comparison-lab

Ce que fait cette compétence

Transforme « compare quelques options pour X » en un véritable instrument. Vous générez plusieurs variantes véritablement distinctes, étayées par la recherche de X, vous les affichez chacune dans son propre panneau sur un tableau de comparaison partageable, et vous le remettez à un humain pour comparer, choisir les gagnants et laisser des commentaires. Leurs choix vous reviennent et vous approfondissez les gagnants.

Cela fonctionne pour tout : approches de solutions alternatives, conceptions d'interface/composants, stratégies de test/évaluation, et médias générés (code, images, audio, texte). Le tableau est un fichier HTML autonome sans dépendances, donc il s'intègre dans n'importe quel projet.

$ARGUMENTS est ce qui doit être comparé. Si c'est vague (comparer quoi, faire varier quelle dimension, pour quels sujets), posez 1 à 2 questions de clarification avant de générer.

Principes fondamentaux (l'épine dorsale — ne pas sauter)

1. Variantes authentiques et distinctes — pas des réglages de boutons. Chaque variante est une technique réelle nommée. Si deux variantes ne diffèrent que par une valeur de paramètre, elles représentent une seule approche échantillonnée deux fois — fusionnez-les. Test : si vous pouvez décrire deux variantes avec la même phrase en ne changeant qu'un nombre, elles ne sont pas distinctes.
2. La recherche EST l'étape de calibration. Lorsque le domaine a une littérature ou des pratiques établies, recherchez les techniques réelles nommées AVANT de concevoir les variantes — utilisez WebSearch / docs / references/. Deviner le menu par imagination conduit à des excès ou des insuffisances. (Voir reference.md §1 pour les invites de recherche par domaine.)
3. Comparaison contrôlée. Figez chaque entrée ; ne faites varier QUE la dimension testée. Même seed/scénario/invite/copie sur chaque carte d'une ligne. Indiquez les entrées figées dans l'objectif de la ligne. Une ligne = une dimension variée.
4. Badges objectifs. Partout où quelque chose est mesurable, attachez un badge de métrique avec code couleur par panneau (distance à la cible, taux de réussite, latence, taille du bundle, rapport de contraste, …) afin que le choix soit basé sur des preuves, pas sur des impressions.
5. Isoler les facteurs de confusion — vues multiples d'un même artefact. Lorsqu'il vaut la peine de voir plus d'une vue d'un même résultat, donnez à la carte une bascule content.views (par exemple Notation / Piano-roll / Audio / Brut / Diff). Le cas classique est BRUT vs TRAITÉ — affichez l'artefact brut à côté du traité afin que l'humain puisse dire quelle étape d'une chaîne de traduction/recolorisation/normalisation/sérialisation/compression a causé un mauvais résultat ; content.raw est le raccourci à 2 vues. Ne simulez jamais une bascule. N'ajoutez une vue que si elle diffère réellement — si le résultat traité et le brut sont identiques (une transformation fidèle), supprimez la bascule. Une bascule sans effet est pire que pas de bascule ; le tableau réduit automatiquement les vues byte-identiques et masque automatiquement la bascule à ≤1 vue.
6. Honnêteté métrique vs artefact. Affichez l'artefact réel à côté de ses badges métriques et laissez les désaccords apparaître. Si la notation montre clairement une tierce abaissée mais que le badge « distance » indique 0, cette contradiction est la constatation — cela signifie que la métrique ignore quelque chose. La mettre en évidence est le but ; ne cachez pas l'artefact derrière le nombre et n'ajustez pas le nombre pour qu'il corresponde.
7. Barrière de contenu réel. Chaque panneau montre une sortie RÉELLE — jamais un espace réservé, un placeholder, ou un contrôle de taille d'octet. Vérifiez que le contenu réel s'affiche. Pour l'audio, le contenu doit réellement SONNER — vérifié avec la source de l'échantillon bloquée (reference.md §9 gate hors ligne) — pas simplement s'afficher.
8. Une seule surface partageable. Produisez un tableau unique que l'humain ouvre (un fichier ou un lien), pas des artefacts dispersés.
9. Discipline de jalonnement. Construisez d'abord la tranche la plus risquée / la plus représentative (un sujet, une ligne, avec du contenu réel + audio/lecture si pertinent). Montrez-la à l'humain et obtenez des retours AVANT de passer à l'échelle sur toutes les dimensions.
10. Boucler la boucle. L'humain choisit les gagnants et laisse des commentaires SUR le tableau ; cette exportation vous revient pour affiner. Ensuite, approfondissez les gagnants.
11. Gagnants par sujet + fusion. Lorsque la meilleure variante diffère selon le sujet de test, montrez les gagnants par sujet et ajoutez une étape de fusion/synthèse qui combine les caractéristiques gagnantes, plutôt que d'imposer un gagnant global. Le but de plusieurs sujets est de révéler qu'une seule approche gagne rarement partout — honorez cela au lieu de le moyenner.

Flux de travail

1. Clarifier la comparaison. À partir de $ARGUMENTS, établissez : ce qui est comparé, la dimension unique qui varie par ligne, et les sujets/graines contrôlés (2 est une bonne valeur par défaut). Ne demandez que si c'est réellement ambigu.

2. Rechercher les variantes réelles. Si le domaine a des techniques établies, consultez-les d'abord (reference.md §1 contient des invites de recherche). Produisez une courte liste de 2 à 6 approches nommées, véritablement distinctes par ligne. Rejetez deux approches qui ne diffèrent que par un paramètre.

3. Générer du contenu réel pour chaque variante. Pour chaque (sujet, ligne, variante), produisez l'artefact réel et choisissez son type de contenu : html (interface/texte), code, image, iframe, audio (incl. synthèse WebAudio), ou passfail (tests/évaluations). Voir reference.md §2 pour la table des modalités. Pour offrir plusieurs vues d'une même sortie, définissez content.views comme une liste de vues nommées (la première est la valeur par défaut ; les vues identiques se réduisent, la bascule se masque automatiquement à ≤1) — ou utilisez le raccourci à 2 vues content.raw lorsqu'un pipeline pourrait cacher la vérité (principe 5). Attachez des badges objectifs partout où quelque chose est mesurable, et affichez-les à côté de l'artefact réel afin que les contradictions apparaissent (principes 4, 6).

   Rendu d'artefacts de domaine réels (notation, graphiques, diagrammes) : la voie fiable consiste à effectuer le rendu dans un <svg> dans une page sans tête, à prendre svg.outerHTML, et à l'intégrer via le type de contenu html (SVG en ligne — PAS une data-URI <img>, qui perd l'espace de noms SVG et s'affiche de manière cassée). Les moteurs de glyphes (par exemple VexFlow/Bravura) nécessitent que la police soit intégrée sous forme de @font-face en base64 à la fois sur la page de rendu et sur le tableau, avec document.fonts.ready attendu avant le rendu et avant la capture d'écran. template/render-artifacts.example.mjs est un harnais copiable et adaptable exactement pour cela ; reference.md §6 contient la recette complète et les pièges.

4. Construire le tableau à partir du modèle. Copiez template/comparison-lab.html dans le projet (à un endroit accessible, ou n'importe où pour une utilisation file://). Écrivez votre jeu de données dans un fichier data.json à côté en utilisant le schéma dans template/README.md. Ne créez PAS une nouvelle interface utilisateur — le modèle fournit déjà le tableau de post-it, les badges, la bascule, les boutons et l'exportation.

   • Servi via http(s) : data.json est récupéré automatiquement.
   • Double-cliqué (file://) : collez le jeu de données dans le bloc <script id="inline-data"> du HTML (la récupération d'un fichier frère est bloquée sur file://).

5. Vérifier que le contenu réel s'affiche. Ouvrez le tableau et confirmez que chaque panneau montre une sortie réelle (pas l'espace réservé), que les badges sont colorés, que les éventuelles bascules views/brut fonctionnent là où elles sont présentes (et sont absentes là où il n'y a pas de deuxième vue authentique), et que les fonctions Pick/Feedback/Export fonctionnent. Si vous avez accès à un navigateur sans tête, faites une capture d'écran — également sur une largeur de téléphone (le tableau est mobile-first). Corrigez tout ce qui ressemble à un brouillon.

6. Jalon — partager la tranche la plus risquée. Remettez le tableau à l'humain (lien ou fichier) avec le premier sujet/ligne entièrement construit. Obtenez des retours avant de passer à l'échelle pour le reste. C'est le principe 9 — ne construisez pas tout en silence.

7. Collecter les choix + approfondir les gagnants. L'humain choisit les gagnants et laisse des notes, puis clique sur Exporter les choix + commentaires (Markdown ou JSON). Reprenez cela et approfondissez les variantes choisies — affinez, renforcez ou industrialisez ce qu'ils ont choisi.

L'interface du tableau (ce que le modèle fournit)

Un tableau blanc propre de cartes post-it — texte noir à contraste élevé, ombre subtile, bande d'en-tête pastel par carte, droites et alignées. Calibré par rapport aux vrais tableaux post-it / kanban.

• En-tête : titre, introduction figée, un sélecteur de sujet/graine (boutons qui changent l'entrée contrôlée), une légende des badges, Réinitialiser, et Exporter les choix + commentaires.
• Chaque carte (post-it) : étiquette de variante, description de technique d'une ligne, un emplacement de contenu générique (affiche du HTML/SVG en ligne, <img>, <iframe> en bac à sable, <audio>/synth, <pre><code>, ou une liste de contrôle réussite/échec — piloté par les données), des badges de métrique avec code couleur, et une bascule de vue nommée optionnelle (une rangée de pilules) lorsque les données fournissent content.views ou content.raw.
• Boutons par carte : ★ Choisir (bascule un surlignage de gagnant), ✎ Commentaire (note en ligne), plus des actions de contenu qui suivent la vue active (▶ Lire, ⤢ Ouvrir, ⧉ Copier).
• Exporter extrait les choix + notes de l'humain sous forme de Markdown ou JSON copiable. Les choix + notes persistent dans localStorage.
• Zéro dépendance, zéro réseau — fonctionne en ouvrant le fichier. Mobile-first : les cartes se réduisent à une colonne sur un téléphone, les cibles tactiles sont ≥40px, le sélecteur de sujet reste accessible dans l'en-tête collant, le texte du corps reste lisible. Adapté à la souris et au tactile, respecte prefers-reduced-motion.

Fichiers

Fichier	Objectif
template/comparison-lab.html	Le tableau. Autonome (CSS en ligne + JavaScript vanille), mobile-first. Copiez tel quel ; ne reconstruisez pas.
template/data.sample.json	Jeu de données fonctionnel prouvant la généralité (html, code, passfail, image+brut, une bascule content.views à N vues, audio sur 2 sujets). Copiez → data.json, éditez.
template/render-artifacts.example.mjs	Harnais copiable et adaptable pour le rendu d'artefacts de domaine réels (notation/graphiques/diagrammes) dans le tableau — regroupez votre moteur de rendu, intégrez une police de glyphes, extrayez le SVG en ligne sans tête, injectez + capturez. Éditez les blocs ADAPT THIS.
template/README.md	Comment remplir data.json ; le schéma complet, champ par champ (incl. content.views) ; le format d'exportation.
reference.md	Plongée en profondeur dans la conception de variantes + invites de recherche par domaine (§1), la table de rendu des modalités (§2), les badges (§3), le pointeur de schéma (§4), l'exemple musical travaillé incl. l'histoire brut vs traité (§5), le rendu d'artefacts réels + le harnais sans tête (§6), le schéma content.views + leçon métrique vs artefact (§7), et une liste de contrôle mobile-first (§8).

Remarques

• Il s'agit d'une compétence d'approche (comme le brainstorming) — invocable par slash ET invocable par modèle. Ne définissez pas disable-model-invocation.
• Copiez le modèle HTML textuellement — tout le travail d'interface est fait. Votre travail est la donnée : des variantes authentiques + du contenu réel + des badges.
• Ne livrez PAS un tableau de variantes quasi identiques. Si vous ne pouvez pas nommer chaque variante comme une technique distincte, vous n'avez pas effectué l'étape 2.
• Ne simulez PAS le contenu. Un panneau factice va à l'encontre du but (principe 7).
• Ne livrez PAS une bascule sans effet. N'ajoutez une vue views/brut que lorsqu'elle diffère réellement — les vues identiques se réduisent automatiquement, mais concevez pour une vraie différence (principe 5).
• Pour les aperçus interactifs plus grands, préférez iframe avec srcdoc plutôt qu'une énorme chaîne html. Pour le SVG rendu, intégrez via le type html, pas une data-URI <img> (reference.md §6).
• Gardez les médias générés en ligne (data: URIs, synthèse WebAudio) afin que le tableau reste un fichier unique partageable et hors ligne.