systematic-debugginglisted

# Systematic Debugging Never skip to fixing. Understand the cause first. A fix applied without understanding the root cause is a coin flip — it may mask the symptom while leaving the disease. ## 4-Phase Investigation > Follow `skills/progress-tracking/SKILL.md`: when this procedure has two or more steps, seed one todo item per step before starting and mark each complete as you go. ### Phase 1: OBSERVE Gather evidence before forming any theories. The goal is to build a factual picture of what is happening. - **Read error messages completely.** The first line is the symptom. The stack trace is the geography. The last frame before your code is where to look. - **Reproduce the failure.** If you cannot reproduce it, you cannot verify your fix. Document the exact reproduction steps. - **Collect multiple data points.** One error message is an anecdote. Three error messages are a pattern. Gather logs, stack traces, test output, and runtime state. - **Note what IS working.** The boundary between working and broken code narrows the search space dramatically. - **Record timestamps and sequence.** When did it start failing? What changed just before? Check git log, deployment history, and dependency updates. - **Treat intermittency as evidence, not noise.** A test that fails 1 in 10 runs is not "flaky". It reports a real condition that most invocations do not hit: timing, ordering, resource contention, or hidden global state. The conditions that make a test intermi