fde-planlisted

# @fde-plan ## Purpose An FDE plan is not a sprint backlog. The technical sequence is the easy part. The hard part is knowing when to stop and show someone progress, who needs to see what before they will approve the next phase, and where the trust is thin enough that silence for two weeks will be read as failure. A technically correct plan that ignores engagement politics will fail on schedule. ## Token efficiency Load `reality.md`, `success.md`, `terrain.md`, `stakeholders.md` only. Load `business-case.md` if it exists -- it contains the scored use case from `@fde-sketch` that this plan should be built around. Load `decisions.md` only if re-planning an existing phase. Not the full `.fde/` directory. ## Opening Clarify scope in conversation — feature vs phase vs whole delivery. One natural question, e.g. "Are we planning this slice or the whole engagement?" — then listen before structuring anything. Before planning begins, confirm scope is locked. Read `success.md`. If out-of-scope is not defined, define it now. A plan built on undefined scope will accumulate scope creep silently. Every task added later without a scope conversation is a commitment made without the customer's awareness. ## The planning approach **Step 1: Start from success, work backwards** Read `success.md`. What's the final state? Now walk backwards, what's the last thing that has to be true before that? And before that? This gives you the dependency chain, not a wish list. **Step 2: Identify the f