# Implémentation Phase 2.1 — validation métier de Ma journée

> **Rectificatif de requalification (2026-08-23)** : les jeux
> `TEST_UI_PHASE21_*` ont été préparés par fixtures/SQLAlchemy/script pour
> tester le moteur. Ils ne prouvent pas un parcours administrateur réalisé
> dans l'interface. Voir `PHASE21_REQUALIFICATION.md`.

## 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.
