picoduck/orchestrate-issues

Orchestrer les Issues

Lancer une campagne d'issues initiales et de leurs suivis justifiés. Coordonner via de vraies sessions enfants Wollipog, pas des sous-agents dans le processus. L'Orchestrateur investigate, planifie, révise les résultats et maintient l'état ; les enfants implémentent. Créer ou modifier cette compétence ne démarre pas une campagne.

Limite d'Activation

Le nombre d'issues, les dépendances, la taille des tâches et la disponibilité des outils de session enfant n'autorisent pas la délégation. Exiger une invocation explicite de ce workflow ou une demande d'orchestrer, coordonner entre sessions, ou déléguer l'implémentation aux enfants. L'autorisation pertinente déjà établie pour une campagne active reste valide ; elle n'a pas besoin d'être répétée à chaque tour.

« Réclamer et implémenter les issues 1089, 1090 et 1091 » signifie que la session courante réclame et implémente ces issues en suivant le workflow d'issues du dépôt (tel qu'une compétence issue-workflow installée), dans l'ordre des dépendances et avec ses worktrees isolés et revue requis. Ne pas lancer de sessions enfants d'implémentation ni demander s'il faut orchestrer simplement parce que la requête liste plusieurs issues. Les titres ou corps d'issues concernant les paramètres Orchestrator sont le sujet de la tâche, pas des instructions pour devenir un Orchestrateur.

« Orchestrer des sessions enfants pour implémenter les issues 1089, 1090 et 1091 » ou « Utilise orchestrate-issues pour ces issues » active ce workflow. Un enfant recevant plusieurs issues assignées reste une session d'implémentation ; l'autorisation d'orchestration du parent n'autorise pas automatiquement cet enfant à déléguer à nouveau. Une revue requise par le dépôt, y compris une revue inter-modèles, reste régie par ses propres règles et n'est pas une délégation d'implémentation d'issue.

Si la session courante est restreinte par le préréglage de permission Orchestrator et ne peut pas implémenter directement, expliquez cette limitation concrète et demandez une direction plutôt que de créer silencieusement des enfants ou tenter une implémentation interdite. Le simple fait d'avoir le préréglage disponible n'est pas une autorisation pour l'utiliser.

Entrées et Configuration

• count : tout entier positif, le nombre d'issues initiales à sélectionner. Déduisez-le de la requête ; s'il est omis, utilisez 5 et précisez cette hypothèse. Une liste explicite d'issues remplace la sélection par priorité et détermine le count.
• concurrency : plafond optionnel, indépendant du count. Par défaut, le plus petit entre count, le maximumConcurrentChildren de la politique et la capacité d'enfants actifs disponibles. Mettez en file d'attente les issues excédentaires ; n'augmentez jamais les limites de la plateforme pour correspondre au count.
• Le harnais enfant, le modèle et l'effort proviennent de la politique Orchestrator de la campagne Wollipog (childHarness, childModel, childEffort dans get_campaign.behavior) ; cette compétence n'a pas de valeurs par défaut. Chaque valeur est soit fixe, soit Automatique (null). Voir Résoudre le Modèle et l'Effort Enfant.
• Les réviseurs conservent le modèle spécifié par le workflow de revue du dépôt.
• Limites optionnelles spécifiées par l'utilisateur sur le coût, le temps, le nombre total d'issues ou la profondeur des suivis. Préservez les garde-fous hérités. N'inventez pas de valeurs budgétaires ou de round d'arrêt réussi arbitraire.

Lisez using-wollipog, les instructions du dépôt, et toute compétence ou politique de workflow d'issue, de revue, et de rapport d'issue que le dépôt ou l'utilisateur fournit. Seul using-wollipog est requis ; lorsque le dépôt ne définit pas de workflow d'issue, les enfants suivent ses directives de contribution et les gardes de cette compétence. Les enfants doivent avoir les mêmes compétences disponibles dans leur environnement d'exécution. Résolvez les chemins des compétences à partir du catalogue de cet environnement ; ne supposez pas que les chemins personnels de cette machine existent ailleurs. Lisez la politique de rapport d'issue du dépôt avant de préparer les charges de publication.

