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 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 with documented justification.

Stop after three failed fixes and question the architecture rather than attempting a fourth fix. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss the architecture with your team before continuing.

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

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 treated as failures regardless of how simple the issue appears.