d34683bc681479c3ca16cc68f90cb0396e0a90f7
The pipeline caught two flaky tests of mine that sixty local runs had not. Both were bad tests rather than bad code, and both were mine from this session: - the eater test counted SURVIVORS, not arrivals. An eater crosses the whole court in ~24s and despawns, so a snapshot at 40s can legitimately show an empty court — that read as "the eaters never came". It tracks arrivals over the window now, and asserts the cap as a running peak. - the auto-aim test never actually aimed at the body it claimed to: fy was pinned at -0.95 and fx was a scaled x offset, so the ray leaned up-court and the called body could genuinely be the best-aligned thing in the cone. That is the magnet working. It now normalises a vector straight at the wrong body, picks the one furthest in x from the called one so the two are separable, and asserts the magnet takes what you pointed at. Measured 8 failures in 40 runs before, 0 in 60 after. And the durable fix: Math.random is seeded at the top of test.js. This suite is a Dockerfile build stage, so a red run blocks the deploy, which makes a 1-in-5 flake worse than no gate — it trains you to re-run it. The game leans on randomness everywhere, so the stream is made reproducible rather than the randomness stripped out. SEED=1234 node test.js re-rolls it; 25 seeds pass. The cost is noted in PROJECT.md: under one seed a guarded test can silently take its early-out forever, so I checked all four guards still run their bodies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Languages
JavaScript
75.2%
Python
15.8%
HTML
7.3%
Shell
1.4%
Swift
0.2%