OPENCLAW_ARCHIVE3_17/workspace/tests-pv/README.md

tests-pv — banc de test « gammes PV » de l'agent vocal

Garde-fou de la section « Repères énergie » d'AGENTS.md. À rejouer à CHAQUE modification de cette section : il vérifie que l'agent lit la bonne source, discrimine bridage / vraie baisse / substitution, décide (charge voiture, reste à capter) et reste propre sur des données abîmées (gel GX, capteur unavailable).

Lancer

node tests-pv/campagne-pv.mjs [passages=3] [--only=<id>]

• Extrait la section « Repères énergie » de la vraie AGENTS.md à l'exécution (donc teste la fiche DÉPLOYÉE, pas une copie).
• Envoie des snapshots FIGÉS de capteurs au modèle Spark (qwen3-coder), puis note sur N passages (>=3 : un run unique ne distingue pas 3/5 de 5/5).
• Écrit un journal journal-<horodatage>.json à côté du script.

Variables : SPARK_URL (défaut http://10.10.10.8:8000/v1/chat/completions), AGENTS_MD (défaut ../AGENTS.md).

Vérité-terrain

Snapshots et attendus = mesures RÉELLES fournies par le contrôleur EVCS (PostgreSQL/InfluxDB). Ne jamais inventer un attendu — cf. le bug des 4,2 kWh (extrapolation prise pour du réalisé). Statut de chaque cas :

Cas	Teste	Source
G1	production du jour = somme des 3 yield	réel
G2	reste à produire = prévision restante (seule exception)	réel
G3	bridage batterie pleine → lit evcs_pv_diagnostic=bridage_normal, ne rejuge pas	réel
G4	vraie baisse → evcs_pv_diagnostic=ressource_limitee	réel
G5	substitution → evcs_pv_diagnostic=substitution_edf, l'agent NE rejuge PAS	apprentissage (réel 27/08)
G6	charge voiture : excédent négatif → non	réel
G7	reste-t-il du solaire à capter	réel
G8	gel GX en journée → ne pas citer une valeur figée	synthétique hygiène
G9	yield unavailable → production partielle, ne pas sommer un trou	synthétique
G10	prévision de production DEMAIN (≠ réalisé du jour)	réel
G11	cellule la plus sensible → détail BMS unavailable (HA), le dire sans inventer	réel (HA cell down depuis 15/09)
G11b	cellule la plus sensible → identifier le plus grand déséquilibre	réel (relevé série EVCS)
G12	charge voiture nuit : faut-il de l'EDF ? surplus vs besoin, jamais soustraire un SOC	réel

Architecture (25/09/2026) : le JUGEMENT est sorti de la fiche vers des capteurs calculés côté service EVCS — sensor.evcs_pv_diagnostic (état + explication) et sensor.evcs_cellules (écart + module, ou statut perime/muet). L'agent LIT et RELAIE, il ne discrimine plus. Fraîcheur via sensor.evcs_historisation_heartbeat.

Cela a GUÉRI la fragilité : G3, G4, G5, G13b = 7/7 sur 7 passages (avant, un ajout anodin ailleurs faisait chuter G5 de 7/7 à 1/7). Dernier état (26/09) : réseau/EDF câblé — import du jour (evcs_import_jour_kwh, compteur EDF), import nuit (bilan_nuit.reseau_importe_kwh), état réseau (evcs_reseau : non_raccorde/mesure_muette/incoherent). Nouveaux cas 5/5. e2e E1–E8. Gmail déplacé en reference-gmail.md (garde-fous 4.6/4.7 gardés en fiche). Fiche 24 137 car (marge 5 863).

Banc bout en bout — e2e-attributs.mjs

campagne-pv.mjs injecte des snapshots directement : il teste le raisonnement, mais ne traverse pas l'outil de lecture airtria-ha-read.js. Un défaut de l'outil lui est donc invisible — c'est ainsi qu'un banc à 15/15 a coexisté avec un agent qui ne voyait aucun attribut en réel (le module de la cellule, trouvé à la main par le propriétaire le 25/09).

e2e-attributs.mjs bouche ce trou : il appelle le VRAI outil sur les VRAIES entités live et vérifie qu'un fait porté UNIQUEMENT par un attribut remonte (1) dans la sortie de l'outil, (2) dans la réponse du modèle. L'attendu est lu au moment du run via l'API HA (concordance, jamais une valeur figée).

node tests-pv/e2e-attributs.mjs [passages=3]

Cas : E1 module_le_plus_sensible (evcs_cellules), E2 source/raison contrôleur (evcs_charge_solaire), E3 statut (evcs_production_jour_kwh). Si l'outil n'expose pas la vérité, le banc l'affiche en clair — c'est le défaut qu'on veut attraper.