Three-Loop-Workflow (Planen – Bauen – Abschließen)

Three-Loop-Workflow (Drei-Schleifen-Arbeitsablauf)

Planen → Bauen → Abschließen, auf einer Tiefe, die dem Risiko angemessen ist.

Übernimm die Verantwortung für die zugewiesene Implementierung: ihren Plan, ihre Änderungen, Nachweise, Überprüfung und Reparaturen. Der Implementierer kann der übergeordnete Agent oder ein beauftragter Ausführender sein. Wenn ein Koordinator existiert, überlasse diesem die Aufgabenverteilung, Abhängigkeiten, gemeinsame Schnittstellen und die Integrationsverantwortung. Fordere erforderliche Rollen oder Terminplanänderungen von diesem Koordinator an. Koordiniere nicht rekursiv andere Aufgaben. Leite Benutzerentscheidungsanfragen durch den Koordinator. Ohne Koordinator verwalte die Änderung und die erforderlichen Rollen direkt. Implementierungstiefe und Ausführungsmodus sind getrennt. Direkte Ausführung hebt die erforderliche Überprüfung nicht auf.

Harte Einschränkungen, die einzigen Regeln, die keine Voreinstellungen sind:

1. Eine Änderung oberhalb von Direkt wird von einem Kontext überprüft, der sie nicht geschrieben hat; nur wenn keiner verfügbar ist, vermerkt die Übergabe dies (Abschnitt 5).
2. Führe die Projektprüfungen aus. Eine Prüfung, die nicht ausgeführt werden konnte, ist keine bestandene Prüfung.
3. Die Übergabe berichtet, was beobachtet wurde, nicht was beabsichtigt war.
4. Eine Änderung, wer worauf zugreifen kann (Authentifizierung, Autorisierung, Geheimnisse, ein neuer Pfad für nicht vertrauenswürdige Eingaben), ist niemals Direkt.
5. Eine Aktion außerhalb des Repositorys, die nicht rückgängig gemacht werden kann, wartet auf den Benutzer: Pushen in einen gemeinsamen Branch, Bereitstellen, Schreiben von echten Daten, Senden von irgendetwas.

Alles andere ist eine Voreinstellung: verlasse eine nur aus einem genannten Grund. Die Projektanleitung überschreibt jede Voreinstellung, und die Mittel stehen dir frei.

Lies die Projektanleitung (AGENTS.md, CLAUDE.md) für ihre Prüfbefehle und die Dateien, die sie als Verträge behandelt; wo sie keine nennt, leite sie aus dem Repository ab und sage, was du abgeleitet hast. Prüfungen stammen aus der Build-Konfiguration und CI; Verträge sind das, was außerhalb dieses Repositorys konsumiert oder beibehalten wird: öffentliche APIs, Schemata, CLIs, Drahtformate, gespeicherte Daten.

Wende die Texttyp-, Sprach- und visuellen Regeln in references/writing.md auf das Schreiben dieser Aufgabe an.

1. Tiefe

Nimm die leichteste Tiefe, die passt.

• Direkt: eine offensichtlich kleine Bearbeitung, deren Korrektheit sichtbar oder durch eine bestehende Prüfung abgedeckt ist. Eine nicht-triviale Verhaltensänderung ist Standard oder Tief, selbst mit Tests. Eine Tippfehlerkorrektur kann Direkt sein. Eine geänderte Voreinstellung nicht. Nimm die Änderung vor und führe die Prüfungen aus. Kein Plan oder Prüfer erforderlich. Melde die Änderung, Prüfungen, Ergebnisse und das Fehlen einer Überprüfung in einer Zeile.

• Standard: die Voreinstellung für Verhaltensänderungen.

• Tief: nur, wenn ein Auslöser zutrifft:

  1. eine bahnbrechende Änderung an einem Vertrag, der außerhalb dieses Repositorys konsumiert wird;
  2. ein irreversibler Effekt außerhalb des Repositorys: eine Migration von persistenten Daten, Geld, irgendetwas, das an einen Dritten gesendet wird;
  3. eine geänderte Regel in einer Datei, die das Projekt als Vertrag behandelt;
  4. Alternativen, die sich auf unterschiedliche Strukturen festlegen.

  Dann lies references/deep.md.