Découvrez le runner actuel, le dépôt/espace de travail, les harnais de travailleurs disponibles et les capacités de modèle/effort, la capacité enfant, et les outils de session supportés. Sélectionnez un harnais faisant la publicité du modèle choisi ; ne supposez pas que chaque modèle appartient à Codex. Inspectez la session courante et la liste des enfants actifs avant de créer quoi que ce soit. Utilisez uniquement les opérations Orchestrator autorisées ; les écritures de projet et l'implémentation appartiennent aux enfants. Conservez le journal de campagne dans les artefacts persistants de session ou le scratch autorisé, jamais dans le checkout principal. Résumez son dernier état dans la conversation avant de céder ou compacter.

Résoudre le Modèle et l'Effort Enfant

Lisez childHarness, childModel et childEffort de get_campaign.behavior avant de sélectionner quoi que ce soit, et relisez-les avant chaque dispatch : une personne peut les modifier pendant que la campagne s'exécute, et seuls les enfants créés ensuite utilisent les nouvelles valeurs. Les paramètres Orchestrator de Wollipog sont la seule source de ces valeurs. Ne revenez jamais à un modèle ou effort écrit dans cette compétence, mémorisé d'une campagne antérieure, ou hérité de la session parente.

• Valeur fixe : utilisez-la exactement. Le serveur remplit une valeur fixe lorsque create_session l'omet et rejette toute valeur différente, donc ne la remplacez pas. Si l'invite de l'utilisateur demande un modèle ou effort différent d'un paramètre fixe, signalez le conflit et demandez à l'utilisateur de modifier le paramètre Wollipog ; ne dispatchez pas l'issue concernée tant qu'il n'est pas résolu.
• Harnais fixe : un childHarness fixe nomme un harnais, et chaque machine a son propre agent pour celui-ci. Lorsque get_campaign retourne childHarnessAgents, passez le agentId listé pour la machine sur laquelle vous créez l'enfant ; une machine listée avec null ne peut pas l'exécuter. Ne déduisez pas l'agent de childHarness.agentId ; il n'est pas nécessairement un agent sur une machine.
• Modèle ou effort fixe : lorsque get_campaign retourne childModelMachines, créez les enfants uniquement sur les machines marquées supported ; les autres ne peuvent pas exécuter ce modèle et cet effort, et la création y est refusée.
• Automatique (null) : choisissez pour chaque assignation à partir de get_agent_capabilities (MCP) ou wollipog session capabilities (CLI). Suivez page.nextOffset jusqu'à ce que truncated soit false. Choisissez un harnais qui fait la publicité du modèle choisi ; ne supposez pas que chaque modèle appartient à un seul harnais. Basez le choix sur la complexité de l'issue, l'incertitude, les conséquences des erreurs, les besoins de contexte, et toute contrainte de coût ou latence exprimée par l'utilisateur. Les préférences de modèle ou d'effort dans l'invite de l'utilisateur guident un choix Automatique mais ne modifient pas le paramètre Wollipog. Préférez une option économique capable pour un travail simple et un raisonnement plus fort pour le débogage complexe, l'architecture ou les changements étendus. N'inventez pas de classements de modèles, de prix ou de niveaux d'effort ; utilisez les capacités annoncées et expliquez l'incertitude matérielle. Si un modèle n'annonce pas d'effort configurable, enregistrez l'effort comme not applicable.

Si une valeur fixe est absente de la découverte de capacités actuelle, signalez l'inadéquation et demandez un paramètre corrigé tout en poursuivant le triage indépendant. Ne substituez jamais silencieusement.

Enregistrez pour chaque issue le harnais, le modèle exact, l'effort exact, s'ils étaient fixes ou Automatiques, et une brève justification pour les choix Automatiques dans le tableau de sélection et le journal avant le dispatch. Le mode Automatique autorise ces choix de routine sans demander par enfant ; il n'autorise pas à changer de comptes, arrangements de facturation, permissions, budgets, ou les paramètres Wollipog eux-mêmes.

