docs(R3): draw.committedW en préalable — et evReservedW n'est PAS un registre

Le moteur l'a trouvé en câblant `counts` : `budget.evReservedW` est un terme de CORRECTION du budget, pas un registre d'allocation. Il mêle la correction « commandé non encore mesuré » à la part réseau d'`EV_GRID_START`, et une borne servie au réseau qui tire déjà ce qu'on lui a commandé y contribue 0 pour un `targetW` de 7 000 W. `Σ counts == targetW` y serait vraie au premier cycle après un changement et fausse ensuite : une identité dépendante du temps, qui passe tous les tests et certifie un total faux. Ne pas livrer était le bon appel. Réponse : `draw.committedW` en préalable, oui, sans réserve — et trois demandes : par cycle, en watts, dans la même trame que `budget` ; publié SEUL, les quatre autres champs de `draw` absents et jamais à 0 (un `authorisedW` forgé afficherait un plafond de soutirage qui n'existe pas) ; et une définition d'`evReservedW`, que nous affichons sous « Réservé au véhicule » — un libellé qui affirme une réservation là où il y a une correction, et que nous ne renommerons pas au jugé. Nous portions la fausse affirmation en cinq endroits (`CLAUDE.md` ×2, le modèle ×3, la description ARB) : retirée ici, sans changement de comportement. Elle ne relève pas de la discipline « attendre la sonde » — celle-ci arbitre ce que fait la box, pas ce que nous en avions cru, et la phrase est fausse aujourd'hui. Il n'existe donc qu'UNE identité vérifiable, et elle ne couvre qu'un côté : Σ targetW(surplus) == budget.allocatedW. Côté réseau, rien — pas « à vérifier plus tard », rien, jusqu'à `draw.committedW`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
2026-08-30 08:35:17 +02:00 · 2026-08-30 08:35:17 +02:00 · b01a716047
commit b01a716047
parent 1d0112a6e4
5 changed files with 106 additions and 11 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@ -264,8 +264,16 @@ surplus, même cycle — et c'est pourquoi le champ a dû descendre d'un cran **

 L'identité vérifiable devient : *somme des `targetW` des niveaux financés au surplus ==
 `budget.allocatedW`*. Vérifiée à la sonde sur `.75` le 2026-08-30 (`+etm30`) :
-3 500 + 3 000 == 6 500, puis 1 500 == 1 500 au cycle suivant. Une charge financée au réseau
-vit dans `budget.evReservedW`. Omis en mode dégradé — sans plan, pas de financement.
+3 500 + 3 000 == 6 500, puis 1 500 == 1 500 au cycle suivant. Omis en mode dégradé — sans
+plan, pas de financement.
+
+> 🔴 **Et il n'y a d'identité que de ce côté-là.** Une charge financée au réseau ne vit
+> **nulle part** : `budget.evReservedW` n'est pas un registre d'allocation mais un **terme de
+> correction** du budget, qui mêle la correction « commandé non encore mesuré » à la part
+> réseau d'`EV_GRID_START` — une borne servie au réseau qui tire déjà ce qu'on lui a commandé
+> y contribue **0** alors que son `targetW` vaut 7 000 W. Constaté par le moteur le
+> 2026-08-30 en câblant R3. Les watts achetés n'auront de registre qu'avec
+> `draw.committedW`, préalable à R3. **Ne réconcilier aucun total sur `evReservedW`.**

 Le niveau publié est `"comfort"` et ce **n'est pas un rebaptisage** : c'est bien la passe
 qui, au §10, servira le confort depuis le surplus. Un niveau à `targetW: 0` est une passe
@ -339,7 +347,8 @@ Et **deux pièges de lecture**, tous deux au contrat :

 **3. `EV_GRID_START` partage une allocation entre les DEUX compteurs du budget.** C'est le
 seul motif qui le fasse : `budgetW` vient du surplus et entre dans `budget.allocatedW`,
-`gridW` est acheté au réseau et entre dans `budget.evReservedW`, avec
+`gridW` est acheté au réseau — et **n'entre dans aucun registre** (cf. §1 : `evReservedW`
+est une correction, pas une destination), avec
 `budgetW + gridW == allocatedW`. Toute réconciliation doit traiter cette ligne à part —
 cf. `LoadTelemetryEntry.surplusShareW`. Motif **jamais vu sur machine** au 2026-08-27 :
 la clé est prête, rien n'est bâti autour.
