spec(LM-1005-b-i/ii/iii): une plage tarifaire porte son fuseau dans le champ
L'agent app pousse la distinction un cran plus loin, et elle a raison : ce n'est pas la même donnée avec deux fuseaux, ce sont DEUX DONNÉES DIFFÉRENTES. Ça change ce qu'il faut persister, pas seulement ce qu'il faut afficher. Une heure murale nue est CORRECTE pour une échéance client. Si la box change de fuseau, « 07:00 » doit se réinterpréter : le client veut son eau chaude à 7 h du matin CHEZ LUI. Réinterpréter est le bon comportement, pas une tolérance. La même heure nue est un défaut MUET pour une plage tarifaire. La fenêtre est définie ailleurs, par le fournisseur ; elle ne bouge pas parce que la box a bougé. Une donnée qui se réinterprète alors que son référentiel ne bouge pas devient fausse SANS QUE RIEN DANS LA DONNÉE NE PERMETTE DE S'EN APERCEVOIR — et la facture est le seul endroit où ça se verrait, un mois plus tard. D'où LM-1005-b-i : le fuseau de référence vit dans le CHAMP, pas dans une convention d'appel. Une convention se perd au premier import, au premier changement de fournisseur, au premier agent qui n'a pas lu le paragraphe. LM-1005-b-ii : et il se PUBLIE. Ne pas laisser un client déduire Europe/Paris — un fournisseur allemand définit ses plages en Europe/Berlin. Déduire, ce serait choisir une horloge à la place de quelqu'un, exactement ce que la décision « ni imposer, ni refuser : déclarer » refuse. Le moteur publie le fuseau de référence avec la configuration tarifaire, comme il publiera celui de l'installation avec la sienne. LM-1005-b-iii : DEUX avertissements distincts, jamais fusionnés en une seule comparaison. L'échéance compare installation ≠ appareil ; la plage tarifaire compare fournisseur ≠ installation. Seul le second peut faire acheter au mauvais moment, et seul le second est indevinable par un installateur — il ne se voit ni sur la box ni sur le téléphone, seulement en rapprochant le contrat. Les fondre en un « les fuseaux diffèrent » ferait disparaître celui qui compte derrière celui qui se corrige tout seul.
This commit is contained in:
parent
7398b1dd24
commit
02522dd941
@ -606,6 +606,43 @@ tarif est défini.**
|
||||
> `docs/DESIGN_FUSEAU.md` — il n'existe qu'UN fuseau, celui du système, et un `nymead` vivant
|
||||
> suit son changement sans redémarrage.
|
||||
|
||||
**LM-1005-b-i — une heure murale nue est CORRECTE pour une échéance client, et FAUTIVE pour une
|
||||
plage tarifaire.** *(Distinction poussée un cran plus loin par l'agent app, 2026-09-04.)*
|
||||
|
||||
Ce n'est pas la même donnée avec deux fuseaux : ce sont deux données différentes.
|
||||
|
||||
- **Échéance client** — `"07:00"` nu est le bon codage. Si la box change de fuseau, l'habitude
|
||||
doit se réinterpréter : le client veut toujours son eau chaude à 7 h **du matin chez lui**.
|
||||
Réinterpréter est ici le comportement CORRECT, pas une tolérance.
|
||||
- **Plage tarifaire** — `"22:00"` nu est un défaut MUET. La fenêtre est définie **ailleurs**,
|
||||
par le fournisseur ; elle ne bouge pas parce que la box a bougé. Une donnée qui se
|
||||
réinterprète alors que son référentiel, lui, ne bouge pas, devient fausse **sans que rien
|
||||
dans la donnée ne permette de s'en apercevoir**.
|
||||
|
||||
Conséquence : **le fuseau de référence vit dans le CHAMP, pas dans une convention d'appel.** Une
|
||||
convention se perd au premier import, au premier changement de fournisseur, au premier agent qui
|
||||
n'a pas lu ce paragraphe. Sans ça, le piège du 2026-09-04 revient à l'identique sur un champ où
|
||||
il coûte de l'argent au lieu d'une phrase d'écran.
|
||||
|
||||
**LM-1005-b-ii — le fuseau de référence se PUBLIE, il ne se déduit pas.** Ne pas laisser un
|
||||
client supposer `Europe/Paris` : un fournisseur allemand définit ses plages en `Europe/Berlin`.
|
||||
Un client qui déduirait choisirait une horloge **à la place de quelqu'un** — exactement ce que
|
||||
la décision « ni imposer, ni refuser : déclarer » refuse. Le moteur publie donc le fuseau de
|
||||
référence avec la configuration tarifaire, comme il publiera celui de l'installation avec la
|
||||
sienne.
|
||||
|
||||
**LM-1005-b-iii — DEUX avertissements distincts, à ne jamais fusionner en une comparaison.**
|
||||
|
||||
| avertissement | compare | conséquence si ignoré |
|
||||
|---|---|---|
|
||||
| échéance client | **installation ≠ appareil** | l'obligation tombe à la mauvaise heure |
|
||||
| plage tarifaire | **fournisseur ≠ installation** | on **achète au mauvais moment** |
|
||||
|
||||
Seul le second peut coûter de l'argent, et seul le second est **indevinable par un installateur**
|
||||
— il ne se voit ni sur la box, ni sur le téléphone, seulement en rapprochant le contrat du
|
||||
fournisseur. Les fusionner en un unique « les fuseaux diffèrent » ferait disparaître celui des
|
||||
deux qui compte derrière celui qui se corrige tout seul.
|
||||
|
||||
**Conséquence de conception** : la passe 1 n'est **pas** bornée par le surplus. Elle est bornée
|
||||
par une **autorisation de soutirage** — un objet distinct, que le rule-based rendra binaire et
|
||||
que le MILP rendra continu. La passe 2, elle, reste strictement bornée par le reliquat de
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user