L’état technique
du dépôt

Comment lire ce livre

La seule question qui compte, devant n'importe quelle regle de ce systeme : quel fichier retourne false ou leve une exception quand on la viole ?

Si la reponse est « aucun », vous tenez du texte, pas une garde.

Ce livre a ete bati sur cette question. Quinze domaines ont ete releves en ouvrant le code, jamais en lisant la documentation — parce que le depot avertit lui-meme que son manifeste doctrinal derive du code reel. Chaque piece porte donc un etat et une preuve :

LIVRÉ — le code existe *et* quelque chose l'appelle : une route montee, un import reel, un test qui l'exerce.
CÂBLÉ, EN ATTENTE — le code existe, il est correct, mais rien ne l'appelle. Il attend.
DÉCLARATIF — ca n'existe qu'en documentation, en commentaire ou en maquette.

Et les pieces declarees livrees ont ensuite ete reprises par un second lecteur, avec la consigne inverse : les refuter. Quinze n'ont pas tenu. Elles ont leur chapitre, avant les domaines.

Ce que vous possédez

Vous héritez d'une membrane HTTP en bien meilleur état que sa réputation : 357 routers, tous montés, zéro orphelin, 4 428 portes d'entrée, 85 % authentifiées, 1 268 fichiers de test.
Le mécanisme de montage est bien pensé : dix routers vitaux font échouer le démarrage, le reste dégrade sans coucher le serveur, et un témoin nominatif dit qui est mort.
La membrane de mérite (perméable / gestationné / scellé) est bâtie, testée, sans dépendance, et trois consommateurs réels s'en servent avant d'agir.
La cryptographie est vraie là où elle prétend l'être : Ed25519 pour la signature, HMAC-SHA256 avec séparation de domaine et comparaison à temps constant pour l'armure.
L'œuvre publique est complète et se régénère depuis ses sources — aucune page recopiée à la main.
Le squelette est là : une carte fractale de 24 troncs, 2 577 feuilles, servie en API.

Mais : les agents ne travaillent pas — l'exécution retourne une chaîne en dur, Nova excepté.
Les étages ne sont pas une sécurité — un clic suffit pour se hisser au sommet.
Les règles de frontière sont du texte servi en HTTP — aucune ne refuse quoi que ce soit.
Le site public ne publie pas ce dépôt, et 43 pages ne sont reliées à rien.

En une phrase : *une charpente solide, une belle façade, une plomberie honnête — et le moteur n'est pas branché.*

Les sept choses à ne pas casser

1. Les dix routers core=True (main.py:1216-1228). Leur panne refuse le démarrage : c'est une protection, pas un défaut. Ne la retirez pas pour « déboguer plus vite ».
2. Object.freeze dans frontend/js/sacred-constants.js. C'est le Point 0. Tout s'y réfère, et le pouls du Sanctum diffuse une somme de contrôle faite exprès pour détecter qu'on l'a bougé.
3. Les deux gardes de gouvernance des agents (routers/agents.py:684-700 et :774) : refus du chaînage agent→agent, point de contrôle humain obligatoire en L2/L3. C'est le seul endroit du système où un interdit est réellement appliqué.
4. Le gate d'authentification MCP (mcp_server.py:751), fermé par défaut. Sans lui, la lecture du code source est ouverte à tout Internet.
5. Le silence du centre. Le Centre-Réceptacle mesure et ne renvoie jamais d'ordre ; les deux pôles voisins publient des topics nommés au lieu du pouls canonique. Le jour où l'un des trois republie vers les étages, vous avez une boucle et plus de vide central.
6. Les fichiers engendrés — index.html, livre-reference.html, releve-chiffres.html. Éditez la source (landing-unifie.html, content/lettre-aux-humains.md), jamais la copie : elle sera écrasée sans avertissement.
7. Les populations mises au frigo (agents/capability-notes/, cinq notes). Elles sont archivées volontairement et un test vérifie qu'elles y restent. Ne les « réveillez » pas par curiosité.

Les sept premiers gestes

