L’emboîtement fractal

Les deux bouts sont bâtis — 7 sorties fermées et gardées au serveur, 6 moteurs et 6 afficheurs au client — mais le MILIEU n'existe que sur UNE page : le seul choisisseur de sortie n'est dans aucun des deux tableaux du chargeur central, l'attestation de l'appareil arrive au noyau APRÈS que la branche de compilation soit déjà choisie, et les deux moitiés du joint appareil→assemblage ne se rencontrent sur AUCUNE page.

• ⚑ LA CORRECTION PRINCIPALE — « LE JOINT appareil → assemblage, BÂTI DE BOUT EN BOUT » est FAUX, et de deux façons indépendantes. (1) Les deux moitiés clientes ne coexistent sur AUCUNE page : `device-master.js` n'est chargé que par l'entrée `'institutions'` de SPHERE_MODULE_MAP (governance-init.js:95) ; `view-mode-manager.js` n'est dans aucun des deux tableaux `scripts` et n'arrive que par balise directe sur desktop.html, meshmap.html, simulation-dashboard.html. Intersection = 0. (2) Là où le plafond atteint bien un organe chargé — le noyau lui-même — il arrive à la ligne 1326, soit APRÈS le `if/else` de la ligne 1286 qui a déjà choisi le moteur : le noyau ANNOTE la requête et son propre commentaire l'avoue (« Le plafond qualifie seulement la lecture graphique »).
• ⚑ LE PIÈGE QUI M'A PRESQUE FAIT DIRE LE CONTRAIRE : `grep -c view-mode-manager governance-init.js` rend 2, et on croit le module chargé. Les deux occurrences sont (a) un commentaire à la ligne 667 et (b) la ligne 1389, DANS `TIER3_PATTERNS` — une liste de noms qui ne CHARGE rien : `matchesTier` (:1433-1436) dérive le nom d'un script déjà présent dans le tableau pour le classer en étage 3. Même piège pour `atom-meshmap` (:1320) et `env-customizer`. ⛔ Ne jamais conclure « chargé » d'un nom trouvé dans governance-init : il faut la chaîne `'/js/<nom>.js'` DANS un des deux tableaux `scripts` (bornes : :232-1078 FULL, :1079-1200 LIGHT, plus SPHERE_MODULE_MAP :71-138 et PAGE_MODULE_MAP :139-224 qui sont page-conditionnels).
• ⚑ LE CHIFFRE « 166 PAGES » N'EST PAS REPRODUCTIBLE. Mes mesures, avec leurs règles : 215 fichiers .html suivis par git sous frontend/ (`git ls-files 'frontend/*.html' | wc -l`) ; 109 chargent governance-init.js ; 27 sont des GOVERNANCE_PAGES et reçoivent le tableau FULL (governance-init.js:51-65). Les 82 autres reçoivent le tableau nommé « LIGHTWEIGHT » — qui, malgré son commentaire « ~15 scripts instead of ~130 », en contient plus de cent, dont le noyau de projection. Ce commentaire est lui-même une dérive à signaler.
• ⚑ J'AI DÛ CORRIGER LA FICHE DANS L'AUTRE SENS AUSSI : « compileVillage2D / compileXR — zéro demandeur » est trop fort. Le select du panneau studio offre bel et bien `2d` et `xr` (atom-projection-studio.js:1278-1280) et ces valeurs traversent `_resolveMedium` jusqu'au noyau. La vérité exacte : 0 demandeur en CODE, 1 demandeur par geste humain, sur la SEULE page qui porte `#projection-studio-root` (frontend/design-center.html). Et pour `xr` c'est pire que l'absence : design-center est une page LIGHT, donc `xr-layer.js` (tableau FULL seul, governance-init.js:913) n'y est pas — on peut y demander une sortie XR que rien n'affiche.
• ⚑ `compileText` : la fiche avait raison, mais pas pour la raison annoncée. La thèse disait « aucun des 17 types ne peut atteindre la sortie text » — or 8 des 17 types DÉCLARENT `text` (mobile, ar_headset, station, baton_360, glasses, xr_headset, console, watch — re-mesuré par appel). Le vrai verrou est un ORDRE : `_deviceMediumCeiling` teste `outputs.includes('2d')` (view-mode-manager.js:951) avant `outputs.includes('text')` (:958), et AUCUN des 8 types ne porte `text` sans porter `2d` (re-mesuré : liste vide). La ligne `return 'text'`, écrite le 2026-09-30 avec un long commentaire qui la justifie, est morte à la naissance pour les 17 types.
• ⚑ ET SON COMMENTAIRE SE TROMPE DE COMPTE : governance-init.js:476 et view-mode-manager.js:952 annoncent « text pour SEPT familles d'appareils sur huit ». Il y a 7 familles de runtime au total (RuntimeFamily, device_taxonomy.py:23-31), pas 8 ; et 6 d'entre elles portent `text` — robot est la seule qui n'en porte pas. Un commentaire qui dit « 7 sur 8 » là où le code dit « 6 sur 7 » fabrique une fausse assurance sur l'organe le plus fragile de la chaîne.
• ⚑ LA DOUBLE SOURCE DU VOCABULAIRE CANON : `trinity_geo_router.py:53-58` importe `RenderLayer` dans un `try/except Exception` dont le repli est un CLONE LITTÉRAL des sept valeurs. J'ai vérifié que l'import RÉUSSIT (backend/.venv-tests → 7 valeurs identiques) et que le Dockerfile installe bien le paquet (`backend/Dockerfile:43-44`, `pip install -e /opt/hf-atom-tools`). Mais AUCUN test ne compare `device_taxonomy.RENDER_OUTPUTS` à `RenderLayer` : trois copies des sept valeurs peuvent diverger sans qu'une garde bronche. C'est un gisement, pas encore un défaut.
• ⚑ `render_layer` par nœud : je ne reproduis pas « 13 valeurs ». Sous ma règle (`git grep -ohE "render_layer[\"']?\s*[:=]\s*[\"'][A-Za-z0-9_.-]+[\"']" -- backend frontend/js hf-atom-tools agents`, hors __tests__) j'en compte 12 distinctes. Le nombre dépend entièrement de la forme cherchée, donc il ne doit JAMAIS voyager sans sa règle. Ce qui est solide et indépendant du compte : 8 de ces valeurs sortent des 7 sorties canon, et la colonne (world_canon_projection.py:57) est un `Text` sans enum ni CheckConstraint.
• ⚑ « MONTÉ DANS main.py » N'EST PAS UNE MESURE. `register_router` avale l'`ImportError` sauf si `core=True` ou `REGISTER_ROUTER_STRICT` — et aucun des 5 routeurs de cette planche n'est `core`. J'ai donc re-mesuré autrement : import réel dans `backend/.venv-tests` → les 5 importent, avec 10/9/10/6/6 routes. ⚠ C'est l'interpréteur LOCAL, pas le conteneur de production : je n'ai pas interrogé la prod.
• ⚑ LA PORTE REST DE LA FRACTALE COMMUNAUTAIRE EST UNE SURFACE SANS CLIENT. 6 routes, importables, montées — et 0 appelant dans le dépôt hors docs et scripts de déploiement. Un conseil antérieur l'avait déjà mesuré (data/urbanisme/projets-services/.../conseil_3.json:86 : « personne ne s'y présente ») ; je le confirme indépendamment. Je dégrade donc BATI → PARTIEL : la porte est atteignable, la chaîne est coupée.
• ⚑ LE MODULE QUI PORTE LE NOM NE FAIT PAS LA CHOSE. `frontend/js/fractal-nested-windows.js` est chargé par les DEUX tableaux (governance-init.js:485, :1172) et son nom promet l'emboîtement fenêtre-dans-fenêtre. Son en-tête (:3-7) dit la vérité : 3 niveaux FIXES (L1 tronc / L2 feuille / L3 flux), lisant /api/v2/fractal-code. Aucune récursion. On pourrait croire la primitive rachetée côté client : elle ne l'est pas.
• ARBITRAGE QUI ATTEND JONATHAN nº1 — où doit vivre le choisisseur ? Deux options exclusives, et le code porte déjà les deux moitiés : (a) charger `view-mode-manager.js` dans les deux tableaux et charger `device-master.js` hors de la seule page institutions — le joint se ferme, mais 1114 modules héritent d'un choisisseur actif ; (b) déplacer la décision DANS le noyau (qui lit déjà le plafond à :92-113) et faire du ViewModeManager un simple lecteur. ⛔ Ne pas trancher cela dans une planche : la planche doit MONTRER les deux moitiés et le vide entre elles.
• ARBITRAGE nº2 — `meshmap` est le défaut du noyau et n'est PAS une sortie canon. Soit on l'ajoute aux 7 (et les 4 vocabulaires doivent bouger ensemble), soit le `else` de la ligne 1303 doit REFUSER au lieu de glisser. Aujourd'hui le système a un défaut silencieux qui porte un nom hors canon.
• ARBITRAGE nº3 — `dom` comme dernier barreau du repli (view-mode-manager.js:314) sort du vocabulaire et n'affiche pas le monde. Et ces 4 marches sont FIGÉES par un test (commentaire :975-977) : c'est exactement le cas « un test qui fige une dérive reste vert ». Corriger l'échelle demandera de toucher au banc.
• CE QUE LA PLANCHE DOIT FAIRE VOIR, GRAPHIQUEMENT : ne pas dessiner les 7 sorties, les 6 moteurs et les 6 afficheurs du MÊME trait. Les deux bouts sont pleins ; le milieu est une bande vide traversée par trois fils seulement — et deux de ces trois fils n'existent que sur une seule page. Le trait du choisisseur doit être pointillé et porter « 0 / 109 pages par le chargeur central ».

Ce que cette collecte N'A PAS pu voir. (1) LE RUNTIME : tout est mesuré sur le commit 8addf1c9481559a8e9dbc97b1fc0bcc85e10a0e1 et sur l'arbre de travail, jamais sur un navigateur ouvert. Je n'ai chargé aucune page, donc je n'ai pas vu un seul `window.ViewModeManager` réel, aucun appel HTTP, aucune projection compilée. « Chargé » signifie ici « présent dans un tableau de scripts ou une balise <script> », pas « exécuté sans erreur ». (2) LA PRODUCTION : je n'ai pas interrogé le VPS DigitalOcean (138.197.132.63) ni la base atom_db. Je ne sais donc pas combien d'appareils sont réellement enregistrés dans le registre, ni si `scope_membership` / `projection_nodes` contiennent une seule ligne, ni quels routeurs le processus prod a réellement montés (`register_router` avale l'ImportError, et les listes `_registered_ok` / `_registered_broken` ne vivent qu'en mémoire du processus). L'importabilité des 5 routeurs est mesurée dans backend/.venv-tests, en local. (3) LE DEUXIÈME ARBRE : mes grep ont bien couvert `backend/app/` ET les ~278 .py hors `app/` (le motif `-- backend` les prend tous les deux), mais je n'ai PAS fouillé `archives/`, `transit/` ni `AT-OM-999-DEPLOY-ZAMA-ALLELUYA/` — un appelant historique y vivrait sans que je le voie, et ce serait un appelant mort de toute façon. (4) LES BALISES DYNAMIQUES : je n'ai cherché les chargements que dans governance-init.js et dans les balises `<script src>` statiques des .html. Un module injecté par un autre chargeur JS (window-manager, module-orchestrator, un import dynamique) m'échapperait : mes comptes « 0 / N pages » sont donc des MINORANTS de chargement, et c'est dans ce sens-là qu'ils peuvent être faux. (5) LE COMPTE DES VALEURS `render_layer` dépend de la forme cherchée : ma règle ne voit que les littéraux `render_layer = \"x\"` / `render_layer: 'x'` ; une valeur construite, lue en base ou passée par variable n'y figure pas. (6) LES SORTIES `2.5d` ET `sonore` : je conclus ABSENT sur l'absence de moteur dans le noyau de projection ; je n'ai pas cherché un organe sonore ailleurs dans le dépôt (bioacoustic, audio_generation existent et n'ont pas été examinés pour cette question).

ne pas dessiner

• Les 27 cellules de la grille, l'urbanisme du village, le contenu du village, l'anatomie des lieux, les poumons, le Metatron et le QG — les 7 cosmogrammes existants (frontend/planches/*.svg, galerie frontend/planches-atelier.html) les portent déjà.
• La topologie 8 branches + tronc + sève. Elle est tranchée et scellée (CLAUDE.md §0, arbre_canon.py tenu par 12 tests) ; la reprendre ici rouvrirait un arbitrage fermé. Cette planche ne touche à l'arbre que par UN point : le registre S6_PACKAGING_LAYER et ses 14 renderers déclarés.
• Le vocabulaire étoile/pétale et le yin-yang des services : scellés par ADR le 2026-08-08 (« tout existe déjà »), hors sujet du joint appareil→sortie.
• La chaîne de position / point 0 / covenant. Elle touche cette planche en un seul endroit (le focus dérivé de nav-state qui écrase le medium choisi, atom-projection-studio.js:966-971) — ce seul trait suffit ; le reste a ses propres planches.
• Les 7 mondes et les 3 portées de trinity_geo. Ils partagent le même routeur que la garde des sorties, mais ce sont trois axes DIFFÉRENTS : les mêler sur une planche ferait croire que la sortie est une portée. Ne tirer de trinity_geo QUE le validateur `_sortie_connue`.
• Un schéma qui montrerait la chaîne complète comme fonctionnelle. Les deux bouts bâtis et le milieu vide doivent se distinguer au premier regard — trait plein / trait pointillé / absence de trait, et chaque pointillé annoté de son compte de pages.

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.