Que fait Claudex Loop ?
La conversation courante est responsable des exigences, de la planification et de la coordination. L'autre fournisseur révise le plan. Chacun des fournisseurs peut construire ; le fournisseur qui n'a pas construit inspecte le code final dans une session fraîche.
Résoudre les rôles une fois
Identifiez l'hôte réel à partir de votre environnement d'exécution, pas de PATH, des compétences installées, des suppositions sur le nom du modèle ou du dépôt. Les deux CLI peuvent être installés. Utilisez host=claude dans Claude Code et host=codex dans Codex. Si l'identité d'exécution n'est pas disponible, demandez une fois à l'utilisateur quel hôte il utilise.
| Hôte | Exigences et plan | Réviseur du plan | Constructeur par défaut | Inspecteur final |
|---|---|---|---|---|
| Claude Code | Session Claude courante | Codex | Claude | Session Codex fraîche |
| Codex | Session Codex courante | Claude | Codex | Session Claude fraîche |
Respectez builder=claude|codex. L'inspecteur est toujours l'autre fournisseur. L'hôte reste le coordinateur même lorsque l'autre fournisseur construit. Pour échanger le planificateur, commencez la conversation dans l'autre hôte ; ne prétendez pas qu'un réviseur CLI est la conversation de planification de l'utilisateur.
La sélection du modèle est indépendante des rôles des fournisseurs. Préservez le modèle sélectionné de l'hôte. Les appels CLI de révision/construction héritent de leur propre configuration sauf si reviewer_model, builder_model ou inspector_model est fourni ; mappez-les à --model de l'exécuteur pour cette invocation. Appliquez un *_effort explicite de la même manière. Fable 5.1 et GPT-6 Astra sont des choix explicites appropriés, pas des verrouillages obligatoires. Un modèle dans l'interface utilisateur de l'hôte ne prouve pas quel modèle un CLI séparé utilisera. Signalez les informations de modèle demandées et observées séparément ; signalez honnêtement une valeur par défaut de CLI non résolue. Ne revenez jamais silencieusement à un autre modèle/fournisseur en cas d'échec.
Lisez la référence d'exécution avant de lancer un CLI. Résolvez son exécuteur par rapport à ce fichier SKILL.md installé, jamais par rapport au projet en cours de révision. Utilisez des chemins absolus lors de son lancement.
Si l'utilisateur fournit codex_cli ou claude_cli, mappez le chemin exécutable du fournisseur sélectionné à --cli. Une application hôte peut avoir un binaire fonctionnel plus récent que le CLI sur PATH ; vérifiez le chemin et la version sans modifier silencieusement l'installation ou la configuration globale.
Paramètres ajustables
| Argument | Défaut | Signification |
|---|---|---|
PLAN_FILE / plan | PLAN.md | Chemin du plan utilisé tout au long, y compris la passation de construction |
LOG_FILE / log | PLAN-REVIEW-LOG.md | Transcription en mode ajout seul |
rounds / MAX_ROUNDS | 5 | Nombre maximum de tours planification-révision terminés |
builder | hôte | Fournisseur implémentant le plan |
research | proportionnel à la tâche | none, web, ou adhésion explicite deep |
mode | full | full inclut la reconnaissance/l'entretien ; review démarre à partir d'un plan existant |
inspect | on | off seulement lorsque l'utilisateur se retire explicitement ; enregistrez-le |
MAX_FIX_ROUNDS | 2 | Nombre limité de tentatives de correction avant de signaler ou de prendre le relais |
MAX_INSPECTION_ROUNDS | 2 | Inspection initiale plus une après les corrections |
Affichez les rôles, chemins, limites de tours, modèles demandés et option d'inspection avant de commencer. Préservez l'autorisation existante : une demande de planification n'autorise pas la construction ; une demande de planification et d'implémentation le fait. Effectuez la préparation autorisée avant de demander toute approbation restante.
Phase 0 — Reconnaissance
Pour les projets existants, inspectez le code pertinent, les dépendances, les appelants et les rédacteurs d'état partagé. Lisez le CONTEXT.md / CONTEXT-MAP.md existant et les ADR pertinents. Pour un projet nouveau, recherchez l'art antérieur, une pile raisonnable et les modes de défaillance concrets lorsque cela est utile. Respectez une profondeur de recherche explicite. La recherche multi-agents profonde nécessite une adhésion explicite et un outil disponible ; sinon, utilisez la recherche ciblée prise en charge et signalez la limitation. N'exigez pas un outil Workflow propriétaire ou ne codez pas en dur un modèle d'agent de recherche.
Découvrez les compétences pertinentes via le catalogue disponible de l'hôte et les emplacements documentés des compétences de l'autre fournisseur lorsqu'ils sont accessibles. N'enregistrez que les dépendances proposées pertinentes. Ne supposez pas que le MCP, le navigateur, les identifiants ou les compétences de l'hôte se transfèrent à l'autre CLI. Vérifiez les capacités de construction requises avant de vous y fier.
Présentez un registre d'hypothèses avec les chemins source ou les liens de recherche. Demandez les corrections des incertitudes matérielles en un lot. Résolvez vous-même les choix réversibles de routine lorsque l'utilisateur a autorisé le travail ; le silence n'est pas une approbation d'une action nécessitant une approbation.
Phase 1 — Définir les exigences
Maintenez une carte de décision courte et visible. Ne posez des questions que sur les décisions non résolues qui changent le résultat. Pour chaque question conséquente, donnez la recommandation, pourquoi elle est importante et le coût d'une erreur. Regroupez les questions indépendantes ; posez les questions dépendantes de manière séquentielle. Si le code peut répondre, inspectez-le à la place. Proposez « accepter toutes les recommandations restantes » lorsqu'une longue liste de décisions ralentit l'utilisateur.
Respectez les définitions de glossaire existantes ; résolvez le langage de domaine ambigu. Maintenez le contexte uniquement du glossaire paresseusement en utilisant CONTEXT-FORMAT.md. Enregistrez un ADR uniquement pour les compromis coûteux à inverser et non évidents en utilisant ADR-FORMAT.md.
Rédigez le PLAN_FILE résolu avec :
- Objectif et critères d'acceptation observables.
- Approche concrète, décisions clés, compromis et non-objectifs.
- Hypothèses confirmées avec sources et risques restants.
- Exigences de chaîne d'outils pertinentes par fournisseur, le cas échéant.
- Vérification : commande(s) de preuve exacte(s), résultats attendus et vérifications manuelles/visuelles si nécessaire.
Dérivez les commandes de preuve du dépôt lorsque cela est possible. Demandez uniquement lorsque ce qui constitue un succès reste flou. Démarrez le LOG_FILE en mode ajout seul avec les rôles, les demandes de modèle, la portée, l'autorisation et les limites de tours. Conservez les diagnostics d'exécution en dehors du répertoire de travail.
Avec mode=review, chargez le plan fourni, comblez uniquement les lacunes matérielles avec l'utilisateur si nécessaire, et passez directement à la révision ; ne redémarrez pas un entretien sur les exigences.
Phase 2 — Révision indépendante du plan
Utilisez l'exécuteur partagé en mode review avec le --host réel, le --plan résolu et le modèle/effort optionnel. Le premier tour crée une session. Les tours suivants utilisent --resume <previous-successful-result.json> avec le même fournisseur/modèle/effort et un fichier --feedback rédigé par l'hôte contenant les décisions. N'utilisez jamais un ID de session deviné, --last ou une session de construction comme réviseur.
Chaque réponse réussie contient un verdict, des conclusions étayées par des preuves, la couverture réelle et les limitations. Préservez l'intégralité de la réponse et le chemin du résultat de l'exécuteur dans LOG_FILE.
- APPROUVÉ : aucun défaut matériel non résolu. L'approbation est liée au chemin exact du plan et au SHA256. Présentez les conseils et limitations restants de faible priorité ; aucun résultat est valide et n'est pas une preuve d'exactitude exhaustive.
- RÉVISER : l'hôte arbitre chaque conclusion. Implémentez les modifications de plan justifiées ; rejetez les suggestions non étayées avec des raisons. Enregistrez les décisions et envoyez le plan révisé au même réviseur. Évitez de rouvrir des points résolus sans nouvelles preuves.
- BLOQUÉ / échec du processus / résultat malformé : ne comptez jamais cela comme une approbation. Expliquez les preuves manquantes réelles ou l'échec opérationnel. Ne brûlez pas les tours restants avec des tentatives aveugles ou ne changez pas de fournisseur silencieusement.
Arrêtez à MAX_ROUNDS. Présentez les conclusions non résolues et la position de l'hôte au lieu de fabriquer une convergence. Un plan modifié nécessite une autre révision. Avant de construire, effectuez la vérification d'approbation sur le plan final. Si l'utilisateur choisit explicitement de procéder sans approbation indépendante, enregistrez cette dérogation et utilisez le chemin de spécification non révisée autonome ; ne le qualifiez jamais d'approuvé.
Phase 3 — Construire et inspecter
Présentez le plan révisé, les améliorations et les limites restantes. Si l'implémentation n'est pas déjà autorisée, demandez cette décision finale. Utilisez le constructeur sélectionné, par défaut l'hôte. Lisez la référence de construction.
L'hôte peut implémenter directement avec ses outils normaux. Pour un constructeur différent, utilisez le mode build de l'exécuteur partagé. L'une ou l'autre voie doit capturer le commit avant construction, préserver le travail utilisateur non lié et transporter le même plan résolu et le même contrat de vérification.
Exécutez les vérifications de preuve convenues, inspectez tous les fichiers modifiés et examinez le résultat via l'autre fournisseur dans une session inspect fraîche. Fournissez le commit avant construction et l'identité du constructeur. La réinspection après des corrections acceptées utilise également une session fraîche. Consignez les conclusions et les décisions ; réexécutez les vérifications de preuve affectées après les corrections.
Si le coordinateur reprend le codage, il est devenu constructeur. Exigez une inspection fraîche de l'autre fournisseur de ses modifications ; ne décrivez jamais l'inspection précédente comme couvrant les modifications ultérieures. Si les deux fournisseurs ont contribué au code, enregistrez la paternité et faites inspecter les modifications de l'autre par chacun ; ne prétendez pas qu'un modèle a examiné indépendamment le code qu'il a écrit. Si le budget d'inspection est épuisé, signalez les conclusions restantes et les modifications non examinées explicitement pour la décision de l'utilisateur.
Présentez le diff final, les résultats de preuve, la couverture d'inspection, les conclusions non résolues, les écarts et les tours utilisés. Respectez l'autorisation de commit/push existante ; sinon, laissez le diff concret prêt pour la validation. La publication externe n'est jamais implicite par le simple fait d'exécuter la boucle.