ETM-Schurig/etm-powersync-energy-plugin-etm
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(LM-1210-a): le masque de phases est un report daté, pas une position

Browse Source 
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
This commit is contained in:
Patrick Schurig 2026-08-30 13:05:36 +02:00
parent df10320634
commit 6211b75173
2 changed files with 20 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/DESIGN_DELESTAGE.md
View File

@ -169,8 +169,14 @@ dépensée.
> elle est réversible.
>
> La levée demande un champ déclaré (masque de phases par charge) — donc config, interface app
> et migration. Cela dépasse ce lot. **Décision attendue** : vivre avec le pessimisme, ou ouvrir
> le champ.
> et migration. Cela dépasse ce lot.
>
> **Tranché le 2026-08-30 : on vit avec le pessimisme**, et c'est le bon arbitrage pour une
> couche de sécurité — il coûte du rendement, jamais de la sécurité. Mais c'est un **report
> daté**, pas une position : la V2C publie `currentL1/L2/L3` depuis le **2026-08-28**, donc
> l'information existe déjà côté matériel pour une borne, et le **§14a distinguera par phase**.
> 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.
**Étape 4 — la protection L4 déleste le waterfall.** `verifyOverloadProtection()` cesse d'être
réservée aux bornes ; ordre inverse du rang, `force = true`, verrous bypassés comme le repli L2.

12
specs/spec_loadmodel.md
View File

@ -880,6 +880,18 @@ plafond et ne borne personne. Il ne mord que sur une triphasée réellement dés
coûte alors du **rendement, jamais de la sécurité**. Lever la limite demande un masque de phases
déclaré, donc config, interface et migration : hors de ce lot.
> **Report daté, pas position de principe (2026-08-30).** Le masque **finira par s'ouvrir**, et
> l'échéance se rapproche par les deux bouts. Côté matériel, l'information EXISTE déjà pour une
> borne : la V2C publie `currentL1` / `currentL2` / `currentL3` depuis le **2026-08-28**. Côté
> modèle, le **§14a** distinguera par phase — il ne pourra pas se contenter d'un nombre.
>
> Ce qui est décidé ici n'est donc pas « le moteur ignorera toujours les phases », mais « il les
> ignore tant que le champ n'est pas déclaré, et il se comporte alors de la manière la plus
> défensive ». Le jour où le masque arrive, `houseDrawMargin()` cesse de retenir la pire phase
> pour retenir **celle de la charge** — un seul appel change, et le pessimisme disparaît sans
> qu'aucune règle ne bouge. C'est précisément ce que l'étape 2 a préparé en comparant des
> **marges** et non des plafonds.
**LM-1011 — `BELOW_MIN_POWER` prime sur `DRAW_CAP` dès qu'il reste de l'autorisation.**
*(Précédence tranchée par Patrick le 2026-08-29, sur une question de l'agent app. Écrite ICI,
une fois, pour qu'aucun côté de la frontière ne l'établisse pour son compte.)*