From 9c4862eab0fff91dcb8ca277c5feb2ef98b8c9db Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Thu, 27 Aug 2026 14:49:55 +0200 Subject: [PATCH] =?UTF-8?q?docs(spec=20=C2=A710):=20LM-1009=20=E2=80=94=20?= =?UTF-8?q?les=20trois=20arbitrages=20tranch=C3=A9s,=20et=20deux=20conditi?= =?UTF-8?q?ons=20de=20livraison?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Décisions de Patrick, écrites dans la spec et portées à l'agent app qui avait remonté la question. 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 lit comme une lecture du véhicule. Le pourcentage reste dans la saisie de l'intention, il sort de l'affichage de l'avancement. D2 — obligation par SESSION d'abord. Elle ne demande que de lire un champ déjà publié, c'est l'usage réel (on branche le soir pour partir le matin), et surtout la remise à zéro de sessionEnergy au branchement CESSE d'être une réserve : pour une obligation de session, c'est la bonne sémantique. Le texte est réécrit en conséquence — le problème disparaît au lieu d'être contourné. L'obligation quotidienne devient un lot à part, dépendant de l'historique du §11. 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. Précédent de nommage déjà dans ce document (estimatedPowerW), et même refus que le currentPowerStorage à zéro du relevé 3g-1 : mieux vaut « estimé », ou rien, qu'un chiffre crédible et faux. Les deux réserves deviennent des CONDITIONS DE LIVRAISON, pas des notes — ce sont les deux façons dont le §10 peut mentir sans erreur visible : C1 — une borne sans sessionEnergy dégrade VISIBLEMENT. Mesuré : wallboxNoMeter et l'une des deux classes wallbox ne l'ont pas. Une échéance qui cesse silencieusement d'être mesurable est pire qu'une échéance absente, parce qu'elle continue de s'afficher. Et « pas mesurable » n'est pas « rien livré ». 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. La distinction des deux régimes est conservée telle quelle : une obligation en énergie peut annoncer son atteinte, une cible en pourcentage publie une intention et un avancement estimé — jamais « tenue ». Le brief app gagne un cinquième point : c'est celui qui change un écran. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj --- specs/spec_loadmodel.md | 63 +++++++++++++++++++++++++++++------------ 1 file changed, 45 insertions(+), 18 deletions(-) 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**. ---