@deftai/directive-content 0.116.0 → 0.117.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\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"
+      "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 — except the identity-only Starting-new\nskip below (#4390).\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,\nexcept the identity-only Starting-new / Proceed invocation named below.\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 (same rule as setup Phase 3; #4390 recut of the #2925 identity-OR-scopes probe):\n\n- **Identity-only** when BOTH:\n  - live PROJECT-DEFINITION `plan.items` is empty (`[]` or absent), AND\n  - no convention-valid `*.xbrief.json` / `*.vbrief.json` in lifecycle folders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `./xbrief/` or legacy `./vbrief/`). Exclude `.gitkeep` and `*.premigrate.*`. PROJECT-DEFINITION itself is identity, not a scope record.\n- **Scoped (brownfield)** when `plan.items` is non-empty OR at least one convention-valid scope file exists\n- **Greenfield** otherwise (no PROJECT-DEFINITION and no convention-valid scope file)\n\n! The detector MUST run on every Chaining Gate presentation.\n! Identity-only and greenfield share the Proceed / Starting-new default. Scoped/brownfield defaults to Add-scope.\n⊗ Treat PROJECT-DEFINITION existence alone as brownfield.\n⊗ Use session-age (\"this setup turn just wrote identity\") as the probe.\n⊗ Invent a \"finished Phase 3\" marker.\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### Starting-new / Proceed skip (#4390)\n\n! Starting-new (setup Phase 3) and Proceed (this gate) MUST ask what to build before writing a scope.\n\n? When setup Phase 3 already selected **Starting a new project specification** on identity-only, this Chaining Gate MAY be skipped for that invocation and the agent may continue to the Sizing Gate. Written reason: identity-only default is already Proceed; the prior identity-OR-scopes detector re-defaulted to Add-scope one step later and skipped the product interview.\n\n⊗ Skip this gate on scoped/brownfield repos.\n⊗ Skip this gate when the operator chose Add-scope, Update, or Replace.\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 or identity-only):**\n1. **Proceed to specification** (default) — ask what to build; continue to the [Sizing Gate](#sizing-gate) for a full create path\n\n**Identity-only also keeps Add-scope / Update / Replace / Process-only on the menu** (same vocabulary as setup Phase 3). They are not the default.\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 only after capturing an explicit product or slice description; gather only the new scope; emit **one** proposed scope record; apply the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) on write\n   - ! On identity-only Add-scope: capture a product or slice description, or do not emit a proposed xBRIEF. ⊗ Synthesize the first scope from Overview / directory name / init seed. Swarm's `xbrief/proposed/` scan is in scope for that skip.\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**Identity-only** (PROJECT-DEFINITION exists; empty `plan.items`; no convention-valid scopes) — same options as setup Phase 3; Proceed is the default:\n\n```\nThis repo has project identity but no scopes yet. Before we proceed:\n\n1. Proceed to specification (default) — ask what to build; full create path\n2. Add scope to this project — keep identity; requires an explicit product or slice description\n3. Update project definition — delta interview; merge narratives (Spec-Generating Guard)\n4. Replace specification (scrap) — requires explicit yes/confirmed; full recreate\n5. Process-only (keep Phase 2 identity) — leave strategy; no new scope; no spec write\n\n--- Preparatory (loops back) ---\n6. Run a research phase — investigate the domain, find libraries, identify pitfalls\n7. Run a discuss phase — lock key decisions using Feynman technique\n8. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks\n9. Run a map phase — analyze existing codebase conventions\n\n--- Switch strategy ---\n10. Switch to yolo — auto-pilot picks all answers\n11. Switch to speckit — formal spec process with story readiness before implementation\n12. Other (specify)\n13. Discuss\n14. Back\n```\n\n**Brownfield** (scoped):\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/skills/deft-directive-build/SKILL.md

@@ -51,7 +51,7 @@ Multi-scope greenfield (app-bank pins, N story scopes) multiplies agent turns wh
 
 ### Quality check once at end of multi-scope batch (#3012)
 
