@gobing-ai/spur 0.3.90 → 0.3.92

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

@@ -231,8 +231,17 @@ to executors via `agent.executors[].agent` (or the model's `<provider>/` prefix)
 write path. A provider is exhausted when any `primary|secondary|tertiary` window reports
 `usedPercent >= 100`; the window name and `resetsAt` go into the observation reason. Per-provider
 `{ "error": … }` entries are skipped (listed, never treated as recovery); healthy entries still
-apply. A missing codexbar binary or an unparsable payload exits `1` and changes nothing.
-Unmapped providers are listed and never guessed.
+apply. Providers whose windows are all null carry no signal (`no-usage`): they are reported and
+excluded from availability decisions — an absent signal neither disables nor recovers, and an
+exhausted signal wins on shared executors. Operator-owned availability (`disabled: true` or an
+operator ownership object) is never touched. A missing codexbar binary or an unparsable payload
+exits `1` and changes nothing. Unmapped providers are listed and never guessed.
+
+Each reported change carries a delivery-semantics `action` (0907): `would-apply` (dry run),
+`applied` — the exact observation created by the invocation was acknowledged without a skip
+(desired state confirmed; not proof of a YAML byte change), `no-op` — already satisfied or
+operator-owned, `skipped` — the observation was superseded or rejected, `pending` — delivery
+unconfirmed or failed. For `skipped`/`pending` the printed target is intent only.
 
 **Scheduling is external** (cron/launchd, same pattern as `spur history daily`):
 

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

@@ -28,7 +28,7 @@ what* or *how to write a scenario*, this skill.
 | `list` | List features, filtered | `--status <s>` `--priority <p>` `--folder` `--json` |
 | `move <id>` | Re-parent a subtree (cascade-rename of descendants) | `--parent <id>` `--dry-run` `--folder` `--json` |
 | `refresh` | Rebuild INDEX + each feature `## Tasks` table from task edges (**docs only**; no status change) | `--feature <id>` `--all` `--folder` `--json` |
-| `check [id]` | Validate one feature / the tree; the 4-layer gate; `--fix` repairs structural findings in place | `--strict` `--fix` `--folder` `--json` |
+| `check [id]` | Validate one feature / the tree; the 4-layer gate; `--fix` repairs structural findings in place | `--strict` `--fix` `--as <status>` `--folder` `--json` |
 | `sync [id]` | Align feature **lifecycle status** with linked task states (real transitions + guards) | `--all` `--dry-run` `--force` `--folder` `--json` |
 
 **`refresh` vs `sync` (do not conflate):**

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

@@ -19,6 +19,7 @@ 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` |
+| `clean` | Purge missing project folders and terminate lingering processes (alias: `refresh`) | `--no-terminate-processes` `--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` |
@@ -35,7 +36,8 @@ exit `0`; validation, registry, spawn, health, or lookup failure is exit `1`.
 - `add` requires an existing path, resolves a relative path from the current working directory, and
   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` automatically heals tilde paths, verifies project directories exist on disk (purging missing entries and terminating lingering processes), and heals stale entries to `port: 0` before reporting `running`.
+- `clean` (alias `refresh`) explicitly purges non-existent project directories from `projects.json`, probes live ports for removed entries, and cleanly terminates orphaned listening processes (SIGTERM with bounded wait and SIGKILL escalation). Supports `--no-terminate-processes` to skip process kills.
 - `list --fleet` (0835/0858) additionally resolves each project's `agent.fleet` section from that
   project's `.spur/config.yaml` 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`,

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

@@ -90,7 +90,11 @@ spur self status --json               # machine-readable
 ```
 
 Reports the project's Spur configuration state (init status, feature/task counts, rule preset
-health) and git working-tree status. Optional `[path]` argument targets a different project
+health), git working-tree status, and DecisionMaker readiness (0911): the human output adds a
+`DecisionMaker:` line and `--json` exposes `decisionMaker: {enabled, provider,
+credentialPresent, state, connectivity, inlineSupport}` with states `disabled` / `missing-key` /
+`configured-not-probed`. Presence check only — never a live probe, never echoes the key.
+Optional `[path]` argument targets a different project
 directory. Only flag is `--json`.
 
 ## What this skill is NOT

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

@@ -80,7 +80,9 @@ Use this skill to:
 - **Author a workflow** — turn a described process into a validated, dry-run-verified YAML definition
   in the right mode. → authoring-workflows.md
 - **Validate before trusting** — schema + semantic-check a workflow file (references, terminal
-  reachability, template vars) before running it.
+  reachability, template vars, and since 0911 the HITL decision policy: `decision` only on
+  `hitl.confirm`/`hitl.select`, evidence mode banned in `pause: true` states/nodes, one evidence
+  action per state/node, existing producer nodes, valid select choices) before running it.
 - **Run a workflow** — execute a definition and read its run trace (states/nodes entered, transitions
   taken, terminal status).
 - **Refine an existing workflow** — fix a stuck guard, add a state/node, retune `iterationBound`,
@@ -108,11 +110,11 @@ The skill's logic divides by **whether the LLM adds value**:
 | --------- | --------- | ----- | ------------------ |
 | `validate` | `spur workflow validate` (CLI) | `<file> [--no-schema]` | Schema + semantic verdict |
 | `run` | `spur workflow run` (CLI) | `<file> [--run-id <id>] [--vars <json>] [--dry-run] [--async] [--no-plan] [--quiet/--silent/--verbose] [--detail <level>] [--trace-file] [--no-log] [--steer]` | Terminal state reached (sync) or run started (async); trace readable |
-| `continue` | `spur workflow continue` (CLI) | `[run-id] [--yes] [--answer <yes\|no\|cancel>] [--async] [--no-log]` | Resume a paused or interrupted run (omit id -> most recent resumable); `--answer` injects a gate answer before guard re-evaluation and is required headless (0901 R3); `--async` detaches the resume (0901 R4) |
+| `continue` | `spur workflow continue` (CLI) | `[run-id] [--yes] [--answer <yes\|no\|cancel>] [--answer-text <text>] [--async] [--no-log]` | Resume a paused or interrupted run (omit id -> most recent resumable); `--answer` injects a confirm/select gate answer and `--answer-text` answers an input gate with free text (H1 R27), both before guard re-evaluation; one of them is required headless (0901 R3) and each is validated against the pending gate kind; `--async` detaches the resume (0901 R4) |
 | `cancel` | `spur workflow cancel` (CLI) | `<run-id>` | Single non-terminal run marked failed (SIGTERM async worker when live) |
 | `clean` | `spur workflow clean` (CLI) | `[--older-than <min>] [--force] [--logs] [--dry-run]` | Bulk-finalize stale `running`/`pending` runs as failed **and** reclaim retained run logs older than `workflow.logRetentionDays` (30d default) |
 | `list` | `spur workflow list` (CLI) | — | Available workflow **YAML definition files** (not run records) |
-| `trace` | `spur workflow trace` (CLI) | `[run-id] [--workflow <n>] [--status <s>] [--since <iso>] [--last <n>] [--follow] [--poll <ms>] [--output]` | Run history list or per-run timeline |
+| `trace` | `spur workflow trace` (CLI) | `[run-id] [--workflow <n>] [--status <s>] [--since <iso>] [--last <n>] [--follow] [--poll <ms>] [--output] [--timeout <ms>]` | Run history list or per-run timeline |
 | `progress` | `spur workflow progress` (CLI) | `<run-id>` | The `projectWorkflowProgress` projection for that run — current state, per-action attempts, candidate next transitions, diagnostics. Read-only; the verb renders, `packages/app` derives. Unknown run id exits 1 with `Run <id> not found.` |
 | `add` | agent procedure | `"<nl-description>" [--kind <state-machine\|transition-flow>] [--file <path>]` | **Mode chosen (confirmed)** → first reconciled against existing workflows (extend an existing flow rather than duplicate) → YAML authored in real schema shape → **validated AND dry-run** (reaches the expected terminal state) → [add](workflows/operations.md#add) |
 | `refine` | agent procedure | `<workflow-file> [--intent "<goal>"] [--dry-run]` | Smallest change meeting the intent, re-validated and re-dry-run; `--dry-run` emits a diff only → [refine](workflows/operations.md#refine) |
@@ -202,7 +204,7 @@ spur workflow run ./workflows/approval.yaml --silent               # errors only
 spur workflow run ./workflows/approval.yaml --verbose              # transitions + correlation diagnostics
 spur workflow run ./workflows/approval.yaml --detail minimal       # tersest human output
 spur workflow run ./workflows/approval.yaml --trace-file           # persist redacted JSONL trace
-spur workflow run ./workflows/approval.yaml --no-log               # opt out of the consolidated .spur/run/<RUNID>.log
+spur workflow run ./workflows/approval.yaml --no-log               # opt out of the run record .spur/run/<RUNID>.md + .state.json
 spur workflow run ./workflows/approval.yaml --steer                # interactive steering on stdin
 ```
 
@@ -212,8 +214,8 @@ spur workflow run ./workflows/approval.yaml --steer                # interactive
   per-step headers), `full` (transitions + correlation). `--verbose` is shorthand for `--detail full`.
 - **`--trace-file`** appends a redacted, schema-versioned JSONL trace under `.spur/workflow/`
   for post-run analysis - independent of human/JSON output.
