Repositoriums-Aufgaben-Nachweis-Schleife

Was macht Repositoriums-Aufgaben-Nachweis-Schleife?

Verwende diese Fähigkeit, wenn der Benutzer einen wiederholbaren, auditierbaren Implementierungs-Workflow für eine nicht-triviale Codierungsaufgabe wünscht, insbesondere für ein Feature, Refactoring, eine Migration oder eine Fehlerbehebung, die einen lokalen Nachweis in .agent/tasks/<TASK_ID>/ hinterlassen soll.

Alle durch diesen Workflow erstellten Aufgaben-Artefakte müssen innerhalb des Repositorys verbleiben.

Wenn in den folgenden Beispielen scripts/task_loop.py erwähnt wird, ist dieser Pfad relativ zu diesem Fähigkeits-Wurzelverzeichnis. Führe es aus, während dein Shell-Arbeitsverzeichnis im Ziel-Repository liegt.

Was diese Fähigkeit tut

1. Initialisiert einen strengen, repo-lokalen Aufgabenordner unter .agent/tasks/<TASK_ID>/
2. Legt die erforderlichen Artefakt-Dateien an oder aktualisiert sie
3. Installiert projektspezifische Codex- und Claude-Subagentenvorlagen in .codex/agents/ und .claude/agents/
4. Aktualisiert die Codex-Baseline AGENTS.md im Repository-Wurzelverzeichnis sowie die Claude-Anleitungsdatei des Repositorys (CLAUDE.md oder .claude/CLAUDE.md) mit einem verwalteten Block, der den Workflow erklärt
5. Führt den Agenten durch eine strenge Schleife:
   • Spezifikationseinfrieren
   • Implementierung durch Builder
   • Nachweisverpackung
   • Frische Verifizierung
   • Minimale Korrektur
   • Erneute frische Verifizierung bis zum PASS

Siehe:

• references/REFERENCE.md
• references/COMMANDS.md
• references/SUBAGENTS.md
• references/SCHEMAS.md

Von dieser Fähigkeit unterstützte Befehle

Behandle die folgenden Wörter als Befehle, wenn der Benutzer diese Fähigkeit aufruft:

• init <TASK_ID>: Erstelle .agent/tasks/<TASK_ID>/, installiere oder aktualisiere Subagentenvorlagen und aktualisiere AGENTS.md sowie die Claude-Anleitungsdatei des Repositorys
• freeze <TASK_ID>: Erstelle oder verfeinere spec.md basierend auf der Benutzeraufgabe, der Aufgabendatei und den Repository-Vorgaben
• build <TASK_ID>: Implementiere die Aufgabe gegen die eingefrorene Spezifikation
• evidence <TASK_ID>: Erstelle oder aktualisiere evidence.md, evidence.json und Roh-Artefakte, ohne den Produktionscode zu ändern
• verify <TASK_ID>: Führe einen frischen Prüfdurchlauf durch und schreibe verdict.json sowie bei Bedarf problems.md
• fix <TASK_ID>: Wende den kleinstmöglichen, sicheren Korrektur-Satz aus problems.md an und aktualisiere dann das Nachweis-Bündel
• run <TASK_ID>: Führe die vollständige Schleife vom Spezifikationseinfrieren bis zur Verifizierung aus
• status <TASK_ID>: Fasse den aktuellen Artefakt-Status zusammen

Wenn der Benutzer keinen Befehl angibt, leite den nächsten Schritt aus dem Repository-Zustand ab:

• Wenn der Aufgabenordner nicht existiert, führe zuerst init aus. Wenn der Benutzer eindeutig nur eine Initialisierung wünscht, höre dort auf. Andernfalls, nachdem init erfolgreich war und .agent/tasks/<TASK_ID>/spec.md existiert, fahre fort, indem der Repository-Zustand im selben Durchlauf erneut bewertet wird. Überschneide init nicht mit freeze, build, evidence, verify, fix, validate, status oder Subagenten-Arbeit.
• Wenn spec.md fehlt oder nur Platzhalter enthält, führe freeze aus
• Wenn die Implementierung noch nicht vollständig ist, führe build aus
• Wenn der Nachweis veraltet oder nicht vorhanden ist, führe evidence aus
• Wenn kein frisches Urteil vorliegt, führe verify aus
• Wenn das Urteil nicht PASS ist, führe fix aus

