Name the script for what it does, now that it serves two providers

`link-polyfill.ts` handled one provider. It now handles two through a registry,
one of which is not a polyfill, so both the filename and the `link:` verb said
something false — and a name that is short but wrong misleads more than an opaque
one would.

It becomes `overlay-local-checkout.ts`, which is the operation: it copy-overlays a
local package checkout into node_modules for development. "link" also implied a
symlink, which is precisely what the script exists NOT to do — its own header
spends a paragraph on why.

No behaviour changed: same registry, same copy, same `--once`, same watch loop,
same assertion. Both providers exercised afterwards, each reporting the singletons
it must preserve — one package for the data layer, two for the indexing package,
whose own checkout carries `file:` links and would otherwise smuggle in a second
verifier.

Seven references repaired by rewriting the sentence that carried them rather than
swapping a path, across the script, `package.json`, `.env.example` and four
doctrine leaves. No compatibility alias left behind: an old name kept "just in
case" would restore exactly the ambiguity being removed.

.env.example

@@ -0,0 +1,50 @@
+# 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. C'est la forme du DEV
+# LOCAL et du harness de TESTS : le fichier vit sur le disque de la machine.
+FESTIPOD_SHARED_WALLET_FILE=/chemin/absolu/vers/festipod-wallet.ngw
+
+# Contenu du portefeuille partagé (.ngw), encodé en base64 — deuxième source
+# pour le même fichier. C'est la forme des DÉPLOIEMENTS (conteneur) : *.ngw est
+# gitignoré, donc `COPY . .` n'en embarque aucun et rien n'en monte un ; le
+# fichier n'étant pas un secret (l'app le sert à quiconque ouvre l'app), il
+# voyage comme une variable de config. `FESTIPOD_SHARED_WALLET_FILE` est
+# prioritaire quand les deux sont renseignées — voir le commentaire dans
+# src/index.ts. Générer la valeur avec, p.ex., `base64 -w0 festipod-wallet.ngw`.
+FESTIPOD_SHARED_WALLET_FILE_BASE64=
+
+# ── 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
+# overlay:polyfill` (overlay local réactif). Défaut = ../nextgraph/ng-eventually-js/packages/sdk.
+NG_EVENTUALLY_LOCAL=
+

.gitignore

@@ -32,3 +32,18 @@ report.[0-9]_.[0-9]_.[0-9]_.[0-9]_.json
 
 # Finder (MacOS) folder config
 .DS_Store
+.ng-tarballs
+
+# Playwright persistent profile (contains NG wallet)
+.playwright-profile/
+.playwright-profile-debug/
+playwright/.auth/
+
+*storybook.log
+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

@@ -0,0 +1,26 @@
+---
+type: _overview
+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/**"]
+---
+
+# App architecture
+
+How the app's code is **structured** and **assembled**. *Feature-based* architecture: the code is organized by **business domain** (module), not by technical layer.
+
+**Read this first:** [[rule_module-imports]] — the central invariant that keeps modules decoupled.
+
+## Links
+
+- [[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 empty until my profile document resolves, and an ownership answer can be UNKNOWN; neither means "no"
+- [[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 yourself** before believing the tests — and drive a whole flow rather than looking at the page, which is what a throwaway probe is for (`bdd-testing` → [[cookbook_live-probe]]).
+
+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,36 @@
+---
+type: caveat
+summary: Values a screen must not read as data once — currentUserId is EMPTY until my profile document resolves, an ownership answer can be UNKNOWN, and a useState seeded from an unresolved read (UpdateEventScreen) freezes blank; all look like ordinary values, none mean "no"
+last_checked: 2026-08-17
+---
+
+# Pitfall: "not answered yet" looks exactly like an answer
+
+Two things a screen receives can be *unresolved*, and in both cases the unresolved form reads like an ordinary value. Nothing throws.
+
+## `currentUserId` is empty until my profile resolves
+
+`currentUserId` **is** `currentUser?.id`: the NURI of **the profile document I own**. It is not derived from the signed-in identity and shares no id space with it — the identity the session signed in as is opaque, is never rendered, and never travels into a data call (`data-layer` → [[knowledge_context-internals]]). A screen never sees it except as an attribution string.
+
+Until that profile document resolves — the owned-document listing has to land, and a profile may have to be created — `currentUserId` is **`''`**, a perfectly ordinary empty string.
+
+- A **query** keyed on it (`getUserEvents`, `isParticipating`, `getFriends`, all defaulting to it) returns an **empty result**, which renders as "you have nothing" instead of "not ready yet".
+- A **mutation** that needs it now **rejects** rather than writing a malformed entity: `joinEvent` and `leaveEvent` throw, naming the cause. A caller must therefore *await* them and handle the rejection — the confirmation belongs **after** the write, never beside the call. A screen that fires and forgets shows a success it did not get.
+
+**The rule**: treat an empty `currentUserId` as *not ready*, never as *no data*.
+
+## An ownership answer can be UNKNOWN
+
+`getEventOwnership(eventId)` returns `'mine' | 'not-mine' | 'unknown'`, and `unknown` is a **real third answer** — the listing has not landed, or it failed (`data-layer` → [[knowledge_write-rights-are-ownership]]).
+
+Rendering it as "not yours" silently denies an owner their own event. Rendering it as a **disabled twin** of the real control is no better: a greyed pencil reads as "edit, broken" and invites a dead click. The slot stays occupied by a distinct *pending* mark, so the layout does not jump and nobody is told a wrong verdict — `app-security` → [[decision_2026-08-16_write-rights-are-the-owned-list]].
+
+Never derive permission from `unknown` either. A screen that opens an editor because the answer "was not a refusal" is editing on a guess; the edit route consults the same three-state answer the control does, and renders `unknown` as its own pending state — [[knowledge_screen-pattern]].
+
+> The participation→profile join is **not** the screen's business — it is done in the provider (`resolveParticipantUser`). Full mechanics: `data-layer` → [[knowledge_context-internals]].
+
+## A `useState` seed freezes on whatever the first render saw
+
+`UpdateEventScreen` reads `const event = eventId ? getEvent(eventId) : undefined;` from the reactive data plane, then seeds every editable field from it: `useState(event?.title ?? '')`, and likewise for `startDate`, `endDate`, `startTime`, `endTime`, `location`, `description`. A `useState` initializer runs **once**, at mount — unlike a value read directly in the render body, it does not track `event` afterwards.
+
+If the screen mounts before the event has landed in the reactive set — a direct navigation to the edit route, a slow reconnect — every field seeds to `''` and **stays blank**: the later, successful read of `event` never reaches state that already initialized. Nothing throws and nothing looks wrong; the form is simply empty. Same hazard as `currentUserId` and the ownership answer above — "not ready yet" reads as an ordinary value — just caught by `useState` instead of by a query result. Pre-existing, not fixed.

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

@@ -0,0 +1,20 @@
+---
+type: cookbook
+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: adding a screen
+
+A screen has to be wired up in **several places** — forgetting one produces silent bugs (see the `ConnectScreen` case, [[knowledge_screens]]).
+
+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. **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. **Add the route**: `src/app/router.tsx` — extend the `Route` type, add the case in `parsePath()` (and the reverse conversion if present).
+
+4. **Mount it in the shell**: `src/app/App.tsx` — add the case in the switch that maps `route.page` → component.
+
+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`.
+
+> 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

@@ -0,0 +1,44 @@
+---
+type: knowledge
+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/` is the **shell of the real app** (mobile web app), not a prototyping tool.
+
+> 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]]).
+
+## Provider stack
+
+`App.tsx` stacks the providers, then switches screens according to the current route:
+
+```
+ThemeProvider
+  └ 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
+```
+
+`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.
+
+### Ordering invariants (what breaks if you move a layer)
+
+- **`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()` — 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 — pulls the runtime config, sets the wallet global, **then** dynamically imports and renders `<App />`; the order is the point (`tech-stack` → [[knowledge_build-pipeline]], `app-security` → [[caveat_shared-wallet-global-before-gate-import]]) |
+
+The build and the bundler (Bun + Tailwind, alias `@/* → ./src/*`) are documented in the `tech-stack` concept.

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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+summary: Feature-based tree — business modules (event, user, home, auth, workshop, meeting, notification) and a shared/ layer importable by all of them
+---
+
+# Module structure
+
+The code is organized by **business domain**, not by technical layer.
+
+```
+src/modules/
+  event/          # Events: CRUD, discovery, participants, meeting points
+  user/           # Profiles, connections ("friends"), sharing
+  home/           # Dashboard, settings
+  auth/           # Login, welcome/onboarding
+  workshop/       # Workshop specs (features only, no screens)
+  meeting/        # Meeting point specs (features only)
+  notification/   # Notification specs (features only)
+```
+
+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
+
+## The `shared/` layer
+
+`src/shared/` holds everything reusable across modules:
+
+| Directory | Contents |
+|---|---|
+| `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`, `resolveOnce.ts` (single-flight resolution per key, unit-tested), `serialTask.ts` (a task that never runs concurrently with itself, unit-tested) |
+| `steps/`, `support/` | Shared Cucumber step definitions and hooks (concept `bdd-testing`) |
+| `lib/` | Helpers (`cn`, etc.) |
+
+The dependency rule between modules and `shared/` lives in [[rule_module-imports]].

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

@@ -0,0 +1,35 @@
+---
+type: knowledge
+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
+
+**Path-based** routing via the History API — hand-rolled router in `src/app/router.tsx` (`window.history.pushState` + `popstate`, `parsePath(pathname)`). No hash routing.
+
+## Route table
+
+| Path | Screen |
+|---|---|
+| `/` | WelcomeScreen |
+| `/home` | HomeScreen |
+| `/events` | EventsScreen |
+| `/events/new` | CreateEventScreen |
+| `/events/:id` | EventDetailScreen |
+| `/events/:id/edit` | UpdateEventScreen |
+| `/events/:id/invite` | InviteScreen |
+| `/events/:id/participants` | ParticipantsListScreen |
+| `/events/:id/meeting-points` | MeetingPointsScreen |
+| `/profile` | ProfileScreen |
+| `/profile/edit` | UpdateProfileScreen |
+| `/profile/friends` | FriendsListScreen |
+| `/profile/share` | ShareProfileScreen |
+| `/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 |
+
+> 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
+
+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

@@ -0,0 +1,48 @@
+---
+type: knowledge
+summary: Canonical anatomy of a screen — named function with no props, everything through useFestipodData/useNavigate/useParams, flex column layout, hard-coded French labels; the confirmation FOLLOWS the write, and a write affordance is decided by the three-state ownership answer
+last_checked: 2026-08-16
+---
+
+# Canonical screen pattern
+
+Every screen follows the same shape. Knowing it avoids reinventing or diverging.
+
+## Shape
+
+```tsx
+export function MyScreen() {              // named function, NEVER any props
+  const navigate = useNavigate();
+  const { eventId, userId } = useParams();
+  const { getEvent, currentUser, … } = useFestipodData();
+  const [local, setLocal] = useState(…);  // screen-local state (steps, selections)
+
+  const handleAction = () => {
+    // THE CONFIRMATION FOLLOWS THE WRITE — never beside the call.
+    void Promise.resolve(mutate(…))
+      .then(() => { showToast('Message', 'success'); navigate('/path'); })
+      .catch((err: unknown) => { console.error(…); showToast('Échec…', 'error'); });
+  };
+
+  return (
+    <div style={{ display:'flex', flexDirection:'column', height:'100%' }}>
+      <Header title="…" /* left/right optional */ />
+      <div style={{ flex:1, overflow:'auto' }}>{/* scrollable content */}</div>
+      <BottomNav active="…" />              {/* only on hub screens */}
+    </div>
+  );
+}
+```
+
+## Invariants
+
+- **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 NURI of the profile document this session **owns**, so it is **empty until that document resolves** — see [[caveat_identity-ids-in-screens]] before keying anything on it.
+- **The confirmation FOLLOWS the write.** Mutations reject rather than returning quietly, so a screen must `await` (or `.then`) before announcing anything: success toast and navigation on resolve, an error toast on reject, and the user kept on their edits. A toast fired beside the call announces a write that may never have happened — the pattern that had to be corrected on the event and profile edit screens.
+- **A write affordance is decided by ownership, in three states.** Both the control that *offers* the write and the screen that *performs* it consult the same answer (`data-layer` → [[knowledge_write-rights-are-ownership]]). `unknown` is never folded into either side: showing the form lets a non-owner edit on a guess, and bouncing them out tells a genuine owner their thing is not theirs. Render it as its own pending state.
+- **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]].
+
+To **create** a screen (the 3+ places to wire up), see [[cookbook_add-screen]].

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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+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
+---
+
+# Screens and components
+
+## Component library: `sketchy/` = modern theme
+
+⚠️ **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.
+
+Typical components: `Header`, `BottomNav`, `Button`, `Card`, `Input`, `Badge`, `Avatar`/`AvatarStack`, `Text`/`Title`, `Toggle`, `ListItem`, `Divider`, `Placeholder`, `BrokerBanner`, `NgStatus`.
+
+## Screen registry
+
+`src/screens/index.ts` imports every screen from every module and exposes:
+
+```typescript
+export const screenGroups   // grouped by domain (home, events, user, general)
+export const screens        // flat list
+export function getScreen(id): Screen | undefined
+```
+
+Used notably by Storybook (see concept `tech-stack`) to browse the screens.
+
+## Inventory
+
+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/**: `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]]).
+
+> The path → screen mapping lives in [[knowledge_routing]]. Most screens consume `useFestipodData()` (concept `data-layer`); the exception is `WelcomeScreen`.
+
+## Pitfall: incomplete registry
+
+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

@@ -0,0 +1,32 @@
+---
+type: knowledge
+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
+---
+
+# Styling system
+
+**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`)
+
+- 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', …`.
+
+## `app-*` classes
+
+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 for writing a screen
+
+- 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.
+
+## Pitfalls
+
+- **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

@@ -0,0 +1,24 @@
+---
+type: rule
+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
+---
+
+# Rule: a module never imports from another module
+
+**Modules import only from `shared/` — never from each other.**
+
+```
+src/modules/event/screens/EventDetailScreen.tsx
+  ✅ import from 'shared/components/...'
+  ✅ import from 'shared/context/FestipodDataContext'
+  ✅ import from 'src/screens' (registry types)
+  ❌ import from 'modules/user/screens/...'
+```
+
+## Why
+
+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.
+
+## How to check
+
+`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

@@ -0,0 +1,31 @@
+---
+type: _overview
+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, anonymat, pseudonyme, traçage, corrélation, identité, login, scope, isolation]
+  paths: ["src/modules/auth/**", "src/shared/context/NextGraphContext.tsx"]
+---
+
+# App security
+
+Festipod's **security, privacy and authorization** model.
+
+- **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]].
+- **Write rights** — only a document's owner writes it, and the owned-document listing is the whole answer; the app reads it to decide what to *offer*, never to enforce. Settled: [[decision_2026-08-16_write-rights-are-the-owned-list]].
+- **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.
+
+## Pitfalls
+
+- [[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
+
+> **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
+- [[decision_2026-08-16_write-rights-are-the-owned-list]] — may-I-write is the owned-document listing and nothing else; no capability probe is planned
+- [[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

@@ -0,0 +1,126 @@
+---
+type: brief
+summary: Target authorization matrix per data type (meeting point, registration, event, profile, connection) mapped onto the public/protected/private/dialog scopes; framing decisions settled and event update now settled as owner-only; host identity and event deletion still open
+last_updated: 2026-05-18
+---
+
+# Authorization matrix and query inventory
+
+**Status:** Incubating — target model, not frozen into rules.
+
+## Context
+
+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]]).
+
+## Framing
+
+### Actors (all authenticated)
+
+`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).
+
+### Verbs
+
+`create` · `read` (one-shot) · `subscribe` (reactive read) · `update` · `delete`. Conventions: `✓` allowed · `✗` forbidden · `cond` conditional · `—` not applicable.
+
+## Framing decisions (settled)
+
+- **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.**
+
+## Matrix per data type
+
+### Meeting point
+
+| Verb | Alice (= Host) | I (other registrant) | D (parent declarer) | U (plain user) |
+|---|---|---|---|---|
+| create | ✓ (becomes host) | — | ✗ | ✓ (becomes host) |
+| read | ✓ | ✓ | ✓ | ✓ |
+| subscribe | ✓ | ✓ | ✓ | ✓ |
+| update | ✓ | ✗ | ✗ | ✗ |
+| delete | ✓ | ✗ | ✗ | ✗ |
+
+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.
+
+### Registration to a meeting point
+
+`Inscription` links a user and a meeting point. **Personal data** (registrant + their connections). Composite act (a)+(b) above.
+
+| Verb | Alice (registrant) | C (connection) | H (host) | I (other registrant) | U |
+|---|---|---|---|---|---|
+| 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) | ✗ | ✗ |
+
+**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?
+
+### Event
+
+| Verb | Alice (= D) | H (host of a grafted meeting point) | U |
+|---|---|---|---|
+| create | ✓ (becomes declarer) | — | ✓ (becomes declarer) |
+| read / subscribe | ✓ | ✓ | ✓ |
+| update | ✓ (owner, sole writer) | ✗ | ✗ |
+| delete | ? **to be decided** | ✗ | ✗ |
+
+**Update is settled — owner only**, and forced rather than chosen: only a document's owner writes it and no call adds a writer, so "wiki" is not expressible ([[decision_2026-08-16_write-rights-are-the-owned-list]]). It constrains deduplication (concept `functional-domain`, [[brief_2026-06-15_event-deduplication]]). **Open:** who may **delete** an event, and what becomes of the grafted meeting points (orphaned/cascade/marked deleted)?
+
+### User profile
+
+**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).
+
+| Verb | Alice | C | U |
+|---|---|---|---|
+| create | ✓ (at sign-up) | — | — |
+| read — network | ✓ | ✓ | ✗ |
+| read — private | ✓ | ✗ | ✗ |
+| subscribe | ✓ | ✓ (network) | ✗ |
+| update | ✓ | ✗ | ✗ |
+| delete (account) | ✓ | ✗ | ✗ |
+
+**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?).
+
+### Connection (friendship link)
+
+Bilateral. `DemandeDeConnexion` (one-sided, pending) → `Connexion` (bilateral, upon acceptance; opens access to personal data). Alice's connection list is **personal** (Alice + her connections).
+
+| Verb | Alice (initiator) | Bob (other side) | C | U |
+|---|---|---|---|---|
+| create the request | ✓ | — | — | — |
+| accept | — | ✓ | — | ✗ |
+| read Alice's list | ✓ | ✓ | ✓ | ✗ |
+| subscribe | ✓ | ✓ | ✓ | ✗ |
+| delete (break A↔B) | ✓ | ✓ | ✗ | ✗ |
+
+**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)).
+
+## Derived scopes
+
+Heuristic: same scope if (a) same write-authorization cell *and* (b) accessed together. Three **scopes** emerge, plus the bilateral case:
+
+| Scope | Write | Read | Data |
+|---|---|---|---|
+| **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) |
+
+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.
+
+## Query inventory per screen
+
+*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
+
+- 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, and the fetch that sets it must never be gated on NODE_ENV (production serves from src/). Missing it: ensureIdentity() throws, AuthGate shows the reason.
+last_checked: 2026-08-16
+---
+
+# 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]]). That fetch may be skipped on **one** condition: the global is already set, which only a `build.ts` bundle's `define` does. **Never on an `NODE_ENV` test** — this project's production serves from `src/` exactly like dev, so gating the fetch on "production" is what removed the wallet from the deployed app and left it unable to sign anybody in.
+- **`@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` cannot sign anyone in, and it **says so** — `ensureIdentity()` rejects and `AuthGate` renders its named error panel carrying the reason. Verified live on a rejected sign-in: a refusal shows the reason, not a blank page (`bdd-testing` → [[cookbook_live-probe]]). The failure mode still worth fearing is the **silent** one: a promise that never settles either way renders nothing at all and logs nothing — `app-architecture` → [[caveat_boot-unverified-outside-broker]].
+
+**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/decision_2026-08-16_write-rights-are-the-owned-list.md

@@ -0,0 +1,30 @@
+---
+type: decision
+summary: May-I-write is answered by the list of documents this session owns, and by nothing else — no "may I write this?" call is planned, now or later; the residual window this leaves open is accepted rather than closed
+---
+
+# Decision (2026-08-16): write rights are the owned list, permanently
+
+## Context
+
+Screens need to know whether this session may **write** an event's document, in order to offer an edit affordance at all. [[contract_polyfill-surface]] leaves exactly one reading of write rights: *"Only a document's owner writes to it. Holding its read key never grants a write"*, and, under non-guarantees, *"No delegated writing. A received key never grants a write, and no call adds a writer to a document."* Owning a document and being able to write it are therefore the same fact, and `storeRegistry.listMyEntityDocs(scope)` is the only call that reports it. No call answers "may I write this?" — the surface publishes none.
+
+## Decision
+
+**Ownership, read from the owned-document listing, IS the write right — and that is the permanent answer.** The project owner has ruled that **no capability probe is planned**: Festipod will not ask the provider for a "may I write this?" call, and no future one is being waited on. `listMyEntityDocs('public')` says which events are this session's, and a screen asks nothing else.
+
+The answer a screen receives is **three-state** — `mine` / `not-mine` / `unknown` — never a boolean. A rejected or not-yet-landed listing means **UNKNOWN**, and the contract is explicit that *"a rejection means 'unknown', never 'absent'"*. Collapsing it into "not mine" is how an owner gets silently told their own event is not theirs.
+
+## Consequences accepted with it
+
+- **UNKNOWN renders neither the control nor a greyed twin of it.** A disabled look-alike reads as "edit, broken" and invites a dead click; the slot stays occupied by a distinct pending mark, so an owner is never silently told the event is not theirs. Screen-side rule: `app-architecture` → [[caveat_identity-ids-in-screens]].
+- **"Not mine" is inferred from ABSENCE**, and absence is not authoritative. The reactive read and the listing are two separate mechanisms, so an event can be on screen a moment before a listing can see it; ruled out in that window, it is only re-examined when some other unclassified event triggers a fresh listing. This residual is **deliberate and stated**, not an oversight.
+- **The window is not closed**, because closing it needs either a timer — polling, forbidden by `bdd-testing` → [[rule_no-broker-polling]] — or the probe call this decision rules out. Accepting a bounded wrong answer is the arbitration; do not "fix" it with a poll.
+
+## Rejected alternative
+
+**Raise the missing probe as a contract gap and wait for it.** Rejected by the project owner: the contract's ownership rule is not an omission, it is the model — a document has one writer, and a list of one's own documents is a complete answer to who that is. Treating it as a gap would keep an affordance permanently provisional against a call that is not coming.
+
+## Scope
+
+Applies to every write-affordance question the app asks, not only the event edit pencil. How the answer is derived and where it lives: concept `data-layer` → [[knowledge_write-rights-are-ownership]].

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

@@ -0,0 +1,37 @@
+---
+type: knowledge
+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
+---
+
+# Authentication
+
+**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.
+
+## The flow — one act, no screen of Festipod's own
+
+**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.
+
+**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]].
+
+**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]].
+
+**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 — the identity and the profile are two things
+
+**The identity** is what `ensureIdentity()` returns, and nothing else derives it. The contract calls it **opaque**: do not parse it, split it, or render it as a readable name. Festipod holds it for display attribution and logging only, and **never passes it to a data-layer call** — no call takes one.
+
+**The profile** — pseudo, name, initials — is **Festipod's own object**, not something the SDK knows about. "My profile" is the profile **document I own**, resolved from the owned-document listing; a failed listing leaves the answer UNKNOWN, never "none", and the app never presents somebody else's profile as mine. When a person has no profile, one is created at sign-in with placeholders that read as unset — never a plausible name, never anything derived from the identity.
+
+The two share no id space and there is **no join between them**. The profile value is therefore empty until that document resolves — 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

@@ -0,0 +1,27 @@
+---
+type: knowledge
+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
+---
+
+# Trust model
+
+**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`).
+
+Principles:
+
+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.
+
+   The one thing the app *does* read is **write rights**, and it reads them to decide what to **offer**, never to enforce: only a document's owner writes it, so the owned-document listing is the whole answer, in three states ([[decision_2026-08-16_write-rights-are-the-owned-list]]). Enforcement stays below — a screen that got the affordance wrong offers a doomed action, it does not open a hole.
+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.
+
+   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]]).
+
+## The point to watch
+
+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

@@ -0,0 +1,42 @@
+---
+type: _overview
+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", "@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
+
+BDD tests written in **Cucumber/Gherkin in French** (`Etant donné`, `Quand`, `Alors`) across **3 layers** of increasing cost.
+
+**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*.
+
+## The 3 layers
+
+```
+       /\  @e2e   real app inside the broker iframe — critical journeys
+      /  \
+     /----\  @data  mutations & persistence through the real NextGraph broker
+    /------\
+   /  @ui   \  in-process screen rendering (happy-dom + seed) — the bulk of the volume
+  /__________\
+```
+
+## Links
+
+- [[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_data-suite-has-no-fixtures]] — **known, not fixed**: the fixture seed writes nothing into a connected wallet, so `@data` scenarios that assumed seeded data have none
+- [[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`)
+- [[cookbook_live-probe]] — verifying a flow for real when the suite cannot answer: a throwaway Playwright probe on the real app, what it must collect, and why its findings must be written down the same day

.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_data-suite-has-no-fixtures.md

@@ -0,0 +1,29 @@
+---
+type: caveat
+summary: Known, not fixed — the fixture seed is off for connected wallets, so every @data scenario that assumed seeded events or profiles now runs against whatever the shared wallet happens to hold; "load test data" is a no-op that reports success
+last_checked: 2026-08-16
+---
+
+# Caveat: the `@data` suite lost its fixtures
+
+## What changed under it
+
+No fixture is written into a connected wallet any more, by any route — a product decision enforced in one place (`concept data-layer`, [[knowledge_seed-data]]). The `@data` layer did not ask for that and was not adapted to it.
+
+## What that does to the suite
+
+The bridge's `loadTestData()` still resolves, and it reports **`seeded: false`** with no documents created. So:
+
+- Scenarios that **load test data and then assert on it** (`auth/connexion-nextgraph.feature`: loading the fixtures, the "not reloaded twice" idempotence check, "the events have NextGraph identifiers") no longer have anything to assert on. The call succeeds; nothing is written.
+- Scenarios whose background **assumes a seeded wallet** ("le portefeuille contient des données de test", "un événement {string} existe" — which seeds on demand when the wallet reads empty) now depend entirely on what the shared wallet happens to already hold.
+- Nothing raises. A no-op seed reports success, which is the failure mode to expect: a green step followed by an assertion that finds nothing.
+
+## What NOT to do about it
+
+**Do not re-enable the seed for the tests, and do not add a test-only bypass of the enforcement point.** The switch is enforced at `bootstrapWallet` precisely so no caller can walk around it, and a harness is a caller like any other. **Do not weaken the affected scenarios into something that passes** either.
+
+The suite needs scenarios that **create what they need through the app's own path** (the same `createEvent` / `joinEvent` a user drives), rather than a background that assumes a pre-populated wallet. That is the direction; it is not done.
+
+## Related
+
+This compounds [[caveat_data-scenarios-share-one-wallet]] — scenarios already could not choose their identity or start from a clean slate, and now they cannot furnish that slate either. Both are open.

.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

@@ -0,0 +1,21 @@
+---
+type: caveat
+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: source-analysis leftovers in `world.ts`
+
+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 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.
+
+## Migration plan (in progress)
+
+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`.
+
+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

@@ -0,0 +1,36 @@
+---
+type: cookbook
+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: adding a scenario / a step
+
+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. **Pick the layer** (see [[rule_test-layer-contracts]]): rendering assertion → `@ui`; mutation/persistence → `@data`; full journey → `@e2e`.
+
+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. **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. **⚠️ `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 is undefined
+   // ✅ await appFrame.evaluate((t) => td.getEventByTitle(t), eventTitle)
+   ```
+   Always `await` (forgetting it means asserting before the promise resolves).
+
+6. **⚠️ `waitForFunction` timeout goes in the THIRD slot, not the second.** Playwright's signature is `waitForFunction(pageFunction, arg, options)`. Passing `{ timeout: N }` where `arg` belongs is **not an error**: it is accepted as the page function's *argument*, no options are supplied, and the wait silently uses the **30 s default** while the source reads 5, 10 or 60. When there is no argument to pass, the slot must be filled explicitly:
+   ```ts
+   // ❌ await frame.waitForFunction(fn, { timeout: 10000 })            // waits 30 s
+   // ✅ await frame.waitForFunction(fn, undefined, { timeout: 10000 }) // waits 10 s
+   ```
+   This had gone unnoticed on **seventeen** calls at once, nine of which meant to wait *less* than the default. It is worth honouring the written number: a wait that is too short fails loudly and names its step, whereas thirty seconds obtained by accident hides a real slowness and makes the source lie. Same family as the pitfall above — both are Playwright argument slots that accept the wrong thing without complaining.
+
+7. **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.
+
+8. **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`).
+
+9. **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/cookbook_live-probe.md

@@ -0,0 +1,30 @@
+---
+type: cookbook
+summary: How to verify a flow for real when the suite cannot answer — a throwaway Playwright probe that boots the REAL app in a real browser against the real broker and drives the UI as a user does; what it must collect, and why its findings must land in doctrine the same day.
+last_checked: 2026-08-16
+---
+
+# Driving the real app with a throwaway probe
+
+A **probe** is a one-off Playwright script, outside Cucumber — no World, no hooks, no fixtures — that boots the **real app** in a real browser against the **real broker** and drives its interface the way a user does. You write it, you run it, you read it, you delete it.
+
+## When to reach for one
+
+Before believing a flow works. The create-and-participate flow had been declared *correct by construction* on typecheck, build and reading; the first probe ever run against it found **three defects** none of those could see — all three now fixed, though one left a residual one-connection display lag whose cause sits outside the app ([[caveat_participant-count-one-connection-lag]] in `data-layer`).
+
+Reach for it when the suite cannot answer the question: the `@data` run dies silently from around its sixth scenario ([[caveat_wallet-bloat-hang]]), its scenarios have no fixtures ([[caveat_data-suite-has-no-fixtures]]), and entry paths are covered by nothing ([[caveat_first-time-entry-untested]], `app-architecture` → [[caveat_boot-unverified-outside-broker]]).
+
+## Method
+
+1. **Drive the app's own interface, never a bridge.** A probe that calls into the data context proves the data context. The whole point is the collaboration between the layers, so the only inputs are the ones a user gives — clicks, typing, waiting — and the only outputs are the ones a user sees.
+2. **Reuse the boot the `@e2e` layer already documents** ([[knowledge_e2e-layer]]) rather than inventing one: the app server on its own port, the broker round-trip, the app in its iframe. Do not build a second way in.
+3. **Collect `pageerror` and `console` from the first navigation.** The findings that matter surface as a rejection raised *inside a layer you never called* — invisible on screen except as a panel saying something failed.
+4. **Time the steps you assert on.** "The toast landed after the write" and "1.8 s" are two different findings; the second is what makes a later regression legible.
+5. **Keep watching after the confirmation, then reconnect.** A step that reports honestly can still leave the flow wrong. Give the state a real interval (minutes, not a tick), then come back through a fresh load — most of what a probe finds lives after the point where a test would have asserted green.
+6. **Say what state you started from.** A **brand-new origin with a brand-new identity** is what separates a real defect from accumulated wallet state, and a finding reported without it is not yet a finding. Report the run count too (*"3 of 3"*).
+
+## What a probe is not
+
+It is **not a regression guard**: nothing re-runs it, and a deleted script protects nothing. Its whole value is converted at the end of the run, into doctrine or a `bug_` leaf, the same day — a probe run that is not written down bought nothing. Recording an observation, mark **VERIFIED** (seen, with the run count) apart from **INFERRED** (the explanation you reached for); a real symptom does not certify its diagnosis.
+
+> **The lesson that pays for the method: honest steps do not add up to an honest flow.** Every step of the sign-up reports truthfully — the mutation rejects rather than lying, the confirmation follows the write — and the flow as a whole still announces a success it does not obtain. No layer can see that from inside itself; only exercising the whole thing end to end shows it.

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

