@gobing-ai/spur 0.4.33 → 0.4.35

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

@@ -89,7 +89,6 @@ content up front — not to accumulate more into one oversized task.
 | `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>` |
@@ -105,13 +104,11 @@ content up front — not to accumulate more into one oversized task.
 | `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.
 
@@ -203,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

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

@@ -126,14 +126,8 @@ scenario, it matches by title. Rules:
   Registered user can log in with email and password" is traceable.
 - **No synonyms in cross-references.** The title in the feature file and the title in the
   task's AC reference must be byte-identical.
-- **Avoid gate vocabulary in titles.** `spur task check` (L4.gate-language) rejects task sections
-  containing `HITL`, `merge event`, `content-gate`, `GATED`, or `capstone` as standalone words in any
-  case (dotted action kinds such as `hitl.confirm` are fine);
-  ambiguous words (`approval`, `approved`, `merged`) warn only when the same sentence also carries
-  a gating cue (`until`, `after`, `once`, `before`, `pending`, `blocked`, `wait for`, `requires`)
-  — plain composition prose like "the stages merged back into one step" stays silent. Task AC
-  bullets copy scenario titles verbatim, so a title using the unconditional tokens fails every
-  child task. Write "pause for an operator answer" instead of "HITL approval".
+- **Avoid gate vocabulary in titles** (`HITL`, `merge event`, `GATED`, `capstone`): it reads as a
+  dependency nothing declares. Convention only — nothing checks it. Write "pause for an operator answer" instead of "HITL approval".
 
 ## Verdict AC ↔ feature scenario linkage
 
@@ -174,7 +168,7 @@ Any of the four may additionally carry a **bracket tag** in any position — `[d
 `Scenario: [advisory] Foo`. Tags are stripped before matching (0398 R7), so tagging never breaks
 the linkage.
 
-Task-side, the `spur task verdict` answer lint additionally accepts a fifth declared id source — a **bold-trajectory
+Task-side, a fifth declared id source is accepted — a **bold-trajectory
 paragraph**: a whole-line `**AC id…**` paragraph inside the task's `### Acceptance Criteria`
 block (task 0817 R3). The id up to its first `:` and the paragraph's full spelling are both
 declared; two bold spans on one line are not a declaration (an interpolated bold id stays
@@ -190,13 +184,12 @@ unmatchable):
 
 ### A bullet's bold head is its id
 
-The `spur task verdict` answer lint declares the bold span of a single-line criterion bullet
+`spur task verdict` treats the bold span of a single-line criterion bullet
 (`- **AC2 — The roster runtime is gone (R3).** Given …, when …, then …`) and its head before the
 first ` — ` or `:` — so answer rows may key `AC2` or `AC2 — The roster runtime is gone (R3).`. Keep
 at least one answer row keyed to the verbatim feature scenario title the task graduates, and keep
 requirement ids in the template-taught corpus form, `- [ ] R1. <text>`: that (or an unbolded `R1.`
-variant) is what the task-local binding loop parses — bold wrapping (`**R1**`) passes the
-`L3.requirements-format` ratio but binds nothing — and a colon after the bold span still silently
+variant) is what the task-local binding loop parses — bold wrapping (`**R1**`) binds nothing — and a colon after the bold span still silently
 drops the whole section to a warning. Bold AC heads are likewise a verdict-table id form, not the AC
 authoring form: author new AC rows in the plain `- [ ] AC1 —` / `Scenario: AC1 —` shapes.
 
@@ -340,5 +333,5 @@ truly does not apply (do not silently default new tasks to it).
 | Legacy raw bullets | `- AC1 …` (no checkbox, no `Scenario:`) | n/a | unparsed: invisible to subset, binding, and box checks — preserve in place, never author new |
 
 `task-local` altitude skips only the feature-subset check. It does not waive the unchecked-box check,
-required sections, the proof-bound verdict, line anchors, or any other done check — AC syntax alone,
+required sections, the proof-bound verdict, or any other done check — AC syntax alone,
 at any altitude, never makes a task done.

package/plugins/sp/skills/spur-dev/references/cross-cutting.md

@@ -412,9 +412,8 @@ loop?**
 
 - **External evidence** — evidence that lives outside `spur`'s working tree uses the frozen non-anchor
   form `origin`path`line N` (line OUTSIDE the backticks), e.g.
