Aller au contenu
rebond

Pour les développeurs

Rebond est un monorepo TypeScript (pnpm + Turbo, Effect 4, Postgres). Cette section s’adresse à qui veut lire le code, brancher un outil sur l’API ou préparer l’import d’un club.

L’architecture en bref

Section intitulée « L’architecture en bref »
  • packages/domain porte toutes les règles métier : commandes, requêtes et erreurs typées. C’est le seul endroit où une règle est écrite.
  • apps/api (GraphQL) et apps/mcp (serveur MCP) sont des adaptateurs minces au-dessus des mêmes commandes : aucune règle n’y vit.
  • apps/desk (l’accueil du club) et apps/player (l’application joueur, sur téléphone) parlent à l’API GraphQL.
  • apps/worker relaie les événements du domaine : chaque mutation écrit un domain_event dans la même transaction, et les autres modules y réagissent.
  • Un club par hôte : le club vient du nom d’hôte (bo.localhost en local, un sous-domaine ou un domaine personnalisé ensuite). Chaque table métier porte un club_id et la sécurité au niveau des lignes de Postgres (RLS) limite chaque requête au club courant. Rien ne tourne en propriétaire des tables : l’api, le serveur MCP et le worker se connectent avec des rôles soumis à la RLS (booker_app_login, booker_worker_login) et refusent de démarrer sinon ; bo doctor le vérifie.
  • L’argent est en centimes entiers, dans un journal en ajout seul, chaîné par empreintes.

Le vocabulaire du domaine est dans CONTEXT.md, les décisions dans docs/adr/, la manière d’écrire le code dans docs/conventions.md.

Lancer Rebond en local

Section intitulée « Lancer Rebond en local »

Il faut Node 24, pnpm 10 et Docker.

Fenêtre de terminal
pnpm install
pnpm bo doctor        # vérifie la machine et écrit .ports pour ce worktree
pnpm bo db up         # Postgres 17 + Mailpit (boîte mail de dev) dans Docker
pnpm bo db migrate && pnpm bo e2e setup
pnpm bo dev           # api, worker, mcp, desk, player

Les ports dépendent du worktree : lisez .ports, ne supposez jamais un port fixe.

  • Accueil : http://bo.localhost:<DESK_PORT>, avec thibault@bo.test / booker-dev.
  • Application joueur : http://bo.localhost:<PLAYER_PORT>, avec le membre de démonstration lea.martin@example.test (pnpm bo auth login lea.martin@example.test). Les liens de connexion arrivent dans Mailpit (pnpm bo mail last).
  • Tests : pnpm bo test all (biome, typecheck, Vitest contre Postgres, Playwright, puis le site). La CI tourne sur la machine d’Arnaud : pnpm bo ci <pr> construit le candidat (la PR squashée sur main) et y lance les mêmes étapes en parallèle, puis Playwright sur les specs que le diff peut toucher (choisies par Claude Haiku ; celles déjà vertes sur les mêmes fichiers sont sautées, les échecs précédents passent en premier, le reste en parts parallèles) et une revue de code par Claude Code, et pose les statuts gate et merge-ready ; bo merge <pr> est la file de fusion : jusqu’à 4 PR en attente sont squashées l’une sur l’autre au-dessus de main, testées comme un seul candidat, puis main avance jusqu’à lui (main vert par construction ; en cas d’échec le lot est coupé en deux, et la PR qui échoue seule sort de la file). Un arbre déjà testé vert le même jour sur le même main n’est pas retesté.

Dans cette section

Section intitulée « Dans cette section »