Les mémoires : séparer

La CLASSIFICATION est bâtie et vérifiable (2 axes orthogonaux, 34 libellés sur 3 faces, 16 canaux en énum fermée, 8 branches tenues par 12 épreuves) ; la COMPARTIMENTATION, elle, est bâtie du côté de l'ÉCRITURE et creuse du côté de la LECTURE — et la correction décisive est que les deux « portes à 5 » ne sont pas la même porte : celle des 5 DROITS mémoriels a bien un appelant de production, qui lui passe un tuple VIDE ; celle des 5 AXES a sept appelants applicatifs, mais son axe nº3 (womb_depth) n'est alimenté par AUCUN d'eux, et la seule fonction qui le dériverait de la rive durable a zéro appelant.

• ⚑ LES DEUX « PORTES À CINQ » NE SONT PAS LA MÊME PORTE, ET LA THÈSE LES A FUSIONNÉES. Il y a cinq DROITS mémoriels (read · write · propose_promotion · derive · purge — instance_passport.py:51) pesés par compartiment dans p0p2_admission_gate.py:507-517 ; et cinq AXES de membrane (localisation · identité · womb_depth · engagement · rôle — membrane_service.py:9-20) pesés par authorize_axes. La thèse disait « la porte des 5 droits n'a aucun appelant applicatif ». Mesuré : la porte des 5 DROITS a UN appelant de production qui lui passe `memory_access=()` (supervisor_p0p2_admission_gate.py:446) — appelée, mais avec rien à peser. La porte des 5 AXES a SEPT appelants applicatifs, dont un routeur enregistré (coquille_router, main.py:2342) — donc BÂTIE et atteinte. Deux défauts réels, deux formes différentes, et l'un n'excuse pas l'autre.
• ⚑ LE VRAI TROU QUE LA THÈSE A MANQUÉ : L'AXE Nº3 EST MORT DANS LES SEPT CHEMINS. J'ai ouvert les sept sites d'appel un par un. Cinq passent `engagement_level` (bureau_service.py:151, knowledge_gate/porte.py:210, mcp_carte_tools.py:76, mcp_live_organs.py:44, mcp_repo_tools.py:70). ZÉRO passe `womb_depth`. Il reste donc au défaut `0` (membrane_service.py:231) dans toute la production, et le seuil `womb_depth < required_womb_depth` (:352) ne peut jamais refuser. La fonction qui le remplirait depuis la rive durable — `aderive_womb_depth` (:493), avec sa règle nommée « un point = un couple DISTINCT (event_type, jour) » — a zéro appelant hors du module, comme `aauthorize` (:529) qui l'enveloppe. La membrane a cinq axes écrits et quatre axes vivants ; et celui qui manque est précisément celui du MÉRITE GESTATIONNEL, c'est-à-dire la doctrine entière de « l'information se mérite ».
• ⚑ CORRECTION DU POOL ACMI : CE N'EST PAS « LA MÊME LIGNE SANS JOINTURE », C'EST PIRE. La thèse annonçait les mémoires et les compartiments dans la même ligne. Mesuré : DEUX dictionnaires séparés sur le même objet — `self.local_memory` (canon_aware_memory_agent.py:121) et `self._compartments` (:130) — et `recall(fractal_address)` (:402-404) lit le premier sans jamais ouvrir le second. Le défaut n'est pas l'absence de jointure entre deux colonnes : c'est que le chemin de lecture et le registre d'isolement ne se rencontrent NULLE PART. L'unique endroit où les deux cohabitent vraiment est une photo durable : `acmi_agent_pool_records.local_memory` (JSONB, :25) à côté de `.compartments` (JSONB, :26) — et une photo ne garde rien.
• ⚑ LE MUR DE LA LECTURE N'EST PAS ABSENT : IL EST BINAIRE ET COLLECTIF. La thèse disait « pas de mur du côté de la lecture ». Précision mesurée : tout `/api/v2/acmi` est derrière `require_internal_token`, posé en dépendance de l'APIRouter entier (acmi_router.py:72-81). `/recall` n'est donc pas ouvert au public. Mais c'est UN secret partagé, pas un droit nommé : qui le porte rappelle la mémoire de n'importe quel agent à n'importe quelle adresse fractale. La différence compte, parce qu'on ne corrige pas un mur absent et un mur sans portes de la même façon.
• ⚑ LE « CHECK EN BASE » DE LA THÈSE N'EST PAS CELUI QU'ELLE CROYAIT. `memory_layer_events` n'a AUCUNE contrainte CHECK — `grep -i check` sur v82_086_memory_contract.py rend 0 ; la colonne `layer` n'a qu'un `DEFAULT 'hot'` (:31). La discipline hot/warm/cold vit uniquement en Python (memory.py:191). Les vrais CHECK de portée mémorielle sont ailleurs, et ils sont bons : `acmi_memory_deposits.scope IN ('indiv','commu','civ')` (models/acmi_memory_deposit.py:89-92) et `acmi_agent_pool_records.default_scope IN ('unknown','indiv','commu','civ')` (:32-35).
• ⚑ ET `memory_layer_events` N'A PAS DE PROPRIÉTAIRE. Aucune colonne d'usager dans la table ; `created_by` est rempli avec `thread_id` par la migration elle-même (v82_086:78). La propriété est reconstituée à la main, en Python, par un `SELECT owner_id FROM threads` (memory.py:658-661). Conséquence exacte : la séparation des mémoires de fil tient entièrement à ce que ces treize appels soient là. Ils y sont, 13/13 — mais rien dans la base ne les remplacerait si un quatorzième endpoint naissait sans son garde. Et c'est exactement ce qui s'est produit le 2026-08-06, consigné dans le code même (memory.py:600-612) : la porte gardée, six fenêtres nues, 200 sans jeton.
• ⚑ UN POINT OÙ LE DÉPÔT FAIT MIEUX QUE SA RÉPUTATION. Le womb écrit en FAIL-CLOSE réel : `db is None → 503` avec sa raison (womb.py:104-108), et le commentaire garde la trace du défaut corrigé — l'ancien repli rendait `status: ok` pour un événement qui disparaissait au redémarrage. Même honnêteté à la lecture : `/status` rend `source` et `degraded` (:200), et refuse de traiter « zéro événement » comme une panne (:191-196 — « Personne n'a rien fait n'est pas la base est tombée »). La mémoire de fil, elle, n'a PAS cette franchise : `_events_for_thread` (memory.py:580-594) sert un magasin local quand la base rend `None`, sans un champ pour le dire.
• ⚑ LA PHASE DU WOMB EST UNE DÉDUCTION, PAS UN ÉTAT. L'INSERT ne nomme que quatre colonnes — user_id, event_type, data, recorded_at (womb.py:119-120) ; le `phase` du modèle part dans le JSON `data` (_envelope, :75-84). Et `/status` rend `"phase": "active" if recent else "dormant"` (:199-201) : la gestation « active » signifie seulement qu'il existe des événements dans les dix derniers. Un champ annoncé n'est pas un chemin implémenté.
• ⚑ TROIS FAÇONS DONT L'ISOLEMENT MÉMORIEL CANON NE TIENT PAS, et aucune n'est un oubli de code — chacune est une décision visible. (1) Le demandeur déclare sa propre portée : `observer_scope` vient du corps de la requête (canon_compartment_router.py:58), pendant que `Depends(get_current_user)` (:92) authentifie sans jamais alimenter le verdict. (2) Le gate des dimensions ne se déclenche que si l'observateur en déclare : `if observer_dimensions:` (compartment.py:130) — ne rien déclarer le saute. (3) Un pont désarme la portée pour TOUT LE MONDE : `if observer_scope != compartment.scope and not compartment.bridged_compartments` (:117-121) teste si la liste de ponts est non vide, jamais si le demandeur est au bout d'un pont.
• ⚑ LES COMPARTIMENTS CANON N'ONT PAS DE TABLE. `_COMPARTMENTS` est un dict de module dans canon_compartment_router.py ; `self._compartments` un dict par agent (canon_aware_memory_agent.py:130). Créer, sceller ou mettre en quarantaine un compartiment est un geste qui ne survit pas au prochain déploiement — et le déploiement redémarre le backend en une minute. Les deux seules persistances de compartiment du dépôt portent d'autres noms : `instance_memory_grants.memory_compartment` (les droits) et `acmi_memory_deposits.memory_compartment` (les dépôts).
• ⚑ `civ` PAR DÉFAUT : CONFIRMÉ, MAIS IL FALLAIT DIRE OÙ. Le défaut est celui de la mémoire fractale BABEL — `DEFAULT_TREE_SCOPE = "civ"` (fractal_pipeline.py:94, fractal_dataseed.py:23, babel_macro_decoder.py:81), avec sa raison écrite à côté : « rétro-compatibilité V1 ». Ni la membrane ni le passeport ne font ça. Et le contre-exemple existe, bâti exprès : `acmi_agent_pool_records.default_scope` vaut `'unknown'` (:22, migration v82_280), jamais promu à la plus large. ⚠ Mais la divergence entre les deux CHECK n'est gardée par rien : le pool admet `unknown`, `acmi_memory_deposits` ne l'admet pas (3 valeurs contre 4). Un agent `unknown` sera refusé par la base, sans refus nommé pour le dire.
• ⚑ LE CHIFFRE « 13 COUCHES » N'EST PAS ÉTABLI, ET JE DIS POURQUOI. J'en ai vérifié ONZE, chacune située : womb_events · memory_layer_events · memory_layer_snapshots · PersistentDict(memory_events) · PersistentDict(memory_snapshots) · instance_memory_grants · acmi_memory_deposits · acmi_agent_pool_records · _acmi_pool (RAM) · _COMPARTMENTS (RAM) · les trois paliers navigateur. On arrive à 13 en comptant hot/warm/cold séparément — c'est très probablement l'origine du chiffre, mais c'est une hypothèse, pas une mesure. Tant que la règle de comptage n'est pas écrite, le compte est une rumeur.
• ⚑ CE QUE LA CLASSIFICATION, ELLE, TIENT — et il faut le dire avec la même précision que les trous. Les quatre chiffres de CLAUDE.md sur cet axe ont été RECOMPTÉS à HEAD et sont justes : 34 libellés (16 opérationnels + 11 données + 7 sectoriels, recomptés sphère par sphère sur le dict LIBELLES de spheres_libelles.py:66-141) ; 16 canaux (event_bus.py:289-294) ; 8 branches + 1 tronc (arbre_canon.py:70, :73) tenus par 12 épreuves (hf-atom-tools/atom_canon/tests/test_arbre_canon.py, 12 `def test_`) ; 27 = 3 × (8+1) (arbre_canon.py:155-157). La décision 34 — « la taxonomie de CLAUDE.md EST le canon » — se vérifie.
• ⚑ LE PIÈGE DES DEUX RÉPONSES EST RÉEL ET NON GARDÉ. `sphere_de('TRONC')` rend S0 (spheres_libelles.py:71 — « TRONC » enregistré comme face DONNÉES de S0) pendant que `arbre_canon.TRONC` vaut S9 (arbre_canon.py:73). Deux modules du MÊME paquet, deux réponses, aucun test qui les croise. Ce n'est pas une erreur — c'est une homonymie de FACE, et CLAUDE.md la documente — mais rien dans le code n'empêche une session future de la lire comme une erreur et de « corriger » le bon module.
• ⚑ LA RÉSOLUTION PAR LE SENS EXISTE ET PERSONNE NE S'EN SERT. `sphere_de()` ferme exactement le piège qui a coûté une session (lire la 6ᵉ clé de ATOM_MAPPING et conclure « S6 = communication », alors que Communication est S0). Mais les trois listes divergentes que sa propre docstring dénonce (:21-30) sont toujours là, inchangées : `routers/spheres.py` CANONICAL_SPHERES, `atom-mapping-data.js` ATOM_MAPPING.spheres, `atom-manifest-format.js` SPHERE_RULES. L'organe de réconciliation est bâti ; aucun classeur ne l'appelle. C'est le même motif que la myéline et que `aderive_womb_depth` : la bonne pièce, posée à côté de la chaîne.
• ⚑ PÉRIMÈTRE DE MES « ZÉRO APPELANT », parce qu'un zéro sans son périmètre est une rumeur. Fouillé : `backend/app/` ET `backend/` hors app/ (le second arbre, ~278 .py), `agents/`, `frontend/`, `scripts/`, `hf-atom-tools/` — hors `archives/`, `transit/`, `backend/tests/`, `__pycache__`, `.venv-tests`. Mesuré au COMMIT (`git show HEAD:` / `git grep HEAD`), pas dans l'arbre de travail, parce que 60+ fichiers backend sont sales sur cette branche (`integration/fondateur-p0`, HEAD = 8addf1c9481559a8e9dbc97b1fc0bcc85e10a0e1). Les routeurs cités sont vérifiés enregistrés dans `git show HEAD:backend/app/main.py` — mais `register_router` avale les ImportError : « enregistré » n'est pas « monté sans erreur » tant qu'on n'a pas interrogé le serveur vivant, ce que cette planche n'a pas fait (lecture seule).

