agent-wave
Führt einen deklarierten Batch akzeptierter Warteschlangeneinträge mithilfe der Fähigkeiten aus, die dieser Host tatsächlich bereitstellt. Budgets zählen Items oder Wellen. Eine optionale Stundenbegrenzung stoppt neue Wellen, niemals ein laufendes Item. Langzeitautomatisierung nutzt die Zeitplanungsfunktion des Hosts (siehe README); diese Sitzung kann nicht garantieren, dass sie sich selbst überdauert.
Vorbedingungen und Host-Fähigkeit
Bevor Parameter abgefragt werden, lies den Einstiegspunkt des Repositorys, die Konventionen, die Warteschlange und den autonomen Prompt. Löse alle Artefaktpfade, einschließlich _agent/, gegen die aufgezeichnete Wurzel auf. Erfordere ein echtes Gate und die Warteschlange, die es durchläuft.
| Aufgezeichneter Modus | Ausführung | |---|---|---| | Single Writer | Stoppe und leite den Operator zum sequentiellen autonomen Prompt, bei jeder angeforderten Breite. | | Shared Checkout, direkte Integration | Ein Ausführender nach dem anderen in diesem Checkout, unter Verwendung von Item-Status und Lock-Zeilen. Kein Claim-Branch oder Integrations-Worktree. | | Shared Checkout, PR-Integration | Stoppe vor dem Claim; erfordere separate Worktrees für PR-Wellen. | | Separate Worktrees | Jeder Ausführende verwendet seinen eigenen Worktree; Integration folgt dem aufgezeichneten Modell. |
Hole/Fetch-und-Prune den aufgezeichneten Remote und erfordere seinen Integrations-Branch. Gib den gefetchten Base-SHA aus. Vergleiche den lokalen Integration-Ref: Melde nicht-gepushte Commits oder Abweichungen, bevor du fortfährst; verwirf sie niemals stillschweigend. Ein zurückliegender, sauberer Checkout darf schnell-vorwärts gespult werden, wenn es sicher ist; ansonsten lass ihn in Ruhe. Der Zustand der Welle und der Probe stammen vom gefetchten Base, nicht von nicht-committeten Dateien im Checkout des Operators. Wenn die Remote-Warteschlange leer ist, aber die lokale Warteschlange abweicht, erkläre diese Abweichung.
Leite ab, ob der Host delegieren, Checkouts isolieren, parallel laufen lassen, eine vom Operator bereits aktivierte Orchestrierungsfunktion nutzen und geformte Ergebnisse anfordern kann. Wähle die höchste verfügbare Stufe:
- Aktivierte Orchestrierungsfunktion: ein Fan-Out nur für diese Welle. Behalte Wellen-Schleifen, Uhr-Prüfungen und Fragen im Orchestrator.
- Einfache Subagents: parallel falls verfügbar, sonst sequentiell. Verwende Host-Worktree-Isolation nur, wenn sein Start-Head dem deklarierten Base entspricht; andernfalls erstelle explizit jeden Worktree auf diesem Base.
- Der Orchestrator führt ein Item nach dem anderen aus, in seinem eigenen Worktree oder dem Shared Checkout, wie es der aufgezeichnete Modus erlaubt.
Melde Ausführung: Stufe N — Grund. Der Operator kann diese Wahl herabsetzen; erhöhe sie niemals über die beobachtete Fähigkeit hinaus oder bitte um Aktivierung. Eine Skill, die eine Funktion erwähnt, ist kein Opt-in des Operators. Die gleiche kanonische Kurzbeschreibung unten wird auf jeder Stufe verwendet. Ohne eine nachgewiesene Parallelitätsgrenze verwende eins.
Bewertung und Deklaration
Verwende bereits gegebene anwendbare Antworten erneut, einschließlich Tiefe; Standardwerte ersetzen niemals explizite Entscheidungen. Eine vollständig gelieferte Spezifikation benötigt keine wiederholte Auswahl oder Bestätigung. Frage nur nach einer wesentlich fehlenden oder widersprüchlichen Wahl; eine aufgezeichnete Präferenz allein ist keine aktuelle Ausführungsberechtigung. Ansonsten stelle jeweils eine Frage mit einer empfohlenen Antwort und einem Grund, unter Verwendung eines strukturierten Selektors, falls verfügbar. Wenn die Tiefe ungeklärt ist, biete Express (Standardwerte), Guided (Budget/Aufsicht) oder Vollständige Tiefe an, mit der aufgezeichneten Tiefe vorausgewählt. Ehre 'Standards-von-hier' oder 'gehe-tiefer'.
- Anfgefordert Breite: Empfehle min(berechtigte Warteschlangentiefe, 3, Host-Obergrenze).
- Budget: Items oder Wellen; empfohlene eine Welle. Optional eine weiche Stundenbegrenzung.
- Aufsicht: Checkpoint nach jeder Welle (empfohlen) oder kontinuierlich.
- Integration: Verwende das Repository-Profil, es sei denn, es wird explizit überschrieben. Direkte Integration ist legitim mit aufgezeichneten Parallelitäts-Schutzmechanismen; ihre Integration ist seriell. Eine Überschreibung kann keinen nicht unterstützten Modus gültig machen.
Deklariere und bestätige die resultierende Spezifikation vor der Ausführung (explizite Aufrufparameter gelten bereits als Bestätigung). Enthalte:
- Wellenname, Datum, Remote, Integrations-Branch und gefetchter Base-SHA.
- Angeforderte/effektive Breite, Stufe/Grund, Host-Obergrenze und etwaiges Token-Limit.
- Budget, Aufsicht und weiche Begrenzung; konvertiere niemals Token-Limits in Item-Anzahlen.
- Schlüssel jedes Items, zugehörige Entscheidungen, Abhängigkeiten, Claim-Variante, exakte zugehörige Artefakte, reservierte Identifikatoren mit ihren Sequenzen und Continue-Flag.
- Isolations- und Integrationsprofil; tatsächlich gewährte Integrations-/Merge-Aktionen.
- Gewährung: "Begleitete Welle: Der Operator hat diese Parameter und dieses Item am bestätigt; implementiere nur das genannte Item, wähle niemals ein anderes."
Reserviere nur Identifikatoren, die ein Item erstellen wird, in endlichen disjunkten Blöcken. Enthalte bestehende Live-Reservierungen; fortgesetzte Items behalten ihre ursprünglichen. Weise niemals zwei Schreibern denselben Entscheidungs- oder Plan-Body zu. INDEX wird abgeleitet: Ein Ausführender ändert nur seine eigenen Zeilen, und die Integration regeneriert die gesamte Tabelle. Erschöpfte Reservierungen stoppen das Item; keine Slots stehlen.
Nach der Bestätigung erstelle einen abgetrennten Integrations-/Probe-Worktree auf dem Base für den Separate-Worktree-Modus, außerhalb des Baums des Operators. Verwende einen übriggebliebenen nur nach dem Nachweis, dass er sauber und im Besitz ist. Führe dort die genaue Gate-Prüfung mit verfolgten Dateien und vorhandener Umgebung durch. Bei Umgebungsfehlern stoppe vor dem Versand und melde den Befehl, die Ausgabe und den Exit-Code; installiere keine fehlenden Abhängigkeiten und impliziere nicht, dass die Wahl von Stufe drei das Gate repariert. Melde den effektiven Hooks-Pfad und den Ursprung der Signierungseinstellung.
Vor jeder Welle sammeln
Führe erneut Fetch/Prune aus; lies Item-Status, Claim-Tips, Worktrees und PR-Zustand aus. Verwende diese Rangfolge, löse jedes Item auf dem Base und dem Claim-Tip auf:
| Klasse | Beweis und Aktion |
|---|---|
| Nicht verifizierbar | Erforderlicher Remote/PR-Beweis nicht verfügbar oder widersprüchlich: Stoppe den Lauf. |
| Verschifft | 'Done'-Eintrag auf dem Integrations-Branch mit erreichbarem Footer-Commit oder bestätigtem gemergten PR. Ausschließen. |
| Gemergt aber nicht verschifft | Arbeit/PR gemergt, aber Item noch in der Warteschlange auf dem Base. Ausschließen und Abgleich anfordern. |
| Gestoppt | 'Stopped'-Feld auf dem Base oder Claim-Tip. Ausschließen, es sei denn explizit fortgesetzt. |
| Live | Nicht gemergter Remote-Claim oder Draft/Ready-PR, oder aktueller Shared-Checkout-Besitzer/Locks. Ausschließen, es sei denn explizit fortgesetzt. |
| Veraltet | Branch-gestützter lokaler Besitz nach bestätigtem Verschwinden eines Remote-Refs. Bereinigung melden; unsichere Überbleibsel nicht neu zuweisen. |
| Berechtigt | Akzeptierter Besitz, erfüllte Abhängigkeiten, kein Claim/Stop/Stale-Konflikt. In Warteschlangenreihenfolge auswählen. |
Ein fertiger PR hat das Item möglicherweise auf seinem eigenen Branch als erledigt markiert. Löse diese Verschiebung über den verlinkten PR/History auf; es ist immer noch live, kein Waisenkind. Überprüfe bestätigte PR-Merges, wenn Squash/Rebase die Quell-Abstammung unklar macht. Shared Claims werden aus Item/Locks bewertet, niemals vom Fehlen eines Remote-Claims. Abgetrennte Worktrees sind weder Claims noch veraltet. Ein vorausliegender lokaler Claim-Ref bedeutet ungepushte Arbeit: gib 'unknown' zurück und bewahre ihn.
Bei Guided/Vollständiger Tiefe biete Continue nur für einen bestehenden Live/Stopped-Claim an; standardmäßig ausschließen. Express schließt aus und listet auf, wie man fortsetzt. Ein Aufruf, der den Claim oder das Item nennt, ist die explizite Antwort. Fortsetzung erzeugt keinen neuen Claim oder neue Reservierung; melde übriggebliebene Worktrees. Nach der Auswahl überprüfe erneut überlappende Pfade und Abhängigkeiten.
Kanonischer Ausführer-Brief
Übergebe diesen vollständigen Brief mit der Spezifikation des Items, unverändert auf allen Stufen:
- Öffnen und orientieren. Verifiziere die Base-Abstammung und das genannte Item. Ein fortgesetzter Checkout muss dem gefetchten Claim-Tip entsprechen; die Abschlussverschiebung eines verlinkten fertigen PRs ist gültiger Kontext. Lies den Einstiegspunkt und den autonomen Prompt. Eine Diskrepanz wird blockiert, niemals die Erlaubnis, an einem anderen Item zu arbeiten.
- Claim. Führe erneut Fetch aus. Erstelle für ein neues Separate-Worktree-Item
claim/<item-key>vom Base; committe 'Claimed by' mit Akteur/Datum/Branch und setze den tatsächlichen Claim-Branch, die Welle, Reservierungen und zugehörige Artefakte in die erste Commit-Nachricht. Vor dem Veröffentlichen liesgit show -s --format=%B HEADundgit show HEAD:<owned-plan-path>zurück. Überprüfe den wörtlichen tatsächlichen Branch sowohl in der Nachricht als auch in 'Claimed by', den Wellennamen, Reservierungen (einschließlich keiner) und exakte owned-Pfade. Überprüfegit diff-tree --no-commit-id --name-only -r HEAD: Dieser erste Commit ändert nur den Status des gehörten Items, ohne Implementierungsausgabe. Repariere fehlende Metadaten lokal vor der Übernahme. Ein späterer Commit kann einen mangelhaften initialen Claim nicht reparieren. Validiere den Schlüssel mitgit check-ref-format --branch; verwende niemals einen wörtlichen Platzhalter. Übernehme mitgit push --porcelain --force-with-lease=refs/heads/claim/<item-key>: origin HEAD:refs/heads/claim/<item-key>. Fordere Exit-Code Null und das Porzellan-*-Ergebnis für diesen Ziel-Ref. Existierende Refs, einschließlich gleicher-Tip/aktuell-Ergebnisse, gewähren kein Eigentum. Warte darauf, dass der Push abgeschlossen wird, und inspiziere seine erfolgreiche neue-Ref-Quittung, bevor du einen Implementierungsschreibvorgang ausgibst. Fasse Übernahme und Implementierung nicht im selben Tool-Aufruf zusammen. Ein Signierungs-/Push-Fehler stoppt vor der Implementierung; bewahre unbekannte Ergebnisse. Überschreibe niemals einen anderen Claim. Setze Upstream nach der Übernahme. Für den PR-Modus öffne sofort einen Draft-PR oder verwende einen bestehenden wieder, mit Item, Akteur, Branch, Reservierungen, owned-Pfaden und schließendem Block; Fehler blockieren die Implementierung. Setze fort, indem du am bestehenden Remote-Tip detachst, Reservierungen behältst und 'Claimed by' im ersten Commit aktualisierst, dann zurück zu diesem Ref pushst. Shared Checkout: Claim über Item-Status und Lock-Zeilen vor jeder Bearbeitung, einschließlich neuer Einträge; erstelle oder wechsle niemals einen Claim-Branch. - Implementieren. Folge dem autonomen Prompt für dieses eine Item. Akzeptiere/ersetze keine Entscheidungen, füge keine neuen Warteschlangeneinträge ein oder nummeriere sie neu, überschreite keine Reservierungen, führe kein Version-Bumping, Tagging, Veröffentlichen oder Frage den Operator. Gib einen Blocker zurück, wenn der Brief nicht eingehalten werden kann.
- Verifizieren und committen. Führe das aufgezeichnete Gate genau aus. Repariere verstandene Implementierungsfehler und führe es erneut aus. Wenn das Gate nicht ausgeführt werden kann, installiere nichts, was es nicht selbst installiert: Zeichne den genauen Fehler in Blockern auf, committe/pushe wiederherstellbare Arbeit innerhalb der Gewährung und gib 'blocked' zurück, niemals 'verified' oder 'shipped'. Befolge die Regeln zu Signierung, Rationale und Gate-Integrität.
- Integrieren gemäß Profil. Separate-Worktree direkte Integration: Pushe den verifizierten Claim und gib 'ready' zurück; der Orchestrator ruft den Integrationsmodus von ship-item auf. Shared Checkout: Rufe ship-item im aktiven Baum auf. PR-Modus: Rufe ship-item auf dem aktuellen PR auf, einschließlich Rebase, Kollisionsprüfungen, Reparatur der eigenen Nummer, beide Gates und Abschluss-Commit. Halte seinen Body/Report aktuell; 'ready' erfordert Checks auf dem aktuellen Head. Merge nur innerhalb der Gewährung und melde 'shipped' nur nach bestätigtem Landen. Wiederhole einen verschobenen Base höchstens zweimal; bewahre ungelöste Claims bei Fehlschlag.6. Stoppen und melden. Setze Datum/Grund und die drei Berichtsetiketten in das 'Stopped'-Feld des Warteschlangeneintrags oder in den PR-Body, wenn er bereits dorthin verschoben wurde. Committe/Pushe nur innerhalb der Gewährung. Gib die unten stehenden Felder und den finalen Block zurück. Erstelle niemals einen Koordinations-Snapshot oder lösche schmutzige Arbeit stillschweigend.
Ausführen, integrieren und Ergebnisse sammeln
Versende die deklarierte Welle mit dem abgeleiteten Mechanismus. Effektive Breite ist eins auf Stufe drei und für Shared Checkouts. Auf Stufe drei beginnt das Claimen eines Items: Erstelle lokale oder Remote-Claim-Branches und fülle 'Claimed by' nur für das aktuelle Item; beanspruche niemals vorab den restlichen Batch. Überprüfe sein Gate-Ergebnis, bevor du die Befehle für das nächste Item ausgibst. Ein späteres Vorab-Claim ist kein bereits laufender Ausführender. Auf Stufe drei beende und integriere jedes Item, bevor du mit dem nächsten beginnst. Bevor du die Schleife fortsetzt, überprüfe das Gate-Ergebnis des letzten Ausführenden. Ein Umgebungs-Blocker beendet die gesamte Welle sofort, selbst wenn das nächste Item unabhängig ist und das Budget Platz hat. Starte nicht das nächste Item oder eine weitere Integration. Diese Regel hat Vorrang vor kontinuierlicher Aufsicht und der numerischen Fehlerschwelle. Sammle bereits laufende Ausführende ein, ohne neue Arbeit zu starten, und melde dann den systemischen Blocker. Bewahre ihre wiederherstellbaren Claims. Ein erfolgreicher Base-Probe überschreibt keinen Umgebungsfehler nach der Implementierung.
Bei paralleler direkter Arbeit rufe den Integrationsmodus von ship-item für bereite Claims in Warteschlangenreihenfolge auf, unter Verwendung des abgetrennten Integrations-Worktrees. Die Integrationsmechanik lebt in ship-item, nicht in einem zweiten Verfahren hier. PR-Hosts serialisieren autorisierte PR-Merges.
Normalisiere jede Rückgabe auf: Item-Key; Ergebnis (shipped, ready, failed, blocked, stopped, unknown); Claim/Aktueller Branch; Integrations-SHA oder PR; verwendete/neu nummerierte Identifikatoren; Blocker; Konfliktdateien; finaler Block wörtlich. Keine Rückgabe bedeutet 'unknown'. Ergebnis ist getrennt vom Vokabular von 'Overall'. Für einen bereiten Claim, der auf Integration wartet, schreibe Outcome: ready und Overall: partially verified; ready und shipped sind niemals 'Overall'-Werte. Melde jedes Item und eine Wellenzusammenfassung mit 'Status auf einen Blick'; jedes 'unknown' begrenzt die Welle auf 'partially verified'. Enthalte ausgeschlossene/zurückgezogene Claims, effektive Breite, Stufe, Gate-Ergebnisse, Hooks/Signierungsquellen und verbleibende Arbeit.
In der endgültigen Antwort behalte einen 'Status auf einen Blick'-Block für jedes Item, dann einen separaten Block für die Welle. Jeder hat 'Dieser Lauf', 'Insgesamt' und 'Noch zu erledigen'. Eine Ergebnistabelle pro Item kann diese Blöcke begleiten, ersetzt sie aber niemals, auch nicht auf der sequentiellen Stufe. Überprüfe ihre Anzahl vor der Rückgabe. Setze den Item-Key oder 'Welle' in eine separate Überschrift über seinen Block. Behalte die Blocküberschrift genau Status auf einen Blick, ohne Item-Suffix oder Wellen-Präfix. Setze Welle in einen eigenen Bereichs-Überschrift, genau wie bei einem Item. Zum Beispiel:
## Item <key>
### Status auf einen Blick
- **Dieser Lauf:** <beobachtete Aktionen und Gate-Ausgabe/Exit>
- **Insgesamt:** <erlaubtes Vokabular>
- **Noch zu erledigen:** <verbleibende Arbeit oder Keine>
Checkpoint fragt vor einer weiteren Welle. Der kontinuierliche Modus sammelt erneut von git und fährt innerhalb des bestätigten Budgets fort. Lies die Shell-Uhr beim ersten Versand und nach jeder Welle; wenn nicht verfügbar, melde die weiche Begrenzung als nicht durchgesetzt. Stoppe den Start neuer Wellen nach der Begrenzung; unterbrich niemals ein laufendes Item.
Stoppen und Bereinigen
Eine explizite Host/Tool-Berechtigungsverweigerung stoppt t...