delegation-layer 0.1.30 → 0.1.37

package/README.md

@@ -301,6 +301,14 @@ reference](skills/agent-integration/references/workspaces.md) for attachment,
 continuation, verification, review scope, release, and forgetting. This
 feature does not automatically apply, commit, branch, or merge worker changes.
 
+To fork a worker from current uncommitted work, first record a Git checkpoint
+with `delegate checkpoint create --cwd ABS` (or `--workspace ID`). It stores a
+synthetic commit under a Delegate-owned ref without moving `HEAD` or touching
+the real index. After `checkpoint status` reports it `checkpointed` and
+`usable`, pass its commit to `dispatch --isolation git-worktree --base`.
+Checkpoints stay until `checkpoint remove`; see the [checkpoint
+guidance](skills/agent-integration/references/workspaces.md#git-checkpoints).
+
 ## Documentation
 
 - [Getting started](docs/getting-started.md) — install and run a first task.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "delegation-layer",
-  "version": "0.1.30",
+  "version": "0.1.37",
   "description": "Multi-provider AI agent delegation CLI and Agent Skill for running bounded coding tasks across provider CLIs.",
   "keywords": [
     "ai-agents",

package/plugins/delegation-layer/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "delegation-layer",
   "displayName": "Delegation Layer",
-  "version": "0.1.30",
+  "version": "0.1.37",
   "description": "Consult external AI harnesses and CCR-configured models for reviews, research, implementation, and debate through the resumable Delegate CLI.",
   "author": {
     "name": "Hesham Karam",

package/plugins/delegation-layer/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "delegation-layer",
-  "version": "0.1.30",
+  "version": "0.1.37",
   "description": "Consult external AI harnesses and CCR-configured models for reviews, research, implementation, and debate through the resumable Delegate CLI.",
   "author": {
     "name": "Hesham Karam",

package/plugins/delegation-layer/skills/agent-integration/SKILL.md

@@ -112,7 +112,13 @@ tasks may proceed; the failed attempt must remain reported as failed or blocked.
    output as an answer.
 7. If a task is timed out and its JSON says `continuation.resumable: true`, use
    `continue --task TASK_ID`, optionally with a new `--brief`. Do not create a
-   fresh unrelated dispatch to replace a resumable task.
+   fresh unrelated dispatch to replace a resumable task. The one other automatic
+   route is an `interrupted` task from `status` or `collect`, and only when
+   `failure.code` is `"task_interrupted"`, `failure.next_action` is
+   `"continue_task"`, and `continuation.resumable` is `true`; see
+   [interrupted turn](references/continuation.md#interrupted-turn). A
+   cancellation, `stop_and_report`, or failed admission always takes precedence
+   over `resumable: true`.
 8. Treat `blocked` authentication as unresolved. Do not call it compatible,
    successful, or failed provider behavior, and do not invent login commands.
 9. Never put credentials, tokens, or unrestricted provider output in a brief,
@@ -127,7 +133,12 @@ tasks may proceed; the failed attempt must remain reported as failed or blocked.
     or provider comparison. For independent parallel writes, choose
     `--isolation git-worktree` automatically unless the user explicitly chooses
     shared coordination; the model chooses fan-out and task scope. A read-only
-    review may attach a retained workspace with `--workspace ID`.
+    review may attach a retained workspace with `--workspace ID`. To fork a
+    worker from current uncommitted content, follow
+    [checkpoint before fork](references/workspaces.md#checkpoint-before-fork):
+    fork only from a `checkpointed`, `usable` checkpoint commit. If your own
+    turn holds the workspace, do not wait or retry through `--cwd`; report so
+    the Lead checkpoints after your turn closes.
 
 For an explicit Codex code review, use the discoverable `codex:review` profile
 with one persisted target: `--review-target uncommitted`,
@@ -321,8 +332,8 @@ delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" status TASK_ID --json
 delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect TASK_ID --watch 5s --json
 ```
 
-Check `status` first: if it is `timed_out`, follow step 6 even when publication
-is pending and no outcome is present. If `interaction.pending_requests` is
+Check `status` first: if it is `timed_out` or `interrupted`, follow step 6 even
+when publication is pending or unknown and no outcome is present. If `interaction.pending_requests` is
 nonempty and the interaction is not closed, answer the questions using
 [active-task interaction](references/interaction.md) before collecting again.
 Otherwise, if `collect` exits with code `3` because publication is still
@@ -336,14 +347,19 @@ is committed. A rejected outcome is terminal evidence and must be reported as
 rejected. Payload and raw output are returned as validated descriptors; do not
 copy unrestricted provider output into the control response.
 
-### 6. Continue a timed out turn
+### 6. Continue a timed out or interrupted turn
 
-When `status` or `collect` reports `timed_out`, read
-[continuation and timeout recovery](references/continuation.md). If
-`continuation.resumable` is true, use `continue --task TASK_ID` with the original
-state root and a finite budget, then observe the returned successor ID. Do not
+When `status` or `collect` reports `timed_out` or `interrupted`, read
+[continuation and timeout recovery](references/continuation.md). Unless a
+cancellation or `stop_and_report` applies, a `timed_out` task with
+`continuation.resumable: true` may use `continue --task TASK_ID`. An
+`interrupted` task may use it only under all three conditions in rule 7;
+otherwise report it. When continuing, use the original state root and a finite
+budget, then observe the returned successor ID. Do not
 wait indefinitely for pending publication or restart the task as an unrelated
-dispatch. If continuation is unavailable, report its reason. Apply the same
+dispatch. If continuation is unavailable, report its reason, except the busy
+managed-workspace case in [continuation and timeout
+recovery](references/continuation.md). Apply the same
 `failure` and `task_record` decisions as for dispatch; never repeat an uncertain
 successor creation.
 
@@ -365,10 +381,12 @@ recruit more agents unless that is explicitly part of the task.
   model/effort options or another public command.
 - Read [result handling](references/result-handling.md) when interpreting
   admission, publication, authentication, errors, or exit codes.
-- Read [continuation](references/continuation.md) for timeout recovery or an
-  exact-session follow-up.
+- Read [continuation](references/continuation.md) for timeout or interruption
+  recovery or an exact-session follow-up.
 - Read [managed workspaces](references/workspaces.md) for optional Git
-  worktrees, capture, review scope, release, and forgetting.
+  worktrees, capture, review scope, release, and forgetting, and
+  [Git checkpoints](references/workspaces.md#git-checkpoints) before creating,
+  observing, forking from, or removing a checkpoint.
 - Use [read-only example](examples/read-only-task.md),
   [write example](examples/workspace-write-task.md),
   [JSON examples](examples/json-results.md), and

package/plugins/delegation-layer/skills/agent-integration/examples/json-results.md

@@ -11,3 +11,45 @@ own the decision order for task creation, failures, timeout continuation,
 terminal outcomes, pending interaction, and bounded collection. Read them
 before interpreting these commands; pending publication alone is not a reason
 to wait when the task needs an answer or timeout recovery.
+
+## Checkpoint responses
+
+These abbreviated shapes use the delivered field names; `…` marks omitted
+values. Apply [checkpoint results](../references/result-handling.md#checkpoint-results)
+to the whole response and its exit code.
+
+Accepted creation, exit `3`:
+
+```json
+{"schema_version":1,"command":"checkpoint","root_id":"…","admission":"unknown","liveness":"undetermined","publication":"unknown",
+ "checkpoint":{"id":"CHECKPOINT_ID","next_action":"watch_checkpoint"}}
+```
+
+Busy refusal, exit `3`, with no accepted ID:
+
+```json
+{"checkpoint":{"reason_code":"requested_action_not_authorized","next_action":"retry_create"}}
+```
+
+Qualified checkpoint from `status`, exit `0`; only this state may be forked:
+
+```json
+{"checkpoint":{"id":"CHECKPOINT_ID","current":{"id":"CHECKPOINT_ID","selection":"ordinary","cwd":"/abs/source",
+ "state":"checkpointed","snapshot_ref":"refs/delegate/ROOT_ID/checkpoints/CHECKPOINT_ID","commit_oid":"…","usable":true}}}
+```
+
+Exact removal attempt from `status CHECKPOINT_ID --operation OPERATION_ID`,
+exit `0`. Creation history stays `checkpointed`, but `usable` is now `false`:
+
+```json
+{"checkpoint":{"id":"CHECKPOINT_ID","operation_id":"OPERATION_ID",
+ "current":{"id":"CHECKPOINT_ID","selection":"ordinary","state":"checkpointed","usable":false,
+  "removal":{"operation_id":"OPERATION_ID","attempts":1,"state":"removed"}},
+ "operation":{"operation_id":"OPERATION_ID","attempts":1,"state":"removed"}}}
+```
+
+An empty `list` page, exit `0`, still has the array:
+
+```json
+{"schema_version":1,"command":"checkpoint","root_id":"…","admission":"unknown","liveness":"undetermined","publication":"unknown","checkpoints":[]}
+```

package/plugins/delegation-layer/skills/agent-integration/examples/managed-workspace.md

@@ -66,3 +66,64 @@ Save each response and exit code once. A created task is observed with
 success; continue observing the same task. The Lead reviews the capture and
 owns landing any changes. `workspace release` is explicit; no automatic
 apply, commit, branch merge, TTL eviction, or provider-CLI fallback occurs.
+
+## Fork from a checkpoint
+
+Use this sequence when the worker must start from current uncommitted content
+instead of a committed base. Run it from the Lead, not from inside a worker
+that uses the same workspace. The [checkpoint guidance](../references/workspaces.md#checkpoint-before-fork)
+owns the rules; [checkpoint results](../references/result-handling.md#checkpoint-results)
+owns every response decision.
+
+```sh
+SOURCE="$PWD"
+RESPONSE="$(mktemp)"
+if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint create \
+  --cwd "$SOURCE" --budget 5m --json >"$RESPONSE.checkpoint"; then
+  checkpoint_exit=0
+else
+  checkpoint_exit=$?
+fi
+printf '%s\n' "$checkpoint_exit" >"$RESPONSE.checkpoint.exit"
+cat "$RESPONSE.checkpoint"
+```
+
+Exit `3` with `checkpoint.id` and `next_action: "watch_checkpoint"` means the
+request was accepted, not captured. Use that `checkpoint.id` as
+`CHECKPOINT_ID`. Do not run `create` again.
+
+```sh
+if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint status CHECKPOINT_ID \
+  --watch 30s --json >"$RESPONSE.checkpoint.status"; then
+  checkpoint_status_exit=0
+else
+  checkpoint_status_exit=$?
+fi
+printf '%s\n' "$checkpoint_status_exit" >"$RESPONSE.checkpoint.status.exit"
+cat "$RESPONSE.checkpoint.status"
+```
+
+Repeat that status command while it exits `3`. Fork only when it exits `0`,
+`checkpoint.current.state` is `checkpointed`, and `checkpoint.current.usable`
+is `true`. Use `checkpoint.current.commit_oid` as `COMMIT_OID` in the first
+dispatch example, replacing `--base HEAD` with `--base COMMIT_OID`. Report a
+`stop_and_report` result instead of forking.
+
+When the Lead no longer needs the checkpoint, remove it explicitly:
+
+```sh
+if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint remove CHECKPOINT_ID \
+  --budget 5m --json >"$RESPONSE.checkpoint.remove"; then
+  checkpoint_remove_exit=0
+else
+  checkpoint_remove_exit=$?
+fi
+printf '%s\n' "$checkpoint_remove_exit" >"$RESPONSE.checkpoint.remove.exit"
+cat "$RESPONSE.checkpoint.remove"
+```
+
+Exit `3` with `checkpoint.operation_id` and `watch_checkpoint` means removal
+attempt `OPERATION_ID` was accepted. Observe that exact attempt with
+`checkpoint status CHECKPOINT_ID --operation OPERATION_ID --watch 30s --json`,
+saving its response and exit the same way. A `retry_remove` response has no
+`operation_id` and accepted nothing.

package/plugins/delegation-layer/skills/agent-integration/references/collaboration.md

@@ -8,6 +8,22 @@ cap or TTL eviction. A read-only review may attach a retained workspace with
 release rules live in [managed workspace guidance](workspaces.md); do not
 restate them in each collaboration brief.
 
+Give each participant a bounded deliverable, explicit write ownership, and the
+inputs it depends on. Run independent assignments in parallel; dependent work
+begins only after the required results are collected and any prerequisite
+changes are applied and verified in the consuming worker's workspace, without
+requiring a merge. Combine the relevant completed results in the verification
+workspace before running checks that depend on their interaction. A worker's
+terminal outcome establishes that assignment's result, not completion of the
+user's full objective; keep remaining integration, verification and unresolved
+work explicit.
+
+When a participant must start from the Lead's current uncommitted work, the
+Lead checkpoints that content first and forks each worker from the qualified
+checkpoint commit with `--base`. Follow
+[checkpoint before fork](workspaces.md#checkpoint-before-fork); a worker never
+checkpoints a workspace its own turn is using.
+
 ## Keep each request identifiable
 
 Choose the fan-out needed for the user's task. Each participant needs its own

package/plugins/delegation-layer/skills/agent-integration/references/command-reference.md

@@ -6,7 +6,8 @@ All paths passed to `--root`, `--cwd`, and `--brief` must be absolute. Add
 Pass the intended workspace directly. Delegate handles provider launch options;
 do not initialize Git, change trust settings, or call a provider CLI as a
 workspace workaround. Ordinary tasks support non-Git directories. Git is
-required for managed worktree creation/attachment only; native review retains
+required for managed worktree creation/attachment and checkpoint creation or
+removal only; native review retains
 its separate explicit review-target contract. See [managed workspace guidance](workspaces.md)
 for the policy owner.
 
@@ -52,8 +53,8 @@ Dispatch flags:
 - `--model MODEL` and `--effort VALUE`: provider-advertised choices (CCR requires a model alias);
   Codex maps effort to TOML `model_reasoning_effort` for ordinary turns or a native
   turn parameter for interactive turns, while Claude and AGY
-  pass native effort flags; Pi maps effort to `--thinking`; OpenCode maps it to
-  `--variant`; CCR forwards effort to Claude and uses `--model` as a CCR alias; `default` is omitted;
+  pass native effort flags; Pi maps effort to `--thinking`; OpenCode sends model
+  and effort as acknowledged ACP session options; CCR forwards effort to Claude and uses `--model` as a CCR alias; `default` is omitted;
 - `--interactive`: enable advertised native clarification and steering; see [interaction](interaction.md);
 - `--native-timeout DURATION`: optional provider-native timeout where advertised.
 
@@ -101,6 +102,27 @@ Continuation flags:
 - `--budget DURATION`, `--model MODEL`, and `--effort VALUE`: optional overrides;
 - `--interactive`: enable interaction when supported; already-interactive predecessors keep it.
 
+## Checkpoint commands
+
+Git checkpoints are optional and launch no provider work. Use them to fork a
+worker from current uncommitted content; the canonical
+[checkpoint guidance](workspaces.md#git-checkpoints) owns targets, limits, and
+the checkpoint-before-fork sequence, and
+[checkpoint results](result-handling.md#checkpoint-results) owns the decisions.
+
+```sh
+delegate --root ROOT checkpoint create --cwd ABS [--budget DURATION] --json
+delegate --root ROOT checkpoint create --workspace ID [--budget DURATION] --json
+delegate --root ROOT checkpoint status CHECKPOINT_ID [--operation OP] [--watch DURATION] --json
+delegate --root ROOT checkpoint list [--after CHECKPOINT_ID] [--limit 1..50] --json
+delegate --root ROOT checkpoint remove CHECKPOINT_ID [--budget DURATION] --json
+```
+
+`create` takes exactly one of `--cwd` or `--workspace`. `--operation` selects a
+removal attempt ID returned by `remove`; without it, `status` observes the
+creation and its latest removal. `list` pages with the returned
+`checkpoint_cursor` as `--after`.
+
 ## Choosing models and effort
 
 Pass an explicitly supplied model ID and effort unchanged, even if discovery
@@ -135,7 +157,9 @@ enumeration, not effort metadata. `null` means effort metadata is unknown;
 `[]` means the provider explicitly reported no choices. Discovery exits `0`
 for `available` or `partial`, `2` for `blocked` or `unavailable`, and `1` for
 `failed`. Preserve a blocked or unavailable discovery result as unresolved;
-defaults remain allowed.
+defaults remain allowed. An operational discovery failure also includes an
+optional `failure` object and a fixed `error` message; keep both fields and
+follow `failure.next_action`.
 
 ## Checking readiness
 

package/plugins/delegation-layer/skills/agent-integration/references/continuation.md

@@ -53,6 +53,42 @@ Then retry the exact `continue --task PREDECESSOR_ID` after it becomes retained.
 Keep the original predecessor, brief, and budget; do not replace continuation
 with a fresh dispatch. A created successor is only observed.
 
+**Busy managed workspace after a timeout.** This is the only case where an
+unavailable continuation may be waited for instead of reported. It applies
+only when a `timed_out` task reports all of `continuation.resumable: false`,
+`continuation.reason` exactly `"managed workspace is busy"`,
+`workspace.state: "busy"`, and `workspace.next_action: "watch_workspace"`.
+Another reservation may still hold the workspace; do not infer which use. Wait
+only when further work needs to continue this task, and return a committed
+result normally. Do not wait when a cancellation (`failure.code:
+"task_cancelled"`), a concrete fault, or `stop_and_report` applies to the task
+or the workspace. If a successor from this predecessor was already created,
+observe that successor instead; if its creation is uncertain, follow the
+`task_record` stop rule in [result handling](result-handling.md).
+
+1. Watch the workspace with the same root and a finite duration, using
+   `workspace.id` from the task response; never guess an ID or path:
+
+   ```sh
+   delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" workspace status \
+     WORKSPACE_ID --watch 30s --json
+   ```
+
+   Repeat the watch only while it reports `state: "busy"`.
+2. When it reports `state: "retained"`, run a fresh `status` for the same
+   predecessor task ID.
+3. Only if that status now reports `continuation.resumable: true` and the task
+   rules above still permit it, run the exact `continue --task PREDECESSOR_ID`
+   once. Otherwise report its reason and stop.
+
+Never run `continue` while `resumable` is `false`. Report any other reason,
+workspace state, or fault under the existing guidance; do not reactivate a
+`released` or `forgotten` workspace. An `undetermined` workspace view is
+unobserved and follows [managed workspace results](result-handling.md#managed-workspace-results);
+it is neither a terminal failure nor permission to continue. Do not dispatch,
+fall back to another provider, repair the environment, or mutate the workspace
+to free it. Availability is not guaranteed; do not wait indefinitely.
+
 `mode` describes the provider contract:
 
 - `native` uses the provider’s exact persisted conversation/session ID;
@@ -61,11 +97,14 @@ with a fresh dispatch. A created successor is only observed.
 - `unsupported` cannot be continued safely.
 
 Do not use a guessed session ID, a provider-specific resume command, or a new
-independent dispatch to recover a timeout. The CLI accepts either a validated
-terminal outcome or a durable Pueue-ended observation backed by a guardian
-lifetime-termination record with independently proven empty scope for the
-session handoff; without one of those proofs it refuses continuation. Inspect
-the predecessor again rather than bypassing that boundary.
+independent dispatch to recover a timeout. The CLI accepts a validated
+terminal outcome, a durable Pueue-ended budget stop backed by a guardian
+lifetime-termination record with independently proven empty scope, or canonical
+closed lifetime evidence of any closure kind together with a free runner lease
+for a turn with no seal or outcome. A sealed predecessor must be collected
+first. A queue-row end or a timestamp alone never qualifies; without one of those
+proofs it refuses continuation. Inspect the predecessor again rather than
+bypassing that boundary.
 
 For a managed workspace timeout, capture is a new finite auxiliary operation
 after canonical closure. The normal path proves the provider scope empty and
@@ -76,6 +115,56 @@ unavailable capture can still preserve continuation evidence; it does not
 change the provider outcome.
 
 
+## Interrupted turn
+
+A host restart can end a provider turn before it publishes anything. Delegate
+reports an interruption only when the task's stored publication state is still
+unknown, with no provider exit or outcome, its canonical lifetime closure is
+proven, and its runner lease is released. A terminated budget stop is checked
+first and reports `timed_out` instead, as does a closure whose recorded
+termination cause is the budget. Closure proves only that the provider
+scope is gone; it is not provider success, and no answer or output from that
+turn is accepted. Do not check these facts yourself or infer eligibility from
+missing files: obey the returned `status`, `failure`, `continuation`, and
+`pending` fields. For an eligible task, after real outcomes and concrete errors
+are checked, `status` and `collect` report `status: "interrupted"` with
+`publication: "unknown"`, no `outcome`, and
+`failure.code: "task_interrupted"`. `status` exits `0`; `collect` exits `1`.
+An interruption may also carry `pending.kind: "supervisor-command"`; that
+independent observation means only that a supervisor command has not
+finished, so follow the interruption's `failure` and `continuation` as usual.
+Do not infer an interruption from `publication: "unknown"` alone: a response
+with `pending.kind: "publication"` is still pending publication and carries no
+interrupted resume offer, so handle it as pending under
+[result handling](result-handling.md). Outcomes, `timed_out`, interaction,
+`lifetime-finalization`, and ordinary pending exit `3` keep their meaning.
+
+| Response | Action |
+|---|---|
+| `failure.code: "task_interrupted"`, `failure.next_action: "continue_task"`, and `continuation.resumable: true` (all three) | Run the `continue` above for that predecessor with the original root and a finite budget, then observe the successor. |
+| `interrupted` with any other combination, including `failure.next_action: "stop_and_report"` or `continuation.resumable: false` | Report the reason and stop. |
+| `timed_out` with `failure.code: "task_cancelled"` (user stop and budget stop, no outcome) | `stop_and_report`; `continuation.resumable` is `false` and no `continue_command` is returned. Report it. `collect` exit `3` here is a finite watch, not success and not a reason to keep waiting. |
+| Any other operational error | It is not an interruption; apply [result handling](result-handling.md). |
+
+`continuation.resumable: true` alone never revives an attempt that returned
+`stop_and_report`, and a failed admission keeps its `task_record` rules.
+Never continue a cancelled task automatically or start a fresh provider
+fallback. A user stop keeps `interrupted` / `task_interrupted` for a closed
+interrupted task, now with `stop_and_report` and `resumable: false`. A
+committed or rejected outcome stays authoritative and is never replaced by
+`task_cancelled`. A later, explicit user request to `continue` is a separate
+action and still validated against real closure and the recorded session.
+
+The successor uses the predecessor's observed provider session from
+`provider.ref`. Only when `provider.ref` is genuinely absent, for any eligible
+predecessor and not only an interrupted one, does `continue` fall back to the
+validated immutable session that turn was asked to resume. The response reports
+the source in `continuation.session_source`: `observed` means `provider.ref`
+supplied the identity, and `recorded_input` means the requested session supplied
+it. Neither value is evidence the provider saved any message or resumed
+successfully. A missing task reference, or an unreadable, malformed, or mismatched
+record, refuses. Never search ancestors or rerun the original task.
+
 ## Follow up after normal completion
 
 A validated terminal outcome, committed or rejected, can also support a new

package/plugins/delegation-layer/skills/agent-integration/references/result-handling.md

@@ -3,7 +3,11 @@
 Use the response fields independently. A successful control command is not
 the same as a successful provider result.
 
-1. Save `task_id` immediately after dispatch or continue.
+1. Save `task_id` immediately after dispatch or continue. It is the durable
+   Delegate identity. `supervisor.numeric_task_id` and a stop's
+   `numeric_task_id` are private, ephemeral queue addresses. The queue can
+   reuse a number for a later task, so a repeated number is not a binding
+   error; never use it as a task handle.
 2. For a dispatch or continue error, inspect `task_record` first. When it is
    `created`, observe the returned ID with `status`. Before applying the generic
    `not_created` stop rule, handle the sole migration exception: when
@@ -24,7 +28,13 @@ the same as a successful provider result.
    evidence for an existing task.
 3. If `status` is `timed_out`, follow the continuation procedure before treating
    pending publication as a reason to wait. `continuation.resumable: true`
-   permits a linked successor even when no outcome has been published.
+   permits a linked successor even when no outcome has been published. An
+   `interrupted` task (`failure.code: "task_interrupted"`) follows the table in
+   [interrupted turn](continuation.md#interrupted-turn): continue only when
+   `failure.next_action` is `continue_task` and `continuation.resumable` is
+   `true`, otherwise report it. A `timed_out` task whose `failure.code` is
+   `task_cancelled` is `stop_and_report`: report it and stop, even though
+   `collect` exits `3`; that exit is not success.
 4. If `publication` is committed and `outcome.verdict` is committed, return
    the result and its payload/evidence descriptors.
 5. If `outcome.verdict` is rejected and `failure.next_action` is `recheck`,
@@ -51,7 +61,13 @@ from an inspection-worker or supervisor-observation failure.
 For `delegate models`, validate the complete JSON envelope before using any
 fact. Treat `available` and `partial` with exit `0` as observations, preserve
 `blocked` and `unavailable` with exit `2` as unresolved prerequisites, and
-preserve `failed` with exit `1` as a discovery failure. `complete` refers to
+preserve `failed` as a discovery failure. Exit `1` with `failed` is an
+operational failure; exit `2` with `failed` is an invalid or unsupported
+request, not an authentication block. Status and exit are separate
+observations. When the response
+includes the optional `failure` object and `error` message, keep both in the
+report and follow `failure.next_action`; report and stop on
+`stop_and_report`. `complete` refers to
 model enumeration. Keep `efforts: null` distinct from `efforts: []`, and do not
 apply harness-wide effort choices to every model. Discovery is advisory and
 never an admission allowlist; a provider default remains valid and a listed
@@ -79,6 +95,18 @@ The provider outcome is immutable and the workspace `CaptureReceipt` is a
 separate immutable fact; a failed or unavailable capture must not be reported
 as a provider failure when native closure is already proven.
 
+In task `status` or `collect`, a workspace with `state: "undetermined"`,
+`evidence_state: "unknown"`, and `next_action: "watch_workspace"` means that
+observer's bounded view expired before it read the workspace. It is an
+unobserved view only. It does not imply corruption, change the task fields, or
+revoke an eligible continuation, and it does not turn a committed task into a
+failure. Follow the task fields above: return a committed result, handle a
+rejection using its reported guidance, and keep observing only while the task
+fields are pending. When useful, watch the same workspace with the same root.
+Do not dispatch again, retry the provider, fall back to another integration,
+or repair the environment because of it. A workspace view with `stop_and_report` remains a
+concrete failure to report.
+
 Before a task record exists, a pending workspace provision returns
 `task_record: "not_created"` with
 `failure.code: "workspace_provision_pending"` and
@@ -112,6 +140,42 @@ Lead has terminal task/capture evidence and explicitly releases it. Read
 [managed workspace guidance](workspaces.md) for the exact command surface and
 review/capture/forgetting boundaries.
 
+## Checkpoint results
+
+A `checkpoint` response has `command: "checkpoint"` and no `task_id` or
+`outcome`. A checkpoint receipt is Git-content evidence; it never replaces a
+provider outcome, and a provider outcome never proves a checkpoint. Read
+`checkpoint.id`, `checkpoint.operation_id`, `checkpoint.current`,
+`checkpoint.operation`, `checkpoint.reason_code`, `checkpoint.next_action`, and
+`error` separately, together with the exit code. Exit `0` alone is not enough.
+
+| Command and response | Meaning and next action |
+| --- | --- |
+| `create`: exit `3`, `id` C, `next_action: "watch_checkpoint"` | Accepted, not yet captured. Watch `status C`; never repeat `create`. |
+| `create`: exit `3`, `requested_action_not_authorized`, `retry_create`, no `id` | Busy refusal; nothing was accepted. Apply the [busy rule](workspaces.md#checkpoint-before-fork). Never wait for your own turn or switch to `--cwd`. |
+| `remove C`: exit `3`, `id` C, `operation_id` R, `watch_checkpoint` | Removal attempt R is accepted. Watch `status C --operation R`; never repeat `remove` to observe it. |
+| `remove C`: exit `3`, `requested_action_not_authorized`, `retry_remove`, no `operation_id` | Not accepted, usually because creation is still pending. The `id` in your command is not a removal ID. Watch `status C` until it settles, then retry `remove C` once. |
+| `remove C`: exit `0` with `operation_id` R | R already succeeded. No new attempt was registered. |
+| `status C`: exit `0` | Successful observation. Fork only when `current.state` is `checkpointed` and `current.usable` is `true`. With `next_action: "stop_and_report"`, report the unavailable creation or latest removal; do not fork. |
+| `status C`: exit `3`, `watch_checkpoint` | Creation or latest removal is still pending. Keep watching the same C. |
+| `status C --operation R`: exit `0`, `1`, or `3` | R's own result: `removed` or `nothing_to_remove` is `0`; `unavailable` is `1` with `stop_and_report`; pending is `3`. A newer attempt in `current.removal` never replaces R's outcome. Keep watching R, not the newer head. |
+| `list`: exit `0` | One metadata page. Entries may be pending, unavailable, or removed. Run `status C` for a reconciled verdict. |
+| Exit `1` with `stop_and_report` | Concrete failure. Report `error` and every ID already returned; do not repeat the mutation. |
+| Exit `2` | Invalid request. Parse errors print usage on stderr without guaranteed JSON; correct the request. |
+
+Take `C` only from `checkpoint.id` and `R` only from `checkpoint.operation_id`
+of a response that returned them. Never invent an operation ID or reuse a
+creation ID as `--operation`. Returned IDs stay valid after a later read
+fault; an unreadable `current` or `operation` is omitted rather than shown as
+empty availability.
+
+`status --watch` repeats the same observation of the same IDs until a settled
+or failed result or the bound ends. It never begins another action, renews a
+helper deadline, or cancels accepted work. The latest observation chooses the
+exit. A watch that ends at exit `3` means keep observing; it is not a failure.
+If writing the response itself fails (exit `1`), accepted work stays accepted;
+observe it with `status` instead of repeating the mutation.
+
 ## Offline recovery
 
 When Delegate returns `failure.next_action: "recheck"`, use the same root and