gmao/docs/development/STATUS_020_DEV3.md

CURRENT VERSION: 0.2.0-dev.2 CURRENT CHECKPOINT: C3-FINAL — branchement automatique des anomalies CURRENT COMMIT: cac9dbc — fix(meters): automate statistical anomaly detection CURRENT MIGRATION: r3f4g5h6i7j8 (down_revision q2f3g4h5i6j7) DOCKER VERSION: gmao-college:0.2.0-dev.2 (reconstruite, healthy, MariaDB connectée) LAST FULL TEST: baseline précédente 202 passed, 1 failed, 1 error ; les deux anomalies historiques restent visibles LAST TARGETED TEST: 39 passed (C1/C2/C3) ; 17 tests C3 incluant les anomalies statistiques automatiques BLOCKERS: validation responsive visuelle et base vide non exécutées ; anomalies pytest historiques conservées NEXT ACTION: appliquer r3f4g5h6i7j8 dans Docker, terminer pytest complet puis revue indépendante ; ne pas commencer C4

C3 — socle analytique

• intervalles calculés à partir de deux MeterReading bruts, avec rupture explicite sur reset/baisse et frontières de compteur remplacé ;
• contexte calendrier réutilisant CollegeClosure/PlanningService, logements hors calendrier scolaire par défaut ;
• régimes datés NORMAL/REDUCED/STOP par compteur et réseau ;
• reste parent/sous-compteurs avec qualités EXACT, ESTIMATED, PARTIAL ;
• règles et alertes persistées, niveaux WARNING/CRITICAL, médiane et déduplication des alertes ouvertes ;
• conversions gaz datées, priorité manuelle, tarifs facultatifs et coût informatif au tarif du relevé final ;
• tableau de surveillance et fiche analytique ;
• agrégations DAY/WEEK/MONTH, seuil d’écart, minimum comparable et zero/low ;
• preuves idempotentes et exclusions baseline pour fuite/erreur de relevé ;
• conversion gaz issue de facture et règle eau m³ sans conversion kWh ;
• alertes informatives dans Ma journée et graphiques locaux responsives ;
• recalcul ciblé automatique après nouveau relevé et correction auditée ; preuves obsolètes neutralisées sans effacer l'historique clôturé ;
• anomalies statistiques branchées automatiquement avec distinction explicite MANUAL_THRESHOLD / STATISTICAL_ANOMALY ;
• clôture HTTP RBAC, visibilité filtrée dans Ma journée et création d'intervention idempotente ;
• dashboard 30 jours avec données insuffisantes et synthèses séparées eau/gaz/électricité ;
• migration q2f3g4h5i6j7 appliquée ; migration additive r3f4g5h6i7j8 préparée ;
• mesures C3-CLOSE sur TEST_UI_C3_PERF_* : dashboard 83 requêtes, fiche 24, évaluation 4, Ma journée 86 ; temps variables selon MariaDB ;
• validation Playwright/base vide non effectuée ;
• C4 non commencé.

C2 — état et limites

• règles hebdomadaire, mensuelle, semestrielle, annuelle et date annuelle fixe ;
• occurrences idempotentes à horizon borné, retard persistant et traitement avec/sans relevé ;
• intégration dans DayPlanner/« Ma journée » avec responsable et durée ;
• tournées ordonnées, occurrences de tournée et progression ;
• migration o0d1e2f3g4h5 appliquée sur la base existante ;
• tests C2 ciblés et absence de nouvelle régression dans le pytest complet ;
• validation sur base vide non effectuée ;
• validation Playwright authentifiée desktop/tablette/mobile non effectuée ;
• mesure de référence avant C2-FIX : Ma journée 199 requêtes / 4,8439 s ; tournée 88 requêtes / 0,6140 s ;
• C3 terminé fonctionnellement sous réserve de revue indépendante ; [ ] C4 non commencé.

C2-FIX — fiabilisation

