multi-evaluator

Boucle d'amélioration de conception multi-évaluateurs

Séries d'évaluations indépendantes jusqu'à ce que le produit soit prêt pour les utilisateurs : chaque parcours obtient un score de 9 ou mieux de chaque évaluateur, aucun correctif de gravité élevée n'est ouvert, les évaluateurs sont d'accord à un point près, et cela s'est maintenu pendant deux séries consécutives. Un 10 unanime est un signal pour revérifier le brief, pas l'objectif. Les scores IA sont un signal fort, pas une preuve : lorsque la boucle dit prêt, de vrais utilisateurs novices le testent, et là où ils sont en désaccord avec l'IA, ce sont les utilisateurs qui gagnent.

Tout s'exécute via un outil en ligne de commande, scripts/eval_loop.py (à côté de ce fichier), de sorte qu'un humain, cet agent, ou tout autre agent obtienne les mêmes résultats. Chaque commande prend --dir <dossier de révision>, et status --json indique toujours où en est la boucle et quoi faire ensuite. Nécessite Python 3.9 ou ultérieur, Node.js 18 ou ultérieur et Google Chrome ou Chromium. Rien d'autre à installer.

Ci-dessous, BOUCLE signifie python3 <dossier de cette compétence>/scripts/eval_loop.py.

Avant de commencer (chaque compétence mStack)

