Plan Arbiter

Transformez les plans concurrents en une seule ligne directrice concrète. Conservez les meilleures idées, rejetez les hypothèses peu fondées et établissez une transition claire plutôt qu’un mélange confus.

Déroulement

1. Rassemblez les plans sources.
2. Normalisez chaque plan en affirmations comparables.
3. Comparez les plans entre eux et par rapport au code source réel ou au contexte de la tâche.
4. Choisissez un plan gagnant, fusionnez-les pour obtenir un meilleur hybride, ou renvoyez les plans pour révision.
5. Produire un seul transfert d’exécution comprenant des points de vérification et les alternatives rejetées .

La planification est en lecture seule, sauf si l’utilisateur vous demande explicitement de la mettre en œuvre après la décision.

Collecter les plans sources

Acceptez les plans sous forme de texte collé, de fichiers locaux, d’identifiants de session, de chemins d’accès aux transcriptions, de PR, de commentaires, de liens vers des plans visuels ou d’historique de discussion. Résolvez les artefacts d’origine lorsque cela est possible afin de pouvoir voir les modifications de ligne de commande et les hypothèses qui pourraient manquer dans un résumé final.

Si un plan est encore en cours de rédaction et que l’utilisateur vous a demandé d’attendre, surveillez-le jusqu’à ce qu’il soit terminé ou bloqué. Si un plan ne peut pas être résolu, poursuivez avec le texte du plan disponible et signalez la source manquante comme un risque.

Normaliser

Pour chaque plan, extrayez :

• L’objectif et le périmètre.
• Les hypothèses clés et les questions en suspens.
• Fichiers, modules, API, structures de données, états de l’interface utilisateur ou workflows proposés.
• Séquence de mise en œuvre.
• Stratégie de validation.
• Problématiques liées à la restauration ou à la migration.
• Coût, complexité et adéquation attendue avec l’exécuteur.

Ne privilégiez pas la verbosité. Privilégiez les plans concrets, fondés sur du code réel, et honnêtes quant aux compromis.

Révision croisée

Examinez chaque plan comme s’il avait été rédigé par un autre agent compétent :

• Vérifiez s’il répond à la demande réelle de l’utilisateur.
• Vérifiez les affirmations par rapport au dépôt, à la documentation, aux tests, aux captures d’écran ou aux systèmes externes lorsqu’ils sont pertinents et disponibles.
• Identifiez les dépendances cachées, les tests manquants, les enchaînements risqués, les étapes vagues, la portée inutile et les décisions difficiles à inverser.
• Remarquez les atouts complémentaires : un plan peut présenter une meilleure architecture tandis qu’un autre propose un meilleur parcours de migration ou de validation.
• Faites la distinction entre la qualité du plan et la préférence de l’exécuteur. Un exécuteur moins coûteux ou plus rapide peut constituer le bon choix pour la mise en œuvre, même si un autre modèle a donné lieu à la meilleure critique.

Utilisez des sous-agents pour un examen indépendant lorsque les plans sont volumineux, que la base de code est étendue ou que la décision gagnerait à faire l’objet d’examens techniques et produit distincts.

Décider

Choisissez l’un des trois résultats suivants :

• Adopter : retenir un plan tel qu’il a été rédigé, dans l’ensemble.
• Hybride : combiner des éléments spécifiques pour obtenir un plan d’exécution plus solide.
• Réviser d’abord : demandez une nouvelle phase de planification car les deux plans omettent une contrainte clé ou dépendent d’une décision non tranchée.

Utilisez cet ordre de départage :

1. Exactitude et adéquation avec la demande de l’utilisateur.
2. Ancrage dans des fichiers, des API, des tests, des données et le comportement de l’interface utilisateur réels.
3. Une première implémentation plus simple qui ne bloque pas les développements futurs prévus.
4. Meilleure stratégie de validation et de retour en arrière.
5. Coût en jetons/temps d’exécution plus faible une fois que la qualité est acceptable.

Transfert

Renvoyer une note de décision concise :

Decision
- Adopt Plan A / Hybrid / Revise first.

Why
- The deciding evidence and tradeoffs.

Execution Plan
- Ordered steps with files or surfaces to touch.

Borrowed From Other Plans
- Useful pieces kept from non-winning plans.

Rejected
- Ideas intentionally not taking, with reasons.

Verification
- Tests, browser checks, screenshots, CI, review, or deploy checks needed.

Executor Recommendation
- Which agent/model should implement and why.

Lorsque l’utilisateur a déjà demandé l’exécution et que la voie choisie est claire, poursuivre avec le plan sélectionné après avoir brièvement rendu compte de la décision. Sinon, s’arrêter au transfert et demander une validation.