etm-powersync-energy-plugin-etm/docs/DESIGN_10.md

# DESIGN — §10 : éco / confort, et le délestage dans le même lot

**Statut : conception, à valider avant tout code** (`AGENTS.md`, workflow obligatoire).
**Entrée** : `specs/spec_loadmodel.md` §10 (LM-1000 → LM-1009) et §12.
**Écrit après relecture de** `rulebasedscheduler.cpp` (`getPlan`, `buildSetpointAction`,
`buildSgReadyStateAction`), `smartchargingmanager.cpp` (`verifyOverloadProtection`), et des deux
notes qui contraignent la forme : **LM-1006-1** (le plafond de soutirage) et **LM-1009** (les
deux régimes d'échéance).

> **Ce document ne demande pas si le §10 doit se faire. Il dit sous quelle forme, et nomme les
> points qui demandent une décision** — §8. **Quatre sont tranchés.** 2026-08-27 : la réserve
> batterie n'annule pas l'autorisation de soutirage (8.1), et le repli dégradé ne concerne pas ce
> lot (8.3). 2026-08-29 : le plafond §14a porte **les deux** formes — par phase et au total —
> sans jamais convertir (8.2), et la cible de confort reste un **comparateur**, le dosage
> attendant le modèle thermique du §11 (8.4).
>
> **Un seul reste ouvert, et il est chez l'app** : 8.5, l'ordre de service apparent. Question
> posée le 2026-08-29 dans `docs/BRIEF_depuis_plugin.md` §9.

---

## 0. ⚠️ CE QUI A CHANGÉ DEPUIS L'ÉCRITURE DE CE DESIGN (2026-08-30)

Ce document a été écrit **avant** le lot délestage. Trois de ses sections décrivent désormais du
code livré, et une propose une forme qui a depuis été **refusée**. Lire les sections suivantes
sans cette mise à jour ferait reconstruire l'existant, ou pire, ressusciter un champ qu'un test
interdit.

| Section | État |
|---|---|
| **§2 — le plafond de soutirage devient un OBJET** | **LIVRÉ.** `DrawCap` / `DrawMargin` / `resolveDrawMargin()`, avec les trois sources et le départage par rang de contrainte. Voir `DESIGN_DELESTAGE.md`. |
| **§5 — le délestage, ce qu'il coupe et dans quel ordre** | **LIVRÉ** (`LM-1211`) : ordre inverse du rang, franchissement de verrou **constaté** et non présumé, réservé aux plafonds subis. |
| **§6 — les motifs** | `DRAW_CAP` **existe**, avec sa source, son ampleur et sa phase. `ECO_FLOOR_MET` / `ECO_FLOOR_GRID` restent à naître. |
| **§3 — la forme de `PlanDraw`** | **PARTIELLEMENT REFUSÉE**, voir ci-dessous. |

### La correction à faire sur §3 : `PlanDraw` n'a qu'un champ

Le §3 propose `PlanDraw { authorisedW, committedW, remainingW }`. Seul **`committedW`** a été
livré, et l'absence des deux autres a été **défendue en prose à trois endroits** puis **épinglée
par un test** (`testLoadTelemetryRpc` casse si on ajoute le champ). Le motif d'alors : *« un
`authorisedW` forgé afficherait un plafond de soutirage qui n'existe pas »*.

> **Mais ce motif est tombé.** Le plafond existe désormais — `ctx.drawMargin`, résolu une fois
> par cycle, avec sa source et sa phase. `authorisedW` ne serait plus une forge : il serait une
> lecture. **C'est donc une décision à reprendre, pas une règle à appliquer** (voir §11.2), et
> c'est un bon exemple de ce qu'`AGENTS.md` appelle une décision qui se périme : elle était
> juste, son motif a disparu, et seule sa formulation a survécu.

---

## 1. Pourquoi le délestage part AVEC, et pas après

C'est la précondition écrite en §13 de la spec, et elle tient pour une raison arithmétique
simple : **la passe éco n'est pas bornée par le surplus** (LM-1005). Elle est bornée par une
autorisation de soutirage. Or aujourd'hui, la seule borne de soutirage qui existe dans le moteur
— `phasePowerLimit` — ne déleste **que les bornes de recharge**
(`verifyOverloadProtection`, boucle sur `m_evChargers`).

Livrer les planchers éco sans le délestage général donnerait donc : un matin sans soleil, chaque
charge se sert au réseau pour tenir son obligation, personne ne les additionne, et
l'installation disjoncte. Ce n'est pas une dégradation de confort — c'est une coupure, chez un
client.

**Conséquence de conception, pas de calendrier** : la passe éco a besoin d'un objet « plafond »
qui n'existe pas encore. Le §10 doit donc le créer. C'est le §2.

---

## 2. Le plafond de soutirage devient un OBJET (LM-1006-1)

### 2.1 Ce qu'il remplace

Aujourd'hui, la limite de raccordement est consultée à deux endroits, sous deux formes, sans
jamais être nommée :

- `RootMeter::calculateAllowanceAmpere(phases, phasePowerLimit)` — la place libre **par phase**,
  interrogée par le proxy puis, depuis 3g-2, par `EnergyArbitrator::evPhaseAllowanceW()` ;
- `verifyOverloadProtection()` — la réaction temps réel, qui déleste les bornes.

Aucun des deux ne se demande *d'où vient* le plafond, parce qu'il n'y en a qu'un. Le §14a en
ajoutera un second, le §10 lui-même un troisième.

### 2.2 La forme proposée

```cpp
/*! Un plafond de soutirage, et ce qui l'a produit. */
struct DrawCap {
    enum Source { Connection, GridOperator, EcoSelfImposed };

    Source  source      = Connection;
    double  totalW      = -1;   //!< Plafond au POINT DE LIVRAISON. < 0 = pas de plafond total.
    QList<double> perPhaseA;    //!< Plafond PAR PHASE. Vide = pas de plafond par phase.
    QDateTime until;            //!< Fin de validité ; invalide = permanent.
};

/*! Le plafond EFFECTIF du cycle, et celui qui a mordu. */
struct DrawBudget {
    QList<DrawCap> declared;    //!< Tous les plafonds actifs, quelle que soit leur source.
    double  effectiveW   = -1;  //!< Le plus contraignant, ramené en watts.
    DrawCap::Source binding = DrawCap::Connection;  //!< QUI a mordu — publié, pas déduit.
    bool    perPhaseBound = false;  //!< Vrai si c'est une phase qui borne, pas le total.
};
```

**`binding` est le champ qui justifie tout l'objet.** Sans lui, un client bridé lit « protection
de surcharge » là où la cause est le gestionnaire de réseau — deux causes, deux gestes
(LM-1006-1, propriété 1).

### 2.3 Le piège : par phase, ou au total ?

Les trois sources ne parlent pas la même langue, et c'est le seul vrai problème technique du §2.

| Source | Forme naturelle | Peut-on la convertir ? |
|---|---|---|
| Disjoncteur de branchement | **par phase** (A) | pas en un total : 3 × 32 A ne vaut pas 22 kW répartissables |
| §14a EnWG | **total** (W au point de livraison) | pas en par-phase : le gestionnaire ne dit rien de la répartition |
| Plancher éco (§10) | **total** (W qu'on s'autorise) | idem |

**Un plafond total ne protège pas d'une surcharge monophasée** : 4 kW tirés entièrement sur L1
passent un plafond total de 6 kW et font disjoncter un 16 A. **Et un plafond par phase ne sait
pas exprimer le §14a.**

**Décision de conception proposée** : `DrawBudget` porte **les deux**, les évalue **toutes les
deux**, et `binding` dit laquelle a mordu la première. Aucune conversion, jamais — c'est la
conversion qui perdrait l'information. `effectiveW` n'est qu'une commodité d'affichage, dérivée,
et `perPhaseBound` dit s'il faut la lire avec précaution.

### 2.4 Où il se calcule

Une fois par cycle, dans `buildContext()`, à côté de `ctx.meter` et `ctx.battery` — c'est déjà
l'endroit qui lit le compteur et connaît `phasePowerLimit`. Il devient un champ de
`SurplusContext` :

```cpp
struct SurplusContext {
    // … existant …
    DrawBudget drawCap;   //!< [§10] Plafond de soutirage du cycle, toutes sources confondues.
};
```

Publié en télémétrie au même titre que `budget` — c'est la contrepartie de `binding` : un client
qui ne voit pas le plafond ne peut pas expliquer ce qu'il affiche.

---

## 3. Les deux passes, et ce qui borne chacune

`LM-1002` fixe la structure : deux passes sur la **même** liste, triée une seule fois par rang.
Ce qui change entre elles n'est pas l'ordre, c'est **la borne**.

```
                    ┌────────────── passe 1 : ÉCO ──────────────┐
liste triée par     │ borne : DrawBudget (autorisation de       │
rang (une seule)    │         SOUTIRAGE — pas le surplus)       │
   rang 1 ─────────▶│ sert : le plancher `needs` non atteint    │
   rang 2 ─────────▶│ produit : une CIBLE, pas une commande     │
   rang 3 ─────────▶└───────────────────────────────────────────┘
        │
        │           ┌──────────── passe 2 : CONFORT ────────────┐
        └──────────▶│ borne : le RELIQUAT de surplus            │
   (même ordre)     │ sert : la cible de confort si demandeuse  │
                    │ produit : une CIBLE, pas une commande     │
                    └───────────────────────────────────────────┘
                                        │
                            somme par charge, arrondie UNE fois
                                        │
                                   UNE commande
```

**Ce que la passe 1 dépense n'est pas ce que la passe 2 dépense.** C'est le point que le code
actuel ne sait pas exprimer : `getPlan()` n'a qu'un compteur, `remainingSurplusW`, et
`buildSetpointAction()` le décrémente **et** émet l'action dans le même geste
(`rulebasedscheduler.cpp:207-212`). Le §10 doit séparer les deux — voir §4.

**Deux comptabilités, donc, et elles ne se mélangent pas** :

```cpp
struct PlanBudget {          // existant, inchangé dans sa sémantique
    double surplusW, evReservedW, allocatedW, recreditedW, remainingW;
};
struct PlanDraw {            // [§10] ce que la passe 1 a décidé d'ACHETER
    double authorisedW = 0;  //!< Ce que le DrawBudget laissait prendre.
    double committedW  = 0;  //!< Ce que la passe 1 a réellement engagé au réseau.
    double remainingW  = 0;  //!< Reliquat d'autorisation, non dépensé.
};
```

> **Pourquoi deux structures et pas un champ de plus** : `PlanBudget` répond « d'où vient
> l'énergie servie » ; `PlanDraw` répond « combien a-t-on décidé d'acheter ». Les fondre
> rendrait l'invariant publié de `PlanBudget` (`surplus + recrédit − alloué == restant`) faux
> ou incompréhensible, et c'est lui qui rend la charge utile vérifiable par un client.

---

## 4. Une seule commande par charge et par cycle (LM-1003)

C'est la contrainte qui impose la refonte structurelle, et elle est petite à énoncer :
**les passes calculent, elles ne commandent pas.**

Découpage proposé de `getPlan()` :

```cpp
// 1. contexte, budget de surplus, plafond de soutirage  (inchangé + DrawBudget)
// 2. tri UNE fois                                        (inchangé)
QHash<QString, LoadTarget> cibles;   // loadId → { ecoW, confortW, motifs… }

// 3. passe 1 — éco, bornée par ctx.drawCap
for (const LoadContext &lc : chargesTriees)
    cibles[lc.id].eco = planifierEco(lc, drawRestant, planDraw);

// 4. passe 2 — confort, bornée par le reliquat de surplus
for (const LoadContext &lc : chargesTriees)
    cibles[lc.id].confort = planifierConfort(lc, surplusRestant, planBudget);

// 5. UNE émission par charge : somme, arrondi au mécanisme, motif
for (const LoadContext &lc : chargesTriees)
    slot.actions.append(emettre(lc, cibles.value(lc.id)));
```

**L'arrondi au mécanisme se fait à l'étape 5, une seule fois.** C'est ce qui empêche le défaut
que LM-1003 nomme : un relais commuté en passe 1 puis recommuté en passe 2, soit du
court-cycling fabriqué par l'arbitre lui-même.

**Le recrédit s'attribue à la première passe où la charge apparaît** (LM-1004) — donc dans
`planifierEco()` si elle a un plancher, dans `planifierConfort()` sinon. Un champ
`recreditAttribue` dans `LoadTarget` le rend vérifiable plutôt que discipliné.

> **Ce que cette refonte casse, et qu'il faut prévoir** : `buildSetpointAction()` et
> `buildSgReadyStateAction()` mélangent aujourd'hui décision, écrêtage de verrou, comptabilité
> et motif. Ils doivent se scinder en « décider une cible » et « émettre ». C'est le gros du
> travail du lot, et c'est du remaniement, pas de l'ajout. Les tests de motif existants
> (`testDecisionReasonRendering`, `testEcsBudgetUnderLock`, `testEcsSurplusPV`) sont le filet :
> ils portent sur le TEXTE publié, donc ils survivront au remaniement ou le condamneront.

---

## 5. Le délestage : ce qu'il coupe, et dans quel ordre

**Le plafond borne le PLAN, il ne le corrige pas après coup.** C'est la leçon de 3g-2 : un
plafond appliqué après l'allocation laisse le waterfall croire qu'il a servi.

- **En passe 1**, chaque charge servie décrémente `planDraw.remainingW`. Quand l'autorisation est
  épuisée, les charges suivantes reçoivent 0 **et le motif nomme la source** (§6).
- **L'ordre de délestage est l'inverse de l'ordre de service** : le rang décide qui est servi en
  premier, donc qui est coupé en dernier. Aucun second classement — c'est LM-1002 appliqué à
  l'envers, et c'est la seule lecture qui ne surprendra pas l'installateur.
- **L4 ne bouge pas.** `verifyOverloadProtection()` garde le dernier mot en temps réel, sur la
  mesure, après le dispatch. Le §10 lui ajoute des charges à délester ; il ne lui retire pas son
  rôle et ne s'y substitue pas. **Sa position dans `update()` reste INTOUCHABLE** (AGENTS,
  modèle de sécurité).

