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é.
 
 ---