kkestell/xauto

Orchestriere den vollständigen x-Workflow

Die aktuelle Sitzung ist der übergeordnete Koordinator. Lese references/workflow.md, bevor du Aufträge erteilst. Lese die anderen drei Skills nach Bedarf; ihre Phasensemantik und der gemeinsame Vertrag gelten für jeden Arbeiter. Führe wegen eines Tippfehlers in einer Anfrage keinen nicht zusammenhängenden kauto-Workflow aus.

Vorbereiten und zuweisen

1. Lege das gewünschte Ergebnis, Einschränkungen und den Umfang fest. Finde das Git-Root, den aktuellen Branch/HEAD, gültige Anweisungen sowie den Status von Arbeitsverzeichnis und Index. Git ist erforderlich; stoppe, anstatt es stillschweigend zu initialisieren. Wähle einen sauberen, exklusiven Task-Checkout aus. Bewahre nicht zusammenhängende Arbeit; isoliere sie nach Möglichkeit, ansonsten frage nach der benötigten Behandlung. Versprich keinen Commit auf dem ursprünglichen Branch des Benutzers, wenn du auf einem separaten Branch arbeitest.
2. Weise die Aufgaben-ID und die kanonischen Artefaktpfade zu. Ein Planer kann mehrere abgegrenzte Einheiten plus ein gemeinsames Design vorschlagen; der übergeordnete Koordinator weist zentral zusätzliche IDs zu und stellt die Abdeckung der vollständigen Anfrage sicher.
3. Entdecke die verfügbaren Delegationstools. Verwende Kind-Sitzungen zuerst; nur wenn nicht verfügbar, verwende Sub-Agenten. Befolge die Delegations-/Lebenszyklus-Regeln des Hosts. Nimm keinen Toolnamen an und simuliere keinen neuen Kontext mit einer weiteren Nachricht im übergeordneten Koordinator. Falls keiner der Mechanismen existiert, stoppe und erkläre, dass der unabhängige orchestrierte Workflow nicht verfügbar ist; führe nicht stillschweigend jede Rolle inline aus.
4. Übernimm Modell/Harness/Aufwand, es sei denn, der Benutzer oder geltende Anweisungen wählen sie aus. Verwende einen frischen Reviewer-Kontext, keinen Fork mit den privaten Überlegungen des Autors. Der Reviewer kann die Anfrage, den Code, die Artefakte und vorherige öffentliche Beanstandungen sehen, ist aber nicht der Arbeiter, der den geprüften Plan/die geprüfte Implementierung geschrieben hat.
5. Erfasse die Sitzungsherkunft des übergeordneten Koordinators gemäß dem gemeinsamen Vertrag. Fordere die Koordinator-ID und die native Konversations-ID jedes Arbeiters bei dessen Übergabe an; bewahre sie im Arbeitsprotokoll vor der Bereinigung auf, nicht nur flüchtige Arbeiternamen.

Explizite Phasenkurzbriefe erteilen

Jeder Arbeiter erhält das Ziel, relevante Benutzereinschränkungen, Skill und Aufruf, Aufgaben-ID, genauen Checkout und Start-HEAD, Ein-/Ausgabepfade, erlaubte Änderungen, Commit-Befugnis, Prüfanforderungen und vorhandene Verifikationsnachweise, erwartete Übergabe (einschließlich Sitzungsherkunft) und Abbruchbedingung. Gib an, wo das Ergebnis verwendet wird. Liefere einen Plan oder eine Anforderung, keine Annahmen, welche der Arbeiter unabhängig überprüfen soll.

Phasen sind sequenziell in einem gemeinsamen Checkout. Standardmäßig schreibt jeweils nur einer; führe separate Einheiten nur dann gleichzeitig aus, wenn ihre Dateien und Abhängigkeiten wirklich unabhängig sind und die Verantwortung für Integration/Review explizit ist. Bestätige das tatsächliche Verzeichnis/HEAD jedes Kindes; integriere Übergabe-Commits von isolierten Arbeitern vor der nächsten Phase, wie im gemeinsamen Vertrag beschrieben. Lösche niemals ein nicht übertragenes Ergebnis.

Planen → Plan-Review

