docs(§10): acheter sans vérifier — figer le TAUX, pas le reste

Réponse à la question du moteur. L'escalade de l'étalement est une correction
calculée sur une grandeur qui n'existe pas sous `unmeasurable` : `remainingWh`
étant figé par contrat, le taux ne suit plus un retard mesuré, il suit l'horloge.

Et ce n'est pas qu'un risque de mur — la loi surachète sans borne : ∫ E/(T−t) dt
diverge, bornée seulement par le plafond du mécanisme. Chiffré sur notre relevé
(4 000 Wh, 18 779 s, plafond 3 500 W) : plafond atteint 1 h 09 avant l'échéance,
total ≈ 10,1 kWh pour 4,0 kWh dus — x2,5, et le facteur grandit avec la fenêtre.

Proposition : remplir `sessionWh` depuis le compteur de charge d'abord (le vrai
correctif, LM-1014-b s'y applique telle quelle) ; puis, pour ce qui reste non
mesurable, taux CONSTANT = cible ÷ fenêtre à l'ouverture, `atMaximum` jamais
vrai — le total acheté vaut exactement la cible.

La part qui nous revient : la déclaration d'une obligation sur une charge sans
mesure d'énergie devra dire, à la saisie, qu'elle sera achetée à l'aveugle, ce
qu'elle coûte par jour, et qu'elle ne pourra jamais être annoncée tenue.

`targetW`/`counts` pour l'arithmétique, `gridW` pour la phrase : confirmé.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw

docs/BRIEF_plugin_depuis_maquettes.md

@@ -2,6 +2,73 @@
 
 ---
 
+## 2026-09-01 (suite) — acheter sans vérifier : ce que nous proposons, et pourquoi
+
+**Notre position : oui, mais à taux CONSTANT — l'escalade n'a pas de justification sous
+`unmeasurable`, et elle achète 2,5 fois l'obligation.**
+
+### L'escalade est une correction calculée sur une grandeur qui n'existe pas dans ce régime
+
+L'étalement vaut `remainingWh / remainingS`. Sous `measured`, il accélère parce qu'un **retard
+mesuré** subsiste : la correction suit une preuve. Sous `unmeasurable`, `remainingWh` est **figé
+par contrat** — c'est la règle que vous avez posée hier, et elle est juste. Mais alors le taux ne
+suit plus un retard : **il suit l'horloge**. On achète davantage parce que le temps passe, pas
+parce que quelque chose est en retard. C'est le motif « chiffre crédible et faux » déplacé dans
+une **loi de commande** au lieu d'un champ.
+
+### Et ce n'est pas qu'un risque de mur : la loi surachète, sans borne
+
+Avec `remainingWh` figé, l'énergie achetée sur la fenêtre vaut `∫ E/(T−t) dt` — **elle diverge**.
+Bornée seulement par le plafond du mécanisme. Chiffré sur notre relevé du 05:47 (E = 4 000 Wh,
+T = 18 779 s, plafond 3 500 W lu dans `mechanism.maxStageW`) :
+
+| | |
+|---|---|
+| taux au plafond | **1 h 09 avant l'échéance** |
+| acheté avant le plafond | 6 073 Wh |
+| puis 4 114 s à 3 500 W | 4 000 Wh |
+| **total** | **≈ 10,1 kWh pour une obligation de 4,0 kWh — ×2,5** |
+
+Et le facteur **grandit avec la fenêtre** : plus l'échéance est lointaine, plus on surachète. Une
+obligation quotidienne sur une charge durablement non mesurable, ce n'est donc pas « la cible tous
+les jours » — c'est **deux à trois fois la cible tous les jours**.
+
+*(Arithmétique dérivée de la loi observée sur quatre cycles, pas mesurée jusqu'à l'échéance : nous
+n'avons pas laissé le banc aller au bout, et le relevé s'arrête à 767 W.)*
+
+### Ce que nous proposons
+
+1. **Remplir `sessionWh` depuis le compteur de charge** — c'est le vrai correctif, et il ferme la
+   question pour toute charge instrumentée. `meterThingId` est déjà là, `measurement.source ==
+   "meter"` dit quand c'est fiable, `totalEnergyConsumed` porte l'énergie. LM-1014-b s'applique
+   telle quelle : cumul, donc base capturée à l'ouverture et reprise à la bascule.
+2. **Pour ce qui reste non mesurable : figer le TAUX, pas le reste.** Taux = `targetWh` ÷ fenêtre
+   à l'ouverture, **constant**, `atMaximum` jamais vrai. Le total acheté vaut alors **exactement
+   la cible** — on garde « viser l'obligation entière », on perd l'escalade qui ne repose sur
+   rien. C'est le même geste que partout cette semaine : ne pas laisser une absence d'information
+   produire un chiffre qui a l'air d'en être une.
+
+### Et la part qui nous revient, sur votre règle
+
+Vous dites qu'une obligation non vérifiable ne devrait pas pouvoir déclencher un achat au plafond
+**sans que l'installateur l'ait su en la déclarant**. C'est un écran, donc c'est à nous : la
+déclaration d'une obligation sur une charge **sans mesure d'énergie** dira, à la saisie, qu'elle
+sera achetée à l'aveugle, ce qu'elle coûtera par jour, et qu'elle ne pourra **jamais** être
+annoncée tenue. Nous le construirons avec l'écran de configuration — pas avant que le §10 soit
+déployé, mais la maquette le portera.
+
+Un corollaire à ne pas perdre : sous `unmeasurable`, `ECO_FLOOR_MISSED` sortira **tous les jours,
+par construction**, puisque R6 interdit `ECO_FLOOR_MET`. Un mécanisme dont le succès est
+inobservable et l'échec quotidien ne doit pas, en plus, dépenser en accélérant. Notre écran dira
+« non vérifiable », jamais « non tenue ».
+
+### Confirmé pour l'app
+
+`targetW` / `counts` pour l'arithmétique, `gridW` pour la phrase. C'est bien ainsi que nous
+lisons, et l'écart entre les deux (766,81 vs 767) reste sous le watt.
+
+---
+
 ## 2026-09-01 — §10 vu à la sonde : les six champs, et une trajectoire à trancher
 
 **Obligation déclarée sur le banc puis retirée** — `chauffe-eau`, `needs {dailyDeadline: "12:00",