From 909cfc5c1e498f5f00a34f18a564f80a9d3417ef Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sat, 29 Aug 2026 12:50:01 +0200 Subject: [PATCH] =?UTF-8?q?docs(=C2=A710):=208.2=20et=208.4=20tranch=C3=A9?= =?UTF-8?q?s,=208.5=20pos=C3=A9e=20=C3=A0=20l'agent=20app?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Quatre des cinq points du §10 sont désormais tranchés. 8.2 : le plafond §14a porte les deux formes — par phase et au total — sans jamais convertir. 8.4 : la cible de confort reste un comparateur, le dosage attendant le modèle thermique du §11. Confirmations, rien de rouvert. 8.5 reste, et il ne se tranche pas ici : c'est l'ordre de service APPARENT. Un plancher éco de rang 4 passe devant un confort de rang 1 — voulu, lexicographique sur (niveau, rang), et contre-intuitif pour l'installateur qui vient de poser son ordre. La question est POSÉE à l'agent app dans le brief §9, pas répondue. Trois choses lui sont données pour décider : sur quoi la liste est ordonnée — par rang, et l'ordre affiché n'est plus l'ordre de service, ce qu'il faut dire ; ou par ordre de service, et le rang cesse d'être lisible. Une entrée par passe ou une entrée à deux états. Et ce qu'on voit d'une charge dont l'éco est servi et le confort non — le cas le plus fréquent, et le seul qui n'ait AUCUN équivalent aujourd'hui : la télémétrie publie un motif et une allocation, un seul de chaque. Ce qui lui est demandé est de dire quelle FORME DE PUBLICATION rendrait l'écran possible, comme la maquette des mécanismes l'a fait pour les six écrans — pas de câbler quoi que ce soit, le §10 n'étant pas implémenté. Deux garde-fous joints pour que la réponse ne se ferme pas sur un détail : une charge reçoit une SEULE commande par cycle quelles que soient les passes (LM-1003), et le rang reste UN — pas de prioritéEco/prioritéConfort, rejet explicite de LM-1002. Et la conséquence est écrite des deux côtés : le §10 ne se code pas avant cette réponse. Commencer par le moteur reviendrait à inventer une charge utile puis à demander à l'écran de s'en arranger, c'est-à-dire l'ordre inverse de celui qui a marché. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p --- AGENTS.md | 17 ++++++--- docs/BRIEF_depuis_plugin.md | 71 ++++++++++++++++++++++++++++++++++++- docs/DESIGN_10.md | 32 +++++++++++++---- 3 files changed, 108 insertions(+), 12 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 085a4d5..d413c74 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -328,10 +328,19 @@ actifs. **PROCHAINE ACTION** : rien de tranché en attente. -**§10 — OUVERT.** Le design est écrit : **`docs/DESIGN_10.md`**, à valider avant tout code. Il -porte l'ordre de travail en cinq étapes (dont deux à comportement constant, qui rendent le reste -petit) et **cinq points à trancher**, dont trois ne sont pas techniques — le premier étant : la -réserve batterie annule-t-elle aussi la passe éco ? +**§10 — UN SEUL POINT OUVERT, ET IL EST CHEZ L'APP.** Le design est écrit : +**`docs/DESIGN_10.md`**. Sur les cinq points à trancher, **quatre le sont** — réserve batterie +(8.1), repli dégradé (8.3), plafond §14a portant les deux formes sans conversion (8.2), cible de +confort en comparateur (8.4). + +Reste **8.5 — l'ordre de service apparent** : un plancher éco de rang 4 passe devant un confort +de rang 1, ce qui est voulu et aura l'air d'un bug. **Question posée à l'agent app** le +2026-08-29, `docs/BRIEF_depuis_plugin.md` §9 — sur quoi la liste est ordonnée, une entrée ou +deux par charge, et ce qu'on voit d'une charge dont l'éco est servi et le confort non. + +> ⚠️ **Le §10 ne se code pas avant cette réponse.** La troisième question n'a aucun équivalent +> dans la télémétrie d'aujourd'hui — un motif, une allocation, un seul de chaque. Commencer par +> le moteur reviendrait à inventer une charge utile puis à demander à l'écran de s'en arranger. Deux notes de conception le contraignent, à relire avant de coder : **LM-1006-1** (le délestage est un plafond de soutirage à trois sources) et **LM-1009** diff --git a/docs/BRIEF_depuis_plugin.md b/docs/BRIEF_depuis_plugin.md index cfb296d..c1f55a9 100644 --- a/docs/BRIEF_depuis_plugin.md +++ b/docs/BRIEF_depuis_plugin.md @@ -5,7 +5,8 @@ **Contexte** : `docs/RELEVE_3g2.md` (ce dépôt) porte les traces machine, cycle par cycle. **Contrat** : `INTERFACE.md` fait autorité — ce brief ne fait qu'en signaler les mouvements. -> Huit points. Le sixième répond à vos quatre constats du 28 août, le septième à votre +> Neuf points. Le NEUVIÈME est une QUESTION, pas une réponse : le dernier point ouvert +> du §10 se tranche chez vous, à partir de l'écran. Le sixième répond à vos quatre constats du 28 août, le septième à votre > constat d'usage sur le compteur par charge — et celui-là **bouge un champ du contrat**. > Le deuxième **retire une mise en garde** que vous portiez — du code conditionnel > peut disparaître. Le cinquième répond à **votre** question sur `targetPercentage`, et c'est @@ -485,6 +486,74 @@ en produira d'autres — et remonterait au rang 3 une borne que le moteur vient --- +## 9. UNE QUESTION POUR VOUS — l'ordre de service apparent, quand le §10 arrivera + +*(Point 8.5 de `docs/DESIGN_10.md`, dernier point ouvert du lot. `spec_loadmodel.md` LM-1002 et +LM-1006. **Rien à câbler** : le §10 n'est pas implémenté, et il ne le sera pas avant que cette +question soit tranchée — c'est une condition de livraison, pas une suite.)* + +**Ce n'est pas à nous d'y répondre.** Ce que nous vous demandons est du même ordre que la +maquette des mécanismes pour les six écrans : **dire quelle forme de publication rendrait +l'écran possible.** Nous fabriquerons ensuite la charge utile qui la sert. + +### Le fait qui produit le problème + +Le §10 donne deux niveaux de besoin à une charge : **éco** (le minimum vital — un ballon doit +voir 50 °C, une PAC ne doit pas geler) et **confort** (le reste). L'arbitre fera **deux passes +sur la MÊME liste, dans le MÊME ordre** : + +``` +passe 1 — ÉCO : parcourir les charges par rang croissant, servir leur plancher éco +passe 2 — CONFORT : reparcourir la MÊME liste, dans le MÊME ordre, avec le reliquat +``` + +Le rang garde un sens unique — l'ordre de service posé par l'installateur. La hiérarchie +éco/confort le **surplombe** : elle dit *quel besoin* passe avant, jamais *quelle charge*. + +**Et voici la conséquence, qui est voulue et qui aura l'air d'un bug** : + +> **le plancher éco d'une charge de rang 4 est servi AVANT le confort d'une charge de rang 1.** + +Formellement c'est un ordre lexicographique sur `(niveau, rang)` — total, dérivé du rang +existant, pas un second système de priorité. Vu de l'écran, c'est un installateur qui vient de +poser son ordre et voit le moteur ne pas le suivre. **Sans un écran qui montre les deux passes, +le premier retour terrain sera « l'ordre n'est pas respecté ».** + +### Les trois choses à trancher + +**1. Sur quoi la liste est-elle ordonnée ?** Les deux réponses coûtent quelque chose, et il faut +choisir laquelle : +- **par RANG** — l'ordre affiché n'est alors plus l'ordre de service, et il faut le **dire** à + l'écran ; sinon la liste ment par omission ; +- **par ORDRE DE SERVICE effectif** — le rang cesse d'être lisible dans la liste, alors que + c'est le seul champ que l'installateur règle. + +**2. Une charge apparaît-elle une fois ou deux ?** Une entrée par passe — la même charge à deux +endroits de la liste — ou **une seule entrée portant deux états** ? + +**3. Que voit-on d'une charge dont l'éco est servi et le confort non ?** C'est le cas **le plus +fréquent** en régime normal, et **il n'a aucun équivalent aujourd'hui** : la télémétrie actuelle +publie une allocation et un motif par charge, un seul de chaque. Ni « servie à moitié », ni +« servie pour son minimum, en attente pour le reste » ne sont exprimables. + +### Ce dont vous disposez pour décider + +Aujourd'hui `GetLoadTelemetry` publie **par charge** : `allocatedW`, `funding`, `available`, +`decision {code, params}`, `measurement {source, powerW}`, `mechanism`, `lock`. **Un seul motif, +une seule allocation.** Tout ce qui distinguerait les deux passes reste à inventer — un second +couple, un niveau sur le motif, une entrée dédoublée : **c'est précisément ce que nous vous +demandons de nommer**, en partant de l'écran et non de la charge utile. + +> **Deux garde-fous, pour que la réponse ne se ferme pas sur un détail** : +> - **Une charge reçoit UNE SEULE commande par cycle** (LM-1003), quelles que soient les passes. +> Deux passes ne veulent pas dire deux consignes ; si l'écran montre deux lignes, elles +> décrivent une seule décision. +> - **Le rang reste UN**, et il n'y aura jamais de `prioritéEco`/`prioritéConfort` (LM-1002, +> rejet explicite) : deux classements à tenir cohérents dans la tête d'un installateur, c'est +> la chose que le modèle refuse. + +--- + ## Ce qui n'a PAS changé, et qu'il ne faut pas déduire - **L'échéance de départ et le tarif dynamique restent au proxy**, financés au réseau diff --git a/docs/DESIGN_10.md b/docs/DESIGN_10.md index b15f4be..554b798 100644 --- a/docs/DESIGN_10.md +++ b/docs/DESIGN_10.md @@ -8,9 +8,14 @@ notes qui contraignent la forme : **LM-1006-1** (le plafond de soutirage) et **L deux régimes d'échéance). > **Ce document ne demande pas si le §10 doit se faire. Il dit sous quelle forme, et nomme les -> points qui demandent une décision** — §8. **Deux sont tranchés** (2026-08-27) : la réserve -> batterie n'annule pas l'autorisation de soutirage, et le repli dégradé ne concerne pas ce lot. -> Trois restent ouverts. +> points qui demandent une décision** — §8. **Quatre sont tranchés.** 2026-08-27 : la réserve +> batterie n'annule pas l'autorisation de soutirage (8.1), et le repli dégradé ne concerne pas ce +> lot (8.3). 2026-08-29 : le plafond §14a porte **les deux** formes — par phase et au total — +> sans jamais convertir (8.2), et la cible de confort reste un **comparateur**, le dosage +> attendant le modèle thermique du §11 (8.4). +> +> **Un seul reste ouvert, et il est chez l'app** : 8.5, l'ordre de service apparent. Question +> posée le 2026-08-29 dans `docs/BRIEF_depuis_plugin.md` §9. --- @@ -295,10 +300,23 @@ mis à jour en conséquence : **le §10 n'a rien à faire de ce côté.** (`sonde < consigne` → demandeuse), le dosage attend le modèle thermique du §11. **À confirmer que ça reste vrai pour ce lot**, parce que c'est ce qui le rend faisable sans historique. -**8.5 — Que fait l'app des deux passes ?** LM-1006, couplage 2 : un plancher éco de rang 4 passe -devant un confort de rang 1, et c'est **contre-intuitif** pour l'installateur qui vient de poser -son ordre. Sans écran qui montre les deux passes, le premier retour terrain sera « l'ordre n'est -pas respecté ». Ce n'est pas du travail moteur, mais c'est une condition de livraison du lot. +**8.5 — Que fait l'app des deux passes ? POSÉE À L'AGENT APP le 2026-08-29**, et c'est le +dernier point ouvert du lot. LM-1006, couplage 2 : un plancher éco de rang 4 passe devant un +confort de rang 1 — voulu, et **contre-intuitif** pour l'installateur qui vient de poser son +ordre. Sans écran qui montre les deux passes, le premier retour terrain sera « l'ordre n'est pas +respecté ». Ce n'est pas du travail moteur, mais c'est une **condition de livraison**. + +La question est formulée en `docs/BRIEF_depuis_plugin.md` §9, avec les trois choses à trancher — +sur quoi la liste est ordonnée, une entrée ou deux par charge, et ce qu'on voit d'une charge dont +l'éco est servi et le confort non. **Le moteur ne répond pas à sa place** : ce qui lui est demandé +est de dire quelle forme de publication rendrait l'écran possible, comme la maquette des +mécanismes l'a fait pour les six écrans. La charge utile suivra. + +> ⚠️ **Tant qu'elle n'est pas tranchée, le §10 ne se code pas.** Ce n'est pas une dépendance +> molle : la troisième question — une charge dont l'éco est servi et le confort non — n'a +> **aucun équivalent** dans la télémétrie d'aujourd'hui, qui publie un motif et une allocation, +> un seul de chaque. Commencer par le moteur reviendrait à inventer une charge utile puis à +> demander à l'écran de s'en arranger, c'est-à-dire l'ordre inverse de celui qui a marché. ---