blog.vfg.lol

La nuit des lots — plan d'orchestration du prototype local (Citadelle, Cockpit, Blog, WSL)

Cinq lots d'agents séquentiels, zéro concurrence, et neuf gates humaines pour tenir la barre

La nuit des lots — plan d'orchestration du prototype local

TL;DR

Ce soir (vendredi 17 juillet 2026), le royaume tente d'aligner en une nuit un prototype fonctionnel entièrement local : la Citadelle réelle sur :6767, le Cockpit branché sur du vrai (fini le mock), le blog v2 servi en local sur :5195, le tout posé sur l'infra WSL déjà stable (15 conteneurs). La méthode : cinq lots d'agents strictement séquentiels — jamais deux agents en même temps, chaque lot déverrouillé par le GO écrit du précédent — encadrés par neuf gates humaines. Aucun agent ne décide ; FG tranche, les agents exécutent des plans-guides écrits pour être suivis sans réflexion.

Pourquoi cette forme

Deux leçons payées cash ont façonné ce plan.

La première : le 10–11 juillet, deux agents non coordonnés ont écrasé une flotte de 29 conteneurs stabilisée. Depuis, le protocole AGENT-LOCK existe — et cette nuit le pousse à sa conclusion logique : plutôt que de gérer la concurrence, on la supprime. Un lot, un agent, un repo, une fenêtre de temps. Le suivant ne démarre que sur un GO LOT SUIVANT écrit dans le handoff de sortie du précédent.

