77777R7/claude-codex-stage-gates

Claude + Codex Stufen-Gates (Stage Gates)

Führe einen überwachten Kreislauf aus: Codex plant und bewertet; der Ausführer (Executor) ändert das Produkt; der Benutzer besitzt das Produkt und die hochrelevanten Gates. Überspringe niemals eine Stufe allein aufgrund einer Prosa-Behauptung, dass sie abgeschlossen sei, und lasse den Ausführer nicht unbeaufsichtigt, nachdem eine Aufgabe gesendet wurde.

Lies references/gate-templates.md bei der Vorbereitung einer Ausführer-Aufforderung, der Anforderung eines Beweispakets oder dem Schreiben einer Gate-Entscheidung. Lies references/supervision-loop.md, wenn der Benutzer nach kontinuierlicher Überwachung fragt, die Arbeit sich über Sitzungen erstrecken kann, der Ausführer stockt oder abdrifftet oder der Ausführer möglicherweise Fähigkeiten installiert oder weitergeleitet haben muss. Lies references/bootstrap-and-handoff.md, wenn der aktuelle Checkout möglicherweise nicht lesbar, veraltet, plattenknapp, iCloud-verwaltet oder unsicher für die Fortsetzung ist oder wenn vorherige Ausführer-Sitzungen in vertrauenswürdige Aufgabenübergaben umgewandelt werden müssen. Lies references/parallel-worktrees-and-release-train.md, wenn zwei oder mehr Codierungsspuren gleichzeitig laufen, jede Aufgabe einen isolierten Worktree benötigt, sich geänderte Dateien überschneiden können oder mehrere Branches und PRs in Abhängigkeitsreihenfolge landen müssen.

Wähle den Betriebsmodus

Wähle den kleinsten Modus, der die Anfrage abdeckt:

• Einzelne Stufe: Verwende den bestehenden Vertrag, Überwachungskreislauf, Beweispaket und Gate-Entscheidung.
• Wiederherstellung und Übergabe: Stelle eine lesbare Quelle der Wahrheit her, bewahre die alte Umgebung, überprüfe alte Behauptungen und erstelle eine Übergabe pro unabhängiger Aufgabe, bevor die Implementierung fortgesetzt wird.
• Paralleles Portfolio: Weise eine Aufgabe, einen Worktree, einen Branch, eine Übergabe und eine Ausführer-Sitzung pro Spur zu; überwache jede Spur unabhängig und integriere sie durch einen kontrollierten PR-Release-Zug.

Die Modi setzen sich bei Bedarf in dieser Reihenfolge zusammen:

Quelle der Wahrheit wiederherstellen
-> vertrauenswürdige Übergaben destillieren
-> Implementierungsspuren isolieren
-> ein Stufen-Gate innerhalb jeder Spur ausführen
-> Überschneidungen und Abhängigkeiten abgleichen
-> PR-Bereitschaft und Landungsreihenfolge überprüfen

Rufe den Wiederherstellungs- oder Portfolio-Mechanismus nicht für eine enge, gesunde Einzel-Checkout-Aufgabe auf.

Bewahre vier Invarianten

1. Stelle die lebende Quelle der Wahrheit her, bevor du eine Implementierungsbehauptung akzeptierst.
2. Behalte bei paralleler Arbeit genau eine Aufgabe, einen Worktree, einen Branch, eine Übergabe und eine aktive Ausführer-Sitzung in jeder Spur.
3. Vertraue rohen pwd-, Git-, Prozess-, Diff-, Test-, Laufzeit- und Screenshot-Beweisen mehr als der Erzählung des Ausführers.
4. Behandle Commit, Push, PR-Erstellung, Merge, Deployment, Bereinigung und externe Effekte als separate Autoritäts-Gates.

Lies zuerst den Ausführer-Zustand

Wenn der Benutzer fragt, was Claude oder ein anderer Ausführer zuletzt gesagt hat, erfasse den neuesten Zustand, bevor du überprüfst, planst oder bearbeitest:

