@gobing-ai/spur 0.3.43 → 0.3.45

package/plugins/sp/plugin.json

@@ -1,6 +1,6 @@
 {
     "name": "sp",
-    "version": "0.3.43",
+    "version": "0.3.45",
     "description": "Spur — a local-first harness engineering toolkit that wraps mainstream coding agents with constraint checking, workflow orchestration, and history analytics.",
     "extensions": {
         "pi": ["./hooks/pi/guard-extension.ts"]

package/plugins/sp/skills/next-feature/SKILL.md

@@ -40,9 +40,9 @@ in this corpus it is 76% one value (0493 measurement).
 **Propose, never apply.** This skill performs no `spur feature move` and writes nothing under
 `docs/features/**`. The only path from a structure proposal to a changed tree is
 `/sp:dev-featurechange` (dry-run → confirm → apply). Ranking runs are read-only; the sole exception is
-`--task`, which after an **explicit operator confirm** dispatches `/sp:dev-plan` and
-`/sp:dev-refineall` — commands that write `docs/tasks*/` through their own gates. This skill still
-creates no tasks itself.
+`--task`, which after an **operator confirm** (interactive, or auto-accepted under `--auto`)
+dispatches `/sp:dev-plan` and `/sp:dev-refineall` — commands that write `docs/tasks*/` through their
+own gates. This skill still creates no tasks itself.
 
 ## When to Use
 
@@ -89,13 +89,16 @@ Run the steps in order. Each step's depth lives in its reference; this file is t
    at the ranking; advancing a chosen feature is `/sp:dev-next`'s job.
 7. **`--task` only — confirm, then dispatch the planning half.** Offer the rank-1 candidate (or the
    id passed as `--task <feature-id>` — which may name a **gated** feature, since T2/T3/T4 are tiers
-   the rubric assigns to the gated list and only T1 comes from the ranked frontier), take an
-   **explicit** operator confirmation, then route on the
-   tier step 4 already assigned: T3 with zero tasks → `/sp:dev-plan --feature <id>` then
-   `/sp:dev-refineall --feature <id> --auto --depth ready`; T1 → refineall only; T3 with invalid AC,
-   T2, and T4 stop with their reason. **This skill creates no tasks itself** — the dispatched
-   commands own decomposition and its schema gate. The confirm pauses regardless of `--auto`. Full
-   contract: [references/handoff-routing.md](references/handoff-routing.md).
+   the rubric assigns to the gated list and only T1 comes from the ranked frontier). **Without
+   `--auto`:** take an explicit operator confirmation (accept the offer, name another candidate, or
+   decline). **With `--auto`:** auto-accept the offered target (rank-1 for bare `--task`, or the
+   explicit id) — the flag is operator pre-consent to take the ranking's recommendation — then
+   proceed without a HITL pause. Route on the tier step 4 already assigned: T3 with zero tasks →
+   `/sp:dev-plan --feature <id>` then `/sp:dev-refineall --feature <id> --auto --depth ready`; T1 →
+   refineall only; T3 with invalid AC, T2, and T4 stop with their reason. **This skill creates no
+   tasks itself** — the dispatched commands own decomposition and its schema gate. Forward `--auto`
+   into the dispatched children. Full contract:
+   [references/handoff-routing.md](references/handoff-routing.md).
 
 ## Anti-patterns — do not do these
 
@@ -105,9 +108,10 @@ Run the steps in order. Each step's depth lives in its reference; this file is t
 - Copying the B3 predicate into this skill. Cite it; read it at runtime.
 - Any `spur feature move`, or writing proposals anywhere `docs/features/**` — featurechange owns apply.
 - Decomposing a feature here, or calling `spur task create` / `spur task batch-create` under `--task`.
-  Dispatch `/sp:dev-plan`; it owns decomposition and the batch-create schema gate. Equally: skipping
-  the `--task` confirm because `--auto` was passed, or decomposing a T1 feature that already has a
-  live task frontier.
+  Dispatch `/sp:dev-plan`; it owns decomposition and the batch-create schema gate. Equally:
+  dispatching under `--auto` without `--task` (there is no confirm to skip), auto-accepting a target
+  other than the offer / named `--task <id>`, or decomposing a T1 feature that already has a live
+  task frontier.
 - Padding the defect list with tidiness findings that move no rank.
 - Re-proposing F31's rejected merges (B∪H, J∪K body-merge) or reading
   `## Applied mapping` as current state — letters are recycled; resolve against live features.

package/plugins/sp/skills/next-feature/references/handoff-routing.md

@@ -65,15 +65,20 @@ survivors would make its primary case unreachable. Offer the rank-1 ranked candi
 | **T2 — unblock first** | gated on a blocker | **Refuse.** Name the blocker and its owner. Tasks created under a blocked feature cannot run. |
 | **T4 — stale-done** | post-sync status would be `done` | **Refuse.** Route to `/sp:dev-wrapall --feature <id>` or the sync-first block; the work is finished, not startable. |
 
-### The confirmation is unconditional
+### The confirmation — interactive by default, auto-accepted under `--auto`
 
 | Rule | Detail |
 | --- | --- |
-| Default offer | The rank-1 candidate. The operator may confirm it, name another candidate from the report, or decline. |
-| `--task <feature-id>` | An explicit id skips the *default-offer* step. It does **not** skip the confirm. |
-| `--auto` | Forwarded to the dispatched children (`dev-plan --auto`, `dev-refineall --auto`). It **never** answers the confirm — choosing what to invest in is a taste decision (Auto-Decision Principle #5), and `ranking-rubric.md` already states the operator overrides the ranking. |
-| No escape | There is no `--yes` / `--force` bypass. No path exists from `--task` to a created task file without an explicit operator decision. |
-| Refusal | Declining ends the run at the report. Nothing is written. |
+| Default offer | The rank-1 candidate. Without `--auto`, the operator may confirm it, name another candidate from the report, or decline. |
+| `--task <feature-id>` | An explicit id becomes the offered target (skips the *default-offer* step). Without `--auto` it still requires confirm; with `--auto` the named id is auto-accepted. |
+| `--auto` | **Two effects:** (1) auto-accept the offered target — rank-1 for bare `--task`, or the explicit `--task <feature-id>` — without a HITL pause; (2) forward into the dispatched children (`dev-plan --auto`, `dev-refineall --auto`). Passing `--auto` is operator **pre-consent** to take the ranking's recommendation (streamline path); it does **not** invent a different target, and it does **not** bypass T2/T4 refuse or invalid-AC stop. Without `--task`, `--auto` is a no-op (ranking-only has no HITL). |
+| Report the accept | When `--auto` accepts, print a one-line note: `auto-accepted target <id> (tier <Tn>) via --auto` so the transcript records the decision. |
+| Refusal | Declining (interactive path only) ends the run at the report. Nothing is written. |
+
+**Why this is not a Principle #5 taste auto-click.** The ranking already produced the recommendation;
+`--auto` only skips the *proceed-with-offer* pause. Overriding the ranking (picking a non-offered
+candidate) still requires the interactive confirm path. Architecture / design-approval taste gates
+inside dispatched children remain governed by their own contracts (`--approve-taste` where applicable).
 
 ### What `--task` does not change
 
@@ -89,4 +94,4 @@ adds one gated path to `docs/tasks*/`, through commands that own their own gates
 | Defect proposals | stdout; optionally appended to `docs/plans/feature-tree-restructure-map.md` |
 | "Sync first" block | top of report when the dry-run proposes frontier changes |
 | Winner handoff | printed `/sp:dev-next <id>` hint — operator runs it |
-| `--task` dispatch | after an explicit confirm: `/sp:dev-plan` and/or `/sp:dev-refineall`, which write `docs/tasks*/` through their own gates |
+| `--task` dispatch | after confirm (interactive) or auto-accept (`--auto`): `/sp:dev-plan` and/or `/sp:dev-refineall`, which write `docs/tasks*/` through their own gates |

package/plugins/sp/skills/next-feature/references/signal-derivation.md

@@ -19,6 +19,11 @@ status on sync). Rules:
 - Urgency signals premised on raw `status` (sunk-work decay, WIP pressure, staleness) are computed
   only against the post-sync view — 0493 rejected all three as standalone signals; post-sync they
   survive only as tie-break texture (see ranking-rubric.md).
+- The dry run is captured **exactly once per run**; the captured result is the sole source of the
+  post-sync status view for protocol steps 1–4 (gating, roster completion, and signal derivation
+  all read the same in-memory capture). This is a prompt-run capture, not a cache/state file: the
+  run never issues a second `spur feature sync --all --dry-run --json` call, and no other verb
+  reproduces it in this run.
 
 ## §1 — Actionability gate (runtime citation, never restated)
 
@@ -32,11 +37,34 @@ Inputs per candidate feature:
 spur task list --feature <id> --json
 ```
 
-Apply B3 over the feature's tasks. **Zero actionable tasks ⇒ gated, not ranked.** Record the gating
+`task list --feature` is **active-folder-only**: it enumerates tasks in the active task folder
+(`.spur/config.yaml`) and omits linked tasks archived in the other configured folders. Apply B3 over
+that list. **Zero actionable tasks ⇒ gated, not ranked.** Record the gating
 reason verbatim for the report's gated list: `all tasks terminal` / `blocked: <task wbs> — <reason>`
 / `no tasks`. A blocked task with no corpus dependency is an **external** block (approval, trigger) —
 report it as such; it is not satisfiable by ranking other work first.
 
+**Complete the roster before declaring terminal or empty.** If the active view yields no B3
+frontier candidate and the tentative reason is `all tasks terminal` or `no tasks`, the active view
+is not authoritative — a frontier task may be archived outside it. Run the fallback once:
+
+1. Consult the §0 capture (the run's single `spur feature sync --all --dry-run --json` result) for
+   the feature's row as an **anomaly hint** only: it may flag the feature without naming a WBS. The
+   sync reason is never treated as a WBS source — no WBS is ever inferred from sync prose.
+2. Scan the whole corpus for linked tasks:
+   ```bash
+   rg -l '^feature_id: "?<id>"?$' docs/tasks*/
+   ```
+   Corpus ids are `[A-Z][0-9]+`-shaped, so `<id>` is regex-safe as-is; escape metacharacters if a
+   non-conforming id ever appears.
+3. Parse the leading WBS from each matched basename; resolve every corpus-only WBS (not present in
+   the active list) with `spur task show <wbs> --json`.
+4. Union the active-list records with the resolved corpus records, deduplicate by WBS, and reapply
+   runtime B3 to the complete set.
+5. Record the gating reason from the complete roster. If the union exposes a blocked task that the
+   active view omitted, the classification is `blocked: <task wbs> — <reason>` — never `all tasks
+   terminal` — with the blocker text taken from the resolved task body, not from sync prose.
+
 ## §2 — The four surviving signals
 
 0493 measured eight candidate signals over this corpus; exactly four discriminate. Derivation
@@ -44,11 +72,20 @@ commands (per candidate feature `<id>`):
 
 | Signal | Derivation | Notes |
 | --- | --- | --- |
-| **AC coverage** (readiness proxy) | `spur feature show <id> --json` → count `Scenario:` in body; `spur feature check <id> --json` for validity findings | 0 scenarios ⇒ "specify next", not "work next" (routes toward B4/B5 territory; see handoff-routing.md) |
+| **AC coverage** (readiness proxy) | `spur feature show <id> --json` → count `Scenario:` in the frozen response's `.content` (the JSON carries the full body as `.content`); `spur feature check <id> --json` for validity findings | 0 scenarios ⇒ "specify next", not "work next" (routes toward B4/B5 territory; see handoff-routing.md) |
 | **Churn exposure** (urgency proxy — WSJF cost-of-delay, numerator only) | `git rev-list --count --since="<40 days ago>" HEAD -- <dirs the feature's scope touches>` | 40d window is 0493's measured default; tune on dogfood. Scope = the paths named in the feature's Goal/Scope |
 | **Dogfood proximity** (compound leverage) | `rg -c 'plugins/sp | apps/cli | task-pipeline | sp:' docs/features/<id>_*.md` + child task bodies | Degenerate-high in this harness (everything touches itself); discriminates mainly at **zero** — a 0-hit feature is "specify, don't ship" |
 | **Authority pull** (declared intent) | `rg -n '\b<id>\b' docs/02_ROADMAP.md docs/00_ADR.md` | Presence is positive evidence; absence is not negative |
 
+**Freeze each candidate input once.** Per candidate `<id>`, capture at most one
+`spur feature show <id> --json` and at most one `spur feature check <id> --json`; reuse those
+captures wherever the four-signal pass needs feature metadata, body, or AC validity. Count
+`Scenario:` in the frozen show response's `.content` — the body is carried as `.content`, so no
+`.filePath` re-read is required (read the file only when the response does not carry the corpus text
+needed). No signal re-invokes a frozen capture. Churn, dogfood, and authority pull continue using
+their own prescribed `git`/`rg` derivations above — they do not derive from the feature show/check
+captures.
+
 **Degenerate-spread rule.** After deriving a signal across the candidate set, check its spread. One
 dominant value (as `priority` was at 76% P2) ⇒ the signal does not discriminate on this frontier:
 report it as **rejected with its measured spread** for this run, and proceed without it. A rejected

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

@@ -101,6 +101,9 @@ the whole point of this facade is that the CLI surface has a single, scalable ho
   prose checks here.
 - **Not a competency.** Design, implementation, testing, and review are competency skills, not CLI
   verbs — they are not documented here.
+- **Not the orchestration owner.** The ADR-054 boundary: this facade owns CLI noun/verb/flag
+  semantics — including task and feature status-transition verbs — while multi-step lifecycle
+  orchestration belongs to `sp:spur-dev`.
 
 ## See also
 

package/plugins/sp/skills/spur-cli/references/features/hierarchy-mece.md

@@ -117,15 +117,15 @@ If any check fails → **child of best parent** or **task under existing feature
 | --- | --- | --- |
 | Board module + UX slice as child | `F8` Features board → `F81` detail action group | **Good** — same product surface, finer grain |
 | Restructure tooling under Feature CLI | `F3` Feature management CLI → `F31` restructure kit | **Good** — not a new root letter (was root `S`, moved) |
-| Runner vs plugin integration | `B` Agent execution (`spur agent`) vs `H` Agent integration (`plugins/sp`) | **Keep separate** — Goals at `B_agent-execution.md:14` vs `H_agent-integration.md:14`; **reject merge on “agent” alone** |
+| Runtime vs plugin harness | `B` Agent execution (`spur agent`) vs `I` sp plugin (`plugins/sp`) | **Keep separate** — B owns runner/process/session/executor behavior; I owns skills, commands, subagents, hooks, and orchestration guidance. H is frozen history. |
 | Observability UX as sibling roots | `J` board + `K` System Events table redesign + `L` payload enrichment | **Reparent K,L under J** — not body-merge; not peer roots (audit 0356) |
-| Plugin epics as new letters | `N` dev-next UX, `O` token architecture as roots beside `H` | **Reparent under H** — same plugin plane, finer grain |
+| Plugin epics as new letters | Historical `N` dev-next UX and `O` token architecture | **Historical move under H is retained; new plugin work goes under I** — do not extend frozen H |
 | Workflow observability as board root | `P` workflow run observability as peer of `D` Workflows | **Reparent under D** — object is `spur workflow run`, not board J |
 | Planning validation as root | `Q` AC-verifiable gates as peer of `F` Planning | **Reparent under F** |
 | Status feedback as root | `R` feature status loop as peer of `F` | **Reparent under F** (corpus status is planning) |
 | CLI backbone vs board product | `G` Collaboration (message/team CLI) vs `M` Teams board | **Keep both** — different surfaces; do not merge |
 | One-off polish as root | New letter for “fix button loading” | **Bad** — task under existing feature |
-| Done historical epic as root | `I` sp plugin hands-off ready (`done`) | **Keep** as historical root OK; optional later neatness under H |
+| Done plugin epic as root | `I1` sp plugin hands-off ready (`done`) | **Good after reparent** — completed delivery under durable plugin root I |
 
 ### Audit 0356 snapshot (A–R dispositions)
 
@@ -144,6 +144,11 @@ Authoritative seed for restructure mapping lives in task 0356 Solution and
 
 **Rejected merges:** B∪H (name-only overlap); J∪K body-merge (use reparent for K/L).
 
+**Ownership amendment (2026-08-11):** audit 0356 is a historical snapshot. The current active
+boundary is B = runtime agent execution, I = `sp` plugin harness, H = frozen mixed history. The
+applied map is `docs/plans/2026-08-11-sp-plugin-feature-tree-restructure-map.md`; do not place new
+work under H.
+
 ---
 
 ## Checklist: before `spur feature create`

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

@@ -18,6 +18,21 @@ pipeline run) lives in **`sp:spur-dev`** — do not reimplement that loop here.
 *drive* a task through its lifecycle, reach for `sp:spur-dev`; when you need to know *which verb
 does what*, this skill.
 
