La provocation solaire se demande aux chargeurs, pas au SOC

Le correctif precedent bloque l incident de 19:44, mais un excedent proche de
zero est ambigu : c est la signature de la censure ET celle de l equilibre de
fin de journee. Le releve du 03/09 contient les deux avec le meme excedent —
18:50 : +14 W, ressource refusee ; 19:41 : +1 W, plus rien a donner. Rejeu du
19:41 : batteryAssistSolarStartOk etait encore vrai. Trois minutes avant
l incident, le systeme aurait commis la meme faute.

Le plan annoncait de lire evcs_balance_pv_censored. Lecture de CENSORSHIP.js :
ce drapeau est un OU de motifs dont l un est exactement le proxy qu on voulait
remplacer (socPct >= 90 et batterie sans puits). Et il est reste ON jusqu au
calcul de 19:50, soit cinq minutes APRES le demarrage de la charge — ce qui l a
fait basculer n est pas la censure mais sun_elevation passant sous 10 degres.
Il n aurait pas bloque l incident.

Le signal juste, ce sont les chargeurs eux-memes : sept entites
sensor.*_mppt_operation_mode, jamais lues par aucun workflow. mppt_active = je
suis a mon point de puissance maximale, je donne tout ; voltage_current_limited
ou off = je me retiens faute de preneur. Le 03/09 elles ont bascule a 19:20,
soit 24 minutes avant pv_censored, sans aucun proxy et a la cadence de la
boucle. Contre-verification le 01/09 a 14:22 : les trackers restaient limites
PENDANT une charge de 3,4 kW sous 6,9 kW de PV, donc le signal ne s auto-annule
pas a midi.

Collecte sans aucun entity_id code en dur (selectattr sur mppt et
operation_mode), expression testee sur /api/template puis gabarit complet
re-rendu : 191 champs, JSON valide, aucun null. Lectures inexploitables
ecartees, et repli sur le comportement anterieur quand il n en reste aucune.

Garde de DEMARRAGE uniquement, structurellement : la lier au sourceMode ou au
maintien ferait que la charge, en donnant un preneur au MPPT, detruirait sa
propre condition d autorisation — le bistable de l abondance P6 corrige le
24/08.

Golden 64 -> 66. Mutation dans trois directions : garde neutralisee -> 1 echec
cible, provocation toujours refusee -> 3 echecs, lecture illisible traitee
comme "a fond" -> 1 echec sur le scenario de repli.

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

docs/MANUEL_COMPLET.md

@@ -785,6 +785,23 @@ Golden 61 → 64, autour d'une paire de releves reels pris a 54 minutes d'ecart
 dont les lectures PV ne different que de **11 W** (769 puis 758) : le premier
 demarre, le second non — ce qui les separe est la maison. Detail : HANDOFF §36.
 
+**Complement du 03/09 au soir — un excedent nul est ambigu.** L'excedent proche
+de zero est la signature de la censure ET celle de l'equilibre de fin de
+journee : 18:50 (+14 W, ressource refusee) et 19:41 (+1 W, plus rien a donner)
+sont indiscernables par la puissance. Ce sont les **chargeurs eux-memes** qui
+tranchent : `sensor.*_mppt_operation_mode` vaut `mppt_active` quand le tracker
+donne tout, `voltage_current_limited` ou `off` quand il se retient. Sept
+entites, que ne lisait aucun workflow. Le 03/09 elles ont bascule a 19:20 —
+**24 minutes avant** le drapeau `pv_censored` du bilan (qui tourne toutes les
+5 min et dont l'un des motifs est justement le proxy SOC ≥ 90 qu'on cherchait a
+remplacer). La provocation `solar_potential` et l'assistance batterie exigent
+desormais qu'au moins un chargeur se retienne.
+
+⚠️ Garde de DEMARRAGE uniquement, structurellement : la lier au maintien ferait
+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.
+
 ⚠️ 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