Les planches d’ancrage · série II · feuille 15 / 19

Entrer

ENTRER — le rite naît en une transaction, et referme six portes derrière lui

Planche 15 · Entrer
20 pièces · 11 bâties · 7 partielles · 2 absentes · 0 non établies
Planche 15 — Entrer

ouvrir la planche en plein écran → · 20 pièces · 12 traverses · 8 marges

La thèse une ligne, écrite dans la matière

Le nouveau venu franchit une porte unique et naît proprement — compte, sceau du pacte et deux faces de position en UNE transaction — puis le rite, correctement accompli, lui FERME six portes qu'un compte ancien sans dossier traverse encore : le seul organe qui pourrait les ouvrir est bâti, éprouvé, et n'a aucune main dans tout le dépôt.

ce que la figure ancre
La figure que la planche rassemblée mettait au centre — « un rite à trois temps » — n'ancre presque rien : c'est un compte liturgique imposé du dehors, et quelqu'un qui ne connaît pas déjà le système n'apprend pas d'où viennent les trois. Deux figures, elles, ancrent une vraie fonction. (1) « TU NE T'INSCRIS PAS, TU NAIS » (le sceau, frontend/inscription.html:434) ancre une propriété technique exacte et vérifiable : l'atomicité. Naître, accepter le pacte et recevoir ses deux faces de position sont UNE transaction avec UN commit (auth_service.py:147-269) ; on ne peut pas être à moitié né. La parabole ne décore pas le mécanisme, elle le NOMME — et elle interdit la réparation paresseuse (« si le sceau échoue, le compte existe quand même » est exactement ce que le code refuse désormais, :169-172). (2) « DEUX POSITIONS SANS DROIT » ancre la distinction exister / être autorisé : les faces physical et numerical sont inscrites en_attente, et seul un juge peut les rendre autoritatives. Cette figure-là est si juste qu'elle rend visible sa propre blessure : le juge est écrit, éprouvé, et n'a pas de main. En revanche « la porte unique » est une image honnête mais faible — derrière l'unique bouton il y a immédiatement deux voies, et le livre promet au seuil une conversation qui n'y est pas.

la même figure, ailleurs
⚑ « La grande architecture explique la plus petite » — et ici c'est l'inverse qui éclaire : LE RITE D'UNE SEULE PERSONNE REDIT, en miniature, la figure la plus coûteuse de tout AT·OM — ce qui est BÂTI ET MURÉ. Trois mécanismes différents, une seule forme. (a) À l'échelle de la matière : materialize_upward_propagation est le seul organe qui déduise la portée de la POSITION de l'émetteur, et il est inatteignable parce que deux verrous sur cinq sont écrits en dur à False (fractal_bio_tick_worker.py:423-424). Mur = une constante. (b) À l'échelle du monde : resolve_descendants reste dormant PAR DÉCISION, pour que le rythme de la descente soit la gradation (world_canon.py:1049-1058). Mur = un arbitrage assumé. (c) À l'échelle d'UNE personne, ici : agrant_membership, amark_face_authoritative et aregister_contract sont complets, testés, et murés par l'ABSENCE D'UNE ROUTE. Mur = un oubli. Les trois se ressemblent à la lecture — « ça existe et ça ne tourne pas » — et un seul est un défaut. C'est pourquoi un audit qui compte les organes dormants sans dire PAR QUOI chacun est muré ne mesure rien : il mélange une décision, une constante et un trou. Et la même figure encore, à l'échelle du nom : une arité déclarée au canon mais incomplète dans le gabarit qui la reproduit ne produit pas des oublis, elle produit une contrefaçon à l'échelle — ici, un rite déclaré à trois temps dont le gabarit n'en câble que deux.