+## WBS lookup fast path
+
+Start from the WBS, not the corpus layout:
+
+```bash
+spur task show <wbs> --json  # metadata + full content + filePath
+spur task path <wbs> --json  # absolute path only
+```
+
+Do not search `docs/tasks*` or guess `--folder` to locate a known WBS. `show` is the default when an
+agent needs to read a task; use `path` only when another filesystem command needs the absolute path.
+Both commands resolve across configured task folders. Add `--folder` only when deliberately limiting
+the lookup to one non-default corpus. Capture `show` once per run and reuse its response instead of
+re-reading or re-tokenizing the task.
+
 ## Verb map
 
 | Verb | Purpose | Key flags |
@@ -219,6 +234,13 @@ spur task check --strict --json     # elevate ALL warnings to failures
 spur task check 0040 --strict-core  # the testing→done gate variant
 ```
 
+**Folder resolution (task 0522):** a WBS-targeted check (`<wbs>` present, no `--folder`) resolves
+the task across **all configured task folders** — the same resolution as `task show` / `task path` /
+`task update` — so a task in an inactive configured folder is checked, not reported missing. An
+explicit `--folder <path>` is normalized to an absolute path and restricts lookup to that single
+directory (relative and absolute spellings are equivalent). Unscoped checks (no WBS) and
+`task list` remain active-folder-only.
+
 `--json` emits the structured matrix — per-task findings (missing sections, broken feature edges,
 AC-coverage orphans via L4 traceability) keyed by WBS, plus a per-task `pass` verdict. **Query this,
 do not re-derive it**: parse the JSON to answer "which tasks are ready?", "what's blocking 0040?",

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

@@ -45,6 +45,10 @@ the lifecycle*; the competency skills know *how to do each job*; the CLI knows *
 The skill was decomposed **by function** (ADR-028): design, decomposition, implementation, testing,
 and verification each became a standalone competency skill, leaving this spine to orchestrate them.
 
+**Ownership (ADR-054).** This spine owns multi-step lifecycle orchestration — intake, gates,
+decomposition, pipeline runs, HITL pauses. CLI noun/verb/flag semantics, including
+status-transition verbs, are the facade's (`sp:spur-cli`), never this skill's.
+
 **The competencies the spine dispatches:**
 
 | Unit of work | Competency skill |
@@ -154,13 +158,17 @@ CLI does.
    you ship corrupted corpus.
 2. **The pipeline, not you, writes results.** `## Testing` and `## Review` sections are
    filled by the pipeline's `record` step. Do not edit them directly during execution.
