From be556ef2079679b0b164c0ded247949b1d987b91 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sat, 5 Sep 2026 07:39:15 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20quatri=C3=A8me=20mode=20d'=C3=A9rosion,?= =?UTF-8?q?=20et=20la=20troisi=C3=A8me=20nature=20d'heure=20murale?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit QUATRIÈME MODE D'ÉROSION — l'inverse du troisième. La règle immortelle survit parce que sa garde la protège ; celle-ci meurt parce que le CHEMIN qui y menait s'est raréfié, et c'est un CORRECTIF qui l'a raréfié. Le taux constant (LM-1013-b-v) a été décidé le 2026-09-01 avec son chiffrage. Puis sessionWh a été alimenté depuis le compteur de charge et `unmeasurable` est passé de « la V2C, tous les jours » à trois cas matériels rares. La décision n'a jamais été écrite, et plus personne ne passait devant pour s'en apercevoir. Ce qui rend la classe traître : le correctif est un PROGRÈS. On ne se méfie pas de ce qui améliore les choses. Réduire un régime dégradé à ses cas irréductibles est exactement ce qu'il faut faire — et c'est ce qui a fait disparaître la décision de la vue. Parade : quand un lot RÉDUIT la fréquence d'un chemin, lister ce qui vivait dessus et n'a pas été fait. Une décision non écrite ne se périme pas au rythme de sa pertinence mais au rythme de sa VISIBILITÉ, et les deux viennent de se découpler. UN CHIFFRE FAUX DANS UNE SPEC finit par servir de prémisse. Variante numérique du raisonnement faux sous une conclusion juste — et elle se transmet plus facilement, parce qu'un chiffre se cite et se recopie sans ses conditions. Le ×2,5 aurait voyagé avec « 4 kWh » et sans « fenêtre de 2,5 h ». Règle : un chiffre porte les conditions qui le produisent, ou il se refait avant d'être écrit ; et quand il change, la spec garde les deux valeurs et la raison de l'écart. « LENT PAR CONSTRUCTION » ET « FIGÉ » ONT LA MÊME FORME. Règle d'investigation, pas un fait sur selfConsumptionRate — lui va bien : sur un cycle de surplus complet il a parcouru 53,4 → 98,4 en 54 valeurs distinctes. La leçon n'est PAS « observer plus longtemps » : ça aurait marché ici et ça échoue sur une grandeur à cadence horaire. Le discriminant est la NATURE de la grandeur — instantanée, cumulée sur une période, événementielle — et elle se lit dans le contrat, pas dans le signal. Sans cette phrase, toute observation est trop courte ou trop longue sans qu'on puisse le savoir. TROISIÈME NATURE D'HEURE MURALE : la période de REPORTING. GetEnergyRatios dérive ses Δ depuis minuit local. Elle suit l'installation, ce qui est le bon comportement — mais elle repose sur la même prémisse non vérifiée que l'échéance client : que le fuseau de la box SOIT celui de l'installation. Sur .75, le bilan journalier de l'app se remet à zéro à 01:00 heure française, et rien ne le dit. Ce que la troisième ajoute : la prémisse « la box est bien réglée » ne porte pas seulement une saisie, elle porte des GRANDEURS PUBLIÉES. Une échéance mal fuseau-horée se corrige d'un réglage ; un bilan journalier découpé au mauvais endroit a déjà été lu, affiché, et peut-être facturé. La colonne « qui le vérifie » de DESIGN_FUSEAU.md répond « personne » pour celle-là. --- AGENTS.md | 55 +++++++++++++++++++++++++++++++++++++++++ docs/DESIGN_FUSEAU.md | 20 ++++++++++++--- specs/spec_loadmodel.md | 7 ++++++ 3 files changed, 78 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index ac0d149..db7ab54 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1093,6 +1093,61 @@ aucune, la décision est une intention, et elle se périmera à la vitesse du co > levée. « Ce champ reste absent **tant que** rien ne le mesure » se relit et se lève ; « ce > champ ne doit pas exister » se relit et s'obéit. +> **Un QUATRIÈME mode d'érosion, et il est l'inverse du troisième (2026-09-04).** La règle +> immortelle survit parce que sa garde la protège. Celle-ci meurt parce que **le chemin qui y +> menait s'est raréfié** — et c'est un CORRECTIF qui l'a raréfié. +> +> Cas d'école, le taux constant sous `unmeasurable` (`LM-1013-b-v`). Décidé le 2026-09-01, avec +> son chiffrage et sa raison. Puis `sessionWh` a été alimenté depuis le compteur de charge, et le +> régime `unmeasurable` est passé de « la V2C, tous les jours » à **trois cas matériels rares**. +> La décision n'a jamais été écrite : ni dans le code, ni dans la spec, ni au contrat. Trois jours +> plus tard, elle a été retrouvée par une question, pas par un contrôle. +> +> **Ce qui rend cette classe traître, c'est que le correctif est un PROGRÈS.** On ne se méfie pas +> de ce qui améliore les choses. Réduire un régime dégradé à ses cas irréductibles est exactement +> ce qu'il faut faire — et c'est précisément ce qui a fait disparaître la décision de la vue : +> plus personne ne passait devant, donc plus rien ne la rappelait. +> +> **Parade** : quand un lot RÉDUIT la fréquence d'un chemin, lister ce qui vivait sur ce chemin +> et n'a pas encore été fait. Une décision non écrite ne se périme pas au rythme de sa +> pertinence, elle se périme au rythme de sa VISIBILITÉ — et les deux viennent de se découpler. +> Une décision qu'on prend sans l'écrire le jour même mise sur le fait qu'on repassera devant. + +> ### Un chiffre faux dans une spec finit par servir de prémisse à quelqu'un (2026-09-04) +> +> Le chiffrage qui justifiait le taux constant — « ×2,5 sur une obligation de 4 kWh » — a été +> **refait plutôt que repris** au moment de l'écrire. Sur la fenêtre quotidienne, qui est celle du +> modèle, c'est **×4,75** ; le ×2,5 valait pour une fenêtre bien plus courte. La conclusion ne +> bougeait pas, le chiffre si. +> +> **C'est la variante numérique du raisonnement faux sous une conclusion juste** (bloc +> ci-dessus), et elle se transmet plus facilement : un chiffre se cite, se recopie, et entre dans +> le calcul de quelqu'un d'autre sans que personne ne remonte à ses conditions. Ici il aurait +> voyagé avec « 4 kWh » et sans « fenêtre de 2,5 h ». +> +> **Règle** : un chiffre écrit dans une spec porte les conditions qui le produisent, ou il est +> refait avant d'être écrit. Et quand il change, le dire — la spec garde les deux valeurs et +> pourquoi elles diffèrent, sinon le lecteur qui se souvient de l'ancienne croit à une erreur. + +> ### « Lent par construction » et « figé » ont la même forme — c'est une règle d'investigation +> +> Relevé le 2026-09-04 sur `selfConsumptionRate`, soupçonné d'être un compteur figé de plus : +> constant à 100 sur 40 secondes d'observation, pendant qu'`autonomyRate` variait à côté. +> +> Il n'était pas figé. C'est un **Δ de cumuls sur la journée locale** : il bouge lentement par +> construction, et 100 % était la valeur JUSTE — zéro export cumulé sur la journée à cet instant. +> Sur un cycle de surplus complet il a parcouru **53,4 → 98,4**, en 54 valeurs distinctes. +> +> **La leçon n'est pas « observer plus longtemps ».** Elle aurait marché ici, et elle échoue +> ailleurs : une grandeur à cadence horaire résisterait à une heure d'observation. Le discriminant +> n'est pas la durée, c'est **la NATURE de la grandeur** — instantanée, cumulée sur une période, +> événementielle. Elle se lit dans le contrat, pas dans le signal. +> +> **Règle** : avant de conclure qu'une grandeur est figée, dire ce qu'elle est censée faire et à +> quelle cadence. Sans cette phrase, toute observation est trop courte ou trop longue sans qu'on +> puisse le savoir — et c'est ainsi qu'on ouvre une chasse au défaut sur un champ qui va bien, +> après en avoir laissé passer un qui, lui, l'était vraiment. + > **Fait de méthode, relevé le 2026-08-30** : la règle d'ECS-415 était **déjà écrite**, dans le > commentaire de la branche voisine du même fichier, **à trois lignes** de la branche fautive > (« ce retour était MUET, si bien que "état déjà bon" ne se distinguait pas de "action jamais diff --git a/docs/DESIGN_FUSEAU.md b/docs/DESIGN_FUSEAU.md index 317584e..d048dcc 100644 --- a/docs/DESIGN_FUSEAU.md +++ b/docs/DESIGN_FUSEAU.md @@ -75,10 +75,22 @@ ce qu'on s'interdit ailleurs (`measurement.source`, `rankOrigin`, `progress.regi Elles ne prennent pas leur fuseau au même endroit, et les confondre est le piège. -| | nature | fuseau qui fait foi | -|---|---|---| -| `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation | -| heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est DÉFINI | +| | nature | fuseau qui fait foi | qui le vérifie | +|---|---|---|---| +| `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation | l'app, à la saisie | +| heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est DÉFINI | `LM-1005-b`, au lot tarifaire | +| taux journaliers (« minuit local ») | **période de reporting** | celui de l'installation | **personne** | + +La troisième s'est trouvée en cherchant autre chose : `GetEnergyRatios` dérive ses Δ **depuis +minuit local** (`docs/INTERFACE_energyratios.md` §2). Elle suit l'installation, ce qui est le bon +comportement — mais elle repose sur la même prémisse non vérifiée que la première : que le fuseau +de la box SOIT celui de l'installation. Sur `.75`, le bilan journalier de l'app se remet à zéro à +01:00 heure française, et rien nulle part ne le dit. + +**Ce que la troisième nature ajoute au raisonnement** : elle montre que la prémisse « la box est +bien réglée » ne porte pas seulement une saisie, elle porte des **grandeurs publiées**. Une +échéance mal fuseau-horée se corrige d'un réglage ; un bilan journalier découpé au mauvais +endroit a déjà été lu, affiché, et peut-être facturé. Une plage d'heures creuses française est définie en `Europe/Paris` par le fournisseur, pas « à l'heure locale de la box ». Une box française mal réglée ne décale pas seulement diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md index 1af45b3..2bd5109 100644 --- a/specs/spec_loadmodel.md +++ b/specs/spec_loadmodel.md @@ -590,6 +590,13 @@ tarif est défini.** > |---|---|---| > | `dailyDeadline`, « avant 7 h » | **habitude du client** | celui de l'installation | > | heures creuses, Tempo, EPEX | **calendrier réglementé** | celui où le tarif est **défini** | +> | taux journaliers (« minuit local ») | **période de reporting** | celui de l'installation | +> +> La troisième a été trouvée en cherchant autre chose (2026-09-04) : `GetEnergyRatios` calcule +> ses Δ **depuis minuit local**. Elle suit l'installation, ce qui est CORRECT — mais seulement si +> le fuseau de la box est celui de l'installation. Sur `.75`, en `Europe/London`, le bilan +> journalier de l'app se remet à zéro à **01:00 heure française**. Le comportement du moteur est +> juste ; c'est la prémisse qui est fausse, et rien ne la vérifie. > > Une plage d'heures creuses française est définie en `Europe/Paris` par le fournisseur, pas > « à l'heure locale de la box ». Les confondre ne décale pas un affichage : **ça achète au