@gobing-ai/spur 0.3.95 → 0.3.96

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

@@ -64,6 +64,10 @@ function normalizeArgs(raw: Args): Args {
 
 - If `--feature FOO` is present and `--tasks` is absent, treat the effective selector as `feature:FOO`.
 - If both are present, `--tasks` wins (with a one-line note in the batch report).
+- **Per-command admission filters (I33 1023).** Step 1 is the shared baseline; commands may layer
+  stricter grammar on top — e.g. `/sp:dev-review` rejects `ready`/status pseudo-lists and the mixed
+  `--tasks` + `--feature` combination (exit 2), and accepts multi-id `--feature <id>,<id>` as
+  caller-level sugar expanded by the command layer before the resolver.
 
 **Feature-derived strict preflight (R2, task 0510).** After normalization, if the **effective
 selector** is `feature:<id>` (whether via `--tasks feature:<id>` or the `--feature <id>` sugar),
@@ -291,8 +295,8 @@ Each pipeline run ends in one of two terminal states:
 `.spur/run/<wbs>-verify-answer.txt` AC table is exactly four columns:
 `| AC | Status | Evidence Type | Evidence |`. The evidence-type token
 (`test`, `command`, `static-ref`, `manual-review`, `llm-judge`, `n/a`, or a `+`
-compound) is isolated in cell 3. A token merged into the evidence cell fails
-`verify-answer-lint`.
+compound) is isolated in cell 3. A token merged into the evidence cell fails the
+`spur task verdict` answer lint.
 
 **Driver acceptance (0930 R3).** The trace row and `.spur/run/<wbs>-verdict.json` are accepted as
 terminal evidence only if BOTH hold:
@@ -328,40 +332,35 @@ node "$(superskill script path sp batch-preflight.mjs)" --wbs <wbs> --status <st
 Helper: `recoveryHint(status, wbs)` in `plugins/sp/scripts/batch-preflight.ts`. Tables remain SSOT
 in next-router; this only maps status → primary TABLE A hop for recovery.
 
-### 3.3c Bounded feature-sync retry suppression (task 0411)
+### 3.3c Feature-sync retry suppression (task 0411; 1004 R3 moved it into the sync service)
 
 During a batch, the per-task `record` step and the wrap-up `feature-transition` step each invoke
 feature status sync. When a feature is L4-gate-blocked (e.g. not all linked tasks are `done`), the
 identical blocked proposal repeats on every call with no intervening input change — in the H9
-dogfood, 4 redundant sync calls produced the same blocked result. The orchestration seam fixes
-this, not the engine.
+dogfood, 4 redundant sync calls produced the same blocked result. The service fixes this, not the
+engine.
 
 Both `task-pipeline.yaml` (`record` step) and `wrapup-pipeline.yaml` (`feature-transition` step)
-invoke the bounded wrapper instead of raw `feature sync`:
-
-```bash
-node "$(superskill script path sp feature-sync-bounded.mjs)" <feature-id> --spur-bin "<spurBin>" --json
-```
-
-The wrapper:
-
-1. Reads an input fingerprint (feature file content hash, linked task statuses, verdict artifact
-   mtimes) **before** invoking `feature sync`.
-2. Classifies the structured result — `gateBlocked` checked first (a partial hop can have
-   `applied: true` while still gate-blocked), then `applied`, then `no-op`.
-3. On a **blocked** result, persists `.spur/run/feature-sync-blocked-<id>.json` and, on the next
-   call with an **identical fingerprint**, suppresses the redundant sync and replays the prior
-   blocked result.
-4. On **applied** or **no-op** results, passes through unchanged (no suppression).
-5. When the fingerprint **changes** (a task completed, a verdict file updated), suppression is
+invoke `spur feature sync <feature-id> --json` directly — retry suppression lives inside the
+`FeatureService.syncFeature` implementation:
+
+1. On a **blocked** result (`gateBlocked` checked first — a partial hop can have `applied: true`
+   while still gate-blocked — then an unapplied from≠to deferral), the service persists
+   `.spur/run/feature-sync-blocked-<id>.json` keyed by an input fingerprint (feature file content
+   hash, linked task statuses, verdict artifact mtimes).
+2. On the next call with an **identical fingerprint**, the service suppresses the redundant sync
+   and replays the prior blocked result (`suppressed: true`) without re-deriving hops.
+3. On **applied** or **no-op** results, the state file is cleared (no suppression).
+4. When the fingerprint **changes** (a task completed, a verdict file updated), suppression is
    invalidated and a fresh sync runs.
+5. `--force` (and an explicit confirm re-attempt) bypass the replay and re-derive live; dry-run
+   never reads or writes the state.
 
