feat(loans): confirm declared material state changes

review.md

@@ -23,6 +23,8 @@ Ces décisions s'appliquent à tout le projet, sauf mention contraire.
 | Workflow Git : `develop` comme branche d'intégration + branches dédiées `feat/...`, `fix/...`, `docs/...` | `master` reste figé ; chaque changement logique est isolé sur une branche puis mergé dans `develop`, conformément à `CLAUDE.md`. |
 | Process avant chaque migration : `prisma format` -> `prisma validate` -> `npm run build` -> migration | Détecter toute erreur de schéma/typage avant de toucher la base. |
 | DTO nommés `XxxResponse` (sortie) et `XxxRequest` (entrée) | Le sens est explicite dans le nom. Sortie = mapping (`toXxxResponse`), entrée = validation. |
+| Confirmation responsable uniquement en cas d'écart | Les checklists sont préremplies. Sans modification, le départ ou le retour est automatique ; une différence déclarée reste provisoire jusqu'à la décision du responsable. |
+| Un seul emprunt bloquant par catégorie et par étudiant | La catégorie reste bloquée jusqu'à la clôture du retour, sans limite calendaire après clôture. |
 
 ---
 
@@ -35,11 +37,11 @@ l'historique complet, y compris des étapes devenues obsolètes après brancheme
 |---|---|---|
 | Infrastructure | Terminé | Docker Compose SQL Server + Adminer, monorepo, backend Node/TS, frontend Flutter Web. |
 | Base de données | Terminé pour la V1 | Schéma Prisma 16 entités, migrations, seeds et fixtures de démonstration. |
-| API étudiant | Terminé pour la V1 | Catalogue, détail matériel, création d'emprunt, mes emprunts, restitution, anomalie automatique. |
-| Frontend étudiant | Fonctionnel pour la V1 | Parcours API complet, ordre identification puis choix validé, interface premium et responsive fidèle à la maquette. |
+| API étudiant | À adapter au nouveau workflow | Les parcours automatiques restent valides ; le retour doit être prérempli depuis le départ et les seules différences doivent être mises en attente. |
+| Frontend étudiant | À adapter au nouveau workflow | Interface premium conservée ; préremplissage et écran d'attente à ajouter lorsqu'une valeur est modifiée. |
 | Authentification | Prête pour Azure, démo active | Double mode sécurisé : `x-user-email` seulement en développement, MSAL/OIDC + Bearer JWT en mode Azure. Validation réelle en attente des identifiants Entra ID. |
-| API responsable | Terminé pour la V1 | Dashboard, emprunts, stock, anomalies, notifications, historique et export CSV, avec contrôle du rôle et du campus. |
-| Frontend responsable | Fonctionnel pour la V1 | Espace de supervision responsive avec navigation dédiée, dashboard métier, vues API et export CSV opérationnel. |
+| API responsable | Partielle pour le nouveau workflow | Supervision existante ; confirmation des écarts de départ et de retour à ajouter avec alertes et transitions atomiques. |
+| Frontend responsable | Partiel pour le nouveau workflow | Dashboard existant ; file des écarts, contrôle des checklists et décisions à ajouter. |
 | Tests automatisés | Non démarré | Tests backend/frontend/E2E à ajouter ; tests runtime manuels effectués. |
 | Documentation | Partielle | README principal et documents de conception présents ; OpenAPI, guides utilisateur et captures restent à produire. |
 
@@ -68,7 +70,9 @@ Notes :
 - le wrapper `flutter` peut rester bloqué dans l'environnement Codex ; l'analyse directe avec l'exécutable Dart fonctionne et ne signale aucune erreur ;
 - la compilation Web complète a été validée avec l'exécutable Dart du SDK Flutter et produit `build/web`.
 
-## Scénario de démo validé
+## Scénario de démo historique
+
+> Ce scénario valide toujours les parcours automatiques sans écart. Les branches avec modification de checklist et confirmation responsable restent à implémenter et à tester.
 
 Scénario étudiant validé avec SQL Server Docker et backend compilé :
 
@@ -272,7 +276,8 @@ En terminal interactif (VS Code), `migrate dev` fonctionne normalement (taper `y
 | Tailles de colonnes `@db.NVarChar(n)` | À cadrer | Faible V1, important pour qualité BDD. |
 | Swagger/OpenAPI | À faire | Moyen : utile pour tester/documenter l'API. |
 | Validation réelle Azure AD | En attente des identifiants Entra ID | Fort : le code OIDC/MSAL/JWT est prêt, mais une connexion Microsoft réelle doit encore être testée sur le tenant ENSUP. |
-| Limite d'emprunts actifs par étudiant | À valider métier | Non bloquant V1 ; décision métier non présente dans les règles actuelles. |
+| Blocage d'une catégorie jusqu'à la clôture du retour | Décidé, à implémenter | Fort : contrôle à appliquer atomiquement lors de toute demande d'emprunt. |
+| Confirmation responsable des écarts déclarés | Décidée, à implémenter | Fort : nécessite des statuts conditionnels, alertes, endpoints et écrans de décision. |
 
 ---
 
@@ -458,6 +463,19 @@ En terminal interactif (VS Code), `migrate dev` fonctionne normalement (taper `y
 - Limite actuelle : faute d'identifiants Entra ID, le flux Microsoft réel n'a pas encore pu être exécuté. Le QR sécurisé reste un sous-bloc séparé à développer après le SSO.
 - Commits : `313bb1c`, `530bd52`, `ef31e2a`, `dc208fa`, `36224f3`.
 
+### Étape 48 — Changement métier : confirmation responsable des écarts
+- Décision corrigée après précision métier : le responsable ne valide pas systématiquement chaque départ et chaque retour.
+- Au départ, la checklist est préremplie avec l'état de référence, normalement tous les éléments présents. Sans modification, l'emprunt démarre automatiquement.
+- Si l'étudiant modifie une valeur au départ, le matériel est réservé, le responsable est alerté et l'état déclaré reste provisoire jusqu'à sa confirmation.
+- Au retour, la checklist est automatiquement préremplie avec l'état de départ réellement validé.
+- Sans modification au retour, la restitution est clôturée automatiquement.
+- Dès que l'étudiant tente de modifier une valeur au retour, le responsable est alerté. Aucun changement de l'état officiel du matériel n'est appliqué avant sa décision.
+- La confirmation du responsable authentifie le changement et crée l'anomalie ; un refus conserve l'état précédemment validé.
+- Un étudiant ne peut avoir qu'un emprunt bloquant d'une même catégorie. La catégorie est débloquée après la clôture automatique ou la décision du responsable sur un retour modifié.
+- Chaque tentative de modification, décision, anomalie et changement d'état officiel est historisé.
+- `CLAUDE.md`, `CONTEXT.md`, les règles métier, `TODO.md`, le README et la maquette textuelle sont synchronisés avant toute modification du code.
+- Un diagramme Mermaid devient la source de vérité du parcours ; le PNG contradictoire est conservé uniquement comme historique.
+
 ---
 
-*Dernière mise à jour : 2026-07-23 — SSO Microsoft Entra ID prêt à configurer, mode démo sécurisé actif.*
+*Dernière mise à jour : 2026-07-24 — Confirmation responsable uniquement en cas d'écart déclaré.*