ProofRun binder testresultatet til et SHA-256-avtrykk av koden din

En KI-kodeagent som nettopp har kjørt testene, og en som bare antar at de fortsatt går gjennom, skriver den samme setningen i chatvinduet. ProofRun, et Go-verktøy som nå ligger ute på GitHub, skiller de to ved å binde hvert resultat til git-commiten pluss en SHA-256-sum av alt som ikke er kommittert: staged, ustaged og usporede filer.

Endrer noen én byte etter kjøringen, går proofrun status fra PASS til STALE uten at noen må huske å spørre. Verktøyet har fire statuser, PASS, FAIL, STALE og NOT RUN, og hver av dem stammer fra en observert kjøring eller fra dokumentert fravær av en. Det gjøres ingen LLM-kall noe sted. ProofRun starter en ekte subprosess og leser den ekte exit-koden. Kommandoer sammenlignes som argv-lister, ikke som tekst, så en sjekk deklarert som pytest -k "foo bar" kan ikke innfris av en kommando som bare ser lik ut når alt flates ut til én streng.

Gaten er det praktiske poenget for deg som lar en agent jobbe løst i repoet. proofrun status --strict avslutter med kode ulik null hvis en påkrevd sjekk ikke er PASS, og kan henges på en pre-commit-hook eller i CI. GitHub-actionen sjekker ut PR-hodet selv i stedet for å stole på det arbeidsflyten allerede har hentet, og fjerner receipt.json som følger med PR-branchen, slik at ingen medbrakt kvittering blir trodd.

Prosjektet er ungt og åpent om grensene sine. Versjonen er 0.2.0, lisensen MIT, og repoet har 29 stjerner. .proofrun.yml er ikke beskyttet mot å bli svekket i samme PR som endrer koden: actionen varsler når fila avviker fra base-branchen, men blokkerer ikke. Signerte kvitteringer som tåler tukling er på ønskelista, ikke ferdig designet. En uavhengig gjennomgang før første utgivelse fant dessuten at ProofRuns egen kommandosammenligning kunne lures av et feilsitert shell-argument.

Hva bør du gjøre?

1. Kjør proofrun init i et repo der en agent skriver kode, og merk test og build som required: true.
2. Legg proofrun status --strict i pre-commit-hooken, slik at en STALE-sjekk stopper commiten før noen rekker å love at alt går gjennom.
3. Les diffen på .proofrun.yml like nøye som resten av PR-en, siden actionen bare varsler om endringer der.