@gobing-ai/spur 0.4.15 → 0.4.17

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-find-conflict.md

@@ -1,7 +1,7 @@
 ---
 description: "Authority-aware semantic audit across source, task files, feature files, and project authority files — discover conflicts, resolve claim-specific authority, collect reproducible evidence, and route confirmed repairs through owner surfaces. Triggers: find conflict, conflict audit, semantic conflict, authority mismatch, stale projection."
 role: reviewer
-argument-hint: "[<scope>] [--pillar <source|tasks|features|authority|all>] [--mode <adaptive|full>] [--resolve] [--agent <inline|auto|name>] [--json]"
+argument-hint: "[--tasks <selector> | --feature <id>[,<id>] | --scope <path>[,<path>]] [--pillar <source|tasks|features|authority|all>] [--mode <adaptive|full>] [--resolve] [--auto] [--agent <inline|auto|name>] [--json]"
 allowed-tools: ["Bash", "Read", "Write", "Grep", "Glob", "Skill"]
 ---
 
@@ -15,10 +15,14 @@ owner-routed remediation.
 
 | Flag                                                   | Description                                                                                                                              | Default         |
 | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
-| `<scope>`                                              | Optional path, WBS, feature ID, symbol, command, config key, or free-form subject to scope the audit.                                    | current project |
+| `--tasks <selector>`                                   | Audit a task set — batch selector grammar ([execution-batch.md § Step 1](../skills/spur-dev/references/execution-batch.md#step-1--selector-resolution-r1)): comma WBS list or `feature:<id>`. Resolved once and frozen; the tasks seed one audit (below).                        | —               |
+| `--feature <id>[,<id>]`                                | Sugar for the union of the `feature:<id>` sets plus the feature records themselves — resolved once, frozen, audited as one seed set.                                                                                                                                  | —               |
+| `--scope <path>[,<path>]`                              | Audit the tracked files under one or more paths: paths must exist (exit 2 otherwise), are normalized, duplicates dropped and nested paths collapse to the ancestor (`--scope apps,apps/cli` → `apps`).                                                                 | —               |
+| `[<wbs\|path>]`                                        | **Deprecated positional alias** (one release): a `^\d{4}$` token with a resolvable task → `--tasks <wbs>`; an existing path → `--scope <path>`; otherwise exit 2. Prints a deprecation warning naming the replacement.                                                 | —               |
 | `--pillar` `<source\|tasks\|features\|authority\|all>` | Limit the internal audit to one pillar; the minimum authorities needed to judge it still load.                                           | all             |
 | `--mode` `<adaptive\|full>`                            | Scan protocol — adaptive reuses fresh indexed context and discloses skipped areas; full forces a cold comprehensive scan.                | adaptive        |
 | `--resolve`                                            | Enable the proposal, confirmation, and owner-routed remediation workflow. Its absence guarantees no source/corpus/numbered-doc mutation. | off             |
+| `--auto`                                               | Under `--resolve`, pre-approve the eligible repair set instead of pausing at the confirmation gate (see the skill's Step 10). Authority decisions still pause. Requires `--resolve` (exit 2 otherwise).                                                            | off             |
 | `--agent` `<inline\|auto\|name>`                       | Who runs the model-bearing analysis.                                                                                                     | omit           |
 | `--json`                                               | Emit the same result envelope as Markdown as JSON.                                                                                       | off             |
 
@@ -28,13 +32,21 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 
 ```
 /sp:dev-find-conflict
-/sp:dev-find-conflict docs/00_ADR.md
+/sp:dev-find-conflict --scope docs/00_ADR.md
 /sp:dev-find-conflict --pillar authority
-/sp:dev-find-conflict --pillar tasks --mode full
-/sp:dev-find-conflict 0486 --resolve
-/sp:dev-find-conflict "command surface" --json
+/sp:dev-find-conflict --tasks 0486,0487 --pillar tasks --mode full
+/sp:dev-find-conflict --feature H11,H12 --resolve
+/sp:dev-find-conflict --scope apps/cli,docs/design --resolve --auto --json
 ```
 
+Target selection: **at most one** of `--tasks`, `--feature`, `--scope` per invocation — more than
+one (a positional beside an explicit selector counts as a second kind) → exit 2 naming the
+conflicting selectors. None → the whole project (the audit's natural default, unlike `dev-review`).
+The target set is resolved once and frozen through the shared batch resolver — no find-conflict
+parser; status pseudo-lists and `ready` are rejected (they select work to do, not artifacts to
+audit). The frozen objects seed **one** audit, not one audit per object, so conflicts *between*
+selected objects (two tasks, a task and a feature) stay visible.
+
 Audit mode is read-only with respect to source, corpus, and numbered documentation. Findings are
 presented before any repair. Approved repairs route through the artifact owner's existing harness
 surface (`spur task` / `spur feature`, `sp:doc-evolve`, the Spur development lifecycle, or

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

@@ -44,7 +44,7 @@ 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 |
+| 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 |
 
 The AC check and the batch create are deterministic pipeline steps, not gates: `ac-generate`
@@ -52,6 +52,11 @@ runs `spur feature check` and routes on the recorded result (a FAIL retries the
 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`.
 

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/plugin.json

@@ -1,5 +1,5 @@
 {
     "name": "sp",
-    "version": "0.4.15",
+    "version": "0.4.17",
     "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.

package/plugins/sp/skills/code-verification/references/verdict-schema.md

@@ -64,6 +64,14 @@ no level (ADR-131, 1196), no operator `ackLowConfidence`-style var exists, and h
 findings carry no per-finding grade. A verifier that can write a PASS can still write a wrong
 `HIGH` — which is exactly why the gate derives the level instead of trusting it.
 
+**A review run carries two answer artifacts, one `Confidence:` line each (1254).** The `## Review`
+section states the disposition-derived level (`deriveReviewConfidence`); the captured answer handed
+to `spur task verdict --from-answer` states the evidence-derived level (`deriveVerifyConfidence`)
+under the table above and carries exactly one `Confidence:` line. The two legitimately disagree — a
+PASS with executable AC and one carried P4 is section `MEDIUM`, answer `HIGH` — so the captured
+answer must not repeat the section's line (`confidence-duplicate` rejects the whole answer). The
+review stage's prompt owns that instruction; this schema owns the shape it must produce.
+
 ## Compatibility alias: `scenario` row key
 
 Task 0410 hardened the verdict reader. Producers SHOULD use the canonical `id` field for every
@@ -241,25 +249,33 @@ Wave C verification can emit the following additive `checks[]` rows:
 
 ## How the gate reads it
 
-`task-pipeline.yaml`, transition `verify → record`:
+In `task-pipeline.yaml` the `review` state writes this artifact: `spur task verdict <wbs>
+--from-answer` lints the review answer and derives `.spur/run/<wbs>-verdict.json`. A fold step then
+writes `.spur/run/<wbs>-review.status` = PASS only when the typed verdict is PASS, the artifact's own
+`verdict` is PASS (`jq -r '.verdict // empty'`) and `spur task residual <wbs> review-gate` is clean.
+The `review → done` guard reads that status **and** the approval decision point's token:
 
 ```yaml
 guard:
   kind: shell
   options:
-    command: 'test "$(jq -r .verdict .spur/run/${vars.wbs}-verdict.json)" = PASS'
+    command: >-
+      test "$(cat ".spur/run/$wbs-review.status" 2>/dev/null)" = PASS &&
+      test "$(cat ".spur/run/$wbs-approval.status" 2>/dev/null)" = APPROVED
 ```
 
-with a sibling `verify → failed` guarded on the negation. So a missing file, malformed JSON, or any
-non-`PASS` verdict routes the run to `failed` rather than `done` — the pipeline cannot certify
-completion without an explicit PASS artifact.
+A missing file, malformed JSON or any non-`PASS` verdict leaves the status FAIL, which the
+`review-failure-class` decision routes to `remediate` (`fix`) or `failed` (`stop`). The pipeline
+cannot certify completion without an explicit PASS artifact.
 
 ## Lifecycle
 
-- **Written:** Step 9 of verify mode, *after* the verdict is final (never partially).
-- **Read:** by the workflow gate on the `verify → record` transition.
-- **Location:** `.spur/run/` (the run-scratch dir the pipeline's `record` step also uses).
-- **Lifetime:** per execution attempt; overwritten on the next verify of the same WBS.
+- **Written:** by `spur task verdict` in the pipeline's `review` state, or by Step 9 of standalone
+  verify mode, *after* the verdict is final (never partially).
+- **Read:** by the review fold and the `review → done` guard, then by `done`'s `spur task record`
+  close, which transcribes it.
+- **Location:** `.spur/run/`.
+- **Lifetime:** per execution attempt; overwritten on the next certification of the same WBS.
 
 ## Optional check severity (task 0592, feature F92)
 
@@ -304,6 +320,6 @@ The prose shape above is executed by a single runtime-validated contract:
   failure can never yield PASS.
 - A row-less artifact aggregates to UNKNOWN — a stored PASS that does not recompute to PASS
   (including a row-less PASS) is treated as non-PASS at the done gate. The done-transition choke
-  point (`done-transition-guard.ts` `evaluateDoneTransition`) is the final authority; workflow JSON
-  routing may select `verify → record/failed` but cannot weaken the final transition.
+  point (`done-transition-guard.ts` `evaluateDoneTransition`) is the final authority; workflow
+  routing may select `review → done/failed` but cannot weaken the final transition.
 - `--force-done --reason` on `spur task update <wbs> done` remains the sole auditable override.

package/plugins/sp/skills/conflict-finding/SKILL.md

@@ -57,24 +57,29 @@ dependency, or dedicated subagent.
 - Code review — use `sp:code-review` / `sp:code-verification`.
 - General documentation drift maintenance — use `sp:doc-evolve`.
 - Performing repairs automatically — this skill only audits and (with `--resolve`) proposes
-  confirmed, owner-routed repairs; it never mutates without explicit confirmation.
+  confirmed, owner-routed repairs; it never mutates without explicit confirmation (interactive, or
+  the operator's explicit `--auto` pre-approval of eligible items).
 
 ## Arguments
 
 | Argument                                             | Description                                                                                                                                          | Default         |
 | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
-| `[scope]`                                            | Optional path, WBS, feature ID, symbol, command, config key, or free-form subject to scope the audit.                                                | current project |
+| `--tasks <selector>`                                 | Task set (comma WBS list or `feature:<id>`, batch selector grammar) seeding the audit.                                                                | —               |
+| `--feature <id>[,<id>]`                              | Union of the `feature:<id>` task sets plus the feature records themselves, seeding the audit.                                                        | —               |
+| `--scope <path>[,<path>]`                            | Tracked files under one or more existing paths, seeding the audit.                                                                                   | —               |
+| `[<wbs\|path>]`                                      | Deprecated positional alias for `--tasks <wbs>` / `--scope <path>` (one release).                                                                    | —               |
 | `--pillar <source\|tasks\|features\|authority\|all>` | Limit the internal audit to one pillar; the minimum authorities needed to judge it still load.                                                       | `all`           |
 | `--mode <adaptive\|full>`                            | Scan protocol — `adaptive` reuses fresh, provenance-verifiable indexed context and discloses skipped areas; `full` forces a cold comprehensive scan. | `adaptive`      |
 | `--resolve`                                          | Enable the proposal, confirmation, and owner-routed remediation workflow. Its absence guarantees no source/corpus/numbered-doc mutation.             | off             |
+| `--auto`                                             | Under `--resolve`, pre-approve the eligible repair set at the confirmation gate (Step 10). Requires `--resolve`.                                    | off             |
 | `--agent <inline\|auto\|name>`                       | Who runs the model-bearing analysis. `inline` is the default; `--agent auto`/a named executor isolates the analysis. Not a dedicated subagent.       | `inline`        |
 | `--json`                                             | Emit the same result envelope as Markdown as JSON. Never implies deterministic semantic reasoning.                                                   | off             |
 
 ## The 10-Step Audit Protocol
 
 ```
-scope + flags
-  → PARSE & GUARD     resolve scope/flags; confirm repository root; set audit-only vs resolve mode
+target + flags
+  → PARSE & GUARD     resolve + freeze the target set; confirm repository root; set audit-only vs resolve mode
   → DISCOVER AUTHORITY  read entry/process rules; build the claim-specific authority matrix
   → PREFLIGHT         git, rg, spur task/feature --json, relevant spur … check, doc-evolve audit
   → INVENTORY         four-pillar inventory: pillar, identity, path, anchor, freshness, scan status
@@ -84,13 +89,35 @@ scope + flags
   → CROSS-PILLAR      all six applicable boundaries
   → CLASSIFY          lifecycle, supersession, abstraction-level, intentional-deprecation challenges
   → REPORT            order by severity then confidence; coverage, unresolved authority, scan cost
-  → REMEDIATE         only with --resolve and explicit confirmation + freshness recheck
+  → REMEDIATE         only with --resolve and explicit (or --auto pre-) confirmation + freshness recheck
 ```
 
 ### Step 1 — Parse and guard
 
-Resolve `<scope>` and `--pillar`; confirm the repository root; establish **audit-only** versus
-`--resolve` mode. Without `--resolve`, the run is strictly read-only: no source, corpus, or
+Resolve the target and `--pillar`; confirm the repository root; establish **audit-only** versus
+`--resolve` mode.
+
+**Target selection.** At most one of `--tasks`, `--feature`, `--scope` (a deprecated positional
+beside an explicit selector counts as a second kind) — more than one refuses the audit naming the
+conflicting selectors. None → the whole project. Resolve the set **once** and freeze it:
+
+- `--tasks` / `--feature` go through the shared batch resolver
+  ([execution-batch.md § Step 1](../spur-dev/references/execution-batch.md#step-1--selector-resolution-r1));
+  `--feature <id>[,<id>]` is sugar for the union of the `feature:<id>` sets, and the feature records
+  join the seed set. Status pseudo-lists and `ready` are refused. An unresolvable WBS/feature refuses
+  the audit.
+- `--scope` paths must exist; normalize them, drop duplicates, collapse nested paths to the ancestor.
+- Deprecated positional: a `^\d{4}$` token with a resolvable task → `--tasks <wbs>`; an existing path
+  → `--scope <path>`; anything else refuses. Emit a deprecation warning naming the replacement.
+
+The frozen objects **seed one audit** — they are the starting nodes of the candidate graph (Step 5),
+not the boundary of what may be read: the authorities and counterpart artifacts needed to judge them
+still load. One audit, not one per object, so conflicts *between* selected objects stay visible.
+Every finding names the seed object(s) it traces to; `coverage` accounts per seed object.
+
+`--auto` without `--resolve` refuses the audit (it has no gate to skip in audit mode).
+
+Without `--resolve`, the run is strictly read-only: no source, corpus, or
 numbered-document mutation of any kind. With `--resolve`, no write happens until a repair set is
 presented, explicitly confirmed, and freshness-revalidated.
 
@@ -98,7 +125,7 @@ Validate every enum flag against the domain declared by the command surface
 (`plugins/sp/commands/dev-find-conflict.md`): `--pillar` ∈ `source|tasks|features|authority|all`,
 `--mode` ∈ `adaptive|full`, `--agent` ∈ `inline|auto|name`. An out-of-domain value **refuses** the
 audit before any discovery work — report the received value, the flag's valid domain, and stop;
-never silently coerce or ignore it. Only `<scope>` is free-form and exempt from this check.
+never silently coerce or ignore it.
 
 ### Step 2 — Discover local authority
 
@@ -157,8 +184,9 @@ findings, evidence, authority provenance, coverage, unresolved decisions, and re
 
 ### Step 10 — Remediate only when requested
 
-With `--resolve`: present the proposed repair set, obtain explicit confirmation, revalidate evidence
-freshness, then route each approved repair through its verified owner surface. Report the completed,
+With `--resolve`: present the proposed repair set, obtain explicit confirmation (or, under
+`--auto`, the pre-approval of the eligible subset — [remediation-routing.md §2.2a](references/remediation-routing.md#22a---auto-pre-approval)),
+revalidate evidence freshness, then route each approved repair through its verified owner surface. Report the completed,
 failed, and untouched sets; never silently roll forward past a partial failure. See
 [references/remediation-routing.md](references/remediation-routing.md).
 
@@ -173,7 +201,7 @@ items; no mutation.
 {
   "schema_version": 1,
   "command": "dev-find-conflict",
-  "scope": "docs/00_ADR.md",
+  "scope": "scope:docs/00_ADR.md",
   "mode": "adaptive",
   "pillars": ["authority"],
   "authority_map": {},
@@ -226,10 +254,10 @@ Thin wrapper: `Skill(skill="sp:conflict-finding", args="$ARGUMENTS")`.
 
 ```
 /sp:dev-find-conflict
-/sp:dev-find-conflict docs/00_ADR.md
-/sp:dev-find-conflict --pillar tasks --mode full
-/sp:dev-find-conflict 0486 --resolve
-/sp:dev-find-conflict "command surface" --json
+/sp:dev-find-conflict --scope docs/00_ADR.md
+/sp:dev-find-conflict --tasks 0486,0487 --pillar tasks --mode full
+/sp:dev-find-conflict --feature H11 --resolve
+/sp:dev-find-conflict --scope apps/cli --resolve --auto --json
 ```
 
 ## Common rationalizations
@@ -240,6 +268,7 @@ Thin wrapper: `Skill(skill="sp:conflict-finding", args="$ARGUMENTS")`.
 | "Lower-numbered docs always win."          | Authority is claim-specific; the constitution's precedence applies only within its stated boundary.                                                             |
 | "Code is always right."                    | Code is authoritative for what currently happens, not automatically for what should happen.                                                                     |
 | "`--resolve` authorizes automatic repair." | It opens the proposal/confirmation workflow; every repair still needs explicit confirmation and a freshness check, then the owner surface.                      |
+| "`--auto` approves everything."            | It pre-approves only eligible items (resolved authority, `high` confidence, verified owner surface); authority decisions still pause; freshness still applies. |
 | "Adaptive can reuse any context."          | Reuse requires freshness + verifiable provenance; absent/stale/unverifiable context degrades to a cold scan or an explicit incomplete-coverage result.          |
 
 ## Red flags
@@ -248,7 +277,8 @@ Thin wrapper: `Skill(skill="sp:conflict-finding", args="$ARGUMENTS")`.
 - Forcing an ambiguous/missing authority through a global ranking instead of an unresolved HITL item.
 - Silently omitting a selected pillar or a tool failure (no coverage accounting).
 - Claiming "comprehensive" when `coverage.complete` is false.
-- Any mutation in audit mode, or automatic mutation merely because `--resolve` is present.
+- Any mutation in audit mode, or automatic mutation merely because `--resolve` is present (without `--auto`).
+- Under `--auto`, applying an ineligible item or settling a `needs-authority-decision` item.
 - Editing a derived projection before correcting a defective authority, or changing a correct authority merely to repair its stale projection.
 - Adding a production analyzer, index/cache/database, dependency, or dedicated subagent in v1.
 

package/plugins/sp/skills/conflict-finding/references/comparison-protocol.md

@@ -76,8 +76,10 @@ Join keys, in priority order:
 
 Construction protocol:
 
-1. **Seed from scope.** If `<scope>` is a path/WBS/feature-id/symbol/command/config-key, seed the
-   graph with every artifact whose identity or content references that scope.
+1. **Seed from the frozen target.** Every object in the `--tasks` / `--feature` / `--scope` set is
+   a seed, plus every artifact whose identity or content references one of them (its WBS, feature
+   ID, or path). Multiple seeds share one graph, so edges between seeds are compared too. No
+   selector → the whole project is the seed set.
 2. **Grow by shared keys.** For each seed, add an edge to any artifact sharing one of the keys
    above for the _same subject_. A key matches only when it refers to the same subject, not merely
    the same string in an unrelated context (see normalize).