Model Fusion
Effort: heavy — un panel complet qui rédige en parallèle plus un juge indépendant (et un rédacteur en option) ; à dépenser sur les builds durs et les correctifs qui livrent, jamais sur des changements d'une ligne. Élimine : parier le changement sur le brouillon d'un seul modèle, et le rework quand ce brouillon-là est faux.
Plusieurs voix indépendantes battent une seule voix. Un panel de modèles rédige
la même tâche en parallèle. Un juge — un modèle qui n'a écrit aucun des
brouillons — choisit ou fusionne le meilleur. Le gagnant est ensuite vérifié
contre ce qui était vraiment demandé.
Quand le lancer
- Tout build, fix ou uplift substantiel où la qualité compte plus que la vitesse.
- Quand tu veux une paire précise de correcteurs indépendants, pas une confiance
aveugle en un seul modèle.
- PAS pour les changements triviaux d'une ligne. Fais le changement direct et
vérifie-le.
Les trois étapes
1. Panel — brouillons en parallèle
- Envoie la même tâche, avec le même contexte, à chaque modèle du panel en
même temps.
- Chaque rédacteur travaille seul. Aucun rédacteur ne voit le travail d'un autre.
- Un rédacteur qui plante, dépasse le délai ou renvoie du vide est loggé et
écarté. Il ne tue jamais le tour. Logge l'éviction bien fort — ne l'avale
jamais.
- Collecte chaque candidat non vide.
2. Juge — un extérieur choisit et fusionne
- Avant de juger, fais passer à chaque candidat un filtre mécanique pas cher :
s'applique-t-il proprement ? Parse-t-il ? Exécute la sonde sur une copie
jetable, jamais sur l'arbre live. Les candidats qui échouent au filtre
sortent avant que le juge les voie.
- Deux formes de juge — choisis-en une par config :
- Synthèse : le juge analyse chaque candidat (forces, défauts, conflits),
puis un modèle rédacteur séparé compose la réponse finale à partir de cette
analyse. Rédacteur et juge sont des rôles différents ; garde-les sur des
modèles différents quand tu peux.
- Sélection : le juge choisit le meilleur candidat unique qui a passé le
filtre. Moins cher. Utilise-la quand fusionner n'apporte rien.
- Si le juge ou le rédacteur est indisponible, dégrade BRUYAMMENT vers la
sélection sur les mêmes candidats. Ne gâche jamais le panel en silence ; ne
prétends jamais qu'une synthèse a eu lieu.
- Si aucun candidat ne survit au filtre, ajoute la meilleure erreur au prompt
et relance le panel — borné, 2 tours de réparation au maximum. À
l'épuisement, renvoie un échec avec la liste complète des erreurs. Ne
renvoie jamais un résultat vide ou sans effet comme un succès.
3. Valider — vérifier le gagnant contre l'intention
- Relis la demande d'origine. Le gagnant fait-il ce qui était demandé — tout,
et rien de ce qui n'était pas demandé ?
- Vérifie la justesse sémantique, l'accord de style avec le code environnant,
et qu'il s'applique toujours proprement.
- Une confiance basse remonte comme un signal d'escalade, jamais cachée. Puis
prouve-le de la manière normale : test en échec d'abord, vert, comportement
live. Un brouillon fusionné qui n'a jamais tourné est une supposition.
L'échelle
- La forme des barreaux de la fusion : un panel large de modèles pas chers en
bas, des panels plus serrés et des budgets de sortie plus serrés en montant —
un barreau mal configuré échoue bruyamment au chargement.
- Le format de config, les rôles-pas-les-noms et la résolution par sonde live
appartiennent à fleet-ladder.
Règles dures — une seule enfreinte et le skill a échoué
- Le builder ne juge jamais. Le juge n'a rédigé aucun candidat. Le
correcteur final est un modèle différent (idéalement d'une autre famille) de
celui qui a construit le gagnant.
- Aucun nom de modèle en dur à aucun point d'appel. Les rôles dans le code,
les modèles dans la config.
- Aucune dégradation silencieuse. Rédacteurs écartés, repli du juge, échecs
au filtre et épuisement sont tous bruyants. Un résultat innotable ne passe
jamais par défaut.
- Réparation bornée. Les relances du panel ont un plafond dur. L'épuisement
est un échec bruyant, pas une boucle infinie.
- Des tests verts seuls, ce n'est pas fini. Le gagnant est prouvé sur le
comportement live.
Fonctionne bien avec
- fleet-ladder — résoudre quels modèles sont debout avant que le panel tire.
- blind-tribunal — la cour de notation fail-closed quand le correcteur principal meurt.
- red-first — le test en échec que le brouillon gagnant doit faire passer au vert.
- blind-eval — le filtre de goût garder-ou-revenir quand aucun test ne peut trancher.
1---2name: model-fusion-43description: À utiliser quand la réponse d'un seul modèle n'est pas assez fiable — un build, un fix ou un design difficile où tu veux plusieurs modèles en compétition et un juge indépendant qui tranche. Un panel rédige en parallèle, un juge fusionne le gagnant, le résultat est validé contre l'intention d'origine. Trigger words: fusion, panel, judge, multi-model, ensemble, draft and merge, builder not grader, juge, multi-modèle, brouillons parallèles, fusionner, le builder ne note pas.4license: MIT5---67# Model Fusion8**Effort:** heavy — un panel complet qui rédige en parallèle plus un juge indépendant (et un rédacteur en option) ; à dépenser sur les builds durs et les correctifs qui livrent, jamais sur des changements d'une ligne. Élimine : parier le changement sur le brouillon d'un seul modèle, et le rework quand ce brouillon-là est faux.910Plusieurs voix indépendantes battent une seule voix. Un panel de modèles rédige11la même tâche en parallèle. Un juge — un modèle qui n'a écrit aucun des12brouillons — choisit ou fusionne le meilleur. Le gagnant est ensuite vérifié13contre ce qui était vraiment demandé.1415## Quand le lancer1617- Tout build, fix ou uplift substantiel où la qualité compte plus que la vitesse.18- Quand tu veux une paire précise de correcteurs indépendants, pas une confiance19 aveugle en un seul modèle.20- PAS pour les changements triviaux d'une ligne. Fais le changement direct et21 vérifie-le.2223## Les trois étapes2425### 1. Panel — brouillons en parallèle26271. Envoie la même tâche, avec le même contexte, à chaque modèle du panel en28 même temps.292. Chaque rédacteur travaille seul. Aucun rédacteur ne voit le travail d'un autre.303. Un rédacteur qui plante, dépasse le délai ou renvoie du vide est loggé et31 écarté. Il ne tue jamais le tour. Logge l'éviction bien fort — ne l'avale32 jamais.334. Collecte chaque candidat non vide.3435### 2. Juge — un extérieur choisit et fusionne36371. Avant de juger, fais passer à chaque candidat un filtre mécanique pas cher :38 s'applique-t-il proprement ? Parse-t-il ? Exécute la sonde sur une copie39 jetable, jamais sur l'arbre live. Les candidats qui échouent au filtre40 sortent avant que le juge les voie.412. Deux formes de juge — choisis-en une par config :42 - **Synthèse :** le juge analyse chaque candidat (forces, défauts, conflits),43 puis un modèle rédacteur séparé compose la réponse finale à partir de cette44 analyse. Rédacteur et juge sont des rôles différents ; garde-les sur des45 modèles différents quand tu peux.46 - **Sélection :** le juge choisit le meilleur candidat unique qui a passé le47 filtre. Moins cher. Utilise-la quand fusionner n'apporte rien.483. Si le juge ou le rédacteur est indisponible, dégrade BRUYAMMENT vers la49 sélection sur les mêmes candidats. Ne gâche jamais le panel en silence ; ne50 prétends jamais qu'une synthèse a eu lieu.514. Si aucun candidat ne survit au filtre, ajoute la meilleure erreur au prompt52 et relance le panel — borné, 2 tours de réparation au maximum. À53 l'épuisement, renvoie un échec avec la liste complète des erreurs. Ne54 renvoie jamais un résultat vide ou sans effet comme un succès.5556### 3. Valider — vérifier le gagnant contre l'intention57581. Relis la demande d'origine. Le gagnant fait-il ce qui était demandé — tout,59 et rien de ce qui n'était pas demandé ?602. Vérifie la justesse sémantique, l'accord de style avec le code environnant,61 et qu'il s'applique toujours proprement.623. Une confiance basse remonte comme un signal d'escalade, jamais cachée. Puis63 prouve-le de la manière normale : test en échec d'abord, vert, comportement64 live. Un brouillon fusionné qui n'a jamais tourné est une supposition.6566## L'échelle6768- La forme des barreaux de la fusion : un panel large de modèles pas chers en69 bas, des panels plus serrés et des budgets de sortie plus serrés en montant —70 un barreau mal configuré échoue bruyamment au chargement.71- Le format de config, les rôles-pas-les-noms et la résolution par sonde live72 appartiennent à [fleet-ladder](../fleet-ladder/SKILL.md).7374## Règles dures — une seule enfreinte et le skill a échoué7576- **Le builder ne juge jamais.** Le juge n'a rédigé aucun candidat. Le77 correcteur final est un modèle différent (idéalement d'une autre famille) de78 celui qui a construit le gagnant.79- **Aucun nom de modèle en dur** à aucun point d'appel. Les rôles dans le code,80 les modèles dans la config.81- **Aucune dégradation silencieuse.** Rédacteurs écartés, repli du juge, échecs82 au filtre et épuisement sont tous bruyants. Un résultat innotable ne passe83 jamais par défaut.84- **Réparation bornée.** Les relances du panel ont un plafond dur. L'épuisement85 est un échec bruyant, pas une boucle infinie.86- **Des tests verts seuls, ce n'est pas fini.** Le gagnant est prouvé sur le87 comportement live.8889## Fonctionne bien avec9091- [fleet-ladder](../fleet-ladder/SKILL.md) — résoudre quels modèles sont debout avant que le panel tire.92- [blind-tribunal](../blind-tribunal/SKILL.md) — la cour de notation fail-closed quand le correcteur principal meurt.93- [red-first](../red-first/SKILL.md) — le test en échec que le brouillon gagnant doit faire passer au vert.94- [blind-eval](../blind-eval/SKILL.md) — le filtre de goût garder-ou-revenir quand aucun test ne peut trancher.