docs(development): cadrer le checkpoint B

This commit is contained in:
root 2026-08-23 16:45:44 +00:00
parent b202cca760
commit e26c9bab13
5 changed files with 139 additions and 14 deletions

View file

@ -2,6 +2,34 @@
Les décisions sont ajoutées au fil des checkpoints. Les modèles existants sont privilégiés avant toute nouvelle table.
## D-005 — Centre de configuration permanent et setup progressif
**CONTEXTE** : le setup initial ne doit pas devenir une page jetable ; une GMAO utile doit accepter une configuration partielle et expliciter les actions restantes.
**OPTIONS ÉTUDIÉES** : checklist statique de fin d'installation ; tableau calculé et permanent avec liens d'action.
**CHOIX** : créer/faire évoluer un Centre de configuration permanent, organisé par domaines (Essentiel, Maintenance, Patrimoine, Entreprises, Compteurs, Cartographie technique, Intégrations), avec états calculés et intégrations facultatives non bloquantes.
**JUSTIFICATION** : rendre la configuration progressive observable et exploitable sans SQL ni connaissance de l'architecture.
**CONSÉQUENCES** : chaque contrôle doit avoir une règle de calcul et une destination UI ; Pronote, ENT, Outlook, Yeastar, IA, compteurs, logements et cartographie restent facultatifs.
**DATE/COMMIT** : 2026-08-23 / préparation checkpoint B.
## D-006 — RoomType structurel, RoomProfile séparé à étudier
**CONTEXTE** : `RoomType` classe actuellement les locaux et est utilisé par Pronote et les écrans de patrimoine, mais ne porte aucun catalogue d'équipements, de quantités ou d'ouvrages.
**OPTIONS ÉTUDIÉES** : enrichir `RoomType` ; créer un `RoomProfile` distinct relié à `RoomType` ; stocker des JSON dans `RoomType`.
**CHOIX** : `RoomProfile` séparé, avec `RoomProfileItem` et `RoomSurface` normalisés. `RoomType` reste structurel et n'est pas modifié.
**JUSTIFICATION** : éviter de casser les usages de classification/enseignement et permettre plusieurs profils de proposition pour un même type structurel.
**CONSÉQUENCES** : migrations `k6f7a8b9c0d1` et `l7a8b9c0d1e2` ajoutées ; association de profil nullable ; aucune création automatique d'équipement sans validation utilisateur.
**DATE/COMMIT** : 2026-08-23 / implémentation checkpoint B en cours.
## D-000 — Checkpoints indépendants
**CONTEXTE** : le chantier couvre plusieurs domaines avec migrations et risques différents.

View file

@ -6,9 +6,10 @@ Faire évoluer la GMAO par checkpoints indépendants, reprenables et testables,
## État initial
- Version : 0.1.0-dev.12
- Version de départ : 0.2.0-dev.1
- Checkpoint A : validé
- Migration : j5e6f7a8b9c0
- Docker local : gmao-college:0.1.0-dev.12
- 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.
@ -31,14 +32,23 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
### 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 ;
- [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) ;
- [ ] création en masse et duplication complète ;
- [ ] setup Essentiel/Maintenance/Avancé ;
- [ ] logements intégrés avec HousingUnit ;
- [x] logements existants conservés et non obligatoires ;
- [ ] charge 200 locaux.
#### Exigences transverses B
- [ ] Centre de configuration permanent, organisé en Essentiel, Maintenance, Patrimoine, Entreprises, Compteurs, Cartographie technique et Intégrations ;
- [ ] états calculés « Configuré », « Incomplet », « À configurer », « Facultatif », « Attention » avec liens d'action ;
- [ ] setup progressif : Essentiel, Maintenance/Patrimoine, Avancé facultatif ;
- [ ] 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 ;
@ -48,6 +58,14 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
- [ ] 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 ;
@ -55,6 +73,13 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
- [ ] 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. CCFVMCSSIélectricité) ;
- [ ] page future « À documenter » et réutilisation du Centre documentaire.
### E — Exploitation / complétude → 0.2.0-dev.3
- [ ] page Patrimoine → À documenter ;
@ -64,6 +89,10 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
- [ ] 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.

View file

