L’armure 15D

L'armure n'est pas l'organe le plus durci du dépôt : c'est un organe DURCI MAIS DÉBRANCHÉ — son pont frontend→backend ne peut pas se déclencher (trois ruptures indépendantes), sa garde de signature n'a aucun appelant, son régime v2 keyé n'existe qu'en test, et son unique sortie vers l'économie se déclare elle-même inactive ; ce qui tient vraiment, c'est le refus : le registre fail-close et la contrainte de base qui interdit à l'armure d'être autoritative.

• ⚑ LA RÉFUTATION PRINCIPALE, en une phrase : la vague annonçait sept pièces BÂTIES ; au commit 8addf1c94, DEUX seulement le restent (le registre durable et la contrainte de base), deux passent à PARTIEL (le schéma, la trajectoire), une à PARTIEL par son producteur (l'exposition de menace), une à PARTIEL par son régime (l'engagement : v1 seul vit), et le PONT — la pièce dont dépendent toutes les autres — passe à ABSENT.
• ⚑ TROIS RUPTURES INDÉPENDANTES sur le même pont, chacune suffisante à elle seule : un champ absent du contrat de bus (`tokenId`), une fonction d'entrée sans appelant (`updatePoint0`), et un endpoint de mint qui lève 503 inconditionnellement. Les réparer une à une ne réveille rien ; il faut les trois. C'est le genre de panne que seul un parcours de bout en bout révèle — aucun des deux côtés n'est en faute isolément.
• ⚑ UN GABARIT MENTEUR, À L'INVERSE DE D'HABITUDE : l'en-tête d'`armure_sentinel.py:6-8` annonce « Ici la garde devient vivante » pour corriger un défaut nommé (« `snapshot_matches` n'avait AUCUN appel runtime »). Le fichier a été écrit, le branchement non. Le défaut est donc intact — mais désormais couvert par une phrase qui dit l'avoir réparé. C'est pire que le défaut nu.
• ⚑ TROIS FICHES DE CONSEIL AFFIRMENT UN APPEL QUI N'EXISTE PAS : conseil_3.json:89, conseil_6.json:54 et conseil_9.json:58 (data/urbanisme/projets-services/protocol-999-protocole-de-resistance/) écrivent « `armure_sentinel.guard` appelée depuis `armure.py:96-100` », et conseil_3 en fait « le seul espace de ce lieu à la fois bâti, appelé et monté ». Les lignes 96-100 d'armure.py ne contiennent pas cet appel ; `guard` n'a aucun appelant. Trois conseils ont convergé sur la même erreur — probablement en se citant.
• CHIFFRES DE DOCS QUI NE PASSENT PLUS : `frontend/etat-technique.html:130,502,512` et `docs/cartographie-proprietaire.json:1557-1559` annoncent « armure.py, 166 lignes » (c'est 208 au commit), « monté à main.py:1491 » (c'est 1957), « le pont frontend→backend fonctionne de bout en bout » (il ne part jamais) et « `armure_store` retient → `aip_signing` estampe » (plus personne n'écrit le store). À noter : etat-technique.html:130 contient aussi, dans la MÊME page, le constat juste — « Le ROUTEUR tient, le PONT ne tient pas ». La page se contredit par ses deux bouts ; le bout juste est celui-là.
• CE QUE LA THÈSE D'ORIGINE AVAIT RAISON DE DIRE, et que je confirme pièce en main : les quinze dimensions dérivent bien d'UN SEUL scalaire — `FractalExpansion.js:188-196` pondère `harmony` par φ (`Math.pow(PHI_INV, (DIMENSIONS - d) / DIMENSIONS)`) pour fabriquer quinze forces. Et la fréquence EST jetée à la frontière Python : `fractal_dimensions.py:60-68` (`commitment_vector`) ne retient que `strength`, écartant explicitement fréquence et cohérence comme « dérivables ». Quinze fentes, une mesure — c'est exact.
• CE QUI TIENT VRAIMENT, ET QU'IL NE FAUT PAS DÉGRADER EN LE REDESSINANT : le registre (verrou advisory, rejeu à deux refus distincts, commit avant retour, 503 nommé) et la contrainte `ck_armure_observation_non_authoritative_class`. C'est la doctrine « fail-close sur ce qui engage » appliquée correctement. Le reste du domaine est un refus honnête (aip_signing) ou un organe débranché — jamais une fausse confirmation. Sur ce point précis, l'armure est exemplaire : elle n'a jamais menti en répondant « créé » ; elle s'est tue.
• DÉCISION QUI ATTEND JONATHAN — nº1 : réveiller le pont, ou l'assumer dormant ? Le geste minimal est de trois lignes (ajouter `tokenId` au payload de mint OU assouplir la garde FractalExpansion.js:882, et donner un appelant à `updatePoint0`) — mais il ouvre un robinet d'écritures en base derrière une identité, sur un mint actuellement fail-close par décision. Ne pas le faire sans trancher le mint d'abord.
• DÉCISION nº2 : la custody de la clé v2. Le code HMAC est bien écrit (séparation de domaine armure_15d.py:89-90, sous-clé dérivée pour l'aveuglement l.161, `hmac.compare_digest` l.237, refus des clés < 16 octets l.103). Il attend UNE décision : qui détient la clé par membre, et comment elle tourne. Tant qu'elle n'est pas prise, le dépôt scelle en SHA-256 nu — c'est-à-dire en valeur recomposable par quiconque connaît les identifiants publics.
• DÉCISION nº3 : trancher les trois tables de 15. La plus dangereuse des trois dérives parce qu'elle est SILENCIEUSE et que le troisième vocabulaire (dimensional-armor.js) est CHARGÉ en production. Coût faible aujourd'hui : faire importer `dimensions_15.py` par `antenna.py` (recopie identique, migration triviale) et nommer autrement les quinze de `spiderweb.py` et de `dimensional-armor.js`, qui ne sont pas les mêmes objets.
• DÉCISION nº4 : les trois lecteurs orphelins d'`armure_store`. Le store a été correctement déclassé, mais `verite.py:731-741` en tire une cote d'identité permanente « absente » pour tout usager, et `passage_decision.ArmureStorePort` reste un port qui lit un dictionnaire de processus. Il faut soit les repointer sur le registre durable, soit les retirer. Attention au piège que le code nomme lui-même (passage_decision.py:1221-1223) : NE PAS se contenter de changer l'étiquette `MEMOIRE` en `DURABLE`.
• PIÈGE POUR LA PROCHAINE SESSION : `verify_chain` est écrite, testée et bonne. La tentation sera de l'appeler depuis le routeur pour « compléter la trajectoire ». Mais rien ne LIT les versions historiques (`aget_current_owner_observation` ne rend que la tête) — il faudrait d'abord un lecteur de la suite ordonnée. Brancher `verify_chain` sur une liste vide rendrait `{valid: True, length: 0}` : une planche verte sur un organe non mesuré.

Ce que cette collecte N'A PAS pu voir. (1) AUCUNE BASE, AUCUNE PROD : lecture seule, par consigne. Donc NON ÉTABLI — que la migration v82_293 soit appliquée sur le VPS (CLAUDE.md mesure la prod au 2026-08-08 à `v82_260_atom_positions`, soit 33 révisions en retard de la table d'observations d'armure) ; que la table `armure_owner_observation_versions` contienne ne serait-ce qu'une ligne ; qu'un `identities.id` existe pour un usager authentifié (la FK `fk_armure_observation_owner` restreint sur `identities`, et un usager absent de cette table ferait échouer l'insertion en 503 — c'est la même famille de défaut que le `owner_principal_id` corrigé au commit dfcb8a3ec, mais je ne l'ai PAS vérifiée). (2) AUCUN SERVEUR LANCÉ, AUCUN NAVIGATEUR : je n'ai pas chargé une page, donc l'enchaînement « module chargé → bus → POST » est établi par LECTURE DE CODE, pas par observation. Un script inline d'une page HTML particulière pourrait appeler `ATOMArmureBridge.pushDimensions` ou `updatePoint0` d'une façon que mes motifs de recherche ont manquée — j'ai cherché `ATOMArmureBridge`, `pushDimensions`, `refinePoint0`, `updatePoint0`, `.aspirate(`, `.breathe(` et `FractalExpansion` sur frontend/ et agents/, et n'ai trouvé que des tests ; je n'ai pas lu les 122 pages HTML une à une. (3) AUCUN TEST LANCÉ : je n'ai exécuté aucune garde, aucun banc. Toute mention de test dans ce rendu décrit un FICHIER LU, jamais une sortie verte. (4) PÉRIMÈTRE DES « ZÉRO APPELANT » : chaque « 0 appelant » de ce rendu a été mesuré par `git grep` sur l'ARBRE SUIVI PAR GIT, au commit 8addf1c94, en excluant `backend/tests/`, `**/__tests__/**`, `docs/`, `leaves/`, `leaf-flows/` et `frontend/etat-technique.html` — et en INCLUANT les deux arbres de `backend/` (`backend/app/`, 1 627 fichiers, et les ~278 `.py` hors `app/` sur 29 racines), plus `frontend/`, `agents/`, `hf-atom-tools/`, `scripts/`. `archives/` et `transit/` sont exclus comme code de référence non actif. (5) LE COMMIT, PAS L'ARBRE : tous les chiffres et toutes les lignes citées viennent de `git show HEAD:<fichier>`. L'arbre de travail porte 60+ fichiers modifiés non commités (dont `main.py`) : une mesure sur l'arbre pourrait différer. (6) LES 12 `backend/verticals/` ACTIFS sont des bytecode-squatters non versionnés, donc invisibles à `git grep` : si un appelant d'armure y vit, je ne l'ai pas vu. (7) LES BUNDLES CODEX ET LES WORKTREES hors dépôt n'ont pas été fouillés.

ne pas dessiner

• NE PAS dessiner l'armure comme un CHIFFREMENT ni comme un BOUCLIER. C'est un engagement (hash) sur des attaches d'identité ; rien n'est déchiffrable, rien ne bloque. Le code le dit deux fois : armure_15d.py:137-141 (« v2 N'ATTEINT PAS prouver-sans-révéler ») et armure_sentinel.py:15-17 (« ON EXPOSE, ON NE FRAPPE PAS »).
• NE PAS dessiner une arête armure→économie. Elle n'existe pas : le seul pont se déclare inactif et n'est chargé par aucune page (armor-economy-bridge.js:6-11). Les multiplicateurs ×1.0 à ×5.0 et les « 30 UR/jour » de son en-tête sont de la doctrine résiduelle dans un module mort — les reproduire sur une planche leur donnerait une existence qu'ils n'ont pas.
• NE PAS dessiner le pont et le registre du MÊME TRAIT. Le registre est bâti et fail-close ; le pont qui devrait l'alimenter ne peut pas partir. Les montrer semblables serait exactement le mensonge que la devise interdit.
• NE PAS dessiner « v1/v2 » comme deux régimes disponibles. Un seul vit (v1 nu). Le v2 est du code correct sans porteur de clé — si on le dessine, il faut l'ombrer et nommer la décision de custody qui manque.
• NE PAS redessiner les 7 cosmogrammes existants (frontend/planches/*.svg), ni le plan VISION de docs/presentation/CARTE-CONTENU-grand-cosmogramme.md.
• NE PAS dessiner un verdict sur la production. Aucune base n'a été interrogée dans cette collecte : la table d'observations peut exister ou non sur le VPS, et je n'en sais rien.
• NE PAS dessiner « 15 dimensions » au singulier. Il y en a trois tables qui ne se parlent pas, dont deux vivantes côte à côte en production (dimensions_15.py et dimensional-armor.js). Une planche honnête montre TROIS tables et l'absence de pont entre elles.

On ne remplace pas le nom canon, on le double : le terme reste l’autorité, la glose est une poignée. Le lexique entier est sur sa propre page.