-**Batch driver contract:** the orchestrator does **nothing extra** — the wrapper lives inside the
-pipeline's `record` step and the wrap-up's `feature-transition` step. The driver still launches
-`task-pipeline.yaml` verbatim (R4.1). Suppression is transparent: the wrapper emits the same
-`FeatureSyncResult` JSON shape as `feature sync --json`, so downstream report logic is unchanged.
-The only observable difference is fewer redundant `feature sync` invocations and a one-line
-`feature-sync-bounded:` annotation on stderr when a duplicate is suppressed.
+**Batch driver contract:** the orchestrator does **nothing extra** — the suppression lives inside
+the pipeline's `record` step and the wrap-up's `feature-transition` step. The driver still
+launches `task-pipeline.yaml` verbatim (R4.1). Suppression is transparent: the sync emits the same
+`FeatureSyncResult` JSON shape (`suppressed: true` added on replay), so downstream report logic is
+unchanged. The only observable difference is fewer redundant `feature sync` derivations.
 
 ### 3.4 Metadata-only host controller (R5, task 0510)
 
@@ -513,6 +512,19 @@ 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.
 
+**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
+forwarded task file's leading four digits before `_`) or `<runId>-…` (every run row in the worktree
+DB, whichever task it ran) — `<wbs>-verdict.json`, check receipts, route reasons — whether or not
+the task file cites them. They join the cited set: same copy / byte-identical no-op /
+divergent-refuse handling. The 64-file cap bounds citations alone; owned names are bounded per
+owner (each `<wbs>-` / `<runId>-` prefix gets its own 64-file budget, task 1034), so the bound
+scales with the batch and one runaway owner refuses by name before any write. `<runId>.md` /
+`<runId>.state.json` stay with the record copy (a conflict there is a reported skip). Files
+matching neither a citation nor an ownership prefix are left behind. An absent worktree `.spur/run/`
+means nothing is owned; any other listing failure (not a directory, permission denied) fails the
+pass before the invoking tree is written → WT-5. Without `--task-file` nothing is enumerated.
+
 The shapes are pinned (task 0975 R1; `record-missing` and citation behavior per 0984): 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>"}]}`
@@ -544,6 +556,15 @@ The wrap receives only what it would accept:
 3. When the done subset is **empty**, skip the wrap entirely with the reason (e.g. `batch wrap
    skipped: no done tasks`) instead of invoking wrapup-pipeline on an empty set.
 
+**Repo-wide tripwire (1037).** After the doc-sync exits converge, the pipeline's `doc-tripwire` hop
+runs the TRUSTED CONFIG ONLY `docTripwireCmd` over the still-uncommitted wrap diff before
+metrics-record. The default probes `package.json` for a `test-repo-wide` script and runs
+`bun run test-repo-wide` only when it is declared (a no-op in other projects), so the batch driver
+passes no extra vars. Batch callers override it like any wrap var (`docTripwireCmd` in `--vars`);
+an empty string disables the check while still recording PASS. A FAIL routes the wrap to `failed`
+with already-written learnings/docs preserved — fix the flagged working-diff violation and re-run
+the wrap.
+
 Filtering lives here, in the batch driver — no change to wrapup-pipeline.yaml or wrapup-steps.ts;
 the wrap's refusal of non-done tasks remains the hard invariant.
 
@@ -582,11 +603,14 @@ non-PASS verify verdict, or a HITL pause that ends the run take the WT-5 retenti
 full pipeline is eligible — `--worktree --mode implement` is rejected (WT-7), because that mode is
 the pipeline's implement stage and already runs in the driver's tree.
 
-**Review triage `dev-review` (run of one).** `/sp:dev-review <target> --triage --worktree [<name>]`
+**Review triage `dev-review` (run of one).** `/sp:dev-review [--tasks <selector> | --feature <id>[,<id>] | --scope <path>[,<path>]] --triage --worktree [<name>]`
 runs this lifecycle around one review-plus-triage pass: WT-1…WT-6 apply unchanged, the marker's
