# 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 ;
- [x] charge 200 locaux (benchmark isolé et test anti-doublon).

#### 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 ;
- [x] Site → Building → Zone → Room et HousingUnit réutilisés ; logements facultatifs ;
- [x] TaskExecutionSegment et propriétés interruptible/splittable conservés sans régression.

### C — Compteurs, consommations, contrats → après validation B

- [x] C1 : socle Meter/MeterReading, rattachements patrimoine, hiérarchie et relevés audités ;
- [ ] C2 : échéances périodiques, Ma journée et tournées de relevés ;
- [ ] C3 : consommations, estimations, anomalies, alertes et coûts ;
- [ ] C4 : contrats et quotas photocopieurs ;
- [ ] 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.

#### C1 — Socle compteurs et relevés

- [x] rattachement explicite par FK nullable à Equipment, Building, Zone, Room ou HousingUnit ;
- [x] plusieurs compteurs racines possibles et relation Meter parent/enfants ;
- [x] relevé physique centralisé, baisse refusée sans reset explicite et justifié ;
- [x] corrections relationnelles auditées et index courant recalculé ;
- [x] remplacement explicite conservant l'ancien compteur et son historique ;
- [x] photo facultative du relevé, stockée selon les conventions d'upload existantes ;
- [x] unités physiques conservées, sans conversion gaz ni calcul de consommation ;
- [x] aucune utilisation de `Equipment.parent_id` pour la hiérarchie des compteurs ;
- [ ] service des échéances et intégration « Ma journée » : C2 ;
- [ ] consommation, coefficients gaz, alertes et coûts : C3 ;
- [ ] contrats et quotas photocopieurs : C4.

### 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.