---

## 6. Les motifs — ce que le §10 ajoute au catalogue

Le catalogue est fermé et testé sur le texte ; toute clé ajoutée demande une ligne de rendu et
une entrée de clôture (`testDecisionReasonRendering`).

| Code | params | Quand |
|---|---|---|
| `DRAW_CAP` | `capW`, `source`, `requiredW`, `o:phase` | Le plafond de soutirage refuse, et **`source` dit lequel** : raccordement, gestionnaire de réseau, ou auto-imposé. `phase` présent si c'est une phase qui borne. **Réservé à l'autorisation résiduelle NULLE** — voir la précédence ci-dessous. |

**PRÉCÉDENCE `DRAW_CAP` ↔ `BELOW_MIN_POWER`** — tranchée le 2026-08-29, et son domicile est
`specs/spec_loadmodel.md` **LM-1011**, pas ici : une note de conception se périme, la spec fait
autorité. En un mot : autorisation résiduelle **non nulle mais sous le plus petit palier** →
`BELOW_MIN_POWER` ; `DRAW_CAP` réservé au résiduel **nul**. Le point de rupture de l'écran 2 est
ancré sur le `DRAW_CAP`.

**RÉPONSE À R4 — ce que les compteurs de budget comptent : le DÉCIDÉ.** *(Question de l'agent
app, 2026-08-29.)*

