Compétence d'orchestration

Cette compétence est destinée à un orchestrateur (généralement un agent préconfiguré Admin) qui coordonne d'autres agents et humains tout au long du cycle de vie AI-DLC au lieu de faire tout le travail lui-même. L'orchestrateur décompose le travail, confie chaque pièce à un propriétaire choisi, exécute des examinateurs indépendants comme portes de contrôle qualité, et verrouille les portes d'approbation/vérification gérées par l'humain — mais ne livre jamais seul.

Il complète les autres compétences plutôt que de les remplacer :

• /yolo — un seul agent pilote tout le pipeline seul. L'orchestration est l'inverse : plusieurs agents, chacun propriétaire d'une pièce, coordonnés par vous.
• /idea, /proposal, /develop, /review, /quick-dev — une seule étape que vous exécutez vous-même. L'orchestration est la couche au-dessus : vous décidez qui exécute chaque étape.

Quand utiliser cette compétence

Utilisez-la quand plus d'un agent (ou agent + humain) touchera au travail et que quelqu'un doit les maintenir cohérents :

• Vous possédez un thème / épique / idée contenant qui se décompose en plusieurs idées enfants indépendantes, et vous voulez confier chacune à un travailleur spécifique (cas motivant : un propriétaire de thème donne un enfant à Codex, un autre à un agent Claude dev, un autre à un humain).
• Une proposition approuvée a un DAG de tâches et vous voulez plusieurs agents développeurs travaillant sur les tâches débloquées en vagues parallèles.
• Vous avez besoin d'une revue adversariale indépendante de la proposition / tâche / fonctionnalité de quelqu'un d'autre avant qu'elle progresse.
• Vous êtes le propriétaire responsable et devez maintenir un assignataire responsable par idée tandis que le travail s'étend.

Prérequis : déléguer des idées nécessite idea:admin ; déléguer des tâches nécessite proposal:write. Exécutez d'abord chorus_checkin() pour confirmer votre ensemble de permissions.

Primitives de délégation

Assigner une idée — chorus_pm_assign_idea (idea:admin)

Confier une idée entière à un agent ou utilisateur choisi. Paramètres :

Comportement que vous devez comprendre :

• L'assignataire est réveillé et progresse à partir de l'étape actuelle de l'idée — il ne réclame PAS. Si l'idée est open elle passe à elaborating ; tout autre statut est préservé. L'assignataire reprend là où l'idée l'était déjà (élaboration, ready-for-proposal, etc.).
• Les cibles agent doivent détenir idea:write (via une préconfigurations telle que pm_agent/admin_agent, ou une permission explicite) ou l'appel est rejeté. Les cibles utilisateur doivent être dans votre entreprise. instanceUuid est rejeté pour les cibles utilisateur.
• Reprise silencieuse. Réassigner une idée déjà possédée transfère simplement la propriété au nouvel assignataire — il y a un propriétaire à la fois, pas de demande de confirmation. Utilisez ceci délibérément, pas par accident.

Assigner une tâche — chorus_pm_assign_task (proposal:write)

Confier une seule tâche à un agent développeur. Paramètres : taskUuid, agentUuid (doit détenir task:write), instanceUuid optionnel. La tâche doit être open ou assigned. L'assignataire est réveillé pour l'exécuter. Utilisez ceci pour distribuer les tâches d'une proposition approuvée.

Dériver des idées enfants et les distribuer

Le cas décomposition-thème, de bout en bout :

1. Lire l'idée conteneur/thème et son contexte (chorus_get_idea, chorus_get_documents, chorus_get_comments).
2. Pour chaque tranche indépendante, créer une idée enfant avec chorus_pm_create_idea (la lier au parent dans le corps / via references[]).
3. Assigner chaque enfant à un propriétaire distinct avec chorus_pm_assign_idea — p. ex. un enfant à Codex, un à un agent Claude dev, un à un humain. Chaque enfant a maintenant son propre propriétaire unique et progresse indépendamment.
4. @mention chaque assignataire et le propriétaire du thème pour que la délégation soit visible.

