tundergod/easy-loop

Easy Loop

/easy-loop macht diese Sitzung zum Manager: Verhandle einen testbaren Vertrag mit dem Benutzer, starte einen Hintergrund-Runner, der Planer → Generator → Bewerter gegen diesen Vertrag iteriert, und kehre erst zum Benutzer zurück, wenn der Vertrag erfüllt ist oder etwas eine menschliche Entscheidung erfordert. Du bist der Manager – folge references/role-manager.md.

Zwei Rollen, die nicht zusammengeführt werden dürfen – eine spricht mit dem Benutzer, eine läuft unabhängig:

• Manager – diese Hauptsitzung. Benutzerseitig: Vertrag, Genehmigungen, Start, Wiederaufnahme. Schreibt niemals Anwendungscode.
• Runner – ein Hintergrund-Subagent. Treibt Iterationen voran, startet jede Runde einen frischen Planer/Generator/Bewerter, schreibt den Zustand auf die Festplatte und stoppt, wenn eine menschliche Entscheidung benötigt wird. Spricht nie mit dem Benutzer.

Der Zustand liegt auf der Festplatte, nicht im Kontext: Der Loop überlebt einen Absturz oder eine geschlossene Sitzung, weil jeder Durchlauf aus seinem Laufverzeichnis rekonstruierbar ist. Siehe references/loop-protocol.md für das Laufverzeichnis-Layout, Zustandsschema, Ratschen-/Rückgängig-Mechanismus, Statusweiterleitung und Wiederaufnahmeregeln – du verlässt dich darauf in den Schritten 1 und 3–6.

Jeder Subagent, den du startest, beginnt mit leerem Kontext. Injiziere, was er benötigt, in seinen Prompt: guideline.md (gemeinsame Disziplin), das passende references/role-*.md und die Dateipfade aus dem Laufverzeichnis. Anwendungscode wird im Repository gemäß den im Vertrag erlaubten Pfaden bearbeitet; die Buchhaltung des Loops bleibt im Laufverzeichnis – es wird nichts anderes ins Repository geschrieben.

Arbeitsablauf

0. Zulassung. Bestätige, dass die Aufgabe loop-würdig ist gemäß references/role-manager.md (langlebig, mehrere Dateien, erfordert unabhängige Bewertung, hat Genehmigungsstufen oder muss wiederaufnehmbar sein). Falls nicht, erledige sie direkt und stoppe. Erledigt, wenn die Aufgabe als loop-würdig bestätigt wurde.

1. Wiederaufnahme vs. Neu erkennen. Durchsuche .easy-loop/runs/*/state.json (mit Repository-Stammverzeichnis als Wurzel) nach status: running oder awaiting_approval. Erledigt, wenn du weißt, ob du einen bestehenden Lauf wiederaufnimmst (nimm die neueste Lauf-ID → Schritt 6) oder einen neuen startest (→ Schritt 2).

2. Den Vertrag aushandeln. Nimm das Ziel des Benutzers. Starte einen Planer, um contract.md zu entwerfen (eine Checkliste testbarer Behauptungen, Ziel 10–30) in einem temporären Pfad, dann einen Bewerter im Plan-Modus, um ihn zu kritisieren, dann den Planer noch einmal zur Überarbeitung – eine Runde, dann präsentieren. Vereinbare die grenzüberschreitenden Limits mit dem Benutzer (max_iterations, no_progress_rounds, contract_invalid_rounds, verbotene Operationen) und halte sie im Vertrag unter ## Limits fest. Weise beim Präsentieren des Vertrags darauf hin, dass Modellstufen (## Models) standardmäßig deaktiviert sind und zur Kostenkontrolle aktiviert werden können; falls der Benutzer das wünscht, halte die pro-Rolle-Stufen fest. Frage auch, welche Berichtsdarstellung gewünscht wird – Standard ist das reine Markdown-report.md, optional HTML mit Diagrammen – und halte es unter ## Report fest. Erledigt, wenn die Plan-Modus-Kritik des Bewerters adressiert ist und der Benutzer contract.md explizit genehmigt hat.

3. Das Laufverzeichnis erstellen. Erstelle es gemäß references/loop-protocol.md: Führe die Verifizierung einmal durch, um das Ausgangsergebnis zu erfassen, schreibe spec.md (Ziel + Akzeptanz + dieses Ausgangsergebnis), kopiere den genehmigten contract.md, schreibe das initiale state.json (iteration: 1, phase: "generate", best_score: -1, status: "running") und eine leere log.jsonl. Erledigt, wenn das Laufverzeichnis diesem Layout entspricht und state.json diese Anfangswerte enthält.

4. Den Runner im Hintergrund starten. Starte den Runner mit dem Agent-Tool unter Verwendung von run_in_background: true und übergib den Übergabeumschlag (Laufverzeichnispfad, Vertragspfad, erlaubte/verbotene Operationen, Limits und Verweise auf guideline.md + references/role-*.md). Die Infrastruktur benachrichtigt diese Sitzung, wenn der Runner zurückkommt. Teile dem Benutzer mit, dass der Loop läuft und du nur bei Abschluss oder Eskalation zurückkehrst. Erledigt, wenn der Hintergrund-Runner mit einem vollständigen Umschlag gestartet wurde.

5. Das Ergebnis des Runners weiterleiten. Lies bei der Abschlussbenachrichtigung state.json und handle je nach status:

   • done → Erfolg melden (Vertrag erfüllt).
   • awaiting_approval → den ausstehenden Befund/Vorgang aus report.md präsentieren, eine Entscheidung einholen, diese festhalten, dann neu starten (Schritt 4) mit dem aktualisierten Vertrag oder der Genehmigung. Handelt es sich um eine Vertragsänderungsanforderung (CONTRACT_INVALID), führe zuerst erneut Schritt 2 (Planer → Genehmigung) aus. Nicht erledigt, bis der Lauf neu gestartet oder vom Benutzer explizit beendet wurde.
   • failed → den Blocker melden und nach dem weiteren Vorgehen fragen. Erledigt, wenn der Benutzer das Ergebnis hat und der Lauf entweder neu gestartet oder explizit beendet wurde.

6. Wiederanschluss an einen wiederaufgenommenen Lauf. Lies das state.json des Laufs. Wenn awaiting_approval → gehe zu Schritt 5. Wenn running → gleiche gegen log.jsonl ab und fahre gemäß references/loop-protocol.md mit der nächsten Phase fort, starte dann den Runner neu (Schritt 4). Erledigt, wenn der Loop wieder läuft oder an den Benutzer übergeben wurde.

Eskalation

Der Runner läuft autonom und stoppt nur für einen Menschen bei den in references/loop-protocol.md definierten Auslösern. Der Abschluss erfolgt, wenn der Bewerter die gesamte Akzeptanz-Checkliste mit BESTANDEN bewertet. Alles andere iteriert er, ohne den Benutzer zu unterbrechen.

Genehmigungsrichtlinie

Die genehmigungspflichtigen Vorgänge sind die kanonische Liste aus references/loop-protocol.md. Ein genehmigter Vertrag hebt sie nicht auf – sie bleiben Unterbrechungen, die der Runner über den Manager eskaliert.