fde-discoverlisted

# @fde-discover ## Purpose Find the real problem and map the codebase. The brief is a hypothesis until evidence confirms it. ## Token efficiency Load `context.md` and `brief.md` only. Load `terrain.md` if it exists -- do not regenerate it from scratch. Go deep only on hotspots, never load the full codebase into context. ## Start the conversation (not a script) The real spec is what people **do** when the system fails — not what the slide deck says. Coach the FDE to ask about workarounds in plain language, woven into what they already know: - "How are they coping today without your fix?" - "What do they rerun every Monday that embarrasses them?" - "Who's the person with the spreadsheet everyone trusts more than the dashboard?" **Find the spreadsheet** — almost always there. Who maintains it is your best interview. That file is the actual requirements doc. Talk like a curious colleague, not a discovery-phase checklist. ## What to actually listen for **The hesitation:** when someone says "well, there's also this other thing we do..." -- stop them. Ask them to finish. That is where the real problem is. The main story is what they are comfortable explaining. The hesitation is what they have not explained to anyone before. **Shadow AI:** if the workaround involves someone using ChatGPT or similar tools to process data, write queries, or fill gaps -- note it. It means the system is failing to meet a real need and someone found a way around it. That is both a risk (uncontro