Cotal-AI/gestionnaires-de-fonctionnalités-parallèles

Gestionnaires de fonctionnalités parallèles

Utilisez la hiérarchie maillée Cotal en direct :

• La session actuelle est le coordinateur. Elle crée l'isolation, définit les règles, surveille la progression et relaie les décisions. Elle ne duplique pas l'implémentation ni la revue du panel.
• Chaque fonctionnalité possède un gestionnaire ancré dans son propre worktree Git et sa propre branche. Le gestionnaire est responsable de l'ensemble du cycle planification -> implémentation -> revue -> test -> commit.
• Chaque gestionnaire génère trois pairs ou plus en lecture seule / revue uniquement dans un salon dédié : ingénieur, sécurité et critique au minimum.
• Près de la porte finale, chaque gestionnaire ajoute un réviseur indépendant à froid, briefé sous la compétence cold-review, qui est la source unique de la manière dont ce siège est briefé, isolé et noté. C'est un contrôle sur le panel plutôt qu'un quatrième panéliste.

Modèles : les panels multi-fournisseurs sont une règle de correction, pas une préférence

Aucun deux sièges dont l'accord est déterminant ne peut partager une famille de modèles. Une conclusion confirmée par un siège de la même famille que celui qui l'a émise est un écho, pas une confirmation. Un panel de trois réviseurs du même modèle a approuvé une tête contenant un défaut que tous les trois ont manqué, et ce qui l'a révélé a été une lecture formulée différemment plutôt qu'un quatrième vérificateur.

Formulez cela ainsi plutôt que comme un nombre de sièges. La disponibilité est une propriété du moment, pas du fournisseur : le même modèle a rejoint et livré une heure et n'a pas réussi à rejoindre l'heure suivante, sur le même hôte avec les mêmes outils. Une règle formulée comme « N fournisseurs distincts » est insatisfaisable sur une flotte dégradée et silencieusement ainsi, et une règle qui peut être brisée par l'horloge est ignorée plutôt qu'obéie. cold-review porte l'ordre de dégradation et le plancher.

Épinglez le modèle explicitement à la génération ET dans la personnalité, car une capacité non enregistrée est non notée en pratique : un réviseur dont l'effort ou le modèle n'a été enregistré par personne produit un verdict que personne ne peut évaluer par la suite.

Les gestionnaires peuvent exécuter un modèle plus fort que leurs réviseurs. Les réviseurs ne doivent pas exécuter le même modèle que le coordinateur, afin que le panel ne puisse pas hériter des angles morts du coordinateur.

Vérifiez les identifiants exacts des modèles par rapport au propre catalogue du connecteur avant la génération, et traitez un niveau d'effort de raisonnement déclaré comme non vérifié jusqu'à ce qu'un siège ait réellement démarré avec ce niveau : un catalogue peut déclarer des niveaux que le fournisseur refuse, et un niveau refusé tue le siège au démarrage.

Règles strictes

• Ne changez jamais la branche du coordinateur. Créez des worktrees à partir d'une base nommée et commitée.
• Un gestionnaire par fonctionnalité, un réviseur par voie de salon, et un réviseur indépendant à froid par fonctionnalité. Sélectionnez le contact et la destination de ce siège sous cold-review. Une destination fichier est un repli normatif uniquement et ne peut satisfaire une porte qui nécessite une identité de publication attestée par le courtier. Aucune instance sœur ou ramification de test à moins que l'utilisateur ne le demande.
• Seuls les gestionnaires modifient leur worktree de fonctionnalité. Les réviseurs lisent uniquement, exécutent des vérifications non mutatives et publient des conclusions avec des références fichier/ligne.
• Chaque fonctionnalité utilise un salon de panel, review.<slug-fonctionnalité>, plus un salon dédié d'enregistrement à froid, review.<slug-fonctionnalité>.cold-record. Gardez les accusés de réception et les bavardages de statut hors du salon du panel ; utilisez-le pour les plans, les conclusions, les dispositions motivées, les demandes de revue de code et les résultats finaux.
• Le réviseur indépendant à froid n'est pas sur ce salon. Son isolation, son briefing et son reporting sont gérés par cold-review ; appliquez-les là plutôt que de les répéter par voie.
• Les décisions produit/design voyagent par DM : gestionnaire -> coordinateur -> utilisateur -> coordinateur -> gestionnaire. Un gestionnaire ne doit pas deviner à travers un choix conséquent non résolu.
• Ne fusionnez jamais, ne poussez jamais, n'ouvrez jamais de PR, ni ne supprimez de worktrees à moins que l'utilisateur ne le demande.
• Ne perturbez jamais le courtier maillé en direct. Les tests utilisent des espaces jetables et des ports aléatoires élevés ; tuez les processus de test par PID exact, jamais un pkill large.

