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

tests/golden/scenarios.mjs

@@ -903,6 +903,7 @@ export const scenarios = [
       soc_percent: '95', pv_power_w: '430', pv_power_10m_avg_w: '430',
       pv_trend_w: '0', battery_current_a: '2',
       house_ac_power_w: '400', vebus_ac_out_l1_power_w: '400',
+      mppt_operation_modes: 'voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited',
     },
     expect: {
       profile: 'outside_window',
@@ -936,6 +937,7 @@ export const scenarios = [
       pv_power_w: '769.1', pv_power_10m_avg_w: '800', pv_trend_w: '0',
       house_ac_power_w: '755', vebus_ac_out_l1_power_w: '755',
       evcs_ac_power_w: '0',
+      mppt_operation_modes: 'voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited,voltage_current_limited',
     },
     expect: {
       profile: 'evening_high_soc',
@@ -991,6 +993,56 @@ export const scenarios = [
     },
   },
 
+  // ===== 03/09/2026 : la provocation doit etre justifiee par les chargeurs =====
+  // Un excedent proche de zero est AMBIGU. Meme releve, meme excedent, deux
+  // situations opposees a 51 min d'ecart le 03/09 :
+  //   18:50  excedent +14 W, trackers LIMITES     -> ressource refusee, on y va
+  //   19:41  excedent  +1 W, trackers MPPT_ACTIVE -> plus rien a donner, on reste
+  // Aucun seuil de puissance ne les separe ; les chargeurs, eux, le disent.
+  {
+    id: 'provocation-trackers-a-fond-ne-demarre-pas',
+    label: "Relevé du 03/09 19:41 : excédent +1 W (équilibre au crépuscule), SOC 94, mais les 7 trackers en mppt_active → plus rien à révéler → PAS de provocation",
+    time: '2026-08-08T19:41:00+02:00',
+    overrides: {
+      evcs_vehicle_connected: 'on', evcs_device_connected: 'on',
+      soc_percent: '94', battery_current_a: '-1.4',
+      pv_power_w: '816.9', pv_power_10m_avg_w: '850', pv_trend_w: '0',
+      house_ac_power_w: '816', vebus_ac_out_l1_power_w: '816',
+      evcs_ac_power_w: '0',
+      mppt_operation_modes: 'mppt_active,mppt_active,mppt_active,mppt_active,mppt_active,mppt_active,mppt_active',
+    },
+    expect: {
+      profile: 'evening_high_soc',
+      state: 'idle_wait_conditions',
+      decision: 'hold',
+      desiredCharging: false,
+    },
+  },
+
+  {
+    // Le repli doit etre sur le comportement ANTERIEUR, jamais sur une
+    // supposition : integration muette => on ne sait pas => on autorise comme
+    // avant. Meme releve que ci-dessus, seules les lectures changent.
+    id: 'provocation-trackers-illisibles-comportement-anterieur',
+    label: "Même relevé, mais chargeurs illisibles (unavailable) → on ne sait pas → repli sur le comportement antérieur, la charge démarre",
+    time: '2026-08-08T19:41:00+02:00',
+    overrides: {
+      evcs_vehicle_connected: 'on', evcs_device_connected: 'on',
+      soc_percent: '94', battery_current_a: '-1.4',
+      pv_power_w: '816.9', pv_power_10m_avg_w: '850', pv_trend_w: '0',
+      house_ac_power_w: '816', vebus_ac_out_l1_power_w: '816',
+      evcs_ac_power_w: '0',
+      mppt_operation_modes: 'unavailable,unknown,',
+    },
+    expect: {
+      profile: 'evening_high_soc',
+      state: 'start_min_current',
+      decision: 'start',
+      desiredCharging: true,
+      currentA: 6,
+    },
+  },
+
   // ===== 01/09/2026 : le depassement souple de la batterie doit DURER =====
   // Incident du 01/09 (14:26 et 14:56) : SOC 94, batterie en float, courant
   // oscillant entre +1,8 et -2,6 A d'un echantillon a l'autre. Le controleur