@gobing-ai/spur 0.3.95 → 0.3.97

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

@@ -23,12 +23,12 @@ 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` |
 | `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 agent specs with `--specs` (live run status + member session merged from `spur serve`) | `--specs` `--server <url>` `--json` |
-| `status` | Agent specs with live process status and member session (requires `spur serve`) | `--server <url>` `--json` |
+| `list` | List detected coding agents, or agent specs with `--specs` (live run status + member session merged from `spur self serve`) | `--specs` `--server <url>` `--json` |
+| `status` | Agent specs with live process status and member session (requires `spur self serve`) | `--server <url>` `--json` |
 | `doctor [agent]` | Check agent readiness | `--json` `--probe-health` `--force-refresh` |
 | `usage` | Run-once provider usage capture (codexbar) → quota-owned availability refresh; scheduled externally | `--dry-run` `--source <name>` `--json` |
-| `start <spec-id>` | Start a supervised agent process (requires `spur serve`) | `--server <url>` `--json` |
-| `stop <spec-id>` | Stop a supervised agent process (requires `spur serve`) | `--server <url>` `--json` |
+| `start <spec-id>` | Start a supervised agent process (requires `spur self serve`) | `--server <url>` `--json` |
+| `stop <spec-id>` | Stop a supervised agent process (requires `spur self serve`) | `--server <url>` `--json` |
 
 `list`, `status`, `doctor`, `run`, `wait`, `start`, and `stop` accept `--json` plus `--json-envelope`. The hidden
 `loop` is a supervisor-internal process surface. **Exit codes:** `0` success, `1` failure, and `2`
@@ -85,7 +85,7 @@ justify it - but ensure the run executes in a context that can write the target
 
 ## `loop` - supervisor-internal self-draining wrapper (hidden)
 
-`spur agent loop --spec <id> [--poll <ms>]` is spawned by the `spur serve` supervisor for each
+`spur agent loop --spec <id> [--poll <ms>]` is spawned by the `spur self serve` supervisor for each
 materialized agent spec; it is hidden from `--help` and not an operator verb (use `spur agent start`).
 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
@@ -145,7 +145,7 @@ lists agent specs (`.spur/agents/*.yaml`) **with live run status merged from the
 supervisor**: each row carries a trailing status column
 (`running` / `stopped` / `errored` / `unknown`), `pid=<n>` where a process exists, and the member
 session (0897): the session mode plus a shortened resume id (`resume id=3f9c2a1d`), or `-` when the
-member has no recorded session. When `spur serve` is unreachable, the listing falls back to all
+member has no recorded session. When `spur self 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.
 
@@ -200,9 +200,9 @@ spur agent start worker-1
 spur agent start worker-1 --json
 ```
 
