From 295dd03b8d43e0f7fabdee77290aef86d588e3fc Mon Sep 17 00:00:00 2001 From: SaidSoighiri94 Date: Thu, 9 Jul 2026 10:01:30 +0200 Subject: [PATCH] docs: clarify review current state --- review.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 73 insertions(+), 8 deletions(-) diff --git a/review.md b/review.md index 26271ec..8fccfb9 100644 --- a/review.md +++ b/review.md @@ -20,10 +20,61 @@ Ces décisions s'appliquent à tout le projet, sauf mention contraire. | Champs nullable selon les cardinalités `0..1` du diagramme de classes | Un champ non connu à la création (ex. date de retour) ou optionnel doit être `NULL`, sinon le workflow métier est bloqué. | | `onDelete: NoAction, onUpdate: NoAction` sur les données de traçabilité (Emprunt, Checklist, ChecklistElement, Anomalie, Historique) | Ces données ne doivent jamais être supprimées/altérées automatiquement en cascade. Toute suppression sera explicite côté service. Évite aussi l'erreur SQL Server "multiple cascade paths". | | ERD tenu à jour en miroir du schéma (`docs/conceptions/uml/ERD.md`) | La source de vérité doit refléter le code réel (nullable, `UK`, etc.). | -| Workflow Git : commits sur `develop` uniquement | `master` est figé ; `develop` reste toujours à jour de `master` (aucune divergence puisque master ne bouge plus). | +| 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. | +--- + +## État actuel synthétique + +Cette section résume l'état courant du projet. Le journal chronologique plus bas conserve +l'historique complet, y compris des étapes devenues obsolètes après branchement API. + +| Bloc | État | Commentaire | +|---|---|---| +| 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 | Terminé pour la V1 | Parcours emprunt et restitution branchés sur l'API et testés en réel. | +| Authentification | Simulée | `x-user-email` côté backend et identité démo côté frontend ; Azure AD reste à faire. | +| Responsable matériel | Non démarré | Dashboard, stock, anomalies, historique à développer. | +| Tests automatisés | Non démarré | Tests backend/frontend/E2E à ajouter ; tests runtime manuels effectués. | +| Documentation | Partielle | `CONTEXT.md`, `TODO.md`, `review.md` existent ; README principal et OpenAPI restent à créer. | + +## Commandes validées + +Commandes utilisées et validées dans l'environnement de développement local : + +```bash +docker compose up -d +cd eme-backend +npm run dev +npm run build +npm run lint +npm run seed +npm run fixtures +cd ../eme-frontend +flutter run -d web-server --web-port 5000 +``` + +Notes : +- le backend écoute sur `http://localhost:3000` ; +- le frontend web de démo écoute sur `http://localhost:5000` ; +- Adminer est disponible sur `http://localhost:8081` ; +- dans l'environnement Codex, `flutter analyze`, `flutter analyze --no-pub` et `dart format` ont déjà bloqué au timeout ; à relancer dans un terminal local Flutter. + +## Scénario de démo validé + +Scénario étudiant validé avec SQL Server Docker et backend compilé : + +1. Afficher le catalogue des matériels disponibles du campus. +2. Ouvrir le détail d'un matériel et vérifier les accessoires. +3. Créer un emprunt avec checklist de départ. +4. Vérifier que l'emprunt apparaît dans `mes-emprunts`. +5. Restituer conforme : l'emprunt passe `CLOTURE` et le matériel redevient disponible. +6. Restituer non conforme : l'emprunt passe `RETOUR_NON_CONFORME` et le matériel sort du catalogue disponible. + ### Note outillage — migrations en environnement non-interactif `prisma migrate dev` se bloque quand il doit demander une confirmation (ex. ajout de contrainte `@unique` sur table existante) car le terminal est non-interactif. @@ -192,18 +243,24 @@ En terminal interactif (VS Code), `migrate dev` fonctionne normalement (taper `y - Modèle `MaterielItem` enrichi (marque, modèle, état, accessoires) ; données statiques mises à jour. - Navigation : Catalogue (Sélectionner) -> Détail ; « Démarrer l'emprunt » -> placeholder (checklist à venir). +> Note historique : les étapes 21 à 25 décrivent l'état initial statique du frontend. +> Elles ont été remplacées fonctionnellement par les branchements API des étapes 26 à 32. + --- ## Dette technique en attente À traiter ensemble plus tard (avec mise à jour ERD en miroir) : -1. `CarteEtudiante.qr_code` -> `@unique` (identification, RG02) -2. `MaterielAccessoire` -> `@@unique([materielId, accessoireId])` (un accessoire une seule fois par matériel) -3. `Materiel.statut` -> `@default("DISPONIBLE")` (un matériel neuf est disponible, RG07) -4. Tailles de colonnes `@db.NVarChar(n)` (actuellement `NVARCHAR(1000)` partout) -5. Swagger/OpenAPI (Block 1, reporté après les endpoints) -6. Auth réelle Azure AD (Block 3) — remplacera l'auth simulée par en-tête +| Dette | Statut | Impact V1 | +|---|---|---| +| `CarteEtudiante.qr_code` -> `@unique` | À faire avec migration + ERD | Moyen : sécurise l'identification QR. | +| `MaterielAccessoire` -> `@@unique([materielId, accessoireId])` | À faire avec migration + ERD | Moyen : évite les doublons d'accessoires. | +| `Materiel.statut` -> `@default("DISPONIBLE")` | À faire avec migration + ERD | Faible : le code fournit déjà le statut explicitement. | +| Tailles de colonnes `@db.NVarChar(n)` | À cadrer | Faible V1, important pour qualité BDD. | +| Swagger/OpenAPI | À faire | Moyen : utile pour tester/documenter l'API. | +| Auth réelle Azure AD | À faire | Fort : requis pour sortir de la démo avec auth simulée. | +| Limite d'emprunts actifs par étudiant | À valider métier | Non bloquant V1 ; décision métier non présente dans les règles actuelles. | --- @@ -259,6 +316,14 @@ En terminal interactif (VS Code), `migrate dev` fonctionne normalement (taper `y - Commentaire obsolète du modèle `MaterielItem` corrigé : les données viennent maintenant de l'API. - `TODO.md` mis à jour : les parcours emprunt et restitution étudiant sont maintenant branchés API. +### Étape 33 — Clarification du journal de décisions +- Branche dédiée `docs/review-current-state` créée depuis `develop`. +- Ajout d'une synthèse d'état courant pour éviter de devoir relire tout l'historique. +- Correction de la convention Git : `develop` est la branche d'intégration, les travaux passent par branches dédiées. +- Ajout des commandes validées et du scénario de démo étudiant testé. +- Dette technique reformatée en tableau avec statut et impact V1. +- Clarification des étapes frontend statiques historiques : elles sont conservées pour mémoire mais remplacées par les branchements API ultérieurs. + --- -*Dernière mise à jour : 2026-07-08 — Parcours étudiant complet testé et libellés V1 harmonisés.* +*Dernière mise à jour : 2026-07-09 — État courant du projet et journal de décisions clarifiés.*