etm-powersync-energy-plugin-etm/specs/spec_loadmodel.md

# SPEC — Modèle de charges (domaine × mécanisme)

Version : 0.1.4
Dépôt : `etm-powersync-energy-plugin-etm`
Statut : **intention de conception figée.** §3 (schéma persisté) est **en cours
d'implémentation** depuis le 2026-08-09 : `relay-router`, `etmvariableload` et
`sg-ready` sont trois charges utiles discriminées par `adapter`. Le reste du
document reste une intention.

> **0.1.4** — LM-201 et LM-202 ajoutés (§2). **LM-201 est la règle qui manquait** : une
> charge existe quand il y a un **canal de commande distinct pour un service**. Un canal, une
> charge. Elle repose la question du domaine, que 0.1.3 posait mal — le domaine ne décrit pas la
> **machine**, il décrit **ce qu'on arbitre**. Elle explique du même coup la contrainte
> d'exclusivité de `validateSet()`, qui cesse d'être une limite technique subie.
> **LM-202** : les thermostats et les zones ne sont pas des charges.

> **0.1.3** — LM-200 ajouté (§2) : toutes les cases de la matrice ne se valent pas.
> Certaines sont *non prévues*, d'autres sont **interdites par la physique** — le cas de la
> PAC, qui ne se pilote qu'en `SgReady` ou en communicant. Précise LM-101, qui était trop
> permissif lu seul. Aucune décision de conception renversée ; une contrainte qui existait
> dans le matériel et pas dans le document.

> **0.1.2** — LM-104 ajouté (§1) : « supposer conservateur pour annoncer, tenter
> systématiquement pour agir ». Principe dégagé des tests d'ECS-411 et ECS-414,
> inscrit ici parce qu'il vaut pour tout mécanisme et non pour l'ECS seul.
> §3 : le mécanisme `sg-ready` a sa charge utile et cesse d'être une intention.

> **0.1.1** — passe de vérification contre le code. Quatre précisions :
> préséance des verrous (LM-303), portée de l'union discriminée (LM-302),
> citation de règle (LM-102), `EvAdapter` inscrit au renommage (LM-601).
> Aucune décision de conception modifiée.

> **Ce document ne déclenche aucun travail.** L'ordre de `specs/spec_ecs.md` §2
> reste seul en vigueur, et l'étape 1 reste bloquée par ses arbitrages §13-1 et
> §13-2. Une seule chose ici est urgente : la **forme du schéma persisté** (§3),
> parce que c'est la seule partie coûteuse à rattraper une fois que le banc et la
> beta auront écrit des données. Le reste s'implémente au fil des besoins.

---

## §1 — Deux couches

**LM-100** — Le modèle de charges se découpe en deux couches indépendantes :

- **Couche domaine** — `Ecs`, `Hvac`, `Ev`, `SmartHome`. Détient le modèle de la
  charge (état thermique, échéance de départ, cycle), en déduit la demande et
  `available`. **Ne parle à aucun matériel.**
- **Couche mécanisme** — `Relay`, `Variable`, `SgReady`, `ModbusSetpoint`.
  Traduit une enveloppe en watts vers le matériel et tient les verrous.
  **Écrite une seule fois, partagée par tous les domaines.**

**LM-101** — Une charge configurée choisit **un domaine et un mécanisme**. Le
domaine ne détermine pas le mécanisme et réciproquement — mais il en **exclut**
certains, cf. **LM-200**. L'indépendance des deux couches porte sur le *couplage
de conception*, pas sur la liberté de combiner : elle dit qu'aucune des deux
n'a besoin de connaître l'autre pour être écrite, jamais que toute paire est
réalisable.

**LM-102** — Aucune des deux couches ne répartit de budget. La couche domaine se
retire de l'allocation via `available` ; elle ne la négocie pas. Règles absolues
1 et 2 d'`AGENTS.md` inchangées.

