@gobing-ai/spur 0.4.14 → 0.4.16

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gobing-ai/spur",
-    "version": "0.4.14",
+    "version": "0.4.16",
     "description": "Spur CLI — local-first harness for mainstream coding agents: constraint checking, workflow orchestration, agent health, and history analytics. Bun-native; exposes the `spur` command.",
     "keywords": [
         "spur",
@@ -32,6 +32,7 @@
     "files": [
         "spur.js",
         "config",
+        "worker",
         "schemas",
         "board",
         "web",
@@ -49,7 +50,7 @@
         "dev": "bun run src/index.ts",
         "build": "bun run ../../scripts/spur-dev.ts build-cli",
         "build:binaries": "bun run ../../scripts/spur-dev.ts build-binaries",
-        "build:bundle": "bun run ../../scripts/spur-dev.ts bundle-web && bun run ../../scripts/spur-dev.ts emit-board-types && bun build src/index.ts --target=bun --outfile spur.js --external @johnhenry/backend-webgpu && bun run ../../scripts/spur-dev.ts bundle-config config && bun run ../../scripts/spur-dev.ts bundle-plugins",
+        "build:bundle": "bun run ../../scripts/spur-dev.ts bundle-web && bun run ../../scripts/spur-dev.ts emit-board-types && bun build src/index.ts --target=bun --outfile spur.js --external @johnhenry/backend-webgpu && bun run ../../scripts/spur-dev.ts bundle-config config && bun run ../../scripts/spur-dev.ts bundle-laya-worker && bun run ../../scripts/spur-dev.ts bundle-plugins",
         "test": "bun test tests --coverage --coverage-dir=../../.coverage --pass-with-no-tests",
         "typecheck": "tsc --noEmit",
         "prepack": "bun run build:bundle",
@@ -57,14 +58,14 @@
     },
     "devDependencies": {
         "@commander-js/extra-typings": "^14.0.0",
-        "@gobing-ai/ts-db": "^0.5.28",
-        "@gobing-ai/ts-ai-runner": "^0.5.28",
-        "@gobing-ai/ts-dual-workflow-engine": "^0.5.28",
-        "@gobing-ai/ts-infra": "^0.5.28",
-        "@gobing-ai/ts-llm-jsonl-importer": "^0.5.28",
-        "@gobing-ai/ts-rule-engine": "^0.5.28",
-        "@gobing-ai/ts-runtime": "^0.5.28",
-        "@gobing-ai/ts-utils": "^0.5.28",
+        "@gobing-ai/ts-db": "^0.5.32",
+        "@gobing-ai/ts-ai-runner": "^0.5.32",
+        "@gobing-ai/ts-dual-workflow-engine": "^0.5.32",
+        "@gobing-ai/ts-infra": "^0.5.32",
+        "@gobing-ai/ts-llm-jsonl-importer": "^0.5.32",
+        "@gobing-ai/ts-rule-engine": "^0.5.32",
+        "@gobing-ai/ts-runtime": "^0.5.32",
+        "@gobing-ai/ts-utils": "^0.5.32",
         "@types/bun": "1.4.3",
         "@types/figlet": "^1.7.0",
         "@types/node-notifier": "8.0.5",

package/plugins/sp/README.md

@@ -29,7 +29,7 @@ One feature, start to finish — see the Command index below for exact command n
 ```
 idea/plan  vague description → feature + AC + decomposed task batch
      ↓
-run        <wbs>  → pipeline: precheck → implement → test → review → approve(HITL) → verify → record → done
+run        <wbs>  → pipeline: precheck → implement → gate ⇄ remediate → review → done  (decision points route repair, stop and approval)
      ↓
 verify     <wbs>  → traceability + AC verdict (PASS clears the gate; this also runs inside the run step)
      ↓
@@ -95,8 +95,8 @@ list this README is checked against.
 
 | Command          | What it does                                                                                                                                                                    |
 | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `dev-idea`       | Turn a vague idea into a feature with AC and a decomposed task batch — discovery, idea-eval, feature-create, AC, feature-check, system-design, decompose, batch-create, handoff |
-| `dev-plan`       | Plan a feature from a written description — intake → feature create → AC generation → feature check gate → decomposition → batch-create                                         |
+| `dev-idea`       | Turn a vague idea into a feature with AC and a decomposed task batch — discovery, idea-eval, feature-create, AC, system-design, decompose, batch-create, handoff |
+| `dev-plan`       | Plan a feature from a written description — intake → feature create → AC generation → decomposition → batch-create                                                              |
 | `dev-brainstorm` | Interactive solution design — heuristic discovery interview followed by structured ideation with trade-offs and confidence scoring                                              |
 | `dev-find-way`   | Wayfinder — chart a multi-session investigation map, or resolve one map ticket; always in an isolated git worktree + branch (`--worktree`, `--wrap`)                             |
 | `dev-refine`     | Refine task requirements via structured Q&A — clarify scope, elicit missing details, tighten acceptance criteria; `--depth ready` audits and corrects existing claims, freezes the spec, promotes to todo |
@@ -348,7 +348,7 @@ surface or run one workflow. All skills target the same five core platforms: `cl
 | `conflict-finding`          | 1.0   | Authority-aware semantic audit — four-pillar (source/task/feature/authority) conflict discovery, claim-specific authority resolution, reproducible evidence, confirmed owner-routed remediation; backs `/sp:dev-find-conflict`             |
 | `fleet-join`                | 1.0   | Guest fleet occupancy — join as a live guest occupant, loop `spur agent wait --inbox` to pull work, reply through `spur message reply`, then leave; G73 (task 1081)                                                                          |
 | `next-feature`              | 1.0   | Prompt-first feature frontier prioritizer — sync-first precondition, B3 actionability gate (cited, never restated), tiered rubric over measured signals, D1–D4 defect proposals conforming to the restructure map schema; backs `/sp:dev-find-next` |
-| `pr-reviewing`              | 1.0   | GitHub Codex PR review — PR prepare/reuse, `@codex review` request with per-HEAD dedupe, bounded polling, findings normalization, validated fix + re-review; spine SSOT `pr-review.yaml` + `spur builder pr`; backs `/sp:dev-pr-review`     |
+| `pr-reviewing`              | 1.0   | GitHub Codex PR review — PR prepare/reuse, `@codex review` request with per-HEAD dedupe, bounded polling, findings normalization, validated fix + re-review; direct `spur builder pr-status`/`pr-check`/`pr-open`/`pr-review` sequence; backs `/sp:dev-pr-review`     |
 | `indexed-context`           | 1.0   | Cross-agent project context — anatomy/learnings/pitfalls/buglog/memory in `.spur/context/`; hook-tracked token-ledger; graceful degradation on agents without hooks                                                                        |
 | `history-anatomy`           | 1.0   | Diagnostic interpretation owner over already-imported history — daily/ad-hoc mode contract, closed finding taxonomy, twelve-section report contract, `enrich`/`validate` rubrics; no workflow launch, no JSONL fallback, no corpus mutation                                                                   |
 | `session-review`            | 1.1   | Inline review of the active coding-agent session — compact outcomes, evidence-backed resolved/open issue classification, proposal-only improvements, and next actions; no workflow, import, delegation, or mutation                                                                                           |
@@ -695,7 +695,11 @@ pipeline owns one lifecycle phase:
 | `task-pipeline.yaml`        | Single-task execution             | `/sp:dev-run`                     |
 | `idea-pipeline.yaml`        | Idea/planning → feature + tasks   | `/sp:dev-idea`, `/sp:dev-plan`    |
 | `wrapup-pipeline.yaml`      | Post-execution wrap-up            | `/sp:dev-wrap`, `/sp:dev-wrapall` |
-| `wayfinder-resolution.yaml` | Wayfinder ticket resolution loop  | `spur workflow run` (free-form)   |
+
+> 1251 (D66): the PR-review and wayfinder-investigate spines were retired — the PR sequencing
+> lives in the `spur builder pr-status | pr-check | pr-open | pr-review` verbs, and the wayfinder
+> investigate hop is a skill procedure in `sp:wayfinder`. 1246 retired the feature-verification
+> wrapper the same way: `feature-lifecycle`'s `verifying` entry calls `spur feature verify`.
 
 > 0946 (D64): the `decision-routing-example.yaml` authoring sample was retired from the catalogue
 > (zero runs, example-only — `docs/design/workflow-catalogue-refactor.md` §10); the pattern lives on

package/plugins/sp/agents/expert-spur.md

@@ -42,6 +42,9 @@ Use for:
   ladder, trace-driven rule tuning, and applying accepted doctor proposals.
 - Evaluation and reflection campaigns via `sp:spur-doctor`: read-only evidence, history-finding
   reflection, and a proposal table.
+- Decision campaigns: catalog health and reliability audits (`spur decision status --json`,
+  `--reliability`, `--probe`) through `sp:spur-doctor`'s decision flags, and new or tuned decision
+  points through the decision lifecycle and `sp:spur-composer` (shared ids need operator consent).
 
 One bounded campaign per dispatch. Do not use for one CLI invocation. Do not use for
 planning→implementation→verification lifecycle or batch task execution; `sp:spur-dev` owns that

package/plugins/sp/agents/super-planner.md

@@ -89,6 +89,9 @@ You own the spaces **between** task runs:
   timeout prints one checkpoint and exits 1; the run continues, never cancelled or relaunched) plus
   `.spur/run/<wbs>-verdict.json`, accepted only when the trace's `.run.runId` equals the dispatched
   run and the verdict's mtime ≥ the trace's `.run.startedAt` — otherwise `stale-evidence` (Step 3.3).
+  A `failed` run's cause is its decision row (`failure-class` / `review-failure-class` = `stop`, or
+  approval `DENIED`); report it per [reporting a run](../skills/spur-dev/references/decision-points.md#reporting-a-run)
+  and do not re-judge it before recovery.
 - **One-shot recovery (optional)** - on non-PASS / stuck status, consult next-router **once** for that
   WBS (`recoveryHint` / dry-run plan): print the child command, or dispatch once only when the batch
   was started with `--auto` and cardinality is 1. Never self-loop until done.
@@ -135,7 +138,8 @@ Your decision-autonomy is **at the batch level**, bounded by the global Decision
 | Continue/halt between task runs | Whether to auto-approve a HITL gate inside a task (only `--auto` does, via `vars.profile`) |
 
 Surface blockers/HITL **only at the batch boundary** (between task runs). A pipeline run that pauses
-on its internal HITL `approve` gate (under the default profile) is surfaced to the operator as a
+on its `review`-state approval decision point (interactive profiles only; under `profile=auto` the
+decision point answers itself, and a deferred answer is no objection) is surfaced to the operator as a
 batch-level event: "task 0042 is awaiting approval - `spur workflow continue <run-id> --yes` to
 approve, or provide feedback". You do not answer the gate from inside a step.
 

package/plugins/sp/agents/super-reviewer.md

@@ -70,8 +70,10 @@ Only when invoked under the pipeline do blocker/major findings block a gate.
 
 Invoked by `task-pipeline.yaml`'s `review` step. The pipeline hands you the task WBS and the
 `--focus` dimensions. You run the review, write findings to the task's `## Review` section, and
-return a PASS/PARTIAL/FAIL verdict to the pipeline's `approve(HITL)` gate. `blocker`/`major`
-findings block the gate; `minor`/`advisory` are recorded but do not block.
+return a PASS/PARTIAL/FAIL verdict. `spur task verdict` certifies the answer; a PASS then reaches the
+approval decision point before `done`, and a non-PASS feeds the `review-failure-class` decision
+(`fix` → `remediate`, `stop` → `failed`). `blocker`/`major` findings block certification;
+`minor`/`advisory` are recorded but do not block.
 
 ### Multi-target coordination (task 1023)
 
@@ -181,11 +183,11 @@ with the commit) drops the row from the sweep; `DEFER(<reason>)` reclassifies a
 the cell, not the sentence. `OPEN` states "still live", and `ACCEPTED` marks a non-blocking P4
 observation you are deliberately not acting on; both behave as an ordinary open row.
 
