Sequence d ouverture : baisser le courant avant que le reseau parte

Le plafond majore (28 A en BOOST) n est legitime que tant que le reseau alimente
AC-IN : sinon les deux MultiPlus portent seuls la voiture plus la maison, le
mecanisme du W-105. Personne ne baissait avant l ouverture -- c est l hysteresis
qui ouvre, l EVCS l apprenait apres coup -- et quand il l apprenait, la reduction
attendait le cooldown de courant et descendait d un pas a la fois.

Correctif sans poignee de main ni helper nouveau : le plafond majore exige que
l EVCS DEMANDE lui-meme le reseau. Sa demande tombe au cycle ou la fenetre se
ferme (30 s), l hysteresis ne peut ouvrir qu ensuite (override disparu PUIS
min_on, cycle 1 min) : l EVCS baisse toujours avant, mecaniquement.

Second volet : un plafond n est pas une cible qu on approche. Reduction
immediate et directe au plafond, sans cooldown.

Le calcul du plafond a ete deplace apres sourceMode dans WINDOWS_SOURCEV2 ; rien
entre les deux ne le lisait, verifie avant de bouger.

Helper a 20 A par defaut : comportement inchange. Le correctif ne mord que sur
le BOOST 28 A, le cas dangereux.

Golden 48 -> 51, chaque cas apparie a son contrefactuel. Mutations des deux
volets separement : 1 puis 2 echecs cibles, restauration 51/51.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

HANDOFF.md

@@ -1951,3 +1951,78 @@ restant verts puisqu'ils n'en dépendent pas. Restauration → 48/48.
 
 ---
 *Document mis à jour le : 31/08/2026 (~18:20) — fenêtre d'établissement déployée dans src/, golden 48/48, PUT n8n en attente de validation*
+
+## 30. Session du 31/08/2026 (suite) — Séquence d'ouverture du contacteur
+
+### Le défaut, en deux morceaux
+Le plafond de courant EVCS majoré (P5, `input_number.evcs_plafond_courant_edf_on`,
+jusqu'à **28 A en BOOST**) n'est légitime que tant que le réseau alimente AC-IN :
+hors réseau, les deux MultiPlus portent seuls la voiture **plus** la maison.
+C'est le mécanisme du W-105 déjà consigné (§3, maintenance du 09/07).
+
+1. **Personne ne baissait avant l'ouverture.** C'est l'hystérésis (cycle 1 min)
+   qui ouvre le contacteur ; le contrôleur EVCS ne l'apprenait qu'après coup, via
+   `parsed.acInAvailable`. Les deux automates n'ont aucune poignée de main.
+2. **Et quand il l'apprenait, il ne baissait pas vite.** La branche
+   `charging_step_down_system_cap` de `DECISION_ENGINEV2` exigeait
+   `lifecycle.currentCooldownElapsed` — un compteur de **confort** — et ne
+   descendait que de `currentStepDownA` par cycle. De 28 A à 20 A : plusieurs
+   cooldowns. L'exposition ne se comptait donc pas en secondes mais en minutes.
+
+### Le correctif
+**Aucune poignée de main entre les deux automates, aucun helper nouveau.** Le
+plafond majoré exige désormais que **l'EVCS demande lui-même le réseau** :
+
+```js
+const evcsGridCeilingAllowed =
+  parsed.acInAvailable &&
+  (sourceMode === 'grid_forced' || sourceMode === 'grid_hc_allowed' || forceGridRequested);
+```
+
+L'ordonnancement devient mécanique : la demande de l'EVCS tombe au cycle où la
+fenêtre se ferme (30 s), alors que l'hystérésis ne peut ouvrir qu'**ensuite**
+(sa branche `turn_off_recovered` exige justement que l'override ait disparu, puis
+min_on écoulé, sur un cycle d'une minute). L'EVCS baisse donc toujours avant,
+sans que rien ne soit coordonné.
+
+⚠️ **Le calcul du plafond a été DÉPLACÉ après le calcul de `sourceMode`** dans
+`WINDOWS_SOURCEV2` (juste avant `const operatingMode = profile;`). Vérifié avant
+de bouger : `physicalCapA`, `canRunAtMinCurrent` et les quatre variables
+intermédiaires n'étaient utilisés qu'à leur définition et dans l'export — rien
+entre les deux ne les lisait. Ne pas les remonter.
+
+Second volet, dans `DECISION_ENGINEV2` : **un plafond n'est pas une cible qu'on
+approche, c'est une limite qu'on respecte.** La réduction ne dépend plus du
+cooldown et descend directement au plafond (`decision: 'step_down_fast'`, valeur
+déjà utilisée par la branche surcharge). Réduire est toujours sûr ; c'est la
+montée qui doit être temporisée, et elle l'est.
+
+### Portée réelle, et ce qui reste exposé
+Avec le helper à sa valeur par défaut (20 A), **le comportement est strictement
+inchangé** : le plafond valait déjà 20 A dans les deux branches. Le correctif ne
+mord que sur le BOOST 28 A, c'est-à-dire exactement le cas dangereux.
+
+Reste irréductible : une ouverture **manuelle** (EDF URGENCE) ou une perte
+physique du réseau ne se laissent pas anticiper. L'exposition y passe de
+plusieurs minutes à **≤ 30 s plus le temps de rampe de la borne**, ce qui est le
+minimum atteignable sans signal matériel.
+
+### Golden 48 → 51
+| scénario | attendu |
+|---|---|
+| `ouverture-plafond-tombe-hors-demande-reseau` (AC-IN présent, BOOST 28, matin solaire, cooldown NON écoulé) | `charging_step_down_system_cap` → **20 A immédiatement** |
+| `ouverture-plafond-maintenu-en-demande-reseau` (CONTREFACTUEL, `force_grid_now`) | `charging_hold_grid` **28 A**, BOOST préservé |
+| `ouverture-reseau-disparu-reduction-immediate` (AC-IN absent, cooldown non écoulé) | réduction immédiate à 20 A |
+
+Preuve par mutation, les deux volets séparément :
+- plafond majoré reconditionné au seul `acInAvailable` → 1 échec ciblé ;
+- réduction remise sous `currentCooldownElapsed` → 2 échecs ciblés ;
+- restauration → 51/51.
+
+### Suite
+3. priorité solaire pour la voiture à batterie pleine (coût marginal nul :
+   6-7 trackers sur 7 bridés = ressource refusée) et interdiction de fermer le
+   contacteur pour charger une voiture en journée batterie pleine (~150 Wh).
+
+---
+*Document mis à jour le : 31/08/2026 (~19:00) — séquence d'ouverture corrigée, golden 51/51, PUT n8n en attente de validation*