festipod/AGENTS.md

Festipod

Web app mobile-first où les utilisateurs créent des points de rencontre qui se greffent sur des événements publics existants, pour favoriser les rencontres. L'événement n'est qu'un prétexte/ancrage ; la valeur, c'est le point de rencontre — on s'inscrit à un point de rencontre ou directement à un événement ; être inscrit à un de ses points de rencontre inscrit à l'événement. Stack : Bun + React + NextGraph (P2P, local-first, chiffré).

Invariants à toujours garder

• Architecture feature-based : le code est organisé par domaine métier, pas par couche technique.

  src/modules/{event,user,home,auth,workshop,meeting,notification}/
  src/shared/          # Composants, context, data — importable par tous les modules
  src/app/             # App shell (router, providers, entrée)
  src/screens/index.ts # Registre d'écrans (utilisé par Storybook)
  

• Un module n'importe QUE depuis shared/ — jamais d'un autre module. C'est l'invariant qui rend l'archi réelle.
• Bun-first : bun / bun install / bun test / bun build, jamais node/npm/vite/jest. pnpm dev (port fixe, PORT du .env racine, défaut 4005 ; même défaut pour pnpm start).

Frontière SDK

Le SDK de données de Festipod est @ng-eventually/polyfill, injecté une seule fois via ngSession.configure(...).

L'engagement que le fournisseur publie est tiré dans ce repo et épinglé : data-layer, fiche contract_polyfill-surface. C'est la seule référence. On n'ouvre jamais les sources du fournisseur ni sa copie dans node_modules, pas même pour vérifier une signature. Ce que le contrat ne dit pas, ce repo ne le sait pas : un manque est remonté au fournisseur, jamais contourné ici ni documenté ici. Vaut aussi pour les tests, qui valident Festipod et jamais le SDK (bdd-testing, rule_tests-validate-festipod-not-the-sdk).

Le contrat se re-tire à chaque montée de version : python3 ~/projects/skills/concept/contracts.py pull (dérive : … check). Sa surface rétrécit — un symbole retiré est du code que l'app supprime, pas une régression à amortir.

Ne jamais décrire dans ce repo comment la couche de données est implémentée. La doctrine Festipod décrit uniquement le contrat + comment Festipod l'utilise + le domaine + l'architecture + le contrat BDD.

Doctrine du projet — concepts (livrée automatiquement)

La connaissance détaillée vit dans .project/concepts/ (système concept) : fiches courtes, typées, livrées par un hook quand tu touches leur territoire — tu n'as pas à les charger d'avance. Les 6 concepts :

Concept	Couvre
functional-domain	Modèle produit : point de rencontre, acteurs, concepts métier, périmètres public/protected/private par entité, découverte, défi déduplication
app-architecture	Modules, invariant d'imports, app shell, routing path-based, écrans
tech-stack	Bun-first, APIs Bun, build pipeline, commandes
data-layer	Persistance via le SDK @ng-eventually/polyfill : entités-documents par scope, shapes SHEX/ORM, modes connected/demo, pièges
bdd-testing	Cucumber multi-couches FR, contrat @ui/@data/@e2e, harness broker, cookbook
app-security	Isolation déléguée au SDK (pas de contrôle d'accès dans les écrans), auth wallet, matrice d'autorisations cible

Pour documenter un fait projet : /concept document <sujet> (ne pas écrire en libre dans .project/).

Rules

@.project/rules/INDEX.md