Cotal-AI/parallele-Feature-Manager

Parallel-Feature-Manager

Nutze das Live-Cotal-Mesh als Hierarchie:

• Die aktuelle Session ist der Koordinator. Er schafft Isolation, setzt Richtlinien, überwacht den Fortschritt und leitet Entscheidungen weiter. Er führt keine Implementierung oder Gremiumsprüfung durch.
• Jedes Feature erhält einen Manager, der in einem eigenen Git-Worktree und Branch verwurzelt ist. Der Manager besitzt den vollständigen Plan -> Implementierung -> Review -> Test -> Commit-Zyklus.
• Jeder Manager erzeugt drei oder mehr rein lesende/prüfende Peers in einem dedizierten Kanal: mindestens Engineer, Security und Critic.
• Kurz vor dem finalen Gate fügt jeder Manager einen unabhängigen Cold-Review-Prüfer hinzu, der unter dem cold-review Skill instruiert wird, das die einzige Quelle dafür ist, wie dieser Sitz instruiert, isoliert und bewertet wird. Es ist eine Kontrolle des Gremiums, kein viertes Gremiumsmitglied.

Modelle: Herstellerübergreifende Gremien sind eine Korrektheitsregel, keine Präferenz

Zwei Sitze, deren Zustimmung lasttragend ist, dürfen keine gemeinsame Modellfamilie haben. Eine von einem Sitz derselben Familie wie derjenige, der sie festgestellt hat, bestätigte Feststellung ist ein Echo, keine Bestätigung. Ein Gremium von drei gleichen Modellprüfern hat einen Head mit einem Defekt genehmigt, den alle drei übersehen haben, und was ihn aufgedeckt hat, war eine anders gerahmte Lektüre und kein vierter Prüfer.

Formuliere es so und nicht als Anzahl. Verfügbarkeit ist eine Eigenschaft des Augenblicks, nicht des Herstellers: dasselbe Modell ist eine Stunde beigetreten und hat geliefert und ist die nächste Stunde nicht beigetreten, auf demselben Host mit denselben Werkzeugen. Eine als „N verschiedene Anbieter“ formulierte Regel ist bei einer degradierten Flotte nicht erfüllbar und zwar stillschweigend, und eine Regel, die von der Uhr gebrochen werden kann, wird stillschweigend ignoriert, statt befolgt. cold-review trägt die Degradationsreihenfolge und das Minimum.

Pinne das Modell explizit sowohl beim Spawn als auch in der Persona, denn nicht aufgezeichnete Fähigkeit ist in ihrer Wirkung unbewertet: Ein Prüfer, dessen Aufwand oder Modell niemand aufgezeichnet hat, erzeugt ein Urteil, das danach niemand abwägen kann.

Manager dürfen ein stärkeres Modell als ihre Prüfer verwenden. Prüfer sollten nicht dasselbe Modell wie der Koordinator verwenden, damit das Gremium nicht die blinden Flecken des Koordinators erbt.

Überprüfe die genauen Modellkennungen im Katalog des Connectors, bevor du spawnst, und behandle eine deklarierte Reasoning-Effort-Stufe als unbestätigt, bis ein Sitz tatsächlich damit gestartet ist: Ein Katalog kann Stufen deklarieren, die der Anbieter verweigert, und eine verweigerte Stufe tötet den Sitz beim Start.

Harte Regeln

• Wechsle niemals den Branch des Koordinators. Erstelle Worktrees von einem benannten committierten Basis-Commit aus.
• Ein Manager pro Feature, ein Prüfer pro Kanallane und ein unabhängiger Cold-Review-Prüfer pro Feature. Wähle den Kontakt und das Ziel dieses Sitzes unter cold-review. Ein Dateiziel ist ein Standard-Fallback und kann kein Gate erfüllen, das eine broker-beglaubigte Posteridentität erfordert. Keine Geschwisterinstanzen oder Tester-Fan-Out, es sei denn, der Benutzer fordert es an.
• Nur Manager bearbeiten ihren Feature-Worktree. Prüfer lesen nur, führen nicht mutierende Prüfungen durch und posten Ergebnisse mit Datei-/Zeilenverweisen.
• Jedes Feature verwendet einen Gremiumskanal, review.<feature-slug>, plus einen dedizierten Cold-Record-Kanal, review.<feature-slug>.cold-record. Halte Bestätigungen und Status-Chatter vom Gremiumskanal fern; verwende ihn für Pläne, Feststellungen, begründete Entscheidungen, Code-Review-Anfragen und Endergebnisse.
• Der unabhängige Cold-Review-Prüfer ist nicht in diesem Kanal. Seine Isolation, Instruktion und Berichterstattung werden von cold-review verwaltet; setze sie dort durch, anstatt sie pro Lanes neu zu formulieren.
• Produkt-/Designentscheidungen reisen per DM: Manager -> Koordinator -> Benutzer -> Koordinator -> Manager. Ein Manager darf eine ungelöste folgenreiche Wahl nicht erraten.
• Führe niemals Merge, Push, PR-Erstellung oder Worktree-Entfernung durch, es sei denn, der Benutzer fragt danach.
• Störe niemals den Live-Mesh-Broker. Tests verwenden Wegwerfbereiche und zufällige High-Ports; beende Testprozesse exakt per PID, niemals mit breitem pkill.