-`command` is `dev-review` and its `selector` is the review target, and the slug is the WBS or the
-path's basename (`sp/review-<slug>-<short-id>`). It skips `quickReadiness` (there is no task set;
-admission is "the target resolves"). WT-4 success reads as "every direct fix passed its check and the
+`command` is `dev-review` and its `selector` records the full normalized target list, and the slug
+is `sp/review-<first>-and-<N>-<short-id>` for a multi-target run (N = target count) or
+`sp/review-<slug>-<short-id>` for a single target (the WBS or the path's basename). It skips
+`quickReadiness` (there is no task set; admission is "every target resolves" — each WBS/path must
+resolve before the tree is cut). Under `--triage` the findings are bucketed across all targets once
+(identical `file:line` findings deduped). WT-4 success reads as "every direct fix passed its check and the
 project gate is green"; anything else takes WT-5. Contract: [dev-operations.md § 2. review](dev-operations.md#2-review).
 
 One flag, two modes (see the glossary entry for the ownership rule). Bare `--worktree` is **create
@@ -979,6 +1003,25 @@ Resume, merge, or discard:
   discard: git worktree remove <worktree-path> && git branch -D <branch> && spur projects remove <worktree-path>
 ```
 
+When the halt cause is `non-FF base ref`, the report replaces the one-line `merge:` hint with this
+ordered divergence recipe, run by the operator — the driver never merges, rebases, or resolves
+conflicts itself. Other halt causes (task failure, HITL pause) keep the hint as printed:
+
+```
+# 1. integrate as a merge commit — never a rebase; task evidence cites the branch's commit SHAs
+git checkout <base-ref> && git merge --no-ff --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 (git add …) — an unmerged or
+#    unstaged path makes step 5 abort
+# 4. run qualityGateCmd once, after ALL conflicts are resolved
+# 5. commit the merge with the prepared message file
+git commit -F <message-file>
+# 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 …
+```
+
 The report reuses the [`--next` chain contract](flag-glossary.md#--next-chain-contract) halt-report
 shape (halt cause + where + why), not new vocabulary. Retention is the right default: these batches
 are long and already resumable via `--continue`; auto-deleting is data loss, auto-merging is a
@@ -1156,11 +1199,11 @@ per-task with `/sp:dev-run <wbs> --worktree <branch>`.
 ### Generated regions — defer the sync, regenerate once (R5)
 
 The only per-task writer of feature files is the `record` step's post-record feature sync
-(`task-pipeline.yaml`, the `feature-sync-bounded` wrapper). Parallel launches set
+(`task-pipeline.yaml`). Parallel launches set
 the pipeline var `deferFeatureSync: "true"` (default `"false"`): the record step appends
 `feature sync deferred to batch integration` to the task report and skips the sync, so task
 branches never touch feature files or `docs/features/INDEX.md`. After the last integration, on the
-base ref, the orchestrator runs the same bounded wrapper plus `spur feature refresh --feature <f>`
+base ref, the orchestrator runs `spur feature sync <f> --json` (service-level suppression) plus `spur feature refresh --feature <f>`
 once per touched feature and commits the result as one `chore(corpus)` commit. Sequential and
 inline runs keep the default `"false"` and are unchanged. Any rebase conflict — on a generated
 path or any other — is an R4 `integration-conflict`; there is no path-based exception.

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

@@ -47,7 +47,7 @@ one thing and yields, so the **pipeline (not the agent) owns the loop**.
 | ------- | ----------- | ------------ |
 | `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 |
-| `review` | `/sp:dev-review <wbs>` — SECUA-framework review of the diff. | [dev-operations.md §2 review](dev-operations.md) |
+| `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
@@ -96,10 +96,7 @@ cache-conservation discipline (`plugins/sp/skills/dogfood-testing/references/mon
 
 ## Step 2: Pipeline run
 
-> **Pre-launch size-gate pre-check (R1 / 0478).** Before launching `spur workflow run task-pipeline.yaml`, probe the task's `## Plan` checklist item count (`spur task show <wbs> --json`). The default cap is 8 items (`maxImplementPlanItems: 8`). If the plan item count exceeds 8:
->
-> - Without `--auto`: warn the operator before calling `spur workflow run` and prompt for confirmation or a plan-item override via `--vars '{"maxImplementPlanItems":"<count>"}'`.
-> - With `--auto`: automatically append `"maxImplementPlanItems": "<count>"` to `--vars` and log a single-line notice (e.g. `Notice: task <wbs> has N plan items (>8 default cap); injecting maxImplementPlanItems override`).
+> **Pre-launch size-gate pre-check (R1 / 0478; task 1002).** Before launching `spur workflow run task-pipeline.yaml`, run `spur task check <wbs> --precheck --json` — the same command the pipeline's precheck guard runs. It fails with a `precheck-size` finding above 10 requirements or 16 Plan items. The limits are fixed (no `--vars` override): on a failure, split the task instead of launching.
 
 **`--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
@@ -336,10 +333,9 @@ task.** A `cheap`/`standard`-tier model handed a task that big does not fail fas
 entire `implementTimeoutMs` and exits 3 with a partial tree (run `ca130182` — 7 reqs / 9 plan
 items / 12+ files → 30 minutes, 6 of 12 files, no tests, no docs, no `## Solution`).
 
-The precheck size gate is count-only: it writes FAIL above 10 requirements or 16 Plan items and
-never consults the executor's capability tier. Clear a FAIL deliberately — split the task, or raise
-the cap with `--vars '{"maxImplementReqs":<n>}'` — but the caps only accept a big task, they do not
-make a flash model able to finish one.
+The precheck size gate (`spur task check <wbs> --precheck`) is count-only: it fails above 10
+requirements or 16 Plan items and never consults the executor's capability tier. The limits are
+fixed — clear a failure by splitting the task.
 
 The empty-implement guard (`requireDiff` on the task-pipeline `implement` step, R3) fails the
 run fast when an implement exits 0 with zero non-corpus changes — a no-op never drifts into

package/plugins/sp/skills/spur-dev/references/feature-link-helper.md

@@ -11,13 +11,13 @@ see_also:
 **Scope:** opt-in, strictness-triggered — never gate-time, never automatic.
 
 This helper resolves a deferred `feature_id` edge when the operator explicitly invokes or intends
-`--strict` rigor, or asks to "link this task to a feature." It is **NOT** part of the `--strict-core`
+`--strict` rigor, or asks to "link this task to a feature." It is **NOT** part of the `--as done`
 done-gate, NOT in any `--next` chain, and NOT triggered automatically. Invoking it is always an
 explicit operator choice.
 
 **Design boundaries (enforced):**
 
-- `feature_id: null` is a valid, supported state under the default done-gate (`--strict-core`). Deferral is legitimate.
+- `feature_id: null` is a valid, supported state under the default done-gate (`--as done`). Deferral is legitimate.
 - This helper fires only when the operator opts in — it does NOT change the L4 warning severity.
 - It NEVER creates a new feature without operator confirmation.
 - It ALWAYS prefers matching an **existing** feature before proposing creation.
@@ -30,7 +30,7 @@ explicit operator choice.
 - A deliberate traceability audit: `spur task check --strict` across the corpus reveals N orphan tasks.
 
 **Do NOT invoke from:**
-- The `--strict-core` done-gate (it must stay feature_id-agnostic)
+- The `--as done` done-gate (it must stay feature_id-agnostic)
 - Any `--next` chain or automated pipeline step
 - Any context where the operator has not explicitly requested strict rigor or linking
 

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

@@ -43,7 +43,7 @@ as a follow-up, not quietly left inconsistent.
 `implementAgent` override, objective triggers, and surface-derivation logic — lives in
 [cross-cutting.md](cross-cutting.md#inline-default-execution-surface).
 The value table below is the C3a cross-file parity surface (kept in lockstep with the SSOT by
-`validate-flag-contracts.ts`), not an independent restatement.
+`scripts/commands/validate-flag-contracts.ts`), not an independent restatement.
 
 | Value                           | Who does the work                                                           | Derived surface                                                             |
 | ------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
@@ -126,6 +126,10 @@ Skip objective HITL confirmations inside this command (feature-check, batch-crea
 gate). Taste gates and irreversible HITL gates (e.g. `--merge`) still pause even under `--auto`.
 Only declared where the command already has at least one HITL gate the flag can skip.
 
+**Planning exception** (`dev-idea`, `dev-plan`): `--auto` also accepts the recommendation at the
+taste gates (idea-eval, design-approval) — every gate there is reversible corpus writes. A gate
+without an actionable recommendation (missing eval recommendation, FAIL design check) still pauses.
+
 ### `--keep-going` — batch failure policy: skip dependents, continue independents
 
 **Anchor:** `#flag-keep-going`.
@@ -177,7 +181,8 @@ forced. Never bypasses lifecycle status transitions or irreversible HITL gates.
 
 Scope the operation to all tasks under a feature id (`^[A-Z][1-9]*$`). On feature-advancing
 commands (`dev-wrapall`) it also advances the feature through legal lifecycle edges with guards
-honored.
+honored. On `dev-review` it takes a comma list (`--feature <id>[,<id>]`) — sugar for the union of
+the `feature:<id>` sets, resolved once and frozen.
 
 ### `--check <cmd>` — validation command for iterate-and-check loops
 
@@ -190,11 +195,13 @@ establishes a baseline with it before the first change and re-runs it after each
 
 **Anchor:** `#flag-focus`.
 
-Constrain the operation to a named subset of dimensions — review dimensions on `dev-review`/
-`dev-verify`/`dev-verifyall` (`all|stack|dependencies|data|flows|api|security|quality|performance`),
-a refactor lens set on `dev-refactor` (`api|architect|tests|ui|auto`), a refine focus mode on
+Constrain the operation to a named subset of dimensions — review dimensions on `dev-review`
+(vocabulary SSOT: [code-verification/SKILL.md](../../code-verification/SKILL.md) review mode —
+`dev-verify`/`dev-verifyall` keep their SECUA-only lens set), a refactor lens set on
+`dev-refactor` (`api|architect|tests|ui|auto`), a refine focus mode on
 `dev-refine`/`dev-refineall` (`all|requirements|background|constraints|acceptance|quick` —
-[dev-operations.md](dev-operations.md) § refine), or a reconstruction lens on `dev-reverse`.
+[dev-operations.md](dev-operations.md) § refine), or a reconstruction lens on `dev-reverse`
+(`all|stack|dependencies|data|flows|api|security|quality|performance`).
 Narrowing reduces token cost; omitting runs
 all dimensions.
 
