Codex AutoLoop

Was macht Codex AutoLoop?

Führen Sie langlaufende Entwicklungsaufgaben als einen wiederherstellbaren, auditierbaren, abgesicherten und rechtzeitig stoppenden Workflow aus.

Wann verwenden

Aktivieren Sie diese Fähigkeit bei Anfragen wie:

• „Fortlaufende Entwicklung / automatische Schleife / Hintergrundausführung“
• „Nicht aufhören, erst melden, wenn fertig“
• „Ich lege mich schlafen, mach du weiter“
• „Fortschritt gemäß CSV-Aufgabenliste“
• „Der plan.md Schritt für Schritt folgen“
• „Codex / Claude Code über längere Zeit selbstständig iterieren lassen“
• „Workaholic-Modus“

Wenn es sich um eine sehr kleine Aufgabe handelt, die in wenigen Minuten erledigt ist, zwingen Sie nicht AutoLoop auf, sondern erledigen Sie sie direkt auf normalem Wege.

Kernprinzipien

Die Hauptschleife ist einfach:

1. Zuerst den aktuellen Kontext lesen
2. Eine klar abgegrenzte kleine Aufgabe / eine einzelne Hypothese auswählen
3. Eine interpretierbare atomare Änderung vornehmen
4. Das Ergebnis mechanisch verifizieren
5. Bei Bestehen beibehalten, bei Nichtbestehen zurücksetzen
6. Status und Ergebnis aufzeichnen
7. Fortfahren, bis ein Stoppkriterium ausgelöst wird

Nutzen Sie Git und die Statusdatei als Gedächtnis und die Verifikation als Schutzzaun. Betrachten Sie die Verifikation nicht als „die Wahrheit an sich“.

Zwei Betriebsmodi

Modus A: Einzelziel-Schleife

Geeignet für Aufgaben mit sehr klarem Ziel und klaren Metriken, z. B.:

• Reduzieren von any in einem bestimmten Verzeichnis
• Eine Gruppe von Tests auf grün bringen
• Kontinuierliche Optimierung eines Benchmarks
• Erhöhung der Abdeckung einer bestimmten Funktionalität

Modus B: CSV / Plan-gesteuerte Lieferung

Geeignet für eine Reihe von Backlog-Aufgaben, die bereits Folgendes haben:

• Prioritäten
• Abhängigkeiten
• Abnahmekriterien
• Verifikationsbefehle
• Änderungsbereich

Bei Bedarf lesen Sie:

• references/csv-template.md: Wie die Aufgabentabelle geschrieben wird
• references/plan-template.md: Wie der Plan als maschinenausführbarer Vertrag geschrieben wird

Prüfungen vor dem Start

Starten Sie keine lange Schleife, wenn diese Bedingungen nicht erfüllt sind:

• Das Repository ist bereits unter Git
• Der Basis-Verifikationsbefehl wurde manuell einmal erfolgreich ausgeführt
• Die erlaubten Änderungspfade sind klar
• Die Pfade, die niemals berührt werden dürfen, sind klar
• Status-/Ergebnisdateien werden nicht versehentlich committet
• Der Benutzer hat explizit „autonomes Vorantreiben / Hintergrundausführung / langes Laufen“ gewünscht

Stoppkriterien

Standardmäßig wird fortgefahren, aber bei folgenden Situationen muss angehalten und Bericht erstattet werden:

1. Gate-Fehler: Das vollständige Gate / Review-Gate ist fehlgeschlagen
2. Anforderungsmehrdeutigkeit: Es tauchen mehrere sinnvolle Produktentscheidungen auf, aber der Plan/die Aufgabe enthält keine Entscheidungsregeln
3. Gefährliche Aktionen: Löschen von Datenbanken, Migrationen, Umgang mit Anmeldeinformationen, Seiteneffekte in der Produktion, externe Schreiboperationen
4. Verifikationsdrift: Die Verifikation repräsentiert nicht mehr wirklich die „Aufgabenerfüllung“
5. Anhaltende Fehler: Nach mehreren Runden von Verwerfen/Abstürzen gibt es immer noch keine neue Hypothese
6. Scope-Überschreitung: Die zu ändernden Inhalte überschreiten den definierten Bereich
7. Menschlicher Checkpoint: Der Benutzer hat explizit gesagt, dass er zuerst sehen möchte