1. Erstelle die Feature-Matrix

Für jedes angeforderte Feature wähle und notiere:

Feld	Beispiel
Feature	Kanäle exportieren
Slug	channels-export
Branch	feat/channels-export
Worktree	Pfad zum Geschwisterverzeichnis, z.B. Cotal-feature-channels-export
Manager Persona	mgr-channels-export
PR	exakte Nummer oder none, falls noch keiner existiert
Kanal	review.channels-export
Vertrag	konkretes Verhalten, Grenzen, Tests und bekannte Nicht-Ziele

Löse Branch-/Pfadkollisionen, bevor du etwas erstellst. Überprüfe git status, git worktree list --porcelain und vorhandene Branches. Bereinige oder setze nicht zusammenhängenden schmutzigen Zustand nicht zurück.

Erstelle die Worktrees sequenziell, da sie gemeinsame Git-Metadaten mutieren:

git worktree add -b feat/<slug> /absolute/sibling/Cotal-feature-<slug> <base>

Verwende denselben Basis-Commit für alle Features, es sei denn, der Benutzer wünscht explizit gestapelte Arbeit.

2. Stelle privaten Repository-Kontext bereit

Überprüfe vor dem Start, dass jeder Worktree .internal/plans/STATUS.md und die relevanten Richtlinien lesen kann. Normalerweise ist git submodule update --init .internal ausreichend.

Wenn die Initialisierung fehlschlägt, weil das Superprojekt einen nicht verfügbaren Commit pinnt:

1. Vergleiche den committierten Pointer (git ls-tree <base> .internal) mit dem aktiven lokalen Submodule HEAD (git -C .internal rev-parse HEAD). Dies ist ein Repository-Status-Drift, kein Cotal-ACL-Problem.
2. Bevorzuge, wenn autorisiert, die Veröffentlichung des beabsichtigten Submodule-Commits und des Superprojekt-Pointers.
3. Für einen temporären parallelen Durchlauf materialisiere den bekannten guten lokalen .internal-Commit unabhängig in jedem Feature-Worktree aus dem aktiven lokalen Submodule-Repository.
4. Teile den Managern mit, dass das Superprojekt M .internal anzeigen kann; sie müssen es lesen, aber niemals stagen, bearbeiten oder in Feature-Commits aufnehmen.

Halte Manager nicht blockiert, nur weil ein frischer Worktree keinen privaten Commit abrufen kann, der bereits lokal verfügbar und verifiziert ist. Tue auch nicht so, als ob die Abweichung sauber wäre; melde die dauerhafte Reparatur, die erforderlich ist.

3. Erstelle zuerst Manager- und Prüfer-Personas mit Richtlinien

Manager-Agenten benötigen capabilities: [spawn] plus Kanal-ACLs. Prüfer-Agenten benötigen Kanal-ACLs und dürfen kein spawn haben. cotal_persona kann keine Richtlinie gewähren, und cotal_spawn kann allowSubscribe oder allowPublish nicht überschreiben, daher autorisiere jede Persona-Datei vor dem Spawn. Diese Dateien sind lokal/ignoriert in diesem Repo. Eine saubere Maschine, die nur eine Standard-Persona hat, kann das Gremium nicht besetzen: Die Spawn-Namen unten schlagen fehl, es sei denn, diese Dateien existieren, und eine übrig gebliebene lokale Persona ist kein Ersatz, da ihre Berechtigungen fehlen oder breiter als die Lane sein können.

---
name: mgr-<slug>
role: feature-manager
model: <gepinntes Manager-Modell>
description: Besitzt <feature> und sein Review-Gremium.
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---