**LM-104 — Supposer conservateur pour annoncer, tenter systématiquement pour agir.**
Un adaptateur qui ne peut pas LIRE l'état d'un organe DOIT le supposer dans l'état
le plus consommateur (contact fermé, palier engagé) quand il **annonce** — dans
`telemetry()`, `toLoadContext()` ou la déduction de son état courant au démarrage.
Le même adaptateur DOIT néanmoins **émettre l'écriture** vers cet organe quand il
agit, sans jamais la court-circuiter au motif que l'état supposé coïncide déjà avec
la cible.

Les deux moitiés sont indissociables, et c'est l'omission de la seconde qui est
piégeuse : supposer « fermé » puis en déduire « donc rien à écrire » transforme une
hypothèse de prudence en **masquage de panne** — l'organe reste dans son état réel,
inconnu, et aucun verdict d'échec ne se déclenche. La prudence porte sur ce qu'on
DIT de l'installation, jamais sur ce qu'on lui ENVOIE.

Portée : tout mécanisme, présent et futur. `Relay` (déduction de palier au
démarrage), `SgReady` (relevé du motif de contacts réellement fermés), et par
construction `ModbusSetpoint` dès qu'un registre devient illisible. Origine :
deux défauts symétriques trouvés par les tests d'ECS-411 puis d'ECS-414 —
d'abord l'hypothèse inverse (« injoignable donc ouvert »), puis son corollaire
(« supposé fermé donc jamais écrit »).

**Justification.** Un nommage par domaine seul (`EcsAdapter`, `HvacAdapter`)
obligerait à écrire l'encodage SG-Ready deux fois (ECS et HVAC), la combinatoire
de relais deux fois (ECS et EV en prise commandée), et le transport Modbus deux
fois (HVAC et EV). Un nommage par mécanisme seul perdrait les comportements
propres au domaine, qui sont réels : stockage différable pour l'ECS, confort
immédiat pour le HVAC, échéance de départ pour l'EV, cycle non modulable pour le
SmartHome.

---

## §2 — Matrice

| Domaine | Mécanismes attendus |
|---|---|
| `Ecs` | `Relay` (résistance à paliers) · `SgReady` (ballon thermodynamique) · `Variable` (triac) |
| `Hvac` | `SgReady` (PAC) · `ModbusSetpoint` (PAC, clim, VMC) |
| `Ev` | `Relay` (prise commandée : GreenUp, Witty) · `ModbusSetpoint` (borne) |
| `SmartHome` | `Relay` — voir §7, sémantique différente |

**LM-200 — Une case vide se lit de deux façons, et il faut les distinguer.** La
plupart sont *non prévues* : rien ne les interdit, elles n'ont simplement pas
d'usage identifié. D'autres sont **impossibles**, parce que le mécanisme ne sait
pas commander cet organe-là. Les confondre revient à traiter une contrainte
physique comme une lacune de feuille de route.

**Le cas dur, et le seul identifié à ce jour : la PAC.** Une pompe à chaleur se
pilote de **deux** façons, et de deux seulement :

| Voie | Mécanisme | Ce qui circule |
|---|---|---|
| **SG-Ready** | `SgReady` | deux contacts **secs** vers l'entrée de signalisation — 4 états normés |
| **Communicante** | mécanisme *communicant*, via un plugin nymea | mode, consignes, limite de puissance — le modèle **propre** de la machine |

**Ni `Relay`, ni `Variable`.** Ce ne sont pas des cases à remplir plus tard :

- **`Relay` couperait l'ALIMENTATION du compresseur.** Un `RelayRouter` étage de la
  puissance réelle ; appliqué à une PAC, il lui retire son autorité sur son propre
  cycle — dégivrage, retour d'huile, temporisation de redémarrage — et transforme
  chaque décision d'arbitrage en court-cycling. Le verrou `minOn/minOff` limite la
  casse, il ne rend pas le geste légitime.
- **`Variable` suppose un cadran en watts.** Un triac module une résistance ; un
  compresseur n'est pas gradable. Une PAC communicante peut certes accepter une
  *limite* de puissance, mais elle l'interprète selon son propre modèle et ne
  s'engage sur aucune valeur instantanée — ce n'est pas la sémantique d'enveloppe
  que `Variable` promet à l'optimiseur, et cette promesse alimente le budget.

