doc : enseigner la classe de defaut, pas seulement la corriger
Some checks are pending
verifier / verifier (push) Waiting to run
Some checks are pending
verifier / verifier (push) Waiting to run
L'exploitant, apres le refactor : « je n'y comprends rien ». C'est la mesure qui compte — la regle fondatrice du depot est qu'un humain pilote sans IA, et une correction qu'il ne peut pas expliquer ne lui appartient pas. - L'unite « La preuve » gagne une section : le defaut le plus dangereux n'est pas l'erreur, c'est la COPIE. Neuf copies ne vieillissent pas ensemble, et la divergence ne se voit jamais de l'interieur d'une copie. Avec le cas vecu — un devis qui repondait CONFORME sur le mauvais ecosysteme parce que les deux avaient les memes valeurs. - Le glossaire gagne « source unique » et « resolution d'instance » ; P39 les exige. - Le rapprochement qui rend la chose evidente : c'est la meme lecon que proxmox-hebergeur.yml, ou les listes du cluster recopiees chez chaque tenant avaient deja diverge. Une source, pas N copies — pour les donnees comme pour le code. Plan de recette regenere. make verifier 41/41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
c18debc25e
commit
5bb503be45
3 changed files with 54 additions and 0 deletions
|
|
@ -776,6 +776,7 @@ JARGON_A_ENSEIGNER = [
|
|||
"SMTP", "IMAP", "LMTP", "DKIM", "MTA",
|
||||
# etat et methode
|
||||
"restic", "devis", "preuve", "harnais", "GUI", "index", "plan", "tenant", "SQLite",
|
||||
"source unique", "resolution d'instance",
|
||||
# filiation — le vocabulaire arrive le 2026-08-21 avec les signatures
|
||||
"genome", "parente", "commit", "empreinte", "Merkle", "etiquette", "signature",
|
||||
"allowed-signers", "temoin", "journal de transparence", "horodatage",
|
||||
|
|
|
|||
|
|
@ -298,6 +298,15 @@ sans rien écrire (`make sdn-plan`, `make placement-plan`).
|
|||
**Preuve (Pxx)** — Une vérification rejouable de `make prouver` qui garde une classe
|
||||
d'erreur. Cf. [La preuve](La-preuve).
|
||||
|
||||
**Source unique** — Le principe qui traverse tout le dépôt : une information vit à **un**
|
||||
endroit, et tout le reste en dérive. Neuf copies d'une même règle ne vieillissent pas
|
||||
ensemble — et la divergence ne se voit jamais de l'intérieur d'une copie.
|
||||
|
||||
**Résolution d'instance** — Comment un script sait **quel écosystème** il regarde : la
|
||||
variable `SETOPS_INSTANCE`, sinon le lien `instance`. Une seule fonction y répond pour tout
|
||||
le moteur (`inventory_rules.instance_courante`) ; la preuve P41 refuse qu'on en réécrive
|
||||
une deuxième.
|
||||
|
||||
**Harnais** — L'ensemble des preuves. Un `make prouver` vert veut dire : aucune des classes
|
||||
d'erreur connues n'est présente.
|
||||
|
||||
|
|
|
|||
|
|
@ -87,6 +87,50 @@ harnais de Set-OPS ».
|
|||
|
||||
---
|
||||
|
||||
## Le défaut le plus dangereux n'est pas l'erreur, c'est la **copie**
|
||||
|
||||
Set-OPS pilote plusieurs écosystèmes. Avant d'agir, chaque script doit donc savoir
|
||||
**lequel il regarde** — par le lien `instance`, ou par la variable `SETOPS_INSTANCE`.
|
||||
|
||||
En août 2026, **neuf scripts avaient chacun écrit leur propre réponse** à cette question.
|
||||
Trois lignes chacun. Aucune n'était fausse en soi.
|
||||
|
||||
Le problème n'est pas l'erreur : c'est que **neuf copies ne vieillissent pas ensemble**.
|
||||
Quand on améliore l'une, les huit autres ne le savent pas. Et personne ne peut le voir,
|
||||
parce que de l'intérieur d'un fichier, la copie locale a toujours l'air correcte.
|
||||
|
||||
### Ce que ça donnait
|
||||
|
||||
`make placement-plan` visait patient 0 et répondait :
|
||||
|
||||
```
|
||||
Devis du placement — tenant « instance »
|
||||
noeud asgard · stockage TrueNAS · gabarit 99998 → CONFORME
|
||||
```
|
||||
|
||||
C'était vrai — **sur l'autre écosystème**. Sa copie lisait le lien au lieu de la variable.
|
||||
Comme les deux tenants portaient les mêmes valeurs de placement, le verdict semblait
|
||||
juste. C'est très exactement la circonstance où une erreur ne se voit pas.
|
||||
|
||||
Cinq défauts de cette famille sont sortis en cinq jours. Tous dans des outils qui
|
||||
**constatent** — preuves et devis — jamais dans ceux qui agissent. C'est moins grave et
|
||||
plus insidieux : un outil qui agit mal, on le voit ; un outil qui mesure mal dit
|
||||
« conforme », et on passe à la suite.
|
||||
|
||||
### La réponse
|
||||
|
||||
Une **source unique** : une fonction, dans un fichier, que tous appellent. Si elle est
|
||||
fausse, elle l'est partout d'un coup — donc visible, donc corrigée une fois.
|
||||
|
||||
Et une preuve, **P41**, qui refuse la prochaine copie. Elle en a trouvé une dixième le
|
||||
jour de son écriture, dans le fichier des preuves lui-même.
|
||||
|
||||
> **C'est la même leçon que `proxmox-hebergeur.yml`** : les nœuds et stockages du cluster
|
||||
> recopiés chez chaque tenant avaient divergé. Une source, pas N copies — pour les données
|
||||
> comme pour le code.
|
||||
|
||||
---
|
||||
|
||||
## Pour aller plus loin *(dépôt)*
|
||||
- Le mode d'emploi : `docs/audit/README.md`.
|
||||
- Le registre : `docs/audit/affirmations.md` ; le harnais : `scripts/prouver.py`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue