`phasePowerLimit` devient un `DrawCap{Breaker, perPhaseW}` et
`evPhaseAllowanceW()` traverse `resolveDrawMargin()` — la mécanique du
délestage est branchée, et rien ne bouge. C'est le but : à comportement
constant, tout écart observé ensuite est un défaut, pas une évolution.
L'égalité est obtenue par CONSTRUCTION. `phaseDrawW()` inverse
`calculateAllowanceAmpere()` phase par phase plutôt que de relire les états
du compteur : les lectures amont ne sont pas symétriques entre phases, et
les recopier ici en aurait fait deux versions vouées à diverger.
Deux déplacements sans changement de valeur : l'écrêtage `qMax(0, …)`
descend chez le consommateur (la résolution rend une marge SIGNÉE, dont
l'étape 4 a besoin pour dire de combien délester), et le facteur 230 remonte
dans le plafond, qui s'exprime en watts comme les autres.
Vérification : quatre suites diffées ligne à ligne contre une référence
capturée avant l'édition — charging 48/48 et simulation 50/50 identiques,
loadmodel 21/21, spotmarket 32/32. Contre-épreuve : à 1 V près la suite ne
discrimine pas (consignes en ampères entiers), donc cet essai ne prouve
rien ; à un facteur dix, 7 échecs. Le chemin est vivant.
Au passage, une `\note` du .h affirmait qu'on rend à la borne ce qu'elle
tire déjà. Le code ne l'a jamais fait, et c'est délibérément de sécurité :
sur une phase en dépassement la marge est négative, et c'est ce signe qui
ramène la borne à son minimum.
Décisions 6.1 à 6.3 gravées dans le design, et défaut amont consigné dans
SAFETY.md — non corrigé sciemment, il appartient à un [upstream-fix] isolé.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
Écrit avant tout code de liaison, comme le workflow l'exige pour une couche de
sécurité. Il dit sous quelle forme, dans quel ordre, et nomme trois points à
trancher.
L'écart mesuré : verifyOverloadProtection() parcourt m_evChargers et rien
d'autre ; le waterfall ne connaît le plafond que par evPhaseAllowanceW(), et
uniquement pour les bornes. Les charges pilotées et la PAC n'ont aucun plafond —
invisible tant que la cascade ne dépense que du surplus, puisqu'on ne peut pas
dépasser ce qu'on n'achète pas. Le §10 change cela.
LE POINT TECHNIQUE DU LOT, et il n'est pas évident : on ne compare pas les
plafonds — ils n'ont pas la même forme — on compare LES MARGES qu'ils laissent.
Un plafond par phase donne sa marge sur la phase la plus chargée, un plafond
total la sienne sur le soutirage mesuré ; les deux sont des watts, donc
comparables. Le plus petit mord, et on retient sa source. Aucune conversion, donc
aucune hypothèse d'équilibre entre phases — et la marge est exactement ce que la
cascade doit connaître pour ne pas dépasser : le même nombre borne et explique.
Deux endroits, deux rôles, et ce n'est pas une redondance : la cascade empêche de
CRÉER le dépassement, la protection L4 rattrape ce qu'on n'a pas décidé — une
plaque de cuisson, un sèche-linge. L4 garde le dernier mot.
Quatre étapes dont DEUX À COMPORTEMENT CONSTANT (le type, puis la source Breaker
branchée à résultat identique au watt près). Dans un lot de sécurité, ce qui coûte
n'est pas d'écrire le comportement, c'est de prouver qu'on n'a rien cassé.
Trois décisions demandées, avec recommandation : la marge tient-elle compte du
commandé non encore mesuré (recommandé NON — une hypothèse fausse y coupe du
courant) ; que fait le délestage d'une charge sous minOn (recommandé : bypass pour
Breaker et GridOperator, PAS pour EcoSelfImposed — un plafond qu'on s'impose ne
justifie pas d'abîmer un compresseur, et c'est la première conséquence concrète
du fait que la source soit un paramètre) ; et ce que porte le motif DRAW_CAP.
Et ce que le lot ne fait pas : aucun transport §14a, aucun changement du repli L2
— le plafond auto-imposé est respecté par construction dès lors que le repli ne
dépense pas, et l'exigence dure appartient au §14a, hors du moteur.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p
