systematic-debugginglisted

# Systematic debugging ``` NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST ``` A fix for a symptom is a failure. The pressure to guess is highest under time pressure, so that is exactly when to follow the process. ## Phase 1: Root cause 1. **Read the whole error**: the stack trace, codes, file and line numbers, and warnings above the error. 2. **Reproduce it reliably.** Write down the exact steps. If you can't reproduce it, gather more data; don't guess. 3. **Check what changed**: `git log`/`git diff`, dependency bumps, config, environment, data, OS or device version. 4. **Instrument the boundaries.** In multi-component systems (UI → API → service → DB; CI → build → signing; POS → fiscal device), log what enters and leaves each boundary once. That shows where it breaks. 5. **Trace backwards** from the bad value to where it first appears (`references/root-cause-tracing.md`). Fix at the source. ## Phase 2: Pattern Find similar code that works in this repo. Read the reference implementation completely. List every difference, however small, and every dependency or assumption involved. ## Phase 3: Hypothesis State one hypothesis: "X is the cause because Y." Test it with the smallest change, changing one variable at a time. If it's wrong, form a new hypothesis; don't stack fixes. If you don't understand something, say so and research or ask. ## Phase 4: Fix 1. Write a failing test that reproduces the bug (test-driven-development). 2. Make one fix at the root cause. No "wh