systematic-debugging

Follow the four phases: first investigate the root cause by reading errors fully, reproducing consistently, and checking recent changes; then analyze patterns against working examples; form one testable hypothesis; finally implement a single fix with a failing test case. Never propose fixes before completing Phase 1.

Use root-cause tracing: identify the immediate failing code, then trace backward through each caller asking what value was passed and where it originated. Add stack trace instrumentation with console.error before the failing operation if manual tracing stalls, and fix at the source rather than the symptom.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual condition you need, such as an event appearing or state changing. Poll every 10ms with a clear timeout error, and only use fixed delays when testing documented timing behavior.

Stop after three failed fixes and question the architecture rather than attempting a fourth. Repeated failures where each fix reveals new problems elsewhere indicate a structural issue, so discuss refactoring the pattern with your team instead of stacking more patches.

Never, according to this process. Even during production emergencies or under authority pressure, systematic investigation is faster than guess-and-check thrashing, and symptom fixes are classified as failure regardless of how simple the issue appears.