@gobing-ai/spur 0.3.78 → 0.3.81

package/plugins/sp/skills/doc-evolve/references/operations.md

@@ -15,41 +15,33 @@ it enforces; the skill never invents process.
 
 | Operation | Authority § | What "done" means |
 | --------- | ----------- | ----------------- |
-| drift-audit | §7 | the 8-item §7 checklist run, each backed by a command; report lists deltas (or the zero-delta commands) |
-| sync-check | §5 (T1–T8) | every changed surface mapped to its trigger; the obligated doc confirmed edited in the same change |
+| drift-audit | §7 | the affected §7 checks run, each backed by a command; report lists deltas (or the zero-delta commands) |
+| sync-check | §5 (applicable §5 triggers) | every changed surface mapped to its trigger; the obligated doc confirmed edited in the same change |
 | contract-verify | §4.3 (+ §4.1) | each doc's frontmatter `owns`/`authority` matches its §4.1 row; `updated_at` plausible |
-| lesson-append | §8 | a dedup'd, correctly-formatted dated line in the right per-file section |
+| lesson-append | §8 | a deduplicated lesson in existing learning/context storage, never appended to 99 |
 
 ## drift-audit — §7 checklist → detection commands
 
 | §7 item | Detection (deterministic) | Authoritative doc |
 | ------- | ------------------------- | ----------------- |
-| Real CLI surface vs docs | `rg -n "\.command\('" apps/cli/src/commands/` vs `rg -n '^#### \`spur ' docs/04_DESIGN.md` | `04` + `AGENTS.md` surface, `00` committed-surface |
-| `05` ✅/🔶 spot-check; no ⏳ quietly shipped | `rg -n '✅\|🔶\|⏳\|💤' docs/05_FEATURES.md`, then check each against code | `05` |
+| Real CLI surface vs docs | Compare source-local help/registrations with owning `docs/design/` contracts | `04` satellites |
+| Feature state matches evidence | Read the feature tool's generated index, then inspect affected acceptance evidence | `05` / feature records |
 | Every shipped surface has a `01` scope row | surface set (above) vs `rg` of `01` scope table | `01` |
 | `02` phase bullets name real things | read `02` current-phase bullets; grep each name in code/docs | `02` |
-| `03` modules vs real tree | `fd -t d -d 2 . apps packages` vs `03` module list | `03` |
+| `03` modules vs real tree | `rg --files apps packages` vs `03` module map | `03` |
 | `04` covers every command/flag/config/schema | the verb/flag/config set vs `04` | `04` |
 | `AGENTS.md` doc map == §4.1 | diff the two tables | `AGENTS.md` (§4.4) |
 | frontmatter matches §4.1 + `updated_at` plausible | see contract-verify | each doc (§4.3) |
 
 **Judgment:** is a candidate real drift (vs. an intentional, documented exception)? Which doc is
-authoritative? What is the *minimal* repair (a one-line dated amendment beats a rewrite)?
+authoritative? What is the *minimal* repair (preserve decision history and condense only editorial noise under §6.1)?
 
-## sync-check — T1–T8 → obligations
+## sync-check — applicable §5 triggers → obligations
 
-Read the change (diff or finished task); for each changed path classify the trigger and confirm the
-obligated doc was touched in the same change. The high-frequency miss is **T3** (a CLI/config/schema
-change without the matching `04` + `AGENTS.md` edit) — check it first. (T1–T8 listed in the SKILL.md
-table; this reference is the detection recipe, not a restatement of the triggers.)
-
-```bash
-# Surface changed in this diff?
-git diff --name-only | rg 'apps/cli/src/commands/|packages/.*/schema|config/'
-# Was 04 / AGENTS.md touched in the same diff?
-git diff --name-only | rg 'docs/04_DESIGN.md|^AGENTS.md'
-# Both non-empty → likely synced; surface-changed-but-no-04 → T3 drift.
-```
+Read the diff and the live constitution §5. Map changed facts to their owning document and
+check that contract, not merely whether a filename appears in the diff. Unchanged index pointers
+and entry guidance need no edits. T7 additionally requires the governance reason and existing
+operator authorization under §6.8; include affected templates.
 
 ## contract-verify — §4.3
 