@@ -203,7 +210,9 @@ all dimensions.
 **Anchor:** `#flag-scope`.
 
 Limit the operation to a file or directory path (`dev-arch`, `dev-debug`, `dev-fixall`,
-`dev-gitmsg`, `dev-gtd`, `dev-refactor`, `dev-simplify`) to bound the working set.
+`dev-gitmsg`, `dev-gtd`, `dev-refactor`, `dev-review`, `dev-simplify`) to bound the working set.
+On `dev-review` it takes a comma list of paths — normalized, nested and duplicate paths merged,
+one advisory sub-review per surviving path.
 
 ### `--all` — widen the operation to everything in its domain
 
@@ -226,11 +235,13 @@ is the contract; divergence between `--dry-run` and the real run is a bug.
 
 **Anchor:** `#flag-tasks`.
 
-Batch operation only (`dev-parallel`, `dev-refineall`, `dev-runall`, `dev-verifyall`). An explicit selector — WBS
-list, status pseudo-list (`todo`, `wip`), `feature:<id>`, or `ready` — resolving to the set the
-batch runs over. Required on `dev-parallel`, `dev-runall`, and `dev-verifyall`, where `--feature` is an optional
-restrictor. On `dev-refineall` it is instead one of a required pair — supply exactly one of
-`--feature` or `--tasks`.
+Batch operation (`dev-parallel`, `dev-refineall`, `dev-review`, `dev-runall`, `dev-verifyall`). An
+explicit selector — WBS list, status pseudo-list (`todo`, `wip`), `feature:<id>`, or `ready` —
+resolving to the set the batch runs over. On `dev-review` the selector is restricted to the
+review-safe forms: comma WBS list and `feature:<id>` — status pseudo-lists and `ready` are
+rejected (they select work to do, not work to review). Required on `dev-parallel`, `dev-runall`,
+and `dev-verifyall`, where `--feature` is an optional restrictor. On `dev-refineall` it is instead
+one of a required pair — supply exactly one of `--feature` or `--tasks`.
 
 ### `--mode <kind>` — select an execution mode
 
