flaky-triagelisted

# Flaky triage A flaky test is a test that reports noise. Left alone, it teaches the team to re-run rather than read, and by the time it has taught that, a real failure goes unnoticed. Retries hide the symptom and keep the cost. ## 1 — Confirm it is flaky Run the test in isolation, repeatedly, on the unchanged commit: ```bash <test cmd> --testNamePattern='<name>' --runInBand # repeat 20× ``` Then run the whole file, then the whole suite. **Where it passes alone and fails in the suite, the flakiness is shared state, not timing** — that distinction decides everything downstream, so establish it before theorising. Record the failure rate. One failure in twenty and one in two are different problems with different urgencies. ## 2 — Find the cause Five causes account for nearly all of them: **Shared state.** A previous test left a module registry, a global, a store, a DOM node, a spy or a database row behind. Signature: passes alone, fails in suite; the failure moves when the order changes. Confirm by running with a fixed seed and bisecting the test order. **Timing.** A fixed wait instead of a condition; an assertion racing an async update; a debounce or animation not accounted for. Signature: fails more on a loaded machine, more in CI than locally. **Time and timezone.** `new Date()` in the assertion path, a test that fails near midnight, or only in UTC, or on the day the month rolls over. Signature: fails at specific times of day, or only in CI. **Ordering.** The te