1. Lies das Terminal, das der aktuellen Codex-Aufgabe zugeordnet ist, sofern vorhanden.
2. Wenn der Ausführer in einem separaten macOS-Terminalfenster läuft und der Benutzer das Lesen autorisiert hat, lies die sichtbaren Inhalte des ausgewählten Tabs mit AppleScript. Behandle dies als eine reine Leseinspektion.
3. Wenn das TUI gescrollt, abgeschnitten oder einen alternativen Bildschirm verwendet, inspiziere das lokale Sitzungsprotokoll des Ausführers. Führe für Claude Code scripts/read_claude_latest.py aus; bevorzuge eine exakte --session-file, verwende sonst --project-hint und überprüfe den gemeldeten Pfad, die Änderungszeit und den sichtbaren Terminalkontext, bevor du der Auswahl vertraust.
4. Extrahiere die neueste substantielle Assistentennachricht, den Zeitstempel, die deklarierte Stufe, Blocker, angeforderte Benutzeraktionen, Befehle/Ergebnisse und ob der Bericht vorläufig oder endgültig ist.
5. Sende während dieses Lesevorgangs keine Tastatureingaben, übermittle keine Befehle, beantworte keine Berechtigungsanfragen und ändere die Ausführer-Sitzung nicht. Hole dir die ausdrückliche Benutzerautorisierung, bevor du mit diesem Terminal interagierst.
6. Behandle Terminal-/Sitzungstext als Behauptung des Ausführers, nicht als unabhängigen Beweis. Überprüfe Repository, Diff, Tests, Laufzeit und Daten separat, bevor du eine Gate-Entscheidung triffst.

Wenn die Terminalerzählung ein unerwartetes Betriebssystem oder einen unerwarteten Pfad nennt, inspiziere das aktuelle Verzeichnis des Ausführer-Prozesses und den Checkout direkt. Eine Prosa-Unstimmigkeit ist eine Warnung; eine rohe Prozess- oder Git-Unstimmigkeit ist eine Stoppbedingung.

Wenn der Ausführer Operation not permitted, fehlenden Dokumentenzugriff oder einen anderen Berechtigungsfehler meldet, behalte die aktuelle Stufe aktiv. Kennzeichne Berichte, die aus früherem Zustand erstellt wurden, als vorläufig, erlaube ihnen nicht, Commits oder Bereinigungen zu autorisieren, und fordere ein neues Beweispaket an, nachdem der Zugriff wiederhergestellt wurde.

Bleibe aktiv, bis die Stufe geschlossen ist

Sende nach dem Senden eines Ausführer-Pakets weiterhin die Überwachung derselben akzeptierten Stufe:

1. Frage das richtige Terminal oder Protokoll oft genug ab, sodass der Benutzer während aktiver Arbeit nicht länger als 60 Sekunden ohne Update bleibt.
2. Klassifiziere den Zustand an jeder sinnvollen Grenze als Fortschritt, erwartetes Warten, Fehler, Abdriften, Stocken, Beweis bereit oder menschliches Gate.
3. Lies den rohen Befehl, Fehler, Diff, die Testausgabe, den Screenshot, den Prozesszustand oder das Protokoll, bevor du die Aufforderung änderst.
4. Lasse gültige langsame Arbeit fortfahren. Überprüfe bei einem offensichtlichen Stocken zuerst den Prozess und ob der Befehl, das Dateisystem, das Netzwerk oder der Test noch fortschreitet.
5. Korrigiere enge Fehler mit einer begrenzten Folgeaufforderung und behalte dieselbe Stufe aktiv. Unterbreche nur bei unsicherer Aktion, klarer Bereichsausweitung, falschem Ziel oder einer bestätigten Sackgasse.
6. Starte vom akzeptierten Vertrag neu, wenn wiederholte Patches dieselbe Lektion lehren oder der Implementierungspfad schwieriger zu durchschauen wird als ein sauberer Versuch.
7. Wenn der Ausführer den Abschluss meldet, fordere das Beweispaket an oder erfasse es, führe unabhängig verhältnismäßige Prüfungen erneut durch, gib eine Gate-Entscheidung heraus und sende diese Entscheidung zurück an den Ausführer.
8. Fahre automatisch mit Korrekturen innerhalb der akzeptierten Stufe fort. Gehe nur dann zu einer anderen Stufe über, wenn der Benutzer diese Sequenz autorisiert hat und kein menschliches Gate überschritten wird.