@@ -65,15 +57,10 @@ Compare `owns`/`authority` against the §4.1 row (verbatim in meaning; §4.1 win
 
 ## lesson-append — §8
 
-```
-- [YYYY-MM-DD] <project>: <lesson — what went wrong / what to do instead>
-```
-
-1. Identify the per-file `### Lessons for <doc>` section (or the cross-cutting one).
-2. `rg` that section for an equivalent lesson — if found, **bump its date**, don't duplicate.
-3. Append the formatted line. If the lesson restates an existing §6 rule, it's already law — skip.
-4. If it has recurred, **promote** it to a §6 rule / §5 trigger and remove from §8 (the only
-   sanctioned deletion).
+1. Resolve the existing learning/context destination from the project's conventions.
+2. Search for an equivalent lesson; skip duplicates and routine completion receipts.
+3. Record the useful lesson with evidence outside the constitution.
+4. Propose any governance correction separately; recurrence does not authorize a §6.8 edit.
 
 ## Drift-report shape
 
@@ -84,7 +71,7 @@ Checks run: <n> (§7 items)  ·  Findings: <m>
 
 | # | Doc | Reality says | Doc says | Authority | Trigger | Repair |
 |---|-----|--------------|----------|-----------|---------|--------|
-| 1 | 04_DESIGN | `spur foo` exists (apps/cli/.../foo.ts) | absent | 04 (T3) | — | add the §6.4 command block |
+| 1 | 04_DESIGN | Changed command contract | Satellite describes old behavior | 04 | T3 | update its owning satellite under §6.5 |
 
 Zero-finding checks: <list the §7 items that returned no delta, with the command used>
 ```

package/plugins/sp/skills/parallel-execution/references/dispatch-surface.md

@@ -128,7 +128,7 @@ rule at the source, so no per-path shim is needed:
 | `spur agent run` (CLI) | `AgentService.run` → resolution → child process | Declared wins; absent inherits via `SPUR_ROLE`; envelope carries `roleOrigin` |
 | Workflow `agent.run` step | `AgentRunActionRunner` → `AgentService.runTraced` | Step `role:` is **mandatory** (0538 R2, `agent-run.ts` fails a role-less step before dispatch) — always a declaration (`roleOrigin: 'declared'`); inheritance applies at the next fan-out boundary the step's subagent itself dispatches |
 | `spur agent loop` | `AgentService.run` per drained iteration | Same resolution path as `spur agent run`; inherits its own `SPUR_ROLE` |
-| `spur team` supervisor → member | spawns `spur agent loop` | Member inherits the supervisor's `SPUR_ROLE` (recursive by construction) |
+| `spur serve` team supervisor → member | spawns `spur agent loop` | Member inherits the supervisor's `SPUR_ROLE` (recursive by construction) |
 | Native subagent fan-out (this skill's default) | in-session `Task()`/`Skill()` | In-session subagents share the host session; when they themselves dispatch, the host's role is already in the session env — the rule holds at the next `spur agent run` boundary |
 | `plugins/sp/evals/run-eval.ts` | `spawnSync('spur agent run', …)` per scenario | Out of scope: a top-level eval harness, not a fan-out — no dispatcher role exists to inherit; each scenario is an independent top-level run (documented, no shim) |
 

package/plugins/sp/skills/spec-decomposition/references/decomposition.md

@@ -525,6 +525,35 @@ The payload is a top-level JSON **array** (no `tasks` wrapper):
 ]
 ```
 
+## Idea-pipeline emission
+
+When the idea-pipeline workflow dispatches you for a feature, read the brainstorm artifact, the
+feature AC, and the design doc, then emit two run-scoped artifacts.
+
+**Sizing first, before any JSON.** Apply the `Default to NOT decomposing` rubric to the whole
+unit of work — if it scores 0–2 the correct output is a ONE-entry batch, not many.
+
+**Scenario count is not task count.** Merge scenarios that one task delivers (same file surface,
+same subsystem, or unreadable apart in review), and list every scenario a task covers in its
+background. Merging never costs AC coverage — one task may carry several scenarios. Do not emit
+one entry per scenario or per requirement by reflex.
+
+**The batch.** Produce a task-batch JSON array at the workflow-provided batch path
+(`.spur/run/<runId>-idea-task-batch.json`), validated against `task-batch.schema.json`.
+Schema-permitted fields per entry: `name`, `background`, `requirements`, `design`, `plan`,
+`acceptance_criteria`, `feature_id`, `parent_wbs`, `priority`, `tags`, `template` — schema
+validation rejects anything else. `design`, `plan`, and `acceptance_criteria` are supported batch
+fields and normal default planning fills them from your analysis; the per-task refine step after
+batch-create still deepens them when a task needs more detail. Validate locally against the
+schema before emitting.
+
+**The order sidecar.** Also emit the private task-order sidecar at
+`.spur/run/<runId>-idea-task-order.json`: a JSON array (one entry per batch item) of
+`{ name: <exact batch item name>, depends_on_names: [<batch item names>] }` declaring
+ordering/dependencies between the batch items; state `depends_on_names: []` per item when no
+ordering exists. Every `name` and every dependency must match exactly one batch item `name` —
+it is private workflow data, not part of task-batch.schema.json.
+
 ## Common schema violations
 
 | Violation | Fix |

package/plugins/sp/skills/spur-cli/references/agent.md

@@ -24,11 +24,13 @@ that before using `run` for fan-out dispatch.
 | `run <prompt>` | Execute a prompt or slash command via a coding agent | `--agent <name>` `--spec <id>` `--model <name>` `--mode <mode>` `--continue` `--cwd <path>` `--drain` `--json` |
 | `loop` | Persistent self-draining inbox loop for a team member (supervisor-managed) | `--spec <id>` `--agent <id>` `--poll <ms>` |
 | `wait [<specId>]` | Identity-pinned wait for an occupant run to reach a lifecycle state (G4 wave 2; `--role` selector per 0685) | `--role <name>` `--run <runId>` `--until <state>...` `--timeout <ms>` `--json` |
-| `list` | List detected coding agents, or team agent specs with `--specs` | `--specs` `--json` |
+| `list` | List detected coding agents, or team agent specs with `--specs` (live run status merged from `spur serve`) | `--specs` `--server <url>` `--json` |
 | `doctor [agent]` | Check agent readiness | `--json` `--probe-health` `--force-refresh` |
 | `create <id>` | Write a team agent spec to `.spur/agents/<id>.yaml` | `--type` `--tags` `--model` `--autonomy` `--system-prompt` `--name` `--workspace` `--purpose` `--auto-start` `--no-identity-preamble` `--json` |
 | `edit <id>` | Open an agent spec in `$EDITOR`, or print its path | - |
 | `delete <id>` | Remove an agent spec | `--force` |
+| `start <spec-id>` | Start a supervised agent process (requires `spur serve`; 0848 moved home of `spur team start`) | `--server <url>` `--json` |
+| `stop <spec-id>` | Stop a supervised agent process (requires `spur serve`; 0848 moved home of `spur team stop`) | `--server <url>` `--json` |
 
 `list`, `doctor`, `run`, `wait`, and `create` accept `--json` plus `--json-envelope`. `loop`, `edit`,
 and `delete` are human/process-control surfaces. **Exit codes:** `0` success, `1` failure, and `2`
@@ -54,7 +56,7 @@ through a coding agent as an external process, producing a persisted run record
 | `--mode <mode>` | Agent output mode: `text` or `json`. |
 | `--continue` | Resume the previous agent session instead of starting fresh. |
 | `--cwd <path>` | Working directory for agent execution (default: current directory). |
-| `--spec <id>` | Team agent spec id (occupant addressing, 0542 R1). Pairs with `--drain`; with `--spec` alone the run is addressed to the occupant without touching the inbox. A legacy `--agent <spec-id>` still works during the transition with a one-time warning (shim `agent-flag-spec-id`). |
+| `--spec <id>` | Team agent spec id (occupant addressing, 0542 R1). Pairs with `--drain`; with `--spec` alone the run is addressed to the occupant without touching the inbox. A legacy `--agent <spec-id>` is still accepted as fallback addressing (task 0849 retired the `agent-flag-spec-id` deprecation warning). |
 | `--drain` | Prepend pending inbox messages addressed to `--spec <id>` before the prompt. |
 | `--json` | Output machine-readable JSON where supported. |
 | `--json-envelope` | Wrap JSON using the facade's standard output contract. |
@@ -89,9 +91,13 @@ justify it - but ensure the run executes in a context that can write the target
 spur agent loop --agent worker-1 --poll 2000
 ```
 
-`loop` is the **persistent self-draining wrapper** used by the team supervisor. It polls the
-addressed agent's inbox, drains each pending message into an `agent run` invocation, and idles
-between drains. It is not typically invoked directly by the operator - `spur team start` launches it
+`loop` is the **persistent self-draining wrapper** used by the team supervisor. It waits for a
+wake on the `system_events` ledger — a human request (`message.sent`), a strategy change
+(`strategy.changed`), a capacity change (`fleet.capacity.changed`), or a completion receipt
+(`agent.invoke.exit`) — then drains the inbox into an `agent run` invocation. An idle wake
+records the hold reason instead of dispatching; with no wake event at all it still drains every
+`--poll` ms (backstop). It
+between drains. It is not typically invoked directly by the operator - `spur agent start` launches it
 under supervision.
 
 ### Flags
@@ -99,10 +105,10 @@ under supervision.
 | Flag | Purpose |
 |------|---------|
 | `--spec <id>` | **Required.** Team agent spec id / message recipient (0542 R1; legacy `--agent <spec-id>` still read with a one-time warning). |
-| `--poll <ms>` | Idle poll interval in milliseconds (default: `2000`). |
+| `--poll <ms>` | Wakeup backstop timeout in milliseconds — drains at least this often (default: `2000`). |
 
 The loop runs until `SIGINT` / `SIGTERM`. Each iteration: check inbox -> if messages, drain each
-into `run` with `--drain` -> else sleep for `--poll` ms.
+into `run` with `--drain` -> else record the idle hold (an empty drain dispatches nothing).
 
 ## `wait` - identity-pinned occupant wait (G4 wave 2)
 
@@ -152,7 +158,17 @@ spur agent list --json       # machine-readable
 ```
 
 Without `--specs`, lists coding agents detected on the host (by binary on `PATH`). With `--specs`,
-lists team agent specs (`.spur/agents/*.yaml`).
+lists team agent specs (`.spur/agents/*.yaml`) **with live run status merged from the server's
+supervisor** (0848, the moved home of `spur team status`): each row carries a trailing status column
+(`running` / `stopped` / `errored` / `unknown`) and `pid=<n>` where a process exists. When `spur serve`
+is unreachable, the listing falls back to all `stopped` with a stderr warning. `--server <url>`
+(default `http://localhost:3000/api`) targets the supervisor API.
+
+```bash
+spur agent list --specs
+# planner	claude	reviewer	claude	plans the work	running pid=4132
+# worker-1	pi	worker	pi	implements	stopped
+```
 
 ## `doctor` - readiness check
 
@@ -176,7 +192,8 @@ spur agent create reviewer --type codex --autonomy review --auto-start
 ```
 
 Writes a team agent spec to `.spur/agents/<id>.yaml`. The spec captures the agent's identity
-(type, model, autonomy, system prompt, tags) so `spur team up` can materialize a roster and `spur
+(type, model, autonomy, system prompt, tags) so the fleet declaration (`.spur/fleet.json`, converted
+by `spur projects migrate`) can materialize a roster and `spur
 agent loop` can self-drain its inbox.
 
 ### Flags
@@ -191,7 +208,7 @@ agent loop` can self-drain its inbox.
 | `--name <name>` | Agent display name. |
 | `--workspace <path>` | Workspace path for this agent. |
 | `--purpose <text>` | Team identity purpose. |
-| `--auto-start` | Auto-start flag (start on `team up` without manual `team start`). |
+| `--auto-start` | Auto-start flag (started by the supervisor when serve materializes the fleet; without it, start manually with `spur agent start`). |
 | `--no-identity-preamble` | Disable the identity preamble prepended to prompts. |
 | `--json` | Output machine-readable JSON. |
 
@@ -211,20 +228,45 @@ spur agent delete worker-1 --force
 
 `--force` is required (guards against accidental deletion). Removes `.spur/agents/<id>.yaml`.
 
+## `start` - start a supervised process (0848)
+
+```bash
+spur agent start worker-1
+spur agent start worker-1 --json
+```
+
+The moved home of `spur team start`. Posts to the `spur serve` supervisor API
+(`POST /api/team/agents/:id/start`) and prints `started <id> (pid=<n>, status=<s>)`. Requires a
+reachable `spur serve`; `--server <url>` (default `http://localhost:3000/api`) targets it. Exit `1`
+when the server is unreachable or the start fails.
+
+## `stop` - stop a supervised process (0848)
+
+```bash
+spur agent stop worker-1
+spur agent stop worker-1 --json
+```
+
+The moved home of `spur team stop`. Posts to the supervisor API
+(`POST /api/team/agents/:id/stop`) and prints `stopped <id>`. Same server requirement and flags as
+`start`. `spur agent delete` (with `--force`) remains the spec-removal counterpart of the old
+`team down --purge`.
+
 ## What this skill is NOT
 
 - **Not the dispatch decision.** *When* to use `spur agent run` vs a native subagent is the
   **[dispatch-surface rule](../../parallel-execution/references/dispatch-surface.md)**, not this
   reference. This reference documents the verbs; that rule decides which surface carries a dispatch.
-- **Not the team orchestrator.** `spur team up` / `spur team start` drive the supervisor lifecycle;
-  `spur agent` provides the execution primitives they compose.
+- **Not the team orchestrator.** The `spur serve` supervisor drives the lifecycle: `spur agent
+  start` / `stop` manage supervised processes and `agent list --specs` reports live state (0848
+  moved these homes off the deprecated `spur team` noun).
 
 ## See also
 
 - **[dispatch-surface.md](../../parallel-execution/references/dispatch-surface.md)** - native
   subagent vs `spur agent run` decision rule. `--model` and `--agent` are its escalation levers.
-- **`spur team` (see [team.md](team.md))** - team lifecycle that launches `agent loop` under
-  supervision.
+- **`spur team` (see [team.md](team.md))** - deprecated team noun (0848); its verbs moved to this
+  noun (`start`/`stop`/`list --specs`) and to `spur task update --assignee`.
 - **`spur message` (see [message.md](message.md))** - the inbox `--drain` reads from.
 - **`sp:spur-cli`** SKILL.md - the facade that routes to this reference.
 

package/plugins/sp/skills/spur-cli/references/message.md

@@ -19,8 +19,8 @@ use it well*.
 
 | Verb | Purpose | Key flags |
 | ---- | ------- | --------- |
-| `send <body>` | Enqueue a message for an agent | `--to <id>` `--role <name>` `--from <id>` `--wait` `--until <state>` `--timeout <ms>` `--json` |
-| `inbox` | List messages addressed to an agent | `--agent <id>` `--json` |
+| `send <body>` | Enqueue a message for an agent | `--to <id>` `--role <name>` `--from <id>` `--request-key <key>` `--wait` `--until <state>` `--timeout <ms>` `--json` |
+| `inbox` | List messages addressed to an agent | `--agent <id>` `--unresolved` `--json` |
 | `reply <msg-id> <body>` | Thread a reply to a message | `--json` |
 | `watch` | Follow an agent inbox - surface new messages as they arrive | `--agent <id>` `--interval <ms>` `--json` |
 
@@ -34,6 +34,7 @@ spur message send "Please review PR 42" --to reviewer
 spur message send "Task 0040 is blocked" --to worker-1 --from operator
 spur message send "Done" --to planner --json
 spur message send "Review 0042" --to reviewer --wait --until invoke-exit --timeout 30000
+spur message send "Done" --to manager --request-key 0695-report-42      # retry-safe: same key replays the original receipt
 spur message send "Start the pass" --role reviewer          # resolves to exactly one instance
 ```
 
@@ -51,6 +52,9 @@ wait; enqueue is **not** rolled back if the wait later fails.
 | `--to <id>` | Recipient agent id. Mutually exclusive with `--role`; exactly one of the two is required. |
 | `--role <name>` | Address by Layer-1 role or executor name. Must resolve to exactly one materialized instance; zero (`count=0`, candidates `none`) or multi (`count=N` + candidates) matches are hard errors (exit 1); unknown name exits 2 naming the accepted vocabulary (`AGENT_ROLE_NAMES` ∪ executor names). Resolution yields the same spec-id path as `--to`; `--wait` snapshots that occupant pin. (0685 R6 / ADR-075 amendment) |
 | `--from <id>` | Sender id (default: `operator`). |
+| `--request-key <key>` | Caller-minted idempotency key. The same key with the same body + recipient replays the original receipt (`replayed: true`, no second row/delivery); the same key with a different payload fails with a request-key-conflict error (0832). |
+| `replayed` receipt field | Present on keyed sends: `true` when this submission was a replay of an earlier accepted send. |
+| `requestKey` receipt field | Present on keyed sends, including replays; echoes the accepted key. Blank keys are rejected. |
 | `--wait` | Block until the recipient reaches `--until` (snapshots occupant before send). |
 | `--until <state>` | Wait target: `injected` \| `invoke-exit` (repeatable OR). Default `invoke-exit`. |
 | `--timeout <ms>` | Caller deadline in milliseconds. |
@@ -64,11 +68,33 @@ wait; enqueue is **not** rolled back if the wait later fails.
 ```bash
 spur message inbox --agent worker-1
 spur message inbox --agent worker-1 --json
+spur message inbox --agent worker-1 --unresolved --json
 ```
 
 Lists messages addressed to `--agent <id>`, oldest first. The body is truncated in plain-text output;
 `--json` returns the full body.
 
+### Delivery failure states (0834)
+
+`--unresolved` filters the listing to messages the delivery reconciler holds, and every `--json` row
+gains the operator-read fields: `injectAttempts`, `injectError`, `reason`, `runId`, `taskId`, `runStatus`,
+`artifacts`. The hold reasons are distinct and durable — never one overloaded status column:
+
+Delivered messages remain eligible for holds until their receipt is verified. Interrupted runs
+carry their persisted origin and run status; exhausted attempts keep the same reason on repeated reads.
+
+| `reason` | Meaning |
+| -------- | --------- |
+| `delivery-failed` | The drain marked the delivery failed (`injectError` carries why), or its run's receipt outcome is `errored`. |
+| `attempts-exhausted` | The message burned its bounded redelivery budget (`MAX_INJECT_ATTEMPTS`, 0831); the reconciler marks it `failed` — the reconciler's only write. |
+| `outcome-unknown` | The drain consumed it and no completion receipt ever arrived: the agent may have edited files. **Never requeued, never auto-released** — a human decides. |
+| `run-exit-only` | Its run exited (receipt outcome `run-exit-only`) with no workflow verification result. |
+
+`runId`, `taskId`, and `artifacts` (path-only refs) come only from the persisted run row that lists
+the message in its receipt; nothing is inferred from terminal output or process lists. The same
+reconciler runs once at `spur agent loop` startup and writes a `reconcile:` summary to the run log
+before the first drain.
+
 ## `reply` - thread a reply
 
 ```bash
@@ -107,7 +133,8 @@ lines.
 ## See also
 
 - **`spur agent` (see [agent.md](agent.md))** - `run --drain` and `loop` consume the inbox.
-- **`spur team` (see [team.md](team.md))** - team lifecycle that assigns agents to tasks.
+- **`spur task` (see [tasks.md](tasks.md))** - `task update --assignee` wires an agent spec to a
+  task (0848 moved home of `spur team assign`).
 - **`sp:spur-cli`** SKILL.md - the facade that routes to this reference.
 
 > **Shared option declarations (0618):** options shared across command modules resolve from

package/plugins/sp/skills/spur-cli/references/projects.md

@@ -19,9 +19,10 @@ shapes live in `apps/cli/src/commands/projects.ts`.
 | ---- | ------- | --------- |
 | `add <path>` | Upsert an existing path in the registry | `--name <name>` `--json` |
 | `remove <target>` | Remove an entry by display name or path | `--json` |
-| `list` | List entries with live running status | `--json` |
+| `list` | List entries with live running status | `--json` `--fleet` |
 | `start <target>` | Start or reuse a detached project server | `--port <n>` `--json` |
 | `stop <target>` | Best-effort stop the listener and clear its recorded port | `--json` |
+| `migrate [path]` | Preview (default) or apply the legacy `agent.team` → `fleet.json` conversion (0847) | `--dry-run` `--apply` `--json` |
 
 Every verb also advertises `--json-envelope`; use the facade's machine-output contract. Success is
 exit `0`; validation, registry, spawn, health, or lookup failure is exit `1`.
@@ -36,6 +37,49 @@ exit `0`; validation, registry, spawn, health, or lookup failure is exit `1`.
   defaults the display name to its basename. It upserts; it does not start a server. The current
   source does not enforce a `.spur/` marker or directory type.
 - `list` probes recorded ports and heals stale entries to `port: 0` before reporting `running`.
+- `list --fleet` (0835) additionally resolves each project's fleet declaration at
+  `<project>/.spur/fleet.json` under the existing verb (no new noun). Per project it prints one line
+  per member: instance id (the spec id / mailbox identity), `role`, resolved `executor`,
+  `fsWrite` capability state, and derived `write` flag. A project with no declaration reports
+  `no declaration (.spur/fleet.json)`; an all-disabled roster reports `no enabled members`; a project
+  whose executors fail resolution reports the error without failing the listing. Under `--json` each
+  project gains `fleet` (the resolved fleet, `null` on resolution failure) and, on failure,
+  `fleetError`.
+- `list --fleet` (0836) also reports the project's orchestrator binding: one
+  `orchestrator:` line per project with state `bound-online <id> (holder <spec-id>)`,
+  `bound-offline <id> (no live claim)`, `missing (no-orchestrator-declared)`, or
+  `unresolvable (<reason>)` — missing (nothing bound) and bound-offline (bound, no live
+  claim) are distinct states with distinct next actions, and an unresolvable pointer is an
+  error, never inferred. Reading the live claim touches the project's own `.spur/spur.db`
+  (lazily; only when the pointer resolves). Under `--json` each project gains
+  `orchestrator` (the binding, `null` on resolution failure) and, on failure,
+  `orchestratorError`.
+- `list --fleet` (0838) also reports the project's persisted strategy (0838): one
+  `strategy:` line — `rest (default)` when nothing is persisted (the read never
+  writes; only the runtime's `setStrategy`/`resume` persist), `<name> (v<n>)` for a
+  persisted row, or `unavailable (<error>)` on a db failure. Under `--json` each
+  project gains `strategy` (`{ strategy, strategyVersion }`, `null` when
+  unpersisted) and, on failure, `strategyError`.
+- `migrate [path]` (0847) converts the single legacy `agent.team.<id>` roster whose
+  `work_dir` resolves to the project into `<project>/.spur/fleet.json`, preserving
+  every spec id verbatim (explicit member ids freeze the `<role>-<n>` derivation).
+  Dry-run is the default: it emits the 0846 plan (steps + conflicts + warnings) and
+  writes nothing — an existing project db is opened read-only without migrations;
+  an absent db or table contributes no addressed identities.
+  `--apply` validates first, deep-equals an existing declaration (`unchanged`, no
+  rewrite), backs up a differing prior file to `.bak`, then atomically writes the
+  declaration (`converted`). It is purely additive — specs, `config.yaml`, and the
+  database are never touched — and it refuses to write while any conflict exists
+  (`addressed-id-without-spec`, `two-teams-one-project`, …). A registry name that
+  differs from the legacy team ID is `project-name-mismatch`: align that name
+  explicitly before conversion so fleet resolution preserves the spec-id prefix.
+  Exit codes: `0` for a
+  clean preview or `converted`/`unchanged`/`nothing-to-convert`; `2` when blocked
+  (the JSON payload still carries the full plan/result); `1` on error. Under
+  `--json` the payload is the raw `MigrationPlan` (preview) or `ConversionResult`
+  (apply). `rollback` is a service-level API (no CLI verb): restore the `.bak` a
+  previous apply created, remove a file that apply created when no `.bak` exists,
+  or report `nothing-to-roll-back`.
 
 ## Server lifecycle
 

package/plugins/sp/skills/spur-cli/references/self.md

@@ -95,8 +95,9 @@ directory. Only flag is `--json`.
 
 ## What this skill is NOT
 
-- **Not the team supervisor.** `self serve` hosts the supervisor API; `spur team start` / `stop` /
-  `status` are the verbs that drive it. See **[team.md](team.md)**.
+- **Not the team supervisor.** `self serve` hosts the supervisor API; `spur agent start` / `stop` /
+  `agent list --specs` are the verbs that drive and inspect it (0848). See
+  **[agent.md](agent.md)**.
 - **Not a production server.** This is the local fallback. Production deployment uses the Cloudflare
   Worker build (`apps/server/`), not `self serve`.
 
@@ -105,8 +106,8 @@ directory. Only flag is `--json`.
 - **[init.md](init.md)** - `init` / `status` verbs: scaffold semantics and the Phase 1.5 / 1.6
   post-scaffold validation probes.
 - **[serve.md](serve.md)** - `serve` verb: server flags and the `--json` dry-probe contract.
-- **`spur team` (see [team.md](team.md))** - `start`/`stop`/`status` require `self serve` for the
-  supervisor API.
+- **`spur agent` (see [agent.md](agent.md))** - `start`/`stop`/`list --specs` require `self serve`
+  for the supervisor API.
 - **`sp:spur-cli`** SKILL.md - the facade that routes to this reference.
 
 > **Shared option declarations (0618):** options shared across command modules resolve from

package/plugins/sp/skills/spur-cli/references/serve.md

@@ -46,13 +46,14 @@ the team supervisor API become available at `http://<host>:<port>`.
 
 ## What this skill is NOT
 
-- **Not the team supervisor.** `spur serve` hosts the supervisor API; `spur team start` / `stop` /
-  `status` are the verbs that drive it. See **[team.md](team.md)**.
+- **Not the team supervisor.** `spur serve` hosts the supervisor API; `spur agent start` / `stop` /
+  `agent list --specs` are the verbs that drive and inspect it (0848). See
+  **[agent.md](agent.md)**.
 - **Not a production server.** This is the local fallback. Production deployment uses the Cloudflare
   Worker build (`apps/server/`), not `spur serve`.
 
 ## See also
 
-- **`spur team` (see [team.md](team.md))** - `start`/`stop`/`status` require `spur serve` for the
-  supervisor API.
+- **`spur agent` (see [agent.md](agent.md))** - `start`/`stop`/`list --specs` require `spur serve`
+  for the supervisor API.
 - **`sp:spur-cli`** SKILL.md - the facade that routes to this reference.

package/plugins/sp/skills/spur-cli/references/tasks/verbs.md

@@ -67,6 +67,20 @@ frontmatter scalar.
   wholesale. No inline-body flag. Section names: `Background`, `Requirements`, `Acceptance Criteria`, `Q&A`, `Design`, `Plan`, `Solution`, `Testing`, `Review`, `References`, `History`, `Notes`.
 - **Frontmatter** (`--feature <id>`, `--priority <p>`): sets the scalar frontmatter field on an
   existing task — the only post-create path, allow-listed to `feature_id` / `parent_wbs` / `priority`.
+- **AC controls** (`--ac-altitude <graduating|task-local>`, `--ac-numbering task-local`) — independent
+  of each other (task 0818 R5). `--ac-altitude task-local` skips the **DD-09 feature-AC subset** rule
+  because the task's scenarios are intentionally not the feature's ship criteria; `--ac-numbering
+  task-local` opts the task into the **Requirements↔AC coverage** check inside the task. Setting one
+  never implies the other. `graduating` remains the default and DD-09 stays enforced for graduating
+  tasks. Use it for an issue/fix-batch task that is genuinely linked to a feature but whose
+  regression scenarios sit below that feature's ship criteria, and record the rationale in the task
+  body:
+
+  ```bash
+  # One frontmatter flag per call — `update` sets a single field and ignores the rest.
+  bun run apps/cli/src/index.ts task update 0818 --feature D6 --json
+  bun run apps/cli/src/index.ts task update 0818 --ac-altitude task-local --json
+  ```
 
 Exit code `2` when neither mode's required args are supplied (e.g. `--section` without `--from-file`,
 or no status and no `--section`/frontmatter flag).
@@ -183,7 +197,9 @@ traceability. Bare = whole corpus; with a WBS = one task. The matrix is loaded f
 
 **L4 traceability** resolves `feature_id` / `parent_wbs` / `dependencies` edges and checks **AC
 coverage** (DD-09): a task's scenarios must be a subset of its linked feature's AC by normalized
-title — orphans warn by default.
+title — orphans warn by default. A task declaring `ac_altitude: task-local` is exempt from that
+subset rule only (`--ac-altitude`, above); every graduating task is still enforced, and the exemption
+does not touch `ac_numbering`'s Requirements↔AC coverage or any other layer.
 
 `--json` emits an array of per-task results:
 

package/plugins/sp/skills/spur-cli/references/tasks.md

@@ -40,7 +40,7 @@ re-reading or re-tokenizing the task.
 | ---- | ------- | --------- |
 | `create <title>` | Allocate a new task (race-safe WBS) | `--feature <id>` `--parent <wbs>` `--template <variant>` `--dedupe-within <s>` `--allow-duplicate-name` `--folder` `--json` |
 | `show <wbs>` | Print one task's frontmatter + body | `--folder` `--json` |
-| `update <wbs> [status]` | Lifecycle transition, section replace, **or** frontmatter set | `--section <name> --from-file <path>` `--feature <id>` `--priority <p>` `--no-lifecycle` `--force-done` `--reason <text>` `--verdict-dir <path>` `--folder` `--json` |
+| `update <wbs> [status]` | Lifecycle transition, section replace, **or** frontmatter set | `--section <name> --from-file <path>` `--assignee <spec-id>` (moved home of `spur team assign`; exclusive with `--section`) `--feature <id>` `--priority <p>` `--no-lifecycle` `--force-done` `--reason <text>` `--verdict-dir <path>` `--folder` `--json` |
 | `deps <wbs> <op> [values...]` | Mutate `dependencies[]` frontmatter array (ops: `set`, `add`, `remove`, `clear`) | `--folder` `--json` |
 | `sections <wbs> <op> [name]` | Initialize, add, or list canonical task sections (ops: `init`, `add`, `list`) | `--folder` `--json` |
 | `list` | List tasks, filtered | `--status <s>` `--phase <p>` `--parent <wbs>` `--feature <id>` `--folder` `--json` |
@@ -157,13 +157,43 @@ spur task update 0040 --section Review --from-file /tmp/review.md
   first, then point `--from-file` at it.
 
 **Frontmatter set** (the only post-create path to scalar fields, allow-listed to
-`feature_id`/`parent_wbs`/`priority`):
+`feature_id`/`parent_wbs`/`priority`, plus the two AC controls below):
 
 ```bash
 spur task update 0040 --feature H2
 spur task update 0040 --priority P1
 ```
 
