@gobing-ai/spur 0.4.33 → 0.4.34

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.
 

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