From 8864e6a56219af28de5e0d4aea4f40c14a37b1c9 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sat, 29 Aug 2026 10:48:47 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20l'=C3=A9cho=20verbatim=20passe=20sur=20?= =?UTF-8?q?marque=20fra=C3=AEche=20=E2=80=94=20et=20deux=20corrections=20m?= =?UTF-8?q?esur=C3=A9es?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit VERDICT SUR L'ÉCHO, sur une marque FRAÎCHE et sans rien déplacer avant : écho verbatim inchangé -> EnergyErrorNoError, configuration identique, marque survivante ; écho verbatim + un renommage ailleurs -> EnergyErrorNoError. Nos deux relevés contradictoires s'expliquent : le premier essai suivait le déplacement qui avait fait tomber la marque, l'app écrivait donc un "auto" que le persisté ne portait plus — cas de l'écho périmé, refus correct. sansRankOriginAuto() peut partir ; relire avant de réécrire le remplace. CORRECTION LOURDE — le brief promettait à l'app l'inverse de la vérité. « Supprimer l'entrée d'une borne dont le Thing existe encore la fait recréer au cycle suivant » est FAUX : mesuré sur .75, entrée retirée, Thing vivant, rien recréé en 140 s. syncAdapters() n'appelle provisionEvChargerConfig() que dans la branche !m_adapters.contains(id), et l'adaptateur est construit depuis le Thing — il survit à la suppression de l'entrée. Ce que ça produit est le trou de 3g-2 rouvert par le côté client : la borne reste ARBITRÉE mais ABSENTE de GetLoadConfig, à un rang de queue non réglable (evPriority() → 1000). Il ne se referme qu'au redémarrage de nymead. Un correctif est proposé — reprovisionner toute borne sans entrée, pas seulement à la naissance de l'adaptateur — et NON écrit : c'est un changement de comportement, la décision appartient à Patrick. LM-1209-d — le rang est un ordre TOTAL, les domaines ne le partitionnent pas. L'insertion en queue entrelace les domaines ; la contiguïté n'a jamais été un invariant et rien dans le moteur n'en a besoin. L'exiger serait CONTRADICTOIRE avec la raison même de LM-1209 : insérer une charge heating en respectant la contiguïté décalerait toutes les ev suivantes, soit une détection qui réordonne une installation qu'un humain a classée. Le même raisonnement vaut côté client : grouper à l'affichage oui, à l'écriture non — et la note d'entrelacement ne devrait pas être un avertissement, une liste entrelacée n'ayant rien d'incohérent. UN REFUS ARRIVE EN status: "success" — le verdict est dans params.energyError. Porté en tête d'INTERFACE.md avec l'extrait qui va bien : une sonde qui teste status annonce « accepté » sur une écriture rejetée, et une sonde qui se trompe de champ produit un relevé qui a l'air d'un résultat. Même famille que le journal lu par un sudo qui échoue en silence. Banc rendu intact : 5 charges, rangs 1-5, marque "auto" en place au rang 5. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p --- specs/spec_loadmodel.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md index 04e0928..e10201d 100644 --- a/specs/spec_loadmodel.md +++ b/specs/spec_loadmodel.md @@ -1369,6 +1369,38 @@ doit pas devenir un geste d'arbitrage.** Renuméroter pour « faire de la place l'ordre de service de charges auxquelles personne n'a touché — et le ferait sans qu'aucune décision d'exploitation ait été prise. +**LM-1209-d — Le rang est un ordre TOTAL ; les domaines ne le partitionnent pas.** *(Point +ouvert soulevé par l'agent app, tranché le 2026-08-29.)* + +L'insertion en queue entrelace les domaines — `ecs, ev, ev, heating, ev`. Faut-il que +l'insertion respecte la **contiguïté** d'un domaine, ou que le regroupement automatique côté +client cesse d'être automatique ? **La seconde.** + +**La contiguïté n'a jamais été un invariant, et rien dans le moteur n'en a besoin** : le +waterfall trie sur le **rang seul**, et `domain` est une métadonnée d'intention que l'arbitre ne +lit pas (LM-1101 · §3). La contiguïté est une convention d'**affichage**, inventée par le client. + +**Et l'exiger du moteur serait CONTRADICTOIRE avec la raison même de LM-1209**, pas seulement +avec sa condition « aucun autre rang ne bouge ». Insérer une charge `heating` en respectant la +contiguïté obligerait à décaler toutes les charges `ev` situées après — c'est-à-dire **une +détection qui réordonne une installation qu'un humain a classée**, exactement ce que LM-1209 +interdit. On ne peut pas invoquer LM-1209 pour la queue et l'enfreindre pour le regroupement. + +> **Le même raisonnement s'applique au CLIENT, et c'est le vrai point.** Un regroupement par +> domaine appliqué **à l'enregistrement** est aussi une machine qui réordonne ce qu'un humain a +> décidé — au pire moment, et sans que personne l'ait demandé. Il défait l'entrelacement +> délibéré (« l'ECS après la borne 1 mais avant la borne 2 » est un arbitrage légitime, et le +> §10 en produira d'autres), et il remonterait au rang 3 une borne que le moteur vient de ranger +> en queue. +> +> **Grouper à l'AFFICHAGE : oui. Grouper à l'ÉCRITURE : non.** Si le regroupement a de la +> valeur, il doit être un **geste explicite** de l'installateur — visible, réversible —, jamais +> une normalisation au moment de sauver. +> +> **Conséquence sur la note d'entrelacement** : elle ne doit pas s'énoncer comme un +> avertissement. Une liste entrelacée n'a rien d'incohérent ; l'annoncer comme un défaut pousse +> à « réparer » un ordre que personne n'a cassé. Au plus une **proposition**. + **LM-1209-c — Une entrée créée d'office DOIT se dire.** Une charge qui prend une place dans l'ordre de service sans que rien ne le signale est un **changement d'arbitrage silencieux**. Le journal l'annonce déjà ; cela ne suffit pas — l'app ne lit pas le journal, et c'est elle qui