-Posts to the `spur serve` supervisor API
+Posts to the `spur self serve` supervisor API
 (`POST /api/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`
+reachable `spur self 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
@@ -250,7 +250,7 @@ unconfirmed or failed. For `skipped`/`pending` the printed target is intent only
 0 * * * * /opt/homebrew/bin/spur agent usage >> /tmp/spur-agent-usage.log 2>&1
 ```
 
-`spur serve` never invokes the producer (asserted by a test, design R4).
+`spur self serve` never invokes the producer (asserted by a test, design R4).
 
 ### Flags
 
@@ -285,7 +285,7 @@ one never re-sends settled work; only never-started deliveries release and redel
 - **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 fleet orchestrator.** The `spur serve` supervisor drives the lifecycle: `spur agent
+- **Not the fleet orchestrator.** The `spur self serve` supervisor drives the lifecycle: `spur agent
   start` / `stop` manage supervised processes and `agent list --specs` reports live state.
 
 ## See also

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

@@ -181,11 +181,16 @@ planning reference, then apply accepted deterministic changes through `spur feat
 ## The gate — `check --json`
 
 ```bash
-spur feature check H2 --json        # one feature
-spur feature check --json           # whole tree
-spur feature check --strict --json  # warnings → failures
+spur feature check H2 --json                       # one feature
+spur feature check --json                          # whole tree
+spur feature check --strict --json                 # warnings → failures
+spur feature check H2 --inventory <eval-report.md> # also cross-check AC ↔ requirement inventory
 ```
 
+With `--inventory <report>`, the `inventory-coverage` finding (1004 R1, unsuppressible error layer)
+fails the check when a `## Requirement inventory` item has no covering scenario (`# covers: I<n>`)
+and is not `[deferred: ...]`; a missing/empty inventory section is itself an error.
+
 The 4-layer validator (frontmatter, AC syntax, children-limit/structure, L4 traceability) emits its
 verdict and findings as a JSON **array**, one entry per feature (`jq '.[0].pass'`, `.[0].findings[].code`),
 like `spur task check --json`. Gherkin AC must keep its `Feature:` line (`L3.ac-bdd-error`) and
@@ -207,15 +212,21 @@ see the proposed status hop.
 spur feature sync H2 --json                    # one feature
 spur feature sync H2 --dry-run --json          # propose only, no write
 spur feature sync --all --json                 # every feature with linked tasks
-spur feature sync H2 --force                   # apply a reopen proposal without confirmation
+spur feature sync H2 --force                   # re-derive live: bypass replay + apply a reopen without confirmation
 spur feature sync H2 --folder docs/custom-tasks --json   # non-default tasks folder
 ```
 
 - **`[id]`** syncs one feature; **`--all`** syncs every feature with linked tasks. One of the two is
   required - exit `2` if neither is given.
 - **`--dry-run`** reports proposed transitions without applying. **`--force`** applies a *reopen*
-  proposal (status moving backward) without interactive confirmation.
-- **`--json`** single-feature emits `{ proposal, applied, appliedHops[] }`; `--all` emits
+  proposal (status moving backward) without interactive confirmation **and** bypasses blocked-sync
+  replay (below).
+- **Blocked-sync suppression (1004 R3):** a BLOCKED outcome is persisted at
+  `.spur/run/feature-sync-blocked-<id>.json` with an input fingerprint (feature content, linked
+  task statuses, verdict mtimes); an identical next call replays the prior result
+  (`suppressed: true`) instead of re-deriving. A changed input, `--force`, or a non-blocked
+  outcome re-derives/clears. Dry-run never reads or writes the state.
+- **`--json`** single-feature emits `{ proposal, applied, appliedHops[], suppressed? }`; `--all` emits
   `{ totalFeatures, evaluated, updatedCount, results[] }` where each result is the single-feature
   shape. `proposal` is
   `{ featureId, from, to, reason, requiresConfirm?, gateBlocked?, gateFindings?, hops? }`.

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

@@ -1,11 +1,11 @@
 ---
 name: init
-description: "spur-cli noun reference for `spur init` and `spur status`: CLI verbs (init scaffold with --name/--force/--minimal, status with --json) plus post-scaffold init validation for /sp:spur-init - Phase 1.5 functional-validation probes and Phase 1.6 rule-glob adaptation."
+description: "spur-cli noun reference for `spur self init` and `spur self status`: CLI verbs (init scaffold with --name/--force/--minimal, status with --json) plus post-scaffold init validation for /sp:spur-init - Phase 1.5 functional-validation probes and Phase 1.6 rule-glob adaptation."
 see_also:
   - spur-cli
 ---
 
-# spur init / spur status - CLI verbs and post-scaffold validation
+# spur self init / spur self status - CLI verbs and post-scaffold validation
 
 ## CLI verbs
 
@@ -14,14 +14,14 @@ see_also:
 | `init` | Scaffold a new Spur project in the current directory | `--name <name>` `--force` `--minimal` `--json` |
 | `status [path]` | Show project and git status for a Spur project | `--json` |
 
-### `spur init` - scaffold a Spur project
+### `spur self init` - scaffold a Spur project
 
 ```bash
-spur init                            # interactive: prompt for project name
-spur init --name my-project          # non-interactive
-spur init --name my-project --force  # overwrite existing .spur/ files
-spur init --minimal                  # skip optional scaffolding (rules, workflows)
-spur init --json                     # machine-readable
+spur self init                            # interactive: prompt for project name
+spur self init --name my-project          # non-interactive
+spur self init --name my-project --force  # overwrite existing .spur/ files
+spur self init --minimal                  # skip optional scaffolding (rules, workflows)
+spur self init --json                     # machine-readable
 ```
 
 Materializes the `.spur/` directory tree with config, docs, rules, and workflow templates. The
@@ -34,14 +34,15 @@ post-scaffold validation probes (Phase 1.5 / 1.6, below) run immediately after t
 | `--name <name>` | Project name (skips interactive prompt). |
 | `--force` | Overwrite existing `.spur/` files. Without it, existing files are preserved. |
 | `--minimal` | Skip optional scaffolding (rules presets, workflow templates). Core config + docs only. |
+| `--adopt-global-config` | Also rewrite `~/.config/spur/config.yaml` from the shipped global default (backed up first). Opt-in only. |
 | `--json` | Output machine-readable JSON instead of interactive summary. |
 
-### `spur status [path]` - project and git status
+### `spur self status [path]` - project and git status
 
 ```bash
-spur status                          # current directory
-spur status /path/to/project         # specific project
-spur status --json                   # machine-readable
+spur self status                          # current directory
+spur self status /path/to/project         # specific project
+spur self status --json                   # machine-readable
 ```
 
 Reports the project's Spur configuration state (init status, feature/task counts, rule preset
@@ -50,11 +51,11 @@ directory.
 
 ## Post-scaffold validation
 
-Two probes sit between the deterministic scaffold (`spur init`) and the non-deterministic doc
+Two probes sit between the deterministic scaffold (`spur self init`) and the non-deterministic doc
 customization: Phase 1.5 (functional validation) confirms the fresh tree is immediately functional;
 Phase 1.6 (rule glob adaptation) rewrites layout-dependent rule globs so `recommended-pre-check`
 runs clean on this project's layout. The executing agent owns content *adaptation* only — `spur
-init` owns *file materialization* (`04_DESIGN.md` §1.1 "Init ownership contract").
+self init` owns *file materialization* (`04_DESIGN.md` §1.1 "Init ownership contract").
 
 ### Phase 1.5 — Functional validation probe
 
@@ -62,8 +63,8 @@ Before any customization, confirm the fresh scaffold is immediately functional.
 fails, STOP and report the gap rather than papering over it with customization:
 
 ```
-spur status
-spur task create "__probe__" --template standard   # confirms task template + matrix resolve
+spur self status
+spur task create "__probe__" --template standard --skip-ready   # no model dispatch; confirms task template + matrix resolve
 spur workflow validate task-pipeline.yaml
 ```
 

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

@@ -17,7 +17,7 @@ top-level forms are omitted from `spur --help`, leaving `self` as the visible su
 
 | Verb | Purpose | Key flags |
 | ---- | ------- | --------- |
-| `init` | Scaffold a new Spur project in the current directory | `--name <name>` `--force` `--minimal` `--json` |
+| `init` | Scaffold a new Spur project in the current directory | `--name <name>` `--force` `--minimal` `--adopt-global-config` `--json` |
 | `maintain` | Run database maintenance: PRAGMA optimize, WAL truncation, optional VACUUM | `--vacuum` `--json` |
 | `migrate` | Apply CLI-owned schema migrations | `--json` |
 | `serve` | Start the Spur web server (local fallback) | `--port <n>` `--host <addr>` `--no-open` `--cwd <path>` `--json` |
@@ -40,7 +40,8 @@ spur self init --json                 # machine-readable
 
 Materializes the `.spur/` directory tree with config, docs, rules, and workflow templates. Flags:
 `--name <name>` (default: current directory name), `--force` (recreate existing files), `--minimal`
-(skip optional scaffolding), `--json` (machine-readable output). Post-scaffold validation probes
+(skip optional scaffolding), `--adopt-global-config` (also rewrite `~/.config/spur/config.yaml` from
+the shipped global default, backed up first), `--json` (machine-readable output). Post-scaffold validation probes
 (Phase 1.5 / 1.6) run immediately after this verb completes — see **[init.md](init.md)** for the
 probe protocol and rule-glob adaptation procedure.
 

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

@@ -1,13 +1,13 @@
 ---
 name: spur-cli-serve
-description: "spur-cli noun reference: operate `spur serve` as the local web-server fallback - start the Hono/Cloudflare-Worker server that backs the web Task Kanban and the supervisor API. Single verb, five flags."
+description: "spur-cli noun reference: operate `spur self serve` as the local web-server fallback - start the Hono/Cloudflare-Worker server that backs the web Task Kanban and the supervisor API. Single verb, five flags."
 see_also:
   - spur-cli
 ---
 
-# spur serve - local web server
+# spur self serve - local web server
 
-`spur serve` starts the **Spur web server** - a local Hono / Cloudflare-Worker server that serves
+`spur self serve` starts the **Spur web server** - a local Hono / Cloudflare-Worker server that serves
 the web Task Kanban and exposes the supervisor API (`/api/processes/*` + `/api/agents/*`). It is the local fallback
 when no remote server is configured.
 
@@ -22,10 +22,10 @@ when no remote server is configured.
 ## `serve` - start the web server
 
 ```bash
-spur serve                          # default: localhost:3000, opens browser
-spur serve --port 8080 --host 0.0.0.0
-spur serve --no-open                # skip browser
-spur serve --json                   # dry probe: print { port, url, pid, running } and exit
+spur self serve                          # default: localhost:3000, opens browser
+spur self serve --port 8080 --host 0.0.0.0
+spur self serve --no-open                # skip browser
+spur self serve --json                   # dry probe: print { port, url, pid, running } and exit
 ```
 
 Starts the server with the Hono app backed by the local SQLite database. The web Task Kanban and
@@ -46,14 +46,14 @@ the supervisor API become available at `http://<host>:<port>`.
 
 ## What this skill is NOT
 
-- **Not the agent supervisor.** `spur serve` hosts the supervisor API; `spur agent start` / `stop` /
+- **Not the agent supervisor.** `spur 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 `spur serve`.
+  Worker build (`apps/server/`), not `spur self serve`.
 
 ## See also
 
-- **`spur agent` (see [agent.md](agent.md))** - `start`/`stop`/`list --specs` require `spur serve`
+- **`spur agent` (see [agent.md](agent.md))** - `start`/`stop`/`list --specs` require `spur self 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/section-editing.md

@@ -58,16 +58,20 @@ exactly: `Background`, `Requirements`, `Acceptance Criteria`, `Q&A`, `Design`, `
 `spur task record 0040 --transition testing` reads `.spur/run/0040-verdict.json`, writes
 `Testing` (per-requirement table), and backfills `Review` (P1–P4 findings table) **only when the
 section is bare** — a standalone compatibility fallback, never an overwrite of the review
-coordinator's authored Review — optionally backfilling a bare `Solution` from `git diff -U0`. It
-never transitions to `done`.
+coordinator's authored Review — optionally backfilling a bare `Solution` from `git diff -U0`.
+Record can also refresh its own earlier Review backfill. The `--transition testing` example stops
+at testing; `--transition done` with a PASS verdict walks the forward lifecycle edges through their
+guards and creates the required pipeline run-link immediately before the done hop.
 
 - **Use `record`** when a verify step produced a verdict artifact — it is the pipeline's record step
   and the deterministic `Testing` writer.
 - **Use `update --section`** when you are authoring a section by hand (planning, design, narrative
   solution) or amending one `record` already wrote.
 
-`record` writes `Testing` unconditionally and `Review` only when bare; a later
-`update --section` overwrites either (file-wins). Both go through the same file-wins atomic write.
+`record` re-reads the verdict on each invocation. PASS/PARTIAL/FAIL artifacts refresh Testing;
+UNKNOWN preserves authored Testing and writes a stub only when Testing is bare. Review remains
+fallback-only: bare content or record's own earlier backfill can be replaced, authored Review cannot.
+A later `update --section` overwrites either section (file-wins). Both use the same atomic write.
 
 ## Which section, when
 
@@ -81,7 +85,7 @@ LLM's job (orchestrated by `sp:spur-dev`); this skill only owns the *mechanism*:
 | `Plan` | before `wip` | the step list |
 | `Solution` | during impl (implement step) | the approach actually taken; L3 `file:line` rule fires once it has real content |
 | `Testing` | testing phase (`record` — deterministic writer) | what was verified and how — gated at `wip→testing` by `check` |
-| `Review` | review phase (`/sp:dev-review` coordinator) | merged SECU findings + verdict — gated at `testing→done` by `check --strict-core` |
+| `Review` | review phase (`/sp:dev-review` coordinator) | merged SECU findings + verdict — gated at `testing→done` by `check --as done` |
 
 Section presence per status is a **runtime contract**, not a table: query
 `spur task sections <wbs> list --json` (permitted present sections) and `spur task check <wbs> --json`

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

@@ -24,8 +24,16 @@ blocking retry).
 | `--feature <id>` | Records `feature_id` in frontmatter; derives `Background` from the feature's `Goal` (L4 edge). |
 | `--parent <wbs>` | Groups under a parent WBS for sub-task decomposition. |
 | `--template <variant>` | Selects the section-matrix variant for the new file. |
+| `--skip-ready` | Keep the capture as-is: no ready preparation, no model dispatch. |
+| `--agent <selector>` | Agent used for ready preparation (default: the configured agent). Exit `2` when combined with `--skip-ready`. |
 | `--folder <path>` | Target a non-default tasks folder. |
-| `--json` | Emit `{ ref: { id, filePath } }`. |
+| `--json` | Emit `{ ref: { id, filePath }, wbs, filePath, readiness: { status, depth } }`. |
+
+**Ready by default (ADR-109):** after the capture is saved, `create` prepares the same WBS in place —
+model refine → deterministic post-check (`task check --as todo`) → promotion to `todo`.
+`readiness.status` is `ready`, `skipped` (`--skip-ready`), or `failed`. A failed preparation exits `1`
+with error code `preparation-failed` (`failedStage`, `recoveryCommand`, `findings`); the task file and
+its WBS are kept. `batch-create` takes the same two flags.
 
 (See also the full verb map in [tasks.md](../tasks.md).)
 
@@ -67,6 +75,10 @@ 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`.
+- **Estimate** (`--estimate-hours <n>`): sets the `estimate_hours` frontmatter field (positive number) —
+  the decomposition size estimate the inline pipeline driver reads.
+- **`--provenance-bypass`** (pair with `--force-done` and `--reason`): records an audited
+  provenance-bypass link when no pipeline run exists. Replaces the `SPUR_PROVENANCE_OVERRIDE` env var.
 - **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
@@ -339,8 +351,11 @@ column to distinguish AC rows from requirement rows:
 `AC-<i>` (which credits the scenario) and the task checkbox id `AC<i>` (which the box flip needs).
 Key the row **`AC<n> — <scenario title>`**, omitting the scenario's own `R<n>` label — then one row
 does both: `normalizeTitle` strips the `AC<n>` prefix so the row still matches the scenario title,
-and `prefixId` normalizes `AC<n>` so the box flips. A bare `AC<n>` credits no scenario; a bare
-`AC-<i>` flips no box; a title carrying the scenario's `R<n>` label matches neither.
+and `prefixId` normalizes `AC<n>` so the box flips. A bare `AC-<i>` also does both: `record`
+resolves it through the feature's scenario order to the AC line aliasing scenario *i*
+(`AC<k> — [R<n> — ]<scenario title>`) and flips that box — never the same-numbered `AC<i>`; with no
+aliasing line it flips nothing. A bare `AC<n>` credits no scenario; a title carrying the scenario's
+`R<n>` label matches neither.
 
 **Evidence rule (behavior-bearing AC):** an AC row with `status: MET` on a behavior-bearing id
 (no `[advisory]`/`[non-core]`/`[non-behavior]`/`[docs-only]` marker) MUST carry `test` or
@@ -410,9 +425,9 @@ unallocated.
 ## Command surface (quick)
 
 ```
-spur task create   <title> [--feature <id>] [--parent <wbs>] [--template <v>] [--dedupe-within <seconds>] [--allow-duplicate-name] [--folder] [--json]
+spur task create   <title> [--feature <id>] [--parent <wbs>] [--template <v>] [--dedupe-within <seconds>] [--allow-duplicate-name] [--skip-ready | --agent <selector>] [--folder] [--json]
 spur task show     <wbs> [--folder] [--json]
-spur task update   <wbs> [status] [--section <n> --from-file <p>] [--feature <id>] [--priority <p>] [--no-lifecycle] [--folder] [--json]
+spur task update   <wbs> [status] [--section <n> --from-file <p>] [--feature <id>] [--priority <p>] [--ac-numbering task-local] [--ac-altitude <a>] [--estimate-hours <n>] [--assignee <spec-id>] [--no-lifecycle] [--force-done --reason <text> [--provenance-bypass] [--verdict-dir <path>]] [--folder] [--json]
 spur task deps     <wbs> <set|add|remove|clear> [values...] [--folder] [--json]
 spur task sections <wbs> <init|add|list> [name] [--folder] [--json]
 spur task list     [--status <s>] [--phase <p>] [--parent <wbs>] [--feature <id>] [--folder] [--json]
@@ -420,7 +435,7 @@ spur task refresh  [--folder] [--json]
 spur task migrate  [--dry-run] [--folder] [--json]
 spur task migrate-anchors [--dry-run] [--json]
 spur task refresh-roster <wbs> [--folder] [--json]
-spur task batch-create --file <path> [--folder] [--json]
+spur task batch-create --file <path> [--skip-ready | --agent <selector>] [--folder] [--json]
 spur task record   <wbs> [--verdict-file <p>] [--solution-from-diff] [--transition <s>] [--folder] [--json]
 spur task verdict  <wbs> [--from-answer <p>] [--folder] [--json]
 spur task verifyall-aggregate [--from-file <path>] [--json]

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

@@ -38,9 +38,9 @@ re-reading or re-tokenizing the task.
 
 | Verb | Purpose | Key flags |
 | ---- | ------- | --------- |
-| `create <title>` | Allocate a new task (race-safe WBS) | `--feature <id>` `--parent <wbs>` `--template <variant>` `--dedupe-within <s>` `--allow-duplicate-name` `--folder` `--json` |
+| `create <title>` | Allocate a new task (race-safe WBS) | `--feature <id>` `--parent <wbs>` `--template <variant>` `--dedupe-within <s>` `--allow-duplicate-name` `--skip-ready` `--agent <selector>` `--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>` `--assignee <spec-id>` (exclusive with `--section`) `--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>` (exclusive with `--section`) `--feature <id>` `--priority <p>` `--ac-numbering task-local` `--ac-altitude <a>` `--estimate-hours <n>` `--no-lifecycle` `--force-done` `--reason <text>` `--provenance-bypass` `--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` |
@@ -48,10 +48,10 @@ re-reading or re-tokenizing the task.
 | `migrate` | One-time A17 corpus normalization pass | `--dry-run` `--folder` `--json` |
 | `migrate-anchors` | Qualify in-repo evidence anchors to repo-relative paths (0583 R1–R3) | `--dry-run` `--json` |
 | `refresh-roster <wbs>` | Regenerate a parent task's sub-task roster block in `## Plan` | `--folder` `--json` |
-| `batch-create` | Create many tasks from a validated JSON array | `--file <path>` `--folder` `--json` |
+| `batch-create` | Create many tasks from a validated JSON array | `--file <path>` `--skip-ready` `--agent <selector>` `--folder` `--json` |
 | `record <wbs>` | Write `Testing` from a verify verdict (deterministic); bare-`## Review` fallback only; optional Solution + transition | `--verdict-file <path>` `--solution-from-diff` `--transition <status>` `--folder` `--json` |
 | `verdict <wbs>` | Derive PASS/PARTIAL/FAIL/UNKNOWN from verify answer text → verdict JSON; see [answer-file shape](tasks/verbs.md#answer-file-shape-what---from-answer-parses) | `--from-answer <path>` `--folder` `--json` |
-| `check [wbs]` | Four-layer validation; `--fix` repairs structure; `--corpus` is the explicit unsuppressed audit | `--strict` `--as <status>` `--strict-core` `--fix` `--folder` `--corpus` `--since <ref>` `--json` |
+| `check [wbs]` | Four-layer validation; `--fix` repairs structure; `--corpus` is the explicit unsuppressed audit; `--precheck` adds the pipeline precheck gate (size + evidence channel, WBS required) | `--strict` `--as <status>` `--strict-core` `--precheck` `--fix` `--folder` `--corpus` `--since <ref>` `--json` |
 | `resolve <file-path>` | Map a file path to its owning task WBS | `--strict` `--folder` `--json` |
 | `path <wbs>` | Map a WBS to its absolute task file path (inverse of `resolve`) | `--folder` `--json` |
 | `run-link <wbs>` | Record pipeline run provenance link for task | `--source <src>` `--run-id <id>` `--json` |
@@ -73,6 +73,11 @@ spur task create "Add email validation" --feature H2 --parent 0040
 - **`--template <variant>`** selects the section-matrix variant that shapes the new file's sections:
   `standard·feature-impl·issue·review·meta·brainstorm`. The default is **`feature-impl` when
   `--feature` is given, else `standard`**. An unknown variant is exit `2`.
+- **Ready by default (ADR-109):** `create` and `batch-create` dispatch a model to prepare the new task
+  to ready (refine → `task check --as todo` post-check → promotion to `todo`). Pass **`--skip-ready`**
+  for a plain capture with no model dispatch; **`--agent <selector>`** picks the preparing agent.
+  `--json` carries `readiness: { status: ready|skipped|failed, depth }`; a failed preparation exits `1`
+  (`preparation-failed`) and keeps the task.
 
 The same `--template` axis drives both *which sections the new file carries* (per the
 Section-Status-Matrix) and *its creation status*: a spec'd task (a `--feature` link, or a batch item
@@ -271,7 +276,7 @@ spur task check --json              # whole corpus
 spur task check 0040 --json         # one task
 spur task check --strict --json     # elevate ALL warnings to failures
 spur task check 0040 --as done        # evaluate as the done row (lifecycle target, F92 R2)
-spur task check 0040 --strict-core    # temporary compatibility alias
+spur task check 0040 --strict-core    # compatibility alias; not the done gate (use --as done)
 ```
 
 **Folder resolution (task 0522):** a WBS-targeted check (`<wbs>` present, no `--folder`) resolves
@@ -291,9 +296,10 @@ The two flags are distinct gate profiles:
 - **`--strict`** elevates *all* warnings to failures (the strictest reading).
 - **`--as <status>`** evaluates the task as if it were already in `<status>` (F92 R2); the lifecycle
   guards pass the transition target. Validated against canonical task statuses; excluded with `--corpus`.
-- **`--strict-core`** is a **temporary compatibility alias** (F92 R2). Fails only on hard-core errors — Solution `file:line`, Review P1–P4, and
-  `gate:true` required-section misses — *without* the blanket elevation. This is the variant wired
-  as the `testing→done` lifecycle guard.
+- **`--strict-core`** is a **compatibility alias** (F92 R2) kept so installed plugins/workflows that
+  call it keep working. It runs the default severity computation against the task's *current* status
+  and is no longer meaningful on its own. The lifecycle guards are `--as testing` (`wip→testing`) and
+  `--as done` (`testing→done`); use `--as <status>` for gate checks.
 
 See [tasks/verbs.md](tasks/verbs.md) for the JSON shape per finding.
 

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

@@ -204,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 run record .spur/run/<RUNID>.md + .state.json
+spur workflow run ./workflows/approval.yaml --no-log               # opt out of the run record .spur/memory/runs/<RUNID>.md + .state.json
 spur workflow run ./workflows/approval.yaml --steer                # interactive steering on stdin
 ```
 
@@ -214,7 +214,7 @@ 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 two-file run record (`.spur/run/<RUNID>.md` + `.state.json`).
+- **`--no-log`** opts out of writing the two-file run record (`.spur/memory/runs/<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`).
@@ -285,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 two-file run record `.spur/run/<RUNID>.md` + `.state.json` (retained by default; propagates to `--async` workers). |
+| `--no-log` | Opt out of writing the two-file run record `.spur/memory/runs/<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
@@ -302,7 +302,7 @@ 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>.md instead of the DB timeline
+spur workflow trace <run-id> --follow --output   # stream .spur/memory/runs/<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
 ```
 
@@ -316,7 +316,7 @@ spur workflow trace <run-id> --follow --timeout 600000 # bound the watch; timeou
   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
+  (`.spur/memory/runs/<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
@@ -360,15 +360,18 @@ redirecting `agent.run` stages (ADR-047).
 
 - **Stale-run finalization** (existing): bulk-finalizes orphaned `running`/`pending` runs as `failed`.
   `--older-than <minutes>` (default 30) and `--force` (all non-terminal regardless of age) apply here only.
-- **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`. 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
-  `--logs`, the reclamation object alone).
+- **Run-log reclamation** (0429): removes expired `.log` files from `.spur/memory/runs/`
+  and legacy `.spur/run/`, using `workflow.logRetentionDays` (default 30 days). Non-terminal
+  runs, including paused/interrupted runs, are protected; ownership lookup failures preserve logs.
+  The two-file record (`.md` + `.state.json`) and partial handoffs are retained.
+- **Checkpoint reclamation**: removes expired terminal checkpoints only when confinement,
+  metadata and run-ownership guards pass. Recoverable runs remain protected.
+- **Migration** (E71): verified lasting scratch data is preserved and references redirected before
+  reclamation. Unsettled imports, live dependencies, malformed files and conflicts retain their sources.
+- **`--logs`** scopes to log reclamation and its migration (skips stale-run finalization and
+  checkpoint reclamation). `--dry-run` reports without copying or deleting. `--json` returns
+  `{ olderThanMinutes, dryRun, cleaned, logs, checkpoints, migration }`; with `--logs`, it returns
+  `{ retentionDays, dryRun, reclaimed, failures, migration }`.
 
 ## Behavior
 

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

@@ -206,6 +206,8 @@ section adds what that table has no room for: per-file content summaries and ite
 step (glossary, config companions).** Read Step routing to find "which file for step X"; read below
 for "what's actually in file Y" or for resources that sit outside the step sequence.
 
+- Job transfer: [dump/resume](references/dev-operations.md#11a-job-dump).
+
 - [references/glossary.md](references/glossary.md) — sp's own vocabulary: spine, competency, facade,
   corpus, gate, verdict, noun/verb, half, HITL, WBS, section-write contract — canonical term +
   Avoid list. Owns term definitions only; `cross-cutting.md` owns the process rules that use them.

package/plugins/sp/skills/spur-dev/references/ac-style-guide.md

@@ -125,7 +125,7 @@ Any of the four may additionally carry a **bracket tag** in any position — `[d
 `Scenario: [advisory] Foo`. Tags are stripped before matching (0398 R7), so tagging never breaks
 the linkage.
 
-Task-side, `verify-answer-lint` additionally accepts a fifth declared id source — a **bold-trajectory
+Task-side, the `spur task verdict` answer lint additionally accepts a fifth declared id source — a **bold-trajectory
 paragraph**: a whole-line `**AC id…**` paragraph inside the task's `### Acceptance Criteria`
 block (task 0817 R3). The id up to its first `:` and the paragraph's full spelling are both
 declared; two bold spans on one line are not a declaration (an interpolated bold id stays
@@ -141,7 +141,7 @@ unmatchable):
 
 ### A bullet's bold head is its id
 
-`verify-answer-lint` declares the bold span of a single-line criterion bullet
+The `spur task verdict` answer lint declares the bold span of a single-line criterion bullet
 (`- **AC2 — The roster runtime is gone (R3).** Given …, when …, then …`) and its head before the
 first ` — ` or `:` — so answer rows may key `AC2` or `AC2 — The roster runtime is gone (R3).`. Keep
 at least one answer row keyed to the verbatim feature scenario title the task graduates, and keep
@@ -222,7 +222,8 @@ Use the canonical BDD template at `templates/bdd/gherkin.md`. Key rules:
   ```
 
   Every inventory item without a `[deferred: ...]` marker must be covered by at least one
-  scenario — `idea-coverage-check` measures this at the idea-pipeline's ac-generate boundary.
+  scenario — the `feature check --inventory` gate (inventory-coverage finding) measures this at
+  the idea-pipeline's ac-generate boundary.
 
 Avoid:
 

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

@@ -22,7 +22,7 @@ not redefine it.
 > precedence chain, and the `implementAgent` override.** Every other reference (flag-glossary,
 > execution-workflow, execution-batch, dev-operations, cmd_agent, cmd_workflow) links here and
 > does not restate the contract. The value table below is authoritative; parity with it is
-> enforced by `validate-flag-contracts.ts` (C3a/C3b).
+> enforced by `scripts/commands/validate-flag-contracts.ts` (C3a/C3b).
 
 ### The one rule
 
@@ -135,7 +135,9 @@ workflow run` and never redirect silently to `agent.default`. Interactive **omit
 **host-controlled and non-subprocess**, but no longer guarantees host-context execution for every
 model stage (task 0508): an eligible `agent.run` stage — pure-slash input, non-interactive state,
 native subagent with shared-worktree read/write/shell capability, and a task above the
-`estimate_hours` dispatch floor (2026-09-15 subagent-dispatch evaluation; the floor and the
+`estimate_hours` dispatch floor — a small, non-sensitive triage diffstat
+(`.spur/run/<wbs>-diffstat.json`, verify only) keeps that stage host-inline (2026-09-15
+subagent-dispatch evaluation; the floor and the
 resume-over-re-dispatch rule for worker-role continuation stages are owned by
 [inline-pipeline-driver.md](inline-pipeline-driver.md)) — dispatches **once** to that
 native subagent and joins before the driver continues; any pre-dispatch eligibility failure falls
@@ -289,8 +291,8 @@ Never edit a task or feature file directly. Every mutation goes through:
 
 The interactive `--next` step-chain (`dev-refine → dev-run → dev-verify → done`) moves a task's
 status with `spur task update <wbs> <status>` **without `--no-lifecycle`**, so the lifecycle guards
-run: `wip → testing` invokes `spur task check`, `testing → done` invokes
-`spur task check --strict-core`. A guard failure **stops the chain as review-pending** — leave the
+run: `wip → testing` invokes `spur task check --as testing`, `testing → done` invokes
+`spur task check --as done`. A guard failure **stops the chain as review-pending** — leave the
 task at its current status, surface the blocking finding, do not advance. This is the gate that
 keeps a malformed task out of `testing`/`done`.
 
@@ -455,7 +457,7 @@ Seven non-negotiable invariants for the spur-dev lifecycle. These are laws, not
 violation is a defect in the run, not a style choice. Every competency skill and the spine consume
 them; they live here because they cross every phase boundary.
 
-1. **NEVER skip the verification gate.** A task is not done until `spur task check <wbs> --strict-core`
+1. **NEVER skip the verification gate.** A task is not done until `spur task check <wbs> --as done`
    returns PASS and every AC scenario has a corresponding verify command that exited 0. "I tested it
    manually" is not verification evidence.
 2. **NEVER write to task/feature corpus outside the `spur` CLI.** Direct file edits to
@@ -463,7 +465,7 @@ them; they live here because they cross every phase boundary.
    under `.spur/memory/`. Every other mutation goes through `spur task` / `spur feature` so the
    schema, matrix, and traceability guards run.
 3. **NEVER mark a task done without a PASS verdict.** `testing → done` requires
-   `spur task check --strict-core` PASS and a recorded verdict. PARTIAL or FAIL verdicts leave the
+   `spur task check --as done` PASS and a recorded verdict. PARTIAL or FAIL verdicts leave the
    task at `testing` and surface to the operator.
 4. **NEVER proceed past a failed gate without explicit operator approval.** A failed
    `feature-check`, `batch-create`, `precheck`, `review`, or `verify` stops the run. The operator
@@ -783,10 +785,12 @@ The Design Approval Gate is the taste gate between system design and decompositi
 **Auto-mode behavior:**
 
 - `--auto` routes around taste HITL states BEFORE entry only when the matching pre-clear vars are
-  true. CLI **`--approve-taste`** (idea + plan) sets `design_approved=true` and, on the idea path,
-  also `idea_approved=true`. Aliases: `--design-approved` / `--idea-approved` set one var each.
-- Without explicit prior approval, `--auto` still pauses at idea-eval and design-approval — taste
-  gates are not auto-clicked (Auto-Decision Principle #5).
+  true. On the planning commands (`dev-idea`, `dev-plan`) CLI **`--auto`** sets `profile=auto`,
+  `design_approved=true`, and `idea_approved=true` — the planning exception to Auto-Decision
+  Principle #5 (reversible corpus writes; see flag-glossary `--auto`).
+- The bypass still follows the evidence: idea-eval continues only on a `proceed`/`reshape`
+  recommendation (`drop` cancels, missing pauses) and design-approval only on a PASS design check.
+  Direct `spur workflow run` callers that leave the pre-clear vars `false` keep both taste pauses.
 - The brainstorm design summary is ALWAYS recorded, regardless of `--auto` — `--auto` does not
   bypass the "nothing is too simple" pattern.