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 Phase 1.

Stop after three failed fixes and question the architecture rather than attempting a fourth patch. Repeated failures where each fix reveals new problems elsewhere indicate a structural issue, not a wrong hypothesis, and warrant discussion before more changes.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual expected state, such as an event appearing or a count being reached. The included condition-based-waiting reference shows polling patterns with 10ms intervals and explicit timeouts.

Use the included find-polluter.sh bisection script, which runs test files one by one and checks whether a target file or directory appears after each run. It stops at the first test that creates the pollution and reports the culprit.

Never, according to the skill's iron law. Even for simple bugs, emergencies, or when a quick fix seems obvious, skipping Phase 1 is forbidden because symptom fixes mask underlying issues and create new bugs.

Every conclusion must be prefixed with [C] Confirmed (direct file:line or execution evidence), [D] Deduced (traceable inference chain), or [H] Hypothesized (unverified with stated confirmation steps). This prevents presenting guesses as verified facts.