-- **`--no-log`** opts out of writing the consolidated all-in-one run log (`.spur/run/<RUNID>.log`).
-  By default the log is written **and retained** after the run ends; this flag skips it entirely
+- **`--no-log`** opts out of writing the two-file run record (`.spur/run/<RUNID>.md` + `.state.json`).
+  By default the record is written **and retained** after the run ends; this flag skips it entirely
   (propagates to the `--async` detached worker). No `--keep-log` / delete-by-default exists.
 - **`--steer`** is synchronous and in-process: it cannot combine with `--json` or `--async` (exit `2`).
   It accepts steering commands on stdin at declared action boundaries for interactive control.
@@ -258,11 +260,11 @@ the operator accepts it, and never hot-edit a running workflow's shell in place.
 spur workflow validate <file> [--no-schema] [--json]
 spur workflow show      <file> [--format <mermaid|todo>] [--json]
 spur workflow run      <file> [--run-id <id>] [--vars <json>] [--dry-run] [--async] [--no-plan] [--quiet/--silent/--verbose] [--detail <level>] [--trace-file] [--no-log] [--steer] [--json]
-spur workflow continue [run-id] [--yes] [--answer <yes|no|cancel>] [--async] [--no-log] [--json]
+spur workflow continue [run-id] [--yes] [--answer <yes|no|cancel>] [--answer-text <text>] [--async] [--no-log] [--json]
 spur workflow cancel   <run-id> [--json]
 spur workflow clean    [--older-than <minutes>] [--force] [--logs] [--dry-run] [--json]
 spur workflow list     [--json]