• une tournée génère les occurrences selon operational_date, y compris lorsque target_date est ultérieure ;
• priorité d'affectation : règle de compteur, responsable par défaut de tournée, puis non attribué ;
• isolation utilisateurs, double traitement et progression/reprise testés ;
• génération batchée des occurrences existantes et cache des calculs horaires/calendrier ;
• mesure après C2-FIX : Ma journée 183 requêtes ; tournée 89 requêtes ; temps variable selon la charge MariaDB (mesures observées respectivement 1,2285–2,9419 s et 0,3699–0,7112 s) ;
• la majorité des requêtes restantes provient de l'autorisation/navigation globale ; la tournée reste à une requête de la référence SQL ;
• collision réellement concurrente non simulée ; la contrainte unique (schedule_id, target_date) reste la protection DB ;
• validation Playwright et base vide toujours non effectuées.

Avancement

• mémoire de chantier créée ;
• baseline Git/Docker/version vérifié ;
• service commun introduit pour les routes fiche et wizard ;
• lot facultatif accepté par les routes wizard ;
• suppression de la recherche par nom dans le wizard ;
• fallback Intervention 60 minutes supprimé ;
• tests ciblés A (28 passants) ;
• audit A1-A7 ;
• checkpoint A commit/version ;
• checkpoint B ;
• checkpoint C ;
• checkpoint D ;
• checkpoint E.

Reprise

Lire ROADMAP_020_DEV3.md et DECISIONS_020_DEV3.md, puis reprendre sur NEXT ACTION. Ne pas commencer B avant clôture documentée de A.

Détail checkpoint A

• Le service core.services.equipment_creation.create_equipment est utilisé par la fiche Equipment et les deux parcours wizard.
• Catégorie et lot sont facultatifs dans les créations wizard ; une catégorie/lot explicitement invalide reste rejeté.
• Les instances créées sont conservées en mémoire ; aucune recherche post-création par nom n'est effectuée.
• Le fallback silencieux de 60 minutes des interventions est remplacé par une durée inconnue (0) quand aucune estimation n'est disponible.
• Les nouveaux tests unitaires couvrent l'équipement sans lot et les noms dupliqués.
• Le test historique test_gmao_config_caps_lookback_at_one_year échoue encore (plafond 9000 au lieu de 8760) et son teardown échoue sur gmao_context.user_id NULL ; aucune nouvelle régression observée.

Après versionnement A

• Version applicative : 0.2.0-dev.1.
• La version est mise à jour dans VERSION, dans les valeurs par défaut de docker-compose.yml et dans le test de version.
• Le checkpoint B n'est pas commencé ; aucune migration nouvelle n'a été créée.
• Docker doit être reconstruit avec GMAO_VERSION=0.2.0-dev.1 avant toute validation UI de cette version.
• Reconstruction effectuée : image gmao-college:0.2.0-dev.1, migrations lancées au démarrage, /health/ retourne healthy, version 0.2.0-dev.1, MariaDB connectée.
• Le compose signale encore health: starting pendant sa fenêtre initiale ; l'endpoint applicatif est déjà sain.
• Aucun fichier non commité après le commit de statut suivant.

Reprise checkpoint B

• exigences Centre de configuration permanent ajoutées à la roadmap ;
• configuration progressive et intégrations facultatives documentées ;
• horaires technicien explicitement rattachés à l'utilisateur et absence de fallback rappelée ;
• hiérarchie Site → Building → Zone → Room et HousingUnit documentée ;
• non-régression TaskExecutionSegment/interruption documentée ;
• exigences détaillées des checkpoints C, D et E ajoutées à la roadmap sans les commencer ;
• audit B1 des modèles et parcours ;
• décision RoomType enrichi ou RoomProfile ;
• décision documentée : RoomProfile séparé de RoomType ;
• migration B écrite : k6f7a8b9c0d1 puis l7a8b9c0d1e2 ;
• implémentation initiale des profils, propositions, surfaces et Centre de configuration ;
• association facultative d'un profil aux locaux et sélection dans le bulk ;
• tests ciblés B et pytest complet sans nouvelle régression ;
• rebuild Docker dev.2, application des migrations et /health/ healthy ;
• validation HTTP authentifiée des profils : création UI, preview, application, réapplication, modification sans mutation ;
• validation HTTP authentifiée des horaires de deux techniciens ;
• Centre de configuration rendu et liens principaux vérifiés ;
• charge 200 locaux ;
• validation responsive visuelle avec compte admin local (non bloquante, limitation documentée) ;
• checkpoint B validé et version 0.2.0-dev.2.