@@ -0,0 +1,37 @@
+---
+type: decision
+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
+
+**Date:** 2026-03-12 15:00
+**Status:** Accepted
+
+## Context
+
+`@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: 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: 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** — 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
+
+**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.
+
+> Detailed lifecycle mechanics: [[knowledge_data-layer-broker]].

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

@@ -0,0 +1,46 @@
+---
+type: knowledge
+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
+---
+
+# Cucumber setup
+
+26 `.feature` files (US-1 to US-26), all in **French**, tagged `@CATEGORIE @priority-N` (categories EVENT, WORKSHOP, USER, MEETING, NOTIF).
+
+## Layout
+
+Features and steps are **colocated with their module**:
+
+```
+src/modules/event/features/us-13-creer-evenement.feature
+src/modules/event/steps/{ui,data,e2e}/
+```
+
+**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)
+
+The French screen names (`"accueil"`, `"détail événement"`, `"mon profil"`…) map to screen IDs through `screenNameMap`.
+
+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` 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.
+
+## The test harness is built on demand
+
+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]]).
+
+## Auto-generated files
+
+Scripts under `scripts/` parse features and steps into TS data consumed by the browsing tool:
+
+| 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` |
+
+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

@@ -0,0 +1,42 @@
+---
+type: knowledge
+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 as the app does, per-scenario isolation is ABSENT and the seed now writes nothing
+last_checked: 2026-08-16
+---
+
+# The `@data` layer (real broker)
+
+`@data` exercises the **real NextGraph pipeline** through a broker, not mocked data.
+
+## Architecture
+
+```
+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)
+  → window.__testData bridge
+```
+
+**Dual mode**: real broker (`harness-ng.tsx`, the default) or mock fallback (`harness.tsx`, standalone DeepSignalSets if the NG build fails).
+
+## Wallet lifecycle (automated, CI-ready)
+
+- **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`.
+
+> 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]].
+
+## Technical details
+
+- **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`, and what goes in it is **the profile document this session owns** — resolved from the owned-document listing, and created at sign-in when there is none, so it lags behind the public events. Steps wait for `ensureCurrentUser()` before `joinEvent`, then wait (`waitForFunction`) for the participation to be read back. Waiting is no longer optional politeness: `joinEvent` and `leaveEvent` now **reject** when the profile is unresolved, so a step that fires too early fails loudly instead of passing over a write that never happened.
+- **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 bridge's `loadTestData` no longer writes anything.** No fixture reaches a connected wallet by any route, and the enforcement point is deliberately un-bypassable — so the call resolves, reports nothing seeded, and every scenario that assumed seeded events or profiles is now running on whatever the shared wallet already holds. Read [[caveat_data-suite-has-no-fixtures]] before diagnosing an empty assertion, and do not re-enable the seed for the tests.

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

@@ -0,0 +1,76 @@
+---
+type: knowledge
+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
+---
+
+# The `@e2e` layer (real app)
+
+`@e2e` tests the **UI of the real app** running inside the broker iframe — unlike `@data`, which loads a test harness.
+
+## Architecture
+
+```
+Cucumber → Playwright (Chromium, persistent profile)
+  → https://nextgraph.net/redir/#/?o=http://127.0.0.1:{appPort}
+  → 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
+```
+
+**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
+
+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` plus a `popstate` dispatch (path-based routing, see `app-architecture`).
+
+## Differences from `@data`
+
+| Aspect | `@data` | `@e2e` |
+|---|---|---|
+| 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) |
+
+> **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]]).
+
+## Scenario identity, and why no scenario drives the SDK's barrier
+
+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

@@ -0,0 +1,63 @@
+---
+type: knowledge
+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
+---
+
+# Multi-browser harness (shared 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]]).
+
+| Concern | What it decides | Expressed by |
+|---|---|---|
+| **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'`) |
+
+## Wallet model — one is exercised, one is dormant
+
+- `É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).
+
+## Architecture (where things live)
+
+- **`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).
+
+## Wallet provisioning
+
+- **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**.
+
+> 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`).
+
+## No scenario left drives the real app through a fresh context
+
+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]].
+
+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.
+
+## Isolation of the contexts (a property of the harness, not a tested behaviour)
+
+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**.
+
+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.
+
+## Files
+
+- 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.
+
+## The `@wip` convention (now enforced)
+
+`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).
+
+## Links
+
+- [[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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+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
+---
+
+# The `@ui` layer
+
+`@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` (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.
+- **`@ui` is untouched by the connected-wallet seed switch.** No fixture may be written into a *wallet* any more, but `@ui` renders the fixtures straight into React state through `LocalDataProvider` and writes to nothing — so these fixtures are unchanged and stay the layer's ground ([[caveat_data-suite-has-no-fixtures]] is a `@data` problem only).
+
+## Good assertion patterns
+
+```ts
+// Visible text
+expect(this.getDomText()).to.include('Marie Dupont');
+// Element present, by class/role
+expect(this.renderedDoc!.querySelector('.app-avatar')).to.not.be.null;
+// Conditional rendering (filled vs empty)
+expect(this.renderedDoc!.querySelectorAll('.app-card').length).to.be.greaterThan(0);
+// 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;
+```
+
+## `FestipodWorld` fields & helpers (`src/shared/support/world.ts`)
+
+- `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]]).
+
+## ⚠️ 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

@@ -0,0 +1,29 @@
+---
+type: rule
+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
+---
+
+# Rule: the test layer contract
+
+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` — 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` — 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` — 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.
+
+## Why cost dictates the pyramid
+
+`@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`.
+
+## `@ui` anti-patterns to ban
+
+```ts
+// ❌ regex over the source: couples the test to the structure of the code
+expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source)).to.be.true;
+// ❌ implementation details
+expect(/showDuplicateWarning/.test(source)).to.be.true;
+```
+
+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

@@ -0,0 +1,40 @@
+---
+type: _overview
+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, "@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
+
+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**.
+
+> **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]].
+
+## Interfaces (one folder per interface, engagement + our declaration)
+
+Each external interface this concept consumes lives in **its own folder**, holding the provider's engagement (pulled, version-pinned) and — once Festipod actually consumes it — our own declaration beside it.
+
+- `polyfill-surface/` — [[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. Beside it, [[usage_festipod]] — what the app *actually* calls, the conditions it needs, and the frictions measured against the engagement. **Frictions are how a need reaches the provider**: put it there, then signal it out of band.
+- `indexing-layer/` — [[contract_indexing-layer]], the `@ng-helpers/indexing` engagement, PULLED and pinned on `v1.0.0`: creating an index, depositing references into it, curating it, reading it back. **Nothing consumes it yet** — no declaration is authored beside it, deliberately, since an empty one would say nothing.
+
+## Model & data
+- [[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; the generated ORM names carry no `Fp` prefix and are aliased at the import sites
+- [[knowledge_seed-data]] — the fixtures, and the master switch that keeps them out of any connected wallet
+- [[knowledge_context-internals]] — pitfalls of `FestipodDataContext` (identity vs profile, which profile is mine and when it arrives, no silent success, the legacy participation id space, `participantCount`, local no-op)
+- [[knowledge_write-rights-are-ownership]] — may I write this? is answered by the owned-document listing, in three states
+
+## Write rules
+
+- [[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
+
+## Pitfalls (read before touching deletions / the participant count)
+
+- [[caveat_participation-deletion]] — withdrawal must be **authoritative** and must not come back
+- [[caveat_participant-count-one-connection-lag]] — `participantCount` lags one connection behind the write that produced it; cause is outside the app, no app-side compensation
+
+> 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_participant-count-one-connection-lag.md

@@ -0,0 +1,37 @@
+---
+type: caveat
+summary: After a sign-up (or a withdrawal) the participantCount a bystander sees needs one connection more than the write itself — written on the first reconnect, displayed on the second. Cause is outside the app, in the layer not notifying you of your own actions; no app-side compensation, deliberately.
+last_checked: 2026-08-17
+---
+
+# Caveat: the participant count lags one connection behind the write that produced it
+
+In the create-and-participate flow — declare an event, sign up to it — the event's `participantCount` **stays at 0 for the rest of the session**, VERIFIED over two-minute intervals, while the button already reads « ✓ Je participe ». The count starting at 0 on creation is correct and is not this caveat ([[knowledge_context-internals]] §participantCount: no host baseline).
+
+## The convergence, VERIFIED
+
+The count does converge, but **one connection later than the write**: the first reconnect after the sign-up still reads 0; the count only reaches the true value on the **second** reconnect. The same one-connection lag applies to a withdrawal — earlier it looked like withdrawal converged immediately while sign-up never did, but that asymmetry was the multi-inbox race below, not a separate mechanism: with one inbox per document, both paths share this same lag.
+
+## Two measured causes, both about the layer not notifying you of your own actions
+
+- A deposit you make into an inbox **you watch** produces no push — so the owner's own materializer, sitting on its own inbox, is not woken by its own sign-up.
+- A write to **your own document** is not re-read by `watchShape` in the writing session — so the materializer's own count write does not come back on the load that made it, only on the one after.
+
+Both are gaps in [[contract_polyfill-surface]], raised with the provider ([[rule_app-uses-sdk-surface-only]] in this concept) — not something to work around in the app.
+
+## Why nothing is done about it here
+
+Any retry or short-interval poll to paper over the gap is exactly what `bdd-testing` → [[rule_no-broker-polling]] forbids. The count is not lost — the materializer fires directly on connection, not only on a push, so it always catches up on the second reconnect — so there is nothing to compensate for beyond the one connection of delay.
+
+## What this is not
+
+Not data loss, not a race: [[knowledge_context-internals]] §participantCount describes the concurrency-safety the flow now has (one inbox per document, one materialize cycle at a time, a monotonic guard against a stale write). This caveat is the residual display delay that mechanism does not close, because its cause sits below it.
+
+## Reproduce
+
+1. Connect, declare an event (the count shows 0 — correct).
+2. Sign up to it; the button reaches « ✓ Je participe ».
+3. Stay on the page and watch the count for a couple of minutes — it stays at 0.
+4. Reconnect once — still 0. Reconnect a second time — now correct.
+
+Method: `bdd-testing` → [[cookbook_live-probe]]. Watching *after* the confirmation, over a real interval, and across two reconnects, is what makes this visible at all.

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

@@ -0,0 +1,15 @@
+---
+type: caveat
+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: withdrawal must be authoritative
+
+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.
+
+## The pitfall
+
+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.
+
+**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/decision_2026-08-17_discovery-through-a-shared-index.md

@@ -0,0 +1,33 @@
+---
+type: decision
+summary: Public events become findable through a shared index (@ng-helpers/indexing) rather than a direct read of the public scope, which never actually unioned every user's store; the package's append-only, curation-gated, never-refreshed shape is accepted as-is, with four costs named rather than solved
+---
+
+# Decision (2026-08-17): discovery through a shared index
+
+## Context
+
+[[knowledge_data-scopes-and-discovery]] (concept `functional-domain`) named "reading the `public` scope" as the primary discovery axis. [[contract_polyfill-surface]] shows why that never delivered cross-user discovery: `storeRegistry` places and lists documents **per session** (`listMyEntityDocs`, `resolveScopeGraph` — both scoped to "this session's own"), and no published call unions every user's public store into one readable set. A declared event was therefore reachable by its own declarer only, and the whole cross-user sign-up flow — the product's premise — was unreachable.
+
+## Decision
+
+Festipod adopts **`@ng-helpers/indexing`**, pinned at `1.0.0` ([[contract_indexing-layer]]), as the mechanism that makes a public event findable by someone other than its declarer.
+
+An index is an ordinary public document that the package builds on top of the polyfill: nothing marks it as one, so Festipod will hardcode its reference in the app's own source. Depositing a reference to an event into the index (`refer`) is open to anyone; only the index's owner turns deposits into visible entries (`curate`); `read` returns those entries ordered by one declared field, compared **as strings**. Festipod indexes on the event's **ISO-8601 start date** specifically because string comparison then sorts entries chronologically for free — that field is being added to the event shape by other work in parallel and is not yet written by any create/update path.
+
+**No code consumes the index today.** This decision records the arbitration and its accepted costs ahead of the wiring: which identity owns and curates Festipod's index, and where `refer`/`curate`/`read` are called from, are not yet decided.
+
+## Consequences accepted with it
+
+- **Curation is a role, not a line of code.** Nothing lands in the index until its owner curates the deposits, and the package schedules no curation run — there is "no timing and no delivery promise" ([[contract_indexing-layer]] → Non-guarantees). Someone, or something, must be relied on to curate; that is an operator commitment this decision takes on, not a gap left for later code to close.
+- **An event declared before its document could carry the indexed field can never be indexed.** `read` refuses a document that declares no field at all, and curating a reference to an object missing the field reports `skipped: "no-field"` — every run, forever, since a deposit is never consumed and an already-written document does not retroactively gain a field it was not written with. There is no way back into the index for those events short of a fresh index.
+- **A withdrawn or corrected event stays listed.** The package removes nothing "at any level, ever" — the only answer to a bad entry is a fresh index, not a fix to this one. Whatever eventually reads Festipod's index must tolerate an entry whose object no longer resolves, or resolves to something changed; that tolerance is the app's to build, the package provides none of it.
+- **An entry's position is frozen at the moment it was curated.** The index never re-reads an already-indexed object, so the value it sorts by is whatever that object held at curation time — a later correction to the real event's start date does not move its entry. `read`'s ordering is faithful to the index, not to the live object.
+
+## Rejected alternative
+
+**Wait for the polyfill to publish a cross-store read** — a call that would union every user's `public` scope into one set, restoring the assumption the app started on. Rejected: nothing in [[contract_polyfill-surface]] offers this and none is signalled as coming, and the app cannot leave its central discovery flow unreachable while waiting on a capability nobody has committed to.
+
+## Scope
+
+Applies to **event** discovery only — the axis this decision replaces. Meeting-point and profile discovery are unaffected. Product framing and the four costs restated for a domain reader: concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]. Package surface and guarantees: [[contract_indexing-layer]].

.project/concepts/data-layer/indexing-layer/contract_indexing-layer.md

@@ -0,0 +1,158 @@
+---
+type: contract
+summary: The API @ng-helpers/indexing exposes to an application — creating an index, depositing references into it, curating it, and reading it back
+pulled_from: https://gitea.reconnexion.apps.gueraud.net/Sylvain/ng-helpers.git/.project/concepts/indexing/indexing-layer/contract_indexing-layer.md
+pulled_version: 2ce21131575f66af09f28ee109ad712aa41173ae
+pulled_at: 2026-08-17
+---
+
+# contract_indexing-layer — `@ng-helpers/indexing`
+
+## Scope
+
+This package builds an **index** on top of NextGraph: an ordinary public document that holds one entry per indexed object, keyed by that object's NURI and carrying its value for a single declared field.
+
+It covers creating an index, handing an index a reference to an object (open to anyone), the owner resolving those references and adding what it can, and reading the entries back in order.
+
+It does not cover NextGraph itself — documents, identity, sharing, inboxes, transport — all of which reach it through a port you supply. It does not cover search, filtering, pagination, or querying by anything but the index's own field. It **never removes anything**, from anywhere, and that is a property of the engagement rather than a missing feature.
+
+### Deployment requirements
+
+An application using this package must:
+
+- have a NextGraph session already open under the identity it wants to act as, and build the port from it — `polyfillPort({ sessionId })`, where `sessionId` is what `@ng-eventually/polyfill`'s own `init(…)` hands its callback;
+- reach a broker, since every operation here is a document read, a document write, or an inbox deposit;
+- **supply `@ng-eventually/polyfill` itself.** This package declares it a *peer*, not a dependency: the application names it among its own dependencies and decides which copy it gets. That copy must be the very one the application's own code calls, because everything this package does passes through it — and that package requires exactly one instance of itself in an application, for reasons its own contract states.
+- **hardcode the index's NURI in its own source.** Nothing marks a document as an index; the reference is what makes it one, and it is the only way anyone reaches it.
+
+One handle is one identity: the port carries a session and no call takes an identifier. Two users mean two handles.
+
+**Obtaining it.** This package is not published to npm, nor to any other package host, and it is not distributed as built output: its published entry point is TypeScript source, so whatever builds the application is what compiles it, and a toolchain that accepts only JavaScript cannot consume it as it stands. `@ng-eventually/polyfill` is distributed the same way. By which channel the source reaches a given application is agreed with that application rather than fixed here; what this contract fixes is the version you pin and what you must provide alongside it.
+
+## Surface
+
+Full typed shape: the package's `types` entry, `@ng-helpers/indexing`. The load-bearing signatures:
+
+```ts
+// ── wiring: one handle, one identity ─────────────────────────────────────────
+export function polyfillPort(options: PolyfillPortOptions): NextGraphPort;
+export interface PolyfillPortOptions { readonly sessionId: string | number }
+export function indexing(port: NextGraphPort): Indexing;
+
+// ── addressing (re-exported so you import them from here) ────────────────────
+export type Nuri = `did:ng:${string}`;
+export type NuriLike = Nuri | string;
+export type { PrincipalId, UnionSubject, NextGraphPort, IncomingDeposit, ObjectResolution };
+
+// ── everything this package does ─────────────────────────────────────────────
+export interface Indexing {
+  /** Creates an index in THIS identity's public store and opens its inbox. Any user may.
+   *  `field` is the predicate an indexed object must carry, declared once and for good;
+   *  an empty or blank one throws. Returns the NURI to hardcode. */
+  createIndex(field: string): Promise<Nuri>;
+  /** Deposits a bare reference into the index's inbox. Open to ANYONE. Nothing lands in
+   *  the index until its owner curates. Throws if the index has no inbox. */
+  refer(index: NuriLike, object: NuriLike): Promise<void>;
+  /** OWNER only — resolves the references received and adds what it can. */
+  curate(index: NuriLike): Promise<CurationReport>;
+  /** The entries, ordered by value. Sugar over `readUnion([index])`. */
+  read(index: NuriLike): Promise<IndexEntry[]>;
+}
+
+// ── what an index holds ──────────────────────────────────────────────────────
+export interface IndexEntry { readonly object: Nuri; readonly value: string }
+export interface IndexDescriptor { readonly field: string }
+
+// ── what curating reports ────────────────────────────────────────────────────
+export type CurationOutcome =
+  | { readonly result: "indexed"; readonly object: Nuri; readonly value: string }
+  | { readonly result: "unchanged"; readonly object: Nuri }
+  | { readonly result: "skipped"; readonly object: Nuri; readonly reason: SkipReason }
+  | { readonly result: "unresolved"; readonly object: Nuri; readonly reason: string }
+  | { readonly result: "foreign"; readonly reason: string };
+export type SkipReason = "no-field" | "several-values" | "self-reference";
+export interface CurationReport {
+  readonly index: Nuri;
+  readonly outcomes: readonly CurationOutcome[];   // one per deposit, in deposit order
+}
+
+// ── what travels from a depositor to a curator ───────────────────────────────
+export type IndexDeposit = Nuri;                   // the reference IS the whole payload
+export function decodeReference(payload: unknown): Nuri | null;   // untrusted input
+
+// ── the IRIs, for a reader going straight to `readUnion` ─────────────────────
+export const INDEX_FIELD: string;   // on the index's own subject: the field it indexes by
+export const ENTRY_VALUE: string;   // on an entry: that object's value for the field
+```
+
+## Guarantees
+
+**An index is an ordinary public document, and nothing marks it as one.** It lives in its creator's public store, so any reader opens it from the reference alone; its creator owns it, and any user may create one.
+
+**The field is declared once, inside the document, and cannot be changed.** `createIndex` refuses an empty or blank field at the door, because nothing here deletes and an index created on a useless field is useless for good. Declaring it in the document rather than in an application's source is what stops two applications curating the same index on two different fields.
+
+**`createIndex` opens the index's inbox itself.** Only the owner can, and creation is the one moment the owner is present, so it is not left to a later call to remember.
+
+**Depositing is open to anyone; writing is the owner's alone.** `refer` is a deposit into the index document's inbox — not a write — so a stranger can contribute to an index they do not own. `curate` reads that inbox and writes the document, and both are refused to anyone but the owner. The deposit is a **bare reference**: it carries no operation, no index reference (the inbox address already identifies the index), and no copy of the indexed value. What the object itself says is what goes in.
+
+**An index ONLY EVER GROWS.** There is no call that removes an entry, for anyone including the owner, and none is planned. This package cannot express a removal at all. The only answer to "this entry must go" is a fresh index.
+
+**Curation is convergent and order-independent.** Deposits are never consumed, so every run sees every deposit again; re-applying one re-resolves the reference and lands on the same result. An already-indexed object is skipped outright as `unchanged`. Nothing depends on the order references arrived in.
+
+**A reference that does not resolve costs nothing and is reported.** It comes back as `unresolved`, nothing is written for it, and nothing already in the index is touched — a later deposit adds it. Every unresolved reference appears in `CurationReport.outcomes`: harmless is not the same as invisible.
+
+**Reading is per-entry tolerant.** `read` returns entries ordered by value, ties broken on the object NURI, so two readers of the same index always see the same order. Values are compared **as strings** — an index whose field holds ISO-8601 dates therefore comes out in chronological order. A subject that is not a NURI is skipped, never thrown on, and only own properties are read: one stray triple cannot make every real entry unreadable.
+
+**An entry carrying several values keeps the smallest, deterministically** — which two curation runs racing each other can produce. The entry stays visible and every reader agrees on it.
+
+**`read` refuses a document that declares no field at all**, rather than answering "an empty index". An unreadable document and an empty one arrive as the same empty result, so an empty answer would be a failure wearing the shape of a fact. Retry before concluding the document is malformed.
+
+**An index declaring SEVERAL fields refuses to CURATE, loudly and permanently — and stays readable.** Picking one would leave a single list ordered by two different properties, because entries already written are never re-read. Existing entries stay visible and correct; nothing new is added. The refusal cannot be undone, and it says so instead of suggesting a retry.
+
+**Reading needs nothing from this package.** An application that knows the NURI can call the polyfill's `readUnion([index])` and get the entries as subjects — one per indexed object, keyed by its NURI — plus the index's own subject declaring its field, which `read` drops. `INDEX_FIELD` and `ENTRY_VALUE` are published for exactly that reader.
+
+**Every inbox payload is untrusted.** Anyone may deposit anything; `decodeReference` returns `null` for everything that is not a reference, and such a payload is reported as `foreign` rather than crashing curation.
+
+## Non-guarantees
+
+**No removal, at any level, ever.** Not an oversight and not "not yet": it was deliberately never built. Do not design around a future delete.
+
+**No refresh.** An already-indexed object is never re-read, so an object whose field value changes later keeps its original value in the index, indefinitely.
+
+**No private data.** Indexing is limited to objects the curator can open itself. An object the index's owner cannot read is simply `unresolved`.
+
+**`unresolved` does not tell you why.** Gone, unreadable, and "the read failed" arrive identically and are deliberately not distinguished. Never read it as "the object does not exist".
+
+**The narrow behaviours are open questions, not promises.** An object carrying nothing for the field is `skipped: "no-field"`; one carrying several values is `skipped: "several-values"`; a raced entry keeps the smallest value. Each is implemented in its narrowest form and reported rather than generalised, and each may change.
+
+**No stable error text.** What a throw or an `unresolved` reason reads is for a human reading a report. Do not parse it or branch on it.
+
+**No timing and no delivery promise.** A deposit is not in the index until the owner curates, and nothing here schedules curation. There is no notification, no queue depth, and no ordering between a deposit and a read.
+
+**The report grows with the inbox.** Since deposits are never retired, `CurationReport.outcomes` has one entry per deposit ever made, not per change.
+
+**No cross-broker reach.** A NURI resolves for users of the same broker.
+
+**No depositor authentication or rate limit.** Anyone may deposit any number of payloads into any index's inbox.
+
+## Change policy
+
+**Semver, and majors are the normal case.** This layer sits on a polyfill that is itself converging on a NextGraph that does not ship yet, and several of its own behaviours are declared above as open questions. Settling one of them narrows this surface — the major number will move often, and that frequency is the honest signal about this package, not an apology. Refusing to version would not slow the churn down; it would only take away the one tool you have for managing it. Pin a version, upgrade deliberately, and re-pull this contract each time.
+
+What each level means here, in this package's own terms:
+
+- **major** — an exported symbol is removed or renamed, **or** an existing call narrows: it now throws where it returned, or reports a state you did not have to handle before. Settling an open question counts, and so does adding a `CurationOutcome` variant or a `SkipReason` — an exhaustive `switch` in your code stops being exhaustive. A signature change a caller must react to counts; one that only accepts more than before does not.
+- **minor** — a symbol is added and nothing existing moves: a new read helper, a new optional option.
+- **patch** — a fix that changes neither the exported surface nor anything above under `## Guarantees`, including the text of a throw, which is explicitly disclaimed above.
+
+**A tag says where it comes from.** A release cut on `main` carries a **full version** (`1.0.0`), and the three rules above govern what changes between two full versions. Work still on a branch carries a **pre-release** of the version it is heading for (`1.0.0-dev.3`), which sorts *below* that version by construction — so you can pin what exists today while the tag itself tells you the surface has not been released and may still move before it is. Between two pre-releases of the same version nothing is promised: re-pull and read this leaf again. When the branch lands, the full version appears alongside; the pre-release keeps resolving, so no reference you pinned is ever withdrawn from under you.
+
+**The tag is bare — `v1.0.1` — because this repository publishes exactly one engagement**, so there is nothing for a prefix to disambiguate. Should a second one ever ship here, tags take the package name from that point on (`indexing/v…`), because a bare tag stops saying which surface it froze the day two versions move independently. Bare tags already laid stay valid as history.
+
+`1.0.0` was a baseline, not a claim of maturity: it was the number that made your pin mean something. Nothing was released before it. **It could not be installed, however**, and `1.0.1` supersedes it. `1.0.0` declared `@ng-eventually/polyfill` as a dependency resolved through a path that existed only in one working copy, so every attempt to install it from anywhere else failed outright — not on some operations but at the install itself, which is why no application ever ran it. `1.0.1` declares that package a peer, which the application supplies. Nothing exported moved, which is what makes this a patch and not a major: the only thing that changed for a caller is a requirement it could never have satisfied before, so there is no working arrangement for it to break.
+
+**`1.0.0` is superseded, not withdrawn.** The tag stays where it is and keeps resolving, because no pinned reference is ever taken away from under you — this contract's policy holds even for a version that never worked. Nothing forces an upgrade; it is simply that an installation pinned there cannot have succeeded, so there is nothing to migrate.
+
+This engagement is cut on `main`, so `1.0.1` is what you pin, and your `usage_` leaf anchors `against:` on that exact string — `against: @ng-helpers/indexing@1.0.1`. Had you pinned a pre-release, `against:` would carry that string, pre-release suffix included.
+
+There is no changelog file and no deprecation window: **the sections above are the release note.** A removal or a narrowing lands in `## Surface` and `## Guarantees` in the same version that ships it. Diff this leaf between two pulls — `## Guarantees` and `## Non-guarantees` before `## Surface`, because that is where a narrowing shows up first.

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

@@ -0,0 +1,95 @@
+---
+type: knowledge
+summary: Internal pitfalls of FestipodDataContext — the signed-in identity and the profile are two unrelated things, "my profile" is the profile document I own, mutations reject instead of succeeding silently, participantCount is derived by the event's owner, and local mode is a no-op
+last_checked: 2026-08-17
+---
+
+# Internals & pitfalls of `FestipodDataContext`
+
+Non-obvious behaviours of `src/shared/context/FestipodDataContext.tsx` to know about before touching the data context.
+
+## Identity and profile are TWO things — never join them
+
+**The identity** is what `ensureIdentity()` returns: an opaque value, published to the tree by `src/shared/utils/currentPrincipal.ts` (a module store, not a context — the component that awaits sits *inside* the data provider, so a context it published would be invisible to its own consumer). It is **for display and log attribution only**. It is never parsed, never rendered as a name, never written into an entity, and **never passed to a data-layer call** — placement is named by scope alone, so handing it back would recreate the parameter the surface deliberately removed ([[contract_polyfill-surface]]).
+
+**The profile** — pseudo, name, initials — is **Festipod's own object**, in a document the app creates and writes. `currentUserId` is that document's NURI, the same value as `currentUser?.id`, and the only value a mutation may write into a `Participation`'s `fp:user`.
+
+**There is no join between the two, and there must not be one.** The identity says nothing about the profile. Never compare the principal to an entity id, and never match it against a profile field to decide who the current user is.
+
+## "My profile" is the profile document I OWN
+
+`listMyEntityDocs('protected')` answers *which documents are mine*, and the UserProfile among them is mine. **No field of any profile takes part**: no username comparison, no normalization, no positional pick.
+
+A failed listing is **UNKNOWN, never "none"** — the set stays unresolved, no profile is chosen and none is created, and the failure is retried then said loudly. Reading a rejection as "I own nothing" would create a second profile for someone who already has one.
+
+Four outcomes, and *somebody else's profile* is not one of them:
+
+| Owned profiles | Answer |
+|---|---|
+| listing unresolved | UNKNOWN — nothing resolved, nothing created |
+| none | I have no profile yet → one is created (below) |
+| exactly one | that is me |
+| several, none created by this session | the **first by document reference** — stable across reloads, openly arbitrary, warned about once |
+
+The last row is a reloaded wallet carrying a fixture seed. The pick carries no meaning, so it is logged as demo data rather than presented as you; **every candidate is a document I own**, which is what separates it from the impersonation that was removed — that one reached for a profile by *name* and could land on a stranger's document. Delete the branch the day a profile is really created and known.
+
+> **Two impersonation fallbacks are gone**, including one in `updateProfile` that would have written your pseudo into a stranger's document. Having no profile now resolves to *having no profile*. Do not reintroduce a "pick something plausible" fallback anywhere on this path.
+
+## A profile is created at sign-in when there is none
+
+Gated on **both** the protected read having settled (`isSuccess` — synced-and-empty, not still-syncing) **and** the owned-document set being known, because "I have no profile" is only true when both have answered. Single-shot per session; on failure the guard is released so a later change retries.
+
+The UserProfile shape makes `name`, `initials` and `username` **mandatory**, so the profile cannot be written empty. The three fields carry **placeholders that read on screen as "not filled in yet"** — never a plausible human name, never a handle, and **never anything derived from the opaque identity**. The user replaces them through `updateProfile`.
+
+## Nothing succeeds in silence
+
+Mutations on the create/participate path **reject** rather than returning quietly, and the screen's confirmation **follows** the write:
+
+- `joinEvent` refuses when no profile of mine is resolved: a `Participation` needs `fp:user`, and one written without it is dropped on read — a sign-up that wrote nothing, threw nothing, and let the screen congratulate the user. It now throws, naming the cause. `leaveEvent` likewise, because withdrawal must be authoritative ([[caveat_participation-deletion]]).
+- Idempotence is checked **authoritatively against the broker**, not against the reactive set, which can lag a just-written participation. A **failed** count is UNKNOWN and is deliberately *not* swallowed — reading it as zero is exactly how a duplicate gets written.
+- **The deposit IS the delivery.** A host-facing notification is no longer minted at join time. It used to be written into the *joiner's* own protected scope with `recipient` set to the event — a document the host can never read — and pushed into the joiner's own list, so the joiner saw a "new participant" notice addressed to someone else. Both are gone: `inbox.postToDocument(doc, …)` carries the news, and the owner builds the notification from the deposits it reads on its own event's inbox.
+- The creator signs up through the **common path** — no owner branch, no special case, the same deposit and the same derived count.
+
+## The legacy participation id space — resolved on READ only
+
+A `Participation` written **today** carries the profile document's NURI in `fp:user`, so the direct join `u.id === userId` matches. Participations written under the **earlier** scheme carry `urn:festipod:user:<normalized-handle>`, which matches nothing directly.
+
+**`resolveParticipantUser`** is the single join point and tries, in order: (1) the direct id match — today's writes, and the demo seed's bare `user-1` space; (2) failing that, strip `USER_PRINCIPAL_PREFIX` and compare the remainder to `normalizeIdentifier(profile.username)`. Never join by direct comparison at a call site: getting it wrong renders every participant as « participant inconnu », which shipped once. `USER_PRINCIPAL_PREFIX` is **read-side only** — nothing mints it any more; it is not a shape to write against. The inbox deposit `uid` (`mint…`) is a third space that takes **no** part: it identifies a deposit for the counter, never a user.
+
+> **Horizon.** The target model drops the plaintext `userId` and resolves identity by reading the profile — [[brief_2026-07-20_attendance-set-model]], gated. The id-space fix is noted there as still valid: do not undo it in anticipation.
+
+## Reads = `watchShape`, writes = an optimistic overlay
+
+Reads go through `useShapeQuery(shape, scope)` — three scoped reads (events/public, profiles/protected, participations/protected) mapped by `shapeAdapters.ts`; `ready` combines their `isSuccess` flags. The app resolves, lists and re-queries nothing ([[rule_document-per-entity]] §Reads).
+
+**Immediate visibility of a mutation is a pure optimistic overlay**: `createEvent`/`joinEvent`/`leaveEvent`/profile creation feed `pendingAdd*` / `pendingRemoveIds`; the exposed state is merge(reactive, adds) minus removes, deduped by id. Reconciliation is automatic on push — never a poll ([[rule_no-broker-polling]]).
+
+## `participantCount` — derived, and written only by the event's owner
+
+The counter is **not** incremented by whoever joins: only a document's owner writes to it. The flow is deposit → owner-materialization.
+
+- A participant writes their **own** participation document (protected), then **deposits** a marker into the event's inbox (`depositRegistration` / `depositLeave`, `src/shared/data/registration.ts`).
+- The event **owner's** session watches the inboxes of the events it owns (`inbox.watch`, no polling) and **recomputes** `participantCount` on its own event document. It is the counter's only writer, and it reads through `inbox.readSynced` — the synced view — not `inbox.read`.
+- **One inbox per document, whatever the concurrency.** `openDocumentInbox` (`storeRegistry.ts`) resolves at most once per document per session (`resolveOncePerKey`, `src/shared/utils/`, unit-tested): several callers racing for the same event's inbox — create, materializer, watch wiring, watch callback — all await the same in-flight resolution instead of minting a second address. A rejection is not memoized (unknown, not absent), so a later call genuinely retries.
+- **One materialize cycle at a time.** The owner's connection trigger and its inbox-push trigger both call into a `createSerialTask` (`src/shared/utils/`, `serialTask.ts`, unit-tested): a cycle in flight absorbs every request that arrives during it into a single follow-up, so two read-derive-write passes never race on the same document. Each cycle carries a monotonic sequence number, and a write only lands if no fresher cycle has already written — a stale cycle can no longer clobber a newer value.
+- **Derived, not incremented**: `materializeAttendance` computes the set of distinct active sign-ups (deposits deduped by `uid`, minus those cancelled). `participantCount = |active set|`. There is **no host baseline** — an event has no host, the declarer is not required to attend, so the counter starts at **0** on creation and moves only on real sign-ups. Being a pure function of the inbox, a replay is *designed* to converge: no double count, no phantom decrement. The write is guarded so it only fires on a genuine change, and lands in **one** SPARQL statement (`updateEntityField`: `DELETE … INSERT … WHERE`), closing a window where a reader could see the field briefly absent and read zero.
+- **Owner offline = eventual.** While the owner is disconnected the count does not move for anyone else; nothing is lost. The materializer fires directly on connection, not only on a push, and it never locks in a premature 0.
+- The counter is an **aggregate**, not the list of named participants — `getEventParticipants` is governed by what the protected scope hands back.
+
+> A live run still shows the count **one connection later** than this design implies — not a race, not data loss, a layer that does not notify you of your own actions: [[caveat_participant-count-one-connection-lag]].
+
+Which event a deposit belongs to is matched on the **canonical id-form** — see [[knowledge_write-rights-are-ownership]] §Matching, which governs every event-id comparison in this file.
+
+## Logging convention — identity-first, and the counter before→after
+
+Every DATA log goes through **`logPrefix`**: `[<currentUserId or principal>][app][data]`. A run often drives several sessions at once and their lines are read side by side, so a line must say *whose* it is. Adding a DATA log means reusing `logPrefix`, not a bare `console.log`.
+
+Two measurement points are laid down **as a pair**: the owner's materializer logs `participantCount` before → after its write, and the display read logs the value as exposed to the render. Together they separate a **data** problem (never incremented) from a **display** problem (incremented but not re-read). Do not remove one without the other — alone they diagnose nothing.
+
+## There is no identity switch, and nothing to reset
+
+The app settles its identity once, before anything renders, and offers no way to change it (`app-security` → [[decision_2026-08-10_the-barrier-names-no-identity]]). One page hosts exactly one identity for its whole life, so there is no identity-change reset: no `useEffect([identifier])`, no cap reset, no registry-cache reset. Do not reintroduce a reset for a transition that cannot happen. Cross-identity **isolation** is still a real requirement, but proving it needs two genuinely separate browser contexts (`bdd-testing` → [[rule_tests-validate-festipod-not-the-sdk]]).
+
+## Mutations are no-ops in local mode
+
+In local/demo mode (`useLocalData`), `createEvent`/`joinEvent`/`leaveEvent`/`updateEvent` are **no-ops** (a log, no state change) — yet the screens still show a success toast. Misleading UX, unchanged. See [[knowledge_data-modes]].

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

@@ -0,0 +1,30 @@
+---
+type: knowledge
+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()
+---
+
+# Data modes & contexts
+
+The app has **two modes**, both consumed through the `useFestipodData()` hook:
+
+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`)
+
+- 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`)
+
+- 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)
+
+> Mutations are **genuinely persisted** in connected mode: `joinEvent` writes a Participation into its own document and **deposits** into the event's inbox (the deposit is the delivery — no notification is written for the host), `leaveEvent` deletes authoritatively (see [[caveat_participation-deletion]]). Both **reject** rather than returning quietly when they cannot write, and the screen's confirmation follows the write. In local/demo mode they are **no-ops that still show a success toast** — see [[knowledge_context-internals]].
+>
+> **Per-call honesty is not flow-level honesty.** Every one of those calls tells the truth about itself; the sign-up flow driven end to end still shows a bystander a stale `participantCount` for one connection longer than the write itself — not a lie, a layer that neither pushes you your own deposit nor re-reads your own write in the same session, see [[caveat_participant-count-one-connection-lag]]. Do not read the paragraph above as "the count updates instantly".

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

@@ -0,0 +1,34 @@
+---
+type: knowledge
+summary: The Fp* app types and their SHEX shapes — Event (no host), UserProfile, Participation, MeetingPoint and Notification are persisted, Friendship stays local-only; the generated ORM names carry NO Fp prefix and are aliased at the import sites
+last_checked: 2026-08-17
+---
+
+# Data entities
+
+`src/shared/data/types.ts` holds the app's own types; `src/shared/shapes/shex/festipodShapes.shex` holds what is actually persisted.
+
+| Type | Persistence | Key fields |
+|---|---|---|
+| `FpEventData` | SDK (Event shape) | title, date, startDate, endDate, startTime, endTime, location, distance, participantCount, coverImage |
+| `FpUserData` | SDK (UserProfile shape) | name, initials, username, role, isPublic |
+| `FpParticipationData` | SDK (Participation shape) | event + user + isConfirmed |
+| `FpMeetingPointData` | SDK (MeetingPoint shape) | event, host, title, place, time |
+| `FpNotificationData` | SDK (Notification shape) | recipient, type, ref, payload, timestamp, isRead |
+| `FpFriendshipData` | **local-only** | userId + friendId |
+
+**An event has no host.** `hostName`/`hostInitials` are gone from the type and the shape alike — the event is only the anchor, and the host lives one level down on the meeting point (`FpMeetingPointData.hostId`, SHEX `fp:MeetingPoint.host`). See concept `functional-domain`, [[knowledge_actors-and-concepts]].
+
+**A Notification is no longer created when someone signs up.** The joiner deposits into the event's inbox and the **owner** builds the notification from what it reads there — see [[knowledge_context-internals]] §Nothing succeeds in silence.
+
+`Friendship` has **no** SHEX shape and no persistence — it stays app-TS-only ([[knowledge_nextgraph-stack]]).
+
+## The generated ORM names carry no `Fp` prefix
+
+The generator emits `Event`, `UserProfile`, `Participation`, `MeetingPoint`, `Notification` (and `EventShapeType`, `UserProfileShapeType`, …) — **without** the `Fp` prefix earlier bindings had.
+
+**It cannot be restored at the generator.** The emitted name derives from the shape IRI, and those IRIs are the **persisted RDF classes**: renaming them to regain a prefix would rename the data. So the app **aliases at its import sites** (`… as FpEvent`, `… as FpEventShapeType`) — three of them, in the data context and the two test harnesses. That keeps the downstream names unchanged and, just as importantly, stops the DOM's own `Event` and `Notification` from being shadowed.
+
+Alias at the import; never rename in the generated files, which `bun run build:orm` overwrites ([[knowledge_nextgraph-stack]]).
+
+> `themes` is on `FpEventData` and the seed but **not** on the Event shape: a repeated value needing a cardinality decision before it can be one more optional string. Nothing reads it back today, in any mode, so its absence in connected mode is not yet observable — see [[knowledge_nextgraph-stack]] for the shape's actual field list.

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

@@ -0,0 +1,32 @@
+---
+type: knowledge
+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
+---
+
+# Data stack (SHEX shapes over the `@ng-eventually/polyfill` surface)
+
+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]].
+
+## SDK boundary (the golden rule)
+
+- 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**.
+
+## ORM & SHEX shapes
+
+The reactive ORM (`useShape`) is built on **SHEX shapes**: `src/shared/shapes/shex/festipodShapes.shex` defines:
+
+- **Event** — title, description, date, startDate, endDate, startTime, endTime, location, distance, participantCount, coverImage, plus an **inbox** field. **No host**: an event is only the anchor ([[knowledge_entities]]). `startDate`/`endDate`/`startTime`/`endTime` are the ISO/HH:MM values the form collects, carried end to end alongside `date` (the display label); they are all optional, so an event written before these fields existed reads as one without them rather than one with blank strings. `themes` is **not** on the shape: a repeated value needing a cardinality decision before it can be one more optional string, and nothing reads it back today. `inbox` is a **vestige** and must stay unused: 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]]).
+- **UserProfile** — name, initials, username, role, isPublic. The first three are **mandatory**, which is why a new profile is written with placeholders rather than empty.
+- **Participation** — links an event and a user, confirmation status
+- **MeetingPoint** — a meeting point (event, host, title, place, time)
+- **Notification** — recipient, type, ref, payload, timestamp, isRead
+
+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.
+
+> **Regenerating an unchanged `.shex` reproduces the committed bindings byte-for-byte** — verified by running the generator twice: once before touching the shape, to confirm a no-op diff, then again after the shape edit, so what shows up is the shape change alone. Run it that way on every `.shex` change — it is what keeps an ORM diff reviewable, since nothing separates your edit from a generator side effect if you only ever run it once. And the emitted names carry **no `Fp` prefix**; the app aliases at its import sites instead, because the name derives from the shape IRI and those IRIs are the persisted RDF classes ([[knowledge_entities]]). Never hand-edit the generated files.
+
+> **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

