Trois sondes permanentes, et le relevé de ce qu'elles ont montré sur .75.
- telemetry_watch.dart (lecture seule) : cadence du battement de cœur et avancée
du cycle. C'est la seule mesure qui distingue une installation stable d'un
moteur arrêté — les deux produisent le même flux de trames.
- domain_assign.dart (écrit, --yes) : classe des charges en important le code
d'écriture de l'app. Une sonde qui sérialiserait à sa façon ne prouverait rien
sur l'app.
- fault_probe.dart (écrit, --yes) : provoque une charge en défaut, éprouve
ClearLoadFault, restaure. La config d'origine part sur le disque AVANT la
première écriture et la restauration rejoue ce fichier verbatim — filtrer la
sonde hors d'une relecture serait une reconstruction, c'est-à-dire le chemin
qui a failli écraser la config du banc via persist(). La config relue est
ensuite comparée clé par clé, pas seulement « la sonde a disparu ».
Ce que le banc a appris, et qui ne se déduisait pas du code :
- ClearLoadFault lève RÉELLEMENT le verrou (journal : « défaut LEVÉ ») et le
cycle suivant reverrouille, la cause n'ayant pas disparu. La télémétrie ne
repasse jamais à available:true. Une app qui aurait cru l'acquittement aurait
menti deux secondes plus tard.
- Le défaut publié est WRITE_FAILED, pas THING_MISSING : l'écriture est tentée,
échoue, l'échelle s'épuise, et m_faulted masque le second code.
- SetLoadConfig refuse en bloc et le motif n'est PAS dans la réponse RPC — il est
au journal. L'app ne peut que rapporter un refus, pas l'expliquer.
- ECS-412 confirmé au journal : une écriture de domaine ne reconstruit aucun
adaptateur (« 2 inchangée(s), 0 retirée(s) »). Le §7-1bis n'est plus une
lecture de code.
.75 est laissé classé (chauffe-eau→ecs, pac-terrain→hvac) : métadonnée que
l'arbitre ne lit pas, et le multi-domaines y devient exerçable. Retour arrière :
domain_assign.dart --clear --yes
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPUo3RMr8SzK6qbFtfBm8H
40ea285663