docs: conditions de la fenêtre d'observation du week-end

Posé dimanche 2026-09-06 à 08:19 (Europe/Paris) : chauffe-eau, minEnergyWhPerDay
3000 → 2000, dailyDeadline inchangé à 12:00. Discipline habituelle — capture sur
disque avant écriture, 76 clés comparées, 1 divergence attendue, 0 imprévue — mais
PAS de restauration : la configuration reste en place tout le week-end.

Symboles de débogage laissés en place jusqu'à lundi, donc aucune couture
supplémentaire pendant la fenêtre. Les deux dernières restent 06:53:30Z (fuseau) et
09:22:57 (installation des symboles), toutes deux du 2026-09-05.

CE QUE L'ÉCRAN MONTRE À LA POSE, et pourquoi ce n'est pas un défaut. À 08:19 le
palier est ECO_FLOOR_MET avec deliveredWh = 30 475 Wh pour une cible de 2 000.
Arithmétiquement correct et sans intérêt : le compteur de l'ECS publie 1 500 W en
permanence, donc deliveredWh monte de 1,5 kWh/h que la charge soit commandée ou
non. La période a basculé hier à 12:00 ; vingt heures plus tard elle a « livré »
30 kWh.

LA FENÊTRE UTILE EST À 12:00 et dure ~80 minutes. À la bascule, la base est reprise
(LM-1013-c) : deliveredWh repart de 0 face à 2 000 Wh sur 24 h, soit une cadence de
83 W financée par le réseau si le surplus manque, que le compteur fixe comble en
2000/1500 = 80 min. Deux fenêtres sur le week-end — dimanche 12:00 et lundi 12:00.

ET C'EST LA CINQUIÈME FORME D'HOMOGÉNÉITÉ QUI FIXE CE PLAFOND. Sur un banc dont le
compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible modeste
et un chemin d'achat longuement exercé : ce qui décide n'est pas la cible, c'est la
constance du compteur. Tenir l'achat en éveil tout le week-end demanderait de
dépasser 36 kWh/jour, c'est-à-dire acheter au plafond — précisément ce qu'on
voulait éviter. La contrainte est du banc, pas du moteur.

docs/DESIGN_COMMANDE_PERDUE.md

@@ -223,3 +223,46 @@ l'objet `command` ne le distingue d'un zéro réel.
 - **Le compte des écartés est publié aussi.** Un tri dont on ne dit pas ce qu'il a jeté n'est pas
   un tri, c'est une sélection.
 
+---
+
+## 7. CONDITIONS DE LA FENÊTRE D'OBSERVATION — week-end du 2026-09-06
+
+Noté pour que les traces de lundi soient lisibles. **Rien n'a été restauré** : la configuration
+ci-dessous reste en place tout le week-end.
+
+| | |
+|---|---|
+| **Posé le** | dimanche 2026-09-06 à **08:19** (Europe/Paris ; box et atelier à la même heure depuis la correction du 2026-09-05) |
+| **Charge** | `chauffe-eau` |
+| **Changement** | `minEnergyWhPerDay` **3000 → 2000**, `dailyDeadline` inchangé à `"12:00"` |
+| **Vérification** | 76 clés comparées entre capture et relecture : 1 divergence attendue, 0 imprévue |
+| **Capture d'avant** | conservée hors dépôt, `scratchpad/loadconfig_AVANT_weekend.json` |
+| **Moteur** | `1.15.2+etm56` · plugin générique `1.14.2+etm3` |
+| **Symboles de débogage** | `libnymea1-dbgsym` / `libnymea-core-dbgsym` arm64 **laissés en place** jusqu'à lundi — donc **aucune couture supplémentaire** pendant la fenêtre |
+
+### Ce que l'écran montre à la pose, et pourquoi ce n'est pas un défaut
+
+À 08:19, le palier éco est `ECO_FLOOR_MET` avec `deliveredWh` = **30 475 Wh** pour une cible de
+2 000, `measuredSince` = `2026-09-05T10:00:00Z`. L'obligation est tenue vingt fois.
+
+**C'est arithmétiquement correct et sans intérêt** : le compteur de l'ECS publie 1 500 W en
+permanence (cf. §6), donc `deliveredWh` monte de 1,5 kWh par heure que la charge soit commandée ou
+non. La période courante a basculé hier à 12:00 ; vingt heures plus tard, elle a « livré » 30 kWh.
+
+### La fenêtre utile est à 12:00, et elle dure ~80 minutes
+
+À chaque bascule de période, la base d'avancement est reprise (`LM-1013-c`). `deliveredWh` repart
+de 0 face à une cible de 2 000 Wh sur 24 h — soit une cadence de **83 W**, financée par le réseau
+si le surplus manque. Le compteur fixe la comble en **2000 / 1500 = 80 minutes**, après quoi
+l'écran repasse à `ECO_FLOOR_MET` pour les 22,7 h restantes.
+
+**Donc deux fenêtres exploitables sur le week-end** : dimanche 12:00 et lundi 12:00, ~80 min
+chacune, où l'on voit un vrai plancher éco, son financement et sa cadence. Le reste du temps,
+l'écran montre l'état « tenue » — qui est aussi une forme à valider.
+
+> **Et c'est la cinquième forme d'homogénéité qui fixe ce plafond** (`INVENTAIRE_MOCK.md` §7).
+> Sur un banc dont le compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible
+> **modeste** et un chemin d'achat **longuement exercé** : ce qui décide n'est pas la cible, c'est
+> la constance du compteur. Choisir une cible qui tienne l'achat en éveil tout le week-end
+> reviendrait à dépasser 36 kWh/jour — c'est-à-dire acheter au plafond, précisément ce qu'on
+> voulait éviter. La contrainte est du banc, pas du moteur.