@gobing-ai/spur 0.3.50 → 0.3.52

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

@@ -27,15 +27,16 @@ metadata:
 
 The **verifier** in the Spur execution loop. A coding agent reports "done" with overconfidence;
 this skill is the deterministic counterweight that proves — or disproves — the claim against the
-task's own requirements and Acceptance Criteria, then writes the evidence back to the corpus
-through CLI verbs.
+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).
 
 It backs two commands:
 
 | Command | Mode | Input | Output |
 |---------|------|-------|--------|
-| `/sp:dev-verify <wbs>` | **verify** | a task WBS | per-requirement verdict → `## Testing`; `.spur/run/<wbs>-verdict.json` |
-| `/sp:dev-review <wbs>` | **review** | a task WBS (diff scope) | three-dimensional findings → `## Review` (functional + SECUA + architecture) |
+| `/sp:dev-verify <wbs>` | **verify** | a task WBS | `.spur/run/<wbs>-verdict.json`; `record` transcribes `## Testing` |
+| `/sp:dev-review <wbs>` | **review** (coordinator) | a task WBS (diff scope) | merged three-dimensional findings → `## Review` |
 
 The verify mode is the **completion gate's evidence source**: it emits a machine verdict the
 `task-pipeline.yaml` workflow reads before allowing `record → done`. A `PASS` clears the gate; a
@@ -243,34 +244,32 @@ blocker finding → FAIL; core PARTIAL or an unresolved major finding (no FAIL)
 MET or justified N/A → PASS. Minor/advisory findings do not block. Only `PASS` clears the pipeline
 completion gate (`PARTIAL`/`FAIL` route the pipeline to `failed`).
 
-### Step 10 — Write findings to the task
+### Step 10 — Emit the verdict artifact (the only verify output)
 
-Assemble the evidence and write via CLI verbs (temp-file → `--section`):
+Assemble the evidence and **emit the canonical verdict artifact** — verification writes no task
+section (F92 0593 R1). Under the pipeline, the output is captured as
+`.spur/run/<wbs>-verify-answer.txt`; a deterministic shell step derives
+`.spur/run/<wbs>-verdict.json`, and the `record` step transcribes `## Testing` from it.
+
+**Standalone** (`/sp:dev-verify` outside the pipeline), write the artifact yourself, then invoke
+the deterministic Testing writer `spur task record` (section authorship never happens here):
 
 ```bash
-# Testing section: per-requirement and per-AC verdict tables + evidence
-printf '...' > /tmp/<wbs>-testing.md
-spur task update <wbs> --section Testing --from-file /tmp/<wbs>-testing.md
+# write .spur/run/<wbs>-verdict.json (shape in references/verdict-schema.md), then:
+spur task record <wbs> --verdict-file .spur/run/<wbs>-verdict.json  # renders ## Testing
 ```
 
 > **Corrections: the answer file is the source of truth.** `spur task record` re-transcribes
-> `## Testing` from the verdict artifact, overwriting `--section Testing` writes — direct section
-> fixes are futile. Fix `.spur/run/<wbs>-verify-answer.txt` → `spur task verdict <wbs>
-> --from-answer <file>` → re-record. `--section` is initial authorship only.
-
-> **Do not write `## Review` directly in verify mode.** The `## Review` section is owned by the
-> `review` step (`/sp:dev-review`), which dispatches `functional-review` + `code-verification`
-> review mode + `code-improvement`. The `record` step backfills `## Review` from the verdict
-> artifact only if the section is bare (`sectionIsBare` guard, `task-service.ts:485`). Writing
-> `## Review` here bypasses that guard and destroys the review step's three-dimensional findings.
-
-Section bodies passed to `spur task update --section` must be **body-only**. Do not put a same-level
-heading inside any section body; the task writer strips same-level headings to prevent phantom
-sections. Concretely:
+> `## Testing` from the verdict artifact — direct `--section Testing` writes are futile. Fix
+> `.spur/run/<wbs>-verify-answer.txt` → `spur task verdict <wbs> --from-answer <file>` → re-record.
 
-- **Testing section:** do not put `### Acceptance Criteria Verification`, `### Per-Requirement
-  Traceability`, or any `###` heading inside the Testing body. Use bold labels
-  (`**Acceptance Criteria Verification**`) or tables instead.
+> **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
+> (`sectionIsBare` guard, `task-service.ts`) — a standalone compatibility fallback, never an
+> overwrite of authored Review. Writing `## Review` here destroys the review step's
+> three-dimensional findings.
 
 ### Step 11 — State the verdict and hand off (the gate contract)
 