@@ -352,11 +363,18 @@ pauses, even under `--auto`.
 
 **Anchor:** `#flag-max-retry`.
 
-Bound the retry loop on fix-family commands (`dev-dogfood`, `dev-fixall`, `dev-gtd`). After `n` consecutive
+Bound the retry loop on fix-family commands (`dev-dogfood`, `dev-fixall`, `dev-fixgha`, `dev-gtd`). After `n` consecutive
 failed fix attempts, stop and ask the operator rather than looping indefinitely. On `dev-dogfood`
 the default is `2` (fix mode) and `--max-retry 0` selects observe-only — matching the backing
 `sp:dogfood-testing` skill; the command table and the skill must not drift on this default.
 
+### `--no-push` — commit locally, stop before push
+
+**Anchor:** `#flag-no-push`.
+
+Commit the fixes locally but do not `git push` or run the post-push `gh` verification
+(`dev-fixgha`, `dev-gtd`). The report lists the unpushed commits.
+
 ### `--full` — rewrite a `--next` run as full pipeline
 
 **Anchor:** `#flag-full`.
@@ -421,14 +439,6 @@ remainder through `spur task` — never fix straight from the raw findings list.
 features ([dev-operations.md § 2. review](dev-operations.md#2-review)); `dev-review-session` keeps
 the stricter direct-fix bar (pure docs / one-to-two-line fixes).
 
-### `--approve-taste` — pre-clear all taste gates this run
-
-**Anchor:** `#flag-approve-taste`.
-
-Planning commands (`dev-idea`, `dev-plan`): with `--auto`, skip all remaining taste pauses this
-run (idea-eval + design-approval). Sets `idea_approved=true` and `design_approved=true`. One CLI
-flag sets both.
-
 ### `--worktree [<name>]` — run the batch in an isolated git worktree (create or reuse)
 
 **Anchor:** `#flag-worktree`.

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

@@ -72,16 +72,15 @@ Entered before `task-pipeline.yaml` `precheck` state runs `spur task check <wbs>
 - [ ] The `## Plan` section is an ordered checklist (not prose).
 - [ ] The `## Design` section, if present, does not contradict the parent feature's design.
 - [ ] No `TODO`, `TBD`, or `???` placeholders in Requirements, AC, Design, or Plan.
-- [ ] The evidence-channel precheck (0726 R2) status file is consulted by the
-      pipeline guard: `plugins/sp/scripts/task-evidence-precheck.ts` parses the task
-      content for an exact `evidence-channel: history_tool_call.args_raw[pi]`
+- [ ] The evidence-channel precheck (0726 R2, folded into the pipeline guard by 1002) is
+      enforced by `spur task check <wbs> --precheck` — the guard command itself. It parses the
+      task content for an exact `evidence-channel: history_tool_call.args_raw[pi]`
       declaration and, when present, counts live pi rows with `args_raw` on
-      `.spur/spur.db` via bun:sqlite. Tasks without a declaration pass without opening
-      SQLite; unknown declarations, a missing database/table, and a zero count write
-      FAIL. Both precheck guard conjuncts (`precheck-size.status` and
-      `precheck-evidence.status`) must read PASS — tasks declaring a live-data
-      evidence channel must import real history (safe importer, non-dry-run) before
-      implementation begins.
+      `.spur/spur.db` via the domain read (fail-closed: unknown declarations, a missing
+      database/table, and a zero count error). Tasks without a declaration pass without
+      opening the database; size limits (10 R-items / 16 plan items) are checked in the
+      same call. Tasks declaring a live-data evidence channel must import real history
+      (safe importer, non-dry-run) before implementation begins.
 
 ## review gate
 
@@ -102,12 +101,13 @@ Entered before `task-pipeline.yaml` `review` state dispatches `sp:code-verificat
 Entered before `task-pipeline.yaml` `verify` state produces a task verdict.
 
 - [ ] The verify answer file (`.spur/run/<wbs>-verify-answer.txt`) is lint-clean before
-      verdict derivation: `plugins/sp/scripts/verify-answer-lint.ts <wbs>` (0726 R3)
-      rejects missing/duplicate/unknown R IDs, AC identities that are not an exact task
-      checklist label or linked-feature scenario title, invalid status/evidence-type
-      values, and empty evidence on any row. A lint failure fails the verify
-      step (fail-closed) before `spur task verdict` runs.
-- [ ] `spur task check <wbs> --strict-core --json` returns PASS.
+      verdict derivation: `spur task verdict <wbs> --from-answer …` (0726 R3) lints the
+      file first and rejects missing/duplicate/unknown R IDs, AC identities that are not an
+      exact task checklist label or linked-feature scenario title, invalid status/evidence-type
+      values, and empty evidence on any row. A lint failure fails the verdict step
+      (fail-closed) before verdict derivation; an unresolvable task file fails open so
+      pre-lint historical runs (8001–8005) stay reproducible.
+- [ ] `spur task check <wbs> --as done --json` returns PASS.
 - [ ] Every AC scenario has a corresponding verify command that exited 0.
 - [ ] The `## Solution` section is filled (not the placeholder comment).
 - [ ] The `## Testing` evidence (commands run + outcomes) is present in the verdict artifact —
@@ -143,19 +143,19 @@ bounded retry does not.
 ### The three `testing → done` gate layers
 
 The CLI verdict-artifact check runs first. The lifecycle adapter then checks provenance, Review L3,
-and finally the workflow's strict-core shell guard. The table groups the two complementary
-strict-core/verdict checks as one defense-in-depth layer even though they bracket the adapter checks.
+and finally the workflow's `task check --as done` shell guard. The table groups the two complementary
+done-row/verdict checks as one defense-in-depth layer even though they bracket the adapter checks.
 The first denial wins; each denial names its own remediation. In verify-0293, the artifact check
 passed, so provenance denied first and Review L3 denied on the retry.
 
 | # | Gate layer | Triggers denial when | Remediation |
 |---|------------|----------------------|-------------|
-| 1 | **Strict-core + verdict artifact** (`spur task check <wbs> --strict-core` + `done-transition-guard.ts`) | The strict-core check fails, or `.spur/run/<wbs>-verdict.json` is **missing** or has a non-PASS aggregate. **Missing artifact is a deny** (not a silent allow — closes the 0349 "done without verdict" class). The aggregate is recomputed from requirement/AC rows; the harsher of stored and computed wins. | Re-run `/sp:dev-verify <wbs>` until PASS (writes the artifact), or explicitly override with `spur task update <wbs> done --force-done --reason "<why>"`. Docs-only procedures meet the same layer: read-only measured verification
+| 1 | **Done-row check + verdict artifact** (`spur task check <wbs> --as done` + `done-transition-guard.ts`) | The done-row check fails, or `.spur/run/<wbs>-verdict.json` is **missing** or has a non-PASS aggregate. **Missing artifact is a deny** (not a silent allow — closes the 0349 "done without verdict" class). The aggregate is recomputed from requirement/AC rows; the harsher of stored and computed wins. | Re-run `/sp:dev-verify <wbs>` until PASS (writes the artifact), or explicitly override with `spur task update <wbs> done --force-done --reason "<why>"`. Docs-only procedures meet the same layer: read-only measured verification
 (answer file + `spur task verdict`) writes the standard `.spur/run/<wbs>-verdict.json` artifact
 under proof-input digest bracketing; missing or non-PASS evidence is a refusal, never a synthetic
 PASS stub. |
 | 2 | **Provenance guard** (`lifecycle-adapter.ts`) | No pipeline-kind run link exists for `<wbs>`. | Run `/sp:dev-run <wbs>` through the full pipeline, use `/sp:dev-run <wbs> --mode implement --auto --next` for the explicit step chain, or record the audited bypass with `--provenance-bypass` on `spur task update`. |
-| 3 | **Review L3** (`task-check.ts`) | `### Review` is empty, placeholder-only, or lacks a populated P1–P4 findings table. | Run `/sp:dev-review <wbs>`; verify cannot write Review because of the Step 10 prohibition above. |
+| 3 | **Review L3** (`task-check.ts`) | `### Review` is empty, placeholder-only, or lacks a populated P1–P4 findings table. | Run `/sp:dev-review --tasks <wbs>`; verify cannot write Review because of the Step 10 prohibition above. |
 
 When the verdict is **PARTIAL/FAIL**, or any gate layer fails: stop as review-pending — surface
 the verdict (or the gate's blocking finding), leave the task at its current status, do NOT

package/plugins/sp/skills/spur-dev/references/idea-evaluation.md

@@ -33,7 +33,7 @@ before any processing); the `## Requirement inventory` items trace back to it.
 <one-paragraph refined statement of what the idea actually requires — the "real requirement" after discovery sharpens the vague input>
 
 ## Requirement inventory
-<mandatory — the coverage gate (idea-coverage-check) parses this section, so keep the exact `- I<n> — ` item form>
+<mandatory — the coverage gate (`feature check --inventory`) parses this section, so keep the exact `- I<n> — ` item form>
 - I1 — <requirement stated as an ask, quoting or paraphrasing the source line from the run's idea-input artifact> (source: "<quoted fragment from the operator's idea>")
 - I2 — <next requirement>
 - I<n> — <optional: a requirement explicitly out of scope> [deferred: <reason>]
@@ -68,6 +68,7 @@ Score guide:
 
 ## Recommendation
 <proceed | reshape | drop> — <one-line rationale linking scores, premises, and pros/cons>
+<!-- the first line under this heading MUST start with exactly one of proceed / reshape / drop — `--auto` routes on it -->
 
 Stakes: <plain-English cost of proceeding vs not; reversibility; blast radius>
 
@@ -83,8 +84,8 @@ Stakes: <plain-English cost of proceeding vs not; reversibility; blast radius>
 |------|--------|
 | Filled instance path | `.spur/run/idea-eval-report.md` |
 | Template home | this file |
-| Requirement inventory | mandatory `## Requirement inventory` section (0887 R3); consumed by `idea-coverage-check` (R4) |
+| Requirement inventory | mandatory `## Requirement inventory` section (0887 R3); consumed by the `feature check --inventory` coverage gate (R4) |
 | HITL state | `idea-eval` in `idea-pipeline.yaml` |
 | Approve | continue → `feature-create` |
 | Reject / cancel | → `cancelled` (no feature) |
-| `--auto` | still pauses unless taste pre-cleared (`--approve-taste` → `idea_approved=true`) |
+| `--auto` (`idea_approved=true`) | `proceed`/`reshape` → `feature-create`; `drop` → `cancelled`; missing/unparseable recommendation → pauses |

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

@@ -2,7 +2,7 @@
 name: inline-pipeline-driver
 description: "Interactive host-session interpreter for Spur state-machine pipelines: execute the existing FSM without a workflow agent subprocess while preserving actions, guards, artifacts, and provenance."
 owner: spur-dev-maintainers
-retirement-criterion: "The per-task interpreter retires once the engine covers per-task execution for /sp:dev-runall with real terminal runs and the parity check (plugins/sp/scripts/inline-pipeline-parity-check.ts) is green (D8 decision D7). Batch orchestration wrapper may remain."
+retirement-criterion: "The per-task interpreter retires once the engine covers per-task execution for /sp:dev-runall with real terminal runs and the parity check (scripts/commands/inline-pipeline-parity-check.ts) is green (D8 decision D7). Batch orchestration wrapper may remain."
 see_also:
   - spur-dev
   - execution-workflow
@@ -18,7 +18,7 @@ see_also:
 ## Supported action and guard set (0755 R2 parity contract)
 
 The action and guard kinds this driver implements. The parity check
-(`plugins/sp/scripts/inline-pipeline-parity-check.ts`) compares this set against
+(`scripts/commands/inline-pipeline-parity-check.ts`) compares this set against
 the resolved actions and guards of every `.spur/workflows/*.yaml`; any element present
 in one and absent in the other fails the check. Add a new kind here when the driver
 implements it; remove the entry when the corresponding kind is dropped from the YAML.
@@ -201,7 +201,7 @@ Expected artifacts per stage (all run-scoped under `.spur/run/<run-id>-*`):
 | start | `-idea-input.md` (verbatim idea), `-idea-precheck-doctor.status` |
 | discovery | `-idea-eval-report.md` (with `## Requirement inventory`), `-idea-needs-design.json` |
 | feature-create | `-idea-feature-id.txt`, `-idea-goal.md`, `-idea-scope.md` |
-| ac-generate | `-idea-ac-content.md`, `-idea-ac-check.status`, `-idea-coverage.status` |
+| ac-generate | `-idea-ac-content.md`, `-idea-ac-check.status` |
 | system-design | `-idea-design-review.md`, `-idea-design-check.status` |
 | decompose | `-idea-task-batch.json`, `-idea-task-order.json` |
 | batch-create-run | `-idea-batch-create-result.json`, `-idea-batch-create.done`/`.failed` |
@@ -247,6 +247,13 @@ Action semantics come from the YAML and the workflow action contract:
   actions/guards.
 - `hitl.confirm` — under `profile=auto`, follow the YAML's auto-skip transition. Otherwise pause,
   surface the prompt, and resume from the same state with the operator's answer.
+  **Host-session rendering:** ask the gate as ONE `AskUserQuestion`
+  [decision brief](decision-brief.md), never a typed yes/no. Read the state's evidence (the
+  artifacts its prompt names and the recorded `.status` files) and derive the recommendation;
+  map options to the `yes` / `no` / `cancel` answers the guards route on, recommended option
+  first, each with a one-line reason from that evidence. When a `no` needs operator feedback
+  (design-approval's `## Operator feedback`), take it from the operator's notes/"Other" text
+  and write it into the named artifact yourself before resuming. Never ask them to edit the file.
 - `hitl.input` — pause, surface the declared prompt (the agent's operator question, 0933), and
   resume from the same state with the operator's answer written into the declared var (default
   `__hitlInput`); the subsequent guards route on answer presence exactly as the engine does.
@@ -500,6 +507,25 @@ The driver reaches it through the existing run delegate (`$SETUP_SCRIPT`,
   (0887 R8), so `completed_at − started_at == duration_ms` exactly; a back-date failure is
   recorded (`action.backdate`) and never affects the run.
 
+- **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}, …]` — same fields the `--action` flags carry) to a temp
+  file and pass it with `--actions-file`:
+
+  ```bash
+  bun "$SETUP_SCRIPT" --actions-file <actions.json> --run-id "$RUN_ID"
+  ```
+
+  Every row is recorded through the same writer as `--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
+  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.
+
 - **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)
   and returns the decision, then the delegate records the `action_runs` row (`kind=decide`)

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

