Six different tests failed during one night's work, never twice the same one, every one of them green when run alone: dom-subagent-ttl-tick.test.js:121, W7 dies during wait, chain happy path, W4 concurrency cap, submit-verify single: busy never rises, and chain "confirmed" fold … inconclusive. With the machine idle the full suite passes 923/916/0.
This is not a handful of fragile tests, it is a property of the suite. A pre-commit hook that fails at random exactly when the machine is busy is a hook that will eventually be bypassed, and it would hide a real regression in the noise.
dom-subagent-ttl-tick.test.js:121 is the clearest example: it allows 50 ms either side of a 60,000 ms deadline and measured 59,941 under load.
Unverified hypothesis worth trying first: node --test spawns one worker per core with no bound, which would explain both the timing drift and the out-of-memory kill seen the same night. A concurrency limit may fix both at once.
Six different tests failed during one night's work, never twice the same one, every one of them green when run alone:
dom-subagent-ttl-tick.test.js:121,W7 dies during wait,chain happy path,W4 concurrency cap,submit-verify single: busy never rises, andchain "confirmed" fold … inconclusive. With the machine idle the full suite passes 923/916/0.This is not a handful of fragile tests, it is a property of the suite. A pre-commit hook that fails at random exactly when the machine is busy is a hook that will eventually be bypassed, and it would hide a real regression in the noise.
dom-subagent-ttl-tick.test.js:121is the clearest example: it allows 50 ms either side of a 60,000 ms deadline and measured 59,941 under load.Unverified hypothesis worth trying first:
node --testspawns one worker per core with no bound, which would explain both the timing drift and the out-of-memory kill seen the same night. A concurrency limit may fix both at once.