tribunal-app/CLAUDE.md

@AGENTS.md

Le Tribunal

Application web pour un groupe d'amis (~12 personnes) qui anime un jeu et des olympiades pendant une semaine de vacances : comptes, rôles, leaderboard en direct, attribution de points par des juges, journal public des événements. Ré-thématisable par édition (un thème différent chaque année).

1. État actuel

V1, V2 et V3 sont livrées :

• V1 : comptes, profils, leaderboard statique.
• V2 : authentification par email réel (plus de pseudo+email interne), rôles public/judge, verrou de pseudo (modifiable une fois), section Administration.
• V3 : attribution de points par les juges (RPC sécurisée, +/- avec confirmation explicite), journal public « le crieur », podium top 3, flèches de progression, recadrage/compression photo côté client.

Hors périmètre pour l'instant (voir roadmap en fin de doc) : éditions/thèmes, le jeu du Tribunal lui-même (Char, roulette, ostracisme, timer du Gardien), mode grand écran.

---

2. Stack technique

• Framework : Next.js 16 (App Router) + TypeScript
• Style : Tailwind CSS v4 (design tokens en variables CSS, voir globals.css)
• Auth + Base + Stockage + Temps réel : Supabase (Auth, Postgres, Storage, Realtime)
• Recadrage photo : react-easy-crop + canvas natif (resize/compression client, jamais d'upload de l'image brute)
• Déploiement : Vercel (front) + Supabase (managé) — pas encore déployé, tourne en local pour l'instant

Next.js 16 a renommé middleware.ts en proxy.ts (fichier src/proxy.ts, fonction proxy). src/lib/supabase/middleware.ts est un nom de fichier utilitaire interne, sans rapport avec cette convention.

---

3. Modèle de données (supabase/schema.sql, source de vérité)

Le script est idempotent : toujours le ré-exécuter en entier après une modification, jamais de migration incrémentale séparée.

public.profiles (liée à auth.users, créée automatiquement par un trigger sur auth.users)

Colonne	Notes
id	= auth.users.id
pseudo	affiché partout, unique (insensible à la casse)
avatar_url	URL publique Storage ({user_id}.webp)
points	jamais modifiable directement — uniquement via RPC award_points
role	public (défaut) ou judge
pseudo_locked	passe à true automatiquement au 1er changement de pseudo
previous_rank	repère de classement, mis à jour par reset_rank_reference()

public.points_log (journal, lecture seule côté client)

id, target_id, judge_id, delta, reason, created_at — écrit uniquement par la RPC award_points.

Colonnes sensibles : RLS + trigger, jamais confiance au client

La RLS est au niveau ligne : elle ne peut pas exprimer « cette colonne seulement si tel rôle ». Le verrouillage fin des colonnes (role, points, pseudo_locked, pseudo figé, previous_rank) passe par le trigger enforce_profile_update() :

• points : bloqué pour tout le monde, y compris les juges, en écriture directe. Seule la RPC award_points() (SECURITY DEFINER) peut la modifier, via un flag de session (app.bypass_points_lock) qui autorise explicitement CETTE écriture précise.
• role, previous_rank : modifiables uniquement par un judge.
• pseudo : modifiable une fois par le propriétaire (auto-lock ensuite), ou à tout moment par un judge.
• auth.uid() is null (SQL Editor, migrations) bypass le trigger : ces accès sont déjà fiables par construction.

Ce pattern (RLS pour l'accès à la ligne + trigger BEFORE UPDATE pour l'accès aux colonnes) est la convention du projet — le reproduire pour toute nouvelle colonne sensible plutôt que d'inventer autre chose.

RPC exposées

• is_pseudo_taken(p_pseudo) — anon + authenticated, ne renvoie qu'un booléen (l'anon ne peut pas lire profiles).
• award_points(p_target_id, p_delta, p_reason) — authenticated, vérifie role = 'judge' côté serveur, jamais côté client.
• reset_rank_reference() — authenticated, vérifie role = 'judge', fige le classement courant dans previous_rank.

---

4. Authentification

Email + mot de passe (Supabase Auth impose l'unicité de l'email). Confirmation d'email activée — nécessite un SMTP custom configuré côté Supabase (le service intégré est trop limité en volume, voir README). Le pseudo est un simple nom d'affichage stocké dans profiles, jamais l'email n'est montré aux autres membres.

---

5. Pages & navigation

Route	Contenu
/	Redirige vers /leaderboard si connecté, sinon /login
/login	Email + mot de passe
/signup	Email + mot de passe + pseudo + photo (recadrée) ; gère l'attente de confirmation email
/leaderboard	Podium top 3 + liste, Realtime, contrôles de points pour les juges
/journal	« Le crieur » — fil live des attributions de points, lecture pour tous
/profile	Pseudo (verrouillable), photo, déconnexion
/admin	Juges uniquement, vérifié côté serveur (Server Component) — gestion des membres, reset du repère de classement

/leaderboard, /profile, /admin, /journal sont protégées par src/proxy.ts (redirection /login si non connecté). L'accès juge-only de /admin n'est pas géré par le proxy (il n'a pas facilement le rôle) — c'est la page elle-même qui vérifie et redirige.

---

6. Look & feel

Design tokens en variables CSS (globals.css) : --navy #0F2748, --gold #C9A227, --ivory #F4ECD8, --ink #2A2116. Ne jamais coder une couleur en dur dans un composant — passer par ces tokens pour que le re-thème par édition reste possible.

Convention de carte : rounded-xl border border-navy/10 bg-white shadow-sm (formulaires, podium) ou rounded-lg pour les lignes de liste. Bouton primaire : bg-navy text-ivory hover:bg-navy/90. Bouton secondaire : border border-navy/20 hover:bg-navy/5.

---

7. Conventions

• Toujours passer par les policies RLS + trigger ; ne jamais exposer la service_role key côté client.
• Toute nouvelle colonne sensible sur profiles (ou une future table) suit le pattern RLS+trigger de la section 3, pas un grant/revoke par colonne (qui ne peut pas distinguer les rôles applicatifs).
• Aperçus locaux d'image avant upload (crop, fichier choisi) = blob:/data: URL → toujours unoptimized sur next/image ou une balise <img> classique (next/image ne sait pas résoudre ces schémas côté serveur).
• Commandes : npm run dev, npm run build, npm run lint.
• Le schéma SQL (supabase/schema.sql) est la seule source de vérité pour la base — le tenir à jour à chaque changement de données/sécurité, et le garder idempotent.

---

8. Roadmap (pas encore codé)

• Éditions & thèmes : table editions (année, thème, mood board, vocabulaire) ; les points deviendront rattachables à une édition.
• Le jeu du Tribunal : le Char (zone de pénalité), batailles de cul sec, ostracisme, roulette, timer du Gardien.
• Mode grand écran : vue leaderboard optimisée pour vidéoprojecteur.
• Déploiement : pas encore fait (Vercel + Supabase managé prévus, voir README).