r3xsean/code-loop

Überprüfe eine Code-Änderung mit einem anderen Modell in bis zu 3 Runden: Ein Prüfer liest die Änderung, und ein Breaker versucht, sie mit Tests zu brechen. Halte jede Korrektur so klein wie möglich, um den Befund zu beheben, und lege bei einem falschen Befund mit Beweisen Widerspruch ein.

1. Den Prüfer und den Breaker einweisen

Der Prüfer und der Breaker sind das neueste Modell in orchestrator_capabilities der Familie, die der Benutzer genannt hat (sol, opus, …), mit dem genannten Aufwand; setze keine anderen Modelloptionen. Ein Anbieter allein (gpt, claude) nennt keine Familie. Wenn die Familie oder der Aufwand fehlt, frage danach und tue nichts anderes, bis sie antworten.

Lege die Basis fest: diejenige, die der Aufrufer übergibt, sonst git merge-base HEAD <remote>/<default-branch>, wobei der Remote derjenige ist, in den die Änderung gemergt wird (upstream bei einem Fork), oder HEAD, wenn die Änderung nur uncommittet ist. Führe die Checks aus, die die Änderung abdecken, über die Verifizierungsfähigkeit des Repos, falls vorhanden (.agents/skills/verify/), und behebe alle Fehler vor Runde 1. Zeichne die Revision auf, auf der sie ausgeführt wurden, einschließlich uncommitteter Änderungen.

Beginne jede Runde als frische delegate_task. Widerspruch und spätere Runden gehören in die neue Einweisung, niemals in eine Folgenachricht an einen fertigen Prüfer. Ein Timeout oder Fehler ist keine Zustimmung: Starte den fehlgeschlagenen Agenten einmal neu.

Wenn der Diff nur Kommentare, Doks oder Formatierung ändert, führe keinen Loop aus und teile dies in der Abschlussnachricht mit. Starte in Runde 1 den Prüfer und den Breaker parallel, den Breaker mit isolation: "worktree". Überspringe den Breaker, wenn der Diff keinen ausführbaren Code ändert. Bei einem leichten Durchlauf (die Stufe see-it-through wird übergeben) starte in Runde 1 keinen Breaker; sobald der Prüfer antwortet, starte einen, der auf die Bedingungen seiner Zeile „Not verified“ beschränkt ist, die ein Test klären könnte, falls vorhanden.

Beide Einweisungen beginnen mit diesem Header:

Repo: <absoluter Pfad>  Basis: <sha>  Nicht im Fokus: <Scope>
Standards: <die Regeldateien des Repos, wie AGENTS.md oder CONTRIBUTING.md; oder keine>
Setup: <was jede Shell zuerst ausführen muss, wie ein Skript für die festgelegte Toolchain, und was ein frischer Checkout braucht, wie eine Installation; oder keine>
Checks: <Ergebnisse>  Läuft jetzt: <noch laufende Checks; oder keine>
Anfrage: <die Anfrage oder Einweisung des Benutzers, wortwörtlich, oder ihr absoluter Pfad>
Vorgehen: <das genehmigte Vorgehen, oder sein absoluter Pfad; oder keine>. Seine Behauptungen stammen vom Autor: Überprüfe diejenigen, auf die der Diff sich stützt.
Abnahme: <der Commit oder Patch, der die vor der Änderung geschriebenen Abnahme-Checks enthält; oder keiner>
Diff: git diff <base>; lies auch unverfolgte Dateien von git status --short.
Bedingungen: Bevor du den Diff liest, schreibe Abnahmebedingungen aus der Anfrage: was der Benutzer bei Erfolg, Fehlschlag, Abbruch und Wiederholung sehen oder zurückbekommen soll; nach einem Teilfehlschlag (was im Speicher, auf der Festplatte und auf dem Bildschirm verbleibt); bei einer Wiederholung oder wenn ein früherer Versuch nach einem neueren endet; wenn eine Erwartung zurückkommt, nachdem der Benutzer weitergemacht hat; auf jeder Oberfläche, die das Ergebnis zeigt, einschließlich zwischengespeicherter Daten; und einen Ausweg aus jedem Zustand, den die Änderung hinterlassen kann. Schreibe eine nur dort, wo der geänderte Code diesen Fall erreicht: auf dem beabsichtigten Pfad, durch jeden anderen Aufrufer des geänderten Codes, und durch jeden anderen Schreiber von Zustand, dem die Änderung nun vertraut (suche nach beidem).