1. Mesurer avant de toucher. Appeler /internal/registration-status sur le serveur en marche. Si le nombre « ok » est nettement sous 366, des pans entiers sont muets et personne ne l'a vu.
2. Fermer la porte des étages. Faire dériver le niveau autorisé de la session serveur au lieu du clic (env-runtime.js:799, desktop-shell.js:979). Tant que ce trou est ouvert, la hiérarchie est un rangement d'écran. À faire avant toute mise en ligne publique.
3. Rebrancher la publication. Le domaine public est servi par un autre projet, depuis un autre dépôt, figé depuis mars. Soit vous rattachez le domaine au projet qui sert ce dépôt, soit vous déployez ce frontend depuis celui qui porte le domaine. Sans ce geste, aucun des six autres ne se voit.
4. Armer les alarmes. REGISTER_ROUTER_STRICT=1 en intégration continue (jamais en production) : chaque router mort devient un échec bruyant. Aucun code à écrire. Meilleur rapport effort/résultat du dépôt.
5. Brancher l'exécution des agents. Nova sait déjà parler à un modèle réel. Réutiliser ce connecteur là où il y a # TODO: Actual LLM execution. C'est le geste qui transforme un catalogue en système. Tout le reste — quotas, coûts, approbations, traçabilité — est déjà bâti et attend.
6. Réparer ce qui est visible et cassé. Les huit cartes muettes (bibliothèques externes bloquées par la politique de sécurité : les rapatrier en local plutôt qu'ouvrir la politique), puis relier au menu les pages orphelines qui marchent — à commencer par le Livre, que l'onglet portant son nom contourne aujourd'hui.
7. Trancher les orphelins. 52 services que rien n'importe, un arbre fantôme de 2 460 lignes en double, un point d'entrée agents que personne n'appelle, un noyau NEXUS de 1 287 lignes que le catalogue déclare branché à tort. Chacun : brancher ou supprimer. Le pire état est l'état actuel — vert aux tests, absent du produit.

La carte en un coup d’œil

Lecture verticale, du porteur vers le porté. *Si l'étage du bas tombe, tout ce qui est au-dessus tombe.*

``
FAÇADE Pages (148) · Œuvre publique · Livres
↑ dépend de : config.js, governance-init.js, CSP
SURFACES Domaines métier · Décodage (Babel, temples, canon)
Économie & chaîne · Armure 15D
↑ dépend de : routers, services, base
MEMBRANE Routers (357) · Auth & RBAC · Membrane de mérite
Étages L1-L4 · Gate MCP
↑ dépend de : main.py, bus, base
PLOMBERIE Bus d'événements · Topics · Base (Supabase)
Fournisseurs LLM
↑ dépend de : constantes, main.py
CENTRE main.py · Point Zéro · Constantes gelées · Cartographie
``

Les dépendances qui font mal :
- Tout dépend de main.py. Un router non déclaré n'existe pas, quel que soit son code.
- Le peuple dépend entièrement des fournisseurs LLM. Sans eux, 529 fiches et zéro travailleur.
- Les quatre cardinaux dépendent entièrement du bus. Sans bus, ils ne font rien.
- Les étages ne dépendent de rien — c'est précisément le problème : aucune session ne les gouverne.
- Le double pouls vient de deux bus séparés (serveur et navigateur). Ce n'est pas un bogue local, c'est une conséquence d'architecture.
- Le décodage, l'économie et l'armure supposent la base présente. 55 % des routers survivent sans elle ; ces domaines-là, moins.
- La façade dépend de la politique de sécurité du déploiement — c'est elle qui protège le site et elle qui casse huit cartes.

Les surprises

Ce qu'on croit avoir et qu'on n'a pas

- Douze modules métier « verticals » annoncés. Le dépôt versionné n'en contient aucun. Sur un clone neuf, ils n'existent pas.
- 400+ agents. Il y a 405 à 529 *fiches*, 238 *définitions*, et environ dix classes exécutables — dont quatre réellement appelées. Rapport vitrine/atelier : 40 pour 1.
- Un catalogue d'agents affiché. Il est chargé, mais aucune page ne le lit : le chargeur et le lecteur sont des ensembles disjoints, et une branche de lecture pointe vers un objet global qui n'existe nulle part.
- Une isolation en trois zones. Le fichier qui devait l'imposer se déclare lui-même « échafaudage », liste 3 modules au lieu de ~160, et n'est lancé par aucun script du dépôt.
- Une escalade automatique des alertes critiques. Elle est morte deux fois : l'étage émetteur n'a aucun droit de commande, et la comparaison de casse ne peut pas correspondre. Une alerte sentinelle critique ne remonte à personne.
- Des règles de frontière et de passation. Elles sont lues, transportées, recopiées — jamais appliquées. Zéro sur quatre.
- Une sphère Durabilité peuplée. 45 fiches en vitrine, 0 définition au registre.
- Un site public servi par ce dépôt. Non : par un autre projet, depuis un autre dépôt, dernier déploiement en mars.

Ce qu'on a sans le savoir

- Zéro router orphelin. La documentation en annonce 36 ; il n'y en a plus un seul. La famille « canon », décrite comme abandonnée, est complète et montée.
- 4 428 portes d'entrée web, dont 85 % authentifiées.
- Un témoin de vérité déjà bâti : un endpoint qui livre la liste nominative des routers morts au démarrage.
- Un mode strict déjà codé — il suffit d'une variable d'environnement pour rendre toute panne bruyante.
- Un coupe-circuit de site entier, avec dérogation locale pour vous. Si un jour tout semble mort, regardez cette ligne en premier.
- De la vraie cryptographie, correctement faite, testée, là où on s'attendait à des maquettes.
- 1 268 fichiers de test, dont 705 touchent une route : c'est le filet qui protège tout le reste.
- Un dépôt qui se dénonce lui-même : une page de relevé porte des ancres nommées « gonflé » sur ses propres chiffres. Quelqu'un a déjà commencé le travail d'honnêteté — il suffit de le continuer.

Ce qui n’a pas tenu à la contre-épreuve

Chaque pièce déclarée livrée a été reprise par un second lecteur, avec une consigne inverse : essayer de la réfuter. Car « livré » exige deux choses — que le code existe, et que quelque chose l’appelle vraiment. Un fichier que personne n’importe n’est pas livré : il attend.

Quinze pièces n’ont pas tenu. Les voici, sans arrangement.

Les modules opérationnels — routers HTTP et couche services du backend

C'est la partie du système qui répond quand quelqu'un frappe à la porte : 357 fichiers « routers » qui exposent environ 4 428 portes d'entrée web (les endpoints), et 720 fichiers « services » qui contiennent le travail réel derrière ces portes. Tout est monté par un seul fichier chef d'orchestre, backend/app/main.py, qui décide au démarrage quels modules s'allument.

23 livrées · 1 en attente · 1 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

La membrane HTTP est en bien meilleur état que ce que la documentation laisse croire. Les 357 routers présents sur disque sont tous déclarés au montage — il n'y a plus un seul orphelin, alors que CLAUDE.md en annonce encore 36. La famille canon, décrite comme dix routers abandonnés, est aujourd'hui complète et montée à treize.

Le mécanisme de montage est bien pensé. register_router() (main.py:1174) sépare franchement deux régimes : dix routers CORE dont la panne fait refuser le démarrage — donc jamais de dégradation invisible sur le cœur — et le reste en optionnel, qui échoue en écrivant une erreur sans coucher le serveur. Un commentaire dans le fichier raconte pourquoi : une panne d'import était autrefois journalisée en simple avertissement, invisible en production pendant plus de vingt-quatre heures. C'est corrigé, et un mode strict (REGISTER_ROUTER_STRICT=1) permet d'échouer franchement en développement.

L'instrumentation existe et elle est honnête : /internal/registration-status (main.py:2080) livre la liste nominative des routers cassés au démarrage, protégée par un jeton interne.

Les habitudes de code sont régulières : 198 routers sur 357 continuent de répondre sans base de données, 301 sur 357 portent une authentification, et 1268 fichiers de test dont 705 touchent une route — c'est la meilleure preuve indirecte que ces modules se chargent vraiment.

Ce qui manque

Du plus bloquant au moins.

1. « Monté » veut dire « déclaré », pas « vivant ». Je n'ai pas pu le prouver : fastapi et sqlalchemy ne sont pas installés sur cette machine, donc aucun import n'a pu être testé. Comme register_router avale les erreurs d'import des 356 routers optionnels, un router peut être déclaré dans main.py et n'exposer aucune porte en production sans que rien ne le crie. Mon 357 sur 357 est un compte de déclarations. La vérité runtime n'est lisible que sur le serveur, via /internal/registration-status.

2. 52 services que rien n'appelle. Du code entier, d'apparence correcte, qu'aucune ligne du dépôt n'importe : sphere_service, vector_db, embedding_service, websocket_handler, gematria, page_rank, forum, social_feed, zama_service, xr_renderer_service, automation_engine et 41 autres. Le piège : plusieurs figurent dans master_hash_registry.py, ce qui donne l'illusion d'être branchés. Ce fichier ne contient aucun import dynamique — il ne fait que distribuer des étiquettes au bus d'événements. Y être inscrit ne réveille rien.

3. backend/verticals/ est vide. La documentation annonce douze verticals V68 actifs. Le dépôt versionné n'en contient aucun : seulement un README et un dossier _archived (5 fichiers suivis par git). Sur un clone neuf, ces douze modules métier n'existent pas. Les quatorze routers « verticals » de main.py:1832-1853 pointent, eux, vers backend/app/routers/ — ils ne dépendent pas de ce dossier.

4. Trois concentrations lourdes. qg_fractalization_router (185 endpoints), governed_collaboration_router (161) et qr_sentinel_router (123) portent à eux seuls 469 endpoints, soit 11 % de la surface. Aucun n'est CORE : si l'un casse à l'import, 185 portes disparaissent en silence.

5. Un bloc mal étiqueté. Les 100 routers de main.py:1899-2025 sont sous l'en-tête « FRACTAL-CODE-INDEX REST query API ». Le contenu réel est tout autre chose : crm, compta, marketing, creation_hub, energy_center. Un lecteur qui se fie aux commentaires se trompe de carte.

6. La surface legacy /api/v1 (11 routers) est montée en optionnel. Elle peut mourir sans bruit.

Se tient avec : Base de données et persistance — 198 routers sur 357 dépendent de get_db_optional et changent de comportement selon que la base répond ou non · Authentification et RBAC — 301 routers portent get_current_user ou require_internal_token ; le bloc RBAC de main.py:1375-1548 (39 routers) gouverne l'accès de tous les autres · Bus d'événements et catalogues de topics — event_bus.py et bus_acl.py consultent master_hash_registry pour valider la provenance des messages ; c'est ce qui donne aux services orphelins une fausse apparence de branchement · Agents et ACMI — 15 routers en main.py:1548-1610, et 12 cibles de montage portant 'agent' dans leur nom · Babel et le décodage — 11 routers plus 64 fichiers services, dont un router en CORE (inter_village_router) · Canon et cohérence doctrinale — 13 routers canon montés, plus l'outil de détection de divergence code/documentation (canon_divergence_router) · Frontend — les 4 428 endpoints sont la surface que consomment les pages de frontend/ via atomFetch et atomPost · Tests — 705 des 1268 fichiers de test touchent un router ; c'est le filet qui protège ce domaine

Les pages du frontend — frontend/*.html : ce que chaque page est, et ce qu'elle fait vraiment

C'est la partie visible d'AT·OM : 148 fichiers HTML qui vont de l'affiche publique (l'œuvre, les lettres, les livres) jusqu'aux tableaux de bord qui parlent au serveur. Chaque page est autonome — elle charge elle-même sa liste de scripts, il n'y a pas de framework qui assemble le tout.

21 livrées · 2 en attente · 1 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent solidement, et elles sont mesurables.

Premièrement, le câblage n'est pas cassé. J'ai extrait les 237 références de script distinctes de toutes les pages et vérifié l'existence de chaque fichier : zéro manquant. C'est rare dans un dépôt de cette taille, et ça veut dire qu'aucune page ne plante au chargement à cause d'un fichier absent.

Deuxièmement, l'œuvre publique est complète et se régénère. index.html, livre-reference.html et releve-chiffres.html ne sont pas recopiés à la main : ils sont engendrés par scripts/generer-index.py, scripts/generer-livre-reference.py et scripts/generer-releve-chiffres.py depuis leurs sources. Le chemin de lecture — page-mère, les Lettres, les 7 présentations, le Livre, le relevé des chiffres — est entièrement relié et fonctionne sans serveur.

Troisièmement, le cœur métier est réellement branché. Les 10 pages de sphère ont leurs 10 modules présents sur disque (vérifiés un par un, de 311 à 1617 lignes), elles figurent dans la liste GOVERNANCE_PAGES de governance-init.js:53-56 qui leur donne la pile complète, et elles appellent le serveur. business.html avec ses 28 appels, construction.html avec 21, institutions.html avec 17 : ces pages-là travaillent pour de vrai.

Ce qui manque

Du plus bloquant au moins.

1. Huit cartes sont muettes en production. cooperation, cosmogramme-3d, donut, flows, geo-hub, mirror-earth, resources et temple-decoder chargent d3.js, Leaflet, MapLibre ou CesiumJS depuis l'extérieur. Or frontend/vercel.json impose une Content-Security-Policy avec script-src 'self' : le navigateur refuse ces fichiers. Le code des pages est bon, la carte reste blanche. C'est le seul défaut que j'ai pu prouver comme cassant quelque chose de visible.

2. Quarante-trois pages sur 148 sont inaccessibles à la navigation. Personne ne peut les atteindre en cliquant — il faut connaître l'adresse. Parmi elles, des pages qui marchent : admin.html (14 appels serveur), mission-center.html (router monté en main.py:1699), les 4 centres Tier-2 (routers montés en main.py:1916, 1923, 1934, 1947), les 4 pages Babel, et 5 des 6 livres de référence. Ce n'est pas du code mort, c'est du travail livré et enterré.

3. Six centres sectoriels n'ont aucune route derrière. energy-center, defense-center, science-center, disaster-center, agriculture-center et design-center ont chacun une page de 735 à 1331 lignes, mais un grep -rl sur backend/app/routers/ ne trouve aucun fichier à leur nom. Les pages existent, le serveur n'a rien à leur répondre.

4. Le JavaScript écrit dans les pages. admin.html porte 1645 lignes de code inline, editor.html 1251, liberation.html 560. Ce code n'est ni réutilisable, ni testable, ni chargé par governance-init. Si une de ces pages tombe, il n'y a pas de module à ouvrir : il faut fouiller le HTML.

5. Les seize pages « Loading… » qui ne se remplissent que si le serveur répond. Les 4 centres Tier-2, mission-center, coverage.html (un seul div vide) sont des coquilles par conception : tout leur contenu vient de center-summary-page.js ou d'un module. Elles ne sont pas fausses, mais elles n'ont aucun repli — serveur absent, page vide, sans message.

Se tient avec : Le serveur (backend/app/main.py) — 369 routes montées via register_router ; c'est de là que viennent les données des 61 pages qui appellent le serveur, et son absence explique les 6 centres sectoriels sans réponse · Les modules JavaScript (frontend/js/, 1658 fichiers) — les pages ne sont que des coquilles qui les chargent ; governance-init.js est le distributeur · Le déploiement (frontend/vercel.json et le vercel.json racine) — décide de ce qui est publié, et sa Content-Security-Policy casse 8 cartes · Les générateurs (scripts/generer-index.py, generer-livre-reference.py, generer-releve-chiffres.py) — 3 pages de l'œuvre en dépendent et ne doivent pas être éditées à la main · Le bus de messages (frontend/js/message-bus.js, 1359 lignes) — chargé par presque toutes les pages câblées ; c'est la plomberie entre modules d'une même page · Supabase — seul service tiers autorisé par la CSP en connect-src (vzbrhovthpihrhdbbjud.supabase.co), avec une poignée d'API ouvertes (Wikipedia, OpenLibrary, open-meteo, GBIF, iNaturalist, OpenStreetMap)

La population interne — agents, fiches, registres et les 4 cardinaux

C'est le peuple du système : les fiches de personnages qu'on peut « embaucher » dans un catalogue, les définitions rangées dans un registre côté serveur, et le très petit nombre de classes qui savent réellement s'exécuter. Trois choses différentes que le vocabulaire du dépôt appelle toutes « agents », et qu'il faut absolument séparer pour ne pas se croire propriétaire de 400 travailleurs alors qu'on possède 400 cartes de visite.

15 livrées · 5 en attente · 5 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Quatre choses tiennent debout et méritent votre confiance.

D'abord, le catalogue. Les 405 fiches frontend et les 529 fiches backend sont réelles, complètes, bien écrites, avec des descriptions en français adressées à l'utilisateur (« Vous suit vos stocks… »). C'est un vrai travail de conception, pas du remplissage. La navigation, le filtrage par domaine et par niveau, l'embauche et le renvoi fonctionnent de bout en bout.

Ensuite, la gouvernance humaine. C'est la partie la plus sérieuse du domaine. La règle « pas d'agent qui en appelle un autre » est appliquée pour de vrai : backend/app/routers/agents.py:684-700 refuse la requête avec une erreur 400 si on tente de chaîner. Le point de contrôle humain pour les niveaux L2 et L3 est appliqué aussi : erreur 423 tant qu'un humain n'a pas approuvé (agents.py:774). Ce ne sont pas des intentions dans un document, c'est du code qui bloque.

Puis, les 4 cardinaux au navigateur. Ils sont réellement réveillés au démarrage (governance-init.js:429-432), ils écoutent et publient sur le bus interne. Ils sont petits mais honnêtes : ils font exactement ce que leur code dit, ni plus ni moins.

Enfin, Nova côté serveur (backend/app/routers/nova.py, 1890 lignes). C'est le seul endroit du domaine où un vrai modèle de langage est appelé, avec un repli propre sur des réponses toutes faites quand aucune clé n'est configurée. Si quelque chose dans ce système « parle » vraiment, c'est là.

Ce qui manque

Du plus bloquant au moins :

1. Les agents ne travaillent pas. C'est le trou central. Quand on demande à un agent d'exécuter une tâche, le système répond [Mock response from <nom>]: Processed input successfully (backend/app/routers/agents.py:794-806). Le service dédié dit la même chose autrement : # TODO: Actual LLM execution et "note": "This is a placeholder. Real LLM integration pending." (agent_execution.py:432-455). Les jetons facturés sont calculés par len(str(...)) // 4, une estimation grossière. Tout l'échafaudage — embauche, quotas, coûts, points de contrôle, traçabilité — entoure un centre vide. Nova est la seule exception.

2. Les agents de fil (ThreadAgent) sont enfermés. 756 lignes de code correct dans backend/app/services/thread_agent_service.py, et aucun router ne l'importe. Le canon présente pourtant les Thread Agents comme le type d'agent numéro 1, celui que l'utilisateur voit. Il n'est joignable par aucune adresse. Et même s'il l'était, ses capacités sont des maquettes (l.553 « CAPABILITY HANDLERS (Mock implementations) »).

3. Les deux catalogues ne décrivent pas le même monde. Le backend dit « reflète le frontend » en tête de fichier, mais il contient 529 fiches contre 405, et son 8e domaine s'appelle Logistique là où le frontend dit MonEquipe. Selon qu'on interroge la page ou le serveur, on ne voit pas la même population.

4. La sphère Durabilité est vide au registre. SphereType.SUSTAINABILITY: 0 (agent_schemas.py:452) alors que la vitrine en montre 45. Si un utilisateur clique sur un agent Durabilité, il tombe sur le catalogue de secours, jamais sur une définition en base.

5. Neuf modules d'interface sur vingt ne sont pas chargés. agent-permissions.js, agent-decision-log.js, agent-negotiation.js, agent-execution-ui.js, agent-templates-picker.js, knowledge-agent-wiring.js n'existent qu'à travers leurs propres tests. Ils passent au vert et ne servent personne. agent-permissions en particulier — les permissions d'agent — est un manque qui compte.

6. Le point d'entrée agents/index.js est mort. Personne ne fait require dessus dans tout le dépôt. Le fichier qui se présente comme « AT·OM AGENT ORCHESTRATION SYSTEM — Nova, Aria & 400 Specialists » n'orchestre rien.

7. Un arbre fantôme de 2460 lignes. backend/services/agent_registry.py (652 lignes) coexiste avec backend/app/services/agent_registry.py (916 lignes, le vivant). Trois autres fichiers du même genre. Aucun n'est importé par l'application. C'est un piège à modification.

8. Les 88 profils de personnes ne sont branchés nulle part. Zéro référence en code, dans les deux sens de recherche.

Se tient avec : Fournisseurs LLM — le domaine population dépend entièrement de app/services/llm_connector.py pour cesser d'être une maquette ; aujourd'hui seul Nova s'en sert · Bus de messages — les 4 cardinaux n'existent qu'à travers frontend/js/message-bus.js ; sans bus, ils ne font rien · Gouvernance et points de contrôle — les checkpoints L2/L3 et l'interdiction de chaînage sont la membrane du domaine (S3 Institutions) · Sphères et taxonomie — les 9 domaines du catalogue et les 9 SphereType du registre ne coïncident pas exactement (S9 vide côté registre) · Base de données Supabase — 12 migrations alembic v82_* portent des tables agents ; le registre sait semer via seed_agents(), appelé depuis 3 routers · Moteur de monde (world_engine) — seule zone où des classes agents s'exécutent vraiment, via domain/worker.py · ORIGIN-GENESIS — population parallèle de 21 experts, gouvernée séparément · Connecteurs externes — agent-character-manager.js raccorde automatiquement les personnages créés par l'utilisateur à connector-hub.js

Les étages de cohabitation (L1 ETHOS / L2 AGORA / L3 NEXUS / L4 LUNA), la membrane, les gates et le Point Zéro

C'est l'étage « qui a le droit de voir quoi » du système : quatre paliers d'observation empilés (sentinelles, opérations, commandement, observatoire), une membrane qui décide si une lecture passe ou « gestationne encore », et un centre vide — le Point Zéro — qui bat un pouls et n'ordonne rien. Aujourd'hui le tri de visibilité fonctionne vraiment côté écran, mais personne ne vérifie qui vous êtes avant de vous laisser choisir votre étage.

19 livrées · 3 en attente · 4 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent vraiment.

D'abord, la chaîne de visibilité côté écran est complète et mécanique, du haut en bas : la matrice (hierarchy-sync.js:68-72) → getVisibleLevels (level-consoles.js:373) → maxAccessLevel (level-consoles.js:395-405) → le filtre effectif (widget-registry.js:629). Un utilisateur en « agora » ne verra réellement pas les widgets marqués L3 ou L4. Ce n'est pas de la décoration.

Ensuite, la membrane serveur est bâtie, propre et testée. membrane_service.py est un fichier de 103 lignes sans dépendance à la base de données ni au framework — on peut le tester à froid, et c'est fait (10 tests). Ses trois verdicts sont bien pensés : « permeable », « gestating » (pas encore mérité — un pas-encore, pas un refus) et « sealed » (l'intérieur d'autrui, inviolable). Trois consommateurs réels s'en servent avant d'agir : les organes vivants MCP, l'accès au dépôt, et le bureau.

Enfin, le Point Zéro bat pour de vrai côté serveur : le planificateur démarre à l'allumage (main.py:753-754) et s'arrête proprement (main.py:917-918), et au moins deux consommateurs l'écoutent (fractal_clock_router.py:163, atom_node_ws_relay.py:80). La discipline du centre muet est respectée : le Centre-Réceptacle mesure sans jamais renvoyer d'ordre, et les deux pôles voisins émettent des topics nommés plutôt que de squatter le pouls canonique.

Ce qui manque

Du plus bloquant au moins.

1. Les étages ne sont pas une sécurité — ils sont une préférence d'affichage. env-runtime.js:799-803 ne vérifie qu'une seule chose : que le nom d'étage existe. Aucune session, aucun rôle, aucun jeton. Le menu du bureau (desktop-shell.js:979-986) offre les quatre consoles en clic direct. N'importe qui peut se hisser à L4 LUNA. Tout ce qui est « caché » à un étage inférieur n'est caché qu'à quelqu'un qui ne clique pas.

2. La seule escalade automatique du système est morte deux fois. hierarchy-sync.js:687 tente sendCommand('ethos','nexus') alors qu'ethos n'a aucun droit de commande (ligne 69) — refus garanti. Et même sans ça, la condition teste 'critical' en minuscules quand les émetteurs réels publient 'HIGH' (event-bridge-router.js:233,308). Une alerte sentinelle critique ne remonte à personne.

3. Deux Points Zéro battent en parallèle sans se connaître. Le Sanctum publie 'pointzero.heartbeat' côté serveur ; zero-point-sync.js:271 publie le même nom de topic côté navigateur, sur un bus différent. 23 fichiers frontend touchent ce topic. Le code serveur lui-même a nommé le danger (communication-center-governed.js:245 : « multiple_runtime_neighbor_publishers_share_pointzero_heartbeat_without_canonical_ownership »). Les constantes canon sont d'ailleurs recopiées à la main en Python (point_zero_heartbeat.py:39-44) au lieu d'être lues depuis sacred-constants.js — un TODO l'admet.

4. L'isolation des 3 zones n'existe pas. .importlinter était censé l'imposer mécaniquement ; il se déclare lui-même « SCAFFOLDING », liste 3 modules d'exemple au lieu de ~160, ne cite même pas app.services.sanctum, et n'est lancé par aucun script ni aucune CI du dépôt. L'obstacle historique (le fichier decision_point_schemas.py tronqué) est pourtant réparé — j'ai vérifié qu'il compile. La voie est libre, personne ne l'a prise.

5. Les règles de frontière sont du texte servi en HTTP. Les « frontier_rule » de cluster_k_frontier.py et les 4 handoff_rules du protocole (dont « le centre est fermé ») sont lus, transportés, recopiés dans des paquets — jamais appliqués. Aucun code ne refuse quoi que ce soit sur leur base.

6. Deux échelles portent les mêmes noms. L1/L2/L3 veut dire ETHOS/AGORA/NEXUS d'un côté, et Orchestrateur/Spécialiste/Assistant de l'autre (backend/agents/core/models.py:23-35), les deux montés en production. Rien n'indique dans le code lequel est en jeu.

7. L'annuaire serveur des étages ne sert à rien en production : get_by_level (master_hash_registry.py:729) n'est appelé que par des tests.

Se tient avec : Agents et orchestrateurs — les quatre personas cardinales (Aria, Nova, Orion, Keli) sont référencées dans chaque ORCHESTRATOR_GUIDE des modules d'étage ; et le "TOI augmenté" (Keli) est explicitement prévu par la membrane pour opérer SOUS l'identité du Point Zéro (membrane_service.py, docstring) · Sphères S0-S9 — la seconde coordonnée de chaque module dans master_hash_registry.py, et la cible des gates de spatial_rbac_enforcer.py (SPHERE_GATES) · Bus de messages — c'est le seul moyen de circulation entre étages ; le domaine dépend entièrement de frontend/js/message-bus.js côté navigateur et de app/services/event_bus.py côté serveur, et le double pouls du Point Zéro vient précisément de ce que ce sont deux bus séparés · Horloge fractale et pouls bio — fractal_clock_router.py:163 est le consommateur principal du battement du centre ; les cadences (432 ms, 39 s, 43,2 s) viennent de là · MCP et le bureau — mcp_live_organs.py, mcp_repo_tools.py et bureau_service.py sont les trois seuls consommateurs vivants de la membrane ; c'est là que la perméabilité par mérite s'exerce vraiment · Souveraineté et invariants canon — l'invariant IC-N10 (souveraineté observée, non imposée) est ce que traduit le verdict "sealed" de la membrane ; le paquet hf-atom-tools/atom_canon/ en porte la version formelle, encore non branchée au serveur · Temples et positionnement fractal — cluster_k_frontier.py articule le Point Zéro avec le maillage des temples et l'adresse fractale

L'armure 15D et le quantique

L'armure, c'est la fiche d'identité chiffrée d'un membre : quinze « dimensions » (identité, valeur, mémoire, souveraineté…) qu'on résume en une empreinte cryptographique unique, pour pouvoir signer un engagement sans jamais montrer le contenu. Le « quantique », lui, est un nom : il y a de la vraie cryptographie moderne (Ed25519, HMAC-SHA256) qui fonctionne, mais rien dans le dépôt n'exécute de calcul quantique ni de signature post-quantique — ce sont des simulations classiques et des maquettes.

13 livrées · 4 en attente · 4 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Le vrai trésor du domaine, c'est la cryptographie classique — et elle est solide. aip_signing.py signe et vérifie avec Ed25519 par la bibliothèque cryptography standard : ce sont de vraies signatures, pas des imitations. armure_15d.py est encore mieux fait : c'est un schéma d'engagement en HMAC-SHA256 avec séparation de domaine (ARMURE15D\0v2\0hmac\0), aveuglement optionnel, et comparaison à temps constant contre les attaques temporelles. Quelqu'un qui connaissait la cryptographie a écrit ce fichier.

Le pont frontend→backend fonctionne de bout en bout et il est authentifié : FractalExpansion.js calcule les 15 forces, POST /api/v2/armure/dimensions les ingère derrière Depends(get_current_user), l'empreinte est calculée puis relue par la signature. La discipline du dépôt est respectée : le routeur ne renvoie jamais le contenu des dimensions, seulement l'empreinte et des comptes.

Les quatre routeurs du domaine sont réellement montés dans main.py (lignes 1491, 1655, 1807, 1892) — 57 endpoints qui répondent. Et le fichier services/dimensions_15.py porte une garde d'intégrité (is_valid_schema()) qui refuse un schéma abîmé.

Ce qui manque

1. Il n'y a pas une armure à 15 dimensions, il y en a trois qui ne se parlent pas. antenna.py:137 et services/dimensions_15.py:25 disent sovereignty/temporal/territorial… spiderweb.py:103 (routeur vivant, monté) dit Physical/Emotional/Mental… frontend/js/dimensional-armor.js:50 dit Électrique/Physique/Réseau… Zéro nom en commun entre les trois. Le fichier canonique l'avoue d'ailleurs lui-même dans son en-tête : « Toute divergence entre les deux est un bug ». Il n'a simplement pas vu la troisième.

2. Le post-quantique n'existe pas. Zéro signature Dilithium ou Falcon réelle. backend/security/post_quantum/crypto.py fabrique ses clés avec une f-string (f"pub_{algorithm.value}_...") et sa fonction de signature *refuse de s'exécuter* sans une variable d'environnement de test. En plus, ce module est complètement orphelin : aucun fichier de backend/app/ ne l'importe. C'est 338 lignes qui ne servent à rien aujourd'hui.

3. Le « quantique » est du calcul classique. Les modules Q1–Q5 tournent vraiment, mais ils importent random et math. Aucun qiskit, cirq ou pennylane nulle part. Ce sont des heuristiques de décision honnêtes habillées d'un vocabulaire quantique.

4. L'interrupteur CHE·NU est un leurre. Basculer CHENU_LIVE_MODE=true ne connecte rien : il n'y a aucun client HTTP dans le pont, et le mode « live » renvoie littéralement "phase": "P1_TODO". Pire, CHENU_API_URL et CHENU_API_KEY ne sont lues par aucun fichier — les configurer est sans effet. Le mode simulé donne aujourd'hui de meilleures réponses que le mode « réel ».

5. Les empreintes d'armure s'évaporent au redémarrage. armure_store.py est un dictionnaire en mémoire vive plafonné à 5 000 membres avec éviction. Après un redémarrage du serveur, toute signature retombe silencieusement sur le bouchon sha256("armure-15d:"+id) — sans erreur, sans avertissement. C'est une dégradation invisible.

6. Le cœur cryptographique n'a pas de tests. armure_15d.py, le fichier le plus sensible du domaine (325 lignes de HMAC), n'a aucun fichier de test dédié. Les 39 tests du domaine couvrent les périphéries.

7. 1 523 lignes de JS écrites pour rien. confirmation-armor.js (1 404 L) et loteria-armor-bridge.js (119 L) ne sont chargés par aucune page.

Se tient avec : Économie & UR COIN — armor-economy-bridge.js relie l'armure à l'économie ; la dimension 7 « financial » et la dimension 5 « Valeur » (deux tables différentes) prétendent toutes deux gouverner la valeur · Hedera / blockchain — antenna.py frappe les dNFT d'âme, services/hedera/mint-armor.js, dimension 12 « Blockchain » ; même pattern mock-by-default via HEDERA_LIVE_MODE · Identité & authentification — tout le domaine dépend de app.core.auth.get_current_user ; l'armure EST la fiche d'identité scellée du membre · Gouvernance AIP — aip_signing.py est le consommateur principal de l'empreinte d'armure ; le routeur aip_router est monté à main.py:1869 · Souveraineté (S3) — verite.py importe armure_15d ; la dimension 11 « Souveraineté » et la dimension 1 « sovereignty » se recouvrent sans être reliées · Canon η / ACMI — hf-atom-tools/atom_canon/bridges/ héberge le pont CHE·NU ; le hub fractal_hub.py:71 lit entangle_result · Spiderweb / défense — spiderweb.py porte la deuxième table de 15 et une couche de 9 organes de protection ; c'est le voisin le plus proche et le plus divergent · Frontend / governance-init.js — l'unique porte de chargement des modules JS d'armure (lignes 461, 462, 875)

Les portefeuilles et la trésorerie (UR COIN, Crédits, Hedera, paiements)

C'est la partie du système qui tient l'argent : une monnaie interne appelée « Crédits », une monnaie-jeton appelée « UR COIN » censée vivre sur la chaîne Hedera, et un pont entre les deux. Aujourd'hui les Crédits vivent vraiment dans une base de données, mais UR COIN ne sort pas de la machine — la trousse logicielle Hedera n'est même pas installée.

17 livrées · 6 en attente · 2 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent vraiment.

Un : les Crédits sont une vraie monnaie en base de données. Les cinq tables existent, les migrations existent (v80_023 et v80_024), chaque mouvement passe par une méthode async qui verrouille la ligne, écrit une transaction dans le grand livre et refuse de fonctionner si la base est absente. Ce n'est pas de la mémoire volatile.

Deux : la porte de création de monnaie est fermée à double tour. La route /treasury/mint exige un compte administrateur (economy_engine.py:344). Avant d'écrire quoi que ce soit, amint_credits consulte la gouvernance ET la doctrine de réserve, et si l'un des deux est injoignable, l'émission est REFUSÉE plutôt qu'autorisée (treasury_service.py:930-937 et 985-990). Le plafond quotidien est de 1 000 Crédits. La route /hedera/token/mint exige une signature cryptographique et renvoie 404 si le secret n'est pas configuré, donc elle est invisible par défaut.

Trois : la chaîne paiement → frappe ne perd rien. Le webhook Stripe répond vite, la frappe part en tâche de fond, et si elle rate, la demande est mise dans une file (pending_mints) qu'un ouvrier réessaie automatiquement au démarrage du serveur (main.py:390 et 877). L'usager a payé, son UR lui est dû, et le système s'en souvient.

Ce qui manque

Du plus bloquant au moins.

1. LA TROUSSE HEDERA N'EST PAS INSTALLÉE. Aucun des quatre fichiers requirements ne mentionne hedera ni hiero. Conséquence directe : hedera_service.py bascule en mode simulation dès le démarrage (ligne 168) et y reste, et hedera_mainnet_bridge._ensure_client() lève RuntimeError. Autrement dit, même en mettant HEDERA_LIVE_MODE=true, il ne se passera rien sur la chaîne. UR COIN, aujourd'hui, n'existe que dans notre base.

2. DEUX TROUSSES DIFFÉRENTES, TROIS NOMS DE JETON. hedera_service.py importe hedera (l'ancienne, Java) ; hedera_mainnet_bridge.py importe hiero_sdk_python (la nouvelle). Pire, dans le même fichier : _ensure_client utilise hiero_sdk_python mais get_balance (ligne 258) importe from hedera import AccountBalanceQuery — cette fonction ne peut pas marcher, quelle que soit la trousse installée. Côté nom du jeton : le pont lit UR_COIN_TOKEN_ID, le service lit HEDERA_UR_TOKEN_ID, et .env.example ne déclare ni l'un ni l'autre — il déclare HEDERA_TOKEN_ID. Trois noms pour la même chose.

3. VARIABLES MANQUANTES DANS .env.example. UR_COIN_TOKEN_ID, HEDERA_ADMIN_SECRET et MAX_SAFE_AMOUNT n'y figurent pas. Quelqu'un qui installe le système en suivant le fichier d'exemple ne peut ni frapper (jeton inconnu) ni ouvrir les routes admin (404 permanent).

4. DEUX REGISTRES D'UR QUI NE SE PARLENT PAS. La table ur_balances (ur_engine.py) et le champ coin_balance de treasury_wallets tiennent tous deux « l'UR d'une personne ». Rien dans le code ne les réconcilie. Le portefeuille affiché à l'usager (wallet_portfolio.py:169-196) lit l'UR chez ur_engine et les Crédits chez treasury — et pour les Crédits il appelle get_user_balance (treasury_service.py:754) qui est la version MÉMOIRE VIVE, celle que la décision D23 déclare morte. Le solde affiché à l'usager risque donc d'être 0 alors que la base dit autre chose.

5. LE MOTEUR D'ÉMISSION EST DÉSARMÉ VOLONTAIREMENT. Le garde G4 dit lui-même en entête (g4_emission_guard.py:22) : « État inerte préservé… le battement ne produit pas d'énergie ». C'est un choix de prudence, pas un bogue — mais il faut le savoir : l'économie ne se met pas en marche toute seule.

6. AT·OM PAY N'A PAS DE PORTE. 1 068 lignes correctes et testées dans backend/app/services/pay/, avec cinq rails monétaires décrits, et zéro routeur qui les expose. C'est un beau moteur dans une caisse.

7. LE PORTEFEUILLE CÔTÉ NAVIGATEUR N'EST PAS BRANCHÉ. rosetta-wallet.js (1 659 lignes) et hedera-flow.js (1 847 lignes) ne sont pas dans la liste de chargement de governance-init.js. L'usager ne les voit jamais.

8. SIX APPELANTS ENCORE SUR LE CHEMIN MÉMOIRE VIVE. checkout_system, grand_exchange, marketplace_3d, merchant_service, ristourne_policy_service et trinity_palace_service utilisent encore les méthodes sync (liste dans treasury_service.py:38-44). Tout ce qu'ils comptabilisent disparaît au redémarrage.

Se tient avec : Gouvernance et points de contrôle humains (app/core/governance.py) — sans elle, aucune émission de Crédits n'est autorisée : c'est une dépendance dure, fail-close · Doctrine de réserve (app/services/reserve_doctrine.py) — deuxième verrou obligatoire avant toute expansion monétaire · Paiements externes Stripe (app/routers/payments.py) — la seule entrée d'argent réel dans le système aujourd'hui · Babel et l'énergie fractale (app/services/babel/) — les trois producteurs temple, forge et fractal qui alimentent la frappe gouvernée, actuellement désarmés au niveau G4 · Le bus d'événements interne (app/core/bus_topics.py) — 11 sujets argent (2 treasury, 5 hedera, 3 stripe) par lesquels le reste du système apprend qu'un mouvement a eu lieu · Souveraineté S3 (ur_sovereignty_doctrine, sovereign_bridge) — pose les règles que la trésorerie doit respecter : pas d'indexation sur une devise, pont transitoire · Paie et comptabilité (payroll_service, compta_router, pay/bordereau) — consommateurs en aval du grand livre de trésorerie · NFT et missions (mission_nft_service) — troisième lecteur de HEDERA_LIVE_MODE, même contrat mock-par-défaut

Les NFT et ce qui se frappe (minting, Hedera, tokens)

C'est la partie du système qui « frappe » des jetons : des NFT (pièces uniques : missions, connexions, antennes, paliers investisseurs) et l'UR COIN (monnaie du système). Sur le papier c'est branché sur la blockchain Hedera ; dans les faits, aucune des deux trousses Hedera nécessaires n'est installée, alors tout se frappe en simulation.

16 livrées · 4 en attente · 1 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Le squelette est vraiment là, et il est bien meilleur que la moyenne du dépôt. Les 6 routeurs du domaine sont TOUS montés dans main.py — aucun routeur orphelin, ce qui est rare ici. 69 points d'entrée HTTP répondent. 84 fonctions de test sont écrites (je ne les ai pas exécutées : le Python local est nu).

Trois choses tiennent particulièrement bien :

Les garde-fous d'argent sont réels et ils échouent du bon côté. hedera_mainnet_bridge.py refuse toute frappe ≤ 0 ou > 100 unités (ligne 137). governed_mint.py refuse de frapper si la base est absente plutôt que de retomber sur un pot en mémoire (ligne 66) — c'est exactement le bon réflexe pour de la monnaie. nft_emission_service.py débite l'UR AVANT la frappe et échoue fermé si le débit rate (ligne 193). Personne ne peut se frapper de la monnaie par accident.

Le rattrapage automatique tourne. pending_mint_retry est démarré au lancement (main.py:388) et arrêté proprement (main.py:877) : les frappes bloquées sont reprises par lots de 9 toutes les ~56 s, les orphelines récupérées après 15 min, et l'échec définitif est signalé plutôt qu'avalé.

connection_nft_service (917 lignes) est la pièce NFT la plus solide : vraie table en base, vraies méthodes de lecture/écriture/hydratation, 4 tests, appelé par un routeur monté. Si vous devez faire confiance à un NFT, c'est celui-là.

Ce qui manque

Du plus bloquant au moins :

1. RIEN NE SE FRAPPE SUR LA BLOCKCHAIN. C'est le fait central. Deux trousses Hedera différentes sont attendues — hedera (hedera_service.py:25) et hiero_sdk_python (hedera_mainnet_bridge.py:117) — et AUCUNE des deux n'est déclarée dans les 4 fichiers requirements. Conséquence en chaîne : hedera_service.py:168 fixe _simulation_mode = True définitivement, et hedera_mainnet_bridge.py:129 lève une erreur dès qu'on tente d'initialiser le client. Le HEDERA_LIVE_MODE qu'on peut activer ne change rien : sans la trousse, l'initialisation échoue et la frappe revient en statut FAILED. Le côté Node possède la vraie trousse officielle (@hashgraph/sdk dans services/hedera/) mais son node_modules n'a jamais été installé et aucun code backend ne l'appelle.

2. LES NFT INVESTISSEURS NE DEVIENDRAIENT PAS DES NFT MÊME EN LIVE. Ce n'est pas un problème de trousse, c'est un trou dans le code. _try_hedera_mint_nft (nft_emission_service.py:163) écrit une ligne de journal HCS puis renvoie pending_xxx (ligne 185) sans jamais construire de transaction de frappe. Le client paie 1 / 100 / 10 000 UR — le débit est réel — et reçoit une ligne en base. Le vrai code de frappe NFT existe pourtant, dans backend/services/tokenomics_hedera_bridge.py lignes 79-140, mais personne ne l'importe.

3. LE NFT_VISUAL MENT. La route répond status: "completed" et une adresse /generated/nft/{id}.png (lignes 217, 242) alors qu'aucune image n'est produite — zéro code de dessin dans le fichier, et le dossier frontend/generated/nft n'existe pas. Une API qui affirme un succès qui n'a pas eu lieu est pire qu'une API qui échoue.

4. LES ANTENNES VIVENT DANS LA MÉMOIRE VIVE. Le plus gros morceau du domaine (23 points d'entrée) stocke tout dans _FALLBACK, un dictionnaire Python (antenna.py:56). Zéro sqlalchemy dans le fichier. Pendant ce temps, les tables antenna_parents et antenna_fragments existent en base (alembic v80_021) et ne sont touchées par AUCUNE ligne de code — grep sur tout backend/ hors alembic : 0. Le logement est bâti, personne n'y habite. Un redémarrage efface tout. Même problème, plus léger, pour nft_trinity (lignes 59-61).

5. DEUX FICHIERS PORTENT LE MÊME NOM. app/services/tokenomics_hedera_bridge.py (50 lignes, un simple hachage) et backend/services/tokenomics_hedera_bridge.py (~224 lignes, avec une vraie frappe NFT). Seul le petit est branché. Quiconque cherche « le bridge tokenomics » a une chance sur deux de lire le mauvais.

6. 1847 LIGNES D'INTERFACE DÉBRANCHÉES. frontend/js/hedera-flow.js n'est chargé par aucune page ni par governance-init.js.

7. UN JETON MARQUÉ COMPROMIS traîne en commentaire : services/hedera/mint-existing-token.js:11 note que 0.0.7780104 « remplace ZAMA 0.0.7730446 compromis ». À vérifier avant toute activation.

Se tient avec : Trésorerie et UR COIN — treasury_service, ur_engine, governed_mint : c'est le grand livre que toute frappe doit traverser · Paiements et abonnements — payments.py + sovereign_bridge_service : l'argent encaissé devient frappe d'UR · QR Sentinel — qr_sentinel_router est le SEUL appelant de mission_nft_service et connection_nft_service ; s'il tombe, ces deux NFT deviennent orphelins · Babel et les moissonneurs d'énergie — babel_fractal / babel_temple / forge_energy_consumer déclenchent les frappes gouvernées · Antenne dNFT et sphère S1 Personnel — les 144 000 parents × 144 fragments sont la couche identité personnelle · Mémoire et vecteurs — embedding_orchestrator utilise hedera_anchor_service pour ancrer l'historique · Migrations Alembic — 5 migrations du domaine (v80_021, v80_022, v82_042, v82_116, v82_230), dont une dont les tables ne servent à rien

Les connexions vers l'extérieur (intégrations tierces : base de données, blockchain, paiements, banque, LLM, MCP, communications, cartes, médias)

C'est l'ensemble des portes par lesquelles AT·OM parle au monde extérieur : la base de données Supabase, la blockchain Hedera, Stripe pour l'argent, Flinks pour les banques canadiennes, une douzaine de fournisseurs d'intelligence artificielle, et une cinquantaine d'autres services (courriel, cartes, images, vidéo). Presque toutes ces portes sont bâties selon le même principe : le code d'appel existe pour de vrai, mais si la clé d'accès n'est pas fournie, la porte reste fermée et le système répond une fausse réponse au lieu de planter.

17 livrées · 5 en attente · 3 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Le motif de conception est bon et cohérent partout : « la clé en dernier ». Le code d'appel est écrit d'avance, il vérifie la présence de sa clé, et sans clé il répond une fausse réponse ou une erreur propre au lieu de faire tomber le système. C'est pour ça qu'AT·OM démarre et fonctionne même sans un seul compte tiers payé.

Ce qui marche pour de vrai, aujourd'hui, sans rien ajouter :
· La base de données Supabase, dans les deux sens (navigateur en direct par REST, serveur en SQL).
· Le chemin d'argent Stripe, de bout en bout, en mode LIVE — la clé publiable est posée, la trousse est installée, les routes sont montées, 5 forfaits sont définis.
· Le chat des agents, par llm_connector : 8 fournisseurs d'IA prêts, chacun s'allume dès que sa clé arrive.
· Le géocodage : il fonctionne SANS aucune clé, grâce au repli automatique sur OpenStreetMap.
· Le serveur MCP : des agents externes (Claude Desktop, n8n) peuvent réellement se brancher et appeler 12 outils.
· Deux guichets gardés par authentification (external_proxies 21 routes, connectors 23 routes) qui centralisent la sortie vers l'extérieur au lieu de laisser chaque module appeler dans son coin.
· L'envoi de courriels avec trois fournisseurs interchangeables et bascule automatique.
· La liaison Flinks aux 8 grandes banques canadiennes : le code HTTP est réel et testé par un test de contrat.

Et une bonne nouvelle sécurité : aucun secret réel n'est versionné. Les deux clés trouvées en clair sont des clés publiables, faites pour être exposées. Le .gitignore protège bien .env, .env.local et .env.production.

Ce qui manque

Du plus bloquant au moins :

1. LA BLOCKCHAIN NE TOURNE PAS. C'est le trou le plus grave, parce que c'est le seul qui trompe. Les 14 routes Hedera sont montées, 22 fichiers importent le service, la documentation annonce Hedera dans la pile — mais aucune des trois trousses (hedera-sdk-py, hiero_sdk_python, hedera) n'est dans les requirements. Résultat : hedera_service.py:168 bascule en mode simulation et 15 branches renvoient de fausses transactions. Un appel à /token/mint répond « succès » sans rien frapper. Tant que la trousse n'est pas installée, l'UR COIN n'existe que dans la base locale.

2. TWILIO EST MONTÉ MAIS N'A PAS SA TROUSSE. Même maladie, plus petite : le routeur est monté (main.py:2011), le service vérifie les 6 variables d'environnement, mais twilio n'est dans aucun requirements — les appels lignes 173 et 209 planteront à l'import. La vérification _require() teste les clés, pas la trousse. C'est le piège classique : ça a l'air configuré, ça casse à l'usage.

3. LA DOCTRINE CHE·NU MENT SUR LE CODE. docs/adr/2026-05-24… tranche (décision D9) « prod live active via CHENU_API_URL + CHENU_API_KEY ». Mesure : ces deux variables ne sont lues par AUCUN fichier .py ni .js du dépôt. Elles peuvent être posées sur le serveur, elles ne changeront rien. Il n'y a pas de client HTTP vers CHE·NU. C'est déclaratif.

4. DES CLÉS D'API DANS LE NAVIGATEUR. frontend/js/connector-hub.js:509-522 écrit l'objet config — qui contient apiKey — en clair dans localStorage. Toute extension de navigateur, tout script tiers chargé sur la page peut les lire. Aucun des 44 connecteurs n'est branché aujourd'hui, donc rien n'est exposé pour l'instant : la faille est en attente d'usage, pas en train de fuir.

5. DEUX SYSTÈMES LLM EN PARALLÈLE, ET LE PLUS BEAU N'EST PAS BRANCHÉ. llm_router.py (1196 lignes, budget, repli, choix du moins cher) nomme 19 fournisseurs mais n'en câble que 4 ; les 15 autres — Anthropic compris — renvoient littéralement « [Mock response from …] ». Pendant ce temps c'est llm_connector.py (653 lignes, 8 fournisseurs réels) qui sert les utilisateurs. Le risque : un développeur croit brancher Anthropic dans le routeur et reçoit du faux texte sans erreur.

6. DEUX CHEMINS STRIPE INDÉPENDANTS. payments.py et external_proxies_router.py touchent tous deux Stripe, montés séparément. Ce n'est pas une doctrine, c'est de la duplication — deux endroits à corriger, deux endroits à sécuriser.

7. LES RAILS D'ARGENT AT·OM PAY SONT ORPHELINS. money_adapter_registry.py (5 rails) n'est importé par aucun routeur — uniquement par lui-même et par son test. Le code est propre, personne ne l'appelle.

8. LE CATALOGUE MÉDIA EST UN CATALOGUE. 16 fournisseurs vidéo/voix/3D déclarés, zéro appel réseau — le module le dit lui-même. À lire comme une liste de courses, pas comme une capacité.

Se tient avec : L'économie et la trésorerie — Hedera, Stripe et Flinks sont les rails par lesquels la valeur entre et sort ; le registre AT·OM Pay (money_adapter_registry) attend d'être branché à ce domaine. · Les agents et orchestrateurs — Nova, Aria, Orion passent tous par llm_connector.py ; sans clé LLM posée, ils ne pensent pas. · La base de données et la persistance — Supabase est à la fois une connexion externe et le socle de tout le stockage ; le navigateur y écrit en direct, ce qui court-circuite le backend. · La sécurité et la souveraineté — les deux guichets gardés (external_proxies_router, connectors) sont la membrane de sortie ; le localStorage de connector-hub.js est le trou dans cette membrane. · Le déploiement — les réécritures de vercel.json sont ce qui rend le backend HTTP joignable depuis un site HTTPS ; sans elles, aucune connexion ne marche en ligne. · Babel et le décodage — babel_fractal_treasury_consumer.py lit HEDERA_LIVE_MODE, donc le décodeur dépend de l'état de la blockchain. · Le MCP et le bureau d'architecte — le serveur MCP est une porte d'ENTRÉE (des agents externes viennent chez vous), à l'inverse de tout le reste de ce domaine.

Les services internes — ce qui tourne pour le système lui-même (bus de messages, pouls bio, stigmergie, immunitaire, ouvriers de fond, observabilité)

C'est la plomberie du système : le réseau nerveux par lequel les morceaux se parlent (le bus de messages), le cœur qui bat et déclenche les tâches répétitives (le bio-tick), et les ouvriers de fond qui vont chercher des données dehors. Personne ne « visite » ces services — mais si l'un s'arrête, des pans entiers du système cessent silencieusement de vivre.

19 livrées · 8 en attente · 0 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent solidement, et le propriétaire peut compter dessus.

Le bus d'événements backend est le meilleur morceau du domaine : 649 lignes, importé par 143 fichiers, trois tests dédiés, un vocabulaire officiel de 443 noms d'événements réparti sur 9 catalogues dont plusieurs se vérifient eux-mêmes à l'import (si quelqu'un ajoute un topic sans mettre le compte à jour, le serveur refuse de démarrer). C'est de l'infrastructure adulte.

Le cœur backend tient aussi. Une seule boucle à 432 ms, démarrée sans condition (main.py:415 — quelqu'un a pris soin de la sortir d'un bloc try qui pouvait la faire échouer silencieusement, le commentaire ligne 409 le dit), 17 consommateurs réellement branchés, un arrêt propre au shutdown. Deux tests unitaires le couvrent.

Le démarrage lui-même est sérieux : 43 blocs de câblage dans le lifespan, chacun encapsulé pour qu'un échec ne tue pas le serveur, 7 ordonnanceurs démarrés et 7 arrêtés proprement, un audit d'uptime au boot (main.py:584) qui dit ce qui a démarré. Et les 10 ouvriers de moisson externe ont une vraie garde anti-SSRF (base_worker.py lignes 30-60) avec son test — quelqu'un a pensé à la sécurité avant qu'on la lui demande.

Ce qui manque

Du plus bloquant au moins.

1. Le système immunitaire n'existe pas côté serveur. Zéro fichier. Toute la défense (704 lignes de immune-system.js, plus 1195 lignes de gardes cutanée, entérique et cortisol) vit dans le navigateur — donc chez le visiteur, désactivable, et absent dès qu'on ferme l'onglet. Et sur les 4 modules, 3 ne sont chargés par aucune page. Un système qui se dit protégé ne l'est ici que sur 3 pages sur 122.

2. Le bus frontend n'a pas de catalogue. 2316 noms d'événements uniques sont écrits en clair, dispersés dans 1157 fichiers, sans liste officielle nulle part. Une faute de frappe dans un nom d'événement ne casse rien : elle rend juste le message invisible, pour toujours, sans erreur. C'est le défaut le plus insidieux du domaine.

3. Le frontend n'est presque pas branché. 337 fichiers JS parlent au cœur — 7 pages seulement le chargent. 1157 fichiers parlent au bus — 22 pages le chargent. La majorité de ce code est écrit pour un système qui n'est allumé nulle part.

4. La stigmergie backend n'a pas de service. Les 836 lignes vivent entièrement dans le routeur. Aucun autre morceau du système ne peut déposer une piste sans passer par une requête HTTP à lui-même.

5. Environ 4600 lignes dorment. Le plus gros : events_service.py, 498 lignes complètes avec zéro importeur ; et arq_job_queue, un vrai pool d'ouvriers Redis dont le mot « arq » n'apparaît même pas dans main.py.

6. L'observabilité est presque invisible. observability_service.py — le seul endroit qui rassemble le battement, la flamme active et le chaos — n'a aucune URL. Il n'est joignable que par l'outil MCP. Le propriétaire ne peut pas demander « comment va mon système ? » depuis un navigateur.

7. La doctrine dérive du code. Sur les 3 chiffres que j'ai pu recouper avec CLAUDE.md, les 3 sont faux : 232 topics annoncés contre 443 mesurés, « 1360 topics dans message-bus.js » qui est en fait le nombre de lignes du fichier, et le « pouls 4,44 s » qui est une cadence secondaire parmi cinq.

Se tient avec : Babel — le décodeur consomme et publie sur le bus (39 topics propres), et son ouvrier bio fractal est démarré par le même lifespan (main.py:633) · L'économie et la trésorerie — les consommateurs qui frappent l'UR COIN sont abonnés au bus au démarrage (main.py:600-700), et la ristourne bat sur CYCLE_9 · Les agents et orchestrateurs — l'équipe royalties (9 membres) est le plus gros consommateur du cœur backend · Le frontend et les pages HTML — c'est là que le domaine se perd : le code est écrit, les pages ne le chargent pas · La base de données — les pistes stigmergiques et le magasin persistant ont leur vidange planifiée au boot (main.py:404) · La sécurité — la garde anti-SSRF des ouvriers de moisson, et l'alerteur d'incidents démarré main.py:592

Les systèmes collaboratifs (fils/threads, équipes, espaces de travail, communauté, messages, votes, projets de territoire)

C'est la partie d'AT·OM qui permettrait à plusieurs personnes de travailler ensemble : ouvrir un fil de discussion, monter une équipe, partager un espace de travail, s'envoyer des messages, voter sur un besoin local, suivre un projet de territoire. Aujourd'hui la tuyauterie est posée et branchée — 16 routeurs et 421 points d'entrée répondent — mais personne ne s'en est jamais servi : les 9 tables collaboratives de la base sont vides à zéro ligne, et la plus grosse partie du code garde ses données en mémoire vive, donc tout disparaît au redémarrage du serveur.

13 livrées · 9 en attente · 4 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent vraiment.

Un : le montage. Les 16 routeurs sont tous inscrits dans backend/app/main.py, aucun n'est mort. Les 421 adresses répondent si le serveur démarre. Le routeur Threads est même le seul du domaine déclaré core=True (main.py:1221), ce qui veut dire que si le fil de discussion casse, le serveur refuse de démarrer — c'est une protection réelle et bien placée, le fil étant présenté comme la source de vérité du système.

Deux : la discipline du repli. Neuf routeurs sur seize essaient d'abord la base puis retombent gracieusement en mémoire quand elle manque (my_team.py compte 43 marqueurs de repli, workspaces.py 16, social_graph.py 16). Résultat concret : même avec 26 tables manquantes, rien ne plante en production. Le système ment doucement plutôt que de tomber.

Trois : la structure du code. Les routeurs sont proprement séparés de leurs services et de leurs couches de persistance, et chaque couche de persistance est réellement importée par son routeur (my_team_persistence par my_team.py, community_legacy_persistence par community.py, social_legacy_persistence par social.py — vérifié un par un). Quand les tables arriveront, le branchement se fera sans réécriture. C'est du travail préparé, pas du travail à refaire.

Et les trois tables de démocratie locale — local_needs, need_votes, territory_projects — sont les seules dont le script de création existe vraiment dans le dépôt (backend/supabase/supabase-schema.sql). Elles sont posées, propres, et attendent.

Ce qui manque

Du plus bloquant au moins, tel que mesuré :

1. Il n'y a aucune donnée. Zéro. Les 9 tables collaboratives existantes affichent count(*) = 0 chacune. Aucun fil n'a jamais été ouvert, aucun espace de travail créé, aucun message échangé, aucun vote déposé. Le domaine n'a jamais servi une seule fois.

2. Vingt-six tables déclarées n'existent pas dans la base, et rien ne les créera. La fonction create_tables() de backend/app/core/database.py:517 n'est appelée nulle part au démarrage — main.py:278 n'appelle que init_db(), qui se contente de se connecter. Pire : les scripts SQL de création n'existent même pas dans le dépôt pour 32 des 35 tables du domaine. Il n'y a donc rien à exécuter, même à la main. C'est le trou le plus lourd : il faut écrire ces migrations avant tout le reste.

3. Toute la mémoire collaborative est volatile. Les trois plus gros moteurs — team_collab_runtime/agent.py:693, social_runtime/agent.py:481, community_runtime/agent.py:266 — rangent tout dans des dictionnaires Python. Le commentaire du code le dit sans détour : « In-memory storage (would be database in production) ». Un redémarrage du serveur efface tous les messages, tous les canaux, tous les sondages, tous les cas de modération.

4. La gestion de projet est bloquée net. project_management_router.py fait 29 appels à la base et n'a AUCUN repli mémoire (0 marqueur mesuré) — contrairement à tous ses voisins. Et ses 7 tables sont absentes. C'est le seul module du domaine qui échoue franchement au lieu de se dégrader en douceur.

5. Il n'y a pas de temps réel. Aucun WebSocket, aucun abonnement Supabase Realtime dans le domaine (grep = 0 sur backend/app/routers/). Un système collaboratif sans canal vivant oblige chaque écran à redemander la page pour voir un message. Le Realtime est pourtant annoncé dans la pile technique du CLAUDE.md.

6. La façade est déconnectée. Les deux seules pages web du domaine, collaboration.html (1595 lignes) et threads.html (580 lignes), ne contiennent aucun appel /api/v2. Ce sont des maquettes. Et six modules JS qui savent, eux, parler au backend — dont social-graph-ui.js avec ses 8 vraies routes — ne sont chargés par aucune page (absents de governance-init.js). Le pont entre l'écran et le moteur n'est pas posé.

7. Le plus gros morceau n'est pas un moteur. La « Collaboration gouvernée » pèse 14 021 lignes et 161 adresses, mais ne touche jamais la base (0 occurrence de sqlalchemy dans tout le dossier) et renvoie des gabarits figés — voir base_packets.py:11-45. C'est un protocole publié en JSON, pas un système qui fait collaborer quiconque. Il occupe 38 % des adresses du domaine pour 0 % de sa capacité de travail.

8. Deux routeurs partagent l'adresse /api/v2/workspaces (workspaces.py monté à main.py:1238, workspaces_stone.py à main.py:2019). Aucune collision franche mesurée aujourd'hui, mais la cohabitation repose sur un détail de typage d'URL et cassera au premier ajout de route.

Se tient avec : Base de données Supabase — le domaine collaboratif dépend entièrement d'elle et 26 de ses tables n'y existent pas ; c'est le point de blocage principal · Authentification / identité — tous les routeurs V68 et knowledge_threads dépendent de get_current_user_id ou get_current_user (Depends dans community_v68_router.py:24) ; sans identité, aucune collaboration nommée · Agents et orchestrateurs — agent_team_composer, agent_team_system et royalty_team font collaborer des agents plutôt que des humains ; même grammaire, autre substrat · Économie / projets — project_generator.py est importé par 16 services économiques (economy_engine, lnis_service, exchange_hub…) : les projets de territoire sont la charnière entre collaboration et économie · MessageBus et catalogues de topics — le domaine n'a aucun canal temps réel propre ; toute vie collaborative devrait passer par le bus, ce qui n'est pas mesuré comme fait · Frontend / governance-init.js — six modules JS collaboratifs sont écrits mais absents du chargeur ; le domaine dépend de ce fichier pour exister à l'écran · Babel — models/babel_community.py déclare babel_communities et babel_user_communities, absentes de la base : la couche communautaire de Babel touche ce domaine sans y être branchée

L'économie — UR, trésorerie, moteur économique, jubilé / ristourne / jachère / compagnonnage, jauge, distribution 40/30/20/10

C'est la partie d'AT·OM qui crée, compte et déplace la monnaie interne (l'UR), et qui décide qui reçoit quoi. Une moitié tourne vraiment (des portefeuilles, des transferts, des ristournes, une frappe bridée par un garde-fou), l'autre moitié est écrite, testée, correcte — mais rien ne l'appelle encore.

15 livrées · 10 en attente · 1 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Le circuit monétaire de base tourne pour vrai. Un usager peut avoir un portefeuille, recevoir de l'UR, en transférer, voir son historique : 66 routes mesurées sur les deux routeurs principaux (46 sur /api/v2/economy-engine, 20 sur /api/v2/economy), toutes montées dans main.py.

La frappe automatique est armée ET bridée. Quatre consommateurs de bus (fractale, temple, crop-circle, graine) écoutent l'énergie captée et frappent de l'UR COIN ; le garde G4 (g4_emission_guard.py, appelé à babel_fractal_treasury_consumer.py:478) plafonne à 1000 UR par jour et met θ à zéro s'il n'y a eu aucune captation réelle sur 24 h. C'est la règle « on ne frappe que ce qu'on capte », et elle est dans le chemin d'exécution, pas seulement dans un document.

La ristourne est le seul organe « doctrinal » réellement branché : quatre flux commerciaux distincts l'appellent (caisse, marchand, grande bourse, marché 3D), elle tourne sur le tick CYCLE_9, et elle persiste.

Les douze catégories de réglages économiques existent bel et bien : douze, ni plus ni moins. C'est le rare endroit où la documentation et le code disent la même chose.

Ce qui manque

1. Trois parts sur quatre de la distribution 40/30/20/10 ne sont jamais versées. À economy.py:339-352, les quatre parts sont calculées et renvoyées dans la réponse, mais seul le 0,40 « agent » passe par _mint. Communauté, stabilité et RCS reçoivent zéro. C'est le trou le plus grave : le système affiche une redistribution qu'il n'exécute pas.

2. Deux formules 40/30/20/10 différentes cohabitent. economy.py:277 dit agent/communauté/stabilité/RCS ; economy_data.py:35-43 dit infrastructure/liquidité/développement/ristournes. Mêmes chiffres, sens opposés. Personne ne peut dire laquelle est la vraie sans trancher.

3. Une contradiction doctrinale non gardée. financing_doctrine.py:31 pose INTEREST_LENDING_ALLOWED = False et refuse le prêt à intérêt — mais les réglages actifs portent « lending / default_interest_rate_annual : 5 % » (economy_data.py:122) et rien n'appelle validate_financing pour l'en empêcher. La doctrine existe ; la garde n'est pas posée.

4. Les quatre grands organes doctrinaux sont écrits mais muets. Jubilé (227 L), jachère (198 L), compagnonnage (167 L), plus les cinq modules de app/services/economy/ (597 L au total : jauge, canaux d'énergie, doctrine de financement, gâchettes du jubilé, rente décroissante). Ensemble : environ 1190 lignes de code correct, couvert par une trentaine de tests, appelé par zéro ligne de production. Trois de ces fichiers écrivent eux-mêmes « EN RÉSERVE, câblage différé ».

5. AT·OM Pay n'a pas de porte. 1068 lignes, 79 tests, aucun routeur monté. Deux modules sur sept seulement sont atteints, et par un chemin détourné (liquidity_bridge).

6. La trésorerie vit encore en mémoire vive. treasury_service.py garde ses portefeuilles dans self._wallets (ligne 134) ; 23 méthodes async base de données coexistent avec les méthodes synchrones RAM. Un redémarrage du serveur peut faire disparaître un état monétaire qui n'a pas été écrit.

7. Le côté écran est mince. Une seule page (dashboard.html) charge l'interface économie, qui n'appelle que 3 des 66 routes. ristourne-store-ui.js, 540 lignes, n'est chargé par aucune page.

Se tient avec : Le bus d'événements et le pouls — sans le tick CYCLE_9 et le bus, la ristourne, le projecteur circulaire et toute la frappe automatique s'arrêtent (main.py:322-347, 600-720) · Babel et le décodage — les consommateurs de trésorerie (fractale, temple, crop-circle) sont dans app/services/babel/ : c'est le décodage qui produit l'énergie qui devient de l'UR · La bioacoustique et le col d'import — FractalPipelineBridge (main.py:648) est le maillon qui fait passer l'énergie captée vers la trésorerie · Hedera / la chaîne — tokenomics_hedera_bridge et l'ancrage canon (treasury_canon_router.py:33), en mode simulé par défaut sauf HEDERA_LIVE_MODE · La gouvernance et la souveraineté — le jubilé exige une ratification au scope civilisationnel (AIPEngineService), et les réglages « requires_vote » (economy_data.py) renvoient au vote · Le mérite et la formation — le compagnonnage et le registre de confiance/compétence (trust_ledger_router.py) portent le mérite qui devrait conditionner l'accès économique · Le commerce et le marché — checkout_system, merchant_service, grand_exchange, marketplace_3d sont les quatre vrais appelants de la ristourne · Le frontend — dashboard.html et presentation-economie.html sont la seule surface visible de ces 66 routes

La mémoire

C'est tout ce qui permet au système de retenir quelque chose et de le retrouver plus tard : une base de 5223 morceaux de texte vectorisés dans Supabase, trois paliers de mémoire (chaud/tiède/froid) côté navigateur, un WOMB qui enregistre les événements de gestation, et une couche de gouvernance qui dit ce qui a le droit d'être mémorisé. Aujourd'hui la partie « écrire » fonctionne surtout en local et en RAM ; la partie « relire intelligemment » n'est branchée nulle part.

13 livrées · 8 en attente · 3 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses tiennent vraiment.

D'abord, les 5223 morceaux dans Supabase. C'est de la mémoire réelle, indexée, protégée par RLS depuis juin. Elle contient le cœur doctrinal du système : 209 morceaux du MASTER-INDEX, les plans et specs, les cosmogonies ancestrales. Elle est là, elle est bonne, elle a survécu à tout.

Ensuite, la mémoire trois paliers du navigateur. Les six modules (chaud, tiède, froid, stigmergique, womb de transition, gestionnaire) sont chargés pour de vrai par governance-init.js, avec des durées de vie nettes : 5 minutes en RAM, 1 heure en localStorage, 24 heures en IndexedDB. Et le palier froid a un débouché qui fonctionne : 363 lignes réellement écrites dans bio_states en production. C'est le seul chemin où une mémoire sort du navigateur et arrive vraiment dans la base.

Enfin, les compartiments (hf-atom-tools/atom_canon/memory/compartment.py). C'est la seule pièce de gouvernance mémoire qui soit à la fois écrite, testée ET appelée depuis un vrai routeur. Les cloisons entre identités existent et fonctionnent.

Le registre fractal vivant (leaves/, modules/, cells/) tient aussi : il donne une carte honnête et à jour du code par étage H0..H7.

Ce qui manque

Du plus bloquant au moins.

1. Le stock et le moteur ne se parlent pas. Les 5223 morceaux existent dans Supabase ; le moteur de recherche sémantique (13e pilier) existe aussi. Ils ignorent l'un l'autre. Le moteur cherche dans une table atom_corpus_embeddings qui n'a jamais été créée, et qui de toute façon ne contiendrait que 5 chunks de démarrage. Le système possède une bibliothèque et un bibliothécaire, dans deux bâtiments qui n'ont pas de porte commune.

2. Le vectoriseur par défaut n'est pas un vectoriseur. Il produit des vecteurs à partir d'un SHA-256 du texte (multi_model_embedder.py:104-109). Deux phrases qui veulent dire la même chose donnent des vecteurs sans rapport. Toute « recherche sémantique » faite dans cette configuration est du bruit propre. Le vrai câblage (bge-m3 et les quatre autres, sur le bureau Hetzner) est écrit, testé, complet — il attend une variable d'environnement, ATOM_EMBEDDINGS_PROVIDER, qui n'est posée nulle part.

3. Cinq tables manquent en base. womb_events, memory_layer_events, memory_layer_snapshots, atom_corpus_embeddings, knowledge_seed_batches. Le code écrit dedans, la base ne les a pas, l'erreur est avalée par un except silencieux, tout part en RAM et disparaît au redémarrage. Le pire signe : kv_store, le filet censé rattraper ces replis, contient 0 ligne.

4. Le WOMB est en trois morceaux qui ne se connaissent pas. La loi doctrinale (law12_womb_perspective.py, S0 fertile ⇄ S9 membrane), le routeur backend (2 routes, une table absente), et le moteur frontend (7 modules, ~3000 lignes, chargés par personne). En prime, le client womb-core.js envoie un format que le serveur refuse — un lot d'événements là où il en attend un seul.

5. Le gardien ne garde rien. memory_governance_service.py applique les 10 Lois de la Mémoire correctement, avec 18 tests qui passent. Aucun routeur ne l'appelle. Aucune écriture mémoire du système n'est aujourd'hui soumise à l'approbation explicite, au scope d'identité ou à la réversibilité. La doctrine est codée, elle n'est pas en travers du chemin.

6. Six dimensions de vecteurs incompatibles circulent (256, 384, 768, 1024, 1536, 2048), et le routeur interroge en 5 largeurs une colonne déclarée à 384.

7. Le miroir atom-fractal-canon est périmé de 324 feuilles et vient d'une autre machine.

Se tient avec : Babel (le décodeur réutilise LocalEmbeddingsClient et déclare viser le même index pgvector 384 dimensions) · Le bureau Hetzner (Ollama :11434 héberge bge-m3 et les 4 autres modèles du BureauEmbeddingProvider — sans lui, pas d'embeddings réels) · Hedera / UR COIN (hedera_anchor_service devrait sceller l'empreinte des vecteurs ; mode 'partial', jamais exercé) · ACMI / atom_canon (compartiments et hiérarchie 7 tiers viennent de hf-atom-tools ; acmi_agent_pool_persistence en dépend réellement) · Supabase / pgvector (unique support persistant réel du domaine — et la moitié des tables attendues n'y existent pas) · Le système bio (memory-cold écrit dans bio_states, la table du système bio : les deux domaines partagent le même tuyau de sortie) · Stigmergie (memory-stigmergic alimente /api/v2/stigmergy/trails) · Le registre fractal (leaves/, modules/, cells/ — c'est lui qui situe chaque pièce de mémoire dans la grammaire H0..H7)

Gouvernance et gardes — ce qui bloque réellement une action dans AT·OM

C'est l'ensemble des serrures du système : ce qui décide si une action passe, s'arrête, ou attend l'accord d'un humain. Il y en a de plusieurs sortes — l'authentification (qui es-tu ?), la membrane (as-tu mérité de voir ça ?), les 3 lois de l'Arbre (le système ne décide jamais à ta place), le HTTP 423 « Locked » (bloqué en attente d'approbation), et la garde OPA qui protège la monnaie.

18 livrées · 7 en attente · 2 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Trois choses bloquent vraiment aujourd'hui, et elles sont solides.

1. L'authentification. Sans jeton signé valide, une route protégée renvoie 401, sans exception ni porte dérobée de développement (backend/app/core/auth.py:200-212). 1331 points d'application dans les routeurs.

2. La monnaie est fail-close. Frapper de l'UR ou du crédit passe obligatoirement par une vérification de gouvernance ; si le serveur de politiques est absent, en erreur ou injoignable, la frappe est REFUSÉE, pas laissée passer (backend/app/services/ur_engine.py:145-150, backend/app/services/treasury_service.py:928-935). C'est la garde la mieux faite du système, et elle a été corrigée exprès dans ce sens.

3. Le 423 et les points de contrôle. 68 endroits du code s'arrêtent et attendent un humain plutôt que d'agir. Le routeur d'approbation (backend/app/routers/checkpoints.py, 15 endpoints) est complet, monté, vérifie la propriété et l'expiration. C'est l'incarnation de la première loi de l'Arbre : le système propose, l'humain décide.

Tiennent aussi, plus discrètement : la porte des endpoints internes (fail-closed en 404 si le jeton n'est pas configuré), la membrane mémorielle (verdicts permeable / gestating / sealed, réellement appelée par les 3 organes MCP), le plafond de confiance interprétative à 0,3 hors S1, et le tampon discipline_flag présent sur 3045 sorties.

Ce qui manque

Du plus bloquant au moins, tel que mesuré :

1. La RLS n'est pas dans le chemin réel. Les 257 migrations Alembic — celles qui construisent vraiment la base — ne contiennent aucune règle de sécurité par ligne. Les 132 politiques écrites vivent dans des fichiers .sql à part (backend/supabase/, frontend/sql/) que rien dans le dépôt n'applique. Conséquence : la séparation entre citoyens repose entièrement sur le code Python, pas sur la base. Une seule requête qui oublie un filtre user_id expose tout.

2. La porte globale « auth par défaut » est éteinte. Le mécanisme est écrit, testé, branché en middleware — et sort immédiatement parce que ATOM_AUTH_REQUIRED_BY_DEFAULT_ENABLED vaut false et n'est posé nulle part. Tant qu'elle est éteinte, 44 fichiers de routeur sur 343 restent ouverts.

3. Les 24 politiques OPA ne sont jamais évaluées. Aucun serveur OPA n'est démarré par le dépôt (adresse par défaut : localhost:8181) et le middleware est éteint. Effet paradoxal : la monnaie est bien protégée (fail-close), mais par l'ABSENCE du serveur, pas par les règles. Le jour où quelqu'un démarre OPA sans les bonnes politiques, la protection change de nature sans prévenir.

4. L'ACL du bus n'empêche rien. Elle est réellement appelée (event_bus.py:466) mais en mode OBSERVE : elle journalise et laisse passer. N'importe quel module peut encore émettre treasury.mint ou governance.vote.cast. Il faut BUS_ACL_ENFORCE=1.

5. Les 12 lois canon η ne gardent presque rien. 7 sur 12 existent en code, et une seule (loi 4, anti-S3) traverse jusqu'au runtime. Les autres sont exposées en lecture par canon_router.py. Ce sont des lois consultables, pas des lois appliquées.

6. Les paliers de souveraineté ont un défaut permissif. Tout utilisateur inconnu obtient le palier 1 plutôt qu'un refus (sovereignty_dep.py, politique MVP assumée), et le registre est un PersistentDict « best-effort » : si la base tombe, les paliers vivent en mémoire seulement.

7. Deux vérifications constatent sans bloquer. master_mind.py:478 journalise une violation des lois de l'Arbre puis retourne success=True. Et la garde 5 de la porte d'accès canon (distance géomagnétique) est explicitement un simulacre.

8. Les 47 fichiers de gardes côté navigateur ne gardent rien — ils s'exécutent chez le visiteur. Ne jamais compter dessus pour une décision.

Se tient avec : Économie et trésorerie — la garde OPA fail-close protège la frappe d'UR et de crédit (ur_engine.py, treasury_service.py) ; c'est le seul endroit où la gouvernance bloque de l'argent réel · Agents et orchestrateurs — Nova (nova_pipeline.py) est le seul pipeline qui applique vraiment les lois de l'Arbre et Foundation avant d'exécuter ; les autres agents ne passent pas par là · Mémoire et WOMB — la membrane mémorielle (membrane_service.authorize) est la garde du corpus doctrinal, appelée par les 3 organes MCP (bureau, live organs, repo tools) · Babel Decoder — porte la seule loi canon η exécutée en runtime (loi 4 anti-S3) et le plafond de confiance interprétative à 0,3 · Base de données Supabase — le trou RLS relie ce domaine directement à la couche de persistance ; sans RLS la séparation entre citoyens dépend entièrement du code applicatif · Bus d'événements — l'ACL par topic (bus_acl) est la serrure du système nerveux ; en mode observe elle laisse passer les 232 topics backend · Frontend — 47 modules JS de gouvernance qui AFFICHENT l'état des gardes sans jamais pouvoir en imposer une

Les Écritures et les temples (corpus restauré, Décodeur de Babel, registre des sites-temples)

C'est la mémoire textuelle et la mémoire de pierre du système : d'un côté un corpus de 176 altérations d'écritures anciennes documentées avec l'état reçu et l'état restauré côte à côte, de l'autre un registre de 1975 sites-temples du monde entier. Entre les deux, le Décodeur de Babel — un moteur qui mesure le déplacement de sens d'un texte modifié et l'énergie d'un lieu.

17 livrées · 6 en attente · 2 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

Le corpus des Écritures est la pièce la plus solide de tout ce domaine, et probablement la plus honnête du dépôt. Les 176 records sont vérifiables au comptage, un test automatique recompte les statistiques au lieu de croire ce qui est écrit, le manifeste sert de point d'entrée unique pour qu'aucune strate ne soit oubliée, et la discipline est appliquée sans tricher : quand aucun manuscrit n'atteste l'état antérieur, le champ reste vide plutôt que rempli d'un faux original (Testimonium Flavianum, Marcion, 1 Thess 2:14-16). Les deux pages publiques recomptent le corpus en direct au lieu d'afficher un chiffre écrit en dur — ce qui veut dire qu'elles ne peuvent pas mentir en vieillissant.

Le moteur de mesure tient aussi. Le mode Écritures (563 lignes) est un cœur pur, testable sans base ni modèle, avec 5 canaux de détection dont le canal « témoin » qui est le seul capable d'attraper une interpolation qui imite le style de son texte-hôte. Il refuse de renvoyer un chiffre inventé : s'il ne peut pas mesurer, il renvoie 503. Sa route publique (POST /api/v2/babel/ecriture) est bien montée.

Côté temples, ce qui tient c'est le recensement et la traduction. Les 1975 sites sont comptés juste, chargés au démarrage du backend, et surtout la table pivot id-crosswalk réconcilie 5 registres qui vivaient séparés — 136 pilotes frontend sur 136 retrouvés, 78 nœuds de circulation sur 78. Les 136 pilotes JS sont bel et bien chargés par le navigateur (governance-init.js:655), après avoir passé une période où personne ne les appelait. 112 routes HTTP sont montées et 1109 tests couvrent Babel.

Ce qui manque

1. Le trou le plus bloquant : les temples ne sont pas encodés. 131 sites sur 1975 portent un Hz — 6,6%. Le reste est une liste de noms. Et la cause est en amont : 1833 sites n'ont même pas de coordonnées, et sans coordonnées le décodage ne peut pas commencer. La chaîne est : coordonnées → décodage Gemma → adresse fractale. Elle est cassée au premier maillon.

2. La moisson est là et dort. 146 décodages uniques attendent sur disque depuis le 13 juillet, rapatriés du bureau Hetzner, avec un README qui dit explicitement qu'ils attendent un feu vert. Les intégrer ferait passer l'encodage de 131 à environ 270 sites — une multiplication par deux, sans nouveau calcul.

3. Le corpus des Écritures ne parle pas au moteur. Les 176 records sont lus par deux pages web et un test, point. Aucun service backend ne les charge. Le Décodeur sait mesurer une altération, le corpus contient 176 altérations mesurables, et rien ne relie les deux automatiquement. La boucle vertueuse n'est pas fermée.

4. Rien n'est en base. Zéro table SQL pour les 1975 sites. Tout vit en fichiers JSON sur disque — donc pas de requête, pas d'index, pas d'écriture concurrente, et un fichier de 1 Mo relu en entier à chaque démarrage.

5. Des écarts entre l'annonce et le réel, mesurés : 40 tables Babel au lieu de 45 annoncées ; 39 topics de bus au lieu de 36 documentés ; 63 modules de service au lieu de 59. Rien de grave en soi, mais ça prouve que le CLAUDE.md ne peut pas servir de source de vérité.

6. Une incohérence à l'intérieur d'un même fichier : le registre maître répartit 1061 sites par région alors que sa liste en contient 1761. 700 sites sont géographiquement nulle part.

7. Le classement par famille couvre 27% du corpus. 1431 sites sont dans le fourre-tout.

8. La couverture varie selon la porte d'entrée : le décodeur de temples ne voit que les 112 fichiers de data/temples/, le registre Mirror Earth ne voit que 52 sites canoniques, la bibliothèque 183 GLM. Trois portes, trois périmètres, aucune ne voit les 1975.

9. Le rapport de calibration du détecteur (17 détections sur 31) est un constat figé de juillet, pas une mesure qui se rejoue.

Se tient avec : Trésorerie / économie UR COIN — les temples-batteries minent : babel_temple_treasury_consumer.py et crop_circle_treasury_consumer.py sont branchés au démarrage (main.py:700-703) ; réserve UR COIN cumulée mesurée à 1920,1 sur 6 sites · Bus de messages interne — Babel publie 39 topics (bus_topics.py) qui alimentent l'Observatoire MPAL et la boucle fractale ; c'est par là que les Écritures et les temples parlent au reste du système · Cohérence géographique et QG — proximity_graph.py et temple_coherence_witness.py lisent le registre maître pour bâtir les arêtes du réseau ; node_registry_bootstrap.py l'injecte au démarrage (main.py:809) · Bibliothèque universelle — bibliotheque_service.py (783 l.) transforme les temples décodés en livres lisibles ; 6 routes, montées main.py:1690 · Frontend / pilotes de temples — 136 modules JS chargés via governance-init.js:655, qui émettent les arêtes de résonance sur le bus du navigateur · Crop circles et matrice 27 — temple_crop_circle_bridge.py et open_web_matrix_router.py partagent le même socle Babel · Décodeur de la pierre (stone_*) — 5 tables SQL et 13 topics de bus, couche sœur des temples côté inscriptions

Les systèmes WOMB — la matrice gestationnelle

Le mot « womb » recouvre deux choses differentes, et il faut les separer sans quoi on se raconte une histoire. Ce qui tourne vraiment est un journal : une table, deux routes, une chose entre et ressort identique — rien ne lui arrive dedans. Ce qui porte reellement la doctrine est ailleurs, dans un petit organe de 103 lignes qui, lui, tient le discours au complet.

Et la vraie matrice gestationnelle existe — 1 139 lignes, neuf etapes, trois trimestres au ratio phi, un certificat de naissance en sortie. Elle est ecrite, correcte, testee. Aucune page ne la charge.

8 livrées · 3 en attente · 3 déclaratives

L’inventaire

Les chiffres, mesurés

Ce sur quoi vous pouvez compter

La membrane est le plus beau morceau du depot : 103 lignes pures, injectables, testables sans base de donnees. La distinction entre en gestation (pas encore) et scelle (jamais) est une vraie idee, correctement codee.

Le repli du routeur est propre — base d'abord, retour arriere explicite, memoire ensuite. Et la Loi 12 est le seul endroit du systeme qui definit S0 et S9 en code executable.

Ce qui manque

Le womb ne gestationne pas. Le champ « phase » est accepte puis jete — un mensonge poli.

La vraie matrice est debranchee. 1 139 lignes de moteur correct, qu'aucun chemin ne peut atteindre.

La membrane ne garde pas le womb. Les deux organes canoniques du meme corps s'ignorent.

Le womb n'est pas branche sur la memoire vectorielle.

Se tient avec : La memoire · Gouvernance et gardes · La population interne · Les etages de cohabitation