`budget.allocatedW` et ses voisins comptent **ce que la cascade a décidé**, jamais ce que le
matériel a reçu. Ce n'est pas un choix de commodité : 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,
lui, vit **après** — dans l'adaptateur, au dispatch, et il est propre à chaque mécanisme. Compter
le commandé obligerait à **rouvrir le budget après le dispatch**, c'est-à-dire à décider deux
fois.

> ⚠️ **Et cela corrige une prémisse de R4, qu'il vaut mieux corriger maintenant.** La maquette
> écrit « `allocatedW` publie ce qui a été **commandé** ». **C'est faux aujourd'hui** :
> `buildTelemetry()` publie `action.estimatedPowerW` du 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**, par construction — les deux sont du
> décidé. L'écart que l'écran veut nommer (« 1 400 W décidés → palier 1 500 W ») n'est **pas**
> entre `targetW` et `allocatedW` : il est entre `allocatedW` (**décidé**) et la charge utile de
> mécanisme (**appliqué**) — `mechanism.stageW`, `mechanism.setpointW`, `mechanism.currentA` —
> **qui est déjà publiée aujourd'hui**. L'écran a déjà les deux nombres ; ce sont leurs noms qui
> étaient inversés.
| `ECO_FLOOR_GRID` | `deliveredWh`, `targetWh`, `gridW` | Une obligation éco servie **au réseau**. `gridW` chiffre l'achat, comme `EV_GRID_START` le fait déjà. |
| `ECO_FLOOR_MET` | `deliveredWh`, `targetWh` | L'obligation est **atteinte** — et elle ne peut se dire atteinte que sur le régime ÉNERGIE (LM-1009). |
| `COMFORT_SKIPPED` | `o:sensorValue`, `o:setpoint` | La charge n'est plus demandeuse de son bonus (comparateur de LM-1008). Distinct de « pas de budget ». |

