@gobing-ai/spur 0.4.10 → 0.4.12

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

@@ -159,13 +159,13 @@ must not be changed without updating the backing skill.
 - **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 reads `task-pipeline.yaml` and drives its actions/guards in the host session — 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.
 - **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 → test → review → approve(HITL) → verify → record → done. Interactive omit/inline uses [inline-pipeline-driver.md](inline-pipeline-driver.md) (host-controlled; eligible stages may use a native subagent); explicit/headless executor selection invokes `spur workflow run task-pipeline.yaml --vars '{"wbs":"<wbs>"}'` (with `profile: auto` when `--auto`). Both monitor/surface HITL and preserve the YAML gates. `--next` never changes this mode.
+  - **`full`** (default): Drive the full pipeline — precheck → implement → test → review → approve(HITL) → verify → record → done. 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.
   - **`implement`** (explicit `--mode implement` only): Execute only the implement step. Read the task's `## Requirements` / `## Design` / `## Plan`, write the code that satisfies them, author the `## Solution` change-map section (file:line + what/why per changed file) via `spur task update <wbs> --section Solution --from-file`. This is the implement step the pipeline calls — it is NOT the pipeline driver. With `--next`: on success, 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` and `## Review` sections MUST carry a `⚠️ PARTIAL` marker naming the deferred part and the follow-up WBS — see `plugins/sp/commands/dev-run.md` → "Section ownership".
-- **Delegation:** `Skill(skill="sp:spur-dev", args="run-inline $ARGUMENTS")` for interactive full omit/inline (resolved-inline semantics, task 0687); `Skill(skill="sp:spur-dev", args="run $ARGUMENTS")` for explicit/headless full mode; `Skill(skill="sp:code-implementation", args="$ARGUMENTS")` for implement mode.
+- **Delegation:** `Skill(skill="sp:spur-dev", args="run $ARGUMENTS")` for both full-mode paths (the `executor` var picks host session vs child process); `Skill(skill="sp:code-implementation", args="$ARGUMENTS")` for implement mode.
 
 #### Execution summary
 
-Produced by the run's own close (1146 R1), not by a trailing step: `spur workflow inline close` writes
+Produced by the run's own terminal close (1146 R1), not by a trailing step: the close writes
 `.spur/run/<runId>-summary.md` + `.json` and reports `summaryFile` in its stdout JSON. The driver's only
 job is to print that file's contents under an `### Execution summary` heading, and to pass `--no-summary`
 through to `inline close`. `--no-summary` is an `inline close` flag: anywhere else it is a usage error.
@@ -551,7 +551,7 @@ gate commands, pending questions and approval requirements.>
   Ties lean design — when the signal is ambiguous, `system-design` runs. Task Design defaults on
   unless `--skip-design`. Plan path uses the same package contract (no `--design` force flag).
 
-- **Operator gates:** every pause is one `AskUserQuestion` [decision brief](decision-brief.md) — recommended option first; see the gate table in `commands/dev-idea.md` and the `hitl.confirm` rule in [inline-pipeline-driver.md](inline-pipeline-driver.md).
+- **Operator gates:** every pause is one `AskUserQuestion` [decision brief](decision-brief.md) — recommended option first; see the gate table in `commands/dev-idea.md` and the `hitl.confirm` rule in [execution-workflow.md](execution-workflow.md).
 
 ### 17. refactor
 
@@ -568,7 +568,7 @@ gate commands, pending questions and approval requirements.>
 These define their procedure directly in the command file. No `Skill()` delegation — the command
 is the procedure. The backing is a combination of git CLI, `spur` CLI, and agent reasoning.
 
-**Gate ownership.** A project quality gate (`bun run gate`, `spur-check`, lint, typecheck, tests,
+**Gate ownership.** A project quality gate (`spur self exec autofix|check|lint`, typecheck, tests,
 rule runs) runs only where an operation's own contract names it: the pipeline `test` hop
 (`run`/`runall`), `fixall`, `gtd`, `fixgha`, `unit`, and the `--check <cmd>` loops. The scribe
 operations — `changelog`, `gitmsg`, `handover`, `job-dump` — produce text or a commit, not code, so
@@ -595,7 +595,7 @@ host instructions does not add one. An opt-in gate is explicit: `gitmsg --check
      - **Defect precision decides what must be fixed.** The check is precise once a bullet is classified as a claim: an annotation missing its anchor is unambiguously wrong and blocks emitting. A summary broader than its evidence is reworded to what the anchor shows. Which bullets *are* claims is the heuristic half — resolve it by this step's rule, and for a genuinely borderline bullet say so in the bullet's body rather than annotating or skipping it silently.
   8. Self-check before emitting: every short hash in `<since>..<until>` appears exactly once, and every claim bullet carries exactly one `<!-- src: … -->` comment holding exactly one anchor — no unannotated claim bullets, no duplicate annotations. Fix any miss or duplicate; do not report a verdict.
   9. Reply in at most three lines: the range, bullet counts per category plus the verified-claim count, and the output target.
-- **Invariants:** Bullets are derived from `git log` only; the claim-verification pass (step 7) adds evidence from commit diffs, the working tree, and official docs. No quality gates — no `bun run gate`/lint/typecheck/test/`spur-check`/rule runs, and no edits beyond the one inserted section (its verification comments included). The file is left uncommitted.
+- **Invariants:** Bullets are derived from `git log` only; the claim-verification pass (step 7) adds evidence from commit diffs, the working tree, and official docs. No quality gates — no `spur self exec autofix|check|lint` and no typecheck, test or rule run, and no edits beyond the one inserted section (its verification comments included). The file is left uncommitted.
 
 ### 9. gitmsg
 
@@ -678,7 +678,7 @@ host instructions does not add one. An opt-in gate is explicit: `gitmsg --check
 
      Hooks stay enabled; a failing hook stops the run with its output — never `--no-verify`.
 
-- **Invariants:** Git and POSIX shell only — no helper script, no temp file. At most two Bash calls: gather, then (only when committing) commit — three with `--check`. No quality gate (`bun run gate`, lint, typecheck, tests, `spur-check`) unless `--check` names one. With neither `--commit` nor `--squash`, never runs `git commit` — message only. Neither flag commits across a secret hit, and `--commit` never splits across a partial staging. Without `--all` the change set is the index, so plain `/sp:dev-gitmsg` keeps pre-commit semantics; only `--all` reaches unstaged and untracked files, and only a committing run stages them. The empty-index widen is read-only and always announced — a committing run never widens its own scope. An explicit `--scope <path>` always bounds the change set, with or without `--all`. One bounded, context-free capture per run — never a second, wider read.
+- **Invariants:** Git and POSIX shell only — no helper script, no temp file. At most two Bash calls: gather, then (only when committing) commit — three with `--check`. No quality gate (`spur self exec autofix|check|lint`, typecheck, tests) unless `--check` names one. With neither `--commit` nor `--squash`, never runs `git commit` — message only. Neither flag commits across a secret hit, and `--commit` never splits across a partial staging. Without `--all` the change set is the index, so plain `/sp:dev-gitmsg` keeps pre-commit semantics; only `--all` reaches unstaged and untracked files, and only a committing run stages them. The empty-index widen is read-only and always announced — a committing run never widens its own scope. An explicit `--scope <path>` always bounds the change set, with or without `--all`. One bounded, context-free capture per run — never a second, wider read.
 
 ### 10. fixall
 
@@ -686,16 +686,16 @@ host instructions does not add one. An opt-in gate is explicit: `gitmsg --check
 - **Inputs:** `--scope <path>` (default: entire working tree) — limits fixes to a file or directory. `--gate-log <path>` (R3, task 0482) — before fixing, read this captured validation-run log and start at the `file:line` anchors its findings name, rather than re-deriving the failure from a fresh gate run. `--findings <anchors>` (R3, task 0482) — space-separated `file:line` anchors already extracted from that log by the `test` hop; when present these ARE the failing set, so fix them in order and do not run the gate to discover what broke.
 - **Backing:** `inline` — lint + test fix loop.
 - **Behavior:** 0. **Start at the anchors, never at a discovery run.** If `--findings <anchors>` is given, that space-separated `file:line` list IS the failing set — open those locations first, in order, and fix them; do not run the gate to find out what broke. If only `--gate-log <path>` is given, read that log first and identify the failing findings (lint/test errors with their `file:line` anchors) before running the loop — the captured log is the authoritative source. Either way the first action of this hop is a read, not a gate run (R3, task 0482).
-  1. Inspect the project's formatter command, then settle formatter-only diffs. Without `--scope`, use the project formatter (here `bun run format`). With `--scope`, use a formatter invocation whose only path operands are inside the selected scope — for Biome, `bunx biome check --write "$SCOPE"`. Never append a path to a script already containing `.`: `biome check . --write <path>` still writes across the repository. Preserve quoted paths and apply the same scope to every later formatting pass. If no scoped formatter is available, report that limitation and leave out-of-scope files untouched. Here `bun run lint` checks formatting without rewriting it and also runs typecheck; formatting errors fail that check.
-  2. Run the project's read-only lint/type check (here `bun run lint`). Collect all errors. A repository-wide check may report outside-scope errors; report them without widening the authorized fix scope.
+  1. Inspect the project's formatter command, then settle formatter-only diffs. Without `--scope`, use the project formatter (here `spur self exec format`). With `--scope`, use a formatter invocation whose only path operands are inside the selected scope — for Biome, `bunx biome check --write "$SCOPE"`. Never append a path to a script already containing `.`: `biome check . --write <path>` still writes across the repository. Preserve quoted paths and apply the same scope to every later formatting pass. If no scoped formatter is available, report that limitation and leave out-of-scope files untouched. Here `spur self exec lint` checks formatting without rewriting it and also runs typecheck; formatting errors fail that check.
+  2. Run the project's read-only lint/type check (here `spur self exec lint`). Collect all errors. A repository-wide check may report outside-scope errors; report them without widening the authorized fix scope.
   3. **Surface-change sweep (before any fix).** If the failing set is a **surface/parity** change — CLI noun/verb/flag surface, reference-file structure, or a renamed/moved symbol — do one upfront `rg` sweep across ALL test dirs + docs for stale references to the changed symbols (e.g. `rg -l "<old-noun>|<old-file>.md|Tier C" apps/*/tests plugins/sp/tests plugins/sp/skills docs`), and fix every in-scope pinned test/docs file in that sweep; report outside-scope matches without editing them. A surface change is pinned in **multiple independent test files** (each with its own hardcoded noun→reference map); discovering them one-by-one via full-suite probes is the dominant waste — each wave costs a suite run and a fresh edit loop (task 0436 R2 lesson). One sweep produces the complete edit set upfront.
   4. If lint is clean, skip to step 6.
   5. **Lint fix loop:** for each in-scope error, diagnose the root cause and apply the smallest fix. **Use targeted probes to verify each fix** (`bunx tsc --noEmit` on the affected package, `bunx biome check <file>`) — do NOT re-run the full gate after every batch. Loop until lint is green, or report outside-scope blockers without editing them.
   6. For standalone execution, run `bun run test` and collect all failures. With `--gate-log`, use its failing set and targeted tests instead of running the full suite here.
   7. If tests are green, proceed to the applicable standalone confirmation or pipeline handoff below.
   8. **Test fix loop:** for each in-scope failure, diagnose (test bug vs implementation bug), apply the fix, re-run the **failing test only** (`bun test <file> --test-name-pattern "<test>"`). Report outside-scope blockers without editing them. Do NOT re-run the full suite per fix — it is the dominant loop cost (task 0436 R2).
-  9. **Confirming run — standalone invocation only (at most once).** After all fixes, repeat the scope-safe formatting invocation from step 1, then run the selected validation command **at most once** to confirm (here the default project gate is `bun run spur-check`). If it passes, the hop is done. **Skip this step entirely when `--gate-log` is set** (see step 10) — under the pipeline nothing consumes its verdict.
-  10. **Pipeline-awareness (R4, task 0483; confirming run dropped 2026-08-31).** `--gate-log` is set only by the pipeline's `test-fix` hop, so treat it as the pipeline signal. There, `test-recheck` runs the full `${vars.qualityGateCmd}` gate immediately after this hop returns — that is the **deciding** run, the only one that writes PASS to `.spur/run/<wbs>-test-gate.status`. A confirming run inside this hop decides nothing and costs a second full gate (~105 s here) to answer a question `test-recheck` is about to answer anyway. So under `--gate-log`: **run no full gate at all.** Your self-check is what step 8 already gives you — the failing tests you re-ran individually — plus **one `bun run lint`** (~7 s: Biome + typecheck) to catch type or lint breakage your fixes introduced. Then return and let `test-recheck` judge. `test-recheck` opens with the same cheap `${vars.gateProbeCmd}` probe, so a still-red tree is caught in seconds rather than by a full suite. Historical anti-pattern this replaces: 0482 ran the gate 3× plus a standalone `bun run test`, and `test-recheck` then ran it a 5th time.
+  9. **Confirming run — standalone invocation only (at most once).** After all fixes, repeat the scope-safe formatting invocation from step 1, then run the selected validation command **at most once** to confirm (here the default project gate is `spur self exec check`). If it passes, the hop is done. **Skip this step entirely when `--gate-log` is set** (see step 10) — under the pipeline nothing consumes its verdict.
+  10. **Pipeline-awareness (R4, task 0483; confirming run dropped 2026-08-31).** `--gate-log` is set only by the pipeline's `test-fix` hop, so treat it as the pipeline signal. There, `test-recheck` runs the full `${vars.qualityGateCmd}` gate immediately after this hop returns — that is the **deciding** run, the only one that writes PASS to `.spur/run/<wbs>-test-gate.status`. A confirming run inside this hop decides nothing and costs a second full gate (~105 s here) to answer a question `test-recheck` is about to answer anyway. So under `--gate-log`: **run no full gate at all.** Your self-check is what step 8 already gives you — the failing tests you re-ran individually — plus **one `spur self exec lint`** (~7 s: Biome + typecheck) to catch type or lint breakage your fixes introduced. Then return and let `test-recheck` judge. `test-recheck` opens with the same cheap `${vars.gateProbeCmd}` probe, so a still-red tree is caught in seconds rather than by a full suite. Historical anti-pattern this replaces: 0482 ran the gate 3× plus a standalone `bun run test`, and `test-recheck` then ran it a 5th time.
   11. Report: list what was fixed (file + one-line summary per fix). If any error could not be resolved, report it explicitly — do not suppress.
 - **Invariants:** Never bypass with `--no-verify`, `--force`, or new `biome-ignore`/`eslint-disable` suppressions. Never skip or `.skip` a test to make the suite green. Fix the root cause, not the symptom. Here lint checks formatting and types; it does not prove that the full test gate passed. Keep every write inside `--scope`. **Never re-run the full gate more than once per confirming pass** (R4) — use targeted probes during the fix loops and let the pipeline's `test-recheck` state be the deciding run.
 - **MANDATORY Exit Condition — standalone only.** At step 9, execute the following once; do not add another confirming run:

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

@@ -45,7 +45,8 @@ run-id) or you walked it manually (name the gate you checked).
 Threshold is by **change type**, not priority: a task is high-stakes if it touches code, tests, or
 shared infrastructure. Priority (P1/P2) is advisory - it does not by itself force raw paste on a
 pure doc/markdown edit. For high-stakes tasks, paste the **raw tail output** of every verification
-gate that applies - not a one-line "green" summary. Include:
+gate that applies - not a one-line "green" summary. Include the tails of spur-new's own gate
+scripts (any other project: the same actions through `spur self exec lint` / `test`):
 
 - `bun run lint` tail (last 20 lines minimum)
 - `bun run test` tail (last 20 lines minimum)
@@ -92,8 +93,8 @@ spur workflow trace <run-id>           # confirm the terminal state
 has verified the tree. You must:
 
 ```bash
-bun run lint
-bun run test
+spur self exec lint
+spur self exec test
 ```
 
 Both must pass before you go further. Establish the environmental baseline first if you are in a

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

@@ -85,14 +85,14 @@ batch can never destroy its own evidence. Reuse mode retains its operator-owned
 persists the Step 5 report under the invoking tree; the reused tree's `.spur/run/` remains the live
 copy while that tree lives on. The per-run provenance — the worktree DB's run/action rows and the
 `.spur/memory/runs/<runId>.md` + `.state.json` records — is persisted mechanically by WT-4a's
-`spur workflow inline persist-out --from <worktree> [--task-file <merged-task>]...` call,
+`spur workflow persist-out --from <worktree> [--task-file <merged-task>]...` call,
 not by hand.
 
 **Stage records are worktree-local too (0948 R9, E7 Finding 5; persisted by 0975 R1).** Each task's
 own per-stage run record (`.spur/memory/runs/<runId>.md` + `.state.json`) and the worktree DB's run rows are
 written inside the worktree and **are removed with it** in create mode — the E7 batch lost exactly
 this evidence. Copying them out is no longer a manual audit-time duty: WT-4a (create-mode block
-below) runs `spur workflow inline persist-out --from "$WT_PATH"` **before** WT-4b holder cleanup,
+below) runs `spur workflow persist-out --from "$WT_PATH"` **before** WT-4b holder cleanup,
 which copies the run/action/phase/transition/workflow-state rows and both record files into the
 invoking tree.
 
@@ -106,7 +106,7 @@ obligation; neither do root-qualified paths (`knowledge-kit/.spur/run/…`, `/ab
 which cite another project's evidence — cite foreign run artifacts that way, never bare. A citation missing in BOTH trees, a divergent cited file (never overwritten — reconcile
 by hand), an unreadable task file, or more than 64 distinct cited files fails the pass → WT-5.
 
-**Durable planes ride it too (E71).** Persist-out copies canonical task verdicts, feature run/latest receipts, nested run artifacts and owned sessions before teardown. Artifact and task-run-link rows are exported with run rows, and stored path references are redirected to the invoking tree. Conflicting or unreadable **owned** retained evidence refuses teardown. A divergent copy of evidence a forwarded task does **not** own (its WBS is not a forwarded task's and its receipt `runId` is not a worktree run row) is `foreign-divergent` (1139 R5): it is skipped, reported as `evidenceSkipped[{name, reason:'foreign-divergent', newer:'invoking'|'worktree'}]`, and the invoking-tree copy is never overwritten — another task's newer verdict can no longer block this batch's teardown. A divergent **owned** file still fails with `durable evidence conflicts`. `spur workflow inline persist-check` accepts the same foreign-divergent set from the success JSON and does not recompute it.
+**Durable planes ride it too (E71).** Persist-out copies canonical task verdicts, feature run/latest receipts, nested run artifacts and owned sessions before teardown. Artifact and task-run-link rows are exported with run rows, and stored path references are redirected to the invoking tree. Conflicting or unreadable **owned** retained evidence refuses teardown. A divergent copy of evidence a forwarded task does **not** own (its WBS is not a forwarded task's and its receipt `runId` is not a worktree run row) is `foreign-divergent` (1139 R5): it is skipped, reported as `evidenceSkipped[{name, reason:'foreign-divergent', newer:'invoking'|'worktree'}]`, and the invoking-tree copy is never overwritten — another task's newer verdict can no longer block this batch's teardown. A divergent **owned** file still fails with `durable evidence conflicts`. `spur workflow persist-check` accepts the same foreign-divergent set from the success JSON and does not recompute it.
 
 **Owned evidence rides it too (1012).** With at least one `--task-file`, persist-out also treats as
 copy obligations the worktree's `.spur/run/` direct children named `<wbs>-…` (the WBS is each
@@ -124,7 +124,7 @@ pass before the invoking tree is written → WT-5. Without `--task-file` nothing
 The shapes are pinned (task 0975 R1; `record-missing`, citation behavior per 0984; `evidenceSkipped` per 1139 R5): idempotent on re-persist;
 success exits 0 printing
 `{"ok":true,"persisted":<n>,"skipped":[{"id":<run-id>,"reason":"id-exists"|"external-key-conflict"|"record-conflict:<file>"|"record-missing:<file>"|"cited-directory:<name>"|"cited-symlink:<name>"|"cited-non-file:<name>"}],"evidenceSkipped":[{"name":<file>,"reason":"foreign-divergent","newer":"invoking"|"worktree"}]}`
-(`evidenceSkipped` is omitted when empty; the same object is written to `<invoking-tree>/.spur/run/persist-out.json` for `spur workflow inline persist-check` to read)
+(`evidenceSkipped` is omitted when empty; the same object is written to `<invoking-tree>/.spur/run/persist-out.json` for `spur workflow persist-check` to read)
 — an `external-key-conflict` skip leaves the target run unchanged **and fails the pass (1049)**: the delegate exits 1 printing `{"ok":false,"error":…}` naming the skipped source run ids, because that (workflow, external key) identity already belongs to a different receiving run — the batch was not persisted, so reconcile the source worktree by hand (it stays the provenance owner of record) before any teardown: auditable reconciliation names the original archived DB snapshot and the skipped source run identities, verifies the archive by file hash and by merged-commit ancestry of the source branch, and treats any residual deletion as explicit operator-authorized cleanup under the strict canonical evidence rules above. Task 1149 R1 grades a terminal duplicate lifecycle row (`task-lifecycle`/`feature-lifecycle`) as `external-key-conflict-bookkeeping` (non-fatal), so guarded transitions driven inside the worktree do not block teardown; the receiving lifecycle row is reconciled automatically during persist-out. An `id-exists` replay repairs missing owned artifacts and task links without duplicating them. A
 `record-conflict:<file>` never overwrites a divergent invoking-tree record and causes the delegate to exit 1, retaining the worktree. Before reconciling one by hand, check **what** the invoking record is: when the run closed `done` inside a linked worktree the owning tree holds that run's **WT-0 landing obligation** (`landing: required branch=… path=… base=…`, see [execution-worktree-landing.md § WT-0](execution-worktree-landing.md#wt-0--markerless-worktree-runs)) — a 3-line record that is *not* a stub of the worktree's stage narrative, so copying the worktree record over it destroys the very obligation a later merge must rewrite. The reconciliation is therefore: discharge the obligation in place (`landing: merged <sha>` or `landing: retained`), and preserve the worktree narrative beside it (e.g. `<runId>.worktree-provenance.md`) rather than in place of it. A
 `record-missing:<file>` skip is a known `task-lifecycle`/`feature-lifecycle` row with no record file

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

@@ -52,8 +52,8 @@ that a flat FSM cannot express.
 The active batch orchestrator owns the spaces **between** task runs: resolve+freeze the set,
 topo-sort, run each task's pipeline, inspect terminal state, decide continue/halt, and emit the
 report. It does not redefine individual steps. Interactive sequential omit/inline delegates each
-ready WBS to [inline-pipeline-driver.md](inline-pipeline-driver.md); explicit/parallel/headless paths
-delegate to the workflow engine and `vars.agent` resolution.
+ready WBS to the same engine loop as every other path (host executor by default); explicit/parallel/
+headless paths delegate to the workflow engine and `vars.agent` resolution.
 
 ## Step 1 — Selector resolution (R1)
 
@@ -316,7 +316,8 @@ per-task letter is ever hand-assigned.
 4. **When a task ends:** mark the task's letter (and its published digits) with the task's terminal
    outcome — `done` renders completed; `failed`/`skipped`/`blocked` render pending + ` [<outcome>]`
    per the frozen status mapping in
-   [inline-pipeline-driver.md](inline-pipeline-driver.md) § Host todo update styles.
+   [cross-cutting.md](cross-cutting.md#shared-startup-contract-task-0814-r1r3r4r6r7r8) § Publish the
+   generated plan (per-item and full-list host update styles).
 
 ## Step 3 — The driver loop (R3, R4)
 
@@ -338,7 +339,8 @@ for wbs in plan:                                       # default sequential mode
         report += preflight-skip(wbs, preflight); continue
     visible plan (§2.7): letter in_progress + task-children digits at start; letter ← outcome at end
     run: if interactive sequential omit/inline:
-             inline-pipeline-driver(task-pipeline.yaml, wbs)
+             spur workflow run task-pipeline.yaml --vars <vars with executor=host> --json
+             perform the returned work item; spur workflow continue <run-id> --answer-text <receipt>
          else:
              spur workflow run task-pipeline.yaml --vars <vars> --async --json
              follow trace until terminal    # spur workflow trace "$RUN" --follow --timeout 600000
@@ -371,9 +373,9 @@ record the reason.
 ### 3.1 Per-task execution reuses the pipeline verbatim (R4)
 
 Each task runs through the **standard single-task pipeline** — `task-pipeline.yaml`
-— with no new FSM and no step edits. Interactive sequential omit/inline invokes the host
-[inline pipeline driver](inline-pipeline-driver.md), which interprets that file; explicit/parallel
-execution invokes the workflow engine. The batch loop inspects the result and never redefines a
+— with no new FSM and no step edits. Interactive sequential omit/inline and explicit/parallel
+execution both invoke the workflow engine on that file; only the executor differs (host session vs
+child process). The batch loop inspects the result and never redefines a
 step.
 
 **Explicit/parallel path: launch async, then one bounded follow** (per execution-workflow.md §"Step 2"): a pipeline with
@@ -606,15 +608,15 @@ command doc so it does not read as a bug.
 
 The cheap rule gates fail fast when run first — the full-gate run is dominated by the ~65 s test
 suite, so a gate run that dies at `test-post-check` or `corpus-check` wastes most of its wall time.
-Before launching a full `spur-check-new`:
+Before launching a full `spur-check:full`:
 
-1. **Run the static checks first** — `bun run lint` (biome over the whole tree plus every workspace
+1. **Run the static checks first** — `spur self exec lint` (biome over the whole tree plus every workspace
    typecheck). They fail in ~20 s and are the two defects that most often kill a full launch: a
    formatting miss in a touched test file, or a generated declaration surface that no longer lists a
    new export. Measured 2026-10-12: two consecutive `spur-check` launches died here and each spent
    its whole wall time before reaching the suite.
-2. **Then the two rule gates** — `bun run test-pre-check` (43 rules: `no-console-output`,
-   `no-direct-process-spawn`, `cli-*`, `require-corresponding-test`) and `bun run test-post-check`
+2. **Then the two rule gates** — `spur self exec rules-pre` (43 rules: `no-console-output`,
+   `no-direct-process-spawn`, `cli-*`, `require-corresponding-test`) and `spur self exec rules-post`
    (`every-export-has-tsdoc`, `coverage-gate`). They catch boundary/TSDoc violations in seconds.
    Two `coverage-gate` facts change how you call post-check: it **fails closed when
    `.coverage/lcov.info` is absent**, which is the normal state of a fresh worktree, so run it after

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

@@ -46,14 +46,15 @@ one thing and yields, so the **pipeline (not the agent) owns the loop**.
 | Stage | Operation | Defined in |
 | ------- | ----------- | ------------ |
 | `implement` | `/sp:dev-run --mode implement <wbs>` — write the code that satisfies the task; author `## Solution`. | [dev-operations.md §4 run](dev-operations.md) → `sp:code-implementation` |
-| `test` → (`test-fix` ↔ `test-recheck`) → `review` \| `failed` | **Project quality gate** (not `/sp:dev-unit`). Soft shell probe of `${vars.qualityGateCmd}` (default `bun run spur-check`) — green path pays **one** full gate run. On FAIL: bounded `/sp:dev-fixall` loop (`qualityGateMaxFixAttempts`, default 2) with soft recheck; exhausted attempts route to pipeline `failed`. `/sp:dev-unit` remains **coverage gap-fill** (router C3/C5 / standalone). | [dev-operations.md §10 fixall](dev-operations.md); unit op still §1 |
+| `test` → (`test-fix` ↔ `test-recheck`) → `review` \| `failed` | **Project quality gate** (not `/sp:dev-unit`). Soft shell probe of `${vars.qualityGateCmd}` (default `spur self exec check`) — green path pays **one** full gate run. On FAIL: bounded `/sp:dev-fixall` loop (`qualityGateMaxFixAttempts`, default 2) with soft recheck; exhausted attempts route to pipeline `failed`. `/sp:dev-unit` remains **coverage gap-fill** (router C3/C5 / standalone). | [dev-operations.md §10 fixall](dev-operations.md); unit op still §1 |
 | `review` | `/sp:dev-review --tasks <wbs>` — SECUA-framework review of the diff. | [dev-operations.md §2 review](dev-operations.md) |
 | `verify` | `sp:code-verification` — requirements traceability + verdict. | [dev-operations.md §3 verify](dev-operations.md) |
 
-Interactive omit/`inline` executes these model stages through the
-[inline pipeline driver](inline-pipeline-driver.md) in the host session and records stage/session
-provenance. The host is the controller; eligible `agent.run` stages may dispatch once to a native
-subagent (task 0508), with host fallback and no post-dispatch replay — see the driver reference.
+Interactive omit/`inline` executes these model stages in the host session through the engine loop:
+the engine owns every guard and transition, the host performs each returned work item and records
+its receipt. Eligible `agent.run` stages may dispatch once to a native subagent (task 0508), with
+host fallback and no post-dispatch replay — see
+[cross-cutting.md](cross-cutting.md#inline-default-execution-surface).
 `--agent <name|auto>`, parallel batches, and headless workflow invocation select
 the existing subprocess actions. Direct invocations of the same dev operations remain inline by
 default. See the [inline-default execution-surface contract](cross-cutting.md#inline-default-execution-surface).
@@ -106,9 +107,9 @@ and merge-or-retain after the run reports. The lifecycle is
 applied to a batch of one. Rejected with `--mode implement`.
 
 **Choose the surface before execution.** In an interactive `/sp:dev-run --mode full` invocation,
-omit/`--agent inline` selects the [inline pipeline driver](inline-pipeline-driver.md). Read the YAML
-at invocation time, allocate the inline run id/session provenance, record `task run-link`, and walk
-its actions/guards in declaration order. Do not call `spur workflow run` on this path. `--agent auto`,
+omit/`--agent inline` selects the host executor. Start the run with `spur workflow run <file>
+--vars '{"executor":"host",…}'` and advance it with `spur workflow continue <run-id> --answer-text
+<receipt>`; the engine walks the YAML's actions/guards, this session never re-executes them. `--agent auto`,
 a named executor, an explicit `vars.agent`/`vars.implementAgent`, or a headless caller selects the
 workflow subprocess path below. Never fall back silently from inline to `agent.default`.
 
@@ -171,13 +172,7 @@ Two branches reach the bounded repair hop, not one (session finding after 1088):
   an on-graph, bounded path to remediation instead of dead-ending the run, and the fix re-enters
   quality → review → verify on a freshly captured proof digest.
 
-The completion gate reads deterministic evidence only (F511, task 1207): both `verify → record` and
-`record → done` check the proof digests in `.spur/run/<wbs>-verdict.json` — verdict PASS, matching
-run/definition digests, review stage completed. No confidence is read, stated or acknowledged; the
-asserted `Confidence:` line and the `ackLowConfidence` operator var were retired because a model
-that can write a PASS can write `HIGH` — the grade verified nothing. What protects a hand-driven
-`task update <wbs> done` is unchanged: the digests must match the run's captured proof, and the
-review stage must actually be completed in the artifact.
+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.
 
 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.
@@ -325,8 +320,8 @@ the partial work still in the working tree. The failure output names the partial
 1. **Recognise.** `.spur/memory/runs/<runId>/artifacts/<runId>-implement-partial.md` exists, the run reported `exited
    with code 3`, the task is at `todo`. The artifact's `git diff --stat` section is the partial
    work inventory.
-2. **Establish green from the partial files.** `bun run format` then `bun run lint` + `bun
-   test` (or the affected packages). Fix mechanical formatting/type fallout first; the partial
+2. **Establish green from the partial files.** `spur self exec format` then `spur self exec lint` + `spur
+   self exec test` (or the affected packages). Fix mechanical formatting/type fallout first; the partial
    tree is the baseline, not a code review target.
 3. **Resume the remaining requirements against that tree.** Re-run the implement step with the
    partial diff as explicit context — hand the continuation agent `git diff` (the partial
@@ -338,11 +333,25 @@ the partial work still in the working tree. The failure output names the partial
    [`done-housekeeping.md`](done-housekeeping.md) F6 — it carries the provenance obligations
    (honest `done_reason`, verdict regeneration).
 
-   **Inline path (task 0727).** There is no `<runId>-implement-partial.md` artifact on the inline
-   driver path — it is written only by the subprocess `agent.run` action. The inline equivalent is
-   the dispatch-timeout contract in [`inline-pipeline-driver.md`](inline-pipeline-driver.md):
-   resume from the partial tree, never restart the stage inline; the partial working tree is the
-   recovery input.
+   **Host-executor path (task 0727).** There is no `<runId>-implement-partial.md` artifact on the
+   host path — it is written only by the subprocess `agent.run` action. A host-stage timeout is a
+   recorded stage failure: resume from the partial tree, never restart the stage inline; the partial
+   working tree is the recovery input.
+
+**3a. Verify dispatch floor (task 1039).** A small, clean diff does not need a separate verify
+session: when the diff is below the floor, `verify` runs host-inline in the current session and
+records exactly one log line —
+
+    stage verify executed inline in session <session-id> (below dispatch floor: diffstat files <f> lines <n>)
+
+The floor is read from the recorded diffstat artifact under `.spur/run/`; the filter that decides
+it is
+
+    ([.files, .insertions, .deletions] | all(type == "number")) and .files <= 3 and (.insertions + .deletions) <= 60 and .sensitive == false
+
+A diffstat that is missing, malformed, or names a sensitive path is never below the floor: the
+floor is an optimisation, so an unreadable artifact dispatches the normal verify executor. (This
+contract moved here from the retired inline driver reference, D65 1242.)
 
 **3. Match the executor to the size (task 0487 R3).** Size and executor capability are one
 decision, not two. **≥ 6 requirements or ≥ 9 Plan items → a `reviewer`-role executor (the

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

@@ -116,7 +116,7 @@ WT_PATH="$(cd "../<worktree-dir>" && pwd)"   # hoisted: needed by WT-4a AND WT-4
 # automatically reconciles each forwarded terminal task's receiving lifecycle row in
 # the invoking tree (finalizing any stale in-flight or interrupted row left from the
 # task's creation), so a manual DB edit is never required:
-spur workflow inline persist-out --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
+spur workflow persist-out --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
   || { echo "halt: worktree run-record persist-out failed - worktree retained (WT-5)" >&2; write_marker retained; exit 1; }
 #
 # WT-4b — bounded CWD-holder cleanup (task 0720 R1). $WT_PATH above is the EXACT
@@ -155,9 +155,9 @@ fi                                           #   NO prune/remove/branch delete
 # worktree while it still owns evidence absent from (or divergent from) the invoking tree —
 # the D63 landing skipped persist-out and silently lost verdicts + receipts. WBSes ride the
 # same TASK_FILE_ARGS resolved for WT-4a; run ids are a separate `--run-id <id>` per run and
-# belong to THIS check only — `spur workflow inline persist-out` accepts `--from` and
+# belong to THIS check only — `spur workflow persist-out` accepts `--from` and
 # `--task-file` alone and exits 2 on `--run-id` (1089 driver note).
-spur workflow inline persist-check --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
+spur workflow persist-check --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
   || { echo "WT-4 halt: worktree evidence would be abandoned - persist-out missing or stale (WT-5)" >&2; write_marker retained; exit 1; }
 git worktree remove "../<worktree-dir>" \
   || { echo "WT-4 halt: worktree remove failed after landed merge $BATCH_TIP" >&2; write_marker retained; exit 1; }
@@ -408,7 +408,7 @@ conflicts itself. Other halt causes (task failure, HITL pause) keep the hint as
 #     (a test, a hook, a tool invocation) discards MERGE_HEAD silently. The failure is invisible
 #     until the history is read — it produced a single-parent commit in run ada5a36c (task 1090),
 #     which then needed an extra empty ancestry merge to repair. A cheap probe could not
-#     reproduce it (MERGE_HEAD survived `bun run lint`, the rule preset and a test-file subset),
+#     reproduce it (MERGE_HEAD survived `spur self exec lint` (recorded then as the raw lint script), the rule preset and a test-file subset),
 #     so the cross-command dependency is removed rather than diagnosed.
 git checkout <base-ref> && git merge --no-ff -m "<prepared message>" <branch>
 
@@ -443,7 +443,7 @@ git checkout <base-ref> && git merge --no-ff -m "<prepared message>" <branch>
 #     ancestry).
 
 # 6. persist evidence out (WT-4a), then WT-4b/4c cleanup, and set the marker to merged
-spur workflow inline persist-out --from <worktree> --task-file …
+spur workflow persist-out --from <worktree> --task-file …
 ```
 
 The report reuses the [`--next` chain contract](flag-glossary.md#--next-chain-contract) halt-report

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

@@ -79,8 +79,8 @@ inherits no cwd from the previous call, so "the loop runs with the worktree as p
 bootstrap convenience, never a carried guarantee. Every host command boundary in this lifecycle —
 corpus reads/writes, the WT-3b commit, WT-4's merge and evidence persistence, the WT-4a
 persist-out — re-selects its intended tree within the same call via the canonical per-call pin
-protocol ([inline-pipeline-driver.md](inline-pipeline-driver.md) § "Per-call execution-tree
-pin"): `cd --` to the quoted absolute tree, verify `pwd -P` against the recorded physical tree,
+protocol ([execution-batch.md](execution-batch.md) § "Per-call execution-tree pin"):
+`cd --` to the quoted absolute tree, verify `pwd -P` against the recorded physical tree,
 verify Git top-level and expected branch, then execute the already-resolved Spur invocation. The
 identity is consumed, not re-derived: it is the WT-3 marker's confirmed `path` + `branch` (or the
 resolved worktree's physical path + checked-out branch in reuse mode). The one deliberate tree
@@ -269,8 +269,8 @@ the tree's own source:
     cd "<worktree>" && bun apps/cli/src/index.ts task check <wbs> --json
 
 Run that as a per-call pin subshell (task 1058) — `cd --` plus the `pwd -P` / git-top-level /
-branch identity checks of the canonical protocol (inline-pipeline-driver.md § "Per-call
-execution-tree pin") — rather than relying on a persistent `cd` between host tool calls.
+branch identity checks of the canonical protocol (execution-batch.md § "Per-call execution-tree
+pin") — rather than relying on a persistent `cd` between host tool calls.
 
 Confirm isolation by making a distinctive change in the worktree and checking that
 the command reflects it.

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

@@ -209,8 +209,9 @@ wraps the one resolved ticket inside the worktree before the merge, and is skipp
 **Anchor:** `#flag-force`.
 
 Bypass a specific named guard that would otherwise stop the command (e.g. a shippable check on
-`dev-verify`/`dev-verifyall`). Named, not global: the command documentation states which guard is
-forced. Never bypasses lifecycle status transitions or irreversible HITL gates.
+`dev-verify`/`dev-verifyall`, or the per-HEAD review dedupe on `dev-pr-review`). Named, not global:
+the command documentation states which guard is forced. Never bypasses lifecycle status transitions
+or irreversible HITL gates.
 
 ### `--feature <id>` — scope the operation to a feature
 

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

@@ -17,7 +17,7 @@ catch it (the CLI catches schema violations, not intent errors).
 Run each checklist as an actual command sequence, not a mental confirmation:
 
 1. Read the checklist for the gate you are about to enter.
-2. Run each verification command (grep, `spur task check`, `bun run lint`, etc.).
+2. Run each verification command (grep, `spur task check`, `spur self exec lint`, etc.).
 3. If any checkbox fails: stop, fix, re-run. Do not enter the gate.
 4. Only when every checkbox passes: enter the gate (run the CLI verb or trigger the workflow state).
 
@@ -89,7 +89,7 @@ Entered before `task-pipeline.yaml` `review` state dispatches `sp:code-verificat
 - [ ] The implementation matches the task's `## Plan` checklist (every checked item maps to a code/test/doc change).
 - [ ] `git status` shows only changes traceable to this task's Plan (no drive-by edits).
 - [ ] Check receipt current: `spur task gate <wbs> status` reports `reuse: true` for
-      `.spur/run/<wbs>-check-receipt.json` at the current digest; run `bun run spur-check` only
+      `.spur/run/<wbs>-check-receipt.json` at the current digest; run `spur self exec check` only
       when it reports stale or missing (0940 — never re-run the full chain on a reusable receipt).
 - [ ] New `biome-ignore` / `eslint-disable` suppressions: none, or each is justified inline.
 - [ ] No new `console.*` in scripts (use a project logger if one exists).
@@ -176,9 +176,9 @@ transition to `done`.
 
 > **Finding-rule discipline (ADR-108).** When checker policy changes, run focused tests and one explicit unsuppressed `bun run corpus-check` audit; record/reconcile essential failures without waivers (T10). Ordinary corpus commit prep checks changed tasks/features and their required linked evidence, not the corpus (T11). The baseline and regenerators remain deleted; tests are not a substitute for the explicit policy-change audit.
 >
-> **Transition-shim discipline (`transition-shim-check`, task 0541 / ADR-058).** Wired as an early step of `spur-check` / `spur-check-new` (second, after `link-check` and before `lint`) so a shim violation fails in ~0.3 s rather than after the test run. Two-sided against `config/transition-shims.json`: an `@transition-shim(<id>)` marker with no manifest entry fails as a **new unregistered shim**, **and** a listed entry whose marker is gone from source fails as a **stale entry**. Emptying the manifest is the definition of the agent-role transition being complete. A removal condition must be objectively checkable against the repository. Shapes: `docs/04_DESIGN.md` §2.5.
+> **Transition-shim discipline (`transition-shim-check`, task 0541 / ADR-058).** Wired as an early step of `spur-check-feature` (second, after `link-check`) so a shim violation fails in ~0.3 s rather than after the test run. Two-sided against `config/transition-shims.json`: an `@transition-shim(<id>)` marker with no manifest entry fails as a **new unregistered shim**, **and** a listed entry whose marker is gone from source fails as a **stale entry**. Emptying the manifest is the definition of the agent-role transition being complete. A removal condition must be objectively checkable against the repository. Shapes: `docs/04_DESIGN.md` §2.5.
 
-> **Sandbox test baseline (`bun run test` / `spur-check`).** In the restricted Bash sandbox
+> **Sandbox test baseline (`bun run test` / `spur-check`).** In spur-new's restricted Bash sandbox
 > `bun run spur-check` exits **1 regardless of code health**: ~24 tests bind real ports and the
 > sandbox denies `listen`, so they fail environmentally. They cluster in seven suites — `spur
 > projects CLI`, `startServer`, `createServerContext`, `healthModule`, `rpc client`,

package/schemas/spur-config.schema.json

@@ -343,8 +343,26 @@
         },
         "builder": {
             "type": "object",
-            "description": "Builder noun configuration. Currently hosts the release plumbing knobs for `spur builder bump-ver` / `drop-tags`; every field defaults to the built-in release convention, so an absent builder section keeps default behavior.",
+            "description": "Builder noun configuration. Hosts the release plumbing knobs for `spur builder bump-ver` / `drop-tags` and the SDLC action binding (`preset` + `actions`, ADR-139) that binds the reserved action vocabulary to this project's commands. Every field defaults to the built-in behavior, so an absent builder section keeps default behavior.",
             "properties": {
+                "preset": {
+                    "type": "string",
+                    "enum": ["bun", "none"],
+                    "default": "bun",
+                    "description": "Stack preset for the SDLC action vocabulary. `bun` (default) binds every reserved action to the legacy bun scripts, so a bun project needs no config change; `none` binds only the stack-neutral `spur rule run` presets (rules-pre, rules-post) and leaves every other undeclared action unbound."
+                },
+                "actions": {
+                    "type": "object",
+                    "default": {},
+                    "propertyNames": { "pattern": "^[a-z][a-z0-9-]*$" },
+                    "additionalProperties": {
+                        "oneOf": [
+                            { "type": "string", "minLength": 1, "pattern": "\\S" },
+                            { "type": "array", "minItems": 1, "items": { "type": "string", "minLength": 1 } }
+                        ]
+                    },
+                    "description": "Action name -> one shell command, or a list of action names (composite, executed in order, fail-fast). A declared entry replaces the preset binding whole. Reserved names (closed in packages/config): build, dev, clean, format, autofix, lint, typecheck, test, test-full, test-heavy, rules-pre, rules-post, check, check-full, check-feature, lint-changed, typecheck-changed, test-changed; other names are custom (exec-only). Placeholders are allowed only in the scoped actions, each with its own set: lint-changed {files}, typecheck-changed {workspace}, test-changed {workspace} {paths}; and each substituted item is shell-quoted."
+                },
                 "bump-ver": {
                     "type": "object",
                     "description": "Release knobs for bump-ver/drop-tags. Defaults: -v separator, publish.yml workflow, chore(release) commit, gh run list limit 5.",