diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md
index a71e80b..6015191 100644
--- a/docs/BRIEF_plugin_depuis_maquettes.md
+++ b/docs/BRIEF_plugin_depuis_maquettes.md
@@ -2,6 +2,37 @@
 
 ---
 
+## 2026-08-29 (suite) — l'insertion en queue casse la contiguïté des domaines
+
+**Constaté au premier auto-provisionnement réel** (`Simulated wallbox 2`, `.75`, `+etm27`).
+
+LM-1209 range la borne détectée en queue (`1 + max`), et c'est le bon choix : elle ne passe
+plus devant l'ECS que l'installateur a classé exprès. Mais l'ordre obtenu est :
+
+```
+rang 1  chauffe-eau          (ecs)
+rang 2  V2C Trydan           (ev)
+rang 3  Simulated wallbox    (ev)
+rang 4  PAC banc             (heating)
+rang 5  Simulated wallbox 2  (ev)   ← le domaine `ev` est coupé par `heating`
+```
+
+Le domaine `ev` est **entrelacé**, et l'app le signale — c'est la note posée le 2026-08-28,
+qui prévient que le premier enregistrement **regroupera** et changera donc l'ordre de
+service. Concrètement : la borne rangée en queue par le moteur remonterait au rang 3 au
+premier geste de l'installateur, sans qu'il l'ait demandé.
+
+Ce n'est pas un défaut de LM-1209 : c'est le prix de l'insertion en queue dès que la
+dernière charge n'est pas du même domaine, ce qui est le cas courant. **Trois lectures
+possibles**, et c'est au moteur de trancher : insérer en queue *du domaine* plutôt qu'en
+queue de liste ; assumer l'entrelacement et considérer que le regroupement de l'app est
+l'erreur ; ou déclarer que l'ordre à plat prime et que l'app ne doit pas regrouper.
+
+L'app ne changera rien tant que ce n'est pas tranché : elle regroupe pour afficher depuis le
+début, et elle prévient avant d'écrire.
+
+---
+
 ## 2026-08-29 — `rankOrigin` : un écho inchangé de `"auto"` passe-t-il ?
 
 **Une question, et le contournement posé en attendant.**
diff --git a/docs/UI_data_contract.md b/docs/UI_data_contract.md
index 4a2dd79..9bcf868 100644
--- a/docs/UI_data_contract.md
+++ b/docs/UI_data_contract.md
@@ -446,6 +446,30 @@ toutes les charges à chaque écriture, et le badge s'éteint sur une borne que
 classée, au premier renommage d'une autre charge. **Une information qui s'efface au premier
 geste voisin ne vaut pas d'être publiée.**
 
+### Constaté sur machine le 2026-08-29, et la forme du refus
+
+Une seconde wallbox simulée appairée après `+etm27` a produit les trois cas d'un coup :
+`rankOrigin: "auto"`, rang **5** (insertion en queue), badge sur elle seule.
+
+| Écriture | Réponse de la box | État après |
+|---|---|---|
+| renommage d'une AUTRE charge, `"auto"` renvoyé verbatim | `status: "success"` + `energyError: "EnergyErrorInvalidParameter"` | **inchangé** |
+| même renommage, `"auto"` → `""` (ce que fait l'app) | `EnergyErrorNoError` | **la marque est effacée** |
+| `"user"` sur la seule borne visée | `EnergyErrorNoError` | rang inchangé, seul ce champ change |
+| deux renommages voisins ensuite | `EnergyErrorNoError` | **`"user"` survit** |
+
+Le coût annoncé est donc réel et vérifié : le badge « rang posé par la box » a disparu d'une
+borne que personne n'avait classée, au renommage d'une autre charge. La fragilité ne touche
+que `"auto"` — `"user"`, lui, traverse les gestes voisins.
+
+> ⚠️ **Un refus arrive en `status: "success"`.** Le verdict est dans `params.energyError`,
+> et un contrôle sur `status` seul le prend pour un succès. Le service de l'app teste bien
+> les deux (`setLoadConfig`) — mais une sonde jetable écrite le jour même est tombée dans le
+> piège et a annoncé « ACCEPTÉ » sur une écriture que la box venait de rejeter. La raison
+> lisible, elle, ne sort **que** dans le journal de la box : *« la charge "Simulated wallbox
+> 2" prétend un rankOrigin "auto" que le moteur n'a pas posé »*. Côté RPC, il ne reste que
+> `EnergyErrorInvalidParameter`.
+
 ### Ce que ça impose à l'app, aujourd'hui
 
 Le nettoyage vit à un **point de sortie unique** (`NymeaService.setLoadConfig`), jamais sur