@deftai/directive-content 0.114.0 → 0.116.0

package/packs/strategies/strategies-pack-0.1.json

@@ -81,7 +81,7 @@
         "interview"
       ],
       "path": "strategies/interview.md",
-      "body": "# Interview Strategy\n\nThe standard Deft workflow: structured interview → SPECIFICATION. This is the\ncanonical source of truth for the interview process. All entry points (CLI via\n`directive` / setup Phase 3, agent via `deft-directive-setup` Phase 3, and `templates/make-spec.md`) MUST\nfollow this strategy.\n\nLegend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.\n\n**⚠️ See also**: [strategies/discuss.md](./discuss.md) | [strategies/yolo.md](./yolo.md) | [strategies/artifact-guards.md](./artifact-guards.md) | [core/glossary.md](../glossary.md)\n\n## When to Use\n\n- ! Default strategy for all new projects\n- ~ Projects with unclear or evolving requirements\n- ~ When stakeholder alignment is needed before implementation\n- ? Skip to SPECIFICATION phase if requirements are already fully documented\n\n---\n\n## Chaining Gate\n\nBefore spec generation, offer the user a chance to run preparatory strategies\nor switch to a different spec-generating strategy. This gate is the single\norchestration point for strategy composition.\n\n! The chaining gate MUST always be shown — even when the interview strategy is\ninvoked directly with no prior strategy.\n! The chaining gate is a **blocking question**. The AI MUST present the options\nand wait for the user to choose before proceeding.\n⊗ Skip the chaining gate or proceed to the sizing gate without presenting it.\n\n### When It Appears\n\n- ! Before the [Sizing Gate](#sizing-gate) on every entry to the interview strategy\n- ! After each completed preparatory strategy (recursive — the gate reappears)\n- ! After the [Acceptance Gate](#acceptance-gate) when the user chooses \"Revise\" or \"Switch\"\n\n### Brownfield Detector\n\nBefore rendering menu options, classify the repo (align with setup Phase 3):\n\n- **Brownfield** when **either**:\n  - `PROJECT-DEFINITION` exists under `./xbrief/` or legacy `./vbrief/` (`PROJECT-DEFINITION.xbrief.json` or `PROJECT-DEFINITION.vbrief.json`), **or**\n  - any lifecycle folder (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `xbrief/` or legacy `vbrief/`) has scope records\n- **Greenfield** otherwise\n\n! The detector MUST run on every Chaining Gate presentation.\n⊗ Offer only the greenfield-framed **Proceed to specification** default on a brownfield repo.\n⊗ Treat brownfield as a full create path without an explicit Replace/scrap confirm.\n\n### Options\n\n! Numbered Chaining Gate menus (greenfield and brownfield examples below) MUST end with `Discuss` and `Back` as the final two options per [deterministic-questions.md](../contracts/deterministic-questions.md).\n\nPresent groups sourced from the `Type` column in\n[strategies/README.md](./README.md#strategy-types). The **default path** depends\non the brownfield detector:\n\n**Default path (greenfield):**\n1. **Proceed to specification** (default) — continue to the [Sizing Gate](#sizing-gate) for a full create path\n\n**Default path (brownfield) — create-vs-update menu:**\n1. **Add scope to this project** (default) — load existing project identity + preparatory artifacts; **skip** the greenfield \"what are we building?\" interview; gather only the new scope; emit **one** proposed scope record; apply the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) on write\n2. **Update project definition** — run a **delta** interview against existing identity; apply the [Spec-Generating Guard](./artifact-guards.md#spec-generating-guard-full); **merge** narratives (prefer enrich/merge when the user declines replace)\n3. **Replace specification (scrap)** — full recreate equivalent to greenfield Proceed; **only** after explicit affirmative (`yes` / `confirmed`); vague replies (`proceed`, `ok`, `go ahead`) are **not** acceptance\n   - ! On confirmed scrap, continue to the [Sizing Gate](#sizing-gate) as a full create path\n   - ⊗ Auto-delete PROJECT-DEFINITION without scrap confirm\n   - ⊗ Rename Proceed to \"Update\" without changing behavior\n\n**Preparatory strategies** (type: `preparatory` — loops back to this gate on completion):\n- Research — investigate the domain, find libraries, identify pitfalls\n- Discuss — lock key decisions using Feynman technique\n- Probe — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n- Map — analyze existing codebase conventions\n\n~ Some preparatory strategies (currently map) also support standalone invocation\nvia `/deft:run:<name>` without entering the interview flow. When invoked standalone,\nthey present their own completion options instead of returning to this gate.\nSee `strategies/map.md` for standalone behavior.\n\n**Switch spec-generating strategy** (type: `spec-generating` — replaces current pipeline):\n- Yolo — auto-pilot, Johnbot picks all answers\n- SpecKit — formal spec process with story readiness before implementation\n\n### Run Count Annotations\n\n- ! Previously-run strategies MUST display with a run count (e.g., `Research (ran 1×)`)\n- ! No strategy is ever removed from the gate — users can re-run any strategy\n- ! Run counts are read from `completedStrategies` in\n  [`./xbrief/plan.xbrief.json`](../vbrief/vbrief.md#strategy-chaining-fields)\n\n### State Tracking\n\n- ! On completion of a preparatory strategy, update `completedStrategies` in\n  `./xbrief/plan.xbrief.json`: increment `runCount`, append artifact paths\n- ! Append all new artifact paths to the flat `artifacts` array\n- ! The next strategy and eventual spec generation MUST load all artifacts\n  listed in `plan.xbrief.json`\n- ! On brownfield **Add scope** or **Update project definition**, load existing\n  PROJECT-DEFINITION identity and preparatory artifacts before asking questions\n\n### Write Guards (interview)\n\n! Interview is a **spec-generating** strategy and MUST follow\n[artifact-guards.md](./artifact-guards.md) before emission (Light or Full path).\n\n- ! **Before writing** scope records to `proposed/`: [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) (xbrief-first: `./xbrief/proposed/`, else legacy `./vbrief/proposed/`)\n- ! **Before writing** or updating `PROJECT-DEFINITION`: [Spec-Generating Guard](./artifact-guards.md#spec-generating-guard-full) against the **single live** identity file only — `./xbrief/PROJECT-DEFINITION.xbrief.json` when present (or after `deft migrate:xbrief`); else, until migrated, the existing legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`. ⊗ Dual-write both roots\n- ! Prefer enrich/merge when the user declines replace\n- ⊗ Silently overwrite PROJECT-DEFINITION or same-slug proposed scopes\n- ⊗ Guard only the legacy `vbrief/` path while an `xbrief/` PROJECT-DEFINITION is the live identity\n- ⊗ Rely on write-time guards alone without the brownfield Chaining Gate menu above\n\nSurface this obligation **inside `interview.md`** so agents that load only this\nfile still hit the guards (#2925; incomplete closeout of #82/#387).\n\n### Example Prompt\n\n**Greenfield:**\n\n```\nReady to generate the specification. Before we proceed, would you like to:\n\n1. Proceed to specification (default)\n\n--- Preparatory (loops back) ---\n2. Run a research phase — investigate the domain, find libraries, identify pitfalls\n3. Run a discuss phase — lock key decisions using Feynman technique\n4. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n5. Run a map phase — analyze existing codebase conventions\n\n--- Switch strategy ---\n6. Switch to yolo — auto-pilot picks all answers\n7. Switch to speckit — formal spec process with story readiness before implementation\n8. Other (specify)\n9. Discuss\n10. Back\n```\n\n**Brownfield:**\n\n```\nThis repo already has a project definition and/or scopes. Before we proceed:\n\n1. Add scope to this project (default) — keep identity; add one new proposed scope\n2. Update project definition — delta interview; merge narratives (Spec-Generating Guard)\n3. Replace specification (scrap) — requires explicit yes/confirmed; full recreate\n\n--- Preparatory (loops back) ---\n4. Run a research phase — investigate the domain, find libraries, identify pitfalls\n5. Run a discuss phase — lock key decisions using Feynman technique\n6. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n7. Run a map phase — analyze existing codebase conventions\n\n--- Switch strategy ---\n8. Switch to yolo — auto-pilot picks all answers\n9. Switch to speckit — formal spec process with story readiness before implementation\n10. Other (specify)\n11. Discuss\n12. Back\n```\n\n---\n\n## Sizing Gate\n\nBefore the interview begins, determine project complexity to select the\nappropriate path. The gate runs once, immediately after hearing what the user\nwants to build.\n\n! The sizing gate is a **blocking question**. The AI MUST propose a size and\nwait for the user to confirm or override before asking any interview questions.\n⊗ Combine the sizing proposal with the first interview question in the same message.\n⊗ Proceed to interview questions before the user has explicitly confirmed the path.\n\n### Sizing Signals\n\nThe AI SHOULD propose a size based on these signals; the user confirms or overrides:\n\n- Number of features (≤5 → Light, >5 → Full)\n- Number of components/services (1–2 → Light, 3+ → Full)\n- Expected duration (days → Light, weeks/months → Full)\n- Team/agent count (solo → Light, multi-agent/swarm → Full)\n- Integration complexity (standalone → Light, external APIs/auth/DB → Full)\n\n### PROJECT-DEFINITION.vbrief.json Override\n\n`PROJECT-DEFINITION.vbrief.json` narratives ? declare `\"Process\": \"Light\"` or `\"Process\": \"Full\"` to skip the\ngate entirely. `PROJECT.md` (deprecated) may also carry this field. If the field is absent or empty, the AI MUST ask.\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n    subgraph interview [\"Interview Strategy\"]\n        G{\"⚖️ Sizing Gate\"}\n        I_L[\"💬 Interview<br/><i>Light path</i>\"]\n        I_F[\"💬 Interview<br/><i>Full path</i>\"]\n        P[\"📄 PRD<br/><i>What to build</i>\"]\n        S[\"📋 SPECIFICATION<br/><i>How to build it</i>\"]\n    end\n\n    G -->|\"Light\"| I_L\n    G -->|\"Full\"| I_F\n    I_L -->|\"Ambiguity resolved\"| S\n    I_F -->|\"Ambiguity resolved\"| P\n    P -->|\"Approved\"| S\n    S -->|\"Ready\"| IMPL[\"🔨 Implementation\"]\n\n    style G fill:#f0abfc,stroke:#a21caf,color:#000\n    style I_L fill:#c4b5fd,stroke:#7c3aed,color:#000\n    style I_F fill:#c4b5fd,stroke:#7c3aed,color:#000\n    style P fill:#fef08a,stroke:#ca8a04,color:#000\n    style S fill:#6ee7b7,stroke:#059669,color:#000\n    style IMPL fill:#7dd3fc,stroke:#0284c7,color:#000\n```\n\n---\n\n## Interview Rules (shared by both paths)\n\n- ~ Use Claude AskInterviewQuestion when available (emulate if not)\n- ! Ask **ONE** focused, non-trivial question per step\n- ⊗ Ask multiple questions at once or sneak in \"also\" questions\n- ~ Provide numbered answer options when appropriate\n- ! Include \"other\" option for custom/unknown responses\n- ! Indicate which option is RECOMMENDED\n- ! When making an opinionated recommendation, state the principle (1 sentence)\n- ! When done, append all questions asked and answers given to the working document\n\n### Question Areas\n\n- ! Missing decisions (language, framework, deployment)\n- ! Edge cases (errors, boundaries, failure modes)\n- ! Implementation details (architecture, patterns, libraries)\n- ! Requirements (performance, security, scalability)\n- ! UX/constraints (users, timeline, compatibility)\n- ! Tradeoffs (simplicity vs features, speed vs safety)\n\n### Transition Criteria (interview complete)\n\n- ! All major decisions have answers\n- ! Edge cases are addressed\n- ! User has approved key tradeoffs (Interview strategy) or Johnbot has chosen recommended options (Yolo strategy)\n- ~ Little ambiguity remains\n\n---\n\n## Light Path (small/medium projects)\n\nInterview → scope records (date-prefixed in proposed/) + live PROJECT-DEFINITION + rendered SPECIFICATION (v0.20 contract). Paths are **xbrief-first**: use `./xbrief/` when that root is the live project layout; else legacy `./vbrief/`.\n\n### Flow\n\n1. Sizing gate selects Light\n2. Interview (rules above)\n3. Write scope record(s) to the live lifecycle root — `./xbrief/proposed/YYYY-MM-DD-<slug>.xbrief.json` when `./xbrief/` is live; else legacy `./vbrief/proposed/YYYY-MM-DD-<slug>.vbrief.json` — date-prefixed with `status: proposed`\n4. Run `task project:render` to create/update the **live** PROJECT-DEFINITION under the resolved layout root (`./xbrief/PROJECT-DEFINITION.xbrief.json`). Engine layout resolution requires `xbrief/` (#2112); if the repo is legacy-only `./vbrief/`, run `deft migrate:xbrief` first, then render. Ensure all five lifecycle folders exist under the live root. ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `xbrief/` is live\n5. Summarize decisions, ask user to review\n6. On approval, use `task scope:promote` (or equivalent) to move scope record(s) to `pending/` under the **same** live root with `status: pending` / `approved`\n7. Run `task project:export-spec` / `task spec:render` as appropriate (SPECIFICATION.md is a rendered derivative with deprecation sentinel; `specification.vbrief.json` / `specification.xbrief.json` are legacy and are NOT written by this strategy on the v0.20 path)\n\n! **Before writing** scope records or updating `PROJECT-DEFINITION` on the Light path, follow [artifact-guards.md](./artifact-guards.md): Preparatory Guard for `proposed/` scopes; Spec-Generating Guard against the **live** identity file (xbrief-first). Prefer enrich/merge when the user declines replace.\n! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.\n\n! At the emission step (step 3 above), after writing the scope record(s) to the live `proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).\n\n### SPECIFICATION Structure (Light)\n\n```markdown\n# [Project Name] SPECIFICATION\n\n## Overview\nBrief summary of the project.\n\n## Requirements\n\n### Functional Requirements\n- FR-1: [requirement]\n- FR-2: [requirement]\n\n### Non-Functional Requirements\n- NFR-1: Performance — [requirement]\n- NFR-2: Security — [requirement]\n\n## Architecture\nHigh-level system design, components, data flow.\n\n## Implementation Plan\n\n### Phase 1: Foundation\n#### Subphase 1.1: Setup\n- Task 1.1.1: [description] (traces: FR-1)\n  - Dependencies: none\n  - Acceptance: [criteria]\n\n#### Subphase 1.2: Core (depends on: 1.1)\n- Task 1.2.1: [description] (traces: FR-2, NFR-1)\n\n### Phase 2: Features (depends on: Phase 1)\n...\n\n## Testing Strategy\nHow to verify the implementation meets requirements.\n\n## Deployment\nHow to ship it.\n```\n\n- ! Requirements section MUST appear in SPECIFICATION.md (embedded, no separate PRD)\n- ! Each task SHOULD reference which FR/NFR it implements via `(traces: FR-N)`\n- ⊗ Create a separate PRD.md on the Light path\n\n---\n\n## Full Path (large/complex projects)\n\nInterview → PRD → scope records (date-prefixed in proposed/) + live PROJECT-DEFINITION + rendered SPECIFICATION (v0.20 contract). Paths are **xbrief-first**: use `./xbrief/` when that root is the live project layout; else legacy `./vbrief/`.\n\n### Flow\n\n1. Sizing gate selects Full\n2. Interview (rules above)\n3. Generate `PRD.md` — user approval gate\n4. Write scope record(s) to the live lifecycle root — `./xbrief/proposed/YYYY-MM-DD-<slug>.xbrief.json` when `./xbrief/` is live; else legacy `./vbrief/proposed/YYYY-MM-DD-<slug>.vbrief.json` — date-prefixed with `status: proposed`\n5. Run `task project:render` to create/update the **live** PROJECT-DEFINITION under the resolved layout root (`./xbrief/PROJECT-DEFINITION.xbrief.json`). Engine layout resolution requires `xbrief/` (#2112); if the repo is legacy-only `./vbrief/`, run `deft migrate:xbrief` first, then render. Ensure all five lifecycle folders exist under the live root. ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `xbrief/` is live\n6. Summarize decisions, ask user to review\n7. On approval, use `task scope:promote` (or equivalent) to move scope record(s) to `pending/` under the **same** live root with `status: pending` / `approved`\n8. Run `task project:export-spec` / `task spec:render` as appropriate (SPECIFICATION.md is a rendered derivative with deprecation sentinel; `specification.vbrief.json` / `specification.xbrief.json` are legacy and are NOT written by this strategy on the v0.20 path)\n\n! **Before writing** PRD, scope records, or updating `PROJECT-DEFINITION` on the Full path, follow [artifact-guards.md](./artifact-guards.md): Preparatory Guard for `proposed/` scopes; Spec-Generating Guard against the **live** identity file (xbrief-first). Prefer enrich/merge when the user declines replace.\n! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.\n\n! At the emission step (step 4 above), after writing the scope record(s) to the live `proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).\n\n### PRD Structure (Full path only)\n\n```markdown\n# [Project Name] PRD\n\n## Problem Statement\nWhat problem does this solve? Who has this problem?\n\n## Goals\n- Primary goal\n- Secondary goals\n- Non-goals (explicitly out of scope)\n\n## User Stories\nAs a [user type], I want [capability] so that [benefit].\n\n## Requirements\n\n### Functional Requirements\n- FR-1: [requirement]\n- FR-2: [requirement]\n\n### Non-Functional Requirements\n- NFR-1: Performance — [requirement]\n- NFR-2: Security — [requirement]\n\n## Success Metrics\nHow do we know this succeeded?\n\n## Open Questions\nAny remaining decisions deferred to implementation.\n```\n\n### PRD Guidelines\n\n- ! Focus on WHAT, not HOW\n- ! Use RFC 2119 language (MUST, SHOULD, MAY)\n- ! Number all requirements for traceability\n- ~ Include acceptance criteria for each requirement\n- ⊗ Include implementation details or architecture\n\n### PRD Transition Criteria\n\n- ! All functional requirements documented\n- ! Non-functional requirements specified\n- ! User has reviewed and approved PRD\n- ~ No blocking open questions remain\n\n### PRD Approval Menu (#740, refs #767)\n\n! After every PRD (Product Requirements Document) review, the agent MUST\npresent the canonical numbered approval menu defined in\n[`../references/plain-english-ux.md`](../references/plain-english-ux.md)\n`## Rule 4`. The menu replaces ambiguous `Accept / Refine / Edit`\nbuttons with action-shaped labels and follows the #767 framework rule\nfor deterministic numbered menus -- the **final two numbered options\nMUST be `Discuss` and `Back`**, in that order.\n\n```\nWhat would you like to do with the PRD (Product Requirements Document)?\n\n  1. Approve and continue (lock the PRD, generate the SPECIFICATION)\n  2. Suggest changes (you describe what to change; the agent rewrites)\n  3. Edit yourself (you edit the PRD directly; the agent waits)\n  4. Discuss\n  5. Back\n\nEnter confirm / b back / 0 discuss\n```\n\n! When `contracts/deterministic-questions.md` lands (Agent 1, #767), this\nstrategy MUST defer to that contract for canonical menu wording.\n\n! When the PRD review surfaces a red/green diff, the agent MUST emit a\nnon-alarming preface above it (per `references/plain-english-ux.md` Rule 5):\n\n```\nHere's what changed since the previous draft. Red lines were removed,\ngreen lines were added. Nothing here is broken -- this is a normal\nreview.\n```\n\n? Alternatively, the agent MAY hide the diff entirely on the first review\npass and present a plain-English summary of changes; show the diff only\non the second pass or when the user explicitly asks for it.\n\n- ⊗ Use plain `Accept / Refine / Edit` buttons without explanatory\n  parentheticals.\n- ⊗ Add a numbered approval menu where Discuss and Back are not the\n  final two options.\n- ⊗ Show a red/green diff at first review without a non-alarming preface.\n\n### SPECIFICATION Structure (Full)\n\n```markdown\n# [Project Name] SPECIFICATION\n\n## Overview\nBrief summary and link to PRD.\n\n## Architecture\nHigh-level system design, components, data flow.\n\n## Implementation Plan\n\n### Phase 1: Foundation\n#### Subphase 1.1: Setup\n- Task 1.1.1: [description] (traces: FR-1)\n  - Dependencies: none\n  - Acceptance: [criteria]\n\n#### Subphase 1.2: Core (depends on: 1.1)\n- Task 1.2.1: [description] (traces: FR-2, NFR-1)\n\n### Phase 2: Features (depends on: Phase 1)\n...\n\n## Testing Strategy\nHow to verify the implementation meets requirements.\n\n## Deployment\nHow to ship it.\n```\n\n---\n\n## SPECIFICATION Guidelines (both paths)\n\n- ! Reference requirement IDs (FR-1, NFR-2, etc.) in each task\n- ! Break into phases, subphases, tasks\n- ! Mark ALL dependencies explicitly\n- ! Design for parallel work (multiple agents)\n- ! End each phase/subphase with tests that pass\n- ~ Size tasks for 1-4 hours of work\n- ~ Minimize inter-task dependencies\n- ⊗ Write code (specification only)\n\n### Task Format\n\nEach task SHOULD include:\n- ! Clear description\n- ! Dependencies (or \"none\")\n- ! Acceptance criteria\n- ~ Estimated effort\n- ? Assigned agent (for swarm mode)\n\n### Transition Criteria\n\n- ! All requirements mapped to tasks\n- ! Dependencies form a valid DAG (no cycles)\n- ! Scope records exist in the live `proposed/` root (`./xbrief/proposed/` when live; else legacy `./vbrief/proposed/`) with date-prefixed filenames and `status: \"proposed\"`, or promoted to pending/active (with `status: \"approved\" / \"pending\"`)\n- ! Live PROJECT-DEFINITION is present (`./xbrief/PROJECT-DEFINITION.xbrief.json` when that is the identity; else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) populated via `task project:render`\n- ! `SPECIFICATION.md` has been rendered via export/`task spec:render`\n- ! Proceed to [Acceptance Gate](#acceptance-gate)\n\n---\n\n## Acceptance Gate\n\nAfter spec generation, present the user with a final decision before\nimplementation begins.\n\n! The acceptance gate MUST appear after every spec generation (both Light and\nFull paths).\n! The acceptance gate is a **blocking question**. The AI MUST present the\noptions and wait for the user to choose.\n\n### Options\n\n1. **Accept** — spec is approved, proceed to implementation\n   - ! Before handing off to implementation, verify the project toolchain is installed and functional — see [../coding/toolchain.md](../coding/toolchain.md); stop and report if any required tool is missing\n2. **Revise** — return to the [Chaining Gate](#chaining-gate) with all prior\n   context preserved (completed strategies, artifacts). Run additional\n   preparatory strategies or regenerate the spec.\n3. **Switch strategy** — return to the [Chaining Gate](#chaining-gate) to select\n   a different spec-generating strategy (e.g., switch from interview to speckit)\n\n### SPECIFICATION Approval Menu (#740, refs #767)\n\n! In addition to the structured Accept / Revise / Switch options above,\nthe agent MUST present the canonical numbered approval menu defined in\n[`../references/plain-english-ux.md`](../references/plain-english-ux.md)\n`## Rule 4`. The menu states what each choice will actually do, in\nplain-English action-shaped labels, and follows the #767 framework rule\nfor deterministic numbered menus -- the **final two numbered options\nMUST be `Discuss` and `Back`**, in that order.\n\n```\nWhat would you like to do with the SPECIFICATION?\n\n  1. Approve and continue (lock the SPEC, proceed to implementation)\n  2. Suggest changes (you describe what to change; the agent rewrites)\n  3. Edit yourself (you edit the SPEC directly; the agent waits)\n  4. Discuss\n  5. Back\n\nEnter confirm / b back / 0 discuss\n```\n\n! Option 1 (`Approve and continue`) maps to the `Accept` option above\n(which then runs the toolchain verification). Option 2 (`Suggest\nchanges`) and Option 3 (`Edit yourself`) both map to `Revise` (return to\nthe Chaining Gate with prior context preserved). The numbered menu is\nthe user-facing surface; the structured Accept / Revise / Switch above\nis the agent's internal contract.\n\n! When `contracts/deterministic-questions.md` lands (Agent 1, #767), this\nstrategy MUST defer to that contract for canonical menu wording.\n\n! When the SPECIFICATION review surfaces a red/green diff, the agent\nMUST emit a non-alarming preface above it (per\n`references/plain-english-ux.md` Rule 5):\n\n```\nHere's what changed since the previous draft. Red lines were removed,\ngreen lines were added. Nothing here is broken -- this is a normal\nreview.\n```\n\n? Alternatively, the agent MAY hide the diff entirely on the first\nreview pass and present a plain-English summary of changes; show the\ndiff only on the second pass or when the user explicitly asks for it.\n\n- ⊗ Add a numbered approval menu where Discuss and Back are not the\n  final two options.\n- ⊗ Show a red/green diff at first review without a non-alarming preface.\n\n### Rejected Spec Archival\n\n- ! When the user chooses \"Revise\" or \"Switch\", the current `SPECIFICATION.md`\n  MUST be archived to `history/specs/` before regeneration\n- ! Archived name format: `SPECIFICATION-rejected-{ISO-timestamp}.md`\n  (e.g., `SPECIFICATION-rejected-2026-03-15T19-23-00Z.md`)\n- ! If a `PRD.md` exists (Full path), it is NOT archived — only the spec\n- ~ Include a one-line header in the archived file noting why it was rejected\n\n### State Preservation\n\n- ! All `completedStrategies` and `artifacts` in `plan.xbrief.json` MUST be\n  preserved across revisions\n- ! The chaining gate will show updated run counts reflecting the full session history\n\n---\n\n## Artifacts Summary\n\n**Light path:**\n\n| Artifact | Purpose | Created By |\n|----------|---------|------------|\n| `./xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (else legacy `./vbrief/proposed/YYYY-MM-DD-*.vbrief.json`) | Scope story records (date-prefixed, v0.20 contract) | Interview |\n| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |\n| `SPECIFICATION.md` | Generated plan with embedded Requirements (rendered derivative; deprecation sentinel) | export / `task spec:render` |\n| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |\n\n**Full path:**\n\n| Artifact | Purpose | Created By |\n|----------|---------|------------|\n| `PRD.md` | What to build (approval gate) | Interview |\n| `./xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (else legacy `./vbrief/proposed/YYYY-MM-DD-*.vbrief.json`) | Scope story records (date-prefixed, v0.20 contract) | Post-PRD interview |\n| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |\n| `SPECIFICATION.md` | Generated implementation plan (rendered derivative; deprecation sentinel) | export / `task spec:render` |\n| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |\n\n## Invoking This Strategy\n\n```\n/deft:run:interview [project name]\n```\n\nOr explicitly:\n\n```\nUse the interview strategy to plan [project].\n```\n\nAfter completion:\n\n```\nimplement the scope records in ./xbrief/active/ (or legacy ./vbrief/active/)\n```\n"
+      "body": "# Interview Strategy\n\nThe standard Deft workflow: structured interview → SPECIFICATION. This is the\ncanonical source of truth for the interview process. All entry points (CLI via\n`directive` / setup Phase 3, agent via `deft-directive-setup` Phase 3, and `templates/make-spec.md`) MUST\nfollow this strategy.\n\nLegend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.\n\n**⚠️ See also**: [strategies/discuss.md](./discuss.md) | [strategies/yolo.md](./yolo.md) | [strategies/artifact-guards.md](./artifact-guards.md) | [core/glossary.md](../glossary.md)\n\n## When to Use\n\n- ! Default strategy for all new projects\n- ~ Projects with unclear or evolving requirements\n- ~ When stakeholder alignment is needed before implementation\n- ? Skip to SPECIFICATION phase if requirements are already fully documented\n\n---\n\n## Chaining Gate\n\nBefore spec generation, offer the user a chance to run preparatory strategies\nor switch to a different spec-generating strategy. This gate is the single\norchestration point for strategy composition.\n\n! The chaining gate MUST always be shown — even when the interview strategy is\ninvoked directly with no prior strategy.\n! The chaining gate is a **blocking question**. The AI MUST present the options\nand wait for the user to choose before proceeding.\n⊗ Skip the chaining gate or proceed to the sizing gate without presenting it.\n\n### When It Appears\n\n- ! Before the [Sizing Gate](#sizing-gate) on every entry to the interview strategy\n- ! After each completed preparatory strategy (recursive — the gate reappears)\n- ! After the [Acceptance Gate](#acceptance-gate) when the user chooses \"Revise\" or \"Switch\"\n\n### Brownfield Detector\n\nBefore rendering menu options, classify the repo (align with setup Phase 3):\n\n- **Brownfield** when **either**:\n  - `PROJECT-DEFINITION` exists under `./xbrief/` or legacy `./vbrief/` (`PROJECT-DEFINITION.xbrief.json` or `PROJECT-DEFINITION.vbrief.json`), **or**\n  - any lifecycle folder (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `xbrief/` or legacy `vbrief/`) has scope records\n- **Greenfield** otherwise\n\n! The detector MUST run on every Chaining Gate presentation.\n⊗ Offer only the greenfield-framed **Proceed to specification** default on a brownfield repo.\n⊗ Treat brownfield as a full create path without an explicit Replace/scrap confirm.\n\n### Options\n\n! Numbered Chaining Gate menus (greenfield and brownfield examples below) MUST end with `Discuss` and `Back` as the final two options per [deterministic-questions.md](../contracts/deterministic-questions.md).\n\nPresent groups sourced from the `Type` column in\n[strategies/README.md](./README.md#strategy-types). The **default path** depends\non the brownfield detector:\n\n**Default path (greenfield):**\n1. **Proceed to specification** (default) — continue to the [Sizing Gate](#sizing-gate) for a full create path\n\n**Default path (brownfield) — create-vs-update menu:**\n1. **Add scope to this project** (default) — load existing project identity + preparatory artifacts; **skip** the greenfield \"what are we building?\" interview; gather only the new scope; emit **one** proposed scope record; apply the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) on write\n2. **Update project definition** — run a **delta** interview against existing identity; apply the [Spec-Generating Guard](./artifact-guards.md#spec-generating-guard-full); **merge** narratives (prefer enrich/merge when the user declines replace)\n3. **Replace specification (scrap)** — full recreate equivalent to greenfield Proceed; **only** after explicit affirmative (`yes` / `confirmed`); vague replies (`proceed`, `ok`, `go ahead`) are **not** acceptance\n   - ! On confirmed scrap, continue to the [Sizing Gate](#sizing-gate) as a full create path\n   - ⊗ Auto-delete PROJECT-DEFINITION without scrap confirm\n   - ⊗ Rename Proceed to \"Update\" without changing behavior\n4. **Process-only (keep Phase 2 identity)** — leave strategy; no new scope; no spec write. Do not emit a proposed scope. Do not merge or scrap PROJECT-DEFINITION narratives. Then-path: session ritual / deft check / later Add scope. Skip Sizing Gate, export, Acceptance Gate, and build. GitHub issues stay cache/queue inputs. Docs stay described content.\n   - ⊗ Use Back or Other as this option\n   - ⊗ Bind docs or issues as the next-build plan\n\n**Preparatory strategies** (type: `preparatory` — loops back to this gate on completion):\n- Research — investigate the domain, find libraries, identify pitfalls\n- Discuss — lock key decisions using Feynman technique\n- Probe — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n- Map — analyze existing codebase conventions\n\n~ Some preparatory strategies (currently map) also support standalone invocation\nvia `/deft:run:<name>` without entering the interview flow. When invoked standalone,\nthey present their own completion options instead of returning to this gate.\nSee `strategies/map.md` for standalone behavior.\n\n**Switch spec-generating strategy** (type: `spec-generating` — replaces current pipeline):\n- Yolo — auto-pilot, Johnbot picks all answers\n- SpecKit — formal spec process with story readiness before implementation\n\n### Run Count Annotations\n\n- ! Previously-run strategies MUST display with a run count (e.g., `Research (ran 1×)`)\n- ! No strategy is ever removed from the gate — users can re-run any strategy\n- ! Run counts are read from `completedStrategies` in\n  [`./xbrief/plan.xbrief.json`](../vbrief/vbrief.md#strategy-chaining-fields)\n\n### State Tracking\n\n- ! On completion of a preparatory strategy, update `completedStrategies` in\n  `./xbrief/plan.xbrief.json`: increment `runCount`, append artifact paths\n- ! Append all new artifact paths to the flat `artifacts` array\n- ! The next strategy and eventual spec generation MUST load all artifacts\n  listed in `plan.xbrief.json`\n- ! On brownfield **Add scope** or **Update project definition**, load existing\n  PROJECT-DEFINITION identity and preparatory artifacts before asking questions\n\n### Write Guards (interview)\n\n! Interview is a **spec-generating** strategy and MUST follow\n[artifact-guards.md](./artifact-guards.md) before emission (Light or Full path).\n\n- ! **Before writing** scope records to `proposed/`: [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) (xbrief-first: `./xbrief/proposed/`, else legacy `./vbrief/proposed/`)\n- ! **Before writing** or updating `PROJECT-DEFINITION`: [Spec-Generating Guard](./artifact-guards.md#spec-generating-guard-full) against the **single live** identity file only — `./xbrief/PROJECT-DEFINITION.xbrief.json` when present (or after `deft migrate:xbrief`); else, until migrated, the existing legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`. ⊗ Dual-write both roots\n- ! Prefer enrich/merge when the user declines replace\n- ⊗ Silently overwrite PROJECT-DEFINITION or same-slug proposed scopes\n- ⊗ Guard only the legacy `vbrief/` path while an `xbrief/` PROJECT-DEFINITION is the live identity\n- ⊗ Rely on write-time guards alone without the brownfield Chaining Gate menu above\n\nSurface this obligation **inside `interview.md`** so agents that load only this\nfile still hit the guards (#2925; incomplete closeout of #82/#387).\n\n### Example Prompt\n\n**Greenfield:**\n\n```\nReady to generate the specification. Before we proceed, would you like to:\n\n1. Proceed to specification (default)\n\n--- Preparatory (loops back) ---\n2. Run a research phase — investigate the domain, find libraries, identify pitfalls\n3. Run a discuss phase — lock key decisions using Feynman technique\n4. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n5. Run a map phase — analyze existing codebase conventions\n\n--- Switch strategy ---\n6. Switch to yolo — auto-pilot picks all answers\n7. Switch to speckit — formal spec process with story readiness before implementation\n8. Other (specify)\n9. Discuss\n10. Back\n```\n\n**Brownfield:**\n\n```\nThis repo already has a project definition and/or scopes. Before we proceed:\n\n1. Add scope to this project (default) — keep identity; add one new proposed scope\n2. Update project definition — delta interview; merge narratives (Spec-Generating Guard)\n3. Replace specification (scrap) — requires explicit yes/confirmed; full recreate\n4. Process-only (keep Phase 2 identity) — leave strategy; no new scope; no spec write\n\n--- Preparatory (loops back) ---\n5. Run a research phase — investigate the domain, find libraries, identify pitfalls\n6. Run a discuss phase — lock key decisions using Feynman technique\n7. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n8. Run a map phase — analyze existing codebase conventions\n\n--- Switch strategy ---\n9. Switch to yolo — auto-pilot picks all answers\n10. Switch to speckit — formal spec process with story readiness before implementation\n11. Other (specify)\n12. Discuss\n13. Back\n```\n\n---\n\n## Sizing Gate\n\nBefore the interview begins, determine project complexity to select the\nappropriate path. The gate runs once, immediately after hearing what the user\nwants to build.\n\n! The sizing gate is a **blocking question**. The AI MUST propose a size and\nwait for the user to confirm or override before asking any interview questions.\n⊗ Combine the sizing proposal with the first interview question in the same message.\n⊗ Proceed to interview questions before the user has explicitly confirmed the path.\n\n### Sizing Signals\n\nThe AI SHOULD propose a size based on these signals; the user confirms or overrides:\n\n- Number of features (≤5 → Light, >5 → Full)\n- Number of components/services (1–2 → Light, 3+ → Full)\n- Expected duration (days → Light, weeks/months → Full)\n- Team/agent count (solo → Light, multi-agent/swarm → Full)\n- Integration complexity (standalone → Light, external APIs/auth/DB → Full)\n\n### PROJECT-DEFINITION.vbrief.json Override\n\n`PROJECT-DEFINITION.vbrief.json` narratives ? declare `\"Process\": \"Light\"` or `\"Process\": \"Full\"` to skip the\ngate entirely. `PROJECT.md` (deprecated) may also carry this field. If the field is absent or empty, the AI MUST ask.\n\n## Workflow Overview\n\n```mermaid\nflowchart LR\n    subgraph interview [\"Interview Strategy\"]\n        G{\"⚖️ Sizing Gate\"}\n        I_L[\"💬 Interview<br/><i>Light path</i>\"]\n        I_F[\"💬 Interview<br/><i>Full path</i>\"]\n        P[\"📄 PRD<br/><i>What to build</i>\"]\n        S[\"📋 SPECIFICATION<br/><i>How to build it</i>\"]\n    end\n\n    G -->|\"Light\"| I_L\n    G -->|\"Full\"| I_F\n    I_L -->|\"Ambiguity resolved\"| S\n    I_F -->|\"Ambiguity resolved\"| P\n    P -->|\"Approved\"| S\n    S -->|\"Ready\"| IMPL[\"🔨 Implementation\"]\n\n    style G fill:#f0abfc,stroke:#a21caf,color:#000\n    style I_L fill:#c4b5fd,stroke:#7c3aed,color:#000\n    style I_F fill:#c4b5fd,stroke:#7c3aed,color:#000\n    style P fill:#fef08a,stroke:#ca8a04,color:#000\n    style S fill:#6ee7b7,stroke:#059669,color:#000\n    style IMPL fill:#7dd3fc,stroke:#0284c7,color:#000\n```\n\n---\n\n## Interview Rules (shared by both paths)\n\n- ~ Use Claude AskInterviewQuestion when available (emulate if not)\n- ! Ask **ONE** focused, non-trivial question per step\n- ⊗ Ask multiple questions at once or sneak in \"also\" questions\n- ~ Provide numbered answer options when appropriate\n- ! Include \"other\" option for custom/unknown responses\n- ! Indicate which option is RECOMMENDED\n- ! When making an opinionated recommendation, state the principle (1 sentence)\n- ! When done, append all questions asked and answers given to the working document\n\n### Question Areas\n\n- ! Missing decisions (language, framework, deployment)\n- ! Edge cases (errors, boundaries, failure modes)\n- ! Implementation details (architecture, patterns, libraries)\n- ! Requirements (performance, security, scalability)\n- ! UX/constraints (users, timeline, compatibility)\n- ! Tradeoffs (simplicity vs features, speed vs safety)\n\n### Transition Criteria (interview complete)\n\n- ! All major decisions have answers\n- ! Edge cases are addressed\n- ! User has approved key tradeoffs (Interview strategy) or Johnbot has chosen recommended options (Yolo strategy)\n- ~ Little ambiguity remains\n\n---\n\n## Light Path (small/medium projects)\n\nInterview → scope records (date-prefixed in proposed/) + live PROJECT-DEFINITION + rendered SPECIFICATION (v0.20 contract). Paths are **xbrief-first**: use `./xbrief/` when that root is the live project layout; else legacy `./vbrief/`.\n\n### Flow\n\n1. Sizing gate selects Light\n2. Interview (rules above)\n3. Write scope record(s) to the live lifecycle root — `./xbrief/proposed/YYYY-MM-DD-<slug>.xbrief.json` when `./xbrief/` is live; else legacy `./vbrief/proposed/YYYY-MM-DD-<slug>.vbrief.json` — date-prefixed with `status: proposed`\n4. Run `task project:render` to create/update the **live** PROJECT-DEFINITION under the resolved layout root (`./xbrief/PROJECT-DEFINITION.xbrief.json`). Engine layout resolution requires `xbrief/` (#2112); if the repo is legacy-only `./vbrief/`, run `deft migrate:xbrief` first, then render. Ensure all five lifecycle folders exist under the live root. ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `xbrief/` is live\n5. Summarize decisions, ask user to review\n6. On approval, use `task scope:promote` (or equivalent) to move scope record(s) to `pending/` under the **same** live root with `status: pending` / `approved`\n7. Run `task project:export-spec` / `task spec:render` as appropriate (SPECIFICATION.md is a rendered derivative with deprecation sentinel; `specification.vbrief.json` / `specification.xbrief.json` are legacy and are NOT written by this strategy on the v0.20 path)\n\n! **Before writing** scope records or updating `PROJECT-DEFINITION` on the Light path, follow [artifact-guards.md](./artifact-guards.md): Preparatory Guard for `proposed/` scopes; Spec-Generating Guard against the **live** identity file (xbrief-first). Prefer enrich/merge when the user declines replace.\n! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.\n\n! At the emission step (step 3 above), after writing the scope record(s) to the live `proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).\n\n### SPECIFICATION Structure (Light)\n\n```markdown\n# [Project Name] SPECIFICATION\n\n## Overview\nBrief summary of the project.\n\n## Requirements\n\n### Functional Requirements\n- FR-1: [requirement]\n- FR-2: [requirement]\n\n### Non-Functional Requirements\n- NFR-1: Performance — [requirement]\n- NFR-2: Security — [requirement]\n\n## Architecture\nHigh-level system design, components, data flow.\n\n## Implementation Plan\n\n### Phase 1: Foundation\n#### Subphase 1.1: Setup\n- Task 1.1.1: [description] (traces: FR-1)\n  - Dependencies: none\n  - Acceptance: [criteria]\n\n#### Subphase 1.2: Core (depends on: 1.1)\n- Task 1.2.1: [description] (traces: FR-2, NFR-1)\n\n### Phase 2: Features (depends on: Phase 1)\n...\n\n## Testing Strategy\nHow to verify the implementation meets requirements.\n\n## Deployment\nHow to ship it.\n```\n\n- ! Requirements section MUST appear in SPECIFICATION.md (embedded, no separate PRD)\n- ! Each task SHOULD reference which FR/NFR it implements via `(traces: FR-N)`\n- ⊗ Create a separate PRD.md on the Light path\n\n---\n\n## Full Path (large/complex projects)\n\nInterview → PRD → scope records (date-prefixed in proposed/) + live PROJECT-DEFINITION + rendered SPECIFICATION (v0.20 contract). Paths are **xbrief-first**: use `./xbrief/` when that root is the live project layout; else legacy `./vbrief/`.\n\n### Flow\n\n1. Sizing gate selects Full\n2. Interview (rules above)\n3. Generate `PRD.md` — user approval gate\n4. Write scope record(s) to the live lifecycle root — `./xbrief/proposed/YYYY-MM-DD-<slug>.xbrief.json` when `./xbrief/` is live; else legacy `./vbrief/proposed/YYYY-MM-DD-<slug>.vbrief.json` — date-prefixed with `status: proposed`\n5. Run `task project:render` to create/update the **live** PROJECT-DEFINITION under the resolved layout root (`./xbrief/PROJECT-DEFINITION.xbrief.json`). Engine layout resolution requires `xbrief/` (#2112); if the repo is legacy-only `./vbrief/`, run `deft migrate:xbrief` first, then render. Ensure all five lifecycle folders exist under the live root. ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `xbrief/` is live\n6. Summarize decisions, ask user to review\n7. On approval, use `task scope:promote` (or equivalent) to move scope record(s) to `pending/` under the **same** live root with `status: pending` / `approved`\n8. Run `task project:export-spec` / `task spec:render` as appropriate (SPECIFICATION.md is a rendered derivative with deprecation sentinel; `specification.vbrief.json` / `specification.xbrief.json` are legacy and are NOT written by this strategy on the v0.20 path)\n\n! **Before writing** PRD, scope records, or updating `PROJECT-DEFINITION` on the Full path, follow [artifact-guards.md](./artifact-guards.md): Preparatory Guard for `proposed/` scopes; Spec-Generating Guard against the **live** identity file (xbrief-first). Prefer enrich/merge when the user declines replace.\n! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.\n\n! At the emission step (step 4 above), after writing the scope record(s) to the live `proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`).\n\n### PRD Structure (Full path only)\n\n```markdown\n# [Project Name] PRD\n\n## Problem Statement\nWhat problem does this solve? Who has this problem?\n\n## Goals\n- Primary goal\n- Secondary goals\n- Non-goals (explicitly out of scope)\n\n## User Stories\nAs a [user type], I want [capability] so that [benefit].\n\n## Requirements\n\n### Functional Requirements\n- FR-1: [requirement]\n- FR-2: [requirement]\n\n### Non-Functional Requirements\n- NFR-1: Performance — [requirement]\n- NFR-2: Security — [requirement]\n\n## Success Metrics\nHow do we know this succeeded?\n\n## Open Questions\nAny remaining decisions deferred to implementation.\n```\n\n### PRD Guidelines\n\n- ! Focus on WHAT, not HOW\n- ! Use RFC 2119 language (MUST, SHOULD, MAY)\n- ! Number all requirements for traceability\n- ~ Include acceptance criteria for each requirement\n- ⊗ Include implementation details or architecture\n\n### PRD Transition Criteria\n\n- ! All functional requirements documented\n- ! Non-functional requirements specified\n- ! User has reviewed and approved PRD\n- ~ No blocking open questions remain\n\n### PRD Approval Menu (#740, refs #767)\n\n! After every PRD (Product Requirements Document) review, the agent MUST\npresent the canonical numbered approval menu defined in\n[`../references/plain-english-ux.md`](../references/plain-english-ux.md)\n`## Rule 4`. The menu replaces ambiguous `Accept / Refine / Edit`\nbuttons with action-shaped labels and follows the #767 framework rule\nfor deterministic numbered menus -- the **final two numbered options\nMUST be `Discuss` and `Back`**, in that order.\n\n```\nWhat would you like to do with the PRD (Product Requirements Document)?\n\n  1. Approve and continue (lock the PRD, generate the SPECIFICATION)\n  2. Suggest changes (you describe what to change; the agent rewrites)\n  3. Edit yourself (you edit the PRD directly; the agent waits)\n  4. Discuss\n  5. Back\n\nEnter confirm / b back / 0 discuss\n```\n\n! When `contracts/deterministic-questions.md` lands (Agent 1, #767), this\nstrategy MUST defer to that contract for canonical menu wording.\n\n! When the PRD review surfaces a red/green diff, the agent MUST emit a\nnon-alarming preface above it (per `references/plain-english-ux.md` Rule 5):\n\n```\nHere's what changed since the previous draft. Red lines were removed,\ngreen lines were added. Nothing here is broken -- this is a normal\nreview.\n```\n\n? Alternatively, the agent MAY hide the diff entirely on the first review\npass and present a plain-English summary of changes; show the diff only\non the second pass or when the user explicitly asks for it.\n\n- ⊗ Use plain `Accept / Refine / Edit` buttons without explanatory\n  parentheticals.\n- ⊗ Add a numbered approval menu where Discuss and Back are not the\n  final two options.\n- ⊗ Show a red/green diff at first review without a non-alarming preface.\n\n### SPECIFICATION Structure (Full)\n\n```markdown\n# [Project Name] SPECIFICATION\n\n## Overview\nBrief summary and link to PRD.\n\n## Architecture\nHigh-level system design, components, data flow.\n\n## Implementation Plan\n\n### Phase 1: Foundation\n#### Subphase 1.1: Setup\n- Task 1.1.1: [description] (traces: FR-1)\n  - Dependencies: none\n  - Acceptance: [criteria]\n\n#### Subphase 1.2: Core (depends on: 1.1)\n- Task 1.2.1: [description] (traces: FR-2, NFR-1)\n\n### Phase 2: Features (depends on: Phase 1)\n...\n\n## Testing Strategy\nHow to verify the implementation meets requirements.\n\n## Deployment\nHow to ship it.\n```\n\n---\n\n## SPECIFICATION Guidelines (both paths)\n\n- ! Reference requirement IDs (FR-1, NFR-2, etc.) in each task\n- ! Break into phases, subphases, tasks\n- ! Mark ALL dependencies explicitly\n- ! Design for parallel work (multiple agents)\n- ! End each phase/subphase with tests that pass\n- ~ Size tasks for 1-4 hours of work\n- ~ Minimize inter-task dependencies\n- ⊗ Write code (specification only)\n\n### Task Format\n\nEach task SHOULD include:\n- ! Clear description\n- ! Dependencies (or \"none\")\n- ! Acceptance criteria\n- ~ Estimated effort\n- ? Assigned agent (for swarm mode)\n\n### Transition Criteria\n\n- ! All requirements mapped to tasks\n- ! Dependencies form a valid DAG (no cycles)\n- ! Scope records exist in the live `proposed/` root (`./xbrief/proposed/` when live; else legacy `./vbrief/proposed/`) with date-prefixed filenames and `status: \"proposed\"`, or promoted to pending/active (with `status: \"approved\" / \"pending\"`)\n- ! Live PROJECT-DEFINITION is present (`./xbrief/PROJECT-DEFINITION.xbrief.json` when that is the identity; else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) populated via `task project:render`\n- ! `SPECIFICATION.md` has been rendered via export/`task spec:render`\n- ! Proceed to [Acceptance Gate](#acceptance-gate)\n\n---\n\n## Acceptance Gate\n\nAfter spec generation, present the user with a final decision before\nimplementation begins.\n\n! The acceptance gate MUST appear after every spec generation (both Light and\nFull paths).\n! The acceptance gate is a **blocking question**. The AI MUST present the\noptions and wait for the user to choose.\n\n### Options\n\n1. **Accept** — spec is approved, proceed to implementation\n   - ! Before handing off to implementation, verify the project toolchain is installed and functional — see [../coding/toolchain.md](../coding/toolchain.md); stop and report if any required tool is missing\n2. **Revise** — return to the [Chaining Gate](#chaining-gate) with all prior\n   context preserved (completed strategies, artifacts). Run additional\n   preparatory strategies or regenerate the spec.\n3. **Switch strategy** — return to the [Chaining Gate](#chaining-gate) to select\n   a different spec-generating strategy (e.g., switch from interview to speckit)\n\n### SPECIFICATION Approval Menu (#740, refs #767)\n\n! In addition to the structured Accept / Revise / Switch options above,\nthe agent MUST present the canonical numbered approval menu defined in\n[`../references/plain-english-ux.md`](../references/plain-english-ux.md)\n`## Rule 4`. The menu states what each choice will actually do, in\nplain-English action-shaped labels, and follows the #767 framework rule\nfor deterministic numbered menus -- the **final two numbered options\nMUST be `Discuss` and `Back`**, in that order.\n\n```\nWhat would you like to do with the SPECIFICATION?\n\n  1. Approve and continue (lock the SPEC, proceed to implementation)\n  2. Suggest changes (you describe what to change; the agent rewrites)\n  3. Edit yourself (you edit the SPEC directly; the agent waits)\n  4. Discuss\n  5. Back\n\nEnter confirm / b back / 0 discuss\n```\n\n! Option 1 (`Approve and continue`) maps to the `Accept` option above\n(which then runs the toolchain verification). Option 2 (`Suggest\nchanges`) and Option 3 (`Edit yourself`) both map to `Revise` (return to\nthe Chaining Gate with prior context preserved). The numbered menu is\nthe user-facing surface; the structured Accept / Revise / Switch above\nis the agent's internal contract.\n\n! When `contracts/deterministic-questions.md` lands (Agent 1, #767), this\nstrategy MUST defer to that contract for canonical menu wording.\n\n! When the SPECIFICATION review surfaces a red/green diff, the agent\nMUST emit a non-alarming preface above it (per\n`references/plain-english-ux.md` Rule 5):\n\n```\nHere's what changed since the previous draft. Red lines were removed,\ngreen lines were added. Nothing here is broken -- this is a normal\nreview.\n```\n\n? Alternatively, the agent MAY hide the diff entirely on the first\nreview pass and present a plain-English summary of changes; show the\ndiff only on the second pass or when the user explicitly asks for it.\n\n- ⊗ Add a numbered approval menu where Discuss and Back are not the\n  final two options.\n- ⊗ Show a red/green diff at first review without a non-alarming preface.\n\n### Rejected Spec Archival\n\n- ! When the user chooses \"Revise\" or \"Switch\", the current `SPECIFICATION.md`\n  MUST be archived to `history/specs/` before regeneration\n- ! Archived name format: `SPECIFICATION-rejected-{ISO-timestamp}.md`\n  (e.g., `SPECIFICATION-rejected-2026-03-15T19-23-00Z.md`)\n- ! If a `PRD.md` exists (Full path), it is NOT archived — only the spec\n- ~ Include a one-line header in the archived file noting why it was rejected\n\n### State Preservation\n\n- ! All `completedStrategies` and `artifacts` in `plan.xbrief.json` MUST be\n  preserved across revisions\n- ! The chaining gate will show updated run counts reflecting the full session history\n\n---\n\n## Artifacts Summary\n\n**Light path:**\n\n| Artifact | Purpose | Created By |\n|----------|---------|------------|\n| `./xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (else legacy `./vbrief/proposed/YYYY-MM-DD-*.vbrief.json`) | Scope story records (date-prefixed, v0.20 contract) | Interview |\n| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |\n| `SPECIFICATION.md` | Generated plan with embedded Requirements (rendered derivative; deprecation sentinel) | export / `task spec:render` |\n| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |\n\n**Full path:**\n\n| Artifact | Purpose | Created By |\n|----------|---------|------------|\n| `PRD.md` | What to build (approval gate) | Interview |\n| `./xbrief/proposed/YYYY-MM-DD-*.xbrief.json` (else legacy `./vbrief/proposed/YYYY-MM-DD-*.vbrief.json`) | Scope story records (date-prefixed, v0.20 contract) | Post-PRD interview |\n| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |\n| `SPECIFICATION.md` | Generated implementation plan (rendered derivative; deprecation sentinel) | export / `task spec:render` |\n| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |\n\n## Invoking This Strategy\n\n```\n/deft:run:interview [project name]\n```\n\nOr explicitly:\n\n```\nUse the interview strategy to plan [project].\n```\n\nAfter completion:\n\n```\nimplement the scope records in ./xbrief/active/ (or legacy ./vbrief/active/)\n```\n"
     },
     {
       "id": "map",

package/scm/github.md

@@ -38,6 +38,37 @@ Rules that apply to every `gh` invocation, regardless of context.
 - ⊗ Construct Markdown-rich `gh api -f body="..."` or `gh issue comment --body "..."` commands when the body contains backticks, dollar signs, quotes, or fenced code blocks -- use a body file and the `scm:body:*` wrapper instead
 - ⊗ Write `--body-file` temp files inside the worktree or repository directory -- always use the OS temp directory (`$env:TEMP` on PowerShell, `$TMPDIR` or `/tmp` on Unix)
 
+### Explicit PR bodies skip the GitHub template (#4293)
+
+`gh pr create --body-file`, `--body`, and `--fill` replace `.github/PULL_REQUEST_TEMPLATE.md`. They do not fill it. Leftover-complete and `swarm:finalize-cohort` openers use an explicit body.
+
+- ! Compose the template `Documentation impact` block (`change_class` / `surfaces` / quoted `rationale`) into the body-file or `--body` payload before create or edit
+- ! Run `task verify:docs-impact -- --body-file <path>` on that same file object, then pass `--body-file <path>` to `gh pr create` / `gh pr edit`. The verified bytes are the uploaded bytes
+- ⊗ Treat a custom `--body-file` as an exemption from the declaration
+- ⊗ Verify file A then upload file B
+- ⊗ Treat naming the check in pre-pr / review-cycle / swarm story-open as the leftover-complete or finalize-cohort remedy
+- ⊗ Invent `scm:pr:create` -- `tasks/scm.yml` has `body:pr:edit` only; create stays `gh pr create --body-file`
+
+**PowerShell (PR open, leftover-complete included):**
+
+```powershell
+$bodyFile = [System.IO.Path]::GetTempFileName()
+# $content already includes the template Documentation impact block
+[System.IO.File]::WriteAllText($bodyFile, $content, [System.Text.UTF8Encoding]::new($false))
+task verify:docs-impact -- --body-file $bodyFile
+gh pr create --title "feat: example" --body-file $bodyFile
+```
+
+**Unix (bash/zsh):**
+
+```bash
+bodyFile=$(mktemp)
+# $content already includes the template Documentation impact block
+printf "%s" "$content" > "$bodyFile"
+task verify:docs-impact -- --body-file "$bodyFile"
+gh pr create --title "feat: example" --body-file "$bodyFile"
+```
+
 ## Safe Markdown Body Posting (#1555)
 
 Use `task scm:body:*` (`scm:body:comment:create`, `scm:body:issue:edit`, `scm:body:pr:edit`) whenever an agent needs to post or edit Markdown-rich GitHub text. The helper accepts `--body-file <path>`, wraps the body as JSON, calls `gh api --input -` with explicit UTF-8 encoding, and prints the live read-back object returned by `gh`.
@@ -214,6 +245,7 @@ On Windows PowerShell (5.1 and often `pwsh` when commands are not routed through
 $bodyFile = [System.IO.Path]::GetTempFileName()
 [System.IO.File]::WriteAllText($bodyFile, $prBody, [System.Text.UTF8Encoding]::new($false))
 git commit -F $bodyFile
+task verify:docs-impact -- --body-file $bodyFile
 gh pr create --title "feat: example" --body-file $bodyFile
 ```
 

package/skills/deft-directive-build/SKILL.md

@@ -277,7 +277,9 @@ Multi-iteration implement-fix and pre-PR polish loops MUST carry **both** a succ
 |------------|--------------|----------------------|
 | Implement / quality fix (tests, lint, typecheck, coverage, AC) | Affected/static gates green for the change; AC met | **max 5** fix iterations **or** **3** consecutive identical outcomes (same failing command + same primary error class) with no material code/config change |
 | Pre-PR polish (`deft-directive-pre-pr` Read-Write-Lint-Diff) | Full pass with zero further edits | **max 3** polish passes **or** **2** consecutive no-diff / same-diff outcomes |
-| Full `task check` re-run after a red merge chokepoint | `task check` green | Counts toward the implement/quality fix envelope above (do not open a separate unbounded check-retry loop) |
+| Full `task check` re-run | `task check` green after a red merge chokepoint or a new commit | Counts toward the implement/quality fix envelope above (do not open a separate unbounded check-retry loop) |
+
+- ! Re-run full `task check` only after a red merge chokepoint or a new commit.
 
 **On failure stop:**
 

package/skills/deft-directive-design-critique/SKILL.md

@@ -45,12 +45,13 @@ Comment lead (model then role): Stop 3 — Critic envelope.
 Operator-gated loop. Successor lean. Parent-side substantiation. Operator verbs. Dual stop. Halt line. Bind after accepted synthesis.
 After this round's siblings are posted: successor lean, then verbs.
 Auto-stamp after operator confirm; not while same-round siblings outstanding.
+Yolo standing confirm of a posted all-accept map: Operator verbs. Confirm conjunct only. Not ingest.
 Walk / walk all. Auto-stamp when agents agree: Operator verbs.
 Parent chip write: scm:issue:design-critique-chip.
 Chip apply miss is non-blocking convenience; do not halt. Ingest waits on the completed-arc record, not a catalog chip.
 Run posture: parse closed tokens; else ask. Field lives in the contract.
 Grok-bot detect default and widget apply-set live in the contract. Consume parseOperatorRunPosture.
-Widgets: numbered Discuss and Back. Plain English first in main-chat.
+Widgets: numbered Discuss and Back. Plain English first in main-chat. `## Plain-language summary`.
 
 Each critic dispatch EXITs after posting.
 

package/skills/deft-directive-pre-pr/SKILL.md

@@ -23,13 +23,13 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## Branch-Protection Policy Guard
 
-! Before entering Phase 1 (Read), run the skill-level branch-policy guard documented in `task policy:show` / `task verify:branch` (#746 / #747). Halt before any state mutation (the Phase 2 Write phase, the Phase 3 Lint phase that may touch files) when the policy is unresolvable AND no env-var bypass is active:
+! Before entering Phase 1 (Read), run the skill-level branch-policy guard documented in `task policy:show` / dual-invoke `deft verify:branch` (#746 / #747). Halt before any state mutation (the Phase 2 Write phase, the Phase 3 Lint phase that may touch files) when the policy is unresolvable AND no env-var bypass is active:
 
 ```
-task verify:branch
+deft verify:branch
 ```
 
-or invoke `task verify:branch`. Pre-PR is the last gate before push, so a stale / unresolvable policy here is the highest-leverage place to catch the bug before it reaches the bot reviewer.
+or `task deft:verify:branch` when the consumer Taskfile include is present. Do not add a consumer `verify:branch` task. Pre-PR is the last gate before push, so a stale / unresolvable policy here is the highest-leverage place to catch the bug before it reaches the bot reviewer.
 
 ## Deterministic Questions Contract
 
@@ -64,11 +64,12 @@ task verify:plan-sequence -- --target-kind <entry-kind> --target <entry-id>
 
 > **Invariant:** every change MUST pass the full gate at least once before merge. Pre-PR is the merge chokepoint — NOT every iteration commit.
 
-- ! **Iteration lane (Phases 2–3 loop):** use affected/static gates on changed paths — `vitest run --coverage <paths>`, relevant `verify:*` on touched files, `task coverage:hotspots` — instead of full `task check` on every pre-PR iteration.
-- ! **Merge chokepoint (Phase 3 Lint exit + final confirm):** run full `task check` once before push/PR; Phase 3c targeted coverage precedes but does not replace the full gate.
+- ! **Iteration lane (Phases 2–3 loop):** use affected/static gates on changed paths — `vitest run --coverage <paths>`, relevant `verify:*` on touched files, `task coverage:hotspots` — instead of full `task check` on every pre-PR iteration. Phase 3 sits inside this loop, so it uses the iteration lane, not a full suite.
+- ! **Merge chokepoint (once after the loop, before push/PR):** run full `task check` once before push/PR. This is a #1704 revision of the prior Phase 3 Lint exit + final confirm (two runs, one inside every iteration). The escape-rate guard below still applies; do not invent a separate surface.
 - ! **Escape-rate safety (#1703 Tier-1):** before recommending fleet-wide fast-lane tightening, cite `#1703` Tier-1 telemetry (`helped/crud-metrics.jsonl`) and `task eval:health` — do NOT invent a separate escape-rate surface.
 - ~ **In-engine incrementality (#1713):** content-hash cache + runner-delegated affected selection are sibling work (#1713).
 - ⊗ Treat Phase 3c targeted coverage alone as PR-ready without full `task check` at the merge chokepoint.
+- ⊗ Run full `task check` inside every pre-PR Phase 3 iteration — Phase 3 is inside the loop; the chokepoint is once after exit.
 
 ## When to Use
 
@@ -90,6 +91,7 @@ Each iteration proceeds through all phases in order. Do NOT skip phases or reord
 - ~ If changed files include `xbrief/PROJECT-DEFINITION.xbrief.json`, a configured `codebase-map` provider artifact, or `.planning/codebase/MAP.md`, read the MAP and canonical metadata together. The MAP is orientation; `plan.architecture.codeStructure` and provider artifacts remain authoritative.
 - ! When adding a `!` or `⊗` rule that prohibits a specific command, pattern, or behavior, search the same file for any `~`, `≉`, or prose that recommends or permits the same command/pattern -- resolve all contradictions in the same commit before pushing
 - ! When strengthening a rule (e.g. upgrading `~` to `!`), grep for the term in the full file and verify no weaker-strength duplicate remains
+- ! When adding a weaker rule (`~`, `≉`, or prose that recommends or permits a command/pattern) beside an existing `!` or `⊗` for the same command/pattern in the same file, resolve the contradiction in the same commit — weaken-beside-a-MUST is the same-commit reconcile as adding or strengthening a MUST (#4135 / #4324)
 - ~ Note any inconsistencies, missing RFC2119 markers, stale cross-references, or incomplete sections
 - ~ Check that CHANGELOG.md entries match the actual changes made
 - ! If the change alters **user-visible behavior**, apply [coding/docs.md](../../coding/docs.md) (#447): update the matching user-facing surface (CHANGELOG when user/operator-visible, CLI help / commands.md for new or changed verbs/flags, README/getting-started for install/first-run, skill/strategy triggers when entry points change) in this PR
@@ -108,9 +110,9 @@ Each iteration proceeds through all phases in order. Do NOT skip phases or reord
 
 ### Phase 3 -- Lint
 
-! Run the merge-chokepoint gate and fix any failures (#1704).
+! Run the iteration-lane gates and fix any failures (#1704). Full `task check` is the post-loop merge chokepoint, not this per-iteration phase.
 
-- ! Run full `task check` (fmt + lint + typecheck + tests + coverage + verify:*) — the merge chokepoint, not every pre-PR iteration
+- ! Run affected/static gates on changed paths (`vitest run --coverage <paths>`, relevant `verify:*`, `task coverage:hotspots`) — not full `task check` inside the loop
 - ! Fix all failures before proceeding to Phase 3b
 - ~ If a lint fix requires changing a file, that counts as a change for the Loop phase
 
@@ -210,7 +212,10 @@ A red product verification may be resolved only by a product change or an indepe
 ! Exit when a complete Read-Write-Lint-Diff cycle produces **zero changes** -- no file edits in Write, no lint fixes in Lint, and no scope issues in Diff.
 
 After exiting:
-- ! Run `task check` one final time to confirm clean state
+- ! Run full `task check` once — the merge chokepoint. Phase 3 used the iteration lane, so this is the first full suite in the loop, not a second run.
+- ! If that post-loop `task check` is red and the fix changes files, restart from Phase 1 (Read). Do not only re-run the gate — those edits must pass Read and Diff (#4324).
+- ! After that restart exits with zero changes, run full `task check` once again (recovery after a red merge chokepoint).
+- ! Re-run the full gate only after a red merge chokepoint or a new commit.
 - ~ The branch is now ready for push and PR creation
 
 
@@ -233,6 +238,8 @@ Docs: `docs/decision-log.md`.
 - ⊗ Make out-of-scope fixes during Write -- this introduces scope creep that Diff will flag, forcing another iteration
 - ⊗ Ignore the iteration count -- more than 3 iterations usually indicates oscillating fixes or an unclear spec task
 - ⊗ Add a prohibition (`!` or `⊗`) without scanning the same file for conflicting softer-strength rules (`~`, `≉`) that reference the same term
+- ⊗ Add a weaker rule (`~` / `≉`) beside an existing `!` / `⊗` for the same command/pattern without reconciling in the same commit
+- ⊗ After a red post-loop `task check`, fix files and re-run only the gate without restarting Read-Write-Lint-Diff
 - ⊗ Skip `task pr:check-closing-keywords` (#737) before pushing a PR. Intent mode (#3015) also refuses bare/conditional real `Closes #N` without `--allow-close`. The negation-context substring match is the Layer 0 (prevention) gate that prevents the recurring auto-close of umbrella / staying-OPEN issues observed in #697 (closed #642), #401 (closed #642), #700 (closed #233), and #735 (closed #734) -- each incident required manual reopen and downstream cleanup. The lint's three-state exit (0 clean / 1 hits found / 2 config error) MUST be treated as a hard refusal: rewrite the PR body / commit messages until clean, OR pass `--allow-known-false-positives` ONLY for legitimately-quoted occurrences (test fixtures, documentation that discusses the trigger token literally). See `skills/deft-directive-swarm/SKILL.md` Phase 6 Step 1 for the corresponding Layer 3 (recovery) `pr:check-protected-issues` rule (#701)
 - ⊗ Invent remote PR/SHA/CI/review claims in handoff evidence without same-turn probe binding — invented-done (#3120)
 - ⊗ Fill remote ship/gate fields from memory when only local work completed; legal partial omits PR fields (#3120)

package/skills/deft-directive-release/SKILL.md

@@ -29,7 +29,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## Branch-Protection Policy Guard
 
-! Before any Phase 1 state mutation, run the skill-level branch-policy guard documented in `task policy:show` / `task verify:branch` (#746 / #747). Releases run on the configured base branch (default `master`), so the operator MUST be on the explicit-opt-in side of the policy before the pipeline starts writing files.
+! Before any Phase 1 state mutation, run the skill-level branch-policy guard documented in `task policy:show` / dual-invoke `deft verify:branch` (#746 / #747). Releases run on the configured base branch (default `master`), so the operator MUST be on the explicit-opt-in side of the policy before the pipeline starts writing files.
 
 **Preferred path — typed direct-commit policy opt-out (#1553).** For a release session on the default branch, prefer the audited typed flag over the emergency env-var bypass:
 
@@ -54,16 +54,16 @@ DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1 DEFT_ALLOW_DESTRUCTIVE_GH_VERBS=1 git push or
 **Branch-guard probe (either path).** Regardless of which opt-out path you chose, confirm the guard passes before Phase 1 mutates state:
 
 ```
-task verify:branch
+deft verify:branch
 ```
 
-or invoke `task verify:branch`. This is the canonical surface that surfaces the policy state to the operator before the pipeline starts writing files. The release pipeline's other safety surfaces (the dirty-tree guard, base-branch check, `task check` gate) remain independent of this check. (`task ci:local` is historical and removed.)
+or `task deft:verify:branch` when the consumer Taskfile include is present. Do not add a consumer `verify:branch` task. This is the canonical surface that surfaces the policy state to the operator before the pipeline starts writing files. The release pipeline's other safety surfaces (the dirty-tree guard, base-branch check, `task check` gate) remain independent of this check. (`task ci:local` is historical and removed.)
 
 **Emergency env-var bypass — narrow scope only (#1553).** `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1` is process-wide: every child process, nested test, and temporary repository spawned from the same shell inherits it. During the v0.43.0 release attempt, wrapping the entire `task release` invocation in this env var let the bypass leak into the Step 5 `task ci:local` preflight, which caused `TestWriteConsumerGitHooks_VendoredCommitBlocked_RealGit` to fail because the vendored test repo allowed a direct `master` commit the test expected the hook to block.
 
 - ! Prefer `task policy:allow-direct-commits -- --confirm` for release sessions instead of exporting `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1` for the whole shell.
 - ⊗ Wrap `task release` or `task check` in `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1` -- the env var is inherited by every subprocess and can produce false preflight failures before any release mutation. (`task ci:local` is historical; same leak class.)
-- ? If the env-var path is unavoidable, scope it to a **single** branch-guard probe only (e.g. `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1 task verify:branch`) and do NOT export it for the release session. The release pipeline itself passes the bypass only in scoped subprocess `env=` for its authorised commit/tag/push mutations (#867); operators MUST NOT mirror that pattern at the shell level.
+- ? If the env-var path is unavoidable, scope it to a **single** branch-guard probe only (e.g. `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1 deft verify:branch`) and do NOT export it for the release session. The release pipeline itself passes the bypass only in scoped subprocess `env=` for its authorised commit/tag/push mutations (#867); operators MUST NOT mirror that pattern at the shell level.
 
 The release pipeline's Step 9/10/11 git mutations carry the bypass in subprocess `env=` only (`the release pipeline subprocess env`, #867) so the parent shell stays clean. Operator-side env-var exports defeat that isolation.
 

package/skills/deft-directive-review-cycle/SKILL.md

@@ -49,6 +49,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 - A bot reviewer (Greptile) has posted findings on an open PR
 - Dispatching a cloud or background agent to monitor and resolve PR review findings until merge-ready
 - Operator re-authorizes after conf-hold / dual-stop residual: **pursue residual**, **follow-up hard-stop**, **same as conf-hold**, **continue dual-stopped PR**, or **re-babysit residual** — route to § Operator follow-up after dual-stop / hard stop (#3273) **one-shot** path
+- Reviewer findings on invariant-shaped code (concurrency, error handling, containment/security) -- classify against a written HEAD policy before patching (`review-response` / #3452)
 - Operator issues a **standing residual order**: **until floor or loop**, **until greptile meets policy**, or **pursue residuals until told otherwise** — route to the same § **standing** path (#3448); applies to open cohort / ordered-plan units, not only the last halted PR
 
 ## Cursor global babysit supersession (#2261)
@@ -203,6 +204,36 @@ Babysit and review-cycle are **not** a second unbounded implementation mandate.
 ⊗ Treat confidence-only holds as authorization to invent new subsystems in-tree.
 
 
+
+### Policy-anchored review-response (#3452)
+
+Working name `deft-directive-review-response`. This is **how to respond while continuing**. `#3448` / PR #3451 (shipped) remains **park-vs-continue**. `#3457` is how parks exit. `#3434` is where (d) escalations go. `#3462` / ADR-004 is a different issue -- do not implement it here.
+
+! Universal principles live in [coding/review.md](../../coding/review.md) `## Policy-anchored classification (#3452)`. This adapter adds HEAD-blob HOW and the rounds-tripwire composition.
+
+! **Policy-anchor precondition.** Invariant-shaped findings (concurrency, error handling, containment/security) MUST NOT be classified out-of-model until a written policy exists on the **current HEAD** of the file under review: assumptions / guarantees / non-goals as a header comment or design note.
+
+1. Absent on HEAD -> write the anchor first. That is the first work item. Do not classify out-of-model yet.
+2. Anchor-wrong -> revise the anchor, then classify.
+3. ! A review-response pass MUST refuse out-of-model classification until that HEAD anchor exists.
+
+! **Classify-then-act.** After the HEAD anchor exists:
+
+- In-model -> patch in the same review-round batch.
+- Out-of-model -> accepted-risk reply citing the HEAD anchor on the pushed SHA, not a worktree mid-edit.
+
+! **Head-blob check (slizard#2694).** Any deterministic arity/wiring claim MUST include `git show <head-sha>:<file>` before it can be confirmed. When the PR itself changes the named symbol, presume false and verify. Blanket dismissal is wrong -- check every time (dead export on #3440 was real). A one-line falsification reply citing slizard#2694 is enough when the head blob matches.
+
+! **Batch discipline.** One consolidated push per review round. Local review pass before that push. Never push per finding. Riders are allowed on mechanical rebases.
+
+! **Rounds tripwire.** When **more than 3 review rounds** touch the same file, compose with the `#3448` **Same-fingerprint stop** (do not invent a second detector): escalate to a design pass (`#3434` motion), not round K+1 and not parking. `#3448` still governs park-vs-continue; this tripwire governs the continue-side exit.
+
+⊗ Classify an invariant-shaped finding out-of-model with no written policy on current HEAD.
+⊗ Patch finding-by-finding or push per finding.
+⊗ Invent a second same-fingerprint detector alongside `#3448`.
+⊗ Run round K+1 or park when the rounds tripwire fires -- escalate to `#3434`.
+⊗ Implement `#3462` / ADR-004 as this issue.
+
 ### Dual stop — review fix loops (#2442)
 
 Review fix cycles are multi-iteration work and MUST carry dual stop (`main.md` `## Dual Stop Rule (#2442)`). Single-turn re-checks are exempt.
@@ -911,6 +942,10 @@ task lifecycle:event -- emit plan:approved \
 
 ## Anti-Patterns
 
+- ⊗ Classify an invariant-shaped finding out-of-model with no written policy on current HEAD (#3452)
+- ⊗ Invent a second same-fingerprint detector alongside #3448 (#3452)
+- ⊗ Run round K+1 or park when the rounds tripwire fires -- escalate to #3434 (#3452)
+- ⊗ Implement #3462 / ADR-004 as this issue (#3452)
 - ⊗ Multi-hour empty-commit / close-reopen thrash after CI weather thrash caps when `ci_never_scheduled` or `ci_cancelled_no_failover` (#3167)
 - ⊗ Workflow thrash or empty-commit spam during attributed platform outage without status-page probe (#3180)
 - ⊗ Tight forge-outage retry / empty-commit thrash without a one-shot human report (#3422)

package/skills/deft-directive-setup/SKILL.md

@@ -502,7 +502,7 @@ apply here too. Do not combine questions. See `skills/deft-directive-interview/S
 
   ! **Capability-cost disclosure (#746):** When the user picks option 2 (trunk-based), the agent MUST present the capability-cost disclosure verbatim BEFORE writing the typed flag, then re-prompt for explicit confirmation:
 
-  > "Capability-cost disclosure -- enabling direct commits to the default branch turns OFF the deft branch-protection policy. The pre-commit + pre-push hooks will no longer block default-branch commits, `task verify:branch` will pass on the default branch, and the skill-level guards in deft-directive-{swarm,review-cycle,pre-pr,release} will not halt for default-branch work. The change is reversible (`task policy:enforce-branches`) and is recorded to meta/policy-changes.log for auditability. The CI sanity check (head_ref != base_ref) remains independent and will continue to flag master->master PRs. Are you sure?"
+  > "Capability-cost disclosure -- enabling direct commits to the default branch turns OFF the deft branch-protection policy. The pre-commit + pre-push hooks will no longer block default-branch commits, `deft verify:branch` / `task deft:verify:branch` will pass on the default branch, and the skill-level guards in deft-directive-{swarm,review-cycle,pre-pr,release} will not halt for default-branch work. The change is reversible (`task policy:enforce-branches`) and is recorded to meta/policy-changes.log for auditability. The CI sanity check (head_ref != base_ref) remains independent and will continue to flag master->master PRs. Are you sure?"
   > 1. Yes, opt out -- persist `allowDirectCommitsToMaster=true` through the policy writer
   > 2. No, keep branch-protection enforced -- persist `allowDirectCommitsToMaster=false` through the policy writer
   > 3. Discuss
@@ -607,8 +607,7 @@ omit = [
       "Strategy": "Use {strategy name} for this project",
       "Quality": "Run task check before every commit. Achieve >= {coverage}% coverage overall + per-module. Store secrets in secrets/ dir.",
       "ProjectRules": "{Any rules the user specified, or 'No project-specific rules defined.'}",
-      "Branching": "{If confirmed trunk-based: 'Trunk-based workflow', otherwise 'Branch-based workflow (default)'}",
-      "DeftVersion": "0.20.0"
+      "Branching": "{If confirmed trunk-based: 'Trunk-based workflow', otherwise 'Branch-based workflow (default)'}"
     },
     "items": []
   }
@@ -620,7 +619,10 @@ omit = [
 
 ### Then
 
-- ! Emit a structured-tool question asking whether to continue to Phase 3 (specification) only when the host preserves numeric labels; otherwise emit the deterministic numbered menu in chat. Options: `1. Yes (continue)`, `2. Not now (exit setup)`, `3. Discuss`, `4. Back (revisit previous phase)`. The numeric labels MUST remain visible and be returned as numeric selections or exact displayed option text.
+- ! Emit a structured-tool question asking whether to continue to Phase 3 (specification) only when the host preserves numeric labels; otherwise emit the deterministic numbered menu in chat. Options: `1. Yes (continue)`, `2. Process-only (keep Phase 2 identity)`, `3. Discuss`, `4. Back (revisit previous phase)`. The numeric labels MUST remain visible and be returned as numeric selections or exact displayed option text.
+- ! Option 2 is the process-only adoption: leave setup with Phase 2 identity in place. Point at session ritual (`deft session:start` / `deft verify:session-ritual -- --tier=gated`) / `deft check` / later Add scope when a slice is ready. Do not write `xbrief/proposed/*.xbrief.json`. Do not overwrite PROJECT-DEFINITION narratives. GitHub issues stay cache/queue inputs. Docs stay described content. Skip Lifecycle Bridge, export prompt, Acceptance Gate, and build handoff.
+- ⊗ Bind docs or GitHub issues as the next-build plan.
+- ⊗ Use Back or Other as the process-only adoption path.
 - ⊗ Ask the phase-transition question as unnumbered conversational prose or through a structured UI that hides the canonical numeric labels -- it is a deterministic menu and MUST preserve visible numbers (#478, #1563).
 
 ### Follow-up: triage onboarding (#1143)
@@ -658,8 +660,9 @@ omit = [
 > 2. **Update project definition** — delta interview → Spec-Generating Guard → merge narratives into existing PROJECT-DEFINITION
 > 3. **Replace specification (scrap)** — only after explicit affirmative (`yes` / `confirmed`); then full new-spec path
 > 4. **Starting a new project specification** [default when greenfield] — proceed to the Strategy Gate below
-> 5. **Discuss** — explore these options before choosing
-> 6. **Back** — return to the previous setup question
+> 5. **Process-only (keep Phase 2 identity)** — same exit as Phase 2 option 2; no new scope; no spec write
+> 6. **Discuss** — explore these options before choosing
+> 7. **Back** — return to the previous setup question
 
 - ! Default based on repo state via the brownfield detector above (brownfield → Add scope; greenfield → Starting new)
 - ! Final two numbered options MUST be `Discuss` and `Back` per [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md)
@@ -667,6 +670,7 @@ omit = [
 - ! If **Update project definition**: run a delta interview; apply Spec-Generating Guard against `./xbrief/PROJECT-DEFINITION.xbrief.json` (or legacy `./vbrief/PROJECT-DEFINITION.vbrief.json` if that is the existing identity); merge narratives (do not wholesale replace unless the user confirmed scrap)
 - ! If **Replace specification (scrap)**: require explicit `yes`/`confirmed`, then proceed to the Strategy Gate as a greenfield-style full path
 - ! If **Starting new**: proceed to the Strategy Gate below
+- ! If **Process-only (keep Phase 2 identity)**: same exit as Phase 2 option 2. Do not write a scope xBRIEF. Do not merge or scrap PROJECT-DEFINITION narratives. Skip Lifecycle Bridge, End-of-Phase-3 Export Prompt, Acceptance Gate, and build handoff. Point at session ritual / `deft check` / later Add scope. GitHub issues stay cache/queue inputs. Docs stay described content.
 - ⊗ Treat brownfield repos as "Starting new" by default
 - ⊗ Accept vague confirmation (`proceed`, `ok`) for Replace/scrap
 - ⊗ Exit immediately after Add-scope write without the lifecycle bridge / export / handoff guidance
@@ -871,8 +875,9 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 
 ## Anti-Patterns
 
-- ! When deft-directive-setup generates or updates USER.md or PROJECT-DEFINITION.xbrief.json, the `deft_version` field MUST be set to the current framework version
-- ⊗ Generate a USER.md or PROJECT-DEFINITION.xbrief.json without including the `deft_version` field
+- ! When deft-directive-setup generates or updates USER.md, the `deft_version` field MUST be set to the current framework version. USER.md is the only artifact that carries this field.
+- ⊗ Generate a USER.md without including the `deft_version` field
+- ⊗ Write `deft_version` or `DeftVersion` into PROJECT-DEFINITION, specification, or plan xBRIEFs. Those stamps are retired (HASH4271). Specification `deft_version` has no framework seeding path; Pass 1 absence locks are the only control.
 - ⊗ Explore codebase before Phase 1 questions
 - ⊗ Read framework files before first question
 - ⊗ Batch multiple questions into one message — ask one at a time, interview style

package/skills/deft-directive-swarm/references/core-phase-0.md

@@ -46,7 +46,7 @@ Cross-links: Phase 3 Worker-owns-lifecycle (`references/core-phase-3.md`), revie
 ### Headless cohort fast-path: low-ceremony launch (C1 / #1387)
 
 ! `task swarm:launch` claims this worktree occupancy lease (`intent: swarm`) before emitting the manifest (#3433). A live foreign occupant fails closed.
-! **Spawned mutating workers take their own worktree (#4066 / #4215).** Phase 2/3 must put each implement/review/fix leaf on a uniquely reserved linked worktree (C3 worktree-map or `git worktree add`) *before* occupancy claim. Sharing the primary checkout with a live occupant is refuse, not grant-across-host. Grok `spawn_subagent` implement dest is `cwd` only. `isolation=worktree` / `worktree_path` stay on reroot hosts (Cursor Task, Claude subagent, Codex). Do not advertise `worktree_path` for Grok. Terminal release is dispatcher-owned (`phase: terminal` + incarnation); do not tell a refused Grok child to steal master.
+! **Spawned mutating workers take their own worktree (#4066 / #4215 / #4295).** Phase 2/3 must put each implement/review/fix leaf on a uniquely reserved linked worktree (C3 worktree-map or `git worktree add`) *before* occupancy claim. Sharing the primary checkout with a live occupant is refuse, not grant-across-host. Grok `spawn_subagent` implement dest is `cwd` only. Claude/Codex keep `isolation=worktree` / path keys. Cursor Task has no local dest field — local implement is dest-placing (nursery inherit on a dest-rooted window, or dest-rooted `@cursor/sdk` `Agent.create` cwd), not Task dest keys. Do not advertise `worktree_path` for Grok or Task dest keys for Cursor. Terminal release is dispatcher-owned (`phase: terminal` + incarnation); do not tell a refused Grok child to steal master.
 ! When the operator supplies a **pre-approved cohort** via the **C1** `task swarm:launch` CLI, Phase 0 runs in headless / low-ceremony mode: the per-phase interactive approval gates (the Step 0c promote-fill prompts, the Step 0.5 lifecycle-bridge approval, and the Step 4/5 allocation approval) collapse into a SINGLE consent -- the `## Allocation context` token (#1378) carried in the dispatch envelope. The interactive promote-fill loop (Step 0a -- 0d below) is SKIPPED.
 ! The **C1** signature is `task swarm:launch -- --stories <ids|paths> [--group <label>] [--worktree-map <path>] [--base-branch <branch>] [--autonomous]`. `--stories` names the pre-approved story ids or xBRIEF paths; `--group` is an optional cohort label; `--worktree-map` points at the pre-created **C3** worktree-map JSON consumed in Phase 2; `--base-branch` overrides the default `master`; `--autonomous` runs without the interactive launch confirmation.
 ! The SINGLE consent is the #1378 `## Allocation context` token with `dispatch_kind: swarm-cohort` and a NON-NULL `allocation_plan_id` AND `batching_rationale` (the recognition contract in `templates/agent-prompt-preamble.md` § 2.5). That token IS the batched approval for the whole cohort -- the deterministic-question gates the interactive path runs (per [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md)) are bypassed wholesale on the headless path, not asked once per phase.

package/skills/deft-directive-swarm/references/core-phase-3.md

@@ -33,7 +33,7 @@
 8. ! **Select launch path automatically** based on detection results — do NOT present static options:
    - **`start_agent` available** → Orchestrated launch (Step 2a) — preferred path, fully automated, no manual tab management
    - **`start_agent` unavailable, Warp detected** → Interactive Warp tabs (Step 2b) — full MCP, global rules, warm index; requires manual tab management
-   - **Cursor `Task` tool available (no `start_agent`, no `WARP_*`)** → Cursor sub-agent launch (Step 2e) via the `Task` tool with `run_in_background: true` (Tier 1 / Approach 1) — keeps the monitor pane interactive; descriptor is `cursor-composer` (interactive) or `cursor-cloud-agent` (cloud)
+   - **Cursor detected (no `start_agent`, no `WARP_*`)** → Cursor dest-placing launch (Step 2e / `host-cursor.md`) (Tier 1 / Approach 1). Local implement is nursery inherit on a dest-rooted window or dest-rooted `@cursor/sdk` `Agent.create({ local: { cwd } })` with reservation before exec — not Task dest keys. Descriptor is `cursor-composer` (interactive) or `cursor-cloud-agent` (cloud)
    - **Claude Code available (no `start_agent`, no `WARP_*`, no Cursor classification)** → Claude Code launch (Step 2g) via `Agent` with `run_in_background: true` (Tier 1 / Approach 1) — descriptor is `claude-code` (#3134)
    - **OpenClaw `sessions_spawn` available (no `start_agent`, no `WARP_*`, no Cursor, no Claude Code)** → OpenClaw launch (Step 2f) via `sessions_spawn` (Tier 1 / Approach 1) — descriptor is `openclaw`
    - **Grok Bot unique signals available (no earlier Tier-1 primitive)** → Grok Bot launch (Step 2h) via Task/executor/CloudAgent (Tier 1 / Approach 1) — descriptor is `grok-bot` (#4201)

package/skills/deft-directive-swarm/references/host-cursor.md

@@ -2,32 +2,54 @@
 
 Legend (RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
-Descriptor: `cursor-composer` or `cursor-cloud-agent` (Cursor `Task` tool).
+Descriptor: `cursor-composer` or `cursor-cloud-agent`. Detect still probes the Cursor `Task` tool. Local implement launch is dest-placing Cursor, not dest-binding Task (#4295).
 
 Load this file only after detect selects Cursor. Do not load other host adapters.
 
-! **Windows + Cursor Task-tool console windows (#2563):** Local Cursor Task swarms on Windows are first-class. Shipped mitigations (do not regress): `windowsHide: true` (CREATE_NO_WINDOW) on engine/spawn paths, and warm-dist skip via `tasks/ts-build-fresh.cjs` so `engine:_ts-build` does not cold-rebuild when `packages/cli/dist` is current. See `templates/agent-prompt-preamble.md` §3.8. ! Default to **local** Task workers on Windows (not cloud-for-Windows). Parallel cohorts are allowed — do not force concurrency=1 for #2563. ⊗ Drop or weaken those mitigations without a replacement that keeps Windows local swarm workable.
+! **Windows + Cursor Task-tool console windows (#2563):** Local dest-placing Cursor swarms on Windows are first-class. Shipped mitigations (do not regress): `windowsHide: true` (CREATE_NO_WINDOW) on engine/spawn paths, and warm-dist skip via `tasks/ts-build-fresh.cjs` so `engine:_ts-build` does not cold-rebuild when `packages/cli/dist` is current. See `templates/agent-prompt-preamble.md` §3.8. ! Default to **local dest-placing Cursor** on Windows (not cloud-for-Windows; not dest-binding Task). Parallel cohorts are allowed — do not force concurrency=1 for #2563. ⊗ Drop or weaken those mitigations without a replacement that keeps Windows local swarm workable.
 
-### Step 2e: Cursor Launch (Task tool available) — #1877
+### Step 2e: Cursor Launch — dest-placing, not Task dest (#4295 / #1877)
 
-! When the platform descriptor is `cursor-composer` or `cursor-cloud-agent` (Cursor `Task` tool detected with Cursor signals, no `start_agent`, no `WARP_*`, no Claude Code classification, no OpenClaw `sessions_spawn`, no `spawn_subagent`), dispatch each worker via the Cursor `Task` tool with:
-0. Create `<worktree>/.deft-scratch/subagent-status/` before spawn if `swarm:launch` / `swarm:pre-dispatch` did not already (#3730). Include preamble § 10.5 (heartbeat + commit early) and poll with `task verify:subagent-alive -- --require-agent <agent-id>`.
-1. The canonical `templates/agent-prompt-preamble.md` content as the preamble (AGENTS.md read mandate, #810 xBRIEF gate, #798 PowerShell UTF-8, pre-PR + review-cycle mandates).
-2. The standard worktree prompt (STEP 1-6 from the Prompt Template below).
-3. The worktree path set to the agent's isolated git worktree.
-4. ! **`run_in_background: true`** for any worker or poller whose loop runs longer than a short task (~3 min) — implementation, fix, and review-cycle workers — so the monitor conversation pane stays interactive (#1880 Gap D). The parent is notified on completion.
-5. ! **Deliberate model routing (#1739):** pass the route's `resolved_model` (when non-null) as the Task tool's `model` argument — stamping the C2 manifest is prep; the recorded model MUST reach the actual spawn call.
+Cursor `Task` has no local dest field. Extra keys (`isolation`, `worktree_path`, `cwd`) are stripped before `preToolUse`. Hook `updated_input` dest fields do not re-root Task. A prompt token may select a trusted reservation record; it does not move the child. Comment 5611146439 stands.
 
-~ This is the first-class Cursor path. It is **Tier 1 → Approach 1** (a backgroundable sub-agent primitive), equivalent in tier to `start_agent` / `spawn_subagent` / OpenClaw `sessions_spawn`; it MUST NOT be downgraded to a `generic-terminal` blocking poll. Cursor pollers whose loop runs > ~3 min MUST honour the sub-agent heartbeat contract (`docs/subagent-heartbeat.md`, #1166), same as the `spawn_subagent` path.
+⊗ Dispatch local implement via Cursor `Task` dest keys, a worktree map in the prompt, or inherited primary cwd.
+⊗ Treat a prompt token as moving the child onto a worktree.
 
+! **Local implement (required):** dest-placing Cursor. The child process or window folder is an already-created linked worktree *before* it can write.
+
+Two local hatches, in this order:
+
+1. **Nursery inherit (interactive dest-rooted window).** Open Composer on the reserved linked worktree (not primary). One Task child may inherit that payload root: consult treats the window as dest, mints a unique reservation, and admits the child through `occupancy:grant`. While that grant is live, parent product writes in that tree are denied. A second Task in the same window is reservation-conflict. Nested Task from a dest-rooted session is still dest-missing unless *this* window is the dest. Nursery child `workspace_roots` equal the parent window.
+2. **Headless dest-rooted SDK.** `@cursor/sdk` `Agent.create({ local: { cwd: <reserved-worktree> } })` with `Agent.resume` / `agent.send` as the retain-capable sibling. Reservation before exec. Process-handle liveness (not parent-cwd `verify:subagent-alive`). Doctor check `cursor-sdk-auth` for the separate SDK login (`CURSOR_API_KEY`). The leaf implements in that session and does not nested-Task.
+
+Cursor Task dest-missing deny copy is CURSOR_TASK_SPAWN_CLASS_RECOVERY in packages/core/src/hooks/dispatcher.ts. It names these hatches as payload-root and does not advertise Task dest keys (#4362).
+
+! Create `<worktree>/.deft-scratch/subagent-status/` before spawn if `swarm:launch` / `swarm:pre-dispatch` did not already (#3730). Include preamble § 10.5 (heartbeat + commit early). Headless SDK liveness is the process handle; scratch heartbeats remain for dest-rooted Composer sessions.
+! Include the canonical `templates/agent-prompt-preamble.md` content as the preamble.
+! Include the standard worktree prompt (STEP 1-6 from the Prompt Template).
+! **`run_in_background: true`** (or SDK async create) for any worker or poller whose loop runs longer than a short task (~3 min).
+! **Deliberate model routing (#1739):** pass the route `resolved_model` (when non-null) into the actual spawn primitive.
+
+~ Cursor stays **Tier 1 → Approach 1**. Do not downgrade to `generic-terminal`. Spawn available means dest-placing dispatch exists, not Task-present (#3032 / #4295).
+? Cloud `Task` (`environment: "cloud"`) is the #4294 dest-consult carve-out. Complementary. Do not treat cloud as local dest-proof. Do not duplicate that hook slice here.
+
+### Fence-in-place (parked)
+
+Fence-in-place (bind a parent-cwd Task and rewrite writes into `.deft-scratch/worktrees/`) stays parked until measured:
+
+- Shell `updated_input.cwd`
+- Write/ApplyPatch path rewrite
+- Composer visibility of gitignored `.deft-scratch/worktrees/`
+
+The write gate does not cover Shell or MCP. Relative targets resolve against hook cwd. Bind is specifiable later (`EXACT_LIFECYCLE_VERBS` + identity rewrite; adding `spawn:bind`). ⊗ Sequence `best-of-n-runner` ahead of nursery. ⊗ Primary-window writes through `.deft-scratch/worktrees/`.
 
 ## Nested Task boundary
 
-! Cursor ownership split (#2797 / #2893) lives in `references/core-phase-3.md` Orchestrator dispatch doctrine — a Cursor `Task` implementation leaf MUST NOT nested-spawn a review-monitor Task.
+! Cursor ownership split (#2797 / #2893) lives in `references/core-phase-3.md` Orchestrator dispatch doctrine — a Cursor implement leaf MUST NOT nested-spawn a review-monitor Task. Dest-rooted SDK / nursery leaves implement in-session.
 
 ## Retained / continue-by-id (#3158)
 
 ! **Default one-shot after Task completion:** Cursor `Task` leaves that exit their tool loop are typically terminal — prefer **split-dispatch** for mid-scope user-approval gates (#954) unless the host surfaces an explicit continue/resume-by-agent-id for that Task.
-? When the host documents resume of the same Task / agent id with context intact, treat as **retain-capable** for message-later / steer-mid-flight and re-message instead of a full second Task spawn.
-! Liveness failures (`task verify:subagent-alive` exit `1` / `REDISPATCH_OK`) still authorize replacement re-dispatch — retain does not override the false-alive contract (#2824).
+? `@cursor/sdk` `Agent.resume` / `agent.send` is retain-capable for the headless dest-rooted path.
+! Liveness failures (`task verify:subagent-alive` exit `1` / `REDISPATCH_OK`) still authorize replacement re-dispatch for Composer heartbeats — retain does not override the false-alive contract (#2824). Headless SDK replacement keys on the process handle.
 ~ Stance: orchestration only (#3164).