diff --git a/docs/DESIGN_MIN_RESEAU.md b/docs/DESIGN_MIN_RESEAU.md
index b3575f7..8fefa8b 100644
--- a/docs/DESIGN_MIN_RESEAU.md
+++ b/docs/DESIGN_MIN_RESEAU.md
@@ -230,3 +230,61 @@ Ce qu'il faudra pour lever la réserve, et c'est cumulatif :
    un compteur réel, parce que 2 kWc contre un plancher de 4 140 W ne le produira jamais.
 
 Les trois sont indépendantes, et aucune n'est à notre main aujourd'hui.
+
+## 9. Correction apportée par le brief app du 2026-09-07 — le plancher se DÉRIVE
+
+L'agent app a raison, et ça simplifie l'étape D. Pour une borne, la valeur du minimum **n'a
+besoin d'aucun champ** : elle est déjà sur la box, dans la classe du Thing.
+
+```
+maxChargingCurrent.minValue (6 A)  ×  phaseCount (3)  ×  230 V  =  4 140 W
+```
+
+**Conséquence de conception** : `minPowerWAlways` n'a pas à porter la valeur pour un VE — le
+**mode** est déjà l'interrupteur, et la valeur se dérive au moment de décider. Écrire la valeur
+dans le champ à l'appairage, comme l'étape D le proposait, créerait une **copie qui se périme** :
+un recâblage change le réglage `phaseCount`, et la valeur stockée resterait fausse sans que rien
+ne le dise. C'est la doctrine « une valeur dérivable est illégitime quand on la publie »,
+appliquée au **stockage**.
+
+**Le champ garde sa raison d'être pour les charges en watts** — un chauffe-eau à minimum permanent
+n'a pas de plancher matériel à dériver, il faut le déclarer. Les deux cas coexistent :
+
+| charge | d'où vient la valeur |
+|---|---|
+| borne VE | **dérivée** de `maxChargingCurrent.minValue × phaseCount` |
+| charge en watts | **déclarée** dans `needs.minPowerWAlways` |
+
+**Étape D révisée** : le mode `EcoWithMinCurrent` n'écrit rien ; il marque que la charge veut un
+minimum, et la passe éco dérive la valeur au cycle. Une seule source, jamais périmée.
+
+## 10. La piste « basculer en monophasé » — TRANCHÉE, et elle ne tient pas
+
+> « En monophasé le plancher tomberait à 1 380 W, et les 2 214 W du 6 septembre auraient suffi. »
+
+**Il n'existe aucun registre de phases dans la carte Modbus de la Trydan.** Constat de la campagne
+de portage, écrit dans le plugin lui-même (`integrationpluginv2c.cpp` l. 70-77) :
+
+> *« Il n'existe aucun registre de phases dans la carte Modbus V2C (0x0BC2-0x0BD5,
+> 0x177A-0x1783) : le câblage mono/tri n'est pas lisible sur la borne. »*
+
+La carte a été explorée entièrement. La borne ne sait pas **dire** son câblage, donc a fortiori
+elle n'offre rien pour le **changer**. `phaseCount` est un **réglage** — une déclaration de
+l'installateur sur le câblage physique, recopiée dans un état pour que le moteur la lise.
+
+### Et le danger, s'il fallait une raison de plus
+
+Baisser le réglage à 1 « pour faire tomber le plancher » serait un **mensonge sur le matériel**,
+et le plugin documente déjà l'effet dans le sens inverse : le moteur convertit les watts alloués
+en un courant, et un facteur de phases faux donne un courant faux.
+
+Déclarer 1 phase sur une borne câblée en 3 ferait budgéter 1 380 W et commander 6 A **sur trois
+phases** — soit **4 140 W tirés**. La borne démarrerait, au mauvais courant, **sans erreur**.
+
+> **Le réglage décrit le câblage ; il n'est pas un bouton de réglage du plancher.** Un champ qu'on
+> détourne pour son effet de bord est un champ qui ment, et celui-ci ment vers le haut, sur du
+> courant réel.
+
+**Ce qui reste vrai dans la piste** : sur une installation à petit surplus, une borne **câblée en
+monophasé** a un plancher de 1 380 W et se sert bien mieux. C'est une décision de **câblage à
+l'installation**, pas un réglage logiciel — et elle mérite d'être dite au dimensionnement.