-spur workflow trace    [run-id] [--workflow <name>] [--status <s>] [--since <iso>] [--last <n>] [--follow] [--poll <ms>] [--output] [--json]
+spur workflow trace    [run-id] [--workflow <name>] [--status <s>] [--since <iso>] [--last <n>] [--follow] [--poll <ms>] [--output] [--timeout <ms>] [--json]
 spur workflow progress <run-id> [--json]
 ```
 
@@ -283,7 +285,7 @@ not advertise `--json-envelope` because its JSON projection is a kept-raw docume
 | `--verbose` | Include transitions and correlation diagnostics in human progress (implies `--detail full`). |
 | `--detail <level>` | Human detail level: `minimal`, `invocation` (default), or `full`. |
 | `--trace-file` | Append a redacted schema-versioned JSONL trace under `.spur/workflow/`. |
-| `--no-log` | Opt out of writing the consolidated `.spur/run/<RUNID>.log` (retained by default; propagates to `--async` workers). |
+| `--no-log` | Opt out of writing the two-file run record `.spur/run/<RUNID>.md` + `.state.json` (retained by default; propagates to `--async` workers). |
 | `--steer` | Accept in-process steering commands on stdin at declared action boundaries (sync only; incompatible with `--json`/`--async`). |
 
 `validate` and `run` exit non-zero on failure (`run` exits non-zero when the final status is not
@@ -300,32 +302,51 @@ Follow a live run to terminal (human streaming mode):
 ```bash
 spur workflow trace <run-id> --follow            # stream until terminal (default 1000ms poll)
 spur workflow trace <run-id> --follow --poll 500 # poll every 500ms