Autorisiere passende Dateien für die drei Gremiumssitze und den Cold-Sitz vor jedem Spawn. Gib jedem Prüfer-Persona einen auf die Lane beschränkten Dateinamen wie review-<slug>-engineer; der Persona-Katalog wird von gleichzeitigen Lanes gemeinsam genutzt, daher kollidieren generische Dateinamen, selbst wenn die Worktrees und Kanäle dies nicht tun. Gremiumspersonas abonnieren und veröffentlichen nur auf review.<slug>. Die Cold-Persona listet leere subscribe und allowSubscribe auf, sodass Nicht-Beitreten eine Eigenschaft des Sitzes ist, keine Anweisung, und darf nur an review.<slug>.cold-record veröffentlichen. Verwende keine Prüfer-Persona aus einer anderen Lane wieder oder definiere sie neu.

---
name: review-<slug>-engineer
role: reviewer
model: <gepinntes Gremiumsmodell, Familie A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---

---
name: review-<slug>-freelance
role: reviewer
model: <gepinntes Cold-Modell, nicht die Familie des Autors>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---

Wiederhole die Gremiumsvorlage für review-<slug>-security und review-<slug>-critic mit unterschiedlichen Modellfamilien. Falls später ein Schiedsrichter benötigt wird, autorisiere review-<slug>-referee auf dieselbe Weise wie den Cold-Sitz, mit leerem subscribe und allowSubscribe plus einem dedizierten allowPublish-Grant für den Record-Kanal, vor dem Spawn.

Der Manager-Prompt muss alle folgenden Punkte enthalten:

• Exakter Feature-Vertrag, Branch und absoluter Worktree-Pfad.
• Besitze das Feature durchgehend und committe nur die beabsichtigten Feature-Dateien.
• Lies Repo-Anweisungen, aktuelle Dokus und .internal, bevor du bearbeitest.
• Tritt zuerst dem review.<slug>-Kanal bei.
• Spawne nur Personas, die in diesem Abschnitt autorisiert sind. Spawne review-<slug>-engineer, review-<slug>-security und review-<slug>-critic, so platziert, dass keine zwei von ihnen, deren Zustimmung lasttragend ist, eine gemeinsame Modellfamilie teilen. Das ist die Ordnungsregel oben und keine Anzahl. Wo der Anbietersatz kurz ist, nenne die Kollision mechanisch und die Klasse, die sie ungedeckt lässt. Benennung ist Offenlegung, nicht Vollständigkeit: ein Gremium, dessen lasttragende Genehmigungen gleichartige Echos sind, kann nicht abschließen, einschließlich A, A, A und A, B, A. Behandle einen besetzten, aber kollidierten Gremium nicht als bestandenes Gate. Gib jedem seinen eigenen abgetrennten Worktree als cwd. Ein Prüfer bewertet in seinem eigenen Baum, niemals in dem Baum, den er bewertet, und „schreibgeschützt“ muss die Git-Schreibverben explizit nennen (checkout, switch, stash, reset, clean, restore), anstatt nur zu sagen „bearbeite keine Quelle“. DM jede zurückgegebene Prüfer-Identität, dem Kanal beizutreten und nur lesend/prüfend zu bleiben. Führe Plan-Review vor der Bearbeitung, Code-/Test-Review nach der Implementierung durch, falte gültige Feststellungen und frage alle drei nach einem endgültigen Befund. Nachdem Gremium und Implementierung konvergiert sind, spawne genau einen review-<slug>-freelance in seinem eigenen abgetrennten Worktree und instruiere ihn unter dem cold-review Skill, das besitzt, was diesem Sitz gegeben wird, wohin sein Urteil geht, was das Urteil bindet und wie die Regeln degradieren, wenn der Anbietersatz kurz ist. Wiederhole hier nichts davon. Löse Cold-Feststellungen unter cold-reviews kanonischer Regel, niemals, indem du diesen Sitz aufforderst, zu überdenken. Wenn der Manager die Änderung verfasst hat und ein Blocker eine unabhängige Widerlegung benötigt, sende dem Koordinator nur die genaue SHA-Feststellung und das Artefakt. Der Koordinator stellt einen frischen review-<slug>-referee in seinem eigenen abgetrennten Worktree bereit; dieser Sitz hatte keinen Anteil am Verfassen, Bewerten oder Überwachen der Lane, teilt keine Modellfamilie mit dem Autor und erhält keinerlei Begründung des Autors. Der Koordinator stellt den Schiedsrichter bereit, fungiert aber nicht als dieser. Wenn eine Faltung Code ändert, gib das Ergebnis zur erneuten finalen Prüfung an das Kanalgremium zurück und pinne den Cold-Sitz auf die neue SHA mit explizit schriftlich zurückgesetztem Lieferlimit. Wenn dieser Sitz weg ist, autorisiere eine frische Cold-Persona mit leerem subscribe und allowSubscribe plus nur seinem dedizierten allowPublish-Grant für den Record-Kanal, spawne sie und instruiere sie unter cold-review auf der neuen SHA als neuen Sitz mit einer Lieferung. Das ist ein Nachfolger, kein dritter Schließungsweg für die alte SHA. Löse den Head als Aktion auf, nicht als spätere Behauptung. Bei der Instruktion, bei jedem Abschlussanspruch und erneut vor dem Merge, löst der Manager oder Koordinator zuerst das Review-Ziel auf. Führe für einen PR git ls-remote origin refs/pull/<n>/head aus und überprüfe kreuzweise gh pr view <n> --json headRefOid. Für einen Branch ohne PR löse git ls-remote origin refs/heads/<branch> auf und verzichte auf die PR-only API Kreuzprüfung. Hole das aufgelöste Objekt in den abgetrennten Review-Worktree, falls es nicht bereits vorhanden ist, führe dann git cat-file -t für dieses Objekt mit einer bekannten guten Kontrolle und einer bekannten fehlenden vollen Objekt-ID, wie vierzig Nullen, die fehlschlagen muss, aus. Verwende keine negative Kontrolle, indem du ein Zeichen an die echte ID anhängst: Git kann die gültige führende Objekt-ID auflösen und Erfolg zurückmelden. Nenne den Akteur, der die Instrumente ausgeführt hat. Wenn anwendbare Instrumente widersprechen, stoppe. Ein Urteil oder eine Widerlegung, das/ die eine andere SHA nennt, schließt diesen Head nicht. Führe die relevanten Tests selbst aus. Prüfer bearbeiten keine Quelle. Eskaliere nur ungelöste folgenreiche Entscheidungen mit dieser exakten Struktur:

ENTSCHEIDUNG ERFORDERLICH: <einzeilige Frage>
Optionen: <A>; <B>; ...
Empfehlung: <Empfehlung des Managers und warum>
Auswirkung: <beobachtbares Verhalten / Kompatibilität / Risiko>
Blockiert: <was nicht fortgesetzt werden kann>; Fortsetzend: <was fortgesetzt werden kann>

• DM dem Koordinator bei Fertigstellung die Commit-ID, ausgeführten Tests, alle drei Gremiumsbefunde, das abschließende Cold-Urteil und alle öffentlichen Widerlegungen sowie Restrisiken.

4. Erstelle Kanäle und starte Manager

Erstelle den Gremiumskanal und den dedizierten Cold-Record-Kanal, bevor du das Team einlädst, mit aktiviertem Replay und einer kurzen Operator-Notiz. Spawne dann jeden Manager über cotal_spawn:

name: mgr-<slug>
role: feature-manager
agent: <connector>
model: <gepinntes Manager-Modell>
cwd: /absolute/path/to/feature-worktree

Starte Manager parallel erst, nachdem alle Worktrees, Personas und Kanäle existieren. Verfolge die zurückgegebene Prüfer-Identität, nicht einen angenommenen Namen; ein neu gestarteter oder duplizierter Start kann dennoch automatisch nummeriert werden, obwohl der Persona-Dateiname auf die Lane beschränkt ist.

Überprüfe mit cotal_roster, dass jeder Manager erscheint und sein volles Gremium hält. Spawne nicht vorzeitig vermisste Duplikate; erlaube Startzeit und überprüfe zuerst erneut.

Ein Spawn, der einen Timeout meldet, ist kein Beweis dafür, dass der Spawn fehlgeschlagen ist. Er könnte bereits erfolgreich sein, und ein erneuter Versuch sendet ein zweites Ziel, das den Effekt dupliziert. Lies das Ergebnis aus der Prozessliste, bevor du handelst, und versuche es niemals nur aufgrund eines Timeouts erneut.

Überprüfe einen Sitz durch ANTWORT, niemals durch Anwesenheit. Ein Sitz kann als laufend gemeldet werden und stillschweigend unerreichbar sein. Fordere ein Nonce-Artefakt an, das er produzieren muss, wie ein echo eines zufälligen Tokens, verbunden mit dem kurzen Commit, auf dem er sitzt, und überprüfe die Rohausgabe. Ein Handshake, der die erwartete Antwort angibt („bestätige, dass du unter auf bist“), ist suggestiv: Eine Echo-kompatible Antwort beweist, dass etwas Text spiegeln kann, nicht, dass eine Shell ausgeführt wurde.

Der unabhängige Prüfer ist beabsichtigt.