docs(prévision PV): la somme vérifiée, et une configuration qui ressemble à une révision

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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p

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é.