delegation-layer 0.3.0 → 0.4.0

package/README.md

@@ -57,8 +57,10 @@ For a manual CLI task, use the packaged
 [read-only example](skills/agent-integration/examples/read-only-task.md).
 
 For recurring work, follow the [scheduler walkthrough](docs/getting-started.md#recurring-tasks)
-to save a definition, start the scheduler in your own terminal or tmux pane,
-inspect its first result and stop or restart it.
+to start `delegate scheduler serve` in your own terminal or tmux pane, even
+before saving a definition. Agents and manual commands share the CLI's default
+state across projects. The walkthrough covers saving a schedule, inspecting its
+first result and stopping or restarting the host.
 
 ## Help and contributing
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "delegation-layer",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "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.3.0",
+  "version": "0.4.0",
   "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.3.0",
+  "version": "0.4.0",
   "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

@@ -87,11 +87,16 @@ Use a supplied brief or write the worker's bounded assignment and acceptance
 criteria to a regular file. Do not copy the orchestration request or ask workers
 to recruit others unless recursive delegation was requested.
 
-Keep the state root outside provider-writable workspaces, provider runtime
-directories, and temporary trees they may write. For every task command pass
-`--root "${DELEGATE_ROOT:-$HOME/delegation-state}"` directly in that shell
-invocation. If the user explicitly requests another root, use that exact path
-consistently. Task IDs separate tasks; do not invent per-task roots.
+For ordinary task, schedule, observation, interaction, and continuation commands,
+omit `--root`; the CLI owns default-root resolution for the user's configuration
+context, independently of the project cwd. Do not assemble a default path, use a
+sample path or shell fallback, or treat ambient `DELEGATE_ROOT` as authority.
+Only pass `--root` when the user explicitly supplies a root or existing work has
+an already recorded custom or historical root; preserve that exact path for
+every command concerning that work. Never search other roots for an old task.
+Task IDs separate tasks; do not invent per-task or per-project roots. The state
+root must remain outside provider-writable workspaces, provider runtime
+directories, and temporary trees they may write.
 
 Prepare paths and dispatch in one tool invocation; shell variables may not
 persist between calls. Use saved absolute paths in later calls. Do not use
@@ -125,13 +130,16 @@ original command and intent.
 ### 5. Observe and collect
 
 Follow [observation decisions](references/result-handling.md#observe-and-collect)
-with the same root and created task ID:
+with the created task ID, using the CLI default for ordinary work:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" status TASK_ID --json
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect TASK_ID --watch 5s --json
+delegate status TASK_ID --json
+delegate collect TASK_ID --watch 5s --json
 ```
 
+For work bound to an explicit custom or historical root, add its exact
+`--root` to both commands under the [root rule](#3-prepare-separate-paths-and-a-finite-brief).
+
 Apply the owning decision order before waiting: terminal outcomes and concrete
 errors, cancellation/timeout/interruption, interaction, then pending
 observation. Keep collection in the foreground until completion or a reported

package/plugins/delegation-layer/skills/agent-integration/evals/evals.json

@@ -10,7 +10,7 @@
     {
       "name": "normal-dispatch",
       "prompt": "Run one bounded task through the available agent provider.",
-      "expected": ["dispatch --auto", "--json", "save task_id", "status", "collect"]
+      "expected": ["dispatch --auto", "omit --root on ordinary commands", "--json", "save task_id", "status", "collect"]
     },
     {
       "name": "model-discovery-when-needed",
@@ -68,9 +68,29 @@
       "expected": ["use status with returned task_id", "read saved dispatch response if needed", "do not dispatch again to print an exit code", "exactly one admitted task for the assignment"]
     },
     {
-      "name": "supplied-root-across-shell-calls",
+      "name": "ambient-root-ignored-across-shell-calls",
       "prompt": "DELEGATE_ROOT is already set. Consult a separate external agent and answer its questions; each shell tool call starts a new shell.",
-      "expected": ["use supplied DELEGATE_ROOT on dispatch, status, collect, reply, steer, and continue", "resolve the same root in each shell call", "no invented task-specific root"]
+      "expected": ["omit --root on dispatch, status, collect, reply, steer, and continue", "ambient DELEGATE_ROOT has no root-selection authority", "CLI resolves its default in the same user/configuration context", "no assembled default, shell fallback, sample path, or per-task root"]
+    },
+    {
+      "name": "ordinary-root-from-another-project",
+      "prompt": "DELEGATE_ROOT is unset. An admitted task was dispatched without --root in project A. Observe and continue it from project B in the same user/configuration context.",
+      "expected": ["omit --root on status, collect, and continue", "use the recorded task ID", "CLI default is independent of project cwd", "no path guessed from project A or B", "no search across roots"]
+    },
+    {
+      "name": "explicit-root-across-shell-calls",
+      "prompt": "For this isolated test, I explicitly choose the state root /state/custom with spaces. Consult a separate external agent and answer its questions; each shell tool call starts a new shell.",
+      "expected": ["pass --root with the exact single argument /state/custom with spaces on dispatch, status, collect, reply, steer, and continue", "quote the root in shell commands", "save and reassign absolute brief and response paths in each needed shell invocation", "no ambient variable or fallback overrides the explicit choice"]
+    },
+    {
+      "name": "historical-root-continuation",
+      "prompt": "An eligible predecessor task has recorded historical root /state/legacy with spaces. Continue that exact task and collect its successor. The current CLI default is different.",
+      "expected": ["pass the exact recorded --root argument /state/legacy with spaces on continue, status, and collect", "use the exact predecessor and returned successor IDs", "no fresh dispatch", "do not move or search for the task in the default root"]
+    },
+    {
+      "name": "ordinary-schedule-root",
+      "prompt": "Create a recurring task in this project, then inspect its definition, history, and execution from another project in the same user/configuration context. No custom state root was requested.",
+      "expected": ["omit --root on schedule create, list, show, history, and execution", "keep the definition's own project --cwd", "no per-project root", "do not start a persistent scheduler inside the agent task", "forward any returned scheduler.serve_command argv intact"]
     },
     {
       "name": "pending-without-questions",

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

@@ -1,8 +1,11 @@
 # JSON decision sketch
 
+Use the created task's exact ID as `TASK_ID` and follow the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief).
+
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" status "$TASK_ID" --json
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect "$TASK_ID" --watch 5s --json
+delegate status TASK_ID --json
+delegate collect TASK_ID --watch 5s --json
 ```
 
 Apply [result handling](../references/result-handling.md) to each response and

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

@@ -3,14 +3,18 @@
 Use this example for independent write work that should be isolated in a
 retained Git worktree. The source must be a Git checkout and the state root
 must remain outside provider-writable workspaces.
+Commands use the CLI default under the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief); preserve any
+explicit custom or recorded historical root on all related commands.
 
 ```sh
 SOURCE="$PWD"
-BRIEF="$(mktemp)"
-RESPONSE="$(mktemp)"
+BRIEF="$(mktemp)" || exit 1
+RESPONSE="$(mktemp)" || exit 1
 printf '%s\n' 'Implement the requested change and report the files changed.' >"$BRIEF"
+printf 'Saved response: %s\n' "$RESPONSE"
 
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" dispatch --auto \
+if delegate dispatch --auto \
   --brief "$BRIEF" --cwd "$SOURCE" \
   --permission workspace-write --isolation git-worktree \
   --base HEAD --workspace-budget 5m --budget 30m --json >"$RESPONSE"; then
@@ -26,9 +30,13 @@ Read the saved JSON before running another command. When
 `task_record: "created"`, use its `task_id` as `TASK_ID` below. When no task
 was created, follow the [result decisions](../references/result-handling.md#managed-workspace-results);
 do not run task status or collection against that nonexistent record.
+Each later block is a separate shell invocation. Replace `ABS_SAVED_RESPONSE`
+with the printed absolute response path and the ID placeholders with the actual
+returned IDs; reassign the path in each invocation.
 
 ```sh
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" status TASK_ID --json >"$RESPONSE.status"; then
+RESPONSE="ABS_SAVED_RESPONSE"
+if delegate status TASK_ID --json >"$RESPONSE.status"; then
   status_exit=0
 else
   status_exit=$?
@@ -43,7 +51,8 @@ before running another command. Run the collection below only when that
 guidance calls for it.
 
 ```sh
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect TASK_ID --watch 5s --json >"$RESPONSE.collect"; then
+RESPONSE="ABS_SAVED_RESPONSE"
+if delegate collect TASK_ID --watch 5s --json >"$RESPONSE.collect"; then
   collect_exit=0
 else
   collect_exit=$?
@@ -64,7 +73,8 @@ Before release, wait for the workspace to return to `state: retained` and inspec
 its final capture. Only after the Lead explicitly chooses release, run:
 
 ```sh
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" workspace release WORKSPACE_ID \
+RESPONSE="ABS_SAVED_RESPONSE"
+if delegate workspace release WORKSPACE_ID \
   --budget 5m --json >"$RESPONSE.release"; then
   release_exit=0
 else
@@ -95,8 +105,9 @@ owns every response decision.
 
 ```sh
 SOURCE="$PWD"
-RESPONSE="$(mktemp)"
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint create \
+RESPONSE="$(mktemp)" || exit 1
+printf 'Saved response: %s\n' "$RESPONSE"
+if delegate checkpoint create \
   --cwd "$SOURCE" --budget 5m --json >"$RESPONSE.checkpoint"; then
   checkpoint_exit=0
 else
@@ -109,9 +120,12 @@ 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.
+For the later checkpoint blocks, replace `ABS_SAVED_RESPONSE` with the absolute
+response path printed by this checkpoint invocation.
 
 ```sh
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint status CHECKPOINT_ID \
+RESPONSE="ABS_SAVED_RESPONSE"
+if delegate checkpoint status CHECKPOINT_ID \
   --watch 30s --json >"$RESPONSE.checkpoint.status"; then
   checkpoint_status_exit=0
 else
@@ -130,7 +144,8 @@ dispatch example, replacing `--base HEAD` with `--base COMMIT_OID`. Report a
 When the Lead no longer needs the checkpoint, remove it explicitly:
 
 ```sh
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" checkpoint remove CHECKPOINT_ID \
+RESPONSE="ABS_SAVED_RESPONSE"
+if delegate checkpoint remove CHECKPOINT_ID \
   --budget 5m --json >"$RESPONSE.checkpoint.remove"; then
   checkpoint_remove_exit=0
 else

package/plugins/delegation-layer/skills/agent-integration/examples/read-only-task.md

@@ -2,6 +2,8 @@
 
 Run from the intended workspace, outside Delegate's private state root.
 Use a catalog provider ID in place of `--auto` when a destination was named.
+This example uses the CLI default under the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief).
 Prepare paths and dispatch in this same shell invocation:
 
 ```sh
@@ -13,7 +15,7 @@ Inspect the workspace and summarize the current test failures. Do not edit files
 You are the assigned worker; perform this task without delegating it.
 EOF
 printf 'Saved response: %s\n' "$RESPONSE"
-if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" dispatch --auto \
+if delegate dispatch --auto \
   --brief "$BRIEF" --cwd "$WORKSPACE" \
   --permission read-only --budget 30m --json >"$RESPONSE"; then
   dispatch_exit=0

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

@@ -3,18 +3,19 @@
 Use this reference when asked to consult Claude Code Router (CCR), use one of
 its configured model aliases, or compare its models with other harnesses.
 CCR runs Claude Code against a configured third-party or local provider.
-`ROOT` below is the exact absolute state root selected for dispatch; use it
-unchanged for model discovery and dispatch.
+Use the CLI default under the main skill's
+[root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief); preserve any
+explicit custom or recorded historical root for model discovery and dispatch.
 
 1. Resolve CCR through `delegate providers --json`; its profile is `ccr:print`.
 2. Preserve an explicitly requested CCR alias as `--model ALIAS`. Do not replace
    it with an upstream model ID or reject it solely because discovery omitted it.
 3. If no alias was chosen, run
-   `delegate --root ROOT models --provider ccr:print --cwd ABSOLUTE_WORKSPACE --json`.
+   `delegate models --provider ccr:print --cwd ABSOLUTE_WORKSPACE --json`.
    Choose a suitable configured alias from the available metadata and report
    the choice. Clarify when the intended model remains ambiguous. If discovery
    is unavailable and no alias is known, report the blocker; do not guess.
-4. Dispatch through Delegate with the same `--root ROOT`,
+4. Dispatch through Delegate with
    `--provider ccr:print --model ALIAS`, the brief, workspace, permission, finite
    budget, and `--json`. Use the normal status, collect, and continuation procedure
    from the main skill.

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

@@ -45,7 +45,7 @@ RECEIPTS="$(mktemp -d)" || exit 1
 # Set these absolute paths and catalog IDs in this same tool invocation.
 # BRIEF_A and BRIEF_B contain the real independent assignments.
 (
-  if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" dispatch --provider "$PROVIDER_A" \
+  if delegate dispatch --provider "$PROVIDER_A" \
     --brief "$BRIEF_A" --cwd "$WORKSPACE_A" \
     --permission read-only --budget 30m --json \
     >"$RECEIPTS/review-a.json" 2>"$RECEIPTS/review-a.stderr"; then
@@ -56,7 +56,7 @@ RECEIPTS="$(mktemp -d)" || exit 1
   printf '%s\n' "$dispatch_exit" >"$RECEIPTS/review-a.exit"
 ) &
 (
-  if delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" dispatch --provider "$PROVIDER_B" \
+  if delegate dispatch --provider "$PROVIDER_B" \
     --brief "$BRIEF_B" --cwd "$WORKSPACE_B" \
     --permission read-only --budget 30m --json \
     >"$RECEIPTS/review-b.json" 2>"$RECEIPTS/review-b.stderr"; then

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

@@ -24,13 +24,15 @@ The main skill owns [root selection](../SKILL.md#3-prepare-separate-paths-and-a-
 | `schedule` | [Recurring definitions](#schedules), [history and execution evidence](#schedule-history-and-execution) | None |
 | `scheduler serve/status/stop` (when supported), `scheduler run` | [User-started host and compatibility runtime](#scheduler-runtime) | Due occurrences use normal dispatch; status/stop do not launch providers |
 
-Prefix every task command with `delegate --root ROOT`, using the same
-explicit root across invocations.
+The commands below use the CLI default and omit `--root`. The advanced override
+syntax is `delegate --root ABS COMMAND ...`; use it only for an explicitly
+supplied or already recorded custom or historical root, preserved exactly under
+the main skill's [root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief).
 
 ## Dispatch
 
 ```text
-delegate --root ROOT dispatch [--auto | --provider ID] --brief FILE \
+delegate dispatch [--auto | --provider ID] --brief FILE \
   --cwd ABS [--id TASK_ID] [--permission MODE] [--budget DURATION] \
   [--model MODEL] [--effort EFFORT] [--native-timeout DURATION] \
   [--interactive] [--review-target TARGET] [--resume-task TASK_ID] \
@@ -170,8 +172,8 @@ setup, even when there is no matching Team or project default.
 After a task record is created, inspect the same ID and root:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" status TASK_ID --json
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" collect TASK_ID --watch 5s --json
+delegate status TASK_ID --json
+delegate collect TASK_ID --watch 5s --json
 ```
 
 Dispatch/status/collect optionally expose top-level `team`, the admitted
@@ -198,18 +200,18 @@ another create to obtain a running scheduler.
 See [definition and host results](result-handling.md#schedule-definition-and-host-results).
 
 ```text
-delegate --root ROOT schedule create --brief FILE --cwd ABS \
+delegate schedule create --brief FILE --cwd ABS \
   [--auto | --provider ID] --cron 'MIN HOUR DOM MONTH DOW' \
   [--timezone ZONE] [--id SCHEDULE_ID] [--model MODEL] [--effort EFFORT] \
   [--permission MODE] [--budget DURATION] [--native-timeout DURATION] \
   [--review-target TARGET] \
   [--team-scope user|project --team TEAM_ID --member MEMBER_ID] \
   [--project-root ABS] --json
-delegate --root ROOT schedule list [--after SCHEDULE_ID] [--limit N] --json
-delegate --root ROOT schedule show SCHEDULE_ID --json
-delegate --root ROOT schedule pause SCHEDULE_ID --json
-delegate --root ROOT schedule resume SCHEDULE_ID --json
-delegate --root ROOT schedule delete SCHEDULE_ID --json
+delegate schedule list [--after SCHEDULE_ID] [--limit N] --json
+delegate schedule show SCHEDULE_ID --json
+delegate schedule pause SCHEDULE_ID --json
+delegate schedule resume SCHEDULE_ID --json
+delegate schedule delete SCHEDULE_ID --json
 ```
 
 - Requested provider options remain as supplied, including omissions. Creation
@@ -245,9 +247,10 @@ delegate --root ROOT schedule delete SCHEDULE_ID --json
   history. Pause/delete do not cancel an active occurrence or require a live
   host. Create/resume preserve the saved definition even when the host is
   absent, starting, in backoff or otherwise not confirmed ready.
-- Only create initializes absent schedule storage. An absent store lists as
-  empty; show/state commands report not found. List defaults to 50 rows, at most
-  100, including paused/deleted definitions. Use the returned cursor to page.
+- Among schedule management commands, only create initializes absent storage.
+  An absent store lists as empty; show/state commands report not found. List
+  defaults to 50 rows, at most 100, including paused/deleted definitions. Use the
+  returned cursor to page.
 - Create/state responses are compact. Show returns saved requested choices and
   brief metadata, not brief contents, with a 2 MiB response limit. Keep the ID
   when output or storage reports uncertainty; inspect it with show rather than
@@ -265,8 +268,8 @@ timestamp range has a distinct range error, not a claim of permanent invalidity.
 ### Schedule history and execution
 
 ```text
-delegate --root ROOT schedule history SCHEDULE_ID [--before RFC3339Nano] [--limit N] --json
-delegate --root ROOT schedule execution TASK_ID --json
+delegate schedule history SCHEDULE_ID [--before RFC3339Nano] [--limit N] --json
+delegate schedule execution TASK_ID --json
 ```
 
 `history` returns occurrence summaries and compact skipped intervals together,
@@ -292,22 +295,49 @@ Missing task files and corrupt evidence are distinct; see
 [scheduled result handling](result-handling.md#scheduled-execution-results)
 for freshness, no-result states, response bounds, exit codes and recovery.
 
+## Supervisor owner control
+
+```sh
+delegate supervisor stop-owner --json
+```
+
+Use only when the installed build advertises this command. Preserve the explicit
+root for work bound to a custom or historical root. This command contacts one
+existing infrastructure owner; it does not initialize, repair or start one.
+It leaves Pueue and admitted tasks running. Startup, accepted operations and
+unresolved cleanup can make the owner busy.
+
+The `supervisor_owner` response separates `state` (`serving_released`,
+`not_initialized`, `busy` or `unknown`) from `process_closure` (`closed`,
+`pending` or `unknown`). A released owner can remain alive as the sole waiter for
+its daemon; serving release is not proof of process exit or root quiescence.
+The optional `process` value (`pid`, `start_token`) identifies the validated
+selected `startup`; it does not establish liveness. It is omitted when no owner
+was selected or validated. Observe that exact incarnation after daemon shutdown;
+a new root-selected stop can address a newer owner.
+An absent root reports `not_initialized` with unknown process closure.
+Exit `0` reports the observed release or uninitialized state, `3` reports busy,
+and `1` reports a control or observation fault. Preserve an uncertain result;
+the command does not resend an uncertain stop request. Human output exposes
+the same separate observations.
+
 ## Scheduler runtime
 
 Check `delegate help` for the installed build's command surface. Use `serve`,
 `status` and `stop` only when that help advertises them; prefer `serve` for managed
-recovery. The signatures below describe the current command surface. Keep the
-same explicit absolute `ROOT` used by the schedule commands.
+recovery. The signatures below describe the current command surface. They use
+the same CLI default as ordinary schedule commands; preserve an explicit custom
+or historical root when the schedule is bound to one.
 
 ```text
-delegate --root ROOT scheduler serve
-delegate --root ROOT scheduler status
-delegate --root ROOT scheduler stop
-delegate --root ROOT scheduler run [--pueue-config ABS] [--json]
+delegate scheduler serve
+delegate scheduler status
+delegate scheduler stop
+delegate scheduler run [--pueue-config ABS] [--json]
 ```
 
 If installed help offers only `scheduler run`, the user runs
-`delegate --root ROOT scheduler run` in an independent terminal or tmux pane and
+`delegate scheduler run` in an independent terminal or tmux pane and
 leaves it in the foreground. Ctrl-C in its original pane stops it; it has no
 automatic child restart. Keep the saved schedule ID and inspect
 [history and execution](#schedule-history-and-execution) for actual occurrences.
@@ -332,9 +362,13 @@ When present, `scheduler.serve_command` preserves spaces and shell metacharacter
 as separate arguments. Human output also prints JSON argv, not an unquoted shell string.
 Preserve those boundaries; see the [scheduler response fields](result-handling.md#schedule-definition-and-host-results).
 
-Serve requires existing schedule storage; create owns initialization. A second
-host or competing `run` cannot acquire the same root's ownership. The host uses
-its retained launch context and the saved requested provider choices. For
+Explicit `serve` may initialize absent scheduler storage through the same
+scheduler owner lease used by `schedule create`. It can become ready with no
+definitions; later creates reach that running host without a restart. Existing
+root identity and data stay in place; invalid existing storage fails explicitly.
+Passive reads and low-level `run` do not initialize absent storage. A second host
+or competing `run` cannot acquire the same root's ownership. The host uses its
+retained launch context and the saved requested provider choices. For
 Team-targeted schedules, new occurrences read the pinned catalog's latest Member
 defaults through normal admission; existing task IDs retain saved settings. Use
 the intended user configuration context, or a different catalog instance fails
@@ -452,8 +486,8 @@ A checkpoint is Git-content evidence, not a provider outcome.
 ## Providers and capabilities
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" providers --json
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" capabilities --provider PROVIDER_ID --json
+delegate providers --json
+delegate capabilities --provider PROVIDER_ID --json
 ```
 
 `providers` returns `schema_version: 1` and a sorted `providers` array.
@@ -479,9 +513,11 @@ Inspection-backed admission can return `status: "ready"` with
 `verification: "runtime"` after its probe. Managed runtime-only admission
 keeps the catalog projection; its supervised worker checks compatibility before
 provider execution. Collect the created task to establish the result.
-Optional protocol members `version` and `executable_sha256` are diagnostics,
-not launch authority. Live acceptance remains separate (`not_run`, `passed`,
-or `blocked`); a blocked prerequisite is unresolved.
+Provider versions are optional diagnostics. Historical executable-digest members
+remain readable as recorded data. Do not depend on these fields or calculate new
+executable fingerprints for diagnostics or admission. Required behavior and the
+selected installed executable govern compatibility. Live acceptance remains separate (`not_run`,
+`passed`, or `blocked`); a blocked prerequisite is unresolved.
 
 ## Choosing models and effort
 
@@ -490,7 +526,7 @@ them. Keep defaults when no explicit choice is needed. Resolve a natural-languag
 name through native discovery:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" models \
+delegate models \
   --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE --json
 ```
 
@@ -533,7 +569,7 @@ reason codes and return no model facts.
 Use static preflight when readiness was requested, not before every task:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" preflight \
+delegate preflight \
   --provider PROVIDER_ID --cwd ABSOLUTE_WORKSPACE \
   --permission REQUESTED_MODE --json
 ```

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

@@ -22,7 +22,7 @@ When `status` or `collect` reports a timed-out turn with:
 run:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" continue \
+delegate continue \
   --task PREDECESSOR_TASK_ID \
   --brief FOLLOW_UP_BRIEF \
   --budget 30m \
@@ -35,8 +35,11 @@ indefinitely for a publication that the interrupted turn cannot complete.
 
 The follow-up brief is optional. If it is omitted, Delegation Layer reuses the
 validated predecessor brief. A successful continuation returns a new task ID
-and links it to the predecessor. Observe and collect the new ID separately. Always retain the original state
-root, even if a returned command hint omits it. Permission is inherited; do not
+and links it to the predecessor. Observe and collect the new ID separately.
+Follow the main skill's [root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief):
+ordinary continuation omits `--root` in the same user/configuration context;
+an explicit custom or recorded historical root must be retained exactly, even
+if a returned command hint omits it. Permission is inherited; do not
 add `--permission` to `continue`. Apply
 [task creation](result-handling.md#task-creation) before retrying or observing.
 Any authorized admission retry remains the argv-equivalent `continue`;
@@ -85,7 +88,7 @@ observe that successor instead; if its creation is uncertain, follow the
    `workspace.id` from the task response; never guess an ID or path:
 
    ```sh
-   delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" workspace status \
+   delegate workspace status \
      WORKSPACE_ID --watch 30s --json
    ```
 

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

@@ -62,7 +62,7 @@ question. A printed question alone is not a pending reply request.
    together with the exact answers. Submit the reply:
 
    ```sh
-   delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" reply "$task_id" \
+   delegate reply "$task_id" \
      --request "$request_id" --answers "$answers_file" \
      --id "$message_id" --json
    ```
@@ -70,9 +70,10 @@ question. A printed question alone is not a pending reply request.
 6. Keep collecting. A receipt is not task completion. Only the task's
    authoritative `outcome` establishes the final result.
 
-Use the same root expression for dispatch, collection, reply, and steering.
-If the user explicitly chose another root, use that exact path for all of
-them. The other variables stand for actual values saved from this task;
+Follow the main skill's [root rule](../SKILL.md#3-prepare-separate-paths-and-a-finite-brief)
+for dispatch, collection, reply, and steering. The examples use the CLI default;
+preserve an explicit custom or recorded historical root for all of them.
+The variables stand for actual values saved from this task;
 reassign them in each shell invocation if your tool does not preserve variables.
 A pending response without questions means keep collecting, not inspect OS
 processes or dispatch a replacement task.
@@ -86,7 +87,7 @@ reply IDs and earlier steering IDs. Submit it; for a lost response, follow the
 [delivery rules](#interpret-delivery-precisely) with the same ID and content:
 
 ```sh
-delegate --root "${DELEGATE_ROOT:-$HOME/delegation-state}" steer "$task_id" \
+delegate steer "$task_id" \
   --brief "$guidance_file" --id "$steering_message_id" --json
 ```
 

package/plugins/delegation-layer/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. |
@@ -192,7 +195,7 @@ keep `schedule.id` even if the command exits nonzero. The separate top-level
 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:
+`run independently (argv):`. For example, a returned root containing spaces:
 
 ```text
 run independently (argv): ["/installation with spaces/delegate","--root","/state with spaces","scheduler","serve"]
@@ -280,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).
@@ -390,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/plugins/delegation-layer/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."