modeles : extraire le denominateur commun de patient 0

Patient 0 conflait trois roles : le denominateur commun, l'ecosysteme de
l'hebergeur de SITE-Chezlepro, et le detenteur du genome. Seul le premier est
generique -- il devient le modele `origine`.

Un modele n'a ni index reel, ni voute, ni parente, ni machines. Patient 0 avait
les quatre : c'est ce qui prouvait la confusion.

`origine` ne porte PAS serveur_ops_site ni serveur_cache_site : ce sont les
roles de l'hebergeur, et un client qui les recevrait aurait un pouvoir sur ses
voisins.

Trouve au passage : les six modeles prives portaient encore setops_plan_dir en
dur sur `instance/plan`. Corrige chez les instances il y a deux jours, il avait
survecu ici -- un deploiement par SETOPS_INSTANCE y aurait lu le plan d'une
autre instance.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,57 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-24 — Le dénominateur extrait : `origine` devient un modèle
+
+La hiérarchie se lit maintenant sans ambiguïté :
+
+```
+Set-OPS          le moteur — méthodes, rôles, preuves
+SITE-xxx         le terrain — UN par hébergeur
+Set-OPS-Modeles  les plans-types, dont `origine` est le dénominateur commun
+OPS-xxx          les écosystèmes réels : un modèle, posé sur un SITE
+```
+
+Chezlepro et Technolibre sont **frères** — deux OPS au même niveau.
+
+### Patient 0 conflait trois rôles
+
+La mesure l'a montré : il portait le dénominateur commun **et** un `index: 29`, une voûte
+réelle, une parenté, cinq VM en marche — quatre choses qu'un modèle n'a pas.
+
+```
+socle public   pki · edge · mail · dns
+patient 0      pki · edge · dns · forge · ops
+               + artefacts + cache_site + ops_site + resolveur
+```
+
+Trois rôles, dont **un seul est générique** :
+
+| rôle | où il vit désormais |
+|---|---|
+| le dénominateur commun | le modèle **`origine`** |
+| l'écosystème de l'hébergeur de `SITE-Chezlepro` | reste dans `OPS-Patient0` |
+| le détenteur du génome | reste dans `OPS-Patient0` |
+
+### Ce que `origine` ne porte pas
+
+**`serveur_ops_site` et `serveur_cache_site`** — les rôles de l'hébergeur. Un modèle qui
+les porterait donnerait à chaque client un pouvoir sur ses voisins.
+
+**Ni index réel, ni voûte, ni parenté.** Un modèle est une recette : `index: 1` est un
+gabarit que l'instanciation remplace par le seed dont tout l'adressage dérive.
+
+C'est la même séparation que pour les runners et pour les voûtes — distinguer **la recette**
+de **la machine qui l'applique**.
+
+### Et le même défaut, trouvé une fois de plus
+
+Les six modèles privés portaient encore `setops_plan_dir: instance/plan` — le lien du
+moteur, en dur. Corrigé chez les instances et le modèle public il y a deux jours, il avait
+survécu ici. Un déploiement lancé par `SETOPS_INSTANCE` y aurait lu le plan d'une **autre**
+instance, comme l'edge de patient 0 avait publié les noms de Chezlepro.
+
+Les sept modèles génèrent leur inventaire.
+
 ## 2026-08-24 — Les deux pare-feu appliqués, et un `derive` qui n'était compris que d'un côté
 
 ```

docs/audit/preuve-2026-08-24.md

@@ -13,7 +13,7 @@
 
 | # | Preuve | Affirmations | Statut | Detail |
 |---|---|---|---|---|
-| P01 | Lint (ansible-lint) | AFF-006 | ✅ OK | <unknown>:1: SyntaxWarning: invalid decimal literal |
+| P01 | Lint (ansible-lint) | AFF-006 | ✅ OK |  |
 | P02 | Tests unitaires (inventory_host) | — | ✅ OK | >>> le verrou tient : aucune VM n'aurait ete touchee |
 | P03 | Diff-vide du plan — TOUTES les instances | AFF-001, AFF-004, AFF-030, AFF-031, AFF-032 | ✅ OK | 4 instance(s) verifiee(s) — OPS-Chezlepro-lab, OPS-Chezlepro, OPS-Technolibre, OPS-Patient0 : plan et inventaire applique coincident. |
 | P04 | Groupes <-> playbooks homonymes | AFF-008 | ✅ OK |  |