• Starte einen Planer mit xplan <Anfrage> und ohne Bearbeitungsbefugnis für Produktionscode. Der Planer recherchiert knifflige Fragen, trifft Engineering-Entscheidungen und gibt fertige Pläne, einen Kurzbrief für winzige Aufgaben oder konkrete Hinderungsgründe zurück.
• Überprüfe die zurückgegebenen Artefakte und deren Abdeckung. Führe Plan- und gemeinsame Design-Einträge als plan fest, sende dann jeden Ausführungsplan an einen unabhängigen Arbeiter mit xreview plan .agents/plans/ID.md. Führe dessen Review-Durchlauf als plan-review fest.
• Bei Beanstandungen gib eine konkrete Korrekturanweisung an den Planer zurück. Führe den überarbeiteten Plan fest. Der übergeordnete Koordinator prüft die Korrekturen gegen die Beanstandungen und einschlägige Nachweise, dokumentiert deren Behandlung und die endgültigen Plan-/Leitfaden-Blöcke und fährt fort, wenn kein wesentlicher Mangel mehr besteht. Dies ist die Ausführungsentscheidung des übergeordneten Koordinators, keine Behauptung, der Reviewer habe unsichtbare Überarbeitungen genehmigt. Sende nicht jede Überarbeitung durch ein weiteres vollständiges Plan-Review. Eine zusätzliche unabhängige Bewertung benötigt eine spezifische, folgenreiche Frage, die das vorherige Review und die Korrekturprüfung nicht klären können; benenne diese Frage und fordere nur die benötigte Bewertung an. Formulierungen, Metadaten und Routine-Korrekturen rechtfertigen kein Neustarten des Reviews. Änderungen am gemeinsamen Design erfordern eine Prüfung der betroffenen Einheiten, nicht automatisch ein weiteres Review jeder einzelnen.
• Bei wirklich winzigen Arbeiten behalte den abgegrenzten Kurzbrief des Planers für xwork und überspringe die separaten Plan-/Review-Artefakte; das spätere Arbeitsprotokoll hält den Grund fest. Umgehe die Normalisierung nicht, indem du eine große, ungelöste Zuweisung als Kurzbrief bezeichnest.
• Eine aufgeteilte Anfrage ist nach ihrer ersten Einheit nicht abgeschlossen. Verfolge Einheiten-Abhängigkeiten im gemeinsamen Design, führe jede angeforderte Einheit in der richtigen Reihenfolge aus und überprüfe gemeinsame Schnittstellen/ Zwischenzustände erneut, wenn sich eine Abhängigkeit ändert.

Arbeiten → Arbeits-Review

• Sende einen Implementierer mit xwork .agents/plans/ID.md oder dem expliziten Kurzbrief für winzige Aufgaben. Übergib das akzeptierte Review/den Plan und die verknüpften Leitfaden-Blöcke. Autorisierte ausschließlich task-eigenen Code und Log-Commits. xwork zeichnet eine festgelegte Code-Basis auf, commitet verifizierten Code, dann separat sein Log mit einem bekannten Code-HEAD.
• Prüfe die Übergabe gegen Git und die aufgezeichneten Testergebnisse; eine „erledigt“-Meldung eines Kindes ist kein Nachweis für den richtigen Baum, bestandene Prüfungen oder committete Dateien. Löse Integrationszuordnungen auf und verwende Task-Checkout-Hashes im endgültigen Log.
• Starte einen unabhängigen Reviewer mit xreview work .agents/work/ID.md. Gib die Anfrage, den Plan/Kurzbrief, den vollständigen Code-Basis-..Code-HEAD-Bereich, das Arbeitslog und relevante Repository-Anweisungen. Der Reviewer liest Code und Tests, nicht nur das Log, und schreibt ein Review, ohne die Implementierung zu korrigieren. Führe das Review als work-review fest.
• Gib überprüfbare Prüfergebnisse für den aufgezeichneten Code-HEAD weiter. Bitte den Reviewer, diese Nachweise zuerst zu prüfen/wiederzuverwenden und verbleibende Unsicherheiten zu identifizieren, bevor er neue Prüfungen auswählt. Fordere nicht routinemäßig gezielte Wiederholungen, einen vollständigen Paketlauf und die Repository-Suite erneut für denselben unveränderten Code an. Explizite Anforderungen für neue Läufe gelten weiterhin.
• Sende umsetzbare Beanstandungen an den Implementierer. Dieser commitet Korrekturen und einen angehängten Log-Eintrag unter Beibehaltung der ursprünglichen Basis. Gib die vollständig aktualisierte Änderung an den unabhängigen Reviewer zurück; vorherige Beanstandungen benötigen Nachweise für die Behebung, keine frische leere Checkliste. Bewahre alle Review-Durchläufe auf. Der Reviewer kann wiederverwendet werden, solange er unabhängig vom Autor bleibt; keine Rolle darf Code genehmigen, den sie gerade selbst geschrieben hat.
• Wenn die Implementierung ein ungültiges Design offenbart, leite die Entscheidung zurück durch den Planer und den übergeordneten Koordinator, bevor du fortfährst. Wende dieselbe Korrekturprüfung auf betroffene abhängige Einheiten an; zusätzliche unabhängige Bewertung benötigt eine spezifische folgenreiche Unsicherheit, nicht bloß einen geänderten Plan-Blob. Lasse xwork nicht stillschweigend den Umfang erweitern oder die schwierige Entscheidung bis zum Coden aufschieben.

