# Discuss Strategy Structured alignment before planning — front-load decisions, prevent drift. Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY. **⚠️ See also**: [strategies/interview.md](./interview.md) (Phase 1: Interview) | [strategies/speckit.md](./speckit.md) (Phase 2: Specify) | [core/glossary.md](../glossary.md) > Extends Deft's Interview phase with decision locking and Feynman technique. Adapted from [GSD](https://github.com/gsd-build/get-shit-done) discuss phase. --- ## Core Principle The most expensive mistake is building the wrong thing. A 10-minute alignment conversation saves hours of re-implementation. Decisions made here flow through the entire pipeline — planning, execution, verification — and are **never re-debated** downstream. --- ## When to Use - ! Before planning any feature/phase with gray areas - ~ Before any feature where multiple reasonable approaches exist - ? Skip only when the path forward is unambiguous and the user confirms ## The Feynman Approach Use the Feynman technique: if the user (or you) can't explain the feature in simple, concrete terms, the understanding isn't there yet. - ! **Make the abstract concrete** — "Walk me through using this." "What does that look like on screen?" "What happens when this fails?" - ! **Explain it back** — Restate the user's intent in your own words. If the restatement surprises them, the spec is wrong. - ! **Find the gaps** — Where the explanation gets hand-wavy is where the bugs will be. - ~ Use the "teach it to a child" filter: if the expected behavior can't be described without jargon, it's underspecified. ## Questioning Behaviors ### Follow Energy - ~ Whatever the user emphasizes, dig deeper into that - ⊗ Robotically marching through a predetermined question list - ~ If the user spends time on error handling, ask deeper questions about error handling ### Challenge Vagueness - ! Push back on fuzzy answers: "Make it simple" → "Simple how? For the user? To implement? To extend later?" - ! Push back on assumed agreement: "Standard auth" → "JWT with refresh? Server-side sessions? OAuth? Which standard?" - ⊗ Accept fuzzy input — it produces divergent output ### Scope Guardrails - ! If the user suggests a capability belonging to a different feature, capture it as **deferred** - ~ Redirect: "That sounds like a new capability — I'll note it. For now, let's focus on [current scope]." - ~ Record deferred ideas in `./xbrief/plan.xbrief.json` with `deferred` status and a narrative explaining why ## Domain-Sensitive Questions Adapt question focus to what's being built: - **Visual features** → Layout, density, interactions, empty states - **APIs/CLIs** → Response format, flags, error handling, verbosity - **Data systems** → Schema, validation, migration, edge cases - **Organization tasks** → Grouping criteria, naming, duplicates, exceptions ## Output ! Before writing output artifacts, follow the [Preparatory Guard](./artifact-guards.md#preparatory-guard-light). - ! Produce a `xbrief/proposed/{scope}-context.xbrief.json` scope vBRIEF with a `LockedDecisions` narrative - ! Each decision includes: **what** was decided, **why**, and **alternatives considered** - ! When the lock is an intentional under-build (weaker Now + decided end-product Later), the decision MUST also include dual-path graduation fields: `now`, `later`, `graduationRef`, `trigger`, and `status` (`open` | `shipped` | `cancelled`) — see [Graduation (Now+Later)](#graduation-nowlater-dual-path-locks-2899) - ! This vBRIEF is injected into all downstream work: planning, execution, verification - ! Persist decisions as vBRIEF narratives on the relevant plan items - ⊗ Write decisions to a hand-authored markdown context file -- use vBRIEF narratives for token-efficient agent consumption ! After emitting the scope vBRIEF to `xbrief/proposed/`, surface the GitHub-issue tracking hint from [emit-hints.md](./emit-hints.md) — name all three patterns (none / `--umbrella` / `--per-vbrief`). ## Decision Locking - ! Decisions in the vBRIEF `LockedDecisions` narrative are **locked** -- downstream tasks inherit them, don't re-debate - ! If a locked decision needs revisiting, explicitly flag it as unlocked with justification - ⊗ Silently making a different choice because the agent forgot what was decided - ⊗ Re-debating a settled decision without explicit user approval ## Graduation (Now+Later) dual-path locks (#2899) **Graduation** (alias: Now+Later) is a first-class decision shape for intentional under-builds: > We *decided* to ship a weaker path **now**, and we also decided what the end-product path is **later**. It is **not** the same as other "later" concepts: | Concept | Meaning | |---|---| | `DeferredDecisions` (probe) | Not decided yet; open question with justification | | deferred plan item / `triage:defer` | Out of scope, or not accepted into the workspace backlog | | rapid **graduate** | Spike / prototype → fresh full interview/spec cycle | | **Graduation** | Decided weaker **Now** + decided end-product **Later** | Glossary naming for this term is owned by sibling work (#2907). Strategy prose here is the Wave A contract agents must follow until the glossary entry lands. ### When a lock is an under-build - ! When a `LockedDecisions` entry chooses a temporary, weaker, MVP, or shortcut approach **and** a stronger end-product approach is also decided, the entry MUST record a dual-path graduation shape with all of: - `now` — what this scope ships - `later` — the end-product approach - `graduationRef` — GitHub issue URL and/or scope xBRIEF path that tracks Later work - `trigger` — free-text condition that makes Later required (examples are illustrative only, e.g. "before multi-tenant customers", "when latency SLO is adopted") - `status` — `open` | `shipped` | `cancelled` (cancellation MUST include justification) - ! A permanent approach lock (no weaker temporary path) does **not** require graduation fields - ! Chat-only "we'll harden this later" is insufficient — same anti-pattern as decisions that exist only in conversation history - ~ Emitting `graduationRef` SHOULD use existing [emit-hints](./emit-hints.md) patterns (none / `--umbrella` / `--per-vbrief`) rather than a parallel SCM ontology - ⊗ Routing a *decided* under-build into `DeferredDecisions`, a deferred plan item, or `triage:defer` — those surfaces mean undecided or out-of-scope, not dual-path delivery - ⊗ Treating rapid prototype **graduate** as Graduation dual-path tracking inside a normal production build ### Lifecycle: Now complete ≠ Later closed - ! `task scope:complete` on the Now story MUST NOT imply closure of linked graduation work (`graduationRef` issue and/or Later scope xBRIEF stay open until Later ships or is explicitly cancelled) - ⊗ Closing a graduation ticket solely because the MVP / Now story completed - ~ Wave A (soft): when completing a story whose `LockedDecisions` contain an open graduation, warn and audit if `graduationRef` is missing or invalid — hard fail / policy flag is Wave B follow-on - ! Durable surfaces for graduation are: (1) strategy output narratives (this contract), (2) optional always-loadable ProjectRules for stricter consumer policy — ⊗ Cursor-rule-only as the sole persistence path --- ## Then: Chaining Gate After alignment is complete and decisions are locked in `xbrief/proposed/{scope}-context.xbrief.json`, return to the [chaining gate](./interview.md#chaining-gate) so the user can run additional preparatory strategies or proceed to spec generation. - ! On completion, register artifacts in `./xbrief/plan.xbrief.json`: - Update `completedStrategies`: increment `runCount` for `"discuss"`, append artifact path (`xbrief/proposed/{scope}-context.xbrief.json`) - Append the path to the flat `artifacts` array - ! Return to [interview.md Chaining Gate](./interview.md#chaining-gate) (the discuss phase replaces the interview's question-gathering -- decisions are already made, so the interview will be short or skipped entirely) - ! The locked decisions from `xbrief/proposed/{scope}-context.xbrief.json` MUST flow into subsequent strategies and spec generation - ⊗ End the session after discuss without returning to the chaining gate or the invoking strategy's next-step menu ! **Standalone context:** If invoked from a standalone strategy (e.g. map's standalone next-step menu) rather than from the interview chaining gate, return to the invoking strategy's menu instead. --- ## Workflow 1. **Open** -- Start with the user's goal statement; restate it in your own words 2. **Explore** -- Follow energy, challenge vagueness, ask domain-sensitive questions 3. **Lock** -- Record each decision in `xbrief/proposed/{scope}-context.xbrief.json` `LockedDecisions` narrative with what/why/alternatives (and dual-path graduation fields when the lock is an under-build; #2899) 4. **Verify** -- Explain the full picture back to the user (Feynman check) 5. **Chain** -- Return to [interview.md Chaining Gate](./interview.md#chaining-gate), or -- if invoked from a standalone strategy (e.g. map's standalone next-step menu) -- return to the invoking strategy's menu per the [standalone-context rule](#then-chaining-gate) above ## Anti-Patterns - ⊗ Skipping discuss and immediately writing code - ⊗ Asking generic checklist questions instead of following energy - ⊗ Accepting "make it nice" / "standard approach" / "whatever works" without pushback - ⊗ Scope creep — capturing out-of-scope ideas inline instead of deferring - ⊗ Decisions that exist only in conversation history (they must be in the vBRIEF `LockedDecisions` narrative) - ⊗ Ending after discuss without chaining into specification generation (chained mode; in standalone context, returning to the invoking strategy's menu satisfies the completion requirement per the [standalone-context rule](#then-chaining-gate))