@sgtbeatdown/pi-tasks 0.1.5 → 0.1.7

package/README.md

@@ -1,10 +1,10 @@
 # pi-tasks
 
-`pi-tasks` is a Pi extension client for Wolfpack task transports. The default v2 adapter keeps endpoint-owned Pi task state locally and uses Wolfpack as a content-blind relay; the retained v1 adapter uses Wolfpack's machine-global `~/.wolfpack/tasks` store. Neither adapter writes assignments to terminals. Wolfpack's [relay v2 control-api contract](https://github.com/almogdepaz/wolfpack/blob/main/docs/control-api-schema.md#pi-tasks-relay-v2-boundary) is canonical for the default transport, while its [task gateway guide](https://github.com/almogdepaz/wolfpack/blob/main/docs/task-gateway.md) documents the explicit v1 compatibility transport.
+`pi-tasks` is an endpoint-owned Pi extension for Wolfpack relay v2. It keeps task state in each Pi endpoint's local SQLite store and uses Wolfpack as a content-blind relay. It never writes assignments to terminals. Wolfpack's [relay v2 control-api contract](https://github.com/almogdepaz/wolfpack/blob/main/docs/control-api-schema.md#pi-tasks-relay-v2-boundary) is canonical for the transport boundary.
 
-## v2 endpoint-owned relay
+## endpoint-owned relay
 
-The default extension uses the configured local Wolfpack relay v2 adapter, never the in-memory conformance relay. It registers an opaque endpoint with `POST /api/task-relay/v2/connect`, stores endpoint-owned task state at the deterministic per-session path `~/.pi/tasks/v2/sessions/<sha256(WOLFPACK_SESSION_NAME)>/tasks.sqlite`, and exchanges opaque relay envelopes through Wolfpack. The adapter needs a Wolfpack release exposing the stable [relay v2 control-api contract](https://github.com/almogdepaz/wolfpack/blob/main/docs/control-api-schema.md#pi-tasks-relay-v2-boundary); a v1-only gateway is incompatible and does not silently fall back.
+The default extension uses the configured local Wolfpack relay, never the in-memory conformance relay. It registers an opaque endpoint with `POST /api/task-relay/v2/connect`, stores task state at the deterministic per-session path `~/.pi/tasks/v2/sessions/<sha256(WOLFPACK_SESSION_NAME)>/tasks.sqlite`, and exchanges opaque relay envelopes through Wolfpack. The adapter requires a Wolfpack release exposing the stable [relay v2 control-api contract](https://github.com/almogdepaz/wolfpack/blob/main/docs/control-api-schema.md#pi-tasks-relay-v2-boundary).
 
 Set `WOLFPACK_SESSION_NAME` for every Pi process. The adapter uses `WOLFPACK_PORT` when the local control port differs from `18790`; `WOLFPACK_SESSION_NAME` resolves the active Pi process to its relay endpoint. After the target extension registers, run `wolfpack session status <session> --json` and read its `taskEndpoint`. Pass that opaque `{ relay, id }` value unchanged; do not derive it from a session name, broker ID, terminal label, output, or prose.
 
@@ -20,107 +20,42 @@ Set `WOLFPACK_SESSION_NAME` for every Pi process. The adapter uses `WOLFPACK_POR
 }
 ```
 
-The default `agent_task_send` schema is exactly `to`, `task`, and optional `timeoutMs`. v1-only context, role, metadata, preflight, idempotency, and completion-prompt fields are not silently accepted or translated.
+The `agent_task_send` schema is exactly `to`, `task`, and optional `timeoutMs`. Unsupported fields are rejected before persistence: a pre-persistence validation rejection creates no task. If creation status is uncertain after a transport failure, idempotency remains necessary; inspect the structured task ID rather than creating an unrelated replacement.
 
-Wolfpack's relay owns durable mailbox delivery and peer forwarding; Pi owns task lifecycle, logical event order, receipts, and its local SQLite state. `agent_task_send` returns after relay acceptance only, not Pi insertion or model execution. The receiver inserts model-visible events as structured `pi-tasks-event` custom messages through Pi's safe `deliverAs: "followUp"` queue and records structured `{ taskId, eventId }` insertion evidence. Replay after Pi has structurally recorded an event cannot create an additional logical receipt. `createInMemoryTaskRelay` remains exported solely as a deterministic conformance fixture.
+Wolfpack owns durable mailbox delivery and peer forwarding; Pi owns lifecycle, logical event order, receipts, and local SQLite state. `agent_task_send` returns after relay acceptance only, not Pi insertion or model execution. The receiver inserts model-visible events as structured `pi-tasks-event` custom messages through Pi's safe `deliverAs: "followUp"` queue and records structured `{ taskId, eventId }` insertion evidence. Replay after Pi has structurally recorded an event cannot create another logical receipt. `createInMemoryTaskRelay` remains exported solely as a deterministic conformance fixture.
 
-### v2 delegation workflow
+## delegation workflow
 
-1. create or select a role session. For a disposable worker, omit an initial model prompt: `wolfpack agent spawn <project> --name <task-role> --json`. Put all worker instructions in `agent_task_send.task` so the new Pi process can become idle before assignment.
+Configure Pi role models with `WOLFPACK_IMPLEMENTER_MODEL` and `WOLFPACK_REVIEWER_MODEL`; they default to `openai-codex/gpt-5.6-terra` and `openai-codex/gpt-5.6-sol`. Explicit user or project choices override those defaults.
+
+```bash
+IMPLEMENTER_MODEL="${WOLFPACK_IMPLEMENTER_MODEL:-openai-codex/gpt-5.6-terra}"
+REVIEWER_MODEL="${WOLFPACK_REVIEWER_MODEL:-openai-codex/gpt-5.6-sol}"
+```
+
+1. create or select a role session. For a disposable worker, omit an initial assignment prompt and pass the resolved role model: `wolfpack agent spawn <project> --name <task-role> --model "$IMPLEMENTER_MODEL" --json` (or `"$REVIEWER_MODEL"` for review). Put all worker instructions in `agent_task_send.task` so the new Pi process can become idle before assignment.
 2. verify structured session readiness, wait for extension registration, and read `taskEndpoint` from `wolfpack session status <session> --json`.
-3. call `agent_task_send` with that endpoint and the complete task instructions. Keep working; use `agent_task_status` or `agent_task_inbox` for structured evidence, and call `agent_task_wait` only when the user explicitly asks to block.
+3. call `agent_task_send` with that endpoint and the complete instructions. Keep working; use `agent_task_status` or `agent_task_inbox` for structured evidence, and call `agent_task_wait` only when explicitly asked to block.
 4. use `agent_task_message` for durable questions, answers, and information. The receiver calls `agent_task_done` as its final action; no completion prose follows.
 5. independently verify the result, call `agent_task_ack({ taskId })` once for that terminal task, then explicitly retain or close only the role sessions the parent spawned.
 
-### v2 worker-only execution gate
+Coordinator-capable agents may delegate further when justified, and the spawning coordinator owns each child's lifecycle. After terminal completion and acknowledgment, deliberately retain the child or run `wolfpack kill <stable-session-id> --json`, then verify that exact ID is absent from `wolfpack list --json`. Never use `wolfpack session send`, `/exit`, or `/quit` for cleanup; terminal input is not Wolfpack teardown.
 
-Set `PI_TASK_WORKER=1` only when launching a task-only worker. The exact value enables a fail-closed model `tool_call` gate; an absent value or any other value leaves ordinary interactive Pi behavior unchanged. Before assignment, only `agent_task_inbox`, `agent_task_status`, and `agent_task_wait` are allowed. Other current and future model tools are blocked with the stable reason `PI_TASK_WORKER_ASSIGNMENT_REQUIRED`. Explicit user `!`/`!!` shell commands are outside Pi's model `tool_call` event and are not intercepted.
+## worker-only execution gate
 
-`PI_TASK_WORKER=1` sessions are leaf roles. Workers cannot call `agent_task_send`; workers cannot call `agent_task_cancel`; workers cannot call `agent_task_ack`. These coordinator-tool attempts are blocked with the stable reason `PI_TASK_WORKER_COORDINATION_FORBIDDEN`, not the pre-assignment reason. `agent_task_message` is limited to the eligible incorporated assignment named by its input `taskId`. Generic role-orchestration guidance applies only to non-worker coordinators.
+Set `PI_TASK_WORKER=1` only when launching a task-only worker. The exact value enables a fail-closed model `tool_call` gate; an absent value or any other value leaves ordinary interactive Pi behavior unchanged. Before assignment, only `agent_task_inbox`, `agent_task_status`, and `agent_task_wait` are allowed. Other current and future model tools are blocked with `PI_TASK_WORKER_ASSIGNMENT_REQUIRED`. Explicit user `!`/`!!` shell commands are outside Pi's model `tool_call` event and are not intercepted.
+
+`PI_TASK_WORKER=1` sessions are leaf roles. Workers cannot call `agent_task_send`, `agent_task_cancel`, or `agent_task_ack`; those attempts are blocked with `PI_TASK_WORKER_COORDINATION_FORBIDDEN`. `agent_task_message` is limited to the eligible incorporated assignment named by its input `taskId`. Generic role-orchestration guidance applies only to non-worker coordinators.
 
 The gate opens only when the current Pi session contains a structured `pi-tasks-event` entry for `task.created` and the same event belongs to a locally persisted active task targeted to the current endpoint. Rendered prompt text, terminal output, unknown events, foreign tasks, and stale terminal tasks do not authorize execution. On restart, durable session evidence reopens the gate only while the matching local task remains eligible.
 
 Preflighting `agent_task_done` marks that task as closing before sibling calls are preflighted. Ordinary tools remain blocked for a closing, pending-terminal, accepted-terminal, or `delivery_blocked` task; an idempotent `agent_task_done` retry for that same assigned task remains allowed. Another independently active assignment can still authorize work.
 
-### v2 terminal delivery and acknowledgment
-
-A receiver task snapshot reports terminal transport separately as `terminalDelivery`: `not_submitted`, `pending`, `accepted`, or `delivery_blocked`. The blocked variant includes the stable intent/envelope identities, origin endpoint, timestamp, and structured non-retryable relay error. Canonical task `status` remains origin-owned and is never changed to `delivery_blocked`. Retryable failures keep the same pending terminal intent and envelope; permanent failures remain inspectable and are not rebound to a successor endpoint without a separate authenticated Wolfpack contract.
-
-`agent_task_ack` is valid only for a terminal origin-owned task. Sequential, concurrent, and restart retries reuse one durable `task.parent_acknowledged` event and the same destination envelope identities while still retrying any pending physical delivery.
-
-## v1 gateway adapter (retained)
-
-The v1 gateway client is available only through the published `@sgtbeatdown/pi-tasks/v1-compat-extension` entry. This is an explicit opt-in: after resolving the installed package root, add `src/v1-compat-extension.ts` as an extension path in Pi settings instead of loading the package default. The package manifest loads only `src/extension.ts` (v2); v2 does not fall back to v1 when its relay is unavailable or incompatible. Its v1 behavior and operational requirements are documented below.
-
-## requirements and trust boundary
-
-- a reachable local Wolfpack v1 task gateway on every participating machine;
-- this package loaded in every participating Pi process;
-- `WOLFPACK_SESSION_NAME` set by Wolfpack so the local gateway can resolve the caller to a stable broker ID; and
-- `WOLFPACK_PORT` when the local control port is not the default `18790`.
-
-The boundary is trusted local processes and trusted Tailnet machines. Pi only calls its own local gateway. The gateways perform direct fetch federation; Pi never fetches a peer directly. v1 adds no task capability authentication. Normal Wolfpack global JWT behavior is not bypassed, and JWT federation is unsupported: peer delivery fails clearly when credentials would be required.
-
-## task address and send
-
-A target is always `{ machine, sessionId }`, where `sessionId` is the stable opaque broker ID returned by Wolfpack session control. Use `machine: "local"` for same-machine work. For a peer, use the receiver's canonical HTTPS Tailnet origin, for example `https://worker.example.ts.net`; do not supply a hostname label, path, query, fragment, credentials, unexpected port, or arbitrary HTTPS URL.
-
-```json
-{
-  "to": { "machine": "local", "sessionId": "receiver-broker-id" },
-  "task": "implement the narrow change and run focused tests",
-  "context": {
-    "summary": "## constraints and preferences\n- keep scope narrow\n## key decisions\n- preserve the public contract",
-    "refs": [{ "path": "src/extension.ts", "purpose": "affected tool wiring" }]
-  },
-  "metadata": { "phaseId": "phase-1", "issueId": "task-3", "verificationTier": "focused" },
-  "onCompletePrompt": "review the receiver diff before reporting completion",
-  "timeoutMs": 1800000
-}
-```
-
-### v1 minimal valid send envelope
-
-```json
-{
-  "to": {
-    "machine": "local",
-    "sessionId": "receiver-broker-id"
-  },
-  "task": "implement the narrow change and run focused tests"
-}
-```
-
-`INVALID_REQUEST.error.path` is an optional RFC 6901 JSON Pointer to the rejected send field, for example `/preflight/requiredProject`; use it rather than parsing error prose. A pre-persistence validation rejection creates no task, so correct the field and retry. If creation status is uncertain, idempotency remains necessary.
-
-Remote addressing changes only `to.machine`:
-
-```json
-{ "to": { "machine": "https://worker.example.ts.net", "sessionId": "receiver-broker-id" }, "task": "review the cited diff" }
-```
-
-Context is optional, curated Markdown plus deliberately selected ref metadata. The extension renders refs but never reads or copies their contents. Relative refs resolve in the receiver project; absolute refs are same-machine only and must remain inside the authoritative parent or receiver project root. Missing refs are warnings, not copied content or transcript transfer.
-
-Initial limits are 16 KiB UTF-8 each for task instructions and context summary, 48 KiB for the assignment envelope, and 64 KiB for an HTTP request body. The initial size limits require representative payload benchmarking before adjustment.
-
-`agent_task_send` waits for durable gateway acceptance, not adapter insertion or task execution; delivery remains pending until `task.delivered`. A remote initial send has one initial attempt: the receiver persists a provisional receipt, then receives sender confirmation before Pi can see the assignment. Later peer confirmation, messages, terminal updates, cancellation, delivery notices, and parent acknowledgment have four total attempts: the initial attempt plus retries around 1, 2, and 4 seconds with jitter. Exhaustion is a visible local delivery failure, not a background queue or offline dispatch promise.
-
-Normal delegation is fire-and-forget. Use `agent_task_wait` only when the user explicitly asks to block.
-
-## tools, messages, and acknowledgment
+## terminal delivery and acknowledgment
 
-| tool | purpose |
-| --- | --- |
-| `agent_task_send` | create a durable gateway assignment |
-| `agent_task_status` | read task state, history, result, and warnings |
-| `agent_task_wait` | explicitly poll a task until terminal or timeout |
-| `agent_task_inbox` | read task events without acknowledgment |
-| `agent_task_ack` | acknowledge one independently verified terminal task |
-| `agent_task_message` | send a durable `question`, `answer`, or `information` event |
-| `agent_task_cancel` | request cancellation |
-| `agent_task_done` | receiver-only terminal completion; terminates the tool turn |
+A receiver task snapshot reports terminal transport separately as `terminalDelivery`: `not_submitted`, `pending`, `accepted`, or `delivery_blocked`. The blocked variant includes stable intent/envelope identities, origin endpoint, timestamp, and structured non-retryable relay error. Canonical task `status` remains origin-owned and is never changed to `delivery_blocked`. Retryable failures keep the same pending terminal intent and envelope; permanent failures remain inspectable and are not rebound to a successor endpoint without a separate authenticated Wolfpack contract.
 
-Use `agent_task_message` for clarification instead of terminal prose. Only one question can be unresolved per task; answers link to that question. Information is durable and does not change task state. An accepted receiver question terminates that receiver turn; a parent question does not.
+`agent_task_ack` is valid only for a terminal origin-owned task. Sequential, concurrent, and restart retries reuse one durable `task.parent_acknowledged` event and the same destination envelope identities while retrying pending physical delivery.
 
 Report source modifications in `result.changedFiles`. Artifacts are receiver-project-relative regular files for a parent to inspect, not a changed-file list:
 
@@ -128,36 +63,6 @@ Report source modifications in `result.changedFiles`. Artifacts are receiver-pro
 { "result": { "changedFiles": ["src/extension.ts"] }, "artifacts": [{ "path": "verification/task-2.md" }] }
 ```
 
-See the canonical Wolfpack artifact contract for provenance, containment, and warning behavior.
-
-The sender gateway owns canonical event order, timeout, and terminal state. The first accepted terminal event wins. Sender timeout triggers best-effort remote cancellation; late terminals remain diagnostics. After independently verifying one terminal result, call `agent_task_ack({ taskId })`. Remote acknowledgment is two-phase: the receiver durably confirms pending acknowledgment before the sender records final parent acknowledgment. If that delivery fails, the task remains visible and a later explicit acknowledgment repairs it with the same event ID.
-
-## structured delivery and replay
-
-The extension polls the local gateway every five seconds. With no pending message, it submits each visible event as a structured custom message using Pi's safe `deliverAs: "followUp"` mode: idle Pi starts immediately, while an active turn finishes before the queued event starts the next turn. It never steers or interrupts active work. Delivery remains pending until `task.delivered`. The `{ taskId, eventId }` details let task context participate in the session without parsing prose.
-
-On start or resume it rebuilds incorporated IDs from the full durable session entry set, not only active prompt context. A session gets only missing events; a new Pi session in the same Wolfpack PTY gets complete active history. The receiver records gateway delivery only after the structured insertion exists. A restart after insertion and before acknowledgment therefore acknowledges the existing entry without duplicate injection. Unknown model-visible events fail closed without advancing the cursor. Gateway delivery is at-least-once; this does not claim exactly-once model execution.
-
-## parent workflow
-
-1. create or select a Wolfpack Pi session with the canonical session-control workflow and retain its stable broker ID. Spawn a disposable worker without an initial model prompt using `wolfpack agent spawn <project> --name <task-role> --json` so it reaches idle before assignment; put worker instructions in `agent_task_send.task`.
-2. before remote dispatch, complete Wolfpack's [Live-peer readiness checklist](https://github.com/almogdepaz/wolfpack/blob/main/docs/task-gateway.md#live-peer-readiness-checklist) and retain operator-recorded package/reload evidence; only then check the target's local requirements and send compact instructions with curated context and selected refs when they save receiver investigation.
-3. keep working; use `agent_task_status` or `agent_task_inbox` for structured follow-up, and `agent_task_message` for questions, answers, and decisions.
-4. verify cited files, diffs, tests, and paths-only artifact metadata independently before reporting success.
-5. acknowledge the accepted terminal result, then clean up only sessions this parent spawned. Keep a reusable implementer alive while review or correction remains possible; never make workers close their own sessions.
-
-Isolated coverage is the deterministic acceptance gate, but a specific live peer still requires current readiness at the time of use. If the checklist cannot pass, stop before task creation and report fixture-only verification. Do not use direct peer URLs from Pi.
-
-See `skills/wolfpack-pi-task-delegation/SKILL.md` for the operational workflow and `skills/task-context-summary/SKILL.md` for recovery/reuse summaries.
-
-## deferred follow-up
-
-These are documented operational debt, not production TODOs: exact Pi runtime registration and heartbeat/capability leases; durable offline initial dispatch; JWT/authenticated peer federation; artifact byte transfer and retention; representative payload benchmarking; automated recovery summaries; and summary caching only after measured repeated-generation waste. v1 has no queue, scheduler, artifact transfer, or transcript transfer.
-
-## legacy historical metrics
-
-`task-metrics` and the task board remain read-only analyzers for already-existing historical `.pi/tasks` directories. They are not part of the runtime task protocol and must not create, mutate, or deliver v1 gateway tasks. Replacing or retiring that historical reporting surface requires a product decision about gateway-wide query/metrics ownership.
-
 ## development
 
 ```bash

package/package.json

@@ -1,11 +1,10 @@
 {
   "name": "@sgtbeatdown/pi-tasks",
-  "version": "0.1.5",
-  "description": "Durable Pi agent delegation through the Wolfpack task gateway.",
+  "version": "0.1.7",
+  "description": "Durable endpoint-owned Pi agent delegation through Wolfpack relay v2.",
   "module": "src/index.ts",
   "exports": {
-    ".": "./src/index.ts",
-    "./v1-compat-extension": "./src/v1-compat-extension.ts"
+    ".": "./src/index.ts"
   },
   "repository": {
     "type": "git",
@@ -50,7 +49,6 @@
   },
   "scripts": {
     "test": "bun test",
-    "task-metrics": "bun src/metrics-cli.ts",
     "typecheck": "tsc --noEmit"
   },
   "type": "module"

package/skills/wolfpack-pi-task-delegation/SKILL.md

@@ -7,27 +7,49 @@ description: Use when opening, selecting, delegating to, checking, or cleaning u
 
 use `wolfpack-tailnet-control` for session control. this skill covers endpoint-owned v2 task lifecycle, structured handoffs, and parent verification. The package default is the v2 extension described by Wolfpack's [relay v2 control-api contract](https://github.com/almogdepaz/wolfpack/blob/main/docs/control-api-schema.md#pi-tasks-relay-v2-boundary).
 
+## choose one assignment mode
+
+choose exactly one mode for the initial assignment:
+
+- **full-startup mode:** spawn with the complete `--plan`, `--prompt-file`, or concise `--prompt`. do not call `agent_task_send` for that same work.
+- **endpoint mode:** spawn without a startup plan or prompt, obtain the structured `taskEndpoint`, then put the complete assignment in one `agent_task_send.task`.
+
+never combine a plan-driven spawn with a narrower endpoint task. prefer one cohesive implementation handoff per approved PR or phase; split only at a real approval, design, isolation, or blocker boundary—not per issue, commit, finding, or verification checkpoint. the remaining v2 workflow below describes endpoint mode.
+
+## role model selection
+
+Pi role models are explicit and configurable at spawn time:
+
+```bash
+IMPLEMENTER_MODEL="${WOLFPACK_IMPLEMENTER_MODEL:-openai-codex/gpt-5.6-terra}"
+REVIEWER_MODEL="${WOLFPACK_REVIEWER_MODEL:-openai-codex/gpt-5.6-sol}"
+```
+
+Pass `--model "$IMPLEMENTER_MODEL"` when spawning the editing implementer and `--model "$REVIEWER_MODEL"` when spawning the read-only reviewer. an explicit user or project model choice overrides the environment/default. never infer role or model from the session name, and never omit the resolved model because the current parent default may differ.
+
 ## v2 requirements and addressing
 
 - load this package's default extension in every participating Pi process and set `WOLFPACK_SESSION_NAME`. Set `WOLFPACK_PORT` only when the local Wolfpack control port differs from `18790`.
 - address `agent_task_send` targets only as `to: { relay, id }`. For the default Wolfpack adapter, the relay is `wolfpack-pi-tasks-v2` and the ID is opaque.
-- create a disposable worker without an initial model prompt: `wolfpack agent spawn <project> --name <task-role> --json`. Do not start a disposable worker with a blocking “wait for assignments” prompt. Put the complete instructions in `agent_task_send.task`.
+- create a disposable worker without an initial assignment prompt: `wolfpack agent spawn <project> --name <task-role> --model "$IMPLEMENTER_MODEL" --json` (or `"$REVIEWER_MODEL"` for review). Do not start a disposable worker with a blocking “wait for assignments” prompt. Put the complete instructions in `agent_task_send.task`.
 - after the target extension registers, run structured session control (`wolfpack session status <session> --json`) and read its `taskEndpoint`. Do not derive endpoint IDs from session names, broker IDs, terminal labels, output, or prose.
 - pass the returned endpoint without translation:
 
 ```json
 {
   "to": { "relay": "wolfpack-pi-tasks-v2", "id": "target-opaque-endpoint-id" },
-  "task": "implement the narrow change and run focused tests",
-  "timeoutMs": 1800000
+  "task": "implement the approved phase and run focused tests",
+  "timeoutMs": 3600000
 }
 ```
 
-The default `agent_task_send` schema is exactly `to`, `task`, and optional `timeoutMs`. v1-only fields such as context, role, metadata, preflight, idempotency keys, and completion prompts are not silently accepted or translated.
+The default `agent_task_send` schema is exactly `to`, `task`, and optional `timeoutMs`. Unsupported fields are rejected rather than translated. use at least `3600000` milliseconds for coding assignments; timeout is a failure deadline, not a progress-poll interval.
 
 ## phase roles and handoffs
 
-For a multi-step project phase, retain one persistent implementer and one persistent read-only reviewer. Reuse a healthy role session for corrections and follow-up review; a completed task finishes one assignment, not the underlying session. Do not rotate a healthy role session for routine corrections. Rotate only for phase completion, material context degradation, harness failure, or required specialist independence. Keep at most one active assignment per role unless the user explicitly approves parallel work.
+For a multi-step project phase, retain one persistent implementer and one persistent read-only reviewer. Give the implementer the whole approved phase, including required commit ordering and focused verification, rather than opening one task per issue or checkpoint. Reuse a healthy role session for corrections and follow-up review; a completed task finishes one assignment, not the underlying session. Do not rotate a healthy role session for routine corrections. Rotate only for phase completion, material context degradation, harness failure, or required specialist independence. Keep at most one active assignment per role unless the user explicitly approves parallel work.
+
+A coordinator-capable agent may delegate further when the quality or throughput gain justifies it. The spawning coordinator owns each child's complete lifecycle: record the stable session ID, acknowledge its terminal task once, then deliberately retain the child or close it with `wolfpack kill <stable-session-id> --json` and verify that exact ID is absent from `wolfpack list --json`.
 
 `PI_TASK_WORKER=1` sessions are leaf roles. Workers cannot call `agent_task_send`; workers cannot call `agent_task_cancel`; workers cannot call `agent_task_ack`. These coordinator-tool attempts are blocked with the stable reason `PI_TASK_WORKER_COORDINATION_FORBIDDEN`, not the pre-assignment reason. They may use `agent_task_message` only for the eligible incorporated assignment named by its input `taskId`. Generic role-orchestration guidance applies only to non-worker coordinators. Task workers must not create, rotate, or close Wolfpack sessions through shell or session-control tools.
 
@@ -40,17 +62,17 @@ After every verified and acknowledged terminal task, explicitly retain a parent-
 | assignment completion | worker | `agent_task_done` | unchanged |
 | task acknowledgment | parent | `agent_task_ack` | unchanged |
 | role session retention | parent | `none` | retained for reuse |
-| role session teardown | parent | `wolfpack kill <session-or-id> --json` | exact stable session id terminated |
-| teardown verification | parent | `wolfpack list --json` | exact stable session id absent |
-| Pi exit | none | `/quit` | not Wolfpack teardown |
+| role session teardown | spawning coordinator | `wolfpack kill <stable-session-id> --json` | exact stable session id terminated |
+| teardown verification | spawning coordinator | `wolfpack list --json` | exact stable session id absent |
+| Pi exit | none | `/exit` or `/quit` | not Wolfpack teardown |
 
-Assignment completion ends the assigned task, not the reusable role session. When no further reuse is likely, the parent—not the worker—must pass the exact stable session ID to `wolfpack kill <session-or-id> --json`, then inspect `wolfpack list --json` and verify that ID is absent. `/quit` exits Pi; it is not Wolfpack teardown. Workers never close themselves.
+Assignment completion ends the assigned task, not the reusable role session. When no further reuse is likely, the coordinator that spawned the role—not the worker itself—must pass the exact stable session ID to `wolfpack kill <stable-session-id> --json`, then inspect `wolfpack list --json` and verify that ID is absent. Never use `wolfpack session send`, `/exit`, or `/quit` for cleanup: they are terminal interaction, not Wolfpack teardown. Do not guess lifecycle commands. Workers never close themselves.
 
 ## v2 workflow
 
 1. create or select the role session, verify its structured project and terminal readiness, then obtain its registered `taskEndpoint`.
 2. call `agent_task_send` with the opaque endpoint and concise instructions in `task`. The tool returns after relay acceptance only, not Pi insertion or model execution. If submission reports a retryable delivery error after local persistence, use the structured task ID from the error and inspect it rather than creating an unrelated replacement.
-3. keep working. Use `agent_task_status` or `agent_task_inbox` for structured evidence. Call `agent_task_wait` only when the user explicitly asks to block.
+3. keep working. Use `agent_task_status` or `agent_task_inbox` only at meaningful checkpoints or when progress evidence is needed; do not turn status checks into lifecycle chatter. Call `agent_task_wait` only when the user explicitly asks to block.
 4. use `agent_task_message` for durable `question`, `answer`, or `information` flow. Do not use rendered text, terminal output, or logs as lifecycle evidence.
 5. assignees call `agent_task_done` as their final action with the assigned task ID, terminal status, concise summary, and optional structured result, error, and artifact declarations. Report source modifications in `result.changedFiles`; artifacts are receiver-project-relative regular files for a parent to inspect, not changed-file lists: `{ "result": { "changedFiles": ["src/extension.ts"] }, "artifacts": [{ "path": "verification/task-2.md" }] }`. No prose completion afterward.
 6. the parent independently verifies files, diff, tests, and artifacts. Then call `agent_task_ack({ taskId })` for that one terminal task and explicitly retain or close the spawned role session.
@@ -63,21 +85,11 @@ Receiver terminal submission has one task-wide logical identity. Same-status ret
 
 Set `PI_TASK_WORKER=1` only for task-only workers. Before a valid structured assignment matches a locally owned active task, the worker gate allows only inbox/status/wait inspection and blocks other model tools with `PI_TASK_WORKER_ASSIGNMENT_REQUIRED`.
 
-## v1 compatibility
-
-The retained v1 workflow is available only through the explicit `@sgtbeatdown/pi-tasks/v1-compat-extension` entrypoint. It does not load by default, and v2 never falls back or translates its targets.
-
-v1 uses a reachable local Wolfpack task gateway and addresses targets as `to: { machine, sessionId }`. Use `machine: "local"` for same-machine work; remote work uses only the receiver's canonical HTTPS Tailnet origin. v1 trusts local processes and trusted Tailnet machines, has no JWT federation, and follows Wolfpack's [task gateway guide](https://github.com/almogdepaz/wolfpack/blob/main/docs/task-gateway.md).
-
-Before v1 remote dispatch, complete the [Live-peer readiness checklist](https://github.com/almogdepaz/wolfpack/blob/main/docs/task-gateway.md#live-peer-readiness-checklist), including operator-recorded package/reload evidence. If it cannot pass, stop before task creation and report fixture-only verification. Isolated coverage is the deterministic acceptance gate, but it does not prove a specific live peer.
-
-Only v1 supports curated `context.summary`/refs, role, metadata, preflight, idempotency keys, and completion prompts. Use `context.summary` only for constraints, decisions, and recovery state. Refs are metadata, not copied files or transcript. A v1 remote initial send gets one initial attempt; later peer events get four total attempts. Retry exhaustion is surfaced; v1 has no offline queue or background dispatch promise.
-
 ## do not
 
 - do not use terminal output, rendered prompts, logs, or error prose as task state.
 - do not ask workers to complete in prose or close their own sessions.
 - do not steer or interrupt an active Pi turn with task context; use the adapter's follow-up queue.
 - Do not copy plans, source contents, or transcripts into task context.
-- do not mix v1 and v2 target shapes or silently translate between them.
+- do not derive or transform opaque endpoint IDs.
 - do not promise JWT federation, artifact byte transfer, exactly-once model execution, or successor endpoint rebinding.

package/src/extension.ts

@@ -5,9 +5,9 @@ import { Type } from "typebox";
 
 import { abortableSleep } from "./abortable-sleep";
 import { deliverTaskInbox, incorporatedTaskEvents } from "./task-inbox";
-import { TaskOutboxDeliveryError, TaskProtocolError } from "./task-protocol";
+import { TaskDeliveryEvidenceState, TaskDeliveryStage, TaskOutboxDeliveryError, TaskProtocolError } from "./task-protocol";
 import { createWolfpackTaskCore } from "./wolfpack-task-relay";
-import type { TaskCore } from "./task-core";
+import type { SubmitIntentInput, SubmitIntentOutcome, TaskCore } from "./task-core";
 import type { TaskEndpoint, TaskSnapshot } from "./task-protocol";
 
 const DEFAULT_TASK_TIMEOUT_MS = 30 * 60 * 1_000;
@@ -64,7 +64,6 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 	let inboxContext: ExtensionContext | undefined;
 	let backgroundTimer: ReturnType<typeof setInterval> | undefined;
 	let lifecycleEpoch = 0;
-	const pendingInsertions = new Set<string>();
 	const closingTaskIds = new Set<string>();
 	const workerGateEnabled = process.env.PI_TASK_WORKER === "1";
 	const configuredCore: ConfiguredCoreFactory = core === undefined ? createConfiguredCoreLoader(createCore) : async (): Promise<TaskCore> => core;
@@ -104,9 +103,10 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 			sendMessage(message, options) { if (isCurrent()) pi.sendMessage(message, options); },
 			appendEntry(customType, data) { if (isCurrent()) pi.appendEntry(customType, data); },
 		}, guardedCore, {
+			isIdle: (): boolean => isCurrent() && context.isIdle(),
 			hasPendingMessages: (): boolean => !isCurrent() || context.hasPendingMessages(),
 			sessionManager: context.sessionManager,
-		}, pendingInsertions, signal);
+		}, signal);
 		return outboxError;
 	});
 	const refreshLifecycle = async (context: ExtensionContext, epoch: number): Promise<void> => {
@@ -157,7 +157,6 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 	});
 
 	pi.on("session_start", async (_event, context) => {
-		pendingInsertions.clear();
 		closingTaskIds.clear();
 		const epoch = ++lifecycleEpoch;
 		inboxContext = context;
@@ -173,8 +172,12 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 		inboxContext = context;
 		await refreshLifecycle(context, epoch);
 	});
