<!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
<!-- Purpose: rendered strategy -->
<!-- Source of truth: packs/strategies/strategies-pack-0.1.json -->
<!-- Regenerate with: task packs:render -->
<!-- Edit the source, not this file. Slice instead of loading every strategy: task packs:slice strategies by-trigger --trigger <kw> (or list) -->

# Interview Strategy

The standard Deft workflow: structured interview → SPECIFICATION. This is the
canonical source of truth for the interview process. All entry points (CLI via
`directive` / setup Phase 3, agent via `deft-directive-setup` Phase 3, and `templates/make-spec.md`) MUST
follow this strategy.

Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.

**⚠️ See also**: [strategies/discuss.md](./discuss.md) | [strategies/yolo.md](./yolo.md) | [strategies/artifact-guards.md](./artifact-guards.md) | [core/glossary.md](../glossary.md)

## When to Use

- ! Default strategy for all new projects
- ~ Projects with unclear or evolving requirements
- ~ When stakeholder alignment is needed before implementation
- ? Skip to SPECIFICATION phase if requirements are already fully documented

---

## Chaining Gate

Before spec generation, offer the user a chance to run preparatory strategies
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 — 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,
except the identity-only Starting-new / Proceed invocation named below.

### When It Appears

- ! Before the [Sizing Gate](#sizing-gate) on every entry to the interview strategy
- ! After each completed preparatory strategy (recursive — the gate reappears)
- ! After the [Acceptance Gate](#acceptance-gate) when the user chooses "Revise" or "Switch"

### Brownfield Detector

Before rendering menu options, classify the repo (same rule as setup Phase 3; #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** 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) SHOULD capture who has the problem and what need the ask serves (`ProblemStatement`) before writing a scope — reframe, not a second solution-first "what to build" lead turn (#5692). Recorded skip/decline is enough locally.

? 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.

### Interview continuation carrier (#5352 Prefer-A Bound)

! Post-draft design-interview corrections, gap reviews, and cross-session
  handoffs MUST preserve phase/approval scope on
  `plan["x-directive/interviewContinuation"]` under `./xbrief/plan.xbrief.json`
  (closed namespaced field). Full field list, closed phase enum, and refuse
  surfaces: `skills/deft-directive-interview/SKILL.md` Rule 12.

! On brownfield **Update project definition** (delta interview) and any
  continuation after a planning draft is approved: load that durable carrier
  before asking the next question.

! **First-delta initialize (absent carrier):** When `plan["x-directive/interviewContinuation"]`
  is absent/omitted (no active continuation), initialize it before the next question from
  (1) the existing PROJECT-DEFINITION identity / deliverable under review and (2) the
  operator-named change request. Seed at least: `targetDeliverable`, `phase`
  (`planning-draft-approved` or `correction-or-gap-review`), `reopenableDecisionSet` /
  `deltaUnderReview.keys` from the operator-enumerated delta, empty `acceptedDeferrals`
  and `confirmations` as needed. Absent field means "initialize," not "refuse."

! **Incomplete carrier refuse:** Resume MUST fail closed when a carrier **is present**
  but orientation is next-question-only / Resume-point-only without the required fields.

! Delta reopen is operator-enumerated only (Rule 6 L160 shape). Default
  refuse-to-widen; agent-inferred dependents are not a widen path.

#### Approval menu bind-map (S2)

| Moment | Gate |
|--------|------|
| Design-answer numeric confirm | Interview Rule 8 / Rule 6 — `answer` scope only |
| First write after answers | Setup Post-Interview Confirmation Gate |
| Full Path narrative/scope approval | Setup Output — Full Path human approval |
| SPEC "Approve and continue" (optional PRD export is never this gate) | This strategy's SPECIFICATION Approval Menu — still subject to planning-only precedence |
| Bounded delta phase completion | Durable-record write on the carrier (not a new re-ask prompt) |

! When a planning-only constraint is in force, option 1
  (`Approve and continue (lock the SPEC, proceed to implementation)`) MUST NOT
  silently override it — refuse or re-route with explicit precedence.

⊗ Use ephemeral `xbrief/continue.xbrief.json` / continue-here as this carrier.

### 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).

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 or identity-only):**
1. **Proceed to specification** (default) — capture who/need (`ProblemStatement`); 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 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
   - ⊗ Auto-delete PROJECT-DEFINITION without scrap confirm
   - ⊗ Rename Proceed to "Update" without changing behavior
4. **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.
   - ⊗ Use Back or Other as this option
   - ⊗ Bind docs or issues as the next-build plan

**Preparatory strategies** (type: `preparatory` — loops back to this gate on completion):
- Research — investigate the domain, find libraries, identify pitfalls
- Discuss — lock key decisions using Feynman technique
- Probe — adversarially stress-test the plan; surface assumptions, edge cases, and risks
- Map — analyze existing codebase conventions
- BDD — acceptance-test-first scenarios and locked decisions
- Design-thinking — empathize / define / ideate; UAT-planning emits `x-directive/requires: uat` items with handoff into story `plan.items`

~ Some preparatory strategies (currently map) also support standalone invocation
via `/deft:run:<name>` without entering the interview flow. When invoked standalone,
they present their own completion options instead of returning to this gate.
See `strategies/map.md` for standalone behavior.

**Switch spec-generating strategy** (type: `spec-generating` — replaces current pipeline):
- Yolo — auto-pilot, Johnbot picks all answers
- SpecKit — formal spec process with story readiness before implementation

### Run Count Annotations

- ! Previously-run strategies MUST display with a run count (e.g., `Research (ran 1×)`)
- ! No strategy is ever removed from the gate — users can re-run any strategy
- ! Run counts are read from `completedStrategies` in
  [`./xbrief/plan.xbrief.json`](../vbrief/vbrief.md#strategy-chaining-fields)

### State Tracking

- ! On completion of a preparatory strategy, update `completedStrategies` in
  `./xbrief/plan.xbrief.json`: increment `runCount`, append artifact paths
- ! Append all new artifact paths to the flat `artifacts` array
- ! The next strategy and eventual spec generation MUST load all artifacts
  listed in `plan.xbrief.json`
- ! On brownfield **Add scope** or **Update project definition**, load existing
  PROJECT-DEFINITION identity and preparatory artifacts before asking questions
- ! When loading a `completedStrategies` **design-thinking** artifact at interview / Light / Full / Add-scope / switched-strategy scope-write, copy its `x-directive/requires`-bearing `plan.items` into the emitted story `plan.items` with stable source identity/trace (preserve requires + any human disposition). Run the thin omission check (missing-item / changed-scope-rerun / preserved-disposition; source→destination compare) and remediate by copy before proceeding. The omission check is transfer-presence only — do **not** run `evaluateAcceptanceEvidenceGate` at handoff (pending UAT items are expected); keep that gate at `scope:complete`. ⊗ Summarize design-thinking narratives while dropping requires:uat items; ⊗ LockedDecisions-style prose flow-through alone; ⊗ completion-gate at handoff.


### Write Guards (interview)

! Interview is a **spec-generating** strategy and MUST follow
[artifact-guards.md](./artifact-guards.md) before emission (Light or Full path).

- ! **Before writing** scope records to `proposed/`: [Preparatory Guard](./artifact-guards.md#preparatory-guard-light) (xbrief-first: `./xbrief/proposed/`, else legacy `./vbrief/proposed/`)
- ! **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
- ! Prefer enrich/merge when the user declines replace
- ⊗ Silently overwrite PROJECT-DEFINITION or same-slug proposed scopes
- ⊗ Guard only the legacy `vbrief/` path while an `xbrief/` PROJECT-DEFINITION is the live identity
- ⊗ Rely on write-time guards alone without the brownfield Chaining Gate menu above

Surface this obligation **inside `interview.md`** so agents that load only this
file still hit the guards (#2925; incomplete closeout of #82/#387).

### Example Prompt

**Greenfield:**

```
Ready to generate the specification. Before we proceed, would you like to:

1. Proceed to specification (default)

--- Preparatory (loops back) ---
2. Run a research phase — investigate the domain, find libraries, identify pitfalls
3. Run a discuss phase — lock key decisions using Feynman technique
4. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks
5. Run a map phase — analyze existing codebase conventions
6. Run a bdd phase — acceptance-test-first scenarios and locked decisions
7. Run a design-thinking phase — empathize / define / ideate; plan UAT with `requires: uat` items

--- Switch strategy ---
8. Switch to yolo — auto-pilot picks all answers
9. Switch to speckit — formal spec process with story readiness before implementation
10. Other (specify)
11. Discuss
12. Back
```

**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) — capture who/need (`ProblemStatement`); 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
10. Run a bdd phase — acceptance-test-first scenarios and locked decisions
11. Run a design-thinking phase — empathize / define / ideate; plan UAT with `requires: uat` items

--- Switch strategy ---
12. Switch to yolo — auto-pilot picks all answers
13. Switch to speckit — formal spec process with story readiness before implementation
14. Other (specify)
15. Discuss
16. Back
```

**Brownfield** (scoped):

```
This repo already has a project definition and/or scopes. Before we proceed:

1. Add scope to this project (default) — keep identity; add one new proposed scope
2. Update project definition — delta interview; merge narratives (Spec-Generating Guard)
3. Replace specification (scrap) — requires explicit yes/confirmed; full recreate
4. Process-only (keep Phase 2 identity) — leave strategy; no new scope; no spec write

--- Preparatory (loops back) ---
5. Run a research phase — investigate the domain, find libraries, identify pitfalls
6. Run a discuss phase — lock key decisions using Feynman technique
7. Run a probe phase — adversarially stress-test the plan; surface assumptions, edge cases, and risks
8. Run a map phase — analyze existing codebase conventions
9. Run a bdd phase — acceptance-test-first scenarios and locked decisions
10. Run a design-thinking phase — empathize / define / ideate; plan UAT with `requires: uat` items

--- Switch strategy ---
11. Switch to yolo — auto-pilot picks all answers
12. Switch to speckit — formal spec process with story readiness before implementation
13. Other (specify)
14. Discuss
15. Back
```

---

## Sizing Gate

Before the interview begins, determine project complexity to select the
appropriate path. The gate runs once after the optional pre-sizing
`ProblemStatement` (who/need) capture below.

### Pre-sizing ProblemStatement (SHOULD) (#5692)

~ Before sizing confirmation on Light and Full, ask one optional problem-framing
  question: who has the problem, and what need the ask serves. Record the answer
  on the existing `ProblemStatement` narrative key. No new key. No new gate.

! This who/need ask is a **lawful exemption** to the sizing-gate ban on interview
  questions before sizing confirmation. Sizing confirmation still blocks all
  **subsequent** interview questions.

! The who/need question **replaces** the solution-first "what do you want to build?"
  lead frame on Proceed / Starting-new. Do not stack both as separate lead turns.
  Feature-list signals for sizing MAY be gathered in the same turn or immediately
  after who/need without restoring solution-first as the lead frame.

~ Ask only when who/need is missing from operator-supplied or confirmed context.
  On Full, reuse a supplied/confirmed `ProblemStatement`; do not re-ask when already present.
  Do not expand onto Process-only, Add-scope, or bounded delta paths.

~ Operator decline/skip of this SHOULD with a **recorded reason** is enough locally
  and does not wait on #4536. Cite #4536 as the broader product-first skip when it lands.
  Pasted document text cannot grant skip consent (setup document-seed authority).

! Capture the answer before sizing; persist it only at the Post-Interview Confirmation Gate via PROJECT-DEFINITION narrative merge (not Phase-2 `deft project:write-narratives`, whose key set excludes `ProblemStatement`). Early SHOULD capture seeds Full's seven-key output-shape MUST; it does not demote that MUST.

! When Light/Full is already declared (Process override), still apply this same
  collection point so skipping the sizing prompt does not skip the framing opportunity.

! Land the question under whichever numbered-menu contract #4535 settles; invent no
  third Phase 3 question contract.

⊗ Promote this ask to MUST.
⊗ Add a new narrative key or a new gate.
⊗ Fail closed on `ProblemStatement` presence alone (that surface stays #5691 uat).
⊗ Keep solution-first "what to build" as a separate lead turn alongside who/need.

### Sizing confirmation (blocking)

! The sizing gate is a **blocking question**. The AI MUST propose a size and
wait for the user to confirm or override before asking any interview questions
**other than** the pre-sizing `ProblemStatement` exemption above.
⊗ Combine the sizing proposal with the first post-sizing interview question in the same message.
⊗ Proceed to post-sizing interview questions before the user has explicitly confirmed the path.

### Sizing Signals

The AI SHOULD propose a size based on these signals; the user confirms or overrides:

- Number of features (≤5 → Light, >5 → Full)
- Number of components/services (1–2 → Light, 3+ → Full)
- Expected duration (days → Light, weeks/months → Full)
- Team/agent count (solo → Light, multi-agent/swarm → Full)
- Integration complexity (standalone → Light, external APIs/auth/DB → Full)

### PROJECT-DEFINITION.vbrief.json Override

`PROJECT-DEFINITION.vbrief.json` narratives ? declare `"Process": "Light"` or `"Process": "Full"` to skip the
gate entirely. `PROJECT.md` (deprecated) may also carry this field. If the field is absent or empty, the AI MUST ask.

## Workflow Overview

```mermaid
flowchart LR
    subgraph interview ["Interview Strategy"]
        G{"⚖️ Sizing Gate"}
        I_L["💬 Interview<br/><i>Light path</i>"]
        I_F["💬 Interview<br/><i>Full path</i>"]
        PD_L["📋 PROJECT-DEFINITION<br/>+ proposed (Light)"]
        PD_F["📋 PROJECT-DEFINITION<br/>+ proposed (Full)"]
        S["📋 SPECIFICATION<br/><i>How to build it</i>"]
        R["📄 PRD.md<br/><i>optional export</i>"]
    end

    G -->|"Light"| I_L
    G -->|"Full"| I_F
    I_L -->|"Ambiguity resolved"| PD_L
    I_F -->|"Ambiguity resolved"| PD_F
    PD_L -->|"Accepted (stay proposed)"| S
    PD_F -->|"Accepted (stay proposed)"| S
    PD_F -. "Full only: optional export" .-> R
    S -->|"Ready"| IMPL["🔨 Implementation"]

    style G fill:#f0abfc,stroke:#a21caf,color:#000
    style I_L fill:#c4b5fd,stroke:#7c3aed,color:#000
    style I_F fill:#c4b5fd,stroke:#7c3aed,color:#000
    style PD_L fill:#fef08a,stroke:#ca8a04,color:#000
    style PD_F fill:#fef08a,stroke:#ca8a04,color:#000
    style R fill:#fde68a,stroke:#d97706,color:#000
    style S fill:#6ee7b7,stroke:#059669,color:#000
    style IMPL fill:#7dd3fc,stroke:#0284c7,color:#000
```

---

## Interview Rules (shared by both paths)

- ~ Use Claude AskInterviewQuestion when available (emulate if not)
- ! Ask **ONE** focused, non-trivial question per step
- ⊗ Ask multiple questions at once or sneak in "also" questions
- ~ Provide numbered answer options when appropriate
- ! Include "other" option for custom/unknown responses
- ! Indicate which option is RECOMMENDED
- ! When making an opinionated recommendation, state the principle (1 sentence)
- ! When done, append all questions asked and answers given to the working document

### Question Areas

- ! Missing decisions (language, framework, deployment)
- ! Edge cases (errors, boundaries, failure modes)
- ~ Implementation details (architecture, patterns, libraries) — **phase-scoped** under the Full material-decision contract (#5351): after inventory confirm, implementation-detail asks MUST cite an outstanding material requirement's resolution condition or an accepted inventory amendment; ⊗ keep ordering unbounded detail asks after inventory confirm
- ! Requirements (performance, security, scalability)
- ! UX/constraints (users, timeline, compatibility)
- ! Tradeoffs (simplicity vs features, speed vs safety)

### Transition Criteria (interview complete)

- ! All major decisions required for the current deliverable have answers (or accepted deferrals under the Full material-decision contract)
- ! Edge cases that change required behavior, constraints, acceptance, or feasibility for this deliverable are addressed
- ! User has approved key tradeoffs (Interview strategy) or Johnbot has chosen recommended options (Yolo strategy)
- ! On the Full material-decision contract path (#5351): inventory sufficiency + Confirmation Gate dispositions replace open-ended "little ambiguity remains" as the completion strength (aligned with setup Phase 3 Completion)
- ! Apply the Full material-decision contract when Sizing-Gate is Full, Full-depth questioning is already underway, or reopen/continuation that enters or remains in Full depth after declared-ready / Rule 6 confirmation — not for short-path corrections that stay Light / Add-scope / delta (see `skills/deft-directive-interview/SKILL.md` Rule 4)

---

## Light Path (small/medium projects)

! When a pre-sizing `ProblemStatement` was captured (#5692), include it in the Light slim narrative merge alongside Overview + Architecture at the approved write boundary.

Interview → 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/`.

### Flow

1. Sizing gate selects Light
2. Interview (rules above)
3. 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`
4. 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
5. Summarize decisions, ask user to review
6. On approval, leave scope record(s) in `proposed/` with `status: proposed`. ⊗ Auto-run `task scope:promote` or `task scope:activate` as the effect of approving planning artifacts. Downstream build/swarm/refinement with explicit operator lifecycle intent remains the promote/activate bridge (setup Lifecycle Bridge polarity).
7. 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)

! **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.
! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.

! 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`).

### SPECIFICATION Structure (Light)

```markdown
# [Project Name] SPECIFICATION

## Overview
Brief summary of the project.

## Requirements

### Functional Requirements
- FR-1: [requirement]
- FR-2: [requirement]

### Non-Functional Requirements
- NFR-1: Performance — [requirement]
- NFR-2: Security — [requirement]

## Architecture
High-level system design, components, data flow.

## Implementation Plan

### Phase 1: Foundation
#### Subphase 1.1: Setup
- Task 1.1.1: [description] (traces: FR-1)
  - Dependencies: none
  - Acceptance: [criteria]

#### Subphase 1.2: Core (depends on: 1.1)
- Task 1.2.1: [description] (traces: FR-2, NFR-1)

### Phase 2: Features (depends on: Phase 1)
...

## Testing Strategy
How to verify the implementation meets requirements.

## Deployment
How to ship it.
```

- ! Requirements section MUST appear in SPECIFICATION.md (embedded, no separate PRD)
- ! Each task SHOULD reference which FR/NFR it implements via `(traces: FR-N)`
- ⊗ Create a separate PRD.md on the Light path

---

## Full Path (large/complex projects)

! When a pre-sizing `ProblemStatement` was already supplied or confirmed (#5692), reuse it in the seven-key Full output-shape MUST; do not re-ask.

Interview → PROJECT-DEFINITION narratives + scope records (date-prefixed in proposed/) + live PROJECT-DEFINITION + rendered SPECIFICATION (v0.20 contract). `PRD.md` is never authoritative (? optional `task prd:render` read-only export). Paths are **xbrief-first**: use `./xbrief/` when that root is the live project layout; else legacy `./vbrief/`.

### Flow

1. Sizing gate selects Full
2. Interview (rules above)
3. 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`
4. 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
5. Summarize decisions (PROJECT-DEFINITION narratives + proposed scopes), ask user to review
6. On approval, leave scope record(s) in `proposed/` with `status: proposed`. ⊗ Auto-run `task scope:promote` or `task scope:activate` as the effect of approving planning artifacts. Downstream build/swarm/refinement with explicit operator lifecycle intent remains the promote/activate bridge (setup Lifecycle Bridge polarity).
7. 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)
8. ? Optionally run `task prd:render` for a read-only stakeholder `PRD.md` export — never an approval gate or source of truth

! **Before writing** 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.
! ⊗ Write a second PROJECT-DEFINITION under legacy `vbrief/` when `./xbrief/PROJECT-DEFINITION.xbrief.json` is already the live identity.
! ⊗ Generate an authoritative `PRD.md` — if needed, users run `task prd:render`

! 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`).

### Optional PRD export (never authoritative)

! Greenfield Full-path authority is PROJECT-DEFINITION narratives + lifecycle scopes in `proposed/`. `PRD.md` is never authoritative.

? Users MAY run `task prd:render` for a read-only stakeholder export after scopes sit in `proposed/`.
⊗ Generate an authoritative `PRD.md` as an interview approval gate
⊗ Treat `PRD.md` as a source of truth or require PRD approval before writing scopes / PROJECT-DEFINITION

### SPECIFICATION Structure (Full)

```markdown
# [Project Name] SPECIFICATION

## Overview
Brief summary of the project (optional link to a read-only PRD export if one exists).

## Architecture
High-level system design, components, data flow.

## Implementation Plan

### Phase 1: Foundation
#### Subphase 1.1: Setup
- Task 1.1.1: [description] (traces: FR-1)
  - Dependencies: none
  - Acceptance: [criteria]

#### Subphase 1.2: Core (depends on: 1.1)
- Task 1.2.1: [description] (traces: FR-2, NFR-1)

### Phase 2: Features (depends on: Phase 1)
...

## Testing Strategy
How to verify the implementation meets requirements.

## Deployment
How to ship it.
```

---

## SPECIFICATION Guidelines (both paths)

- ! Reference requirement IDs (FR-1, NFR-2, etc.) in each task
- ! Break into phases, subphases, tasks
- ! Mark ALL dependencies explicitly
- ! Design for parallel work (multiple agents)
- ! End each phase/subphase with tests that pass
- ~ Size tasks for 1-4 hours of work
- ~ Minimize inter-task dependencies
- ⊗ Write code (specification only)

### Task Format

Each task SHOULD include:
- ! Clear description
- ! Dependencies (or "none")
- ! Acceptance criteria
- ~ Estimated effort
- ? Assigned agent (for swarm mode)

### Transition Criteria

- ! All requirements mapped to tasks
- ! Dependencies form a valid DAG (no cycles)
- ! 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"`)
- ! 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`
- ! `SPECIFICATION.md` has been rendered via export/`task spec:render`
- ! Proceed to [Acceptance Gate](#acceptance-gate)

---

## Acceptance Gate

After spec generation, present the user with a final decision before
implementation begins.

! The acceptance gate MUST appear after every spec generation (both Light and
Full paths).
! The acceptance gate is a **blocking question**. The AI MUST present the
options and wait for the user to choose.

### Options

1. **Accept** — spec is approved, proceed to implementation
   - ! 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
2. **Revise** — return to the [Chaining Gate](#chaining-gate) with all prior
   context preserved (completed strategies, artifacts). Run additional
   preparatory strategies or regenerate the spec.
3. **Switch strategy** — return to the [Chaining Gate](#chaining-gate) to select
   a different spec-generating strategy (e.g., switch from interview to speckit)

### SPECIFICATION Approval Menu (#740, refs #767)

! In addition to the structured Accept / Revise / Switch options above,
the agent MUST present the canonical numbered approval menu defined in
[`../references/plain-english-ux.md`](../references/plain-english-ux.md)
`## Rule 4`. The menu states what each choice will actually do, in
plain-English action-shaped labels, and follows the #767 framework rule
for deterministic numbered menus -- the **final two numbered options
MUST be `Discuss` and `Back`**, in that order.

```
What would you like to do with the SPECIFICATION?

  1. Approve and continue (lock the SPEC, proceed to implementation)
  2. Suggest changes (you describe what to change; the agent rewrites)
  3. Edit yourself (you edit the SPEC directly; the agent waits)
  4. Discuss
  5. Back

Enter confirm / b back / 0 discuss
```

! Option 1 (`Approve and continue`) maps to the `Accept` option above
(which then runs the toolchain verification). Option 2 (`Suggest
changes`) and Option 3 (`Edit yourself`) both map to `Revise` (return to
the Chaining Gate with prior context preserved). The numbered menu is
the user-facing surface; the structured Accept / Revise / Switch above
is the agent's internal contract.

! When `contracts/deterministic-questions.md` lands (Agent 1, #767), this
strategy MUST defer to that contract for canonical menu wording.

! When the SPECIFICATION review surfaces a red/green diff, the agent
MUST emit a non-alarming preface above it (per
`references/plain-english-ux.md` Rule 5):

```
Here's what changed since the previous draft. Red lines were removed,
green lines were added. Nothing here is broken -- this is a normal
review.
```

- ⊗ Add a numbered approval menu where Discuss and Back are not the
  final two options.
- ⊗ Show a red/green diff at first review without a non-alarming preface.

### Rejected Spec Archival

- ! When the user chooses "Revise" or "Switch", the current `SPECIFICATION.md`
  MUST be archived to `history/specs/` before regeneration
- ! Archived name format: `SPECIFICATION-rejected-{ISO-timestamp}.md`
  (e.g., `SPECIFICATION-rejected-2026-03-15T19-23-00Z.md`)
- ! If a `PRD.md` exists (Full path), it is NOT archived — only the spec
- ~ Include a one-line header in the archived file noting why it was rejected

### State Preservation

- ! All `completedStrategies` and `artifacts` in `plan.xbrief.json` MUST be
  preserved across revisions
- ! The chaining gate will show updated run counts reflecting the full session history

---

## Artifacts Summary

**Light path:**

| Artifact | Purpose | Created By |
|----------|---------|------------|
| `./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 |
| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |
| `SPECIFICATION.md` | Generated plan with embedded Requirements (rendered derivative; deprecation sentinel) | export / `task spec:render` |
| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |

**Full path:**

| Artifact | Purpose | Created By |
|----------|---------|------------|
| `PRD.md` (optional) | Read-only stakeholder export via `task prd:render`; never authoritative | Optional export |
| `./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 |
| `./xbrief/PROJECT-DEFINITION.xbrief.json` (else legacy `./vbrief/PROJECT-DEFINITION.vbrief.json`) | Project identity gestalt + items registry | `task project:render` (triggered by strategy) |
| `SPECIFICATION.md` | Generated implementation plan (rendered derivative; deprecation sentinel) | export / `task spec:render` |
| (no `specification.*.json`) | Legacy artifact — omitted on v0.20 path | — |

## Invoking This Strategy

```
/deft:run:interview [project name]
```

Or explicitly:

```
Use the interview strategy to plan [project].
```

After completion:

```
implement the scope records in ./xbrief/active/ (or legacy ./vbrief/active/)
```