• Si ~/.mstack/config.json liste multi-evaluator sous "disabled", ou si la personne a dit de ne pas l'utiliser pour cette tâche, travaillez de la manière habituelle.
• Si ~/.mstack/learned/multi-evaluator.md existe, lisez-le : il contient les améliorations acceptées par cette personne, et elles priment sur ce fichier.
• Lorsque la boucle se termine (ou s'arrête), enregistrez en privé comment cela s'est passé : python3 <dossier compétence mstack>/scripts/mstack.py log multi-evaluator --outcome atteint|partiel|non-atteint --needed-user "..." --stalled "..." (la compétence mstack se trouve à côté de celle-ci).

1. Parcours et critères d'abord

Avant toute évaluation, convenez avec la personne de ce qu'un utilisateur réel doit être capable de faire, de bout en bout.

1. BOUCLE init --dir revision-design --name "<produit>" --start "<commande qui le démarre, avec {port}>" --cwd <son dossier> (ou --url <adresse> pour quelque chose déjà en cours d'exécution, comme un site de préproduction).
2. Remplissez revision-design/mstack-eval.json avec la personne. Voir references/config.md pour chaque champ :
   • about et persona : ce qu'est le produit et qui le juge. Gardez la direction de conception et toutes les contraintes hors de about et dans rules : elles sont montrées aux évaluateurs comme « non notées », de sorte que le brief ne donne jamais la réponse que vous espérez entendre.
   • journeys : 3 à 6 tâches réelles, chacune de bout en bout (« Ajouter un livre et le voir dans la liste »).
   • views : les écrans fixes capturés à chaque série (ordinateur, téléphone, thème sombre). Thème clair en premier.
   • criteria : le socle est clair, rapide, digne de confiance, familier, calme, fonctionne partout. stages ajoutent plus de critères à mesure que le produit mûrit (temps de valeur, récupération d'erreur, copie, expérience agent, accessibilité mesurée, vitesse, test en cinq secondes, ton émotionnel, cohérence, sécurité des données, plaisir). Activez une étape avec "active": true ou "from_round": <n> lorsque les scores montrent que le socle est atteint.
   • reviewers : au moins deux, provenant de différents fabricants d'IA. La valeur par défaut est Claude (exécuté par vous, l'agent) et Codex (exécuté par l'outil avec codex exec).
   • control : la vérification du bruit (recommandée). La première capture fige les écrans de cette série dans control/ ; chaque évaluateur les note à chaque série comme parcours control, et le rapport montre à quel point ce score a bougé. Un changement plus petit que ce mouvement est du bruit, pas un progrès.
3. Montrez à la personne les parcours et les critères et obtenez un oui avant la série 1.

2. Chaque série

BOUCLE start-round --dir revision-design          # ouvre rounds/r<N>/, prend un instantané des critères de cette série
                                                    # écrivez rounds/r<N>/changes.md : ce qui a changé, une puce par élément
BOUCLE capture --dir revision-design               # les mêmes écrans, capturés de la même manière, à chaque série
BOUCLE brief --dir revision-design                 # briefs d'évaluation à l'aveugle dans rounds/r<N>/briefs/, plus -compare briefs à partir de la série 2
BOUCLE review --dir revision-design                # exécute les évaluateurs en ligne de commande (Codex) en parallèle ; exécutez-le en arrière-plan

En même temps, exécutez vous-même chaque évaluateur dont le kind est agent, dans un contexte frais :

• Claude Code : démarrez un sous-agent (l'outil Agent, à usage général) dont l'invite est le texte intégral de rounds/r<N>/briefs/claude.md. N'ajoutez pas vos propres opinions, la réponse attendue ou les scores précédents.
• Tout autre agent : ouvrez une nouvelle session ou un nouveau fil de discussion avec le brief comme seule instruction.
• Un évaluateur de kind: "chat" (facultatif, sur option : Grok, ChatGPT ou Gemini dans le propre navigateur connecté de la personne, pas de clé API) : uniquement avec l'accord de la personne sur ce qui peut être partagé, ouvrez un nouveau chat privé, collez rounds/r<N>/briefs/<id>.md, téléchargez les écrans fixes de cette série si le produit n'est pas public, enregistrez la réponse, fermez l'onglet, puis verdict. Il voit des captures d'écran, pas le produit en direct, donc c'est un arbitre : il ne compte jamais pour « prêt pour les utilisateurs » et ne peut jamais être le seul évaluateur.

Lorsqu'il répond, enregistrez son JSON (l'outil le vérifie et refuse une réponse qui ne correspond pas au format) :

BOUCLE verdict --dir revision-design --reviewer claude reponse.json      # ou redirigez la réponse avec -

D'abord à l'aveugle, ensuite en comparaison. Le brief d'évaluation montre cette série uniquement : pas de captures d'écran antérieures, pas de scores antérieurs, pas de direction de conception, de sorte que le score signifie la même chose à la série 1 et à la série 9. À partir de la série 2, il y a aussi rounds/r<N>/briefs/<evaluateur>-compare.md. Donnez-le au même évaluateur après que son verdict soit enregistré (la même session convient ; il n'est plus en aveugle) et enregistrez la réponse à part du score :

BOUCLE verdict --dir revision-design --reviewer claude --compare compare-reponse.json
BOUCLE report --dir revision-design                                               # écrit revision-design/report.html

La comparaison ne change jamais un score ; le rapport la montre sous « Ce qui a changé ».

Ensuite, montrez à la personne le rapport et les captures d'écran en thème clair (rounds/r<N>/shots/). Envoyez-lui une notification si votre agent le peut (dans Claude Code, PushNotification) lorsqu'un rapport de série est prêt ou que la boucle a besoin d'une décision ; la commande notify de la configuration peut également en envoyer une (voir references/config.md).

3. Corriger, puis répéter

1. Commencez par la liste À faire ensuite du rapport (d'abord les correctifs sur un parcours que tous les évaluateurs ont signalés, puis la gravité élevée, puis le plus grand écart « si corrigé »). Là où le tableau des parcours indique que les évaluateurs sont en désaccord de 2 points ou plus, examinez vous-même ce parcours avant d'agir sur l'un ou l'autre score.
2. Apportez les correctifs dans le produit, exécutez ses propres tests et écrivez le changes.md de la série suivante.
3. BOUCLE start-round, et répétez jusqu'à ce que BOUCLE status indique prêt pour les utilisateurs (la règle d'arrêt ci-dessus, maintenue pendant deux séries). Si une série est réussie, ne changez rien d'important et exécutez-en une de plus pour que cela se maintienne. Après max_rounds (par défaut 6) sans l'atteindre, status dit d'arrêter et de parler à la personne : les parcours ou les critères demandent peut-être quelque chose que le produit ne devrait pas faire.
4. Ensuite, de vrais utilisateurs : cinq utilisateurs novices essaient les parcours sans aide. Enregistrez leur temps, leurs hésitations et leurs mots dans rounds/r<N>/people.md (une puce chacun ; le rapport les montre). Là où ils ne sont pas d'accord avec les évaluateurs IA, ce sont les utilisateurs qui gagnent : transformez ce qu'ils ont trouvé en parcours ou critères pour la série suivante.

Règles

• Les évaluateurs ne voient jamais les verdicts des autres, les séries précédentes, les scores antérieurs ou le rapport pendant l'évaluation ; le brief le leur dit. La comparaison avec la dernière série est un passage séparé, après le verdict.
• Les mêmes vues, capturées de la même manière, à chaque série, afin que l'avant et l'après se comparent de manière équivalente.
• Ne laissez jamais un évaluateur soumettre de vrais paiements, messages ou données personnelles. Utilisez des données de démonstration et une copie fraîche.
• Les évaluateurs en bac à sable (Codex) ne peuvent pas démarrer Chrome : review démarre un Chrome headless partagé et le brief leur dit de mettre MSTACK_CDP_PORT=<port> devant la commande du pilote.
• Si la réponse d'un évaluateur ne correspond pas, lisez rounds/r<N>/work/<evaluateur>/raw-reply.txt, puis réexécutez-la. L'outil refuse un 10 qui propose encore des correctifs, et un « si corrigé » en dessous du score.
• Conservez le dossier de révision dans le dépôt du produit (ou à côté) afin que chaque série soit conservée.

Fichiers

• scripts/eval_loop.py : l'outil en ligne de commande (init, status, start-round, capture, brief, serve, review, verdict, validate, report, notify).
• scripts/drive.mjs : le pilote de parcours, un vrai Chrome headless ; les évaluateurs l'utilisent directement.
• scripts/report.py : le constructeur de rapports. scripts/readiness.py : la règle d'arrêt et la vérification du bruit.
• templates/mstack-eval.json : la configuration de démarrage.
• references/config.md : chaque champ de configuration. references/verdict-format.md : le format de réponse. references/method.md : pourquoi la boucle fonctionne ainsi et comment les critères croissent.