@gobing-ai/spur 0.3.60 → 0.3.61

package/plugins/sp/skills/spec-decomposition/references/decomposition.md

@@ -146,7 +146,7 @@ blank Design before implement (`/sp:dev-refine` / `dev-refineall`).
 
 The `template` field is the **single variant axis** (TASK_VARIANTS): it selects the section
 layout (the `section-matrix.yaml` variant), the scaffold body file
-(`.spur/templates/task/<variant>.md`), and is written to the task's `template:` frontmatter.
+(`.spur/tasks/templates/<variant>.md`), and is written to the task's `template:` frontmatter.
 Which sections actually appear is **status-driven** by the runtime matrix — query
 `spur task sections <wbs> list --json` rather than assuming a fixed list — pick the variant by
 *purpose*, not by a section checklist.

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

@@ -64,7 +64,7 @@ fails, STOP and report the gap rather than papering over it with customization:
 ```
 spur status
 spur task create "__probe__" --template standard   # confirms task template + matrix resolve
-spur workflow validate .spur/workflows/task-pipeline.yaml
+spur workflow validate task-pipeline.yaml
 ```
 
 ### Phase 1.6 — Rule glob adaptation (LLM-as-judge)

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

@@ -12,7 +12,7 @@ Read this before writing `Solution`, `Testing`, or `Review`. Section **writers**
 evidence section (F92 0593 R1): implement owns `Solution`, the review coordinator
 (`/sp:dev-review`) owns `Review`, and `spur task record` owns `Testing` (bare-`## Review`
 backfill is fallback-only). The owning implementations are
-`.spur/workflows/task-lifecycle.yaml`, `hasPopulatedPriorityTable()` in
+`task-lifecycle.yaml`, `hasPopulatedPriorityTable()` in
 `packages/app/src/services/task-check.ts`, the verdict normalizers in
 `packages/app/src/services/task-record.ts`, and `TASK_CANONICAL_SECTIONS` in
 `packages/domain/src/planning/markdown-document.ts`.

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

@@ -29,7 +29,7 @@ Authored workflows default to a project-local directory, grouped by purpose:
 
 A `--file <path>` argument overrides the default. Keep one workflow per file, named for what it does
 (`approval.yaml`, `import-file.yaml`), not for its mode. The canonical example
-(`.spur/workflows/basic.yaml`) lives here; copy real schema shapes from it rather than from a
+(`basic.yaml`) lives here; copy real schema shapes from it rather than from a
 half-remembered snippet.
 
 ## Sub-procedure: mode-selection gate

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

@@ -143,7 +143,7 @@ must not be changed without updating the backing skill.
 - **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.
 - **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)
 ```

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

@@ -120,7 +120,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/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",