-**Pipeline cost of an open finding (1122).** The review PASS edges run this same classification
-before verify (`spur task residual <wbs> review-gate`): a PASS whose table still carries an open P1-P3 row
-routes into `review-fail-triage` → the bounded repair hop instead of verify. Open P1-P3 findings
-block `done`; fixing one invalidates the certified digest and re-runs quality → review → verify on
-a fresh digest. Only P4 rows and `DEFER`-ed P3 rows are wrap residuals — disposition the finding in
+**Pipeline cost of an open finding (1122).** The review certification runs this same classification
+(`spur task residual <wbs> review-gate`): a PASS whose table still carries an open P1-P3 row is a
+non-PASS review, so the `review-failure-class` decision routes it to `remediate` instead of `done`.
+Open P1-P3 findings block `done`; fixing one invalidates the certified digest and re-runs
+gate → review on a fresh digest. Only P4 rows and `DEFER`-ed P3 rows are wrap residuals — disposition the finding in
 its cell now, while you hold the context, instead of leaving the cost to be rediscovered after a
 full cycle.
 
@@ -220,9 +222,9 @@ shallower.
 ```
 
 The **Verdict line is machine-read** by the task pipeline (session finding after 1088): `review →
-verify|approve` requires a line matching `Verdict: PASS` (plain or bold), and ANYTHING ELSE —
-FAIL, PARTIAL, a missing line, a line split across two lines — routes the run into
-`review-fail-triage` and its bounded repair hop. Keep it on one line, in that shape, in every
+done` requires a line matching `Verdict: PASS` (plain or bold), and ANYTHING ELSE —
+FAIL, PARTIAL, a missing line, a line split across two lines — routes the run through the
+`review-failure-class` decision into the bounded `remediate` hop. Keep it on one line, in that shape, in every
 review answer; never restate it as prose only.
 
 **State `Confidence: HIGH | MEDIUM | LOW` — the gate derives it from your dispositions (ADR-141).**
