Unbeaufsichtigter Lauf
Dies ist der Modus für "Hier ist der Plan, los geht's": Setzen Sie ihn komplett um, ohne dass jemand an der Tastatur sitzt, und stellen Sie sicher, dass die Arbeit nach Rückkehr der Person überprüfbar ist. Er ist nicht an eine bestimmte Tageszeit gebunden. Er gilt für alle Zeiträume, in denen niemand zusieht, um eine Frage zu beantworten.
Voraussetzung: Ein genehmigter Plan
Dieser Modus hebt das Prinzip "Vorschlagen vor dem Bauen" nicht auf (siehe coding-process). Er kommt nach der Genehmigung zum Einsatz. Innerhalb des genehmigten Plans entscheiden Sie über reversible Implementierungsdetails selbst und schreiben jede Annahme auf. Eine dokumentierte Annahme ist besser als eine Sitzung, die die Nacht mit Warten verbracht hat. Das ist die gesamte Ausnahme.
Vier Kontrollpunkte, die Sie niemals allein passieren
Diese bleiben Kontrollpunkte, selbst wenn der Schritt reversibel ist. Keiner davon ist eine Ermessensentscheidung.
- Umfang. Alles, was der genehmigte Plan nicht bereits abdeckt: eine neue Funktion, eine nicht angeforderte Refaktorisierung oder das Auslassen eines Schritts, weil er sich als schwierig erwiesen hat. Das Einrichten eines fehlenden Test-Harnesses gilt als Umfang.
- Alles, was den Rechner verlässt: Externe Nachrichten, Veröffentlichungen oder Aufrufe eines Drittanbieterdienstes. Arbeiten im Repository (Branches, Commits, Pushen, PRs) sind Teil des Plans; die Kommunikation mit der Außenwelt ist es nicht.
- Alles, was Geld kostet: Kostenpflichtige APIs, bereitgestellte Infrastruktur, alles, was nach Verbrauch abgerechnet wird.
- Alles Destruktive oder Irreversible: Datenverlust, Force-Pushes auf geteilte Branches, Produktion.
Die Arbeit dauerhaft sichern
- Zuerst isolieren. Verwenden Sie einen Worktree, es sei denn, das Harness hat Ihnen bereits einen bereitgestellt. Ein unbeaufsichtigter Lauf ist genau der Zeitpunkt, an dem jemand anderes das Haupt-Checkout berühren könnte.
- Nach jeder logischen Einheit committen und pushen, nicht erst am Ende. Nicht gepushte Arbeit geht verloren, wenn die Sitzung abrupt endet. In diesem Modus überschreibt dies das übliche "Vor dem Committen fragen".
- Gehen Sie niemals mit uncommitteter Arbeit in eine Pause. Wenn Ihr Agent Nutzungslimits hat, machen Sie kurz vor dem Limit eine Pause, warten Sie auf den Reset und setzen Sie dann fort.
- Führen Sie die vollständigen Tests (Gates) an Kontrollpunkten aus, nicht nach jeder Änderung. Führen Sie während einer Änderung den engsten Test durch, der erfassen würde, was Sie gerade geändert haben: den Typtest eines Pakets oder eine einzelne Testdatei. Führen Sie den Build, Lint, die vollständige Testsuite und das CI-äquivalente Gate aus, sobald eine Arbeitseinheit abgeschlossen ist und bevor sie zur Überprüfung gepusht wird. Das erneute Ausführen einer Suite, die vor zehn Minuten bestanden wurde, an Code, den Sie nicht berührt haben, verbraucht Rechenleistung, um nichts zu lernen.
Delegation (wenn Ihr Agent Subagenten starten kann)
- Delegieren Sie mechanische Arbeit an günstigere Modelle: Kopieren einer vorhandenen Struktur, Boilerplate, Synchronisieren von Dokumentationen, wiederholte Änderungen. Behalten Sie das primäre Modell für korrektheitskritische Logik (Schema, Sicherheitsgrenzen, Kerndienste) und für Ermessensentscheidungen.
- Begrenzen Sie die Parallelität auf etwa fünf. Darüber hinaus wird die Prüfung unrealistisch, und parallele Agenten kollidieren in denselben Dateien.
- Prüfen Sie alles, was delegiert wurde. Integrieren Sie niemals die Ausgabe eines Subagenten, ohne sie gelesen zu haben. Überprüfen Sie, ob sie sinnvoll ist, Konventionen folgt und Build und Tests grün sind. Wenn sie falsch ist, bewerten Sie die Lücke: Beheben Sie eine kleine selbst und senden Sie eine große mit der Korrektur zurück.
Blocker
- Blockaden benennen; nicht raten. Wenn ein Planschritt einen expliziten Kontrollpunkt hat oder auf einen echten Blocker stößt (fehlende Infrastruktur, fehlgeschlagene Annahme), markieren Sie ihn deutlich, anstatt eine Problemumgehung zu erfinden, die das Design ändert.
- Erledigen Sie zuerst alles, was nicht von der Antwort abhängt, sodass die Person bei ihrer Rückkehr eine Frage plus erledigte Arbeit vorfindet, nicht nur eine Frage.
- Ein feststeckendes PR-Review ist ebenfalls ein Blocker. Markieren Sie es und bauen Sie die darüber liegenden Stufen lokal weiter, wo sie nicht von der Antwort abhängen.
UI-Verifizierung ist nicht optional, wenn niemand zusieht
Das Steuern der Benutzeroberfläche in einem Browser ist der Schritt, der am ehesten weggelassen wird, wenn niemand zusieht – und dessen Fehlen ein Prüfer nicht im Diff sehen kann. Befolgen Sie verify-ui. Wenn die Umgebung die Funktion nicht ausführen kann (fehlende Anmeldeinformationen, Infrastruktur, die Ihnen nicht gehört), geben Sie dies im Testbereich des PRs an: Nennen Sie, was blockiert hat und was stattdessen verifiziert wurde. Schweigen wird als "verifiziert" interpretiert.
Wenn Sie fertig sind
Berichten Sie den Stand der Arbeit: Was ausgeliefert wurde (PRs und Branches), was auf Review wartet, jede getroffene Annahme und jeden markierten Blocker. Schreiben Sie dies als Übergabe in docs/plans/, wenn die Sitzung endet.