@@ -0,0 +1,26 @@
+---
+type: knowledge
+summary: seedData.ts holds deterministic fixtures (14 users with CURRENT_USER_ID = 'user-1', 5 events) used by demo mode and the @ui tests; no fixture reaches a CONNECTED wallet by any route any more — bootstrapWallet is the single enforcement point of that master switch
+last_checked: 2026-08-16
+---
+
+# Seed data
+
+`src/shared/data/seedData.ts` holds **deterministic** fixtures: 14 users (`CURRENT_USER_ID = 'user-1'`, Marie Dupont), 5 events, participations, meeting points and friendships.
+
+## Where they are still used
+
+- **Demo / disconnected mode** — `LocalDataProvider` reads them straight into React state ([[knowledge_data-modes]]).
+- **The `@ui` rendering tests** — they render screens against this predictable data (`Marie Dupont`/`@mariedupont` is the current user, `Jean Durand`/`@jeandurand` exists…). Concept `bdd-testing`.
+
+Neither path writes to a wallet, which is why both are untouched by the switch below.
+
+## No fixture reaches a CONNECTED wallet, by any route
+
+A **master switch** — `fixtureSeedEnabled()` in `src/shared/utils/autoSeed.ts` — is **off**, a product decision: no fixture is written into a connected wallet at all, neither by the opt-in automatic seed nor by an explicit "load test data" action.
+
+**`bootstrapWallet` (`src/shared/utils/ngBootstrap.ts`) is the single enforcement point.** Every route into a wallet funnels through that one function, so the switch cannot be walked around by a screen, a bridge or a test harness; a caller simply gets the ordinary "nothing was seeded" answer, which is exactly true. Call sites consult the switch too, but only so they neither log nor await work that will not happen — the enforcement is not theirs. A unit test fails if a document is created after all.
+
+**Off, not deleted.** The fixtures and the seeding code stay, because the two paths above need them and neither writes to a wallet. If the switch is ever turned back on, what follows still applies: the seed is **linear in the number of documents** (one document per entity, each a serial round trip), so the connected seed writes only what is needed — all events, a few profiles, and no participations, which the sign-up scenarios create live. Events are the only entities whose inbox is opened at seed time, because events are what people deposit into.
+
+> **Consequence, live now**: the `@data` suite has lost its fixtures — concept `bdd-testing`, [[caveat_data-suite-has-no-fixtures]].

.project/concepts/data-layer/knowledge_write-rights-are-ownership.md

@@ -0,0 +1,35 @@
+---
+type: knowledge
+summary: getEventOwnership answers mine / not-mine / unknown from listMyEntityDocs('public') — owning a document IS being able to write it, the ruling is rebuilt on every listing rather than accumulated, and UNKNOWN is a real third answer callers must handle
+last_checked: 2026-08-16
+---
+
+# Write rights are ownership, read from the owned list
+
+The app never asks whether it may write a document; it asks whether it **owns** one, because [[contract_polyfill-surface]] makes those the same fact. Only an owner writes, a read key never grants a write, and no call adds a writer — so `listMyEntityDocs('public')` is the whole answer, and no probe call will be added (`app-security` → [[decision_2026-08-16_write-rights-are-the-owned-list]]).
+
+## The answer is three-state
+
+`getEventOwnership(eventId)` (`FestipodDataContext`) returns `'mine' | 'not-mine' | 'unknown'`:
+
+- **`mine`** — the event is in the owned set, either because a listing returned it or because this session created it and claimed it directly. Checked **first**, so a fresh creation is authoritative before any listing has answered and never loses to a stale miss.
+- **`not-mine`** — a listing has *resolved* and did not return this event, so it was genuinely looked past.
+- **`unknown`** — everything else: no listing has landed, the listing failed, or the event arrived after the last one. A rejection means UNKNOWN, never "this session owns nothing"; reading it as `not-mine` is how an owner is silently denied their own event.
+
+**Callers must treat `unknown` as its own case.** It is not a polite `not-mine`, and it is not a boolean waiting to settle.
+
+## The ruling is REBUILT, never accumulated
+
+Every listing **re-adjudicates every visible event**: the ruled-out set is recomputed from scratch, so a later listing can overturn an earlier one. An earlier version latched the verdict into a boolean, which denied an owner their own event forever once a single listing had missed it. Do not reintroduce accumulation — add to the owned set, but rebuild the ruled-out set.
+
+Re-listing is driven by **arrivals, not by time**: while some visible event is neither owned nor ruled out, one more listing is taken; the set then empties and the effect falls silent. That is a push-driven retry, not a poll ([[rule_no-broker-polling]] in `bdd-testing`).
+
+## Known residual — accepted, do not paper over
+
+"Not mine" is inferred from **absence**, and the reactive read and the listing are **separate mechanisms**. An event can therefore be on screen a moment before a listing can see it, and it is ruled out for exactly that window; it is re-examined only if some other unclassified event later triggers a listing. Closing the window needs a timer (forbidden) or a capability probe (ruled out). It is left visible and stated on purpose.
+
+## Matching is on the canonical id-form
+
+An event's `@id` is its document NURI, and the same event can be reached under two overlays (`:v:<overlay>`). Every ownership comparison — the owned set, the ruled-out set, the lookup — runs on the **canonical** form (`canonicalEventId`, `src/shared/data/registration.ts`): the base repo id with any overlay suffix stripped. **Matching only.** A stripped id is never a write target nor an anchor; the counter is always written to the real owned NURI.
+
+> Two screen-side consumers, one answer: the control that **offers** the write and the route that **performs** it ask the same question and treat `unknown` the same way — `app-architecture` → [[knowledge_screen-pattern]]. Why the answer is this and will stay this: `app-security` → [[decision_2026-08-16_write-rights-are-the-owned-list]].

.project/concepts/data-layer/polyfill-surface/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: a33fb8a21464194227668fd703edd35f685bb3c1
+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/polyfill-surface/usage_festipod.md

@@ -0,0 +1,84 @@
+---
+type: usage
+summary: What the Festipod application actually calls in @ng-eventually/polyfill, the conditions it needs beyond the call list, and the five frictions it has measured against the engagement
+against: a33fb8a21464194227668fd703edd35f685bb3c1
+---
+
+# usage_festipod — Festipod on `@ng-eventually/polyfill`
+
+Festipod is a mobile-first web application: users create **meeting points** grafted onto public events, and sign up to them. Its entire persistence goes through this package — there is no second data path, no server of its own, and no direct use of the SDK underneath. Two kinds of caller live in this repo and both are declared here: the **application** (screens, data context, write helpers) and the **test harness** (a browser-side bridge the BDD suites drive). The harness is a caller like any other; what it calls is part of what we consume.
+
+The list below is what we actually call, derived from the call sites, not from what the engagement offers. Anything not listed is offered-but-unused and free to evolve without us.
+
+## Consumed surface
+
+### Bootstrap and session
+
+- `configure(c)` — **one call site**, once per page load, with every published field: `ng`, `useShape`, `init`, `initNg`, `debugAccessLog`, and `sharedWallet: { fileUrl, password, importUrl }`. All three `sharedWallet` fields are supplied, `importUrl` included.
+- `init(callback, true, [])` — this package's `init`, not the one handed to `configure`. We read `event.session` off the callback and keep it for the whole page.
+- From that session object we read **two** members: `session_id`, relayed unconverted (`string | number`) into every `docs` call, and **`session.user`**, a string user id passed to `ng.session_stop`. `session.user` reaches us only through the session's open index signature — the engagement names `session_id` and nothing else, so this is a **declared dependency on an unpublished member**: if the session stops carrying `user`, our sign-out breaks.
+- `initNg(ng, session)` — called from inside that same callback.
+- `ng` — exactly one member: `ng.session_stop(userId)`. Nothing else of the 88 is touched.
+- `ensureIdentity()` — awaited before the interface renders (auth gate and app entry), and again by the data context, the principal resolver, and the harness. Its return is treated as opaque: never parsed, split, or rendered.
+
+### Placement — `storeRegistry`
+
+- `createEntityDoc(scope)` — one document per entity, on create.
+- `listMyEntityDocs(scope)` — the owned-document listing; it is also **how we answer "may I write this?"**, since no call answers that question.
+- `resolveScopeGraph(scope)` — the anchor for every SPARQL call.
+- `openDocumentInbox(doc)` — through **one app-side wrapper** that collapses concurrent calls for the same document into a single resolution, keyed on the document's canonical form, for the session's lifetime. The raw entry is deliberately not re-exported, so no call site can reach it directly. That wrapper exists only because of friction 1.
+- `resolveWriteGraph` — **imported and re-exported, never called.** Declared because the import is real: removing the symbol breaks our build even though no behaviour depends on it.
+
+### Reading
+
+- `watchShape<T>(shapeType, scope)` — **two positional arguments plus a type parameter** (see friction 5). Wrapped once, in the single React binding that couples the app to the reactive read; every screen reads through that binding. `ShapeObservable`'s `getSnapshot`, `subscribe` and the `ShapeQuery` state it yields are all consumed.
+- `useShape(shapeType, scope)` — the read-filtered view, in the write path and in the `@data` step definitions.
+- `UnionSubject` — its `subject`, `graph` and `props` are read and adapted into the app's own entity types.
+- **Not consumed:** `readUnion`, `subscribeDoc`, `subscribeDocs`.
+
+### Low-level document / SPARQL primitives
+
+- `docs.sparqlUpdate(sessionId, query, anchor, label)` — every write the app makes, always anchored, always labelled.
+- `docs.sparqlQuery(sessionId, query, base, anchor, label)` — authoritative re-reads on the write path (what a reactive read must not be asked to settle) and in the harness.
+- **Not consumed:** `docs.docCreate` — documents are created through `storeRegistry.createEntityDoc`.
+
+### Inbox
+
+- `inbox.share(doc, toUser)` — granting a connection the read of a protected document.
+- `inbox.postToDocument(doc, { from, payload, ts })` — reaching a document's owner. We pass `from: null` **deliberately** (a sign-up is unnamed unless the host is already a connection), a structured `payload`, and our own `ts`.
+- `inbox.read(targetInbox)` and `inbox.readSynced(targetInbox)` — the owner materialising its deposits; `readSynced` is what the count path uses, because a read before the sync barrier returns a premature empty.
+- `inbox.watch(targetInbox, onDeposits)` — subscribed by the owner; the returned unsubscribe is called on teardown.
+- `inbox.readForDocument(doc)` — harness only.
+- `Deposit` — **all three fields** consumed: `payload`, `ts` (sorting and identity), `from`.
+- **Not consumed:** `inbox.post` (we always address a document, never a raw inbox), `inbox.processInbox`.
+
+### Types imported
+
+`Nuri`, `NuriLike`, `PrincipalId`, `NG`, `UnionSubject`, `ShapeQuery`, `ShapeObservable`, `DeepSignalSet`.
+
+Two of these are not underwritten by the engagement document as it stands. `ShapeQuery` and `ShapeObservable` are *named* by `watchShape`'s published signature but never defined there, and we use both **generically** (`ShapeQuery<T>`, `ShapeObservable<T>`) while the published signature is not generic. `DeepSignalSet` is named by **no** published signature at all — the harness imports it on the strength of the package exporting it, which by the engagement's own rule ("a type is published only when a published signature uses it") means we depend on something unpublished.
+
+## Constraints
+
+- **The session is the package's, and there is exactly one identity per page.** No call of ours takes an identifier, and we never build a session. Anything that made a page carry two identities would break the whole app, starting with the inbox wrapper's session-long memo.
+- **`ensureIdentity()` must reject rather than resolve early.** We render the entire interface past that await. A resolve that did not actually finish restoring what was shared would show a signed-in user an empty account — worse than an error — so we rely on the rejection being real and we never render past one.
+- **The barrier is the package's to mount and take down.** The app renders nothing of its own around sign-in and does not reload its own page; a barrier that leaked past the broker round-trip, or one the app had to dismiss itself, would need app-side machinery we deliberately do not have.
+- **A rejection means "unknown", never "absent".** Every place we ask whether something exists (a document's record, a document's inbox) treats a throw as unknown and retries or surfaces it. A call that quietly returned "nothing" instead of throwing would make us provision a second set of documents for a user who already has them.
+- **`sessionId` is relayed, never converted.** We pass through whatever the session carries, `string | number`, because stringifying it fails for real downstream.
+- **Isolation is the package's, not ours.** No screen and no data helper implements an access check: we place each entity in its scope and trust the scope. If reading stopped being "possession of the key", the app would have no barrier of its own to fall back on.
+- **Writes must be authoritative on our own document.** A withdrawal must not come back. We re-read with `sparqlQuery` rather than trusting a reactive read to settle it — the reactive surface is a view, not the authority.
+- **We do not poll the broker.** No retry loop and no short-interval re-read papers over a missing push. So every gap in the reactive path stays visible as a delay in the product, which is why the frictions below matter rather than being absorbed.
+- **A public store must serve its read key to whoever asks.** Discovery of other people's events is a plain read of the public scope, with no grant step. If that stopped holding, the product's primary discovery axis would be gone.
+- **One deployment parameter is ours, not yours:** the wallet file we serve and its password. We pass them; the package reads no environment of its own.
+
+## Frictions
+
+**1. Resolving a document's inbox is not idempotent under concurrency.** The engagement states that resolving an inbox "throws rather than handing back a second one". It does not. **Four concurrent calls for one document produced three inboxes.** The four are ordinary and unavoidable: creating an event opens its inbox, the materialiser opens it to read, the watch opens it to subscribe, and the watch callback re-enters the materialiser — all within a fraction of a second, none aware of the others. The consequence is silent and total: the owner watches one inbox while sign-ups land in another, and a sign-up is simply never seen. We now funnel every call through one wrapper that de-duplicates in-flight resolutions per document for the session's lifetime. That wrapper is compensation for this friction, not a design of ours, and it only protects a single session — two sessions racing are still unprotected, because nothing on this surface makes the resolution idempotent where it actually lives.
+
+**2. A deposit into an inbox you watch yourself produces no push. Verified twice.** The depositor's own session never materialises it. This is the normal case for us, not an edge: the host of a meeting point is often also the actor whose deposit must be processed, and its materialiser sits on its own inbox. So the owner is not woken by its own action, and the deposit waits for the next connection.
+
+**3. A write to your own document is not re-read by the reactive read in the writing session.** Three observations of sixty seconds each: the value stays stale for the whole session. Combined with friction 2, this is what makes a participant count lag **one full connection** behind the write that produced it — the first reconnect after a sign-up still reads the old value, and only the second reads the true one. We compensate nowhere: papering over it would mean polling, which we forbid.
+
+**4. There is no way to reset a test wallet.** The suite's data lives in the wallet file the deployment serves; nothing on this surface empties it, and recreating the browser profile does not touch it — two runs "on a fresh profile" measure the same accumulated state. Every scenario writes into that wallet and nothing removes what it wrote, so per-scenario duration climbs monotonically within a run and later scenarios die in their setup hook at its cap, silently, with nothing in the console. **The suite degrades to zero passing scenarios.** No reset primitive is published — no teardown call, no throwaway wallet — so there is nothing to call, and we will not fake one by bypassing our own enforcement point. This is the friction that costs us the most: it makes the `@data` layer's results non-reproducible, which is a property of the harness we cannot fix from here.
+
+**5. The published signature of `watchShape` does not match the call that works.** It is published as `watchShape(query: ShapeQuery): ShapeObservable` — one argument, non-generic, and naming two types (`ShapeQuery`, `ShapeObservable`) that the engagement document never defines. What works, and what every read in the app goes through, is the **two-positional-argument** form with a type parameter: `watchShape<T>(shapeType, scope)`. Lower than the four above — we have a working call — but the document as written cannot be coded against for the single most-used read on the surface.