-  `@gobing-ai/ts-llm-jsonl-importer`src/mappers.ts`line 481`. It is classified external, never
-  `L4.stale-line-anchor`. In-repo evidence MUST use the repo-relative backtick form `path:line` —
-  citing an in-repo file in the external form still reports (R1/R2). See `ac-style-guide.md` and the
+  `@gobing-ai/ts-llm-jsonl-importer`src/mappers.ts`line 481`. In-repo evidence uses the repo-relative backtick form `path:line`. Reviewer-facing convention —
+  nothing resolves anchors mechanically. See `ac-style-guide.md` and the
   `code-verification` skill for when each applies.
 
 **Why this is a rule and not a preference.** A decision filed as a task sits in `spur task list` and

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

@@ -73,7 +73,7 @@ each would be scope creep for one-liner procedures.
 | 2   | review     | `dev-review`        | `Skill()`         | `sp:code-verification` (`review`) + `sp:functional-review` + `sp:code-improvement` | `[--tasks <selector> \| --feature <id>[,<id>] \| --scope <path>[,<path>]] [--agent <inline\|auto\|name>] [--focus <dims>] [--triage] [--worktree [<name>]] [--auto]`                                                                                              |
 | 3   | verify     | `dev-verify`        | `Skill()`         | `sp:code-verification` (`verify`)                                                  | `<wbs> [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--skip-shippable]`                                                     |
 | 3a  | verifyall  | `dev-verifyall`     | `Skill()` → agent | `sp:spur-dev` (`verifyall`)                                                        | `--tasks <selector> [--feature <id>] [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--json] [--skip-shippable] [--worktree [<name>]]` |
-| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--continue] [--worktree [<name>]] [--no-summary]`                                                                                              |
+| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--wrap-pr] [--continue] [--worktree [<name>]] [--no-summary]`                                                                                              |
 | 5   | refine     | `dev-refine`        | `Skill()`         | `sp:spur-dev` (`refine`)                                                           | `<wbs> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--next]`                                                                           |
 | 5a  | refineall  | `dev-refineall`     | `Skill()`         | `sp:spur-dev` (`refineall`)                                                        | `--feature <id> \| --tasks <selector> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--keep-going] [--status <s>] [--json] [--worktree [<name>]]` |
 | 6   | plan       | `dev-plan`          | `Skill()`         | host executor (`idea-pipeline`) or async workflow                                  | `"<description>" [--feature <id>] [--parent <feature-id>] [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                   |
@@ -86,7 +86,7 @@ each would be scope creep for one-liner procedures.
 | 11b | job-resume | `dev-job-resume`    | `Skill()`         | `sp:spur-dev` (`job-resume`) | `--file <path>` |
 | 12  | brainstorm | `dev-brainstorm`    | `Skill()`         | `sp:brainstorm` (`dev-brainstorm`)                                                 | `<topic> [--depth <basic\|detailed\|comprehensive>] [--options <n>] [--agent <inline\|auto\|name>] [--skip-discovery] [--task [<feature-id>]] [--feature [<parent-id>]] [--next]`          |
 | 12a | find-way   | `dev-find-way`      | `Skill()`         | `sp:wayfinder` (worktree-isolated)                                                 | `<idea> \| <feature-id> [<wbs>] [--agent <inline\|auto\|name>] [--auto] [--worktree [<name>]] [--wrap]` |
-| 13  | runall     | `dev-runall`        | `Skill()` → agent | `sp:spur-dev` (`runall`) → `sp:super-planner`                                      | `--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]`                      |
+| 13  | runall     | `dev-runall`        | `Skill()` → agent | `sp:spur-dev` (`runall`) → `sp:super-planner`                                      | `--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]`                      |
 | 14  | wrap       | `dev-wrap`          | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `<wbs> [--agent <inline\|auto\|name>] [--auto] [--merge] [--dry-run]`                                                                                                                                 |
 | 15  | wrapall    | `dev-wrapall`       | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `[--since <iso>] [--feature <id>] [--status <s>] [--agent <inline\|auto\|name>] [--auto] [--merge] [--dry-run]`                                                                                        |
 | 16  | idea       | `dev-idea`          | `Skill()`         | host executor (`idea-pipeline`) or async workflow                                  | `"<idea>" \| --from-file <path> [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                                                                              |
@@ -156,7 +156,7 @@ must not be changed without updating the backing skill.
 ### 4. run
 
 - **Purpose:** Run a task through the execution pipeline (full) or execute a single pipeline step (implement).
-- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` resolves the selector uniformly (task 0687): omit ≡ explicit `--agent inline`; full mode runs `task-pipeline.yaml` on the host executor (`spur workflow run … executor=host` → work item → `spur workflow continue`) — host-controlled and non-subprocess, with 0508 eligibility applying to the resolved-inline selector (eligible `agent.run` stages dispatch once to a native subagent, host fallback)). `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope. `--worktree [<name>]` runs the full pipeline inside an isolated git worktree (create or reuse; FF-merge on success, retain on failure) — the batch lifecycle in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name) applied to a batch of one; rejected with `--mode implement`. `--no-summary` skips the [execution summary](#execution-summary) printed after a full-mode run. `--wrap` hands off to `/sp:dev-wrap <wbs>` after the main step; the `--agent` selector is preserved into that handoff when supplied (omission remains omission), and the wrap hop reports its own trigger-3 subprocess override per the wrap contract.
+- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` resolves the selector uniformly (task 0687): omit ≡ explicit `--agent inline`; full mode runs `task-pipeline.yaml` on the host executor (`spur workflow run … executor=host` → work item → `spur workflow continue`) — host-controlled and non-subprocess, with 0508 eligibility applying to the resolved-inline selector (eligible `agent.run` stages dispatch once to a native subagent, host fallback)). `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope. `--worktree [<name>]` runs the full pipeline inside an isolated git worktree (create or reuse; FF-merge on success, retain on failure) — the batch lifecycle in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name) applied to a batch of one; rejected with `--mode implement`. `--no-summary` skips the [execution summary](#execution-summary) printed after a full-mode run. `--wrap` hands off to `/sp:dev-wrap <wbs>` after the main step; the `--agent` selector is preserved into that handoff when supplied (omission remains omission), and the wrap hop reports its own trigger-3 subprocess override per the wrap contract. `--wrap-pr` runs the wrap hop on `$BRANCH`, commits close-out writes, pushes the branch to `origin`, and opens a Pull Request targeting `$BASE_REF` via `gh pr create` (`WT-PR`); mutually exclusive with `--wrap`.
 - **Backing:** `sp:spur-dev` skill — `run` operation for the full pipeline (the spine drives it); `sp:code-implementation` competency skill for the implement step (the spine dispatches to it).
 - **Modes:**
   - **`full`** (default): Drive the full pipeline — precheck → implement → gate ⇄ remediate → review → done, with the repair, stop and approval routes taken from decision rows ([decision-points.md](decision-points.md)). Interactive omit/inline runs `spur workflow run task-pipeline.yaml --vars '{"wbs":"<wbs>","executor":"host"}'` and performs each returned work item (eligible stages may use a native subagent); explicit/headless executor selection runs the same definition without the `executor` var (with `profile: auto` when `--auto`). Both monitor/surface HITL and preserve the YAML gates. `--next` never changes this mode.
@@ -481,7 +481,7 @@ gate commands, pending questions and approval requirements.>
 ### 13. runall
 
 - **Purpose:** Run a batch of tasks through their pipelines in dependency-correct order — resolve a set, topo-sort, run each via `task-pipeline.yaml`, inspect verdicts, apply the failure policy, emit a batch report.
-- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default off; `--auto` implies `--keep-going`, so an unattended batch never stops for a human — 1318 R1). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --fix --json` then `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2); scoped: `L4.scenario-unverified` and `L4.verifying-incomplete-tasks` (expected pre-run states of a not-yet-run or reopened feature) are reported verbatim but do not abort — the non-aborting set is `NON_ABORTING_PREFLIGHT_CODES` behind `spur task preflight --classify-feature` and `--fix` repairs are listed under `autoRepairs` — any other strict error aborts. Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` **once for the batch** over the `done` subset only (execution-batch.md Step 6: `vars.feature` only when every frozen task is `done`/`cancelled`; empty done subset skips with a reason), `--next` chains each task to terminal status then runs the same batch-once wrap, `--continue` resumes from checkpoint. `--no-summary` skips the [execution summary](#execution-summary) printed after the batch report (one row per attempted run).
+- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default off; `--auto` implies `--keep-going`, so an unattended batch never stops for a human — 1318 R1). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --fix --json` then `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2); scoped: `L4.scenario-unverified` and `L4.verifying-incomplete-tasks` (expected pre-run states of a not-yet-run or reopened feature) are reported verbatim but do not abort — the non-aborting set is `NON_ABORTING_PREFLIGHT_CODES` behind `spur task preflight --classify-feature` and `--fix` repairs are listed under `autoRepairs` — any other strict error aborts. Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` **once for the batch** over the `done` subset only (execution-batch.md Step 6: `vars.feature` only when every frozen task is `done`/`cancelled`; empty done subset skips with a reason), `--wrap-pr` runs the batch-once wrap hop, pushes to `origin`, and creates a Pull Request via `gh pr create` (`WT-PR`; mutually exclusive with `--wrap`), `--next` chains each task to terminal status then runs the same batch-once wrap, `--continue` resumes from checkpoint. `--no-summary` skips the [execution summary](#execution-summary) printed after the batch report (one row per attempted run).
 - **Three orthogonal axes (do not confuse):** `--keep-going` = batch failure policy (halt vs skip dependents); `--continue` = resume from checkpoint against the batch's original frozen identity (execution-batch.md § Batch continuation, task 0919); `--next` = per-task lifecycle chaining (advance status on a verdict — `dev-verify`/`dev-verifyall` only). `routing-table.md` offers `--continue` and `--next` as competing options for the same situation only when the batch was interrupted mid-run; otherwise they address different problems.
 - **Backing:** `sp:spur-dev` skill, `runall` operation → delegates the driver loop to the **`sp:super-planner`** agent (the batch orchestrator).
 - **Behavior:** The orchestrator reads [execution-batch.md](execution-batch.md) and drives: resolve selector → freeze set → topo-sort by `dependencies[]` (Kahn, WBS-ascending tie-break; cycle aborts) → resolve out-of-set deps by status (done → allow, else → block subtree) → run each task via `spur workflow run task-pipeline.yaml --async` + `spur workflow trace` polling → inspect terminal state + `.spur/run/<wbs>-verdict.json` → stop-the-batch default or `--keep-going` subtree skip → emit batch report. Per-task pipeline is invoked **verbatim** — no new FSM, no step edits. `--auto`/`--agent` are the only flags that cross the orchestrator→pipeline boundary (both into per-task `--vars`).

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

@@ -102,8 +102,7 @@ restricted sandbox - port-binding and `ps` denials produce failures that are not
 project's sandbox notes). Real regressions are *additional* failures.
 
 **3. Finish the work the step abandoned.** Write the sections the killed step would have written
-(`## Solution`, `## Testing`, and the `## Review` P1-P4 table - the L3 `review-priority-table`
-gate will reject the task without it). Use the normal `--section --from-file` contract.
+(`## Solution`, `## Testing`, and the `## Review` P1-P4 table). Use the normal `--section --from-file` contract.
 
 **4. Force-done with an honest reason.**
 
@@ -131,13 +130,13 @@ silently incomplete (H6 shipped at 23/48 that way, with one verdict carrying an
 `acceptanceCriteria` array and still reading PASS). See `ac-style-guide.md` §
 "Verdict AC ↔ feature scenario linkage" for the id forms and evidence vocabulary.
 
-**Parser contract (`spur task verdict` answer lint, 0817 re-verify findings):**
+**Parser contract (`spur task verdict --from-answer`; nothing lints — a malformed row is silently dropped):**
 
 1. The requirement id cell must be the **bare** id — `| R1 | MET | … |`. Suffixes (`R1 (AC1)`) or
-   decoration (`**R1**`) fail the exact-match completeness check (`missing requirement row`).
+   decoration (`**R1**`) do not match the requirement and the row is dropped.
 2. The AC table only opens when the header's **third** cell contains the word "evidence" — use
    `| AC | Status | Evidence Type | Evidence |`. `| AC | Status | Type | Evidence |` silently
-   parses zero AC rows while lint still reports PASS.
+   parses zero AC rows.
 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`). Only the

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

@@ -51,13 +51,11 @@ runs, which have no executor to pin.
 ```
 | WBS | Status | Recovery |
 |-----|--------|--------|
-| 0042 | failed | C6 recovery: /sp:dev-run 0042 (residual report: .spur/run/0042-residual-report.md) |
+| 0042 | failed | /sp:dev-run 0042 |
 | 0050 | not-attempted | /sp:dev-next 0050 |
 ```
 
-A task with a residual report (failing `residual-sweep` check in its verdict artifact) uses the
-C6 recovery line (re-run the pipeline); every other excluded task uses the next-router A-row
-command for its status (F96 task 0952 R2).
+Every excluded task uses the next-router A-row command for its status (task 0952 R2).
 
 The per-task outcome vocabulary: `done` | `failed` | `blocked` | `skipped` | `not-attempted`,
 plus the resume-only `recheck` (stale/mismatched evidence — pipeline re-run), `not-admitted`
@@ -154,10 +152,11 @@ spur workflow summary --rollup <runId>-summary.json --rollup <runId2>-summary.js
 One row per run carrying that run's own Total, a bold total of the sums, and — when run windows overlap —
 a wall-span line from the first start to the last end. No run block reuses a batch-wide window.
 
-## Step 6 — Batch wrap (`--wrap` / `--next`) (F96 task 0952 R1)
+## Step 6 — Batch wrap (`--wrap` / `--wrap-pr` / `--next`) (F96 task 0952 R1)
 
 Run **once for the batch**, after the Step 5 report — never per task (dev-operations.md §runall
 agrees; the old "per task" flag-row wording in dev-runall.md was a contradiction, now fixed).
+`--wrap` and `--wrap-pr` are mutually exclusive; passing both is rejected.
 
 The wrap receives only what it would accept:
 
@@ -202,5 +201,10 @@ spur workflow commit-guard-stage --run "$RUN_ID" -- <files the wrap wrote> \
 git commit -m "chore(wrap): <command> <selector> close-out writes"
 ```
 
+**PR landing (`--wrap-pr`):** Under `--wrap-pr`, the wrap hop and close-out commit execute identically
+on `$BRANCH`, but instead of fast-forward merging into the base ref (`WT-4`), the branch is pushed to
+remote origin and a Pull Request is opened targeting `$BASE_REF` via `gh pr create` (`WT-PR`,
+`execution-worktree-landing.md`).
+
 > **Forbidden:** `git add -A` and `git add .` — here as in every driver commit step. In the
 > worktree batch the same rule rides in the WT-3b block above.

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

@@ -445,8 +445,8 @@ Each pipeline run ends in one of two terminal states:
 `.spur/run/<wbs>-verify-answer.txt` AC table is exactly four columns:
 `| AC | Status | Evidence Type | Evidence |`. The evidence-type token
 (`test`, `command`, `static-ref`, `manual-review`, `llm-judge`, `n/a`, or a `+`
-compound) is isolated in cell 3. A token merged into the evidence cell fails the
-`spur task verdict` answer lint.
+compound) is isolated in cell 3. A token merged into the evidence cell is not parsed as an
+evidence type.
 
 **Driver acceptance (0930 R3).** The trace row and `.spur/run/<wbs>-verdict.json` are accepted as
 terminal evidence only if BOTH hold:
@@ -661,9 +661,8 @@ Before launching a full `spur-check:full`:
    `console.*`), spawn processes via `NodeProcessExecutor` (no `Bun.spawnSync`), get a
    `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>`
-   on touched tasks). Repoint the shifted citations (via `spur task update --section`)
+4. **Doc/TSDoc edits shift `file:line` anchors** cited by other tasks — nothing
+   detects the drift mechanically. Repoint the shifted citations (via `spur task update --section`)
 
 ## AC traceability
 

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

@@ -194,7 +194,7 @@ by this session's judgment:
 Every decision point, its fallback and its consumer are listed in
 [decision-points.md](decision-points.md); read the rows it names instead of re-judging them.
 
-The completion gate reads deterministic evidence only: the review stage's **verdict artifact** (`.spur/run/<wbs>-verdict.json`, derived by `spur task verdict --from-answer`) and the **tree-hash gate receipt** (`.spur/run/<wbs>-check-receipt.json`, reused while the tree is unchanged). The ADR-071 proof chain this paragraph used to describe — proof digests, `verify → record`, review-inside-the-bracket — was deleted by the D65 pipeline rewrite; `record` now runs inside `done`'s onEnter and `verify` merged into `review`. Two grades are read, and only as cross-checks against the answer's own rows: the review answer states one `Confidence: HIGH|MEDIUM|LOW` line (ADR-141) and the review gate recomputes it from the finding dispositions, rejecting a disagreement. Nothing grades the *verifier's* opinion: an open P1–P3 finding blocks `done` on its own, and what protects a hand-driven `task update <wbs> done` is unchanged — the gate must show a PASS receipt for this tree and a recorded review artifact.
+The completion gate reads deterministic evidence only: the review stage's **verdict artifact** (`.spur/run/<wbs>-verdict.json`, derived by `spur task verdict --from-answer`) and the **tree-hash gate receipt** (`.spur/run/<wbs>-check-receipt.json`, reused while the tree is unchanged). The ADR-071 proof chain this paragraph used to describe — proof digests, `verify → record`, review-inside-the-bracket — was deleted by the D65 pipeline rewrite; `record` now runs inside `done`'s onEnter and `verify` merged into `review`. No confidence grade is stated or read anywhere, and nothing lints the answer: the reviewer's `Verdict:` line is the only review authority, so a review with an open P1–P3 finding must carry a non-PASS verdict. Nothing grades the *verifier's* opinion: what protects a hand-driven `task update <wbs> done` is unchanged — the gate must show a PASS receipt for this tree and a recorded review 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/execution-worktree-landing.md