**⚠️ Le piège de lecture : « ma PAC est pilotée par deux relais, donc `Relay` ».**
Non. Les contacts SG-Ready **sont** des relais, et au banc `.75` ce sont bien deux
things `power` (K1/K2). Mais ils **signalent**, ils ne **portent** pas la charge.
C'est exactement ce qui sépare les deux mécanismes : `Relay` commute de la
puissance, `SgReady` commute du sens. Voir des relais dans une configuration ne
dit donc rien du mécanisme qui convient.

**Ce que ça implique pour le mécanisme communicant, qui n'existe pas encore.** Il
est appelé `ModbusSetpoint` dans ce document : **le nom est trop étroit.** Ce qui
le définit n'est pas Modbus — c'est qu'un **thing nymea** porte le modèle de la
machine et que le moteur lui parle dans ce modèle-là. Le transport (Modbus
RTU/TCP, IP propriétaire, passerelle cloud) est une affaire de plugin
d'intégration, invisible d'ici. À renommer quand il sera implémenté ; à ne pas
confondre avec `Variable` d'ici là, malgré la ressemblance de surface d'une
« consigne » à écrire.

**Rien n'empêche aujourd'hui d'exprimer une case interdite, et c'est assumé.**
`domain` est une métadonnée d'intention, **optionnelle**, que l'arbitre ne lit
pas : une charge `domain: "hvac"` + `adapter: "relay-router"` est acceptée par
`isValid()`. **Décision prise (2026-08-25) : pas de refus.** Un refus ferait
cesser `o:domain` d'être une métadonnée — donc changerait le contrat annoncé à
l'app — et resterait **contournable par omission**, le domaine étant facultatif.
Un contrôle qu'on esquive en effaçant un champ protège mal. La sanction retenue
est un **avertissement au journal** à la construction de l'adaptateur.

**Cet avertissement n'a pas encore de prédicat, et ne peut donc pas être écrit
aujourd'hui.** LM-201 en dit la raison : le domaine décrit **ce qu'on arbitre**,
pas la machine — il ne peut pas révéler qu'il y a un compresseur derrière. Keyé
sur le domaine seul, l'avertissement crierait sur des installations correctes :

| Configuration | Verdict réel |
|---|---|
| `heating` + `relay-router` | **légitime** — chauffage électrique résistif sur relais |
| `hvac` + `relay-router` | **légitime** — VMC, ventilateur sur contact |
| `hvac` + `etmvariableload` | **légitime** — ventilation à vitesse variable |
| `heating`/`hvac` + relais, mais PAC derrière | ce qu'on veut signaler — **indistinguable des trois lignes ci-dessus** |

Le discriminant qui le porterait est **`typeAppareil`** (§3, LM-300), dont
l'énumération reste ouverte (§8-1) — c'est sa valeur *thermodynamique* qui dirait
« compresseur ». **L'avertissement est donc spécifié ici et implémenté avec
`typeAppareil`, pas avant.** Un avertissement qui crie au loup sur des
installations correctes abîme la seule surface de diagnostic dont dispose le banc.

---

**LM-201 — UN CANAL DE COMMANDE, UNE CHARGE.** Une charge existe quand il y a un
**canal de commande distinct pour un service**. C'est la règle qui fonde toutes
les autres, et elle repose la question du domaine : *« quel domaine pour une
PAC ? »* est **mal posée**. Une PAC air/eau fait chauffage, rafraîchissement et
ECS — le domaine ne décrit donc pas la **machine**, il décrit **ce qu'on
arbitre**.

Conséquences, toutes vérifiables sur une installation :

| Installation | Charges | Pourquoi |
|---|---|---|
| PAC chauffage + ECS, **sans ballon séparé** | **UNE** charge, domaine `heating` | un seul canal SG-Ready commande la machine entière |
| PAC + **ballon séparé** | **DEUX** charges (`heating`, `ecs`) | le ballon a son **propre** canal |
| PAC qui fait **aussi du froid** | **UNE** charge | même machine, même canal, même rang |

