@gobing-ai/spur 0.4.3 → 0.4.5

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

@@ -79,7 +79,7 @@ each would be scope creep for one-liner procedures.
 | 6   | plan       | `dev-plan`          | `Skill()`         | inline driver (`idea-pipeline`) or async workflow                                  | `"<description>" [--feature <id>] [--parent <feature-id>] [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                   |
 | 7   | docs       | _(no thin wrapper)_ | `Skill()`         | `sp:doc-evolve`                                                                    | `"<change description>"`                                                                                                                                                                               |
 | 8   | changelog  | `dev-changelog`     | `inline`          | git log + conventional-commit grouping                                             | `[<file>] [--since <ref>] [--until <ref>] [--version <ver>]`                                                                                                                                            |
-| 9   | gitmsg     | `dev-gitmsg`        | `inline`          | bounded diff capture → concern grouping → conventional commit                      | `[--commit] [--squash] [--all] [--scope <path>]`                                                                                                                            |
+| 9   | gitmsg     | `dev-gitmsg`        | `inline`          | bounded diff capture → concern grouping → conventional commit                      | `[--commit] [--squash] [--all] [--scope <path>] [--check <cmd>]`                                                                                                           |
 | 10  | fixall     | `dev-fixall`        | `inline`          | lint + test fix loop                                                               | `[<validation-command>] [--max-retry <n>] [--scope <path>] [--gate-log <path>] [--findings <anchors>]`                                                                                                 |
 | 11  | handover   | `dev-handover`      | `inline`          | structured doc generation                                                          | `"<blocker description>"`                                                                                                                                                                              |
 | 11a | job-dump   | `dev-job-dump`      | `Skill()`         | `sp:spur-dev` (`job-dump`) | `--file <path>` |
@@ -250,7 +250,8 @@ check receipt (`receipt.runId === runId`), otherwise `n/a (<reason>)`. Any value
   checklist** against target sections (read codebases, ADRs, dependent WBS, dogfood evidence as
   needed). If any item fails, synthesize and rewrite via CLI-gated section updates until all pass
   (or surface a blocked Q&A with a concrete question). Outcome vocabulary: `refined` (wrote) |
-  `ready` (checklist already met, no write — optional alias of refined with zero writes) | `failed`.
+  `ready` (checklist already met, no write — optional alias of refined with zero writes) |
+  `cancelled` (issue triage found no valid issue — see `premises`) | `failed`.
   Prefer reporting `refined` when any section changed; if checklist already fully met, emit:
 
   ```