--- a/docs/BRIEF_plugin_depuis_maquettes.md
+++ b/docs/BRIEF_plugin_depuis_maquettes.md
@ -2,6 +2,69 @@

 ---

+## 2026-08-30 (suite) — `draw.committedW` en préalable : OUI, sans réserve
+
+**Et le refus de livrer `counts` sur `budget.evReservedW` est le bon appel.** Une identité
+*dépendante du temps* est pire que pas d'identité : vraie au premier cycle après un
+changement, fausse après convergence, elle passerait tous les tests — qui portent sur des
+cycles isolés — et **certifierait** un total faux chez les clients. R3 existe pour empêcher
+une réconciliation qui pourrit sans se voir ; la livrer sur un terme tantôt registre tantôt
+correction aurait fabriqué exactement ça, avec en plus le sceau d'une identité publiée.
+
+### Les trois destinations, et ce que l'app peut en dire
+
+| Destination | Nature | Réconciliable ? |
+|---|---|---|
+| `budget.allocatedW` | **registre d'allocation** (surplus) | **oui, aujourd'hui** — mesuré sur `.75` |
+| `budget.evReservedW` | **terme de correction** du budget, deux natures mêlées | **non, et jamais** |
+| `draw.committedW` | **registre** des watts achetés | oui, dès qu'il existe |
+
+Conséquence, à dire telle quelle : **il n'existe aujourd'hui qu'une identité vérifiable, et
+elle ne couvre qu'un côté.** `Σ targetW(surplus) == budget.allocatedW` — vérifiée à la sonde
+le 2026-08-30 (06:10 et 06:14). Côté réseau : **rien**. Pas « à vérifier plus tard », pas
+« approximativement `evReservedW` » : rien, jusqu'à `draw.committedW`.
+
+### Nous portions la fausse affirmation, et elle part aujourd'hui
+
+Elle est écrite chez nous en cinq endroits — « une charge financée au réseau vit dans
+`budget.evReservedW` » (`CLAUDE.md` ×2, le modèle ×3, la description ARB de la mention
+« servie au réseau »). Retirée dans le même lot, sans changement de comportement.
+
+> **Et la distinction avec notre discipline de la semaine, parce qu'elle a l'air de la
+> contredire.** L'exception `EV_GRID_START` décrit un **comportement de la box** : on ne la
+> retire qu'au vu de la sonde. « `evReservedW` est la destination des watts achetés » est une
+> **affirmation sur le sens d'un champ**, et elle est fausse *maintenant*, sur la box
+> d'aujourd'hui. Attendre une livraison pour corriger ce qu'on a compris de travers serait
+> laisser une doc mentir en connaissance de cause. **La sonde arbitre ce que fait la box, pas
+> ce que nous en avons cru.**
+
+### Trois demandes sur `draw.committedW`
+
+**a. Par cycle, en watts, dans la même trame que `budget`.** Sinon on compare deux instants,
+et l'identité redevient dépendante du temps par un autre chemin — celui-là même qu'on vient
+d'éviter.
+
+**b. Ne fabriquez pas le reste de l'objet `draw`.** Notre maquette lui donne aussi
+`authorisedW`, `remainingW`, `binding`, `perPhaseBound` (§10). Publier
+`draw: { "committedW": 1400 }` **seul** est parfait. Publier `authorisedW: 0` ou
+`binding: "connection"` par défaut ferait afficher à l'écran « ordre de service » un
+**plafond de soutirage qui n'existe pas, avec sa source** — un chiffre crédible et faux, et
+la faute exacte que ce champ est censé rendre impossible. Absent, jamais forgé : l'écran 2
+n'apparaîtra qu'avec l'objet complet.
+
+**c. Une phrase de définition pour `evReservedW`.** Nous l'affichons sous le libellé
+**« Réservé au véhicule »** (`_BudgetTable`), qui affirme une réservation là où il y a une
+correction. Nous ne le renommerons pas au jugé — donnez la définition, nous écrirons le
+libellé. C'est le seul geste que cette découverte laisse en suspens côté écran.
+
+### Ce qui ne bouge pas
+
+`counts` reste retenu tel qu'arbitré ce matin : la **forme** ne change pas, seul son préalable
+apparaît. Et l'exception `EV_GRID_START` reste dans le code et dans `CLAUDE.md` — elle tiendra
+plus longtemps que prévu, et c'est très bien ainsi.
+
+---
+
 ## 2026-08-30 — R3 : `counts` est retenu, et `funding` sort de la réconciliation

 **Réponse à la question du moteur sur le niveau mixte.** La forme proposée est prise telle