-spur workflow trace <run-id> --follow --output   # stream .spur/run/<RUNID>.log instead of the DB timeline
+spur workflow trace <run-id> --follow --output   # stream .spur/run/<RUNID>.md instead of the DB timeline
+spur workflow trace <run-id> --follow --timeout 600000 # bound the watch; timeout → one checkpoint, run continues, exit 1
 ```
 
 - **`--follow`** replays a run timeline and polls persisted state until it becomes terminal. It
   requires a `run-id` (exit `2` without one) and cannot combine with `--json` (exit `2` - it is a
   human streaming mode).
 - **`--poll <ms>`** sets the follow polling interval (default `1000`, minimum `50`; exit `2` otherwise).
-- **`--output`** swaps the follow source from the structured DB timeline to the consolidated all-in-one
-  log (`.spur/run/<RUNID>.log`, tail -f equivalent), streaming new lines as they land and exiting at
-  terminal status. It requires `--follow` and a `run-id`, is a human stream (rejects `--json`), and is
-  a **distinct source** — it never interleaves with the DB timeline. If the log never appears (e.g. the
+- **`--timeout <ms>`** (requires `--follow`, positive integer; otherwise exit `1` with `VALIDATION_FAILED`)
+  bounds the watch (0930): when the deadline passes before the run is terminal — including the `Run not
+  found` registration retry window — the follow prints one checkpoint naming the run id and last observed
+  status and exits `1`. A watch timeout never cancels or relaunches the run; resume by re-running the same
+  follow command.
+- **`--output`** swaps the follow source from the structured DB timeline to the human run record
+  (`.spur/run/<RUNID>.md`, tail -f equivalent), streaming new lines as they land and exiting at
+  terminal status. A pre-0925 run with only a legacy `<RUNID>.log` is followed in place (read-only
+  fallback). It requires `--follow` and a `run-id`, is a human stream (rejects `--json`), and is
+  a **distinct source** — it never interleaves with the DB timeline. If no record file appears (e.g. the
   run was started with `--no-log`), a clear message is printed at terminal status rather than hanging.
-  No `spur workflow monitor` verb exists; `--output` is the log-streaming surface.
+  No `spur workflow monitor` verb exists; `--output` is the record-streaming surface.
 
 HITL pause/resume: a run that hits a HITL action pauses; resume with `spur workflow continue [run-id]`
 (`--yes` skips confirmation). A headless `hitl.confirm` persists a default `no` before pausing -
-use `--answer yes|no|cancel` to inject the operator's gate answer before guard re-evaluation (0433).
-`--answer` is distinct from `--yes`: `--yes` skips the CLI resume prompt, `--answer` sets the HITL
-gate answer. 0901: resumes accept interrupted runs too (rerun-enter re-executes the interrupted
+use `--answer yes|no|cancel` to inject the operator's gate answer before guard re-evaluation (0433),
+or `--answer-text <text>` to answer an input gate with free text (H1 R27). `--answer` is distinct from
+`--yes`: `--yes` skips the CLI resume prompt, the answer flags set the HITL gate answer. Answer flags
+are validated against the pending gate kind (`--answer` requires a confirm/select gate,
+`--answer-text` an input gate; both together are rejected; a mismatch exits 2 with the run still
+paused), and `--answer`/`--answer-text` honor the gate's `options.var` instead of assuming the
+default var. 0901: resumes accept interrupted runs too (rerun-enter re-executes the interrupted
 node and needs `resumeRerun: true` on the target state); a headless (`--json`/non-TTY) continue
-without `--answer` is refused (exit 2); `--async` detaches the resume and reports started/failed
+without `--answer` or `--answer-text` is refused (exit 2); `--async` detaches the resume and reports started/failed
 after the worker claims the run; resumed runs write the consolidated run log and pass shell
 streams through the secret redactor + 64 KiB tail unless `--no-log`. Cancel one live/paused run
 with `cancel <run-id>`; bulk-finalize orphans stuck in
 `running`/`pending` with `clean` (`--older-than` default 30 minutes, or `--force`).
 
+Replay posture (0916): no canonical workflow opts into rerun-enter today — every state relies on
+the engine's refusal default, so an interrupted resume into an unmarked state is refused and the
+next safe action is the printed status (resume `paused` runs directly; recover crashed `running`
+runs via `clean`, which sweeps them to `interrupted`). Enabling `resumeRerun: true` on a canonical
+state requires demonstrated repeatability evidence and a conscious update to the replay matrix in
+`packages/app/tests/workflow/replay-matrix.test.ts`; mutating steps behind `pause: true` gates are
+safe by construction because paused resumes skip-enter.
+
 **Schema resolution parity (0431):** `validate` and `run` both load the workflow through
 `WorkflowAppService` with the same `embeddedSchemaOptions()` map the CLI injects for
 `@gobing-ai/spur/schemas/...` refs. `run` pre-loads then calls the engine with the loaded def
@@ -342,7 +363,8 @@ redirecting `agent.run` stages (ADR-047).
 - **Run-log reclamation** (0429): removes retained `.spur/run/<RUNID>.log` files whose mtime is older
   than `workflow.logRetentionDays` in `.spur/config.yaml` (default 30 days; integer days, not minutes).
   Age is the only gate; best-effort deletes never abort the rest. Never touches
-  `.spur/workflow/<RUNID>.jsonl` or `*-partial.md`.
+  `.spur/workflow/<RUNID>.jsonl` or `*-partial.md`. Scope stays legacy `.log` names only (0925 R4):
+  the two-file record (`.md` + `.state.json`) is not reclaimed until a pair retention policy exists.
 - **`--logs`** scopes to log reclamation only (skips stale-run finalization). `--dry-run` applies to
   both scopes (lists what would be removed, writes nothing). `--json` returns
   `{ olderThanMinutes, dryRun, cleaned, logs: { retentionDays, dryRun, reclaimed, failures } }` (with

package/plugins/sp/skills/spur-dev/SKILL.md

@@ -92,9 +92,15 @@ pick task (spur task list --json)
 The pipeline (`kind: state-machine`) runs the work loop:
 
 ```