@@ -295,6 +296,17 @@ check receipt (`receipt.runId === runId`), otherwise `n/a (<reason>)`. Any value
        list`, `spur task list --status wip --json`) are recorded in References/Design.
      - **Scope** — the work is not already done, and not owned by another task.
 
+     **Issue triage.** When the task bundles several issues (findings, defects, R-items with their
+     proposed fixes), judge each one separately as `valid` (reproduced or confirmed in the current
+     tree), `already-fixed`, `owned-elsewhere` (name the WBS) or `invalid` (premise false). An issue
+     that is not `valid` is removed **with everything that exists only for it**: its Background
+     paragraph, R-items, Design/Solution notes, Plan steps and ACs. Renumber nothing that other
+     tasks or feature scenarios cite; leave a gap instead. Each removal is one correction-record
+     line. When **no** issue stays valid, do not rewrite the task. Record the triage in the
+     correction block, then `spur task update <wbs> cancelled --json`, and report outcome
+     `cancelled`. Cancelling is not demotion; it is valid only within the backlog/todo status scope
+     above.
+
      Contradictions are corrected in **this** refine (rewrite the claim, or re-point the design at
      ground truth), never deferred to the implementer. `--depth ready` exists so a downstream agent
      does not re-derive the analysis; a frozen design built on a false premise is the worst
@@ -309,7 +321,10 @@ check receipt (`receipt.runId === runId`), otherwise `n/a (<reason>)`. Any value
   1. Run `spur task check <wbs> --as todo --json`. Any error means the task is not ready. Fix it,
      or report `failed`.
   2. Fill metadata that is still unset: `spur task update <wbs> --priority <P0–P3>` and
-     `--estimate-hours <n>` (both `--json`). Never overwrite a value the operator set.
+     `--estimate-hours <n>` (both `--json`). Never overwrite a value the operator set. The one
+     exception is a triage that dropped issues: re-estimate the remaining scope and record
+     old → new in the correction block. The CLI cannot rename a task. When a drop leaves the title
+     naming removed scope, record that in the correction block as well.
   3. Promote `backlog → todo` idempotently with `spur task update <wbs> todo --json`, the same FSM
      transition `--next` uses. Create-time ready preparation skips its own promotion when the task
      is already `todo`, and next-router stops routing the task back to refine. Without `--next`,
@@ -341,9 +356,10 @@ check receipt (`receipt.runId === runId`), otherwise `n/a (<reason>)`. Any value
   3. Topo-sort by `dependencies[]` (Kahn, WBS-ascending tie-break). Cycle → abort entire batch before any refine. Out-of-set deps: `done` → allow; else → block subtree (same as runall).
   4. For each WBS in order: invoke single-task refine with shared flags **including `--depth`**. Under `--auto` + **`--depth standard`** (default), the per-task **L3 pre-synthesis SKIP gate** still applies. Under **`--depth ready`**, each task runs the implement-ready checklist (no L3-only SKIP). That includes the premises audit, the correction record and ready finalization, so a passing task leaves at `todo`.
   5. Failure policy: **stop-the-batch** (default) or `--keep-going` (skip in-batch dependents of a failed refine; continue independents).
-  6. Emit a batch report (markdown or `--json`) that records `depth` once at the header. Under `--depth ready`, each row also carries the corrections count, status before → after, and failed checklist ids.
-- **Per-task outcome vocabulary:** `refined` (synthesis wrote sections) | `SKIP` (already meets the active depth bar under `--auto`) | `failed` | `skipped` (dep failed under `--keep-going`) | `not-attempted` (halted) | `blocked` (unmet out-of-set dep).
-- **Batch verdict:** `clean` (all attempted tasks `refined` or `SKIP`) | `halted` (a failure stopped the batch) | `aborted` (cycle / unknown selector / empty set after filter).
+  6. Emit a batch report (markdown or `--json`) that records `depth` once at the header. Under `--depth ready`, each row also carries the corrections count, dropped issues, status before → after, and failed checklist ids.
+  7. **Cross-task proposals (`--depth ready` only).** After the per-task pass, list two kinds of proposals in the report: tasks whose remaining issues overlap another set member (same root cause or file set → name the merge target; tasks that only share a step, such as one upstream release, or that fix two layers of one failure → propose ordering or a shared step, not a merge), and tasks with no `feature_id` (name the candidate owning feature with evidence). These are proposals only. Refineall merges, cancels or links a task only when the operator's `--description` names that task and the action (e.g. `cancel 0273 and merge its issues into 0269; link 0260 to G11`). That explicit directive is the confirmation the [feature-link helper](feature-link-helper.md) requires. A merge moves the surviving issues with their fixes into the target through CLI section updates, records the merge in both tasks' correction blocks, then cancels the source. Run directives before the per-task pass, so each target is refined with its merged content.
+- **Per-task outcome vocabulary:** `refined` (synthesis wrote sections) | `SKIP` (already meets the active depth bar under `--auto`) | `cancelled` (no valid issue left, or merged away by directive) | `failed` | `skipped` (dep failed under `--keep-going`) | `not-attempted` (halted) | `blocked` (unmet out-of-set dep).
+- **Batch verdict:** `clean` (all attempted tasks `refined`, `SKIP` or `cancelled`) | `halted` (a failure stopped the batch) | `aborted` (cycle / unknown selector / empty set after filter).
 - **`--next` is not accepted** (dropped by feature H8, 2026-07-31 — see `plugins/sp/commands/dev-refineall.md` for the removal record). Chain execution explicitly: refineall, then `/sp:dev-runall --feature <id>`.
 - **`--auto` recommendation:** Batch refine without `--auto` requires per-task interactive Q&A and does not scale. Default operator path: `/sp:dev-refineall --feature <id> --auto`. For implement handoffs, or to re-audit a feature's filed tasks: `/sp:dev-refineall --feature <id> --auto --depth ready`.
 - **Delegation:** `Skill(skill="sp:spur-dev", args="refineall $ARGUMENTS")` → per task `Skill(skill="sp:spur-dev", args="refine <wbs> $SHARED_FLAGS")` (shared flags include `--depth` when set).
@@ -375,7 +391,7 @@ check receipt (`receipt.runId === runId`), otherwise `n/a (<reason>)`. Any value
 - **Behavior:**
   1. Parse arguments, preserving quoted paths with spaces. Reject a missing/empty path, repeated `--file`, unknown flags, or extra positional arguments with usage. Resolve the absolute path before changing directories. Reject a directory target; create missing parent directories. Respect CLI-gated corpus writes: task/feature documents cannot be dump targets.
   2. Gather the mission, original invocation/options, approved outcome, completed and partial work, blockers, and next actions. Verify repository/worktree paths, branch, HEAD/base, dirty files and relevant commits with Git. Inspect referenced tasks/features/runs through the CLI facade with `--json` in their execution directory. Preserve frozen batch membership, dependency order, run IDs, workflow/checkpoint identity, failure policy, executor state and worktree marker when applicable. Record inspection time and provenance; label unavailable facts `unknown`.
-  3. Fill every template section for this job; use `N/A` where inapplicable. Include uncommitted work and ownership, gate commands/results, pending questions, approvals given or still required, discovery maps, evidence paths, and wrap/merge/cleanup success conditions. Keep confirmed lessons and rejected approaches with anchors. Link authoritative specifications instead of copying them; never turn task-specific bypasses into general instructions.
+  3. Fill every template section for this job; use `N/A` where inapplicable. Include uncommitted work and ownership, gate commands/results already on record (never run a gate to fill this — write `not run`), pending questions, approvals given or still required, discovery maps, evidence paths, and wrap/merge/cleanup success conditions. Keep confirmed lessons and rejected approaches with anchors. Link authoritative specifications instead of copying them; never turn task-specific bypasses into general instructions.
   4. Redact credentials, tokens and sensitive personal data. Link large logs/artifacts by path and note their durability and availability to the recipient; the Markdown file does not transfer referenced files. Include essential continuation context directly so missing optional scratch notes do not erase the plan.
   5. Construct the complete snapshot before writing or refreshing `--file`. Read it back to verify the mission, execution directory, ordered remaining work and first actions. Report the absolute path and unresolved facts. Dumping only saves context: it does not stop an active executor, execute remaining work, change lifecycle state, commit, merge, or remove a worktree; record any executor still running.
 
@@ -552,6 +568,14 @@ gate commands, pending questions and approval requirements.>
 These define their procedure directly in the command file. No `Skill()` delegation — the command
 is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent reasoning.
 
+**Gate ownership.** A project quality gate (`bun run gate`, `spur-check`, lint, typecheck, tests,
+rule runs) runs only where an operation's own contract names it: the pipeline `test` hop
+(`run`/`runall`), `fixall`, `gtd`, `fixgha`, `unit`, and the `--check <cmd>` loops. The scribe
+operations — `changelog`, `gitmsg`, `handover`, `job-dump` — produce text or a commit, not code, so
+they run **no gate by default**, and a generic "verify before you finish" rule from `AGENTS.md` or
+host instructions does not add one. An opt-in gate is explicit: `gitmsg --check <cmd>`, or
+`/sp:dev-gtd [--no-push]` for gate → auto-fix → commit. Commit hooks still run as configured.
+
 ### 8. changelog
 
 - **Purpose:** Generate a structured changelog from git commits between two refs.
@@ -568,12 +592,12 @@ is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent
   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 lint/test/`spur-check`/rule runs, citation or manifest lookups, confidence ratings, or edits beyond the one inserted section. The file is left uncommitted.
+- **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.
 
 ### 9. gitmsg
 
 - **Purpose:** Generate conventional commit message(s) for the current change set — one gather call → concern grouping → one message per concern; optionally commit. Git + POSIX shell only; no helper script.
-- **Inputs:** `--scope <path>` (default: the whole change set) — path filter; an explicit `--scope` always wins over change-set auto-discovery. `--all` (default: off) — widen the change set past the index to every change in the tree: unstaged **and untracked** files. Omitted, the change set is the index only, which keeps pre-commit semantics stable. `--commit` (default: off) — commit the change set, one commit per concern. `--squash` (default: off) — collapse every concern into one message and one commit; implies `--commit`.
+- **Inputs:** `--scope <path>` (default: the whole change set) — path filter; an explicit `--scope` always wins over change-set auto-discovery. `--check <cmd>` (default: off) — run `<cmd>` once as a pre-commit gate (step 5a). `--all` (default: off) — widen the change set past the index to every change in the tree: unstaged **and untracked** files. Omitted, the change set is the index only, which keeps pre-commit semantics stable. `--commit` (default: off) — commit the change set, one commit per concern. `--squash` (default: off) — collapse every concern into one message and one commit; implies `--commit`.
 - **Backing:** `inline` — one bounded gather call + concern grouping + conventional commit formatting.
 - **Behavior:**
 
@@ -631,6 +655,8 @@ is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent
 
   5. **Report.** Print: one context line (branch; `linked worktree` when `--git-dir` ≠ `--git-common-dir` and the superproject line is empty), then each message in a fenced block. No per-file summaries, no restated diff. With neither `--commit` nor `--squash`, add one copy-paste `git commit` line per message and stop.
 
+  5a. **Gate (`--check <cmd>` only) — one more Bash call.** Without `--check`, run no gate of any kind. With it, run `<cmd>` exactly once, verbatim, after the report: exit 0 → one `check PASS` line and continue; non-zero → print its last 30 lines and commit nothing. Never fix, retry, or widen the command — gate → fix → commit is `/sp:dev-gtd`.
+
   6. **Commit (`--commit` / `--squash`) — one more Bash call.** `--squash` implies `--commit`, so both together is just `--squash`. Refuse before touching the index when:
      - `## secret hits` is non-empty → print each `file: line`, commit nothing;
      - `--commit` would split (more than one group) and `## partially staged` is non-empty → splitting would widen those `git add -p` stagings to whole files; print the paths and commit nothing (`--squash` is allowed — it commits the index as staged).
