delegation-layer 0.1.30 → 0.1.37

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

@@ -4,7 +4,7 @@ Managed workspaces are an optional Delegate feature for tasks that need a
 retained Git worktree. Ordinary delegation, including ordinary work in a
 non-Git directory, is unchanged. Git is required only when a request creates
 or attaches to a managed workspace (`--isolation git-worktree` or
-`--workspace ID`).
+`--workspace ID`), or creates or removes a [Git checkpoint](#git-checkpoints).
 
 This reference is self-contained guidance for using managed workspaces.
 
@@ -48,7 +48,10 @@ delegate --root ROOT dispatch --isolation git-worktree --cwd ABS \
 `--base` resolves to a commit; the default is `HEAD`. Dirty and untracked
 source changes are observed but excluded from the managed checkout. The
 provider runs in the retained detached worktree, with the source-relative
-working subdirectory preserved. A request that attaches to an existing
+working subdirectory preserved. The source may itself be a managed checkout,
+such as a sibling in the same workspace container. After provisioning, the new
+workspace depends on the shared repository, not on the source checkout, so
+removing that source does not block capture, release, or forget. A request that attaches to an existing
 workspace uses its recorded checkout and source identity:
 
 ```text
@@ -117,6 +120,36 @@ facts. Normal capture covers the initial committed base through the captured
 tree, including worker commits and added untracked files that belong to the
 Git-content view. It uses a private temporary Git index and records an owned
 base pin plus tree/snapshot reference.
+
+Each provider turn also records its actual starting tree, `HEAD`, and index
+identity just before launch, so Lead edits made between turns belong to the
+next turn's start. The index identity covers every entry's mode, object, stage
+(including conflicts), path, assume-unchanged or skip-worktree flag, and
+intent-to-add (`git add -N`) state, but not stat caches or `HEAD`. A task capture's `candidate.turn` compares that start with the
+final capture: `content`, `head`, and `index` are `changed` or `unchanged`, and
+`baseline_ref` keeps the start tree. This is observed evidence, not
+enforcement: a read-only turn that commits or edits is reported, not rejected,
+and writes reverted before capture or ignored files are not observed.
+`status: "unavailable"` with `reason_code: "baseline_unavailable"` means no
+baseline exists, for example for a turn started before this evidence existed;
+treat it as unknown, never as unchanged. A capture without `candidate.turn`,
+such as one recorded before per-turn evidence existed or a release or exec
+recapture, is also unknown, never unchanged. A failed baseline refuses the
+provider launch for that task.
+
+An observed turn adds `turn-diff.patch` and `turn-name-status.z`, which diff
+that turn's start tree to the final tree with the same bounds as the
+cumulative artifacts. Use them to see which files the current turn touched;
+they exclude earlier turns and Lead edits made before its launch. Use the
+cumulative `diff.patch` and `name-status.z`, from the workspace base, to land
+or review the whole delegated result. Report a read-only turn whose `content`,
+`head`, or `index` is `changed` as a mutation, even when its turn file list is
+empty, and report an unavailable turn as unknown.
+
+`status` and `collect` for a task report that task's own capture, even after a
+later turn has used the workspace. The workspace `state` still reflects the
+resource now, so a sealed earlier capture does not make a busy, released, or
+forgotten workspace usable. `workspace status` reports the latest use.
 Optional binary patch and name-status artifacts are bounded to 8 MiB each; an
 overflow is omitted, never silently truncated. Verification diagnostics retain
 an 8 MiB prefix per stream, mark truncation explicitly, and continue draining
@@ -136,6 +169,98 @@ expired provider scope is never renewed or reused. If capture
 is unavailable after closure, the closure evidence can still preserve a valid
 continuation decision; it does not rewrite the provider outcome.
 
+## Git checkpoints
+
+A checkpoint records the current Git content of one checkout as a synthetic
+commit pinned by the owned ref `refs/delegate/ROOT_ID/checkpoints/CHECKPOINT_ID`.
+It does not move `HEAD`, create or switch a branch, or change the real index.
+The commit's tree is the full current Git-content view, built through a private
+index with the capture algorithm above, so the same exclusions apply. Its single
+parent is the `HEAD` the helper observed. Author, committer, and timestamp are
+fixed Delegate values; trailers carry the checkpoint ID and request digest.
+This is unrelated to a provider continuation `mode: "checkpoint"`.
+
+```text
+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` names exactly one target: `--cwd` for an absolute ordinary Git
+  checkout directory, or `--workspace` for a managed workspace ID. Nothing is
+  inferred from the current directory. Select a managed checkout only by
+  `--workspace ID`; never pass its path as `--cwd`.
+- `status` and `remove` take the checkpoint ID `C` from the create response.
+  `list` takes no target and runs no Git command.
+- Only `create --cwd` may initialize a new state root. Every other checkpoint
+  command needs the existing root and fails with exit `1` without creating it.
+  Use one state root for every command about the same checkpoint.
+- `--budget` is the finite helper budget (default 5m). It is persisted with the
+  operation and does not renew any provider task budget. `--watch` exists only
+  on `status`.
+
+A managed checkpoint is a workspace use. It needs the workspace's use owner and
+holds that workspace's usage reservation while its helper runs, so a concurrent
+turn or `workspace exec` on that workspace gets the normal busy response. It
+closes without content capture. Create it while the workspace is retained.
+
+Delegate does not restore, apply, merge, or land a checkpoint into any checkout.
+It does not control nested delegation budgets or lifetimes either. A fork from
+a checkpoint is an ordinary new managed dispatch with its own task budget.
+
+### Checkpoint before fork
+
+Use this sequence to start an isolated worker from current uncommitted work.
+Save every response and exit code once; follow
+[checkpoint results](result-handling.md#checkpoint-results) for each one.
+
+1. Run `checkpoint create` with one target. Exit `3` with `checkpoint.id` and
+   `next_action: "watch_checkpoint"` means the request was accepted. It does
+   not mean the content was captured. Save that exact ID as `C`.
+2. Run `checkpoint status C --watch 30s --json` until the exit is not `3`.
+   Never repeat `create` to observe it.
+3. Fork only when `status` exits `0` and `checkpoint.current.state` is
+   `checkpointed` and `checkpoint.current.usable` is `true`. A `commit_oid` or
+   `snapshot_ref` alone is not proof: an unavailable creation can still name a
+   retained candidate.
+4. Dispatch the worker with the qualified `checkpoint.current.commit_oid` as
+   the existing `--base` of a new managed workspace. Use an ordinary checkout of
+   the same repository as `--cwd`, normally the source the Lead already uses:
+
+   ```text
+   delegate --root ROOT dispatch --auto --brief ABS_BRIEF --cwd ABS_SOURCE \
+     --isolation git-worktree --base COMMIT_OID \
+     --permission workspace-write --budget 30m --json
+   ```
+
+5. Remove the checkpoint explicitly when the Lead no longer needs it.
+
+`status` exit `0` means a successful metadata observation, not an available
+checkpoint. `usable` is `true` only for a `checkpointed` creation with no
+registered removal attempt, including a failed one. It is derived from
+Delegate's records; it is not proof that an external Git command left the ref
+in place.
+
+If `checkpoint create --workspace ID` returns exit `3` with
+`reason_code: "requested_action_not_authorized"` and `retry_create`, no
+checkpoint was accepted and no ID was assigned. When that workspace is in use
+by the turn you are running in, do not wait for yourself, retry in a loop, or
+retry through `--cwd`. Finish and report; the Lead creates the checkpoint after
+your turn closes. When another use holds it, the Lead observes that workspace
+until it is retained again, then retries the same create once.
+
+Checkpoint refs outlive `workspace release` and `workspace forget`: the forget
+inventory covers only the workspace's own base, capture, and baseline refs.
+`checkpoint remove C` is the only command that removes a checkpoint ref.
+Removal needs only the shared Git common directory, so it works after the
+source checkout or managed checkout is gone. A missing or replaced common
+directory makes that removal attempt `unavailable`, never `removed`. Creation
+history stays observable after removal: `current.state` keeps the creation
+disposition, while `current.usable` becomes `false` and `current.removal`
+shows the latest attempt.
+
 ## Retention and forgetting
 
 A created managed checkout is retained for every outcome, including no-op and
@@ -146,9 +271,10 @@ identity check retains the checkout and evidence for retry. `--discard` accepts
 loss of uncaptured checkout content; it does not waive native closure,
 ownership, or identity proof.
 
-Release leaves the pinned refs/blobs and capture receipts as evidence. After a
-proven release, `workspace forget ID` writes an exact inventory intent before
-removing only matching owned refs and optional artifacts by identity/CAS. It
+Release leaves the pinned refs/blobs, turn-baseline refs, and capture receipts
+as evidence. After a proven release, `workspace forget ID` writes an exact
+inventory intent before removing only matching owned refs and optional
+artifacts by identity/CAS. It
 retains capture receipts, tombstones, all provider outcomes, raw evidence, and
 payload descriptors. Readers should label an intentionally forgotten item as
 `forgotten`, not as corruption.

package/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/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/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/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/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/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