Initialisation du projet photobooth-qr

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014akYEuf44fM6EiUvrmoBzS

CLAUDE.md

@@ -0,0 +1,65 @@
+# 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`).