@@ -243,6 +245,35 @@ No verdict-artifact field, no receipt level, no per-finding grade, and no operat
 (ADR-138 stands for every other carrier). Evidence gaps still belong in the report body: name them,
 then let the dispositions decide the level.
 
+**Two artifacts, one `Confidence:` line each (1254).** The body you write into `### Review` states
+the disposition-derived level above. When the pipeline also captures your final answer as the
+certification input for `spur task verdict`, that text is a *second* artifact with a *different*
+consumer, and it carries the **evidence-derived** level (`deriveVerifyConfidence`): PASS with every
+AC row MET on executable evidence (`test`/`command`) is HIGH; a citation-only (`static-ref`),
+`manual-review`, `llm-judge` or `N/A` AC is MEDIUM; a non-PASS verdict or any PARTIAL/UNMET row is
+LOW. It ends with exactly one plain `Verdict: PASS|PARTIAL|FAIL` line preceded by both tables, in
+this exact shape:
+
+| Req | Status | Evidence |
+| --- | --- | --- |
+| R1 | MET | `src/api/users.ts:42` |
+
+| AC | Status | Evidence Type | Evidence |
+| --- | --- | --- | --- |
+| AC1 — the guard rejects an unsafe input | MET | test | `packages/app/tests/guard.test.ts:12` |
+
+One row per declared requirement (`MET | PARTIAL | UNMET`, none omitted or merged) and one row per
+acceptance criterion (`MET | PARTIAL | UNMET | N/A`), with the evidence-type token alone in its own
+cell — `test | command | static-ref | manual-review | llm-judge | n/a`, or a `+` compound when more
+than one kind applies. Evidence cells cite a repo-relative `path:line` or a named test/command. AC
+identities stay the task's own (checklist label, title, bold head, `Scenario:` prefix, bracket tag or
+declared `AC-N` alias): a linked feature's scenario title covers the task that implements it, and a
+task-local criterion is legal as-is — it needs no feature credit.
+Never repeat the section's disposition-derived `Confidence:` line here: a second `Confidence:` line is
+a `confidence-duplicate` rejection of the whole answer, and so is a level the rows do not derive. A
+PASS with executable AC and one accepted P4 therefore certifies as `Confidence: HIGH` in the answer
+while the section keeps `Confidence: MEDIUM`.
+
 **Source citations for external claims (one claim contract, 2026-10-12).** A Finding cell or a
 Functional Traceability `Evidence` cell that asserts an external API/library claim carries a
 verifiable citation in the SAME cell — a repo `path:line(-end)`, the external named-origin form
