Prompt de lancement - Sprint 07

Copier-coller ce prompt pour démarrer une session dédiée au Sprint 07 (ou utilisé par l'agent programmé à 16h15).

Tu démarres le Sprint 07 de la plateforme MJY Holding (branche de travail dev/perf). Le Sprint 06 (observabilité + export) est clôturé - voir docs/sprints/sprint_06/sprint_review.md.

Avant tout, lis : docs/sprints/sprint_07/sprint_backlog.md et docs/sprints/sprint_07/tasks.md (source de vérité du périmètre), ainsi que docs/features/propositions_nouvelles_fonctionnalites.md (§1.A, §1.C, §2.B) et docs/ADR/ADR_0002_authentification_supabase_native.md.

Objectif du sprint

Livrer les fonctionnalités demandées mais pas encore intégrées autour du compte utilisateur :

1. Bloc 1 - Compte & profil (engagement ferme) : page Profil (consultation + édition nom/email), changement de PIN renforcé (ancien PIN requis), édition des emails par le super-admin (US1.3, Admin API).
2. Bloc 2 - Notifications « tâche à valider », sans Firebase : in-app temps réel via Supabase Realtime (US7-NOTIF-04, engagement ferme) puis Web Push navigateur/PWA via VAPID (US7-NOTIF-05, peut déborder - Service Worker minimal, table push_subscriptions, envoi via web-push).
3. Bloc 3 - Report (peut déborder) : validation import par les chefs (après vendredi soir).

Commence par le Bloc 1.

Contraintes d'architecture (non négociables)

• Auth Supabase native (auth.users + bcrypt géré par Supabase) : aucun hashage manuel. Le PIN = mot de passe du compte (updateUser). Adapter toute spec parlant de « bcrypt côté serveur ».
• Notifications SANS Firebase : Supabase Realtime (in-app) + Web Push standard (VAPID). Firebase seulement pour un futur push mobile natif - hors périmètre.
• Onboarding email automatisé : REPORTÉ (décision PO) - roster conservé, ne pas l'implémenter ce sprint.
• Écran de connexion : roster CONSERVÉ - la proposition §1.B (« écran neutre ») est écartée, ne pas la réintroduire.
• Parité server.js (Express, local/test) ↔ netlify/functions/* (production) sur tout endpoint touché : le contrat /api doit rester iso.
• Déploiement production hors périmètre (sprint dédié ultérieur). Ne pas déployer.
• L'édition d'email auth.users passe par le serveur (Admin API auth.admin.updateUserById), pas côté front.

Décisions à me soumettre (ne pas trancher seul)

• Web Push (US7-NOTIF-05) : gestion des clés VAPID + déclenchement (Database Webhook Supabase vs appel serveur) → rédiger un ADR.
• Édition d'email self-service vs réservée au super-admin (US7-PROF-01 / US7-EMAIL-03).

Méthode de travail

• Implémente par bloc ; écris/maj les tests (Vitest) et fais passer npm run test, npm run test:e2e, npm run build, eslint (0 nouvelle erreur).
• Vérifie en preview réelle (serveurs web + backend de .claude/launch.json, Supabase live) les parcours modifiés - ne demande pas à l'utilisateur de vérifier à ta place.
• Coche les TS7.x dans tasks.md au fur et à mesure ; flag tout conflit/doute au lieu de trancher.
• Ne committe pas sans feu vert ; propose des messages de commit par blocs de fichiers.
• Toute décision d'archi → nouvel ADR dans docs/ADR/.

Tiens-moi informé à chaque fin de bloc.