@gobing-ai/spur 0.4.11 → 0.4.13

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).
@@ -100,15 +101,15 @@ cache-conservation discipline (`plugins/sp/skills/dogfood-testing/references/mon
 
 **`--worktree [<name>]` wraps Step 2, on either surface.** When `/sp:dev-run --mode full` carries
 [`--worktree`](flag-glossary.md#flag-worktree), create or adopt the worktree *before* launching the
-pipeline, `cd` into it (`spur workflow run` and the inline driver both resolve cwd from the process),
+pipeline, `cd` into it (`spur workflow run` and `spur workflow continue` both resolve cwd from the process),
 and merge-or-retain after the run reports. The lifecycle is
 [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name)
 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/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/plugins/sp/skills/spur-dev/references/idea-evaluation.md

@@ -21,7 +21,7 @@ re-author the report.
 
 **Sidecar rule:** The enhanced idea does **not** overwrite `vars.idea`. Feature-create reads both
 the original idea and this report. The operator's verbatim ask of record is the run's
-`.spur/run/<run-id>-idea-input.md` (persisted by the pipeline `start` state / the inline driver
+`.spur/run/<run-id>-idea-input.md` (persisted by the pipeline `start` state on every executor surface
 before any processing); the `## Requirement inventory` items trace back to it.
 
 ## Template

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.",