Skip to content

[P1] Écrire les invariants du projet, qui sont aujourd'hui la seule chose qui tient les décisions #200

Description

@stephrobert

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

  • docs/design-principles.md (EN + FR) énonce les invariants, chacun avec
    l'incident qui l'a révélé — un principe sans son histoire se discute, un
    principe avec son bug se respecte.
  • CONTRIBUTING.md y renvoie, dans la section qui décrit ce qu'une PR doit
    respecter.
  • Le gabarit de PR renvoie au document plutôt que de dupliquer la liste.
  • Chaque invariant nomme le test qui le tient quand il en existe un —
    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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions