Code against the polyfill's published contract, and nothing else

The data layer is now reached through one pulled, version-pinned engagement
(`.project/concepts/data-layer/contract_polyfill-surface.md`, @1ecf511e9d).
That copy is the only reference: the provider's sources are never opened, and
what the contract does not answer is a gap raised with it, never worked around
here.

Surface
- `@ng-eventually/sdk` -> `@ng-eventually/polyfill`, one entry point.
- `configure` loses `getSession`, `normalizeId`, `currentUser`; the session
  belongs to the package and its own `init` captures it.
- Placement is named by scope alone -- a session is one user, so the app no
  longer passes an identity it had no way to obtain. This removes a constant
  that made every user collide on one owner's document.
- `init(...)` then `await ensureIdentity()`, in that order, as one sequence:
  React runs child effects first, so the two calls sat in the wrong order and
  the contract now makes that throw.
- `sessionId` relayed as `string | number`, `materialize` -> `read`.

A rejection means "unknown", never "absent"
Four places treated a caught error as an empty result. The worst wrote a
duplicate participation: an unknown count read as zero defeated the idempotence
guard of `joinEvent`. Also fixed: a per-document count, a silently dropped
notification shown optimistically anyway, and a failed listing that left the
owned-event set empty and disabled the materializer for the whole session.

Shared identity is not a Festipod notion
A browser context is one user. The per-scenario identity plant is deleted at
its source and its five sites; what stays is the deployment's wallet file,
which the contract requires an application to serve.

Documentation
The doctrine no longer describes how the data layer works underneath: five
leaves whose subject was internals are gone, a dozen more are re-founded on the
contract's own words, and two frozen arbitrations about a deleted screen were
removed rather than left to mislead a future session.

Test harness
It can sign in at last: cucumber runs under node, which does not load `.env`,
so the harness never received the wallet material and every scenario silently
fell back to an empty local mode. A failed sign-in is now loud on both sides.
The suite also releases what it opens and exits on its own -- runs were still
resident hours after reporting, holding a browser and two servers.

Known red: `@data` cannot be measured. The served wallet accumulates and
nothing resets it; moving the browser profile aside does not, since the data
lives in the wallet file, not the profile.

.env.example

@@ -0,0 +1,41 @@
+# Festipod — variables d'environnement (exemple)
+#
+# Copier en `.env` et renseigner les valeurs.
+# En dev (`bun run dev`) ET en prod (`bun run start`), l'app sert depuis src/ et
+# lit ces variables au RUNTIME (via l'endpoint /festipod-config.json de src/index.ts).
+#
+# REQUIS POUR LES TESTS. La suite Cucumber tourne sous `node` (pas sous Bun), qui
+# ne charge pas `.env` tout seul : le harness le lit explicitement et LÈVE UNE
+# ERREUR NOMMÉE si le mot de passe ou le fichier manquent. Or `.env` ET `*.ngw`
+# sont tous deux gitignorés — un clone frais n'a donc ni l'un ni l'autre et ne
+# peut pas exécuter `@data`/`@e2e` tant que ces deux valeurs ne sont pas fournies.
+
+# ── Portefeuille partagé (stopgap staging) ─────────────────────────────────
+# Mot de passe du portefeuille partagé.
+# VIDE => rien n'est passé à `configure({ sharedWallet })` => le SDK refuse de
+# signer l'entrée et l'app affiche son panneau d'erreur au lieu de démarrer.
+# REQUIS en staging (onboarding d'un appareil sans wallet) ET pour les tests.
+FESTIPOD_SHARED_WALLET_PASSWORD=
+
+# Chemin vers le fichier portefeuille partagé (.ngw), absolu ou relatif à la
+# racine. Servi en téléchargement à /shared-wallet.ngw — par le build de l'app,
+# et par le serveur du harness pendant les tests.
+FESTIPOD_SHARED_WALLET_FILE=/chemin/absolu/vers/festipod-wallet.ngw
+
+# ── Seed automatique (opt-in) ──────────────────────────────────────────────
+# Non vide => l'app amorce des données de démo dans un wallet VIDE au 1er login.
+# OFF par défaut : laisser vide en usage normal.
+FESTIPOD_AUTO_SEED=
+
+# ── Serveur ────────────────────────────────────────────────────────────────
+# Port HTTP du serveur (défaut 3000).
+PORT=3000
+
+# NODE_ENV=production bascule `bun run start` (pas de HMR). En dev, laisser vide.
+NODE_ENV=
+
+# ── Outillage dev (facultatif) ─────────────────────────────────────────────
+# Override du chemin local du polyfill @ng-eventually/sdk pour `pnpm run
+# link:polyfill` (lien local réactif). Défaut = ../nextgraph/ng-eventually-js/packages/sdk.
+NG_EVENTUALLY_LOCAL=
+

.gitignore

@@ -43,3 +43,7 @@ playwright/.auth/
 storybook-static
 dist-staging/
 *.ngw
+.tasks/
+
+# Per-developer contract access map (canonical provider → local checkout) — never committed.
+.project/contracts.local.yaml

.project/concepts/app-architecture/_overview.md

@@ -1,6 +1,6 @@
 ---
 type: _overview
-summary: Architecture feature-based de l'app — modules par domaine, invariant d'imports, app shell à providers, routing path-based, écrans et registre
+summary: Feature-based architecture of the app — modules per domain, import invariant, provider-stacked app shell, path-based routing, screens and registry
 triggers:
   keywords: [module, modules, screen, écran, routing, route, navigate, useNavigate, useParams, registry, registre, app shell, shared, import]
   paths: ["src/app/**", "src/screens/**", "src/modules/*/screens/**", "src/shared/components/**", "src/shared/context/**"]
@@ -8,17 +8,19 @@ triggers:
 
 # App architecture
 
-Comment le code de l'app est **structuré** et **assemblé**. Architecture *feature-based* : le code est organisé par **domaine métier** (module), pas par couche technique.
+How the app's code is **structured** and **assembled**. *Feature-based* architecture: the code is organized by **business domain** (module), not by technical layer.
 
-**À lire en premier :** [[rule_module-imports]] — l'invariant central qui garde les modules découplés.
+**Read this first:** [[rule_module-imports]] — the central invariant that keeps modules decoupled.
 
-## Liens
+## Links
 
-- [[knowledge_module-structure]] — arborescence modules + couche `shared/`
-- [[knowledge_app-shell]] — `src/app/`, pile de providers, points d'entrée
-- [[knowledge_routing]] — routing path-based (History API), table de routes, hooks
-- [[knowledge_screens]] — inventaire des écrans, registre, lib de composants
-- [[knowledge_screen-pattern]] — anatomie canonique d'un écran (sans props, layout flex, showToast)
-- [[knowledge_styling-system]] — `src/index.css`, classes `app-*`, vars, pièges (Tailwind non-utilisé, `user-content` inerte)
-- [[cookbook_add-screen]] — procédure pour câbler un nouvel écran (registre + router + shell)
-- `tech-stack` — build, bundler Bun, commandes
+- [[knowledge_module-structure]] — module tree + `shared/` layer
+- [[knowledge_app-shell]] — `src/app/`, provider stack, entry points
+- [[knowledge_routing]] — path-based routing (History API), route table, hooks
+- [[knowledge_screens]] — screen inventory, registry, component library
+- [[knowledge_screen-pattern]] — canonical anatomy of a screen (no props, flex layout, showToast)
+- [[caveat_identity-ids-in-screens]] — `currentUserId` is the profile document's NURI and is **empty until the protected read lands**; empty reads like "no data"
+- [[caveat_boot-unverified-outside-broker]] — the unconditional `ensureIdentity()` await is verified inside the broker iframe; standalone/top-level boot is unverified
+- [[knowledge_styling-system]] — `src/index.css`, `app-*` classes, vars, pitfalls (Tailwind unused, `user-content` inert)
+- [[cookbook_add-screen]] — procedure for wiring up a new screen (registry + router + shell)
+- `tech-stack` — build, Bun bundler, commands

.project/concepts/app-architecture/caveat_boot-unverified-outside-broker.md

@@ -0,0 +1,25 @@
+---
+type: caveat
+summary: The standalone boot (app opened directly, not in the broker iframe) is covered by NO test, and it broke SILENTLY once — a blank page with no error, because nothing started a session and ensureIdentity() then settled neither way. Fixed by making the session start unconditionally; still untested, so break it and you will not hear about it.
+last_checked: 2026-08-10
+---
+
+# Pitfall: nothing tests the app booting outside the broker iframe
+
+## What happened, VERIFIED
+
+`AuthGate` awaits `ensureIdentity()` and renders **nothing** until it settles. `NextGraphProvider` used to start the NextGraph session **only inside the broker iframe** — standalone, the session was started by the user pressing "Entrer" on the app's own access screen.
+
+That screen was deleted the same day (the SDK shows the barrier now, see [[decision_2026-08-10_sdk-renders-the-barrier]]), and the iframe-only condition survived it. Standalone, the result was: no session ever started → the `getSession` thunk never returned → `ensureIdentity()` **neither resolved nor rejected** → `AuthGate` returned `null` forever. **A blank page with nothing in the console.**
+
+Note the shape of the failure, because it is the instructive part: a rejection would have been *shown* (`AuthGate` renders a named error panel). What produced silence was a promise that never settled at all — the one outcome no error path catches. Found by a human opening the app, not by any suite.
+
+The fix: the session starts unconditionally, in the iframe and standalone alike, through one `startSession()` in `NextGraphContext`. Standalone, `initNg()` redirects to the broker — that redirect **is** the sign-in flow now that nothing is left to click.
+
+## What is still true
+
+**No test exercises this path.** `@data` runs the harness inside the broker iframe; `@e2e` drives the real app inside the broker iframe too. The standalone top-level boot — the one a developer uses every day with `bun run dev`, and the one a first-time visitor hits — is covered by nothing.
+
+So: a change to `AuthGate`, to `NextGraphProvider`, or to what `configure()` receives can break the app's entry completely while every suite stays green. If you touch any of them, **open the app standalone yourself** before believing the tests.
+
+Two related pieces: [[caveat_first-time-entry-untested]] (the wallet-import journey, same blind spot seen from the user's side) and [[caveat_shared-wallet-global-before-gate-import]] (a missing wallet password now makes `ensureIdentity()` throw, which at least fails loudly).

.project/concepts/app-architecture/caveat_identity-ids-in-screens.md

@@ -0,0 +1,24 @@
+---
+type: caveat
+summary: currentUserId is now the profile document's NURI — the same value as currentUser.id — so the old two-id-spaces pitfall is gone; the live hazard is that it is EMPTY until the protected profile read lands, and nothing raises when a screen keys on it too early
+last_checked: 2026-08-10
+---
+
+# Pitfall: the current user arrives late, and empty reads like a value
+
+## What is true now — one id, not two
+
+`currentUserId` **is** `currentUser?.id`: the **NURI of the profile document** the app reads back in its own protected scope. The two are no longer distinct spaces, because the app no longer derives a principal from anything it was told — it stopped naming its own identity altogether (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]). A participation written today carries that same NURI in `fp:user`.
+
+> The earlier pitfall — a stable principal `urn:festipod:user:<key>` on one side and a profile NURI on the other, never equal in connected mode — **no longer applies to values written today**. The provider still resolves the older principal form on read (`resolveParticipantUser`, concept `data-layer` → [[knowledge_context-internals]]); a screen never sees it.
+
+## The live hazard: `''` before the read lands
+
+`currentUserId` is **empty** until the protected profile read resolves — and empty is a perfectly ordinary string. Nothing throws.
+
+- A **query** keyed on it (`getUserEvents`, `isParticipating`, `getFriends` — all defaulting to `currentUserId`) returns an **empty result** rather than an error, which renders as "you have nothing" instead of "not ready yet".
+- A **mutation** that needs it refuses rather than writing a malformed entity: `joinEvent` logs `empty user principal — refusing to write a participation with no fp:user` and returns. A screen that assumed the write happened shows a success it did not get.
+
+**The rule**: treat an empty `currentUserId` as *not ready*, never as *no data*. Gate on it before rendering an emptiness verdict or firing a mutation that stores it.
+
+The participation→profile join itself is **not** the screen's business: it is done in the provider (`resolveParticipantUser`). Full mechanics and the write/read invariant: concept `data-layer`, [[knowledge_context-internals]].

.project/concepts/app-architecture/cookbook_add-screen.md

@@ -1,20 +1,20 @@
 ---
 type: cookbook
-summary: Procédure pour ajouter un écran — créer le composant dans le module, l'enregistrer dans src/screens/index.ts, ajouter la route dans router.tsx, le monter dans App.tsx, et un alias screenNameMap si testé en BDD
+summary: Procedure for adding a screen — create the component in the module, register it in src/screens/index.ts, add the route in router.tsx, mount it in App.tsx, plus a screenNameMap alias if it is covered by BDD
 ---
 
-# Cookbook : ajouter un écran
+# Cookbook: adding a screen
 
-Un écran doit être câblé à **plusieurs endroits** — en oublier un produit des bugs silencieux (cf. le cas `ConnectScreen`, [[knowledge_screens]]).
+A screen has to be wired up in **several places** — forgetting one produces silent bugs (see the `ConnectScreen` case, [[knowledge_screens]]).
 
-1. **Créer le composant** : `src/modules/{module}/screens/MyScreen.tsx`, en suivant [[knowledge_screen-pattern]] (fonction sans props, `useFestipodData`/`useNavigate`/`useParams`, layout flex, style via [[knowledge_styling-system]]). Respecter [[rule_module-imports]] (importer seulement depuis `shared/`).
+1. **Create the component**: `src/modules/{module}/screens/MyScreen.tsx`, following [[knowledge_screen-pattern]] (function with no props, `useFestipodData`/`useNavigate`/`useParams`, flex layout, styling via [[knowledge_styling-system]]). Respect [[rule_module-imports]] (import only from `shared/`).
 
-2. **Enregistrer dans le registre** : `src/screens/index.ts` — ajouter l'import + l'entrée (`id`, `name` FR, `path`, `component`). **Étape la plus oubliée** : un écran absent du registre est invisible à Storybook et aux consommateurs du registre, même s'il fonctionne en route.
+2. **Add it to the registry**: `src/screens/index.ts` — add the import plus the entry (`id`, French `name`, `path`, `component`). **The most frequently forgotten step**: a screen missing from the registry is invisible to Storybook and to the registry's consumers, even though it works as a route.
 
-3. **Ajouter la route** : `src/app/router.tsx` — étendre le type `Route`, ajouter le cas dans `parsePath()` (et la conversion inverse si présente).
+3. **Add the route**: `src/app/router.tsx` — extend the `Route` type, add the case in `parsePath()` (and the reverse conversion if present).
 
-4. **Monter dans le shell** : `src/app/App.tsx` — ajouter le cas dans le switch qui mappe `route.page` → composant.
+4. **Mount it in the shell**: `src/app/App.tsx` — add the case in the switch that maps `route.page` → component.
 
-5. **(Si testé en BDD)** : ajouter un alias dans `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`) si le nom français du `.feature` ne se résout pas trivialement vers l'`id`. Voir concept `bdd-testing`.
+5. **(If covered by BDD)**: add an alias in `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`) if the French name used in the `.feature` does not resolve trivially to the `id`. See concept `bdd-testing`.
 
-> Vérifier la cohérence : l'`id` doit être identique entre le registre, le router et `screenNameMap`. Un écart silencieux = écran injoignable ou non rendu.
+> Check consistency: the `id` must be identical across the registry, the router and `screenNameMap`. A silent mismatch = an unreachable or unrendered screen.

.project/concepts/app-architecture/knowledge_app-shell.md

@@ -1,33 +1,44 @@
 ---
 type: knowledge
-summary: src/app/ est le shell réel de l'app — App.tsx empile les providers (Theme > NextGraph > FestipodData > Router) et bascule l'écran selon la route
+summary: src/app/ is the app's real shell — App.tsx stacks the providers (Theme > NextGraph > FestipodData > Router), AuthGate makes the one unconditional ensureIdentity() await and renders nothing of its own until it settles, and the shell switches screens according to the route
+last_checked: 2026-08-10
 ---
 
 # App shell
 
-`src/app/` est le **shell de l'app réelle** (mobile web app), pas un outil de prototypage.
+`src/app/` is the **shell of the real app** (mobile web app), not a prototyping tool.
 
-> Note de migration : d'anciennes notes décrivaient `src/app/` comme un « prototyping tool » en routing par hash (`#/`, `#/demo/...`). C'est **périmé** depuis la restructuration en vraie app. La vérité courante : routing path-based via History API (voir [[knowledge_routing]]).
+> Migration note: older notes described `src/app/` as a "prototyping tool" using hash routing (`#/`, `#/demo/...`). That is **obsolete** since the restructuring into a real app. The current truth: path-based routing via the History API (see [[knowledge_routing]]).
 
-## Pile de providers
+## Provider stack
 
-`App.tsx` empile les providers puis bascule l'écran selon la route courante :
+`App.tsx` stacks the providers, then switches screens according to the current route:
 
 ```
 ThemeProvider
-  └ NextGraphProvider        (cycle de connexion NextGraph — concept data-layer)
-      └ FestipodDataProvider (données, mode connected/demo — concept data-layer)
-          └ RouterProvider   (route courante + navigate)
+  └ NextGraphProvider            (NextGraph connection cycle — concept data-layer)
+      └ FestipodDataProvider     (data, connected/demo mode — concept data-layer)
+          └ RouterProvider       (current route + navigate)
+              └ div.app-container
+                  ├ AuthGate       (the one ensureIdentity() await; renders nothing of its own)
+                  │   └ AppContent (switch route.page → screen)
+                  └ ToastContainer
 ```
 
-Le composant racine lit `useRouter()` pour résoudre `route.page` → écran à rendre.
+`AppContent` reads `useRouter()` to resolve `route.page` → the screen to render. **There is no identity provider**: the app names no identity of its own (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]), so there is nothing to hold above the data provider.
 
-## Points d'entrée
+### Ordering invariants (what breaks if you move a layer)
 
-| Fichier | Rôle |
+- **`AuthGate` sits INSIDE the router**: it reads `useRouter()`/`useNavigate()` to leave the logged-out landing route once identified. Moving it out of `RouterProvider` breaks it.
+- **`AuthGate` wraps EVERY routed screen**, and it holds them behind **one** condition: the single `await ensureIdentity()` (`@ng-eventually/polyfill`) it fires unconditionally on mount has resolved. Until it does, `AuthGate` renders **nothing at all** — there is no Festipod screen standing in for `AppContent` while it waits (concept `app-security`, [[decision_2026-08-10_sdk-renders-the-barrier]]). `AuthGate` does not read `useNextGraph()` — no `status`, no `connect()`, no error branch of its own. The identity await is not decoration: `ensureIdentity()` also does the connection work (restoring what others shared with us), so a screen mounted before it resolves would read as an identity that is not yet settled. Consequence: **no screen may assume it is reachable without a settled identity**, and there is no longer a way to disable the barrier — see [[caveat_boot-unverified-outside-broker]] for the one path this leaves unverified.
+- **`ToastContainer` sits OUTSIDE `AuthGate`** (but inside `.app-container`): it is mounted regardless of whether identity has settled.
+
+## Entry points
+
+| File | Role |
 |---|---|
-| `src/index.ts` | `Bun.serve()` — serveur HTTP, sert `index.html` + rapport cucumber |
-| `src/index.html` | Entrée HTML, charge `src/app/frontend.tsx` |
-| `src/app/frontend.tsx` | Racine React, rend `<App />` |
+| `src/index.ts` | `Bun.serve()` — HTTP server, serves `index.html` + the cucumber report |
+| `src/index.html` | HTML entry point, loads `src/app/frontend.tsx` |
+| `src/app/frontend.tsx` | React root, renders `<App />` |
 
-Le build et le bundler (Bun + Tailwind, alias `@/* → ./src/*`) sont documentés dans le concept `tech-stack`.
+The build and the bundler (Bun + Tailwind, alias `@/* → ./src/*`) are documented in the `tech-stack` concept.

.project/concepts/app-architecture/knowledge_module-structure.md

@@ -1,41 +1,41 @@
 ---
 type: knowledge
-summary: Arborescence feature-based — modules métier (event, user, home, auth, workshop, meeting, notification) et couche shared/ importable par tous
+summary: Feature-based tree — business modules (event, user, home, auth, workshop, meeting, notification) and a shared/ layer importable by all of them
 ---
 
-# Structure des modules
+# Module structure
 
-Le code est organisé par **domaine métier**, pas par couche technique.
+The code is organized by **business domain**, not by technical layer.
 
 ```
 src/modules/
-  event/          # Événements : CRUD, discovery, participants, points de rencontre
-  user/           # Profils, connexions (« amis »), partage
+  event/          # Events: CRUD, discovery, participants, meeting points
+  user/           # Profiles, connections ("friends"), sharing
   home/           # Dashboard, settings
   auth/           # Login, welcome/onboarding
-  workshop/       # Specs atelier (features seulement, pas d'écrans)
-  meeting/        # Specs point de rencontre (features seulement)
-  notification/   # Specs notification (features seulement)
+  workshop/       # Workshop specs (features only, no screens)
+  meeting/        # Meeting point specs (features only)
+  notification/   # Notification specs (features only)
 ```
 
-Chaque module peut contenir :
-- `screens/` — composants d'écran React
-- `features/` — fichiers Gherkin `.feature` (specs BDD, voir concept `bdd-testing`)
-- `steps/{ui,data,e2e}/` — step definitions Cucumber par couche
+Each module may contain:
+- `screens/` — React screen components
+- `features/` — Gherkin `.feature` files (BDD specs, see concept `bdd-testing`)
+- `steps/{ui,data,e2e}/` — Cucumber step definitions, one folder per layer
 
-## Couche `shared/`
+## The `shared/` layer
 
-`src/shared/` contient tout le réutilisable inter-modules :
+`src/shared/` holds everything reusable across modules:
 
-| Répertoire | Contenu |
+| Directory | Contents |
 |---|---|
-| `components/` | Lib de composants UI (voir [[knowledge_screens]]) |
-| `context/` | `ThemeContext`, `NextGraphContext`, `FestipodDataContext` (voir concept `data-layer`) |
-| `data/` | User stories, `features.ts` (auto-généré), `seedData.ts`, `types.ts` |
-| `hooks/` | `useShapeWithDefaults` (NextGraph) |
-| `shapes/` | SHEX + bindings ORM (voir concept `data-layer`) |
-| `utils/` | `ngSession.ts`, `ngBootstrap.ts`, `ngGraph.ts` |
-| `steps/`, `support/` | Step definitions et hooks Cucumber partagés (concept `bdd-testing`) |
+| `components/` | UI component library (see [[knowledge_screens]]) |
+| `context/` | `ThemeContext`, `NextGraphContext`, `FestipodDataContext` (concept `data-layer`); their **stacking order** is constrained, see [[knowledge_app-shell]]. There is no identity context — the app names no identity of its own (concept `app-security`) |
+| `data/` | User stories, `features.ts` (auto-generated), `seedData.ts`, `types.ts` |
+| `hooks/` | empty — the reactive read binding lives in `data/useShapeQuery.ts` (concept `data-layer`) |
+| `shapes/` | SHEX + ORM bindings (see concept `data-layer`) |
+| `utils/` | `ngSession.ts`, `ngBootstrap.ts`, `ngGraph.ts`, `storeRegistry.ts`, `connections.ts`, `identifier.ts` |
+| `steps/`, `support/` | Shared Cucumber step definitions and hooks (concept `bdd-testing`) |
 | `lib/` | Helpers (`cn`, etc.) |
 
-La règle de dépendance entre modules et `shared/` est dans [[rule_module-imports]].
+The dependency rule between modules and `shared/` lives in [[rule_module-imports]].

.project/concepts/app-architecture/knowledge_routing.md

@@ -1,18 +1,17 @@
 ---
 type: knowledge
-summary: Routing path-based via History API (router maison dans src/app/router.tsx) — table de routes, hooks useNavigate/useParams, pas de prop drilling
+summary: Path-based routing via the History API (hand-rolled router in src/app/router.tsx) — route table, useNavigate/useParams hooks, no prop drilling
 ---
 
 # Routing
 
-Routing **path-based** via l'History API — router maison dans `src/app/router.tsx` (`window.history.pushState` + `popstate`, `parsePath(pathname)`). Pas de routing par hash.
+**Path-based** routing via the History API — hand-rolled router in `src/app/router.tsx` (`window.history.pushState` + `popstate`, `parsePath(pathname)`). No hash routing.
 
-## Table de routes
+## Route table
 
-| Path | Écran |
+| Path | Screen |
 |---|---|
 | `/` | WelcomeScreen |
-| `/login` | LoginScreen |
 | `/home` | HomeScreen |
 | `/events` | EventsScreen |
 | `/events/new` | CreateEventScreen |
@@ -25,12 +24,12 @@ Routing **path-based** via l'History API — router maison dans `src/app/router.
 | `/profile/edit` | UpdateProfileScreen |
 | `/profile/friends` | FriendsListScreen |
 | `/profile/share` | ShareProfileScreen |
-| `/profile/connect` | (connexion) |
+| `/profile/connect` | ConnectScreen (`src/modules/user/screens/ConnectScreen.tsx`) — routed and mounted in `App.tsx`, but **absent from the screen registry**, see [[knowledge_screens]] |
 | `/users/:id` | UserProfileScreen |
 | `/settings` | SettingsScreen |
 
-> Cette table reflète `parsePath()` dans `router.tsx` — y revenir si elle évolue, c'est la source de vérité.
+> This table mirrors `parsePath()` in `router.tsx` — go back to it whenever it changes, that is the source of truth. There is **no** authentication route: the access barrier is not routed, it is rendered *above* the route switch by `AuthGate` (see [[knowledge_app-shell]]).
 
 ## Hooks
 
-Les écrans utilisent `useNavigate()` et `useParams()` du router — **pas de prop drilling**. Le shell intercepte la navigation pour basculer l'écran affiché (voir [[knowledge_app-shell]]).
+Screens use the router's `useNavigate()` and `useParams()` — **no prop drilling**. The shell intercepts navigation to switch the displayed screen (see [[knowledge_app-shell]]).

.project/concepts/app-architecture/knowledge_screen-pattern.md

@@ -1,32 +1,33 @@
 ---
 type: knowledge
-summary: Anatomie canonique d'un écran — fonction nommée sans props, lit tout via useFestipodData/useNavigate/useParams, layout flex colonne (Header / contenu scrollable / BottomNav pour les écrans hub), feedback via showToast, libellés français en dur
+summary: Canonical anatomy of a screen — named function with no props, reads everything through useFestipodData/useNavigate/useParams, flex column layout (Header / scrollable content / BottomNav), feedback via showToast, hard-coded French labels; zero-prop rule has no exception left
+last_checked: 2026-08-10
 ---
 
-# Pattern canonique d'un écran
+# Canonical screen pattern
 
-Tous les écrans suivent la même forme. La connaître évite de réinventer ou de diverger.
+Every screen follows the same shape. Knowing it avoids reinventing or diverging.
 
-## Forme
+## Shape
 
 ```tsx
-export function MyScreen() {              // fonction nommée, JAMAIS de props
+export function MyScreen() {              // named function, NEVER any props
   const navigate = useNavigate();
   const { eventId, userId } = useParams();
   const { getEvent, currentUser, … } = useFestipodData();
-  const [local, setLocal] = useState(…);  // état local d'écran (étapes, sélections)
+  const [local, setLocal] = useState(…);  // screen-local state (steps, selections)
 
   const handleAction = () => {
-    // …muter via useFestipodData
+    // …mutate through useFestipodData
     showToast('Message', 'success');       // feedback
     navigate('/path');
   };
 
   return (
     <div style={{ display:'flex', flexDirection:'column', height:'100%' }}>
-      <Header title="…" /* left/right optionnels */ />
-      <div style={{ flex:1, overflow:'auto' }}>{/* contenu scrollable */}</div>
-      <BottomNav active="…" />              {/* seulement sur les écrans hub */}
+      <Header title="…" /* left/right optional */ />
+      <div style={{ flex:1, overflow:'auto' }}>{/* scrollable content */}</div>
+      <BottomNav active="…" />              {/* only on hub screens */}
     </div>
   );
 }
@@ -34,10 +35,11 @@ export function MyScreen() {              // fonction nommée, JAMAIS de props
 
 ## Invariants
 
-- **Zéro prop** : l'écran ne reçoit rien ; tout vient du contexte/hooks (`useFestipodData`, `useNavigate`, `useParams`). Exceptions légitimes : `LoginScreen`/`WelcomeScreen` n'utilisent pas `useFestipodData` (auth/intro).
-- **Layout** : flex colonne pleine hauteur ; `Header` en haut, contenu en `flex:1; overflow:auto`, `BottomNav` en bas **uniquement pour les écrans hub** (Home, Events, Profile, Friends). Les écrans de flux (création, édition, détail) n'ont pas de `BottomNav`.
-- **Feedback** : `showToast(message, 'success'|'info'|'error')` (mécanisme `ToastContainer` exporté par `sketchy/`).
-- **Libellés** : **français, en dur** — aucun i18n, aucune clé de traduction dans le projet.
-- Style : voir [[knowledge_styling-system]]. Navigation/registre : [[knowledge_routing]], [[knowledge_screens]].
+- **Zero props, no exception left**: every registered screen receives nothing; everything comes from context/hooks (`useFestipodData`, `useNavigate`, `useParams`). `WelcomeScreen` does not use `useFestipodData` (intro) — but still takes no props. (`LoginScreen`/`ConnexionScreen`/`AccessGateScreen` no longer exist — Festipod renders no access screen of its own; see [[knowledge_screens]] and [[knowledge_app-shell]].)
+- **Identity: the current user may not be there yet.** `currentUserId` is the profile document the app reads back in its own protected scope, so it is **empty until that read lands** — see [[caveat_identity-ids-in-screens]] before keying anything on it.
+- **Layout**: full-height flex column; `Header` at the top, content at `flex:1; overflow:auto`, `BottomNav` at the bottom **only for hub screens** (Home, Events, Profile, Friends). Flow screens (creation, editing, detail) have no `BottomNav`.
+- **Feedback**: `showToast(message, 'success'|'info'|'error')` (`ToastContainer` mechanism exported by `sketchy/`).
+- **Labels**: **French, hard-coded** — no i18n, no translation keys anywhere in the project.
+- Styling: see [[knowledge_styling-system]]. Navigation/registry: [[knowledge_routing]], [[knowledge_screens]].
 
-Pour **créer** un écran (les 3+ endroits à câbler), voir [[cookbook_add-screen]].
+To **create** a screen (the 3+ places to wire up), see [[cookbook_add-screen]].

.project/concepts/app-architecture/knowledge_screens.md

@@ -1,40 +1,41 @@
 ---
 type: knowledge
-summary: Inventaire des écrans par module, registre central src/screens/index.ts, et lib de composants sous shared/components/sketchy/ — dont le NOM est conservé mais qui rend un thème moderne (pas hand-drawn)
+summary: Inventory of screens per module, central registry src/screens/index.ts, and the component library under shared/components/sketchy/ — whose NAME is kept but which renders a modern theme (not hand-drawn); the auth module now holds only WelcomeScreen, no access screen of its own
+last_checked: 2026-08-10
 ---
 
-# Écrans et composants
+# Screens and components
 
-## Lib de composants : `sketchy/` = thème moderne
+## Component library: `sketchy/` = modern theme
 
-⚠️ **Piège de nommage.** La lib de composants vit sous `src/shared/components/sketchy/` (chemin conservé, importé par ~17 écrans), **mais elle ne rend plus un style « hand-drawn »** : elle a été portée vers un thème **moderne** (DM Sans / orange, classes `app-*`). Le *chemin d'import* est bon, la *description visuelle « sketchy »* est périmée. Ne pas réintroduire d'esthétique dessinée en se fiant au nom du dossier.
+⚠️ **Naming pitfall.** The component library lives under `src/shared/components/sketchy/` (path kept, imported by ~17 screens), **but it no longer renders a "hand-drawn" style**: it was ported to a **modern** theme (DM Sans / orange, `app-*` classes). The *import path* is right, the *"sketchy" visual description* is obsolete. Do not reintroduce hand-drawn aesthetics on the strength of the folder name.
 
-Composants typiques : `Header`, `BottomNav`, `Button`, `Card`, `Input`, `Badge`, `Avatar`/`AvatarStack`, `Text`/`Title`, `Toggle`, `ListItem`, `Divider`, `Placeholder`, `BrokerBanner`, `NgStatus`.
+Typical components: `Header`, `BottomNav`, `Button`, `Card`, `Input`, `Badge`, `Avatar`/`AvatarStack`, `Text`/`Title`, `Toggle`, `ListItem`, `Divider`, `Placeholder`, `BrokerBanner`, `NgStatus`.
 
-## Registre d'écrans
+## Screen registry
 
-`src/screens/index.ts` importe tous les écrans de tous les modules et expose :
+`src/screens/index.ts` imports every screen from every module and exposes:
 
 ```typescript
-export const screenGroups   // groupés par domaine (home, events, user, general)
-export const screens        // liste à plat
+export const screenGroups   // grouped by domain (home, events, user, general)
+export const screens        // flat list
 export function getScreen(id): Screen | undefined
 ```
 
-Utilisé notamment par Storybook (voir concept `tech-stack`) pour parcourir les écrans.
+Used notably by Storybook (see concept `tech-stack`) to browse the screens.
 
-## Inventaire
+## Inventory
 
-Écrans par module (IDs = clés du registre) :
+Screens per module (IDs = registry keys):
 
-- **home/** : `welcome`, `home`, `settings`
-- **event/** : `events`, `event-detail`, `create-event`, `update-event`, `invite`, `participants-list`, `meeting-points`
-- **user/** : `profile`, `update-profile`, `user-profile`, `friends-list`, `share-profile`
-- **auth/** : `login`
+- **home/**: `welcome`, `home`, `settings`
+- **event/**: `events`, `event-detail`, `create-event`, `update-event`, `invite`, `participants-list`, `meeting-points`
+- **user/**: `profile`, `update-profile`, `user-profile`, `friends-list`, `share-profile`
+- **auth/**: `WelcomeScreen` (intro, routed at `/`) is the only screen left in this module. Festipod renders **no access screen of its own** any more: `AccessGateScreen`, its route and its registration are deleted, along with the `LoginScreen`/`ConnexionScreen` that preceded it. Signing in is `src/app/AuthGate.tsx`'s single `await ensureIdentity()`; whatever a user sees or does while that resolves is drawn entirely by the SDK, outside the registry, outside routing, and outside this app's component tree (concept `app-security`, [[decision_2026-08-10_sdk-renders-the-barrier]]).
 
-> Le mapping path → écran est dans [[knowledge_routing]]. La plupart des écrans consomment `useFestipodData()` (concept `data-layer`) ; exceptions : `LoginScreen`/`WelcomeScreen`.
+> The path → screen mapping lives in [[knowledge_routing]]. Most screens consume `useFestipodData()` (concept `data-layer`); the exception is `WelcomeScreen`.
 
-## Piège : registre incomplet
+## Pitfall: incomplete registry
 
-Le registre doit lister **tous** les écrans. Cas observé : `ConnectScreen` (`src/modules/user/screens/`, routé `/profile/connect`, monté dans `App.tsx`) est **absent de `src/screens/index.ts`** → invisible à Storybook et aux consommateurs du registre, bien qu'il fonctionne en route. Toujours vérifier que l'écran est enregistré (cf. [[cookbook_add-screen]]).
+The registry must list **every** screen. Observed case, **still true (verified 2026-07-28)**: `ConnectScreen` (`src/modules/user/screens/ConnectScreen.tsx`) exists, is routed at `/profile/connect` (`router.tsx`) and is mounted in `App.tsx` (`case 'connect'`), yet it is **missing from `src/screens/index.ts`** → invisible to Storybook and to the registry's consumers, even though it works as a route. Always check that the screen is registered (see [[cookbook_add-screen]]).
 

.project/concepts/app-architecture/knowledge_styling-system.md

@@ -1,32 +1,32 @@
 ---
 type: knowledge
-summary: src/index.css est la source de vérité du style — variables --app-* (couleurs, rayons, police DM Sans) et classes app-* rendues par les composants ; les écrans combinent ces classes avec des styles inline ; Tailwind est dans le build mais les écrans n'utilisent pas d'utilitaires Tailwind ; la classe user-content est inerte
+summary: src/index.css is the styling source of truth — --app-* variables (colors, radii, DM Sans font) and app-* classes rendered by the components; screens combine those classes with inline styles; Tailwind is in the build but screens use no Tailwind utilities; the user-content class is inert
 last_checked: 2026-06-15
 ---
 
-# Système de style
+# Styling system
 
-**Source de vérité : `src/index.css`** (thème « Modern clean — DM Sans »). C'est là que vivent les variables CSS et les classes `app-*`. Pas de fichiers CSS par module.
+**Source of truth: `src/index.css`** ("Modern clean — DM Sans" theme). That is where the CSS variables and the `app-*` classes live. No per-module CSS files.
 
 ## Variables (`:root`)
 
-- Couleurs : `--app-black #1a1a1a`, `--app-gray #888`, `--app-bg/--app-white #fff`, accent orange `--app-accent #E8590C` (+ `-light #FFF7ED`, `-border`, `-dark #C05621`), vert `--app-green #22543D` (+ `-light`, `-border`, `-text`).
-- Rayons : `--app-radius 16px`, `--app-radius-sm 12px`, `--app-radius-xs 8px`.
-- Police : `--font-app: 'DM Sans', …`.
+- Colors: `--app-black #1a1a1a`, `--app-gray #888`, `--app-bg/--app-white #fff`, orange accent `--app-accent #E8590C` (+ `-light #FFF7ED`, `-border`, `-dark #C05621`), green `--app-green #22543D` (+ `-light`, `-border`, `-text`).
+- Radii: `--app-radius 16px`, `--app-radius-sm 12px`, `--app-radius-xs 8px`.
+- Font: `--font-app: 'DM Sans', …`.
 
-## Classes `app-*`
+## `app-*` classes
 
-Définies dans `index.css`, rendues par les composants de `shared/components/sketchy/` : `app-btn` (+ `-primary`/`-green`), `app-input`, `app-card`, `app-title`/`app-subtitle`/`app-text`, `app-badge`, `app-toggle`, `app-checkbox`, `app-header`, `app-navbar`, `app-list-item`, `app-avatar`, `app-placeholder`, `app-divider`, `app-tab`.
+Defined in `index.css`, rendered by the components in `shared/components/sketchy/`: `app-btn` (+ `-primary`/`-green`), `app-input`, `app-card`, `app-title`/`app-subtitle`/`app-text`, `app-badge`, `app-toggle`, `app-checkbox`, `app-header`, `app-navbar`, `app-list-item`, `app-avatar`, `app-placeholder`, `app-divider`, `app-tab`.
 
-## Conventions d'écriture d'un écran
+## Conventions for writing a screen
 
-- Utiliser les **composants `sketchy/`** (qui portent les classes `app-*`) pour boutons/inputs/cartes/typo.
-- Pour le **layout** (flex, gaps, paddings, couleurs ponctuelles), les écrans utilisent des **styles inline** (`style={{…}}`) — c'est le pattern normal, pas une déviation.
-- Icônes : **emojis**/symboles Unicode (📅 📍 📝 🎪…), pas d'imports d'icônes en général.
-- Largeur : `.app-container` borne à **`max-width: 768px`, `height: 100dvh`** (mobile-first/tablette portrait). Aucune media query — pas de responsive desktop.
+- Use the **`sketchy/` components** (which carry the `app-*` classes) for buttons/inputs/cards/typography.
+- For **layout** (flex, gaps, paddings, one-off colors), screens use **inline styles** (`style={{…}}`) — that is the normal pattern, not a deviation.
+- Icons: **emojis**/Unicode symbols (📅 📍 📝 🎪…), generally no icon imports.
+- Width: `.app-container` caps at **`max-width: 768px`, `height: 100dvh`** (mobile-first/portrait tablet). No media queries — no desktop responsiveness.
 
-## Pièges
+## Pitfalls
 
-- **Tailwind est dans le build** (plugin `bun-plugin-tailwind`, dépendance `tailwindcss`), mais **les écrans n'utilisent pas de classes utilitaires Tailwind** — le style réel passe par `app-*` + inline. Ne pas « tailwindiser » un écran en pensant suivre la convention.
-- **`user-content` est une classe INERTE** : utilisée sur de nombreux titres/noms dans les écrans, **sans aucune définition CSS**. C'est un marqueur legacy sans effet — ne pas s'appuyer dessus pour styler, ne pas croire qu'elle fait quelque chose.
-- Pas de **dark mode** : le toggle « darkMode » de `SettingsScreen` n'est branché à rien.
+- **Tailwind is in the build** (`bun-plugin-tailwind` plugin, `tailwindcss` dependency), but **screens use no Tailwind utility classes** — the actual styling goes through `app-*` + inline. Do not "tailwindify" a screen thinking you are following the convention.
+- **`user-content` is an INERT class**: used on many titles/names across the screens, **with no CSS definition whatsoever**. It is a legacy marker with no effect — do not rely on it for styling, do not assume it does anything.
+- No **dark mode**: the "darkMode" toggle in `SettingsScreen` is not wired to anything.

.project/concepts/app-architecture/rule_module-imports.md

@@ -1,24 +1,24 @@
 ---
 type: rule
-summary: Un module n'importe QUE depuis shared/ (et le registre d'écrans) — jamais depuis un autre module ; c'est l'invariant qui garde l'architecture feature-based
+summary: A module imports ONLY from shared/ (and the screen registry) — never from another module; this is the invariant that keeps the feature-based architecture real
 ---
 
-# Règle : un module n'importe jamais d'un autre module
+# Rule: a module never imports from another module
 
-**Les modules importent uniquement depuis `shared/` — jamais entre eux.**
+**Modules import only from `shared/` — never from each other.**
 
 ```
 src/modules/event/screens/EventDetailScreen.tsx
-  ✅ import depuis 'shared/components/...'
-  ✅ import depuis 'shared/context/FestipodDataContext'
-  ✅ import depuis 'src/screens' (types du registre)
-  ❌ import depuis 'modules/user/screens/...'
+  ✅ import from 'shared/components/...'
+  ✅ import from 'shared/context/FestipodDataContext'
+  ✅ import from 'src/screens' (registry types)
+  ❌ import from 'modules/user/screens/...'
 ```
 
-## Pourquoi
+## Why
 
-C'est ce qui rend l'architecture *feature-based* réelle et pas cosmétique : chaque domaine reste un bloc autonome, déplaçable/supprimable sans casser les autres. Tout besoin partagé **remonte dans `shared/`** ; toute dépendance inter-domaines passe par un contrat de `shared/` (souvent `FestipodDataContext` ou le registre d'écrans), jamais par un import direct.
+This is what makes the *feature-based* architecture real rather than cosmetic: each domain stays a self-contained block, movable or removable without breaking the others. Any shared need **moves up into `shared/`**; any cross-domain dependency goes through a `shared/` contract (usually `FestipodDataContext` or the screen registry), never through a direct import.
 
-## Vérifier
+## How to check
 
-`grep -rE "from '\.\./\.\./(event|user|home|auth|workshop|meeting|notification)/" src/modules/` ne doit rien remonter d'un module vers un *autre* module. Un import qui croise deux noms de modules différents est une violation.
+`grep -rE "from '\.\./\.\./(event|user|home|auth|workshop|meeting|notification)/" src/modules/` must not surface anything pointing from one module to *another* module. An import that crosses two different module names is a violation.

.project/concepts/app-security/_overview.md

@@ -1,23 +1,29 @@
 ---
 type: _overview
-summary: Sécurité & confidentialité de Festipod — posture ACTUELLE (mono-store, confiance broker, aucun contrôle d'accès côté app) et modèle d'autorisations CIBLE (incubation) ; authentification par wallet NextGraph
+summary: Festipod's security & privacy — isolation between scopes is enforced by the data SDK, the app trusts it and carries no authorization logic in the screens; wallet-based authentication; target authorization matrix still incubating
 triggers:
-  keywords: [sécurité, security, confidentialité, privacy, accès, "access control", contrôle d'accès, trust, confiance, authz, autorisation, permission, wallet, auth, authentification, anonyme, identité, login]
+  keywords: [sécurité, security, confidentialité, privacy, accès, "access control", contrôle d'accès, trust, confiance, authz, autorisation, permission, wallet, auth, authentification, anonyme, anonymat, pseudonyme, traçage, corrélation, identité, login, scope, isolation]
   paths: ["src/modules/auth/**", "src/shared/context/NextGraphContext.tsx"]
 ---
 
 # App security
 
-Le modèle de **sécurité, confidentialité et autorisations** de Festipod. Le pilier se lit en deux temps :
+Festipod's **security, privacy and authorization** model.
 
-- **Actuel** — ce que le code applique aujourd'hui : voir [[knowledge_trust-model]]. Résumé brutal : **aucun contrôle d'accès côté app**, l'app affiche le `private_store` de l'utilisateur connecté et fait confiance au broker. Mono-user de fait.
-- **Cible** — le modèle d'autorisations dérivé (qui peut faire quoi, données personnelles = réseau, anonymat via inbox) : [[brief_2026-05-18_authorization-matrix]]. **Incubation, non implémenté.** Il graduera en `rule_`/`behavior_` quand le multi-user atterrira (chantiers data dans le concept `nextgraph-platform`).
+- **Enforced model** — **isolation between scopes** (public / protected / private) is **enforced by the data SDK** (`@ng-eventually/polyfill`), which exposes to each user only what they are entitled to. The app **trusts** the SDK: no screen carries authorization logic. See [[knowledge_trust-model]].
+- **Target authorization matrix** — the detail of *who may do what* per actor × verb (personal data = network, anonymity through the notification inbox): [[brief_2026-05-18_authorization-matrix]]. **Incubating.** It will graduate into `rule_`/`behavior_` as the product settles.
 
-L'écart entre les deux est volontaire : tant que l'app est mono-store (cf. concept `data-layer`), il n'y a rien à autoriser côté app.
+## Pitfalls
 
-## Liens
+- [[caveat_shared-wallet-global-before-gate-import]] — a wallet-password global set **after** `sharedWallet.ts` has been imported makes `ensureIdentity()` throw and the app render nothing, silently
 
-- [[knowledge_trust-model]] — posture de sécurité actuelle (mono-store, confiance broker, pas d'enforcement app)
-- [[knowledge_authentication]] — auth par wallet NextGraph, tous authentifiés, pas d'accès anonyme
-- [[brief_2026-05-18_authorization-matrix]] — modèle d'autorisations cible (incubation)
-- `nextgraph-platform` — les primitives (stores, capabilities, inbox) et les chantiers data qui porteront la cible
+> **Before designing anything "anonymous"**, read the closing section of [[knowledge_trust-model]]: the contract guarantees isolation, never anonymity, so a Festipod action that circulates a reference to someone's document is pseudonymous at best.
+
+## Links
+
+- [[knowledge_trust-model]] — the app delegates isolation to the SDK, no access control in the screens
+- [[knowledge_authentication]] — wallet-based auth, everyone authenticated, no anonymous access, no screen of Festipod's own
+- [[decision_2026-08-10_the-barrier-names-no-identity]] — the app names no identity: the barrier takes nothing, signing in is one `ensureIdentity()`
+- [[decision_2026-08-10_sdk-renders-the-barrier]] — Festipod renders no access screen of its own; the SDK draws whatever a first-time device needs to see
+- [[brief_2026-05-18_authorization-matrix]] — target authorization matrix (incubating)
+- Concept `functional-domain` → [[knowledge_data-scopes-and-discovery]] — which scope for which entity (product fact)

.project/concepts/app-security/brief_2026-05-18_authorization-matrix.md

@@ -1,143 +1,126 @@
 ---
 type: brief
-summary: Matrice d'autorisations par type de donnée (PdR, inscription, événement, profil, connexion) ; dérive que 3 stores natifs par utilisateur + Dialog stores suffisent, aucun Group store sur le périmètre validé ; questions ouvertes sur modèle d'écriture événement et identité de l'hôte
+summary: Target authorization matrix per data type (meeting point, registration, event, profile, connection) expressed as public/protected/private + dialog scopes; settled framing decisions (everyone authenticated, public meeting points, personal data = network, notification through an identified-or-anonymous inbox); open questions on the event write model and on host identity
 last_updated: 2026-05-18
 ---
 
-# Matrice d'autorisations et inventaire des requêtes
+# Authorization matrix and query inventory
 
-**Status:** Incubating — analyse en cours
-**Last updated:** 2026-05-18
+**Status:** Incubating — target model, not frozen into rules.
 
 ## Context
 
-Préalable au refactor multi-store ([[brief_2026-05-17_multi-store-refactor]]) et à toute évolution multi-user. La structure de stores NextGraph cible doit être *dérivée* de : (1) une matrice d'autorisations ; (2) un inventaire des requêtes par écran ; (3) les partitions naturelles qui en découlent (données partageant autorisations *et* schéma d'accès).
+The **target** model of who-may-do-what. Festipod's privacy derives from: (1) an authorization matrix per actor × verb; (2) the inventory of queries per screen; (3) the **scopes** that follow from them — data sharing both an authorization *and* an access pattern. The concrete entity → scope placement is a product fact: concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]. Isolation is **enforced by the data SDK** ([[knowledge_trust-model]]).
 
-C'est aussi le **modèle de confidentialité/sécurité** de Festipod (pilier sécurité), non encore implémenté.
+## Framing
 
-## Cadre
+### Actors (all authenticated)
 
-### Acteurs (tous authentifiés)
+`Alice` (viewpoint, owner of the data in focus) · `Bob` (second protagonist, bilateral relationships) · `D` (event declarer) · `H` (host of a meeting point) · `I` (registrant) · `C` (connection) · `U` (plain user with no relationship).
 
-`Alice` (point de vue, propriétaire de la donnée en focus) · `Bob` (second protagoniste, relations bilatérales) · `D` (déclarant d'événement) · `H` (hôte d'un PdR) · `I` (inscrit) · `C` (connexion) · `U` (utilisateur lambda sans relation).
+### Verbs
 
-### Verbes
+`create` · `read` (one-shot) · `subscribe` (reactive read) · `update` · `delete`. Conventions: `✓` allowed · `✗` forbidden · `cond` conditional · `—` not applicable.
 
-`créer` · `lire` (one-shot) · `s'abonner` (lecture réactive) · `modifier` · `supprimer`. Conventions : `✓` autorisé · `✗` interdit · `cond` sous condition · `—` sans objet.
+## Framing decisions (settled)
 
-## Décisions cadre (acquises)
+- **Everyone is authenticated.** No anonymous access.
+- **Meeting points are universally public.** Any user may read and subscribe.
+- **Creating a meeting point is open to all.** No prerequisite.
+- **Host = holder of the write rights** on a meeting point (1 host, the creator; being the host is public).
+- **Personal information = reserved to the network.** Visible only to the holder and their connections: participations, the profile in full, the connection list, and any declarative state whose disclosure would be a leak. "Public" status (meeting point, event) and "personal" status (profile, participations, connections) coexist within the same user.
+- **Bilateral connection.** It exists once both sides have accepted. Two objects: `DemandeDeConnexion` (one-sided, transient) and `Connexion` (bilateral, persistent).
+- **Registration notification through the meeting point's inbox.** The act of registering is composite: (a) writing an `Inscription` object into the registrant's *protected* scope, (b) dropping a link into the **inbox** of the meeting point document. The sender is **identified if they are one of the host's connections, anonymous otherwise** — a property of the data model.
+- **Joining a community / following: out of current scope.**
 
-- **Tous authentifiés.** Pas d'accès anonyme.
-- **Points de rencontre publics universels.** Tout utilisateur peut lire et s'abonner.
-- **Création de PdR ouverte à tous.** Pas de prérequis.
-- **Hôte = détenteur des droits d'écriture** sur un PdR (1 hôte, le créateur ; le fait d'être hôte est public).
-- **Informations personnelles = réservées au réseau.** Visibles seulement au titulaire et à ses connexions : participations, intégralité du profil, liste de connexions, et tout état déclaratif dont la divulgation serait une fuite. Statut « public » (PdR, événement) et « personnel » (profil, participations, connexions) coexistent dans le même utilisateur.
-- **Connexion bilatérale.** Existe après acceptation des deux côtés. Deux objets : `DemandeDeConnexion` (unilatérale, transitoire) et `Connexion` (bilatérale, persistante).
-- **Notification d'inscription via l'inbox NextGraph du PdR.** L'acte « s'inscrire » est composite : (a) écriture d'un objet `Inscription` dans le `protected_store` de l'inscrit, (b) dépôt d'un lien (DID cap) dans l'**inbox** du document PdR. Identification du sender par résolution du DID contre le graphe de connexions de l'hôte : connexion → inscription complète visible ; sinon → lien opaque (« quelqu'un (DID…) s'est inscrit »). Anonymat partiel **natif aux capabilities** (cf. [[knowledge_stores-permissions]] §Inbox).
-- **Adhésion à une communauté / suivi : hors périmètre actuel.**
+## Matrix per data type
 
-## Matrice par type de donnée
+### Meeting point
 
-### Point de rencontre
-
-| Verbe | Alice (= Hôte) | I (autre inscrit) | D (déclarant parent) | U (lambda) |
+| Verb | Alice (= Host) | I (other registrant) | D (parent declarer) | U (plain user) |
 |---|---|---|---|---|
-| créer | ✓ (rend hôte) | — | ✗ | ✓ (rend hôte) |
-| lire | ✓ | ✓ | ✓ | ✓ |
-| s'abonner | ✓ | ✓ | ✓ | ✓ |
-| modifier | ✓ | ✗ | ✗ | ✗ |
-| supprimer | ✓ | ✗ | ✗ | ✗ |
+| create | ✓ (becomes host) | — | ✗ | ✓ (becomes host) |
+| read | ✓ | ✓ | ✓ | ✓ |
+| subscribe | ✓ | ✓ | ✓ | ✓ |
+| update | ✓ | ✗ | ✗ | ✗ |
+| delete | ✓ | ✗ | ✗ | ✗ |
 
-Notes : pas de différenciation `C` (les connexions sont un filtre d'affichage UI, pas un droit, tout étant public). Le `D` n'a aucun droit particulier sur les PdR greffés sur son événement.
+Notes: no `C` differentiation (connections are a UI display filter, not a right, since everything is public). `D` has no special right over the meeting points grafted onto their event.
 
-### Inscription à un point de rencontre
+### Registration to a meeting point
 
-`Inscription` lie un utilisateur et un PdR. **Donnée personnelle** (inscrit + ses connexions). Acte composite (a)+(b) ci-dessus.
+`Inscription` links a user and a meeting point. **Personal data** (registrant + their connections). Composite act (a)+(b) above.
 
-| Verbe | Alice (inscrite) | C (connexion) | H (hôte) | I (autre inscrit) | U |
+| Verb | Alice (registrant) | C (connection) | H (host) | I (other registrant) | U |
 |---|---|---|---|---|---|
-| créer (acte composite) | ✓ | — | ✗ | ✗ | ✓ (rend inscrite) |
-| lire le contenu | ✓ | ✓ | cond : ✓ si H ∈ connexions(Alice) ; sinon lien opaque | cond : ✓ si I ∈ connexions(Alice) | ✗ |
-| s'abonner | ✓ | ✓ | cond (idem) | cond (idem) | ✗ |
-| lire l'inbox du PdR (entrées brutes) | — | — | ✓ | ✗ | ✗ |
-| modifier | ? **à trancher** (selon champs) | ✗ | ✗ | ✗ | ✗ |
-| supprimer | ✓ (se désinscrire ; retirer le lien de l'inbox si possible) | ✗ | cond : modération inbox seule (ne supprime pas l'objet) | ✗ | ✗ |
+| create (composite act) | ✓ | — | ✗ | ✗ | ✓ (becomes registrant) |
+| read the content | ✓ | ✓ | cond: ✓ if H ∈ connections(Alice); opaque link otherwise | cond: ✓ if I ∈ connections(Alice) | ✗ |
+| subscribe | ✓ | ✓ | cond (same) | cond (same) | ✗ |
+| read the meeting point's inbox (raw entries) | — | — | ✓ | ✗ | ✗ |
+| update | ? **to be decided** (depends on the fields) | ✗ | ✗ | ✗ | ✗ |
+| delete | ✓ (unregister; remove the link from the inbox if possible) | ✗ | cond: inbox moderation only (does not delete the object) | ✗ | ✗ |
 
-**Visibilité hôte : résolue** (identifiée si connecté, anonyme sinon — natif). **Questions ouvertes :** champs modifiables d'une inscription (booléen seul ou +commentaire/statut/accompagnants ?) ; **suppression côté inbox** — un déposant peut-il retirer son lien d'un doc qu'il ne contrôle pas ? (à vérifier au protocole).
+**Host visibility: resolved** (identified if a connection, anonymous otherwise). **Open questions:** which fields of a registration are editable (a bare boolean, or + comment/status/companions?); **inbox-side deletion** — can a depositor withdraw their link from a document they do not control?
 
-### Événement
+### Event
 
-| Verbe | Alice (= D) | H (hôte d'un PdR greffé) | U |
+| Verb | Alice (= D) | H (host of a grafted meeting point) | U |
 |---|---|---|---|
-| créer | ✓ (rend déclarant) | — | ✓ (rend déclarant) |
-| lire / s'abonner | ✓ | ✓ | ✓ |
-| modifier | ? **à trancher** | ? **à trancher** | ? **à trancher** |
-| supprimer | ? **à trancher** | ✗ | ✗ |
+| create | ✓ (becomes declarer) | — | ✓ (becomes declarer) |
+| read / subscribe | ✓ | ✓ | ✓ |
+| update | ? **to be decided** | ? **to be decided** | ? **to be decided** |
+| delete | ? **to be decided** | ✗ | ✗ |
 
-**Questions ouvertes :** qui peut **modifier** un événement déclaré — déclarant seul (propriétaire) ? tout utilisateur (wiki) ? personne (immuable) ? Central pour la déduplication (cf. concept `functional-domain`, [[brief_2026-06-15_event-deduplication]] côté functional-domain). Qui peut **supprimer**, et que deviennent les PdR greffés (orphelins/cascade/marqué supprimé) ?
+**Open questions:** who may **update** a declared event — the declarer alone (owner)? every user (wiki)? nobody (immutable)? Central to deduplication (concept `functional-domain`, [[brief_2026-06-15_event-deduplication]]). Who may **delete** it, and what becomes of the grafted meeting points (orphaned/cascade/marked deleted)?
 
-### Profil utilisateur
+### User profile
 
-**Rien dans le profil n'est public.** Deux périmètres : **profil réseau** (Alice + connexions : nom, avatar, bio, ville, intérêts) ; **profil privé** (Alice seule : settings, email, préférences).
+**Nothing in the profile is public.** Two scopes: the **network profile** (Alice + connections: name, avatar, bio, city, interests); the **private profile** (Alice alone: settings, email, preferences).
 
-| Verbe | Alice | C | U |
+| Verb | Alice | C | U |
 |---|---|---|---|
-| créer | ✓ (à l'inscription) | — | — |
-| lire — réseau | ✓ | ✓ | ✗ |
-| lire — privé | ✓ | ✗ | ✗ |
-| s'abonner | ✓ | ✓ (réseau) | ✗ |
-| modifier | ✓ | ✗ | ✗ |
-| supprimer (compte) | ✓ | ✗ | ✗ |
+| create | ✓ (at sign-up) | — | — |
+| read — network | ✓ | ✓ | ✗ |
+| read — private | ✓ | ✗ | ✗ |
+| subscribe | ✓ | ✓ (network) | ✗ |
+| update | ✓ | ✗ | ✗ |
+| delete (account) | ✓ | ✗ | ✗ |
 
-**Tension à résoudre :** un PdR est lisible par tous, mais son hôte ne devrait pas être identifiable par un lambda. Trois positions : (i) **pseudonyme par DID seul** (nom/avatar résolus seulement aux connexions) ; (ii) **identité dénormalisée dans l'offre** (l'hôte choisit une « carte de visite » par PdR, vivant dans l'objet PdR, profil fermé) ; (iii) **anonymat de l'hôte** (identité révélée seulement aux connexions). À trancher. Autres : composition champ-par-champ de chaque périmètre ; statut du `username` (public/réseau/supprimé ?).
+**Tension to resolve:** a meeting point is readable by everyone, yet its host should not be identifiable by a plain user. Three positions: (i) **pseudonym through identity alone** (name/avatar resolved only for connections); (ii) **identity denormalized into the offer** (the host picks a "business card" per meeting point, living inside the meeting point object, profile closed); (iii) **host anonymity** (identity revealed only to connections). To be decided. Others: field-by-field composition of each scope; status of the `username` (public/network/dropped?).
 
-### Connexion (lien d'amitié)
+### Connection (friendship link)
 
-Bilatérale. `DemandeDeConnexion` (unilatérale, en attente) → `Connexion` (bilatérale, à l'acceptation ; ouvre l'accès aux données personnelles). La liste de connexions d'Alice est **personnelle** (Alice + ses connexions).
+Bilateral. `DemandeDeConnexion` (one-sided, pending) → `Connexion` (bilateral, upon acceptance; opens access to personal data). Alice's connection list is **personal** (Alice + her connections).
 
-| Verbe | Alice (initiatrice) | Bob (autre côté) | C | U |
+| Verb | Alice (initiator) | Bob (other side) | C | U |
 |---|---|---|---|---|
-| créer la demande | ✓ | — | — | — |
-| accepter | — | ✓ | — | ✗ |
-| lire la liste d'Alice | ✓ | ✓ | ✓ | ✗ |
-| s'abonner | ✓ | ✓ | ✓ | ✗ |
-| supprimer (rompre A↔B) | ✓ | ✓ | ✗ | ✗ |
+| create the request | ✓ | — | — | — |
+| accept | — | ✓ | — | ✗ |
+| read Alice's list | ✓ | ✓ | ✓ | ✗ |
+| subscribe | ✓ | ✓ | ✓ | ✗ |
+| delete (break A↔B) | ✓ | ✓ | ✗ | ✗ |
 
-**Questions ouvertes :** granularité côté Bob (voit-il toute la liste d'Alice ou juste A↔B ? — conséquence du principe : toute la liste) ; découvrabilité « amis d'amis » (Alice voit-elle Bob↔Carole ? — non, sauf si Carole ∈ connexions(Alice)).
+**Open questions:** granularity on Bob's side (does he see Alice's whole list, or only A↔B? — the principle implies: the whole list); "friends of friends" discoverability (does Alice see Bob↔Carole? — no, unless Carole ∈ connections(Alice)).
 
-## Partitions naturelles dérivées
+## Derived scopes
 
-Heuristique : même store si (a) même cellule d'autorisation en écriture *et* (b) accédées ensemble. À partir des seuls points validés, **trois périmètres** émergent — qui correspondent **presque parfaitement aux 3 stores natifs**.
+Heuristic: same scope if (a) same write-authorization cell *and* (b) accessed together. Three **scopes** emerge, plus the bilateral case:
 
-| Périmètre | Écriture | Lecture | Données validées |
+| Scope | Write | Read | Data |
 |---|---|---|---|
-| **Public** ↔ `public_store` | Alice seule | Tous | PdR hébergés par Alice ; événements déclarés *(sous réserve du modèle d'écriture)* |
-| **Réseau** ↔ `protected_store` | Alice seule | Alice + connexions | Profil réseau ; participations ; index des connexions |
-| **Privé** ↔ `private_store` | Alice seule | Alice seule | Profil privé (settings, email, préférences) |
+| **public** | Alice alone | Everyone | Meeting points hosted by Alice; declared events *(subject to the write model)* |
+| **protected** (network) | Alice alone | Alice + connections | Network profile; participations; connection index |
+| **private** | Alice alone | Alice alone | Private profile (settings, email, preferences) |
+| **dialog** (A↔B) | Alice and Bob | Alice and Bob | The bilateral `Connexion` (+ groundwork for future messaging) |
 
-### Cas particulier : la Connexion bilatérale
+The bilateral **`Connexion`** has *two* writers → a **dialog** scope dedicated to the pair; the **"all of Alice's connections" index** lives in *protected* (it lists the connection references). The **meeting point's inbox** is an attribute of the public document, not a separate scope.
 
-Donnée à *deux* écrivains → ne tient dans aucun store individuel. Primitive native : le **Dialog store**. Modèle : **une `Connexion` A↔B = un Dialog store** (contient l'objet + matière à messagerie future) ; l'**index « toutes les connexions d'Alice »** vit dans le `protected_store` d'Alice (liste les NURIs des Dialog stores). La `DemandeDeConnexion` : soit dans un Dialog store provisoire, soit dans le `public_store` du destinataire (à trancher selon le SDK).
+## Query inventory per screen
 
-### Inbox du document PdR
-
-Le doc PdR (dans le `public_store` de l'hôte) a une **inbox** native : reçoit les dépôts d'inscription (liens DID cap), plus tard commentaires/signaux. **Pas un store séparé**, attribut du document. Pas d'impact sur les partitions.
-
-### Ce qui ne demande aucun Group store
-
-Sur le périmètre validé, **aucune donnée ne demande de Group store**. Tout tient dans : 3 stores natifs par utilisateur + Dialog stores + inboxes natives. Les Group stores ne deviennent nécessaires que si le modèle d'écriture événement est « wiki », ou si communautés/suivi/collaboration multi-hôte reviennent dans le périmètre.
-
-### Implication pour [[brief_2026-05-17_multi-store-refactor]]
-
-Ce brief y propose une structure à 4 niveaux de Group stores. **Cette analyse dérive une structure différente** (3 stores natifs + Dialog, sans Group) parce que les concepts qui justifient les Group stores ont été mis hors périmètre. À reconcilier à l'exécution.
-
-## Inventaire des requêtes par écran
-
-*À remplir une fois la matrice stabilisée.* Schéma prévu : `| Écran | Lectures one-shot | Abonnements | Écritures | Acteur déclencheur |`. Écrans à analyser : voir la table de routes (concept `app-architecture`).
+*To be filled in once the matrix has stabilized.* Planned schema: `| Screen | One-shot reads | Subscriptions | Writes | Triggering actor |`. Screens to analyze: see the route table (concept `app-architecture`).
 
 ## See Also
 
-- [[brief_2026-05-17_multi-store-refactor]] — consommateur principal
-- [[brief_2026-06-15_shared-wallet-shim]] — stopgap reprenant ces périmètres
-- `README.md §Modèle fonctionnel` / concept `functional-domain` — source des acteurs
-- Concept `data-layer` — état actuel mono-store
+- Concept `functional-domain` → [[knowledge_data-scopes-and-discovery]] — entity → scope placement + discovery
+- [[knowledge_trust-model]] — isolation is enforced by the SDK
+- `README.md §Modèle fonctionnel` — source of the actors

.project/concepts/app-security/caveat_shared-wallet-global-before-gate-import.md

@@ -0,0 +1,22 @@
+---
+type: caveat
+summary: The wallet password is captured at the EVALUATION of src/shared/utils/sharedWallet.ts; a value set after that first import is never re-read — a missing one used to yield AccessGateScreen's error block, now it makes ensureIdentity() throw and the app render nothing at all, silently
+last_checked: 2026-08-10
+---
+
+# Pitfall: set the wallet-password global BEFORE the module is first imported
+
+The contract requires a deployment to **serve a wallet file and pass its URL and password to `configure`** ([[contract_polyfill-surface]]). Festipod does that from one module, and *when* that module is evaluated decides whether the value arrives at all.
+
+**The invariant.** `src/shared/utils/sharedWallet.ts` reads `globalThis.__FESTIPOD_SHARED_WALLET_PASSWORD__` **exactly once, at module evaluation** (the `SHARED_WALLET_PASSWORD` constant, surfaced by `hasSharedWallet()`). A value set *after* that first import is never re-read. This module used to be `src/modules/auth/sharedWallet.ts`; that file, and `AccessGateScreen` which was its only reason to sit in the `auth` module, are both deleted — the surviving copy lives in `shared/utils/` and is imported by `src/shared/utils/ngSession.ts`, which reads `hasSharedWallet()` to decide whether to pass a `sharedWallet` config into the SDK's `configure()`.
+
+**Why it still matters, and how the consequence changed.** `hasSharedWallet() === false` is a **misconfiguration**, not a degraded mode: the contract makes serving a wallet file and passing its URL and password a deployment requirement, so an app without them cannot sign anyone in. With no `sharedWallet` passed, `ensureIdentity()` **throws**, and `AuthGate` shows its named error panel — loud, which is the point. What must never come back is a silent fallback that renders screens anyway: a session that failed looks exactly like an account that owns nothing.
+
+## Impact — if I touch X, Y breaks
+
+- **Static import = trap.** A static `import` reaching `ngSession.ts` (hence `sharedWallet.ts`) from an entry point that sets the global itself is **hoisted above the assignment** → empty password → the failure mode above, with no JS error at the import site to signal it. The remedy is a **dynamic import** (`await import(...)`) executed after setting the global.
+- **The real entry point that must get this right**: the frontend served from `src/` (`src/app/frontend.tsx` fetches `/festipod-config.json`, sets the global, then imports `App` dynamically — mechanics in `tech-stack` → [[knowledge_build-pipeline]]). A bundle produced by `build.ts` is **not** concerned: there the value is inlined by `define`.
+- **`@ui` reaches the module too, but harmlessly today.** `screens/index.ts` eagerly imports every screen including `SettingsScreen`, which imports `ngSession.ts` — so any `@ui` test already evaluates `sharedWallet.ts` with the global unset. This does not currently break anything because no `@ui` path calls `ensureIdentity()` (`renderScreen()` bypasses `AuthGate`/`NextGraphProvider` entirely); see `bdd-testing` → [[knowledge_ui-layer]] for the detail and for what would make it stop being harmless.
+- **Operations**: a server without `FESTIPOD_SHARED_WALLET_PASSWORD` now fails **silently** (blank page, console-only) rather than with a screen saying so — worth knowing when diagnosing "the app shows nothing."
+
+**Verified (2026-08-10)**: capture at evaluation time in `src/shared/utils/sharedWallet.ts`; the `sharedWallet: hasSharedWallet() ? {...} : undefined` branch in `ngSession.ts`'s `configure()` call; the `throw` in `ensureIdentity()` when no `sharedWallet` config is present; `AuthGate`'s `.catch(err => console.error(...))` with no fallback UI.

.project/concepts/app-security/decision_2026-08-10_sdk-renders-the-barrier.md

@@ -0,0 +1,26 @@
+---
+type: decision
+summary: Festipod deleted its own access-gate screen (AccessGateScreen, its route, its wallet module) and relies entirely on the SDK's ensureIdentity() to show whatever a first-time device needs to see; cost accepted: the app can no longer test that path itself, from any layer
+---
+
+# Decision (2026-08-10): the SDK renders the barrier, Festipod renders none
+
+## Context
+
+[[decision_2026-08-10_the-barrier-names-no-identity]] settled *what* the barrier asks (nothing — no identifier). It left open a separate question: *who draws the screen* a device sees while `ensureIdentity()` resolves — a Festipod component still fed by SDK state, or nothing on Festipod's side at all.
+
+## Decision
+
+**Festipod renders no access screen of its own.** `AccessGateScreen`, its route, its registration, and `src/modules/auth/sharedWallet.ts` (the wallet re-export whose only consumer it was) are deleted. `src/app/AuthGate.tsx` makes a single unconditional `await ensureIdentity()` and renders nothing until it settles — it no longer couples to `useNextGraph()`'s status, `connect()`, or error state. Whatever a user has to see or do while the wallet loads onto a first-time device belongs to the SDK, which shows it: the library owns that flow end to end and absorbed it precisely so consumer applications can delete theirs (see [[contract_polyfill-surface]] on `ensureIdentity`). `src/shared/utils/sharedWallet.ts` keeps the one surviving copy of the wallet material (file URL, password, import URL) and hands it to the SDK through `configure({ sharedWallet })` — Festipod's only remaining involvement is supplying those three values, never displaying them.
+
+## Cost accepted
+
+Festipod now has **no test at all** proving a first-time device can get in. The contract publishes no testid, no DOM contract and no call for a test to interact with the SDK's barrier, so the scenario that used to drive `AccessGateScreen`'s own DOM ("Parcours humain — le testeur importe le portefeuille fourni par Festipod et se connecte", `workshop/multibrowser-harness.feature`) had nothing left to assert and was deleted rather than rewritten. See [[caveat_first-time-entry-untested]] (concept `bdd-testing`). Raised with the provider.
+
+## Rejected alternative
+
+**Keep a thin Festipod wrapper around the SDK's state** (a `status`/`error`/`onEnter`-driven screen, still Festipod-rendered). Rejected: it would recreate the exact code the library moved out of consumer applications, for a flow already declared owned by the SDK — a wrapper an application must still write, test and delete at migration is not an absorption, it is the old cost with new labels.
+
+## Scope
+
+Distinct from [[decision_2026-08-10_the-barrier-names-no-identity]] (that one settles *what* the barrier asks; this one settles *who draws it*). Current state of the flow: [[knowledge_authentication]].

.project/concepts/app-security/decision_2026-08-10_the-barrier-names-no-identity.md

@@ -0,0 +1,34 @@
+---
+type: decision
+summary: The access barrier no longer takes an identifier — the SDK surface stopped letting an application name its own identity, so signing in is one ensureIdentity() call that takes nothing; supersedes the identifier half of the 2026-07-06 and 2026-07-20 arbitrations
+---
+
+# Decision (2026-08-10): the barrier names no identity
+
+## Context
+
+Earlier arbitrations put an **identifier** at the access barrier: the user typed it in the same act that opened the wallet, and the application handed it to the data layer. They rested on a premise the provider has since withdrawn — that an application **names its own identity**. (Those leaves were deleted on 2026-08-16, with everything else that described the data layer's internals; `git log` has them.)
+
+The pulled [[contract_polyfill-surface]] removes that premise explicitly. `ensureIdentity()` takes **no identifier**, and the contract states why: naming your own identity is *"the gesture that inverts the model"*, so a "set my identity" call was removed rather than renamed. There is no successor call — the capability is gone, not relocated.
+
+## Decision
+
+**Festipod does not name, persist or switch its own identity.** Concretely:
+
+- The barrier asks for nothing but the wallet: « Entrer » triggers the broker redirect and nothing else.
+- Signing in is **one await on `ensureIdentity()`**, in `src/app/AuthGate.tsx`, before any screen renders.
+- All app-side identity machinery is deleted: the identity context, the `?id=` URL param that carried it across the broker round-trip, the localStorage key, the app-level (faux) logout. The only logout left is the **wallet session** one.
+- **Who the current user is** is no longer derived from an input; it is **the profile document read back in the app's own protected scope**.
+
+## Consequences accepted with it
+
+- **Multi-identity on one page is no longer expressible**, and that is correct rather than missing: it was a property of *one wallet hosting several identities*, i.e. emulation scaffolding. Multi-user is exercised as it is lived — several browser contexts, each signing in as itself ([[rule_tests-validate-festipod-not-the-sdk]] in bdd-testing).
+- **The `@data` layer lost its per-scenario determinism**, which the app used to provide by planting a fresh identity per scenario. The app cannot restore it — choosing which identity comes up is exactly what the surface no longer allows. Open, with the provider: [[caveat_data-scenarios-share-one-wallet]].
+
+## Rejected alternative
+
+**Keeping an app-side identifier and mapping it onto the SDK behind the scenes.** Rejected: it would teach the application a model it must unlearn, and it would convert a deliberate provider decision into an app-side workaround nobody revisits ([[rule_app-uses-sdk-surface-only]]).
+
+## Scope
+
+Supersedes every earlier arbitration that put an identifier at the barrier. Current state of the flow: [[knowledge_authentication]].

.project/concepts/app-security/knowledge_authentication.md

@@ -1,20 +1,33 @@
 ---
 type: knowledge
-summary: Authentification = possession d'un wallet NextGraph ; tous les utilisateurs sont authentifiés (pas d'accès anonyme) ; l'auth passe par le redirect/iframe broker, et l'app n'auto-connecte que dans l'iframe
+summary: A user's identity = their NextGraph wallet; every user is authenticated (no anonymous access); the app never names, persists or switches its own identity, and renders no access screen of its own — AuthGate awaits ONE unconditional ensureIdentity() before anything renders
+last_checked: 2026-08-10
 ---
 
-# Authentification
+# Authentication
 
-**L'identité d'un utilisateur = son wallet NextGraph.** Il n'y a **pas d'accès anonyme** à l'app : tout utilisateur est authentifié (cf. concept `functional-domain`). Il n'y a pas de système de comptes/mots de passe applicatif — l'auth est déléguée à NextGraph.
+**A user's identity = their NextGraph wallet.** There is **no anonymous access** to the app: every user is authenticated (see concept `functional-domain`). There is **no application-level account/password system** — authentication is **delegated to the data SDK** (`@ng-eventually/polyfill`): opening your session means opening your wallet.
 
-## Flux
+## The flow — one act, no screen of Festipod's own
 
-- `LoginScreen` (`src/modules/auth/screens/`) déclenche la connexion via `useNextGraph()` (ne consomme pas `useFestipodData`).
-- Le flux standard `@ng-org/web` est un **redirect vers le broker** (`nextgraph.net/redir/`) qui recharge l'app dans une **iframe** après authentification (détail dans concept `nextgraph-platform`, [[knowledge_integration-model]] côté nextgraph-platform).
-- **L'app n'auto-connecte que dans l'iframe broker** (`window.self !== window.top`) — sinon `initNgWeb()` redirigerait toute la page. Cette règle vit côté data-layer ([[rule_conditional-ng-init]]) car elle concerne le cycle `NextGraphContext`, mais elle a une conséquence sécurité directe : **hors iframe, aucune session n'est ouverte sans action explicite** de l'utilisateur.
+**Signing in is `src/app/AuthGate.tsx`'s single, unconditional `await ensureIdentity()`.** It fires on mount, with no dependency on `NextGraphContext`'s connection status. **Nothing of the app renders before it resolves**: `ensureIdentity()` settles who we are *and* does the connection work (restoring what others shared with us). A screen mounted earlier would read as an identity that is not yet settled.
 
-## Le wallet de test
+**Festipod renders no access screen of its own.** `AccessGateScreen`, its route and its registration are deleted; whatever a user has to see or do while the SDK resolves — opening the shared wallet, loading it onto a first-time device — is drawn entirely by the SDK. The library owns that flow and absorbed it precisely so consumer applications can delete theirs. See [[decision_2026-08-10_sdk-renders-the-barrier]].
 
-Les tests `@data`/`@e2e` créent/ouvrent un wallet réel (`festipod-tests`/`festipod-tests`, profil persistant) — voir concept `bdd-testing`. Ce sont des **credentials de test en clair**, sans enjeu de sécurité, dédiés au staging (cohérent avec la posture « utilisateurs amicaux » du stopgap, concept `nextgraph-platform`).
+**The application never names, persists or switches its own identity.** `ensureIdentity()` takes **no identifier**, deliberately, and the contract states that **no other call takes one either** ([[contract_polyfill-surface]]). There is consequently **no** app-side identity state at all: no identity context, no `?id=` URL param, no localStorage identity key, no "set my identity" call. See [[decision_2026-08-10_the-barrier-names-no-identity]].
 
-> Le modèle d'autorisations qui s'appuiera sur cette identité (connexions bilatérales, données personnelles = réseau, anonymat hôte) est en incubation : [[brief_2026-05-18_authorization-matrix]].
+**Festipod's only remaining involvement is supplying the wallet material, never displaying it.** `src/shared/utils/sharedWallet.ts` holds the one copy of the file URL, password and import URL this deployment hands out, and passes them to the SDK through `configure({ sharedWallet })` in `src/shared/utils/ngSession.ts` — the contract makes that a deployment requirement. The one hazard left around that module is an evaluation-order trap, [[caveat_shared-wallet-global-before-gate-import]]. Misconfiguration (no password set) makes `ensureIdentity()` throw, and `AuthGate` shows its named error panel instead of any screen.
+
+**Signing out.** The only logout left is the **wallet session** one (`logoutNg`, offered as « Quitter l'environnement de test » in the settings screen): it stops the shared-wallet session so the next access goes back through the broker. There is no app-level sign-out, because there is no app-level identity to sign out of.
+
+## Who the current user IS, seen from the app
+
+The app does not derive an identity from anything it was told; **what it is, is the profile document it reads back in its own protected scope**. That value is therefore empty until the protected read lands — the mechanics and the hazard that follows live in concept `data-layer`, [[knowledge_context-internals]] and `app-architecture` → [[caveat_identity-ids-in-screens]].
+
+**Vocabulary.** `username` designates the profile handle `UserProfile.username` and nothing else. `normalizeIdentifier` (`src/shared/utils/identifier.ts`) is a **pure string normalization** of that handle, applied only to `UserProfile.username` — the join between a profile and the person it belongs to, and the name given when sharing a document with a neighbour. It is never applied to the identity: normalising an identity belongs to the data layer, which the contract states outright, and no configuration hook takes it from us. It names no space, account or session.
+
+## The test wallet
+
+The `@data`/`@e2e` tests open a real wallet (`festipod-tests`, persistent profile) — see concept `bdd-testing`. These are **plaintext test credentials**, with no security stake, dedicated to staging. Since no call takes an identifier, a scenario cannot choose which identity it comes up as: every scenario in a run shares that one wallet, which keeps growing — [[caveat_data-scenarios-share-one-wallet]] (bdd-testing).
+
+> The authorization model that will build on this identity (bilateral connections, personal data = network, host anonymity) is incubating: [[brief_2026-05-18_authorization-matrix]].

.project/concepts/app-security/knowledge_trust-model.md

@@ -1,21 +1,25 @@
 ---
 type: knowledge
-summary: Posture de sécurité actuelle — aucun contrôle d'accès côté app, l'app lit/affiche le private_store de l'utilisateur connecté et fait confiance au broker NextGraph pour ne retourner que des données autorisées ; mono-user de fait
-last_checked: 2026-06-15
+summary: Isolation between scopes (public/protected/private) is enforced by the data SDK; the app trusts it and only displays what it returns — no access control in the screens, and the only thing it declares is which of its own documents it shares with whom
+last_checked: 2026-08-10
 ---
 
-# Modèle de confiance actuel
+# Trust model
 
-**Posture observée dans `src/shared/context/FestipodDataContext.tsx` (`useNgData`) :** l'app lit tout ce que les subscriptions ORM retournent depuis le `private_store` de l'utilisateur connecté et l'affiche **sans aucun filtre d'autorisation côté app**.
+**Stance:** the app reads data through the ORM subscriptions of the `@ng-eventually/polyfill` SDK and displays it **with no app-side authorization logic** (`src/shared/context/FestipodDataContext.tsx`, `useNgData`).
 
-Conséquences (à connaître avant de raisonner sécurité) :
+Principles:
 
-1. **Aucun contrôle d'accès applicatif.** Pas de vérification « l'utilisateur a-t-il le droit de voir cette donnée ». L'app suppose que **le broker/NextGraph ne retourne que ce que l'utilisateur peut voir**. Toute la confidentialité repose sur cette confiance dans la couche NextGraph, pas sur du code Festipod.
-2. **Mono-store, donc mono-user de fait.** Tout (events, profils, participations) vit dans le `private_store` de l'utilisateur connecté (cf. concept `data-layer`, [[decision_2026-03-17_private-store-nuri-scope]] côté data-layer). Un autre utilisateur ne voit rien — par construction, le `private_store` n'est pas partageable. Il n'y a donc rien à « autoriser » : chacun ne voit que ses propres données.
-3. **Pas de séparation de périmètres.** Le découpage public / réseau / privé du modèle cible ([[brief_2026-05-18_authorization-matrix]]) **n'existe pas encore** dans le code : aucun `protected_store`/`public_store` n'est utilisé pour le métier.
+1. **Isolation is delegated to the SDK.** Every entity lives in the store of its **scope** (public / protected / private, see concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]); the SDK **exposes to the current user only what they are entitled to**. The app assumes that whatever it receives is already authorized — privacy rests on the SDK, not on Festipod code.
+2. **Screens carry no access rules.** No "is this user allowed to see this data" check in the components, nor in the data context. The public / network / private separation is a property of **placement by scope**, not of an application-level filter.
+3. **The relationship between users ("connections") is an application-level notion.** The contract publishes no connection or friendship primitive: it models reading as **key possession**, and giving someone that key is **one act** — `inbox.share(doc, toUser)`, naming the document and the person. The app therefore **owns** its relationship graph (`src/shared/utils/connections.ts`) and, once a link is two-sided, **shares its own protected documents** with that neighbour. It does not delegate the notion of a relationship, only the **enforcement** of the isolation that follows from it.
 
-## Le piège pour la suite
+   What the app declares to the SDK is now **only those shares**: it declares **no identity** ([[decision_2026-08-10_the-barrier-names-no-identity]]), and it **never handles a key or an inbox address** — neither exists in app code. Sharing is also **irreversible**: the contract publishes no revocation, so an act of sharing is permanent ([[contract_polyfill-surface]]).
 
-Le jour où le multi-user arrive (lecture cross-wallet, voir les briefs de `nextgraph-platform`), cette **absence d'enforcement applicatif devient un risque** : si la séparation reste portée seulement par la crypto/capabilities NextGraph et que l'app continue d'afficher « tout ce qu'elle reçoit », une fuite de capability = une fuite de données. Le stopgap `shared-wallet-shim` (concept `nextgraph-platform`) prévoit d'ailleurs un **filtre d'isolation applicatif** explicite parce que, dans ce mode, un seul wallet rend tout physiquement lisible.
+## The point to watch
 
-> À vérifier si on doute : `useNgData` dans `FestipodDataContext.tsx` ne contient aucune branche de filtrage par identité ; les seuls IDs manipulés sont ceux du wallet courant.
+Because the app **displays everything it receives**, privacy rests entirely on the SDK exposing only what is legitimate. It is a deliberate choice (the app stays thin), but it means **never reintroducing on the screen side a piece of data that the scope should not have let through**.
+
+**And never promise anonymity.** The contract guarantees isolation per document; it guarantees **no anonymity** — nothing per reader on a public document, no revocation, and a reference that names a person's document remains comparable wherever it travels. So a Festipod action that circulates such a reference (a sign-up, an invitation, a mention, an index entry) is **pseudonymous at best**: do not label it "anonymous" in the interface, and count the contexts in which you expose the same reference.
+
+> To check when in doubt: `useNgData` in `FestipodDataContext.tsx` contains no identity-filtering branch — that is intentional, isolation comes from below.

.project/concepts/bdd-testing/_overview.md

@@ -1,36 +1,40 @@
 ---
 type: _overview
-summary: BDD Cucumber/Gherkin en français sur 3 couches (@ui, @data, @e2e) — setup, contrat de couches (quoi tester où), harness broker réel, et le piège des vestiges source-grep
+summary: BDD Cucumber/Gherkin in French across 3 layers (@ui, @data, @e2e) — setup, layer contract (what to test where), real broker harness, and the source-grep leftovers pitfall
 triggers:
-  keywords: [cucumber, gherkin, bdd, feature, scenario, scénario, step, steps, "@ui", "@data", "@e2e", playwright, broker, harness, wallet, world, hooks, renderHelper, multibrowser, multi-navigateur, "@multibrowser", "@private-wallet", "@shared-wallet", storageState, "@wip"]
+  keywords: [cucumber, gherkin, bdd, feature, scenario, scénario, step, steps, "@ui", "@data", "@e2e", playwright, broker, harness, wallet, world, hooks, renderHelper, multibrowser, multi-navigateur, "@multibrowser", "@shared-wallet", storageState, "@wip", "@humain"]
   paths: ["src/modules/*/features/**", "src/modules/*/steps/**", "src/shared/steps/**", "src/shared/support/**", "src/shared/test-harness/**", "cucumber.json"]
 ---
 
 # BDD testing
 
-Tests BDD **Cucumber/Gherkin en français** (`Etant donné`, `Quand`, `Alors`) sur **3 couches** de coût croissant.
+BDD tests written in **Cucumber/Gherkin in French** (`Etant donné`, `Quand`, `Alors`) across **3 layers** of increasing cost.
 
-**À lire avant d'écrire un test :** [[rule_test-layer-contracts]] — chaque couche répond à une question distincte ; mélanger produit des tests fragiles. C'est la règle qui décide *où* va une assertion.
+**Read before writing a test:** [[rule_test-layer-contracts]] — each layer answers a distinct question; mixing them produces brittle tests. That is the rule which decides *where* an assertion belongs. And [[rule_tests-validate-festipod-not-the-sdk]] — which decides *whether the assertion belongs here at all*.
 
-## Les 3 couches
+## The 3 layers
 
 ```
-       /\  @e2e   app réelle dans l'iframe broker — parcours critiques
+       /\  @e2e   real app inside the broker iframe — critical journeys
       /  \
-     /----\  @data  mutations & persistance via broker NextGraph réel
+     /----\  @data  mutations & persistence through the real NextGraph broker
     /------\
-   /  @ui   \  rendu d'écran in-process (happy-dom + seed) — le gros du volume
+   /  @ui   \  in-process screen rendering (happy-dom + seed) — the bulk of the volume
   /__________\
 ```
 
-## Liens
+## Links
 
-- [[rule_test-layer-contracts]] — quoi tester à chaque couche (le contrat)
-- [[knowledge_cucumber-setup]] — config, layout, scripts, fichiers auto-générés
-- [[knowledge_ui-layer]] — couche `@ui` : render helper, fixtures, bons/anti patterns
-- [[knowledge_data-layer-broker]] — couche `@data` : harness broker, cycle de vie wallet, bridge
-- [[knowledge_e2e-layer]] — couche `@e2e` : app réelle dans l'iframe
-- [[knowledge_multibrowser-harness]] — plusieurs navigateurs isolés × modèle de wallet (private/shared), injection storageState
-- [[decision_2026-03-12_headless-wallet-creation]] — pourquoi le wallet de test est créé en UI headless
-- [[caveat_source-grep-vestiges]] — vestiges de l'ère « analyse de source » dans `world.ts`
-- [[cookbook_add-scenario]] — ajouter un scénario/step (couches, piège de sérialisation `evaluate`, `@wip`)
+- [[rule_test-layer-contracts]] — what to test at each layer (the contract)
+- [[rule_tests-validate-festipod-not-the-sdk]] — the subject under test is Festipod's behaviour, never the SDK's; no shortcut past the published surface
+- [[knowledge_cucumber-setup]] — config, layout, scripts, auto-generated files
+- [[knowledge_ui-layer]] — the `@ui` layer: render helper, fixtures, good and bad patterns
+- [[knowledge_data-layer-broker]] — the `@data` layer: broker harness, wallet lifecycle, bridge
+- [[knowledge_e2e-layer]] — the `@e2e` layer: the real app inside the iframe
+- [[knowledge_multibrowser-harness]] — several isolated browsers on the shared wallet (storageState injection); the only way multi-user is exercised
+- [[caveat_data-scenarios-share-one-wallet]] — a scenario cannot choose its identity, so all of them share one wallet that nothing empties: no per-scenario isolation
+- [[caveat_reconnexion-froide-local-vs-broker]] — a "fresh page" is not a cold start: which setup proves broker durability, and which one just re-reads local
+- [[caveat_first-time-entry-untested]] — **open**: no test proves a first-time device can get into Festipod any more; the SDK's replacement barrier publishes nothing to test against
+- [[decision_2026-03-12_headless-wallet-creation]] — why the test wallet is created through a headless UI
+- [[caveat_source-grep-vestiges]] — leftovers from the "source analysis" era in `world.ts`
+- [[cookbook_add-scenario]] — adding a scenario/step (layers, `evaluate` serialization pitfall, `@wip`)

.project/concepts/bdd-testing/caveat_data-scenarios-share-one-wallet.md

@@ -0,0 +1,25 @@
+---
+type: caveat
+summary: A @data scenario cannot choose which identity it comes up as — no published call takes an identifier — so every scenario in a run shares one identity and one physical wallet, which nothing empties. Per-scenario isolation is GONE, and the wallet grows for the whole run.
+last_checked: 2026-08-10
+---
+
+# Pitfall: one wallet, one identity, nothing that empties it
+
+## What is verified
+
+**No scenario can name the identity it opens as.** [[contract_polyfill-surface]] is explicit: `ensureIdentity()` takes no identifier, *"and no other call takes one"*. So a scenario gets whatever identity the wallet in `.playwright-profile` resolves to — the same one, every time.
+
+Machinery from when this was not true is still in the tree and is now **inert**: the `Before` hook mints a unique identifier (`freshScenarioIdentifier`, `src/shared/support/hooks.ts`) and injects it via `addInitScript` into `localStorage['festipod.account.identifier']`, and several steps re-inject it. Nothing consumes that key. **Do not build new setup on it, and do not "repair" it** by making the app read it again — naming your own identity is exactly what the surface refuses.
+
+## What follows, and gets worse
+
+**Everything a run writes lands in ONE wallet, and nothing removes it.** There is no per-scenario reset: the old one (`resetDataState()`, a SPARQL DELETE on the anchor graph) was dropped for cost and its helper is gone. So each scenario leaves its documents behind for every later scenario to carry — within a run, and across runs. That is the source of [[caveat_wallet-bloat-hang]].
+
+The practical signature: hook timeouts on `__testData.ready` that appear **partway through a run** and get worse the longer the profile has lived, **with no console error at all**. Silence is the tell — a wallet that has stopped answering just stops answering.
+
+So: a scenario failing on **stale data from an earlier scenario** is expected, not a surprise — scenarios are not isolated. A scenario **timing out in `Before`**, especially the fifth one onward, is the wallet, not the assertion. Move the profile aside and re-measure before diagnosing anything else ([[caveat_wallet-bloat-hang]]).
+
+## What is missing
+
+A way to start a scenario from a clean slate. The surface publishes no teardown and no throwaway-wallet call, and there is nothing to fake here: it is a **gap to raise with the provider**, stated as the need — *a scenario must be able to begin on an empty space*. Until then, per-scenario determinism is not available at the `@data` layer, and scenarios must be written so they do not depend on it.

.project/concepts/bdd-testing/caveat_first-time-entry-untested.md

@@ -0,0 +1,29 @@
+---
+type: caveat
+summary: No test proves a first-time device can get into Festipod — the scenario that drove AccessGateScreen's own DOM was deleted with the screen, and the SDK's replacement barrier publishes no testid or contract to write a new one against
+last_checked: 2026-08-10
+---
+
+# Caveat: first-time entry has no test, and none can be written from here
+
+## What is gone
+
+`workshop/multibrowser-harness.feature` used to carry « Parcours humain — le testeur importe le portefeuille fourni par Festipod et se connecte »: a fresh browser opened the staging app, `AccessGateScreen` offered the wallet file and password, the file was downloaded **from the screen** (`[data-testid=shared-wallet-download]`), the password checked against the wallet's own (`[data-testid=shared-wallet-password]`), imported on `nextgraph.eu`, then an identifier typed (`[data-testid=identifier-input]`) and « Entrer » clicked — landing on the connected home screen. Every step drove **Festipod's own DOM**.
+
+`AccessGateScreen` is deleted (concept `app-security`, [[decision_2026-08-10_sdk-renders-the-barrier]]), and with it every testid the scenario asserted on, the steps that drove them (`src/modules/workshop/steps/data/multibrowser.steps.ts`), and the helpers built only for this scenario (`pool.ensureStagingApp`, `pool.importWalletViaFile`, `findE2eWalletFile`, the `dist-staging` build in `hooks.ts`).
+
+## Why it cannot be rewritten, not just why it was deleted
+
+The scenario was not migrated to assert against something else, because there is nothing to migrate it to: `ensureIdentity()` (`@ng-eventually/polyfill`) is a plain async function with no published testid, no documented DOM contract, and no call a test could make to drive or observe what it shows a first-time device. [[contract_polyfill-surface]] (concept `data-layer`) states only the call's signature and behaviour, not a UI shape — by design, since that UI is exactly the part the SDK owns and Festipod must not couple to.
+
+## What is true today
+
+**No test at all — `@ui`, `@data`, `@e2e`, or `@humain` — proves that a first-time device can sign into Festipod.** The `@shared-wallet` multi-browser scenario ([[knowledge_multibrowser-harness]]) injects the wallet via `storageState`, bypassing the import entirely; every `@data`/`@e2e` scenario runs on a persistent profile that is already signed in before `ensureIdentity()` ever runs ([[caveat_data-scenarios-share-one-wallet]]), so none of them exercises the path a genuinely new user takes either.
+
+## What would close it
+
+A test contract published by the SDK for its own barrier (a testid, an event, a promise a test can await) — this is a gap in what Festipod consumes, not in what Festipod tests. Raised with the provider. Until one exists, this path is verified only by hand.
+
+## Links
+
+[[knowledge_multibrowser-harness]] — where the deleted scenario lived. Concept `app-architecture` → [[caveat_boot-unverified-outside-broker]] — the related, narrower question of whether the boot even completes outside the broker iframe.

.project/concepts/bdd-testing/caveat_reconnexion-froide-local-vs-broker.md

@@ -0,0 +1,51 @@
+---
+type: caveat
+summary: A "fresh page" on the PERSISTENT context never proves broker durability — it re-reads the same profile's IndexedDB; only a non-persistent context spawned from freshBrowser, seeded solely by the BeforeAll storageState, settles broker-vs-local
+last_checked: 2026-08-10
+---
+
+# Pitfall: a "fresh page" is not a cold start (local vs broker)
+
+**Reconnection** scenarios all ask the same question — *does the user get their own data back after closing and reopening?* — but **depending on the browser context chosen, they do not answer the same question**. That is the pitfall: the most natural setup (`ctx.newPage()`) yields a green that proves nothing about the broker.
+
+## The two setups, and what each one proves
+
+| Setup | Where | What it proves | What it does NOT prove |
+|---|---|---|---|
+| `this.page!.context().newPage()` — fresh page on the **persistent** context (`.playwright-profile`) | `reconnexion.steps.ts` (@data), `reconnexion-persistance.steps.ts` (@e2e) | a new broker login and a full remount of the providers, with nothing carried over in memory | nothing about **broker durability**: the profile **still holds local data** in IndexedDB, so a "fresh" reader may well read **from local** |
+| `spawnContext('shared')` — **non-persistent** context spawned from `freshBrowser` | `reconnexion-froide-sans-local.steps.ts` (@data) | that the data **reached the broker** (or did not) | nothing about the real UI journey (this is the harness, not the app) |
+
+**Invariant.** Any assertion of the form "the write is durable broker-side" **requires** the second setup. Making that assertion on a fresh page of the persistent context produces a false green (or a red blamed on the broker when it is really local/timing).
+
+## What makes the "no-local" verdict valid (do not break it)
+
+Three conditions, all met in `reconnexion-froide-sans-local.steps.ts`:
+
+1. **Separate process** — `freshBrowser` is a non-persistent `chromium.launch`, distinct from the profile carrying the wallet (see [[knowledge_multibrowser-harness]] for the isolation proven all the way to the broker origin).
+2. **Hermetic partition** — every Playwright `newContext()` has its own storage; no IndexedDB shared with the writing page.
+3. **The only pre-injected state is `pool.sharedWalletState`**, captured **once at `BeforeAll`**, hence **before** the scenario writes anything → the snapshot **cannot** contain the data under test.
+
+> **Impact if you touch the storageState capture** (`hooks.ts` `BeforeAll` → `pool.sharedWalletState`): moving it later, re-capturing it per scenario, or adding a warm-up that writes data **silently invalidates** the verdict of every "cold, no local" scenario — they would turn green by re-reading the snapshot. The step **fails outright** when `sharedWalletState` is missing (by design: no verdict beats a false verdict).
+
+## Reconnection vs isolation — the identifier no longer decides anything
+
+`isolation.steps.ts` and `reconnexion.steps.ts` set up **the same machinery** (fresh page plus an identifier written into `localStorage['festipod.account.identifier']` via `addInitScript`). That identifier used to be the **only** thing telling them apart — same value re-injected = reconnection, new value = a distinct identity B.
+
+**It decides nothing now**: nothing reads that key, so both setups yield the **same** identity. The reconnection sense still holds (a fresh page on the same wallet is genuinely a reconnection); the **isolation** sense is gone — the setup can no longer produce a second identity at all, which is why `event/isolation-deux-identites.feature` is `@wip`. Proving isolation now needs **two genuinely separate browser contexts**, each signing in for itself ([[rule_tests-validate-festipod-not-the-sdk]]). Background: [[caveat_data-scenarios-share-one-wallet]].
+
+## Reads stay reactive, even when "waiting a long time"
+
+The reconnection `Then` steps read the **reactive** state (`homeEventTitles` on the bridge, via `waitForFunction`) — never a broker re-read loop ([[rule_no-broker-polling]]). The long diagnostic step (« … en laissant jusqu'à 60 secondes à la barrière avec rechargements ») does loop, but over the **reactive state already pushed** plus **full page reloads** (each reload = a new mount, hence a fresh attempt at reaching a synced state): that is the pragmatic fallback the rule explicitly allows, not broker polling. The distinction to keep in mind — *observing the reactive state* versus *re-issuing a broker read*.
+
+## Current state of the scenarios
+
+`reconnexion-froide-sans-local.feature`, the `@reconnexion-pause` scenario of `reconnexion-meme-identite.feature` and `reconnexion-persistance-e2e.feature` are **`@wip`**: they are **diagnostic instruments** (they print a verdict to stdout / as a Cucumber attachment), not regression guards. `@wip` is excluded from the default run (`cucumber.json`) — run them explicitly with `--tags`. The **non-`@wip`** scenario of `reconnexion-meme-identite.feature`, on the other hand, is a genuine guard and must stay green.
+
+> This leaf describes **the test setup that produces a readable verdict**, and nothing else. What a write has to clear to be durable is not this repo's to explain — if a verdict comes back negative, that is a finding to raise with the provider, not a mechanism to write up here.
+
+## Links
+
+- [[knowledge_data-layer-broker]] — the single-browser `@data` layer (persistent profile).
+- [[knowledge_multibrowser-harness]] — `freshBrowser`, `spawnContext`, `pool.sharedWalletState`.
+- [[knowledge_e2e-layer]] — the `@e2e` counterpart (real app) of the "close and reopen" setup.
+- [[rule_no-broker-polling]] — the red line waiting steps must not cross.

.project/concepts/bdd-testing/caveat_source-grep-vestiges.md

@@ -1,21 +1,21 @@
 ---
 type: caveat
-summary: world.ts garde des vestiges de l'ère « analyse de source » (screenFileMap, screenFieldDetectors, screenExpectedContent, screenRequiredFields ; hasText/hasField/hasElement à fallback source) — à supprimer une fois la migration @ui vers le DOM rendu terminée
+summary: world.ts still carries leftovers from the "source analysis" era (screenFileMap, screenFieldDetectors, screenExpectedContent, screenRequiredFields; hasText/hasField/hasElement with a source fallback) — to be deleted once the @ui migration to the rendered DOM is complete
 last_checked: 2026-06-15
 ---
 
-# Caveat : vestiges d'analyse de source dans `world.ts`
+# Caveat: source-analysis leftovers in `world.ts`
 
-La suite `@ui` **précède** le contrat de couches ([[rule_test-layer-contracts]]). Des restes de l'ère « grep sur le code source » subsistent et **ne doivent pas être étendus** :
+The `@ui` suite **predates** the layer contract ([[rule_test-layer-contracts]]). Remnants of the "grep the source code" era are still around and **must not be extended**:
 
-- `world.ts:screenFileMap`, `screenFieldDetectors`, `screenExpectedContent`, `screenRequiredFields` — mappings de l'approche analyse-de-source.
-- `hasText` / `hasField` / `hasElement` — **préfèrent désormais le DOM rendu** mais **retombent sur la source** pour que les steps non migrés continuent de marcher pendant la transition.
+- `world.ts:screenFileMap`, `screenFieldDetectors`, `screenExpectedContent`, `screenRequiredFields` — mappings from the source-analysis approach.
+- `hasText` / `hasField` / `hasElement` — they now **prefer the rendered DOM** but **fall back to the source** so that unmigrated steps keep working during the transition.
 
-## Plan de migration (en cours)
+## Migration plan (in progress)
 
-1. Réécrire les assertions grep-source → requêtes DOM via le render helper.
-2. Supprimer les tests sur détails d'implémentation (`/showDuplicateWarning/`, `/importableEvents/`, regex sur JSX).
-3. Déplacer les assertions comportementales vers `@e2e` quand pas déjà couvertes.
-4. Retirer les checks de contenu `@e2e` redondants avec `@ui`.
+1. Rewrite grep-the-source assertions as DOM queries through the render helper.
+2. Delete tests that assert implementation details (`/showDuplicateWarning/`, `/importableEvents/`, regexes over JSX).
+3. Move behavioural assertions to `@e2e` where they are not already covered.
+4. Drop the `@e2e` content checks that duplicate `@ui`.
 
-Une fois la migration terminée, les 4 maps vestiges peuvent disparaître au profit d'assertions sur le DOM rendu + seed. **Tant qu'elles existent, ne pas s'appuyer dessus pour de nouveaux tests.**
+Once the migration is done, the 4 leftover maps can go away in favour of assertions on the rendered DOM plus seed data. **As long as they exist, do not rely on them for new tests.**

.project/concepts/bdd-testing/caveat_wallet-bloat-hang.md

@@ -0,0 +1,37 @@
+---
+type: caveat
+summary: The @data suite degrades within a run and across runs, silently — later scenarios time out in Before with nothing in the console. Moving .playwright-profile aside does NOT reset the data (the served wallet file is what holds it), so two "fresh profile" runs measure the same accumulated state; the only real lever is serving a new wallet file, which nothing here does yet.
+last_checked: 2026-08-16
+---
+
+# Pitfall: the test wallet saturates — within a run, and across runs
+
+The persistent Chromium profile `.playwright-profile` (at the root of the working tree) carries the **wallet** the whole `@data`/`@e2e` suite opens. Every scenario reads and writes through it, so anything that slows that wallet down slows everything.
+
+Two distinct phenomena, and the first is the one that bites today.
+
+## Within a single run — the binding constraint
+
+**Symptom, VERIFIED.** On a **fresh** profile, on an idle machine, per-scenario duration climbs monotonically (observed 7 s → 53 s across the six that pass), then every later scenario dies in the `Before` hook on `frame.waitForFunction` at its 30 s cap. **Silently** — no error, no rejection, nothing in the console. Reproduced twice with identical results (6 of 14 passing, 8 min 34 s and 8 min 37 s).
+
+**What it is NOT.** Runs that never exit leave a Chromium and two servers resident (see below), and it was reasonable to suspect that pressure. **Ruled out by measurement**: one of the two runs above happened with four leaked browsers and two leaked servers alive, the other on a cleaned machine — same pass count, same duration. Leaked processes are a real defect and not this cause.
+
+**The likely mechanism, INFERRED.** Every scenario in a run writes into the **same wallet**, and nothing removes what it wrote ([[caveat_data-scenarios-share-one-wallet]]) — so each one leaves behind documents that every later scenario carries. That is not something tidying the test code can fix. What would settle it is a reset the surface does not publish (a teardown call, or a throwaway wallet per run): raise it with the provider rather than faking one here.
+
+**Practical reading.** A `Before` timing out, especially from roughly the sixth scenario onward, is the wallet — not the assertion below it, and not the step definition. Diagnose the run's shape before diagnosing the scenario.
+
+## Moving the profile aside does NOT reset the data — corrected 2026-08-16
+
+The reset this leaf used to prescribe (`mv .playwright-profile …`) gives a fresh **browser profile**, not fresh **data**. The suite's data lives in the wallet file the deployment serves (`FESTIPOD_SHARED_WALLET_FILE`, a fixed `.ngw` at the working-copy root), which is the same file on every run and whose state persists outside the profile entirely. Recreating the profile makes the harness build a new broker-side wallet to get *into* the broker; the app then opens the same served wallet as always.
+
+This matters beyond the inconvenience: two measurements taken "on a fresh profile" are **not** two measurements on fresh data. A pair of identical numbers from them proves reproducibility and nothing about accumulation — a conclusion drawn from exactly that mistake had to be withdrawn.
+
+**The lever we actually have** is the served wallet file: it is the application's own deployment parameter, not something the provider controls. Serving a new one gives genuinely empty data. Nothing in this repo does that yet.
+
+Until it does, treat any `@data` number as **relative to whatever that wallet already holds**, and do not compare two runs taken days apart as if they measured the same thing.
+
+## The leak that makes it worse
+
+A Cucumber run prints its summary and then **does not exit**, leaving a Chromium and two servers alive (runs observed still resident 2-3 hours after reporting). It does not cause the degradation above, but it fills the machine and forces manual cleanup. Kill the process after reading the summary until the teardown releases what it opens.
+
+> This caveat describes only what is observable on the test side. Why a saturated wallet stops answering is not this repo's to explain.

.project/concepts/bdd-testing/cookbook_add-scenario.md

@@ -1,29 +1,29 @@
 ---
 type: cookbook
-summary: Procédure pour ajouter un scénario/step BDD — .feature français taggé, steps par couche, piège de sérialisation de appFrame.evaluate (passer les args, pas de closure), ajouter les helpers aux DEUX harness, tag @wip pour le non-implémenté
+summary: How to add a BDD scenario/step — a tagged French .feature, steps per layer, the appFrame.evaluate serialization pitfall (pass arguments, no closures), add helpers to BOTH harnesses, @wip tag for what is not implemented yet
 ---
 
-# Cookbook : ajouter un scénario / un step
+# Cookbook: adding a scenario / a step
 
-1. **Écrire le `.feature`** : `src/modules/{module}/features/us-N-slug.feature`, `# language: fr`, tag de tête `@CATEGORIE @priority-N`, et un tag de couche par scénario (`@ui` / `@data` / `@e2e`). Mots-clés FR : `Fonctionnalité`, `Contexte` (Background), `Scénario`, `Étant donné`/`Quand`/`Alors`. Tagger `@wip` un scénario dont les steps ne sont pas encore écrits.
+1. **Write the `.feature`**: `src/modules/{module}/features/us-N-slug.feature`, `# language: fr`, a header tag `@CATEGORIE @priority-N`, and one layer tag per scenario (`@ui` / `@data` / `@e2e`). French keywords: `Fonctionnalité`, `Contexte` (Background), `Scénario`, `Étant donné`/`Quand`/`Alors`. Tag `@wip` any scenario whose steps are not written yet.
 
-2. **Choisir la couche** (cf. [[rule_test-layer-contracts]]) : assertion de rendu → `@ui` ; mutation/persistance → `@data` ; parcours complet → `@e2e`.
+2. **Pick the layer** (see [[rule_test-layer-contracts]]): rendering assertion → `@ui`; mutation/persistence → `@data`; full journey → `@e2e`.
 
-3. **Écrire les steps** dans `src/modules/{module}/steps/{ui,data,e2e}/*.steps.ts` (ou `src/shared/steps/ui/` si cross-domaine). Signature : `async function (this: FestipodWorld, …)`. Importer `FestipodWorld` depuis `../../../../shared/support/world` (ajuster le chemin relatif).
+3. **Write the steps** in `src/modules/{module}/steps/{ui,data,e2e}/*.steps.ts` (or `src/shared/steps/ui/` if cross-domain). Signature: `async function (this: FestipodWorld, …)`. Import `FestipodWorld` from `../../../../shared/support/world` (adjust the relative path).
 
-4. **Accès aux données selon la couche** :
-   - `@ui` : `this.renderedDoc` / `this.getDomText()` / `this.hasText(...)` après `navigateTo(...)` (voir [[knowledge_ui-layer]]).
-   - `@data`/`@e2e` : `await this.appFrame!.evaluate(fn, ...args)` sur le bridge `window.__testData` (voir [[knowledge_data-layer-broker]]).
+4. **Data access, per layer**:
+   - `@ui`: `this.renderedDoc` / `this.getDomText()` / `this.hasText(...)` after `navigateTo(...)` (see [[knowledge_ui-layer]]).
+   - `@data`/`@e2e`: `await this.appFrame!.evaluate(fn, ...args)` on the `window.__testData` bridge (see [[knowledge_data-layer-broker]]).
 
-5. **⚠️ Piège de sérialisation `appFrame.evaluate`** : la fonction passée s'exécute **dans l'iframe**, les variables du step **ne sont pas capturées** (closures perdues). **Passer toute valeur en argument** :
+5. **⚠️ `appFrame.evaluate` serialization pitfall**: the function you pass runs **inside the iframe**, and the step's variables **are not captured** (closures are lost). **Pass every value as an argument**:
    ```ts
-   // ❌ const title = eventTitle; await appFrame.evaluate(() => td.getEventByTitle(title)) // title undefined
+   // ❌ const title = eventTitle; await appFrame.evaluate(() => td.getEventByTitle(title)) // title is undefined
    // ✅ await appFrame.evaluate((t) => td.getEventByTitle(t), eventTitle)
    ```
-   Toujours `await` (oublier → assertion avant résolution).
+   Always `await` (forgetting it means asserting before the promise resolves).
 
-6. **Si tu ajoutes une opération de données** : exposer le helper sur `window.__testData` dans **les deux** harness (`src/shared/test-harness/harness.tsx` ET `harness-ng.tsx`) — sinon le fallback mock diverge du broker réel.
+6. **If you add a data operation**: expose the helper on `window.__testData` in **both** harnesses (`src/shared/test-harness/harness.tsx` AND `harness-ng.tsx`) — otherwise the mock fallback drifts away from the real broker.
 
-7. **Câbler un écran testé** : si le nom français de l'écran ne se résout pas vers son `id`, ajouter un alias dans `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`).
+7. **Wire up a screen under test**: if the French screen name does not resolve to its `id`, add an alias in `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`).
 
-8. **Lancer** : `bun run test:cucumber` (tout) ou `bun run test:data` (@data). Rapport : `reports/cucumber-report.html`. Le `@data`/`@e2e` exige le wallet de test (`bun run test:auth-setup` au premier coup si besoin, sinon création auto — cf. [[decision_2026-03-12_headless-wallet-creation]]).
+8. **Run**: `bun run test:cucumber` (everything) or `bun run test:data` (@data). Report: `reports/cucumber-report.html`. `@data`/`@e2e` require the test wallet (`bun run test:auth-setup` on the first go if needed, otherwise it is created automatically — see [[decision_2026-03-12_headless-wallet-creation]]).

.project/concepts/bdd-testing/decision_2026-03-12_headless-wallet-creation.md

@@ -1,6 +1,6 @@
 ---
 type: decision
-summary: Décision 2026-03-12 — créer le wallet de test en automatisant l'UI broker headless (Playwright) plutôt que par API NG, car ça teste le vrai flux d'auth et évite de reverse-engineer l'API d'inscription
+summary: Decision 2026-03-12 — create the test wallet by automating the broker UI headlessly (Playwright) rather than through the NG API, because it exercises the real auth flow and avoids reverse-engineering the sign-up API
 ---
 
 # Automated Headless Wallet Creation for CI
@@ -10,28 +10,28 @@ summary: Décision 2026-03-12 — créer le wallet de test en automatisant l'UI
 
 ## Context
 
-Les tests `@data` exigent un wallet NextGraph dans un profil Chromium persistant. Avant, le premier run exigeait une interaction manuelle (navigateur visible, création de wallet à la main) → bloquait le CI.
+`@data` tests require a NextGraph wallet inside a persistent Chromium profile. Previously, the first run required manual interaction (visible browser, wallet created by hand) → CI was blocked.
 
 ## Options Considered
 
-### Option A: création programmatique du wallet via SDK NG
-Appeler `ng.wallet_create()` depuis Node/Bun, sans UI.
-- **Pour** : plus rapide, pas de navigateur.
-- **Contre** : `@ng-org/web` est browser-only (WASM + postMessage) ; il faudrait reverse-engineer l'API d'inscription d'`account.nextgraph.eu` ; ne teste pas le vrai flux d'auth.
+### Option A: create the wallet programmatically through the NG SDK
+Call `ng.wallet_create()` from Node/Bun, without any UI.
+- **Pros**: faster, no browser needed.
+- **Cons**: `@ng-org/web` is browser-only (WASM + postMessage); we would have to reverse-engineer the sign-up API of `account.nextgraph.eu`; it does not exercise the real auth flow.
 
-### Option B: automatiser le flux UI headless
-Piloter via Playwright la même UI de création de wallet, en headless.
-- **Pour** : teste le vrai flux auth/login de bout en bout ; pas de reverse-engineering ; même profil persistant réutilisé ; CI-ready sans étape manuelle.
-- **Contre** : dépend de `nextgraph.eu`/`account.nextgraph.eu` joignables ; fragile aux changements d'UI NextGraph ; +~27s au premier run.
+### Option B: automate the UI flow headlessly
+Drive the very same wallet-creation UI with Playwright, in headless mode.
+- **Pros**: exercises the real auth/login flow end to end; no reverse-engineering; the same persistent profile is reused; CI-ready with no manual step.
+- **Cons**: depends on `nextgraph.eu`/`account.nextgraph.eu` being reachable; brittle to NextGraph UI changes; adds ~27s to the first run.
 
 ## Decision
 
-**Option B** — automatiser l'UI broker. Le flux de création (navigate → Create Wallet → ToS → username/password → submit) est lui-même un test légitime de la feature d'auth. La dépendance aux services externes est acceptable puisque les tests dépendent déjà du broker joignable.
+**Option B** — automate the broker UI. The creation flow (navigate → Create Wallet → ToS → username/password → submit) is itself a legitimate test of the auth feature. Depending on external services is acceptable since the tests already depend on the broker being reachable.
 
 ## Consequences
 
-**Positif :** tests pleinement CI-ready (zéro interaction) ; flux auth testé en passant ; `bun run test:data` part d'un état propre.
-**Négatif :** exige un accès internet (nextgraph.eu, account.nextgraph.eu) ; fragile aux changements d'UI NextGraph (textes de boutons, IDs de formulaire).
-**Risque :** rate-limiting d'`account.nextgraph.eu` si le CI recrée souvent des wallets.
+**Positive:** fully CI-ready tests (zero interaction); the auth flow gets tested along the way; `bun run test:data` starts from a clean state.
+**Negative:** requires internet access (nextgraph.eu, account.nextgraph.eu); brittle to NextGraph UI changes (button texts, form IDs).
+**Risk:** rate-limiting from `account.nextgraph.eu` if CI recreates wallets often.
 
-> Mécanique de cycle de vie détaillée : [[knowledge_data-layer-broker]].
+> Detailed lifecycle mechanics: [[knowledge_data-layer-broker]].

.project/concepts/bdd-testing/knowledge_cucumber-setup.md

@@ -1,46 +1,46 @@
 ---
 type: knowledge
-summary: Config Cucumber (cucumber.json, langue fr, loader tsx), layout des features/steps colocalisés par module, steps partagés dans shared/steps/, et les scripts qui génèrent features.ts/testResults.ts/stepDefinitions.ts
+summary: Cucumber config (cucumber.json, fr language, tsx loader), layout of features/steps colocated per module, shared steps under shared/steps/, and the scripts that generate features.ts/testResults.ts/stepDefinitions.ts
 ---
 
-# Setup Cucumber
+# Cucumber setup
 
-26 fichiers `.feature` (US-1 à US-26), tous en **français**, taggés `@CATEGORIE @priority-N` (catégories EVENT, WORKSHOP, USER, MEETING, NOTIF).
+26 `.feature` files (US-1 to US-26), all in **French**, tagged `@CATEGORIE @priority-N` (categories EVENT, WORKSHOP, USER, MEETING, NOTIF).
 
 ## Layout
 
-Features et steps **colocalisés avec leur module** :
+Features and steps are **colocated with their module**:
 
 ```
 src/modules/event/features/us-13-creer-evenement.feature
 src/modules/event/steps/{ui,data,e2e}/
 ```
 
-Steps **partagés** (cross-domaine) dans `src/shared/steps/ui/` :
-- `navigation.steps.ts` — navigation, auth, clics/sélections, assertions section/bouton/champ
-- `form.steps.ts` — validation de champs, champs requis, import/duplicate
-- `screen.steps.ts` — contenu d'écran (participants, events, profils, QR)
+**Shared** (cross-domain) steps live in `src/shared/steps/ui/`:
+- `navigation.steps.ts` — navigation, auth, clicks/selections, section/button/field assertions
+- `form.steps.ts` — field validation, required fields, import/duplicate
+- `screen.steps.ts` — screen content (participants, events, profiles, QR)
 
-Les noms français des écrans (`"accueil"`, `"détail événement"`, `"mon profil"`…) mappent vers les IDs d'écran via `screenNameMap`.
+The French screen names (`"accueil"`, `"détail événement"`, `"mon profil"`…) map to screen IDs through `screenNameMap`.
 
-Tags de scénario : `@ui` / `@data` / `@e2e` (couche) + **`@wip`** pour un scénario dont les steps ne sont pas encore implémentés. Un `Contexte` (Background) fréquent — « Étant donné que je suis connecté » — ne fait que poser un flag `isAuthenticated`, pas d'auth réelle en `@ui`.
+Scenario tags: `@ui` / `@data` / `@e2e` (layer) plus **`@wip`** for a scenario whose steps are not implemented yet **or whose application behaviour is not reliable yet** (intended use: flagging a genuine expectation that fails because of a product bug, not marking an obsolete test — historical example: sign-up cancellation not being reflected in the UI, `@wip` **lifted** once it was fixed in T02.c, see [[caveat_participation-deletion]]). **`@wip` is EXCLUDED from the default run** (`cucumber.json: "tags": "not @wip"`): those scenarios document an expectation without breaking the suite; drop the `@wip` once they are reliable. A common `Contexte` (Background) — « Étant donné que je suis connecté » — merely sets an `isAuthenticated` flag, there is no real auth in `@ui`.
 
 ## Config
 
-`cucumber.json` : `import` de `src/shared/support/**`, `src/shared/steps/**`, `src/modules/*/steps/**` ; `paths` = `src/modules/*/features/**`; `language: fr`. **Runner = Node + tsx** (`node --import tsx/esm node_modules/.bin/cucumber-js`), pas Bun — les plugins (Playwright, happy-dom) ne chargent pas en import Bun natif. Ne pas « bunifier » `cucumber:run`/`test:data`.
+`cucumber.json`: `import` of `src/shared/support/**`, `src/shared/steps/**`, `src/modules/*/steps/**`; `paths` = `src/modules/*/features/**`; `tags: "not @wip"` (excludes WIP scenarios); `language: fr`. **Runner = Node + tsx**, not Bun — the plugins (Playwright, happy-dom) do not load under a native Bun import. Do not "bunify" `cucumber:run`/`test:data`. ⚠️ The runner must point at the package's **actual JS entry** (`node_modules/@cucumber/cucumber/bin/cucumber.js`), **never** at `node_modules/.bin/cucumber-js`: depending on the installer, `.bin/` holds a **shell shim** (not JS) that `node --import tsx/esm` cannot execute.
 
-## Le harness de test est buildé à la demande
+## The test harness is built on demand
 
-Les harness `@data`/`@e2e` (`src/shared/test-harness/harness.tsx`, `harness-ng.tsx`) **ne sont pas** buildés par `build.ts`. Le `BeforeAll` de `hooks.ts` les compile **à la demande** (`bun build` → `dist/test-harness*.js`). Le wallet de test peut être créé d'avance via `bun run test:auth-setup` (`scripts/setup-test-auth.ts`), sinon il est créé automatiquement au premier run (cf. [[decision_2026-03-12_headless-wallet-creation]]).
+The `@data`/`@e2e` harnesses (`src/shared/test-harness/harness.tsx`, `harness-ng.tsx`) are **not** built by `build.ts`. The `BeforeAll` hook in `hooks.ts` compiles them **on demand** (`bun build` → `dist/test-harness*.js`). The test wallet can be created ahead of time with `bun run test:auth-setup` (`scripts/setup-test-auth.ts`); otherwise it is created automatically on the first run (see [[decision_2026-03-12_headless-wallet-creation]]).
 
-## Fichiers auto-générés
+## Auto-generated files
 
-Des scripts `scripts/` parsent features/steps en data TS consommée par l'outil de parcours :
+Scripts under `scripts/` parse features and steps into TS data consumed by the browsing tool:
 
-| Script | Entrée | Sortie |
+| Script | Input | Output |
 |---|---|---|
 | `parse-features.ts` | `*/features/*.feature` | `src/shared/data/features.ts` |
 | `parse-test-results.ts` | `reports/cucumber-report.json` | `src/shared/data/testResults.ts` |
 | `extract-step-definitions.ts` | `shared/steps/ui/*.ts` | `src/shared/data/stepDefinitions.ts` |
 
-Lancer : `bun run test:cucumber` (tout), `bun run test:data` (@data). Après ajout de steps : `bun run steps:extract`.
+Run: `bun run test:cucumber` (everything), `bun run test:data` (@data). After adding steps: `bun run steps:extract`.

.project/concepts/bdd-testing/knowledge_data-layer-broker.md

@@ -1,36 +1,42 @@
 ---
 type: knowledge
-summary: Couche @data — Playwright pilote Chromium (profil persistant) qui s'authentifie au broker NextGraph réel chargeant harness-ng.tsx en iframe ; cycle de vie wallet automatisé (création + login bootstrap), bridge window.__testData, fallback mock
+summary: The @data layer — Playwright drives Chromium (persistent profile) into the real broker, which loads harness-ng.tsx in an iframe; automated wallet lifecycle, window.__testData bridge, mock fallback; the harness signs in exactly as the app does, and per-scenario isolation is currently ABSENT
+last_checked: 2026-08-10
 ---
 
-# Couche `@data` (broker réel)
+# The `@data` layer (real broker)
 
-`@data` teste le **vrai pipeline NextGraph** via un broker, pas des données mockées.
+`@data` exercises the **real NextGraph pipeline** through a broker, not mocked data.
 
 ## Architecture
 
 ```
-Cucumber → Playwright (Chromium, profil persistant)
-  → broker wallet login (automatisé)
-  → broker charge le harness en iframe (http://127.0.0.1:{port})
+Cucumber → Playwright (Chromium, persistent profile)
+  → broker wallet login (automated)
+  → broker loads the harness in an iframe (http://127.0.0.1:{port})
   → harness-ng.tsx (init → useShape → ORM → broker)
-  → bridge window.__testData
+  → window.__testData bridge
 ```
 
-**Dual mode** : broker réel (`harness-ng.tsx`, défaut) ou fallback mock (`harness.tsx`, DeepSignalSets standalone si le build NG échoue).
+**Dual mode**: real broker (`harness-ng.tsx`, the default) or mock fallback (`harness.tsx`, standalone DeepSignalSets if the NG build fails).
 
-## Cycle de vie du wallet (automatisé, CI-ready)
+## Wallet lifecycle (automated, CI-ready)
 
-- **Premier run** : pas de marker `.wallet-ready` → Chromium headless crée le wallet (`nextgraph.eu` → Create Wallet → ToS sur `account.nextgraph.eu` → username/password → submit), **puis se logge** — ce login déclenche le bootstrap du verifier depuis le broker distant (peuple `self.repos`, sauvé en localStorage). **Sans ce login initial, toutes les écritures échoueraient en `RepoNotFound`.** Marker écrit.
-- **Runs suivants** : marker trouvé → login automatisé (click Login → wallet → password → submit) → harness en iframe → `window.__testData.ready`.
-- Credentials wallet : `festipod-tests` / `festipod-tests`.
+- **First run**: no `.wallet-ready` marker → headless Chromium creates the wallet (`nextgraph.eu` → Create Wallet → ToS on `account.nextgraph.eu` → username/password → submit), **then logs in** — that initial login is required to bootstrap the session (saved in localStorage); without it, writes would not go through. Marker written.
+- **Subsequent runs**: marker found → automated login (click Login → wallet → password → submit) → harness in the iframe → `window.__testData.ready`.
+- Wallet credentials: `festipod-tests` / `festipod-tests`.
 
-> Le choix « automatiser l'UI headless plutôt que créer le wallet par API » est tranché dans [[decision_2026-03-12_headless-wallet-creation]].
+> The choice of "automating the headless UI rather than creating the wallet through an API" is settled in [[decision_2026-03-12_headless-wallet-creation]].
 
-## Détails techniques
+## Technical details
 
-- **Flags Chromium** (`--disable-web-security`, `--allow-insecure-localhost`, désactivation de Private Network Access) : nécessaires car le broker public charge un harness `http://127.0.0.1` en iframe.
-- **Profil persistant** `.playwright-profile/` (gitignored, wallet en localStorage) — exige le vrai binaire Chrome, pas `chrome-headless-shell`.
-- **Serveur HTTP** lancé en `BeforeAll` (port auto), sert le HTML + `/harness.js` (fichiers séparés — le script inline casse à cause de caractères spéciaux du bundle).
-- **Subscriptions ORM** : les 3 shapes avec scope `did:ng:${session.private_store_id}` (cf. concept `data-layer`).
-- **Bridge `window.__testData`** : `events`/`users`/`participations` (sets live), `currentUserId`, lookups (`getEvent`, `getEventByTitle`), mutations (`joinEvent`, `leaveEvent`, `updateEvent`), requêtes (`isParticipating`, `getEventParticipants`).
+- **Chromium flags** (`--disable-web-security`, `--allow-insecure-localhost`, Private Network Access turned off): necessary because the public broker loads a `http://127.0.0.1` harness in an iframe.
+- **Persistent profile** `.playwright-profile/` (gitignored, wallet in localStorage) — requires the real Chrome binary, not `chrome-headless-shell`.
+- **HTTP server** started in `BeforeAll` (auto-assigned port), serving the HTML plus `/harness.js` (separate files — an inline script breaks because of special characters in the bundle).
+- **The bridge is the real app path (per entity).** Since the move to *one document per entity* (concept `data-layer`, [[rule_document-per-entity]]), the `window.__testData` bridge (`events`/`users`/`participations`, `joinEvent`/`leaveEvent`/`isParticipating`/`getEventParticipants`, `loadTestData`) **delegates to the app's data context** (`appData` through `FestipodDataProvider`) — this is the real per-entity path the screens use, not a read at root-store level. It reads `appData` through a **live ref** (a captured snapshot goes stale after a seed re-render).
+- **The harness signs in exactly as the app does.** It mounts `NextGraphProvider > FestipodDataProvider` — **no identity provider, no default login** — and awaits the single `ensureIdentity()` before exposing the bridge, mirroring the order `AuthGate` imposes (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]). Nothing may read before it resolves. The low-level probes that used to reach past the app path are **gone**, along with the scenarios whose subject was the SDK rather than Festipod ([[rule_tests-validate-festipod-not-the-sdk]]).
+- **Identity before writing.** A `Participation` has a mandatory `fp:user`; the current user is **the profile document read back in the protected scope**, so it lags behind the public events. Steps wait for `ensureCurrentUser()` before `joinEvent` (otherwise the mutation refuses, or writes a participation with no user → dropped on read) and then wait (`waitForFunction`) for the participation to be read back.
+- **Per-scenario isolation is currently ABSENT — read [[caveat_data-scenarios-share-one-wallet]] before trusting a green run.** The `Before` hook still mints `this.freshIdentifier` and injects it into `localStorage['festipod.account.identifier']`, and several steps re-inject it, but **nothing reads that key any more**: no published call takes an identifier. Every scenario therefore runs as the same identity on one accumulating wallet. That machinery is inert, not load-bearing — do not build new setup on it, and do not "repair" it by making the app honour the key again.
+  - The old per-scenario reset (`resetDataState()`, a SPARQL DELETE on the anchor graph) was dropped for cost (up to 10 s of the `Before` hook's 60 s budget, already eaten by the broker login) and its helper is gone too.
+  - The **physical** growth of the shared wallet was never bounded by any of this — see [[caveat_wallet-bloat-hang]] (profile to be moved aside when reads start to hang).
+  - The connected seed stays **lightweight** (few docs): creating a document is a serial round trip, so the seed's cost is linear in the number of documents it writes.

.project/concepts/bdd-testing/knowledge_e2e-layer.md

@@ -1,47 +1,76 @@
 ---
 type: knowledge
-summary: Couche @e2e — Playwright boote l'app RÉELLE (pas un harness) dans l'iframe broker, interagit via appFrame.evaluate()/locator(), réutilise setupBrokerPage() de @data ; teste navigation/redirects/clics, pas de fallback mock
+summary: The @e2e layer — Playwright boots the REAL app inside the broker iframe, driven through appFrame.evaluate()/locator(); no mock fallback; there is no more access-gate-disable flag, and no scenario has had to drive the SDK's own barrier because the persistent profile comes up already signed in
+last_checked: 2026-08-10
 ---
 
-# Couche `@e2e` (app réelle)
+# The `@e2e` layer (real app)
 
-`@e2e` teste l'**UI de l'app réelle** tournant dans l'iframe broker — contrairement à `@data` qui charge un harness de test.
+`@e2e` tests the **UI of the real app** running inside the broker iframe — unlike `@data`, which loads a test harness.
 
 ## Architecture
 
 ```
-Cucumber → Playwright (Chromium, profil persistant)
+Cucumber → Playwright (Chromium, persistent profile)
   → https://nextgraph.net/redir/#/?o=http://127.0.0.1:{appPort}
-  → login broker (automatisé, même mécanique que @data)
-  → broker charge la VRAIE APP en iframe
-  → app rend avec NextGraphProvider auto-connectant
-  → steps via appFrame.evaluate() + locators Playwright
+  → broker login (automated, same machinery as @data)
+  → broker loads the REAL APP in an iframe
+  → app renders with a self-connecting NextGraphProvider
+  → steps through appFrame.evaluate() + Playwright locators
 ```
 
-**Serveur app** : lancé en `BeforeAll` (`spawn('bun', ['src/index.ts'], { env: { PORT } })`, poll jusqu'à réponse HTTP, tué en `AfterAll`). Réutilise le helper `setupBrokerPage()` de `@data` (redirect, login, découverte de l'iframe).
+**App server**: started in `BeforeAll` (`spawn('bun', ['src/index.ts'], { env: { PORT } })`, polled until it answers over HTTP, killed in `AfterAll`). It reuses the `setupBrokerPage()` helper from `@data` (redirect, login, iframe discovery).
 
 ## Step definitions
 
-Dans les modules (ex. `src/modules/auth/steps/e2e/connexion.steps.ts`) :
-- `this.appFrame!.evaluate()` — JS dans l'iframe app (navigation hash/path, checks de contenu)
-- `this.appFrame!.locator()` — éléments DOM
-- `this.appFrame!.waitForFunction()` — poll d'état attendu
-- `SCREEN_MARKERS` — map ID d'écran → texte unique de vérification
+Inside the modules (e.g. `src/modules/auth/steps/e2e/connexion.steps.ts`):
+- `this.appFrame!.evaluate()` — JS inside the app iframe (hash/path navigation, content checks)
+- `this.appFrame!.locator()` — DOM elements
+- `this.appFrame!.waitForFunction()` — poll for an expected state
+- `SCREEN_MARKERS` — map from screen ID to a unique verification text
 
-Navigation : `window.history.pushState` + dispatch `popstate` (routing path-based, cf. `app-architecture`).
+Navigation: `window.history.pushState` plus a `popstate` dispatch (path-based routing, see `app-architecture`).
 
-## Différences avec `@data`
+## Differences from `@data`
 
 | Aspect | `@data` | `@e2e` |
 |---|---|---|
-| Chargé en iframe | harness (`harness-ng.tsx`) | app réelle (`src/index.ts`) |
-| Signal ready | `window.__testData.ready` | `root.innerHTML.length > 100` |
-| Interaction | bridge `evaluate()` | `evaluate()` + locators |
-| Fallback mock | oui | **non** (broker réel requis) |
-| Teste | opérations données | comportement UI (nav, redirects, clics) |
+| Loaded in the iframe | harness (`harness-ng.tsx`) | real app (`src/index.ts`) |
+| Ready signal | `window.__testData.ready` | `root.innerHTML.length > 100` |
+| Interaction | `evaluate()` bridge | `evaluate()` + locators |
+| Mock fallback | yes | **no** (real broker required) |
+| Tests | data operations | UI behaviour (nav, redirects, clicks) |
 
-> **Ne pas re-vérifier en `@e2e` ce que `@ui` couvre déjà** — `@e2e` doit casser quand la *collaboration* entre couches casse, pas quand une icône change (cf. [[rule_test-layer-contracts]]).
+> **Do not re-check in `@e2e` what `@ui` already covers** — `@e2e` must break when the *collaboration* between layers breaks, not when an icon changes (see [[rule_test-layer-contracts]]).
 
-## Fichiers clés
+## Scenario identity, and why no scenario drives the SDK's barrier
 
-`src/shared/support/hooks.ts` (lifecycle Playwright), `world.ts` (champs `page`/`appFrame`), `scripts/debug-browser.ts` (debug headed), `.playwright-profile{,-debug}/` (gitignored).
+The `Before` hook still plants `this.freshIdentifier` — a unique identifier minted per scenario (`freshScenarioIdentifier`) and injected via `addInitScript` into `localStorage['festipod.account.identifier']` on the **persistent** context. **Nothing consumes it**: no published call takes an identifier, so a scenario cannot choose who it opens as. Treat it as inert machinery, not as a determinism lever — [[caveat_data-scenarios-share-one-wallet]].
+
+**There is no more access-gate-disable flag.** `AccessGateScreen` and the `__FESTIPOD_ACCESS_GATE_DISABLED__` global it used to check are both gone. What keeps every `@e2e` scenario from having to drive the SDK's barrier is simply that the **persistent profile already carries an open wallet session** — the automated broker login in the shared `@data`/`@e2e` setup put it there. **Fresh** contexts (multi-browser, see [[knowledge_multibrowser-harness]]) carry no such session, but no scenario left loads the real app through a fresh context — and none could assert against that barrier anyway ([[caveat_first-time-entry-untested]]).
+
+> **Impact:** any page opened by hand inside a step (`ctx.newPage()`) does **not** inherit page-level init scripts — `addInitScript` applies only to the pages of the context it was called on.
+
+## The "close and reopen" idiom (reconnection scenarios)
+
+`reconnexion-persistance-e2e.feature` / `src/modules/event/steps/e2e/reconnexion-persistance.steps.ts` reproduce the "I create, I close, I come back" journey inside the REAL app:
+
+1. **Creation through the real form** — the step drives the actual creation wizard at DOM level (3-step wizard, selection by *placeholder*: event name, venue; submit button by its label). ⚠️ **These steps are coupled to the French labels of the creation screen**: renaming a placeholder or the submit button breaks the scenario, not the app.
+2. **Reopening** — a second page on the **same** persistent context, replanting `this.freshIdentifier` on it (page-level `addInitScript` only covers the page it is called on), then `pool.setupBrokerPage(page, pool.appUrl!)` → new broker login, same identity.
+3. **Proof** — the step captures the console of **both** pages and publishes a summary through `this.attach` (Cucumber attachment) plus stdout; a raw dump of the connection/sync lines is **opt-in** through the `RECO_RAW_DUMP=1` environment variable (noisy, off by default).
+
+> **Limitation to know about**: this setup proves the reconnection *of the journey*, **not** the broker durability of the write — the second page shares the IndexedDB of the persistent profile. See [[caveat_reconnexion-froide-local-vs-broker]] for the setup that does settle broker-vs-local.
+
+The scenario is **`@wip`** (diagnostic instrument, excluded from the default run).
+
+## `@smoke` — guarding the "blank page once connected" class
+
+`@e2e @smoke` (`src/modules/home/features/accueil-connecte-rend.feature`) guards a CLASS of regression: a rendering crash that happens ONLY once the app is connected and mounted on real data (symptom: only the broker iframe banner shows, `#root` stays empty). The smoke test reuses the boot from the @e2e `Before` hook, navigates to the connected home screen and asserts TWO things:
+1. **HomeScreen really mounted** — presence of strong markers (`.app-navbar` plus the `[aria-label="Relayer un événement"]` button), absent from a spinner or from the broker banner. A `throw` inside a component/provider mounted after connection unmounts the tree (there is no `ErrorBoundary`) → those markers disappear → red.
+2. **Zero runtime errors** — `this.pageErrors` (see below) must be empty.
+
+The @e2e `Before` hook now **collects** the app page's `pageerror` and `console.error` events into the World (field `pageErrors`, reset per scenario) — that is what makes the "no error" assertion possible. The default run of `bun run validate` executes `@smoke and not @wip` (not all of `@e2e`, to stay fast). **Detection proof**: a `throw` at the top of `HomeScreen` turns the smoke test red; without it, green.
+
+## Key files
+
+`src/shared/support/hooks.ts` (Playwright lifecycle + `pageErrors` collection), `world.ts` (fields `page`/`appFrame`/`pageErrors`), `scripts/debug-browser.ts` (headed debugging), `.playwright-profile{,-debug}/` (gitignored).

.project/concepts/bdd-testing/knowledge_multibrowser-harness.md

@@ -1,71 +1,63 @@
 ---
 type: knowledge
-summary: Harness multi-navigateur sur DEUX axes orthogonaux — nombre de navigateurs (machinerie, contextes frais isolés via un freshBrowser non-persistant) ET modèle de wallet (own/@private-wallet vs shared/@shared-wallet) ; shared provisionné par injection storageState (test) ; e2e @humain qui valide le mécanisme produit RÉEL via la vraie app staging (fichier .ngw téléchargé depuis l'écran → import nextgraph.eu « Import a Wallet File » → Entrer → connecté) ; convention @wip exclue via cucumber.json
-last_checked: 2026-06-16
+summary: Multi-browser harness — isolated contexts spawned from a non-persistent freshBrowser, all carrying the shared wallet by storageState injection (test-only); the scenario that once drove the real access screen end to end is gone with the screen, and nothing replaces it
+last_checked: 2026-08-10
 ---
 
-# Harness multi-navigateur (private-wallet vs shared-wallet)
+# Multi-browser harness (shared wallet)
 
-Capacité du harness `@data`/`@e2e` à piloter **plusieurs navigateurs isolés** dans un même scénario, sous **deux axes orthogonaux**. Sert à tester le stopgap wallet partagé (cf. concept `nextgraph-platform` → `brief_2026-06-15_shared-wallet-shim`) **et** le modèle cible (chacun son wallet).
+The ability of the `@data`/`@e2e` harness to drive **several isolated browsers** within a single scenario. This is also the **only** way multi-user is exercised now: each browser context signs in **as itself**, since nothing lets a single page hold two identities ([[rule_tests-validate-festipod-not-the-sdk]]). That capability is not yet fully used: `isolation-deux-identites.feature` needs exactly this — two real contexts, each connecting for itself — and is currently `@wip` because it still assumes the old single-page identity switch (product-level statement of the gap: concept `functional-domain` → [[knowledge_roadmap]]).
 
-## Les deux axes (orthogonaux)
-
-| Axe | Ce qu'il décide | Exprimé par |
+| Concern | What it decides | Expressed by |
 |---|---|---|
-| **Nombre de navigateurs** (machinerie) | 1..N contextes nommés isolés | `openBrowser(name, …)` + steps `… dans le navigateur "X"` |
-| **Modèle de wallet** | identité NG distincte vs partagée | **phrasing du step + tag** (voir ci-dessous) |
+| **Number of browsers** (machinery) | 1..N isolated named contexts | `openBrowser(name, …)` + steps `… dans le navigateur "X"` |
+| **Wallet model** | which wallet a context carries | the `WalletModel` argument (`'own'` \| `'shared'`) |
 
-Ne **pas** confondre `@multibrowser` (plusieurs navigateurs) avec `@shared-wallet` (même wallet) : on fait du multibrowser **en private** (utile dès que NextGraph livrera la lecture cross-wallet — le modèle cible) **et en shared** (stopgap), et on compare les deux setups avec les **mêmes** steps de comportement.
+## Wallet model — one is exercised, one is dormant
 
-## Modèle de wallet : phrasing + tags
+- `Étant donné un navigateur "A" avec le wallet partagé` → **shared** model, tag `@shared-wallet`. This is what every scenario uses.
+- The **own-wallet** model (`'own'`, an empty partition with no wallet) still exists in `spawnContext`, but **no scenario exercises it**: the two `@private-wallet` scenarios were **deleted** because what they proved — Playwright's storage partitioning — is a property of the tooling, not a Festipod behaviour. Keep the machinery, do not re-add scenarios whose subject is the isolation of the tooling.
+- Umbrella tag `@multibrowser` (whole feature).
 
-- `Étant donné un navigateur "A" avec son propre wallet` → modèle **own**, tag `@private-wallet`.
-- `Étant donné un navigateur "A" avec le wallet partagé` → modèle **shared**, tag `@shared-wallet`.
-- Tag umbrella `@multibrowser` (feature entière).
+## Architecture (where things live)
 
-## Architecture (où vit quoi)
+- **`src/shared/support/browserPool.ts`** — shared state + factory. Outside the **persistent** Chromium context that carries the shared wallet (legacy single-browser `@data`/`@e2e`, **unchanged**, see [[knowledge_data-layer-broker]]), the harness launches a **non-persistent** browser `freshBrowser` (`chromium.launch`) which mints fresh isolated contexts on demand (`spawnContext(wallet)`). The module is imported by `hooks.ts` (lifecycle) and `world.ts` (per-scenario use) — no import cycle.
+- **`world.ts`** — API: `openBrowser(name, wallet)`, `browser(name)`, `loadAppInBrowser(name, 'app'|'harness')`, `closeBrowsers()`; registry `browsers: Map<name, NamedBrowser>`. Named browsers are closed in `After`, `freshBrowser` in `AfterAll`.
+- **`hooks.ts`** — a scenario tagged `@multibrowser` **does not get** the legacy single page; the steps open the browsers themselves. Requires the real broker mode (`freshBrowser` is unavailable in the mock fallback).
 
-- **`src/shared/support/browserPool.ts`** — état partagé + fabrique. Hors du contexte Chromium **persistant** porteur du wallet partagé (legacy mono-navigateur `@data`/`@e2e`, **inchangé**, cf. [[knowledge_data-layer-broker]]), le harness lance un navigateur **non-persistant** `freshBrowser` (`chromium.launch`) qui mint des contextes frais et isolés à la demande (`spawnContext(wallet)`). Module importé par `hooks.ts` (cycle de vie) et `world.ts` (usage par scénario) — pas de cycle d'import.
-- **`world.ts`** — API : `openBrowser(name, wallet)`, `browser(name)`, `loadAppInBrowser(name, 'app'|'harness')`, `closeBrowsers()` ; registre `browsers: Map<name, NamedBrowser>`. Navigateurs nommés fermés en `After`, `freshBrowser` en `AfterAll`.
-- **`hooks.ts`** — un scénario taggé `@multibrowser` **ne reçoit pas** la page unique legacy ; les steps ouvrent les navigateurs. Exige le mode broker réel (`freshBrowser` indispo en fallback mock).
+## Wallet provisioning
 
-## Provisioning du wallet
+- **own**: empty `newContext()` → distinct NG identity / no wallet.
+- **shared**: `newContext({ storageState })`, where `storageState` is **captured once** at `BeforeAll` from the persistent profile (warm-up through `setupBrokerPage`, then `browserContext.storageState()`), exposed as `pool.sharedWalletState`. **Empirically verified (2026-06-16)**: the `nextgraph.eu` and `nextgraph.net` origins round-trip into the fresh contexts, and two **shared** browsers both reach the app **connected** to NextGraph (`window.__testData.ready`) **without any manual login**.
 
-- **own** : `newContext()` vide → identité NG distincte / pas de wallet.
-- **shared** : `newContext({ storageState })`, où `storageState` est **capturé une fois** au `BeforeAll` depuis le profil persistant (warm-up via `setupBrokerPage` puis `browserContext.storageState()`), exposé par `pool.sharedWalletState`. **Vérifié empiriquement (2026-06-16)** : les origines `nextgraph.eu` + `nextgraph.net` round-trippent dans les contextes frais, et deux navigateurs **shared** atteignent tous deux l'app **connectée** à NextGraph (`window.__testData.ready`) **sans login manuel**.
+> This provisioning is **test-only** — distinct from the **product** mechanism (FILE-assisted import). The shared-wallet scenario using storageState **bypasses the import**, and nothing left validates that import end to end: see [[caveat_first-time-entry-untested]] (concept `bdd-testing`).
 
-> Ce provisioning est **de test** — distinct du mécanisme **produit** (import assisté par FICHIER). Le scénario shared-wallet par storageState **court-circuite l'import** ; pour valider le mécanisme RÉEL, voir l'e2e `@humain` ci-dessous.
+## No scenario left drives the real app through a fresh context
 
-## Parcours humain — e2e du mécanisme produit (vert)
+There used to be a `@humain` scenario here that drove `AccessGateScreen` end to end on a fresh context: download the wallet file from the screen, import it on `nextgraph.eu`, come back, type an identifier, land connected. `AccessGateScreen`, its testids (`shared-wallet-download`, `shared-wallet-password`, `identifier-input`), and every helper built only for that scenario (`pool.ensureStagingApp`, `pool.importWalletViaFile`, `findE2eWalletFile`, the `dist-staging` build) are **deleted** along with the screen itself (concept `app-security`, [[decision_2026-08-10_sdk-renders-the-barrier]]) — nothing of Festipod's own is left to assert against. What this leaves unproven: [[caveat_first-time-entry-untested]].
 
-Scénario `@humain` : valide le flux RÉEL de distribution du wallet **de bout en bout, via la vraie app**, pas l'injection de test (cf. concept `nextgraph-platform` → `decision_2026-06-17_assisted-wallet-import`). Un navigateur vierge ouvre l'app staging → l'`AccessGateScreen` propose le **fichier** + le **mot de passe** → on télécharge le fichier **depuis l'écran**, on vérifie que le mot de passe affiché **égale** celui du wallet → import sur `nextgraph.eu` « Import a Wallet File » → retour → clic « Entrer » → app connectée (`ConnexionScreen`).
+The `@shared-wallet` scenario above is unaffected — it never drove the import, and it loads the **harness** (`loadAppInBrowser(name, 'harness')`), not the real app, so it never touched `AccessGateScreen` or `ensureIdentity()` either.
 
-- **Wallet e2e** : un fichier `.ngw` (`festipod-e2e-tests`, mot de passe = identifiant) placé **à la racine du worktree** ; `findE2eWalletFile()` le localise (`*.ngw`). Gitignoré → chaque environnement doit l'ajouter (sinon erreur claire).
-- `pool.ensureStagingApp()` (`hooks.ts`) — build **isolé** `bun run build.ts --outdir=dist-staging` (barrière d'accès **ON par défaut** ; mot de passe gravé + **fichier copié** en `/shared-wallet.ngw`, cf. `build.ts`), servi statiquement. Mémoïsé, lazy (seul `@humain` le paie).
-- **Bypass de la barrière pour `@e2e`** : le harness fait `browserContext.addInitScript` sur le **contexte persistant** pour poser `globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ = true` (s'applique à l'iframe app avant ses scripts) → `@e2e` voit l'app directement, pas la barrière. Les contextes frais (`@humain`) n'y touchent pas → barrière ON (cf. `decision_2026-06-17`). L'ancien `LoginScreen` `/login` a été retiré.
-- `pool.importWalletViaFile(page, filePath, password)` — `nextgraph.eu/#/wallet/login` → `setInputFiles('input[type=file]')` (attendre que la SPA rende, sinon `EncryptionError`) → champ password → unlock.
-- `pool.completeBrokerLogin(page, appUrl, walletPassword?)` — moitié « login broker » extraite de `setupBrokerPage`. **Attente robuste** : après le redirect (multi-hop), attend l'iframe app OU le lien « Click here to login with your wallet », puis déverrouille avec le mot de passe. La session broker n'étant **pas** persistée entre lancements, ce login wallet est requis à chaque run (warm-up + `@e2e` + `@humain`).
+## Isolation of the contexts (a property of the harness, not a tested behaviour)
 
-> **C'est l'e2e qui garantit que ça marche pour un humain réel** : Festipod fournit le BON fichier + mot de passe, et ce fichier importé donne un wallet fonctionnel sur un device vierge. Le scénario `@shared-wallet` (storageState) reste un raccourci de provisioning de test, il ne valide pas l'import.
+1. `freshBrowser` runs in a **separate process** from the persistent profile carrying the wallet → an **own** browser starts **with no wallet**.
+2. Every `newContext()` is a **hermetic storage partition** (Playwright guarantee).
+3. That holds on the **local** origin (`127.0.0.1`) and on the **broker origin** `nextgraph.net` **where the wallet actually lives**.
 
-## Isolation (garantie à 3 niveaux, prouvée par les scénarios)
+These three are what makes a cold-start verdict meaningful ([[caveat_reconnexion-froide-local-vs-broker]]). They are **no longer asserted by scenarios** — they were, and those scenarios were deleted: their subject was the tooling.
 
-1. `freshBrowser` est un **process séparé** du profil persistant porteur du wallet → un navigateur **own** démarre **sans wallet**.
-2. Chaque `newContext()` est une **partition de stockage hermétique** (garantie Playwright).
-3. Isolation prouvée non seulement sur l'origine **locale** (`127.0.0.1`) mais aussi sur l'**origine broker** `nextgraph.net` **où vit réellement le wallet** (sonde localStorage écrite dans A absente de B).
+## Files
 
-## Fichiers
+- Feature: `src/modules/workshop/features/multibrowser-harness.feature`.
+- Steps: `src/modules/workshop/steps/data/multibrowser.steps.ts`.
+- A `/blank` route added to the harness server (`hooks.ts`): a minimal page **with no NG stack**, for the localStorage isolation checks.
 
-- Feature : `src/modules/workshop/features/multibrowser-harness.feature`.
-- Steps : `src/modules/workshop/steps/data/multibrowser.steps.ts`.
-- Route `/blank` ajoutée au serveur harness (`hooks.ts`) : page minimale **sans stack NG**, pour les checks d'isolation localStorage.
+## The `@wip` convention (now enforced)
 
-## Convention `@wip` (désormais appliquée)
+`cucumber.json` (profile `default`) carries `"tags": "not @wip"`. `cookbook_add-scenario` prescribed `@wip` for anything unimplemented, but it was **excluded nowhere**; now `not @wip` is **AND**ed with the CLI filters (e.g. `--tags @data` → `(not @wip) and @data`, verified).
 
-`cucumber.json` (profile `default`) porte `"tags": "not @wip"`. Le `cookbook_add-scenario` prescrivait `@wip` pour le non-implémenté mais ce n'était **exclu nulle part** ; maintenant `not @wip` s'**AND** avec les filtres CLI (ex. `--tags @data` → `(not @wip) and @data`, vérifié).
+## Links
 
-## Liens
-
-- [[knowledge_data-layer-broker]] — la couche `@data` mono-navigateur (profil persistant) que cette capability étend.
-- [[cookbook_add-scenario]] — convention `@wip`, pièges de steps.
-- Concept `nextgraph-platform` → `brief_2026-06-15_shared-wallet-shim` — le stopgap wallet partagé que ce harness sert à tester.
+- [[knowledge_data-layer-broker]] — the single-browser `@data` layer (persistent profile) that this capability extends.
+- [[cookbook_add-scenario]] — the `@wip` convention, step pitfalls.
+- [[caveat_first-time-entry-untested]] — the hole left by the deleted `@humain` scenario.

.project/concepts/bdd-testing/knowledge_ui-layer.md

@@ -1,33 +1,40 @@
 ---
 type: knowledge
-summary: Couche @ui — renderHelper.tsx rend tout écran dans LocalDataProvider + happy-dom, world.renderCurrentScreen() l'invoque à chaque navigateTo, assertions sur le DOM rendu avec les fixtures de seed déterministes
+summary: The @ui layer — renderHelper.tsx renders a screen inside LocalDataProvider + happy-dom, assertions run against the rendered DOM; there is no access screen left to render, and a dormant module-evaluation-order trap around sharedWallet.ts survives, currently harmless
+last_checked: 2026-08-10
 ---
 
-# Couche `@ui`
+# The `@ui` layer
 
-`@ui` rend un écran avec `LocalDataProvider` (seed) + `RouterProvider` via happy-dom, puis assert sur le **DOM rendu**.
+`@ui` renders a screen with `LocalDataProvider` (seed) plus `RouterProvider` through happy-dom, then asserts on the **rendered DOM**.
 
-- Helper : `src/shared/test-harness/renderHelper.tsx` (installe les globals happy-dom, enveloppe l'écran). Invoqué depuis `world.ts:renderCurrentScreen()` à chaque `navigateTo(...)`.
-- Fixtures déterministes (`src/shared/data/seedData.ts`, voir concept `data-layer`) : `Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` existe, 5 events, etc.
+- Helper: `src/shared/test-harness/renderHelper.tsx` (installs the happy-dom globals, wraps the screen). Invoked from `world.ts:renderCurrentScreen()` on every `navigateTo(...)`.
+- Deterministic fixtures (`src/shared/data/seedData.ts`, see concept `data-layer`): `Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` exists, 5 events, and so on.
 
-## Bons patterns d'assertion
+## Good assertion patterns
 
 ```ts
-// Texte visible
+// Visible text
 expect(this.getDomText()).to.include('Marie Dupont');
-// Présence d'élément par classe/rôle
+// Element present, by class/role
 expect(this.renderedDoc!.querySelector('.app-avatar')).to.not.be.null;
-// Rendu conditionnel (rempli vs vide)
+// Conditional rendering (filled vs empty)
 expect(this.renderedDoc!.querySelectorAll('.app-card').length).to.be.greaterThan(0);
-// Champ requis rendu avec label + astérisque
+// Required field rendered with a label and an asterisk
 const labels = Array.from(this.renderedDoc!.querySelectorAll('p')).map(p => p.textContent ?? '');
 expect(labels.some(t => t.includes("Nom de l'événement *"))).to.be.true;
 ```
 
-## Champs & helpers de `FestipodWorld` (`src/shared/support/world.ts`)
+## `FestipodWorld` fields & helpers (`src/shared/support/world.ts`)
 
-- `renderedDoc: Document | null` — le DOM happy-dom rendu (peuplé par `renderCurrentScreen()`, appelé à chaque `navigateTo(...)`).
-- `currentScreenId: string | null` — l'écran courant.
-- Helpers d'assertion : `getDomText()` (texte du DOM), `hasText(t)`, `hasField(name)`, `hasElement(selector)` — ils **préfèrent le DOM rendu** mais **retombent sur la source** des écrans pour les steps non migrés (vestige, voir [[caveat_source-grep-vestiges]]).
+- `renderedDoc: Document | null` — the rendered happy-dom DOM (populated by `renderCurrentScreen()`, called on every `navigateTo(...)`).
+- `currentScreenId: string | null` — the current screen.
+- Assertion helpers: `getDomText()` (DOM text), `hasText(t)`, `hasField(name)`, `hasElement(selector)` — they **prefer the rendered DOM** but **fall back to the screens' source** for unmigrated steps (a leftover, see [[caveat_source-grep-vestiges]]).
 
-> Les classes `app-*` confirment le thème moderne (cf. `app-architecture`). Les anti-patterns (regex sur source, détails d'implémentation) sont proscrits par [[rule_test-layer-contracts]]. Pour écrire un nouveau scénario, voir [[cookbook_add-scenario]].
+## ⚠️ No `@ui` module renders an access screen — there is none left to render
+
+Festipod deleted its own access screen (`AccessGateScreen`) entirely; signing in is now one `ensureIdentity()` call, entirely SDK-owned (concept `app-security`, [[decision_2026-08-10_sdk-renders-the-barrier]]). The two features that used to cover the identifier field and its resolution were **deleted** with the screen — there is nothing left for a `@ui` scenario to render or assert here, and `renderElement()` (the helper `renderHelper.tsx` used to expose for prop-driven components like that screen) is gone too.
+
+**A dormant trap survives, unrelated to the screen's deletion.** `src/shared/utils/sharedWallet.ts` (the module used to be `src/modules/auth/sharedWallet.ts`, now deleted — the surviving copy moved) still **captures, at module evaluation time**, a global set by `build.ts` (`__FESTIPOD_SHARED_WALLET_PASSWORD__`). The `@ui` harness runs under Node **without going through the build**, and it reaches this module regardless of which screen a scenario renders: `screens/index.ts` eagerly imports every screen including `SettingsScreen`, which imports `src/shared/utils/ngSession.ts`, which imports `sharedWallet.ts` — so `hasSharedWallet()` is always `false` under `@ui`. This is currently **harmless**: `configure()` just runs with `sharedWallet: undefined`, and no `@ui` path ever calls `ensureIdentity()` (`renderScreen()` bypasses `AuthGate`/`NextGraphProvider` entirely). It stops being harmless the day a `@ui` scenario does call `ensureIdentity()` — full mechanics: `app-security` → [[caveat_shared-wallet-global-before-gate-import]].
+
+> The `app-*` classes confirm the modern theme (see `app-architecture`). Anti-patterns (regexes over the source, implementation details) are banned by [[rule_test-layer-contracts]]. To write a new scenario, see [[cookbook_add-scenario]].

.project/concepts/bdd-testing/rule_no-broker-polling.md

@@ -0,0 +1,27 @@
+---
+type: rule
+summary: NEVER poll the broker (re-reading in a loop "is it there yet?"). The read surface is push-based and says itself when a scope has finished syncing — `isPending` differs from `isSuccess` with empty `data`. App and tests wait for the push, never a broker re-read loop.
+last_checked: 2026-07-09
+---
+
+# Never poll the broker — wait for the subscription
+
+The published read surface is **push-based**: `watchShape` resolves a scope, pushes on every change, and carries its own readiness — `isPending` (still syncing) is distinct from `isSuccess` with empty `data` (synced and genuinely empty). A read is therefore never "query in a loop until it shows up"; the surface already answers *"has it finished?"*, and a loop that re-asks the question is asking something the answer is already available for.
+
+## The anti-pattern to ban
+
+```
+for (i = 0; i < N; i++) { if (await authParticipationCount(...) === X) break; sleep(500); }
+```
+
+Any loop that **re-queries the broker** (repeated `authParticipationCount`, `listMyEntityDocs`, `sparqlQuery`) in order to "wait" for data is forbidden: it hides the real mechanism, makes the test brittle (guessed timeout), and contradicts the surface the app is built on. That remark is what caused the deletion of the old caveat which wrongly held polling up as a practice.
+
+## What to do instead
+
+Wait for the **reactive push**. In practice (app AND test): the reactive state updates **on push**. We wait for THAT state to reflect the expectation — we **observe the settled reactive state**, we do NOT re-issue a broker read.
+
+- App: the screen is already reactive (re-render on push) — no application-level polling, no spinner driven by a guessed timeout (if a waiting state is wanted, it comes from the surface's own readiness flags, not from an added signal).
+- Test: **a helper that reliably waits for the push/readiness is welcome** (it makes things reliable without making them brittle). What is banned is the **re-read loop**, not waiting for a signal.
+- **Pragmatic fallback**: if strictly waiting for the push/signal turns out to be brittle one way or another, a **short interval** (`setInterval` / closely spaced re-checks) that **observes the ALREADY updated reactive state** (the local state fed by the subscription — NOT a broker re-read) is acceptable: it is as close as it gets to what the user experiences, simply **waiting** for the (reactive) screen to update. The red line is invariant: **never re-query the broker in a loop**; observing the settled reactive state, yes.
+
+See also [[caveat_wallet-bloat-hang]] (another source of `@data` flakiness, orthogonal to this one).

.project/concepts/bdd-testing/rule_test-layer-contracts.md

@@ -1,29 +1,29 @@
 ---
 type: rule
-summary: Chaque couche BDD répond à une question distincte — @ui = rendu (DOM + seed), @data = mutations/persistance broker, @e2e = collaboration des couches sur un parcours ; descendre chaque assertion à la couche la plus basse qui peut y répondre
+summary: Each BDD layer answers a distinct question — @ui = rendering (DOM + seed), @data = broker mutations/persistence, @e2e = collaboration of the layers over a journey; push every assertion down to the lowest layer that can answer it
 ---
 
-# Règle : contrat des couches de test
+# Rule: the test layer contract
 
-Chaque couche répond à **une question distincte**. Mélanger les préoccupations produit des tests fragiles qui cassent au refactor sans attraper de vraie régression. **Descendre toute assertion à la couche la plus basse qui peut y répondre.**
+Each layer answers **one distinct question**. Mixing concerns produces brittle tests that break on refactors without catching any real regression. **Push every assertion down to the lowest layer that can answer it.**
 
-- **`@ui` — couche affichage.** Rend un écran avec `LocalDataProvider` (seed) + happy-dom et assert sur le DOM. Vérifie que *données connues → l'écran montre le texte et les éléments attendus*. **Ne teste pas** la navigation, les mutations, ni la persistance.
+- **`@ui` — display layer.** Renders a screen with `LocalDataProvider` (seed) plus happy-dom and asserts on the DOM. Checks that *given known data, the screen shows the expected text and elements*. **Does not test** navigation, mutations or persistence.
 
-- **`@data` — couche données.** Pilote des mutations ORM via le **broker NextGraph réel** (harness headless, pas d'UI app). Vérifie que *les opérations sur shapes sont persistées et observables dans le wallet*. Pas de DOM ici — utiliser le bridge `window.__testData`.
+- **`@data` — data layer.** Drives ORM mutations through the **real NextGraph broker** (headless harness, no app UI). Checks that *shape operations are persisted and observable in the wallet*. No DOM here — use the `window.__testData` bridge.
 
-- **`@e2e` — couche intégration.** Boote l'app réelle dans l'iframe broker (Playwright/Chromium). Vérifie que *les couches collaborent pour livrer un parcours* (créer → lister → modifier → recharger → toujours là). **Rare** : 1 scénario par chemin critique ; **ne jamais dupliquer** un check de contenu `@ui`.
+- **`@e2e` — integration layer.** Boots the real app inside the broker iframe (Playwright/Chromium). Checks that *the layers collaborate to deliver a journey* (create → list → edit → reload → still there). **Rare**: 1 scenario per critical path; **never duplicate** a `@ui` content check.
 
-## Pourquoi le coût impose la pyramide
+## Why cost dictates the pyramid
 
-`@ui` tourne in-process (instantané) ; `@data` boote un broker (~50s) ; `@e2e` boote broker + app + navigateur (~2min). Une affirmation de rendu appartient à `@ui`, pas à `@e2e`.
+`@ui` runs in-process (instant); `@data` boots a broker (~50s); `@e2e` boots broker + app + browser (~2min). A rendering claim belongs to `@ui`, not to `@e2e`.
 
-## Anti-patterns `@ui` à proscrire
+## `@ui` anti-patterns to ban
 
 ```ts
-// ❌ regex sur la source : couple le test à la structure du code
+// ❌ regex over the source: couples the test to the structure of the code
 expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source)).to.be.true;
-// ❌ détails d'implémentation
+// ❌ implementation details
 expect(/showDuplicateWarning/.test(source)).to.be.true;
 ```
 
-Préférer des assertions sur le **DOM rendu** + données de seed (voir [[knowledge_ui-layer]]). Les helpers/maps d'analyse de source sont des vestiges en voie de suppression : [[caveat_source-grep-vestiges]].
+Prefer assertions on the **rendered DOM** plus seed data (see [[knowledge_ui-layer]]). The source-analysis helpers and maps are leftovers on their way out: [[caveat_source-grep-vestiges]].

.project/concepts/bdd-testing/rule_tests-validate-festipod-not-the-sdk.md

@@ -0,0 +1,26 @@
+---
+type: rule
+summary: Festipod's tests validate FESTIPOD's behaviour — multi-user included — never the SDK's, and they take NO shortcut past the published surface. Multi-user is exercised the way it is lived, several browser contexts each signing in as itself, since no published call lets one page hold two identities.
+---
+
+# The tests validate Festipod, not the SDK — and they take no shortcut
+
+## The rule
+
+Stated by the project owner on 2026-08-10, when the app moved onto the pulled [[contract_polyfill-surface]]:
+
+1. **Festipod is a consumer entirely ignorant of how the SDK is implemented, and its tests may take no shortcut.** No deep import into the package, no reaching for a symbol the contract does not publish, no fixture that reaches past the published surface to get to a state faster.
+2. **The subject under test is Festipod's behaviour — multi-user included — never the SDK's.** An assertion whose subject is "the capability was learned", "the store served the key", "the inbox holds two deposits" is testing the provider. It does not belong here; if it is worth having, it belongs in the provider's own suite.
+3. **Multi-user is tested the way it is lived**: several browser contexts, each signing in as itself through `ensureIdentity()`. Each actor obtains what it consumes through the application, under its own session.
+
+## Why
+
+The contract publishes no way to name or switch identity: signing in is one call that takes **no identifier**, and *"no other call takes one"*. A session is one user's. So "play two identities on one page" is not a capability that went missing — it is something no published call offers, and a test that manufactured it would be exercising something below the surface and would keep passing while the real behaviour rotted; worse, it would hand one actor's values to another through a shared variable, which is exactly the shape that once hid a real bug behind a green test (see [[multi-actor-tests-obtain-not-receive]]).
+
+The rule also protects the thing the contract exists for. Every shortcut past the surface is a place the app learns something it must unlearn, and it silently converts a **provider gap** — which should be written down and raised — into an app-side workaround nobody revisits.
+
+## How to apply
+
+The tell is mechanical: a test import that is not `@ng-eventually/polyfill`, or an assertion naming an SDK concept rather than something a Festipod user would observe.
+
+When a scenario cannot be written without a shortcut, that is a finding, not an obstacle to route around: the missing thing is either a **product behaviour Festipod does not expose yet** (build it) or a **gap in the provider's contract** (raise it with the provider and leave the scenario unwritten or `@wip` meanwhile — [[rule_app-uses-sdk-surface-only]]). Deleting a scenario whose subject turns out to be the SDK is the correct outcome, not a loss of coverage.

.project/concepts/data-layer/_overview.md

@@ -1,35 +1,34 @@
 ---
 type: _overview
-summary: Couche données NextGraph telle qu'utilisée AUJOURD'HUI (mono-store) — stack ORM/SHEX, modes connected/demo, entités, seed, et 3 règles d'écriture critiques
+summary: How Festipod persists its data through the @ng-eventually/polyfill SDK — entities stored as documents placed by scope, direct SPARQL writes + reactive shape reads, SHEX stack, connected/demo modes, seed
 triggers:
-  keywords: [nextgraph, useShape, ORM, SHEX, shape, store, private_store, "@graph", NURI, sparql, sparql_update, seed, wallet, RepoNotFound, FestipodData, ngGraph, bootstrap]
-  paths: ["src/shared/shapes/**", "src/shared/hooks/useShape*", "src/shared/context/NextGraphContext.tsx", "src/shared/context/FestipodDataContext.tsx", "src/shared/utils/ng*", "src/shared/data/seedData.ts"]
+  keywords: [nextgraph, "@ng-eventually", polyfill, watchShape, useShape, useShapeQuery, SHEX, shape, scope, "@graph", NURI, inbox, share, sparql, seed, wallet, FestipodData, ngSession, ngGraph, storeRegistry, bootstrap, document, entité, déconnexion, reconnexion]
+  paths: ["src/shared/shapes/**", "src/shared/data/**", "src/shared/context/NextGraphContext.tsx", "src/shared/context/FestipodDataContext.tsx", "src/shared/utils/*", "src/shared/data/seedData.ts"]
 ---
 
 # Data layer
 
-Comment Festipod **persiste ses données aujourd'hui** via NextGraph (P2P, local-first, chiffré). État actuel : **mono-store** — tout atterrit dans le `private_store` de l'utilisateur connecté.
+How Festipod **persists its data** through NextGraph (P2P, local-first, end-to-end encrypted). The data SDK is **`@ng-eventually/polyfill`**: every entity is a **document** placed in its **scope** (public / protected / private). A **write** is direct SPARQL into the entity's own document; a **read** is the SDK's **reactive shape surface** (`watchShape(shape, scope)` → the app's `useShapeQuery` binding), which resolves the scope itself and pushes on change — the app resolves, lists and re-queries nothing. See [[rule_document-per-entity]]. The mapping *which entity → which scope* is a **product** fact (concept `functional-domain`, [[knowledge_data-scopes-and-discovery]]); this concept describes **how Festipod uses the surface**.
 
-> Distinction importante : ce concept décrit le **code actuel**. Le modèle *cible* (multi-store, multi-user, autorisations) est de la doctrine **prospective** qui vit dans le concept `nextgraph-platform` (briefs). NextGraph comme **système externe** (stores, permissions, inbox, SDK) y est aussi documenté.
+> **SDK boundary.** `@ng-eventually/polyfill` is injected **exactly once** through `ngSession.configure(...)`. The pulled contract is the whole of what this repo knows about it: never describe here how the data layer is implemented underneath. See [[rule_app-uses-sdk-surface-only]].
 
-**À lire avant de toucher aux écritures :** les 3 règles ci-dessous — chacune corrige un bug réel (`RepoNotFound`, suppression non persistée, redirect intempestif).
+## Model & data
 
-## Règles d'écriture (chacune adossée à une décision)
+- [[contract_polyfill-surface]] — **the data contract, PULLED from the provider and version-pinned**: the `@ng-eventually/polyfill` surface the app codes against, what it guarantees and what it refuses to promise. The ONLY reference — never open the provider's own sources.
+- [[knowledge_nextgraph-stack]] — the SHEX shapes, the reactive ORM bindings, `build:orm`, injection through `ngSession`
+- [[knowledge_data-modes]] — connected (SDK) vs disconnected/demo (seeded local state), how the provider is chosen
+- [[knowledge_entities]] — the `Fp*` types and their SHEX shapes
+- [[knowledge_seed-data]] — seed data, `CURRENT_USER_ID`
+- [[knowledge_context-internals]] — pitfalls of `FestipodDataContext` (who the current user is and when it arrives, the legacy principal space, dev auto-seed, `participantCount`, local no-op)
 
-- [[rule_private-store-scope]] ← [[decision_2026-03-17_private-store-nuri-scope]]
-- [[rule_conditional-ng-init]] ← [[decision_2026-03-13_conditional-ng-init-broker-detection]]
+## Write rules
 
-## Pièges (lire avant de toucher au contexte / aux suppressions / aux champs d'event)
+- [[rule_document-per-entity]] — every entity gets **its own document** (per scope), never one at store level; access is granted per document, so this is what makes isolation possible
+- [[rule_app-uses-sdk-surface-only]] — the pulled contract is the only reference; a gap in it is raised with the provider, never worked around here
 
-- [[knowledge_context-internals]] — currentUser `@mariedupont`, auto-seed dev, `participantCount` cache, IRI vide, no-op local
-- [[caveat_participation-deletion]] — `leaveEvent` via `ngSet.delete()` (décision SPARQL annulée), persistance possiblement partielle
-- [[caveat_event-fields-not-persisted]] — `startTime`/`themes`… perdus en connecté (SHEX incomplet)
+## Pitfalls (read before touching deletions / event fields)
 
-## Modèle & données
+- [[caveat_participation-deletion]] — withdrawal must be **authoritative** and must not come back
+- [[caveat_event-fields-not-persisted]] — `startTime`/`themes`… not covered by the Event shape → lost when connected
 
-- [[knowledge_nextgraph-stack]] — paquets `@ng-org/*`, SHEX, ORM, `build:orm`
-- [[knowledge_data-modes]] — connected vs disconnected/demo, providers selon le statut NG
-- [[knowledge_entities]] — types `Fp*` et shapes
-- [[knowledge_seed-data]] — données de seed, `CURRENT_USER_ID`
-
-> Sécurité/confidentialité (mono-store, confiance broker) : concept `app-security`.
+> Confidentiality (scope isolation, trusting the SDK): concept `app-security`. Product scopes per entity + discovery: concept `functional-domain`.

.project/concepts/data-layer/brief_2026-07-20_attendance-set-model.md

@@ -0,0 +1,97 @@
+---
+type: brief
+summary: Target model for sign-ups — a Participation READABLE by everyone (event ref + `active` boolean + a key-less reference to the participant's profile), deposited into the event's inbox; the creator processes the inbox, dedups WITHOUT knowing who, files the reference into a Set on the event and PURGES the cancelled ones; count = Set.size with no filtering (accepted upper bound); only connections can read the profile and recognize the person. Supersedes the mutated counter + plaintext userId.
+---
+
+# Brief (2026-07-20, revised 2026-07-27) — Set-based sign-ups
+
+## The model
+
+Laid down and refined by the PO on 2026-07-27. Everything is **keys and URLs** — no roles, no membership, no allow-list.
+
+1. The participant creates a **Participation** object, **readable by everyone**, holding: the **reference to the event**, an **`active` boolean**, and a **reference to their *protected* profile that carries no key**. **Nothing else** — no description for now.
+2. They deposit the **Participation's reference** into the **event's inbox**.
+3. The **creator** processes their inbox **automatically**, as soon as they are online.
+4. They **dedup** (see below) — **without knowing who the participant is**: they hold a name for the profile, not the key to read it.
+5. They file a **reference** to the Participation into a **Set** carried by the event's document.
+6. Anyone reads **`Set.size`** → the number of participants.
+7. Someone **connected** to the participant holds their profile's cap, reads it, and **recognizes** the person.
+
+**Withdrawal**: the participant sets `active` to false **on their own object**. The creator sees it when reading, and **purges** — removing the reference from the Set.
+
+Three properties follow: **anonymous attendance by default** (even the creator cannot see who); **nobody modifies anyone else's sign-up** (only the participant holds the write key to their own object); **no plaintext `userId`** ever travels.
+
+### The principle that holds it all together: the truth is in the object, messages are only hints
+
+The object **controlled by the participant** is what counts. Any message — an inbox deposit, a purge notification — is only a **hint** that triggers a check, never an authority.
+
+Consequence: **forgery becomes structurally harmless**. A fake « purge X » leads the creator to read X, find it still active, and do nothing. That is why inbox deposits **need not be signed** — which is just as well, since the contract promises no authenticated sender.
+
+### Why a flag rather than a deletion
+
+Without the read key, a **deletion** cannot be told apart from "nothing was ever there". A **readable** object carrying a **flag** transforms the problem: the cancellation no longer has to be *detected*, it is simply *read*. The blocker disappears instead of being worked around with a forgeable message.
+
+### Why the identity pointer targets the existing profile
+
+No need for a second document per participation: the participant's **protected profile** already plays that role, and their connections **already** hold the key to read it — that is the very definition of being connected. A third party sees an opaque reference.
+
+The advantage over an encrypted field inside the Participation: **adding a connection rewrites nothing**. The profile is shared with a new connection once, durably (and irreversibly — the contract publishes no revocation). An encrypted field would require re-encrypting to N recipients and rewriting the Participation on every new connection.
+
+## What this rests on
+
+Two guarantees the contract publishes, and one thing it does not.
+
+| What the model needs | Where it stands |
+|---|---|
+| A reference can **name without granting read access** | Published: *"A returned reference carries no key… A reference found inside a document yields a name, not a key."* |
+| Sharing is **per document, durable and one-way** | Published: `inbox.share(doc, toUser)` — one act, no revocation, nothing per reader on a public document |
+| **Anyone may deposit, only the owner reads** the inbox | Published: `inbox.postToDocument` / `inbox.read` |
+| A **dedup key** letting the creator count distinct people without reading them | **NOT published.** See below — this is the open dependency. |
+
+## The dedup: the requirement, and the gap
+
+**The requirement, validated by the PO (2026-07-27)**: the creator must be able to tell two references from the *same* person apart from two references from *different* people, **without ever knowing who** — otherwise the count is not a count of people, and a participant could inflate it by creating several Participations.
+
+**The contract publishes nothing that does this.** A reference "yields a name, not a key", and no call answers "do these two references belong to one person?". So the mechanism is **not Festipod's to specify**: it is a **gap to raise with the provider**, stated as a need — *a stable, per-person discriminator that can be compared without reading the referenced document*.
+
+Design consequence, whatever the mechanism turns out to be: the Set is **keyed by that discriminator** — at most one reference per person. `Set.size` = the number of distinct people.
+
+### The reservation that must outlive this brief
+
+Any such discriminator is by construction a **pseudonym**: it does not say *who*, but it is comparable across contexts, so whoever collects references can link them. **Never present a Festipod action as "anonymous"** when it circulates one — the contract guarantees no anonymity, and making the Participation public widens the surface on which it is collected. Whether the pseudonym can be rotated, or scoped, is part of the gap above.
+
+## Trade-offs deliberately accepted (PO, 2026-07-27)
+
+- **No filtering on read.** The count is `Set.size`, **without** checking the `active` flags. We accept the **staleness risk**: a cancelled participation still counts until the creator has purged. `Set.size` is therefore an **upper bound**, exact once purged. *Rationale: keep reads simple and O(1).*
+- **Purging is the creator's job.** No curator service, no catch-up by readers.
+- **No description** in the Participation for now. *(To be reopened when the need arises: whatever we put there would become public.)*
+- **Creator offline**: the Set does not move until they have processed their inbox. Accepted.
+
+## What changes vs the current implementation
+
+What exists today ([[knowledge_context-internals]] §participantCount) derives a `participantCount` **written by the owner** from inbox markers carrying the **plaintext `userId`**.
+
+- **Drop the `userId`** from inbox deposits → only the **Participation's reference** remains.
+- **Count distinct people** through the discriminator above, no longer `userId`s.
+- **`event.participantCount` goes away**, replaced by `Set.size`.
+- **Identity resolution** now goes through **reading the profile** (hence through being connected), no longer through the marker.
+- **Withdrawal stops being a deletion** → `active` set to false + a purge by the creator. See [[caveat_participation-deletion]], whose requirement (« authoritative, must not come back ») still holds but changes mechanism.
+
+Still valid as-is: **reactive reads**, **re-arming on reconnection**, and the **id-space fix** already shipped.
+
+## Open points
+
+- **Participation scope** — it becomes **public**, whereas current product doctrine places it in *protected* ([[knowledge_data-scopes-and-discovery]], concept `functional-domain`). That leaf describes **what is implemented**: do not change it until this brief has graduated, but **do update it at that point**.
+- **Recognition by connections** (step 7) — and what happens to a broken connection: the contract publishes **no revocation**, so sharing a profile is permanent. Explicitly deferred to a second stage.
+- **Public reads are not recursive** — this is the principle the whole model rests on, and it deserves to be stated on its own: *an item in the **public** store is public — whoever has the URL reads the content.* But **not recursively**: public content may **reference** private content, and **that is exactly our case**. So the creator reads the Participation (public) and **cannot** follow the reference to the profile (protected). That is what yields both readability by the creator and anonymity towards them — with no additional mechanism.
+
+## Dependencies
+
+- **Blocking — a contract gap**: no published way to **dedup without reading** (see above). Until the contract answers it, coding this model would produce a count that **claims** to be a count of people without being one. Raise it with the provider; do not emulate it here.
+- **Parked**: **identity terminology** (wallet / user / profile) — see `.project/to-discuss.md`.
+
+## Status: model settled, implementation gated
+
+The model is **settled** (PO, 2026-07-27). What remains gated is the **implementation**, waiting on the dependency above. **Do not remove the current owner-derived counter** in the meantime ([[knowledge_context-internals]]).
+
+Links: [[caveat_participation-deletion]], [[rule_document-per-entity]], [[rule_app-uses-sdk-surface-only]], app-security ([[brief_2026-05-18_authorization-matrix]], [[knowledge_trust-model]]).

.project/concepts/data-layer/caveat_event-fields-not-persisted.md

@@ -1,17 +1,19 @@
 ---
 type: caveat
-summary: Le type FpEventData et le seed portent startDate/endDate/startTime/endTime/themes, mais le SHEX Event ne les définit pas — ces champs sont silencieusement perdus en mode connected (NextGraph)
+summary: The FpEventData type and the seed carry startDate/endDate/startTime/endTime/themes, but the Event SHEX does not define them — these fields are silently lost in connected mode (NextGraph)
 last_checked: 2026-06-15
 ---
 
-# Caveat : champs d'événement non persistés en mode connected
+# Caveat: event fields not persisted in connected mode
 
-Le type app `FpEventData` (`src/shared/data/types.ts`) et le seed (`seedData.ts`) portent des champs **`startDate`, `endDate`, `startTime`, `endTime`, `themes`** — mais la **shape SHEX `Event`** (`src/shared/shapes/shex/festipodShapes.shex`) ne les définit **pas**. La shape ne couvre que : `title, description, date, location, distance, participantCount, coverImage, hostName, hostInitials` (à vérifier dans le `.shex`).
+The app type `FpEventData` (`src/shared/data/types.ts`) and the seed (`seedData.ts`) carry the fields **`startDate`, `endDate`, `startTime`, `endTime`, `themes`** — but the **SHEX `Event` shape** (`src/shared/shapes/shex/festipodShapes.shex`) does **not** define them. The shape covers exactly (verified 2026-08-10 in the `.shex`): `title, description, date, location, distance, participantCount, coverImage, hostName, hostInitials`, plus an optional `inbox`.
 
-## Conséquence
+> That `inbox` field is a **vestige, and it must stay unused**: it was there to publish an event's inbox address so others could deposit into it. The app no longer handles an inbox address anywhere — a deposit **names the document** (`inbox.postToDocument(doc, …)`) and the owner opens its own with `openDocumentInbox(doc)`. Writing an address into the entity would put back exactly what the surface removed ([[rule_document-per-entity]]).
 
-En **mode connected** (NextGraph), le mapping (`mapEvent` dans `FestipodDataContext.tsx`) ne lit/écrit que les champs de la shape. Les champs hors-shape sont **silencieusement perdus** : remplis par des defaults ou vides. Or des écrans **les affichent** (ex. `startTime`/`endTime` dans `EventDetailScreen`) — donc en mode démo (seed local) ils apparaissent, mais en connecté ils disparaissent. Décalage observable seulement à l'usage.
+## Consequence
 
-## Pour corriger (si on veut les persister)
+In **connected mode** (SDK), the mapping (`mapEvent` in `FestipodDataContext.tsx`) only reads/writes the shape's fields. Fields outside the shape are **silently lost**: filled with defaults, or empty. Yet screens **do display them** (e.g. `startTime`/`endTime` in `EventDetailScreen`) — so in demo mode (the local seed) they show up, but when connected they vanish. The discrepancy is only observable in actual use.
 
-Ajouter les champs à `festipodShapes.shex` puis `bun run build:orm`, et étendre `mapEvent`. C'est aussi un prérequis de la modélisation complète du point de rencontre (cf. concept `nextgraph-platform`, [[brief_2026-05-21_fork-nextgraph-inbox]] §Couche 3). Tant que ce n'est pas fait, **ne pas se fier aux champs date/heure/thèmes en mode connecté**.
+## To fix it (if we want them persisted)
+
+Add the fields to `festipodShapes.shex`, then `bun run build:orm`, and extend `mapEvent`. Until that is done, **do not rely on the date/time/theme fields in connected mode**.

.project/concepts/data-layer/caveat_participation-deletion.md

@@ -1,23 +1,15 @@
 ---
 type: caveat
-summary: La suppression de Participation (leaveEvent) se fait via ngSet.delete() — le bug de non-persistance qui avait motivé SPARQL DELETE est en grande partie corrigé, mais la persistance peut rester partielle ; vérifier après refresh
-last_checked: 2026-06-15
+summary: Withdrawing from a meeting point must be AUTHORITATIVE — once the Participation is deleted, it must not come back; after a real refresh, check that the sign-up is really gone on the data side
+last_checked: 2026-07-03
 ---
 
-# Caveat : suppression de Participation via `ngSet.delete()`
+# Caveat: withdrawal must be authoritative
 
-**État actuel du code** (`src/shared/context/FestipodDataContext.tsx`, `leaveEvent` en mode NG) : la suppression d'une `Participation` se fait via **`participationsShape.ngSet.delete(ngPart)`** — pas via `ng.sparql_update()` DELETE WHERE.
+Business contract: when a user **withdraws** from a meeting point (`leaveEvent` in `src/shared/context/FestipodDataContext.tsx`), the `Participation` must be **durably deleted**. It must **not come back to life** after a resynchronization.
 
-## Histoire (important)
+## The pitfall
 
-Une décision antérieure ([[decision_2026-03-17_sparql-delete-for-orm-objects]], **annulée le 2026-06-15**) imposait SPARQL DELETE car `ngSet.delete()` ne persistait pas (l'objet réapparaissait au refresh). Ce **bug du `@ng-org/orm` a depuis été en grande partie corrigé** : `ngSet.delete()` est redevenu le chemin utilisé.
+Reflecting the deletion only in the UI's reactive state is not enough: the sign-up can reappear if the deletion is not **persisted** on the data side. Withdrawal must therefore be **authoritative at the document level**, not merely at the display level.
 
-## Le piège (pourquoi un caveat et pas une règle)
-
-La correction **semble partielle** : selon les cas, la suppression via `ngSet.delete()` peut ne **pas se propager complètement** au broker. Donc :
-
-- **Ne pas tenir pour acquis** que `leaveEvent` persiste à coup sûr — **vérifier après un vrai refresh** que la participation a bien disparu côté wallet.
-- Si une suppression se révèle non persistée, le repli connu reste `ng.sparql_update()` avec `DELETE WHERE { GRAPH <…> { <…> ?p ?o } }` (le mécanisme décrit dans la décision annulée). **Ne pas combiner** les deux (conflit CRDT — c'était l'autre enseignement de la décision).
-- Re-tester ce point à chaque montée de version de `@ng-org/orm`.
-
-> À valider : ouvrir `FestipodDataContext.tsx` → `leaveEvent` (mode NG, `console.log('Deleting participation via ngSet.delete()')`). Si le code est repassé à `sparql_update`, mettre ce caveat à jour ou le promouvoir en règle.
+**To check after any change to `leaveEvent`**: sign up, then withdraw, do a **real refresh**, and confirm that the participation is indeed gone (the button must not stay on « ✓ Je participe »). Covered by the `@e2e` scenario « Se désinscrire d'un événement » (`src/modules/event/features/cycle-de-vie-evenement.feature`) and a `@data` one, « désinscription persistante » (`inscription-inbox.feature`).

.project/concepts/data-layer/contract_polyfill-surface.md

@@ -0,0 +1,150 @@
+---
+type: contract
+summary: The API @ng-eventually/polyfill exposes to an application — signatures, guaranteed behaviour, and what it does not offer
+pulled_from: https://gitea.reconnexion.apps.gueraud.net/Reconnexion/ng-eventually.git/.project/concepts/app-contract/contract_polyfill-surface.md
+pulled_version: 1ecf511e9d8de8e0feb007f3a88f2c0d56ce455a
+pulled_at: 2026-08-16
+---
+
+# contract_polyfill-surface — `@ng-eventually/polyfill`
+
+## Scope
+
+This package is a polyfill of NextGraph's SDK.
+
+This package covers placement (creating and listing an application's documents by scope), reading (a document's subjects, one-shot or reactive), sharing a document with a named user, and depositing into inboxes. It does not cover user management, display names, transport, or the operation of a deployment.
+
+### Deployment requirements
+
+An application using this package must:
+
+- serve a wallet file (`.ngw`) from its own bundle, and pass its URL and password to `configure` as `sharedWallet: { fileUrl, password }`;
+- call `init(…)` — this package's, not the one it passed to `configure` — and then await `ensureIdentity()`, in a browser context, before rendering its interface. `ensureIdentity()` resolves once a session is open, and a session arrives only through `init`: awaited before `init` has been called, it throws and names the call to make first.
+
+## Surface
+
+Full typed shape: the package's `types` entry, `@ng-eventually/polyfill`. A type is published only when a published signature uses it. The load-bearing signatures:
+
+```ts
+// ── bootstrap ────────────────────────────────────────────────────────────
+export function configure(c: EventuallyConfig): void;
+export interface EventuallyConfig {
+  ng: NgLike;                                    // the `ng` object from @ng-org/web
+  useShape: UseShapeLike;                        // `useShape` from @ng-org/orm
+  sharedWallet?: SharedWalletConfig;             // { fileUrl, password, importUrl? }
+  debugAccessLog?: boolean;
+  init?: (...args: any[]) => any;
+  initNg?: (...args: any[]) => any;
+}
+
+// ── identity — one await before the application renders ──────────────────
+export async function ensureIdentity(): Promise<PrincipalId>;   // returns who you are
+
+// ── addressing ───────────────────────────────────────────────────────────
+export type Nuri     = `did:ng:${string}`;
+export type NuriLike = Nuri | string;
+export type Scope    = "public" | "protected" | "private";
+
+// ── placement: where an application's documents live ─────────────────────
+export const storeRegistry: {          // no identity parameter — a session is one user's
+  createEntityDoc(scope: Scope): Promise<Nuri>;
+  listMyEntityDocs(scope: Scope): Promise<Nuri[]>;
+  resolveScopeGraph(scope: Scope): Promise<Nuri>;
+  resolveWriteGraph(scope: Scope): Promise<Nuri>;
+  openDocumentInbox(doc: NuriLike): Promise<Nuri>;
+};
+
+// ── reading ──────────────────────────────────────────────────────────────
+export async function readUnion(docs: NuriLike[]): Promise<UnionSubject[]>;
+export interface UnionSubject { subject: string; graph: Nuri; props: Record<string, string[]> }
+export function useShape(shapeType: unknown, scope: unknown): unknown;   // read-filtered view
+export function watchShape(query: ShapeQuery): ShapeObservable;
+export function subscribeDoc(nuri: NuriLike, onChange: (r: DocChange, t: DocChangeType) => void): Unsubscribe;
+export function subscribeDocs(nuris: NuriLike[], onChange: (r: DocChange, t: DocChangeType) => void): Unsubscribe;
+
+// ── low-level document / SPARQL primitives ───────────────────────────────
+export const docs: {
+  // `sessionId` is `string | number` — upstream's own declared type (`Session.session_id`).
+  // It is RELAYED, never converted: the wasm side deserializes a `u64`, and stringifying it
+  // fails for real (`Deserialization error of session_id JsValue("1")`).
+  docCreate(sessionId: string | number, crdt: string, cls: string, dest: string, store?: unknown): Promise<Nuri>;
+  sparqlQuery(sessionId: string | number, query: string, base?: string, anchor?: NuriLike, label?: string): Promise<unknown>;
+  // Returns the commits the update produced, as upstream does (it typed this `void` until
+  // 2026-08-14 while already relaying the value). A caller that ignores it is unaffected.
+  sparqlUpdate(sessionId: string | number, query: string, anchor?: NuriLike, label?: string): Promise<unknown>;
+};
+
+// ── inbox: giving to read, and depositing ────────────────────────────────
+export const inbox: {
+  share(doc: NuriLike, toUser: string): Promise<void>;      // give a reader the key
+  post(targetInbox: NuriLike, opts: PostOptions): Promise<void>;
+  postToDocument(doc: NuriLike, opts: PostOptions): Promise<void>;
+  read(targetInbox: NuriLike): Promise<Deposit[]>;          // only your own
+  readForDocument(doc: NuriLike): Promise<Deposit[]>;
+  readSynced(targetInbox: NuriLike): Promise<Deposit[]>;
+  processInbox(targetInbox: NuriLike): Promise<Deposit[]>;
+  watch(targetInbox: NuriLike, onDeposits: (d: Deposit[]) => void): () => void;
+  // `materialize` (a second published name for `read`) was REMOVED on 2026-08-14 —
+  // an alias with no call site, and no counterpart upstream. Use `read`.
+};
+export interface Deposit { from: PrincipalId | null; payload: unknown; ts: number }
+
+// ── the wrapped SDK objects ──────────────────────────────────────────────
+export const ng: NG;                    // call this instead of the `ng` passed to `configure`
+                                        // `NG` is upstream's own type (`@ng-org/web`), 88 typed
+                                        // members; it was `Record<string, any>` until 2026-08-14
+export function init(...args: any[]): any;      // likewise — not the `init` passed to `configure`
+export function initNg(...args: any[]): any;
+```
+
+## Guarantees
+
+Every entry accepts `NuriLike` and validates at the door; what it returns is a precise `Nuri`. No type guard is published.
+
+A returned reference carries no key — not `createEntityDoc`, not `listMyEntityDocs`, not `UnionSubject.subject` / `.graph`. A reference found inside a document yields a name, not a key.
+
+You read a document whose key you hold: you created it, it was shared with you, or it sits in a public store, which serves its read key to whoever asks. No call answers "may I read this?".
+
+What was shared with you becomes readable after `ensureIdentity()`.
+
+`readUnion` returns one entry per distinct subject present in a document. `subject` is that subject's IRI exactly as written, and is a `string`, because a subject may be any IRI; `graph` is the document reference you passed in, and is the `Nuri` to hand back to this surface. Properties of different subjects are never merged, and the same subject IRI found in two documents stays two entries, told apart by `graph`. Several objects in one document are allowed. Recommended placement is one document per business entity: access is granted per document.
+
+`urn:ng-eventually:` is reserved. Triples whose **subject** falls under that prefix are dropped on read and never returned by `readUnion`; every other IRI is returned.
+
+Only a document's owner writes to it. Holding its read key never grants a write.
+
+`inbox.share(doc, toUser)` names the document and the person; the recipient calls nothing. It refuses a recipient nobody has signed in as, rather than creating them.
+
+`inbox.post` refuses a target that is not an inbox; to reach a document's owner, use `inbox.postToDocument(doc, …)`. Anyone may deposit into an inbox; only its owner reads it.
+
+`ensureIdentity()` settles the identity, completes the connection work it starts, and returns the identity. It takes no identifier, and no other call takes one.
+
+It resolves **only once that work has actually completed**: if what was shared with you could not be restored, or a queue could not be drained, it throws instead of returning. So a resolved call means everything shared with you is readable — and a rejected one must not be rendered past, since the interface would show an empty account rather than an empty screen.
+
+`ensureIdentity()` mounts a full-screen barrier on every top-level load, and takes it down itself — past the broker round-trip it never appears. A person who comes back to the page from that round-trip finds the barrier live again, prefilled, and confirming it hands the page over a second time. The application's own page is never reloaded and nothing outside the barrier is touched.
+
+**The session is the package's, not yours.** You never build one, and no call takes one. Call this package's `init` (not the one you passed to `configure`): it captures the session the SDK delivers to `init`'s callback and keeps it, then calls your callback with that same event untouched — so an application that wants the `session_id` for the `docs` primitives reads it there, and one that does not may pass no callback at all. Identity normalisation is the package's too: `@Alice`, `alice ` and `ALICE` are one person.
+
+Where a call must first find out whether something already exists — a document's record in its store, a user's inbox — it throws when it could not find out, instead of proceeding as though the answer were "nothing". So `createEntityDoc` throws if the document cannot be recorded in its store, and resolving an inbox throws rather than handing back a second one. **A rejection means "unknown", never "absent"** — retry it or surface it, but do not read it as an empty result.
+
+## Non-guarantees
+
+**No display name.** `ensureIdentity()` returns an opaque identifier: do not parse it, split it, or render it as a readable name.
+
+**No revocation.** `inbox.share` cannot be undone.
+
+**Nothing per reader on a document in a public store.** No grant, no revocation, no audience list.
+
+**No delegated writing.** A received key never grants a write, and no call adds a writer to a document.
+
+**No mailbox model.** Do not build on the raw deposit list.
+
+**No cross-broker reference.** A returned reference resolves for users of the same broker.
+
+**No unfiltered read through `useShape`.** Members that yield items are filtered and mutations pass through; anything else throws. A document reached through that view alone, read nowhere else first, does not appear.
+
+## Change policy
+
+This surface changes, and shrinks. The package does not offer semantic-version stability.
+
+Re-pull this contract at every upgrade.

.project/concepts/data-layer/decision_2026-03-13_conditional-ng-init-broker-detection.md

@@ -1,35 +0,0 @@
----
-type: decision
-summary: Décision 2026-03-13 — auto-init NextGraph seulement quand dans l'iframe broker (window.self !== window.top), sinon initNgWeb() redirige la page et casse le dev/démo standalone
----
-
-# Conditional NextGraph Init Based on Broker Iframe Detection
-
-**Date:** 2026-03-13 14:00
-**Status:** Accepted
-
-## Context
-
-`initNgWeb()` de `@ng-org/web` teste `window.self === window.top`. En standalone (hors iframe), il redirige toute la page vers `nextgraph.net/redir/` pour déclencher l'auth broker. Résultat : l'app redirigeait à chaque chargement — même en dev ou quand l'utilisateur n'avait pas cliqué « Se connecter ».
-
-## Options Considered
-
-### Option A: toujours auto-init NG au mount
-- Plus simple (pas de branchement).
-- **Contre** : redirect immédiat vers le broker en standalone ; casse le workflow de dev ; l'utilisateur voit la page de login broker au lieu de l'app.
-
-### Option B: auto-init conditionnel selon détection iframe
-- En iframe, le broker a déjà authentifié → auto-init sûr ; en standalone, l'utilisateur doit cliquer « Se connecter » ; préserve l'expérience démo/dev ; calque la propre logique de détection de `@ng-org/web`.
-- **Contre** : repose sur l'heuristique `window.self !== window.top` (théoriquement faillible si embarqué dans une iframe non-broker).
-
-## Decision
-
-**Option B.** `NextGraphContext` calcule `isInsideBroker = typeof window !== 'undefined' && window.self !== window.top` au niveau module. `useEffect` n'auto-appelle `initNg()` que si `isInsideBroker`. Le callback `connect()` reste disponible pour la connexion explicite. De plus, `FestipodDataContext` rend des données vides (pas le seed) pendant `connecting` pour éviter de flasher le contenu démo.
-
-## Consequences
-
-**Positif :** l'app charge sans rediriger (standalone dev/démo) ; en iframe broker, connexion fluide et automatique ; pas de flash de seed pendant la connexion.
-**Négatif :** aucun significatif.
-**Risque :** si `@ng-org/web` change sa logique de détection, notre garde peut diverger — les garder alignés.
-
-> Règle dérivée : [[rule_conditional-ng-init]].

.project/concepts/data-layer/decision_2026-03-17_private-store-nuri-scope.md

@@ -1,39 +0,0 @@
----
-type: decision
-summary: Décision 2026-03-17 — utiliser private_store_id comme scope useShape ET @graph (calqué sur expense-tracker-rdf) pour que orm_start_graph ouvre le repo et que les écritures ne lèvent plus RepoNotFound
----
-
-# Use private_store_id as useShape scope and @graph
-
-**Date:** 2026-03-17 16:00
-**Status:** Accepted
-
-## Context
-
-Cliquer « Charger données de test » chargeait les données en mémoire (signaux ORM) mais produisait des `RepoNotFound` sur `doc_create` et `orm_frontend_update`. Les données disparaissaient au reload car les écritures SPARQL n'atteignaient jamais le broker. La HashMap `self.repos` du verifier ne contenait pas le repo du private store → `resolve_target()` échouait.
-
-## Options Considered
-
-### Option A: `did:ng:i` scope + `doc_create` pour @graph
-- `did:ng:i` bien documenté comme scope d'abonnement, `doc_create` renvoie un vrai NURI.
-- **Contre** : `did:ng:i` passe par `NuriTargetV0::UserSite` qui n'ouvre pas les repos individuels ; `doc_create` appelle `resolve_target(PrivateStore)` qui exige le repo dans `self.repos` → échoue ; exige une logique de retry/timing complexe.
-
-### Option B: `private_store_id` comme scope ET @graph
-- Calque exact de l'exemple `expense-tracker-rdf` qui fonctionne ; `orm_start_graph` avec le NURI du private store ouvre le repo dans `self.repos` ; les écritures `orm_frontend_update` trouvent ensuite le repo. Simple, sans retry.
-- **Contre** : un peu moins flexible que `did:ng:i` (scopé à un store) ; exige de passer la session à `useShapeWithDefaults`.
-
-### Option C: `did:ng:i` scope + réutiliser le @graph d'une entité existante
-- Marche pour les users qui ont déjà des données.
-- **Contre** : échoue pour les wallets vides (aucune entité à réutiliser) ; retombe sur `doc_create` et le même `RepoNotFound`.
-
-## Decision
-
-**Option B** : `did:ng:${session.private_store_id}` comme scope `useShape` ET `@graph` d'écriture, exactement comme `expense-tracker-rdf`. `useShapeWithDefaults` accepte un `storeNuri` ; `FestipodDataContext.useNgData()` récupère la session via `useNextGraph()` et passe le NURI du private store. `ensureGraphNuri()` simplifié : entités existantes d'abord (optimisation), sinon fallback `private_store`.
-
-## Consequences
-
-**Positif :** écritures immédiates après connexion (sans retry) ; persistance au reload ; aligné sur les exemples officiels ; les 7 scénarios e2e passent (dont la persistance).
-**Négatif :** signature de `useShapeWithDefaults` modifiée (param `storeNuri`).
-**Risque :** si NextGraph change le comportement du private store, ça casse.
-
-> Règle dérivée : [[rule_private-store-scope]]. Décision *remise en cause* par le futur multi-store : [[brief_2026-05-17_multi-store-refactor]].

.project/concepts/data-layer/decision_2026-03-17_sparql-delete-for-orm-objects.md

@@ -1,51 +0,0 @@
----
-type: decision
-summary: Décision 2026-03-17 — supprimer les objets ORM via ng.sparql_update (DELETE WHERE) seul, car ngSet.delete() ne persiste pas et les combiner crée un conflit CRDT
----
-
-# Use SPARQL DELETE instead of ORM ngSet.delete() for object removal
-
-**Date:** 2026-03-17 18:00
-**Status:** ~~Accepted~~ → **Superseded (2026-06-15)**
-
-> **Annulée le 2026-06-15.** Le bug de non-persistance de `ngSet.delete()` qui motivait cette décision a depuis été en grande partie corrigé côté `@ng-org/orm` : le code (`leaveEvent`) est repassé à `ngSet.delete()`. La persistance reste toutefois possiblement partielle — l'état courant et le repli SPARQL sont décrits dans [[caveat_participation-deletion]]. Décision conservée comme mémoire d'arbitrage (le conflit CRDT « ne pas combiner les deux » reste vrai).
-
-## Context
-
-Quitter un event exige de supprimer l'objet `Participation` du store NextGraph. `DeepSignalSet.delete()` met à jour l'état réactif local (UI immédiate) mais **ne persiste pas** au broker — après refresh, la participation réapparaît.
-
-## Options Considered
-
-### Option A: ORM `ngSet.delete(item)`
-- API officielle (README ORM), update réactif local instantané.
-- **Contre** : ne persiste pas en pratique (`delete()` renvoie `true`, set local à jour, mais objet de retour après refresh) ; `graph_orm_update` semble mal gérer les patches "remove" pour objets de set top-level (bug moteur probable) ; échoue silencieusement.
-
-### Option B: `ng.sparql_update()` avec SPARQL DELETE
-- `DELETE WHERE { GRAPH <graph> { <subject> ?p ?o } }` retire tous les triples RDF.
-- **Pour** : persiste (survit au refresh) ; le broker confirme via `GraphOrmUpdate` remove qui retire réactivement l'item du set ORM ; contrôle direct.
-- **Contre** : pas instantané (round-trip SPARQL + callback broker, ~50ms) ; ne doit pas être combiné avec `ngSet.delete()`.
-
-### Option C: les deux ensemble
-- **Ne marche pas** : le patch ORM `.delete()` et le DELETE SPARQL entrent en conflit CRDT → ni UI ni persistance.
-
-## Decision
-
-**Option B : SPARQL DELETE seul.** Le broker renvoie un `GraphOrmUpdate` `op: "remove"` qui retire réactivement l'item du set ORM (UI à jour, juste pas synchrone). **Ne pas** appeler `ngSet.delete()` à côté.
-
-```typescript
-// FestipodDataContext.tsx leaveEvent():
-const session = await sessionPromise;
-await ng.sparql_update(
-  session.session_id,
-  `DELETE WHERE { GRAPH <${partGraph}> { <${partId}> ?p ?o } }`,
-  partGraph,
-);
-```
-
-## Consequences
-
-**Positif :** suppression persistée ; source de vérité unique (broker → ORM → UI).
-**Négatif :** léger délai UI (~50ms) ; diverge des exemples README ORM.
-**Risque :** si `ng.sparql_update` change, ça casse ; toute future suppression doit suivre le même pattern ; revisiter si `ngSet.delete()` est corrigé en montée de version.
-
-> État courant (la règle a été retirée) : [[caveat_participation-deletion]].

.project/concepts/data-layer/knowledge_context-internals.md

@@ -1,30 +1,94 @@
 ---
 type: knowledge
-summary: Pièges internes de FestipodDataContext — currentUser NG résolu par username '@mariedupont' (fallback users[0]), auto-seed dev-only après 3s sans retry, participantCount muté en place (cache), currentUserId vide → IRI invalide, mutations no-op en mode local malgré le toast
-last_checked: 2026-06-15
+summary: Internal pitfalls of FestipodDataContext — currentUserId is the profile document read back in the protected scope (empty until it lands), the legacy principal space resolveParticipantUser still resolves on read, OPT-IN auto-seed, owner-derived participantCount, local-mode no-op mutations
+last_checked: 2026-08-10
 ---
 
-# Internals & pièges de `FestipodDataContext`
+# Internals & pitfalls of `FestipodDataContext`
 
-Comportements non évidents de `src/shared/context/FestipodDataContext.tsx` à connaître avant de toucher au contexte de données.
+Non-obvious behaviours of `src/shared/context/FestipodDataContext.tsx` to know about before touching the data context.
 
-## Résolution du `currentUser` (mode NG)
+## Who am I — `currentUserId` is a document you read back, not a value you were given
 
-En mode connected, le currentUser n'est **pas** `CURRENT_USER_ID` ('user-1', qui ne vaut qu'en mode local). Il est résolu par **`users.find(u => u.username === '@mariedupont') || users[0]`** (vers ligne 286). Pièges :
-- **Fallback silencieux** sur `users[0]` si `@mariedupont` absent → currentUser arbitraire.
-- Si le wallet est **vide** (`users.length === 0`), `currentUserId` devient `''` → toute `Participation` créée a un `user: ''` (**IRI invalide**), sans alerte. Bug silencieux possible à la première connexion sur un wallet vierge.
-- L'IRI du currentUser diffère entre mode local (ID de seed statique) et mode NG (IRI NextGraph dynamique) — ne pas comparer les deux.
+**The app names no identity of its own** (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]): `ensureIdentity()` takes nothing, and nothing switches identity afterwards. So the provider cannot *derive* a principal from an input. What the current user **is**, is the **profile document it reads back in its own protected scope**: `currentUserId` = that profile's `@id`, a doc NURI — the very same value as `currentUser?.id`.
 
-## Auto-seed de dev
+**The pitfall that follows**: it is **empty until the protected read lands**, and empty is an ordinary string that raises nothing. Mutations needing it **refuse** (`joinEvent` logs `empty user principal — refusing to write a participation with no fp:user` rather than writing an entity that would be dropped on read); queries keyed on it return **empty results** that render as "you have nothing". Treat `''` as *not ready*, never as *no data* — see `app-architecture`, [[caveat_identity-ids-in-screens]].
 
-Un auto-seed se déclenche (vers lignes 263-283) **uniquement hors production** (`process.env.NODE_ENV !== 'production'`), après un **`setTimeout` de ~3s**, si les sets events ET users sont vides. Pièges :
-- **Pas de retry** : `hasTriedAutoSeed` (useRef) est posé une fois ; si le seed échoue, jamais réessayé (écran vide, juste un `console.error`).
-- Le délai de 3s est **heuristique** : si l'hydratation ORM est lente, le seed peut partir alors que des données arrivent.
+> The `currentUser` object is picked with a **fallback** (`@mariedupont`, then `users[0]`) — a leftover of the demo seed, and a silent one: on a wallet holding several profiles it can settle on the wrong person. Worth a look whenever "the app thinks I am someone else".
 
-## `participantCount` muté en place
+## The legacy principal space — resolved on READ only
 
-`joinEvent`/`leaveEvent`/`updateEvent` **mutent directement** `ngEvent.participantCount` (`+1`/`-1`) — c'est un **cache** du nombre de `Participation`, pas une valeur recalculée. Il peut **désynchroniser** des objets `Participation` réels (ex. après un crash, un rejeu, ou la suppression partielle décrite dans [[caveat_participation-deletion]]). Ne pas s'y fier comme source de vérité du nombre de participants.
+A `Participation` written **today** carries `currentUserId` in `fp:user`, i.e. a profile doc NURI, so a direct `participation.userId === profile.id` join matches. Participations written under the **earlier** scheme carry a principal of the form `urn:festipod:user:<normalized-handle>`, which matches nothing directly.
 
-## Mutations no-op en mode local
+**`resolveParticipantUser`** (`FestipodDataContext`) is the single join point, and it tries, in order: (1) a **direct match** `u.id === userId` — today's writes, and the demo seed's bare `user-1` space; (2) failing that, strip `USER_PRINCIPAL_PREFIX` and match the remainder against `normalizeIdentifier(profile.username)` — the legacy space. Never join by direct comparison at a call site: the symptom of getting it wrong is every participant rendering as « participant inconnu », which shipped once already.
 
-En mode local/demo (`useLocalData`), `createEvent`/`joinEvent`/`leaveEvent`/`updateEvent` sont des **no-ops** (`console.log`, l'état ne change pas) — mais les écrans affichent quand même un **toast de succès** (« Tu participes »). UX potentiellement trompeuse : l'utilisateur croit s'être inscrit alors que rien n'a changé. Voir [[knowledge_data-modes]] pour le choix du provider selon le statut.
+`USER_PRINCIPAL_PREFIX` is now **read-side only** — nothing mints it any more. It is kept so old data still resolves; it is not a shape to write against.
+
+A further id space takes **no** part in this join: the inbox deposit `uid` (`mint…`) — it identifies a **deposit** for the counter, never a user.
+
+> **Horizon.** This paragraph describes **what is implemented**. The target model drops the plaintext `userId` and routes identity resolution through **reading the profile** — see [[brief_2026-07-20_attendance-set-model]], whose implementation is gated. The id-space fix is explicitly noted there as **still valid**: do not undo it in anticipation of the target.
+
+### Which space each query expects (the `buildQueries` contract)
+
+| Query | What it expects / returns |
+|---|---|
+| `getUserEvents(userId)`, `isParticipating(eventId, userId?)`, `getFriends(userId?)` | filter on `participation.userId` / `friendship.userId`; their default is `currentUserId`, which is correct |
+| `getEventParticipants(eventId)` | **returns profiles** (`FpUserData` → `id` = NURI), the join being done internally |
+
+**Screen-side impact**: `currentUserId` and `currentUser?.id` are now the same value, so filtering yourself out of a participant list works either way. What still bites is passing an id **before it resolves** — see `app-architecture`, [[caveat_identity-ids-in-screens]].
+
+## Reads = `watchShape` (the SDK surface), no more bespoke machinery
+
+**Since 2026-07-10**: `useNgData` reads through `useShapeQuery(shape, scope)` (a `useSyncExternalStore` binding over `watchShape`) — THREE useQuery-shaped reads (events/public, users/protected, participations/protected) + Fp adapters (`shapeAdapters.ts`). Removed: `readEntities`, `subscribeDocs`+`bumpRead`+`readTick`, the manual listing (`publicDocs`/`protectedDocs`/`registerDoc` for reads), and `relist`. `ready` = the combination of the `isSuccess` flags. See [[rule_app-uses-sdk-surface-only]].
+
+**Immediate visibility of mutations = an OPTIMISTIC overlay** (no `registerDoc`): `createEvent`/`joinEvent`/`leaveEvent` feed `pendingAddEvents`/`pendingAddParticipations`/`pendingRemoveIds`; the exposed state = merge(reactive, adds) minus removes, deduped by id (id = the doc's NURI). Reconciliation happens automatically on push (an add that shows up in the reactive state, or a remove that disappears from it, is dropped) — never a poll ([[rule_no-broker-polling]]).
+
+## Dev auto-seed
+
+**Since 2026-07-13 the auto-seed is OPT-IN and OFF by default**: it only fires if the `FESTIPOD_AUTO_SEED` env var is set (`=1`), no longer off `NODE_ENV`. Var absent → **no automatic seed at all**, even in dev (`autoSeedEnabled()`/`shouldAutoSeed()`, `src/shared/utils/autoSeed.ts`; delivered in dev through the `/festipod-config.json` runtime route + a compile-time `define` in `build.ts`, the same mechanism as the shared wallet — see `tech-stack/knowledge_build-pipeline`). The **explicit** seed (`loadTestData()`, @data tests) is unchanged. Rationale: the repeated auto-seed was bloating the wallet (slow reads, see [[caveat_wallet-bloat-hang]]).
+
+When it is enabled, the auto-seed fires if events AND users are both empty — **gated on `isSuccess`** (`watchShape`'s readiness), NO LONGER on a 3s `setTimeout`: we only decide "the wallet is empty" once the sync is **confirmed** (`isSuccess`), otherwise a not-yet-finished read was taken for an empty wallet → a re-seed on every reconnection (bug fixed). Remaining pitfalls:
+- **One seed at a time**: `loadTestData()` sets `hasTriedAutoSeed`, and the auto-seed re-checks it → an explicit load cancels the pending auto-seed (otherwise two concurrent `bootstrapWallet` calls write everything twice).
+- The seed writes under the **connected session**, so the session that seeds **holds** what it seeded and its protected fixtures round-trip. Seeded users are fixtures, not accounts — nobody has signed in as them, which matters because `inbox.share` refuses a recipient nobody has ever been. Only **events** get an inbox opened at seed time (`openDocumentInbox`), because events are what people deposit into.
+- **No retry**: if the seed fails, you get an empty screen + a `console.error`.
+
+## `participantCount` — derived and owned by the owner
+
+> ✅ **CORRECTED (2026-07-13).** The requirement is **"reliable at the owner's NEXT CONNECTION"** (the creator processes their inbox when they connect), NOT a live real-time cross-user notification. The bug was: the owner-materializer materialized **too early** (before the participant's deposit had synced) → read `active=0` → wrote 0 → **memoized that 0** → never re-processed. Fix: (1) read through `inbox.readSynced` instead of `inbox.read` — the two differ by contract, and only the former is the synced view ([[contract_polyfill-surface]]); (2) the materializer fires **directly on connection** (`[ready, ownedKey]`), no longer only on a push; (3) `materializedCountRef` no longer locks in a premature 0 (its sole role = loop guard: only write when the derived value changes); (4) **the single source of the NUMBER = `event.participantCount`** (the `participantCount: 1` literal in `CreateEventScreen` is removed → it starts at 0; the display no longer computes a local number). Kept GREEN (on a fresh profile) by `event/e2e-multibrowser.feature` « Le compteur converge chez le propriétaire à sa prochaine connexion » (un-`@wip`'d). No polling ([[rule_no-broker-polling]]).
+
+**Since 2026-07-07**: `participantCount` is no longer mutated in place by the participant. The flow is inbox-deposit → owner-materialization:
+- `joinEvent`/`leaveEvent` **no longer** write `participantCount` on the event's doc — **only a document's owner writes to it**, so a participant cannot touch someone else's. The participant only writes their **own** participation doc (protected), then **deposits** a marker into the event's inbox (`depositRegistration` on join, `depositLeave` on leave, `src/shared/data/registration.ts`).
+- The event **owner's** session does the materializing: it watches (`inbox.watch`, no polling) the inbox of the events it owns (`ownedEventIds` = `listMyEntityDocs('public')` + freshly created events), and on every deposit it **recomputes** `participantCount` on **its own** event doc (`updateEntityField` on its own doc). It is the counter's only writer.
+- **The counter is DERIVED, not incremented**: `materializeAttendance` (registration.ts) reads the inbox and computes the **set** of distinct active sign-ups (`new-participant` deposits deduped by `uid`, MINUS those cancelled by a `leave-participant` — by exact `regUid` or by the `(eventId, userId)` fallback). `participantCount = |active set|` — **no host baseline**: the creator does not attend automatically (there is no notion of host, see concept `functional-domain`), so the counter starts at **0** on creation and only moves on real sign-ups. `createEvent` **no longer writes** a participation at creation time (it used to write a host participation and set the counter to 1); the creator sees « J'y serai » and can join/leave their own event like anyone else. Because it is a **pure function of the inbox**, a replay converges — never double-counting nor a phantom decrement (idempotence). The write is guarded (it only writes when the value changes), a loop guard. Covered by the `@data` scenario « Le créateur ne participe pas automatiquement à son événement » (us-13): counter 0 + `isParticipating(E)===false` at creation, then join→true / leave→false.
+- **Owner offline = eventual**: only the owner's session materializes; while they are disconnected, the counter does not move for anyone else (the participations and deposits stay persisted — nothing is lost).
+- The counter nevertheless remains an **aggregate**, not the list of named participants: `getEventParticipants` (named identity) is still governed by what the protected scope hands back ([[caveat_participation-deletion]] for the authoritative deletion, unchanged).
+
+### Id-form invariant: match on the CANONICAL form of the event id
+
+An event's `@id` **is** its document NURI (`did:ng:o:<repo>[:v:<overlay>]`). The owner's materializer matches the inbox **deposits** to the owned events **by event id**: `ownedEventIds` (what the materializer iterates over), the **deposit key** (`payload.eventId`, what the participant deposits under) and the counter's **write target** must all designate the same event.
+
+**Measured finding (2026-07-07)**: on the current tree these three paths carry the **same** NURI (the `:v:<overlay>` suffix included) — create-time, `listMyEntityDocs` and the `@id` read back all coincide, because `readUnion` **pins the subject to the input NURI** (lib `read-model.ts`, `63ecfee`). So matching already works, **including** for an owned event reached through `listMyEntityDocs` (validated by the @data scenario « …fait converger le compteur dérivé »). The canonicalization below is **defensive**, not the fix for an active bug. (The mismatch one investigation thought it had seen was the **seeded-but-not-owned** artifact: on a persistent wallet, the seed belonged to a `test-*` identity from an earlier run → the current session reaches it through discovery, not through `ownedEventIds` — correct behaviour.)
+
+**Rule**: match the event id on its **canonical form** — the base repo id, with any `:v:<overlay>` suffix stripped (`canonicalEventId`, `src/shared/data/registration.ts`). This canonical form is used for **matching** in `materializeAttendance` / `readRegistrationNotifications`, and for **deduplicating** `ownedEventIds` (`ownedKey`, FestipodDataContext) so that one and the same event reached through two paths is not materialized twice. **Careful**: only the **matching** uses the stripped form; the counter is always **written** to the real owned NURI (a live, openable doc) — a stripped id must never serve as a write target or an anchor. This is an **app-side** invariant (not a NextGraph detail): however the lib makes the overlay vary, the app matches on the common base.
+
+## There is no identity switch any more
+
+The app settles its identity **once**, before anything renders (`ensureIdentity()` in `AuthGate`), and offers no way to change it — the surface stopped publishing one (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]). So the provider carries **no identity-change reset**: no `useEffect([identifier])`, no cap reset, no registry-cache reset. Those symbols are gone; do not reintroduce a reset for a transition that cannot happen.
+
+> **Why there is nothing left to reset.** An identity-change reset only made sense while a single React tree could outlive a change of identity. It cannot: one page hosts exactly one identity for its whole life, so session state (the read set, the optimistic overlay, the owner-materializer's doc set) has no second identity to leak into.
+>
+> The **cross-identity isolation** behaviour is still a real Festipod requirement, but proving it needs **two genuinely separate browser contexts**, each signing in for itself. `event/isolation-deux-identites.feature` is `@wip` for exactly that reason (concept `bdd-testing`, [[rule_tests-validate-festipod-not-the-sdk]]).
+
+## `useShapeQuery` instrumentation — global spinner + timing
+
+`useShapeQuery` (a `useSyncExternalStore` binding over `watchShape`) instruments **every query cycle**: at the start of a cycle it registers itself in a module-level store `src/shared/data/pendingQueries.ts` (`beginQuery`/`resolveQuery`, a Set of ids — idempotent, safe under StrictMode), and on the first `isPending → isSuccess|isError` transition (the "first result", the readPromise equivalent) it resolves AND logs the delay: `[FestipodData] <shape>/<scope> premier résultat en <N>ms (n=<len>)` (so the delay for Event/public events is visible by name). The `cycleId` is memoized on `[shapeKey, scope]` → an identity/scope switch recreates the observable AND starts a new cycle (a fresh `beginQuery`), and the cleanup resolves on unmount (never stuck). The `usePendingQueries()` hook exposes the number of pending queries; `HomeScreen` renders a `Spinner` (sketchy, `.app-spinner` + `@keyframes app-spin` in `index.css`) next to the « Festipod » title as long as the count is > 0 → it only stops once **all** in-flight queries have received their first result. Any future `useShapeQuery` contributes to it automatically. The measurement lives on the app side (React-perceived delay), **not** in the polyfill.
+
+## Logging convention — identity-first prefix, and counter before→after
+
+Every DATA log from the provider goes through **`logPrefix`**: `[<currentUserId>][app][data]` when the principal is resolved, `[app][data]` otherwise (a transient connection state). Reason: a run often drives **several sessions at once** (two tabs, a multi-browser scenario) and their lines end up read side by side — an unprefixed line does not say *whose* it is and becomes useless for diagnosing a leak or a stuck counter. **Adding a DATA log = reusing `logPrefix`**, not a bare `console.log`.
+
+Two measurement points are laid down **as a pair** and serve together: the owner's materializer logs `participantCount` **before → after** its write, and the display read logs the value **as exposed to the render**. Comparing them tells a stuck counter apart between a **DATA** problem (never incremented) and a **DISPLAY** problem (incremented but not re-read until the next session). Do not remove one without the other — on their own they diagnose nothing.
+
+## Mutations are no-ops in local mode
+
+In local/demo mode (`useLocalData`), `createEvent`/`joinEvent`/`leaveEvent`/`updateEvent` are **no-ops** (a `console.log`, the state does not change) — yet the screens still show a **success toast** (« Tu participes »). Potentially misleading UX: the user believes they signed up when nothing has changed. See [[knowledge_data-modes]] for how the provider is chosen based on status.

.project/concepts/data-layer/knowledge_data-modes.md

@@ -1,29 +1,28 @@
 ---
 type: knowledge
-summary: Deux modes (connected = NextGraph ORM, disconnected/demo = état local seedé) ; FestipodDataContext choisit le provider selon le statut NextGraphContext, tous les écrans passent par useFestipodData()
+summary: Two modes (connected = the @ng-eventually/polyfill SDK, disconnected/demo = seeded local state); FestipodDataContext picks the provider based on connection status, and every screen goes through useFestipodData()
 ---
 
-# Modes de données & contextes
+# Data modes & contexts
 
-L'app a **deux modes**, tous deux consommés via le hook `useFestipodData()` :
+The app has **two modes**, both consumed through the `useFestipodData()` hook:
 
-1. **Connected** — shapes ORM NextGraph (P2P, chiffré, local-first)
-2. **Disconnected / Demo** — état React local seedé depuis `seedData.ts` (voir [[knowledge_seed-data]])
+1. **Connected** — ORM shapes from the `@ng-eventually/polyfill` SDK (P2P, encrypted, local-first)
+2. **Disconnected / Demo** — local React state seeded from `seedData.ts` (see [[knowledge_seed-data]])
 
 ## NextGraphContext (`src/shared/context/NextGraphContext.tsx`)
 
-- Cycle de connexion : `disconnected` → `connecting` → `connected` | `error`.
-- Fournit la session avec les IDs de stores (private, protected, public).
-- **Auto-init conditionnel** : voir [[rule_conditional-ng-init]] (n'auto-initialise que dans l'iframe broker).
+- Connection cycle: `disconnected` → `connecting` → `connected` | `error`.
+- That status is what the data provider below keys on; the app holds no session of its own.
 
 ## FestipodDataContext (`src/shared/context/FestipodDataContext.tsx`)
 
-- Enveloppe les shapes via `useShapeWithDefaults()`.
-- Expose `useFestipodData()` (consommé par tous les écrans) + CRUD (`createEvent`, `updateEvent`, etc.).
-- **Provider selon le statut NG** :
-  - `disconnected` → `LocalDataProvider` avec seed (démo)
-  - `connecting` → `LocalDataProvider` **vide** (évite de flasher le seed avant le chargement du wallet)
-  - `connected` → `NgDataProvider` (données réelles du wallet)
-  - `error` → `LocalDataProvider` avec seed (fallback gracieux)
+- Reads the shapes reactively through **`useShapeQuery()`** (`src/shared/data/useShapeQuery.ts`), the app's React binding over the SDK's `watchShape(shape, scope)` observable — three scoped reads: events (`public`), profiles and participations (`protected`), mapped to the `Fp*` domain types by `shapeAdapters.ts` (see [[rule_document-per-entity]] §Reads). There is no `useShapeWithDefaults` — that name is obsolete (verified 2026-07-28).
+- Exposes `useFestipodData()` (consumed by every screen) + CRUD (`createEvent`, `updateEvent`, `joinEvent`, `leaveEvent`, etc.).
+- **Provider chosen by connection status**:
+  - `disconnected` → `LocalDataProvider` with the seed (demo)
+  - `connecting` → an **empty** `LocalDataProvider` (avoids flashing the seed before the wallet loads)
+  - `connected` → `NgDataProvider` (real wallet data)
+  - `error` → `LocalDataProvider` with the seed (graceful fallback)
 
-> Réserve : certaines mutations (`joinEvent`/`leaveEvent`) sont encore des **no-ops** (`console.log`) en attendant le chantier données — cf. [[brief_2026-05-21_fork-nextgraph-inbox]] §Couche 3.
+> Mutations are **genuinely persisted** in connected mode (`joinEvent` writes a Participation and notifies the meeting point's host, `leaveEvent` deletes authoritatively — see [[caveat_participation-deletion]]). In local/demo mode they are no-ops (see [[knowledge_context-internals]]).

.project/concepts/data-layer/knowledge_entities.md

@@ -1,20 +1,24 @@
 ---
 type: knowledge
-summary: Types de données Fp* (Event, UserProfile, Participation persistés NextGraph ; MeetingPoint et Friendship encore local-only)
+summary: The Fp* data types — Event, UserProfile, Participation, MeetingPoint and Notification are persisted in NextGraph (SHEX shapes + ORM); only Friendship stays local-only (app-TS)
+last_checked: 2026-07-03
 ---
 
-# Entités de données
+# Data entities
 
-`src/shared/data/types.ts` :
+`src/shared/data/types.ts`:
 
-| Type | Persistance | Champs clés |
+| Type | Persistence | Key fields |
 |---|---|---|
-| `FpEventData` | NextGraph (shape Event) | id, title, date, location, distance, themes |
-| `FpUserData` | NextGraph (shape UserProfile) | id, name, username, bio, city, counts |
-| `FpParticipationData` | NextGraph (shape Participation) | eventId + userId + confirmed |
-| `FpMeetingPointData` | **local-only** | eventId, location, time, host |
+| `FpEventData` | SDK (Event shape) | id, title, date, location, distance, themes |
+| `FpUserData` | SDK (UserProfile shape) | id, name, username, bio, city, counts |
+| `FpParticipationData` | SDK (Participation shape) | eventId + userId + confirmed |
+| `FpMeetingPointData` | SDK (MeetingPoint shape) | eventId, location, time, host |
+| `FpNotificationData` | SDK (Notification shape) | kind, target, source |
 | `FpFriendshipData` | **local-only** | userId + friendId |
 
-`MeetingPoint` et `Friendship` n'ont **pas encore de shape SHEX** ni de persistance NextGraph (cf. [[knowledge_nextgraph-stack]]). Les brancher au store est un prérequis du multi-user — voir les briefs du concept `nextgraph-platform`.
+`MeetingPoint` and `Notification` do have real **SHEX shapes** (`src/shared/shapes/shex/festipodShapes.shex`) with generated ORM bindings (`festipodShapes.shapeTypes.ts`: `FpMeetingPointShapeType`, `FpNotificationShapeType`) and **are persisted**. A `Notification` is created in particular when signing up to a meeting point (`joinEvent`).
 
-> Piège : même pour `FpEvent` (persisté), plusieurs champs du type app ne sont **pas** dans la shape et sont perdus en connecté — voir [[caveat_event-fields-not-persisted]].
+`Friendship` has **no** SHEX shape and no persistence — it stays app-TS-only (see [[knowledge_nextgraph-stack]]).
+
+> Pitfall: even for `FpEvent` (which is persisted), several fields of the app type are **not** in the shape and are lost when connected — see [[caveat_event-fields-not-persisted]].

.project/concepts/data-layer/knowledge_nextgraph-stack.md

@@ -1,26 +1,30 @@
 ---
 type: knowledge
-summary: Paquets @ng-org/* (web, orm, shex-orm, alien-deepsignals), shapes SHEX festipodShapes, bindings ORM générés, régénérés via build:orm
+summary: The data SDK is @ng-eventually/polyfill, injected exactly once through ngSession.configure; reads go through the reactive useShape/watchShape surface over the festipodShapes SHEX shapes, whose ORM bindings are regenerated with build:orm
 ---
 
-# Stack NextGraph (côté app)
+# Data stack (SHEX shapes over the `@ng-eventually/polyfill` surface)
 
-```
-@ng-org/web                # Runtime navigateur (proxy postMessage vers l'iframe)
-@ng-org/orm                # ORM réactif basé sur les shapes RDF (useShape…)
-@ng-org/shex-orm           # Génération SHEX → TypeScript
-@ng-org/alien-deepsignals  # Pont de signaux réactifs
-```
+Festipod persists through **`@ng-eventually/polyfill`**. What that surface offers, and what it refuses to promise, is written down in one place: [[contract_polyfill-surface]], pulled into this repo and version-pinned. See [[rule_app-uses-sdk-surface-only]].
 
-Installés depuis npm (`@ng-org/*`, versions alpha). Pour développer contre un build local non publié de `nextgraph-rs`, `scripts/build-ng-packages.sh` pack le monorepo en tarballs et repointe `package.json` (cf. `nextgraph-platform` — le pattern d'origine du projet, réactivable pour un fork).
+## SDK boundary (the golden rule)
 
-## Shapes SHEX
+- The app **depends on `@ng-eventually/polyfill` only** for data.
+- It is **initialized/injected exactly once** through `ngSession.configure(...)` (`src/shared/utils/ngSession.ts`) — a single injection point. Everything else in the app (data plane, lifecycle, login, types) goes through it.
+- **Never describe here how the data layer is implemented underneath.** This concept covers only **how Festipod uses the surface**.
 
-`src/shared/shapes/shex/festipodShapes.shex` définit :
-- **Event** — titre, description, dates, lieu, thèmes, participants
-- **UserProfile** — nom, username, bio, ville, visibilité
-- **Participation** — lie event + user, statut de confirmation
+## ORM & SHEX shapes
 
-Bindings ORM dans `src/shared/shapes/orm/` (`*.schema.ts`, `*.shapeTypes.ts`, `*.typings.ts`). **Régénérer** avec `bun run build:orm` après toute modif `.shex`.
+The reactive ORM (`useShape`) is built on **SHEX shapes**: `src/shared/shapes/shex/festipodShapes.shex` defines:
 
-> Manque côté shapes : **pas de `MeetingPoint`** ni d'entité notification — le point de rencontre est aujourd'hui local-only côté types (voir [[knowledge_entities]]). Leur modélisation est un chantier de [[brief_2026-05-21_fork-nextgraph-inbox]].
+- **Event** — title, description, dates, location, themes, participants
+- **UserProfile** — name, username, bio, city, visibility
+- **Participation** — links an event and a user, confirmation status
+- **MeetingPoint** — a meeting point (location, time, host)
+- **Notification** — a notification (created in particular when signing up to a meeting point)
+
+The ORM bindings are generated in `src/shared/shapes/orm/` (`*.schema.ts`, `*.shapeTypes.ts`, `*.typings.ts`). **Regenerate** with `bun run build:orm` after any `.shex` change.
+
+> **The canonical way to read is the reactive hook.** `useShape`/`watchShape`: you subscribe to a shape on a scope, you get the current value, and the component re-renders on every change — subscription/push, never polling; one-shot reads are the exception. The read/reactivity contract is [[contract_polyfill-surface]] and nothing else.
+
+> `Friendship` has **no** SHEX shape and no persistence — it stays app-TS-only (see [[knowledge_entities]]).

.project/concepts/data-layer/knowledge_seed-data.md

@@ -1,17 +1,17 @@
 ---
 type: knowledge
-summary: seedData.ts fournit des fixtures déterministes (10 users, events, participations) avec CURRENT_USER_ID = 'user-1' (Marie Dupont) ; utilisé en mode démo et par les tests @ui
+summary: seedData.ts provides deterministic fixtures (10 users, events, participations) with CURRENT_USER_ID = 'user-1' (Marie Dupont); used in demo mode and by the @ui tests
 ---
 
 # Seed data
 
-`src/shared/data/seedData.ts` fournit des fixtures **déterministes** :
+`src/shared/data/seedData.ts` provides **deterministic** fixtures:
 
-- 10 users — **Marie Dupont = utilisateur courant**, `user-1`
-- Plusieurs events (dates, lieux, thèmes)
+- 10 users — **Marie Dupont = the current user**, `user-1`
+- Several events (dates, locations, themes)
 - Participations, meeting points, friendships
 - `CURRENT_USER_ID = 'user-1'`
 
-Ces fixtures servent (a) le **mode démo** (`LocalDataProvider`, cf. [[knowledge_data-modes]]) et (b) les tests **`@ui`** qui rendent les écrans avec ces données prévisibles (`Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` existe, etc. — voir concept `bdd-testing`).
+These fixtures serve (a) **demo mode** (`LocalDataProvider`, see [[knowledge_data-modes]]) and (b) the **`@ui`** tests, which render the screens against this predictable data (`Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` exists, etc. — see concept `bdd-testing`).
 
-> `bootstrapWallet()` (`src/shared/utils/ngBootstrap.ts`) seede ces données dans le wallet NG en mode connected — déclenché uniquement par action explicite de l'utilisateur (« Charger données de test »). Sa refonte par documents/périmètres est un point des briefs `nextgraph-platform`.
+> `bootstrapWallet()` (`src/shared/utils/ngBootstrap.ts`) seeds this data into the wallet in connected mode — triggered only by an explicit user action (« Charger données de test »).

.project/concepts/data-layer/rule_app-uses-sdk-surface-only.md

@@ -0,0 +1,25 @@
+---
+type: rule
+summary: The app codes against the engagement the provider publishes — [[contract_polyfill-surface]], pulled into this repo and version-pinned — and that copy is the ONLY reference. Never open the provider's sources or its node_modules copy; never describe or reason about how the data layer is implemented; what the contract does not answer is a GAP, raised with the provider and never worked around here.
+---
+
+# The app uses the published surface only
+
+## The rule
+
+Festipod is a consumer of **one published contract** and is entirely ignorant of how it is honoured.
+
+1. **The pulled contract is the only reference.** [[contract_polyfill-surface]] is the provider's engagement, version-pinned in this repo. An agent working here reads that file and **never opens the provider's repo or its `node_modules` copy** — not to check a signature, not to settle a doubt.
+2. **What the contract does not answer is a gap.** Raise it with the provider and leave the app's call site as it is. An app-side workaround is a doctrine violation *even when it works*, because it hard-codes a passing state into code meant to outlive it.
+3. **No description of how the data layer works underneath**, in code, in comments or in this repo's doctrine. Nothing of the form "we do X because a read behaves like Y". From the app's point of view there is only the contract and what it promises.
+4. **No shortcut, in the app or in its tests.** Deep imports into the package are refused by its `exports` map, and that refusal is correct — see [[rule_tests-validate-festipod-not-the-sdk]].
+
+## The surface shrinks, and that is normal
+
+The contract's own change policy states that this surface **changes, and shrinks**, and that it must be re-pulled at every upgrade. A removal is therefore never a regression to absorb defensively — it is work the app deletes.
+
+## What the app reads through
+
+Reactive reads go through `useShapeQuery` (a `useSyncExternalStore` binding over `watchShape`) plus the Fp adapters in `src/shared/data/`. The app mounts no reactivity of its own and keeps no bespoke read model.
+
+What the app **does** rely on is the distinction the observable carries: `isPending` (sync in progress) is not the same as `isSuccess` with empty `data` (synced and genuinely empty). Code that needs "is it really empty?" — the auto-seed gate, the `ready` flag — uses that distinction and nothing finer.

.project/concepts/data-layer/rule_conditional-ng-init.md

@@ -1,14 +0,0 @@
----
-type: rule
-summary: N'auto-initialiser NextGraph que dans l'iframe broker (window.self !== window.top) ; en standalone, initNgWeb() redirige toute la page — attendre un connect() explicite
----
-
-# Règle : auto-init NextGraph seulement dans l'iframe broker
-
-`initNgWeb()` de `@ng-org/web` teste `window.self === window.top`. **Hors iframe** (app standalone), il **redirige toute la page** vers `nextgraph.net/redir/` pour déclencher l'auth broker.
-
-Donc `NextGraphContext` calcule `isInsideBroker = window.self !== window.top` et **n'auto-appelle `initNg()` que si `isInsideBroker`**. En standalone, la connexion attend un `connect()` explicite (clic « Se connecter ») — sinon l'app redirige à chaque chargement et casse le dev/démo.
-
-De plus, `FestipodDataContext` rend des données **vides** (pas le seed) pendant la phase `connecting`, pour éviter de flasher du contenu démo avant le chargement du wallet (voir [[knowledge_data-modes]]).
-
-> Garder ce garde **aligné** sur la détection interne de `@ng-org/web` : si leur heuristique change, le nôtre doit suivre. Pourquoi + alternatives : [[decision_2026-03-13_conditional-ng-init-broker-detection]].

.project/concepts/data-layer/rule_document-per-entity.md

@@ -0,0 +1,49 @@
+---
+type: rule
+summary: Festipod persists EVERY entity as ITS OWN document (through the SDK), placed in its scope — never several entities in a store-level document. The document is the unit of sharing and of rights: access is granted PER DOCUMENT, so one document per entity is what makes it possible.
+---
+
+# Rule: one document per entity (never at store level)
+
+When Festipod creates an entity (event, meeting point, profile, participation, notification), it writes it as **its own document**, through the surface's "create a document" call ([[knowledge_nextgraph-stack]]), stating its **scope** (`public` / `protected` / `private`). The entity is then read from and written to **that** document.
+
+**Never** write several entities into a shared "store-level" document (e.g. putting everything into a single root document). That is an anti-pattern that breaks isolation.
+
+## Why
+
+The **document is the unit of sharing and of rights**: the contract states that **access is granted per document**. `private` → the owner; `protected` → the owner + their connections; `public` → everyone. That discrimination is possible **only if each entity has its own document**: putting several entities (or worse, several owners) into a single document makes sharing all-or-nothing and defeats scope-based isolation.
+
+Isolation itself is **entirely the surface's business** ([[knowledge_trust-model]] in the `app-security` concept) — the app carries no access logic; it declares **no identity at all**, only which of its own documents it shares with whom, then trusts whatever it gets back. The "one document per entity" granularity is the write-side counterpart of that trust.
+
+## How to apply it
+
+- At creation time: ask the SDK for **a document for the entity, in its scope** — `createEntityDoc(scope)`. Placement is named by **scope alone** — the session belongs to one user, so there is no identity to pass, and a creation that cannot be recorded **throws** rather than handing back a reference that would read empty forever. Write the entity into it. Do not reuse a document from another scope, nor a store-level document.
+- **A document only HAS an inbox if its owner opened one** (`openDocumentInbox(doc)`). Festipod opens one on the documents meant to **receive** deposits — its **events** — not on every entity. A deposit then **names the document**: `inbox.postToDocument(doc, …)`, never an address the app resolved itself.
+- For reads: go through the **reactive shape surface** (see below) — the app names a SHEX shape and a **logical scope**, and the surface resolves that scope to the documents to read, synchronizes them and pushes changes. No NURI resolution, no document listing and no query written on the app side.
+- The *entity → scope* mapping (event/meeting point → public, network profile/participation → protected, settings → private) is a product fact (concept `functional-domain`, [[knowledge_data-scopes-and-discovery]]).
+
+## Reads: the SDK's reactive shape surface (`watchShape` / `useShapeQuery`)
+
+**Reads go through the SDK surface only** ([[rule_app-uses-sdk-surface-only]]). The app names a shape and a scope, and gets a live, `useQuery`-shaped result back:
+
+1. `watchShape(shapeType, scope)` returns an **observable** — `{ data, isPending, isSuccess, isError }` — which resolves the scope itself and **pushes** on every change. `data` is always an array; a synced-but-empty scope reads `{ data: [], isPending: false, isSuccess: true }`, which is what distinguishes "still syncing" from "genuinely empty".
+2. `useShapeQuery(shapeType, scope)` (`src/shared/data/useShapeQuery.ts`) is the app's **only** React binding over it (`useSyncExternalStore`), memoized per (shape, scope) so the underlying document subscriptions are not churned on every render.
+3. `FestipodDataContext` mounts exactly three of them — events (`public`), profiles (`protected`), participations (`protected`) — and maps the returned `UnionSubject` property bags onto the app's `Fp*` domain types through `src/shared/data/shapeAdapters.ts`.
+
+**The app resolves, lists, registers and re-queries nothing.** There is no app-side document set, no manual re-read signal and no per-document subscription: reactivity is the surface's own push. The single app-side layer laid over the read is a **pure optimistic overlay** (`pendingAdd*` / `pendingRemoveIds` in `FestipodDataContext`), auto-reconciled the moment the reactive set catches up — it hides push latency, it is not a read path.
+
+> **Removed (verified 2026-07-28).** An earlier version of this rule described reads as a bespoke union model: an on-demand document set (`publicDocs`/`protectedDocs` fed by `listMyEntityDocs` + `registerDoc`), a one-shot `readEntities` → `readModel.readUnion`, and a manual re-query signal (`bumpRead`/`readTick`). **None of those read symbols exist in `src/` any more** — `src/shared/data/readEntities.ts` is gone, and the surviving mentions are historical code comments. Do not code against them ([[rule_app-uses-sdk-surface-only]]).
+
+## Direct writes (the round-trip pitfall)
+
+**Writing** an entity happens **directly into its own document** (through the surface's SPARQL call — `src/shared/data/entityWrites.ts`, `writeEntity`), **not** by adding to a reactive set. Reason: a reactive set is only *writable* if the target document is **already** within its subscription scope; but registering the freshly created document is React state that only takes effect on the **next** render → you cannot create-then-add in a single synchronous pass (seed loop, first creation). The observable symptom when you try: an `add` on an empty scope raises "Set is readonly because scope is empty".
+
+So: **write = direct SPARQL into the entity's document** (immediate, per-document); **read = the SDK's reactive shape surface** (above).
+
+**Graph convention (write into the anchored default graph).** A write passes the document's NURI as the **anchor** of `docs.sparqlUpdate` and writes the SPARQL body **without** an explicit `GRAPH <…>` clause; the shape read queries that same anchored default graph. This is the **canonical** form — to be kept for `writeEntity`, `updateEntityField` and `registration.ts`. It is a choice of **simplicity and uniformity**, not a round-trip necessity: an explicit `GRAPH` wrapper anchored to the same document does round-trip, so a "0 entities" symptom is never evidence of a graph mismatch — look at the test wallet first (`bdd-testing/caveat_wallet-bloat-hang`).
+
+The same goes for **mutating an existing field** (e.g. `participantCount`): mutating a value in memory does not hold — the reactive read re-reads the **persisted** value from the broker (reverting to the old value) → persist through SPARQL (`updateEntityField`: DELETE then INSERT of the triple) so that the change sticks and the re-read agrees. Each field is written with the **right RDF term** according to the SHEX shape (xsd:integer / float / boolean, or an IRI for the `Participation.event`/`.user` references) — a missing or mistyped mandatory field makes the read **discard the entity** (it never round-trips). The entity's **subject** = its document's **NURI** (one entity = one document), which yields an `@id` of the form `did:ng:…`.
+
+Identity corollary: a `Participation` carries a **mandatory** `fp:user` — never write it with an empty value (the entity would be discarded on read). What goes in it is `currentUserId`, i.e. the **NURI of the profile document the app read back in its own protected scope**; the app derives it from nothing, because it names no identity ([[decision_2026-08-10_the-barrier-names-no-identity]] in `app-security`). It therefore **arrives late**: a mutation fired before the protected read lands must refuse rather than write, which is what `joinEvent` does. See [[knowledge_context-internals]].
+
+Sharing keys off a different space: `inbox.share(doc, toUser)` names a **person**, so bilateral connections (`declareConnections`) are declared with **normalized profile handles**, not document NURIs — the data context maps each peer IRI to that key before declaring, and skips peers whose profile it cannot read (they cannot be named).

.project/concepts/data-layer/rule_private-store-scope.md

@@ -1,25 +0,0 @@
----
-type: rule
-summary: Utiliser did:ng:${private_store_id} comme scope useShape ET comme @graph d'écriture ; ne jamais utiliser did:ng:i comme scope (casse toutes les écritures par RepoNotFound)
----
-
-# Règle : scope = `@graph` = private_store_id
-
-Pour lire **et** écrire via l'ORM NextGraph :
-
-- **Scope** : `useShape(shapeType, \`did:ng:${session.private_store_id}\`)`
-- **`@graph`** (cible des écritures) : `did:ng:${session.private_store_id}`
-
-C'est critique : `orm_start_graph` avec le NURI du private_store **ouvre explicitement le repo** dans la HashMap `self.repos` du verifier. Sans ça, `orm_frontend_update` échoue en `RepoNotFound`.
-
-## Interdit
-
-**Ne pas utiliser `did:ng:i` comme scope.** Il s'abonne au site entier de l'utilisateur via un chemin de code spécial (`NuriTargetV0::UserSite`) qui **n'ouvre pas les repos individuels** → casse toutes les écritures.
-
-## Fichiers porteurs
-
-- `src/shared/hooks/useShapeWithDefaults.ts` — accepte un `storeNuri`, le passe à `useShape`.
-- `src/shared/utils/ngGraph.ts` — `ensureGraphNuri()` retourne le `@graph` (entités existantes d'abord, sinon fallback `private_store`).
-- `src/shared/utils/ngBootstrap.ts` — seede en utilisant `ensureGraphNuri()`.
-
-> Le *pourquoi* complet et les alternatives écartées : [[decision_2026-03-17_private-store-nuri-scope]]. **Ce scope mono-store est précisément ce que le chantier multi-store viendra remplacer** — voir [[brief_2026-05-17_multi-store-refactor]].

.project/concepts/functional-domain/_overview.md

@@ -1,28 +1,29 @@
 ---
 type: _overview
-summary: Modèle produit Festipod — le point de rencontre greffé sur un événement public comme unité de valeur, ses acteurs et ses concepts métier
+summary: Festipod's product model — the meeting point grafted onto a public event as the unit of value, its actors, its business concepts, and the confidentiality scopes (public/protected/private) per entity
 triggers:
-  keywords: [point de rencontre, rencontre, greffe, greffer, événement, déclarant, hôte, inscrit, inscription, communauté, connexion, festival, déduplication]
+  keywords: [point de rencontre, rencontre, greffe, greffer, événement, déclarant, hôte, inscrit, inscription, communauté, connexion, festival, déduplication, découverte, périmètre, scope, public, protected, privé]
   paths: ["src/modules/*/features/**"]
 ---
 
 # Functional domain
 
-Le **domaine fonctionnel** de Festipod : ce que le produit promet et le vocabulaire métier qui le décrit. Source d'origine : `README.md §Modèle fonctionnel`.
+Festipod's **functional domain**: what the product promises and the business vocabulary that describes it. Original source: `README.md §Modèle fonctionnel`.
 
-**À lire en premier :** [[knowledge_business-model]] — sans lui, on confond l'événement (l'ancrage) et le point de rencontre (la valeur), et on modélise à l'envers.
+**Read this first:** [[knowledge_business-model]] — without it, you conflate the event (the anchor) with the meeting point (the value), and you model things backwards.
 
-## Idée pivot
+## Pivotal idea
 
-Festipod laisse les utilisateurs créer des **points de rencontre** qui se *greffent* sur des **événements publics** existants. L'événement (festival, conférence…) n'est qu'un *prétexte* et un point d'ancrage spatio-temporel ; la valeur produite, c'est le point de rencontre. **On s'inscrit à un point de rencontre, jamais à un événement.**
+Festipod lets users create **meeting points** that *graft* themselves onto existing **public events**. The event (festival, conference…) is only a *pretext* and a space-time anchor; the value produced is the meeting point. **You sign up to a meeting point, never to an event.**
 
-## Périmètre & sécurité
+## Scope & confidentiality
 
-Le modèle d'**autorisations / confidentialité** (qui voit quoi : « données personnelles = réseau seulement », anonymat via inbox, capabilities) n'est pas encore implémenté — il vit aujourd'hui comme incubation dans [[brief_2026-05-18_authorization-matrix]] (concept `nextgraph-platform`). Il graduera en règles/`behavior_` quand le multi-user atterrira. C'est la raison pour laquelle il n'y a pas encore de concept `app-security` distinct.
+The product model of **who sees what** — personal data reserved to one's network, public events/meeting points, identified-or-anonymous sign-up notification — is a business fact: see [[knowledge_data-scopes-and-discovery]]. The detailed authorization matrix (actor × verb) and its incubation live in the `app-security` concept ([[brief_2026-05-18_authorization-matrix]]).
 
-## Liens
+## Links
 
-- [[knowledge_actors-and-concepts]] — référence des acteurs et concepts métier
-- [[knowledge_roadmap]] — fonctionnalités actuelles vs évolutions à venir
-- [[brief_2026-06-15_event-deduplication]] — défi ouvert de déduplication des événements en P2P
-- `nextgraph-platform` — où vit la dérivation de la structure de données cible (authz matrix, multi-store)
+- [[knowledge_business-model]] — the event / meeting point inversion
+- [[knowledge_actors-and-concepts]] — reference for actors and business concepts
+- [[knowledge_data-scopes-and-discovery]] — public/protected/private scopes per entity + discovery
+- [[knowledge_roadmap]] — current features vs upcoming evolutions
+- [[brief_2026-06-15_event-deduplication]] — open challenge of deduplicating events in P2P

.project/concepts/functional-domain/brief_2026-06-15_event-deduplication.md

@@ -1,23 +1,23 @@
 ---
 type: brief
-summary: Défi ouvert — en infra P2P, deux utilisateurs peuvent déclarer le même événement public et fragmenter les points de rencontre greffés ; pistes non tranchées
+summary: Open challenge — on a P2P infrastructure, two users can declare the same public event and fragment the meeting points grafted onto it; leads not yet settled
 ---
 
-# Déduplication des événements en infra décentralisée
+# Deduplicating events on a decentralized infrastructure
 
-**Status:** Défi ouvert — non tranché
-**Capturé:** 2026-06-15 (issu de `README.md §Défis ouverts`)
+**Status:** Open challenge — not settled
+**Captured:** 2026-06-15 (from `README.md §Défis ouverts`)
 
-## Problème
+## Problem
 
-NextGraph étant P2P, rien n'empêche deux utilisateurs de **déclarer indépendamment le même événement public** (par ex. « Eurockéennes 2027 ») et de produire deux entrées distinctes. La dispersion qui en résulte **fragmente les points de rencontre greffés** et réduit leur visibilité — ce qui va à l'encontre de la fonction première de l'app (cf. [[knowledge_business-model]]).
+Since NextGraph is P2P, nothing prevents two users from **independently declaring the same public event** (e.g. "Eurockéennes 2027") and producing two distinct entries. The resulting dispersion **fragments the meeting points grafted onto it** and reduces their visibility — which runs against the app's primary purpose (see [[knowledge_business-model]]).
 
-## Pistes envisagées (non tranchées)
+## Leads considered (not settled)
 
-- **Recherche avant création** — proposer à l'utilisateur, lors de la déclaration, les événements déjà déclarés dans son réseau / ses communautés qui correspondent à sa saisie.
-- **Identifiant externe canonique** — utiliser une URL officielle de l'événement, Wikidata, ou `schema.org/Event` pour reconnaître les doublons et les présenter comme un seul événement à l'affichage.
-- **Curation** — laisser des curators (humains ou communautaires) fusionner / vetter les entrées canoniques.
+- **Search before create** — when declaring, offer the user the events already declared within their network / their communities that match what they are typing.
+- **Canonical external identifier** — use an official event URL, Wikidata, or `schema.org/Event` to recognize duplicates and present them as a single event on display.
+- **Curation** — let curators (human or community-run) merge / vet the canonical entries.
 
-## Lien avec le modèle d'écriture
+## Link with the write model
 
-Ce défi est couplé à une question ouverte de [[brief_2026-05-18_authorization-matrix]] : **qui peut modifier un événement déclaré** (propriétaire / wiki / immuable). Un modèle *wiki* faciliterait la convergence ; un modèle *propriétaire* la complique. À arbitrer ensemble.
+This challenge is coupled to an open question in [[brief_2026-05-18_authorization-matrix]]: **who may modify a declared event** (owner / wiki / immutable). A *wiki* model would make convergence easier; an *owner* model makes it harder. To be decided together.

.project/concepts/functional-domain/knowledge_actors-and-concepts.md

@@ -1,31 +1,31 @@
 ---
 type: knowledge
-summary: Référence des acteurs (utilisateur, connexion, déclarant, hôte, inscrit, membre) et des concepts métier (point de rencontre, événement, communauté, liste curated, connexion)
+summary: Reference for the actors (user, connection, declarer, host, participant, member) and the business concepts (meeting point, event, community, curated list, connection)
 ---
 
-# Acteurs et concepts métier
+# Actors and business concepts
 
-Référence du vocabulaire. Tous les acteurs sont des spécialisations d'un **utilisateur** authentifié dans un contexte donné — pas des rôles de compte distincts.
+Vocabulary reference. Every actor is a specialization of an authenticated **user** in a given context — not a separate account role.
 
-## Acteurs
+## Actors
 
-| Acteur | Définition |
+| Actor | Definition |
 |---|---|
-| **Utilisateur** | Toute personne ayant un compte (un wallet NextGraph). Racine de tous les autres. |
-| **Connexion (« ami »)** | Un autre utilisateur avec qui je suis connecté. Sert à scoper les listes (« mes amis qui participent à… ») et la confiance. Bilatérale (acceptation des deux côtés). |
-| **Déclarant d'un événement** | L'utilisateur qui a inséré l'événement dans Festipod. *N'est pas forcément l'organisateur réel* : juste celui qui le référence. |
-| **Hôte d'un point de rencontre** | L'utilisateur qui a créé un point de rencontre rattaché à un événement. |
-| **Inscrit à un point de rencontre** | Un utilisateur inscrit à un point de rencontre ; de fait il devient participant à l'événement parent. |
-| **Membre d'une communauté d'intérêt** | Un utilisateur abonné à une communauté pour découvrir les événements qu'elle référence. |
+| **User** | Anyone with an account (a NextGraph wallet). The root of all the others. |
+| **Connection ("friend")** | Another user I am connected to. Used to scope lists ("my friends who are attending…") and trust. Bilateral (accepted on both sides). |
+| **Declarer of an event** | The user who inserted the event into Festipod. *Not necessarily the real organizer*: just whoever references it. **There is NO notion of "event host"**: the event is public, merely flagged by its declarer, who **is NOT required to attend** — at creation no participation is written, the counter starts at 0, and the declarer can join/leave like anyone else (a product decision; on the data side see data-layer/[[knowledge_context-internals]] §participantCount). The "host" remains an actor at the **meeting point** level (next row), not at the event level. |
+| **Host of a meeting point** | The user who created a meeting point attached to an event. |
+| **Participant in a meeting point** | A user signed up to a meeting point; in effect they become an attendee of the parent event. |
+| **Member of an interest community** | A user subscribed to a community in order to discover the events it references. |
 
-## Concepts métier
+## Business concepts
 
-| Concept | Définition |
+| Concept | Definition |
 |---|---|
-| **Point de rencontre** | *L'unité de valeur de l'app.* Un moment de rencontre proposé par un hôte à un endroit et un horaire donnés, greffé sur un événement public. C'est ce à quoi on s'inscrit. |
-| **Événement** | L'ancrage. Un événement public réel référencé dans Festipod pour servir de support à des points de rencontre. Simple prétexte (titre, dates, lieu, thèmes). |
-| **Communauté d'intérêt** | Un groupement thématique d'utilisateurs. Sert surtout à découvrir des événements (via abonnement) et à délimiter les périmètres de référencement. |
-| **Liste curated** | Une liste d'événements éditorialisée (par un utilisateur ou une communauté), distincte de « les événements que j'ai déclarés ». Permet d'organiser/recommander. |
-| **Connexion** | Lien de confiance bilatéral entre deux utilisateurs (équivalent « ami »). |
+| **Meeting point** | *The app's unit of value.* A moment of meeting proposed by a host at a given place and time, grafted onto a public event. It is what you sign up to. |
+| **Event** | The anchor. A real public event referenced in Festipod to serve as a support for meeting points. A mere pretext (title, dates, location, themes). |
+| **Interest community** | A thematic grouping of users. Used mainly to discover events (through subscription) and to delimit referencing scopes. |
+| **Curated list** | An editorialized list of events (by a user or a community), distinct from "the events I declared". Allows organizing/recommending. |
+| **Connection** | A bilateral trust link between two users (the equivalent of "friend"). |
 
-> Communauté, liste curated et abonnement sont en grande partie **prospectifs** (cf. [[knowledge_roadmap]]). La matrice d'autorisations détaillée par type de donnée vit dans [[brief_2026-05-18_authorization-matrix]].
+> Communities, curated lists and subscriptions are largely **prospective** (see [[knowledge_roadmap]]). The detailed authorization matrix by data type lives in [[brief_2026-05-18_authorization-matrix]].

.project/concepts/functional-domain/knowledge_business-model.md

@@ -1,26 +1,26 @@
 ---
 type: knowledge
-summary: Le point de rencontre est l'unité de valeur, greffée sur un événement-prétexte ; on s'inscrit au point de rencontre, pas à l'événement
+summary: The meeting point is the unit of value, grafted onto an event that is only a pretext; you sign up to the meeting point, not to the event
 ---
 
-# Modèle métier : le point de rencontre greffé
+# Business model: the grafted meeting point
 
-> Festipod permet aux utilisateurs de créer des **points de rencontre** qui viennent se « greffer » sur des **événements publics existants**. L'objectif : favoriser les rencontres autour de ces événements.
+> Festipod lets users create **meeting points** that come to be "grafted" onto **existing public events**. The goal: encourage people to meet around those events.
 
-## L'inversion à comprendre
+## The inversion to grasp
 
-L'**événement public** (festival, conférence, salon, exposition…) n'est **qu'un prétexte** et un *point d'ancrage temporel et géographique*. La valeur produite par l'app, c'est le **point de rencontre** que les utilisateurs viennent y greffer pour se retrouver.
+The **public event** (festival, conference, trade show, exhibition…) is **only a pretext** and a *temporal and geographical anchor point*. The value the app produces is the **meeting point** that users come and graft onto it.
 
-Conséquences directes sur la modélisation :
+Direct consequences for modelling:
 
-- **On s'inscrit à un point de rencontre, pas à un événement.** Sans points de rencontre, un événement Festipod n'a aucun intérêt.
-- Le **déclarant** d'un événement n'est *pas* (forcément) son organisateur réel — c'est juste quelqu'un qui a inséré la référence dans Festipod pour que d'autres puissent y attacher des points de rencontre.
-- L'**hôte** d'un point de rencontre est celui qui l'a créé ; l'acte de créer rend hôte. De même l'acte de déclarer un événement rend déclarant.
+- **You sign up to a meeting point, not to an event.** Without meeting points, a Festipod event is of no interest whatsoever.
+- The **declarer** of an event is *not* (necessarily) its real organizer — just someone who inserted the reference into Festipod so that others can attach meeting points to it.
+- The **host** of a meeting point is whoever created it; the act of creating makes you the host. Likewise the act of declaring an event makes you its declarer.
 
-## Authentification
+## Authentication
 
-**Tous les utilisateurs sont authentifiés** (chacun possède un wallet NextGraph) — il n'y a pas d'accès anonyme à l'app. Les différents « acteurs » (déclarant, hôte, inscrit, connexion…) sont des *spécialisations d'un utilisateur dans un contexte donné*, pas des comptes distincts. Voir [[knowledge_actors-and-concepts]].
+**Every user is authenticated** (each one owns a NextGraph wallet) — there is no anonymous access to the app. The various "actors" (declarer, host, participant, connection…) are *specializations of a user in a given context*, not separate accounts. See [[knowledge_actors-and-concepts]].
 
-## Stack porteuse
+## Underlying stack
 
-App web mobile-first, Bun + React + **NextGraph** (P2P, local-first, chiffré de bout en bout). Le choix P2P a une conséquence métier forte : voir le défi de [[brief_2026-06-15_event-deduplication]].
+A mobile-first web app, Bun + React + **NextGraph** (P2P, local-first, end-to-end encrypted). The P2P choice has a strong business consequence: see the challenge in [[brief_2026-06-15_event-deduplication]].

.project/concepts/functional-domain/knowledge_data-scopes-and-discovery.md

@@ -0,0 +1,44 @@
+---
+type: knowledge
+summary: The product model of confidentiality and discovery — every entity lives in a SCOPE (public / protected / private) depending on who must see it; events & meeting points = public, network profile & participations = protected (network), settings = private; bilateral connections = the dialog scope; discovery = reading the public scope
+---
+
+# Data scopes and discovery
+
+The **product** model of who sees what, and of how events are found. This is **domain**: the technical *how* is the `@ng-eventually/polyfill` data SDK's business — the app only states **the business intent**.
+
+## Three scopes per piece of data
+
+Every entity is stored in the **scope** matching who must be able to read it:
+
+| Entity | Scope | Who reads it |
+|---|---|---|
+| Event (the anchor) | **public** | everyone |
+| Meeting point | **public** | everyone |
+| Network profile (name, avatar, bio, city, interests) | **protected** | the holder + their connections |
+| Participation / sign-up to a meeting point | **protected** | the participant + their connections |
+| Connection index | **protected** | the holder + their connections |
+| Private profile (settings, email, preferences) | **private** | the holder alone |
+| Connection A↔B (bilateral link, + future messaging) | **dialog** | both users |
+
+Guiding principle: **the "public" side (meeting point, event) and the "personal" side (profile, participations, connections) coexist within a single user.** Personal information is reserved to the **network** (bilateral connections), never visible to an ordinary user.
+
+- **Meeting points / events are universally public.** Any user can read them and subscribe; creating a meeting point makes you its host, declaring an event makes you its declarer (no prerequisite).
+- **The host is the sole holder of write rights** on their meeting point; the declarer has no particular right over the meeting points grafted onto their event.
+- **Bilateral connection**: `DemandeDeConnexion` (unilateral, transient) → `Connexion` (bilateral, persistent) — the latter opens access to the other person's *protected* data.
+
+Festipod **places each entity in its scope**; isolation between scopes is **handled by the data SDK**, not by application code (see concept `app-security`).
+
+## Event discovery
+
+A user discovers the events they did not create simply by **reading the `public` scope**: the app names the shape and the scope, and gets back everyone's public events, not just its own. That is the **primary** discovery axis; a **secondary**, relational one is layered on top (the connections' *protected* participations: "my friends are attending…").
+
+> **Sign-up notification (product intent).** Signing up to a meeting point notifies its host: identified if the participant is one of the host's connections, **unnamed otherwise**. This "identified if known, unnamed otherwise" falls out of scope placement — the host can read the sign-up, but not the *protected* profile it points at unless they are connected. The app states the intent; it implements no filter of its own.
+
+## Open questions (business)
+
+- **Event write model**: owner (the declarer alone) / wiki (everyone) / immutable? Central to deduplication ([[brief_2026-06-15_event-deduplication]]).
+- **The host's identity towards an ordinary user**: a meeting point is readable by all, but should its host be identifiable? (pseudonym by default, a business card per meeting point, or anonymity lifted only for connections.)
+- **Which fields of a sign-up can be edited**; **"friends of friends" discoverability**.
+
+> The detailed authorization matrix by actor × verb lives in the `app-security` concept ([[brief_2026-05-18_authorization-matrix]]).

.project/concepts/functional-domain/knowledge_roadmap.md

@@ -1,25 +1,29 @@
 ---
 type: knowledge
-summary: Ce qui est implémenté aujourd'hui (cycle événement + point de rencontre, profils, connexions) vs les évolutions identifiées mais non faites (communautés, abonnements, listes curated, multi-user)
+summary: What is implemented today (event + meeting point lifecycle, profiles, connections) vs the evolutions identified but not built (communities, subscriptions, curated lists, multi-user)
 ---
 
-# Fonctionnalités actuelles vs évolutions à venir
+# Current features vs upcoming evolutions
 
-## Implémenté (écrans visibles via le router)
+## Implemented (screens reachable through the router)
 
-- Authentification via wallet NextGraph
-- Cycle de vie d'événement (déclaration, consultation, mise à jour)
-- Cycle de vie de point de rencontre (rattaché à un événement)
-- Inscription / désinscription à un point de rencontre
-- Liste des participants à un événement
-- Profil utilisateur, mise à jour, partage de profil
-- Liste d'amis (connexions), profil d'un autre utilisateur
+- Authentication through a NextGraph wallet
+- Event lifecycle (declaration, viewing, update)
+- Meeting point lifecycle (attached to an event)
+- Signing up to / withdrawing from a meeting point
+- List of an event's participants
+- User profile, profile update, profile sharing
+- Friends list (connections), another user's profile
 
-> Réserve : certaines actions de données restent des no-ops en l'état (ex. `joinEvent`/`leaveEvent` côté `FestipodDataContext` — détail dans [[brief_2026-05-21_fork-nextgraph-inbox]] §Couche 3). Le router et les écrans existent, mais le branchement données suit le chantier multi-store.
+> Signing up to / withdrawing from a meeting point is **genuinely wired** on the data side: `joinEvent` persists a Participation, notifies the meeting point's host and creates a Notification; `leaveEvent` deletes the Participation authoritatively (see concept `data-layer`, [[caveat_participation-deletion]] on the data-layer side). Public discovery — a user seeing another user's public event — works too.
 
-## Évolutions identifiées (non implémentées)
+> **The reconnection promise is guarded, not assumed.** "I come back later and my events and sign-ups are still there" is a product promise like any other, and it is the one whose failure would be least visible — nothing on screen distinguishes "you have nothing" from "it did not come back". The `src/modules/event/features/reconnexion-*.feature` scenarios of the `event` module are its non-regression guard; keep them meaningful, and read [[caveat_reconnexion-froide-local-vs-broker]] (concept `bdd-testing`) before trusting one of them green, because the natural setup proves less than it looks.
 
-- **Abonnement à une communauté d'intérêt** pour découvrir ses événements (discovery distribué).
-- **Abonnement à un utilisateur** pour suivre ses déclarations sans être ami.
-- **Listes curated** — créer/partager des sélections éditorialisées.
-- **Multi-utilisateurs collaboratif** : aujourd'hui chaque utilisateur a ses données isolées dans son wallet. Le passage collaboratif (un point de rencontre vu par plusieurs) suppose un refactor de la couche données — voir [[brief_2026-05-17_multi-store-refactor]].
+> **Product reservation — a user cannot be shown two identities on one device.** Signing in is one act with no choice attached: the user does not name, pick or switch an identity, and there is no in-app sign-out from one identity into another (concept `app-security`, [[decision_2026-08-10_the-barrier-names-no-identity]]). One session = one person, for the life of the page. Consequence for the domain: **do not design a flow that asks "who are you signing in as"**, nor an account-switcher, nor a demo that plays two people side by side on one device — none of them is expressible. Two people means two devices (or two browser contexts). The **isolation between two identities** is still a real requirement, but it is currently unproven at the `@data` layer for the same reason (concept `bdd-testing`).
+
+## Identified evolutions (not implemented)
+
+- **Subscribing to an interest community** in order to discover its events (distributed discovery).
+- **Subscribing to a user** in order to follow their declarations without being a friend.
+- **Curated lists** — creating/sharing editorialized selections.
+- **Collaborative multi-user**: actually sharing a meeting point seen by several users, resting on the public/protected/private scopes (see [[knowledge_data-scopes-and-discovery]]).

.project/concepts/nextgraph-platform/_overview.md

@@ -1,36 +0,0 @@
----
-type: _overview
-summary: NextGraph comme système EXTERNE (stores, permissions, inbox, modèle d'intégration iframe, limites SDK) + les 4 briefs prospectifs qui dérivent la structure de données cible et le chemin multi-user de Festipod
-triggers:
-  keywords: [nextgraph-rs, store, group store, dialog store, protected_store, public_store, inbox, capability, nuri, fork, ngd, broker, verifier, multi-store, multi-user, sharedWalletShim, storeRegistry, permission, social_query, OpenRepo, wallet, auto-import, textcode, wallet import, AccessGateScreen]
-  paths: ["src/shared/utils/ngGraph.ts", "src/shared/hooks/useShapeWithDefaults.ts", "scripts/build-ng-packages.sh", "src/modules/auth/sharedWallet.ts", "src/modules/auth/screens/AccessGateScreen.tsx"]
----
-
-# NextGraph platform
-
-Deux choses ici, distinctes du concept `data-layer` (qui décrit l'**usage actuel** de NextGraph par l'app) :
-
-1. **Référence du système externe NextGraph** — ses primitives de stockage et de permission, son inbox, son modèle d'intégration/déploiement, et ce que son SDK JS expose (ou pas).
-2. **Briefs prospectifs** — la dérivation de la structure de données *cible* de Festipod et les chemins pour y arriver (stopgap wallet partagé, refactor multi-store, fork moteur pour l'inbox).
-
-> Le code de l'app touché par ces chantiers : `src/shared/utils/ngGraph.ts`, `useShapeWithDefaults.ts`, `FestipodDataContext.tsx`, `ngBootstrap.ts` — les seams du futur multi-store. Le modèle de **confidentialité/autorisations** (qui peut faire quoi) vit dans le concept `app-security` ([[brief_2026-05-18_authorization-matrix]]) ; ces chantiers data en sont l'infrastructure.
-
-## Source locale
-
-Le repo `nextgraph-rs` est cloné en `/home/sylvain/projects/nextgraph/nextgraph-rs` (soit `../../nextgraph/nextgraph-rs` depuis la racine projet). À consulter pour vérifier ce qui est réellement exposé au protocole/SDK plutôt que la doc.
-
-## Référence (système externe)
-
-- [[knowledge_stores-permissions]] — 5 types de stores, document/repo, capabilities/Nuri, inbox, exposition SDK JS
-- [[knowledge_integration-model]] — paquets JS, modèle iframe, où tourne le verifier, broker `ngd`, déploiement, reciblage build-time
-- [[knowledge_broker-import-constraint]] — le broker hébergé n'autorise pas l'auto-import d'un wallet par une web-app tierce (vérifié 2026-06-17)
-
-## Briefs (chantiers prospectifs)
-
-- [[brief_2026-05-17_multi-store-refactor]] — passer du mono-store actuel à une structure par entité
-- [[brief_2026-06-15_shared-wallet-shim]] — stopgap staging : wallet partagé unique + `storeRegistry`
-- [[brief_2026-05-21_fork-nextgraph-inbox]] — forker `nextgraph-rs` pour exposer l'inbox au SDK JS
-
-## Décisions
-
-- [[decision_2026-06-17_assisted-wallet-import]] — distribution du wallet partagé par import assisté (l'auto-import zéro-touche étant impossible)

.project/concepts/nextgraph-platform/brief_2026-05-17_multi-store-refactor.md

@@ -1,84 +0,0 @@
----
-type: brief
-summary: Passer du mono-store actuel (tout dans private_store) à une structure de stores par entité ; hardcoding dans ngGraph.ts + useShapeWithDefaults ; contrainte SDK bloquante (Group stores/inbox non exposés) ; refactor structurel possible avec placeholders en attendant l'API
-last_updated: 2026-05-17
----
-
-# Refactor multi-store NextGraph
-
-**Status:** Incubating — aucun travail démarré
-**Last updated:** 2026-05-17
-
-## Context
-
-L'app est aujourd'hui *mono-store* : tout (events, profils, participations, friendships) atterrit dans le `private_store` de l'utilisateur connecté. Héritage de l'exemple expense-tracker-rdf, formalisé dans la décision du 2026-03-17 (concept `data-layer`, [[decision_2026-03-17_private-store-nuri-scope]]).
-
-Ce choix bloque le multi-utilisateurs : le `private_store` est non partageable (*« not possible to share the documents of your private store »*, cf. [[knowledge_stores-permissions]]). Tant que tout y est, Bob ne verra jamais l'event d'Alice. Le modèle natif NextGraph est *multi-store par utilisateur* — Festipod doit s'y aligner avant de devenir collaboratif.
-
-**Déclencheur :** discussion du 2026-05-17 — *poser le cap, exécuter plus tard*.
-
-## What We Know
-
-### État actuel du code
-
-Deux fichiers concentrent le hardcoding du store unique :
-- `src/shared/utils/ngGraph.ts` — `ensureGraphNuri()` retourne `did:ng:${session.private_store_id}` pour TOUTES les entités.
-- `src/shared/hooks/useShapeWithDefaults.ts` — accepte un `storeNuri` mais l'appelant unique (`FestipodDataContext`) lui passe toujours le NURI du private_store.
-
-Entités impactées (toutes mélangées) : `FpEvent` (→ store partagé), `FpUserProfile` (→ partie privée/publique), `FpParticipation` (→ avec son event), `FpMeetingPoint` (local-only aujourd'hui), `FpFriendship` (local-only, privée). Cf. concept `data-layer` §entités.
-
-### Modèle cible proposé
-
-> **Note (2026-05-19)** : [[brief_2026-05-18_authorization-matrix]] a depuis dérivé, à partir des seuls points validés, une structure différente — 3 stores natifs par utilisateur + Dialog stores, **sans Group store** dans le périmètre actuel. La structure à 4 niveaux ci-dessous reste pertinente pour le périmètre élargi (communautés, collaboration multi-hôte), aujourd'hui hors périmètre. À reconcilier à l'exécution.
-
-Structure hiérarchique en **4 niveaux de Group stores** : index communautaire ⊃ communauté ⊃ event ⊃ meeting point.
-
-| Entité | Store cible | Justification |
-|---|---|---|
-| Event (métadonnées) | Group « communauté » | La communauté possède l'event → contrôle qui le modifie |
-| Référence d'event (pointeur) | Group « index communautaire » | Discovery |
-| Participation | Group « event » | N'a de sens que dans son event |
-| MeetingPoint (métadonnées) | Group « event » | Le RDV appartient à l'event |
-| Participation à un MeetingPoint | Group « meeting point » | RSVP scopé au RDV |
-| UserProfile (partie publique) | public_store de l'utilisateur | Modèle natif |
-| Friendship | private_store de l'utilisateur | Purement personnelle |
-
-### Contrainte SDK bloquante
-
-Primitives présentes au protocole mais **non exposées dans `@ng-org/web`** (vérifié `0.1.2-alpha.13`) : création de Group stores + invitations/permissions ; **dépôt/lecture d'inbox** (mécanisme retenu pour la notif d'inscription, cf. [[brief_2026-05-18_authorization-matrix]]). `app_request_stream` est la méthode générique la plus susceptible de porter ce mécanisme une fois exposée (à confirmer côté Rust). Cf. [[knowledge_stores-permissions]] §Limites SDK.
-
-**Implication :** le refactor *structurel* peut commencer sans attendre l'API, avec des placeholders (continuer à pointer `private_store_id` pour les Group stores impossibles). L'**aboutissement complet** (vrai multi-user) dépend de l'arrivée de l'API ou d'un contournement (voir [[brief_2026-05-21_fork-nextgraph-inbox]], [[brief_2026-06-15_shared-wallet-shim]]).
-
-### Implications côté code
-
-1. **Disparition de `ensureGraphNuri()`** comme helper unique → helpers par entité ou couche `storeRegistry` résolvant le NURI selon `(entité, contexte)`.
-2. **`useShapeWithDefaults` reste un wrapper** mais l'appelant choisit explicitement le store (N appelants demain).
-3. **Chaque entité déclare son store cible** (mapping centralisé ou convention shape→store).
-4. **`bootstrapWallet()`** (`src/shared/utils/ngBootstrap.ts`) revu : seed réparti, ou seed = données de l'utilisateur courant seulement.
-5. **`FestipodDataContext`** : hooks par entité, chacun avec son store résolu.
-
-## Open Questions
-
-1. Quand crée-t-on un Group store de communauté (API absente) ? Acte explicite vs communauté par défaut ?
-2. Comment Bob connaît-il l'index communautaire d'Alice ? (possiblement via le public_store d'Alice)
-3. Faut-il vraiment 4 niveaux ? Le « meeting point = group store » mérite validation.
-4. Que devient le seed de démo quand les Group stores n'existent pas encore ?
-5. Migration des wallets de test existants (script / wipe-reseed / ignore) ?
-6. Bootstrap d'un user vierge : auto-créer un Group store « par défaut » ou attendre ?
-
-## Possible Approaches
-
-- **Refactor structurel d'abord, partage ensuite** (placeholders `private_store_id`).
-- **Registry centralisé** vs **résolution par convention**.
-- **Big-bang** vs **par entité** (commencer par Event).
-- **Maintenir un mode mono-store** parallèle pour dev/demo.
-
-## Out of Scope
-
-Invitation effective (capability sharing), permissions par rôle, discovery cross-wallet, contournement de l'UI wallet, mode P2P direct sans broker. → second chantier multi-user dont ce refactor est le prérequis structurel.
-
-## Starting Points
-
-- Concept `data-layer` → [[decision_2026-03-17_private-store-nuri-scope]] (la décision qu'on viendra modifier), état du pattern d'écriture
-- `src/shared/utils/ngGraph.ts`, `src/shared/hooks/useShapeWithDefaults.ts`, `src/shared/context/FestipodDataContext.tsx`, `src/shared/utils/ngBootstrap.ts`
-- NextGraph docs : [Documents et Stores](https://docs.nextgraph.org/en/documents/), [Getting started](https://docs.nextgraph.org/en/getting-started/)

.project/concepts/nextgraph-platform/brief_2026-05-21_fork-nextgraph-inbox.md

@@ -1,96 +0,0 @@
----
-type: brief
-summary: Forker temporairement nextgraph-rs pour exposer l'inbox au SDK JS (notif d'inscription, anonymat via from optionnel) — 3 couches : patch Rust (4 fichiers), auto-hébergement ngd+ng-app sur Coolify, intégration Festipod ; fork jetable abandonné quand l'upstream livrera sa solution
-last_updated: 2026-05-21
----
-
-# Forker NextGraph pour exposer l'inbox au SDK JS
-
-**Status:** Incubating — aucun travail démarré
-**Last updated:** 2026-05-21
-
-## Context
-
-Festipod doit notifier l'hôte d'un PdR quand quelqu'un s'inscrit, avec **identification si connexion / anonyme sinon** (cf. décision cadre inbox dans [[brief_2026-05-18_authorization-matrix]]). L'**inbox** NextGraph est idéale (le `from` optionnel donne l'anonymat) **mais n'est pas exposée au SDK JS** (cf. [[knowledge_stores-permissions]] §Inbox). Ce brief évalue **forker/patcher `nextgraph-rs`** pour l'exposer.
-
-### Posture stratégique (cadrée par l'utilisateur)
-
-Le fork est **explicitement temporaire, non destiné à l'upstream**. Hypothèse : NextGraph finira par exposer sa **propre** solution d'inbox au SDK JS, **possiblement différente**. Quand elle arrivera, on **abandonne le fork et on adapte Festipod**. Tant que leur solution n'est pas là : maintenir le fork à jour (rebase sur `upstream/main`, qui bouge vite en `0.1.2-alpha`) ; **déployer broker + ng-app depuis le fork** ; surveiller l'upstream pour basculer dès que possible. On ne vise **pas** une PR.
-
-## What We Know
-
-Trois couches.
-
-### Couche 1 — Le patch Rust : 4 fichiers (broker vanilla)
-
-1. **`engine/net/src/types.rs`** — `InboxMsgContent::Link` est une variante **unit** (stub) ; lui donner un payload (ou variante `Notification`) portant le NURI du PdR + lien vers l'`Inscription`. Ajouter un builder `InboxPost::new_link(...)` calqué sur `new_contact_details`. `from = None` → anonymat.
-2. **`engine/verifier/src/request_processor.rs`** — ajouter le bras de commande manquant (pas de bras `InboxPost`). Idéalement une commande haut-niveau (`NotifyInbox`) construisant le post côté Rust (garde le scellement crypto en Rust). Calquer sur `SocialQueryStart`.
-3. **`sdk/js/lib-wasm/src/lib.rs`** — exposer `pub async fn inbox_post_link(session_id, to_inbox_nuri, to_profile_nuri, link, anonymous)`, calqué sur `social_query_start`.
-4. **`engine/verifier/src/inbox_processor.rs`** (`process_inbox`) — bras de réception qui **matérialise** le message en document dans le store de l'hôte (calquer sur le handler `ContactDetails`). L'app lit ensuite via ORM/SPARQL — pas de nouvelle API de lecture d'inbox.
-
-**Résolution d'identité** (connu/anonyme) : gratuite via SPARQL côté app (JOIN du NURI d'inbox émetteur contre les docs `social:contact`). **Découverte de l'inbox de l'hôte** : embarquer le NURI d'inbox du `public_store` de l'hôte dans le doc PdR ou le profil public (le flux QR-code de partage de profil le porte déjà).
-
-### Couche 2 — Déploiement (depuis le fork)
-
-Détail dans [[knowledge_integration-model]]. Le verifier patché tourne **dans l'iframe ng-app** → **construire et auto-héberger le `ngd` + le ng-app** depuis le fork, puis rebuilder le `@ng-org/web` de Festipod avec `NG_REDIR_SERVER`/`NG_DEV*` pointant sur ce ng-app. **Aucune réécriture de l'intégration Festipod** (reste iframe). Le routage inbox du broker est déjà natif, mais comme on auto-héberge le ng-app patché, **on déploie toute la stack depuis le fork** (un seul arbre source).
-
-- **Local** : `ngd` + ng-app du fork ; Festipod buildé avec `NG_DEV`/`NG_DEV_LOCAL_BROKER`.
-- **Serveur de test** : `ngd` + ng-app du fork sur notre domaine ; Festipod buildé avec `NG_REDIR_SERVER=notre-domaine`.
-
-#### Hébergement sur Coolify — 3 pièces web
-
-1. **`ngd`** — démon WebSocket **stateful** : conteneur avec **volume persistant** pour `--base-path` (RocksDB + clés + PeerId, jamais wipé), mode `--domain` derrière le Traefik de Coolify. Build : Dockerfiles officiels cassés → **écrire notre Dockerfile multi-stage Rust** (RocksDB exige llvm/clang). Premier démarrage **interactif** (lien d'invitation wallet admin) → scripter via `ngcli` ou faire une fois à la main puis persister dans le volume.
-2. **ng-app** (frontend iframe, wasm patché) — **build statique** (`pnpm webfilebuild`). Servi en statique (buildpack ou nginx).
-3. **Routage** : un même domaine sert le statique du ng-app ET proxifie le WebSocket vers ngd.
-
-Plus **Festipod** lui-même (app Bun → skill `coolify-hosting` pour CELLE-CI, pas pour le `ngd` Rust). Drivers de complexité : build Rust+RocksDB sans Dockerfile prêt, conteneur stateful à volume critique, premier-run interactif, double-service (statique + WS).
-
-### Couche 1 (libs JS) — paquets npm clients patchés
-
-**On maintient des versions patchées des paquets clients, pas seulement le wasm.** Le forwarding générique permet *techniquement* d'atteindre une méthode wasm sans toucher le JS, mais c'est un **hack** (non typé, fragile) — test rapide seulement. À modifier réellement :
-
-- **`@ng-org/web`** — modifié de toute façon (URL broker) → y ajouter `inbox_post_link` dans la **surface d'API typée + `.d.ts`**.
-- **Méthodes streamées** (si lecture inbox en *flux* un jour) — entrée des deux côtés (`E` + `streamed_api`). Pour la seule **écriture** (requête/réponse), inutile.
-- **`@ng-org/orm`** — à modifier **si** on intègre l'écriture inbox au flux ORM. Sinon (appel `ng.inbox_post_link` à côté), inutile.
-- **`@ng-org/alien-deepsignals`, `@ng-org/shex-orm`** — a priori inchangés.
-
-#### Outillage existant : `scripts/build-ng-packages.sh`
-
-`bun run build:ng` build les 4 paquets depuis `$NEXTGRAPH_RS/sdk/js/*` (défaut `../../nextgraph/nextgraph-rs`) → `pnpm pack` → `.tgz` dans `.ng-tarballs/` → `bun add` réécrit `package.json` vers les tarballs locaux. **Pattern d'origine du projet** : le commit `fd6d408` l'a abandonné quand les alphas ont été publiées sur npm. Pour repasser au custom : **réactiver `bun run build:ng`**. Nuances : `@ng-org/web` est TS pur (le script crée un *stub* `lib-wasm` ; le tarball porte l'API inbox typée + l'URL broker bakée, **pas** le wasm) ; pointer le script sur la **branche patchée** (retirer le `git pull --ff-only`) ; option recommandée : patcher `@ng-org/web` pour lire l'URL broker au **runtime** (évite de rebuilder par domaine).
-
-### Couche 3 — Intégration dans Festipod
-
-Exposer la méthode ne suffit pas. Chantiers (certains préexistent à l'inbox) :
-
-- **Modéliser le PdR.** Les SHEX (`src/shared/shapes/shex/festipodShapes.shex`) ne définissent qu'`Event`/`UserProfile`/`Participation` — **pas de `MeetingPoint`** (local-only), ni d'entité notification. Ajouter les shapes + `bun run build:orm`.
-- **Implémenter l'inscription (aujourd'hui no-op).** Dans `FestipodDataContext.tsx`, `joinEvent`/`leaveEvent` sont des `console.log`. Le vrai flux : (a) écrire l'`Inscription` dans le `protected_store` de l'inscrit (via multi-store, [[brief_2026-05-17_multi-store-refactor]]), (b) appeler `ng.inbox_post_link(...)` pour notifier l'inbox du PdR.
-- **Porter le NURI d'inbox de l'hôte** sur le doc PdR (ou lookup profil).
-- **Lire et résoudre les notifications côté hôte** : lire les docs notification matérialisés (ORM/SPARQL), JOIN identité contre `social:contact`. UI : « N inscrits dont X identifiés ».
-- **Câblage session** via `src/shared/utils/ngSession.ts`.
-
-**Dépendances** : présuppose (1) le fork SDK livré, (2) le refactor multi-store. **Surface jetable** : à l'arrivée de l'API officielle, migrer aussi ces points d'appel Festipod.
-
-## Open Questions
-
-- `NotifyInbox` haut-niveau vs `InboxPost` brut ? (haut-niveau préféré, garde la crypto en Rust)
-- Où sourcer le NURI d'inbox de l'hôte (doc PdR vs lookup profil) ?
-- Forme de la matérialisation côté réception (quels triples) ?
-- Suppression côté inbox : un déposant peut-il retirer son dépôt ? (résiduelle, cf. [[brief_2026-05-18_authorization-matrix]])
-- Cadence de rebase du fork ? Critère de bascule vers la solution upstream ?
-- `@ng-org/web` : patch runtime vs tarball par domaine ?
-- `ngd` Coolify : automatiser le premier-run vs one-shot manuel persisté ? Un service (reverse-proxy maison) ou deux ?
-
-## Possible Approaches
-
-- **A. Fork temporaire + auto-hébergement (retenu comme stopgap)** — patch des 4 fichiers, déploiement depuis le fork. Vrai inbox, anonymat natif. Coût : maintenir le fork + héberger. Jetable.
-- **B. Contribution upstream — écartée** comme objectif.
-- **C. Pas de patch, détourner `social_query_start`** — repli, livrable tout de suite mais limité aux **contacts** (pas d'anonyme vers un hôte non-connecté).
-
-> Voir aussi [[brief_2026-06-15_shared-wallet-shim]] : le vrai multi-user (lecture cross-wallet) suppose en plus un patch `OpenRepo` + capabilities, au-delà de l'inbox.
-
-## Starting Points
-
-- [[knowledge_integration-model]], [[knowledge_stores-permissions]]
-- [[brief_2026-05-18_authorization-matrix]] — la décision cadre inbox que ce patch sert
-- Repo local `nextgraph-rs` : `sdk/js/lib-wasm/src/lib.rs`, `engine/verifier/src/{request_processor,inbox_processor}.rs`, `engine/net/src/types.rs`
-- Remotes : `origin` = `git.nextgraph.org/slaivyn/nextgraph-rs` (fork perso), `upstream` = `git.nextgraph.org/NextGraph/nextgraph-rs`

.project/concepts/nextgraph-platform/brief_2026-06-15_shared-wallet-shim.md

@@ -1,183 +0,0 @@
----
-type: brief
-summary: Stopgap staging multi-user — deux visions cadrées. Lointaine (cible) — multi-wallet, 3 stores natifs par utilisateur + Dialog, 1 document par entité (événement/PdR), partage par capabilities, inbox native du PdR. Adaptée (stopgap) — UN wallet partagé, 1 document par entité dans son private_store, périmètre = métadonnée logique + index, filtre d'isolation applicatif, login simulé. Obstacles NextGraph — pas de lecture cross-wallet (OpenRepo TODO, ReadCap ignoré), capabilities/inbox non exposées au SDK, login non programmable. sharedWalletShim + filtre = jetables à la migration.
-last_updated: 2026-06-16
----
-
-# Stopgap multi-user : wallet partagé unique (`sharedWalletShim`)
-
-**Status:** En cours — compte/login + isolation livrés et vérifiés ; **granularité 1 document par entité implémentée** ; primitives + **fan-out multi-documents validés sur broker** (`@data`, 3 scénarios). Reste : reactivity in-app de la création (best-effort) + seeding multi-doc.
-
-## Objectif & posture
-
-Mettre Festipod en **staging** avec des **utilisateurs amicaux**, **sans enjeu de sécurité**, branché sur le vrai NextGraph, et **structuré au plus près de l'infra cible** pour qu'une migration soit un simple changement de résolveur, pas une réécriture.
-
-Trois choses doivent rester nettes pour ne pas dériver, et structurent ce brief :
-
-1. la **vision lointaine** — ce qu'on aura quand NextGraph offrira lecture cross-wallet, capabilities et inbox ;
-2. les **obstacles NextGraph** — ce qui, aujourd'hui, empêche cette vision ;
-3. la **vision adaptée** (stopgap) — au plus proche de la lointaine, compte tenu des obstacles.
-
-> **Invariant directeur** : tout ce que fait la vision adaptée doit avoir une **correspondance 1:1** explicite avec la vision lointaine (table en fin de section adaptée). Si un choix du stopgap n'a pas d'image claire dans la cible, c'est un signal de dérive.
-
----
-
-## 1. Vision lointaine (cible finale)
-
-Dérivée de [[brief_2026-05-18_authorization-matrix]] et [[knowledge_stores-permissions]]. Périmètre **validé** (hors communautés / listes curées / suivi, encore hors périmètre).
-
-### Identité & login
-- **1 utilisateur = 1 wallet NextGraph.** Le wallet **est** l'identité ; pas de compte applicatif séparé.
-- **Login = ouvrir son propre wallet** (redirect broker). C'est un vrai login par-utilisateur.
-
-### Stores & granularité documents
-Modèle natif : `1 document = 1 repo = 1 frontière de permission = 1 inbox`. Un **store** est un document-conteneur qui regroupe et permissionne d'autres documents. Chaque utilisateur a **3 stores natifs** ; les entités sont des **documents individuels** dedans (pas un gros graphe par store).
-
-| Entité | Store (propriétaire) | Granularité | Notes |
-|---|---|---|---|
-| Événement | `public_store` du déclarant | **1 document / événement** | adressable par NURI (utile pour la déduplication) |
-| Point de rencontre (PdR) | `public_store` de l'hôte | **1 document / PdR** | **possède son inbox native** (reçoit les inscriptions) |
-| Profil réseau | `protected_store` | 1 document | nom, avatar, bio, ville, intérêts |
-| Participation / Inscription | `protected_store` de l'inscrit | 1 document / inscription | + dépôt d'un lien dans l'**inbox du PdR** |
-| Profil privé (settings, email) | `private_store` | 1 document | soi seul |
-| Connexion A↔B | **Dialog store** A↔B | doc connexion (+ messagerie) | deux écrivains |
-| Index des connexions | `protected_store` | 1 document | liste les NURIs des Dialog stores |
-
-**Aucun Group store** sur le périmètre validé (les 3 stores + Dialog + inboxes suffisent).
-
-### Partage & visibilité
-- Par **capabilities** : on transmet un Nuri portant un read/write cap. **Public** = lisible par tous sans cap. **Protected** = cap obtenue via la connexion. **Privé** = soi.
-- Ajout de permission asynchrone ; retrait synchrone (SyncSignature).
-
-### Inbox & notifications
-- L'**inbox native du document PdR** reçoit les dépôts d'inscription (lien DID cap). `from` optionnel ⇒ **identifié si connexion de l'hôte, anonyme sinon**, gratuitement.
-
-### Découverte
-- **Pas d'annuaire central.** On découvre via les `public_store` et le graphe de connexions (et plus tard `social_query`).
-
----
-
-## 2. Obstacles côté NextGraph (ce qui empêche la vision lointaine aujourd'hui)
-
-Vérifiés dans `nextgraph-rs` (2026-06-15).
-
-| Élément de la cible | Obstacle actuel | Preuve |
-|---|---|---|
-| Lire le store d'un **autre** utilisateur | `OpenRepo` **non implémenté** ; un NURI étranger lève `RepoNotFound` ; une session ne contient que ses 3 stores dans `self.repos` | `engine/verifier/src/verifier.rs:1423`, `request_processor.rs` `resolve_target` |
-| Partager une **capability** (Nuri + droits) | non exposé au SDK ; le champ `access`/`ReadCap` du NURI **n'est jamais inspecté** | [[knowledge_stores-permissions]] |
-| **Inbox** d'un document (notif d'inscription) | pas exposée au SDK JS (nécessite un fork moteur) | [[brief_2026-05-21_fork-nextgraph-inbox]] |
-| **Login per-utilisateur** fluide | login **non programmable** (redirect web vers le broker) | [[decision_2026-06-15_shared-wallet-login-flow]] |
-
-**Conséquence centrale** : tant que la lecture cross-wallet n'existe pas, **aucune donnée ne franchit la frontière entre deux wallets**. Bob ne peut pas lire le `public_store` d'Alice. Toute approche « chacun son wallet » est donc bloquée à la racine.
-
----
-
-## 3. Vision adaptée (stopgap) — au plus proche de la cible
-
-### Principe : UN wallet partagé
-Tous les utilisateurs amicaux ouvrent **le même** wallet. NextGraph ne voit qu'une identité → **tout est techniquement lisible** (on contourne l'absence de lecture cross-wallet en supprimant la frontière). Le « multi-utilisateur » devient une **fiction applicative**.
-
-### Granularité documents — **identique à la cible** : 1 document par entité
-Pour rester fidèle, on reproduit les **deux niveaux** de la cible (conteneur → documents) :
-
-- chaque **événement** et chaque **PdR** = **son propre document** (`doc_create`), tous physiquement dans le `private_store` de l'unique wallet partagé ;
-- le **périmètre** (public/protected/private) est une **métadonnée logique** portée par le document, **pas** un store physique ;
-- un **document-index par (utilisateur × périmètre)** liste les NURIs des entités de ce périmètre — il **joue le rôle du futur store-conteneur** (`docPublic` ≈ futur `public_store`, etc.).
-
-Garder la granularité « 1 doc par entité » est ce qui rend la migration 1:1 **et** ce qui rendra l'**inbox du PdR** possible plus tard sans refonte (l'inbox est un attribut de document).
-
-| Entité | Périmètre logique | Document stopgap | Indexé dans |
-|---|---|---|---|
-| Événement | public | 1 doc / événement | `docPublic` du déclarant |
-| PdR | public | 1 doc / PdR | `docPublic` de l'hôte |
-| Profil réseau | protected | doc profil réseau | `docProtected` |
-| Participation | protected | 1 doc / participation (ou groupé) | `docProtected` de l'inscrit |
-| Profil privé | private | doc settings | `docPrivate` |
-| Connexion A↔B | dialog | doc connexion | index de connexions |
-
-### `sharedWalletShim` (échafaudage, sans équivalent cible)
-Index des **comptes** simulés → leurs documents-index : `username → profileId → { docPublic, docProtected, docPrivate }`. Ancré dans le `private_store` du wallet partagé (`session.private_store_id`, toujours connu → ancre de bootstrap). Rend possibles le **login cross-device** et le **picker d'utilisateurs**. **N'a aucun équivalent cible** (la cible n'a pas d'annuaire central) → **jetable**.
-
-### Partage simulé : filtre d'isolation applicatif
-Un seul wallet ⇒ tout lisible. Pour **se comporter** comme la cible, la couche données filtre les lectures par `currentAccountId` + connexions : `private` → propriétaire ; `protected` → propriétaire + connexions ; `public` → tous. Remplace les **capabilities** (pas appliqué par la crypto, mais honoré par l'app) → **jetable**.
-
-### Identité & login simulés
-- **Couche réelle (technique, invisible)** : le redirect broker du wallet partagé, présenté comme **barrière d'accès à l'environnement** (pas un login). Cf. [[decision_2026-06-15_shared-wallet-login-flow]].
-- **Couche applicative (le login perçu)** : écran « Connexion » = **username seul** (déclaratif, sans mot de passe) → `localStorage`. « Déconnexion » = efface le username, sans toucher NG. Vrai logout planqué.
-
-### Inbox / notification d'inscription
-**Hors périmètre du stopgap** (nécessite le fork). Mais la granularité « 1 doc/PdR » est le **pré-requis** qui la rendra branchable plus tard sans refonte.
-
-### Correspondance stopgap → cible (l'invariant 1:1)
-
-| Stopgap | Vision lointaine | Migration |
-|---|---|---|
-| doc événement (dans le wallet partagé) | doc événement dans le `public_store` du déclarant | déplacer le doc + appliquer cap publique |
-| doc PdR | doc PdR dans le `public_store` de l'hôte **+ inbox** | déplacer + brancher l'inbox |
-| `docPublic`/`docProtected`/`docPrivate` (index) | `public_store`/`protected_store`/`private_store` | l'index devient le store natif |
-| filtre d'isolation applicatif | capabilities (read caps via connexion) | retirer le filtre, poser les caps |
-| login applicatif (username) | login = ouvrir son wallet | retirer la couche compte |
-| `sharedWalletShim` | — (rien) | supprimer |
-| wallet partagé unique | un wallet par utilisateur | éclater par propriétaire |
-
-**Migration = swap du résolveur `storeRegistry`** (de « doc dans le wallet partagé » vers « doc dans le vrai store du propriétaire ») + déplacement des documents + pose des capabilities + suppression de l'échafaudage. **Les écrans ne changent pas.**
-
----
-
-## Familles de contournement (pourquoi A)
-
-| Famille | Idée | Verdict |
-|---|---|---|
-| **A — wallet partagé** | un seul wallet, multi-user simulé côté app | **retenue** : livrable vite, zéro travail moteur, local-first préservé |
-| B — NG comme backend | un backend Bun détient un wallet, clients HTTP | écartée : abandonne le local-first, plus lourd |
-| C — lecture cross-wallet | chacun son wallet, lecture du public des autres | **infaisable** (obstacle §2) sans fork moteur |
-| D — fork moteur (`OpenRepo` + capabilities) | rendre la cible réelle | hors stopgap : c'est le chemin cible, lourd (cf. [[brief_2026-05-21_fork-nextgraph-inbox]]) |
-
----
-
-## État d'implémentation (2026-06-16)
-
-Deux drapeaux de build, **OFF par défaut** (le mono-store validé reste le défaut ; dev/`@ui`/`@e2e` inchangés) :
-- **`FESTIPOD_STAGING=1`** — flux login option 2 (découplé de `NODE_ENV` pour ne pas bloquer `@e2e`).
-- **`FESTIPOD_MULTISTORE=1`** — couche multi-document (storeRegistry).
-
-| Pièce | Fichier | État |
-|---|---|---|
-| Couche compte (faux login, localStorage) | `src/shared/context/AccountContext.tsx` | ✅ livré, vérifié (build + `@ui`) |
-| Gate technique + écran « Connexion » + orchestrateur | `src/modules/auth/screens/{AccessGateScreen,ConnexionScreen}.tsx`, `src/app/AuthGate.tsx` | ✅ livré |
-| Vrai logout planqué | `ngSession.ts:logoutNg`, `SettingsScreen.tsx` | ✅ livré |
-| Filtre d'isolation (mode connecté) | `src/shared/utils/isolation.ts` + `FestipodDataContext` | ✅ livré, pur, vérifié |
-| storeRegistry + sharedWalletShim | `src/shared/utils/storeRegistry.ts` | ✅ **1 doc/entité** (`createEntityDoc`/`listEntityDocs` + index par périmètre) ; primitives **validées broker** |
-| Câblage multi-document (reads fan-out `{graphs}` + write per-entité `createEntityDoc`) | `FestipodDataContext` (useNgData) derrière `MULTISTORE` | ✅ lecture fan-out validée ; ⚠️ reactivity de la création in-app = **best-effort** (le nouveau doc est ajouté au fan-out, l'`@id` peut être en attente jusqu'au re-subscribe) |
-| Validation broker (`@data`) | `src/modules/workshop/{features/multistore-stopgap.feature, steps/data/multistore.steps.ts}` | ✅ **3 scénarios verts** (ORM-sur-doc-créé, shim r/w, **fan-out par entité**) |
-
-**Granularité = 1 document par entité (fait)** : public (événements/PdR) → un `doc_create` **par entité**, NURI ajouté à l'**index** du périmètre (le futur store-conteneur) ; protected (profil, participations) → **groupé** dans l'index protected. Lecture publique = `listEntityDocs('public')` → `useShape({graphs:[…]})`. Mono-store (défaut) inchangé.
-
-**Validation broker (2026-06-16, `@data` contre `nextgraph.net`, 3 scénarios verts)** :
-1. ✅ `doc_create("Graph","data:graph","store",undefined)` → NURI utilisable comme `@graph` ORM (write+read d'une `Participation` via `useShape({graphs:[nuri]})`). On n'est **pas** limité au `private_store` comme scope (cf. [[rule_private-store-scope]]).
-2. ✅ Shim r/w : 3 docs créés + `sparql_update`, rechargés via `sparql_query` (`readBindings` tolérant, OK en pratique).
-3. ✅ **Fan-out par entité** : 2 comptes × 1 doc-événement (`createEntityDoc` + indexé), un `useShape({graphs:[docA,docB]})` lit **les deux** événements, l'index public liste les deux docs.
-4. ⏳ **Reste** : reactivity de la création in-app (best-effort, à itérer sur broker) + seeding multi-document (auto-seed neutralisé en `MULTISTORE`).
-
-## Open Questions
-
-- **Modèle d'écriture de l'événement** (propriétaire / wiki / immuable) — *ouvert dans la matrice*. Propriétaire/immuable → événement = doc dans le `public_store` du déclarant (granularité par entité exacte). **Wiki** → exigerait un Group store (hors périmètre) et **changerait la cible**.
-- **Création des documents** : `doc_create` à la création de l'entité (retenu par la granularité par entité) ; création paresseuse des index de périmètre.
-- **Picker d'utilisateurs** : saisie libre vs liste des comptes du `sharedWalletShim`.
-
-## Out of Scope
-
-- Le **vrai multi-user** (lecture cross-wallet) — fork moteur (`OpenRepo` + capabilities), voir [[brief_2026-05-21_fork-nextgraph-inbox]].
-- L'**inbox du PdR** (notif d'inscription) — même fork.
-- L'**auto-hébergement** du broker/ng-app (staging sur `nextgraph.net`).
-- Toute **sécurité réelle** (credential partagé, pas de mot de passe, pas de chiffrement par utilisateur).
-
-## Starting Points
-
-- [[brief_2026-05-18_authorization-matrix]] — périmètres et partition de la vision lointaine
-- [[brief_2026-05-17_multi-store-refactor]] — l'indirection `storeRegistry`
-- [[brief_2026-05-21_fork-nextgraph-inbox]] — le chemin cible réel (cross-wallet + inbox)
-- [[decision_2026-06-15_shared-wallet-login-flow]] — flux login/logout
-- [[knowledge_stores-permissions]] — stores, capabilities, inbox, limites SDK
-- `src/shared/utils/storeRegistry.ts`, `src/shared/context/FestipodDataContext.tsx`, `src/app/AuthGate.tsx`, `src/shared/utils/isolation.ts`
-- Source `nextgraph-rs` : `sdk/rust/src/tests/sparql_regressions.rs:136-200` (multi-document), `engine/verifier/src/verifier.rs:1423` (TODO `OpenRepo`)

.project/concepts/nextgraph-platform/decision_2026-06-15_shared-wallet-login-flow.md

@@ -1,51 +0,0 @@
----
-type: decision
-summary: Flux login/logout du stopgap wallet partagé — le vrai login NextGraph (redirect broker) apparaît en premier, perçu comme une barrière technique d'accès à l'environnement ; l'écran applicatif « Connexion » (username seul → localStorage) EST le login perçu ; « Déconnexion » efface juste le username sans toucher NG ; vrai logout planqué
-last_updated: 2026-06-15
----
-
-# Décision 2026-06-15 — Flux de login/logout du stopgap wallet partagé
-
-Arbitrage du flux d'authentification perçu pour le stopgap [[brief_2026-06-15_shared-wallet-shim]]. Frozen.
-
-## Contrainte de départ
-
-Le login NextGraph **n'est pas programmable** : c'est une **redirection web** vers la page du broker (`nextgraph.net`). Impossible d'ouvrir le wallet partagé en silence — il faut au minimum un passage par le redirect broker, au moins une fois par device. La question n'est donc pas *« comment éviter le redirect »* mais *« comment l'ordonner et le présenter »* pour que l'UX reste cohérente.
-
-## Décision : option 2 — gate technique d'abord, « Connexion » applicative ensuite
-
-Deux couches d'auth distinctes, présentées dans cet ordre :
-
-1. **Couche réelle (technique, non perçue comme login)** — le redirect broker apparaît **immédiatement, avant tout rendu de l'app**. Comme il précède l'app, l'utilisateur le lit comme une **barrière technique d'accès à l'environnement de test** (type mur de beta), **pas** comme un login applicatif. Mêmes credentials partagés pour tous (donnés dans l'invitation, façon « code d'accès »). Une fois par device, puis persistant. **Jamais étiqueté « login ».** Un splash Festipod minimal précède le redirect pour donner du contexte.
-2. **Couche applicative (perçue comme LE login)** — écran **« Connexion »** = saisie du **username** (→ `localStorage`, `currentAccountId`). C'est le login *dans la perception* de l'utilisateur. **Sans mot de passe** (décision username-seul) → connexion **déclarative** : n'importe qui prend n'importe quel username (cohérent zéro-sécurité / amis). **« Déconnexion »** = efface **seulement** le username et revient à l'écran « Connexion » ; **n'appelle aucune fonction NG**.
-
-Le **vrai logout** (`ng.session_stop` / `user_disconnect` / `wallet_close`) reste **planqué** (réglages/debug), car il force un nouveau redirect.
-
-Le label **« Connexion »/« Déconnexion »** (et non « Changer de profil ») est un choix explicite : on assume de faire passer le username pour le login applicatif, puisque la barrière technique n'est pas perçue comme tel.
-
-## Pourquoi (vs option 1 écartée)
-
-**Option 1 écartée** — faux login d'abord (username), puis page d'avertissement « saisissez tel username/password », puis bouton *Continuer* déclenchant le redirect. Rejetée : workflow étrange, **double-login dissonant** (« je me suis déjà connecté, pourquoi je recommence ailleurs ? »), page d'avertissement qui **ressemble à une arnaque**, et le redirect **ressurgit en plein usage** à chaque expiration de session.
-
-**Option 2 retenue** parce que :
-- **Cohérence du modèle mental** : la barrière technique n'étant pas perçue comme un login, la paire **Connexion/Déconnexion** applicative est complète et auto-cohérente — plus aucun mismatch sur le logout (se déconnecter ramène à l'écran de connexion, les deux dans la même couche).
-- **Dégradation gracieuse** : un re-gate après redémarrage navigateur (perte de `sessionStorage`) se lit comme « reconnexion à l'environnement », pas comme un bug.
-- **Implémentation plus simple** : `NextGraphContext` fait déjà le flux `connect`/redirect ; l'écran « Connexion » est un écran in-app normal ; pas de page d'avertissement bespoke.
-- **Similarité avec l'infra cible** (objectif directeur du stopgap) : la forme **« redirect broker → app »** est exactement le flux du vrai multi-wallet. À la migration, on **supprime l'écran « Connexion » username** et la **barrière technique devient le vrai login per-user** — la forme du flux ne change pas.
-
-## Faits techniques vérifiés (`nextgraph-rs`, 2026-06-15)
-
-- **Persistance de session : OUI.** Wallet mémorisé côté iframe broker (`localStorage` long-terme + `sessionStorage` pour la session active) ; au rechargement, `init()` retrouve la session **sans re-déclencher le redirect** tant que la session broker existe (`sdk/js/web/src/index.ts`, `sdk/js/api-web/main.ts`). Un **redémarrage complet du navigateur** (perte de `sessionStorage`) peut re-déclencher le gate.
-- **Logout réel exposé : OUI.** `ng.session_stop()`, `ng.user_disconnect()`, `ng.wallet_close()` (`sdk/js/lib-wasm/src/lib.rs`) ; arrêtent la session / effacent le wallet ; **forcent un nouveau redirect** ensuite → d'où le choix de **ne pas** les appeler dans la « Déconnexion » applicative et de planquer le vrai logout.
-
-## Conséquences côté code (Festipod)
-
-- `NextGraphContext` — déclencher le `connect`/redirect **au boot**, avant le rendu de l'app (+ splash pré-redirect).
-- Un écran applicatif **« Connexion »** (username → `localStorage` / `currentAccountId`), username résolu contre les comptes du `sharedWalletShim`.
-- Une **« Déconnexion »** qui efface seulement le username (aucun appel NG).
-- Vrai logout exposé seulement en réglages/debug.
-
-## See Also
-
-- [[brief_2026-06-15_shared-wallet-shim]] — le stopgap que cette décision complète
-- Concept `data-layer` — `NextGraphContext`, auto-init conditionnel, flux redirect broker

.project/concepts/nextgraph-platform/decision_2026-06-17_assisted-wallet-import.md

@@ -1,53 +0,0 @@
----
-type: decision
-summary: Distribution du wallet partagé par IMPORT ASSISTÉ PAR FICHIER (.ngw) — l'auto-import zéro-touche étant impossible (broker hébergé), Festipod sert le FICHIER du wallet (téléchargement) + le mot de passe et guide un import unique sur nextgraph.eu « Import a Wallet File » depuis l'AccessGateScreen. Le TextCode a d'abord été retenu puis CORRIGÉ (transfert temporaire 5 min, inutilisable à embarquer). Barrière d'accès ON par défaut (ACCESS_GATE_DISABLED=1 pour bypass tests/dev), ancien LoginScreen retiré. Alternatives écartées (auto-import app, lien magique, self-host) ; provisioning de test (storageState) distinct
-last_updated: 2026-06-29
----
-
-# Décision 2026-06-17 — Distribution du wallet partagé par import assisté
-
-Comment un utilisateur récupère le wallet partagé sur un nouveau navigateur, dans le stopgap [[brief_2026-06-15_shared-wallet-shim]]. Frozen.
-
-## Contrainte de départ
-
-L'auto-import zéro-touche par l'app est **impossible** avec le broker hébergé (fait vérifié : [[knowledge_broker-import-constraint]]). Le wallet doit préexister dans le navigateur, importé sur `nextgraph.eu` (cross-origin, non pilotable par Festipod). La question n'est donc pas « comment auto-importer » mais « comment **minimiser la friction de récupération** » — le problème initial étant que l'utilisateur devait d'abord *se procurer* le wallet.
-
-## Décision : import assisté par FICHIER
-
-Festipod **sert le FICHIER `.ngw`** du wallet partagé (téléchargement) et **affiche le mot de passe** dans l'`AccessGateScreen` (la barrière d'accès, cf. [[decision_2026-06-15_shared-wallet-login-flow]]), avec un guide en 3 étapes :
-
-1. Télécharger le fichier du wallet partagé (bouton de téléchargement).
-2. Ouvrir `https://nextgraph.eu/#/wallet/login` (nouvel onglet) → « Import a Wallet File » → choisir le fichier → saisir le mot de passe affiché.
-3. Revenir et cliquer « Entrer » (redirect broker → demande de déverrouiller le wallet → mot de passe → app).
-
-Festipod **fournit** ainsi le wallet (fin de la friction de récupération) ; l'**import lui-même reste un geste manuel unique par device**, incompressible avec le broker hébergé. Posture **zéro-sécurité, credential partagé** assumée (cf. brief) → embarquer le fichier + le mot de passe est cohérent.
-
-> **Correction 2026-06-25 (le TextCode était une fausse piste)** : la 1ʳᵉ version embarquait le **TextCode**. Or le TextCode est un **transfert temporaire** (5 min, deux devices en ligne, usage unique — cf. [[knowledge_broker-import-constraint]]), donc **inutilisable embarqué** (un testeur arrivant plus tard aurait un code mort). Le test e2e passait quand même car il génère+importe le code dans la foulée. La primitive correcte est le **FICHIER statique**.
-
-## Pourquoi (alternatives écartées)
-
-- **(a) Auto-import embarqué par l'app** — *impossible* : le broker ne laisse aucune fenêtre d'exécution avant son gate wallet ([[knowledge_broker-import-constraint]]).
-- **(b) TextCode embarqué** — *cassé* : transfert temporaire 5 min, non réutilisable (cf. correction ci-dessus).
-- **(c) Lien magique pré-rempli** vers le broker — pas de route d'import par URL côté broker hébergé.
-- **(d) Self-host / fork du ng-app** — seule voie vers le **vrai zéro-touche**, mais lourde ; track séparé ([[brief_2026-05-21_fork-nextgraph-inbox]]). Non retenu pour le stopgap.
-
-## Conséquences côté code (Festipod)
-
-- `src/modules/auth/sharedWallet.ts` — `SHARED_WALLET_PASSWORD` lu depuis un **global gravé au build** `globalThis.__FESTIPOD_SHARED_WALLET_PASSWORD__` (`define` dans `build.ts`, depuis `FESTIPOD_SHARED_WALLET_PASSWORD`) ; `SHARED_WALLET_FILE_URL = /shared-wallet.ngw` ; `hasSharedWallet()` (mot de passe non vide) pilote l'affichage. Vide par défaut → la barrière retombe sur le flux simple.
-- `build.ts` — copie le fichier (`FESTIPOD_SHARED_WALLET_FILE`) dans le bundle en `/shared-wallet.ngw` + grave le mot de passe.
-- `src/modules/auth/screens/AccessGateScreen.tsx` — section assistée (téléchargement du fichier + mot de passe + guide) affichée si `hasSharedWallet()`.
-- `src/app/AuthGate.tsx` — la barrière est **ON PAR DÉFAUT** (« Festipod ne fonctionne jamais sans NextGraph »). **Révision 2026-06-29** : drapeau **inversé** — la barrière n'est désactivée que si `globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ === true` (gravé par `build.ts` depuis `ACCESS_GATE_DISABLED=1`, ou injecté par le harness via `context.addInitScript` pour `@e2e`). Absent → barrière ON. (Remplace l'ancien `FESTIPOD_STAGING`/`__FESTIPOD_REQUIRE_NG__`, qui était OFF par défaut.)
-- **Ancien `LoginScreen` retiré** (`/login`, bouton « Se connecter avec NextGraph » + login démo email/mdp) : obsolète puisque l'`AccessGateScreen` précède le routeur. Évite le dead-end « connecter sans wallet ». Route `/login` supprimée.
-- **Atterrissage post-login** : après le choix du pseudo, `ConnexionScreen` navigue vers `/home` (la redirection vers l'accueil que faisait l'ancien `LoginScreen` avait disparu avec lui → on retombait sur l'onboarding `WelcomeScreen` à `/`). Filet pour les retours : `WelcomeScreen` redirige vers `/home` si déjà connecté. L'e2e `@humain` va désormais jusqu'à l'accueil pour couvrir ça.
-- L'admin exporte le fichier une fois (nextgraph.eu : menu wallet → Download/Export Wallet File) et l'injecte au build (`FESTIPOD_SHARED_WALLET_FILE=<chemin.ngw> FESTIPOD_SHARED_WALLET_PASSWORD=<mdp> bun run build` ; barrière ON par défaut, pas de drapeau à poser).
-
-## À distinguer du provisioning de test
-
-Le harness multi-navigateur provisionne le wallet partagé par **injection storageState** (niveau navigateur, sans la contrainte broker) — concept `bdd-testing` → `knowledge_multibrowser-harness`. Cela **prouve** « wallet partagé → app connectée » mais **court-circuite l'import**. Le mécanisme RÉEL est validé **de bout en bout par la vraie app** (e2e `@humain`) : un navigateur vierge ouvre l'app staging, **télécharge le fichier proposé par l'`AccessGateScreen`** (et vérifie que le mot de passe affiché est celui du wallet), l'importe via le vrai flux `nextgraph.eu` « Import a Wallet File », revient, clique « Entrer » et atteint l'app connectée. Les deux ne se confondent pas.
-
-## See Also
-
-- [[knowledge_broker-import-constraint]] — le fait technique qui force cette décision
-- [[brief_2026-06-15_shared-wallet-shim]] — le stopgap
-- [[decision_2026-06-15_shared-wallet-login-flow]] — le flux d'accès dont l'AccessGateScreen est la barrière
-- [[knowledge_stores-permissions]] — wallet, capabilities, limites SDK

.project/concepts/nextgraph-platform/knowledge_broker-import-constraint.md

@@ -1,69 +0,0 @@
----
-type: knowledge
-summary: Le broker NextGraph hébergé n'autorise pas l'auto-import d'un wallet par une web-app tierce — init() top-level redirige, toute méthode ng.* exige d'être déjà loggé dans l'iframe, et le broker renvoie un device sans wallet vers nextgraph.eu (cross-origin, non pilotable). Un wallet doit préexister dans le navigateur. Des 4 méthodes d'import nextgraph.eu, seul le FICHIER .ngw est statique/réutilisable ; le TextCode/QR sont des transferts temporaires (5 min, deux devices en ligne) inutilisables à embarquer.
-last_checked: 2026-06-25
----
-
-# Contrainte : pas d'auto-import de wallet par une web-app tierce
-
-Fait technique **vérifié empiriquement (2026-06-17)** : avec le broker NextGraph **hébergé** (`nextgraph.net`), une web-app tierce (Festipod) **ne peut pas** provisionner/importer un wallet par programme. Le wallet doit **préexister** dans le navigateur avant que le redirect d'authentification puisse réussir.
-
-## Pourquoi (mécanisme du proxy `@ng-org/web`)
-
-Lecture de `ngweb.js` (dist de `@ng-org/web`) :
-
-- **`init()` top-level REDIRIGE** : si `window.self === window.top`, il fait `window.location.href = https://nextgraph.net/redir/#/?o=<url>`. Le code de l'app ne tourne plus.
-- **Toute méthode `ng.*` est relayée** par `parent.postMessage` vers `nextgraph.net`, et le handler **lève `"you must call init() first"` tant que la session n'est pas établie** (garde interne `d !== false`). Cela inclut `wallet_import_from_code`, `add_in_memory_wallet`, `session_in_memory_start`.
-- L'app tierce ne s'exécute **dans l'iframe qu'APRÈS** que le broker a déjà ouvert un wallet et établi la session. **Il n'existe aucune fenêtre** où notre code tourne *avant* le gate wallet du broker → **rien à quoi accrocher un auto-import**.
-
-> Vérifier : `node_modules/@ng-org/web/dist/ngweb.js` — fonction `init` (redirect / postMessage selon top-vs-iframe) et le handler `apply` du Proxy `ng`. Cohérent avec [[knowledge_integration-model]] (le verifier tourne dans l'iframe du ng-app, le proxy ne fait que relayer).
-
-## Ce que montre le broker (probe Playwright, navigateur frais sans wallet)
-
-Sur `https://nextgraph.net/redir/#/?o=...`, le broker affiche **littéralement** :
-
-> « We could not find a wallet in your browser. For now, creating a new wallet while a Web App is authenticating, is not implemented. Please create or import your wallet in a new tab. »
-
-…et renvoie vers `https://nextgraph.eu/` (app wallet **standalone**). L'import standalone (`/#/wallet/login`) propose **4 méthodes**, mais elles ne sont **PAS équivalentes** :
-
-| Méthode | Nature | Embarquable / réutilisable ? |
-|---|---|---|
-| **Import a Wallet File** (`.ngw`) | **fichier statique** (export portable, hors-ligne) | ✅ **oui** — statique, sans expiration, sans device source |
-| Import with TextCode | **transfert temporaire** device↔device via leurs serveurs : **5 min**, **les deux appareils en ligne**, usage unique | ❌ non |
-| Import with QR-Code | transfert live (même famille que TextCode) | ❌ non |
-| Import via Username | récupération liée à un compte | à étudier |
-
-> **Piège vérifié (2026-06-25)** : le **TextCode n'est PAS un export statique** — l'écran nextgraph.eu le dit (« temporarily stored on our servers for up to 5 minutes », « both devices need to be online »). L'embarquer dans l'app est **inutilisable** : il expire / est à usage unique. Un test automatisé qui génère ET importe le code dans la foulée **passe** (live), masquant le problème — d'où une fausse piste initiale. **La primitive correcte pour un wallet partagé embarqué = le FICHIER `.ngw`.**
-
-## Logique du redirect nextgraph.net (broker discovery) + ORDRE critique
-
-`init()` redirige vers `nextgraph.net/redir`. Là, nextgraph.net regarde dans le **localStorage** s'il connaît un **broker** (le domaine du broker, posé lors d'un import/login wallet antérieur) :
-
-- **trouvé** → redirige vers le broker (`nextgraph.eu/auth/#/wallet/login` → « Click here to login with your wallet <nom> » → mot de passe) → app. **Cas qui marche.**
-- **absent** → message « We could not find a wallet in your browser… Please create or import your wallet in a new tab by clicking here ». Le lien ouvre `nextgraph.eu` (page **Welcome**) → **Login** → **Import a Wallet File** → on rejoint l'import.
-
-> **Ordre critique** : il faut **importer le wallet AVANT** d'atteindre nextgraph.net. Le guide de l'`AccessGateScreen` impose cet ordre (télécharger + importer, *puis* « Entrer »).
-
-**Deux routes vers l'import** : **A** = lien direct `nextgraph.eu/#/wallet/login` (celui de Festipod + des tests — saute la page Welcome/Login) ; **B** = fallback nextgraph.net « no wallet → clicking here » → Welcome → **Login** → Import (si on atteint nextgraph.net sans wallet).
-
-**Pourquoi l'e2e `@humain` ne bute pas sur le « no wallet »** : il importe le fichier (route A) **avant** le « Entrer », donc nextgraph.net trouve déjà le broker. Le test **ne couvre pas** la route B (message « no wallet » + page Welcome/Login de nextgraph.eu) — ce sont des comportements nextgraph, pas Festipod, mais un humain cliquant « Entrer » en premier y tombe.
-
-> **Atténuation côté Festipod (2026-06-29)** : la barrière `AccessGateScreen` (qui **fournit** le fichier wallet + le mot de passe + le guide) est désormais l'écran d'entrée **par défaut** (cf. [[decision_2026-06-17_assisted-wallet-import]]) — l'ancien `LoginScreen` « Se connecter avec NextGraph » (qui menait directement au redirect sans fournir le wallet) a été retiré. Un utilisateur ne peut donc plus atteindre nextgraph.net **sans** que Festipod lui ait d'abord proposé le wallet. La route B reste possible s'il clique « Entrer » avant d'importer, mais il a le wallet sous les yeux pour le faire.
-
-> **Contrainte UX irréductible + dé-piégeage** : « Entrer » fait une **redirection pleine-page**. Si on clique AVANT d'importer → message « no wallet » → l'import se fait dans un **autre onglet** sans retour auto vers Festipod (le broker hébergé ne sait pas revenir). Il faut donc **importer d'abord, PUIS Entrer** (guide de l'`AccessGateScreen`, ordre du `@humain`). Piège corrigé (2026-06-29) : au retour (back) après un « Entrer » prématuré, la page standalone était restaurée du bfcache avec l'état figé sur `connecting` → bouton « Accès en cours » bloqué ; `NextGraphContext` écoute `pageshow.persisted` (sans session) et réinitialise sur `disconnected` pour permettre de réessayer.
-
-## Pistes d'élimination du va-et-vient — testées, ÉCARTÉES (2026-06-30)
-
-Deux idées pour éviter le 2ᵉ onglet ; les deux **infaisables** sans fork :
-
-1. **Embarquer `nextgraph.eu` en iframe** dans Festipod pour guider l'import sur le même écran. nextgraph.eu **n'a pas** d'en-tête anti-framing (embed possible, import OK dans l'iframe), **MAIS** le wallet importé atterrit dans le stockage **partitionné** `(top: festipod, frame: nextgraph.eu)` — invisible du login top-level → « no wallet ». **Confirmé en vrai navigateur (Chrome).** ⚠️ **Le Chromium de Playwright N'applique PAS ce partitioning → faux positif** : un probe Playwright montrait le wallet « transmis », alors que le vrai Chrome bloque. Ne jamais valider une question d'**isolation de stockage** via Playwright ; tester en vrai navigateur.
-2. **Déclencher l'écriture cross-origin sur nextgraph.net** : le mécanisme existe (pont `/auth` iframe+postMessage qui écrit `ng_bootstrap` sur nextgraph.net pendant le login nextgraph.eu) mais ce sont **les pages de NextGraph** qui l'orchestrent ; un tiers ne peut pas écrire le localStorage d'une autre origine (same-origin policy), et ça ne couvrirait que la découverte du broker, pas le wallet.
-
-→ Seule élimination réelle = self-host/fork du ng-app ([[brief_2026-05-21_fork-nextgraph-inbox]]). Le flow stopgap reste l'import **en onglet séparé** (top-level `nextgraph.eu`, première-partie → pas de partitioning → fonctionne).
-
-## Conséquences
-
-- Le wallet doit être importé **sur `nextgraph.eu` (cross-origin)** — Festipod ne peut **pas** piloter ce flux ni pré-remplir l'import (pas de route d'import par URL côté broker hébergé).
-- Le **vrai zéro-touche** exigerait de **self-host/forker le ng-app** (territoire de [[brief_2026-05-21_fork-nextgraph-inbox]]).
-- Distribution produit retenue, vu cette contrainte : **import assisté par FICHIER** — Festipod fournit le `.ngw` (téléchargement) + le mot de passe et guide l'import — voir [[decision_2026-06-17_assisted-wallet-import]].
-- À ne pas confondre avec le **provisioning de TEST** (injection storageState dans le harness), qui n'a pas cette contrainte car il agit au niveau navigateur — concept `bdd-testing` → `knowledge_multibrowser-harness`.

.project/concepts/nextgraph-platform/knowledge_integration-model.md

@@ -1,51 +0,0 @@
----
-type: knowledge
-summary: Modèle d'intégration NextGraph — @ng-org/web est un proxy iframe (verifier tourne dans l'iframe ng-app, pas dans le broker), reciblable au build via NG_REDIR_SERVER/NG_DEV*, broker ngd stateful WebSocket ; modifier le verifier = rebuilder le ng-app, pas le broker
-last_checked: 2026-05-21
----
-
-# Modèle d'intégration et de déploiement NextGraph
-
-Comment une app web tierce s'intègre à NextGraph, et **où tourne le moteur (verifier)**. Vérifié dans `nextgraph-rs` le 2026-05-21.
-
-NextGraph s'utilise via un **proxy iframe** (`@ng-org/web`) : l'app tierce ne contient pas le moteur, elle délègue à un ng-app hébergé (défaut `nextgraph.net`) qui exécute le moteur dans une iframe.
-
-## Les paquets JS
-
-- **`@ng-org/web`** — paquet **publié**. Proxy postMessage léger (aucun wasm embarqué). **Le** chemin d'intégration tierce ; `@ng-org/orm` et tous les exemples en dépendent. **Festipod l'utilise.**
-- **`@ng-org/api-web`** — **privé** (non publié). Moteur navigateur complet (charge `@ng-org/lib-wasm` dans un Web Worker). Consommé uniquement par `app/nextgraph` (frontend ng-app) — **pas** une cible d'intégration tierce.
-- **`@ng-org/lib-wasm`** — moteur compilé wasm (contient le verifier). Source `sdk/js/lib-wasm/`.
-- **`nextgraph`** (npm) — API NodeJS (build `pkg-node`).
-- **`@ng-org/orm`** — ORM réactif (`useShape`…), bâti sur `@ng-org/web`.
-
-## Où tourne le verifier
-
-Dans le modèle web standard (iframe), le verifier tourne **dans l'iframe** : `app/nextgraph` charge `api-web` → `lib-wasm` dans un Web Worker, côté navigateur. Le broker (`ngd`) ne fait que **transport et stockage**.
-
-**Conséquence** : modifier la logique du verifier (`request_processor`, `inbox_processor`) = reconstruire le **ng-app**, pas le broker.
-
-## Le modèle iframe & reciblage build-time
-
-`@ng-org/web` redirige vers le ng-app hébergé, qui recharge l'app tierce en iframe après auth, puis relaie par `postMessage`. **Reciblable au build** (`sdk/js/web/src/index.ts`, `import.meta.env`) :
-
-| Variable | Cible |
-|---|---|
-| `NG_REDIR_SERVER` | défaut `nextgraph.net` |
-| `NG_DEV3` | `127.0.0.1:3033` |
-| `NG_DEV` | `localhost:14402`/`14404` |
-| `NG_DEV_LOCAL_BROKER` | `localhost:1421` |
-
-**Pas d'override runtime** — `init()` ne prend pas d'URL broker. Pour pointer vers un ng-app auto-hébergé : **rebuilder `@ng-org/web`** (TS pur, sans wasm → build trivial).
-
-## Plomberie proxy ↔ iframe ↔ worker (générique)
-
-Le chemin d'appel d'une méthode est **entièrement générique** (aucune allowlist) : `@ng-org/web` est un `Proxy` JS qui relaie *n'importe quel* nom de méthode par `postMessage` ; `app/nextgraph` dispatch via `Reflect.apply(ng[method], …)`. **Conséquence** : une nouvelle fonction wasm en requête/réponse simple est *atteignable* sans toucher le JS — mais c'est un **hack** non typé (test rapide, pas un plan ; cf. [[brief_2026-05-21_fork-nextgraph-inbox]]). Cas **streamé** : exige une entrée des deux côtés (`E` dans `@ng-org/web` + `streamed_api` dans api-web ; méthodes streamées actuelles : `doc_subscribe`, `orm_start_graph`, `orm_start_discrete`, `file_get`, `app_request_stream`).
-
-## Le broker (ngd)
-
-- Supporte déjà nativement l'inbox (`inbox_post`, `inbox_register`, `inbox_pop_for_user` dans `engine/net/src/server_broker.rs`) — un `ngd` standard routerait l'inbox, **aucun patch broker nécessaire**.
-- Démon **WebSocket** (`async-tungstenite`), **stateful** : RocksDB sous `--base-path`, PeerId persisté (volume critique).
-- CLI : `--local PORT`, `--domain DOMAIN:PORT,LOCAL_PORT` (mode derrière reverse-proxy TLS-terminé type Traefik/Coolify).
-- **Ne sert pas de statique** : le ng-app frontend est un déploiement statique séparé (`pnpm webfilebuild`). Premier démarrage **interactif** (lien d'invitation wallet admin). Dockerfiles officiels **cassés**.
-
-> Détail du déploiement depuis un fork : [[brief_2026-05-21_fork-nextgraph-inbox]] §Couche 2.

.project/concepts/nextgraph-platform/knowledge_stores-permissions.md

@@ -1,60 +0,0 @@
----
-type: knowledge
-summary: Référence des 5 types de stores NextGraph et leurs droits, document=repo, granularité des permissions, capability/Nuri, inbox native (anonymat via from optionnel), et ce que le SDK @ng-org/web n'expose PAS
-last_checked: 2026-05-21
----
-
-# Stores NextGraph et droits d'accès
-
-Référence des primitives de stockage et permission de NextGraph (**système externe**, pas le code de Festipod). Socle des briefs [[brief_2026-05-17_multi-store-refactor]] et [[brief_2026-05-18_authorization-matrix]].
-
-Source : doc NextGraph officielle ([Documents & Stores](https://docs.nextgraph.org/en/documents/), [Getting started](https://docs.nextgraph.org/en/getting-started/)) vérifiée le 2026-05-21.
-
-## Points d'entrée du code source local
-
-Repo cloné en `../../nextgraph/nextgraph-rs` (cf. `_overview`) :
-- `sdk/js/lib-wasm/src/lib.rs` — API wasm effectivement exposée au JS.
-- `engine/net/src/app_protocol.rs` — enum `AppRequestCommandV0`, formats `NuriV0`.
-- `engine/verifier/src/request_processor.rs` — dispatch effectif des `app_request` (la vérité sur ce qui est *traité*).
-- `engine/net/src/types.rs` — types inbox (`InboxPost`, `InboxMsg`, `InboxMsgContent`).
-- `engine/verifier/src/inbox_processor.rs` — traitement des messages d'inbox.
-
-## Les 5 types de stores
-
-| Store | Lecture | Écriture | Création |
-|---|---|---|---|
-| **Private** | Titulaire seul | Titulaire seul | Par défaut |
-| **Protected** | Titulaire + détenteurs d'un lien + permission | Titulaire + collaborateurs permissionnés | Par défaut |
-| **Public** | Tout le monde, sans capability | Titulaire seul | Par défaut |
-| **Group** | Membres du groupe | Membres du groupe (collaboratif) | À la demande |
-| **Dialog** | Les deux utilisateurs uniquement | Les deux utilisateurs uniquement | À la demande |
-
-Citations doc (verbatim) : Private — *« only you have access to … not possible to share »* ; Protected — *« share … but they will need a special link and permission »*, *« protected social profile »* ; Public — *« equivalent to your website … without the need for special permissions »* ; Group — *« each Group is a separate Store … documents inherit the permissions of the store »* ; Dialog — *« hold all the data you exchange with another user (and only with that other user) … You cannot add more users »*.
-
-Tout wallet a d'office les **3 stores** private/protected/public (session : `private_store_id`, `protected_store_id`, `public_store_id`). Group et Dialog se créent à la demande.
-
-## Concepts transverses
-
-**Document vs Repo.** *« A Repo is the equivalent of an E2EE group for one and only one Document. »* **1 document = 1 repo** (commits + permissions). Identifiant : `did:ng:o:<RepoID>`. Un **store** est lui-même un document spécial qui regroupe et permissionne d'autres documents.
-
-**Granularité.** Écriture gérée au niveau **Document (repo)**, pas branche/bloc. Lecture plus fine possible (par bloc/branche). Héritage : un Group store peut faire hériter ses permissions à ses documents.
-
-**Capability / Nuri.** Le partage transmet un **Nuri** embarquant la capability crypto (lecture et/ou écriture). Pas d'ACL centralisée : posséder le Nuri = le droit. *« adding permissions can be done offline »* ; *« removing permissions … requires a SyncSignature »* (synchrone).
-
-## Inbox
-
-**Chaque document a une inbox native.** Un non-éditeur peut y **déposer un lien (DID cap)** sans être invité éditeur ; le propriétaire **modère**. NURI : `did:ng:d:<inbox_id>`. Contenu : enum `InboxMsgContent` (`ContactDetails`, `DialogRequest`, **`Link`**, `Patch`, `ServiceRequest`, `ExtRequest`, `RemoteQuery`, `SocialQuery`…). Message **scellé** (`crypto_box::seal`) vers la pubkey de l'inbox → seul le titulaire déchiffre. Champ `from` **optionnel** → expéditeur **anonyme** possible. C'est le « identifié si connu, anonyme sinon » voulu par Festipod, **natif au protocole** (mécanisme retenu pour la notification d'inscription, cf. [[brief_2026-05-18_authorization-matrix]]).
-
-### L'inbox n'est PAS utilisable directement depuis le SDK JS
-
-- `app_request(request)` est exposé, et `AppRequestCommandV0::InboxPost` + `AppRequest::inbox_post()` existent. **MAIS** le `request_processor` du verifier **n'a aucun bras `InboxPost`** (commandes traitées : `OrmStart(Discrete)`, `Fetch`, `FileGet`, `OrmUpdate`, `OrmDiscreteUpdate`, `SocialQueryStart`, `QrCodeProfile(Import)`, `Header`, `Create`, `FilePut`). Envoyer un `InboxPost` ne déclenche rien.
-- Construire un `InboxPost` exige le scellement crypto côté Rust ; **aucun helper wasm** ne l'expose.
-- Le dépôt en inbox n'est déclenché qu'**en interne** par `QrCodeProfileImport` (`post_to_inbox(new_contact_details)`) et `social_query_start` (propagation via inbox des **contacts**).
-
-**Conséquence** : pas de moyen propre de « drop a Link » arbitraire dans l'inbox d'un PdR depuis le SDK JS aujourd'hui. → chantier [[brief_2026-05-21_fork-nextgraph-inbox]]. Piste connexe : `social_query_start` EST exposé (requête fédérée via inbox jusqu'à `degree` sauts) mais limité aux **contacts** (ne couvre pas la notif anonyme vers un hôte non-connecté).
-
-## Limites du SDK JS
-
-`@ng-org/web` (vérifié `0.1.2-alpha.13` = `upstream/main` au 2026-05-21, version installée) **n'expose pas** : création de Group/Dialog store ; partage de capability (Nuri avec droits) ; manipulation de permissions ; dépôt/lecture d'inbox.
-
-Méthodes JS disponibles : `doc_create`, `doc_subscribe`, `sparql_query`, `sparql_update`, `orm_start_graph`, `orm_start_discrete`, `graph_orm_update`, `discrete_orm_update`, `file_get`, `app_request_stream`. La doc annonce *« An API will be provided for permission manipulation »* (sans date).

.project/concepts/tech-stack/_overview.md

@@ -1,6 +1,6 @@
 ---
 type: _overview
-summary: Stack et outillage — Bun-first (runtime, bundler, APIs natives), build pipeline, et commandes du projet
+summary: Stack and tooling — Bun-first (runtime, bundler, native APIs), build pipeline, and the project's commands
 triggers:
   keywords: [bun, bunx, build, bundler, vite, webpack, jest, npm, storybook, "bun.serve", hmr, tailwind, package.json]
   paths: ["build.ts", "package.json", "bunfig.toml", "tsconfig.json", "src/index.ts", "src/index.html", ".storybook/**", "scripts/**"]
@@ -8,14 +8,14 @@ triggers:
 
 # Tech stack
 
-Stack et outillage du projet. Principe directeur : **Bun-first** — Bun remplace Node/npm/vite/webpack/jest et fournit les APIs serveur natives.
+The project's stack and tooling. Guiding principle: **Bun-first** — Bun replaces Node/npm/vite/webpack/jest and provides the native server APIs.
 
-**À lire en premier :** [[rule_bun-first]] — la convention qui décide quel outil utiliser.
+**Read this first:** [[rule_bun-first]] — the convention that decides which tool to use.
 
-## Liens
+## Links
 
-- [[rule_bun-first]] — utiliser Bun, pas Node/npm/vite/jest/express/ws/pg…
-- [[knowledge_bun-apis]] — APIs natives Bun (serve, sqlite, redis, sql, file, shell)
-- [[knowledge_build-pipeline]] — build.ts, bundler, serveur, harness buildé à part, Storybook
-- [[knowledge_stack-and-commands]] — composants de la stack + scripts réels (+ quirks)
-- [[knowledge_deployment]] — Dockerfile, prod depuis src/, pas de CI, `portless` en dev
+- [[rule_bun-first]] — use Bun, not Node/npm/vite/jest/express/ws/pg…
+- [[knowledge_bun-apis]] — native Bun APIs (serve, sqlite, redis, sql, file, shell)
+- [[knowledge_build-pipeline]] — build.ts, bundler, server, harness built separately, Storybook
+- [[knowledge_stack-and-commands]] — stack components + the real scripts (plus quirks)
+- [[knowledge_deployment]] — Dockerfile, prod served from src/, no CI, `portless` in dev

.project/concepts/tech-stack/caveat_firefox-lna-blocks-broker-iframe.md

@@ -0,0 +1,26 @@
+---
+type: caveat
+summary: Firefox 151+ blocks (Local Network Access) the hosted broker embedding the local dev app in its iframe → blank iframe, zero app logs, no error at all. This is NOT a code bug. Browser-side fix — about:config network.lna.enabled=false.
+last_checked: 2026-08-10
+---
+
+# Firefox LNA blocks the broker's app iframe in local dev
+
+## Symptom
+
+In local dev, the app runs INSIDE the hosted broker's iframe (`nextgraph.eu`/`nextgraph.net` over HTTPS embeds `festipod.localhost` → `127.0.0.1`). On **Firefox 151+**, the iframe stays **blank**: **no `[FestipodData]`/`[NG]` log at all** (the app's JS never runs), and **no red error** either (the block is a network policy decision, not a throw). Easy to mistake for a Festipod rendering crash — it is NOT one.
+
+## Cause
+
+**Local Network Access (LNA)**: Firefox 151+ (on by default, see the 149→151 rollout) forbids a **public site** (the HTTPS broker) from reaching a **local network resource** (`127.0.0.1`) — including embedding it in an iframe. The telltale console log:
+`Local Network Access detected: ... accessing target "…festipod.localhost…" (127.0.0.1) … prompt action: auto_deny`.
+
+Two corollaries that mislead:
+- **The top level loads just fine**: navigating directly to `https://festipod.localhost:1355` is NOT subject to LNA. Only **iframe embedding** by the broker is. So "the cert is already accepted / the app starts up" before the iframe does not mean the iframe will go through.
+- **HTTPS changes nothing**: LNA targets the **local destination address**, not the protocol. Switching to `portless proxy start --https` (app on `https://festipod.localhost`) does not unblock it.
+
+## Fix (browser, not code)
+
+`about:config` → **`network.lna.enabled` = `false`** (master flag: disables every LNA check). Targeted alternative: **`network.lna.skip-domains`** with `nextgraph.eu`, `nextgraph.net` (keeps the protection everywhere else). Other LNA prefs: `network.lna.blocking`, `network.lna.block_trackers`.
+
+Do NOT go hunting for a Festipod rendering bug as long as there is **no `[FestipodData]` log** in the console: with no app logs, the app never ran → it is the environment (LNA, untrusted cert, dev server down), not the code. The `@e2e` smoke test CANNOT catch this: Playwright does not enforce LNA the way a real Firefox does.

.project/concepts/tech-stack/knowledge_build-pipeline.md

@@ -1,25 +1,40 @@
 ---
 type: knowledge
-summary: Dev en bun --hot, build prod via build.ts (bundler Bun + plugin Tailwind) vers dist/, alias @/* → ./src/*
+summary: Dev runs on bun --hot, prod builds through build.ts (Bun bundler + Tailwind plugin) into dist/, path alias @/* → ./src/*
+last_checked: 2026-08-10
 ---
 
 # Build pipeline
 
-- **Dev** : `bun --hot src/index.ts` (via `bun run dev`) — HMR, port 3000.
-- **Prod** : `bun run build` → `build.ts` (bundler Bun + plugin Tailwind) → `dist/`.
-- **Alias de chemin** : `@/* → ./src/*` (déclaré dans `tsconfig.json`).
+- **Dev**: `bun --hot src/index.ts` (through `bun run dev`) — HMR, port 3000.
+- **Prod**: `bun run build` → `build.ts` (Bun bundler + Tailwind plugin) → `dist/`.
+- **Path alias**: `@/* → ./src/*` (declared in `tsconfig.json`, resolved relative to that file — `paths` has needed no `baseUrl` since TS 4.4).
 
-Le serveur sert `src/index.html`, qui charge `src/app/frontend.tsx` (voir `app-architecture` §app-shell). Le bundler transpile le TSX et bundle le CSS sans outil externe — pas de Vite/webpack/esbuild (cf. [[rule_bun-first]]).
+> ⚠️ **Never put `baseUrl` back in `tsconfig.json`.** TypeScript 6 reports it as an **error that aborts the whole compilation**, and the failure is silent where it hurts: `tsc --noEmit` then exits **0 having checked nothing**, so the typecheck gate goes green over any amount of broken code. A green typecheck is only meaningful if `tsc` actually ran — treat an instant, output-free `tsc` as a red flag, not a fast pass.
 
-## Détails de `build.ts` et du serveur
+The server serves `src/index.html`, which loads `src/app/frontend.tsx` (see `app-architecture` §app-shell). The bundler transpiles the TSX and bundles the CSS without any external tool — no Vite/webpack/esbuild (see [[rule_bun-first]]).
 
-- `build.ts` scanne `src/**/*.html` comme entrypoints (aujourd'hui un seul : `src/index.html`), `target: 'browser'`, minify + sourcemap linked, plugin `bun-plugin-tailwind`. Ajouter un 2e `.html` créerait un 2e bundle.
-- `src/index.ts` (`Bun.serve`) sert : `/reports/cucumber` (rapport HTML), des stubs `/api/hello*`, et un **catch-all `/*` → `src/index.html`** (routing SPA, doit rester en dernier). HMR si `NODE_ENV !== 'production'`, port via `PORT`.
+## Details of `build.ts` and of the server
 
-## Le harness de test est buildé à part
+- `build.ts` scans `src/**/*.html` for entrypoints (today just one: `src/index.html`), `target: 'browser'`, minify plus linked sourcemap, `bun-plugin-tailwind` plugin. Adding a second `.html` would create a second bundle.
+- `src/index.ts` (`Bun.serve`) serves: `/reports/cucumber` (HTML report), `/api/hello*` stubs, `/festipod-config.json` plus `/shared-wallet.ngw` (runtime config, see below), and a **catch-all `/*` → `src/index.html`** (SPA routing, which must stay last). HMR when `NODE_ENV !== 'production'`, port from `PORT`.
 
-⚠️ `build.ts` ne build **pas** les harness de test. Les hooks Cucumber (`src/shared/support/hooks.ts`) lancent un `bun build` **à la demande** pour `src/shared/test-harness/harness.tsx` (et `harness-ng.tsx`) → `dist/test-harness*.js`. C'est un entrypoint séparé du build app — voir concept `bdd-testing`.
+## Build-time globals vs runtime config (the shared wallet pitfall)
+
+`build.ts` injects **compile-time globals** through `define`: `__FESTIPOD_SHARED_WALLET_PASSWORD__` from `FESTIPOD_SHARED_WALLET_PASSWORD`, and `__FESTIPOD_AUTO_SEED__` from `FESTIPOD_AUTO_SEED` — the dev auto-seed, OFF when absent. **Pitfall**: the `src/index.ts` server (used by `bun run dev` AND `bun run start`) bundles `index.html` through Bun's HTML import, which **applies no `define`** — neither `bun --define` nor `process.env` propagates there (verified). So an environment variable passed to `bun run dev` never reaches the frontend bundle along that path.
+
+For those paths served from `src/`, the configuration therefore goes through the **runtime**: `src/index.ts` exposes `/festipod-config.json` (read from the environment), and the `src/app/frontend.tsx` entry **fetches it first**, sets the global, **then imports the app dynamically** (`await import('./App')`) — so that `sharedWallet.ts` reads the value when it is evaluated. In a `build.ts` bundle the value is already inlined by `define`, so the fetch is skipped (`NODE_ENV === 'production'`). Practical consequence: to exercise the "shared wallet" flow in dev **end to end** (download plus a working import), pass the REAL password of the e2e wallet **and** the file — the password shown on screen must match the imported `.ngw`, otherwise the import fails (a dummy value such as `1` merely makes the screen appear):
+
+```
+FESTIPOD_SHARED_WALLET_PASSWORD=festipod-e2e-tests \
+FESTIPOD_SHARED_WALLET_FILE=./festipod-e2e-tests.ngw \
+bun run dev
+```
+
+## The test harness is built separately
+
+⚠️ `build.ts` does **not** build the test harnesses. The Cucumber hooks (`src/shared/support/hooks.ts`) run a `bun build` **on demand** for `src/shared/test-harness/harness.tsx` (and `harness-ng.tsx`) → `dist/test-harness*.js`. It is an entrypoint separate from the app build — see concept `bdd-testing`.
 
 ## Storybook
 
-`storybook dev -p 6006` — **webpack5 + SWC** (pas Vite). Les décorateurs (`.storybook/`) injectent la pile complète de providers (Theme > NextGraph > FestipodData > Router) et importent `src/index.css` ; viewport mobile par défaut. Couplage dur au contexte projet (pas réutilisable hors Festipod).
+`storybook dev -p 6006` — **webpack5 + SWC** (not Vite). The decorators (`.storybook/`) inject the full provider stack (Theme > NextGraph > FestipodData > Router) and import `src/index.css`; mobile viewport by default. Tightly coupled to the project context (not reusable outside Festipod).

.project/concepts/tech-stack/knowledge_bun-apis.md

@@ -1,15 +1,15 @@
 ---
 type: knowledge
-summary: APIs natives Bun utilisées par le projet — Bun.serve (HTTP/WS/routes), HTML imports bundlés, bun:sqlite, Bun.redis, Bun.sql, Bun.file, Bun.$
+summary: Native Bun APIs used by the project — Bun.serve (HTTP/WS/routes), bundled HTML imports, bun:sqlite, Bun.redis, Bun.sql, Bun.file, Bun.$
 ---
 
-# APIs natives Bun
+# Native Bun APIs
 
-Référence des APIs Bun à privilégier (cf. [[rule_bun-first]]). Doc complète : `node_modules/bun-types/docs/**.mdx`.
+Reference for the Bun APIs to favour (see [[rule_bun-first]]). Full documentation: `node_modules/bun-types/docs/**.mdx`.
 
-## Serveur — `Bun.serve()`
+## Server — `Bun.serve()`
 
-Supporte WebSockets, HTTPS et routes. Pas besoin d'`express`/`ws`.
+Supports WebSockets, HTTPS and routes. No need for `express`/`ws`.
 
 ```ts
 import index from "./index.html"
@@ -23,19 +23,19 @@ Bun.serve({
 })
 ```
 
-C'est le mécanisme de `src/index.ts` (voir concept `app-architecture` §app-shell).
+This is the mechanism behind `src/index.ts` (see concept `app-architecture` §app-shell).
 
 ## HTML imports (frontend)
 
-`Bun.serve()` sert des HTML imports ; le bundler Bun transpile/bundle automatiquement `.tsx`/`.jsx`/`.js` et le CSS (Tailwind inclus). Un `<script type="module" src="./frontend.tsx">` dans le HTML suffit — pas de Vite.
+`Bun.serve()` serves HTML imports; the Bun bundler automatically transpiles and bundles `.tsx`/`.jsx`/`.js` and the CSS (Tailwind included). A `<script type="module" src="./frontend.tsx">` in the HTML is enough — no Vite.
 
-## Stockage & shell
+## Storage & shell
 
-- **`bun:sqlite`** pour SQLite (pas `better-sqlite3`)
-- **`Bun.redis`** pour Redis (pas `ioredis`)
-- **`Bun.sql`** pour Postgres (pas `pg`/`postgres.js`)
-- **`WebSocket`** intégré (pas `ws`)
-- **`Bun.file`** plutôt que `node:fs` readFile/writeFile
-- **`Bun.$\`ls\`** plutôt qu'`execa`
+- **`bun:sqlite`** for SQLite (not `better-sqlite3`)
+- **`Bun.redis`** for Redis (not `ioredis`)
+- **`Bun.sql`** for Postgres (not `pg`/`postgres.js`)
+- **`WebSocket`** built in (not `ws`)
+- **`Bun.file`** rather than `node:fs` readFile/writeFile
+- **`Bun.$\`ls\`** rather than `execa`
 
-Bun charge `.env` automatiquement → ne pas utiliser `dotenv`.
+Bun loads `.env` automatically → do not use `dotenv`.

.project/concepts/tech-stack/knowledge_deployment.md

@@ -1,28 +1,32 @@
 ---
 type: knowledge
-summary: Déploiement — Dockerfile multi-stage Bun Alpine qui lance `bun run start` depuis src/ (pas dist/), EXPOSE 3000, env PORT/NODE_ENV ; aucun CI/CD committé ; dev passe par le wrapper portless
-last_checked: 2026-06-15
+summary: Deployment — multi-stage Bun Alpine Dockerfile; install through pnpm (git+node inside the image) but bun at runtime; runs `bun run start` from src/ (not dist/), EXPOSE 3000, env PORT/NODE_ENV; no CI/CD committed; dev goes through the portless wrapper
+last_checked: 2026-07-14
 ---
 
-# Déploiement & infra
+# Deployment & infra
 
 ## Dockerfile
 
-Un `Dockerfile` existe (multi-stage Bun Alpine) :
-- `FROM oven/bun:1-alpine`, stages `install` (`bun install --frozen-lockfile` depuis `package.json` + `bun.lock`) puis `release` (copie `node_modules` + source).
+A `Dockerfile` exists (multi-stage Bun Alpine). **Installation goes through pnpm, but runtime/build/test stay on bun** (see [[knowledge_stack-and-commands]]):
+- `FROM oven/bun:1-alpine`, `install` stage: `apk add --no-cache git nodejs npm` then `npm install -g pnpm@10.26.0` (the bun image has neither Node nor pnpm; Alpine's `apk nodejs` does not ship corepack), `COPY package.json pnpm-lock.yaml`, then `pnpm install --frozen-lockfile`. `git` is required because `@ng-eventually/polyfill` is a public **git+https** dependency (Gitea, no auth). `release` stage: copies `node_modules` plus the source.
 - `ENV NODE_ENV=production`, `USER bun`, `EXPOSE 3000/tcp`, `ENTRYPOINT ["bun","run","start"]`.
 
-**Quirk** : `start` = `NODE_ENV=production bun src/index.ts` → le conteneur **exécute la source TypeScript directement** (Bun transpile à la volée), il **n'utilise pas `dist/`**. Le `bun run build` (→ `dist/`) n'est donc **pas** sur le chemin de prod par défaut. Si on veut servir le build, il faut changer l'entrypoint.
+**`bun` peer pitfall**: `bun-plugin-tailwind` declares `bun` as a peerDependency → pnpm materializes the npm `bun` package and **creates a `node_modules/.bin/bun` shim** that shadows the `bun` from the PATH under `bun run`/`pnpm run`. Its postinstall is ignored by default → broken shim → `bun run start` fails. Fixed by approving the build: `pnpm.onlyBuiltDependencies: ["bun"]` in `package.json` (the postinstall then downloads the real binary). Without that, the whole pnpm migration breaks startup.
+
+**Quirk**: `start` = `NODE_ENV=production bun src/index.ts` → the container **runs the TypeScript source directly** (Bun transpiles on the fly), it **does not use `dist/`**. `bun run build` (→ `dist/`) is therefore **not** on the default production path. Serving the build would require changing the entrypoint.
 
 ## CI/CD
 
-**Aucun** pipeline committé (`.github/workflows/` absent, pas de config Coolify dans le repo). Angle mort assumé. Pour héberger l'app Bun, le skill `coolify-hosting` s'applique (mentionné aussi dans concept `nextgraph-platform` pour distinguer Festipod du `ngd` Rust).
+**No** pipeline is committed (`.github/workflows/` absent, no Coolify config in the repo). A knowingly accepted blind spot. To host the Bun app, the `coolify-hosting` skill applies.
 
-## Variables d'environnement
+## Environment variables
 
-- `PORT` (défaut 3000), `NODE_ENV` (active/désactive HMR et l'auto-seed dev — cf. concept `data-layer`).
-- Aucun `.env*` committé (`.env` est gitignored). Pas de gestion de secrets dans le repo.
+- `PORT` (default 3000), `NODE_ENV` (enables/disables HMR and the dev auto-seed — see concept `data-layer`).
+- No `.env*` is committed (`.env` is gitignored). No secret management in the repo.
 
 ## Dev
 
-`bun run dev` = **`portless festipod bun --hot src/index.ts`** — passe par le wrapper **`portless`** (outil externe de gestion de port), pas un `bun --hot` nu. HMR actif hors production.
+`bun run dev` = **`portless festipod bun --hot src/index.ts`** — it goes through the **`portless`** wrapper (an external port-management tool), not a bare `bun --hot`. HMR is active outside production.
+
+**Reactive local link to the SDK**: in production the `@ng-eventually/polyfill` dependency comes from Gitea (git+https, pinned by `pnpm-lock.yaml`). When the provider's package has to be exercised from a local checkout, `pnpm run link:polyfill` (script `scripts/link-polyfill.ts`) replaces `node_modules/@ng-eventually/polyfill` with a **real copy** of that checkout (location overridable with `NG_EVENTUALLY_LOCAL`) — **without** its own `node_modules/@ng-org` — and resyncs on every edit. Copying rather than symlinking is what keeps **a single `@ng-org/*` instance** installed: a symlink would drag in a second one and the SDK would stop working. To go back to the committed state: `pnpm install`.

.project/concepts/tech-stack/knowledge_stack-and-commands.md

@@ -1,40 +1,43 @@
 ---
 type: knowledge
-summary: Composants de la stack (Bun, React, NextGraph, Storybook, Cucumber, Tailwind-dans-le-build) et liste réelle des scripts package.json, dont les quirks (cucumber via node+tsx, build:orm au chemin périmé, build:ng pour le fork local)
+summary: Stack components (Bun runtime/build/test, install through pnpm, React, NextGraph, Storybook, Cucumber, Tailwind-inside-the-build) and the real list of package.json scripts, quirks included (cucumber through node+tsx, link:polyfill for the reactive local link)
 ---
 
-# Stack & commandes
+# Stack & commands
 
-## Composants
+## Components
 
-| Couche | Techno |
+| Layer | Technology |
 |---|---|
-| Runtime / bundler / test | **Bun** (cf. [[rule_bun-first]]) |
-| UI | **React** (mobile-first, largeur max 768px — style dans concept `app-architecture`) |
-| Données | **NextGraph** P2P local-first (concept `data-layer`) |
-| Build CSS | **Tailwind** (`tailwindcss` + `bun-plugin-tailwind`) — présent dans le build, mais les écrans stylent via `app-*`/inline, pas d'utilitaires Tailwind (cf. concept `app-architecture`) |
-| Exploration UI | **Storybook** (webpack5 + SWC, port 6006) |
-| Tests | **Cucumber/Gherkin** FR multi-couches + Playwright + happy-dom + chai (concept `bdd-testing`) |
+| Runtime / bundler / test | **Bun** (see [[rule_bun-first]]) |
+| **Dependency installation** | **pnpm** (`pnpm install`, `pnpm-lock.yaml`) — **only** installation moves to pnpm; runtime/build/test stay on bun. Reason: `@ng-eventually/polyfill` is resolved from Gitea over **git+https** (pnpm handles `git+…#main&path:/packages/polyfill` cleanly, along with deduplication of the `@ng-org` peers). Do not switch installation back to bun/npm. |
+| UI | **React** (mobile-first, max width 768px — styling covered by concept `app-architecture`) |
+| Data | **NextGraph** P2P local-first (concept `data-layer`) |
+| CSS build | **Tailwind** (`tailwindcss` + `bun-plugin-tailwind`) — present in the build, but the screens style themselves with `app-*`/inline, no Tailwind utilities (see concept `app-architecture`) |
+| UI exploration | **Storybook** (webpack5 + SWC, port 6006) |
+| Tests | **Cucumber/Gherkin** in French, multi-layer, plus Playwright, happy-dom and chai (concept `bdd-testing`) |
 
-## Scripts `package.json` (réels)
+## `package.json` scripts (the real ones)
 
-| Script | Commande / rôle |
+| Script | Command / role |
 |---|---|
-| `dev` | `portless festipod bun --hot src/index.ts` — dev HMR via wrapper `portless` (cf. [[knowledge_deployment]]) |
-| `start` | `NODE_ENV=production bun src/index.ts` — prod, depuis `src/` (pas `dist/`) |
-| `build` | `bun run build.ts` — bundler Bun + Tailwind → `dist/` ([[knowledge_build-pipeline]]) |
-| `test:cucumber` | enchaîne `cucumber:run` → `cucumber:report` → `features:parse` → `steps:extract` |
-| `cucumber:run` | `node --import tsx/esm …/cucumber-js` — **via Node+tsx, pas Bun** (compat plugins Playwright/happy-dom) |
-| `test:data` | idem `--tags @data` |
-| `test:auth-setup` | `bun scripts/setup-test-auth.ts` — bootstrap wallet de test persistant |
+| `dev` | `portless festipod bun --hot src/index.ts` — dev with HMR through the `portless` wrapper (see [[knowledge_deployment]]) |
+| `start` | `NODE_ENV=production bun src/index.ts` — production, served from `src/` (not `dist/`) |
+| `build` | `bun run build.ts` — Bun bundler + Tailwind → `dist/` ([[knowledge_build-pipeline]]) |
+| `test:cucumber` | chains `cucumber:run` → `cucumber:report` → `features:parse` → `steps:extract` |
+| `cucumber:run` | `node --import tsx/esm node_modules/@cucumber/cucumber/bin/cucumber.js` — **through Node+tsx, not Bun** (Playwright/happy-dom plugin compatibility), and through the package's **actual JS entry**, not the `.bin/` shim (see Pitfalls) |
+| `test:data` | same, with `--tags @data` |
+| `test:auth-setup` | `bun scripts/setup-test-auth.ts` — bootstraps the persistent test wallet |
 | `cucumber:report` | `bun scripts/parse-test-results.ts` — `cucumber-report.json` → HTML |
 | `features:parse` | `bun scripts/parse-features.ts` → `features.ts` |
 | `steps:extract` | `bun scripts/extract-step-definitions.ts` |
-| `build:orm` | `rdf-orm build --input ./src/shapes/shex --output ./src/shapes/orm` |
-| `build:ng` | `bash scripts/build-ng-packages.sh` — rebuild des `@ng-org/*` depuis le fork local (concept `nextgraph-platform`) |
-| `storybook` / `build-storybook` | Storybook dev (6006) / build statique |
+| `build:orm` | `rdf-orm build --input ./src/shared/shapes/shex --output ./src/shared/shapes/orm` |
+| `build:ng` | `bash scripts/build-ng-packages.sh` — (re)builds the NextGraph packages from a local source (optional tool) |
+| `link:polyfill` | `bun scripts/link-polyfill.ts` — **reactive** local link to `@ng-eventually/polyfill` (copy-overlay + watcher). Details in [[knowledge_deployment]]. |
+| `storybook` / `build-storybook` | Storybook dev (6006) / static build |
 
-## Pièges
+## Pitfalls
 
-- **`cucumber:run`/`test:data` tournent sous Node+tsx**, pas Bun — les plugins de test ne chargent pas en import Bun natif. Ne pas « bunifier » ces scripts.
-- **`build:orm` cible `./src/shapes/shex` et `./src/shapes/orm`**, alors que les shapes réelles vivent sous **`src/shared/shapes/`** — le chemin du script est vraisemblablement **périmé** (à corriger ou exécuter avec les bons chemins ; vérifier avant de régénérer l'ORM).
+- **`cucumber:run`/`test:data` run under Node+tsx**, not Bun — the test plugins do not load under a native Bun import. Do not "bunify" these scripts.
+- **Never point a script at `node_modules/.bin/*`.** Installation goes through pnpm ([[rule_bun-first]] §exception), which puts **shell shims** there rather than JS entries: `node --import tsx/esm node_modules/.bin/cucumber-js` fails. Invoke the package's **actual JS entry** (`node_modules/@cucumber/cucumber/bin/cucumber.js`). This holds for any npm script that would launch a dependency's binary under `node`.
+- **`build:orm` was broken until 2026-07-28**: it targeted `./src/shapes/`, which does not exist (the shapes live under `src/shared/shapes/`), so the command exited with an error. **Fixed in `package.json`** — it now runs. Beware of a side effect: the generator has moved on since the committed bindings were produced, so a run reformats them and drops the `: Schema` annotation. That regeneration is a **tool-version bump, not a content fix** — treat it as its own validated change, do not let it ride along.

.project/concepts/tech-stack/rule_bun-first.md

@@ -1,31 +1,39 @@
 ---
 type: rule
-summary: Par défaut utiliser Bun et ses APIs natives, jamais les équivalents Node — bun au lieu de node/ts-node, bun install/test/build, bunx, et pas d'express/ws/pg/dotenv
+summary: By default use Bun and its native APIs, never the Node equivalents — bun instead of node/ts-node, bun test/build, bunx, and no express/ws/pg/dotenv. EXCEPTION — package installation goes through pnpm, not bun install
 ---
 
-# Règle : Bun-first
+# Rule: Bun-first
 
-Par défaut, utiliser **Bun** et ses APIs natives plutôt que les équivalents Node.js.
+By default, use **Bun** and its native APIs rather than the Node.js equivalents.
 
-| Au lieu de… | Utiliser |
+| Instead of… | Use |
 |---|---|
 | `node <file>`, `ts-node` | `bun <file>` |
 | `jest`, `vitest` | `bun test` |
-| `npm/yarn/pnpm install` | `bun install` |
+| `npm/yarn install`, `bun install` | **`pnpm install`** (see the exception below) |
 | `npm run <script>` | `bun run <script>` |
 | `npx <pkg>` | `bunx <pkg>` |
-| `webpack`, `esbuild`, `vite` | `bun build` / bundler Bun (HTML imports) |
+| `webpack`, `esbuild`, `vite` | `bun build` / the Bun bundler (HTML imports) |
 | `express` | `Bun.serve()` |
 | `better-sqlite3` | `bun:sqlite` |
 | `ioredis` | `Bun.redis` |
 | `pg`, `postgres.js` | `Bun.sql` |
-| `ws` | `WebSocket` (intégré) |
+| `ws` | `WebSocket` (built in) |
 | `node:fs` readFile/writeFile | `Bun.file` |
 | `execa` | `Bun.$\`...\`` |
-| `dotenv` | (inutile — Bun charge `.env` automatiquement) |
+| `dotenv` | (pointless — Bun loads `.env` automatically) |
 
-Détail des APIs : [[knowledge_bun-apis]].
+API details: [[knowledge_bun-apis]].
 
-## Pourquoi
+## Exception: package installation goes through pnpm
 
-Le projet est tout-Bun (runtime, bundler, test, serveur). Réintroduire un outil Node redondant ajoute une dépendance, divergerait des conventions du repo, et casse l'intégration native (HMR, transpilation TS automatique, chargement `.env`). C'est un choix de cohérence, pas une préférence cosmétique.
+**Dependencies are installed with `pnpm install`, not `bun install`.** Everything else stays on Bun: **runtime, build, test, scripts** (`bun run dev`, `bun build`, `bun test`, `bunx`). Only the installation step changes package manager.
+
+**Why.** The data SDK is installed from a Gitea repository as a **subdirectory** git dependency: `git+https://…/ng-eventually.git#main&path:/packages/polyfill`. pnpm (≥ 10.26) resolves that `#<ref>&path:/…` format and guarantees a **single** instance of `@ng-org/*`; `bun install` does not handle this workflow cleanly. The reference lockfile is therefore `pnpm-lock.yaml`, and the reactive local link goes through `pnpm run link:polyfill` (see [[knowledge_deployment]]).
+
+**Practical consequence.** npm scripts that relied on `node_modules/.bin/*` may break (pnpm puts shell shims there, not JS entries) — call the package's actual JS entry (e.g. `node_modules/@cucumber/cucumber/bin/cucumber.js`) rather than the `.bin/` shim.
+
+## Why (Bun for everything else)
+
+The project is all-Bun (runtime, bundler, test, server). Reintroducing a redundant Node tool adds a dependency, diverges from the repo's conventions, and breaks the native integration (HMR, automatic TS transpilation, `.env` loading). This is a consistency choice, not a cosmetic preference. The installation exception above is the only deviation, and it is motivated by the subdirectory git dependency.

.project/contracts.yaml

@@ -0,0 +1,22 @@
+# Inter-repo contracts. Festipod is a CONSUMER only: it publishes no interface of its own,
+# and it consumes exactly one — the SDK surface `@ng-eventually/polyfill` engages toward the
+# applications built on it.
+#
+# The pulled copy under `into:` IS the specification Festipod codes against. An agent
+# working here reads that copy and never opens the provider's own source: a gap is raised
+# upstream (see `data-layer/rule_app-uses-sdk-surface-only`), never peeked around.
+#
+# `pullFrom:` names the canonical identity of the provider (its git remote URL + the
+# repo-relative path of the leaf), so the manifest travels with the branch. Per-developer
+# access to a local checkout lives in `.project/contracts.local.yaml`, which is never
+# committed.
+
+consume:
+  - contract: polyfill-surface
+    into: concepts/data-layer
+    type: git
+    pullFrom: https://gitea.reconnexion.apps.gueraud.net/Reconnexion/ng-eventually.git/.project/concepts/app-contract/contract_polyfill-surface.md
+    # The contract is published from the branch that carries it while that branch is still
+    # in flight; it moves to `main` once the provider lands it there. Flip this line then,
+    # and re-pull — the stamp records which commit the local copy actually came from.
+    ref: caps-p1a-and-virtual-user-boundary

.project/to-discuss.md

@@ -0,0 +1,3 @@
+# To discuss
+
+- [ ] clarifier le vocabulaire d'identité employé par Festipod (wallet, utilisateur, profil, username) et réconcilier decision_2026-07-06 (« identifiant = wallet ») et decision_2026-07-20 (« username dans le profil ») avec ce que le contrat publie aujourd'hui : `ensureIdentity()` ne prend aucun identifiant, et `username` ne désigne plus que `UserProfile.username`

AGENTS.md

@@ -14,18 +14,27 @@ Web app mobile-first où les utilisateurs créent des **points de rencontre** qu
 - **Un module n'importe QUE depuis `shared/` — jamais d'un autre module.** C'est l'invariant qui rend l'archi réelle.
 - **Bun-first** : `bun` / `bun install` / `bun test` / `bun build`, jamais node/npm/vite/jest. `bun run dev` (port 3000).
 
+## Frontière SDK
+
+Le SDK de données de Festipod est **`@ng-eventually/polyfill`**, injecté une seule fois via `ngSession.configure(...)`.
+
+**L'engagement que le fournisseur publie est tiré dans ce repo et épinglé** : `data-layer`, fiche `contract_polyfill-surface`. **C'est la seule référence.** On n'ouvre jamais les sources du fournisseur ni sa copie dans `node_modules`, pas même pour vérifier une signature. Ce que le contrat ne dit pas, ce repo ne le sait pas : **un manque est remonté au fournisseur**, jamais contourné ici ni documenté ici. Vaut aussi pour les tests, qui valident **Festipod** et jamais le SDK (`bdd-testing`, `rule_tests-validate-festipod-not-the-sdk`).
+
+Le contrat se re-tire à chaque montée de version : `python3 ~/projects/skills/concept/contracts.py pull` (dérive : `… check`). Sa surface **rétrécit** — un symbole retiré est du code que l'app supprime, pas une régression à amortir.
+
+**Ne jamais décrire dans ce repo comment la couche de données est implémentée.** La doctrine Festipod décrit uniquement *le contrat* + *comment Festipod l'utilise* + le domaine + l'architecture + le contrat BDD.
+
 ## Doctrine du projet — concepts (livrée automatiquement)
 
 La connaissance détaillée vit dans `.project/concepts/` (système *concept*) : fiches courtes, typées, **livrées par un hook quand tu touches leur territoire** — tu n'as pas à les charger d'avance. Les 6 concepts :
 
 | Concept | Couvre |
 |---|---|
-| `functional-domain` | Modèle produit : point de rencontre, acteurs, concepts métier, défi déduplication |
+| `functional-domain` | Modèle produit : point de rencontre, acteurs, concepts métier, périmètres public/protected/private par entité, découverte, défi déduplication |
 | `app-architecture` | Modules, invariant d'imports, app shell, routing path-based, écrans |
 | `tech-stack` | Bun-first, APIs Bun, build pipeline, commandes |
-| `data-layer` | NextGraph actuel (mono-store), shapes, modes connected/demo, règles + pièges (suppression, champs perdus, internals) |
+| `data-layer` | Persistance via le SDK `@ng-eventually/polyfill` : entités-documents par scope, shapes SHEX/ORM, modes connected/demo, pièges |
 | `bdd-testing` | Cucumber multi-couches FR, contrat `@ui`/`@data`/`@e2e`, harness broker, cookbook |
-| `app-security` | Posture de sécurité actuelle (mono-store, confiance broker), auth wallet, modèle d'autorisations cible |
-| `nextgraph-platform` | NextGraph système externe (stores, inbox, SDK) + briefs prospectifs (multi-store, fork, shim) |
+| `app-security` | Isolation déléguée au SDK (pas de contrôle d'accès dans les écrans), auth wallet, matrice d'autorisations cible |
 
 Pour **documenter** un fait projet : `/concept document <sujet>` (ne pas écrire en libre dans `.project/`).

Dockerfile

@@ -1,11 +1,19 @@
-# Use the official Bun image
+# Use the official Bun image (runtime stays Bun; only install moves to pnpm)
 FROM oven/bun:1-alpine AS base
 WORKDIR /app
 
-# Install dependencies
+# Install dependencies with pnpm.
+# - git: the @ng-eventually/client polyfill is a git+https (public Gitea) dependency → no auth.
+# - nodejs + npm: pnpm is a Node CLI; we pin the exact pnpm version via `npm i -g`
+#   (Alpine's nodejs package does not bundle corepack).
+# The `bun` npm peer (pulled by bun-plugin-tailwind) is approved to build in package.json
+# (pnpm.onlyBuiltDependencies) so node_modules/.bin/bun is a real binary — required because
+# `bun run start` puts node_modules/.bin ahead of PATH.
 FROM base AS install
-COPY package.json bun.lock ./
-RUN bun install --frozen-lockfile
+RUN apk add --no-cache git nodejs npm \
+    && npm install -g pnpm@10.26.0
+COPY package.json pnpm-lock.yaml ./
+RUN pnpm install --frozen-lockfile
 
 # Copy source code and build assets
 FROM base AS release

build.ts

@@ -133,21 +133,24 @@ const result = await Bun.build({
   sourcemap: "linked",
   define: {
     "process.env.NODE_ENV": JSON.stringify("production"),
-    // Access gate (ON by default) + shared wallet password, baked into the
-    // browser bundle as globals (see src/app/AuthGate.tsx, sharedWallet.ts). The
+    // Shared wallet password, baked into the browser bundle as a global (see
+    // sharedWallet.ts) and handed to the SDK by the ONE `configure` call. The
     // wallet FILE is copied into the outdir below (served at /shared-wallet.ngw).
-    "globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__": JSON.stringify(
-      process.env.ACCESS_GATE_DISABLED === "1",
-    ),
     "globalThis.__FESTIPOD_SHARED_WALLET_PASSWORD__": JSON.stringify(
       process.env.FESTIPOD_SHARED_WALLET_PASSWORD ?? "",
     ),
+    // Auto-seed gate (OFF by default): only seed a genuinely-empty wallet with
+    // demo data when FESTIPOD_AUTO_SEED is set (see src/shared/utils/autoSeed.ts).
+    "globalThis.__FESTIPOD_AUTO_SEED__": JSON.stringify(
+      process.env.FESTIPOD_AUTO_SEED ?? "",
+    ),
   },
   ...cliConfig,
 });
 
-// Staging: copy the shared wallet FILE into the bundle so the access gate can
-// offer it for download (served at /shared-wallet.ngw). See sharedWallet.ts.
+// Staging: copy the shared wallet FILE into the bundle so it can be offered for
+// download (served at /shared-wallet.ngw — the `fileUrl` the app hands the SDK
+// through `configure`). See sharedWallet.ts.
 if (process.env.FESTIPOD_SHARED_WALLET_FILE) {
   const { copyFileSync } = await import("fs");
   copyFileSync(process.env.FESTIPOD_SHARED_WALLET_FILE, path.join(outdir, "shared-wallet.ngw"));

cucumber.json

@@ -6,13 +6,13 @@
       "src/modules/*/steps/**/*.ts"
     ],
     "paths": ["src/modules/*/features/**/*.feature"],
+    "tags": "not @wip and not @humain",
     "format": [
       "progress-bar",
       "json:reports/cucumber-report.json",
       "html:reports/cucumber-report.html"
     ],
     "language": "fr",
-    "tags": "not @wip",
     "formatOptions": {
       "snippetInterface": "async-await"
     },

package.json

@@ -8,18 +8,21 @@
     "start": "NODE_ENV=production bun src/index.ts",
     "build": "bun run build.ts",
     "test:cucumber": "bun run cucumber:run && bun run cucumber:report && bun run features:parse && bun run steps:extract",
-    "cucumber:run": "node --import tsx/esm node_modules/.bin/cucumber-js --config cucumber.json",
-    "test:data": "node --import tsx/esm node_modules/.bin/cucumber-js --config cucumber.json --tags @data",
+    "cucumber:run": "node --import tsx/esm node_modules/@cucumber/cucumber/bin/cucumber.js --config cucumber.json",
+    "test:data": "node --import tsx/esm node_modules/@cucumber/cucumber/bin/cucumber.js --config cucumber.json --tags @data",
     "test:auth-setup": "bun scripts/setup-test-auth.ts",
     "cucumber:report": "bun scripts/parse-test-results.ts",
     "features:parse": "bun scripts/parse-features.ts",
     "steps:extract": "bun scripts/extract-step-definitions.ts",
-    "build:orm": "rdf-orm build --input ./src/shapes/shex --output ./src/shapes/orm",
+    "build:orm": "rdf-orm build --input ./src/shared/shapes/shex --output ./src/shared/shapes/orm",
+    "validate": "bun scripts/validate.ts",
     "build:ng": "bash scripts/build-ng-packages.sh",
+    "link:polyfill": "bun scripts/link-polyfill.ts",
     "storybook": "storybook dev -p 6006",
     "build-storybook": "storybook build"
   },
   "dependencies": {
+    "@ng-eventually/polyfill": "git+https://gitea.reconnexion.apps.gueraud.net/Reconnexion/ng-eventually.git#main&path:/packages/polyfill",
     "@ng-org/alien-deepsignals": "0.1.2-alpha.11",
     "@ng-org/orm": "0.1.2-alpha.18",
     "@ng-org/shex-orm": "0.1.2-alpha.8",
@@ -56,5 +59,11 @@
     "@storybook/addon-a11y": "^10.3.5",
     "@storybook/addon-docs": "^10.3.5",
     "@storybook/addon-onboarding": "^10.3.5"
-  }
+  },
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "bun"
+    ]
+  },
+  "packageManager": "pnpm@10.26.0+sha512.3b3f6c725ebe712506c0ab1ad4133cf86b1f4b687effce62a9b38b4d72e3954242e643190fc51fa1642949c735f403debd44f5cb0edd657abe63a8b6a7e1e402"
 }

scripts/link-polyfill.ts

@@ -0,0 +1,106 @@
+#!/usr/bin/env bun
+/**
+ * link-polyfill.ts — Reactive local link for the @ng-eventually/polyfill polyfill.
+ *
+ * WHY a copy-overlay and not a symlink:
+ *   The committed prod dependency installs @ng-eventually/polyfill from Gitea (git+https)
+ *   into pnpm's store WITHOUT its own node_modules/@ng-org → @ng-org/web resolves up to
+ *   Festipod → ONE @ng-org instance (one verifier). The local polyfill CHECKOUT, however,
+ *   carries its own node_modules/@ng-org/* (symlinks into the ng-eventually-js monorepo
+ *   store). Symlinking node_modules/@ng-eventually/polyfill to that checkout puts the
+ *   checkout's @ng-org in the resolution path → a SECOND @ng-org instance → broken SDK
+ *   (two verifiers). So we overlay a real directory that contains ONLY the polyfill's
+ *   source (no node_modules) and keep it in sync by copying — @ng-org still resolves to
+ *   Festipod, single instance preserved.
+ *
+ * WHAT IT DOES:
+ *   1. Replaces node_modules/@ng-eventually/polyfill (the pnpm store symlink) with a real
+ *      directory holding the local polyfill's package.json + src (NO node_modules).
+ *   2. Asserts the single-instance invariant (same @ng-org/web realpath from Festipod and
+ *      from the overlay) — aborts if it would break.
+ *   3. Watches the local polyfill src and copies each change into the overlay, so
+ *      `bun --hot` (bun run dev) reloads the edited file live.
+ *
+ * USAGE (reactive dev):
+ *   Terminal 1:  pnpm run link:polyfill      # overlays local source, then watches
+ *   Terminal 2:  bun run dev                 # portless festipod bun --hot src/index.ts
+ *   Edit files under packages/polyfill/src → they land in node_modules → bun --hot reloads.
+ *
+ *   pnpm run link:polyfill --once            # overlay + verify, no watch (CI / one-shot)
+ *   Return to the committed git-installed dependency:  pnpm install
+ *
+ * Override the local checkout path with NG_EVENTUALLY_LOCAL=/path/to/packages/polyfill.
+ */
+import { existsSync, lstatSync, mkdirSync, rmSync, cpSync, copyFileSync, realpathSync } from "node:fs";
+import { watch } from "node:fs";
+import { join, dirname } from "node:path";
+
+const FESTIPOD = realpathSync(join(import.meta.dir, ".."));
+const LOCAL =
+  process.env.NG_EVENTUALLY_LOCAL ??
+  "/home/sylvain/projects/nextgraph/ng-eventually-js/packages/polyfill";
+const TARGET = join(FESTIPOD, "node_modules", "@ng-eventually", "polyfill");
+const SRC_LOCAL = join(LOCAL, "src");
+const SRC_TARGET = join(TARGET, "src");
+const ONCE = process.argv.includes("--once");
+
+function fail(msg: string): never {
+  console.error(`✖ link:polyfill — ${msg}`);
+  process.exit(1);
+}
+
+if (!existsSync(join(LOCAL, "package.json"))) {
+  fail(`local polyfill not found at ${LOCAL} (set NG_EVENTUALLY_LOCAL to override)`);
+}
+
+// 1. Replace the pnpm store symlink with a real overlay dir (metadata + src, NO node_modules).
+console.log(`→ overlaying local polyfill: ${LOCAL}`);
+if (existsSync(TARGET) || lstatSync(TARGET, { throwIfNoEntry: false })) {
+  rmSync(TARGET, { recursive: true, force: true });
+}
+mkdirSync(TARGET, { recursive: true });
+for (const meta of ["package.json", "tsconfig.json", "README.md"]) {
+  const from = join(LOCAL, meta);
+  if (existsSync(from)) copyFileSync(from, join(TARGET, meta));
+}
+// Copy src fresh (NEVER a node_modules dir — that is what guarantees single @ng-org instance).
+cpSync(SRC_LOCAL, SRC_TARGET, { recursive: true });
+
+// 2. Assert the single-instance invariant.
+const fromFestipod = realpathSync(Bun.resolveSync("@ng-org/web", FESTIPOD));
+const overlayReal = realpathSync(TARGET);
+const fromPolyfill = realpathSync(Bun.resolveSync("@ng-org/web", overlayReal));
+console.log(`  @ng-org/web (Festipod): ${fromFestipod}`);
+console.log(`  @ng-org/web (overlay) : ${fromPolyfill}`);
+if (fromFestipod !== fromPolyfill) {
+  fail(
+    "single-instance invariant BROKEN — @ng-org/web resolves to two different realpaths.\n" +
+      "  The overlay must not contain its own node_modules/@ng-org. Aborting.",
+  );
+}
+console.log("✓ single @ng-org/web instance preserved");
+
+if (ONCE) {
+  console.log("✓ overlay ready (--once, not watching)");
+  process.exit(0);
+}
+
+// 3. Watch and copy on change so `bun --hot` sees live edits.
+console.log(`👀 watching ${SRC_LOCAL} → ${SRC_TARGET} (Ctrl-C to stop)`);
+watch(SRC_LOCAL, { recursive: true }, (_event, filename) => {
+  if (!filename) return;
+  const from = join(SRC_LOCAL, filename);
+  const to = join(SRC_TARGET, filename);
+  try {
+    if (existsSync(from)) {
+      mkdirSync(dirname(to), { recursive: true });
+      copyFileSync(from, to);
+      console.log(`  ↻ ${filename}`);
+    } else if (existsSync(to)) {
+      rmSync(to, { force: true });
+      console.log(`  ✗ ${filename} (removed)`);
+    }
+  } catch (err) {
+    console.error(`  ! failed to sync ${filename}:`, err);
+  }
+});

scripts/validate.ts

@@ -0,0 +1,490 @@
+#!/usr/bin/env bun
+/**
+ * validate.ts — Validation matrix (broker-level tests only, no @ui/@e2e).
+ *
+ * Default run (no flags) — key subset only, fast:
+ *   (a) Polyfill unit tests        (@ng-eventually/client — bun test)
+ *   (b) Polyfill e2e real-broker   (@ng-eventually/client — bun run e2e/run.ts)
+ *   (c) Festipod @data KEY SUBSET  (cucumber --name regex covering terrain bugs)
+ *   (d) Festipod @multibrowser     (cucumber --tags @multibrowser)
+ *   (e) Festipod @smoke            (cucumber --tags @smoke — boot connecté rend)
+ *   (f) Festipod @wip [informational only, non-blocking]
+ *
+ * With --full flag:
+ *   (c) becomes full @data suite   (cucumber --tags @data)
+ *
+ * Each step runs even if the previous one failed (--bail mode is OFF).
+ * Exit code is non-zero if any non-informational step has failures.
+ *
+ * Profile rotation: both Playwright profiles are rotated before @data and
+ * @multibrowser when their size exceeds BLOAT_THRESHOLD_MB (default 50 MB),
+ * to avoid the sparql_query hang described in caveat_wallet-bloat-hang.
+ */
+
+import { spawnSync } from "child_process";
+import * as fs from "fs";
+import * as path from "path";
+
+// ─── Config ────────────────────────────────────────────────────────────────
+
+const FESTIPOD_DIR = "/home/sylvain/projects/festipod/festipod";
+const POLYFILL_DIR =
+  "/home/sylvain/projects/nextgraph/ng-eventually-js/packages/client";
+
+const FESTIPOD_PROFILE = path.join(FESTIPOD_DIR, ".playwright-profile");
+const POLYFILL_PROFILE = path.join(
+  POLYFILL_DIR,
+  "e2e",
+  ".playwright-profile-lib",
+);
+
+/** Rotate profile when it exceeds this many MB (caveat_wallet-bloat-hang). */
+const BLOAT_THRESHOLD_MB = 50;
+
+/**
+ * Per-step timeouts:
+ * - polyfill unit/e2e: short steps, keep 10 min
+ * - @data key subset: generous — BeforeAll + 8 scenarios, ~15 min margin
+ * - @data full: full suite, ~35 min margin
+ * - @multibrowser: 7 scenarios, ~10 min margin
+ * - @wip: informational, 10 min
+ */
+const TIMEOUT_POLYFILL_UNIT_MS = 10 * 60 * 1000;  // 10 min
+const TIMEOUT_POLYFILL_E2E_MS  = 10 * 60 * 1000;  // 10 min
+const TIMEOUT_DATA_KEY_MS      = 15 * 60 * 1000;  // 15 min (key subset)
+const TIMEOUT_DATA_FULL_MS     = 35 * 60 * 1000;  // 35 min (--full)
+const TIMEOUT_MULTIBROWSER_MS  = 10 * 60 * 1000;  // 10 min
+const TIMEOUT_SMOKE_MS         = 10 * 60 * 1000;  // 10 min (1 @e2e boot scenario)
+const TIMEOUT_WIP_MS           = 10 * 60 * 1000;  // 10 min
+
+/**
+ * Key-subset --name regex: matches exactly the 8 scenarios that cover the
+ * known terrain bugs (inscription, désinscription, isolation, reconnexion,
+ * compteur dérivé, créateur ne participe pas, auth vide, auth distinctes).
+ *
+ * Uses a single cucumber invocation so BeforeAll (broker login) runs once.
+ *
+ * French accent chars must be URL-safe in the regex — cucumber uses JS
+ * RegExp, which handles unicode natively; we pass the literal string.
+ */
+const DATA_KEY_NAME_REGEX = [
+  "S'inscrire à un événement",
+  "Se désinscrire d'un événement$",
+  "Une identité fraîche ne voit pas la participation d'une autre",
+  "Une page fraîche pour la même identité relit ses propres données",
+  "Le créateur ne participe pas automatiquement à son événement",
+  "L'inscription fait converger le compteur dérivé du propriétaire",
+  "Un portefeuille connecté est vide par défaut",
+  "Les données du portefeuille sont distinctes des données par défaut",
+].join("|");
+
+// ─── Helpers ───────────────────────────────────────────────────────────────
+
+function dirSizeMB(dir: string): number {
+  if (!fs.existsSync(dir)) return 0;
+  try {
+    const result = spawnSync("du", ["-sm", dir], { encoding: "utf-8" });
+    const line = result.stdout.trim().split("\n")[0] ?? "";
+    return parseInt(line.split("\t")[0] ?? "0", 10);
+  } catch {
+    return 0;
+  }
+}
+
+/**
+ * Remove any stale Chromium singleton files from `profilePath`. Chromium refuses
+ * to launch (ProcessSingleton error) if SingletonLock, SingletonCookie, or
+ * SingletonSocket are left over from a previous crashed run. Idempotent — safe to
+ * call even when the profile does not exist yet.
+ */
+function cleanSingletons(profilePath: string, label: string): void {
+  if (!fs.existsSync(profilePath)) return;
+  const singletons = ["SingletonLock", "SingletonCookie", "SingletonSocket"];
+  for (const name of singletons) {
+    const p = path.join(profilePath, name);
+    if (fs.existsSync(p)) {
+      try {
+        fs.rmSync(p, { force: true });
+        console.log(`[rotate] ${label}: removed stale ${name}.`);
+      } catch {
+        // Non-fatal: if we can't remove it, launch will fail with a clear error
+      }
+    }
+  }
+}
+
+function rotateProfile(profilePath: string, label: string): void {
+  const sizeMB = dirSizeMB(profilePath);
+  if (sizeMB > BLOAT_THRESHOLD_MB) {
+    console.log(
+      `[rotate] ${label}: ${sizeMB}MB > ${BLOAT_THRESHOLD_MB}MB — rotating profile...`,
+    );
+    try {
+      fs.rmSync(profilePath, { recursive: true, force: true });
+      console.log(`[rotate] ${label}: profile removed. Will be recreated.`);
+    } catch (e) {
+      console.warn(`[rotate] ${label}: failed to remove profile: ${e}`);
+    }
+  } else {
+    // Even if we keep the profile, remove any stale Chromium singleton files left
+    // by a previous crashed run — Chromium refuses to launch if they exist.
+    cleanSingletons(profilePath, label);
+    console.log(
+      `[rotate] ${label}: ${sizeMB}MB — below threshold, keeping profile.`,
+    );
+  }
+}
+
+interface StepResult {
+  label: string;
+  status: "passed" | "failed" | "error";
+  /** Lines to show in the summary (failed scenario names, FAIL lines, etc.) */
+  failures: string[];
+  /** Raw exit code */
+  exitCode: number;
+  durationMs: number;
+}
+
+/**
+ * Run a command and capture its output. Returns the result with parsed
+ * pass/fail summary. Never throws — all errors are captured in StepResult.
+ */
+function runStep(
+  label: string,
+  cmd: string,
+  args: string[],
+  cwd: string,
+  timeoutMs: number,
+  extraEnv: Record<string, string> = {},
+): StepResult {
+  const t0 = Date.now();
+  console.log(`\n${"═".repeat(60)}`);
+  console.log(`▶  ${label}`);
+  console.log(`   ${cmd} ${args.join(" ")}  (cwd: ${cwd})`);
+  console.log(`   timeout: ${Math.round(timeoutMs / 60000)}min`);
+  console.log(`${"═".repeat(60)}`);
+
+  const env = { ...process.env, ...extraEnv };
+
+  const result = spawnSync(cmd, args, {
+    cwd,
+    env,
+    encoding: "utf-8",
+    timeout: timeoutMs,
+    maxBuffer: 20 * 1024 * 1024, // 20MB
+  });
+
+  const durationMs = Date.now() - t0;
+  const stdout = result.stdout ?? "";
+  const stderr = result.stderr ?? "";
+  const combined = stdout + "\n" + stderr;
+
+  // Print output in real-time equivalent (post-hoc since spawnSync)
+  if (stdout) process.stdout.write(stdout);
+  if (stderr) process.stderr.write(stderr);
+
+  if (result.error) {
+    console.error(`[${label}] process error:`, result.error.message);
+    return {
+      label,
+      status: "error",
+      failures: [`Process error: ${result.error.message}`],
+      exitCode: result.status ?? 1,
+      durationMs,
+    };
+  }
+
+  const exitCode = result.status ?? 1;
+  const failures = extractFailures(combined, label);
+  const status = exitCode === 0 ? "passed" : "failed";
+
+  return { label, status, failures, exitCode, durationMs };
+}
+
+/**
+ * Extract meaningful failure lines from combined stdout+stderr.
+ * Heuristics per step type (cucumber scenario names, FAIL lines, etc.).
+ */
+function extractFailures(output: string, label: string): string[] {
+  const lines = output.split("\n");
+  const failures: string[] = [];
+
+  if (label.includes("polyfill:unit")) {
+    // bun test output: lines starting with "✗" or "FAIL" or "fail"
+    for (const line of lines) {
+      const l = line.trim();
+      if (/^(✗|✕|FAIL|fail)\s/.test(l) || l.includes("tests failed")) {
+        failures.push(l);
+      }
+    }
+    // Also capture summary line "N passed, M failed"
+    const summary = lines.find(
+      (l) => l.includes("passed") && l.includes("failed"),
+    );
+    if (summary) failures.push(summary.trim());
+  } else if (label.includes("polyfill:e2e")) {
+    // e2e/run.ts output: lines starting with "  [FAIL]"
+    for (const line of lines) {
+      const l = line.trim();
+      if (l.startsWith("[FAIL]")) failures.push(l);
+    }
+    // Summary: "N passed / M failed" style
+    const summary = lines.find(
+      (l) => l.includes("passed") || l.includes("failed"),
+    );
+    if (summary && !failures.includes(summary.trim()))
+      failures.push(summary.trim());
+  } else {
+    // Cucumber steps: look for "✗" scenario lines, "FAILED" scenario names,
+    // or lines beginning with "✖" / "×" / "Scenario:" after a failure tag
+    for (const line of lines) {
+      const l = line.trim();
+      if (
+        /^(✗|✕|×|✖)\s/.test(l) ||
+        l.startsWith("✘") ||
+        l.includes("# Scénario:") ||
+        l.includes("# Scenario:") ||
+        (l.startsWith("F") && l.length === 1) // progress-bar failure tick
+      ) {
+        if (l.length > 1) failures.push(l);
+      }
+    }
+    // Cucumber "N scenarios (M failed)" summary
+    const summary = lines.find((l) =>
+      /\d+ sc[eé]narios?.*(failed|undefined)/.test(l),
+    );
+    if (summary) failures.push(summary.trim());
+    // Individual scenario fail lines: "✗ Scenario name (features/...)"
+    for (const line of lines) {
+      const l = line.trim();
+      if (l.startsWith("✗") || l.startsWith("✕")) {
+        if (!failures.includes(l)) failures.push(l);
+      }
+    }
+  }
+
+  return failures.filter(Boolean);
+}
+
+function fmtDuration(ms: number): string {
+  if (ms < 60_000) return `${(ms / 1000).toFixed(1)}s`;
+  const m = Math.floor(ms / 60_000);
+  const s = ((ms % 60_000) / 1000).toFixed(0);
+  return `${m}m${s}s`;
+}
+
+function printMatrix(
+  steps: StepResult[],
+  wipResult: StepResult | null,
+  fullMode: boolean,
+): void {
+  console.log("\n");
+  console.log("╔══════════════════════════════════════════════════════════╗");
+  console.log("║                  VALIDATION MATRIX                      ║");
+  if (fullMode) {
+    console.log("║              (mode: --full, @data complet)               ║");
+  } else {
+    console.log("║           (mode: défaut, sous-ensemble clé)              ║");
+  }
+  console.log("╚══════════════════════════════════════════════════════════╝");
+  console.log("");
+
+  const maxLabel = Math.max(...steps.map((s) => s.label.length));
+
+  for (const step of steps) {
+    const icon = step.status === "passed" ? "✅" : step.status === "failed" ? "❌" : "⚠️ ";
+    const pad = step.label.padEnd(maxLabel + 2);
+    console.log(`  ${icon}  ${pad}  [${fmtDuration(step.durationMs)}]`);
+    for (const f of step.failures) {
+      console.log(`       ↳ ${f}`);
+    }
+  }
+
+  if (wipResult) {
+    console.log("");
+    console.log("  ── @wip (informational, non-blocking) ──────────────────");
+    const icon =
+      wipResult.status === "passed"
+        ? "✅"
+        : wipResult.status === "failed"
+          ? "❌"
+          : "⚠️ ";
+    const pad = wipResult.label.padEnd(maxLabel + 2);
+    console.log(`  ${icon}  ${pad}  [${fmtDuration(wipResult.durationMs)}]`);
+    for (const f of wipResult.failures) {
+      console.log(`       ↳ ${f}`);
+    }
+  }
+
+  console.log("");
+  const allPassed = steps.every((s) => s.status === "passed");
+  const totalMs = steps.reduce((sum, s) => sum + s.durationMs, 0) +
+    (wipResult?.durationMs ?? 0);
+  if (allPassed) {
+    console.log("  🟢  ALL STEPS PASSED");
+  } else {
+    const failed = steps.filter((s) => s.status !== "passed");
+    console.log(`  🔴  ${failed.length} STEP(S) FAILED: ${failed.map((s) => s.label).join(", ")}`);
+  }
+  console.log(`  ⏱   Total: ${fmtDuration(totalMs)}`);
+  if (!fullMode) {
+    console.log("  ℹ️   Pour @data complet : bun run validate -- --full");
+  }
+  console.log("");
+}
+
+// ─── Cucumber command builder ───────────────────────────────────────────────
+
+function cucumberArgsByTags(tags: string): string[] {
+  return [
+    "--import",
+    "tsx/esm",
+    "node_modules/.bin/cucumber-js",
+    "--config",
+    "cucumber.json",
+    "--tags",
+    tags,
+  ];
+}
+
+function cucumberArgsByName(nameRegex: string): string[] {
+  return [
+    "--import",
+    "tsx/esm",
+    "node_modules/.bin/cucumber-js",
+    "--config",
+    "cucumber.json",
+    "--tags",
+    "@data",
+    "--name",
+    nameRegex,
+  ];
+}
+
+// ─── Main ──────────────────────────────────────────────────────────────────
+
+async function main(): Promise<void> {
+  const args = process.argv.slice(2);
+  const fullMode = args.includes("--full");
+
+  if (fullMode) {
+    console.log("🔍  Festipod — Full Validation Run (--full : @data complet)");
+  } else {
+    console.log("🔍  Festipod — Validation Run (sous-ensemble clé)");
+    console.log("    Pour @data complet : bun run validate -- --full");
+  }
+  console.log(`    Festipod: ${FESTIPOD_DIR}`);
+  console.log(`    Polyfill: ${POLYFILL_DIR}`);
+  console.log("");
+
+  // ── Profile rotation AVANT les étapes broker ──────────────────────────────
+  console.log("── Profile rotation check (avant @data et @multibrowser) ────");
+  rotateProfile(FESTIPOD_PROFILE, "festipod");
+  rotateProfile(POLYFILL_PROFILE, "polyfill-lib");
+
+  const steps: StepResult[] = [];
+
+  // ── (a) Polyfill unit tests ───────────────────────────────────────────────
+  steps.push(
+    runStep(
+      "polyfill:unit",
+      "bun",
+      ["test"],
+      POLYFILL_DIR,
+      TIMEOUT_POLYFILL_UNIT_MS,
+    ),
+  );
+
+  // ── (b) Polyfill e2e real broker ──────────────────────────────────────────
+  // Clean singleton files immediately before launching Chromium — guards against
+  // any file left by polyfill:unit (unlikely but defensive) or by a previous
+  // interrupted run that the initial rotateProfile call ran before.
+  cleanSingletons(POLYFILL_PROFILE, "polyfill-lib (pre-e2e)");
+  steps.push(
+    runStep(
+      "polyfill:e2e",
+      "bun",
+      ["run", "e2e/run.ts"],
+      POLYFILL_DIR,
+      TIMEOUT_POLYFILL_E2E_MS,
+    ),
+  );
+
+  // ── (c) Festipod @data ────────────────────────────────────────────────────
+  if (fullMode) {
+    // --full : lance tout @data
+    steps.push(
+      runStep(
+        "festipod:@data (complet)",
+        "node",
+        cucumberArgsByTags("@data"),
+        FESTIPOD_DIR,
+        TIMEOUT_DATA_FULL_MS,
+      ),
+    );
+  } else {
+    // défaut : sous-ensemble clé en UNE invocation (BeforeAll partagé)
+    steps.push(
+      runStep(
+        "festipod:@data (clé)",
+        "node",
+        cucumberArgsByName(DATA_KEY_NAME_REGEX),
+        FESTIPOD_DIR,
+        TIMEOUT_DATA_KEY_MS,
+      ),
+    );
+  }
+
+  // ── (d) Festipod @multibrowser ────────────────────────────────────────────
+  // Exclude @wip: a scenario tagged @wip @multibrowser (e.g. the reactive
+  // cross-session scenario, blocked by the shared-wallet structural limit) must
+  // not gate the baseline — it flows into the informational @wip pass below.
+  steps.push(
+    runStep(
+      "festipod:@multibrowser",
+      "node",
+      cucumberArgsByTags("@multibrowser and not @wip"),
+      FESTIPOD_DIR,
+      TIMEOUT_MULTIBROWSER_MS,
+    ),
+  );
+
+  // ── (e) Festipod @smoke — boot connecté rend / page blanche ───────────────
+  // Un seul scénario @e2e : boote le VRAI App, se connecte au broker, et vérifie
+  // que l'accueil connecté rend du contenu d'app réel SANS erreur runtime. Garde
+  // la CLASSE « crash de rendu une fois connecté » (page blanche). On ne lance
+  // QUE @smoke (pas tout @e2e) pour garder le run par défaut rapide.
+  // Nettoie les singletons Chromium juste avant, comme les autres étapes broker.
+  cleanSingletons(FESTIPOD_PROFILE, "festipod (pre-@smoke)");
+  steps.push(
+    runStep(
+      "festipod:@smoke",
+      "node",
+      cucumberArgsByTags("@smoke and not @wip"),
+      FESTIPOD_DIR,
+      TIMEOUT_SMOKE_MS,
+    ),
+  );
+
+  // ── (f) Festipod @wip [informational] ────────────────────────────────────
+  console.log("\n── @wip informational pass (non-blocking) ──────────────────");
+  const wipResult = runStep(
+    "festipod:@wip",
+    "node",
+    cucumberArgsByTags("@wip"),
+    FESTIPOD_DIR,
+    TIMEOUT_WIP_MS,
+  );
+
+  // ── Matrix ────────────────────────────────────────────────────────────────
+  printMatrix(steps, wipResult, fullMode);
+
+  // ── Exit code ─────────────────────────────────────────────────────────────
+  const anyFailed = steps.some((s) => s.status !== "passed");
+  process.exit(anyFailed ? 1 : 0);
+}
+
+main().catch((e) => {
+  console.error("validate.ts: unhandled error:", e);
+  process.exit(1);
+});

src/app/App.tsx

@@ -1,7 +1,6 @@
 import { RouterProvider, useRouter } from './router';
 import { ThemeProvider } from '../shared/context/ThemeContext';
 import { NextGraphProvider } from '../shared/context/NextGraphContext';
-import { AccountProvider } from '../shared/context/AccountContext';
 import { FestipodDataProvider } from '../shared/context/FestipodDataContext';
 import { AuthGate } from './AuthGate';
 import { ToastContainer } from '../shared/components/sketchy';
@@ -57,18 +56,16 @@ export function App() {
   return (
     <ThemeProvider>
       <NextGraphProvider>
-        <AccountProvider>
-          <FestipodDataProvider>
-            <RouterProvider>
-              <div className="app-container">
-                <AuthGate>
-                  <AppContent />
-                </AuthGate>
-                <ToastContainer />
-              </div>
-            </RouterProvider>
-          </FestipodDataProvider>
-        </AccountProvider>
+        <FestipodDataProvider>
+          <RouterProvider>
+            <div className="app-container">
+              <AuthGate>
+                <AppContent />
+              </AuthGate>
+              <ToastContainer />
+            </div>
+          </RouterProvider>
+        </FestipodDataProvider>
       </NextGraphProvider>
     </ThemeProvider>
   );

src/app/AuthGate.tsx

@@ -1,48 +1,103 @@
 /**
- * AuthGate — the stopgap access flow (see decision_2026-06-15_shared-wallet-login-flow):
- *   1. Technical access barrier (AccessGateScreen) → opens the SHARED wallet via
- *      the broker redirect (with the wallet file + guide it hands the user).
- *   2. Perceived app login (ConnexionScreen) → pick a username.
- *   3. The app.
+ * AuthGate — the ONE await the application makes before it renders.
  *
- * The gate is ON BY DEFAULT (Festipod never functions without NextGraph). It is
- * disabled only when `globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ === true` —
- * injected by `build.ts` (from ACCESS_GATE_DISABLED=1) for a no-gate build, or
- * by the test harness via `context.addInitScript` for @e2e (which exercises the
- * screens, not the auth flow). Absent → gate ON.
+ * Signing in is `ensureIdentity()` and nothing else: it takes no identifier,
+ * resolves who we are and does the connection work (restoring what others shared
+ * with us, draining our inboxes). Whatever a user has to see or do while that
+ * resolves — opening the wallet, loading it onto a first-time device — belongs to
+ * the SDK: it mounts a full-screen barrier of its own on every top-level load and
+ * takes it down itself, and it owns the return from the broker round-trip (the
+ * barrier comes back prefilled, and confirming it hands the page over a second
+ * time; our page is never reloaded and nothing outside the barrier is touched).
+ * Festipod renders no access screen of its own and re-drives nothing.
+ *
+ * TWO CALLS, IN ORDER, AND THE ORDER IS CONTRACTUAL: start the session (`init`),
+ * then await `ensureIdentity()`. A session arrives only through `init`, and
+ * `ensureIdentity()` awaited before it has been called THROWS. The order is a fact
+ * of the statement sequence below, not of React's effect ordering — which would
+ * get it wrong: this gate's effect runs BEFORE its parent provider's.
+ *
+ * It hands back WHO WE ARE, and this is the app's only upstream answer to that
+ * question — everything else it knows about the user it has to read first. The
+ * value is published for display (`shared/utils/currentPrincipal`) and goes
+ * nowhere near a data call: no call takes an identity, because the session
+ * already belongs to one user.
+ *
+ * Nothing of the app renders before that await settles: a screen mounted earlier
+ * would read as an identity that is not yet settled.
+ *
+ * AND NOTHING RENDERS IF IT FAILS. A rejected `ensureIdentity()` is not a mode the
+ * app degrades through: an app that could not sign in but still shows its screens
+ * is indistinguishable from an app whose user simply owns nothing — a total
+ * failure wearing the face of an empty account. So the rejection is SHOWN, and the
+ * children stay unmounted, which is also what keeps the data layer from settling
+ * on its empty stand-in provider for the rest of the session.
  */
 
-import type { ReactNode } from 'react';
-import { useNextGraph } from '../shared/context/NextGraphContext';
-import { useAccount } from '../shared/context/AccountContext';
-import { AccessGateScreen } from '../modules/auth/screens/AccessGateScreen';
-import { ConnexionScreen } from '../modules/auth/screens/ConnexionScreen';
-
-declare global {
-  // eslint-disable-next-line no-var
-  var __FESTIPOD_ACCESS_GATE_DISABLED__: boolean | undefined;
-}
-const GATE_DISABLED = globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ === true;
+import { useEffect, useState, type ReactNode } from 'react';
+import { ensureIdentity } from '@ng-eventually/polyfill';
+import { startNgSession } from '../shared/utils/ngSession';
+import { setCurrentPrincipal } from '../shared/utils/currentPrincipal';
+import { useRouter, useNavigate } from './router';
 
 export function AuthGate({ children }: { children: ReactNode }) {
-  const { status, error, connect } = useNextGraph();
-  const { username } = useAccount();
+  const { route } = useRouter();
+  const navigate = useNavigate();
+  // Whether the ONE identity await has resolved.
+  const [identityReady, setIdentityReady] = useState(false);
+  // Why it did NOT resolve. Set once, never cleared: signing in is attempted once.
+  const [signInError, setSignInError] = useState<string | null>(null);
 
-  // Gate explicitly disabled (no-gate build / @e2e harness) → straight to app.
-  if (GATE_DISABLED) {
-    return <>{children}</>;
+  useEffect(() => {
+    let cancelled = false;
+    // FIRST — a session arrives only through the SDK's `init`. Idempotent, so the
+    // provider above may have started it already; what matters is that it has been
+    // called before the await below, or the await throws.
+    void startNgSession();
+    void ensureIdentity()
+      .then(principal => {
+        // Publish who we are BEFORE anything renders — the identity is a fact of
+        // the session, not state of this component, so it is recorded even if the
+        // effect was torn down in between.
+        setCurrentPrincipal(principal);
+        if (!cancelled) setIdentityReady(true);
+      })
+      .catch(err => {
+        console.error('[Auth] ensureIdentity failed:', err);
+        if (!cancelled) setSignInError(err instanceof Error ? err.message : String(err));
+      });
+    return () => { cancelled = true; };
+  }, []);
+
+  // Once identified, leave the disconnected welcome screen for the app home.
+  useEffect(() => {
+    if (identityReady && route.page === 'welcome') {
+      navigate('/home');
+    }
+  }, [identityReady, route.page, navigate]);
+
+  // Signing in FAILED — say so. The app has nothing legitimate to show, and
+  // showing it anyway would pass a broken session off as an empty one.
+  if (signInError) {
+    return (
+      <div id="auth-error" role="alert" className="app-card" style={{ margin: '2rem 1rem' }}>
+        <h1 className="app-title">Connexion impossible</h1>
+        <p className="app-text">
+          Festipod n’a pas réussi à vous connecter. Rien ne peut s’afficher tant que
+          la connexion n’a pas abouti — les écrans seraient vides sans le dire.
+        </p>
+        <p className="app-text" data-testid="auth-error-detail">{signInError}</p>
+      </div>
+    );
   }
 
-  // 1. Technical access barrier (real NG login) — until the shared wallet opens.
-  if (status !== 'connected') {
-    return <AccessGateScreen status={status} error={error} onEnter={connect} />;
+  // Signing in is not settled yet. Render NOTHING — the SDK's own full-screen
+  // barrier is what is on screen, it put it there and it takes it down. Anything
+  // of ours here would be a second thing competing with it.
+  if (!identityReady) {
+    return null;
   }
 
-  // 2. Perceived app login — until a username is chosen.
-  if (!username) {
-    return <ConnexionScreen />;
-  }
-
-  // 3. The app.
+  // The app.
   return <>{children}</>;
 }

src/app/frontend.tsx

@@ -3,24 +3,59 @@
  * element and renders the App component to the DOM.
  *
  * It is included in `src/index.html`.
+ *
+ * Before loading the app tree it pulls the RUNTIME shared-wallet config (dev
+ * server + `bun run start`, which serve from src/ and so miss build.ts's
+ * compile-time `define`), sets the global, then dynamically imports `App` so
+ * `sharedWallet.ts` reads the value on evaluation. In a build.ts bundle the
+ * password is already inlined via `define`, so this step is skipped (NODE_ENV).
  */
 
 import { StrictMode } from "react";
 import { createRoot } from "react-dom/client";
-import { App } from "./App";
 
-const elem = document.getElementById("root")!;
-const app = (
-  <StrictMode>
-    <App />
-  </StrictMode>
-);
-
-if (import.meta.hot) {
-  // With hot module reloading, `import.meta.hot.data` is persisted.
-  const root = (import.meta.hot.data.root ??= createRoot(elem));
-  root.render(app);
-} else {
-  // The hot module reloading API is not available in production.
-  createRoot(elem).render(app);
+/** Fetch the runtime shared-wallet config and set the global (dev/start only). */
+async function loadRuntimeConfig(): Promise<void> {
+  if (process.env.NODE_ENV === "production") return; // build.ts define provides it
+  try {
+    const res = await fetch("/festipod-config.json");
+    if (!res.ok) return;
+    const cfg = (await res.json()) as { sharedWalletPassword?: string; autoSeed?: string };
+    // Bracket access so build.ts's `define` (which matches the dotted global)
+    // never rewrites this assignment. Only set when the env actually carries one.
+    const g = globalThis as Record<string, unknown>;
+    if (cfg.sharedWalletPassword && g["__FESTIPOD_SHARED_WALLET_PASSWORD__"] == null) {
+      g["__FESTIPOD_SHARED_WALLET_PASSWORD__"] = cfg.sharedWalletPassword;
+    }
+    // Auto-seed gate (see src/shared/utils/autoSeed.ts): only set the global when
+    // the env var carries a truthy value; absent → stays undefined → seed OFF.
+    if (cfg.autoSeed && g["__FESTIPOD_AUTO_SEED__"] == null) {
+      g["__FESTIPOD_AUTO_SEED__"] = cfg.autoSeed;
+    }
+  } catch {
+    // No runtime config endpoint (static build) → rely on the compile-time define.
+  }
 }
+
+async function main(): Promise<void> {
+  await loadRuntimeConfig();
+  // Dynamic import AFTER the global is set, so sharedWallet.ts reads it on eval.
+  const { App } = await import("./App");
+  const elem = document.getElementById("root")!;
+  const app = (
+    <StrictMode>
+      <App />
+    </StrictMode>
+  );
+
+  if (import.meta.hot) {
+    // With hot module reloading, `import.meta.hot.data` is persisted.
+    const root = (import.meta.hot.data.root ??= createRoot(elem));
+    root.render(app);
+  } else {
+    // The hot module reloading API is not available in production.
+    createRoot(elem).render(app);
+  }
+}
+
+void main();

src/index.css

@@ -333,6 +333,17 @@ body {
   min-height: 0;
 }
 
+/* Global data-query spinner (near the "Festipod" title) */
+@keyframes app-spin {
+  to { transform: rotate(360deg); }
+}
+
+.app-spinner {
+  animation: app-spin 0.8s linear infinite;
+  flex-shrink: 0;
+  vertical-align: middle;
+}
+
 /* Online indicator on avatar */
 .app-avatar .online-dot {
   position: absolute;

src/index.ts

@@ -41,6 +41,28 @@ const server = serve({
       });
     },
 
+    // Shared-wallet config, exposed at RUNTIME for the dev server + `bun run start`
+    // (both serve from src/, so they miss build.ts's compile-time `define`). The app
+    // entry (frontend.tsx) fetches this before it loads the app tree, so
+    // `sharedWallet.ts` sees the password. Empty env → '' → no shared wallet.
+    "/festipod-config.json": () =>
+      Response.json({
+        sharedWalletPassword: process.env.FESTIPOD_SHARED_WALLET_PASSWORD ?? "",
+        // Auto-seed gate (OFF by default): only set when the env var is present, so
+        // the front seeds an empty wallet only on explicit opt-in (see autoSeed.ts).
+        autoSeed: process.env.FESTIPOD_AUTO_SEED ?? "",
+      }),
+
+    // The shared wallet file — the `fileUrl` the app hands the SDK, when configured.
+    "/shared-wallet.ngw": async () => {
+      const p = process.env.FESTIPOD_SHARED_WALLET_FILE;
+      if (p) {
+        const file = Bun.file(p);
+        if (await file.exists()) return new Response(file);
+      }
+      return new Response("No shared wallet file configured.", { status: 404 });
+    },
+
     // Serve index.html for all unmatched routes (must be last)
     "/*": index,
   },

src/modules/auth/features/connexion-nextgraph.feature

@@ -6,10 +6,10 @@ Fonctionnalité: Connexion NextGraph et chargement des données
   Et charger les données de test dans mon portefeuille
   Afin d'utiliser l'application avec mes propres données
 
-  # NB : l'ancien écran /login (LoginScreen) a été retiré — l'accès NextGraph
-  # passe désormais par l'AccessGateScreen (barrière ON par défaut), cf.
-  # decision_2026-06-17_assisted-wallet-import. Les scénarios @ui qui testaient
-  # le LoginScreen ont été supprimés en conséquence.
+  # NB : Festipod n'affiche plus d'écran d'accès à lui. Se connecter, c'est le
+  # SEUL `ensureIdentity()` attendu par AuthGate ; ce qu'un utilisateur voit ou
+  # fait pendant cette attente appartient au SDK, qui le montre. Aucun scénario
+  # ici ne pilote donc une barrière d'accès.
 
   # --- Data layer: comportement du portefeuille ---
 

src/modules/auth/screens/AccessGateScreen.tsx

@@ -1,137 +0,0 @@
-/**
- * AccessGateScreen — the *technical access barrier* of the stopgap.
- *
- * STOPGAP (see decision_2026-06-15_shared-wallet-login-flow). This is the
- * REAL NextGraph login, shown before the app renders. Because it precedes the
- * app, the user reads it as "access to the test environment", not as an app
- * login. Clicking "Entrer" triggers `connect()`, which redirects to the broker
- * to open the SHARED wallet. After return (inside the broker iframe) NG
- * auto-connects and the app shows the perceived login (ConnexionScreen).
- *
- * ASSISTED IMPORT (see the broker-import constraint, concept nextgraph-platform
- * + decision_2026-06-17). The hosted broker can't import a wallet inline during
- * web-app auth: a first-time device has no wallet, so the broker redirect would
- * dead-end. We therefore HAND the user the shared wallet FILE (download) + the
- * shared password and guide a one-time import on nextgraph.eu ("Import a Wallet
- * File"), BEFORE they click "Entrer". The wallet FILE is the correct static
- * primitive — a TextCode is a transient 5-min transfer, unusable to embed. Shown
- * only when a shared wallet is configured (FESTIPOD_SHARED_WALLET_PASSWORD).
- */
-
-import { useState, type ReactNode } from 'react';
-import { Button, Title, Text } from '../../../shared/components/sketchy';
-import { SHARED_WALLET_PASSWORD, SHARED_WALLET_FILE_URL, WALLET_IMPORT_URL, hasSharedWallet } from '../sharedWallet';
-
-interface AccessGateScreenProps {
-  status: 'disconnected' | 'connecting' | 'connected' | 'error';
-  error?: string;
-  onEnter: () => void;
-}
-
-// One numbered step: a badge + a title + the action for that step.
-function Step({ n, title, children }: { n: number; title: string; children: ReactNode }) {
-  return (
-    <div style={{ display: 'flex', gap: 12, marginBottom: 18 }}>
-      <div style={{
-        flexShrink: 0, width: 26, height: 26, borderRadius: '50%', background: '#E8590C',
-        color: '#fff', display: 'flex', alignItems: 'center', justifyContent: 'center', fontWeight: 700, fontSize: 14,
-      }}>{n}</div>
-      <div style={{ flex: 1, minWidth: 0 }}>
-        <Text style={{ margin: '2px 0 8px', fontWeight: 600, fontSize: 14 }}>{title}</Text>
-        {children}
-      </div>
-    </div>
-  );
-}
-
-export function AccessGateScreen({ status, error, onEnter }: AccessGateScreenProps) {
-  const connecting = status === 'connecting';
-  const [copied, setCopied] = useState(false);
-
-  const copyPassword = async () => {
-    try {
-      await navigator.clipboard.writeText(SHARED_WALLET_PASSWORD);
-      setCopied(true);
-      setTimeout(() => setCopied(false), 2000);
-    } catch {
-      // clipboard may be blocked — the password stays selectable
-    }
-  };
-
-  const entrer = (
-    <Button
-      variant="primary"
-      onClick={onEnter}
-      disabled={connecting}
-      style={{ width: '100%', opacity: connecting ? 0.6 : 1 }}
-    >
-      {connecting ? 'Accès en cours…' : 'Entrer'}
-    </Button>
-  );
-
-  return (
-    <div style={{ padding: 24, display: 'flex', flexDirection: 'column', height: '100%' }}>
-      <div style={{ flex: 1, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
-        <Title style={{ textAlign: 'center', fontSize: 30, marginBottom: 4 }}>Festipod</Title>
-        <Text style={{ textAlign: 'center', marginBottom: 24, color: '#888' }}>Espace de test</Text>
-
-        {hasSharedWallet() ? (
-          <>
-            <Text style={{ textAlign: 'center', fontSize: 14, color: '#666', margin: '0 0 20px', lineHeight: 1.5 }}>
-              Première connexion sur cet appareil ?<br />Chargez le portefeuille partagé, une seule fois.
-            </Text>
-
-            <Step n={1} title="Téléchargez le portefeuille">
-              <a
-                data-testid="shared-wallet-download"
-                href={SHARED_WALLET_FILE_URL}
-                download="festipod-wallet.ngw"
-                style={{
-                  display: 'block', textAlign: 'center', textDecoration: 'none',
-                  padding: 10, borderRadius: 10, background: '#E8590C', color: '#fff', fontWeight: 600, fontSize: 14,
-                }}
-              >
-                ⬇ Télécharger le portefeuille
-              </a>
-            </Step>
-
-            <Step n={2} title="Importez-le sur NextGraph">
-              <Text style={{ margin: '0 0 8px', fontSize: 13, lineHeight: 1.6, color: '#666' }}>
-                <a href={WALLET_IMPORT_URL} target="_blank" rel="noopener noreferrer" style={{ color: '#E8590C', fontWeight: 600 }}>
-                  Ouvrir la page d'import
-                </a>{' '}(nouvel onglet) → « Import a Wallet File » → choisissez le fichier → mot de passe :
-              </Text>
-              <div style={{ display: 'flex', alignItems: 'center', gap: 8 }}>
-                <code
-                  data-testid="shared-wallet-password"
-                  style={{ flex: 1, padding: '6px 10px', background: '#fff', border: '1px solid #eee', borderRadius: 8, fontSize: 13, userSelect: 'all' }}
-                >
-                  {SHARED_WALLET_PASSWORD}
-                </code>
-                <Button variant="accent-outline" onClick={copyPassword} style={{ padding: '6px 10px', fontSize: 12 }}>
-                  {copied ? 'Copié ✓' : 'Copier'}
-                </Button>
-              </div>
-            </Step>
-
-            <Step n={3} title="Revenez sur cet onglet et entrez">
-              {entrer}
-            </Step>
-          </>
-        ) : (
-          entrer
-        )}
-
-        {status === 'error' && (
-          <Text style={{ textAlign: 'center', fontSize: 12, color: '#c92a2a', marginTop: 12 }}>
-            {error || "Accès à l'environnement impossible. Réessayez."}
-          </Text>
-        )}
-      </div>
-
-      <Text style={{ textAlign: 'center', fontSize: 12, color: '#bbb' }}>
-        Version beta
-      </Text>
-    </div>
-  );
-}

src/modules/auth/screens/ConnexionScreen.tsx

@@ -1,92 +0,0 @@
-/**
- * ConnexionScreen — the *perceived* login of the stopgap.
- *
- * STOPGAP (see decision_2026-06-15_shared-wallet-login-flow). The real NG
- * login (AccessGateScreen) already happened and is not perceived as a login;
- * THIS screen is what the user experiences as "logging in": they pick a
- * username (no password — declarative). The username is persisted by
- * AccountContext (localStorage) and resolved against the accounts living in
- * the shared wallet.
- */
-
-import { useState } from 'react';
-import { Button, Input, Title, Text, Avatar } from '../../../shared/components/sketchy';
-import { useAccount } from '../../../shared/context/AccountContext';
-import { useFestipodData } from '../../../shared/context/FestipodDataContext';
-import { useNavigate } from '../../../app/router';
-
-export function ConnexionScreen() {
-  const { login } = useAccount();
-  const { users } = useFestipodData();
-  const navigate = useNavigate();
-  const [value, setValue] = useState('');
-
-  // Choosing a username completes the login → land on the app (not the '/'
-  // welcome/onboarding screen, which the access gate has replaced upstream).
-  const doLogin = (name: string) => {
-    login(name);
-    navigate('/home');
-  };
-
-  const submit = () => {
-    if (value.trim()) doLogin(value);
-  };
-
-  return (
-    <div style={{ padding: 24, display: 'flex', flexDirection: 'column', height: '100%' }}>
-      <div style={{ flex: 1, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
-        <Title style={{ textAlign: 'center', fontSize: 32, marginBottom: 8 }}>Connexion</Title>
-        <Text style={{ textAlign: 'center', marginBottom: 32, color: '#888' }}>
-          Choisissez votre nom d'utilisateur
-        </Text>
-
-        <div style={{ display: 'flex', flexDirection: 'column', gap: 12, marginBottom: 24 }}>
-          <Input
-            placeholder="@votrepseudo"
-            value={value}
-            onChange={(e: React.ChangeEvent<HTMLInputElement>) => setValue(e.target.value)}
-            onKeyDown={(e: React.KeyboardEvent) => {
-              if (e.key === 'Enter') submit();
-            }}
-          />
-          <Button variant="primary" onClick={submit} disabled={!value.trim()} style={{ width: '100%' }}>
-            Se connecter
-          </Button>
-        </div>
-
-        {users.length > 0 && (
-          <>
-            <Text style={{ textAlign: 'center', fontSize: 13, color: '#888', margin: '8px 0 12px' }}>
-              ou reprenez un compte existant
-            </Text>
-            <div style={{ display: 'flex', flexDirection: 'column', gap: 8 }}>
-              {users.map(u => (
-                <button
-                  key={u.id}
-                  onClick={() => doLogin(u.username)}
-                  style={{
-                    display: 'flex',
-                    alignItems: 'center',
-                    gap: 12,
-                    padding: 10,
-                    border: '1px solid #eee',
-                    borderRadius: 12,
-                    background: '#fff',
-                    cursor: 'pointer',
-                    textAlign: 'left',
-                  }}
-                >
-                  <Avatar initials={u.initials} color="#E8590C" size="sm" />
-                  <span>
-                    <Text style={{ margin: 0, fontWeight: 600 }}>{u.name}</Text>
-                    <Text style={{ margin: 0, fontSize: 12, color: '#888' }}>{u.username}</Text>
-                  </span>
-                </button>
-              ))}
-            </div>
-          </>
-        )}
-      </div>
-    </div>
-  );
-}

src/modules/auth/steps/data/connexion.steps.ts

@@ -2,31 +2,18 @@ import { Given, When, Then } from '@cucumber/cucumber';
 import { expect } from 'chai';
 import type { FestipodWorld } from '../../../../shared/support/world';
 
-// Seed data matching what bootstrapWallet uses
-import { seedEvents, seedUsers } from '../../../../shared/data/seedData';
-
 // --- Setup ---
 
 Given('le portefeuille est vide', async function (this: FestipodWorld) {
-  // Verify starting state: the harness graph should have its own seeded data.
-  // We clear events/users/participations to simulate a truly empty wallet.
-  await this.appFrame!.evaluate(() => {
-    const td = (window as any).__testData;
-    // Delete all events
-    for (const e of [...td.events]) td.events.delete(e);
-    // Delete all users
-    for (const u of [...td.users]) td.users.delete(u);
-    // Delete all participations
-    for (const p of [...td.participations]) td.participations.delete(p);
-  });
-
-  // Verify empty
+  // A fast INSTANT CHECK — assert the reactive read already shows nothing — NOT
+  // the old `clearWallet` per-entity-doc fan-out (a full wallet enumeration that
+  // was itself slow). No mutation, no polling.
   const counts = await this.appFrame!.evaluate(() => {
     const td = (window as any).__testData;
-    return { events: td.events.size, users: td.users.size, participations: td.participations.size };
+    return { events: td.events.size, users: td.users.size };
   });
-  expect(counts.events, 'Events should be empty').to.equal(0);
-  expect(counts.users, 'Users should be empty').to.equal(0);
+  expect(counts.events, 'An empty wallet should have no events').to.equal(0);
+  expect(counts.users, 'An empty wallet should have no users').to.equal(0);
 });
 
 Given('le portefeuille contient déjà des événements', async function (this: FestipodWorld) {
@@ -40,10 +27,13 @@ Given('le portefeuille contient déjà des événements', async function (this:
       const td = (window as any).__testData;
       td.loadTestData();
     });
-    // Wait for data to propagate
+    // Wait for data to propagate. `waitForFunction(fn, arg, options)` — the
+    // timeout goes in the THIRD slot; passed second it is silently taken as the
+    // predicate's argument and the wait runs on the 30s default instead.
     await this.appFrame!.waitForFunction(
       () => (window as any).__testData.events.size > 0,
-      { timeout: 10000 },
+      undefined,
+      { timeout: 75000 },
     );
   }
 });
@@ -58,22 +48,37 @@ When('je charge les données de test', async function (this: FestipodWorld) {
   });
   (this as any)._eventCountBefore = countBefore;
 
-  await this.appFrame!.evaluate(() => {
+  // AWAIT the seed's own promise (loadTestData returns a BootstrapResult promise)
+  // and record whether it actually seeded — so the propagation wait below can tell
+  // a genuinely-populated wallet (nothing to appear) from an empty one that must
+  // seed. Fire-and-forget here would let the assertions race the async seed.
+  const seededResult = await this.appFrame!.evaluate(async () => {
     const td = (window as any).__testData;
-    td.loadTestData();
+    const r = await td.loadTestData();
+    return { seeded: r?.seeded ?? false };
   });
+  (this as any)._loadSeeded = seededResult.seeded;
 
-  // Wait for data to propagate (if wallet was empty, data should appear)
-  await this.appFrame!.waitForFunction(
-    () => {
-      const td = (window as any).__testData;
-      // Either data was already there, or it should appear after loading
-      return td.events.size > 0 || td._loadResult?.seeded === false;
-    },
-    { timeout: 10000 },
-  ).catch(() => {
-    // Timeout is OK if wallet was already populated (idempotent case)
-  });
+  // Wait for data to propagate. Events reach the read via the discovery index (a
+  // fast, independent path); the seeded PROTECTED user docs reach it only through
+  // the by-need re-list, which can lag the public read under load. So wait for BOTH
+  // events AND users to settle (not just events) — otherwise `contient des
+  // utilisateurs` asserts before the protected read lands and flakes to users:0.
+  // On a wallet that already had data (seeded === false) there is nothing to wait
+  // for. The assertions still verify the real counts; this only synchronizes.
+  if (seededResult.seeded) {
+    await this.appFrame!.waitForFunction(
+      () => {
+        const td = (window as any).__testData;
+        return td.events.size > 0 && td.users.size > 0;
+      },
+      undefined,
+      { timeout: 75000 },
+    ).catch(() => {
+      // Timeout tolerated — the assertions below surface the real failure with a
+      // clearer message than a raw waitForFunction timeout.
+    });
+  }
 });
 
 // --- Assertions ---

src/modules/event/features/cycle-de-vie-evenement.feature

@@ -47,20 +47,24 @@ Fonctionnalité: Cycle de vie d'un événement
     Et l'utilisateur clique sur le bouton "J'y serai" si visible
     Alors l'écran contient le texte "Je participe"
 
-  # ngSet.delete() updates UI but doesn't persist — NG ORM limitation.
-  @e2e @wip
+  # Auto-suffisant : on s'inscrit d'abord (précondition), puis on se désinscrit,
+  # le tout dans la même session — ne dépend ni de l'état inter-scénarios ni de
+  # la persistance après reconnexion.
+  # FIX T02.c (2026-07-03) : le @wip est LEVÉ. La désinscription se reflète
+  # désormais dans l'UI et est DURABLE — leaveEvent supprime la Participation
+  # côté données via SPARQL DELETE-WHERE (docs.sparqlUpdate, le ng injecté), donc
+  # l'item ne ressuscite plus via la sync broker (l'ancien bug CRDT décrit dans
+  # caveat_participation-deletion). Prouvé : ce scénario @e2e passe + le scénario
+  # @data « désinscription persistante » de inscription-inbox.feature. (La
+  # validation multi-navigateur complète reste T02.f.)
+  @e2e
   Scénario: Se désinscrire d'un événement
     Quand l'utilisateur navigue vers l'écran "events"
     Et l'utilisateur clique sur un événement de la liste
     Et l'utilisateur attend que l'écran "event-detail" soit affiché
-    Et l'utilisateur clique sur le bouton "Je participe"
-    Alors l'écran contient le texte "J'y serai"
-
-  @e2e @wip
-  Scénario: La désinscription persiste après reconnexion
-    Quand l'utilisateur navigue vers l'écran "events"
-    Et l'utilisateur clique sur un événement de la liste
-    Et l'utilisateur attend que l'écran "event-detail" soit affiché
+    Et l'utilisateur clique sur le bouton "J'y serai" si visible
+    Alors l'écran contient le texte "Je participe"
+    Quand l'utilisateur clique sur le bouton "Je participe"
     Alors l'écran contient le texte "J'y serai"
 
   # --- Modification ---

src/modules/event/features/decouverte-publique.feature

@@ -0,0 +1,28 @@
+# language: fr
+# SUSPENDU (@wip) le 2026-08-03 — l'index global de découverte a été RETIRÉ du SDK :
+# il n'y a pas de découverte, on ne joint un document qu'en suivant un lien reçu.
+# Ce scénario décrit donc une capacité qui n'existe plus telle quelle. Il est
+# conservé, non supprimé : le besoin produit demeure, et il sera réalisé par un
+# ANNUAIRE Festipod — un document public dont l'app connaît le lien, alimenté par
+# dépôt et matérialisé par son curateur. À ce moment-là ce scénario est réécrit
+# sur l'annuaire et redevient actif.
+@EVENT @priority-1 @wip
+Fonctionnalité: Découverte publique via l'index global
+  En tant qu'utilisateur
+  Je veux découvrir les événements publics des autres comptes sans être connecté
+  à eux, afin de trouver des points de rencontre à rejoindre au-delà de mon
+  propre réseau.
+
+  # Découverte = lire l'INDEX GLOBAL. Publier un événement public, c'est soumettre
+  # sa référence à l'index (submitEventToIndex) ; découvrir, c'est lire l'index
+  # (readDiscoveredEvents) puis s'abonner aux documents référencés. L'app ne fait
+  # AUCUN fan-out cross-comptes et ne connaît ni l'hôte de l'index ni sa
+  # mécanique — le SDK possède l'index de bout en bout.
+
+  @data
+  Scénario: Un compte découvre l'événement public d'un autre compte non connecté
+    Étant donné le compte "@bob-public" publie un événement public "Concert au parc"
+    Et le compte "@alice-public" n'est pas connecté à "@bob-public"
+    Quand "@alice-public" découvre les événements publics
+    Alors "@alice-public" voit l'événement public "Concert au parc"
+    Et l'index global liste le document de l'événement

src/modules/event/features/e2e-multibrowser.feature

@@ -0,0 +1,108 @@
+# language: fr
+@EVENT @priority-1 @multibrowser @shared-wallet
+Fonctionnalité: Validation e2e multi-navigateurs des nouvelles features (T02.f)
+  En tant que développeur validant les fonctionnalités T02
+  Je pilote DEUX navigateurs isolés (contextes Playwright distincts, sessions
+  NextGraph indépendantes) portant le wallet partagé, chacun chargé dans l'app
+  via le broker réel (nextgraph.net), afin de prouver que les comportements
+  démontrables round-trippent réellement à travers le broker d'un navigateur à
+  l'autre — pas seulement dans le set réactif d'une seule page.
+
+  # NB périmètre : l'isolation cryptographique réelle (ReadCap/write-guard actifs,
+  # mono-document + setCurrentUser) est DIFFÉRÉE (mécanisme validé mais dormant,
+  # cf. T02.d/T02.g). Ces scénarios ne prouvent donc PAS l'isolation crypto entre
+  # navigateurs ; ils valident les COMPORTEMENTS démontrables cross-navigateur.
+
+  # --- Inscription + notification hôte (T02.c) ---
+  # Navigateur A = l'hôte (crée l'événement/PdR) ; navigateur B = un second
+  # compte qui s'inscrit. A reçoit la notification, matérialisée depuis l'inbox.
+
+  Scénario: Inscription dans un navigateur, notification hôte dans l'autre
+    Étant donné un navigateur "A" avec le wallet partagé
+    Et un navigateur "B" avec le wallet partagé
+    Et le navigateur "A" charge l'application via le broker
+    Et le navigateur "B" charge l'application via le broker
+    Et le navigateur "A" est connecté à NextGraph
+    Et le navigateur "B" est connecté à NextGraph
+    Quand le navigateur "A" crée l'événement "Rencontre au kiosque"
+    Et le navigateur "B" s'inscrit à l'événement "Rencontre au kiosque"
+    Alors le navigateur "B" devient participant de l'événement "Rencontre au kiosque"
+    Et l'inbox de l'événement "Rencontre au kiosque" reçoit un dépôt "new-participant"
+
+  # --- Désinscription persistante (T02.c, fix @wip) ---
+  # B se désinscrit → la participation disparaît côté broker (SELECT autoritatif)
+  # ET ne ressuscite pas après une re-sync du broker.
+
+  Scénario: La désinscription dans un navigateur ne ressuscite pas après re-sync
+    Étant donné un navigateur "A" avec le wallet partagé
+    Et un navigateur "B" avec le wallet partagé
+    Et le navigateur "A" charge l'application via le broker
+    Et le navigateur "B" charge l'application via le broker
+    Et le navigateur "A" est connecté à NextGraph
+    Et le navigateur "B" est connecté à NextGraph
+    Et le navigateur "A" crée l'événement "Café des curieux"
+    Et le navigateur "B" s'inscrit à l'événement "Café des curieux"
+    Et le navigateur "B" devient participant de l'événement "Café des curieux"
+    Quand le navigateur "B" se désinscrit de l'événement "Café des curieux"
+    Alors le broker ne contient plus aucune participation à l'événement "Café des curieux" pour le navigateur "B"
+    Et l'inscription de l'événement "Café des curieux" ne ressuscite pas dans le navigateur "B" après re-sync
+
+  # --- Découverte publique cross-comptes (T02.e) ---
+  # Bob (navigateur B) publie un événement PUBLIC ; Alice (navigateur A) le
+  # découvre SANS être connectée/amie avec Bob, via le fan-out public.
+
+  # --- Compteur fiable à la connexion du propriétaire (Option B, brief §D.2) ---
+  # Cadrage (recadré 2026-07-13) : ce n'est PAS une exigence de push temps-réel
+  # cross-session. Le compteur est STOCKÉ dans l'événement, SEUL le propriétaire
+  # l'écrit ; l'inscrit DÉPOSE dans l'inbox de l'événement ; le propriétaire traite
+  # ces dépôts à sa PROCHAINE CONNEXION (matérialisation fiable, barrière de sync de
+  # l'inbox). Une reconnexion / re-matérialisation de A est donc ACCEPTÉE — on ne
+  # vise pas « sans reload ».
+  #
+  # FIX (appliqué) : la matérialisation du propriétaire lit l'inbox APRÈS sa barrière
+  # de sync (`inbox.readSynced`, SDK `@ng-eventually/polyfill`), de sorte qu'un dépôt de l'inscrit déjà synchronisé au
+  # broker EST vu (plus de « 0 prématuré » mémoïsé) ; le materializer est lancé
+  # directement à la connexion ([ready, ownedKey]), pas seulement sur un push
+  # d'inbox. Source unique du NOMBRE : `event.participantCount` (le littéral local
+  # `participantCount: 1` du CreateEventScreen est retiré → départ à 0).
+  Scénario: Le compteur converge chez le propriétaire à sa prochaine connexion
+    Étant donné un navigateur "A" avec le wallet partagé
+    Et un navigateur "B" avec le wallet partagé
+    Et le navigateur "A" charge l'application via le broker
+    Et le navigateur "B" charge l'application via le broker
+    Et le navigateur "A" est connecté à NextGraph
+    Et le navigateur "B" est connecté à NextGraph
+    Et le navigateur "A" crée l'événement "Apéro réactif"
+    Et le navigateur "A" ouvre le détail de l'événement "Apéro réactif"
+    # Le créateur ne participe PAS automatiquement (pas de notion d'hôte) : à la
+    # création le compteur démarre à 0 (|inscriptions actives| = 0).
+    Et le compteur de participants réactif dans "A" pour "Apéro réactif" vaut 0
+    Quand le navigateur "B" s'inscrit à l'événement "Apéro réactif"
+    # À sa PROCHAINE CONNEXION, A traite l'inbox (barrière de sync) et matérialise le
+    # dépôt de B sur son propre doc → participantCount passe à 1. Symétrie avec B :
+    # après reconnexion, B lit le doc public mis à jour par A et voit 1 aussi.
+    Et le navigateur "A" se reconnecte et matérialise l'inbox
+    Alors le compteur de participants réactif dans "A" pour "Apéro réactif" vaut 1
+    Et le navigateur "A" affiche un participant "inconnu" pour "Apéro réactif"
+    Et le navigateur "B" se reconnecte et matérialise l'inbox
+    Et le compteur de participants réactif dans "B" pour "Apéro réactif" vaut 1
+    # Option B symétrique : B se désinscrit → à la prochaine connexion de A, A
+    # matérialise le marqueur "leave" depuis l'inbox et RECALCULE participantCount
+    # sur son propre doc → le compteur repasse à 0.
+    Quand le navigateur "B" se désinscrit de l'événement "Apéro réactif"
+    Et le navigateur "A" se reconnecte et matérialise l'inbox
+    Alors le compteur de participants réactif dans "A" pour "Apéro réactif" vaut 0
+    # Symétrie côté inscrit après désinscription : B voit aussi 0 après reconnexion.
+    Et le navigateur "B" se reconnecte et matérialise l'inbox
+    Et le compteur de participants réactif dans "B" pour "Apéro réactif" vaut 0
+
+  Scénario: Un navigateur découvre l'événement public publié dans l'autre
+    Étant donné un navigateur "A" avec le wallet partagé
+    Et un navigateur "B" avec le wallet partagé
+    Et le navigateur "A" charge l'application via le broker
+    Et le navigateur "B" charge l'application via le broker
+    Et le navigateur "A" est connecté à NextGraph
+    Et le navigateur "B" est connecté à NextGraph
+    Quand le compte "@bob-mb" publie un événement public "Concert au kiosque" dans le navigateur "B"
+    Et le compte "@alice-mb" découvre les événements publics dans le navigateur "A" sans être connecté à "@bob-mb"
+    Alors le navigateur "A" voit l'événement public "Concert au kiosque"