4.8 KiB
Fiche PIPE1-SPEC-01 — Niveau N2 — Modèle prévu opus | utilisé claude-opus-5-5 — Session Big Boss — Skills lp-lot, lp-repo, sk-orchestrate
PIPE1-SPEC-01 : W7 (ex-W1), la vague du gardien (règle stricte) (2026-10-15)
Demande de l'utilisateur : « W1 en premier, il doit être défini très drastiquement sinon le reste du pipeline se cassera la figure. » Objectif : moins de jetons (un agent gardien coûte 55 à 82 k ; 5 passages le 2026-10-15). Statut : SPEC à approuver ; aucun skill modifié.
Ce qui ne change pas
Gardien unique, verrou, index privé, chemins explicites, PubCheck -Index, R-REPO1, aucun push par un agent,
un commit par ticket (doc 10 § 1.3), ordre addon → pin → jeu.
Règles
V1. Déposer n'est pas lancer. Un ticket déposé entre dans la file etat\REPO\FILE.md (une ligne par ticket :
rang, ticket, dépôt, dépend de, heure, PubCheck relu). Seul Big Boss écrit la file. Aucun gardien ne part sur un dépôt.
V2. Trois déclencheurs, pas un de plus. Big Boss lance une vague seulement :
(a) en fin de journée, ou avant une rotation de Big Boss ;
(b) avant un push demandé par l'utilisateur ;
(c) quand un travail en attente a besoin d'un commit : un pin addon, ou un fichier en file qu'un autre lot doit modifier.
Hors de ces trois cas, aucune vague, même pour un seul ticket urgent. Seule exception : un retour arrière RESTORE
décidé par l'utilisateur, traité tout de suite et seul.
V3. Une vague = un agent, un verrou. Un seul agent gardien (sonnet), un seul verrou pris au début et rendu à la
fin, tous les tickets de la file traités dans l'ordre. Plafond : 8 tickets ; au-delà, deux vagues de suite.
Budget : maxTurns = 10 + 6 par ticket.
V4. Ordre fixe dans la vague. (1) tickets de l'addon, dans l'ordre de dépôt ; (2) un seul pin au doc 21, avec le dernier hash addon de la vague (les hashes intermédiaires listés en « précédents ») ; (3) tickets du jeu, dans l'ordre de dépôt ; (4) en dernier, le ticket des fichiers partagés (V5).
V5. Les fichiers partagés ont leur propre ticket. Journal_Modifications.md, Registre_Erreurs.md, README.md,
NUMEROS.md, le doc 21, BOSS-ETAT.md, BOSS-JOURNAL.md ne figurent jamais dans le ticket d'un lot.
(REPO-JOURNAL.md et le statut du ticket restent écrits par le gardien dans chaque commit de ticket, R-REPO1 ; le pin du
doc 21 est posé par le gardien et commité avec le ticket PARTAGES.) Big Boss écrit un seul ticket VAGUE-<AAAAMMJJ>-<n>-PARTAGES par vague, qui les commite en entier, en dernier.
Contrôle du gardien : chaque ligne ajoutée à un fichier partagé appartient à un CHG ou à un ERR listé dans ce ticket,
ou à une ligne de Big Boss ; une ligne inconnue = vague arrêtée.
Conséquence pour lp-repo § 6 : « aussitôt » devient « dans la prochaine vague ».
V6. Jeton du journal rendu à l'écriture. La DOC rend le jeton dès que son entrée est écrite (JOURNAL-EN-FILE <CHG>), sans attendre le commit. Plusieurs CHG non commités peuvent donc coexister ; V5 les commite ensemble. La
réservation des numéros ne change pas.
V7. Seul un ticket mûr entre en file. Livrables finis, PubCheck 0 relu par Big Boss, VAL faite quand elle est requise. Aucun ticket « à compléter », aucun ticket corrigé dans la file : on le retire et on en dépose un autre.
V8. Chemins gelés entre deux vagues. Un chemin cité par un ticket en file n'est touché par personne jusqu'au commit. Un lot qui doit le modifier attend la vague, qui se lance alors par le cas V2 (c).
V9. Échec = arrêt net. Un ticket refusé (HEAD inattendu, PubCheck non nul, diff hors liste, ligne inconnue en V5) arrête toute la vague à ce ticket. Les tickets déjà faits restent faits, les suivants restent en file. Aucun contournement. Big Boss corrige, retire ou remplace le ticket, puis lance une nouvelle vague.
V10. Compte rendu court, contre-vérification unique. Le gardien rend une ligne VERDICT par ticket et le status
restant de chaque dépôt, sans rien d'autre. Big Boss fait un seul passage de contrôle sur toute la vague
(git show --name-status de chaque commit contre son ticket), puis vide la file.
Textes à modifier après approbation (un seul instantané, un seul CHG)
lp-repo § 6 et § 8 (gabarit : ajout du ticket PARTAGES), sk-repo § 2 (une vague par verrou), lp-lot (DOC et
tickets), boss.md § 1 et § 5 (messages VAGUE, JOURNAL-EN-FILE), agent lp-gardien (mode vague, budget),
nouveau etat\REPO\FILE.md. Copies du profil faites par l'utilisateur, MD5 cités.
Risques
- Un lot attend plus longtemps son commit : il ne doit pas en dépendre, sauf par V2 (c).
- Une vague arrêtée bloque les tickets suivants jusqu'à la correction (V9) : c'est voulu.
- Arbre de travail moins propre entre deux vagues : couvert par V8 et par les chemins explicites.