pin-the-case-that-narrowed-the-rule
Quand un contrôle se déclenche sur la mauvaise cible, le correctif l'affaiblit. Capturez le faux positif sous forme de test dans le même commit, sinon la règle s'érode en silence.
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
- le linter signale du code légitime
- ajouter une exception
- faux positif en CI
- assouplir un contrôle
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
Une vérification que vous avez écrite a échoué sur quelque chose qui est en fait correct, et vous vous apprêtez à ajouter une exemption, une entrée dans une liste blanche, ou un motif plus restreint.
Cela ne s'applique pas quand la vérification a trouvé un vrai problème — corrigez le problème. Cela ne s'applique pas non plus au réglage d'un seuil avant que la vérification n'ait jamais tourné en conditions réelles.
À faire
- Notez, en une phrase, pourquoi le cas signalé est légitime. Si vous n'y arrivez pas, c'est peut-être la vérification qui a raison et le code qui a tort.
- Ajoutez les deux cas à la suite de tests : le cas légitime qui doit passer, et une version synthétique de la vraie violation qui doit continuer à échouer.
- Restreignez la règle le moins possible. Exemptez un chemin, pas tout un répertoire ; exigez une négation à proximité, plutôt que de supprimer la phrase de la liste.
- Mettez la restriction dans son propre commit, et indiquez dans le message quel cas y a forcé.
À éviter
Supprimer la règle parce qu'elle a été gênante une fois. Évitez aussi la version plus discrète : élargir une exemption jusqu'à ce que la règle ne couvre plus rien — une liste blanche qui grossit à chaque sprint est une règle qu'on retire une ligne à la fois, sans que personne n'ait décidé de la retirer.
Évitez d'exempter par fichier quand la vraie distinction se fait par sens. Une vérification de phrase qui interdit une phrase purement et simplement interdira aussi l'avertissement qui la nie, et la correction honnête est d'exiger la négation, pas d'arrêter de vérifier cette page.
Vérifier
Après la restriction, lancez la suite avec la violation d'origine réintroduite. Elle doit toujours échouer.
Lisez ensuite le diff de la règle elle-même et demandez-vous : quelle classe de problème peut maintenant passer alors qu'elle ne le pouvait pas avant ? Si vous ne pouvez pas répondre, la restriction n'a pas été comprise.
Risque
Cela ajoute un test pour chaque exception, et une suite pleine de tests d'exception est une suite fastidieuse à lire.
Le risque le plus important est de traiter le test épinglé comme la preuve que la règle est toujours solide. Il prouve qu'un cas échoue encore. Une règle restreinte cinq fois a cinq cas épinglés et possiblement un grand trou entre eux, et seule une relecture de la règle dans son ensemble le révélera.
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/pin-the-case-that-narrowed-the-rule/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.
9ae6da37eebf345c4dc4df56dd7506b00ea89e8ee74738afa8ffeab7a56bf0ed