@@ -649,7 +675,7 @@ is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent
 
      Hooks stay enabled; a failing hook stops the run with its output — never `--no-verify`.
 
-- **Invariants:** Git and POSIX shell only — no helper script, no temp file. At most two Bash calls: gather, then (only when committing) commit. With neither `--commit` nor `--squash`, never runs `git commit` — message only. Neither flag commits across a secret hit, and `--commit` never splits across a partial staging. Without `--all` the change set is the index, so plain `/sp:dev-gitmsg` keeps pre-commit semantics; only `--all` reaches unstaged and untracked files, and only a committing run stages them. The empty-index widen is read-only and always announced — a committing run never widens its own scope. An explicit `--scope <path>` always bounds the change set, with or without `--all`. One bounded, context-free capture per run — never a second, wider read.
+- **Invariants:** Git and POSIX shell only — no helper script, no temp file. At most two Bash calls: gather, then (only when committing) commit — three with `--check`. No quality gate (`bun run gate`, lint, typecheck, tests, `spur-check`) unless `--check` names one. With neither `--commit` nor `--squash`, never runs `git commit` — message only. Neither flag commits across a secret hit, and `--commit` never splits across a partial staging. Without `--all` the change set is the index, so plain `/sp:dev-gitmsg` keeps pre-commit semantics; only `--all` reaches unstaged and untracked files, and only a committing run stages them. The empty-index widen is read-only and always announced — a committing run never widens its own scope. An explicit `--scope <path>` always bounds the change set, with or without `--all`. One bounded, context-free capture per run — never a second, wider read.
 
 ### 10. fixall
 
