3 Commits

Author	SHA1	Message	Date
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	44a9b6ee04	test: quatre tests prouvaient autre chose que ce qu'ils annonçaient ... Lot D de la revue adverse. Aucun changement de comportement de la bibliothèque : ce sont les tests qui mentaient, et deux faux `ng` qui fabriquaient un état que le vrai broker ne produit pas. **« Un tiers résout l'inbox d'un autre utilisateur » prouvait le CACHE.** `userInbox` indexe par (compte, portée) sans regarder qui demande, donc Bob tombait sur l'entrée que la session d'Alice venait de chauffer. Rien de la persistance n'était exercé — le faux ne servait même pas la requête `docInbox` — si bien que dans une seconde SESSION, ou une seconde page de navigateur comme en pilote la suite applicative, Bob aurait obtenu une inbox DIFFÉRENTE et son dépôt serait parti où personne ne lit. C'est la panne que cette bibliothèque a déjà payée une fois. Deux causes, toutes deux dans les faux : la requête `docInbox` n'était servie nulle part, et le faux de `cross-user-access` prenait le **nom de graphe** pour le sujet dans un `INSERT DATA { GRAPH <g> { … } }` — donc le pointeur du shim n'était jamais retrouvé et chaque résolution à froid créait un nouveau shim. Les deux corrigées, et les tests qui franchissent une frontière d'identité purgent maintenant le cache à la frontière. **Mon propre index d'inbox avait le même défaut**, découvert en faisant ça : `isKnownInbox` ne répondait que par sa mémoire, parce qu'aucun faux ne servait la requête. La moitié durable n'était pas exercée — exactement la faute que ce lot corrigeait ailleurs. **« Connecting drains BOTH levels » n'observait pas le second niveau.** Rejoué contre un `connectedUser` qui ne draine que les inbox de l'utilisateur, il restait vert. La raison n'est pas un test faible : le second niveau n'a **aucun producteur**. Le seul appel qui dépose un cap est `inbox.share(doc, toUser)`, qui résout l'inbox d'un UTILISATEUR, jamais celle d'un document. Drainer une inbox de document n'applique donc rien. Le test dit désormais ce qu'il prouve, et l'anticipation est nommée comme telle : en amont `AddInboxCap` est générique sur les repos et `InboxMsgContent::Link` existe, donc viser cela est légitime — annoncer que c'est exercé ne l'était pas. **« La liste de Bob ne contient pas la note d'Alice » n'avait pas de contrôle positif.** Bob n'écrivait jamais de note publique : sa liste était vide quoi qu'il arrive. Il en écrit une maintenant, et la vérification symétrique est ajoutée. Au passage, `showScope` lisait le DOM avant le rendu — le gestionnaire `change` de l'application lance `refresh()` sans l'attendre. 189 tests unitaires, e2e 40/40 et applicatif 12/12.	2026-08-10 09:10:51 +02:00
Sylvain Duchesne	aa6bbc436e	test(e2e): les parcours applicatifs passent par l'app d'exemple ... Une seconde suite e2e, `packages/sdk/e2e/notebook.ts` (`test:e2e:app`), qui pilote `examples/notebook` par le DOM — une page de navigateur par identité — contre le même broker réel. **Pourquoi une seconde suite plutôt qu'un ajout dans la première.** `run.ts` parle à un sac de méthodes sur `window.__sdk` : cela prouve que les fonctions TOURNENT, jamais qu'une application peut s'écrire avec. L'écart a déjà coûté un défaut livré — l'inbox d'un document était verte ici et inutilisable en pratique, parce que le harnais pouvait faire traverser une adresse d'une identité à l'autre par une variable, canal qu'aucune application n'a. Ici, rien ne traverse que ce qui traverse dans la vie : la RÉFÉRENCE d'une note, recopiée d'un écran, et un identifiant tapé dans un champ. Quatre parcours, qui se lisent comme des parcours : - Bob lit la note publique d'Alice depuis sa seule référence — la propriété pour laquelle l'émulation du store public existe, vérifiée bout en bout et sans qu'aucune clé ne circule ; - la note protégée d'Alice reste fermée jusqu'à ce qu'elle la partage — même geste côté Bob, issue opposée, décidée par où la note se trouve ; - Bob laisse un message sur la note d'Alice, et seule Alice le lit — il TROUVE l'adresse depuis la note, personne ne la lui donne ; - la liste de chacun ne contient que ses notes. **Deux étapes quittent `run.ts`** (`documentInboxDeposit`, `capsShareCap`), avec un commentaire disant où elles sont parties : ce sont des parcours, et ils valent plus joués sur deux écrans que sur deux appels d'une même page. Ce qui reste là-bas est ce qu'une application ne fait pas : primitives, caractérisation, régressions de démarrage à froid. **Trois défauts trouvés en écrivant la suite**, tous côté application et invisibles pour le harnais : `connectedUser()` devait être attendu à la connexion (sinon une note qu'on vient de vous partager se lit comme illisible — ce qui ressemble à un problème de droits alors que c'est un problème de moment) ; une réponse périmée restait affichée à côté d'une question fraîche ; et changer de portée ne rafraîchissait pas la liste. L'app affiche désormais la référence de chaque note — ce qu'aucun écran ne montre, aucun utilisateur ne peut le faire circuler. Corrigé au passage : le `.gitignore` pointait encore `packages/client/`, si bien que le commit de renommage a embarqué le profil Playwright de la suite e2e (226 fichiers). Les chemins sont réalignés et le commit précédent a été amendé — rien n'était poussé. 179 tests unitaires, e2e 40/40 (3,2 min) et applicatif 10/10 (0,7 min).	2026-08-07 11:20:58 +02:00