--- a/docs/mockups/deux_passes_eco_confort_mockup.html
+++ b/docs/mockups/deux_passes_eco_confort_mockup.html
@ -239,7 +239,7 @@
          <div class="lab"><span class="p2">■</span><u>Passe 2 — surplus disponible</u></div>
          <div class="grid">
            <div class="cell zero"><u>Surplus</u><b>0</b></div>
-            <div class="cell zero"><u>Réservé VE</u><b>0</b></div>
+            <div class="cell zero" style="border-style:dashed"><u>Réservé VE *</u><b>0</b></div>
            <div class="cell zero"><u>Recrédité</u><b>0</b></div>
            <div class="cell zero"><u>Alloué</u><b>0</b></div>
            <div class="cell zero"><u>Reliquat</u><b>0</b></div>
@ -422,6 +422,10 @@
          <code>setpointW</code>, <code>currentA</code>), qui existe déjà aujourd'hui.</li>
        <li><b>Et il ne se répartit pas non plus.</b> L'écart appartient à la charge, pas à un niveau :
          l'adaptateur arrondit une consigne unique, il ne sait pas de quel besoin elle venait.</li>
+        <li><b>* « Réservé VE » n'est pas une destination</b> — c'est un <b>terme de correction</b> du budget
+          (constaté par le moteur le 2026-08-30). Il est affiché parce que la box le publie, jamais sommé, et
+          son libellé actuel affirme une réservation qui n'a pas lieu : il attend une définition du moteur pour
+          être réécrit. Les watts achetés, eux, n'ont de registre qu'avec <code>draw.committedW</code>.</li>
        <li>Le bandeau ◆ n'apparaît <b>que si au moins une charge porte une obligation éco</b>. Sans obligation,
          il n'y a qu'une passe utile et la phrase serait du bruit (LM-1007).</li>
      </ul>
@ -663,7 +667,12 @@

 <span class="c">// et, une fois par cycle, à côté de "budget" :</span>
 <span class="k">"draw"</span>: { <span class="k">"authorisedW"</span>: <span class="n">4000</span>, <span class="k">"committedW"</span>: <span class="n">4000</span>, <span class="k">"remainingW"</span>: <span class="n">0</span>,
-          <span class="k">"binding"</span>: <span class="s">"gridOperator"</span>, <span class="k">"perPhaseBound"</span>: false }</pre>
+          <span class="k">"binding"</span>: <span class="s">"gridOperator"</span>, <span class="k">"perPhaseBound"</span>: false }
+
+<span class="c">// ⚠ committedW part SEUL, et AVANT counts (2026-08-30) : c'est le registre des watts</span>
+<span class="c">// achetés, et il n'en existe aucun aujourd'hui. draw: {"committedW": 1400} tout court</span>
+<span class="c">// est la bonne première livraison — les quatre autres champs ABSENTS, jamais à 0 :</span>
+<span class="c">// un authorisedW forgé afficherait un plafond de soutirage qui n'existe pas.</span></pre>

  <h3>Huit exigences, et chacune tient un endroit précis de la maquette</h3>

@ -703,6 +712,13 @@
    <b>ni <code>"mixed"</code> publié</b> : une troisième valeur tomberait dans la branche par défaut de tout
    client — « surplus » — donc reproduirait la panne de l'omission, et elle serait <b>dérivable de
    <code>counts</code></b>, donc supprimée un jour à juste titre.</p>
+    <p><b>Et il a un préalable, trouvé en le câblant (2026-08-30) : <code>draw.committedW</code>.</b>
+    <code>budget.evReservedW</code> n'est pas un registre d'allocation mais un <b>terme de correction</b> du
+    budget — une borne servie au réseau qui tire déjà ce qu'on lui a commandé y contribue <b>0</b> pour un
+    <code>targetW</code> de 7 000 W. <code>Σ counts == targetW</code> y serait vraie au premier cycle après un
+    changement et fausse ensuite : une identité <b>dépendante du temps</b>, qui passe tous les tests et
+    certifie un total faux. <b>Les watts achetés n'ont aucun registre aujourd'hui</b> — d'où une seule identité
+    vérifiable, du côté surplus, et rien de l'autre côté tant que <code>committedW</code> n'est pas publié.</p>
    <p><b>Ce que l'app promet en échange</b> : les clés de <code>counts</code> sont traitées comme des
    <b>identifiants opaques</b>, jamais comme des chemins. Une clé inconnue d'une version ancienne n'est pas
    perdue : l'identité <code>Σ counts == targetW</code> reste vérifiable sans connaître le sens des clés, et
