delegation-layer 0.2.0 → 0.3.1

package/skills/agent-integration/references/result-handling.md

@@ -2,6 +2,9 @@
 
 Read response fields independently. A successful control command is not a
 successful provider result.
+Examples use the CLI default under the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief); preserve an
+explicit custom or recorded historical root on related commands.
 
 ## Task control response
 
@@ -49,7 +52,7 @@ this table to each dispatch or continuation attempt separately, in order:
 | Response | Next action |
 |---|---|
 | Usage error, no JSON response | Correct the reported syntax using Delegate help or `providers --json`, then invoke that request again. Parsing failed before admission. |
-| `task_record: not_created`, `failure.code: supervisor_upgrade_required`, and `failure.next_action: run_supervisor_migrate` | Run `delegate --root "<the exact absolute state root used by the failed command>" supervisor migrate --json` once. Retry the exact original admission argv once only after `supervisor_control.state: migrated` and `supervisor_control.next_action: retry_dispatch`; otherwise stop and report the migration response. Preserve an explicit custom root exactly. A failed `continue` must be retried as the same `continue`; never replace it with a fresh `dispatch` or a direct provider call. |
+| `task_record: not_created`, `failure.code: supervisor_upgrade_required`, and `failure.next_action: run_supervisor_migrate` | Run `delegate supervisor migrate --json` once in the same user/configuration context for ordinary default-root work. If the failed command used an explicit custom or recorded historical root, run `delegate --root "<the exact absolute root used by the failed command>" supervisor migrate --json` instead. Retry the exact original admission argv once only after `supervisor_control.state: migrated` and `supervisor_control.next_action: retry_dispatch`; otherwise stop and report the migration response. A failed `continue` must be retried as the same `continue`; never replace it with a fresh `dispatch` or a direct provider call. |
 | `task_record: not_created` and `failure.next_action: correct_request` | Correct that request and retry it. |
 | `task_record: not_created`, `failure.code: workspace_provision_pending` or `workspace_busy`, and `failure.next_action: watch_workspace` | Follow [managed workspace recovery](#managed-workspace-results) using the same root and workspace. Once ready, retry the exact admission command and inputs. A failed `continue` remains that same `continue`, never a new dispatch. |
 | `task_record: not_created`, `failure.code: resource_pressure`, `failure.next_action: retry_later`, and `failure.retry_after_seconds: 30` | Delegate checked the host and confirmed resource pressure, so no ordinary task record was created and no provider task is running for this attempt. Do not poll or observe a task. Choose one: report the refusal and stop, or wait at least 30 seconds in the foreground and retry the exact original admission argv once. A `continue` stays that same `continue`. If the retry is refused again, report and stop. Never loop, retry in the background, schedule a retry, or run Pueue or process commands. The 30 seconds is advice, not a guarantee that the retry will pass. |
@@ -166,6 +169,66 @@ asking again, but never infer it from a rejection or silently substitute a
 destination. Keep the original failed attempt reported as failed; independent
 requests and explicitly allowed recovery paths retain their existing rules.
 
+## Schedule definition and host results
+
+Use the installed build's help to check `scheduler serve/status/stop` support.
+Keep three facts separate: the definition was
+saved, the host is ready, and an occurrence produced an accepted provider result.
+Neither saving nor host readiness proves that a task ran.
+
+Schedule create/resume report confirmed persistence as `schedule.saved: true`;
+keep `schedule.id` even if the command exits nonzero. The separate top-level
+`scheduler` object carries host observation and guidance:
+
+| JSON field | Meaning |
+| --- | --- |
+| `scheduler.state` | Observed lifecycle or availability state, including `foreground` for a current raw `scheduler run`. Read it with `ready` and the process exit. |
+| `scheduler.epoch`, `scheduler.attempt` | Owner generation string and numeric child attempt, when known. Omission does not identify an owner. |
+| `scheduler.ready` | Whether this observation confirms host/child readiness; it is not an occurrence result. |
+| `scheduler.fault` | Optional `true` for a permanent fault reported by the host owner. Do not infer it from degraded state or `last_error`; omission is not proof that the whole command is fault-free. |
+| `scheduler.next_retry_at` | Optional next retry timestamp during recovery. Observation does not reset it. |
+| `scheduler.last_error` | Optional bounded host diagnostic. Keep it alongside pending or readiness facts. |
+| `scheduler.next_action` | Caller guidance, such as `start_required`, `inspect_scheduler` or `stop_foreground_runtime`. |
+| `scheduler.serve_command` | Optional exact argv array for an independent user start. Preserve every element and its argument boundary. |
+| `scheduler.stop_accepted` | Optional boolean for acceptance of this stop request. `true` is accepted, `false` is explicitly not accepted, and omission is unknown. Acceptance does not prove shutdown completed. |
+
+For `start_required`, both `schedule.next_action` and `scheduler.next_action`
+carry that guidance. `scheduler.serve_command` is JSON argv, including the
+resolved executable and exact root. Human output also prints JSON argv after
+`run independently (argv):`. For example, a returned root containing spaces:
+
+```text
+run independently (argv): ["/installation with spaces/delegate","--root","/state with spaces","scheduler","serve"]
+```
+
+Forward the array intact. It is not an unquoted shell command: do not join its
+elements with spaces or pass the joined text through a shell. The user starts
+serve independently with those exact argument boundaries; the agent must not
+execute it inside its bounded task. An omitted `schedule.saved` does not confirm
+persistence; preserve any ID and follow the reported storage/error guidance.
+
+| Response or observation | Next action |
+| --- | --- |
+| Create/resume saved the definition and confirmed a compatible ready host; exit `0` | Keep its schedule ID/root. The host will handle future due work; use history/execution for actual occurrence evidence. |
+| Create/resume returns exit `3`, `schedule.saved: true` and `scheduler.next_action: start_required` | The definition remains saved. Preserve the returned schedule ID/root and give `scheduler.serve_command` unchanged to the user to run in an independent terminal or tmux pane. Never start it inside the agent's bounded task, detach it in the background, or submit another create. |
+| Create/resume saved the definition but reports starting, backoff or pending readiness; exit `3` | Keep the same ID and report its host state and available retry time. Use passive scheduler status for later observation; do not create another definition, start a competing host or reset cooldown. |
+| Create/resume saved the definition but the host is temporarily unreachable; exit `3`, pending guidance and no top-level `error` | Preserve `schedule.saved: true` and the same ID. Use passive status to observe the uncertainty. A transport failure does not establish owner death or a permanent host fault. |
+| Create/resume saved the definition and the host reports `scheduler.fault: true`; exit `1` | Report the permanent fault and available `scheduler.last_error`; retain `schedule.saved: true` and the ID. For an incompatible saved definition, the before-Ready check stops automatic child restart. Repeated create, serve or status calls are not a repair. |
+| Scheduler status observes starting, ready, backoff, degraded, stopping or stopped; exit `0` | Observation completed. Report the observed state; exit `0` does not mean ready or that an occurrence succeeded. Status does not start, migrate, repair or clean resources. |
+| Scheduler stop confirms completed stop; exit `0` | The exact stopped intent has a validated owner-written closure witness and the exact host is absent. The witness follows joined child shutdown and free execution ownership. Independently admitted tasks keep their existing lifetimes. A later host needs a fresh explicit user-run serve command. |
+| Scheduler stop has `scheduler.stop_accepted: true` but completion is pending; exit `3` | Preserve its acceptance and pending state. The host remains control-responsive while joining its child or waiting for a prior execution owner. Host death before the closure witness does not complete stop. Observe the same generation; do not claim stopped, launch a replacement or repeat schedule creation. An omitted `stop_accepted` is unknown, not false. |
+| Scheduler stop has authenticated `scheduler.stop_accepted: true` and a later readback fault; exit `1` | Preserve the accepted fact and report the concrete fault. Readback failure does not revoke acceptance or establish completed shutdown. |
+| Status reports `scheduler.state: foreground`, or stop returns exit `3` with that state, `stop_accepted: false` and `next_action: stop_foreground_runtime` | The current compatibility `scheduler run` owns this generation; an older managed-host receipt cannot hide it. Public stop does not terminate it. Have the user end that invocation with Ctrl-C in its original pane. Prefer managed `scheduler serve` afterward. |
+| Invalid input/state; exit `2`, or concrete operational/compatibility/cleanup fault; exit `1` | Report the error and retain any saved ID or accepted-control fact. A concrete fault joined to pending work remains a fault; it is not a pending-only result. |
+
+If the host dies, its pane closes or the machine reboots, the user must start
+serve again. Child crash recovery applies only while that host remains alive.
+An absent heartbeat or unresponsive endpoint is uncertainty, not permission to
+replace an owner. Do not install a service or invoke a detached bootstrap as a
+recovery step. Pause/delete affect future claims and need no live host; they do
+not cancel already admitted occurrences. [Scheduler runtime](command-reference.md#scheduler-runtime)
+owns launch, backoff and calendar behavior.
+
 ## Scheduled execution results
 
 Use [schedule history and execution](command-reference.md#schedule-history-and-execution)
@@ -220,7 +283,7 @@ For an older released occurrence whose publication is unfinished, use the
 existing collection command with the same root and task ID:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect TASK_ID --watch 0s --json
+delegate collect TASK_ID --watch 0s --json
 ```
 
 Follow its own response and exit using [observation guidance](#observe-and-collect).
@@ -330,7 +393,7 @@ When Delegate returns `failure.next_action: "recheck"`, use the same root and
 exact task ID:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" recheck TASK_ID --json
+delegate recheck TASK_ID --json
 ```
 
 This command checks the already sealed evidence with an explicitly compatible

package/skills/agent-integration/references/routing-rule.json

@@ -1 +1 @@
-"For work assigned to an external agent, model, or separate harness session, load the installed agent-integration skill before choosing tools and use Delegate. This includes research, implementation, testing, review, consultation, comparison, and debate, including external collaboration you choose. Discover destinations through Delegate. Preserve requested model IDs, effort, and permissions; do not guess ambiguous model identifiers. For task commands, pass --root \"${DELEGATE_ROOT:-$HOME/delegation-state}\" directly in each shell invocation; reuse that root for dispatch, observation, and continuation, never an invented /tmp root. If the user explicitly requests another root, use that exact path consistently. Keep each concurrent request and its response associated separately. Capture each dispatch response and exit status once; after task_record created, observe that task ID. Never dispatch again merely to recover output or inspect its exit status. Naming a CLI identifies the destination, not a request to bypass Delegate. Earlier assistant-generated direct-launch workflows do not override this preference. Native same-harness subagents remain available unless a separate session is requested. Respect an explicit user choice of another integration; otherwise do not substitute provider CLIs, plugins, or APIs after a Delegate blocker. Before observing or retrying an admission, read the installed skill's references/result-handling.md#task-creation and apply its creation decisions. It owns the narrow same-root migration, workspace-wait, and resource-refusal exceptions before the generic not_created stop rule. Preserve the original admission intent: dispatch remains dispatch and continue remains continue; never replace a failed continue with a fresh dispatch or direct provider call. A stop_and_report failure ends that attempt, not diagnosis: follow references/result-handling.md#failure-diagnosis without another generic troubleshooting request. Inspect bounded returned evidence and relevant authorized local read-only facts, distinguish supported causes from uncertainty, and propose a concrete next step. Do not poll unknown/uncreated tasks, expose credentials or unrestricted output, retry uncertain work, change setup/permissions or substitute destinations without authorization covering that action. Continue other independent requests. Keep collection in the foreground until completion or a reported blocker unless the user requested detachment. Pending work is observed through Delegate status, collect, or events, not OS process searches or supervisor commands. Merely discussing or configuring a tool is not delegation."
+"For work assigned to an external agent, model, or separate harness session, load the installed agent-integration skill before choosing tools and use Delegate. This includes research, implementation, testing, review, consultation, comparison, and debate, including external collaboration you choose. Discover destinations through Delegate. Preserve requested model IDs, effort, and permissions; do not guess ambiguous model identifiers. For ordinary task, schedule, observation, interaction, and continuation commands, omit --root and let the CLI resolve its default in the same user/configuration context, independently of project cwd. Never assemble a default path, use a sample path or shell fallback, or treat ambient DELEGATE_ROOT as authority. Only pass --root for an explicitly user-supplied or already recorded custom or historical root; preserve that exact path for every command concerning its work. Do not search other roots for an old task or invent per-task or per-project roots. Keep each concurrent request and its response associated separately. Capture each dispatch response and exit status once; after task_record created, observe that task ID. Never dispatch again merely to recover output or inspect its exit status. Naming a CLI identifies the destination, not a request to bypass Delegate. Earlier assistant-generated direct-launch workflows do not override this preference. Native same-harness subagents remain available unless a separate session is requested. Respect an explicit user choice of another integration; otherwise do not substitute provider CLIs, plugins, or APIs after a Delegate blocker. Before observing or retrying an admission, read the installed skill's references/result-handling.md#task-creation and apply its creation decisions. It owns the narrow same-root migration, workspace-wait, and resource-refusal exceptions before the generic not_created stop rule. Preserve the original admission intent: dispatch remains dispatch and continue remains continue; never replace a failed continue with a fresh dispatch or direct provider call. A stop_and_report failure ends that attempt, not diagnosis: follow references/result-handling.md#failure-diagnosis without another generic troubleshooting request. Inspect bounded returned evidence and relevant authorized local read-only facts, distinguish supported causes from uncertainty, and propose a concrete next step. Do not poll unknown/uncreated tasks, expose credentials or unrestricted output, retry uncertain work, change setup/permissions or substitute destinations without authorization covering that action. Continue other independent requests. Keep collection in the foreground until completion or a reported blocker unless the user requested detachment. Pending work is observed through Delegate status, collect, or events, not OS process searches or supervisor commands. Merely discussing or configuring a tool is not delegation."

package/skills/agent-integration/references/workspaces.md

@@ -7,6 +7,10 @@ or attaches to a managed workspace (`--isolation git-worktree` or
 `--workspace ID`), or creates or removes a [Git checkpoint](#git-checkpoints).
 
 This reference is self-contained guidance for using managed workspaces.
+Commands use the CLI default under the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief). For a workspace
+or checkpoint in an explicit custom or recorded historical root, pass that
+exact `--root` on every related command.
 
 Provider-native permissions still apply inside an isolated checkout. A provider
 may edit files but be unable to stage or commit because linked-worktree Git
@@ -41,7 +45,7 @@ row ending or a provider outcome alone is not closure evidence.
 Create a managed workspace from a committed source base:
 
 ```text
-delegate --root ROOT dispatch --isolation git-worktree --cwd ABS \
+delegate dispatch --isolation git-worktree --cwd ABS \
   [--base REV] [--workspace-budget DURATION] ... --json
 ```
 
@@ -55,7 +59,7 @@ removing that source does not block capture, release, or forget. A request that
 workspace uses its recorded checkout and source identity:
 
 ```text
-delegate --root ROOT dispatch --workspace WORKSPACE_ID ... --json
+delegate dispatch --workspace WORKSPACE_ID ... --json
 ```
 
 Public `--workspace` cannot be combined with `--cwd`, `--base`, or
@@ -80,11 +84,11 @@ made no write outside the promised content scope.
 The CLI currently exposes these managed-workspace commands:
 
 ```text
-delegate --root ROOT workspace list [--after ID] [--limit 1..50] --json
-delegate --root ROOT workspace status ID [--operation OP] [--watch DURATION] --json
-delegate --root ROOT workspace exec ID --budget DURATION --json -- ARGV...
-delegate --root ROOT workspace release ID [--discard] [--budget DURATION] --json
-delegate --root ROOT workspace forget ID [--budget DURATION] --json
+delegate workspace list [--after ID] [--limit 1..50] --json
+delegate workspace status ID [--operation OP] [--watch DURATION] --json
+delegate workspace exec ID --budget DURATION --json -- ARGV...
+delegate workspace release ID [--discard] [--budget DURATION] --json
+delegate workspace forget ID [--budget DURATION] --json
 ```
 
 `workspace exec` passes `ARGV...` directly to the supervised helper; the
@@ -110,7 +114,7 @@ must not mutate the predecessor's immutable records. A retained workspace can be
 read-only review by attaching its ID, for example:
 
 ```text
-delegate --root ROOT dispatch --provider codex:review \
+delegate dispatch --provider codex:review \
   --workspace WORKSPACE_ID --review-target TARGET --brief ABS_BRIEF \
   --permission read-only --budget 1h --json
 ```
@@ -183,11 +187,11 @@ 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
+delegate checkpoint create --cwd ABS [--budget DURATION] --json
+delegate checkpoint create --workspace ID [--budget DURATION] --json
+delegate checkpoint status CHECKPOINT_ID [--operation OP] [--watch DURATION] --json
+delegate checkpoint list [--after CHECKPOINT_ID] [--limit 1..50] --json
+delegate checkpoint remove CHECKPOINT_ID [--budget DURATION] --json
 ```
 
 - `create` names exactly one target: `--cwd` for an absolute ordinary Git
@@ -232,7 +236,7 @@ Save every response and exit code once; follow
    the same repository as `--cwd`, normally the source the Lead already uses:
 
    ```text
-   delegate --root ROOT dispatch --auto --brief ABS_BRIEF --cwd ABS_SOURCE \
+   delegate dispatch --auto --brief ABS_BRIEF --cwd ABS_SOURCE \
      --isolation git-worktree --base COMMIT_OID \
      --permission workspace-write --budget 30m --json
    ```