@gobing-ai/spur 0.4.7 → 0.4.9

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

@@ -104,7 +104,7 @@ bun run apps/cli/src/index.ts feature check <id> --strict --json
   tasks, and the structured feature findings (the `--json` finding list) reported verbatim. This is
   the same abort vocabulary as cycle / unknown selector (Step 4/Step 5). **Expected pre-run
   states are classified in code, not here:** the non-aborting set lives in
-  `NON_ABORTING_PREFLIGHT_CODES` (`plugins/sp/scripts/batch-preflight.ts`), consumed through
+  `NON_ABORTING_PREFLIGHT_CODES` (`spur task preflight --classify-feature`), consumed through
   `classifyFeaturePreflightFindings`, which splits the finding list into `aborting` and
   `nonAborting` and reports `shouldAbort`. `L4.scenario-unverified` is the expected state of any
   not-yet-run feature (its covering tasks have no PASS verdicts yet) and
@@ -211,12 +211,12 @@ as a JSON array of `{wbs, dependencies, files?}` (`dependencies` from `spur task
 frontmatter; `files` = repo paths the task's Design/Plan names, omit when it names none) and run:
 
 ```bash
-node "$(superskill script path sp batch-plan.mjs)" order --tasks <tasks.json> [--concurrency <n>]
+spur task batch-plan order --tasks <tasks.json> [--concurrency <n>]
 # → {"order":[…],"waves":[[…],…],"cycle":null|[…],"overlaps":[…],"mode":"sequential|parallel","reason":"…"}
 ```
 
 `order` is the execution plan; a non-null `cycle` is the abort below. `waves`, `overlaps`, `mode`
-and `reason` feed `--mode auto` (§ 2.4a) and the batch report. The script implements Kahn's
+and `reason` feed `--mode auto` (§ 2.4a) and the batch report. The verb implements Kahn's
 algorithm (ADR-130 glue over `scheduleBatch` in `packages/app/src/workflow/plan-projection.ts`):
 
 1. Seed the queue with zero-indegree nodes, **sorted WBS-ascending** (deterministic tie-break).
@@ -265,12 +265,12 @@ The ordered execution plan: a WBS-ascending-topological list of tasks to run, pl
 ### 2.6 Preflight — TABLE A STOP rows (task 0279 / next-router consumer)
 
 **Before** each `spur workflow run` for a WBS still on the plan, re-check readiness with the pure
-helper (preferred) or `sp:next-router` dry-run:
+helper (preferred) or `sp:next-router` dry-run. Status, dependencies and their statuses are read
+from the task corpus; `--status` / `--deps` / `--dep-status` override those reads:
 
 ```bash
-node "$(superskill script path sp batch-preflight.mjs)" \
-  --wbs <wbs> --status <status> \
-  --deps <comma-deps> --dep-status <wbs:status,...> --json
+spur task preflight <wbs> --json
+spur task preflight <wbs> --status <status> --deps <comma-deps> --dep-status <wbs:status,...> --json
 ```
 
 | Result | Batch action |
@@ -289,9 +289,8 @@ out-of-set deps; 2.6 is belt-and-braces for status STOP rows and a uniform repor
 ### 2.7 Visible batch plan (1105 R3)
 
 The batch publishes a generated two-layer plan in the host's native todo list — letters first, digits
-per task only at task start. Rows come from `batch-plan.mjs` (ADR-130 glue over
-`packages/app/src/workflow/plan-projection.ts`), reached like `batch-preflight`:
-`node "$(superskill script path sp batch-plan.mjs)"`. The visible plan is a projection of the frozen
+per task only at task start. Rows come from `spur task batch-plan` (a thin verb over
+`packages/app/src/workflow/plan-projection.ts`), reached like `spur task preflight`. The visible plan is a projection of the frozen
 plan, never a second plan: labels carry identity, updates happen at the boundaries below only, and no
 per-task letter is ever hand-assigned.
 
@@ -302,7 +301,7 @@ per-task letter is ever hand-assigned.
    JSON array of `{wbs, name}` and render the waves:
 
    ```bash
-   node "$(superskill script path sp batch-plan.mjs)" waves --tasks <tasks.json>
+   spur task batch-plan waves --tasks <tasks.json>
    ```
 
    Publish wave 1's rows — one letter (B…Y) per task with no digit children, then `Z Batch report`;
@@ -311,7 +310,7 @@ per-task letter is ever hand-assigned.
    `spur workflow show task-pipeline.yaml --no-logo --format todo --json` payload:
 
    ```bash
-   node "$(superskill script path sp batch-plan.mjs)" task-children --letter <task-letter> --plan <plan.json>
+   spur task batch-plan task-children --letter <task-letter> --plan <plan.json>
    ```
 
 4. **When a task ends:** mark the task's letter (and its published digits) with the task's terminal
@@ -324,9 +323,9 @@ per-task letter is ever hand-assigned.
 ```
 plan = resolve(--tasks) → freeze → order(deps)        # may abort (cycle) or pre-block (unmet dep)
 report = []
-publish visible plan §2.7: A/Z rows now; one letter per task after this freeze (batch-plan.mjs waves)
+publish visible plan §2.7: A/Z rows now; one letter per task after this freeze (task batch-plan waves)
 RUN_ID = WT-3 marker id under --worktree, else "batch-$(date -u +%Y%m%dT%H%M%SZ)"   # fixed ONCE here; the close-out reuses it
-commit-guard start --run "$RUN_ID"                     # 1129 R1: fingerprint before the first task writes; the close-out commit stages through it
+spur workflow commit-guard start --run "$RUN_ID"       # 1129 R1: fingerprint before the first task writes; the close-out commit stages through it
 for wbs in plan:                                       # default sequential mode
     if any dependency of wbs failed earlier in THIS batch:
         report += skipped(wbs, reason); continue       # only relevant under --keep-going
@@ -334,7 +333,7 @@ for wbs in plan:                                       # default sequential mode
     if precheck fails on semantic findings:
         if --auto: one /sp:dev-refineall --auto pass; still failing → report += skipped(wbs, findings); continue
         else:      HALT (unchanged non-auto behavior)
-    preflight = batch-preflight(wbs)                   # Step 2.6 — TABLE A STOP
+    preflight = spur task preflight <wbs>              # Step 2.6 — TABLE A STOP
     if preflight.action == skip:
         report += preflight-skip(wbs, preflight); continue
     visible plan (§2.7): letter in_progress + task-children digits at start; letter ← outcome at end
@@ -443,7 +442,7 @@ After a non-PASS terminal state (or when the task status is stuck at `wip`/`test
 verdict), consult **one** recovery hop:
 
 ```bash
-node "$(superskill script path sp batch-preflight.mjs)" --wbs <wbs> --status <status> --recovery
+spur task preflight <wbs> --status <status> --recovery
 # → e.g. /sp:dev-verify 0042 --auto --next
 ```
 
@@ -455,7 +454,7 @@ node "$(superskill script path sp batch-preflight.mjs)" --wbs <wbs> --status <st
 | Multi-candidate | HITL stop — do not silent-pick (batch `--auto` does not break ties) |
 | Forbidden | Replacing the whole batch with repeated `/sp:dev-next` (deep-merge) |
 
-Helper: `recoveryHint(status, wbs)` in `plugins/sp/scripts/batch-preflight.ts`. Tables remain SSOT
+Helper: `recoveryHint(status, wbs)` behind `spur task preflight --recovery`. Tables remain SSOT
 in next-router; this only maps status → primary TABLE A hop for recovery.
 
 ### 3.3c Feature-sync retry suppression (task 0411; 1004 R3)

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

@@ -47,7 +47,7 @@ emit batch report (per-task outcomes + preflight skips + recovery hints + batch
   rebase over theirs. Omitting `--mode` stays sequential; this loop is entered only via
   `--mode parallel` on `/sp:dev-runall`, directly or as a `--mode auto` resolution
   ([execution-batch.md § 2.4a](execution-batch.md#24a---mode-auto-resolution)).
-- **Fan-out set.** Run order and eligibility come from the § 2.4 `batch-plan.mjs order` schedule;
+- **Fan-out set.** Run order and eligibility come from the § 2.4 `spur task batch-plan order` schedule;
   its file-overlap edges are in-set dependencies here, so overlapping tasks never run at once.
 - **Workdir.** `spur workflow run` records the launch workdir (0784 R1), so launch with `cwd` = the
   task worktree: resume and `.spur/run/` artifact paths resolve there. Read the verdict from

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

@@ -89,7 +89,7 @@ git merge-base --is-ancestor "$BATCH_TIP" "$LANDED_BASE_TIP" \
 write_marker () {   # $1 = merged | retained; read-modify-write: preserve WT-3 fields (id, command, selector, createdAt, adopted, adoptedAt); jq already assumed by WT-3/task-resolution flows
   mkdir -p "$(dirname "$MARKER")"
   if [ -f "$MARKER" ]; then
-    TMP_MARKER="$(mktemp)"
+    TMP_MARKER="$(mktemp "$MARKER.XXXXXX")"   # sibling: atomic same-dir mv, no system temp dir
     jq --arg s "$1" --arg m "$BATCH_TIP" '.status = $s | .mergeCommit = $m' "$MARKER" > "$TMP_MARKER" \
       || { echo "WT-4 halt: cannot rewrite marker $MARKER" >&2; rm -f "$TMP_MARKER"; exit 1; }
     mv "$TMP_MARKER" "$MARKER"
@@ -116,8 +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:
-SETUP_SCRIPT=plugins/sp/scripts/inline-run-setup.ts; [ -f config/plugin-scripts.json -a -f "$SETUP_SCRIPT" ] || SETUP_SCRIPT="$(superskill script path sp inline-run-setup.mjs 2>/dev/null)"
-bun "$SETUP_SCRIPT" --persist-out --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
+spur workflow inline 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
@@ -156,10 +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 — `inline-run-setup.ts --persist-out` accepts `--from` and
+# belong to THIS check only — `spur workflow inline persist-out` accepts `--from` and
 # `--task-file` alone and exits 2 on `--run-id` (1089 driver note).
-CHECK_SCRIPT=plugins/sp/scripts/persist-out-check.ts; [ -f config/plugin-scripts.json -a -f "$CHECK_SCRIPT" ] || CHECK_SCRIPT="$(superskill script path sp persist-out-check.mjs 2>/dev/null)"
-bun "$CHECK_SCRIPT" --from "$WT_PATH" "${TASK_FILE_ARGS[@]}" \
+spur workflow inline 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; }
@@ -235,7 +233,7 @@ WT_PATH="<resolved-worktree-path>"   # reuse mode: the adopted tree's physical p
 write_marker () {   # $1 = merged | retained; read-modify-write: preserve WT-3 fields (id, command, selector, createdAt, adopted, adoptedAt); jq already assumed by WT-3/task-resolution flows
   mkdir -p "$(dirname "$MARKER")"
   if [ -f "$MARKER" ]; then
-    TMP_MARKER="$(mktemp)"
+    TMP_MARKER="$(mktemp "$MARKER.XXXXXX")"   # sibling: atomic same-dir mv, no system temp dir
     jq --arg s "$1" --arg m "$BATCH_TIP" '.status = $s | .mergeCommit = $m' "$MARKER" > "$TMP_MARKER" \
       || { echo "WT-4 halt: cannot rewrite marker $MARKER" >&2; rm -f "$TMP_MARKER"; exit 1; }
     mv "$TMP_MARKER" "$MARKER"
@@ -423,15 +421,14 @@ git checkout <base-ref> && git merge --no-ff -m "<prepared message>" <branch>
 #     the batch's run id, the same one WT-3b's worktree fingerprint used — the two trees keep two
 #     artifacts under the same id):
 #       RUN_ID="<marker-id>"   # the WT-3 marker's id
-#       GUARD=plugins/sp/scripts/commit-guard.ts; [ -f config/plugin-scripts.json -a -f "$GUARD" ] || GUARD="$(superskill script path sp commit-guard.mjs 2>/dev/null)"
-#       bun "$GUARD" start --run "$RUN_ID"
+#       spur workflow commit-guard start --run "$RUN_ID"
 #     git checkout <base-ref> && git merge --no-commit <branch>
 # 2. resolve source conflicts by hand; generated files are then regenerated with the project's
 #    generator, never hand-merged
 #    (this repo: bun run build:plugin-lib && bun run --filter @gobing-ai/spur build:bundle)
 # 3. stage every resolved path and regenerated bundle through the guard — an unmerged or
 #    unstaged path makes step 5 abort, and a conflict-marked path exits 3 (resolve, then retry):
-#      bun "$GUARD" stage --run "$RUN_ID" -- <resolved paths and regenerated bundles>
+#      spur workflow commit-guard stage --run "$RUN_ID" -- <resolved paths and regenerated bundles>
 #    Forbidden here as in every driver commit step: `git add -A` and `git add .`.
 # 4. run qualityGateCmd once, after ALL conflicts are resolved
 # 5. commit the merge with the prepared message file — CHECK THE PARENTS FIRST (step 5a)
@@ -446,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
-inline-run-setup --persist-out --from <worktree> --task-file …
+spur workflow inline 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

@@ -20,7 +20,7 @@ lifecycle for the sequential batch loop. `--mode parallel` has its own per-task
 rejected there (parallel mode already isolates each task in its own worktree).
 
 **Startup ordering (task 0814 R3).** Resolve the selector/status filter and run the quick
-command-aware readiness (the `quickReadiness` contract in `batch-preflight.ts`) **before** creating
+command-aware readiness (the `quickReadiness` contract behind `spur task preflight --operation`) **before** creating
 or adopting the tree. The admission decision is what determines whether a tree should be cut at all;
 all subsequent tools, agents, task/feature writes, and run artifacts use the confirmed execution
 tree's cwd. A stale or empty selector, an unsupported mode, or an invalid target creates no tree and
@@ -209,7 +209,7 @@ the worktree directory before launching the loop.
 
 `.spur/memory/evidence/` and `.spur/run/` are **untracked per-tree** planes, so a fresh worktree
 starts with neither while the invoking tree holds every earlier task's verdict. Both
-`preflightFeature` (`plugins/sp/scripts/wrapup-steps.ts` → `spur feature check --strict --as done`
+`preflightFeature` (`spur task wrapup resolve` → `spur feature check --strict --as done`
 with cwd = the worktree) and `runMetrics` resolve verdict artifacts relative to the tree they run
 in, so without this step an already-`done` linked task reads as missing evidence
 (`L4.evidence-not-recoverable`, `L4.scenario-unverified`) and its metrics row degrades to
@@ -346,14 +346,13 @@ fingerprints the invoking tree, which is also where its commit lands. The confli
 fingerprints the invoking tree for the same reason (its own step 1b).
 
 ```bash
-GUARD=plugins/sp/scripts/commit-guard.ts; [ -f config/plugin-scripts.json -a -f "$GUARD" ] || GUARD="$(superskill script path sp commit-guard.mjs 2>/dev/null)"
 # Pinned subshell, same discipline as WT-3b: select the execution tree for this one call.
 (
   cd -- "../<worktree-dir>" || { echo "tree missing: expected ../<worktree-dir>" >&2; exit 1; }
   [ "$(git branch --show-current)" = "$BRANCH" ] \
     || { echo "branch mismatch: expected $BRANCH, got $(git branch --show-current)" >&2; exit 1; }
   RUN_ID="<marker-id>"   # the WT-3 marker's id — the same id WT-3b's stage call uses
-  bun "$GUARD" start --run "$RUN_ID"   # <worktree>/.spur/run/$RUN_ID-tree-start.json = { head, dirty[] }
+  spur workflow commit-guard start --run "$RUN_ID"   # <worktree>/.spur/run/$RUN_ID-tree-start.json = { head, dirty[] }
 )
 ```
 
@@ -369,9 +368,8 @@ same call, verifies the WT-3 identity, and never relies on a persistent `cd` or
   cd -- "../<worktree-dir>" || { echo "tree missing: expected ../<worktree-dir>" >&2; exit 1; }
   [ "$(git branch --show-current)" = "$BRANCH" ] \
     || { echo "branch mismatch: expected $BRANCH, got $(git branch --show-current)" >&2; exit 1; }
-  GUARD=plugins/sp/scripts/commit-guard.ts; [ -f config/plugin-scripts.json -a -f "$GUARD" ] || GUARD="$(superskill script path sp commit-guard.mjs 2>/dev/null)"
-  bun "$GUARD" check --run "$RUN_ID"        # 1129 R3: concurrent foreign writers; a non-empty list goes in the batch report
-  bun "$GUARD" stage --run "$RUN_ID" -- <files-the-batch-wrote> \
+  spur workflow commit-guard check --run "$RUN_ID"        # 1129 R3: concurrent foreign writers; a non-empty list goes in the batch report
+  spur workflow commit-guard stage --run "$RUN_ID" -- <files-the-batch-wrote> \
     || { echo "WT-3b halt: commit-guard refused a path (foreign, unmerged or conflict-marked); nothing committed" >&2; exit 1; }
   git commit -m "<type>(<scope>): <command> <selector> batch writes"
 )
@@ -379,7 +377,7 @@ same call, verifies the WT-3 identity, and never relies on a persistent `cd` or
 
 > **Forbidden in every driver commit step:** `git add -A` and `git add .`. They stage whatever a
 > concurrent writer happened to leave in the tree — the two incidents this guard exists for are
-> `a94f9f431` and `36f274590` — so a driver stages only through `commit-guard stage`.
+> `a94f9f431` and `36f274590` — so a driver stages only through `spur workflow commit-guard stage`.
 
 > **`stage` takes files, never directories.** A directory argument is refused as `(unchanged since
 > base)` and stages *nothing*, so a task whose diff lives in a moved tree must expand the changed

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

@@ -88,7 +88,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: `quality-gate.ts status` reports `reuse: true` for
+- [ ] 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
       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.

package/plugins/sp/skills/spur-dev/references/inline-pipeline-driver.md

@@ -21,7 +21,7 @@ the interpreter and trace instructions must match. Never hand-edit the installed
 
 ## Driver state checklist (re-read this after a compaction)
 
-- **Run id** — the run row `inline-run-setup` persisted (`.spur/run/<run-id>-inline-setup.json`
+- **Run id** — the run row `spur workflow inline begin` persisted (`.spur/run/<run-id>-inline-setup.json`
   sidecar, `.spur/memory/runs/<run-id>.md` + `.state.json`); never re-derive it from the transcript.
 - **Markers under `.spur/run/`** — `<run-id>-inline-setup.json` (frozen invocation identity),
   `<run-id>-tree-start.json` (commit-guard fingerprint), `<wbs>-verdict.json` (per-stage verdict),
@@ -98,14 +98,8 @@ fallback) — labels are display addresses only, never an execution key.
    accept the inline run (0785 R3):
 
    ```bash
-   SETUP_SCRIPT=plugins/sp/scripts/inline-run-setup.ts; [ -f config/plugin-scripts.json -a -f "$SETUP_SCRIPT" ] || SETUP_SCRIPT="$(superskill script path sp inline-run-setup.mjs 2>/dev/null)";
-   # 0960 R2: record the run's script-resolution identity beside the run row (the same file the
-   # pipelines' run-start action writes) so the inline path carries the same provenance.
-   RS=plugins/sp/scripts/script-root.ts; [ -f config/plugin-scripts.json -a -f "$RS" ] || RS="$(superskill script path sp script-root.mjs 2>/dev/null)";
-   RUNNER=bun; case "$RS" in *.mjs) RUNNER=node ;; esac; [ -f "$RS" ] && "$RUNNER" "$RS" --run-id "$RUN_ID" || echo "script-root failed closed — run 'superskill install sp --marketplace gobing-ai/spur'" >&2
-   [ -n "$SETUP_SCRIPT" ] && [ -f "$SETUP_SCRIPT" ] && \
-     bun "$SETUP_SCRIPT" --run-id "$RUN_ID" --file <selected-pipeline-yaml> \
-     || { echo "inline run setup failed closed — checker not found; run 'superskill install sp --marketplace gobing-ai/spur'" >&2; exit 1; }
+   spur workflow inline begin --run-id "$RUN_ID" --file <selected-pipeline-yaml> \
+     || { echo "inline run setup failed closed — see the spur workflow inline begin error above" >&2; exit 1; }
    ```
 
    **Commit fingerprint (1129 R1).** Fingerprint the tree the task commit will land in — before the
@@ -118,21 +112,18 @@ fallback) — labels are display addresses only, never an execution key.
 
    ```bash
    RUN_ID="<marker-id>"   # the WT-3 marker's id (execution-batch.md), or the run id allocated at setup
-   GUARD=plugins/sp/scripts/commit-guard.ts; [ -f config/plugin-scripts.json -a -f "$GUARD" ] || GUARD="$(superskill script path sp commit-guard.mjs 2>/dev/null)";
-   bun "$GUARD" start --run "$RUN_ID"     # <this tree>/.spur/run/$RUN_ID-tree-start.json = { head, dirty[] }
+   spur workflow commit-guard start --run "$RUN_ID"     # <this tree>/.spur/run/$RUN_ID-tree-start.json = { head, dirty[] }
    ```
 
-   The delegate uses the source app service when the SPUR_BIN chain identifies a checkout;
-   otherwise it loads the generated application bundle shipped with the plugin. Both setup paths
-   obtains the selected definition from the existing CLI `workflow show --format todo --json`
-   projection and revalidates its schema/name/digest before preserving its source layer.
-   Both paths create-or-attach the row,
+   `spur workflow inline begin` (the installed CLI transport; the plugin requires spur) obtains the
+   selected definition from the CLI's `workflow show --format todo --json` projection — through
+   `--spur-bin`/`SPUR_BIN` when set, else the running spur — and revalidates its
+   schema/name/digest before preserving its source layer. It create-or-attaches the row,
    and writes the run-record state `.spur/memory/runs/<run-id>.state.json` plus the `.md` run-start
    header (task 0927; a legacy pre-0927 run keeps its `<run-id>-inline-setup.json` sidecar).
    Seed `__runId` and `__definitionDigest`
    from that state so proof capture and bound registration verify against the persisted identity.
-   Bun remains required for SQLite; the Node-runnable installed twin re-enters Bun on PATH.
-   A non-zero exit (missing runtime/bundle, invalid projection, missing row identity, changed definition) stops the run —
+   A non-zero exit (invalid projection, missing row identity, changed definition) stops the run —
    never continue unbound and never fabricate a PASS. (The delegate persists the authoritative
    RUN row only — the 0808 inline record is the registration-equivalent convention below, not a
    setup-time artifact-ledger insert.)
@@ -173,7 +164,7 @@ fallback) — labels are display addresses only, never an execution key.
    Publishing executes nothing, so it safely precedes readiness and isolation, which keep their
    existing order below.
 6. **Quick deterministic readiness (R2), before isolation.** Evaluate `quickReadiness` from
-   `plugins/sp/scripts/batch-preflight.ts` with the operation, status, filtered-set size, the
+   `spur task preflight <wbs> --operation <op>` with the operation, status, filtered-set size, the
    matrix-selected required/present sections, and content-policy findings. Record the outcome
    (runnable / needs-refinement / blocked / skipped / invalid) in the run log. Admission decision
    only — no model, no full tests/lint, no live-data probe, no feature mutation, no corpus-wide
@@ -414,15 +405,15 @@ After each executed action settles, record its boundary before the next action,
 or terminal close. Measure its actual duration and preserve its declared failure policy:
 
 ```bash
-bun "$SETUP_SCRIPT" --action --run-id "$RUN_ID" --node <state-id> --kind <action-kind> \
+spur workflow inline action --run-id "$RUN_ID" --node <state-id> --kind <action-kind> \
   --status <done|failed> --ok <true|false> --duration-ms <measured-ms> [--estimated]
 ```
 
 `--duration-ms` is the wall clock measured around the action. Pass `--estimated` when you did
 **not** time it — for example a duration reconstructed after a subagent returned — so the row is
-labelled instead of presented as measured. `--estimated` is valid only with `--action`.
+labelled instead of presented as measured. `--estimated` is valid only on `inline action`.
 
-For a multi-action state, `--actions-file` may emit the measured boundaries together before leaving
+For a multi-action state, `spur workflow inline actions --file <json>` may emit the measured boundaries together before leaving
 that state. Follow [Structured trace emission](#structured-trace-emission-adr-117-task-0868) for the
 payload, delegated `decide` emission and best-effort failure handling. Never retry a failed batch
 or backfill at close; a zero-row done close fails with `NO_ACTION_ROWS`.
@@ -488,7 +479,7 @@ Action semantics come from the YAML and the workflow action contract:
   state mutates the task, the host validates the same refusal conditions inline — the declared
   artifact exists at the resolved path and is canonical-valid for the run's wbs (for
   `verify-verdict`: verdict `PASS`), `proofBinding: current` is honored against a freshly captured
-  proof digest — capture it with `bun "$SETUP_SCRIPT" --fingerprint --task-file <task path>
+  proof digest — capture it with `spur workflow inline fingerprint --task-file <task path>
   [--feature-file <feature path>]`, the same entry point used at Run setup, which prints the engine
   `sha256:<hex>` digest. Run it inside a per-call pin subshell for the confirmed execution tree
   (the cwd feeds the git-tree half of the digest)
@@ -560,8 +551,7 @@ run collapses into one serial host worker with no executor diversity. So classif
 failure before falling back:
 
 ```bash
-DISPATCH_SCRIPT=plugins/sp/scripts/inline-run-dispatch.ts; [ -f config/plugin-scripts.json -a -f "$DISPATCH_SCRIPT" ] || DISPATCH_SCRIPT="$(superskill script path sp inline-run-dispatch.mjs 2>/dev/null)"
-bun "$DISPATCH_SCRIPT" --dispatch-failure --run-id "$RUN_ID" --stage <state-id> --decision <escalate|stop> \
+spur workflow inline dispatch-failure --run-id "$RUN_ID" --stage <state-id> --decision <escalate|stop> \
   --text-file <bounded failure record> [--executor <name>] [--agent <a>] [--model <m>]
 ```
 
@@ -586,7 +576,7 @@ record the executor identity the stage will use, so a later classified exhaustio
 to a rung configuration can disable:
 
 ```bash
-bun "$DISPATCH_SCRIPT" --attribution --run-id "$RUN_ID" --stage <state-id> \
+spur workflow inline attribution --run-id "$RUN_ID" --stage <state-id> \
   [--executor <name>] [--agent <name>] [--model <m>]     # omit --executor for the no-attribution marker
 ```
 
@@ -662,6 +652,12 @@ boundary, and a delegate left to re-derive them re-derives them against its own
    when a plugin script was touched, and the paired-script parity test when `package.json` changed —
    so an env-var-hygiene violation, a stale generated twin, or a half-updated paired chain is
    named by the stage rather than discovered by the pipeline `test` hop.
+   **That pre-check is returned evidence, not a background step:** the stage reports its output (or
+   `precheck: not-run` with the reason), and a stage that returns neither the output nor the
+   not-run line is recorded `done` with a `precheck-missing` marker beside the `probe-missing` one.
+   Measured cost of skipping it (2026-10-16, task 1215): one full quality-gate run plus a
+   `test-fix` → `test-recheck` cycle on a `process.env` in a new test that the pre-check preset
+   flags in seconds.
    **A stage that returns neither probe evidence nor the not-applicable line is not silently
    complete (task 1135 R2): the driver records the stage `done` with a `probe-missing` marker in
    the run log and carries the same marker into that task's batch-report row.**
@@ -765,7 +761,7 @@ host-owned gate sat between the stages, or when the platform cannot address comp
 
 **Implement and test-fix workers never run the full gate (task 1142 R3).** Workers use the light tier as their iteration check (task 1142 R3) in exact order:
 1. the **changed-path matrix** (`code-implementation/SKILL.md` § Changed-path targeted checks) over the paths they touched;
-2. the resolved `quality-gate` script in `light` mode (source-repo probe, else the installed twin) (biome, per-workspace typecheck, rule presets, related tests).
+2. `spur task gate <wbs> light` (biome, per-workspace typecheck, rule presets, related tests).
 Neither step takes the full gate. The pipeline's `test` and `test-recheck` hops remain the only full gate. Carry
 `--gate-log <path>` through to the child **verbatim**: never paraphrase it into "re-run the named
 gate command". That paraphrase is not cosmetic — it sent a worker into a full gate run instead of
@@ -864,7 +860,7 @@ documented beside `DEFAULT_EXCLUDE_GLOBS` in `proof-input-fingerprint.ts`).
 Order matters for the `testing → done` hop: the sections must not be hand-written **before** the
 verdict artifact exists (tasks 0617, 0619 — the clobbering spiral).
 
