110 lines
5.4 KiB
Markdown
110 lines
5.4 KiB
Markdown
# Roadmap 0.2.0-dev.3
|
||
|
||
## Objectif
|
||
|
||
Faire évoluer la GMAO par checkpoints indépendants, reprenables et testables, depuis la consolidation de la création d'équipements jusqu'aux compteurs, au graphe technique et à la page « À documenter ».
|
||
|
||
## État initial
|
||
|
||
- Version de départ : 0.2.0-dev.1
|
||
- Checkpoint A : validé
|
||
- Migration : j5e6f7a8b9c0
|
||
- Docker local : gmao-college:0.2.0-dev.1
|
||
- Pytest baseline : 159 passed, 1 failed, 1 error (lookback GMAO historique)
|
||
- Benchmark 100 équipements : 214 requêtes après optimisation, génération 3,22 s.
|
||
|
||
## Protections
|
||
|
||
Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_* et Ancien menu 76/76 doivent rester inchangés sauf nécessité démontrée.
|
||
|
||
## Checkpoints
|
||
|
||
### A — Fondations équipements → 0.2.0-dev.1
|
||
|
||
- [x] service métier unique de création Equipment ;
|
||
- [x] lot facultatif et équipement incomplet accepté ;
|
||
- [x] création quantitative/individuelle/groupe/parent homogène ;
|
||
- [x] suppression des recherches par nom dans les nouveaux workflows ;
|
||
- [x] audit du fallback Intervention 60 minutes ;
|
||
- [x] validation des parcours et génération préventive ;
|
||
- [x] tests ciblés et pytest complet sans nouvelle régression ;
|
||
- [x] version 0.2.0-dev.1 commitée séparément.
|
||
|
||
### B — Patrimoine, profils, setup → après A
|
||
|
||
- [x] décision RoomType enrichi ou RoomProfile (RoomProfile séparé) ;
|
||
- [x] profils de locaux et propositions d'équipements (première tranche) ;
|
||
- [x] ouvrages facultatifs (RoomSurface) ;
|
||
- [x] création en masse avec prévisualisation et duplication contrôlée ;
|
||
- [x] setup Essentiel/Maintenance/Avancé affiché et Centre permanent ;
|
||
- [x] logements existants conservés et non obligatoires ;
|
||
- [ ] charge 200 locaux (mesure isolée restant à rejouer).
|
||
|
||
#### Exigences transverses B
|
||
|
||
- [x] Centre de configuration permanent, organisé en Essentiel, Maintenance, Patrimoine, Entreprises, Compteurs, Cartographie technique et Intégrations ;
|
||
- [x] états calculés « Configuré », « Incomplet », « À configurer », « Facultatif », « Attention » avec liens d'action ;
|
||
- [x] setup progressif : Essentiel, Maintenance/Patrimoine, Avancé facultatif ;
|
||
- [x] horaires de travail rattachés explicitement à l'utilisateur/technicien ; aucun horaire fictif ;
|
||
- [ ] Site → Building → Zone → Room et HousingUnit réutilisés ; logements facultatifs ;
|
||
- [ ] TaskExecutionSegment et propriétés interruptible/splittable conservés sans régression.
|
||
|
||
### C — Compteurs, consommations, contrats → 0.2.0-dev.2
|
||
|
||
- [ ] Meter/MeterReading réutilisés ;
|
||
- [ ] périmètre générique et calendrier scolaire ;
|
||
- [ ] relevés dans Ma journée ;
|
||
- [ ] consommation normalisée et alertes ;
|
||
- [ ] quotas globaux photocopieurs ;
|
||
- [ ] tests ciblés, complets, migration et version.
|
||
|
||
#### Exigences C conservées pour la reprise
|
||
|
||
- [ ] Meter/MeterReading : eau, gaz, électricité, heures, copies, cycles, autre ; nature général/divisionnaire/individuel ;
|
||
- [ ] périmètres Site, Building, Zone, Room, HousingUnit, Equipment et plusieurs compteurs par équipement ;
|
||
- [ ] périodicité de relevé, Ma journée, delta et consommation normalisée ; seuil absolu/relatif avec message « Surconsommation inhabituelle — fuite possible » ;
|
||
- [ ] calendrier scolaire contextuel pour collège, `school_calendar_aware=false` par défaut pour HousingUnit ;
|
||
- [ ] photocopieurs N&B/couleur, quotas globaux de contrat, agrégation, projection et historique de périmètre.
|
||
|
||
### D — Graphe technique générique
|
||
|
||
- [ ] décision et migration non destructive ;
|
||
- [ ] relations techniques génériques ;
|
||
- [ ] cascades électricité/eau/gaz/CVC/SSI/informatique ;
|
||
- [ ] points de coupure progressifs.
|
||
|
||
#### Exigences D conservées pour la reprise
|
||
|
||
- [ ] `Equipment.parent_id` reste limité à la hiérarchie d'inventaire ; graphe technique séparé ;
|
||
- [ ] relations extensibles : alimente, protège, isole, commande, dessert, connecté à, report de, asservi à ;
|
||
- [ ] cascades électricité/eau/gaz/chauffage/VMC/SSI/informatique et relations multiples (ex. CCF–VMC–SSI–électricité) ;
|
||
- [ ] page future « À documenter » et réutilisation du Centre documentaire.
|
||
|
||
### E — Exploitation / complétude → 0.2.0-dev.3
|
||
|
||
- [ ] page Patrimoine → À documenter ;
|
||
- [ ] navigation des relations ;
|
||
- [ ] intégration Centre documentaire ;
|
||
- [ ] compteur en retard et anomalies visibles ;
|
||
- [ ] benchmark final ;
|
||
- [ ] version 0.2.0-dev.3 uniquement si tous les critères sont démontrés.
|
||
|
||
#### Critère bêta E
|
||
|
||
`0.2.0-dev.3` signifie une bêta utilisable au quotidien sur patrimoine, équipements, interventions, préventif, entreprises, planning, Ma journée, setup et Centre de configuration. Les fonctions avancées non configurées doivent rester non bloquantes.
|
||
|
||
## Migrations prévues
|
||
|
||
Uniquement Alembic, non destructives, testées sur installation existante et neuve. Chaque checkpoint décide ses tables après audit des modèles existants.
|
||
|
||
## Risques / dépendances
|
||
|
||
- workflows historiques multiples pour Equipment ;
|
||
- données de test locales non équivalentes à une validation UI ;
|
||
- absence éventuelle de compte fonctionnel de validation ;
|
||
- coût N+1 des périmètres et des graphes ;
|
||
- règles contractuelles de quotas et calendrier.
|
||
|
||
## Définition de DONE
|
||
|
||
Un checkpoint est DONE quand son code, sa migration éventuelle, ses tests ciblés, le pytest complet, sa documentation, son statut et ses commits sont cohérents et poussés sur origin/main et audit/main.
|