@@ -352,6 +352,40 @@ merge. One contract, no alternatives:
 This is a deliberate choice over auto-migrating DB state: the committed corpus files are the durable
 record and the persisted run artifacts are the evidence record.
 
+### WT-PR — Remote PR landing path (`--wrap-pr`)
+
+When `--wrap-pr` is supplied instead of `--wrap`:
+The batch/task completes verification with no failed task, and Step 6 wrap completes its close-out commit
+directly on `$BRANCH` in the execution tree.
+Instead of checking out `$BASE_REF` and fast-forward merging locally (`WT-4`), the driver pushes the branch
+to the remote repository and opens a GitHub Pull Request:
+
+1. **Preflight checks (fail-closed):**
+   ```bash
+   git remote get-url origin >/dev/null 2>&1 \
+     || { echo "WT-PR halt: git remote 'origin' is not configured" >&2; exit 1; }
+   gh auth status >/dev/null 2>&1 \
+     || { echo "WT-PR halt: gh CLI is not authenticated; run 'gh auth login'" >&2; exit 1; }
+   ```
+2. **Push branch to origin:**
+   ```bash
+   git push -u origin "$BRANCH" \
+     || { echo "WT-PR halt: git push origin $BRANCH failed" >&2; exit 1; }
+   ```
+3. **Open Pull Request via `gh pr create`:**
+   ```bash
+   # Compose PR title and body from task / batch metadata:
+   # For single task (dev-run): title="feat(<wbs>): <title>", body cites verification PASS & Solution.
+   # For batch (dev-runall): title="feat(<feature-id>): <feature-summary>" or "feat(batch): <selector> (<n> tasks)".
+   PR_URL=$(gh pr create --base "$BASE_REF" --head "$BRANCH" --title "$PR_TITLE" --body "$PR_BODY") \
+     || { echo "WT-PR halt: gh pr create failed" >&2; exit 1; }
+   echo "WT-PR: Pull Request opened at $PR_URL"
+   ```
+4. **Marker transition & worktree disposition:**
+   - Record in the worktree marker: `.status = "pr-created" | .prUrl = "$PR_URL"`.
+   - Local base branch (`$BASE_REF`) remains untouched.
+   - The local worktree and branch are retained (or worktree cleaned up in create mode, while preserving the branch on origin).
+
 ### WT-4r — rebasing a retained branch in a linked worktree
 
 When a pre-merge halt is resolved by rebasing the retained branch (rather than landing as-is), two

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

