Livrable 28

Dépôt

Décision

Une seule application, pas le monorepo à quatre apps du prompt.

Le prompt demande d'éviter plusieurs applications si une app organisée suffit, et cite Next.js. Même raisonnement, stack réelle TanStack Start :

docs/
  README.md               # carte du corpus
  brief.md                # brief de phase
  architecture/           # canon 00–30
  adr/                    # ADR-001 … ADR-009
  decisions/              # entrée des arbitrages A1–A8
  agents/                 # notes classées, non canoniques
    product/ city/ experience/ data/ trust/ platform/ delivery/
src/
  routes/                 # URLs françaises ; /architecture lit le canon
  components/
    public/               # shell du client
    atlas/                # lecteur du corpus
  domain/
    city/ places/ events/ offers/ live/ search/ reco/ geo/ content/
    identity/ analytics/ moderation/ billing/ ads/
  styles.css              # feuille du runtime, chemin fixe
  lib/                    # plateforme : auth, db, app-data
server/                   # middleware Nitro du runtime, pas le métier
scripts/                  # outillage du runtime
migrations/               # SQL versionné quand le schéma démarre
public/                   # statique, dont __grok

src/server/ n'existe pas. Le dossier server/ à la racine appartient au runtime (PWA, install). Les fonctions métier, le jour où elles existent, restent sous src/domain/ ou src/routes/, pas dans ce server/.

identity, analytics, moderation, billing et ads sont des modules unavailable : le dossier existe, l'encaissement et la pub ne tournent pas. city, places, events, offers, live, search, reco, geo et content portent la démo étiquetée fixture. Les routes publiques restent des fichiers à plat : l'URL TanStack est le chemin, et src/routes/index.tsx est le contrat de la home.

Pourquoi pas `apps/web` + `apps/pro` + `apps/api`

Choix : un déploiement, une auth, un design system, un schéma.
Alternatives : monorepo dès maintenant (frontières plus dures, trois pipelines, prématuré) ; packages publiés (inutile).
Compromis : la discipline de frontières est humaine. Revue : domain/search n'importe pas domain/ads.
Extraction : workers d'import d'abord, si la durée des jobs gêne le process web. Pas avant mesure.
Multi-ville : aucun dossier orleans/.

Standards quand le code commencera

TypeScript strict. Pas de any sans motif écrit. Validation partagée Zod. Erreurs typées. Pas de constante métier magique (seuils = policy en base ou config validée). Pas de TODO silencieux : un écart va dans le registre des risques ou n'est pas mergé.

Tests prévus : unit (freshness, horaires cross-midnight, ranking sans feature paiement), intégration API, permissions, géo (haversine vs fixture), e2e des parcours du prompt (anonyme search/map/venue, favori, plan, claim, publish, approve, DNA).

Les fixtures de test portent fixture: true et une ville slug fixture-ville, jamais orleans mélangé à du faux inventaire.

Documentation demandée par le prompt

À créer avec l'implémentation, pas en double vide maintenant : README produit, DATABASE, API (OpenAPI), SECURITY, PRIVACY, SEO, DEPLOYMENT, TESTING. Cette phase couvre le fond ; ces fichiers racine pointeront ici plutôt que de diverger.

Décision de nommage