@gobing-ai/spur 0.3.50 → 0.3.52

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.