photobooth-qr/CLAUDE.md

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).