delegation-layer 0.1.32 → 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.32",
+  "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.32",
+  "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.32",
+  "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

@@ -133,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`,
@@ -352,7 +357,9 @@ cancellation or `stop_and_report` applies, a `timed_out` task with
 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.
 
@@ -377,7 +384,9 @@ recruit more agents unless that is explicitly part of the task.
 - 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.
 
@@ -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

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;

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
@@ -91,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
@@ -124,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

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.
 
@@ -169,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

package/skills/agent-integration/SKILL.md

@@ -133,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`,
@@ -352,7 +357,9 @@ cancellation or `stop_and_report` applies, a `timed_out` task with
 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.
 
@@ -377,7 +384,9 @@ recruit more agents unless that is explicitly part of the task.
 - 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.
 
@@ -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

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;

package/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
@@ -91,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
@@ -124,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

package/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.
 
@@ -169,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