@gobing-ai/spur 0.4.31 → 0.4.34

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

@@ -2,7 +2,7 @@
 description: Run a task — full pipeline (precheck→implement→test→review→approve→verify→record→done) or single-step (implement)
 requires: [cli:spur, local-fs]
 role: coder
-argument-hint: "<wbs> [--mode <full|implement>] [--agent <inline|auto|name>] [--auto] [--next] [--wrap] [--continue] [--worktree [<name>]] [--no-summary]"
+argument-hint: "<wbs> [--mode <full|implement>] [--agent <inline|auto|name>] [--auto] [--next] [--wrap] [--wrap-pr] [--continue] [--worktree [<name>]] [--no-summary]"
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill"]
 ---
 
@@ -19,7 +19,8 @@ Wraps the **sp:spur-dev** and **sp:code-implementation** skills.
 | `--agent` `<inline\|auto\|name>` | Who runs the model-bearing stages. omit and explicit `--agent inline` resolve identically (task 0687): eligible stages dispatch once to a native subagent with host-session fallback (0508 eligibility); otherwise every stage executes in the invoking session. `auto` or a name keeps subprocess dispatch.. The opt-in `fleet` selector (0942) maps the run to `executor: 'fleet'` so `agent.run` stages dispatch through the fleet control plane (ADR-126) instead of a subprocess. | omit |
 | `--auto` | Skip objective HITL confirmations. | off |
 | `--next` | Chain-to-completion via the next-router. | off |
-| `--wrap` | Run the wrap hop after the main step. The `--agent` selector is preserved into the `/sp:dev-wrap <wbs>` handoff when supplied; omission remains omission. The wrap hop is workflow-backed and reports its trigger-3 subprocess override. | off |
+| `--wrap` | Run the wrap hop after the main step. The `--agent` selector is preserved into the `/sp:dev-wrap <wbs>` handoff when supplied; omission remains omission. The wrap hop is workflow-backed and reports its trigger-3 subprocess override. Mutually exclusive with `--wrap-pr`. | off |
+| `--wrap-pr` | Run the wrap hop after the main step, commit close-out writes, push the worktree branch to remote origin, and open a Pull Request targeting the base ref (WT-PR). Mutually exclusive with `--wrap`. Full mode only; requires `--worktree` or a dedicated non-base branch. | off |
 | `--continue` | Resume an interrupted task from its checkpoint. | off |
 | `--worktree` `[<name>]` | Run the task pipeline in an isolated git worktree; FF-merge on success, retain on failure. Bare `--worktree` creates a fresh tree; `--worktree <name>` adopts an existing worktree by name/path/branch. Full mode only. | off |
 | `--no-summary` | Skip the measured execution summary (per-stage time, wait, tool calls, total / non-cached tokens) printed after a full-mode run. | off (summary printed) |
@@ -28,7 +29,7 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 
 ## Usage
 
-/sp:dev-run <wbs> [--mode <full|implement>] [--agent <inline|auto|name>] [--auto] [--next] [--wrap] [--continue] [--worktree [<name>]] [--no-summary]
+/sp:dev-run <wbs> [--mode <full|implement>] [--agent <inline|auto|name>] [--auto] [--next] [--wrap] [--wrap-pr] [--continue] [--worktree [<name>]] [--no-summary]
 
 ## Implementation
 
@@ -64,6 +65,10 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
   `.spur/run/<wbs>-question.md` and exits 0 — the pipeline's `escalate` hop surfaces the question,
   the operator answers via `spur workflow continue --answer-text`, and the guard appends the Q/A
   pair to this transcript before re-entering implement, where the agent reads it and resumes.
+- `--wrap-pr` (run wrap hop, push branch, and create PR) — runs the wrap hop on `$BRANCH`, commits close-out
+  writes, pushes the branch to `origin`, and opens a Pull Request targeting `$BASE_REF`
+  (`WT-PR`, execution-worktree-landing.md). Mutually exclusive with `--wrap`: passing both exits 2. Full mode only;
+  requires `--worktree` or execution on a dedicated non-base branch (refuses execution directly on `main`).
 
 `--worktree` `[<name>]` (run the task's pipeline in an isolated git worktree — FF-merge onto the
 base ref on full success, retain intact on any failure/halt/non-FF; bare form creates a fresh tree,

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

@@ -2,7 +2,7 @@
 description: Run a batch of tasks through their pipelines in dependency-correct order — resolve a set, topo-sort, run each via task-pipeline.yaml, emit a batch report
 requires: [cli:spur, local-fs]
 role: planner
-argument-hint: "--tasks <selector> [--feature <id>] [--mode <sequential|parallel|auto>] [--concurrency <n>] [--keep-going] [--auto] [--agent <inline|auto|name>] [--json] [--wrap] [--next] [--continue] [--worktree [<name>]] [--no-summary] [--defer-gate]"
+argument-hint: "--tasks <selector> [--feature <id>] [--mode <sequential|parallel|auto>] [--concurrency <n>] [--keep-going] [--auto] [--agent <inline|auto|name>] [--json] [--wrap] [--wrap-pr] [--next] [--continue] [--worktree [<name>]] [--no-summary] [--defer-gate]"
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
 
@@ -21,7 +21,8 @@ Wraps the **sp:spur-dev** skill.
 | `--auto` | Skip objective HITL gates, and treat the batch as unattended: `--auto` implies `--keep-going` (a failed task is `failed`, its in-batch dependents `skipped`, independents keep running). | off |
 | `--agent` `<inline\|auto\|name>` | Who runs each task's pipeline stages. Interactive sequential omit/`inline` uses the host-session driver with unified inline semantics (task 0687 — see below). `auto`, a name, parallel mode, and headless invocation use subprocesses; `auto` is resolved **once per batch** — the first run's implement `result.executor` is pinned for every later task, and only a `failed-agent` ending re-resolves it, exactly once (1318 R2/R3). The opt-in `fleet` selector (0942) maps each task run to `executor: 'fleet'` so `agent.run` stages dispatch through the fleet control plane (ADR-126) instead of a subprocess. | omit |
 | `--json` | Emit structured JSON. | off |
-| `--wrap` | Run the wrap hop **once for the batch** over the `done` subset only (Step 6 of execution-batch.md): `vars.feature` is passed only when every frozen task is `done`/`cancelled`; an empty done subset skips the wrap with a reason. The `--agent` selector is preserved into the `/sp:dev-wrap` handoff when supplied; omission remains omission. | off |
+| `--wrap` | Run the wrap hop **once for the batch** over the `done` subset only (Step 6 of execution-batch.md): `vars.feature` is passed only when every frozen task is `done`/`cancelled`; an empty done subset skips the wrap with a reason. The `--agent` selector is preserved into the `/sp:dev-wrap` handoff when supplied; omission remains omission. Mutually exclusive with `--wrap-pr`. | off |
+| `--wrap-pr` | Run the wrap hop **once for the batch** over the `done` subset, commit close-out writes, push the worktree branch to remote origin, and open a Pull Request targeting the base ref (WT-PR). Mutually exclusive with `--wrap`. Requires `--worktree` or a dedicated non-base branch. | off |
 | `--next` | Chain-to-completion via the next-router. | off |
 | `--continue` | Resume an interrupted batch. | off |
 | `--worktree` `[<name>]` | Run the batch in an isolated git worktree; FF-merge on success, retain on failure. Bare `--worktree` creates a fresh tree; `--worktree <name>` adopts an existing worktree by name/path/branch. | off |
@@ -34,7 +35,7 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 ## Usage
 
 ```
-/sp:dev-runall --tasks <selector> [--feature <id>] [--mode <sequential|parallel|auto>] [--concurrency <n>] [--keep-going] [--auto] [--agent <inline|auto|name>] [--json] [--wrap] [--next] [--continue] [--worktree [<name>]] [--no-summary] [--defer-gate]
+/sp:dev-runall --tasks <selector> [--feature <id>] [--mode <sequential|parallel|auto>] [--concurrency <n>] [--keep-going] [--auto] [--agent <inline|auto|name>] [--json] [--wrap] [--wrap-pr] [--next] [--continue] [--worktree [<name>]] [--no-summary] [--defer-gate]
 ```
 
 Flags: `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`,
@@ -57,7 +58,9 @@ unattended, so it also implies `--keep-going`), `--agent <inline|auto|name>`
 `auto` or a name is merged into each per-task `vars.agent` and `vars.implementAgent`; `fleet` maps each task run to `executor: 'fleet'` instead (fleet dispatch, 0942); parallel mode
 retains isolated subprocesses, ADR-047), `--json` (emit the
 report as JSON), `--wrap` (trigger
-`wrapup-pipeline.yaml` after the batch completes), `--next`
+`wrapup-pipeline.yaml` after the batch completes; mutually exclusive with `--wrap-pr`), `--wrap-pr`
+(run batch wrap hop, commit close-out writes, push worktree branch to remote origin, and open a Pull Request
+targeting the base ref; mutually exclusive with `--wrap`), `--next`
 (chain each task to terminal status, then run the wrap hop **once for the batch** — see below),
 `--worktree` `[<name>]` (run the batch in an isolated git worktree —
 FF-merge onto the base ref on full success, retain intact on any failure/halt/non-FF; bare form

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

@@ -41,16 +41,6 @@ See `sp:code-verification` § Shippable readiness gate.
 
 - Apply the [inline-default execution-surface contract](../skills/spur-dev/references/cross-cutting.md#inline-default-execution-surface).
 - `Skill(skill="sp:code-verification", args="verify $ARGUMENTS")`
-- **Residual sweep (F96 R1, post-record since 0987):** after `task verdict` derives
-  `.spur/run/<wbs>-verdict.json` and `spur task record` has flipped the verdict-proven R/AC boxes,
-  run `spur task residual <wbs> scan` + `fold` (observe-only; folds the verdict's `residual-sweep` check,
-  PASS → PARTIAL when a blocking residual exists) — under every `--fix` mode — then, only on a
-  downgrade, re-run `spur task record <wbs> --verdict-file .spur/run/<wbs>-verdict.json` so Testing
-  carries the final verdict. Same order as the pipeline `done` state's record close (0983): scanning before
-  record reads unticked-but-proven boxes and folds a clean PASS to PARTIAL. When the task reaches
-  `done` through `--next`, run `spur task residual <wbs> settle` (best-effort). On a folded PARTIAL: the bounded remediation loop has
-  already run — a residual-failed task is routed to router C6 (HITL STOP), never another
-  automatic fix loop.
 
 **Flags:**
 

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

@@ -73,8 +73,3 @@ Without `--fix all`, shippable is not evaluated (optional note: use `--fix all`
 - Batch orchestration: `Skill(skill="sp:spur-dev", args="verifyall $ARGUMENTS")`
 - Per-task verification (inner): `Skill(skill="sp:code-verification", args="verify <wbs> $SHARED_FLAGS")`
 - Shippable gate: once after the batch (same skill § Shippable readiness gate)
-- **Residual sweep (F96 R1, per task, post-record since 0987):** same contract as
-  `/sp:dev-verify` — after each task's verdict artifact is derived and `spur task record` has
-  flipped its verdict-proven boxes, run `spur task residual <wbs> scan` + `fold` (under every
-  `--fix` mode), and re-record only on a downgrade; on reaching `done` via `--next`, run
-  `spur task residual <wbs> settle`.

package/plugins/sp/plugin.json

@@ -1,5 +1,5 @@
 {
     "name": "sp",
-    "version": "0.4.31",
+    "version": "0.4.34",
     "description": "Spur — a local-first harness engineering toolkit that wraps mainstream coding agents with constraint checking, workflow orchestration, and history analytics."
 }

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

@@ -84,9 +84,7 @@ not have and work you were not asked to do.
   prerequisite. If the target genuinely cannot proceed without it, stop and say so — a blocked task
   is a cheap finding; a two-task diff costs the reverts.
 - **Flip the target's `## Plan` boxes as each step completes.** They are this pass's progress
-  ledger, and the record-time residual sweep treats an *unchecked* Plan box as blocking: it
-  downgrades the verdict to PARTIAL and closes the `done` gate
-  (`docs/design/task-residual-sweep.md`), which costs a remediation cycle and a manual re-record.
+  ledger.
   Leave every finished step ticked through `spur task update <wbs> --section Plan --from-file`, and
   if you deliberately skipped one, say so in the Solution change map.
 

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

@@ -161,12 +161,10 @@ Evidence: @gobing-ai/ts-llm-jsonl-importer `src/mappers.ts` line 481 — omp cal
 ```
 
 Use this form ONLY when the evidence genuinely lives outside `spur`'s working tree (a `@gobing-ai/ts-*`
-source under `~/xprojects/ts-libs`, or a gitignored `.spur/run/**` artifact). `checkLineAnchors`
-classifies it as external and never raises `L4.stale-line-anchor` for it (R1). Do NOT use it for a file
-that lives in this repo — in-repo evidence MUST use the repo-relative backtick form
-`` `path:line` `` / `` `path:start-end` ``, and citing it in the external form still reports (R2).
+source under `~/xprojects/ts-libs`, or a gitignored `.spur/run/**` artifact). In-repo evidence uses the
+repo-relative backtick form `` `path:line` `` / `` `path:start-end` ``.
 
-**Concrete anchors (0804 R9):** existing `file:line`s only, never globs, always repo-root-relative — a basename is `L4.anchor-unresolved` at the `--as done` gate (`references/verdict-schema.md`).
+**Concrete anchors:** existing `file:line`s only, never globs or basenames, always repo-root-relative (`references/verdict-schema.md`).
 
 ### Step 5 — Acceptance Criteria guard
 
@@ -275,7 +273,7 @@ completion gate (`PARTIAL`/`FAIL` route the pipeline to `failed`).
 Assemble the evidence and **emit the canonical verdict artifact** — verification writes no task
 section (F92 0593 R1). Under the pipeline **you** write
 `.spur/run/<wbs>-verify-answer.txt` (0726 R3: host `expectFile`, never captured/overwritten); a
-deterministic shell step lints it and derives `.spur/run/<wbs>-verdict.json`, and `record`
+deterministic shell step derives `.spur/run/<wbs>-verdict.json`, and `record`
 transcribes `## Testing` from it.
 
 **Standalone** (`/sp:dev-verify` outside the pipeline), write the artifact yourself, then invoke
@@ -284,40 +282,14 @@ the deterministic Testing writer `spur task record` (section authorship never ha
 ```bash
 # 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, flips proven boxes
-# F96 residual sweep (observe-only): scan + fold AFTER record, under every --fix mode (0987).
-spur task residual <wbs> scan
-spur task residual <wbs> fold
-# Downgrade only: re-record so Testing carries the final (folded) verdict.
-[ "$(jq -r .verdict .spur/run/<wbs>-verdict.json)" = PASS ] \
-  || spur task record <wbs> --verdict-file .spur/run/<wbs>-verdict.json
 ```
 
-> **Residual fold (F96).** `scan` reads `.spur/run/` artifacts and the post-record task file and
-> writes `residuals.json` + `residual-report.md`; `fold` rewrites the verdict artifact's
-> `residual-sweep` check in place (PASS → PARTIAL when a blocking residual exists), and the
-> downgrade-only re-record transcribes it — a manual verify cannot certify what the pipeline would
-> reject. The sweep runs after `record` (same order as the pipeline, 0983/0987): before it, a
-> verdict-proven box is still unticked and a clean PASS would fold to PARTIAL. The sweep is the
-> `spur task residual` verb (no plugin script to resolve). When the task reaches `done` through
-> `--next`, run `spur task residual <wbs> settle` (files the follow-up task; best-effort).
-
 > **Corrections: the answer file is the source of truth.** `spur task record` re-transcribes
 > `## 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.
 
-> **Scenario-key carry-forward (standalone `--force` re-verifies).** When you author a fresh
-> verdict artifact for a task whose `## Testing` already carries feature scenario-title rows
-> (`Scenario: <title>` / `AC-N` keys with MET status), **copy those rows into the new artifact**
-> keyed the same way — record re-transcribes `## Testing` wholesale, so a fresh artifact keyed by
-> bare `R1`-style ids drops the scenario keys `spur feature check` needs for satisfaction
-> (`L4.scenario-unverified` regresses; 0921/D63). Since 0936, `record` warns on stderr (exit 0)
-> for each dropped MET-matched scenario key and when the new rows match no feature scenario —
-> treat those warnings as a re-key instruction, not noise.
-
-> **Keying rule for feature-linked tasks (1086/1089 re-audits).** Key AC rows by the exact feature
-> scenario title (`R1 — …`): feature `Scenario:` titles are declared identities and satisfy L4
-> scenario matching directly. Bare `AC1` fails `ac-identity` on Gherkin AC sections, and checklist
-> labels truncate at the first colon (a `(req: …)` suffix), so the task's own AC title may not resolve.
+> **Keying rule for feature-linked tasks.** Key AC rows by the exact feature scenario title
+> (`R1 — …`) or `AC-N`, so `record` can tick the aliased AC line.
 
 > **Do not write `## Review` directly, ever.** The `## Review` section is owned by the
 > `review` coordinator (`/sp:dev-review` → `sp:super-reviewer`), which merges
@@ -358,20 +330,18 @@ Verdict: PASS
 ```
 
 The per-requirement traceability table MUST use `| Req | Status | Evidence |` (exactly this header, no `R#`/`R`/`Requirement` variant — `Status` in column 2 — and no extra columns between Req and Status). The Acceptance Criteria table MUST use `| AC | Status | Evidence Type | Evidence |`.
-The answer MUST carry exactly one top-level `Confidence: HIGH|MEDIUM|LOW` line (ADR-141): the lint *derives* the level from your own rows and rejects a mismatch (`confidence-missing` / `-duplicate` / `-mismatch`), so state the level your evidence earns — `HIGH` needs every AC row MET on `test`/`command`, a citation-only row makes it `MEDIUM`. Full rule: [verdict-schema](references/verdict-schema.md).
-The answer MUST cite a source for external API/library claims in Requirement/AC evidence cells: a cell asserting a scoped-package (`@scope/name`), `node_modules/`, semver-version (`x.y.z`), or backticked function-call (`` `name(args)` ``) claim is rejected with `evidence-citation` unless the SAME cell carries a citation — a repo `path:line(-end)` (backticked or bare), the external named-origin form (@origin `path` line N), or a URL. Cross-cell references ("receipt above") do not count; marker-free receipts ("bun test 398 pass / 0 fail") need no citation.
+Cite a source for external API/library claims in the SAME evidence cell (repo `path:line`, the external named-origin form, or a URL) — reviewer-enforced, not linted.
 **MUST NOT:** place a `Severity` column between `Req` and `Status`. The parser tolerates variants
 as defense-in-depth; this contract is canonical.
 
 Under the pipeline, the verifier owns the answer file `.spur/run/<wbs>-verify-answer.txt` (0726
 R3): `Verdict: PARTIAL` first, append one row at a time, replace the verdict line only when all
-rows are certified — interruptions leave lintable partial rows; retries fill only missing IDs.
-Host: `spur task verdict --from-answer` lints the answer file, then derives the verdict +
-`spur task check` (R9). Vocabularies,
-rejection classes, and the AC identity rule: `references/verdict-schema.md`. Sections follow the
+rows are certified — interruptions leave usable partial rows; retries fill only missing IDs.
+Host: `spur task verdict --from-answer` derives the verdict from the answer file, then runs
+`spur task check` (R9). Vocabularies and the AC identity rule: `references/verdict-schema.md`. Sections follow the
 Step 10 contract.
 
-**Standalone** (outside the pipeline — no host lint/derive step), write the answer file and
+**Standalone** (outside the pipeline — no host derive step), write the answer file and
 artifact yourself; shape and field-by-field contract in
 [references/verdict-schema.md](references/verdict-schema.md):
 

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

@@ -40,38 +40,6 @@ interface VerifyVerdict {
 }
 ```
 
-## Answer confidence is derived and cross-checked (ADR-141, superseding F511 for answers)
-
-A verify answer carries exactly one top-level `Confidence: HIGH|MEDIUM|LOW` line — conventionally
-right after `Verdict:`, and legal anywhere at top level. The label is **not** a self-assessment: the
-lint recomputes it from the answer's own rows and rejects a disagreement.
-
-| Derived | When the answer's rows say so |
-| --- | --- |
-| `LOW` | the verdict is not PASS, or any requirement/AC row is PARTIAL/UNMET |
-| `HIGH` | PASS, and every AC row is MET on executable evidence (`test`/`command`; compounds allowed) |
-| `MEDIUM` | PASS with every AC MET, but at least one row rests on `static-ref`, `manual-review`, `llm-judge` or `N/A` |
-
-Rejections (`spur task verdict --from-answer`, exit 1, no artifact): `confidence-missing`,
-`confidence-duplicate`, `confidence-mismatch` — the last names both the stated and the derived level
-plus the clause the rows turn on. Derivation lives once, in
-`packages/app/src/services/answer-confidence.ts`; the review lane uses the same module for its own
-dispositions.
-
-Still retired and not revived by this: **verdict artifacts** carry no `confidence` field (the answer
-stays the record of truth, and a test pins the field's absence), feature-verification receipts keep
-no level (ADR-131, 1196), no operator `ackLowConfidence`-style var exists, and history-anatomy
-findings carry no per-finding grade. A verifier that can write a PASS can still write a wrong
-`HIGH` — which is exactly why the gate derives the level instead of trusting it.
-
-**A review run carries two answer artifacts, one `Confidence:` line each (1254).** The `## Review`
-section states the disposition-derived level (`deriveReviewConfidence`); the captured answer handed
-to `spur task verdict --from-answer` states the evidence-derived level (`deriveVerifyConfidence`)
-under the table above and carries exactly one `Confidence:` line. The two legitimately disagree — a
-PASS with executable AC and one carried P4 is section `MEDIUM`, answer `HIGH` — so the captured
-answer must not repeat the section's line (`confidence-duplicate` rejects the whole answer). The
-review stage's prompt owns that instruction; this schema owns the shape it must produce.
-
 ## Compatibility alias: `scenario` row key
 
 Task 0410 hardened the verdict reader. Producers SHOULD use the canonical `id` field for every
@@ -81,17 +49,7 @@ as a compatibility alias for the row identifier, with these rules:
 - Row with `id` only → canonical; accepted as-is.
 - Row with `scenario` only → accepted; normalized to `{ id: scenario, … }`.
 - Row with both `id` and `scenario` where they are EQUAL → `id` is authoritative; accepted.
-- Row with both `id` and `scenario` where they DIFFER or either value is not a string → **rejected**
-  (conflict); the rejected row
-  count and invalid fields surface as a bounded `L4.malformed-verdict-artifact` warning naming the
-  task WBS and artifact path.
-- Row missing both `id` and `scenario`, or missing `status`, or not an object → rejected and warned.
-
-Empty `requirements` / `acceptanceCriteria` arrays are valid and produce no warning. The required
-`requirements` array being absent, either coverage field being a non-array value, a missing artifact,
-malformed JSON, and a non-object JSON root are distinct diagnostic outcomes. Each emits one bounded
-`L4.malformed-verdict-artifact` warning per task/artifact whose message names the failure mode;
-optional `acceptanceCriteria` may remain absent.
+- Row with both `id` and `scenario` where they DIFFER, or a row missing both → ignored.
 
 Canonical producers and docs continue to use `id`. The `scenario` alias exists so older or
 third-party verdict emitters keyed on scenario titles are not silently dropped.
@@ -144,65 +102,28 @@ For answer files, emit a matching parseable table:
 
 **Authoring contract under the pipeline (0726 R3).** The verifier owns the answer file: write
 `Verdict: PARTIAL` first, append one complete row at a time, and replace the first verdict line only
-after every row is certified. `spur task verdict --from-answer` lints the file before deriving the
-verdict and rejects, with row-level diagnostics: missing/duplicate/unknown requirement IDs,
-AC ids that do not resolve to one accepted identity — a task AC checklist label or its declared
-`AC-N`/checklist-token alias, or a linked feature scenario title, in the ac-style-guide forms
-(exact/bare title, `Scenario:` prefix, bracket tags, `AC-N`); paraphrases and ambiguous aliases
-fail — invalid status (`MET | PARTIAL | UNMET` for requirements;
-`N/A` additionally allowed for AC), invalid evidence type (`test | command | static-ref |
-manual-review | llm-judge | n/a`, or a `+` compound), and empty evidence. Evidence cells that assert an
-external API/library claim without a same-cell citation are rejected with `evidence-citation` (see
-"Source citations for external claims" below). Interrupted runs keep the
-rows that pass the lint and complete only the missing IDs on retry.
-
-**Feature-credited AC ids are narrower than the lint's accepted set (task 0966 finding).** A row keyed
-by a bare checklist ordinal (`AC1`) passes the `spur task verdict` answer lint — it resolves to the task's AC
-checklist label — but `feature-check.rowMatchesScenario` credits a linked feature scenario only by the
-scenario's normalized title or its `AC-N` ordinal alias. Such a row therefore carries a PASS verdict
-while crediting no scenario, and the feature's `verifying → done` gate denies with
-`L4.scenario-unverified` / `L4.verdict-rows-match-no-scenario`. When the task has a linked feature,
-key each AC row `AC-N` (1-based scenario ordinal, hyphenated) or by the exact scenario title.
-A scenario-keyed row (`R3 — <title>`) ticks the task AC box whose line aliases that scenario
-(`- [ ] AC1 — R3 — <title>`) during `spur task record` (0996); a scenario key no AC line aliases
-ticks nothing, so alias every graduated scenario on its AC line.
-
-**Concrete anchors only (task 0804 R9).** An evidence anchor must be a concrete existing `file:line`
-(or `file:start-end`) path. A glob or directory summary (`src/services/*.ts`, `the retry
-classifiers in task-pipeline.yaml`) is not an anchor: expand it into the specific cited files/ranges
-the run actually verified. Since 0804 R9 the checker ignores complete parsed citation spans before
-scanning for subjects, so a citation's filename (including snake_case paths) can never become a
-false subject — a real absent symbol, nonexistent file, or invalid range still reports.
-
-## Basename-only anchors are unresolved anchors (task 1110 R1)
-
-`spur task verdict --from-answer` accepts the citation *shape*, but the `--as done` gate resolves
-every Testing/Solution anchor against the repo root. A basename citation — `decision-events.ts:83`,
-`task.test.ts:42` — reports `L4.anchor-unresolved` at **error** and blocks
-`spur task update <wbs> done`, because the gate cannot tell which file the row meant. Write the
-repo-root-relative form from the first pass:
+after every row is certified. `spur task verdict --from-answer` derives the verdict from that file;
+nothing lints the rows, so their accuracy is the verifier's responsibility. Vocabularies: status
+`MET | PARTIAL | UNMET` (`N/A` additionally allowed for AC); evidence type `test | command |
+static-ref | manual-review | llm-judge | n/a`, or a `+` compound. Interrupted runs keep the rows
+already written and complete only the missing IDs on retry.
+
+**Key AC rows so `record` can tick them.** A scenario-keyed row (`R3 — <title>`, `AC-N`, or the exact
+scenario title) ticks the task AC box whose line aliases that scenario (`- [ ] AC1 — R3 — <title>`)
+during `spur task record` (0996); a key no AC line aliases ticks nothing.
+
+**Concrete anchors only.** Cite a concrete existing repo-root-relative `file:line` (or
+`file:start-end`), never a glob, directory summary or basename. Nothing resolves anchors
+mechanically — a reviewer who cannot open the cited line treats the row as unproven.
 
 - Right: `packages/app/src/decision/decision-events.ts:83`, `apps/cli/tests/commands/task/verdict.test.ts:42`
 - Wrong: `decision-events.ts:83`, `../services/foo.ts:12`, `@gobing-ai/ts-x/src/persistence.ts:108`
   (a scoped package is never repo-relative — use the external named-origin form below)
 
-The pipeline's implement stage also runs a scoped `spur task migrate-anchors --wbs <wbs>` pass
-before the proof capture (task 1109), but it qualifies **unique** basenames only: an ambiguous
-basename (two tracked files share it) is reported and left untouched, and line drift and
-`L4.anchor-subject-mismatch` are never repaired by that pass — those remain the author's rows.
-
-A **workspace-relative** path fails the same way, and is the easier mistake to make because the
-command it came from is real. `(cd apps/cli && bun test tests/commands/builder/pr.test.ts)` is the
-right way to run the suite, but `tests/commands/builder/pr.test.ts` does not resolve from the repo
-root, so the AC-coverage guard reports `missing: <AC> — <path>` and refuses `done` (observed
-2026-10-16, task 1215 — the repair was a fresh verify pass over the whole answer). Cite both halves:
-the workspace-rooted command you ran, then the repo-root-relative anchor of the file it names
-(`apps/cli/tests/commands/builder/pr.test.ts`). One anchor per cited file per cell is enough.
-
 ## Source citations for external claims (task 1070)
 
 A Requirement/AC evidence cell that asserts an external API/library claim must carry a verifiable
-citation in the SAME cell, or lint rejects the row with `evidence-citation` (blocking derivation).
+citation in the SAME cell. Nothing machine-checks this — the reviewer enforces it.
 
 - Claim markers (closed set): a scoped-package mention (`@scope/name`), a `node_modules/` reference,
   a semver version claim (`x.y.z`), or a backticked function-call-shaped token (`` `name(args)` ``).
@@ -212,27 +133,6 @@ citation in the SAME cell, or lint rejects the row with `evidence-citation` (blo
 - The rule is cell-local: a citation in another row or a "receipt above" cross-reference does not
   satisfy it. Marker-free receipts (test counts, reviewed-log notes) need no citation. The check is
   presence-only — which citation proves which claim is not deterministically decidable.
-- The same two predicates (`hasClaimMarker` / `hasCitationForm` in
-  `packages/app/src/services/verify-answer-lint.ts`) gate the review report's findings table through
-  `spur task residual <wbs> review-gate` as the blocking `review-contract` category — one definition of
-  "external claim" and one set of accepted citation forms for both paths.
-
-## Hedged evidence is rejected on MET rows
-
-A MET row asserts the requirement is satisfied; evidence that hedges ("the guard likely prevents
-the leak") contradicts the assertion the row is making. The lint rejects such rows with
-`evidence-hedged`, naming the detected phrase, with two remedies: state the deterministic fact
-with a concrete anchor, or downgrade the row to PARTIAL (which is what suspected-but-unproven
-behavior actually is).
-
-- Detected phrases (closed set, word-anchored, case-insensitive): `likely`, `unlikely`,
-  `probably`, `presumably`, `apparently`, `seems/seeming/seemingly to`, `appears to`. Modal verbs
-  (`might`/`may`/`could`/`should`) are deliberately out of set — they are constant in remediation
-  prose and would drown the signal.
-- Only MET rows are scanned. Hedging a gap in an UNMET row ("the stale path likely still loads
-  the old bundle") is honest reporting and stays clean.
-- Citation spans are stripped before scanning, so a filename or test name containing a hedge
-  word (`likely-match.test.ts`) cannot fire.
 
 ## Checks evidence
 
@@ -245,14 +145,13 @@ Wave C verification can emit the following additive `checks[]` rows:
 | `evidence-rule-pass` | All behavior-bearing AC rows had executable evidence or were explicitly non-behavioral. |
 | `evidence-rule-failed` | One or more MET behavior-bearing AC rows lacked `test` / `command` evidence and were downgraded to PARTIAL. |
 | `cli-golden-path-present` | CLI-surface tasks supplied, or failed to supply, one golden-path command evidence row. |
-| `residual-sweep` | Post-verdict residual scan (F96): `fail` when blocking leftovers exist (P1–P3 findings, added diff markers, unchecked boxes); evidence lists blocking/deferrable/advisory/housekeeping counts plus blocking and deferrable item ids. A `fail` downgrades an otherwise-PASS verdict to PARTIAL via the fold step. |
 
 ## How the gate reads it
 
 In `task-pipeline.yaml` the `review` state writes this artifact: `spur task verdict <wbs>
---from-answer` lints the review answer and derives `.spur/run/<wbs>-verdict.json`. A fold step then
-writes `.spur/run/<wbs>-review.status` = PASS only when the typed verdict is PASS, the artifact's own
-`verdict` is PASS (`jq -r '.verdict // empty'`) and `spur task residual <wbs> review-gate` is clean.
+--from-answer` derives `.spur/run/<wbs>-verdict.json` from the review answer. A fold step then
+writes `.spur/run/<wbs>-review.status` = PASS only when the typed verdict is PASS and the artifact's
+own `verdict` is PASS (`jq -r '.verdict // empty'`).
 The `review → done` guard reads that status **and** the approval decision point's token:
 
 ```yaml

package/plugins/sp/skills/issue-finding/SKILL.md

@@ -316,7 +316,7 @@ spur task check <wbs> --json
 ```
 
 Must return `pass: true` with 0 errors. Warnings may be acceptable on meta tasks
-(e.g. `prose-prerequisite-unlisted`, `uncovered-task-scenario`).
+(e.g. `uncovered-task-scenario`).
 
 ## Output
 

package/plugins/sp/skills/next-router/references/routing-table.md

@@ -119,13 +119,6 @@ token, deterministic).
 | C3 | A5/A6 when Testing empty/N/A **and** verify would fail for missing tests — only if prior implement claims code exists | Coverage/test signal: `bun test` fail attributed to task paths OR explicit "insufficient tests" in prior verify verdict artifact `.spur/run/<wbs>-verdict.json` | test fail / coverage gap | `/sp:dev-unit <wbs> --auto` | continue |
 | C4 | A3/A5/A6 when operator or task tags mention rules, OR `spur rule run` last report dirty in `.spur/` if present | `spur rule run` (default project preset) non-zero with findings | rule findings | **HITL STOP** — print rule summary; suggest `/sp:rule-scan` or `rule-add`/`rule-refine` (do not auto-author rules) | continue |
 | C5 | A6 only | Existing `.spur/run/<wbs>-verdict.json` with FAIL and findings pointing at coverage | verdict artifact | `/sp:dev-unit <wbs>` then re-verify on next invocation (`--once` friendly) | `/sp:dev-verify …` |
-| C6 | A4/A5 | `.spur/run/<wbs>-verdict.json` has a failing (PARTIAL/FAIL) `residual-sweep` check — residual blockers survived the pipeline sweep (F96) | folded verdict artifact | **HITL STOP** — print `.spur/run/<wbs>-residual-report.md` and the recovery command `/sp:dev-run <wbs>`; never auto-dispatch a fix (repeating the loop unattended burns quota without new information) | continue |
-
-**C-row precedence note (F96):** C6 outranks C2/C3/C5 for the same task — a residual-sweep failure
-means the workspace holds unfinished task residue, so fixall/unit reruns would either clean it
-unintentionally or re-certify a folded verdict. C6 fires before any fix/unit dispatch; recovery is
-the operator re-running the pipeline (`/sp:dev-run <wbs>`), which re-enters the normal
-gate ⇄ remediate budget.
 
 **Explicit non-probes in v1:** no freeform chat history; no always-on full `bun run test` for every
 call; no git dirtiness as a route (optional advisory print only).

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

@@ -562,12 +562,7 @@ schema before emitting.
 
 **Pass the deterministic task check.** Each `acceptance_criteria` bullet must be an exact feature
 scenario title (L4.uncovered-task-scenario); add task-local checks as prose after the bullets, not
-as extra bullets. No section body may use `HITL`, `merge event`, `content-gate`, `GATED`, or
-`capstone` as standalone words in any case (L4.gate-language) — dotted action kinds such as
-`hitl.confirm` are fine, a bare `hitl` count is not; ambiguous words (`approval`, `approved`,
-`merged`) warn only with a gating cue (`until`, `after`, `once`, `before`, `pending`, `blocked`,
-`wait for`, `requires`) in the same sentence, so plain composition prose stays silent — say
-"operator answer" / "accepted" instead, and keep enum values out of that list too.
+as extra bullets.
 
 **The order sidecar.** Also emit the private task-order sidecar at
 `.spur/run/<runId>-idea-task-order.json`: a JSON array (one entry per batch item) of

package/plugins/sp/skills/spur-cli/references/decision.md

@@ -25,7 +25,7 @@ Decisions resolve first-wins across three layers:
 | `registered` | folders listed in config `decisions.paths` | Operator-added catalogs |
 | `shared` | `decisions/` under the bundled config root | Shipped catalogs (`config/decisions/` in-repo) |
 
-The bundled shared catalog ships `task-semantic-risk`, `failure-class`,
+The bundled shared catalog ships `failure-class`,
 `gate-evidence`, `idea-recommendation`, `needs-design`, `anatomy-validation-verdict` and
 `maker-liveness` (the last served only by `spur decision status --probe`; no workflow references
 it). Layers win **per file basename** (a project `gates.yaml` replaces the shipped `gates.yaml`
@@ -84,8 +84,7 @@ row lands in `system_events` beside `decision.end`, on the same `run_id`, so the
 **Scoring one.** `decisions.outcomeMap` in config (project or global layer) holds Spur's reading of
 Spur's own artifacts — per decision id, which recorded outcomes count as correct for each served
 value (`String(value)` keys, so a yes/no decision uses `"true"`/`"false"`). The shipped defaults
-score `failure-class` (`fix` → `fixed`, `stop` → `not-fixed`) and `task-semantic-risk`
-(`"false"` → `none`/`p4`/`p3`, `"true"` → `p1`/`p2`).
+score `failure-class` (`fix` → `fixed`, `stop` → `not-fixed`).
 
 `spur decision status --reliability` then reports, per (decision × maker) group:
 
@@ -237,9 +236,7 @@ guards: [decision/lifecycle.md](decision/lifecycle.md) §1, §3.
 
 ```bash
 spur decision list --json | jq -r '.[].id'
-spur decision show task-semantic-risk               # inspect contract before serving
-spur decision run task-semantic-risk --param wbs=1093 \
-    --evidence .spur/run/1093-diffstat.json --evidence docs/tasks/1093_*.md --json
+spur decision show failure-class                    # inspect contract before serving
 spur decision run failure-class --param wbs=1093 \
     --evidence .spur/run/<runId>-test-output.txt    # redacted evidence -> instructions
 spur decision status --json | jq '.loadErrors'      # audit catalog health

package/plugins/sp/skills/spur-cli/references/tasks/verbs.md

@@ -256,32 +256,6 @@ the active tasks folder (or `--folder`).
 | `--folder <path>` | Custom tasks folder. |
 | `--json` | Machine-readable report envelope. |
 
-## `migrate-anchors`
-
-Qualify in-repo evidence anchors to repo-relative paths across the task corpus. Run
-`--dry-run` first: unambiguous matches are reported in `qualified`, multiple matches in `ambiguous`
-without rewriting, and schema-incompatible files in `skipped`. The write path uses the planning
-service rather than raw file edits.
-
-**`done_reason` scratch pointers are retargeted** (task 1140, ADR-131): a `.spur/run/<wbs>-verdict.json`
-or `.spur/run/<wbs>/verdict.json` substring becomes `.spur/memory/evidence/<wbs>-verdict.json` when
-that copy exists, else `tracked Testing section (scratch verdict not retained)` when Testing is
-non-empty; otherwise the value is left unchanged and reported in `doneReasonUnresolved`. Each
-`doneReasons` row carries `kind` (`absolute-path` | `durable-evidence` | `tracked-testing`). This is
-the repair for the `no-scratch-verdict-pointer` rule.
-
-**`--wbs <wbs>` scopes the pass to one task file** (task 1109 R1) — the wbs is resolved through the
-task locator and exactly that file is scanned, so the pipeline's implement stage can auto-repair a
-task's unique basename anchors without the corpus-wide pass rewriting unrelated files (the unscoped
-apply rewrote 119 on 2026-10-07). An unknown wbs exits `1` with an actionable message and writes
-nothing. Ambiguous basenames are still reported and left untouched in scoped mode.
-
-```bash
-spur task migrate-anchors --dry-run --json
-spur task migrate-anchors --json
-spur task migrate-anchors --wbs 1109 --json     # one task file only
-```
-
 ## `resolve <file-path>`
 
 Map a file path to its **owning task** — returns the WBS + task file. Strategies, in order: direct
@@ -454,7 +428,6 @@ spur task sections <wbs> <init|add|list> [name] [--folder] [--json]
 spur task list     [--status <s>] [--phase <p>] [--parent <wbs>] [--feature <id>] [--folder] [--json]
 spur task refresh  [--folder] [--json]
 spur task migrate  [--dry-run] [--folder] [--json]
-spur task migrate-anchors [--wbs <wbs>] [--dry-run] [--json]
 spur task refresh-roster <wbs> [--folder] [--json]
 spur task batch-create --file <path> [--skip-ready | --agent <selector>] [--folder] [--json]
 spur task record   <wbs> [--verdict-file <p>] [--solution-from-diff] [--transition <s>] [--folder] [--json]
@@ -466,7 +439,6 @@ spur task path     <wbs> [--folder] [--json]
 spur task run-link <wbs> [--source <src>] [--run-id <id>] [--json]
 spur task scaffold-tests <wbs> [--file <path>] [--folder] [--json]
 spur task gate     <wbs> <run|recheck|light|deferred|status> [--cmd <c>] [--probe-cmd <c>] [--run-id <id>]
-spur task residual <wbs> <scan|review-gate|fold|settle|report> [--root <dir>] [--tmp-dir <dir>] [--folder]
 spur task diffstat <wbs>
 ```
 

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

@@ -72,11 +72,16 @@ mode; `batch-create` surfaces per-child `warnings` rows (`[{"wbs", "warnings"}]`
 when non-empty) in `--json` and prints `<wbs>: <warning>` lines to stderr in human mode;
 `update --section` section writes carried this advisory already.
 
+When an advisory fires, split the task instead of growing it: decompose into smaller tasks before
+pipeline execution (execution-workflow.md, "Split oversized tasks before pipeline execution").
+`create --requirements/--plan` and `batch-create` body fields exist to author the split tasks'
+content up front — not to accumulate more into one oversized task.
+
 ## Verb map
 
 | Verb | Purpose | Key flags |
 | ---- | ------- | --------- |
-| `create <title>` | Allocate a new task (race-safe WBS) | `--feature <id>` `--no-reopen` `--parent <wbs>` `--template <variant>` `--dedupe-within <s>` `--allow-duplicate-name` `--skip-ready` `--agent <selector>` `--folder` `--json` |
+| `create <title>` | Allocate a new task (race-safe WBS) | `--feature <id>` `--no-reopen` `--parent <wbs>` `--template <variant>` `--requirements <text>` `--plan <text>` `--dedupe-within <s>` `--allow-duplicate-name` `--skip-ready` `--agent <selector>` `--folder` `--json` |
 | `show <wbs>` | Print one task's frontmatter + body; section-filtered or summary mode (1325) | `--section <name>` `--sections <csv>` `--summary` `--folder` `--json` |
 | `update <wbs> [status]` | Lifecycle transition, section replace, **or** frontmatter set | `--section <name> --from-file <path>` `--assignee <spec-id>` (exclusive with `--section`) `--feature <id>` `--no-reopen` `--priority <p>` `--ac-numbering task-local` `--ac-altitude <a>` `--estimate-hours <n>` `--no-lifecycle` `--force-done` `--reason <text>` `--provenance-bypass` `--verdict-dir <path>` `--folder` `--json` |
 | `deps <wbs> <op> [values...]` | Mutate `dependencies[]` frontmatter array (ops: `set`, `add`, `remove`, `clear`) | `--folder` `--json` |
@@ -84,7 +89,6 @@ when non-empty) in `--json` and prints `<wbs>: <warning>` lines to stderr in hum
 | `list` | List tasks, filtered | `--status <s>` `--phase <p>` `--parent <wbs>` `--feature <id>` `--folder` `--json` |
 | `refresh` | Re-scan the corpus and report counts (**`kanban.md` retired** — web Task Kanban is SSOT) | `--folder` `--json` |
 | `migrate` | One-time A17 corpus normalization pass | `--dry-run` `--folder` `--json` |
-| `migrate-anchors` | Qualify in-repo evidence anchors to repo-relative paths (0583 R1–R3); `--wbs` scopes to one task file (1109 R1); retargets scratch `done_reason` verdict pointers (1140) | `--wbs` `--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>` `--skip-ready` `--agent <selector>` `--folder` `--json` |
 | `batch-plan <mode>` | Batch plan projection: `waves` / `order` (JSON on stdout; the batch driver's visible plan) | `--tasks <file>` `--concurrency <n>` |
@@ -100,13 +104,11 @@ when non-empty) in `--json` and prints `<wbs>: <warning>` lines to stderr in hum
 | `verifyall-aggregate` | Aggregate per-task verify outcomes into a batch verdict (NOT-STARTED excluded) | `--from-file <path>` `--json` |
 | `scaffold-tests <wbs>` | Generate BDD test stubs from task Acceptance Criteria | `--file <path>` `--folder` `--json` |
 | `gate <wbs> <mode>` | Task-pipeline quality gate (`run`, `recheck`, `light`, `deferred`, `status`); mode-specific exits and git-tree-keyed receipts (see `sp:spur-check`) | `--cmd <c>` `--probe-cmd <c>` `--run-id <id>` |
-| `residual <wbs> <step>` | F96 residual sweep step (`scan`, `review-gate`, `fold`, `settle`, `report`) | `--root <dir>` `--tmp-dir <dir>` `--folder` |
 | `diffstat <wbs>` | Write the triage diffstat artifact against the run base (fails safe to `sensitive: true`) | — |
 
 Use only the flags listed for the selected verb. `batch-plan` emits JSON without `--json`;
-`wrapup`, `gate`, `residual` and `diffstat` use their operation-specific stdout/artifact contracts.
-`run-link`, `verifyall-aggregate` and `migrate-anchors` accept `--json` but no `--folder`;
-`residual` accepts `--folder` but no `--json`. Do not append shared flags to every command.
+`wrapup`, `gate` and `diffstat` use their operation-specific stdout/artifact contracts.
+`run-link` and `verifyall-aggregate` accept `--json` but no `--folder`. Do not append shared flags to every command.
 General exit codes are `0` success, `1` error, `2` invalid usage; consult the operation contract
 for soft gate modes and specialized refusal codes.
 
@@ -198,7 +200,7 @@ refused (ready-set resolver and pipeline preflight), and a live dependent is rep
 reported, never rewritten.
 
 Writes that stay **permitted** on a `deprecated` task (each edits the record rather than declaring
-the work resumable): `spur task record`, `migrate-anchors` and verdict writes, and
+the work resumable): `spur task record` and verdict writes, and
 `spur task update <wbs> --section <any>` — the section write lands and returns a freeze warning.
 
 **`--no-lifecycle`** suppresses lifecycle workflow *run record* creation (use during pipeline-driven