merttcetn/pev-loop

PEV-Schleife

Führe eine zustandslose Planer-Ausführer-Verifizierer-Schleife für ein persistentes Ziel aus. Halte den primären Agenten als dünnen Controller: Verwalte kanonischen Zustand, entsende isolierte Rollen, erzwinge Limits und melde Ergebnisse, ohne das Produkt selbst zu planen, zu implementieren oder zu bewerten.

Nicht verhandelbare Garantien

• Erfordere expliziten $pev-Aufruf. Behandle diesen Aufruf als Autorisierung, das passende native Ziel zu erstellen oder wiederzuverwenden und die P-, E- und V-Subagenten zu entsenden.
• Halte den Controller aus der Produktarbeit heraus. Überprüfe keine Quelltexte, implementiere keine Änderungen, interpretiere keine rohen Testergebnisse und entscheide nicht über Rubrikerfüllung im primären Kontext.
• Erstelle jeden P-, E- und V-Agenten mit frischem Kontext. Verwende fork_turns="none" oder das stärkste Äquivalent der Laufzeitumgebung.
• Lasse niemals zu, dass ein Agent seine eigene Arbeit bewertet.
• Verberge Planer- und Ausführungslogik, Zusammenfassungen und erwartete Ergebnisse vor dem Verifizierer.
• Nur Verifizierer-Nachweise dürfen die Rubrikerfüllung ändern.
• Speichere den gesamten Ausführungszustand in einem eindeutig benannten OS-temporären Verzeichnis. Erstelle niemals Ausführungszustand unter dem Repository-, Arbeitsbereichs-, Home- oder Skillverzeichnis.
• Lasse das genaue temporäre Verzeichnis am Ende des Laufs an Ort und Stelle. Stage, committe, pushe, veröffentliche oder kopiere keine Inhalte in dauerhafte Projektdateien.
• Halte die PEV-Mechanik aus der Produkt-Rubrik heraus. Erzwinge Iterationslimits, Modell-Routing, Rollenisolation und temporären Zustand durch die mechanische Prüfung des Controllers.
• Lösche, überspringe, schwäche oder schreibe keine bestehenden Tests neu, nur um ein Bestehen zu erzielen. Erlaube legitime Teständerungen nur, wenn das Benutzerziel dies erfordert, und lasse sie dann vom Verifizierer genau prüfen.
• Umgehe niemals die finale vollständige Rubrikverifizierung.

Den Aufruf parsen

Akzeptiere ein Ziel nach $pev und diese optionalen Steuerungen:

• max=N oder --max N: erlaube 1..10; Standardwert 6.
• using=$skill-name: lade das benannte Skill unabhängig in jeder Rolle, in der es relevant ist. Verwende seine Anforderungen in der Rubrik, fordere den Ausführer auf, es zu befolgen, und fordere den Verifizierer auf, es unabhängig zu bewerten.

Wenn der Aufruf kein Ziel angibt, lese das aktive native Ziel. Wenn keines existiert, frage nach dem Ziel und halte an.

Wenn native Zielwerkzeuge verfügbar sind:

1. Lese das aktuelle Ziel, bevor du eines erstellst.
2. Verwende ein aktives Ziel nur wieder, wenn es dem angeforderten Ziel entspricht.
3. Erstelle ein Ziel, wenn keines existiert. Setze kein Token-Budget, es sei denn, der Benutzer hat explizit eines angegeben.
4. Wenn ein anderes unvollendetes Ziel existiert, halte an und frage den Benutzer, es zu lösen, anstatt es zu ersetzen.

Wenn native Zielwerkzeuge nicht verfügbar sind, fahre als begrenzter PEV-Lauf fort und teile mit, dass eine automatische Fortsetzung nicht verfügbar ist.

Temporären Zustand bootstrappen

Führe aus:

python3 <skill-verzeichnis>/scripts/init_run.py --max-iterations <N>

Notiere das zurückgegebene absolute run_dir im Thread und übergib es explizit an jeden Subagenten. Lies references/contracts.md vor der ersten Entsendung.

Bevölkere goal.json mit dem genauen Ziel und den Einschränkungen. Entsende einen frischen Spezifikationsplaner, um die unveränderliche Definition von „fertig" zu erstellen. Fordere, dass jedes Rubrik-Element:

• als unerfüllt beginnt;
• ein beobachtbares Ergebnis und keine Aktivität beschreibt;
• akzeptable Nachweise nennt;
• Benutzer- und Repository-Einschränkungen bewahrt; und
• unabhängig verifizierbar ist.

Schließe interne PEV-Mechaniken wie Iterationsanzahl, Agentenauswahl, Kontextisolation, temporäre Pfade und Controller-Buchhaltung aus der Produkt-Rubrik aus. Bewahre benutzersichtbare Arbeitsbereichsinvarianten wie „nicht committen", „nicht pushen" oder „Tests nicht ändern", wenn sie das angeforderte Ergebnis einschränken.

Friere rubric.json nach dem mechanischen Schema-Gate des Controllers ein. Speichere veränderliche Erfüllung und Nachweise nur in progress.json.

