From a5b3d5fc163689fe39137e5ce1485b49db83aeab Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Wed, 9 Sep 2026 08:10:33 +0200 Subject: [PATCH] =?UTF-8?q?docs(pr=C3=A9vision=20PV):=20la=20somme=20v?= =?UTF-8?q?=C3=A9rifi=C3=A9e,=20et=20une=20configuration=20qui=20ressemble?= =?UTF-8?q?=20=C3=A0=20une=20r=C3=A9vision?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Un second plan a été créé : le chemin de sommation a été exercé pour la première fois, sur la machine. 20,0 + 16,0 = 36,0 kWh au dixième, « 2 plans sommés », puis déduplication au cycle suivant. MA GARDE ÉTAIT JUSTE, ET SON COÛT PLUS GRAND QUE PRÉVU. L'hypothèse « les plans d'un site partagent un instant » était FAUSSE — un jitter par plan les faisait diverger en minutes. Ma garde aurait donc bloqué la somme à chaque publication de run : huit fenêtres par jour, jusqu'à une heure chacune. Corrigé chez le producteur (+etm14), et désormais au contrat : l'hypothèse est vraie par construction, pas par chance. Et la garde reste utile APRÈS le correctif : elle devient l'instrument qui l'observe. Si la boucle naturelle ne tenait pas, le journal dirait « plans de runs différents — on attend ». Une garde qui vérifie la promesse sur laquelle elle repose vaut mieux qu'une garde qu'on retire parce que la promesse a été faite. CE QUE LA SOMME REND VISIBLE : le passage de 20,0 à 36,0 kWh est enregistré comme une RÉVISION, et il n'en est pas une — la prévision n'a pas changé, l'INSTALLATION a changé. C'est le point du §8.5 annoncé au premier jour et devenu réel : comparer les 20 kWh d'avant 08:08 à une production postérieure comparerait deux installations différentes, et rien dans la table ne permet de le voir. La révision est là, sa CAUSE ne l'est pas. Proposition non implémentée : une colonne portant l'ensemble des plans, qui ne change pas la clé mais rend la cause lisible. Pas fait maintenant et délibérément — ce serait un schéma v3 une heure après la v2, sur un mécanisme qui n'a qu'une matinée d'observation. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p --- docs/DESIGN_PREVISION_PV.md | 59 +++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/docs/DESIGN_PREVISION_PV.md b/docs/DESIGN_PREVISION_PV.md index 01d0083..f9853fb 100644 --- a/docs/DESIGN_PREVISION_PV.md +++ b/docs/DESIGN_PREVISION_PV.md @@ -1003,3 +1003,62 @@ douter de l'installation, l'autre fait croire au chiffre qui la fait douter. Écrit dans la description de `GetPvForecast`, pas seulement ici : c'est un client qui construira l'écran, et c'est le contrat qu'il lira. + + +--- + +## 22. La somme vérifiée — et ce qu'elle rend visible (2026-09-09, 08:08) + +Un second plan a été créé sur le site. **Le chemin de sommation a donc été exercé pour la +première fois**, et il l'a été sur la machine : + +``` +08:08:00 [Prévision] 2 plans sommés — 48 créneaux +08:08:00 RÉVISION 484220d7 — 48 créneaux, âge 2026-09-09T03:00:00Z +08:09:00 courbe inchangée — fraîcheur mise à jour + + 7eb8a7d4 vu 08:02:00 revu 08:07:00 48 créneaux 20,0 kWh ← un plan + 484220d7 vu 08:08:00 revu 08:09:00 48 créneaux 36,0 kWh ← deux plans sommés +``` + +`20,0 + 16,0 = 36,0 kWh`, au dixième. Puis déduplication au cycle suivant. + +### 22.1 Ma garde était juste, et son coût était plus grand que je ne le pensais + +L'hypothèse « les plans d'un site partagent un instant » était **fausse** : `due()` portait un +jitter aléatoire par plan, si bien que deux plans divergeaient en quelques minutes. Ma garde +« ne sommer que des plans du même run » aurait donc **bloqué la somme** à chaque publication de +run — `issuedAt` venant d'un domaine à 3 h, cela fait **huit fenêtres par jour, jusqu'à une heure +chacune**. Pas un cas rare : un cas régulier. + +Corrigé chez le producteur (`+etm14`) : le site pilote la prévision horaire de tous ses plans dans +la même passe, et c'est désormais **au contrat**. L'hypothèse est vraie **par construction, pas +par chance**. + +> **Et ma garde reste utile après le correctif** — elle devient l'**instrument qui l'observe**. +> Si la boucle naturelle ne tenait pas, le journal dirait « plans de runs différents — on attend +> la prochaine passe ». Une garde qui vérifie la promesse sur laquelle elle repose vaut mieux +> qu'une garde qu'on retire parce que la promesse a été faite. + +### 22.2 CE QUE LA SOMME REND VISIBLE : une CONFIGURATION qui ressemble à une révision + +Le passage de 20,0 à 36,0 kWh est enregistré comme une **révision**. Il n'en est pas une : **la +prévision n'a pas changé, l'installation a changé.** + +C'est le point du §8.5, annoncé au premier jour et devenu réel : + +> *« L'historique doit retenir SOUS QUEL PLAN une prévision a été convertie — sinon un recâblage +> rend toute la série antérieure incomparable sans que rien ne le dise. »* + +**Conséquence pour la comparaison prévu/réalisé** : comparer les 20 kWh d'avant 08:08 à une +production postérieure comparerait **deux installations différentes**. Rien dans la table ne +permet aujourd'hui de le voir — la révision est là, sa **cause** ne l'est pas. + +**Proposition, non implémentée** : une colonne portant l'**ensemble des plans** (leur nombre, ou +l'empreinte de leurs identifiants) à côté de la courbe. Elle ne change pas la clé — le contenu +suffit à identifier la révision — mais elle rend la **cause** lisible, et permet d'écarter d'une +comparaison les révisions qui n'en sont pas. + +**Pas fait maintenant, et délibérément** : ce serait un schéma v3 une heure après la v2, sur un +mécanisme qui n'a qu'une matinée d'observation. Mêler deux inconnues. À reprendre quand les runs +se seront succédé.