@gobing-ai/spur 0.3.42 → 0.3.44

package/plugins/sp/commands/dev-wrapall.md

@@ -1,6 +1,6 @@
 ---
 description: Wrap up a batch of completed tasks — learnings, metrics, doc-sync, feature transition, optional branch cleanup
-argument-hint: "[--since <iso-date>] [--feature <id>] [--status <s>] [--auto] [--merge] [--dry-run]"
+argument-hint: "[--since <iso-date>] [--feature <id>] [--status <s>] [--agent <inline|auto|name>] [--auto] [--merge] [--dry-run]"
 allowed-tools: ["Bash", "Read", "AskUserQuestion"]
 ---
 
@@ -15,6 +15,7 @@ Wraps the **wrapup-pipeline.yaml** workflow.
 | `--since` `<iso-date>` | Wrap tasks completed since a date. | configured |
 | `--feature` `<id>` | Wrap tasks in a feature. | omitted |
 | `--status` `<s>` | Only wrap tasks in a status. | done |
+| `--agent` `<inline\|auto\|name>` | Who runs the wrap's model-bearing steps. Wrap is workflow-backed: omit/`inline` resolves to `agent.default` (objective trigger 3 — durable auditable run record required); `auto` tier-resolves an executor; a name pins that executor into `vars.agent`. | agent.default |
 | `--auto` | Skip objective HITL gates. | off |
 | `--merge` | Merge wrap branches. | off |
 | `--dry-run` | Render wraps without writing. | off |
