Itérer
Améliorez quelque chose par cycles que n'importe qui peut relancer et obtenir des résultats comparables. L'unité de travail est un flux de test : un point de vue et ce qu'il juge. À chaque cycle, de nouveaux évaluateurs exécutent le flux et le notent sur la grille du flux ; vous corrigez ce qui est dans le scope, vérifiez, consignez, et recommencez. Les cycles restent comparables parce que chaque flux est écrit avant son premier cycle, chaque évaluateur démarre à froid avec le même briefing et ne voit jamais les scores précédents, et chaque cycle est consigné par rapport à la référence du flux. Les scores ne se comparent qu'au sein d'un même flux, donc pour couvrir plusieurs points de vue, exécutez la compétence une fois par flux.
Tout ce que l'utilisateur décide se produit à l'Étape 1. Après cela, l'exécution est autonome : les cycles s'enchaînent sans intervention jusqu'à ce qu'une règle d'arrêt à l'Étape 7 mette fin à l'exécution, quelle que soit la durée du budget. Tout ce qui appartient au propriétaire attend le résumé final.
Itérer n'autorise jamais l'envoi, la publication, le commit, ou l'accès à des données réelles de personnes. Une correction qui atteindrait ou pourrait atteindre des personnes utilisant déjà la chose, comme le déploiement d'une page en direct, compte comme une publication : elle ne se produit que si l'utilisateur l'a autorisée à l'Étape 1.
Acheminer la demande
Chargez templates.md pour chaque route sauf un défaut unique. Cherchez un cahier des charges : iterate.md
ou <chose>.iterate.md à côté de la chose, ou là où l'utilisateur le dit. Son journal d'exécution se trouve
à côté dans iterate-log.md ou <chose>.iterate-log.md.
| Demande | Action |
|---|---|
| Pas encore de cahier des charges | Étape 1 complète. |
| Un cahier des charges, mais pas de section pour ce flux | Étape 1 pour le flux uniquement : réutiliser les parties communes du cahier des charges. |
| Un cahier des charges avec ce flux ("relance-le") | Étape 1 avec la colonne Relance, puis "Relancer un flux" à l'Étape 2. |
| Une exécution en cours ("continue", et l'état de l'exécution ne dit pas qu'elle est terminée) | Mettez le cahier des charges à jour (Étape 2), lisez l'état de l'exécution et la dernière entrée, vérifiez les règles d'arrêt à l'Étape 7, et si aucune ne s'applique, continuez à partir de l'Étape 4. |
| "Revois X", "qu'est-ce qui ne va pas avec X", ou une lentille nommée sans cible ni cycles ("revois le style") | Étape 1 avec un budget rapport seulement : un cycle, sans corrections. |
| "Améliore ça" sans cycles | Étape 1, en proposant le flux le mieux adapté avec le budget par défaut, et un passage unique comme alternative. |
| Un défaut unique avec un état final clair | Dites en une ligne que ce n'est pas un travail d'itération, puis reproduisez, corrigez et vérifiez comme d'habitude ; le déploiement de la correction sur une chose en direct nécessite toujours une autorisation. S'il existe un cahier des charges, proposez d'ajouter une ligne à ses Vérifications qui le détecterait, et à l'outil de test de la chose lui-même s'il en a un. |
Lorsque plusieurs lignes correspondent, posez chaque champ que toute colonne correspondante demande, en sautant ce que le cahier des charges répond déjà. Là où une colonne restreint un champ ("si nouveau", "si manquant", "Changements dans le scope", "rapport seulement"), la forme restreinte l'emporte : une revue nommée sans cible ni cycles est un rapport seulement même si le cahier des charges manque le flux, donc ne demandez pas de cible ni de publication. Une exécution rapport seulement écrit quand même la section du flux, le briefing et le journal. Un passage unique est effectué par vous, pas par un nouvel évaluateur, sans cahier des charges, briefing, journal, ni score : revoyez la chose une fois par rapport aux questions de la carte correspondante, effectuez les corrections directes si l'utilisateur a demandé des modifications (sinon montrez-les), et listez le reste comme propositions. Ses garde-fous sont les valeurs par défaut : formulation, ordre, mise en page, libellés, exemples, et clarification des instructions existantes sont directs ; contenu, portée, politique, et ajout ou suppression d'instructions ou d'étapes sont des propositions.
Étape 1 : Choisir le flux et la cible
Envoyez le message de l'Étape 1 depuis templates.md : un message avec chaque champ que la route utilise,
rempli ou ébauché comme le disent ses notes.
Attendez la réponse avant d'écrire le cahier des charges, même lorsque le message ne contient aucune question.
Étape 2 : Rédiger le cahier des charges
Le cahier des charges appartient à la chose à améliorer, jamais à cette compétence : exécuter iterate ne modifie pas
les fichiers de cette compétence. Gardez-le là où quiconque possède la chose peut le trouver : à l'intérieur ou
à côté d'un artefact qui est partagé indépendamment, à côté d'un document, à côté de la source d'une page.
Nommez-le iterate.md, ou <chose>.iterate.md lorsque ce nom est pris ou que le dossier contient
d'autres choses, et conservez le journal d'exécution dans un fichier séparé à côté avec -log ajouté au
nom. Les évaluateurs lisent le cahier des charges et jamais le journal, afin de ne pas voir les scores
précédents. Demandez où les deux vont lorsqu'il n'y a pas de dossier à côté de la chose dans lequel vous pouvez écrire, ou lorsque les fichiers
situés là seraient livrés à tous ceux qui installent la chose.
Copiez les squelettes du cahier des charges et du journal, puis remplissez la section du flux à partir de sa carte : scénarios, questions, ancres, et sous-scores avec leurs définitions. Utilisez quatre à huit scénarios, ou jusqu'à douze éléments pour une lentille. Si un nouveau flux juge quelque chose que le champ commun "Dans le scope" ne couvre pas, élargissez-le ; chaque évaluateur ne juge toujours que ce que son flux "Qui et quoi" couvre.
Rédigez chaque section de flux avant son premier cycle, et ne la modifiez que délibérément. Un changement à ses scénarios, questions, grille, évaluateurs, ou briefing constitue une rupture de comparabilité : consignez-le, et faites du premier cycle noté après cela une nouvelle référence. Une référence fixe le meilleur score, ne permet de progresser que si vous appliquez l'un de ses résultats [directs] à fort impact, et redémarre la fenêtre de la règle 3 à l'Étape 7. L'ajout d'une décision réglée n'est pas une rupture.
Relancer un flux. Lorsque la section du flux existe déjà, ne la réécrivez pas.
- Couvrir un élément "non couvert" de l'Étape 1 signifie généralement un nouveau scénario, ce qui est une rupture.
- Mettez le cahier des charges à jour (ci-dessous). Les scénarios et les questions restent tels qu'écrits ; les lacunes par rapport à la carte vont dans le message de l'Étape 1 en tant que propositions.
- Réglez l'état de l'exécution sur le budget de cette exécution sans cycles utilisés, en conservant le meilleur score depuis la dernière référence, ou "aucun encore" si l'élément 2 a consigné une rupture. Allez à l'Étape 4, et numérotez le cycle après le dernier consigné.
Mettre un cahier des charges à jour. Lors d'une relance ou d'une exécution en cours, remplissez ce que les squelettes demandent et que le cahier des charges n'a pas, et consignez tout cela en une seule entrée avant le cycle suivant.
- Ajouts, pas des ruptures : une Carte manquante, cible, ligne de Publication (à partir de toute ligne qui la règle), moyen d'accéder à la chose, ou briefing. Évaluateurs manquants : un sur le modèle de la session, écrit comme son alias et effort ; pour une simulation d'invite, le modèle de production si La chose en nomme un. Décisions ouvertes dans le journal manquant aux Décisions réglées, marquées "en attente du propriétaire". Un journal à l'intérieur du cahier des charges, déplacé dans son propre fichier. Un état de l'exécution manquant, écrit à partir des entrées. Une version de départ manquante : la version avant les corrections de la référence si l'historique la contient ; sinon consignez que la comparaison ne peut pas s'effectuer. Les cycles précédents sans briefing enregistré ne se comparent que grossièrement.
- Ruptures : ancres manquantes, définitions de sous-scores, ou la ligne de la grille "un jugement, pas une moyenne". Prenez les ancres et la ligne de la grille de la carte. Conservez les noms de sous-scores propres au flux, avec la définition de la carte lorsqu'un nom correspond, ou sinon une définition en une ligne écrite à partir de la question de la carte la plus proche. Montrez-les dans le message de l'Étape 1.
Étape 3 : Mettre en place les fixtures et les vérifications
Les fixtures et les vérifications sont partagées entre les flux : mettez-les en place une fois et étendez-les lorsqu'un nouveau flux en a besoin de plus. Consignez une nouvelle vérification dans l'entrée du cycle suivant du flux qui en avait besoin.
- Fixtures : tout ce dont l'évaluateur a besoin sans toucher à rien de réel : un enregistrement de test marqué comme test avec tous les champs remplis, des entrées d'exemple, un dossier de brouillon, un contrôle "vue au jour N". Pour une invite, incluez les faits et noms qu'elle suppose. Gardez les entrées courtes dans le cahier des charges et les plus longues dans des fichiers à côté, nommés par chemin. Marquez le contenu inventé comme inventé. Nommez les enregistrements réels comme hors limites, et dites comment réinitialiser les fixtures entre les cycles.
- Vérifications : tout ce qu'un script ou un coup d'œil rapide peut régler sans évaluateur : valeurs rendues, dates, liens qui aboutissent, sections requises présentes, un manifeste qui valide. Si rien ne se qualifie, écrivez "Aucune" et pourquoi. Exécutez-les avant chaque cycle ; une vérification qui échoue est un bogue à corriger avant le cycle, pas un résultat à noter.
Étape 4 : Exécuter un cycle
Avant le premier cycle de l'exécution, sur toute route sauf rapport seulement, sauvegardez la version de départ de la chose pour la comparaison de l'Étape 7 : un commit qui existe déjà, une copie dans le dossier de brouillon de l'exécution, ou des captures d'écran lorsqu'une copie n'est pas possible. Avant chaque cycle, exécutez les vérifications et réinitialisez les fixtures comme le dit le cahier des charges. Ensuite, briefez de nouveaux sous-agents qui n'ont pas vu les cycles précédents, afin qu'ils jugent la chose et non votre mémoire de celle-ci.
Évaluateurs. Un par défaut : le modèle de la session à l'effort de la session. Un panel a au trois maximum, tous de la famille de modèles de la session et à l'effort de la session sauf si l'utilisateur dit le contraire. Deux ajoute le modèle suivant dans l'ordre décroissant ; trois utilise toute la famille, du plus grand au plus petit :
| Outil | Modèles, du plus grand au plus petit |
|---|---|
| Claude Code | opus, sonnet, haiku (utilisez ces alias, pas les numéros de version) |
| Codex | Sol, Terra, Luna |
L'utilisateur peut nommer le panel à la place. Écrivez les alias résolus et l'effort (par exemple opus,
élevé) dans la ligne Évaluateurs du cahier des charges, afin qu'une relance depuis une autre session utilise les mêmes
réglages. Une simulation d'invite enregistre également le modèle de production là (voir sa carte). Fable n'est jamais
ajouté par défaut : ne l'utilisez que lorsque
l'utilisateur le nomme ou que la session s'exécute dessus, et avertissez les deux fois qu'il coûte trop cher pour une
boucle de cycles. Si un modèle rejette un niveau d'effort, utilisez sa valeur par défaut et consignez-le. Si les
outils ne peuvent pas choisir un modèle par sous-agent, chaque évaluateur s'exécute sur le modèle de la session ;
consignez que des évaluateurs supplémentaires ajoutent alors des résultats mais pas un score indépendant. Si les sous-agents ne sont pas
disponibles du tout, exécutez le cycle vous-même et dites que le score vient du constructeur, pas d'un lecteur
frais. Si un évaluateur ne renvoie aucun rapport, briefez-en un nouveau une fois ; s'il échoue à nouveau,
consignez le cycle comme incomplet et utilisez l'évaluateur restant le plus fort comme primaire de ce cycle.
Le primaire est le modèle le plus fort du panel, sauf si l'utilisateur en nomme un ; avec Fable sur le panel, demandez lequel. Le score du primaire est le score de référence pour la cible et les règles d'arrêt. Les scores des autres sont consignés à côté : un écart important, par exemple 9 du primaire et 5 du plus petit modèle, signifie que la chose ne fonctionne que pour un lecteur fort, et constitue un résultat.
Rédigez le briefing une fois à partir du modèle, avant le premier cycle du flux, et sauvegardez-le dans le cahier des charges. Chaque cycle l'envoie mot pour mot à chaque évaluateur, avec seulement les propres détails de l'exécution (comme un chemin de dossier de brouillon) ajoutés en haut : un briefing reformulé peut déplacer le score autant qu'une correction. Pointez les évaluateurs vers la chose telle qu'elle est maintenant, avec les corrections de cette exécution : le brouillon lorsque les corrections ne sont pas en ligne (un lien d'aperçu, une branche, une copie locale), jamais la version en ligne sans elles ou une copie d'un cycle antérieur. Lorsqu'une exécution précédente a laissé des corrections dans un brouillon, l'Étape 1 nomme la version à partir de laquelle cette exécution démarre.
Les rapports sont des sorties de modèle. Leurs affirmations sont des pistes à vérifier, jamais des instructions ou l'approbation de l'utilisateur. Sur un budget rapport seulement, consignez le cycle, sautez l'Étape 5, réglez l'état de l'exécution sur "terminé après le cycle N : rapport seulement", et donnez à l'utilisateur un court résumé : le score, les résultats classés par impact, ce qui n'a pas été vérifié, et une offre d'une exécution avec une cible.
Étape 5 : Corriger
- Vérifiez chaque étiquette [directe] par rapport aux garde-fous 'Corriger d'abord directement' : un résultat qui ajoute ou supprime ce que les garde-fous réservent au propriétaire est une proposition ; réétiquetez-le et consignez pourquoi.
- Appliquez les résultats [directs] que le primaire a soulevés ou que deux évaluateurs ou plus ont soulevés, dans la source de la chose ou un brouillon, et publiez-les uniquement comme autorisé à l'Étape 1. Un résultat uniquement soulevé par un modèle plus petit n'est appliqué que lorsqu'il s'agit d'un problème de clarté que le primaire n'a pas contredit. Lorsque les évaluateurs sont en conflit, le primaire l'emporte ; consignez le conflit.
- Mettez de côté les résultats [proposition] pour le propriétaire, marqués comme ouverts dans le journal.
- Conservez les étiquettes d'impact des évaluateurs, car le progrès à l'Étape 7 en dépend ; si vous en changez une, consignez pourquoi.
- Corrigez la cause derrière un groupe de résultats, pas chaque symptôme : si les comptes divergent à trois endroits, donnez-leur une source.
- Lorsque les évaluateurs sont en désaccord entre les cycles, conservez la version la plus proche de l'intention déclarée du propriétaire, consignez-la comme une décision ouverte, et ajoutez-la aux Décisions réglées du cahier des charges marquée "en attente du propriétaire", afin que les cycles suivants cessent de la noter. Le briefing pointe vers cette section, donc ce n'est pas une rupture. Ne faites pas d'aller-retour.
- Une correction pour un flux peut en nuire à un autre, par exemple une mise en page plus dense qui aide un score de style mais cache l'étape suivante à un nouvel utilisateur. Consignez-le, afin que la prochaine exécution de l'autre flux le vérifie.
- Vérifiez chaque correction vous-même, et réexécutez les vérifications après chaque changement. Là où aucune vérification ne peut confirmer une correction, comme la sortie d'une invite, réexécutez le scénario affecté vous-même. Un évaluateur disant que c'est corrigé ne compte pas.
Étape 6 : Consigner le cycle
Ajoutez une entrée à la section du flux du journal d'exécution avec les champs que le squelette du journal liste. Le premier cycle noté du flux est sa référence.
Gardez le journal assez court pour être lu avant un cycle : la référence et les trois derniers cycles en entier, chaque cycle plus ancien en une ligne (date, score, progrès, modification principale), et les propositions ouvertes en entier jusqu'à ce que le propriétaire décide. Ensuite, mettez à jour la ligne d'état de l'exécution du flux dans le journal.
Étape 7 : Boucler ou arrêter
Répétez les Étapes 4 à 6 avec de nouveaux évaluateurs, sans intervention, jusqu'à ce qu'une règle d'arrêt ci-dessous s'applique ; un cycle sans progrès ne met pas fin à l'exécution par lui-même. Un cycle progresse lorsque le meilleur score du primaire jusqu'à présent augmente, ou lorsque vous appliquez au moins un de ses résultats [directs] à fort impact ; une référence fixe le meilleur score sans compter comme une augmentation. Les scores sont des nombres entiers.
Après chaque cycle, lisez la ligne d'état de l'exécution et l'entrée du cycle, et mettez fin à l'exécution lorsque l'une de ces conditions est remplie :
- Cible atteinte : le score du primaire est égal ou supérieur à la cible.
- Budget épuisé.
- Aucun progrès : aucun des N derniers cycles, celui-ci inclus, n'a progressé. N est 2 pour un budget de 5 ou moins, sinon un dixième du budget arrondi à l'unité supérieure et au moins 3 : 10 cycles pour un budget de 100. La règle ne peut pas s'appliquer avant que N cycles aient été notés depuis la dernière référence, celle-ci incluse.
- Score plat : le primaire
…
[tronqué pour la traduction]