@gobing-ai/spur 0.3.60 → 0.3.62

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

@@ -50,7 +50,7 @@ ordered guards, and may loop back on itself (e.g. implement → check → fix
 | Node typing | none (states are untyped) | `type: action\|gate\|parallel\|decision` |
 | Required keys | `name, initialState, states, transitions` | `kind, name, initialNode, nodes, edges` |
 | `kind` field | optional (defaults to state-machine) | **required** — `kind: transition-flow` |
-| Canonical example | implement→check→fix loop (`.spur/workflows/basic.yaml` — soft status-file probe + bounded fixall) | read→validate→transform→write pipeline |
+| Canonical example | implement→check→fix loop (`basic.yaml` — soft status-file probe + bounded fixall) | read→validate→transform→write pipeline |
 
 **Heuristic:** loops / retries / one-active-state → **state-machine**; pipeline / fan-out / action-per-node → **transition-flow**.
 
@@ -335,7 +335,7 @@ the workflow's actions (`shell`, custom runners) do that; this skill builds and
    (transition-flow) wins. Order the specific case before the fallback. Simple shell checks can use
    `action-ok` before an unconditional retry edge; multi-condition gates prefer a **soft status-file
    probe** (always exit 0) with ordered shell guards for PASS / FAIL / exhausted (see
-   `.spur/workflows/basic.yaml` and `task-pipeline.yaml` quality-gate hop).
+   `basic.yaml` and `task-pipeline.yaml` quality-gate hop).
 4. **`env.allow` is an allowlist.** `${env.X}` resolves only if `X` is listed under `env.allow`;
    otherwise it resolves empty. A workflow that "loses" an environment value usually forgot to allow it.
 5. **Extensions are fail-closed.** The CLI loads YAML-declared extension modules itself
@@ -372,9 +372,9 @@ the workflow's actions (`shell`, custom runners) do that; this skill builds and
   custom action/guard runners, the trust-gated extension loader, and CLI-vs-library capability gaps.
 - `@gobing-ai/ts-dual-workflow-engine` README — authoritative library reference (both drivers,
   RunLifecycle, persistence, the full event map, every built-in capability).
-- `.spur/workflows/basic.yaml` — the canonical state-machine implement→soft-check→fixall loop
+- `basic.yaml` — the canonical state-machine implement→soft-check→fixall loop
   (status-file branching + `qualityGateMaxFixAttempts`); copy real shapes from here.
