docs(concept): durabilité écriture↔déconnexion, décision wallet-partagé-unique, rule_bun-first (install pnpm)

caveat_write-durability-across-disconnect + decision_2026-07-20 (wallet partagé = seul mode ; identifiant ≠ username profil) + amendement bun-first. Marqueurs _debt.md inclus (voyagent avec la branche, à réconcilier avant push).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg

.gitignore

@@ -41,3 +41,6 @@ playwright/.auth/
 
 *storybook.log
 storybook-static
+dist-staging/
+*.ngw
+.tasks/

.project/briefs/authorization-matrix.md

@@ -1,175 +0,0 @@
-# Matrice d'autorisations et inventaire des requêtes
-
-**Status:** Incubating — analyse en cours
-**Last updated:** 2026-05-18
-
-## Context
-
-Préalable au refactor multi-store ([brief](./multi-store-refactor.md)) et à toute évolution multi-user. La structure de stores NextGraph cible doit être *dérivée* de :
-
-1. Une matrice d'autorisations (qui peut faire quoi sur quel type de donnée).
-2. Un inventaire des requêtes nécessaires (lectures, abonnements, écritures par écran).
-3. Les partitions naturelles qui en découlent (regroupements de données qui partagent autorisations *et* schéma d'accès).
-
-Ce brief porte cette analyse. Il alimentera la décision finale sur la structure de stores.
-
-## Cadre
-
-### Acteurs (tous authentifiés)
-
-- `Self` — propriétaire de la donnée (varie par type : auteur d'un message, titulaire d'un profil…)
-- `D` — Déclarant d'un événement (celui qui a inséré la référence dans Festipod ; pas l'organisateur réel)
-- `H` — Hôte d'un point de rencontre (celui qui l'a créé)
-- `I` — Inscrit à un point de rencontre
-- `C` — Connexion (« ami ») d'un autre acteur lié à la donnée
-- `U` — Utilisateur authentifié quelconque, sans relation à la donnée
-
-### Verbes
-
-- `créer`
-- `lire` (one-shot)
-- `s'abonner` (lecture longue / réactive)
-- `modifier`
-- `supprimer`
-
-### Conventions
-
-`✓` autorisé · `✗` interdit · `cond` autorisé sous condition (notée) · `—` sans objet
-
-## Décisions cadre (acquises)
-
-- **Tous les utilisateurs sont authentifiés.** Pas d'accès anonyme.
-- **Points de rencontre publics universels.** Tout utilisateur peut lire et s'abonner.
-- **Création de point de rencontre ouverte à tous.** Pas de prérequis (adhésion, invitation).
-- **Hôte = détenteur technique des droits d'écriture** sur un point de rencontre. À ce stade : 1 hôte par PdR, celui qui l'a créé.
-- **Adhésion à une communauté : hors périmètre actuel.** Le rôle « Membre de communauté » n'est pas analysé ici.
-- **Suivi de communauté ou d'utilisateur : hors périmètre actuel.** À reprendre quand la fonctionnalité de discovery par abonnement sera traitée.
-
-## Matrice par type de donnée
-
-### Point de rencontre
-
-| Verbe | Self (= Hôte) | I (autre inscrit) | D (déclarant de l'événement parent) | U (utilisateur lambda) |
-|---|---|---|---|---|
-| créer | ✓ (l'acte de créer rend l'utilisateur hôte) | — | ✗ | ✓ (l'acte le rend hôte) |
-| lire | ✓ | ✓ | ✓ | ✓ |
-| s'abonner | ✓ | ✓ | ✓ | ✓ |
-| modifier | ✓ | ✗ | ✗ | ✗ |
-| supprimer | ✓ | ✗ | ✗ | ✗ |
-
-**Notes :**
-- Pas de différenciation `C` (connexion de l'hôte) — les connexions sont un filtre d'affichage côté UI, pas un droit d'accès, puisque tout est public.
-- Le `D` n'a pas de droit particulier sur les PdR greffés sur son événement déclaré — il a juste déclaré la référence.
-
-### Inscription à un point de rencontre
-
-L'objet « Inscription » lie un utilisateur et un point de rencontre. Représente l'engagement à participer.
-
-| Verbe | Self (l'inscrit) | H (hôte du PdR) | I (autre inscrit au même PdR) | U (utilisateur lambda) |
-|---|---|---|---|---|
-| créer | ✓ (s'inscrire) | ✗ | ✗ | ✓ (l'acte le rend inscrit) |
-| lire | ✓ | ✓ | ? **à trancher** | ? **à trancher** |
-| s'abonner | ✓ | ✓ | ? **à trancher** | ? **à trancher** |
-| modifier | ? **à trancher** (selon les champs modifiables) | ✗ | ✗ | ✗ |
-| supprimer | ✓ (se désinscrire) | ? **à trancher** (modération ? blacklist ?) | ✗ | ✗ |
-
-**Questions ouvertes :**
-- **Visibilité de la liste des inscrits.** Cohérent avec « tout est public » : tous les utilisateurs voient qui s'est inscrit. Mais à confirmer — y a-t-il un cas où on veut cacher la liste (PdR à inscription confidentielle) ?
-- **Champs modifiables d'une inscription.** Booléen seul, ou champs additionnels (commentaire, statut "peut-être", nombre d'accompagnants) ?
-- **Modération par l'hôte.** L'hôte peut-il désinscrire un inscrit (= blacklist) ?
-
-### Événement
-
-| Verbe | Self (= D, déclarant) | H (hôte d'un PdR greffé) | U (utilisateur lambda) |
-|---|---|---|---|
-| créer | ✓ (l'acte rend déclarant) | — | ✓ (l'acte le rend déclarant) |
-| lire | ✓ | ✓ | ✓ |
-| s'abonner | ✓ | ✓ | ✓ |
-| modifier | ? **à trancher** | ? **à trancher** | ? **à trancher** |
-| supprimer | ? **à trancher** | ✗ | ✗ |
-
-**Questions ouvertes :**
-- **Qui peut modifier un événement déclaré ?** Le déclarant seul (modèle propriétaire) ? Tout utilisateur (modèle wiki, pour compléter/corriger) ? Personne après création (modèle immuable, pour éviter les modifications mal intentionnées) ? Cette question est centrale pour le défi de déduplication évoqué dans le README — un modèle wiki facilite la convergence, un modèle propriétaire complique.
-- **Qui peut supprimer ?** Si le déclarant supprime, que deviennent les PdR greffés (orphelins ? supprimés en cascade ? l'événement reste mais marqué supprimé ?) ?
-
-### Profil utilisateur
-
-À déterminer : un seul objet ou split public/privé ?
-
-| Verbe | Self | C (connexion) | U (utilisateur lambda) |
-|---|---|---|---|
-| créer | ✓ (à l'inscription) | — | — |
-| lire (partie publique) | ✓ | ✓ | ? **à trancher** |
-| lire (partie privée) | ✓ | ? **à trancher** | ✗ |
-| s'abonner | ✓ | ? | ? |
-| modifier | ✓ | ✗ | ✗ |
-| supprimer | ✓ (auto-destruction du compte) | ✗ | ✗ |
-
-**Questions ouvertes :**
-- **Split public/privé ?** Le profil contient-il des champs réservés aux connexions ou à l'utilisateur seul (préférences, paramètres, email) ?
-- **Profil entièrement public ?** Cohérent avec « points de rencontre publics » : un visiteur peut voir le profil de l'hôte d'un PdR. Mais le détail (bio, photos, ville…) ?
-
-### Connexion (lien d'amitié)
-
-| Verbe | Self (A, demandeur) | Other (B, l'autre côté de la connexion) | U (utilisateur lambda) |
-|---|---|---|---|
-| créer (demande) | ✓ | — | — |
-| accepter | — | ✓ | ✗ |
-| lire (sa propre liste d'amis) | ✓ | — | — |
-| lire (la liste d'amis d'un autre) | — | — | ? **à trancher** |
-| s'abonner (à sa liste) | ✓ | — | — |
-| modifier | — | — | — |
-| supprimer (rompre la connexion) | ✓ | ✓ | ✗ |
-
-**Questions ouvertes :**
-- **Bilatérale ou unilatérale ?** Le concept « connexion / ami » suggère bilatérale (les deux acceptent). À confirmer ; si oui, il y a deux objets distincts : `DemandeDeConnexion` (unilatérale) et `Connexion` (bilatérale).
-- **Visibilité de la liste d'amis.** Une connexion est-elle observable par des tiers ? « Marie est connectée à Bob » est-il public, restreint, ou privé ?
-
-## Hors périmètre actuel
-
-À reprendre quand ces concepts deviendront actifs :
-
-- **Communauté d'intérêt** (membres, modération, création)
-- **Adhésion à une communauté**
-- **Liste curated** (création, partage, abonnement)
-- **Suivi d'utilisateur ou de communauté** pour discovery distribuée
-
-## Inventaire des requêtes par écran
-
-*À remplir une fois la matrice des autorisations stabilisée.*
-
-Schéma prévu :
-
-| Écran | Lectures one-shot | Abonnements | Écritures | Acteur déclencheur |
-|---|---|---|---|---|
-
-Écrans à analyser (depuis [AGENTS.md](../../AGENTS.md#routing)) :
-
-- `WelcomeScreen` `/`
-- `LoginScreen` `/login`
-- `HomeScreen` `/home`
-- `EventsScreen` `/events`
-- `CreateEventScreen` `/events/new`
-- `EventDetailScreen` `/events/:id`
-- `UpdateEventScreen` `/events/:id/edit`
-- `InviteScreen` `/events/:id/invite` (à voir si encore pertinent)
-- `ParticipantsListScreen` `/events/:id/participants`
-- `MeetingPointsScreen` `/events/:id/meeting-points`
-- `ProfileScreen` `/profile`
-- `UpdateProfileScreen` `/profile/edit`
-- `FriendsListScreen` `/profile/friends`
-- `ShareProfileScreen` `/profile/share`
-- `UserProfileScreen` `/users/:id`
-- `SettingsScreen` `/settings`
-
-## Partitions naturelles dérivées
-
-*À remplir une fois la matrice + l'inventaire stabilisés.*
-
-Heuristique de dérivation : on regroupe dans un même store les données qui (a) partagent leur cellule d'autorisation pour les verbes d'écriture, et (b) sont accédées ensemble dans la majorité des requêtes (pour éviter de multiplier les abonnements).
-
-## See Also
-
-- [Brief : refactor multi-store](./multi-store-refactor.md) — consommateur principal de cette analyse
-- [README §Modèle fonctionnel](../../README.md) — source des acteurs et concepts
-- [Knowledge : data layer](../knowledge/data-layer.md) — état actuel mono-store

.project/briefs/multi-store-refactor.md

@@ -1,126 +0,0 @@
-# Refactor multi-store NextGraph
-
-**Status:** Incubating — aucun travail démarré
-**Last updated:** 2026-05-17
-
-## Context
-
-L'app Festipod est aujourd'hui *mono-store* : tout ce que l'app écrit (events, profils, participations, friendships) atterrit dans le `private_store` de l'utilisateur connecté. C'est un héritage du sample expense-tracker-rdf, formalisé dans [la décision du 2026-03-17](../decisions/2026-03-17-1600-private-store-nuri-scope.md).
-
-Ce choix bloque toute évolution vers du multi-utilisateurs : par construction le `private_store` est non partageable (cf. [data-layer](../knowledge/data-layer.md) et la doc NextGraph officielle — *« It is not possible to share the documents of your private store with anybody else »*). Tant que tout est dans le private_store, Bob ne pourra jamais voir l'event d'Alice.
-
-Le modèle natif NextGraph est *multi-store par utilisateur* (private, protected, public, group, dialog) — chaque type d'information a sa place. Festipod doit s'aligner sur ce modèle avant de pouvoir devenir collaboratif.
-
-**Déclencheur :** discussion du 2026-05-17 sur la suite multi-user. Décision prise : *poser le cap, exécuter plus tard*.
-
-## What We Know
-
-### État actuel du code
-
-Deux fichiers concentrent le hardcoding du store unique :
-
-- `src/shared/utils/ngGraph.ts:30` — `ensureGraphNuri()` retourne `did:ng:${session.private_store_id}` pour TOUTES les entités, peu importe leur nature.
-- `src/shared/hooks/useShapeWithDefaults.ts` — accepte un `storeNuri` mais l'appelant unique (`FestipodDataContext`) lui passe systématiquement le NURI du private_store.
-
-Entités impactées (toutes mélangées dans le même store aujourd'hui) :
-- `FpEvent` — devrait vivre dans un store partagé (logique multi-user)
-- `FpUserProfile` — devrait être en partie privée, en partie publique
-- `FpParticipation` — liée à un event, devrait vivre avec lui
-- `FpMeetingPoint` — actuellement local-only côté types ([`src/shared/data/types.ts:106`](../../src/shared/data/types.ts)), pas encore branché à NextGraph
-- `FpFriendship` — actuellement local-only, naturellement privée
-
-### Modèle cible proposé
-
-Structure hiérarchique en **4 niveaux de Group stores** (pas de private/public pour le métier collaboratif — tout en Group) :
-
-```
-┌─ Group store « index communautaire » ────────────────────┐
-│  Référence tous les events visibles dans la communauté   │
-│  Lecture par tous les membres, sert d'annuaire/discovery │
-│                                                          │
-│  ┌─ Group store « communauté » ──────────────────────┐   │
-│  │  Propriétaire de l'event                          │   │
-│  │  Permissions = qui peut modifier l'event          │   │
-│  │  (organisateurs / membres de la communauté)       │   │
-│  │                                                   │   │
-│  │  ┌─ Group store « event » ─────────────────────┐  │   │
-│  │  │  Tout ce qui se rattache à l'event :        │  │   │
-│  │  │  participations, infos pratiques, discu…    │  │   │
-│  │  │  Membres = participants à l'event           │  │   │
-│  │  │                                             │  │   │
-│  │  │  ┌─ Group store « meeting point » ───────┐  │  │   │
-│  │  │  │  Un RDV de l'event = son propre group │  │  │   │
-│  │  │  │  Permet participations + discu        │  │  │   │
-│  │  │  │  scopées au point de rencontre        │  │  │   │
-│  │  │  └───────────────────────────────────────┘  │  │   │
-│  │  └─────────────────────────────────────────────┘  │   │
-│  └───────────────────────────────────────────────────┘   │
-└──────────────────────────────────────────────────────────┘
-```
-
-Mapping entités → store cible :
-
-| Entité | Store cible | Justification |
-|---|---|---|
-| Event (métadonnées : titre, dates, description) | Group store « communauté » | C'est la communauté qui possède l'event, donc qui contrôle qui peut le modifier |
-| Référence d'event (pointeur depuis l'index) | Group store « index communautaire » | Discovery : « voici les events visibles » |
-| Participation | Group store « event » | Une participation n'a de sens que dans le contexte de son event |
-| MeetingPoint (métadonnées) | Group store « event » | Le RDV appartient à l'event |
-| Participation à un MeetingPoint | Group store « meeting point » | RSVP/présence scopés au RDV |
-| UserProfile (partie publique) | public_store de l'utilisateur | Modèle natif NextGraph |
-| Friendship | private_store de l'utilisateur | Donnée purement personnelle |
-
-### Contrainte SDK bloquante
-
-La création de Group stores et la gestion des invitations/permissions **ne sont pas exposées dans le SDK `@ng-org/web` actuel** (version `0.1.2-alpha.11`). Les méthodes disponibles : `doc_create`, `doc_subscribe`, `sparql_query/update`, `orm_start_*`, `file_get`, `app_request_stream`. Aucune méthode `share_doc`, `invite_user`, `create_group_store`, `accept_invite`. La doc NextGraph annonce qu'*« An API will be provided for permission manipulation »* — pas de date.
-
-**Implication :** le refactor *structurel* (passer d'un store unique à un système de stores par entité) peut commencer sans attendre cette API, en utilisant des placeholders (par ex. continuer à pointer vers `private_store_id` pour les Group stores qui ne peuvent pas encore exister). Mais l'**aboutissement complet** (vrai multi-user, partage entre wallets distincts) dépend de l'arrivée de l'API SDK ou d'un contournement (fork du wallet, accès Rust direct, etc.).
-
-### Implications côté code
-
-Le refactor touche au moins :
-
-1. **Disparition de `ensureGraphNuri()`** comme helper unique. Remplacé par des helpers par entité (`getEventStore(communityId)`, `getParticipationStore(eventId)`, `getProfileStore(scope: 'public' | 'private')`, …) ou par une couche `storeRegistry` qui résout le NURI selon `(entité, contexte)`.
-2. **`useShapeWithDefaults` reste un wrapper utile** mais l'appelant choisit explicitement le store. Aujourd'hui un seul appelant ([`FestipodDataContext`](../../src/shared/context/FestipodDataContext.tsx)), demain N appelants ou un appelant qui résout dynamiquement.
-3. **Chaque entité de domaine déclare son store cible** — soit via un mapping centralisé, soit via une convention (shape → store).
-4. **`bootstrapWallet()`** ([`src/shared/utils/ngBootstrap.ts`](../../src/shared/utils/ngBootstrap.ts)) doit être revu : on ne seed plus dans un unique store, on doit seed dans plusieurs (ou décider que seed ne crée que des données de l'utilisateur courant — ce qui colle mieux à la réalité multi-user).
-5. **`FestipodDataContext`** : structurer les hooks par entité, chacun avec son store résolu.
-
-## Open Questions
-
-1. **Quand crée-t-on un Group store de communauté ?** L'API n'existe pas en SDK aujourd'hui. Faut-il que ce soit un acte explicite de l'utilisateur (« créer une communauté ») ou bien tout user a une communauté par défaut à la création de son wallet ?
-2. **Comment Bob connaît-il l'index communautaire d'Alice ?** Discovery toujours ouverte — possiblement via le public_store d'Alice qui annonce le NURI de l'index communautaire.
-3. **Faut-il vraiment 4 niveaux d'imbrication ?** Le « meeting point comme group store » mérite d'être validé — quel besoin réel justifie une couche de permission supplémentaire vs un simple sous-graphe du group store de l'event ?
-4. **Que devient le seed de démo** quand l'app est multi-store et que les Group stores ne peuvent pas encore exister ? Mode dégradé en private_store le temps que le SDK rattrape, ou retirer le seed en mode connecté ?
-5. **Migration des wallets existants** : les wallets de test ont déjà des données dans le private_store. Comment on les fait évoluer (script de migration, wipe and reseed, ignore) ?
-6. **Bootstrap d'un user vierge** : à la première connexion, faut-il auto-créer un Group store communautaire « par défaut » pour lui ou attendre une action utilisateur ?
-
-## Possible Approaches
-
-Esquisses sans engagement (les arbitrages se feront dans une décision dédiée au moment de l'exécution) :
-
-- **Refactor structurel d'abord, partage ensuite.** Réorganiser l'app en multi-store dès maintenant en utilisant `private_store_id` comme placeholder pour les Group stores manquants. Quand l'API arrive, on remplace les placeholders par de vrais NURIs de Group stores.
-- **Registry centralisé** vs **résolution par convention**. Soit un `storeRegistry.ts` qui mappe explicitement `(entité, contexte) → NURI`, soit chaque shape porte sa propre logique de scope.
-- **Big-bang** vs **par entité**. Tout migrer en un coup vs migrer entité par entité (commencer par Event qui est le plus stratégique).
-- **Maintenir un mode mono-store** parallèle pour le dev/demo tant que les Group stores ne sont pas fonctionnels.
-
-## Out of Scope
-
-Ce brief — et le refactor qui en découlera — **ne traite pas** :
-- L'invitation effective d'utilisateurs à un Group store (capability sharing, Nuri d'invitation)
-- La gestion des permissions par rôle (organisateur / membre / lecteur)
-- La résolution du problème de discovery cross-wallet
-- Le contournement éventuel de l'UI wallet (jugée dysfonctionnelle dans cette conversation)
-- Le mode P2P direct sans broker
-
-Ces sujets relèvent d'un **second chantier multi-user** dont le refactor multi-store est seulement le *prérequis structurel*.
-
-## Starting Points
-
-- [decision: private_store NURI scope](../decisions/2026-03-17-1600-private-store-nuri-scope.md) — la décision actuelle qu'on viendra modifier
-- [knowledge: data-layer](../knowledge/data-layer.md) — état actuel du pattern d'écriture
-- [`src/shared/utils/ngGraph.ts`](../../src/shared/utils/ngGraph.ts) — point de hardcoding principal
-- [`src/shared/hooks/useShapeWithDefaults.ts`](../../src/shared/hooks/useShapeWithDefaults.ts) — l'autre point de hardcoding
-- [`src/shared/context/FestipodDataContext.tsx`](../../src/shared/context/FestipodDataContext.tsx) — l'unique appelant aujourd'hui
-- [`src/shared/utils/ngBootstrap.ts`](../../src/shared/utils/ngBootstrap.ts) — le seed à revoir
-- NextGraph docs : [Documents et Stores](https://docs.nextgraph.org/en/documents/), [Getting started](https://docs.nextgraph.org/en/getting-started/)

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

@@ -0,0 +1,9 @@
+# Doc-debt — app-architecture
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Raw markers (consolidate into blocks, then delete)
+- TOUCHED src/shared/context/FestipodDataContext.tsx @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/auth/screens/AccessGateScreen.tsx @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/shared/context/AccountContext.tsx @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

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

@@ -0,0 +1,24 @@
+---
+type: _overview
+summary: Architecture feature-based de l'app — modules par domaine, invariant d'imports, app shell à providers, routing path-based, écrans et registre
+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
+
+Comment le code de l'app est **structuré** et **assemblé**. Architecture *feature-based* : le code est organisé par **domaine métier** (module), pas par couche technique.
+
+**À lire en premier :** [[rule_module-imports]] — l'invariant central qui garde les modules découplés.
+
+## Liens
+
+- [[knowledge_module-structure]] — arborescence modules + couche `shared/`
+- [[knowledge_app-shell]] — `src/app/`, pile de providers, points d'entrée
+- [[knowledge_routing]] — routing path-based (History API), table de routes, hooks
+- [[knowledge_screens]] — inventaire des écrans, registre, lib de composants
+- [[knowledge_screen-pattern]] — anatomie canonique d'un écran (sans props, layout flex, showToast)
+- [[knowledge_styling-system]] — `src/index.css`, classes `app-*`, vars, pièges (Tailwind non-utilisé, `user-content` inerte)
+- [[cookbook_add-screen]] — procédure pour câbler un nouvel écran (registre + router + shell)
+- `tech-stack` — build, bundler Bun, commandes

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

@@ -0,0 +1,20 @@
+---
+type: cookbook
+summary: Procédure pour ajouter un écran — créer le composant dans le module, l'enregistrer dans src/screens/index.ts, ajouter la route dans router.tsx, le monter dans App.tsx, et un alias screenNameMap si testé en BDD
+---
+
+# Cookbook : ajouter un écran
+
+Un écran doit être câblé à **plusieurs endroits** — en oublier un produit des bugs silencieux (cf. le cas `ConnectScreen`, [[knowledge_screens]]).
+
+1. **Créer le composant** : `src/modules/{module}/screens/MyScreen.tsx`, en suivant [[knowledge_screen-pattern]] (fonction sans props, `useFestipodData`/`useNavigate`/`useParams`, layout flex, style via [[knowledge_styling-system]]). Respecter [[rule_module-imports]] (importer seulement depuis `shared/`).
+
+2. **Enregistrer dans le registre** : `src/screens/index.ts` — ajouter l'import + l'entrée (`id`, `name` FR, `path`, `component`). **Étape la plus oubliée** : un écran absent du registre est invisible à Storybook et aux consommateurs du registre, même s'il fonctionne en route.
+
+3. **Ajouter la route** : `src/app/router.tsx` — étendre le type `Route`, ajouter le cas dans `parsePath()` (et la conversion inverse si présente).
+
+4. **Monter dans le shell** : `src/app/App.tsx` — ajouter le cas dans le switch qui mappe `route.page` → composant.
+
+5. **(Si testé en BDD)** : ajouter un alias dans `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`) si le nom français du `.feature` ne se résout pas trivialement vers l'`id`. Voir concept `bdd-testing`.
+
+> Vérifier la cohérence : l'`id` doit être identique entre le registre, le router et `screenNameMap`. Un écart silencieux = écran injoignable ou non rendu.

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

@@ -0,0 +1,33 @@
+---
+type: knowledge
+summary: src/app/ est le shell réel de l'app — App.tsx empile les providers (Theme > NextGraph > FestipodData > Router) et bascule l'écran selon la route
+---
+
+# App shell
+
+`src/app/` est le **shell de l'app réelle** (mobile web app), pas un outil de prototypage.
+
+> Note de migration : d'anciennes notes décrivaient `src/app/` comme un « prototyping tool » en routing par hash (`#/`, `#/demo/...`). C'est **périmé** depuis la restructuration en vraie app. La vérité courante : routing path-based via History API (voir [[knowledge_routing]]).
+
+## Pile de providers
+
+`App.tsx` empile les providers puis bascule l'écran selon la route courante :
+
+```
+ThemeProvider
+  └ NextGraphProvider        (cycle de connexion NextGraph — concept data-layer)
+      └ FestipodDataProvider (données, mode connected/demo — concept data-layer)
+          └ RouterProvider   (route courante + navigate)
+```
+
+Le composant racine lit `useRouter()` pour résoudre `route.page` → écran à rendre.
+
+## Points d'entrée
+
+| Fichier | Rôle |
+|---|---|
+| `src/index.ts` | `Bun.serve()` — serveur HTTP, sert `index.html` + rapport cucumber |
+| `src/index.html` | Entrée HTML, charge `src/app/frontend.tsx` |
+| `src/app/frontend.tsx` | Racine React, rend `<App />` |
+
+Le build et le bundler (Bun + Tailwind, alias `@/* → ./src/*`) sont documentés dans le concept `tech-stack`.

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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+summary: Arborescence feature-based — modules métier (event, user, home, auth, workshop, meeting, notification) et couche shared/ importable par tous
+---
+
+# Structure des modules
+
+Le code est organisé par **domaine métier**, pas par couche technique.
+
+```
+src/modules/
+  event/          # Événements : CRUD, discovery, participants, points de rencontre
+  user/           # Profils, connexions (« amis »), partage
+  home/           # Dashboard, settings
+  auth/           # Login, welcome/onboarding
+  workshop/       # Specs atelier (features seulement, pas d'écrans)
+  meeting/        # Specs point de rencontre (features seulement)
+  notification/   # Specs notification (features seulement)
+```
+
+Chaque module peut contenir :
+- `screens/` — composants d'écran React
+- `features/` — fichiers Gherkin `.feature` (specs BDD, voir concept `bdd-testing`)
+- `steps/{ui,data,e2e}/` — step definitions Cucumber par couche
+
+## Couche `shared/`
+
+`src/shared/` contient tout le réutilisable inter-modules :
+
+| Répertoire | Contenu |
+|---|---|
+| `components/` | Lib de composants UI (voir [[knowledge_screens]]) |
+| `context/` | `ThemeContext`, `NextGraphContext`, `FestipodDataContext` (voir concept `data-layer`) |
+| `data/` | User stories, `features.ts` (auto-généré), `seedData.ts`, `types.ts` |
+| `hooks/` | `useShapeWithDefaults` (NextGraph) |
+| `shapes/` | SHEX + bindings ORM (voir concept `data-layer`) |
+| `utils/` | `ngSession.ts`, `ngBootstrap.ts`, `ngGraph.ts` |
+| `steps/`, `support/` | Step definitions et hooks Cucumber partagés (concept `bdd-testing`) |
+| `lib/` | Helpers (`cn`, etc.) |
+
+La règle de dépendance entre modules et `shared/` est dans [[rule_module-imports]].

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

@@ -0,0 +1,36 @@
+---
+type: knowledge
+summary: Routing path-based via History API (router maison dans src/app/router.tsx) — table de routes, hooks useNavigate/useParams, pas de prop drilling
+---
+
+# Routing
+
+Routing **path-based** via l'History API — router maison dans `src/app/router.tsx` (`window.history.pushState` + `popstate`, `parsePath(pathname)`). Pas de routing par hash.
+
+## Table de routes
+
+| Path | Écran |
+|---|---|
+| `/` | WelcomeScreen |
+| `/login` | LoginScreen |
+| `/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` | (connexion) |
+| `/users/:id` | UserProfileScreen |
+| `/settings` | SettingsScreen |
+
+> Cette table reflète `parsePath()` dans `router.tsx` — y revenir si elle évolue, c'est la source de vérité.
+
+## Hooks
+
+Les écrans utilisent `useNavigate()` et `useParams()` du router — **pas de prop drilling**. Le shell intercepte la navigation pour basculer l'écran affiché (voir [[knowledge_app-shell]]).

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

@@ -0,0 +1,43 @@
+---
+type: knowledge
+summary: Anatomie canonique d'un écran — fonction nommée sans props, lit tout via useFestipodData/useNavigate/useParams, layout flex colonne (Header / contenu scrollable / BottomNav pour les écrans hub), feedback via showToast, libellés français en dur
+---
+
+# Pattern canonique d'un écran
+
+Tous les écrans suivent la même forme. La connaître évite de réinventer ou de diverger.
+
+## Forme
+
+```tsx
+export function MyScreen() {              // fonction nommée, JAMAIS de props
+  const navigate = useNavigate();
+  const { eventId, userId } = useParams();
+  const { getEvent, currentUser, … } = useFestipodData();
+  const [local, setLocal] = useState(…);  // état local d'écran (étapes, sélections)
+
+  const handleAction = () => {
+    // …muter via useFestipodData
+    showToast('Message', 'success');       // feedback
+    navigate('/path');
+  };
+
+  return (
+    <div style={{ display:'flex', flexDirection:'column', height:'100%' }}>
+      <Header title="…" /* left/right optionnels */ />
+      <div style={{ flex:1, overflow:'auto' }}>{/* contenu scrollable */}</div>
+      <BottomNav active="…" />              {/* seulement sur les écrans hub */}
+    </div>
+  );
+}
+```
+
+## Invariants
+
+- **Zéro prop** : l'écran ne reçoit rien ; tout vient du contexte/hooks (`useFestipodData`, `useNavigate`, `useParams`). Exceptions légitimes : `LoginScreen`/`WelcomeScreen` n'utilisent pas `useFestipodData` (auth/intro).
+- **Layout** : flex colonne pleine hauteur ; `Header` en haut, contenu en `flex:1; overflow:auto`, `BottomNav` en bas **uniquement pour les écrans hub** (Home, Events, Profile, Friends). Les écrans de flux (création, édition, détail) n'ont pas de `BottomNav`.
+- **Feedback** : `showToast(message, 'success'|'info'|'error')` (mécanisme `ToastContainer` exporté par `sketchy/`).
+- **Libellés** : **français, en dur** — aucun i18n, aucune clé de traduction dans le projet.
+- Style : voir [[knowledge_styling-system]]. Navigation/registre : [[knowledge_routing]], [[knowledge_screens]].
+
+Pour **créer** un écran (les 3+ endroits à câbler), voir [[cookbook_add-screen]].

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

@@ -0,0 +1,40 @@
+---
+type: knowledge
+summary: Inventaire des écrans par module, registre central src/screens/index.ts, et lib de composants sous shared/components/sketchy/ — dont le NOM est conservé mais qui rend un thème moderne (pas hand-drawn)
+---
+
+# Écrans et composants
+
+## Lib de composants : `sketchy/` = thème moderne
+
+⚠️ **Piège de nommage.** La lib de composants vit sous `src/shared/components/sketchy/` (chemin conservé, importé par ~17 écrans), **mais elle ne rend plus un style « hand-drawn »** : elle a été portée vers un thème **moderne** (DM Sans / orange, classes `app-*`). Le *chemin d'import* est bon, la *description visuelle « sketchy »* est périmée. Ne pas réintroduire d'esthétique dessinée en se fiant au nom du dossier.
+
+Composants typiques : `Header`, `BottomNav`, `Button`, `Card`, `Input`, `Badge`, `Avatar`/`AvatarStack`, `Text`/`Title`, `Toggle`, `ListItem`, `Divider`, `Placeholder`, `BrokerBanner`, `NgStatus`.
+
+## Registre d'écrans
+
+`src/screens/index.ts` importe tous les écrans de tous les modules et expose :
+
+```typescript
+export const screenGroups   // groupés par domaine (home, events, user, general)
+export const screens        // liste à plat
+export function getScreen(id): Screen | undefined
+```
+
+Utilisé notamment par Storybook (voir concept `tech-stack`) pour parcourir les écrans.
+
+## Inventaire
+
+Écrans par module (IDs = clés du registre) :
+
+- **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/** : `AccessGateScreen` — la **barrière d'accès** (login NextGraph + saisie de l'identifiant), rendue par `src/app/AuthGate.tsx`, **hors registre/routing** (ce n'est pas un écran routé). Les anciens `LoginScreen` puis `ConnexionScreen` ont été retirés (cf. concept `app-security`, [[knowledge_authentication]]).
+
+> Le mapping path → écran est dans [[knowledge_routing]]. La plupart des écrans consomment `useFestipodData()` (concept `data-layer`) ; exceptions : `WelcomeScreen` et la barrière `AccessGateScreen`.
+
+## Piège : registre incomplet
+
+Le registre doit lister **tous** les écrans. Cas observé : `ConnectScreen` (`src/modules/user/screens/`, routé `/profile/connect`, monté dans `App.tsx`) est **absent de `src/screens/index.ts`** → invisible à Storybook et aux consommateurs du registre, bien qu'il fonctionne en route. Toujours vérifier que l'écran est enregistré (cf. [[cookbook_add-screen]]).
+

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

@@ -0,0 +1,32 @@
+---
+type: knowledge
+summary: src/index.css est la source de vérité du style — variables --app-* (couleurs, rayons, police DM Sans) et classes app-* rendues par les composants ; les écrans combinent ces classes avec des styles inline ; Tailwind est dans le build mais les écrans n'utilisent pas d'utilitaires Tailwind ; la classe user-content est inerte
+last_checked: 2026-06-15
+---
+
+# Système de style
+
+**Source de vérité : `src/index.css`** (thème « Modern clean — DM Sans »). C'est là que vivent les variables CSS et les classes `app-*`. Pas de fichiers CSS par module.
+
+## Variables (`:root`)
+
+- Couleurs : `--app-black #1a1a1a`, `--app-gray #888`, `--app-bg/--app-white #fff`, accent orange `--app-accent #E8590C` (+ `-light #FFF7ED`, `-border`, `-dark #C05621`), vert `--app-green #22543D` (+ `-light`, `-border`, `-text`).
+- Rayons : `--app-radius 16px`, `--app-radius-sm 12px`, `--app-radius-xs 8px`.
+- Police : `--font-app: 'DM Sans', …`.
+
+## Classes `app-*`
+
+Définies dans `index.css`, rendues par les composants de `shared/components/sketchy/` : `app-btn` (+ `-primary`/`-green`), `app-input`, `app-card`, `app-title`/`app-subtitle`/`app-text`, `app-badge`, `app-toggle`, `app-checkbox`, `app-header`, `app-navbar`, `app-list-item`, `app-avatar`, `app-placeholder`, `app-divider`, `app-tab`.
+
+## Conventions d'écriture d'un écran
+
+- Utiliser les **composants `sketchy/`** (qui portent les classes `app-*`) pour boutons/inputs/cartes/typo.
+- Pour le **layout** (flex, gaps, paddings, couleurs ponctuelles), les écrans utilisent des **styles inline** (`style={{…}}`) — c'est le pattern normal, pas une déviation.
+- Icônes : **emojis**/symboles Unicode (📅 📍 📝 🎪…), pas d'imports d'icônes en général.
+- Largeur : `.app-container` borne à **`max-width: 768px`, `height: 100dvh`** (mobile-first/tablette portrait). Aucune media query — pas de responsive desktop.
+
+## Pièges
+
+- **Tailwind est dans le build** (plugin `bun-plugin-tailwind`, dépendance `tailwindcss`), mais **les écrans n'utilisent pas de classes utilitaires Tailwind** — le style réel passe par `app-*` + inline. Ne pas « tailwindiser » un écran en pensant suivre la convention.
+- **`user-content` est une classe INERTE** : utilisée sur de nombreux titres/noms dans les écrans, **sans aucune définition CSS**. C'est un marqueur legacy sans effet — ne pas s'appuyer dessus pour styler, ne pas croire qu'elle fait quelque chose.
+- Pas de **dark mode** : le toggle « darkMode » de `SettingsScreen` n'est branché à rien.

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

@@ -0,0 +1,24 @@
+---
+type: rule
+summary: Un module n'importe QUE depuis shared/ (et le registre d'écrans) — jamais depuis un autre module ; c'est l'invariant qui garde l'architecture feature-based
+---
+
+# Règle : un module n'importe jamais d'un autre module
+
+**Les modules importent uniquement depuis `shared/` — jamais entre eux.**
+
+```
+src/modules/event/screens/EventDetailScreen.tsx
+  ✅ import depuis 'shared/components/...'
+  ✅ import depuis 'shared/context/FestipodDataContext'
+  ✅ import depuis 'src/screens' (types du registre)
+  ❌ import depuis 'modules/user/screens/...'
+```
+
+## Pourquoi
+
+C'est ce qui rend l'architecture *feature-based* réelle et pas cosmétique : chaque domaine reste un bloc autonome, déplaçable/supprimable sans casser les autres. Tout besoin partagé **remonte dans `shared/`** ; toute dépendance inter-domaines passe par un contrat de `shared/` (souvent `FestipodDataContext` ou le registre d'écrans), jamais par un import direct.
+
+## Vérifier
+
+`grep -rE "from '\.\./\.\./(event|user|home|auth|workshop|meeting|notification)/" src/modules/` ne doit rien remonter d'un module vers un *autre* module. Un import qui croise deux noms de modules différents est une violation.

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

@@ -0,0 +1,9 @@
+# Doc-debt — app-security
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Raw markers (consolidate into blocks, then delete)
+- TOUCHED src/modules/auth/screens/AccessGateScreen.tsx @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/auth/steps/ui/barriere-acces.steps.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/auth/steps/data/connexion.steps.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

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

@@ -0,0 +1,21 @@
+---
+type: _overview
+summary: Sécurité & confidentialité de Festipod — l'isolation entre périmètres est assurée par le SDK de données, l'app lui fait confiance et ne porte aucune logique d'autorisation dans les écrans ; authentification par wallet ; matrice d'autorisations cible en incubation
+triggers:
+  keywords: [sécurité, security, confidentialité, privacy, accès, "access control", contrôle d'accès, trust, confiance, authz, autorisation, permission, wallet, auth, authentification, anonyme, identité, login, scope, isolation]
+  paths: ["src/modules/auth/**", "src/shared/context/NextGraphContext.tsx"]
+---
+
+# App security
+
+Le modèle de **sécurité, confidentialité et autorisations** de Festipod.
+
+- **Modèle appliqué** — l'**isolation entre périmètres** (public / protected / private) est **assurée par le SDK de données** (`@ng-eventually/client`), qui n'expose à chaque utilisateur que ce à quoi il a droit. L'app **fait confiance** au SDK : aucun écran ne porte de logique d'autorisation. Voir [[knowledge_trust-model]].
+- **Matrice d'autorisations cible** — le détail *qui peut faire quoi* par acteur × verbe (données personnelles = réseau, anonymat via inbox de notification) : [[brief_2026-05-18_authorization-matrix]]. **Incubation.** Graduera en `rule_`/`behavior_` à mesure que le produit se cale.
+
+## Liens
+
+- [[knowledge_trust-model]] — l'app délègue l'isolation au SDK, pas de contrôle d'accès dans les écrans
+- [[knowledge_authentication]] — auth par wallet, tous authentifiés, pas d'accès anonyme
+- [[brief_2026-05-18_authorization-matrix]] — matrice d'autorisations cible (incubation)
+- Concept `functional-domain` → [[knowledge_data-scopes-and-discovery]] — quel scope pour quelle entité (fait produit)

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

@@ -0,0 +1,126 @@
+---
+type: brief
+summary: Matrice d'autorisations cible par type de donnée (PdR, inscription, événement, profil, connexion) exprimée en scopes public/protected/private + dialog ; décisions cadre acquises (tous authentifiés, PdR publics, données personnelles = réseau, notification par inbox identifiée-ou-anonyme) ; questions ouvertes sur modèle d'écriture événement et identité de l'hôte
+last_updated: 2026-05-18
+---
+
+# Matrice d'autorisations et inventaire des requêtes
+
+**Status:** Incubating — modèle cible, non figé en règles.
+
+## Context
+
+Le modèle **cible** de qui-peut-quoi. La confidentialité de Festipod se dérive de : (1) une matrice d'autorisations par acteur × verbe ; (2) l'inventaire des requêtes par écran ; (3) les **périmètres** (scopes) qui en découlent — données partageant à la fois autorisation *et* schéma d'accès. Le placement concret entité → scope est un fait produit : concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]. L'isolation est **assurée par le SDK de données** ([[knowledge_trust-model]]).
+
+## Cadre
+
+### Acteurs (tous authentifiés)
+
+`Alice` (point de vue, propriétaire de la donnée en focus) · `Bob` (second protagoniste, relations bilatérales) · `D` (déclarant d'événement) · `H` (hôte d'un PdR) · `I` (inscrit) · `C` (connexion) · `U` (utilisateur lambda sans relation).
+
+### Verbes
+
+`créer` · `lire` (one-shot) · `s'abonner` (lecture réactive) · `modifier` · `supprimer`. Conventions : `✓` autorisé · `✗` interdit · `cond` sous condition · `—` sans objet.
+
+## Décisions cadre (acquises)
+
+- **Tous authentifiés.** Pas d'accès anonyme.
+- **Points de rencontre publics universels.** Tout utilisateur peut lire et s'abonner.
+- **Création de PdR ouverte à tous.** Pas de prérequis.
+- **Hôte = détenteur des droits d'écriture** sur un PdR (1 hôte, le créateur ; le fait d'être hôte est public).
+- **Informations personnelles = réservées au réseau.** Visibles seulement au titulaire et à ses connexions : participations, intégralité du profil, liste de connexions, et tout état déclaratif dont la divulgation serait une fuite. Statut « public » (PdR, événement) et « personnel » (profil, participations, connexions) coexistent dans le même utilisateur.
+- **Connexion bilatérale.** Existe après acceptation des deux côtés. Deux objets : `DemandeDeConnexion` (unilatérale, transitoire) et `Connexion` (bilatérale, persistante).
+- **Notification d'inscription via l'inbox du PdR.** L'acte « s'inscrire » est composite : (a) écriture d'un objet `Inscription` dans le périmètre *protected* de l'inscrit, (b) dépôt d'un lien dans l'**inbox** du document PdR. L'expéditeur est **identifié si connexion de l'hôte, anonyme sinon** — propriété du modèle de données.
+- **Adhésion à une communauté / suivi : hors périmètre actuel.**
+
+## Matrice par type de donnée
+
+### Point de rencontre
+
+| Verbe | Alice (= Hôte) | I (autre inscrit) | D (déclarant parent) | U (lambda) |
+|---|---|---|---|---|
+| créer | ✓ (rend hôte) | — | ✗ | ✓ (rend hôte) |
+| lire | ✓ | ✓ | ✓ | ✓ |
+| s'abonner | ✓ | ✓ | ✓ | ✓ |
+| modifier | ✓ | ✗ | ✗ | ✗ |
+| supprimer | ✓ | ✗ | ✗ | ✗ |
+
+Notes : pas de différenciation `C` (les connexions sont un filtre d'affichage UI, pas un droit, tout étant public). Le `D` n'a aucun droit particulier sur les PdR greffés sur son événement.
+
+### Inscription à un point de rencontre
+
+`Inscription` lie un utilisateur et un PdR. **Donnée personnelle** (inscrit + ses connexions). Acte composite (a)+(b) ci-dessus.
+
+| Verbe | Alice (inscrite) | C (connexion) | H (hôte) | I (autre inscrit) | U |
+|---|---|---|---|---|---|
+| créer (acte composite) | ✓ | — | ✗ | ✗ | ✓ (rend inscrite) |
+| lire le contenu | ✓ | ✓ | cond : ✓ si H ∈ connexions(Alice) ; sinon lien opaque | cond : ✓ si I ∈ connexions(Alice) | ✗ |
+| s'abonner | ✓ | ✓ | cond (idem) | cond (idem) | ✗ |
+| lire l'inbox du PdR (entrées brutes) | — | — | ✓ | ✗ | ✗ |
+| modifier | ? **à trancher** (selon champs) | ✗ | ✗ | ✗ | ✗ |
+| supprimer | ✓ (se désinscrire ; retirer le lien de l'inbox si possible) | ✗ | cond : modération inbox seule (ne supprime pas l'objet) | ✗ | ✗ |
+
+**Visibilité hôte : résolue** (identifiée si connecté, anonyme sinon). **Questions ouvertes :** champs modifiables d'une inscription (booléen seul ou +commentaire/statut/accompagnants ?) ; **suppression côté inbox** — un déposant peut-il retirer son lien d'un doc qu'il ne contrôle pas ?
+
+### Événement
+
+| Verbe | Alice (= D) | H (hôte d'un PdR greffé) | U |
+|---|---|---|---|
+| créer | ✓ (rend déclarant) | — | ✓ (rend déclarant) |
+| lire / s'abonner | ✓ | ✓ | ✓ |
+| modifier | ? **à trancher** | ? **à trancher** | ? **à trancher** |
+| supprimer | ? **à trancher** | ✗ | ✗ |
+
+**Questions ouvertes :** qui peut **modifier** un événement déclaré — déclarant seul (propriétaire) ? tout utilisateur (wiki) ? personne (immuable) ? Central pour la déduplication (concept `functional-domain`, [[brief_2026-06-15_event-deduplication]]). Qui peut **supprimer**, et que deviennent les PdR greffés (orphelins/cascade/marqué supprimé) ?
+
+### Profil utilisateur
+
+**Rien dans le profil n'est public.** Deux périmètres : **profil réseau** (Alice + connexions : nom, avatar, bio, ville, intérêts) ; **profil privé** (Alice seule : settings, email, préférences).
+
+| Verbe | Alice | C | U |
+|---|---|---|---|
+| créer | ✓ (à l'inscription) | — | — |
+| lire — réseau | ✓ | ✓ | ✗ |
+| lire — privé | ✓ | ✗ | ✗ |
+| s'abonner | ✓ | ✓ (réseau) | ✗ |
+| modifier | ✓ | ✗ | ✗ |
+| supprimer (compte) | ✓ | ✗ | ✗ |
+
+**Tension à résoudre :** un PdR est lisible par tous, mais son hôte ne devrait pas être identifiable par un lambda. Trois positions : (i) **pseudonyme par identité seule** (nom/avatar résolus seulement aux connexions) ; (ii) **identité dénormalisée dans l'offre** (l'hôte choisit une « carte de visite » par PdR, vivant dans l'objet PdR, profil fermé) ; (iii) **anonymat de l'hôte** (identité révélée seulement aux connexions). À trancher. Autres : composition champ-par-champ de chaque périmètre ; statut du `username` (public/réseau/supprimé ?).
+
+### Connexion (lien d'amitié)
+
+Bilatérale. `DemandeDeConnexion` (unilatérale, en attente) → `Connexion` (bilatérale, à l'acceptation ; ouvre l'accès aux données personnelles). La liste de connexions d'Alice est **personnelle** (Alice + ses connexions).
+
+| Verbe | Alice (initiatrice) | Bob (autre côté) | C | U |
+|---|---|---|---|---|
+| créer la demande | ✓ | — | — | — |
+| accepter | — | ✓ | — | ✗ |
+| lire la liste d'Alice | ✓ | ✓ | ✓ | ✗ |
+| s'abonner | ✓ | ✓ | ✓ | ✗ |
+| supprimer (rompre A↔B) | ✓ | ✓ | ✗ | ✗ |
+
+**Questions ouvertes :** granularité côté Bob (voit-il toute la liste d'Alice ou juste A↔B ? — conséquence du principe : toute la liste) ; découvrabilité « amis d'amis » (Alice voit-elle Bob↔Carole ? — non, sauf si Carole ∈ connexions(Alice)).
+
+## Périmètres dérivés
+
+Heuristique : même périmètre si (a) même cellule d'autorisation en écriture *et* (b) accédées ensemble. Trois **scopes** émergent, plus le cas bilatéral :
+
+| Périmètre | Écriture | Lecture | Données |
+|---|---|---|---|
+| **public** | Alice seule | Tous | PdR hébergés par Alice ; événements déclarés *(sous réserve du modèle d'écriture)* |
+| **protected** (réseau) | Alice seule | Alice + connexions | Profil réseau ; participations ; index des connexions |
+| **private** | Alice seule | Alice seule | Profil privé (settings, email, préférences) |
+| **dialog** (A↔B) | Alice et Bob | Alice et Bob | La `Connexion` bilatérale (+ matière à messagerie future) |
+
+La **`Connexion` bilatérale** a *deux* écrivains → périmètre **dialog** dédié à la paire ; l'**index « toutes les connexions d'Alice »** vit en *protected* (liste les références des connexions). L'**inbox du PdR** est un attribut du document public, pas un périmètre séparé.
+
+## Inventaire des requêtes par écran
+
+*À remplir une fois la matrice stabilisée.* Schéma prévu : `| Écran | Lectures one-shot | Abonnements | Écritures | Acteur déclencheur |`. Écrans à analyser : voir la table de routes (concept `app-architecture`).
+
+## See Also
+
+- Concept `functional-domain` → [[knowledge_data-scopes-and-discovery]] — placement entité → scope + découverte
+- [[knowledge_trust-model]] — l'isolation est assurée par le SDK
+- `README.md §Modèle fonctionnel` — source des acteurs

.project/concepts/app-security/decision_2026-07-06_identifier-at-access-barrier.md

@@ -0,0 +1,45 @@
+---
+type: decision
+summary: L'identifiant de l'espace virtuel se saisit à la barrière d'accès (AccessGateScreen), dans le même acte que l'ouverture du wallet ; l'écran de « login perçu » séparé (ConnexionScreen, « choisissez un nom d'utilisateur ») est retiré ; l'identifiant est un id technique normalisé en minuscules, pas un username Festipod
+---
+
+# Décision (2026-07-06) : identifiant saisi à la barrière d'accès
+
+## Contexte
+
+Le flux stopgap de [[decision_2026-06-15_shared-wallet-login-flow]] enchaînait **deux
+écrans** : (1) `AccessGateScreen`, la barrière d'accès (vrai login NextGraph, ouverture du
+wallet partagé) ; (2) `ConnexionScreen`, un « login perçu » où l'utilisateur choisissait un
+**nom d'utilisateur**. Cette identité applicative était en réalité la clé du **wallet virtuel**
+(clé du compte shim / cap owner), pas un username produit — le cadrage « nom d'utilisateur »
+était donc trompeur (logique `setUsername` confuse).
+
+## Décision
+
+L'utilisateur saisit son **identifiant** directement dans `AccessGateScreen`, **dans le même
+acte** qui ouvre le wallet (« Entrer » enregistre l'identifiant puis déclenche `connect()`).
+`ConnexionScreen` est **supprimé**. L'identifiant :
+
+- est un **id technique** qui nomme l'espace virtuel (un pseudo en pratique, **pas** un
+  username Festipod) ;
+- est **normalisé** à la saisie (trim, `@` retiré, **minuscules**) et persisté avant la
+  redirection broker (donc il survit au round-trip) ;
+- **est** l'id d'identité remis au SDK (`setCurrentUser`), et la clé des caps et du compte
+  shim — plus de handle à casse mixte à réconcilier.
+
+`AuthGate` affiche donc la barrière tant que le wallet n'est pas ouvert **ou** que l'identifiant
+n'est pas posé, puis l'app directement — sans écran intermédiaire.
+
+## Alternatives écartées
+
+- **Garder les deux écrans** : le second écran « nom d'utilisateur » perpétuait la confusion
+  entre identité-produit et identifiant-de-wallet, et ajoutait une étape sans valeur.
+- **Dériver l'identifiant du wallet** (pas de saisie) : impossible ici — le wallet partagé est
+  unique ; l'identifiant est précisément ce qui distingue les espaces virtuels au sein de ce
+  wallet (émulation, cf. concept `data-layer` et le SDK `@ng-eventually/client`).
+
+## Portée
+
+Supersede la partie « écran 2 / login perçu » de [[decision_2026-06-15_shared-wallet-login-flow]]
+(l'ouverture du wallet partagé via broker reste inchangée). État courant du flux :
+[[knowledge_authentication]].

.project/concepts/app-security/decision_2026-07-20_shared-wallet-only-mode.md

@@ -0,0 +1,32 @@
+---
+type: decision
+summary: Le wallet partagé est le SEUL mode de fonctionnement (le polyfill @ng-eventually/client en dépend comme backend de données) ; le repli « sans wallet partagé » est retiré — mauvaise config → écran d'erreur franc, plus de formulaire nu. Réaffirme que l'identifiant de la barrière = id du wallet/espace, distinct du username du profil.
+---
+
+# Décision (2026-07-20) — le wallet partagé est l'unique mode ; identifiant ≠ username du profil
+
+## Contexte
+
+Régression observée : à l'ouverture, l'app tombait sur un **formulaire nu demandant un identifiant**, sans l'assistance de chargement du portefeuille. Cause : `FESTIPOD_SHARED_WALLET_PASSWORD` non défini dans l'environnement du serveur → `hasSharedWallet()` faux → `AccessGateScreen` basculait sur son mode replié. Or ce mode est une **impasse** : un appareil sans wallet ne peut pas se connecter une fois l'assistance d'import masquée. En parallèle, l'ancienne notion de « username » traînait encore pour désigner l'**identité du wallet**, ce qui la confondait avec le vrai username du profil.
+
+## Décision
+
+1. **Le wallet partagé est le seul mode supporté.** Festipod ne fonctionne pas sans lui — le polyfill `@ng-eventually/client` s'en sert comme backend de données (voir [[knowledge_authentication]], `rule_app-uses-sdk-surface-only`). `hasSharedWallet() === false` n'est donc **pas un mode fonctionnel** : c'est une **mauvaise configuration** → `AccessGateScreen` affiche un **écran d'erreur franc** (« Portefeuille partagé non configuré, définir `FESTIPOD_SHARED_WALLET_PASSWORD` »), jamais le formulaire nu en impasse.
+
+2. **L'identifiant de la barrière ≠ le username du profil.** L'identifiant saisi à `AccessGateScreen` est l'**id technique du wallet/espace** (normalisé en minuscules, porté par le param d'URL `?id=`), pas un username. Le **username** est un concept distinct qui vit dans `UserProfile` (`@handle`, prédicat `http://festipod.org/username`). Le code et les tests ne doivent plus étiqueter l'identité du wallet « username/user » (renommé en `identifier`). Réaffirme et prolonge [[decision_2026-07-06_identifier-at-access-barrier]].
+
+## Conséquences
+
+- `AccessGateScreen` : rendu 3-branches (erreur config / flux d'import assisté quand non connecté / champ identifiant seul quand déjà connecté).
+- Renommage `username → identifier` de l'identité du wallet dans l'infra de test (`freshScenarioIdentifier`, `freshIdentifier`), `registration.ts`, `ngSession`, + commentaires ; **`UserProfile.username` intact** (profil, seed, affichage, SHEX).
+- `.env.example` ajouté à la racine pour rendre la config explicite (dont `FESTIPOD_SHARED_WALLET_PASSWORD`, `FESTIPOD_SHARED_WALLET_FILE`).
+
+## Alternative écartée
+
+Garder le repli sans-wallet comme futur « flux wallet-propre » : écarté **pour l'instant** — aucun flux wallet-propre à court terme, et le repli silencieux créait une impasse trompeuse. À réintroduire **explicitement** le jour où un mode wallet-propre (chaque utilisateur avec son propre wallet NextGraph) existera, hors stopgap.
+
+## Liens
+
+- Stopgap wallet partagé : `decision_2026-06-15_shared-wallet-login-flow` (référencé par `AccessGateScreen`/`AccountContext`).
+- [[decision_2026-07-06_identifier-at-access-barrier]] — l'identifiant à la barrière.
+- [[knowledge_authentication]], [[knowledge_trust-model]].

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

@@ -0,0 +1,22 @@
+---
+type: knowledge
+summary: L'identité d'un utilisateur = son wallet NextGraph ; tous les utilisateurs sont authentifiés (pas d'accès anonyme) ; l'auth est déléguée au SDK, l'app n'a pas de comptes/mots de passe applicatifs
+---
+
+# Authentification
+
+**L'identité d'un utilisateur = son wallet NextGraph.** Il n'y a **pas d'accès anonyme** à l'app : tout utilisateur est authentifié (cf. concept `functional-domain`). Il n'y a **pas de système de comptes/mots de passe applicatif** — l'authentification est **déléguée au SDK de données** (`@ng-eventually/client`) : ouvrir sa session, c'est ouvrir son wallet.
+
+## Flux
+
+- La **barrière d'accès** (`AccessGateScreen`, rendue par `src/app/AuthGate.tsx`) est le vrai login NextGraph : elle ouvre le wallet partagé via la redirection broker. **Dans le même acte**, l'utilisateur saisit un **identifiant** qui nomme son espace virtuel (`onEnter`). Il n'y a **plus d'écran « login perçu » séparé** (l'ancien `ConnexionScreen` « choisissez un nom d'utilisateur » a été retiré — cf. [[decision_2026-07-06_identifier-at-access-barrier]] ; supersede le flux à deux écrans de [[decision_2026-06-15_shared-wallet-login-flow]]).
+- Cet **identifiant est un id technique** (un pseudo en pratique, **pas** un username Festipod) : il est **normalisé** (trim, `@` retiré, **minuscules**) puis persisté (`AccountContext` → `IdentityStore`), donc un rechargement — ou un autre appareil rouvrant le même wallet partagé — retombe sur le même espace. C'est cet id qui est donné au SDK (`setCurrentUser`) et sur lequel les caps et le compte shim sont clés.
+- **Porté cross-frontière par un PARAM D'URL `?id=`** (source de vérité), PAS par localStorage. L'app tourne dans deux contextes — **top-level** (`127.0.0.1:3000` direct, `window.self === window.top`, où s'affiche la barrière) et **iframe** (embarquée sous `nextgraph.net` après le round-trip broker, `window.self !== window.top`). Le navigateur **partitionne le storage par site top-level** : le localStorage du top-level et celui de l'iframe sont **deux partitions distinctes** → localStorage NE PEUT PAS porter l'identité d'un contexte à l'autre (symptôme observé : deux valeurs divergentes selon le contexte). Le SDK redirige via `location.href = broker + encodeURIComponent(window.location.href)` (embarque l'URL app complète, query comprise, dans le `o=` rechargé en iframe), donc un **param d'URL traverse**. `AuthGate` écrit `?id=<identifiant>` (`history.replaceState`) **avant** `connect()` ; `AccountContext` résout l'identifiant par priorité **(1) `?id=` de l'URL** puis **(2) localStorage** (préremplissage/convenance same-partition uniquement). Clé localStorage : `festipod.account.identifier`.
+- **Saisi UNE SEULE FOIS au premier accès + prérempli au retour.** Au rechargement top-level, la session NG n'est pas restaurée d'office (`NextGraphContext` repart en `disconnected`) : `AuthGate` réaffiche la barrière tant que `status !== 'connected'`, mais le champ d'`AccessGateScreen` est **prérempli** (prop `initialIdentifier`) — jamais un champ nu et vide. Régressions gardées par `src/modules/auth/features/{barriere-acces-identifiant,identifiant-resolution}.feature` (@ui) — d'autant plus utiles que le flux de barrière est **désactivé** dans les tests @e2e (`__FESTIPOD_ACCESS_GATE_DISABLED__`), donc invisible à cette couche.
+- Une fois la session ouverte, l'utilisateur courant et son accès aux stores par scope sont fournis par `NextGraphContext`.
+
+## Le wallet de test
+
+Les tests `@data`/`@e2e` ouvrent un wallet réel (`festipod-tests`, profil persistant) — voir concept `bdd-testing`. Ce sont des **credentials de test en clair**, sans enjeu de sécurité, dédiés au staging.
+
+> Le modèle d'autorisations qui s'appuiera sur cette identité (connexions bilatérales, données personnelles = réseau, anonymat de l'hôte) est en incubation : [[brief_2026-05-18_authorization-matrix]].

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

@@ -0,0 +1,21 @@
+---
+type: knowledge
+summary: L'isolation entre périmètres (public/protected/private) est assurée par le SDK de données ; l'app lui fait confiance et n'affiche que ce qu'il retourne — aucun contrôle d'accès dans les écrans, toute la confidentialité repose sur le SDK
+last_checked: 2026-07-06
+---
+
+# Modèle de confiance
+
+**Posture :** l'app lit les données via les subscriptions ORM du SDK `@ng-eventually/client` et les affiche **sans logique d'autorisation côté app** (`src/shared/context/FestipodDataContext.tsx`, `useNgData`).
+
+Principes :
+
+1. **L'isolation est déléguée au SDK.** Chaque entité vit dans le store de son **scope** (public / protected / private, cf. concept `functional-domain` → [[knowledge_data-scopes-and-discovery]]) ; le SDK **n'expose à l'utilisateur courant que ce à quoi il a droit**. L'app suppose que ce qu'elle reçoit est déjà autorisé — la confidentialité repose sur le SDK, pas sur du code Festipod.
+2. **Les écrans ne portent aucune règle d'accès.** Pas de vérification « cet utilisateur a-t-il le droit de voir cette donnée » dans les composants ni dans le contexte de données. La séparation public / réseau / privé est une propriété du **placement par scope**, pas d'un filtre applicatif.
+3. **La relation entre utilisateurs (« connexions ») est une notion applicative, pas une primitive du SDK.** NextGraph n'a pas de primitive de connexion/amitié bilatérale ; côté SDK il n'existe qu'un **grant de lecture dirigé** vers une identité. L'app **possède** donc son graphe de relations (`src/shared/utils/connections.ts`) et le **traduit** en grants dirigés par document remis au SDK — elle ne délègue pas la notion de relation au SDK, seulement l'**application** de l'isolation qui en découle. Ce que l'app déclare au SDK reste minimal : **son identité** (l'identifiant, cf. [[knowledge_authentication]]) et **ces grants** ; elle ne porte toujours aucune logique d'accès dans les écrans.
+
+## Le point de vigilance
+
+Parce que l'app **affiche tout ce qu'elle reçoit**, la confidentialité tient entièrement à ce que le SDK n'expose que le légitime. C'est un choix assumé (l'app reste mince), mais il implique de **ne jamais réintroduire côté écran une donnée que le scope n'aurait pas dû laisser passer**.
+
+> À vérifier si on doute : `useNgData` dans `FestipodDataContext.tsx` ne contient aucune branche de filtrage par identité — c'est intentionnel, l'isolation vient d'en dessous.

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

@@ -0,0 +1,20 @@
+# Doc-debt — bdd-testing
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Raw markers (consolidate into blocks, then delete)
+- TOUCHED src/modules/event/features/reconnexion-persistance-e2e.feature @2026-07-13 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/steps/e2e/reconnexion-persistance.steps.ts @2026-07-13 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/shared/test-harness/harness-ng.tsx @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/shared/test-harness/harness.tsx @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-socket-mort.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/steps/data/reconnexion-socket-mort.steps.ts @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-meme-identite.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/steps/data/reconnexion.steps.ts @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-froide-sans-local.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/steps/data/reconnexion-froide-sans-local.steps.ts @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/auth/steps/ui/barriere-acces.steps.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/shared/support/hooks.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/steps/data/isolation.steps.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/auth/steps/data/connexion.steps.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

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

@@ -0,0 +1,36 @@
+---
+type: _overview
+summary: BDD Cucumber/Gherkin en français sur 3 couches (@ui, @data, @e2e) — setup, contrat de couches (quoi tester où), harness broker réel, et le piège des vestiges source-grep
+triggers:
+  keywords: [cucumber, gherkin, bdd, feature, scenario, scénario, step, steps, "@ui", "@data", "@e2e", playwright, broker, harness, wallet, world, hooks, renderHelper, multibrowser, multi-navigateur, "@multibrowser", "@private-wallet", "@shared-wallet", storageState, "@wip"]
+  paths: ["src/modules/*/features/**", "src/modules/*/steps/**", "src/shared/steps/**", "src/shared/support/**", "src/shared/test-harness/**", "cucumber.json"]
+---
+
+# BDD testing
+
+Tests BDD **Cucumber/Gherkin en français** (`Etant donné`, `Quand`, `Alors`) sur **3 couches** de coût croissant.
+
+**À lire avant d'écrire un test :** [[rule_test-layer-contracts]] — chaque couche répond à une question distincte ; mélanger produit des tests fragiles. C'est la règle qui décide *où* va une assertion.
+
+## Les 3 couches
+
+```
+       /\  @e2e   app réelle dans l'iframe broker — parcours critiques
+      /  \
+     /----\  @data  mutations & persistance via broker NextGraph réel
+    /------\
+   /  @ui   \  rendu d'écran in-process (happy-dom + seed) — le gros du volume
+  /__________\
+```
+
+## Liens
+
+- [[rule_test-layer-contracts]] — quoi tester à chaque couche (le contrat)
+- [[knowledge_cucumber-setup]] — config, layout, scripts, fichiers auto-générés
+- [[knowledge_ui-layer]] — couche `@ui` : render helper, fixtures, bons/anti patterns
+- [[knowledge_data-layer-broker]] — couche `@data` : harness broker, cycle de vie wallet, bridge
+- [[knowledge_e2e-layer]] — couche `@e2e` : app réelle dans l'iframe
+- [[knowledge_multibrowser-harness]] — plusieurs navigateurs isolés × modèle de wallet (private/shared), injection storageState
+- [[decision_2026-03-12_headless-wallet-creation]] — pourquoi le wallet de test est créé en UI headless
+- [[caveat_source-grep-vestiges]] — vestiges de l'ère « analyse de source » dans `world.ts`
+- [[cookbook_add-scenario]] — ajouter un scénario/step (couches, piège de sérialisation `evaluate`, `@wip`)

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

@@ -0,0 +1,21 @@
+---
+type: caveat
+summary: world.ts garde des vestiges de l'ère « analyse de source » (screenFileMap, screenFieldDetectors, screenExpectedContent, screenRequiredFields ; hasText/hasField/hasElement à fallback source) — à supprimer une fois la migration @ui vers le DOM rendu terminée
+last_checked: 2026-06-15
+---
+
+# Caveat : vestiges d'analyse de source dans `world.ts`
+
+La suite `@ui` **précède** le contrat de couches ([[rule_test-layer-contracts]]). Des restes de l'ère « grep sur le code source » subsistent et **ne doivent pas être étendus** :
+
+- `world.ts:screenFileMap`, `screenFieldDetectors`, `screenExpectedContent`, `screenRequiredFields` — mappings de l'approche analyse-de-source.
+- `hasText` / `hasField` / `hasElement` — **préfèrent désormais le DOM rendu** mais **retombent sur la source** pour que les steps non migrés continuent de marcher pendant la transition.
+
+## Plan de migration (en cours)
+
+1. Réécrire les assertions grep-source → requêtes DOM via le render helper.
+2. Supprimer les tests sur détails d'implémentation (`/showDuplicateWarning/`, `/importableEvents/`, regex sur JSX).
+3. Déplacer les assertions comportementales vers `@e2e` quand pas déjà couvertes.
+4. Retirer les checks de contenu `@e2e` redondants avec `@ui`.
+
+Une fois la migration terminée, les 4 maps vestiges peuvent disparaître au profit d'assertions sur le DOM rendu + seed. **Tant qu'elles existent, ne pas s'appuyer dessus pour de nouveaux tests.**

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

@@ -0,0 +1,35 @@
+---
+type: caveat
+summary: Le wallet de test partagé (.playwright-profile) accumule des données à chaque run ; passé un seuil, les sparql_query ancrées au private store hangent (>15s) et toute la suite @data échoue au setup — repartir d'un profil frais restaure des lectures ~1s
+last_checked: 2026-07-06
+---
+
+# Piège : le wallet de test se gonfle et fait *hang* les lectures @data
+
+Le profil Chromium persistant `.playwright-profile` (racine du working tree) porte le **wallet
+partagé** ouvert par toute la suite `@data`/`@e2e`. Ce wallet **accumule des données à chaque
+run** : comptes shim (un par scénario, via l'identifiant frais `freshScenarioUsername`), docs
+d'entités seedés, dépôts d'inbox historiques… Le private store est le **point d'ancrage du shim**
+(résolution de compte) et est interrogé par **toute** lecture/écriture (`resolveAccount`,
+`listMyEntityDocs`, …).
+
+**Symptôme.** Passé un certain volume (observé ~99 Mo de profil), une `sparql_query` **ancrée au
+private store** ne revient plus sous 15 s — elle *hang*. Comme la résolution de compte est sur le
+chemin de **chaque** read/write, **toute la suite @data échoue au setup** (0 événement chargé,
+timeouts), sans erreur explicite. Diagnostic vérifié : sur un wallet frais la même requête revient
+en **~1,5 s** et le seed complète normalement.
+
+**Contournement.** Mettre le profil gonflé de côté et laisser le hook d'auth (beforeAll) en
+recréer un frais :
+
+```bash
+mv .playwright-profile /tmp/festipod-bloated-$(date +%s)
+```
+
+L'identifiant frais par scénario (`freshScenarioUsername`) borne le *registre* des comptes mais
+**pas** la croissance physique du private store partagé — d'où la récurrence. Une hygiène durable
+(purge périodique / wallet jetable par run) reste à mettre en place ; en attendant, si les
+`resolveAccount failed`/timeouts réapparaissent, repartir d'un profil frais.
+
+> Le *pourquoi* côté broker (comment une requête ancrée touche le repo du private store) appartient
+> au SDK `@ng-eventually/client`, pas ici — ce caveat ne décrit que la conséquence côté tests.

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

@@ -0,0 +1,29 @@
+---
+type: cookbook
+summary: Procédure pour ajouter un scénario/step BDD — .feature français taggé, steps par couche, piège de sérialisation de appFrame.evaluate (passer les args, pas de closure), ajouter les helpers aux DEUX harness, tag @wip pour le non-implémenté
+---
+
+# Cookbook : ajouter un scénario / un step
+
+1. **Écrire le `.feature`** : `src/modules/{module}/features/us-N-slug.feature`, `# language: fr`, tag de tête `@CATEGORIE @priority-N`, et un tag de couche par scénario (`@ui` / `@data` / `@e2e`). Mots-clés FR : `Fonctionnalité`, `Contexte` (Background), `Scénario`, `Étant donné`/`Quand`/`Alors`. Tagger `@wip` un scénario dont les steps ne sont pas encore écrits.
+
+2. **Choisir la couche** (cf. [[rule_test-layer-contracts]]) : assertion de rendu → `@ui` ; mutation/persistance → `@data` ; parcours complet → `@e2e`.
+
+3. **Écrire les steps** dans `src/modules/{module}/steps/{ui,data,e2e}/*.steps.ts` (ou `src/shared/steps/ui/` si cross-domaine). Signature : `async function (this: FestipodWorld, …)`. Importer `FestipodWorld` depuis `../../../../shared/support/world` (ajuster le chemin relatif).
+
+4. **Accès aux données selon la couche** :
+   - `@ui` : `this.renderedDoc` / `this.getDomText()` / `this.hasText(...)` après `navigateTo(...)` (voir [[knowledge_ui-layer]]).
+   - `@data`/`@e2e` : `await this.appFrame!.evaluate(fn, ...args)` sur le bridge `window.__testData` (voir [[knowledge_data-layer-broker]]).
+
+5. **⚠️ Piège de sérialisation `appFrame.evaluate`** : la fonction passée s'exécute **dans l'iframe**, les variables du step **ne sont pas capturées** (closures perdues). **Passer toute valeur en argument** :
+   ```ts
+   // ❌ const title = eventTitle; await appFrame.evaluate(() => td.getEventByTitle(title)) // title undefined
+   // ✅ await appFrame.evaluate((t) => td.getEventByTitle(t), eventTitle)
+   ```
+   Toujours `await` (oublier → assertion avant résolution).
+
+6. **Si tu ajoutes une opération de données** : exposer le helper sur `window.__testData` dans **les deux** harness (`src/shared/test-harness/harness.tsx` ET `harness-ng.tsx`) — sinon le fallback mock diverge du broker réel.
+
+7. **Câbler un écran testé** : si le nom français de l'écran ne se résout pas vers son `id`, ajouter un alias dans `screenNameMap` (`src/shared/steps/ui/navigation.steps.ts`).
+
+8. **Lancer** : `bun run test:cucumber` (tout) ou `bun run test:data` (@data). Rapport : `reports/cucumber-report.html`. Le `@data`/`@e2e` exige le wallet de test (`bun run test:auth-setup` au premier coup si besoin, sinon création auto — cf. [[decision_2026-03-12_headless-wallet-creation]]).

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

@@ -0,0 +1,37 @@
+---
+type: decision
+summary: Décision 2026-03-12 — créer le wallet de test en automatisant l'UI broker headless (Playwright) plutôt que par API NG, car ça teste le vrai flux d'auth et évite de reverse-engineer l'API d'inscription
+---
+
+# Automated Headless Wallet Creation for CI
+
+**Date:** 2026-03-12 15:00
+**Status:** Accepted
+
+## Context
+
+Les tests `@data` exigent un wallet NextGraph dans un profil Chromium persistant. Avant, le premier run exigeait une interaction manuelle (navigateur visible, création de wallet à la main) → bloquait le CI.
+
+## Options Considered
+
+### Option A: création programmatique du wallet via SDK NG
+Appeler `ng.wallet_create()` depuis Node/Bun, sans UI.
+- **Pour** : plus rapide, pas de navigateur.
+- **Contre** : `@ng-org/web` est browser-only (WASM + postMessage) ; il faudrait reverse-engineer l'API d'inscription d'`account.nextgraph.eu` ; ne teste pas le vrai flux d'auth.
+
+### Option B: automatiser le flux UI headless
+Piloter via Playwright la même UI de création de wallet, en headless.
+- **Pour** : teste le vrai flux auth/login de bout en bout ; pas de reverse-engineering ; même profil persistant réutilisé ; CI-ready sans étape manuelle.
+- **Contre** : dépend de `nextgraph.eu`/`account.nextgraph.eu` joignables ; fragile aux changements d'UI NextGraph ; +~27s au premier run.
+
+## Decision
+
+**Option B** — automatiser l'UI broker. Le flux de création (navigate → Create Wallet → ToS → username/password → submit) est lui-même un test légitime de la feature d'auth. La dépendance aux services externes est acceptable puisque les tests dépendent déjà du broker joignable.
+
+## Consequences
+
+**Positif :** tests pleinement CI-ready (zéro interaction) ; flux auth testé en passant ; `bun run test:data` part d'un état propre.
+**Négatif :** exige un accès internet (nextgraph.eu, account.nextgraph.eu) ; fragile aux changements d'UI NextGraph (textes de boutons, IDs de formulaire).
+**Risque :** rate-limiting d'`account.nextgraph.eu` si le CI recrée souvent des wallets.
+
+> Mécanique de cycle de vie détaillée : [[knowledge_data-layer-broker]].

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

@@ -0,0 +1,46 @@
+---
+type: knowledge
+summary: Config Cucumber (cucumber.json, langue fr, loader tsx), layout des features/steps colocalisés par module, steps partagés dans shared/steps/, et les scripts qui génèrent features.ts/testResults.ts/stepDefinitions.ts
+---
+
+# Setup Cucumber
+
+26 fichiers `.feature` (US-1 à US-26), tous en **français**, taggés `@CATEGORIE @priority-N` (catégories EVENT, WORKSHOP, USER, MEETING, NOTIF).
+
+## Layout
+
+Features et steps **colocalisés avec leur module** :
+
+```
+src/modules/event/features/us-13-creer-evenement.feature
+src/modules/event/steps/{ui,data,e2e}/
+```
+
+Steps **partagés** (cross-domaine) dans `src/shared/steps/ui/` :
+- `navigation.steps.ts` — navigation, auth, clics/sélections, assertions section/bouton/champ
+- `form.steps.ts` — validation de champs, champs requis, import/duplicate
+- `screen.steps.ts` — contenu d'écran (participants, events, profils, QR)
+
+Les noms français des écrans (`"accueil"`, `"détail événement"`, `"mon profil"`…) mappent vers les IDs d'écran via `screenNameMap`.
+
+Tags de scénario : `@ui` / `@data` / `@e2e` (couche) + **`@wip`** pour un scénario dont les steps ne sont pas encore implémentés **ou dont le comportement applicatif n'est pas encore fiable** (usage : marquer un attendu réel qui échoue à cause d'un bug produit, pas un test obsolète — ex. historique : la désinscription qui ne se reflétait pas dans l'UI, `@wip` **levé** depuis sa résolution T02.c, cf [[caveat_participation-deletion]]). **`@wip` est EXCLU du run par défaut** (`cucumber.json: "tags": "not @wip"`) : ces scénarios documentent un attendu sans casser la suite ; retirer le `@wip` quand c'est fiable. Un `Contexte` (Background) fréquent — « Étant donné que je suis connecté » — ne fait que poser un flag `isAuthenticated`, pas d'auth réelle en `@ui`.
+
+## Config
+
+`cucumber.json` : `import` de `src/shared/support/**`, `src/shared/steps/**`, `src/modules/*/steps/**` ; `paths` = `src/modules/*/features/**`; `tags: "not @wip"` (exclut les scénarios WIP) ; `language: fr`. **Runner = Node + tsx** (`node --import tsx/esm node_modules/.bin/cucumber-js`), pas Bun — les plugins (Playwright, happy-dom) ne chargent pas en import Bun natif. Ne pas « bunifier » `cucumber:run`/`test:data`.
+
+## Le harness de test est buildé à la demande
+
+Les harness `@data`/`@e2e` (`src/shared/test-harness/harness.tsx`, `harness-ng.tsx`) **ne sont pas** buildés par `build.ts`. Le `BeforeAll` de `hooks.ts` les compile **à la demande** (`bun build` → `dist/test-harness*.js`). Le wallet de test peut être créé d'avance via `bun run test:auth-setup` (`scripts/setup-test-auth.ts`), sinon il est créé automatiquement au premier run (cf. [[decision_2026-03-12_headless-wallet-creation]]).
+
+## Fichiers auto-générés
+
+Des scripts `scripts/` parsent features/steps en data TS consommée par l'outil de parcours :
+
+| Script | Entrée | Sortie |
+|---|---|---|
+| `parse-features.ts` | `*/features/*.feature` | `src/shared/data/features.ts` |
+| `parse-test-results.ts` | `reports/cucumber-report.json` | `src/shared/data/testResults.ts` |
+| `extract-step-definitions.ts` | `shared/steps/ui/*.ts` | `src/shared/data/stepDefinitions.ts` |
+
+Lancer : `bun run test:cucumber` (tout), `bun run test:data` (@data). Après ajout de steps : `bun run steps:extract`.

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

@@ -0,0 +1,66 @@
+---
+type: knowledge
+summary: Couche @data — Playwright pilote Chromium (profil persistant) qui s'authentifie au broker NextGraph réel chargeant harness-ng.tsx en iframe ; cycle de vie wallet automatisé (création + login bootstrap), bridge window.__testData, fallback mock
+last_checked: 2026-07-05
+---
+
+# Couche `@data` (broker réel)
+
+`@data` teste le **vrai pipeline NextGraph** via un broker, pas des données mockées.
+
+## Architecture
+
+```
+Cucumber → Playwright (Chromium, profil persistant)
+  → broker wallet login (automatisé)
+  → broker charge le harness en iframe (http://127.0.0.1:{port})
+  → harness-ng.tsx (init → useShape → ORM → broker)
+  → bridge window.__testData
+```
+
+**Dual mode** : broker réel (`harness-ng.tsx`, défaut) ou fallback mock (`harness.tsx`, DeepSignalSets standalone si le build NG échoue).
+
+## Cycle de vie du wallet (automatisé, CI-ready)
+
+- **Premier run** : pas de marker `.wallet-ready` → Chromium headless crée le wallet (`nextgraph.eu` → Create Wallet → ToS sur `account.nextgraph.eu` → username/password → submit), **puis se logge** — ce login initial est requis pour amorcer la session (sauvé en localStorage) ; sans lui, les écritures ne passeraient pas. Marker écrit.
+- **Runs suivants** : marker trouvé → login automatisé (click Login → wallet → password → submit) → harness en iframe → `window.__testData.ready`.
+- Credentials wallet : `festipod-tests` / `festipod-tests`.
+
+> Le choix « automatiser l'UI headless plutôt que créer le wallet par API » est tranché dans [[decision_2026-03-12_headless-wallet-creation]].
+
+## Détails techniques
+
+- **Flags Chromium** (`--disable-web-security`, `--allow-insecure-localhost`, désactivation de Private Network Access) : nécessaires car le broker public charge un harness `http://127.0.0.1` en iframe.
+- **Profil persistant** `.playwright-profile/` (gitignored, wallet en localStorage) — exige le vrai binaire Chrome, pas `chrome-headless-shell`.
+- **Serveur HTTP** lancé en `BeforeAll` (port auto), sert le HTML + `/harness.js` (fichiers séparés — le script inline casse à cause de caractères spéciaux du bundle).
+- **Bridge = le vrai chemin app (per-entité).** Depuis le passage à *un document par entité*
+  (concept `data-layer`, [[rule_document-per-entity]]), le bridge `window.__testData`
+  (`events`/`users`/`participations`, `joinEvent`/`leaveEvent`/`isParticipating`/
+  `getEventParticipants`, `loadTestData`) **délègue au contexte de données de l'app**
+  (`appData` via `FestipodDataProvider`) — c'est le chemin per-entité réel des écrans, pas une
+  lecture au niveau du store-racine. Le harness monte donc l'**`AccountProvider`** et se logge
+  par défaut (`@mariedupont`) pour établir l'identité courante (sans quoi le filtre ReadCap ne
+  laisserait passer que le public). Il lit `appData` via une **ref vivante** (un snapshot capturé
+  devient périmé après un re-rendu de seed).
+  - Chemins probes de bas niveau conservés (scope store-racine `protectedNuri`) pour les
+    scénarios ReadCap/isolation qui *gouvernent* ce document : `rawJoin`/`rawParticipations`,
+    `governDocument`/`governProtected`/`documentNuri`, `FilterProbe`/`FanoutProbe`.
+- **Identité avant écriture.** Une `Participation` a un `fp:user` obligatoire ; comme la lecture
+  du profil peut retarder derrière les events publics, les steps attendent
+  `ensureCurrentUser()` avant `joinEvent` (sinon participation écrite sans user → jetée en
+  lecture, ne fait jamais l'aller-retour) et attendent (`waitForFunction`) que la participation
+  soit relue.
+- **Caveat wallet persistant + isolation par scénario (T03.j)** : le wallet partagé **accumule**
+  le registre de comptes émulé et les docs per-entité à chaque scénario/run. Le fan-out de lecture
+  (`listEntityDocs` = `allAccounts()` → 1 SELECT/compte) parcourt tous les docs de tous les comptes
+  → ralentit et fait *timeouter* les steps quand le wallet est pollué. Ce registre vit **côté
+  broker** : supprimer `.playwright-profile/` ne le nettoie PAS (re-sync depuis le broker) et force
+  une re-auth lente — mauvais levier. À la place, le `Before` @data appelle
+  `window.__testData.resetDataState()` : **UN** SPARQL DELETE sur le graphe ancre (private-store)
+  qui efface tous les records `urn:ng-eventually:shim:Account` → `allAccounts()` s'effondre à vide →
+  le fan-out se **borne** à ce que le scénario courant reprovisionne (comptes recréés paresseusement
+  par `ensureAccount`). O(1) sur UN graphe — **pas** un delete en fan-out (qui saturait le navigateur,
+  cf. T03.i `authClearParticipation` retiré). Borné à ≤10s (`Promise.race`) pour ne pas disputer le
+  budget 60s du `Before` (login broker déjà lent). Infra de test uniquement — ne touche ni la lib ni
+  le modèle produit ni le chemin de lecture applicatif. Le seed connecté reste **allégé** (peu de
+  docs) car chaque `docCreate` est un aller-retour broker sériel ~2s.

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

@@ -0,0 +1,67 @@
+---
+type: knowledge
+summary: Couche @e2e — Playwright boote l'app RÉELLE (pas un harness) dans l'iframe broker, interagit via appFrame.evaluate()/locator(), réutilise setupBrokerPage() de @data ; teste navigation/redirects/clics, pas de fallback mock
+---
+
+# Couche `@e2e` (app réelle)
+
+`@e2e` teste l'**UI de l'app réelle** tournant dans l'iframe broker — contrairement à `@data` qui charge un harness de test.
+
+## Architecture
+
+```
+Cucumber → Playwright (Chromium, profil persistant)
+  → https://nextgraph.net/redir/#/?o=http://127.0.0.1:{appPort}
+  → login broker (automatisé, même mécanique que @data)
+  → broker charge la VRAIE APP en iframe
+  → app rend avec NextGraphProvider auto-connectant
+  → steps via appFrame.evaluate() + locators Playwright
+```
+
+**Serveur app** : lancé en `BeforeAll` (`spawn('bun', ['src/index.ts'], { env: { PORT } })`, poll jusqu'à réponse HTTP, tué en `AfterAll`). Réutilise le helper `setupBrokerPage()` de `@data` (redirect, login, découverte de l'iframe).
+
+## Step definitions
+
+Dans les modules (ex. `src/modules/auth/steps/e2e/connexion.steps.ts`) :
+- `this.appFrame!.evaluate()` — JS dans l'iframe app (navigation hash/path, checks de contenu)
+- `this.appFrame!.locator()` — éléments DOM
+- `this.appFrame!.waitForFunction()` — poll d'état attendu
+- `SCREEN_MARKERS` — map ID d'écran → texte unique de vérification
+
+Navigation : `window.history.pushState` + dispatch `popstate` (routing path-based, cf. `app-architecture`).
+
+## Différences avec `@data`
+
+| Aspect | `@data` | `@e2e` |
+|---|---|---|
+| Chargé en iframe | harness (`harness-ng.tsx`) | app réelle (`src/index.ts`) |
+| Signal ready | `window.__testData.ready` | `root.innerHTML.length > 100` |
+| Interaction | bridge `evaluate()` | `evaluate()` + locators |
+| Fallback mock | oui | **non** (broker réel requis) |
+| Teste | opérations données | comportement UI (nav, redirects, clics) |
+
+> **Ne pas re-vérifier en `@e2e` ce que `@ui` couvre déjà** — `@e2e` doit casser quand la *collaboration* entre couches casse, pas quand une icône change (cf. [[rule_test-layer-contracts]]).
+
+## Smoke `@smoke` — garde la classe « page blanche une fois connecté »
+
+`@e2e @smoke` (`src/modules/home/features/accueil-connecte-rend.feature`) garde une
+CLASSE de régression : un crash de rendu qui ne survient QUE une fois l'app connectée
+et montée sur des données réelles (symptôme : seul le bandeau de l'iframe broker
+s'affiche, `#root` reste vide). Le smoke réutilise le boot du hook `Before` @e2e,
+navigue vers l'accueil connecté et asserte DEUX choses :
+1. **HomeScreen a réellement monté** — présence de marqueurs forts (`.app-navbar` +
+   bouton `[aria-label="Relayer un événement"]`), absents d'un spinner / du bandeau
+   broker. Un `throw` dans un composant/provider monté après connexion démonte l'arbre
+   (aucun `ErrorBoundary`) → ces marqueurs disparaissent → rouge.
+2. **Zéro erreur runtime** — `this.pageErrors` (voir ci-dessous) doit être vide.
+
+Le hook `Before` @e2e **collecte** désormais dans le World les `pageerror` +
+`console.error` de la page app (champ `pageErrors`, réinitialisé par scénario) — c'est
+ce qui rend l'assertion « pas d'erreur » possible. Le run par défaut de `bun run
+validate` exécute `@smoke and not @wip` (pas tout `@e2e`, pour rester rapide).
+**Preuve de détection** : un `throw` en tête de `HomeScreen` fait virer le smoke au
+rouge ; sans lui, vert.
+
+## Fichiers clés
+
+`src/shared/support/hooks.ts` (lifecycle Playwright + collecte `pageErrors`), `world.ts` (champs `page`/`appFrame`/`pageErrors`), `scripts/debug-browser.ts` (debug headed), `.playwright-profile{,-debug}/` (gitignored).

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

@@ -0,0 +1,70 @@
+---
+type: knowledge
+summary: Harness multi-navigateur sur DEUX axes orthogonaux — nombre de navigateurs (machinerie, contextes frais isolés via un freshBrowser non-persistant) ET modèle de wallet (own/@private-wallet vs shared/@shared-wallet) ; shared provisionné par injection storageState (test) ; e2e @humain qui valide le mécanisme produit RÉEL via la vraie app staging (fichier .ngw téléchargé depuis l'écran → import nextgraph.eu « Import a Wallet File » → Entrer → connecté) ; convention @wip exclue via cucumber.json
+last_checked: 2026-06-16
+---
+
+# Harness multi-navigateur (private-wallet vs shared-wallet)
+
+Capacité du harness `@data`/`@e2e` à piloter **plusieurs navigateurs isolés** dans un même scénario, sous **deux axes orthogonaux**. Permet de tester à la fois le modèle « chacun son wallet » (`@private-wallet`) et le modèle « wallet partagé entre navigateurs » (`@shared-wallet`).
+
+## Les deux axes (orthogonaux)
+
+| Axe | Ce qu'il décide | Exprimé par |
+|---|---|---|
+| **Nombre de navigateurs** (machinerie) | 1..N contextes nommés isolés | `openBrowser(name, …)` + steps `… dans le navigateur "X"` |
+| **Modèle de wallet** | identité NG distincte vs partagée | **phrasing du step + tag** (voir ci-dessous) |
+
+Ne **pas** confondre `@multibrowser` (plusieurs navigateurs) avec `@shared-wallet` (même wallet) : on fait du multibrowser **en private** (chacun son wallet) **et en shared** (wallet partagé), et on compare les deux setups avec les **mêmes** steps de comportement.
+
+## Modèle de wallet : phrasing + tags
+
+- `Étant donné un navigateur "A" avec son propre wallet` → modèle **own**, tag `@private-wallet`.
+- `Étant donné un navigateur "A" avec le wallet partagé` → modèle **shared**, tag `@shared-wallet`.
+- Tag umbrella `@multibrowser` (feature entière).
+
+## Architecture (où vit quoi)
+
+- **`src/shared/support/browserPool.ts`** — état partagé + fabrique. Hors du contexte Chromium **persistant** porteur du wallet partagé (legacy mono-navigateur `@data`/`@e2e`, **inchangé**, cf. [[knowledge_data-layer-broker]]), le harness lance un navigateur **non-persistant** `freshBrowser` (`chromium.launch`) qui mint des contextes frais et isolés à la demande (`spawnContext(wallet)`). Module importé par `hooks.ts` (cycle de vie) et `world.ts` (usage par scénario) — pas de cycle d'import.
+- **`world.ts`** — API : `openBrowser(name, wallet)`, `browser(name)`, `loadAppInBrowser(name, 'app'|'harness')`, `closeBrowsers()` ; registre `browsers: Map<name, NamedBrowser>`. Navigateurs nommés fermés en `After`, `freshBrowser` en `AfterAll`.
+- **`hooks.ts`** — un scénario taggé `@multibrowser` **ne reçoit pas** la page unique legacy ; les steps ouvrent les navigateurs. Exige le mode broker réel (`freshBrowser` indispo en fallback mock).
+
+## Provisioning du wallet
+
+- **own** : `newContext()` vide → identité NG distincte / pas de wallet.
+- **shared** : `newContext({ storageState })`, où `storageState` est **capturé une fois** au `BeforeAll` depuis le profil persistant (warm-up via `setupBrokerPage` puis `browserContext.storageState()`), exposé par `pool.sharedWalletState`. **Vérifié empiriquement (2026-06-16)** : les origines `nextgraph.eu` + `nextgraph.net` round-trippent dans les contextes frais, et deux navigateurs **shared** atteignent tous deux l'app **connectée** à NextGraph (`window.__testData.ready`) **sans login manuel**.
+
+> Ce provisioning est **de test** — distinct du mécanisme **produit** (import assisté par FICHIER). Le scénario shared-wallet par storageState **court-circuite l'import** ; pour valider le mécanisme RÉEL, voir l'e2e `@humain` ci-dessous.
+
+## Parcours humain — e2e du mécanisme produit (vert)
+
+Scénario `@humain` : valide le flux RÉEL de distribution du wallet **de bout en bout, via la vraie app**, pas l'injection de test. Un navigateur vierge ouvre l'app staging → l'`AccessGateScreen` propose le **fichier** + le **mot de passe** → on télécharge le fichier **depuis l'écran**, on vérifie que le mot de passe affiché **égale** celui du wallet → import sur `nextgraph.eu` « Import a Wallet File » → retour → on **saisit un identifiant** puis clic « Entrer » (nommer l'espace et ouvrir le wallet = un seul acte, cf. concept `app-security` [[decision_2026-07-06_identifier-at-access-barrier]]) → app connectée, arrivée directe sur l'accueil (plus d'écran « nom d'utilisateur » séparé).
+
+- **Wallet e2e** : un fichier `.ngw` (`festipod-e2e-tests`, mot de passe = identifiant) placé **à la racine du worktree** ; `findE2eWalletFile()` le localise (`*.ngw`). Gitignoré → chaque environnement doit l'ajouter (sinon erreur claire).
+- `pool.ensureStagingApp()` (`hooks.ts`) — build **isolé** `bun run build.ts --outdir=dist-staging` (barrière d'accès **ON par défaut** ; mot de passe gravé + **fichier copié** en `/shared-wallet.ngw`, cf. `build.ts`), servi statiquement. Mémoïsé, lazy (seul `@humain` le paie).
+- **Bypass de la barrière pour `@e2e`** : le harness fait `browserContext.addInitScript` sur le **contexte persistant** pour poser `globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ = true` (s'applique à l'iframe app avant ses scripts) → `@e2e` voit l'app directement, pas la barrière. Les contextes frais (`@humain`) n'y touchent pas → barrière ON. L'ancien `LoginScreen` `/login` a été retiré.
+- `pool.importWalletViaFile(page, filePath, password)` — `nextgraph.eu/#/wallet/login` → `setInputFiles('input[type=file]')` (attendre que la SPA rende, sinon `EncryptionError`) → champ password → unlock.
+- `pool.completeBrokerLogin(page, appUrl, walletPassword?)` — moitié « login broker » extraite de `setupBrokerPage`. **Attente robuste** : après le redirect (multi-hop), attend l'iframe app OU le lien « Click here to login with your wallet », puis déverrouille avec le mot de passe. La session broker n'étant **pas** persistée entre lancements, ce login wallet est requis à chaque run (warm-up + `@e2e` + `@humain`).
+
+> **C'est l'e2e qui garantit que ça marche pour un humain réel** : Festipod fournit le BON fichier + mot de passe, et ce fichier importé donne un wallet fonctionnel sur un device vierge. Le scénario `@shared-wallet` (storageState) reste un raccourci de provisioning de test, il ne valide pas l'import.
+
+## Isolation (garantie à 3 niveaux, prouvée par les scénarios)
+
+1. `freshBrowser` est un **process séparé** du profil persistant porteur du wallet → un navigateur **own** démarre **sans wallet**.
+2. Chaque `newContext()` est une **partition de stockage hermétique** (garantie Playwright).
+3. Isolation prouvée non seulement sur l'origine **locale** (`127.0.0.1`) mais aussi sur l'**origine broker** `nextgraph.net` **où vit réellement le wallet** (sonde localStorage écrite dans A absente de B).
+
+## Fichiers
+
+- Feature : `src/modules/workshop/features/multibrowser-harness.feature`.
+- Steps : `src/modules/workshop/steps/data/multibrowser.steps.ts`.
+- Route `/blank` ajoutée au serveur harness (`hooks.ts`) : page minimale **sans stack NG**, pour les checks d'isolation localStorage.
+
+## Convention `@wip` (désormais appliquée)
+
+`cucumber.json` (profile `default`) porte `"tags": "not @wip"`. Le `cookbook_add-scenario` prescrivait `@wip` pour le non-implémenté mais ce n'était **exclu nulle part** ; maintenant `not @wip` s'**AND** avec les filtres CLI (ex. `--tags @data` → `(not @wip) and @data`, vérifié).
+
+## Liens
+
+- [[knowledge_data-layer-broker]] — la couche `@data` mono-navigateur (profil persistant) que cette capability étend.
+- [[cookbook_add-scenario]] — convention `@wip`, pièges de steps.

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

@@ -0,0 +1,33 @@
+---
+type: knowledge
+summary: Couche @ui — renderHelper.tsx rend tout écran dans LocalDataProvider + happy-dom, world.renderCurrentScreen() l'invoque à chaque navigateTo, assertions sur le DOM rendu avec les fixtures de seed déterministes
+---
+
+# Couche `@ui`
+
+`@ui` rend un écran avec `LocalDataProvider` (seed) + `RouterProvider` via happy-dom, puis assert sur le **DOM rendu**.
+
+- Helper : `src/shared/test-harness/renderHelper.tsx` (installe les globals happy-dom, enveloppe l'écran). Invoqué depuis `world.ts:renderCurrentScreen()` à chaque `navigateTo(...)`.
+- Fixtures déterministes (`src/shared/data/seedData.ts`, voir concept `data-layer`) : `Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` existe, 5 events, etc.
+
+## Bons patterns d'assertion
+
+```ts
+// Texte visible
+expect(this.getDomText()).to.include('Marie Dupont');
+// Présence d'élément par classe/rôle
+expect(this.renderedDoc!.querySelector('.app-avatar')).to.not.be.null;
+// Rendu conditionnel (rempli vs vide)
+expect(this.renderedDoc!.querySelectorAll('.app-card').length).to.be.greaterThan(0);
+// Champ requis rendu avec label + astérisque
+const labels = Array.from(this.renderedDoc!.querySelectorAll('p')).map(p => p.textContent ?? '');
+expect(labels.some(t => t.includes("Nom de l'événement *"))).to.be.true;
+```
+
+## Champs & helpers de `FestipodWorld` (`src/shared/support/world.ts`)
+
+- `renderedDoc: Document | null` — le DOM happy-dom rendu (peuplé par `renderCurrentScreen()`, appelé à chaque `navigateTo(...)`).
+- `currentScreenId: string | null` — l'écran courant.
+- Helpers d'assertion : `getDomText()` (texte du DOM), `hasText(t)`, `hasField(name)`, `hasElement(selector)` — ils **préfèrent le DOM rendu** mais **retombent sur la source** des écrans pour les steps non migrés (vestige, voir [[caveat_source-grep-vestiges]]).
+
+> Les classes `app-*` confirment le thème moderne (cf. `app-architecture`). Les anti-patterns (regex sur source, détails d'implémentation) sont proscrits par [[rule_test-layer-contracts]]. Pour écrire un nouveau scénario, voir [[cookbook_add-scenario]].

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

@@ -0,0 +1,52 @@
+---
+type: rule
+summary: Ne JAMAIS poller le broker (re-lire en boucle « c'est là ? »). NextGraph est par abonnement — la donnée arrive par PUSH, et le 1er `State` d'un `doc_subscribe` est la barrière de sync déterministe (après lui : présence garantie / absence définitive). Tests ET app attendent le push / l'état réactif settlé, jamais une boucle de re-lecture broker.
+last_checked: 2026-07-09
+---
+
+# Ne jamais poller le broker — attendre l'abonnement
+
+NextGraph est **par abonnement (réactif)**. Une lecture n'est PAS « interroge en
+boucle jusqu'à ce que ça apparaisse » ; c'est « abonne-toi, réagis au push ». Le
+**1er `State`** d'un `doc_subscribe` marque la fin de la synchronisation initiale
+(barrière synchrone) : après lui, la **présence** d'une donnée est **garantie** et
+l'**absence** est **définitive**. Contrat vérifié empiriquement côté SDK
+(`@ng-eventually/client`, test e2e « CONTRAT 3 »).
+
+## L'anti-pattern à bannir
+
+```
+for (i = 0; i < N; i++) { if (await authParticipationCount(...) === X) break; sleep(500); }
+```
+
+Toute boucle qui **re-interroge le broker** (`authParticipationCount`,
+`listMyEntityDocs`, `sparql_query` répétés) pour « attendre » une donnée est
+proscrite : elle masque le vrai mécanisme, fragilise le test (timeout deviné), et
+contredit frontalement le modèle NextGraph. C'est la remarque qui a fait supprimer
+l'ancien caveat qui, à tort, érigeait le polling en pratique.
+
+## Ce qu'il faut faire
+
+Attendre le **push réactif**. En pratique (app ET test) : l'état réactif
+(`AD().*` alimenté par `subscribeDoc` dans le contexte de données) se met à jour
+**au push**. On attend que CET état reflète l'attendu — on **observe l'état réactif
+settlé**, on ne ré-émet PAS de lecture broker. Le mécanisme de données est
+l'abonnement ; l'attente ne fait qu'**observer le résultat réactif**.
+
+- App : l'écran est déjà réactif (`subscribeDoc` → re-render au push) — pas de poll
+  applicatif, pas de spinner piloté par timeout deviné (si un état d'attente est
+  voulu, il vient de la barrière d'abonnement native, pas d'un signal ajouté).
+- Test : **un helper qui attend le push/la barrière de façon fiable est bienvenu**
+  (fiabilise sans fragiliser). Ce qui est banni, c'est la **boucle de re-lecture**,
+  pas l'attente d'un signal.
+- **Fallback pragmatique** : si attendre strictement le push/signal s'avère fragile
+  d'une manière ou d'une autre, un **intervalle court** (`setInterval` / re-check
+  rapproché) qui **observe l'état réactif DÉJÀ mis à jour** (l'état local alimenté
+  par l'abonnement — PAS une re-lecture broker) est acceptable : c'est au plus près
+  de ce que vit l'utilisateur, qui **attend** simplement que l'écran (réactif) se
+  mette à jour. La ligne rouge est invariante : **ne jamais re-interroger le broker
+  en boucle** ; observer l'état réactif settlé, oui.
+
+Voir aussi [[caveat_wallet-bloat-hang]] (autre source de flakiness @data,
+orthogonale). Le mécanisme non-polling côté lib (`open-repo` : subscribe + attendre
+le 1er State + lire) vit dans le repo `@ng-eventually/client`, pas ici.

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

@@ -0,0 +1,29 @@
+---
+type: rule
+summary: Chaque couche BDD répond à une question distincte — @ui = rendu (DOM + seed), @data = mutations/persistance broker, @e2e = collaboration des couches sur un parcours ; descendre chaque assertion à la couche la plus basse qui peut y répondre
+---
+
+# Règle : contrat des couches de test
+
+Chaque couche répond à **une question distincte**. Mélanger les préoccupations produit des tests fragiles qui cassent au refactor sans attraper de vraie régression. **Descendre toute assertion à la couche la plus basse qui peut y répondre.**
+
+- **`@ui` — couche affichage.** Rend un écran avec `LocalDataProvider` (seed) + happy-dom et assert sur le DOM. Vérifie que *données connues → l'écran montre le texte et les éléments attendus*. **Ne teste pas** la navigation, les mutations, ni la persistance.
+
+- **`@data` — couche données.** Pilote des mutations ORM via le **broker NextGraph réel** (harness headless, pas d'UI app). Vérifie que *les opérations sur shapes sont persistées et observables dans le wallet*. Pas de DOM ici — utiliser le bridge `window.__testData`.
+
+- **`@e2e` — couche intégration.** Boote l'app réelle dans l'iframe broker (Playwright/Chromium). Vérifie que *les couches collaborent pour livrer un parcours* (créer → lister → modifier → recharger → toujours là). **Rare** : 1 scénario par chemin critique ; **ne jamais dupliquer** un check de contenu `@ui`.
+
+## Pourquoi le coût impose la pyramide
+
+`@ui` tourne in-process (instantané) ; `@data` boote un broker (~50s) ; `@e2e` boote broker + app + navigateur (~2min). Une affirmation de rendu appartient à `@ui`, pas à `@e2e`.
+
+## Anti-patterns `@ui` à proscrire
+
+```ts
+// ❌ regex sur la source : couple le test à la structure du code
+expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source)).to.be.true;
+// ❌ détails d'implémentation
+expect(/showDuplicateWarning/.test(source)).to.be.true;
+```
+
+Préférer des assertions sur le **DOM rendu** + données de seed (voir [[knowledge_ui-layer]]). Les helpers/maps d'analyse de source sont des vestiges en voie de suppression : [[caveat_source-grep-vestiges]].

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

@@ -0,0 +1,8 @@
+# Doc-debt — data-layer
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Raw markers (consolidate into blocks, then delete)
+- TOUCHED src/shared/context/FestipodDataContext.tsx @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/shared/utils/ngSession.ts @2026-07-20 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

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

@@ -0,0 +1,33 @@
+---
+type: _overview
+summary: Comment Festipod persiste ses données via le SDK @ng-eventually/client — entités stockées comme documents par scope, écriture SPARQL directe + lecture par modèle union, stack SHEX, modes connected/demo, seed
+triggers:
+  keywords: [nextgraph, "@ng-eventually", union, readUnion, readEntities, SHEX, shape, scope, "@graph", NURI, sparql, seed, wallet, FestipodData, ngSession, ngGraph, bootstrap, document, entité, déconnexion, reconnexion, durabilité, outbox, SerializationError]
+  paths: ["src/shared/shapes/**", "src/shared/data/readEntities.ts", "src/shared/data/entityWrites.ts", "src/shared/context/NextGraphContext.tsx", "src/shared/context/FestipodDataContext.tsx", "src/shared/utils/ng*", "src/shared/data/seedData.ts"]
+---
+
+# Data layer
+
+Comment Festipod **persiste ses données** via NextGraph (P2P, local-first, chiffré de bout en bout). Le SDK de données est **`@ng-eventually/client`** : on le traite comme un SDK NextGraph fini — chaque entité est un **document** placé dans le store de son **scope** (public / protected / private). L'**écriture** est un SPARQL direct dans le document de l'entité ; la **lecture** est le **modèle union** (résoudre les documents par besoin → ouvrir/sync → **une** requête `sparql_query` sans ancre sur l'union → re-query sur signal), et non un abonnement ORM réactif en fan-out (qui *hang*). Voir [[rule_document-per-entity]]. Le mapping *quelle entité → quel scope* est un fait **produit** (concept `functional-domain`, [[knowledge_data-scopes-and-discovery]]) ; ce concept décrit la **mécanique de persistance**.
+
+> **Frontière SDK.** Le SDK de données de Festipod est `@ng-eventually/client` — initialisé/injecté **une seule fois** via `ngSession.configure(...)`. On l'écrit comme un SDK NextGraph **fini** : ne jamais documenter ici l'état courant de NextGraph (contraintes, contournements, internes broker) — cela vit dans le repo `@ng-eventually/client`. Voir [[knowledge_nextgraph-stack]].
+
+## Modèle & données
+
+- [[knowledge_nextgraph-stack]] — SDK `@ng-eventually/client`, shapes SHEX, ORM réactif, `build:orm`, injection via `ngSession`
+- [[knowledge_data-modes]] — connected (SDK) vs disconnected/demo (état local seedé), choix du provider
+- [[knowledge_entities]] — types `Fp*` et leurs shapes SHEX
+- [[knowledge_seed-data]] — données de seed, `CURRENT_USER_ID`
+- [[knowledge_context-internals]] — pièges de `FestipodDataContext` (currentUser, auto-seed dev, `participantCount` cache, no-op local)
+
+## Règles d'écriture
+
+- [[rule_document-per-entity]] — chaque entité = **son propre document** (par scope), jamais au niveau du store ; c'est ce qui rend l'isolation par-document du SDK possible
+
+## Pièges (lire avant de toucher aux suppressions / aux champs d'event)
+
+- [[caveat_participation-deletion]] — la désinscription doit être **autoritative** et ne pas réapparaître
+- [[caveat_event-fields-not-persisted]] — `startTime`/`themes`… non couverts par la shape Event → perdus en connecté
+- [[caveat_write-durability-across-disconnect]] — une écriture juste avant une inactivité/chute de socket peut être **perdue** (non durable broker) ; compte survit. Incident ouvert → post-mortem dans le polyfill
+
+> Confidentialité (isolation par scope, confiance dans le SDK) : concept `app-security`. Périmètres produit par entité + découverte : concept `functional-domain`.

.project/concepts/data-layer/brief_2026-07-06_reactive-reads-and-attendance.md

@@ -0,0 +1,186 @@
+---
+type: brief
+summary: Design d'implémentation — rendre les lectures RÉACTIVES cross-session via doc_subscribe (par-document, sans fan-out ORM qui hang) et remplacer le participantCount muté-en-place par le flux Option-B (l'inscrit dépose dans l'inbox de l'événement, le propriétaire matérialise et incrémente son propre doc) ; plan de test 2-browsers réel sans polling
+---
+
+# Reactive reads + participant-count correct (Option B)
+
+Brief d'implémentation, ancré dans le code courant. Objectif : deux évolutions couplées de la couche données Festipod (mode connected / `@ng-eventually/client`).
+
+1. **Lectures réactives cross-session** — remplacer le one-shot `readUnion` + `bumpRead` (re-query manuel, local-only) par une réactivité réelle poussée par le broker, **sans jamais poller** et **sans le fan-out ORM qui hang**.
+2. **Compteur de participants correct (Option B)** — supprimer la violation d'isolation actuelle (l'inscrit écrit `participantCount` sur le doc de l'événement qui ne lui appartient pas) et la remplacer par le flux dépôt-inbox → matérialisation-propriétaire.
+
+Ce brief décrit **quoi construire et dans quel ordre**. Aucune modification de code n'est faite ici.
+
+Références transverses : [[knowledge_context-internals]], [[rule_document-per-entity]], [[caveat_participation-deletion]], `functional-domain/knowledge_data-scopes-and-discovery`, `app-security/knowledge_trust-model`, et le contrat SDK `@ng-eventually/client` (`docs/sdk-reference.md`, `docs/read-model.md`, `docs/nextgraph-current-state.md`).
+
+---
+
+## 0. État courant (le point de départ, fichier:fonction)
+
+### Lecture (one-shot, re-query manuel)
+`src/shared/context/FestipodDataContext.tsx` → `useNgData()` :
+- Le jeu de docs à lire **par besoin** est deux `useState` : `publicDocs` / `protectedDocs` (l.232-233). Il est alimenté par (a) l'effet de listing (l.302-332) qui appelle `listMyEntityDocs(owner, 'public'|'protected')` (borné à mon compte) + `readDiscoveredEvents()` (l'index global), et (b) `registerDoc(scope, nuri)` (l.251-255) qui ajoute un doc fraîchement créé.
+- La **lecture réelle** (l.347-364) : `readEntities(allReadDocs)` → `readModel.readUnion(docs)` (un `sparql_query` ancré par doc, en parallèle, tolérant par-doc). Elle **re-tourne** quand `allReadDocs` change **ou** quand `readTick` change.
+- `readTick`/`bumpRead` (l.236-237) = **signal de re-query manuel**, bumpé après chaque mutation. **Il n'y a AUCUN signal venant du broker** : une écriture faite par une AUTRE session n'incrémente jamais `readTick` de cette session → **pas de réactivité cross-session**. C'est le trou que ce brief comble.
+- `listTick`/`relist` (l.246-247) rejoue l'effet de listing après un seed.
+
+### Écriture du compteur (la violation à retirer)
+- `joinEvent` (l.597-668) : après avoir écrit sa propre `Participation` (doc protected, l.621-631), il fait `updateEntityField(eventId, eventId, 'participantCount', int(next))` sur **le doc de l'événement** (l.635-640) — or ce doc appartient au **propriétaire de l'événement**, pas à l'inscrit. C'est un write hors-scope. Il dépose *aussi* dans l'inbox via `depositRegistration` (l.652) — ce dépôt-là est le bon canal ; c'est l'écriture directe du `participantCount` qui est à supprimer.
+- `leaveEvent` (l.670-712) : symétriquement, décrémente `participantCount` sur le doc de l'événement (l.705-710) après le DELETE autoritatif de la participation.
+- `caveat_participation-deletion` : le DELETE de participation doit rester **autoritatif** (SPARQL DELETE-WHERE via `deleteParticipation`, `src/shared/data/registration.ts` l.260-334, vérifié `remaining === 0`) — ce brief ne change pas ce contrat.
+- [[knowledge_context-internals]] documente déjà que `participantCount` est un **cache muté en place**, jamais recalculé, et « pas une source de vérité ». Option B en fait une valeur **dérivée et possédée par le propriétaire**.
+
+### Affichage (déjà « compte + anonyme », à conserver)
+`src/modules/event/screens/EventDetailScreen.tsx` :
+- `joined = isParticipating(eventId)` (l.20).
+- `participants = getEventParticipants(eventId)` (l.21) → dans le contexte, `getEventParticipants` (FestipodDataContext l.108-111) filtre les `participations` connues par `eventId` et joint les `users` **lisibles** (donc seulement mes connexions, cf. cap protected).
+- `knownParticipants = participants.filter(p => p.id !== currentUserId)` (l.33).
+- Le libellé **« Participants ({event.participantCount}) »** (l.146) affiche le **compte dérivé**, et `knownParticipants.length < event.participantCount` rend les **placeholders « voir tous les participants »** (l.163-170) — c'est exactement le modèle « compte + anonymes » voulu. **Cet affichage ne change pas** : Option B ne fait que rendre `participantCount` correct et réactif, et les `knownParticipants` restent gouvernés par le cap de lecture protected.
+
+### Les watchers polling de la lib (à remplacer)
+Confirmé par lecture de la lib (`packages/client/src/`) :
+- `inbox.watch(target, onDeposits, {intervalMs=1000})` (`inbox.ts:195-223`) = **`setInterval` polling**, se déclenche uniquement sur changement de `deposits.length`.
+- `discovery.watchIndex(onEntries, {intervalMs=1000})` (`discovery.ts:163-187`) = **`setInterval` polling** identique.
+- `useShape` (`use-shape.ts:12`) EST poussé/réactif, mais **seulement sûr sur UN seul document déjà ouvert** — le fan-out `graphs:[…]` hang (§2).
+- **Aucun wrapper `doc_subscribe` n'est exposé aujourd'hui** dans `docs.ts` (qui n'expose que `docCreate` / `sparqlUpdate` / `sparqlQuery`). Le primitif `ng.doc_subscribe` est atteignable *untyped* via le proxy `ng` (`ng-proxy.ts:54-56` passthrough), mais il n'y a **pas de couche typée** → **la lib doit en ajouter une** (§A).
+
+---
+
+## 1. Les primitives plateforme (nextgraph-rs, vérifié)
+
+- `doc_subscribe(repo_o: String, session_id, callback)` (`sdk/js/lib-wasm/src/lib.rs:1907`) est **par-document** : un seul NURI de repo, un callback. Il monte une souscription sur **une branche** du doc (`verifier.rs:352` `create_branch_subscription`), pousse d'abord un `TabInfo` + `State` initial (`verifier.rs:470-477`), puis un flux de `Patch` à chaque commit.
+- Le push : à chaque transaction vérifiée sur une branche B, le vérifieur appelle `push_app_response(&B, AppResponse::…)` (`verifier.rs:252`) sur le `Sender` enregistré dans `branch_subscriptions[B]` (`verifier.rs:115`). **Unité de souscription = une branche d'un doc.**
+- Le **fan-out ORM** vit ailleurs : `orm_start_graph(scope.graphs[], …)` (un seul appel sur un tableau). Là, un **seul** repo non-synchronisé dans le tableau fait que `open_for_target → resolve_target` retourne `RepoNotFound` (`request_processor.rs:147-171`, et surtout la boucle `initialize.rs:125-128` où le `?` **avorte toute la souscription**). Le `readyPromise` ne se résout jamais → **hang ~75s** (`nextgraph-current-state.md` § *The ORM fan-out hang*, cité dans `read-model.md:93-98` et l'en-tête de `read-model.ts:24-31`). **Corollaire : `doc_subscribe` par-doc n'a PAS ce défaut** — il ne subit pas de fan-out, donc un doc absent ne casse que sa propre souscription.
+- **Write membership-bound, pas d'append** (confirmé, `repo.rs:584` `verify_permission` : auteur non-membre → `PermissionDenied` ; `commit.rs` : une transaction exige `WriteAsync`/`WriteSync`, obtenus uniquement par grant du propriétaire ; **aucune variante `Append` dans `PermissionV0`**). ⇒ **Option A est impossible** : un inscrit ne peut pas écrire/incrémenter un compteur sur le doc public d'un autre. D'où Option B via l'inbox.
+- **Inbox = primitif plateforme réel** (`server_broker.rs:826` `inbox_post` : aucun contrôle de membership sur l'émetteur ; message scellé à la clé de l'inbox, lisible seulement par les *readers* enregistrés). C'est exactement le canal « n'importe qui dépose, seul le propriétaire dépile ». Aujourd'hui la lib l'émule sur le wallet partagé (`inbox.ts` post/read RDF), le natif étant différé.
+
+---
+
+## A. Lectures réactives — le design
+
+### Principe : `doc_subscribe` par-doc comme **signal de changement**, `readUnion` reste le lecteur
+On **ne** rend **pas** `readUnion` réactif et on **n'introduit pas** de fan-out ORM. On garde le pattern documenté (`read-model.md:100-110`) :
+
+> une souscription réactive légère (`doc_subscribe`, ou l'ORM sur un seul store déjà ouvert — jamais un fan-out par-entité) sur les docs synchronisés ; sur son signal de changement, re-jouer le jeu borné de `sparql_query` par-doc (`readUnion`).
+
+Concrètement :
+
+1. **La lib expose un wrapper typé `doc_subscribe`.** Il n'existe pas aujourd'hui. Ajouter dans `packages/client/src/docs.ts` (ou un nouveau `subscribe.ts`) une fonction, p.ex. :
+   ```ts
+   // renvoie un unsubscribe ; onChange appelé au State initial puis à chaque Patch
+   export function subscribeDoc(nuri: Nuri, onChange: (r: AppResponse) => void): () => void
+   ```
+   qui wrappe `ng.doc_subscribe(nuri, sessionId, cb)` et normalise l'AppResponse (initial + patches) + la fermeture du flux. C'est **par-document** (un NURI), donc immunisé au hang du fan-out.
+   - Exposer aussi un helper pour souscrire **un ensemble** de docs en montant **une souscription par doc** (map `nuri → unsubscribe`), avec **isolation par-doc des erreurs** : un `RepoNotFound` / doc non-synchronisé ne fait échouer QUE sa propre souscription (retry/skip), jamais les autres. C'est le point-clé qui évite de reproduire le fan-out. Le contrat SDK (`sdk-reference.md`) devra documenter ce wrapper.
+
+2. **Le contexte data (FestipodDataContext) monte une souscription par-doc sur le jeu qu'il lit déjà.** Le jeu `allReadDocs` (union `publicDocs` ∪ `protectedDocs`) est déjà borné et par-besoin. Nouvel effet dans `useNgData()` :
+   ```
+   useEffect(() => {
+     const unsubs = allReadDocs.map(nuri => subscribeDoc(nuri, () => bumpRead()));
+     return () => unsubs.forEach(u => u());
+   }, [allReadDocs]);
+   ```
+   → sur **tout** patch d'un des docs abonnés (écrit par CETTE session OU une autre), `bumpRead()` re-déclenche le `readUnion` existant (l.347-364). **`readTick`/`bumpRead` restent** — ils cessent d'être « manuel après ma mutation » pour devenir « poussé par le broker ». La forme du contexte (valeurs `events`/`users`/`participations` en `useState`) **ne change pas** ; les écrans continuent de lire via `useFestipodData()` sans modification.
+
+3. **Entrée de NOUVEAUX docs dans le jeu abonné, sans fan-out hang :**
+   - **Nouvel événement découvert** : la découverte réactive remplace `discovery.watchIndex` (setInterval) par une **souscription `doc_subscribe` sur le doc d'index global** (l'inbox d'index, un seul doc — `resolveInboxAnchor`-style). À chaque patch de l'index → re-lire `readDiscoveredEvents()` → les nouveaux `doc` NURIs entrent dans `publicDocs` (via `setPublicDocs`), ce qui **agrandit `allReadDocs`**, ce qui **remonte la souscription par-doc** (nouveau `useEffect` ci-dessus) → le nouvel événement est lu ET désormais abonné. Pas de fan-out : chaque doc est abonné **individuellement**, quand il entre.
+   - **Nouveau dépôt d'inbox** (nouveau participant, notification hôte) : idem, remplacer `inbox.watch` (setInterval) par une **souscription `doc_subscribe` sur le doc-inbox** concerné (un seul doc). Un patch → re-matérialiser (§B).
+   - **Doc que je viens de créer** : `registerDoc` continue de l'ajouter à `publicDocs`/`protectedDocs` → il entre dans `allReadDocs` → il est abonné. (`bumpRead` immédiat garde la latence perçue nulle localement.)
+
+4. **La lib remplace ses watchers polling** : `inbox.watch` et `discovery.watchIndex` deviennent des wrappers `doc_subscribe` sur le doc-inbox / doc-index respectif (un doc chacun — pas de fan-out). Signature publique conservée (callback + unsubscribe) pour ne pas casser les appelants ; l'implémentation passe de `setInterval(read)` à `subscribeDoc(anchor, () => read().then(onX))`.
+
+### Ce qui NE change pas
+- `readUnion` reste one-shot, par-doc, tolérant (un doc en échec → `[]`, jamais d'abort).
+- Le mapping `readEntities` (`src/shared/data/readEntities.ts`) est inchangé.
+- **Aucun `useShape({graphs:[…]})` par-entité n'est introduit** — le seul `useShape` restant est le `FanoutProbe` du harness de test (qui sert justement à *démontrer* le hang), pas un chemin applicatif.
+
+---
+
+## B. Compteur de participants — Option B (dépôt → matérialisation propriétaire)
+
+### Les documents / inboxes impliqués
+- **Doc de participation de l'inscrit** : protected, **possédé par l'inscrit** (déjà créé par `joinEvent`, `createEntityDoc(owner,'protected')` + `writeEntity(ENTITY_TYPE.participation, …)`). Lisible en clair par les **connexions** de l'inscrit uniquement (cap protected + `declareConnections`).
+- **Inbox de l'événement** : résolue par `hostInboxNuri(eventId)` → `resolveInboxAnchor()` (aujourd'hui une anchor unique ; à migration, un doc-inbox par événement — `hostInboxNuri` réserve déjà le param `eventId`). C'est là que l'inscrit **dépose le lien de participation**.
+- **Doc de l'événement** : public, **possédé par le propriétaire**. C'est **le propriétaire** qui y écrit `participantCount` — jamais l'inscrit.
+- **(référence) enregistrée par le propriétaire** : une entrée reliant le compte incrémenté au dépôt (idempotence + audit) ; peut vivre dans le doc de l'événement (référence de dépôt déjà matérialisé) ou un doc protected du propriétaire.
+
+### Le flux (qui écrit quoi)
+1. **Inscrit — `joinEvent`** (modifié) :
+   - Écrit sa propre `Participation` (protected, à lui) — **inchangé**.
+   - **Dépose dans l'inbox de l'événement** un payload `{ kind:'new-participant', eventId, participationDoc, participantId, uid }` via `depositRegistration` (aujourd'hui `inbox.post(target, {from:null, payload})`, `registration.ts:110-125`). `from` reste anonyme au transport (le SDK lie `from` à l'identité et rejette un spoof — cf. `registration.ts:106-108`) ; l'identité domaine voyage dans le payload. **Le dépôt porte le NURI du doc de participation** (`participationDoc`) pour que le propriétaire, s'il est une connexion, puisse le lire en clair.
+   - **SUPPRIME l'écriture de `participantCount` sur le doc de l'événement** (l.635-640 actuelles). L'inscrit n'écrit plus jamais sur le doc d'un autre.
+2. **Propriétaire — matérialisation (quand connecté)** : la session du propriétaire est abonnée (`doc_subscribe`, §A.3) au doc-inbox de son événement. Sur un nouveau dépôt `new-participant` :
+   - dédup via `uid` (idempotence : ne pas re-compter un dépôt déjà matérialisé — vérifier la (référence) enregistrée) ;
+   - **incrémente `participantCount` sur SON PROPRE doc d'événement** (`updateEntityField(eventDoc, eventDoc, 'participantCount', int(next))`) — **c'est le propriétaire qui écrit son propre doc**, pas un privilège de lecture ni un write hors-scope ;
+   - enregistre la **(référence)** du dépôt matérialisé (marqueur d'idempotence).
+   - Cette logique remplace/prolonge l'effet de **matérialisation des notifications** existant (FestipodDataContext l.443-479, `readRegistrationNotifications`) : aujourd'hui il ne fait que surfacer des notifications ; il devient aussi le point où le compteur est incrémenté. Le déclencheur passe du polling implicite à la souscription `doc_subscribe` sur l'inbox.
+3. **Autres sessions voient le compte changer** : le doc de l'événement est **public**, donc **toute** session qui l'a dans son `allReadDocs` y est abonnée (§A). L'écriture du propriétaire produit un patch → `bumpRead()` → `readUnion` re-lit → `event.participantCount` mis à jour → `EventDetailScreen` re-rend « Participants (N) » **sans reload ni action**. C'est le chemin réactif complet, cross-session.
+
+### Désinscription (symétrique, autoritative)
+- `leaveEvent` : garde le **DELETE autoritatif** de la participation (`deleteParticipation`, vérifié `remaining === 0`) — [[caveat_participation-deletion]] intact (ne doit pas ressusciter).
+- **Retire la décrémentation directe** de `participantCount` par l'inscrit (l.705-710). À la place, l'inscrit **dépose un `leave`** (`{ kind:'leave-participant', eventId, uid }`) dans l'inbox de l'événement ; le propriétaire matérialise → **décrémente son propre doc** (idempotent via `uid`, `max(0, n-1)`, et refuse de re-décrémenter un `uid` déjà traité pour ne pas « ressusciter » un compte faux).
+- **Cas propriétaire hors-ligne = comportement éventuel ACCEPTÉ** : si le propriétaire n'est pas connecté, le dépôt reste dans l'inbox ; le compte n'est **pas** mis à jour tant qu'il ne se reconnecte pas et ne matérialise pas. **C'est un comportement accepté** (cohérence à terme, local-first). Les autres voient le compte se corriger quand le propriétaire revient. À énoncer tel quel dans le contrat produit.
+
+### Identité (C)
+- Un participant est montré **par son nom** uniquement si le viewer est une **connexion** du participant : le doc de participation + le profil du participant sont protected, donc lisibles en clair seulement via le cap accordé par `declareConnections` (`src/shared/utils/connections.ts` → `grantRead(protectedDocsOf(owner), neighbour)`). Sinon le doc reste illisible → le participant n'apparaît **pas** dans `getEventParticipants` (qui joint sur les `users`/`participations` lus) → il tombe dans les **placeholders « inconnu »** de `EventDetailScreen` (l.163-170), le compte dérivé restant visible via `participantCount`.
+- **Aucune lecture privilégiée de l'hôte** : le propriétaire ne lit pas les participations ; il ne fait que **compter des dépôts** et écrire son propre compteur. Il ne voit un participant nommé que s'il en est une connexion — exactement comme n'importe quel viewer. C'est conforme à `functional-domain/knowledge_data-scopes-and-discovery` (« identifié si connu, anonyme sinon ») et à `app-security/knowledge_trust-model` (pas de contrôle d'accès applicatif, l'isolation est par-document déléguée au SDK).
+
+---
+
+## D. Plan de test (e2e réel, sans polling)
+
+### D.1 — POLYFILL bas-niveau : `doc_subscribe` réagit vraiment
+But : prouver que la primitive réactive fonctionne, indépendamment de Festipod.
+- Emplacement : test unité/intégration de la lib (`packages/client`) — ou un `@data` Festipod si le harness broker est requis.
+- Setup : deux « vues » du **même** doc (deux souscriptions, ou une souscription + une écriture par un autre chemin). Monter `subscribeDoc(nuri, onChange)`, écrire dans le doc via `sparqlUpdate`.
+- **Assertion** : `onChange` est appelé (State initial) **puis** re-appelé après l'écriture, **sans polling** (aucun `setInterval` ; l'assertion attend un event, pas un timeout). Vérifier qu'une écriture sur un **autre** doc ne déclenche PAS `onChange` (isolation par-branche). Vérifier qu'un doc non-synchronisé qui échoue **n'avorte pas** les autres souscriptions (par-doc).
+
+### D.2 — FESTIPOD app-level : 2 navigateurs réels, sans reload ni action de A
+But : B s'inscrit → l'`EventDetailScreen` de A montre `participantCount` incrémenté **et** un « participant inconnu », **sans que A recharge ni n'agisse**.
+- Étendre `src/modules/event/features/e2e-multibrowser.feature` (`@multibrowser @shared-wallet`) et `src/modules/event/steps/e2e/multibrowser-features.steps.ts`.
+- Nouveau scénario (esquisse Gherkin FR) :
+  ```
+  Scénario: Un participant apparaît réactivement dans l'autre navigateur sans reload
+    Étant donné un navigateur "A" avec le wallet partagé
+    Et un navigateur "B" avec le wallet partagé
+    Et le navigateur "A" charge l'application via le broker
+    Et le navigateur "B" charge l'application via le broker
+    Et le navigateur "A" est connecté à NextGraph
+    Et le navigateur "B" est connecté à NextGraph
+    Et le navigateur "A" crée l'événement "Apéro réactif"
+    Et le navigateur "A" ouvre le détail de l'événement "Apéro réactif"
+    Et le compteur de participants affiché dans "A" pour "Apéro réactif" vaut 1
+    Quand le navigateur "B" s'inscrit à l'événement "Apéro réactif"
+    Alors sans recharger, le compteur de participants affiché dans "A" pour "Apéro réactif" passe à 2
+    Et le navigateur "A" affiche un participant "inconnu" pour "Apéro réactif"
+  ```
+- **Assertions exactes** :
+  1. `participantCount` **côté A** passe de 1 à 2 — assert via `frame.waitForFunction` sur l'état réactif du contexte (`__testData.events` → l'event → `participantCount === 2`) **puis** confirmé sur le DOM rendu (le libellé « Participants (2) » de `EventDetailScreen`), **sans appel de `loadAppInBrowser`/reload** entre le join de B et l'assertion de A.
+  2. **Placeholder inconnu** : `knownParticipants.length < participantCount` → assert présence du bloc « Voir tous les participants » (ou un compteur d'anonymes = `participantCount − knownParticipants.length ≥ 1`), le participant B n'étant PAS une connexion de A → non nommé.
+  3. **Négatif no-polling** : le passage 1→2 arrive via souscription (event-driven) ; le test attend l'event, il ne doit pas dépendre d'un `waitForTimeout` fixe comme *source* de la mise à jour (un timeout de garde reste toléré pour laisser la sync broker, comme dans le scénario désinscription existant l.131).
+- **Helpers harness nécessaires** (dans `harness-ng.tsx`, exposés sur `window.__testData`, et répliqués dans les DEUX harness — cf. `bdd-testing/cookbook_add-scenario`) :
+  - un getter du `participantCount` réactif pour un event (déjà accessible via `__testData.events`).
+  - un accès au **rendu** `EventDetailScreen` de A **sans navigation manuelle** : soit monter l'app réelle sur la route détail (chemin @e2e), soit exposer `knownParticipants` / le compte d'anonymes. Réutiliser `createEventReal` (l.232), `appJoinEvent` (l.245), `readInboxDeposits` (l.283), `authParticipationCount` (l.302).
+  - un hook « le propriétaire a matérialisé » : comme A est le propriétaire ET connecté, sa souscription inbox doit incrémenter son propre doc — le test observe le résultat (count 2) sans piloter la matérialisation à la main.
+- **Symétrie désinscription** : étendre le scénario existant « la désinscription ne ressuscite pas » (l.36-48) d'une assertion réactive : après le leave de B, `participantCount` côté A **repasse à 1 sans reload**, et `authParticipationCount === 0` (déjà couvert).
+
+---
+
+## E. Risques / questions ouvertes
+
+1. **Le hang du fan-out** (le risque n°1). Le design l'évite **par construction** : souscription **par-document** (`doc_subscribe`), jamais `orm_start_graph(graphs:[…])`. À garder comme invariant : tout nouveau doc entre via une souscription **individuelle** avec isolation d'erreur par-doc — un doc non-synchronisé ne doit jamais pouvoir avorter les autres souscriptions ni bloquer le `readUnion` (qui reste tolérant par-doc). Risque résiduel : le **volume** de souscriptions par-doc (une par doc lu) — à valider sur le broker réel ; sinon, plafonner/prioriser les docs abonnés (event courant + son inbox + mes docs) plutôt que l'union entière.
+
+2. **Compte propriétaire hors-ligne = éventuel — DÉCIDÉ (2026-07-06).** Tant que le propriétaire n'est pas connecté, aucun dépôt n'est matérialisé → `participantCount` reste périmé pour les autres (la participation elle-même est persistée côté broker — rien n'est perdu, seul l'agrégat attend la reconnexion de l'hôte). Accepté pour la V1. **Plus tard, un SERVICE prendra le relai** quand le propriétaire est déconnecté (le paquet différé `@ng-eventually/service` — le « curateur » évoqué dans les docs inbox de la lib) : un acteur toujours disponible matérialisera l'inbox à la place de l'hôte. Pas de fallback « N+ en attente » en V1.
+
+3. **`doc_subscribe` par-doc — FAIT (lib `c0498a6`).** La lib expose désormais `subscribeDoc`/`subscribeDocs` (isolation d'erreur par-doc, pas de fan-out ORM), `inbox.watch`/`discovery.watchIndex` sont passés en `doc_subscribe` (plus de polling), et le contrat est dans `sdk-reference.md`. Validé broker réel (le callback traverse le RPC iframe et fire sur changement). Reste : brancher la souscription dans le chemin de lecture app (P3).
+
+> **Hooks réactifs du SDK** (précision) : l'adaptateur React de NextGraph expose `useShape` (shapes RDF réactives) et `useDiscrete` (docs CRDT discrets) — pas de `useQuery`. La lib ré-expose `useShape`. Pour la lecture UNION de N docs (le cas de Festipod), `useShape`/l'ORM en fan-out *hangue* ; le chemin réactif app passe donc par `subscribeDocs` (par-doc) + re-`readUnion`, éventuellement enveloppé en un hook de lecture réactive côté lib (à décider en P3).
+
+Autres points à trancher :
+
+> ⚠️ **RECADRÉ + CORRIGÉ (2026-07-13).** L'affirmation ci-dessous « Prouvé par l'e2e D.2 … sans reload » était **FAUSSE** (le « vert » venait d'un wallet bloaté). Mais surtout le **cadrage « réactif / sans reload / push cross-session » était un SUR-CADRAGE** : la spec réelle est **« le propriétaire traite son inbox de façon fiable à sa PROCHAINE CONNEXION »** (pas de notification live temps-réel entre deux utilisateurs connectés). Bug corrigé sous ce cadrage : le materializer lisait l'inbox **avant sa sync** (→ 0 mémoïsé). Fix = lecture inbox **gated sur barrière** (`inbox.readSynced` = `ensureRepoOpen` + `read`) + déclenchement à la connexion + source unique `event.participantCount`. Scénario `event/e2e-multibrowser.feature` **reframé « à la prochaine connexion » et dé-`@wip`, VERT sur profil frais** (une reconnexion/re-matérialisation de A est le mécanisme accepté). Détail : [[knowledge_context-internals]] §participantCount. Le plan de phasage ci-dessous doit être relu à cette lumière (le « sans reload » n'est plus l'exigence).
+
+- **Ordre de phasage :** ~~(P1) lib : `subscribeDoc` + variante multi-doc + tests D.1~~ **FAIT (`c0498a6`)** ; ~~(P2) lib : remplacer `inbox.watch`/`discovery.watchIndex` par `doc_subscribe`~~ **FAIT (`c0498a6`)** ; ~~(P3) app : brancher la souscription par-doc dans `useNgData` (bumpRead poussé) + découverte réactive~~ **FAIT (branche `ng-eventually`, non commité)** — `useNgData` monte un effet `subscribeDocs(allReadDocs, …)` clé sur un join trié des NURIs (`readDocKey`, anti-boucle : un patch → `bumpRead` → re-`readUnion` ne change pas le set → pas de re-souscription ; le reset d'identité `prevOwnerRef` vide le set → `readDocKey=''` → cleanup unsubscribe, puis re-listing → re-souscription sur le set reconstruit) + un effet de découverte réactive `watchDiscoveredEvents()` (wrapper app sur `discovery.watchIndex`, déjà `doc_subscribe`) → `relist()`. `readUnion` reste le lecteur one-shot tolérant. **Prouvé par l'e2e D.2** (`e2e-multibrowser.feature`, scénario « Un participant apparaît réactivement… », @multibrowser @shared-wallet, 12 steps verts en isolation) : B s'inscrit → A voit `participantCount === 2` + un participant « inconnu » **sans reload ni action**, via `doc_subscribe` sur le doc public de l'événement (le join en P3 écrit encore ce compteur, cf. §B.5 — c'est ce qui valide P3 avant P4). ; (P4) app : Option B join (retirer le write compteur de l'inscrit, matérialisation propriétaire) ; (P5) app : Option B leave symétrique ; ~~(P6) e2e D.2~~ **FAIT avec P3** (le scénario réactif ci-dessus ; la symétrie désinscription réactive reste à ajouter avec P5). P1→P3 livrent la réactivité ; P4→P6 le compteur correct. On peut livrer P1–P3 avant P4–P6.
+- **Idempotence de la matérialisation** : le `uid` par-dépôt (`RegistrationPayload.uid`, `registration.ts:56`) est le pivot ; la (référence) enregistrée par le propriétaire doit être consultée avant tout incrément/décrément pour ne jamais double-compter (rejeu de sync) ni « ressusciter » un compte.
+- **Migration inbox natif** : aujourd'hui l'inbox est émulée sur le wallet partagé (`inbox.ts` post/read RDF). À la migration vers l'inbox broker natif (`inbox_post`/`inbox_pop_for_user`, scellé), le flux Option B **reste valide** (dépôt non-membre autorisé, lecture réservée aux *readers* = propriétaire), mais le wrapper `subscribeDoc` sur l'inbox devra viser le mécanisme natif de notification de dépôt. À vérifier au moment de la migration.

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

@@ -0,0 +1,17 @@
+---
+type: caveat
+summary: Le type FpEventData et le seed portent startDate/endDate/startTime/endTime/themes, mais le SHEX Event ne les définit pas — ces champs sont silencieusement perdus en mode connected (NextGraph)
+last_checked: 2026-06-15
+---
+
+# Caveat : champs d'événement non persistés en mode connected
+
+Le type app `FpEventData` (`src/shared/data/types.ts`) et le seed (`seedData.ts`) portent des champs **`startDate`, `endDate`, `startTime`, `endTime`, `themes`** — mais la **shape SHEX `Event`** (`src/shared/shapes/shex/festipodShapes.shex`) ne les définit **pas**. La shape ne couvre que : `title, description, date, location, distance, participantCount, coverImage, hostName, hostInitials` (à vérifier dans le `.shex`).
+
+## Conséquence
+
+En **mode connected** (SDK), le mapping (`mapEvent` dans `FestipodDataContext.tsx`) ne lit/écrit que les champs de la shape. Les champs hors-shape sont **silencieusement perdus** : remplis par des defaults ou vides. Or des écrans **les affichent** (ex. `startTime`/`endTime` dans `EventDetailScreen`) — donc en mode démo (seed local) ils apparaissent, mais en connecté ils disparaissent. Décalage observable seulement à l'usage.
+
+## Pour corriger (si on veut les persister)
+
+Ajouter les champs à `festipodShapes.shex` puis `bun run build:orm`, et étendre `mapEvent`. Tant que ce n'est pas fait, **ne pas se fier aux champs date/heure/thèmes en mode connecté**.

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

@@ -0,0 +1,15 @@
+---
+type: caveat
+summary: La désinscription à un point de rencontre doit être AUTORITATIVE — une fois la Participation supprimée, elle ne doit plus réapparaître ; vérifier après un vrai rafraîchissement que l'inscription a bien disparu côté données
+last_checked: 2026-07-03
+---
+
+# Caveat : la désinscription doit être autoritative
+
+Contrat métier : quand un utilisateur **se désinscrit** d'un point de rencontre (`leaveEvent` dans `src/shared/context/FestipodDataContext.tsx`), la `Participation` doit être **supprimée durablement**. Elle ne doit **pas ressusciter** après une resynchronisation.
+
+## Le piège
+
+Refléter la suppression uniquement dans l'état réactif de l'UI ne suffit pas : l'inscription peut réapparaître si la suppression n'est pas **persistée** côté données. La désinscription doit donc être **autoritative** au niveau du document, pas seulement au niveau de l'affichage.
+
+**À vérifier après toute évolution de `leaveEvent`** : s'inscrire puis se désinscrire, faire un **vrai rafraîchissement**, et confirmer que la participation a bien disparu (le bouton ne doit pas rester « ✓ Je participe »). Couvert par le scénario `@e2e` « Se désinscrire d'un événement » (`src/modules/event/features/cycle-de-vie-evenement.feature`) et un `@data` « désinscription persistante » (`inscription-inbox.feature`).

.project/concepts/data-layer/caveat_write-durability-across-disconnect.md

@@ -0,0 +1,17 @@
+---
+type: caveat
+summary: Une entité écrite juste avant une inactivité/chute de socket peut être perdue silencieusement (jamais durable côté broker) ; le compte survit (pas de fork). Observé Firefox. Le SDK ne confirme pas la durabilité et ne se reconnecte pas seul.
+last_checked: 2026-07-14
+---
+
+# Piège : une écriture juste avant une déconnexion n'est pas garantie durable
+
+**Symptôme produit.** L'utilisateur crée une entité (un événement), ça semble réussir, puis une **période d'inactivité** survient ; au rechargement / à la reconnexion, l'entité a **disparu**. Le scope se relit **vide**. L'**identité/compte survit** — ce n'est PAS un fork, c'est une écriture non durable.
+
+**Mécanisme (résumé, non tranché).** Le socket broker peut mourir spontanément pendant l'idle (`SOCKET IS CLOSED … SerializationError`). L'écriture était dans l'outbox local ; au retour, le replay échoue (`Err(TopicNotFound)`) et l'entité est abandonnée. **Observé Firefox uniquement** à ce jour. Un test @data à froid (2026-07-14) a par ailleurs montré qu'une session **fraîche** (aucun état local, même compte A) ne récupère **pas** le scope propre de A depuis le broker : le test de reconnexion @data qui « passait » relisait en fait l'IndexedDB **locale**. Reste à trancher : **perte à l'écriture** vs **échec de réhydratation à froid** (mécanismes distincts) — voir le post-mortem dans le polyfill.
+
+**Pourquoi l'app ne le voit pas.** `NgStatus` est dérivé **une seule fois** de la session initiale → aveugle aux chutes en cours de session. Le canal `disconnections_subscribe` du SDK se déclenche sur la panne mais **n'est pas consommé** (ni polyfill ni app). Aucune API ne confirme qu'une écriture a atteint le broker.
+
+**Ne pas documenter ici les internes NextGraph.** Frontière SDK (voir [[knowledge_nextgraph-stack]]) : cause racine, chaîne causale (socket, reconnexion en TODO) et pistes de correction vivent dans le repo `@ng-eventually/client` → `docs/incidents/2026-07-14-write-loss-on-disconnect.md`. Cette fiche ne garde que l'**impact consommateur** + le pointeur.
+
+**Statut : ouvert, non traité (2026-07-14).** À revisiter quand le core/SDK adresse la reconnexion ou expose une confirmation de durabilité — ce caveat tombera alors. Voir aussi le débat lecture-à-froid vs perte réelle dans [[brief_2026-07-06_reactive-reads-and-attendance]] (le `BARRIER timed-out` de @data est une signature distincte, non confirmée comme ce bug).

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

@@ -0,0 +1,81 @@
+---
+type: knowledge
+summary: Pièges internes de FestipodDataContext — currentUserId = principal stable dérivé de l'identifiant, auto-seed OPT-IN (FESTIPOD_AUTO_SEED, OFF par défaut), participantCount dérivé Option-B (fiable à la connexion du propriétaire via lecture inbox gated sur barrière ; source unique = event.participantCount), instrumentation useShapeQuery (spinner+timing), mutations no-op en mode local malgré le toast
+last_checked: 2026-07-07
+---
+
+# Internals & pièges de `FestipodDataContext`
+
+Comportements non évidents de `src/shared/context/FestipodDataContext.tsx` à connaître avant de toucher au contexte de données.
+
+## Résolution du `currentUser` (mode NG)
+
+En mode connected, le **principal** du currentUser (`currentUserId`) n'est **pas** `CURRENT_USER_ID` ('user-1', mode local) ni l'IRI du profil lu. Quand un identifiant est connecté, c'est un id **stable dérivé de l'identifiant** : `urn:festipod:user:<identifiant-normalisé>`, disponible immédiatement (sans dépendre de la lecture du profil protégé) et invariant sur la session — c'est la même clé que `setCurrentUser`, le cap owner et le compte shim (cf. [[rule_document-per-entity]], corollaire d'identité). Pièges restants :
+- L'objet `currentUser` (le profil affiché) est, lui, résolu par `users.find(u => normalizeIdentifier(u.username) === identifiant)` avec **fallback** `@mariedupont` puis `users[0]` — un fallback silencieux si l'identifiant ne correspond à aucun profil (l'identifiant est un id d'espace, pas forcément le `username` d'un profil seedé).
+- Sans identifiant connecté (dev/demo), `currentUserId` retombe sur l'IRI du profil lu (ou `''` si le wallet est vide → `Participation` avec `user: ''` invalide) : ne créer une participation qu'une fois le principal résolu.
+
+## Lecture = `watchShape` (surface SDK), plus de machinerie bespoke
+
+**Depuis 2026-07-10** : `useNgData` lit via `useShapeQuery(shape, scope)` (binding
+`useSyncExternalStore` sur `watchShape` du polyfill) — TROIS lectures useQuery-shaped
+(events/public, users/protected, participations/protected) + adaptateurs Fp
+(`shapeAdapters.ts`). Supprimés : `readEntities`, `subscribeDocs`+`bumpRead`+`readTick`,
+le listing manuel (`publicDocs`/`protectedDocs`/`registerDoc` pour la lecture),
+`relist`. `ready` = combinaison des `isSuccess`. Cf. [[rule_app-uses-sdk-surface-only]].
+
+**Visibilité immédiate des mutations = overlay OPTIMISTE** (pas de `registerDoc`) :
+`createEvent`/`joinEvent`/`leaveEvent` alimentent `pendingAddEvents`/
+`pendingAddParticipations`/`pendingRemoveIds` ; l'état exposé = merge(réactif, adds)
+moins removes, dédupé par id (id = NURI du doc). Réconciliation auto au push
+(un add qui apparaît dans le réactif / un remove qui en disparaît est retiré) —
+jamais de poll ([[rule_no-broker-polling]]). Vidé au changement d'identité.
+
+## Auto-seed de dev
+
+**Depuis 2026-07-13, l'auto-seed est OPT-IN et OFF par défaut** : il ne se déclenche que si la variable d'env `FESTIPOD_AUTO_SEED` est définie (`=1`), plus sur `NODE_ENV`. Variable absente → **aucun seed automatique**, même en dev (`autoSeedEnabled()`/`shouldAutoSeed()`, `src/shared/utils/autoSeed.ts` ; livrée en dev via la route runtime `/festipod-config.json` + `define` compile-time dans `build.ts`, même mécanisme que le shared-wallet — cf. `tech-stack/knowledge_build-pipeline`). Le seed **explicite** (`loadTestData()`, tests @data) est inchangé. Motivation : le seed auto répété bloatait le wallet (lenteurs de lecture, cf. [[caveat_wallet-bloat-hang]]).
+
+Quand il est activé, l'auto-seed se déclenche si events ET users sont vides — **gardé sur `isSuccess`** (la readiness de `watchShape`),
+PLUS sur un `setTimeout` de 3s : on ne décide « wallet vide » qu'une fois la sync
+**confirmée** (`isSuccess`), sinon la lecture pas-encore-finie était prise pour un
+wallet vide → re-seed à chaque reconnexion (bug corrigé). Pièges restants :
+- **Un seul seed à la fois** : `loadTestData()` pose `hasTriedAutoSeed`, l'auto-seed le
+  re-teste → un chargement explicite supprime l'auto-seed en attente (sinon deux
+  `bootstrapWallet` concurrents écrivent en double).
+- Le seed est **possédé par l'identité courante** (`bootstrapWallet(…, owner)`) : les
+  entités protégées seedées passent le cap de lecture par-document du propriétaire.
+- **Pas de retry** : si le seed échoue, écran vide + `console.error`.
+
+## `participantCount` — dérivé et possédé par le propriétaire (Option B)
+
+> ✅ **CORRIGÉ (2026-07-13).** L'exigence est **« fiable à la PROCHAINE CONNEXION du propriétaire »** (le créateur traite son inbox à sa connexion), PAS une notification live cross-utilisateur temps-réel. Le bug était : le owner-materializer matérialisait **trop tôt** (avant que le dépôt de l'inscrit soit synchronisé) → lisait `active=0` → écrivait 0 → **mémoïsait ce 0** → ne retraitait plus. Fix : (1) **lecture inbox gated sur barrière** — `inbox.readSynced` (= `ensureRepoOpen(doc)` attend le premier `State`, PUIS `read`, comme `discovery.readIndex`) au lieu de `inbox.read`, donc un dépôt déjà synchronisé EST vu à la connexion ; (2) le materializer se déclenche **directement à la connexion** (`[ready, ownedKey]`), plus seulement sur un push ; (3) `materializedCountRef` ne verrouille plus un 0 prématuré (son seul rôle = anti-boucle : n'écrire que si la valeur dérivée change) ; (4) **source unique du NOMBRE = `event.participantCount`** (le littéral `participantCount: 1` de `CreateEventScreen` est retiré → démarre à 0 ; l'affichage ne calcule plus de nombre local). Gardé VERT (profil frais) par `event/e2e-multibrowser.feature` « Le compteur converge chez le propriétaire à sa prochaine connexion » (dé-`@wip`). Pas de polling ([[rule_no-broker-polling]]).
+
+**Depuis Option B (2026-07-07)** : `participantCount` n'est plus muté en place par l'inscrit. Le flux est dépôt-inbox → matérialisation-propriétaire :
+- `joinEvent`/`leaveEvent` n'écrivent **plus** `participantCount` sur le doc de l'événement (ce serait une violation d'isolation — l'inscrit écrirait le doc d'un autre ; le write NextGraph est membership-bound, pas d'append). L'inscrit écrit seulement son **propre** doc de participation (protected) puis **dépose** un marqueur dans l'inbox de l'événement (`depositRegistration` sur join, `depositLeave` sur leave, `src/shared/data/registration.ts`).
+- La session du **propriétaire** de l'événement matérialise : elle est abonnée (`inbox.watch`, `doc_subscribe`, sans polling) à l'inbox de ses events possédés (`ownedEventIds` = `listMyEntityDocs(owner,'public')` + les events fraîchement créés), et sur chaque dépôt **recalcule** `participantCount` sur **son propre** doc d'événement (`updateEntityField` sur son doc). C'est le seul écrivain du compteur.
+- **Le compteur est DÉRIVÉ, pas incrémenté** : `materializeAttendance` (registration.ts) lit l'inbox et calcule l'**ensemble** des inscriptions actives distinctes (dépôts `new-participant` dédupés par `uid`, MOINS ceux annulés par un `leave-participant` — par `regUid` exact ou fallback `(eventId, userId)`). `participantCount = |ensemble actif|` — **pas de base « hôte »** : le créateur ne participe pas automatiquement (pas de notion d'hôte, cf. concept `functional-domain`), donc le compteur démarre à **0** à la création et n'avance que sur des inscriptions réelles. `createEvent` **n'écrit plus** de participation à la création (elle écrivait une participation hôte + posait le compteur à 1) ; le créateur voit « J'y serai » et peut rejoindre/quitter son propre événement comme tout le monde. Comme c'est une **fonction pure de l'inbox**, un rejeu de sync broker converge — jamais de double-comptage ni de décrément fantôme (idempotence). L'écriture est gardée (n'écrit que si la valeur change), anti-boucle. Couvert par le scénario `@data` « Le créateur ne participe pas automatiquement à son événement » (us-13) : compteur 0 + `isParticipating(E)===false` à la création, puis join→true / leave→false.
+- **Propriétaire hors-ligne = éventuel** : seule la session du propriétaire matérialise ; déconnecté, le compteur n'avance pas pour les autres (les participations/dépôts restent persistés — rien n'est perdu ; un futur service matérialisera à sa place).
+- Le compteur reste néanmoins un **agrégat**, pas la liste des participants nommés : `getEventParticipants` (identité nommée) reste gouverné par le cap de lecture protected ([[caveat_participation-deletion]] pour la suppression autoritative, inchangée). Cf. le brief `brief_2026-07-06_reactive-reads-and-attendance` §B.
+
+### Invariant id-form : apparier sur la forme CANONIQUE de l'event-id
+
+Le `@id` d'un événement **est** son NURI de document (`did:ng:o:<repo>[:v:<overlay>]`). Le matérialiseur du propriétaire apparie les **dépôts** de l'inbox aux événements possédés **par l'event-id** : `ownedEventIds` (ce que le matérialiseur itère), la **clé de dépôt** (`payload.eventId`, ce sous quoi l'inscrit dépose) et la **cible d'écriture** du compteur doivent désigner le même événement.
+
+**Constat mesuré (2026-07-07)** : sur l'arbre courant ces trois voies portent le **même** NURI (suffixe `:v:<overlay>` inclus) — create-time, `listMyEntityDocs` et le `@id` relu coïncident, parce que `readUnion` **épingle le subject au NURI d'entrée** (lib `read-model.ts`, `63ecfee`). L'appariement marche donc déjà, **y compris** pour un événement possédé atteint via `listMyEntityDocs` (validé par le scénario @data « …fait converger le compteur dérivé »). La canonicalisation ci-dessous est **défensive**, pas la correction d'un bug actif. (Le non-match qu'une investigation avait cru voir était l'artefact **seedé-mais-pas-possédé** : sur un wallet persistant, le seed appartenait à une identité `test-*` d'un run antérieur → la session courante l'atteint par découverte, pas par `ownedEventIds` — comportement correct.)
+
+**Règle** : apparier l'event-id sur sa **forme canonique** — l'id de repo de base, en retirant tout suffixe `:v:<overlay>` (`canonicalEventId`, `src/shared/data/registration.ts`). Cette forme canonique est utilisée pour l'**appariement** dans `materializeAttendance` / `readRegistrationNotifications`, et pour **dédupliquer** `ownedEventIds` (`ownedKey`, FestipodDataContext) afin qu'un même événement atteint par deux voies ne soit pas matérialisé deux fois. **Attention** : seul l'**appariement** utilise la forme stripée ; le compteur est toujours **écrit** sur le vrai NURI possédé (un doc vivant, ouvrable) — un id stripé ne doit jamais servir de cible d'écriture / d'ancre. C'est un invariant **côté app** (pas un détail NextGraph) : quelle que soit la façon dont la lib fait varier l'overlay, l'app apparie sur la base commune.
+
+## Changement d'identité = session fraîche (isolation)
+
+Le jeu de lecture par besoin (`publicDocs`/`protectedDocs`) **accumule** les docs de scope de l'identité courante (pour ne pas perdre un doc juste créé avant la re-liste). Or le stopgap wallet-partagé garde **un seul arbre React** au travers d'un faux-logout + re-login sous un **autre identifiant** (pas de rechargement — `AccountContext.login` ne fait que réécrire l'identifiant en localStorage, `AuthGate` ne remonte rien). Sans réinitialisation, **les docs PROTECTED de l'identité précédente (ses participations) survivent dans le jeu de lecture de la nouvelle identité et fuient** via la lecture union : le cap gate ne peut pas les filtrer quand le registre de caps (en mémoire) ne gouverne pas ce doc *cette* session (doc persisté d'un run antérieur, ou chargement frais où les caps sont vides). Symptôme observé : un utilisateur B voyait la participation de A (et l'événement de A apparaissait sur l'**accueil** de B, car l'accueil = `getUserEvents(currentUserId)`, cf. concept `app-architecture`).
+
+**Règle** : traiter **tout changement d'identifiant** comme une session fraîche — un `useEffect([identifier])` (ref-gardé pour ne pas tirer au premier mount) vide `publicDocs`/`protectedDocs`, appelle `resetCaps()` + `resetRegistryCache()`, puis bump le read tick ; l'effet de listing reconstruit le jeu **borné à la nouvelle identité**. L'isolation reste par-document/émulée (concept `app-security`, [[knowledge_trust-model]]) ; ce reset ne fait que supprimer le report d'état inter-identités.
+
+**Mécanisme confirmé empiriquement (2026-07-07)** : le leak se reproduit UNIQUEMENT quand DEUX conditions coïncident — (a) le jeu de lecture porte encore le doc PROTECTED de A au travers du switch (pas de reset), ET (b) le registre de caps en mémoire ne gouverne pas ce doc (`resetCaps()` déjà tiré / caps vides pour un doc persisté d'une session antérieure au reload). Alors la participation de A traverse la lecture union de B (le filtre par-document n'a aucun cap à vérifier). Avec le reset ci-dessus tiré, `setProtectedDocs([])` retire le doc de A du jeu de lecture de B AVANT que la lecture cap-less ne l'expose → plus de fuite quel que soit l'état des caps. **Régression gardée** par le scénario `@data` « Une identité fraîche ne voit pas la participation d'une autre » (event/isolation-deux-identites.feature) : A crée E + s'y inscrit, B (page fraîche sur le même wallet, identifiant distinct) n'a NI E sur son accueil (`getUserEvents(B)`), NI `isParticipating(E,B)`, ET ne lit AUCUNE participation portant le principal de A. Le symptôme historique « B voit “Je participe” » survenait surtout quand B **réutilisait un identifiant déjà employé par A** (même principal normalisé) sur un wallet **bloaté** (docs persistés d'un run antérieur, caps vides).
+
+## Instrumentation `useShapeQuery` — spinner global + timing
+
+`useShapeQuery` (binding `useSyncExternalStore` sur `watchShape`) instrumente **chaque cycle de requête** : au début d'un cycle il s'enregistre dans un store module-level `src/shared/data/pendingQueries.ts` (`beginQuery`/`resolveQuery`, Set d'ids — idempotent, sûr sous StrictMode), et à la 1re transition `isPending → isSuccess|isError` (le « premier résultat », équivalent readPromise) il se résout ET logge le délai : `[FestipodData] <shape>/<scope> premier résultat en <N>ms (n=<len>)` (le délai des événements Event/public est donc visible nommément). Le `cycleId` est mémoïsé sur `[shapeKey, scope]` → un switch d'identité/scope recrée l'observable ET un nouveau cycle (re-`beginQuery`), et le cleanup résout au démontage (jamais bloqué). Le hook `usePendingQueries()` expose le nombre de requêtes en attente ; `HomeScreen` affiche un `Spinner` (sketchy, `.app-spinner` + `@keyframes app-spin` dans `index.css`) à côté du titre « Festipod » tant que le compte > 0 → il ne s'arrête que quand **toutes** les requêtes en cours ont reçu leur premier résultat. Toute future `useShapeQuery` y contribue automatiquement. La mesure vit côté app (délai perçu React), **pas** dans le polyfill.
+
+## Mutations no-op en mode local
+
+En mode local/demo (`useLocalData`), `createEvent`/`joinEvent`/`leaveEvent`/`updateEvent` sont des **no-ops** (`console.log`, l'état ne change pas) — mais les écrans affichent quand même un **toast de succès** (« Tu participes »). UX potentiellement trompeuse : l'utilisateur croit s'être inscrit alors que rien n'a changé. Voir [[knowledge_data-modes]] pour le choix du provider selon le statut.

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

@@ -0,0 +1,28 @@
+---
+type: knowledge
+summary: Deux modes (connected = SDK @ng-eventually/client, disconnected/demo = état local seedé) ; FestipodDataContext choisit le provider selon le statut de connexion, tous les écrans passent par useFestipodData()
+---
+
+# Modes de données & contextes
+
+L'app a **deux modes**, tous deux consommés via le hook `useFestipodData()` :
+
+1. **Connected** — shapes ORM du SDK `@ng-eventually/client` (P2P, chiffré, local-first)
+2. **Disconnected / Demo** — état React local seedé depuis `seedData.ts` (voir [[knowledge_seed-data]])
+
+## NextGraphContext (`src/shared/context/NextGraphContext.tsx`)
+
+- Cycle de connexion : `disconnected` → `connecting` → `connected` | `error`.
+- Fournit la session (l'utilisateur courant et son accès aux stores par scope).
+
+## FestipodDataContext (`src/shared/context/FestipodDataContext.tsx`)
+
+- Enveloppe les shapes via `useShapeWithDefaults()`.
+- Expose `useFestipodData()` (consommé par tous les écrans) + CRUD (`createEvent`, `updateEvent`, `joinEvent`, `leaveEvent`, etc.).
+- **Provider selon le statut de connexion** :
+  - `disconnected` → `LocalDataProvider` avec seed (démo)
+  - `connecting` → `LocalDataProvider` **vide** (évite de flasher le seed avant le chargement du wallet)
+  - `connected` → `NgDataProvider` (données réelles du wallet)
+  - `error` → `LocalDataProvider` avec seed (fallback gracieux)
+
+> Les mutations sont **réellement persistées** en mode connected (`joinEvent` écrit une Participation et notifie l'hôte du PdR, `leaveEvent` supprime de façon autoritative — cf. [[caveat_participation-deletion]]). En mode local/demo elles sont des no-ops (cf. [[knowledge_context-internals]]).

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

@@ -0,0 +1,24 @@
+---
+type: knowledge
+summary: Types de données Fp* — Event, UserProfile, Participation, MeetingPoint et Notification sont persistés NextGraph (shapes SHEX + ORM) ; seul Friendship reste local-only (app-TS)
+last_checked: 2026-07-03
+---
+
+# Entités de données
+
+`src/shared/data/types.ts` :
+
+| Type | Persistance | Champs clés |
+|---|---|---|
+| `FpEventData` | SDK (shape Event) | id, title, date, location, distance, themes |
+| `FpUserData` | SDK (shape UserProfile) | id, name, username, bio, city, counts |
+| `FpParticipationData` | SDK (shape Participation) | eventId + userId + confirmed |
+| `FpMeetingPointData` | SDK (shape MeetingPoint) | eventId, location, time, host |
+| `FpNotificationData` | SDK (shape Notification) | kind, target, source |
+| `FpFriendshipData` | **local-only** | userId + friendId |
+
+`MeetingPoint` et `Notification` ont de vraies **shapes SHEX** (`src/shared/shapes/shex/festipodShapes.shex`) avec bindings ORM générés (`festipodShapes.shapeTypes.ts` : `FpMeetingPointShapeType`, `FpNotificationShapeType`) et **sont persistés**. `Notification` est notamment créée lors de l'inscription à un point de rencontre (`joinEvent`).
+
+`Friendship` n'a **pas** de shape SHEX ni de persistance — il reste app-TS-only (cf. [[knowledge_nextgraph-stack]]).
+
+> Piège : même pour `FpEvent` (persisté), plusieurs champs du type app ne sont **pas** dans la shape et sont perdus en connecté — voir [[caveat_event-fields-not-persisted]].

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

@@ -0,0 +1,34 @@
+---
+type: knowledge
+summary: Le SDK de données est @ng-eventually/client (traité comme un SDK NextGraph fini) — injecté une seule fois via ngSession.configure ; ORM réactif useShape sur shapes SHEX festipodShapes, bindings régénérés via build:orm ; ne jamais documenter l'état courant de NextGraph ici
+---
+
+# Stack de données (SDK `@ng-eventually/client`)
+
+Festipod persiste via **`@ng-eventually/client`** — le SDK NextGraph que l'app consomme. On le traite comme un **SDK fini et mature** : documents par entité placés par scope, capabilities, inboxes, ORM réactif.
+
+```
+@ng-eventually/client   # LE SDK de données de l'app (ORM réactif useShape, docs, scopes, inbox)
+```
+
+## Frontière SDK (règle d'or)
+
+- L'app **ne dépend que de `@ng-eventually/client`** pour la donnée.
+- Le SDK est **initialisé/injecté une seule fois** via `ngSession.configure(...)` (`src/shared/utils/ngSession.ts`) — point d'injection unique. Le reste de l'app (data-plane, lifecycle, login, types) passe par la lib.
+- **Ne jamais documenter dans ce repo l'état courant de NextGraph** (contraintes du SDK sous-jacent, contournements, internes broker/verifier) : cela vit dans le repo `@ng-eventually/client`. Ici on décrit seulement **comment Festipod utilise ce SDK**.
+
+## ORM & shapes SHEX
+
+L'ORM réactif (`useShape`) s'appuie sur des **shapes SHEX** : `src/shared/shapes/shex/festipodShapes.shex` définit :
+
+- **Event** — titre, description, dates, lieu, thèmes, participants
+- **UserProfile** — nom, username, bio, ville, visibilité
+- **Participation** — lie event + user, statut de confirmation
+- **MeetingPoint** — point de rencontre (lieu, horaire, hôte)
+- **Notification** — notification (créée notamment à l'inscription à un PdR)
+
+Bindings ORM générés dans `src/shared/shapes/orm/` (`*.schema.ts`, `*.shapeTypes.ts`, `*.typings.ts`). **Régénérer** avec `bun run build:orm` après toute modif `.shex`.
+
+> **Lecture recommandée = le hook réactif du SDK.** La façon canonique de lire, c'est `useShape` : on s'abonne à une shape sur un scope, on obtient la valeur courante, et le composant se re-rend à chaque changement (local **ou** distant synchronisé) — abonnement/push, jamais de polling ; les lectures one-shot sont l'exception. La référence complète du SDK (contrat de lecture/réactivité + où l'émulation courante diverge encore) vit côté lib : `packages/client/docs/sdk-reference.md` dans `@ng-eventually/client`. Ne pas recopier les internes NextGraph ici.
+
+> `Friendship` n'a **pas** de shape SHEX ni de persistance — il reste app-TS-only (cf. [[knowledge_entities]]).

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

@@ -0,0 +1,17 @@
+---
+type: knowledge
+summary: seedData.ts fournit des fixtures déterministes (10 users, events, participations) avec CURRENT_USER_ID = 'user-1' (Marie Dupont) ; utilisé en mode démo et par les tests @ui
+---
+
+# Seed data
+
+`src/shared/data/seedData.ts` fournit des fixtures **déterministes** :
+
+- 10 users — **Marie Dupont = utilisateur courant**, `user-1`
+- Plusieurs events (dates, lieux, thèmes)
+- Participations, meeting points, friendships
+- `CURRENT_USER_ID = 'user-1'`
+
+Ces fixtures servent (a) le **mode démo** (`LocalDataProvider`, cf. [[knowledge_data-modes]]) et (b) les tests **`@ui`** qui rendent les écrans avec ces données prévisibles (`Marie Dupont`/`@mariedupont` = currentUser, `Jean Durand`/`@jeandurand` existe, etc. — voir concept `bdd-testing`).
+
+> `bootstrapWallet()` (`src/shared/utils/ngBootstrap.ts`) seede ces données dans le wallet en mode connected — déclenché uniquement par action explicite de l'utilisateur (« Charger données de test »).

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

@@ -0,0 +1,53 @@
+---
+type: rule
+summary: L'app se comporte EXACTEMENT comme si NextGraph était fini et sans défaut — elle ne consomme QUE des surfaces SDK-shaped (`useShape`, `docs`, `inbox`…) et ne raisonne JAMAIS sur un problème courant de NextGraph (hang du fan-out ORM, cold-open, etc.). La raison d'être du polyfill est le WALLET VIRTUEL ; tout contournement interne (read-model union, subscribeDoc, open-repo…) vit DANS le polyfill, invisible à l'app.
+---
+
+# L'app n'utilise que la surface SDK — jamais les internes du polyfill
+
+## La règle
+
+L'app Festipod traite `@ng-eventually/client` comme un **SDK NextGraph fini et sans
+défaut**. Concrètement :
+
+1. **Lecture réactive = `useShape`** (la surface SDK-shaped, fournie par le polyfill,
+   **scopée au wallet virtuel**). L'app ne lit PAS via des internes du polyfill
+   (`readModel.readUnion`, `subscribeDoc`, un read-model maison…), et ne monte PAS sa
+   propre réactivité (re-run sur signal).
+2. **L'app ne raisonne JAMAIS sur l'état courant de NextGraph** : pas de code ni de
+   commentaire du type « on fait X parce que le fan-out ORM hang / parce que la lecture
+   à froid rend 0 ». Ces problèmes n'existent pas du point de vue de l'app.
+
+## La raison d'être du polyfill = le WALLET VIRTUEL
+
+Le polyfill existe pour émuler le **wallet virtuel** (plusieurs identités sur un seul
+wallet physique), que NextGraph ne fournit pas encore nativement. **Ce n'est PAS**
+« parce que le fan-out ORM hang » — ça, c'est un simple **détail d'implémentation
+interne** de la façon dont le polyfill livre un `useShape` fonctionnel. Tous les
+contournements (read-model union à la place du fan-out ORM, `open-repo`, readiness
+miroir de `readyPromise`, émulation de caps…) sont **internes au polyfill** et
+n'apparaissent jamais dans l'app.
+
+## État (déviation résolue)
+
+**Résolu** : `FestipodDataContext` lit désormais via `useShapeQuery` (binding
+`useSyncExternalStore` sur `watchShape` du polyfill) + adaptateurs Fp
+(`src/shared/data/shapeAdapters.ts`). Sont **supprimés** : `readEntities.ts`, la
+réactivité bespoke (`subscribeDocs`+`bumpRead`+`readTick`), le listing manuel
+(`publicDocs`/`protectedDocs`/`registerDoc` pour la lecture), et les commentaires
+raisonnant sur le hang ORM. L'auto-seed est gardé sur `isSuccess` (plus de
+chronomètre 3 s). L'app ne consomme plus que la surface SDK.
+
+**Cible (rappel du design)** : le polyfill expose un `useShape` **réactif, scopé au wallet virtuel**, dont
+la **forme suit TanStack `useQuery`** — `{ data, isPending/isLoading, isSuccess, isError,
+… }` — **en anticipation de la mise à jour PRÉVUE de `useShape` par NextGraph** (qui va
+adopter ce fonctionnement). Ce n'est donc pas une invention : c'est une API future de
+NextGraph, émulée d'avance, qui s'aligne quand NextGraph la livre. Elle **distingue
+nativement** `isPending` (sync en cours) de `isSuccess` + `data` vide (synchronisé,
+réellement vide) — exactement le besoin. En interne, le hook encapsule readUnion sur
+`subscribeDoc` + le scoping identité (invisible à l'app). L'app **supprime** sa
+machinerie bespoke (`readEntities`/`subscribeDocs`/`bumpRead`) et lit via ce hook.
+
+Le bug d'auto-seed (chronomètre 3 s) est un **symptôme** : avec `isSuccess`, l'auto-seed
+décide « vide » seulement une fois la sync confirmée, au lieu de deviner un délai. Voir
+[[rule_no-broker-polling]] et [[knowledge_nextgraph-stack]].

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

@@ -0,0 +1,112 @@
+---
+type: rule
+summary: Festipod persiste CHAQUE entité comme SON PROPRE document (via le SDK), placé dans son scope (public/protected/private) — jamais plusieurs entités écrites dans un document de niveau store. Le document est l'unité de partage et de droits : l'isolation du SDK est PAR-DOCUMENT, donc un document par entité est ce qui la rend possible.
+---
+
+# Règle : un document par entité (jamais au niveau du store)
+
+Quand Festipod crée une entité (événement, point de rencontre, profil, participation,
+notification), il l'écrit comme **son propre document**, via l'appel « créer un document » du
+SDK de données ([[knowledge_nextgraph-stack]]), en indiquant son **scope**
+(`public` / `protected` / `private`). L'entité est ensuite lue et écrite dans **ce** document.
+
+**Ne jamais** écrire plusieurs entités dans un document partagé « de niveau store » (p. ex.
+tout mettre dans un seul document racine). C'est un anti-pattern qui casse l'isolation.
+
+## Pourquoi
+
+Le **document est l'unité de partage et de droits** du SDK : l'isolation (qui peut lire quoi)
+est appliquée **par document**. `private` → le propriétaire ; `protected` → le propriétaire +
+ses connexions ; `public` → tout le monde. Cette discrimination n'est possible **que si chaque
+entité a son propre document** : mettre plusieurs entités (voire plusieurs propriétaires) dans
+un même document rend le partage tout-ou-rien et défait l'isolation par périmètre.
+
+L'isolation elle-même est **entièrement assurée par le SDK** ([[knowledge_trust-model]] du
+concept `app-security`) — l'app ne porte aucune logique d'accès ; elle déclare seulement son
+identité (au login) et ses connexions (acte de partage), puis fait confiance à ce que le SDK
+renvoie. La granularité « un document par entité » est la contrepartie côté écriture de cette
+confiance.
+
+## Comment l'appliquer
+
+- À la création : demander au SDK **un document pour l'entité, dans son scope**
+  (`createEntityDoc(scope)`) ; y écrire l'entité. Ne pas réutiliser un document d'un autre
+  périmètre ni un document de niveau store.
+- En lecture : passer par le SDK via le **modèle de lecture union** (voir plus bas) — l'app
+  résout un jeu de documents *par besoin* (index de découverte pour les événements publics ;
+  ses propres documents de scope pour ses entités) et le SDK ouvre/synchronise puis lit
+  l'union en **une seule** requête ; pas de résolution de NURI ni de choix union/ancré côté app.
+- Le mapping *entité → scope* (événement/PdR → public, profil réseau/participation → protected,
+  settings → private) est un fait produit (concept `functional-domain`,
+  [[knowledge_data-scopes-and-discovery]]).
+
+## Lecture : modèle union (open/sync + une requête ancrée-libre + re-query)
+
+La **lecture** ne passe **PAS** par un abonnement ORM réactif en fan-out sur un jeu de documents
+par-entité (`useShape({ graphs: […] })`) : contre le vrai broker un document fraîchement créé /
+non-synchronisé dans ce fan-out fait avorter tout l'abonnement (`RepoNotFound`) → l'abonnement
+n'émet jamais son initial → **hang ~75 s**. À la place, la lecture est le **modèle union** du SDK
+([[knowledge_nextgraph-stack]], SDK `docs/read-model.md`) :
+
+1. **résoudre par besoin** le jeu de NURIs à lire — événements publics via l'**index de découverte**
+   (la seule énumération cross-comptes sanctionnée) ; « mes entités » (profil, participations) via
+   **mes propres** documents de scope (`listMyEntityDocs(username, scope)`, borné à mon compte —
+   jamais de fan-out sur tous les comptes) ;
+2. le SDK **ouvre/synchronise** ces documents puis exécute **UNE** requête `sparql_query`
+   **sans ancre** sur l'union locale (`GRAPH ?g { … }`) et rend les triplets groupés par sujet
+   (`src/shared/data/readEntities.ts` → `readModel.readUnion`) ;
+3. il n'y a **pas** de requête union réactive → la **réactivité = re-query** sur un signal de
+   changement (un document créé/enregistré déclenche `bumpRead`).
+
+Côté app, `FestipodDataContext` collecte les NURIs par besoin puis appelle `readEntities` ;
+un document fraîchement créé est aussi enregistré localement (`registerDoc`) pour apparaître
+immédiatement, avant que la re-liste ne le rattrape.
+
+## Écriture directe (piège d'aller-retour)
+
+L'**écriture** d'une entité se fait **directement dans son propre document** (via l'appel
+SPARQL du SDK — `src/shared/data/entityWrites.ts`, `writeEntity`), **pas** via l'ajout à un
+ensemble réactif. Raison : un ensemble réactif n'est *inscriptible* que si le document cible est
+**déjà** dans son scope d'abonnement ; or enregistrer le document fraîchement créé est un état
+React qui ne prend effet qu'au rendu **suivant** → on ne peut pas créer-puis-ajouter en une passe
+synchrone (boucle de seed, première création). Contre le vrai broker, un `add` sur un scope vide
+lève « Set is readonly because scope is empty » (les tests unitaires fake-ng ne l'attrapent pas).
+
+Donc : **écriture = SPARQL direct dans le doc de l'entité** (immédiat, par-document) ;
+**lecture = union + re-query** (ci-dessus).
+
+**Convention de graphe (écrire dans le graphe par défaut ancré).** L'écriture passe le NURI du
+document comme **ancre** de `docs.sparqlUpdate` et écrit le corps SPARQL **sans** clause
+`GRAPH <…>` explicite ; la lecture union interroge le même graphe par défaut ancré
+(`readEntities`/`readUnion`). C'est la forme **canonique et toujours sûre** — à conserver pour
+`writeEntity`, `updateEntityField` et `registration.ts`.
+
+> **Correction (2026-07-06).** Un commentaire antérieur (et une version de ce paragraphe)
+> affirmaient qu'un corps `GRAPH <nuriDuDoc>` explicite écrit dans un graphe *nommé distinct* que
+> la lecture ancrée ne verrait pas → l'entité « disparaîtrait ». **C'est faux sur le broker
+> courant** (`@ng-org/web 0.1.2-alpha.13`) : le harness e2e réel de la lib
+> (`packages/client/e2e/`) vérifie qu'un `INSERT DATA { GRAPH <plainNuri> {…} }` **ancré** au doc
+> round-trippe (relu aussi bien en graphe par défaut qu'en `GRAPH <plainNuri>`). Le symptôme « 0
+> entité » qu'on avait attribué à ce « piège » venait en réalité du **hang de wallet gonflé** (cf.
+> `bdd-testing/caveat_wallet-bloat-hang`), pas d'un mismatch de graphe. La règle « sans wrapper
+> `GRAPH` » reste donc un choix de **simplicité/sûreté**, pas une nécessité de round-trip. (Le
+> *pourquoi* côté SDK vit dans `@ng-eventually/client`, pas ici.)
+
+Idem pour la **mutation d'un champ** existant (p. ex. `participantCount`) : muter une valeur
+en mémoire ne tient pas — la re-query union relit la valeur **persistée** depuis le broker
+(retour à l'ancienne valeur) → persister via SPARQL (`updateEntityField` : DELETE puis
+INSERT du triplet) pour que le changement tienne et que la relecture concorde. Chaque champ est écrit avec le **bon terme RDF** selon la shape SHEX (xsd:integer /
+float / boolean, ou IRI pour les références `Participation.event`/`.user`) — un champ obligatoire
+manquant ou mal typé fait que la lecture **jette l'entité** (elle ne fait jamais
+l'aller-retour). Le **sujet** de l'entité = le **NURI de son document** (une entité = un document),
+ce qui donne un `@id` en `did:ng:…`.
+
+Corollaire d'identité : une `Participation` porte un `fp:user` **obligatoire** — ne jamais
+l'écrire avec un principal vide (l'entité serait jetée en lecture). Le principal du user courant
+est **stable et dérivé du username** (`urn:festipod:user:<username-normalisé>`), disponible
+**immédiatement** après login (pas de dépendance à la lecture du profil protégé, qui peut
+retarder) et **invariant** (il ne bascule pas d'un fallback vers l'IRI de profil en cours de
+session, ce qui désynchroniserait une participation écrite sous une valeur d'une vérification
+sous l'autre). C'est le même principal que l'identité SDK (`setCurrentUser`) et le cap owner
+dérivent du username ; les connexions bilatérales (`declareConnections`) se déclarent avec ces
+mêmes clés username (pas des IRIs de profil) pour que « protégé = mes connexions » discrimine.

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

@@ -0,0 +1,10 @@
+# Doc-debt — functional-domain
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Raw markers (consolidate into blocks, then delete)
+- TOUCHED src/modules/event/features/reconnexion-persistance-e2e.feature @2026-07-13 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-socket-mort.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-meme-identite.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)
+- TOUCHED src/modules/event/features/reconnexion-froide-sans-local.feature @2026-07-14 (session 0b064e8b-1717-421f-a20e-a4318ad217b1)

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

@@ -0,0 +1,29 @@
+---
+type: _overview
+summary: Modèle produit Festipod — le point de rencontre greffé sur un événement public comme unité de valeur, ses acteurs, ses concepts métier, et les périmètres de confidentialité (public/protected/private) par entité
+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
+
+Le **domaine fonctionnel** de Festipod : ce que le produit promet et le vocabulaire métier qui le décrit. Source d'origine : `README.md §Modèle fonctionnel`.
+
+**À lire en premier :** [[knowledge_business-model]] — sans lui, on confond l'événement (l'ancrage) et le point de rencontre (la valeur), et on modélise à l'envers.
+
+## Idée pivot
+
+Festipod laisse les utilisateurs créer des **points de rencontre** qui se *greffent* sur des **événements publics** existants. L'événement (festival, conférence…) n'est qu'un *prétexte* et un point d'ancrage spatio-temporel ; la valeur produite, c'est le point de rencontre. **On s'inscrit à un point de rencontre, jamais à un événement.**
+
+## Périmètre & confidentialité
+
+Le modèle produit de **qui voit quoi** — données personnelles réservées au réseau, événements/PdR publics, notification d'inscription identifiée-ou-anonyme — est un fait métier : voir [[knowledge_data-scopes-and-discovery]]. La matrice d'autorisations détaillée (acteur × verbe) et son incubation vivent dans le concept `app-security` ([[brief_2026-05-18_authorization-matrix]]).
+
+## Liens
+
+- [[knowledge_business-model]] — l'inversion événement / point de rencontre
+- [[knowledge_actors-and-concepts]] — référence des acteurs et concepts métier
+- [[knowledge_data-scopes-and-discovery]] — périmètres public/protected/private par entité + découverte
+- [[knowledge_roadmap]] — fonctionnalités actuelles vs évolutions à venir
+- [[brief_2026-06-15_event-deduplication]] — défi ouvert de déduplication des événements en P2P

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

@@ -0,0 +1,23 @@
+---
+type: brief
+summary: Défi ouvert — en infra P2P, deux utilisateurs peuvent déclarer le même événement public et fragmenter les points de rencontre greffés ; pistes non tranchées
+---
+
+# Déduplication des événements en infra décentralisée
+
+**Status:** Défi ouvert — non tranché
+**Capturé:** 2026-06-15 (issu de `README.md §Défis ouverts`)
+
+## Problème
+
+NextGraph étant P2P, rien n'empêche deux utilisateurs de **déclarer indépendamment le même événement public** (par ex. « Eurockéennes 2027 ») et de produire deux entrées distinctes. La dispersion qui en résulte **fragmente les points de rencontre greffés** et réduit leur visibilité — ce qui va à l'encontre de la fonction première de l'app (cf. [[knowledge_business-model]]).
+
+## Pistes envisagées (non tranchées)
+
+- **Recherche avant création** — proposer à l'utilisateur, lors de la déclaration, les événements déjà déclarés dans son réseau / ses communautés qui correspondent à sa saisie.
+- **Identifiant externe canonique** — utiliser une URL officielle de l'événement, Wikidata, ou `schema.org/Event` pour reconnaître les doublons et les présenter comme un seul événement à l'affichage.
+- **Curation** — laisser des curators (humains ou communautaires) fusionner / vetter les entrées canoniques.
+
+## Lien avec le modèle d'écriture
+
+Ce défi est couplé à une question ouverte de [[brief_2026-05-18_authorization-matrix]] : **qui peut modifier un événement déclaré** (propriétaire / wiki / immuable). Un modèle *wiki* faciliterait la convergence ; un modèle *propriétaire* la complique. À arbitrer ensemble.

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

@@ -0,0 +1,31 @@
+---
+type: knowledge
+summary: Référence des acteurs (utilisateur, connexion, déclarant, hôte, inscrit, membre) et des concepts métier (point de rencontre, événement, communauté, liste curated, connexion)
+---
+
+# Acteurs et concepts métier
+
+Référence du vocabulaire. Tous les acteurs sont des spécialisations d'un **utilisateur** authentifié dans un contexte donné — pas des rôles de compte distincts.
+
+## Acteurs
+
+| Acteur | Définition |
+|---|---|
+| **Utilisateur** | Toute personne ayant un compte (un wallet NextGraph). Racine de tous les autres. |
+| **Connexion (« ami »)** | Un autre utilisateur avec qui je suis connecté. Sert à scoper les listes (« mes amis qui participent à… ») et la confiance. Bilatérale (acceptation des deux côtés). |
+| **Déclarant d'un événement** | L'utilisateur qui a inséré l'événement dans Festipod. *N'est pas forcément l'organisateur réel* : juste celui qui le référence. **Il n'y a PAS de notion d'« hôte d'événement »** : l'événement est public, simplement signalé par son déclarant, qui **n'est PAS obligé de participer** — à la création aucune participation n'est écrite, le compteur démarre à 0, et le déclarant peut rejoindre/quitter comme tout le monde (décision produit ; côté données cf. data-layer/[[knowledge_context-internals]] §participantCount). L'« hôte » reste un acteur au niveau du **point de rencontre** (ligne suivante), pas de l'événement. |
+| **Hôte d'un point de rencontre** | L'utilisateur qui a créé un point de rencontre rattaché à un événement. |
+| **Inscrit à un point de rencontre** | Un utilisateur inscrit à un point de rencontre ; de fait il devient participant à l'événement parent. |
+| **Membre d'une communauté d'intérêt** | Un utilisateur abonné à une communauté pour découvrir les événements qu'elle référence. |
+
+## Concepts métier
+
+| Concept | Définition |
+|---|---|
+| **Point de rencontre** | *L'unité de valeur de l'app.* Un moment de rencontre proposé par un hôte à un endroit et un horaire donnés, greffé sur un événement public. C'est ce à quoi on s'inscrit. |
+| **Événement** | L'ancrage. Un événement public réel référencé dans Festipod pour servir de support à des points de rencontre. Simple prétexte (titre, dates, lieu, thèmes). |
+| **Communauté d'intérêt** | Un groupement thématique d'utilisateurs. Sert surtout à découvrir des événements (via abonnement) et à délimiter les périmètres de référencement. |
+| **Liste curated** | Une liste d'événements éditorialisée (par un utilisateur ou une communauté), distincte de « les événements que j'ai déclarés ». Permet d'organiser/recommander. |
+| **Connexion** | Lien de confiance bilatéral entre deux utilisateurs (équivalent « ami »). |
+
+> Communauté, liste curated et abonnement sont en grande partie **prospectifs** (cf. [[knowledge_roadmap]]). La matrice d'autorisations détaillée par type de donnée vit dans [[brief_2026-05-18_authorization-matrix]].

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

@@ -0,0 +1,26 @@
+---
+type: knowledge
+summary: Le point de rencontre est l'unité de valeur, greffée sur un événement-prétexte ; on s'inscrit au point de rencontre, pas à l'événement
+---
+
+# Modèle métier : le point de rencontre greffé
+
+> Festipod permet aux utilisateurs de créer des **points de rencontre** qui viennent se « greffer » sur des **événements publics existants**. L'objectif : favoriser les rencontres autour de ces événements.
+
+## L'inversion à comprendre
+
+L'**événement public** (festival, conférence, salon, exposition…) n'est **qu'un prétexte** et un *point d'ancrage temporel et géographique*. La valeur produite par l'app, c'est le **point de rencontre** que les utilisateurs viennent y greffer pour se retrouver.
+
+Conséquences directes sur la modélisation :
+
+- **On s'inscrit à un point de rencontre, pas à un événement.** Sans points de rencontre, un événement Festipod n'a aucun intérêt.
+- Le **déclarant** d'un événement n'est *pas* (forcément) son organisateur réel — c'est juste quelqu'un qui a inséré la référence dans Festipod pour que d'autres puissent y attacher des points de rencontre.
+- L'**hôte** d'un point de rencontre est celui qui l'a créé ; l'acte de créer rend hôte. De même l'acte de déclarer un événement rend déclarant.
+
+## Authentification
+
+**Tous les utilisateurs sont authentifiés** (chacun possède un wallet NextGraph) — il n'y a pas d'accès anonyme à l'app. Les différents « acteurs » (déclarant, hôte, inscrit, connexion…) sont des *spécialisations d'un utilisateur dans un contexte donné*, pas des comptes distincts. Voir [[knowledge_actors-and-concepts]].
+
+## Stack porteuse
+
+App web mobile-first, Bun + React + **NextGraph** (P2P, local-first, chiffré de bout en bout). Le choix P2P a une conséquence métier forte : voir le défi de [[brief_2026-06-15_event-deduplication]].

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

@@ -0,0 +1,44 @@
+---
+type: knowledge
+summary: Modèle produit de confidentialité et de découverte — chaque entité vit dans un SCOPE (public / protected / private) selon qui doit la voir ; événements & points de rencontre = public, profil réseau & participations = protected (réseau), settings = private ; connexions bilatérales = scope dialog ; la découverte lit un index global d'événements
+---
+
+# Périmètres de données et découverte
+
+Le modèle **produit** de qui voit quoi, et comment on trouve les événements. C'est du **domaine** : le *comment* technique (documents, capabilities, index) est assuré par le SDK de données `@ng-eventually/client` — l'app décrit seulement **l'intention métier**.
+
+## Trois périmètres (scopes) par donnée
+
+Chaque entité est stockée dans le **scope** correspondant à qui doit pouvoir la lire :
+
+| Entité | Scope | Qui lit |
+|---|---|---|
+| Événement (l'ancrage) | **public** | tout le monde |
+| Point de rencontre (PdR) | **public** | tout le monde |
+| Profil réseau (nom, avatar, bio, ville, intérêts) | **protected** | le titulaire + ses connexions |
+| Participation / inscription à un PdR | **protected** | l'inscrit + ses connexions |
+| Index des connexions | **protected** | le titulaire + ses connexions |
+| Profil privé (settings, email, préférences) | **private** | le titulaire seul |
+| Connexion A↔B (lien bilatéral, + messagerie future) | **dialog** | les deux utilisateurs |
+
+Principe directeur : **le statut « public » (PdR, événement) et « personnel » (profil, participations, connexions) coexistent dans un même utilisateur.** Les informations personnelles sont réservées au **réseau** (connexions bilatérales), jamais visibles d'un utilisateur lambda.
+
+- **PdR / événement = publics universels.** Tout utilisateur peut lire et s'abonner ; créer un PdR rend hôte, créer un événement rend déclarant (aucun prérequis).
+- **Hôte = seul détenteur des droits d'écriture** sur son PdR ; le déclarant n'a aucun droit particulier sur les PdR greffés sur son événement.
+- **Connexion bilatérale** : `DemandeDeConnexion` (unilatérale, transitoire) → `Connexion` (bilatérale, persistante) — cette dernière ouvre l'accès aux données *protected* de l'autre.
+
+Festipod **place chaque entité dans le store de son scope** ; l'isolation entre scopes est **assurée par le SDK de données**, pas par du code applicatif (cf. concept `app-security`).
+
+## Découverte des événements
+
+Un utilisateur découvre les événements qu'il n'a pas créés via un **index global** : le SDK lit cet index, qui donne les références (NURIs) des documents-événements, puis synchronise et interroge en local. La découverte **primaire** passe par cet index ; un **axe secondaire** relationnel s'y superpose (les participations *protected* des connexions : « mes amis participent à… »).
+
+> **Notification d'inscription (intention produit).** S'inscrire à un PdR notifie son hôte : identifié si l'inscrit fait partie des connexions de l'hôte, **anonyme sinon**. Ce « identifié si connu, anonyme sinon » est une propriété du modèle de données — l'app y compte, le mécanisme est fourni par le SDK.
+
+## Questions ouvertes (métier)
+
+- **Modèle d'écriture de l'événement** : propriétaire (déclarant seul) / wiki (tous) / immuable ? Central pour la déduplication ([[brief_2026-06-15_event-deduplication]]).
+- **Identité de l'hôte vis-à-vis d'un lambda** : un PdR est lisible par tous, mais faut-il que son hôte soit identifiable ? (pseudonyme par défaut, carte de visite par PdR, ou anonymat révélé aux seules connexions.)
+- **Champs modifiables d'une inscription** ; **découvrabilité « amis d'amis »**.
+
+> La matrice d'autorisations détaillée par acteur × verbe vit dans le concept `app-security` ([[brief_2026-05-18_authorization-matrix]]).

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

@@ -0,0 +1,25 @@
+---
+type: knowledge
+summary: Ce qui est implémenté aujourd'hui (cycle événement + point de rencontre, profils, connexions) vs les évolutions identifiées mais non faites (communautés, abonnements, listes curated, multi-user)
+---
+
+# Fonctionnalités actuelles vs évolutions à venir
+
+## Implémenté (é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
+
+> L'inscription/désinscription au point de rencontre est **réellement branchée** côté données : `joinEvent` persiste une Participation, notifie l'hôte du PdR et crée une Notification ; `leaveEvent` supprime la Participation de façon autoritative (cf. concept `data-layer`, [[caveat_participation-deletion]] côté data-layer). La découverte publique — un utilisateur voit un événement public d'un autre — fonctionne aussi.
+
+## Évolutions identifiées (non implémentées)
+
+- **Abonnement à une communauté d'intérêt** pour découvrir ses événements (discovery distribué).
+- **Abonnement à un utilisateur** pour suivre ses déclarations sans être ami.
+- **Listes curated** — créer/partager des sélections éditorialisées.
+- **Multi-utilisateurs collaboratif** : le partage effectif d'un point de rencontre vu par plusieurs utilisateurs, appuyé sur les périmètres public/protected/private (cf. [[knowledge_data-scopes-and-discovery]]).

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

@@ -0,0 +1,21 @@
+---
+type: _overview
+summary: Stack et outillage — Bun-first (runtime, bundler, APIs natives), build pipeline, et commandes du projet
+triggers:
+  keywords: [bun, bunx, build, bundler, vite, webpack, jest, npm, storybook, "bun.serve", hmr, tailwind, package.json]
+  paths: ["build.ts", "package.json", "bunfig.toml", "tsconfig.json", "src/index.ts", "src/index.html", ".storybook/**", "scripts/**"]
+---
+
+# Tech stack
+
+Stack et outillage du projet. Principe directeur : **Bun-first** — Bun remplace Node/npm/vite/webpack/jest et fournit les APIs serveur natives.
+
+**À lire en premier :** [[rule_bun-first]] — la convention qui décide quel outil utiliser.
+
+## Liens
+
+- [[rule_bun-first]] — utiliser Bun, pas Node/npm/vite/jest/express/ws/pg…
+- [[knowledge_bun-apis]] — APIs natives Bun (serve, sqlite, redis, sql, file, shell)
+- [[knowledge_build-pipeline]] — build.ts, bundler, serveur, harness buildé à part, Storybook
+- [[knowledge_stack-and-commands]] — composants de la stack + scripts réels (+ quirks)
+- [[knowledge_deployment]] — Dockerfile, prod depuis src/, pas de CI, `portless` en dev

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

@@ -0,0 +1,41 @@
+---
+type: caveat
+summary: Firefox 151+ bloque (Local Network Access) le broker hébergé qui embarque l'app de dev locale dans son iframe → iframe blanche, zéro log app, aucune erreur. Ce n'est PAS un bug de code. Fix navigateur — about:config network.lna.enabled=false.
+last_checked: 2026-07-13
+---
+
+# Firefox LNA bloque l'iframe app du broker en dev local
+
+## Symptôme
+
+En dev local, l'app tourne DANS l'iframe du broker hébergé (`nextgraph.eu`/`nextgraph.net`
+en HTTPS embarque `festipod.localhost` → `127.0.0.1`). Sur **Firefox 151+**, l'iframe reste
+**blanche** : **aucun log `[FestipodData]`/`[NG]`** (l'app JS n'est jamais exécutée), et
+**aucune erreur** rouge (le blocage est une décision de politique réseau, pas un throw). Facile
+à prendre pour un crash de rendu Festipod — ce n'en est PAS un.
+
+## Cause
+
+**Local Network Access (LNA)** : Firefox 151+ (activé par défaut, cf. rollout 149→151) interdit
+à un **site public** (le broker HTTPS) d'atteindre une **ressource du réseau local**
+(`127.0.0.1`) — y compris l'embarquer en iframe. Le log révélateur (console) :
+`Local Network Access detected: ... accessing target "…festipod.localhost…" (127.0.0.1) … prompt action: auto_deny`.
+
+Deux corollaires qui trompent :
+- **Le top-level charge très bien** : ta navigation directe vers `https://festipod.localhost:1355`
+  (la barrière AccessGateScreen) n'est PAS soumise à LNA. Seul l'**embarquement iframe** par le
+  broker l'est. Donc « le cert est déjà accepté / l'app se lance » avant l'iframe ≠ l'iframe passera.
+- **HTTPS n'y change rien** : LNA vise l'**adresse locale cible**, pas le protocole. Passer
+  `portless proxy start --https` (app en `https://festipod.localhost`) ne débloque pas.
+
+## Fix (navigateur, pas code)
+
+`about:config` → **`network.lna.enabled` = `false`** (drapeau maître : désactive tous les
+contrôles LNA). Alternative ciblée : **`network.lna.skip-domains`** avec `nextgraph.eu`,
+`nextgraph.net` (garde la protection ailleurs). Autres prefs LNA : `network.lna.blocking`,
+`network.lna.block_trackers`.
+
+Ne PAS chasser un bug de rendu Festipod tant qu'il n'y a **aucun log `[FestipodData]`** dans la
+console : sans logs app, l'app n'a pas tourné → c'est l'environnement (LNA, cert non approuvé,
+serveur dev éteint), pas le code. Le smoke `@e2e` ne peut PAS attraper ça : Playwright n'applique
+pas LNA comme un vrai Firefox.

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

@@ -0,0 +1,37 @@
+---
+type: knowledge
+summary: Dev en bun --hot, build prod via build.ts (bundler Bun + plugin Tailwind) vers dist/, alias @/* → ./src/*
+---
+
+# Build pipeline
+
+- **Dev** : `bun --hot src/index.ts` (via `bun run dev`) — HMR, port 3000.
+- **Prod** : `bun run build` → `build.ts` (bundler Bun + plugin Tailwind) → `dist/`.
+- **Alias de chemin** : `@/* → ./src/*` (déclaré dans `tsconfig.json`).
+
+Le serveur sert `src/index.html`, qui charge `src/app/frontend.tsx` (voir `app-architecture` §app-shell). Le bundler transpile le TSX et bundle le CSS sans outil externe — pas de Vite/webpack/esbuild (cf. [[rule_bun-first]]).
+
+## Détails de `build.ts` et du serveur
+
+- `build.ts` scanne `src/**/*.html` comme entrypoints (aujourd'hui un seul : `src/index.html`), `target: 'browser'`, minify + sourcemap linked, plugin `bun-plugin-tailwind`. Ajouter un 2e `.html` créerait un 2e bundle.
+- `src/index.ts` (`Bun.serve`) sert : `/reports/cucumber` (rapport HTML), des stubs `/api/hello*`, `/festipod-config.json` + `/shared-wallet.ngw` (config runtime, voir ci-dessous), et un **catch-all `/*` → `src/index.html`** (routing SPA, doit rester en dernier). HMR si `NODE_ENV !== 'production'`, port via `PORT`.
+
+## Globals de build vs config runtime (piège du wallet partagé)
+
+`build.ts` injecte des **globals à la compilation** via `define` (p. ex. `__FESTIPOD_SHARED_WALLET_PASSWORD__` depuis `FESTIPOD_SHARED_WALLET_PASSWORD`, `__FESTIPOD_ACCESS_GATE_DISABLED__`, et `__FESTIPOD_AUTO_SEED__` depuis `FESTIPOD_AUTO_SEED` — l'auto-seed de dev, OFF si absent). **Piège** : le serveur `src/index.ts` (utilisé par `bun run dev` ET `bun run start`) bundle `index.html` via l'import HTML de Bun, qui **n'applique aucun `define`** — ni `bun --define` ni `process.env` ne s'y propagent (vérifié). Donc une variable d'env passée à `bun run dev` n'atteint pas le bundle frontend par ce chemin.
+
+Pour ces chemins servis depuis `src/`, la config passe donc au **runtime** : `src/index.ts` expose `/festipod-config.json` (lu depuis l'env), et l'entrée `src/app/frontend.tsx` la **fetch d'abord**, pose le global, **puis importe l'app dynamiquement** (`await import('./App')`) — ainsi `sharedWallet.ts` lit la valeur à son évaluation. Dans un bundle `build.ts` la valeur est déjà inline par `define`, donc le fetch est court-circuité (`NODE_ENV === 'production'`). Conséquence pratique : pour exercer le flux « portefeuille partagé » en dev **de bout en bout** (téléchargement + import qui fonctionne), passer le VRAI mot de passe du wallet e2e **et** le fichier — le mot de passe affiché à l'écran doit correspondre au `.ngw` importé, sinon l'import échoue (une valeur factice comme `1` fait juste apparaître l'écran) :
+
+```
+FESTIPOD_SHARED_WALLET_PASSWORD=festipod-e2e-tests \
+FESTIPOD_SHARED_WALLET_FILE=./festipod-e2e-tests.ngw \
+bun run dev
+```
+
+## Le harness de test est buildé à part
+
+⚠️ `build.ts` ne build **pas** les harness de test. Les hooks Cucumber (`src/shared/support/hooks.ts`) lancent un `bun build` **à la demande** pour `src/shared/test-harness/harness.tsx` (et `harness-ng.tsx`) → `dist/test-harness*.js`. C'est un entrypoint séparé du build app — voir concept `bdd-testing`.
+
+## Storybook
+
+`storybook dev -p 6006` — **webpack5 + SWC** (pas Vite). Les décorateurs (`.storybook/`) injectent la pile complète de providers (Theme > NextGraph > FestipodData > Router) et importent `src/index.css` ; viewport mobile par défaut. Couplage dur au contexte projet (pas réutilisable hors Festipod).

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

@@ -0,0 +1,41 @@
+---
+type: knowledge
+summary: APIs natives Bun utilisées par le projet — Bun.serve (HTTP/WS/routes), HTML imports bundlés, bun:sqlite, Bun.redis, Bun.sql, Bun.file, Bun.$
+---
+
+# APIs natives Bun
+
+Référence des APIs Bun à privilégier (cf. [[rule_bun-first]]). Doc complète : `node_modules/bun-types/docs/**.mdx`.
+
+## Serveur — `Bun.serve()`
+
+Supporte WebSockets, HTTPS et routes. Pas besoin d'`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 },
+})
+```
+
+C'est le mécanisme de `src/index.ts` (voir concept `app-architecture` §app-shell).
+
+## HTML imports (frontend)
+
+`Bun.serve()` sert des HTML imports ; le bundler Bun transpile/bundle automatiquement `.tsx`/`.jsx`/`.js` et le CSS (Tailwind inclus). Un `<script type="module" src="./frontend.tsx">` dans le HTML suffit — pas de Vite.
+
+## Stockage & shell
+
+- **`bun:sqlite`** pour SQLite (pas `better-sqlite3`)
+- **`Bun.redis`** pour Redis (pas `ioredis`)
+- **`Bun.sql`** pour Postgres (pas `pg`/`postgres.js`)
+- **`WebSocket`** intégré (pas `ws`)
+- **`Bun.file`** plutôt que `node:fs` readFile/writeFile
+- **`Bun.$\`ls\`** plutôt qu'`execa`
+
+Bun charge `.env` automatiquement → ne pas utiliser `dotenv`.

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

@@ -0,0 +1,32 @@
+---
+type: knowledge
+summary: Déploiement — Dockerfile multi-stage Bun Alpine ; install via pnpm (git+node dans l'image) mais runtime bun ; lance `bun run start` depuis src/ (pas dist/), EXPOSE 3000, env PORT/NODE_ENV ; aucun CI/CD committé ; dev passe par le wrapper portless
+last_checked: 2026-07-14
+---
+
+# Déploiement & infra
+
+## Dockerfile
+
+Un `Dockerfile` existe (multi-stage Bun Alpine). **L'installation passe par pnpm, mais le runtime/build/test restent bun** (cf. [[knowledge_stack-and-commands]]) :
+- `FROM oven/bun:1-alpine`, stage `install` : `apk add --no-cache git nodejs npm` puis `npm install -g pnpm@10.26.0` (l'image bun n'a ni Node ni pnpm ; l'`apk nodejs` d'Alpine n'embarque pas corepack), `COPY package.json pnpm-lock.yaml`, puis `pnpm install --frozen-lockfile`. `git` est requis car `@ng-eventually/client` est une dépendance **git+https** publique (Gitea, sans auth). Stage `release` : copie `node_modules` + source.
+- `ENV NODE_ENV=production`, `USER bun`, `EXPOSE 3000/tcp`, `ENTRYPOINT ["bun","run","start"]`.
+
+**Piège `bun` peer** : `bun-plugin-tailwind` déclare `bun` en peerDependency → pnpm matérialise le paquet npm `bun` et **crée un shim `node_modules/.bin/bun`** qui shadow le `bun` du PATH sous `bun run`/`pnpm run`. Son postinstall est ignoré par défaut → shim cassé → `bun run start` échoue. Corrigé en approuvant le build : `pnpm.onlyBuiltDependencies: ["bun"]` dans `package.json` (le postinstall télécharge le vrai binaire). Sans ça, toute la migration pnpm casse le démarrage.
+
+**Quirk** : `start` = `NODE_ENV=production bun src/index.ts` → le conteneur **exécute la source TypeScript directement** (Bun transpile à la volée), il **n'utilise pas `dist/`**. Le `bun run build` (→ `dist/`) n'est donc **pas** sur le chemin de prod par défaut. Si on veut servir le build, il faut changer l'entrypoint.
+
+## CI/CD
+
+**Aucun** pipeline committé (`.github/workflows/` absent, pas de config Coolify dans le repo). Angle mort assumé. Pour héberger l'app Bun, le skill `coolify-hosting` s'applique.
+
+## Variables d'environnement
+
+- `PORT` (défaut 3000), `NODE_ENV` (active/désactive HMR et l'auto-seed dev — cf. concept `data-layer`).
+- Aucun `.env*` committé (`.env` est gitignored). Pas de gestion de secrets dans le repo.
+
+## Dev
+
+`bun run dev` = **`portless festipod bun --hot src/index.ts`** — passe par le wrapper **`portless`** (outil externe de gestion de port), pas un `bun --hot` nu. HMR actif hors production.
+
+**Lien local réactif du polyfill** : en prod la dépendance `@ng-eventually/client` vient de Gitea (git+https, figée par `pnpm-lock.yaml`). Pour éditer le polyfill localement et voir les changements en direct, `pnpm run link:polyfill` (script `scripts/link-polyfill.ts`, stratégie S2) remplace `node_modules/@ng-eventually/client` par une **copie réelle** de la source locale (`…/ng-eventually-js/packages/client`) — **sans** son propre `node_modules/@ng-org` — et resynchronise `src/` à chaque édition. C'est ce qui garantit **une seule instance `@ng-org/web`** (un seul verifier) : un symlink vers le checkout monorepo, lui, embarque son `@ng-org` → 2ᵉ instance → SDK cassé. Revenir à l'état committé : `pnpm install`.

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

@@ -0,0 +1,42 @@
+---
+type: knowledge
+summary: Composants de la stack (Bun runtime/build/test, install via pnpm, React, NextGraph, Storybook, Cucumber, Tailwind-dans-le-build) et liste réelle des scripts package.json, dont les quirks (cucumber via node+tsx, build:orm au chemin périmé, build:ng pour le fork local, link:polyfill pour le lien local réactif)
+---
+
+# Stack & commandes
+
+## Composants
+
+| Couche | Techno |
+|---|---|
+| Runtime / bundler / test | **Bun** (cf. [[rule_bun-first]]) |
+| **Installation des deps** | **pnpm** (`pnpm install`, `pnpm-lock.yaml`) — **seule** l'install passe à pnpm ; runtime/build/test restent bun. Motif : `@ng-eventually/client` est résolu depuis Gitea en **git+https** (pnpm gère proprement `git+…#main&path:/packages/client` + le dédoublonnage des peers `@ng-org`). Ne pas rebasculer l'install vers bun/npm. |
+| UI | **React** (mobile-first, largeur max 768px — style dans concept `app-architecture`) |
+| Données | **NextGraph** P2P local-first (concept `data-layer`) |
+| Build CSS | **Tailwind** (`tailwindcss` + `bun-plugin-tailwind`) — présent dans le build, mais les écrans stylent via `app-*`/inline, pas d'utilitaires Tailwind (cf. concept `app-architecture`) |
+| Exploration UI | **Storybook** (webpack5 + SWC, port 6006) |
+| Tests | **Cucumber/Gherkin** FR multi-couches + Playwright + happy-dom + chai (concept `bdd-testing`) |
+
+## Scripts `package.json` (réels)
+
+| Script | Commande / rôle |
+|---|---|
+| `dev` | `portless festipod bun --hot src/index.ts` — dev HMR via wrapper `portless` (cf. [[knowledge_deployment]]) |
+| `start` | `NODE_ENV=production bun src/index.ts` — prod, depuis `src/` (pas `dist/`) |
+| `build` | `bun run build.ts` — bundler Bun + Tailwind → `dist/` ([[knowledge_build-pipeline]]) |
+| `test:cucumber` | enchaîne `cucumber:run` → `cucumber:report` → `features:parse` → `steps:extract` |
+| `cucumber:run` | `node --import tsx/esm …/cucumber-js` — **via Node+tsx, pas Bun** (compat plugins Playwright/happy-dom) |
+| `test:data` | idem `--tags @data` |
+| `test:auth-setup` | `bun scripts/setup-test-auth.ts` — bootstrap wallet de test persistant |
+| `cucumber:report` | `bun scripts/parse-test-results.ts` — `cucumber-report.json` → HTML |
+| `features:parse` | `bun scripts/parse-features.ts` → `features.ts` |
+| `steps:extract` | `bun scripts/extract-step-definitions.ts` |
+| `build:orm` | `rdf-orm build --input ./src/shapes/shex --output ./src/shapes/orm` |
+| `build:ng` | `bash scripts/build-ng-packages.sh` — (re)build des paquets NextGraph depuis une source locale (outil optionnel) |
+| `link:polyfill` | `bun scripts/link-polyfill.ts` — lien local **réactif** du polyfill `@ng-eventually/client` (stratégie S2 : copie-overlay + watcher), préserve l'instance `@ng-org` unique. Détails dans [[knowledge_deployment]]. |
+| `storybook` / `build-storybook` | Storybook dev (6006) / build statique |
+
+## Pièges
+
+- **`cucumber:run`/`test:data` tournent sous Node+tsx**, pas Bun — les plugins de test ne chargent pas en import Bun natif. Ne pas « bunifier » ces scripts.
+- **`build:orm` cible `./src/shapes/shex` et `./src/shapes/orm`**, alors que les shapes réelles vivent sous **`src/shared/shapes/`** — le chemin du script est vraisemblablement **périmé** (à corriger ou exécuter avec les bons chemins ; vérifier avant de régénérer l'ORM).

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

@@ -0,0 +1,39 @@
+---
+type: rule
+summary: Par défaut utiliser Bun et ses APIs natives, jamais les équivalents Node — bun au lieu de node/ts-node, bun test/build, bunx, et pas d'express/ws/pg/dotenv. EXCEPTION : l'installation des paquets passe par pnpm (les deux repos), pas bun install
+---
+
+# Règle : Bun-first
+
+Par défaut, utiliser **Bun** et ses APIs natives plutôt que les équivalents Node.js.
+
+| Au lieu de… | Utiliser |
+|---|---|
+| `node <file>`, `ts-node` | `bun <file>` |
+| `jest`, `vitest` | `bun test` |
+| `npm/yarn install`, `bun install` | **`pnpm install`** (voir exception ci-dessous) |
+| `npm run <script>` | `bun run <script>` |
+| `npx <pkg>` | `bunx <pkg>` |
+| `webpack`, `esbuild`, `vite` | `bun build` / bundler Bun (HTML imports) |
+| `express` | `Bun.serve()` |
+| `better-sqlite3` | `bun:sqlite` |
+| `ioredis` | `Bun.redis` |
+| `pg`, `postgres.js` | `Bun.sql` |
+| `ws` | `WebSocket` (intégré) |
+| `node:fs` readFile/writeFile | `Bun.file` |
+| `execa` | `Bun.$\`...\`` |
+| `dotenv` | (inutile — Bun charge `.env` automatiquement) |
+
+Détail des APIs : [[knowledge_bun-apis]].
+
+## Exception : l'installation des paquets passe par pnpm
+
+**L'installation des dépendances se fait avec `pnpm install` — pas `bun install` — dans les DEUX repos** (Festipod *et* le polyfill `@ng-eventually/client`). Tout le reste reste Bun : **runtime, build, test, scripts** (`bun run dev`, `bun build`, `bun test`, `bunx`). Seule l'étape d'installation change de gestionnaire.
+
+**Pourquoi.** Le polyfill est installé en prod depuis un dépôt Gitea comme dépendance git à **sous-répertoire** : `git+https://…/ng-eventually.git#main&path:/packages/client`. pnpm (≥ 10.26) résout ce format `#<ref>&path:/…` et garantit une **seule** instance de `@ng-org/*` (un seul verifier) ; `bun install` ne couvre pas ce workflow proprement. Le lockfile de référence est donc `pnpm-lock.yaml`, et le lien local réactif du polyfill passe par `pnpm run link:polyfill` (voir [[knowledge_deployment]]).
+
+**Conséquence pratique.** Les scripts npm qui reposaient sur `node_modules/.bin/*` peuvent casser (pnpm y place des shims shell, pas des entrées JS) — appeler l'entrée JS réelle du paquet (ex. `node_modules/@cucumber/cucumber/bin/cucumber.js`) plutôt que le shim `.bin/`.
+
+## Pourquoi (Bun pour tout le reste)
+
+Le projet est tout-Bun (runtime, bundler, test, serveur). Réintroduire un outil Node redondant ajoute une dépendance, divergerait des conventions du repo, et casse l'intégration native (HMR, transpilation TS automatique, chargement `.env`). C'est un choix de cohérence, pas une préférence cosmétique. L'exception d'installation ci-dessus est le seul écart, et il est motivé par la dépendance git à sous-répertoire.

.project/decisions/2026-03-12-1500-headless-wallet-creation.md

@@ -1,54 +0,0 @@
-# Automated Headless Wallet Creation for CI
-
-**Date:** 2026-03-12 15:00
-**Status:** Accepted
-
-## Context
-
-Data-layer BDD tests (`@data` scenarios) require a NextGraph wallet in a persistent Chromium profile. Previously, the first run required manual interaction: a visible browser opened and the user had to create a wallet and close the browser. This blocked CI execution.
-
-## Options Considered
-
-### Option A: Programmatic wallet creation via NG SDK
-Call `ng.wallet_create()` directly from Node/Bun, bypassing the UI entirely.
-
-**Arguments for:**
-- Fastest execution
-- No browser needed for wallet creation
-
-**Arguments against:**
-- `@ng-org/web` is browser-only (WASM + postMessage)
-- Would need to reverse-engineer the registration API at `account.nextgraph.eu`
-- Doesn't test the real auth flow
-
-### Option B: Automate the browser UI flow headlessly
-Use Playwright to drive the same wallet creation UI a real user would use, but in headless mode.
-
-**Arguments for:**
-- Tests the real auth/login feature end-to-end
-- No API reverse-engineering needed
-- Same persistent profile used for subsequent test runs
-- CI-ready with no manual steps
-
-**Arguments against:**
-- Depends on `nextgraph.eu` and `account.nextgraph.eu` being reachable
-- UI changes in NextGraph could break the automation
-- Adds ~27s to first run
-
-## Decision
-
-Option B — automate the browser UI. The wallet creation flow (navigate to `nextgraph.eu` → "Create Wallet" → accept ToS at `account.nextgraph.eu` → fill username/password → submit) is itself a legitimate test of the app's auth feature. The dependency on external services is acceptable since the tests already depend on the broker being reachable.
-
-## Consequences
-
-**Positive:**
-- Tests are fully CI-ready (no human interaction)
-- Auth/login flow is tested as a side effect
-- Single command `bun run test:data` works from a clean state
-
-**Negative:**
-- Requires internet access (nextgraph.eu, account.nextgraph.eu)
-- Fragile to NextGraph UI changes (button text, form IDs)
-
-**Risks:**
-- `account.nextgraph.eu` rate limiting could block CI runs that frequently recreate wallets

.project/decisions/2026-03-13-1400-conditional-ng-init-broker-detection.md

@@ -1,48 +0,0 @@
-# Conditional NextGraph Init Based on Broker Iframe Detection
-
-**Date:** 2026-03-13 14:00
-**Status:** Accepted
-
-## Context
-
-`@ng-org/web`'s `initNgWeb()` checks `window.self === window.top`. When the app runs standalone (not in an iframe), it redirects the entire page to `nextgraph.net/redir/` to trigger broker authentication. This caused the app to redirect on every load — even during development or when the user hadn't clicked "Se connecter".
-
-## Options Considered
-
-### Option A: Always auto-init NG on mount
-**Arguments for:**
-- Simpler code — no branching logic
-
-**Arguments against:**
-- Causes immediate redirect to broker when loaded standalone
-- Breaks development workflow
-- User sees broker login page instead of the app
-
-### Option B: Conditional auto-init based on iframe detection
-**Arguments for:**
-- When in iframe, the broker has already authenticated — safe to auto-init
-- When standalone, user must explicitly click "Se connecter" to trigger the redirect
-- Preserves standalone demo/development experience
-- Matches `@ng-org/web`'s own detection logic
-
-**Arguments against:**
-- Relies on `window.self !== window.top` heuristic (could theoretically be wrong if embedded in non-broker iframe)
-
-## Decision
-
-Option B. `NextGraphContext` checks `const isInsideBroker = typeof window !== 'undefined' && window.self !== window.top` at module level. `useEffect` only auto-calls `initNg()` when `isInsideBroker` is true. The `connect()` callback remains available for explicit user-initiated connection.
-
-Additionally, `FestipodDataContext` now renders empty data (not seed data) during the `connecting` phase to avoid flashing demo content before the wallet loads.
-
-## Consequences
-
-**Positive:**
-- App loads without redirecting — works standalone for development and demo
-- In broker iframe, connection is seamless and automatic
-- No seed data flash during wallet connection
-
-**Negative:**
-- None significant
-
-**Risks:**
-- If `@ng-org/web` changes its detection logic, our guard may diverge — keep them aligned

.project/decisions/2026-03-17-1600-private-store-nuri-scope.md

@@ -1,67 +0,0 @@
-# Use private_store_id as useShape scope and @graph
-
-**Date:** 2026-03-17 16:00
-**Status:** Accepted
-
-## Context
-
-Clicking "Charger données de test" loaded data in-memory (via ORM signals) but produced `RepoNotFound` errors from `doc_create` and `orm_frontend_update`. Data disappeared after page reload because SPARQL writes never reached the broker. The NextGraph verifier's `self.repos` HashMap didn't contain the private store repo, so `resolve_target()` failed.
-
-## Options Considered
-
-### Option A: `did:ng:i` scope + `doc_create` for @graph
-Use "entire user site" scope for reads, create a new document for writes.
-
-**Arguments for:**
-- `did:ng:i` is well-documented as a valid subscription scope
-- `doc_create` returns a real document NURI
-
-**Arguments against:**
-- `did:ng:i` uses a special code path (`NuriTargetV0::UserSite`) that doesn't open individual repos
-- `doc_create` calls `resolve_target(NuriTargetV0::PrivateStore)` which needs the repo in `self.repos` — fails if repo wasn't opened
-- Requires complex retry logic / timing workarounds
-
-### Option B: `private_store_id` as both scope AND @graph
-Mirror the expense-tracker-rdf example: `useShape(type, `did:ng:${session.private_store_id}`)` and `@graph: `did:ng:${session.private_store_id}``.
-
-**Arguments for:**
-- Proven pattern: expense-tracker-rdf uses exactly this and works
-- `orm_start_graph` with private store NURI opens the repo in the verifier's `self.repos` HashMap
-- Subsequent writes via `orm_frontend_update` find the repo because it's now in the cache
-- Simple, no retry logic needed
-
-**Arguments against:**
-- Slightly less flexible than `did:ng:i` (scoped to one store)
-- Requires passing session to `useShapeWithDefaults`
-
-### Option C: `did:ng:i` scope + reuse existing entity @graph
-Subscribe with `did:ng:i`, then reuse `@graph` from any existing entity for writes.
-
-**Arguments for:**
-- Works for returning users who already have data
-
-**Arguments against:**
-- Fails for empty wallets (no existing entities to reuse)
-- Still needs `doc_create` fallback which hits the same `RepoNotFound` issue
-
-## Decision
-
-**Option B**: Use `did:ng:${session.private_store_id}` as both `useShape` scope and `@graph` for writes. This matches the official expense-tracker-rdf example exactly.
-
-The `useShapeWithDefaults` hook accepts a `storeNuri` parameter. `FestipodDataContext.useNgData()` gets the session from `useNextGraph()` and passes `did:ng:${session.private_store_id}`.
-
-`ensureGraphNuri()` simplified: checks existing entities first (optimization), then falls back to `did:ng:${session.private_store_id}`.
-
-## Consequences
-
-**Positive:**
-- Writes work immediately after connection (no retries needed)
-- Data persists across page reloads
-- Pattern matches official NextGraph examples
-- All 7 e2e scenarios pass including data persistence
-
-**Negative:**
-- `useShapeWithDefaults` signature changed (added `storeNuri` parameter)
-
-**Risks:**
-- If NextGraph changes the private store behavior, this would break

.project/decisions/2026-03-17-1800-sparql-delete-for-orm-objects.md

@@ -1,81 +0,0 @@
-# Use SPARQL DELETE instead of ORM ngSet.delete() for object removal
-
-**Date:** 2026-03-17 18:00
-**Status:** Accepted
-
-## Context
-
-Leaving an event requires deleting the user's `Participation` object from the NextGraph store. The ORM's `DeepSignalSet.delete()` method updates the local reactive state (UI reflects the change immediately) but the deletion does not persist to the broker — after page refresh, the participation reappears.
-
-## Options Considered
-
-### Option A: ORM `ngSet.delete(item)`
-
-The ORM README shows `dogs.delete(aDog)` as the intended API. Internally, `.delete()` generates a `{ op: "remove", path: "/<syntheticId>" }` patch, delivered via microtask to `OrmSubscription.onSignalObjectUpdate`, which calls `ng.graph_orm_update()`.
-
-**Arguments for:**
-- Official ORM API, shown in README examples
-- Immediate local reactive update (instant UI feedback)
-
-**Arguments against:**
-- Does not persist in practice: `delete()` returns `true`, local set updates, but after refresh the object is back
-- The `graph_orm_update` WASM call may not correctly handle "remove" patches for top-level set objects (possible engine bug)
-- No error is thrown — fails silently
-
-### Option B: `ng.sparql_update()` with SPARQL DELETE
-
-Bypass the ORM patch mechanism entirely. Use `DELETE WHERE { GRAPH <graph> { <subject> ?p ?o } }` to remove all RDF triples for the object.
-
-**Arguments for:**
-- Works: deletion persists across page refresh
-- The broker confirms via `TORMO became invalid` + `GraphOrmUpdate` remove, which reactively removes the item from the ORM set
-- Direct control over RDF triple removal
-
-**Arguments against:**
-- Not instant: UI update waits for the SPARQL round-trip + broker `GraphOrmUpdate` callback (near-instant in practice, ~50ms)
-- Must not combine with `ngSet.delete()` — running both causes CRDT conflicts where the item reappears
-
-### Option C: `ngSet.delete()` + `ng.sparql_update()` together
-
-Use `.delete()` for instant UI and SPARQL for persistence.
-
-**Arguments for:**
-- Instant UI feedback + guaranteed persistence
-
-**Arguments against:**
-- **Does not work**: the ORM `.delete()` patch and the SPARQL DELETE backend update conflict in the CRDT, resulting in neither UI change nor persistence
-
-## Decision
-
-**Option B: SPARQL DELETE only.** The broker sends back a `GraphOrmUpdate` with `op: "remove"` that reactively removes the item from the ORM set, so the UI still updates — just not synchronously.
-
-Do NOT call `ngSet.delete()` alongside `sparql_update()` — they conflict.
-
-## Implementation
-
-```typescript
-// In FestipodDataContext.tsx leaveEvent():
-const session = await sessionPromise;
-await ng.sparql_update(
-  session.session_id,
-  `DELETE WHERE { GRAPH <${partGraph}> { <${partId}> ?p ?o } }`,
-  partGraph,
-);
-```
-
-Imports: `ng` from `@ng-org/web`, `sessionPromise` from `../utils/ngSession`.
-
-## Consequences
-
-**Positive:**
-- Deletion actually persists
-- Single source of truth (broker → ORM → UI)
-
-**Negative:**
-- Slight UI delay (~50ms) vs instant for property mutations
-- Pattern diverges from ORM README examples
-
-**Risks:**
-- If `ng.sparql_update` API changes, this breaks
-- Other delete operations (if added) must follow the same pattern
-- The ORM `ngSet.delete()` bug may be fixed in a future version — revisit when upgrading `@ng-org/orm`

.project/knowledge/architecture.md

@@ -1,84 +0,0 @@
-# Architecture
-
-Feature-based architecture where code is organized by business domain (module), not by technical layer.
-
-## Module Structure
-
-```
-src/modules/
-  event/          # 7 screens, 5 features — events CRUD, discovery, participants, meeting points
-  user/           # 5 screens, 11 features — profiles, friends, sharing
-  home/           # 2 screens — dashboard, settings
-  auth/           # 2 screens — login, welcome/onboarding
-  workshop/       # 0 screens, 6 features — workshop/atelier specs (future)
-  meeting/        # 0 screens, 1 feature — meeting point specs
-  notification/   # 0 screens, 3 features — notification specs
-```
-
-Each module can contain:
-- `screens/` — React screen components
-- `features/` — Gherkin `.feature` files (BDD specs)
-- `steps/{ui,data,e2e}/` — Cucumber step definitions by layer
-
-## Import Rules
-
-**Modules only import from `shared/` — never from each other.**
-
-```
-src/modules/event/screens/EventDetailScreen.tsx
-  ✅ import from '../../../shared/components/sketchy'
-  ✅ import from '../../../shared/context/FestipodDataContext'
-  ✅ import from '../../../screens' (registry types)
-  ❌ import from '../../user/screens/...'
-```
-
-## Shared Layer
-
-`src/shared/` contains everything reusable across modules:
-
-| Directory | Contents |
-|-----------|----------|
-| `components/sketchy/` | Hand-drawn UI library (Button, Card, Avatar, Header, NavBar, etc.) |
-| `components/ui/` | Shadcn/Radix components (used only in prototyping tool) |
-| `context/` | ThemeContext, NextGraphContext, FestipodDataContext |
-| `data/` | User stories (`index.ts`), auto-generated `features.ts`, `testResults.ts`, `seedData.ts`, `types.ts` |
-| `hooks/` | `useShapeWithDefaults` (NextGraph) |
-| `shapes/` | SHEX definitions + ORM TypeScript bindings |
-| `utils/` | `ngSession.ts`, `ngBootstrap.ts` |
-| `steps/ui/` | Shared BDD step definitions (navigation, screen, form) |
-| `support/` | Cucumber `world.ts`, `hooks.ts` |
-| `types/` | `gherkin.ts` (ParsedFeature, ParsedScenario types) |
-| `lib/` | `utils.ts` (cn helper for Tailwind) |
-
-## App Shell
-
-`src/app/` is the prototyping tool — not part of the Festipod app itself:
-
-- `App.tsx` — Root: ThemeProvider > NextGraphProvider > FestipodDataProvider > RouterProvider
-- `router.tsx` — Hash-based routing: `#/` (gallery), `#/demo/{screenId}`, `#/specs/{featureId}`
-- `frontend.tsx` — React entry point (referenced from `src/index.html`)
-- `components/Gallery.tsx` — Screen preview grid
-- `components/DemoMode.tsx` — Interactive mockup viewer with sidebar navigation
-- `components/specs/` — BDD specs browser (SpecsPage, FeatureView, GherkinHighlighter)
-
-## Screen Registry
-
-`src/screens/index.ts` is the central registry that imports all screens from all modules and exports:
-- `screenGroups` — Grouped by domain (Accueil, Evenements, Utilisateur, General)
-- `screens` — Flat list
-- `getScreen(id)` — Lookup by ID
-- `ScreenProps` interface — `{ navigate: (screenId: string) => void }`
-
-## Entry Points
-
-| File | Purpose |
-|------|---------|
-| `src/index.ts` | Bun.serve() — HTTP server, serves index.html + cucumber report |
-| `src/index.html` | HTML entry, loads `src/app/frontend.tsx` |
-| `src/app/frontend.tsx` | React root, renders `<App />` |
-
-## Build
-
-- Dev: `bun --hot src/index.ts` (via `bun run dev`)
-- Prod: `bun run build.ts` — Bun bundler + Tailwind plugin → `dist/`
-- Path alias: `@/*` → `./src/*` (tsconfig)

.project/knowledge/bdd-testing.md

@@ -1,113 +0,0 @@
-# BDD Testing
-
-Cucumber/Gherkin BDD specs in French with multi-layer step definitions.
-
-## Overview
-
-- 26 feature files (US-1 to US-26), all in French
-- Categories: EVENT, WORKSHOP, USER, MEETING, NOTIF
-- Priorities: 0 (Impossible), 1 (Haute), 2 (Moyenne), 3 (Basse)
-- Current results: 51 passed, 7 failed, 75 skipped (133 scenarios total)
-
-## Multi-Layer BDD
-
-Each module has step directories for three test layers:
-
-```
-src/modules/event/steps/
-  ui/           # UI/screen assertions (source analysis)
-  data/         # Data layer assertions (Playwright + broker)
-  e2e/          # E2E assertions (Playwright + broker + real app UI)
-```
-
-Shared steps (cross-domain) live in `src/shared/steps/ui/`.
-
-## Feature Files
-
-Collocated with their module:
-
-```
-src/modules/event/features/us-13-creer-evenement.feature
-src/modules/user/features/us-23-connexion-utilisateurs.feature
-src/modules/workshop/features/us-1-visualiser-atelier-termine.feature
-...
-```
-
-Tagged with `@CATEGORY @priority-N` for filtering.
-
-## Step Definitions
-
-### Shared Steps (`src/shared/steps/ui/`)
-
-| File | Purpose |
-|------|---------|
-| `navigation.steps.ts` | Screen navigation, authentication, click/select actions, section/button/field assertions |
-| `form.steps.ts` | Form field validation, required fields, import/duplicate detection |
-| `screen.steps.ts` | Screen content assertions (participants, events, profiles, QR codes) |
-
-### How UI Steps Work
-
-`@ui` steps render the screen with `LocalDataProvider` (seed data) and `RouterProvider` via happy-dom, then assert on the rendered DOM. The render helper lives in `src/shared/test-harness/renderHelper.tsx` and is invoked from `world.ts:renderCurrentScreen()` on every `navigateTo(...)`.
-
-See [test-layer-contracts](./test-layer-contracts.md) for what `@ui` is allowed to test and the patterns to follow (and avoid).
-
-Legacy: `screenFileMap`, `screenFieldDetectors`, `screenExpectedContent`, `screenRequiredFields` in `world.ts` are vestiges of an earlier source-code-grep approach. `hasText`/`hasField`/`hasElement` now prefer the rendered DOM and fall back to source so unmigrated steps keep working during the transition.
-
-### Screen Name Resolution
-
-French names in `.feature` files map to screen IDs via `screenNameMap`:
-- `"accueil"` → `home`
-- `"détail événement"` → `event-detail`
-- `"mon profil"` → `profile`
-- `"relayer un événement"` → `create-event`
-
-## Cucumber Configuration
-
-`cucumber.json`:
-```json
-{
-  "default": {
-    "import": [
-      "src/shared/support/**/*.ts",
-      "src/shared/steps/**/*.ts",
-      "src/modules/*/steps/**/*.ts"
-    ],
-    "paths": ["src/modules/*/features/**/*.feature"],
-    "language": "fr"
-  }
-}
-```
-
-Requires `tsx` loader: `node --import tsx/esm node_modules/.bin/cucumber-js`
-
-## Auto-Generated Files
-
-Scripts in `scripts/` parse features and steps into TypeScript data files consumed by the prototyping tool:
-
-| Script | Input | Output |
-|--------|-------|--------|
-| `parse-features.ts` | `src/modules/*/features/*.feature` | `src/shared/data/features.ts` |
-| `parse-test-results.ts` | `reports/cucumber-report.json` | `src/shared/data/testResults.ts` |
-| `extract-step-definitions.ts` | `src/shared/steps/ui/*.ts` | `src/shared/data/stepDefinitions.ts` |
-
-Run all: `bun run test:cucumber`
-
-## Data-Layer Testing
-
-`@data` scenarios test through the real NextGraph broker. See [data-layer-testing](./data-layer-testing.md) for full architecture.
-
-## E2E Testing
-
-`@e2e` scenarios test the real app running in the broker iframe. See [data-layer-testing](./data-layer-testing.md#e2e-layer) for architecture. Key differences from `@data`:
-
-- Uses the **real app** (not a test harness) served on a local HTTP port
-- Interacts via Playwright locators and `evaluate()` on the app iframe
-- Tests actual UI behavior: navigation, redirects, button clicks, screen content
-- Requires real broker mode (fails with `Error` if broker unavailable)
-
-## Adding New Steps
-
-1. **Module-specific**: Create in `src/modules/{module}/steps/ui/`
-2. **Cross-domain**: Add to `src/shared/steps/ui/`
-3. Import `FestipodWorld` type from `../../support/world` (shared) or adjust relative path
-4. Run `bun run steps:extract` to regenerate tooltip data

.project/knowledge/data-layer-testing.md

@@ -1,177 +0,0 @@
-# Data-Layer Testing
-
-BDD scenarios tagged `@data` test the real NextGraph data pipeline through a broker, not mocked data.
-
-## Overview
-
-`@data` scenarios run Cucumber steps against a real NextGraph broker. Playwright drives a Chromium instance that authenticates with the broker, which loads our test harness in an iframe. The harness uses real `useShape`/ORM subscriptions and exposes a `window.__testData` bridge for step definitions.
-
-## Architecture
-
-```
-Cucumber steps → Playwright (Chromium, persistent profile)
-                      ↓
-               https://nextgraph.eu/auth/#/?o=http://127.0.0.1:{port}
-                      ↓
-               Broker wallet login (automated)
-                      ↓
-               Broker loads app in iframe → http://127.0.0.1:{port}
-                      ↓
-               harness-ng.tsx (init → useShape → ORM → broker)
-                      ↓
-               window.__testData bridge
-```
-
-## Dual Mode
-
-- **Real broker** (default): `harness-ng.tsx` with NextGraph ORM through broker iframe
-- **Mock fallback**: `harness.tsx` with standalone DeepSignalSets (if NG harness build fails)
-
-## Wallet Lifecycle
-
-Fully automated — no manual interaction required. CI-ready.
-
-### First Run (wallet creation + bootstrap)
-1. `BeforeAll` detects no `.wallet-ready` marker in `.playwright-profile/`
-2. Launches headless Chromium with persistent profile
-3. Navigates to `https://nextgraph.eu/` → clicks "Create Wallet"
-4. Redirected to `account.nextgraph.eu` → clicks "I accept" (ToS)
-5. Redirected back → fills username/password form → submits
-6. Wallet created in localStorage
-7. **Logs in to the wallet** — this triggers the verifier bootstrap from the remote broker, populating localStorage with repo data
-8. Waits 10s for bootstrap to complete, then closes context
-9. Marker written
-
-Step 7 is critical: the NextGraph verifier starts with an empty `repos` HashMap. On first login, `verifier.sync()` bootstraps from the remote broker, downloading repo data (including store repos). This data is saved to localStorage via `session_save`. Without this initial login, subsequent sessions would have empty repos and all writes would fail with `RepoNotFound`.
-
-### Subsequent Runs (automated login)
-1. Marker found → skip wallet creation
-2. Headless Chromium with persistent profile
-3. Automated login: click "Login" → click wallet link → fill password → submit
-4. Broker authenticates, loads app harness in iframe
-5. Harness initializes NG, creates ORM subscriptions, seeds data if needed
-6. `window.__testData.ready` → steps execute via `appFrame.evaluate()`
-
-### Wallet Credentials
-- Name: `festipod-tests`
-- Password: `festipod-tests`
-
-## Key Technical Details
-
-### Chromium Flags
-```
---disable-features=PrivateNetworkAccessRespectPreflightResults,BlockInsecurePrivateNetworkRequests,...
---allow-insecure-localhost
---disable-web-security
-```
-Required because broker at `nextgraph.eu` (public) loads harness from `http://127.0.0.1:{port}` (local) in an iframe — Chromium's Private Network Access blocks this by default.
-
-### Persistent Profile (`.playwright-profile/`)
-- Stores NG wallet in localStorage (`ng_wallets` on `nextgraph.eu`, `ng_bootstrap` on `nextgraph.net`)
-- Gitignored
-- Must use full Chrome binary, not `chrome-headless-shell`
-
-### HTTP Server
-- Started in `BeforeAll` on auto-assigned port (`127.0.0.1:0`)
-- Serves harness HTML at `/` and JS bundle at `/harness.js` (separate files — inline script breaks due to special characters in bundle)
-- Shut down in `AfterAll`
-
-### ORM Subscriptions
-Harness creates subscriptions for all three shapes with scope `did:ng:${session.private_store_id}` (opens the store repo for reads AND writes):
-- `FpEventShapeType` → events
-- `FpUserProfileShapeType` → users
-- `FpParticipationShapeType` → participations
-
-### Test Bridge (`window.__testData`)
-Exposed by the harness, consumed by steps via `appFrame.evaluate()`:
-- `events`, `users`, `participations` — live DeepSignalSets
-- `currentUserId` — IRI of the test user
-- `getEvent(id)`, `getEventByTitle(title)` — lookups
-- `joinEvent(eventId, userId)`, `leaveEvent(eventId, userId)` — mutations
-- `isParticipating(eventId, userId)`, `getEventParticipants(eventId)` — queries
-- `updateEvent(eventId, updates)` — field updates
-
-## E2E Layer (`@e2e`)
-
-`@e2e` scenarios test the real app UI running inside the broker iframe. Unlike `@data` which loads a test harness, `@e2e` loads the actual app.
-
-### Architecture
-
-```
-Cucumber steps → Playwright (Chromium, persistent profile)
-                      ↓
-               https://nextgraph.net/redir/#/?o=http://127.0.0.1:{appPort}
-                      ↓
-               Broker wallet login (automated, same as @data)
-                      ↓
-               Broker loads REAL APP in iframe → http://127.0.0.1:{appPort}
-                      ↓
-               App renders with NextGraphProvider auto-connecting
-                      ↓
-               Steps interact via appFrame.evaluate() and Playwright locators
-```
-
-### App Server
-
-Started in `BeforeAll` alongside the harness server:
-1. Find a free port
-2. `spawn('bun', ['src/index.ts'], { env: { PORT: appPort } })`
-3. Poll until the server responds to HTTP GET
-4. Killed in `AfterAll`
-
-### Shared Infrastructure
-
-`@e2e` reuses the same `setupBrokerPage()` helper as `@data` — handles broker redirect URL construction, wallet login automation, and iframe discovery.
-
-### Step Definitions
-
-E2E steps live in module directories (e.g., `src/modules/auth/steps/e2e/connexion.steps.ts`). They use:
-- `this.appFrame!.evaluate()` — run JS in the app iframe (hash navigation, content checks)
-- `this.appFrame!.locator()` — find and interact with DOM elements
-- `this.appFrame!.waitForFunction()` — poll for expected state (screen content, URL changes)
-- `SCREEN_MARKERS` — map screen IDs to unique text content for verification
-
-### Before Hook (`@e2e`)
-
-```
-1. Open new Playwright page
-2. setupBrokerPage(page, realAppUrl) → automated login → find app iframe
-3. Wait for React render (root.innerHTML.length > 100)
-4. Wait 3s for NG connection + provider stabilization
-```
-
-### Differences from `@data`
-
-| Aspect | `@data` | `@e2e` |
-|--------|---------|--------|
-| What loads in iframe | Test harness (`harness-ng.tsx`) | Real app (`src/index.ts`) |
-| Ready signal | `window.__testData.ready === true` | `root.innerHTML.length > 100` |
-| Interaction | `evaluate()` on test bridge | `evaluate()` + Playwright locators |
-| Mock fallback | Yes (standalone DeepSignalSets) | No — requires real broker |
-| Tests | Data operations (CRUD, queries) | UI behavior (navigation, redirects, clicks) |
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `src/shared/test-harness/harness-ng.tsx` | Real broker harness (useShape through broker iframe) |
-| `src/shared/test-harness/harness.tsx` | Mock harness (DeepSignalSets, no broker) |
-| `src/shared/support/hooks.ts` | Playwright lifecycle (wallet creation, login automation, iframe detection, app server) |
-| `src/shared/support/world.ts` | World with `page`/`appFrame` fields |
-| `src/modules/event/steps/data/inscription.steps.ts` | Inscription data steps |
-| `src/modules/auth/steps/e2e/connexion.steps.ts` | Auth/connection e2e steps |
-| `.playwright-profile/` | Persistent Chromium profile (gitignored) |
-| `scripts/debug-browser.ts` | Manual browser debug tool — launches headed Chromium to inspect broker interactions |
-| `.playwright-profile-debug/` | Chromium profile created by debug-browser.ts (gitignored) |
-
-## Commands
-
-```bash
-bun run test:data      # Run @data scenarios (real broker if wallet exists, mock fallback)
-bun run test:cucumber  # Run all scenarios (UI + data + e2e)
-```
-
-## See Also
-
-- [BDD Testing](./bdd-testing.md) — general Cucumber setup, UI-layer steps
-- [Data Layer](./data-layer.md) — NextGraph stack, shapes, context providers

.project/knowledge/data-layer.md

@@ -1,115 +0,0 @@
-# Data Layer
-
-NextGraph-backed local-first data with fallback to local state for demo/disconnected mode.
-
-## Overview
-
-The app has two data modes:
-1. **Connected** — NextGraph ORM shapes (P2P, encrypted, local-first)
-2. **Disconnected/Demo** — Local React state seeded from `seedData.ts`
-
-All screens use `useFestipodData()` hook regardless of mode.
-
-## NextGraph Stack
-
-```
-@ng-org/web          # Browser WASM runtime
-@ng-org/orm          # RDF shape-based ORM
-@ng-org/shex-orm     # SHEX → TypeScript code generation
-@ng-org/alien-deepsignals  # Reactive signals bridge
-```
-
-Packages installed from npm (`@ng-org/*` alpha versions). For local development against an unreleased `nextgraph-rs` build, `scripts/build-ng-packages.sh` packs the monorepo into `.ng-tarballs/` and updates `package.json` to point at those paths.
-
-## SHEX Shapes
-
-`src/shared/shapes/shex/festipodShapes.shex` defines:
-- **Event** — title, description, dates, location, themes, participants
-- **UserProfile** — name, username, bio, city, visibility
-- **Participation** — links event + user, confirmation status
-
-ORM bindings in `src/shared/shapes/orm/`:
-- `festipodShapes.schema.ts` — Schema registration
-- `festipodShapes.shapeTypes.ts` — Shape type constants
-- `festipodShapes.typings.ts` — TypeScript interfaces
-
-Regenerate with `bun run build:orm`.
-
-## NextGraph Read/Write Pattern
-
-The app follows the same pattern as the official expense-tracker-rdf example:
-
-- **Scope**: `useShape(shapeType, `did:ng:${session.private_store_id}`)` — opens the private store repo in the verifier
-- **@graph**: `did:ng:${session.private_store_id}` — writes target the same NURI
-
-This is critical: `orm_start_graph` with the private store NURI explicitly opens the repo in the verifier's `self.repos` HashMap. Without this, `orm_frontend_update` fails with `RepoNotFound`.
-
-**Do NOT use `did:ng:i` as scope** — it subscribes to the entire user site via a special code path that doesn't open individual repos, breaking all writes.
-
-### Deleting Objects
-
-`ngSet.delete(item)` updates the local reactive set but does **not** persist to the broker. Use `ng.sparql_update()` with SPARQL DELETE instead:
-
-```typescript
-import { ng } from '@ng-org/web';
-import { sessionPromise } from '../utils/ngSession';
-
-const session = await sessionPromise;
-await ng.sparql_update(
-  session.session_id,
-  `DELETE WHERE { GRAPH <${item["@graph"]}> { <${item["@id"]}> ?p ?o } }`,
-  item["@graph"],
-);
-```
-
-The broker sends back a `GraphOrmUpdate` with `op: "remove"` that reactively removes the item from the ORM set. **Do NOT combine with `ngSet.delete()`** — the two operations conflict in the CRDT.
-
-See [decision record](../decisions/2026-03-17-1800-sparql-delete-for-orm-objects.md) for details.
-
-### Key files
-
-- `src/shared/hooks/useShapeWithDefaults.ts` — Accepts `storeNuri` param, passes to `useShape`
-- `src/shared/utils/ngGraph.ts` — `ensureGraphNuri()` returns `@graph` for entity creation
-- `src/shared/utils/ngBootstrap.ts` — Seeds test data using `ensureGraphNuri()` for `@graph`
-
-See [decision record](.project/decisions/2026-03-17-1600-private-store-nuri-scope.md) for why.
-
-## Context Providers
-
-### NextGraphContext (`src/shared/context/NextGraphContext.tsx`)
-- Connection lifecycle: `disconnected` → `connecting` → `connected` | `error`
-- Provides session with store IDs (private, protected, public)
-- **Conditional auto-init**: Only auto-calls `initNg()` when running inside the broker iframe (`window.self !== window.top`). Outside the iframe, `initNgWeb()` would redirect the page to the broker — so connection waits for explicit `connect()` call.
-- `connect()`: Called by user clicking "Se connecter". When outside broker, triggers the redirect flow.
-
-#### `@ng-org/web` redirect behavior
-`initNgWeb()` checks `window.self === window.top`. If the app is NOT in an iframe, it redirects to `nextgraph.net/redir/` with the current URL encoded as a return parameter. The broker then loads the app back in an iframe after auth. This means the app must NOT auto-init NG when loaded standalone.
-
-### FestipodDataContext (`src/shared/context/FestipodDataContext.tsx`)
-- Wraps NextGraph shapes with `useShapeWithDefaults()` hook
-- CRUD: `createEvent()`, `updateEvent()`, `joinEvent()`, `leaveEvent()`, etc.
-- Exposes `useFestipodData()` hook consumed by all screens
-- `selectedEventId` state for cross-screen event navigation
-- `loadTestData()`: Calls `bootstrapWallet()` to seed test data into NG wallet — only triggered by explicit user action
-- **Provider states based on NG status**:
-  - `disconnected` → `LocalDataProvider` with seed data (demo mode)
-  - `connecting` → `LocalDataProvider` with **empty data** (avoids flashing seed data before wallet loads)
-  - `connected` → `NgDataProvider` with real wallet data
-  - `error` → `LocalDataProvider` with seed data (graceful fallback)
-
-## Data Types
-
-`src/shared/data/types.ts`:
-- `FpEventData` — id, title, date, location, distance, themes, etc.
-- `FpUserData` — id, name, username, bio, city, counts
-- `FpParticipationData` — eventId + userId + confirmed
-- `FpMeetingPointData` — eventId, location, time, host (local-only)
-- `FpFriendshipData` — userId + friendId (local-only)
-
-## Seed Data
-
-`src/shared/data/seedData.ts`:
-- 10 users (Marie Dupont = current user, `user-1`)
-- Multiple events with dates, locations, themes
-- Participations, meeting points, friendships
-- `CURRENT_USER_ID = 'user-1'`

.project/knowledge/screens.md

@@ -1,94 +0,0 @@
-# Screens
-
-16 mobile mockup screens using the sketchy hand-drawn component library.
-
-## Screen Inventory
-
-### Home Module (`src/modules/home/screens/`)
-
-| ID | Name | File | Description |
-|----|------|------|-------------|
-| `welcome` | Bienvenue | WelcomeScreen.tsx | Onboarding/welcome page |
-| `home` | Accueil | HomeScreen.tsx | Dashboard with upcoming events, quick actions |
-| `settings` | Parametres | SettingsScreen.tsx | Notifications, privacy, location settings |
-
-### Event Module (`src/modules/event/screens/`)
-
-| ID | Name | File | Description |
-|----|------|------|-------------|
-| `events` | Decouvrir | EventsScreen.tsx | Event discovery/search |
-| `event-detail` | Detail evenement | EventDetailScreen.tsx | Event info, participants, join/leave |
-| `create-event` | Relayer evenement | CreateEventScreen.tsx | Create/relay event, import from Mobilizon/Transiscope |
-| `update-event` | Modifier evenement | UpdateEventScreen.tsx | Edit existing event |
-| `invite` | Inviter des amis | InviteScreen.tsx | Invite contacts to event |
-| `participants-list` | Liste des participants | ParticipantsListScreen.tsx | Event participant list |
-| `meeting-points` | Points de rencontre | MeetingPointsScreen.tsx | Carpooling/meeting coordination |
-
-### User Module (`src/modules/user/screens/`)
-
-| ID | Name | File | Description |
-|----|------|------|-------------|
-| `profile` | Mon profil | ProfileScreen.tsx | Current user profile |
-| `update-profile` | Modifier mon profil | UpdateProfileScreen.tsx | Edit profile form |
-| `user-profile` | Profil d'un utilisateur | UserProfileScreen.tsx | View another user's profile |
-| `friends-list` | Mon reseau | FriendsListScreen.tsx | Network/friends list |
-| `share-profile` | Partager mon profil | ShareProfileScreen.tsx | QR code + link sharing |
-
-### Auth Module (`src/modules/auth/screens/`)
-
-| ID | Name | File | Description |
-|----|------|------|-------------|
-| `login` | Connexion | LoginScreen.tsx | Login (NextGraph + email fallback) |
-
-## Screen Registry
-
-`src/screens/index.ts` imports all screens and exports:
-
-```typescript
-export interface ScreenProps {
-  navigate: (screenId: string) => void;
-}
-
-export const screenGroups: ScreenGroup[]  // Grouped: home, events, user, general
-export const screens: Screen[]            // Flat list
-export function getScreen(id: string): Screen | undefined
-```
-
-## Sketchy Component Library
-
-`src/shared/components/sketchy/` — hand-drawn UI with custom font:
-
-| Component | Usage |
-|-----------|-------|
-| `Header` | Screen header with back button |
-| `NavBar` | Bottom tab navigation |
-| `Button` | Action buttons |
-| `Card` | Content cards |
-| `Input` | Text inputs |
-| `Title`, `Subtitle`, `Text` | Typography |
-| `Avatar` | User avatars with initials |
-| `Badge` | Status/category badges |
-| `Toggle`, `Checkbox` | Form controls |
-| `ListItem` | List row items |
-| `Divider` | Section separators |
-| `Placeholder` | Image/content placeholders |
-| `PhoneFrame` | Phone device frame wrapper |
-| `BrokerBanner` | NextGraph connection status banner |
-| `NgStatus` | Connection indicator dot |
-
-## Screen Patterns
-
-All screens follow the same pattern:
-
-```typescript
-import { Header, Button, ... } from '../../../shared/components/sketchy';
-import { useFestipodData } from '../../../shared/context/FestipodDataContext';
-import type { ScreenProps } from '../../../screens';
-
-export function MyScreen({ navigate }: ScreenProps) {
-  const { events, currentUser, ... } = useFestipodData();
-  // render with sketchy components
-}
-```
-
-Navigation between screens uses `navigate(screenId)` — the prototyping tool intercepts this to switch the displayed screen.

.project/knowledge/test-layer-contracts.md

@@ -1,90 +0,0 @@
-# Test Layer Contracts
-
-Each BDD test layer (`@ui`, `@data`, `@e2e`) answers a distinct question. Mixing concerns produces brittle tests that fail on refactors without catching real regressions.
-
-## Overview
-
-```
-       /\  @e2e   ~10 scénarios, parcours utilisateur critiques
-      /  \
-     /----\
-    / @data\  ~10 scénarios, mutations & persistance NG
-   /--------\
-  /   @ui    \  ~60 scénarios, 1-5 par état d'écran × 15 écrans
- /____________\
-```
-
-The pyramid reflects cost: `@ui` runs in-process (instant), `@data` boots a broker (~50s for the suite), `@e2e` boots broker + real app + navigates a real browser (~2min). Move every assertion to the lowest layer that can answer the question — UI rendering claims belong in `@ui`, not `@e2e`.
-
-## Key Concepts
-
-- **`@ui` — display layer.** Renders a screen with `LocalDataProvider` (seed data) + happy-dom and asserts on the resulting DOM. Verifies that *given known data, the screen shows the expected text and elements*. Does **not** test navigation outcomes, mutations, or data persistence.
-
-- **`@data` — data layer.** Drives ORM mutations through the real NextGraph broker via a headless test harness. No app UI involved. Verifies that *operations on shapes are correctly persisted and observable in the wallet*. See [data-layer-testing](./data-layer-testing.md).
-
-- **`@e2e` — integration layer.** Boots the real app inside the broker iframe with a Playwright-controlled Chromium. Verifies that *layers collaborate to deliver a user journey* (e.g. create → list → modify → reload → still there). Sparse: 1 scenario per critical path; never duplicate `@ui` content checks here.
-
-## Implementation
-
-### `@ui` — rendering helper
-
-`src/shared/test-harness/renderHelper.tsx` installs happy-dom globals and renders any screen wrapped in `LocalDataProvider` + `RouterProvider`. Called from `world.ts:renderCurrentScreen()` on every `navigateTo(...)`. Seed data (`src/shared/data/seedData.ts`) provides predictable fixtures — `Marie Dupont`/`@mariedupont` is `currentUser`, `Jean Durand`/`@jeandurand` exists in `users`, 5 seed events, etc.
-
-**Good `@ui` assertion patterns:**
-
-```ts
-// Text visible to the user
-expect(this.getDomText()).to.include('Marie Dupont');
-
-// Element presence by class/role
-expect(this.renderedDoc!.querySelector('.app-avatar')).to.not.be.null;
-
-// Conditional rendering (filled state vs empty state)
-const cards = this.renderedDoc!.querySelectorAll('.app-card');
-expect(cards.length).to.be.greaterThan(0);
-
-// Required form fields rendered with their label + 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;
-```
-
-**Anti-patterns to remove:**
-
-```ts
-// ❌ Regex on source: couples test to code structure, fails on refactor
-expect(/<Title[^>]*>Marie Dupont<\/Title>/.test(source)).to.be.true;
-
-// ❌ Testing implementation details
-expect(/showDuplicateWarning/.test(source)).to.be.true;
-expect(/importableEvents/.test(source)).to.be.true;
-
-// ❌ Testing JSX structure rather than rendered output
-expect(/<Avatar[^>]*initials="MD"[^>]*size="lg"/.test(source)).to.be.true;
-```
-
-### `@data` — broker-only
-
-Already isolated correctly. See [data-layer-testing](./data-layer-testing.md). Don't touch the DOM here; use the test harness bridge (`window.__testData`).
-
-### `@e2e` — full stack
-
-Path-based routing: navigate via `window.history.pushState` + `popstate` dispatch (`src/modules/auth/steps/e2e/connexion.steps.ts`). Assert on actual DOM text after `appFrame.waitForFunction`. **Do not** re-verify here what `@ui` already covers — `@e2e` should fail when *collaboration* between layers breaks, not when an icon changes.
-
-## Migration Consequences
-
-The current `@ui` suite predates this contract. The migration plan:
-
-1. **Rewrite source-grep assertions** → DOM queries via the helper. The `world.ts:hasText/hasField/hasElement` methods already prefer the rendered DOM and fall back to source — so unmigrated steps still work during the transition.
-2. **Delete tests on implementation details** (`/showDuplicateWarning/`, `/importableEvents/`, regex on JSX). They protect nothing the user sees.
-3. **Move behavioral assertions to `@e2e`** when not already covered ("clicking Suivant advances the wizard" — exercise it via Playwright if it's not redundant with existing journeys).
-4. **Drop redundant `@e2e` content checks** that duplicate `@ui` (e.g. "screen contains 'Découvrir'" — let `@ui` own that).
-
-`world.ts:screenFileMap`, `screenFieldDetectors`, `screenExpectedContent`, `screenRequiredFields` are vestiges of the source-analysis era. Once the migration is complete, they can be removed in favor of seed-data assertions on the rendered DOM.
-
-## See Also
-
-- [BDD Testing setup](./bdd-testing.md) — Cucumber config, file layout, scripts
-- [Data Layer](./data-layer.md) — NextGraph shapes, seed data, contexts
-- [Data-Layer Testing](./data-layer-testing.md) — broker harness, wallet setup, Playwright
-- [Architecture](./architecture.md) — module structure

AGENTS.md

@@ -1,75 +1,34 @@
 # Festipod
 
-Mobile-first web app for discovering and sharing festival/event recommendations through trusted networks.
+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é).
 
-## Architecture
+## Invariants à toujours garder
 
-Feature-based: code organized by business domain, not technical layer. See [architecture](.project/knowledge/architecture.md).
+- **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).
 
-```
-src/modules/{event,user,home,auth,workshop,meeting,notification}/
-src/shared/          # Components, context, data — importable by all modules
-src/app/             # App shell (router, providers, entry point)
-src/screens/index.ts # Screen registry (used by Storybook)
-```
+## Frontière SDK NextGraph
 
-## Routing
+Le SDK de données de Festipod est **`@ng-eventually/client`** — traité comme un **SDK NextGraph fini et mature** (documents par entité placés par scope public/protected/private, capabilities, inboxes). Il est injecté une seule fois via `ngSession.configure(...)`. **Ne jamais documenter dans ce repo l'état courant de NextGraph** (contraintes du SDK sous-jacent, contournements, internes broker/verifier) : cela vit dans le repo `@ng-eventually/client`. La doctrine Festipod décrit uniquement *comment Festipod utilise ce SDK* + le domaine + l'architecture + le contrat BDD.
 
-Path-based routing with History API (custom router in `src/app/router.tsx`).
+## Doctrine du projet — concepts (livrée automatiquement)
 
-| Path | Screen |
-|------|--------|
-| `/` | WelcomeScreen |
-| `/login` | LoginScreen |
-| `/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 |
-| `/users/:id` | UserProfileScreen |
-| `/settings` | SettingsScreen |
+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 :
 
-Screens use `useNavigate()` and `useParams()` hooks from the router — no prop drilling.
+| 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/client` : 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 |
 
-## Data Layer
-
-NextGraph (P2P/local-first) with SHEX shapes and ORM. See [data-layer](.project/knowledge/data-layer.md).
-
-## BDD Testing
-
-Multi-layer Cucumber/Gherkin in French. See [bdd-testing](.project/knowledge/bdd-testing.md) for the setup and [test-layer-contracts](.project/knowledge/test-layer-contracts.md) for what each layer is allowed to test.
-
-`@ui` scenarios render screens in-process (happy-dom + seed data) and assert on the DOM. `@data` scenarios test data operations through the real NextGraph broker. `@e2e` scenarios test the real app UI in the broker iframe. See [data-layer-testing](.project/knowledge/data-layer-testing.md).
-
-## Quick Start
-
-```bash
-bun run dev              # Dev server with HMR (port 3000)
-bun run build            # Production build to dist/
-bun run storybook        # Browse screens and components
-bun run test:cucumber    # Run all BDD tests
-bun run features:parse   # Regenerate features.ts from .feature files
-bun run steps:extract    # Extract step definitions for tooltips
-bun run build:orm        # Regenerate ORM from SHEX shapes
-```
-
-## Documentation
-
-- [Architecture](.project/knowledge/architecture.md) — module structure, import rules, app shell
-- [Data Layer](.project/knowledge/data-layer.md) — NextGraph, shapes, context, seed data
-- [BDD Testing](.project/knowledge/bdd-testing.md) — Cucumber setup, step layers, feature files
-- [Test Layer Contracts](.project/knowledge/test-layer-contracts.md) — what each of `@ui`/`@data`/`@e2e` is allowed to test
-- [Screens](.project/knowledge/screens.md) — screen inventory, registry, sketchy components
-- [Data-Layer Testing](.project/knowledge/data-layer-testing.md) — real broker testing, wallet setup, Playwright harness, e2e layer
-
-## Briefs (work not yet started)
-
-- [Multi-store refactor](.project/briefs/multi-store-refactor.md) — passer du mono-store actuel à une structure de Group stores par communauté/event/RDV (prérequis multi-user)
-- [Matrice d'autorisations et requêtes](.project/briefs/authorization-matrix.md) — analyse qui doit guider la structure de stores cible
+Pour **documenter** un fait projet : `/concept document <sujet>` (ne pas écrire en libre dans `.project/`).

CLAUDE.md

@@ -2,195 +2,8 @@
 
 # Festipod Project
 
-Mobile-first web app for discovering and sharing festival/event recommendations through trusted networks. Uses a sketchy hand-drawn UI style.
+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.
 
-## Architecture
-
-Feature-based architecture: code is organized by business domain (module), not by technical layer. A module can only import from `shared/` — never from another module.
-
-Multi-layer BDD: each module has `steps/ui/`, `steps/data/`, `steps/e2e/` directories. Shared step definitions live in `src/shared/steps/`.
-
-## Project Structure
-
-```
-src/
-  modules/                  # Business domain modules
-    event/                  # Events (create, discover, detail, update, invite, participants, meeting points)
-      screens/              # EventsScreen, EventDetailScreen, CreateEventScreen, etc.
-      features/             # Gherkin .feature files for this domain
-      steps/                # BDD step definitions
-        ui/                 # UI-layer steps
-        data/               # Data-layer steps
-        e2e/                # E2E steps
-    user/                   # User profiles, friends, sharing
-      screens/              # ProfileScreen, FriendsListScreen, ShareProfileScreen, etc.
-      features/
-      steps/
-    home/                   # Home dashboard, settings
-      screens/              # HomeScreen, SettingsScreen
-    auth/                   # Authentication, onboarding
-      screens/              # LoginScreen, WelcomeScreen
-    workshop/               # Workshop/atelier specs (no screens yet)
-      features/
-      steps/
-    meeting/                # Meeting point specs
-      features/
-      steps/
-    notification/           # Notification specs
-      features/
-      steps/
-  shared/                   # Shared code (importable by all modules)
-    components/
-      sketchy/              # Hand-drawn UI components (Button, Card, Avatar, etc.)
-      ui/                   # Shadcn/Radix components
-    context/                # ThemeContext, NextGraphContext, FestipodDataContext
-    data/                   # User stories, features.ts (auto-generated), testResults.ts
-    hooks/                  # Custom hooks (useShapeWithDefaults)
-    shapes/                 # SHEX shapes + ORM bindings (NextGraph)
-    utils/                  # ngSession, ngBootstrap
-    steps/                  # Shared BDD step definitions (cross-domain)
-      ui/                   # navigation.steps.ts, form.steps.ts, screen.steps.ts
-      data/
-    support/                # Cucumber hooks.ts, world.ts
-    types/                  # TypeScript type definitions
-    lib/                    # Utility functions (cn, etc.)
-  app/                      # App shell
-    App.tsx                 # Root component with providers + route switch
-    router.tsx              # Path-based routing (History API)
-    frontend.tsx            # React entry point
-  screens/
-    index.ts                # Screen registry (used by Storybook)
-scripts/                    # Build scripts for parsing features
-docs/                       # Documentation
-.storybook/                 # Storybook configuration
-```
-
-## Key Commands
-
-```bash
-bun run dev              # Start dev server with HMR
-bun run storybook        # Browse screens and components in Storybook
-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
-```
-
-## Routing
-
-Path-based routing via `src/app/router.tsx`. Screens use `useNavigate()` and `useParams()` hooks. See AGENTS.md for the full route table.
-
-## Conventions
-
-- Gherkin specs are in French (Etant donne, Quand, Alors)
-- UI labels are in French
-- User stories are prefixed US-1 to US-26
-- Screens use the sketchy component library, not Tailwind
-- Max app width: 768px (tablet portrait)
-
----
-
-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: the @ng-eventually/client polyfill is a git+https (public Gitea) dependency → no auth.
+# - nodejs + npm: pnpm is a Node CLI; we pin the exact pnpm version via `npm i -g`
+#   (Alpine's nodejs package does not bundle corepack).
+# The `bun` npm peer (pulled by bun-plugin-tailwind) is approved to build in package.json
+# (pnpm.onlyBuiltDependencies) so node_modules/.bin/bun is a real binary — required because
+# `bun run start` puts node_modules/.bin ahead of PATH.
 FROM base AS install
-COPY package.json bun.lock ./
-RUN bun install --frozen-lockfile
+RUN apk add --no-cache git nodejs npm \
+    && npm install -g pnpm@10.26.0
+COPY package.json pnpm-lock.yaml ./
+RUN pnpm install --frozen-lockfile
 
 # Copy source code and build assets
 FROM base AS release

README.md

@@ -40,7 +40,7 @@ Implémentées dans le code (écrans visibles via le router) :
 - Liste d'amis (connexions)
 - Profil d'un autre utilisateur
 
-Voir le tableau des routes dans [AGENTS.md](./AGENTS.md#routing) et l'inventaire des écrans dans [.project/knowledge/screens.md](./.project/knowledge/screens.md).
+Voir l'inventaire des routes et des écrans dans le concept [app-architecture](./.project/concepts/app-architecture/).
 
 ### Défis ouverts
 
@@ -56,7 +56,7 @@ Identifiées comme nécessaires (notamment pour la scalabilité et la découvert
 - **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 vers les Group stores NextGraph. Voir [brief multi-store-refactor](./.project/briefs/multi-store-refactor.md).
+- **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
 
@@ -78,7 +78,5 @@ bun run build:orm        # Régénérer l'ORM depuis les SHEX shapes
 
 ## Documentation
 
-- [AGENTS.md](./AGENTS.md) — architecture, routes, points d'entrée pour contribuer
-- [.project/knowledge/](./.project/knowledge/) — comment les choses fonctionnent (data layer, BDD, écrans…)
-- [.project/decisions/](./.project/decisions/) — choix techniques figés
-- [.project/briefs/](./.project/briefs/) — chantiers à venir, recherche préparatoire
+- [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,32 @@ const result = await Bun.build({
   sourcemap: "linked",
   define: {
     "process.env.NODE_ENV": JSON.stringify("production"),
+    // Access gate (ON by default) + shared wallet password, baked into the
+    // browser bundle as globals (see src/app/AuthGate.tsx, sharedWallet.ts). The
+    // wallet FILE is copied into the outdir below (served at /shared-wallet.ngw).
+    "globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__": JSON.stringify(
+      process.env.ACCESS_GATE_DISABLED === "1",
+    ),
+    "globalThis.__FESTIPOD_SHARED_WALLET_PASSWORD__": JSON.stringify(
+      process.env.FESTIPOD_SHARED_WALLET_PASSWORD ?? "",
+    ),
+    // Auto-seed gate (OFF by default): only seed a genuinely-empty wallet with
+    // demo data when FESTIPOD_AUTO_SEED is set (see src/shared/utils/autoSeed.ts).
+    "globalThis.__FESTIPOD_AUTO_SEED__": JSON.stringify(
+      process.env.FESTIPOD_AUTO_SEED ?? "",
+    ),
   },
   ...cliConfig,
 });
 
+// Staging: copy the shared wallet FILE into the bundle so the access gate can
+// offer it for download (served at /shared-wallet.ngw). See sharedWallet.ts.
+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 => ({

cucumber.json

@@ -6,6 +6,7 @@
       "src/modules/*/steps/**/*.ts"
     ],
     "paths": ["src/modules/*/features/**/*.feature"],
+    "tags": "not @wip and not @humain",
     "format": [
       "progress-bar",
       "json:reports/cucumber-report.json",

package.json

@@ -15,11 +15,14 @@
     "features:parse": "bun scripts/parse-features.ts",
     "steps:extract": "bun scripts/extract-step-definitions.ts",
     "build:orm": "rdf-orm build --input ./src/shapes/shex --output ./src/shapes/orm",
+    "validate": "bun scripts/validate.ts",
     "build:ng": "bash scripts/build-ng-packages.sh",
+    "link:polyfill": "bun scripts/link-polyfill.ts",
     "storybook": "storybook dev -p 6006",
     "build-storybook": "storybook build"
   },
   "dependencies": {
+    "@ng-eventually/client": "git+https://gitea.reconnexion.apps.gueraud.net/Reconnexion/ng-eventually.git#main&path:/packages/client",
     "@ng-org/alien-deepsignals": "0.1.2-alpha.11",
     "@ng-org/orm": "0.1.2-alpha.18",
     "@ng-org/shex-orm": "0.1.2-alpha.8",
@@ -56,5 +59,10 @@
     "@storybook/addon-a11y": "^10.3.5",
     "@storybook/addon-docs": "^10.3.5",
     "@storybook/addon-onboarding": "^10.3.5"
+  },
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "bun"
+    ]
   }
 }

scripts/link-polyfill.ts

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

scripts/validate.ts

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

src/app/App.tsx

@@ -1,12 +1,13 @@
 import { RouterProvider, useRouter } from './router';
 import { ThemeProvider } from '../shared/context/ThemeContext';
 import { NextGraphProvider } from '../shared/context/NextGraphContext';
+import { AccountProvider } from '../shared/context/AccountContext';
 import { FestipodDataProvider } from '../shared/context/FestipodDataContext';
+import { AuthGate } from './AuthGate';
 import { ToastContainer } from '../shared/components/sketchy';
 
 // Auth
 import { WelcomeScreen } from '../modules/auth/screens/WelcomeScreen';
-import { LoginScreen } from '../modules/auth/screens/LoginScreen';
 
 // Home
 import { HomeScreen } from '../modules/home/screens/HomeScreen';
@@ -34,7 +35,6 @@ function AppContent() {
 
   switch (route.page) {
     case 'welcome': return <WelcomeScreen />;
-    case 'login': return <LoginScreen />;
     case 'home': return <HomeScreen />;
     case 'events': return <EventsScreen />;
     case 'create-event': return <CreateEventScreen />;
@@ -57,14 +57,18 @@ export function App() {
   return (
     <ThemeProvider>
       <NextGraphProvider>
-        <FestipodDataProvider>
-          <RouterProvider>
-            <div className="app-container">
-              <AppContent />
-              <ToastContainer />
-            </div>
-          </RouterProvider>
-        </FestipodDataProvider>
+        <AccountProvider>
+          <FestipodDataProvider>
+            <RouterProvider>
+              <div className="app-container">
+                <AuthGate>
+                  <AppContent />
+                </AuthGate>
+                <ToastContainer />
+              </div>
+            </RouterProvider>
+          </FestipodDataProvider>
+        </AccountProvider>
       </NextGraphProvider>
     </ThemeProvider>
   );

src/app/AuthGate.tsx

@@ -0,0 +1,91 @@
+/**
+ * AuthGate — the stopgap access flow (see decision_2026-06-15_shared-wallet-login-flow):
+ *   1. Access barrier + identifier (AccessGateScreen) → the user names their
+ *      virtual space (an identifier) and opens the SHARED wallet via the broker
+ *      redirect (with the wallet file + guide it hands the user). Naming the
+ *      space and opening it are ONE act.
+ *   2. The app.
+ *
+ * The gate is ON BY DEFAULT (Festipod never functions without NextGraph). It is
+ * disabled only when `globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ === true` —
+ * injected by `build.ts` (from ACCESS_GATE_DISABLED=1) for a no-gate build, or
+ * by the test harness via `context.addInitScript` for @e2e (which exercises the
+ * screens, not the auth flow). Absent → gate ON.
+ */
+
+import { useEffect, type ReactNode } from 'react';
+import { useNextGraph } from '../shared/context/NextGraphContext';
+import { useAccount, normalizeIdentifier } from '../shared/context/AccountContext';
+import { AccessGateScreen } from '../modules/auth/screens/AccessGateScreen';
+import { useRouter, useNavigate } from './router';
+
+declare global {
+  // eslint-disable-next-line no-var
+  var __FESTIPOD_ACCESS_GATE_DISABLED__: boolean | undefined;
+}
+const GATE_DISABLED = globalThis.__FESTIPOD_ACCESS_GATE_DISABLED__ === true;
+
+export function AuthGate({ children }: { children: ReactNode }) {
+  const { status, error, connect } = useNextGraph();
+  const { identifier, login } = useAccount();
+  const { route } = useRouter();
+  const navigate = useNavigate();
+
+  // Once connected AND identified, leave the disconnected welcome screen for the
+  // app home. The identifier is now set at the barrier (before the broker
+  // round-trip), so on return the app can land on '/' with a session already
+  // open; the removed ConnexionScreen used to do this navigate on login.
+  useEffect(() => {
+    if (!GATE_DISABLED && status === 'connected' && identifier && route.page === 'welcome') {
+      navigate('/home');
+    }
+  }, [status, identifier, route.page, navigate]);
+
+  // Gate explicitly disabled (no-gate build / @e2e harness) → straight to app.
+  if (GATE_DISABLED) {
+    return <>{children}</>;
+  }
+
+  // Access barrier — shown until BOTH the wallet is open AND the space is named.
+  // "Entrer" records the identifier (persisted to localStorage AND written into
+  // the `?id=` URL param, which is what actually survives the broker redirect
+  // across the partitioned frontier) and, if the wallet isn't open yet, triggers
+  // the connect.
+  //
+  // On return (reload / broker round-trip) the identifier is already stored, so
+  // we PREFILL the field with it (`initialIdentifier`) — the user never sees a
+  // bare empty prompt they must re-type. It is captured ONCE, at first access.
+  if (status !== 'connected' || !identifier) {
+    const onEnter = (entered: string) => {
+      login(entered);
+      // Carry the identifier across the broker frontier via the URL. localStorage
+      // is partitioned by top-level site, so the value written here (127.0.0.1)
+      // is NOT what the app reads inside the broker iframe (nextgraph.net). The
+      // `@ng-org/web` redirect embeds the FULL app URL (query included) in the
+      // broker `o=`, which is reloaded in the iframe — so writing the normalized
+      // id into `?id=` BEFORE connect() makes it travel. `history.replaceState`
+      // (not push) keeps a single history entry. See AccountContext resolution.
+      if (typeof window !== 'undefined') {
+        try {
+          const url = new URL(window.location.href);
+          url.searchParams.set('id', normalizeIdentifier(entered));
+          window.history.replaceState(window.history.state, '', url.toString());
+        } catch {
+          /* URL construction can't fail for a real page URL; ignore defensively */
+        }
+      }
+      if (status !== 'connected') connect();
+    };
+    return (
+      <AccessGateScreen
+        status={status}
+        error={error}
+        initialIdentifier={identifier ?? ''}
+        onEnter={onEnter}
+      />
+    );
+  }
+
+  // The app.
+  return <>{children}</>;
+}

src/app/frontend.tsx

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

src/app/router.tsx

@@ -6,7 +6,6 @@ import React, { createContext, useContext, useState, useEffect, useCallback } fr
 
 type Route =
   | { page: 'welcome' }
-  | { page: 'login' }
   | { page: 'home' }
   | { page: 'events' }
   | { page: 'create-event' }
@@ -38,7 +37,6 @@ function parsePath(pathname: string): Route {
   const path = pathname.replace(/\/+$/, '') || '/';
 
   if (path === '/' || path === '') return { page: 'welcome' };
-  if (path === '/login') return { page: 'login' };
   if (path === '/home') return { page: 'home' };
   if (path === '/events') return { page: 'events' };
   if (path === '/events/new') return { page: 'create-event' };
@@ -73,7 +71,6 @@ function parsePath(pathname: string): Route {
 export function routeToPath(route: Route): string {
   switch (route.page) {
     case 'welcome': return '/';
-    case 'login': return '/login';
     case 'home': return '/home';
     case 'events': return '/events';
     case 'create-event': return '/events/new';

src/index.css

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

src/index.ts

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

src/modules/auth/features/barriere-acces-identifiant.feature

@@ -0,0 +1,27 @@
+# language: fr
+@AUTH @priority-1
+Fonctionnalité: Barrière d'accès — l'identifiant se saisit une seule fois
+  En tant qu'utilisateur qui revient dans Festipod
+  Je veux retrouver l'identifiant que j'ai déjà choisi, pré-rempli
+  Afin de ne jamais avoir à le retaper à l'arrivée
+
+  # Garde-fou contre la régression rapportée : au retour (rechargement / round-trip
+  # broker) la barrière re-demandait un identifiant NU et VIDE alors qu'il était
+  # déjà stocké. L'identifiant est capturé UNE FOIS au premier accès, persisté,
+  # puis pré-rempli. Voir AuthGate + AccessGateScreen.
+
+  @ui
+  Scénario: Le champ identifiant est pré-rempli avec la valeur déjà stockée
+    Étant donné que la barrière d'accès s'affiche avec l'identifiant stocké "alice"
+    Alors le champ identifiant contient "alice"
+
+  @ui
+  Scénario: Un premier accès sans identifiant stocké affiche un champ vide
+    Étant donné que la barrière d'accès s'affiche sans identifiant stocké
+    Alors le champ identifiant est vide
+
+  @ui
+  Scénario: Entrer remonte l'identifiant saisi
+    Étant donné que la barrière d'accès s'affiche avec l'identifiant stocké "alice"
+    Quand je clique sur "Entrer" dans la barrière
+    Alors l'identifiant remonté à l'application est "alice"

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

@@ -6,29 +6,10 @@ Fonctionnalité: Connexion NextGraph et chargement des données
   Et charger les données de test dans mon portefeuille
   Afin d'utiliser l'application avec mes propres données
 
-  # --- UI layer: écran de connexion ---
-
-  @ui
-  Scénario: L'écran de connexion affiche le bouton NextGraph
-    Étant donné je suis sur la page "connexion"
-    Alors l'écran contient un bouton "Se connecter avec NextGraph"
-
-  @ui @wip
-  # Behavioral: requires simulating an NG status change. Better tested at the
-  # @e2e layer where a real connected session triggers the redirect.
-  Scénario: L'écran de connexion redirige automatiquement quand connecté
-    Étant donné je suis sur la page "connexion"
-    Alors l'écran gère la redirection automatique après connexion
-
-  @ui
-  Scénario: L'état initial est "en cours" quand une connexion est en attente
-    Étant donné je suis sur la page "connexion"
-    Alors l'écran gère l'état de connexion en cours
-
-  @ui
-  Scénario: Aucune donnée de démonstration n'est visible pendant la connexion
-    Étant donné je suis sur la page "connexion"
-    Alors l'écran n'importe pas de données de démonstration
+  # NB : l'ancien écran /login (LoginScreen) a été retiré — l'accès NextGraph
+  # passe désormais par l'AccessGateScreen (barrière ON par défaut), cf.
+  # decision_2026-06-17_assisted-wallet-import. Les scénarios @ui qui testaient
+  # le LoginScreen ont été supprimés en conséquence.
 
   # --- Data layer: comportement du portefeuille ---
 
@@ -59,11 +40,6 @@ Fonctionnalité: Connexion NextGraph et chargement des données
 
   # --- E2E layer: comportement réel dans le navigateur ---
 
-  @e2e
-  Scénario: L'écran de connexion redirige vers l'accueil si déjà connecté
-    Quand l'utilisateur navigue vers l'écran "login"
-    Alors l'application affiche l'écran "home"
-
   @e2e
   Scénario: La navigation interne met à jour l'URL
     Quand l'utilisateur navigue vers l'écran "events"

src/modules/auth/features/identifiant-resolution.feature

@@ -0,0 +1,42 @@
+# language: fr
+@AUTH @priority-1
+Fonctionnalité: Résolution de l'identifiant — le param d'URL prime sur localStorage
+  En tant qu'application relancée dans l'iframe du broker après le round-trip
+  Je veux résoudre l'identifiant depuis le param d'URL "?id="
+  Afin qu'il traverse la frontière top-level↔iframe (que localStorage ne franchit pas)
+
+  # Le flux wallet-partagé fait tourner l'app dans DEUX contextes avec DEUX
+  # partitions localStorage distinctes (top-level 127.0.0.1 vs iframe
+  # nextgraph.net). localStorage ne traverse pas la frontière ; le param "?id="
+  # embarqué dans le redirect broker (o=) la traverse. AccountContext résout donc
+  # dans l'ordre : (1) param d'URL "?id=" (source de vérité) ; (2) sinon
+  # localStorage (préremplissage même-partition). Voir AccountContext + AuthGate.
+
+  @ui
+  Scénario: Le param d'URL est la source de vérité quand il est présent
+    Étant donné que localStorage contient l'identifiant "alice"
+    Et que l'URL porte le param id "bob"
+    Quand le contexte de compte résout l'identifiant
+    Alors l'identifiant résolu est "bob"
+
+  @ui
+  Scénario: Le param d'URL prime même sur une valeur localStorage différente et est persisté
+    Étant donné que localStorage contient l'identifiant "alice"
+    Et que l'URL porte le param id "carol"
+    Quand le contexte de compte résout l'identifiant
+    Alors l'identifiant résolu est "carol"
+    Et localStorage contient désormais l'identifiant "carol"
+
+  @ui
+  Scénario: Sans param d'URL, localStorage sert de repli
+    Étant donné que localStorage contient l'identifiant "dave"
+    Et que l'URL ne porte aucun param id
+    Quand le contexte de compte résout l'identifiant
+    Alors l'identifiant résolu est "dave"
+
+  @ui
+  Scénario: Le param d'URL est normalisé (minuscules, @ retiré)
+    Étant donné que localStorage ne contient aucun identifiant
+    Et que l'URL porte le param id "@Erin"
+    Quand le contexte de compte résout l'identifiant
+    Alors l'identifiant résolu est "erin"

src/modules/auth/screens/AccessGateScreen.tsx

@@ -0,0 +1,169 @@
+/**
+ * AccessGateScreen — the *technical access barrier* of the stopgap.
+ *
+ * STOPGAP (see decision_2026-06-15_shared-wallet-login-flow). This is the
+ * REAL NextGraph login, shown before the app renders. Because it precedes the
+ * app, the user reads it as "access to the test environment", not as an app
+ * login. The user also types an IDENTIFIER here — the id that names their
+ * virtual space (a technical id, a pseudo in practice, not a Festipod username).
+ * Clicking "Entrer" records that identifier and triggers `connect()`, which
+ * redirects to the broker to open the SHARED wallet. After return the identity
+ * is already set (persisted before the redirect), so NG auto-connects straight
+ * into the app — there is no separate "pick a username" screen.
+ *
+ * ASSISTED IMPORT (see decision_2026-06-17). The hosted broker can't import a
+ * wallet inline during
+ * web-app auth: a first-time device has no wallet, so the broker redirect would
+ * dead-end. We therefore HAND the user the shared wallet FILE (download) + the
+ * shared password and guide a one-time import on nextgraph.eu ("Import a Wallet
+ * File"), BEFORE they click "Entrer". The wallet FILE is the correct static
+ * primitive — a TextCode is a transient 5-min transfer, unusable to embed. Shown
+ * only when a shared wallet is configured (FESTIPOD_SHARED_WALLET_PASSWORD).
+ */
+
+import { useState, type ReactNode } from 'react';
+import { Button, Input, Title, Text } from '../../../shared/components/sketchy';
+import { SHARED_WALLET_PASSWORD, SHARED_WALLET_FILE_URL, WALLET_IMPORT_URL, hasSharedWallet } from '../sharedWallet';
+
+interface AccessGateScreenProps {
+  status: 'disconnected' | 'connecting' | 'connected' | 'error';
+  error?: string;
+  /**
+   * The identifier already stored for this space (the persisted one), used to
+   * PREFILL the field so a returning user never re-types it. Empty on a truly
+   * first access. Normalized upstream; shown verbatim.
+   */
+  initialIdentifier?: string;
+  /** Enter the space: the raw identifier the user typed (normalized upstream). */
+  onEnter: (identifier: string) => void;
+}
+
+// One numbered step: a badge + a title + the action for that step.
+function Step({ n, title, children }: { n: number; title: string; children: ReactNode }) {
+  return (
+    <div style={{ display: 'flex', gap: 12, marginBottom: 18 }}>
+      <div style={{
+        flexShrink: 0, width: 26, height: 26, borderRadius: '50%', background: '#E8590C',
+        color: '#fff', display: 'flex', alignItems: 'center', justifyContent: 'center', fontWeight: 700, fontSize: 14,
+      }}>{n}</div>
+      <div style={{ flex: 1, minWidth: 0 }}>
+        <Text style={{ margin: '2px 0 8px', fontWeight: 600, fontSize: 14 }}>{title}</Text>
+        {children}
+      </div>
+    </div>
+  );
+}
+
+export function AccessGateScreen({ status, error, initialIdentifier, onEnter }: AccessGateScreenProps) {
+  const connecting = status === 'connecting';
+  const [copied, setCopied] = useState(false);
+  // The identifier that names this virtual space (a technical id — a pseudo in
+  // practice, but not a Festipod username). Entered HERE, at wallet access, so a
+  // single act both names the space and opens it. Normalized (lowercased) upstream.
+  // PREFILLED from the stored identifier so a returning user (reload / broker
+  // round-trip) sees the value they already chose and never re-types it.
+  const [identifier, setIdentifier] = useState(initialIdentifier ?? '');
+
+  const copyPassword = async () => {
+    try {
+      await navigator.clipboard.writeText(SHARED_WALLET_PASSWORD);
+      setCopied(true);
+      setTimeout(() => setCopied(false), 2000);
+    } catch {
+      // clipboard may be blocked — the password stays selectable
+    }
+  };
+
+  const canEnter = !connecting && identifier.trim().length > 0;
+  const enter = () => { if (canEnter) onEnter(identifier); };
+
+  // Identifier field + Entrer: naming the space and opening it are one act.
+  const entrer = (
+    <div style={{ display: 'flex', flexDirection: 'column', gap: 10 }}>
+      <Input
+        data-testid="identifier-input"
+        placeholder="votre identifiant"
+        value={identifier}
+        onChange={(e: React.ChangeEvent<HTMLInputElement>) => setIdentifier(e.target.value)}
+        onKeyDown={(e: React.KeyboardEvent) => { if (e.key === 'Enter') enter(); }}
+      />
+      <Text style={{ margin: 0, fontSize: 12, color: '#999' }}>
+        Il identifie votre espace (mis en minuscules).
+      </Text>
+      <Button
+        variant="primary"
+        onClick={enter}
+        disabled={!canEnter}
+        style={{ width: '100%', opacity: canEnter ? 1 : 0.6 }}
+      >
+        {connecting ? 'Accès en cours…' : 'Entrer'}
+      </Button>
+    </div>
+  );
+
+  return (
+    <div style={{ padding: 24, display: 'flex', flexDirection: 'column', height: '100%' }}>
+      <div style={{ flex: 1, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
+        <Title style={{ textAlign: 'center', fontSize: 30, marginBottom: 4 }}>Festipod</Title>
+        <Text style={{ textAlign: 'center', marginBottom: 24, color: '#888' }}>Espace de test</Text>
+
+        {hasSharedWallet() && status !== 'connected' ? (
+          <>
+            <Text style={{ textAlign: 'center', fontSize: 14, color: '#666', margin: '0 0 20px', lineHeight: 1.5 }}>
+              Première connexion sur cet appareil ?<br />Chargez le portefeuille partagé, une seule fois.
+            </Text>
+
+            <Step n={1} title="Téléchargez le portefeuille">
+              <a
+                data-testid="shared-wallet-download"
+                href={SHARED_WALLET_FILE_URL}
+                download="festipod-wallet.ngw"
+                style={{
+                  display: 'block', textAlign: 'center', textDecoration: 'none',
+                  padding: 10, borderRadius: 10, background: '#E8590C', color: '#fff', fontWeight: 600, fontSize: 14,
+                }}
+              >
+                ⬇ Télécharger le portefeuille
+              </a>
+            </Step>
+
+            <Step n={2} title="Importez-le sur NextGraph">
+              <Text style={{ margin: '0 0 8px', fontSize: 13, lineHeight: 1.6, color: '#666' }}>
+                <a href={WALLET_IMPORT_URL} target="_blank" rel="noopener noreferrer" style={{ color: '#E8590C', fontWeight: 600 }}>
+                  Ouvrir la page d'import
+                </a>{' '}(nouvel onglet) → « Import a Wallet File » → choisissez le fichier → mot de passe :
+              </Text>
+              <div style={{ display: 'flex', alignItems: 'center', gap: 8 }}>
+                <code
+                  data-testid="shared-wallet-password"
+                  style={{ flex: 1, padding: '6px 10px', background: '#fff', border: '1px solid #eee', borderRadius: 8, fontSize: 13, userSelect: 'all' }}
+                >
+                  {SHARED_WALLET_PASSWORD}
+                </code>
+                <Button variant="accent-outline" onClick={copyPassword} style={{ padding: '6px 10px', fontSize: 12 }}>
+                  {copied ? 'Copié ✓' : 'Copier'}
+                </Button>
+              </div>
+            </Step>
+
+            <Step n={3} title="Revenez ici, choisissez un identifiant et entrez">
+              {entrer}
+            </Step>
+          </>
+        ) : (
+          entrer
+        )}
+
+        {status === 'error' && (
+          <Text style={{ textAlign: 'center', fontSize: 12, color: '#c92a2a', marginTop: 12 }}>
+            {error || "Accès à l'environnement impossible. Réessayez."}
+          </Text>
+        )}
+      </div>
+
+      <Text style={{ textAlign: 'center', fontSize: 12, color: '#bbb' }}>
+        Version beta
+      </Text>
+    </div>
+  );
+}

src/modules/auth/screens/LoginScreen.stories.tsx

@@ -1,14 +0,0 @@
-import type { Meta, StoryObj } from '@storybook/react-webpack5';
-import { LoginScreen } from './LoginScreen';
-import { withProviders } from '../../../../.storybook/decorators';
-
-const meta: Meta<typeof LoginScreen> = {
-  title: 'Screens/Auth/LoginScreen',
-  component: LoginScreen,
-  decorators: [withProviders],
-};
-export default meta;
-
-type Story = StoryObj<typeof LoginScreen>;
-
-export const Default: Story = {};

src/modules/auth/screens/LoginScreen.tsx

@@ -1,95 +0,0 @@
-import { useEffect } from 'react';
-import { Button, Input, Title, Text, Divider } from '../../../shared/components/sketchy';
-import { useNextGraph } from '../../../shared/context/NextGraphContext';
-import { useNavigate } from '../../../app/router';
-
-export function LoginScreen() {
-  const navigate = useNavigate();
-  const { status, connect } = useNextGraph();
-
-  useEffect(() => {
-    if (status === 'connected') {
-      navigate('/home');
-    }
-  }, [status]);
-
-  const handleNgLogin = () => {
-    if (status === 'connected') {
-      navigate('/home');
-    } else {
-      connect();
-    }
-  };
-
-  return (
-    <div style={{ padding: 24, display: 'flex', flexDirection: 'column', height: '100%' }}>
-      <div style={{ flex: 1, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
-        <Title style={{ textAlign: 'center', fontSize: 32, marginBottom: 8 }}>Festipod</Title>
-        <Text style={{ textAlign: 'center', marginBottom: 32, color: '#888' }}>Créez et rejoignez des événements entre amis</Text>
-
-        {/* NextGraph login */}
-        <div style={{ marginBottom: 24 }}>
-          {status === 'connected' ? (
-            <div style={{ textAlign: 'center', marginBottom: 8 }}>
-              <Text style={{ color: '#22543D', fontWeight: 'bold', margin: '0 0 8px 0' }}>
-                ✓ Connecté via NextGraph
-              </Text>
-              <Button variant="primary" onClick={() => navigate('/home')} style={{ width: '100%' }}>
-                Continuer vers l'accueil
-              </Button>
-            </div>
-          ) : status === 'connecting' ? (
-            <Button disabled style={{ width: '100%', opacity: 0.6 }}>
-              Connexion NextGraph en cours...
-            </Button>
-          ) : (
-            <div>
-              <Button
-                variant="primary"
-                onClick={handleNgLogin}
-                style={{ width: '100%' }}
-              >
-                Se connecter avec NextGraph
-              </Button>
-              {status === 'error' && (
-                <Text style={{ textAlign: 'center', fontSize: 12, color: '#888', marginTop: 8 }}>
-                  NextGraph non disponible — mode démonstration
-                </Text>
-              )}
-            </div>
-          )}
-        </div>
-
-        <Divider />
-
-        <Text style={{ textAlign: 'center', fontSize: 14, color: '#888', margin: '16px 0' }}>
-          ou connexion classique (démo)
-        </Text>
-
-        <div style={{ display: 'flex', flexDirection: 'column', gap: 16 }}>
-          <div>
-            <Text style={{ marginBottom: 4, fontSize: 13, color: '#888' }}>Email</Text>
-            <Input type="email" placeholder="vous@exemple.com" />
-          </div>
-
-          <div>
-            <Text style={{ marginBottom: 4, fontSize: 13, color: '#888' }}>Mot de passe</Text>
-            <Input type="password" placeholder="••••••••" />
-          </div>
-
-          <Button variant="primary" onClick={() => navigate('/home')}>
-            Se connecter
-          </Button>
-
-          <Text style={{ textAlign: 'center', fontSize: 14, color: '#E8590C' }}>
-            Mot de passe oublié ?
-          </Text>
-        </div>
-      </div>
-
-      <Text style={{ textAlign: 'center', fontSize: 14, color: '#888' }}>
-        Pas encore de compte ? <span style={{ color: '#E8590C', cursor: 'pointer' }}>S'inscrire</span>
-      </Text>
-    </div>
-  );
-}

src/modules/auth/screens/WelcomeScreen.tsx

@@ -1,8 +1,18 @@
+import { useEffect } from 'react';
 import { Button, Title, Text } from '../../../shared/components/sketchy';
 import { useNavigate } from '../../../app/router';
+import { useNextGraph } from '../../../shared/context/NextGraphContext';
 
 export function WelcomeScreen() {
   const navigate = useNavigate();
+  const { status } = useNextGraph();
+
+  // Onboarding is for NOT-connected users. A connected user landing on '/'
+  // (e.g. a returning tester past the access gate) goes straight to the app.
+  useEffect(() => {
+    if (status === 'connected') navigate('/home');
+  }, [status]);
+
   return (
     <div style={{ padding: 24, display: 'flex', flexDirection: 'column', height: '100%' }}>
       <div style={{ flex: 1, display: 'flex', flexDirection: 'column', justifyContent: 'center' }}>
@@ -41,12 +51,12 @@ export function WelcomeScreen() {
           </div>
         </div>
 
-        <Button variant="primary" onClick={() => navigate('/login')} style={{ marginBottom: 12 }}>
+        <Button variant="primary" onClick={() => navigate('/home')} style={{ marginBottom: 12 }}>
           Rejoindre la communauté
         </Button>
 
         <Text style={{ textAlign: 'center', fontSize: 13, color: '#888' }}>
-          Déjà membre ? <span onClick={() => navigate('/login')} style={{ color: '#E8590C', cursor: 'pointer', fontWeight: 600 }}>Connexion</span>
+          Déjà membre ? <span onClick={() => navigate('/home')} style={{ color: '#E8590C', cursor: 'pointer', fontWeight: 600 }}>Connexion</span>
         </Text>
       </div>
 

src/modules/auth/sharedWallet.ts

@@ -0,0 +1,38 @@
+/**
+ * Shared wallet material for the staging stopgap.
+ *
+ * STOPGAP: the hosted broker can't auto-import a wallet, so Festipod HANDS the
+ * user the shared wallet and guides a one-time import on nextgraph.eu.
+ *
+ * The correct primitive is the **wallet FILE** (.ngw), NOT a TextCode: a
+ * TextCode is a transient device-to-device transfer (5 min, source device
+ * online, single use) — useless to embed. A wallet file is STATIC and reusable.
+ * So Festipod serves the file (download) + shows the shared password; the user
+ * imports it via nextgraph.eu → "Import a Wallet File".
+ *
+ * ZERO-SECURITY shared credential (friendly users) → embedding the file +
+ * password is consistent with the posture.
+ *
+ * `build.ts` copies the file (from FESTIPOD_SHARED_WALLET_FILE) to the bundle as
+ * `/shared-wallet.ngw`, and `define`s the password global from
+ * FESTIPOD_SHARED_WALLET_PASSWORD. Empty password → no shared wallet configured
+ * → the gate falls back to the plain flow.
+ */
+
+// Build-injected global (not `process.env`, absent in the browser); any path
+// that doesn't inject it reads `undefined` → '' safely (no ReferenceError).
+declare global {
+  // eslint-disable-next-line no-var
+  var __FESTIPOD_SHARED_WALLET_PASSWORD__: string | undefined;
+}
+
+export const SHARED_WALLET_PASSWORD: string = globalThis.__FESTIPOD_SHARED_WALLET_PASSWORD__ ?? '';
+
+/** URL of the shared wallet file in the bundle (copied by build.ts). */
+export const SHARED_WALLET_FILE_URL = '/shared-wallet.ngw';
+
+/** Standalone NextGraph wallet app — where the import actually happens. */
+export const WALLET_IMPORT_URL = 'https://nextgraph.eu/#/wallet/login';
+
+/** Whether Festipod has a shared wallet to hand over (drives the assisted UI). */
+export const hasSharedWallet = (): boolean => SHARED_WALLET_PASSWORD.trim().length > 0;

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

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

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

@@ -13,7 +13,6 @@ import type { FestipodWorld } from '../../../../shared/support/world';
 const SCREEN_MARKERS: Record<string, string> = {
   'home': 'Festipod',
   'events': 'Découvrir',
-  'login': 'connecter',
   'profile': 'Mon profil',
   'create-event': "Relayer un événement",
   'settings': 'Paramètres',
@@ -35,7 +34,6 @@ function pathForScreen(screenId: string): string {
     case 'home': return '/home';
     case 'events': return '/events';
     case 'create-event': return '/events/new';
-    case 'login': return '/login';
     case 'profile': return '/profile';
     case 'edit-profile': return '/profile/edit';
     case 'friends-list': return '/profile/friends';

src/modules/auth/steps/ui/barriere-acces.steps.ts

@@ -0,0 +1,101 @@
+/**
+ * @ui steps for the access barrier (AccessGateScreen).
+ *
+ * These render the prop-driven AccessGateScreen directly (via renderElement) —
+ * it is NOT a registry/route screen, its state comes from props (status,
+ * initialIdentifier, onEnter). We assert on the rendered DOM: the identifier
+ * field is PREFILLED from the stored value, and "Entrer" reports the identifier.
+ *
+ * Guards the reported regression: on return the barrier used to re-ask for a
+ * bare, empty identifier despite one being stored. See AuthGate.tsx.
+ */
+import { Given, When, Then } from '@cucumber/cucumber';
+import { expect } from 'chai';
+import React from 'react';
+import { renderElement } from '../../../../shared/test-harness/renderHelper';
+import { AccessGateScreen } from '../../screens/AccessGateScreen';
+import type { FestipodWorld } from '../../../../shared/support/world';
+
+// Local per-scenario state (kept off the World to avoid touching its type).
+interface GateState {
+  doc: Document | null;
+  entered: string | null;
+}
+const gateStates = new WeakMap<object, GateState>();
+function stateFor(world: object): GateState {
+  let s = gateStates.get(world);
+  if (!s) {
+    s = { doc: null, entered: null };
+    gateStates.set(world, s);
+  }
+  return s;
+}
+
+async function renderGate(world: object, initialIdentifier?: string): Promise<void> {
+  const s = stateFor(world);
+  s.entered = null;
+  // 'connecting' would disable the button; 'disconnected' is the returning-user
+  // state (session not yet restored) — the exact case that re-prompted before.
+  s.doc = await renderElement(
+    React.createElement(AccessGateScreen, {
+      status: 'disconnected',
+      initialIdentifier,
+      onEnter: (id: string) => {
+        s.entered = id;
+      },
+    }),
+  );
+}
+
+Given(
+  'la barrière d\'accès s\'affiche avec l\'identifiant stocké {string}',
+  async function (this: FestipodWorld, identifier: string) {
+    await renderGate(this, identifier);
+  },
+);
+
+Given(
+  'la barrière d\'accès s\'affiche sans identifiant stocké',
+  async function (this: FestipodWorld) {
+    await renderGate(this, '');
+  },
+);
+
+function identifierField(world: object): HTMLInputElement {
+  const s = stateFor(world);
+  expect(s.doc, 'The access barrier should be rendered').to.not.be.null;
+  const input = s.doc!.querySelector('[data-testid="identifier-input"]') as HTMLInputElement | null;
+  expect(input, 'The identifier field should be present').to.not.be.null;
+  return input!;
+}
+
+Then(
+  'le champ identifiant contient {string}',
+  function (this: FestipodWorld, expected: string) {
+    expect(identifierField(this).value).to.equal(expected);
+  },
+);
+
+Then('le champ identifiant est vide', function (this: FestipodWorld) {
+  expect(identifierField(this).value).to.equal('');
+});
+
+When('je clique sur {string} dans la barrière', function (this: FestipodWorld, _label: string) {
+  const s = stateFor(this);
+  const input = identifierField(this);
+  // Submit via Enter on the field (canEnter is satisfied by the prefilled value).
+  const KeyboardEventCtor = (globalThis as { KeyboardEvent?: typeof KeyboardEvent }).KeyboardEvent;
+  const evt = KeyboardEventCtor
+    ? new KeyboardEventCtor('keydown', { key: 'Enter', bubbles: true })
+    : Object.assign(new (globalThis as { Event: typeof Event }).Event('keydown', { bubbles: true }), { key: 'Enter' });
+  input.dispatchEvent(evt);
+  expect(s.doc, 'The access barrier should be rendered').to.not.be.null;
+});
+
+Then(
+  'l\'identifiant remonté à l\'application est {string}',
+  function (this: FestipodWorld, expected: string) {
+    const s = stateFor(this);
+    expect(s.entered, 'onEnter should have been called with the identifier').to.equal(expected);
+  },
+);

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

@@ -1,27 +0,0 @@
-import { Then } from '@cucumber/cucumber';
-import { expect } from 'chai';
-import type { FestipodWorld } from '../../../../shared/support/world';
-
-Then('l\'écran gère la redirection automatique après connexion', async function (this: FestipodWorld) {
-  // Behavioral — covered by the @e2e scenario
-  // "L'écran de connexion redirige vers l'accueil si déjà connecté".
-  // At the @ui layer we only verify the screen mounts cleanly.
-  expect(this.currentScreenId).to.equal('login');
-  expect(this.renderedDoc, 'Login screen should render').to.not.be.null;
-});
-
-Then('l\'écran gère l\'état de connexion en cours', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  const hasConnectingState =
-    source.includes("status === 'connecting'") ||
-    source.includes("Connexion NextGraph en cours");
-  expect(hasConnectingState, 'LoginScreen should handle connecting state').to.be.true;
-});
-
-Then('l\'écran n\'importe pas de données de démonstration', async function (this: FestipodWorld) {
-  const source = this.getRenderedText();
-  const importsSeedData = source.includes('seedData') || source.includes('seedEvents');
-  const usesFestipodData = source.includes('useFestipodData');
-  expect(importsSeedData, 'LoginScreen should not import seed data').to.be.false;
-  expect(usesFestipodData, 'LoginScreen should not use FestipodData context').to.be.false;
-});

src/modules/auth/steps/ui/identifiant-resolution.steps.ts

@@ -0,0 +1,111 @@
+/**
+ * @ui steps for AccountContext identifier resolution.
+ *
+ * Guards the cross-frontier fix: the shared-wallet flow runs the app in TWO
+ * localStorage partitions (top-level 127.0.0.1 vs broker iframe nextgraph.net),
+ * so localStorage does NOT cross. The `?id=` URL param — embedded in the broker
+ * redirect `o=` — DOES cross. AccountContext resolution therefore PRIORITIZES the
+ * URL param over localStorage, and (when present) persists it to localStorage for
+ * same-partition convenience. Normalization (trim, `@`-strip, lowercase) applies.
+ *
+ * These render a tiny probe inside a real AccountProvider (via renderElement),
+ * having first seeded window.location.search and window.localStorage through the
+ * happy-dom harness — so the resolution logic runs for real, not mocked.
+ */
+import { Given, When, Then } from '@cucumber/cucumber';
+import { expect } from 'chai';
+import React from 'react';
+import {
+  renderElement,
+  setRenderUrl,
+  setRenderLocalStorage,
+  getRenderLocalStorage,
+} from '../../../../shared/test-harness/renderHelper';
+import { AccountProvider, useAccount } from '../../../../shared/context/AccountContext';
+import type { FestipodWorld } from '../../../../shared/support/world';
+
+const STORAGE_KEY = 'festipod.account.identifier';
+
+// Per-scenario intent (kept off the World type via a WeakMap).
+interface ResolveState {
+  storageSeed: string | null;
+  url: string;
+  doc: Document | null;
+}
+const states = new WeakMap<object, ResolveState>();
+function stateFor(world: object): ResolveState {
+  let s = states.get(world);
+  if (!s) {
+    s = { storageSeed: null, url: 'http://localhost/', doc: null };
+    states.set(world, s);
+  }
+  return s;
+}
+
+// Probe: renders the resolved identifier so the DOM can be asserted.
+function IdentifierProbe(): React.ReactElement {
+  const { identifier } = useAccount();
+  return React.createElement('div', { 'data-testid': 'resolved-identifier' }, identifier ?? '');
+}
+
+Given(
+  'localStorage contient l\'identifiant {string}',
+  function (this: FestipodWorld, value: string) {
+    stateFor(this).storageSeed = value;
+  },
+);
+
+Given('localStorage ne contient aucun identifiant', function (this: FestipodWorld) {
+  stateFor(this).storageSeed = null;
+});
+
+Given('l\'URL porte le param id {string}', function (this: FestipodWorld, id: string) {
+  const s = stateFor(this);
+  const url = new URL('http://localhost/');
+  url.searchParams.set('id', id);
+  s.url = url.toString();
+});
+
+Given('l\'URL ne porte aucun param id', function (this: FestipodWorld) {
+  stateFor(this).url = 'http://localhost/';
+});
+
+When('le contexte de compte résout l\'identifiant', async function (this: FestipodWorld) {
+  const s = stateFor(this);
+  // Seed the happy-dom window (URL + localStorage) BEFORE mounting the provider,
+  // so the provider's init-time resolution reads exactly this state.
+  await setRenderUrl(s.url);
+  await setRenderLocalStorage(STORAGE_KEY, s.storageSeed);
+  s.doc = await renderElement(
+    React.createElement(AccountProvider, null, React.createElement(IdentifierProbe)),
+  );
+});
+
+function resolved(world: object): string {
+  const s = stateFor(world);
+  expect(s.doc, 'The probe should be rendered').to.not.be.null;
+  const el = s.doc!.querySelector('[data-testid="resolved-identifier"]');
+  expect(el, 'The resolved-identifier probe should be present').to.not.be.null;
+  return el!.textContent ?? '';
+}
+
+Then('l\'identifiant résolu est {string}', function (this: FestipodWorld, expected: string) {
+  expect(resolved(this)).to.equal(expected);
+});
+
+Then(
+  'localStorage contient désormais l\'identifiant {string}',
+  async function (this: FestipodWorld, expected: string) {
+    // The URL-param → localStorage persistence runs in a mount useEffect, which
+    // React flushes AFTER the render's first microtask. Yield a few macrotask
+    // ticks (bounded, no polling of any live resource) so the effect has run
+    // before asserting — otherwise the read races the effect and flakes.
+    let stored: string | null = null;
+    for (let i = 0; i < 10; i++) {
+      stored = await getRenderLocalStorage(STORAGE_KEY);
+      if (stored === expected) break;
+      await new Promise((r) => setTimeout(r, 0));
+    }
+    expect(stored).to.equal(expected);
+  },
+);