One in twenty means you can't verify a fix by running it once — that's
the actual problem, and it's the first thing to solve.

BUILD THE LOOP BEFORE TOUCHING THE CODE
  1. Reproduce on demand. Run it 200× in a loop, capture failures.
     If it fails ~10 times, you now have a signal.
     If it never fails alone, it's suite interaction — go to step 3.
  2. Establish a baseline failure rate. Write the number down. Every
     "fix" gets measured against it, not against a single green run.
  3. Bisect the environment, not the code:
       alone, 200×                → isolates the test itself
       full suite, random order   → shared state or ordering
       full suite, fixed seed     → random data
       full suite, --workers=1    → concurrency
     Whichever column changes the rate is your class of bug. This is
     four experiments and it eliminates three of four possibilities.

INSTRUMENT THE FAILURE, DON'T READ IT
  On failure only, dump: wall-clock timestamps per step, the random
  seed, test execution order, and any shared fixture state. A flake you
  can't reproduce is a flake you didn't record enough about.

THEN FORM ONE HYPOTHESIS
  State it so it can be wrong: "the assertion runs before the debounce
  fires." Change exactly one thing. Re-run 200×. Compare to baseline.

  10/200 → 0/200 is a fix.
  10/200 → 3/200 is a different bug underneath, not partial success.

WHAT NOT TO DO
  Don't add a retry, don't add a sleep, don't mark it skip. Each one
  converts a reproducible signal into a silent one, and you'll pay for
  it when the same race shows up in production where there's no retry.

What does the loop give you at 200 runs — does it fail alone?