From ff18dfee48b9844161dc82bcc6758c5db396ddf9 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Tue, 1 Sep 2026 07:53:13 +0200 Subject: [PATCH] =?UTF-8?q?docs(=C2=A710):=20acheter=20sans=20v=C3=A9rifie?= =?UTF-8?q?r=20=E2=80=94=20figer=20le=20TAUX,=20pas=20le=20reste?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw --- docs/BRIEF_plugin_depuis_maquettes.md | 67 +++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md index 18d3549..80f1494 100644 --- a/docs/BRIEF_plugin_depuis_maquettes.md +++ b/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",