Eine riskante Ecke hebt ihre eigene Tiefe an, niemals die Tiefe der gesamten Änderung. Hebe die Tiefe selbst an, auch wenn der Build einen Auslöser offenbart; nur der Benutzer senkt sie. Bevor du sie senkst, empfehle deine Tiefe. Für jemanden, der neu in diesem Workflow ist, zeige, was diese Änderung überspringen würde und welcher Fehler offen bleibt. Wenn sie darauf bestehen, folge ihnen, ohne eine harte Einschränkung aufzuheben.

2. Planen

Bei Standard und Tief, vor der ersten Bearbeitung, schreibe das Ziel, die Nicht-Ziele, die dich versucht haben, und Akzeptieren, die Nachweise (Abschnitt 4).

Skaliere den Plan und die Überprüfung auf die Änderung.

Füge Entscheidungen nur bei echten Verzweigungen hinzu: die Optionen, einschließlich der kleineren, und warum der Gewinner gewonnen hat.

Schreibe es nach .agent/<task>/plan.md, ein Verzeichnis pro Aufgabe, und committe die Dateien mit der Änderung, es sei denn, das Projekt hat eine eigene Konvention. Wenn .agent in .gitignore steht, belasse diesen Eintrag und füge die Dateien nicht mit Gewalt hinzu.

Bei zugewiesener Arbeit verwende den angegebenen Planpfad und referenziere den gemeinsamen Umfang und die Akzeptanzkriterien. Behalte Implementierungsdetails dort. Hinterlasse globale Aufgabenaufzeichnungen beim Koordinator. Bewahre bestehende kanonische Aufgabenverzeichnisse. Für delegierte Pläne, standardmäßig nach .agent/<task>/tasks/<slice-id>/plan.md.

Wenn zwei Lesarten der Anfrage unterschiedliche Arbeiten erfordern, gib deine im Ziel an, zeige es und das Akzeptieren dem Benutzer und warte; wenn niemand antworten kann, fahre mit deiner Lesart fort und markiere es in der Übergabe als unbestätigt. Frage zu echten Produkt-, Umfangs- oder Risikoentscheidungen mit Optionen, einer Empfehlung und einer Begründung, entscheide niemals stillschweigend; zeichne die Antwort im Plan auf.

Wenn die Ursache eines Fehlers unbekannt ist, ist das Finden die Aufgabe: Sein Akzeptieren ist eine Reproduktion; plane die Korrektur danach.

3. Bauen

• Jede geänderte Zeile geht auf das Ziel oder eine Entscheidung zurück. Keine Abstraktion, Konfigurierbarkeit oder Fehlerbehandlung, die niemand braucht.
• Wenn der Code oder eine Korrektur dem Plan widerspricht, stoppe und korrigiere den Plan offen, nicht am Ende.
• Bleibe innerhalb der zugewiesenen Dateien und Schnittstellen. Wenn diese Änderungen benötigen, pausiere die betroffene Arbeit und fordere eine überarbeitete Zuweisung an.
• Paralleles Lesen, isoliertes Schreiben. Verwende einen separaten Arbeitsbaum für jeden gleichzeitigen Schreiber (references/parallel.md).
• Für Integrationsarbeit, führe Prüfungen und Überprüfungen gegen die gemergte Änderung durch. Das Bestehen von Teilprüfungen etabliert keine integrierte Akzeptanz.
• Wo ein Dokument eine Zahl zitiert, die ein Befehl erzeugt, zitiere den Befehl neben der Zahl oder lasse eine Prüfung sie neu berechnen.

Für dauerhafte Arbeit speichere Prüfergebnisse in evidence/checks.md neben dem Plan. Zeichne Kriterien, Befehle, Revisionen, Ergebnisse, Nachweislinks und Ungültigkeitsbedingungen auf. Speichere Ergebnisse, Triage, Prüferidentität und Reparaturrunden in evidence/review.md.

4. Nachweise

