systematic-debugging

Root-cause-first debugging in four phases — investigate (read the full error, reproduce, check recent changes, instrument component boundaries), pattern-match against working examples, test one hypothesis at a time, then fix the cause with a failing test. Use when any bug, test failure, or unexpected behavior lacks a proven cause, when a fix is being proposed before the data flow was traced, when the previous fix didn't work, especially under time pressure (guessing is slower than the protocol), and when three or more fixes have failed — treat that as an architecture signal and raise it with the user instead of attempting a fourth. The bright line: no fix before the root cause is identified with evidence; in multi-component systems, log what enters and exits each boundary before theorizing. Hands the reproducing test to test-driven-development and the resolution claim to verification-before-completion. Not for changes whose cause is already proven (just fix them) and not for performance tuning without a defect (profile first).