diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md index 0c05016..262499c 100644 --- a/specs/spec_loadmodel.md +++ b/specs/spec_loadmodel.md @@ -727,15 +727,12 @@ annonçait. véhicule en reçoit moins. Ce n'est pas un défaut de la mesure — c'est le bon côté du compteur pour une **obligation d'énergie** : celui qu'on paie. Mais la promesse doit se formuler « livrer X kWh », jamais « mettre X kWh dans la batterie ». -2. **`sessionEnergy` se remet à zéro au branchement.** Parfait pour une obligation *par session*, - **inutilisable tel quel** pour un `minEnergyWhPerDay` : débrancher et rebrancher relance le - compteur, et l'obligation du jour se croirait à zéro. L'accumulation entre sessions est un - mécanisme distinct, et sa place naturelle est l'historique du §11. -3. **Toutes les bornes ne la publient pas** — mesuré : `wallboxNoMeter` et l'une des deux classes - `wallbox` ne l'ont pas. La dégradation doit être **VISIBLE** : une échéance qui cesse - silencieusement d'être mesurable est pire qu'une échéance absente, parce qu'elle continue de - s'afficher. Même exigence que `hasPowerMeter()`, qui est déjà testé avant d'estimer un SoC. -4. **Elle ne répondra JAMAIS à « la voiture sera-t-elle pleine ? »** Aucune énergie livrée ne dit +2. **`sessionEnergy` est une grandeur de SESSION** : elle se remet à zéro au branchement. Ce + n'est une réserve que si l'on vise une obligation *quotidienne* — et la décision D2 ci-dessous + ne la vise pas. Pour une obligation *par session*, la remise à zéro n'est pas un obstacle + contourné : c'est **exactement la bonne sémantique**, et le problème disparaît au lieu d'être + traité. +3. **Elle ne répondra JAMAIS à « la voiture sera-t-elle pleine ? »** Aucune énergie livrée ne dit où en est une batterie dont on ne connaît ni l'état de départ ni la capacité réelle. Une cible en énergie est vérifiable ; une cible en pourcentage ne l'est pas. Ce sont **deux objets différents**, et le §10 ne doit pas les confondre sous le mot « échéance ». @@ -759,15 +756,45 @@ l'être. C'est la même exigence que celle qui sépare `BELOW_MIN_POWER` de `SUR qu'elles n'appellent pas le même geste. Ici le geste diffère radicalement — « attends, ça charge » contre « je ne peux pas savoir où tu en es ». -> **Ce que cette note NE tranche pas**, et qui demande une décision : -> — l'app garde-t-elle un écran en pourcentage, alimenté par l'estimation clairement étiquetée, -> ou bascule-t-elle en énergie livrée, qui est la seule chose que la box sait prouver ? -> — `minEnergyWhPerDay` exige-t-il l'accumulation inter-sessions du §11, ou le §10 se limite-t-il -> d'abord à une obligation **par session**, qui ne demande rien de plus que de lire un champ -> déjà publié ? -> -> La seconde est le vrai arbitrage de lot : l'obligation par session est faisable avec -> `sessionEnergy` seul, l'obligation quotidienne demande un historique. +### DÉCISIONS *(Patrick, 2026-08-27)* + +**D1 — L'avancement s'affiche en ÉNERGIE LIVRÉE, jamais en pourcentage.** « 8,4 kWh livrés depuis +le branchement » est vérifiable ; « 62 % » suppose une capacité que personne ne connaît et **se +lira comme une lecture du véhicule**. Le pourcentage garde sa place dans la **saisie de +l'intention** — l'utilisateur pense sa voiture en pourcentage — mais **jamais dans l'affichage de +l'avancement**. + +**D2 — Obligation par SESSION d'abord.** Le §10 lit `sessionEnergy` et s'arrête là. Trois raisons +qui vont dans le même sens : elle ne demande que de lire un champ **déjà publié** ; la remise à +zéro au branchement cesse d'être une réserve (voir ci-dessus) ; et c'est **l'usage réel** — on +branche le soir pour partir le matin. L'accumulation inter-sessions est un **lot à part**, +dépendant de l'historique du §11, et `minEnergyWhPerDay` ne sera honoré qu'avec lui. + +**D3 — Tant que le chemin `carBatteryLevel` survit, il est ÉTIQUETÉ à la publication.** Une valeur +que le moteur a lui-même intégrée ne franchit pas la frontière RPC **sous le même nom qu'une +mesure**. Le précédent de nommage existe déjà dans ce document : `estimatedPowerW` porte +volontairement son préfixe (§3), parce qu'un nom doit porter le statut épistémique de ce qu'il +transporte. C'est aussi le refus opposé au `currentPowerStorage` à zéro du relevé 3g-1 : **mieux +vaut « estimé », ou rien, qu'un chiffre crédible et faux** — et c'est le corollaire de forme +d'`AGENTS.md` invariant 12, « un champ absent vaut mieux qu'un champ nul ou forgé ». + +### CONDITIONS DE LIVRAISON — pas des recommandations + +Elles s'écrivent avec le mécanisme, pas après. Ce sont les deux façons dont ce §10 peut mentir +sans erreur visible. + +**C1 — Une borne qui ne publie pas `sessionEnergy` DÉGRADE VISIBLEMENT.** Mesuré sur le banc : +`wallboxNoMeter` et l'une des deux classes `wallbox` n'ont pas cet état. Sur ces bornes, +l'obligation n'est **pas mesurable** — et une échéance qui cesse silencieusement de l'être est +**pire qu'une échéance absente**, parce qu'elle continue de s'afficher comme si elle tenait. Le +moteur doit le dire, l'app doit le montrer, et la dégradation ne doit jamais se lire comme un +avancement nul. Même geste que `hasPowerMeter()`, déjà testé avant toute estimation de SoC. + +**C2 — On doit pouvoir dire LEQUEL des deux régimes s'applique — dans le motif comme à l'écran.** +Un avancement mesuré et un avancement estimé ne se distinguent par aucune de leurs valeurs : les +deux sont un nombre qui monte. Si le régime ne se lit pas, le second se fait passer pour le +premier, et c'est précisément le défaut que cette note décrit. Le régime est donc une donnée +publiée, au même titre que la source d'un plafond en LM-1006-1 — **deux causes, deux phrases**. ---