[Migration map](../reference/tool-name-migration.md).
# task_resume — continue the original operation
[resource-specific discovery](../reference/results.md#segment-task-discovery-and-resource-scope) has narrower enums and different default requirements.
Continue an existing saved workflow after checking [task_status](publ_task_status.md). This is a mutation-capable operation: its annotations are `readOnlyHint:false`, `destructiveHint:true`, `idempotentHint:true`, and `openWorldHint:true`. A resume can perform remaining publication, deletion, access changes, uploads, or credential refresh according to the original request. The hints do not authorize a new operation or promise an atomic transaction.
## Input
| Field | Type | Required | Constraint |
| --- | --- | --- | --- |
| `taskId` | string | Yes | Exactly 8–80 ASCII letters, digits, underscores, or hyphens; copy the returned ID. |
| `taskType` | enum string | Required on hosted channel; optional on account/local stdio | Copy the returned type. Account/local stdio defaults to `channel-create`; hosted channel has no default. See [current 34-type scope](../reference/results.md#segment-task-discovery-and-resource-scope). |
```json
{"taskId":"example-profile-001","taskType":"account-profile"}
```
The ID is illustrative and must already exist. `null` is not accepted. Resume has no input for a new target, revision, nickname, content, file, or request ID. The saved inputs, connection, owner/target, and runtime job storage must still match. Recalling the original change tool with its request ID likewise requires the original business inputs and revision.
Account schemas expose seven types; selected-channel schemas expose 26 and require taskType. Local stdio exposes all 34, including local-only domain-favicon. The new segment type is channel-only. Descriptions render the allowed names and scope/default rules. An unknown or cross-resource type is not authorization to inspect another store; use the [current scope table](../reference/results.md#segment-task-discovery-and-resource-scope).
## Recovery behavior
| Saved situation | Behavior |
| --- | --- |
| No job | Return a missing-task result. Resume cannot replace an original execution request or materialize a dry-run plan. |
| Prepared, definitely not sent, or definite rejection | Recheck the saved plan, identity, permissions, and relevant current state. Remaining original writes may execute if the workflow permits it. |
| Request sent with uncertain outcome | Observe or reconcile using that workflow's rules; do not blindly resend the uncertain write. |
| Created entity with an acknowledged ID | Continue supported verification or subsequent steps using that exact ID. |
| Creation receipt lacks the required ID | Stop for inspection when the workflow cannot safely identify its creation. A matching name or body is not permission to adopt an unrelated object. |
| Conflict or changed context | Return a conflict/context or human-action result; do not replace the stored input or switch accounts to bypass it. |
| Completed job | Return the historical saved result. Use a separate get for current state. |
For channel creation, `prepared` can proceed with revalidated options and creation; `creating` returns `CREATE_OUTCOME_UNKNOWN` without recreating; `created` continues refresh/readback; `done` or `failed` returns its saved result. This describes legacy/default-image creation. Sent unknown stages never repeat; untouched upload requires the identical channel_create input and original bytes (ICON_FILE_REQUIRED), while acknowledged refresh leaves only channel readback. Do not migrate an old journal or generalize these new checkpoints to legacy jobs. See the [creation recovery contract](publ_channel_create.md#saved-identity-effects-and-recovery). A partial task is not automatically rolled back.
## Workflow-specific limits
- Design, access, menu, page, and channel settings may have multiple steps. Earlier changes can remain applied if a later step fails. Resume uses checkpoints and does not automatically restore previous content or visibility.
- Channel archive/unarchive resumes the remaining batch without replaying an uncertain sent change. Completed counts describe that saved batch, not a new account-wide audit.
- Terms publication and page/menu creation need their required response IDs. Unknown receipts must not be replaced with guessed IDs or new creation requests.
- Manager and member-moderation tasks recheck the relevant channel/identity/permission boundaries.
- Domain registration completion can still require human DNS setup. Sent activation and deletion operations are observed rather than replayed; domain absence and record absence each have their own completeness requirements.
- Domain record creation requires its saved receipt identity; a matching hostname is insufficient. Incomplete pagination cannot establish deletion. No automatic delete/recreate conversion is performed.
- Favicon recovery never obtains another upload grant or repeats an uncertain upload. Incomplete grant/upload acknowledgement requires operator inspection. A saved uploaded asset can proceed to its original reference update after required checks.
- Account profile recovery can include the original nickname save and account credential refresh. Seller-contact recovery preserves the complete original form. Unknown saves/refreshes are not resent; completed replays are historical with `verification.confirmed:false`.
Later task types include membership-display-settings, sitemap-indexing, channel-seo, analytics-tools, marketing-widget, questionnaire, conversion-link, legacy-promotion-link and promotion-notifications. Use each writer's phase rules. Untouched stages may proceed after guards; sent saves/uploads are not blindly replayed. Questionnaire and conversion creation need durable identity; original apply bytes may be required for untouched image stages. Notification recovery reads the fixed event after save-sent, tolerates only its documented generated updatedAt change and requires full preservation. Segment recovery follows prepared/write-sent/done: only prepared may send the original first write; sent writes only reconcile. A lost create identity is never adopted by title. See the [segment guide](../guides/segments.md#saved-work-and-recovery). Campaign and discount handoffs create no tasks.
## Completed member-moderation history
It retains earlier result data while directing nextStep to member_moderation_get with the original channelCode/profileId. Channel/connection/permission and journal integrity are checked, but no member-state read or moderation write occurs and the journal remains unchanged. An inherited writesPerformed value belongs to the earlier result. Current navigation is unavailable. Identical non-dry-run member_moderation_apply replay uses the same behavior; its existing-job dryRun remains a plan.
## Inputs
| Field | Required here | Contract |
| --- | --- | --- |
| `taskId` | Yes | string; pattern `^[A-Za-z0-9_-]{8,80}$` |
| `taskType` | Yes | `messenger-room-product`, `messenger-room-create`, `messenger-settings`, `messenger-notifications`, `messenger-welcome`, `messenger-message-hide`, `messenger-gift-reactions`, `messenger-app-product`, `autonomous-room`, `autonomous-room-password`, `autonomous-room-delete`, `autonomous-room-moderation`, `autonomous-room-create`, `autonomous-room-image`, `autonomous-room-image-replace`, `messenger-room-thumbnail`, `messenger-room-thumbnail-replace`, `gift-products`, `messenger-gift-editor`, `messenger-gift-image`, `web-message-schedule`, `web-delivery`, `web-schedule-activation`, `email-settings`, `email-draft`, `email-label`, `email-draft-labels`, `email-duplicate`, `email-audience`, `email-image-upload`, `email-recipients-upload`, `email-image-delete`, `email-sender-verification`, `email-delivery`, `messenger-room`, `room-operators`, `messenger-paid-pricing`, `messenger-participants`, `messenger-room-quiet`, `messenger-read-marker`, `messenger-reply-task`, `messenger-reply-bulk`, `messenger-direct-room-create`, `messenger-room-memberships`, `messenger-room-pricing`, `messenger-delivery`, `messenger-media-delivery`, `messenger-promotion-delivery`, `messenger-media-upload`, `messenger-media-encode`, `commerce-ticket-event`, `commerce-image-binding`, `commerce-ticket-tier-label`, `commerce-ticket-venue`, `commerce-ticket-template`, `commerce-ticket-capacity`, `commerce-ticket-seats`, `commerce-ticket-settings`, `commerce-ticket-notifications`, `commerce-ticket-translation`, `commerce-ticket-discount-creation`, `commerce-ticket-policy-labels`, `commerce-product-control`, `commerce-product-settings`, `commerce-image`, `commerce-creation`, `commerce-ticket-pricing`, `commerce-ticket-refund-settings`, `commerce-ticket-discount-settings`, `commerce-ticket-policy-lifecycle`, `commerce-ticket-operation`, `commerce-ticket-schedule`, `commerce-ticket-schedule-policies`, `commerce-ticket-schedule-batch`, `commerce-ticket-schedule-edit-many`, `commerce-reservation-settings`, `commerce-reservation-slot`, `commerce-reservation-product`, `commerce-reservation-unlock-product`, `commerce-reservation-coupon`, `commerce-legacy-ticket-policy`, `commerce-legacy-ticket-label`, `media-course-home`, `media-course-session-editor`, `media-course-description`, `course-image`, `media-course-cover`, `media-course-notification`, `media-video-upload`, `media-course-product`, `media-course-catalog`, `media-course-catalog-price`, `media-settings`, `media-collection`, `media-live`, `media-post`, `media-label`, `media-vod-appearance`, `media-schedule`, `media-upload`, `media-subtitle`, `media-course-comment`, `media-course-notice`, `media-course-review`, `content-post`, `content-settings`, `content-taxonomy`, `content-comments`, `content-question`, `content-series`, `content-schedule`, `content-upload`, `content-catalog`, `content-general-label`, `content-home`, `channel-admin-app-release`, `channel-notifications`, `channel-profile`, `channel-branded-app`, `monitoring-account`, `design-theme`, `menu-design`, `custom-code`, `access-control`, `iframe-page`, `general-page`, `member-view-restriction`, `customer-support`, `page-design`, `menu-tree`, `channel-settings`, `papp-lifecycle`, `signup-form`, `menu-items`, `default-entry`, `menu-options`, `terms`, `member-moderation`, `managers`, `membership-product-create`, `point-settings`, `point-provisions`, `point-products`, `discount-settings`, `discount-create`, `promotion-campaign`, `promotion-campaign-create`, `promotion-benefit-create`, `promotion-benefit`, `membership-products`, `membership-create`, `membership-metadata`, `membership-display-settings`, `sitemap-indexing`, `channel-seo`, `analytics-tools`, `marketing-widget`, `questionnaire`, `conversion-link`, `legacy-promotion-link`, `promotion-notifications`, `segment`, `channel-insight`; Required: copy the taskType returned by this selected-channel workflow. Only task types admitted to this resource are listed. Legacy ticket policy and label support has ended. This identifier returns guidance only; task_status and task_resume neither read stored business data nor retry, migrate or delete past work. Preserve the original task and contact the operator if its outcome is uncertain. No replacement app is selected automatically. |
## Result and failure handling
Resume returns the corresponding business workflow's completion, pending, error, or human-action payload, not a universal `RESUMED` result. Read `status`, `code`, `outcome`, `verification`, saved progress, and any required action together. Task/context metadata may vary when a failure occurs outside the main workflow. See [common results](../reference/results.md).
Keep the same task after interruption or uncertain response. Do not change its request ID, target, input, or private state to bypass a conflict. A current read may clarify the situation but is not by itself authorization to repeat the original mutation.
Implementation: `src/server.ts` dispatch, `src/state.ts` locking, and each workflow's `resume`/continuation logic. The [agent guide](../agent-guide.md#using-tool-descriptions-and-saved-jobs) covers choosing between current reads, status, and resume.
## Older saved member-ban reasons
See the [current reason-length and recovery rule](../reference/README.md#current-member-ban-reason-length). Status can report `dispatchBlocked:INVALID_BAN_REASON` for an unsent old ban. Resume does not rewrite it or send that invalid reason. Already-sent tasks still reconcile, and completed records remain historical.
## Older saved SEO text
The [current SEO text contract](../reference/README.md#current-seo-text-length) preserves old input records. Status marks an overlong prepared/uploaded plan with `dispatchBlocked:INVALID_SEO_TEXT`; resume leaves its journal and object intact without saving. Already-sent stages retain their existing uncertainty/reconciliation rules and are never repeated.
## Campaign creation recovery
Copy its taskId and original selected context. Status reads saved progress; resume only observes. Prepared work can dispatch only through the identical create call after fresh checks. Sent creation never repeats, and absent receipt identity is not recovered by title or list changes. A receipt binds both campaign and initial-benefit identities; an equivalent replacement benefit cannot satisfy recovery. Completed replay is historical.
## Article catalog and image-card recovery
Copy its returned type instead of content-settings. Status is historical; resume or identical sent apply only observes the exact expected membership set and preserved catalog/price/target/retained-membership records. An unresolved durable catalog guard prevents a new request from bypassing the original task. Runtime deployment and actual recovery/access/restoration remain unverified; no successful live task is implied by this namespace.
Pricing, content-link and membership changes share one guard. Unresolved work of any kind blocks fresh requests of the other kinds; sent pricing retries/resume only read back and never repeat save/discard. Changed price identity, unrelated fields, catalog flags, currency or branding remain unverified. Historical completion does not confirm current price, original-console parity, visitor access or restoration.
All four catalog action kinds block each other while uncertain. Sent detail retries/resume only observe the original catalog and linked references, never repeat PUT; unexplained catalog metadata/timestamp drift remains unverified. A historical result cannot establish current activation or restored visitor access.
Resume and identical apply retries never repeat creation POST. With a durably saved receipt identity, they read back that exact catalog's requested access configuration, empty targets and preserved prior records; without it, CONTENT_CATALOG_CREATION_UNVERIFIED retains createdIdentityKnown:false and cannot discover an ID from title or list differences. Keep the original request/task. CONTENT_CATALOG_CREATION_PENDING blocks fresh creation and fresh existing-catalog writes across the same installed instance; it does not prevent reconciliation of original tasks. No automatic cleanup, recreation or rollback is supplied. Completed replay is historical with writesPerformed:false, not a fresh observation.
Resume and identical sent apply only check complete-list absence, exact detail404 and preservation of older catalog rows, membership candidates and linked posts/other associations. They never repeat DELETE or recreate a catalog, even after a lost receipt or partial result. An unverified outcome retains the original task and shared guard. Fresh deletion is also blocked by an unresolved creation on the same installed instance. Successful recovery may identify the surviving list; completed replay remains historical and cannot prove current state, price cleanup, purchase rights or restoration.
Status/resume observe all creation phases and cannot issue credentials, upload or POST a card. Only identical apply can continue a prepared or durably image-ready stage after revalidation with the original bytes/context/storage/snapshot. Uncertain image-sent and create-sent effects never replay. An image acknowledgement is not creation; a matching created card requires the unique issued-image identity and preserved prior state. Fresh observation requires revision, acknowledged image, matching sent phase and current state; a fresh mismatch remains pending with a parent link, while missing fields, image-only checkpoints and historical results expose no product link. Source connection does not prove actual upload, console state or restoration.
## Shop image and creation tasks
Shared status/resume never issue credentials, PUT bytes or POST a product; prepared work needs the identical original input. Issuing/uploading image uncertainty never repeats. A sent creation requires its durably saved product identity to reconcile and cannot adopt a resource by title or a new requestId. Image references also retain credential-version/storage binding. Completed results are historical with no fresh success link; use the relevant reader for current state.
## Later existing-method recovery options
[Buyer input-field creation](commerce_product_settings_apply.md#one-buyer-input-field) retains commerce-product-settings but needs the exact new field identity from the REVISE response; sent uncertainty never adopts a title or resends. Older settings journals keep their prior requirements. [Card image replacement](media_live_apply.md#replace-an-existing-c00014-card-image) retains media-live with image-sent/image-ready/update-sent checkpoints; status/resume only observe and cannot upload or PUT the card. [Article category selection](content_post_apply.md#select-an-existing-article-category) retains content-post; a sent request only rechecks saved selection and fresh eligibility.
## Shorts conversion-link receipt identity
Creation saves the exact string distinctId as receiptIdentity alongside its numeric post receipt before fresh observation. Missing/lost identity stays pending even if a link now exists; status/resume cannot adopt it or resend a sent write. Prepared recovery is observation-only. Ordinary numeric resource journals remain compatible. The dedicated link revision and unchanged post/link fields govern readback; Only validated fresh sent/done observations can resolve the current screen; a fresh mismatch remains pending, and prepared, unobserved, historical or foreign results have no link. A link does not repair missing receiptIdentity or prove actual restoration.
## Messenger room creation recovery
Unlike workflows that permit remaining writes through resume, this shared resume is observation-only. Prepared/catalog-confirmed require repeating the identical original apply to authorize an unattempted stage after current checks. Sent stages may reconcile only saved identities; unknown catalog/room receipts never trigger title search or another POST. Completed results remain historical. Preserve the original request, journal and any orphan catalog; no automatic rollback or cleanup is supplied.
## Article GENERAL label lifecycle recovery
It is separate from content-taxonomy category jobs and content-post selection jobs; copy the returned type. Status is historical. Resume or identical sent apply reads the complete inventory without repeating a POST/PATCH/DELETE, and does not require the writer hook to remain present. A missing creation receipt never permits name adoption. Completed results are historical; context/credential/instance changes block recovery. Deletion does not restore old IDs/associations. Shared SDK fixtures exercise direct/compact channel routing and observation-only sent recovery, including missing-writer rename/delete recovery.
## Existing seated ticket policy tasks
The historical taskType values commerce-legacy-ticket-policy and commerce-legacy-ticket-label are channel-scoped compatibility notices only, not executable workflows. Both status and resume return action_required / COMMERCE_PAPP_RETIRED with supportEnded:true, writesPerformed:false, writesPerformedThisCall:false, journalAccessed:false and verification.confirmed/currentStateVerified:false. There is no current console link. Account scope rejects these identifiers.
These notices do not open a journal or determine whether the task exists, succeeded or failed. Existing mixed Commerce journal handlers also stop recorded E00002 targets before ordinary plan validation or host effects. Preserve prepared, sent, completed and uncertain records; no retry, observation of business state, migration, deletion or automatic restoration is provided. Do not repeat the removed apply method, change request IDs or replace the app code to continue an old effect. Contact the operator for uncertain historical outcomes.
## E00003 ticket pricing recovery
Use the existing taskType `commerce-ticket-pricing` and original taskId for [ticket_pricing_apply](ticket_pricing_apply.md). Shared-host resume is observation-only: prepared work returns instructions to repeat the identical original apply after revalidation, and a separate request guard blocks recovery writes. A sent price edit, link or unlink is never dispatched again, including through identical apply.
A durably saved created-tier-price ID can be observed after an interrupted read; a missing receipt stays pending with lastCode:COMMERCE_CREATE_UNKNOWN and cannot be inferred from a label, title or list difference. Partial unlinking and collateral changes remain pending without a second delete or automatic relink. Preserve the original request, context and journal. Completed resume is historical with current verification false and no current verified link; use [a fresh read](ticket_pricing_get.md). The [ticket guide](../guides/ticket-pricing.md) describes exact event navigation and the separate actual API/console/restoration limitations.
## E00003 cancellation settings recovery
Use taskType `commerce-ticket-refund-settings` and the original taskId from [ticket_refund_settings_apply](ticket_refund_settings_apply.md). Shared-host resume never sends a business write: prepared work returns saved status and instructions for identical original apply, with a separate request guard preventing recovery writes. Identical apply can dispatch only known-unsent work after revalidation; the later policy guard makes a prepared task with its own durable claim observation-only. Once sent, resume and identical apply only observe the existing exact policy; no second PATCH/POST is dispatched.
These settings edit an existing resource and require no created-ID receipt. Partial saves, field/row drift and changed context stay unresolved; do not switch request IDs or automatically apply a reverse change. Completed replay is historical with current verification false, writesPerformedThisCall:false and no current verified link. Use [fresh discovery/preparation](ticket_refund_settings_get.md) for current values or a separately authorized reverse operation. No actual refund execution, event-copy rewrite or automatic restoration is supplied.
<a id="ticket-policy-metadata-candidate-recovery"></a>
## Ticket policy metadata recovery
[Policy metadata](ticket_pricing_apply.md#policy-metadata-candidate) reuses commerce-ticket-pricing. Shared resume is observation-only. Prepared metadata requires identical original apply; sent metadata only rereads its exact event/default policy and management-label catalog without repeating the POST. It edits an existing policy and needs no created-ID receipt. Partial names, conflicting linked projections, catalog drift or collateral price/refund changes remain pending.
Fresh matching recovery may resolve the exact base-pricing/home destination; completed replay is historical with current verification false and no current link. Existing tier tasks keep base-pricing/detail and their original dependency shape; they do not acquire metadata catalog reads. Do not alter old journals, substitute a task/request ID, or apply an automatic reverse edit to resolve uncertainty.
## E00003 discount settings recovery
For nondelete settings use taskType commerce-ticket-discount-settings and the original taskId from [ticket_discount_settings_apply](ticket_discount_settings_apply.md). Shared-host resume is observation-only: prepared work requires identical original apply after revalidation, and a separate request guard blocks recovery writes. Once sent, resume and identical apply never dispatch another save.
A durably saved tierLink receipt allows observation of that exact new override. Missing identity remains pending with lastCode:COMMERCE_CREATE_UNKNOWN; a matching label/title or list difference cannot substitute. Metadata, sales terms, existing-price edits and unlinking use known identities, so full matching observation may resolve a lost acknowledgement without proving causality. Partial values/removals, catalog drift or collateral changes remain pending, without another POST or automatic rollback.
Preserve the original request, context and journal. Completed replay is historical with current verification false and no current link; use [a fresh exact read](ticket_discount_settings_get.md). Changing requestId or installation cannot bypass uncertainty.
## E00003 ticket operation recovery
Use taskType commerce-ticket-operation and the original taskId from [ticket_operation_apply](ticket_operation_apply.md). Shared-host resume never dispatches a business write: prepared work requires identical original apply after revalidation, and the recovery transport permits only observations. Once sent, neither resume nor identical apply sends another hold, release, metadata update or deletion.
These operations observe existing schedule/sheet identities without a separate created-price receipt. Full matching readback may resolve a lost acknowledgement, but partial changes, buyer races, price/count drift and wrong/duplicate release slots remain pending. Deletion requires explicit same-identity DELETED detail with preserved metadata/counts; a missing detail or 404 is not confirmation. Retain the exact requestId and fields instead of replacing an uncertain task.
Completed resume is historical with current verification false and no current link. Use a fresh [operation preparation](ticket_operations_get.md) for current configuration. Release does not restore old slot identities or erase history; schedule deletion has no automatic undo. A separately authorized reverse change needs fresh preparation and verification after uncertainty is resolved.
## E00003 discount policy deletion recovery
Use the original taskId and returned taskType commerce-ticket-policy-lifecycle for deletion through [ticket_discount_settings_apply](ticket_discount_settings_apply.md#delete-selected-discount-policies). There is no public lifecycle tool pair. Prepared work requires identical original apply through the existing discount method; shared resume cannot send it. Sent work only rereads the complete active inventory and never dispatches a second DELETE.
Completion requires selected-policy absence plus preserved default/unselected policies and event/refund data. Any retained selected embedded projection must be a matching DELETED record with a valid timestamp. Partial removal, inventory drift or read failure remains pending; exact observation may resolve a lost acknowledgement without causal proof. Do not use a new requestId or repurpose a settings task to retry. Fresh confirmed recovery returns the surviving event discount list; completed replay is historical with current verification false and no current link. No recreation, restoration or existing-schedule/ticket propagation is supplied.
Seated-ticket price uses the existing commerce-ticket-operation recovery. It observes the known selected sheet items and complete override maps without a created-price receipt or repeated dispatch. Partial overrides, changed buyers or unrelated-field drift stay pending. Price changes preserve existing slot identity; histories remain outside configuration verification and are not erased. Preserve the original journal. The original per-item price action exposes SEATING only and has no explicit reset/removal entry; setting a base amount keeps the override. Separate schedule-policy changes and override-bearing parking release remain unresolved as described in the [source action boundaries](ticket_operations_get.md#source-action-boundaries).
## Original article product recovery
Resume and identical saved apply only observe the original task; they never issue another POST/PUT, delete a product, roll back or recreate it. Context and authorization must still match. A lost/missing/unpersisted creation identity remains ARTICLE_PRODUCT_OUTCOME_UNVERIFIED even when the complete list contains a similar product. Never adopt by name or list delta. A durably saved identity permits readback of that exact product without another creation.
Readback requires the requested fields, receipt/detail agreement where applicable, complete preserved inventory and unchanged monetary context. Partial effects, altered unselected products or unknown metadata drift stay unresolved. ARTICLE_PRODUCT_PENDING blocks fresh product writes in that installed app until the original outcome is resolved. A new requestId cannot bypass it. Completed retries are historical with current verification false and no fresh link; saved dry-run retries return the old plan without mutating the journal.
Known-target uncertainty may provide the exact product editor for inspection; unknown creation identity uses the parent list and manual modal instructions. Neither proves a successful save. Supported reverse edits need fresh preparation and separate authorization after uncertainty resolves; they cannot restore a missing purchase-method key, clear originalPrice, restore old timestamps/raw formatting or provide creation cleanup.
## E00003 schedule recovery
Use taskType commerce-ticket-schedule and the original taskId from [ticket_schedule_apply](ticket_schedule_apply.md#results-and-recovery). Shared resume is observation-only: prepared work requires identical original apply and a separate host guard prevents recovery writes. Sent work observes the exact known schedule/dependencies without another PATCH or CREATE_LOOP.
A creation without a durably returned identity stays COMMERCE_CREATE_UNKNOWN; a matching name or list delta cannot supply it. A saved identity allows failed readback to resume. Completion checks requested configuration and preserved dependencies/counts; initial parking additionally checks the whole created sheet and selected metadata. Partial effects, buyer races and changed projections stay pending. Completed replay is historical with no current confirmation or link.
No automatic reverse write, recreation or cleanup occurs. Separately authorized restoration needs fresh preparation after resolving uncertainty and does not restore purchase history or prove every generated slot.
## Discount settings recovery
This task's resume is observation-only despite the generic tool's mutation-capable annotation.
Prepared work returns saved history; only identical original apply can dispatch after fresh revision/context checks. A sent task rereads the known selected offer twice and checks intended values, projected field/segment preservation and current context. It never repeats PATCH or activation POST, including after response loss, partial effects or receipt mismatch. A matching read may reconcile an unacknowledged save but cannot prove attribution. Wrong channel, changed operator/permissions or invalid journal stays blocked rather than adopting another identity.
Completed resume and identical completed apply return historical results with verification.confirmed:false and no current link/revision. Read [discounts_get](publ_discounts_get.md#prepare-an-existing-offer-edit) for current values. Preserve the original expectedRevision, requestId, family, target and action; dryRun on an existing task is a historical plan. There is no automatic rollback, and a fresh reverse operation cannot promise raw restoration of null/past expiry, empty descriptions, timestamps or visitor effects.
## Schedule policy recovery
For operation.kind:policies through [ticket_schedule_apply](ticket_schedule_apply.md#apply-schedule-policy-changes), retain taskType commerce-ticket-schedule-policies and the original taskId. MCP routes both existing public methods and recovery to this separate canonical policy store.
Shared resume is observation-only. Prepared work returns saved progress and requires identical original apply after fresh guards; the recovery transport also forbids business writes. Sent work rereads channel bulk status, exact event/source policies and every selected schedule, never repeating PATCH_EVENT_POLICY. Busy REQUESTED state, a newly observed selected-target failure, changed dependencies or partial application stay pending. Global DONE is not a correlated receipt and cannot replace exact stable readback. Keep the unchanged hall/event/selection/order/mode, expectedRevision and requestId.
Historical status/completed replay provides no current confirmed state or verified link. Old create/edit journals remain commerce-ticket-schedule and are not migrated. There is no automatic rollback; a reverse selection uses current source definitions and may not reconstruct the earlier policy snapshot or ticket/visitor effects.
## Original article conversion recovery
Resume rechecks exact saved channel/app/installation and authorization, then uses the original input. A saved conversion task has sent, created or verified phase; exact retry/resume only reads back and never repeats initialization POST or edit PUT. The generic untouched prepared-post continuation rule does not authorize replay of a conversion operation.
Initialization needs the durably saved receipt's string distinctId. A lost/malformed receipt or failed identity persistence keeps createdIdentityKnown:false even if a link now exists; no current-state/title inference or second initialization is permitted. With a stored identity, recovery checks the exact link and preserved article; editing checks the original link identity, desired full form and unselected fields. Unexplained article projection changes stay unresolved. ARTICLE_CONVERSION_OUTCOME_UNVERIFIED opens the parent article for inspection and does not claim a save; completed replay is historical, with no fresh verified destination.
The pending guard blocks new conversion writes and fresh ordinary post mutations for that article, while history reads and reconciliation remain available. It does not retrofit old ordinary-post journals or control external writers. No automatic rollback, initialization undo or thumbnail restoration is provided. Resolve uncertainty and obtain a fresh dedicated link revision before a later authorized edit.
## Discount creation recovery
Resume checks the saved channel, connection, operator, permission context and journal. Prepared resume never dispatches; the untouched prepared operation needs identical original apply after fresh checks. Sent resume and sent apply retries only observe the recorded authoritative receipt identity and never repeat creation POST.
DISCOUNT_CREATION_ID_UNKNOWN cannot be resolved by a matching code, title, inventory difference or caller-provided ID. Keep the original draft, expectedRevision and requestId; do not create another offer to bypass uncertainty. A saved receipt allows two fresh detail/inventory observations to reconcile only if the new record and preserved existing offers, plan and selected segment match. Receipt/readback mismatch, storage failure or context drift stays unconfirmed. Credential refresh is tolerated only after prepared while the remaining context matches.
Completed replay is historical, with verification.confirmed:false and no current configurationRevision/link; read the exact profile separately. A fresh confirmed recovery may open the exact created profile but proves no visitor benefit, coupon issuance, payment or actual cleanup. There is no automatic rollback, original-ID restoration or offer deletion endpoint.
## Original article address recovery
An untouched prepared ordinary-post task may continue with the original input after current checks; a sent retry or resume only reads and never repeats POST/PUT. Completed replay is historical. Changed credentials/context and a reused requestId with different input are rejected.
Creation requires a durably saved post identity and valid slug receipt matching a fresh read. No similar-title adoption or automatic recreation occurs. Custom edit readback accepts only the exact submitted segment or unambiguous source-compatible ID form and preserves non-slug metadata/body. keep/already-matching edits send no PUT and verify unchanged state. Unknown/mismatched outcomes retain the original task.
Ordinary-post journals do not globally block a manually supplied fresh requestId after an unresolved ordinary write; do not use that as a retry strategy. Reconcile first. Fresh slug actions share the existing conversion pending guard, without migrating all old journals or controlling external editors. No automatic rollback, blank reset or public URL inference is available. A later reverse edit requires fresh detail/revision and may not restore unusual or overlong original values.
## Multiple-date schedule recovery
Recovery uses the same canonical root store and unchanged flat draft/confirmation journal, separately from single-schedule and schedule-policy tasks. Current channel, installation, context and authorization must match; no journal migration or manual wrapping is allowed.
Shared task resume is observation-only even though an untouched prepared domain task can be continued through apply. Prepared resume returns stored progress with writesPerformedThisCall:false and sends nothing. The identical original apply may send once after fresh dependency/plan checks. They never repeat CREATE_LOOP or recreate a missing subset.
COMMERCE_CREATE_UNKNOWN cannot be repaired by title, list differences or adopting partial identities. Preserve the original draft/revision/requestId and obtain operator inspection. With complete receipts, every exact schedule is read twice, including each complete initial-parking sheet when selected, and all requested/preserved fields must match. A mismatch in any occurrence leaves the whole task pending; saveAcknowledged alone is insufficient. journalPersistence.saved:false retains storage uncertainty and grants no retry permission.
Completed replay is historical, with current confirmation false and no fresh console link. Fresh confirmed recovery may return the parent schedules list only; reselect event, hall, dates, publication and filters and inspect each exact scheduleId. No shared edit revision, atomic creation guarantee, automatic rollback or cleanup is supplied.
## Original article selection recovery 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):
Resume/exact apply retries use the original ordered IDs, operation, confirmation and revision under matching current context. They observe nonterminal rows and issue no mutation requests, even for prepared work or an unexecuted remainder. Readback may issue GET requests. Unresolved recovery reports readOnlyRecovery:true, writesPerformed:false and writeRequestsAttemptedThisCall:0. Completed replay is historical; status keeps lastResult without fresh target reads.
Completed/known-failed rows retain recorded observations/timestamps. Unexecuted rows stay unexecuted after observation, so reconciling attempted rows alone may leave the task partial. Read a fresh selection before explicitly confirming a later intended operation for known-failed, unexecuted or completed targets. Attempted uncertain targets block fresh writes with ARTICLE_SELECTION_PENDING, including new request IDs; missing guard journals fail closed. Existing conversion guards remain, without rewriting old journals or globally covering every workflow.
Only dedicated target absence verifies deletion. Authentication/installation failures, acknowledgement or list counts do not suffice. No replay, replacement creation, automatic rollback or restoration occurs. The parent list requires exact-ID reselection; stored navigation is not a current observation.
## Selected schedule metadata recovery
The existing tools, guarded transport, canonical task recovery and parent navigation are connected in source.
Use taskType:commerce-ticket-schedule-edit-many and the original taskId for [editMany](ticket_schedule_apply.md#edit-selected-schedule-metadata). Single edit retains commerce-ticket-schedule but shares the same durable target guard. Recover only under matching current context and the original immutable input/fingerprint. Shared task_resume returns historical status for a prepared journal without schedule reads or mutation requests. Only an identical original apply can continue unattempted work; if a durable claim already exists, that apply observes instead of sending. Sent recovery performs read requests without another mutation or subset PATCH. An empty HTTP 204 response does not acknowledge the save under the connected HTTP 200/data contract; recover the original uncertain task without replay.
Two stable observations must match requested and preserved values before matching task evidence is persisted and claims are released. A visible old value, ACK, fresh get/revision, new requestId, dry run or elapsed time cannot release protection. Status is read-only; original recovery can finish an interrupted guard release. Guard persistence/release failures keep confirmation false.
A claim saved before the sent marker may survive a crash or storage failure while the journal still looks prepared. That original task must observe only, not infer non-execution and send again. Old pending journals without a claim require inspection/settlement or explicit enrollment before new edits are enabled; there is no automatic pending-task inventory/migration.
Resolved rows retain observationScope:stored_resolution rather than rereading later changes on targets already released for other tasks. Unresolved observations are current_attempt. No-op rows were never sent or claimed but still need their recorded comparison; the original before snapshots remain immutable. Completion is non-atomic and can combine observations from multiple attempts. Shared currentStateVerified:false explicitly excludes a fresh snapshot of all targets. Pending and historical results receive no current result link.
The later publication continuation shares this guard with single/editMany in the same storage namespace. It does not cover different OAuth grants, policies, seats/parking/prices, availability and other lifecycle operations, external clients or manual console writes. Do not delete stale execution locks or guard records to bypass a failure. The hall/event parent list requires date/row/modal reselection; historical evidence is not a fresh console result.
## Original article assignee recovery
The existing tools and guarded transport are connected in source.
Use taskType:content-post and the original taskId for [article_assignee](content_post_apply.md#change-an-original-article-assignee). Resume and identical apply retry keep the original input, revision and fingerprint and require matching current context. Both observe existing tasks without another assignment POST, even when the task is prepared and never attempted. A changed input under the same ID fails with REQUEST_ID_REUSED.
Recovery reads the exact post and dedicated current assignees, checks any Post.assignees projection, and compares the selected role/identity/profileId plus preserved semantic post fields. It does not rediscover candidates to send a new assignment. Fresh successful observation may resolve an attempted uncertain save as ARTICLE_ASSIGNEE_SAVED with readOnlyRecovery:true and writesPerformed:false for this call. Matching state remains non-atomic and does not prove causality or notifications.
A prepared non-no-op without an attempted boundary remains ARTICLE_ASSIGNEE_NOT_SENT and is never dispatched by retry/resume. A known rejected/not-sent transport with fully unchanged readback can become terminal ARTICLE_ASSIGNEE_REJECTED. After either known boundary, later intended work requires fresh discovery, a new requestId and explicit confirmation; do not apply that rule to unknown attempted effects.
Unknown attempted outcomes retain ARTICLE_ASSIGNEE_OUTCOME_UNVERIFIED and block new assignment, ordinary post, selection and conversion mutations through ARTICLE_ASSIGNEE_PENDING. Missing journals behind pending markers fail closed. Existing selection/conversion recovery remains observational. Stored verified/rejected results are returned historically without a fresh read or current result link; inspect the dedicated getter separately.
A previous person can be selected again only after fresh eligibility is established. There is no clear/multiple assignment, restoration to a formerly unassigned state, notification cancellation or automatic rollback.
## Course comment recovery
Registration, guarded transport, task routing and exact navigation are connected in source.
For [media_course_comment_apply](media_course_comment_apply.md), supply taskType:media-course-comment and the original taskId. Resume delegates to this workflow's status: prepared tasks remain unsent, while sent and done tasks reread the selected parent and comments. It never issues create, DELETE, pin or unpin. Only identical currently valid apply may dispatch prepared work after the original revision/context checks. Sent identical apply retries also only observe.
Keep the original target, channel, actor, credentials and storage binding. An authoritative creation receipt is required; matching text or a list difference is not recovery. An empty204 deletion acknowledgement can initially leave uncertainty under HTTP200/data; a subsequent observation may verify absence of the original known target without another DELETE. Recheck currentStateMatches and the result code rather than relying on a saved done phase.
Legacy sent text accepted under the previous code-point limit is still observable without resending. The current3000 UTF-16-unit rule applies to new dispatch; definitely-unsent over-limit prepared input needs a revised intended request and fresh management revision. Do not use that exception to bypass a sent task with a new requestId. There is no promised cross-task target lock, automatic undo, deletion restoration or notification reversal.
Readback preserves the projected parent and unrelated projected comments, but does not prove atomicity, causality, delivery or learner visibility. Fresh matching results can link the exact original class/session screen; page/filter controls are manually reselected.
## Selected schedule publication recovery
The existing get/apply methods, transport, canonical task guard and publication-aware navigation are connected in source.
Use taskType:commerce-ticket-schedule-edit-many and the original taskId for [publication](ticket_schedule_apply.md#change-publication-for-selected-schedules). Shared resume returns historical status for prepared work without schedule reads or mutation dispatch. Only identical original apply may continue a genuinely unattempted stage; a durable claim beside a prepared-looking record makes that path observation-only. Sent recovery reads unresolved IDs without another STATUS or subset retry.
Stable requested/preserved observations must be saved durably before original claims are released. Previously resolved targets retain stored_resolution evidence; later work does not rewrite the old observation. A matching new no-op, subset/inverse request, refreshed credential or fresh revision cannot release or bypass another task's claim. Historical completed retries are not fresh admission or current verification.
After the original task resolves, restoration needs new explicit preparations grouped by the original per-target boolean; it is not a blanket inverse and cannot undo previous exposure/cache/bookings/notifications. Different grants/namespaces, manual console writes and other commerce functions remain outside protection. Pre-upgrade unregistered pending journals require rollout inspection/enrollment or settlement; guard absence alone is insufficient. Fresh completed navigation goes to the validated hall/event parent list with manual date/row/dropdown reselection, while historical/pending results have no current successful link.
## Original article notification recovery
This connects the existing settings methods and canonical recovery in source.
Use taskType:content-settings and the original taskId for [article_manager_comment_notifications](content_settings_apply.md#original-article-manager-comment-notification-preferences). Resume and identical apply only observe unfinished tasks, including prepared-but-unsent work. They never repeat PUT. A definitely unattempted non-no-op remains ARTICLE_NOTIFICATION_NOT_SENT; this option does not inherit generic prepared-post dispatch rules. Verified/rejected terminal replay is historical and does not remeasure current preferences.
Fresh complete observations must establish requested ACTIVE/email/app/PWA values and preserved unrelated fields. Partial changes, malformed reads and unknown outcomes remain unverified. A known transport rejection plus a fully unchanged record permits a fresh revision/new explicit operation; a response loss alone does not. Same-ID input changes are rejected. The pending marker follows connection/channel/event across reinstall while exact saved installation/credential/permission checks still guard recovery; stale context cannot disclose old preference values or gain a fresh navigation link. Ordinary settings tasks remain independent.
An accessible action_required result may link the exact B00001 /notice notification settings screen for inspection while snapshotHistorical:true and the completion disclaimer remain. Do not treat that link as successful save evidence. Restoration requires a fresh explicit ACTIVE change after uncertainty is resolved; enabling again cannot restore delivery flags cleared by OFF, and there is no rollback or notification recall.
## Cancellation-policy claim recovery
They correct admission to the existing cancellation-settings workflow without changing its inputs, transport or task type.
Retain commerce-ticket-refund-settings and the original taskId/input. Shared resume returns historical status for prepared work without fresh policy reads, enrollment or release. A known-unsent prepared task may continue through identical original apply after revalidation. If its own durable claim survived claim/marker persistence uncertainty, identical apply moves it to sent observation without dispatch. Sent apply/resume never repeats PATCH/POST and keeps rules/usage protection for the whole policy.
Stable requested/preserved readback must be recorded in a durable completed journal before original ownership is released. A completion-save failure stays pending/unconfirmed; a release failure can leave a stored done journal with a pending claim. Original completed apply/resume can finish only its own release, returning historical completion with no fresh verification or current link. Status, dryRun, unrelated historical replay and fresh matching/inverse requests cannot settle or release that claim.
Original recovery may enroll a pre-upgrade sent journal without changing its saved input/context/before/fingerprint/requestDigest. It is not an automatic scan or migration, and does not prove that other old journals are safe. The guard stays within its existing backend/grant namespace; a new grant is not a resolution. Malformed claims and changed context require inspection, not deletion, retries under another ID or automatic rollback.
## Promotion benefit pending recovery
Keep the original taskId/input and `taskType:"promotion-benefit"` for profile, activation, existing product discounts, eligible new connections and relationship disconnection. The [benefit-wide guard](promotion_benefit_apply.md#benefit-wide-pending-protection) protects the same environment/connection/channel/pcid/pbid within its backend/grant namespace, independent of action, row, credential version and request ID.
| Saved state | Recovery behavior |
| --- | --- |
| Prepared, without its own durable claim | Resume returns historical saved status and sends nothing. Only identical apply may revalidate the original snapshot/revision, claim and dispatch. |
| Prepared, with its own durable claim | Treat as an uncertain attempted operation; persist sent and observe without dispatch. Do not infer safety from the prepared label. |
| Sent, including lost receipt or partial/mismatching readback | Recheck the original context and exact requested/preserved snapshot; never repeat the HTTP effect. An explicitly recovered old sent task may enroll its claim. |
| Matching readback, completion persistence fails | Keep original pending ownership and continue observation; matching data alone is not durable completion. |
| Done, own claim release failed | The original apply/resume can observe again and finish durable completion/release. Fresh success remains withheld while release is unresolved. |
| Done, no own claim | Return historical completion without a fresh revision/link; never clear a later task's claim. |
A failed sent-marker write allows another dispatch only when prepared restoration and claim release both durably succeeded before transport began. Lost claim acknowledgement or failed rollback/release stays uncertain. New requests, matching no-ops and inverse values cannot bypass another pending owner. Dry runs/status do not resolve that ownership.
For product discounts, recovery remains bound to the original connected row and exact page/limit, parents and currency. A moved/changed page or out-of-range page is not silently replaced and cannot prove success. After resolution, use [promotions_get](publ_promotions_get.md#current-connected-product-selection) for a current productRevision; restoring an old value is a separate intentional edit with a fresh observation, not automatic rollback or proof that prior customer effects were undone.
Pre-upgrade unregistered sent tasks are not automatically inventoried/migrated. Different grants, task types, manual/external callers and actual PostgreSQL are outside this bounded protection.
Product-disconnect recovery keeps the original relationship ID and original plan's complete inventory. It requires complete stable absence and preservation of every remaining relationship, price and parent, within the 1000-row bound. A missing row on one page, lost receipt, changed totals/order or partial scan cannot resolve the task; sent POST never repeats.
If the original page no longer exists after the intended removal, reconciliation explicitly reads surviving page 1 at the original limit and checks its contents against the remaining inventory. Fresh completion returns that observed page, exact console link and an explanation, retaining requestedPage and the original targetProductId. This exception is specific to sent relationship-removal reconciliation; before dispatch an invalid page requires explicit reselection. Historical completion remains historical, and another task's claim is never released. See the [disconnect result contract](promotion_benefit_apply.md#result-and-surviving-page-navigation). Eligible new connections now have a separate bounded action, but restorationSupported:false must not be turned into an automatic restore instruction or a promise to recreate an old relationship ID.
Product-connect recovery retains the original selector page/limit/search, chosen targetIds, explicit values and durable complete-inventory plan. Sent POST never repeats, even when no authoritative receipt identity was returned. Reconciliation must observe exactly one new relationship per requested target/type/value and preserve every old row, price, relative order and parent. Partial results, repeated identities, changed selector observations or a failed preservation check stay pending; a fresh requestId or another action cannot bypass that benefit claim.
Fresh confirmed results contain the newly observed connectedRelationships and an exact first-products-page link with the later-row explanation. They do not provide a new write revision; read products or product-options again for another intentional operation. Known-unsent preparation and completion/claim-release failures follow the same table above. Product creation, automatic rollback, reusing old removed relationship IDs and proof of actual restoration are not provided. See [connection reconciliation](promotion_benefit_apply.md#connection-save-and-reconciliation).
## Additional promotion benefit creation recovery
For [promotion_benefit_create](promotion_benefit_create.md#receipt-independent-readback-and-recovery), keep the original taskId and `taskType:"promotion-benefit-create"` for ORDER_DISCOUNT or DISCOUNT. Status and resume never dispatch creation. Prepared work can continue only through the identical original create call after dependency/context/revision checks. Sent work is observation-only, including after an uncertain response or missing receipt. Do not substitute promotion-benefit, change requestId or adopt a title/count/list match.
DISCOUNT reconciliation requires the stored authoritative benefit id/pbid and every initial relationship ID, then two matching observations of parent, detail and the independent complete products page1/limit100. Receipt IDs, target/type/values, currency, selected source options and old campaign/benefit state must remain consistent. Missing/partial/contradictory evidence stays pending; a later matching list cannot replace a lost receipt. Same-operator refreshed credentials may observe sent work under unchanged authorization/context; prepared dispatch still uses its original credential binding.
Fresh verified completion opens the exact new benefit detail and returns benefitRevision. Completed replay is historical with no fresh successful link or revision; use promotions_get for current state. The workflow adds no campaign-wide reservation, automatic rollback, benefit deletion or automatic restoration.