Einweisung für den Prüfer, nach dem Header:

Nur prüfen: Lesen und verfolgen. Nicht bearbeiten, committen, pushen, kommentieren, Unteragenten starten oder Tests oder Builds schreiben oder ausführen.
Schreibe die Abnahmebedingungen wie von Conditions angegeben, dann wie du die Änderung innerhalb des Vorgehens vornehmen würdest. Beginne deine finale Antwort mit beidem, wortwörtlich; die VERDICT-Zeile folgt ihnen.
Finde Probleme mit der Änderung, indem du jede Bedingung durch den Code bis zu dem verfolgst, was der Benutzer sieht oder zurückbekommt. Dein Vorgehen ist nur dann ein Befund, wenn es eine Bedingung erfüllt, die der Diff nicht erfüllt, oder jede Bedingung mit weniger Code erfüllt.
Benenne für jeden gefundenen Bug seine Klasse und suche im restlichen Diff und seinen Aufrufern nach demselben Fehler, einschließlich eines verwandten Falls, den die Änderung anders behandelt; melde einen Befund pro Klasse und liste alle Orte auf.
Überprüfe die Änderung anhand der Standards-Dateien; kennzeichne diese Befunde als [standards] und überspringe, was Linter und Typprüfer erzwingen.
Markiere als Nits: Code oder Guards, die keine Bedingung benötigt, neuen Code, den das Repo oder die Plattform bereits bereitstellt, und Code, der von den Standards oder den Konventionen des umgebenden Codes abweicht; keinen Stil, den du lediglich bevorzugst.
Prüfe, ob die Änderung konkurrierende Zustandsverwaltung, eine an zwei Stellen getroffene Entscheidung, eine Verpflichtung, an die Aufrufer denken müssen, oder eine Grenze, die Aufrufer umgehen können, einführt; kennzeichne diese als [structure], nenne den Code und seine Konsequenz, und bewerte sie nach den folgenden Definitionen. Ein anderes Design ohne solche Konsequenz ist ein Nit; ein umfangreicheres Redesign ist nur ein Befund, wenn begründet wird, warum die kleinste Korrektur es nicht beheben kann.
Eine Bearbeitung eines Checks in der Abnahme, die ihn daran hindert, das zu beweisen, was er verspricht, ist ein Should.
blocker = der beabsichtigte Fall ist falsch. should = ein Problem, das diese Änderung verursacht und das eine unterstützte Aktion oder Eingabe erreichen kann: eine Benutzeraktion, Dateien auf der Festplatte, ein E/A-Fehler, vom Benutzer erstellte Dateien, gezeigt durch Ausführung oder durch den Code verfolgt, auch durch Aufrufer, die der Diff nicht berührt hat. Ein Test, den die Änderung hinzufügt und der ohne das von ihm bewiesene Verhalten bestehen kann, ist ein Should.
nit = Stil, kleine Leistungsverbesserung, Politur. pre-existing = derselbe Fehler tritt auf der Basis auf, gezeigt durch einen Test oder eine Spur, und die Änderung macht ihn weder leichter erreichbar noch widerspricht sie einer von ihr gemachten Behauptung.
VERDICT: APPROVE oder CHANGES, dann eine Zeile pro Befund:
S1 [blocker|should|nit|pre-existing] <Datei>:<Zeile> <Behauptung>. Korrektur: <kleinste Korrektur>
dann Checked: eine Zeile pro Bedingung: <Datei>:<Zeile> und was diese Zeile feststellt.
dann Not verified: was du nicht bestätigen konntest und warum; oder keine.

Einweisung für den Breaker, nach dem Header:

Brich diese Änderung. Committe, pushe, kommentiere nicht und starte keine Unteragenten.
Arbeite nur in deinem eigenen Checkout, dem Arbeitsverzeichnis, in dem du gestartet bist, das eine Kopie von <Repo>'s HEAD ist. Übertrage zuerst den uncommitteten Teil der Änderung: git -C <Repo> diff HEAD | git apply, kopiere dann die unverfolgten Dateien, die von git -C <Repo> status --short aufgelistet werden. Ändere niemals Dateien in <Repo> oder die Konfiguration des Benutzers und führe nichts aus, was pusht, postet oder benachrichtigt; Paket-Manager-Caches sind in Ordnung. Überspringe E2E-Läufe und alles, was unter „Läuft jetzt“ aufgeführt ist; kompiliere nur das, was deine Tests benötigen.
Schreibe die Abnahmebedingungen wie von Conditions angegeben. Schreibe und führe für jede den kleinsten Test, der fehlschlagen würde, wenn die Bedingung gebrochen wäre, und bestätige, was der Benutzer sieht oder zurückbekommt.
Entferne für jeden Test unterhalb von E2E, den die Änderung als Beweis hinzufügt, den Guard, den er abfangen soll, oder brich seine Vorbedingung, führe ihn aus und stelle dann den Code wieder her.
COULDN'T TEST ist nur für eine Bedingung, die diese Ebene nicht erreichen kann, wie eine, die E2E benötigt. Eine langsame Warteschlange oder dein eigenes kaputtes Setup ist keine: Bündele deine Tests in einem Job, warte darauf, ohne abzubrechen, und repariere dein Setup.
Bevor du antwortest, schreibe einen Patch deiner erfolgreichen Tests, die eine Bedingung abdecken, die kein vorhandener Test abdeckt, nach <keep path>, und lösche alles andere, was du hinzugefügt hast.
Antworte, eine Zeile pro Bedingung: B1 HELD <Bedingung> — <Befehl>; B2 BROKE <Bedingung> — <Befehl> und die fehlschlagende Ausgabe; oder B3 COULDN'T TEST <Bedingung> — warum. Dann eine Zeile pro Beweistest: P1 FAILS <Test> mit <Guard> entfernt; oder P2 STILL PASSES <Test> mit <Guard> entfernt. Dann: Behalten: <keep path> und die Bedingung, die jeder Test abdeckt; oder keine.

Wähle <keep path>: einen absoluten Pfad außerhalb beider Checkouts.

2. Befunde beantworten

Bewerte jeden Befund selbst nach den Definitionen aus der Prüfer-Einweisung, unabhängig vom beigefügten Label. Behandle jede BROKE- und STILL PASSES-Zeile als Befund.

• Zustimmen: Reproduziere ihn zuerst mit einem Test, der auf dem aktuellen Code fehlschlägt, wenn ein sinnvoller Test praktikabel ist, ansonsten eine direkte Reproduktion (Befehl und Ausgabe) mit seinen Grenzen; überprüfe eine Behauptung über Tatsachen, wie was CI ausführt oder was die Basis tut, anhand ihrer Quelle. Durchsuche dann die verwandten Fälle und Aufrufer des geänderten Codes nach weiteren Vorkommen der Befundsklasse und wende die kleinste Korrektur auf jede Instanz an, die die Änderung eingeführt oder offengelegt hat; liste nicht verwandte, bereits bestehende als Nacharbeiten auf. Zeige, dass der Test besteht (bei einem STILL PASSES-Befund, dass der korrigierte Test mit entferntem Guard fehlschlägt), und behalte den Test. Bevorzuge das Löschen oder Eingrenzen von Code gegenüber einem neuen Lock, Cache, Hilfsmittel oder einer Option.
• Nicht zustimmen: Sage warum, mit Beweisen (einem Test oder einer Befehlsausgabe). Ein Grund, der allein aus dem Code gelesen wird, wie „das kann nicht passieren“, hinterlässt den Befund als strittig, nicht als fallengelassen oder herabgestuft.
• Nit: Bei Code, den der Diff hinzufügt, ändert oder verschiebt, wende es an, wenn seine Korrektur Code löscht, das wiederverwendet, was das Repo oder die Plattform bereitstellt, oder den Code an die Standards oder den umgebenden Code anpasst, wobei alle Checks bestehen bleiben und ohne Klarheit gegen Länge einzutauschen. Lehne in einer Zeile ein Nit ab, das einen Pfad, Fall, eine Option oder Kompatibilitätsschicht hinzufügt, eines, dessen Korrektur ändert, was der Benutzer sieht oder zurückbekommt, und eines, das nur Geschmackssache ist.
• Pre-existing oder nicht im Fokus: Lehne in einer Zeile ab.

