omc-plan

<Utiliser_Quand>

• L'utilisateur veut planifier avant d'implémenter - "planifie ça", "planifie le", "planifions"
• L'utilisateur veut une collecte structurée des exigences pour une idée vague
• L'utilisateur veut qu'un plan existant soit révisé - "révise ce plan", --review
• L'utilisateur veut un consensus multi-perspectives sur un plan - --consensus, "ralplan"
• La tâche est large ou vague et nécessite un cadrage avant d'écrire du code </Utiliser_Quand>

<Ne_Pas_Utiliser_Quand>

• L'utilisateur veut une exécution autonome de bout en bout - utiliser autopilot à la place
• L'utilisateur veut commencer à coder immédiatement avec une tâche claire - utiliser ralph ou déléguer à un exécuteur
• L'utilisateur pose une question simple qui peut être répondue directement - répondre simplement
• La tâche est une correction unique et ciblée avec un périmètre évident - utiliser une compétence d'exécution au lieu de lancer ce module de planification </Ne_Pas_Utiliser_Quand>

<Pourquoi_Cela_Existe> Se lancer dans le code sans comprendre les exigences entraîne des retouches, une dérive du périmètre et des cas limites oubliés. Plan fournit une collecte structurée des exigences, une analyse experte et des plans vérifiés qualitativement pour que l'exécution repose sur des bases solides. Le mode consensus ajoute une validation multi-perspectives pour les projets à enjeux élevés. </Pourquoi_Cela_Existe>

<Politique_d_Exécution>