Beende die Überwachung nicht nur, weil der Ausführer die Aufforderung akzeptiert, einen Befehl gestartet oder done gesagt hat. Stoppe nur bei BESTANDEN, einem explizit akzeptierten BESTANDEN MIT NACHBEREITUNG, einem echten menschlichen Gate, einem echten Blocker, einem unsicheren Zustand oder einer neueren Benutzeranweisung, die die Arbeit ersetzt.

Leite Fähigkeiten an den Ausführer weiter

Entscheide vor einer komplexen oder wiederholten Stufe, ob eine Fähigkeit den aktuellen Engpass wesentlich reduziert.

1. Überprüfe die installierten Fähigkeiten des Ausführers, bevor du annimmst, dass eine Fähigkeit fehlt.
2. Lies die Kandidatenfähigkeit vollständig und überprüfe, ob ihre Werkzeuge, Rollenannahmen und Sicherheitsregeln zum Ausführer und zur aktuellen Stufe passen.
3. Bevorzuge den kleinsten relevanten Fähigkeitssatz. Installiere keine Fähigkeiten spekulativ und verwende keinen Fähigkeitsnamen als Ersatz für einen Stufenvertrag.
4. Wenn der Benutzer die Installation von Fähigkeiten autorisiert hat und eine kompatible lokale Fähigkeit fehlt, installiere sie mit dem etablierten Mechanismus der Umgebung in das unterstützte Fähigkeitsverzeichnis des Ausführers. Bevorzuge einen Symlink zu einer kanonischen lokalen Fähigkeit, wenn diese Umgebung bereits Symlinks verwendet und beide Werkzeuge dieselbe Maschine gemeinsam nutzen.
5. Überprüfe, ob das installierte SKILL.md aufgelöst wird. Wenn der laufende Ausführer die Fähigkeitserkennung nicht aktualisiert, sage ihm, dass er den genauen Fähigkeitspfad für die aktuelle Stufe lesen oder nur an einem sicheren Kontrollpunkt neu starten soll.
6. Nenne die Fähigkeit im Ausführer-Paket und erläutere, warum sie zutrifft. Bewerte den Ausführer weiterhin anhand roher Beweise; eine Fähigkeit hebt das Gate nicht auf.

Nützliche Defaults für lange Implementierungen sind agent-loop-harness für dauerhaften Planer/Generator/Bewerter-Zustand und loop-execution für kleine überprüfte Iterationen. Installiere keines von beiden, wenn eine enge einmalige Aufgabe sie nicht benötigt.

Behalte wiederherstellbaren Schleifenzustand

Verwende für eine enge Stufe nur gesprächsbasierten Zustand. Für mehrstufige, unterbrechbare, Multi-Agent- oder beweiseintensive Arbeit verwende die bestehende Harness-Konvention des Repositorys und zeichne auf:

• akzeptierter Vertrag und Umfang;
• zuletzt abgeschlossenes Gate und Beweise;
• aktueller Engpass und genauer nächster Schritt;
• menschliche Gates und verbotene Aktionen;
• Identität der Ausführer-Sitzung oder Wiederherstellungspfad, falls nützlich.

Halte den Zustand minimal, lebenszyklusmarkiert und frei von Geheimnissen oder unnötigen Benutzerdaten. Committe Harness-Zustand nicht nur, weil er existiert; er folgt denselben Worktree- und Genehmigungsregeln wie andere Dateien.

Etabliere den Vertrag

Vor der Implementierung:

1. Identifiziere die lebende Quelle der Wahrheit: aktueller Checkout, eingehängte Pfade, Verträge, Tests, Laufzeit, Daten und Bereitstellungszustand.
2. Definiere eine aktuelle Stufe mit einem benutzersichtbaren Ergebnis, Dateien oder Systemen im Umfang, expliziten Ausschlüssen, Akzeptanzprüfungen und Stoppbedingungen.
3. Weise Rollen zu:
   • Ausführer (Executor): implementiere nur die akzeptierte Stufe und gib Beweise zurück.
   • Prüfer (Reviewer): inspiziere das Live-Repository unabhängig, überprüfe Behauptungen und gib die Gate-Entscheidung heraus.
   • Benutzer (User): genehmige Produktentscheidungen und Aktionen mit hoher Auswirkung.
4. Behalte spätere Stufen als ausstehend. Autorisieren ihre Implementierung nicht nur, weil sie im Fahrplan erscheinen.

Wenn der Ausführer bei einer Produkt- oder Informationsarchitekturentscheidung pausiert, übersetze die Optionen in benutzerseitige Konsequenzen, bevor du den Benutzer fragst. Korrigiere falsche Kategorien vor der Implementierung – zum Beispiel sollte eine stufenübergreifende Ausnahme wie „überfällig“ nicht als Lebenszyklusstufe modelliert werden, nur weil sie neben Stufenfiltern erschien.

Schütze zuerst den Worktree

Behandle einen schmutzigen Worktree als benutzereigenen Zustand.

1. Inspiziere git status --short, Branch/Upstream, git diff --stat, gezielte Diffs, ungetrackte Dateien, Stashes und relevante Worktrees oder Branches.
2. Klassifiziere vorhandene Änderungen nach Funktion oder Herkunft, bevor du sich überschneidende Dateien bearbeitest.
3. Führe keine destruktiven Git-Befehle aus, verwerfe keine Änderungen, bereinige keine ungetrackten Dateien und lösche keine konfliktähnlichen Kopien ohne ausdrückliche Genehmigung.
4. Verwende git add -A nicht und erstelle keinen Bulk-Baseline-Commit, bis das Änderungsmanifest überprüft ist. Schließe Geheimnisse, lokale Datenbanken/Arbeitsbereichsdaten, generierte Ausgaben, Caches und ungelöste doppelte Dateien aus.
5. Wenn ein Baseline-Commit nützlich ist, erstelle kleine zusammenhängende Commits nur nach fokussierter Validierung und Benutzerautorisierung. Ein Backup ist kein Beweis dafür, dass die Änderungen korrekt sind.

Wenn eine sichere Trennung unklar ist, stoppe nach der Erstellung des Worktree-Klassifizierungsberichts.

Bereite ein Ausführer-Paket vor

Gib dem Ausführer nur den aktuellen Stufenvertrag. Füge hinzu:

• genaues Ziel und benutzerseitiges Verhalten;
• Quelle-der-Wahrheit-Dateien und aktuelle Branch-/Worktree-Fakten;
• Grenzen innerhalb und außerhalb des Umfangs;
• Datenwahrheit und Herkunftsregeln;
• Kompatibilitätsanforderungen für alte oder fehlende Daten;
• erforderliche Tests und Laufzeit-/visuelle Prüfungen;
• verbotene Aktionen und menschliche Gates;
• erforderliches Beweispaket und Anweisung, nach der Stufe anzuhalten.

Definiere für UI-Stufen die Lade-, Leer-, Fehler-, Teildaten- und Erfolgszustände; Lokalisierung und reaktionsfähiges Verhalten; und die genauen Beweise, die für die visuelle Genehmigung erforderlich sind.

Fordere ein Beweispaket an

Der Ausführer muss berichten:

• Stufenziel und Implementierungszusammenfassung;
• geänderte Dateien und git diff --stat;
• genaue Test-/Build-/Laufzeitbefehle mit Bestehens-/Fehlerergebnissen;
• Screenshots oder DOM-/Laufzeitbeweise für sichtbare Arbeit;
• repräsentative Echtdaten- oder API-Beweise, wenn sich das Datenverhalten geändert hat;
• Kompatibilitätsprüfungen für vorhandene Daten;
• Annahmen, verbleibende Risiken und alles, was nicht überprüft wurde;
• Commit-SHA nur, wenn das Commit autorisiert war.