1. Établir la matrice des fonctionnalités

Pour chaque fonctionnalité demandée, choisissez et enregistrez :

Champ	Exemple
Fonctionnalité	exportation des canaux
Slug	exportation-canaux
Branche	feat/exportation-canaux
Worktree	chemin frère tel que Cotal-feature-exportation-canaux
Personnalité du gestionnaire	mgr-exportation-canaux
PR	numéro exact, ou aucun jusqu'à ce qu'un existe
Salon	review.exportation-canaux
Contrat	comportement concret, limites, tests et non-objectifs connus

Résolvez les collisions de branche/chemin avant de créer quoi que ce soit. Inspectez git status, git worktree list --porcelain, et les branches existantes. Ne nettoyez pas et ne revenez pas sur un état sale non lié.

Créez les worktrees séquentiellement car ils mutent les métadonnées Git partagées :

git worktree add -b feat/<slug> /chemin/absolu/frere/Cotal-feature-<slug> <base>

Utilisez le même commit de base pour toutes les fonctionnalités, sauf si l'utilisateur veut explicitement un travail empilé.

2. Rendre le contexte du dépôt privé disponible

Avant le lancement, vérifiez que chaque worktree peut lire .internal/plans/STATUS.md et les directives pertinentes. Normalement git submodule update --init .internal suffit.

Si l'initialisation échoue parce que le super-projet épingle un commit indisponible :

1. Comparez le pointeur commité (git ls-tree <base> .internal) avec le HEAD local actif du sous-module (git -C .internal rev-parse HEAD). C'est une dérive de l'état du dépôt, pas un problème ACL Cotal.
2. Préférez corriger/publier le commit de sous-module prévu et le pointeur du super-projet lorsque cela est autorisé.
3. Pour une exécution parallèle temporaire, matérialisez le commit .internal local connu bon indépendamment dans chaque worktree de fonctionnalité à partir du dépôt de sous-module local actif.
4. Dites aux gestionnaires que le super-projet peut afficher M .internal ; ils doivent le lire mais ne jamais le mettre en scène, le modifier ou l'inclure dans les commits de fonctionnalité.

Ne laissez pas les gestionnaires bloqués simplement parce qu'un nouveau worktree ne peut pas récupérer un commit privé qui est déjà disponible et vérifié localement. Ne faites pas non plus comme si le décalage était propre ; signalez la réparation permanente nécessaire.

3. Créer d'abord les personnalités du gestionnaire et des réviseurs avec la politique

Les agents gestionnaires ont besoin de capabilities: [spawn] plus des ACL de salon. Les agents réviseurs ont besoin d'ACL de salon et ne doivent pas avoir spawn. cotal_persona ne peut pas accorder de politique, et cotal_spawn ne peut pas remplacer allowSubscribe ou allowPublish, donc rédigez chaque fichier de personnalité avant de générer. Ces fichiers sont locaux/ignorés dans ce dépôt. Une machine propre qui n'a qu'une personnalité par défaut ne peut pas constituer le panel : les noms de génération ci-dessous échouent à moins que ces fichiers n'existent, et une personnalité locale restante n'est pas un substitut car ses autorisations peuvent être manquantes ou plus larges que la voie.

---
name: mgr-<slug>
role: feature-manager
model: <modèle gestionnaire épinglé>
description: Possède <fonctionnalité> et son panel de revue.
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---

