docs(development): document checkpoint C3 analytics

docs/development/DECISIONS_020_DEV3.md

@@ -100,6 +100,18 @@ La date cible reste distincte de la date opérationnelle. L'anticipation réutil
 
 **DATE/COMMIT** : 2026-08-24 / checkpoint C2.
 
+## D-012 — Intervalles et contexte analytique C3
+
+**CHOIX** : calculer les intervalles à la demande à partir de deux relevés réels successifs, conserver les mesures brutes et annoter chaque intervalle par sa composition calendaire et ses régimes de chauffage. Les logements ne sont pas reclassés selon les vacances scolaires. Les régimes sont datés par compteur et réseau pour éviter l'hypothèse d'un chauffage global unique.
+
+**JUSTIFICATION** : éviter une table de cache difficile à invalider après correction de relevé, tout en gardant des requêtes explicites et des données historiques intactes. Une rupture de compteur ou un reset ne produit jamais de delta analytique trompeur.
+
+## D-013 — Alertes, gaz et coûts C3
+
+**CHOIX** : persister les règles et alertes C3 séparément des seuils historiques ; conserver une évidence par intervalle, dédupliquer tant qu'une alerte équivalente est ouverte, utiliser une médiane avec minimum configurable (défaut 3), puis permettre un lien relationnel vers une intervention. Les coefficients gaz sont datés et manuels prioritaires sur ceux issus de facture ; le tarif applicable est celui de la date du relevé final et le coût reste informatif.
+
+**HORS PÉRIMÈTRE** : aucune consommation avancée, contrat/quota photocopieur, moteur comptable ou C4.
+
 ## D-009 — Rattachement explicite des compteurs
 
 **CONTEXTE** : les compteurs historiques étaient obligatoirement rattachés à `Equipment`, alors que l'exploitation nécessite aussi des compteurs de bâtiment, zone, local et logement.

docs/development/ROADMAP_020_DEV3.md

@@ -53,7 +53,7 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
 
 - [x] C1 : socle Meter/MeterReading, rattachements patrimoine, hiérarchie et relevés audités ;
 - [x] C2 : échéances périodiques, Ma journée et tournées de relevés ;
-- [ ] C3 : consommations, estimations, anomalies, alertes et coûts ;
+- [ ] C3 : consommations, estimations, anomalies, alertes et coûts ; (socle en cours : migration `p1e2f3g4h5i6`)
 - [ ] C4 : contrats et quotas photocopieurs ;
 - [ ] Meter/MeterReading réutilisés ;
 - [ ] périmètre générique et calendrier scolaire ;
@@ -136,3 +136,7 @@ L'anticipation vers le dernier jour travaillé précédent réutilise `PlanningS
 Les occurrences en retard restent ouvertes jusqu'à leur traitement. Le traitement avec valeur appelle `record_meter_reading()` ; le traitement sans relevé conserve un motif, un commentaire, l'utilisateur et l'horodatage sans créer de `MeterReading`. Le remplacement d'un compteur annule explicitement ses occurrences ouvertes lors de la génération suivante et ne crée plus d'occurrence future.
 
 Les occurrences sont agrégées par `DayPlanner` dans « Ma journée » avec responsable, durée estimée et échéance, sans création de fausse intervention ni créneau horaire simulé. Une tournée regroupe les règles membres par position et expose une occurrence datée avec progression et reprise.
+
+## C3 — décisions de périmètre
+
+Les intervalles sont calculés à la demande depuis les relevés bruts et ne sont pas une nouvelle source de vérité. Les resets, baisses et changements de compteur physique ne sont jamais soustraits naïvement. Le contexte scolaire réutilise le calendrier existant ; les logements restent hors calendrier scolaire par défaut. Les régimes de chauffage sont datés et liés au compteur/réseau, afin de permettre plusieurs réseaux indépendants. Les règles et alertes C3 sont distinctes des seuils historiques de `Meter`, et les alertes ouvertes sont enrichies plutôt que dupliquées. Les conversions gaz et tarifs sont facultatifs ; aucun contrat ou quota photocopieur n'est implémenté en C3.

docs/development/STATUS_020_DEV3.md

@@ -1,12 +1,25 @@
 CURRENT VERSION: 0.2.0-dev.2
-CURRENT CHECKPOINT: C2-FIX — validation finale
+CURRENT CHECKPOINT: C3 — implémentation en cours de validation
-CURRENT COMMIT: correctifs locaux C2-FIX en cours de validation
+CURRENT COMMIT: socle C3 local en cours de validation
-CURRENT MIGRATION: o0d1e2f3g4h5 (down_revision n9c0d1e2f3g4, appliquée sur la base applicative)
+CURRENT MIGRATION: p1e2f3g4h5i6 (down_revision o0d1e2f3g4h5)
 DOCKER VERSION: gmao-college:0.2.0-dev.2 (reconstruite, healthy, MariaDB connectée)
 LAST FULL TEST: 186 passed, 1 failed, 1 error ; les deux anomalies historiques restent visibles
 LAST TARGETED TEST: 9 passed (C2 service, HTTP, fréquences, idempotence, calendrier, Ma journée, traitements, remplacement, tournée, permissions)
 BLOCKERS: validation responsive visuelle non exécutée ; aucun défaut fonctionnel B restant
-NEXT ACTION: terminer pytest complet, pousser C2-FIX sur Forgejo et GitHub principal, puis revue indépendante ; ne pas commencer C3
+NEXT ACTION: terminer les tests C3, appliquer la migration et effectuer la revue indépendante ; ne pas commencer C4
+
+## C3 — socle analytique
+
+- [x] intervalles calculés à partir de deux `MeterReading` bruts, avec rupture explicite sur reset/baisse et frontières de compteur remplacé ;
+- [x] contexte calendrier réutilisant `CollegeClosure`/`PlanningService`, logements hors calendrier scolaire par défaut ;
+- [x] régimes datés `NORMAL`/`REDUCED`/`STOP` par compteur et réseau ;
+- [x] reste parent/sous-compteurs avec qualités `EXACT`, `ESTIMATED`, `PARTIAL` ;
+- [x] règles et alertes persistées, niveaux WARNING/CRITICAL, médiane et déduplication des alertes ouvertes ;
+- [x] conversions gaz datées, priorité manuelle, tarifs facultatifs et coût informatif au tarif du relevé final ;
+- [x] tableau de surveillance et fiche analytique ;
+- [ ] migration et pytest complet C3 à finaliser ;
+- [ ] validation Playwright/base vide non effectuée ;
+- [ ] C4 non commencé.
 
 ## C2 — état et limites