Recording this so the next person does not misclassify it as a regression.
Failure
FAIL test/integration/run-writeback.cli.test.ts
> a write that never becomes visible
> records the bound it applied, so the timeout can be read against it
Tests 1 failed | 791 passed | 2 skipped (794)
What is known
| Observation |
Detail |
| Full-suite run |
failed once, npm test |
| Isolated re-runs |
3/3 passed — npx vitest run test/integration/run-writeback.cli.test.ts, 20 tests each |
| Branch under test |
feat/readme-poster-capture at the time |
| Files changed on that branch |
scripts/, package.json, package-lock.json, assets/ — nothing under src/ or test/ |
| Reproduced since |
no |
git diff --stat main...HEAD -- src test was empty on the branch that saw the failure, so no code the test exercises had changed.
Suspicion
Timing-bound. The test is about a write that never becomes visible and reads a recorded bound against a timeout, so it is inherently sensitive to how long the surrounding suite leaves the CLI waiting. A full suite run loads the machine differently from an isolated run, which fits passing 3/3 alone and failing once under load.
That is a hypothesis, not a diagnosis. It has not been reproduced.
Not captured
Vitest seed and file order were not recorded for the failing run, and the run predates this issue. Anyone reproducing should capture both, plus whether it reproduces under --sequence.shuffle or a constrained --poolOptions.threads.maxThreads.
Why this is filed rather than fixed
It surfaced during the README asset sequence and does not block it. A genuinely flaky timing assertion in a suite this project uses as evidence is worth fixing properly rather than in passing — the repository's whole posture is that a green suite means something.
Recording this so the next person does not misclassify it as a regression.
Failure
What is known
npm testnpx vitest run test/integration/run-writeback.cli.test.ts, 20 tests eachfeat/readme-poster-captureat the timescripts/,package.json,package-lock.json,assets/— nothing undersrc/ortest/git diff --stat main...HEAD -- src testwas empty on the branch that saw the failure, so no code the test exercises had changed.Suspicion
Timing-bound. The test is about a write that never becomes visible and reads a recorded bound against a timeout, so it is inherently sensitive to how long the surrounding suite leaves the CLI waiting. A full suite run loads the machine differently from an isolated run, which fits passing 3/3 alone and failing once under load.
That is a hypothesis, not a diagnosis. It has not been reproduced.
Not captured
Vitest seed and file order were not recorded for the failing run, and the run predates this issue. Anyone reproducing should capture both, plus whether it reproduces under
--sequence.shuffleor a constrained--poolOptions.threads.maxThreads.Why this is filed rather than fixed
It surfaced during the README asset sequence and does not block it. A genuinely flaky timing assertion in a suite this project uses as evidence is worth fixing properly rather than in passing — the repository's whole posture is that a green suite means something.