Sylvain Duchesne
b98fcaa77d
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.
55 lines
3.1 KiB
TypeScript
55 lines
3.1 KiB
TypeScript
/**
|
|
* The app-facing slice of `store-registry` — and the reason it exists as a file.
|
|
*
|
|
* `store-registry.ts` holds two things that must not be exported together: the
|
|
* placement/addressing calls a consumer application legitimately makes, and the
|
|
* shim machinery that makes virtual users work at all (account resolution, the
|
|
* durable cap registers, the inbox-ownership predicate, cache resets). Until now
|
|
* `index.ts` did `export * as storeRegistry from "../shared-wallet/account-registry"` and shipped
|
|
* both, so an application could reach `ensureAccount`, `addLink` or
|
|
* `resetRegistryCache` from the SDK-identical entry — machinery it must never call,
|
|
* on the entry whose whole promise is "this survives migration unchanged".
|
|
*
|
|
* What is re-exported here is only what an application needs to do its own work,
|
|
* and each has a target-SDK counterpart (see `docs/api-contract.md`). Everything
|
|
* else stays reachable at `./store-registry` for the library's own modules, the
|
|
* unit tests and the e2e harness — an internal path, not a published one.
|
|
*
|
|
* At migration this file disappears: placement becomes the user's real per-scope
|
|
* stores and the calls below become native SDK ones.
|
|
*
|
|
* **No inbox ADDRESS is published here**, deliberately (`userInbox`,
|
|
* `documentInboxAddress`, removed 2026-08-05). An application deposits with
|
|
* `inbox.postToDocument(doc, …)`, shares with `inbox.share(doc, toUser)` and reads
|
|
* its own with `inbox.readForDocument(doc)` — always naming a document or a person,
|
|
* never an address. Upstream an address is resolved from a profile and never handled by
|
|
* a caller, so exposing one taught a step that has to be unlearned. The example
|
|
* application is the check: it must never name an inbox.
|
|
*/
|
|
|
|
export {
|
|
/** Create a document for ONE entity in `scope`, and record it in that scope's store. */
|
|
createEntityDoc,
|
|
/** The entity documents this user owns in `scope` — with their caps recovered. */
|
|
listMyEntityDocs,
|
|
/** The NURI to use as a READ scope for `scope` (what `useShape` is pointed at). */
|
|
resolveScopeGraph,
|
|
/** The NURI where GROUPED entities of `scope` are written (no per-entity document). */
|
|
resolveWriteGraph,
|
|
} from "../shared-wallet/account-registry";
|
|
|
|
/** Open an inbox on a document you OWN, so others can deposit into it. */
|
|
export { openDocumentInbox } from "../emulated-verifier/branch-registers";
|
|
|
|
// No `linkTo` here, and its absence is deliberate (it existed 2026-08-06, one day).
|
|
//
|
|
// It returned a document's KEY where a caller would ask for its reference, which turns
|
|
// the access rule from "whoever has the reference AND the key reads" into "whoever has
|
|
// the reference reads" — see `docs/readcap-and-nuri-model.md` § 0. That is not a leak of
|
|
// hygiene, it is the rule changing: a document one circulates would grant everything it
|
|
// MENTIONS, and confidentiality could no longer be composed inside a shared document.
|
|
//
|
|
// An application names a document with the reference it already has (every call here
|
|
// returns bare ones), and grants access with `inbox.share(doc, toUser)`. What travels
|
|
// with a key in it is a deliberate act, not the result of asking for a link.
|