@@ -796,4 +822,4 @@ is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent
   `## Testing`, `## Review`), verdict files (`.spur/run/<wbs>-verdict.json`), diffs, and docs — by
   **path**, not by pasting their content into the handover body. The handover is a pointer document;
   restating content it can instead link to makes it stale the moment the source changes.
-- **Invariants:** The handover is honest — rejected approaches are recorded so the next agent doesn't retry them. The blocker is specific, not "it doesn't work."
+- **Invariants:** The handover is honest — rejected approaches are recorded so the next agent doesn't retry them. The blocker is specific, not "it doesn't work." No quality gate runs — cite gate results already on record.

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

@@ -152,8 +152,8 @@ kickoff** — the driver never re-queries `spur task list` to recompute membersh
 | --- | --- | --- |
 | Explicit WBS list | `^[0-9, ]+$` | Split on comma; validate each token is a 4-digit WBS; collect the explicit set. (R1.1) |
 | `feature:<id>` (via `--tasks` or `--feature <id>`) | literal `feature:` prefix or `--feature` flag | `spur task list --feature <id> --json`; collect `wbs` from each row. The `--feature` flag is sugar that becomes `--tasks feature:<id>` at the command layer. (R1.3) |
-| `ready` | literal `ready` | Resolve the union of `spur task list --status todo --json` + `spur task list --status backlog --json`, drop tasks with open children (R1.5, umbrella-parent exclusion below), then keep only tasks whose every `dependencies[]` entry resolves to `status == done` (via `spur task show <dep> --json | jq '{wbs, status, dependencies, feature_id}'` — R5 metadata-only). Report each excluded task with its unmet dependency. (R1.4) |
-| Status pseudo-list | `todo` \| `backlog` \| `wip` \| `blocked` \| `testing` | `spur task list --status <value> --json`; collect `wbs` from each row. (R1.2) |
+| `ready` | literal `ready` | Resolve the union of `spur task list --status todo --json` + `spur task list --status backlog --json`, drop tasks with open children (R1.5, umbrella-parent exclusion below), then keep only tasks whose every `dependencies[]` entry resolves to `status == done` (via `spur task show <dep> --json | jq '{wbs, status, dependencies, feature_id}'` — R5 metadata-only). Report each excluded task with its unmet dependency. A `deprecated` dependency is *not* satisfied (ADR-137: a frozen task never reads as `done`), so it keeps its dependents out of the ready set. (R1.4) |
+| Status pseudo-list | `todo` \| `backlog` \| `wip` \| `blocked` \| `testing` | `spur task list --status <value> --json`; collect `wbs` from each row. (R1.2) `deprecated` is deliberately not a selector value: a frozen task has no pipeline hop to drive, so a batch is never built from that status (ADR-137; `/sp:dev-next` row A10 stops the same way). |
 | *(else)* | no match | Error: "unknown selector `<value>`" — list the valid forms and halt before running anything. |
 
 **Dedup:** an explicit list with a repeated WBS (`--tasks 0040,0040`) collapses to a single entry;