@@ -311,10 +310,8 @@ canonical.
 `.spur/run/<wbs>-verify-answer.txt`. A deterministic shell step then derives
 `.spur/run/<wbs>-verdict.json` from it plus an independent `spur task check` (R9; the agent
 reporting PASS in prose is necessary but not sufficient — the artifact is never left to the agent's
-discretion). The **record** step transcribes only `## Testing` from the verdict — verdict + per-
-requirement/AC tables + evidence. `## Review` is owned by the review step (`/sp:dev-review`) and
-the record step's `sectionIsBare` guard (`task-service.ts:485`) preserves any non-bare Review
-content. Verify mode never writes `## Review`.
+discretion). Section transcription follows the Step 10 contract (record → `## Testing`; bare-only
+Review fallback; verify never writes sections).
 
 **Standalone** (`/sp:dev-verify` outside the pipeline — no answer-file capture exists), write the
 artifact yourself; shape and field-by-field contract in
@@ -455,8 +452,8 @@ re-audit is never misread as a successful `testing -> done` (dev-verify.md `--ne
 ## Mode: review (`/sp:dev-review`)
 
 The source-oriented path: SECUA review of a task's diff without the full traceability verdict. Runs
-Steps 3 + 7 + 10 (Review section only) — no verdict artifact, no `done` gate. Use for a focused
-quality/security audit of changes when the full verify isn't wanted.
+Steps 3 + 7 and returns a **review fragment** — no verdict artifact, no section write, no `done`
+gate (F92 0593 R1); the coordinator (`sp:super-reviewer`) merges fragments into `## Review`.
 
 Flags: `--agent <inline|auto|name>` (execution surface — inline default, with named escalation triggers taking precedence), `--auto` (no confirmations), `--fix <none|blockers-first|all>` (post-review repair), and `--focus <all|security|efficiency|correctness|usability|architecture>` (SECUA dimensions). Apply the [central contract](../spur-dev/references/cross-cutting.md#inline-default-execution-surface) before starting the review.
 

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

@@ -139,3 +139,50 @@ completion without an explicit PASS artifact.
 - **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.
+
+## Optional check severity (task 0592, feature F92)
+
+`checks[]` rows may carry an optional `severity` field so the aggregation policy can distinguish a
+blocking review finding from a non-blocking one:
+
+```typescript
+checks: Array<{
+  name: string;                                // aliases accepted on read: `check`, `id`
+  status: 'pass' | 'fail' | 'warn';
+  evidence: string;
+  severity?: 'blocker' | 'major' | 'minor' | 'advisory';
+}>;
+```
+
+### Compatibility aliases: check label key
+
+Producers SHOULD write the check label as `name`. Consumers ALSO accept `check` and `id` as
+aliases, normalized to `name` in the same single place the `scenario`→`id` coverage alias is
+normalized (`checkSchema` in `verify-verdict.ts`). A row carrying none of the three is
+**structurally invalid** — an unnamed check cannot be matched by the aggregation policy's
+`task-check` detection, so it would silently exempt a failed task-check from the completion rule.
+
+The alias resolves for raw rows as well as parsed ones (`checkRowName`), because
+`aggregateVerifyVerdict` and the done guard's task-check lookup both run over unparsed artifacts.
+Precedence is `name` → `check` → `id`, first non-empty string wins.
+
+## Canonical runtime contract + one aggregation policy (task 0592)
+
+The prose shape above is executed by a single runtime-validated contract:
+`packages/app/src/services/verify-verdict.ts`. It owns:
+
+- **`verifyVerdictSchema`** (Zod) — validates the persisted artifact and distinguishes
+  **missing** (file absent / empty), **malformed** (bad JSON), **structurally invalid**
+  (`invalid` outcome), and **valid** (with case-normalized `verdict`). The `scenario`→`id` coverage
+  alias and the `check`/`id`→`name` check-label alias are both normalized here, in exactly one place.
+- **`aggregateVerifyVerdict`** — the ONE aggregation policy every verdict consumer uses (answer
+  derivation, persisted-artifact consistency checks, task/feature validation, record rendering,
+  and the done-transition gate). Requirements/AC use `MET`/`PARTIAL`/`UNMET`/`N/A`. Checks:
+  non-pass **blocker** → FAIL, non-pass **major** → PARTIAL, **minor**/**advisory** do not block;
+  legacy rows without a severity map `fail` → FAIL and `warn` → PARTIAL. An independent task-check
+  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.
+- `--force-done --reason` on `spur task update <wbs> done` remains the sole auditable override.

package/plugins/sp/skills/functional-review/SKILL.md

@@ -241,16 +241,16 @@ all core requirements MET                          → PASS
 `PARTIAL` blocks the gate exactly like `FAIL` — the distinction only tells the operator *how far
 off* delivery is.
 
-### Step 7 — Write findings to the task
+### Step 7 — Return the review fragment (no section write)
 
-Write the review body to the task's `## Review` section via CLI verbs. The body MUST lead with a
-`| Priority | Dimension | Location | Finding |` table (the L3 `hasPopulatedPriorityTable` gate at
+Assemble the findings into a **review fragment** — the priority-table lead + the per-requirement
+traceability table. The fragment MUST lead with a `| Priority | Dimension | Location | Finding |`
+table (the L3 `hasPopulatedPriorityTable` gate at
 `task-check.ts:96-106` requires at least one `P[1-4]` row with non-placeholder siblings — any other
 shape, e.g. `| Req | Status | Evidence |` alone, is structurally rejected and denies the
 `wip→testing` transition). Use the same canonical shape as `sp:code-verification`:
 
-```bash
-cat > /tmp/<wbs>-functional.md <<'BODY'
+```markdown
 | Priority | Dimension | Location | Finding |
 | --- | --- | --- | --- |
 | P4 | — | — | No P1–P3 findings; functional verdict PASS |
@@ -260,16 +260,17 @@ cat > /tmp/<wbs>-functional.md <<'BODY'
 | R1  | MET     | `src/api/users.ts:42` — `createUser()` |
 | R2  | PARTIAL | `src/api/users.ts:42` — basic only; MISSING duplicate-email handling |
 | R3  | UNMET   | no implementation found; searched src/api/, src/services/ |
-BODY
-spur task update <wbs> --section Review --from-file /tmp/<wbs>-functional.md
-rm /tmp/<wbs>-functional.md
 ```
 
 For a PARTIAL/FAIL verdict, replace the P4 row with the actual P1–P3 findings ranked by severity.
 The priority table leads; the traceability table follows for per-requirement detail.
 
-Section bodies passed to `spur task update --section` must be **body-only** — no same-level (`##`)
-headings inside the body. Tables and bold labels are fine.
+**Fragment-only discipline (F92 0593 R1).** In coordinated mode (dispatched by `/sp:dev-review` /
+`sp:super-reviewer`), do **not** write `## Review` — return the fragment to the coordinator, which
+merges the functional + SECUA + architecture fragments into the combined `## Review` section. Only
+`sp:super-reviewer` (the review coordinator) writes `## Review`; direct component-skill use is
+advisory output. `spur task record` backfills a **bare** `## Review` from the verdict artifact as a
+standalone compatibility fallback only and never overwrites authored Review (F92 0593 R1).
 
 ### Step 8 — Report
 
@@ -289,11 +290,11 @@ Include the per-requirement traceability table in the report:
 | R3  | UNMET  | no implementation found; searched src/api/, src/services/ |
 ```
 
-**Under the pipeline**, `sp:functional-review` is the review step dispatched by `/sp:dev-review`,
-so it owns `## Review` — its `--section Review` write is the authoritative source. The pipeline's
-`record` step transcribes only `## Testing` from the verify verdict (`code-verification/SKILL.md`,
-`task-record.ts:226-247`); it does not overwrite a non-bare `## Review` thanks to the
-`sectionIsBare` guard (`task-service.ts:485`). Keep the priority-table lead stable so the L3 gate
+**Under the pipeline**, `sp:functional-review` is a component of `/sp:dev-review`: it returns its
+fragment to the coordinator (`sp:super-reviewer`), which writes the combined `## Review`. The
+`record` step transcribes only `## Testing` from the verdict artifact and backfills `## Review`
+only when the section is bare (`sectionIsBare` guard, `task-service.ts`); it never overwrites the
+coordinator's authored Review. Keep the priority-table lead stable in the fragment so the L3 gate
 stays satisfied through `record` → `done`.
 
 ---

package/plugins/sp/skills/pr-reviewing/SKILL.md

@@ -135,9 +135,12 @@ bun "$(superskill script path sp pr-reviewing.ts)" <subcommand> [flags]
 Installed targets resolve the staged TypeScript source and execute it with Bun, matching the rest
 of `plugins/sp/scripts`.
 
-1. **Preflight** — `<script> preflight --json`. Hard-fails on a
-   detached HEAD, missing `gh` auth, no GitHub remote, or a dirty tree. On a dirty tree, triage
-   with the user (commit/stash/exclude) before continuing — the workflow refuses to guess.
+1. **Preflight** — `<script> preflight --base "$base" --json`. Hard-fails on a
+   detached HEAD, missing `gh` auth, no GitHub remote, a dirty tree, or the current branch
+   being the base branch (a PR reviews a feature branch against the base; nothing on the
+   base branch is reviewable, and the guard runs before any push can publish it). On a
+   dirty tree, triage with the user (commit/stash/exclude) before continuing — the
+   workflow refuses to guess.
 2. **Hygiene** — `<script> hygiene --base "$base" --json`. `BLOCK` (secrets, `.env`, conflict markers,
    private keys) stops the run — never submit a tainted diff. `WARN` (debug residue) rides along
    into the report. This is a submission sanity check, not a second local review.

package/plugins/sp/skills/spec-decomposition/references/decomposition.md

@@ -147,8 +147,9 @@ blank Design before implement (`/sp:dev-refine` / `dev-refineall`).
 The `template` field is the **single variant axis** (TASK_VARIANTS): it selects the section
 layout (the `section-matrix.yaml` variant), the scaffold body file
 (`.spur/templates/task/<variant>.md`), and is written to the task's `template:` frontmatter.
-Which sections actually appear is **stage-driven** by the matrix (e.g. `Solution` only from `wip`),
-not a fixed list — pick the variant by *purpose*, not by a section checklist.
+Which sections actually appear is **status-driven** by the runtime matrix — query
+`spur task sections <wbs> list --json` rather than assuming a fixed list — pick the variant by
+*purpose*, not by a section checklist.
 
 | Variant | When to use |
 |---------|-------------|
@@ -464,18 +465,16 @@ with research/design/implement/integrate/test as `## Plan` steps.
 
 A task created with a spec (a `--feature` link, or a batch item carrying `background`/
 `requirements`) lands at **`todo`** — "ready to execute" (§2.3). A bare capture lands at
-**`backlog`** — "still preparing". The Section-Status-Matrix
-(`.spur/tasks/section-matrix.yaml`) decides which sections a task carries at each stage; the
-producer renders them with invisible HTML guidance comments. You do **not** hand-build the section
-list — `spur task create` / `batch-create` does it from the matrix.
-
-| Stage | Means | Sections present |
-|-------|-------|------------------|
-| `backlog` | still preparing | Background |
-| `todo` | ready to execute — the **HITL review gate** | Background, Acceptance Criteria, Design, Plan (+ Q&A/Requirements optional) |
-| `wip` | implementing | + Solution (the change-map starts here) |
-| `testing` | verifying | Solution, Testing |
-| `done` | shipped | Solution, Testing, Review (gated) |
+**`backlog`** — "still preparing". The runtime section matrix decides which sections a task
+carries at each status; the producer renders them with invisible HTML guidance comments. You do
+**not** hand-build the section list — `spur task create` / `batch-create` does it from the matrix.
+
+**Query the runtime contract — never restate a status-to-section table (F92 0593 R2).**
+`spur task sections <wbs> list --json` returns the matrix required/optional/forbidden sections
+per status; `spur task check <wbs> --json` returns what the gate requires at the current status.
+Both replace any static "sections present at stage X" projection. The section *content* guidance
+below (Design = the decision record, Solution = the change-map) is prose ownership, not a
+section-layout authority.
 
 **Design (written at `todo`, for HITL review) = the decision record — WHAT/WHY:**
 the chosen approach + a one-line reason, rejected alternatives, key interface/type **signatures**

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

@@ -8,7 +8,10 @@ see_also:
 
 # Task L3 guard cheat sheet
 
-Read this before writing `Solution`, `Testing`, or `Review`. The owning implementations are
+Read this before writing `Solution`, `Testing`, or `Review`. Section **writers** are one per
+evidence section (F92 0593 R1): implement owns `Solution`, the review coordinator
+(`/sp:dev-review`) owns `Review`, and `spur task record` owns `Testing` (bare-`## Review`
+backfill is fallback-only). The owning implementations are
 `.spur/workflows/task-lifecycle.yaml`, `hasPopulatedPriorityTable()` in
 `packages/app/src/services/task-check.ts`, the verdict normalizers in
 `packages/app/src/services/task-record.ts`, and `TASK_CANONICAL_SECTIONS` in
@@ -25,8 +28,9 @@ done → wip
 backlog|todo|wip|testing|blocked → cancelled
 ```
 
-- `wip → testing` runs `spur task check <wbs>`.
-- `testing → done` runs `spur task check <wbs> --strict-core`, followed by the PASS-verdict gate.
+- `wip → testing` runs `spur task check <wbs> --as testing` (F92 R3 — target-aware).
+- `testing → done` runs `spur task check <wbs> --as done` (evaluates the `done` row incl. `gate:true`),
+  followed by the PASS-verdict gate. `--strict-core` remains as a compatibility alias only.
 - Invalid: `todo → testing`, `todo → done`, and `wip → done`.
 - Normal path: `backlog → todo → wip → testing → done`.
 

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.