@gobing-ai/spur 0.3.51 → 0.3.52

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
     },
     "plugins": [
         {
-            "version": "0.3.51",
+            "version": "0.3.52",
             "name": "sp",
             "source": "./plugins/sp",
             "description": "Spur - my harness toolkits"

package/config/tasks/section-matrix.yaml

@@ -1,12 +1,17 @@
 # Section-Status-Matrix: which sections are required/optional/forbidden per task status.
-# Design §3.2 — evaluated CLI-side only. Ships permissive; tightened by compliance data.
+# Design §3.2 — the SOLE semantic authority for task section layout (F92 R1):
+#   * VALIDATION (`spur task check`, incl. target-aware `--as <status>` lifecycle guard)
+#   * CREATION (`spur task create` / `spur task batch-create` -> `buildTaskSkeleton`)
+# There is NO hand-maintained creation or matrix fallback — packaged/compiled
+# execution loads data copied/generated from THIS canonical file and fails loudly
+# if no asset is reachable. Template files supply section BODY content + guidance
+# only; they never own the heading list (which comes from this matrix).
 #
 # Each VARIANT (the unified template axis — TASK_VARIANTS) maps status →
 # { required, optional, forbidden } section lists. Sections reference the canonical
 # section vocabulary (§2.1). `gate: true` on a status makes L2 violations hard errors.
 #
 # The variant is selected by a task's `template:` frontmatter (default: `standard`).
-# It drives BOTH validation (`spur task check`) AND creation (`buildTaskSkeleton`).
 $schema: "@gobing-ai/spur/schemas/section-matrix.schema.json"
 
 variants:

package/config/workflows/task-lifecycle.yaml

@@ -12,15 +12,16 @@ name: task-lifecycle
 description: >
   Task lifecycle FSM (design §2.3, §5.1). States are the canonical TaskStatus
   vocabulary (DD-01); transitions encode the §2.3 graph; guards invoke
-  `${vars.spurBin} task check` at the wip→testing and testing→done placements.
+  `${vars.spurBin} task check --as <target>` at the wip→testing and testing→done
+  placements (F92 R3): each guard evaluates the task AS the transition target so
+  testing→done checks the `done` row instead of the current `testing` row.
   `done` is re-enterable (reopen with a warning); `cancelled` is terminal.
-  Guard commands reference the check verb (0051) — structural validation passes
-  today, behavioral wiring activates as the verb ships. Unconditional transitions
+  Guard commands reference the check verb (0051). Unconditional transitions
   use the `always` guard (externally-driven via `requestTransition`, not
   auto-advance).
 
   Two-layer done gate (task 0292): this workflow's testing→done guard
-  (`spur task check --strict-core`) is the FIRST gate. The CLI verdict guard
+  (`spur task check --as done`, F92 R3 — target-aware) is the FIRST gate. The CLI verdict guard
   (`packages/app/src/services/done-transition-guard.ts`) is the SECOND gate,
   invoked by `apps/cli/src/commands/task.ts` for every `spur task update <wbs>
   done` call — it reads `.spur/run/<wbs>-verdict.json` and blocks non-PASS
@@ -69,14 +70,14 @@ transitions:
     guard:
       kind: shell
       options:
-        command: '$spurBin task check $wbs'
+        command: '$spurBin task check $wbs --as testing'
   - from: testing
     to: done
     description: Testing passed — task complete
     guard:
       kind: shell
       options:
-        command: '$spurBin task check $wbs --strict-core'
+        command: '$spurBin task check $wbs --as done'
 
   # Reopen: done → wip (warned, mandatory History entry)
   - from: done

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gobing-ai/spur",
-    "version": "0.3.51",
+    "version": "0.3.52",
     "description": "Spur CLI — local-first harness for mainstream coding agents: constraint checking, workflow orchestration, agent health, and history analytics. Bun-native; exposes the `spur` command.",
     "keywords": [
         "spur",

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

@@ -183,8 +183,9 @@ When you fan out or dispatch a subagent, apply the four disciplines the SSOT
 - [ ] Never replace yourself as orchestrator when `--agent` is set - it pins the step executor, not you.
 - [ ] Never auto-approve a HITL gate inside a task unless `--auto` was passed (it sets `profile=auto`).
 - [ ] Never silent-pick multi-candidate router stops; surface HITL (batch `--auto` does not break ties).
-- [ ] Never mutate the corpus - the pipeline's `record` step writes per-task `## Testing` / `## Review`
-      sections; your sole output is the batch report (+ optional recovery dispatch of an existing
+- [ ] Never mutate the corpus - the review coordinator writes `## Review`, the pipeline's `record`
+      step writes `## Testing` deterministically (bare-`## Review` fallback only — never an
+      overwrite of authored Review, F92 0593 R1); your sole output is the batch report (+ optional recovery dispatch of an existing
       `/sp:dev-*` command).
 - [ ] Never run tasks in parallel unless the operator requested parallel mode and the
       `sp:parallel-execution` checks pass. If checks fail, serialize and report why.

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

@@ -38,6 +38,11 @@ You are a **thin delegator**. You do not own the review logic; the three skills
 | SECUA quality | `sp:code-verification` (review mode) | Is the code correct/secure/efficient/usable? |
 | Architectural depth | `sp:code-improvement` | Is the architecture deep / testable? |
 
+**Section ownership (F92 0593 R1).** Component skills **return review fragments only** — never
+write `## Review`. This coordinator is the single `## Review` writer in coordinated/pipeline mode
+(combined fragment merge). `spur task record`'s bare-Review backfill is a standalone compatibility
+fallback only and never overwrites authored Review.
+
 Your job: establish scope, dispatch each requested dimension to its skill, collect findings, merge
 them into a ranked report, and write the report to the task's `## Review` section (pipeline mode) or
 emit it as advisory output (standalone mode).

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

@@ -27,6 +27,6 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 ## Implementation
 
 - Apply the [inline-default execution-surface contract](../skills/spur-dev/references/cross-cutting.md#inline-default-execution-surface).
-- WBS mode (`<wbs>`): `Skill(skill="sp:functional-review", args="<wbs> $ARGUMENTS")` + `Skill(skill="sp:code-verification", args="review $ARGUMENTS")` + `Skill(skill="sp:code-improvement", args="<wbs> $ARGUMENTS")` (functional traceability + SECUA framework + architectural depth; may write `Review` section to task)
+- WBS mode (`<wbs>`): `Skill(skill="sp:functional-review", args="<wbs> $ARGUMENTS")` + `Skill(skill="sp:code-verification", args="review $ARGUMENTS")` + `Skill(skill="sp:code-improvement", args="<wbs> $ARGUMENTS")` (functional traceability + SECUA framework + architectural depth; the three skills return review fragments and the coordinator (`sp:super-reviewer`) writes the combined `## Review` — F92 0593 R1)
 - Path mode (`<path>`): `Skill(skill="sp:code-verification", args="review $ARGUMENTS")` + `Skill(skill="sp:code-improvement", args="<path> $ARGUMENTS")` (advisory SECUA quality + architectural depth; performs no task mutation)
 - `--fix`: Deprecated (no-op + warning message; route remediation to `/sp:dev-verify --fix`). **`--next` removed** (feature H8, 2026-07-31) — it was a deprecated no-op; route progression to `/sp:dev-next`. **was: `--next` deprecated no-op.**

package/plugins/sp/plugin.json

@@ -1,6 +1,6 @@
 {
     "name": "sp",
-    "version": "0.3.51",
+    "version": "0.3.52",
     "description": "Spur — a local-first harness engineering toolkit that wraps mainstream coding agents with constraint checking, workflow orchestration, and history analytics.",
     "extensions": {
         "pi": ["./hooks/pi/guard-extension.ts"]

package/plugins/sp/scripts/pr-reviewing.ts

@@ -25,7 +25,7 @@ import { join } from 'node:path';
 
 // ─── Types ──────────────────────────────────────────────────────────────────
 
-interface CmdResult {
+export interface CmdResult {
     code: number;
     stdout: string;
     stderr: string;
@@ -110,10 +110,14 @@ interface ParsedArgs {
     booleans: Set<string>;
 }
 
-// ─── Process runner (git/gh resolved from PATH so tests can stub them) ──────
+// ─── Process runner (single seam; every git/gh call routes through run) ─────
 
-function run(cmd: readonly string[]): CmdResult {
-    // Pass env explicitly so both Node and Bun resolve git/gh against the test fixture PATH.
+/** How an external command is executed. The only seam between this script and git/gh. */
+export type CommandRunner = (cmd: readonly string[]) => CmdResult;
+
+/** Real execution: resolve the binary from PATH and capture its output. The default runner. */
+export const spawnRunner: CommandRunner = (cmd) => {
+    // Pass env explicitly so both Node and Bun resolve git/gh against the caller's PATH.
     const proc = spawnSync(cmd[0] ?? '', [...cmd.slice(1)], { encoding: 'utf8', env: process.env });
     return {
         code: proc.status ?? 1,
@@ -121,6 +125,20 @@ function run(cmd: readonly string[]): CmdResult {
         stderr: proc.stderr ?? '',
         error: proc.error?.message,
     };
+};
+
+let runner: CommandRunner = spawnRunner;
+
+/**
+ * Swap the git/gh runner. Tests inject an in-process stub so a suite of CLI cases costs no
+ * subprocess spawns; call with no argument to restore real execution.
+ */
+export function setCommandRunner(next?: CommandRunner): void {
+    runner = next ?? spawnRunner;
+}
+
+function run(cmd: readonly string[]): CmdResult {
+    return runner(cmd);
 }
 
 function runOk(cmd: readonly string[], what: string): string {

package/plugins/sp/scripts/stage-registry-adapter.ts

@@ -30,7 +30,7 @@ import { join } from 'node:path';
 // ─── Inline type definitions (mirrors packages/domain/src/stage-registry/) ─
 
 export type SchemaVersion = { major: number; minor: number };
-export const CURRENT_SCHEMA_VERSION: SchemaVersion = { major: 1, minor: 0 };
+export const CURRENT_SCHEMA_VERSION: SchemaVersion = { major: 1, minor: 3 };
 export const AUTHORITY_LANES = ['registry', 'workflow', 'skill', 'cli', 'adapter'] as const;
 export type AuthorityLane = (typeof AUTHORITY_LANES)[number];
 // Mirrors packages/domain/src/stage-registry/schema.ts MUTATION_CLASSES. Pinned by
@@ -65,6 +65,8 @@ export type ContextLayerName = (typeof CONTEXT_LAYER_NAMES)[number];
 export interface StageArtifact {
     kind: string;
     direction: ArtifactDirection;
+    /** Exact artifact identity (F92 0593 R2): task-section name or artifact file basename. */
+    identity?: string;
     description?: string;
     required?: boolean;
 }
@@ -308,10 +310,7 @@ export const REGISTERED_STAGES: StageRecord[] = [
         ],
         reasoning_skill: 'sp:spur-dev',
         required_references: ['references/dev-operations.md', 'spur-dev/references/decision-brief.md'],
-        gates: [
-            { name: 'refine-skip-gate', timing: 'pre', description: 'Skip sections that already meet L3' },
-            { name: 'l4-advisory', timing: 'post', min_verdict: 'pass', description: 'L4 advisory surface' },
-        ],
+        gates: [],
         mutation_class: 'corpus',
         retry: defaultRetry,
         model_policy: policy('refine', ['capable-2']),
@@ -346,7 +345,7 @@ export const REGISTERED_STAGES: StageRecord[] = [
         description: 'dev-run --mode implement: code edits in worktree',
         artifacts: [
             { kind: 'worktree-diff', direction: 'output', required: true },
-            { kind: 'task-section', direction: 'input', description: 'Solution section constraints' },
+            { kind: 'task-section', direction: 'output', required: true, identity: 'Solution' },
         ],
         reasoning_skill: 'sp:code-implementation',
         gates: [],
@@ -370,7 +369,7 @@ export const REGISTERED_STAGES: StageRecord[] = [
             { kind: 'coverage-report', direction: 'output', required: false },
         ],
         reasoning_skill: 'sp:code-testing',
-        gates: [{ name: 'coverage-floor', timing: 'post', min_verdict: 'pass', description: '≥90% function coverage' }],
+        gates: [],
         mutation_class: 'tests',
         retry: defaultRetry,
         model_policy: policy('test', ['capable-1']),
@@ -403,13 +402,13 @@ export const REGISTERED_STAGES: StageRecord[] = [
         id: 'verify',
         description: 'dev-verify: SECUA review + requirements traceability',
         artifacts: [
-            { kind: 'verdict-artifact', direction: 'output', required: true },
-            { kind: 'task-section', direction: 'output', description: 'Testing/Review sections' },
+            { kind: 'worktree-diff', direction: 'input', required: true },
+            { kind: 'verdict-artifact', direction: 'output', required: true, identity: '<wbs>-verdict.json' },
         ],
         reasoning_skill: 'sp:code-verification',
         gates: [
             { name: 'verdict-artifact', timing: 'post', min_verdict: 'pass' },
-            { name: 'strict-core', timing: 'post', description: 'L3 core findings must pass' },
+            { name: 'strict-core', timing: 'post', min_verdict: 'pass', description: 'L3 core findings must pass' },
         ],
         mutation_class: 'verdict',
         retry: { max_attempts: 2, terminal_stop: 'escalate', timeout_seconds: 600 },
@@ -423,10 +422,7 @@ export const REGISTERED_STAGES: StageRecord[] = [
         id: 'wrap',
         aliases: ['dev-wrap'],
         description: 'dev-wrap: learnings/doc-sync/feature transition',
-        artifacts: [
-            { kind: 'learning-entry', direction: 'output' },
-            { kind: 'task-section', direction: 'output', description: 'Testing/Review updated' },
-        ],
+        artifacts: [{ kind: 'learning-entry', direction: 'output' }],
         reasoning_skill: 'sp:spur-dev',
         gates: [
             {
@@ -447,9 +443,9 @@ export const REGISTERED_STAGES: StageRecord[] = [
         schema_version: CURRENT_SCHEMA_VERSION,
         id: 'review',
         description: 'dev-review: multi-dimensional code review (functional/SECUA/architecture)',
-        artifacts: [{ kind: 'review-findings', direction: 'output', required: true }],
+        artifacts: [{ kind: 'review-findings', direction: 'output', required: true, identity: 'Review' }],
         reasoning_skill: 'sp:code-verification',
-        gates: [{ name: 'review-guard', timing: 'post', min_verdict: 'pass', description: 'No P1 findings blocking' }],
+        gates: [],
         mutation_class: 'verdict',
         retry: { max_attempts: 2, terminal_stop: 'block', timeout_seconds: 300 },
         model_policy: policy('review', ['capable-1']),
@@ -457,6 +453,32 @@ export const REGISTERED_STAGES: StageRecord[] = [
         observability: [event('stage-started'), event('findings-produced')],
         execution: inlineInline(),
     },
+    {
+        schema_version: CURRENT_SCHEMA_VERSION,
+        id: 'record',
+        aliases: ['dev-record'],
+        description: 'record: deterministic Testing write-back from the verdict artifact; bare-Review fallback only',
+        artifacts: [
+            { kind: 'verdict-artifact', direction: 'input', required: true, identity: '<wbs>-verdict.json' },
+            { kind: 'task-section', direction: 'output', required: true, identity: 'Testing' },
+            {
+                kind: 'task-section',
+                direction: 'output',
+                required: false,
+                identity: 'Review',
+                description:
+                    'fallback-only: backfills Review only when the section is bare; never overwrites authored Review',
+            },
+        ],
+        reasoning_skill: 'inline',
+        gates: [],
+        mutation_class: 'corpus',
+        retry: { max_attempts: 1, terminal_stop: 'block', timeout_seconds: 120 },
+        model_policy: policy('record'),
+        context_layers: [layer('task-state')],
+        observability: [event('stage-started')],
+        execution: inlineDeterministic('cli'),
+    },
     {
         schema_version: CURRENT_SCHEMA_VERSION,
         id: 'dogfood',
@@ -467,15 +489,7 @@ export const REGISTERED_STAGES: StageRecord[] = [
         ],
         reasoning_skill: 'sp:dogfood-testing',
         required_references: ['references/monitor-ledger.md', 'references/report-template.md'],
-        gates: [
-            { name: 'detect-pipeline-driving', timing: 'pre', description: 'Refuse dogfood when driving a pipeline' },
-            {
-                name: 'report-validate',
-                timing: 'post',
-                min_verdict: 'pass',
-                description: 'Report must pass schema validation',
-            },
-        ],
+        gates: [],
         mutation_class: 'driver',
         retry: { max_attempts: 3, terminal_stop: 'block', timeout_seconds: 600 },
         model_policy: policy('dogfood'),
@@ -568,6 +582,7 @@ export function listStages(): StageLookupEntry[] {
         'quality-gate': '/sp:dev-fixall',
         verify: '/sp:dev-verify',
         wrap: '/sp:dev-wrap',
+        record: 'spur task record',
         review: '/sp:dev-review',
         dogfood: '/sp:dev-dogfood',
         handover: 'inline (dev-handover)',

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

@@ -187,9 +187,11 @@ 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
   `sp:code-verification`.
-- The candidate list is recorded in the task's `## Review` section (written by the pipeline's
-  `record` step via `spur task update --section`).
-- This skill does **not** write to the task file directly — the pipeline (or the operator) does.
+- The candidate list is returned as a **review fragment**; the review coordinator
+  (`sp:super-reviewer` under `/sp:dev-review`) merges it into the combined `## Review` section —
+  it is never written by `record`, which backfills `## Review` only when the section is bare
+  (fallback-only, F92 0593 R1).
+- This skill does **not** write to the task file directly — the coordinator (or the operator) does.
 
 Standalone, the skill emits the candidate list as advisory output; the operator acts on it.
 

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/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`.