@gobing-ai/spur 0.3.51 → 0.3.52

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

@@ -12,10 +12,12 @@ Task bodies are edited section-by-section through `spur task update --section <n
 replaced wholesale from the file you point at. There is no inline-body flag — always stage the new
 body in a file first.
 
-For **pipeline output** (`Testing` / `Review` / safety-net `Solution`), prefer `spur task record`
-over hand-assembling files — it renders the matrix-compliant tables from a verify verdict for you.
-Use the manual recipe below for `Plan`, `Acceptance Criteria`, hand-authored `Solution`, and any
-narrative section.
+For **pipeline output**, section authorship is one-writer-per-section (F92 0593 R1):
+`Testing` comes from `spur task record` (deterministic, from a verify verdict artifact — the
+matrix-compliant tables are rendered for you); `Review` is authored by the review coordinator
+(`/sp:dev-review`), with `record` backfilling it only when bare; `Solution` is authored by the
+implement step (record safety-nets a bare `Solution` from the diff). Use the manual recipe below
+for `Plan`, `Acceptance Criteria`, hand-authored `Solution`, and any narrative section.
 
 ## The recipe
 
@@ -47,16 +49,19 @@ exactly: `Background`, `Requirements`, `Acceptance Criteria`, `Q&A`, `Design`, `
 
 ## `record` vs. hand-editing
 
-`spur task record 0040 --transition testing` reads `.spur/run/0040-verdict.json` and writes both
-`Testing` (per-requirement table) and `Review` (P1–P4 findings table) in the matrix-required shape,
-optionally backfilling a bare `Solution` from `git diff -U0`. It never transitions to `done`.
+`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`.
 
-- **Use `record`** when a verify step produced a verdict artifact — it is the pipeline's record step.
+- **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.
 
-The two are interchangeable on the same section: `record` writes `Review`, a later
-`update --section Review` overwrites it. Both go through the same file-wins atomic write.
+`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.
 
 ## Which section, when
 
@@ -68,9 +73,13 @@ LLM's job (orchestrated by `sp:spur-dev`); this skill only owns the *mechanism*:
 | `Background` | at create (derived from feature `Goal` if `--feature`) | why this task exists |
 | `Acceptance Criteria` | planning (present at `todo` for spec'd tasks) | the scenarios this task satisfies (matched to feature AC by title) |
 | `Plan` | before `wip` | the step list |
-| `Solution` | during impl (first appears at `wip`) | the approach actually taken; L3 `file:line` rule fires once it has real content |
-| `Testing` | testing phase (via `record`) | what was verified and how — gated at `wip→testing` by `check` |
-| `Review` | review phase (via `record`) | SECU findings + verdict — gated at `testing→done` by `check --strict-core` |
+| `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` |
+
+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`
+(required sections at the current status) before writing.
 
 A spec'd task (`--feature` link or batch item with `background`/`requirements`) is created at `todo`
 with Acceptance Criteria + Plan scaffolding present; a bare capture is created at `backlog` with

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

@@ -35,8 +35,9 @@ and its scaffold body. **Default:** `feature-impl` when `--feature` is given, el
 unknown variant is exit `2`.
 
 **Creation status** follows the matrix: a spec'd task (a `--feature` link, or a batch item with
-`background`/`requirements`) is created at **`todo`** ("ready to execute"); a bare capture is created
-at **`backlog`** ("still preparing"). `Solution` first appears at `wip`.
+`background`/`requirements`) is created at **`todo`**; a bare capture is created at
+**`backlog`** ("still preparing"). Which sections a status carries is a runtime contract — query
+`spur task sections <wbs> list --json` or `spur task check <wbs> --json`; do not restate the matrix.
 
 ## `show <wbs>` / `list`
 
@@ -50,8 +51,10 @@ Multi-mode. Status and `--section` are **mutually exclusive**; `--feature`/`--pr
 frontmatter scalar.
 
 - **Status** (positional): legal transition over `backlog → todo → wip → testing → blocked → done →
