systematic-debugging

Follow a four-phase process: read the error completely and reproduce the failure, compare against working examples, form one testable hypothesis, then implement a single fix verified by a failing reproduction. Never propose a patch before the investigation phase names the cause.

Replace setTimeout and sleep calls with condition-based waiting that polls for the actual event or state you need. The condition-based-waiting reference includes a waitFor polling pattern and helpers like waitForEvent and waitForEventCount.

Stop attempting more fixes and question the architecture instead. Repeated failures that each reveal new coupling indicate a structural problem, so raise the architecture question with your team rather than attempting a fourth patch.

Do not use it to implement an already-approved design, add features with no failing behavior, produce postmortems, or rewrite architecture on a first failure. It applies only when there is a named, observable technical failure to investigate.

Without a consistent reproduction or a next measurement to take, there is no evidence to investigate, so any root cause would be invented. The correct response is to state what is missing and hold rather than guess a likely fix.

Trace backward from the error site by asking what called each function and what value was passed, until you find where the bad value originated. The root-cause-tracing reference shows how to add stack-trace instrumentation and bisect test suites with find-polluter.sh.