**Et un champ, pas un code** : le **régime** de l'avancement (mesuré / estimé / non mesurable),
publié sur chaque charge portant une obligation. C'est la condition C2 de LM-1009, et elle ne
peut pas vivre dans un code : les trois régimes coexistent dans le même cycle, sur des charges
différentes.

---

## 7. Ce que LM-1009 impose à l'obligation éco

Trois décisions déjà prises, rappelées ici parce qu'elles ferment des choix de conception :

- **D1** — l'avancement se mesure et s'affiche en **énergie livrée**. La passe 1 compare donc des
  Wh à des Wh, jamais un pourcentage.
- **D2** — **obligation par SESSION** d'abord. Pour une borne, la session est le branchement, et
  la source est `sessionEnergy`. Pour une charge thermique, la « session » est le cycle
  quotidien — et c'est là que l'analogie s'arrête : `minEnergyWhPerDay` **reste hors de ce lot**,
  faute d'accumulation inter-sessions (§11).
- **C1** — une charge dont l'énergie livrée **n'est pas mesurable** dégrade **visiblement**. Le
  cas est réel dès demain : la V2C Trydan ne publie pas `sessionEnergy`
  (`docs/PREPA_BANC_20260828.md` §2.2). Le §10 doit donc prévoir ce régime **dès l'écriture**,
  pas comme un cas dégradé ajouté après.