-  cancelled`. Two transitions run a `check` guard (§7.5): `wip→testing` → `spur task check <wbs>`;
-  `testing→done` → `spur task check <wbs> --strict-core`. A failing gate blocks the transition.
+  cancelled`. Two transitions run a target-aware `check` guard (§7.5): `wip→testing` →
+  `spur task check <wbs> --as testing`; `testing→done` → `spur task check <wbs> --as done`
+  (F92 R3 — each evaluates the transition target, so `testing→done` checks the `done` row).
+  A failing gate blocks the transition.
 - **`--no-lifecycle`**: suppress lifecycle workflow *run record* creation (use inside pipeline runs
   to avoid orphaned nested lifecycle runs). **It is not a guard bypass** — the `wip→testing` and
   `testing→done` `check` gates above still run; the CLI evaluates them inline when the FSM guard
@@ -127,8 +130,9 @@ in `sp:spur-dev`.
 
 ## `record <wbs>`
 
-Write `Testing` + `Review` from a verify verdict, with optional `Solution` backfill and a lifecycle
-transition. Collapses the pipeline's record step to one call.
+Write `Testing` from a verify verdict artifact — the **deterministic Testing writer** (F92 0593 R1) —
+with a **bare-only `Review` backfill** (never overwrites authored Review), optional `Solution`
+backfill, and a lifecycle transition. Collapses the pipeline's record step to one call.
 
 | Flag | Effect |
 | ---- | ------ |
@@ -149,9 +153,11 @@ transition. Collapses the pipeline's record step to one call.
 
 - `verdict`: `PASS` | `PARTIAL` | `FAIL` | `UNKNOWN`. A missing/malformed/empty file degrades to
   `UNKNOWN` (empty arrays) — `record` never throws.
-- `requirements[]` → the `Testing` per-requirement table. `checks[]` → the `Review` P1–P4 findings
-  table. With no requirements/checks, each renders exactly one "none recorded" row (a clean verify is
-  a valid outcome; the matrix requires a table, not an empty section).
+- `requirements[]` → the `Testing` per-requirement table (deterministic transcript).
+- `checks[]` → the P1–P4 findings table used for the **bare-only `Review` backfill** — the done-gate's
+  `## Review` L3 layer is satisfied by the `review` coordinator's authored table; `record` writes the
+  fallback shape only when the section is bare. With no requirements/checks, each renders exactly one
+  "none recorded" row (a clean verify is a valid outcome; the matrix requires a table, not an empty section).
 - `--solution-from-diff` parses `+++ b/<path>` + `@@ +new @@` hunk headers into sorted, unique
   `` `file:line` `` rows; falls back to `--name-only` at `:1` when there are no hunk lines.
 
@@ -162,7 +168,12 @@ traceability. Bare = whole corpus; with a WBS = one task. The matrix is loaded f
 `.spur/tasks/section-matrix.yaml`.
 
 - **`--strict`** elevates *all* warnings to failures.
-- **`--strict-core`** is the `testing→done` gate variant: fails only on **hard-core errors** —
+- **`--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; mutually exclusive
+  with `--corpus`. Omitted `--as` uses current-status diagnostics.
+- **`--strict-core`** is a **temporary compatibility alias** (F92 R2), retained so installed
+  plugins/workflows that call it keep working; target-state selection (`--as`) supplies the real
+  done semantics. Fails only on **hard-core errors** —
   Solution `file:line`, Review P1–P4, and `gate:true` required-section misses — *without* the blanket
   warning elevation.
 
@@ -354,7 +365,7 @@ spur task refresh-roster <wbs> [--folder] [--json]
 spur task batch-create --file <path> [--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 check    [wbs] [--strict] [--strict-core] [--folder] [--json]
+spur task check    [wbs] [--strict] [--as <status>] [--strict-core] [--folder] [--json]
 spur task resolve  <file-path> [--strict] [--folder] [--json]
 spur task path     <wbs> [--folder] [--json]
 spur task run-link <wbs> [--source <src>] [--run-id <id>] [--json]

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

@@ -49,9 +49,9 @@ re-reading or re-tokenizing the task.
 | `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` |
-| `record <wbs>` | Write Testing/Review from a verify verdict; optional Solution + transition | `--verdict-file <path>` `--solution-from-diff` `--transition <status>` `--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; the readiness matrix | `--strict` `--strict-core` `--folder` `--json` |
+| `check [wbs]` | Four-layer validation; the readiness matrix | `--strict` `--as <status>` `--strict-core` `--folder` `--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` |
@@ -120,7 +120,8 @@ spur task update 0040 wip
 
 Valid statuses: `backlog · todo · wip · testing · blocked · done · cancelled` (the lifecycle engine
 enforces legal transitions). Two transitions are **guarded by `check`**: `wip→testing` runs
-`spur task check <wbs>`, and `testing→done` runs `spur task check <wbs> --strict-core` — a failing
+`spur task check <wbs> --as testing`, and `testing→done` runs `spur task check <wbs> --as done`
+(F92 R3 — target-aware guards) — a failing
 gate blocks the transition (§7.5).
 
 **`--no-lifecycle`** suppresses lifecycle workflow *run record* creation (use during pipeline-driven
@@ -166,12 +167,14 @@ spur task update 0040 --priority P1
 The section-write-then-replace pattern is the workflow agents use to fill in `Plan` / `Solution` /
 `Testing` / `Review` during a run. See
 [tasks/section-editing.md](tasks/section-editing.md) for the full recipe. For pipeline
-output specifically, prefer **`record`** (below) over hand-assembling Testing/Review files.
+output specifically, prefer **`record`** for `Testing` (below) over hand-assembling section files; `Review` is authored by the review coordinator (`/sp:dev-review`), not hand-filled.
 
 ## Recording pipeline results — `record`
 
-`spur task record <wbs>` writes the `Testing` and `Review` sections **from a verify verdict**, so the
-pipeline's record step is one CLI call instead of awk/sed/jq plumbing:
+`spur task record <wbs>` writes the `Testing` section **from a verify verdict artifact** (the
+deterministic Testing writer — F92 0593 R1) and backfills `Review` **only when the section is
+bare** (standalone compatibility fallback; never overwrites authored Review), so the pipeline's
+record step is one CLI call instead of awk/sed/jq plumbing:
 
 ```bash
 spur task record 0040 --transition testing
@@ -179,8 +182,8 @@ spur task record 0040 --verdict-file .spur/run/0040-verdict.json --solution-from
 ```
 
 - Reads the verdict JSON (default `.spur/run/<wbs>-verdict.json`); renders `Testing` as a
-  per-requirement table and `Review` as a P1–P4 findings table. A missing/malformed verdict degrades
-  to an `UNKNOWN` verdict — it never throws.
+  per-requirement table and, when the `Review` section is bare, backfills a P1–P4 findings table.
+  A missing/malformed verdict degrades to an `UNKNOWN` verdict — it never throws.
 - **`--solution-from-diff`** backfills `Solution` from `git diff -U0` hunk headers **only when the
   Solution section is still bare** — a safety net, not an overwrite.
 - **`--transition <status>`** optionally advances the lifecycle after writing (e.g. `testing`).
@@ -235,7 +238,8 @@ corpus, or with a WBS for one task:
 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 --strict-core  # the testing→done gate variant
+spur task check 0040 --as done        # evaluate as the done row (lifecycle target, F92 R2)
+spur task check 0040 --strict-core    # temporary compatibility alias
 ```
 
 **Folder resolution (task 0522):** a WBS-targeted check (`<wbs>` present, no `--folder`) resolves
@@ -253,7 +257,9 @@ or "are there orphaned scenarios?" rather than reading task files and re-impleme
 The two flags are distinct gate profiles:
 
 - **`--strict`** elevates *all* warnings to failures (the strictest reading).
-- **`--strict-core`** fails only on hard-core errors — Solution `file:line`, Review P1–P4, and
+- **`--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.
 

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

@@ -122,7 +122,7 @@ reference for the half you're operating; do not duplicate its content here.
 | Continue | execution | `spur feature update` / `refresh` | [execution-workflow.md](references/execution-workflow.md) |
 | Batch run | execution | `sp:super-planner` + `spur workflow run` | [execution-batch.md](references/execution-batch.md) |
 | Parallel fan-out | execution | `sp:parallel-execution` decision framework | [execution-batch.md](references/execution-batch.md) |
-| All writes (both halves) | — | CLI-gated section editing | [cross-cutting.md](references/cross-cutting.md) · [section-batching.md](references/section-batching.md) |
+| All writes (both halves) | — | CLI-gated section editing | [cross-cutting.md](references/cross-cutting.md) · [section-batching.md](references/section-batching.md) (one-writer protocol, F92 0593) |
 
 ## When to use
 
@@ -156,8 +156,11 @@ CLI does.
 1. **Never skip a gate.** A clean `feature check` is the only proof the AC is valid; a
    passing `batch-create` is the only proof the decomposition is well-formed. Skip either and
    you ship corrupted corpus.
-2. **The pipeline, not you, writes results.** `## Testing` and `## Review` sections are
-   filled by the pipeline's `record` step. Do not edit them directly during execution.
+2. **One writer per evidence section (F92 0593 R1).** `## Solution` is authored by the
+   implement step; `## Review` by the review coordinator (`/sp:dev-review`); `## Testing` by the
+   deterministic `record` step from the verdict artifact (`record` backfills `## Review` only when
+   bare — fallback-only, never an overwrite). During execution, do not hand-edit another stage's
+   section.
 3. **Resolve task IDs through the CLI.** Read a known WBS with `spur task show <wbs> --json`; it
    returns metadata, full content, and `filePath` across configured task folders. Use `spur task
    path <wbs> --json` only when another tool needs the absolute path. Never search `docs/tasks*` or
@@ -189,8 +192,10 @@ for "what's actually in file Y" or for resources that sit outside the step seque
 - [references/gate-checklists.md](references/gate-checklists.md) — checkbox checklists for the
   five gates (feature-check, batch-create, precheck, review, verify). Each checklist is a
   `- [ ]` list of prerequisites an agent verifies before entering the gate.
-- [references/section-batching.md](references/section-batching.md) — first-write protocol for
-  staging Solution, Testing, and Review together before one task check.
+- [references/section-batching.md](references/section-batching.md) — the evidence-section
+  **one-writer protocol** (F92 0593 R1/R2): implement owns `Solution`, the review coordinator owns
+  `Review`, deterministic `record` owns `Testing`; skills query `spur task sections` /
+  `spur task check` instead of static section tables.
 - [references/ac-style-guide.md](references/ac-style-guide.md) — BDD scenario authoring:
   R-numbering, the two AC tiers, scenario-title stability, Gherkin template usage.
 - [references/feature-link-helper.md](references/feature-link-helper.md) — opt-in,

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

@@ -110,17 +110,17 @@ must not be changed without updating the backing skill.
 
 - **Purpose:** Multi-dimensional code review of a task or path — (1) functional requirements traceability (WBS mode only), (2) SECUA framework (Security, Efficiency, Correctness, Usability, Architecture), (3) architecture depth.
 - **Modes:**
-  - **WBS mode (`<wbs>`)**: Runs functional requirements traceability (`sp:functional-review`), SECUA framework (`sp:code-verification`), and architectural depth (`sp:code-improvement`). May write findings to the task's `## Review` section.
+  - **WBS mode (`<wbs>`)**: Runs functional requirements traceability (`sp:functional-review`), SECUA framework (`sp:code-verification`), and architectural depth (`sp:code-improvement`). The three skills return review fragments; the coordinator writes the combined `## Review` (F92 0593 R1).
   - **Path mode (`<path>`)**: Runs advisory SECUA framework (`sp:code-verification`) and architectural depth (`sp:code-improvement`). Performs no task mutation.
 - **Inputs:** `<wbs|path>` (required). Review executes inline (in-session) by default. `--agent <inline|auto|name>` selector accepted (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--focus <lens>` narrows to one SECUA dimension. Note: `--fix` and `--next` are **deprecated** (no-op with warning; route remediation to `/sp:dev-verify --fix` and progression to `/sp:dev-next`).
 - **Backing:** `sp:functional-review`, `sp:code-verification` (review mode), `sp:code-improvement`.
-- **Behavior:** WBS mode runs functional traceability + SECUA + architecture depth, ranking findings P1–P4 and writing findings to the task's `## Review` section. Path mode runs advisory SECUA + architecture depth with no task mutation.
+- **Behavior:** WBS mode runs functional traceability + SECUA + architecture depth, ranking findings P1–P4, and hands the merged report to the review coordinator, which writes `## Review`. Component skills never write `## Review` in coordinated mode. Path mode runs advisory SECUA + architecture depth with no task mutation.
 - **Delegation:** WBS mode: `sp:functional-review` + `sp:code-verification` (review) + `sp:code-improvement`; Path mode: `sp:code-verification` (review) + `sp:code-improvement`.
 
 ### 3. verify
 
 - **Purpose:** Requirements traceability — verify a task's implementation against its acceptance criteria, producing a PASS/PARTIAL/FAIL verdict with per-requirement evidence. Optionally (with `--fix all`) evaluate **feature shippable readiness**.
-- **Inputs:** `<wbs>` (required). Verify executes inline (in-session) by default. `--agent <inline|auto|name>` selector accepted (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--fix`, `--focus`, `--bdd`, `--auto`, `--force` modulate the verify pass. `--next` (terminal chain link): on the **post-`--fix`** PASS verdict, transition `testing → done` through the FSM (`--strict-core` guard honored). On PARTIAL/FAIL or guard failure, stop as review-pending. **`--skip-shippable`** (alias `--skip-shipable`): disable the shippable gate that otherwise runs under `--fix all` when the task has a `feature_id`.
+- **Inputs:** `<wbs>` (required). Verify executes inline (in-session) by default. `--agent <inline|auto|name>` selector accepted (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--fix`, `--focus`, `--bdd`, `--auto`, `--force` modulate the verify pass. `--next` (terminal chain link): on the **post-`--fix`** PASS verdict, transition `testing → done` through the FSM (target-aware `--as done` guard honored). On PARTIAL/FAIL or guard failure, stop as review-pending. **`--skip-shippable`** (alias `--skip-shipable`): disable the shippable gate that otherwise runs under `--fix all` when the task has a `feature_id`.
 - **Backing:** `sp:code-verification` skill, `verify` mode.
 - **Behavior:** Status guard → change-scope detection → requirements traceability → SECUA review → verdict aggregation → findings write-back → verdict-artifact emission → optional `--fix` pass → **shippable readiness** (when active). The per-task verdict gates the pipeline's `done` transition. With `--next`: the (post-`--fix`) PASS verdict → transition to `done` (FSM guard honored); PARTIAL/FAIL → stop and surface verdict. Shippable FAIL does not rewrite the task verdict line but must be printed; feature is not “ready.”
 - **Shippable readiness (default on with `--fix all`):** After the task verdict, if `--fix all` and the task has `feature_id` and not `--skip-shippable`, run `spur feature check <id> --json` + linked-task completeness. Emit `Shippable: PASS|FAIL|N/A`. FAIL when feature AC scenarios are orphaned/unverified or any linked task is not `done`/`cancelled`. SSOT procedure: `sp:code-verification` Step 13.
@@ -129,9 +129,9 @@ must not be changed without updating the backing skill.
 ### 3a. verifyall
 
 - **Purpose:** Batch verification of a set of tasks (or all tasks under a feature) against their requirements and AC. Produces per-task verdicts + a summary report with aggregate statistics (counts, table, overall batch verdict). With `--fix all`, also evaluates **feature shippable readiness** once for the set.
-- **Inputs:** `--tasks <selector>` (required unless `--feature`). `--feature <id>` (convenience for `--tasks feature:<id>`). Shared verify flags from `dev-verify` (`--agent <inline|auto|name>`, `--fix`, `--focus`, `--bdd`, `--auto`, `--force`, **`--skip-shippable`**). `--next` (per-task lifecycle chaining: on a PASS verdict transition `testing → done` through the FSM with `--strict-core` honored; PARTIAL/FAIL does not transition; transitions run **before** the shippable gate so `spur feature check` sees final statuses). `--json` for machine-readable summary report.
+- **Inputs:** `--tasks <selector>` (required unless `--feature`). `--feature <id>` (convenience for `--tasks feature:<id>`). Shared verify flags from `dev-verify` (`--agent <inline|auto|name>`, `--fix`, `--focus`, `--bdd`, `--auto`, `--force`, **`--skip-shippable`**). `--next` (per-task lifecycle chaining: on a PASS verdict transition `testing → done` through the FSM with the target-aware `--as done` guard honored; PARTIAL/FAIL does not transition; transitions run **before** the shippable gate so `spur feature check` sees final statuses). `--json` for machine-readable summary report.
 - **Backing:** `sp:spur-dev` skill, `verifyall` operation (resolves the set using the shared selector grammar, dispatches per-task verify via `sp:code-verification` verify mode, writes per-task artifacts, aggregates and emits the batch summary report, then optional shippable gate).
-- **Behavior:** Resolve + freeze the set (supports `--feature` sugar). For each task: apply status guard, requirements traceability + AC + SECUA review, write `## Testing` + verdict.json (per-task fix pass under `--fix`). After the batch: **shippable gate once** when active (see below). Emit a structured summary report (markdown or `--json`). Per-task behavior matches single `dev-verify` (except shippable is batch-once). **Batch verdict rollup is deterministic** — computed by `spur task verifyall-aggregate --from-file <batch-input.json> --json` (a tested service module, not agent discretion). **Per-task outcome grammar:** `PASS` / `PARTIAL` / `FAIL` for implemented tasks; `NOT-STARTED` for tasks that have not entered implementation (status `backlog`/`todo`/`blocked` — reachable only via `--force`). **Rollup rule:** all-NOT-STARTED → `UNKNOWN`; any `FAIL` → `FAIL`; any `PARTIAL` or `UNKNOWN` → `PARTIAL`; all `PASS` → `PASS`. NOT-STARTED rows are _excluded_ from the FAIL/PARTIAL rollup (they cannot manufacture a batch failure) but are _reported explicitly_ in the summary ("N NOT-STARTED, excluded from rollup"). This closes the 0341 dogfood gap where a healthy feature with 5 PASS + 2 unstarted tasks read as FAIL. **Shippable FAIL:** treat the batch as not clean — force rollup to at least **PARTIAL** and set `"shippable": false` under `--json` even if every task outcome is PASS.
+- **Behavior:** Resolve + freeze the set (supports `--feature` sugar). For each task: apply status guard, requirements traceability + AC + SECUA review, emit the verdict artifact (per-task fix pass under `--fix`). `## Testing` is written by the deterministic `record` step from the artifact (F92 0593 R1). After the batch: **shippable gate once** when active (see below). Emit a structured summary report (markdown or `--json`). Per-task behavior matches single `dev-verify` (except shippable is batch-once). **Batch verdict rollup is deterministic** — computed by `spur task verifyall-aggregate --from-file <batch-input.json> --json` (a tested service module, not agent discretion). **Per-task outcome grammar:** `PASS` / `PARTIAL` / `FAIL` for implemented tasks; `NOT-STARTED` for tasks that have not entered implementation (status `backlog`/`todo`/`blocked` — reachable only via `--force`). **Rollup rule:** all-NOT-STARTED → `UNKNOWN`; any `FAIL` → `FAIL`; any `PARTIAL` or `UNKNOWN` → `PARTIAL`; all `PASS` → `PASS`. NOT-STARTED rows are _excluded_ from the FAIL/PARTIAL rollup (they cannot manufacture a batch failure) but are _reported explicitly_ in the summary ("N NOT-STARTED, excluded from rollup"). This closes the 0341 dogfood gap where a healthy feature with 5 PASS + 2 unstarted tasks read as FAIL. **Shippable FAIL:** treat the batch as not clean — force rollup to at least **PARTIAL** and set `"shippable": false` under `--json` even if every task outcome is PASS.
 - **Shippable readiness (default on with `--fix all`):** Active when `--fix all` and feature context exists (`--feature` or unique shared `feature_id`) and not `--skip-shippable`. Procedure: `sp:code-verification` Step 13 once after all per-task legs. Without `--fix all`, do not run the hard gate (optional note: use `--fix all` for ship evaluation).
 - **Cache discipline (batch):** freeze the `spur task list --feature <id> --json` (or selector) capture once at resolve; reuse that snapshot for every per-task verify leg. Do not re-list the set mid-batch. Re-read a task body only when that task's sections changed (e.g. after a `--fix` write). Prefer re-reading only cited `file:line` anchors over re-tokenizing full Solution sections when prior Testing is already present.
 - **Dogfood / mutation composition:** prefer step-split when dogfooding verifyall with `--fix all` and/or `--next` — first observe-only verifyall, then a separate fix pass, then `--next` only if status transitions are still needed. See `sp:dogfood-testing` §step-splitting.

package/plugins/sp/skills/spur-dev/references/execution-workflow.md

@@ -60,7 +60,13 @@ default. See the [inline-default execution-surface contract](cross-cutting.md#in
 
 > **Single-run & parse discipline (suite run cost control).** Run full quality/test suites (`bun run check` / `spur-check`) at most ONCE per task iteration (task 0436 R2). Parse failure details from the single retained command output rather than re-running full suites repeatedly to inspect errors. Re-run targeted/narrow test files (e.g. `bun test <file> --test-name-pattern <pattern>`) while iterating on fixes, and re-run the full suite only when all targeted fixes pass.
 
-## Section ownership — `## Solution`
+## Section ownership — one writer per evidence section (F92 0593 R1)
+
+| Section | Writer |
+| --- | --- |
+| `## Solution` | **implement** step (`sp:code-implementation`) |
+| `## Review` | **review coordinator** (`/sp:dev-review` → `sp:super-reviewer`, merged fragments) |
+| `## Testing` | **`spur task record`** (deterministic, from the verdict artifact) |
 
 The implement step **owns** `## Solution` (the change-map). After writing code, before
 yielding, the implement agent authors the `## Solution` section — a markdown table listing
@@ -163,9 +169,10 @@ The `test` hop is primarily
   resume the host driver with the operator's answer.
 - **On guard failure** (`precheck`): the task's check findings block progress — fix the
   task first.
-- **On completion** (`done`): the pipeline's `record` step has already written results into
-  the task's `## Testing` and `## Review` sections via `spur task record <wbs>` (verdict →
-  matrix-compliant tables; never transitions to `done` — the gate stays in the workflow).
+- **On completion** (`done`): the pipeline's `record` step has already written the verdict
+  transcript into the task's `## Testing` via `spur task record <wbs>` (matrix-compliant tables;
+  `## Review` was authored by the review step and is only backfilled bare, never overwritten —
+  F92 0593 R1; never transitions to `done` — the gate stays in the workflow).
 
 ## `--next` chain — advance to the next step
 

package/plugins/sp/skills/spur-dev/references/gate-checklists.md

@@ -93,8 +93,10 @@ Entered before `task-pipeline.yaml` `verify` state produces a task verdict.
 - [ ] `spur task check <wbs> --strict-core --json` returns PASS.
 - [ ] Every AC scenario has a corresponding verify command that exited 0.
 - [ ] The `## Solution` section is filled (not the placeholder comment).
-- [ ] The `## Testing` section records the commands run and their outcomes.
-- [ ] The `## Review` section records findings (or explicitly states "no findings").
+- [ ] The `## Testing` evidence (commands run + outcomes) is present in the verdict artifact —
+      `spur task record` transcribes it deterministically (F92 0593 R1).
+- [ ] The `## Review` section carries the review coordinator's findings table (or is bare for the
+      record fallback) — verify never writes `## Review`.
 - [ ] No gate was bypassed with `--no-verify`, `--force`, or a suppression comment.
 - [ ] If `--auto` is set: the verdict is `PASS` (not `PARTIAL` or `FAIL`) — `--auto` does not auto-advance a failed verify.
 - [ ] The task is ready for `spur task record <wbs>` and legal transition to `done`.
@@ -154,7 +156,7 @@ transition to `done`.
 
 > **Corpus baseline discipline (`corpus-check`).** `corpus-check` sweeps every task/feature and fails on any structural finding outside `config/corpus-baseline.json`. The baseline is two-sided: an unlisted finding fails, **and** a listed entry that no longer reproduces fails. When introducing or tightening finding rules, reconcile the fallout in the same commit (constitution **T10**).
 >
-> **Transition-shim discipline (`transition-shim-check`, task 0541 / ADR-058).** Wired as the last step of `spur-check` / `spur-check-new`. Two-sided against `config/transition-shims.json`: an `@transition-shim(<id>)` marker with no manifest entry fails as a **new unregistered shim**, **and** a listed entry whose marker is gone from source fails as a **stale entry**. Emptying the manifest is the definition of the agent-role transition being complete. A removal condition must be objectively checkable against the repository. Shapes: `docs/04_DESIGN.md` §2.5.
+> **Transition-shim discipline (`transition-shim-check`, task 0541 / ADR-058).** Wired as an early step of `spur-check` / `spur-check-new` (second, after `link-check` and before `lint`) so a shim violation fails in ~0.3 s rather than after the test run. Two-sided against `config/transition-shims.json`: an `@transition-shim(<id>)` marker with no manifest entry fails as a **new unregistered shim**, **and** a listed entry whose marker is gone from source fails as a **stale entry**. Emptying the manifest is the definition of the agent-role transition being complete. A removal condition must be objectively checkable against the repository. Shapes: `docs/04_DESIGN.md` §2.5.
 
 > **Sandbox test baseline (`bun run test` / `spur-check`).** In the restricted Bash sandbox
 > `bun run spur-check` exits **1 regardless of code health**: ~24 tests bind real ports and the

package/plugins/sp/skills/spur-dev/references/section-batching.md

@@ -1,24 +1,40 @@
 ---
-name: section-batching
-description: Stage pipeline task sections together, apply them through Spur, and validate once per coherent batch.
+name: section-ownership
+description: One writer per evidence section — which stage authors Solution, Testing, and Review, and how a session sequences section writes against the runtime contract.
 see_also:
   - spur-dev
   - spur-cli
+  - super-reviewer
 ---
 
-# Section batching protocol
+# Evidence-section writer protocol
 
-Use this protocol when an in-session operation must author multiple pipeline sections. A workflow
-`record` step should still prefer `spur task record` for verdict-derived `Testing` and `Review`.
+There is exactly **one writer per evidence section** (feature F92, task 0593 R1). The section
+matrix is the runtime authority for *which sections are permitted at a status*; this protocol is
+the *who writes* map. The canonical stage registry projects the exact artifact identities
+(`packages/domain/src/stage-registry/schema.ts` → `RECORDED` stage `identity` fields); skills never
+restate that ownership as competing policy.
 
-1. Read `spur-cli/references/tasks/l3-guard-cheatsheet.md`.
-2. Run `spur task sections <wbs> list --json` to learn which sections the current matrix permits.
-3. Stage complete, body-only `Solution`, `Testing`, and `Review` files before the first task check.
-4. Run `spur task check <wbs> --json` once, then apply every permitted staged section with
-   `spur task update <wbs> --section <name> --from-file <path>`.
-5. Run `spur task check <wbs> --json` once after the coherent write batch.
-6. If the post-write check fails, group all findings by section, repair all affected staged bodies, re-apply them, and
-   check once more.
+| Section | Writer | When |
+| --- | --- | --- |
+| `## Solution` | **implement** (`sp:code-implementation`) | during the implement step; bare-only safety-net backfill by `record` from `git diff` |
+| `## Review` | **review coordinator** (`sp:super-reviewer` under `/sp:dev-review`) | during the review step, after merging component fragments |
+| `## Testing` | **`spur task record`** (deterministic, from the verdict artifact) | during the record step; never authored by hand |
+
+Component review skills (`sp:functional-review`, `sp:code-verification` review mode,
+`sp:code-improvement`) **return review fragments only** in coordinated mode — they do not write
+`## Review`. Verification emits the canonical verdict artifact; it does not write sections.
+`record`'s bare-`## Review` backfill is a **standalone compatibility fallback only** — it fires
+when the section is bare (absent/placeholder) and never overwrites authored Review.
+
+## Sequencing a write
+
+1. Query the runtime contract before writing — never a static table:
+   `spur task sections <wbs> list --json` (permitted sections at the current status) and
+   `spur task check <wbs> --json` (what the gate requires at the current status).
+2. Write only your stage's section, via
+   `spur task update <wbs> --section <name> --from-file <tmp>` (CLI-gated, body-only).
+3. Re-check once after the write batch: `spur task check <wbs> --json`.
 
 Budget: no more than two section writes per section and two task checks per task unless a new
 external failure changes the evidence. Do not use a write→check loop for each section.