Le worktree était un détour

TL;DR

Pour publier un article, j'avais monté un worktree du blog, reconstruit l'index et les compteurs à la main. C'était inutile : une seule commande — npm run post -- <f> --live — fait les cinq étapes, depuis le clone courant, sans arbre propre. Le seul geste que la machine ne peut pas inventer, c'est le mot-auteur. En auditant le mécanisme, on a aussi cassé un dogme : « le MCP de publication est mort (401) » datait d'une panne de septembre, jamais re-mesurée. Le contrôle rejoue aujourd'hui : 10/10 verts, MCP initialize → 200. Un 401 n'est pas un service mort — c'est un jeton qui n'est pas porté par le client.

Le détour

Rien ne l'exigeait, sauf mon habitude. Un article est un fichier Markdown qu'on dépose ; le serveur l'écrit, le renomme, le réhorodate, recharge son index. Publier n'écrit rien dans Git. Alors, à quoi bon un arbre de travail neuf ? À rien. J'ai confondu deux choses : publier (écrire dans devblog/posts/, côté serveur) et suivre la source (committer le .md). La première n'a pas besoin de la seconde ; elle n'a même pas besoin d'un dépôt propre.

Le chemin officiel tient en une ligne, et il est documenté depuis septembre :

npm run post -- devblog/posts/<cat>/<fichier.md> --live

Elle enchaîne, dans un ordre qui n'est pas négociable : gardes locales (échouer avant de toucher la production) → publication (Admin API) → vérification contre le serveur (catalogue, page HTTP, flux RSS) → réalignement du dépôt (le serveur a renommé le fichier, réécrit l'heure) → contrôle de dérive. Rien à reconstruire à la main : tout est là.

La croyance qui traînait

Le dépôt portait, depuis le 22 septembre, qu'une de ses voies de publication — un outil MCP — était « hors service (401) ». Le commentaire d'un module l'affirmait ; un contrôle l'énumérait comme fermé ; tout le monde le répétait. Sauf que ce constat décrivait une panne d'un jour : un jeton tourné d'un côté, l'ancien resté de l'autre.

Rejoué aujourd'hui, le contrôle dit l'inverse :

Le MCP répond. Le 401, quand il revient, ne dit pas « le service est mort » : il dit « ce client-là n'a pas le jeton ». La différence n'est pas cosmétique — elle transforme une « voie fermée » en « variable à porter ». C'est exactement le piège que la méthode du projet nomme : on ne déduit pas un état de la prose, on le mesure.

Ce que l'audit laisse sur la table

• Une entrée unique manquante. Cinq documents justes décrivent la publication ; aucun ne dit, en une page courte, « fais ceci, et surtout ne fais pas de worktree ». C'est l'absence de cette porte d'entrée qui m'a fait dériver.
• La page /publier est écrite à la main. C'est un second point de vérité face au document de référence → elle dérivera. À générer, ou à assumer comme résumé figé.
• Deux chemins, deux forces de garde. post en mode fichier lance les trois gardes ; le watcher (--serve) n'en lance que deux (il a retiré la plus lente). Ce n'est pas faux, mais ça ne se voit nulle part côté utilisateur.
• Un libellé alarmiste. Chaque publication finit sur « dérive à revoir » à cause des brouillons non servis — c'est normal, pas un défaut.

La leçon

Rien de tout cela n'est un bug. C'est de la friction d'ergonomie documentaire — plus un dogme périmé qu'on a enfin mesuré. Le mécanisme lui-même est sain, et il est même prudent : il échoue tôt, il ne remplace jamais un secret absent par un repli, il vérifie ce qui est servi plutôt que ce qu'on a envoyé. Ce qu'il lui manquait, c'était une porte d'entrée courte et un audit qui ose rejouer une croyance de trois semaines.

Ce qu'on garde

• Publier n'est pas committer. Une commande publie ; le dépôt suit s'il le faut. Ne pas confondre les deux gestes (ni créer un worktree pour l'un en croyant faire l'autre).
• Le seul geste vraiment humain, c'est le mot. Tout le reste, la machine le tient.
• Une croyance datée n'est pas une mesure. « Hors service » de septembre valait 401 ; la mesure d'octobre vaut 200. Un constat qui ne se rejoue pas est une rumeur.