one-shot vitest failure on the first run after npm install — twice now, never on rerun

[lex00]

Twice (2026-08-30, both on merged main during merge verification): npm test fails exactly one test file on the FIRST run after npm install, then passes fully on every rerun — three consecutive greens after the first occurrence, immediate green after the second. Both times the failing file's identity was lost (default reporter, output truncated); occurrences were post-#319 (1 failed | 68 passed) and post-#333 (1 failed | 74 passed, 1419/1420 tests).

The install correlation is the lead: suspect something first-run — a vite/vitest cache rebuild race, an esbuild binary rebuild, or a port grabbed by a route test while another file's server is slow to release on cold import. To catch it: run the suite with a file reporter (npx vitest run > log 2>&1) right after a fresh npm install, repeatedly; the log names the file the terminal lost. CI has never shown it.

🤖 Claude Code — https://claude.ai/code/session_01Rfs1mLVWmwginHnDTg75sG

[lex00]

Third occurrence (2026-08-30, after merging #339): 6 failed tests in 1 file on the first npm test after git pull — NO npm install this round, so the install correlation weakens. Refined pattern: first suite run after the working tree changes fails, immediate rerun green (exit 0, 1509/1509). Suspicion shifts to a vite/vitest transform-cache invalidation race on changed modules. Still never in CI. Same capture failure: the default reporter's output didn't survive the terminal buffer — next occurrence, run npx vitest run > log 2>&1 FIRST, not second.

🤖 Claude Code — https://claude.ai/code/session_01Rfs1mLVWmwginHnDTg75sG

[lex00]

Capture fixed at the harness level: just test now tees the reporter into vitest.log (gitignored), so the next occurrence names its file without anyone remembering to redirect first. AGENTS.md says to attach that log here.

Two data points today, both first runs after a working-tree change (a new test file, then an edit to it), both fully green (76 files / 1518 tests). So 'first run after the tree changes' is not sufficient on its own; the three earlier occurrences all followed a git pull or npm install that touched many files at once, which still fits a transform-cache race on a large invalidation better than a per-file one.

🤖 Claude Code — https://claude.ai/code/session_01SfqZdPzrxxkCJkHgzzMacq

[lex00]

Fourth data point, this one on the ORIGINAL trigger: local node_modules had chant 0.52.2 (installed Aug 29, before the #336 floor bump), so npm ci replaced chant, chant-k8s-client and their trees — the largest invalidation yet — and the first just test straight after was green (77 files / 1534 tests, exit 0, log kept). So neither 'first run after a tree change' nor 'first run after install' reproduces on demand. What the three failures still share that these four greens don't: each followed a git pull that brought in NEW test files (post-#319, post-#333, post-#339 all added tests). Next lead: a brand-new test file's first transform, not a changed one's.

🤖 Claude Code — https://claude.ai/code/session_01SfqZdPzrxxkCJkHgzzMacq

[lex00]

Fifth data point, the strongest non-repro yet: a fully fresh clone + npm ci + first npx vitest run (2026-09-01, chant 0.54.0 floor) — green, 79 files / 1584 tests, log kept. That is the maximum possible invalidation (no prior vite/vitest cache, no prior node_modules, every test file "new" to the transform cache), so "a brand-new test file's first transform" alone can't be sufficient either — a fresh clone makes EVERY file's transform new and stays green.

What the three failures still uniquely share: git pull into an EXISTING clone bringing new test files into a WARM vitest cache. Next lead narrowed accordingly: a stale-cache + new-file interaction, not cold-start.

PR #351 makes the capture permanent: every run now writes .vitest-last.json, so the next occurrence names its file without anyone remembering to redirect.