La classification

Les deux axes sont indépendants et l'Event les porte côte à côte — mais le canon de l'axe 1 n'est tenu qu'en Python : son miroir JS, chargé en production, compte 1·2·3·4·5·7·8·9 et ignore S6 ; et la classification des mémoires nomme des compartiments que rien ne persiste, pendant que le seul compartiment qui EST une colonne en base n'a aucune porte.

• ⚑ CE QUI TOMBE : le BATI « Miroir JS de l'axe 1 » devient ABSENT. frontend/js/arbre-spheres.js:292-472 ne liste pas S6 (grep -c divertissement = 0) et compte S9 comme branche : sphereId 1,2,3,4,5,7,8,9. C'est la composition « S1-S5 + S7-S9 » que CLAUDE.md et arbre_canon.py déclarent NON RÉ-ARBITRABLE. Le fichier est chargé en production (governance-init.js:672) et rien ne le garde : scripts/audit_s9_s6_packaging_axis.py n'est PAS dans ci.yml et ne vérifie que des phrases de tronc obsolètes et les renderers. Les 12 épreuves vertes tiennent le Python ; la moitié JS du canon n'a pas de juge.
• ⚑ DEUXIÈME CHUTE : « L'autre compartiment, celui qui EST une colonne » reste PARTIEL faute de porte. La colonne memory_compartment existe (v82_268:97,103 — dans la PRIMARY KEY — et v82_279:74) et l'autorité est vraiment fail-close (acmi_memory_authority.py:111-113). Mais authorize n'est appelée que par issue_remember_capability (:242) et verify_remember_capability (:298), et ces deux-là ont ZÉRO appelant dans tout backend/ hors leur fichier. La seule porte HTTP, /api/v2/acmi/remember (acmi_router.py:517-536), lève 503 `acmi_capability_consumption_not_atomic` AVANT d'y toucher — un refus honnête, mais un refus. Le compartiment en base est bâti et muré.
• ⚑ TROISIÈME : les portes du compartiment en mémoire. Porte 1 (compartment.py:117) — `observer_scope != compartment.scope AND not compartment.bridged_compartments` : UN pont, vers N'IMPORTE QUEL partenaire, désarme le test de portée pour TOUS les observateurs. Porte 4 (:136-139) — bridge_compartments (:175-176) écrase le statut à BRIDGED sans le lire, donc ponter un compartiment en quarantaine lève sa quarantaine en silence.
• Le compte des portes : « 4 gates » annoncé dans la docstring de can_access_compartment, mesuré = 2 inconditionnelles (scope, canon_level) + 2 conditionnelles. La porte 3 (dimensions, :130 `if observer_dimensions:`) a pour défaut None — elle est SAUTÉE par défaut.
• `consolidate_memory` (hierarchy.py:133) rend `"consolidated": True` sans écrire nulle part. C'est la fabrique de défauts que CLAUDE.md nomme : un « créé » qui n'a rien créé. Même famille : `route_memory_to_tier` (:100) rend `backend_hint`, une chaîne qui NOMME un backend sans l'ouvrir.
• Le registre des compartiments canon est un dict de module (canon_compartment_router.py:41) et /health (:142) est OUVERT, sans auth, et annonce `p0_status: "operational"` + `compartments_count`. En prod à 4 workers, chaque worker a son propre dict : un compartiment créé sur l'un est 404 sur les trois autres. Le fichier le dit lui-même (« Stockage in-process (P0) ») — mais sa première page dit « operational ».
• JE ME SUIS TROMPÉ UNE FOIS, et le piège vaut d'être nommé : j'ai d'abord conclu que les endpoints compartiment n'avaient pas d'auth, parce que `get_current_user` n'apparaît pas dans leurs SIGNATURES. Elle y est, en `dependencies=[Depends(get_current_user)]` sur le décorateur (:74, :94, :118, :134). Chercher Depends dans une signature ne voit pas une dépendance de décorateur.
• Même famille de piège inversé : `_VALID_SPHERES` (event_bus.py:297) EST utilisée (:347, :354). Un balayage « constante déclarée sans usage » l'aurait comptée morte.
• LA PLANCHE ELLE-MÊME N'EST PAS AU COMMIT : frontend/planches/planche-8-classification.svg existe sur le disque (78 758 octets, horodatée 2026-10-03 09:50) et `git status --porcelain` la rend `??` — non suivie, `git log` sur ce chemin rend zéro commit. Mesure faite dans l'arbre de travail, pas dans le commit.
• CHAÎNE ALEMBIC À 4 TÊTES au commit a09f620b2 (304 révisions) : v82_042_stone_decoder_tables, v82_046_stigmergy_trails_db_first, v82_258_embeddings_source_path_index, v82_299_scope_membership_node_kind. `alembic upgrade head` refuserait (Multiple heads). Les deux migrations qui portent memory_compartment (v82_268, v82_279) vivent sur cette chaîne branchée.
• PROD : NON ÉTABLI, et je le dis au lieu de deviner. La dernière révision NOMMÉE est v82_260_atom_positions sur atom-db/atom_db (conteneur compose-atom-db-1), mesurée le 2026-08-08 et consignée dans CLAUDE.md. v82_268 et v82_279 lui sont POSTÉRIEURES — donc absentes à cette date. Je n'ai pas interrogé la prod (lecture seule) : l'état d'aujourd'hui n'est pas mesuré.
• Chiffres CONFIRMÉS dans le code au commit : 34 libellés = 16 opérationnelle + 11 données + 7 sectorielle · 16 canaux (énumérés un à un) · 12 épreuves arbre_canon · 7 tiers MemoryTier · 3 faces · 7 topics exacts fail-close · 22 préfixes privilégiés.
• Chiffre NON RE-MESURÉ : le job CI canon-tests annonce « 686 épreuves » (ci.yml:473). Je n'ai confirmé que les 12 de test_arbre_canon.py. Le 686 reste NON ÉTABLI ici.
• Dérive de renvoi mineure mais réelle : arbre_canon.py:27 renvoie à `tests/test_arbre_canon.py` ; le fichier est à hf-atom-tools/atom_canon/tests/test_arbre_canon.py. Le renvoi est mort, la doctrine non.
• Ce qui TIENT, et qu'il faut dessiner comme tenant : l'orthogonalité (event_bus.py:91-95 + deux résolveurs indépendants), le refus du canal en trois gestes (:467-470), le repli nommé de la sphère avec status=red (:445-461), le clamp η réellement appliqué (babel_macro_decoder.py:621-622, :672-673), les 3 faces et les 34 libellés, les 12 épreuves de l'arbre, et le fail-close de l'ACL sur les 7 topics exacts (event_bus.py:510-528).
• PÉRIMÈTRE DE MES « ZÉRO APPELANT » : git show HEAD:… (le commit a09f620b2), sur les DEUX arbres sous backend/ (backend/app/ ET les ~278 .py hors app/) + hf-atom-tools/, hors backend/tests/ et hors hf-atom-tools/atom_canon/tests/, hors .claude/worktrees/.