@@ -174,7 +174,8 @@ Two properties are load-bearing and are asserted structurally:
   unconditional single end-of-run gate).
 - **The full tier is still the only `PASS` writer.** Only the integrated run can claim a green
   project gate; the per-task token is `DEFERRED`, and the deferred `gate → review`
-  guard accepts it only while `deferQualityGate = "true"`.
+  guard accepts it only while `deferQualityGate = "true"` (the pipeline default since the
+  incremental gate; pass `"false"` for a full gate on every task).
 
 `--defer-gate` with `--mode sequential` (or omitted `--mode`) is rejected — the flag exists to move
 one full gate from N worktrees to the one place the integrated tree exists. Under `--mode auto` it
@@ -212,6 +213,18 @@ with `--next`, wrap runs **once for the batch** after every task reaches termina
 the batch-once shippable gate `dev-verifyall` uses. Without `--next`, `--wrap` is wrap-without-
 chaining — the single task or batch wraps without advancing the lifecycle. On `dev-find-way` it
 wraps the one resolved ticket inside the worktree before the merge, and is skipped in chart mode.
+Mutually exclusive with `--wrap-pr`.
+
+### `--wrap-pr` — run wrap hop, push branch, and create a Pull Request
+
+**Anchor:** `#flag-wrap-pr`.
+
+After the main step completes, run the wrap hop (learnings, metrics, doc-sync) and close-out commit,
+then push the worktree or dedicated task branch to `origin` and open a Pull Request targeting the base ref using
+`gh pr create`. Mutually exclusive with `--wrap` (specifying both exits 2). Full mode only; requires
+`--worktree` or execution on a dedicated non-base branch (refuses execution directly on `main`).
+On `dev-runall`, PR creation runs **once for the batch** over the `done` subset. When used with
+`--worktree`, leaves the local base branch unmodified and records the PR URL in the worktree marker.
 
 ### `--force` — bypass a named guard
 

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

@@ -0,0 +1,214 @@
+---
+name: downstream-migration
+description: "Migrate an existing Spur project to the current CLI and plugin contract while preserving local config and planning history."
+see_also:
+  - spur-dev
+  - spur-cli
+---
+
+# Downstream migration guide
+
+Use this guide to upgrade an existing project to **Spur 0.4.34** and its matching `sp` plugin.
+For a later release, use the same procedure and read that release's `CHANGELOG.md` entries for
+additional required changes. Do not treat every release as requiring a corpus rewrite.
+
+## 1. Preservation contract
+
+- `.spur/config.yaml`, `docs/features/`, and `docs/tasks*/` are project-owned inputs. Never replace
+  them with package examples or a fresh checkout.
+- Task and feature Markdown is the planning SSOT. The SQLite database is derived; database
+  migrations do not rewrite that Markdown. `docs/features/INDEX.md` and generated task rosters are
+  outputs and must only be regenerated through `spur feature`.
+- Do not run `spur self init --force`, bulk-copy the packaged default configuration or its
+  workflow definitions, or edit generated feature regions directly. Existing project overrides need
+  reconciliation, not replacement.
+- Keep history. Retired commands and old evidence prose can remain in completed task records;
+  they are not instructions to re-run. `spur task migrate-anchors` and `spur task residual` are
+  removed and must not be called.
+- Use CLI-gated writes. Feature acceptance criteria go through `spur feature update --section`;
+  task sections go through `spur task update --section`. No direct corpus edits.
+
+## 2. Preflight and backup
+
+Work from the downstream project root, with a clean Git tree and a named backup ref:
+
+```bash
+cd /path/to/project
+git status --short
+git switch -c chore/spur-0.4.34-migration
+spur --version
+spur self status --json
+spur self migrate --check --json
+spur self exec --list --json
+```
+
+`self migrate --check` is read-only: exit 1 means importer-schema drift and requires the apply
+step below; an absent database is allowed. Keep the current checkout or another backup ref so the
+migration can be reverted. If `.spur/spur.db` exists, stop the project server and copy it to a
+backup location before continuing. Do not back up or restore Markdown by deleting it first.
+
+## 3. Install matching CLI and plugin
+
+Install the CLI, then install the plugin from that same package rather than mixing versions:
+
+```bash
+bun add -g @gobing-ai/superskill @gobing-ai/spur@0.4.34
+superskill install sp --marketplace $(dirname $(bun pm bin -g))/install/global/node_modules/@gobing-ai/spur
+spur --version
+spur agent doctor --json
+```
+
+Confirm the reported CLI version is the intended release. `agent doctor` checks executor usability;
+it does not prove authentication or provider quota. The Electron shell is retired: use
+`spur self serve` for the Board.
+
+## 4. Migrate `.spur/config.yaml`
+
+Preserve project-specific values and make only the applicable edits:
+
+| Existing state | Required action |
+| --- | --- |
+| `.spur/config.json` still supplies project config | Move the project-owned values into `.spur/config.yaml`; do not keep a second config authority. |
+| `version` is absent or an integer | Use the YAML string `version: "1.1"`. |
+| `agent.team` or `.spur/fleet.json` declares a roster | Move it to **project-layer** `agent.fleet`. Keep executor profiles in the global layer, not in the fleet. A leftover old carrier fails loading by design. |
+| `workflow.hitlDecisionMaker` | Rename the section to `workflows.hitlDecisionMaker`. |
+| Bun project with no `builder` block | No change: `builder.preset: bun` supplies the existing commands. |
+| Non-Bun project, or custom commands required | Set `builder.preset: none` and bind `builder.actions` (`lint`, `test`, `check`, and any required `*-changed` actions) to the project's real commands. |
+| `tasks.folders` and `tasks.active` | Preserve folder names, labels, `baseCounter`, and the active folder. Archived folders remain readable history, not a bulk-migration target. |
+| `features.dir` | Preserve the existing feature tree and hierarchical IDs; do not renumber features or scenario titles. |
+
+Example non-Bun binding only (replace placeholders with real commands):
+
+```yaml
+builder:
+  preset: none
+  actions:
+    lint: <project-lint-command>
+    test: <project-test-command>
+    check: [lint, test]
+```
+
+Validate resolution without running the actions:
+
+```bash
+spur self exec --list --json
+spur self exec check --dry-run --json
+spur self status --json
+```
+
+Do not copy `config/config.example.yaml` over the project file. That example documents available
+keys; it is not a migration target.
+
+## 5. Reconcile project workflow overrides
+
+The bundled definitions are not drop-in replacements for project overrides. Compare with
+`spur workflow list --json` and validate every project-owned definition with
+`spur workflow validate <path>`.
+
+For 0.4.34 specifically:
+
+- Task execution is D65: `precheck → implement[⇄escalate] → gate[⇄remediate] → review → done`.
+  There are no separate `test`/`test-recheck`, `approve`, `verify`, or `record` states. Completion
+  evidence is a tree-hash gate receipt plus the reviewer verdict; the old proof-digest chain,
+  answer lint, answer-confidence fields, residual sweep, and verdict replay are gone.
+- `deferQualityGate: "true"` makes the incremental gate the per-task default. The full project
+  gate runs once per feature or batch; do not remove that integrated-tree check.
+- Feature verification is owned by `feature-lifecycle`: entering `verifying` runs
+  `spur feature verify`. The separate `feature-verification.yaml` workflow is removed, and
+  `wrapup-pipeline` no longer changes feature status.
+- Planning uses `idea-pipeline`. The legacy planning, docs, feature-development, duplicate task,
+  PR-review, and wayfinder workflow definitions are removed. Route former callers to `idea-pipeline`,
+  `task-pipeline`, `feature-lifecycle`,
+  `spur builder pr-check|pr-open|pr-review|pr-status`, or the wayfinder skill as appropriate.
+- Project-layer `task-lifecycle.yaml` and `feature-lifecycle.yaml` overrides must be re-synced for
+  current guards and the non-terminal `deprecated` state. The status addition itself needs no
+  corpus migration.
+
+## 6. Migrate and validate the planning corpus
+
+Run only the operations that apply to the project's actual state:
+
+```bash
+# A17 normalization only, not a general schema migrator — preview first.
+spur task migrate --dry-run --json
+# If the preview shows wanted A17 changes and no conflicts:
+spur task migrate --json
+
+# Structural checks and optional mechanical repairs; review their diffs afterward.
+spur task check --fix --json
+spur feature check --fix --json
+
+# Required final validation (warnings are reported separately from errors).
+spur task check --corpus --json
+spur feature check --json
+```
+
+`task migrate` normalizes the active task folder (or an explicit `--folder`). It is not a
+feature-migration or a reason to rewrite archived folders. `task check --fix` and
+`feature check --fix` repair structure, not semantics or Gherkin conversion.
+
+Feature acceptance criteria must use valid BDD with a `Feature:` declaration and `Scenario:`
+blocks. Raw legacy bullets need a deliberate conversion through:
+
+```bash
+spur feature update <id> --section 'Acceptance Criteria' --from-file /tmp/<id>-ac.md
+```
+
+Preserve each scenario's R-number and meaning. Use `@deprecated` and a Notes entry for a scenario
+that is historical rather than a current requirement. If validation exposes an old hook or
+lifecycle claim, check the current ADR/design owner instead of editing it blindly.
+
+Preview lifecycle derivation before applying it, then regenerate derived projections only after
+the corpus checks are understood:
+
+```bash
+spur feature sync --all --dry-run --json
+spur feature sync --all --json
+spur feature refresh --all --json
+```
+
+A missing, stale, running, or failed feature-verification receipt is unfinished work, not something
+to hide by forcing a transition. Run `spur feature verify <id>` after the applicable full project
+gate passes. Ordinary warnings can remain visible; do not manufacture a clean report by editing
+history or suppressing findings.
+
+## 7. Final acceptance and rollback
+
+Run the project gate and inspect the migration diff:
+
+```bash
+spur self exec check
+spur self exec check-feature   # when closing a feature; full project gate
+spur workflow list --json
+spur task check --corpus --json
+spur feature check --json
+git diff --check
+git status --short
+```
+
+`check-feature` is the full project gate for feature closure, not a replacement for the default
+incremental task gate. If an action is unbound, fix `builder.actions` instead of substituting a
+command from another repository.
+
+Stop on the first material error. Restore from the backup ref rather than running init or
+bulk-deleting files:
+
+```bash
+git diff <backup-ref> -- .spur/config.yaml docs/features docs/tasks*
+git restore --source=<backup-ref> -- .spur/config.yaml docs/features docs/tasks*
+git status --short
+```
+
+Review new untracked files separately; `git restore` does not remove them. Reinstall the previous
+CLI/plugin version and restore the database backup only after stopping the server. Keep failure
+logs and durable evidence under `.spur/memory/`; `.spur/run/` is disposable scratch, not a rollback
+authority.
+
+## Agent handoff
+
+Give the downstream agent this boundary verbatim:
+
+> Follow `plugins/sp/skills/spur-dev/references/migration-guide.md`. Preserve `.spur/config.yaml`,
+> `docs/features/`, and `docs/tasks*/`. Use dry runs and CLI-gated writes. Do not run `init --force`,
+> replace project workflows wholesale, rewrite historical corpus, or hide verification findings.
+> Stop on the first material error and report it with its evidence.