-3. **Check before every write.** Run `spur task check <wbs> --json` to know what sections
+3. **Resolve task IDs through the CLI.** Read a known WBS with `spur task show <wbs> --json`; it
+   returns metadata, full content, and `filePath` across configured task folders. Use `spur task
+   path <wbs> --json` only when another tool needs the absolute path. Never search `docs/tasks*` or
+   guess `--folder`; reuse the first `show` response throughout the run.
+4. **Check before every write.** Run `spur task check <wbs> --json` to know what sections
    the task needs at its current status. Guessing produces matrix violations.
-4. **AC titles are identity keys.** Renaming a scenario after tasks are created breaks
+5. **AC titles are identity keys.** Renaming a scenario after tasks are created breaks
    traceability edges. If you must rename, update the task's scenario references too.
-5. **Batch-create is atomic.** A single schema violation rejects the entire batch. Validate
+6. **Batch-create is atomic.** A single schema violation rejects the entire batch. Validate
    locally against `task-batch.schema.json` before invoking the CLI.
-6. **Two-halves seam.** The planning and execution halves share this skill today but are
+7. **Two-halves seam.** The planning and execution halves share this skill today but are
    designed to split cleanly. Keep new logic in one half or the other — never straddle the
    seam with cross-half dependencies.
 

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