@@ -23,11 +24,28 @@ For shared semantics, see the [flag glossary](../skills/spur-dev/references/flag
 
 ## Usage
 
-/sp:dev-wrapall [--since <iso-date>] [--feature <id>] [--status <s>] [--auto] [--merge] [--dry-run]
+/sp:dev-wrapall [--since <iso-date>] [--feature <id>] [--status <s>] [--agent <inline|auto|name>] [--auto] [--merge] [--dry-run]
 
 ## Implementation
 
+- Apply the [inline-default execution-surface contract](../skills/spur-dev/references/cross-cutting.md#inline-default-execution-surface).
+- Wrap stays **workflow-backed** — `spur workflow run .spur/workflows/wrapup-pipeline.yaml` is the only implementation; there is no inline wrap driver.
+- Resolve the executor **before** launching the workflow:
+  - `--agent <name>` → pass the name unchanged into `vars.agent`.
+  - `--agent auto` → tier-resolve a concrete executor first, then merge it into `vars.agent`.
+  - omit/`--agent inline` → resolve to `agent.default` (the documented headless resolution of `inline`).
+- Emit a pre-dispatch notice naming the override before `spur workflow run`, exactly:
+  `execution surface: subprocess`, `reason: trigger 3 — durable auditable run record required`, `requested agent: inline|auto|<name>`, `executor: agent.default|<resolved-name>`.
+- The wrap workflow still creates its durable run record — the notice reports the override, it does not change the workflow.
+
 ```bash
-spur workflow run .spur/workflows/wrapup-pipeline.yaml --vars '{"tasks":"<json-encoded-wbs-list>","feature":"<id|>","profile":"interactive|auto","merge":"true|false"}' [--dry-run]
+AGENT=… # resolved above: agent.default for inline/omitted, tier-resolved for auto, unchanged for <name>
+echo "execution surface: subprocess; reason: trigger 3 — durable auditable run record required; requested agent: <inline|auto|name>; executor: $AGENT"
+VARS=$(jq -nc --arg tasks "$TASKS" --arg feature "$FEATURE" --arg agent "$AGENT" --arg profile "$PROFILE" --arg merge "$MERGE" \
+  '{tasks:$tasks, feature:$feature, agent:$agent, profile:$profile, merge:$merge}')
+spur workflow run .spur/workflows/wrapup-pipeline.yaml --vars "$VARS" [--dry-run]
 ```
 
+The executor resolution is described in the bullets above; the snippet's `AGENT` variable carries
+the resolved name (`agent.default` for omit/`inline`).
+

package/plugins/sp/plugin.json

@@ -1,6 +1,6 @@
 {
     "name": "sp",
-    "version": "0.3.42",
+    "version": "0.3.44",
     "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/code-implementation/SKILL.md

@@ -92,6 +92,33 @@ only burns wall clock and context budget.
 - If a targeted probe reveals a failure you cannot fix within implement scope, note it in
   `## Solution` and let the `test` hop's fixall handle it — do not pre-empt the gate.
 
+## Changed-path targeted checks (dependency-aware verification, task 0510 R3)
+
+"Run the narrow test first" needs a second half: *which* narrow tests, when a change to a shared
+surface can break a downstream consumer. The matrix below is dependency-aware — domain → app →
+CLI — so a shared change verifies its consumers without recreating the full project check inside
+implement. **It augments narrow behavior tests; it never authorizes `bun run spur-check`,
+`bun run test`, or another full project check inside implement** — the pipeline's `test` hop owns
+that single full gate.
+
+| Changed surface | Required targeted tests | Required typechecks |
+| --- | --- | --- |
+| `packages/domain/src/**` public type/query | affected domain test; affected app service test; affected CLI command test | `@gobing-ai/spur-domain`, `@gobing-ai/spur-app`, `@gobing-ai/spur` |
+| `packages/app/src/**` public service/type | affected app test; affected CLI command test | `@gobing-ai/spur-app`, `@gobing-ai/spur` |
+| `apps/cli/src/**` | affected `apps/cli/tests/**` file | `@gobing-ai/spur` |
+| shared plugin flag/command/reference | affected plugin structure/contract test; add `flag-contract-parity.test.ts` **only** when the shared flag surface changes | no package typecheck unless TypeScript also changed |
+
+- Apply **only the matching rows** for the surfaces actually changed; a multi-surface change applies
+  the union.
+- Workspace typechecks run as `bun run --filter <workspace> typecheck` for each listed workspace
+  (monorepo; installed/other projects substitute their package-manager surface).
+- The shared plugin row is deliberately conditional: a pure reference/prose change needs only the
+  affected structure test; `flag-contract-parity.test.ts` is added only when the shared flag surface
+  (a flag the plugin layer consumes) actually changes, so an unconditional parity suite does not
+  creep into every plugin edit.
+- Run the applicable rows, then stop: the single full project check belongs to the pipeline's
+  `test` hop (`task-pipeline.yaml` `${vars.qualityGateCmd}`).
+
 ## Behavior
 
 This skill behaves as a **technique**: given a task (read its Background, AC, Design, Plan), it maps

package/plugins/sp/skills/issue-finding/SKILL.md

@@ -169,9 +169,27 @@ count identical commands for loop detection.
 Produce per-session metrics (duration, tools, compactions, test runs, spur calls, guard failures,
 key finding). Aggregate totals across sessions.
 
-When `--use-history` is set, optionally run `spur history import --source <mapped> …` and
-`spur history analyze` for token/cost aggregates. Do **not** treat history ETL as a substitute
-for raw tool-loop evidence.
+When `--use-history` is set, the **selected-file history bridge** supplies ETL aggregates for the
+frozen session set (task 0507 R3):
+
+1. **Freeze Phase 1's selected OMP JSONL files once** — the same inventory the raw analysis reads.
+   Discovery roots: the normal OMP session root (`~/.omp/agent/sessions/`) **and**
+   `.spur/run/<run-id>/agent-sessions/<omp-executor>/*.jsonl` for workflow subprocess sessions.
+   Never import a broad `.spur/run` scan and never run a full/source-root reconciliation here.
+2. **Import each frozen file once, through the source-local CLI**, with single-file `force-file`
+   mode:
+   `bun run apps/cli/src/index.ts history import --source omp --file <absolute-file> --mode force-file --json`.
+   The importer derives the session key from the filename; use the same stem for analysis.
+3. **Analyze scoped to that key**: `history analyze --session <filename-stem> --json`.
+4. Use the artifact for the aggregates ETL can represent — tokens, cost, messages, tool calls,
+   loops, and assistant response duration. **Continue parsing the same raw files** for command text,
+   compactions, test/guard retries, tool execution duration/status/errors, and every other signal
+   the ETL does not carry.
+
+ETL supplies normalized aggregates; it is **not** a substitute for raw tool-loop evidence. If an
+import fails or the DB is empty, continue with raw logs and note that cost data is unavailable.
+Before any ad-hoc verification SQL against `history_*` tables, follow the schema-first rule in
+[references/session-formats.md](references/session-formats.md) — inspect the live schema once.
 
 ### Phase 3: IDENTIFY — Root Cause Ranking
 

package/plugins/sp/skills/issue-finding/references/session-formats.md

@@ -104,6 +104,36 @@ For issue-finding:
 Import does not invent bottleneck categories. If import fails or the DB is empty, continue with
 raw logs and note that cost data is unavailable.
 
+**Schema-first rule (task 0506 R3):** history tables are owned by
+`@gobing-ai/ts-llm-jsonl-importer` and can change between versions — never copy column lists
+into this skill. Before any ad-hoc verification SQL that references importer-owned `history_*`
+tables, run **one** schema-introspection query for every table you need and compose the data
+queries from that result:
+
+```bash
+# one introspection pass, then write data queries against what it reports
+sqlite3 <db> "SELECT name, sql FROM sqlite_schema WHERE type='table' AND name LIKE 'history_%';"
+# (or a single `.schema history_<table>` invocation per referenced table)
+```
+
+If a column you expected is absent, trust the live schema — do not guess. The importer's
+`HISTORY_IMPORT_SCHEMA_SQL` is the authority; this skill holds no duplicate column contract.
+
+**Selected-file bridge (task 0507 R3):** `--use-history` imports the frozen Phase-1 file set one
+file at a time — never a root scan, never a full reconciliation. Ambient discovery covers the
+normal OMP root (`~/.omp/agent/sessions/`) **and** workflow subprocess sessions under
+`.spur/run/<run-id>/agent-sessions/<omp-executor>/*.jsonl` (same `type: "message"` envelope). For
+each file, the session key is the JSONL filename stem (importer `sessionIdFromContext`); import and
+analyze per key:
+
+```bash
+bun run apps/cli/src/index.ts history import --source omp --file <absolute-file> --mode force-file --json
+bun run apps/cli/src/index.ts history analyze --session <filename-stem> --json
+```
+
+ETL owns token/cost/message/tool/loop/assistant-duration aggregates; raw JSONL stays authoritative
+for command text, compactions, test/guard retries, and tool execution duration/status/errors.
+
 ## Edge cases
 
 | Scenario | Handling |

package/plugins/sp/skills/next-router/references/routing-table.md

@@ -65,7 +65,7 @@ Statuses from `TASK_STATUSES`: backlog | todo | wip | testing | blocked | done |
 | A5 | `status == wip` (no usable checkpoint) | `task.show.status` | `/sp:dev-run <wbs> --mode implement --auto --next` | yes | **yes** → verify | Completes implement step then chain |
 | A6 | `status == testing` | `task.show.status` | `/sp:dev-verify <wbs> --auto --next` | yes | **yes** — verify `--next` → done (FSM + provenance guards) | On PARTIAL/FAIL → stop review-pending (do not force done) |
 | A7 | `status == blocked` | `task.show` + Notes/History for blocker text | `/sp:dev-handover "<blocker summary from Notes or status>"` | no | no | **STOP** after handover doc; human unblocks |
-| A8 | `status == done` | `task.show.status` | `/sp:dev-wrap <wbs>` | no | **no** (wrap's `--merge` is irreversible HITL; never auto) | Operator may re-invoke with `--merge` explicitly later |
+| A8 | `status == done` | `task.show.status` | `/sp:dev-wrap <wbs>` (`--agent <value>` preserved when the originating command supplied it; omission remains omission) | no | **no** (wrap's `--merge` is irreversible HITL; never auto) | Operator may re-invoke with `--merge` explicitly later |
 | A9 | `status == cancelled` | `task.show.status` | *(none)* | no | no | **STOP** — no-op; print "cancelled — nothing to advance" |
 
 **Priority when multiple TABLE A rows could match:** lowest row number wins (A1–A9 are mutually
@@ -83,7 +83,7 @@ When input is a feature id:
 | B3 | Feature has ≥1 frontier task | task list under feature | **Recurse TABLE A** on chosen task | per A | per A | Frontier = open (`backlog`\|`todo`\|`wip`\|`testing`\|`blocked`), unblocked (all `dependencies[]` done), prefer WBS-ascending among `todo` then `backlog` then `wip` then `testing` then `blocked` |
 | B4 | No frontier tasks AND `feature.status == backlog` AND AC placeholder/invalid | `feature check` / AC body | `/sp:dev-plan` continuation is not WBS-shaped — **STOP** with: run `/sp:dev-plan --feature <id>` or fix AC then `spur feature check <id>` | no | no | Planning-half entry needs a description; do not invent idea text |
 | B5 | No frontier tasks AND feature has valid AC but zero tasks | feature + empty task roster | **STOP** with: `/sp:dev-plan --feature <id>` (decompose/batch-create) | no | no | Avoid auto-running plan without operator description confirmation in v1 |
-| B6 | No frontier tasks AND all child tasks `done` AND feature in `active`\|`verifying` | task list all done | `/sp:dev-wrapall --feature <id>` | no | no | Advances feature via wrapall guards; `--merge` never auto |
+| B6 | No frontier tasks AND all child tasks `done` AND feature in `active`\|`verifying` | task list all done | `/sp:dev-wrapall --feature <id>` (`--agent <value>` preserved when the originating command supplied it; omission remains omission) | no | no | Advances feature via wrapall guards; `--merge` never auto |
 | B7 | No frontier tasks AND mixed cancelled/done only | statuses | **STOP** — print summary; suggest feature status update manually | no | no | |
 | B8 | `feature.status == blocked` | feature status | **STOP** — print feature blocked; do not pick tasks | no | no | |
 

package/plugins/sp/skills/parallel-execution/references/dispatch-surface.md

@@ -89,6 +89,15 @@ non-sandboxed shell, or a workspace that owns the storage path). The upstream fi
 pi-coding-agent's storage-path resolution; it is out of scope here and recorded as motivating
 evidence only.
 
+## Composition with the inline pipeline driver (task 0508)
+
+The interactive inline driver (`cross-cutting.md` § Inline-default execution surface) applies this
+reference's default — native subagent first — to sequential `task-pipeline.yaml` `agent.run`
+stages. Eligibility there is the same observable test (pure-slash action, non-interactive state,
+native subagent with shared-worktree capability); the inline driver remains the authority for
+provenance, artifact validation, and no-replay guarantees. This reference stays the authority for
+the native-subagent versus `spur agent run` choice everywhere else.
+
 ## See also
 
 - **`parallel-execution`** SKILL.md - the dispatch disciplines this rule sits beside.

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 |
@@ -68,7 +83,9 @@ See [tasks/verbs.md](tasks/verbs.md) for the variant detail.
   exit code `3` and names the existing WBS — reuse it.
   - **`--dedupe-within <seconds>`** overrides the default window (e.g. `--dedupe-within 60`).
   - **`--allow-duplicate-name`** disables the guard entirely (explicit override).
-  - Tasks created without `--feature` are never guarded (no collision scope).
+  - The guard applies to every create: feature-scoped tasks collide within the same
+  feature; unscoped tasks (no `--feature`) collide with other unscoped tasks of the
+  same title (their own collision scope).
   - With `--json`, a duplicate emits `{ ok: false, error: { code, message, existingWbs,
     existingName, attemptedName } }` for deterministic reuse.
 
@@ -217,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/cross-cutting.md

@@ -41,7 +41,7 @@ in scripts and audit output but does not change the default.
 
 | Value | Who does the work | Derived surface |
 |---|---|---|
-| `inline` (default when omitted) | Whoever is running this session (interactive) or `agent.default` (headless) | Interactive: inline (host session); headless: subprocess of `agent.default` |
+| `inline` (default when omitted) | Whoever is running this session (interactive) or `agent.default` (headless) | Interactive: inline — host-controlled, eligible model stages may use a native subagent (0508); headless: subprocess of `agent.default` |
 | `auto` | Tier-resolved from the stage's `min_tier` + `fallback` | Subprocess — a tier-resolved executor pins a specific agent/model, which the host session cannot supply |
 | `<name>` (coding agent or configured executor) | That executor | Inline when it resolves to the current session's agent; subprocess otherwise |
 
@@ -105,11 +105,18 @@ meaningless.
 **Interactive task pipelines invert control into the host session (ADR-047 amendment).**
 `dev-run --mode full` and sequential `dev-runall` with omit/`inline` interpret the existing
 `task-pipeline.yaml` in the host session; they do not launch `spur workflow run` and never redirect
-silently to `agent.default`. Each inline model stage appends
-`stage <id> executed inline in session <session-id>` to its run log. `dev-plan` remains a workflow
-subprocess, as do `dev-run`/`dev-runall` with `--agent auto` or a name, parallel batches, and every
-headless `spur workflow run` / `spur agent run`. `dev-run --mode implement` continues to run its
-single competency in-session under omit/`inline`.
+silently to `agent.default`. Interactive inline is **host-controlled and non-subprocess**, but no
+longer guarantees host-context execution for every model stage (task 0508): an eligible `agent.run`
+stage — pure-slash input, non-interactive state, native subagent with shared-worktree
+read/write/shell capability — dispatches **once** to that native subagent and joins before the
+driver continues; any pre-dispatch eligibility failure falls back to one host execution, and a
+failure after dispatch follows the stage's error policy with no automatic host replay. Operator
+confirmation actions, `pause: true`, and approve/taste/ask decisions stay host-owned. Each inline
+model stage appends `stage <id> executed inline in session <session-id>` to its run log; a
+subagent-dispatched stage appends `stage <id> executed via subagent <agent-id> (host session
+<session-id>)` instead. `dev-plan` remains a workflow subprocess, as do `dev-run`/`dev-runall` with
+`--agent auto` or a name, parallel batches, and every headless `spur workflow run` / `spur agent
+run`. `dev-run --mode implement` continues to run its single competency in-session under omit/`inline`.
 
 ### Executor precedence chain (R7)
 
@@ -429,6 +436,15 @@ iterating one task).
 2. Loop on that narrow target until green.
 3. **Then** run the single full `spur-check` (or `bun run check`) as the final gate.
 
+**Dependency-aware selection (task 0510 R3).** "Narrow" is not "whatever file I touched" — a change
+to a shared surface must also verify its downstream consumers. Pick the targeted tests and
+typechecks from the **changed-path matrix** in `code-implementation/SKILL.md` (§ Changed-path
+targeted checks): domain changes run affected domain + app/CLI consumer tests and
+domain/app/CLI typechecks; app changes run affected app + CLI tests and app/CLI typechecks; CLI
+changes run affected CLI tests and the CLI typecheck; shared plugin flag/command contract changes
+run their focused structure/parity tests. Run only the applicable rows, then stop — the full
+project check is still the pipeline's single final gate, never a per-iteration re-run.
+
 Do not re-run the full suite per iteration, and do not `spur-check` before you have a green narrow
 target. **Target:** full `spur-check` runs ≤2 per task (one during iteration, one final) instead of
 4 across a chain.

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

@@ -77,8 +77,8 @@ each would be scope creep for one-liner procedures.
 | 12  | brainstorm | `dev-brainstorm`    | `Skill()`         | `sp:brainstorm` (`dev-brainstorm`)                                                 | `<topic> [--depth <basic\|detailed\|comprehensive>] [--options <n>] [--agent <inline\|auto\|name>] [--skip-discovery] [--wayfind] [--task [<feature-id>]] [--feature [<parent-id>]] [--next]`          |
 | 13  | runall     | `dev-runall`        | `Skill()` → agent | `sp:spur-dev` (`runall`) → `sp:super-planner`                                      | `--tasks <selector> [--feature <id>] [--mode <sequential\|parallel>] [--keep-going] [--auto] [--agent <inline\|auto\|name>] [--json] [--wrap] [--next] [--continue] [--worktree [<name>]]`                      |
 | 13a | parallel   | `dev-parallel`      | `Skill()`         | `sp:parallel-execution`                                                            | `--tasks <selector> [--feature <id>] [--mode <fan-out\|review-panel\|investigation>] [--agent <inline\|auto\|name>] [--json]`                                                                          |
-| 14  | wrap       | `dev-wrap`          | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `<wbs> [--auto] [--merge] [--dry-run]`                                                                                                                                                                 |
-| 15  | wrapall    | `dev-wrapall`       | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `[--since <iso>] [--feature <id>] [--status <s>] [--auto] [--merge] [--dry-run]`                                                                                                                       |
+| 14  | wrap       | `dev-wrap`          | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `<wbs> [--agent <inline\|auto\|name>] [--auto] [--merge] [--dry-run]`                                                                                                                                 |
+| 15  | wrapall    | `dev-wrapall`       | `Skill()`         | `spur workflow run` (wrapup-pipeline)                                              | `[--since <iso>] [--feature <id>] [--status <s>] [--agent <inline\|auto\|name>] [--auto] [--merge] [--dry-run]`                                                                                        |
 | 16  | idea       | `dev-idea`          | `Skill()`         | `spur workflow run` (idea-pipeline)                                                | `"<idea>" [--auto] [--skip-design] [--approve-taste]`                                                                                                                                                  |
 
 ## Skill-backed operations
@@ -137,10 +137,10 @@ must not be changed without updating the backing skill.
 ### 4. run
 
 - **Purpose:** Run a task through the execution pipeline (full) or execute a single pipeline step (implement).
-- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` with omit/`--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session; `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope.
+- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` with omit/`--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session — host-controlled and non-subprocess, with eligible `agent.run` stages dispatching once to a native subagent and host fallback (task 0508); `--agent auto`, a name, or headless invocation launches the workflow subprocess. `--agent <inline|auto|name>` selects the execution surface (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips the HITL approve gate / confirmations and propagates down the `--next` chain. `--next` controls chaining only and never changes the mode; a pipeline implement stage must invoke `/sp:dev-run <wbs> --mode implement`. On implement success with `--next`, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`. On a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` section must state that explicitly and the verify verdict will record the scope. `--wrap` hands off to `/sp:dev-wrap <wbs>` after the main step; the `--agent` selector is preserved into that handoff when supplied (omission remains omission), and the wrap hop reports its own trigger-3 subprocess override per the wrap contract.
 - **Backing:** `sp:spur-dev` skill — `run` operation for the full pipeline (the spine drives it); `sp:code-implementation` competency skill for the implement step (the spine dispatches to it).
 - **Modes:**
-  - **`full`** (default): Drive the full pipeline — precheck → implement → test → review → approve(HITL) → verify → record → done. Interactive omit/inline uses [inline-pipeline-driver.md](inline-pipeline-driver.md); explicit/headless executor selection invokes `spur workflow run .spur/workflows/task-pipeline.yaml --vars '{"wbs":"<wbs>"}'` (with `profile: auto` when `--auto`). Both monitor/surface HITL and preserve the YAML gates. `--next` never changes this mode.
+  - **`full`** (default): Drive the full pipeline — precheck → implement → test → review → approve(HITL) → verify → record → done. Interactive omit/inline uses [inline-pipeline-driver.md](inline-pipeline-driver.md) (host-controlled; eligible stages may use a native subagent); explicit/headless executor selection invokes `spur workflow run .spur/workflows/task-pipeline.yaml --vars '{"wbs":"<wbs>"}'` (with `profile: auto` when `--auto`). Both monitor/surface HITL and preserve the YAML gates. `--next` never changes this mode.
   - **`implement`** (explicit `--mode implement` only): Execute only the implement step. Read the task's `## Requirements` / `## Design` / `## Plan`, write the code that satisfies them, author the `## Solution` change-map section (file:line + what/why per changed file) via `spur task update <wbs> --section Solution --from-file`. This is the implement step the pipeline calls — it is NOT the pipeline driver. With `--next`: on success, transition `todo → wip → testing` through the FSM (guards honored — no `--no-lifecycle`) + chain to `/sp:dev-verify <wbs> --auto --next`; on a guard failure, stop as review-pending. **Partial-deliverable rule:** if the task ships only part of its requirements (e.g. an R1/R2 split with the rest in a follow-up task), the `## Solution` and `## Review` sections MUST carry a `⚠️ PARTIAL` marker naming the deferred part and the follow-up WBS — see `plugins/sp/commands/dev-run.md` → "Section ownership".
 - **Delegation:** `Skill(skill="sp:spur-dev", args="run-inline $ARGUMENTS")` for interactive full omit/inline; `Skill(skill="sp:spur-dev", args="run $ARGUMENTS")` for explicit/headless full mode; `Skill(skill="sp:code-implementation", args="$ARGUMENTS")` for implement mode.
 
@@ -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). The orchestrator loop itself continues in this session; each full per-task workflow's `agent.run` stages always dispatch a subprocess. `--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`).
@@ -297,14 +297,14 @@ must not be changed without updating the backing skill.
 ### 14. wrap
 
 - **Purpose:** Wrap up a single completed task — capture learnings, record metrics, sync docs, and optionally advance the feature / clean up the branch.
-- **Inputs:** `<wbs>` (required, positional). `--auto` skips objective confirmations (the branch-cleanup HITL gate still pauses — irreversible). `--merge` triggers branch cleanup (irreversible HITL gate).
+- **Inputs:** `<wbs>` (required, positional). `--agent <inline|auto|name>` names the wrap's model-bearing executor (default: `agent.default`); wrap is workflow-backed, so omit/`inline` resolves to `agent.default` under objective trigger 3 (durable auditable run record required), `auto` tier-resolves an executor, and a name pins that executor into `vars.agent` (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips objective confirmations (the branch-cleanup HITL gate still pauses — irreversible). `--merge` triggers branch cleanup (irreversible HITL gate).
 - **Backing:** `spur workflow run .spur/workflows/wrapup-pipeline.yaml` — direct workflow invocation (no backing skill; the pipeline IS the procedure).
-- **Behavior:** Builds `--vars '{"tasks":"[\"<wbs>\"]","profile":"interactive|auto","merge":"true|false"}'` and invokes the wrapup pipeline. The pipeline runs: task-resolve → doc-sync → learning-capture → metrics-record → (feature-transition) → (branch-cleanup) → done. Task statuses are NOT mutated. Branch cleanup is an irreversible HITL gate that always pauses, even under `--auto`.
+- **Behavior:** Resolves the executor (`agent.default` for omit/`inline`, tier-resolved for `auto`, unchanged for a name), emits a pre-dispatch notice naming the subprocess override — `execution surface: subprocess`, `reason: trigger 3 — durable auditable run record required`, `requested agent: <selector>`, `executor: <resolved>` — then builds `--vars '{"tasks":"[\"<wbs>\"]","agent":"<resolved>","profile":"interactive|auto","merge":"true|false"}'` and invokes the wrapup pipeline. The pipeline runs: task-resolve → doc-sync → learning-capture → metrics-record → (feature-transition) → (branch-cleanup) → done. Task statuses are NOT mutated. Branch cleanup is an irreversible HITL gate that always pauses, even under `--auto`.
 - **Vars string typing:** `tasks` is a JSON-encoded **string**, not a JSON array — `spur workflow run --vars` accepts only string values (`--vars values must be strings`); the pipeline's guards parse the string with `jq length`. `jq -nc` guarantees the shape:
 
   ```bash
-  VARS=$(jq -nc --arg tasks "[\"$WBS\"]" --arg profile "$PROFILE" --arg merge "$MERGE" \
-    '{tasks:$tasks, profile:$profile, merge:$merge}')
+  VARS=$(jq -nc --arg tasks "[\"$WBS\"]" --arg agent "$AGENT" --arg profile "$PROFILE" --arg merge "$MERGE" \
+    '{tasks:$tasks, agent:$agent, profile:$profile, merge:$merge}')
   spur workflow run .spur/workflows/wrapup-pipeline.yaml --vars "$VARS"
   ```
 
@@ -313,14 +313,14 @@ must not be changed without updating the backing skill.
 ### 15. wrapall
 
 - **Purpose:** Wrap up a batch of completed tasks — capture learnings, record metrics, sync docs, advance a feature through legal lifecycle edges, and optionally clean up branches.
-- **Inputs:** `--since <iso-date>` filters done tasks by frontmatter `updated_at >= date` (v1 approximation). `--feature <id>` selects all tasks under a feature AND advances the feature through legal lifecycle edges (`backlog → active → verifying → done`, guards honored). `--status <s>` (default: `done`) filters by task status. `--auto` skips objective confirmations. `--merge` triggers branch cleanup (irreversible HITL gate).
+- **Inputs:** `--since <iso-date>` filters done tasks by frontmatter `updated_at >= date` (v1 approximation). `--feature <id>` selects all tasks under a feature AND advances the feature through legal lifecycle edges (`backlog → active → verifying → done`, guards honored). `--status <s>` (default: `done`) filters by task status. `--agent <inline|auto|name>` names the wrap's model-bearing executor (default: `agent.default`); wrap is workflow-backed, so omit/`inline` resolves to `agent.default` under objective trigger 3 (durable auditable run record required), `auto` tier-resolves an executor, and a name pins that executor into `vars.agent` (see [SSOT](cross-cutting.md#inline-default-execution-surface)). `--auto` skips objective confirmations. `--merge` triggers branch cleanup (irreversible HITL gate).
 - **Backing:** `spur workflow run .spur/workflows/wrapup-pipeline.yaml` — direct workflow invocation.
-- **Behavior:** Resolves the task list via `spur task list --json` (filtered by `--feature`, `--since`, `--status`), builds `--vars '{"tasks":"[...]","feature":"<id>","profile":"interactive|auto","merge":"true|false"}'`, and invokes the wrapup pipeline. The pipeline runs the same states as `wrap` but with the full task list and optional feature transition. Task statuses are NOT mutated. Feature transitions go through `spur feature update` so lifecycle guards apply. Branch cleanup is an irreversible HITL gate.
+- **Behavior:** Resolves the task list via `spur task list --json` (filtered by `--feature`, `--since`, `--status`), resolves the executor (`agent.default` for omit/`inline`, tier-resolved for `auto`, unchanged for a name), emits a pre-dispatch notice naming the subprocess override — `execution surface: subprocess`, `reason: trigger 3 — durable auditable run record required`, `requested agent: <selector>`, `executor: <resolved>` — then builds `--vars '{"tasks":"[...]","feature":"<id>","agent":"<resolved>","profile":"interactive|auto","merge":"true|false"}'` and invokes the wrapup pipeline. The pipeline runs the same states as `wrap` but with the full task list and optional feature transition. Task statuses are NOT mutated. Feature transitions go through `spur feature update` so lifecycle guards apply. Branch cleanup is an irreversible HITL gate.
 - **Vars string typing:** `tasks` is a JSON-encoded **string**, not a JSON array — `--vars` values must be strings (the CLI rejects raw arrays); `jq -nc` passes the array text through as a string value:
 
   ```bash
-  VARS=$(jq -nc --arg tasks "$TASKS" --arg feature "$FEATURE" --arg profile "$PROFILE" --arg merge "$MERGE" \
-    '{tasks:$tasks, feature:$feature, profile:$profile, merge:$merge}')
+  VARS=$(jq -nc --arg tasks "$TASKS" --arg feature "$FEATURE" --arg agent "$AGENT" --arg profile "$PROFILE" --arg merge "$MERGE" \
+    '{tasks:$tasks, feature:$feature, agent:$agent, profile:$profile, merge:$merge}')
   spur workflow run .spur/workflows/wrapup-pipeline.yaml --vars "$VARS"
   ```
 

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

@@ -64,6 +64,39 @@ 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).
 
+**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),
+run a source-local strict feature check **once** before any task-list resolution, freeze,
+dependency resolution, or worktree task execution:
+
+```bash
+# monorepo source; installed projects use their resolved `spur` binary
+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). **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
+  `--tasks` overrides `--feature`, the effective selector is not feature-derived, so no check runs.
+- **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. 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.
+
 `--tasks <value>` (or the effective value after normalization) resolves to a frozen set of task WBS numbers. Resolution happens **once, at
 kickoff** — the driver never re-queries `spur task list` to recompute membership mid-batch (R2.1).
 
@@ -71,7 +104,7 @@ kickoff** — the driver never re-queries `spur task list` to recompute membersh
 |---|---|---|
 | Explicit WBS list | `^[0-9, ]+$` | Split on comma; validate each token is a 4-digit WBS; collect the explicit set. (R1.1) |
 | `feature:<id>` (via `--tasks` or `--feature <id>`) | literal `feature:` prefix or `--feature` flag | `spur task list --feature <id> --json`; collect `wbs` from each row. The `--feature` flag is sugar that becomes `--tasks feature:<id>` at the command layer. (R1.3) |
-| `ready` | literal `ready` | Resolve the union of `spur task list --status todo --json` + `spur task list --status backlog --json`, drop tasks with open children (R1.5, umbrella-parent exclusion below), then keep only tasks whose every `dependencies[]` entry resolves to `status == done` (via `spur task show <dep> --json`). Report each excluded task with its unmet dependency. (R1.4) |
+| `ready` | literal `ready` | Resolve the union of `spur task list --status todo --json` + `spur task list --status backlog --json`, drop tasks with open children (R1.5, umbrella-parent exclusion below), then keep only tasks whose every `dependencies[]` entry resolves to `status == done` (via `spur task show <dep> --json | jq '{wbs, status, dependencies, feature_id}'` — R5 metadata-only). Report each excluded task with its unmet dependency. (R1.4) |
 | Status pseudo-list | `todo` \| `backlog` \| `wip` \| `blocked` \| `testing` | `spur task list --status <value> --json`; collect `wbs` from each row. (R1.2) |
 | *(else)* | no match | Error: "unknown selector `<value>`" — list the valid forms and halt before running anything. |
 
@@ -113,7 +146,7 @@ edge `A → B` means "A depends on B" (B must complete before A runs). Only edge
 ### 2.3 Out-of-set dependency resolution
 
 For each dependency edge to a task **outside** the frozen set, resolve its current status via
-`spur task show <dep-wbs> --json`:
+`spur task show <dep-wbs> --json | jq '{wbs, status, dependencies, feature_id}'` (R5 metadata-only):
 
 - status `done` → edge satisfied, drop it from the graph (R2.5). The dependent is unblocked.
 - status ≠ `done` → mark the dependent **blocked**. Transitively mark its in-set descendants blocked
@@ -211,7 +244,7 @@ step.
 ```bash
 RUN=$(spur workflow run .spur/workflows/task-pipeline.yaml \
   --vars '{"wbs":"<wbs>","profile":"auto","agent":"claude"}' --async --json | jq -r '.runId')
-spur workflow trace "$RUN" --json   # poll until status is terminal (done/failed)
+spur workflow trace "$RUN" --json | jq '{runId, status, terminalState}'   # poll until status is terminal (done/failed)
 ```
 
 ### 3.2 Flag → `--vars` passthrough (R4.2, R4.3)
@@ -262,6 +295,7 @@ in next-router; this only maps status → primary TABLE A hop for recovery.
 
 ### 3.3c Bounded feature-sync retry suppression (task 0411)
 
+
 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
@@ -295,6 +329,42 @@ pipeline's `record` step and the wrap-up's `feature-transition` step. The driver
 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.
 
+### 3.4 Metadata-only host controller (R5, task 0510)
+
+The batch **orchestrator** reads status, ordering, and terminal state — never task bodies or trace
+output. Task `content`, section bodies (Solution/Testing/Review), and full workflow `output` are
+stage/subagent data and must not enter the host context on the green path; the controller that
+dispatches native subagents must not defeat that isolation by ingesting the very bodies the
+subagents are meant to hold (task 0508's dispatch contract is preserved unchanged).
+
+**Green-path projections — every controller-side read is projected to metadata:**
+
+- `task show --json` reads pipe to `{wbs, status, dependencies, feature_id}` only:
+
+  ```bash
+  spur task show <wbs> --json | jq '{wbs, status, dependencies, feature_id}'
+  ```
+
+  Use this shape for out-of-set dependency resolution (Step 2.3), the `ready` selector's
+  dep-status lookups (Step 1), and any other controller-side `task show`. A status-only lookup may
+  narrow further (`| jq '.status'`), but never widen.
+
+- Green-path trace observation projects to `{runId, status, terminalState}` only:
+
+  ```bash
+  spur workflow trace "$RUN" --json | jq '{runId, status, terminalState}'
+  ```
+
+  The controller decides continue/halt from `status`/`terminalState` (ADR-044: judge a run by
+  `status === 'done'`, never by string-matching a `finalState` name) plus the bounded verdict
+  artifact `.spur/run/<wbs>-verdict.json`. It never streams or re-reads a full trace merely to
+  summarize status.
+
+**Failure-path reads are bounded.** On a failed/blocked task, request only the terminal error and
+the minimal anchor set the batch report needs (e.g. the blocking finding line, the unmet-dep WBS,
+the verdict line) — never the entire trace. If a fuller trace is needed for diagnosis, that read
+belongs to a subagent or the operator, not to the batch controller's report loop.
+
 ## Step 4 — Failure policy (R3)
 
 ### 4.1 Stop-the-batch (default) (R3.1)
@@ -611,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,
@@ -683,6 +753,8 @@ command doc so it does not read as a bug.
 | R5.1 (orchestrator boundary) | "Zero engine code" preamble + Step 3 |
 | R5.2 (structured batch report) | Step 5 |
 | 0411 (bounded feature-sync retry suppression) | Step 3.3c — wrapper lives in pipeline `record` + wrap-up `feature-transition`; driver unchanged |
+| 0510 R2 (feature-derived strict preflight) | Step 1 — "Feature-derived strict preflight (R2, task 0510)" |
+| 0510 R5 (metadata-only host controller) | Step 3.4 + projected `task show` / trace snippets in Step 1, 2.3, 3.1 |
 
 ## Parallel Execution