@gobing-ai/spur 0.4.5 → 0.4.7

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

@@ -296,7 +296,7 @@ Include the per-requirement traceability table in the report:
 fragment to the coordinator (`sp:super-reviewer` — the invoking session under `/sp:dev-review`),
 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
+only when the section is bare (`sectionIsBare` guard, `task-section-bodies.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/spur-cli/references/tasks/verbs.md

@@ -377,8 +377,10 @@ rows), there is no checklist label: cite each row by its exact scenario title
 matches nothing and the verdict is rejected.
 
 **Evidence rule (behavior-bearing AC):** an AC row with `status: MET` on a behavior-bearing id
-(no `[advisory]`/`[non-core]`/`[non-behavior]`/`[docs-only]` marker) MUST carry `test` or
-`command` evidence; any other evidence type downgrades the row to `PARTIAL` and caps the verdict.
+(no `[advisory]`/`[non-core]`/`[non-behavior]`/`[docs-only]` marker **on the AC item in the task
+file**) MUST carry `test` or `command` evidence; any other evidence type downgrades the row to
+`PARTIAL` and caps the verdict. Tags written only in the answer are ignored and reported by the
+advisory `ac-exemption-not-in-task` check.
 
 **Worked example** — a minimal PASS-producing answer file:
 

package/plugins/sp/skills/spur-dev/references/ac-style-guide.md

@@ -219,7 +219,9 @@ clean at authoring time.
 ### Which tags exempt a row from executable evidence
 
 A `MET` row is silently demoted to `PARTIAL` unless it carries `test` or `command` evidence — the
-executable-evidence rule. Five tags opt a row out, because not every scenario is behavioral:
+executable-evidence rule. Five tags opt a row out, because not every scenario is behavioral. The
+tag counts only when the task author writes it on the AC item in the task file; `spur task verdict`
+ignores (and flags) a tag that appears only in the verify answer:
 
 `[doc-only]` · `[docs-only]` · `[non-behavior]` · `[advisory]` · `[non-core]`
 

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

@@ -590,9 +590,13 @@ host instructions does not add one. An opt-in gate is explicit: `gitmsg --check
      - `keepachangelog` (default): `## [<version>] - <date>` header, then category headings per the keepachangelog convention — `### Added` / `### Fixed` / `### Changed` / `### Removed` / `### Other` — mapped from conventional-commit types.
      - `simple`: flat bulleted list grouped by type heading (`### feat`, `### fix`, …).
   6. Emit: with `<file>`, insert the section into that file above its newest `## [` release heading (or after its title when none exists) and touch nothing else in the file; without `<file>`, print it to stdout.
-  7. Self-check before emitting: every short hash in `<since>..<until>` appears exactly once. Fix any miss or duplicate; do not report a verdict.
-  8. Reply in at most three lines: the range, bullet counts per category, and the output target.
-- **Invariants:** Output is derived from `git log` only. No quality gates — no `bun run gate`/lint/typecheck/test/`spur-check`/rule runs, citation or manifest lookups, confidence ratings, or edits beyond the one inserted section. The file is left uncommitted.
+  7. **Verify claims before emitting:** scan the generated bullets for API/library claims — bullets asserting what code, APIs, libraries, dependencies, or versions do (skip merge/bookkeeping bullets that assert no such fact). Verify each affected bullet, then append an HTML comment line directly under it: `<!-- src: <citation> · <HIGH|MEDIUM|LOW> -->`.
+     - Internal claims (what a commit or the code does): confirm against the commit diff (`git show --stat <hash>`, reading hunks when the summary asserts behavior) or the artifact's presence in the tree; cite `path[:line]` — bare path for whole-file claims, `path:line` for a specific behavior or symbol.
+     - External claims (framework/library/version behavior): confirm against official docs for the installed version; cite the URL. Unverifiable → LOW plus the reason in one clause.
+     - Confidence: HIGH = the diff/artifact confirms the summary as written; MEDIUM = the evidence is real but narrower than the summary; LOW = cannot be confirmed from available sources.
+  8. Self-check before emitting: every short hash in `<since>..<until>` appears exactly once, and every verified bullet carries exactly one `<!-- src: … -->` comment whose level is `HIGH`, `MEDIUM`, or `LOW` — no off-rubric levels, no unannotated claim bullets. Fix any miss, duplicate, or bad level; do not report a verdict.
+  9. Reply in at most three lines: the range, bullet counts per category plus verified-claim counts (`x HIGH / y MEDIUM / z LOW`), and the output target.
+- **Invariants:** Bullets are derived from `git log` only; the claim-verification pass (step 7) adds evidence from commit diffs, the working tree, and official docs. No quality gates — no `bun run gate`/lint/typecheck/test/`spur-check`/rule runs, and no edits beyond the one inserted section (its verification comments included). The file is left uncommitted.
 
 ### 9. gitmsg
 

package/plugins/sp/skills/spur-dev/references/done-housekeeping.md

@@ -139,8 +139,9 @@ silently incomplete (H6 shipped at 23/48 that way, with one verdict carrying an
    parses zero AC rows while lint still reports PASS.
 3. A behavioral AC marked `MET` with a non-executable evidence type (`static-ref`,
    `manual-review`, `llm-judge`) is **downgraded to PARTIAL** by `task verdict`, making the whole
-   verdict PARTIAL. Use `test`/`command` (grep-based verification counts as `command`), or tag the
-   AC id `[non-behavior]`/`[advisory]` when executable evidence genuinely doesn't apply.
+   verdict PARTIAL. Use `test`/`command` (grep-based verification counts as `command`). Only the
+   task author can exempt an AC, by tagging the AC item in the task file `[non-behavior]`/`[advisory]`;
+   the same tag added in the verify answer alone is ignored.
 
 **Invariant:** a force-done task has a non-empty `done_reason` naming the timeout, a verdict
 artifact whose AC rows cover every declared scenario, and a green lint/test run recorded in

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

@@ -625,7 +625,7 @@ Before launching a full `spur-check-new`:
 3. **Promoted code must satisfy the boundary rules `scripts/` never enforced.** A command module
    moving from `scripts/` into `apps/cli/src` must route output through the `CommandOutput` seam (no
    `console.*`), spawn processes via `NodeProcessExecutor` (no `Bun.spawnSync`), get a
-   `runtime-boundaries` fs-io exemption for sync reads (mirrors `task.ts`), and a non-command helper
+   `runtime-boundaries` fs-io exemption for sync reads (mirrors `commands/task/shared.ts`), and a non-command helper
    must not live in `apps/cli/src/commands/` (the noun scan treats every file there as a noun).
 4. **Doc/TSDoc edits shift `file:line` anchors** cited by other tasks — the per-task gate surfaces
    them as `L4.anchor-subject-mismatch` (0775: the corpus sweep retired; run `spur task check <wbs>`

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

@@ -202,7 +202,7 @@ install rule (source: task 0481) — create mode always installs because a fresh
 
 After creation or adoption, immediately write/adopt the state marker (WT-3), then run the
 existing batch loop (Steps 1–5) with the worktree as process cwd. `spur workflow run` resolves cwd
-from the process (`apps/cli/src/commands/workflow.ts:124`), so no CLI change is needed — `cd` into
+from the process (`apps/cli/src/commands/workflow/run.ts`), so no CLI change is needed — `cd` into
 the worktree directory before launching the loop.
 
 #### Evidence staging before the first task (create and reuse mode)

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

@@ -188,7 +188,7 @@ transition to `done`.
 > in-sandbox for the same reason.
 >
 > **Triage without a baseline run:** list the failing test *files*, then grep them for the surface
-> you changed. If your change touches `task.ts` and no failing file references task/lifecycle, the
+> you changed. If your change touches `commands/task/` and no failing file references task/lifecycle, the
 > failure is not yours. This costs seconds and mutates nothing — do **not** `git stash` to get a
 > clean baseline on a shared working tree. Treat any failure that does *not* name a port/listen/`ps`
 > cause as yours until proven otherwise; the count is a moving baseline, not a constant.