Concilium — révision contradictoire inter-modèles

Que fait Concilium — révision contradictoire inter-modèles ?

Un second modèle, différent, examine les affirmations de l'utilisateur (ou les vôtres) de manière contradictoire. Une lignée de modèle différente implique des angles morts différents — c'est là toute la valeur. Le réviseur PROPOSE ; la session appelante RATIFIE. Ne laissez jamais la confiance d'un côté se substituer à une preuve.

Conçu pour être orchestré depuis Claude Code — Opus 5 et Fable 5 sont tous deux des sièges de ratification de première classe (mesurés à parité de sièges sur un benchmark aveugle de prédiction de résultats ; tout modèle Claude peut piloter la boucle, mais le ratificateur doit être l'un des deux). Le côté GPT (sol/terra/5.5 via codex) effectue le sondage indépendant et l'exécution mécanique — et ce siège inter-famille est porteur : il détecte de manière mesurable ce que des sièges de la même famille manquent ensemble.

Prérequis (à vérifier une fois par environnement)

1. codex login status → doit indiquer « Logged in using ChatGPT » (OAuth par abonnement — une clé API n'est PAS nécessaire et un abonnement ne peut PAS être utilisé comme tel ; n'essayez pas les ponts proxy/routeur).

2. Découvrez les modèles disponibles : codex debug models ou ~/.codex/models_cache.json. Si un modèle génère une erreur « requires a newer version of Codex », exécutez codex update et réessayez.

3. Première utilisation dans un nouvel environnement : exécutez l'amorçage de calibration (references/setup.md) avant de faire confiance aux verdicts : un test de raisonnement à vérité connue, puis une tâche réelle simple, puis (optionnellement) un face-à-face pour choisir les modèles de niveau.

4. Siège Kimi — EXPÉRIMENTAL et optionnel ; ne fait jamais partie d'un tour par défaut. Ajoutez-le uniquement lorsque l'utilisateur demande explicitement une troisième famille. Deux transports, chacun avec son propre wrapper ici :

   • Kimi Desktop (Windows). scripts/concilium-review-kimi.ps1 pilote le runner daimon intégré de l'application sous son propre Electron. Nécessite l'application de bureau installée et connectée.
   • Kimi Code CLI (Linux/macOS/Windows). scripts/concilium-review-kimi.sh pilote le CLI multiplateforme sous licence MIT — kimi -p sans tête plus OAuth par code d'appareil, donc adapté à un conteneur ou une VM jetable (exemple pratique : references/isolated-guest-vmware.md). ⚠ Le mode impression approuve automatiquement chaque appel d'outil par construction, donc l'isolation y est une condition préalable, pas une précaution. ⚠ Passez toujours --model : le paramètre par défaut intégré du CLI est une génération plus ancienne que le modèle phare et rien dans la sortie ne le nomme.

   Calibré mais plus instable que codex, et plus faible sur l'isolation : chemins, modèles, sandboxing et mises en garde sont dans references/setup.md et les pièges #18–21.

Matrice de niveaux (les valeurs par défaut sont les modèles actuels — à remplacer par installation)

Niveau	Défaut	Effort	Utilisation pour
Recherche	Modèle phare (ex. gpt-5.6-sol)	max	Tours de révision ouverts, vérification contradictoire
Mécanique	Ancien modèle phare (ex. gpt-5.5)	moyen	Vérifier une affirmation connue avec un seul sondage
Exécution	Niveau bon marché (ex. gpt-5.6-terra)	faible	Exécuter et rapporter : lancer un script, surveiller une importation

Les wrappers de niveau Recherche utilisent par défaut max sur chaque siège. Les vocabulaires d'effort diffèrent et il est utile de les connaître exactement : codex accepte none · minimal · low · medium · high · xhigh · max (mesuré — l'API rejette toute autre valeur et nomme l'énumération), le siège kimi accepte low · high · max.

L'effort ne remplace pas une seconde famille — mesuré, avec le témoin. Six exécutions d'un même siège (gpt-5.6-sol) sur le même lot de 14 prédictions, à effort faible/moyen/élevé/très élevé/max plus une réplique au même effort : deux exécutions au MÊME effort ont couvert 10/14, tandis que les paires d'efforts différents ont atteint en moyenne 8,9 et n'ont jamais fait mieux ; l'ensemble complet des six exécutions n'a atteint que 10/14, égal au plancher de bruit de deux exécutions et égal à une paire codex+kimi. La précision n'était pas monotone en fonction de l'effort (élevé 9, max 9, très élevé 7, moyen 7, faible 7) tandis que le temps d'exécution a augmenté de 8× (21s → 166s). Quatre éléments ont été manqués par chaque exécution à chaque effort — et le siège inter-famille en a obtenu deux. Varier l'effort rééchantillonne les mêmes angles morts ; une lignée différente les déplace. Si vous voulez de la couverture, ajoutez une famille, pas du calcul. -Mechanical est la diminution délibérée et reste à medium.

Les tâches d'exécution ne sont PAS des révisions — sautez le wrapper et appelez codex directement : codex exec -m <cheap-model> -c model_reasoning_effort=low [-s read-only unless it writes] "<task>" < /dev/null Fermez toujours stdin sur les appels directs non interactifs (bash < /dev/null ; PowerShell $null | codex …) — un stdin non-TTY ouvert bloque codex indéfiniment sur « Reading additional input from stdin... », et le processus orphelin survit au délai d'attente du shell parent (piège #10 ; les wrappers sont immunisés — ils redirigent via stdin).

Exécuter une révision

Utilisez les wrappers fournis. Ils chargent le contrat de révision partagé depuis references/contract.md (source unique de vérité — sonde de falsification, contre-explication, mise en garde, proposition de verdict, règles de schéma/codage ; modifiez le contrat là, jamais dans les scripts) et ajoutent un estampillage de provenance. Les deux wrappers sont fonctionnellement identiques ; choisissez selon la plateforme :

Linux / macOS (bash) :

• Affirmation : scripts/concilium-review.sh claim "<claim>"
• Diff : scripts/concilium-review.sh diff [base-branch]
• Configuration via env : MODEL, EFFORT, MECHANICAL=1 (niveau mécanique), REPO_DIR, PROJECT_RULES (chemin du fichier de règles).
• Première utilisation après clonage : chmod +x scripts/concilium-review.sh.

Windows (PowerShell 5.1+) :

• Affirmation : powershell -ExecutionPolicy Bypass -File scripts/concilium-review.ps1 -Claim "<affirmation>" [-Mechanical] [-RepoDir <chemin>] [-ProjectRules <fichier>]
• Diff : ... -Diff [-Base <branche>] — révise le diff de l'arbre de travail de -RepoDir.

Siège Kimi de troisième famille — EXPÉRIMENTAL, optionnel. Ne fait pas partie d'un tour par défaut ; ajoutez-le uniquement lorsque l'utilisateur demande une troisième famille. Deux wrappers, même contrat et mêmes cinq blocs : concilium-review-kimi.sh (CLI multiplateforme, configuré par environnement — MODEL y est obligatoire) et concilium-review-kimi.ps1 (runner Windows de bureau).

Le wrapper de bureau utilise les mêmes paramètres -Claim/-Diff/-RepoDir/-ProjectRules/-PriorRounds, plus -Model (par défaut k3-agent), -Effort (low|high|max) et -RawPrompt (pas de contrat, pour les sondes de calibration). Deux différences propres au siège, toutes deux mesurées : le pont automatique CLAUDE.md est DÉSACTIVÉ par défaut ici — l'injection tue systématiquement l'exécution avec un simple « Connection error. », donc il est optionnel via -AutoRules ; utilisez -ProjectRules <fichier> pour donner du contexte au réviseur à la place. Et ne faites jamais confiance à son code de sortie — il renvoie 0 sur cette erreur, donc vérifiez la présence des cinq blocs. Les invites multi-lignes doivent passer par ce wrapper ; un kimi-daimon --prompt direct depuis bash voit ses arguments tronqués (pièges #18–19).

Ce siège n'a pas de sandbox — donnez-lui une copie jetable. -SandboxFrom <rep> copie l'arborescence vers un répertoire temporaire (en excluant .git, les environnements virtuels et les fichiers à l'apparence de secrets), y exécute l'agent, imprime exactement ce qu'il a créé/modifié/supprimé, et supprime la copie sauf si -KeepSandbox. Utilisez-le par défaut. Soyez clair sur ce qu'il apporte : le workDir n'est pas une frontière — un canari en dehors a été lu par chemin absolu et retourné textuellement (pièges #20) — il s'agit donc d'un contrôle de rayon d'explosion et d'une piste d'audit, pas d'un confinement. Si des éléments sur la machine ne doivent pas atteindre le fournisseur, isolez au niveau du système d'exploitation (compte séparé avec ACL, ou une VM).

Pour un tour aveugle, le risque de cette même perméabilité est la contamination plutôt que les dégâts : un agent qui s'aventure dans l'arborescence réelle peut trouver la réponse, et le tour cesse silencieusement d'être aveugle. Ajoutez -WatchPaths <a,b,c> — il prend un instantané des temps de dernier accès NTFS pour tout ce qui doit rester non lu (le dépôt réel, le journal des résultats, le corrigé) et signale tout ce qui est lu pendant l'exécution. Validé contre une fuite connue dans les deux sens ; lisez le piège #21 avant de lui faire confiance, y compris pourquoi une version par énumération de la même vérification a signalé « propre » sur une exécution qui avait pourtant fui.

Règles opérationnelles (chacune est un échec mesuré — le pourquoi est dans references/pitfalls.md) :

• Exécutez en arrière-plan avec un délai d'attente complet d'environ 10 min à partir du PREMIER appel. Les révisions réelles prennent 5–15+ min à effort élevé ; un délai d'attente au premier plan les tue en plein milieu de la sonde.
• Préférez une session fraîche à la reprise d'une session ayant expiré. Les longues chaînes reprises subissent une compression du contexte — la lecture attentive initiale du réviseur est résumée de manière approximative avant l'étape finale et déterminante.
• Ne reprenez jamais à nu. codex exec resume réinitialise silencieusement le modèle ET le sandbox aux valeurs par défaut de config.toml de l'utilisateur. Si vous devez reprendre (ou voulez changer de modèle en cours de session), refixez tout : codex exec resume -m <modèle> -c sandbox_mode="read-only" -c model_reasoning_effort=<niveau> <session-id> - Les indicateurs vont AVANT l'identifiant de session positionnel. L'élément clé est sandbox_mode — -c sandbox=... est silencieusement ignoré, et il n'y a pas d'indicateur -s sur resume. La reprise inter-modèles conserve le contexte.
• Le réviseur est un agent complet, pas un chatbot — le sandbox en lecture seule bloque les écritures de fichiers, pas les commandes de lecture ou les SELECT en base de données. Tout ce qu'il examine est envoyé au fournisseur du second modèle.
• Surveillez la progression en direct, n'attendez pas aveuglément — et surveillez le bon flux. Le contrat (règle 9) fait que le réviseur émet des lignes STATUS: au fur et à mesure de son travail, et codex écrit progressivement — mais les flux sont séparés (vérifié en direct) : avec 1> out 2> err, les cinq blocs finaux arrivent sur stdout tandis que la transcription en continu (bannière, lignes STATUS, appels d'outils) va sur stderr. Pointez un tail/moniteur sur stderr pour la progression + les signatures d'échec ; lisez stdout pour le verdict. Mise en garde : les redirections PowerShell 1>/2> écrivent en UTF-16 — décodez en conséquence (ou redirigez via une étape forçant UTF-8) avant de grepper.
• Un tour aveugle nécessite une isolation structurelle, pas une instruction. Lorsque le tour doit être non amorcé (une évaluation aveugle, un premier passage aveugle critique pour le cadrage selon un modèle de demande), exécutez le réviseur dans un répertoire propre avec le pont de règles automatiques DÉSACTIVÉ (-NoAutoRules / NO_AUTO_RULES=1) : un modèle portant le contexte du projet et invité à « répondre à partir du lot uniquement » utilise encore mesurablement ce contexte (pièges #16–17).

Protocole de ratification (le travail de la session appelante)

Le réviseur renvoie cinq blocs : PROBE / ALT / CAVEAT / VERDICT-PROPOSAL / PHASE-LOG. Avant de relayer ou d'agir :

1. Lisez la sonde réelle (la requête/commandes), pas seulement le résumé en prose.
2. Les résultats extrêmes sont un signal d'alarme : 0% ou 100% dès la première tentative signifie généralement une mauvaise clé de jointure, un mauvais périmètre ou une mauvaise table — pas une découverte. Vérifiez vous-même l'étape déterminante de la sonde avant de l'accepter.
3. Vérifiez le périmètre des désaccords : deux sondes peuvent être toutes deux factuellement correctes à des périmètres différents (une table vs l'ensemble de la base, une source vs toutes les sources). Nommez le périmètre avant de comparer les nombres.
4. Distinguer réfuté / obsolète / incomplet. « Les chiffres diffèrent aujourd'hui » ne signifie pas que l'affirmation était fausse au moment où elle a été écrite — vérifiez l'historique/les horodatages avant de dire « réfuté ».
5. Attribuez vous-même l'étiquette de verdict final : [V-code] (vérifié par rapport à la source, citez fichier:ligne) / [V-db] (requête en lecture seule, citez-la) / [V-probe] (script réexécutable) / [C] (non vérifié) / [X] (réfuté — indiquez ce qui le remplace). La proposition est une entrée, pas la réponse.
6. Pondérez l'accord par lignée. Une confirmation intra-famille (un siège Claude approuvant un orchestrateur Claude) est une preuve faible — les sièges de même lignée partagent mesurablement de mauvaises réponses, jusqu'à produire indépendamment la même inférence erronée. Une confirmation ou une réfutation inter-famille l'emporte sur tout nombre de votes intra-famille ; ne tranchez jamais un différend à la majorité de sièges partageant une lignée. Une troisième famille (Moonshot) est disponible en tant que siège expérimental optionnel ; un troisième siège n'apporte rien à moins d'être indépendant, donc pondérez par famille, pas par nombre — et notez qu'un panel unanime peut simplement signifier que l'élément était facile (setup.md).

La boucle concilium (tours itératifs)

Un seul passage de révision suffit souvent. Mais lorsque la sonde du réviseur présente une lacune, ou que vous (l'orchestrateur) êtes en désaccord avec la proposition pour des raisons défendables, un échange ne constitue pas un concilium — un conseil délibère. La boucle exécute des tours de révision jusqu'à ce que le verdict converge ou que le différend se révèle authentique. Cette boucle est orchestrée par vous, la session Claude appelante — c'est un protocole, pas un script (l'étape de ratification est votre jugement ; rien ne peut l'automatiser).

Chaque tour :

1. Exécutez une révision (le wrapper) → obtenez les cinq blocs → ratifiez selon le protocole ci-dessus.
2. Déterminez le résultat du tour et agissez :

Résultat	Condition	Action
Convergé	Vous avez vérifié l'étape déterminante de la sonde et elle tient	ARRÊTEZ — émettez l'étiquette finale.
Différend	La sonde a une lacune, un mauvais périmètre, ou vous avez une objection spécifique et étayée par des preuves	Écrivez la PROBE de ce tour + votre objection dans un fichier de tours ; exécutez le tour suivant avec -PriorRounds/PRIOR_ROUNDS pointant dessus.
Sec	Un tour n'ajoute aucune nouvelle preuve vérifiable — le réviseur réaffirme, ou dit (dans CAVEAT) n'avoir aucune nouvelle piste	ARRÊTEZ — escaladez au propriétaire en tant que [C]/[POLICY] avec la question ouverte. C'est la garde anti-oscillation.
Plafond	Limite de tours atteinte (par défaut 3) sans convergence	ARRÊTEZ — présentez l'état et escaladez ; un véritable différend est une constatation, pas un échec.

Règles de conception (elles découlent directement des pièges) :

• Session fraîche par tour — jamais de chaîne de reprise. La boucle est exactement la « longue chaîne » contre laquelle met en garde le piège #3 ; transportez le contexte vers l'avant via le fichier -PriorRounds, pas via codex exec resume. Chaque tour commence proprement et ne voit qu'un résumé compact de ce qui a déjà été tenté.
• Chaque tour doit ajouter une NOUVELLE piste de preuve. Le contrat (règle 8) impose cela du côté du réviseur ; vous l'imposez du vôtre — une objection ne vaut un tour que si elle est étayée par des preuves ou pointe vers une lacune concrète et vérifiable. « Je ne suis pas convaincu » n'est pas un tour.
• Le ratificateur reste fixe (vous / Fable) ; le réviseur peut baisser de niveau au fur et à mesure que le différend se resserre. Tour 1 au niveau Recherche ; une fois réduit à une vérification mécanique, exécutez le tour suivant au niveau Mécanique (avec -Mechanical / MECHANICAL=1). Un seul siège kimi au niveau max couvre une troisième famille sans répartir l'effort sur plusieurs tours.

Conception des fichiers de tours inter-tours

Le fichier -PriorRounds est en YAML, écrit par le wrapper à la fin de la révision après une ratification réussie (il est ajouté — le fichier peut donc documenter plusieurs tours ; le wrapper émet une nouvelle section à chaque exécution). Le réviseur reçoit ce fichier comme contexte de l'invite et doit répondre dans son propre nouveau tour — pas répéter ce qui a déjà été essayé.

Champ obligatoire qui rend le fichier de tours utile :

• preuve : la citation exacte, la requête, ou la commande sur laquelle vous (ou la ronde précédente) basez l'objection.

Champs facultatifs que la session appelante remplit :

• lacune : ce que la sonde du tour précédent n'a pas vérifié, ou ce qu'elle a mal interprété.
• périmètre : si applicable, délimitez les limites du différend (par exemple, « L'affirmation porte sur les utilisateurs actifs quotidiens du module X ; la sonde a vérifié la table Y qui est globale : le nombre Y est correct mais ne répond pas à l'affirmation Z »).

La session appelante remplit toujours preuve ; ne générez jamais par une commande unique si une lacune clé n'est pas évidente — une affirmation étayée peut être précise sur un point et se tromper sur un autre. La règle de la lacune est : ne commencez un tour que si vous pouvez pointer vers un écart vérifiable. Sans cela, acceptez le verdict ou escaladez.

Stylisation du verdict (appliquée dans la ratification)

Étiquette	Condition	Support de preuve
[V-code]	Vérifié contre une source textuelle fiable	Citation fichier:ligne
[V-db]	Vérifié via requête en lecture seule contre une base de données	La requête dans les résultats, + instantané (ou lien) du résultat
[V-probe]	Vérifié via un script réexécutable que l'utilisateur/la session peut relancer	Sortie du script ou garantie que les données persistent
[X]	Réfuté : une preuve vérifiable contredit l'affirmation	La preuve (qui remplace ce qui a été réfuté, si applicable) et le périmètre pour lequel elle est vraie
[C]	Non vérifié — aucune sonde fiable produite	Pourquoi (par exemple, pas de chemin réalisable dans le périmètre de travail ; requête non prise en charge par l'outil, etc.)
[C]/[POLICY]	Conflit non résolu nécessitant un jugement humain/du propriétaire	Résumé de la meilleure preuve de chaque côté ; le conflit est le résultat — ne le supprimez pas d'un [C]

Questions fréquentes

Q : Puis-je exécuter cela uniquement sur Claude Code ? R : Oui — c'est conçu pour cela. Tout modèle Claude sert de ratificateur ; le réviseur est GPT via codex.

Q : Dois-je payer pour un abonnement ChatGPT et une clé API ? R : Juste l'abonnement. L'authentification se fait via OAuth (codex login), pas par clé. Aucune clé API nécessaire.

Q : Quelle est la fiabilité ? R : Mesuré — le sondage inter-famille attrape des éléments qu'aucun modèle seul ne voit, même avec plusieurs niveaux d'effort ou plusieurs exécutions.

Q : Puis-je exécuter cela sans un troisième modèle ? R : Oui — le siège par défaut est codex (GPT). Kimi est un ajout optionnel pour un troisième point de vue.

Q : Combien de temps cela prend-il ? R : 5–15+ min par tour à effort élevé. Tournez en arrière-plan avec un délai d'attente de 10 min. Un seul tour suffit souvent pour une affirmation simple.

Q : Puis-je l'utiliser avec Kimi uniquement, sans codex ? R : Non — Kimi est optionnel ; codex est le seul siège par défaut. La conception s'appuie sur la paire [Claude (ratification) + GPT (révision)] ; Kimi est un ajout.

Q : Pourquoi ne pas exécuter Claude contre Claude ? R : Parce qu'ils partagent des angles morts — mesurablement. Une deuxième famille fournit une couverture différente. C'est le principe clé du concilium.

Dépannage

Problème	Cause probable	Solution
codex login status n'affiche pas « Logged in... »	Pas connecté ou pas d'abonnement	Exécutez codex login — OAuth d'abonnement nécessaire
Le modèle échoue avec « requires a newer version of Codex »	Codex CLI obsolète	codex update
Le wrapper se bloque sur stdin ouvert	Appel direct sans redirection	Ajoutez < /dev/null (bash) ou `$null
-SandboxFrom ne copie pas	Chemin de répertoire manquant ou invalide	Vérifiez que -SandboxFrom <dir> pointe vers un répertoire existant
Les fichiers sont écrits là où il ne faut pas	Agent non isolé ; pas de sandbox	Utilisez une copie jetable ; pour les révisions de code, -s read-only sur l'appel codex direct
Verdict toujours « Convergé » alors que je m'attends à un différend	Mauvais périmètre ou juridiction	Vérifiez que la signification de l'affirmation est claire ; ajoutez une lacune au fichier de tours si nécessaire
Le tour sec se produit trop tôt	Aucune nouvelle piste de preuve générée	Assurez-vous que votre objection/lacune est étayée par des preuves ; une simple affirmation peut laisser le réviseur à court de nouvelles pistes

Structure du dépôt

concilium/
├── scripts/
│   ├── concilium-review.sh       # Wrapper bash (Linux/macOS)
│   ├── concilium-review.ps1      # Wrapper PowerShell (Windows)
│   ├── concilium-review-kimi.sh  # Wrapper Kimi CLI (Linux/macOS)
│   └── concilium-review-kimi.ps1 # Wrapper Kimi Desktop (Windows)
├── references/
│   ├── contract.md               # Contrat de révision (source unique)
│   ├── setup.md                  # Calibration et configuration
│   ├── pitfalls.md               # Pièges documentés et leurs raisons
│   └── isolated-guest-vmware.md  # Exemple d'isolation Kimi dans une VM
├── README.md (ce fichier)
└── ...

Licence

MIT

Contribution

Oui. Consultez d'abord references/pitfalls.md ; si vous voyez un piège manquant, ajoutez-le avec une démonstration mesurée. Les PR avec des ajouts calibrés sont les bienvenus. Les PR qui ajoutent des sièges doivent inclure une preuve mesurée qu'ils surpassent le choix par défaut sur un test de référence pertinent.

---

Des versions antérieures de ce document contenaient les détails complets des pièges mesurés qui se trouvent maintenant dans references/pitfalls.md. Les résumés ci-dessus sont suffisants pour une utilisation de base et pour les situations courantes ; pour les cas limites et des informations complètes, consultez le fichier des pièges.