Initialisierungsschritt

Führe den gebündelten Initialisierer vom Repository-Wurzelverzeichnis oder dem aktuellen Arbeitsverzeichnis innerhalb des Repositorys aus:

scripts/task_loop.py init --task-id <TASK_ID>

Optionale Aufgaben-Vorselektion:

scripts/task_loop.py init --task-id <TASK_ID> --task-file path/to/task.md
scripts/task_loop.py init --task-id <TASK_ID> --task-text "Benutzeraufgabentext"

Der Initialisierer wird:

• das Repository-Wurzelverzeichnis auflösen
• .agent/tasks/<TASK_ID>/ erstellen
• alle erforderlichen Artefakte erstellen, einschließlich Platzhalter unter raw/
• projektspezifische Subagenten-Dateien installieren
• verwaltete Workflow-Blöcke in AGENTS.md und der Claude-Anleitungsdatei des Repositorys einfügen oder aktualisieren

Für Codex speichert der Initialisierer seinen verwalteten Workflow-Block im Repository-Wurzelverzeichnis AGENTS.md. Codex unterstützt auch AGENTS.override.md und konfigurierte Fallback-Anleitungsdateinamen; verschachtelte Dateien, die näher am Code liegen, haben weiterhin Vorrang, und diese Fähigkeit überschreibt sie bewusst nicht. Wenn init AGENTS.md während einer laufenden Codex-Sitzung erstellt oder überschreibt, starte eine neue Codex-Sitzung, bevor du dich auf die aktualisierten Anweisungen verlässt. Codex erfasst Projekt-Dokumentationsanleitungen zu Beginn der Sitzung.

