Frontend : consommation de l'API CRUD (matrice, affectations, validation)
Remplace le magasin d'état fabriqué par une vraie couche API typée, alignée
sur le back-end (Étape 5) :
- src/api/ : schema.ts (miroir de backend/app/api/schemas.py), client HTTP,
implémentation mock en mémoire (même surface + portage du moteur de
validation), sélection mock/http via VITE_API_MODE, hooks React Query
(lectures + mutations avec invalidation).
- Grille des besoins ← GET /matrix ; treillis de colonnes dérivé des
créneaux réels (plus de plages figées).
- Panneau d'affectation ← GET /assignments?shift_id, POST /assignments/validate
par candidat (alertes bloquantes / avertissements du moteur),
POST / PATCH / DELETE /assignments.
- Vue par bénévole ← volunteers + shifts + assignments (surcharge / oubliés
calculés côté client).
- Confirmations (ex-« Publication ») ← affectations PROPOSED ; publication
versionnée et emails signalés hors périmètre.
- Mobiles ← assignments filtrées ; confirmation = PATCH ; pointage référent
local (hors périmètre).
- Configuration ← positions & shifts CRUD (min/idéal, ajout/retrait),
volunteers CRUD dont suppression RGPD ; messages = maquette locale.
- i18n mis à jour, aucun texte d'interface en dur.
- Vérifs : build tsc + vite, eslint (0 problème), npm run smoke (API mock +
rendu headless des 6 écrans avec données préchargées).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AwswqSChc3Rwtu61pRXiY2
