build-the-gate-before-the-content
Un contrôle ajouté après ce qu'il protège est un contrôle que quelqu'un désactive pour livrer. Fermez-le pendant qu'il n'y a rien à bloquer.
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
- planification d'une migration
- démarrage d'une nouvelle surface
- on ajoutera le lint plus tard
- définir l'ordre des tâches
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 à construire quelque chose qui aura besoin d'une règle appliquée sur l'ensemble — une contrainte de style, une vérification de fraîcheur, un schéma, un validateur de liens, un budget. L'ordre naturel est de construire la chose puis d'ajouter la vérification une fois qu'il y a quelque chose à vérifier.
Cela ne s'applique pas à une vérification que vous ajoutez à du code qui existe déjà ; c'est un travail différent et plus difficile, et la réponse là-bas est un cliquet, pas un mur.
À faire
- Ajoutez la vérification dans le tout premier commit, avant qu'il n'existe le moindre contenu sur lequel elle pourrait échouer. Elle passe trivialement, et c'est bien le but : elle démarre au vert.
- Donnez-lui un message d'échec qui indique quoi exécuter. Une barrière dont la sortie est
assert Falsefinit supprimée par la prochaine personne qui la déclenche à 2h du matin. - Écrivez la vérification pour qu'elle échoue dès la première violation, pas la centième. Les cliquets sont pour le code existant ; un projet greenfield part de zéro.
- Quand la vérification se déclenche, corrigez le contenu. Chaque fois que vous modifiez la vérification à la place, notez dans le message de commit quel cas y a forcé.
À éviter
« On activera ça une fois que les pages seront écrites. » D'ici là, la vérification a accumulé un arriéré, l'activer
représente une journée de corrections sans rapport, et le chemin le moins coûteux est une liste skip qui ne rétrécit jamais.
Évitez aussi d'assouplir une barrière dans le même commit que la fonctionnalité qui l'a déclenchée. L'assouplissement est invisible dans un gros diff, et c'est exactement le moment où une barrière cesse d'en être une — il doit donc figurer dans son propre commit, avec sa propre explication.
Vérifier
Introduisez une violation exprès et confirmez que le build passe au rouge — puis retirez-la. Faites-le le jour même où vous écrivez la barrière, pas plus tard.
Une barrière que personne n'a jamais vue échouer n'est pas une barrière ; c'est un fichier qui prétend en être une.
Risque
Une barrière écrite avant le contenu encode une hypothèse sur un contenu qui n'existe pas encore, et certaines de ces hypothèses se révèlent fausses. Attendez-vous à devoir la restreindre une ou deux fois au début.
Cette restriction est le moment dangereux. Chacune affaiblit la règle, et une règle restreinte trois fois sans que personne ne le remarque est une règle qui ne couvre plus le cas pour lequel elle a été écrite. Épinglez chaque restriction avec l'exemple en échec qui l'a provoquée.
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/build-the-gate-before-the-content/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.
58c3de3bf7323fb3be38d084394e45ff97e408c20c45db31749cde2b8a13fc81