@@ -105,7 +105,7 @@ rows stay per file. Flagged rows wait for the operator's answer.
 
 ## Workflow step profile and cache-window flags
 
-The step profile (`plugins/sp/scripts/workflow-step-profile`, ADR-065 plugin entrypoint) reads
+The step profile (`plugins/sp/scripts/workflow-step-profile`, ADR-065 plugin entrypoint whose aggregation core lives in `packages/app/src/workflow/step-profile.ts`) reads
 `spur workflow trace` for a workflow's last N completed, non-dry runs. Per node and action kind it
 reports run count, executions, p50 and max `durationMs`, p50 idle gap before the step, session mode
 (`fresh`, `resumed` or `mixed`) and `cacheHit` p50 with its coverage — satellite §10 step evidence.

package/plugins/sp/skills/sys-architecture/SKILL.md

@@ -73,8 +73,9 @@ codebase (or a named module tree) for **shallow modules and deepening opportunit
 them as candidates for the planning half. This is a *generator*, not a fixer — it never refactors;
 it produces a ranked candidate report an operator can turn into a task.
 
-**Not `/sp:dev-review`.** `/sp:dev-review` is a per-task DIFF review (a WBS, forward, findings written
-to the task's `## Review`, backed by `sp:code-verification`). The survey has no WBS and no diff — it
+**Not `/sp:dev-review`.** `/sp:dev-review` is a DIFF review of a task set (`--tasks`/`--feature`) or an advisory `--scope` path review
+(task targets: forward, findings written to each task's `## Review`; paths: advisory report, no task
+mutation; backed by `sp:code-verification`). The survey has no task set and no diff — it
 audits the standing codebase and feeds the planning half. Folding it into `dev-review` would overload
 that verb and pollute `code-verification` with a codebase scanner; it earns its own operation here.