systematic-debugging

Follow a four-phase process: investigate the root cause by reading errors and reproducing the issue, analyze patterns against working examples, form and test a single hypothesis, then implement one verified fix. Never propose fixes before completing the investigation phase.

Replace arbitrary timeouts 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 clear timeout error, which eliminates race conditions and typically speeds up test execution.

Stop and return to root cause investigation with the new information rather than stacking more fixes. If three or more fixes have failed, treat it as an architectural problem and discuss the fundamental design before attempting another fix.

Trace backward from the immediate cause by asking what called each function and what values were passed, continuing until you find the original trigger. Add stack trace instrumentation with console.error before the failing operation when manual tracing is not possible.

Never. Simple bugs have root causes too, and the process is fast for simple issues. Skipping investigation under time pressure leads to guess-and-check thrashing that is slower than systematic debugging.

It means adding validation at every layer data passes through: entry point checks, business logic validation, environment guards, and debug instrumentation. This makes the bug structurally impossible rather than fixed at a single bypassable point.