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

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

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

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

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

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

Known red: `@data` cannot be measured. The served wallet accumulates and
nothing resets it; moving the browser profile aside does not, since the data
lives in the wallet file, not the profile.
2026-08-16 12:33:14 +02:00
2026-01-18 11:53:42 +01:00
2026-01-18 11:53:42 +01:00
2026-01-18 11:53:42 +01:00
2026-01-18 11:53:42 +01:00
2026-01-18 11:53:42 +01:00
2026-01-18 11:53:42 +01:00

Festipod

Festipod permet aux utilisateurs de créer des points de rencontre qui viennent se « greffer » sur des événements publics existants. L'objectif est de favoriser les rencontres autour de ces événements.

L'événement public (festival, conférence, salon…) n'est qu'un prétexte et un point d'ancrage temporel et géographique : la valeur produite par l'app, c'est le point de rencontre que les utilisateurs viennent y greffer pour se retrouver.

Application web mobile-first. Stack : Bun + React + NextGraph (P2P, local-first, chiffré de bout en bout).

Modèle fonctionnel

Tous les utilisateurs sont authentifiés — il n'y a pas d'accès anonyme à l'app.

Acteurs

  • Utilisateur — toute personne ayant un compte (un wallet NextGraph). Tous les acteurs ci-dessous sont des spécialisations d'un utilisateur dans un contexte donné.
  • Connexion (« ami ») — un autre utilisateur avec qui je suis connecté. Sert à scoper les listes (« mes amis qui participent à… ») et la confiance.
  • Déclarant d'un événement — l'utilisateur qui a inséré l'événement dans Festipod. N'est pas (forcément) un organisateur de l'événement réel : c'est juste quelqu'un qui le référence pour que d'autres puissent y attacher des points de rencontre.
  • Hôte d'un point de rencontre — l'utilisateur qui a créé un point de rencontre rattaché à un événement.
  • Inscrit à un point de rencontre — un utilisateur qui s'est inscrit à un point de rencontre. De fait, il devient participant à l'événement parent.
  • Membre d'une communauté d'intérêt — un utilisateur abonné à une communauté pour découvrir les événements qu'elle référence.

Concepts métier

  • Point de rencontrel'unité de valeur de l'app. Un moment de rencontre proposé par un hôte à un endroit et à un horaire donnés, greffé sur un événement public. C'est ce à quoi on s'inscrit (on ne s'inscrit pas à un événement). Sans points de rencontre, un événement Festipod n'a pas d'intérêt.
  • Événement — l'ancrage. Un événement public réel (festival, conférence, salon, exposition…) référencé dans Festipod pour servir de support à des points de rencontre. C'est simplement un prétexte (titre, dates, lieu, thèmes) ; le déclarant n'est pas l'organisateur officiel de l'événement, juste celui qui l'a inscrit dans Festipod.
  • Communauté d'intérêt — un groupement thématique d'utilisateurs. Sert principalement à découvrir des événements (via abonnement) et à délimiter les périmètres de référencement.
  • Liste curated — une liste d'événements éditorialisée (par un utilisateur ou une communauté), distincte de « les événements que j'ai déclarés » ou « les événements de la communauté ». Permet d'organiser/recommander.
  • Connexion — lien de confiance entre deux utilisateurs (équivalent « ami »).

Fonctionnalités actuelles

Implémentées dans le code (écrans visibles via le router) :

  • Authentification via wallet NextGraph
  • Cycle de vie d'événement (déclaration, consultation, mise à jour)
  • Cycle de vie de point de rencontre (rattaché à un événement)
  • Inscription / désinscription à un point de rencontre
  • Liste des participants à un événement
  • Profil utilisateur, mise à jour, partage de profil
  • Liste d'amis (connexions)
  • Profil d'un autre utilisateur

Voir l'inventaire des routes et des écrans dans le concept app-architecture.

Défis ouverts

  • Déduplication des événements en infra décentralisée. NextGraph étant P2P, rien n'empêche deux utilisateurs de déclarer indépendamment le même événement public (par ex. « Eurockéennes 2027 ») et de produire deux entrées distinctes. La dispersion qui en résulte fragmente les points de rencontre greffés et réduit leur visibilité — ce qui va à l'encontre de la fonction première de l'app. Pistes envisagées, non tranchées :
    • proposer à l'utilisateur, lors de la déclaration, les événements déjà déclarés dans son réseau / ses communautés qui correspondent à sa saisie (recherche avant création) ;
    • utiliser un identifiant externe canonique (URL officielle de l'événement, Wikidata, schema.org/Event) pour reconnaître les doublons et les présenter comme un seul événement à l'affichage ;
    • laisser des curators (humains ou communautaires) fusionner / vetter les entrées canoniques.

Évolutions à venir

Identifiées comme nécessaires (notamment pour la scalabilité et la découverte) mais pas encore implémentées :

  • Abonnement à une communauté d'intérêt pour découvrir ses événements (mécanisme de discovery distribué).
  • Abonnement à un utilisateur pour suivre les événements qu'il déclare (sans nécessairement être ami).
  • Listes curated — créer et partager des sélections d'événements éditorialisées.
  • Multi-utilisateurs collaboratif : aujourd'hui chaque utilisateur a ses données isolées dans son wallet. Le passage en mode collaboratif (un point de rencontre vu par plusieurs personnes) suppose un refactor de la couche données. Voir le concept nextgraph-platform (briefs multi-store, matrice d'autorisations, wallet partagé, fork inbox).

Quick Start

bun install
bun run dev              # Dev server avec HMR (port 3000)

Commandes utiles

bun run build            # Build production vers dist/
bun run storybook        # Parcourir écrans et composants
bun run test:cucumber    # Tests BDD
bun run features:parse   # Régénérer features.ts depuis les .feature
bun run steps:extract    # Extraire les step definitions pour les tooltips
bun run build:orm        # Régénérer l'ORM depuis les SHEX shapes

Documentation

  • AGENTS.md — cœur : but produit, invariants, carte des 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.
S
Description
No description provided
Readme 5.6 MiB
Languages
TypeScript 90.8%
Gherkin 6.3%
CSS 1.9%
Shell 0.8%
HTML 0.1%