+### AC altitude — `--ac-altitude` (task 0818 R5)
+
+`--ac-altitude` and `--ac-numbering` are **independent** controls that are easy to confuse:
+
+| Flag | Controls | Default | `task-local` means |
+| --- | --- | --- | --- |
+| `--ac-altitude <graduating\|task-local>` | DD-09 **feature-AC subset** rule (task scenarios ⊆ linked feature AC) | `graduating` | the task's scenarios are deliberately **not** feature ship criteria — skip the subset rule |
+| `--ac-numbering <task-local>` | **Requirements↔AC coverage** inside the task | off | opt the task into the R-to-AC coverage check |
+
+Setting one says nothing about the other: a `task-local`-altitude task can still be under full
+R-to-AC coverage, and usually should be.
+
+**The standing pattern for an issue or fix-batch task.** Link it to the feature it substantively
+belongs to — do not leave it orphaned and do not relink unrelated corpus to silence a diagnostic.
+Then, *only* when its regression scenarios intentionally do not represent that feature's ship
+criteria, declare `--ac-altitude task-local` and record the rationale in the task body (Background
+or Design), so the choice is auditable rather than inferred:
+
+```bash
+# source-local CLI (before `bun link`, or when pinning to this checkout).
+# One frontmatter flag per call: `update` applies a single field, so a second
+# frontmatter flag in the same invocation is silently ignored.
+bun run apps/cli/src/index.ts task update 0818 --feature D6 --json
+bun run apps/cli/src/index.ts task update 0818 --ac-altitude task-local --json
+```
+
+`graduating` stays the default, and DD-09 stays enforced for every graduating task — this flag
+expresses a real altitude distinction, not a gate escape hatch. Ordinary orphan warnings are
+unchanged, and no checker policy changes.
+
 The section-write-then-replace pattern is the workflow agents use to fill in `Plan` / `Solution` /
 `Testing` / `Review` during a run. See
 [tasks/section-editing.md](tasks/section-editing.md) for the full recipe. For pipeline

