Contexte
Le lot 0.1.84 a corrigé onze issues qui n'avaient qu'une chose en commun : un
contrôle qui, faute de pouvoir mesurer, concluait que tout allait bien.
Ce n'est pas une coïncidence, c'est une règle que le projet applique sans
l'avoir jamais écrite. Le CHANGELOG en porte plusieurs autres, chacune découverte
au moment où elle a été violée :
| Invariant |
L'issue qui l'a révélé |
| une sonde qui n'a pas pu regarder ne conclut pas au vert |
#172, le pool libvirt |
| zéro test exécuté n'est pas une note de zéro |
#168 |
| une fixture déclarée et absente n'est pas un workdir partiel |
#177 |
| provisionné n'est pas utilisable |
#170, #178 |
| une commande exécutée n'est pas un état atteint |
la machine d'état des labs |
| la sortie humaine n'est pas l'interface machine |
--json |
| un échec qui ne se dit pas est pire qu'un échec |
#170, #173, #179 |
Pourquoi les écrire
Un contributeur — humain ou agent — qui ajoute un contrôle demain n'a aucun
moyen de deviner ces règles. Elles sont dispersées dans des commentaires, des
docstrings de tests et des entrées de CHANGELOG. Chacune a coûté un bug pour
être découverte ; les réapprendre coûtera les mêmes bugs.
C'est aussi ce qui permettrait de refuser une contribution sans discussion
au cas par cas : « ce contrôle rend ok quand sa sonde échoue » suffit alors
comme motif.
Critères d'acceptation
Ce dernier point est le plus utile : il transforme une liste de bonnes
intentions en une carte de ce qui est réellement gardé, et rend visibles les
invariants qui ne le sont pas encore.
Relevé en confrontant au code une analyse externe du dépôt, le 2026-08-24.
Contexte
Le lot 0.1.84 a corrigé onze issues qui n'avaient qu'une chose en commun : un
contrôle qui, faute de pouvoir mesurer, concluait que tout allait bien.
Ce n'est pas une coïncidence, c'est une règle que le projet applique sans
l'avoir jamais écrite. Le CHANGELOG en porte plusieurs autres, chacune découverte
au moment où elle a été violée :
--jsonPourquoi les écrire
Un contributeur — humain ou agent — qui ajoute un contrôle demain n'a aucun
moyen de deviner ces règles. Elles sont dispersées dans des commentaires, des
docstrings de tests et des entrées de CHANGELOG. Chacune a coûté un bug pour
être découverte ; les réapprendre coûtera les mêmes bugs.
C'est aussi ce qui permettrait de refuser une contribution sans discussion
au cas par cas : « ce contrôle rend
okquand sa sonde échoue » suffit alorscomme motif.
Critères d'acceptation
docs/design-principles.md(EN + FR) énonce les invariants, chacun avecl'incident qui l'a révélé — un principe sans son histoire se discute, un
principe avec son bug se respecte.
CONTRIBUTING.mdy renvoie, dans la section qui décrit ce qu'une PR doitrespecter.
test_journal_en_anglais.py,test_note_sans_mesure.py,test_sondes_des_tests_docker.py, le garde-fou i18n.Ce dernier point est le plus utile : il transforme une liste de bonnes
intentions en une carte de ce qui est réellement gardé, et rend visibles les
invariants qui ne le sont pas encore.
Relevé en confrontant au code une analyse externe du dépôt, le 2026-08-24.