mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-11 21:26:44 +00:00
kevinveenbirkenbachandClaude Opus 5
32b0d3df94
The drill's space check required FREE >= PULLED, but the run is killed from outside by matrix.py's watchdog as soon as the runner drops below 6G free. The check knew nothing about that floor, so it waved through a drill that could not finish: 19008M free against a 13961M pulled tree passes FREE >= PULLED, and the sync then leaves 5047M, which is under the floor. That is what happened to the arch swarm drill in run 30830377785. The device sync reported the marker at 19:16:38.34, the watchdog fired at 19:16:39.73 on its next 30s tick, and the step died with rc 75 thirteen minutes into work that was already doomed when the precondition ran. The requirement is PULLED + FLOOR, not FREE >= PULLED and not 2 * PULLED. FREE is measured after the pull, so the first copy is already deducted; exactly one further copy is ever added on top of it - the device copy during the sync, and later the restore root, by which time base.sh has deleted the pulled tree. The two extra copies are sequential, never simultaneous. matrix.py owns the floor now and exports it as INFINITO_DISK_FLOOR_MB. It was previously a bare `6 * 2**30` the shell had no way to see, which is why the two sides could disagree about what "enough disk" means. This makes the failure honest and immediate; it does not create disk. The arch runner is short by about 1.1G, and closing that needs a capacity decision - bigger runner, smaller test dataset, or reclaiming build cache before the drill. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Test Utilities 🧪
This directory holds the operational side of testing in Infinito.Nexus.
These assets are meant to support confidence, not ceremony. They help the project validate real-world behavior across local development, CI environments, and deployment-oriented smoke tests. The emphasis is on practical feedback: when something breaks, the surrounding test tooling should make the failure easier to understand, easier to reproduce, and easier to clean up. 🚀
Good changes in this area usually make the test experience more:
- repeatable
- diagnosable
- environment-aware
- safe to rerun
The ideal outcome is boring reliability: contributors should be able to trust that a test run says something meaningful about the system, not just about the machine that happened to execute it. ✅