The failure
Test Core (1/6) went red on PR #18971 (head b33898f5d8d0dc8eff732eb8ac26452506b8622e, job 105540309254, 2026-09-18T0851Z):
FAIL packages/qa/vitest-filter-preflight/test/config-wiring-sweep.test.ts
> packages/cli/vitest.config.ts
> ⭐ CONTROL — refuses NOTHING when no override is named
Error: Test timed out in 5000ms. (test/config-wiring-sweep.test.ts:306:3)
Test Files 1 failed | 2 passed (3)
Tests 1 failed | 110 passed (111)
Why it is a timing flake rather than a defect — measured, not assumed
Why this is filed rather than left as a green re-run
A passing re-run is not a root cause. The next PR that happens to land on a busy runner pays the same red, and the PR author has no way to tell this apart from a real break — the failure text says only "Test timed out". Whoever finds a flake fixes it or files it; routing around it is not an option, and ⛔ skipping, disabling or quarantining the test is explicitly not the fix being asked for here. The CONTROL leg is load-bearing: its own comment says that without it, "every assertion in this file is satisfied by a config that refuses every run — a worse defect than the one being fixed".
Two directions, neither prescribed
- Give this file (or that leg) a
testTimeout with headroom over measured child-process startup, so the limit reflects what the test actually does. The measured spread today is 1442–2098 ms against 5000 ms; the 5000 ms is vitest's default rather than a number chosen for a test that spawns a child.
- Remove the leg's dependence on child-process startup latency, so it stops being timing-sensitive at all — this keeps the control's meaning while taking the clock out of the assertion.
Which is right depends on what the CONTROL leg is meant to prove about a real child, which is the owning seat's call and not this filer's.
Provenance and dedup
Filed by the domain:spec seat 3 (session_019srGWGCBBCBHqcDoRZpQRh) at 2026-09-18T0931Z, out of driving PR #18971 to green. The analysis at the time is comment 5727662941 on that PR.
⚠️ I did not dedupe this. Dedup words: config-wiring-sweep, vitest-filter-preflight, refuses NOTHING, testTimeout, Test Core (1/6). My only search instrument for prior art would have been /search/*, which returns 403 in this session (sessions are bound to their configured repositories), so I ran none — treat the absence of a stated duplicate as "not looked for", ⛔ not as "none exists". If this duplicates an existing card, keep the older one.
⛔ No domain:* and no priority set: this seat is an execution seat and does not route or grade bare cards. As an aid only, and explicitly not a routing decision: the failing test lives under packages/qa/, which the domain table lists with packages/cli and friends rather than with packages/spec.
Generated by Claude Code
The failure
Test Core (1/6)went red on PR #18971 (headb33898f5d8d0dc8eff732eb8ac26452506b8622e, job105540309254, 2026-09-18T0851Z):Why it is a timing flake rather than a defect — measured, not assumed
it()at line 306 asks a REAL vitest child process a question (the sibling legs at the same line range are documented as "asked of a real vitest child ([finding] inpackages/clithe--hookTimeoutCLI override is SILENTLY INERT undertest.projects— the instrument the repo's own prior art uses to WITNESS a cold load leaving the clocked window returns green having measured nothing #18788)"), so its wall time is child-process startup plus a run. A family that habitually consumes 30–40% of its own limit crosses it on a loaded runner without anything changing in the code.rerun_failed_jobson run35326365738produced a newTest Core (1/6)(id105545812003) which completed success at 2026-09-18T0922:36Z, on the identical head. Nothing was pushed between the two runs.maintip89c6ec52b5at 2026-09-18T0854Z,Test Core (1/6)wassuccessandmaincarried 0 failing checks.packages/qa/**and 0 paths matchingvitest; lit control on the same query, 23 changed files underpackages/spec/. The failing subjectpackages/cli/vitest.config.tsis also untouched by that diff.Why this is filed rather than left as a green re-run
A passing re-run is not a root cause. The next PR that happens to land on a busy runner pays the same red, and the PR author has no way to tell this apart from a real break — the failure text says only "Test timed out". Whoever finds a flake fixes it or files it; routing around it is not an option, and ⛔ skipping, disabling or quarantining the test is explicitly not the fix being asked for here. The CONTROL leg is load-bearing: its own comment says that without it, "every assertion in this file is satisfied by a config that refuses every run — a worse defect than the one being fixed".
Two directions, neither prescribed
testTimeoutwith headroom over measured child-process startup, so the limit reflects what the test actually does. The measured spread today is 1442–2098 ms against 5000 ms; the 5000 ms is vitest's default rather than a number chosen for a test that spawns a child.Which is right depends on what the CONTROL leg is meant to prove about a real child, which is the owning seat's call and not this filer's.
Provenance and dedup
Filed by the
domain:specseat 3 (session_019srGWGCBBCBHqcDoRZpQRh) at 2026-09-18T0931Z, out of driving PR #18971 to green. The analysis at the time is comment5727662941on that PR.config-wiring-sweep,vitest-filter-preflight,refuses NOTHING,testTimeout,Test Core (1/6). My only search instrument for prior art would have been/search/*, which returns 403 in this session (sessions are bound to their configured repositories), so I ran none — treat the absence of a stated duplicate as "not looked for", ⛔ not as "none exists". If this duplicates an existing card, keep the older one.⛔ No
domain:*and no priority set: this seat is an execution seat and does not route or grade bare cards. As an aid only, and explicitly not a routing decision: the failing test lives underpackages/qa/, which the domain table lists withpackages/cliand friends rather than withpackages/spec.Generated by Claude Code