Le plancher du soir vient de l energie a couvrir, plus d un niveau fixe

grep evcs_balance sur les deux workflows de decision renvoyait 0 depuis la mise
en service du bilan le 26/08 : il calculait l heure de croisement, l energie a
couvrir et le SOC requis, et personne ne l ecoutait. Le 03/09 a 19:44 les deux
nombres coexistaient dans le meme systeme — evening_soc_start_min a 85 %, un
niveau qui ne sait rien de la nuit, contre evcs_balance_required_soc a 99,7 %,
l energie a couvrir jusqu au croisement de 9 h. A SOC 94 le premier autorisait
la charge, le second disait que la batterie ne passerait pas la nuit seule.

Le plancher de demarrage du soir vaut desormais max(regle, bilan). Sens unique
delibere : le bilan peut durcir, jamais relacher. L assouplir — il dira souvent
moins de 85 % par forte prevision d ete — autoriserait des charges qui n ont pas
lieu aujourd hui, decision distincte a valider pour elle-meme. Le max rend au
passage la garde robuste sans borne ni ecretage : une valeur nulle, negative ou
aberrante ne peut pas relacher le plancher.

Portee demarrage : le plancher de maintien reste min(...), donc a 80 %, et
aucune charge en cours n est coupee. L abondance P6 continue de primer, etant
une preuve mesuree que la ressource depasse ce que le systeme absorbe.

Gardes : fraicheur inferieure a 30 min (six cycles du bilan), horodatage futur
rejete, statut ok, valeur finie. Sinon regle historique. Aucun nouveau toggle :
evcs_balance_enabled a OFF arrete les ecritures du bilan, balance_last_run se
fige, la fraicheur expire et le plancher retombe seul sur 85 % en une
demi-heure — un helper de plus aurait fait doublon.

Gabarit complet re-rendu contre HA : 195 champs, JSON valide, aucun null.
parseAdvisorRunToMs reutilise, l advisor et le bilan publiant le meme format.

Golden 66 -> 70. Quatre mutations — bilan ignore, Math.max remplace par une
affectation directe, garde de fraicheur supprimee, garde de statut supprimee —
font tomber chacune exactement un scenario, et un different a chaque fois.

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

docs/MANUEL_COMPLET.md

@@ -802,6 +802,39 @@ que la charge, en donnant un preneur au MPPT, detruirait sa propre autorisation
 — le bistable P6 du 24/08. Lectures indisponibles → repli sur le comportement
 anterieur. Golden 64 → 66. Detail : HANDOFF §37.
 
+#### E. Le plancher du soir etait un niveau, pas une energie (03/09/2026)
+
+`evening_soc_start_min` = 85 % tente de dire « garde de quoi passer la nuit ».
+C'est un NIVEAU, pris a un instant, qui ne sait rien de la nuit qui vient : ni
+sa duree, ni la consommation a couvrir, ni l'heure ou le solaire prendra le
+relais. Le bilan energetique calcule exactement cela depuis le 26/08 et le
+publie dans `input_number.evcs_balance_required_soc` — et **aucun des deux
+workflows de decision ne le lisait** (`grep evcs_balance` → 0).
+
+Le 03/09 a 19:44, SOC 94 % : le plancher fixe autorisait la charge, le bilan
+demandait 99,7 % pour tenir jusqu'au croisement de 9 h.
+
+Le plancher de demarrage du soir vaut desormais
+`max(evening_soc_start_min, evcs_balance_required_soc)`. **Sens unique
+delibere** : le bilan peut durcir, jamais relacher — l'assouplir en ete
+autoriserait des charges qui n'ont pas lieu aujourd'hui, decision distincte a
+valider pour elle-meme. Le `max` rend d'ailleurs la garde robuste sans borne :
+une valeur aberrante ne peut pas relacher le plancher.
+
+Gardes : fraicheur ≤ 30 min (six cycles du bilan), statut `ok`, valeur finie ;
+sinon regle historique. Pas de nouveau toggle — `evcs_balance_enabled` a OFF
+fige `balance_last_run`, la fraicheur expire, et le plancher retombe seul sur
+85 % en une demi-heure.
+
+Portee : demarrage. Le plancher de maintien reste a 80 %, donc aucune charge en
+cours n'est coupee. Golden 66 → 70, quatre mutations faisant tomber chacune
+exactement un scenario different. Detail : HANDOFF §38.
+
+⚠️ Le meme defaut subsiste sur l'autre bout de la nuit : `night_target_soc` est
+toujours deduit du TOTAL de la prevision du lendemain (paliers 35/55/85), aveugle
+a l'heure d'arrivee de l'energie — 35 % cote controleur contre 99,7 % cote bilan
+le 03/09.
+
 ⚠️ Point structurel mis au jour par cet incident : le bilan energetique publie
 l'heure de croisement, l'energie a couvrir, le SOC requis, `grid_needed` et
 `pv_censored` — et **aucun des deux workflows de decision n'en lit une seule