La seconde : le 8 juillet, le premier client réel du Cockpit vers la Citadelle a révélé que le mock mentait sur quatre points (map par slug vs tableau, ordres plats vs triés, garnison à la racine, noms de types d'ordre faux). D'où l'ordre des lots : on met la Citadelle réelle en ligne avant d'écrire le serveur qui la consomme. On teste contre le réel, pas contre des hypothèses.

L'état de départ, sans maquillage

BriqueÉtat au 17/07 19hReste à faire cette nuit
Infra WSL (vps-infra)15 conteneurs up, lock libreVérifier, ne rien toucher
Citadelle65/65 tests, front complet, 9 PR mergéesLa démarrer en local, instruire une vieille gate
CockpitFront mock complet, 78/78 tests, PWALe chantier : le serveur BFF n'existe pas
Blog (RAPPORT-EXPERIENTIEL)v2 migré, Gate F close, 378 articlesVérifier le serveur local, documenter un écart de contenu
VFGate195/195, 0 CVERien — rester debout sur :5191
VFVFGPTDécommissionNo-touch

Le seul vrai développement de la nuit est le BFF Phase 1 du Cockpit : bff/server.mjs n'a jamais été écrit — npm run cockpit échoue sur un module introuvable. Tout le reste du chantier Cockpit existe déjà : l'agrégateur, les heuristiques d'alerte, deux clients upstream testés contre la prod, et un front qui n'attend qu'une bascule de trois lignes (sourceMock → sourceReseau) pour vivre sur données réelles.

Les cinq lots

Lot 1 — la Sentinelle (vps-infra, ~20 min, lecture seule). Prend le lock en mode lecture, compte les conteneurs, fait un make check ENV=dev à blanc, sonde les ports qui compteront plus tard (5191, 6767, 5195), relâche le lock. Son livrable est un sitrep GO/NO-GO. Elle ne répare rien : une anomalie constatée est une information pour FG, pas une invitation à redémarrer quoi que ce soit.

Lot 2 — le Châtelain (Citadelle, ~45 min). npm ci, un .env local (rôle local, token vide — jamais commité), 65 tests, 9 smoke Playwright, puis le serveur reste allumé sur :6767 pour la suite. Il instruit aussi la gate G3-héraut : un vieux fix (b973d80) n'a jamais été poussé vers le repo canonique, mais son contenu semble y être arrivé par une autre route. Un git apply --check du patch de sauvegarde dira si la gate est un vrai manque ou un fantôme de traçabilité. Le Châtelain documente ; FG clôt.

Lot 3 — le Bâtisseur (Cockpit, ~2–3 h). Quatre fichiers à créer, chacun avec son test : un poller (une boucle par upstream, sa cadence propre, une map de tranches), un hub SSE (diffusion uniquement quand le hash de l'état change — la même économie que le front pratique déjà), un client blog (dix derniers articles depuis articles.json, jamais de passthrough brut), et le serveur Fastify qui assemble tout : GET /api/etat, GET /api/events, front statique servi sur :5230. Plus deux corrections de trois lignes : le port VFGate (la config disait 8083, la réalité dit 5191 — gate G2) et la bascule de source du front. Les sept clients upstream restants (messagerie, flotte, jeux, idées, bus d'événements) restent volontairement unknown : l'agrégateur est conçu pour ça, un upstream sans client n'affiche pas de mensonge, il affiche du gris.

Lot 4 — le Héraut (blog, ~1 h). Démarre le blog local, vérifie 74 tests, puis solde une vieille dette d'inventaire : les « 15 articles Citadelle » que le rollout du blog dynamique devait migrer. Le critère de done a toujours été « publiés ou écart documenté » — cette nuit on documente, fichier par fichier, ce qui est en prod et ce qui manque. Aucune publication : l'admin API de prod est le territoire de FG. Le Héraut pose aussi la première marche du chemin critique Citadelle : un draft de _ssot/ports.json, le registre unique des ports du royaume (24 entrées, dont un litige assumé sur le 5190).

Lot 5 — l'Intendant (transversal, ~45 min, docs seulement). Quatre curls, un navigateur, une vérification que la flotte Docker est intacte, et surtout : le handoff du réveil. Ce que FG doit trouver en ouvrant les yeux, c'est un document unique avec l'état réel, les écarts, et les commandes exactes des gates de sortie — copier-coller, pas archéologie.

Les gates humaines

Trois avant (G1 le GO d'exclusivité, G2 le port VFGate, G3 le périmètre git — branches de travail et PR draft uniquement), six après. Les gates du matin sont celles qui donnent son sens à la nuit : clore ou non la gate héraut (G4), valider le registre des ports (G5), publier les articles de la nuit (G6 — dont celui-ci), poser le workflow CI Playwright que le PAT des agents n'a pas le droit d'écrire (G7), merger les PR (G8). La G9 — le litige du port 5190 — reste ouverte, non bloquante, comme un rappel qu'un registre de ports n'est pas une formalité.

Le principe derrière ces gates n'a pas changé depuis la Gate F du blog : tout ce qui touche la prod, les secrets ou une décision d'architecture passe par un humain. Les agents préparent le geste jusqu'au dernier millimètre — la commande est écrite, testée à blanc quand c'est possible — mais c'est FG qui appuie.

Et si ça rate

Le plan de repli est écrit d'avance : si le Lot 3 échoue, le prototype du réveil est Citadelle réelle + blog local + Cockpit en mode mock via son serveur statique — déjà démontrable, déjà utile. Un lot en NO-GO gèle les suivants (sauf le Lot 4, indépendant du Cockpit). Et la règle d'or de la nuit, héritée de juillet : rien de ce qui tourne ne se redémarre pour « débloquer » un agent. On documente, on n'improvise pas.

Rendez-vous au prochain article pour les résultats — il est déjà prévu, en draft, dans le handoff de l'Intendant.


Références : plan maître handoffs/2026-07-17-1915-plan-nuit-lots-prototype-local.md et les cinq plans-guides par repo (vps-infra, VFG_Citadelle-private, VFG_Cockpit, RAPPORT-EXPERIENTIEL, VFGate, VFVFGPT), tous sur les branches claude/citadelle-prototype-plan-2tgcwe.

source markdown

Concepts de cet article

gateCitadelleVFGatehandoffVFVFGPT

Partage le plus de concepts avec