package/plugins/sp/skills/spur-cli/references/team.md

@@ -5,7 +5,27 @@ see_also:
   - spur-cli
 ---
 
-# spur team - team coordination and supervision
+# spur team - team coordination and supervision (DEPRECATED — 0848)
+
+> **Deprecated (0848, feature G64):** every `spur team` capability has moved to its owning noun.
+> The noun keeps working until the G64 cutover window is recorded, emitting a one-time stderr
+> warning per process. Migrate invocations now:
+>
+> | Old verb | New home |
+> | --- | --- |
+> | `spur team assign <task-id> <agent-id>` | `spur task update <wbs> --assignee <spec-id>` |
+> | `spur team status` | `spur agent list --specs` (same live-run merge) |
+> | `spur team status --by-team` | dropped — one project has one fleet; `spur agent list --specs` is the single fleet listing |
+> | `spur team up <team>` | fleet materialization at `spur serve` start (`.spur/fleet.json`); `up --check` diff → `spur projects list --fleet` |
+> | `spur team down <team> [--purge]` | `spur agent stop <spec-id>` per member (`spur agent delete <id>` replaces `--purge`) |
+> | `spur team start <agent-id>` | `spur agent start <spec-id>` |
+> | `spur team stop <agent-id>` | `spur agent stop <spec-id>` |
+
+> **Retiring:** `spur team` is a retiring surface for spur-* guidance. `sp:expert-spur`,
+> `sp:spur-composer` and `sp:spur-doctor` forbid it, and coordination or recurring loops belong to
+> `sp:super-planner` or a workflow. Reach agent specs through `spur agent ... --specs` and use
+> `spur message` for coordination transport. This reference is retained for CLI parity while the
+> noun still ships; do not build new guidance on it.
 
 `spur team` is the CLI for **coordinating team agent assignments and supervision**. It sits above
 `spur agent` specs: `up` / `down` materialize and tear down rosters, `start` / `stop` manage

package/plugins/sp/skills/spur-cli/references/workflows/operations.md

@@ -65,9 +65,12 @@ Reconciliation core — run this **before authoring anything**. Authoring withou
 workflows breeds redundant, diverged definitions (two near-identical approval flows, an import flow
 re-implemented under a new name). Inputs: the clarified process intent. Steps:
 
-1. **Enumerate existing workflows** — list `.spur/workflows/*.yaml` (and any `--file`-adjacent
-   directory); read each one's `name`, `kind`, and the states/nodes it defines so matches are found by
-   *substance*, not just by filename.
+1. **Enumerate existing workflows** — `spur workflow list --json` across **all layers**
+   (`project`, `registered`, `shared` — the listed `layers` are the folders a name can resolve
+   from). Never glob `.spur/workflows`: a folder scan misses the registered and shared layers.
+   Match from each entry's `name`, `kind`, `source` (the layer it came from) and `description`
+   (the intent), then read the strongest candidates' definitions — states/nodes — so matches are
+   found by *substance*, not just by filename.
 2. **Classify the strongest match** against the new intent:
 
    | Match | Meaning | Action |