@ -1,12 +1,12 @@
CURRENT VERSION: 0.2.0-dev.1
CURRENT CHECKPOINT: A — validé
CURRENT CHECKPOINT: B — implémentation partielle, migration à appliquer
CURRENT COMMIT: b6468a5 (version), 7681c55 (statut), 29d336e (documentation), c4bfef1 (fonctionnel)
CURRENT MIGRATION: j5e6f7a8b9c0
DOCKER VERSION: gmao-college:0.2.0-dev.1 (running; /health healthy, MariaDB connected)
LAST FULL TEST: 161 passed, 1 failed, 1 error en 198,60 s — uniquement lookback/configuration GMAO historique et son teardown
LAST TARGETED TEST: 28 passed (service Equipment, maintenance engine, scope, DayPlanner)
BLOCKERS: Aucun nouveau défaut ; les deux erreurs historiques restent autorisées
NEXT ACTION: Pour la reprise suivante, auditer RoomType/RoomProfile et décider B1 avant toute migration ; ne pas coder C/D/E
CURRENT MIGRATION: j5e6f7a8b9c0 (code migrations B non encore appliqué sur Docker)
DOCKER VERSION: gmao-college:0.2.0-dev.1 (ancienne image active ; rebuild B à faire)
LAST FULL TEST: 163 passed, 1 failed, 1 error en 224,38 s — uniquement lookback/configuration GMAO historique et son teardown
LAST TARGETED TEST: 11 passed (version, patrimoine existant, RoomProfile)
BLOCKERS: Aucun nouveau défaut de test ; checkpoint B reste partiel tant que migration, Docker et validation UI ne sont pas terminés
NEXT ACTION: Committer l'implémentation B, appliquer les migrations k6/l7 sur Docker, vérifier /configuration/ et les routes de profils
## Avancement
@ -46,3 +46,24 @@ Lire ROADMAP_020_DEV3.md et DECISIONS_020_DEV3.md, puis reprendre sur NEXT ACTIO
- 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
- [x] exigences Centre de configuration permanent ajoutées à la roadmap ;
- [x] configuration progressive et intégrations facultatives documentées ;
- [x] horaires technicien explicitement rattachés à l'utilisateur et absence de fallback rappelée ;
- [x] hiérarchie Site → Building → Zone → Room et HousingUnit documentée ;
- [x] non-régression TaskExecutionSegment/interruption documentée ;
- [x] 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 ;
- [x] décision documentée : RoomProfile séparé de RoomType ;
- [x] migration B écrite : k6f7a8b9c0d1 puis l7a8b9c0d1e2 ;
- [x] implémentation initiale des profils, propositions, surfaces et Centre de configuration ;
- [x] association facultative d'un profil aux locaux et sélection dans le bulk ;
- [x] tests ciblés B et pytest complet sans nouvelle régression ;
- [ ] rebuild Docker et application des migrations ;
- [ ] validation UI réelle et setup Essentiel/Maintenance/Avancé ;
- [ ] profils complets avec prévisualisation UI démontrée ;
- [ ] charge 200 locaux ;
- [ ] checkpoint B validé et version `0.2.0-dev.2`.

View file

@ -0,0 +1,17 @@
# Centre de configuration permanent
Le Centre de configuration est une page durable (`/configuration/`), distincte
du marqueur de fin du setup initial. Elle calcule les états à partir des
données réelles et fournit un lien d'action pour chaque point.
Sections : Essentiel, Maintenance, Patrimoine, Entreprises, Compteurs,
Cartographie technique, Intégrations.
Les états affichés sont : Configuré, Incomplet, À configurer, Facultatif et
Attention. Pronote, ENT, Outlook, Yeastar, IA, compteurs, logements et
cartographie technique restent facultatifs ; leur absence n'empêche pas le
fonctionnement courant.
Le setup initial conserve son rôle d'amorçage. Le Centre permet ensuite de
reprendre la configuration progressivement sans connaître SQL ou les modèles
internes.

View file

@ -0,0 +1,30 @@
# Architecture des profils de locaux — checkpoint B
## Décision
`RoomType` reste le type structurel d'un local (classe, couloir, sanitaire,
etc.) et conserve ses usages existants, notamment l'identification des salles
d'enseignement. Il ne devient pas un catalogue d'équipements.
Un `RoomProfile` séparé porte une proposition réutilisable :
- `RoomProfileItem` : libellé, quantité, catégorie facultative, lot suggéré,
mode groupe/individuel et sélection par défaut ;
- `RoomSurface` : composition facultative mur/sol/plafond, matériau, finition
et repère.
L'association `Room.room_profile_id` mémorise le profil utilisé comme point de
départ. Elle ne crée aucun équipement. L'application d'un profil passe par une
prévisualisation et le service commun `create_equipment`.
## Progressivité
Un local peut être créé sans `RoomType`, sans profil et sans équipement. Les
ouvrages sont facultatifs. Les lignes d'un profil sont des suggestions et les
quantités peuvent être modifiées avant validation.
## Migration
`k6f7a8b9c0d1_room_profiles.py` crée les tables de profils, propositions et
surfaces. `l7a8b9c0d1e2_assign_room_profiles.py` ajoute l'association nullable
du profil à `rooms`. Les deux migrations sont non destructives.