.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_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`: one `DELETE … INSERT … WHERE` update, not a DELETE followed by a separate INSERT — the latter left a window where a reader could see the field briefly absent) 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 this session OWNS** — never the identity it signed in as, which is opaque and never written into an entity ([[decision_2026-08-10_the-barrier-names-no-identity]] in `app-security`). It therefore **arrives late**: a mutation fired before that document resolves must **reject** rather than write, which is what `joinEvent` and `leaveEvent` do — they throw, and the screen's confirmation follows the write. 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/functional-domain/_overview.md

@@ -0,0 +1,29 @@
+---
+type: _overview
+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, découverte, périmètre, scope, public, protected, privé]
+  paths: ["src/modules/*/features/**"]
+---
+
+# Functional domain
+
+Festipod's **functional domain**: what the product promises and the business vocabulary that describes it. Original source: `README.md §Modèle fonctionnel`.
+
+**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.
+
+## Pivotal idea
+
+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.**
+
+## Scope & confidentiality
+
+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]]).
+
+## Links
+
+- [[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

@@ -0,0 +1,23 @@
+---
+type: brief
+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
+---
+
+# Deduplicating events on a decentralized infrastructure
+
+**Status:** Open challenge — not settled
+**Captured:** 2026-06-15 (from `README.md §Défis ouverts`)
+
+## Problem
+
+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]]).
+
+## Leads considered (not settled)
+
+- **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.
+
+## Link with the write model
+
+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

@@ -0,0 +1,31 @@
+---
+type: knowledge
+summary: Reference for the actors (user, connection, declarer, host, participant, member) and the business concepts (meeting point, event, community, curated list, connection)
+---
+
+# Actors and business concepts
+
+Vocabulary reference. Every actor is a specialization of an authenticated **user** in a given context — not a separate account role.
+
+## Actors
+
+| Actor | Definition |
+|---|---|
+| **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"** — and this now holds all the way down: the event carries no host field at all, in the shape or in the app type (`data-layer` → [[knowledge_entities]]). 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 signs up and withdraws through the same path as anyone else. The declarer is nonetheless the event document's **owner**, hence its only writer (`app-security` → [[decision_2026-08-16_write-rights-are-the-owned-list]]). The "host" is an actor at the **meeting point** level (next row), never 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. |
+
+## Business concepts
+
+| Concept | Definition |
+|---|---|
+| **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"). |
+
+> 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

@@ -0,0 +1,26 @@
+---
+type: knowledge
+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
+---
+
+# Business model: the grafted meeting point
+
+> Festipod lets users create **meeting points** that come to be "grafted" onto **existing public events**. The goal: encourage people to meet around those events.
+
+## The inversion to grasp
+
+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.
+
+Direct consequences for modelling:
+
+- **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.
+
+## Authentication
+
+**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]].
+
+## Underlying stack
+
+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,53 @@
+---
+type: knowledge
+summary: The product model of confidentiality and discovery — every entity lives in the SCOPE matching who must read it; other users' events are found through a shared index, not by 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
+
+Reading the `public` scope only ever returns **this session's own** public documents — there is no call that unions every user's public store (concept `data-layer`, [[contract_polyfill-surface]]). A declared event was therefore reachable by its declarer alone, which made the whole cross-user sign-up flow — the product's premise — unreachable.
+
+**A user discovers events they did not create through a shared index**: an ordinary public document, indistinguishable from any other, that the app reaches by a reference it hardcodes. Anyone may deposit a reference to their event into it; only the index's owner curates those deposits into visible entries, ordered by the event's start date. This is the **primary** discovery axis, settled as [[decision_2026-08-17_discovery-through-a-shared-index]] (concept `data-layer`) — **no code consumes the index yet.** A **secondary**, relational axis stays layered on top: the connections' *protected* participations ("my friends are attending…").
+
+Four costs come with it, accepted rather than solved: an event becomes findable only once **someone curates** the index, on no fixed schedule — curation is an operator role, not a feature that runs itself; an event declared before its document could carry the field the index reads never becomes findable through it, permanently; a withdrawn or later-corrected event **stays listed** — nothing here removes an entry, so a reader of the index must tolerate a reference that no longer resolves, or resolves to something changed; and an event's position in the list is **frozen at the moment it was curated** — correcting its date afterwards does not move it. Full mechanics and the rejected alternative: [[decision_2026-08-17_discovery-through-a-shared-index]].
+
+> **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.
+
+## Settled: the event write model is OWNER-ONLY
+
+Who may update a declared event was long open — owner, wiki, or immutable. It is **owner: the declarer alone**, and not as a free product choice. The data model leaves no other reading: only a document's owner writes it, a read key never grants a write, and no call adds a writer, so "wiki" is not expressible at all. The declarer's own listing of their documents is what says which events are theirs, permanently (`app-security` → [[decision_2026-08-16_write-rights-are-the-owned-list]]).
+
+This constrains **deduplication**: two declarations of the same real-world event cannot be merged by one declarer editing the other's document ([[brief_2026-06-15_event-deduplication]]).
+
+## Open questions (business)
+
+- **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

@@ -0,0 +1,31 @@
+---
+type: knowledge
+summary: What is implemented today (event + meeting point lifecycle, profiles, connections) vs the evolutions identified but not built (communities, subscriptions, curated lists, multi-user)
+---
+
+# Current features vs upcoming evolutions
+
+## Implemented (screens reachable through the router)
+
+- 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
+
+> **Signing up is wired step by step, and the count a bystander sees lags the flow by one connection.** Each step is honest: `joinEvent` persists a Participation and deposits into the event's inbox, where its owner reads it; `leaveEvent` deletes the Participation authoritatively (concept `data-layer`, [[caveat_participation-deletion]]); neither succeeds in silence, and the confirmation the user sees follows the write. Driven end to end in a real browser, the signer's own confirmation is instant and correct, but the `participantCount` a bystander sees stays at 0 through the session and the first reconnect, only catching up on the second — a known layer limitation, not data loss (concept `data-layer`, [[caveat_participant-count-one-connection-lag]]). Nothing short of exercising the whole thing end to end shows this kind of gap (concept `bdd-testing`, [[cookbook_live-probe]]). Treat the bullet above as *screens reachable*, not as an instantly-consistent journey. **Public discovery does not work yet**: a user sees another user's public event only once a shared index exists and is curated (concept `data-layer`, [[decision_2026-08-17_discovery-through-a-shared-index]]; concept `functional-domain`, [[knowledge_data-scopes-and-discovery]]) — no code consumes it today.
+
+> **Updating an event is reserved to its declarer**, and the interface says so rather than discovering it late: the edit route is decided by ownership, and the confirmation follows the write instead of preceding it (concept `app-architecture`, [[knowledge_screen-pattern]]). Owner-only is not a policy choice here — it is the only reading the data model allows ([[knowledge_data-scopes-and-discovery]]).
+
+> **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.
+
+> **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/tech-stack/_overview.md

@@ -0,0 +1,21 @@
+---
+type: _overview
+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", "pnpm-lock.yaml", "Dockerfile", ".env.example", "bunfig.toml", "tsconfig.json", "src/index.ts", "src/index.html", ".storybook/**", "scripts/**"]
+---
+
+# Tech stack
+
+The project's stack and tooling. Guiding principle: **Bun-first** — Bun replaces Node/npm/vite/webpack/jest and provides the native server APIs.
+
+**Read this first:** [[rule_bun-first]] — the convention that decides which tool to use.
+
+## Links
+
+- [[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/caveat_polyfill-overlay-needs-a-dev-restart.md

@@ -0,0 +1,33 @@
+---
+type: caveat
+summary: A running `bun run dev` never picks up a refreshed data-layer package — VERIFIED, not even across a real rebuild (new bundle hash, still the stale dependency). Only a restart serves the fresh copy; suspect a stale server before suspecting the code.
+last_checked: 2026-08-16
+---
+
+# Pitfall: refreshing the data-layer package never reaches a running dev server, not even across a rebuild
+
+`pnpm run overlay:polyfill` (or `overlay:indexing`, for the other provider) overlays the local checkout into `node_modules/<package>/` as real files, and keeps them current. **That is all it does.** A `bun run dev` already running goes on serving the package it loaded at startup, however many times the overlay is rewritten underneath it, and however many rebuilds happen in between.
+
+**VERIFIED, controlled sandbox test with this project's own bun.** A dependency resolving to copy A, overlaid with copy B: the running server still serves A at +3 s and +13 s after the overlay. An edit to **application source** then triggers a genuine rebuild — a new bundle hash confirms it — and the rebuilt bundle **still serves A**. Only a restart serves B. So the mechanism is not "the watcher never fires because `node_modules` is excluded" — a rebuild the watcher DOES trigger still carries the stale dependency forward; the server's resolution of that import is pinned at process start, and a rebuild does not re-resolve it.
+
+**So: restart `bun run dev` after every refresh of the package — a rebuild is not a substitute, even a real one.** There is no signal that you needed to; a stale server looks exactly like a current one.
+
+## Why this is worth a leaf
+
+VERIFIED 2026-08-16, and it cost about an hour. A defect had been fixed on the provider's side, the overlay was refreshed, and an automated probe on a freshly launched server confirmed the fix — 3 runs out of 3, clean. The same sequence performed by hand in a browser reproduced the defect immediately. The two observations looked irreconcilable, and the search went to the wallet, to prior state, to timing.
+
+The dev server had been running for **six days**. It predated the package rename and the whole migration, and it was serving code from before the fix. The browser was running a different application from the one under test.
+
+Two things made it hard to see. The failure mode is **silence** — nothing warns that the served code is old. And `scripts/overlay-local-checkout.ts` explicitly promised the opposite, that `bun --hot` would reload the copied file live; that claim is now corrected in the script, but a reader who trusted it would rule out the true cause first, which is exactly what happened.
+
+## The reflex to build
+
+When a fix does not appear to take effect, or when a hand-run and an automated run disagree, **check how long the server has been up before anything else**. It is one command, and it eliminates the cheapest hypothesis first:
+
+```bash
+ps -o lstart= -p $(pgrep -f 'bun --hot src/index.ts' | head -1)
+```
+
+Do not reach for "touch a source file to force a rebuild" as a lighter alternative to restarting — it does trigger a real rebuild, and the rebuild still serves the stale dependency. The same reasoning applies to anything else served out of `node_modules` — the trap is the location, not this package.
+
+Related: [[cookbook_live-probe]] (bdd-testing) — a probe answers only for the code the server actually holds, so a stale server invalidates the probe's conclusion, not the product's behaviour.

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

@@ -0,0 +1,52 @@
+---
+type: knowledge
+summary: Three run paths — dev AND production both serve from src/ (bun --hot / bun run start), while bun run build produces a dist/ that nothing serves; NODE_ENV therefore never means "I am a bundle"; path alias @/* → ./src/*
+last_checked: 2026-08-16
+---
+
+# Build pipeline
+
+## Three paths, and only two of them ever run
+
+| Path | Command | What is served |
+|---|---|---|
+| **Dev** | `bun run dev` → `bun --hot src/index.ts` | **`src/`** — HMR, port 3000 |
+| **Production** | `bun run start` → `NODE_ENV=production bun src/index.ts` | **`src/` as well** — Bun transpiles on the fly |
+| Bundle | `bun run build` → `build.ts` (Bun bundler + Tailwind plugin) → `dist/` | **nothing** |
+
+> ⚠️ **`dist/` has no consumer, and `NODE_ENV=production` does not mean "built".** The container copies the sources and runs `bun run start`, serving from `src/` exactly as dev does ([[knowledge_deployment]]) — **nothing ever serves `dist/`**, here or anywhere else. So any code that branches on `NODE_ENV` to answer *"am I a bundle?"* is wrong in the one place it matters: in production the answer is **no**. That inference shipped once, on the runtime-config fetch below, and the deployed app could sign nobody in. Ask the artifact you care about, never the environment.
+
+- **Path alias**: `@/* → ./src/*` (declared in `tsconfig.json`, resolved relative to that file — `paths` has needed no `baseUrl` since TS 4.4).
+
+> ⚠️ **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.
+
+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]]).
+
+## Details of `build.ts` and of the server
+
+- `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-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.
+
+Everything served from `src/` — **dev and production alike** — therefore takes its configuration from 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.
+
+**The fetch is skipped on one condition only: the global is already set** (which is what a `build.ts` bundle's `define` does, and nothing else does). The entry reads it through bracket access, so `define` — which rewrites the dotted form — leaves that read alone. The question is *"was the value inlined?"*, asked of the global itself; it was once asked as *"is `NODE_ENV` production?"*, which in this project means the opposite of what it looks like (see above) — the deployed app then skipped the only step that could give it a wallet, `ensureIdentity()` threw for want of one, and `/festipod-config.json` sat there served and unasked (`app-security` → [[caveat_shared-wallet-global-before-gate-import]]).
+
+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** (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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+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.$
+---
+
+# Native Bun APIs
+
+Reference for the Bun APIs to favour (see [[rule_bun-first]]). Full documentation: `node_modules/bun-types/docs/**.mdx`.
+
+## Server — `Bun.serve()`
+
+Supports WebSockets, HTTPS and routes. No need for `express`/`ws`.
+
+```ts
+import index from "./index.html"
+Bun.serve({
+  routes: {
+    "/": index,
+    "/api/users/:id": { GET: (req) => new Response(JSON.stringify({ id: req.params.id })) },
+  },
+  websocket: { open: (ws) => ws.send("hello"), message: (ws, m) => ws.send(m), close: (ws) => {} },
+  development: { hmr: true, console: true },
+})
+```
+
+This is the mechanism behind `src/index.ts` (see concept `app-architecture` §app-shell).
+
+## HTML imports (frontend)
+
+`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.
+
+## Storage & shell
+
+- **`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 loads `.env` automatically → do not use `dotenv`.

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

@@ -0,0 +1,61 @@
+---
+type: knowledge
+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; the data-layer git dependency must be pinned to a tag/commit and match `contracts.yaml`'s ref; the shared wallet reaches the container through env vars, not a mount, because it isn't a secret; no CI/CD committed; dev goes through the portless wrapper
+last_checked: 2026-08-17
+---
+
+# Deployment & infra
+
+Nothing has actually been deployed with this shape yet — this leaf states what a deployment needs to line up, verified against the code and manifests, not a procedure that has been run end to end.
+
+## Dockerfile
+
+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"]`.
+
+**`bun` peer pitfall — historical, and no longer reproducing.** `bun-plugin-tailwind` declares `bun` as a peerDependency, and pnpm used to materialize the npm `bun` package with a `node_modules/.bin/bun` shim that shadowed the real binary under `bun run`; its postinstall being skipped left a broken shim and `bun run start` failed. `pnpm.onlyBuiltDependencies: ["bun"]` in `package.json` was added for that. **VERIFIED 2026-08-17 in a built image: the shim does not appear at all** — `bun` is absent from `node_modules/.bin`, and `which bun` resolves to the base image's `/usr/local/bin/bun`. So the approval is currently inert in this dependency shape. Keep it (it costs nothing and the shape can come back), but do not trust the mechanism as described without re-checking the built image — this paragraph described a live hazard and now describes a dormant one.
+
+**Asset paths are written `/../chunk-*.js`.** Verified in the built image's entry HTML. Browsers normalise that to `/chunk-*.js` at the root and it serves correctly, and the existing deployment already passes it through its proxy — so it works. It is still an odd literal: a proxy or CDN that rejects or rewrites `..` segments differently would break asset loading, and the symptom would be a blank page with 404s on chunks rather than anything naming the cause.
+
+**`tailwindcss` is a devDependency the server needs at serve time, not only at build time.** `bunfig.toml`'s `[serve.static] plugins = ["bun-plugin-tailwind"]` applies to `Bun.serve`'s HTML-import serving — the path both `bun run dev` and `bun run start` use ([[knowledge_build-pipeline]]) — not only to `bun run build.ts`. The install stage must therefore keep installing devDependencies: no `--prod`, and `NODE_ENV` stays unset until the `release` stage, after `pnpm install --frozen-lockfile` has already run. Moving `ENV NODE_ENV=production` earlier, or adding `--prod` to the install, would drop `tailwindcss` and break every serve, dev included.
+
+**Production runs the sources, and this is the normal path, not a quirk**: `start` = `NODE_ENV=production bun src/index.ts` → the container **runs the TypeScript directly** (Bun transpiles on the fly). `bun run build` (→ `dist/`) is on **no** path at all — nothing serves that directory, in this container or anywhere else; serving it would mean changing the entrypoint. Consequence for the code: in this deployment `NODE_ENV=production` says *how* the sources run, never *that they were bundled* — [[knowledge_build-pipeline]].
+
+## The data-layer git dependency must stay pinned, and the pin must be checkable
+
+`package.json` resolves `@ng-eventually/polyfill` from `git+https://…/ng-eventually.git#<ref>&path:/packages/polyfill` — the `path:` selector is what lets a subdirectory of the provider's repo be installed as the package. Two things follow, ahead of any real deployment:
+
+- **`<ref>` must name a tag or a commit, never a branch.** A branch moves: the image was built against whatever commit the branch pointed to at build time, and the branch head can advance afterwards without the image changing — so "the same deployment" silently starts drifting from what it was actually built against. The tag-naming convention itself is the provider's call and is not settled yet; the requirement is only that the ref be immutable.
+- **The same `<ref>` should also be the `ref:` of the `polyfill-surface` entry in `.project/contracts.yaml`.** That manifest pins the version of [[contract_polyfill-surface]] the app is coded against; when it names the same ref as `package.json`'s specifier, the contract the app was written for and the package actually installed name the same state, and a difference between the two becomes visible instead of silent. Both now name the **same commit**, which is the state a deployment can ship on. A tag is expected to replace that commit once the provider settles a naming convention — a one-line change in each of the two files, with the invariant unchanged: whatever the ref is, the two must agree.
+
+**`pnpm install --frozen-lockfile` (the Dockerfile's install step) never regenerates — it only verifies.** `pnpm-lock.yaml` must already reproduce `package.json` exactly, so any change to the git specifier (ref, path, or package name) needs `pnpm install` run and the regenerated lockfile committed *before* the image can build; skipping that step fails the build outright, not silently. This has bitten once: the lockfile still named the old package and path after the dependency was renamed, so `--frozen-lockfile` refused and the image could not build until it was regenerated.
+
+## CI/CD
+
+**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.
+
+**A deployed origin IS embeddable in the hosted broker's iframe — VERIFIED 2026-08-17 in production**, on the first deployment carrying the injected wallet and the external data layer: a user signed in and saw their own data, which is only reachable through that iframe. The question had been open because nothing in this repo exercises it; it is settled for this origin, and it is settled by the deployment rather than by a test — **no scenario covers it**, so a change of origin, of proxy, or of the broker's embedding policy would be found by a person, not by the suite. [[caveat_firefox-lna-blocks-broker-iframe]] remains the one recorded failure mode, and it is a local-dev-origin one (`127.0.0.1` blocked by Firefox LNA).
+
+## Environment variables
+
+- `PORT` (default 3000), `NODE_ENV` (enables/disables HMR and the dev auto-seed — see concept `data-layer`).
+- No `.env*` is committed (`.env` is gitignored).
+
+### The shared wallet: config, not a secret, not a mount
+
+[[contract_polyfill-surface]] requires the app to serve a wallet file (`.ngw`) and pass its URL and password to `configure` as `sharedWallet: { fileUrl, password }`. `*.ngw` is gitignored and no deployment mounts one, so `src/index.ts` serves it from environment variables, read fresh on every request:
+
+- `FESTIPOD_SHARED_WALLET_PASSWORD` — the password, always read this way (dev, tests, and deployments alike).
+- `FESTIPOD_SHARED_WALLET_FILE` — a filesystem path to the `.ngw` file. The form local dev and the test harness use: the file sits on the machine's disk.
+- `FESTIPOD_SHARED_WALLET_FILE_BASE64` — the file's bytes, base64-encoded. The form a deployment uses instead, since nothing mounts a `.ngw` into the container.
+
+**Precedence is one-directional and does not fall through.** `FESTIPOD_SHARED_WALLET_FILE` wins whenever it is set, *even if the path turns out unreadable* — an unreadable path answers 404, it does **not** fall back to the base64 form. A deployment must set exactly one of the two; leaving a leftover `FESTIPOD_SHARED_WALLET_FILE` pointing nowhere in a deployment environment silently 404s instead of serving the base64 value that was actually intended. A malformed base64 value answers 500 naming the variable — never a 404, which would be indistinguishable from "not configured at all".
+
+**Neither the password nor the wallet file is a secret**, and that is deliberate, not an oversight: the contract has the app hand both to every user who opens it — that is how a first-time device without its own wallet onboards. Provisioning them as protected/mounted storage would guard something the app already gives away by design; they travel as plain configuration instead, and a new host needs only its environment variables, nothing to mount.
+
+## Dev
+
+`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 overlay for the SDK**: in production the `@ng-eventually/polyfill` dependency comes from Gitea (git+https, pinned by `pnpm-lock.yaml`), and `@ng-helpers/indexing` likewise. When a provider's package has to be exercised from a local checkout, `pnpm run overlay:polyfill` or `pnpm run overlay:indexing` (script `scripts/overlay-local-checkout.ts`, one provider per run) replaces `node_modules/<package>` with a **real copy** of that checkout (location overridable with `NG_EVENTUALLY_LOCAL` / `NG_HELPERS_LOCAL`) — **without** its own `node_modules/*` — and resyncs on every edit. Copying rather than symlinking is what keeps a **single instance** of every package the provider shares with Festipod installed (`@ng-org/*`, and for `indexing`, `@ng-eventually/polyfill` itself): 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

@@ -0,0 +1,43 @@
+---
+type: knowledge
+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, overlay:polyfill/overlay:indexing for the reactive local overlay)
+---
+
+# Stack & commands
+
+## Components
+
+| Layer | Technology |
+|---|---|
+| 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`) |
+
+## `package.json` scripts (the real ones)
+
+| Script | Command / role |
+|---|---|
+| `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/`, **which nothing serves**: production runs `start`, from `src/` ([[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/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) |
+| `overlay:polyfill` / `overlay:indexing` | `bun scripts/overlay-local-checkout.ts <provider>` — **reactive** local overlay of a provider's checkout (`@ng-eventually/polyfill` or `@ng-helpers/indexing`; copy-overlay + watcher, `--once` for a single pass). Details in [[knowledge_deployment]]. |
+| `storybook` / `build-storybook` | Storybook dev (6006) / static build |
+
+## Pitfalls
+
+- **`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, and reproducibly: regenerating from an *unchanged* `.shex` reproduces the committed bindings byte-for-byte. Verify that before trusting an ORM diff as your own — run the generator once on the shape untouched, then again after your edit, so the diff shown is the edit alone (concept `data-layer` → [[knowledge_nextgraph-stack]]).

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

@@ -0,0 +1,39 @@
+---
+type: rule
+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
+---
+
+# Rule: Bun-first
+
+By default, use **Bun** and its native APIs rather than the Node.js equivalents.
+
+| Instead of… | Use |
+|---|---|
+| `node <file>`, `ts-node` | `bun <file>` |
+| `jest`, `vitest` | `bun test` |
+| `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` / the Bun bundler (HTML imports) |
+| `express` | `Bun.serve()` |
+| `better-sqlite3` | `bun:sqlite` |
+| `ioredis` | `Bun.redis` |
+| `pg`, `postgres.js` | `Bun.sql` |
+| `ws` | `WebSocket` (built in) |
+| `node:fs` readFile/writeFile | `Bun.file` |
+| `execa` | `Bun.$\`...\`` |
+| `dotenv` | (pointless — Bun loads `.env` automatically) |
+
+API details: [[knowledge_bun-apis]].
+
+## Exception: package installation goes through pnpm
+
+**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 overlay goes through `pnpm run overlay:polyfill` (`overlay:indexing` for the other provider; 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,45 @@
+# Inter-repo contracts. Festipod is a CONSUMER only: it publishes no interface of its own,
+# and it consumes two — the SDK surface `@ng-eventually/polyfill` engages toward the
+# applications built on it, and the indexing layer `ng-helpers` engages toward the
+# applications that need to make things findable.
+#
+# 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.
+#
+# Each interface gets its own FOLDER inside the concept that owns it, holding the pulled
+# engagement and — once Festipod actually consumes the interface — the `usage_festipod.md`
+# declaration beside it. Both interfaces land in `data-layer`: it is the concept that owns
+# how Festipod uses an external data surface, including the machinery behind discovery
+# (`functional-domain` owns the product intent of discovery and explicitly delegates its
+# technical how to the data SDK).
+#
+# `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/polyfill-surface/
+    type: git
+    # BLOCKED on the provider: it has moved this leaf into its own interface folder
+    # (`.../app-contract/polyfill-surface/contract_polyfill-surface.md`) and has NOT pushed
+    # that move. The path below is the only one that resolves at a pushed commit, and it is
+    # the path the local copy's stamp came from — so it stays until the move is pushed.
+    # Until then `pull` and `check` both fail on this entry (the file no longer exists at
+    # this path in a working copy that has the move). Adopt the new path and re-pull the
+    # moment the provider pushes; the pulled copy's basename does not change.
+    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: a8d53010c227462cc9317e9be499c2100ca8d533
+
+  - contract: indexing-layer
+    into: concepts/data-layer/indexing-layer/
+    type: git
+    pullFrom: https://gitea.reconnexion.apps.gueraud.net/Sylvain/ng-helpers.git/.project/concepts/indexing/indexing-layer/contract_indexing-layer.md
+    # Pinned on the TAG, never on a branch: a branch moves under us and the pin would stop
+    # naming a state anyone can go back to. Re-pin to the next tag at each upgrade.
+    ref: v1.0.1

.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`

.storybook/decorators.tsx

@@ -0,0 +1,20 @@
+import React from 'react';
+import type { Decorator } from '@storybook/react-webpack5';
+import { ThemeProvider } from '../src/shared/context/ThemeContext';
+import { NextGraphProvider } from '../src/shared/context/NextGraphContext';
+import { FestipodDataProvider } from '../src/shared/context/FestipodDataContext';
+import { RouterProvider } from '../src/app/router';
+
+export const withProviders: Decorator = (Story) => (
+  <ThemeProvider>
+    <NextGraphProvider>
+      <FestipodDataProvider>
+        <RouterProvider>
+          <div style={{ maxWidth: 375, margin: '0 auto', height: '100vh', background: 'var(--sketch-white)' }}>
+            <Story />
+          </div>
+        </RouterProvider>
+      </FestipodDataProvider>
+    </NextGraphProvider>
+  </ThemeProvider>
+);

.storybook/main.ts

@@ -0,0 +1,16 @@
+import type { StorybookConfig } from '@storybook/react-webpack5';
+
+const config: StorybookConfig = {
+  "stories": [
+    "../src/**/*.mdx",
+    "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)"
+  ],
+  "addons": [
+    "@storybook/addon-webpack5-compiler-swc",
+    "@storybook/addon-a11y",
+    "@storybook/addon-docs",
+    "@storybook/addon-onboarding"
+  ],
+  "framework": "@storybook/react-webpack5"
+};
+export default config;

.storybook/preview.ts

@@ -0,0 +1,19 @@
+import type { Preview } from '@storybook/react-webpack5'
+import '../src/index.css';
+
+const preview: Preview = {
+  parameters: {
+    controls: {
+      matchers: {
+       color: /(background|color)$/i,
+       date: /Date$/i,
+      },
+    },
+    viewport: {
+      defaultViewport: 'mobile1',
+    },
+    layout: 'fullscreen',
+  },
+};
+
+export default preview;

AGENTS.md

