Resume and Recover Work

An interrupted conversation is not a reason to start a new project. First identify the repository, branch or worktree, existing slug, artifact format and last known operation. Keep the files and failure output. A short excerpt can help diagnosis; redact credentials, private remote URLs, user-home paths and confidential code before sharing it publicly.

Re-enter the owning lane

Use the existing feature or sprint entry and name the original work. Explicit feature spellings are /ca:feature, $ca-feature and /ca-feature; sprint follows the same host-specific pattern. A useful instruction is: “Resume the existing saved-search export work. Inspect current state and report what is safe to continue. Do not recreate the artifacts or discard unrelated edits.”

The lane must inspect durable state rather than infer progress from the previous chat. For typed work, the coordinator uses validated reads and current bindings. Browser inspection is useful to you, but opening an HTML file does not reconcile or approve anything.

Read the state before choosing a remedy

Observed state	What it establishes	Next boundary
Observed state Draft spec or draft-preview plan	What it establishes Content exists, not execution authority	Next boundary Complete its review/readiness/approval path
Observed state PENDING task	What it establishes Work has not been accepted	Next boundary The engine must still establish eligibility and dependencies
Observed state IN_PROGRESS after interruption	What it establishes Work may have partly executed	Next boundary Inspect changes and reconcile before redispatch
Observed state REVIEW	What it establishes Review-stage work exists	Next boundary Fresh evidence and the owning scope’s acceptance requirements still apply
Observed state BLOCKED	What it establishes A recorded condition prevents selection	Next boundary Resolve the named condition; do not clear state merely to retry
Observed state ACCEPTED	What it establishes Acceptance was recorded	Next boundary Check that the associated evidence and bindings are still current

A sprint may continue independent safe work while a task is blocked. Existing bounded recovery can try a genuinely different strategy within approved scope, but it cannot invent user authority, repeat an exhausted strategy indefinitely, or promote a task by changing a status label. An ordinary feature’s attended checkpoints remain distinct from sprint authorization.

Match the diagnosis to the next action

Read the reason before retrying

These are explanations of task states and diagnostic codes, not live state from your repository.

AUTHORITY_UNVERIFIEDA required authority record is absent, stale or inspection-only after upgrade.

Next safe action: Use the applicable current host-owned approval or evidence boundary. Preserve old receipts; do not relabel them or manufacture a successful event. An unsupported host adapter remains a stop.

DRAFT_BINDINGA plan is still bound to a draft specification.

Next safe action: Return to the existing approval and plan-binding workflow. Do not edit a JSON flag to make the plan executable.

IN_PROGRESSAn interrupted task may have changed files without finishing its review.

Next safe action: Inspect those files and the recorded task state. Reconcile through the owning workflow before redispatch.

REVIEWImplementation is awaiting current review and evidence.

Next safe action: Collect the required fresh evidence and scope review. The label alone is not acceptance.

BLOCKEDA hard boundary or exhausted recovery strategy stopped this task.

Next safe action: Resolve its specific reason. Preserve the failed strategy and attempt record; continue only independent authorized work.

STALE_CURSORA contributing specification, plan or authority record changed after the read.

Next safe action: Read the current context again and reconsider the action. Never force the old cursor.

RECOVERY_REQUIREDA transaction needs inspection before its outcome is known.

Next safe action: Use the recorded operation ID and the recovery path. Do not replay the write with a new ID or remove its journal.

An accepted label also needs current bindings and evidence. Expanding these explanations never changes a task or grants permission.

Installation and capability

CAPABILITY_MISSING, INVALID_INSTALLATION, PACKAGE_INTEGRITY, UNVERIFIED_PLATFORM and UNSUPPORTED_PLATFORM are capability or package failures. Use doctor and the installed host’s capability report to identify the exact package and platform. Reinstall a qualified package only when that diagnosis calls for it. Do not fetch an arbitrary binary, use a project-supplied engine, or set a PATH/environment override to bypass the installation-owned manifest.

Approval and concurrent changes

DRAFT_BINDING and AUTHORITY_UNVERIFIED concern authority, not a broken installation. Return to the existing approval or evidence-capture boundary. Do not fabricate a receipt. The host authority matrix distinguishes an unavailable adapter from a missing current decision. Reinstalling the engine does not create a host adapter that is not implemented.

After an upgrade, receipt format 0.1.0 remains inspection-only in the current source contract. Further authority-bearing transitions require a fresh 0.2.0 attestation from the applicable policy-owned boundary. These are receipt formats, not plugin versions. Preserve the old evidence; do not relabel a receipt, replay a pasted decision as new authority, or infer approval from chat.

REVISION_CONFLICT or STALE_CURSOR means a read no longer describes the current definition or a contributing record. Reread, reconsider the intended change, and obtain fresh contextual reads. Never force the previous write through.

Uncertain writes

RECOVERY_REQUIRED or COMMIT_OUTCOME_UNKNOWN requires inspection of the recorded transaction using its operation ID. Preserve that ID and the original failure. Ask the owning workflow to inspect recovery status before retrying. Starting another write with a new operation ID can make an uncertain outcome worse. LOCK_BUSY is not permission to delete lock files.

For an interrupted host-owned reconciliation, let the adapter recover the exact stored operation and receipt. A lost mutation response can require replay of the same durable operation, not a new approval event. Cancellation must not clear an in-flight mutation. Verify the committed outcome and rerun eligibility before continuing; an observed prompt is not proof the mutation committed.

Unsupported formats

UNSUPPORTED_VERSION and UNSUPPORTED_RENDERER require a reviewed compatibility path. They do not authorize reinterpretation, raw JSON repair or replacement of an HTML pair with Markdown. Existing legacy Markdown pairs continue on their original path; explicit pair migration is a separate operation with drafts, retained legacy bytes and guarded rollback.

Verify the recovery

Ask for the original artifact IDs, format, current revision/binding, any reconciled changes, and the next eligible task or remaining stop. Confirm required tests and reviews refer to the actual current change. A successful retry alone does not prove earlier records were preserved.

If authority, capability or transaction outcome remains unknown, leave the work stopped and preserve the records. Restore lost governing files from known version-control or transaction history through the appropriate recovery path rather than reconstructing approval from chat. Do not manually edit HTML, receipts, protected task boards or append-only logs.

The format and troubleshooting guides cover the adjacent boundaries. The repository’s migration and recovery contract is the detailed current-source protocol, not proof that every installed release supports it.