From cb8ac9dc6dc000c09bbae231531a08a03f406da2 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Fri, 28 Aug 2026 15:30:58 +0200 Subject: [PATCH] =?UTF-8?q?docs(spec=20=C2=A712):=20LM-1209=20=E2=80=94=20?= =?UTF-8?q?l'auto-provisionnement=20remplit=20un=20trou,=20il=20ne=20d?= =?UTF-8?q?=C3=A9cide=20pas?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Décision Patrick : insertion en queue, jamais en tête. Le rang est un choix de l'installateur ; une détection ne réordonne pas ce qu'un humain a décidé. Une borne détectée un mois après la mise en service passerait sinon devant l'ECS que quelqu'un a réglé exprès. La règle est écrite GÉNÉRALE — elle porte sur toute création d'entrée par le moteur, pas sur les seules bornes. Elle lève la tension apparente avec l'ordre par défaut « le VE d'abord » : ce défaut décrit une MISE EN SERVICE INITIALE, où personne n'a encore rien classé. Un ajout ultérieur est une autre situation — il existe un classement et il fait autorité. C'est la distinction qui manquait à la question. « En queue de son domaine » est précisé en `1 + max(rangs existants)`, parce que les domaines ne sont pas des blocs contigus : insérer juste après le dernier `ev` exigerait de pousser une charge d'un autre domaine, ce que LM-1209-b interdit. Et la queue de LISTE est ici plus fidèle au principe — max(domaine) ≤ max(liste) toujours, donc elle est toujours au moins aussi reculée, elle coïncide quand le domaine occupe la fin, et quand elle diverge elle place la nouvelle charge derrière tout le monde au lieu de l'intercaler devant une charge classée. LM-1209-a — l'unicité de rang, garantie plutôt que supposée. Avec une mise en garde qui corrige une lecture périmée : l'égalité ne coûte PAS l'indéterminisme. Depuis 3g-2 le waterfall trie sur (rang, identifiant), ordre total et reproductible ajouté précisément pour cela. Trois charges au rang 1 sont servies dans un ordre STABLE mais arbitraire et non réglable — il obéit à des identifiants, c'est-à-dire à personne. Exigence de gouvernabilité, pas de déterminisme ; s'y tromper ferait chercher le défaut au mauvais endroit. LM-1209-b — insérer ne renumérote personne, pendant exact de la suppression côté app : un geste de configuration ne doit pas devenir un geste d'arbitrage. LM-1209-c — la création doit se dire, et le journal ne suffit pas : l'app ne le lit pas, et c'est elle qui montre le classement. Même exigence que C2 de LM-1009 et LM-1106 — le régime se publie, il ne se déduit pas. La FORME du champ est laissée ouverte : à figer avant écriture. Aucun code. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p --- specs/spec_loadmodel.md | 64 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md index baa2228..4cd9b1c 100644 --- a/specs/spec_loadmodel.md +++ b/specs/spec_loadmodel.md @@ -1286,6 +1286,70 @@ consommation de la borne plutôt que de la sous-estimer. > dangereux que le défaut est crédible. La question « cette borne a-t-elle été préparée ? » doit > être POSABLE, pas déduite d'une valeur. +**LM-1209 — L'auto-provisionnement REMPLIT UN TROU, il ne décide pas.** *(Décision Patrick, +2026-08-28. La règle est générale : elle porte sur toute création d'entrée par le moteur, pas +sur les seules bornes.)* + +Une charge détectée par le moteur reçoit une entrée de configuration parce que **sans entrée +elle serait arbitrée sans rang réglable** — c'est le trou que l'auto-provisionnement referme. Il +ne s'ensuit rien sur sa PLACE : **le rang est un choix de l'installateur**, et une détection ne +réordonne pas ce qu'un humain a décidé. + +**Donc : insertion en QUEUE, jamais en tête.** Une borne détectée un mois après la mise en +service passerait sinon devant l'ECS que quelqu'un a réglé exprès — l'ancienneté d'un réglage +n'est pas une raison de le défaire, et la nouveauté d'une détection n'est pas une raison de la +servir en premier. + +> **Cela ne contredit PAS l'ordre par défaut « le VE d'abord »**, et c'est la distinction qui +> manquait à la question : ce défaut-là décrit une **mise en service initiale**, où personne n'a +> encore rien classé. Un **ajout ultérieur** est une situation différente — il existe un +> classement, et il fait autorité. Deux moments, deux règles, et les confondre revient à laisser +> le matériel réordonner l'installation. + +**Ce que « en queue » veut dire exactement : `1 + max(rangs existants)`.** Formulé d'abord comme +« en queue de son DOMAINE », il faut le préciser, parce que les domaines ne sont pas des blocs +contigus : rien n'empêche `ev` d'occuper les rangs 2 et 3 pendant qu'`ecs` tient 1 et 4. Insérer +« juste après le dernier `ev` » exigerait alors de pousser l'ECS du rang 4 — ce que LM-1209-b +interdit. + +> **Et la queue de LISTE est ici plus fidèle au principe que la queue de domaine**, ce qui règle +> la tension au lieu de l'arbitrer : `max(domaine) ≤ max(liste)` toujours, donc la queue de liste +> est **toujours au moins aussi reculée**. Quand le domaine occupe déjà la fin de la liste — le +> cas ordinaire d'un domaine qui ne grandit que par détection — les deux coïncident. Quand ils +> divergent, la queue de liste place la nouvelle charge **derrière tout le monde** au lieu de +> l'intercaler devant une charge classée : c'est exactement « remplir un trou sans décider ». + +**LM-1209-a — L'égalité de rang doit être IMPOSSIBLE, et le contrat doit la garantir plutôt que +la supposer.** + +`1 + max` produit un rang libre par construction, y compris sur une configuration héritée qui +contiendrait déjà des doublons. Mais la garantie ne peut pas reposer sur le seul chemin +d'insertion : une écriture cliente doit être **refusée** si elle pose deux charges au même rang. + +> ⚠️ **Ce que l'égalité coûte n'est PAS l'indéterminisme** — cette lecture est périmée depuis +> 3g-2, et s'y fier ferait chercher le défaut au mauvais endroit. Le waterfall trie sur le +> couple **`(rang, identifiant)`** (`rulebasedscheduler.cpp`), un ordre **total et reproductible** +> ajouté précisément parce que deux bornes à égalité rendaient irreproductible laquelle +> démarrait. Trois charges au rang 1 sont donc servies dans un ordre **stable** — mais **arbitraire +> et non réglable** : il obéit à des identifiants, c'est-à-dire à personne. C'est cela que +> l'unicité corrige, et c'est une exigence de gouvernabilité, pas de déterminisme. + +**LM-1209-b — Insérer ne renumérote personne.** Aucun autre rang ne bouge. C'est le pendant +exact de la suppression côté app, qui laisse les rangs en place : **un geste de configuration ne +doit pas devenir un geste d'arbitrage.** Renuméroter pour « faire de la place » modifierait +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-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 +montre le classement. La charge utile doit porter de quoi distinguer **« ce rang est un défaut »** +de **« ce rang est un choix »**. + +C'est la même exigence que C2 de LM-1009 et que LM-1106 : **le régime se publie, il ne se déduit +pas.** Un client ne peut pas deviner qu'un rang n'a jamais été choisi — rien dans le nombre ne le +dit. *(Forme du champ : voir la note de contrat, à figer avant écriture.)* + **LM-1207 — Ne PAS ajouter de `priority` à `ChargingInfo`.** Ce serait un **second système de priorité**, et il serait immédiatement insuffisant : il ne saurait pas exprimer **« VE1 > ECS > VE2 »**, puisqu'il ne classerait que les bornes entre elles. Deux classements