La planche ne doit PAS dessiner l'axe 1 comme un canon à deux moitiés accordées : écrire explicitement que la moitié JS, celle qui est chargée dans le navigateur en production, compte 1·2·3·4·5·7·8·9 et ignore S6, et qu'aucune garde ne la tient. Elle ne doit PAS dessiner une mémoire compartimentée : deux registres en mémoire de processus qui ne se voient pas, un « consolidé: true » qui n'écrit rien, un backend_hint qui ne branche rien, et la seule colonne memory_compartment réellement en base derrière une porte qui lève 503 inconditionnellement. Elle ne doit PAS dessiner quatre portes d'accès égales : deux sont conditionnelles, la porte SCOPE se désarme sur un pont quelconque, et la quarantaine se lève par pontage. Elle ne doit PAS dire « polysémie assumée » : rien ne réconcilie 'eta_stricte' et {S1..S4} — c'est une homonymie non réconciliée. Elle ne doit PAS dessiner l'ACL du bus comme une compartimentation des topics : 7 topics exacts mordent, les 22 préfixes attendent une variable absente du déploiement. Et elle doit porter, en clair, que la prod n'a pas été mesurée aujourd'hui et que la dernière révision nommée est v82_260 sur atom-db/atom_db au 2026-08-08.

ne pas dessiner

• Les 7 planches cosmogrammes existantes (frontend/planches/planche-1 à planche-7 : QG, poumons, Metatron, grille 27, urbanisme, contenu, anatomie des lieux)
• Les planches techniques déjà faites : bilatéral, respiration, layers/scopes, portes-fenêtres, meshmap, emboîtement, étoile-semence
• Les planches institutionnelles : économie, armure, politique, institutions, entreprise
• La grille 27+0 et l'arithmétique 8+1=9 × 3 portées — déjà portée par planche-4-grille-27.svg ; ici n'en garder que la composition des branches, sous l'angle de la divergence Python↔JS
• Le détail des 39 topics babel.* et des 235 topics backend — c'est le catalogue, pas la classification
• L'axe des domaines (COFOG) et les 14 lieux civiques — autres planches
• Les 4 cardinaux / la quaternité cardinale (gabarit ORCHESTRATOR_GUIDE) — déjà tenue par scripts/audit_quaternite_cardinale.py et hors de l'axe des données

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.