- **Pas de charge ECS sur une PAC sans ballon séparé.** Le SG-Ready commande la
  machine entière ; la répartition entre chauffage et ECS appartient à la
  **régulation de la PAC**. Il n'y a rien à arbitrer indépendamment — en déclarer
  deux reviendrait à promettre un arbitrage qu'aucun canal ne peut exécuter.
- **Le froid ne crée pas de charge.** Ce qui change entre l'été et l'hiver est la
  **saison**, pas la configuration. Une configuration qui devrait être réécrite
  deux fois par an serait le signe qu'on a modélisé la machine et non le canal.
- **La contrainte d'exclusivité de `validateSet()` n'est pas une limite technique
  subie — c'est le modèle.** Deux charges ne peuvent pas revendiquer les mêmes
  contacts (LM-302-b, ECS-110-b) parce que **deux charges sur un canal unique se
  contrediraient** : elles recevraient deux consignes pour un seul organe, et le
  budget compterait la même puissance deux fois (règle absolue 1). Le refus
  existait avant la règle ; la règle dit enfin pourquoi il est juste.

**LM-202 — Un thermostat de zone n'est PAS une charge.** Un thermostat ouvre une
**vanne** ; il ne porte pas la consommation, qui reste à la machine. Les déclarer
comme charges produirait des entrées à **0 W** dans le waterfall pendant que la
PAC est comptée ailleurs — des charges qui n'ont rien à recevoir, sur un canal
qui ne consomme rien.

Zones et thermostats sont de la **configuration de confort** : ils décrivent **où
va la chaleur**, pas **combien on en achète**. Ils vivent dans leur écran et leur
namespace — **pas dans `LoadConfig`**. C'est la même frontière que LM-102 trace
entre la couche domaine et l'allocation : décrire un besoin n'est pas négocier un
budget.

---

## §3 — Schéma de configuration (à figer)

**LM-300** — `LoadConfig` est une **union discriminée** par le mécanisme :

```
LoadConfig {
    id, nom, enabled
    domaine        : Ecs | Hvac | Ev | SmartHome
    typeAppareil   : affine le domaine (résistif | thermodynamique | …)
    groupe, prioritéGroupe, prioritéMembre
    mécanisme      : Relay | Variable | SgReady | ModbusSetpoint   ← discriminant
    chargeUtile    : LoadConfigRelay | LoadConfigVariable | …
    verrous        : minOnS, minOffS
    facettes[]     : voir §4
}
```

**État d'implémentation (2026-08-09).** Trois charges utiles existent, discriminées
par le champ `adapter` du schéma persisté — `relay-router`, `etmvariableload`,
`sg-ready`. Le domaine, le groupe et les facettes ne sont pas encore portés : ce
qui est figé, c'est la **forme**, celle qui coûte cher à rattraper.

```
adapter = "sg-ready"  →  sgReady {
    states[] { state : 1..4, relays[] : thingId, estimatedPowerW }
    minStateHoldS
}
```

`estimatedPowerW` porte volontairement ce nom : c'est une **estimation**, jamais un
engagement — une PAC ne consomme pas la même chose à −5 °C et à +12 °C. Le champ
sert à ordonner et à budgéter, la mesure reste la source de vérité (ECS-500).
L'état 2 est **obligatoire** : c'est le plancher de repli du mode dégradé L2 et de
la désactivation (ECS-413/414). Une configuration qui ne peut pas l'exprimer est
refusée, pas construite.

**LM-301** — Ajouter un mécanisme DOIT se limiter à un type de charge utile et
une branche de fabrique. Rien d'autre ne bouge. **Vérifié à l'usage** : l'ajout de
`sg-ready` a touché exactement une charge utile, une branche de `isValid()`, une
branche de fabrique dans `rebuildLoadAdapters()`, et un champ optionnel au schéma
RPC. Aucun code d'arbitrage n'a bougé.

