@gobing-ai/spur 0.4.11 → 0.4.13

package/plugins/sp/skills/parallel-execution/references/dispatch-surface.md

@@ -102,13 +102,13 @@ non-sandboxed shell, or a workspace that owns the storage path). The upstream fi
 pi-coding-agent's storage-path resolution; it is out of scope here and recorded as motivating
 evidence only.
 
-## Composition with the inline pipeline driver (task 0508)
+## Composition with the host executor (task 0508)
 
-The interactive inline driver (`cross-cutting.md` § Inline-default execution surface) applies this
+The interactive host executor (`cross-cutting.md` § Inline-default execution surface) applies this
 reference's default — native subagent first — to sequential `task-pipeline.yaml` `agent.run`
 stages. Eligibility there is the same observable test (pure-slash action, non-interactive state,
-native subagent with shared-worktree capability); the inline driver remains the authority for
-provenance, artifact validation, and no-replay guarantees. This reference stays the authority for
+native subagent with shared-worktree capability); the engine remains the authority for provenance,
+artifact validation, and no-replay guarantees. This reference stays the authority for
 the native-subagent versus `spur agent run` choice everywhere else.
 
 ## Fork dispatch on hosts that support it (2026-09-15 subagent-dispatch evaluation)
@@ -131,9 +131,9 @@ Three constraints keep fork honest:
   adversarial panels — must NOT fork; a worker that inherits the author's reasoning grades its own
   homework. Fork is for continuity, cold dispatch is for independence.
 
-The inline driver's resume-over-re-dispatch rule
-([inline-pipeline-driver.md](../../spur-dev/references/inline-pipeline-driver.md)) is the same
-instinct one level down: reuse a warm worker for continuation, dispatch fresh for judgment.
+The engine's resume-over-re-dispatch rule (a paused run resumes with
+`spur workflow continue` instead of re-dispatching its stage) is the same instinct one level down:
+reuse a warm worker for continuation, dispatch fresh for judgment.
 
 ## Role propagation across fan-out (task 0551, feature I4)
 

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

@@ -53,10 +53,10 @@ Every batch item's hour estimate MUST also travel into the batch JSON as the ite
 frontmatter, and it can be corrected later with `spur task update <wbs> --estimate-hours <n>`. The
 estimate already exists at this point (the hour knobs were just applied above); writing it down
 costs nothing and makes the size decision visible to later stages instead of re-derived. Its
-primary consumer is the inline pipeline driver's dispatch floor
-([inline-pipeline-driver.md](../../spur-dev/references/inline-pipeline-driver.md)): a task at or
-below 1 hour executes its stages host-inline rather than paying a subagent dispatch. An estimate
-left unwritten forgoes that gate — the task dispatches like any large one.
+primary consumer is the host session's dispatch floor
+([execution-batch.md](../../spur-dev/references/execution-batch.md)): a task at or below 1 hour
+executes its stages in the host rather than paying a subagent dispatch. An estimate left unwritten
+forgoes that gate — the task dispatches like any large one.
 
 ### Worked example: H8's own first decomposition
 

package/plugins/sp/skills/spur-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spur-check
-description: 'Two-tier check primitive for the sp pipeline: light (changed-scope biome, per-workspace typecheck, related tests) during development; full (bun run spur-check) once at the quality boundary. Reads/writes fingerprint-bound check receipts (.spur/run/<wbs>-check-receipt.json) and reuses a PASS full receipt only at the same proof digest.'
+description: 'Two-tier check primitive for the sp pipeline: light (changed-scope biome, per-workspace typecheck, related tests) during development; full (`spur self exec check`) once at the quality boundary. Reads/writes fingerprint-bound check receipts (.spur/run/<wbs>-check-receipt.json) and reuses a PASS full receipt only at the same proof digest.'
 license: Apache-2.0
 version: 1.0.0
 metadata:
@@ -34,7 +34,7 @@ gate writes a fingerprint-bound receipt that downstream stages read instead of r
 | Tier | Mode | When | Scope |
 | --- | --- | --- | --- |
 | `light` | `spur task gate <wbs> light` | after each implement/fix edit | `bunx biome check` on the changed files (`git diff --name-only HEAD` + untracked), `bun run typecheck` per touched workspace, and related tests (`<ws>/src/**/x.ts` → `<ws>/tests/**/x.test.ts` filename mapping) run via `cd <ws> && bun test …` — never from the repo root, whose bunfig preload does not apply inside the workspace |
-| `full` | `spur task gate <wbs> run` | once at the task quality boundary (`test`) | today's chain: `bun run lint` + `bun run test-pre-check` + `bun run test` + `bun run test-post-check` (=`bun run spur-check`), with bounded findings, SQLite-busy retry, and the `recheck` probe |
+| `full` | `spur task gate <wbs> run` | once at the task quality boundary (`test`) | today's chain: `spur self exec lint` + `spur self exec rules-pre` + `spur self exec test` + `spur self exec rules-post` (=`spur self exec check`), with bounded findings, SQLite-busy retry, and the `recheck` probe |
 
 Exit contract: `run` and `recheck` return 0 on PASS and 1 on FAIL; `deferred` returns 0 on
 DEFERRED and 1 on FAIL. `light` and `status` return 0; invalid usage returns 2. The pipeline
@@ -58,10 +58,10 @@ that soft shell wrapper does not change the standalone CLI contract.
 }
 ```
 
-- `inputDigest` is the shared `ProofInputFingerprint` (task markdown + git tree of tracked
-  sources). The plugin never computes it — the pipeline captures it with the `proof.fingerprint`
-  action into `env.proofDigest` (ADR-124: no second fingerprint, no `@gobing-ai/*` import);
-  standalone callers use `spur workflow inline fingerprint`.
+- `inputDigest` is the git tree the gate computes for itself (`captureGateGitTree`: `git read-tree
+  HEAD`, `git add -A` excluding `docs/tasks*` and `docs/features*`, `git write-tree` on a throwaway
+  index). The plugin never computes it and no caller supplies it — ADR-140 retired the
+  `proofDigest`/`--proof-digest` chain, so a corpus edit cannot invalidate a code PASS.
 - `run` and `recheck` write full-tier receipts; only a PASS at the current digest is reusable. Without a digest, `run` writes no receipt and says
   so in the gate log. The gate executes `qualityGateCmd` as one unit, so the full receipt carries a
   single `test` row for the whole chain; `lint`, `typecheck`, `test-pre-check`,
@@ -76,7 +76,7 @@ Check `status` mode before re-running a gate. The gate ships inside the CLI (no
 resolve):
 
 ```bash
-spur task gate <wbs> status --proof-digest "$proofDigest" --no-logo   # final stdout line: {"reuse":…,"reason":…}
+spur task gate <wbs> status --no-logo   # final stdout line: {"reuse":…,"reason":…}
 ```
 
 `reuse: true` only when the receipt is `status: PASS`, `tier: full`, and `inputDigest` equals the
@@ -105,7 +105,8 @@ preserved by construction. `recheck` stays the no-progress probe path for fix lo
 ## Gotchas
 
 1. **Keep gate logic in the CLI/application owner** — plugin skills invoke `spur task gate`;
-   they do not restore a script or bundle. The digest arrives via `--proof-digest` or `env.proofDigest`.
+   they do not restore a script or bundle. The gate computes its own tree identity; there is no
+   `--proof-digest` flag and no `env.proofDigest` input to supply.
 2. **Never run light tests from the repo root** — the workspace `bunfig.toml` preload (coverage,
    thresholds) only applies inside the workspace; `cd <ws> && bun test …` is the contract.
 3. **Light is a filter, not a boundary** — unmapped files (root-level scripts, non-src layouts)

package/plugins/sp/skills/spur-cli/SKILL.md

@@ -47,7 +47,7 @@ Pick the noun, read its reference. Each Tier A and Tier B reference owns that no
 | **Tier A** | **builder** | Release/PR plumbing: `bump-ver` (including read-only `--check`), `drop-tags`, `publish`, the four flat PR verbs (`pr-status`, `pr-check`, `pr-open`, `pr-review`), and the read-only `show-branches` topology report | [references/builder.md](references/builder.md) |
 | **Tier B** | **agent** | Coding-agent execution surface: run prompts via detected/named agents, list agent specs (incl. `agent.fleet` members), start/stop supervised processes, fleet `report`/`join`/`leave`/`wait`/`trace`, readiness check | [references/agent.md](references/agent.md) |
 | **Tier B** | **message** | Durable inter-agent messaging: send, inbox, reply, watch | [references/message.md](references/message.md) |
-| **Tier B** | **self** | Self-management verbs: scaffold (`init`), database maintenance (`maintain`), schema migrations (`migrate`), local web server (`serve`), status overview (`status`); `self init` runs post-scaffold validation probes & layout classification | [references/self.md](references/self.md) |
+| **Tier B** | **self** | Self-management verbs: scaffold (`init`), project SDLC actions (`exec`), database maintenance (`maintain`), schema migrations (`migrate`), local web server (`serve`), status overview (`status`); `self init` runs post-scaffold validation probes & layout classification | [references/self.md](references/self.md) |
 | **Tier B** | **history** | Import agent histories, aggregate forensic artifacts, render reports, and run the checkpoint-resumed daily pipeline | [references/history.md](references/history.md) |
 | **Tier B** | **projects** | Manage the local multi-project registry and start/stop project servers | [references/projects.md](references/projects.md) |
 | **Tier B** | **decision** | Decision-catalog transport: list visible decisions, show a served contract, run a decision to a served outcome, audit catalog health | [references/decision.md](references/decision.md) |
@@ -145,7 +145,7 @@ and spreading it; full contract in `docs/04_DESIGN.md` §1.0.1.
   `inbox`, `reply`, `watch`).
 - **[references/decision.md](references/decision.md)** - decision catalog (`list`, `show`, `run`,
   `status`); offline by default via the built-in `typesafe` maker.
-- **[references/self.md](references/self.md)** - `spur self init|maintain|migrate|serve|status` CLI verbs
+- **[references/self.md](references/self.md)** - `spur self init|exec|maintain|migrate|serve|status` CLI verbs
   (the five legacy top-level nouns remain hidden aliases). `self init` runs post-scaffold init
   validation (Phase 1.5/1.6 probes).
 - **[references/history.md](references/history.md)** - history import, forensic artifact analysis,

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

@@ -1,22 +1,26 @@
 ---
 name: spur-cli-self
-description: "spur-cli noun reference for `spur self`: self-management verbs — scaffold (`init`), database maintenance (`maintain`), schema migrations (`migrate`), local web server (`serve`), and status overview (`status`). Each verb mounts the same command builder as its legacy top-level noun, which remains a hidden alias over the identical command."
+description: "spur-cli noun reference for `spur self`: self-management verbs — SDLC action runner (`exec`), scaffold (`init`), database maintenance (`maintain`), schema migrations (`migrate`), local web server (`serve`), and status overview (`status`). The five legacy verbs (`init`, `maintain`, `migrate`, `serve`, `status`) each mount the same command builder as their legacy top-level noun, which remains a hidden alias; `exec` has no top-level alias."
 see_also:
   - spur-cli
 ---
 
 # spur self - self-management verbs
 
-`spur self` hosts the self-management verbs. Each verb is the canonical path for a command
+`spur self` hosts the self-management verbs. Five of them are the canonical path for a command
 that also remains registered as a legacy top-level **hidden alias** (`spur init`, `spur maintain`, `spur migrate`,
 `spur serve`, `spur status`) so existing scripts, workflow YAML, and habits keep working unchanged.
 Both paths share the same command builder: identical flags, output, and exit codes. The legacy
 top-level forms are omitted from `spur --help`, leaving `self` as the visible surface.
 
+`exec` is the exception: it exists only as `spur self exec` — there is no `spur exec` top-level
+alias (`spur exec <action>` is an unknown command), so nothing depends on a legacy path.
+
 ## Verb map
 
 | Verb | Purpose | Key flags |
 | ---- | ------- | --------- |
+| `exec` | Run (or list) a project SDLC action bound in `builder.actions` / `builder.preset` | `--list` `--dry-run` `--json` |
 | `init` | Scaffold a new Spur project in the current directory | `--name <name>` `--force` `--minimal` `--adopt-global-config` `--json` |
 | `maintain` | Run database maintenance: PRAGMA optimize, WAL truncation, optional VACUUM | `--vacuum` `--json` |
 | `migrate` | Apply CLI-owned schema migrations (or `--check` the importer schema) | `--check` `--json` |
@@ -28,6 +32,37 @@ top-level forms are omitted from `spur --help`, leaving `self` as the visible su
 **[serve.md](serve.md)** owns the `serve` verb (server flags and dry-probe semantics). `migrate`
 has no reference of its own and is documented inline below.
 
+## `self exec` - run a project SDLC action
+
+```bash
+spur self exec build                   # run the resolved command in the project root
+spur self exec lint -- --fix           # extra args: shell-quoted and appended to a string action
+spur self exec --list                  # every reserved + declared action, its source and command
+spur self exec --list --json           # machine-readable action inventory
+spur self exec test --dry-run          # print the resolved command(s), run nothing
+spur self exec check -- --fail-on error  # trailing args reach the command (composites refuse them: exit 2)
+```
+
+Runs one action resolved from the project's `builder` config in `.spur/config.yaml`:
+`builder.actions.<action>` first, then the active `builder.preset` (`bun` or `none`), then the
+stack-neutral default. The command runs through `sh -c` **in the project root** with
+stdout/stderr inherited (stdin is not forwarded) and `SPUR_ACTION=<action>` exported to the child;
+spur exits with the child's exit code.
+A composite action runs its steps in order, echoes `▶ <step>` per step on stderr, and stops at the
+first non-zero exit.
+
+| Exit | When |
+| ---- | ---- |
+| child's code | the action (or the failing composite step) exited non-zero |
+| `2` | action unbound, composite given arguments, or no action and no `--list` |
+| `1` | unknown option (commander usage error, before the verb runs) |
+
+`--list --json` rows are `{ name, reserved, source: config|preset|default|unbound, command | steps }`; an
+`unbound` row carries neither `command` nor `steps`, so branch on `source`;
+`--dry-run --json` prints `[{ name, command }]`, one object per resolved step, and runs nothing.
+`--json` without `--list` or `--dry-run` prints a final `{ action, steps: [{ name, exitCode, durationMs }], exitCode }`
+after the streaming output. Full surface: `docs/design/sdlc-actions.md` §3.3.
+
 ## `self init` - scaffold a Spur project
 
 ```bash

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

@@ -81,7 +81,7 @@ Prose-only reviews and rows containing only empty/placeholder cells do not pass.
     }
   ],
   "checks": [
-    { "name": "lint-clean", "status": "pass", "evidence": "bun run lint: exit 0" }
+    { "name": "lint-clean", "status": "pass", "evidence": "spur self exec lint: exit 0" }
   ],
   "source": "spur-task-verdict"
 }

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

@@ -79,7 +79,7 @@ frontmatter scalar.
 - **Frontmatter** (`--feature <id>`, `--priority <p>`): sets the scalar frontmatter field on an
   existing task — the only post-create path, allow-listed to `feature_id` / `parent_wbs` / `priority`.
 - **Estimate** (`--estimate-hours <n>`): sets the `estimate_hours` frontmatter field (positive number) —
-  the decomposition size estimate the inline pipeline driver reads.
+  the decomposition size estimate the host-session dispatch floor reads.
 - **`--provenance-bypass`** (pair with `--force-done` and `--reason`): records an audited
   provenance-bypass link when no pipeline run exists. Replaces the `SPUR_PROVENANCE_OVERRIDE` env var.
 - **AC controls** (`--ac-altitude <graduating|task-local>`, `--ac-numbering task-local`) — independent
@@ -356,7 +356,7 @@ column to distinguish AC rows from requirement rows:
 | AC | Status | Evidence Type | Evidence |
 |----|--------|---------------|----------|
 | AC-1 | MET | test    | `tests/foo.test.ts:12` |
-| AC-2 | MET | command | `bun run lint` exit 0 |
+| AC-2 | MET | command | `spur self exec lint` exit 0 |
 | AC-3 | N/A | n/a     | non-behavioral — doc-only |
 ```
 
@@ -465,7 +465,7 @@ spur task resolve  <file-path> [--strict] [--folder] [--json]
 spur task path     <wbs> [--folder] [--json]
 spur task run-link <wbs> [--source <src>] [--run-id <id>] [--json]
 spur task scaffold-tests <wbs> [--file <path>] [--folder] [--json]
-spur task gate     <wbs> <run|recheck|light|deferred|status> [--cmd <c>] [--probe-cmd <c>] [--proof-digest <d>] [--run-id <id>]
+spur task gate     <wbs> <run|recheck|light|deferred|status> [--cmd <c>] [--probe-cmd <c>] [--run-id <id>]
 spur task residual <wbs> <scan|review-gate|fold|settle|report> [--root <dir>] [--tmp-dir <dir>] [--folder]
 spur task diffstat <wbs>
 ```

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

@@ -60,7 +60,7 @@ re-reading or re-tokenizing the task.
 | `run-link <wbs>` | Record pipeline run provenance link for task | `--source <src>` `--run-id <id>` `--json` |
 | `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 fingerprint-bound receipts (see `sp:spur-check`) | `--cmd <c>` `--probe-cmd <c>` `--proof-digest <d>` `--run-id <id>` |
+| `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`) | — |
 

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

@@ -119,7 +119,8 @@ The skill's logic divides by **whether the LLM adds value**:
 | `summary` | `spur workflow summary` (CLI) | `--progress <[label=]file>`… \| `--rollup <[label=]file>`… `[--transcript] [--since] [--markdown]` | Measured execution summary (per-stage time, wait, tool calls, tokens, actor split) or the batch roll-up `/sp:dev-runall` prints. `n/a` exit 0 without a transcript; exit 2 on usage or unreadable input |
 | `profile` | `spur workflow profile` (CLI) | `<workflow> [--last n] [--window sec] [--spur-bin cmd] [--json]` | Read-only per-node step profile from `spur workflow trace` with the ADR-115 cache-window flags, for `sp:spur-doctor`. Exit 1 when a trace read fails |
 | `cost` | `spur workflow cost` (CLI) | `[--workflow <name>]… [--by-state] [--include-bookkeeping] [--since <date>] [--budget <file>] [--measured-file <json>] [--json]` | Real terminal non-dry run measurements, or a budget result; unknown measurements stay null. Budget failures exit 1 |
-| `inline` | `spur workflow inline <op>` (CLI) | `begin`, `fingerprint`, `node-enter`, `action`, `actions`, `close`, `decide`, `persist-out`, `persist-check`, `attribution`, `dispatch-failure` | The host-inline driver's run lifecycle transport ([inline-pipeline-driver.md](../../spur-dev/references/inline-pipeline-driver.md)); exit 0 ok / 1 fail closed / 2 usage |
+| `persist-out` | `spur workflow persist-out` (CLI) | `--from <worktree> [--task-file <path>]…` | WT-4 landing: copy a worktree's run rows, two-file records and cited/owned evidence into the invoking tree before teardown; exit 1 fail closed (retain the worktree) |
+| `persist-check` | `spur workflow persist-check` (CLI) | `--from <worktree> [--task-file <path>]… [--run-id <id>]… [--root <tree>] [--success-json <path>]` | WT-4 pre-removal assertion that the worktree owns no unpersisted durable evidence; exit 0 ok / 1 blocked or divergent / 2 usage |
 | `commit-guard` | `spur workflow commit-guard <op>` (CLI) | `start\|stage\|check --run <id> [--base <sha>] [-- <paths…>]` | Stages only paths this run wrote; exit 2 when a listed path is refused, 3 on unmerged/conflict-marked targets |
 | `add` | agent procedure | `"<nl-description>" [--kind <state-machine\|transition-flow>] [--file <path>]` | **Mode chosen (confirmed)** → first reconciled against existing workflows (extend an existing flow rather than duplicate) → YAML authored in real schema shape → **validated AND dry-run** (reaches the expected terminal state) → [add](workflows/operations.md#add) |
 | `refine` | agent procedure | `<workflow-file> [--intent "<goal>"] [--dry-run]` | Smallest change meeting the intent, re-validated and re-dry-run; `--dry-run` emits a diff only → [refine](workflows/operations.md#refine) |
@@ -255,7 +256,7 @@ suppression snapshot, so every finding is reported — none are suppressed.
 
 **Advisory-only posture (binding):** findings never justify blocking a run, failing a gate, or
 editing a pipeline that is currently executing. The advisory never changes `validate`'s exit status,
-never blocks `workflow run`, and is not part of `spur-check` / `spur-check-new`. Treat a finding as
+never blocks `workflow run`, and is not part of `spur-check`. Treat a finding as
 a to-be-enhanced note for the workflow's owner — surface it in your report, apply the fix only when
 the operator accepts it, and never hot-edit a running workflow's shell in place.
 
@@ -274,7 +275,8 @@ spur workflow progress <run-id> [--json]
 spur workflow summary  (--progress <[label=]file>... | --rollup <[label=]file>...) [--transcript <path>] [--since <iso>] [--markdown]
 spur workflow profile  <workflow> [--last <n>] [--window <sec>] [--spur-bin <cmd>] [--json]
 spur workflow cost     [--workflow <name>]... [--by-state] [--include-bookkeeping] [--since <YYYY-MM-DD>] [--budget <file>] [--measured-file <json>] [--json]
-spur workflow inline   <op> [options]
+spur workflow persist-out   --from <worktree> [--task-file <path>]...
+spur workflow persist-check --from <worktree> [--task-file <path>]... [--run-id <id>]... [--root <tree>]
 spur workflow commit-guard <op> [options]
 ```
 

package/plugins/sp/skills/spur-dev/SKILL.md

@@ -98,12 +98,12 @@ run. Resume with `spur workflow continue --answer-text <answer>` — the guard a
 `maxEscalations` (default 2) bounds the loop; exhausted or empty answer → `failed`. Implement only.
 
 Full procedure: **[references/execution-workflow.md](references/execution-workflow.md)**.
-Host-session procedure: **[references/inline-pipeline-driver.md](references/inline-pipeline-driver.md)**.
+Host executor: `spur workflow run` with `executor=host` → work item → `spur workflow continue`.
 
 ## Bootstrap reads
 
 Read this `SKILL.md` plus your mode's files below before the first dispatch; everything else under
-`references/` is on demand, and the per-task delegate `inline-pipeline-driver.md` is read at dispatch
+`references/` is on demand; the per-task procedure lives in `execution-workflow.md`/`execution-batch.md`
 (budgets: `plugins/sp/tests/bootstrap-budget.test.ts`, task 1128).
 
 - sequential-inline: `references/execution-batch.md`
@@ -131,7 +131,7 @@ reference for the half you're operating; do not duplicate its content here.
 | Refine                     | planning  | `spur task update --section`                                                              | [planning-workflow.md](references/planning-workflow.md)                                                                                 |
 | Batch refine               | planning  | `sp:dev-refineall` → per-task `refine`                                                    | [dev-operations.md](references/dev-operations.md) § refineall · [planning-workflow.md](references/planning-workflow.md)                 |
 | Task selection             | execution | `spur task list`                                                                          | [execution-workflow.md](references/execution-workflow.md)                                                                               |
-| Pipeline run               | execution | inline YAML driver or `spur workflow run`                                                 | [execution-workflow.md](references/execution-workflow.md) · [inline-pipeline-driver.md](references/inline-pipeline-driver.md)           |
+| Pipeline run               | execution | `spur workflow run` / `spur workflow continue`                                            | [execution-workflow.md](references/execution-workflow.md)                                                                               |
 | Implement (dispatch)       | execution | `sp:code-implementation`                                                                  | competency skill — the spine dispatches, does not inline                                                                                |
 | Test (dispatch)            | execution | `sp:code-testing`                                                                         | competency skill — the spine dispatches, does not inline                                                                                |
 | Review / verify (dispatch) | execution | `sp:dev-review` → `sp:code-verification` + `sp:functional-review` + `sp:code-improvement` | competency skills — the spine dispatches, does not inline                                                                               |

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

@@ -110,9 +110,10 @@ inside that subprocess boundary runs its backing skill in that process; it must
 
 **Pipeline wrappers (`dev-run`, `dev-runall`, `dev-idea`, `dev-plan`)** — the orchestrator is a loop; its *stages* do the
 model-bearing work. Interactive omit/`inline` therefore uses the
-[inline pipeline driver](inline-pipeline-driver.md): it reads the selected pipeline YAML, executes each
-`agent.run` input through the backing skill in the host session, and preserves every shell action
-and guard. `auto` or a named executor is merged into per-task `vars.agent` and
+engine loop: `spur workflow run <file> --vars '{"executor":"host",…}'` executes every guard and
+deterministic action on the engine and pauses with one work item per model stage, which this session
+performs through the backing skill before `spur workflow continue <run-id> --answer-text <receipt>`
+advances the run. `auto` or a named executor is merged into per-task `vars.agent` and
 `vars.implementAgent`, and the workflow's `agent.run` steps run under that subprocess executor (see
 `execution-batch.md` § 3.2). The loop itself continues in the current session.
 
@@ -139,8 +140,8 @@ native subagent with shared-worktree read/write/shell capability, and a task abo
 (`.spur/run/<wbs>-diffstat.json`, verify only) keeps that stage host-inline (2026-09-15
 subagent-dispatch evaluation; the floor and the
 resume-over-re-dispatch rule for worker-role continuation stages are owned by
-[inline-pipeline-driver.md](inline-pipeline-driver.md)) — dispatches **once** to that
-native subagent and joins before the driver continues; any pre-dispatch eligibility failure falls
+[cross-cutting.md](#inline-default-execution-surface)) — dispatches **once** to that
+native subagent and joins before the host reports the work-item receipt; any pre-dispatch eligibility failure falls
 back to one host execution, and a failure after dispatch follows the stage's error policy with no
 automatic host replay. Inline resolution (omitted or explicit, 0687 R1/R2) keeps the native-subagent
 leg for eligible stages. Operator
@@ -238,13 +239,13 @@ Inline avoids process startup and preserves the host session's context and tools
 subprocess dispatch it provides **no isolated workspace**, **no per-stage subprocess action
 record**, **no independent timeout or abort boundary**, and **no tier-selected executor**: the
 executor is the current coding agent. Interactive pipelines retain a run log and session provenance
-through the inline driver; task pipelines additionally record a task run-link. If process isolation or an independently killable
+through the host executor; task pipelines additionally record a task run-link. If process isolation or an independently killable
 stage is required, select the subprocess path (`--agent auto` or `--agent <name>`).
 
 ## Shared startup contract (task 0814 R1/R3/R4/R6/R7/R8)
 
 The workflow-backed dev commands (`dev-run`, `dev-runall`, `dev-refineall`, `dev-verifyall`) share one
-startup order. The order is load-bearing and applies on both the inline driver and the subprocess
+startup order. The order is load-bearing and applies on both the host executor and the subprocess
 path. Runs that resolve a workflow definition publish the generated plan as their first action
 (1105 R1); skill-only operations (refine/verify batches with no nested workflow) display their owned
 procedure and do not fabricate a workflow YAML.
@@ -495,8 +496,8 @@ them; they live here because they cross every phase boundary.
    skill, no `/sp:prd-*` commands, no `sp:super-pm` agent — unless a later task proves a stable,
    distinct routing value (ADR-022).
 7. **NEVER claim completion without fresh verification evidence.** "Tests pass" must be backed by
-   the actual `bun run test` tail pasted into the record. "Lint clean" must be backed by
-   `bun run lint` output. Stale evidence from a prior run is not evidence — re-run the gate and
+   the actual `spur self exec test` tail pasted into the record. "Lint clean" must be backed by
+   `spur self exec lint` output. Stale evidence from a prior run is not evidence — re-run the gate and
    paste the current output.
 
 ## Verification Before Completion
@@ -570,7 +571,7 @@ does not earn another full-gate run:
    final gate.
 3. **Red alone**, or a failure that is not a timeout → it is a real failure. Fix it.
 4. Give the test an explicit per-test timeout and a WHY comment (see
-   `plugins/sp/tests/inline-run-close-reason.test.ts:100-102`) as soon as EITHER (a) the same test
+   `plugins/sp/tests/helpers/cli-surface.test.ts:81`) as soon as EITHER (a) the same test
    load-flakes in two separate runs, OR (b) it times out once **outside the change scope** and then
    passes green alone on three consecutive isolated reruns. **Prefer making the test cheap or
    hermetic first** — a test that hashes the live checkout transitively, or writes a probe file into
@@ -594,7 +595,7 @@ principles determine which gates route around HITL and which still pause.
    pausing. The schema is the contract; schema-valid means structurally sound.
 2. **Gate-passed → auto-continue.** If `spur task check`, `spur feature check`, or
    `spur workflow validate` exits 0, the run continues to the next state without surfacing.
-3. **Tests-green → auto-continue.** If `bun run lint` and `bun run test` exit 0, the verify step
+3. **Tests-green → auto-continue.** If `spur self exec lint` and `spur self exec test` exit 0, the verify step
    continues. A red test suite is a hard stop, not an auto-retry.
 4. **Verdict-PASS → auto-continue.** If the verify step produces a PASS verdict, the run advances
    to `record` and `done`. PARTIAL or FAIL verdicts surface to the operator regardless of `--auto`.

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

@@ -76,7 +76,7 @@ each would be scope creep for one-liner procedures.
 | 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]`                                                                                              |
 | 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()`         | inline driver (`idea-pipeline`) or async workflow                                  | `"<description>" [--feature <id>] [--parent <feature-id>] [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                   |
+| 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]`                                                                   |
 | 7   | docs       | _(no thin wrapper)_ | `Skill()`         | `sp:doc-evolve`                                                                    | `"<change description>"`                                                                                                                                                                               |
 | 8   | changelog  | `dev-changelog`     | `inline`          | git log + conventional-commit grouping                                             | `[<file>] [--since <ref>] [--until <ref>] [--version <ver>]`                                                                                                                                            |
 | 9   | gitmsg     | `dev-gitmsg`        | `inline`          | bounded diff capture → concern grouping → conventional commit                      | `[--commit] [--squash] [--all] [--scope <path>] [--check <cmd>]`                                                                                                           |
@@ -89,7 +89,7 @@ each would be scope creep for one-liner procedures.
 | 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]`                      |
 | 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()`         | inline driver (`idea-pipeline`) or async workflow                                  | `"<idea>" \| --from-file <path> [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                                                                              |
+| 16  | idea       | `dev-idea`          | `Skill()`         | host executor (`idea-pipeline`) or async workflow                                  | `"<idea>" \| --from-file <path> [--skip-design] [--agent <inline\|auto\|name>] [--auto]`                                                                                                                              |
 | 17  | refactor   | `dev-refactor`      | `Skill()`         | `sp:code-refactoring` skill (thin wrapper, ADR-032)                                | `[<description>] [--scope <path>] [--focus <api\|architect\|tests\|ui\|auto>] [--fix <none\|blockers-first\|all>] [--check <cmd>] [--agent <inline\|auto\|name>] [--auto]`                                                                                          |
 
 ## Skill-backed operations
@@ -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.
@@ -537,9 +537,9 @@ gate commands, pending questions and approval requirements.>
   `--from-file` contents) unmodified to `.spur/run/<run-id>-idea-input.md` (0887 R1); the precheck
   fails the run when that file is empty or missing, and every model-bearing stage prompt treats
   it as the authoritative ask (R2).
-- **Backing:** `idea-pipeline.yaml` through the inline driver for omitted/`inline`, or `spur workflow run idea-pipeline.yaml --async` for `auto`/name.
+- **Backing:** `idea-pipeline.yaml` on the host executor (`vars.executor: host`, advanced by `spur workflow continue`) for omitted/`inline`, or `spur workflow run idea-pipeline.yaml --async` for `auto`/name.
 - **Behavior:** Builds vars from the table above and drives the idea pipeline. Flow: discovery → **idea-eval** (taste; reject → cancelled) → feature-create → ac-generate → feature-check → system-design (conditional) → design-approval (taste) → decompose → batch-create (`--skip-ready`) → ready-prepare (ready checklist per created task + ready-evidence sidecar, 0788) → handoff. STOPS at handoff — no task execution, no pipeline nesting. Headless runs use one `trace --follow`; cancellation is reported stopped only when `workflow cancel --json` returns `killed: true`.
-- **Delegation:** Host-session inline driver by default; explicit executor selection uses the async workflow worker.
+- **Delegation:** Host executor (this session answers each work item) by default; explicit executor selection uses the async workflow worker.
 - **Idea-evaluation gate:** After discovery, operator reviews `.spur/run/idea-eval-report.md` ([idea-evaluation.md](idea-evaluation.md)). Approve continues; reject/cancel → no feature. Under `--auto`, follows the report's recommendation (`drop` → cancelled; missing recommendation → pauses). Enhanced idea is a sidecar — `vars.idea` is not overwritten.
 - **Design package (`--skip-design` only):**
 
@@ -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