@@ -0,0 +1,40 @@
+# Festipod
+
+Web app mobile-first où les utilisateurs créent des **points de rencontre** qui se *greffent* sur des **événements publics** existants, pour favoriser les rencontres. L'événement n'est qu'un prétexte/ancrage ; la valeur, c'est le point de rencontre — **on s'inscrit à un point de rencontre, pas à un événement**. Stack : Bun + React + NextGraph (P2P, local-first, chiffré).
+
+## Invariants à toujours garder
+
+- **Architecture feature-based** : le code est organisé par domaine métier, pas par couche technique.
+  ```
+  src/modules/{event,user,home,auth,workshop,meeting,notification}/
+  src/shared/          # Composants, context, data — importable par tous les modules
+  src/app/             # App shell (router, providers, entrée)
+  src/screens/index.ts # Registre d'écrans (utilisé par Storybook)
+  ```
+- **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, 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` | 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` | 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/`).

CLAUDE.md

@@ -1,149 +1,9 @@
+@AGENTS.md
+
 # Festipod Project
 
-This project has two parts:
-1. **Festipod App** - Mobile app mockups in `src/screens/` with sketchy hand-drawn UI
-2. **Prototyping Tool** - Web app to view mockups, user stories, and BDD specs
+Le cœur toujours-chargé (but produit, invariants, conventions Bun-first, carte des concepts) vit dans `@AGENTS.md` ci-dessus. Toute la doctrine détaillée est dans `.project/concepts/` et **livrée automatiquement par le hook concept** quand tu touches le territoire concerné — ne la recopie pas ici.
 
-## Project Structure
-
-```
-src/
-  screens/           # Mockup screens (HomeScreen, EventDetailScreen, etc.)
-  components/
-    sketchy/         # Hand-drawn UI components (Button, Card, Avatar, etc.)
-    specs/           # Specs viewer (GherkinHighlighter, FeatureView, etc.)
-    ui/              # Shadcn/Radix components
-  data/
-    index.ts         # User stories definitions
-    features.ts      # Auto-generated from .feature files
-    testResults.ts   # Cucumber test results
-features/            # Gherkin .feature files (French)
-scripts/             # Build scripts for parsing features
-docs/                # Documentation
-```
-
-## Key Commands
-
-```bash
-bun run dev              # Start dev server with HMR
-bun run test:cucumber    # Run Cucumber tests
-bun run features:parse   # Regenerate features.ts from .feature files
-bun run steps:extract    # Extract step definitions for tooltips
-```
-
-## Conventions
-
-- Gherkin specs are in French (Étant donné, Quand, Alors)
-- UI labels are in French
-- User stories are prefixed US-1 to US-26
-- Screens use the sketchy component library, not Tailwind
-- Specs pages use Tailwind + Shadcn components with system font (not sketchy font)
-- GherkinHighlighter uses card-based layout, not code/text style
-
----
-
-Default to using Bun instead of Node.js.
-
-- Use `bun <file>` instead of `node <file>` or `ts-node <file>`
-- Use `bun test` instead of `jest` or `vitest`
-- Use `bun build <file.html|file.ts|file.css>` instead of `webpack` or `esbuild`
-- Use `bun install` instead of `npm install` or `yarn install` or `pnpm install`
-- Use `bun run <script>` instead of `npm run <script>` or `yarn run <script>` or `pnpm run <script>`
-- Use `bunx <package> <command>` instead of `npx <package> <command>`
-- Bun automatically loads .env, so don't use dotenv.
-
-## APIs
-
-- `Bun.serve()` supports WebSockets, HTTPS, and routes. Don't use `express`.
-- `bun:sqlite` for SQLite. Don't use `better-sqlite3`.
-- `Bun.redis` for Redis. Don't use `ioredis`.
-- `Bun.sql` for Postgres. Don't use `pg` or `postgres.js`.
-- `WebSocket` is built-in. Don't use `ws`.
-- Prefer `Bun.file` over `node:fs`'s readFile/writeFile
-- Bun.$`ls` instead of execa.
-
-## Testing
-
-Use `bun test` to run tests.
-
-```ts#index.test.ts
-import { test, expect } from "bun:test";
-
-test("hello world", () => {
-  expect(1).toBe(1);
-});
-```
-
-## Frontend
-
-Use HTML imports with `Bun.serve()`. Don't use `vite`. HTML imports fully support React, CSS, Tailwind.
-
-Server:
-
-```ts#index.ts
-import index from "./index.html"
-
-Bun.serve({
-  routes: {
-    "/": index,
-    "/api/users/:id": {
-      GET: (req) => {
-        return new Response(JSON.stringify({ id: req.params.id }));
-      },
-    },
-  },
-  // optional websocket support
-  websocket: {
-    open: (ws) => {
-      ws.send("Hello, world!");
-    },
-    message: (ws, message) => {
-      ws.send(message);
-    },
-    close: (ws) => {
-      // handle close
-    }
-  },
-  development: {
-    hmr: true,
-    console: true,
-  }
-})
-```
-
-HTML files can import .tsx, .jsx or .js files directly and Bun's bundler will transpile & bundle automatically. `<link>` tags can point to stylesheets and Bun's CSS bundler will bundle.
-
-```html#index.html
-<html>
-  <body>
-    <h1>Hello, world!</h1>
-    <script type="module" src="./frontend.tsx"></script>
-  </body>
-</html>
-```
-
-With the following `frontend.tsx`:
-
-```tsx#frontend.tsx
-import React from "react";
-import { createRoot } from "react-dom/client";
-
-// import .css files directly and it works
-import './index.css';
-
-const root = createRoot(document.body);
-
-export default function Frontend() {
-  return <h1>Hello, world!</h1>;
-}
-
-root.render(<Frontend />);
-```
-
-Then, run index.ts
-
-```sh
-bun --hot ./index.ts
-```
-
-For more information, read the Bun API docs in `node_modules/bun-types/docs/**.mdx`.
+- Specs Gherkin et libellés UI en **français** (`Etant donné`, `Quand`, `Alors`).
+- Conventions techniques (Bun, APIs, build) : concept `tech-stack`. Architecture et écrans : concept `app-architecture`.
+- Documenter un fait projet : `/concept document <sujet>`.

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: @ng-eventually/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

README.md

@@ -1,44 +1,82 @@
 # Festipod
 
-A prototyping tool for the Festipod mobile app - an event discovery and networking platform.
+**Festipod permet aux utilisateurs de créer des points de rencontre qui viennent se « greffer » sur des événements publics existants. L'objectif est de favoriser les rencontres autour de ces événements.**
 
-## What's Inside
+L'événement public (festival, conférence, salon…) 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.
 
-- **Mobile App Mockups** - 13 interactive screens with hand-drawn "sketchy" UI
-- **User Stories** - 26 stories across 5 categories (Events, Workshops, Users, Meetings, Notifications)
-- **BDD Specifications** - Cucumber feature files in French with test integration
+Application web mobile-first. Stack : Bun + React + NextGraph (P2P, local-first, chiffré de bout en bout).
+
+## Modèle fonctionnel
+
+Tous les utilisateurs sont authentifiés — il n'y a pas d'accès anonyme à l'app.
+
+### Acteurs
+
+- **Utilisateur** — toute personne ayant un compte (un wallet NextGraph). Tous les acteurs ci-dessous sont des spécialisations d'un utilisateur dans un contexte donné.
+- **Connexion (« ami »)** — un autre utilisateur avec qui je suis connecté. Sert à scoper les listes (« mes amis qui participent à… ») et la confiance.
+- **Déclarant d'un événement** — l'utilisateur qui a inséré l'événement dans Festipod. *N'est pas (forcément) un organisateur* de l'événement réel : c'est juste quelqu'un qui le référence pour que d'autres puissent y attacher des points de rencontre.
+- **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 qui s'est 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.
+
+### Concepts métier
+
+- **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 (on ne s'inscrit pas à un événement). Sans points de rencontre, un événement Festipod n'a pas d'intérêt.
+- **Événement** — l'ancrage. Un événement public réel (festival, conférence, salon, exposition…) référencé dans Festipod pour servir de support à des points de rencontre. C'est simplement un *prétexte* (titre, dates, lieu, thèmes) ; le déclarant n'est pas l'organisateur officiel de l'événement, juste celui qui l'a inscrit dans Festipod.
+- **Communauté d'intérêt** — un groupement thématique d'utilisateurs. Sert principalement à 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 » ou « les événements de la communauté ». Permet d'organiser/recommander.
+- **Connexion** — lien de confiance entre deux utilisateurs (équivalent « ami »).
+
+### Fonctionnalités actuelles
+
+Implémentées dans le code (écrans visibles via le 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
+
+Voir l'inventaire des routes et des écrans dans le concept [app-architecture](./.project/concepts/app-architecture/).
+
+### Défis ouverts
+
+- **Déduplication des événements en infra décentralisée.** 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. Pistes envisagées, non tranchées :
+  - 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 (recherche avant création) ;
+  - utiliser un identifiant externe canonique (URL officielle de l'événement, Wikidata, schema.org/Event) pour reconnaître les doublons et les présenter comme un seul événement à l'affichage ;
+  - laisser des curators (humains ou communautaires) fusionner / vetter les entrées canoniques.
+
+### Évolutions à venir
+
+Identifiées comme nécessaires (notamment pour la scalabilité et la découverte) mais pas encore implémentées :
+
+- **Abonnement à une communauté d'intérêt** pour découvrir ses événements (mécanisme de discovery distribué).
+- **Abonnement à un utilisateur** pour suivre les événements qu'il déclare (sans nécessairement être ami).
+- **Listes curated** — créer et partager des sélections d'événements éditorialisées.
+- **Multi-utilisateurs collaboratif** : aujourd'hui chaque utilisateur a ses données isolées dans son wallet. Le passage en mode collaboratif (un point de rencontre vu par plusieurs personnes) suppose un refactor de la couche données. Voir le concept [nextgraph-platform](./.project/concepts/nextgraph-platform/) (briefs multi-store, matrice d'autorisations, wallet partagé, fork inbox).
 
 ## Quick Start
 
 ```bash
 bun install
-bun run dev
+bun run dev              # Dev server avec HMR (port 3000)
 ```
 
-Open http://localhost:3000
-
-## Navigation
-
-| Page | Route | Description |
-|------|-------|-------------|
-| Gallery | `#/` | Browse all mockup screens |
-| Demo | `#/demo/{screen}` | Interactive screen preview |
-| Stories | `#/stories` | User stories browser |
-| Specs | `#/specs` | BDD specifications with test status |
-
-## Commands
+## Commandes utiles
 
 ```bash
-bun run dev              # Start dev server with HMR
-bun run test:cucumber    # Run Cucumber tests
-bun run features:parse   # Regenerate features from .feature files
-bun run steps:extract    # Extract step definitions
+bun run build            # Build production vers dist/
+bun run storybook        # Parcourir écrans et composants
+bun run test:cucumber    # Tests BDD
+bun run features:parse   # Régénérer features.ts depuis les .feature
+bun run steps:extract    # Extraire les step definitions pour les tooltips
+bun run build:orm        # Régénérer l'ORM depuis les SHEX shapes
 ```
 
 ## Documentation
 
-See [docs/](./docs/) for detailed documentation:
-
-- [Festipod App](./docs/festipod-app.md) - Mobile app design
-- [Prototyping Tool](./docs/prototyping-tool.md) - Web app architecture
-- [Cucumber Integration](./docs/cucumber-integration.md) - BDD testing setup
+- [AGENTS.md](./AGENTS.md) — cœur : but produit, invariants, carte des concepts
+- [.project/concepts/](./.project/concepts/) — toute la doctrine projet (savoir, règles, décisions, briefs), typée et livrée par hook au moment pertinent. 6 concepts : `functional-domain`, `app-architecture`, `tech-stack`, `data-layer`, `bdd-testing`, `nextgraph-platform`.

build.ts

@@ -133,10 +133,30 @@ const result = await Bun.build({
   sourcemap: "linked",
   define: {
     "process.env.NODE_ENV": JSON.stringify("production"),
+    // 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_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 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"));
+  console.log(`📦 Copied shared wallet → ${path.join(outdir, "shared-wallet.ngw")}`);
+}
+
 const end = performance.now();
 
 const outputTable = result.outputs.map(output => ({

bun.lock

@@ -1,543 +0,0 @@
-{
-  "lockfileVersion": 1,
-  "configVersion": 1,
-  "workspaces": {
-    "": {
-      "name": "bun-react-template",
-      "dependencies": {
-        "@radix-ui/react-label": "^2.1.7",
-        "@radix-ui/react-select": "^2.2.6",
-        "@radix-ui/react-slot": "^1.2.3",
-        "@radix-ui/react-tooltip": "^1.2.8",
-        "bun-plugin-tailwind": "^0.1.2",
-        "class-variance-authority": "^0.7.1",
-        "clsx": "^2.1.1",
-        "lucide-react": "^0.545.0",
-        "react": "^19",
-        "react-dom": "^19",
-        "tailwind-merge": "^3.3.1",
-      },
-      "devDependencies": {
-        "@cucumber/cucumber": "^12.5.0",
-        "@cucumber/gherkin": "^29.0.0",
-        "@cucumber/messages": "^26.0.1",
-        "@types/bun": "latest",
-        "@types/chai": "^5.2.3",
-        "@types/react": "^19",
-        "@types/react-dom": "^19",
-        "chai": "^6.2.2",
-        "happy-dom": "^16.6.0",
-        "tailwindcss": "^4.1.11",
-        "tsx": "^4.21.0",
-        "tw-animate-css": "^1.4.0",
-      },
-    },
-  },
-  "packages": {
-    "@babel/code-frame": ["@babel/code-frame@7.28.6", "", { "dependencies": { "@babel/helper-validator-identifier": "^7.28.5", "js-tokens": "^4.0.0", "picocolors": "^1.1.1" } }, "sha512-JYgintcMjRiCvS8mMECzaEn+m3PfoQiyqukOMCCVQtoJGYJw8j/8LBJEiqkHLkfwCcs74E3pbAUFNg7d9VNJ+Q=="],
-
-    "@babel/helper-validator-identifier": ["@babel/helper-validator-identifier@7.28.5", "", {}, "sha512-qSs4ifwzKJSV39ucNjsvc6WVHs6b7S03sOh2OcHF9UHfVPqWWALUsNUVzhSBiItjRZoLHx7nIarVjqKVusUZ1Q=="],
-
-    "@colors/colors": ["@colors/colors@1.5.0", "", {}, "sha512-ooWCrlZP11i8GImSjTHYHLkvFDP48nS4+204nGb1RiX/WXYHmJA2III9/e2DWVabCESdW7hBAEzHRqUn9OUVvQ=="],
-
-    "@cucumber/ci-environment": ["@cucumber/ci-environment@12.0.0", "", {}, "sha512-SqCEnbCNl3zCXCFpqGUuoaSNhLC0jLw4tKeFcAxTw9MD/QRlJjeAC/fyvVLFuXuSq0OunJlFfxLu+Z3HE+oLPg=="],
-
-    "@cucumber/cucumber": ["@cucumber/cucumber@12.5.0", "", { "dependencies": { "@cucumber/ci-environment": "12.0.0", "@cucumber/cucumber-expressions": "18.0.1", "@cucumber/gherkin": "37.0.1", "@cucumber/gherkin-streams": "6.0.0", "@cucumber/gherkin-utils": "10.0.0", "@cucumber/html-formatter": "22.3.0", "@cucumber/junit-xml-formatter": "0.9.0", "@cucumber/message-streams": "4.0.1", "@cucumber/messages": "31.1.0", "@cucumber/pretty-formatter": "1.0.1", "@cucumber/tag-expressions": "8.1.0", "assertion-error-formatter": "^3.0.0", "capital-case": "^1.0.4", "chalk": "^4.1.2", "cli-table3": "0.6.5", "commander": "^14.0.0", "debug": "^4.3.4", "error-stack-parser": "^2.1.4", "figures": "^3.2.0", "glob": "^13.0.0", "has-ansi": "^4.0.1", "indent-string": "^4.0.0", "is-installed-globally": "^0.4.0", "is-stream": "^2.0.0", "knuth-shuffle-seeded": "^1.0.6", "lodash.merge": "^4.6.2", "lodash.mergewith": "^4.6.2", "luxon": "3.7.2", "mime": "^3.0.0", "mkdirp": "^3.0.0", "mz": "^2.7.0", "progress": "^2.0.3", "read-package-up": "^12.0.0", "semver": "7.7.3", "string-argv": "0.3.1", "supports-color": "^8.1.1", "type-fest": "^4.41.0", "util-arity": "^1.1.0", "yaml": "^2.2.2", "yup": "1.7.1" }, "bin": { "cucumber-js": "bin/cucumber.js" } }, "sha512-+VWxkIIpm5EWFfaF3grP1GlHobzlDBIF54FqJutdYmfpx3LJc+IS8uWdIN97m6zxizo5CPrUopTWkxzwVswUzg=="],
-
-    "@cucumber/cucumber-expressions": ["@cucumber/cucumber-expressions@18.0.1", "", { "dependencies": { "regexp-match-indices": "1.0.2" } }, "sha512-NSid6bI+7UlgMywl5octojY5NXnxR9uq+JisjOrO52VbFsQM6gTWuQFE8syI10KnIBEdPzuEUSVEeZ0VFzRnZA=="],
-
-    "@cucumber/gherkin": ["@cucumber/gherkin@29.0.0", "", { "dependencies": { "@cucumber/messages": "<=25" } }, "sha512-6t3V7fFsLlyhLSj4FS+fPz22pPVcFhFZ3QOP7otFYmkhZ4g1ierj5pf7fxJWvEsI555hGatg+Iql6cqK93RFUg=="],
-
-    "@cucumber/gherkin-streams": ["@cucumber/gherkin-streams@6.0.0", "", { "dependencies": { "commander": "14.0.0", "source-map-support": "0.5.21" }, "peerDependencies": { "@cucumber/gherkin": ">=22.0.0", "@cucumber/message-streams": ">=4.0.0", "@cucumber/messages": ">=17.1.1" }, "bin": { "gherkin-javascript": "bin/gherkin" } }, "sha512-HLSHMmdDH0vCr7vsVEURcDA4WwnRLdjkhqr6a4HQ3i4RFK1wiDGPjBGVdGJLyuXuRdJpJbFc6QxHvT8pU4t6jw=="],
-
-    "@cucumber/gherkin-utils": ["@cucumber/gherkin-utils@10.0.0", "", { "dependencies": { "@cucumber/gherkin": "^34.0.0", "@cucumber/messages": "^29.0.0", "@teppeis/multimaps": "3.0.0", "commander": "14.0.0", "source-map-support": "^0.5.21" }, "bin": { "gherkin-utils": "bin/gherkin-utils" } }, "sha512-BcujlDT343GXXNrMPl3ws6Il3zs8dQw3Yp/d3HnOJF8i2snGGgiapoTbko7MdvAt7ivDL7SDo+e1d5Cnpl3llA=="],
-
-    "@cucumber/html-formatter": ["@cucumber/html-formatter@22.3.0", "", { "peerDependencies": { "@cucumber/messages": ">=18" } }, "sha512-0s3G7kznCRDiiesQ4K0yBdswGqU9E0j2AWUug41NpedBzhaY+Hn192ANRF597GZtuWrCjE53aFb3fOyOsT8B+g=="],
-
-    "@cucumber/junit-xml-formatter": ["@cucumber/junit-xml-formatter@0.9.0", "", { "dependencies": { "@cucumber/query": "^14.0.1", "@teppeis/multimaps": "^3.0.0", "luxon": "^3.5.0", "xmlbuilder": "^15.1.1" }, "peerDependencies": { "@cucumber/messages": "*" } }, "sha512-WF+A7pBaXpKMD1i7K59Nk5519zj4extxY4+4nSgv5XLsGXHDf1gJnb84BkLUzevNtp2o2QzMG0vWLwSm8V5blw=="],
-
-    "@cucumber/message-streams": ["@cucumber/message-streams@4.0.1", "", { "peerDependencies": { "@cucumber/messages": ">=17.1.1" } }, "sha512-Kxap9uP5jD8tHUZVjTWgzxemi/0uOsbGjd4LBOSxcJoOCRbESFwemUzilJuzNTB8pcTQUh8D5oudUyxfkJOKmA=="],
-
-    "@cucumber/messages": ["@cucumber/messages@26.0.1", "", { "dependencies": { "@types/uuid": "10.0.0", "class-transformer": "0.5.1", "reflect-metadata": "0.2.2", "uuid": "10.0.0" } }, "sha512-DIxSg+ZGariumO+Lq6bn4kOUIUET83A4umrnWmidjGFl8XxkBieUZtsmNbLYgH/gnsmP07EfxxdTr0hOchV1Sg=="],
-
-    "@cucumber/pretty-formatter": ["@cucumber/pretty-formatter@1.0.1", "", { "dependencies": { "ansi-styles": "^5.0.0", "cli-table3": "^0.6.0", "figures": "^3.2.0", "ts-dedent": "^2.0.0" }, "peerDependencies": { "@cucumber/cucumber": ">=7.0.0", "@cucumber/messages": "*" } }, "sha512-A1lU4VVP0aUWdOTmpdzvXOyEYuPtBDI0xYwYJnmoMDplzxMdhcHk86lyyvYDoMoPzzq6OkOE3isuosvUU4X7IQ=="],
-
-    "@cucumber/query": ["@cucumber/query@14.7.0", "", { "dependencies": { "@teppeis/multimaps": "3.0.0", "lodash.sortby": "^4.7.0" }, "peerDependencies": { "@cucumber/messages": "*" } }, "sha512-fiqZ4gMEgYjmbuWproF/YeCdD5y+gD2BqgBIGbpihOsx6UlNsyzoDSfO+Tny0q65DxfK+pHo2UkPyEl7dO7wmQ=="],
-
-    "@cucumber/tag-expressions": ["@cucumber/tag-expressions@8.1.0", "", {}, "sha512-UFeOVUyc711/E7VHjThxMwg3jbGod9TlbM1gxNixX/AGDKg82Eha4cE0tKki3GGUs7uB2NyI+hQAuhB8rL2h5A=="],
-
-    "@esbuild/aix-ppc64": ["@esbuild/aix-ppc64@0.27.2", "", { "os": "aix", "cpu": "ppc64" }, "sha512-GZMB+a0mOMZs4MpDbj8RJp4cw+w1WV5NYD6xzgvzUJ5Ek2jerwfO2eADyI6ExDSUED+1X8aMbegahsJi+8mgpw=="],
-
-    "@esbuild/android-arm": ["@esbuild/android-arm@0.27.2", "", { "os": "android", "cpu": "arm" }, "sha512-DVNI8jlPa7Ujbr1yjU2PfUSRtAUZPG9I1RwW4F4xFB1Imiu2on0ADiI/c3td+KmDtVKNbi+nffGDQMfcIMkwIA=="],
-
-    "@esbuild/android-arm64": ["@esbuild/android-arm64@0.27.2", "", { "os": "android", "cpu": "arm64" }, "sha512-pvz8ZZ7ot/RBphf8fv60ljmaoydPU12VuXHImtAs0XhLLw+EXBi2BLe3OYSBslR4rryHvweW5gmkKFwTiFy6KA=="],
-
-    "@esbuild/android-x64": ["@esbuild/android-x64@0.27.2", "", { "os": "android", "cpu": "x64" }, "sha512-z8Ank4Byh4TJJOh4wpz8g2vDy75zFL0TlZlkUkEwYXuPSgX8yzep596n6mT7905kA9uHZsf/o2OJZubl2l3M7A=="],
-
-    "@esbuild/darwin-arm64": ["@esbuild/darwin-arm64@0.27.2", "", { "os": "darwin", "cpu": "arm64" }, "sha512-davCD2Zc80nzDVRwXTcQP/28fiJbcOwvdolL0sOiOsbwBa72kegmVU0Wrh1MYrbuCL98Omp5dVhQFWRKR2ZAlg=="],
-
-    "@esbuild/darwin-x64": ["@esbuild/darwin-x64@0.27.2", "", { "os": "darwin", "cpu": "x64" }, "sha512-ZxtijOmlQCBWGwbVmwOF/UCzuGIbUkqB1faQRf5akQmxRJ1ujusWsb3CVfk/9iZKr2L5SMU5wPBi1UWbvL+VQA=="],
-
-    "@esbuild/freebsd-arm64": ["@esbuild/freebsd-arm64@0.27.2", "", { "os": "freebsd", "cpu": "arm64" }, "sha512-lS/9CN+rgqQ9czogxlMcBMGd+l8Q3Nj1MFQwBZJyoEKI50XGxwuzznYdwcav6lpOGv5BqaZXqvBSiB/kJ5op+g=="],
-
-    "@esbuild/freebsd-x64": ["@esbuild/freebsd-x64@0.27.2", "", { "os": "freebsd", "cpu": "x64" }, "sha512-tAfqtNYb4YgPnJlEFu4c212HYjQWSO/w/h/lQaBK7RbwGIkBOuNKQI9tqWzx7Wtp7bTPaGC6MJvWI608P3wXYA=="],
-
-    "@esbuild/linux-arm": ["@esbuild/linux-arm@0.27.2", "", { "os": "linux", "cpu": "arm" }, "sha512-vWfq4GaIMP9AIe4yj1ZUW18RDhx6EPQKjwe7n8BbIecFtCQG4CfHGaHuh7fdfq+y3LIA2vGS/o9ZBGVxIDi9hw=="],
-
-    "@esbuild/linux-arm64": ["@esbuild/linux-arm64@0.27.2", "", { "os": "linux", "cpu": "arm64" }, "sha512-hYxN8pr66NsCCiRFkHUAsxylNOcAQaxSSkHMMjcpx0si13t1LHFphxJZUiGwojB1a/Hd5OiPIqDdXONia6bhTw=="],
-
-    "@esbuild/linux-ia32": ["@esbuild/linux-ia32@0.27.2", "", { "os": "linux", "cpu": "ia32" }, "sha512-MJt5BRRSScPDwG2hLelYhAAKh9imjHK5+NE/tvnRLbIqUWa+0E9N4WNMjmp/kXXPHZGqPLxggwVhz7QP8CTR8w=="],
-
-    "@esbuild/linux-loong64": ["@esbuild/linux-loong64@0.27.2", "", { "os": "linux", "cpu": "none" }, "sha512-lugyF1atnAT463aO6KPshVCJK5NgRnU4yb3FUumyVz+cGvZbontBgzeGFO1nF+dPueHD367a2ZXe1NtUkAjOtg=="],
-
-    "@esbuild/linux-mips64el": ["@esbuild/linux-mips64el@0.27.2", "", { "os": "linux", "cpu": "none" }, "sha512-nlP2I6ArEBewvJ2gjrrkESEZkB5mIoaTswuqNFRv/WYd+ATtUpe9Y09RnJvgvdag7he0OWgEZWhviS1OTOKixw=="],
-
-    "@esbuild/linux-ppc64": ["@esbuild/linux-ppc64@0.27.2", "", { "os": "linux", "cpu": "ppc64" }, "sha512-C92gnpey7tUQONqg1n6dKVbx3vphKtTHJaNG2Ok9lGwbZil6DrfyecMsp9CrmXGQJmZ7iiVXvvZH6Ml5hL6XdQ=="],
-
-    "@esbuild/linux-riscv64": ["@esbuild/linux-riscv64@0.27.2", "", { "os": "linux", "cpu": "none" }, "sha512-B5BOmojNtUyN8AXlK0QJyvjEZkWwy/FKvakkTDCziX95AowLZKR6aCDhG7LeF7uMCXEJqwa8Bejz5LTPYm8AvA=="],
-
-    "@esbuild/linux-s390x": ["@esbuild/linux-s390x@0.27.2", "", { "os": "linux", "cpu": "s390x" }, "sha512-p4bm9+wsPwup5Z8f4EpfN63qNagQ47Ua2znaqGH6bqLlmJ4bx97Y9JdqxgGZ6Y8xVTixUnEkoKSHcpRlDnNr5w=="],
-
-    "@esbuild/linux-x64": ["@esbuild/linux-x64@0.27.2", "", { "os": "linux", "cpu": "x64" }, "sha512-uwp2Tip5aPmH+NRUwTcfLb+W32WXjpFejTIOWZFw/v7/KnpCDKG66u4DLcurQpiYTiYwQ9B7KOeMJvLCu/OvbA=="],
-
-    "@esbuild/netbsd-arm64": ["@esbuild/netbsd-arm64@0.27.2", "", { "os": "none", "cpu": "arm64" }, "sha512-Kj6DiBlwXrPsCRDeRvGAUb/LNrBASrfqAIok+xB0LxK8CHqxZ037viF13ugfsIpePH93mX7xfJp97cyDuTZ3cw=="],
-
-    "@esbuild/netbsd-x64": ["@esbuild/netbsd-x64@0.27.2", "", { "os": "none", "cpu": "x64" }, "sha512-HwGDZ0VLVBY3Y+Nw0JexZy9o/nUAWq9MlV7cahpaXKW6TOzfVno3y3/M8Ga8u8Yr7GldLOov27xiCnqRZf0tCA=="],
-
-    "@esbuild/openbsd-arm64": ["@esbuild/openbsd-arm64@0.27.2", "", { "os": "openbsd", "cpu": "arm64" }, "sha512-DNIHH2BPQ5551A7oSHD0CKbwIA/Ox7+78/AWkbS5QoRzaqlev2uFayfSxq68EkonB+IKjiuxBFoV8ESJy8bOHA=="],
-
-    "@esbuild/openbsd-x64": ["@esbuild/openbsd-x64@0.27.2", "", { "os": "openbsd", "cpu": "x64" }, "sha512-/it7w9Nb7+0KFIzjalNJVR5bOzA9Vay+yIPLVHfIQYG/j+j9VTH84aNB8ExGKPU4AzfaEvN9/V4HV+F+vo8OEg=="],
-
-    "@esbuild/openharmony-arm64": ["@esbuild/openharmony-arm64@0.27.2", "", { "os": "none", "cpu": "arm64" }, "sha512-LRBbCmiU51IXfeXk59csuX/aSaToeG7w48nMwA6049Y4J4+VbWALAuXcs+qcD04rHDuSCSRKdmY63sruDS5qag=="],
-
-    "@esbuild/sunos-x64": ["@esbuild/sunos-x64@0.27.2", "", { "os": "sunos", "cpu": "x64" }, "sha512-kMtx1yqJHTmqaqHPAzKCAkDaKsffmXkPHThSfRwZGyuqyIeBvf08KSsYXl+abf5HDAPMJIPnbBfXvP2ZC2TfHg=="],
-
-    "@esbuild/win32-arm64": ["@esbuild/win32-arm64@0.27.2", "", { "os": "win32", "cpu": "arm64" }, "sha512-Yaf78O/B3Kkh+nKABUF++bvJv5Ijoy9AN1ww904rOXZFLWVc5OLOfL56W+C8F9xn5JQZa3UX6m+IktJnIb1Jjg=="],
-
-    "@esbuild/win32-ia32": ["@esbuild/win32-ia32@0.27.2", "", { "os": "win32", "cpu": "ia32" }, "sha512-Iuws0kxo4yusk7sw70Xa2E2imZU5HoixzxfGCdxwBdhiDgt9vX9VUCBhqcwY7/uh//78A1hMkkROMJq9l27oLQ=="],
-
-    "@esbuild/win32-x64": ["@esbuild/win32-x64@0.27.2", "", { "os": "win32", "cpu": "x64" }, "sha512-sRdU18mcKf7F+YgheI/zGf5alZatMUTKj/jNS6l744f9u3WFu4v7twcUI9vu4mknF4Y9aDlblIie0IM+5xxaqQ=="],
-
-    "@floating-ui/core": ["@floating-ui/core@1.7.3", "", { "dependencies": { "@floating-ui/utils": "^0.2.10" } }, "sha512-sGnvb5dmrJaKEZ+LDIpguvdX3bDlEllmv4/ClQ9awcmCZrlx5jQyyMWFM5kBI+EyNOCDDiKk8il0zeuX3Zlg/w=="],
-
-    "@floating-ui/dom": ["@floating-ui/dom@1.7.4", "", { "dependencies": { "@floating-ui/core": "^1.7.3", "@floating-ui/utils": "^0.2.10" } }, "sha512-OOchDgh4F2CchOX94cRVqhvy7b3AFb+/rQXyswmzmGakRfkMgoWVjfnLWkRirfLEfuD4ysVW16eXzwt3jHIzKA=="],
-
-    "@floating-ui/react-dom": ["@floating-ui/react-dom@2.1.6", "", { "dependencies": { "@floating-ui/dom": "^1.7.4" }, "peerDependencies": { "react": ">=16.8.0", "react-dom": ">=16.8.0" } }, "sha512-4JX6rEatQEvlmgU80wZyq9RT96HZJa88q8hp0pBd+LrczeDI4o6uA2M+uvxngVHo4Ihr8uibXxH6+70zhAFrVw=="],
-
-    "@floating-ui/utils": ["@floating-ui/utils@0.2.10", "", {}, "sha512-aGTxbpbg8/b5JfU1HXSrbH3wXZuLPJcNEcZQFMxLs3oSzgtVu6nFPkbbGGUvBcUjKV2YyB9Wxxabo+HEH9tcRQ=="],
-
-    "@isaacs/balanced-match": ["@isaacs/balanced-match@4.0.1", "", {}, "sha512-yzMTt9lEb8Gv7zRioUilSglI0c0smZ9k5D65677DLWLtWJaXIS3CqcGyUFByYKlnUj6TkjLVs54fBl6+TiGQDQ=="],
-
-    "@isaacs/brace-expansion": ["@isaacs/brace-expansion@5.0.0", "", { "dependencies": { "@isaacs/balanced-match": "^4.0.1" } }, "sha512-ZT55BDLV0yv0RBm2czMiZ+SqCGO7AvmOM3G/w2xhVPH+te0aKgFjmBvGlL1dH+ql2tgGO3MVrbb3jCKyvpgnxA=="],
-
-    "@oven/bun-darwin-aarch64": ["@oven/bun-darwin-aarch64@1.3.6", "", { "os": "darwin", "cpu": "arm64" }, "sha512-27rypIapNkYboOSylkf1tD9UW9Ado2I+P1NBL46Qz29KmOjTL6WuJ7mHDC5O66CYxlOkF5r93NPDAC3lFHYBXw=="],
-
-    "@oven/bun-darwin-x64": ["@oven/bun-darwin-x64@1.3.6", "", { "os": "darwin", "cpu": "x64" }, "sha512-I82xGzPkBxzBKgbl8DsA0RfMQCWTWjNmLjIEkW1ECiv3qK02kHGQ5FGUr/29L/SuvnGsULW4tBTRNZiMzL37nA=="],
-
-    "@oven/bun-darwin-x64-baseline": ["@oven/bun-darwin-x64-baseline@1.3.6", "", { "os": "darwin", "cpu": "x64" }, "sha512-nqtr+pTsHqusYpG2OZc6s+AmpWDB/FmBvstrK0y5zkti4OqnCuu7Ev2xNjS7uyb47NrAFF40pWqkpaio5XEd7w=="],
-
-    "@oven/bun-linux-aarch64": ["@oven/bun-linux-aarch64@1.3.6", "", { "os": "linux", "cpu": "arm64" }, "sha512-YaQEAYjBanoOOtpqk/c5GGcfZIyxIIkQ2m1TbHjedRmJNwxzWBhGinSARFkrRIc3F8pRIGAopXKvJ/2rjN1LzQ=="],
-
-    "@oven/bun-linux-aarch64-musl": ["@oven/bun-linux-aarch64-musl@1.3.6", "", { "os": "linux", "cpu": "arm64" }, "sha512-FR+iJt17rfFgYgpxL3M67AUwujOgjw52ZJzB9vElI5jQXNjTyOKf8eH4meSk4vjlYF3h/AjKYd6pmN0OIUlVKQ=="],
-
-    "@oven/bun-linux-x64": ["@oven/bun-linux-x64@1.3.6", "", { "os": "linux", "cpu": "x64" }, "sha512-egfngj0dfJ868cf30E7B+ye9KUWSebYxOG4l9YP5eWeMXCtenpenx0zdKtAn9qxJgEJym5AN6trtlk+J6x8Lig=="],
-
-    "@oven/bun-linux-x64-baseline": ["@oven/bun-linux-x64-baseline@1.3.6", "", { "os": "linux", "cpu": "x64" }, "sha512-jRmnX18ak8WzqLrex3siw0PoVKyIeI5AiCv4wJLgSs7VKfOqrPycfHIWfIX2jdn7ngqbHFPzI09VBKANZ4Pckg=="],
-
-    "@oven/bun-linux-x64-musl": ["@oven/bun-linux-x64-musl@1.3.6", "", { "os": "linux", "cpu": "x64" }, "sha512-YeXcJ9K6vJAt1zSkeA21J6pTe7PgDMLTHKGI3nQBiMYnYf7Ob3K+b/ChSCznrJG7No5PCPiQPg4zTgA+BOTmSA=="],
-
-    "@oven/bun-linux-x64-musl-baseline": ["@oven/bun-linux-x64-musl-baseline@1.3.6", "", { "os": "linux", "cpu": "x64" }, "sha512-7FjVnxnRTp/AgWqSQRT/Vt9TYmvnZ+4M+d9QOKh/Lf++wIFXFGSeAgD6bV1X/yr2UPVmZDk+xdhr2XkU7l2v3w=="],
-
-    "@oven/bun-windows-x64": ["@oven/bun-windows-x64@1.3.6", "", { "os": "win32", "cpu": "x64" }, "sha512-Sr1KwUcbB0SEpnSPO22tNJppku2khjFluEst+mTGhxHzAGQTQncNeJxDnt3F15n+p9Q+mlcorxehd68n1siikQ=="],
-
-    "@oven/bun-windows-x64-baseline": ["@oven/bun-windows-x64-baseline@1.3.6", "", { "os": "win32", "cpu": "x64" }, "sha512-PFUa7JL4lGoyyppeS4zqfuoXXih+gSE0XxhDMrCPVEUev0yhGNd/tbWBvcdpYnUth80owENoGjc8s5Knopv9wA=="],
-
-    "@radix-ui/number": ["@radix-ui/number@1.1.1", "", {}, "sha512-MkKCwxlXTgz6CFoJx3pCwn07GKp36+aZyu/u2Ln2VrA5DcdyCZkASEDBTd8x5whTQQL5CiYf4prXKLcgQdv29g=="],
-
-    "@radix-ui/primitive": ["@radix-ui/primitive@1.1.3", "", {}, "sha512-JTF99U/6XIjCBo0wqkU5sK10glYe27MRRsfwoiq5zzOEZLHU3A3KCMa5X/azekYRCJ0HlwI0crAXS/5dEHTzDg=="],
-
-    "@radix-ui/react-arrow": ["@radix-ui/react-arrow@1.1.7", "", { "dependencies": { "@radix-ui/react-primitive": "2.1.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-F+M1tLhO+mlQaOWspE8Wstg+z6PwxwRd8oQ8IXceWz92kfAmalTRf0EjrouQeo7QssEPfCn05B4Ihs1K9WQ/7w=="],
-
-    "@radix-ui/react-collection": ["@radix-ui/react-collection@1.1.7", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-context": "1.1.2", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-Fh9rGN0MoI4ZFUNyfFVNU4y9LUz93u9/0K+yLgA2bwRojxM8JU1DyvvMBabnZPBgMWREAJvU2jjVzq+LrFUglw=="],
-
-    "@radix-ui/react-compose-refs": ["@radix-ui/react-compose-refs@1.1.2", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-z4eqJvfiNnFMHIIvXP3CY57y2WJs5g2v3X0zm9mEJkrkNv4rDxu+sg9Jh8EkXyeqBkB7SOcboo9dMVqhyrACIg=="],
-
-    "@radix-ui/react-context": ["@radix-ui/react-context@1.1.2", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-jCi/QKUM2r1Ju5a3J64TH2A5SpKAgh0LpknyqdQ4m6DCV0xJ2HG1xARRwNGPQfi1SLdLWZ1OJz6F4OMBBNiGJA=="],
-
-    "@radix-ui/react-direction": ["@radix-ui/react-direction@1.1.1", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-1UEWRX6jnOA2y4H5WczZ44gOOjTEmlqv1uNW4GAJEO5+bauCBhv8snY65Iw5/VOS/ghKN9gr2KjnLKxrsvoMVw=="],
-
-    "@radix-ui/react-dismissable-layer": ["@radix-ui/react-dismissable-layer@1.1.11", "", { "dependencies": { "@radix-ui/primitive": "1.1.3", "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-use-callback-ref": "1.1.1", "@radix-ui/react-use-escape-keydown": "1.1.1" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-Nqcp+t5cTB8BinFkZgXiMJniQH0PsUt2k51FUhbdfeKvc4ACcG2uQniY/8+h1Yv6Kza4Q7lD7PQV0z0oicE0Mg=="],
-
-    "@radix-ui/react-focus-guards": ["@radix-ui/react-focus-guards@1.1.3", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-0rFg/Rj2Q62NCm62jZw0QX7a3sz6QCQU0LpZdNrJX8byRGaGVTqbrW9jAoIAHyMQqsNpeZ81YgSizOt5WXq0Pw=="],
-
-    "@radix-ui/react-focus-scope": ["@radix-ui/react-focus-scope@1.1.7", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-use-callback-ref": "1.1.1" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-t2ODlkXBQyn7jkl6TNaw/MtVEVvIGelJDCG41Okq/KwUsJBwQ4XVZsHAVUkK4mBv3ewiAS3PGuUWuY2BoK4ZUw=="],
-
-    "@radix-ui/react-id": ["@radix-ui/react-id@1.1.1", "", { "dependencies": { "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-kGkGegYIdQsOb4XjsfM97rXsiHaBwco+hFI66oO4s9LU+PLAC5oJ7khdOVFxkhsmlbpUqDAvXw11CluXP+jkHg=="],
-
-    "@radix-ui/react-label": ["@radix-ui/react-label@2.1.8", "", { "dependencies": { "@radix-ui/react-primitive": "2.1.4" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-FmXs37I6hSBVDlO4y764TNz1rLgKwjJMQ0EGte6F3Cb3f4bIuHB/iLa/8I9VKkmOy+gNHq8rql3j686ACVV21A=="],
-
-    "@radix-ui/react-popper": ["@radix-ui/react-popper@1.2.8", "", { "dependencies": { "@floating-ui/react-dom": "^2.0.0", "@radix-ui/react-arrow": "1.1.7", "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-context": "1.1.2", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-use-callback-ref": "1.1.1", "@radix-ui/react-use-layout-effect": "1.1.1", "@radix-ui/react-use-rect": "1.1.1", "@radix-ui/react-use-size": "1.1.1", "@radix-ui/rect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-0NJQ4LFFUuWkE7Oxf0htBKS6zLkkjBH+hM1uk7Ng705ReR8m/uelduy1DBo0PyBXPKVnBA6YBlU94MBGXrSBCw=="],
-
-    "@radix-ui/react-portal": ["@radix-ui/react-portal@1.1.9", "", { "dependencies": { "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-bpIxvq03if6UNwXZ+HTK71JLh4APvnXntDc6XOX8UVq4XQOVl7lwok0AvIl+b8zgCw3fSaVTZMpAPPagXbKmHQ=="],
-
-    "@radix-ui/react-presence": ["@radix-ui/react-presence@1.1.5", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-/jfEwNDdQVBCNvjkGit4h6pMOzq8bHkopq458dPt2lMjx+eBQUohZNG9A7DtO/O5ukSbxuaNGXMjHicgwy6rQQ=="],
-
-    "@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.4", "", { "dependencies": { "@radix-ui/react-slot": "1.2.4" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-9hQc4+GNVtJAIEPEqlYqW5RiYdrr8ea5XQ0ZOnD6fgru+83kqT15mq2OCcbe8KnjRZl5vF3ks69AKz3kh1jrhg=="],
-
-    "@radix-ui/react-select": ["@radix-ui/react-select@2.2.6", "", { "dependencies": { "@radix-ui/number": "1.1.1", "@radix-ui/primitive": "1.1.3", "@radix-ui/react-collection": "1.1.7", "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-context": "1.1.2", "@radix-ui/react-direction": "1.1.1", "@radix-ui/react-dismissable-layer": "1.1.11", "@radix-ui/react-focus-guards": "1.1.3", "@radix-ui/react-focus-scope": "1.1.7", "@radix-ui/react-id": "1.1.1", "@radix-ui/react-popper": "1.2.8", "@radix-ui/react-portal": "1.1.9", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-slot": "1.2.3", "@radix-ui/react-use-callback-ref": "1.1.1", "@radix-ui/react-use-controllable-state": "1.2.2", "@radix-ui/react-use-layout-effect": "1.1.1", "@radix-ui/react-use-previous": "1.1.1", "@radix-ui/react-visually-hidden": "1.2.3", "aria-hidden": "^1.2.4", "react-remove-scroll": "^2.6.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-I30RydO+bnn2PQztvo25tswPH+wFBjehVGtmagkU78yMdwTwVf12wnAOF+AeP8S2N8xD+5UPbGhkUfPyvT+mwQ=="],
-
-    "@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.4", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Jl+bCv8HxKnlTLVrcDE8zTMJ09R9/ukw4qBs/oZClOfoQk/cOTbDn+NceXfV7j09YPVQUryJPHurafcSg6EVKA=="],
-
-    "@radix-ui/react-tooltip": ["@radix-ui/react-tooltip@1.2.8", "", { "dependencies": { "@radix-ui/primitive": "1.1.3", "@radix-ui/react-compose-refs": "1.1.2", "@radix-ui/react-context": "1.1.2", "@radix-ui/react-dismissable-layer": "1.1.11", "@radix-ui/react-id": "1.1.1", "@radix-ui/react-popper": "1.2.8", "@radix-ui/react-portal": "1.1.9", "@radix-ui/react-presence": "1.1.5", "@radix-ui/react-primitive": "2.1.3", "@radix-ui/react-slot": "1.2.3", "@radix-ui/react-use-controllable-state": "1.2.2", "@radix-ui/react-visually-hidden": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-tY7sVt1yL9ozIxvmbtN5qtmH2krXcBCfjEiCgKGLqunJHvgvZG2Pcl2oQ3kbcZARb1BGEHdkLzcYGO8ynVlieg=="],
-
-    "@radix-ui/react-use-callback-ref": ["@radix-ui/react-use-callback-ref@1.1.1", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-FkBMwD+qbGQeMu1cOHnuGB6x4yzPjho8ap5WtbEJ26umhgqVXbhekKUQO+hZEL1vU92a3wHwdp0HAcqAUF5iDg=="],
-
-    "@radix-ui/react-use-controllable-state": ["@radix-ui/react-use-controllable-state@1.2.2", "", { "dependencies": { "@radix-ui/react-use-effect-event": "0.0.2", "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-BjasUjixPFdS+NKkypcyyN5Pmg83Olst0+c6vGov0diwTEo6mgdqVR6hxcEgFuh4QrAs7Rc+9KuGJ9TVCj0Zzg=="],
-
-    "@radix-ui/react-use-effect-event": ["@radix-ui/react-use-effect-event@0.0.2", "", { "dependencies": { "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Qp8WbZOBe+blgpuUT+lw2xheLP8q0oatc9UpmiemEICxGvFLYmHm9QowVZGHtJlGbS6A6yJ3iViad/2cVjnOiA=="],
-
-    "@radix-ui/react-use-escape-keydown": ["@radix-ui/react-use-escape-keydown@1.1.1", "", { "dependencies": { "@radix-ui/react-use-callback-ref": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Il0+boE7w/XebUHyBjroE+DbByORGR9KKmITzbR7MyQ4akpORYP/ZmbhAr0DG7RmmBqoOnZdy2QlvajJ2QA59g=="],
-
-    "@radix-ui/react-use-layout-effect": ["@radix-ui/react-use-layout-effect@1.1.1", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-RbJRS4UWQFkzHTTwVymMTUv8EqYhOp8dOOviLj2ugtTiXRaRQS7GLGxZTLL1jWhMeoSCf5zmcZkqTl9IiYfXcQ=="],
-
-    "@radix-ui/react-use-previous": ["@radix-ui/react-use-previous@1.1.1", "", { "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-2dHfToCj/pzca2Ck724OZ5L0EVrr3eHRNsG/b3xQJLA2hZpVCS99bLAX+hm1IHXDEnzU6by5z/5MIY794/a8NQ=="],
-
-    "@radix-ui/react-use-rect": ["@radix-ui/react-use-rect@1.1.1", "", { "dependencies": { "@radix-ui/rect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-QTYuDesS0VtuHNNvMh+CjlKJ4LJickCMUAqjlE3+j8w+RlRpwyX3apEQKGFzbZGdo7XNG1tXa+bQqIE7HIXT2w=="],
-
-    "@radix-ui/react-use-size": ["@radix-ui/react-use-size@1.1.1", "", { "dependencies": { "@radix-ui/react-use-layout-effect": "1.1.1" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-ewrXRDTAqAXlkl6t/fkXWNAhFX9I+CkKlw6zjEwk86RSPKwZr3xpBRso655aqYafwtnbpHLj6toFzmd6xdVptQ=="],
-
-    "@radix-ui/react-visually-hidden": ["@radix-ui/react-visually-hidden@1.2.3", "", { "dependencies": { "@radix-ui/react-primitive": "2.1.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-pzJq12tEaaIhqjbzpCuv/OypJY/BPavOofm+dbab+MHLajy277+1lLm6JFcGgF5eskJ6mquGirhXY2GD/8u8Ug=="],
-
-    "@radix-ui/rect": ["@radix-ui/rect@1.1.1", "", {}, "sha512-HPwpGIzkl28mWyZqG52jiqDJ12waP11Pa1lGoiyUkIEuMLBP0oeK/C89esbXrxsky5we7dfd8U58nm0SgAWpVw=="],
-
-    "@teppeis/multimaps": ["@teppeis/multimaps@3.0.0", "", {}, "sha512-ID7fosbc50TbT0MK0EG12O+gAP3W3Aa/Pz4DaTtQtEvlc9Odaqi0de+xuZ7Li2GtK4HzEX7IuRWS/JmZLksR3Q=="],
-
-    "@types/bun": ["@types/bun@1.3.6", "", { "dependencies": { "bun-types": "1.3.6" } }, "sha512-uWCv6FO/8LcpREhenN1d1b6fcspAB+cefwD7uti8C8VffIv0Um08TKMn98FynpTiU38+y2dUO55T11NgDt8VAA=="],
-
-    "@types/chai": ["@types/chai@5.2.3", "", { "dependencies": { "@types/deep-eql": "*", "assertion-error": "^2.0.1" } }, "sha512-Mw558oeA9fFbv65/y4mHtXDs9bPnFMZAL/jxdPFUpOHHIXX91mcgEHbS5Lahr+pwZFR8A7GQleRWeI6cGFC2UA=="],
-
-    "@types/deep-eql": ["@types/deep-eql@4.0.2", "", {}, "sha512-c9h9dVVMigMPc4bwTvC5dxqtqJZwQPePsWjPlpSOnojbor6pGqdk541lfA7AqFQr5pB1BRdq0juY9db81BwyFw=="],
-
-    "@types/node": ["@types/node@25.0.9", "", { "dependencies": { "undici-types": "~7.16.0" } }, "sha512-/rpCXHlCWeqClNBwUhDcusJxXYDjZTyE8v5oTO7WbL8eij2nKhUeU89/6xgjU7N4/Vh3He0BtyhJdQbDyhiXAw=="],
-
-    "@types/normalize-package-data": ["@types/normalize-package-data@2.4.4", "", {}, "sha512-37i+OaWTh9qeK4LSHPsyRC7NahnGotNuZvjLSgcPzblpHB3rrCJxAOgI5gCdKm7coonsaX1Of0ILiTcnZjbfxA=="],
-
-    "@types/react": ["@types/react@19.2.8", "", { "dependencies": { "csstype": "^3.2.2" } }, "sha512-3MbSL37jEchWZz2p2mjntRZtPt837ij10ApxKfgmXCTuHWagYg7iA5bqPw6C8BMPfwidlvfPI/fxOc42HLhcyg=="],
-
-    "@types/react-dom": ["@types/react-dom@19.2.3", "", { "peerDependencies": { "@types/react": "^19.2.0" } }, "sha512-jp2L/eY6fn+KgVVQAOqYItbF0VY/YApe5Mz2F0aykSO8gx31bYCZyvSeYxCHKvzHG5eZjc+zyaS5BrBWya2+kQ=="],
-
-    "@types/uuid": ["@types/uuid@10.0.0", "", {}, "sha512-7gqG38EyHgyP1S+7+xomFtL+ZNHcKv6DwNaCZmJmo1vgMugyF3TCnXVg4t1uk89mLNwnLtnY3TpOpCOyp1/xHQ=="],
-
-    "ansi-regex": ["ansi-regex@4.1.1", "", {}, "sha512-ILlv4k/3f6vfQ4OoP2AGvirOktlQ98ZEL1k9FaQjxa3L1abBgbuTDAdPOpvbGncC0BTVQrl+OM8xZGK6tWXt7g=="],
-
-    "ansi-styles": ["ansi-styles@5.2.0", "", {}, "sha512-Cxwpt2SfTzTtXcfOlzGEee8O+c+MmUgGrNiBcXnuWxuFJHe6a5Hz7qwhwe5OgaSYI0IJvkLqWX1ASG+cJOkEiA=="],
-
-    "any-promise": ["any-promise@1.3.0", "", {}, "sha512-7UvmKalWRt1wgjL1RrGxoSJW/0QZFIegpeGvZG9kjp8vrRu55XTHbwnqq2GpXm9uLbcuhxm3IqX9OB4MZR1b2A=="],
-
-    "aria-hidden": ["aria-hidden@1.2.6", "", { "dependencies": { "tslib": "^2.0.0" } }, "sha512-ik3ZgC9dY/lYVVM++OISsaYDeg1tb0VtP5uL3ouh1koGOaUMDPpbFIei4JkFimWUFPn90sbMNMXQAIVOlnYKJA=="],
-
-    "assertion-error": ["assertion-error@2.0.1", "", {}, "sha512-Izi8RQcffqCeNVgFigKli1ssklIbpHnCYc6AknXGYoB6grJqyeby7jv12JUQgmTAnIDnbck1uxksT4dzN3PWBA=="],
-
-    "assertion-error-formatter": ["assertion-error-formatter@3.0.0", "", { "dependencies": { "diff": "^4.0.1", "pad-right": "^0.2.2", "repeat-string": "^1.6.1" } }, "sha512-6YyAVLrEze0kQ7CmJfUgrLHb+Y7XghmL2Ie7ijVa2Y9ynP3LV+VDiwFk62Dn0qtqbmY0BT0ss6p1xxpiF2PYbQ=="],
-
-    "buffer-from": ["buffer-from@1.1.2", "", {}, "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ=="],
-
-    "bun": ["bun@1.3.6", "", { "optionalDependencies": { "@oven/bun-darwin-aarch64": "1.3.6", "@oven/bun-darwin-x64": "1.3.6", "@oven/bun-darwin-x64-baseline": "1.3.6", "@oven/bun-linux-aarch64": "1.3.6", "@oven/bun-linux-aarch64-musl": "1.3.6", "@oven/bun-linux-x64": "1.3.6", "@oven/bun-linux-x64-baseline": "1.3.6", "@oven/bun-linux-x64-musl": "1.3.6", "@oven/bun-linux-x64-musl-baseline": "1.3.6", "@oven/bun-windows-x64": "1.3.6", "@oven/bun-windows-x64-baseline": "1.3.6" }, "os": [ "linux", "win32", "darwin", ], "cpu": [ "x64", "arm64", ], "bin": { "bun": "bin/bun.exe", "bunx": "bin/bunx.exe" } }, "sha512-Tn98GlZVN2WM7+lg/uGn5DzUao37Yc0PUz7yzYHdeF5hd+SmHQGbCUIKE4Sspdgtxn49LunK3mDNBC2Qn6GJjw=="],
-
-    "bun-plugin-tailwind": ["bun-plugin-tailwind@0.1.2", "", { "peerDependencies": { "bun": ">=1.0.0" } }, "sha512-41jNC1tZRSK3s1o7pTNrLuQG8kL/0vR/JgiTmZAJ1eHwe0w5j6HFPKeqEk0WAD13jfrUC7+ULuewFBBCoADPpg=="],
-
-    "bun-types": ["bun-types@1.3.6", "", { "dependencies": { "@types/node": "*" } }, "sha512-OlFwHcnNV99r//9v5IIOgQ9Uk37gZqrNMCcqEaExdkVq3Avwqok1bJFmvGMCkCE0FqzdY8VMOZpfpR3lwI+CsQ=="],
-
-    "capital-case": ["capital-case@1.0.4", "", { "dependencies": { "no-case": "^3.0.4", "tslib": "^2.0.3", "upper-case-first": "^2.0.2" } }, "sha512-ds37W8CytHgwnhGGTi88pcPyR15qoNkOpYwmMMfnWqqWgESapLqvDx6huFjQ5vqWSn2Z06173XNA7LtMOeUh1A=="],
-
-    "chai": ["chai@6.2.2", "", {}, "sha512-NUPRluOfOiTKBKvWPtSD4PhFvWCqOi0BGStNWs57X9js7XGTprSmFoz5F0tWhR4WPjNeR9jXqdC7/UpSJTnlRg=="],
-
-    "chalk": ["chalk@4.1.2", "", { "dependencies": { "ansi-styles": "^4.1.0", "supports-color": "^7.1.0" } }, "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA=="],
-
-    "class-transformer": ["class-transformer@0.5.1", "", {}, "sha512-SQa1Ws6hUbfC98vKGxZH3KFY0Y1lm5Zm0SY8XX9zbK7FJCyVEac3ATW0RIpwzW+oOfmHE5PMPufDG9hCfoEOMw=="],
-
-    "class-variance-authority": ["class-variance-authority@0.7.1", "", { "dependencies": { "clsx": "^2.1.1" } }, "sha512-Ka+9Trutv7G8M6WT6SeiRWz792K5qEqIGEGzXKhAE6xOWAY6pPH8U+9IY3oCMv6kqTmLsv7Xh/2w2RigkePMsg=="],
-
-    "cli-table3": ["cli-table3@0.6.5", "", { "dependencies": { "string-width": "^4.2.0" }, "optionalDependencies": { "@colors/colors": "1.5.0" } }, "sha512-+W/5efTR7y5HRD7gACw9yQjqMVvEMLBHmboM/kPWam+H+Hmyrgjh6YncVKK122YZkXrLudzTuAukUw9FnMf7IQ=="],
-
-    "clsx": ["clsx@2.1.1", "", {}, "sha512-eYm0QWBtUrBWZWG0d386OGAw16Z995PiOVo2B7bjWSbHedGl5e0ZWaq65kOGgUSNesEIDkB9ISbTg/JK9dhCZA=="],
-
-    "color-convert": ["color-convert@2.0.1", "", { "dependencies": { "color-name": "~1.1.4" } }, "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ=="],
-
-    "color-name": ["color-name@1.1.4", "", {}, "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA=="],
-
-    "commander": ["commander@14.0.2", "", {}, "sha512-TywoWNNRbhoD0BXs1P3ZEScW8W5iKrnbithIl0YH+uCmBd0QpPOA8yc82DS3BIE5Ma6FnBVUsJ7wVUDz4dvOWQ=="],
-
-    "csstype": ["csstype@3.2.3", "", {}, "sha512-z1HGKcYy2xA8AGQfwrn0PAy+PB7X/GSj3UVJW9qKyn43xWa+gl5nXmU4qqLMRzWVLFC8KusUX8T/0kCiOYpAIQ=="],
-
-    "debug": ["debug@4.4.3", "", { "dependencies": { "ms": "^2.1.3" } }, "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA=="],
-
-    "detect-node-es": ["detect-node-es@1.1.0", "", {}, "sha512-ypdmJU/TbBby2Dxibuv7ZLW3Bs1QEmM7nHjEANfohJLvE0XVujisn1qPJcZxg+qDucsr+bP6fLD1rPS3AhJ7EQ=="],
-
-    "diff": ["diff@4.0.2", "", {}, "sha512-58lmxKSA4BNyLz+HHMUzlOEpg09FV+ev6ZMe3vJihgdxzgcwZ8VoEEPmALCZG9LmqfVoNMMKpttIYTVG6uDY7A=="],
-
-    "emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="],
-
-    "error-stack-parser": ["error-stack-parser@2.1.4", "", { "dependencies": { "stackframe": "^1.3.4" } }, "sha512-Sk5V6wVazPhq5MhpO+AUxJn5x7XSXGl1R93Vn7i+zS15KDVxQijejNCrz8340/2bgLBjR9GtEG8ZVKONDjcqGQ=="],
-
-    "esbuild": ["esbuild@0.27.2", "", { "optionalDependencies": { "@esbuild/aix-ppc64": "0.27.2", "@esbuild/android-arm": "0.27.2", "@esbuild/android-arm64": "0.27.2", "@esbuild/android-x64": "0.27.2", "@esbuild/darwin-arm64": "0.27.2", "@esbuild/darwin-x64": "0.27.2", "@esbuild/freebsd-arm64": "0.27.2", "@esbuild/freebsd-x64": "0.27.2", "@esbuild/linux-arm": "0.27.2", "@esbuild/linux-arm64": "0.27.2", "@esbuild/linux-ia32": "0.27.2", "@esbuild/linux-loong64": "0.27.2", "@esbuild/linux-mips64el": "0.27.2", "@esbuild/linux-ppc64": "0.27.2", "@esbuild/linux-riscv64": "0.27.2", "@esbuild/linux-s390x": "0.27.2", "@esbuild/linux-x64": "0.27.2", "@esbuild/netbsd-arm64": "0.27.2", "@esbuild/netbsd-x64": "0.27.2", "@esbuild/openbsd-arm64": "0.27.2", "@esbuild/openbsd-x64": "0.27.2", "@esbuild/openharmony-arm64": "0.27.2", "@esbuild/sunos-x64": "0.27.2", "@esbuild/win32-arm64": "0.27.2", "@esbuild/win32-ia32": "0.27.2", "@esbuild/win32-x64": "0.27.2" }, "bin": { "esbuild": "bin/esbuild" } }, "sha512-HyNQImnsOC7X9PMNaCIeAm4ISCQXs5a5YasTXVliKv4uuBo1dKrG0A+uQS8M5eXjVMnLg3WgXaKvprHlFJQffw=="],
-
-    "escape-string-regexp": ["escape-string-regexp@1.0.5", "", {}, "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg=="],
-
-    "figures": ["figures@3.2.0", "", { "dependencies": { "escape-string-regexp": "^1.0.5" } }, "sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg=="],
-
-    "find-up-simple": ["find-up-simple@1.0.1", "", {}, "sha512-afd4O7zpqHeRyg4PfDQsXmlDe2PfdHtJt6Akt8jOWaApLOZk5JXs6VMR29lz03pRe9mpykrRCYIYxaJYcfpncQ=="],
-
-    "fsevents": ["fsevents@2.3.3", "", { "os": "darwin" }, "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw=="],
-
-    "get-nonce": ["get-nonce@1.0.1", "", {}, "sha512-FJhYRoDaiatfEkUK8HKlicmu/3SGFD51q3itKDGoSTysQJBnfOcxU5GxnhE1E6soB76MbT0MBtnKJuXyAx+96Q=="],
-
-    "get-tsconfig": ["get-tsconfig@4.13.0", "", { "dependencies": { "resolve-pkg-maps": "^1.0.0" } }, "sha512-1VKTZJCwBrvbd+Wn3AOgQP/2Av+TfTCOlE4AcRJE72W1ksZXbAx8PPBR9RzgTeSPzlPMHrbANMH3LbltH73wxQ=="],
-
-    "glob": ["glob@13.0.0", "", { "dependencies": { "minimatch": "^10.1.1", "minipass": "^7.1.2", "path-scurry": "^2.0.0" } }, "sha512-tvZgpqk6fz4BaNZ66ZsRaZnbHvP/jG3uKJvAZOwEVUL4RTA5nJeeLYfyN9/VA8NX/V3IBG+hkeuGpKjvELkVhA=="],
-
-    "global-dirs": ["global-dirs@3.0.1", "", { "dependencies": { "ini": "2.0.0" } }, "sha512-NBcGGFbBA9s1VzD41QXDG+3++t9Mn5t1FpLdhESY6oKY4gYTFpX4wO3sqGUa0Srjtbfj3szX0RnemmrVRUdULA=="],
-
-    "happy-dom": ["happy-dom@16.8.1", "", { "dependencies": { "webidl-conversions": "^7.0.0", "whatwg-mimetype": "^3.0.0" } }, "sha512-n0QrmT9lD81rbpKsyhnlz3DgnMZlaOkJPpgi746doA+HvaMC79bdWkwjrNnGJRvDrWTI8iOcJiVTJ5CdT/AZRw=="],
-
-    "has-ansi": ["has-ansi@4.0.1", "", { "dependencies": { "ansi-regex": "^4.1.0" } }, "sha512-Qr4RtTm30xvEdqUXbSBVWDu+PrTokJOwe/FU+VdfJPk+MXAPoeOzKpRyrDTnZIJwAkQ4oBLTU53nu0HrkF/Z2A=="],
-
-    "has-flag": ["has-flag@4.0.0", "", {}, "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ=="],
-
-    "hosted-git-info": ["hosted-git-info@9.0.2", "", { "dependencies": { "lru-cache": "^11.1.0" } }, "sha512-M422h7o/BR3rmCQ8UHi7cyyMqKltdP9Uo+J2fXK+RSAY+wTcKOIRyhTuKv4qn+DJf3g+PL890AzId5KZpX+CBg=="],
-
-    "indent-string": ["indent-string@4.0.0", "", {}, "sha512-EdDDZu4A2OyIK7Lr/2zG+w5jmbuk1DVBnEwREQvBzspBJkCEbRa8GxU1lghYcaGJCnRWibjDXlq779X1/y5xwg=="],
-
-    "index-to-position": ["index-to-position@1.2.0", "", {}, "sha512-Yg7+ztRkqslMAS2iFaU+Oa4KTSidr63OsFGlOrJoW981kIYO3CGCS3wA95P1mUi/IVSJkn0D479KTJpVpvFNuw=="],
-
-    "ini": ["ini@2.0.0", "", {}, "sha512-7PnF4oN3CvZF23ADhA5wRaYEQpJ8qygSkbtTXWBeXWXmEVRXK+1ITciHWwHhsjv1TmW0MgacIv6hEi5pX5NQdA=="],
-
-    "is-fullwidth-code-point": ["is-fullwidth-code-point@3.0.0", "", {}, "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg=="],
-
-    "is-installed-globally": ["is-installed-globally@0.4.0", "", { "dependencies": { "global-dirs": "^3.0.0", "is-path-inside": "^3.0.2" } }, "sha512-iwGqO3J21aaSkC7jWnHP/difazwS7SFeIqxv6wEtLU8Y5KlzFTjyqcSIT0d8s4+dDhKytsk9PJZ2BkS5eZwQRQ=="],
-
-    "is-path-inside": ["is-path-inside@3.0.3", "", {}, "sha512-Fd4gABb+ycGAmKou8eMftCupSir5lRxqf4aD/vd0cD2qc4HL07OjCeuHMr8Ro4CoMaeCKDB0/ECBOVWjTwUvPQ=="],
-
-    "is-stream": ["is-stream@2.0.1", "", {}, "sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg=="],
-
-    "js-tokens": ["js-tokens@4.0.0", "", {}, "sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ=="],
-
-    "knuth-shuffle-seeded": ["knuth-shuffle-seeded@1.0.6", "", { "dependencies": { "seed-random": "~2.2.0" } }, "sha512-9pFH0SplrfyKyojCLxZfMcvkhf5hH0d+UwR9nTVJ/DDQJGuzcXjTwB7TP7sDfehSudlGGaOLblmEWqv04ERVWg=="],
-
-    "lodash.merge": ["lodash.merge@4.6.2", "", {}, "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ=="],
-
-    "lodash.mergewith": ["lodash.mergewith@4.6.2", "", {}, "sha512-GK3g5RPZWTRSeLSpgP8Xhra+pnjBC56q9FZYe1d5RN3TJ35dbkGy3YqBSMbyCrlbi+CM9Z3Jk5yTL7RCsqboyQ=="],
-
-    "lodash.sortby": ["lodash.sortby@4.7.0", "", {}, "sha512-HDWXG8isMntAyRF5vZ7xKuEvOhT4AhlRt/3czTSjvGUxjYCBVRQY48ViDHyfYz9VIoBkW4TMGQNapx+l3RUwdA=="],
-
-    "lower-case": ["lower-case@2.0.2", "", { "dependencies": { "tslib": "^2.0.3" } }, "sha512-7fm3l3NAF9WfN6W3JOmf5drwpVqX78JtoGJ3A6W0a6ZnldM41w2fV5D490psKFTpMds8TJse/eHLFFsNHHjHgg=="],
-
-    "lru-cache": ["lru-cache@11.2.4", "", {}, "sha512-B5Y16Jr9LB9dHVkh6ZevG+vAbOsNOYCX+sXvFWFu7B3Iz5mijW3zdbMyhsh8ANd2mSWBYdJgnqi+mL7/LrOPYg=="],
-
-    "lucide-react": ["lucide-react@0.545.0", "", { "peerDependencies": { "react": "^16.5.1 || ^17.0.0 || ^18.0.0 || ^19.0.0" } }, "sha512-7r1/yUuflQDSt4f1bpn5ZAocyIxcTyVyBBChSVtBKn5M+392cPmI5YJMWOJKk/HUWGm5wg83chlAZtCcGbEZtw=="],
-
-    "luxon": ["luxon@3.7.2", "", {}, "sha512-vtEhXh/gNjI9Yg1u4jX/0YVPMvxzHuGgCm6tC5kZyb08yjGWGnqAjGJvcXbqQR2P3MyMEFnRbpcdFS6PBcLqew=="],
-
-    "mime": ["mime@3.0.0", "", { "bin": { "mime": "cli.js" } }, "sha512-jSCU7/VB1loIWBZe14aEYHU/+1UMEHoaO7qxCOVJOw9GgH72VAWppxNcjU+x9a2k3GSIBXNKxXQFqRvvZ7vr3A=="],
-
-    "minimatch": ["minimatch@10.1.1", "", { "dependencies": { "@isaacs/brace-expansion": "^5.0.0" } }, "sha512-enIvLvRAFZYXJzkCYG5RKmPfrFArdLv+R+lbQ53BmIMLIry74bjKzX6iHAm8WYamJkhSSEabrWN5D97XnKObjQ=="],
-
-    "minipass": ["minipass@7.1.2", "", {}, "sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw=="],
-
-    "mkdirp": ["mkdirp@3.0.1", "", { "bin": { "mkdirp": "dist/cjs/src/bin.js" } }, "sha512-+NsyUUAZDmo6YVHzL/stxSu3t9YS1iljliy3BSDrXJ/dkn1KYdmtZODGGjLcc9XLgVVpH4KshHB8XmZgMhaBXg=="],
-
-    "ms": ["ms@2.1.3", "", {}, "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA=="],
-
-    "mz": ["mz@2.7.0", "", { "dependencies": { "any-promise": "^1.0.0", "object-assign": "^4.0.1", "thenify-all": "^1.0.0" } }, "sha512-z81GNO7nnYMEhrGh9LeymoE4+Yr0Wn5McHIZMK5cfQCl+NDX08sCZgUc9/6MHni9IWuFLm1Z3HTCXu2z9fN62Q=="],
-
-    "no-case": ["no-case@3.0.4", "", { "dependencies": { "lower-case": "^2.0.2", "tslib": "^2.0.3" } }, "sha512-fgAN3jGAh+RoxUGZHTSOLJIqUc2wmoBwGR4tbpNAKmmovFoWq0OdRkb0VkldReO2a2iBT/OEulG9XSUc10r3zg=="],
-
-    "normalize-package-data": ["normalize-package-data@8.0.0", "", { "dependencies": { "hosted-git-info": "^9.0.0", "semver": "^7.3.5", "validate-npm-package-license": "^3.0.4" } }, "sha512-RWk+PI433eESQ7ounYxIp67CYuVsS1uYSonX3kA6ps/3LWfjVQa/ptEg6Y3T6uAMq1mWpX9PQ+qx+QaHpsc7gQ=="],
-
-    "object-assign": ["object-assign@4.1.1", "", {}, "sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg=="],
-
-    "pad-right": ["pad-right@0.2.2", "", { "dependencies": { "repeat-string": "^1.5.2" } }, "sha512-4cy8M95ioIGolCoMmm2cMntGR1lPLEbOMzOKu8bzjuJP6JpzEMQcDHmh7hHLYGgob+nKe1YHFMaG4V59HQa89g=="],
-
-    "parse-json": ["parse-json@8.3.0", "", { "dependencies": { "@babel/code-frame": "^7.26.2", "index-to-position": "^1.1.0", "type-fest": "^4.39.1" } }, "sha512-ybiGyvspI+fAoRQbIPRddCcSTV9/LsJbf0e/S85VLowVGzRmokfneg2kwVW/KU5rOXrPSbF1qAKPMgNTqqROQQ=="],
-
-    "path-scurry": ["path-scurry@2.0.1", "", { "dependencies": { "lru-cache": "^11.0.0", "minipass": "^7.1.2" } }, "sha512-oWyT4gICAu+kaA7QWk/jvCHWarMKNs6pXOGWKDTr7cw4IGcUbW+PeTfbaQiLGheFRpjo6O9J0PmyMfQPjH71oA=="],
-
-    "picocolors": ["picocolors@1.1.1", "", {}, "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA=="],
-
-    "progress": ["progress@2.0.3", "", {}, "sha512-7PiHtLll5LdnKIMw100I+8xJXR5gW2QwWYkT6iJva0bXitZKa/XMrSbdmg3r2Xnaidz9Qumd0VPaMrZlF9V9sA=="],
-
-    "property-expr": ["property-expr@2.0.6", "", {}, "sha512-SVtmxhRE/CGkn3eZY1T6pC8Nln6Fr/lu1mKSgRud0eC73whjGfoAogbn78LkD8aFL0zz3bAFerKSnOl7NlErBA=="],
-
-    "react": ["react@19.2.3", "", {}, "sha512-Ku/hhYbVjOQnXDZFv2+RibmLFGwFdeeKHFcOTlrt7xplBnya5OGn/hIRDsqDiSUcfORsDC7MPxwork8jBwsIWA=="],
-
-    "react-dom": ["react-dom@19.2.3", "", { "dependencies": { "scheduler": "^0.27.0" }, "peerDependencies": { "react": "^19.2.3" } }, "sha512-yELu4WmLPw5Mr/lmeEpox5rw3RETacE++JgHqQzd2dg+YbJuat3jH4ingc+WPZhxaoFzdv9y33G+F7Nl5O0GBg=="],
-
-    "react-remove-scroll": ["react-remove-scroll@2.7.2", "", { "dependencies": { "react-remove-scroll-bar": "^2.3.7", "react-style-singleton": "^2.2.3", "tslib": "^2.1.0", "use-callback-ref": "^1.3.3", "use-sidecar": "^1.1.3" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Iqb9NjCCTt6Hf+vOdNIZGdTiH1QSqr27H/Ek9sv/a97gfueI/5h1s3yRi1nngzMUaOOToin5dI1dXKdXiF+u0Q=="],
-
-    "react-remove-scroll-bar": ["react-remove-scroll-bar@2.3.8", "", { "dependencies": { "react-style-singleton": "^2.2.2", "tslib": "^2.0.0" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0" }, "optionalPeers": ["@types/react"] }, "sha512-9r+yi9+mgU33AKcj6IbT9oRCO78WriSj6t/cF8DWBZJ9aOGPOTEDvdUDz1FwKim7QXWwmHqtdHnRJfhAxEG46Q=="],
-
-    "react-style-singleton": ["react-style-singleton@2.2.3", "", { "dependencies": { "get-nonce": "^1.0.0", "tslib": "^2.0.0" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-b6jSvxvVnyptAiLjbkWLE/lOnR4lfTtDAl+eUC7RZy+QQWc6wRzIV2CE6xBuMmDxc2qIihtDCZD5NPOFl7fRBQ=="],
-
-    "read-package-up": ["read-package-up@12.0.0", "", { "dependencies": { "find-up-simple": "^1.0.1", "read-pkg": "^10.0.0", "type-fest": "^5.2.0" } }, "sha512-Q5hMVBYur/eQNWDdbF4/Wqqr9Bjvtrw2kjGxxBbKLbx8bVCL8gcArjTy8zDUuLGQicftpMuU0riQNcAsbtOVsw=="],
-
-    "read-pkg": ["read-pkg@10.0.0", "", { "dependencies": { "@types/normalize-package-data": "^2.4.4", "normalize-package-data": "^8.0.0", "parse-json": "^8.3.0", "type-fest": "^5.2.0", "unicorn-magic": "^0.3.0" } }, "sha512-A70UlgfNdKI5NSvTTfHzLQj7NJRpJ4mT5tGafkllJ4wh71oYuGm/pzphHcmW4s35iox56KSK721AihodoXSc/A=="],
-
-    "reflect-metadata": ["reflect-metadata@0.2.2", "", {}, "sha512-urBwgfrvVP/eAyXx4hluJivBKzuEbSQs9rKWCrCkbSxNv8mxPcUZKeuoF3Uy4mJl3Lwprp6yy5/39VWigZ4K6Q=="],
-
-    "regexp-match-indices": ["regexp-match-indices@1.0.2", "", { "dependencies": { "regexp-tree": "^0.1.11" } }, "sha512-DwZuAkt8NF5mKwGGER1EGh2PRqyvhRhhLviH+R8y8dIuaQROlUfXjt4s9ZTXstIsSkptf06BSvwcEmmfheJJWQ=="],
-
-    "regexp-tree": ["regexp-tree@0.1.27", "", { "bin": { "regexp-tree": "bin/regexp-tree" } }, "sha512-iETxpjK6YoRWJG5o6hXLwvjYAoW+FEZn9os0PD/b6AP6xQwsa/Y7lCVgIixBbUPMfhu+i2LtdeAqVTgGlQarfA=="],
-
-    "repeat-string": ["repeat-string@1.6.1", "", {}, "sha512-PV0dzCYDNfRi1jCDbJzpW7jNNDRuCOG/jI5ctQcGKt/clZD+YcPS3yIlWuTJMmESC8aevCFmWJy5wjAFgNqN6w=="],
-
-    "resolve-pkg-maps": ["resolve-pkg-maps@1.0.0", "", {}, "sha512-seS2Tj26TBVOC2NIc2rOe2y2ZO7efxITtLZcGSOnHHNOQ7CkiUBfw0Iw2ck6xkIhPwLhKNLS8BO+hEpngQlqzw=="],
-
-    "scheduler": ["scheduler@0.27.0", "", {}, "sha512-eNv+WrVbKu1f3vbYJT/xtiF5syA5HPIMtf9IgY/nKg0sWqzAUEvqY/xm7OcZc/qafLx/iO9FgOmeSAp4v5ti/Q=="],
-
-    "seed-random": ["seed-random@2.2.0", "", {}, "sha512-34EQV6AAHQGhoc0tn/96a9Fsi6v2xdqe/dMUwljGRaFOzR3EgRmECvD0O8vi8X+/uQ50LGHfkNu/Eue5TPKZkQ=="],
-
-    "semver": ["semver@7.7.3", "", { "bin": { "semver": "bin/semver.js" } }, "sha512-SdsKMrI9TdgjdweUSR9MweHA4EJ8YxHn8DFaDisvhVlUOe4BF1tLD7GAj0lIqWVl+dPb/rExr0Btby5loQm20Q=="],
-
-    "source-map": ["source-map@0.6.1", "", {}, "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="],
-
-    "source-map-support": ["source-map-support@0.5.21", "", { "dependencies": { "buffer-from": "^1.0.0", "source-map": "^0.6.0" } }, "sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w=="],
-
-    "spdx-correct": ["spdx-correct@3.2.0", "", { "dependencies": { "spdx-expression-parse": "^3.0.0", "spdx-license-ids": "^3.0.0" } }, "sha512-kN9dJbvnySHULIluDHy32WHRUu3Og7B9sbY7tsFLctQkIqnMh3hErYgdMjTYuqmcXX+lK5T1lnUt3G7zNswmZA=="],
-
-    "spdx-exceptions": ["spdx-exceptions@2.5.0", "", {}, "sha512-PiU42r+xO4UbUS1buo3LPJkjlO7430Xn5SVAhdpzzsPHsjbYVflnnFdATgabnLude+Cqu25p6N+g2lw/PFsa4w=="],
-
-    "spdx-expression-parse": ["spdx-expression-parse@3.0.1", "", { "dependencies": { "spdx-exceptions": "^2.1.0", "spdx-license-ids": "^3.0.0" } }, "sha512-cbqHunsQWnJNE6KhVSMsMeH5H/L9EpymbzqTQ3uLwNCLZ1Q481oWaofqH7nO6V07xlXwY6PhQdQ2IedWx/ZK4Q=="],
-
-    "spdx-license-ids": ["spdx-license-ids@3.0.22", "", {}, "sha512-4PRT4nh1EImPbt2jASOKHX7PB7I+e4IWNLvkKFDxNhJlfjbYlleYQh285Z/3mPTHSAK/AvdMmw5BNNuYH8ShgQ=="],
-
-    "stackframe": ["stackframe@1.3.4", "", {}, "sha512-oeVtt7eWQS+Na6F//S4kJ2K2VbRlS9D43mAlMyVpVWovy9o+jfgH8O9agzANzaiLjclA0oYzUXEM4PurhSUChw=="],
-
-    "string-argv": ["string-argv@0.3.1", "", {}, "sha512-a1uQGz7IyVy9YwhqjZIZu1c8JO8dNIe20xBmSS6qu9kv++k3JGzCVmprbNN5Kn+BgzD5E7YYwg1CcjuJMRNsvg=="],
-
-    "string-width": ["string-width@4.2.3", "", { "dependencies": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } }, "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g=="],
-
-    "strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="],
-
-    "supports-color": ["supports-color@8.1.1", "", { "dependencies": { "has-flag": "^4.0.0" } }, "sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q=="],
-
-    "tagged-tag": ["tagged-tag@1.0.0", "", {}, "sha512-yEFYrVhod+hdNyx7g5Bnkkb0G6si8HJurOoOEgC8B/O0uXLHlaey/65KRv6cuWBNhBgHKAROVpc7QyYqE5gFng=="],
-
-    "tailwind-merge": ["tailwind-merge@3.4.0", "", {}, "sha512-uSaO4gnW+b3Y2aWoWfFpX62vn2sR3skfhbjsEnaBI81WD1wBLlHZe5sWf0AqjksNdYTbGBEd0UasQMT3SNV15g=="],
-
-    "tailwindcss": ["tailwindcss@4.1.18", "", {}, "sha512-4+Z+0yiYyEtUVCScyfHCxOYP06L5Ne+JiHhY2IjR2KWMIWhJOYZKLSGZaP5HkZ8+bY0cxfzwDE5uOmzFXyIwxw=="],
-
-    "thenify": ["thenify@3.3.1", "", { "dependencies": { "any-promise": "^1.0.0" } }, "sha512-RVZSIV5IG10Hk3enotrhvz0T9em6cyHBLkH/YAZuKqd8hRkKhSfCGIcP2KUY0EPxndzANBmNllzWPwak+bheSw=="],
-
-    "thenify-all": ["thenify-all@1.6.0", "", { "dependencies": { "thenify": ">= 3.1.0 < 4" } }, "sha512-RNxQH/qI8/t3thXJDwcstUO4zeqo64+Uy/+sNVRBx4Xn2OX+OZ9oP+iJnNFqplFra2ZUVeKCSa2oVWi3T4uVmA=="],
-
-    "tiny-case": ["tiny-case@1.0.3", "", {}, "sha512-Eet/eeMhkO6TX8mnUteS9zgPbUMQa4I6Kkp5ORiBD5476/m+PIRiumP5tmh5ioJpH7k51Kehawy2UDfsnxxY8Q=="],
-
-    "toposort": ["toposort@2.0.2", "", {}, "sha512-0a5EOkAUp8D4moMi2W8ZF8jcga7BgZd91O/yabJCFY8az+XSzeGyTKs0Aoo897iV1Nj6guFq8orWDS96z91oGg=="],
-
-    "ts-dedent": ["ts-dedent@2.2.0", "", {}, "sha512-q5W7tVM71e2xjHZTlgfTDoPF/SmqKG5hddq9SzR49CH2hayqRKJtQ4mtRlSxKaJlR/+9rEM+mnBHf7I2/BQcpQ=="],
-
-    "tslib": ["tslib@2.8.1", "", {}, "sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w=="],
-
-    "tsx": ["tsx@4.21.0", "", { "dependencies": { "esbuild": "~0.27.0", "get-tsconfig": "^4.7.5" }, "optionalDependencies": { "fsevents": "~2.3.3" }, "bin": { "tsx": "dist/cli.mjs" } }, "sha512-5C1sg4USs1lfG0GFb2RLXsdpXqBSEhAaA/0kPL01wxzpMqLILNxIxIOKiILz+cdg/pLnOUxFYOR5yhHU666wbw=="],
-
-    "tw-animate-css": ["tw-animate-css@1.4.0", "", {}, "sha512-7bziOlRqH0hJx80h/3mbicLW7o8qLsH5+RaLR2t+OHM3D0JlWGODQKQ4cxbK7WlvmUxpcj6Kgu6EKqjrGFe3QQ=="],
-
-    "type-fest": ["type-fest@4.41.0", "", {}, "sha512-TeTSQ6H5YHvpqVwBRcnLDCBnDOHWYu7IvGbHT6N8AOymcr9PJGjc1GTtiWZTYg0NCgYwvnYWEkVChQAr9bjfwA=="],
-
-    "undici-types": ["undici-types@7.16.0", "", {}, "sha512-Zz+aZWSj8LE6zoxD+xrjh4VfkIG8Ya6LvYkZqtUQGJPZjYl53ypCaUwWqo7eI0x66KBGeRo+mlBEkMSeSZ38Nw=="],
-
-    "unicorn-magic": ["unicorn-magic@0.3.0", "", {}, "sha512-+QBBXBCvifc56fsbuxZQ6Sic3wqqc3WWaqxs58gvJrcOuN83HGTCwz3oS5phzU9LthRNE9VrJCFCLUgHeeFnfA=="],
-
-    "upper-case-first": ["upper-case-first@2.0.2", "", { "dependencies": { "tslib": "^2.0.3" } }, "sha512-514ppYHBaKwfJRK/pNC6c/OxfGa0obSnAl106u97Ed0I625Nin96KAjttZF6ZL3e1XLtphxnqrOi9iWgm+u+bg=="],
-
-    "use-callback-ref": ["use-callback-ref@1.3.3", "", { "dependencies": { "tslib": "^2.0.0" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-jQL3lRnocaFtu3V00JToYz/4QkNWswxijDaCVNZRiRTO3HQDLsdu1ZtmIUvV4yPp+rvWm5j0y0TG/S61cuijTg=="],
-
-    "use-sidecar": ["use-sidecar@1.1.3", "", { "dependencies": { "detect-node-es": "^1.1.0", "tslib": "^2.0.0" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Fedw0aZvkhynoPYlA5WXrMCAMm+nSWdZt6lzJQ7Ok8S6Q+VsHmHpRWndVRJ8Be0ZbkfPc5LRYH+5XrzXcEeLRQ=="],
-
-    "util-arity": ["util-arity@1.1.0", "", {}, "sha512-kkyIsXKwemfSy8ZEoaIz06ApApnWsk5hQO0vLjZS6UkBiGiW++Jsyb8vSBoc0WKlffGoGs5yYy/j5pp8zckrFA=="],
-
-    "uuid": ["uuid@10.0.0", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-8XkAphELsDnEGrDxUOHB3RGvXz6TeuYSGEZBOjtTtPm2lwhGBjLgOzLHB63IUWfBpNucQjND6d3AOudO+H3RWQ=="],
-
-    "validate-npm-package-license": ["validate-npm-package-license@3.0.4", "", { "dependencies": { "spdx-correct": "^3.0.0", "spdx-expression-parse": "^3.0.0" } }, "sha512-DpKm2Ui/xN7/HQKCtpZxoRWBhZ9Z0kqtygG8XCgNQ8ZlDnxuQmWhj566j8fN4Cu3/JmbhsDo7fcAJq4s9h27Ew=="],
-
-    "webidl-conversions": ["webidl-conversions@7.0.0", "", {}, "sha512-VwddBukDzu71offAQR975unBIGqfKZpM+8ZX6ySk8nYhVoo5CYaZyzt3YBvYtRtO+aoGlqxPg/B87NGVZ/fu6g=="],
-
-    "whatwg-mimetype": ["whatwg-mimetype@3.0.0", "", {}, "sha512-nt+N2dzIutVRxARx1nghPKGv1xHikU7HKdfafKkLNLindmPU/ch3U31NOCGGA/dmPcmb1VlofO0vnKAcsm0o/Q=="],
-
-    "xmlbuilder": ["xmlbuilder@15.1.1", "", {}, "sha512-yMqGBqtXyeN1e3TGYvgNgDVZ3j84W4cwkOXQswghol6APgZWaff9lnbvN7MHYJOiXsvGPXtjTYJEiC9J2wv9Eg=="],
-
-    "yaml": ["yaml@2.8.2", "", { "bin": { "yaml": "bin.mjs" } }, "sha512-mplynKqc1C2hTVYxd0PU2xQAc22TI1vShAYGksCCfxbn/dFwnHTNi1bvYsBTkhdUNtGIf5xNOg938rrSSYvS9A=="],
-
-    "yup": ["yup@1.7.1", "", { "dependencies": { "property-expr": "^2.0.5", "tiny-case": "^1.0.3", "toposort": "^2.0.2", "type-fest": "^2.19.0" } }, "sha512-GKHFX2nXul2/4Dtfxhozv701jLQHdf6J34YDh2cEkpqoo8le5Mg6/LrdseVLrFarmFygZTlfIhHx/QKfb/QWXw=="],
-
-    "@cucumber/cucumber/@cucumber/gherkin": ["@cucumber/gherkin@37.0.1", "", { "dependencies": { "@cucumber/messages": ">=31.0.0 <32" } }, "sha512-VmX+PKa9vqKZiycZoQKYlCsA0N7gAfiOfrcHSjK+suEVUwvKEH2sjO47NznrFFLmVWYTRmw3DLHQnpBAznkYEA=="],
-
-    "@cucumber/cucumber/@cucumber/messages": ["@cucumber/messages@31.1.0", "", { "dependencies": { "class-transformer": "0.5.1", "reflect-metadata": "0.2.2" } }, "sha512-BViwUQ9YMjcGL98Ww2QHMgu3S4JLUjbTz+Jo/jsq+8ZjS47/2v3IszpD6e12Y6IzZoGfrZriauZHPQ4PAmN9XA=="],
-
-    "@cucumber/gherkin/@cucumber/messages": ["@cucumber/messages@25.0.1", "", { "dependencies": { "@types/uuid": "9.0.8", "class-transformer": "0.5.1", "reflect-metadata": "0.2.2", "uuid": "9.0.1" } }, "sha512-RjjhmzcauX5eYfcKns5pgenefDJQcfXE3ZDrVWdUDGcoaoyFVDmj+ZzQZWRWqFrfMjP3lKHJss6LtvIP/z+h8g=="],
-
-    "@cucumber/gherkin-streams/commander": ["commander@14.0.0", "", {}, "sha512-2uM9rYjPvyq39NwLRqaiLtWHyDC1FvryJDa2ATTVims5YAS4PupsEQsDvP14FqhFr0P49CYDugi59xaxJlTXRA=="],
-
-    "@cucumber/gherkin-utils/@cucumber/gherkin": ["@cucumber/gherkin@34.0.0", "", { "dependencies": { "@cucumber/messages": ">=19.1.4 <29" } }, "sha512-659CCFsrsyvuBi/Eix1fnhSheMnojSfnBcqJ3IMPNawx7JlrNJDcXYSSdxcUw3n/nG05P+ptCjmiZY3i14p+tA=="],
-
-    "@cucumber/gherkin-utils/@cucumber/messages": ["@cucumber/messages@29.0.1", "", { "dependencies": { "class-transformer": "0.5.1", "reflect-metadata": "0.2.2" } }, "sha512-aAvIYfQD6/aBdF8KFQChC3CQ1Q+GX9orlR6GurGiX6oqaCnBkxA4WU3OQUVepDynEFrPayerqKRFcAMhdcXReQ=="],
-
-    "@cucumber/gherkin-utils/commander": ["commander@14.0.0", "", {}, "sha512-2uM9rYjPvyq39NwLRqaiLtWHyDC1FvryJDa2ATTVims5YAS4PupsEQsDvP14FqhFr0P49CYDugi59xaxJlTXRA=="],
-
-    "@radix-ui/react-arrow/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-collection/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-collection/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-dismissable-layer/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-focus-scope/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-popper/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-portal/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-select/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-select/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-tooltip/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "@radix-ui/react-tooltip/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-visually-hidden/@radix-ui/react-primitive": ["@radix-ui/react-primitive@2.1.3", "", { "dependencies": { "@radix-ui/react-slot": "1.2.3" }, "peerDependencies": { "@types/react": "*", "@types/react-dom": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc", "react-dom": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react", "@types/react-dom"] }, "sha512-m9gTwRkhy2lvCPe6QJp4d3G1TYEUHn/FzJUtq9MjH46an1wJU+GdoGC5VLof8RX8Ft/DlpshApkhswDLZzHIcQ=="],
-
-    "chalk/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="],
-
-    "chalk/supports-color": ["supports-color@7.2.0", "", { "dependencies": { "has-flag": "^4.0.0" } }, "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw=="],
-
-    "read-package-up/type-fest": ["type-fest@5.4.1", "", { "dependencies": { "tagged-tag": "^1.0.0" } }, "sha512-xygQcmneDyzsEuKZrFbRMne5HDqMs++aFzefrJTgEIKjQ3rekM+RPfFCVq2Gp1VIDqddoYeppCj4Pcb+RZW0GQ=="],
-
-    "read-pkg/type-fest": ["type-fest@5.4.1", "", { "dependencies": { "tagged-tag": "^1.0.0" } }, "sha512-xygQcmneDyzsEuKZrFbRMne5HDqMs++aFzefrJTgEIKjQ3rekM+RPfFCVq2Gp1VIDqddoYeppCj4Pcb+RZW0GQ=="],
-
-    "strip-ansi/ansi-regex": ["ansi-regex@5.0.1", "", {}, "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ=="],
-
-    "yup/type-fest": ["type-fest@2.19.0", "", {}, "sha512-RAH822pAdBgcNMAfWnCBU3CFZcfZ/i1eZjwFU/dsLKumyuuP3niueg2UAukXYF0E2AAoc82ZSSf9J0WQBinzHA=="],
-
-    "@cucumber/gherkin-utils/@cucumber/gherkin/@cucumber/messages": ["@cucumber/messages@27.2.0", "", { "dependencies": { "@types/uuid": "10.0.0", "class-transformer": "0.5.1", "reflect-metadata": "0.2.2", "uuid": "11.0.5" } }, "sha512-f2o/HqKHgsqzFLdq6fAhfG1FNOQPdBdyMGpKwhb7hZqg0yZtx9BVqkTyuoNk83Fcvk3wjMVfouFXXHNEk4nddA=="],
-
-    "@cucumber/gherkin/@cucumber/messages/@types/uuid": ["@types/uuid@9.0.8", "", {}, "sha512-jg+97EGIcY9AGHJJRaaPVgetKDsrTgbRjQ5Msgjh/DQKEFl0DtyRr/VCOyD1T2R1MNeWPK/u7JoGhlDZnKBAfA=="],
-
-    "@cucumber/gherkin/@cucumber/messages/uuid": ["uuid@9.0.1", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-b+1eJOlsR9K8HJpow9Ok3fiWOWSIcIzXodvv0rQjVoOVNpWMpxf1wZNpt4y9h10odCNrqnYp1OBzRktckBe3sA=="],
-
-    "@radix-ui/react-arrow/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-dismissable-layer/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-focus-scope/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-popper/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-portal/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@radix-ui/react-visually-hidden/@radix-ui/react-primitive/@radix-ui/react-slot": ["@radix-ui/react-slot@1.2.3", "", { "dependencies": { "@radix-ui/react-compose-refs": "1.1.2" }, "peerDependencies": { "@types/react": "*", "react": "^16.8 || ^17.0 || ^18.0 || ^19.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-aeNmHnBxbi2St0au6VBVC7JXFlhLlOnvIIlePNniyUNAClzmtAUEY8/pBiK3iHjufOlwA+c20/8jngo7xcrg8A=="],
-
-    "@cucumber/gherkin-utils/@cucumber/gherkin/@cucumber/messages/uuid": ["uuid@11.0.5", "", { "bin": { "uuid": "dist/esm/bin/uuid" } }, "sha512-508e6IcKLrhxKdBbcA2b4KQZlLVp2+J5UwQ6F7Drckkc5N9ZJwFa4TgWtsww9UG8fGHbm6gbV19TdM5pQ4GaIA=="],
-  }
-}

cucumber.json

@@ -1,10 +1,12 @@
 {
   "default": {
     "import": [
-      "features/support/**/*.ts",
-      "features/step_definitions/**/*.ts"
+      "src/shared/support/**/*.ts",
+      "src/shared/steps/**/*.ts",
+      "src/modules/*/steps/**/*.ts"
     ],
