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. Never propose fixes before completing the investigation phase.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual expected state, such as waiting for a specific event or count. This eliminates timing guesses and typically raises pass rates while speeding up execution.

Trace backward through the call chain to find where the bad value originated, then fix at the source rather than where the error appears. Add stack trace instrumentation with console.error before the failing operation if manual tracing is not possible.

No. The skill mandates root cause investigation even under time pressure, because systematic debugging is faster than guess-and-check thrashing. Quick symptom patches mask the real issue and typically cause repeat incidents.

Three failed fixes indicate a likely architectural problem rather than a wrong hypothesis. Stop attempting more fixes and question whether the underlying pattern or design is fundamentally sound, discussing it with your team before continuing.

Use the included find-polluter.sh bisection script, which runs test files one by one and checks whether the unwanted file or directory appears after each run. It stops at the first polluting test and reports it for investigation.