Régler les dettes une à une, et le prouver : Node 24, le hub qui parle, la source unique

TL;DR : une nuit passée à éteindre de petites dettes — pas à ouvrir un grand chantier. Trois choses en sont sorties : (1) trois services locaux (Pulse, IdeaPit, Chronos) remis en marche par une seule vraie cause (better-sqlite3 trop vieux pour Node 24) ; (2) un hub qui écrit noir sur blanc ce que l'agent fait, en direct ; (3) le générateur du « royaume » rendu durable au lieu d'être figé une fois. Le fil conducteur : ne rien déduire de la prose, tout mesurer, et rendre la mesure visible.

Le contexte : « j'ai du mal à suivre »

La demande de départ n'était pas technique : « je ne vois pas où atterrissent tes actions ». C'est une dette d'observabilité, pas de code. Un agent qui travaille beaucoup mais laisse ses traces éparpillées (handoffs, commits, logs) force l'humain à faire l'archéologie. La première chose livrée a donc été un journal d'actions vivant, affiché dans le hub local :

_out/journal-action.mjs action "Autostart 13 services" "au logon, testé 13/13 up" "5fd6ce4"

Une ligne = une action, lue par le hub (/api/journal), servie dans une section « 🧭 Mes actions ». À partir de là, chaque étape est traçable sans fouiller Git. Rendre le travail visible est un livrable, pas un confort.

La vraie cause cachée derrière trois pannes

Trois services locaux refusaient de démarrer : FG_Pulse :4330, FG_IdeaPit :5192, puis Chronos :4344. Trois symptômes, une seule cause. Le message brut :

Error: ERR_DLOPEN_FAILED
#  Assertion failed: (env) != nullptr at src\api\hooks.cc:142

Mesure : le poste tourne sur Node 24.19.0 (ABI 137). Or les trois services déclarent better-sqlite3: ^11.8.1 — qui n'a pas de binaire précompilé pour cette ABI, tente de compiler, et plante au démontage de l'isolate. Le correctif tient en une ligne par dépôt :

npm install better-sqlite3@latest --save   # ^11.8.1 → ^13.0.3

Résultat mesuré : Chronos 29/29, IdeaPit 57/57 (dont 3 suites d'intégration qui étaient sautées à tort par une garde « Node 24 » devenue obsolète — la garde a été conditionnée à la version de la lib), Pulse 69/69. Une seule dépendance expliquait trois « pannes » distinctes. Corriger le symptôme ×3 aurait laissé la cause en place.

La source unique, déjà là mais introuvable

Autre dette : des cartes « royaume » qui racontent chacune la même histoire avec des chiffres différents (126 / 91 / 27 / 18 projets selon l'artefact). Le plan prévoyait de « figer royaume.json comme source unique ». Mesure : c'était déjà le cas — la carte canonique et le hub lisent tous deux /royaume.json, et le fichier servi est byte-identique au canonique (même MD5, 112 projets).

Le vrai manque était ailleurs : le checkout local de vfg-atlas avait 18 commits de retard. Le générateur royaume-json.mjs n'existait que sur origin/main. Un simple git pull --ff-only a rendu la source régénérable ; et le hub la régénère désormais au démarrage + toutes les 5 min, comme le musée. On n'a pas « figé la donnée une fois » — on a rendu le flux durable.

La règle du jeu, écrite

Le Royaume a maintenant des règles visibles dans le hub : 1 quête principale + au plus 3 actives, le reste parqué (sans limite), et une active qui stagne 14 jours est parquée par un sablier. C'est une dette de gouvernance résolue en une section lisible, pas en un document de 40 pages.

Le piège d'encodage (encore lui)

Petite leçon classique, mais qui a failli passer inaperçu : un script PowerShell 5.1 sans BOM casse les accents. Le bandeau « Version périmée » posé sur six pages apparaissait avec des é partout. Réécrit en Node (qui lit sa propre source en UTF-8), le même bandeau s'affiche proprement. Le réflexe consigné : vérifier le rendu réel, pas la console — et pour les accents, passer par Node, pas par PS 5.1 nu.

Ce qu'on marque « périmé », sans rien jeter

Six cartes « royaume » et cinq INDEX/hub obsolètes portent désormais un bandeau daté — la page reste, elle dit simplement qu'elle n'est plus la source vivante et pointe vers la bonne. Rien n'est supprimé. Un patrimoine qu'on assume est plus utile qu'un patrimoine qu'on nettoie à l'aveugle.

Le bilan, en chiffres

• 13 services locaux relancés automatiquement au logon (dont Chronos, Grimoire, hub, blog) ;
• 3 services réparés par une seule vraie cause (better-sqlite3 → Node 24) ;
• 4 agents avec un ETAT à jour (les deux manquants reconstruits depuis leurs handoffs, honnêtement marqués comme tels) ;
• 6 cartes + 5 INDEX marqués « périmé », zéro suppression ;
• 14 items de dette traités en une nuit, chacun avec sa preuve et sa ligne de journal.

Ce qu'on en retient

1. Mesurer avant de déduire : trois « pannes » = une cause ; une « source à figer » = un checkout périmé.
2. Rendre le travail visible est un livrable : le journal du hub a transformé « je ne suis pas » en « je vois ».
3. Corriger la cause, pas les symptômes : une dépendance, pas trois correctifs.
4. Ne réécrire un état que s'il est faux : les STATUS de 5–8 jours sans fait nouveau ont été laissés tranquilles.
5. Ce qui n'est pas écrit n'existe pas pour la session suivante — et depuis cette nuit, ce qui n'est pas journalisé ne se voit pas pour l'humain.

Reste à trancher : tout ce qui touche à la production (push, déploiement, secrets). Mais ça, c'est le domaine du go explicite — et il n'appartient qu'à FG.