Beanstandungen beheben und ehrlich abschließen

Fahre ohne Routine-Bestätigung fort, frage aber, wenn Absicht, Umfang, Berechtigungen oder ein wesentlicher Kompromiss tatsächlich den Benutzer erfordern. Stoppe bei nicht verfügbaren erforderlichen Tools/Prüfungen oder bei strittigen Entscheidungen. Setze gewöhnliche Reparaturen fort, solange sie Fortschritte machen; wenn ein Durchlauf denselben fehlgeschlagenen Ansatz wiederholt, eine Benutzerentscheidung benötigt oder ein explizites Budget überschreitet, stoppe und berichte die ungelösten Nachweise, anstatt eine endlose Review-Schleife zu erzeugen. Akzeptiere niemals einen Mangel, um den Zyklus abzuschließen.

Vor dem Erfolg überprüft der übergeordnete Koordinator:

1. Jede angeforderte Ausführungseinheit ist implementiert, erforderliche Prüfungen haben tatsächlich bestanden, und ihr endgültiger Code hat ein unabhängiges, akzeptiertes Arbeits-Review.
2. Jede Code-/Test-/Konfigurationsänderung nach dem geprüften Code-HEAD einer Einheit wird durch den akzeptierten Review-Bereich einer späteren Einheit auf dem integrierten Task-Checkout abgedeckt, oder geht zurück durch Verifikation und Arbeits-Review. Bekannte Änderungen nur im Workflow-Log benötigen kein erneutes Code-Review. Erfasse alle Commits/Diffs, nicht nur passende Pfadnamen. Korrekturen von Integrationskonflikten und gebrochene frühere Verträge erfordern erneute Prüfungen/Reviews; eine später akzeptierte Einheit entschuldigt sie nicht automatisch.
3. Arbeitslogs enthalten den akzeptierten Plan/Kurzbrief, die festgelegte Basis, den endgültig geprüften HEAD, die tatsächlichen Commits, die nativen Konversations-IDs des übergeordneten Koordinators/Arbeiters (oder explizite Gründe für Nichtverfügbarkeit), ausgeführte/wiederverwendete Verifikationsnachweise und Review-Pfade. Setze sie auf complete und führe verbleibende task-eigene Einträge als complete fest.
4. Alle task-eigenen Änderungen und neuen Einträge sind auf dem gemeldeten Branch festgeschrieben. Überprüfe mit Git, bewahre nicht zusammenhängende Arbeit auf und pushe nicht oder merge nicht automatisch in einen anderen Branch. Ursprüngliche Code-HEADS müssen nicht dem endgültigen HEAD entsprechen, da spätere Commits Einträge oder andere unabhängig akzeptierte Einheiten enthalten.
5. Speichere die Sitzungsherkunft jedes Kindes und integriere/speichere jedes Ergebnis, bevor Sitzungen beendet werden, die ihre Branches/Arbeitsbäume entfernen. Hinterlasse ein erreichbares committetes Ergebnis und befolge die Bereinigungsregeln des Hosts. Fehlgeschlagene Zyklen melden teilweise Commits und Hinderungsgründe, nicht Erfolg.

Gib eine knappe Zusammenfassung zurück: Ergebnisse, Aufgaben-IDs, Artefaktpfade, Branch und endgültige Commit-IDs, Prüfungen, Review-Verdikte und verbleibende Einschränkungen. Der übergeordnete Koordinator besitzt diese Verifikation und den endgültigen Bericht; verkette nicht einfach Worker-Zusammenfassungen.