70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
# Implémentation Phase 2.1 — validation métier de Ma journée
|
||
|
||
## Baseline
|
||
|
||
- Version avant : `0.1.0-dev.7`
|
||
- Version après : `0.1.0-dev.8` (replanification interactive minimale)
|
||
- Commit de départ : `c5b298c`
|
||
- Docker local : image `gmao-college:0.1.0-dev.8`, MariaDB saine
|
||
- `/health/` : HTTP 200
|
||
- `/planning/my-day` : réponse 200 après connexion
|
||
- Ancien menu : inchangé, 76/76, administrateurs uniquement
|
||
|
||
## Données persistantes
|
||
|
||
Le scénario est conservé dans la copie locale de la base sous les marqueurs
|
||
`TEST_UI_PHASE21_*`. Le compte `TEST_UI_PHASE21_TECH` possède un rôle dédié
|
||
avec les permissions planning, intervention, patrimoine et prévention. Son mot
|
||
de passe est local uniquement et n'est pas écrit dans Git.
|
||
|
||
Créés :
|
||
|
||
- site `TEST_UI_PHASE21_SITE` ;
|
||
- bâtiments `TEST_UI_PHASE21_BAT_A` et `TEST_UI_PHASE21_BAT_B` ;
|
||
- zones et salles 101, 102, circulation, 201, 001, local technique et
|
||
sanitaires ;
|
||
- horaires utilisateur 08:00–12:00 / 13:30–17:00 du lundi au vendredi ;
|
||
- occupations internes : salle 101 manuelle 08:30–09:30, salle 102 Pronote
|
||
simulée 08:30–09:00, salle 201 manuelle protégée 14:00–16:00 ;
|
||
- rendez-vous `TEST_UI_PHASE21_COMPANY_APPOINTMENT` fixe 09:30–10:30 ;
|
||
- urgence `TEST_UI_PHASE21_EMERGENCY_FUITE` fixe 10:15–11:00 ;
|
||
- interventions, cinq tâches préventives et tâches administratives ;
|
||
- journée contrainte du mardi pour vérifier le statut « À replanifier ».
|
||
|
||
Aucune donnée existante n'a été nettoyée globalement.
|
||
|
||
## Résultats
|
||
|
||
Le lundi 24/08/2026, le moteur place l'administratif, les interventions et les
|
||
maintenances dans les fenêtres de travail, sans utiliser la salle 101 pendant
|
||
son occupation manuelle ni la salle 102 pendant son créneau Pronote simulé.
|
||
Le rendez-vous entreprise reste fixe. L'urgence qui le chevauche est marquée
|
||
`conflit` et expliquée : rendez-vous fixe chevauché, décision humaine requise.
|
||
|
||
Le mardi 25/08/2026, deux blocs fixes occupent 08:00–12:00 et 13:30–16:30.
|
||
La tâche administrative de 45 minutes est conservée et marquée `À replanifier`,
|
||
sans être tronquée.
|
||
|
||
## Replanification minimale
|
||
|
||
`POST /planning/my-day/reschedule` permet de choisir un créneau proposé pour
|
||
une `ScheduledTask` ou une `Intervention`. Le serveur revalide l'identité, la
|
||
durée, les horaires, la pause, les conflits internes et la salle avant
|
||
d'écrire. Les tâches administratives ne sont pas encore persistées
|
||
individuellement car leur modèle est récurrent sans date d'occurrence.
|
||
|
||
## Tests et limites
|
||
|
||
- `tests/unit/test_day_planner.py` : **15 passed** ;
|
||
- navigation + replanification invalide : **5 passed** ;
|
||
- total ciblé Phase 2.1 : **20 passed** ;
|
||
- `pytest -q` : **149 passed, 1 failed, 1 error** ; l'échec et l'erreur
|
||
restent le test historique de configuration/lookback GMAO et son teardown,
|
||
hors périmètre ; aucune nouvelle régression n'a été introduite ;
|
||
- mesure locale : environ 2 secondes pour 10 candidats et plusieurs salles ;
|
||
- aucune validation visuelle réelle 390×844/768×1024, navigateur instrumenté
|
||
indisponible.
|
||
|
||
Restent à développer : résolution humaine plus complète des conflits,
|
||
replanification automatique après urgence, accompagnement multi-segments,
|
||
multi-techniciens, compétences et solveur.
|