Les marges 8 arbitrages ouverts, entiers
  • ⚑ CE QUE J'AI RÉFUTÉ, PIÈCE PAR PIÈCE. Trois BATI annoncés ne tiennent pas : ÉTAPE 11 « La petite équipe déjà là » est ABSENT (6 déclarations d'activeAgents, 0 lecteur dans tout frontend/) · ÉTAPE 4 « TROIS écritures » est un compte faux (4 appels, 5 lignes) · ÉTAPE 14 « l'ancrage » est PARTIEL (200 + persiste=false sans base). Deux sont corrigés à la baisse : ÉTAPE 12 (le point 0 est une chambre, pas un point 0 au pluriel) · ÉTAPE 10 (la carte n'affiche pas la pièce, et il y a 6 noms, pas 5). Un libellé est faux sans que la fonction le soit : ÉTAPE 3 « pas sur la page » — la case EST sur la page.
  • ⚑ LE BON FICHIER. La planche rassemblée mesurait index.html comme page d'accueil. frontend/vercel.json:153-155 réécrit « / » vers landing-unifie.html. Le verdict « porte unique » survit au changement de fichier — mais il a failli être juste pour la mauvaise raison. Loi : avant de compter les portes d'une page d'accueil, nommer le fichier que le serveur rend à « / ».
  • ⚑ UN CHIFFRE QUE J'AI RECALCULÉ, ET UN QUE J'AI REFUSÉ DE REPRENDRE. Recalculé : le SHA-256 du Covenant (59b65c2f…f9eb, 12 350 octets après CRLF→LF) — identique à backend/app/schemas/auth_schemas.py:26, donc la garde de démarrage main.py:574 désigne bien ces mots. Refusé : « ascendants() / correspondances() n'ont AUCUN appelant » (fiche gains-2026-08-01, répété en trinity_geo_router.py:216) — correspondances() EN A UN depuis, trinity_geo_router.py:347, sur une route montée. La fiche a vieilli ; son commentaire de code aussi.
  • ⚠ NON ÉTABLI : combien de personnes sont réellement nées. Lecture seule, aucune base interrogée — je ne sais pas si person_position_bindings, covenant_runtime_records ou atom_positions portent une ligne en production. La mesure de juillet (« atom_positions = 0 ligne », citée par trinity_geo_router.py:209-212) n'est pas la mienne et je ne la reprends pas. Ce qui manque pour trancher : une requête nommant son hôte et sa base, selon la règle du dépôt.
  • ⚠ Divergence d'échelle, à arbitrer : « Relais » (frontend/onboarding.html:947, :956 ; frontend/js/avatar-societal.js:4) n'existe pas dans backend/app/core/engagement.py:44-48, dont le second barreau est PARTICIPANT. Deux échelles à quatre barreaux qui ne se recouvrent pas sur le barreau 2 et 3. Aria annonce à chaque nouveau venu une échelle que le serveur ne connaît pas.
  • ⚠ Doc↔code dans un seul fichier : backend/app/routers/invitations.py:512 annonce « Stockage in-memory » ; :558-562 refuse sans base. La docstring décrit un état antérieur du même fichier.
  • ⚠ La garde de l'échelle d'engagement est presque inemployée : require_engagement n'apparaît que dans 2 fichiers hors de son module (conseil_circles.py, knowledge_gate/porte.py — 3 occurrences, périmètre backend/app/). Le statut Observateur est exact et ne ferme presque rien ; ce sont les 6 portes de l'appartenance qui ferment, et elles ferment au mauvais endroit.
  • ⚑ UN GESTE, SI UN SEUL DEVAIT ÊTRE FAIT. Pas « bâtir le juge » — il est bâti et éprouvé. Lui donner UNE porte, et décider qui la tient. Tant qu'elle n'existe pas, chaque naissance correcte ajoute une personne à la marge, et le rite fabrique mécaniquement ce qu'il prétend abolir.
Les blancs déclarés ce que la mesure n’a pas pu voir