**LM-301-b — La limite de LM-301, trouvée au lot B-bis (2026-08-25).** « Une charge utile, une
branche de fabrique » vaut pour **construire** un mécanisme, pas pour l'**alimenter en actions**.
Quand `sg-ready` a rejoint la table commune des charges arbitrées, un code d'arbitrage a bel et
bien dû bouger : le repli du mode dégradé L2 fabriquait un `Setpoint(0)` pour **toute** la table,
en présumant du kind. Une PAC de configuration recevait donc une action que `SgReadyAdapter`
rejette d'entrée — et rien d'autre : elle restait en **état 4 (forcé)** sous compteur muet, quand
`SAFETY.md` §L2 exige l'état 2. Le défaut ne se voyait pas dans la télémétrie, où le motif
`DEGRADED_L2` s'affichait correctement ; seule l'**écriture** manquait.

**Règle qui en sort** : tout code qui **fabrique** une action pour une charge quelconque DOIT
lire `descriptor().supportedKinds` et se refuser explicitement s'il n'y trouve rien de connu —
jamais présumer du kind à partir de la table où la charge se trouve. C'est le pendant, côté
actions, de ce que LM-302-b dit côté validation : ce qui est vrai « pour toutes les charges »
n'appartient à aucune charge utile.

**LM-302-b — Ce qu'une charge utile ne peut pas valider.** L'exclusivité d'un Thing est
une propriété de l'**ensemble** des charges, pas d'une charge : aucune charge utile ne
peut la vérifier, quelle que soit sa rigueur. Elle vit donc au niveau du store
(`validateSet()`), et tout mécanisme futur DOIT déclarer les Things qu'il revendique via
`LoadConfig::claimedThingIds()` — c'est le seul point à étendre, et l'oublier rend le
mécanisme invisible à la vérification. Voir ECS-110-b.

**LM-302 — Charges utiles auto-validantes, et portée de l'« inexprimable ».**
Chaque charge utile valide la sienne. Les états invalides doivent être inexprimables
dans les **types C++** et le **schéma persisté** ; à la frontière **JSON-RPC**, la
validation est **à l'exécution**, par contrainte nymea.

**Corollaire vérifié à l'usage (2026-08-09).** `GetLoadConfig` sérialise via le
méta-objet, donc **toutes** les propriétés déclarées apparaissent dans la sortie — y
compris la charge utile **vide** d'un autre mécanisme. Un schéma qui exige une clé
interne dès que la charge utile est présente rend donc impossible l'aller-retour
lire-puis-réécrire, c'est-à-dire le geste ordinaire de l'application, et le rejet
survient **avant** le handler.

**Règle.** Toutes les clés internes d'une charge utile optionnelle DOIVENT être
déclarées optionnelles (`o:`) au schéma RPC. L'exigence réelle vit dans `isValid()`,
jamais dans le schéma. Les clés internes d'une charge utile optionnelle contraignent
les charges des **autres** mécanismes — c'est le côté par lequel le mur se touche.

**Obligation permanente.** Tout mécanisme ajouté DOIT être accompagné d'un test
d'aller-retour `GetLoadConfig` → `SetLoadConfig` **inchangé**, vérifié échouant sans
le correctif. Sans cette obligation, le prochain mécanisme rejouera la scène.

**LM-303 — Verrous.** `typeAppareil` fournit des **défauts** (résistif ≈ 60 s,
thermodynamique ≈ 300 s), l'installateur peut les modifier, et c'est la valeur
**stockée** qui fait foi. Jamais de temporisation codée en dur.

**Préséance.** Les verrous déclarés au niveau de la **charge** s'appliquent par
défaut. Une charge utile PEUT en porter de plus fins — par relais, par registre —
et ceux-là **priment** sur le défaut de charge, pour le seul actionneur qu'ils
désignent.

Cette règle laisse `spec_ecs.md` §13-3 (ECS-307, grain des temporisations par
relais) entièrement ouvert : ajouter plus tard un champ optionnel dans une charge
utile est rétro-compatible, quelle que soit la réponse. Le schéma persisté n'a
donc pas à être « rendu tolérant » — c'est la préséance qui devait être écrite,
et elle l'est ici.

---

## §4 — Facettes : une machine, plusieurs fonctions

**LM-400** — Une machine physique est **une seule charge** : un rang, un jeu de
verrous, une ligne de budget. Une PAC assurant chauffage et ECS n'est **jamais**
déclarée deux fois.

