docs(planning): requalify phase 2.1 UI prerequisites

docs/ui-audit/BUGS.md

@@ -1,5 +1,17 @@
 # Bugs et anomalies
 
+## Phase 2.1 — validation fonctionnelle (P1)
+
+- Les scénarios précédents ne constituaient pas une preuve UI : les lots et
+  équipements `TEST_UI_PHASE21_*` n'étaient pas présents dans la copie VM
+  contrôlée et avaient été préparés directement en base/fixtures.
+- Avant correction, la page des horaires ne permettait pas de choisir un
+  technicien et `PlanningService` pouvait réutiliser la plage d'un autre
+  utilisateur. La sélection et le filtrage sont maintenant corrigés ; le
+  parcours doit être revalidé manuellement.
+- La création d'un lot démarre depuis l'assistant équipement ; il n'existe
+  pas encore de formulaire autonome `/lots/new`.
+
 ## UI-001 — Transvasement inaccessible
 
 - Priorité : P1

docs/ui-audit/CREATED_TEST_DATA.md

@@ -1,5 +1,13 @@
 # Données TEST_UI_* laissées sur l'instance
 
+## Rectificatif Phase 2.1
+
+Les données `TEST_UI_PHASE21_*` historiques ont été créées par scripts,
+SQLAlchemy direct et fixtures de tests afin de valider le moteur. Elles ne
+doivent pas être comptées comme créées par un utilisateur dans l'interface.
+La copie VM contrôlée ne contenait notamment aucun lot ni équipement marqué
+Phase 2.1. Elles sont conservées volontairement.
+
 Le nettoyage final est volontairement interdit. Les objets suivants sont
 laissés pour inspection manuelle.
 

docs/ui-audit/IMPLEMENTATION_PHASE21.md

@@ -1,5 +1,10 @@
 # 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`

docs/ui-audit/PHASE21_REQUALIFICATION.md