Ce que cette planche NE dit pas : (1) elle ne dit pas combien de personnes sont nées — aucune base n'a été interrogée, aucune prod touchée ; les états « BATI » portent sur le code au commit cb3667082, pas sur un flux observé ; (2) elle ne dit pas que les 6 refus d'appartenance sont un bug — ils sont fail-close et corrects ; c'est l'absence du troisième temps qui les rend punitifs ; (3) elle ne dit pas que la chaîne est atteignable en production : les 6 routeurs du rite sont montés dans backend/app/main.py au commit, mais tous en core=False, et je n'ai pas lu le registre de démarrage d'un serveur vivant ; (4) elle ne dit pas que « Mon Espace » est un oubli du livre plutôt qu'un choix — seulement qu'il est le défaut du code et absent de la page ; (5) elle ne reprend AUCUN chiffre de fiche sans l'avoir confirmé : les deux chiffres repris d'ailleurs — l'empreinte du Covenant et « point0_ref jamais lu » — sont l'un recalculé par moi, l'autre re-balayé sur les deux arbres sous backend/ plus hf-atom-tools, scripts et frontend.

Les traverses 12 relations, de source à source
landing-unifie.html (la porte)
un seul lien de sortie vers le rite, répété deux fois sur la page servie à « / »
→entrer.html (le seuil)frontend/vercel.json:153-155 · frontend/landing-unifie.html:143, :483
auth.html (porte de retour)
refus + redirection : la connexion ne peut plus faire naître
→inscription.html (le rite)frontend/auth.html:690-700
inscription.html
le pacte voyage DANS l'envoi qui crée ; le serveur refuse sans lui
→POST /api/v1/auth/registerfrontend/inscription.html:910-927 · backend/app/schemas/auth_schemas.py:104-123
register
une seule transaction, un seul commit : si le sceau ou le dossier échoue, le compte n'existe pas
→users · covenant_runtime_records · person_position_bindings ×2 · refresh tokenbackend/app/services/auth/auth_service.py:147-269
register
SECONDE transaction, après le commit — le compte peut exister sans la demande
→POST /api/v1/inscriptionsfrontend/inscription.html:962-979 · backend/app/routers/inscriptions.py:830-852
onboarding.html completeOnboarding
fail-close à deux accusés de base avant toute suite
→POST /api/v2/world-canon (monde + nœud point0)frontend/onboarding.html:1037-1055 · frontend/js/profile-manager.js:611-613 · frontend/js/atom-world-canon-store.js:317
onboarding.html
dernière barrière : 503 si la base manque, le client exige source='db'
→POST /api/v2/onboarding/completefrontend/onboarding.html:1064-1095 · backend/app/routers/onboarding.py:103-148
onboarding.html
premier et seul producteur d'ancrage personnel — mais rend 200 avec persiste=false sans base
→POST /api/v2/trinity-geo/ancrerfrontend/onboarding.html:1144-1158 · backend/app/routers/trinity_geo_router.py:272-277 · backend/app/services/position_registry.py:113-114
person_position_bindings (en_attente)
le seul passage de en_attente à autoritative — aucun appelant, aucune route
→amark_face_authoritative / aregister_contract / agrant_membershipbackend/app/services/person_position_membership_authority.py:889, :934, :1015 (0 appelant applicatif sur backend/app + 29 racines hors app + hf-atom-tools + scripts + frontend)
avalidate_active_membership
403 membership_not_granted pour qui a un dossier sans appartenance ; laissez-passer pour qui n'a pas de dossier
→les 6 surfaces qui l'interrogentbackend/app/services/person_position_membership_authority.py:1196-1209 · fractal_websocket_router.py:103 · canon_coherence_router.py:173 · fractale_communautaire.py:161 · babel/fractal_pipeline.py:610 · fractal_scope_guard.py:86 · relation_mutuelle_service.py:195
profile-manager TEMPLATES.activeAgents
déclaration de la « petite équipe » — aucune relation : 0 lecteur dans tout frontend/
→n'importe quel créateur d'agentsfrontend/js/profile-manager.js:61, :72, :83, :94, :105, :116
register_router(core=False)
montage facultatif : un ImportError les retire au démarrage sans arrêter l'application
→les 6 routeurs du ritebackend/app/main.py:1794-1834, :1837, :1982, :2410, :2474, :2643, :2665
La nomenclature 20 pièces, chacune avec sa source
1ÉTAPE 0 — La porte unique « Entrer »2 liens « Entrer » sur la page servie à « / », 0 lien vers auth.html ou inscription.htmlfrontend/vercel.json:153-155 (rewrite "/" → /landing-unifie.html) · frontend/landing-unifie.html:143 (nav) et :483 (CTA) · confirmé dans le code⚠ CORRECTION de la planche rassemblée : la page d'accueil n'est PAS index.html. index.html porte aussi ces liens (:132, :469) mais vercel.json réécrit « / » vers landing-unifie.html — c'est CE fichier (526 lignes) qu'il fallait mesurer. Le verdict tient sur le bon fichier : la porte est bien unique.
2ÉTAPE 1 — Le seuil : DEUX voies, et le livre dit faux153 lignes, 2 voies, 0 script de conversationfrontend/entrer.html:95 (auth.html « Me connecter »), :105 (inscription.html « M'inscrire »), :152-153 (les 2 seuls scripts : veil-vivante.js, decor-incunable.js) · confirmé dans le codeLe livre promet au pas 1 : « Il ne vous jette pas dans un formulaire — il ouvre une conversation d'accueil » (livre-du-proprietaire.html:365-368). Mesuré : entrer.html est un carrefour à deux boutons. La conversation d'Aria vit DEUX pages plus loin (onboarding.html), APRÈS la naissance. La page de garde du livre (:400-403) avoue la porte d'identification ; elle n'avoue pas que la conversation n'est pas au seuil.
3ÉTAPE 2 — La porte de retour REFUSE de faire naîtrefrontend/auth.html:669-700 — handleRegister ne poste plus, affiche le message et redirige vers /inscription.html (:699, délai 2200 ms) · confirmé dans le code
4ÉTAPE 3 — Le Covenant : exigé au serveur, ET sur la pagebackend/app/schemas/auth_schemas.py:104-123 (champ requis `covenant_accepte` + validator fail-close) · frontend/inscription.html:436 (la case), :835 (vérif client), :917 (voyage DANS l'envoi qui crée) · confirmé dans le codeLe libellé « pas sur la page » est FAUX : la case existe et est vérifiée côté page. Ce qui est juste, c'est que la garde AUTORITATIVE est au serveur — un `false` explicite est refusé aussi franchement qu'une absence (:118-122). La fonction est bâtie ; c'est la phrase qui était trop ronde.
5ÉTAPE 5 — Les deux positions naissent SANS DROIT, et c'est voulu2 faces, statut en_attentebackend/app/services/person_position_membership_authority.py:456-461 (INSERT person_position_bindings, faces 'physical' et 'numerical', binding_status 'en_attente') · :789-795 (le service ne committe ni ne rollback : la transaction appelante possède la naissance entière) · confirmé dans le code
6ÉTAPE 7 — La conversation d'Aria : les QUATRE questions4 questions : rôle · priorités · secteur · taille d'équipefrontend/onboarding.html:422 (phases), :801 interests, :839 sector, :873 team, :900 summary · :378 bouton « Passer » → :1162 skipOnboarding (qui passe quand même par completeOnboarding) · :30-34 scripts chargés explicitement parce que cette page ne charge PAS governance-init.js (commentaire :32-33) · confirmé dans le code
7ÉTAPE 13 — Le registre d'onboarding : la dernière barrièrebackend/app/routers/onboarding.py:22 (prefix /api/v2/onboarding), monté backend/app/main.py:2643 · :103-148 (`_require_db`, INSERT ON CONFLICT DO UPDATE avec FUSION du JSONB :131-141, commit avant de rendre, cache de processus APRÈS le commit :146) · :79-80 (503 fail-close) · frontend/onboarding.html:1078-1080 (le client exige `source === 'db' && completed === true`) · confirmé dans le code
8ÉTAPE 15 — Observateur : déduit, jamais écrit — et l'échelle ne garde presque rienrequire_engagement : 3 occurrences hors de son module, dans 2 fichiers seulement (conseil_circles.py, knowledge_gate/porte.py) — périmètre backend/app/backend/app/services/auth/auth_service.py:126 (`roles=["user"]`) · backend/app/core/engagement.py:52-74 (`_ROLE_TO_LEVEL` — « user » n'y figure pas), :44-48 (l'échelle), :77-88 (`level_of` → OBSERVATEUR par défaut) · backend/app/core/auth.py:61 · confirmé dans le codeDeux marges, pas un défaut de fond. (a) L'échelle backend est Observateur → PARTICIPANT → Contributeur → Gardien (engagement.py:44-48), alors que la carte et Aria annoncent Observateur → Contributeur → RELAIS → Gardien (onboarding.html:947, :956) : « Relais » n'existe nulle part au backend. (b) La garde `require_engagement` n'est invoquée que par 2 fichiers : l'échelle est vraie, et elle ne ferme presque rien.
9ÉTAPE 19 — La destinationfrontend/onboarding.html:501-505 (`/fondateur.html` si role==='fondateur' && status==='approved', sinon `/desktop.html`) · frontend/js/governance-init.js:252 (onboarding-gateway.js chargé) · frontend/js/onboarding-gateway.js:55, :106-116 (lit le statut serveur, redirige vers l'onboarding sinon) · confirmé dans le code
10ÉTAPE 20 — Le sceau du pacte vérifié AVANT la basesha256 = 59b65c2f675a61fea010611c43703e327b80f3390d23ada9a58f21fddc49f9eb · docs/LE-COVENANT-INTEGRAL.md = 12 350 octets après normalisationbackend/app/main.py:570-574 — `verify_covenant_document()` est la PREMIÈRE instruction du lifespan, avant `await init_database()` (:595) · backend/app/schemas/auth_schemas.py:26 (constante), :37-41 (normalisation CRLF/CR → LF), :44-68 (RuntimeError si l'empreinte diverge) · confirmé dans le codeChiffre RECALCULÉ par moi, pas lu dans une fiche : j'ai relu le fichier, normalisé CRLF/CR → LF et hashé — identique à la constante. La version du pacte désigne bien ces mots-là, et le serveur refuse de démarrer sinon.
11⚑⚑ L'INVERSION — naître proprement coûte l'accès6 appelants, tous lecteurs, tous refusants · 0 accordeurbackend/app/services/person_position_membership_authority.py:1179-1209 — AUCUNE liaison → `applicable=False, status="not_applicable"` (:1196-1201) ; liaisons présentes (donc né par le rite) et appartenance non accordée → **403 membership_not_granted** (:1206-1209). Les 6 bouches : backend/app/routers/babel/fractal_websocket_router.py:103 · backend/app/routers/canon_coherence_router.py:173 · backend/app/routers/fractale_communautaire.py:161 · backend/app/services/babel/fractal_pipeline.py:610 · backend/app/services/fractal_scope_guard.py:86 · backend/app/services/relation_mutuelle_service.py:195 · confirmé dans le codeCe que la planche rassemblée ne disait pas, et c'est la pièce qui fait comprendre d'un coup : le dossier de naissance est la CONDITION du refus. Un compte ancien, sans liaisons, traverse les six portes (`not_applicable` est traité comme un laissez-passer — fractale_communautaire.py:166 rend `(True, validation.status)`). Le nouveau-né du rite, lui, est refusé 403 partout. Le mécanisme est fail-close et correct ; c'est l'absence du troisième temps qui transforme une garde juste en pénalité pour qui est né dans les règles.
12ÉTAPE 4 — La naissance : UNE transaction, mais QUATRE écritures1 transaction · 4 appels d'écriture · 5 lignes insérées (le dossier en pose 2)backend/app/services/auth/auth_service.py:147-150 (user+flush), :177-225 (CovenantRuntimeRecord), :246-249 (dossier de position), :267 (refresh token), :269 (l'unique commit) · confirmé dans le code« TROIS écritures » est un compte faux. Recompté au commit : user · sceau · DEUX liaisons de position · jeton de rafraîchissement, sous un seul `commit()`. L'atomicité — ce que la figure veut dire — est vraie ; le chiffre ne l'est pas.
13ÉTAPE 6 — La demande de contexte (inscriptions) : hors de la naissancebackend/app/routers/inscriptions.py:34 (prefix /api/v1/inscriptions), monté backend/app/main.py:2410 · :830-852 (401 sans jeton, 403 si le courriel ne correspond pas, `_require_inscription_db` → 503) · frontend/inscription.html:962 (appelée APRÈS register) · confirmé dans le codeCe n'est pas un maillon de la naissance : c'est une SECONDE transaction, après le commit. Si elle échoue, le compte existe déjà — et la page le dit honnêtement (:973-975 « Votre compte existe, mais votre demande n'a pas été enregistrée. Rien ne vous a été accordé »). Le rite a donc deux commits, pas un ; la planche rassemblée les comptait comme une suite continue.
14ÉTAPE 10 — La carte récapitulative, et la pièce nommée qu'elle n'affiche pas6 pièces nommées, pas 5 : Mon Bureau · Mon Atelier · Ma Classe · Notre Agora · Mon QG · Mon Espacefrontend/onboarding.html:934-949 (la carte : profil · secteur · priorités · équipe · domaines · statut) · frontend/js/profile-manager.js:1042 (`name: profile.firstRoom || template.defaultRoom`), :58/:67/:78/:89/:100/:111 (les 6 pièces nommées) · confirmé dans le codeDeux trous. (1) La carte ne montre PAS le nom de la pièce — le livre dit « votre première pièce porte déjà un nom » et la carte ne le dit nulle part ; le nom part en base comme `world.name`, invisible à l'écran qui l'annonce. (2) Le livre et la planche rassemblée citent 5 noms ; il y en a 6, et la sixième — « Mon Espace », gabarit `curious` — est précisément le DÉFAUT vers lequel « Passer » envoie (onboarding.html:1163).
15ÉTAPE 12 — LE POINT 0 : une chambre à son nom, pas un point 0 au plurielpoint0_ref = la constante 'world_user_home' pour tout le monde (profile-manager.js:1019, :1044, :1079)frontend/onboarding.html:1037-1055 (refus sans world_id ET root_node_id, bouton « Réessayer la création du Point 0 ») · frontend/js/profile-manager.js:611-613 (`requireDatabase: true` sur upsertWorld + upsertNode) · frontend/js/atom-world-canon-store.js:317 (rejette tout `source !== 'db'`) · routeur world_canon monté backend/app/main.py:2665 · confirmé dans le codeLe GESTE est fail-close et honnête : rien n'avance sans deux accusés de base. Mais ce qui est reçu n'est pas « un » point 0 : `point0_ref` vaut la même constante pour chaque personne, et la mesure du 2026-10-01 tient — `point0_ref` n'apparaît dans AUCUN prédicat de lecture du dépôt (seuls `WHERE point0_ref` : les remblais alembic v82_057:168 et :326, qui POSENT la constante). Ce qui est propre à la personne : `world_id = 'world_user_home_' + hash16(sujet)` (:1010) et un nœud `node_kind:'point0'` (:1067). Donc : une CHAMBRE à son nom, oui ; un point 0 énumérable, non.
16ÉTAPE 14 — L'ancrage : « je suis ici » répond 200 quand rien n'a été écritbackend/app/routers/trinity_geo_router.py:61 (prefix /api/v2/trinity-geo), monté backend/app/main.py:2474 · :204-281 (/ancrer : 401 sans jeton :238-241, identité lue du jeton :243-247, 409 si un ancrage actif existe) · frontend/onboarding.html:34 et frontend/js/governance-init.js:482 + :1169 (atom-ancrage.js chargé dans LES DEUX tableaux) · appel :1146, filet 15 s :1145 · confirmé dans le code⚑ LE MAILLON QUI MANQUE, et il est du genre que ce dépôt interdit : base absente → `backend/app/services/position_registry.py:113-114` rend `{enregistre: False, raison: 'no_db_position_refusee'}`, et la route le recopie en `position['persiste'] = False` (trinity_geo_router.py:275-277) puis rend **200 avec `ancrage: true`**. Une réponse de forme « succès » pour un ancrage qui n'existe pas — exactement le repli silencieux que la règle du dépôt réserve à ce qui LIT, jamais à ce qui ENGAGE. ⚠ Et « LE seul producteur » n'est vrai que de l'ancrage PERSONNEL : `/locate` (:148) situe des LIEUX.
17La DEUXIÈME entrée (invitation créateurs) — ce n'est pas une entrée1 seul POST sur 4 routes (creator · stats · admin)backend/app/routers/invitations.py:33 (prefix /api/v2/invite), monté backend/app/main.py:1982 · :505-662 (POST /creator : honeypot, horodatage anti-bot, limiteur fail-close :558-562) · appelée par frontend/creators.html:656 et frontend/landing.html:6217 · confirmé dans le codeElle ne crée NI compte, NI sceau, NI position : elle enregistre une candidature et envoie deux courriels. Aucune naissance ne passe par là — l'appeler « deuxième entrée » prête une fonction qu'elle n'a pas. ⚠ Et sa propre docstring annonce « Stockage in-memory » (:512) alors que le code refuse sans base (:558-562) : doc et code se contredisent dans le même fichier.
18⚑ Toute la chaîne du rite est enregistrée comme OPTIONNELLE6 routeurs du rite, 0 déclaré core=Truebackend/app/main.py:1794-1834 (register_router : un ImportError sur core=False est journalisé en logger.error et l'application DÉMARRE sans le routeur, sauf si REGISTER_ROUTER_STRICT est posé :1795) · :1837 auth `core=False` · :2410 inscriptions · :2643 onboarding · :2474 trinity_geo · :2665 world_canon · :1982 invitations · confirmé dans le codeL'unique route de naissance du système (`POST /api/v1/auth/register`) n'est pas déclarée vitale : une erreur d'import la fait disparaître en silence au démarrage, avec un log d'erreur pour seul témoin. Le rite entier — naître, demander son contexte, s'installer, s'ancrer, recevoir sa chambre — tient sur six routeurs tous facultatifs.
19ÉTAPE 11 — La petite équipe déjà là6 déclarations, 0 lecteur (périmètre balayé : tout frontend/)frontend/js/profile-manager.js:61, :72, :83, :94, :105, :116 — `activeAgents` déclaré dans les 6 gabarits · aucune lecture dans tout `frontend/` · frontend/onboarding.html:1065-1072 (le `complete` n'envoie que role/interests/teamSize/template/sector/language) · confirmé dans le code⚑ RÉFUTATION PRINCIPALE — ce BATI annoncé est une surface sans producteur. `activeAgents` (nova, aria, comptable, rédacteur, designer, monteur, tuteur, modérateur, stratège, RH…) est écrit dans les gabarits et n'est lu par AUCUN fichier. Les autres occurrences du nom dans frontend/ sont des homonymes sans rapport : un id DOM (live.html:999), un Set interne (js/agents-core/nova.js:69), civilizational-mesh.js:1502, dreamcatcher-renderer.js:118. La carte récapitulative n'affiche aucun agent, et rien ne part au serveur. Le livre (:392-396) promet « il est livré avec quelques assistants adaptés à votre profil » : personne ne livre.
20⚑ LE TROISIÈME TEMPS — le juge existe, éprouvé, et n'a aucune main4 méthodes écrivantes · 0 appelant applicatif · périmètre balayé et nommé : backend/app/ + les 29 racines hors app/ + hf-atom-tools/ + scripts/ + frontend/backend/app/services/person_position_membership_authority.py:889 amark_face_authoritative · :934 aregister_contract · :1015 agrant_membership · :1086 arevoke_contract — seuls fichiers qui les nomment : ce service, son unique banc backend/tests/unit/test_person_position_membership_authority_g1.py, et 10 documents sous docs/inventaires/ · confirmé dans le codeAucun routeur ne les expose : rien dans backend/app/main.py ne monte une surface qui confirme une face, enregistre un contrat relationnel-environnemental ou accorde une appartenance. Le commentaire de la naissance l'annonce au futur (auth_service.py:234-236 « Le futur juge serveur accordera scope_membership seulement avec une position autoritative et un contrat valide ») — ce futur n'a pas de porte.
Le lexique de cette planche 16 termes à deux registres · 3 avec un jumeau

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.

point 0Le repère depuis lequel tout est compté pour un sujet : le système le cherche, et quand il ne le trouve pas il écrit qu'il ne l'a pas trouvé.
Face (d'une portée)Le nom sous lequel une même portée se présente selon qui la regarde : la base, l'écran, l'agent, ou le livre du lecteur.
agent (type de nœud)Le genre de place qu'occupe un agent qui agit au nom de quelqu'un, avec l'endroit auquel il est rattaché.
scope_membershipLa table qui dit qui est contenu par qui, avec un contenant différent par portée, et c'est elle qui tranche quand l'adresse dit autre chose.
atom_positionsLa table où survit l'adresse d'une chose, avec son espace et sa portée dans deux colonnes séparées, et la mention de si c'est un corps posé ou un visiteur.
face (enum Face)Elle dit sous quel angle on nomme une sphère : le même objet reçoit un nom différent selon l'angle choisi.
status (green / yellow / red)C'est la note de confiance mise sur l'étiquetage d'un message : vert, le classement est bon ; rouge, il a échoué.
covenantL'entente qu'une personne accepte en entrant, qui fixe ce que le systeme peut faire avec elle et sert de reference a tous les accords qui viennent apres.
riteregistre spirituelUne suite d'etapes qu'on mene jusqu'au bout, et c'est l'ecran d'entree qui refuse d'avancer si une etape manque — pas la base de donnees.
sceau (sceau serveur AIP, Ed25519)Une marque que seul le serveur peut apposer et que n'importe qui peut verifier, parce que la moitie qui verifie est publique et la moitie qui signe ne quitte jamais le serveur.covenant — L'entente qu'une personne accepte en entrant, qui fixe ce que le systeme peut faire avec elle et sert de reference a tous les accords qui…seal_hash (covenant legacy) — Une empreinte rangee a cote d'une acceptation, qui permet plus tard de dire : oui, cette personne a bien accepte ce texte-la, dans cette…
fail-closeQuand l'outil ne peut pas faire le travail pour de vrai, il refuse et dit pourquoi, au lieu de repondre « c'est fait ».
porteUn passage qu'on traverse vraiment : il faut une permission pour le franchir, et il laisse une trace de ce qui est passe.porte (Porte de la Connaissance, knowledge_gate/porte.py) — Elle decide combien d'un document on montre a quelqu'un — de rien du tout jusqu'au texte complet — en six crans, et par defaut elle ne…
porte (Porte de la Connaissance, knowledge_gate/porte.py)Elle decide combien d'un document on montre a quelqu'un — de rien du tout jusqu'au texte complet — en six crans, et par defaut elle ne montre rien.porte — Un passage qu'on traverse vraiment : il faut une permission pour le franchir, et il laisse une trace de ce qui est passe.fenetre — Une vue sur ce qui se passe ailleurs : on voit, on ne prend rien, et rien ne change de main.
gardeUn controle pose sur le chemin d'une action, qui la laisse passer ou la refuse.
engagement (niveaux d'engagement citoyen)Quatre paliers de responsabilite choisis librement : plus on en prend, plus on peut poser de gestes qui touchent le collectif.
ce qui ENGAGE (regle fail-close)La liste courte des choses qui creent un droit ou une obligation — argent, vote, appartenance, accord, marque d'authenticite, transmission — et qui n'ont pas le droit de reussir sans etre ecrites pour de bon.

Matière : PLANCHES-MATIERE-4-OUBLIEES-2026-10-03.json (sha256 7a2a3299f5ed) — planche de matière « ENTRER — le rite naît en une transaction, et referme six portes derrière lui ». Générée par scripts/generer-planches-ancrage.py ; la version « avant » (avant le passage du sceptique) que la matière conserve n’est pas dessinée — c’est la version dégradée au doute qui l’est, et les marges portent les dégradations.