Diagnose a flaky test's real cause before Claude Code touches it

You are diagnosing a flaky test, not fixing it. A flaky test passes and fails on the same code with no relevant change between runs — the job here is finding the actual mechanism, not making the failure stop by whatever means is fastest.

TEST
tests/checkout/discount.spec.ts, 'applies the loyalty discount when cart total exceeds threshold'

WHAT HAS ACTUALLY BEEN OBSERVED
Fails roughly 1 in 15 runs on CI, has never failed locally in about 50 manual runs; failure is always a timeout waiting for a mocked API response.

ENVIRONMENT DIFFERENCES BETWEEN WHERE IT PASSES AND WHERE IT FAILS
CI runs the suite in parallel with 4 workers; locally the suite always runs single-threaded.

SUSPECTED CAUSE, IF ANY
Might be related to another test in the same file mutating a shared mock client instance.

DIAGNOSTIC PROCESS — DO NOT SKIP OR REORDER STEPS
1. Run the test in isolation, alone, at least ten times in a row. Report the exact pass and fail count.
2. Run the full suite it normally runs inside, at least ten times in a row, with this test included. Report the exact pass and fail count.
3. If isolated runs are stable but full-suite runs are not, this is order-dependence or leaked shared state — identify the specific test that runs immediately before it and what state that test leaves behind: a shared database row, a module-level variable, a mock that was never reset.
4. If both are unstable independently, look for genuine nondeterminism: unseeded randomness, a fixed sleep or timeout racing real async work, a system clock or timezone dependency, or a network or filesystem call that is not actually mocked.
5. Check git log for the test file and the code it exercises. Was this test reliable before a specific recent commit? A regression introduced by a real code change is a lead, not a coincidence, and should outrank a theory about inherent randomness.
6. State the diagnosis as one sentence naming the actual mechanism, backed by the evidence from steps one through five. 'It is flaky' or 'there might be a race condition' is not an acceptable diagnosis on its own — name the specific line, shared resource, or timing assumption responsible.

NOT ACCEPTABLE AS A SUBSTITUTE FOR DIAGNOSIS
Do not propose adding a retry, increasing a timeout, or marking the test skipped or quarantined as your finding. Any of these might be a legitimate part of an eventual fix once the mechanism above is named and confirmed, but proposing one before that point is a failed diagnosis, not a shortcut to one.

IF THE ENVIRONMENT DIFFERENCE ITSELF LOOKS LIKE THE CAUSE
If CI runs the suite in parallel with 4 workers; locally the suite always runs single-threaded. points at parallelism, worker count, or resource limits as the likely trigger, still complete steps one through five before concluding that — an environment difference is a plausible contributing factor, not by itself a mechanism, and the specific shared resource or timing assumption it exposes still needs to be named.

Once the diagnosis is confirmed and approved, propose the actual fix in a separate message, not this one.