Der Controller besitzt jede Zustandsdatei. P-, E- und V-Agenten müssen kompakte JSON-Antworten zurückgeben und dürfen den temporären Zustand nicht ändern.

Die Schleife ausführen

Für jede Iteration von 1 bis max_iterations führe diese Schritte in der Reihenfolge aus.

1. Einen frischen Planer entsenden

Starte einen frischen schreibgeschützten Sol-Planer. Gib ihm nur:

• den Arbeitsbereichspfad;
• goal.json, rubric.json und progress.json;
• den vorherigen Verifizierer-Befund, sofern vorhanden;
• die Iterationsnummer und das verbleibende Budget; und
• explizit angeforderte using=-Skills.

Erlaube dem Planer, das Produkt und die Repository-Anweisungen zu inspizieren. Gib ihm keine vorherigen Planer- oder Ausführungsüberlegungen.

Fordere ein begrenztes task_packet gemäß dem Vertrag. Erlaube DONE_CANDIDATE nur, wenn keine nützliche Arbeitseinheit mehr übrig ist; behandle es niemals als Fertigstellungsnachweis.

Lehne einen Plan mechanisch ab, wenn er:

• kein unerfülltes Rubrik-Element adressiert;
• Umfang, Einschränkungen oder Verifizierungsziele auslässt;
• eine fehlgeschlagene Arbeitseinheit wiederholt, ohne auf Verifizierer-Nachweise zu reagieren;
• Testabschwächung oder eine unbefugte destruktive Aktion anfordert; oder
• nicht in eine Ausführer-Zuweisung passt.

Füge bei sicherheitskritischen, migrations-, berechtigungs-, finanz- oder irreversiblen Arbeiten einen frischen schreibgeschützten Plan-Reviewer vor der Ausführung ein. Gib ihm das Ziel, die Rubrik und das Aufgabenpaket, aber keine Planer-Überlegungen.

Schreibe das akzeptierte Aufgabenpaket in plan.json, bevor du den Ausführer entsendest. Verschiebe Controller-Zustandsaktualisierungen nicht bis nach der Verifizierung.

2. Einen frischen Ausführer entsenden

Starte einen frischen Sol-Arbeiter mit Besitz nur der Dateien und der Verantwortung des Aufgabenpakets. Sage ihm, dass andere Arbeiten im Codebestand existieren können und dass er nicht zusammenhängende Änderungen bewahren muss.

Gib ihm:

• das genaue Aufgabenpaket;
• den Arbeitsbereichspfad und anwendbare Repository-Anweisungen;
• die ursprünglichen Einschränkungen, die benötigt werden, um Scope-Drift zu vermeiden; und
• explizit angeforderte using=-Skills.

Gib ihm keine Verifizierer-Befugnis. Fordere ihn auf, eine sinnvolle Arbeitseinheit zu implementieren, verhältnismäßige Prüfungen durchzuführen und nur die Ausführer-Quittung zurückzugeben. Lasse ihn nicht die Rubrik oder den temporären Zustand aktualisieren.

Verhindere, dass Verifizierungs- und Build-Befehle beiläufige Caches, Logs, Coverage-Ausgaben oder andere Nicht-Produktartefakte im Zielarbeitsbereich hinterlassen. Leite dispositive Ausgabe in ein unabhängig erstelltes OS-temporäres Verzeichnis um, wenn unterstützt. Andernfalls entferne nur genaue dispositive Artefakte, die durch diese Zuweisung erstellt wurden und deren Herkunft sicher ist; lösche niemals einen bereits existierenden oder mehrdeutigen Pfad.

Routiniere Denkaufwand wie folgt, wenn die Laufzeitumgebung Modell-Overrides unterstützt:

• mechanische, eng abgegrenzte Ausführung: gpt-5.6-sol mit low;
• gewöhnliche Implementierung: gpt-5.6-sol mit medium;
• bereichsübergreifende oder riskante Implementierung: gpt-5.6-sol mit high.

Commite oder pushe nicht, es sei denn, das Ziel fordert diese Aktionen explizit an.

3. Einen frischen blinden Verifizierer entsenden

Starte einen frischen schreibgeschützten Sol-Verifizierer mit high Denkaufwand; verwende xhigh für kritische Sicherheits-, Migrations-, Berechtigungs- oder irreversible Arbeiten.

Gib ihm nur:

• das genaue ursprüngliche Ziel und die eingefrorene Rubrik;
• den Arbeitsbereich oder das erstellte Artefakt;
• anwendbare Repository-Anweisungen;
• vom Benutzer vorgeschriebene Verifizierungsbefehle; und
• explizit angeforderte using=-Skills.

Gib ihm nicht das Controller-Ausführungsverzeichnis, das Aufgabenpaket, die Planer-Ausgabe, die Ausführer-Quittung, die Implementierungszusammenfassung, das erwartete Ergebnis, die vorherige Befund-Begründung oder die P/E-Konversationshistorie. Gib dem Verifizierer ein separates OS-temporäres Scratch-Verzeichnis, wenn seine Werkzeuge dispositive Ausgabe benötigen.