Für Claude Code speichert der Initialisierer seinen verwalteten Workflow-Block im Repository-Wurzelverzeichnis CLAUDE.md. Claude Code unterstützt auch .claude/CLAUDE.md, .claude/rules/*.md und CLAUDE.local.md, aber diese Fähigkeit behandelt die Wurzel-CLAUDE.md als primäre Projektanleitung, da Claude sie direkt anzeigt.

In Claude Code: Wenn init gerade .claude/agents/* während der aktuellen Sitzung geschrieben oder aktualisiert hat, gehe nicht davon aus, dass diese aktualisierten Agenten bereits sitzungsintern verfügbar sind.

Behandle init als serielle Voraussetzung. Überschneide es niemals mit freeze, build, evidence, verify, fix, validate, status oder dem Start von Kind-Agenten.

Standard-Workflow für schwere Aufgaben

Halte für große Aufgaben die Benutzeranfrage einfach. In Codex fahre seriell fort, es sei denn, der Benutzer bittet ausdrücklich um Delegation oder parallele Agentenarbeit; nach dieser Autorisierung kann die Fähigkeit das interne Kind-Setup automatisch wählen, wenn die aktuelle Produktoberfläche Delegation unterstützt und die Aufgabenform dies rechtfertigt.

Bevorzugte delegierte Reihenfolge

1. Führe bei Bedarf init <TASK_ID> aus. Warte auf den Abschluss, bestätige dann, dass .agent/tasks/<TASK_ID>/spec.md und die repo-lokale Aufgabenstruktur existieren, bevor du fortfährst.
2. Erzeuge erst nach Abschluss von init genau einen Spezifikationseinfrierer-Subagenten und warte auf ihn
3. Erzeuge genau einen Builder-Subagenten und lasse ihn implementieren
4. Fahre mit derselben Builder-Sitzung für die Nachweisverpackung fort
5. Erzeuge genau einen frischen Verifizierer-Subagenten und warte auf ihn
6. Wenn das Urteil nicht PASS ist, erzeuge genau einen Korrektur-Subagenten
7. Erzeuge erneut einen frischen Verifizierer-Subagenten
8. Wiederhole die Schritte 6-7, bis der Verifizierer PASS zurückgibt oder der Benutzer die Schleife stoppt

Codex adaptive Aufteilung

Verwende dies nur, nachdem der Benutzer die Codex-Delegation ausdrücklich autorisiert hat und die Aufgabe breit genug ist, um von begrenzter paralleler Arbeit zu profitieren. Verwende die einfachere serielle Sequenz oben für schmale Aufgaben.

Gute Beispiele:

• Mehrere unabhängige Codebasis-Fragen müssen beantwortet werden, bevor die Spezifikation stabil ist
• Die Implementierung kann in disjunkte Schreibbereiche aufgeteilt werden
• Der Nachweis erfordert mehrere unabhängige schreibgeschützte Prüfungen über verschiedene Oberflächen hinweg

Codex-Muster:

1. init bleibt seriell.
2. Wenn die Aufgabe noch mehrdeutig ist, verteile bis zu 3 integrierte explorer-Kinder parallel. Gib jedem eine einzelne Frage, Subsystem- oder Pfadbereich. Warte auf sie, friere dann die Spezifikation ein.
3. Erzeuge einen Spezifikationseinfrierer-Kind und warte auf ihn.
4. Erzeuge ein task-builder-Kind als Integrationsbesitzer.
5. Wenn die Implementierung sauber aufgeteilt ist, kann das Elternteil auch begrenzte integrierte worker-Kinder parallel erzeugen. Jeder Arbeiter muss explizite Datei- oder Modulbesitzverhältnisse haben und darf nicht evidence.md, evidence.json, verdict.json oder problems.md schreiben.
6. Verwende send_input oder die entsprechende Folgeoberfläche, um den Integrations-Builder für die Nachweisverpackung am Leben zu erhalten. Der Builder bleibt der alleinige Besitzer des Nachweisbündels.
7. Wenn zusätzlicher Nachweis erforderlich ist, kann das Elternteil eine kleine, begrenzte Gruppe von schreibgeschützten explorer-Kindern parallel verteilen, um disjunkte Prüfungen erneut durchzuführen oder separate Nachweislücken zu untersuchen. Diese Kinder können Befehle, Ausgaben und Ergebnisse melden, aber sie schreiben nicht verdict.json.
8. Führe für jeden Verifizierungsdurchlauf genau ein frisches Verifizierer-Kind aus.

Plattformverhalten

• In Codex halte den normalen Pfad nach init seriell und vorzugsweise auto-mode-first. Vermeide es, Delegationsinterna preiszugeben, es sei denn, sie haben einen wesentlichen Einfluss auf die Arbeit.
• In Codex erzeuge begrenzte Subagenten nur, wenn der Benutzer ausdrücklich nach Sub-Agenten, Delegation oder paralleler Agentenarbeit fragt.
• In Codex kann die Fähigkeit nach Autorisierung der Delegation die passenden Kind-Rollen wählen und entscheiden, ob sie immer nur ein Kind gleichzeitig oder eine begrenzte Aufteilung verwenden. Der Benutzer sollte keine bestimmten Kind-Rollen oder Schrägstrich-Befehle nennen müssen.
• In Codex ist das Erzeugen von Kindern immer noch eine explizite Aktion des Elternteils/Orchestrators. Wenn die aktuelle Codex-Oberfläche Delegation blockiert, erwähne dies kurz, nur wenn es die Arbeit wesentlich beeinflusst, und fahre dann seriell fort.
• In Codex halte die Aufgabenstruktur flach. Die Elternsitzung sollte Forschungs-, Builder-, Korrektur- und Verifizierungskinder direkt erzeugen, anstatt ein benutzerdefiniertes Aufgabenkind zu bitten, weitere Kinder zu orchestrieren.
• In Codex, sobald die Delegation autorisiert ist, wähle zwischen der Eins-zu-einem-Zeit-Delegation und der begrenzten Aufteilung basierend auf der eingefrorenen Spezifikation, der Repository-Form und der aktuellen Delegationsumgebung. Halte init, die Nachweis-Eigentümerschaft und jeden Verifizierungsdurchlauf auf jeden Fall serialisiert.
• In Codex halte die Helfer-Aufteilung bescheiden und wellenbasiert. Bevorzuge bis zu 3 parallele Helfer-Kinder gleichzeitig, warte auf das Ende dieser Welle und entscheide dann über die nächste Phase.
• In Codex ist der integrierte explorer die erste Wahl für schreibgeschützte Repository-Erkundung und Nachweisprüfungen. Der integrierte worker ist geeignet für begrenzte disjunkte Implementierungs- oder Prüfungs-Wiederholungen, wenn du explizite Eigentümerschaft zuweisen kannst.
• In Codex verwende das aktive Builder-Kind für die Nachweisverpackung wieder, indem du ihm eine Folgeanweisung sendest. Verifizierungsdurchläufe müssen ein neues Kind oder eine neue Sitzung verwenden; erfülle die Frische des Verifizierers nicht, indem du einen früheren Verifizierer wieder aufnimmst. Builder- und Korrektur-Kinder können wieder verwendet oder wieder aufgenommen werden, wenn du diesen Kontext absichtlich zurückhaben möchtest.
• In Codex überprüfe die aktuelle Kind-Thread-Liste, bevor du ein Kind wieder verwendest oder aufnimmst. Verwende /agent in Codex CLI oder eine beliebige äquivalente Kind-Thread-Bestandsaufnahme-Oberfläche, die in der aktuellen Codex-Produktoberfläche verfügbar ist.
• In Codex ist die Plan-/Aufgaben-UI von update_plan eine optionale Sitzungsanleitung. Sie ist nützlich für die Live-Fortschrittsanzeige, aber nicht die Wahrheitsquelle für diesen Workflow.
• In Claude Code sollte die Fähigkeit entscheiden, ob sie auf dem Hauptthread bleibt oder die Haupt-Claude-Sitzung die aktuelle Phase nach init automatisch an einen passenden integrierten oder Projekt-Subagenten delegiert. Der Benutzer sollte nicht separat einen bestimmten Claude-Subagenten oder Delegationsmodus anfordern müssen.
• In Claude Code ist TodoWrite oder die sichtbare Aufgaben-/Aufgaben-UI nur eine optionale, sitzungsumfangreiche Fortschrittsanzeige. Sie kann bei der Live-Verfolgung in der aktuellen Sitzung helfen, ist aber nicht die Wahrheitsquelle für diesen Workflow.
• In Claude Code bevorzuge die installierten Projekt-Subagenten aus .claude/agents/, deren Beschreibungen als proaktive Auslösebedingungen für die entsprechende Nachweis-Schleifen-Phase verfasst sind. Die Haupt-Claude-Sitzung routet basierend auf der Aufgabenanfrage, den Subagentenbeschreibungen und dem aktuellen Kontext, also halte jede Phasenaufforderung in natürlicher Sprache klar. Verwende standardmäßig dasselbe Builder-Kind für den Nachweisschritt wieder. Führe nur dann einen neuen Builder im Nur-Nachweis-Modus aus, wenn die ursprüngliche Builder-Sitzung nicht verfügbar ist oder du sie absichtlich verworfen hast. Wenn init gerade .claude/agents/* während der aktuellen Claude-Sitzung aktualisiert hat, greife auf den Hauptthread oder bereits sichtbare Agenten zurück, anstatt anzunehmen, dass die aktualisierten sofort verfügbar sind.
• In Claude Code halte die Orchestrierung flach: Die automatische Delegation der Hauptsitzung ist in Ordnung, aber die Nachweis-Schleifen-Workflow-Agenten selbst sind Blatt-Rollen. Die Elternsitzung sollte die Phasenübergänge der Nachweis-Schleife besitzen, anstatt einen benutzerdefinierten Aufgabenagenten zu bitten, einen anderen zu erzeugen.
• In Claude Code ist der kanonische dauerhafte Zustand immer der repo-lokale Artefakt-Satz unter .agent/tasks/<TASK_ID>/, insbesondere spec.md, evidence.md, evidence.json, verdict.json und problems.md.
• Wenn Subagenten nicht verfügbar sind, behalte die gleiche Rollentrennung über separate Sitzungen oder klare Moduswechsel in der aktuellen Sitzung bei.

Verwende die genauen Rollenaufforderungen aus references/COMMANDS.md.

Anforderungen an das Spezifikationseinfrieren

spec.md muss mindestens enthalten:

• ursprüngliche Aufgabenstellung
• explizite Akzeptanzkriterien mit der Bezeichnung AC1, AC2, ...
• Einschränkungen
• Nicht-Ziele

Es kann auch enthalten:

• Repository-Anleitungsquellen
• Verifizierungsplan
• Annahmen, die eng aus der Benutzeranfrage abgeleitet wurden

Bearbeite während des Spezifikationseinfrierens keinen Produktionscode.

Anforderungen an die Nachweisverpackung

evidence.md und evidence.json müssen jedes Akzeptanzkriterium unabhängig mit einem der folgenden Werte bewerten:

• PASS
• FAIL
• UNKNOWN

Die Nachweisverpackung kann fehlende Prüfungen durchführen, aber sie darf den Produktionscode nicht weiter ändern.

Jedes PASS muss konkrete Beweise anführen, wie:

• Dateipfade
• ausgeführte Befehle
• Exit-Codes
• Ausgabezusammenfassungen
• Artefaktpfade unter raw/

Behaupte im Nachweisbündel kein allgemeines PASS, es sei denn, jedes Akzeptanzkriterium ist PASS.

Anforderungen an die frische Verifizierung

Der Verifizierer muss eine neue Sitzung oder ein neuer Subagent sein. In Codex erfülle diese Anforderung nicht, indem du einen früheren Verifizierer-Kind wieder aufnimmst.

Der Verifizierer muss den aktuellen Repository-Zustand und die aktuellen Wiederholungsergebnisse beurteilen, nicht die Erzählung des Builders.

Der Verifizierer schreibt:

• .agent/tasks/<TASK_ID>/verdict.json
• .agent/tasks/<TASK_ID>/problems.md nur, wenn das Gesamturteil nicht PASS ist

problems.md muss für jedes nicht-PASS-Kriterium enthalten:

• Kriterien-ID und -Text
• Status
• warum es nicht bewiesen ist
• minimale Reproduktionsschritte
• erwartet vs. tatsächlich
• betroffene Dateien
• kleinste sichere Korrektur
• korrigierender Hinweis in 1-3 Sätzen

Der Verifizierer darf den Produktionscode nicht ändern oder das Nachweisbündel nicht nachträglich ergänzen.

Anforderungen an den Korrekturarbeiter

Der Korrekturarbeiter liest nur:

• spec.md
• verdict.json
• problems.md

Der Korrekturarbeiter muss:

• jedes aufgeführte Problem in der Codebasis erneut bestätigen, bevor er es bearbeitet
• den kleinstmöglichen, sicheren Änderungssatz vornehmen
• vermeiden, bereits bestandene Kriterien zu verschlechtern
• evidence.md, evidence.json und Roh-Artefakte neu generieren
• anhalten, ohne eine endgültige Abzeichnung zu schreiben

Validierung

Bevor du behauptest, dass der Workflow korrekt initialisiert ist oder der Artefakt-Satz vollständig ist, führe aus:

scripts/task_loop.py validate --task-id <TASK_ID>

Führe validate nur aus, nachdem init vollständig abgeschlossen ist. Wenn es meldet, dass die Initialisierung noch läuft, warte und führe es erneut aus, anstatt dieses Ergebnis als stabilen Aufgabenfehler zu behandeln.

Für eine kurze Zusammenfassung:

scripts/task_loop.py status --task-id <TASK_ID>

Führe status nur aus, nachdem init vollständig abgeschlossen ist, wenn du einen stabilen Aufgabenstatus benötigst. Wenn es init_in_progress: true meldet, behandle dies als eine Bedingung zum späteren Wiederholen.

Leitplanken

• Halte .agent/tasks/<TASK_ID>/ innerhalb des Repositorys
• Behandle die Codex-Aufgaben-/Checkliste-UI als flüchtigen Fortschritt; der dauerhafte Zustand ist der Artefakt-Satz.
• Der Verifizierer muss frisch sein – kein Wiederaufnehmen eines vorherigen Verifizierer-Kindes.
• Die Nachweisverpackung darf den Produktionscode nicht ändern.
• Der Korrekturarbeiter liest nur spec.md, verdict.json und problems.md.
• Überschneide init niemals mit anderen Schritten.
• In Codex: Keine Annahme, dass aktualisierte AGENTS.md-Anweisungen in einer laufenden Sitzung verfügbar sind.
• In Claude Code: Keine Annahme, dass aktualisierte Subagenten aus .claude/agents/ sofort nach einem init verfügbar sind.
• Der Workflow ist auf flache Orchestrierung ausgelegt: Das Elternteil besitzt die Phasenübergänge.