Glauben Sie nicht blind an „niemals stören“. Das richtige Prinzip ist:

Standardmäßig autonom vorantreiben, aber bei Risiko, Mehrdeutigkeit oder Scope-Überschreitung sofort eskalieren.

Einzelrunden-Ausführungsprotokoll

Führen Sie in jeder Runde Folgendes durch:

1. Die relevanten In-Scope-Dateien, letzten Ergebnisse und letzten Git-Verläufe erneut lesen
2. Nur eine Aufgabe oder eine atomare Hypothese auswählen
3. Minimale verifizierbare Änderung vornehmen
4. Den zugehörigen Verifikationsbefehl für diese Aufgabe ausführen
5. Bestanden: Änderung beibehalten und Ergebnis aufzeichnen
6. Fehlgeschlagen: Sauber zurücksetzen und Fehlergrund aufzeichnen
7. Prüfen, ob ein Stoppkriterium ausgelöst wurde
8. Mit der nächsten Runde fortfahren

Aufgaben, die stark experimentell sind und viele Versuche erfordern, sollten vorzugsweise in temporären Branches / unabhängigen Arbeitsbereichen durchgeführt werden. Machen Sie den Hauptbranch nicht zu einer Experimentiermüllhalde.

Anforderungen an das Verifikationsdesign

Ein guter Verifikationsbefehl sollte Folgendes erfüllen:

• Mechanisiert: Möglichst wenig subjektive Beurteilung erforderlich
• Schnell genug: Geeignet für wiederholte Ausführung
• Schwer zu betrügen: Nicht leicht durch „Metriken-Tuning“ zu täuschen
• Nahe an der Abnahme: Möglichst nahe am tatsächlichen Fertigstellungsstandard
• Unbeaufsichtigt: Auch im unbeaufsichtigten Modus sicher ausführbar

Wenn Sie eine Verifikation entwerfen oder reparieren müssen, lesen Sie:

• references/verify-scripts.md

Git / Rückfallprinzipien

Git ist das Gedächtnis, nicht die universelle Sicherung.

Bevorzugen Sie diese Methoden gegenüber groben History-Rewrites:

• Scratch-Branch
• Worktree
• Reversible Commit-Sequenzen
• Bereichsbezogener Revert

Führen Sie Aufgaben nicht leichtfertig parallel aus, nur weil ihre glob-Muster sich nicht zu überschneiden scheinen. Gemeinsame Typen, Konfigurationen, Build-Prozesse und Test-Snapshots können trotzdem kollidieren.

Praxistipps für OpenClaw / Codex

In Umgebungen, die Sessions / Sub-Agenten / ACP-Harness unterstützen:

• Kleine Aufgaben: Direkt in der aktuellen Session erledigen
• Lange Aufgaben: In einer isolierten Session laufen lassen
• Explizite Ausführung im Stil von Codex / Claude Code / Gemini: Die entsprechende Harness / persistenten Thread verwenden
• Nicht häufig den Fortschritt abfragen, sondern auf Checkpoints und Fertigstellungsrückmeldungen setzen
• Vorzugsweise vom Zustand aus wiederherstellen, nicht nach jeder Unterbrechung neu planen

Bei Bedarf lesen:

• references/openclaw-execution.md: Empfohlene Vorgehensweise für OpenClaw / verwaltete Sessions
• references/python-launcher.md: Referenz für lokale DIY-Launcher

Empfohlene Lesereihenfolge

Nur schnell starten

1. Diese Datei
2. references/openclaw-execution.md
3. references/verify-scripts.md

Aufgaben stapelweise vorantreiben

1. Diese Datei
2. references/csv-template.md
3. references/plan-template.md
4. references/openclaw-execution.md

Launcher selbst anpassen

1. Diese Datei
2. references/python-launcher.md
3. references/verify-scripts.md

Abschließend merken

Das Ziel ist nicht „für immer laufen lassen“.

Das Ziel ist:

• So wenig Babysitting wie möglich
• Der Prozess ist nachvollziehbar
• Bei Problemen kann wiederhergestellt werden
• Anhalten, wenn es nötig ist
• Das Endergebnis ist wirklich lieferbar

Autonomous by default. Interruptible by design.