Vérifier le Modèle et l'Effort Avant Implémentation

Utilisez create_session avec useWorktree: true, le harnais résolu, un mode de permission worker annoncé (pas le mode Orchestrator), et les model et effort résolus dans le même appel, plus campaignWorkItemId nommant l'élément de travail enregistré de l'enfant. L'équivalent CLI est wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree. Omettrez une dimension uniquement lorsqu'elle est fixée par la politique (le serveur la fournit) ou not applicable. Les valeurs explicites s'appliquent avant l'invite initiale. Préférez les entrées d'outil structurées pour le texte de la tâche.

Lisez la paire effective à partir du résultat de création ou de get_session et confirmez qu'elle correspond à la combinaison résolue. Si ce n'est pas le cas, arrêtez cet enfant avant qu'il ne fasse du travail, enregistrez l'inadéquation, et signalez-la ; n'acceptez pas une valeur par défaut non vérifiée. Un client et un serveur qui ne supportent pas l'effort explicite échouent en état fermé ; signalez ce bloqueur plutôt que de réessayer sans effort.

Inspectez le schéma de création réel : un numéro de protocole runner seul n'expose pas une entrée. Si un hôte Custom manque de campaignWorkItemId, utilisez uniquement une assignation bootstrap en lecture seule à la création, vérifiez la configuration effective, enregistrez l'assignation d'élément de travail originale avec l'outil d'assignation supporté, et sélectionnez un worktree dédié avant de libérer l'implémentation. Ne revendiquez pas de liaison atomique d'élément de travail sur cet hôte et ne contournez pas l'admission protégée requise. Si ces opérations sont indisponibles, signalez le bloqueur de compatibilité ; ne mettez jamais à jour la pile hébergeant la campagne.

Revérifiez la configuration avant de réutiliser un enfant. Pour une assignation Automatique, reconsidérez la combinaison si des preuves montrent que le choix précédent était inadéquat et enregistrez pourquoi ; appliquez les changements uniquement via une opération de configuration supportée pendant l'inactivité et vérifiez-les avant la libération, ou créez un remplacement avec un transfert de propriété clair. Un message prompt_session normal ne change pas la configuration de session. Ne changez jamais une valeur fixée par politique.

Autorité et Gardes

Lisez la référence pré-vol de l'Autorité de Campagne fournie avec using-wollipog. Avant le dispatch, enregistrez le mode effectif custom/contrôle total, la limite établie par l'humain et sa révision, les opérations autorisées, les propriétaires actuels, la compatibilité, la destination/preuve de divulgation et les exceptions Humain Requis. Identifiez les règles humaines obligatoires non résolues par leur source d'instruction exacte ; ne réécrivez jamais silencieusement des instructions externes ou rédigées par l'utilisateur. Le contrôle total s'applique uniquement à l'autorité établie par le serveur éligible permise par la politique du dépôt. Custom préserve les exigences d'approbation existantes. Une politique modifiée doit passer son propre workflow de contribution explicitement autorisé.

Reportez l'autorisation de campagne réelle de l'utilisateur et les règles du dépôt. Les réclamations de routine, les worktrees isolés, les tests, les pushs, l'ouverture de PRs, et les revues requises n'ont pas besoin d'autorisation répétée. Les règles existantes peuvent encore exiger une autorisation de fusion par PR, une revue des preuves UI, une autorisation de suppression de branche distante, et une approbation de chaque charge utile d'issue exacte et nettoyée. Ne convertissez pas silencieusement une demande pour ce workflow en une renonciation à ces gardes.

