Har bygget kodebasens guard‑motor — 268 registrerede commit‑tjek, 277 lint‑regler og 15 egne ESLint‑regler — plus 146 tests af selve tjekkene, så det er builden, der holder standarden, ikke reviewet.

Situation. Standarder, der er skrevet ned i en contributing‑guide, er forslag. Alle er enige i dem, og så er det fredag, ændringen er lille, og guiden taber. Zero‑warnings‑barren ville kun nogensinde holde, hvis noget andet end velvilje holdt den — og de lintere, der følger med hvert sprog, når slet ikke frem til de projektspecifikke regler, der faktisk betyder noget, dem om, hvordan netop dette kodebase er ment at virke.

Opgave. De regler, projektet gik op i, skulle kunne eksekveres, så det at bryde en fik en commit til at fejle frem for at vente på en reviewer med tid og hukommelse nok til at fange det.

Handling. Det, der voksede ud af det, er en guard‑motor. Der er 274 check‑scripts, 268 af dem registreret i commit‑hooks, ved siden af 277 JavaScript‑lintere og 96 shell- og 17 Python‑validatorer, der dækker de ting, hyldevareværktøj ikke har nogen mening om — at en migration kan rulles tilbage, at en oversættelsesnøgle findes i begge locales, at en registreret rute optræder i OpenAPI‑beskrivelsen, at ingen stille og roligt har tilføjet en inline‑suppression. Femten custom ESLint‑regler holder husets mønstre på plads i TypeScript. Én regel er værd at nævne for sig: enhver commit med præfikset fix: skal bære en test, der fejler uden den, så en fejl, der er rettet, bliver ved med at være rettet. Og fordi en ødelagt guard er værre end slet ingen guard — den lader alt passere, og ingen opdager det — har selve guard‑laget 146 test.

Resultat. Review‑tiden flyttede fra mekanik til design, fordi de mekaniske indvendinger allerede var fremsat af en maskine, før branchen blev pushet. Trade‑off’et er reelt og værd at sige højt: det er langsomt at committe, og en dårligt skrevet guard er oprigtigt irriterende at arbejde uden om. De 146 test findes, fordi netop det skete.