@gobing-ai/spur 0.3.94 → 0.3.96

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.
@@ -76,11 +76,14 @@ the human/native presentation layer — labels are display addresses only, never
    accept the inline run (0785 R3):
 
    ```bash
-   SETUP_SCRIPT="plugins/sp/scripts/inline-run-setup.ts";
-   [ -f "$SETUP_SCRIPT" ] || SETUP_SCRIPT="$(superskill script path sp inline-run-setup.mjs 2>/dev/null)";
+   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'" >&2; exit 1; }
+     || { echo "inline run setup failed closed — checker not found; run 'superskill install sp --marketplace gobing-ai/spur'" >&2; exit 1; }
    ```
 
    The delegate uses the source app service when the SPUR_BIN chain identifies a checkout;
@@ -198,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` |
@@ -244,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.
@@ -497,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.
 

package/plugins/sp/tsconfig.json

@@ -0,0 +1,8 @@
+{
+    "extends": "../../tooling/typescript/base.json",
+    "compilerOptions": {
+        "types": ["bun"],
+        "paths": { "@gobing-ai/spur-app": ["../../packages/app/src/index.ts"] }
+    },
+    "include": ["**/*.ts"]
+}