Le §7 disait « des compteurs figés fabriquent de faux cas ». La fenêtre du
2026-09-08 (292 points par charge) donne le chiffre : σ = 1879 W sur la V2C,
0,0 W sur les trois autres.
Aucun compteur du banc ne suit la commande de la charge qu'il mesure, sauf un.
Ce n'est pas « des instruments imprécis » mais UN SEUL INSTRUMENT VALIDE SUR
QUATRE, et la conséquence change de nature : toute conclusion tirée de ce banc
sur l'OBÉISSANCE des charges est une conclusion sur cette borne, jamais sur le
moteur.
Le critère §6 rend le manque visible, il ne le comble pas — il écarte
correctement les trois compteurs constants, sans nommer personne, sur la seule
propriété observable de la donnée. Mais un tri qui garde un instrument sur
quatre a trié, il n'a pas mesuré.
De vrais SDM120 sur la PAC et l'ECS sont prévus en fin de semaine. C'est la
condition d'EXISTENCE de l'étape 4, pas un confort : décider de rejouer une
commande demande de savoir si des commandes se perdent, et la question n'est pas
posable sur un banc qui ne mesure qu'une charge.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Retenu : déduplication sur le contenu, pas de requête meta.json. Mais le coût
n'est pas un décalage de cycle — c'est un HORIZON FAUX DE PLUSIEURS HEURES.
Entre l'initialisation d'un run et sa mise à disposition il s'écoule la latence
de publication du modèle : des heures pour un modèle global. Donc
targetAt − receivedAt n'est pas l'horizon, il est trop court de toute cette
latence, systématiquement et dans le même sens. Une prévision qu'on croirait à
H−1 peut être le run de H−5.
Ce que la déduplication sauve : les BORNES des révisions — combien, et laquelle
s'applique. Ce qu'elle ne sauve pas : leur ÂGE. « Quelle prévision » est juste,
« quel horizon » est faux. Sans effet sur ce lot qui AFFICHE ; déterminant pour
l'apprentissage, dont l'objet est justement de corréler l'erreur à l'horizon.
Trois conditions :
1. La colonne s'appelle receivedAt, JAMAIS issuedAt. Un nom qui promet l'heure
du run fabrique le calcul faux tout seul : quelqu'un écrira
targetAt - issuedAt et obtiendra un nombre plausible. Et il faut l'écrire :
aucun horizon ne se calcule depuis receivedAt.
2. La déduplication compare les points COMMUNS, pas la charge utile. Si la
fenêtre glisse, un == naïf verrait une révision toutes les heures —
exactement ce que la déduplication existe pour éviter. Je code la comparaison
sur l'intersection dans les deux cas : elle est correcte pour les deux et ne
dépend pas d'un comportement du voisin qui pourrait changer sans préavis.
3. La dette meta.json se rouvre AVEC son consommateur. La décision reposait sur
« aucun consommateur ne le demande » et elle RESTE juste : un affichage n'a
pas besoin de l'âge du run. Le jour où quelque chose corrèle l'erreur à
l'horizon, meta.json devient nécessaire — et la rouvrir maintenant au nom
d'un besoin supposé serait payer une requête par cycle pour un calcul que
personne ne fait.
Volume confirmé : 24-48 points, 4-8 révisions/jour ⇒ ~200-400 lignes/jour au
lieu des 1150 estimées sur révision horaire.
Et la dette forecastModel : la colonne model reste NULLE tant que la correction
n'est pas livrée. Un NULL qui dit « on ne sait pas » est honnête ; une valeur
qui dit « ce qu'on avait demandé » est fausse d'une façon parfaitement crédible.
Aucun remplissage rétroactif.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Découpage tranché : ems n'appelle pas, l'invariant 10 reste. La distinction
retenue est plus fine que « zéro réseau » — une intégration qui lit une API perd
UNE ENTRÉE quand le lien tombe ; un experience-plugin qui appelle met LA LOGIQUE
DE DÉCISION sous dépendance distante. L'attribution CC BY 4.0 disparaît avec le
découpage au lieu d'être gérée.
LE PRÉCÉDENT CITÉ NE COUVRE PAS CE LOT. awattar/tempo/spothinta sont des
précédents d'intégrations qui APPELLENT. Le plugin awattar amont n'expose que
des SCALAIRES — currentMarketPrice, average, lowest, highest, rank, validUntil.
La série ne traverse jamais : l'amont a résolu le problème en appelant DEUX
FOIS. Il n'existe donc aucun canal éprouvé pour une série, parce que personne
n'en a construit.
ET LE MOTEUR APPELLE DÉJÀ : spotmarketdataproviderawattar.cpp, dans CE dépôt,
sort en HTTPS vers api.awattar.at et alimente planSpotMarketCharging() — une
DÉCISION. C'est ce que l'invariant 10 interdit, en service, hérité et jamais
choisi. Un invariant qui a une exception non déclarée n'est plus un invariant,
c'est une habitude. À trancher séparément.
Les trois grandeurs, sur le code et non la doc :
- taille : plafond dur à 1 MiB (jsonrpcserverimplementation.cpp:554, connexion
larguée au-delà). Une courbe 48 h fait 2-5 ko — la taille n'est pas le sujet ;
- rediffusion : PAR RÉVISION, pas par cycle. thing.cpp dédoublonne
(if (oldValue == newValue) return). La prémisse surestimait d'un facteur 60 ;
- nommage : forecastPvCurve, et le mot dit que c'est un canal.
Les deux vrais dangers ne sont pas la taille : « cached » réécrirait things.conf
toutes les heures sur une carte SD (cached: false obligatoire), et la
JOURNALISATION D'ÉTAT créerait une base de données par une case à cochée dans
l'app — chaque révision copiant le JSON entier dans energylogs.sqlite, sans que
personne l'ait décidé.
Et ce que je vois de plus : un JSON qui traverse n'a plus de schéma. Un numéro
de version DANS la charge utile, avec refus plutôt qu'interprétation au mieux —
sinon le symptôme d'un changement de forme est « courbe vide », indistinguable
d'une nuit. issuedAt vient aussi de la charge utile, jamais de l'instant de
réception : sinon un redémarrage réétiquette la série et la table bitemporelle
perd ce qu'elle existe pour retenir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Le §1 de ce design fait appeler une API distante par ems. C'est interdit ici, et
l'interdiction est explicite à quatre endroits : AGENTS.md invariant 10 (« aucun
appel réseau sortant vers un service distant […] le moteur expose l'état, il ne
contacte personne », dont la seule exception nommée est un socket local/LAN) et
docs/SAFETY.md, trois fois.
Ce n'est pas une objection de style : « fonctionne sans internet » est un
argument produit, et le mode dégradé L2 est bâti sur l'idée que rien
d'essentiel ne dépend d'un lien externe.
Je n'avais PAS vu ce conflit en écrivant le design — il a été soulevé hors de ce
fil, avec le point d'attribution CC BY 4.0 qui va avec : l'obligation suit
l'appelant, donc si ems appelle, elle atterrit dans un dépôt où elle n'est
écrite nulle part et serait perdue en silence, dans un dépôt GPL publié.
Aucun code avant arbitrage. Deux issues, et ce n'est pas à l'agent de trancher :
soit l'invariant 10 est amendé avec sa raison écrite et l'attribution posée ici,
soit le découpage change et l'appel reste chez le plugin météo.
Trois décisions rendues, consignées :
- nouvelle table, et la raison est plus forte que la mienne — la CLÉ CHANGE DE
NATURE, une prévision révisée n'a rien à faire dans la base du mesuré ;
- un Get* sans *Changed : l'invariant 11 vise l'ÉTAT VIVANT, pas l'historique.
La distinction n'y était pas écrite ; l'appliquer mécaniquement aurait produit
une notification par heure sur une donnée que personne n'attend en direct ;
- aucun effet sur l'arbitrage. Le jour où l'étalement éco lira la prévision, ce
sera un lot à part — et le §10 est la seule place où elle mordrait, en pariant
sur une courbe dont le §3 dit qu'elle est un plafond systématique.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Nouveau lot cadré par Patrick. Le plugin openmeteo reste météo pure ; les plans
PV, la conversion, l'appel API et l'historique vivent ici.
LE POINT DE CONCEPTION : la table n'est pas « valeur par heure » mais « valeur
par heure, telle que prévue à tel moment ». La clé est la PAIRE
(targetAt, issuedAt). Avec targetAt seul, chaque rafraîchissement écrase le
précédent : on perd les révisions, donc la comparaison prévu/réalisé — ce qu'on
veut précisément montrer. Même distinction que measuredSince.
Conséquence de contrat que le cadrage n'énonçait pas : « prévu » ne veut rien
dire sans HORIZON. Trois lectures (courante, veille, H−1) répondent à trois
questions ; publier « prévu » sans dire laquelle laisse deux écrans montrer deux
courbes pour le même jour.
Repris de l'agent openmeteo, mesuré et non supposé : indexation rétrograde ;
cinq facteurs ignorés, TOUS optimistes — donc un biais signé, pas un bruit : la
conversion produit un PLAFOND, pas une estimation ; la dispersion d'ensemble est
ANTICORRÉLÉE au biais, donc un indicateur de confiance qui rassure le plus quand
il se trompe le plus — pire que pas d'indicateur, et l'affiner l'empire ; et la
correction prévu↔mesuré est un apprentissage, hors GPL.
Le GPL n'apprend pas, il rend l'apprentissage POSSIBLE : la table bitemporelle
EST l'interface avec Héos, et l'écraser à chaque révision détruirait la matière
pour toujours sans que rien ne le signale.
Cinq ajouts au cadrage : targetAt en epoch UTC jamais en heure murale (le piège
du 6 septembre appliqué à une série entière — vérification sur des jours de 23 h
et 25 h) ; rétention 7 jours pleins puis effondrement aux DEUX bouts, parce que
n'en garder qu'un détruit la révision ; stockage chez nous et non dans
energylogs.sqlite, que l'amont migre ; l'absence est un TROU, jamais un zéro ;
et l'historique doit retenir SOUS QUEL PLAN une prévision a été convertie, sinon
un recâblage rend la série antérieure incomparable en silence.
Trois choses manquent pour coder, dont la convention d'indexation AVEC ses
paramètres : reprendre une conclusion sans ses prémisses, c'est hériter d'un
fait vrai sous des conditions qu'on ne saura pas reproduire.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
DÉCISION PRODUIT (Patrick, 2026-09-08, après validation du lot sur le banc) :
trois modes — Normal (manuel), PV, Min+PV — et le boost n'en est PAS un
quatrième. C'est la dérogation : un bouton d'action à côté du sélecteur, posé
par SetLoadDerogation et non par SetChargingInfo, avec sa durée obligatoire et
bornée [60 s, 6 h] que l'écran doit faire saisir. Gravé dans les RÉPONSES
FIGÉES : un mode se choisit et dure, une dérogation répond à un besoin ponctuel
et s'efface — les deux ne se rangent pas au même endroit.
CRITÈRE DE TRI DE L'ÉTAPE 4 — une clause de plus, écrite sur la mesure. Une
dérogation fait bouger la consigne de plusieurs kilowatts d'un coup, et CHAQUE
BORD ouvre une divergence : à l'ouverture la voiture négocie sa montée (13800
attendus, 3930 mesurés, convergence en 300 s), à la fermeture la borne n'a pas
encore décru (0 attendu, 8367 mesurés).
La fermeture est la plus trompeuse : immédiate, énorme, et trait pour trait
semblable à une commande ignorée. Le discriminant est temporel et déjà publié —
une divergence née dans le même cycle qu'un DEROGATION_ENDED, ou qu'un
DEROGATION_ACTIVE neuf, est une transition.
Sans cette clause, chaque boost compterait pour DEUX incidents, et l'étape 4 se
justifierait d'elle-même en comptant ses propres transitoires : le mécanisme du
§6.2 — un instrument qui fabrique la preuve dont il a besoin — déplacé du banc
vers la mesure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Même borne, même durée, +etm61 : commandée 13 à 20 A au lieu de 9, mesurée
8,4 kW au lieu de 4,4, et 716 Wh livrés en 5 minutes contre 276 en 10. Le motif
dit maintenant « 13800 W achetés sur 13800 W possibles » et boundBy vaut
loadCeiling — le plafond suit le soutirage de la maison d'un cycle à l'autre,
parce que evPhaseAllowanceW() le recalcule sur la bonne grandeur.
Trois observations gardées, dont une pour l'étape 4 : la FERMETURE d'une
dérogation ouvre elle aussi une divergence (attendu 0 W, mesuré 8367 W), et
elle est plus trompeuse que celle d'ouverture. Une divergence qui naît dans le
même cycle qu'un DEROGATION_ENDED est une descente en cours, jamais une
commande perdue — sans quoi chaque boost compterait pour un incident.
La fin par débranchement reste non éprouvée : la voiture est revenue avant les
deux confirmations. Le mécanisme a en revanche montré ce qu'on lui demande —
une absence isolée n'a PAS terminé la dérogation (LM-1500-c).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Deux défauts trouvés par le premier essai au banc (2026-09-08, 11:05→11:16),
et le premier est celui que Patrick a vu en regardant la voiture.
LM-1500-h — UNE BORNE N'EST PAS ÉCRÊTÉE DEUX FOIS.
La tête de passe éco appliquait `margeRestante` au plafond d'une borne. Or
`margeRestante` est la marge d'UNE phase, et le plafond d'une borne triphasée
est une enveloppe sur TROIS : les comparer divise son allocation par trois.
Mesuré : marge de 6 210 W sur la phase la plus chargée, plafond de cycle à
13 800 W, borne servie à 6 210 — 9 A par phase au lieu de 27, 4 kW au lieu des
11 que la voiture pouvait prendre.
Le plafond d'une borne porte DÉJÀ l'autorisation de soutirage :
evPhaseAllowanceW() la calcule et la multiplie par le nombre de phases
occupées. La passe confort ne fait pas cette faute, et son commentaire dit
pourquoi depuis 3g-2 — « mieux vaut la borne mieux informée que la borne la
plus sévère ». Je l'ai réécrite quinze lignes plus haut sans la relire : une
règle notée à un seul endroit du code n'est pas une règle.
L'erreur allait dans le sens PRUDENT, donc rien ne la signalait — ni le
disjoncteur, ni le délestage, ni un test qui vérifie qu'on ne dépasse pas. Elle
ne se voyait qu'en regardant la voiture.
LM-1500-g — ÉCRIRE UN MODE PENDANT UNE DÉROGATION LA TERMINE.
Choisir un mode est durable ; une dérogation répond à un besoin ponctuel. Le
durable prime, et il prime tout de suite. Et SANS restituer le mode mémorisé,
qui écraserait celui que l'utilisateur vient de choisir.
Le cas vient du banc : le bouton « boost » de l'app écrit encore
ChargingModeNormal. Reçu pendant une dérogation, il fait restituer les valeurs
manuelles par l'amont — chargingEnabled à FAUX — et arme un verrou de 300 s,
pendant que la dérogation continue de commander 9 A. Deux commandeurs pour un
organe, et six minutes de dérogation servie sur le papier dans une borne
éteinte. Seul le journal de divergence le voyait, sans pouvoir en dire la cause.
Deux autres corrections du même essai :
- DEROGATION_ACTIVE et DEROGATION_ENDED sont rendus en français au journal ;
ils sortaient en « (motif inconnu …) ». Le repli 7-c a tenu — le code brut et
ses paramètres, jamais une chaîne vide — mais la ligne lue par l'utilisateur
était illisible.
- poseDerogation() prend l'instant en paramètre. Elle lisait l'horloge murale
quand le cycle lit l'horloge injectée : sans effet en production, où les deux
sont la même, mais sous test la fin par durée n'arrivait jamais. Trouvé par le
test, pas par la lecture.
Et `setChargingInfo() déclenche un cycle` est gravé dans AGENTS.md comme une
PROPRIÉTÉ : ce qui l'entoure a un ordre qui compte, dans les deux sens, et
ENERGY_SIMULATION supprime précisément l'appel — le chemin fautif n'existe pas
sous test.
simulation 69/69, loadmodel 26/26, charging 48/48, spotmarket 32/32,
ci-quality 4/4, build 0 erreur 0 warning.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
setChargingInfo() appelle update() lui-même, et le lot le touche aux deux bouts.
À LA POSE, l'ordre décide d'une minute. L'écriture du mode vient désormais en
DERNIER, après l'insertion dans m_derogations : le cycle qu'elle déclenche
trouve la dérogation déjà posée et la sert immédiatement. L'ordre inverse la
lui faisait manquer d'un cycle — soixante secondes d'attente sur un mécanisme
dont la définition est « tout de suite ».
À LA FIN, la restitution est différée d'un tour de boucle. Les fins sont
évaluées DEPUIS update() ; y appeler setChargingInfo() imbriquait un update()
dans un update() — deux plans construits et deux dispatchs pour le même
instant, sur des charges qu'un seul des deux croirait avoir commandées.
update() n'a aucun verrou de ré-entrance : rien ne l'aurait signalé, et la
trace aurait montré une borne commandée deux fois sans cause lisible.
simulation 68/68, ci-quality 4/4, build 0 erreur 0 warning.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Une dérogation n'est pas un mode. Un mode se choisit une fois et vaut jusqu'au
prochain choix ; une dérogation répond à un besoin ponctuel et s'éteint avec
lui. Un boost encore actif après la fin est un mode qu'on a oublié de quitter.
Elle se superpose au mode courant, sert la charge à son MAXIMUM en tête de
passe éco — devant toute autre charge, quel que soit son rang — financée au
réseau. Le rang classe ce que l'installateur décide (LM-1002) ; une dérogation
est une action ponctuelle de l'utilisateur, et passe par une porte que LM-1002
ne ferme pas.
Mais elle ne surplombe PAS la sûreté : DRAW_CAP la borne et le délestage la
reprend. Servie la première dans ce qui RESTE, jamais au-delà — sans quoi on
rouvrirait le second chemin d'achat refusé au minimum réseau (LM-1500-e).
LA DURÉE EST OBLIGATOIRE ET BORNÉE, refusée à la pose hors de [60 s, 6 h].
C'est la règle du lot : une dérogation qui ne sait pas dire quand elle finit ne
devrait pas exister (LM-1500). Elle reste armée même avec une cible, parce
qu'une cible repose sur un instrument et qu'un instrument peut se taire — à la
perte du lien, la V2C FIGE sessionEnergy au lieu de l'effacer (LM-1012-d) : une
dérogation « 20 kWh puis stop » dont le compteur reste à 12 kWh n'atteint
jamais sa cible.
Trois décisions prises en écrivant, absentes du design :
- Les fins se lisent dans le CONTEXTE DU CYCLE, pas dans les adaptateurs.
evaluerDerogations() tourne entre buildContext() et getPlan(), sur ce que le
scheduler va lire. Une seconde lecture donnerait une seconde vérité, et une
dérogation pourrait finir sur une mesure que le plan ne voit pas. C'est aussi
ce qui rend le débranchement gratuit : la borne est déjà filtrée du contexte,
son absence EST le signal.
- measurementLost ne mord QUE s'il y a une cible (LM-1500-b). Sans cible, rien
ne dépend de la mesure : couper là punirait la charge du silence d'un
instrument dont elle n'a pas besoin. Et le critère est
telemetry.sessionMeasurable, jamais progress.regime : `progress` est absent
d'une charge sans obligation en énergie, c'est-à-dire exactement le cas du
boost — le critère aurait été inerte.
- La base de la cible se capture au PREMIER CYCLE, pas à la pose : au moment où
l'utilisateur appuie, aucun cycle n'a construit de contexte. Prendre 0
compterait depuis le début de la session — une dérogation « 5 kWh » posée sur
une session déjà à 6 kWh serait atteinte avant d'avoir commencé (LM-1012-b).
Le mode précédent se MÉMORISE, il ne se déduit pas (LM-1500-d). Revenir à un
défaut détruirait un réglage en silence, et sur une borne la sortirait de
l'arbitrage : une dérogation qui laisse l'installation moins pilotée qu'avant
elle. Une borne en manuel est basculée en éco pour la durée — seul cas où le
mode est écrit, et modeForce retient qu'on l'a fait.
La passe confort est SAUTÉE sous dérogation : la fusion des niveaux est une
addition, et la dérogation demande déjà le maximum. Conséquence comptable à
connaître : elle est comptée entièrement en achat alors que le surplus présent
la finance en partie — gridW la surestime au soleil. Approximation héritée du
§10, non aggravée, et la raison pour laquelle la première vérification au banc
se fait le matin.
La fin est un ÉVÉNEMENT et dit sa CAUSE (LM-1500-f), publiée dans
derogationEnded[] au NIVEAU DE LA TRAME : au débranchement la charge n'est déjà
plus dans loads[], et l'événement disparaîtrait quand il explique le plus de
choses. Cinq causes, cinq gestes. Le mode dégradé la porte aussi — c'est là que
measurementLost se produit. telemetrySignificantlyDiffers ne la filtre jamais :
un événement ne vit qu'un cycle.
Éprouvé par testDerogationTakesTheHeadButNotTheSafety, dont la tête de passe est
prouvée par la RARETÉ : 7 500 W d'autorisation pour 8 000 demandés, la borne de
rang 9 servie ENTIÈREMENT et l'ECS de rang 1 réduite aux 500 restants — l'inverse
exact de l'ordre des rangs. Contre-épreuve : la même borne sans dérogation
reçoit 0 W. Et à autorisation nulle, AUCUN niveau — pas un niveau à zéro.
simulation 68/68, loadmodel 26/26, charging 48/48, spotmarket 32/32,
ci-quality 4/4, build 0 erreur 0 warning.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Même raison que le critère de tri du §6 : un protocole rédigé après coup se plie à
ce qu'on a vu.
TROIS OBSERVATIONS. (1) progress.regime de la V2C — première bascule observable sur
du réel, et la dérogation en dépend entièrement puisque sa fin measurementLost se
déclenche sur ce signal. Les trois issues possibles sont écrites d'avance, et
AUCUNE n'est un échec : chacune décide de ce qu'on peut promettre. (2)
command.divergent — les premières traces qui passent le critère du §6, maintenant
qu'une borne charge vraiment et qu'un compteur suit ; regarder d'abord les épisodes
COURTS, ce sont eux qui décident si l'étape 4 vaut le risque de rejouer une
commande. (3) Min+PV sur la borne, où le tirage est dix fois celui du chauffe-eau.
Et le biais de comptage est rappelé : contrairement à « error limit reached », les
lignes [Divergence] DÉBUT/FIN sont émises aux transitions seulement — c'est le
comptage juste.
CE QUI INVALIDERAIT LE RELEVÉ est écrit aussi : tout redémarrage de nymead pendant
la fenêtre repose la base d'avancement. Ne rien déployer pendant l'observation.
LA QUESTION QUE NI L'UN NI L'AUTRE N'AVAIT POSÉE : que fait la dérogation ENTRE le
figement de sessionEnergy et l'échéance de durée ? Elle achète au maximum sur une
mesure morte, et sur un lien qui perd 40 % de ses trames « au bout » peut vouloir
dire des heures.
POSITION RETENUE : une dérogation dont la cible cesse d'être mesurable CESSE. Elle
n'attend pas sa durée. C'est R6 transposée — là-bas « servie oui, tenue jamais » ;
ici « active oui, vérifiable non, donc on s'arrête ». Une dérogation est une
commande qui ACHÈTE, et la maintenir sans savoir où elle en est, c'est acheter à
l'aveugle. L'instrument existe déjà : measurement.source et le régime de LM-1009,
qui le disent au cycle même.
QUATRE FINS, et le motif dit laquelle a mordu : targetReached, unplugged,
measurementLost, durationElapsed. Les quatre appellent des gestes différents — et
une dérogation qui se terminerait sans dire laquelle laisserait l'utilisateur
relancer un boost que le lien empêchera encore.
L'ASYMÉTRIE, reprise du plugin V2C. La confirmation de débranchement existe
(k_absencesPourClore polls) et porte une propriété qu'il faut garder : SEULS LES
POLLS RÉUSSIS font avancer le compteur d'absences. Une coupure réseau le gèle au
lieu de le faire progresser — un lien mort ne peut donc pas fabriquer un faux
débranchement.
Et les deux erreurs ne coûtent pas la même chose : terminer à tort rend la main,
continuer à tort achète au maximum sur une mesure morte. D'où la règle, gravée dans
AGENTS.md : un mécanisme qui achète s'arrête dans le doute, et ses seuils de
confirmation sont asymétriques par conception — prompts à conclure la fin, lents à
conclure la poursuite. C'est l'inverse du réglage qu'on choisirait pour un mode.
La durée devient le FILET DU FILET : la perte de mesure attrape le cas où
l'instrument se tait et se signale ; la durée attrape le cas où même le régime ne
se signale pas. Deux filets parce que le premier repose lui-même sur un instrument.
Correction de Patrick, et elle supprime un manque au lieu de le documenter.
PAS DE COMMUNICATION VÉHICULE, et il n'y en aura pas : aucun plugin constructeur
prévu, et une intégration cloud Skoda/VW serait contraire au 100 % local, fragile,
rafraîchie à la minute au mieux.
Mais l'énergie est la BONNE grandeur indépendamment de cette contrainte. « 20 kWh
puis tu t'arrêtes » demande sessionEnergy, que le plugin V2C construit depuis le
2026-08-29. « Jusqu'à 80 % » demanderait la capacité, l'état de santé et le
rendement — trois inconnues pour dire la même chose en moins sûr. C'est exactement
ce que LM-1009 a établi pour l'obligation éco : on mesure de l'énergie parce que
c'est ce qu'on sait mesurer.
La fin par SOC ne figure donc plus dans le design, et son absence est écrite comme
une DÉCISION, pas comme un manque — sinon quelqu'un l'ouvrirait comme un lot.
ET sessionEnergy A UN SILENCE CONNU, qui justifie le filet mieux qu'un cas d'école.
LM-1012-d, mesuré sur la V2C le 2026-08-30 : à la perte du lien, currentPower tombe
à 0 et les booléens à false, mais sessionEnergy RESTE À SA DERNIÈRE VALEUR. Une
dérogation « 20 kWh puis stop » dont le compteur se fige à 12 kWh n'atteindra
jamais sa cible et achèterait au maximum indéfiniment. C'est le comportement
documenté de la borne installée, pas une hypothèse.
Conséquence heureuse : les trois fins du VE — débranchement, cible en énergie,
durée — sont toutes exerçables sans véhicule communicant. Ce lot est éprouvable sur
le banc réel, là où une fin par SoC ne l'aurait jamais été.
CADRAGE DE PATRICK, et il vaut au-delà du VE. Un mode se choisit une fois et vaut
jusqu'au prochain choix ; une dérogation répond à un besoin ponctuel et s'éteint
avec lui. Un boost encore actif après la fin est un mode qu'on a oublié de
quitter ; un boost qui rend la main est une dérogation terminée.
Conséquence de conception : ni un ChargingMode de plus, ni une demande dans needs.
Une dérogation se superpose au mode courant et s'efface. Elle n'a ni cible
d'énergie ni échéance — les deux supposent un besoin qui dure.
CE QUI LA BORNE : la sûreté seule, DRAW_CAP et le délestage, qui deviennent la
seule limite donc une limite obligatoire. Elle prend la tête de la passe éco mais
ne surplombe pas la sûreté : si DRAW_CAP mord, elle est servie la première DANS CE
QUI RESTE — sans quoi on retomberait sur le second chemin d'achat refusé pour le
minimum.
LE RANG. Le boost passe devant, y compris devant une charge mieux rangée. LM-1002
dit que le rang est ce que l'INSTALLATEUR décide ; elle ne dit rien d'une action
ponctuelle de l'utilisateur. Prendre la tête passe par une porte qu'elle ne ferme
pas.
DEUX PRÉCAUTIONS. Le mode précédent se MÉMORISE : retomber sur Normal sortirait la
borne de l'arbitrage, l'inverse du but — même famille que le repli d'échéance qui
réécrivait EcoWithMinCurrent en Eco. Et « terminé » se définit PAR MÉCANISME, ce
que le moteur ne peut pas deviner : c'est un ajout à ILoadAdapter, au même titre
que commandSettleS().
LA RÈGLE, gravée dans AGENTS.md : une dérogation qui ne sait pas dire quand elle
finit ne devrait pas exister. Sur un chauffe-eau sans sonde, « jusqu'à ce que ce
soit chaud » n'est pas mesurable — la fin doit être une durée, explicitement, et se
dire À LA SAISIE. Même raisonnement que progressMeasurable : l'écran de résultat
parle trop tard.
ET LA DURÉE EST UN FILET, jamais une option. Toute dérogation en porte une, même
avec une meilleure condition de fin, parce que cette condition repose sur un
INSTRUMENT et qu'un instrument peut se taire. Une cible qui ne remonte plus, une
sonde qui tombe : la dérogation ne finit jamais, en commandant le maximum. C'est
l'instrument dont le silence ressemble à un résultat, appliqué à une commande qui
achète. Donc jamais « jusqu'à annulation ».
DEUX APPORTS DU BRIEF APP f2bd07d, intégrés au design.
§9 — LE PLANCHER SE DÉRIVE, et ça corrige mon étape D. Pour une borne, la valeur
n'a besoin d'aucun champ : maxChargingCurrent.minValue × phaseCount × 230 est déjà
sur la box, dans la classe du Thing. Écrire cette valeur dans needs.minPowerWAlways
à l'appairage, comme je le proposais, créerait une COPIE QUI SE PÉRIME — un
recâblage change le réglage phaseCount et la valeur stockée resterait fausse sans
que rien ne le dise. C'est « une valeur dérivable est illégitime quand on la
publie », appliqué au stockage.
Le champ garde sa raison d'être pour les charges en watts, qui n'ont pas de
plancher matériel à dériver. Étape D révisée : le mode marque que la charge veut
un minimum, la passe éco dérive la valeur au cycle. Une seule source, jamais
périmée.
§10 — LA PISTE MONOPHASÉE EST TRANCHÉE, et par la carte Modbus elle-même. Il
n'existe AUCUN registre de phases sur la Trydan : la campagne de portage a exploré
0x0BC2-0x0BD5 et 0x177A-0x1783, et le plugin le documente. La borne ne sait pas
dire son câblage, donc n'offre rien pour le changer. phaseCount est un RÉGLAGE,
déclaration de l'installateur recopiée dans un état.
Et le détourner serait dangereux : déclarer 1 phase sur une borne câblée en 3
ferait budgéter 1 380 W et commander 6 A SUR TROIS PHASES — 4 140 W tirés. La
borne démarrerait, au mauvais courant, sans erreur. Le réglage décrit le câblage,
il n'est pas un bouton de réglage du plancher.
Ce qui reste vrai : une borne CÂBLÉE en monophasé a un plancher de 1 380 W et se
sert bien mieux sur une installation à petit surplus. C'est une décision de
câblage à l'installation, à dire au dimensionnement — pas un réglage logiciel.
DÉFAUT MESURÉ, non corrigé. Bascule Europe/Paris → Europe/London à 13:37:26Z,
sans redémarrage de nymead :
periodStartedAt : 1788645600 → 1788649200 (+3600 s) CORRECT, la journée suit
measuredSince : 1788645607 → 1788649207 (+3600 s) FAUX, un instant absolu
ne bouge pas
Cause : `m_baselinePosee = now` conserve le QDateTime en spécification
Qt::LocalTime, qui garde des composantes d'horloge murale et résout son époque au
moment de la CONVERSION. Après bascule, la même lecture « 00:00:07 » rend une
époque différente d'une heure.
Le champ posé vendredi pour rendre une couture lisible est lui-même déplacé par la
couture. Correctif : `m_baselinePosee = now.toUTC()`, une ligne — un instant
absolu se stocke en UTC, là où periodStartedAt doit rester construit dans le
fuseau courant puisque c'est une frontière locale. Les deux champs n'ont pas la
même nature et le stockage doit le refléter. Non appliqué : le déploiement
redémarrerait nymead et reposerait la baseline pendant la fenêtre de capture de
l'app.
EV_MIN_GRID NE SERA PAS VÉRIFIABLE SUR MACHINE (DESIGN_MIN_RESEAU §8), et c'est
écrit avant plutôt que découvert en mesurant : la voiture est débranchée,
pluggedIn retombe, la borne sort de loads[] — vérifié, il ne reste que chauffe-eau
et pac-terrain. Le lot tiendra sur ses tests et sa contre-épreuve. Trois
préconditions cumulatives pour lever la réserve, aucune à notre main aujourd'hui.
L'INERTIE SAINE, distinguée (AGENTS.md). Tout ce qui précède traite une
contre-épreuve inerte comme un signal d'alarme ; il existe un cas où elle est
correcte — le mécanisme tire sa valeur du CONTEXTE, pas du champ perturbé. Le
plancher du minimum réseau vient de la borne, pas du champ déclaré.
Le test qui sépare : « qu'est-ce qui déciderait, si ce n'est pas ça ? » Inertie
malsaine, on ne sait pas nommer l'autre source. Inertie saine, on la nomme ET on
peut la perturber elle. D'où la conséquence pratique : une inertie saine n'est
acceptable que si la contre-épreuve est DÉPLACÉE sur la vraie source, jamais
abandonnée — sinon c'est refermer l'identité sur elle-même une fois de plus.
TON ARGUMENT REMPLACE LE MIEN. Ce n'est pas la modulation : l'ECS multi-paliers
module aussi. Ce qui sépare les deux cas, c'est qu'ON NE SAIT PAS COMBIEN DE TEMPS
LA VOITURE RESTE BRANCHÉE. Une obligation en énergie suppose une échéance, qui
donne son dénominateur à la cadence ; une borne n'en a aucune tant que personne
n'en déclare. « 4 140 W tant qu'elle est là » est la seule formulation qui ne
suppose rien. Un chauffe-eau a une échéance naturelle et une capacité finie :
l'énergie y est la bonne grandeur.
LE RANG EST CELUI DE L'INSTALLATEUR. Un minimum déclassé par une charge mieux
rangée est le comportement voulu — LM-1002. Le contredire par un mécanisme serait
le doublon qu'on refuse partout. Nuance vérifiée dans le code : la hiérarchie
éco/confort SURPLOMBE le rang (un confort de rang 1 passe après un éco de rang 3),
donc un minimum passe avant tout le confort, et le rang le départage face à un
autre besoin éco.
DRAW_CAP ET LA RÉSERVE BATTERIE PRIMENT. Un besoin, pas une exception aux
plafonds.
LE MOT. Les deux candidats échouent au même test que celui qu'on corrige — un nom
qui promet autre chose que ce que le code fait.
garanti : promet une certitude que rien ne tient.
prioritaire : vrai face à TOUT le confort, faux face à un autre éco mieux rangé
— donc vrai en régime normal et faux exactement dans le cas
d'échec. Un mot qui ne se trompe que dans le cas intéressant ne
sera jamais relu. Et il contredirait LM-1002 dans le libellé, en
laissant croire que le mode réordonne.
RETENU : on nomme le FINANCEMENT, seule propriété qui tienne toujours et vraie
différence avec Eco — Eco dépense le surplus, ce mode ACHÈTE le complément.
· libellé du mode : « Surplus + minimum réseau »
· champ : needs.minPowerWAlways, grammaire de son frère
minEnergyWhPerDay — les deux déclarent une demande, aucun
ne promet une livraison
· bannis partout, commentaires compris : « garanti », « prioritaire »
Ce qui dit le résultat, c'est le motif : ECO_FLOOR_GRID chiffre l'achat, DRAW_CAP
nomme le plafond qui a empêché. Le nom déclare l'intention, le motif rapporte les
faits.
Document renommé DESIGN_MIN_RESEAU.md, et le mot purgé de son propre texte — y
compris des invariants, où « la garantie » s'était réintroduite quatre fois.
Design avant code, comme pour le délestage et le §10. Rien d'implémenté.
LE CONSTAT EST DOUBLE. Le mode n'a jamais eu de minimum garanti — mort par
réécriture chez l'amont, puis mort par exclusion depuis 3g-2 (DESIGN_3g §5). Et
son nom promet l'inverse : `MinCurrent` désigne L'EXIGENCE DE LA BORNE, les 6 A
sous lesquels elle refuse de charger, pas une garantie du mode. Trois modes
annoncés, deux implémentés, et celui qui manque est celui que l'utilisateur
croyait utiliser — le défaut n'est pas qu'une fonction manque, c'est qu'elle est
annoncée.
POURQUOI MAINTENANT, sans attendre le prix. Rachat à 0,01 € : charger 30 % au
réseau en journée revient à 0,073 €/kWh contre 0,180 € la nuit. Sur la majorité du
parc neuf, aucun arbitrage n'est nécessaire pour savoir que c'est le bon choix. Le
prix ne devient décisif que sur les anciens contrats à 0,1296 €, où l'écart tombe
à deux centimes et s'inverse sous 62 % de couverture solaire. L'option 3 reste
l'horizon ; elle choisira S'IL FAUT garantir, pas COMMENT.
CONDITION 1 — machinerie du §10 : passe éco, borné par DrawCap, funding Grid,
motif qui dit combien est acheté. Exclut explicitement EV_GRID_START, dont les
trois bornes dérivent du surplus et qui achète hors du registre d'autorisation.
CONDITION 2 — un champ de plus DANS needs, frère de minEnergyWhPerDay, pas une
structure parallèle : `guaranteedPowerW`. À ne pas confondre avec minPowerW
(LM-1201) : le premier borne une consigne SI on sert, le second en crée une
TOUJOURS. La passe éco rend max(cadenceObligation, guaranteedPowerW), avec quatre
invariants — la garantie ne se tient jamais (donc watts retombe sur elle quand
l'obligation est tenue, pas sur zéro) ; progress ne décrit que l'obligation et est
ABSENT sur une garantie seule ; le motif dit lequel des deux mord ; une garantie
non honorée se dit par DRAW_CAP qui la nomme.
CONDITION 3 — le fil ne peut pas être renommé sans casser les clients déployés.
Ce qui se corrige est la DESCRIPTION au contrat, d'où l'app tire ses libellés.
ChargingModeNormal n'est pas « recharge immédiate au maximum » : c'est MANUEL, la
borne sort de l'arbitrage et le moteur ne commande rien — seule la protection de
surcharge la touche encore, ce qui doit rester et doit être dit.
QUATRE ÉTAPES, à comportement constant d'abord : corriger le contrat (aucun code),
porter et publier le champ sans s'en servir, la passe éco le prend en compte, puis
le mode s'y branche.
ET CE QU'ON NE SAURA PAS PROUVER AU BANC : 2 kWc contre un plancher de 4 140 W,
donc une garantie toujours financée au réseau et jamais le cas mixte. Le
chauffe-eau l'exercera dès qu'il aura un compteur réel — quatrième nomination de
la même précondition.
Établi, aucun correctif posé.
1. ChargingModeEcoWithMinCurrent A un comportement de minimum garanti : branche 4
d'adjustEvChargers(), 6 A inconditionnels, sans condition de budget ni
autorisation de soutirage. Ce n'est pas un EcoCharging avec un seuil.
2. Mais ce chemin n'a JAMAIS tourné, deux fois pour deux raisons. Chez l'amont, le
repli d'échéance réécrivait le mode en ChargingModeEco à chaque cycle : branche
morte, réglage détruit en silence. Corrigé côté ETM. Puis depuis 3g-2, le
crochet evCommandedByWaterfall() exclut du proxy toute borne que le waterfall
commande — la branche redevient inatteignable, pour une raison nouvelle. Mort
par réécriture, puis mort par exclusion, sans que rien ne le signale.
3. Et sur cette installation il n'aurait rien changé : plancher 4 140 W contre
2 000 W de crête. La voiture aurait chargé entièrement au réseau, en
permanence, sans qu'aucun mécanisme ne le compte.
4. EV_GRID_START ne peut pas porter un minimum permanent. Ses trois bornes
dérivent toutes du surplus — budgetW > 0, seuil proportionnel, consommation de
tout le budget — et un minimum permanent en est indépendant par définition. Les
lever, c'est créer le second chemin. Et EV_GRID_START achète HORS du registre
d'autorisation de soutirage, là où la passe éco achète sous DrawCap : deux
mécanismes dont un seul est borné, et c'est le second qui ferait disjoncter.
5. La différence de nature demeure : l'obligation éco est une énergie avec
échéance, Min+PV une puissance permanente. On peut approcher la seconde par la
première, mais sous régime mesuré le plancher retombe à zéro dès la cible
atteinte — ce n'est pas un minimum permanent.
La V2C est restée HORS WATERFALL du samedi 18:00 au dimanche 11:46, 1 066 cycles
portant « Borne V2C Trydan hors waterfall (mode manuel ou aucun véhicule
branché) » et « has no car assigned. Ignoring... ». Elle n'a produit aucune trace
sur la période visée, et ce n'était pas un battement de lien.
La voiture est devenue visible à 11:46 dimanche, pas samedi soir. Huit cycles
utiles ont suivi, 11:47 à 12:08, sur le PV simulé à 9 kWc — démarrages en
tolérance d'acquisition puis consignes de surplus. Puis plus rien : le banc est
passé d'un simulateur 9 kWc à une installation réelle de 2 kWc, et 2 kWc ne peut
pas alimenter le plancher de 4 140 W d'une borne triphasée à 6 A.
Bilan : V2C aucune trace, chauffe-eau et pac-terrain écartées par le critère du §6
(compteurs constants, 1 500 et 800 W puis 0). C'est un résultat, pas un échec — il
dit que la fenêtre a été ouverte sur un banc qui ne pouvait pas la remplir, et il
nomme les deux raisons.
Précondition pour la prochaine : un compteur réel sur une charge pilotée, et une
borne effectivement dans le waterfall — vérifié au journal AVANT d'ouvrir.
ECS-Meter et PAC-Meter sont des smartMeterConsumer de generic-energy appairés à la
main : leur currentPower est SAISI, pas mesuré. 1 500 W et 800 W constants jusqu'au
2026-09-05, puis 0 depuis le passage de la box aux vrais compteurs Eastron, faute
de quelqu'un pour l'écrire.
Donc tout le §11 — compteur dédié par charge, sessionWh depuis le compteur,
measurement.source "meter" — a été éprouvé contre des valeurs tapées.
CE QUI EST PROUVÉ : la plomberie. meterThingId résolu, état lu, valeur remontée
dans measurement.powerW, sessionWh alimenté, source = meter. La chaîne existe et
transporte.
CE QUI NE L'EST PAS : la mesure. Qu'un compteur réel rattaché à une charge réelle
produise une valeur qui SUIT la commande — donc que l'écart commandé↔mesuré
signifie quelque chose.
La distinction n'est pas académique : c'est celle qui rend les traces de divergence
inexploitables sur ces deux charges. Un compteur constant produit un écart qui ne
parle que de sa propre constance.
Et ça explique ce que voit l'app : une consommation affichée sur des compteurs qui
ne mesurent rien. Elle est fidèle, la box aussi — la chaîne est juste sans source.
Troisième nomination du sixième manque du mock, par un troisième chemin : les
traces de divergence, puis la pose d'obligation, maintenant le passage au réel.
TROIS FAITS du 2026-09-06, consignés parce que les traces de lundi en dépendent.
11:47:23 — crête PV du simulateur portée de 9 000 à 6 000 W (banc/cmd/peak,
retenu, courtier 192.168.1.131). Vérifié contre le modèle : écart moyen 0,3 W sur
216 échantillons de plein jour, contre 1 102 W pour l'hypothèse 9 000.
~12:00 — voiture branchée à la V2C. pluggedIn true, lien connected,
sessionEnergy 0,44 kWh. Aucun redémarrage de nymead dans les deux cas : ce ne sont
pas des coutures de baseline.
CE QUE 6 kWc NE CASSE PAS, contrairement à ce que j'avais craint. minPowerW vaut
4140 W (3 × 6 A × 230 V) et le surplus ne dépasse pas ~2 700 W à cette crête ; j'en
avais conclu que la borne ne démarrerait jamais. Faux : mesuré à midi simulé, elle
passe en EV_GRID_START dès 2 140 W de budget, puis en SURPLUS_SETPOINT. Le chemin
d'appoint réseau existe pour ce cas, et BELOW_MIN_POWER seul ne dit pas que la
borne est bloquée — il dit que CE budget-là ne suffit pas. Encore une conclusion
tirée d'un motif lu hors de sa trajectoire.
CONVENTION DE SIGNE, mesurée pour lever une ambiguïté d'écran.
currentPowerAcquisition est NÉGATIF en injection, POSITIF en soutirage — même
convention que banc/etat/grid. Dix échantillons appariés dont un passage par zéro
(−638 → +1939 W) : 10/10 de même signe. currentPowerProduction est négatif de même,
par la convention nymea « from a consumer perspective ».
Un client qui affiche « consommation réseau » sur un currentPowerAcquisition
négatif inverse le sens : la valeur dit que l'installation INJECTE. Le signe porte
la direction ; la valeur absolue seule ne la porte pas.
Un compteur qui SUIVE la commande de la charge qu'il mesure a été nommé par deux
chemins indépendants en deux jours : par les traces de divergence (quatorze
épisodes qui mesurent une consigne variable contre un compteur constant), et par
la pose d'une obligation éco (ce qui borne la fenêtre n'est pas la cible, c'est la
constance du compteur).
Deux lots différents, deux symptômes sans rapport apparent, une seule cause. Le
manque n° 4 avait été nommé deux fois de la même manière, et c'est ce qui lui avait
donné sa priorité — même règle appliquée ici.
Quand un manque se fait nommer deux fois sans qu'on l'ait cherché, il ne s'agit
plus d'un confort de test : il décide de ce que plusieurs lots pourront prouver.
Posé dimanche 2026-09-06 à 08:19 (Europe/Paris) : chauffe-eau, minEnergyWhPerDay
3000 → 2000, dailyDeadline inchangé à 12:00. Discipline habituelle — capture sur
disque avant écriture, 76 clés comparées, 1 divergence attendue, 0 imprévue — mais
PAS de restauration : la configuration reste en place tout le week-end.
Symboles de débogage laissés en place jusqu'à lundi, donc aucune couture
supplémentaire pendant la fenêtre. Les deux dernières restent 06:53:30Z (fuseau) et
09:22:57 (installation des symboles), toutes deux du 2026-09-05.
CE QUE L'ÉCRAN MONTRE À LA POSE, et pourquoi ce n'est pas un défaut. À 08:19 le
palier est ECO_FLOOR_MET avec deliveredWh = 30 475 Wh pour une cible de 2 000.
Arithmétiquement correct et sans intérêt : le compteur de l'ECS publie 1 500 W en
permanence, donc deliveredWh monte de 1,5 kWh/h que la charge soit commandée ou
non. La période a basculé hier à 12:00 ; vingt heures plus tard elle a « livré »
30 kWh.
LA FENÊTRE UTILE EST À 12:00 et dure ~80 minutes. À la bascule, la base est reprise
(LM-1013-c) : deliveredWh repart de 0 face à 2 000 Wh sur 24 h, soit une cadence de
83 W financée par le réseau si le surplus manque, que le compteur fixe comble en
2000/1500 = 80 min. Deux fenêtres sur le week-end — dimanche 12:00 et lundi 12:00.
ET C'EST LA CINQUIÈME FORME D'HOMOGÉNÉITÉ QUI FIXE CE PLAFOND. Sur un banc dont le
compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible modeste
et un chemin d'achat longuement exercé : ce qui décide n'est pas la cible, c'est la
constance du compteur. Tenir l'achat en éveil tout le week-end demanderait de
dépasser 36 kWh/jour, c'est-à-dire acheter au plafond — précisément ce qu'on
voulait éviter. La contrainte est du banc, pas du moteur.
CRITÈRE DE TRI (DESIGN_COMMANDE_PERDUE.md §6), daté et poussé avant l'ouverture de
la fenêtre d'observation. Un critère rédigé après coup se plie aux résultats sans
jamais mentir, et sans qu'on puisse le prouver. S'il doit changer, ce sera un
commit visible avec sa raison.
Deux conditions, toutes deux nécessaires : `measurement.source` != `none`, ET le
compteur doit avoir VARIÉ sur la fenêtre. Un compteur d'écart-type nul n'est pas
un compteur, c'est une constante déguisée, et tout écart mesuré contre lui est un
artefact.
PAS de tri par nom de charge. Écarter chauffe-eau et pac-terrain nommément serait
fragile deux fois : ça se périme au premier renommage, et ça n'attrape pas la
troisième charge à compteur fixe qu'on ajoutera sans y penser. Le critère porte sur
une propriété observable de la donnée.
LES FAUX POSITIFS DE LA V2C sont d'une autre nature, et il faut les séparer avant
de compter. Elle a un vrai compteur, donc elle passe le critère — mais chaque perte
de lien produit une divergence qui n'est pas une commande perdue : c'est une mesure
absente. « Elle n'obéit pas » et « on ne sait pas si elle obéit » sont deux
affirmations que l'écart seul confond.
C'est la distinction `none` contre l'absence, appliquée à un écart. Et le pire cas
est documenté : à la perte du lien la V2C publie currentPower = 0 (LM-1012-d), donc
le zéro est PUBLIÉ, pas absent, et rien dans l'objet `command` ne le distingue d'un
zéro réel. Il produit la divergence maximale — le faux positif qui ressemble trait
pour trait au cas cherché. Conséquence portée au lot : `command` devrait dire que
son observedW n'est pas fiable, comme progress.regime le fait pour l'avancement.
Le compte des écartés sera publié aussi : un tri dont on ne dit pas ce qu'il a jeté
n'est pas un tri, c'est une sélection.
CINQUIÈME FORME D'HOMOGÉNÉITÉ DU BANC (AGENTS.md + INVENTAIRE_MOCK.md), et elle
inverse le mécanisme. Les quatre précédentes MASQUENT un cas ; celle-ci en FABRIQUE
un faux. Un cas masqué se signale par un test qui ne mord pas ; un cas fabriqué se
signale par des données qui rassurent.
14 épisodes en 24 h, de quoi croire le phénomène fréquent et dimensionner un lot
dessus. L'instrument fonctionne, la donnée est réelle, le compte est juste — seule
la question à laquelle ces nombres répondent n'est pas celle qu'on croyait poser,
et un nombre n'annonce jamais de quelle question il est la réponse.
Manque noté au mock : aucun compteur dont la valeur SUIVE la commande de la charge
qu'il mesure. Tant que c'est le cas, aucun test ne peut exercer une charge qui
obéit, donc aucun ne peut distinguer l'obéissance de la désobéissance.
L'hypothèse était que chaque qCInfo bloquait le thread de décision sur une
écriture SQLite sous verrou. Mesurée sur la cible, elle ne tient pas — et deux de
ses prémisses étaient fausses.
CE QUI ÉTAIT FAUX. (1) `qCInfo` ne passe PAS par le LogEngine : il va au
gestionnaire de messages, qui écrit sur stdout. Le chemin `Logger::log()` →
`logEvent()` est celui des états et actions journalisés, déclenché par des
changements d'état. Deux chemins, deux coûts. (2) Le LogEngine de la cible est
LogEngineInfluxDB : `logEvent()` empile dans m_writeQueue et poste en asynchrone.
Rien n'y bloque le thread appelant. Le .sqlite du rapport était celui du harnais
de test, pas de la box.
MESURÉ sur Pi Zero 2 W, banc croisé arm64 lié à libnymea, gestionnaire de nymea
installé, stdout sur la socket journald — les conditions de nymead :
· catégorie active, vers journald : 69,4 µs / ligne
· catégorie active, vers /dev/null : 61,9 µs / ligne
· catégorie éteinte : 0,0045 µs / ligne
L'I/O n'est pas le coût : 8 µs sur 70. Le reste est du formatage. Et le cycle
d'arbitrage tourne à 60 s exactement pour ~30 lignes — soit 2,1 ms par cycle,
0,0035 %. Il faudrait 143 lignes par seconde soutenues pour atteindre 1 %.
Donc : ce n'était pas un argument pour le rapport, et l'y mettre sans mesurer
l'aurait affaibli. Une première estimation en Python donnait 11 µs/ligne — six
fois trop bas, parce qu'elle ne mesurait que l'écriture et pas le formatage. Le
banc en Qt, lié à la vraie bibliothèque, était le seul moyen d'avoir le chiffre.
MAIS UN DÉFAUT RÉEL EN SORT, petit et chiffré. nymeaLogMessageHandler construit
`messageString` — dont un QDateTime::toString — POUR CHAQUE MESSAGE, alors qu'elle
ne sert que si un fichier journal est ouvert. Mesuré isolément : 28,0 µs, soit
40 % du coût d'une ligne. Et nymead tourne sans fichier journal dans le service
livré (`ExecStart=/usr/bin/nymead -n`, aucun descripteur .log ouvert) : ces 28 µs
sont jetés à chaque message, sur toute installation en configuration par défaut.
Correctif d'une accolade : construire messageString sous `if (s_logFile.isOpen())`.
Ajouté en troisième demande du rapport, explicitement indépendante du plantage.
L'hypothèse « durée de vie du Logger vis-à-vis des événements postés » est FAUSSE.
Ce n'est pas un usage après libération : c'est un déréférencement de nullptr, et
la garde censée l'empêcher interroge un ensemble différent de celui qu'elle
protège. Correctif d'une ligne.
ÉTABLI, avec les symboles 1.15.2 (identifiants de build vérifiés) :
· #0 libnymea.so.1 + 0x14ea24 → Logger::log(...), logger.cpp:55
· #1 libnymea-core.so.1+0x1edae6 → la lambda de ThingManagerImplementation::
executeAction connectée à finished
· rdi = 0x0 au signal. Dans l'ABI SysV AMD64, rdi porte le premier argument,
donc `this`. Logger::log a été appelée sur un pointeur NUL — un usage après
libération donnerait une adresse quelconque, pas zéro.
LE MÉCANISME. La lambda fait `m_actionLoggers.value(clé)->log(...)`, et
QHash::value() rend nullptr sur une clé absente. Sa garde est
`thing->loggedActionTypeIds().contains(...)` — la liste DU THING, pas la TABLE
des journaliseurs. Au retrait d'un Thing, unregisterActionLogger vide la table
pendant que la liste du Thing reste intacte. La connexion prend `this` (le
ThingManager) pour contexte, donc un `finished` déjà posté survit au retrait :
garde vraie, table vide, nullptr déréférencé.
C'est notre défaut récurrent, dans du code amont : UN GARDE-FOU QUI INTERROGE LE
MAUVAIS OBJET. Il a l'air de protéger l'accès qui suit et n'a aucun rapport avec
lui — d'où son invisibilité à la relecture.
Et ce n'est pas limité aux tests : toute suppression de Thing pendant qu'une
action est en vol ouvre la même fenêtre en production, qu'une action longue
élargit.
SYMBOLISÉ SANS RIEN INSTALLER, et sans privilèges : `apt-get download` puis
`dpkg-deb -x`, et `addr2line` sur les fichiers extraits. Noté dans le rapport,
parce que c'est aussi la voie qui ne touche pas la machine. gdb, lui, ne peut pas
produire de pile ici : le binaire de test et le plugin ont été reconstruits depuis
le plantage, donc leurs identifiants ne correspondent plus au vidage. La
résolution par offset dans les bibliothèques reste valide, et suffit.
RÉSERVE ÉCRITE : les symboles sont ceux de 1.15.2, mais le code cité est lu dans
l'arbre 1.16.0, seule source locale. Les deux symboles s'y retrouvent à
l'identique ; la formulation exacte du correctif reste à vérifier sur la branche.
LEÇON GRAVÉE (AGENTS.md, à côté de la règle des identités) : entre deux instants
du MÊME fuseau, la soustraction rend la durée d'horloge murale, jamais la durée
réelle — donc un contrôle qui cherche les journées de 23 ou 25 h avec cette
arithmétique rend 24 h partout et conclut qu'elles n'existent pas. Trois de mes
contrôles s'y sont trompés dans ce lot, sur la question même que le champ existe
pour régler.
La parade générale est la vraie leçon : l'attendu d'un test ne se calcule pas avec
les primitives du code testé. L'oracle du test de frontière vient de hors Qt ; le
re-dériver avec QDateTime aurait refermé l'identité sur elle-même — la faute que
la règle voisine traque, retrouvée un cran plus bas, non plus dans l'assertion
mais dans la fabrication de sa valeur attendue.
`Europe/London` sur un banc français était une erreur de configuration. La
correction a été différée tant que le décalage n'était pas visible : déplacer les
frontières d'une heure sans rien qui le dise aurait rendu l'historique illisible
de part et d'autre, sans qu'aucun lecteur ne puisse savoir où passait la couture.
`periodStartedAt`, posé hier, a levé cette réserve.
COUTURE : 2026-09-05T06:53:30Z. Avant, journée de reporting de 23:00 à 23:00 UTC ;
après, de 22:00 à 22:00. Toute comparaison jour à jour qui franchit cet instant
compare deux découpages différents.
Méthode : `Configuration.SetTimeZone` en JSON-RPC. `System.SetTimeZone` N'EXISTE
PAS en 1.15.2 — malgré la note de dépréciation de `Configuration.SetTimeZone` qui
dit d'utiliser celui-là. Suivre la note aurait donné « No such method ».
CONFIRMÉ EN VRAI : le moteur a suivi SANS redémarrage de nymead. Ce n'était
jusqu'ici mesuré qu'en conteneur avec un programme Qt6 ; `GetEnergyRatios.timeZone`
et `System.GetTime.timeZone` sont passés à Europe/Paris au cycle suivant, et
`periodStartedAt` a reculé de 23:00 à 22:00 UTC.
ET LA PAIRE A SERVI AU MOMENT EXACT OÙ ELLE SERVAIT. `measuredSince` n'a pas bougé
(05:04:29 UTC) : la frontière publiée a changé, la portée réelle de la mesure non.
Sans le second champ, le bilan du jour aurait paru couvrir une heure de plus qu'il
ne couvre — un décalage introduit par la correction elle-même, le lendemain du
jour où on a posé de quoi le voir.
`meterNoEnergy` remplace le `powerSwitch` détourné en instrument de mesure. Le
détour marchait — le moteur ne teste que `hasStateType("totalEnergyConsumed")` —
mais il modélisait un montage que personne ne fait, et faisait tenir DEUX rôles à
la même Thing dans le même scénario : relais d'une charge et compteur d'une autre.
La classe ne déclare PAS `energymeter` : cette interface EXIGE `totalEnergyConsumed`
et `totalEnergyProduced`. Promettre une interface qu'on ne tient pas ferait mentir
le mock exactement là où il doit être littéral. `smartmeter` est la base sans état
obligatoire, et c'est précisément ce qu'est ce matériel.
`thermalProbe` ouvre le volet thermique. La branche « sonde présente » de
attachMeasurements() était écrite depuis toujours et n'avait JAMAIS été parcourue :
aucune classe du mock ne portait l'état `temperature`. C'était la seule entrée du
volet thermique, et rien ne l'exerçait.
CE QUE L'OUVERTURE A RÉVÉLÉ, comme les trois précédentes. `setupThing()` du mock
n'avait AUCUNE sortie par défaut : une classe sans branche ne rencontrait jamais
d'`info->finish()`. Le setup ne échouait pas — il ne se terminait jamais. Le
symptôme est un Thing éternellement « en cours de configuration » et un test qui
expire ailleurs, très loin de la cause. Même mécanisme que le contrôleur
déréférencé pour toute classe : une hypothèse du mock que son homogénéité
protégeait. Une classe oubliée se dit maintenant, en qCWarning + SetupFailed.
UNE GARDE A MORDU sur son auteur le jour même. La première version du test
thermique lisait `loads[]` sans compteur racine — donc une liste vide, et trois
assertions qui ne se seraient jamais exécutées. `QCOMPARE(parId.count(), 3)` l'a
attrapé. C'est la parade écrite dans INVENTAIRE_MOCK.md, appliquée à elle-même.
RELEVÉ, NON CORRIGÉ : une sonde DÉSIGNÉE mais incapable produit la même charge
utile qu'aucune sonde du tout (`temperatureC` absent), alors que le geste de
réparation diffère — désigner une sonde, ou en changer. Silence de la famille
`progressUnmeasurableCause` ; le fermer demande un catalogue de causes thermiques
qui n'existe pas encore.
Suites : simulation 67/67 (+1), loadmodel 23/23, charging 48/48, spotmarket 32/32.
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à.
La distinction des deux natures d'heure murale déménage du lot qui l'a découverte
vers le lot qu'elle contraint. Rangée dans DESIGN_FUSEAU.md, c'était une note ;
rangée à l'entrée du lot tarifaire, c'est une condition d'entrée — au même titre
que l'extension du délestage l'était pour le §10.
LM-1005-b, posée juste sous LM-1005, là où la spec nomme déjà la frontière que
l'arbitre franchit en devenant acheteur : « à quel prix, à quelle heure, sous quel
signal tarifaire ». C'est exactement là que le risque naît, et pas un jour avant —
tant que l'arbitre distribue un surplus, il n'a aucune heure à respecter.
· `dailyDeadline` (habitude du client) → fuseau de l'installation
· heures creuses, Tempo, EPEX (calendrier réglementé) → fuseau où le tarif est DÉFINI
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 mauvais moment, et le tarif ne s'est pas décalé. La
facture est le seul endroit où ça se verrait, un mois trop tard.
Le marché de gros amont travaille en instants absolus, donc il est déjà à l'abri.
Le risque apparaît à la première plage écrite en heures murales.
DESIGN_FUSEAU.md ne garde que l'établissement des faits et renvoie ici pour la
règle opposable — pas de règle en double, un seul domicile.
Note de forme, qui a coûté une passe : l'index des règles lit `l.strip()`, donc une
définition placée dans une citation `>` n'est JAMAIS reconnue — elle sort en
« citée et jamais définie ». L'énoncé vit hors de la citation, le bloc d'appui
dedans.
LOT FUSEAU (docs/DESIGN_FUSEAU.md) — design avant code, comme pour le délestage
et le §10. Deux questions étaient posées ; les deux sont fermées par mesure.
1. Le fuseau vient-il de la box ou de nymea ? Des deux, et c'est le MÊME.
`EnergyArbitrator::update()` prend `QDateTime::currentDateTime()`
(energyarbitrator.cpp:329), `resolveDeadline()` hérite via `now.timeZone()`,
et nymea ne fait que relayer `QTimeZone::systemTimeZoneId()`. Aucun réglage
nymea ne peut dire autre chose que timedatectl : box et moteur ne peuvent pas
diverger entre eux.
2. Mesuré dans le conteneur, avec un programme Qt6 pendant qu'on bascule
/etc/localtime sous lui : un processus VIVANT suit le changement, sans
redémarrage. Ce n'était pas acquis — la mise en cache du fuseau par processus
est le comportement classique de la libc, et si Qt l'avait fait, corriger un
fuseau n'aurait rien corrigé jusqu'au redéploiement suivant.
La vraie divergence est ailleurs, et elle est double. Entre l'INSTALLATION et le
CLIENT d'abord : `dailyDeadline` est une heure murale SANS fuseau, saisie sur un
téléphone qui a le sien, lue dans celui de la box — silencieuse des deux côtés,
chacun ayant raison dans son référentiel. Un fuseau implicite est une absence
qui signifie « le défaut s'applique », ce qu'on s'interdit partout ailleurs.
Et entre l'installation et le CALENDRIER RÉGLEMENTÉ, qui est le point neuf : une
plage d'heures creuses française est définie en Europe/Paris par le fournisseur,
pas « à l'heure locale de la box ». Deux natures d'heure murale, deux sources de
fuseau — l'habitude du client suit l'installation, le tarif suit le texte qui le
définit. Les confondre ne décale pas l'affichage : ça achète au mauvais moment.
DÉCISION : ni imposer, ni refuser — déclarer. Imposer serait affirmer un fuseau
qu'on ne sait pas vérifier. Refuser de fonctionner déplacerait un problème
d'affichage vers la sécurité, alors que L0..L4 raisonnent en durées et ne
dépendent d'aucun fuseau. Déclarer est la doctrine maison appliquée telle quelle.
DEUX MASQUES EMPILÉS (AGENTS.md, quatrième occurrence de la même famille). Le
mock plus homogène que la réalité avait une suite : l'environnement de
vérification plus indulgent que la réalité, deux fois dans la même chaîne de
build. Un artefact périmé couvrant un lien cassé, et le build vert couvrant les
deux. Un répertoire de travail accumule de l'état qui répond à la place du
dépôt — « est-ce que ça compile ? » n'a pas de valeur sans dire DEPUIS QUOI.
Seule la reconstruction dans un répertoire vierge les révèle, et le md5 identique
au binaire en service est la façon de fermer : il ne dit pas « ça compile », il
dit que le build reproductible produit exactement ce qui tourne.
totalEnergyConsumed n'était écrit par personne : il valait sa valeur par
défaut, indéfiniment. Un compteur figé est un compteur qui n'existe pas pour
tout ce qui l'intègre — deliveredWh restait à 0, remainingWh à 4 000, et
l'étalement adaptatif n'était jamais exercé. Le comportement se confondait
avec unmeasurable pour une raison entièrement différente et bénigne.
Quatrième occurrence d'un mock plus homogène que la réalité, après les six
états cohérents du rootmeter, les classes portant toutes une puissance, et la
triphasée équilibrée.
En export il ne recule pas — il ne bouge pas : un compteur de consommation
est monotone, et le faire reculer produirait un cas que le terrain ne produit
pas, celui-là même que la garde de sémantique traite comme une anomalie. Le
mock fabriquerait le défaut que le moteur est censé détecter.
LM-1014-b appliquée au mock, question posée et répondue : le cumul est
déclaré `cached`, donc il continue au redémarrage. Repartir de zéro ferait
reculer un cumul monotone.
Et purchasedWh gagne un second usage, sous `measured` cette fois. Mesuré sur
le banc : il accumule pendant que deliveredWh peut rester plat, et cette
divergence est un contrôle que l'écran n'aurait pas su fabriquer — de
l'acheté qui monte avec du livré plat signifie soit que la charge ne consomme
pas ce qu'on paie, soit que le compteur ne compte pas. C'est écrit au contrat
parce que le jour où les deux coïncideront, quelqu'un jugera le champ
redondant : c'est précisément quand ils divergent que la paire devient
informative, et un champ qui ne sert que dans l'anomalie n'a pas l'air utile
le reste du temps.
La borne basse du test de cumul est large, et délibérément : il ne contrôle
ni la cadence du minuteur ni l'alignement du premier tic, qui n'intègre rien.
Une borne serrée en ferait un test instable — qu'on relancerait jusqu'à ce
qu'il passe.
Suite : simulation 66/66, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
`voltage` était déclarée une seule fois hors des trois blocs et mutée par
l'un d'eux : une phase sans tension déclarée était calculée avec celle d'une
autre.
Et le défaut n'était pas celui qu'on croyait — le mesurer l'a montré.
L'interface energymeter rend currentPhaseA et voltagePhaseA OBLIGATOIRES, B
et C optionnels : la branche « puissance ÷ tension » de A est morte par
construction. La fuite n'allait donc pas de A vers B, comme la note d'origine
l'affirmait, mais de B vers C.
Démontré : B à 200 V, C à 4 000 W sans tension déclarée → 5,0 A de marge au
lieu de 7,6. Deux conditions, dont aucune n'était évidente avant d'écrire le
test : le masque doit couvrir B ET C — interroger C seule n'exécute pas le
bloc de B — et C doit être la phase la plus contrainte, sinon le qMin retient
B et masque l'écart. Mes deux premières versions du test passaient pour ces
deux raisons.
Le mock ne savait pas produire le cas : il a fallu meterPowerOnly, avec les
puissances et la tension de B mais sans les courants de B/C ni la tension de
C. Troisième fois qu'ouvrir le mock révèle un défaut plutôt que de seulement
débloquer un test.
draw.bindingPhase dit LAQUELLE des phases borne. perPhaseBound disait qu'une
phase borne, jamais laquelle : l'écran ne pouvait dire que « bridé » sans
dire par quoi. DRAW_CAP la porte aussi mais n'est émis que si une charge est
refusée — un cycle qui borde sans rien refuser laisserait l'écran muet.
Et dans AGENTS.md : une conclusion juste posée sur un raisonnement faux
survit jusqu'à ce qu'on bâtisse dessus, parce que la conclusion PROTÈGE le
raisonnement de l'examen. Un résultat faux se voit ; un résultat juste ferme
la question. Parade : quand une décision est écrite avec sa raison, la raison
mérite son propre contrôle — c'est elle que le lot suivant utilisera.
Suite : simulation 65/65, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Le mock posait currentPhaseX = currentPowerPhaseX / 230 : les deux familles
d'états étaient cohérentes par construction, donc ni triphasée déséquilibrée
ni tension ≠ 230 V n'étaient fabricables. Les paramètres sont optionnels —
sans eux le comportement d'origine tient, et aucun scénario existant ne bouge.
LM-1210-a est enfin exercée : le choix de la pire phase faute de masque était
écrit, raisonné, et jamais vérifié. Phase B saturée à 30 A sous un plafond de
25 pendant que A et C exportent, et la maison exporte GLOBALEMENT — la marge
retenue est celle de B, négative, et non celle du total qui rassurerait.
Et l'ouverture a corrigé une ERREUR DE RAISONNEMENT, pas seulement comblé un
trou. Mon premier test attendait qu'une phase en export donne une marge
supérieure au plafond : c'est ce que le design affirmait. Il a échoué —
calculateAllowanceAmpere() part du plafond et ne fait que des qMin, donc la
marge y est écrêtée. Physiquement juste, mais la phrase était fausse. La
conclusion tenait, la raison non, et rien ne pouvait le révéler tant que le
déséquilibre était infabricable. Corrigée dans la spec et dans le code.
C'est la deuxième fois qu'ajouter de la diversité au mock trouve un défaut
plutôt que de seulement débloquer un test — après dryRelay, qui avait révélé
le déréférencement du contrôleur.
Et une note à côté de la garde du compteur : l'app dépend de `connected` pour
REFUSER D'AFFICHER, jamais pour COMPTER, et elle a raison. Si connected ment,
l'écran dit « hors ligne » à tort et rien n'est mal compté. Une comptabilité
n'a pas droit à cette tolérance — même donnée non fiable, deux usages, deux
verdicts. S'abstenir sur un doute est sûr, accumuler sur un doute ne l'est
pas. Quelqu'un lirait l'asymétrie comme une incohérence sans cette ligne.
Suite : simulation 64/64, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
« Qu'est-ce que ce contrôle aurait attrapé s'il avait échoué ? » passée à la
suite existante. Le résultat n'est pas une liste de tests à supprimer.
Contrôles qui ne contrôlent rien : les assertions conditionnelles dans une
boucle sont à zéro — la seule qui existait a été corrigée avant-hier. Sur dix
identités auto-référentielles relevées, UNE SEULE est vaine :
authorisedW − committedW == remainingW relisait une affectation d'une ligne.
Elle est retirée AVEC SA RAISON à sa place, et avec la distinction d'avec
l'identité du budget — qui croise remainingSurplusW filé le long de la
cascade et allocatedW accumulé en trois sites distincts, donc attrape un site
qui décrémenterait sans accumuler. Supprimer sans dire pourquoi aurait invité
quelqu'un à la remettre.
La moitié qui compte : l'index annonçait 47 règles sans porteur. Il mesurait
la CITATION, pas la couverture — douze étaient couvertes par un test qui ne
les nommait pas. Citées par un test : 22 → 40. Les liens sont maintenant
vérifiables par la machine au lieu de reposer sur la mémoire de qui a écrit
quoi ; c'est la doctrine du dépôt appliquée à elle-même.
Sur les 31 restantes, 23 relèvent de familles non implantées — écrire leur
test poserait un invariant sur du code que rien n'émet. Six sont du cadrage
mal classé. Et UNE manque vraiment : LM-1210-a, la pire phase faute de
masque, qu'aucun test n'exerce parce que le mock ne sait pas produire une
triphasée déséquilibrée. Même angle mort que l'inventaire, nommé deux fois.
tools/audit-controles.py pérennise les deux motifs. Il ne remplace pas la
question, il la pose là où elle se pose souvent — et il ne juge pas : la
lecture tranche, l'écart entre les dix relevées et la seule vaine le montre.
Le résultat le plus utile n'est pas le défaut trouvé, c'est le chiffre
corrigé. On croyait 47 règles non couvertes ; il y en avait 31, dont 23
légitimes et une seule qui manque. Savoir lesquelles change ce qu'on
surveille.
Suite : simulation 62/62, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
La classe `dryRelay` commute et ne mesure pas. Elle ouvre le cas que
l'inventaire à froid avait identifié comme structurellement introuvable : une
charge SAINE et NON MESURÉE. Jusqu'ici `measurement.source: none` n'était
atteignable qu'avec un Thing manquant — ce qui traîne `available: false` et
mélange deux affirmations distinctes, « rien ne mesure cette charge » et
« cette charge est en panne ». Un relais sec est banal sur le terrain, et
parfaitement sain.
Le test vérifie ce que rien ne pouvait vérifier avant : deux charges, même
source: none, available opposés, faultCode sur la seule en défaut. Il
n'aurait pas pu s'écrire hier.
Et l'ajout a révélé que le mock avait SA PROPRE prémisse fausse :
executeAction() déréférençait le contrôleur HTTP de chaque Thing sans
vérifier, supposant que toute classe en possède un. Un relais sec n'en a pas
besoin. Le plantage fut immédiat et net ; l'hypothèse, elle, était invisible
tant qu'aucune classe ne la contredisait — l'homogénéité du mock la
protégeait, exactement comme elle masquait les cas qu'il ne savait pas
produire. Ajouter de la diversité au banc n'a pas seulement ouvert un test :
ça a trouvé un défaut.
AGENTS.md reçoit la règle générale sur les identités : une identité dont les
deux termes viennent de la même source ne vérifie rien. Elle est vraie par
construction et rassure là où rien ne protège — la question n'est pas
« tient-elle ? » mais « de quoi parle-t-elle vraiment ? ». Et c'est le même
défaut que la contre-épreuve qui ne mord pas, vu de l'autre côté : perturber
une grandeur qui ne pouvait rien changer, et vérifier une identité qui se
referme sur elle-même, sont deux gestes de vérification qui ne touchent rien.
Le réflexe commun : demander ce que ce contrôle aurait attrapé s'il avait
échoué. S'il n'y a pas de réponse, il ne contrôle rien.
Suite : simulation 62/62, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Le signal vit dans GetLoadConfig, en r:, et non dans la télémétrie.
`measurement` n'existe que pour les charges arbitrées ; or une charge qu'on
DÉCLARE est précisément celle qui n'y est pas encore. L'écran serait muet au
moment exact où il doit parler — celui de la saisie, avant qu'une obligation
n'achète à l'aveugle tous les jours.
Trois causes, trois gestes : noMeter se répare en une manipulation,
meterWithoutEnergy demande de remplacer le compteur, noSessionEnergy ne se
répare pas. Sans la cause, l'avertissement ne peut dire que « ça ne marchera
pas ».
Et meterThingId ne permet pas de le déduire : un compteur peut publier
currentPower sans totalEnergyConsumed — mesuré sur l'ECS du banc, reproduit
au test avec un powerSwitch désigné comme compteur. La puissance ne suffit
pas, il faut une énergie. Contre-épreuve : déduction par meterThingId seul,
le cas du banc passe pour mesurable.
INVENTAIRE À FROID DU MOCK. Trois fois en trois jours qu'un cas réel s'est
révélé inatteignable ; ce n'est plus un incident, c'est une propriété du banc
— il est plus homogène que la réalité, ayant été construit pour faire marcher
des scénarios et non pour représenter la diversité du parc.
Quatre cas restent structurellement introuvables, dont `source: none` pour
une charge SAINE — toutes les classes pilotables portent une puissance, si
bien qu'une charge non mesurée mais en bon état est impossible à fabriquer,
alors qu'un relais sec est banal sur le terrain. Et la branche `temperature`,
écrite et jamais exécutée faute d'une classe qui porte l'état.
La règle : avant d'écrire un test qui exerce une ABSENCE, vérifier que le
mock peut la produire. Une assertion sur un cas inatteignable ne passe pas,
elle NE S'EXÉCUTE PAS — ce qui est pire, car elle compte comme verte. Le
symptôme se reconnaît : la contre-épreuve ne mord pas.
Deux ajouts dans AGENTS.md. L'asymétrie des latences est une PROPRIÉTÉ, pas
une chance : le refus qui coûte de l'argent est celui de la descente, et
c'est le plus vite constaté — ce qui n'est vrai que parce que le seuil vient
du mécanisme. Et la question opératoire appliquée aux trois autres identités,
avec un résultat inégal qui est le but : celle de `draw` repose sur le fait
que le compteur voie toute la maison, ce que rien ne vérifie ;
Σ levels[].targetW == estimatedPowerW est interne au plan et ne dit rien du
matériel — il a fallu un champ hors de la formule pour relier les deux.
Suite : simulation 61/61, loadmodel 22/22, charging 48/48 identique à la
référence, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Mesuré AVANT d'implanter, et la mesure a corrigé le diagnostic.
Le constat disait « un budget de surplus qui ignore ces watts ». Ce n'est pas
ce qui se passe : quand une charge consomme et OBÉIT, la comptabilité est
juste — sa conso est recréditée puis réallouée à elle-même, et les suivantes
ne reçoivent que le surplus réel. Export 500 W, A à 4 400 W obéissante, B
reçoit 500 W. Corriger cela aurait été corriger un non-défaut.
Le vrai défaut est plus grave, et l'hypothèse est écrite dans le code :
« le budget est une mesure dont la conso de la charge a déjà été retranchée »,
c'est-à-dire « je peux rendre ces watts parce que je peux les reprendre ».
C'est un prêt, et rien ne vérifie que l'emprunteur rembourse.
Mesuré, le cas où la promesse est engagée : A commandée à 0 par son plancher,
ses 4 400 W redistribués à B. Si A obéit, tout est juste. Si A n'obéit pas —
commande perdue, mode manuel, véhicule qui limite — la maison tire 8 400 W
pour 4 900 de production : 3 500 W importés que personne n'a décidés.
Et l'identité surplus + recrédit − alloué == restant TIENT dans les deux cas.
C'est ce qui distingue un prêt d'une erreur : la comptabilité est juste,
c'est l'hypothèse sur laquelle elle repose qui n'est pas vérifiée — donc
aucun contrôle de cohérence ne pouvait l'attraper.
Le test épingle le comportement ACTUEL, correct SOUS HYPOTHÈSE, et dit à
quelle condition il devient faux : le jour où le recrédit sera conditionné à
l'obéissance constatée, c'est l'allocation de B qu'il faudra revoir, pas le
test. Écrit pour qu'on ne le « corrige » pas par réflexe.
Ce que le design proposait — retrancher la conso subie du budget — est SANS
OBJET : elle en est déjà retranchée par le compteur. La note est conservée
pour que personne ne la réimplante en la croyant oubliée.
Suite : simulation 60/60, loadmodel 22/22, charging 48/48 identique à la
référence, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Déploiement vérifié SUR MACHINE et non déduit du script : version relue,
nymead actif, arbitre initialisé, et les quatre motifs du §10 présents dans
le binaire posé.
Piège de vérification noté au passage : authorisedW, perPhaseBound et
binding sont des QStringLiteral, donc stockés en UTF-16 et invisibles à
`strings` par défaut. Un premier relevé les donnait absents — j'ai failli
les rapporter manquants. `strings -el` les trouve. Vérifier une chaîne dans
un binaire demande de savoir comment elle y est encodée.
Et le design du premier constat de l'app, ouvert plutôt qu'attaqué au code.
Trois choses qu'il établit, toutes mesurées :
Le titre est trop étroit. « Réappliquer la commande de l'arbitre » ne décrit
pas le cas : en mode manuel l'arbitre NE COMMANDE PAS. Ce qui s'est passé est
qu'une écriture du proxy a échoué pendant l'indisponibilité, que personne ne
l'a rejouée, et que l'organe est resté sur une consigne dont plus aucun
commandeur ne se réclame.
La pièce qui manque est là où le constat porte : l'EvAdapter ne garde PAS sa
dernière consigne, là où les adaptateurs en watts la gardent. Ils en ont
besoin pour l'écrêtage de verrou ; la borne était pilotée par le proxy, qui
n'a jamais eu à se relire.
Le vrai coût n'est pas l'affichage. draw.committedW à 0 pendant que 4,4 kW
sont tirés veut dire que le budget de surplus est calculé sans ces watts :
le moteur alloue de l'énergie qui n'existe pas. Le délestage, lui, protège —
il agit sur la marge MESURÉE, qui les inclut. C'est le budget qui ment.
Quatre décisions posées, dont la principale : signaler toujours, réappliquer
jamais telle quelle. Rejouer une consigne vieille de plusieurs minutes, c'est
décider avec des données mortes — ce que le mode dégradé L2 refuse déjà de
faire. Ce qui manque n'est pas le rejeu, c'est que l'écart soit DIT tant
qu'il dure, et il dure indéfiniment quand personne ne reprend la main.
Ordre de travail : mémoire de la commande, puis écart publié sans décider
dessus, puis comptabilité corrigée, et la reprise en main EN DERNIER — c'est
la seule étape qui commande du matériel, et on saura alors combien de fois
le cas se produit vraiment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Vérifié plutôt que supposé. La version EXACTE qui a planté est encore au
dépôt nymea — indispensable, car des symboles d%sune autre version ne
résolvent pas un offset, ils le résolvent FAUX.
Trois points qui rendent l%sopération sûre : la version exacte existe ;
l%sépinglage évite la cascade (sans lui apt prendrait la 1.16.0 et mettrait à
jour toute la pile de développement) ; et ces paquets sont amd64, Section
debug, n%sinstallant que /usr/lib/debug — le banc est arm64 et ne peut pas
être affecté.
`sessionEnergy` est l'ACCUMULATEUR du plugin V2C, pas un compteur remis à
zéro pour le moteur : l'écart avec `chargeEnergy` est constant au
dix-millième (7,2044 kWh sur deux échantillons à deux heures d'écart), parce
qu'il porte les incréments d'avant la dernière remise à zéro de la borne.
Le lire directement ferait croire toute obligation éco tenue de 7,2 kWh dès
le premier cycle — un nombre crédible et faux que rien ne signalerait.
Contre-épreuve : lecture directe, le test annonce 7204.
La base se prend à l'ouverture de l'OBLIGATION, jamais au démarrage de
nymead : sinon un redémarrage en pleine session réinitialise l'avancement
sur une valeur déjà accumulée, et la recharge de nuit relue au matin repart
de zéro. Elle est RECAPTURÉE sur un recul franc de l'accumulateur — une
nouvelle session — mais pas sur un recul infime, qui est du bruit de lecture
et coûterait l'avancement acquis à chaque frémissement du compteur.
Ce que le moteur ne refait PAS : la détection de remise à zéro de la BORNE
vit dans le plugin, qui interroge à 30 s. Le moteur travaille à la minute et
raterait des cycles entiers. Lire comment le plugin l'avait écrite a évité
d'ajouter une seconde accumulation, moins fine, en concurrence de la
première.
Trois maillons manquants raccordés, tous déclarés et alimentés par personne :
EvCharger n'exposait pas sessionEnergy ; LoadContextTelemetry::sessionWh
n'était rempli nulle part ; et toLoadContext() ABANDONNAIT les besoins
déclarés, si bien que LoadContext::needs n'était rempli par aucun adaptateur.
L'obligation éco n'existait qu'en configuration.
Mock : sessionEnergy ajouté à chargerPhaseSwitching UNIQUEMENT — `charger`
reste sans, ce qui donne le cas unmeasurable nativement. La suite porte les
deux régimes, comme le banc.
Le régime est publié alors qu'aucune décision ne s'y appuie encore, et c'est
délibéré : cela sépare publier le régime de décider avec, comme measurement
l'a été de l'arbitrage, et rend R6 testable le jour où le motif naîtra au
lieu d'un invariant posé sur du code que rien n'émet.
Suite : simulation 56/56, charging 48/48 identique à la référence ligne à
ligne, loadmodel 21/21, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Six appels à `update(QDateTime::currentDateTime())` manquaient la garde
ENERGY_SIMULATION que leurs voisins ont (l.124, l.288) :
setPhasePowerLimit, setAcquisitionTolerance, et trois dans
onActionExecuted — qui partent sur toute action manuelle appliquée à une
borne.
Un cycle d'arbitrage complet partait donc à l'horloge MURALE au milieu
d'une suite qui injecte un temps simulé. Les deux horloges se mélangeaient
dans les verrous : l'armement paresseux (ECS-412) figeait m_lastSwitch sur
l'heure qu'il était, et un scénario daté en dur se déroulait « avant » son
propre armement — elapsed négatif, verrou jamais ouvert.
Ce n'est pas un défaut de production : il n'y a là-bas qu'une seule horloge.
C'est une faille de REPRODUCTIBILITÉ, et elle touchait tout test de
simulation réglant une limite de phase, une tolérance d'acquisition, ou
exécutant une action manuelle sur une borne.
PREUVE DU CORRECTIF : la garde rendue, testL4ShedsAPacAndSaysItForcedTheLock
repasse avec une DATE FIXE, trois fois sur trois — ce qu'il ne pouvait pas
faire. L'ancrage sur l'horloge réelle, posé la veille faute d'avoir la
cause, était un contournement ; il est retiré, et la date fixe revient parce
qu'elle rend les journaux reproductibles.
tools/check-simulation-clock.py, câblé en 4/4 de ci-quality.sh, et vérifié
mordant : garde retirée, il nomme la ligne exacte. Il a trouvé trois des six
déclencheurs dès son premier passage.
Pourquoi une vérification STATIQUE et pas un test : la suite ne peut pas
dire d'elle-même que son verdict dépend de l'heure, puisque c'est le verdict
qui ment. Le défaut n'a été trouvé que parce qu'il échouait cinq fois sur
cinq à code identique — une fenêtre de nuisance plus étroite ne basculerait
qu'une fois sur vingt, passerait pour une fragilité de temporisation, et
serait relancée jusqu'à ce qu'elle passe. C'est la famille de la semaine
sous une forme de plus : après l'instrument dont le silence ressemble à un
résultat, l'instrument dont le VERDICT ment selon l'heure.
Suite complète : simulation 54/54, charging 48/48 identique à la référence
ligne à ligne, loadmodel 21/21, spotmarket 32/32, doxygen 0 avertissement.
Aucun test ne dépendait de ces cycles.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Préalable au reste, et il n'ajoute aucune fonction. La chaîne de sélection
du motif vivait au milieu de l'émission : il n'y avait qu'un motif possible
parce qu'il n'y avait qu'un endroit pour le former. Chaque passe devra
choisir SON motif sur SES grandeurs (R7 — le motif dit de quel niveau il
parle), donc la chaîne sort avant que la seconde passe n'arrive.
`MotifEntrees` regroupe exactement ce dont le choix dépend : ce qui n'y
figure pas ne peut pas influencer le motif, et c'est vérifiable à l'œil.
Comportement CONSTANT, et vérifié comme tel : la fonction extraite est
IDENTIQUE TOKEN POUR TOKEN à la chaîne d'origine, comparée par
normalisation. L'ordre des branches est ce qui porte les précédences
(LM-1011 : BELOW_MIN_POWER prime sur DRAW_CAP tant qu'il reste de
l'autorisation) — le réordonner changerait le motif publié sans qu'aucun
nombre ne bouge.
Deux erreurs attrapées en chemin, toutes deux par relecture :
- la substitution avait préfixé les CLÉS de charge utile ("budgetW" →
"e.budgetW"), soit un changement de contrat silencieux ;
- un `else if` transformé en `if` : sans effet ici puisque chaque branche
retourne, mais une divergence gratuite dans une fonction dont l'ordre
des branches est la spécification.
Et un piège de HARNAIS, sans rapport avec l'étape mais qui la bloquait :
testL4ShedsAPacAndSaysItForcedTheLock échouait 5 fois sur 5 alors qu'il
passait la veille, à code identique. Ni le code sous test, ni une fragilité
de temporisation — un cycle d'arbitrage tourne à l'horloge MURALE avant le
premier cycle simulé (sonde : action SG_NORMAL estampillée « 22:52:07 »).
L'armement paresseux d'ECS-412 fige m_lastSwitch sur cette heure, et un
scénario daté en dur se déroule « avant » son propre armement : elapsed
négatif, verrou jamais ouvert. Le test passait ou échouait SELON L'HEURE
QU'IL EST, ce qui est pire que les deux, et c'est aussi l'explication du
remainingS: 1288 observé plus tôt sans qu'on sache le lire.
Corrigé en ancrant l'origine du scénario sur l'horloge réelle : la
chronologie relative suffit, l'origine doit vivre dans la même horloge que
ce qui touche le système. Le commentaire dit à quelle condition ce choix
devient faux, conformément au troisième mode d'érosion.
Reste ouvert et consigné : pourquoi un cycle complet s'exécute à l'horloge
murale dans une suite compilée avec ENERGY_SIMULATION, où les minuteurs sont
explicitement exclus. Pas un défaut de production — une seule horloge y
existe — mais une faille de reproductibilité pour tout test manipulant un
Thing.
Suite complète : simulation 54/54, charging 48/48 identique à la référence
ligne à ligne, loadmodel 21/21, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
11.1 étalement uniforme, avec les trois choses qui s'écrivent avec lui :
recalculé à chaque cycle (une cadence figée ne rattrape pas et manque
l'échéance en ayant l'air de travailler) ; il se durcit à l'approche —
2 kWh font 2 kW à une heure et 12 kW à dix minutes, donc la fenêtre d'achat
massif arrive d'un coup et c'est le MOTIF qui doit le dire ; et un point de
non-retour explicite, parce qu'un seuil nommé se discute là où une asymptote
se subit.
11.2 oui aux quatre champs, et la subtilité entre dans le CONTRAT : sous la
réserve batterie, draw.remainingW reste non nul pendant que budget.remainingW
est à zéro. LM-1203-b vue depuis la frontière — la réserve annule le surplus,
jamais l'autorisation de soutirage.
11.3 dissoute, 11.4 par champ explicite.
Et un troisième mode d'érosion dans AGENTS.md, symétrique des deux autres :
non pas une règle qui se périme faute d'être exécutable, mais une règle rendue
IMMORTELLE par sa propre garde. draw.authorisedW a été refusé pour un motif
juste, épinglé par un test, puis le motif est tombé — et la formulation a
survécu, protégée par un test qui ne savait pas que le monde avait changé.
Parade déjà pratiquée ici : quand un test fige une ABSENCE, son commentaire
écrit la condition de levée. « Absent tant que rien ne le mesure » se relit et
se lève ; « ne doit pas exister » se relit et s'obéit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Rangés pour ne pas se perdre — aucun ne passe devant le §10, et aucun ne se
déduit du code : les trois viennent de la machine.
1. Une commande perdue pendant une indisponibilité n%s est jamais réappliquée.
Coupure Modbus, la box restaure « false 6 A », la borne reste à 7 A : 4,4 kW
tirés, draw.committedW à 0, budget de 2 349 W qui les ignore. Une seconde de
coupure suffit. Sur 18 kVA invisible, sur 6 kVA c%s est le disjoncteur.
Même famille qu%sECS-111 et ECS-415, sous une troisième forme : après la
télémétrie et après la valeur de retour, voici l%sexécution.
2. chargingState figé à Idle pendant une charge réelle — pas de la péremption,
personne ne maintient le champ. Un champ sans mainteneur doit être ABSENT,
pas figé, sinon un écran dit « à l%sarrêt » pendant une charge.
3. ChargingModeNormal n%est pas un boost : il restaure des valeurs mémorisées
qui peuvent être false/6 A. Le nom et l%seffet ne coïncident pas.
Et un point ouvert qui se clôt : la V2C publie sessionEnergy. PIÈGE consigné
dans le design §10 étape C — l%saccumulateur porte un OFFSET constant (7,2044
au dix-millième sur deux échantillons), donc deliveredWh doit être une
différence depuis une base capturée. Une lecture directe ferait croire toute
obligation éco tenue de 7,2 kWh au premier cycle.
Ce design précédait le lot délestage. Trois de ses sections décrivaient du
code désormais livré (le plafond comme objet, le délestage, DRAW_CAP), et
une proposait une forme depuis refusée. Le lire tel quel faisait
reconstruire l'existant.
La correction qui compte : PlanDraw n'a qu'un champ. L'absence
d'authorisedW/remainingW a été défendue en prose puis épinglée par un test,
au motif qu'un authorisedW forgé afficherait un plafond qui n'existe pas.
Ce motif est TOMBÉ — le plafond existe maintenant, et le champ serait une
lecture. C'est une décision à reprendre, pas une règle à appliquer : une
décision juste dont le motif a disparu et dont seule la formulation survit.
Plan de travail réécrit sur la stratégie qui a marché au délestage : trois
étapes à comportement constant, une seule qui change.
A — le split décider/émettre, sans ajouter de fonction. Aujourd'hui
buildSetpointAction() décide, écrête, comptabilise et motive dans le
même geste, et décrémente le budget en émettant : une seconde passe y
est littéralement inexprimable. Piège nommé : l'arrondi et l'écrêtage
de verrou doivent migrer SANS changer d'ordre relatif, ECS-306 et
ECS-309 en dépendent — les déplacer ferait publier des motifs faux
sans qu'aucun nombre ne bouge.
B — draw complété (binding, perPhaseBound, authorisedW, remainingW),
publication seule.
C — l'avancement branché EN LECTURE SEULE : sessionWh alimenté, progress
publié avec son régime. C'est là que R5 devient vraie et que R6
devient testable AVANT d'être nécessaire — on sépare publier le
régime de décider avec, comme measurement l'a été de l'arbitrage.
D — la passe éco, seule étape qui change le comportement.
Quatre décisions posées, dont la centrale : comment une obligation en
ÉNERGIE devient une cible en WATTS. minEnergyWhPerDay est transporté et lu
par aucune décision ; sessionWh est déclaré et rempli nulle part. Les deux
moitiés de l'obligation éco sont de la plomberie inerte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
La protection de surcharge ne connaissait que les bornes VE : une PAC ou un
routeur pouvaient tenir un dépassement sans que rien ne les redescende. Elle
déleste désormais les charges du waterfall, de la dernière servie à la
première — le même ordre total que la cascade, lu à l'envers, pour que
délester ne puisse pas contredire l'ordre dans lequel on a servi.
Délester n'est pas toujours retirer des watts. Une PAC ne se module pas : on
la fait redescendre d'ÉTAT, vers 2 et jamais 1. C'est le cas que le bornage
de l'étape 3 ne pouvait pas traiter — il empêche d'allouer, il ne retire
rien à personne.
Le franchissement de verrou se CONSTATE : on tente d'abord sans forcer, et
`minOnBypassed` n'est marqué que si le verrou a réellement refusé. Le
déduire d'un verrou simplement ACTIF serait faux — un verrou peut être armé
et permettre malgré tout le geste demandé. Le marqueur annoncerait alors un
court-cycle qui n'a pas eu lieu, et le premier compresseur réellement
maltraité passerait inaperçu au milieu des fausses alertes. Ce constat
n'était pas possible avant ECS-415.
On ne force que pour un plafond SUBI. Comportement observé, non postulé : la
contre-épreuve « forçage interdit » — qui est le comportement d'un plafond
EcoSelfImposed — laisse la PAC en état 4.
Un seul commandeur par organe : les charges délestées sont revendiquées pour
le cycle et le dispatch les saute, sinon la consigne du plan rallumerait ce
que la sécurité vient de couper.
La fenêtre d'exécution est étroite — après syncAdapters(), avant le dispatch
— et les deux placements écartés sont consignés au design §6bis parce qu'ils
se représenteront.
Ce lot a été repris après un arrêt : deux versions antérieures du test
passaient sans rien prouver, leurs prémisses étant supposées. Les trois
cycles sont désormais MESURÉS puis assertés, l'armement à froid compris.
Suite complète : simulation 54/54, charging 48/48 identique à la référence
ligne à ligne, loadmodel 21/21, spotmarket 32/32, doxygen 0 avertissement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
SgReadyAdapter::applyAction() renvoyait, quand le verrou minStateHold
refusait la transition, l'action DEMANDÉE telle quelle. Un appelant qui
relisait `state` y retrouvait l'état qu'il venait de demander et concluait
au succès — alors que rien n'avait été écrit et que les contacts n'avaient
pas bougé.
Ce n'est pas un défaut du délestage, c'est un défaut de contrat. N'importe
quelle descente d'état pouvait échouer en silence, et `available` restait
vrai : la charge avait l'air saine pendant que la PAC tirait 3 kW. Même
famille qu'ECS-111 — une issue indiscernable de son contraire — transposée
au retour d'une commande au lieu de la télémétrie.
Toute sortie décrit désormais l'état RÉELLEMENT tenu, `estimatedPowerW`
compris. L'idempotence n'y échappe pas : demander « état 4, 0 W » à une PAC
qui en tire 3000 doit rendre 3000, pas le zéro de l'appelant — sinon il lit
son enveloppe, pas une réponse. Même correction sur la branche « motif
vide » du RelayRouter et de l'EtmVariableLoadAdapter.
Le défaut était LATENT : aucun appelant ne lisait ce retour, le dispatch
l'ignore. Le premier à s'y fier fut le délestage L4 en cours d'écriture, qui
a publié 3 kW rendus par une PAC restée en état 4. Un contrat qu'aucun
appelant n'exerce n'est pas un contrat tenu, c'est un contrat non testé.
Deux pistes écartées, mesurées et non supposées. m_currentState n'était pas
en cause : il est écrit synchroniquement, sans attendre d'acquittement.
ECS-411-b non plus : la relecture des contacts répond à une divergence entre
état interne et matériel, et il n'y en avait aucune — l'état interne était
juste, c'est le retour qui mentait.
Les trois pièges rencontrés à l'étape 4 sont consignés dans
DESIGN_DELESTAGE §6bis, les deux placements écartés compris. L'étape 4
elle-même reste non livrée.
Suite complète : simulation 53/53, charging 48/48, loadmodel 21/21,
spotmarket 32/32, doxygen 0 avertissement. Contre-épreuve : sur l'ancien
retour, refuse.state vaut 2 — l'état demandé — au lieu de 4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Vivre avec le pessimisme de la pire phase est le bon arbitrage pour une
couche de sécurité — il coûte du rendement, jamais de la sécurité. Mais
l'échéance se rapproche par les deux bouts, et l'écrire comme une position
de principe serait faux.
Côté matériel, l'information existe déjà pour une borne : la V2C publie
currentL1/L2/L3 depuis le 2026-08-28. Côté modèle, le §14a distinguera par
phase et ne pourra pas se contenter d'un nombre.
Le jour venu, houseDrawMargin() retiendra la phase de la charge au lieu de
la pire : un seul appel change, parce que l'étape 2 compare des MARGES et
non des plafonds.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Patrick Schurig