> **Conséquence directe** : une obligation éco sur une charge non mesurable est **déclarative,
> pas vérifiable**. Elle peut être servie ; elle ne peut jamais être annoncée **tenue**. C'est
> la même frontière que LM-1009 trace pour l'échéance VE.

---

## 8. LES POINTS À TRANCHER — deux le sont déjà

**8.1 — La réserve batterie annule-t-elle aussi la passe ÉCO ?** *(le plus important)*

LM-1203-b dit : sous la réserve, le budget est **annulé**. Mais ce budget est un budget de
**surplus**, et la passe 1 ne dépense pas de surplus — elle dépense une autorisation de
soutirage.

- **Si la réserve annule aussi la passe 1** : une installation dont la batterie est basse
  n'atteindra **jamais** son plancher éco. Un ballon qui n'a pas vu 50 °C ne les verra pas, parce
  que la batterie de la maison est à 15 %.
- **Si elle ne l'annule pas** : la maison achète au réseau pour un chauffe-eau pendant que sa
  batterie est basse — ce qui peut être exactement ce qu'on veut (l'obligation prime) ou une
  absurdité (on achète pendant qu'on manque).

**TRANCHÉ (Patrick, 2026-08-27) : la réserve N'annule PAS la passe 1.** La réserve protège le
**surplus** ; une obligation d'énergie sur échéance est d'une autre nature, et si elle cède à la
réserve, elle 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.
Inscrit en LM-1203-b.

**8.2 — Le plafond §14a est-il par phase, au total, ou les deux ?** Le §2.3 propose de porter les
deux sans jamais convertir. Reste à confirmer que c'est bien ainsi que le gestionnaire de réseau
l'exprimera — et le transport du §14a n'existe pas encore, donc la réponse peut attendre à
condition que la **forme** ne se ferme pas maintenant.

**8.3 — Le repli L2 doit-il TENIR le plafond ? TRANCHÉ, et la réponse retire le point du lot.**
*(Patrick, 2026-08-27.)* Les deux cas ne se confondent pas : 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**, dont le transport n'existe pas, et elle vivra **hors du moteur**.
Les confondre ferait hériter au §10 d'une exigence qui ne le concerne pas encore. LM-1006-1 est
mis à jour en conséquence : **le §10 n'a rien à faire de ce côté.**

**8.4 — La cible de confort : comparateur seul, ou dosage ?** LM-1008 tranche déjà : comparateur
(`sonde < consigne` → demandeuse), le dosage attend le modèle thermique du §11. **À confirmer
que ça reste vrai pour ce lot**, parce que c'est ce qui le rend faisable sans historique.

**8.5 — Que fait l'app des deux passes ? POSÉE À L'AGENT APP le 2026-08-29**, et c'est le
dernier point ouvert du lot. LM-1006, couplage 2 : un plancher éco de rang 4 passe devant un
confort de rang 1 — voulu, et **contre-intuitif** pour l'installateur qui vient de poser son
ordre. Sans écran qui montre les deux passes, le premier retour terrain sera « l'ordre n'est pas
respecté ». Ce n'est pas du travail moteur, mais c'est une **condition de livraison**.

La question est formulée en `docs/BRIEF_depuis_plugin.md` §9, avec les trois choses à trancher —
sur quoi la liste est ordonnée, une entrée ou deux par charge, et ce qu'on voit d'une charge dont
l'éco est servi et le confort non. **Le moteur ne répond pas à sa place** : 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. La charge utile suivra.

> ⚠️ **Tant qu'elle n'est pas tranchée, le §10 ne se code pas.** Ce n'est pas une dépendance
> molle : la troisième question — une charge dont l'éco est servi et le confort non — n'a
> **aucun équivalent** dans la télémétrie d'aujourd'hui, qui publie un motif et une allocation,
> un seul de chaque. 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é.

---

## 9. Ce qui n'est PAS dans ce lot

- **`minEnergyWhPerDay`** — obligation quotidienne, exige l'accumulation inter-sessions (§11).
  Le lot livre l'obligation **par session**.
- **Le transport du §14a** — aucun canal n'existe. Le lot livre la **forme** du plafond, pas sa
  source externe.
- **Le prix, l'heure, le signal tarifaire** (LM-1005) — le rule-based franchit la frontière de
  l'achat **grossièrement** : « plancher non atteint à 22 h → chauffer ». Une règle d'horloge.
  L'optimisation appartient au MILP, donc à l'optimiseur socket, donc à 3d.
- **Le dosage en Wh du confort** — voir 8.4.
- **La conversion degrés → Wh** — couche domaine, jamais l'arbitre (LM-1008).

---

## 10. ORDRE DE TRAVAIL — trois étapes à comportement CONSTANT, puis une seule qui change

*(Réécrit le 2026-08-30, après le lot délestage. La question de forme du §9 est tranchée : la
maquette `deux_passes_eco_confort_mockup.html` **fait contrat**, et `levels[]`, `funding` et
`counts` sont déjà livrés.)*

La stratégie du délestage a marché et se réemploie telle quelle : **ce qui coûte dans un lot de
ce genre n'est pas d'écrire le comportement, c'est de prouver qu'on n'a rien cassé en chemin.**
Trois étapes ne changent rien et rendent la quatrième petite.

### Étape A — le SPLIT décider / émettre, à comportement constant

C'est le gros du travail, et il n'ajoute aucune fonction. `getPlan()` se scinde en deux temps :
une phase qui calcule une **cible par charge**, une phase qui **émet une commande et une seule**.
Aujourd'hui `buildSetpointAction()` décide, écrête, comptabilise et motive dans le même geste, et
décrémente le budget en même temps qu'il émet — ce qui rend une seconde passe littéralement
inexprimable.

Tant qu'il n'y a qu'une passe, la cible confort est la seule, et la sortie doit être **identique
au watt près**. C'est ce qui rend l'étape vérifiable : `simulation` et `charging` ne doivent pas
bouger d'une ligne. Le filet est déjà là — les tests de motif portent sur le **texte publié**,
donc ils survivront au remaniement ou le condamneront.

> **Le piège à surveiller.** L'arrondi au mécanisme et l'écrêtage de verrou doivent migrer vers
> la phase d'émission **sans changer d'ordre relatif**. `ECS-306` (clamp lock-aware AVANT de
> décrémenter le budget) et `ECS-309` (le motif nomme le mécanisme réel, via `vouluW`) reposent
> tous deux sur cet ordre. Les déplacer d'un cran ferait publier des motifs faux sans qu'aucun
> nombre ne change — le genre de régression qu'une somme correcte masque.

### Étape B — `draw` complété, publication SEULE

`draw` ne publie que `committedW`. Le plafond existe maintenant : `binding` (la source qui
borne), `perPhaseBound`, `authorisedW` et `remainingW` deviennent des **lectures** et non des
forges. Aucune décision ne change ; c'est un ajout de charge utile, et il ferme la moitié de R8
qui restait ouverte au niveau du cycle.

Voir la décision **§11.2** — l'ajout suppose de revenir sur un refus dont le motif est tombé, et
de mettre à jour le test qui l'épingle.

### Étape C — l'AVANCEMENT mesuré, publié sans rien décider

`LoadContextTelemetry::sessionWh` est **déclaré et rempli nulle part** ; `EvCharger` n'expose
même pas d'accesseur vers `sessionEnergy`, que quatre des cinq classes du banc publient.
`minEnergyWhPerDay` est transporté par la config et le RPC, et **lu par aucune décision**. Les
deux moitiés de l'obligation éco sont donc de la plomberie inerte.

Cette étape les branche **en lecture seule** : `sessionWh` alimenté, `progress` publié dans
`levels[]` avec son `regime` ∈ `measured | estimated | unmeasurable`, `deliveredWh` **absent**
quand le régime est `unmeasurable` — jamais à zéro, sans quoi une dégradation se lirait comme un
avancement nul, ce que `LM-1009 C1` interdit nommément.

> **⚠️ `sessionEnergy` porte un OFFSET — mesuré le 2026-08-31.** Sur la V2C, l'écart entre
> `sessionEnergy` et `chargeEnergy` est constant au dix-millième (7,2044), parce que
> l'accumulateur du plugin porte les incréments d'avant la dernière remise à zéro. **La valeur
> absolue n'est donc pas l'énergie de la session courante.** `deliveredWh` doit être une
> **différence depuis une base capturée**, jamais une lecture directe — sans quoi toute
> obligation éco se croirait tenue de 7,2 kWh dès le premier cycle. Un nombre crédible et faux,
> que rien ne signalerait. Détail et mesures : `RELEVE_APP_20260831.md`.
>
> Corollaire : **la V2C n'est plus un cas `unmeasurable`.** `LM-1009 C1` reste vraie pour les
> bornes sans l'état, mais le porteur d'exemple change — R6 devra citer une autre classe.

> **C'est ici que R5 devient vraie, et R6 devient TESTABLE avant d'être nécessaire.** Le régime
> se publie sans qu'aucune décision ne s'y appuie : l'app peut afficher « non mesurable » sur la
> V2C dès cette étape, et la garde de R6 — `ECO_FLOOR_MET` interdit sous `unmeasurable` — aura
> son régime à interroger le jour où le motif naît. On sépare **publier le régime** de **décider
> avec**, exactement comme `measurement` l'a été de l'arbitrage.

### Étape D — la PASSE ÉCO naît, et c'est la seule étape qui change le comportement

Deux passes sur la même liste triée, `ECO_FLOOR_MET` et `ECO_FLOOR_GRID` au catalogue, R6 armée.
La passe 1 est bornée par l'**autorisation de soutirage**, la passe 2 par le **reliquat de
surplus**. Le délestage la rattrape si tous les planchers se servent au réseau le même matin —
c'est la précondition qui vient d'être levée.

---

## 11. CE QUI DEMANDE UNE DÉCISION AVANT L'ÉTAPE D

**11.1 — Comment une obligation en ÉNERGIE devient-elle une cible en WATTS pour ce cycle ?**
C'est la question centrale, et le design ne l'a jamais tranchée. `needs` porte
`minEnergyWhPerDay`, une `deadline` et un `targetSocPercent` — jamais un plancher en watts. La
passe éco doit donc convertir « il reste 900 Wh à livrer avant 7 h » en « prends 1400 W
maintenant ».

Trois formes possibles, et elles ne se valent pas :

| Forme | Ce qu'elle donne | Ce qu'elle coûte |
|---|---|---|
| **Tout ou rien** | la charge prend son plancher dès que l'obligation n'est pas tenue | achète au pire moment, et fait disjoncter à plusieurs |
| **Étalement uniforme** | `reste / temps restant` | simple, vérifiable, mais ignore le tarif et le soleil à venir |
| **Au plus tard** | ne rien acheter tant que le surplus peut encore suffire | optimal, mais suppose une **prévision** — hors modèle |

**Recommandation : l'étalement uniforme**, pour la même raison que `LM-1008` a fait de la cible
de confort un **comparateur** plutôt qu'un dosage : ce qui manque n'est pas la formule, c'est le
modèle qui la rendrait honnête. Un étalement se lit, se teste, et ne prétend rien prévoir. Le
« au plus tard » viendra avec la prévision, pas avant.

**11.2 — Publie-t-on `draw.authorisedW` et `remainingW` maintenant ?**
Le refus tenait à ce qu'ils n'existaient pas. Ils existent. Mais `remainingW` a une subtilité :
sous la réserve batterie, `LM-1203-b` annule le budget de surplus **sans annuler l'autorisation
de soutirage** — donc `draw.remainingW` reste non nul quand `budget.remainingW` est à zéro, et
c'est **juste**. Il faut le dire, sinon un client conclura à une incohérence.
**Recommandation : oui aux quatre**, et le test qui les interdit se met à jour en même temps —
c'est un changement de contrat assumé, pas une régression.

**11.3 — La passe éco achète-t-elle au réseau par DÉFAUT ?**
`ECO_FLOOR_GRID` dit « ce plancher est servi en achetant ». Mais faut-il acheter dès que le
surplus manque, ou seulement quand l'échéance est menacée ? Avec l'étalement uniforme la question
se dissout : on achète ce que l'étalement réclame **et rien de plus**, donc jamais « par défaut »
— toujours parce que le temps restant l'exige. **Recommandation : pas de décision séparée**, elle
est absorbée par 11.1.

**11.4 — Que devient le recrédit anti-clignotement avec deux passes ?**
`LM-1004` fixe qu'il est attribué **une seule fois**. Reste à dire **où** : à la première passe
où la charge apparaît. Une charge à plancher éco le reçoit donc en passe 1, une charge sans
obligation en passe 2. **Recommandation : un champ explicite dans la cible** (`recreditAttribue`)
plutôt qu'une discipline — la discipline ne se teste pas, le champ si.

---