chimera-reproduce-before-diagnosing
Un diagnostic est une affirmation sur une machine que vous n'avez pas exécutée. Reproduisez d'abord l'échec en une commande courte — surtout quand le diagnostic vient de quelqu'un d'autre.
Conférée par la personne qui a relu la fiche, et non revendiquée par le fichier lui-même. Une fiche que l'agent distille au cours d'une exécution ayant consommé du contenu non fiable naît contaminée et reste en attente de relecture avant d'être un jour récupérée.
Quand elle vient à l'esprit
- un rapport de bug arrive
- un autre agent a expliqué la cause
- le traceback pointe vers un fichier
- corriger sans avoir vu l'échec
C'est dans À éviter et Vérifier que se trouve d'ordinaire la valeur. À faire est la section que tout le monde écrit.
Le corps de la fiche ci-dessus est une traduction. L'original anglais est ce que la CLI importe, ce que l'agent lit à l'exécution et ce que l'empreinte ci-dessous atteste.
Déclencheur
Vous vous apprêtez à modifier du code à cause d'une défaillance que vous n'avez pas vue se produire vous-même : un job de CI au rouge, un extrait de log dans un ticket, la description d'un utilisateur, ou — le cas dont parle vraiment cette carte — un diagnostic confiant remis par un relecteur, un sous-agent ou un outil d'analyse statique, avec fichier et numéro de ligne à l'appui.
Cela ne s'applique pas quand la défaillance est déjà une commande. Un test qui échoue en local quand vous le lancez est une reproduction ; n'en construisez pas une seconde. Cela ne s'applique pas non plus à un travail sans défaillance dedans — une nouvelle fonctionnalité, un refactor, une question de conception. Il n'y a rien à reproduire là-dedans.
À faire
- Écrivez la chose la plus courte qui échoue et qui peut se lancer seule : un script, un identifiant de nœud pytest, une invocation de CLI. « Lancez la suite et regardez la troisième erreur » n'en est pas une — vous passerez à côté de l'erreur à chaque fois.
- Lancez-la. Recopiez la vraie sortie dans vos notes : le type d'exception, la valeur erronée à côté de la valeur attendue, le code de sortie. Pas votre résumé de tout cela.
- Énoncez maintenant le diagnostic, et essayez aussitôt de le tuer. Placez un
raise RuntimeError("here")en tête de la fonction que le diagnostic met en cause et relancez la reproduction. Si la défaillance d'origine réapparaît inchangée, cette fonction n'est pas sur le chemin fautif et le diagnostic est faux, aussi bien argumenté fût-il. - Corrigez, relancez la même commande, et conservez la reproduction sous forme de test dans le même changement. Une reproduction supprimée après le correctif ne peut pas vous dire quand le correctif est annulé.
À éviter
Modifier la frame de la trace que vous reconnaissez. La frame que vous reconnaissez est celle que vous avez déjà lue, pas celle qui est fautive, et une modification plausible à cet endroit déplacera souvent le symptôme ailleurs — ce qui se lit ensuite comme un progrès.
Évitez d'hériter d'un diagnostic comme d'un fait. Une explication transmise n'est que du texte, et le processus qui produit une explication fausse et fluide est le même que celui qui en produit une juste ; la fluidité ne porte donc aucune information sur celle que vous avez reçue. Traitez-la comme une hypothèse avec un nom dessus : utile pour ordonner ce qu'on essaie, sans valeur comme preuve.
# reviewer says the cache key is missing the tenant id
key = f"{tenant.id}:{user.id}"
# yes — first make the failure appear on demand
# repro.py: two tenants, same user id, assert the second read misses
Et évitez le réflexe de relancer jusqu'au vert sur une défaillance intermittente. Relancer ne diagnostique pas une race condition, cela la cache, et cela transforme un bug reproductible une fois en un bug que personne ne peut plus reproduire du tout.
Vérifier
Avant d'écrire le correctif, répondez par oui ou non : puis-je faire réapparaître cette défaillance, tout de suite, en une seule commande ? Si non, vous ne déboguez pas, vous spéculez avec un éditeur ouvert.
Après le correctif : la même commande passe-t-elle désormais, et l'avez-vous vue échouer auparavant de vos propres yeux ? Un correctif validé uniquement par une suite qui passe au vert prouve que la suite est verte — ce qu'elle était peut-être déjà pour la mauvaise raison, si le cas fautif n'a jamais été dans la suite.
Risque
Certaines défaillances sont réellement coûteuses à reproduire : une race qui se manifeste une fois par jour, un état qui n'existe qu'en production, un plantage au bout de six heures de traitement. Exiger une reproduction bon marché dans ces cas-là coûte plus cher que le bug. Fixez-vous une limite de temps, et si elle expire, dites clairement que le correctif n'est pas vérifié au lieu de le décrire comme confirmé.
Le piège plus subtil est la minimisation excessive. Un script dépouillé peut se mettre à échouer pour une raison différente de l'originale, et vous corrigez alors le jouet. Prémunissez-vous en appliquant aussi le correctif au chemin fautif d'origine et en confirmant que le symptôme initial y disparaît — le cas minimisé est un outil pour trouver la cause, jamais la preuve que c'était bien la cause.
L'utiliser
La fiche est une donnée. Clonez le dépôt et importez-la par son chemin — ce qui arrive par le réseau est traité comme contaminé et retenu pour approbation, ce qui est le comportement souhaitable et la raison pour laquelle il n'y a pas d'installateur en une ligne ici.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-reproduce-before-diagnosing/SKILL.mdIntégrité
SHA-256 du fichier tel qu'il est publié. Qui l'importe peut vérifier que ce qu'il a reçu correspond à ce que cette page affichait.
9d70fa5a61992e3b79a2d0ab2afb592c41a7b63274efbdca0afec1724a5b8338