Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
Set-OPS-Public/docs/audit/schema-plan.json

382 lines
11 KiB
JSON
Raw Normal View History

schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"description": "GENERE par scripts/schema_plan.py (make schema). Ne pas editer a la main. Decrit la FORME des registres ; la COHERENCE reste aux validateurs de inventory_rules.py.",
"registres": {
"applications": {
"entite": {
"additionalProperties": false,
"properties": {
"expose": {
"description": "FQDN publies par l'edge. Derivent le vhost, les SAN et le plancher /etc/hosts.",
"items": {
"type": "string"
},
"title": "Exposition publique",
"type": "array"
},
"groupe": {
"description": "La capacite appliquee. Doit avoir un playbook homonyme.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Groupe (rôle)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string",
"x-source-valeurs": "groupes_operationnels"
},
"hote": {
"description": "Une VM declaree au plan. Un hote inconnu est un « hote fantome » (P06).",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Hôte",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string",
"x-source-valeurs": "serveurs"
},
"liens": {
"description": "Roles acceptes par le role porteur (meta/liens.yml).",
"items": {
"type": "object"
},
"title": "Liens (bindings)",
"type": "array"
},
"port": {
"title": "Port",
"type": "integer"
},
"requiert": {
"description": "Dependance applicative. Indicative : l'ordre de deploiement vient des couches.",
"items": {
"type": "string"
},
"title": "Requiert",
"type": "array"
},
"websocket": {
"description": "L'edge doit relayer la mise a niveau de connexion.",
"title": "WebSocket",
"type": "boolean"
}
},
"required": [
"groupe",
"hote"
],
"type": "object"
},
"title": "Applications",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"x-clef": {
"description": "Nom de l'application dans le plan.",
"title": "Identifiant"
},
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"x-fichier": "plan/applications.yml",
"x-racine": "applications"
},
"bases_donnees": {
"entite": {
"additionalProperties": false,
"properties": {
"base": {
"title": "Base",
"type": "string"
},
"consommateur": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"description": "Qui utilise cette base. La liste depend de la portee.",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"title": "Consommateur",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"type": "string",
"x-source-selon": {
"cas": {
"application": "applications",
"hote": "serveurs"
},
"champ": "portee",
"defaut": "groupes_operationnels"
}
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
},
"portee": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"default": "groupe",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"description": "Comment le consommateur est designe : par application, par groupe ou par hote.",
"enum": [
"application",
"groupe",
"hote"
],
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Portée",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"proprietaire": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Propriétaire",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"secret": {
"description": "NOM d'une variable Vault, jamais une valeur. Le secret ne quitte pas le role.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Secret (Vault)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"serveur": {
"title": "Serveur de BD",
"type": "string",
"x-source-valeurs": "serveurs_bd"
},
"usage": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"default": "principale",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"title": "Usage",
"type": "string"
}
},
"required": [
"base",
"consommateur",
"proprietaire",
"secret",
"serveur"
],
"type": "object"
},
"title": "Bases de donnees",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"x-clef": {
"description": "Nom de l'entree au registre, ex. `bd_forgejo`.",
"title": "Identifiant"
},
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"x-fichier": "plan/bases-donnees.yml",
"x-racine": "bases_donnees"
},
"domaines_publics": {
"entite": {
"additionalProperties": false,
"properties": {
"autorite": {
"enum": [
"auto-heberge",
"delegue",
"primaire-cache"
],
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Autorité DNS",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"dnssec": {
"title": "DNSSEC",
"type": "boolean"
},
"edge": {
"title": "Edge",
"type": "string",
"x-source-valeurs": "serveurs"
},
"mail": {
"description": "La zone porte des enregistrements de messagerie.",
"title": "Courriel",
"type": "boolean"
},
"secondaires": {
"items": {
"type": "string"
},
"title": "Secondaires",
"type": "array"
}
},
"type": "object"
},
"title": "Domaines publics",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"x-clef": {
"description": "Le nom public, ex. `chezlepro.ca`.",
"title": "Domaine"
},
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"x-fichier": "plan/domaines.yml",
"x-racine": "domaines_publics"
},
"nomenclature": {
"entite": {
"additionalProperties": false,
"properties": {
"categories": {
"additionalProperties": {
"additionalProperties": false,
"properties": {
"libelle": {
"description": "Nom lisible de la zone (Frontiere, Identite...).",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Libellé",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
}
},
"required": [
"libelle"
],
"type": "object"
},
"description": "Une zone de securite par cle. Le numero derive le 3e octet et le VLAN.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Catégories (zones)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "object"
},
"cidr_hote": {
"title": "CIDR d'hote",
"type": "integer"
},
"fonctions": {
"additionalProperties": {
"additionalProperties": false,
"properties": {
"categorie": {
"description": "La zone. Fixe le 3e octet (15 + categorie) et le VLAN.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Catégorie",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "integer"
},
"service": {
"description": "Fixe le bloc d'adresses de l'hote dans la zone.",
"title": "Service",
"type": "integer"
}
},
"required": [
"categorie",
"service"
],
"type": "object"
},
"description": "categorie + service par fonction. VMID et IP en derivent.",
"title": "Fonctions",
"type": "object"
},
"index": {
"description": "LE seul champ d'adressage. Tout en derive ; P20 refuse d'en stocker un autre.",
"maximum": 255,
"minimum": 0,
"title": "Index (seed)",
"type": "integer"
},
"reservations": {
"additionalProperties": {
"additionalProperties": false,
"properties": {
"passerelle": {
"description": "Dernier octet de la passerelle. P23 refuse un SVI qui s'en ecarte.",
"title": "Passerelle",
"type": "integer"
},
"reserve_max": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Réserve (max)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "integer"
},
"reserve_min": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Réserve (min)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "integer"
}
},
"type": "object"
},
"description": "Adresses soustraites a la derivation dans chaque zone.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Réservations",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "object"
}
},
"required": [
"index"
],
"type": "object"
},
"title": "Nomenclature",
"x-fichier": "plan/nomenclature.yml",
"x-racine": null
},
"serveurs": {
"entite": {
"additionalProperties": false,
"properties": {
"coeurs": {
"description": "Vide = derive des empreintes des roles.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Cœurs",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "integer"
},
"disque": {
"description": "Ex. `32G`. Vide = derive des empreintes des roles.",
"title": "Disque",
"type": "string"
},
"etat": {
"description": "`planifie` = decrit mais pas deploye ; `actif` = joignable par Ansible.",
"enum": [
"actif",
"planifie"
],
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "État",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"fonction": {
"description": "Determine VMID, IP, VLAN et passerelle. Doit exister dans la nomenclature.",
"title": "Fonction",
"type": "string",
"x-source-valeurs": "nomenclature.fonctions"
},
"integrations": {
"description": "Seulement les facultatives. Les universelles viennent du role et sont refusees ici.",
"items": {
"type": "string"
},
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Intégrations facultatives",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "array"
},
"memoire": {
"description": "Vide = derive des empreintes des roles.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Mémoire (Mo)",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "integer"
},
"noeud": {
"description": "Surcharge le defaut de `make config`.",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Nœud Proxmox",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string"
},
"stockage": {
"description": "Surcharge le defaut.",
"title": "Stockage",
"type": "string"
}
},
"required": [
"fonction"
],
"type": "object"
},
"title": "Serveurs (VM)",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"x-clef": {
"description": "Le nom court de la VM. Le rang final derive l'adresse.",
"title": "Nom d'hôte"
},
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"x-fichier": "plan/serveurs.yml",
"x-racine": "serveurs"
},
"serveurs_bd": {
"entite": {
"additionalProperties": false,
"properties": {
"groupe": {
"title": "Groupe",
"type": "string",
"x-source-valeurs": "groupes_operationnels"
},
"hote": {
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"title": "Hôte",
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"type": "string",
"x-source-valeurs": "serveurs"
},
"port": {
"title": "Port",
"type": "integer"
},
"type": {
"title": "Moteur",
"type": "string"
}
},
"required": [
"hote",
"type"
],
"type": "object"
},
"title": "Serveurs de bases de donnees",
GUI : le formulaire des bases est GENERE depuis le schema Etape 3, sur un seul registre — `bases_donnees`, le plus simple et le seul ou observe et editable coincidaient deja. Les cinq autres gardent leurs formulaires ecrits a la main : on ne bascule pas six vues d un coup. CE QUI DISPARAIT DU JAVASCRIPT Huit `<label>` en dur, trois constructions de `<option>`, et la regle qui choisissait la source du consommateur selon la portee. Cette derniere ne vivait que dans le JS ; elle est desormais DECLAREE au schema (`x-source-selon`), donc lisible et gardee. Le formulaire rend exactement les memes huit champs qu avant — verifie en EXECUTANT le moteur sous node avec le schema et des donnees reelles, pas seulement en passant `node --check`. LA BOUCLE EST FERMEE DES DEUX COTES Le chemin de SAUVEGARDE enumerait lui aussi les sept champs en dur. Un champ ajoute au registre serait apparu au formulaire genere et aurait disparu SILENCIEUSEMENT a l enregistrement — le pire des deux mondes. Il derive maintenant du schema, valeurs par defaut comprises (`default`). LA SEPARATION FORME / COHERENCE, MONTREE portee=groupe + consommateur APPLICATION -> REFUSE par valider_bases portee=application + consommateur app -> ACCEPTE secret absent -> REFUSE Le schema a rempli la FORME (les defauts `groupe` et `principale` se sont poses), le validateur a attrape l INCOHERENCE. Aucune de ces trois regles ne s exprime en JSON Schema, et vouloir l y mettre creerait la seconde source de verite que ce depot refuse. CHAMPS_ECRITS_PAR_GUI COMMENCE A DISPARAITRE Renomme CHAMPS_ECRITS_A_LA_MAIN, et `bases_donnees` en est SORTIE : sa couverture se derive du schema. P19 lit desormais `champs_ecrits_par_gui()`, qui reunit les deux. Le jour ou la table sera vide, elle gardera un mecanisme au lieu d une liste. UNE GARDE A CORRIGER AU PASSAGE `declaration_derive()` verifiait que chaque champ declare apparait dans le SOURCE du GUI. Pour un registre genere il n y apparait plus — c est le but. Elle aurait crie sur precisement le progres qu elle devait constater. Les registres generes en sont exemptes : c est P61 qui tient la promesse pour eux. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. P07 (node --check), P19 (couverture), P61 (schema) : verts. Reste : les cinq autres vues, et le trou de la nomenclature — que le passage au generateur fermera par construction, puisque le schema decrit deja `categorie` et `service`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:30:08 -04:00
"x-clef": {
"description": "Nom du serveur de bases, ex. `pg-principal`.",
"title": "Nom"
},
schema du plan : la forme des registres devient derivee, et gardee Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-08 15:19:20 -04:00
"x-fichier": "plan/bases-donnees.yml",
"x-racine": "serveurs_bd"
}
},
"title": "Registres du plan Set-OPS"
}
Reference in a new issue Copy permalink