-! On an approved multi-scope batch (operator-approved multi-story branch, swarm cohort, or pin walk): run full `task check` (merge chokepoint) **once at the end of the batch** (or after the last scope), not after every scope.
+! On an approved multi-scope batch (operator-approved multi-story branch, swarm cohort, or pin walk): run the merge chokepoint **once at the end of the batch** (or after the last scope), not after every scope — prefer `deft check`; if the CLI is missing, use the tree-correct task form (`task deft:check` on include-only consumers; `task check` in framework source). Do not run both.
 ! Exception: if the last full check **failed**, fix loops MAY re-run check until green.
 ! Pre-PR / merge-ready gates remain end-of-unit — this does not weaken them.
 ! Iteration lane (affected tests / `verify:forward-coverage` / `coverage:hotspots`) still applies **per scope** during implementation (#1704).
@@ -259,7 +259,7 @@ All xBRIEFs (including those read from `xbrief/active/` and any new xBRIEFs this
 > **Invariant:** every change MUST pass the full gate at least once before merge. Iteration MAY use a cheaper proxy; the merge chokepoint MUST NOT be skipped.
 
 - ! **Iteration lane (agents + humans):** during implementation commits, use affected/static gates — targeted tests on changed paths (`vitest run --coverage <paths>` or project equivalent), static `verify:*` gates relevant to touched files, and `task coverage:hotspots` / `task verify:forward-coverage` — NOT full `task check` on every commit.
-- ! **Merge chokepoint:** run full `task check` (or `task check:merge` in the framework source repo) once before push/PR and again when CI merge gate runs. Pre-PR skill exit and review-cycle fix batches still require a green full gate.
+- ! **Merge chokepoint:** prefer `deft check` once before push/PR (and again when CI merge gate runs). If the CLI is missing, use the tree-correct task form (`task deft:check` on include-only consumers; `task check` / `task check:merge` in framework source). These are one gate, not two sequential runs. Do not add a fourth probe (#2893 / #4379). A bare `task check` miss on an include-only consumer is not "gate unavailable". Pre-PR skill exit and review-cycle fix batches still require a green full gate.
 - ! **Escape-rate safety (#1703 Tier-1):** before tightening fast-lane defaults fleet-wide, consult `#1703` measurement — `task eval:health` (Tier 0) and Tier-1 session telemetry (`helped/crud-metrics.jsonl` via instrumented CRUD / workflow metrics). Do NOT invent a separate fast-lane escape-rate surface (#1704 LockedDecisions).
 - ~ **In-engine incrementality (#1713):** content-hash task cache and runner-delegated affected selection are sibling work — not required for this policy face.
 - ⊗ Run full `task check` on every iteration commit when a cheaper proxy suffices — reserve the full gate for PR/merge (#1704).
@@ -277,9 +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 | `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) |
+| Full `deft check` re-run | tree-correct full gate 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.
+- ! Re-run the full gate (prefer `deft check`; else the tree-correct task form) only after a red merge chokepoint or a new commit. Do not run both.
 
 **On failure stop:**
 
@@ -348,7 +348,8 @@ task verify:forward-coverage            # new-source coverage (#1310)
 Before PR / phase handoff (merge chokepoint):
 
 ```bash
-task check          # Full gate — format, lint, typecheck, tests, coverage, verify:*
+deft check          # preferred full gate (getting-started / #2893)
+# else tree-correct: task deft:check on include-only consumers; task check in framework source
 task test:coverage  # >=85% or PROJECT-DEFINITION.xbrief.json override
 ```
 
@@ -423,7 +424,7 @@ Read full files when you need detail:
 - ~ Naming: hyphens for filenames unless language idiom dictates otherwise
 - ! Contracts first: define interfaces/types before implementation
 - ! Secrets: in `secrets/` dir with `.example` templates; ⊗ secrets in code
-- ! Commits: Conventional Commits format; ! use iteration fast lane before checkpoint commits; ! run full `task check` at PR/merge chokepoint only (#1704)
+- ! Commits: Conventional Commits format; ! use iteration fast lane before checkpoint commits; ! run full `deft check` (else tree-correct `task deft:check` / `task check`) at PR/merge chokepoint only (#1704 / #4379)
 
 See `deft/coding/coding.md` and `deft/coding/testing.md` for full rules.
 
@@ -445,7 +446,7 @@ See `deft/coding/coding.md` and `deft/coding/testing.md` for full rules.
 
 - ! Default to one story per branch/PR. Batching multiple stories in one branch requires explicit operator approval and a short rationale.
 - ! Create a checkpoint commit after each completed story before beginning another story.
-- ! Use iteration fast lane before checkpoint commits; run full `task check` at PR/merge chokepoint (#1704)
+- ! Use iteration fast lane before checkpoint commits; run full `deft check` (else tree-correct `task deft:check` / `task check`) at PR/merge chokepoint (#1704 / #4379)
 - ⊗ Claim checks passed without running them
 
 ```

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

@@ -64,9 +64,9 @@ After same-round siblings are posted, the parent posts the successor lean; the o
 ⊗ Auto-dispatch critics from this skill.
 ⊗ Copy the variant table, synthesis rules, or other contract bodies into this skill.
 
-Seat families and Grok Build launcher: Envelope and ceiling.
+Seat families and Grok Build launcher: Envelope and ceiling. Grok critic recovery: Design-critique dispatch (dest-rooted grok --cwd --prompt-file after recorded native deny). Native admit without skip-class is not a critic.
 Dispatch-composition miss: offer or file a prevention issue.
 
 ## EXIT
 
-deft-directive-design-critique complete -- exiting skill. After Recut bind: Next: run `task issue:ingest`. Else: operator fills the brief template and dispatches the next envelope. Direct EXIT: ingest is a separate operator verb.
+deft-directive-design-critique complete -- exiting skill. After an admitted completed-arc record: Next: run `task issue:ingest`. Mid-arc EXIT: operator fills the brief template and dispatches the next envelope. Direct EXIT: ingest is a separate operator verb.

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

@@ -2,7 +2,7 @@
 name: deft-directive-pre-pr
 description: >-
   Iterative pre-PR quality improvement loop. Use before pushing a branch for
-  PR creation -- after completing implementation but before task check. Cycles
+  PR creation -- after completing implementation but before deft check. Cycles
   through Read-Write-Lint-Diff until a full pass produces zero changes.
 ---
 <!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
@@ -65,7 +65,7 @@ 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. 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.
+- ! **Merge chokepoint (once after the loop, before push/PR):** prefer `deft check` once before push/PR. If the CLI is missing, use the tree-correct task form (`task deft:check` on include-only consumers; `task check` in framework source). These are one gate, not two sequential runs. Do not add a fourth probe (#2893 / #4379). A bare `task check` miss on an include-only consumer is not "gate unavailable". 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.
@@ -74,7 +74,7 @@ task verify:plan-sequence -- --target-kind <entry-kind> --target <entry-id>
 ## When to Use
 
 - ! Before pushing a branch for PR creation
-- ! After completing implementation but before the final merge-chokepoint `task check` (#1704)
+- ! After completing implementation but before the final merge-chokepoint `deft check` (#1704 / #4379)
 - ~ After addressing bot reviewer findings (run one pre-PR pass before pushing the fix batch)
 - ? During mid-implementation checkpoints on large changes
 
@@ -212,9 +212,9 @@ 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 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).
+- ! Run the merge chokepoint once: prefer `deft check`; if the CLI is missing, use the tree-correct task form (`task deft:check` on include-only consumers; `task check` in framework source). These are one gate, not two sequential runs. Do not add a fourth probe (#2893 / #4379). Phase 3 used the iteration lane, so this is the first full suite in the loop, not a second run.
+- ! If that post-loop full gate 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 the same tree-correct full gate 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
 

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

@@ -27,6 +27,20 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ! GitHub as the SCM platform; the **GitHub CLI (`gh`)** must be installed and authenticated. The full pipeline plus the rehearsal target (`task release:e2e`) all dispatch through `gh`.
 
+## Primary occupancy — trusted producer (#4266)
+
+! Mutation `session:start` on a contended primary MUST pass `--primary-claim-exception=release-cut` **before any state-changing preflight command** (`task policy:allow-direct-commits -- --confirm`, reconcile, cache refresh). Occupancy already implements that exception; session:start CLI argv is the trusted producer.
+
+```
+deft session:start --primary-claim-exception=release-cut
+```
+
+or `task session:start -- --primary-claim-exception=release-cut`. Sibling values: `policy-restore`, `operator-default-branch`. Unknown values fail closed (exit 2). `--read-only` never claims.
+
+⊗ Invent a process-wide env producer for the exception.
+⊗ Name the exception in spawn JSON.
+⊗ Run `task policy:allow-direct-commits` (or any other mutation) before mutation `session:start --primary-claim-exception=release-cut` on a contended primary.
+
 ## Branch-Protection Policy Guard
 
 ! 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.
@@ -81,7 +95,6 @@ The release pipeline's Step 9/10/11 git mutations carry the bypass in subprocess
 
 ! Validate the local + remote state before any irreversible action.
 
-
 ### Parallel prep — #1880 Gap D (#2692)
 
 ! Phase 1 long steps (`task reconcile:issues -- --apply-lifecycle-fixes`, cache refresh when ritual-stale) and Phase 3 `task release:e2e` MUST be backgrounded or subagent-dispatched when the host supports it (Cursor: Task tool `run_in_background: true`), with progress surfaced via DONE/heartbeat — same ownership as review-cycle / merge-ready workers (#1880 Gap D). The operator conversation MUST stay interactive for version magnitude confirmation, `--summary`, and the Phase 2 dry-run `yes`/`back`/`quit` gate while prep runs. (`task ci:local` is historical and removed.)
@@ -92,6 +105,13 @@ The release pipeline's Step 9/10/11 git mutations carry the bypass in subprocess
 
 ⊗ Foreground-block the operator chat on reconcile / `release:e2e` when background dispatch is available (#1880 Gap D / #2692).
 
+### Orientation-dirty / check-class stale-by-drift (#4399)
+
+! Treat `[deft orientation] cache_fresh: dirty` or check-class `verify:cache-fresh` stale-by-drift as a hard Phase 1 preflight, distinct from ritual-stale (gated ritual age / compact stale). The parallel-prep ritual-stale cache refresh does not cover this class. Run `deft cache fetch-all --source github-issue --repo <owner>/<repo>` before `task release`. Skip-drift gated-verify green is not cache-ready.
+
+⊗ Proceed to `task release` when session:start printed `cache_fresh: dirty` or check-class `verify:cache-fresh` (no `--skip-drift-probe`) reports stale-by-drift.
+
+
 ### Fixable check failure — file-and-merge before resume (#2859)
 
 ! When **pipeline Step 5** fails on a **fixable product or test defect** (hang, failing test, validation bug — not operator env misconfiguration), the release cut MUST pause and route the blocker through normal issue → xBRIEF → feature branch → PR → merge before resuming Phase 1.
@@ -183,6 +203,10 @@ See [`docs/RELEASING.md`](../../../docs/RELEASING.md) § Routine vs hard cut for
 8. ! **Disclose npm irrevocability before any tag push (#1972, #2002, #3527).** A `v<version>` tag push is the **real npm publish gate** -- NOT Phase 5 or `task release:publish`. Tag push fires `.github/workflows/npm-publish.yml` in a separate workflow that is NOT draft-gated; npm packages ship immediately and **cannot be retracted** (`npm unpublish` is forbidden). Recovery is forward-only: deprecate, dist-tag, or ship a patch. The last human gates before npm goes live are: (a) Phase 2 dry-run `yes`, (b) a human-origin closed-verb grant (`deft authz:grant -- --template release-publish --target <version> --confirm` or `DEFT_ALLOW_RELEASE_PUBLISH=1`). `task release` fails closed at the Step 10–11 tag-push boundary without that grant. Phase 5 only controls GitHub release visibility (draft → public); it does NOT gate npm. The draft-flip `release:publish` closed-verb check remains (#1095).
 9. ~ Ask the operator for an optional one-line release **summary** (recommended 80-160 chars; can be skipped). The summary is the canonical narrative for THIS release across three audiences: (a) injected as a Markdown blockquote at the top of the promoted `CHANGELOG.md [<version>]` section, (b) auto-flowed into the GitHub release body via the existing `_section_for_version` pickup, and (c) populated VERBATIM into the Phase 8 Slack `*Summary*:` slot. Capture the wording once here; do NOT regenerate per-audience downstream
 
+10. ! **Treat orientation-dirty `cache_fresh` or check-class stale-by-drift as a hard preflight (#4399).** Distinct from ritual-stale. If `session:start` printed `[deft orientation] cache_fresh: dirty`, or `deft verify:cache-fresh` (no `--skip-drift-probe`) reports stale-by-drift, run `deft cache fetch-all --source github-issue --repo <owner>/<repo>` before invoking `task release`. Do not treat skip-drift `verify:session-ritual` green as cache-ready.
+
+
+
 ⊗ Skip the version-bump magnitude check -- a patch release that ships breaking changes is the kind of regression that Repair Authority [AXIOM] (#709) is designed to prevent.
 
 ⊗ Skip the xBRIEF-lifecycle-sync check (#734); the gate exists because operators consistently forget the manual `task scope:complete` move step. The v0.21.0 cut surfaced 13 stranded xBRIEFs (8 cycle-relevant + 5 historical residue) post-publish as the recurrence record this gate prevents. If `task release` reports `[3/13] Pre-flight xBRIEF lifecycle sync... FAIL (<count> mismatches; run task reconcile:issues -- --apply-lifecycle-fixes to fix)`, the canonical recovery is the apply-mode invocation -- `--allow-vbrief-drift` is reserved for cases where the operator has explicitly reviewed the drift and chosen to defer the lifecycle reconcile to the next refinement pass (e.g. an emergency hot-fix release).
@@ -376,6 +400,8 @@ Where `<one-line guidance>` is one of:
 ## Anti-Patterns
 
 - ⊗ Foreground-block the operator chat on Phase 1 long prep (`reconcile:issues`, cache refresh) or Phase 3 `release:e2e` when background / subagent dispatch is available (#1880 Gap D / #2692) — the interactive channel must stay free for version confirmation, `--summary`, and the Phase 2 dry-run gate
+- ⊗ Proceed to `task release` on orientation-dirty `cache_fresh` or check-class stale-by-drift, or treat skip-drift ritual green / ritual-stale as that bar (#4399) — fetch-all first
+
 - ⊗ Wrap long release-prep task output in PowerShell `Select-Object -Last` — it buffers until exit and makes the session look hung (#2692)
 - ⊗ Run `task release` without a Phase 2 dry-run preview -- the dry-run is the only safe place to catch a bad version, malformed CHANGELOG, or wrong base branch
 - ⊗ Skip Phase 3 (e2e rehearsal) on the assumption that "the dry-run is enough" -- the e2e harness catches gh-CLI auth issues, repo permission gaps, and pipeline-shape regressions that the dry-run cannot detect
@@ -394,6 +420,7 @@ Where `<one-line guidance>` is one of:
 - ⊗ Hardcode `master` as the base branch -- delegate to the configured base branch from `task release --base-branch <branch>`
 - ⊗ Skip the post-create verify-isDraft gate (#724) -- a successful `gh release create` exit code does NOT prove the release actually landed in draft state; the 5-second poll-and-flip gate in `task release` Step 11 is the only safety net against operator-error variants and partial-success races, and any manual recovery path that bypasses `task release` MUST run `gh release view --json isDraft` followed by `gh release edit --draft=true` on `isDraft=false` before handing off to Phase 5
 - ⊗ Manually rewrite the Phase 8 Slack `*Summary*:` line to deviate from the CHANGELOG `[<version>]` blockquote -- the canonical narrative is authored ONCE at Phase 1 via `--summary` and propagates verbatim across all three audiences (CHANGELOG / GitHub release body / Slack). Per-audience hand-edits create documentation drift that the deterministic `--summary` flow is designed to prevent. If the operator wants Slack-specific tone, fold it into the canonical Phase 1 wording before passing `--summary`, OR amend the CHANGELOG blockquote BEFORE Phase 8 so all three surfaces stay aligned
+- ⊗ Cut a release mutation `session:start` on the contended primary without `--primary-claim-exception=release-cut` (#4266) — occupancy already implements the exception; the CLI argv is the trusted producer. ⊗ Invent a process-wide env producer.
 - ⊗ Export `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1` or `DEFT_ALLOW_DESTRUCTIVE_GH_VERBS=1` for the entire release session or wrap `task release` / `task check` in them (#1553) -- the env vars are process-wide and leak into nested tests and temporary repos, producing false preflight failures. Prefer `task policy:allow-direct-commits -- --confirm` and restore with `task policy:enforce-branches` after the cut (closeout commit+push may use a **scoped** prefix of both `DEFT_ALLOW_DEFAULT_BRANCH_COMMIT=1` and `DEFT_ALLOW_DESTRUCTIVE_GH_VERBS=1` on those three git commands only — see Branch-Protection Policy Guard, #2623)
 - ⊗ `task authz:grant` — not a Taskfile target. Name `deft authz:grant -- --template release-publish --target <version> --confirm`.
 - ⊗ Wait for a live grant before Phase 3, or ask the operator to mint rehearsal `0.0.1` — mint the confirmed cut version immediately before Phase 4.

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

@@ -653,27 +653,37 @@ omit = [
 
 ! Before proceeding with the strategy gate, ask the onboarding question. Use the same add-scope / update / replace vocabulary as the Chaining Gate in [strategies/interview.md](../../strategies/interview.md#chaining-gate).
 
-**Brownfield detector** (same as Chaining Gate): `PROJECT-DEFINITION` exists (`./xbrief/` or legacy `./vbrief/`) **OR** any lifecycle folder (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`) has scope records.
+**Brownfield detector** (same as Chaining Gate; #4390 recut of the #2925 identity-OR-scopes probe):
+
+- **Identity-only** when BOTH: live PROJECT-DEFINITION `plan.items` is empty (`[]` or absent), AND no convention-valid `*.xbrief.json` / `*.vbrief.json` in lifecycle folders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `./xbrief/` or legacy `./vbrief/`). Exclude `.gitkeep` and `*.premigrate.*`. PROJECT-DEFINITION itself is identity, not a scope record.
+- **Scoped (brownfield)** when `plan.items` is non-empty OR at least one convention-valid scope file exists.
+- **Greenfield** when there is no PROJECT-DEFINITION and no convention-valid scope file.
+
+! One rule on both surfaces — this detector and the Chaining Gate share identity-only. ⊗ Treat PROJECT-DEFINITION existence alone as brownfield. ⊗ Use session-age ("this setup turn just wrote identity") as the probe. ⊗ Invent a "finished Phase 3" marker.
 
 > "How should we treat this project's specification?"
-> 1. **Add scope to this project** [default when brownfield] — load existing identity; skip greenfield "what are we building?"; emit one proposed scope; Preparatory Guard on write
+> 1. **Add scope to this project** [default when brownfield] — load existing identity; skip greenfield "what are we building?" only after an explicit product or slice description; emit one proposed scope; Preparatory Guard on write
 > 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
+> 4. **Starting a new project specification** [default when identity-only or greenfield] — proceed to the Strategy Gate below and ask what to build
 > 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)
+- ! Default based on repo state via the brownfield detector above (scoped/brownfield → Add scope; identity-only or greenfield → Starting new)
 - ! Final two numbered options MUST be `Discuss` and `Back` per [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md)
-- ! If **Add scope**: skip the full interview, create a new scope xBRIEF in `./xbrief/proposed/` with the user's description, apply Preparatory Guard on write, then surface the Lifecycle Bridge + End-of-Phase-3 Export Prompt + handoff sections below (do not dead-end after the write)
+- ! If **Add scope**: skip the full interview only after capturing an explicit product or slice description from the operator. Create a new scope xBRIEF in `./xbrief/proposed/` with that description, apply Preparatory Guard on write, then surface the Lifecycle Bridge + End-of-Phase-3 Export Prompt + handoff sections below (do not dead-end after the write)
+- ! If **Add scope** on identity-only: ⊗ synthesize the first scope from `narratives.Overview`, directory name, or init-seed identity. Capture a product or slice description, or do not emit a proposed xBRIEF. Swarm Phase 0 Step 0.5 `xbrief/proposed/` scan is in scope for that skip.
 - ! 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 **Starting new**: proceed to the Strategy Gate below. Ask what to build before writing a scope. On identity-only, this invocation MAY skip the interview Chaining Gate (see [strategies/interview.md](../../strategies/interview.md#chaining-gate) Starting-new skip) because the identity-only default is already Proceed.
 - ! 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
+- ⊗ Default identity-only to Add-scope because PROJECT-DEFINITION exists
 - ⊗ Accept vague confirmation (`proceed`, `ok`) for Replace/scrap
 - ⊗ Exit immediately after Add-scope write without the lifecycle bridge / export / handoff guidance
+- ⊗ Auto-promote proposed scopes from this skill
+- ⊗ Change `directive init` brownfield-install classification from this Phase 3 detector
 
 ### ⚠️ MANDATORY: Strategy Gate — Do This First
 
@@ -685,7 +695,7 @@ omit = [
 
 **Dispatch:**
 
-- **interview** (or default) → Continue to the Sizing Gate below ✅
+- **interview** (or default) → On identity-only Starting-new, continue to the Sizing Gate below and ask what to build (Chaining Gate skip allowed for that invocation per [strategies/interview.md](../../strategies/interview.md#chaining-gate)). On scoped/brownfield, present the Chaining Gate first. ✅
 - **anything else** (discuss, yolo, speckit, research, brownfield, map, etc.) →
   1. ! Read `deft/strategies/{strategy-name}.md` **right now, in this same turn**
   2. ! Begin the strategy's workflow immediately — ask its first question
@@ -809,6 +819,23 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 - ! Testing Strategy and Deployment captured in narratives
 - ⊗ Write code — specification only
 
+### Scope acceptance write shape (#4374)
+
+! When a Phase 3 (Light or Full) or Add-scope write includes independently testable acceptance criteria, put them on `plan.narratives.AcceptanceCriteria` as markdown list items (`- ` or `1.`). `Test` and `Verification` use the same shapes. The JSON key is the section delimiter — do not duplicate `## Acceptance Criteria` inside the string. Labeled lines (`test:` / `acceptance:`) are also derivable.
+
+! Bare prose in those keys is not derivable. `scope:promote` / `scope:activate` then name the unparseable shape instead of silently no-op'ing. Do not hand-author `plan.acceptance` to pass activate.
+
+⊗ Stamp write-time `plan.acceptance: { "none_stated": true }` as a derive-and-stamp. Derivation already engages on an absent block; that write opens activate with 0 clauses.
+
+~ A successful #3323 stamp writes `commands`, `none_stated`, `source_rung`, `derived_reason`, `clauses`, and `ambiguity_attestation`. Do not emit `file_scope` or a second attestation writer here — that compose is #4380.
+
+### plan.acceptance exclusive writer (#4380)
+
+! Derivation (`#3323` / `#3360`) owns `plan.acceptance`. Setup stays silent on that block.
+⊗ Emit `plan.acceptance`, `ambiguity_attestation`, or a schema-complete acceptance stamp from this skill.
+? Collect `plan.metadata.swarm.file_scope` only as operator-named declared members for later derived-stamp bind (`#4008`). ⊗ Invent paths. ⊗ Mint an approved-scope digest (`#3145` / `#3110`).
+! Fields the gate requires: [`../../docs/plan-acceptance.md`](../../docs/plan-acceptance.md).
+
 ### Lifecycle Bridge to Downstream Skills (#1025)
 
 ! Scope xBRIEFs created by Phase 3 (both Light and Full paths) AND by the Onboarding Question "Add scope to this project" branch land in `xbrief/proposed/` with `plan.status: proposed`. This is the canonical deposit point per the deft lifecycle (`proposed -> pending -> active -> completed`). The #810 implementation-intent gate (`task xbrief:preflight`) and the deft-directive-swarm Phase 0 Step 1 preflight BOTH require candidate xBRIEFs to live in `xbrief/active/` with `plan.status == "running"` before any agent can dispatch against them; setup deliberately stops at `proposed/` because the lifecycle commitment (promote + activate) belongs to the downstream skill, not the setup interview.
@@ -891,3 +918,5 @@ Per [strategies/interview.md](../../strategies/interview.md#interview-rules-shar
 - ⊗ Skip the Returning-user re-entry / Revisit experimental rules path when USER.md exists and the operator entered setup to change experimental meta (#46)
 - ⊗ Clobber Personal or Defaults while toggling Experimental Rules (#46)
 - ⊗ Invent a full `deft config` verb family for experimental meta when setup re-entry suffices (#46)
+- ⊗ Default identity-only Phase 3 to Add-scope because PROJECT-DEFINITION exists (#4390)
+- ⊗ Synthesize the first proposed scope from Overview, directory name, or init seed (#4390)

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

@@ -157,6 +157,8 @@ Loop body, per candidate (top-of-queue first):
 
 ! **Scan**: list every `*.xbrief.json` under `xbrief/proposed/` and `xbrief/pending/`. Cross-reference each candidate against the user's stated swarm scope (the issue numbers / xBRIEF filenames the user asked the monitor to swarm on). Candidates outside the stated scope MUST NOT be promoted or activated by this bridge -- they may be in a deliberate refinement queue owned by `skills/deft-directive-refinement/SKILL.md` Phase 4.
 
+! **Identity-only first-scope skip (#4390):** write-time is the control. Setup/interview MUST NOT emit a proposed xBRIEF from Overview, directory name, or init seed. This scan does not learn origin from file text — proposed xBRIEFs do not record that provenance. If live PROJECT-DEFINITION `plan.items` is still empty and proposed candidates exist, present them and wait for explicit operator confirmation (`yes` / `confirmed` / `approve`) before promote. ⊗ Infer filler vs operator-authored by comparing Overview or directory name. ⊗ Treat an identity-only filler proposed xBRIEF as swarm-ready work without that confirmation.
+
 ! **Present**: render a numbered list of in-scope candidates to the user with their current lifecycle folder (`proposed/` vs `pending/`) and `plan.status`. Render the canonical numbered menu in chat unless the host UI visibly preserves the same numeric option labels and returns numeric selections or exact displayed option text. The final two numbered options MUST be `Discuss` and `Back` per [`../../contracts/deterministic-questions.md`](../../contracts/deterministic-questions.md).
 
 ! **Approve**: wait for explicit user approval (`yes`, `confirmed`, `approve`) before any lifecycle mutation. Broad affirmative continuation phrases (`proceed`, `do it`, `go ahead`) are NOT authorisation -- the bridge MUST be explicitly confirmed because promoting + activating a scope xBRIEF is a lifecycle commitment that flips `plan.status` to `running` and clears the #810 implementation-intent gate for downstream agent dispatch.

package/strategies/interview.md

@@ -31,10 +31,12 @@ or switch to a different spec-generating strategy. This gate is the single
 orchestration point for strategy composition.
 
 ! The chaining gate MUST always be shown — even when the interview strategy is
-invoked directly with no prior strategy.
+invoked directly with no prior strategy — except the identity-only Starting-new
+skip below (#4390).
 ! The chaining gate is a **blocking question**. The AI MUST present the options
 and wait for the user to choose before proceeding.
-⊗ Skip the chaining gate or proceed to the sizing gate without presenting it.
+⊗ Skip the chaining gate or proceed to the sizing gate without presenting it,
+except the identity-only Starting-new / Proceed invocation named below.
 
 ### When It Appears
 
@@ -44,17 +46,31 @@ and wait for the user to choose before proceeding.
 
 ### Brownfield Detector
 
-Before rendering menu options, classify the repo (align with setup Phase 3):
+Before rendering menu options, classify the repo (same rule as setup Phase 3; #4390 recut of the #2925 identity-OR-scopes probe):
 
-- **Brownfield** when **either**:
-  - `PROJECT-DEFINITION` exists under `./xbrief/` or legacy `./vbrief/` (`PROJECT-DEFINITION.xbrief.json` or `PROJECT-DEFINITION.vbrief.json`), **or**
-  - any lifecycle folder (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `xbrief/` or legacy `vbrief/`) has scope records
-- **Greenfield** otherwise
+- **Identity-only** when BOTH:
+  - live PROJECT-DEFINITION `plan.items` is empty (`[]` or absent), AND
+  - no convention-valid `*.xbrief.json` / `*.vbrief.json` in lifecycle folders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/` under `./xbrief/` or legacy `./vbrief/`). Exclude `.gitkeep` and `*.premigrate.*`. PROJECT-DEFINITION itself is identity, not a scope record.
+- **Scoped (brownfield)** when `plan.items` is non-empty OR at least one convention-valid scope file exists
+- **Greenfield** otherwise (no PROJECT-DEFINITION and no convention-valid scope file)
 
 ! The detector MUST run on every Chaining Gate presentation.
+! Identity-only and greenfield share the Proceed / Starting-new default. Scoped/brownfield defaults to Add-scope.
+⊗ Treat PROJECT-DEFINITION existence alone as brownfield.
+⊗ Use session-age ("this setup turn just wrote identity") as the probe.
+⊗ Invent a "finished Phase 3" marker.
 ⊗ Offer only the greenfield-framed **Proceed to specification** default on a brownfield repo.
 ⊗ Treat brownfield as a full create path without an explicit Replace/scrap confirm.
 
+### Starting-new / Proceed skip (#4390)
+
+! Starting-new (setup Phase 3) and Proceed (this gate) MUST ask what to build before writing a scope.
+
+? When setup Phase 3 already selected **Starting a new project specification** on identity-only, this Chaining Gate MAY be skipped for that invocation and the agent may continue to the Sizing Gate. Written reason: identity-only default is already Proceed; the prior identity-OR-scopes detector re-defaulted to Add-scope one step later and skipped the product interview.
+
+⊗ Skip this gate on scoped/brownfield repos.
+⊗ Skip this gate when the operator chose Add-scope, Update, or Replace.
+
 ### Options
 
 ! 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).
@@ -63,11 +79,14 @@ Present groups sourced from the `Type` column in
 [strategies/README.md](./README.md#strategy-types). The **default path** depends
 on the brownfield detector:
 
-**Default path (greenfield):**
-1. **Proceed to specification** (default) — continue to the [Sizing Gate](#sizing-gate) for a full create path
+**Default path (greenfield or identity-only):**
+1. **Proceed to specification** (default) — ask what to build; continue to the [Sizing Gate](#sizing-gate) for a full create path
+
+**Identity-only also keeps Add-scope / Update / Replace / Process-only on the menu** (same vocabulary as setup Phase 3). They are not the default.
 
 **Default path (brownfield) — create-vs-update menu:**
-1. **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
+1. **Add scope to this project** (default) — load existing project identity + preparatory artifacts; **skip** the greenfield "what are we building?" interview only after capturing an explicit product or slice description; gather only the new scope; emit **one** proposed scope record; apply the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) on write
+   - ! On identity-only Add-scope: capture a product or slice description, or do not emit a proposed xBRIEF. ⊗ Synthesize the first scope from Overview / directory name / init seed. Swarm's `xbrief/proposed/` scan is in scope for that skip.
 2. **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)
 3. **Replace specification (scrap)** — full recreate equivalent to greenfield Proceed; **only** after explicit affirmative (`yes` / `confirmed`); vague replies (`proceed`, `ok`, `go ahead`) are **not** acceptance
    - ! On confirmed scrap, continue to the [Sizing Gate](#sizing-gate) as a full create path
@@ -147,7 +166,32 @@ Ready to generate the specification. Before we proceed, would you like to:
 10. Back
 ```
 
-**Brownfield:**
+**Identity-only** (PROJECT-DEFINITION exists; empty `plan.items`; no convention-valid scopes) — same options as setup Phase 3; Proceed is the default:
+
+```
+This repo has project identity but no scopes yet. Before we proceed:
+
+1. Proceed to specification (default) — ask what to build; full create path
+2. Add scope to this project — keep identity; requires an explicit product or slice description
+3. Update project definition — delta interview; merge narratives (Spec-Generating Guard)
+4. Replace specification (scrap) — requires explicit yes/confirmed; full recreate
+5. Process-only (keep Phase 2 identity) — leave strategy; no new scope; no spec write
+
+--- Preparatory (loops back) ---
+6. Run a research phase — investigate the domain, find libraries, identify pitfalls
+7. Run a discuss phase — lock key decisions using Feynman technique
+8. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks
+9. Run a map phase — analyze existing codebase conventions
+
+--- Switch strategy ---
+10. Switch to yolo — auto-pilot picks all answers
+11. Switch to speckit — formal spec process with story readiness before implementation
+12. Other (specify)
+13. Discuss
+14. Back
+```
+
+**Brownfield** (scoped):
 
 ```
 This repo already has a project definition and/or scopes. Before we proceed:

package/tasks/verify.yml

@@ -113,7 +113,9 @@ tasks:
       - task: :engine:_ts-build
     dir: '{{.USER_WORKING_DIR}}'
     cmds:
-      - node "{{.DEFT_ROOT}}/packages/core/dist/docs/docs-impact.js" --project-root "{{.USER_WORKING_DIR}}" {{.CLI_ARGS}}
+      - task: :engine:invoke
+        vars:
+          ENGINE_CMD: 'docs-impact --project-root "{{.USER_WORKING_DIR}}" {{.CLI_ARGS}}'
 
   license-sync:
     desc: "Drift guard for root LICENSE ↔ content/LICENSE.md and published package.json license fields (#2902). Three-state exit (0 clean / 1 drift / 2 config). Framework-source only."

package/templates/agent-prompt-preamble.md

@@ -96,7 +96,7 @@ Populate `selected_backend` OR `routing_policy` (or both when the operator sets
 
 **Role-boundary expectations (all providers):** the same boundaries apply whether the worker runs on Composer, Grok Build, Cursor/cloud, Claude Code, OpenClaw, or a future adapter:
 
-- ! `leaf-implementation` workers implement scoped xBRIEF work in their assigned worktree only -- gates (`task check`, file-scope audit, Greptile review cycle) are model-agnostic and MUST still pass.
+- ! `leaf-implementation` workers implement scoped xBRIEF work in their assigned worktree only -- gates (prefer `deft check`; else tree-correct `task deft:check` on include-only consumers or `task check` in framework source; file-scope audit; Greptile review cycle) are model-agnostic and MUST still pass. These are one gate, not two sequential runs. Do not add a fourth probe (#2893 / #4379).
 - ! **Spawned mutating workers take their own worktree (#4066 / #4295).** Implement-class spawn must dest-place before occupancy claim. Grok `spawn_subagent` dest is `cwd` only (cannot rewrite PreToolUse input). Claude/Codex keep `isolation=worktree` or a linked path. Cursor Task has no local dest field — dest-placing is a dest-rooted window (nursery inherit) or `@cursor/sdk` `Agent.create({ local: { cwd } })`; do not advertise Task dest keys. Sharing the primary checkout with a live occupant is refuse, not `occupancy:grant` across hosts. Master/primary occupancy is the exception (`release-cut`, `policy-restore`, operator-directed default-branch work). `--read-only` never claims. On DONE/terminal the dispatcher compare-and-releases the recorded child tree (incarnation + parent-id); do not steal the parent's lease to recover.
 - ! `orchestrator`, `review-monitor`, and `merge-release` roles MUST run on strong or review-capable agents; dispatchers MUST NOT route these roles to cheap leaf backends.
 - ⊗ Route a cheap leaf backend onto the merge cascade, Phase 5->6 release gate, conflict-resolution rebase, or review-cycle merge-ready decision -- these are irreversible-damage surfaces that stay on the strong tier regardless of provider.

package/templates/agents-entry.md

@@ -76,6 +76,7 @@ Deft is installed in .deft/core/. Full guidelines: .deft/core/main.md
 ! **Dual stop (#2442):** multi-iteration work MUST have success + failure/budget stop (max iters / no-progress / budget); single-turn exempt; halt with operator-visible report; ⊗ thrash. Defaults: build, swarm, review-cycle skills. See main.md Dual Stop Rule. Ledger #3143 (`packages/core/src/delivery-attempt/`).
 ## Rule Authority [AXIOM]
 ! Prefer `task deft:*` over AGENTS.md prose. See main.md.
+! Merge chokepoint (#4379 / #2893): prefer `deft check`; else `task deft:check` on include-only consumers. One gate, not two runs.
 ## Thin Fail-Closed Design (#3265)
 ! One fail-closed `task deft:*` check + one remediation. See main.md.
 ## Writing bar (#3368)

package/vbrief/schemas/vbrief-core.schema.json

@@ -612,7 +612,7 @@
         "sessionRitualStalenessHours": {
           "type": "integer",
           "minimum": 1,
-          "description": "Maximum age, in hours, for .deft/ritual-state.json before the fail-closed session ritual verifier requires task session:start to run again. Default: 4."
+          "description": "Maximum age, in hours, for .deft/ritual-state.json before the fail-closed session ritual verifier requires task session:start to run again. Default: 8."
         },
         "forgeOutageRetryMinutes": {
           "type": ["integer", "null"],