-- `.spur/workflows/task-pipeline.yaml` — full production pipeline (precheck, quality gate, HITL,
+- `task-pipeline.yaml` — full production pipeline (precheck, quality gate, HITL,
   verify, record) when you need the complete reliability pattern set.
 
 ## Platform Notes

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

@@ -85,7 +85,7 @@ Full procedure: **[references/planning-workflow.md](references/planning-workflow
 ```
 pick task (spur task list --json)
   → interactive omit/inline: read task-pipeline.yaml → drive actions + guards in host session
-  → explicit/headless executor: spur workflow run .spur/workflows/task-pipeline.yaml --vars '{"wbs":"<wbs>"}'
+  → explicit/headless executor: spur workflow run task-pipeline.yaml --vars '{"wbs":"<wbs>"}'
   → on HITL pause: surface to operator; resume the selected driver from the paused state
 ```
 
@@ -218,10 +218,10 @@ for "what's actually in file Y" or for resources that sit outside the step seque
 
 - `plugins/sp/references/roles.md` — the Layer-1 role→tier table (`scribe` / `coder` / `reviewer` /
   `planner`, one per tier); the role vocabulary this spine's operations route under.
-- `.spur/workflows/task-pipeline.yaml` — the execution pipeline definition.
-- `.spur/workflows/idea-pipeline.yaml` — the front-half state machine (absorbed the retired
+- `task-pipeline.yaml` — the execution pipeline definition.
+- `idea-pipeline.yaml` — the front-half state machine (absorbed the retired
   planning-pipeline in D5-K; `/sp:dev-plan` routes here, ADR-072).
-- `.spur/templates/bdd/gherkin.md` — the BDD scenario template.
+- `templates/bdd/gherkin.md` — the BDD scenario template.
 
 ## Platform Notes
 

package/plugins/sp/skills/spur-dev/references/ac-style-guide.md

@@ -148,9 +148,9 @@ contract exists to prevent.
 > Before 0398 R7 this row was unusable: the tag was required to keep `MET`, but the tag also broke
 > title matching, so the scenario read as unverified. Both halves now hold at once.
 
-### What `--strict` advance requires
+### What a done advance requires
 
-`spur feature advance <id> --to done --strict` treats a scenario as verified only when **all** of
+`spur feature advance <id> --to done` treats a scenario as verified only when **all** of
 these hold:
 
 1. A task links to the feature (`feature_id`) and is status `done`.
@@ -169,7 +169,7 @@ Author one row per scenario declared in the task's own `### Acceptance Criteria`
 
 ## Gherkin template
 
-Use the canonical BDD template at `.spur/templates/bdd/gherkin.md`. Key rules:
+Use the canonical BDD template at `templates/bdd/gherkin.md`. Key rules:
 
 - **Given** establishes preconditions (state, setup).
 - **When** describes the single action under test.
@@ -210,7 +210,7 @@ Each resolved decision from a grilling interview (Phase 1) becomes one or more G
 | A **deferred branch** ("out of scope for now") | A `## Scope` **Out** bullet — *not* a scenario |
 
 Number scenarios `R1, R2, …` sequentially, stable forever (the title is the traceability identity
-key). Use the Gherkin template at `.spur/templates/bdd/gherkin.md`.
+key). Use the Gherkin template at `templates/bdd/gherkin.md`.
 
 ## AC altitude (task 0584 / ADR-062)
 

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

@@ -68,7 +68,7 @@ each would be scope creep for one-liner procedures.
 | 2   | review     | `dev-review`        | `Skill()`         | `sp:code-verification` (`review`) + `sp:functional-review` + `sp:code-improvement` | `[<wbs\|path>] [--agent <inline\|auto\|name>] [--focus <dims>] [--fix (deprecated)]`                                                                                                                   |
 | 3   | verify     | `dev-verify`        | `Skill()`         | `sp:code-verification` (`verify`)                                                  | `<wbs> [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--skip-shippable]`                                                     |
 | 3a  | verifyall  | `dev-verifyall`     | `Skill()` → agent | `sp:spur-dev` (`verifyall`)                                                        | `--tasks <selector> [--feature <id>] [--agent <inline\|auto\|name>] [--fix <none\|blockers-first\|all>] [--focus <lens>] [--bdd] [--auto] [--force] [--next] [--json] [--skip-shippable] [--worktree [<name>]]` |
-| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--continue]`                                                                                              |
+| 4   | run        | `dev-run`           | `Skill()`         | `sp:spur-dev` (`run` / `implement`)                                                | `<wbs> [--mode <full\|implement>] [--agent <inline\|auto\|name>] [--auto] [--next] [--wrap] [--continue] [--worktree [<name>]]`                                                                                              |
 | 5   | refine     | `dev-refine`        | `Skill()`         | `sp:spur-dev` (`refine`)                                                           | `<wbs> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--next]`                                                                           |
 | 5a  | refineall  | `dev-refineall`     | `Skill()`         | `sp:spur-dev` (`refineall`)                                                        | `--feature <id> \| --tasks <selector> [--focus <mode>] [--description <text>] [--depth <standard\|ready>] [--agent <inline\|auto\|name>] [--auto] [--keep-going] [--status <s>] [--json] [--worktree [<name>]]` |
 | 6   | plan       | `dev-plan`          | `Skill()`         | `sp:spur-dev` (`plan`)                                                             | `"<description>" [--feature <id>] [--parent <feature-id>] [--agent <inline\|auto\|name>] [--skip-design] [--auto] [--approve-taste]`                                                                   |
@@ -140,10 +140,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 omitted `--agent` or explicit `--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session — host-controlled and non-subprocess; **omitted** `--agent` keeps 0508 eligibility (eligible `agent.run` stages dispatch once to a native subagent, host fallback), while explicit `--agent inline` is the zero-dispatch carve-out (every stage executes in the invoking 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. `--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.
+- **Inputs:** `<wbs>` (required). `--mode <full|implement>` selects the execution mode. `implement` invokes `sp:code-implementation` inline by default. Interactive `full` with omitted `--agent` or explicit `--agent inline` reads `task-pipeline.yaml` and drives its actions/guards in the host session — host-controlled and non-subprocess; **omitted** `--agent` keeps 0508 eligibility (eligible `agent.run` stages dispatch once to a native subagent, host fallback), while explicit `--agent inline` is the zero-dispatch carve-out (every stage executes in the invoking 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. `--worktree [<name>]` runs the full pipeline inside an isolated git worktree (create or reuse; FF-merge on success, retain on failure) — the batch lifecycle in [execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name) applied to a batch of one; rejected with `--mode implement`. `--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) (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.
+  - **`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 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 (explicit `inline` = zero-dispatch carve-out); `Skill(skill="sp:spur-dev", args="run $ARGUMENTS")` for explicit/headless full mode; `Skill(skill="sp:code-implementation", args="$ARGUMENTS")` for implement mode.
 
@@ -301,33 +301,33 @@ must not be changed without updating the backing skill.
 
 - **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). `--agent <inline|auto|name>` names the wrap's model-bearing executor (default: `agent.default`); wrap is workflow-backed, so omitted `--agent` resolves to `agent.default` under objective trigger 3 (durable auditable run record required) while explicit `--agent inline` is rejected with the stable special error (headless workflow surface), `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).