@@ -288,7 +288,7 @@ must not be changed without updating the backing skill.
 ### 13. runall
 
 - **Purpose:** Run a batch of tasks through their pipelines in dependency-correct order — resolve a set, topo-sort, run each via `task-pipeline.yaml`, inspect verdicts, apply the failure policy, emit a batch report.
-- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default halts on first failure). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2). Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` after the batch completes, `--next` chains each task to terminal status then runs the wrap hop **once for the batch**, `--continue` resumes from checkpoint.
+- **Inputs:** `--tasks <selector>` (required — explicit WBS list, status pseudo-list, `feature:<id>`, or `ready`). `--mode <sequential|parallel>` (default `sequential`; `parallel` fans out a proven-independent subset per `execution-batch.md` § Parallel Execution). `--keep-going` skips a failed task's in-batch dependents and continues independents (default halts on first failure). `--auto` sets `profile=auto` on each per-task run (skips the HITL approve gate). `--feature <id>` is sugar for `--tasks feature:<id>`; when the effective selector is feature-derived, the batch runs `spur feature check <id> --strict --json` **once** before task resolution — a non-zero strict check aborts with verdict `aborted`, zero attempted tasks, and the structured findings (task 0510 R2); scoped: `L4.scenario-unverified` (expected pre-run state of any not-yet-run feature) is reported verbatim but does not abort — any other strict error aborts. Explicit WBS/status/`ready` selectors add no feature check. The orchestrator loop itself continues in this session; interactive sequential omit/`inline` uses the host driver — host-controlled with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508) — while `--agent auto`/a name, parallel mode, and headless invocation keep the isolated per-task workflow subprocess boundary. `--agent <inline|auto|name>` pins the executor for the per-task stages (see [SSOT](cross-cutting.md#inline-default-execution-surface)); the value crosses into per-task `vars.agent`, not the orchestrator. `--json` emits the report as JSON. `--wrap` triggers `wrapup-pipeline.yaml` after the batch completes, `--next` chains each task to terminal status then runs the wrap hop **once for the batch**, `--continue` resumes from checkpoint.
 - **Three orthogonal axes (do not confuse):** `--keep-going` = batch failure policy (halt vs skip dependents); `--continue` = resume from checkpoint (pick up an interrupted batch); `--next` = per-task lifecycle chaining (advance status on a verdict — `dev-verify`/`dev-verifyall` only). `routing-table.md` offers `--continue` and `--next` as competing options for the same situation only when the batch was interrupted mid-run; otherwise they address different problems.
 - **Backing:** `sp:spur-dev` skill, `runall` operation → delegates the driver loop to the **`sp:super-planner`** agent (the batch orchestrator).
 - **Behavior:** The orchestrator reads [execution-batch.md](execution-batch.md) and drives: resolve selector → freeze set → topo-sort by `dependencies[]` (Kahn, WBS-ascending tie-break; cycle aborts) → resolve out-of-set deps by status (done → allow, else → block subtree) → run each task via `spur workflow run task-pipeline.yaml --async` + `spur workflow trace` polling → inspect terminal state + `.spur/run/<wbs>-verdict.json` → stop-the-batch default or `--keep-going` subtree skip → emit batch report. Per-task pipeline is invoked **verbatim** — no new FSM, no step edits. `--auto`/`--agent` are the only flags that cross the orchestrator→pipeline boundary (both into per-task `--vars`).

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

@@ -76,7 +76,13 @@ bun run apps/cli/src/index.ts feature check <id> --strict --json
 
 - **Abort shape.** A non-zero check aborts the batch immediately: verdict `aborted`, zero attempted
   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).
+  the same abort vocabulary as cycle / unknown selector (Step 4/Step 5). **Scoped to structural
+  findings:** `L4.scenario-unverified` is the expected state of any not-yet-run feature (its
+  covering tasks have no PASS verdicts yet) and `--strict` elevates it to error, so it is reported
+  verbatim but does **not** abort the batch; every other error finding (L1–L3 structural,
+  `L4.malformed-verdict-artifact`, `L4.uncovered-feature-scenario`) still aborts. The terminal
+  feature-transition gate enforces scenario verification after the batch runs, so pre-run unverified
+  scenarios are transient, not defects (dogfood 2026-08-11, feature I2).
 - **Exactly once.** The check runs once per batch, before `task list`; it is not re-run per task.
 - **Non-feature exclusion.** Explicit WBS lists, status pseudo-lists, and `ready` selectors add no
   feature check — only an effective `feature:<id>` selector is feature-derived. When explicit
@@ -84,7 +90,10 @@ bun run apps/cli/src/index.ts feature check <id> --strict --json
 - **Why.** `FeatureCheckService` emits `L3.scope-delineation` (Scope lacking an In/Out split) as a
   **warning**; feature-scoped batches never ran a strict check before freezing, so the late feature
   transition became the first blocking check. A selector-local strict preflight catches a known
-  strict finding before any task pipeline action without changing corpus-wide severity.
+  strict finding before any task pipeline action without changing corpus-wide severity. A not-yet-run
+  feature always fails `L4.scenario-unverified` under `--strict`, so that class is
+  reported-not-aborting per the Abort shape above — the preflight targets defects, not the
+  expected pre-run state.
 - **Scope.** This preflight is advisory to severity policy: it does not alter `FeatureCheckService`,
   `L3.scope-delineation` severity, `feature sync`, or batch-create.
 
@@ -672,7 +681,7 @@ Resume, merge, or discard:
   discard: git worktree remove <worktree-path> && git branch -D <branch>
 ```
 