• Détection automatique du mode entretien vs direct en fonction de la spécificité de la demande
• Poser une question à la fois lors des entretiens - ne jamais regrouper plusieurs questions
• Recueillir les faits du code via l'agent explore avant d'interroger l'utilisateur à leur sujet
• Les plans doivent respecter des normes de qualité : 80%+ des affirmations citent fichier/ligne, 90%+ des critères sont testables
• Le mode consensus s'exécute entièrement automatiquement par défaut ; ajouter --interactive pour activer les invites utilisateur aux étapes de révision du brouillon et d'approbation finale
• Le mode consensus utilise le mode court RALPLAN-DR par défaut ; passer en mode délibéré avec --deliberate ou lorsque la demande signale explicitement un risque élevé (authentification/sécurité, migration de données, modifications destructrices/irréversibles, incident de production, conformité/PII, rupture d'API publique)
• Limite planification/exécution : les modes de planification inspectent le contexte et produisent uniquement des plans/cahiers des charges/propositions. Ils DOIVENT marquer les artefacts comme en attente d'approbation sauf si l'utilisateur a explicitement opté pour l'exécution dans le tour en cours ou via l'interface d'approbation structurée. Avant l'approbation explicite de l'exécution, les modes de planification NE DOIVENT PAS exécuter de commandes shell modifiant le système, éditer des fichiers source, commit, push, ouvrir des PR, invoquer des compétences d'exécution ou déléguer des tâches d'implémentation.
• Limite du workflow d'objectif : lorsqu'un plan compare Claude Code /goal, Ralph, Team, ou Ultragoal sans artefact, identifier exactement une autorité de boucle principale et utiliser les politiques de conflit déterministes refuse, adopt_existing et artifact_only plutôt qu'une gestion d'avertissement non déterministe. Les faits /goal doivent citer uniquement des sources Claude Code/Anthropic (documents Claude Code /goal : https://code.claude.com/docs/en/goal ; journal des modifications Claude Code d'Anthropic : https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), et les plans NE DOIVENT PAS prétendre que l'évaluateur /goal exécute indépendamment des commandes ou lit des fichiers ; exiger des preuves manifestes avant toute affirmation d'achèvement.
• Cible de documentation du workflow d'objectif : pour les comparaisons orientées utilisateur, garder les exemples alignés avec docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection et docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal. </Politique_d_Exécution>

<Étapes>

Sélection du mode

Mode	Déclencheur	Comportement
Entretien	Par défaut pour les demandes larges	Collecte interactive des exigences
Direct	--direct, ou demande détaillée	Ignorer l'entretien, générer le plan directement
Consensus	--consensus, "ralplan"	Boucle Planificateur -> Architecte -> Critique jusqu'à accord avec délibération structurée RALPLAN-DR (court par défaut, --deliberate pour les risques élevés) ; ajouter --interactive pour les invites utilisateur aux étapes de brouillon et d'approbation
Révision	--review, "révise ce plan"	Évaluation par le Critique d'un plan existant

Mode Entretien (demandes larges/vagues)

1. Classer la demande : Large (verbes vagues, aucun fichier spécifique, touche 3+ domaines) déclenche le mode entretien
2. Poser une question ciblée via AskUserQuestion pour les préférences, le périmètre et les contraintes
3. Recueillir d'abord les faits du code : Avant de demander "quels motifs votre code utilise-t-il ?", lancer un agent explore pour le découvrir, puis poser des questions de suivi éclairées
4. Construire sur les réponses : Chaque question s'appuie sur la réponse précédente
5. Consulter l'Analyste (Opus) pour les exigences cachées, les cas limites et les risques
6. Créer le plan lorsque l'utilisateur signale son état de préparation : "crée le plan", "je suis prêt", "transforme-le en plan de travail"

Mode Direct (demandes détaillées)

1. Analyse rapide : Consultation facultative et brève de l'Analyste
2. Créer le plan : Générer immédiatement un plan de travail complet
3. Révision (facultative) : Révision par le Critique si demandée

Mode Consensus (--consensus / "ralplan")

Modes RALPLAN-DR : Court (par défaut, structure bornée) et Délibéré (pour --deliberate ou demandes explicites à risque élevé). Les deux modes conservent la même séquence Planificateur -> Architecte -> Critique et les mêmes portes AskUserQuestion.

Remplacements de fournisseur (pris en charge lorsque le CLI du fournisseur est installé) :

• --architect codex — remplacer le passage Architecte Claude par omc ask codex --agent-prompt architect "..." pour une révision architecturale axée sur l'implémentation
• --critic codex — remplacer le passage Critique Claude par omc ask codex --agent-prompt critic "..." pour un passage de révision externe avant exécution
• Si le fournisseur demandé n'est pas disponible, le noter brièvement et continuer avec le passage Architecte/Critique Claude par défaut pour cette étape

Cycle de vie de l'état : Le hook d'arrêt en mode persistant utilise ralplan-state.json pour forcer la continuation pendant la boucle de consensus. La compétence DOIT gérer cet état :

• À l'entrée : Appeler state_write(mode="ralplan", active=true, session_id=<current_session_id>) avant l'étape 1
• Lors du transfert à l'exécution (approbation → ralph/team) : Appeler state_write(mode="ralplan", active=false, session_id=<current_session_id>). Ne PAS utiliser state_clear ici — state_clear écrit un signal d'annulation de 30 secondes qui désactive l'application du hook d'arrêt pour TOUS les modes, laissant le mode d'exécution nouvellement lancé sans protection.
• Lors de la sortie terminale réelle (rejet, sortie de plan non interactive, erreur/abandon) : Appeler state_clear(mode="ralplan", session_id=<current_session_id>) — aucun mode d'exécution ne suit, donc la fenêtre du signal d'annulation est inoffensive.
• Ne PAS effacer pendant les étapes intermédiaires comme l'approbation par le Critique ou la présentation de l'itération maximale, car l'utilisateur pourrait encore sélectionner "Demander des modifications".

Sans nettoyage, le hook d'arrêt bloque tous les arrêts ultérieurs avec des messages de renforcement [RALPLAN - CONSENSUS PLANNING] même après la fin du workflow de consensus. Toujours passer session_id pour éviter d'effacer l'état d'autres sessions simultanées.

1. Planificateur crée le plan initial et un résumé RALPLAN-DR compact avant toute révision par l'Architecte. Le résumé DOIT inclure :

   • Principes (3-5)
   • Facteurs de décision (top 3)
   • Options viables (>=2) avec avantages/inconvénients limités pour chaque option
   • Si une seule option viable reste, une justification d'invalidation explicite pour les alternatives qui ont été rejetées
   • En mode délibéré : un pré-mortem (3 scénarios d'échec) et un plan de test étendu couvrant unitaire / intégration / e2e / observabilité

2. Retour utilisateur (--interactive uniquement) : Si exécuté avec --interactive, DOIT utiliser AskUserQuestion pour présenter le plan brouillon plus le résumé RALPLAN-DR Principes / Facteurs de décision / Options pour un alignement précoce de la direction avec ces options :

   • Procéder à la révision — envoyer à l'Architecte et au Critique pour évaluation
   • Demander des modifications — retourner à l'étape 1 avec le retour utilisateur intégré
   • Ignorer la révision — aller directement à l'approbation finale (étape 7) Si PAS exécuté avec --interactive, procéder automatiquement à la révision (étape 3).

3. Architecte révise la solidité architecturale en utilisant Task(subagent_type="oh-my-claudecode:architect", ...). La révision de l'Architecte DOIT inclure : le contre-argument le plus solide (antithèse) contre l'option privilégiée, au moins une tension de compromis significative, et (si possible) une voie de synthèse. En mode délibéré, l'Architecte doit signaler explicitement les violations de principes. Attendre que cette étape soit terminée avant de passer à l'étape 4. Ne PAS exécuter les étapes 3 et 4 en parallèle. L'Architecte DOIT évaluer le même instantané de plan fixe produit par le Planificateur à l'étape 1 sans le modifier ; la sortie de l'Architecte NE DOIT PAS être transmise au Critique.

4. Critique évalue selon des critères de qualité en utilisant Task(subagent_type="oh-my-claudecode:critic", ...). Le Critique DOIT vérifier la cohérence principe-option, l'exploration équitable des alternatives, la clarté de l'atténuation des risques, les critères d'acceptation testables et les étapes de vérification concrètes. Le Critique DOIT rejeter explicitement les alternatives superficielles, les contradictions de facteurs, les risques vagues ou la vérification faible. En mode délibéré, le Critique DOIT rejeter un pré-mortem manquant/faible ou un plan de test étendu manquant/faible. Exécuter uniquement après que l'étape 3 soit terminée. Le Critique DOIT évaluer le même instantané de plan fixe indépendamment, en tant qu'appel Task séparé et individuellement attendu ; le Critique NE DOIT PAS consommer ni recevoir la révision de l'Architecte.

   Révisions séquentielles indépendantes d'un seul instantané de plan fixe. L'Architecte et le Critique révisent chacun le même instantané de plan fixe produit par le Planificateur à l'étape 1, et aucune révision ne le modifie. La sortie de l'Architecte NE DOIT PAS être transmise au Critique. L'Architecte et le Critique DOIVENT s'exécuter séquentiellement en tant qu'appels Task séparés et individuellement attendus — jamais en parallèle — et la Task du Critique NE DOIT PAS être émise avant que la Task de l'Architecte ne soit terminée et que son résultat ait été attendu. Le Critique NE DOIT PAS consommer ni recevoir la révision de l'Architecte. Les résultats de l'Architecte et du Critique DOIVENT être combinés uniquement par le Planificateur lors de la révision ou de la synthèse d'amélioration, et uniquement après que les deux révisions soient terminées.

5. Boucle de re-révision (max 5 itérations) : Si le Critique rejette, exécuter cette boucle fermée : a. Collecter tous les retours de rejet de l'Architecte + du Critique (synthèse par le Planificateur uniquement : les résultats de l'Architecte et du Critique DOIVENT être combinés uniquement par le Planificateur, et uniquement après que les deux révisions soient terminées). b. Transmettre le retour au Planificateur pour produire un plan révisé c. Retour à l'étape 3 — L'Architecte révise le plan révisé d. Retour à l'étape 4 — Le Critique évalue le plan révisé e. Répéter jusqu'à ce que le Critique approuve OU que le maximum de 5 itérations soit atteint f. Si le maximum d'itérations est atteint sans approbation, présenter la meilleure version à l'utilisateur via AskUserQuestion avec la mention que le consensus d'experts n'a pas été atteint

6. Appliquer les améliorations : Lorsque les réviseurs approuvent avec des suggestions d'amélioration, fusionner toutes les améliorations acceptées dans le fichier de plan avant de procéder. La sortie finale du consensus DOIT inclure une section ADR avec : Décision, Facteurs, Alternatives envisagées, Pourquoi choisie, Conséquences, Suivis. Spécifiquement : a. Collecter toutes les suggestions d'amélioration des réponses de l'Architecte et du Critique b. Dédupliquer et catégoriser les suggestions c. Mettre à jour le fichier de plan dans .omc/plans/ avec les améliorations acceptées (ajouter les détails manquants, affiner les étapes, renforcer les critères d'acceptation, mises à jour ADR, etc.) d. Noter quelles améliorations ont été appliquées dans une brève section de journal des modifications à la fin du plan

7. Sur approbation du Critique (avec améliorations appliquées) : marquer le statut du plan comme en attente d'approbation sauf si l'approbation explicite de l'exécution a déjà été capturée. (--interactive uniquement) Si exécuté avec --interactive, utiliser AskUserQuestion pour présenter le plan avec ces options :

   • Approuver l'exécution via team (Recommandé) — option explicite pour procéder via des agents d'équipe coordonnés en parallèle (/team). Team est la surface d'orchestration canonique depuis la v4.1.7.
   • Approuver l'exécution via ralph — option explicite pour procéder via la persistance Ralph avec vérification
   • Compacter puis revenir pour l'approbation d'exécution — option explicite pour compacter d'abord la fenêtre de contexte (recommandée lorsque le contexte est volumineux après la planification), puis s'arrêter sur le plan en attente d'approbation sauvegardé et demander à nouveau avant de lancer l'exécution
   • Demander des modifications — retourner à l'étape 1 avec le retour utilisateur
   • Rejeter — éliminer complètement le plan Si PAS exécuté avec --interactive, sortir le plan final marqué en attente d'approbation, appeler state_clear(mode="ralplan", session_id=<current_session_id>), et s'arrêter. Ne PAS auto-exécuter.

8. (--interactive uniquement) L'utilisateur choisit via l'interface AskUserQuestion structurée (ne jamais demander l'approbation en texte brut). Si l'utilisateur sélectionne Rejeter, appeler state_clear(mode="ralplan", session_id=<current_session_id>) et s'arrêter.

9. Sur approbation utilisateur

…

[tronqué pour la traduction]