Workflow

Workflow

Die Engineering-Pipeline für echte Projekte:

Spezifikation → Council → Taskgraph → Ausführung in Git-Worktrees → Integration → menschliche Freigabe.

Nichts wird gepusht oder deployed. Release heißt: der lokale Quellbranch wird auf den geprüften Integrationsstand fast-forwarded.

1. Spezifikation

Bevor ein Task startet, muss eine Spezifikation genehmigt sein.

1. Ziel / Aufgabe formulieren, optional Projektordner setzen.
2. Planung: kompakt (Entwürfe + Abschluss) oder ausführlich (plus Kritik und Überarbeitung).
3. Projektumfang: einfach oder größer.
4. Teilnehmer und Vorsitz wählen, Rat einberufen.
5. Ergebnis prüfen: Anforderungen, Nicht-Ziele, Architektur, Risiken, offene Fragen.
6. Offene Fragen beantworten und eine neue Version anfordern — oder genehmigen.

Versionen bleiben erhalten. Eine neuere Version ersetzt die alte (superseded), alte Versuche können archiviert werden.

2. Taskgraph

Nach der Freigabe erzeugt der Rat einen Taskgraphen: einzelne Tasks mit Abhängigkeiten und erlaubtem Dateibereich (Scope). Nur gelistete Pfade darf ein Task ändern.

Den Graphen kannst du neu generieren, wenn die Spec sich geändert hat.

3. Einrichtung vor dem ersten Start

• Projektordner einrichten (leere Ordner werden zu Git; bestehende Repos bleiben bis zur Freigabe unverändert).
• Verbindliche Build-/Testprüfungen setzen. Die App schlägt Befehle anhand des erkannten Stacks vor — prüfen, nicht blind übernehmen.
• Budgets je Task: Modellaufrufe, aktive Minuten, Korrekturen, maximale Versuche.
• Implementer, Reviewer, optional Challenger wählen (lokale CLI-Agenten).

4. Ausführung eines Tasks

Jeder Versuch läuft in einem eigenen Git-Worktree. Implementer schreibt, Reviewer (und optional Challenger) prüfen parallel. Nach bestandener Verification und Review integrierst du bewusst in den projektweiten Integrations-Worktree — dort wird erneut geprüft.

Status	Bedeutung
running	Der Task läuft.
awaiting_permission	Der Agent will mehr Rechte (z. B. Shell). Einmal bestätigen oder ablehnen. Der Scope bleibt danach trotzdem geprüft.
awaiting_install	Ein Prüfbefehl fehlt (ENOENT). Die App schlägt einen Installationsbefehl vor, den du prüfen kannst.
review	Prüfungen und Reviews durch, wartet auf Integration.
paused	z. B. Sitzungslimit. Arbeitsstand bleibt; später am selben Punkt fortsetzen, kein neuer Versuch von vorn.
failed	Prüfung oder Review nicht durch. Neuer Versuch möglich.
escalated	Es braucht eine Entscheidung von dir, oft eine Änderungsanfrage.
accepted / discarded	Integriert bzw. verworfen.

Budgets gelten über Fortsetzungen hinweg. Sind sie leer, pausiert der Task, bis du das Limit bewusst erhöhst.

Bereite Tasks lassen sich nacheinander automatisch starten; die finale Release-Freigabe übernimmt die App nie von allein.

5. Gesamtprüfung und Release

Wenn die Tasks integriert sind:

1. Gesamtprüfungen und finales Council starten.
2. Den konkreten Commit lesen.
3. Release freigeben — erst dann wandert der Stand auf den Quellbranch.

Git-Voraussetzungen

Ordner	Verhalten
Leer	Wird beim Einrichten automatisch zu einem Git-Repository.
Bereits Git mit Historie	Wird weiterverwendet, bis du das Release freigibst.
Dateien vorhanden, aber noch nie ein Commit	Wird abgelehnt. Einmal git init und einen ersten Commit von Hand, dann hier auswählen.

Das gilt für alle Agenten gleich, nicht nur für Codex. Der Coding-Tab braucht kein Git.

Worktrees nach einem Neustart

Workflow-Worktrees bleiben über App-Neustarts hinweg bekannt. Merge und Verwerfen funktionieren deshalb auch, wenn du die App zwischendurch geschlossen hast. Ein laufender Versuch, der beim Beenden nicht sauber enden konnte, gilt nach dem Start als unterbrochen — nicht als weiterlaufend.