last_reported ne sauve pas last_changed : la vivacite appartient au battement de coeur seul

En outillant la session OpenClaw, recherche du champ qui distinguerait « pas
ecrit » de « ecrit a l identique ». Home Assistant expose last_reported depuis
2024, cense marquer chaque remontee d etat meme sans changement de valeur. Il ne
sert a rien ici : mesure sur cinq entites, il est rigoureusement EGAL a
last_changed, alors que le controleur reecrit source_mode et night_target_soc a
chaque cycle de 30 s.

Consequence generale : aucun champ de l API ne distingue un ecrivain mort d un
ecrivain qui republie la meme valeur. L anciennete d une entite metier n est
donc jamais une preuve de panne. Releve sur une installation saine :
vehicle_connected inchange depuis 752 min, night_target_soc 194, source_mode
139 — trois faux positifs sur cinq entites.

Regle adoptee avec OpenClaw : la vivacite se lit sur un battement de coeur dedie
dont l etat est un horodatage, seule entite dont l immobilite soit
interpretable. Les entites metier se lisent pour leur VALEUR, jamais pour leur
fraicheur. « inchange depuis X » est un fait, « fige » est un verdict.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj

HANDOFF.md

@@ -2202,6 +2202,33 @@ contrôleur tournait normalement (`charging_hold_grid` stable depuis 02:12, et l
 raison tronquée à 255 caractères perdait justement les champs variables). Un
 helper HA est un mauvais battement de cœur.
 
+⚠️ **COMPLÉTÉ LE 16/09/2026 — et c'est pire que « un mauvais battement de
+cœur ».** En outillant la session OpenClaw j'ai cherché le champ qui
+distinguerait « pas écrit » de « écrit à l'identique ». Home Assistant expose
+`last_reported` depuis 2024, précisément censé marquer chaque remontée d'état
+même sans changement de valeur. **Il ne sert à rien ici** : mesuré sur cinq
+entités, il est rigoureusement ÉGAL à `last_changed`. Or le contrôleur réécrit
+`source_mode` et `night_target_soc` à chaque cycle de 30 s (`execute: true`,
+inconditionnel) — Home Assistant ne matérialise tout simplement pas une écriture
+identique, sur aucun des deux horodatages.
+
+**Conséquence générale : aucun champ de l'API ne permet de distinguer un
+écrivain mort d'un écrivain qui republie la même valeur.** L'ancienneté d'une
+entité métier n'est donc JAMAIS une preuve de panne, et un système stable
+produit des entités immobiles par construction. Relevé à 08:15 sur une
+installation parfaitement saine : `vehicle_connected` inchangé depuis 752 min
+(la voiture est branchée depuis la veille 19:43), `night_target_soc` depuis
+194 min (hors session de nuit, la cible n'a plus de raison de bouger),
+`source_mode` depuis 139 min (la voiture est pleine, le système reste en
+« Bloqué »). Trois faux positifs sur cinq entités.
+
+**Règle qui en découle, adoptée avec la session OpenClaw : la vivacité se lit
+sur un battement de cœur DÉDIÉ dont l'état est un horodatage — la seule entité
+dont l'immobilité soit interprétable, parce que sa valeur change forcément à
+chaque écriture. Les entités métier se lisent pour leur VALEUR, jamais pour leur
+fraîcheur.** Et en vocabulaire : « inchangé depuis X » est un fait, « figé » est
+un verdict ; ne pas transformer le premier en second.
+
 Signal retenu : **l'API d'exécutions de n8n**
 (`GET /api/v1/executions?workflowId=...&limit=3`). Elle prouve que la boucle
 s'exécute, et son absence couvre indifféremment « n8n arrêté », « NAS éteint »