-The report reuses the [`--next` chain contract](flag-glossary.md#-next-chain-contract) halt-report
+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
 partial result presented as a whole. The answer to "what happens if it fails" is "nothing happens,

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

@@ -203,10 +203,11 @@ behavior:
 
 - `dev-brainstorm` `[<feature-id>]` — **creates** one task from the chosen approach, landing at
   `todo` ready for refine. Optional feature id scopes it.
-- `dev-find-next` `[<feature-id>]` — after an **explicit operator confirm**, dispatches the planning
-  half on the ranked winner (`/sp:dev-plan` to decompose, then `/sp:dev-refineall --depth ready` to
-  freeze implement-ready). Creates no task itself; the confirm pauses regardless of `--auto`.
-  Optional feature id names the target instead of offering rank 1.
+- `dev-find-next` `[<feature-id>]` — after confirm, dispatches the planning half on the ranked
+  winner (`/sp:dev-plan` to decompose, then `/sp:dev-refineall --depth ready` to freeze
+  implement-ready). Creates no task itself. Interactive by default; with `--auto`, auto-accepts the
+  offered target (rank-1 or the explicit id) and forwards `--auto` to the children. Optional feature
+  id names the target instead of offering rank 1.
 - `dev-debug` `[<wbs>]` — **attaches** findings to an existing task. Optional WBS names it.
 - `dev-dogfood` (no value) — **records** run outcomes against the task under test.
 
@@ -366,7 +367,7 @@ swallowed as the name. `--worktree=<name>` is the unambiguous spelling. `/sp:dev
 the flag (single step; not worth the worktree cost), and `--worktree --mode parallel` is rejected
 (per-task parallel isolation stays task 0142). The full lifecycle — name resolution, dirty-tree
 precheck, creation or adoption, crash-safe marker, merge-or-retain, and `--continue` re-entry — is
-specified in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree).
+specified in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name).
 Portable `git worktree` commands only; the git mechanics are reused from
 [worktree-patterns.md](../../branch-workflow/references/worktree-patterns.md).
 

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

@@ -217,6 +217,59 @@ fires, author the doc and **report** the chosen slug and a one-line rationale ("
 `docs/design/<slug>.md` — new `spur <noun>` command + config key"); when it does not fire, report the
 skip and why. Do not pause to ask; the operator reviews the satellite afterward.
 
+## Step 5.6: Idea pipeline (sp:dev-idea) — planning handoff contracts
+
+`/sp:dev-idea` runs the same planning half through the idea-pipeline workflow definition
+(`.spur/workflows/idea-pipeline.yaml` — symlinked to the tracked SSOT). Two
+artifacts are the contract between the workflow states and the operator:
+
+**Goal/Scope intent (feature-create).** The agent writes body-only intent files
+`.spur/run/<runId>-idea-goal.md` and `.spur/run/<runId>-idea-scope.md`, then persists both through
+the corpus CLI (a missing/empty artifact stops the state before decomposition can begin):
+
+```bash
+spur feature update <id> --section Goal  --from-file .spur/run/<runId>-idea-goal.md
+spur feature update <id> --section Scope --from-file .spur/run/<runId>-idea-scope.md
+```
+
+- **Goal is intent only** — a short statement of what the feature achieves. Task breakdowns,
+  checklists, and how-to steps **never** enter Goal.
+- **Scope carries explicit boundaries** — in-scope and out-of-scope bullets.
+
+**Design review artifact (system-design / design-approval).** One run-scoped file,
+`.spur/run/<runId>-idea-design-review.md`, with fixed headings `## Proposed design`,
+`## Operator feedback`, and `## Reconciliation`:
+
+- **First pass:** system-design writes the proposed design under `## Proposed design`.
+- **Rejection:** before answering `no` at the design-approval gate, the operator edits
+  `## Operator feedback` with the concrete issue(s).
+- **Retry:** system-design reads that feedback, revises the design/ADR artifacts, records the
+  changes under `## Reconciliation`, and — when the feedback invalidates an Acceptance Criteria
+  scenario — updates the feature AC through `spur feature update <id> --section
+  "Acceptance Criteria" --from-file <file>` (never direct feature-file edits).
+- **Exit gate:** every design exit into decomposition (auto-approved and interactive-approved)
+  re-runs `spur feature check <id>`, so stale or invalidated AC cannot proceed.
+
+**Task ordering (decompose / handoff-finalize).** Decomposition also emits the private
+run-scoped order sidecar `.spur/run/<runId>-idea-task-order.json` — a JSON array of
+`{ name, depends_on_names[] }` (one entry per batch item, names matching batch item `name`s
+exactly; `[]` when no ordering exists). It is private workflow data, not part of
+`task-batch.schema.json`. A post-decompose validation fails the run on any ambiguous or
+missing title match. After batch creation, `handoff-finalize`:
+
+1. Zips batch item names to the created WBS values from the captured
+   `.spur/run/<runId>-idea-batch-create-result.json` (`task batch-create --json` output;
+   `wbs[]` is in input order).
+2. Applies every non-empty `depends_on_names` list through
+   `spur task deps <wbs> set <dep-wbs...> --json` — a mapping or CLI error fails the run
+   before handoff.
+3. Refreshes the feature roster with `spur feature refresh --feature <id> --json`.
+4. Checks each created task (`spur task check <wbs> --json`) and writes
+   `.spur/run/<runId>-idea-handoff.md` with exactly **one** next command:
+   `/sp:dev-refineall --feature <id> --auto --depth ready` when any task is unready
+   (runall is then omitted), otherwise `/sp:dev-runall --feature <id> --auto`. The terminal
+   handoff note points at this report.
+
 ## Step 6: Refine before execute (the spec-completion gate)
 
 `batch-create` accepts optional `design` / `plan` / `acceptance_criteria` fields (plus