fig. 2.17.3: a commit dropped anywhere along the mutation run, and which guard refuses it fig. 2.17.3 · a commit dropped anywhere along the mutation run, and which guard refuses it.⛶ THREE GUARDS: NO COMMIT CARRIES A MUTANT WITH THE THREE GUARDS BEFORE THE GUARDS ONE BLOCK IS ONE MUTANT’S TURN IN THE RUNNER: WRITE THE MUTANT, RUN GAME.CHECKS, RESTORE SIM.PY. LOCK · .MUTANTS.LOCK HELD FOR THE WHOLE RUN CLEAN CLEAN 1 2 3 4 5 6 7 8 9 10 11 12 STAMP ON LINE 1 AT EVERY WRITE COMMIT REFUSED BY THE LOCK: .MUTANTS.LOCK PRESENT SIM.PY LINE 1: # MUTANT: INSTRUMENT COSTS DO NOT SCALE · THE GATE WOULD REFUSE THE STAMP NEXT LOCK .MUTANTS.LOCK IS HELD FROM THE FIRST WRITE TO THE LAST RESTORE; THE RUNNER, VERIFY.SH AND PRE-COMMIT ALL REFUSE WHILE IT EXISTS STAMP LINE 1 OF THE MUTATED SIM.PY READS “# MUTANT: <NAME>, MUTATION RUN IN PROGRESS, DO NOT COMMIT”, SO THE FILE NAMES ITS OWN STATE GATE PRE-COMMIT REFUSES ANY COMMIT WHILE THE LOCK EXISTS, AND ANY STAGED SIM.PY CARRYING THE STAMP
source: vicky game/mutants.py lines 88-143 · .git/hooks/pre-commit lines 5-13 · verify.sh lines 5-8 · docs/BUILD-LOG.md lines 727-756 (703-732 at HEAD 93c9f5e) · fd3212d:game/sim.py line 814 · mutantGuards.data.ts
View in context: Testing assertions by reintroducing bugs → · All figures
Andrew Fribush , software and computer engineer in Austin. I build consequential systems where software meets institutions: finance, healthcare, commerce, government data, and the mechanisms that govern AI agents. Taking new engagements: hello@andrewfribush.com .