-1. **Write the verdict artifact first.** `spur task record --solution-from-diff --transition testing`
+1. **Write the verdict artifact first.** `spur task record <wbs> --solution-from-diff --transition testing --no-lifecycle`
    reads `.spur/run/<wbs>-verdict.json` (default attempt output) on every invocation and atomically retains the recorded verdict under `.spur/memory/evidence/`. A missing or malformed artifact
    yields **UNKNOWN**: bare Testing receives a "No requirements recorded" stub, while already-authored
    Testing is preserved. `--solution-from-diff` backfills only a bare Solution. The clobbering above is
@@ -878,7 +874,7 @@ verdict artifact exists (tasks 0617, 0619 — the clobbering spiral).
    # Both calls are per-call pinned (task 1058): the record hop selects the execution tree inside
    # the same tool call — never through a cwd a previous call happened to leave behind.
    spur task update <wbs> wip --no-lifecycle
-   spur task record <wbs> --solution-from-diff --transition testing
+   spur task record <wbs> --solution-from-diff --transition testing --no-lifecycle
    ```
 
    The engine now preserves an already-authored Testing when the verdict is UNKNOWN (task-service
@@ -908,16 +904,15 @@ verdict artifact exists (tasks 0617, 0619 — the clobbering spiral).
    conflict markers — both mean "resolve it, do not commit":
 
    ```bash