+- **Backing:** `spur workflow run wrapup-pipeline.yaml` — direct workflow invocation (no backing skill; the pipeline IS the procedure).
 - **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 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"
+  spur workflow run wrapup-pipeline.yaml --vars "$VARS"
   ```
 
-- **Delegation:** Direct `spur workflow run .spur/workflows/wrapup-pipeline.yaml` (no `Skill()` call — the command builds the vars JSON and invokes the workflow directly via `Bash`).
+- **Delegation:** Direct `spur workflow run wrapup-pipeline.yaml` (no `Skill()` call — the command builds the vars JSON and invokes the workflow directly via `Bash`).
 
 ### 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. `--agent <inline|auto|name>` names the wrap's model-bearing executor (default: `agent.default`); wrap is workflow-backed, so omitted `--agent` resolves to `agent.default` under objective trigger 3 (durable auditable run record required) while explicit `--agent inline` is rejected with the stable special error (headless workflow surface), `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.
+- **Backing:** `spur workflow run wrapup-pipeline.yaml` — direct workflow invocation.
 - **Behavior:** Resolves the task list via `spur task list --json` (filtered by `--feature`, `--since`, `--status`), resolves the executor (`agent.default` for omitted `--agent`, tier-resolved for `auto`, unchanged for a name; explicit `--agent inline` is rejected with the stable special error), 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 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"
+  spur workflow run wrapup-pipeline.yaml --vars "$VARS"
   ```
 
-- **Delegation:** Direct `spur workflow run .spur/workflows/wrapup-pipeline.yaml` (no `Skill()` call — the command resolves tasks and invokes the workflow directly via `Bash`).
+- **Delegation:** Direct `spur workflow run wrapup-pipeline.yaml` (no `Skill()` call — the command resolves tasks and invokes the workflow directly via `Bash`).
 
 ### 16. idea
 
@@ -337,9 +337,9 @@ must not be changed without updating the backing skill.
   - `--skip-design` — design package off (system-design + task Design).
   - `--approve-taste` — with `--auto`, skip **all** remaining taste pauses this run (idea-eval + design-approval). Sets `idea_approved=true` and `design_approved=true`.
     Aliases (prefer `--approve-taste`): `--idea-approved` → `idea_approved`; `--design-approved` → `design_approved`. There is **no** `--design` force flag.
-- **Backing:** `spur workflow run .spur/workflows/idea-pipeline.yaml` — direct workflow invocation.
+- **Backing:** `spur workflow run idea-pipeline.yaml` — direct workflow invocation.
 - **Behavior:** Builds vars from the table above and invokes the idea pipeline. Flow: discovery → **idea-eval** (taste; reject → cancelled) → feature-create → ac-generate → feature-check → system-design (conditional) → design-approval (taste) → decompose → batch-create → handoff. STOPS at handoff — no task execution, no pipeline nesting.
-- **Delegation:** Direct `spur workflow run .spur/workflows/idea-pipeline.yaml` (command maps flags → vars, then `Bash`).
+- **Delegation:** Direct `spur workflow run idea-pipeline.yaml` (command maps flags → vars, then `Bash`).
 - **Idea-evaluation gate:** After discovery, operator reviews `.spur/run/idea-eval-report.md` ([idea-evaluation.md](idea-evaluation.md)). Approve continues; reject/cancel → no feature. Under `--auto`, still pauses unless taste pre-cleared (`--approve-taste` / alias). Enhanced idea is a sidecar — `vars.idea` is not overwritten.
 - **Design package (`--skip-design` only):**
 

package/plugins/sp/skills/spur-dev/references/done-housekeeping.md

@@ -27,7 +27,7 @@ Invariant: zero `- [ ]` entries (real or placeholder) anywhere in a `done` task
 Drive the real `task-pipeline.yaml` FSM where applicable:
 
 ```
