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
TROIS choses, plus une sauvegarde.
1. LM-1011 — la précédence BELOW_MIN_POWER / DRAW_CAP est dans la SPEC. Je
l'avais écrite hier dans DESIGN_10.md : une note de conception se périme, la
spec fait autorité, et l'index ne voyait donc pas la règle. DESIGN_10 n'en
garde qu'un renvoi.
Autorisation résiduelle non nulle mais sous le plus petit palier →
BELOW_MIN_POWER ; DRAW_CAP réservé au résiduel nul. Ce n'est pas une règle
nouvelle : c'est celle de +etm19 transposée à une seconde ressource — le
surplus a déjà SURPLUS_INSUFFICIENT (« il n'y a rien ») contre BELOW_MIN_POWER
(« il y en a, mais pas au bon format »), et il aurait été absurde qu'une
ressource se lise autrement que l'autre. Ce qui décide n'est pas la véracité
mais le GESTE appelé : revoir le plafond, ou lire la fiche technique.
Conséquence de l'agent app retenue : le point de rupture de l'écran 2 est
ancré sur le DRAW_CAP, donc sur l'épuisement réel. Une charge refusée APRÈS
lui pour cause de palier ne le déplace pas — sans quoi deux charges
successives produiraient deux points de rupture concurrents dans un cycle.
2. LES TROIS NOMBRES au contrat — décidé, appliqué, mesuré. Ma correction sur
allocatedW a fait apparaître un troisième nombre que ni la maquette ni nous
n'avions nommé. INTERFACE.md porte le tableau ET ce que chaque écart signifie,
parce que c'est là qu'un écran se trompe de diagnostic : décidé ≠ appliqué est
une affaire de FORMAT, appliqué ≠ mesuré une affaire d'OBÉISSANCE — et cette
seconde lecture dépend encore de measurement.source.
3. R3 proposée à l'app avant d'être écrite : funding dit d'où viennent les watts,
il ne dit pas dans quel compteur ils tombent. Un niveau publierait sa
ventilation (counts), Σ counts == targetW toujours, et l'identité devient
calculable SANS exception — y compris quand draw.committedW arrivera.
Et la PRÉCONDITION du §10 est consignée : il ne part pas sans l'extension du
délestage au waterfall (LM-1006 couplage 1). La protection de surcharge ne
déleste aujourd'hui que les bornes ; livrer l'éco sans elle donnerait un plancher
capable de faire disjoncter une installation.
Aucun code. ci-quality 3/3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
L'agent app a répondu au §9. Décisions inscrites en LM-1010, précédence des
motifs et réponse à R4 en DESIGN_10.md, réponse à l'app en brief §10.
SON ARGUMENT SUR LA LISTE EST MEILLEUR QUE LE NÔTRE, et il est repris tel quel :
nous disions « le rang doit rester lisible », il dit que l'ORDRE DE SERVICE N'EST
PAS UNE PROPRIÉTÉ DE LA CONFIGURATION — il change d'un cycle à l'autre selon les
planchers atteints. Trier par lui ne rendrait pas le rang illisible, ça rendrait
la LISTE instable, ce qui est pire. Une liste de configuration ne peut pas avoir
une colonne vertébrale qui bouge sous le doigt qui vient d'y glisser une charge.
Les deux autres réponses : une entrée par charge et deux lignes dans la carte —
on dédouble là où l'objet affiché est la SÉQUENCE, jamais là où il est la CHARGE ;
et éco servi / confort non en deux ÉTATS NOMMÉS, jamais une fraction, sans quoi
le régime nominal se lirait comme une dégradation permanente.
PRÉCÉDENCE DRAW_CAP ↔ BELOW_MIN_POWER, tranchée et écrite ICI plutôt que de
chaque côté de la frontière. Autorisation résiduelle non nulle mais sous le plus
petit palier : BELOW_MIN_POWER. DRAW_CAP dit « il n'y a plus d'autorisation », or
il en reste — pas au bon format. C'est la distinction de +etm19 entre
SURPLUS_INSUFFICIENT et BELOW_MIN_POWER, transposée telle quelle au soutirage :
pas une règle nouvelle, la même appliquée à une seconde ressource. Ce qui la
décide est le GESTE qu'elle appelle — revoir le plafond, ou lire la fiche
technique.
RÉPONSE À R4 : les compteurs de budget comptent le DÉCIDÉ. Le budget est le
registre de la cascade, et ce qui détermine ce que reçoit la charge suivante est
la valeur décidée. L'arrondi vit après, dans l'adaptateur, propre à chaque
mécanisme — compter le commandé obligerait à rouvrir le budget après le dispatch,
c'est-à-dire à décider deux fois.
ET UNE PRÉMISSE DE R4 EST FAUSSE, mieux vaut le dire maintenant : la maquette
pose que allocatedW publie « ce qui a été commandé ». buildTelemetry() publie le
PLAN, et applyActionsToAdapters() reçoit le slot const — rien n'est réécrit après
le dispatch. Mesurable : testUnpluggedChargerTakesNoBudget attend allocatedW ==
3000 sur une borne dont le courant commandé donne 2 990 W. Donc Σ targetW ==
allocatedW tiendra exactement, et l'écart que l'écran veut nommer est entre
allocatedW (décidé) et la charge utile de MÉCANISME (appliqué) — déjà publiée.
L'app a les deux nombres ; leurs noms étaient inversés.
PROCHAINE ACTION DU §10 : R2, funding descend au niveau. Seule des huit à être un
changement de forme d'un champ existant ; les sept autres attendent sans se
renchérir.
Aucun code. ci-quality 3/3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Quatre des cinq points du §10 sont désormais tranchés. 8.2 : le plafond §14a
porte les deux formes — par phase et au total — sans jamais convertir. 8.4 : la
cible de confort reste un comparateur, le dosage attendant le modèle thermique du
§11. Confirmations, rien de rouvert.
8.5 reste, et il ne se tranche pas ici : c'est l'ordre de service APPARENT. Un
plancher éco de rang 4 passe devant un confort de rang 1 — voulu, lexicographique
sur (niveau, rang), et contre-intuitif pour l'installateur qui vient de poser son
ordre. La question est POSÉE à l'agent app dans le brief §9, pas répondue.
Trois choses lui sont données pour décider : sur quoi la liste est ordonnée — par
rang, et l'ordre affiché n'est plus l'ordre de service, ce qu'il faut dire ; ou
par ordre de service, et le rang cesse d'être lisible. Une entrée par passe ou
une entrée à deux états. Et ce qu'on voit d'une charge dont l'éco est servi et le
confort non — le cas le plus fréquent, et le seul qui n'ait AUCUN équivalent
aujourd'hui : la télémétrie publie un motif et une allocation, un seul de chaque.
Ce qui lui est demandé est de dire quelle FORME DE PUBLICATION rendrait l'écran
possible, comme la maquette des mécanismes l'a fait pour les six écrans — pas de
câbler quoi que ce soit, le §10 n'étant pas implémenté. Deux garde-fous joints
pour que la réponse ne se ferme pas sur un détail : une charge reçoit une SEULE
commande par cycle quelles que soient les passes (LM-1003), et le rang reste UN —
pas de prioritéEco/prioritéConfort, rejet explicite de LM-1002.
Et la conséquence est écrite des deux côtés : le §10 ne se code pas avant cette
réponse. Commencer par le moteur reviendrait à inventer une charge utile puis à
demander à l'écran de s'en arranger, c'est-à-dire l'ordre inverse de celui qui a
marché.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
1. La réserve batterie n'annule QUE le surplus, pas une autorisation de
soutirage. Inscrit en LM-1203-b : la passe éco du §10 ne dépense pas de
surplus, elle dépense une autorisation d'acheter. Deux raisons dont chacune
suffit — une obligation qui cède à la réserve cesse d'être une obligation, et
la réserve garde son sens là où elle en a un, empêcher de vider la batterie
dans un chauffe-eau, ce qu'un soutirage réseau ne fait pas.
2. Le repli dégradé : les deux cas sont distingués, et la distinction RETIRE le
point du lot. Le plafond du §10 est AUTO-IMPOSÉ, donc un repli qui ne dépense
pas le respecte par construction — rien à écrire. L'exigence dure — tenir une
borne imposée par un TIERS alors que le moteur ne décide plus — appartient au
§14a et vivra hors du moteur. Les confondre aurait fait hériter au §10 d'une
exigence qui ne le concerne pas encore. LM-1006-1 porte désormais la table
des trois sources et de ce que « survivre » veut dire pour chacune.
3. phaseCount de la V2C : saisie à l'appairage. La Trydan du banc est
triphasée ; le repli « câbler en monophasé » est écarté, il ferait tester une
installation qui n'est pas celle du client.
Et l'attendu « sessionEnergy sur matériel réel » est RETIRÉ pour demain — le
refus V2C est documenté, pas un oubli. Remplacé par deux choses : ré-examiner
ChargeEnergy borne et référence en main, et exercer la condition C1 de LM-1009
sur ce cas réel plutôt que sur un cas fabriqué.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj
Deux livrables, aucun code.
DESIGN_10.md — le §10 sous la contrainte des deux notes.
Le délestage part AVEC pour une raison arithmétique, pas de calendrier : la
passe éco n'est pas bornée par le surplus mais par une autorisation de
soutirage, et cet objet n'existe pas encore. Le lot doit donc le créer.
LM-1006-1 devient une structure : DrawCap {source, totalW, perPhaseA, until} et
DrawBudget qui publie `binding` — QUI a mordu. Le piège technique est nommé et
tranché : les trois sources ne parlent pas la même langue (le disjoncteur est
par phase, le §14a et l'éco sont des totaux), un plafond total ne protège pas
d'une surcharge monophasée, un plafond par phase n'exprime pas le §14a. La
proposition est de porter les deux et de ne JAMAIS convertir — c'est la
conversion qui perdrait l'information.
LM-1003 impose la vraie refonte : les passes calculent des cibles, une seule
commande sort par charge et par cycle, arrondie une fois au mécanisme. Cela
scinde buildSetpointAction(), qui mélange aujourd'hui décision, écrêtage,
comptabilité et motif. Deux comptabilités distinctes, PlanBudget (d'où vient
l'énergie) et PlanDraw (combien on a décidé d'acheter) — les fondre rendrait
faux l'invariant publié de la première.
Cinq points à trancher, dont trois ne sont pas techniques. Le premier est le
plus lourd : la réserve batterie annule le budget de SURPLUS, mais la passe éco
dépense une autorisation de SOUTIRAGE. Si la réserve l'annule aussi, un plancher
éco ne sera jamais atteint batterie basse ; si elle ne l'annule pas, la maison
achète pendant qu'elle manque. Recommandation donnée, décision d'exploitation.
L'ordre de travail met en tête les deux étapes qui NE CHANGENT RIEN — publier le
plafond sans effet, puis la refonte décider/émettre à comportement constant,
prouvée par l'invariance des 16 scénarios enregistrés. Si un seul point de
contrôle bouge, c'est qu'une décision a changé, et il faut savoir laquelle.
PREPA_BANC_20260828.md — deux blocages silencieux trouvés la veille.
1. La ThingClass trydan ne déclare PAS phaseCount, et aucun registre Modbus V2C
ne le porte. EvCharger::phaseCount() retombe sur 1 : sur une Trydan
triphasée, le plancher publié vaudrait 1 380 W au lieu de 4 140, et la
conversion W→A donnerait une consigne 3× trop haute. C'est exactement la
famille de défaut que 3g-2 vient de fermer, rouverte côté plugin. Correctif
proposé : saisie à l'appairage, comme la voiture simulée le fait déjà.
2. sessionEnergy n'est délibérément pas exposée — le brief du plugin l'interdit,
evcc ayant retiré son ChargeRater pour cette borne (firmware peu fiable).
Donc « sessionEnergy sur matériel réel » n'est PAS franchissable demain. En
échange, demain permet la validation qui lèverait l'interdit, et exerce pour
de vrai la condition C1 de LM-1009 sur du matériel.
Plus : le plugin V2C n'est pas installé sur le banc, la Skoda n'a aucune
intégration (donc voiture manuelle, avec les quatre réglages à saisir), et
l'IP de test .127 est libre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj
Patrick Schurig