systematic-debugginglisted

# Systematic Debugging Find the root cause before changing production behavior. A plausible symptom fix is still a guess. ## Use this workflow Use it for bugs, failing CI, regressions, performance problems, integration failures, and unexplained behavior. Use it especially after one attempted fix failed or when urgency makes a quick patch tempting. ## Phase 1: establish facts 1. Read the complete error, stack, status, and surrounding logs. Record exact paths, lines, codes, timestamps, and affected identities. 2. State the observable failure separately from any theory about its cause. 3. Reproduce it consistently. If reproduction is intermittent, gather more evidence instead of treating one successful retry as a fix. 4. Inspect the smallest relevant diff, recent deployment, dependency, configuration, or environment change. 5. Trace the bad value or state backward through callers until reaching the earliest point where it becomes wrong. Fix that source, not the final crash site. For a multi-component path, inspect each boundary once: ```text input -> component -> output ``` At every boundary, verify the actual value, configuration propagation, identity, and result. Do not print secrets. Log presence, type, digest, length, or a redacted identifier instead. One evidence-gathering run should identify the first boundary where expected and actual behavior diverge. ## Phase 2: compare the working pattern Find the nearest working implementation in the same repository or autho