diff --git a/docs/DESIGN_10.md b/docs/DESIGN_10.md
index b9cf9d0..6aa8671 100644
--- a/docs/DESIGN_10.md
+++ b/docs/DESIGN_10.md
@@ -231,32 +231,11 @@ une entrée de clôture (`testDecisionReasonRendering`).
 |---|---|---|
 | `DRAW_CAP` | `capW`, `source`, `requiredW`, `o:phase` | Le plafond de soutirage refuse, et **`source` dit lequel** : raccordement, gestionnaire de réseau, ou auto-imposé. `phase` présent si c'est une phase qui borne. **Réservé à l'autorisation résiduelle NULLE** — voir la précédence ci-dessous. |
 
-**PRÉCÉDENCE `DRAW_CAP` ↔ `BELOW_MIN_POWER` — tranchée le 2026-08-29 (Patrick), sur une question
-de l'agent app.**
-
-Autorisation résiduelle **non nulle mais inférieure au plus petit palier** du mécanisme :
-**`BELOW_MIN_POWER`**. Les deux motifs sont vrais, mais pas au même niveau.
-
-`DRAW_CAP` dit « **il n'y a plus d'autorisation** ». Or il en reste — simplement **pas au bon
-format**. C'est exactement la distinction posée en `+etm19` entre `SURPLUS_INSUFFICIENT` (« il
-n'y a rien ») et `BELOW_MIN_POWER` (« il y en a, mais pas au bon format »), **transposée telle
-quelle au soutirage** : ce n'est pas une règle nouvelle, c'est la même appliquée à une seconde
-ressource.
-
-**Ce qui la décide est le GESTE qu'elle appelle** — la règle 7-b : un motif faux envoie
-diagnostiquer le mauvais problème, avec l'autorité d'une explication.
-
-| Motif | Ce qu'il dit | Le geste utile |
-|---|---|---|
-| `DRAW_CAP` | l'autorisation est **épuisée** | revoir le plafond, ou attendre |
-| `BELOW_MIN_POWER` | il reste de l'autorisation, **la charge ne sait pas la prendre** | lire la fiche technique du mécanisme |
-
-> **Conséquence sur le « point de rupture » de l'écran 2** : il est bien un `DRAW_CAP`. Une
-> charge refusée **après** lui pour cause de palier porte `BELOW_MIN_POWER` et **ne déplace pas**
-> le point de rupture — elle est en aval de la coupure, pas la coupure elle-même.
->
-> **La règle est écrite ICI, une fois, par le moteur** — pas établie de chaque côté de la
-> frontière. Deux précédences dérivées séparément divergeraient au premier motif ajouté.
+**PRÉCÉDENCE `DRAW_CAP` ↔ `BELOW_MIN_POWER`** — tranchée le 2026-08-29, et son domicile est
+`specs/spec_loadmodel.md` **LM-1011**, pas ici : une note de conception se périme, la spec fait
+autorité. En un mot : autorisation résiduelle **non nulle mais sous le plus petit palier** →
+`BELOW_MIN_POWER` ; `DRAW_CAP` réservé au résiduel **nul**. Le point de rupture de l'écran 2 est
+ancré sur le `DRAW_CAP`.
 
 **RÉPONSE À R4 — ce que les compteurs de budget comptent : le DÉCIDÉ.** *(Question de l'agent
 app, 2026-08-29.)*
diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md
index b0eb1e8..25963b4 100644
--- a/specs/spec_loadmodel.md
+++ b/specs/spec_loadmodel.md
@@ -850,6 +850,35 @@ se déduit.
 > La maquette **vaut comme contrat, pas comme feuille de route** : elle fixe la forme de ce qui
 > sera publié, pas une date. Et côté app, rien ne commence avant que `levels[]` soit en ligne.
 
+**LM-1011 — `BELOW_MIN_POWER` prime sur `DRAW_CAP` dès qu'il reste de l'autorisation.**
+*(Précédence tranchée par Patrick le 2026-08-29, sur une question de l'agent app. Écrite ICI,
+une fois, pour qu'aucun côté de la frontière ne l'établisse pour son compte.)*
+
+Autorisation résiduelle **non nulle mais inférieure au plus petit palier** du mécanisme :
+**`BELOW_MIN_POWER`**. `DRAW_CAP` reste réservé à l'autorisation résiduelle **nulle**.
+
+Les deux motifs sont vrais, mais pas au même niveau. `DRAW_CAP` dit « **il n'y a plus
+d'autorisation** » — or il en reste, simplement **pas au bon format**.
+
+**Ce n'est pas une règle nouvelle : c'est celle de `+etm19`, transposée à une seconde
+ressource.** Le surplus l'a déjà : `SURPLUS_INSUFFICIENT` dit « il n'y a rien »,
+`BELOW_MIN_POWER` dit « il y en a, mais pas au bon format ». Le soutirage hérite du même couple,
+et il aurait été absurde qu'une ressource se lise autrement que l'autre.
+
+**Ce qui décide n'est pas la véracité, c'est le GESTE que le motif appelle** — règle 7-b : un
+motif faux envoie diagnostiquer le mauvais problème, avec l'autorité d'une explication.
+
+| Motif | Ce qu'il dit | Le geste utile |
+|---|---|---|
+| `DRAW_CAP` | l'autorisation est **épuisée** | revoir le plafond, ou attendre |
+| `BELOW_MIN_POWER` | il en reste, **la charge ne sait pas la prendre** | lire la fiche technique du mécanisme |
+
+> **Conséquence retenue de l'agent app** : le **point de rupture** de l'écran « ordre de service
+> du cycle » est **ancré sur le `DRAW_CAP`**, donc sur l'épuisement réel. Une charge refusée
+> **après** lui pour cause de palier porte `BELOW_MIN_POWER` et **ne déplace pas** ce point :
+> elle est en aval de la coupure, elle n'est pas la coupure. Sans cette précédence, deux charges
+> successives auraient produit deux points de rupture concurrents dans le même cycle.
+
 **LM-1007 — Compatibilité descendante, et elle est gratuite.** Une charge qui ne déclare
 **aucun** besoin éco ne participe qu'à la passe 2 — soit exactement le comportement
 d'aujourd'hui. Le modèle à deux niveaux **dégrade proprement** vers le modèle actuel, ce qui