4.4 KiB
Fiche PIPE1-SPEC-03 — Niveau N2 — Modèle prévu opus | utilisé claude-opus-5-5 — Session Big Boss — Skills lp-lot, lp-validate, sk-orchestrate
PIPE1-SPEC-03 : W4 (ex-W2), la VAL proportionnée (règle stricte) (2026-10-15)
Demande de l'utilisateur : « abordons W2 ». Objectif : moins de jetons (une VAL par agent neuf coûte 121 à 138 k, mesuré le 2026-10-15). Statut : SPEC à approuver ; aucun skill modifié.
Ce qui ne change pas
VAL ≠ IMPL : jamais l'auteur ne valide son propre travail. VAL ≠ DOC. FAIL de VAL : pas de clôture, fiche -fix.
PubCheck 0 exigé partout. lp-validate reste la batterie de référence pour la classe C.
Règles
R1. Chaque fiche porte sa classe de VAL, écrite avant l'IMPL : ligne Classe VAL : L | D | O | C. La classe se
détermine d'après les fichiers touchés, et la plus haute l'emporte (L < D < O < C).
| Classe | Fichiers touchés | Qui valide | Modèle | Contenu de la VAL | Budget |
|---|---|---|---|---|---|
| L lecture | seulement des livrables d'etat\ (INV, CART, RECH, DIAG, PERF, grilles, registres du lot) |
Big Boss (contre-vérification) | — | PubCheck rejoué ; au moins un compte clé par tableau principal recompté sur la source brute ; ligne de registre cohérente | ≤ 10 k |
| D documentation et méthode | skills, agents, gabarits, docs numérotées, CHG, mémoire | Big Boss si le diff fait ≤ 20 lignes ajoutées et ne touche aucune règle d'autorisation ; sinon lp-validator |
Haiku | diff contre l'instantané = hunks annoncés ; LF ; PubCheck ; R9 (≤ 120 lignes) ; aucun texte contradictoire avec un autre skill (grep des mots-clés) | ≤ 15 tours |
| O outils et gardes | Tools\ (scripts, hooks, gardes), réglages Claude (settings.json), règles d'autorisation |
lp-validator, toujours, quelle que soit la taille |
Sonnet | batterie d'essais avec preuve par l'échec (l'ancienne version doit échouer là où la nouvelle passe) ; sortie et codes de retour ; aucune ouverture non voulue | ≤ 25 tours |
| C code, assets, configuration du jeu | C++, Blueprints, Content\, Config\*.ini, .uproject |
lp-validator |
Sonnet | lp-validate complet (build, compte des avertissements, tests, contrôle en jeu) |
selon lp-validate |
R2. L'auteur ne valide jamais. Si Big Boss est l'auteur, une VAL de classe L ou D passe à lp-validator (Haiku).
Exemple : le lot PIPE1, écrit par Big Boss, est validé par un agent.
R3. Une VAL qui échoue se reprend avec le même agent. Correction faite, la nouvelle VAL est envoyée au même
lp-validator (contexte gardé, SendMessage), jamais à un agent neuf, sauf si l'agent a dépassé son budget.
R4. Une VAL par lot, pas par fiche. Les fiches d'un même lot sont validées en une fois, à la fin, sur la liste complète des fichiers ; une VAL intermédiaire seulement si une fiche suivante dépend du résultat (exemple : une garde avant son emploi).
R5. Contrôle au dépôt du ticket. Big Boss vérifie que la classe de VAL déclarée correspond aux fichiers du ticket ; classe sous-évaluée ou VAL absente = ticket refusé à l'entrée de la file (W7, V7).
R6. Compte rendu de VAL court. Verdict, critères (une ligne chacun), PubCheck, tours ; 10 lignes au plus vers
Big Boss ; le détail reste dans le livrable <LOT>-VAL.md (classes D, O, C) ou dans BOSS-JOURNAL.md (classe L).
Exemples du 2026-10-15
| Lot | Fichiers | Classe | Ce qui aurait suffi |
|---|---|---|---|
| A3, G0, KALM1, CRIM1 | livrables d'etat\ |
L | contre-vérification de Big Boss (déjà faite) |
| UES1 | 6 skills (+97 lignes), LICENSE, annexe | D, > 20 lignes | lp-validator Haiku ; la reprise après FAIL au même agent (fait) |
| OPT0-A2, gardes v2 à v6 | hook Tools\hooks\ |
O | lp-validator Sonnet avec la batterie et la preuve par l'échec (la batterie existait, la VAL distincte manquait) |
| G2 (lundi) | Blueprints | C | lp-validate complet |
Textes à modifier après approbation
lp-lot (cycle et VAL), lp-validate (en tête : classes et renvoi), sk-orchestrate (rubrique de la fiche :
ligne Classe VAL), gabarit TACHES de lp-doc (colonne Classe VAL). Un seul instantané, VAL de classe D par un agent
(R2), commit dans la vague de ce soir.
Risque
Une classe L mal posée laisserait passer une modification sans VAL : couvert par R1 (la plus haute l'emporte) et R5 (contrôle des fichiers du ticket).