-    "paths": ["features/**/*.feature"],
+    "paths": ["src/modules/*/features/**/*.feature"],
+    "tags": "not @wip and not @humain",
     "format": [
       "progress-bar",
       "json:reports/cucumber-report.json",

features/event/us-7-inscription-evenement.feature

@@ -1,30 +0,0 @@
-# language: fr
-@EVENT @priority-1
-Fonctionnalité: US-7 M'inscrire/me désinscrire à un événement
-  En tant qu'utilisateur
-  Je peux m'inscrire/me désinscrire à un événement
-  Après avoir consulté la description de l'événement, les dates et le lieu
-  S'il existe déjà dans le système ou en le retrouvant dans une base existante
-
-  Contexte:
-    Étant donné que je suis connecté en tant qu'utilisateur
-
-  Scénario: Consulter un événement avant inscription
-    Étant donné que je suis sur la page "détail événement"
-    Alors l'écran affiche les informations de l'événement
-
-  Scénario: S'inscrire à un événement
-    * Scénario non implémenté
-
-  Scénario: Se désinscrire d'un événement
-    * Scénario non implémenté
-
-  Scénario: Rechercher un événement existant
-    Étant donné que je suis sur la page "découvrir"
-    Alors je peux voir la liste des événements
-
-  Scénario: Vérifier les données de l'écran
-    * Scénario non implémenté
-
-  Scénario: Rechercher dans une base existante (Mobilizon)
-    * Scénario non implémenté

features/step_definitions/form.steps.ts

@@ -1,62 +0,0 @@
-import { Given, Then } from '@cucumber/cucumber';
-import { expect } from 'chai';
-import type { FestipodWorld } from '../support/world';
-
-Given('l\'écran {string} est affiché', async function (this: FestipodWorld, screenName: string) {
-  const screenId = screenName.toLowerCase().replace(/ /g, '-');
-  this.navigateTo(`#/demo/${screenId}`);
-});
-
-Given('le formulaire de création est vide', async function (this: FestipodWorld) {
-  this.formFields.forEach((field, key) => {
-    this.formFields.set(key, { ...field, value: '' });
-  });
-});
-
-// Steps removed: Form interaction steps (je remplis le champ, je laisse le champ vide, je soumets le formulaire)
-// require browser automation. Scenarios needing these use "* Scénario non implémenté" placeholder.
-
-Then('le formulaire contient le champ obligatoire {string}', async function (this: FestipodWorld, fieldName: string) {
-  // This step is for form screens only (create-event)
-  expect(this.currentScreenId, 'This step is for form screens only').to.equal('create-event');
-  const source = this.getRenderedText();
-  // CreateEventScreen.tsx: Required fields have " *" after label: >Label *<
-  const escapedName = fieldName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-  const pattern = new RegExp(`>${escapedName}\\s*\\*<`);
-  expect(pattern.test(source), `Field "${fieldName}" should be marked as required (with *) in create-event screen`).to.be.true;
-});
-
-Then('le formulaire contient les champs obligatoires suivants:', async function (this: FestipodWorld, dataTable) {
-  // This step is for form screens only (create-event)
-  expect(this.currentScreenId, 'This step is for form screens only').to.equal('create-event');
-  const source = this.getRenderedText();
-  const expectedFields = dataTable.raw().flat();
-  expectedFields.forEach((fieldName: string) => {
-    // CreateEventScreen.tsx: Required fields have " *" after label: >Label *<
-    const escapedName = fieldName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-    const pattern = new RegExp(`>${escapedName}\\s*\\*<`);
-    expect(pattern.test(source), `Field "${fieldName}" should be marked as required (with *) in create-event screen`).to.be.true;
-  });
-});
-
-Then('le champ {string} est facultatif', async function (this: FestipodWorld, fieldName: string) {
-  const source = this.getRenderedText();
-  // Optional fields have label without " *": >Label< followed by Input
-  const escapedName = fieldName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-  // Check field exists but NOT marked as required
-  const existsPattern = new RegExp(`>${escapedName}<`);
-  const requiredPattern = new RegExp(`>${escapedName}\\s*\\*<`);
-  expect(existsPattern.test(source), `Field "${fieldName}" should exist in screen`).to.be.true;
-  expect(requiredPattern.test(source), `Field "${fieldName}" should NOT be marked as required`).to.be.false;
-});
-
-Then('le champ {string} est présent', async function (this: FestipodWorld, fieldName: string) {
-  const source = this.getRenderedText();
-  // Check that field label exists in screen source
-  const escapedName = fieldName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-  const pattern = new RegExp(`>${escapedName}[^<]*<`);
-  expect(pattern.test(source), `Field "${fieldName}" should be present in screen`).to.be.true;
-});
-
-// Steps removed: Form display/validation steps (le champ affiche, erreur de validation, formulaire affiche N champs)
-// require browser automation. Scenarios needing these use "* Scénario non implémenté" placeholder.

features/step_definitions/screen.steps.ts

@@ -1,192 +0,0 @@
-import { Given, Then } from '@cucumber/cucumber';
-import { expect } from 'chai';
-import type { FestipodWorld } from '../support/world';
-
-Then('je peux voir la liste des participants', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('event-detail');
-  const source = this.getRenderedText();
-  // EventDetailScreen.tsx has: <Avatar components and "Participants (12)" text
-  const hasAvatars = /<Avatar/.test(source);
-  const hasParticipantsSection = /Participants\s*\(\d+\)/.test(source);
-  expect(hasAvatars, 'Event detail should have Avatar components for participants').to.be.true;
-  expect(hasParticipantsSection, 'Event detail should have "Participants (N)" section').to.be.true;
-});
-
-Then('je peux voir les détails de l\'événement', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('event-detail');
-  const source = this.getRenderedText();
-  // EventDetailScreen.tsx has: <Title>, 📅, 🕓, 📍 emojis, and "À propos" section
-  expect(/<Title[^>]*>[^<]+<\/Title>/.test(source), 'Event detail should have a Title').to.be.true;
-  expect(/📅/.test(source), 'Event detail should have date emoji 📅').to.be.true;
-  expect(/🕓/.test(source), 'Event detail should have time emoji 🕓').to.be.true;
-  expect(/📍/.test(source), 'Event detail should have location emoji 📍').to.be.true;
-  expect(/À propos/.test(source), 'Event detail should have "À propos" section').to.be.true;
-});
-
-Then('je peux voir la section {string}', async function (this: FestipodWorld, sectionName: string) {
-  const source = this.getRenderedText();
-  // Detect section by text search
-  const found = source.includes(sectionName);
-  if (!found) {
-    this.attach(`Looking for section: "${sectionName}"`, 'text/plain');
-    this.attach(`Rendered text: ${source.substring(0, 500)}...`, 'text/plain');
-  }
-  expect(found, `Section "${sectionName}" should be visible on screen`).to.be.true;
-});
-
-// Step removed: "la page affiche N éléments" requires browser automation.
-// Scenarios needing this use "* Scénario non implémenté" placeholder.
-
-Then('je peux voir mon profil', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('profile');
-  const source = this.getRenderedText();
-  // ProfileScreen.tsx has: <Avatar initials="MD" size="lg" />, <Title>Marie Dupont</Title>, @mariedupont
-  expect(/<Avatar[^>]*initials="MD"[^>]*size="lg"/.test(source), 'Profile should have Avatar with initials="MD" and size="lg"').to.be.true;
-  expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source), 'Profile should have Title "Marie Dupont"').to.be.true;
-  expect(/@mariedupont/.test(source), 'Profile should have username @mariedupont').to.be.true;
-});
-
-Then('je peux voir le profil de l\'utilisateur', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('user-profile');
-  const source = this.getRenderedText();
-  // UserProfileScreen.tsx has: <Avatar initials="JD" size="lg" />, <Title>Jean Durand</Title>, @jeandurand
-  expect(/<Avatar[^>]*initials="JD"[^>]*size="lg"/.test(source), 'User profile should have Avatar with initials="JD" and size="lg"').to.be.true;
-  expect(/<Title[^>]*>Jean Durand<\/Title>/.test(source), 'User profile should have Title "Jean Durand"').to.be.true;
-  expect(/@jeandurand/.test(source), 'User profile should have username @jeandurand').to.be.true;
-});
-
-Then('je peux voir la liste des événements', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  if (this.currentScreenId === 'home') {
-    // HomeScreen.tsx has: "Événements à venir" text and EventCard components
-    expect(/Mes événements à venir/.test(source), 'Home screen should have "Événements à venir" text').to.be.true;
-  } else if (this.currentScreenId === 'events') {
-    // EventsScreen.tsx has: EventCard components with event data
-    expect(/<Card[^>]*onClick/.test(source), 'Events screen should have clickable Card components').to.be.true;
-  } else {
-    expect.fail(`Unexpected screen "${this.currentScreenId}" - events list should be on home or events screen`);
-  }
-});
-
-Then('les événements affichent leur lieu', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  // HomeScreen.tsx and EventsScreen.tsx EventCard components display location as:
-  // 📍 <span className="user-content">{location}</span>
-  // Check that there's actual location text after the emoji
-  const locationPattern = /📍.*<span[^>]*className="user-content"[^>]*>[^<]+<\/span>/;
-  expect(locationPattern.test(source), 'Event cards should display location text after 📍 emoji').to.be.true;
-});
-
-Then('je peux voir le QR code', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  if (this.currentScreenId === 'share-profile') {
-    // ShareProfileScreen.tsx has: "QR Code" comment and "Scannez pour me retrouver" text
-    expect(/QR Code/.test(source), 'Share profile should have "QR Code" text').to.be.true;
-    expect(/Scannez pour me retrouver/.test(source), 'Share profile should have "Scannez pour me retrouver" text').to.be.true;
-  } else if (this.currentScreenId === 'meeting-points') {
-    // MeetingPointsScreen.tsx has: "Mon QR Code" text and "Scannez pour m'ajouter"
-    expect(/Mon QR Code/.test(source), 'Meeting points should have "Mon QR Code" text').to.be.true;
-    expect(/Scannez pour m'ajouter/.test(source), 'Meeting points should have "Scannez pour m\'ajouter" text').to.be.true;
-  } else {
-    expect.fail(`QR code should be on share-profile or meeting-points, not "${this.currentScreenId}"`);
-  }
-});
-
-Then('je peux voir le lien de partage', async function (this: FestipodWorld) {
-  expect(this.currentScreenId, 'Share link should be on share-profile screen').to.equal('share-profile');
-  const source = this.getRenderedText();
-  // ShareProfileScreen.tsx has: "Mon lien de profil" text and profileLink variable
-  expect(/Mon lien de profil/.test(source), 'Share profile should have "Mon lien de profil" text').to.be.true;
-  expect(/festipod\.app\/u\//.test(source), 'Share profile should have profile link URL').to.be.true;
-});
-
-// Steps removed: Data setup steps (un événement existe avec les données, un utilisateur existe avec les données)
-// require backend/database. Scenarios needing these use "* Scénario non implémenté" placeholder.
-
-Given('je visualise l\'événement {string}', async function (this: FestipodWorld, eventName: string) {
-  this.navigateTo('#/demo/event-detail');
-  expect(this.currentScreen, 'Event detail screen should be loaded').to.not.be.null;
-  this.attach(`Viewing event: ${eventName}`, 'text/plain');
-});
-
-Given('je visualise le profil de {string}', async function (this: FestipodWorld, userName: string) {
-  this.navigateTo('#/demo/user-profile');
-  expect(this.currentScreen, 'User profile screen should be loaded').to.not.be.null;
-  this.attach(`Viewing profile: ${userName}`, 'text/plain');
-});
-
-Then('l\'écran affiche les informations de l\'événement', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('event-detail');
-  const source = this.getRenderedText();
-  // EventDetailScreen.tsx has: <Title>, 📅, 🕓, 📍 emojis, and "À propos" section
-  expect(/<Title[^>]*>[^<]+<\/Title>/.test(source), 'Event detail should have a Title').to.be.true;
-  expect(/📅/.test(source), 'Event detail should have date emoji 📅').to.be.true;
-  expect(/🕓/.test(source), 'Event detail should have time emoji 🕓').to.be.true;
-  expect(/📍/.test(source), 'Event detail should have location emoji 📍').to.be.true;
-  expect(/À propos/.test(source), 'Event detail should have "À propos" section').to.be.true;
-});
-
-Then('l\'écran affiche les informations du profil', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  if (this.currentScreenId === 'profile') {
-    // ProfileScreen.tsx has: <Avatar initials="MD" size="lg" />, <Title>Marie Dupont</Title>, @mariedupont
-    expect(/<Avatar[^>]*initials="MD"/.test(source), 'Profile should have Avatar with initials="MD"').to.be.true;
-    expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source), 'Profile should have Title "Marie Dupont"').to.be.true;
-    expect(/@mariedupont/.test(source), 'Profile should have username @mariedupont').to.be.true;
-  } else if (this.currentScreenId === 'user-profile') {
-    // UserProfileScreen.tsx has: <Avatar initials="JD" size="lg" />, <Title>Jean Durand</Title>, @jeandurand
-    expect(/<Avatar[^>]*initials="JD"/.test(source), 'User profile should have Avatar with initials="JD"').to.be.true;
-    expect(/<Title[^>]*>Jean Durand<\/Title>/.test(source), 'User profile should have Title "Jean Durand"').to.be.true;
-    expect(/@jeandurand/.test(source), 'User profile should have username @jeandurand').to.be.true;
-  } else {
-    expect.fail(`Unexpected screen "${this.currentScreenId}" for profile info check`);
-  }
-});
-
-// Steps removed: Feature steps not implemented in UI (commentaire, note, filtrer par période, modifier/supprimer commentaire)
-// Scenarios needing these use "* Scénario non implémenté" placeholder.
-
-Then('je peux m\'inscrire à l\'événement', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('event-detail');
-  const source = this.getRenderedText();
-  // EventDetailScreen.tsx line 49: {isJoined ? '✓ Inscrit' : 'Participer'}
-  // The button shows "Participer" when not joined
-  const hasParticiperButton = /isJoined \? '✓ Inscrit' : 'Participer'/.test(source);
-  expect(hasParticiperButton, 'Event detail should have Participer/Inscrit toggle button').to.be.true;
-});
-
-Then('je peux me désinscrire de l\'événement', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('event-detail');
-  const source = this.getRenderedText();
-  // EventDetailScreen.tsx line 49: {isJoined ? '✓ Inscrit' : 'Participer'}
-  // Same button toggles - clicking "✓ Inscrit" will unregister
-  const hasInscritButton = /isJoined \? '✓ Inscrit' : 'Participer'/.test(source);
-  expect(hasInscritButton, 'Event detail should have Participer/Inscrit toggle button (click to unregister)').to.be.true;
-});
-
-Then('je peux contacter l\'utilisateur', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('user-profile');
-  const source = this.getRenderedText();
-  // UserProfileScreen.tsx line 44: <Button>Contacter</Button>
-  const hasContactButton = /<Button>Contacter<\/Button>/.test(source);
-  expect(hasContactButton, 'User profile should have "Contacter" button').to.be.true;
-});
-
-Then('je peux voir les événements auxquels l\'utilisateur a participé', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('user-profile');
-  const source = this.getRenderedText();
-  // UserProfileScreen.tsx: "Événements à venir" and "Événements passés" sections
-  expect(/Événements à venir/.test(source), 'User profile should have "Événements à venir" section').to.be.true;
-  expect(/Événements passés/.test(source), 'User profile should have "Événements passés" section').to.be.true;
-});
-
-Then('je peux configurer mes notifications', async function (this: FestipodWorld) {
-  expect(this.currentScreenId).to.equal('settings');
-  const source = this.getRenderedText();
-  // SettingsScreen.tsx line 25: <Text>Notifications</Text> with Toggle
-  expect(/>Notifications</.test(source), 'Settings should have "Notifications" text').to.be.true;
-  expect(/<Toggle[^>]*checked=\{notifications\}/.test(source), 'Settings should have Toggle for notifications').to.be.true;
-});
-
-// Steps removed: Settings features not implemented in UI (rayon de notification, thématiques d'intérêt)
-// Scenarios needing these use "* Scénario non implémenté" placeholder.

