docs: RECAP — lot télémétrie déployé, mais attendre l'agent plugin

Le bloqueur consigné en fin de session précédente est levé : GetLoadTelemetry,
LoadTelemetryChanged et o:domain sont sur .75 (20 méthodes / 14 notifications).

Mais consigne explicite de Patrick : ne PAS enchaîner sur la moitié télémétrie
tant que l'agent plugin n'a pas fini son travail sur pac-terrain. L'écart
GetLoadTelemetry (2 charges) / GetLoadConfig (1 charge) est ce travail en
cours, pas une anomalie à remonter — coder contre cet état serait coder contre
une cible mouvante.

Consigne aussi que l'arbitre tourne bien (timestamp +1 min/cycle), ce qui fixe
le plancher du seuil de fraîcheur §7-6 à plus de 60 s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

RECAP.md

@@ -57,20 +57,48 @@ remplace **tout l'ensemble** → la charge `chauffe-eau` de `.75` aurait été
 
 ---
 
-## ⛔ BLOQUEUR PRINCIPAL À LA REPRISE
+## ⏸️ ÉTAT À LA REPRISE — attendre l'agent plugin
 
-**Le lot plugin `brief-plugin-lotB-telemetrie.md` n'est PAS déployé sur `.75`.**
-Introspect au 2026-08-25 : toujours **19 méthodes / 13 notifications**.
+**Le lot plugin télémétrie A ÉTÉ déployé sur `.75`** en fin de session (`4ade3e4`) :
+**20 méthodes / 14 notifications**, `GetLoadTelemetry`, `LoadTelemetryChanged` et
+`o:domain` présents. Les critères **4 à 8** du brief lot B sont donc techniquement
+atteignables.
 
-```
-GetLoadTelemetry      : ABSENT
-LoadTelemetryChanged  : ABSENT
-o:domain              : ABSENT du schéma SetLoadConfig
+> **⛔ NE PAS ENCHAÎNER POUR AUTANT.** Décision Patrick, 2026-08-25 : attendre que
+> l'agent plugin ait **terminé son travail sur `pac-terrain`** avant de construire la
+> moitié télémétrie côté app.
+>
+> Symptôme observé (reproductible, **travail en cours — pas un bug à remonter**) :
+> `GetLoadTelemetry` renvoie **2** charges (`chauffe-eau`, `pac-terrain`) là où
+> `GetLoadConfig` n'en renvoie qu'**1** (`chauffe-eau`). Coder l'écran contre cet état
+> intermédiaire, c'est coder contre une cible mouvante.
+
+### Fixtures capturées avant la bascule (déjà committées)
+- `test/fixtures/loadtelemetry_hems75.json` — dump réel de `GetLoadTelemetry`
+- `test/fixtures/loadconfig_hems75_v2.json` — `GetLoadConfig` **avec** la clé `domain`
+- `test/fixtures/schema_hems75_v2.json` — schémas SET + télémétrie introspectés
+- `test/fixtures/loadconfig_hems75.json` — dump d'AVANT, conservé comme référence
+
+Forme confirmée de la charge utile (conforme au brief : des **codes**, jamais des phrases) :
+
+```json
+{ "loadId": "chauffe-eau", "allocatedW": 0, "available": true,
+  "decision": { "code": "SURPLUS_INSUFFICIENT", "params": { "budgetW": 229 } },
+  "lock": { "kind": "minOff", "remainingS": 60 },
+  "mechanism": { "kind": "relay", "stageW": 0, "maxStageW": 3500 } }
 ```
 
-Conséquence : critères **4 à 8** du brief lot B hors d'atteinte (domaine, télémétrie
-vivante, fraîcheur, défaut/`ClearLoadFault`, code inconnu réel). Tant que ce lot n'est pas
-sur la box, **il n'y a plus rien d'utile à faire côté app sur ce périmètre**.
+### Acquis à ne pas reperdre
+- **L'arbitre n'est PAS figé** : le `timestamp` avance d'une minute par cycle
+  (`12:37` → `12:38` → `12:39`, vérifié). Le seuil de fraîcheur du §7-6 doit donc être
+  **supérieur à 60 s** — deux ou trois cycles, pas moins.
+- `.75` a désormais une 2e charge (`pac-terrain`, sg-ready) côté télémétrie : le
+  multi-charges y deviendra exerçable en vrai, contrairement à ce que disait le tableau
+  ci-dessous.
+
+### Sondes JSON-RPC — désormais permanentes
+`tools/rpc/` (voir son `README.md`). `loadconfig_roundtrip.dart` est le **seul qui écrit**
+et exige `--yes`.
 
 ## Vérifié / non vérifié (lot B app)