# Installed content app workflows
The `article_product_*`, `CREATE_ARTICLE_CATALOG`, `DELETE_ARTICLE_CATALOG` and other existing action/confirmation names remain compatibility identifiers; they do not restrict those shared functions to Article. Article manager-comment notifications, category controls, conversion and assignment remain Article-only. Timeline `timeline_notifications` reads its two post-create events, with no save or mutation revision. Source commit references below record introduction history; current support follows this family policy.
Inspect current discovery before using an operation.
## Select the exact installed app
Choose channelCode from authorized targets and pAppCode from [papps_get](../tools/publ_papps_get.md). Use the exact installed instance, not a guessed base family. Ordinary content operations support OWNER or a DELEGATEE with the exact pApp permission (or the source wildcard); creator access is not supported by this contract. The article catalog membership, original article conversion and manager-comment notification extensions below are OWNER-only. Installation/catalog access alone does not grant content management. Hosted operations are channel-scoped; account permission is not a substitute.
| Family | App | Supported instance pattern |
| --- | --- | --- |
| A00001 | Timeline | A9xx01 |
| A00002 | Notices | Base code |
| A00003 | Free board | A9xx03 |
| A00005 | Inquiry board | Base code |
| A00009 | Subscriber questions | Base code |
| B00001 | Articles | B9xx01 |
| B00005 | Photobook | Base code |
| B00012 | Resources | B9xx12 |
Each `xx` is exactly two decimal digits. A valid pattern is not evidence of installation or permission. The transport binds channel, exact app, installed app ID, operator and credential, and checks authorization around requests. Consumer IDs and credentials are internal; do not supply your own. A missing configured transport returns AUTH_REQUIRED rather than pretending a demo operation succeeded.
## Choose an operation
| Task | Read or inspect | Change |
| --- | --- | --- |
| Content list/detail and supported editors | [content_posts_get](../tools/content_posts_get.md) | [content_post_apply](../tools/content_post_apply.md) |
| App settings | [content_settings_get](../tools/content_settings_get.md) | [content_settings_apply](../tools/content_settings_apply.md) |
| Free-board/article categories and labels/subcategories | [content_taxonomy_get](../tools/content_taxonomy_get.md) | [content_taxonomy_apply](../tools/content_taxonomy_apply.md) |
| Comments/inquiry answers | [content_comments_get](../tools/content_comments_get.md) | [content_comments_apply](../tools/content_comments_apply.md) |
| Subscriber-question replacement | [content_question_start, mode inspect](../tools/content_question_start.md) | Same operation, mode start |
| Series and ordered links | [content_series_get](../tools/content_series_get.md) | [content_series_apply](../tools/content_series_apply.md) |
| Publication schedules | [content_schedule_get](../tools/content_schedule_get.md) | [content_schedule_apply](../tools/content_schedule_apply.md) |
| Original file bytes | [content_file_upload, dryRun](../tools/content_file_upload.md) | Same operation, then a separate content/editor save |
`screen_describe` with screenId `channel.content` provides the source workflow summary when available in the connected scope. Read support does not imply every app supports every write. In particular, inquiries are answered through comments; new subscriber questions use their archive-and-create workflow. Outlink B00002 and Welcome B00006 are not supported (removed October 21, 2026); their console data is unchanged. Later extensions below describe their own bounded support, including [original article notification preferences](#original-article-manager-comment-notification-preferences). X00001 general page editing is not supplied by the listed content tools.
## Revisions, dates and uploads
Use the matching read's revision without modification. Post/series creation uses its list selectionRevision; existing targets use detail revision. Taxonomy creation uses the category-list revision; other taxonomy actions use the selected category revision. Comment, schedule, settings and question revisions belong to their own snapshots. A revision from another read is not interchangeable. Ordinary selection revisions bind context, not a complete paginated inventory.
Mutation inputs generally require requestId (8–80 ASCII letters, digits, `_` or `-`), expectedRevision (64 lowercase hexadecimal characters) and the target. dryRun defaults to false. Question inspect has no mutation fields; file upload has no expectedRevision and validates original bytes/purpose instead. Unknown fields in the strict input objects are rejected. Dynamic settings and app-specific constraints can be stricter than a generic JSON Schema envelope; read the relevant page and runtime choices.
Source publication metadata `publishedAt` is UTC without a suffix. Changing that metadata does not create a publication schedule. Schedule writes require a future ISO8601 instant with `Z` or an explicit offset. Never assume the agent's local timezone is the user's intended timezone.
For a new attachment, upload supported bytes, keep the returned location, read the editor again and save the URL with a fresh revision. Upload acknowledgement alone leaves contentSaved:false. Updating resource attachments supplies the complete retained list of 1–10 URLs. Photobook image/audio positions must correspond, and audio requires existing Z00006 availability. Do not infer that an uploaded file is published, readable by visitors or correctly rendered.
## Results, navigation and recovery
`PLAN_READY` is a no-write plan. A matching existing task's dry run is not a fresh current-state check. The source has no atomic compare-and-swap, so a console edit after preflight can still race a save.
Display the single returned labeled navigation link and any parent-destination instruction. Free-board workflows often open category selection; select the category/post there. Upload opens a parent editor destination and does not imply content has already been created. Do not reconstruct deeper routes or replace unavailable navigation with a generic home URL.
Keep the bridge taskId, taskType and original input after an uncertain outcome. `task_status` reads saved progress. `task_resume` never repeats a sent effect, but it is not universally read-only: an untouched prepared post or an unsent question step may continue. Other content changes only read back their sent operation; upload resume cannot request a new credential or resend bytes. A missing create ID requires console reconciliation, never adoption by matching title, reply text or timestamp. Changing requestId is not a recovery strategy for an unknown outcome.
The later catalog extension adds content-catalog without adding a tool name. Hosted status/resume verifies the original target under the current grant. A changed connection, credential, operator, app or permission can prevent continuation. Completed results are historical, with current-state verification false and any saved verification separate; use the matching reader for current state. Deletion has no general undelete, and question replacement can leave partial archives after interruption. No automatic rollback is promised.
Sending a reply or starting a question requires the human's instruction for that communication. Publishing, deletion, schedule changes and uploads likewise follow the requested business task; this Reference is not authorization to execute them.
## Article categories and tab visibility
Article category/label traffic uses v2; free-board retains v1 and its distinct bounds/deletion confirmation. Read complete inventories before creating categories or editing a selected category/subcategory. See [taxonomy apply](../tools/content_taxonomy_apply.md#article-lifecycle-constraints) for limits, zero-post deletion, full label order and preservation.
New categories have a blank cover and isPublished:false. Existing HTTP(S) covers may be retained/replaced or cleared. Upload leaves contentSaved:false; select the category, read its fresh taxonomy revision and separately save coverImageSrc. Restoring its prior URL does not delete the uploaded object. This adds no publication workflow. The source publish control is disabled. [Article settings](../tools/content_settings_get.md#article-category-tab-prerequisite) exposes existing published IDs; hideCategories in either direction requires a fresh nonempty published inventory and cannot remove the last visible tab. Creating an unpublished category is not enough.
## Article catalog membership access
Select an existing POST catalog in B00001/B9xx01 or A00001/A9xx01 and existing channel membership business IDs. This bounded monetization slice is OWNER-only; app permissions alone cannot authorize delegates. It changes existing subscriber access without creating products/memberships, enrolling subscribers or editing individual prices.
Use the catalog-membership revision and CHANGE_CATALOG_MEMBERSHIPS confirmation. Preserve the original content-catalog task after uncertainty. Durable per-catalog guards prevent a fresh request bypass; sent effects only reconcile by observation. Exact membership sets, retained rows, sibling catalogs, candidates, prices and target contents must be preserved as specified. Computed flags are not guessed from counts, and stored linkage does not prove visitor access or billing.
The closed OWNER-only route checker, current authorization/context and exact installation guard the channel-header/consumer-query requests; GET200/data and POST204/none are handled separately from ordinary settings. Older hosts without the port still return CONTENT_CATALOG_TRANSPORT_REQUIRED without a write.
## Select an article's published category
MCP adds [set_article_category](../tools/content_post_apply.md#select-an-existing-article-category) to the existing post writer. Use the post detail revision and the selected published category detail's separate expectedTaxonomyRevision. Send every desired subcategory ID, zero to five; an empty array clears them and category changes never implicitly retain old selections. New unpublished categories cannot be selected. The action preserves unrelated post content/access/pricing data and does not publish the post or category.
It reuses the common post/taxonomy transport. Sent recovery only reads back; completed replay is historical. Category counts can change after assignment, so preflight taxonomy revision is not an after-write equality assertion.
## Preserve article addresses while setting image descriptions
For existing B00001/B9xx01 articles, MCP adds [the shared image-description action](../tools/content_post_apply.md#article-image-descriptions). Read detail, preserve the original metadata and use its revision. One nonempty 1–100 UTF-16-unit value updates both thumbnail/cover descriptions. Image URLs, the original returned slug and unrelated metadata must remain unchanged; ambiguous slug transformations are refused. This reuses the existing registered post adapter and content-post journal, with sent-write observation rather than replay. Exact restoration requires identical nonempty originals. It is not a general SEO or URL editor, and actual console/visitor accessibility/restoration remains unverified.
## Existing article GENERAL labels
These labels are separate from category sublabels. Read the complete inventory and post detail, retain both revisions, and supply every desired GENERAL ID, zero to five; [] clears only the post selection. The unpaged inventory's defensive 1,000 limit is not a label creation cap. The later GENERAL lifecycle extension below adds create/rename/delete; GENERAL ordering remains unavailable.
Sent recovery observes the post without replaying PUT and verifies unrelated fields under the existing post rules. Older hosts without it still block both operations explicitly. This source connection does not prove actual API, console, visitor, restoration or hosted/LLM behavior.
## Manage article GENERAL label records
Use the general_labels inventory revision and preserve the returned content-general-label task type. Names have1–30 untrimmed UTF-16 units; creation needs a new response-returned identity. Sent recovery only observes and never adopts by matching name. Category workflows and post selection retain their distinct revisions/tasks.
Dry run previews current usage counts. Used-label deletion is allowed by this source contract, but original identity and associations cannot be restored, and cascade/visitor effects are not verified by inventory readback. Shared SDK fixtures cover receipt handling and observation-only sent recovery; fixture cleanup does not restore deleted identities or verify linked content.
## Choose category and labels when creating an article
Read the post list for the top-level selectionRevision, the chosen published category detail for category.expectedRevision, and GENERAL inventory for generalLabels.expectedRevision. Send either selection object or both, with zero to five unique IDs per label array. The two label namespaces and revisions are distinct.
Selections travel with the ordinary article fields in one POST. Empty arrays are omitted from that request but verified empty in readback; omitting an entire selection object retains the prior behavior for that selection. The workflow creates no taxonomy records and publishes no category. Keep the returned post identity and content-post task after uncertainty; sent recovery observes without recreating.
## Describe article images during creation
Keep ordinary fields and explicit visibility, use the post-list selectionRevision, and optionally combine category/GENERAL selections with their own revisions. This works without selected images and does not upload or issue a second save.
Without the later explicit articleSlug option, the original blank-slug value is sent as null, while readback verifies the two descriptions and requested post fields without inferring a server URL rule. Existing-post edits retain their original-slug preservation rule. Keep the returned identity and content-post task after uncertainty; never recreate a post because its acknowledgement was lost.
## Create photobooks without descriptions or clear existing text
Omitted or empty content/introduction on create is omitted from the POST, with absent/null/empty saved values accepted. On update, an explicit empty string clears that field and must read back exactly empty; omitting it preserves the previous value. Nonempty content remains 2–50,000 UTF-16 units, title 1–50 and introduction at most 120. Null input is not a clear request.
Creation still requires ordered existing image/audio slots and explicit visibility. Text-only edits preserve image/audio order, metadata, access references and unrequested fields without a new upload or sound activation. Use the list selectionRevision for create or the selected detail revision for an edit, retain content-post recovery and never repeat a sent effect. A lost create receipt cannot be recovered from matching text; uncertain clears need reconciliation before a separate fresh-revision restoration.
No source integration changes runtime availability or grants.
## Set an original article catalog's individual price
MCP adds [catalog_pricing reads](../tools/content_settings_get.md#original-article-individual-pricing) and [full-form save/discard](../tools/content_settings_apply.md#original-article-individual-pricing) to the existing settings tools. Use the exact selected app as OWNER, discover an existing POST catalog and read its pricing revision, currency and limits. Preview the complete form, then apply only the authorized change. Aliases are not remapped; general pApp permission does not enable delegate access.
Use channel-currency amounts on input. Raw CP output uses the source KRW×1/USD×1000 write conversion, while USD original-screen display parity remains unverified. CASH_AND_CP requires fresh verified branding. CASH_ONLY may use unverified branding data but never bypasses a transport/authentication failure. Do not reuse membership-product price rules.
Save preserves price identity and unrelated catalog, membership, target, post, currency and branding state. Discard removes only the price and has no automatic restoration. Unexplained changes to catalog flags remain unverified even when suspected to be server-derived. Pricing, membership and content-link changes share one persistent content-catalog guard: preserve an uncertain task and use its readback-only recovery rather than a new request.
The common catalog/currency/branding ports and hosted proxy are connected in this source; no new tool or task type is added. Owner direct/compact fixtures with intercepted HTTP do not prove real API responses, visitor entitlement, console rendering, payment or purpose-only LLM behavior. Existing upload holds and the rest of B00001 remain separate.
## Rename or activate one original article catalog
MCP adds [catalog_details reads](../tools/content_settings_get.md#original-article-catalog-details) and [rename/set_active](../tools/content_settings_apply.md#original-article-catalog-details) to the existing settings tools. As OWNER on exact selected app, select an existing POST catalog, read its complete revision and preview one desired title or boolean state. Combined fields, deletion, bulk activation and filtered search are outside this option. Exact installed B00001/B9xx01 and A00001/A9xx01 codes are supported without remapping. The later [creation workflow](#create-an-original-article-catalog) uses its own creation revision.
The common PUT connection and catalog detail navigation are implemented. Receipt identity plus fresh list/detail/linked-post agreement and preservation are required; no-op sends no PUT. All four catalog actions share the same guard and readback-only sent recovery. Unexplained catalog timestamps or other preserved-field changes remain unverified. Activation may affect linked content access without publishing posts or changing price forms.
No new tool, task type or currency/branding dependency is introduced.
## Create an original article catalog
MCP adds [catalog_creation options](../tools/content_settings_get.md#original-article-catalog-creation-options) and [catalog_create](../tools/content_settings_apply.md#original-article-catalog-creation) to the existing settings tools. As OWNER on exact selected app, read the complete catalogs and membership candidates plus currency/branding. Use that creation revision, a title and at least one existing membership or a complete individual-price form. Both access choices may be combined. Preview first, then apply only the authorized creation; exact installed B00001/B9xx01 and A00001/A9xx01 codes are supported, while arbitrary target models are not accepted.
The workflow creates one POST catalog with no connected posts. It creates no membership product and makes no purchase. Price rules, original-price fallback, verified point-branding requirements and USD raw-CP/display uncertainty are shared with individual pricing. Creation requires fewer than 2000 existing catalogs and accepts at most 100 selected membership IDs. Common catalog/currency/branding ports, registration and the create/detail navigation are implemented in this source; running-server support remains separate.
Keep the content-catalog task and original request. A returned identity is usable for recovery only after durable storage. Lost or invalid receipt identity cannot be guessed from a title or list difference and must never trigger another POST. An unresolved creation blocks fresh catalog writes across that exact installed instance, including writes to existing catalogs; original pending tasks remain reconcilable. With a saved identity, retries/resume only verify the created catalog's requested access configuration, empty targets and preserved prior state. They do not create again, clean up or roll back.
The options/preview link opens creation; a verified created result opens the exact returned catalog's detail. Read the matching view again before editing because creation does not return an edit revision. The later [catalog deletion workflow](#delete-one-original-article-catalog) uses a fresh detail revision. Existing upload holds and bulk activation remain separate work.
## Delete one original article catalog
MCP adds [catalog_delete](../tools/content_settings_apply.md#original-article-catalog-deletion). As OWNER on exact selected app, read catalog_details, inspect the catalog's linked posts, memberships and price, then preview deletion using that fresh revision and DELETE_ARTICLE_CATALOG. The existing common transport sends one exact DELETE and requires 204/no body.
Completion needs both full-list absence and an exact detail404, while preserving every other catalog, membership candidate and previously linked post. Posts keep their business fields and other catalog links; only this catalog reference is removed. The returned link opens the surviving catalog list. It is a parent destination, not a deleted-detail link or proof that a planned/uncertain deletion succeeded.
Keep the content-catalog task if acknowledgement or readback is uncertain. Retry/resume reads only; it never deletes again or recreates the catalog. The per-catalog guard and instance creation guard still apply. Source checks do not prove physical price cleanup, purchased-access revocation, refunds, original-console/visitor agreement or restoration.
## Search original article catalogs
MCP adds [catalog_search](../tools/content_settings_get.md#original-article-catalog-search) to content_settings_get for OWNER on exact selected app. Choose one page, a source page size of 15, 30, 50 or 100, an optional search string and an optional active-state filter. Defaults are page 1 and limit 15. Omitted isActive means all states; false explicitly requests inactive catalogs. Only an exactly empty search is omitted; other text is preserved without trimming, and API matching/order remain authoritative.
Use catalogSearch and catalogPagination to interpret the returned page. completeInventory refers only to a first page containing the entire filtered total, not a mutation-ready unfiltered snapshot. The read returns no mutation revision or saved task. Select a supported catalog and read the relevant detail/action view before editing; do not reuse the search result as a write precondition.
The current navigation opens the parent catalog list. Reselect search, active state, page and page size there before comparing the original console with MCP results. Core's exact-query navigation hookup and the owner's corresponding result transition are pending, so the link does not promise the same conditions.
## Create or edit an original article product
It uses the existing common catalog/currency/branding connections and content-catalog task. No new method or task type is needed; aliases and delegate configuration remain outside this option.
1. For creation, read view:article_product_creation. For editing, select the observed numeric product ID and read view:article_product_edit. The older paged article_products and plain article_product reads provide no write revision. Preparation must verify the complete inventory within 2000 rows, matching list/detail, currency and branding.
2. Choose the complete source form. Creation includes internal/visible names, selling price, period, deactivation and purchase methods. Editing accepts visible name, deactivation, purchase methods and optional original price; name, selling price, period and recurring stay unchanged. Use [input limits and price rules](../tools/content_settings_apply.md#article-product-fields-and-prices), including channel-specific minima and verified branding for CASH_AND_CP. Values are currency strings, with no catalog CP conversion.
3. Omit originalPrice at creation to use sellingPrice; omit it at editing to preserve its existing value. Empty/null is not a clearing request. Supply required fields explicitly even when the getter advertises source defaults. Preview dryRun:true with the matching revision and inspect plannedBody before an authorized new save.
4. Preserve the original requestId and content-catalog task after a write attempt. A new creation identity must be durably stored before verification. Missing identity cannot be guessed or recreated; unresolved creation/edit blocks fresh product writes on the exact installed app. Identical retry/resume only reads and never repeats POST/PUT.
5. Use the returned exact editor for a known product. Creation preparation opens the product list; the human must open the create modal with its button. The list link does not open or prefill the form. A known-target link during uncertainty is for inspection, not confirmation.
6. Verify supported values and preserved products. Any later reverse edit needs fresh preparation after uncertainty is resolved.
This configures product display/payment choices without a purchase, subscriber assignment, publication or notification.
## Manage an original article conversion link
MCP extends the existing [post reader](../tools/content_posts_get.md#original-article-conversion-link-and-history) and [post writer](../tools/content_post_apply.md#original-article-conversion-initialization-and-editing) for OWNER on exact B00001. No method or task type is added. A post's dedicated string link identity and original start/information/history screens remain separate from channel-wide numeric conversion links and their policy.
Read article_conversion_link for the current dedicated revision. Only its dedicated GET404 means the link is uninitialized; an installed-app preflight404 is CONTENT_APP_CHANGED. Preview initialize with INITIALIZE_ARTICLE_CONVERSION_LINK or edit with CHANGE_ARTICLE_CONVERSION_LINK. Edits preserve omitted full-form values, trim only edited text and support title/description, destination kind/URL, enabled and thumbnail clearing. New thumbnail uploads and arbitrary replacement URLs remain unsupported. History uses its own page/limit query and unchanged original date labels, not the ordinary list query.
Keep the content-post task and original input after uncertainty. An initialization identity is usable only once durably saved; no receipt means no identity adoption or second POST. Exact retry/resume reads only. An unresolved conversion blocks fresh conversion and ordinary mutations on that article, with no retroactive migration of older journals or external-writer guarantee. The article conversion projection and unrequested link/post fields must survive readback. A parent inspection link or historical completion does not prove a successful current save.
Use a fresh dedicated revision for any later reverse edit. Clearing an old thumbnail has no API-only restoration path; initialization has no exposed delete/undo. Existing upload HOLD and delegate/creator policy limits remain open.
## Choose or preserve an original article address
Use ordinary list selectionRevision for creation or post-detail revision for an existing article. The existing post transport, console detail destination and content-post task remain; aliases/delegates are not newly authorized.
On create, choose custom with a 1–50 UTF-16-unit value or automatic to send null. Omitting articleSlug preserves the old body, including the existing null-slug behavior when image descriptions are supplied. Category/GENERAL selections and the shared image description may compose in the same request with their existing rules. On edit, choose custom or keep with CHANGE_ARTICLE_SLUG; blank editing is not reset-to-automatic. Source sanitization preserves case, removes unsupported characters and joins whitespace with hyphens; it does not transliterate or collapse existing hyphens.
Custom readback accepts only the submitted segment or its unambiguous source-compatible post-ID form. Automatic creation needs a durable valid server receipt and identical fresh read; no title-derived URL is guessed. Preserve non-slug metadata, both image descriptions individually and other article fields. Keep/already-matching edits send no PUT. The result's articlePath is relative only, publicUrl:null and publicOriginVerified:false; use the original console link, without constructing a public URL or claiming uniqueness, redirect or visitor success.
Retain the original task after uncertainty. Sent retries/resume read only; missing create identity or slug receipt cannot be adopted from similar/current content. A fresh manually supplied requestId is not globally blocked by ordinary-post journals, so reconcile first. Existing conversion pending guards still apply to fresh slug actions. Reverse changes need a fresh revision and may be unable to restore unusual/overlong old values.
## Manage an original article selection candidate
Current source connection: The shared port now forwards bulk deletion through the existing guarded content transport.
Historical candidate boundary (next paragraph only; the heading and anchor remain stable):
Shared deleteContentPosts forwarding and combined integration remain pending.
1. For OWNER on exact B00001, choose 1–100 observed post IDs and read [article_selection](../tools/content_posts_get.md#original-article-selection-candidate) in that order. Full snapshots must fit 4 MiB. Remove absent targets before preparing a new mutation.
2. Use that revision for [publish/unpublish/delete](../tools/content_post_apply.md#original-article-selection-candidate), with its exact confirmation and stable requestId. List/detail/category/conversion revisions do not substitute. Preview dryRun:true without creating a journal; a missing common delete forwarding method also blocks a new delete preview.
3. Publication skips matching states and processes changed targets sequentially, stopping on a failed transport or unverified target. Later targets remain unsent. Deletion uses one bulk request and verifies each dedicated absence; acknowledgement alone does not prove every article was removed.
4. Inspect each target state/time. DONE requires all targets completed/unchanged and observed. PARTIAL may contain completed, failed, uncertain and unexecuted rows. These are sequential recorded observations, not an atomic transaction or one current snapshot.
5. Retain the content-post task. Exact retry and [resume](../tools/publ_task_resume.md#original-article-selection-recovery-candidate) only observe, including prepared and unexecuted work. They never execute the abandoned remainder. Uncertain attempted targets block fresh mutations; terminal observations stay historical. Replan later intended work with a fresh selection and explicit confirmation after uncertainty is resolved.
6. Open the parent list and inspect the exact IDs after manually reselecting page/search/filters. Deletion has no undo; replacement articles cannot restore the original identities, comments or links.
This action is separate from create.articleSelection category/generalLabels, ordinary visibility/deletion and dedicated conversion options. No public method/task is added.
## Change an original article assignee
The existing tools and guarded transport are connected in source.
1. As OWNER on exact B00001, select an observed post and read [article_assignee](../tools/content_posts_get.md#discover-an-original-article-assignee). Review current identities and candidates; use profileId rather than a name. Delegate/creator operator access is not implied by a candidate's role.
2. Keep the dedicated revision. Multiple current people require console reconciliation, and an empty candidate list supplies no selectable person. No clear action is available.
3. Preview [article_assignee apply](../tools/content_post_apply.md#change-an-original-article-assignee) with the chosen profileId, CHANGE_ARTICLE_ASSIGNEE, a stable requestId and dryRun:true. Selecting the same current identity sends no POST. The actual source method for a change is POST, with one complete discovered candidate.
4. Check the saved requested identity, dedicated current-assignee readback, optional post projection and unrelated post preservation. Acknowledgement or matching names alone do not verify assignment; notification and console effects remain unverified.
5. On uncertainty, retain the original content-post task. Identical retry/resume only observes, including prepared work. Attempted unknown outcomes block fresh assignment/ordinary/selection/conversion changes to that target; existing selection/conversion guards also apply. Never use a new ID to evade them.
6. Use the exact returned post-detail link when present. To restore a previous person, resolve uncertainty and read fresh candidate eligibility/revision before explicitly selecting them in a new request. Formerly unassigned state, multiple assignment and notification reversal cannot be restored by this action.
The bounded candidate lists and 4 MiB snapshot are bridge limits, and sequential observations are not atomic. No method or task type is added.
## Original article manager-comment notification preferences
This connects the existing settings methods and canonical recovery in source.
1. Select the authorized channel and exact installed B00001 as OWNER. Use [content_settings_get](../tools/content_settings_get.md#original-article-manager-comment-notification-preferences) with view.kind:article_manager_comment_notifications.
2. Examine ACTIVE, stored email/app/PWA/realtime values and both available transitions. Changing ACTIVE off clears all three delivery flags; turning it back on preserves their current values and does not restore them. Already matching ACTIVE performs no delivery cleanup.
3. Confirm the intended four-field effect, then use [content_settings_apply](../tools/content_settings_apply.md#original-article-manager-comment-notification-preferences) with the matching revision, explicit active, stable requestId and CHANGE_ARTICLE_MANAGER_COMMENT_NOTIFICATIONS. Start with dryRun:true. No independent delivery edit, receiver normalization or sending is available.
4. Treat completion as fresh full-record readback and preservation only. Retain content-settings and the original taskId on uncertainty; prepared and sent recovery both observe without repeating PUT. Reinstalling the app cannot bypass the channel/event marker. Ordinary settings remain independent.
5. Follow the returned exact B00001 /notice destination to inspect notification settings. An action_required inspection link can be valid while the save remains unverified; retain its completion disclaimer. This screen is not a notice-post editor.
The fixed event is SELLER_P_APP_B00001_POST_MNG_COMMENT_CREATE. Real changes require the existing SELLER / SOURCE_DETAIL_META_SUBSCRIBER_DISTINCT_ID receiver policy. Restoring ACTIVE needs a fresh explicit operation, and cannot reconstruct delivery flags cleared by OFF. Translation backlog and D-PLAN-1 are unaffected.
## Timeline asynchronous video workflow
Use the existing [file uploader](../tools/content_file_upload.md#timeline-file-processing)
for Timeline PNG/JPEG normalization or trusted video inspection and upload. A
video resource upload does not create a post. Read the acknowledged upload with
[Timeline video preparation](../tools/content_posts_get.md#timeline-video-candidate-and-result-reads),
then use [timeline_video_create](../tools/content_post_apply.md#timeline-asynchronous-video-creation)
with the returned revision, selected labels and catalog business IDs. This creates
an encoding candidate once. Candidate WAITING/POSTED observations retain no final
post ID and no playback claim. The existing content-post task resumes by observing
the exact saved candidate; lost receipts are never guessed or retried.
An explicitly selected normal post can be compared independently through timeline_video_result. Matching text/labels/catalogs does not prove authoritative candidate linkage. The original console must separately verify video playback, publication and any verification-post cleanup. The source has no Timeline series or dedicated candidate-manager route.