@@ -200,7 +200,9 @@ For each dependency edge to a task **outside** the frozen set, resolve its curre
 - status ≠ `done` → mark the dependent **blocked**. Transitively mark its in-set descendants blocked
   too (fixpoint propagation: any task depending on a blocked task is itself blocked). Exclude all
   blocked tasks from execution and record the unmet dependency + the blocked subtree for the report
-  (R2.4). Independent (non-blocked) tasks in the set still run.
+  (R2.4). Independent (non-blocked) tasks in the set still run. **`deprecated` is not satisfied**
+  (ADR-137): a frozen task never reads as `done`, so the dependent blocks and the report names the
+  remedy — re-point the edge, or un-deprecate (`spur task update <dep> todo`).
 
 ### 2.4 Topological sort
 
@@ -277,6 +279,7 @@ node "$(superskill script path sp batch-preflight.mjs)" \
 | `action: skip` code **A2** | Do not launch; report `preflight-skip` + unmet deps (mirrors TABLE A2) |
 | `action: skip` code **A7** | Do not launch; report blocked (handover is operator-side) |
 | `action: skip` code **A8**/**A9** | Do not launch; already done / cancelled |
+| `action: skip` code **DEPRECATED** | Do not launch; frozen and retained (ADR-137) — the reason line names the un-deprecate command. A deprecated WBS can reach preflight through an explicit `--tasks` list or a `feature:<id>` selector (`spur task list --feature` reports every linked row, whatever its status); the `ready` and status pseudo-lists exclude it |
 
 **Invariants:** Preflight never replaces the pipeline with a loop of `/sp:dev-next`. TABLES A/B/C
 remain SSOT in `next-router/references/routing-table.md`. Step 2.3 already pre-blocks many unmet

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

@@ -171,17 +171,13 @@ Two branches reach the bounded repair hop, not one (session finding after 1088):
   an on-graph, bounded path to remediation instead of dead-ending the run, and the fix re-enters
   quality → review → verify on a freshly captured proof digest.
 
-The completion gate also reads the verifier's confidence (session finding after 1088): the verify
-answer's `Confidence: HIGH|MEDIUM|LOW` line reaches the verdict artifact, and both `verify → record`
-and `record → done` refuse a `LOW` (or absent) level unless the run was launched with
-`--vars '{"ackLowConfidence":"true"}'`. A PASS the verifier would not stand behind is an operator
-risk decision, so it takes an operator acknowledgement — not a silent certification.
-The CLI-layer done gate (`done-transition-guard`, task 1068 R3) separately requires the artifact to *state* a
-level at all: a PASS artifact whose `confidence` is missing is denied there too, and a present but
-out-of-vocabulary value fails the read closed (`invalid confidence field`), so a hand-driven
-`task update <wbs> done` — which is how this pipeline itself reaches `done` (`--no-lifecycle`) —
-cannot certify a verdict that carries no confidence. `LOW` is accepted at that gate; the
-acknowledgement rule above stays the pipeline's.
+The completion gate reads deterministic evidence only (F511, task 1207): both `verify → record` and
+`record → done` check the proof digests in `.spur/run/<wbs>-verdict.json` — verdict PASS, matching
+run/definition digests, review stage completed. No confidence is read, stated or acknowledged; the
+asserted `Confidence:` line and the `ackLowConfidence` operator var were retired because a model
+that can write a PASS can write `HIGH` — the grade verified nothing. What protects a hand-driven
+`task update <wbs> done` is unchanged: the digests must match the run's captured proof, and the
+review stage must actually be completed in the artifact.
 
 Agentic steps use the pure slash inputs declared by each YAML `agent.run` action (ADR-043). The
 workflow engine dispatches them; the interactive driver invokes their backing skills in-session.

package/plugins/sp/skills/spur-dev/references/flag-glossary.md

@@ -225,8 +225,10 @@ the `feature:<id>` sets, resolved once and frozen.
 
 **Anchor:** `#flag-check`.
 
-Verification command a command iterates against (`dev-simplify`, `dev-refactor`). The command
+Verification command a command iterates against (`dev-simplify`, `dev-refactor`, `dev-gitmsg`). The command
 establishes a baseline with it before the first change and re-runs it after each change.
+`dev-gitmsg` uses it as a one-shot opt-in pre-commit gate: run once, non-zero commits nothing, no
+fix loop. A command without `--check` in its contract runs no gate.
 
 ### `--focus <dims>` — constrain the operation to specific dimensions
 
@@ -462,7 +464,7 @@ Orthogonal to `--focus` (which _narrows_ domains) and to `--mode` on other comma
 | Value (refine family)             | Bar                                                                                                                                                                                | `--auto` SKIP behavior                                                                             |
 | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
 | `standard` (default when omitted) | L3 structural completeness (not empty/placeholder; check-clean for target sections)                                                                                                | **SKIP** when no L3 findings on target sections                                                    |
-| `ready`                           | **Implement-ready** freeze: another agent can implement without inventing design (frozen names/APIs or explicit "no new API", anti-patterns, file targets, handoffs, out-of-scope) | **Do not SKIP** on L3-clean alone — audit existing claims, run the ready checklist, rewrite sections until the bar is met, then promote `backlog → todo` |
+| `ready`                           | **Implement-ready** freeze: another agent can implement without inventing design (frozen names/APIs or explicit "no new API", anti-patterns, file targets, handoffs, out-of-scope) | **Do not SKIP** on L3-clean alone — audit existing claims, drop invalid issues with their fixes (cancel when none stays valid), run the ready checklist, rewrite sections until the bar is met, then promote `backlog → todo` |
 
 Default for refine stays `standard` so ordinary `refineall --auto` remains cheap. Use `ready` for
 multi-package / multi-agent handoffs, flaky-pipeline features where a wrong implement is costly, and

package/plugins/sp/skills/spur-dev/references/inline-pipeline-driver.md

@@ -844,9 +844,10 @@ leave no `.spur/run/<wbs>-check-receipt.json`. The deciding artifacts are then
 1. **Drive the pipeline** for anything that must be certified: only a digest-bound full receipt
    satisfies a review/verify/record boundary (`sp-spur-check`), and the `test` hop owns the capture.
 2. **When a host-driven pass is unavoidable, say so in the verdict** — name the status file and gate
-   log as the evidence and grade confidence `MEDIUM`. A `HIGH` claim needs re-runnable evidence from a
-   checked path (the `sp-code-verification` ladder); claiming a receipt that was never written is the
-   failure mode this note exists to prevent (observed across four A91 tasks, 2026-10-12).
+   log as the evidence, and mark the reliance explicitly in the evidence cell (a host-driven gate is
+   not re-runnable proof from a checked path; the `sp-code-verification` ladder is). Claiming a
+   receipt that was never written is the failure mode this note exists to prevent (observed across
+   four A91 tasks, 2026-10-12).
 
 **A mismatch names the drifted paths (R5).** At gate entry the pipeline snapshots the non-corpus tree
 state (`git status --porcelain=v1 -uall` plus `git diff --name-only HEAD`, excluding
@@ -922,8 +923,10 @@ verdict artifact exists (tasks 0617, 0619 — the clobbering spiral).
 
 ## Running the full gate (task 0872 / 1127 R7)
 
-The full gate legitimately runs 10-25 minutes. Two rules keep it from becoming a hazard (both
-violated once on 2026-10-10, aborting the run's own verification):
+The full gate legitimately runs minutes, not seconds — measured 1.8-3.1 min for `bun run spur-check`
+on an idle 10-core host (2026-10-13), and far longer when other agents' suites run concurrently.
+Five rules keep it from becoming a hazard (the first two
+were both violated once on 2026-10-10, aborting the run's own verification):
 
 - **Never wrap it in an external `timeout`, and never treat its runtime as a hang.** An outer bound
   that fires mid-suite leaves a half-finished suite behind while the caller believes it is gone.
@@ -936,6 +939,24 @@ violated once on 2026-10-10, aborting the run's own verification):
 - **Preserve a signal-induced receipt.** A cap-killed attempt leaves a red receipt that the next
   recheck's `no-progress` guard honours, so it reads as a genuine failure unless the receipt is kept
   under a distinct name and the run log says so.
+- **Clear the killed attempt's process tree before re-running.** A cap-signalled gate leaves its
+  `bun test --test-worker` children alive: the parent dies, the workers keep burning ~100% CPU, and
+  each retry is slower than the last until the cap kills that one too and mints another leak.
+  Observed 2026-10-13: five leaked workers (ages 23 min, 37 min, 50 min, 2 h 17 m, 4 h 18 m) drove
+  consecutive attempts from the measured 1.8-3.1 min up to 13-40 min, and the real defect of the
+  session only became visible once they were cleared. Find them by age and cwd, then clear the tree
+  before the next run; leave a tree alone whose cwd is another session's live run:
+
+  ```bash
+  ps -Ao pid=,ppid=,etime=,%cpu=,command= | grep -E "run-tests\.ts|bun test --test-worker" | grep -v grep
+  kill -TERM <pid> <ppid>; sleep 4; kill -KILL <pid> <ppid>    # escalate only if TERM is ignored
+  ```
+
+- **One gate per tree.** Nothing serializes gate runs since task 1173 deleted the lock, so confirm
+  no live gate is already running in your tree before starting one: two suites in one tree contend
+  for CPU and for the shared fixtures, and the second one's result is uninterpretable. Measured
+  2026-10-13: a duplicate gate launched into a tree already running another session's
+  `bun run spur-check` burned 40 min at the host cap and left an orphaned worker behind.
 
 > Historical (task 1127, removed in task 1173): these rules were once stated in terms of a host-wide
 > `full-gate.lock`. The lock mechanism was deleted (`refactor(gate): remove gate-lock mechanism and
@@ -957,14 +978,14 @@ Each item below cost a driver cycle to discover. They are contracts, not tips.
   `.spur/run/<wbs>-diffstat.json` and never on command output. Never the bare unguarded
   source-repo path form — the script-contract check forbids it on a shipped surface because it
   shadows the installed twin in a consumer.
-- **The verify answer grammar is exact.** One `Verdict:` line, one `Confidence:` line, then
+- **The verify answer grammar is exact.** One `Verdict:` line, then
   `### Per-Requirement Traceability` (`| Req | Status | Evidence |`) and
   `### Acceptance Criteria Verification` (`| AC | Status | Evidence Type | Evidence |`). Requirement
   statuses are `MET | PARTIAL | UNMET`; AC statuses add `N/A`; every AC row id must match a declared
   scenario title verbatim, including its `(req: ...)` suffix. A `MET` row whose evidence hedges
   (`likely`, `probably`, `seems`, `appears`, `possibly`, `presumably`) is rejected as
-  `evidence-hedged`, and a level the rows do not earn is rejected as `confidence-unwarranted` or
-  `confidence-understated`. `spur task verdict` lints before writing, so a rejected answer leaves no
+  `evidence-hedged`. No `Confidence:` line exists (F511, task 1207) — legacy answers that carry one
+  parse with the value ignored. `spur task verdict` lints before writing, so a rejected answer leaves no
   artifact and exits non-zero.
 - **Harness tooling refuses direct task-file writes.** Resolve a merge conflict in a task file by
   choosing a git side, then applying the corpus delta through `spur task update` (for example

package/schemas/section-matrix.schema.json

@@ -53,7 +53,7 @@
         "variant": {
             "type": "object",
             "additionalProperties": false,
-            "description": "A variant may declare any subset of the 7 canonical statuses (enumerated below); an unknown status key is rejected.",
+            "description": "A variant may declare any subset of the 8 canonical statuses (enumerated below); an unknown status key is rejected.",
             "properties": {
                 "backlog": { "$ref": "#/$defs/entry" },
                 "todo": { "$ref": "#/$defs/entry" },
@@ -61,7 +61,8 @@
                 "testing": { "$ref": "#/$defs/entry" },
                 "blocked": { "$ref": "#/$defs/entry" },
                 "done": { "$ref": "#/$defs/entry" },
-                "cancelled": { "$ref": "#/$defs/entry" }
+                "cancelled": { "$ref": "#/$defs/entry" },
+                "deprecated": { "$ref": "#/$defs/entry" }
             }
         }
     }