33 lines
2.8 KiB
Markdown
33 lines
2.8 KiB
Markdown
# Implémentation Phase 2.1c — patrimoine et exécution progressive
|
|
|
|
## Baseline
|
|
|
|
- Version : 0.1.0-dev.11
|
|
- Migration de départ : i4d5e6f7a8b9
|
|
- Phase 2.1b : partiellement validée ; suite pytest connue : 159 pass, 1 échec et 1 erreur historiques (lookback/configuration GMAO).
|
|
- Les intégrations externes et l'ancien menu (76/76, administrateurs) sont hors modification.
|
|
|
|
## Clôture technique 2.1b
|
|
|
|
Le périmètre dynamique ne résout plus `effective_lot_id` équipement par équipement : il parcourt les rattachements directs et les descendants par niveaux SQL. Les groupes dont le lot est hérité restent pris en compte. Mesure locale sur 100 équipements : 0,129 s pour le périmètre. La génération a été regroupée (échéances et doublons chargés par lots) : 214 requêtes, 3,22 s, contre 1 614 requêtes et 11,37 s avant regroupement ; DayPlanner : 0,125 s.
|
|
|
|
Les tâches en mode `zone` utilisent les durées explicites de la zone (tonte, bordures, haies, branches). Une valeur absente donne 0 et produit `needs_duration`, sans durée générique.
|
|
|
|
La fiche contrat expose maintenant les LotTask couvertes, leurs périmètres et leurs occurrences planifiées, en complément de ContractVisit.
|
|
|
|
## Patrimoine progressif
|
|
|
|
`RoomType` est conservé comme profil de local extensible. La route `/equipments/rooms/bulk` permet de créer plusieurs locaux à partir d'une liste, avec bâtiment, zone, étage et profil facultatif. Aucun équipement n'est créé implicitement : l'administrateur valide ensuite les équipements proposés. La cartographie technique avancée reste facultative.
|
|
|
|
## Tâches interrompables
|
|
|
|
LotTask porte désormais la nature métier (`preventive`, `conditional_curative`, `regulatory`, `contractual`, `unknown`) séparément de l'exécutant, ainsi que les indicateurs d'interruption/fractionnement et le segment minimum. Les `TaskExecutionSegment` conservent le temps réalisé, les pauses et leurs motifs. Une tâche conditionnelle n'est pas générée périodiquement par le moteur.
|
|
|
|
La migration est non destructive et conserve les valeurs par défaut sûres. Les actions d'exécution complète et l'édition avancée des profils d'équipements restent à finaliser après validation UI.
|
|
|
|
## Requalification finale locale
|
|
|
|
- Image active : `gmao-college:0.1.0-dev.12` ; `/health/` sain, MariaDB connectée, migration `j5e6f7a8b9c0` appliquée.
|
|
- Benchmark conservé : 100 équipements `TEST_UI_PHASE21C_VALIDATION_BENCH_*`.
|
|
- Segments vérifiés par service : 25 min puis 20 min réalisés, 15 min restants, statut `paused`, 2 segments ; une tâche non interruptible refuse la pause.
|
|
- Le navigateur headless est disponible, mais aucun compte de validation fonctionnel dont le mot de passe soit connu n'a permis de rejouer le scénario UI complet sans réinitialiser un compte existant. La validation UI complète reste donc non acquise.
|