@gobing-ai/spur 0.3.42 → 0.3.44

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

@@ -52,8 +52,10 @@ one thing and yields, so the **pipeline (not the agent) owns the loop**.
 
 Interactive omit/`inline` executes these model stages through the
 [inline pipeline driver](inline-pipeline-driver.md) in the host session and records stage/session
-provenance. `--agent <name|auto>`, parallel batches, and headless workflow invocation select the
-existing subprocess actions. Direct invocations of the same dev operations remain inline by
+provenance. The host is the controller; eligible `agent.run` stages may dispatch once to a native
+subagent (task 0508), with host fallback and no post-dispatch replay — see the driver reference.
+`--agent <name|auto>`, parallel batches, and headless workflow invocation select
+the existing subprocess actions. Direct invocations of the same dev operations remain inline by
 default. See the [inline-default execution-surface contract](cross-cutting.md#inline-default-execution-surface).
 
 > **Single-run & parse discipline (suite run cost control).** Run full quality/test suites (`bun run check` / `spur-check`) at most ONCE per task iteration (task 0436 R2). Parse failure details from the single retained command output rather than re-running full suites repeatedly to inspect errors. Re-run targeted/narrow test files (e.g. `bun test <file> --test-name-pattern <pattern>`) while iterating on fixes, and re-run the full suite only when all targeted fixes pass.

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

@@ -47,7 +47,7 @@ The value table below is the C3a cross-file parity surface (kept in lockstep wit
 
 | 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                                                                  |
 | `<name>`                        | That coding agent or configured executor                                    | Inline when it is the current session's agent; subprocess otherwise         |
 
@@ -366,7 +366,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/inline-pipeline-driver.md

@@ -53,21 +53,53 @@ Action semantics come from the YAML and the workflow action contract:
   actions/guards.
 - `hitl.confirm` — under `profile=auto`, follow the YAML's auto-skip transition. Otherwise pause,
   surface the prompt, and resume from the same state with the operator's answer.
-- `agent.run` — execute the action's slash command through its backing skill in the current host
-  session. Do not call `spur agent run` and do not re-enter `/sp:dev-run --mode full`. Preserve the
-  YAML options: capture `answerFile`; assert `expectFile`; enforce `requireDiff` against a
-  pre-action git snapshot, including the task-scope guard; honor declared error policy. `timeoutMs`
-  is recorded as not applicable because the host session has no independent kill boundary.
-
-After every successful inline `agent.run` action append exactly:
+- `agent.run` — execute the action's slash command, native-subagent-first (task 0508). Do not call
+  `spur agent run` and do not re-enter `/sp:dev-run --mode full`. Preserve the YAML options: capture
+  `answerFile`; assert `expectFile`; enforce `requireDiff` against a pre-action git snapshot,
+  including the task-scope guard; honor declared error policy. `timeoutMs` is recorded as not
+  applicable because the host session has no independent kill boundary.
+
+**Native-subagent dispatch (R2 eligibility, evaluated before each action):**
+
+1. The invocation is one of the two interactive inline full-pipeline surfaces (`dev-run --mode full`
+   or sequential `dev-runall`, omit/`inline`).
+2. The YAML action kind is `agent.run` and its input is a pure slash command. Shell, note, file,
+   guard, and operator-interaction actions remain host-executed.
+3. The current state/action has no operator-confirmation action, `pause: true`, approve/taste/ask
+   decision, or other operator prompt.
+4. The platform exposes a native subagent that shares the working tree and has read, write, shell,
+   and Spur task/run-artifact access.
+
+All four pass → dispatch. Any pre-dispatch failure → execute the stage **once** in the host session.
+No token estimate, stage-size threshold, model heuristic, or configuration switch is added.
+
+**Dispatch and join:** before dispatch, capture the same pre-action git snapshot used by
+`requireDiff` enforcement. Send only: the stage id, the YAML's exact pure slash command, and
+`execution surface already resolved: native subagent; do not dispatch this stage again`. The WBS/path
+already carried by the slash command is the handoff — do not paste task/session transcripts or embed
+machine-specific session paths. Dispatch exactly one native subagent and wait for it; the inline FSM
+must not advance actions or guards concurrently (one writer at a time). After join, validate
+`answerFile`, `expectFile`, `requireDiff`, task scope, and the action's error policy from the shared
+filesystem — a subagent success message is not evidence. On success append exactly:
 
 ```text
-stage <id> executed inline in session <session-id>
+stage <id> executed via subagent <agent-id> (host session <session-id>)
 ```
 
-to `.spur/run/<run-id>.log`, where `<id>` is the current YAML state id. Also log start/failure and
-the ignored timeout value so an inline run remains auditable without fabricating an
-`AgentRunTracedResult`.
+Host fallback retains exactly `stage <id> executed inline in session <session-id>`. If launch fails
+before the subagent starts, log the reason and use host fallback. If a started subagent fails or
+leaves invalid artifacts, do **not** replay the stage in the host — follow the YAML error policy so
+partial mutations are not duplicated.
+
+**Host-owned interaction:** the host alone executes operator-confirmation actions, owns
+`pause: true`, and surfaces approve/taste/ask decisions. A subagent that discovers missing authority
+or an operator decision returns a blocker; the host pauses at the current state and presents it. The
+subagent cannot approve, infer consent, or recursively invoke the full pipeline.
+
+After every successful inline `agent.run` action append exactly one provenance line (inline or
+subagent form above) to `.spur/run/<run-id>.log`, where `<id>` is the current YAML state id. Also
+log start/failure and the ignored timeout value so an inline run remains auditable without
+fabricating an `AgentRunTracedResult`.
 
 Transition guards are not advisory. Execute the declared guard exactly, in order, with the same
 resolved variables and artifacts. `--no-lifecycle` remains bookkeeping only; the YAML's task checks,

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