• Akzeptieren nennt den billigsten echten Nachweis, der ohne die Änderung fehlschlagen würde: eine bestehende Prüfung, die grün wird, ein neuer Test oder das beobachtete Ergebnis. Sage, wie ein Fehlschlag aussieht.
• Standardmäßig ist kein neuer Unit-Test erforderlich. Schreibe einen, wenn das Verhalten eine Logik ist, die ein Test billig fixiert und eine Regression zu bewachen lohnt. Es ist die falsche Prüfung für UI-Rendering und Layout, Verdrahtung und Kleber, Konfiguration, dünne Aufrufe externer Dienste, Einwegskripte und Prosa: beobachte stattdessen das Ergebnis.
• Wo eine Person klickt, tippt oder es aufruft, treibt ein Kontext, der die Änderung nicht geschrieben hat, sie an und berichtet, was er gesehen hat. Gib ihm den Pfad und den Fehlschlag, nicht das Diff oder deinen Bericht. Ein Widerspruch ist ein Befund. Kein solcher Kontext: treibe es selbst an und füge ein, was du gesehen hast. Treibe eine unzulässige Oberfläche irgendwo sicher an und nenne die Lücke. Nicht angetrieben bedeutet nicht geprüft.
• Wo die Ausgabe gelesen und nicht ausgeführt wird (Dokumente, Hilfetexte, ein Lastenheft), ist der Nachweis ein kalter Lesevorgang der fertigen Dateien durch einen Leser ohne den Änderungskontext: lies es als Produkt, nicht als Diff.
• Ein intermittierender Fehler ist selbst eine Reproduktion und der unterscheidende Nachweis. Führe den Fehler dieser Änderung nicht erneut aus, bis er besteht, und verlange keine deterministische Reproduktion, bevor du ihn als solchen behandelst. Einer, den diese Änderung nicht verursacht hat, ist eine benannte Nachverfolgung, die nicht innerhalb dieser Änderung behoben wird.
• Führe die Prüfungen aus vor der Überprüfung, diejenigen, die die Änderung nach jeder Korrektur abdecken, und den vollständigen Satz einmal vor der Übergabe. Füge die Bestehens-/Fehlschlagzeilen ein, nicht die gesamten Protokolle. Alles, was übersprungen oder durch Abschwächung eines Tests grün gekauft wurde, ist kein Bestehen.

5. Überprüfung

Der Prüfer erhält die gesamte Änderung (oder, bei einer schrittweise erstellten Änderung, die gesamte Phase), den Plan und das Repository, nicht deine Zusammenfassung oder Begründung. Gesamt bedeutet jede Datei, die die Änderung hinzufügt, ändert oder löscht, einschließlich neuer unverfolgter Dateien; eine Überprüfung eines leeren oder unvollständigen Diffs ist keine saubere Überprüfung. Direkt benötigt keinen Prüfer; Standard bekommt einen.

Nicht verfügbare unabhängige Überprüfungen oder Lesevorgänge: verwende zuerst verfügbare unabhängige Kontexte. Für fehlende Rollen, inspiziere die oben angegebenen vollständigen Artefakte, nicht deine Erinnerung an die Arbeit. Wende die Kurzanleitungen der fehlenden Rollen in einem einzigen Selbstüberprüfungsdurchlauf an. Kennzeichne es als „Selbstüberprüfung, nicht unabhängig“ und melde die fehlenden unabhängigen Rollen. Biete dem Benutzer die Kurzanleitungen zur Ausführung an anderer Stelle an. Dieser Fallback überschreibt keine strengeren Benutzer-, Projekt- oder Host-Anforderungen.

Übergebe diese Kurzanleitung wörtlich:

Überprüfe diese Änderung anhand ihres Plans. Melde jeden Befund mit Datei:Zeile,
markiert als blockierend (falsches Verhalten, ein gebrochener Vertrag, Arbeit außerhalb des
Plans) oder nicht blockierend. Ändere keinen Code.
1. Wo bricht sie? Unerwartete Eingabe, feindselige Eingabe, wo sie Vertrauen berührt,
   Fehler des von ihr Aufgerufenen, Tatsachen, die von außerhalb des Diffs angenommen werden.
2. Wurden bestehende Tests abgeschwächt?
3. Wird das neue Verhalten durch Nachweise, einen Test oder ein beobachtetes
   Ergebnis gezeigt, das ohne die Änderung fehlschlägt? Verlange nichts weiter.