Rédigez les fichiers correspondants pour les trois sièges du panel et le siège à froid avant toute génération. Donnez à chaque personnalité de réviseur un nom de fichier limité à la voie, tel que review-<slug>-ingenieur ; le catalogue de personnalités est partagé par les voies concurrentes, donc les noms de fichiers génériques entrent en collision même lorsque les worktrees et les salons ne le font pas. Les personnalités du panel s'abonnent et publient uniquement sur review.<slug>. La personnalité à froid liste subscribe et allowSubscribe vides afin que la non-jonction soit une propriété du siège, pas une instruction, et peut publier uniquement sur review.<slug>.cold-record. Ne réutilisez pas et ne redéfinissez pas une personnalité de réviseur d'une autre voie.

---
name: review-<slug>-ingenieur
role: reviewer
model: <modèle panel épinglé, famille A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---

---
name: review-<slug>-freelance
role: reviewer
model: <modèle à froid épinglé, pas la famille de l'auteur>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---

Répétez le modèle du panel pour review-<slug>-securite et review-<slug>-critique avec différentes familles de modèles. Si un arbitre est ultérieurement requis, rédigez review-<slug>-arbitre de la même manière que le siège à froid, avec subscribe et allowSubscribe vides plus une autorisation de publication dédiée sur le salon d'enregistrement, avant de le générer.

L'invite du gestionnaire doit inclure tout ce qui suit :

• Contrat exact de la fonctionnalité, branche et chemin absolu du worktree.
• Posséder la fonctionnalité de bout en bout et commiter uniquement les fichiers de fonctionnalité prévus.
• Lire les instructions du dépôt, la documentation actuelle et .internal avant de modifier.
• Rejoindre review.<slug> en premier.
• Générer uniquement les personnalités rédigées dans cette section. Générer review-<slug>-ingenieur, review-<slug>-securite et review-<slug>-critique, placés de sorte qu'aucun deux d'entre eux dont l'accord est déterminant ne partage une famille de modèles. C'est la règle ordinale ci-dessus et non un nombre de sièges. Lorsque l'ensemble des fournisseurs est court, nommez la collision mécaniquement et la classe qu'elle laisse non couverte. Nommer est une divulgation, pas un achèvement : un panel dont les approbations déterminantes sont des échos de même famille ne peut pas achever, y compris A, A, A et A, B, A. Ne traitez pas un panel doté mais en collision comme une porte passante. Donnez à chacun son propre worktree détaché comme cwd. Un réviseur note dans son propre arbre, jamais dans l'arbre qu'il note, et « lecture seule » doit nommer les verbes d'écriture git explicitement (checkout, switch, stash, reset, clean, restore) plutôt que de dire seulement « ne modifiez pas la source ».
• Envoyer un DM à chaque identité de réviseur retournée pour rejoindre le salon et rester en lecture/revue uniquement.
• Exécuter la revue du plan avant de modifier, la revue du code/des tests après l'implémentation, intégrer les conclusions valides et demander aux trois une disposition finale.
• Après que le panel et l'implémentation convergent, générer exactement un review-<slug>-freelance dans son propre worktree détaché et le briefer sous la compétence cold-review, qui possède ce que ce siège reçoit, où va son verdict, ce que le verdict lie, et comment les règles se dégradent lorsque l'ensemble des fournisseurs est court. Ne répétez rien ici.
• Résoudre les conclusions à froid sous la règle canonique de cold-review, jamais en disant à ce siège de reconsidérer. Si le gestionnaire a rédigé la modification et qu'un bloqueur nécessite une réfutation indépendante, n'envoyez au coordinateur que la conclusion exacte-sha et l'artefact. Le coordinateur provisionne un nouveau review-<slug>-arbitre dans son propre worktree détaché ; ce siège n'a eu aucune part dans la rédaction, la notation ou la supervision de la voie, ne partage pas une famille de modèles avec l'auteur et ne reçoit aucun des raisonnements de l'auteur. Le coordinateur provisionne l'arbitre mais ne fait pas office d'arbitre. Si une intégration modifie le code, renvoyez le résultat au panel du salon pour un autre passage final et ré-épinglez le siège à froid sur le nouveau sha avec sa limite de livraison explicitement réinitialisée par écrit. Si ce siège est parti, rédigez une nouvelle personnalité à froid avec subscribe et allowSubscribe vides plus uniquement son autorisation de publication dédiée sur le salon d'enregistrement, générez-le et briefez-le sous cold-review sur le nouveau sha en tant que nouveau siège à livraison unique. C'est un successeur, pas une troisième voie de fermeture pour l'ancien sha.
• Re-résoudre la tête comme une action, pas comme une assertion ultérieure. Au briefing, à toute réclamation d'achèvement, et à nouveau avant la fusion, le gestionnaire ou le coordinateur résout d'abord la cible de la revue. Pour une PR, exécutez git ls-remote origin refs/pull/<n>/head et recoupez gh pr view <n> --json headRefOid. Pour une branche sans PR, résolvez git ls-remote origin refs/heads/<branche> et omettez la recoupe API propre à la PR. Récupérez l'objet résolu dans le worktree de revue détaché s'il n'est pas déjà présent, puis exécutez git cat-file -t sur cet objet avec un témoin connu bon et un objet connu manquant d'identifiant pleine largeur, tel que quarante zéros, qui doit échouer. Ne faites pas le témoin négatif en ajoutant un caractère à l'identifiant réel : Git peut résoudre l'identifiant d'objet valide principal et retourner un succès. Nommez l'acteur qui a exécuté les instruments. Si les instruments applicables sont en désaccord, arrêtez-vous. Un verdict ou une réfutation qui nomme un sha différent ne ferme pas cette tête.
• Exécuter les tests pertinents lui-même. Les réviseurs ne modifient pas la source.
• Escalader uniquement les choix conséquents non résolus avec cette structure exacte :