-   GUARD=plugins/sp/scripts/commit-guard.ts; [ -f config/plugin-scripts.json -a -f "$GUARD" ] || GUARD="$(superskill script path sp commit-guard.mjs 2>/dev/null)";
-   bun "$GUARD" check --run "$RUN_ID"
-   bun "$GUARD" stage --run "$RUN_ID" -- <files this run wrote> \
+   spur workflow commit-guard check --run "$RUN_ID"
+   spur workflow commit-guard stage --run "$RUN_ID" -- <files this run wrote> \
      || { echo "record halt: commit-guard refused a path (foreign, unmerged or conflict-marked); nothing committed" >&2; exit 1; }
    git commit -m "<type>(<scope>): <wbs> <summary>"
    ```
 
-5. **Print the run's execution summary (1146).** The terminal `--close` returns `summaryFile`; print
+5. **Print the run's execution summary (1146).** The terminal `spur workflow inline close` returns `summaryFile`; print
    that file's contents verbatim under an `### Execution summary` heading, and pass `--no-summary`
-   through to `--close` when the operator asked for it. The window is the run row's `started_at` →
+   through to `inline close` when the operator asked for it. The window is the run row's `started_at` →
    close time — the driver records no `SINCE` and assembles no measurement of its own
    (structured-trace-emission.md § the close step owns the contract).
 
