docs(§11): la règle d'affichage du compteur se lit sur source, jamais sur adapter

Signalé en relayant +etm26 : « masqué dès que la charge mesure, sauf SG-Ready »
formule la règle PAR MÉCANISME. La conclusion est bonne, la clé est fausse, et le
contrat ne l'interdisait pas explicitement.

L'exception SG-Ready est déjà DANS LA DONNÉE : un sg-ready publie `none`, donc
« masquer quand source == device » ne le masque pas, sans qu'aucun client ait à
connaître le mécanisme.

Et brancher sur `adapter` se trompe sur un cas qui n'a rien de théorique : un
relay-router à topologie MIXTE publie lui aussi `none` (LM-1105-a). Un client qui
déciderait au mécanisme masquerait le champ sur un ECS qui ne peut être mesuré
QUE par un compteur dédié. Un mécanisme est un mauvais indice de mesurabilité ;
la source EST la mesurabilité.

C'est LM-1106 pris par l'autre bout : le régime est publié POUR qu'il ne soit pas
déduit. Le redéduire du mécanisme côté client remettrait dans l'app la déduction
qu'on vient de retirer du moteur — et il faudrait la maintenir à chaque mécanisme
ajouté.

Aucun code, aucune sémantique déplacée : le contrat dit désormais ce qu'il
laissait deviner. Pas de release.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p

INTERFACE.md

@@ -417,7 +417,8 @@ charge — jamais ce qu'on lui **commande**.
   **autorisé partout** et **prioritaire** quand il est renseigné : un compteur posé exprès est
   le seul à pouvoir contredire un appareil qui se déclare. Ce qui change est qu'il cesse d'être
   une corvée là où le moteur peut déduire — un client avisé le **masque par défaut** sur les
-  charges dont `source` vaut déjà `device`, sans l'interdire.
+  charges dont `source` vaut déjà `device`, sans l'interdire. **Cette règle d'affichage se lit
+  sur `measurement.source`, jamais sur `adapter`** : voir la note sous `measurement`.
 - **Ni l'un ni l'autre n'est exclusif**, contrairement à `relays[]`. Ils mesurent, ils ne
   commandent pas : `validateSet()` les ignore, et deux charges peuvent partager une sonde de
   pièce ou un compteur de tableau divisionnaire.
@@ -716,6 +717,17 @@ allocations irréconciliable avec `budget.allocatedW`.
 > pouvoir détecter un mensonge.** C'est ce qui justifie de laisser `meterThingId` **disponible**
 > sur une charge qui publie déjà sa puissance : masqué par défaut, jamais interdit.
 
+> **Décidez sur `source`, jamais sur `adapter`.** « Masquer le compteur dédié sauf pour
+> `sg-ready` » paraît équivalent et ne l'est pas : un `relay-router` à topologie **mixte**
+> publie lui aussi `none`, et un client qui déciderait au mécanisme masquerait le champ sur un
+> ECS qui ne peut être mesuré **que** par un compteur dédié. La règle sûre tient en une ligne —
+> masquer par défaut quand `source == "device"`, proposer sinon — et elle couvre l'exception
+> SG-Ready sans qu'aucun client ait à la connaître.
+>
+> C'est la raison d'être de `source` : le régime est publié **pour** qu'il ne soit pas déduit.
+> Le déduire du mécanisme côté client remettrait dans l'app la déduction qu'on vient de retirer
+> du moteur.
+
 > **Migration depuis `measuredW`.** L'ancienne clé disparaît ; elle ne pouvait pas exprimer
 > trois états, et la doubler d'un second champ aurait obligé le client à joindre deux clés pour
 > lire une seule chose. `measuredW: X` devient `measurement: {source: …, powerW: X}` ; son

docs/BRIEF_depuis_plugin.md

@@ -326,6 +326,22 @@ en panne », que rien ne séparait.
 > `meterThingId` reste **autorisé** sur une borne qui publie déjà : à masquer par défaut, pas à
 > interdire.
 
+**Et une mise en garde sur la façon d'écrire cette règle chez vous : décidez sur
+`measurement.source`, jamais sur `adapter`.** « Masqué dès que la charge mesure, sauf SG-Ready »
+paraît équivalent et ne l'est pas — un `relay-router` à topologie **mixte** publie lui aussi
+`none`, et vous masqueriez le champ sur un ECS qui ne peut être mesuré **que** par un compteur
+dédié. La règle sûre tient en une ligne, et elle couvre l'exception SG-Ready sans que vous ayez
+à la connaître :
+
+```
+si measurement.source == "device"  → compteur dédié en réglage avancé (replié)
+sinon                              → compteur dédié proposé, visible
+```
+
+C'est toute la raison d'être de `source` : le régime est **publié** pour ne pas être déduit. Le
+redéduire du mécanisme côté app remettrait chez vous la déduction qu'on vient de retirer du
+moteur — et vous la maintiendriez à chaque mécanisme ajouté.
+
 ### Deux choses trouvées en implantant, qui changent ce que vous afficherez
 
 **`sg-ready` est `none` par CONSTRUCTION, pas par accident de matériel.** Un contact SG-Ready est

specs/spec_loadmodel.md

@@ -1026,6 +1026,22 @@ dédié » se **masque par défaut** là où `source` vaut `device`, et se propo
 Il ne doit pas être *interdit* : ce serait fermer le cas ci-dessus, et casser le compteur de
 tableau divisionnaire couvrant plusieurs charges (LM-1104).
 
+> **La règle de présentation se lit sur `source`, JAMAIS sur `adapter`.** La tentation est
+> d'écrire « masqué sauf pour `sg-ready` », puisque LM-1105-b fait de ce mécanisme une
+> exception. Mais l'exception est déjà **dans la donnée** : un `sg-ready` publie `none`, donc la
+> règle « masquer quand `source == "device"` » ne le masque pas — sans qu'aucun client ait à
+> connaître le mécanisme.
+>
+> Et brancher sur `adapter` se **trompe** sur un cas qui n'a rien de théorique : un
+> `relay-router` à topologie **mixte** publie lui aussi `none` (LM-1105-a). Un client qui ne
+> déciderait qu'au mécanisme masquerait le champ sur un ECS qui, précisément, ne peut être
+> mesuré que par un compteur dédié. Un mécanisme est un mauvais indice de mesurabilité ; la
+> source EST la mesurabilité.
+>
+> C'est LM-1106 pris par l'autre bout — le régime est publié **pour** qu'il ne soit pas déduit,
+> et le déduire du mécanisme côté client remettrait dans l'app la déduction qu'on vient de
+> retirer du moteur.
+
 ---
 
 ## §12 — Le plancher de modulation