systematic-debugging

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

Trace backward through the call chain from the immediate cause to the original trigger, asking what called each level and what value was passed. Add stack trace instrumentation with console.error before the failing operation when manual tracing is not possible.

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

Stop and form a new hypothesis rather than stacking more fixes. If three or more fixes have failed, treat it as an architectural problem and discuss the fundamental design with your team before attempting another fix.

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