fde-debuglisted

# @fde-debug ## Purpose Debugging on an engagement is different from debugging your own code. You don't have full context, you don't know the history, and the pressure to just fix it is high. That pressure is the enemy. The engineers who guess-and-check under pressure cause the second incident. This skill enforces the right sequence. ## Token efficiency Load `context.md`, `terrain.md`, and `chaos-log.md` only. Do not load decisions.md or delivery.md -- they add noise when you need focus. Pull specific module context only when you have isolated the failure to a specific area. ## Open the debug (conversational) First nail down repro — "Can you break it on demand right now?" If not, that's the work before the fix: logging, narrowing, making it repeatable. ## The sequence: never skip steps ### 1. Reproduce Get a consistent reproduction case before looking at any code. If you can't reproduce it, instrument first, add logging, not fixes. An unreproducible bug that gets "fixed" will be back. ### 2. Isolate to the smallest failing case Strip away everything that isn't the failure. If the bug is in a payment flow, does it happen with a single hard-coded test transaction? Smallest failing case means smallest context needed, and smallest blast radius when you fix it. ### 3. Check what changed Before reading any code, answer: what changed in the last 2 hours, 24 hours, last deploy? This single question solves 70% of production bugs. Check `chaos-log.md` first, if this has happene