docs(development): document checkpoint C2

docs/development/DECISIONS_020_DEV3.md

@@ -84,6 +84,22 @@ Les décisions sont ajoutées au fil des checkpoints. Les modèles existants son
 
 **DATE/COMMIT** : 2026-08-23 / checkpoint A en cours.
 
+## D-011 — Échéances et tournées de relevés C2
+
+**CONTEXTE** : un relevé est un travail opérationnel planifiable, mais ne doit pas être modélisé comme une intervention. Les fréquences simples ne suffisent pas pour les dates contractuelles et les logements.
+
+**CHOIX** : créer `MeterReadingSchedule` pour la règle, `MeterReadingOccurrence` pour chaque échéance logique, `MeterReadingRound`/`MeterReadingRoundMember` pour la définition d'une tournée et `MeterReadingRoundOccurrence` pour sa réalisation datée. L'unicité `(schedule_id, target_date)` et l'unicité d'une occurrence de tournée par date rendent la génération idempotente.
+
+La date cible reste distincte de la date opérationnelle. L'anticipation réutilise le moteur horaire/calendrier existant pour les règles scolaires ; les logements sont hors calendrier scolaire par défaut. Sans horaires explicites, le système conserve la date cible plutôt que d'inventer un jour travaillé.
+
+**TRAITEMENT** : une occurrence avec relevé appelle le service C1 `record_meter_reading`. Une occurrence sans relevé conserve un motif distinguant notamment inaccessible, absent, refus et relevé non connu, sans créer de mesure artificielle. Une occurrence ouverte d'un compteur remplacé est annulée avec une raison système et reste historisée.
+
+**INTÉGRATION** : les occurrences sont une source du `DayPlanner`, avec responsable, durée et retard calculé ; elles ne créent pas d'intervention et ne simulent pas de créneau si le planificateur ne sait pas en attribuer un. Les routes de configuration sont administrateur ; le traitement d'une occurrence est limité à l'utilisateur assigné ou à un administrateur.
+
+**LIMITES C2** : génération à horizon borné autour de « Ma journée » (365 jours de regard arrière et 31 jours d'avance) ; aucune analyse de consommation, conversion, alerte, coût, contrat ou quota n'est implémentée.
+
+**DATE/COMMIT** : 2026-08-24 / checkpoint C2.
+
 ## 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

@@ -52,7 +52,7 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
 ### 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 ;
+- [x] 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 ;
@@ -80,7 +80,7 @@ Alban, watchdogs, ENT, Outlook, Pronote, Yeastar, IA, secrets, données TEST_UI_
 - [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 ;
+- [x] service des échéances, intégration « Ma journée » et tournées : C2 ;
 - [ ] consommation, coefficients gaz, alertes et coûts : C3 ;
 - [ ] contrats et quotas photocopieurs : C4.
 
@@ -126,3 +126,13 @@ Uniquement Alembic, non destructives, testées sur installation existante et neu
 ## 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 les deux dépôts configurés : Forgejo (`origin/main`) et GitHub principal (`audit/main`). `audit` désigne le remote du GitHub principal du projet ; il n'existe pas de troisième dépôt d'audit.
+
+## C2 — Planification des relevés
+
+C2 introduit une règle `MeterReadingSchedule`, des occurrences bornées et idempotentes `MeterReadingOccurrence`, ainsi que les définitions et occurrences de tournées. Les fréquences hebdomadaire, mensuelle, semestrielle, annuelle et annuelle à date fixe sont conservées comme valeurs extensibles, sans enum SQL fermée. La date cible/contractuelle est conservée séparément de la date opérationnelle.
+
+L'anticipation vers le dernier jour travaillé précédent réutilise `PlanningService.get_working_hours()` lorsque le périmètre est scolaire et qu'une configuration horaire explicite existe. Les compteurs de logements utilisent par défaut un périmètre hors calendrier scolaire. En l'absence d'horaires explicites, aucune fermeture n'est inventée et la date cible est conservée.
+
+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.

docs/development/STATUS_020_DEV3.md

@@ -1,12 +1,25 @@
 CURRENT VERSION: 0.2.0-dev.2
-CURRENT CHECKPOINT: C1 — clôture
+CURRENT CHECKPOINT: C2 — implémentation finale en validation
-CURRENT COMMIT: série C1-CLOSE (8ab3dce, 4a656b3, documentation finale)
+CURRENT COMMIT: 6017758 (implémentation) ; documentation C2 en cours
-CURRENT MIGRATION: n9c0d1e2f3g4 (appliquée sur la base applicative)
+CURRENT MIGRATION: o0d1e2f3g4h5 (down_revision n9c0d1e2f3g4, appliquée sur la base applicative)
 DOCKER VERSION: gmao-college:0.2.0-dev.2 (reconstruite, healthy, MariaDB connectée)
-LAST FULL TEST: 177 passed, 1 failed, 1 error ; le failed et l'error sont les deux anomalies historiques lookback/teardown
+LAST FULL TEST: 185 passed, 1 failed, 1 error ; les deux anomalies historiques restent visibles
-LAST TARGETED TEST: 9 passed (C1-CLOSE service, HTML, JSON équipement, historique et compteur actif)
+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: revue indépendante finale C1
+NEXT ACTION: pousser la série C2 sur Forgejo et GitHub principal, puis revue indépendante ; ne pas commencer C3
+
+## C2 — état et limites
+
+- [x] règles hebdomadaire, mensuelle, semestrielle, annuelle et date annuelle fixe ;
+- [x] occurrences idempotentes à horizon borné, retard persistant et traitement avec/sans relevé ;
+- [x] intégration dans `DayPlanner`/« Ma journée » avec responsable et durée ;
+- [x] tournées ordonnées, occurrences de tournée et progression ;
+- [x] migration `o0d1e2f3g4h5` appliquée sur la base existante ;
+- [x] tests C2 ciblés et absence de nouvelle régression dans le pytest complet ;
+- [ ] validation sur base vide non effectuée ;
+- [ ] validation Playwright authentifiée desktop/tablette/mobile non effectuée ;
+- [ ] mesures SQL montrent encore un coût élevé sur les parcours complets (`Ma journée` : 199 requêtes / 4,8439 s ; tournée : 88 requêtes / 0,6140 s dans le scénario instrumenté) ;
+- [ ] C3 et C4 non commencés.
 
 ## Avancement