Dernière reprise B

• application explicite d’un profil via le service commun avec origine room_profile_item_id ; réapplication par delta, sans suppression automatique ;
• prévisualisation bulk avant validation, déduplication des noms existants ;
• duplication contrôlée d’un local (profil/ouvrages/équipements cochables), sans historique, documents, compteurs ou identifiants ;
• surfaces facultatives saisissables sur la fiche d’un local, types mur/sol/plafond/autre ;
• page UI des horaires par technicien et année, pause facultative, absence d’horaire explicite ;
• niveaux ESSENTIEL / MAINTENANCE-PATRIMOINE / AVANCÉ affichés dans le setup et Centre de configuration conservé après installation ;
• migration m8 appliquée dans Docker ;
• benchmark isolé 200 locaux (création en lot, sans doublon) ;
• pytest complet : 163 passed, 1 failed, 1 error, uniquement les deux problèmes historiques autorisés ;
• validation visuelle/authentifiée réelle des écrans B et décision de version dev.2.

Mesures et limites de reprise

• Docker reconstruit avec GMAO_VERSION=0.2.0-dev.2; /health/ : healthy, MariaDB connectée, version 0.2.0-dev.2; migration m8b9c0d1e2f3.
• Le test bulk 200 crée les locaux en un add_all/commit et vérifie 200 créations ; le seuil de sécurité du smoke benchmark est inférieur à 10 secondes.
• Chromium Playwright est installé (~/.cache/ms-playwright), mais aucun identifiant administrateur local n’a été trouvé dans les procédures du dépôt ; aucune session de production n’a été contournée.
• Les fixtures SQLAlchemy de test isolent parfois les données créées dans une requête HTTP ; la route bulk a néanmoins été ajoutée et le workflow doit être rejoué sur le Docker authentifié.
• La version 0.2.0-dev.2 est retenue : les workflows sont démontrés par tests HTTP authentifiés et aucune nouvelle régression n’est apparue ; la validation visuelle reste une limitation explicitement documentée.
• Le Centre de configuration a été corrigé pour les contrats (utilisation des colonnes ORM réelles) et les liens profils/bulk/horaires ont été ajoutés au nouveau menu.

Checkpoint C1 — socle compteurs et relevés

• audit des modèles Meter / MeterReading, routes historiques et templates ;
• création unifiée des compteurs par service ;
• rattachement direct à Equipment, Building, Zone, Room ou HousingUnit ;
• plusieurs racines et hiérarchie Meter.parent_id, avec protection contre les cycles ;
• service unique core.services.meter_service.record_meter_reading pour les routes de relevé ;
• baisse refusée sans remise à zéro explicite et motif ;
• corrections auditées dans meter_reading_corrections ;
• remplacement explicite avec conservation de l'ancien compteur et de son historique ;
• photo facultative rattachée à MeterReading ;
• migration n9c0d1e2f3g4 appliquée ;
• mesure SQL : liste 75 requêtes dans le contexte applicatif complet (navigation incluse), détail + historique 2 requêtes après chargement explicite ;
• C1-FIX : parent modifiable, statut physique séparé, remplacement/prédécesseur affichés, types usuels et historiques préservés ;
• C1-FIX : tests HTTP ciblés ;
• C1-FIX : documentation finale et clarification de la topologie Forgejo/GitHub principal ;
• C1-CLOSE : relevés bloqués sur compteur remplacé/inactif, historique et corrections conservés ;
• C1-CLOSE : aucune migration supplémentaire ;
• C2, C3 et C4 non commencés ;
• validation Playwright visuelle complète non exécutée ;
• installation complète sur base vide non validée : l'utilisateur MariaDB applicatif n'a pas le privilège de création de base temporaire.

La version reste 0.2.0-dev.2. Les seuils historiques de compteur ne sont pas réutilisés pour les alertes de consommation futures.