-spur workflow run .spur/workflows/task-pipeline.yaml --vars '{"wbs":"<wbs>"}'
+spur workflow run task-pipeline.yaml --vars '{"wbs":"<wbs>"}'
 ```
 
 If you hand-walk lifecycle statuses (manual `spur task update <wbs> <status>` without the

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

@@ -16,7 +16,7 @@ report shape.
 
 Single-task execution is documented in **[execution-workflow.md](execution-workflow.md)** — this file
 extends that procedure to the batch case. Read that file first for the single-task pipeline contract;
-everything here assumes a task runs through `.spur/workflows/task-pipeline.yaml` unchanged.
+everything here assumes a task runs through `task-pipeline.yaml` unchanged.
 
 **Zero engine code, zero schema changes (ADR-022).** The batch is orchestration over existing seams —
 the status vocabulary (`packages/domain/src/planning/schema.ts`), the `dependencies[]` frontmatter
@@ -232,7 +232,7 @@ invocation in its own subagent/worktree-safe context; synthesize outcomes; recov
 
 ### 3.1 Per-task execution reuses the pipeline verbatim (R4)
 
-Each task runs through the **standard single-task pipeline** — `.spur/workflows/task-pipeline.yaml`
+Each task runs through the **standard single-task pipeline** — `task-pipeline.yaml`
 — with no new FSM and no step edits. Interactive sequential omit/inline invokes the host
 [inline pipeline driver](inline-pipeline-driver.md), which interprets that file; explicit/parallel
 execution invokes the workflow engine. The batch loop inspects the result and never redefines a
@@ -242,7 +242,7 @@ step.
 `agent.run` stages runs for many minutes. Always use `--async` + `spur workflow trace` polling:
 
 ```bash