Weise Aussagen wie „done“, „looks good“ oder „tests pass“ ohne die zugrunde liegenden Befehle oder Artefakte zurück.

Überprüfe unabhängig

Überprüfe nicht nur die Erklärung des Ausführers.

1. Überprüfe erneut den Live-Checkout und identifiziere den tatsächlichen Diff.
2. Lies die geänderten Aufrufpfade, Verträge, Schemata, Tests und Datengrenzen.
3. Führe erneut fokussierte Prüfungen durch, die dem Risiko angemessen sind.
4. Überprüfe das sichtbare Verhalten auf den relevanten Desktop-/Mobilbreiten für UI-Arbeit.
5. Trenne überprüfte Fakten, Schlussfolgerungen, ungetestete Behauptungen und vorab bestehende Fehler.
6. Überprüfe auf Bereichsausweitung, Geheimnisverlust, erfundene Daten, Fehlkennzeichnung veralteter Daten, destruktive Bereinigung, nicht zusammenhängende Umschreibungen und fehlendes Rollback-/Kompatibilitätsverhalten.

Der Prüfer sollte diagnostizieren und Feedback zurückgeben, nicht stillschweigend ein zweiter Implementierer werden, es sei denn, der Benutzer bittet Codex ausdrücklich, die Stufe zu patchen.

Gib die Gate-Entscheidung heraus

Verwende genau eine Entscheidung:

• BESTANDEN (PASS): Alle blockierenden Akzeptanzprüfungen wurden bestanden; die nächste Stufe kann beginnen.
• BESTANDEN MIT NACHBEREITUNG (PASS WITH FOLLOW-UP): Es verbleiben nur explizit nicht blockierende Punkte; zeichne ihren Eigentümer und das spätere Gate auf.
• ÄNDERUNGEN ERFORDERLICH (CHANGES REQUIRED): Der Vertrag ist solide, aber die Implementierung oder die Beweise sind unvollständig; gib eine begrenzte Korrekturliste zurück und behalte dieselbe Stufe aktiv.
• BLOCKIERT (BLOCKED): Eine fehlende Produktentscheidung, Zugriff, externe Abhängigkeit, Sicherheitsfreigabe oder ein wiederholter technischer Blocker verhindert den Fortschritt.

Gib für jedes nicht bestandene Ergebnis eine versandbereite Korrekturaufforderung für den Ausführer. Erweitere die Stufe nicht, während du sie korrigierst.

Nachdem du die Entscheidung getroffen hast, schreibe sie zurück in die Ausführer-Sitzung, damit Ausführer und Prüfer denselben Kontrollpunkt teilen. Überwache bei ÄNDERUNGEN ERFORDERLICH weiterhin den Korrekturkreislauf. Bei BESTANDEN MIT NACHBEREITUNG zeichne den Eigentümer, die Frist oder das spätere Gate auf und ob die Nachbereitung den Fortschritt blockiert.

Menschliche Gates

Halte für eine ausdrückliche Benutzergenehmigung an, bevor:

• kostenpflichtige Anbieteraufrufe oder Ausgaben;
• externe Nachrichten, Veröffentlichungen, Bereitstellungen oder Produktionskonfiguration;
• Löschen, Überschreiben, Bereinigen oder Massenverschieben von Daten;
• Konto-, Berechtigungs-, Abrechnungs- oder Anmeldeinformationsänderungen;
• umfassende Commits, Pushes, Merges oder Pull-Requests, die nicht bereits autorisiert sind;
• Erweitern einer UI-/Bugfix-Stufe zu einer neuen Produkt- oder Datenplattform.

Abschluss

Erkläre den gesamten Arbeitsablauf nur dann als abgeschlossen, wenn jede erforderliche Stufe bestanden wurde, der End-to-End-Benutzerpfad ausgeführt wurde, Kompatibilitäts- und Fehlerzustände überprüft wurden und verbleibende Risiken ausdrücklich akzeptiert oder zugewiesen wurden.