@@ -967,17 +962,15 @@ were both violated once on 2026-10-10, aborting the run's own verification):
 
 Each item below cost a driver cycle to discover. They are contracts, not tips.
 
-- **`--decide --options-json <file>` takes one option object, never an array.** Shape:
+- **`spur workflow inline decide --options-json <file>` takes one option object, never an array.** Shape:
   `{id, decision, params?, evidence? | instructions?, resultFile}`; `evidence` and `instructions` are
   mutually exclusive (`CatalogDecideOptionsSchema`). A JSON array parses as neither dialect and
   surfaces as `decide: invalid options — Invalid input` with no field detail. `resultFile` resolves
   against the confirmed tree's cwd, so pass a worktree-relative path such as
   `.spur/run/<wbs>-triage.decision`.
-- **`task-diffstat.ts` reads `wbs` from the environment and writes an artifact.** Invoke it as
-  `wbs=<wbs> node "$(superskill script path sp task-diffstat.mjs)"`; stdout stays empty, so assert success on
-  `.spur/run/<wbs>-diffstat.json` and never on command output. Never the bare unguarded
-  source-repo path form — the script-contract check forbids it on a shipped surface because it
-  shadows the installed twin in a consumer.
+- **`spur task diffstat <wbs>` writes an artifact, not output.** stdout stays empty, so assert
+  success on `.spur/run/<wbs>-diffstat.json` and never on command output; a missing or malformed
+  run base still exits 0 with `sensitive: true` (fail safe).
 - **The verify answer grammar is exact.** One `Verdict:` line, then
   `### Per-Requirement Traceability` (`| Req | Status | Evidence |`) and
   `### Acceptance Criteria Verification` (`| AC | Status | Evidence Type | Evidence |`). Requirement

