L'écart était jugé APRÈS le dispatch, entre la consigne qui venait de
partir et la mesure de la précédente, puis consommé au cycle suivant
avant d'être rejugé. Toute marche de consigne suivie par la borne se
lisait donc comme un refus vieux d'un cycle (60 s, au-delà des 30 s /
7 s de la borne) : recrédit suspendu, coupure, et une boucle de trois
cycles sous un surplus constant (~1,5 kW exportés en moyenne).
jugerCommande() rend désormais UN jugement par cycle, au début du cycle,
lu par le recrédit et par la télémétrie :
- la commande EN VIGUEUR contre la mesure fraîche ; s'ils concordent
(max(200 W, 15 %)), l'épisode se referme ;
- l'ouverture est datée à l'instant de la commande, en temps de cycle,
et non plus à l'horloge murale de la dernière publication ;
- le sens est celui que la commande demande à la charge, et non plus
deviné au niveau de la mesure ;
- en montée seulement, une mesure rapprochée de la commande de plus de
200 W depuis le cycle précédent est une latence. La descente n'a
jamais cette excuse.
command.divergent publie ce verdict ; expectedW et observedW restent
les nombres de la publication.
Le test de reproduction inverse ses assertions « DÉFAUT » : sur trois
rampes (instantanée, 30 s / 7 s, 120 s), 13 A tenus dès le premier
cycle, aucune suspension, export de 10 W dès que la borne a rejoint sa
consigne.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Borne monophasée 6-16 A, 3 000 W de surplus constant. L'écart commande/mesure
est jugé après le dispatch, entre la consigne qui vient de partir et la mesure
de la précédente, puis consommé au cycle suivant par qualifierRefus() avant
d'être rejugé. Une marche suivie se lit donc comme un refus vieux d'un cycle,
au-delà des 30 s / 7 s de la borne : recrédit retenu, coupure (bloquée par le
verrou de 300 s, 6 A tirés pour 0 attendu), puis 7 A, puis 13 A, et ainsi de
suite. La borne tire 1 495 W en moyenne sur 3 000.
Trois rampes : consigne atteinte au pas suivant, 30 s / 7 s, 120 s. Les deux
premières donnent la même trace, cycle pour cycle.
Le test FIGE le défaut. Le correctif devra inverser les deux assertions
marquées « DÉFAUT ». Aucune ligne du moteur n'est modifiée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Elle remplace celle de e775f66, qui portait des ThingId bruts dans
shedding.open et des dates murales dans un test : le `check` n'y était pas
reproductible. Deux enregistrements successifs sont identiques (cmp).
Contre 76bf482 : les 85 fonctions communes sont identiques, sauf 12 lignes
dans 3 fonctions, où seuls le motif et le journal changent ; leurs actions
sont identiques.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le passage en mode manuel ne restitue rien quand la borne est déjà dans
l'état de l'usager : il n'arme donc aucun verrou à l'heure réelle. Le
scénario peut reprendre une date fixe, et la référence `decisions` se
reproduit à l'octet près.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le JSON ne change pas. Mais une QStringList échappait au parcours par type
de l'enregistreur `decisions`, qui anonymise les ThingId des listes : la
référence portait les identifiants tirés au hasard d'une exécution, et le
`check` sortait en ÉCART à chaque passage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hors épisodes de protection, IDENTIQUE à 76bf482 : les 85 fonctions
communes sont identiques octet pour octet, sauf trois. Celles-là gardent
leurs actions (things, proxy) identiques ; seuls le motif des bornes tenues
(OVERLOAD_THROTTLED, sans niveaux) et le bloc shedding changent :
testL4ShedsAPacAndSaysItForcedTheLock (1 ligne),
testBlockedDischargeShowsAtTheMeterAndL4Decides (2),
testOffPeakFullPowerYieldsToThePhaseLimit (9). Quatre fonctions nouvelles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- borne abaissée, coupée, puis reprise par le cycle : une entrée au journal,
et une fermeture qui notifie sans autre cause (contre-épreuve : un cycle
identique ne notifie rien) ;
- borne en mode manuel, hors de loads[] : l'épisode s'ouvre et se ferme par
notification, et la reprise amont le referme ;
- relais et SG-Ready délestés pendant 20 minutes : une entrée par charge,
avant et après dans le langage de chaque mécanisme ;
- 21 épisodes : le plus ancien sort.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Borne : executeChargingAction() devient virtuel (marque [ETM], corps amont
inchangé). L'arbitre laisse partir la consigne, puis la lit. Une baisse ou
une coupure de la protection de surcharge ouvre la tenue, et la borne
publie OVERLOAD_THROTTLED {fromA, toA, cut, overshootW, limitA, o:phase}.
La tenue se lève quand le cycle reprend la borne, ou quand la reprise
amont lui rend son courant manuel. Les verrous de la borne sont lus : un
geste refusé n'est pas publié comme un délestage.
- Cascade : shedWaterfallForOverload() note chaque délestage au journal,
avant et après lus sur runtimeView(). Rien d'autre ne change.
- Télémétrie : bloc shedding {revision, open}, absent tant que rien n'a été
délesté. Sa révision déclenche LoadTelemetryChanged à l'ouverture et à la
fermeture d'un épisode.
- RPC : NymeaEnergy.GetSheddingLog, même droit que GetLoadTelemetry (table
des droits et compte sans droit mis à jour).
Aucune consigne, aucun émetteur, aucun verrou ne change (invariant 2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un événement par ÉPISODE, en mémoire : il s'ouvre au premier geste de
protection et se ferme à la fin du premier cycle complet où la protection
ne tient plus la charge, daté du premier instant libre. « Avant » et
« après » portent la charge utile de mécanisme de l'adaptateur, sans liste
de types. Vingt épisodes ; le plus ancien épisode clos sort le premier.
Aucune décision ne le lit, et il est perdu au redémarrage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans tarif à heures creuses, IDENTIQUE à b1c0ade : 81 fonctions, octet
pour octet, `run` compris. En heures creuses :
- testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter : 7 → 13 lignes
(variante au total aveugle ajoutée) ;
- testOffPeakFullPowerSwitchesToThreePhases : le recrédit de 1 380 W,
refusé sous le plancher triphasé, est servi en confort dans le plafond ;
achat 11 040 → 9 660 W, consigne totale inchangée (11 040 W) ;
- deux fonctions nouvelles : testOffPeakFullPowerAtDawnStaysInTheCeiling
(13 lignes), testOffPeakFullPowerGivesNothingBackWhileSwitchingPhases (2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
§8 : D9 (2026-10-25, suite) — l'écart 4 est corrigé pour la pleine
puissance d'heures creuses ; la dérogation sans heure creuse et les phases
étiquetées restent à leur lot ; le compteur en retard est accepté.
§8.1 : l'écart 4 renvoie à §8.3 ; ce qui reste de la dérogation y est dit.
§8.3 : la règle, les mesures avant/après, les preuves — dont la garde de
bascule de §8.2, désormais éprouvée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
En heures creuses, le niveau éco d'une borne à pleine puissance vaut son
plafond de cycle, qui porte la limite de phase. À l'aube, la passe confort
lui ajoutait le surplus, et seul le courant maximal de la borne écrêtait
la somme : borne monophasée sur A, limite 16 A, plafond 13 A, 2 540 W de
surplus — 16 A servis, la phase A à 18 A. L'achat publié valait 2 990 W
quand le compteur n'importait que 450 W.
Pour une borne qui porte EV_OFF_PEAK_FULL_POWER :
- la passe confort sert le surplus DANS le plafond ;
- l'achat cède ce que le surplus finance (gridW, drawCommittedW,
draw.committedW) : la somme reste le plafond ;
- la part confort n'a pas de plancher : il porte sur la somme, qui vaut
le plafond. Sinon un surplus sous le plancher serait refusé, ou démarré
par EV_GRID_START, un second achat en plus du premier.
Hors heures creuses et sans tarif, rien ne change.
Tests : testOffPeakFullPowerAtDawnStaysInTheCeiling (nuit, aube, plein
soleil : 13 A, achat 2 990 / 450 / 0 W, achat ≤ import du compteur) ;
testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter étendu au total
aveugle (13, 15, 15… au lieu de 13, 16, 16…) ;
testOffPeakFullPowerGivesNothingBackWhileSwitchingPhases, la garde de
bascule enfin éprouvée (12 A, phase B à 24 A ; sans elle 15 A, B à 27 A).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans tarif à heures creuses : 79 fonctions, 24 056 lignes identiques
octet pour octet à d62365f. En heures creuses, deux fonctions changent
(testBlockedDischargeShowsAtTheMeterAndL4Decides, 2 cycles ;
testOffPeakFullPowerYieldsToThePhaseLimit, réécrit), plus les deux
nouvelles. check et ETM_DECISIONS_TRACES=1 check : IDENTIQUE
(24 168 lignes ; 22 254 lignes de trace).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- §8 : D8 (2026-10-25) — en heures creuses, le plafond de la borne lui
rend son courant mesuré, moins 1 A par phase ; la tenue au plancher en
surcharge (L4 décide) est confirmée.
- §8.1 : écarts ouverts 3 (double écrêtage hors heures creuses, lot à
part) et 4 (partage achat/surplus à l'aube, avec la dérogation) ;
l'oscillation renvoie à §8.2.
- §8.2 : la règle, la marge, la sécurité en dépassement, les hypothèses,
les mesures avant/après et les preuves.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Près de la limite de phase, la consigne d'une borne à pleine puissance
alternait à chaque cycle : le plafond était la place libre au compteur,
sans lui rendre sa propre consommation. Maison à 2 A par phase, borne
16 A : 16, 7, 16, 7 A sous 25 A ; 16, 14 sous 32 A ; 14, 6, 8, 6 sous 16 A.
En heures creuses, et pour la pleine puissance du lot e2 seulement, le
plafond est lu par EnergyArbitrator::evOffPeakAllowanceW() : limite moins
le tirage de la phase sans la borne, moins 1 A, à l'ampère inférieur. La
règle de l'échéance chez l'amont (adjustEvChargers()). Elle converge en
un cycle : 16 A tenus sous 25 et 32 A, 13 A sous 16 A.
- Courant rendu MESURÉ (currentPower), sur les phases où la borne le
mesure ; rien rendu pendant une bascule ou sans mesure.
- Tirage de la maison sans la borne écrêté à zéro : une borne qui
annonce plus que ce que le compteur voit reste à 1 A sous la limite.
- En dépassement, le plafond vaut au plus le courant mesuré moins 1 A :
il baisse à chaque cycle, jusqu'au plancher, où L4 décide.
- Hors heures creuses et sans tarif : evPhaseAllowanceW(), inchangée.
Tests : testOffPeakFullPowerSettlesUnderThePhaseLimit (sept cas, douze
cycles) et testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter, nouveaux ;
testOffPeakFullPowerYieldsToThePhaseLimit réécrit avec un compteur qui
voit la borne (mesure et non consigne, dépassement, plancher, L4) ;
testBlockedDischargeShowsAtTheMeterAndL4Decides : en dépassement, la
borne finit au plancher (L4 16 → 13 A, stratégie 9 A, L4 6 A) au lieu
d'être coupée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
72 fonctions sans borne en heures creuses : 23 812 lignes identiques octet
pour octet à la référence de b144c09. Changent, en heures creuses : les six
fonctions du lot e1 qui ont une borne (ECO_FLOOR_GRID 1 380 W →
EV_OFF_PEAK_FULL_POWER 3 680 W, et leur compteur d'entrée, qui inclut
désormais ce que la borne tire) ; s'ajoutent les trois fonctions du lot e2.
check et ETM_DECISIONS_TRACES=1 check : IDENTIQUE (24 068 lignes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
§8 gagne D7 (2026-10-24) et §8.1 : la règle (minimum = plafond de cycle),
le choix des phases, la sécurité (LM-1500-h en heures creuses seulement, L4
garde le dernier mot), la fin de session au seuil mesuré, le motif
EV_OFF_PEAK_FULL_POWER. Deux points restent à trancher : le double
écrêtage hors heures creuses, et l'oscillation de la consigne près de la
limite de phase (le plafond ne rend pas à la borne ce qu'elle tire).
Lot futur, non implémenté : ne réserver que ce dont la maison a besoin
jusqu'au soleil, d'après la prévision. §2 renvoie à D7.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décision de Patrick du 2026-10-24. Dans les trois modes qui reportent en
heures creuses (Éco avec minimum, Éco min + échéance, Éco avec échéance) :
- le minimum servi au réseau en heures creuses est le PLAFOND de cycle de
la borne (declared.maxPowerW), plus son plancher. Il porte le courant
maximal, les phases et la limite de phase, et ne descend jamais sous le
plancher : la stratégie rabaisse, L4 coupe. 3 680 W en monophasé 16 A,
11 040 W en triphasé 16 A ;
- les phases se choisissent sur la pleine puissance, plus sur « courant +
surplus » (EnergyArbitrator::enHeuresCreuses(), lu par EvAdapter). La nuit,
une batterie qui couvre la maison et la voiture met le compteur à 0, et la
règle de bascule gardait le monophasé : 3,7 kW au lieu de 11 ;
- la passe éco n'oppose plus à cette borne la marge d'UNE phase de la maison
(LM-1500-h, déjà appliquée en tête de passe et en confort) : son plafond
porte déjà l'autorisation, sur ses phases. Restreint aux heures creuses ;
- motif EV_OFF_PEAK_FULL_POWER {gridW, maxW, phases, until, endsAt,
o:boundBy phaseLimit|floor}, rendu en français, à la place
d'ECO_FLOOR_GRID sur la borne.
Hors heures creuses et sans heure creuse dans le tarif : rien ne change.
Le blocage de la décharge se lève toujours sur la puissance MESURÉE (230 W) :
une borne commandée à 16 A dont la voiture ne prend plus rien le lève.
Tests : testOffPeakChargesAtFullPower, testOffPeakFullPowerSwitchesToThreePhases,
testOffPeakFullPowerYieldsToThePhaseLimit. Les tests du lot e1 en heures
creuses attendent le plafond, et leur compteur inclut ce que la borne tire
désormais (TirageHcW) — sinon il fabriquait un surplus.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décisions de Patrick du 2026-10-24, §8 de DESIGN_HC_BATTERIE.md : toute la
décharge bloquée, maison comprise ; EV_GRID_START refusé hors heures
creuses (seul le mode boost charge tout de suite) ; blocage aussi par une
borne en mode Normal ; seuil de 230 W accepté ; étalement de l'échéance
renvoyé à un lot à part ; action « limite de décharge » et nouveau nom
d'enableDischarging décidés dans le dépôt du plugin. Aucune ne change le
code ; le garde reste compatible avec les deux actions actuelles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les 77 fonctions existantes donnent 23 950 lignes identiques octet pour
octet à la référence de 2cde57c (cmp, lignes de la nouvelle fonction
retirées). La référence s'étend des 96 lignes de
testRefusedWritesAreSpacedAndNeverDelayTheRelease ; check : IDENTIQUE
(24 046 lignes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un onduleur qui refuse la consigne (GEN24 sans « Allow Control », exception
0x04) la voyait reposée à chaque cycle, avec un qCWarning à chaque fois,
toute la nuit, et `held` la publiait comme tenue.
- Une pose refusée (taux ou limite) ouvre une série de refus : la pose
suivante attend 1, 2, 5, 10 puis 15 min au plus (marge de 5 s pour la
gigue du cycle). La série se clôt à la première séquence acceptée
jusqu'au bout (retour au tiers du minuteur) ou à la levée.
- La levée n'est jamais espacée : elle part au cycle même où la décision
tombe, série en cours ou non.
- Journal : un seul qCWarning par série, les refus suivants en qCDebug, un
qCInfo à l'acceptation qui clôt la série.
- Télémétrie : pendant une série, `held` est faux (et `dischargeBlocked`
avec lui), et la batterie publie o:refusedWrites, o:refusedSince,
o:nextAttemptAt. `held` faux plutôt qu'un drapeau à côté : un client qui
ignore le champ nouveau ne doit pas afficher une protection absente.
Mock : propriété dynamique `refuserEcritures` sur la batterie pilotable.
Test testRefusedWritesAreSpacedAndNeverDelayTheRelease ; les six
contre-épreuves (espacement, avertissement, held, levée, deux fins de
série) le font rougir.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans elles, l'enregistrement est identique octet pour octet à la référence de
c5c3203 (23 799 lignes, cmp). Les 151 lignes ajoutées sont celles des six
scénarios d'heures creuses (testOffPeakDemoDay, …EndsAtSixAndOnDstDays,
testWithoutOffPeakTheEngineIsEtm74, testABatteryWithoutControlIsReadAsBefore,
testBlockedDischargeShowsAtTheMeterAndL4Decides,
testAMeterSilenceHandsTheBatteryBack). Deux enregistrements successifs
identiques.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La journée de la démo relit la télémétrie par la frontière RPC pendant le
blocage : le bloc passe la validation du schéma déclaré (o:storage), et le Get
rend ce qui a été publié.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DESIGN_HC_BATTERIE.md : la règle des heures creuses, les modes de borne
concernés et le changement de comportement, la lecture du modèle SunSpec 124
(StorCtl_Mod = bit qui ACTIVE la limite, OutWRte en %, séquence NO_DISCHARGE
du plugin) qui fixe l'ordre des écritures, le minuteur de retour comme sûreté
(et l'hypothèse non levée du plugin sur le 124), l'invariant 8 et les règles de
réserve, ce qui est publié, les preuves, et ce que le lot ne fait pas.
SAFETY.md : le repli L2 lève la limite de décharge explicitement.
INVENTAIRE_MOCK.md : la classe controllableStorage, et ce qu'elle n'émule pas.
DESIGN_PREVISION_PV.md §32.4 : la décision e1 est prise, pointeur.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décisions de Patrick du 2026-10-24. Sans heure creuse dans le tarif saisi
(aucun tarif, tarif unique, prix tous égaux), rien de ceci ne s'exécute.
LA BORNE — modes « Éco avec minimum », « Éco min + échéance », « Éco avec
échéance » (EvAdapter déclare needs.offPeakShift ; le scheduler décide) :
- hors heures creuses : surplus seulement. Le minimum réseau est retiré,
EV_GRID_START aussi (le minimum par une autre porte). Motif
EV_WAITING_OFF_PEAK {at "22:00", startsAt, budgetW}, rendu « … attend les
heures creuses (22:00) ». Le plafond de soutirage et le refus gardent la tête.
- en heures creuses : le plancher de la borne est servi au réseau (passe éco,
bornée par l'autorisation de soutirage). L'échéance reste au proxy, inchangée.
- Eco et Normal ne sont pas touchés.
LA BATTERIE — StorageDischargeGuard exécute, le rule-based décide (y compris en
ombre d'un optimiseur) :
- heure creuse ET bornes qui TIRENT ≥ 230 W (mesuré) ET batterie pilotable :
dischargingRate = 0 PUIS enableDischarging = true (StorCtl_Mod bit DiSCHARGE
= limite active, OutWRte = 0 : la séquence NO_DISCHARGE du plugin) ;
rafraîchi au tiers du minuteur de retour (revertTime) ;
- sinon : levée EXPLICITE, enableDischarging = false puis dischargingRate au
maximum. L2 lève aussi. Une limite à 0 % trouvée active au démarrage est
reprise (rafraîchie ou levée).
- jamais gridCharging, enableCharging, chargingRate, ni un taux négatif.
- générique : interface energystorage et états présents. Sans les états
(noDischargeControl), sans minuteur (noRevertTimer) ou minuteur < 120 s
(revertTimerTooShort) : non commandée, STORAGE_NOT_PROTECTED.
- publié : bloc `storage` de la télémétrie (dischargeBlocked, decision,
batteries[] avec ce qui est LU), absent sans heure creuse ou sans batterie ;
ligne « [Arbitre] Batterie → … » au journal.
Le blocage ne verse rien au budget : surplus = compteur + PV (invariant 8),
le soutirage ajouté se mesure au cycle suivant, L4 garde le dernier mot.
Mock : classe controllableStorage (états modifiables du sunspecStorage,
paramètre revertTime). Tests : journée de la démo, 06:00 sur jours de 24/23/25 h,
etm74 sans heure creuse, batteries non pilotables ou absente, soutirage et L4,
repli L2 — les écritures lues à la frontière nymea (actionExecuted), l'onduleur
modélisé hors du moteur. Le commentaire du test §11 est réécrit comme il le
demandait.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TariffConfig::zonesCreuses() : les zones au prix minimal d'un tarif à zones
horaires dont les prix diffèrent. Aucun tarif, tarif unique ou prix tous
égaux : aucune heure creuse. Le libellé ne décide pas — « HC » n'a pas de
code, le prix se compare.
enHeuresCreuses() et prochaineBascule() lisent l'heure murale minute
absolue par minute, comme importSeries() : bascules exactes les jours de
23 h (nuit de 7 h) et de 25 h (nuit de 9 h, 02:30 deux fois creuse),
épinglées sur des époques calculées hors de Qt (zoneinfo).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deux fonctions, par la connexion de sonde :
- testAnInvalidContextIsRefusedWithItsProblems : un GetPlan de contexte invalide
({"timestamp": "valeur-sonde:7Qz9"}) → -32602 à son id, connexion gardée ; la session de sonde
jugée par le validateur publié contre le contrat EMBARQUÉ (--responses-only) : forme exigée
d'un optimiseur qui s'annonce 1.3 ou plus, AVERTISSEMENT seulement pour un 1.2 ; le contrôle
doit avoir eu lieu (GetPlan.error.data compté) ; garde indépendante : la valeur reçue n'est
pas dans error.data, quelle que soit la version.
- testTheTokenIsCheckedBeforeTheMajor : token faux et autre majeure → -32001 puis fermeture ;
-32602 d'un optimiseur 1.2 averti ; SKIP sans token attendu.
Éprouvé contre l'optimiseur de référence : 1.3 conforme (11 verts + 1 SKIP sans token, 3/3 avec
token) ; old-data annoncé 1.3 refusé, annoncé 1.2 averti ; echo-value refusé en 1.3 comme en 1.2 ;
major-first refusé en 1.3, averti en 1.2 ; référence annoncée 1.2 verte sans avertissement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tools/etm-powersync-schema-check :
- lit methods[].errors[].x-etm-data-schema : error.data d'une réponse error de ce code est jugé
contre ce schéma (audité comme les autres) ; exigé à partir de x-etm-data-required-from, la
version étant celle que l'optimiseur annonce dans SON Handshake ; en deçà, écart écrit en
AVERTISSEMENT, sans effet sur le code de sortie ; version inconnue = celle du contrat ;
- truncated n'accompagne que 50 problèmes exactement ;
- aucune valeur reçue recopiée dans error.data : écart dès 1.2 (règle de 1.2). Le contrôle ne
porte que sur les valeurs qu'un chemin conforme ne peut pas contenir — il ne peut pas accuser
un chemin conforme (domain « battery » / params.battery) ;
- --error (un objet error, avec --request et --handshake) et --responses-only (session de sonde,
requêtes fautives à dessein) ; RÉSUMÉ compte les avertissements.
Tests : forme exigée en 1.3 et avertie en 1.2 sur de vraies sessions de l'optimiseur de
référence (normal, old-data, echo-value × 1.3, 1.2), forme ligne à ligne, recopie sans faux
positif, contre-épreuve « sans x-etm-data-schema, rien n'est jugé ». Les cinq nouveaux tests
échouent avec le validateur précédent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Annonce 1.3. error.data du -32602 d'un contexte invalide dans la forme normée :
{"problems":[{"path":"params.timestamp","problem":"missing"|"type"|"format"}]}, 50 problèmes
au plus et truncated au-delà — plus de chemin « /timestamp » ni de phrase libre.
- Handshake : le token était déjà jugé avant la majeure ; l'ordre est désormais écrit et nommé.
- Pour les contre-épreuves de la conformité : --announce VERSION (se présenter en 1.2) et trois
modes, old-data (forme d'avant 1.3, {"problemes": [phrases]}), echo-value (recopie de la valeur
reçue), major-first (la majeure jugée avant le token).
Suite refoptimizer 8/8 ; test du validateur vert avec l'outil inchangé.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contrat (docs/etm-powersync-optimizer-protocol.openrpc.json) :
- composants InvalidContextData, ContextProblem, ContextProblemCode : error.data du -32602 de
GetPlan = {"problems":[{path, problem}]}, 1 à 50 problèmes, truncated au-delà, chemin depuis
params (motif), nature dans une liste fermée (missing, type, range, format, enum, constraint),
formes fermées : aucune valeur reçue ne peut s'y glisser ;
- x-etm-data-schema et x-etm-data-required-from (1.3) sur cette erreur ;
- Handshake : token faux et autre majeure dans le même handshake → -32001, le token d'abord ;
- tolérance : error.data jamais lu par le moteur.
Prose (docs/OPTIMIZER_PROTOCOL.md) : v1.3, changelog §0 avec la compatibilité 1.2 ↔ 1.3, §2
(un lot reçu par le moteur reste sans réponse, à dessein), §3 (le token d'abord), §7 (forme
d'error.data, et ce que le moteur en fait : rien), annexes A, D, E, G. Blocs générés régénérés.
Générateur : un `|` dans une cellule (alternative d'un motif) est échappé ; une forme de
l'optimiseur fermée à dessein dit pourquoi (x-etm-closed-why) au lieu de « émise par le moteur ».
Test ajouté, vérifié échouant avec l'ancien générateur.
Moteur : version annoncée au handshake 1.3 (OptimizerProtocol::ProtocolVersion,
OptimizerClient::kProtocolVersion). Rien d'autre ne change dans le client. Tests qui citent la
version mis à jour (optimizerclient, socketscheduler, test du validateur).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Une requête GetPlan de plus de 1 Mio n'est pas envoyée (§2) ; la trace n'en garde que la
taille, `requestBytes`, et le rejeu passe la ligne. Passage hors bloc généré.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
appendConfig() ne borne que l'entrée ajoutée, mais validateSet() (THING_SHARED) et
validateRanks() (RANK_DUPLICATE) citaient en entier les libellés des deux entrées en
conflit — dont une héritée, sans borne. provisionEvChargerConfig() journalise cette phrase.
Les libellés y passent par libellePourMotif() : 64 caractères au plus (leftChars, jamais au
milieu d'une paire), suivis de « … ». Le motif publié (faultParams) ne change pas.
Test : testInheritedLabelIsCutInSetRefusals — héritée de 300 caractères ; l'ajout d'une borne
refusé sur THING_SHARED puis sur RANK_DUPLICATE : motif exact inchangé, phrase avec les 64
premiers caractères et sans le libellé entier.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Même défaut que I-1, dans les avertissements de chargement ajoutés par Q7 : l'identifiant hors
règle et l'échéance illisible étaient cités en noquote(). Avant Q7, un client pouvait les
persister avec un saut de ligne (ni l'id ni l'échéance n'étaient bornés), et la lecture du
fichier fabriquait alors une fausse ligne de journal.
Ces valeurs passent par citee() : entre guillemets, échappées par QDebug (même rendu
qu'avant pour une valeur ordinaire). L'avertissement LIBELLÉ TROP LONG, qui cite l'identifiant
dans sa phrase, perd son noquote().
Test : testInheritedValuesAreEscapedInTheJournal charge un fichier dont l'id et l'échéance
valent "x\n[NymeaEnergy] FAUX" : les trois avertissements partent, citent la valeur échappée,
et aucun message n'ajoute de ligne commençant par [NymeaEnergy].
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le refus écrivait, en noquote(), la phrase détaillée du refus : elle cite mode, domaine,
rankOrigin, adaptateur, relays[].thingId, échéance et libellé tels que saisis. Un saut de ligne
dans l'un d'eux fabriquait une fausse ligne de journal (etm72 l'échappait par `<< why`).
Le journal ne porte plus que la phrase rendue depuis le motif (renderFr), comme SetTariff :
cause et endroit, un identifiant seulement s'il est bien formé. Échapper le détail aurait
suffi contre l'injection, pas contre le volume : relays[].thingId n'est pas borné.
La cause système d'un WRITE_FAILED, que seul le détail portait, est désormais écrite par
LoadConfigStore::commit() dans une ligne à part (chemin et erreur du fichier, aucune saisie).
Test : testSetLoadConfigRefusalIsPublished envoie dix refus dont un champ vaut
"x\n[NymeaEnergy] FAUX" et vérifie, message par message (JournalCapture::messages()), que le
refus est journalisé et qu'aucun message n'ajoute de ligne commençant par [NymeaEnergy].
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les 69 fonctions existantes rendent un enregistrement identique, octet pour
octet, à la référence précédente (inchangée depuis fae7101). Les seules
lignes ajoutées sont celles de testSetLoadConfigRefusalIsPublished et de
testAutoProvisionedLabelIsCutNeverRefused. Après régénération : check
IDENTIQUE (71 fonctions, 23 728 cycles), traces activées comprises.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Avec les traces actives, la ligne d'un cycle recopiait la requête GetPlan
même quand le client ne l'avait pas écrite (ligne de plus de 1 Mio,
request-too-long) : environ 1 Mio par cycle jusqu'au plafond journalier,
pour une requête que personne n'a reçue, et que le rejeu aurait renvoyée.
- La ligne porte alors `requestBytes` (taille de la ligne, octets) à la
place de `request` ; sa réponse reste l'erreur request-too-long. Même
règle pour la requête qui SERAIT partie sans optimiseur.
- La décision « part ou ne part pas » est celle du client :
OptimizerClient::getPlanLine(), extraite de requestPlan() sans changer
son comportement, est lue par la trace — pas une seconde estimation.
- Le commentaire « la requête RÉELLEMENT envoyée » est corrigé, la doc de
la ligne de trace (optimizertrace.h) aussi.
Preuve : testARequestNotSentIsTracedBySizeOnly (avec et sans optimiseur ;
contre-épreuve : la requête envoyée est recopiée).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testInheritedOutOfRuleConfigWhatGetPlanSends : une configuration écrite sur
disque avant la règle (identifiant « ballon test », échéances « 07:00 » et
« 7:00 ») est chargée par un store neuf et signalée. Lu sur le faux
optimiseur : l'identifiant hors règle part tel quel ; l'échéance lisible part
avec ses energyTargets (contre-épreuve) ; l'échéance illisible ne part ni
brute ni résolue, minEnergyWhPerDay part encore. La requête est jugée
conforme au contrat embarqué (LoadNeeds.dailyDeadline impose
^[0-9]{2}:[0-9]{2}$, que « 7:00 » violait).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Écart « important » de la relecture d'etm72. provisionEvChargerConfig()
prenait le nom du Thing pour libellé et réécrivait l'ensemble complet : un
nom de plus de 256 caractères, ou un libellé hérité trop long sur une AUTRE
entrée, refusait l'ajout, et la borne restait arbitrée sans rang réglable.
- Le libellé est le nom coupé à 256 points de code (LoadConfigStore::
leftChars), jamais au milieu d'une paire de substitution.
- L'ajout passe par appendConfig() : les bornes de saisie ne portent que
sur l'entrée apportée. L'écriture cliente, elle, reste refusée tant que
l'hérité n'est pas raccourci (règle d'etm72 inchangée).
- Le journal nomme la borne par ce libellé coupé.
Preuve : testAutoProvisionedLabelIsCutNeverRefused (nom de 300 caractères,
emoji en 256e position, hérité de 300 caractères sur une autre entrée).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testSetLoadConfigRefusalIsPublished : l'introspection déclare o:fault et
o:faultParams à côté d'energyError ; un succès rend toujours energyError
seul ; chacune des vingt causes atteignables rend EnergyErrorInvalidParameter,
fault LOAD_CONFIG_REFUSED et les faultParams attendus, sans rien changer à
GetLoadConfig ni au fichier, octet pour octet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le refus garde EnergyErrorInvalidParameter et gagne, comme SetTariff, un
`fault` LOAD_CONFIG_REFUSED et des `faultParams` : une cause par motif
existant (ID, LABEL, DEADLINE, MODE, DOMAIN, RANK_ORIGIN, RANK_ORIGIN_AUTO,
ADAPTER, FIELD_*, SG_READY_STATE_2, ID_DUPLICATE, THING_SHARED,
RANK_DUPLICATE, WRITE_FAILED, STORE_UNAVAILABLE) et l'endroit (index, id
quand il est bien formé, field, state, indexes/ids, rank, length/max,
position). Jamais le libellé. Les deux champs sont déclarés optionnels dans
le schéma ; un succès rend exactement ce qu'il rendait.
- id : 1 à 128 caractères de [A-Za-z0-9._{}-], refusé à l'écriture ;
hérité hors règle, chargé tel quel et signalé.
- needs.dailyDeadline : vide ou HH:MM (00:00-23:59), refusé à l'écriture ;
hérité illisible, l'entrée est chargée, l'échéance retirée de la mémoire
(ni l'arbitre ni l'optimiseur ne la reçoivent) et signalée.
- Les bornes de saisie passent avant la réconciliation de rankOrigin, dont le
motif cite le libellé.
- appendConfig() : l'ajout par le moteur ne borne que l'entrée ajoutée.
- leftChars() coupe en caractères sans couper une paire de substitution ;
l'id d'un motif n'est plus coupé par QString::left().
- Au chargement, chaque libellé trop long est signalé, pas seulement le
premier ; loadconfigstore.h dit « n'écarte rien au chargement ».
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