Committe jeden Test im Patch des Breakers oder nenne den vorhandenen Test, der seine Bedingung abdeckt.

Stimme niemals nur zu, um den Loop zu beenden. Führe die Checks und git diff --shortstat <base> erneut aus; entferne, was die Prüfung außerhalb von Tests hinzugefügt hat, die kein akzeptierter Befund benötigt, und behalte die kleinste korrekte Korrektur, auch wenn sie den Code vergrößert.

3. Nächste Runde

Starte eine nur, wenn ein Blocker oder Should offen ist oder sich Verhaltenscode geändert hat. Sende den Header mit seiner Conditions-Zeile ersetzt durch die Bedingungen des Prüfers aus Runde 1, die Prüfer-Einweisung ohne ihre Bedingungs-und-Skizzen-Zeile, jede frühere ID markiert als behoben, strittig (mit den Beweisen) oder abgelehnt (mit dem Grund), und die seit der letzten Runde geänderten Hunks. Sage dem Prüfer, er solle nur die offenen IDs und diese Hunks prüfen, neue Bedingungen für das Verhalten schreiben, das diese Hunks und ihre Aufrufer ändern, jede frühere ID als gelöst oder noch offen markieren und neue Befunde nach der letzten ID nummerieren. Wenn eine Korrektur Verhalten, Reihenfolge oder Eigentumsverhältnisse geändert hat, z. B. das Verschieben eines Schreibvorgangs hinter eine Erwartung, starte auch einen Breaker mit demselben Header, der angewiesen wird, Bedingungen nur für diese Hunks und ihre Aufrufer zu schreiben und zu testen.

4. Abschluss

Beendet, wenn kein Blocker oder Should mehr offen ist und die letzte Änderung außerhalb von Tests, Kommentaren und Formatierung eine Runde durchlaufen hat; APPROVE beendet den Loop vorzeitig auf dem Code, den es geprüft hat. Sende einen neuen Breaker bei jedem COULDN'T TEST, dessen Ursache behoben werden kann; liste einen, der E2E für den Autor benötigt. Wenn ein Blocker oder Should nach Runde 3 noch strittig ist, führe die Streitrunde in dispute-round.md durch; ein Befund, den sie als INCONCLUSIVE zurücklässt, beendet den Loop als abgeschlossen mit ungelösten Streitigkeiten, nicht genehmigt. Abgelehnte Nits und bereits bestehende Befunde bleiben abgelehnt.

Abschlussnachricht: Anzahl der durchgeführten Runden, die Modelle, was die Befunde geändert haben, jedes getaggte Verhalten, jeder Test, jede Behauptung oder Politur, Diff-Größe vorher und nachher, alle fallengelassenen Befunde, weil ein Test oder eine Ausgabe ihre Falschheit gezeigt hat, und jeder abgelehnte Nit oder bereits bestehende Befund mit seinem Grund. Füge hinzu, was der Breaker getestet hat, was gebrochen wurde, welche davon der Prüfer ebenfalls gefunden hat, und jede Bedingung, die kein committeter Test abdeckt. Wenn eine Streitrunde stattfand, gib jedes Ergebnis an. Liste jedes unbestätigte Risiko in einfachen Worten auf. Wenn evals/results.jsonl existiert und sich das Prüfer-Modell vom letzten darin unterscheidet, sage dies und biete einen Lauf der Regressionssuite an (evals/README.md).