-RUN=$(spur workflow run .spur/workflows/task-pipeline.yaml \
+RUN=$(spur workflow run task-pipeline.yaml \
   --vars '{"wbs":"<wbs>","profile":"auto","agent":"claude"}' --async --json | jq -r '.runId')
 spur workflow trace "$RUN" --json | jq '{runId, status, terminalState}'   # poll until status is terminal (done/failed)
 ```
@@ -421,6 +421,15 @@ isolated git worktree instead of the operator's working directory. This section
 lifecycle for the sequential batch loop. Per-task worktrees and `--mode parallel` isolation stay out
 of scope (task 0142 Slice A); `--worktree --mode parallel` is rejected.
 
+**Single-task `dev-run` (batch of one).** `/sp:dev-run <wbs> --worktree [<name>]` runs this same
+lifecycle with a one-task loop: WT-1…WT-6 apply unchanged, the marker's `command` is `dev-run` and
+its `selector` is the `<wbs>` (so WT-6's command+selector fallback resolves the resume), and the
+derived branch/directory slug is the WBS — `sp/run-<wbs>-<short-id>`. The WT-4 success condition
+"no failed task" reads as "the task reached terminal `done` with no failed stage"; a failing gate, a
+non-PASS verify verdict, or a HITL pause that ends the run take the WT-5 retention path. Only the
+full pipeline is eligible — `--worktree --mode implement` is rejected (WT-7), because that mode is
+the pipeline's implement stage and already runs in the driver's tree.
+
 One flag, two modes (see the glossary entry for the ownership rule). Bare `--worktree` is **create
 mode** (cut a fresh branch + sibling tree). `--worktree <name>` is **reuse mode** (attach to a tree
 that already exists); name resolution (§ WT-2 below) runs before WT-1. The deltas each mode applies
@@ -714,9 +723,13 @@ fallback, because `<name>` was explicit and unambiguous intent.
 ### WT-7 — Exclusions (R8)
 
 - **`dev-next`** does not get `--worktree` — it dispatches a single step; per-step isolation is not
-  worth the worktree cost.
+  worth the worktree cost. `dev-run` is different: it drives a whole task pipeline, so it does get
+  the flag.
 - **`--mode parallel`** is rejected when combined with `--worktree` — per-task worktrees and
   parallel isolation remain task 0142 Slice A.
+- **`--mode implement`** is rejected when combined with `--worktree` on `dev-run` — that mode *is*
+  the pipeline's implement stage (bug-742) and runs in whatever tree the driver set up; a second
+  worktree would split one task's evidence across two trees.
 - **No** create-with-name (`--worktree <name>` never creates; an unresolvable name is an error),
   no `--worktree-keep` variant, no auto-cleanup of stale worktrees or markers from prior runs.
 

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

@@ -100,6 +100,13 @@ cache-conservation discipline (`plugins/sp/skills/dogfood-testing/references/mon
 > - Without `--auto`: warn the operator before calling `spur workflow run` and prompt for confirmation or a plan-item override via `--vars '{"maxImplementPlanItems":"<count>"}'`.
 > - With `--auto`: automatically append `"maxImplementPlanItems": "<count>"` to `--vars` and log a single-line notice (e.g. `Notice: task <wbs> has N plan items (>8 default cap); injecting maxImplementPlanItems override`).
 
+**`--worktree [<name>]` wraps Step 2, on either surface.** When `/sp:dev-run --mode full` carries
+[`--worktree`](flag-glossary.md#flag-worktree), create or adopt the worktree *before* launching the
+pipeline, `cd` into it (`spur workflow run` and the inline driver both resolve cwd from the process),
+and merge-or-retain after the run reports. The lifecycle is
+[execution-batch.md § Worktree isolation](execution-batch.md#worktree-isolation---worktree-name)
+applied to a batch of one. Rejected with `--mode implement`.
+
 **Choose the surface before execution.** In an interactive `/sp:dev-run --mode full` invocation,
 omit/`--agent inline` selects the [inline pipeline driver](inline-pipeline-driver.md). Read the YAML
 at invocation time, allocate the inline run id/session provenance, record `task run-link`, and walk
@@ -120,7 +127,7 @@ VARS=$(jq -nc --arg wbs "$WBS" --arg profile auto '{wbs:$wbs, profile:$profile}'
 # optional, when --agent <name|auto> is set:
 #   VARS=$(jq -nc --arg wbs "$WBS" --arg profile auto --arg agent "$AGENT" \
 #         '{wbs:$wbs, profile:$profile, agent:$agent}')
-RUN=$(spur workflow run .spur/workflows/task-pipeline.yaml --vars "$VARS" --async --json | jq -r '.runId')
+RUN=$(spur workflow run task-pipeline.yaml --vars "$VARS" --async --json | jq -r '.runId')
 spur workflow trace "$RUN" --follow --output   # streams the run; --output shows the agent log surface
 ```
 

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

@@ -44,10 +44,11 @@ When `/sp:dev-verify <wbs>` produces a `PASS` verdict:
    - Confirm with the operator before executing `spur feature sync <id>` (in `--auto` mode, apply forward-only proposals).
 
 2. **Task missing `feature_id`**:
-   - Check if `feature_link_declined: true` is set on the task frontmatter (`spur task show <wbs> --json`).
+   - Check the task content for the Q&A marker `feature_link_declined: true` (`spur task show <wbs> --json`).
    - If `feature_link_declined: true`: skip linking prompt — explicit operator deferral is preserved.
    - If unlinked and not declined: propose candidate existing features via single-task mode.
-   - If operator explicitly declines: record `feature_link_declined: true` via `spur task update <wbs> --field feature_link_declined --value true`.
+   - If operator explicitly declines: preserve the existing Q&A body, append the marker, and write it through
+     `spur task update <wbs> --section Q&A --from-file <body-file>`.
 
 ## Single-task mode
 

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

@@ -200,16 +200,25 @@ restrictor. On `dev-refineall` it is instead one of a required pair — supply e
 
 Select an execution mode: `full|implement` on `dev-run` (full pipeline vs implement-only),
 `sequential|parallel` on `dev-runall` (serial vs fanned-out-independent-subset),
-`fan-out|review-panel|investigation` on `dev-parallel`, and the reconstruction depth
-`briefing|structure|architecture|design|full` on `dev-reverse`. Mode selection is explicit and orthogonal
+`fan-out|review-panel|investigation` on `dev-parallel`, the reconstruction depth
+`briefing|structure|architecture|design|full` on `dev-reverse`, and `daily|ad-hoc` on
+`dev-find-issue` (the history-anatomy report mode). Mode selection is explicit and orthogonal
 to `--next`.
 
+### `--date <YYYY-MM-DD>` — local calendar day selection
+
+**Anchor:** `#flag-date`.
+
+Select a local calendar day on `dev-find-issue` (daily mode) and `dev-daily` (report date). DST-aware:
+`--date <that-date>` spans the full local calendar day including any daylight-saving shift, never a
+fixed 24-hour offset.
+
 ### `--task <wbs>` — task work or task narrowing
 
 **Anchor:** `#flag-task`.
 
 Connect the current command's result to task work, or narrow a history analysis to one task
-(`dev-brainstorm`, `dev-debug`, `dev-dogfood`, `dev-find-next`, `dev-history-load`). The value and
+(`dev-brainstorm`, `dev-debug`, `dev-dogfood`, `dev-find-next`). The value and
 the effect are per-command — this flag is a family, not one behavior:
 
 - `dev-brainstorm` `[<feature-id>]` — **creates** one task from the chosen approach, landing at
@@ -221,7 +230,6 @@ the effect are per-command — this flag is a family, not one behavior:
   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.
-- `dev-history-load` `<wbs>` — narrows the `analyze` step to that task's messages.
 
 ### `--since <ref>` — lower bound on a range
 
@@ -250,10 +258,10 @@ Upper bound on a range: a git ref on `dev-changelog` (defaults to `HEAD`), or an
 
 **Anchor:** `#flag-source`.
 
-Scope the operation to one agent source (`dev-find-issue`, `dev-history-load`): one of
-`pi|claude|codex|gemini|opencode|antigravity|openclaw|omp|grok|agy` (or `all`). On
-`dev-history-load` the value is forwarded to **both** `spur history import` and
-`spur history analyze`; on `dev-find-issue` it narrows the report scan to that source's sessions.
+_(Removed 2026-08-24, HA-S1 0661.)_ The only two commands that consumed this flag;
+`dev-find-issue` (now a `sp:history-anatomy` forwarder) and `dev-history-load` (deleted) no
+longer declare it, so the entry is dead and removed. The underlying `spur history` surfaces
+retain their own `--source` handling.
 
 ### `--status <s>` — filter by task status
 
@@ -280,7 +288,8 @@ Omit the design package (system-design satellite + task `### Design`) on plannin
 
 **Anchor:** `#flag-output`.
 
-Write the command's result to a file path (`dev-daily`, `dev-reverse`) instead of stdout.
+Write the command's result to a file path (`dev-daily`, `dev-find-issue`, `dev-reverse`) instead of
+stdout. On `dev-find-issue` (ad-hoc mode) an explicit path replaces the default run-directory write.
 
 ### `--merge` — trigger branch cleanup
 
@@ -359,8 +368,9 @@ flag sets both.
 
 **Anchor:** `#flag-worktree`.
 
-Batch commands only (`dev-refineall`, `dev-runall`, `dev-verifyall`): run the entire driver loop
-inside an isolated git worktree instead of the operator's working directory. One flag, two modes:
+Batch commands plus single-task `dev-run` (`dev-refineall`, `dev-runall`, `dev-verifyall`,
+`dev-run`): run the entire driver loop inside an isolated git worktree instead of the operator's
+working directory. One flag, two modes:
 
 - **Create mode** — bare `--worktree` (no value). Cut a fresh branch from the current HEAD's ref,
   create a sibling worktree with a derived name, run the batch there. On a fully successful batch
@@ -385,8 +395,10 @@ merges but never removes. This keeps the continue-the-work loop stable — after
 **Value binding.** The following token is consumed as `<name>` **only when it does not begin with
 `-`**, so `--worktree --auto` is the bare create form and `--agent`/`--feature`/etc. are never
 swallowed as the name. `--worktree=<name>` is the unambiguous spelling. `/sp:dev-next` does not get
-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
+the flag (single *step*; not worth the worktree cost — unlike `dev-run`, which isolates a whole
+task pipeline), `--worktree --mode parallel` is rejected (per-task parallel isolation stays task
+0142), and `--worktree --mode implement` is rejected on `dev-run` (that mode *is* the pipeline's
+implement stage and runs in the driver's tree). 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-name).
 Portable `git worktree` commands only; the git mechanics are reused from

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

@@ -23,7 +23,7 @@ Run each checklist as an actual command sequence, not a mental confirmation:
 
 ## Task lifecycle transitions
 
-SSOT: `.spur/workflows/task-lifecycle.yaml`.
+SSOT: `task-lifecycle.yaml`.
 
     backlog → todo → wip → testing → done
 

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

@@ -14,8 +14,9 @@ interactive `/sp:dev-run --mode full` or sequential `/sp:dev-runall` invocation
 passes `--agent inline`. A named executor, `--agent auto`, parallel batch mode, `spur workflow run`,
 and `spur agent run` keep the existing subprocess path.
 
-The project runtime definition at `.spur/workflows/task-pipeline.yaml` remains the sole FSM definition.
-The driver MUST read that file
+The project runtime definition — `task-pipeline.yaml`, resolved through the two-tier
+project→bundled model (task 0648/0650, never an unbundled runtime path) — remains the sole
+FSM definition. The driver MUST read that file
 at invocation time. It must not copy the state list, actions, guards, or transition order into a
 command, skill, script, or second workflow.
 
@@ -134,12 +135,14 @@ tasks (0617, 0619) because the sections were hand-written **before** the verdict
    **overwrites** a hand-authored `## Testing` with an auto-generated "No requirements recorded" table,
    plus replaces `## Solution` with a bare auto change-map. Creating the artifact first (PASS, with
    requirement rows keyed by scenario title) makes `task record` the compliant path.
+
    ```bash
    # verdict artifact first (shape: {wbs, verdict, requirements:[{id,status,evidence}], checks:[], source})
    # then the record hop; then re-write Testing/Solution if record's backfill is thinner than intended.
    spur task update <wbs> wip --no-lifecycle
    spur task record <wbs> --solution-from-diff --transition testing
    ```
+
    The engine now preserves an already-authored Testing when the verdict is UNKNOWN (task-service
    `record` fallback-only, mirroring the Review 0593 precedent) — but the order above is still the
    contract for the standard pipeline.

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

@@ -57,7 +57,7 @@ Gherkin template. Conventions:
 - **Scenario-title mapping:** the scenario title is the identity key for traceability edges
   to task files — keep them stable and unique.
 - Generate AC inline (current session) with the BDD template
-  (`.spur/templates/bdd/gherkin.md`), or escalate to `spur agent run` only when a
+  (`templates/bdd/gherkin.md`), or escalate to `spur agent run` only when a
   [subprocess trigger](cross-cutting.md#inline-default-execution-surface) applies. **Thread
   `--agent` through** when the command forwarded one. See the
   [inline-default execution-surface contract](cross-cutting.md#inline-default-execution-surface).
@@ -220,7 +220,7 @@ 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
+(`idea-pipeline.yaml` — resolved from an explicit project path or the bundled tree). Two
 artifacts are the contract between the workflow states and the operator:
 
 **Goal/Scope intent (feature-create).** The agent writes body-only intent files

package/schemas/spur-config.schema.json

@@ -11,7 +11,7 @@
         },
         "version": {
             "type": "string",
-            "description": "Config schema version (string, not integer). Current recommended: '1.1' (ADR-033 executor tiers + planning blocks). '1' remains accepted for backward compatibility."
+            "description": "Config schema version (string, not integer). Current recommended: '1.2' (config-1.2 layered global/project merge, ADR-033 executor tiers + planning blocks). '1' remains accepted for backward compatibility."
         },
         "name": {
             "type": "string",