81 lines
3.1 KiB
Markdown
81 lines
3.1 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 : 0.1.0-dev.12
|
|
- Migration : j5e6f7a8b9c0
|
|
- Docker local : gmao-college:0.1.0-dev.12
|
|
- 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 ;
|
|
- [ ] version 0.2.0-dev.1 commitée séparément.
|
|
|
|
### B — Patrimoine, profils, setup → après A
|
|
|
|
- [ ] décision RoomType enrichi ou RoomProfile ;
|
|
- [ ] profils de locaux et propositions d'équipements ;
|
|
- [ ] ouvrages facultatifs ;
|
|
- [ ] création en masse et duplication ;
|
|
- [ ] setup Essentiel/Maintenance/Avancé ;
|
|
- [ ] logements intégrés avec HousingUnit ;
|
|
- [ ] charge 200 locaux.
|
|
|
|
### 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.
|
|
|
|
### 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.
|
|
|
|
### 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.
|
|
|
|
## 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.
|