**Justification.** Deux déclarations produiraient une double allocation du
surplus pour une seule consommation, deux rangs pour un seul comportement, et
deux jeux de verrous sur un seul compresseur — la protection anti court-cycling
tomberait précisément là où elle coûte le plus cher.

**LM-401** — Une charge PEUT porter **plusieurs facettes** au-dessus d'un
actionnement unique. Une PAC mixte porte une facette ECS (consigne, température
ballon) et une facette chauffage, avec un seul mécanisme.

**LM-402** — Les facettes servent à la lecture, au suivi et au calcul
d'`available`. Elles **ne portent pas de rang**. Une charge à deux facettes ne
peut pas être classée « après les chauffe-eau mais avant la clim » : si cette
granularité est nécessaire, il faut deux machines, pas deux entrées.

**LM-403 — Le mode est une sortie, pas une entrée.** SG-Ready applique un niveau
d'encouragement à la machine entière ; le choix de la fonction appartient au
régulateur interne. Le HEMS **observe** le mode courant, il ne le sélectionne
pas. Aucune conception ne DOIT supposer un aiguillage.

Ce que le mode apporte : `available` devient honnête. Machine en mode chauffage
→ la facette ECS n'absorbera rien quoi qu'on encourage → le waterfall passe au
suivant au lieu de le deviner.

**LM-404 — Biais par consigne : option avancée, hors périmètre pour l'instant.**
Monter `hotWaterSetpointTemperature` place le ballon sous consigne et la machine
bascule d'elle-même. C'est indirect, lent, et surtout **persistant** : une
consigne écrite le reste après un plantage ou un redémarrage, et elle écrase un
réglage d'installateur. Toute implémentation future DOIT comporter des bornes
dures, une politique de restauration et un chien de garde. À ne rouvrir que si le
terrain le justifie.

**LM-405 — Décomposition côté ems, pas côté plugin.** Le découpage en facettes
DOIT se faire dans l'ems au-dessus des états plats du thing, et non en forkant
les plugins constructeurs. Chaque constructeur expose une structure différente ;
l'abstraction doit vivre là où elle est indépendante du constructeur, sous peine
de la refaire N fois et de gérer deux formes du même concept.

**LM-406** — Si l'installation n'a pas de chauffe-eau distinct, il n'y a pas de
charge ECS : la facette ECS s'accroche à la charge PAC.

---

## §5 — Groupes et double rang

**LM-500** — Un groupe est une **clé de tri**, jamais un détenteur de budget. Le
waterfall trie sur le couple `(prioritéGroupe, prioritéMembre)` et reste
inchangé. Un groupe qui reçoit une allocation puis la redistribue est un second
décideur (règle absolue 1).

**LM-501** — Classer un ECS, une PAC et une clim les uns par rapport aux autres
**fonctionne déjà** avec la liste plate triée par `priority`. Les groupes ne sont
nécessaires qu'à l'échelle : plusieurs chauffe-eau, plusieurs bornes, plusieurs
zones, quand on veut déplacer une famille entière sans renuméroter.

**LM-502 — Plafond de groupe : optionnel.** Justifié quand les membres partagent
une limite électrique réelle (bornes sur un même câble ou un même abonnement).
Sans objet pour un groupe thermique, dont les membres sont sur des circuits
distincts. C'est le seul point où la boucle du waterfall change vraiment : elle
doit suivre l'engagement cumulé du groupe.

**LM-503** — Deux notions à **ne pas** confondre avec un rang :

- **Exclusion mutuelle** (clim et PAC en opposition dans une même zone) : une
  contrainte entre appareils.