Revue indépendante comme porte adversariale

Chorus fournit trois sous-agents examinateurs en lecture seule. En tant qu'orchestrateur vous les lancez aux trois portes et agissez en fonction du verdict — c'est votre levier qualité principal quand vous n'écrivez pas vous-même le code.

Chacun affiche exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL. Les verdicts sont consultatifs — ils n'approuvent pas automatiquement, ne vérifient pas automatiquement, ni ne bloquent fermement ; vous lisez les BLOCKER et décidez. Un FAIL signifie router les BLOCKER pour une correction avant de progresser (pour un FAIL de code-review, ajouter des tâches de correction à la proposition approuvée via /quick-dev et relancer une fois qu'elles sont done). Voir /review et la Configuration de l'Agent Examinateur du plugin pour le motif complet.

Choisir un mode de collaboration

Choisissez le mode le plus léger qui convient à la forme du travail :

Orientation : commencez étroit. Si un propriétaire unique peut tenir toute la fonctionnalité dans sa tête, préférez un seul propriétaire — les frais généraux de coordination ne sont pas gratuits. Recourez à la distribution uniquement quand les tranches sont véritablement indépendantes (périmètre séparé, élaboration séparable). Utilisez vagues de tâches parallèles uniquement après qu'une proposition soit approuvée et que son DAG soit réel ; respectez les dépendances — to_verify ne débloque pas les tâches suivantes, seul done le fait.

Propriétaire unique et discipline de concurrence

• Un assignataire responsable par idée à la fois. Ceci reflète la sémantique de propriétaire unique du daemon : l'idée est la racine pivot faisant autorité, et la propre identité des propositions/tâches/réveils du propriétaire en héritent. Ne laissez pas une idée ambiguëment « possédée par l'équipe ».
• Ne pas faire la course avec des sessions dupliquées sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche vont entrer en collision sur les transitions d'état et produire des réveils conflictuels. Assigner, puis laisser un propriétaire s'exécuter.
• Épingler avec instanceUuid quand le travail est attaché à un lieu. Si le code d'une idée enfant vit sur un host/cwd spécifique, épingler l'assignation à cette AgentInstance afin que chaque réveil en aval arrive là au lieu d'une daemon aléatoire.

Portes Conversation-Inversée (vous ne livrez jamais automatiquement)

Chorus c'est l'IA propose, l'humain vérifie. En tant qu'orchestrateur vous imposez cela, vous ne le contournez pas :

• Porte d'élaboration (gateway resolve/skip). Quand une idée enfant que vous avez assignée à un autre agent a son élaboration répondue, vous pouvez fermer la porte d'élaboration vous-même via chorus_pm_validate_elaboration (ou chorus_pm_skip_elaboration pour une idée trivialement claire) même si vous n'êtes pas l'assignataire — détenir idea:admin suffit. C'est la parité MCP de la UI Verify-Elaborate : cela réveille l'agent assignataire pour écrire la proposition. Vous verrouillez la porte ; l'assignataire écrit toujours la proposition (Conversation-Inversée préservée).
• Porte de proposition. Quand un propriétaire délégué soumet une proposition, ARRÊT. Lancer l'examinateur de proposition, puis remettre la décision approuver/rejeter au propriétaire humain. Ne pas vous auto-approuver juste parce que vous pouvez (proposal:admin).
• Porte de vérification. Quand une tâche atteint to_verify, ARRÊT. Lancer l'examinateur de tâche, puis laisser l'humain vérifier. La permission de vérifier n'est pas une autorisation d'estampiller votre propre travail coordonné.
• Ne jamais fusionner ni pousser. L'orchestrateur pilote le travail jusqu'à « PR prêt » et le rend à l'humain — il ne fusionne pas, ne pousse pas, ni ne livre pas d'une autre manière de façon autonome.

@mention le propriétaire à chaque porte pour que l'échange soit explicite et vérifiable.

Dériver une idée enfant vs ajouter une tâche vs assigner directement

Règle de base : nouveau périmètre → idée enfant ; unité même-proposition → tâche ; seul le propriétaire change → assign.