package/plugins/sp/skills/spur-dev/references/structured-trace-emission.md

@@ -16,14 +16,14 @@ implementation. The shared writer is `WorkflowActionTraceWriter`
 around `DbWorkflowPersistenceAdapter`, so the two surfaces call one emission path and one run-row
 closure path and cannot drift.
 
-The driver reaches it through the existing run delegate (`$SETUP_SCRIPT`,
-`plugins/sp/scripts/inline-run-setup.ts`) — no new entry point, no second resolution chain:
+The driver reaches it through the installed CLI transport `spur workflow inline <op>` (the same
+command that began the run) — no second entry point, no second resolution chain:
 
 - **Every executed action** — after the action settles, whether it ran host-inline or via a native
   subagent — append its provenance line as before, then record the boundary:
 
   ```bash
-  bun "$SETUP_SCRIPT" --action --run-id "$RUN_ID" --node <state-id> --kind <action-kind> \
+  spur workflow inline action --run-id "$RUN_ID" --node <state-id> --kind <action-kind> \
     --status <done|failed> --ok <true|false> [--duration-ms <measured-ms>] [--estimated] \
     --project-root "$OWNING_TREE"
   ```
@@ -43,45 +43,45 @@ deliberate, so when the driver runs inside a `--worktree` (or any other executio
 lives in the **invoking** tree's `.spur/spur.db` while the action commands run in the execution
 tree. `--project-root` is the invoking tree recorded by the WT-3 marker; without it the row is read
 from the cwd tree. A run-row miss is a **correctness failure**, not a best-effort emission failure:
-`--action`, `--actions-file` and `--node-enter` exit `1` with
-`{"ok":false,"code":"RUN_NOT_FOUND"}`, exactly like `--close`. **Never redirect these calls'
+`inline action`, `inline actions` and `inline node-enter` exit `1` with
+`{"ok":false,"code":"RUN_NOT_FOUND"}`, exactly like `inline close`. **Never redirect these calls'
 stdout/stderr to `/dev/null`** — the suppressed-RUN_NOT_FOUND run of task 1132 lost 93 action rows
 to exactly that redirect. Capture the output or let it stream; a failure must be visible.
 
   **Durations: measured beats reported (task 1136 R4).** Stamp the enter time before the action runs:
 
   ```bash
-  bun "$SETUP_SCRIPT" --node-enter --run-id "$RUN_ID" --node <state-id> --project-root "$OWNING_TREE"
+  spur workflow inline node-enter --run-id "$RUN_ID" --node <state-id> --project-root "$OWNING_TREE"
   ```
 
-  Then call `--action` **without** `--duration-ms` — the delegate computes
+  Then call `inline action` **without** `--duration-ms` — the delegate computes
   `duration = now − enter` and stamps `provenance: measured` into `action_runs.result_json`. A
   caller-supplied `--duration-ms` stays valid but is recorded `provenance: host-reported` (with
   `--estimated` marking a value reconstructed after the fact); every other inline row is
   `host-reported` too, and the projection exposes `provenance` per attempt so the Board can label a
   reported duration instead of presenting it as measured. A row whose computed start would precede
   `runs.started_at` is **rejected** (exit `1`) — a timestamp before the run began is a broken clock,
-  not evidence. Calling `--action` without `--duration-ms` and without a matching `--node-enter`
+  not evidence. Calling `inline action` without `--duration-ms` and without a matching `inline node-enter`
   exits `1` with `code:"ACTION_DURATION_UNAVAILABLE"`; it never silently drops the row.
 
 - **A state with several actions (1007 R5)** — emit the whole state's boundaries in one call
-  instead of one `--action` invocation per action. Write a JSON array
-  (`[{node,kind,status,ok,durationMs,estimated?}, …]` — the `--action` fields, `estimated`
-  optional and `false` when absent) to a temp file and pass it with `--actions-file`:
+  instead of one `inline action` invocation per action. Write a JSON array
+  (`[{node,kind,status,ok,durationMs,estimated?}, …]` — the `inline action` fields, `estimated`
+  optional and `false` when absent) to a temp file and pass it with `spur workflow inline actions --file`:
 
   ```bash
-  bun "$SETUP_SCRIPT" --actions-file <actions.json> --run-id "$RUN_ID" --project-root "$OWNING_TREE"
+  spur workflow inline actions --file <actions.json> --run-id "$RUN_ID" --project-root "$OWNING_TREE"
   ```
 
-  Every row is recorded through the same writer as `--action` (one `action_runs` row per entry);
+  Every row is recorded through the same writer as `inline action` (one `action_runs` row per entry);
   the batch is validated in full before the first write, so an invalid row or unreadable file
   exits `1` with `{"ok":false}` and leaves **no** partial rows — fix the batch and re-emit. On
   success it prints `{"ok":true,"runId":…,"recorded":<n>}` and exits `0`. Row emission stays
-  best-effort exactly like `--action`: if a row's write fails mid-batch, the failure is recorded
+  best-effort exactly like `inline action`: if a row's write fails mid-batch, the failure is recorded
   to the run record and the call reports `{"ok":false,…,"error":…}` but still exits `0` — the run
-  continues; never retry the batch or backfill by hand. `--actions-file` is exclusive with the
-  other mode flags (`--action`, `--decide`, `--close`, …): mixing them is a usage error (exit 2),
-  and a mixed call must be corrected, not silently split.
+  continues; never retry the batch or backfill by hand. Each op takes only its own flags: an
+  unknown flag (say `--status` on `inline actions`) is a usage error (exit 2), and such a call
+  must be corrected, not silently split.
 
 - **A `decide` action (0941)** — the driver never executes the DecisionMaker itself; it delegates
   to the same app runner the engine registers, which writes the resultFile row (schemaVersion 1)
@@ -89,7 +89,7 @@ to exactly that redirect. Capture the output or let it stream; a failure must be
   through the same writer as every other action:
 
   ```bash
-  bun "$SETUP_SCRIPT" --decide --run-id "$RUN_ID" --node <state-id> --options-json <options-file>
+  spur workflow inline decide --run-id "$RUN_ID" --node <state-id> --options-json <options-file>
   ```
 
   The options JSON mirrors the YAML `decide` options (`id`, `method: choice|noul`, `question`,
@@ -102,14 +102,14 @@ to exactly that redirect. Capture the output or let it stream; a failure must be
   `decide node=<id> value=<v> source=<s> reason=<r>` to the run log, so a declared-default
   fallback is never read as a model decision. Only an invalid options
   schema exits `1` (fail closed), and usage errors exit `2`. The `action_runs` trace row is
-  best-effort exactly like `--action`.
+  best-effort exactly like `inline action`.
 
 - **An operator pause is its own row (task 1136 R5)** — while the driver waits on a `hitl.confirm`
   or `hitl.input`, emit the wait as its own boundary instead of charging it to the neighbouring
   node:
 
   ```bash
-  bun "$SETUP_SCRIPT" --action --run-id "$RUN_ID" --node <state-id> --kind operator-wait \
+  spur workflow inline action --run-id "$RUN_ID" --node <state-id> --kind operator-wait \
     --status done --ok true --duration-ms <waited-ms> --project-root "$OWNING_TREE"
   ```
 
@@ -121,7 +121,7 @@ to exactly that redirect. Capture the output or let it stream; a failure must be
   stale:
 
   ```bash
-  bun "$SETUP_SCRIPT" --close --run-id "$RUN_ID" --status <done|failed|paused> --project-root "$OWNING_TREE"
+  spur workflow inline close --run-id "$RUN_ID" --status <done|failed|paused> --project-root "$OWNING_TREE"
   ```
 
   The close also produces the execution summary (1146 R1): its stdout carries
@@ -152,21 +152,21 @@ to exactly that redirect. Capture the output or let it stream; a failure must be
   close with zero rows stays a clean `0` (a halt before the first boundary legitimately records
   nothing), and any `done` close with `actionRows ≥ 1` exits `0`.
 
-**Best-effort at the action boundary only (ADR-117, task 1136 R1/R2).** An `--action` persistence
+**Best-effort at the action boundary only (ADR-117, task 1136 R1/R2).** An `inline action` persistence
 failure is recorded — the delegate appends a `trace-emission-failed` line to
 `.spur/memory/runs/<run-id>.md` and prints `{"ok":false}` on stdout — and the run continues to its
 declared terminal state; the delegate exits `0` for that outcome and the driver must never treat an
 emission failure as a run failure, retry it in a loop, or substitute a hand-written row. The
 exception is the **run row itself**: a missing run row, a duration that cannot be measured, or a
 start time before `runs.started_at` are correctness failures and exit `1`
-(`RUN_NOT_FOUND`, `ACTION_DURATION_UNAVAILABLE`). The run-row closure (`--close`) is bookkeeping, not
+(`RUN_NOT_FOUND`, `ACTION_DURATION_UNAVAILABLE`). The run-row closure (`inline close`) is bookkeeping, not
 trace emission, and is **not** best-effort either: a missing run row or a persistence failure exits
 `1` with `{"ok":false}` and a named error (a missing row also carries `code:"RUN_NOT_FOUND"`),
 because a silently `running` row is exactly the stale state `spur workflow clean` reaps as `failed`.
 Exit `2` means the invocation itself was malformed (missing `--node`/`--kind`/`--status`/`--ok`, a
 miscased `--ok`, or a malformed `--duration-ms`) and must be corrected, not ignored.
 
-**Never suppress this output.** The driver reference forbids redirecting `inline-run-setup`,
+**Never suppress this output.** The driver reference forbids redirecting `spur workflow inline`,
 `quality-gate` and `persist-out*` stdout/stderr to `/dev/null`; a static pin fails any reference
 snippet that does. Suppressing a `RUN_NOT_FOUND` is how task 1132's 93 action rows disappeared.