Fordere den Verifizierer auf, das aktuelle Produkt unabhängig zu inspizieren, relevante Prüfungen durchzuführen, Teständerungen auf Belohnungs-Hacking zu untersuchen und den Befund-Vertrag zurückzugeben. Der Verifizierer darf Produkt, Tests, Ausführungszustand oder externe Systeme nicht ändern.

4. Kanonischen Zustand aktualisieren

Lasse den Controller die Antwortform validieren, die vollständige Antwort in die Befunddatei der Iteration schreiben und die vom Verifizierer gestützten Status und Nachweise in progress.json kopieren, bevor die nächste Entsendung erfolgt. Interpretiere schwache Nachweise nicht als Bestehen.

• Bei NEEDS_WORK starte die nächste Iteration mit einem neuen Planer.
• Bei PASS entsende einen zusätzlichen frischen endgültigen Verifizierer ohne vorherige Erfüllungsstatus. Fordere ihn auf, jedes Rubrik-Element von Grund auf zu bewerten.
• Bei endgültigem PASS führe die mechanische Prüfung des Controllers auf Rollenisolation, Iterationsanzahl, temporären Zustand und Autorisierungsgrenzen durch. Markiere das native Ziel nur dann als abgeschlossen, wenn beide Gates bestehen.
• Bei endgültigem Fehlschlag fahre fort, wenn Iterationen übrig sind.

Stop-Bedingungen

Stoppe erfolgreich nur, nachdem der frische endgültige Verifizierer jedes Rubrik-Element nachgewiesen hat.

Behandle Produktverifizierung und Orchestrierungsintegrität als separate Gates:

• Produkt-Gate: Ein frischer blinder Endverifizierer beweist die eingefrorene Rubrik.
• Controller-Gate: Maschinenprüfbare Aufzeichnungen beweisen das Iterationslimit, die Frisch-Rollen-Entsendung, den temporären Zustand und das Fehlen unbefugter Commits, Pushes, Veröffentlichungen, Deployments oder destruktiver Aktionen.

Sende keine Fehler der Controller-Buchhaltung an den Produktverifizierer zurück oder mache sie zu Produkt-Rubrik-Elementen. Repariere sichere Buchhaltungsfehler sofort, wenn möglich; melde andernfalls den Controller-Gate-Fehler, ohne Fertigstellung zu beanspruchen.

Am Iterationslimit:

• beanspruche keinen Erfolg;
• markiere das Ziel nicht als abgeschlossen oder blockiert, nur weil das Limit erreicht wurde;
• berichte erfüllte Elemente, verbleibende Elemente, entscheidende Nachweise und den genauen temporären Pfad; und
• lasse das Ziel für eine explizite Fortsetzung aktiv.

Markiere ein Ziel nur dann als blockiert, wenn die wiederholte Blockerschwelle der Laufzeitumgebung tatsächlich erfüllt ist. Halte für Benutzereingabe an, wenn Autorisierung, eine materielle Produktentscheidung, fehlende Anmeldeinformationen oder eine nicht verfügbare externe Abhängigkeit einen sicheren Fortschritt verhindern.

Wiederherstellung

Wenn das temporäre Verzeichnis verschwindet, erstelle ein neues und rekonstruiere das Ziel und die eingefrorene Rubrik aus dem aktiven Thread-Ziel und der Konversation. Behandle alle vorherigen Erfüllungen als unbewiesen, führe dann einen frischen vollständigen Verifizierer aus, bevor du fortfährst.

Wenn ein Subagent fehlschlägt:

• wiederhole eine kritische P-, E- oder V-Rolle einmal mit derselben Isolationsgrenze;
• ersetze niemals einen fehlenden Verifizierer-Befund durch das Urteil des Controllers;
• verkleinere eine zu große Arbeitseinheit durch einen neuen Planer;
• bewahre nicht zusammenhängende Arbeitsbereichsänderungen; und
• melde Lücken ehrlich, wenn das Iterationslimit eine Wiederherstellung verhindert.

Finale Qualitätsprüfung

Bevor du Erfolg zurückmeldest, bestätige:

• der primäre Agent handelte nur als Controller;
• jede Rolle verwendete frischen isolierten Kontext;
• kein Agent bewertete seine eigene Ausgabe;
• der Verifizierer sah keine P/E-Überlegungen oder erwarteten Ergebnisse;
• jedes Rubrik-Element hat aktuelle, direkte Nachweise vom endgültigen Verifizierer;
• bestehende Tests wurden nicht abgeschwächt, um Erfolg zu erzeugen;
• beiläufige Befehlsartefakte, die durch den Workflow erstellt wurden, verbleiben nicht im Zielarbeitsbereich;
• der Ausführungszustand existiert nur unter dem aufgezeichneten OS-temporären Verzeichnis;
• kein Ausführungszustand wurde in das Projekt committed oder kopiert; und
• das native Ziel wurde, wenn verfügbar, erst nach endgültigem PASS als abgeschlossen markiert.