DÉCISION NÉCESSAIRE : <question en une ligne>
Options : <A> ; <B> ; ...
Recommandation : <recommandation du gestionnaire et pourquoi>
Impact : <comportement observable / compatibilité / risque>
Bloqué : <ce qui ne peut pas continuer> ; En cours : <ce qui peut continuer>

• À l'achèvement, envoyer un DM au coordinateur avec l'id du commit, les tests exécutés, les trois dispositions du panel, le verdict à froid terminal et toute réfutation publique, et les risques résiduels.

4. Créer les salons et lancer les gestionnaires

Créez le salon du panel et le salon d'enregistrement à froid dédié avant d'inviter l'équipe, avec la relecture activée et une courte note d'opérateur. Ensuite, générez chaque gestionnaire via cotal_spawn :

name: mgr-<slug>
role: feature-manager
agent: <connecteur>
model: <modèle gestionnaire épinglé>
cwd: /chemin/absolu/vers/worktree-fonctionnalite

Lancez les gestionnaires en parallèle seulement après que tous les worktrees, personnalités et salons existent. Suivez l'identité du réviseur retournée, pas un nom supposé ; un lancement redémarré ou dupliqué peut encore être numéroté automatiquement même si le nom du fichier de personnalité est limité à la voie.

Vérifiez avec cotal_roster que chaque gestionnaire apparaît et détient son panel complet. Ne générez pas de doublons semblant manquants prématurément ; laissez du temps de démarrage et revérifiez d'abord.

Une génération qui signale un délai d'attente n'est pas une preuve que la génération a échoué. Elle peut déjà avoir réussi, et réessayer soumet un deuxième objectif qui duplique l'effet. Lisez le résultat de la liste des processus avant d'agir, et ne réessayez jamais sur un seul délai d'attente.

Vérifiez un siège par RÉPONSE, jamais par présence. Un siège peut être signalé comme en cours d'exécution et être silencieusement inaccessible. Demandez un artefact nonce qu'il doit produire, tel qu'un echo d'un jeton aléatoire joint au short commit sur lequel il est assis, et vérifiez la sortie brute. Une poignée de main qui énonce la réponse attendue (« confirmez que vous êtes à sur ») est suggestive : une réponse compatible echo prouve que quelque chose peut refléter du texte, pas qu'un shell a tourné.