features/support/hooks.ts

@@ -1,38 +0,0 @@
-import { Before, After, BeforeAll, AfterAll, Status } from '@cucumber/cucumber';
-import type { FestipodWorld } from './world';
-
-BeforeAll(async function () {
-  console.log('Starting Festipod BDD tests...');
-});
-
-Before(async function (this: FestipodWorld, scenario) {
-  this.currentRoute = '#/';
-  this.currentScreenId = null;
-  this.formFields.clear();
-  this.navigationHistory = [];
-  this.isAuthenticated = false;
-  this.screenSourceContent = '';
-  this.currentScreen = null;
-
-  // Skipped scenarios use the "* Scénario non implémenté" placeholder step
-  // which returns 'skipped' - no special handling needed in the hook
-});
-
-After(async function (this: FestipodWorld, scenario) {
-  if (scenario.result?.status === Status.FAILED) {
-    this.attach(`Current route: ${this.currentRoute}`, 'text/plain');
-    this.attach(`Current screen: ${this.currentScreenId}`, 'text/plain');
-    this.attach(`Navigation history: ${JSON.stringify(this.navigationHistory)}`, 'text/plain');
-    this.attach(`Form fields: ${JSON.stringify(Array.from(this.formFields.entries()))}`, 'text/plain');
-    if (this.screenSourceContent) {
-      // Show first 500 chars of source to help debug
-      this.attach(`Screen source (first 500 chars): ${this.screenSourceContent.substring(0, 500)}...`, 'text/plain');
-    }
-  }
-  // Clean up
-  this.cleanup();
-});
-
-AfterAll(async function () {
-  console.log('Festipod BDD tests completed.');
-});

