67 lines
2.9 KiB
Markdown
67 lines
2.9 KiB
Markdown
|
# Implémentation Phase 2 — Ma journée
|
|||
|
|
|
|||
|
|
## Baseline
|
|||
|
|
|
|||
|
|
- Version avant : `0.1.0-dev.6`
|
|||
|
|
- Commit de départ : `3c4ef00`
|
|||
|
|
- Environnement : copie locale de la base VM, Docker local sur `127.0.0.1:5080`
|
|||
|
|
- `/health/` : HTTP 200, MariaDB connectée
|
|||
|
|
- Ancien menu : conservé, 76/76 entrées, administrateurs uniquement
|
|||
|
|
- Intégrations externes : Pronote, ENT, Outlook, IA et watchdogs non requis
|
|||
|
|
- Baseline pytest historique : `132 passed, 1 failed, 1 error`, échec/erreur
|
|||
|
|
lookback GMAO hors périmètre
|
|||
|
|
|
|||
|
|
## Architecture retenue
|
|||
|
|
|
|||
|
|
La Phase 2 n'ajoute pas une quatrième table de tâches. Le service
|
|||
|
|
`app_new/core/services/day_planner.py` expose une dataclass
|
|||
|
|
`PlanningCandidate` et agrège les modèles existants : `ScheduledTask`,
|
|||
|
|
`Intervention`, `AdminTask`, les salles et les horaires `WorkSchedule`.
|
|||
|
|
Les propositions restent en mémoire : aucune modification silencieuse du
|
|||
|
|
planning n'est effectuée.
|
|||
|
|
|
|||
|
|
Types couverts : maintenance préventive, intervention, administratif et
|
|||
|
|
urgence. Un rendez-vous d'entreprise déjà représenté par une tâche fixe peut
|
|||
|
|
être conservé ; le modèle multi-segments d'accompagnement reste hors de cette
|
|||
|
|
tranche.
|
|||
|
|
|
|||
|
|
## Règles de proposition
|
|||
|
|
|
|||
|
|
- les horaires de travail et la pause sont des contraintes fortes ;
|
|||
|
|
- sans horaire explicitement configuré pour le jour et l'utilisateur, la vue
|
|||
|
|
affiche une alerte et ne fabrique pas de journée 08:00–17:00 ;
|
|||
|
|
- les créneaux fixes sont conservés ;
|
|||
|
|
- les urgences et échéances sont triées avant les tâches flexibles ;
|
|||
|
|
- les salles sont vérifiées via le planning interne résolu, jamais via Pronote ;
|
|||
|
|
- la recherche de créneau avance par pas déterministes de cinq minutes ;
|
|||
|
|
- une tâche impossible est marquée « À replanifier » avec une explication ;
|
|||
|
|
- chaque choix expose une raison courte à l'utilisateur.
|
|||
|
|
|
|||
|
|
## Interface
|
|||
|
|
|
|||
|
|
`/planning/my-day` est accessible depuis `Mon travail > Ma journée` et depuis
|
|||
|
|
le tableau de bord. La vue propose la date précédente, aujourd'hui et la date
|
|||
|
|
suivante, puis une timeline de cartes indiquant heure, durée, lieu, type,
|
|||
|
|
contrainte, statut et explication. Les actions d'application automatique ne
|
|||
|
|
sont pas présentes dans cette première tranche : l'utilisateur garde le
|
|||
|
|
contrôle.
|
|||
|
|
|
|||
|
|
## Tests ajoutés
|
|||
|
|
|
|||
|
|
`tests/unit/test_day_planner.py` couvre la pause, le déterminisme, les horaires
|
|||
|
|
fixes, l'impossibilité d'une tâche trop longue et l'absence d'horaires.
|
|||
|
|
|
|||
|
|
## Limites Phase 2 restantes
|
|||
|
|
|
|||
|
|
- pas encore de validation/applicaton en masse d'une proposition ;
|
|||
|
|
- pas de workflow de replanification automatique d'une urgence ;
|
|||
|
|
- pas de modèle dédié pour plusieurs segments d'entreprise extérieure ;
|
|||
|
|
- pas de multi-techniciens, compétences ou solveur ;
|
|||
|
|
- contrôles visuels réels à compléter avec navigateur instrumenté.
|
|||
|
|
|
|||
|
|
## Données TEST_UI
|
|||
|
|
|
|||
|
|
Aucune donnée existante n'a été supprimée ou nettoyée. Les scénarios avec
|
|||
|
|
données `TEST_UI_PHASE2_*` seront ajoutés uniquement lorsque les tests
|
|||
|
|
d'intégration de la vue quotidienne seront finalisés.
|