Zeno Suivi — Diagnostics¶
Deux vérifications utiles, pas plus — ce projet n'a ni serveur ni service à sonder.
Vérifier que la copie statique (« baked ») correspond bien à PROJECTS¶
Si quelqu'un a modifié PROJECTS sans relancer node scripts/bake.mjs avant de committer, la page continue d'afficher un contenu périmé dans les contextes qui bloquent le JavaScript (voir overview.md — le mécanisme de baking). Pour vérifier après coup, dans un clone à jour :
Si la commande relance bake.mjs et que git diff montre des changements sur index.html, c'est que la copie statique committée n'était pas synchronisée avec PROJECTS — il faut committer le résultat de ce bake.mjs. Si git diff ne montre rien, la copie statique était déjà à jour.
Vérifier l'état de GitHub Pages¶
status doit valoir "built" (construction terminée) — vérifié le 2026-09-11 : "status":"built", "build_type":"legacy", source = branche main racine du dépôt. Il n'y a pas de workflow GitHub Actions dans ce dépôt : la publication est gérée nativement par GitHub Pages sur chaque push vers main, sans étape de build intermédiaire à surveiller. Si status reste à "building" ou passe à "errored" après un push, c'est le seul vrai signal d'incident possible côté publication — dans ce cas, vérifier l'onglet Settings → Pages du repo GitHub directement.
Vérifier que l'instantané du plan de charge n'est pas périmé¶
La date affichée dans la bannière de la vue Plan de charge (« Instantané exporté le … ») vient de exportedAt dans data/plan-snapshot.json :
Si cette date est ancienne alors que des changements sont censés avoir eu lieu dans l'artifact Claude, c'est qu'une republication (RULES.md §9) est en retard — pas un bug, juste un rappel qu'il faut refaire le cycle snapshot-from-dump.mjs → build.mjs.