65 Commits

Author	SHA1	Message	Date
Sylvain Duchesne	3be8da2178	fix: régler l'identité n'a plus le droit de réclamer une session ... Le partage était cassé : Bob n'ouvrait pas le document qu'Alice venait de lui partager, sans erreur, juste « (illisible) ». Régression introduite en scindant ensureIdentity(). Chaîne observée aux sondes, pas déduite : settleIdentity() appelait setCurrentUser, qui déclenche startConnect(), qui va chercher la session via le thunk getSession de l'application. Or l'exemple appelle init() DEPUIS L'EXÉCUTEUR qui construit sessionReady — le thunk ne peut donc pas répondre, par construction. Il lève, resolveAccount rend null, l'exécution est abandonnée sans restauration ni drainage, mais s'est déjà enregistrée « en vol ». Le ensureIdentity() suivant rejoint cette exécution morte et se résout sans avoir rien fait. Avant la scission, rien n'appelait setCurrentUser pendant l'évaluation du module : la session existait, l'exécution était saine, et la rejoindre était sans danger. C'était bien une affaire de moment. bootstrap.ts scinde le setter : adoptCurrentUser enregistre qui agit, setCurrentUser reste « enregistrer + connecter » pour tous les autres appelants. La moitié sans session ne réclame donc plus de session, et se connecter redevient l'affaire du seul ensureIdentity(), attendu, là où une session existe. Ce que ça bloque, tracé avant de livrer : une application qui appellerait init() sans jamais appeler ensureIdentity() n'aurait plus de restauration en arrière- plan. Aucun appelant de ce genre n'existe, et avant la scission init() était un passthrough nu qui ne déclenchait rien — c'est une répartition rétablie, pas un comportement retiré. Reste connu, non corrigé : connectedUser mémorise toujours une exécution abandonnée. Le piège est documenté sur setCurrentUser.	2026-08-11 19:03:58 +02:00
Sylvain Duchesne	737729c9ce	refactor: le paquet s'appelle polyfill, « SDK » désigne celui de NextGraph ... Le nom @ng-eventually/sdk entrait en collision avec le SDK de NextGraph, dont ce paquet est justement un polyfill. Impossible d'écrire « le SDK » sans lever l'ambiguïté à chaque phrase — et le contrat publié, lu par une application, était le pire endroit pour laisser traîner ça. packages/sdk → packages/polyfill, @ng-eventually/sdk → @ng-eventually/polyfill, contract_sdk-surface → contract_polyfill-surface, e2e/sdk-entry.ts → e2e/polyfill-entry.ts, docs/sdk-reference.md → docs/polyfill-reference.md. Les occurrences de « SDK » qui désignent celui de NextGraph restent intactes, y compris les chemins dans nextgraph-rs (sdk/js/orm, sdk/js/web). Le tri s'est fait occurrence par occurrence, pas par substitution. Le contrat énonce désormais son identité en une phrase : « This package is a polyfill of NextGraph's SDK. »	2026-08-10 17:14:25 +02:00
Sylvain Duchesne	7076c0cca8	fix: readUnion regroupe par sujet réel — la fusion était une divergence ... `readUnion` indexait par DOCUMENT une table nommée `bySubject`, créait ses entrées avec `subject: doc`, et jetait le sujet réellement lu après s'en être servi pour écarter la machinerie. Tout triplet non-machinerie d'un document tombait donc dans un sac unique étiqueté par la référence du document : deux entités écrites sous deux sujets revenaient **conflées**, une entité écrite sous un autre sujet revenait **ré-étiquetée**. Sans erreur, sans trace. **C'était une divergence, et c'est à ce titre qu'elle tombe.** NextGraph dit l'inverse aux deux niveaux : une requête ancrée résout le graphe du repo comme graphe par défaut et rend les sujets tels qu'ils sont ; et l'ORM porte sur chaque objet **deux** propriétés distinctes, `@id` et `@graph`, dont il FABRIQUE la première quand on la laisse vide (`graphIri + ":q:" + aléa`). Plusieurs objets par graphe est le cas prévu, et `@id` existe pour les distinguer à l'intérieur d'un `@graph`. La règle du projet reste **« un document séparé par entité métier »**, mais c'est une recommandation de placement dictée par le modèle de sécurité — une clé est par repo, donc l'isolation par entité exige un repo par entité. Ce n'est pas une contrainte que la lecture a le droit d'imposer en rendant l'autre disposition invisible. Le contrat porte désormais la recommandation, le code porte la capacité ; il faisait exactement l'inverse. **La justification de l'épinglage était une erreur de catégorie**, et elle a été retirée plutôt que contournée : `repo_graph_name` formate un nom de GRAPHE, il est estampillé sur les quads et aucun sujet n'est réécrit. Deux confirmations indépendantes, dont la suite e2e qui écrit un sujet puis le relit par correspondance exacte contre le vrai broker. `UnionSubject.subject` passe de `Nuri` à `string` — un sujet RDF réel est un IRI quelconque. `graph` reste `Nuri` et devient le champ à repasser au SDK ; l'app d'exemple l'utilise à ses deux sites, où le sens était « le document ». **Et la suite e2e ne comptait que les entrées.** C'est pour cela qu'elle est restée verte pendant tout le défaut : compter ne distingue pas un regroupement par document d'un regroupement par sujet. Elle écrit maintenant deux sujets dans le dernier document et vérifie les trois choses qui comptent — quatre entrées pour trois documents, chaque entrée portant le sujet sous lequel elle a été écrite, et son `graph` étant la référence du document. 202 tests unitaires (5 ajoutés, dont 3 échouent si l'on restaure l'ancien repliage), e2e 42/42 et applicatif 12/12.	2026-08-10 14:50:07 +02:00
Sylvain Duchesne	f378c71739	docs: sept affirmations sur NextGraph requalifiées à la source ... Lot F de la revue adverse. Chaque affirmation relue dans `nextgraph-rs` par symbole avant d'être réécrite ; aucune ne s'est révélée exacte. - `AddLink` / `RemoveLink` / `RepoLinkV0` étaient présentés comme **implémentés**. Leurs arms de vérificateur sont des `Ok(())`, là où celui d'`AddRepo` fait un vrai travail, et rien ne les construit. Le tableau dit désormais « déclaré, stubbé », et la conclusion qui en déduisait « le registre existe, seule la livraison manque » est corrigée : **les deux bouts** sont déclarés-et-stubbés. - La table `inboxes` était dite « reconstruite vide à chaque session » — elle est repeuplée au chargement, et la clé privée d'inbox est persistée par repo. L'argument de sécurité qui s'appuyait dessus repose maintenant sur le bon motif : la table est **par vérificateur**, pas éphémère. - La citation de « `doc_create` laisse `inbox: None` » pointait un constructeur réservé aux tests ; re-ciblée sur le chemin de production. - `ExtObjectGet` était dit « le seul » primitif accessible à un non-membre et exigeant les clés : il y en a trois, et sa structure n'a aucun champ de clé. - L'en-tête de `public-store.ts` était marqué **VERIFIED** alors qu'il repose sur un commentaire de doc, et la condition qu'il citait (« si les brokers pairs l'autorisent ») disparaissait de la conclusion. Requalifié en **pari**, condition rétablie. - Deux sur-restrictions corrigées (ce qu'écrit le traitement d'un `ContactDetails`, et le prétendu « miroir 1:1 » de `NuriV0`, qui a dix champs). **Sur la grammaire du ReadCap, une correction de MA correction.** J'avais écrit que la forme `{target}:r:{cap}` était notre invention. Faux : le segment `r:` et son encodage sont ceux d'amont, et l'auteur de NextGraph l'a énoncé. Ce qui est établi est plus étroit — aucun parseur amont n'accepte aujourd'hui un NURI de repo qui le porte, et le segment est produit comme valeur de champ. J'avais conclu d'une implémentation absente à ce que la cible ferait, ce que la doctrine du projet interdit nommément. Seule « P1b remplace la valeur, pas la forme » est corrigée, requalifiée en **pari**. **Et la surface ne publie plus de type que personne n'utilise.** `export * from "./model/types"` publiait huit types en bloc ; c'est une liste nommée de six. `ReadCap` sort — aucune signature publiée ne le prend ni ne le rend, seules deux fonctions privées de `inbox.ts` s'en servent — et `InboxScope` aussi. Un type n'est publié que si une signature publiée l'utilise. 197 tests, 0 échec ; les trois typechecks propres ; `lint` sans erreur.	2026-08-10 12:09:20 +02:00
Sylvain Duchesne	0d9e2bbe97	fix: mon correctif sur createEntityDoc était faux dans les deux sens ... Second tour adverse sur le lot C. Six trouvailles, dont trois sur ce que je venais de livrer. **Le correctif de `createEntityDoc` reproduisait le défaut qu'il annonçait avoir fermé.** Il levait sur la PREMIÈRE écriture de registre en échec. Or : - lever sur le listing sautait l'écriture de la clé — détruisant le chemin de récupération que le commentaire d'à côté décrit explicitement (« la clé doit rester récupérable même si le listing a échoué »), et laissant le document orphelin ; - lever sur la clé laissait le document LISTÉ sans clé — précisément l'état « se lit vide pour toujours » que je prétendais empêcher, en pire, puisque l'appelant n'a même plus sa référence. Les deux écritures sont désormais tentées, ce qui atterrit reste, et l'échec est rapporté après en nommant la moitié manquante. **Le refus de `share` reposait sur une valeur qui confond absence et ignorance.** `resolveAccount` avale toute erreur de lecture et rend `null`, si bien qu'un incident réseau faisait répondre « personne ne s'est connecté sous ce nom » à propos de quelqu'un qui existe. `lookupAccount` propage désormais l'erreur ; `resolveAccount` reste la forme tolérante que tous les autres appelants veulent. **J'avais livré ce comportement sans un seul test.** `test/app-surface.test.ts` en ajoute huit, tous sur ce qu'un APPELANT voit : `ensureIdentity` rend l'identité, un appel de placement avant connexion nomme l'erreur, le placement agit comme l'utilisateur connecté, `share` refuse un nom inventé mais laisse remonter une panne, et une création à moitié écrite échoue en disant quelle moitié — dont le cas « le listing a échoué, la clé est quand même là ». En écrivant ces tests j'ai refait dans leur faux la faute que cette revue a corrigée ailleurs : ignorer le sujet dans la requête de compte, ce qui rendait le dossier d'un autre utilisateur. Deux des huit échouaient pour cette raison, sans rapport avec le code. **Et la documentation contredisait le code livré dans le même commit** : le README enseignait encore `createEntityDoc(me, "protected")` — en JS la portée devient `"alice"` — et le contrat déclarait `Nuri` là où le code et la feuille disent `NuriLike`. 197 tests unitaires, e2e 40/40 et applicatif 12/12.	2026-08-10 10:48:57 +02:00
Sylvain Duchesne	cdc09a1a1d	refactor(api): l'application ne nomme plus son identité — elle l'apprend ... Lot C de la revue adverse. Cinq corrections, dont une qui change la forme de la surface. **L'application ne pouvait pas obtenir son identité par l'API.** `ensureIdentity()` rendait `void`, `getCurrentUser` n'est plus publié — et pourtant `createEntityDoc(id, …)` et `listMyEntityDocs(id, …)` l'exigeaient. L'app d'exemple s'en sortait en lisant `localStorage["ng-eventually:identity"]` et le paramètre `?ng-id`, deux constantes PRIVÉES du portail d'accès. Une frontière qu'aucun consommateur ne devrait voir, et encore moins dont il devrait dépendre. Vérifié au niveau 2 avant de trancher : `session_start(wallet_name, user_id)` prend l'identité — donc en amont l'application la DÉTIENT, elle la tient du portefeuille qu'elle a ouvert. Ici c'est le portail qui la choisit, donc c'est au portail de la rendre. Deux changements, tous deux vers la cible : - `ensureIdentity()` rend l'identité qu'il a établie ; - `createEntityDoc(scope)`, `listMyEntityDocs(scope)`, `resolveWriteGraph(scope)` perdent leur paramètre d'identité. En amont `doc_create(session_id, …)` ne porte aucun utilisateur : une session EST celle d'un utilisateur. Passer la sienne à chaque appel de placement était un geste sans successeur. L'application garde l'identité pour l'afficher, et ne la passe plus à rien. **`inbox.share` provisionnait un destinataire inexistant.** Une faute de frappe créait les trois stores et l'inbox de ce nom, et la clé atterrissait où personne ne regarde — sans la moindre erreur. En amont on ne peut pas viser un nom qu'on invente : un dépôt est scellé vers une clé d'inbox qui vous est parvenue par un contact entrant. Refuser est fidèle ; provisionner était l'invention. **`createEntityDoc` avalait l'échec de ses deux écritures** et rendait quand même une référence — le document n'était dans aucun store, donc la session suivante ne le listait pas et sa lecture rendait vide, en silence. Il lève maintenant, comme `doc_create` en amont propage les siennes. **Deux entrées prenaient `Nuri` au lieu de `NuriLike`** (`inbox.watch`, `openDocumentInbox`), ce qui contredisait la raison même pour laquelle aucune garde de type n'est publiée. Et **deux messages d'erreur nommaient des symboles retirés** (`storeRegistry.documentInboxAddress`, `setCurrentUser`) : une erreur qui envoie vers une fonction inexistante est pire qu'une erreur muette. Contrat d'API et feuille `contract_sdk-surface` mis à jour ; `readForDocument` et le refus de `share` obtiennent enfin leur règle en §9. 189 tests unitaires, e2e 40/40 et applicatif 12/12.	2026-08-10 10:31:15 +02:00
Sylvain Duchesne	b7dc8ca2c3	fix: la suite n'était pas hermétique, et deux tests ne pouvaient pas échouer ... Second tour adverse sur le lot D. Trois trouvailles, et une erreur de diagnostic de ma part qui vaut d'être consignée. **La suite verte dépendait de l'ordre des fichiers.** `bun test isolation-active public-store` donnait 5 échecs quand chaque fichier seul était vert — donc un checkout de CI avec un autre ordre d'inodes livrait rouge. Deux causes distinctes : - le travail de connexion, lancé sans être attendu par `setCurrentUser`, débordait d'un fichier sur le suivant et armait l'émulation. `connectedUser` abandonne désormais dès que l'identité pour laquelle il a démarré n'est plus connectée — ce qui est de toute façon la bonne sémantique : en amont une session appartient à un utilisateur, et changer d'utilisateur est une autre session ; - et surtout **mon propre test de store public exposait le cap d'un document que personne ne détient** — un état que la bibliothèque ne produit jamais. Il ne passait que tant que l'émulation était désarmée. Alice crée sa note avant de l'exposer, maintenant. Balayage des 21 paires de fichiers : plus aucune ne pollue. **Le contrôle symétrique ajouté hier ne pouvait pas échouer.** « La liste d'Alice ne contient pas la note de Bob » lisait un rendu ANTÉRIEUR à l'écriture de Bob : l'attente de `showScope` était satisfaite au premier sondage par le marqueur déjà à l'écran, sans synchroniser quoi que ce soit. Alice écrit désormais une note APRÈS celle de Bob — `writeNote` attend son apparition, donc ce qui suit est un rendu qui post-date. Et le `.catch` qui avalait le délai d'attente est retiré : une liste qui ne se stabilise jamais est un échec à voir, pas une dégradation à absorber. **Le test anti-fork prouvait « pas le premier », pas « le canonique ».** Son minimum lexicographique était aussi le DERNIER élément, si bien qu'un choix positionnel — la faute exacte que ce test existe pour attraper — restait vert. Le minimum est déplacé au milieu ; vérifié par mutation, « prendre le dernier » le fait rougir. **Mon erreur de diagnostic.** J'ai cru trouver, sous la trouvaille d'ordre, une fuite entre utilisateurs — les caps d'Alice classés chez Bob — et je l'ai « reproduite ». Le repro était faux : son faux `ng` ignorait le sujet dans la requête d'inbox, donc l'inbox de Bob résolvait vers celle d'Alice. Une fois le faux corrigé, la fuite ne se reproduit plus, ni avec ni sans correctif. Le danger reste réel en lecture du code — trois chemins classent des caps plusieurs `await` après la garde qui les autorisait — donc `caps.holderKey`/`learnFor` le ferment par construction, mais les commentaires disent maintenant ce que c'est : un risque fermé, pas un défaut observé. 189 tests unitaires, e2e 40/40 et applicatif 12/12.	2026-08-10 10:02:45 +02:00
Sylvain Duchesne	0b936d2119	fix: écrire est une PROPRIÉTÉ, et trois portes qui n'auraient pas dû être ouvertes ... Suite de la revue adverse. Quatre trous de frontière, tous hors du champ « l'isolation est fausse jusqu'à P1b » — P1b parle de matériau de clé, ceux-ci sont des défauts de FORME et resteraient des trous avec une vraie clé. **La garde d'écriture reposait sur la mauvaise question.** Elle demandait « ce cap m'a-t-il été servi par un store public ? ». Ce prédicat était faux dans les deux sens à la fois : trop laxiste — une clé reçue dans une inbox donnait l'écriture, alors qu'en amont un Link est « external repos only » et qu'écrire est l'appartenance au repo ; trop strict — la propriétaire de son propre document public était refusée dès qu'elle l'ouvrait depuis sa référence avant que son store ne soit listé. Un prédicat poussé dans deux sens est le signe que c'était le mauvais prédicat. Écrire dépend désormais de la PROPRIÉTÉ, lue sur la branche Store (l'`AddRepo` émulé), plus la paternité de session pour les documents créés par la primitive brute qui n'a aucun store où s'inscrire. Conséquence assumée et documentée : seul le propriétaire écrit, ce qui est l'état amont d'un repo tant qu'aucun membre n'a été ajouté — mécanisme qu'on n'émule pas. **`docs.depositInto` quittait la frontière en la publiant.** Sa doc disait « `inbox.post` est le seul appelant » : vrai dans la bibliothèque, faux dès qu'on le publie. Démontré : avec la seule référence nue d'un document public, on réécrit l'adresse d'inbox posée dessus et on détourne les dépôts destinés à son propriétaire. Une porte qui saute une garde ne doit pas être ouvrable par une application — elle rejoint la machinerie. **Le filtre de lecture n'interceptait que trois membres** et transmettait tout le reste lié à la CIBLE : `.values()`, `.map()`, `.getById()` rendaient le contenu d'un autre utilisateur — précisément les membres qu'une API de set réactif met en avant. Les membres qui rendent des éléments sont désormais filtrés, les mutations passent (elles ne rendent rien), et **tout membre inconnu lève** au lieu de transmettre : une transmission est une fuite silencieuse, une levée est bruyante et greppable. **Le mémo du store public était par document.** Le premier demandeur déclenchait le téléchargement, le cap était classé chez LUI, et tout demandeur suivant recevait « oui » en ne détenant rien. En amont un broker qui sert un overlay externe répond à TOUS. Le mémo garde la valeur, l'appelant la classe pour qui est connecté. Aussi : l'exemption `declareInfrastructure` supprimée — zéro appelant, ensemble toujours vide, et une doc décrivant deux documents exemptés qui ne l'ont jamais été. Et les caps d'écriture décrits comme « partiels » sont dits **inertes**, ce qu'ils sont : `grantWrite` n'a aucun appelant de production. **Ce que l'e2e a rattrapé.** Ma première version de la garde refusait au créateur l'écriture sur un document fait par `docs.docCreate` — 7 étapes rouges contre le broker, après une suite unitaire restée verte. La primitive brute n'inscrit la paternité nulle part ; c'est ce que `mintedHere` couvre désormais. 185 tests unitaires (dont quatre régressions : la propriétaire écrit, le destinataire non, le store public sert tout demandeur, aucun membre non filtré ne transmet), e2e 40/40 et applicatif 10/10.	2026-08-07 13:59:13 +02:00
Sylvain Duchesne	0455a408b6	refactor(api): le bootstrap redescend de quatre appels à un ... L'objectif acté était deux appels spécifiques au polyfill, voire un. Il en publiait quatre. Chacun des trois de trop était une raison que la BIBLIOTHÈQUE a, pas un besoin qu'une application a : - **`configureStoreRegistry`** existait parce qu'il y a deux internes à câbler — le SDK injecté d'un côté, la session de l'autre. Vu de l'appelant, les deux disent « voici ce qu'il te faut pour tourner ». Replié dans `configure`, qui prend désormais `getSession` / `normalizeId` / `pointerGuard`. - **`setCurrentUser`** n'a plus lieu d'être publié depuis que le portail d'accès est passé dans le polyfill : c'est lui qui pose l'identité. Et une application qui nomme sa propre identité est exactement le geste qui inverse le modèle — il ne doit pas exister d'appel publié vers lequel se tourner. Le harnais e2e, lui, joue plusieurs identités sur une même page ; il y accède par le chemin interne, ce qu'un harnais a le droit de faire et une application non. - **`connectedUser`** est maintenant attendu DANS `ensureIdentity`. Ce n'était pas une commodité : la suite applicative avait montré qu'une app devait l'attendre elle-même, sinon une note qu'on venait de lui partager se lisait comme illisible. J'avais traité le symptôme dans l'app d'exemple ; le défaut était côté bibliothèque. En amont, ouvrir la session EST la connexion — aucune application n'attend un second appel. Reste donc `configure({ … })`, plus `await ensureIdentity()` dont le site d'appel survit à la migration : une application attendra toujours une session avant de rendre. Le test étendu hier a fait son travail : les deux contrôles de contrat sont passés au rouge sur `configureStoreRegistry`, `connectedUser` et `StoreRegistryDeps` dès que la surface a bougé. 180 tests unitaires, e2e 40/40 (3,4 min) et applicatif 10/10 (0,8 min).	2026-08-07 12:06:15 +02:00
Sylvain Duchesne	b98fcaa77d	docs+test: le contrat avait dérivé — et le mécanisme ne voyait pas les règles ... En vérifiant l'alignement de la surface, cinq sections du contrat s'étaient désynchronisées du code sans que rien ne rougisse : - § 1 montrait `getConfig`, `getStoreRegistryDeps`, `resetConfig` et `resetStoreRegistry` comme exportés — retirés à la fusion des portes ; - § 11 documentait `escapeLiteral` / `escapeIri` / `assertNuri` comme publiés — ils ne le sont plus, et l'absence de garde de type est désormais expliquée par sa raison : les portes valident elles-mêmes (`NuriLike`), publier une garde inviterait le cast que les types servent à empêcher ; - § 12 listait sept fonctions `storeRegistry` — il y en a cinq depuis que les deux fonctions d'ADRESSE d'inbox sont parties (une app nomme un document ou une personne, jamais une adresse) ; - § 13 listait `IdentityStore`, `browserIdentityStore` et `getCurrentUser` comme publiés — retirés le 2026-08-05 ; - `ensureIdentity` était publié **sans aucune règle**, et l'annexe renvoyait à un « § 2bis » qui n'existait pas. **§ 2bis est écrit** : le portail d'accès n'a aucune contrepartie en substance — en amont un utilisateur ouvre SON portefeuille et il n'y a rien à nommer — mais son SITE D'APPEL survit, et c'est pourquoi sa signature ne prend pas d'identifiant : nommer son identité est précisément la partie qui disparaît, donc elle ne doit pas figurer dans les paramètres. **Le mécanisme est étendu.** `test/vocabulary.test.ts` épinglait l'annexe — les NOMS — et ne voyait pas les sections, là où vivent les règles. Une règle périmée est pire qu'une règle absente : elle se lit comme vérifiée. Désormais tout `export` montré dans un bloc « ### Today » doit être réellement exporté ; ce qu'on garde pour mémoire passe en commentaire, que le contrôle ignore par construction. Les cinq dérives ci-dessus auraient été rouges le jour même. Nettoyé aussi : deux commentaires de doc orphelins dans `surface/placement.ts`, restés au-dessus de l'accolade fermante après le retrait des fonctions qu'ils décrivaient. 180 tests unitaires, typecheck bibliothèque / exemple / harnais.	2026-08-07 11:51:24 +02:00
Sylvain Duchesne	0eb25286c8	refactor: renommer client → sdk, et fusionner les deux portes en une ... Deux mouvements de surface, aucun changement de comportement. **`packages/client` → `packages/sdk`, `@ng-eventually/client` → `@ng-eventually/sdk`.** « client » ne disait rien : ce paquet EST le SDK que l'application appelle, et c'est tout ce qu'elle appelle. L'ancien nom reste comme mot-clé de recherche dans `docs/source-layout-by-fate.md` et le tableau des paquets du README. **Une seule entrée.** L'entrée `./polyfill` disparaît ; ses symboles applicatifs — `configure`, `configureStoreRegistry`, `setCurrentUser`, `connectedUser` et leurs types — vivent dans un bloc `POLYFILL-ERA` de `src/index.ts`. Ce que la seconde porte portait mérite d'être nommé avant d'être retiré : *ce qu'on importe de ce chemin est exactement ce qu'on supprimera à la migration*. Une seule porte perd ce signal — rien à la ligne d'import ne distingue `configure`, qui part, de `docs`, que le vrai SDK remplace sur place. Trois choses le portent désormais : le bloc lui-même, l'inventaire d'exports de `docs/api-contract.md` (épinglé par `test/vocabulary.test.ts`, donc il ne peut pas rancir en silence), et le contrôle de vocabulaire sur les noms publiés. **Six symboles quittent la surface au passage**, et la fusion est ce qui a rendu le choix visible plutôt qu'hérité : - `getConfig` / `getStoreRegistryDeps` — câblage interne, atteint par `shared-wallet/bootstrap` ; - `resetConfig` / `resetStoreRegistry` / `resetCaps` — remises à zéro de test, atteintes par leur chemin interne, ce qui est leur raison d'être ; - le `share` direct — `inbox.share` a toujours été la même fonction, et la publier deux fois brouillait la frontière qu'elle servait à marquer. Corrections d'affirmations fausses trouvées en chemin : le contrat annonçait `isNuri` / `hasReadCap` sur la porte SDK alors qu'ils ne sont plus exportés depuis le passage au permissif en entrée (`NuriLike` validé à la porte) ; le README du paquet documentait `capFor`, `shareCap`, `getCaps` et `publishRepoLink`, dont aucun n'existe ; et le README de l'app d'exemple affirmait que la suite e2e la pilote, ce qui reste à faire. 179 tests unitaires, typecheck bibliothèque / exemple / harnais, e2e 42/42 contre le broker en ligne — mesuré une fois après le renommage, une fois après la fusion.	2026-08-07 11:16:57 +02:00
Sylvain Duchesne	0832338201	feat: un document en store public sert son ReadCap, une référence nue suffit ... Le modèle amont est explicite dans `PublicRepoLinkV0` : le lien ne porte AUCUN `read_cap`, et son commentaire dit pourquoi — *"The latest ReadCap of the branch will be downloaded from the outerOverlay, if the peer brokers listed below allow it […] the public site are served differently by brokers"* (engine/net/src/types.rs:5098). La clé n'est pas remise par un émetteur : elle est donnée par le réseau à qui la demande, parce que le broker a épinglé l'overlay externe (`expose_outer`). La bibliothèque refusait jusqu'ici la forme sans cap quel que soit le store. Sûr dans le bon sens, mais une application ne pouvait pas exprimer « fais circuler, la référence suffit » — le seul acte que le modèle rend gratuit — et son unique contournement était de distribuer la clé, ce qui détruit la confidentialité composable. `emulated-verifier/public-store.ts` émule le mécanisme SANS toucher à la garde. La possession reste l'unique critère : un document public est lisible non par exception mais parce que son cap est *obtenable*. Chaque porte de lecture demande d'abord (`readUnion`, `docs.sparqlQuery`, `ensureRepoOpen`, `documentInboxAddress`), puis le chemin ordinaire s'applique. Lire n'est pas écrire. Ce que le store sert est un droit de LECTURE : `learnFromPublicStore` le classe à part et `assertMayWrite` refuse l'écriture dessus. Sans cela une référence nue achetait une écriture, ce qu'aucun store amont n'accorde. Autres conséquences : - `recordInPublicStore` (marquer + frapper) devient `markInPublicStore` (marquer). Frapper un second cap à côté de celui qu'on vient de télécharger donnerait deux clés différentes le jour où la constante devient un secret. - `hasCap` quitte la porte polyfill : il se lisait « ai-je le droit de lire ceci ? » et un document public y répondait `false` jusqu'à ce qu'on demande son cap. Aucun appelant hors des tests. - Les tests cross-user ne font plus traverser de cap par une variable JS : Bob n'obtient que la référence nue, comme une vraie application. Écarts documentés plutôt que masqués : le pari sur un modèle DÉCLARÉ (`expose_outer` est câblé à `false` côté client et `ExtTopicSyncReq` est `unimplemented!()`), la découverte limitée à ce qu'on sait déjà nommer, `useShape` qui n'a pas d'await à dépenser, et l'absence de `locator`. 179 tests unitaires, e2e 42/42 contre le broker en ligne.	2026-08-06 19:55:32 +02:00
Sylvain Duchesne	32ef756b0b	docs: deux actes, pas quatre besoins ... La section listait quatre « besoins » — nommer, donner à lire, faire trouver, joindre. C'était confondre ce qu'un acte FAIT avec ce dont son résultat dépend. Un émetteur ne fait que deux choses, et tout cas d'usage est l'une des deux : - transmettre la RÉFÉRENCE (`access` vide) : le destinataire peut nommer le document — et le lire si celui-ci se trouve dans un store public. Même valeur transmise, résultat différent, décidé par l'endroit où est le document et non par ce qu'on a envoyé. - transmettre la référence ET la clé : le destinataire lit. Irréversible. « Faire trouver » n'était donc pas un troisième acte, mais le premier appliqué à un document en store public. Et « joindre » n'est pas un acte du tout : le locator dit si la référence est assez COMPLÈTE pour être résolue par un inconnu — cela relève du destinataire. D'où la conséquence pour tout ce que cette bibliothèque expose : un appel remet la clé ou ne la remet pas, et ce doit être l'intention explicite de l'appelant — jamais l'effet de bord d'une demande de référence. Où en est la bibliothèque, acte par acte : transmettre la référence est couvert sans appel dédié (toutes les références rendues sont nues) ; transmettre référence et clé l'est par `inbox.share`. Et une propriété du modèle n'est PAS émulée : un document en store public est lisible depuis une référence nue, là où `mayReach` exige toujours un cap détenu. L'écart va dans le sens sûr — nous sous-accordons — mais une app ne peut pas exprimer « je diffuse largement, la référence suffit », et son seul contournement serait de remettre la clé, ce qui casse la confidentialité composable. Section redondante supprimée, et le mot banni retiré des exemples.	2026-08-06 17:35:39 +02:00
Sylvain Duchesne	94173fd3d3	docs: consigner l'écart sur l'inbox choisie par share ... `inbox.share` dépose toujours sur l'inbox PROTÉGÉE du destinataire. En amont le choix n'est pas fixe : un enregistrement de contact prend son inbox du PROFIL par lequel la personne a été atteinte — `a_or_b = if details.profile.is_public() { "site" } else { "protected" }` (`inbox_processor.rs:787`, écrit `ng:site_inbox` ou `ng:protected_inbox` en `:823-824`). Mineur aujourd'hui, mais ça aplatit une distinction du modèle, et ce sera faux le jour où une application partagera avec quelqu'un rencontré par son profil public. Consigné plutôt que corrigé : le correctif demande une notion que rien n'a établi ici. Ce qui EST vérifié se limite à un wallet qui contient des `sites`, un `SiteV0` avec `id: PubKey`, `name`, `site_type` et trois stores. L'enum `Identity`, qui nommerait le reste, est entièrement COMMENTÉ en amont (`engine/repo/src/types.rs:586-595`) — il n'y a donc aucun modèle de profil à lire, et rien à supposer. Rappelé au passage, parce que la question s'est posée : le store privé n'a aucune inbox — `new_store_default` n'en attache une que `if !private` — d'où `InboxScope`, qui rend « l'inbox privée » inécrivable plutôt que simplement vide.	2026-08-06 16:25:33 +02:00
Sylvain Duchesne	cb56f91b5e	docs+fix: le modèle de sécurité local-first, et le retrait de linkTo qui le brisait ... La règle d'accès est « qui a la référence ET la clé lit » — jamais « qui a la référence lit ». Il n'y a pas de tiers dans cette phrase : le moteur ne vérifie une permission qu'à l'ÉCRITURE, jamais à la lecture. Le contenu est chiffré, la clé EST le droit. C'est ce que veut dire local-first ici : il n'y a personne à qui demander, donc la possession est tout le mécanisme. Ce que cette règle achète, et qui n'était consigné nulle part : une référence n'accordant rien, **elle n'est pas récursive**. Un document largement diffusé peut pointer vers un document restreint — la référence dit qu'il existe, la clé dit qui le lit. D'où la confidentialité COMPOSABLE : un sommaire diffusé qui renvoie à des chapitres restreints, un événement public qui renvoie à sa liste de participants. L'auteur diffuse un document et décide encore, document référencé par document référencé, qui reçoit la clé. `linkTo` détruisait cette construction. Il rendait la CLÉ là où un appelant demande une référence, transformant la règle en « qui a la référence lit » — pour ce document et pour tout ce qu'il MENTIONNE. Ajouté et retiré le même jour. Documenté en §0, avant tout le reste, avec la raison pour laquelle un agent perd ce point avec constance : les réflexes client-serveur fournissent la moitié manquante sans qu'on s'en aperçoive — quelque part un serveur vérifierait, un lien serait un identifiant inoffensif, « Bob a-t-il le droit ? » aurait une réponse. Aucun des trois n'est vrai ici, et du code écrit là-dessus n'échoue pas : il accorde en silence. Rien ne passe au rouge. Renommé au passage : `publishRepoLink`/`isPublished` → `recordInPublicStore`/ `isInPublicStore`. Ces méthodes n'ont pas de pendant amont et « publier » ne désigne rien de précis ici. 171 tests unitaires, e2e 42/42 en 3,6 min.	2026-08-06 16:04:31 +02:00
Sylvain Duchesne	3c981ffadb	docs: le nommage de NextGraph l'emporte toujours — y compris sur nos propres règles ... La règle que je venais d'écrire bannissait « publish » sans réserve. Or le moteur emploie `publisher` 126 fois — `as_publisher`, `publisher_advert` — pour un rôle pub/sub sur un topic. Une règle appliquée à la lettre aurait fait rejeter du vocabulaire amont, ce qui est exactement l'inverse du but. Le principe est donc posé au-dessus, et il prime sur tout : là où la cible a un mot, c'est le mot, point. Ce qui reste banni est NOTRE « publier un document », qui n'a aucun référent en amont et recouvre trois actes distincts — placer dans un store public, rendre trouvable, remettre une clé. Ça n'autorise jamais à renommer ce que l'amont appelle `publisher`. `publisher`, `topic` et `advert` rejoignent le vocabulaire déclaré du contrôle de noms, avec la raison en commentaire. Le renommage `publishRepoLink` → `recordInPublicStore` reste justifié : cette méthode n'a pas de pendant amont, elle enregistre un document en store public (et, artefact d'émulation, lui frappe une clé).	2026-08-06 15:50:54 +02:00
Sylvain Duchesne	7672915bb9	docs: ce qu'un NURI transporte, et les quatre besoins d'un lien ... Une discussion de conception a calé plusieurs fois sur une séparation supposée entre « un NURI » et « un lien ». Elle n'existe pas, et l'avoir crue est ce qui a fait livrer un `linkTo` faux sur trois points à la fois. `NuriV0` porte exactement ce qu'un lien porte — `target`, `overlay`, `access: Vec<NgAccessV0>`, `locator` — et `NgLinkV0` en est la forme structurée. La vraie question n'est donc pas « NURI ou lien » mais ce qu'on met dans `access` et `locator`. Nuance qui compte pour tout ce qui s'imprime : le TYPE a tous les emplacements, la GRAMMAIRE de chaîne ne les expose pas tous. `access` est une LISTE de formes d'accès (`ReadCap | Token | ExtRequest | Key | Inbox | Topic`), donc une liste VIDE est un état légitime et courant : la référence NOMME sa cible et n'accorde rien. D'où les quatre besoins, chacun avec ce que la référence doit porter : nommer (access vide), donner à lire (+ ReadCap, irréversible), faire trouver un document public (overlay/locator, aucune clé), joindre depuis ailleurs (locator, sans quoi un inconnu n'ouvre rien). Trois confusions nommées parce que chacune a été faite ici : « sans clé » ne veut pas dire « public » ; nommer n'est pas lire et c'est l'acte PAR DÉFAUT (ce que notre test central prouve déjà) ; rien n'est vérifié à l'accès, donc une référence ne peut pas être neutre en droits — ce qu'on y met EST l'autorisation, et un lien diffusé ne se révoque pas. Et la divergence la plus lourde, qui n'était consignée nulle part : publier signifie ICI distribuer une clé, alors qu'en amont un document public est lisible parce que son STORE l'est et que les brokers le servent. L'émulation est trop stricte, pas inversée — elle sous-accorde — mais un consommateur ne doit pas en conclure que publier est un acte de distribution de clé, ni attendre quoi que ce soit de per-lecteur sur un document public.	2026-08-06 12:52:35 +02:00
Sylvain Duchesne	c8d02619b1	refactor(api): partager nomme le document, détenir répond par oui ou non ... `shareCap(cap, toUser)` faisait tenir une clé à l'appelant. En amont il n'en tient aucune : c'est le verifier qui remplit `ContactDetails.read_cap`, et une inbox se résout depuis un profil. Cette signature a déjà changé deux fois aujourd'hui — `(cap, toInbox)` puis `(cap, toUser)` — et les deux laissaient à l'app quelque chose qu'elle ne tiendra pas plus tard. - `inbox.share(doc, toUser)` : les deux choses qu'une application a, un document et une personne. Ni la clé ni l'adresse n'apparaissent. - `hasCap(doc)` remplace `capFor(doc)` et rend un BOOLÉEN. C'est la seule question que le modèle admette, et l'unique appelant qui utilisait la valeur s'en servait pour la passer à `shareCap`. Les tests ont fait apparaître un besoin que ces retraits allaient casser : obtenir le lien PARTAGEABLE d'un document publié, pour le faire circuler. C'est distinct du partage dirigé et ça existe en amont — un `RepoLinkV0 { read_cap }` est ce qu'on passe, `ContactDetails.read_cap` est la remise à quelqu'un. D'où `linkTo(doc)`, seul endroit où une app tient légitimement une clé : on ne peut pas faire circuler ce qu'on n'a pas le droit de toucher. La clé d'un document protégé, elle, ne sort jamais par là — elle passe par `share`. 171 tests unitaires, e2e 42/42 en 3,5 min (synchro à froid 29s, stable contre 30s au run précédent — le wallet par batterie tient).	2026-08-06 11:37:47 +02:00
Sylvain Duchesne	ebf866b1f2	refactor(api): précis en sortie, permissif en entrée — plus de guard publié ... Un polyfill ne doit rien faire de plus que ce qui est prévu. `isNuri` / `hasReadCap` et les utilitaires SPARQL `escapeLiteral` / `escapeIri` / `assertNuri` n'ont de pendant à aucun niveau et n'en auront pas : le binding prend `nuri: String`, le moteur est fortement typé en Rust et n'a besoin d'aucun prédicat, l'ORM n'expose rien de tel. Le contrat les justifiait parce qu'ils « restent utiles à n'importe quelle app » — c'est exactement le raisonnement à refuser : utile n'est pas prévu, et chacun serait un appel à réécrire le jour du SDK. Le besoin d'un guard venait de notre propre signature : les entrées publiques exigeaient `Nuri`, donc un consommateur devait narrower ce qu'il lisait d'une URL ou du stockage. Elles prennent désormais `NuriLike` — n'importe quelle chaîne — et valident à l'intérieur (`toNuri`). Ce que la bibliothèque REND reste typé `Nuri` : l'app en profite gratuitement, et un type plus large ne cassera rien quand le SDK rendra des chaînes. Les guards et les utilitaires restent, internes, là où la validation se fait. Un défaut introduit puis corrigé en chemin, qui valait le test qu'il a produit : `readUnion` a toujours toléré les trous dans sa liste — un index de scope peut porter une entrée blanche, et un appelant qui assemble depuis des valeurs optionnelles n'a pas à compacter. Valider AVANT de filtrer a transformé cette tolérance en exception. Vide est une absence, pas une référence malformée ; les deux sont désormais distingués par un test. 170 tests unitaires, e2e 42/42 contre le broker, typecheck vert sur la bibliothèque, l'exemple et le harnais.	2026-08-06 10:51:36 +02:00
Sylvain Duchesne	54f8389e9e	refactor(api): l'app nomme une personne ou un document, jamais une adresse d'inbox ... L'app d'exemple a servi de juge, et elle a immédiatement montré ce que l'inventaire ne montrait pas : pour partager une note elle résolvait l'inbox du destinataire, pour lire ses messages elle résolvait l'adresse de la sienne. Deux gestes qu'aucune application n'aura à faire une fois la chose native — donc deux gestes qu'elle ne doit pas apprendre. - `shareCap(cap, toUser)` remplace `shareCap(cap, toInbox)`. Partager est un acte envers quelqu'un ; où est son inbox regarde la bibliothèque. - `inbox.readForDocument(doc)` : le propriétaire lit ses messages en nommant la note, comme le déposant la nomme pour en laisser un. - `storeRegistry.userInbox` et `documentInboxAddress` sortent de la surface publiée. Ils restent joignables en interne, où le shim en a besoin. Sortent aussi de `/polyfill`, chacun parce qu'une app qui code contre apprend ce qu'il faudra désapprendre : - `getCaps` / `CapRegistry` — la salle des machines. La question du consommateur est `capFor(doc)` : est-ce que je le détiens ? Le registre n'a ni successeur ni forme inerte ; ce qui s'appuie dessus sera à réécrire, pas à laisser en place. - `getCurrentUser` — une app sait qui elle a connecté ; le redemander à la bibliothèque est une commodité du wallet partagé. - `virtualUsers` / `IdentityStore` — se souvenir d'une identité entre deux sessions est aussi le travail de l'app en amont. L'écran d'accès persiste ce dont IL a besoin ; rien d'autre n'a à être exposé. Reste sur `/polyfill` ce qu'une app appelle vraiment : `configure` et `setCurrentUser`. Le reste y est du test ou de l'injection interne. 170 tests unitaires, e2e 42/42 contre le broker, typecheck vert sur la bibliothèque, l'exemple et le harnais.	2026-08-05 18:55:30 +02:00
Sylvain Duchesne	66a40fbb89	feat(access-gate): le parcours de connexion passe dans le polyfill ... Chaque étape de cet écran n'existe que parce qu'un wallet héberge plusieurs identités. Une app qui l'implémente écrit du code qu'elle devra supprimer, et pire, du code qui enseigne à ses auteurs un modèle que NextGraph n'a pas : « je nomme mon identité ». Le premier consommateur en avait ~300 lignes — un gate, un écran, un module wallet, un contexte d'identité, trois features. C'est le travail de la bibliothèque, pas le sien. `ensureIdentity()` : un appel, avant que l'app s'affiche. Il ne prend PAS d'identifiant — nommer une identité est l'étape qui disparaîtra, donc elle ne doit pas figurer dans la signature. Le jour où le wallet fournit l'identité, l'appel se résout sans rien afficher et le code de l'appelant ne bouge pas. L'écran est en DOM natif, sous shadow root : c'est une barrière technique montrée avant qu'une application s'affiche, comme une demande de mot de passe sur une bêta fermée. La lier à un framework obligerait chaque consommateur à adopter ce framework pour un écran voué à disparaître. L'ordre de résolution de l'identité est pinné par des tests, parce que s'y tromper échoue en SILENCE : le parcours traverse deux partitions localStorage distinctes — la page et l'iframe du broker — et seul l'URL franchit la frontière. Si le stockage l'emportait, l'iframe lirait une identité vide, provisionnerait un second utilisateur virtuel, et l'utilisateur reviendrait dans un espace vide sans la moindre erreur. Les identifiants du wallet partagé (fichier, mot de passe) passent par `configure()` : ce sont des données de déploiement, et cet appel est déjà celui qui devient inerte à la migration. Au passage, l'ancien champ `sharedWallet: { name, secret }` — inutilisé nulle part — est remplacé. 168 tests unitaires, typecheck vert.	2026-08-05 17:06:10 +02:00
Sylvain Duchesne	c42236bc00	test: l'inventaire du contrat est tenu par un test, plus à la main ... L'appendice « inventaire des exports pour diff » d'`api-contract.md` était périmé : il listait encore les internes du shim dans le namespace `storeRegistry` alors que l'entrée avait été réduite à sept fonctions. Or c'est précisément l'instrument qu'on diffe quand la surface bouge — et un inventaire périmé est pire qu'aucun, il se lit comme vérifié. Régénéré depuis les `export`, et désormais tenu par `vocabulary.test.ts` : si la liste et le code divergent, le test échoue. Le document suit le code au lieu de dériver. Au passage, le contrôle de vocabulaire suit maintenant `export * from`, ce qui lui a fait voir trois types qu'il ignorait — d'où le suffixe structurel `…Like` (`NgLike` = « ce qui a la forme de ng ») déclaré comme de la glue de typage et non un mot de domaine. 162 tests unitaires, typecheck src/test/e2e vert.	2026-08-04 18:14:53 +02:00
Sylvain Duchesne	3257afe8c0	feat(inbox): un utilisateur a DEUX inboxes, comme en amont ... Tranché par la cascade plutôt qu'en attendant une réponse : le niveau 3 (ORM) ne dit rien des inbox, le niveau 2 non plus — `@ng-org/web` n'expose aucune méthode contenant « inbox » et la session n'en publie aucune. C'est donc le modèle du moteur qui décide, et il dit DEUX : un site porte une inbox sur son repo de store public et une autre sur son protégé (`engine/verifier/src/site.rs:127-152`), les seuls `AddInboxCap` du moteur, `new_store_default` n'en posant une que `if !private`. Elles sont adressées séparément jusque dans les enregistrements de contact, qui choisissent leur prédicat selon le profil visé — `ng:site_inbox` pour un profil public, `ng:protected_inbox` sinon (`engine/verifier/src/inbox_processor.rs:787,823-824`). `userInbox(id)` en exposait une : une cardinalité que cette bibliothèque avait inventée, et que le nom `walletInbox` avait contribué à masquer. Elle prend désormais le scope, et le store PRIVÉ n'en a pas — d'où `InboxScope` plutôt que `Scope` : demander l'inbox privée n'est pas une recherche qui ne rend rien, c'est une question sans référent dans le modèle, et le type l'interdit. `myInboxes` énumère les deux, `isOwnInbox` reconnaît les deux. Le shim garde un triple par (user, scope). 160 tests unitaires, typecheck src/test/e2e vert, e2e 40/40 contre le broker.	2026-08-04 16:19:49 +02:00
Sylvain Duchesne	107f9d1633	refactor(vocabulary): les noms publiés parlent la langue de la cible, et un test le tient ... La correction de nomenclature du 2026-07-30 — en amont un *wallet* n'est qu'un trousseau, ce qui possède des stores est un **user** (un *site*) — s'était faite à la main. `walletInbox` y a échappé et a vécu des semaines, en faisant des dégâts : le nom rendait « une inbox par wallet » évident, masquant qu'un user en a **deux** en amont (repos de store public et protected, les deux seuls `AddInboxCap` du moteur). Une discipline appliquée à la main en oublie un ; un test non. D'où `test/vocabulary.test.ts` : tout nom publié est bâti sur des mots que la CIBLE emploie — vérifiés dans `nextgraph-rs` — ou porte un marqueur disant POURQUOI il n'existe qu'ici (`virtual`, `physical`, `shim`, `emulated`, `polyfill`), ce qui dit aussi quand il disparaît. Un échec n'est pas « renommer pour faire passer le test », c'est une question : la cible a-t-elle un mot pour ça ? la chose n'existe-t-elle qu'ici ? le mot est-il vraiment de la glue ? Ce que le test a trouvé, et les réponses : - `walletInbox` → `userInbox`, avec l'écart de cardinalité écrit noir sur blanc plutôt que caché par le nom. - `accounts` / `AccountRecord` / `AccountStorage` → `virtualUsers` / `VirtualUserRecord` / `VirtualUserStorage`, module `accounts.ts` → `virtual-users.ts`. « account » n'est pas de la cible : c'est notre mot pour l'utilisateur virtuel, et le marqueur le dit désormais. - `readModel` → la fonction `readUnion`, exposée directement. « model » n'était ni de la cible ni de la glue, et le namespace ne tenait qu'une fonction. - Le reste était du vocabulaire légitime à déclarer (`subject`, `base`, `schema`, `connected`, le modèle réactif de l'ORM). Corrigé au passage, sur signalement du contrat interne : l'en-tête d'`open-repo` justifiait son correctif par un mécanisme que le source contredit. Un repo absent de `self.repos` lève bien `RepoNotFound` (`engine/verifier/src/request_processor.rs:264,269`). Les 0 lignes observées viennent d'ailleurs — `Verifier::load` repeuple `self.repos` depuis le stockage sur un profil persistant (`verifier.rs:535-560`), et notre propre `readDoc` attrape toute erreur et rend `[]`. Le correctif est bon, le diagnostic écrit à côté ne l'était pas. 159 tests unitaires, typecheck src/test/e2e vert, e2e 40/40 contre le broker.	2026-08-04 14:35:01 +02:00
Sylvain Duchesne	0b37d17c2f	docs: reprendre les citations après le rangement, et retirer le membre login fabriqué ... Les deux contrats et la doctrine portent des centaines de citations `file:line` vers `src/`. Le rangement par destin les périmait en bloc — 208 reprises (45 chemins `src/x.ts`, 163 mentions nues). Sans ça la réorganisation pourrissait l'instrument même qui tient la discipline qu'elle sert. Et un défaut relevé par le contrat interne, vérifié : `ng-proxy` fabriquait un membre `login`. `@ng-org/web` n'expose aucune méthode de ce nom — zéro occurrence dans les déclarations installées comme dans `sdk/js/lib-wasm/src/lib.rs` — mais le proxy répondait une fonction au lieu d'`undefined`, laquelle plantait à l'appel. C'était le seul endroit où ce wrapper ajoutait à la surface du SDK, contre son propre en-tête. 157 tests unitaires, typecheck src/test/e2e vert.	2026-08-04 12:56:02 +02:00
Sylvain Duchesne	88914f50ae	refactor(layout): ranger les modules par destin à la migration ... Les 25 modules étaient à plat, nommés d'après ce qu'ils font mécaniquement (`store-registry`, `read-model`, `reach`, `caps`). Rien dans l'arborescence ne disait lesquels DEVIENDRONT le vrai SDK, lesquels tiennent lieu du travail que le verifier fera nativement, et lesquels n'existent que parce qu'un wallet est partagé — trois destins sans rapport. Quatre dossiers, les deux fichiers d'entrée restant à la racine pour que l'`exports` du paquet et le code du consommateur ne bougent pas : - `model/` — le modèle d'adressage de la cible, transcrit : vocabulaire pur, pas d'I/O. Survit comme connaissance. - `surface/` — ce que l'app touche, chaque symbole ayant un pendant cible documenté. Supprimé quand l'alias bascule ; le code de l'app est inchangé. - `emulated-verifier/` — les doublures de ce que le verifier fait nativement : possession, dépôt des caps, frontière, non-livraison, traitement des inbox, registres de branche, ouverture de repo. **C'est le dossier où diverger du modèle est possible.** Le préfixe `emulated-` porte le sens : tient lieu de, jamais est — cette bibliothèque ne réside dans aucune couche de la cible, elle les référence. - `shared-wallet/` — n'existe que parce qu'un wallet héberge toutes les identités. Aucun pendant, rien sur quoi s'aligner ; sa seule loi est de rester invisible depuis `surface/`. S'évapore, remplacé par rien. `store-registry-api.ts` devient `surface/placement.ts` : il faisait déjà à la main ce que la frontière de dossier fait structurellement — c'est la meilleure preuve interne du bien-fondé de ce rangement. Ce commit ne fait que déplacer et recâbler les imports (src, test, e2e). Les scissions des modules à cheval suivent. 157 tests unitaires, typecheck src/test/e2e vert.	2026-08-04 12:46:44 +02:00
Sylvain Duchesne	d07b3642aa	refactor(api): séparer la surface de l'app et la machinerie ... L'entrée SDK déversait la machinerie par deux fuites : - `export * as storeRegistry from "./store-registry"` exportait TOUT le module — `ensureAccount`, `addLink`, `readLinks`, `resolveAccount`, `reservedAccount`, `resetRegistryCache`, `isOwnInbox`, `myInboxes`, `userStoreDoc`. Remplacé par `store-registry-api.ts`, qui ne ré-expose que les sept appels destinés à l'app : createEntityDoc, listMyEntityDocs, resolveScopeGraph, resolveWriteGraph, walletInbox, openDocumentInbox, documentInboxAddress. - `accounts.*` — persistance d'identité navigateur, sans aucun pendant SDK — passe sur `/polyfill`, où sa disparition à la migration se lit sur la ligne d'import. L'en-tête d'`index.ts` affirmait n'exposer « que ce que @ng-org/web et @ng-org/orm exposent ». C'était faux et enseignait une frontière fausse : un consommateur en déduisait que tout ce qui s'importe de l'entrée survit à la migration, ce qui ne valait ni pour `accounts` ni pour l'essentiel de `storeRegistry`. Il énonce désormais ce que l'entrée promet vraiment : tout symbole y a un pendant dans le futur SDK, vérifié ou assumé, et rien n'y est de la machinerie. La frontière mord : le typecheck e2e a échoué aussitôt, le harnais atteignant `ensureAccount` et `resetRegistryCache` par l'entrée publique. Il passe désormais par le chemin interne, comme les tests unitaires — légitime, il teste la bibliothèque. Deux documents plutôt qu'un, mêmes exigences, publics différents : `docs/api-contract.md` (la surface de l'app, avec pour chaque sujet la signature que le futur SDK devrait exposer, et l'étiquette qui distingue le vérifié de l'assumé) et `docs/internal-contract.md` (le complément exact). 157 tests unitaires, e2e 40/40 contre le broker en ligne.	2026-08-04 12:16:59 +02:00
Sylvain Duchesne	e5779ca850	docs: une adresse d'inbox est TRANSMISE en amont, nous la PUBLIONS ... Assertion fausse retirée de `openDocumentInbox` : « en amont, l'acte équivalent est le propriétaire qui commite AddInboxCap avec la clé du repo — personne d'autre ne le peut ». Personne d'autre ne le peut est inventé. Ce commit atterrit sur la branche User de CELUI QUI LE FAIT, donc n'importe qui peut en écrire un nommant le repo de n'importe qui. Le moteur ne pose aucune garde là-dessus. Ce qui protège en amont n'est pas une garde, c'est le mode de circulation : `inboxes: PubKey → RepoId` est une table du Verifier (`verifier.rs:105`), reconstruite vide à chaque session — l'association inbox→repo est LOCALE, pas publiée. Un déposant apprend une pubkey parce qu'on la lui a ENVOYÉE : dans un `ContactDetails` (`contact.inbox`) ou par le QR de profil. Une paire forgée n'atteint personne, faute que quiconque en ait été informé. D'où une divergence à assumer et non à maquiller : nous PUBLIONS l'adresse sur le document, seul moyen qu'un tiers la trouve dans une émulation sans canal de messages. Cela crée un vecteur que le moteur n'a pas — qui peut écrire le document peut rediriger ses dépôts — et c'est ce que la garde `ownsDocument` compense. Elle compense NOTRE conception ; elle ne reproduit aucune règle amont. Manquait aussi dans la carte des inbox dressée juste avant : elle disait qui A une inbox, et omettait comment l'adresse circule — la dimension dont tout le reste dépend.	2026-08-03 18:03:03 +02:00
Sylvain Duchesne	2406afec8b	docs: l'inbox par document n'est pas une anticipation, c'est une capacité du moteur ... Glissement à corriger : de « le moteur ne le FAIT pas » (vrai) j'ai conclu « c'est notre anticipation » (faux). Le moteur le PERMET, et de façon générique par conception : - `inbox: Option<PrivKey>` est un champ de TOUT `Repo` (`repo.rs:126`), pas d'une structure de store ; - `AddInboxCapV0` est clé par `repo_id` — « Repo the Inbox is opened for » ; - `update_inbox_cap_v0` l'applique via `self.repos.get_mut(repo_id)` sans AUCUNE vérification `is_store` (`verifier.rs:1920`) ; - et à tout moment, `AddInboxCap` étant un commit de branche User dont le type documente le cas de mise à jour. Ce qui est vrai est plus étroit : aucun chemin de code n'en CRÉE une pour un document. « Ne fait pas » n'est pas « ne peut pas » — c'est précisément l'interdit que ma propre règle pose, et je l'ai enfreint en le formulant. Donc l'inbox par document s'aligne sur le modèle du moteur (niveau 1) ; ce qui est de nous est la surface JS, aucune n'étant exposée aux niveaux 2 et 3. Corrigé dans store-registry.ts, nextgraph-current-state.md et les deux briefs.	2026-08-03 17:55:46 +02:00
Sylvain Duchesne	07312cd0a2	docs: doc_fetch_*_subscribe ne remplacent pas doc_subscribe ... Vérifié parce qu'elles ressemblent à des appels « ouvrir un repo » tout faits, ce qui aurait rendu notre `ensureRepoOpen` redondant. Elles ne le sont pas : ni l'une ni l'autre ne fait d'I/O — chacune construit un `AppRequest` et le renvoie sérialisé (`lib.rs:1890`, `:1900`), sans session_id ni callback. `doc_subscribe` construit la MÊME requête (`AppRequest::doc_fetch_repo_subscribe` → `Fetch(Subscribe)`), y ajoute la session et la passe à `app_request_stream_`. Ce sont des constructeurs de requête pour qui veut dépêcher lui-même. Donc rien à récupérer : les employer reviendrait à réimplémenter ce que `doc_subscribe` fait déjà. Et `doc_fetch_private_subscribe` ne diffère que par sa cible (le store-root privé), ce qui ne change rien à la barrière — un store-root n'en a toujours pas.	2026-08-03 17:40:50 +02:00
Sylvain Duchesne	4f5c3ed03b	docs: inbox_post_link est notre nom, pas une API NextGraph annoncée ... Le symbole n'existe nulle part dans `nextgraph-rs`, et aucune méthode de `@ng-org/web` ne contient « inbox ». Il vient de notre propre plan de fork (`docs/fork-inbox-fallback.md:32` — « expose `pub async fn inbox_post_link` »), d'où il a essaimé dans huit autres endroits, cité comme une API « proposed/ future » de NextGraph. Une proposition interne devenue un fait par répétition — le même mécanisme que « chaque document a une inbox native » et que l'inbox mutualisée. Corrigé partout sauf dans le plan de fork, où le nom est légitime puisque c'est lui qui le propose. Et l'énoncé exact est désormais posé : on ne connaît NI le nom NI la forme de la future surface JS pour les inbox — ce n'est pas « non implémenté », c'est inconnu. Ce qui est réellement vérifié côté moteur : `AppRequestCommandV0::InboxPost` existe et `AppRequest::inbox_post()` le construit, mais le request_processor n'a aucun arm pour lui — l'envoyer ne déclenche rien. Le seul dépôt qu'un client JS peut provoquer aujourd'hui passe par `import_contact_from_qrcode`, qui appelle `post_to_inbox(InboxPost::new_contact_details(...))` avec `with_readcap = false` — la variante `true` étant `unimplemented!()`.	2026-08-03 17:04:30 +02:00
Sylvain Duchesne	5a7009bd75	fix(inbox): une inbox appartient à un document, jamais à plusieurs ... Retour sur l'adresse par défaut livrée en 8a382f2, qui faisait pointer tout document vers l'inbox de son propriétaire. C'était acheter le coût au prix de la forme — le mauvais arbitrage pour cette bibliothèque. Vérifié en amont : le verifier route un message entrant par `inboxes: PubKey → RepoId` (`engine/verifier/src/verifier.rs:1677,1928`) et le déchiffre avec la moitié privée de CE repo. Et `InboxMsgBody` (`engine/net/src/types.rs:4265`) ne porte aucun document cible — il n'en a pas besoin : l'adresse EST l'identification. Une inbox appartient donc à exactement un repo, et faire tenir plusieurs documents derrière une inbox émule une relation que le modèle ne peut pas exprimer. Conséquences : - `createEntityDoc` ne publie plus rien. Un document neuf n'a pas d'inbox et `documentInboxAddress` rend `undefined`. - Une inbox s'ouvre par `openDocumentInbox(doc)`, sur décision du propriétaire. C'est aussi ce qui règle le coût sans toucher à la forme : seuls les documents destinés à RECEVOIR en paient une — l'app le sait, la bibliothèque non. - `inbox.postToDocument(doc, { payload })` : l'app nomme le DOCUMENT, jamais une inbox. Lève quand le document n'en a pas, au lieu de rendre la main silencieusement — un dépôt qui disparaît sans erreur est exactement le bug que ce chemin traînait. - Pas de champ « document cible » sur un dépôt. Ce serait une invention que les apps devraient désapprendre à la migration. README, principe de conception : les deux moitiés sont contraignantes, et c'est la seconde qu'on brade. La surface doit être au plus près du futur SDK, mais l'IMPLÉMENTATION aussi doit être au plus près de ce que NextGraph prévoit, sans exception. Ce qui est connu vaut spécification. La pression à dévier ne se présente jamais comme une déviation : elle arrive comme un coût, une latence, une gêne d'ergonomie — bien réels. Deux cas déjà rencontrés sont consignés, avec le signal commun : un choix qui ferait apprendre au consommateur quelque chose qu'il devra DÉSAPPRENDRE. 157 tests unitaires, e2e 40/40 contre le broker en ligne.	2026-08-03 16:45:28 +02:00
Sylvain Duchesne	8a382f29f8	feat(inbox): l'inbox d'un document est adressable par tout détenteur ... Répond au brief 2026-08-03 remonté depuis le consommateur. `documentInbox(doc)` répondait « quelle inbox est-ce que MOI je connais pour ce document » et en créait une quand la réponse était « aucune » : un tiers n'atteignait jamais l'inbox du propriétaire, il en obtenait une à lui, que personne ne lit, et son dépôt disparaissait sans erreur. C'est l'acte central du consommateur — s'inscrire à l'événement d'un autre — qui était silencieusement perdu. Lire une inbox et savoir où y déposer sont deux actes opposés, avec des publics opposés. Ils sont désormais deux fonctions : - `openDocumentInbox(doc)` — le PROPRIÉTAIRE ouvre une inbox dédiée. Refuse sur la PROPRIÉTÉ (lue depuis les branches Store), pas sur la possession du cap : un cap se reçoit, et un destinataire ne doit pas pouvoir rediriger vers lui les dépôts destinés au propriétaire. - `documentInboxAddress(doc)` — n'importe quel détenteur trouve où déposer. Ne crée jamais rien. L'adresse est publiée dès la CRÉATION, sur la branche Header émulée du document — un sujet réservé à l'intérieur du document, donc lisible par qui détient le document. Publier seulement le jour où le propriétaire ouvre une inbox dédiée laisserait une fenêtre pendant laquelle un tiers lit le document, ne trouve aucune adresse, et ne peut pas joindre le propriétaire du tout. Sur le coût mesuré par le brief (9m37 → 21m30) : il venait de la création d'un DOCUMENT supplémentaire par document. L'adresse publiée pointe vers l'inbox propre du propriétaire, qui existe déjà et s'amortit sur tous ses documents ; la création grandit d'un triple, pas d'un document. Le dépôt porte le document concerné, donc le propriétaire matérialise toujours par document. La forme « dérivable » du brief n'était pas disponible : notre inbox est un document, et un NURI dérivé nommerait un repo que `doc_create` n'a jamais créé. Le tout reflète la séparation d'amont : un déposant scelle avec la clé PUBLIQUE de l'inbox et n'a besoin de rien d'autre, seul le propriétaire détient la moitié privée — une adresse est donc publique par nature. `src/machinery.ts` : l'espace de noms `urn:ng-eventually:` que la bibliothèque se réserve, et le prédicat que le chemin de lecture utilise. La branche Header est le premier compartiment logé dans un document que le consommateur lit ; `read-model` écarte désormais tout sujet de cet espace, par SUJET et non par prédicat — ce qui couvre toutes les branches émulées, présentes et futures. Question ouverte du brief, tranchée : « une inbox de document adressable par tout détenteur » est une invention de cette bibliothèque, pas de l'amont — aucun document n'y a d'inbox, ni le store privé. Ce qui EST vérifié, c'est la forme qui rend l'anticipation défendable : `AddInboxCapV0` est clé par `repo_id`. Tests : le test qui validait « n'importe qui dépose » passait le NURI d'inbox au déposant par une variable du test — chemin qu'aucune app n'a. Réécrit avec les deux acteurs cloisonnés : le déposant reçoit le lien du document, qui est la seule chose qui circule dans ce modèle, et doit trouver l'adresse lui-même. Le fake `ng` gagne le SELECT de la branche Header et le `DELETE WHERE` (sans quoi un remplacement devenait une accumulation, précisément le bug qu'il évite). 157 tests unitaires, e2e 40/40 contre le broker en ligne.	2026-08-03 16:02:11 +02:00
Sylvain Duchesne	e24a20cc46	docs: le modèle applicatif partagé passe par une app singleton ... Réécriture de « Apps & services » : la version précédente déduisait la forme cible de l'absence d'implémentation dans le moteur — exactement ce que le principe de conception du README interdit — et concluait l'inverse de ce que le développeur NextGraph énonce. Deux couches désormais séparées et étiquetées comme telles : - ce que le moteur CONTIENT (vérifié) : `AppManifestV0` avec `singleton: bool`, `access_requests`, `installs`, `dependencies` ; `init(callback, singleton, access_requests)` côté JS. Et personne ne le consomme — le module `permissions` n'est importé par aucune crate, `AppManifest` n'est construit nulle part. Du vocabulaire, pas du comportement. - ce que le modèle SERA (énoncé par le développeur, non implémenté) : une app singleton peut aussi gérer les documents par utilisateur ; les données communes prennent la forme d'un document ou d'un store partagé par tous les utilisateurs et codé en dur dans l'app ; le développeur détient les droits d'écriture et peut les déléguer, jamais à tous — les contributions arrivent par une inbox. Le commentaire du champ dit `/// cannot create Documents?`, avec le point d'interrogation. Une seconde glose publiée le contredit et rejoint ce que dit le développeur : `sdk/js/web/README.md:90,108` annote l'argument « will your app create many docs in the system, or should it be launched as a unique instance » — `singleton` porte sur la multiplicité d'instance, pas sur une interdiction de créer des documents. C'est cette lecture qu'il faut retenir. Conséquence sur l'ADR discovery : sa moitié « la voie app singleton est incertaine » est caduque et doit être re-posée, sans que cela rétablisse la découverte, qui tient sur son propre appui.	2026-08-03 16:01:46 +02:00
Sylvain Duchesne	33751388fe	Ask that a document's inbox be addressable by anyone holding the document ... `documentInbox(doc)` answers "which inbox do I know for this document?" and mints a fresh one when the answer is none. A third party therefore never reaches the owner's inbox: they get one of their own, the owner never reads it, and the deposit vanishes with no error. That breaks the consumer's central act — signing up to someone else's event — and it blocks the directory document that has to replace discovery, since creators must deposit into a document they do not own. The consumer tried solving it on its side: resolve the address once at creation and publish it on the public document, so participants read it instead of deriving it. It works, and it is still the wrong place. It puts a technical address into a domain shape; it doubles document creation on every event, since resolving an inbox creates one (the @data suite went from 9m37 to 21m30, with sign-up scenarios timing out during setup on a FRESH profile — not wallet bloat); and the library already claims this job, having stated when per-document inboxes landed that draining them "is the library's job, not the app's". Addressing is the other half of that same job. The app-side change is reverted. No shape is prescribed here. Deriving the address from the document would cost nothing and match how the rest of the model works — an overlay is derived, a keyring is looked up, nothing is handed over out of band — with the read guard keeping the asymmetry where it belongs. Publishing it library-side would work too and leaves room to make it lazy. One question decides where this note ultimately belongs: is "a document has an inbox addressable by any holder" part of NextGraph's target model, or this library's own invention? Upstream, it is emulation to align; otherwise it is a design decision to take deliberately.	2026-08-03 14:47:13 +02:00
Sylvain Duchesne	88f396a7ac	fix(caps): créer un document en donne le cap, + corriger 9 faits NextGraph ... Le trou trouvé par l'e2e contre le broker en ligne : `docs.docCreate` ne déposait aucun cap pour le créateur, donc un consommateur pouvait créer un document par la primitive publique puis se voir refuser sa lecture et son écriture. En amont c'est impossible — `doc_create` commite `AddRepo { read_cap }` sur la branche Store du store, et le créateur le détient dès le premier instant. Délibérément non répliqué dans `physical.ts` : les documents du shim n'appartiennent à aucun utilisateur virtuel, et `store-registry` classe leurs caps là où il sait à qui ils sont. e2e : 22 passés / 8 échoués → 39 / 0. Les autres échecs venaient du harnais, qui agissait comme une seconde identité sans l'établir, ou lisait un document quelconque comme une inbox. Un run e2e contre un wallet persistant exige une identité FRAÎCHE par run : `walletInbox(id)` rend l'inbox stable pour son propriétaire — c'est son intérêt — donc un id fixe accumule les dépôts des runs précédents (vert au 2e run, rouge au 3e, à code inchangé). Revue adverse de la documentation, 9 défauts, tous vérifiés à la source avant correction : - « chaque document a une inbox native » est FAUX. Seuls les repos de store public et protected en ont une (`site.rs:128,149`) ; `new_store_default` n'en pose que `if !private` et `doc_create` laisse `inbox: None`. Le store privé n'en a pas non plus. Ce que le code fait est donc une ANTICIPATION — assumée et notée comme telle dans `documentInbox`, le brief et l'ADR discovery. Ce qui est vérifié, c'est la FORME : `AddInboxCapV0` est clé par `repo_id`. - `InboxMsgContent::Link` est une variante unit sans charge utile : l'inbox ne transporte aucun ReadCap. `shareCap` était juste et le reste ; ses citations sont complétées aux deux bouts (émetteur `unimplemented!()`, récepteur qui ignore `details.read_cap`). - les 3 stores appartiennent au user (`SiteV0`), pas au wallet ; - le TODO `OpenRepo` ne concerne pas la lecture cross-wallet — il est dans `open_branch_`, après `RepoNotFound` ; charger par cap, c'est `load_repo_from_read_cap` ; - la liste des méthodes JS était un sous-ensemble présenté comme la surface (77 exportées) ; - `outbox-log.ts` n'enregistre rien : il inspecte l'outbox du SDK ; - l'ADR private-store-nuri-scope citait `orm_start_graph` au présent, remplacé par `ensureRepoOpen` ; - l'incident write-loss plaçait `disconnections_sender.send` dans `broker.rs` ; - la section « Apps & services » n'a aucune citation et rien ne lui correspond dans le moteur : marquée à re-confirmer, pas à citer comme vérifiée. Aussi : `fileOwnCaps` n'existe plus (`holdOwnCap` / `readStoreCaps` / `fileOwnStructure`) — pointeur mort corrigé dans `caps.ts`.	2026-08-03 12:17:40 +02:00
Sylvain Duchesne	9d3e2d2bfe	Fix documentation defects found by an adversarial review ... Fifteen findings, all verified before acting. The ones that mattered: - Corrections added without updating what they corrected. §5's table still said a cap-less NURI is one "without :k:", two hundred lines after §4 established the discriminant is `r:`. Same shape of defect in the P1a report, which kept the sentence "it is the owner's keyring, upstream the keyring is the wallet" — the exact sentence §4quater declares wrong, and the one that produced a global in-memory keyring. - A wrong source citation: RootCapRefresh/BranchCapRefresh live in verifier/src/commits/mod.rs, not repo/src/commit.rs, and are no-op stubs. - Documentation describing deleted code: isolation.ts, discovery.readIndex, the global index, and an acceptance test that was dropped with discovery. - The P1a implementation report had aged into being wrong in four places (caps not persisted, inbox processing not started, plain string types, the :k: segment). It is dated, so it now carries a header saying what later lots overtook, rather than being rewritten. - vision.md stated "a document's data is stored encrypted" in the present tense. That is the target; here the cap value is the constant OK and nothing is encrypted. Said plainly now. - Prose left mangled by an earlier mechanical find-and-replace, in four places I had claimed were repaired. Also: reach.ts and connect.ts had no home in the permanent docs — the boundary and the connection sequence are now described in simulation.md, not only in a brief.	2026-08-03 11:34:24 +02:00
Sylvain Duchesne	ae9c32e271	Align the cap emulation on NextGraph's model, and confine it to a virtual user ... Two batches, verified against nextgraph-rs throughout. P1a — the capability surface. Reading was an ACL (Map<doc, Set<principal>>), the exact inversion of key possession. It is now possession: `capFor(nuri)` is the only question, there is no principal parameter anywhere, and nothing turns a bare reference into a cap. Sharing is `shareCap(cap, toInbox)`, a Link deposit; receiving needs no operation. `Nuri` and `ReadCap` are template literal types, so passing a bare reference where a cap belongs is a compile error, with runtime guards behind it for JavaScript callers. The virtual user boundary. Every access function is now confined to the connected user, through two rules on one criterion (possession), implemented in two places so a lapse in either is caught by the other: authorization at the passage points, and "do not even attempt" at the callers. The polyfill's own machinery moved to physical.ts — unguarded, never exported — which replaced an exemption list: the machinery no longer gets waved through the guard, it calls something the guard never saw. Removed, as emulating capabilities the target does not have: - discovery.ts and its global index. There is no discovery in NextGraph; you follow links. It also pooled user data across wallets. - the cross-account fan-out (listEntityDocs, resolveReadGraphs, allAccounts, loadShim), which was cross-user enumeration by construction. - resolveInboxAnchor, a single inbox common to every user. Caps are now stored where NextGraph stores them, and read back rather than recomputed: AddRepo on the store's Store branch for documents a user creates, AddLink on its User branch for caps received. Inboxes belong to someone — the user's own, plus one per document — and connecting a user drains them all; that is the library's job, not the app's. Corrections worth recording: a ReadCap is `r:`, not `:k:` (reported by NextGraph's developer, verified in BlockRef::readcap_nuri); received caps DO have a register (AddLink), contrary to what this repo's notes claimed; and "wallet" upstream means keyring — what owns three stores is a user, so the vocabulary follows. The cap value is the constant OK: the only question the emulation answers is whether a cap is held. P1b replaces that one constant with a real key. After this the shape is right and the isolation is still fake. Nothing here may be described as anonymous or private.	2026-08-03 11:22:01 +02:00
Sylvain Duchesne	6f0d0586e2	docs(brief): passer le brief caps en anglais et solder trois incohérences ... Dernier document du dossier docs/ encore en français. Traduction fidèle : mêmes sections, mêmes tableaux, mêmes items, mêmes balises. Glossaire repris tel quel du passage précédent pour que le vocabulaire soit cohérent d'un fichier à l'autre. Les DEUX passages délibérément rétractés sont préservés à l'identique — la section barrée « Widened scope: the WriteCap (= membership) » avec son bloc <details>, et le lot barré PW dans la liste des phases. Ils sont là comme garde-fous : sans eux, quelqu'un re-proposera ces idées, qui paraissent toutes raisonnables au premier abord. C'était le risque de la traduction — nettoyer ce qui ressemble à du bruit — d'où la vérification chiffrée demandée. Trois incohérences relevées à la relecture et corrigées : - La liste des phases décrivait encore l'ANCIENNE P1a (types de marque DocRef/DocCap, resolveCapLess, sealCapTo durable) et renvoyait à « Specified above », qui ne pointait plus vers rien depuis l'extraction du lot dans sa propre fiche. Créée par ma restructuration : j'avais remplacé la section sans toucher à son résumé ailleurs. - « Open questions » demandait encore si le fetch keyless devait être permis, alors que le verdict corrigé plus bas tranche la question négativement. Conservée barrée : l'hypothèse est intuitive et se reformerait sinon. - La revue adverse annonçait 6 constats et en listait 7. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-28 15:59:37 +02:00
Sylvain Duchesne	0d52c82ba9	docs: passer vision, readcap-and-nuri-model et l'incident en anglais ... Le reste du dossier docs/ était déjà en anglais ; ces trois fichiers avaient été rédigés en français par erreur. Traduction fidèle, sans changement de fond : mêmes sections, mêmes tableaux, mêmes blocs de code. Le retour à la ligne dur à 78 colonnes est levé (une ligne par paragraphe, convention du projet). Marqueurs épistémiques préservés et rendus aussi visibles : VERIFIED / INFERRED / CORRECTED / DIRECTION / GAP. Les citations verbatim de commentaires amont restent intactes. Deux incohérences de FOND signalées par la traduction et corrigées ici — elles étaient invisibles tant qu'on lisait chaque section isolément : - readcap-and-nuri-model, section « Caveats / gaps » : elle listait encore le fetch keyless comme hypothèse INFÉRÉE à confirmer, alors que le bloc CORRIGÉ du §4bis la déclare fausse et non constructible. Contradiction interne née de ma correction partielle. Conservée barrée plutôt que supprimée : l'hypothèse est intuitive et se reformera sinon. - incident write-loss : l'intro affirmait en fait établi que « l'écriture n'atteint jamais durablement le broker », alors que la réserve épistémique plus bas dit explicitement que l'alternative (perte d'écriture vs réhydratation à froid) n'est pas tranchée. L'intro ne rapporte plus que le symptôme observé. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-28 15:51:22 +02:00
Sylvain Duchesne	518292498a	docs(brief): extraire P1a dans son propre brief, en anglais ... P1a n'était qu'une section d'un brief de ~370 lignes charriant beaucoup de matière rétractée (lot PW barré, section membership en <details>, verdicts corrigés). Coder depuis ce fichier aurait été pénible et risqué. docs/briefs/2026-07-27-p1a-cap-surface.md — le lot actionnable, lisible seul : - un seul type nouveau, ReadCap, le nom de l'amont ; - capFor(nuri) sur le trousseau (la branche de store), avec l'avertissement que le trousseau n'est PAS le mécanisme de partage ; - shareCap(cap, toInbox) — un document, vers une ou plusieurs inboxes ; - rotation de clé : re-livraison automatique, rien à implémenter côté consommateur ; - contenu public : lisible par l'URL, non récursif ; - la frontière index.ts / polyfill, tranchée : signatures sur des chaînes, comme le vrai SDK ; - le test de recette sans crypto (watch-shape moissonne aujourd'hui toute chaîne did🆖 et la replie dans l'ensemble LU) ; - et ce que le lot ne fait PAS, pour ne pas le croire fini. Chaque écart écarté y est justifié plutôt que tu : types de marque, resolveCapLess, receivedCaps, refOf, parseNuri, PrincipalId. Le premier jet introduisait 8 notions nouvelles ; il en reste 2, et le critère est écrit noir sur blanc — toute notion inventée est une dette de vocabulaire. Le brief d'origine reste le chantier d'ensemble et pointe vers la fiche. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-28 15:44:24 +02:00
Sylvain Duchesne	b2cb774124	docs: état courant NextGraph enrichi + modèle cible aligné + retrait du lot PW ... MODÈLE CIBLE (readcap-and-nuri-model) — trois ajouts, deux corrections : - Store public : lisible par l'URL, et NON récursif — un contenu public peut référencer du contenu privé sans y donner accès. C'est la non-récursivité qui porte la valeur (objet public pointant vers de l'identité privée). - Le trousseau : la branche de store, où chaque création commite AddRepo{read_cap} — avec l'avertissement explicite que ce n'est PAS le mécanisme de partage. Confondre l'index privé et le geste de partage mène à « on partage le store », ce qui livrerait tout son contenu présent et futur. - Rotation de clé : re-livraison par inbox, traitée automatiquement à la connexion. Écrit comme DIRECTION, en signalant que le commentaire amont dont ça partait décrit l'état courant. - Levée de la confusion did/NURI en tête de la section grammaire : `did🆖` est un préfixe de schéma présent partout, pas un marqueur de « sans cap ». C'est un seul objet, avec ou sans la clé dedans. - Livraison de cap par inbox signalée comme MANQUE (forme bonne, chemin absent). ÉTAT COURANT (nextgraph-current-state) — 218 lignes ajoutées, structure intacte : livraison de cap par inbox non implémentée ; vérification de signature d'auteur jamais appelée au runtime (members map vide, //TODO) ; aucune sonde d'existence au niveau SDK ; expose_outer codé en dur à false, absent du SDK ; protocole Ext sans aucun contrôle. Plus trois constats d'exploitation : heal cold-start, fork de compte sur provision concurrente, et l'abort du flush outbox sur TopicNotFound. La mort du socket est seulement référencée (déjà couverte). CORRECTION D'UN FAIT QUE J'AVAIS ÉNONCÉ FAUX : le digest d'auteur n'est PAS clé sous le secret de lecture — il est clé par l'overlay outer, public. C'est le CONTENU du commit qui est chiffré. La conclusion « vérifier suppose de pouvoir lire » tient, le mécanisme diffère. Lot PW (WriteCap = membership) RETIRÉ de la liste des phases : il restait planifié alors que le brief déclare plus haut qu'il n'y a pas de membership. Il était en outre justifié par un besoin de dédup par signature que le consommateur n'a pas — sa dédup s'appuie sur l'overlay. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 17:42:14 +02:00
Sylvain Duchesne	8764daff4f	docs: corriger la rotation de clé et poser le principe du store public ... Deux corrections de direction, données par le PO — et les deux viennent de la même erreur de méthode : avoir lu l'ÉTAT COURANT du source comme s'il donnait l'INTENTION. C'est précisément ce que ce brief met en garde de faire. 1. Rotation de clé. La spec disait « qui n'est pas resté abonné perd l'accès » et demandait d'exposer une obligation d'abonnement au consommateur. Faux comme cible : quand une clé tourne, la nouvelle est envoyée dans l'inbox des ayants droit, et cette inbox est traitée automatiquement à la connexion suivante d'un client. L'accès n'est pas perdu, il est différé — cohérent avec le local-first. Donc rien à implémenter côté consommateur, et la re-livraison emprunte le même canal que la livraison initiale : le mécanisme de partage couvre les deux sans cas particulier. 2. Store public. Principe à exposer tel quel : un élément du store public est public — qui a l'URL lit le contenu — mais PAS récursivement. Un contenu public peut référencer du contenu privé sans donner accès au référencé. C'est la non-récursivité qui porte la valeur : elle permet un objet public pointant vers de l'identité privée, le cas exact du consommateur. NextGraph s'oriente par ailleurs vers un non-chiffrement du contenu public (données toujours signées) : détail d'implémentation dont la surface ne doit pas dépendre. Si le store public ne se comporte pas comme le principe le décrit, c'est le polyfill qui s'adapte, pas le consommateur. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 17:05:36 +02:00
Sylvain Duchesne	60a9fd3ede	docs: réécrire P1a après double revue adverse, corriger le verdict Q1 sur-lu ... Deux adversaires à mandats disjoints (alignement NextGraph / économie conceptuelle). Résultat : P1a fond de 8 notions nouvelles à 2, et un fait que j'avais consigné comme VÉRIFIÉ était sur-lu. CORRECTION DE FOND — le fetch keyless n'est PAS constructible. Le spike P0 concluait « Q1 OUI partiel, seul garde : l'overlay ». Il s'arrêtait au contrôle d'accès sans regarder l'ADRESSAGE : aucune commande d'existence au niveau SDK ; la seule sonde est interne au crate, exige des BlockId ET un repo chargé, et vise l'overlay inner dérivé du secret de lecture. Une référence cap-less porte un RepoId et l'overlay outer — ni BlockId, ni le bon overlay. L'adressage présuppose le cap. Note corrigée sur place (pas empilée), avec la leçon transposable : vérifier qu'une garde laisse passer ne prouve pas qu'une opération est atteignable — encore faut-il pouvoir NOMMER ce qu'on demande. P1a réécrite : - UN seul type nouveau, `ReadCap`, le nom de l'amont. `Nuri` reste ce qu'il est déjà (~90 usages) : la forme cap-less. Les types de marque disparaissent — le SDK réel prend `nuri: String` et enforce au RUNTIME par la crypto ; une garantie de compilation est un concept que NextGraph n'a pas, et un consommateur qui typerait tout devrait dé-typer plus tard. - `capFor(nuri) → ReadCap | undefined` : le trousseau. Comble un trou fatal du premier jet — `doc_create` renvoie un NURI cap-less, donc l'invariant « on ne va jamais d'une référence nue à un cap » empêchait le créateur d'obtenir le cap de son propre document. Le trousseau existe déjà : la branche de store, où chaque création commite AddRepo{read_cap}. En amont c'est le wallet. - `shareCap(cap, toInbox)` : on partage UN DOCUMENT, à une ou plusieurs inboxes. Pas le store — donner un cap de store livrerait tout son contenu présent et futur. Les caps reçus arrivent comme dépôts d'inbox, consommés par le inbox.watch existant (ce qui règle le point 7 de la revue adverse). - Durabilité : ne PAS la promettre. Verbatim amont, les caps sont « not durable » et qui ne reste pas abonné perd l'accès ; PermaCap est un TODO. La surface doit exposer l'obligation d'abonnement, sinon le consommateur retient des caps morts. - `PrincipalId` sort de la surface caps : n'existe pas en amont, et le brief le supprimait de canRead en le qualifiant d'inversion ACL avant de le réintroduire dans sealCapTo. On adresse des inboxes, comme inbox.post le fait déjà. - Section 0 conservant les erreurs du premier jet : elles sont instructives. - Exception publique actée : un lien de repo public n'a PAS de read_cap (il se télécharge depuis l'outer overlay) — pour du public, « référence nue → contenu » est bien la forme cible. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 16:08:02 +02:00
Sylvain Duchesne	d7e0ee6a4b	docs(brief): spécifier P1a (la surface) et corriger l'inventaire des contournements ... Découpage de P1 en deux natures de travail : P1a = la FORME exposée aux consommateurs, P1b = l'ENFORCEMENT. Seul P1a bloque Festipod, puisque l'app doit être écrite comme si NextGraph était fini. Après P1a la forme est juste et l'isolation reste fausse — le brief le dit explicitement pour qu'on n'affirme rien d'anonyme avant P1b. P1a spécifié : - Types DocRef / DocCap distincts À LA COMPILATION (aujourd'hui `Nuri = string`, aucun parseur, aucune notion de segment de clé). L'invariant central : AUCUNE fonction ne va de DocRef vers DocCap — on n'obtient pas un cap en le demandant, seulement en le recevant. Le compilateur refuse alors de lire depuis un identifiant nu, et le consommateur ne PEUT PLUS écrire le modèle mental faux. - resolveCapLess(ref) → { exists }, jamais de contenu et jamais d'état `deleted` (vérifié : la cible ne pourra pas l'offrir). - sealCapTo(cap, recipient) durable + receivedCaps(), qui remplacent grantRead. Trois deltas réels vs l'ACL : durabilité, livraison-chez-le-destinataire, re-partage par le détenteur. C'est ce qui fait disparaître declareConnections. - Table de ce qui disparaît : le paramètre `principal` de canRead EST l'inversion ACL ; resetCaps doit BASCULER de trousseau, pas effacer, sinon la durabilité est un mensonge. - Test de recette naturel : watch-shape moissonne aujourd'hui toute chaîne `did🆖` et la replie dans l'ensemble LU — sémantique exactement inversée. Avec les types, elle ne peut plus qu'être résolue en existence. Vérifiable sans une ligne de crypto. Corrigé aussi : l'inventaire des contournements était écrit beaucoup trop doucement. Cartographie vérifiée — seuls 4 sites consultent les caps ; l'inbox entière, store-registry (racine de confiance compte→NURI), discovery.readIndex, subscribe et open-repo rendent de la donnée sans garde. Et le garde d'ÉCRITURE est déjà mort-né : docs contourne ng-proxy par conception et tous les écrivains internes passent par docs — grantWrite/canWrite ne se déclenchent jamais. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 14:48:48 +02:00
Sylvain Duchesne	ead5aececf	docs: l'overlay est store-scopé ; retrait de la fausse piste "membership" ... readcap-and-nuri-model — nouvelle section sur l'OVERLAY, le concept qui manquait à la référence. C'est l'espace réseau d'un STORE : deux formes (outer = BLAKE3 public du store_id, calculable par tous ; inner = BLAKE3 keyed par le ReadCapSecret, réservé aux détenteurs de la clé). Le `✌️` d'un NURI de DOCUMENT porte l'overlay de son store — VÉRIFIÉ de bout en bout, avec une contre-preuve mécanique : dans Store, get/put/del/has passent tous `&self.overlay_id`, donc tous les documents d'un store partagent le namespace de blocs et un overlay par-document est structurellement impossible. Conséquence documentée, qui contraint tout modèle de présence anonyme : le `✌️` est un pseudonyme stable et permanent de la personne, présent dans toute référence cap-less vers n'importe lequel de ses documents protected. Le même bit d'information sert à dédupliquer sans lire ET à tracer — indissociables. vision — correction d'une forme fausse. Le document affirmait « écriture = membership/permissions », en miroir de « lecture = possession de clé ». Faux : il n'y a pas de notion d'appartenance dans le modèle, uniquement des clés et des URLs. Toute forme en member/role/permission est une MAUVAISE forme. brief caps — la section « périmètre élargi : WriteCap = membership » est retirée, conservée barrée comme garde-fou, avec la leçon de méthode qui vaut plus qu'elle : lire l'état courant de nextgraph-rs pour en DÉDUIRE la forme cible est une erreur — le source contient de l'échafaudage inerte (AddMember, PermissionV0, verify_sig jamais appelé hors tests). Le source sert à vérifier un mécanisme, jamais à inférer une intention. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 12:07:24 +02:00
Sylvain Duchesne	1791c31f42	docs: vision du polyfill (shape-fidelity), modèle ReadCap/NURI réel, brief caps ... vision.md — la charte : le polyfill n'est PAS une couche de sécurité (wallet partagé + pas de crypto = insécurité ACCEPTÉE) ; seul objectif = exposer la BONNE FORME des primitives futures pour que les consommateurs n'aient rien à réécrire. Invariant tenu par une simulation crypto légère : un `did` nu (sans ReadCap) ne permet PAS de lire ; un NURI avec ReadCap est suffisant et requis. readcap-and-nuri-model.md — le vrai modèle, VÉRIFIÉ par lecture de `nextgraph-rs` : ReadCap = ObjectRef {id BLAKE3, clé ChaCha20} = possession de clé, PAS une ACL ; grant = sceller la clé à l'inbox du destinataire ; révocation = re-key grossier et non-rétroactif ; grammaire NURI cap-less vs cap-porteur (le segment `:k:` est le discriminant) ; table des divergences avec l'émulation `caps.ts` (aujourd'hui une ACL — l'inversion exacte). briefs/2026-07-20-caps-emulation-alignment.md — le chantier d'alignement : spike P0 keyless-resolve (verdicts vérifiés : existence sans clé OUI, détection de suppression sans clé NON, confidentialité OUI), puis P1 cap-less vs cap-porteur, P2 possession, P3 re-key, P4 migration d'API. Inclut la revue adverse (WriteCap = membership et non possession ; sans crypto la privacy de lecture n'est pas applicable ; migration = re-architecture consommateur). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-27 11:30:33 +02:00
Sylvain Duchesne	127ca3159e	docs: known issues (perte écriture, réhydratation à froid, écho auto-écriture) + gap 4 sdk-reference ... Section 'Known open issues' dans nextgraph-current-state (A ouvert, B indéterminé, C hypothèse-en-cours) + gap 4 (auto-écho non confirmé) dans sdk-reference. Statuts préservés. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-20 13:16:51 +02:00
Sylvain Duchesne	138d37c02f	docs(incident): perte d'écriture sur mort de socket (SerializationError) ... Post-mortem 2026-07-14 (ouvert) : symptôme + preuves Firefox verbatim, chaîne causale tracée (socket→Disconnected→reconnexion en TODO), réserve (i) perte-écriture vs (ii) réhydratation à froid, repro @data décisive (test de reconnexion existant faux-vert = lecture IndexedDB locale). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg	2026-07-14 18:58:38 +02:00
Sylvain Duchesne	3547967d37	chore(client): retirer la migration legacy + alléger les logs d'accès ... - Migration des comptes legacy supprimée (migrateLegacyRecords + garde migratedInto + call-sites). Un wallet pré-fix (records store-root, pas de pointeur) provisionne simplement un doc-shim frais; contenu legacy ignoré (voulu, données = dev). La résolution barrière-autoritative + anti-fork (resolvePointer/ensureRepoOpen/ canonicalDoc/ensureInFlight/pointerGuard) est inchangée. - Logs d'accès SDK préfixés [polyfill] + NURI tronqué via shortNuri() (retire did:ng:o: et :v:…, garde 8 chars) → moins verbeux. Ex: [polyfill] [user1] READ vDlwbZio… (resolvePointer) → 1 triple-rows Tests: bun test unit 126/0. Docs (nextgraph-current-state/simulation/migration-guide) mis à jour (migration legacy retirée du modèle décrit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 18:08:30 +02:00