@@ -0,0 +1,126 @@
+# Requalification Phase 2.1 — prérequis métier et interface
+
+Date : 2026-08-23  
+Version auditée : 0.1.0-dev.8
+
+## Conclusion
+
+La validation précédente est requalifiée **PARTIELLEMENT VALIDÉE**. Les
+services de planification sont testés, mais le scénario préventif annoncé
+n'était pas reproductible par un administrateur depuis l'interface : les
+données `TEST_UI_PHASE21_*` persistées dans la copie VM ont été préparées par
+SQLAlchemy/script (et les tests utilisent des fixtures). Aucun lot ni
+équipement marqué Phase 2.1 n'était présent dans la base contrôlée. Une
+fixture passante ne constitue donc pas une validation du parcours utilisateur.
+
+## Audit des données Phase 2.1
+
+| Donnée | Mode constaté | Parcours UI identifié | Validation métier |
+|---|---|---|---|
+| `TEST_UI_PHASE21_TECH` et horaires | SQLAlchemy/script puis fixtures | `/planning/time` existait pour l'utilisateur courant | Partielle |
+| salles et occupations | script/fixtures | planning des salles | Partielle |
+| tâches planifiées, urgence, entreprise | script/fixtures | routes normales disponibles | Partielle |
+| lot, tâche de lot, équipements | aucune donnée marqueur dans la copie VM | assistant équipement + détail du lot + `/lots/<id>/tasks/new` | Non validée |
+
+Le précédent rapport doit être lu comme une validation technique du moteur, et
+non comme une preuve de configuration UI. La cause est méthodologique : le
+scénario a été construit directement en base pour tester l'algorithme avant de
+vérifier chaque écran de configuration.
+
+## Horaires par technicien
+
+`WorkSchedule.user_id` et `WorkScheduleTemplate.user_id` rattachent déjà les
+plages à un utilisateur. Avant cette passe, `/planning/time` ne permettait
+cependant de gérer que l'utilisateur connecté et `PlanningService` choisissait
+une plage globale lorsqu'aucun utilisateur n'était filtré. Cette contamination
+était incompatible avec deux techniciens.
+
+La correction minimale appliquée :
+
+- sélection du technicien dans `/planning/time` pour un administrateur ou un
+  détenteur de `planning.manage` ;
+- requêtes horaires, absences et formations filtrées par `user_id` ;
+- `DayPlanner` reçoit explicitement l'utilisateur ;
+- sans horaire explicite pour cet utilisateur, aucune journée 08:00–17:00
+  implicite n'est créée ; l'écran affiche une aide et un lien de configuration ;
+- les tâches administratives peuvent être rattachées à un utilisateur (`NULL`
+  conserve les anciennes tâches globales).
+
+Le modèle permet plusieurs plages dans une journée via `lunch_start/lunch_end`
+et des jours différents via `day_of_week`. Les pauses sont donc représentées
+comme une coupure de la plage. La page affiche les horaires appliqués et la
+personne concernée. Les fermetures du collège restent globales ; les congés,
+formations (`TrainingParticipant`) et indisponibilités
+(`TechnicianAvailability`) sont filtrés par technicien.
+
+Test automatisé ajouté : deux utilisateurs avec 08:00–17:00 et 07:00–15:30
+obtiennent chacun exclusivement leurs horaires.
+
+## Lots et préventif
+
+La relation réelle est directe : `Equipment.lot_id -> Lot.id`, avec héritage
+possible par équipement parent (`effective_lot_id`). Un lot possède des
+`LotTask`; la tâche contient `duree_minutes`, `periodicite` et les paramètres de
+génération. Les formulaires équipement permettent de choisir un lot et
+l'assistant équipement expose une création rapide de lot. Le détail du lot
+permet d'ajouter une tâche. Il n'existe pas de route autonome `/lots/new` : la
+création initiale passe par l'assistant, désormais indiqué depuis la liste des
+lots.
+
+La durée et la périodicité sont donc des champs UI de `LotTask`. Attention :
+`LotTask.effective_duration()` conserve un fallback historique de 60 minutes
+si aucune durée n'est saisie ; ce comportement doit rester visible et être
+remplacé ou confirmé avant une validation métier définitive. La génération
+préventive complète depuis un lot et deux équipements n'a pas été rejouée via
+UI dans cette passe : elle reste **NON VALIDÉE**.
+
+## Matrice des prérequis de Ma journée
+
+| Donnée | Rattachement | Création/modification UI | Utilisé par DayPlanner | Statut |
+|---|---|---|---|---|
+| Technicien | `User` | utilisateurs | oui | disponible |
+| Horaires / pauses | `WorkSchedule.user_id` | `/planning/time` | oui | corrigé et testé |
+| Congés | `PersonalLeave.user_id` | planning | oui | filtré |
+| Formation | `TrainingParticipant.user_id` | planning | oui | filtré |
+| Indisponibilité | `TechnicianAvailability.user_id` | planning | oui | filtré |
+| Fermeture | `CollegeClosure` | administration | oui, globale | disponible |
+| Salle/occupation | Room/RoomSchedule | planning salles | oui | disponible |
+| Lot/tâche | `Lot`, `LotTask` | assistant + détail lot | via génération | UI à rejouer |
+| Équipement | `Equipment.lot_id`, localisation | équipements | via préventif | UI à rejouer |
+| Durée/périodicité | `LotTask` | tâche de lot | oui | disponible, fallback 60 à clarifier |
+| Intervention | `Intervention` | interventions | oui | disponible |
+| Tâche administrative | `AdminTask.user_id` | `/planning/admin-tasks` | oui | corrigé |
+| Entreprise extérieure | rendez-vous planning | planning | oui | disponible |
+| Urgence | intervention/candidat | interventions | oui | disponible |
+
+## Fallbacks détectés
+
+- fallback historique 08:00–17:00 : supprimé pour un `user_id` explicite ;
+- durée administrative 30 minutes : supprimée, une durée absente devient « À
+  replanifier » ;
+- durée de lot 60 minutes : conservée provisoirement, à décider avant la
+  prochaine validation ;
+- technicien implicite : conservé uniquement pour les anciennes tâches
+  administratives globales, jamais pour les horaires d'un technicien.
+
+## Navigation et aide
+
+Le nouveau menu `Mon travail` expose maintenant `Horaires de travail` et `Lots
+préventifs`. `Ma journée` propose un lien de configuration lorsque les horaires
+manquent et signale quand le planning des salles est incomplet. L'Ancien menu
+reste inchangé, administrateur uniquement, 76/76.
+
+## Scénario UI et limites
+
+Le scénario complet demandé (TECH_A → horaires, lot, tâche, équipements,
+génération, Ma journée) n'a pas encore été exécuté intégralement avec un
+navigateur et un compte administrateur de test. Il ne doit pas être présenté
+comme validé. Les données historiques `TEST_UI_PHASE21_*` sont conservées ;
+aucune donnée n'a été nettoyée.
+
+## Décision
+
+La phase est **PARTIELLEMENT VALIDÉE** : l'isolation des horaires et l'absence
+de fallback silencieux sont corrigées et testées ; le parcours UI préventif
+réel, la création de deux techniciens depuis l'UI et la génération sans
+fixture restent à démontrer.

docs/ui-audit/PROGRESS.md

@@ -2,6 +2,14 @@
 
 Dernière mise à jour : 22 août 2026 — reprise après interruption.
 
+## Requalification Phase 2.1 — partielle
+
+La validation technique de `DayPlanner` est conservée, mais les données
+préventives Phase 2.1 avaient été créées par script/fixtures et non par le
+parcours UI. Les horaires sont désormais isolés par technicien et configurables
+pour un administrateur via `/planning/time`. Le parcours lot/équipement/
+préventif doit encore être rejoué depuis l'interface.
+
 ## État global
 
 État : **en cours**. Revalidation VM P1 effectuée ; l'audit fonctionnel doit

docs/ui-audit/UX_PROPOSALS.md

@@ -1,5 +1,13 @@
 # Propositions UX — phase finale
 
+## Requalification Phase 2.1 — UX-P1
+
+Les horaires, lots, équipements et tâches préventives doivent être créables
+depuis un parcours métier explicite. `Ma journée` propose maintenant des liens
+vers les horaires et le planning des salles ; la liste des lots indique
+l'assistant de création. Le parcours complet doit encore être validé avec un
+compte administrateur de test.
+
 ## UX appliquée — Phase 2.1
 
 La timeline de `Ma journée` affiche un résumé compact des tâches, urgences,