-precheck → implement → test → review → approve(HITL) → verify → record → done
+precheck → implement[→escalate(HITL)] → test → review → approve(HITL) → verify → record → done
 ```
 
+**Escalation contract (0933).** The implement agent may pause on an operator question: it writes
+`.spur/run/<wbs>-question.md` and exits 0; the `escalate` hop surfaces it via HITL and pauses the
+run. Resume with `spur workflow continue --answer-text <answer>` — the guard appends the Q/A to
+`.spur/run/<wbs>-escalation.md` and re-enters implement (transcript via `--escalation-file`).
+`maxEscalations` (default 2) bounds the loop; exhausted or empty answer → `failed`. Implement only.
+
 Full procedure: **[references/execution-workflow.md](references/execution-workflow.md)**.
 Host-session procedure: **[references/inline-pipeline-driver.md](references/inline-pipeline-driver.md)**.
 
@@ -162,9 +168,10 @@ CLI does.
 - Before accepting a child/watcher result, compare its run ID with the dispatched run ID and check
   current trace state through Spur. If using a run log as evidence, require its mtime to be at least
   the dispatch time. A mismatch or stale timestamp is not completion evidence. Do not scrape terminals.
-  Bound each watch invocation to 10 minutes or 20 polls, whichever comes first; persist the last
-  confirmed identity/state and report a checkpoint before continuing. A watcher timeout does not
-  cancel the owned run or authorize launching a replacement.
+  Bound each watch invocation to `spur workflow trace <run-id> --follow --timeout 600000` — one
+  bounded call, no hand-rolled poll loop; a timeout prints one checkpoint line and exits 1 while the
+  run continues, so persist the last confirmed identity/state and report the checkpoint before
+  continuing. A watcher timeout does not cancel the owned run or authorize launching a replacement.
 - Mark superseded scratch with `SUPERSEDED` and a pointer to the authoritative task Design. Never
   let a scratch instruction override the live task, even when its old run is still readable.
 - Checker-policy changes require one explicit unsuppressed audit (T10); ordinary corpus commit

package/plugins/sp/skills/spur-dev/references/cross-cutting.md

@@ -61,6 +61,18 @@ The explicit-rejection carve-out above was superseded by ADR-087 (task 0687): a
 substitutes tier resolution with a warning instead of rejecting — see the substitution blockquote
 above and `resolveAgent` in `packages/app/src/services/agent-service.ts`.
 
+### Run-scoped session policy (B7, summary)
+
+When an inline resolution dispatches a native subagent, or a workflow `agent.run` executes, the
+run-scoped session policy applies: coder stages default to `session: reuse`; reviewer, planner,
+and scribe stages default to `fresh`; a reviewer stage may declare `session: reuse` explicitly.
+A runner record without resume capability (`supportsResumeById: false`) forces a fresh dispatch,
+and a disabled pinned executor re-resolves once, then starts fresh. Run traces record the session
+provenance (`reused | fresh`). This is a summary only: the owning contract is
+[session-pinned-dispatch.md §4](../../../../../docs/design/session-pinned-dispatch.md) with role
+semantics in [roles.md](../../../references/roles.md); this section does not restate that
+contract.
+
 ### Objective triggers override the answer
 
 The one rule resolves operator *intent*. A trigger is a detected *requirement* the chosen executor
@@ -188,8 +200,15 @@ Do not read provider auth or quota from `spur agent doctor`. The doctor resolves
 config), so it historically degraded to `status: usable · auth: no · model: unknown` for GLM-style
 executors and was useless as a preflight gate. Feature B4 removed the auth signal from the surface
 entirely (no column, no `authenticated` in `--json`) precisely so nothing can read it by mistake;
-the precheck probe classifies on usability alone. Exhaustion is detected mid-run by the escalation
-classifier, not by any preflight probe.
+the precheck probe classifies on usability alone. Preflight availability does exist — as a
+separate, owned surface (session-pinned-dispatch.md §3.4): `spur agent usage` captures provider
+quota windows into a durable snapshot, the availability drain derives `quota.exhausted` /
+`quota.recovered` observations from it, and `spur agent doctor` renders the provenance (`owner`,
+`since`, `reason`, snapshot `age`). A snapshot older than `agent.usage.maxAgeMs` renders `stale`
+and never enables an executor. Usability (doctor) is not authentication, and neither is a live
+quota guarantee — the signals stay distinct. Mid-run exhaustion is still detected by the
+escalation classifier; the preflight surface informs planning, it does not replace the in-run
+detector.
 
 ### Explicit subprocess surfaces are unchanged
 
@@ -493,7 +512,10 @@ iterating one task).
 
 **The rule.** When a test fails and you are iterating to green:
 
-1. Run the narrow target first: `bun test <file> --test-name-pattern <test>`.
+1. Run the narrow target first: `bun test <file> --test-name-pattern <test>`. Workspace tests need
+   the workspace `bunfig.toml` preload — invoke them as a subshell `(cd <workspace> && bun test …)`
+   or with absolute paths, because the shell's cwd persists between calls and a bare `cd` breaks
+   later relative-path commands (verifyall session friction, 2026-09-23).
 2. Loop on that narrow target until green.
 3. **Then** run the single full `spur-check` (or `bun run check`) as the final gate.
 

package/plugins/sp/skills/spur-dev/references/dev-operations.md

@@ -352,8 +352,8 @@ must not be changed without updating the backing skill.
 ### 13. runall
 
 - **Purpose:** Run a batch of tasks through their pipelines in dependency-correct order — resolve a set, topo-sort, run each via `task-pipeline.yaml`, inspect verdicts, apply the failure policy, emit a batch report.
-- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default halts on first failure). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2); scoped: `L4.scenario-unverified` (expected pre-run state of any not-yet-run feature) is reported verbatim but does not abort — any other strict error aborts. Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` after the batch completes, `--next` chains each task to terminal status then runs the wrap hop **once for the batch**, `--continue` resumes from checkpoint.
-- **Three orthogonal axes (do not confuse):** `--keep-going` = batch failure policy (halt vs skip dependents); `--continue` = resume from checkpoint (pick up an interrupted batch); `--next` = per-task lifecycle chaining (advance status on a verdict — `dev-verify`/`dev-verifyall` only). `routing-table.md` offers `--continue` and `--next` as competing options for the same situation only when the batch was interrupted mid-run; otherwise they address different problems.
+- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default halts on first failure). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2); scoped: `L4.scenario-unverified` (expected pre-run state of any not-yet-run feature) is reported verbatim but does not abort — any other strict error aborts. Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` **once for the batch** over the `done` subset only (execution-batch.md Step 6: `vars.feature` only when every frozen task is `done`/`cancelled`; empty done subset skips with a reason), `--next` chains each task to terminal status then runs the same batch-once wrap, `--continue` resumes from checkpoint.
+- **Three orthogonal axes (do not confuse):** `--keep-going` = batch failure policy (halt vs skip dependents); `--continue` = resume from checkpoint against the batch's original frozen identity (execution-batch.md § Batch continuation, task 0919); `--next` = per-task lifecycle chaining (advance status on a verdict — `dev-verify`/`dev-verifyall` only). `routing-table.md` offers `--continue` and `--next` as competing options for the same situation only when the batch was interrupted mid-run; otherwise they address different problems.
 - **Backing:** `sp:spur-dev` skill, `runall` operation → delegates the driver loop to the **`sp:super-planner`** agent (the batch orchestrator).
 - **Behavior:** The orchestrator reads [execution-batch.md](execution-batch.md) and drives: resolve selector → freeze set → topo-sort by `dependencies[]` (Kahn, WBS-ascending tie-break; cycle aborts) → resolve out-of-set deps by status (done → allow, else → block subtree) → run each task via `spur workflow run task-pipeline.yaml --async` + `spur workflow trace` polling → inspect terminal state + `.spur/run/<wbs>-verdict.json` → stop-the-batch default or `--keep-going` subtree skip → emit batch report. Per-task pipeline is invoked **verbatim** — no new FSM, no step edits. `--auto`/`--agent` are the only flags that cross the orchestrator→pipeline boundary (both into per-task `--vars`).
 - **Delegation:** `Skill(skill="sp:spur-dev", args="runall $ARGUMENTS")` → `sp:super-planner` agent.