Sylvain Duchesne
df1db790ad
The seam arrived carrying a switching design that no longer holds. It presented runtime hot-switching as what shaped it — selection in state, a key on <Refine> to drop the previous backend's cache — and it read the backend from a build global whose comment claimed build.ts defined it. Nothing ever did, and nothing could have: this project serves from src/ in production too, so that define block never reaches what runs. What replaces it is a URL. The default provider set lives at the root, another behind a path prefix naming it, and moving between them is a link. The reload is the mechanism rather than a cost to avoid: it discards the cache and the session with no code to undo them. So the switch helpers are gone and the file is smaller than what it replaced. The resolution is a pure function with its own tests, including the case that is true today — an empty registry, where every URL is the default. The router does NOT yet strip the prefix, deliberately: it is a shared primitive every screen depends on, the suites that would prove a change to it are not run here, and no URL carries a prefix while one backend is registered. That half lands with the second backend, which is what makes it testable. Three claims the move to this base falsified are corrected too. The inbox the count comment points at is local here, not on another branch. The worked provider implementation is not in this branch's ancestry. And the MeetingPoint shape exists here, so its binding stops being optional — a backend that cannot carry one of the four entities cannot serve the app, and nothing optional should let a half-backend register quietly. Also: both usage declarations are named usage_festipod.md, so the stem is now ambiguous as a link. They are referred to by folder path, and both are listed under publish so each provider can re-find its own if it moves.
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 rencontre — l'unité de valeur de l'app. Un moment de rencontre proposé par un hôte à un endroit et à un horaire donnés, greffé sur un événement public. C'est ce à quoi on s'inscrit (on ne s'inscrit pas à un événement). Sans points de rencontre, un événement Festipod n'a pas d'intérêt.
- Événement — l'ancrage. Un événement public réel (festival, conférence, salon, exposition…) référencé dans Festipod pour servir de support à des points de rencontre. C'est simplement un prétexte (titre, dates, lieu, thèmes) ; le déclarant n'est pas l'organisateur officiel de l'événement, juste celui qui l'a inscrit dans Festipod.
- Communauté d'intérêt — un groupement thématique d'utilisateurs. Sert principalement à découvrir des événements (via abonnement) et à délimiter les périmètres de référencement.
- Liste curated — une liste d'événements éditorialisée (par un utilisateur ou une communauté), distincte de « les événements que j'ai déclarés » ou « les événements de la communauté ». Permet d'organiser/recommander.
- Connexion — lien de confiance entre deux utilisateurs (équivalent « ami »).
Fonctionnalités actuelles
Implémentées dans le code (écrans visibles via le router) :
- Authentification via wallet NextGraph
- Cycle de vie d'événement (déclaration, consultation, mise à jour)
- Cycle de vie de point de rencontre (rattaché à un événement)
- Inscription / désinscription à un point de rencontre
- Liste des participants à un événement
- Profil utilisateur, mise à jour, partage de profil
- Liste d'amis (connexions)
- Profil d'un autre utilisateur
Voir l'inventaire des routes et des écrans dans le concept app-architecture.
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.