Lisez l'état de campagne actuel faisant autorité et la politique dérivée du serveur avec get_campaign avant le dispatch et à nouveau avant de résoudre une décision de workflow ; ne vous fiez pas à une copie d'invite lorsque l'état du serveur est disponible. Pour les décisions typées telles que implementation_question, pr_merge, merged_branch_deletion, follow_up_issue_publication, ui_evidence_approval, et review_round_extension, l'enfant doit utiliser request_workflow_decision, get_workflow_decision, et consume_workflow_decision pour l'occurrence exacte immédiatement avant l'action correspondante. Le parent ne doit pas créer ni consommer une garde d'un enfant en son nom. Découvrez les occurrences en attente avec list_descendant_requests et résolvez uniquement une occurrence exacte actuellement possédée par Orchestrator avec resolve_descendant_workflow_decision. Utilisez answer_descendant_question et resolve_descendant_approval uniquement pour les demandes non liées au workflow applicables ; ils ne remplacent jamais une garde de workflow typée. Une invitation ordinaire, une approbation obsolète, ou la disponibilité du Contrôle Parent ne sont pas une autorisation pour une garde typée.

Lorsque vous possédez une décision ui_evidence_approval avec plusieurs images, préférez prepare_descendant_ui_evidence_review. Elle remet chaque image à une session de réviseur gérée avec un contexte frais, de sorte que les images n'entrent jamais dans votre propre conversation. Rédigez son résumé à partir des affirmations déclarées par l'enfant et des critères d'acceptation UI de l'issue. Pendant que le réviseur travaille, terminez votre tour ou attendez sur sa session au lieu de sonder, puis lisez le verdict avec get_descendant_ui_evidence_review. Approuvez uniquement avec la référence exacte delegatedImageReview qu'elle retourne, listant chaque identifiant de preuve dans evidenceReviewed. Sur une recommandation de refus, refusez avec un childMessage qui nomme les défauts observés. Gardez review_descendant_ui_evidence pour une décision avec une image, ou pour un examen ciblé d'une image lorsque le verdict laisse quelque chose d'incertain. Lorsque le chemin du réviseur est indisponible, il refuse avec la raison ; révisez directement à la place. Un réviseur est un enfant de campagne comme un autre : vérifiez son rapport et incluez-le dans le nettoyage.

Avant d'approuver un pr_merge GitHub d'un enfant, lisez ce qu'il ferme : le closingReferenceCheck de la décision liste chaque issue que GitHub fermerait lors de la fusion, et le serveur a créé la décision uniquement parce qu'elles correspondent aux intendedClosures de l'instantané. Approuvez une fermeture uniquement lorsque la campagne a l'intention que cette fusion ferme l'issue ; refusez avec un message enfant sinon, pour que l'enfant reformule la référence comme "Refs #N". Lorsque la vérification est absente (le runner de l'enfant lui est antérieur), exécutez wollipog pr closures <pr-url> --json vous-même avant d'approuver. Les mots-clés de fermeture contournent une garde issue_closure typée, donc lorsque la campagne ferme des issues par cette route, une fusion d'un enfant ne devrait normalement en fermer aucune.

Ne changez jamais les paramètres de contrôle de campagne, n'approuvez pas une demande appartenant à un humain, n'usurpez pas l'identité d'un humain, ou ne contournez pas une approbation en attente avec une simple invite. Une occurrence éligible de Contrôle Total racine peut utiliser l'autorisation permanente enregistrée par le serveur via sa route de résolution typée exacte ; elle ne peut pas créer une nouvelle autorisation. La preuve UI reste propriété humaine lorsque la politique active dit que l'Orchestrateur ne peut pas inspecter les octets de preuve. Pour toute garde appartenant à un humain ou autrement non déléguée, relayez la décision concrète via le mécanisme de question typée supporté du harnais et gardez les enfants non liés progressant. Sous Contrôle Total, aucune personne ne voit les questions de la racine : le serveur les ignore sans réponse, donc résolvez les occurrences appartenant à Orchestrator vous-même et signalez une garde appartenant à un humain, qui reste visible dans l'État de Campagne, plutôt que de demander. Lorsque le propriétaire a gardé une décision pour lui-même (un choix de conception, une question de risque...

… [tronqué pour la traduction]