gmao/docs/development/STATUS_020_DEV3.md
2026-08-23 18:34:23 +00:00

6.5 KiB
Raw Blame History

CURRENT VERSION: 0.2.0-dev.2 CURRENT CHECKPOINT: B — validation fonctionnelle finale CURRENT COMMIT: à committer (version dev.2) CURRENT MIGRATION: m8b9c0d1e2f3 (appliquée Docker) DOCKER VERSION: gmao-college:0.2.0-dev.2 (reconstruite, healthy, MariaDB connectée) LAST FULL TEST: 166 passed, 1 failed, 1 error — uniquement lookback/configuration GMAO historique et son teardown LAST TARGETED TEST: 12 passed (navigation, profil HTTP, bulk 200, horaires UI, Centre de configuration, duplication) BLOCKERS: validation responsive visuelle non exécutée ; aucun défaut fonctionnel B restant NEXT ACTION: committer/pousser la version dev.2 sur origin/main et audit/main

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 dun 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 dun local (profil/ouvrages/équipements cochables), sans historique, documents, compteurs ou identifiants ;
  • surfaces facultatives saisissables sur la fiche dun local, types mur/sol/plafond/autre ;
  • page UI des horaires par technicien et année, pause facultative, absence dhoraire 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 na été trouvé dans les procédures du dépôt ; aucune session de production na é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 nest 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.