- **Équité interne** (trois chauffe-eau à rang égal, dont le troisième resterait
  froid tout l'été) : une politique de rotation dans le tri.

**LM-504** — « HVAC » couvre chauffage, ventilation et climatisation ; y ranger
l'eau chaude sanitaire est un abus. Libellé recommandé côté installateur :
« Thermique » ou « Chauffage & eau chaude ».

---

## §6 — Nommage

**LM-600** — Les classes d'actionnement portent le nom du **mécanisme**, jamais
du domaine.

**LM-601** — Un renommage de cohérence est souhaitable. Trois classes sont
concernées, avec des échéances distinctes :

| Classe | Défaut | Débloqué après |
|---|---|---|
| `RelayRouter` | Ne suit pas la convention `*Adapter` de ses voisins | étape 3 de `spec_ecs.md` |
| `EtmVariableLoadAdapter` | Préfixe `Etm` redondant dans un dépôt ETM | étape 3 de `spec_ecs.md` |
| `EvAdapter` | **Nommé d'après un domaine** (§2 range `Ev` en domaine) | **3g** |

`EvAdapter` n'est pas une classe de domaine égarée dans la couche mécanisme :
c'est un **adaptateur de mécanisme mal nommé**. Il parle à l'interface
`evcharger` de nymea — un mécanisme au même titre que `SgReady`. Le correctif est
un renom, pas un redécoupage.

Aucun de ces renommages ne se fait avant son échéance. Pour `RelayRouter`,
renommer juste avant la restructuration de `m_relayMapping` double le bruit dans
l'historique ; pour `EvAdapter`, le câblage lui-même change en 3g (l'adaptateur
n'est aujourd'hui pas dispatché), et renommer une classe dont le branchement va
bouger produit le même bruit pour rien.

`BatteryAdapter` n'entre pas dans ce tableau : LM-700 le traite hors moule.

---

## §7 — Cas hors moule

**LM-700 — Batterie.** Une batterie n'est pas une charge avec un rang : elle est
aussi une **source**, capable de financer les autres charges (grid-funding, 3f).
Elle intervient à un autre moment de la cascade et ne se modélise pas comme un
consommateur classé. Onduleur hybride et AC-coupling sont bien deux mécanismes.

**LM-701 — SmartHome.** Un cycle de lave-vaisselle ne se descend pas à 0 W en
cours de route : c'est un engagement pris au démarrage, pas un verrou `minOn`.
La sémantique d'action n'est pas une enveloppe en watts mais un **décalage
temporel** — démarrer maintenant ou plus tard. À traiter comme un type d'action
distinct, pas comme une variante.

---

## §8 — Points ouverts

1. `typeAppareil` — quelle énumération exacte, et jusqu'où elle affine le
   domaine. **A désormais un consommateur nommé** : c'est lui, et non `domain`,
   qui porterait l'avertissement de LM-200 (valeur *thermodynamique* = il y a un
   compresseur). Tant qu'il n'existe pas, l'avertissement n'a pas de prédicat.
2. Représentation persistée des facettes (§4) : imbriquées dans la charge, ou
   table séparée référençant la charge.
3. Sémantique d'action du SmartHome (LM-701) : à spécifier avant toute
   implémentation, elle ne se déduit pas du reste.
4. Rotation d'équité (LM-503) : politique à définir si le besoin se confirme.
5. **`heating` vs `hvac` — ce que ces deux codes désignent.** Question **ouverte, et
   volontairement non tranchée**. Elle ne se saura vraiment qu'en dessinant la **PAC
   communicante** (Alpha Innotec, Aquarea), où les consignes ECS et chauffage sont enfin
   **séparées** — donc où le canal de commande cesse d'être unique, et où LM-201 rend un
   verdict différent. D'ici là, `o:domain` **garde son rôle actuel** : grouper l'ordre de
   service, **sans force normative**. **Ne construire aucune règle dessus** — l'avertissement
   de LM-200 attend `typeAppareil` précisément pour cette raison.
   *(La question « le domaine doit-il devenir un discriminant de validation ? » est, elle,
   tranchée : non — avertissement, pas refus. Voir LM-200.)*

---

## §9 — Ce que ce document ne change pas

- L'ordre de `specs/spec_ecs.md` §2 et ses arbitrages bloquants.
- Les règles absolues 1 à 10 d'`AGENTS.md`.
- Le découpage en vigueur : le scheduler alloue, `RelayRouter` traduit.
- Rien dans le code aujourd'hui.