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