@@ -258,8 +289,8 @@ as an explicit gap in the report body (above), so a reader can re-check it.
 
 **Machine-checked at the gate (findings table).** `spur task residual <wbs> review-gate` applies the same two
 predicates to every finding row: a Finding cell carrying one of the verify lint's claim markers with
-no citation form becomes a **blocking** `review-contract` item, so `review → verify` stops and the
-run enters `review-fail-triage`. The `Location` column is deliberately not consulted as a citation —
+no citation form becomes a **blocking** `review-contract` item, so `review → done` stops and the
+run enters the `review-failure-class` decision. The `Location` column is deliberately not consulted as a citation —
 that is the rule stated above, and a gate that accepted it would pass every row that has an anchor.
 Functional Traceability `Evidence` cells stay reviewer-enforced (SECUA review): they are free prose
 in a table the gate does not parse.

package/plugins/sp/commands/dev-fixall.md

@@ -27,12 +27,17 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 
 ## Implementation
 
-Follow the inline procedure in [dev-operations.md](../skills/spur-dev/references/dev-operations.md#10-fixall) (fixall). Pipeline signal: when `--gate-log` is set (the `test-fix` hop), run no full gate — the `test-recheck` state immediately after is the deciding run (R4, task 0483).
+Follow the inline procedure in [dev-operations.md](../skills/spur-dev/references/dev-operations.md#10-fixall) (fixall). Pipeline signal: when `--gate-log` is set (the `remediate` hop), run no full gate — the `gate` state's recheck immediately after is the deciding run (R4, task 0483).
 
-When dispatched from the pipeline's test-fix stage (F96, task 0950), the gate log carries a
+When dispatched from the pipeline's `remediate` hop (F96, task 0950), the gate log carries a
 `residual artifact` block (`<wbs>-residuals.json`) and the findings file already
 contains the merged residual anchors: treat those items as fix targets, in order,
 alongside gate anchors. The fixer may write `.spur/run/<wbs>-residual-deferrals.json`
 — one `{id, reason}` entry per item — but only for P3 findings or diff markers it
 cannot fix inside the task; the done stage settles deferrals into follow-up tasks.
 
+The `remediate` hop is entered only after a `fix` decision (`failure-class` on a red gate,
+`review-failure-class` on a non-PASS review). A `stop` decision ends the run before this command
+runs, so do not invoke it by hand to overrule a `stop`
+([decision points](../skills/spur-dev/references/decision-points.md)).
+

package/plugins/sp/commands/dev-idea.md

@@ -1,5 +1,5 @@
 ---
-description: Turn a vague idea into a feature with AC and a decomposed task batch — discovery, idea-eval, feature-create, AC, feature-check, system-design, decompose, batch-create (Design by default), handoff
+description: Turn a vague idea into a feature with AC and a decomposed task batch — discovery, idea-eval, feature-create, AC, system-design, decompose, batch-create (Design by default), handoff
 role: planner
 argument-hint: "\"<idea>\" | --from-file <path> [--skip-design] [--agent <inline|auto|name>] [--auto]"
 allowed-tools: ["Bash", "Read", "Skill", "AskUserQuestion"]
@@ -44,10 +44,18 @@ trace records the answering source. `--auto` takes the recommended option at eac
 
 | Gate | Pauses when | Recommendation comes from | `--auto` takes |
 | --- | --- | --- | --- |
-| idea-eval | after discovery | eval report `## Recommendation` (`proceed` / `reshape` / `drop`) | `proceed`/`reshape` → continue; `drop` → cancel; missing → still asks |
-| feature-check | after AC | recorded AC check + requirement coverage | PASS → continue; FAIL → revise AC (cap 3) |
+| idea-eval | after discovery | eval report `## Recommendation` (`proceed` / `reshape` / `drop`); when unparseable, a model answer from the `idea-recommendation` decision | `proceed`/`reshape` → continue; `drop` → cancel; neither → the gate asks, and under `--auto` its `gate-evidence` decision answers (a deferred answer denies) |
 | design-approval | after system-design (skipped by `--skip-design`) | recorded design check | PASS → approve; FAIL → still asks |
-| batch-create | after decompose | batch schema + task-order sidecar validation | create the batch |
+
+The AC check and the batch create are deterministic pipeline steps, not gates: `ac-generate`
+runs `spur feature check` and routes on the recorded result (a FAIL retries the AC loop, cap 3),
+and `batch-create-run` runs `spur task batch-create` and routes on its own recorded result.
+Neither ever pauses, under any profile.
+
+The rescue decisions and the gate answers are catalog decision points; their rows and switches
+are in [decision points](../skills/spur-dev/references/decision-points.md). With both switches off
+(the default) no model is called and a `--auto` run with no parseable recommendation stops at
+idea-eval as a denial rather than creating a feature.
 
 Flag → vars: `--auto` sets `profile=auto`, `idea_approved=true`, `design_approved=true`;
 `--skip-design` sets `design=skip`.
@@ -78,5 +86,6 @@ Flag → vars: `--auto` sets `profile=auto`, `idea_approved=true`, `design_appro
 - The `start` state persists the operator's idea argument (or the `--from-file` contents)
   **unmodified** to `.spur/run/<run-id>-idea-input.md` (0887 R1); every model-bearing stage prompt
   treats that file as the authoritative ask, and the precheck fails the run when it is empty or missing.
-- Stage contract (discovery → idea-eval → feature-create → AC → feature-check → system-design →
-  decompose → batch-create → ready-prepare → handoff): `plugins/sp/skills/spur-dev/references/dev-operations.md` § idea.
+- Stage contract (discovery → idea-eval → feature-create → ac-generate → system-design
+  (conditional) → design-approval → decompose → batch-create-run → ready-prepare →
+  handoff-finalize → handoff): `plugins/sp/skills/spur-dev/references/dev-operations.md` § idea.

package/plugins/sp/commands/dev-plan.md

@@ -1,5 +1,5 @@
 ---
-description: Plan a feature from a description — intake → feature create → AC generation → feature check gate → decomposition → batch-create (Design by default)
+description: Plan a feature from a description — intake → feature create → AC generation → decomposition → batch-create (Design by default)
 role: planner
 argument-hint: "\"<description>\" [--feature <id>] [--parent <feature-id>] [--skip-design] [--agent <inline|auto|name>] [--auto]"
 allowed-tools: ["Bash", "Read", "Skill", "AskUserQuestion"]

package/plugins/sp/commands/dev-pr-review.md

@@ -17,9 +17,9 @@ and commits the verified ones. The invoking agent orchestrates.
 | Flag | Description | Default |
 | --- | --- | --- |
 | `<mode>` | `status\|review\|fix` — status: read-only branch + PR state; review: local branch-diff review (or the GitHub Codex spine with `--codex`); fix: validate, fix and commit findings from either reviewer. | status |
-| `--codex` | `review` only — route through the GitHub Codex spine (`pr-review.yaml`) instead of the local `/sp:dev-review`. | off |
-| `--force` | `review --codex` only — request a fresh review of the current HEAD even when it was already reviewed (`mode=rerun`). | off |
-| `--no-wait` | `review --codex` only — post the request and return `pending` without polling (`mode=submit`). | off |
+| `--codex` | `review` only — route through the GitHub Codex spine (`spur builder pr-check` → `pr-open` → `pr-review`) instead of the local `/sp:dev-review`. | off |
+| `--force` | `review --codex` only — request a fresh review of the current HEAD even when it was already reviewed (`pr-review --force`). | off |
+| `--no-wait` | `review --codex` only — post the request and return `pending` without polling (`pr-review --no-wait`). | off |
 | `--base <branch>` | Base branch for the branch report, the `pr-check` diff and a newly created PR. | existing PR base, else repo default |
 | `--agent <inline\|auto\|name>` | Who performs the model-bearing triage/fix. Omit uses the current agent, `inline` forbids dispatch, `auto` resolves the declared role, and a name pins that executor. This does not change the deterministic route. | omit |
 | `<focus>` | Remaining free text — extra review focus for the local review or the Codex request (e.g. `security boundaries and transaction idempotency`). | none |
@@ -36,9 +36,9 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 
 - Apply the [inline-default execution-surface contract](../skills/spur-dev/references/cross-cutting.md#inline-default-execution-surface).
 - Delegate everything: `Skill(skill="sp:pr-reviewing", args="$ARGUMENTS")`. The skill owns mode
-  routing, the local `/sp:dev-review` dispatch, the Codex spine and finding triage/fix. On the
-  Codex path `pr-review.yaml` is the SSOT for state order and guards, and the four flat
-  `spur builder pr-<verb>` verbs are the deterministic git/gh core every spine step shells out to.
+  routing, the local `/sp:dev-review` dispatch, the Codex spine and finding triage/fix. The Codex
+  path is a direct sequence of the four flat `spur builder pr-<verb>` verbs — `pr-check` →
+  `pr-open` → `pr-review` → `pr-status` — each verb's verdict gating the next.
 - Retired modes print one notice line and run their replacement: `full` → `review --codex`;
   `submit` → `review --codex --no-wait`; `rerun` → `review --codex --force`; `collect` → `status`.
   `rules` prints that `AGENTS.md` review-rule authoring belongs to `cc:cc-magents` (the `cc` plugin)

package/plugins/sp/commands/dev-run.md

@@ -50,6 +50,9 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 - Implement step only (`--mode implement`): `Skill(skill="sp:code-implementation", args="$ARGUMENTS")`
 - After a full-mode run settles (done, failed or paused), print the
   [execution summary](../skills/spur-dev/references/dev-operations.md#execution-summary) unless `--no-summary`.
+- Then report the run's decision points (triage lane, failure classes, approval) from their rows
+  ([reporting a run](../skills/spur-dev/references/decision-points.md#reporting-a-run)). A `failed` or `remediate` route is explained by the row
+  that chose it; quote its value, source and reason, never a fresh judgment.
 
 **Flags:**
 

package/plugins/sp/commands/dev-runall.md

@@ -26,7 +26,7 @@ Wraps the **sp:spur-dev** skill.
 | `--worktree` `[<name>]` | Run the batch in an isolated git worktree; FF-merge on success, retain on failure. Bare `--worktree` creates a fresh tree; `--worktree <name>` adopts an existing worktree by name/path/branch. | off |
 | `--no-summary` | Skip the measured execution summary (one row per task run: time, wait, tool calls, total / non-cached tokens) printed after the batch report. | off (summary printed) |
 | `--concurrency` `<n>` | Parallel-mode worker bound: at most `<n>` task pipelines run at once (task 0931); a dependent starts only after its in-set dependencies are integrated onto the base ref. No-op in sequential mode (ignored). | 2 |
-| `--defer-gate` | Opt-in parallel-batch gate policy (task 1111): each task's `test` hop runs the light tier and writes `DEFERRED`; the batch runs one integrated full gate on the base ref before the feature sync. Requires `--mode parallel`, or `--mode auto` resolved to parallel (dropped with a note otherwise); default off. | off |
+| `--defer-gate` | Opt-in parallel-batch gate policy (task 1111): each task's `gate` state runs the light tier and writes `DEFERRED`; the batch runs one integrated full gate on the base ref before the feature sync. Requires `--mode parallel`, or `--mode auto` resolved to parallel (dropped with a note otherwise); default off. | off |
 
 For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag-glossary.md).
 
@@ -82,8 +82,8 @@ FF-merge on success. This is expected, not a bug.
 
 **`--next` (batch-once wrap).** `--next`
 is chain-to-completion with propagation. On `dev-runall`, each task in the batch runs its
-`task-pipeline.yaml` to terminal status (the pipeline already drives precheck → implement → test →
-review → approve → verify → record → done); when the batch is complete, the wrap hop runs **once
+`task-pipeline.yaml` to terminal status (the pipeline already drives precheck → implement → gate ⇄ remediate →
+review → done); when the batch is complete, the wrap hop runs **once
 for the batch** — mirroring the batch-once shippable gate `dev-verifyall` uses — rather than once
 per task. Without `--next`, `--wrap` is wrap-without-chaining (the single batch wraps without
 advancing the feature lifecycle). **was: `--next` deliberately omitted; the old no-`--next` rationale argued against the old per-task-transition meaning and does not carry.**
@@ -111,3 +111,6 @@ full distinction.
 - Explicit executor (any mode, including `auto`) or parallel mode: `Skill(skill="sp:spur-dev", args="runall $ARGUMENTS")` → `sp:super-planner` agent.
 - After the batch report, print the [execution summary](../skills/spur-dev/references/dev-operations.md#execution-summary) over every attempted run unless
   `--no-summary`.
+- A failed task's report row names the decision row that ended it (`failure-class` or
+  `review-failure-class` = `stop`, or approval `DENIED`) per
+  [reporting a run](../skills/spur-dev/references/decision-points.md#reporting-a-run); the batch failure policy then applies unchanged.

package/plugins/sp/commands/dev-verify.md

@@ -45,7 +45,7 @@ See `sp:code-verification` § Shippable readiness gate.
   run `spur task residual <wbs> scan` + `fold` (observe-only; folds the verdict's `residual-sweep` check,
   PASS → PARTIAL when a blocking residual exists) — under every `--fix` mode — then, only on a
   downgrade, re-run `spur task record <wbs> --verdict-file .spur/run/<wbs>-verdict.json` so Testing
-  carries the final verdict. Same order as the pipeline `record` state (0983): scanning before
+  carries the final verdict. Same order as the pipeline `done` state's record close (0983): scanning before
   record reads unticked-but-proven boxes and folds a clean PASS to PARTIAL. When the task reaches
   `done` through `--next`, run `spur task residual <wbs> settle` (best-effort). On a folded PARTIAL: the bounded remediation loop has
   already run — a residual-failed task is routed to router C6 (HITL STOP), never another

package/plugins/sp/commands/dev-wrap.md

@@ -1,5 +1,5 @@
 ---
-description: Wrap up a single completed task — learnings, metrics, doc-sync, optional feature transition and branch cleanup
+description: Wrap up a single completed task — learnings, metrics, doc-sync, optional branch cleanup
 role: coder
 argument-hint: "<wbs> [--agent <inline|auto|name>] [--auto] [--merge] [--dry-run]"
 allowed-tools: ["Bash", "Read", "AskUserQuestion"]

package/plugins/sp/commands/dev-wrapall.md

@@ -1,5 +1,5 @@
 ---
-description: Wrap up a batch of completed tasks — learnings, metrics, doc-sync, feature transition, optional branch cleanup
+description: Wrap up a batch of completed tasks — learnings, metrics, doc-sync, optional branch cleanup
 role: coder
 argument-hint: "[--since <iso-date>] [--feature <id>] [--status <s>] [--agent <inline|auto|name>] [--auto] [--merge] [--dry-run]"
 allowed-tools: ["Bash", "Read", "AskUserQuestion"]
@@ -14,7 +14,7 @@ Wraps the **wrapup-pipeline.yaml** workflow.
 | Flag | Description | Default |
 | --- | --- | --- |
 | `--since` `<iso-date>` | Wrap tasks completed since a date. | configured |
-| `--feature` `<id>` | Wrap tasks in a feature. | omitted |
+| `--feature` `<id>` | Select tasks in a feature (selection only — it no longer advances the feature; follow up with `spur feature sync <id>`). | omitted |
 | `--status` `<s>` | Only wrap tasks in a status. | done |
 | `--agent` `<inline\|auto\|name>` | Who runs the wrap's model-bearing steps. Wrap is workflow-backed (headless): `omit` and `--agent inline` resolve identically per task 0687 — tier substitution under objective trigger 3 (durable auditable run record required) with a warning naming the substituted executor; `auto` tier-resolves an executor; a name pins that executor into `vars.agent`. | inline |
 | `--auto` | Skip objective HITL gates. | off |
@@ -42,8 +42,8 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 ```bash
 AGENT=… # omit≡inline → tier-substituted executor + warning; auto tier-resolved; <name> unchanged
 echo "execution surface: subprocess; reason: trigger 3 — durable auditable run record required; requested agent: <inline|auto|name>; executor: $AGENT"
-VARS=$(jq -nc --arg tasks "$TASKS" --arg feature "$FEATURE" --arg agent "$AGENT" --arg profile "$PROFILE" --arg merge "$MERGE" \
-  '{tasks:$tasks, feature:$feature, agent:$agent, profile:$profile, merge:$merge}')
+VARS=$(jq -nc --arg tasks "$TASKS" --arg agent "$AGENT" --arg profile "$PROFILE" --arg merge "$MERGE" \
+  '{tasks:$tasks, agent:$agent, profile:$profile, merge:$merge}')
 spur workflow run wrapup-pipeline.yaml --vars "$VARS" [--dry-run]
 ```
 

package/plugins/sp/plugin.json

@@ -1,5 +1,5 @@
 {
     "name": "sp",
-    "version": "0.4.14",
+    "version": "0.4.16",
     "description": "Spur — a local-first harness engineering toolkit that wraps mainstream coding agents with constraint checking, workflow orchestration, and history analytics."
 }

package/plugins/sp/skills/code-implementation/SKILL.md

@@ -103,7 +103,7 @@ surfaces is what keeps that gate quiet.
 
 ## Implement scope: do not run the project quality gate
 
-During implement, the pipeline's `test` hop runs `${vars.qualityGateCmd}` (the full project gate:
+During implement, the pipeline's `gate` state runs `${vars.qualityGateCmd}` (the full project gate:
 `spur self exec check`) immediately after this step and is the gate that actually
 decides pass/fail. Running it inside implement is pure redundancy — it cannot change the outcome and
 only burns wall clock and context budget.
@@ -118,9 +118,9 @@ only burns wall clock and context budget.
   re-select the execution tree inside the call (`cd -- "$TREE"` plus the identity check) instead of
   relying on a `cd` a previous call left behind.
 - **NEVER run** `spur self exec test`, `spur self exec check`, `bun run check`, or any other full-suite /
-  project-gate command from inside implement. These belong to the pipeline's `test` hop.
+  project-gate command from inside implement. These belong to the pipeline's `gate` state.
 - **Full-suite budget: at most 2 per task** (task 0436 R2) — counted across the whole task run
-  (implement probes + the pipeline `test` hop + verify/recheck), not per step. When a check fails,
+  (implement probes + the pipeline `gate` state and its rechecks), not per step. When a check fails,
   run the narrow target (`bun test <file> --test-name-pattern <test>`) to green before any full
   suite; reach for the second full run only when the narrow target cannot reproduce the failure.
 - **Consolidate dogfood runs**: one combined real-data execution that exercises all scenarios,
@@ -128,7 +128,7 @@ only burns wall clock and context budget.
   rerunning the same dogfood command with one flag changed, stop and fold the variants into a
   single run — repeated identical commands are loop-detector findings and pure cost.
 - If a targeted probe reveals a failure you cannot fix within implement scope, note it in
-  `## Solution` and let the `test` hop's fixall handle it — do not pre-empt the gate.
+  `## Solution` and let the `gate` state's `remediate` hop handle it — do not pre-empt the gate.
 
 ### Public-surface probe (task 1135 R1/R6/R8)
 
@@ -155,7 +155,7 @@ changed no public surface, report the single line
 - the paired-script parity test when `package.json` changed (a half-updated `spur-check` /
   `spur-check:full` chain).
 
-The single full project check stays the pipeline `test` hop's job (see the section above); these are
+The single full project check stays the pipeline `gate` state's job (see the section above); these are
 changed-path checks, not that gate.
 
 ## Changed-path targeted checks (dependency-aware verification, task 0510 R3 / task 1142 R3)
@@ -164,14 +164,14 @@ changed-path checks, not that gate.
 surface can break a downstream consumer. The matrix below is dependency-aware — domain → app →
 CLI — so a shared change verifies its consumers without recreating the full project check inside
 implement. **It augments narrow behavior tests; it never authorizes `spur self exec check`,
-`spur self exec test`, or another full project check inside implement** — the pipeline's `test` hop owns
+`spur self exec test`, or another full project check inside implement** — the pipeline's `gate` state owns
 that single full gate.
 
 **Worker iteration check order (task 1142 R3):**
 1. The **changed-path matrix** below (narrow behavior tests + affected consumers);
 2. `spur task gate <wbs> light` (biome on changed files, per-workspace typecheck, rule presets `rules:pre`/`rules:post`, related tests).
 
-Neither step takes the full project gate. The full gate is named only for the pipeline's `test` and `test-recheck` hops.
+Neither step takes the full project gate. The full gate is named only for the pipeline's `gate` state (first visit and rechecks).
 
 | Changed surface | Required targeted tests | Required typechecks |
 | --- | --- | --- |
@@ -189,7 +189,7 @@ Neither step takes the full project gate. The full gate is named only for the pi
   (a flag the plugin layer consumes) actually changes, so an unconditional parity suite does not
   creep into every plugin edit.
 - Run the applicable rows, then stop: the single full project check belongs to the pipeline's
-  `test` hop (`task-pipeline.yaml` `${vars.qualityGateCmd}`).
+  `gate` state (`task-pipeline.yaml` `${vars.qualityGateCmd}`).
 - **Mirrored surfaces: an edit lands on all of them.** When the change is one instance of a repeated
   pattern — the same wiring rule on two runbooks, a signature in both a generator and its generated
   `.d.mts`, a command chain in both `spur-check` and `spur-check:full` — grep for the siblings and

package/plugins/sp/skills/code-improvement/SKILL.md

@@ -89,8 +89,8 @@ and the deepening direction. Full definitions and examples in
 | **minor** | advisory | Local friction: a module slightly too shallow, coupling that's awkward but not coordinated. |
 | **advisory** | advisory | Deepening opportunity: the code works and is testable, but would be cleaner with a deeper module. Always non-blocking. |
 
-**Under the pipeline** (`/sp:dev-review` in a task run), `blocker` and `major` block the
-`approve(HITL)` gate. `minor` and `advisory` are recorded but do not block. **Standalone** reviews
+**Under the pipeline** (`/sp:dev-review` in a task run), `blocker` and `major` block review
+certification (a non-PASS review goes to the `review-failure-class` decision). `minor` and `advisory` are recorded but do not block. **Standalone** reviews
 are advisory-only — the operator decides what to act on.
 
 ---
@@ -185,7 +185,7 @@ Each candidate is a structured finding:
 When invoked as the `--focus architecture` dimension of `/sp:dev-review`:
 
 - The scope is the task's diff (pipeline) or the `path` arg (standalone).
-- `blocker`/`major` candidates block the `approve(HITL)` gate alongside any SECUA blockers from
+- `blocker`/`major` candidates block review certification alongside any SECUA blockers from
   `sp:code-verification`.
 - The candidate list is returned as a **review fragment**; the review coordinator
   (`sp:super-reviewer` — the invoking session under `/sp:dev-review`) merges it into the combined

package/plugins/sp/skills/code-review/references/verification-before-completion.md

@@ -42,10 +42,11 @@ Before reporting a task as complete, a test as passing, a bug as fixed, or a fea
 
 ## Under the pipeline
 
-`task-pipeline.yaml`'s `verify` step (Phase 8) and `record` step enforce this gate. The `verify`
-step runs `sp:code-verification` verify mode, which produces a `VerifyVerdict` artifact; the
-`record` step transcribes it to the task's `## Testing` section. A `done` transition requires a
-PASS verdict.
+`task-pipeline.yaml` enforces this gate deterministically. The `gate` state runs `spur task gate`
+and a red result goes through the `failure-class` decision to `remediate`; the `review` state
+certifies the review answer with `spur task verdict`, which writes the `VerifyVerdict` artifact.
+`review → done` requires that PASS plus the approval decision point, and `done`'s `spur task record`
+close transcribes the verdict to the task's `## Testing` section.
 
 Under manual execution (no pipeline), the agent must still run the gates and paste the evidence.
 "Manual" is not an exemption — it just means the agent, not the pipeline, runs the commands.

package/plugins/sp/skills/code-verification/SKILL.md

@@ -29,7 +29,7 @@ The **verifier** in the Spur execution loop. A coding agent reports "done" with
 this skill is the deterministic counterweight that proves — or disproves — the claim against the
 task's own requirements and Acceptance Criteria, then emits the canonical verdict artifact
 through CLI verbs (section writes are owned by the review coordinator and the deterministic
-`record` step — F92 0593 R1).
+`spur task record` close in `done` — F92 0593 R1).
 
 It backs two commands:
 
@@ -321,7 +321,7 @@ spur task residual <wbs> fold
 > **Do not write `## Review` directly, ever.** The `## Review` section is owned by the
 > `review` coordinator (`/sp:dev-review` → `sp:super-reviewer`), which merges
 > `functional-review` + `code-verification` review mode + `code-improvement` fragments. The
-> `record` step backfills `## Review` from the verdict artifact **only** if the section is bare
+> `spur task record` close backfills `## Review` from the verdict artifact **only** if the section is bare
 > (`sectionIsBare` guard, `task-section-bodies.ts`) — a standalone compatibility fallback, never an
 > overwrite of authored Review. Writing `## Review` here destroys the review step's
 > three-dimensional findings.
@@ -546,7 +546,7 @@ Flags: `--agent <inline|auto|name>` (execution surface — inline default, with
 
 ## When to use
 
-- **Verify a task before `done`** — the pipeline's `verify` step, or a manual `/sp:dev-verify`.
+- **Verify a task before `done`** — the pipeline's `review` state certifies it (`spur task verdict`), or a manual `/sp:dev-verify`.
 - **Audit completed work** — `--force` re-verifies a `done` task (compliance, post-merge).
 - **Focused code review** — `/sp:dev-review` for SECUA findings on a diff.
 
@@ -581,7 +581,7 @@ Do **not** use this skill for:
   rubric.
 - `plugins/sp/references/roles.md` — the Layer-1 role→tier table; this skill's verify/review modes
   run under the `reviewer` role (0538 R4: this file points at roles.md, it does not restate tiers).
-- `task-pipeline.yaml` — the `verify → record` gate that consumes the verdict.
+- `task-pipeline.yaml` — the `review → done` gate that consumes the verdict.
 - **`sp:spur-dev`** — the execution-half umbrella that drives the pipeline this skill gates.
 - [references/code-improvement.md](references/code-improvement.md) — architecture-improvement lens
   for module depth, seam placement, locality, coupling, and testability.