package.json

@@ -1,19 +1,34 @@
 {
-  "name": "bun-react-template",
+  "name": "festipod",
   "version": "0.1.0",
   "private": true,
   "type": "module",
   "scripts": {
-    "dev": "bun --hot src/index.ts",
+    "dev": "portless festipod bun --hot src/index.ts",
     "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",
+    "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"
+    "steps:extract": "bun scripts/extract-step-definitions.ts",
+    "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",
+    "overlay:polyfill": "bun scripts/overlay-local-checkout.ts polyfill",
+    "overlay:indexing": "bun scripts/overlay-local-checkout.ts indexing",
+    "storybook": "storybook dev -p 6006",
+    "build-storybook": "storybook build"
   },
   "dependencies": {
+    "@ng-eventually/polyfill": "git+https://gitea.reconnexion.apps.gueraud.net/Reconnexion/ng-eventually.git#a8d53010c227462cc9317e9be499c2100ca8d533&path:/packages/polyfill",
+    "@ng-helpers/indexing": "git+https://gitea.reconnexion.apps.gueraud.net/Sylvain/ng-helpers.git#v1.0.1",
+    "@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",
+    "@ng-org/web": "0.1.2-alpha.13",
     "@radix-ui/react-label": "^2.1.7",
     "@radix-ui/react-select": "^2.2.6",
     "@radix-ui/react-slot": "^1.2.3",
@@ -36,8 +51,21 @@
     "@types/react-dom": "^19",
     "chai": "^6.2.2",
     "happy-dom": "^16.6.0",
+    "playwright": "^1.58.2",
     "tailwindcss": "^4.1.11",
     "tsx": "^4.21.0",
-    "tw-animate-css": "^1.4.0"
-  }
+    "tw-animate-css": "^1.4.0",
+    "storybook": "^10.3.5",
+    "@storybook/react-webpack5": "^10.3.5",
+    "@storybook/addon-webpack5-compiler-swc": "^4.0.3",
+    "@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"
 }

patches/@ng-org%2Form@0.1.2-alpha.4.patch

@@ -0,0 +1,74 @@
+diff --git a/node_modules/@ng-org/orm/.bun-tag-78937f1a8bb90c1e b/.bun-tag-78937f1a8bb90c1e
+new file mode 100644
+index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+diff --git a/package.json b/package.json
+index 33023505142d0c7f1dfe9861e8f2adce15ffa2e0..226fd1f6eff39fc6891d8dd5ac2bade3670cae66 100644
+--- a/package.json
++++ b/package.json
+@@ -30,36 +30,47 @@
+     "access": "public"
+   },
+   "dependencies": {
+-    "@astrojs/react": "4.3.0",
+-    "@astrojs/svelte": "7.1.0",
+-    "@astrojs/vue": "^5.1.0",
+-    "@gn8/alien-signals-react": "^0.1.1",
+-    "@gn8/alien-signals-solid": "^0.1.1",
+-    "@gn8/alien-signals-svelte": "^0.1.1",
+-    "@gn8/alien-signals-vue": "^0.1.1",
+-    "@types/react": "19.1.10",
+-    "@types/react-dom": "19.1.7",
+-    "@types/shexj": "^2.1.7",
+     "alien-signals": "^2.0.7",
+-    "astro": "5.13.2",
+-    "install": "^0.13.0",
+-    "npm": "^11.5.2",
+-    "prettier-eslint": "^16.4.2",
+-    "react": "19.1.1",
+-    "react-dom": "19.1.1",
+-    "svelte": "5.39.12",
+-    "vue": "3.5.19",
+     "@ng-org/shex-orm": "0.1.2-alpha.2",
+-    "@ng-org/alien-deepsignals": "0.1.2-alpha.3"
++    "@ng-org/alien-deepsignals": "0.1.2-alpha.3",
++    "@types/shexj": "^2.1.7"
++  },
++  "peerDependencies": {
++    "react": ">=18",
++    "react-dom": ">=18",
++    "svelte": ">=4",
++    "vue": ">=3",
++    "@gn8/alien-signals-react": "^0.1.1",
++    "@gn8/alien-signals-svelte": "^0.1.1",
++    "@gn8/alien-signals-vue": "^0.1.1"
++  },
++  "peerDependenciesMeta": {
++    "react": { "optional": true },
++    "react-dom": { "optional": true },
++    "svelte": { "optional": true },
++    "vue": { "optional": true },
++    "@gn8/alien-signals-react": { "optional": true },
++    "@gn8/alien-signals-svelte": { "optional": true },
++    "@gn8/alien-signals-vue": { "optional": true }
+   },
+   "devDependencies": {
+     "@playwright/test": "^1.55.0",
+     "@types/node": "24.3.0",
+     "@types/react": "19.1.10",
+     "@types/react-dom": "19.1.7",
++    "svelte": "5.39.12",
++    "vue": "3.5.19",
++    "astro": "5.13.2",
++    "@astrojs/react": "4.3.0",
++    "@astrojs/svelte": "7.1.0",
++    "@astrojs/vue": "^5.1.0",
++    "@gn8/alien-signals-react": "^0.1.1",
++    "@gn8/alien-signals-svelte": "^0.1.1",
++    "@gn8/alien-signals-vue": "^0.1.1",
+     "vite": "7.1.3",
+     "vitest": "^3.2.4",
+     "typescript": "^5.3.0",
++    "prettier-eslint": "^16.4.2",
+     "@ng-org/lib-wasm": "0.1.2-alpha.1"
+   },
+   "files": [

scripts/build-ng-packages.sh

@@ -0,0 +1,148 @@
+#!/bin/bash
+#
+# Build and install @ng-org packages from local nextgraph-rs repo.
+#
+# This script:
+#   1. git pull on nextgraph-rs
+#   2. Installs monorepo deps (pnpm install)
+#   3. Builds the 4 packages we need (tsc / vite)
+#   4. Packs them into tarballs (applies publishConfig -> dist/)
+#   5. Installs the tarballs in festipod and updates package.json versions
+#
+# Usage:
+#   bash scripts/build-ng-packages.sh
+#
+# Run this after any nextgraph-rs update, or as needed.
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+FESTIPOD_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
+NEXTGRAPH_RS="${NEXTGRAPH_RS:-$(cd "$FESTIPOD_DIR/../../nextgraph/nextgraph-rs" && pwd)}"
+SDK_JS="$NEXTGRAPH_RS/sdk/js"
+TARBALLS_DIR="$FESTIPOD_DIR/.ng-tarballs"
+
+# Packages to build (in dependency order)
+PACKAGES=(alien-deepsignals shex-orm web orm)
+
+echo "=== @ng-org local build ==="
+echo "  nextgraph-rs: $NEXTGRAPH_RS"
+echo "  festipod:     $FESTIPOD_DIR"
+echo ""
+
+# --- Step 0: git pull ---
+echo "[0/5] Pulling latest nextgraph-rs..."
+cd "$NEXTGRAPH_RS"
+git pull --ff-only || echo "  WARN: git pull failed (maybe uncommitted changes?) — continuing with current state"
+echo ""
+
+# --- Step 1: Ensure lib-wasm/pkg stub exists ---
+LIB_WASM_PKG="$SDK_JS/lib-wasm/pkg"
+if [ ! -f "$LIB_WASM_PKG/package.json" ]; then
+  echo "[1/5] Creating lib-wasm/pkg stub (type-only dependency)..."
+  mkdir -p "$LIB_WASM_PKG"
+  cat > "$LIB_WASM_PKG/package.json" << 'STUBEOF'
+{
+  "name": "@ng-org/lib-wasm",
+  "version": "0.0.0-stub",
+  "type": "module",
+  "main": "./index.js",
+  "types": "./index.d.ts"
+}
+STUBEOF
+  echo "export {};" > "$LIB_WASM_PKG/index.js"
+  # Wildcard type stub: all methods are accepted via index signature
+  cat > "$LIB_WASM_PKG/index.d.ts" << 'DTSEOF'
+// Stub types for @ng-org/lib-wasm (real build requires Rust/WASM)
+export declare function orm_start_graph(...args: any[]): any;
+export declare function orm_start_discrete(...args: any[]): any;
+export declare function graph_orm_update(...args: any[]): any;
+export declare function discrete_orm_update(...args: any[]): any;
+export declare function doc_create(...args: any[]): any;
+export declare function doc_subscribe(...args: any[]): any;
+export declare function file_get(...args: any[]): any;
+export declare function app_request_stream(...args: any[]): any;
+// Catch-all for any other methods
+declare const _extra: { [key: string]: (...args: any[]) => any };
+export default _extra;
+DTSEOF
+else
+  echo "[1/5] lib-wasm/pkg stub already exists"
+fi
+echo ""
+
+# --- Step 2: Install monorepo deps ---
+echo "[2/5] Installing monorepo dependencies..."
+cd "$NEXTGRAPH_RS"
+pnpm install --frozen-lockfile 2>/dev/null || pnpm install
+echo ""
+
+# --- Step 3: Build each package ---
+echo "[3/5] Building packages..."
+for pkg in "${PACKAGES[@]}"; do
+  PKG_DIR="$SDK_JS/$pkg"
+  if [ ! -d "$PKG_DIR" ]; then
+    echo "  SKIP $pkg (directory not found)"
+    continue
+  fi
+
+  # Check if there's a build script
+  HAS_BUILD=$(node -e "const p=require('$PKG_DIR/package.json'); process.stdout.write(p.scripts?.build ? '1' : '0')")
+  if [ "$HAS_BUILD" = "0" ]; then
+    # Try build:ts (orm, alien-deepsignals)
+    HAS_BUILD_TS=$(node -e "const p=require('$PKG_DIR/package.json'); process.stdout.write(p.scripts?.['build:ts'] ? '1' : '0')")
+    if [ "$HAS_BUILD_TS" = "1" ]; then
+      echo "  Building $pkg (build:ts)..."
+      cd "$PKG_DIR"
+      pnpm run build:ts
+    else
+      echo "  SKIP $pkg (no build script)"
+    fi
+  else
+    echo "  Building $pkg (build)..."
+    cd "$PKG_DIR"
+    pnpm run build
+  fi
+done
+echo ""
+
+# --- Step 4: Pack each package ---
+echo "[4/5] Packing tarballs..."
+rm -rf "$TARBALLS_DIR"
+mkdir -p "$TARBALLS_DIR"
+
+for pkg in "${PACKAGES[@]}"; do
+  PKG_DIR="$SDK_JS/$pkg"
+  if [ ! -d "$PKG_DIR/dist" ]; then
+    echo "  WARN: $pkg has no dist/ — skipping pack"
+    continue
+  fi
+  cd "$PKG_DIR"
+  TARBALL=$(pnpm pack --pack-destination "$TARBALLS_DIR" 2>/dev/null | tail -1)
+  echo "  Packed $pkg → $(basename "$TARBALL")"
+done
+echo ""
+
+# --- Step 5: Install tarballs in festipod (one by one, in dependency order) ---
+echo "[5/5] Installing in festipod..."
+cd "$FESTIPOD_DIR"
+
+# Install one by one to avoid Bun's dependency loop detection issue
+for pkg in "${PACKAGES[@]}"; do
+  TGZ=$(ls "$TARBALLS_DIR"/ng-org-${pkg}-*.tgz 2>/dev/null | head -1)
+  if [ -z "$TGZ" ]; then
+    echo "  WARN: no tarball for $pkg"
+    continue
+  fi
+  echo "  Installing @ng-org/$pkg..."
+  bun add "$TGZ"
+done
+
+echo ""
+echo "=== Done! All @ng-org packages installed from local build ==="
+echo ""
+echo "Installed versions:"
+for pkg in "${PACKAGES[@]}"; do
+  VERSION=$(node -e "try{const p=require('$FESTIPOD_DIR/node_modules/@ng-org/$pkg/package.json');console.log(p.version)}catch{console.log('not found')}")
+  echo "  @ng-org/$pkg: $VERSION"
+done

scripts/debug-browser.ts

@@ -0,0 +1,33 @@
+/**
+ * Manual debug tool: launches a headed Chromium to inspect NextGraph broker interactions.
+ * Creates a temporary profile in `.playwright-profile-debug/` (gitignored).
+ *
+ * Usage: bun scripts/debug-browser.ts
+ */
+import { chromium } from 'playwright';
+
+const browser = await chromium.launch({ headless: false });
+const context = await browser.newContext();
+const page = await context.newPage();
+
+console.log('Browser launched. Navigating to nextgraph.net...');
+
+page.on('pageerror', (err) => console.log('[pageerror]', err.message));
+page.on('close', () => console.log('[page closed]'));
+page.on('crash', () => console.log('[page crashed]'));
+browser.on('disconnected', () => console.log('[browser disconnected]'));
+
+try {
+  await page.goto('https://nextgraph.net/redir/#/?o=http%3A%2F%2F127.0.0.1%3A12345', {
+    waitUntil: 'domcontentloaded',
+    timeout: 30000,
+  });
+  console.log('Navigation done. Page URL:', page.url());
+} catch (err: any) {
+  console.log('Navigation error (expected):', err.message);
+}
+
+console.log('Waiting... close the browser manually when done.');
+
+// Keep alive indefinitely
+await new Promise(() => {});

scripts/extract-step-definitions.ts

@@ -11,11 +11,23 @@ interface StepDefinition {
   lineNumber: number;
 }
 
-const stepFiles = [
-  'features/step_definitions/navigation.steps.ts',
-  'features/step_definitions/form.steps.ts',
-  'features/step_definitions/screen.steps.ts',
-];
+import { Glob } from 'bun';
+
+// Discover all step definition files: shared + module-specific
+function discoverStepFiles(): string[] {
+  const files: string[] = [];
+  // Shared steps
+  for (const f of new Glob('src/shared/steps/**/*.steps.ts').scanSync('.')) {
+    files.push(f);
+  }
+  // Module steps
+  for (const f of new Glob('src/modules/*/steps/**/*.steps.ts').scanSync('.')) {
+    files.push(f);
+  }
+  return files.sort();
+}
+
+const stepFiles = discoverStepFiles();
 
 function extractStepDefinitions(): StepDefinition[] {
   const definitions: StepDefinition[] = [];
@@ -115,7 +127,7 @@ export const stepDefinitions: StepDefinitionInfo[] = ${JSON.stringify(definition
 ${findFunctionCode}
 `;
 
-  await Bun.write('src/data/stepDefinitions.ts', output);
+  await Bun.write('src/shared/data/stepDefinitions.ts', output);
   console.log(`Generated ${definitions.length} step definitions`);
 }
 

scripts/overlay-local-checkout.ts

@@ -0,0 +1,160 @@
+#!/usr/bin/env bun
+/**
+ * overlay-local-checkout.ts — Reactive local overlay of a data-layer PROVIDER's checkout
+ * into node_modules. One script, one provider per run; only the paths differ between them.
+ *
+ * PROVIDERS (first non-flag argument; defaults to `polyfill`):
+ *   polyfill  → node_modules/@ng-eventually/polyfill   override: NG_EVENTUALLY_LOCAL
+ *   indexing  → node_modules/@ng-helpers/indexing      override: NG_HELPERS_LOCAL
+ *
+ * WHY a copy-overlay and not a symlink (identical for every provider):
+ *   A committed prod dependency installs from Gitea (git+https) into pnpm's store WITHOUT
+ *   its own node_modules/@ng-org, so @ng-org/web resolves UP to Festipod → ONE @ng-org
+ *   instance (one verifier). A local CHECKOUT, however, carries its own node_modules/*
+ *   (links into that provider's own dev tree). Symlinking node_modules/<pkg> to the
+ *   checkout would put the checkout's copies in the resolution path → a SECOND @ng-org
+ *   (and, for `indexing`, a second @ng-eventually/polyfill) → broken SDK, two verifiers.
+ *   So we overlay a real directory containing ONLY the provider's source (no node_modules):
+ *   shared packages still resolve up to Festipod, single instance preserved.
+ *
+ * WHAT IT DOES:
+ *   1. Replaces node_modules/<package> (the pnpm store symlink) with a real directory
+ *      holding the local checkout's package.json + src (NO node_modules).
+ *   2. Asserts the single-instance invariant — every package this provider SHARES with
+ *      Festipod must resolve to the same realpath from Festipod and from the overlay —
+ *      and aborts if it would break.
+ *   3. Watches the local checkout's src and copies each change into the overlay.
+ *
+ * ⚠️ RESTART `bun run dev` AFTER THIS SCRIPT WRITES — a rebuild is NOT a substitute.
+ * A running dev server NEVER picks up a package refreshed inside node_modules, not even
+ * across a genuine rebuild: VERIFIED in a controlled test, an application-source edit
+ * produced a new bundle hash and the rebuilt bundle STILL carried the stale dependency.
+ * The server's resolution of that import is pinned at process start and a rebuild does not
+ * re-resolve it. Only restarting serves the fresh copy, and nothing warns you — a stale
+ * server looks exactly like a current one. See
+ * .project/concepts/tech-stack/caveat_polyfill-overlay-needs-a-dev-restart.md, which cost
+ * an hour to learn. Watching copies the files; it does not make anything reload them.
+ *
+ * USAGE (reactive dev):
+ *   Terminal 1:  pnpm run overlay:polyfill    # or: pnpm run overlay:indexing
+ *   Terminal 2:  bun run dev                  # portless festipod bun --hot src/index.ts
+ *   Edit the checkout's src → it lands in node_modules → RESTART dev to pick it up.
+ *
+ *   pnpm run overlay:indexing --once          # overlay + verify, no watch (CI / one-shot)
+ *   Return to the committed git-installed dependencies:  pnpm install
+ */
+import { existsSync, lstatSync, mkdirSync, rmSync, cpSync, copyFileSync, realpathSync } from "node:fs";
+import { watch } from "node:fs";
+import { join, dirname } from "node:path";
+
+interface Provider {
+  /** Package as installed, e.g. "@ng-eventually/polyfill" — also its node_modules path. */
+  readonly packageName: string;
+  /** Local checkout used when the env override is unset. */
+  readonly defaultLocal: string;
+  /** Env var overriding the local checkout path. */
+  readonly envOverride: string;
+  /**
+   * Packages this provider SHARES with Festipod and that must stay single-instance.
+   * Each is resolved from Festipod and from the overlay; the realpaths must match.
+   */
+  readonly singletons: readonly string[];
+}
+
+const PROVIDERS: Record<string, Provider> = {
+  polyfill: {
+    packageName: "@ng-eventually/polyfill",
+    defaultLocal: "/home/sylvain/projects/nextgraph/ng-eventually-js/packages/polyfill",
+    envOverride: "NG_EVENTUALLY_LOCAL",
+    singletons: ["@ng-org/web"],
+  },
+  indexing: {
+    packageName: "@ng-helpers/indexing",
+    defaultLocal: "/home/sylvain/projects/nextgraph/ng-helpers",
+    envOverride: "NG_HELPERS_LOCAL",
+    // Consumes the polyfill, so BOTH it and the verifier underneath must stay single.
+    singletons: ["@ng-eventually/polyfill", "@ng-org/web"],
+  },
+};
+
+const FESTIPOD = realpathSync(join(import.meta.dir, ".."));
+const args = process.argv.slice(2);
+const ONCE = args.includes("--once");
+const KEY = args.find((a) => !a.startsWith("-")) ?? "polyfill";
+
+function fail(msg: string): never {
+  console.error(`✖ overlay:${KEY} — ${msg}`);
+  process.exit(1);
+}
+
+const provider = PROVIDERS[KEY];
+if (!provider) {
+  fail(`unknown provider "${KEY}" — expected one of: ${Object.keys(PROVIDERS).join(", ")}`);
+}
+
+const LOCAL = process.env[provider.envOverride] ?? provider.defaultLocal;
+const TARGET = join(FESTIPOD, "node_modules", ...provider.packageName.split("/"));
+const SRC_LOCAL = join(LOCAL, "src");
+const SRC_TARGET = join(TARGET, "src");
+
+if (!existsSync(join(LOCAL, "package.json"))) {
+  fail(`local checkout not found at ${LOCAL} (set ${provider.envOverride} to override)`);
+}
+if (!existsSync(SRC_LOCAL)) {
+  fail(`local checkout has no src/ at ${SRC_LOCAL}`);
+}
+
+// 1. Replace the pnpm store symlink with a real overlay dir (metadata + src, NO node_modules).
+console.log(`→ overlaying local ${provider.packageName}: ${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 instances).
+cpSync(SRC_LOCAL, SRC_TARGET, { recursive: true });
+
+// 2. Assert the single-instance invariant for every package shared with Festipod.
+const overlayReal = realpathSync(TARGET);
+for (const spec of provider.singletons) {
+  const fromFestipod = realpathSync(Bun.resolveSync(spec, FESTIPOD));
+  const fromOverlay = realpathSync(Bun.resolveSync(spec, overlayReal));
+  console.log(`  ${spec} (Festipod): ${fromFestipod}`);
+  console.log(`  ${spec} (overlay) : ${fromOverlay}`);
+  if (fromFestipod !== fromOverlay) {
+    fail(
+      `single-instance invariant BROKEN — ${spec} resolves to two different realpaths.\n` +
+        "  The overlay must not contain its own node_modules. Aborting.",
+    );
+  }
+}
+console.log(`✓ single instance preserved for: ${provider.singletons.join(", ")}`);
+
+if (ONCE) {
+  console.log("✓ overlay ready (--once, not watching)");
+  process.exit(0);
+}
+
+// 3. Watch and copy on change. This keeps the overlay CURRENT; it does NOT make a running
+// dev server notice — not even across a rebuild (see the header). Restart it.
+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/parse-features.ts

@@ -1,5 +1,5 @@
 import { Glob } from 'bun';
-import type { ParsedFeature, ParsedScenario, ParsedStep } from '../src/types/gherkin';
+import type { ParsedFeature, ParsedScenario, ParsedStep } from '../src/shared/types/gherkin';
 
 // Map French screen names to screen IDs (same as navigation.steps.ts)
 const screenNameMap: Record<string, string> = {
@@ -73,7 +73,7 @@ function extractScreenIdsFromSteps(steps: ParsedStep[]): Set<string> {
 }
 
 async function parseFeatures(): Promise<ParsedFeature[]> {
-  const glob = new Glob('features/**/*.feature');
+  const glob = new Glob('src/modules/*/features/**/*.feature');
   const features: ParsedFeature[] = [];
 
   for await (const filePath of glob.scan('.')) {
@@ -116,7 +116,7 @@ export function getAllPriorities(): number[] {
 }
 `;
 
-  await Bun.write('src/data/features.ts', output);
+  await Bun.write('src/shared/data/features.ts', output);
   console.log(`Parsed ${features.length} feature files`);
   return features;
 }

scripts/parse-test-results.ts

@@ -1,4 +1,4 @@
-import type { FeatureTestStatus, ScenarioTestResult } from '../src/types/gherkin';
+import type { FeatureTestStatus, ScenarioTestResult } from '../src/shared/types/gherkin';
 
 interface CucumberScenario {
   id: string;
@@ -137,7 +137,7 @@ export function getTestSummary() {
 }
 `;
 
-  await Bun.write('src/data/testResults.ts', output);
+  await Bun.write('src/shared/data/testResults.ts', output);
   console.log(`Generated test results for ${results.size} features`);
 
   // Print summary

scripts/setup-test-auth.ts

@@ -0,0 +1,119 @@
+/**
+ * One-time auth setup for data-layer testing.
+ *
+ * Two-step flow:
+ *   Step 1: Opens nextgraph.net so you can create/import a wallet
+ *   Step 2: Navigates to the broker redirect URL to authenticate the test app
+ *
+ * Saves auth state to playwright/.auth/ng-state.json for reuse by test runs.
+ *
+ * Usage: bun run test:auth-setup
+ */
+import { chromium } from 'playwright';
+import * as http from 'http';
+import * as path from 'path';
+import * as fs from 'fs';
+import * as readline from 'readline';
+
+const AUTH_STATE_PATH = path.resolve('playwright/.auth/ng-state.json');
+
+function prompt(question: string): Promise<string> {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise((resolve) => {
+    rl.question(question, (answer) => {
+      rl.close();
+      resolve(answer);
+    });
+  });
+}
+
+const SETUP_HTML = `<!DOCTYPE html>
+<html>
+<head><meta charset="utf-8"><title>Festipod Test Auth Setup</title></head>
+<body style="font-family: system-ui; padding: 2rem; text-align: center;">
+  <h2>Festipod — Test Auth Setup</h2>
+  <p id="status">Waiting for NextGraph session...</p>
+  <script type="module">
+    import { init, ng } from "@ng-org/web";
+
+    await init(
+      async (event) => {
+        document.getElementById("status").innerHTML =
+          '<span style="color: green; font-size: 1.5rem;">✓ Logged in!</span>' +
+          '<br><br>You can now close this browser window.';
+        console.log("[auth-setup] Session established:", event.session?.session_id);
+      },
+      true,
+      []
+    );
+  </script>
+</body>
+</html>`;
+
+async function main() {
+  console.log('=== NextGraph Auth Setup (2 steps) ===');
+  console.log('');
+
+  // ---- Step 1: Create / open wallet ----
+  console.log('STEP 1: Create or open your NextGraph wallet');
+  console.log('A browser will open at nextgraph.net.');
+  console.log('Create a wallet (or open an existing one), then come back here.');
+  console.log('');
+
+  const browser = await chromium.launch({ headless: false });
+  const context = await browser.newContext();
+  const page = await context.newPage();
+
+  await page.goto('https://nextgraph.net', { waitUntil: 'domcontentloaded' });
+
+  await prompt('Press ENTER here once your wallet is ready...');
+
+  // ---- Step 2: Authenticate the test app via broker redirect ----
+  console.log('');
+  console.log('STEP 2: Authenticating test app via broker...');
+
+  // Start a minimal HTTP server
+  const server = http.createServer((_req, res) => {
+    res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
+    res.end(SETUP_HTML);
+  });
+
+  const port = await new Promise<number>((resolve) => {
+    server.listen(0, '127.0.0.1', () => {
+      resolve((server.address() as { port: number }).port);
+    });
+  });
+
+  const appUrl = `http://127.0.0.1:${port}`;
+  const brokerUrl = `https://nextgraph.net/redir/#/?o=${encodeURIComponent(appUrl)}`;
+
+  // Navigate the same page to the broker redirect
+  await page.goto(brokerUrl, { waitUntil: 'domcontentloaded' });
+
+  console.log('The broker should now show your wallet login.');
+  console.log('Log in, wait for "✓ Logged in!", then close the browser.');
+  console.log('');
+
+  // Wait for browser close
+  await new Promise<void>((resolve) => {
+    page.on('close', () => resolve());
+    browser.on('disconnected', () => resolve());
+  });
+
+  // Save storage state
+  try {
+    const state = await context.storageState();
+    fs.mkdirSync(path.dirname(AUTH_STATE_PATH), { recursive: true });
+    fs.writeFileSync(AUTH_STATE_PATH, JSON.stringify(state, null, 2));
+    console.log(`\nAuth state saved to: ${AUTH_STATE_PATH}`);
+    console.log('You can now run: bun run test:data');
+  } catch {
+    console.log('\nCould not save auth state — browser may have closed too quickly.');
+  }
+
+  try { await context.close(); } catch {}
+  try { await browser.close(); } catch {}
+  server.close();
+}
+
+main().catch(console.error);

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.tsx

@@ -1,51 +0,0 @@
-import React from 'react';
-import { RouterProvider, useRouter } from './router';
-import { ThemeProvider } from './context/ThemeContext';
-import { Gallery } from './components/Gallery';
-import { DemoMode } from './components/DemoMode';
-import { SpecsPage } from './components/specs';
-
-function AppContent() {
-  const { route, navigate, goBack } = useRouter();
-
-  if (route.page === 'demo') {
-    return (
-      <DemoMode
-        initialScreenId={route.screenId}
-        onBack={goBack}
-        onNavigateToStory={(storyId) => navigate({ page: 'specs', storyId })}
-      />
-    );
-  }
-
-  if (route.page === 'specs') {
-    return (
-      <SpecsPage
-        selectedFeatureId={route.featureId}
-        selectedStoryId={route.storyId}
-        onBack={goBack}
-        onSelectScreen={(screenId) => navigate({ page: 'demo', screenId })}
-        onSelectStory={(storyId) => navigate({ page: 'specs', storyId })}
-      />
-    );
-  }
-
-  return (
-    <Gallery
-      onSelectScreen={(screenId) => navigate({ page: 'demo', screenId })}
-      onShowSpecs={() => navigate({ page: 'specs' })}
-    />
-  );
-}
-
-export function App() {
-  return (
-    <ThemeProvider>
-      <RouterProvider>
-        <AppContent />
-      </RouterProvider>
-    </ThemeProvider>
-  );
-}
-
-export default App;

src/app/App.tsx

@@ -0,0 +1,74 @@
+import { RouterProvider, useRouter } from './router';
+import { ThemeProvider } from '../shared/context/ThemeContext';
+import { NextGraphProvider } from '../shared/context/NextGraphContext';
+import { FestipodDataProvider } from '../shared/context/FestipodDataContext';
+import { AuthGate } from './AuthGate';
+import { ToastContainer } from '../shared/components/sketchy';
+
+// Auth
+import { WelcomeScreen } from '../modules/auth/screens/WelcomeScreen';
+
+// Home
+import { HomeScreen } from '../modules/home/screens/HomeScreen';
+import { SettingsScreen } from '../modules/home/screens/SettingsScreen';
+
+// Event
+import { EventsScreen } from '../modules/event/screens/EventsScreen';
+import { EventDetailScreen } from '../modules/event/screens/EventDetailScreen';
+import { CreateEventScreen } from '../modules/event/screens/CreateEventScreen';
+import { UpdateEventScreen } from '../modules/event/screens/UpdateEventScreen';
+import { InviteScreen } from '../modules/event/screens/InviteScreen';
+import { ParticipantsListScreen } from '../modules/event/screens/ParticipantsListScreen';
+import { MeetingPointsScreen } from '../modules/event/screens/MeetingPointsScreen';
+
+// User
+import { ProfileScreen } from '../modules/user/screens/ProfileScreen';
+import { UpdateProfileScreen } from '../modules/user/screens/UpdateProfileScreen';
+import { UserProfileScreen } from '../modules/user/screens/UserProfileScreen';
+import { FriendsListScreen } from '../modules/user/screens/FriendsListScreen';
+import { ShareProfileScreen } from '../modules/user/screens/ShareProfileScreen';
+import { ConnectScreen } from '../modules/user/screens/ConnectScreen';
+
+function AppContent() {
+  const { route } = useRouter();
+
+  switch (route.page) {
+    case 'welcome': return <WelcomeScreen />;
+    case 'home': return <HomeScreen />;
+    case 'events': return <EventsScreen />;
+    case 'create-event': return <CreateEventScreen />;
+    case 'event-detail': return <EventDetailScreen />;
+    case 'update-event': return <UpdateEventScreen />;
+    case 'invite': return <InviteScreen />;
+    case 'participants': return <ParticipantsListScreen />;
+    case 'meeting-points': return <MeetingPointsScreen />;
+    case 'profile': return <ProfileScreen />;
+    case 'edit-profile': return <UpdateProfileScreen />;
+    case 'friends': return <FriendsListScreen />;
+    case 'share-profile': return <ShareProfileScreen />;
+    case 'connect': return <ConnectScreen />;
+    case 'user-profile': return <UserProfileScreen />;
+    case 'settings': return <SettingsScreen />;
+  }
+}
+
+export function App() {
+  return (
+    <ThemeProvider>
+      <NextGraphProvider>
+        <FestipodDataProvider>
+          <RouterProvider>
+            <div className="app-container">
+              <AuthGate>
+                <AppContent />
+              </AuthGate>
+              <ToastContainer />
+            </div>
+          </RouterProvider>
+        </FestipodDataProvider>
+      </NextGraphProvider>
+    </ThemeProvider>
+  );
+}
+
+export default App;