+	pi.on("agent_settled", async (_event, context) => {
+		const epoch = lifecycleEpoch;
+		inboxContext = context;
+		await refreshLifecycle(context, epoch);
+	});
 	pi.on("session_shutdown", () => {
-		pendingInsertions.clear();
 		closingTaskIds.clear();
 		lifecycleEpoch += 1;
 		if (backgroundTimer) clearInterval(backgroundTimer);
@@ -194,10 +197,13 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 	});
 	pi.registerTool({
 		name: "agent_task_status", label: "Task Status", description: "Read local endpoint-owned task state; status is unavailable while its origin is offline.", parameters: TaskIdParams,
-		async execute(_id, params, signal) {
+		async execute(_id, params, signal, _onUpdate, context) {
 			try {
-				const task = (await configuredCore(signal)).getTask(params.taskId);
-				return task ? toolResult(task, `## task status\n- task: \`${task.taskId}\`\n- status: ${task.status}`) : taskError(new Error("unknown local task"));
+				const activeCore = await configuredCore(signal);
+				const task = activeCore.getTask(params.taskId);
+				if (!task) return taskError(new Error("unknown local task"));
+				const deliveryEvidence = taskDeliveryEvidence(task);
+				return toolResult({ ...task, deliveryEvidence }, `## task status\n- task: \`${task.taskId}\`\n- status: ${task.status}${receiverAssignment(activeCore, task, context)}${deliveryEvidenceText(deliveryEvidence)}`);
 			} catch (error) { return taskError(error); }
 		}, renderResult(result, _options, theme) { return new Text(theme.fg("accent", text(result))); },
 	});
@@ -220,11 +226,12 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 	});
 	pi.registerTool({
 		name: "agent_task_inbox", label: "Task Inbox", description: "Read local task records after processing relay deliveries without acknowledging task lifecycle.", parameters: Type.Object({}),
-		async execute(_id, _params, signal) {
+		async execute(_id, _params, signal, _onUpdate, context) {
 			try {
 				await refreshInbox(signal);
-				const tasks = (await configuredCore(signal)).listTasks();
-				return toolResult({ tasks }, `## task inbox\n${tasks.map((task) => `- \`${task.taskId}\`: ${task.status}`).join("\n") || "- empty"}`);
+				const activeCore = await configuredCore(signal);
+				const tasks = activeCore.listTasks();
+				return toolResult({ tasks }, `## task inbox\n${tasks.map((task) => `- \`${task.taskId}\`: ${task.status}${receiverAssignment(activeCore, task, context)}`).join("\n") || "- empty"}`);
 			} catch (error) { return taskError(error); }
 		},
 		renderResult(result, _options, theme) { return new Text(theme.fg("accent", text(result))); },
@@ -258,8 +265,32 @@ export function registerAgentTaskTools(pi: ExtensionAPI, core: TaskCore | undefi
 		name: "agent_task_done", label: "Complete Agent Task", description: "Persist a terminal task intent before relay submission.", parameters: DoneParams,
 		async execute(_id, params, signal) {
 			try {
-				await (await configuredCore(signal)).submitIntent({ taskId: params.taskId, type: `task.${params.status}`, payload: { summary: params.summary, ...(params.result === undefined ? {} : { result: params.result }), ...(params.error === undefined ? {} : { error: params.error }), ...(params.artifacts === undefined ? {} : { artifacts: params.artifacts }) } }, signal);
-				return { ...toolResult({ taskId: params.taskId }, `## task ${params.status}\n- task: \`${params.taskId}\`\n- ${params.summary}`), terminate: true };
+				const activeCore = await configuredCore(signal);
+				let submission: SubmitIntentOutcome | undefined;
+				try {
+					const input: SubmitIntentInput = { taskId: params.taskId, type: `task.${params.status}`, payload: { summary: params.summary, ...(params.result === undefined ? {} : { result: params.result }), ...(params.error === undefined ? {} : { error: params.error }), ...(params.artifacts === undefined ? {} : { artifacts: params.artifacts }) } };
+					if (activeCore.submitIntentWithOutcome) submission = await activeCore.submitIntentWithOutcome(input, signal);
+					else await activeCore.submitIntent(input, signal);
+				} catch (error) {
+					return blockedDoneResult(activeCore, params.taskId, params.status, error) ?? taskError(error);
+				}
+				const task = activeCore.getTask(params.taskId);
+				if (!task) return taskError(new Error("unknown local task"));
+				if (submission?.authority === "origin" && submission.canonicalEvent.type === "task.late_terminal") {
+					return {
+						...toolResult({ taskId: params.taskId, requestedStatus: params.status, observedCanonicalStatus: task.status, canonicalEvent: submission.canonicalEvent }, `## canonical late terminal recorded\n- task: \`${params.taskId}\`\n- requested status: ${params.status}\n- canonical status remains: ${task.status}\n- ${params.summary}`),
+						terminate: true,
+					};
+				}
+				if (submission?.authority === "origin" && task.status === params.status) {
+					return {
+						...toolResult({ taskId: params.taskId, requestedStatus: params.status, observedCanonicalStatus: task.status, canonicalCompletion: { state: "confirmed", status: task.status } }, `## task ${task.status}\n- task: \`${params.taskId}\`\n- canonical status: ${task.status}\n- ${params.summary}`),
+						terminate: true,
+					};
+				}
+				const deliveryOutcome = task.terminalDelivery.state === "accepted" ? "accepted" : "recorded";
+				const result = toolResult({ taskId: params.taskId, requestedStatus: params.status, observedCanonicalStatus: task.status, terminalDelivery: task.terminalDelivery }, `## terminal intent ${deliveryOutcome}\n- task: \`${params.taskId}\`\n- requested status: ${params.status}\n- observed canonical status: ${task.status}\n- ${params.summary}`);
+				return task.terminalDelivery.state === "accepted" || terminal(task.status) ? { ...result, terminate: true } : result;
 			} catch (error) { return taskError(error); }
 		}, renderResult(result, _options, theme) { return new Text(theme.fg("accent", text(result))); },
 	});
@@ -281,6 +312,37 @@ export default function piTasks(pi: ExtensionAPI): void {
 	registerAgentTaskTools(pi);
 }
 
+interface TaskDeliveryEvidence {
+	readonly receiverPersistence: "not_confirmed" | "confirmed";
+	readonly piInsertion: "not_confirmed" | "blocked" | "confirmed";
+	readonly wakeAcceptance: "not_confirmed" | "pending" | "confirmed";
+	readonly modelExecution: "not_evidenced";
+}
+
+function taskDeliveryEvidence(task: TaskSnapshot): TaskDeliveryEvidence {
+	let receiverPersistence: TaskDeliveryEvidence["receiverPersistence"] = "not_confirmed";
+	let piInsertion: TaskDeliveryEvidence["piInsertion"] = "not_confirmed";
+	let wakeAcceptance: TaskDeliveryEvidence["wakeAcceptance"] = "not_confirmed";
+	const assignmentEventId = task.events.find((event) => event.type === "task.created")?.eventId;
+	for (const event of task.events) {
+		if (event.type !== "task.delivery_receipt" || event.payload.eventId !== assignmentEventId) continue;
+		if (event.payload.stage === TaskDeliveryStage.receiverPersisted) receiverPersistence = "confirmed";
+		if (event.payload.stage === TaskDeliveryStage.piInsertion && event.payload.state === TaskDeliveryEvidenceState.blocked) piInsertion = "blocked";
+		if (event.payload.stage === TaskDeliveryStage.piInserted || event.payload.stage === undefined) {
+			receiverPersistence = "confirmed";
+			piInsertion = "confirmed";
+		}
+		if (event.payload.stage === TaskDeliveryStage.wakeRequested) wakeAcceptance = "pending";
+		if (event.payload.stage === TaskDeliveryStage.wakeAccepted) wakeAcceptance = "confirmed";
+	}
+	return { receiverPersistence, piInsertion, wakeAcceptance, modelExecution: "not_evidenced" };
+}
+
+function deliveryEvidenceText(evidence: TaskDeliveryEvidence): string {
+	const insertion = evidence.piInsertion === "blocked" ? "blocked; retryable" : evidence.piInsertion;
+	return `\n- receiver persistence: ${evidence.receiverPersistence}\n- Pi insertion: ${insertion}\n- wake acceptance: ${evidence.wakeAcceptance}\n- model execution: ${evidence.modelExecution}`;
+}
+
 function toolResult(details: unknown, markdown: string): AgentToolResult<unknown> {
 	return { content: [{ type: "text", text: markdown }], details };
 }
@@ -294,26 +356,41 @@ function taskError(error: unknown): AgentToolResult<unknown> {
 }
 
 function blockedCancellationResult(core: TaskCore, taskId: string, error: unknown): AgentToolResult<unknown> | undefined {
-	if (!(error instanceof TaskOutboxDeliveryError) || error.code !== TARGET_NOT_REGISTERED_CODE || error.retryable || error.details?.taskId !== taskId) return undefined;
+	if (!(error instanceof TaskOutboxDeliveryError) || error.details?.taskId !== taskId) return undefined;
 	const task = core.getTask(taskId);
-	if (task?.status !== "cancelled" || !sameEndpoint(task.origin, core.endpoint)) return undefined;
+	const warning = task === undefined ? undefined : blockedDeliveryWarning(error, task.target);
+	if (task?.status !== "cancelled" || !sameEndpoint(task.origin, core.endpoint) || warning === undefined) return undefined;
+	return toolResult({ taskId, status: "cancelled", warnings: [warning] }, `## task cancelled\n- task: \`${taskId}\`\n- canonical status: cancelled\n- target delivery: blocked; receiver incorporation not confirmed`);
+}
+
+function blockedDoneResult(core: TaskCore, taskId: string, requestedStatus: string, error: unknown): AgentToolResult<unknown> | undefined {
+	if (!(error instanceof TaskOutboxDeliveryError)) return undefined;
+	const task = core.getTask(taskId);
+	if (task === undefined) return undefined;
+	if (!sameEndpoint(task.origin, core.endpoint) && task.terminalDelivery.state === "delivery_blocked" && task.terminalDelivery.intentType === `task.${requestedStatus}`) {
+		return toolResult({
+			taskId,
+			status: task.status,
+			terminalDelivery: task.terminalDelivery,
+			error: { code: error.code, message: error.message, retryable: error.retryable },
+		}, `## terminal intent delivery blocked\n- task: \`${taskId}\`\n- canonical status: ${task.status}\n- canonical completion not confirmed; retry remains allowed`);
+	}
+	const warning = blockedDeliveryWarning(error, task.target);
+	if (!sameEndpoint(task.origin, core.endpoint) || task.status !== requestedStatus || warning === undefined) return undefined;
+	return {
+		...toolResult({ taskId, status: task.status, warnings: [warning] }, `## task ${task.status}\n- task: \`${taskId}\`\n- canonical status: ${task.status}\n- target delivery: blocked; receiver incorporation not confirmed`),
+		terminate: true,
+	};
+}
+
+function blockedDeliveryWarning(error: TaskOutboxDeliveryError, target: TaskEndpoint): Readonly<Record<string, unknown>> | undefined {
+	if (error.code !== TARGET_NOT_REGISTERED_CODE || error.retryable) return undefined;
 	const details = { ...error.details };
 	delete details.taskId;
 	delete details.envelopeId;
 	delete details.target;
 	delete details.blockedAt;
-	return toolResult({
-		taskId,
-		status: "cancelled",
-		warnings: [{
-			code: error.code,
-			message: error.message,
-			retryable: false,
-			delivery: "blocked",
-			target: task.target,
-			details,
-		}],
-	}, `## task cancelled\n- task: \`${taskId}\`\n- canonical status: cancelled\n- target delivery: blocked; receiver incorporation not confirmed`);
+	return { code: error.code, message: error.message, retryable: false, delivery: "blocked", target, details };
 }
 
 function outboxFailureStatus(error: unknown): "tasks: relay unavailable" | "tasks: outbox degraded" {
@@ -324,6 +401,13 @@ function terminal(status: string): boolean {
 	return ["completed", "failed", "cancelled", "timed_out"].includes(status);
 }
 
+function receiverAssignment(core: TaskCore, task: TaskSnapshot, context: Pick<ExtensionContext, "sessionManager">): string {
+	if (task.status !== "active" || sameEndpoint(task.origin, core.endpoint) || !sameEndpoint(task.target, core.endpoint)) return "";
+	const created = task.events.find((event) => event.type === "task.created");
+	if (!created || !incorporatedTaskEvents(context.sessionManager.getEntries()).some((evidence) => evidence.taskId === task.taskId && evidence.eventId === created.eventId)) return "";
+	return `\n\n## task assignment\n${task.task}`;
+}
+
 function assignedWorkerTasks(core: TaskCore, entries: readonly unknown[]): readonly TaskSnapshot[] {
 	const assignments = new Map<string, TaskSnapshot>();
 	for (const evidence of incorporatedTaskEvents(entries)) {

package/src/index.ts

@@ -31,5 +31,5 @@ export type {
 	TaskRecord,
 	TaskRelay,
 } from "./task-protocol";
-export type { TaskCore, TaskCoreOptions } from "./task-core";
+export type { SubmitIntentOutcome, TaskCore, TaskCoreOptions } from "./task-core";
 export type { TaskStore, TaskStoreOptions } from "./task-store";