systematic-debugging

Follow the four-phase process: 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 the investigation phase.

Replace setTimeout and sleep calls 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, and only use arbitrary delays when testing actual timing behavior.

Trace backward through the call chain to find the original trigger rather than fixing where the error appears. Add stack trace instrumentation with console.error before the problematic operation, then fix at the source and add validation at each layer.

Use the find-polluter.sh bisection script with the polluted file path and a test pattern. It runs test files one by one, checks whether the pollution appears after each run, and stops at the first test that creates the unwanted file or state.

Never, according to the skill's iron law: no fixes without root cause investigation first. Even under time pressure or emergencies, systematic debugging is faster than guess-and-check thrashing, and three or more failed fixes indicate an architectural problem requiring discussion.