FunktionValidierungs-Belege
Hat die KI die Tests wirklich ausgeführt?
„Die Tests laufen durch“ ist eine Aussage, die ein Agent über seine eigene Arbeit macht. Reality Graph führt die freigegebenen Checks selbst aus, als argv-Liste ohne Shell und mit begrenztem Timeout, und hält den Exit-Code fest, den es beobachtet hat. Was es nicht selbst ausgeführt hat, steht als bezeugt daneben, und beides wird nie zu einem Wort verschmolzen.
Zuletzt aktualisiert:
Herkunft
Ausgeführt oder bezeugt, ohne dritten Wert
Der Unterschied klingt akademisch, bis jemand den Eintrag sechs Wochen später liest und nicht mehr erkennt, ob ein Ergebnis erzeugt oder nur berichtet wurde.
| Herkunft | Wie das Ergebnis entstand | Was es wert ist |
|---|---|---|
| Ausgeführt | Reality Graph hat den freigegebenen Befehl selbst gestartet und den Exit-Code beobachtet. | Die stärkste verfügbare Aussage: Der Befehl lief, und das kam zurück. |
| Bezeugt | Ein Mensch hat das Ergebnis eines Checks eingetragen, den etwas anderes ausgeführt hat. | Nützlicher Kontext, nie geprüft. Ein bezeugter Exit-Code ist eine Behauptung und wird als solche gespeichert. |
| Fehlend oder unbekannt | Ein gefordertes Ergebnis kam nie an oder kam fehlerhaft an. | Erzwungen blockierend. Es wird nicht zu einem Bestanden geglättet. |
validation-receipt.json (Auszug)
Beispiel – illustrativer Eintrag, keine echten Run-Daten{
"command": ["pytest", "-q"],
"provenance": "executed_by_reality_graph",
"exit_code": 0,
"duration_s": 12.4,
"shell": false,
"timeout_s": 600
}Akzeptanzkriterien
Der Schritt, der eure Kriterien liest und trotzdem nichts entscheidet
Ein optionaler Schritt kann ein Modell fragen, ob jedes Akzeptanzkriterium erfüllt ist. Er ist nützlich, und es lohnt sich zu wissen, wie wenig Befugnis er hat.
Der Schritt wird ausdrücklich gewählt, braucht eine angemeldete Codex-CLI und setzt das Ergebnis nie. Lief er nicht, steht im Eintrag „nicht belegt“, statt das Ergebnis hochzustufen. Genau das verhindert, dass ein ausgefallenes Review wie ein bestandenes aussieht.
Alles, was das Ergebnis entscheidet, bleibt deterministisch. Was das Modell beisteuert, ist eine Lesart neben den Belegen, und das Ergebnis wird ohne sie berechnet.
Bewusst so gebaut
Was ein grüner Check belegt, und was er nie könnte
Ein Bestanden ist eine enge Tatsache, und enge Tatsachen sind die einzigen, auf denen sich bauen lässt. Sie als breite zu verkaufen, ist der Weg, auf dem Prüfwerkzeuge genau das Vertrauen verlieren, für das sie existieren.
Was ihr bekommt
- Freigegebene Befehle als argv-Liste ausführen, ohne Shell, mit begrenztem Timeout und gefilterter Umgebung.
- Die freigegebene Spezifikation unmittelbar vor der Ausführung erneut prüfen, damit keine veraltete Freigabe wiederverwendet wird.
- Den beobachteten Exit-Code festhalten und getrennt davon, ob Reality Graph oder ein Mensch ihn erzeugt hat.
- Ein fehlendes, fehlerhaftes oder unbekanntes Ergebnis blockieren lassen statt es bestehen zu lassen.
Was es nicht ist
- Den Befehl in eine Sandbox setzen. Es begrenzt, welcher Befehl läuft, nicht, was dieser dann darf, und es gibt keine Netzwerkisolierung.
- Ein bezeugtes Ergebnis prüfen. Ein eingetippter Exit-Code wird gegen nichts abgeglichen.
- Messen, wie stark eure Tests sind. Kein Zählen von Assertions, keine Coverage, kein Mutation Testing.
- Den semantischen Review entscheiden lassen. Er hält „nicht belegt“ fest, statt ein Ergebnis hochzustufen.
- Mit eurer CI sprechen. Es gibt keine Pipeline-Anbindung, keinen Git-Hook und keinen Pull-Request-Check.
Bestanden heißt, der Befehl endete mit Null. Es heißt nicht, dass die Aufgabe richtig erledigt wurde, und diese Seite legt nichts anderes nahe.
Fragen, die wirklich gestellt werden
- Woher weiß ich, dass Reality Graph den Befehl ausgeführt und nicht nur ein Ergebnis notiert hat?
- Weil es festhält, was von beidem passiert ist. Es gibt genau zwei Herkunftswerte: Reality Graph hat den Befehl ausgeführt, oder ein Mensch hat bezeugt, dass etwas anderes ihn ausgeführt hat. Eine Vorgabe kann den ersten verlangen, und einen dritten Wert, der den Unterschied verwischt, gibt es nicht.
- Was hindert einen freigegebenen Testbefehl daran, etwas ganz anderes zu tun?
- Weniger, als die meisten annehmen, und hier zählt die ehrliche Antwort. Befehle laufen als argv-Liste ohne Shell, mit begrenztem Timeout und gefilterter Umgebung, und die freigegebene Spezifikation wird unmittelbar vor der Ausführung erneut geprüft, damit keine veraltete Freigabe wiederverwendet wird. Das begrenzt, welcher Befehl läuft, nicht, was dieser Befehl dann darf: Es gibt keine Sandbox und keine Netzwerkisolierung.
- Was passiert, wenn ein geforderter Check gar nicht läuft?
- Er zählt als blockierend, nicht als neutral. Ein fehlendes, fehlerhaftes oder unbekanntes Ergebnis wird zum Blocker gemacht statt zu einem Bestanden geglättet, weil die Alternative still einen Check belohnt, der nie gestartet ist.
- Heißt ein grüner Run, dass die Änderung korrekt ist?
- Nein. Bestanden heißt, der Befehl endete mit Null. Ob eure Tests das Verhalten abdecken, auf das es ankam, ist eine Frage an eure Suite, und Reality Graph misst keine Teststärke: Im Produkt gibt es kein Zählen von Assertions, keine Coverage-Werkzeuge und kein Mutation Testing.
Fragt euren letzten Agenten-Run nach seinem Exit-Code
Nicht nach dem Satz darüber, sondern nach dem Code selbst und danach, wer ihn gesehen hat. Diese Frage ist die ganze Funktion.
Weiterlesen
Schritt 4 von 9