# CLAUDE.md — photobooth-qr

## Contexte

Application web de galerie photo événementielle par QR code.

Principe : les invités d'un événement (mariage, soirée, etc.) scannent un QR
code, arrivent sur une page d'upload, et déposent leurs photos/vidéos qui
atterrissent dans une galerie consultable par l'organisateur/admin. À la fin,
l'admin peut exporter toutes les photos en ZIP.

Développé par **Kévin Lecou**, auto-entrepreneur, mixologue (projet
**Rêves Liquides**). Ce projet est distinct de Rêves Liquides mais peut lui
servir d'outil.

- **V1** : usage personnel de Kévin (ses propres événements / tests).
- **V2 / V3** : vente du service à des clients externes (mariages,
  événementiel professionnel). Le projet doit donc être pensé dès le début
  pour être **multi-clients et réutilisable**, sans pour autant sur-ingénierer
  la V1.

## Stack imposée

- **Supabase** pour la base de données (Postgres) et le stockage (Storage).
- **Front léger, mobile-first, sans framework lourd** (pas de React/Vue/Next
  sauf décision contraire explicite plus tard). HTML/CSS/JS vanilla ou
  micro-lib, en priorité.
- **Pas d'application native.**
- **Pas de compte invité** : les invités uploadent sans créer de compte,
  sans authentification.

## Contraintes non négociables

1. **Écoconception**
   - Compression image **côté client obligatoire** avant upload (jamais
     envoyer une photo brute non compressée vers Supabase Storage).
   - Minimiser le nombre de requêtes réseau et le poids des pages.
   - Toujours proposer, par défaut, le choix le plus sobre en dépendances
     et en requêtes réseau — pas de librairie ajoutée "par confort" si une
     solution native (fetch, Canvas API, etc.) suffit.

2. **RGPD**
   - Mention légale obligatoire sur la page d'upload (voir `docs/rgpd.md`).
   - Suppression automatique des données (photos + métadonnées) à échéance
     fixée (voir `docs/decisions.md` pour la règle exacte : J+7 après la
     date de l'événement, indépendamment du téléchargement du ZIP).

3. **Pas de dette technique inutile**
   - Le projet est pensé pour durer et être réutilisé sur plusieurs clients
     (multi-tenant logique via la table `events`).
   - Éviter les raccourcis qui compliqueraient le passage V1 → V2/V3
     (ex : éviter de hardcoder des valeurs propres à un seul événement).
   - Mais ne pas sur-architecturer non plus : pas de fonctionnalité pour un
     besoin hypothétique non encore confirmé par Kévin.

## Mode de collaboration

- **Avant toute décision structurante** (schéma de base de données,
  mécanisme d'authentification/admin, choix d'hébergement, changement de
  stack), **demander confirmation à Kévin** avant de trancher seul et
  d'implémenter. Proposer les options avec leurs compromis, pas juste une
  question ouverte.
- Toute décision actée est à consigner dans `docs/decisions.md`.
- Ne pas inventer de credentials, URLs, ou valeurs de config manquantes —
  demander si besoin (cf. règle globale dans `~/.claude/CLAUDE.md`).