--- a/lib/l10n/app_fr.arb
+++ b/lib/l10n/app_fr.arb
@ -155,7 +155,7 @@
  },
  "telemetryFundedByGrid": "Financée au réseau (échéance ou tarif dynamique) — hors budget de surplus",
  "@telemetryFundedByGrid": {
-    "description": "funding == « grid » : l'allocation vit dans budget.evReservedW, pas dans budget.allocatedW. Sans cette mention, l'utilisateur voit une charge servie alors que le surplus est nul et croit à un défaut."
+    "description": "funding == « grid » : l'allocation est hors de budget.allocatedW, et sans registre où la retrouver (evReservedW est une correction du budget, pas une destination — constaté 2026-08-30). Sans cette mention, l'utilisateur voit une charge servie alors que le surplus est nul et croit à un défaut."
  },
  "telemetryNotArbitrated": "Non arbitrée — absente du dernier cycle publié",
  "@telemetryNotArbitrated": {
--- a/lib/models/load_telemetry.dart
+++ b/lib/models/load_telemetry.dart
@ -441,7 +441,11 @@ class LoadTelemetryEntry {
  ///
  /// - `"surplus"` — la cascade PV. L'allocation est comptée dans `budget.allocatedW`.
  /// - `"grid"` — le proxy (échéance de départ, tarif dynamique) qui **soutire au
-  ///   réseau**. Elle vit dans `budget.evReservedW`, PAS dans `budget.allocatedW`.
+  ///   réseau**. Elle n'est PAS dans `budget.allocatedW` — et elle n'est nulle part
+  ///   ailleurs non plus : `budget.evReservedW` est un **terme de correction** du budget,
+  ///   pas un registre d'allocation (constaté par le moteur le 2026-08-30 en câblant R3 —
+  ///   une borne au réseau déjà mesurée y contribue 0 pour un `targetW` de 7 000 W). Les
+  ///   watts achetés n'auront de registre qu'avec `draw.committedW`.
  ///
  /// **Sommer les `allocatedW` sans filtrer donne un écart avec `budget.allocatedW` que
  /// rien ne permet d'interpréter** : défaut du moteur, ou borne servie au réseau ? Cf.
@ -541,7 +545,7 @@ class LoadTelemetryEntry {
  }

  /// Vrai quand **tout** ce qui est servi à cette charge est acheté au réseau — donc
-  /// compté dans `budget.evReservedW` et non dans `budget.allocatedW`.
+  /// **hors** de `budget.allocatedW`, et sans registre où le retrouver (voir [funding]).
  ///
  /// Volontairement faux sur `'mixed'` : la mention « servie au réseau » serait alors une
  /// demi-vérité, et c'est un écran à deux niveaux qui la remplacera (R1, R3 à R8).
@ -681,9 +685,12 @@ class LoadTelemetry {

  /// Somme des allocations **financées par le surplus**.
  ///
-  /// C'est le seul terme comparable à `budget.allocatedW` : une borne servie au réseau
-  /// est comptée dans `budget.evReservedW`, et l'inclure ici creuserait un écart que rien
-  /// ne permettrait d'interpréter — défaut du moteur, ou borne au réseau ?
+  /// C'est le seul terme comparable à `budget.allocatedW` : une charge servie au réseau
+  /// n'entre pas dans ce compteur, et l'inclure ici creuserait un écart que rien ne
+  /// permettrait d'interpréter — défaut du moteur, ou charge au réseau ?
+  ///
+  /// **Et c'est la seule identité qui existe** : il n'y en a aucune du côté réseau tant que
+  /// `draw.committedW` n'est pas publié. `budget.evReservedW` ne peut pas en tenir lieu.
  ///
  /// Somme des [LoadTelemetryEntry.surplusShareW], et non des `allocatedW` filtrés : le
  /// démarrage soutiré (`EV_GRID_START`) partage une même allocation entre les deux