4. Fällt irgendetwas außerhalb des Ziels oder innerhalb eines Nicht-Ziels?
5. Ist der Plan selbst falsch?

Triage vor dem Korrigieren. Bestätige jeden Befund gegen den zitierten Code. Weise Fehlinterpretationen und Befunde zurück, die Arbeit verlangen, die ein Nicht-Ziel ausschließt, jeweils eine Zeile. Ein fehlender Test ist nicht blockierend, es sei denn, er schützt einen bestätigten Korrektheitsfehler. Die Änderung schließt, wenn kein bestätigter blockierender Befund mehr übrig ist.

Überprüfung der Änderung einer anderen Person: dieselbe Kurzanleitung, mit ihrer Beschreibung als Plan; fehlende Nicht-Ziele sind ein Befund. Führe eine Triage durch und händige dem Autor die bestätigten Befunde aus; korrigiere sie nicht selbst.

6. Korrigieren und stoppen

• Eine Korrektur repariert, was ein bestätigter Befund zitiert, an seiner Ursache, überall, wo derselbe Fehler auftritt.
• Neue Mechanismen sind neue Arbeit: eine neue Prüfung, ein neuer Prüfstand, eine neue Schutzvorrichtung, Abstraktion oder Testdatei wird zu einer benannten Nachverfolgung, nicht Teil der Korrektur. Füge einen fehlschlagenden Test nur für einen bestätigten Korrektheitsfehler hinzu und erweitere eine bestehende Testdatei.
• Nach jeder Korrektur überprüft der Prüfer nur die Korrektur: sind die zitierten Befunde gelöst, und hat die Korrektur etwas eingeführt? Eine Korrektur plus ihre erneute Überprüfung ist eine Runde.

Stoppe und frage den Benutzer, wenn eine Runde die bestätigten Befunde unverändert lässt, eine Korrektur in Dateien oder Mechanismen hineinwächst, die der Plan nicht abdeckt, oder blockierende Befunde nach der dritten Runde verbleiben. Bringe die ungelösten Befunde wörtlich, was versucht wurde, wo es mit echter Ausgabe bricht, die Optionen (den Plan überarbeiten, ein dokumentiertes Risiko akzeptieren, das Element als Nachverfolgung fallen lassen, die Mechanismen auslagern) und deine Empfehlung. Senke die Messlatte niemals stillschweigend.

7. Abschließen: die Übergabe

Die Übergabe ist die abschließende Änderungsbeschreibung. Eine HANDOFF.md eines Koordinators enthält stattdessen Wiederaufnahmeanweisungen. Wende selektive Lese- und Aufzeichnungslebenszyklusregeln in references/writing.md an. Gib mit einem Koordinator Memory-Kandidaten aus der Quelle zurück und hinterlasse gemeinsame Aktualisierungen bei ihm.

Bei Standard und Tief trägt die Änderungsbeschreibung:

• das Ziel, als das, was ein Benutzer jetzt tun kann, und die Nicht-Ziele;
• Akzeptieren, und was die Nachweise tatsächlich gezeigt haben;
• was nicht geprüft werden konnte, und warum;
• wer es überprüft hat, oder „Selbstüberprüfung, nicht unabhängig“, oder dass keine Überprüfung stattgefunden hat, und dasselbe für einen Pfad, den eine Person antreibt;
• eine Tiefe, die der Benutzer gesenkt hat, und was du ihnen gezeigt hast, bevor sie darauf bestanden haben;
• unkorrigierte nicht blockierende Befunde, jeweils eine Zeile;
• Restrisiko;
• bei Tief, das Rollback, wie es jetzt aussieht.

Bei zugewiesener Arbeit gib Artefaktpfade und -revisionen, Nachweise, Überprüfungsstatus, ungelöste Anfragen sowie aktive oder unbekannte modifizierende Befehle zurück. Melde dem Koordinator den lokalen Abschluss. Gib nicht vor, die Gesamtaufgabe abgeschlossen zu haben.

Vom Benutzer hinzugefügte Überprüfungs-, Sicherheits- oder Orchestrierungswerkzeuge ergänzen die unabhängige Überprüfung, ersetzen sie niemals.