Mesuré en lecture seule au commit 8addf1c9481559a8e9dbc97b1fc0bcc85e10a0e1 (branche integration/fondateur-p0), par `git show HEAD:` et `git grep HEAD` — jamais dans l'arbre de travail, qui est sale sur 60+ fichiers backend. Aucune base interrogée, aucune production touchée, aucun commit. CE QUI N'EST DONC PAS ÉTABLI ICI : (1) qu'un routeur « enregistré dans main.py » soit effectivement monté — `register_router` avale les ImportError, et seule une interrogation du serveur vivant le dirait ; (2) le contenu réel des tables nommées — `womb_events`, `memory_layer_events`, `instance_memory_grants`, `acmi_memory_deposits`, `acmi_agent_pool_records` : la planche décrit leur STRUCTURE et leurs contraintes, pas leur peuplement (et la mémoire du dépôt porte « 429 des 448 tables sont vides », non revérifié ici) ; (3) le compte des couches de mémoire, faute de règle de comptage écrite — onze vérifiées et nommées, pas treize. Les chiffres de CLAUDE.md sur l'axe des données (34 libellés / 16 canaux / 8+1 branches / 12 épreuves / 27 cellules) ont tous été RECOMPTÉS à HEAD et sont confirmés. Le périmètre des « zéro appelant » est nommé en marge ; hors de ce périmètre, aucun de mes zéros ne vaut.

ne pas dessiner

• Les 7 planches cosmogrammes existantes (frontend/planches/*.svg) — 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 déjà faites : économie, armure, politique, institutions, entreprise
• La grille 27 comme sujet principal — elle a sa planche ; ici elle n'apparaît que comme pièce calculée (cellules_grille_27), parce que la question posée est la CLASSIFICATION et la COMPARTIMENTATION, pas la topologie
• Les 2 axes comme simple rappel doctrinal — ils sont dessinés ici avec leurs compteurs recomptés, sinon la planche répète CLAUDE.md au lieu de le vérifier
• Un 12ᵉ inventaire de la dormance : les « zéro appelant » de cette planche sont SITUÉS et leur périmètre est nommé, ils ne rouvrent pas le dossier dormance

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.