LifePlay-Revival/Docs/Migration/etat/EVAL2/EVAL2-RAPPORT.md

Fiche EVAL2-T8 — Niveau N2 — Modèle prévu Opus 5.5 | utilisé claude-opus-5-5 — Agent orchestrateur (session EVAL) — Skills aucun préchargé

EVAL2-RAPPORT : évaluation des opérations après la première release 5.8 (P3, 2026-10-11 → 2026-10-14)

Demande de l'utilisateur (relayée par Big Boss) : « faisons l'évaluation des opérations. reprenons les ancienne évaluations et voyons quels sont nos performances actuelles, ce qui a bien marché, ce quit doit être améliorer au niveau des outils, des skills, des agents, de l'organisation ».

Bases : doc 31 (P0, P1), doc 33 (P0 à P2, E1 à E7, § 7), etat\EVAL\, etat\AG\ORGA2\ORGA2-PROPOSITION.md, doc 32 § 15, doc 34. Chiffres : EVAL2-STATS.md (chaque valeur y renvoie à son relevé T1a à T6). Biais : écrit par une session orchestrateur Opus, partie de l'organisation jugée ; P3b (sprint de correction en jeu) ne se compare pas « à travail égal » avec P0 à P2 (migration, outillage).

---

1. Résumé

1. Le résultat est là : 13 builds communs en 30 h de sprint, tous compilés du premier coup ; une boucle essai → correctif → build de 53 min en médiane ; l'alpha 2026.10.2.1a est taguée sur 2f5d51b avec 0 commit sans ticket, 0 verrou orphelin, 0 --amend.
2. L'utilisateur est le principal testeur : 81 % des défauts KO ont été trouvés par lui en jeu ; 35 % des cas ont été validés sans vérification cas par cas ; 3 VAL PASS-STATIC ont été suivies d'un KO en jeu ; 5 correctifs ont introduit une régression.
3. La documentation décroche sous la pression : aucun CHG ni ERR pendant ≈ 29 h de sprint, 50 ERR consignés en un seul rattrapage, bilans écrits après coup, 81 % des lignes du BOSS-JOURNAL sans heure.
4. Le coût se concentre : Big Boss fait 20 % de tous les jetons (25 % de ceux des principales) et 36 % des heures (clause d'arrêt du doc 33 à 15 % : déclenchée dans les deux bases) ; lp-mcp-bp (Opus) fait 26 % des jetons des sous-agents.
5. Le crochet protège mais gêne : 40 refus utiles, mais 36 à tort, surtout sur > cité dans un grep ou un awk (clause de retrait du doc 33 déclenchée sur CAM : 12 à tort pour 5 utiles, si « refus légitimes » se lit « à tort ») ; 17 refus que les agents se sont infligés eux-mêmes, dont 3 dans ce lot.
6. Les cibles du doc 33 § 7 ne sont pas atteintes (contexte médian 295 k pour < 200 k ; part des sous-agents 57 % pour

   70 %) ; les outils E2 ont été abandonnés pendant le sprint.

---

2. Ce qui a bien marché (avec preuves)

#	Constat	Preuve
B1	Boucle de correction rapide : build commun + fiche de tests commune (décision de l'utilisateur du 2026-10-13)	13 builds, médiane 53 min de la fin d'un essai à l'exe suivant, 15 min au mieux (C9 → C10) ; 0 échec de build sur P3 (STATS § 2.1)
B2	Builds outillés : Build.ps1 + BuildDebug rendent un résumé compté	25 résumés, 20 journaux UAT, tous code 0 ; Build.ps1 52 s, BuildCookRun 128 s en moyenne ; lp-builder haiku 3 % hors budget
B3	Gardien et dépôt sûrs	49 commits, 0 sans ticket ; 82 verrous pris et rendus ; 9 refus de commit tous repris ; 0 --amend (STATS § 2.4)
B4	PubCheck et le gardien attrapent les fuites avant publication	6 commits refusés pour un nom de compte (3 par le gardien, 3 par PubCheck), tous repris ; rien de poussé avec une fuite
B5	Le crochet bloque de vraies écritures	40 refus utiles, dont STE-ORG4c (mkdir + mv d'un autosave GI par un sous-agent, arrêté conformément à sa fiche) ; 7 agents se sont arrêtés après un refus (T6 § 2.5), les autres ont continué ou reformulé (T1b, T6)
B6	Rotation de Big Boss et baisse des jetons par heure	une rotation le 2026-10-13 12:26 (384 k → 268 k de contexte médian) ; jetons lus par heure active 43,5 M contre 130,2 M en P2
B7	Règles de fiche (E5) suivies	« Niveau Nx » 89,7 %, en-tête 83,4 % ; 2 reprises sur 246 fiches ; 0 escalade nécessaire ; 1 agent coupé sans compte rendu sur 258
B8	VAL utiles	9 VAL sur 76 ont rendu un FAIL à un stade, toutes reprises ; FAIL final 6,6 %
B9	Rattrapage des journaux fiable	JOURNAUX1-2 : 26 CHG recoupés 26 / 26 avec git log -S ; 50 ERR sans trou de numéro (T3)
B10	Verrou, Numero, UeState adoptés	110, 77 et 370 appels en P3 (T6 § 2.9)

---

3. Ce qui doit s'améliorer, par axe (cause et preuve)

3.1 Outils

#	Défaut	Cause	Preuve
O1	Crochet trop grossier : 36 refus à tort sur 76	il cherche > et -> dans toute la commande, y compris dans les textes cités (grep "^>", awk 'NR>=…', echo "a -> b") ; il refuse aussi l'écriture dans un dossier temporaire	T6 § 2.4 (relecture 15 / 15) ; CAM 12 à tort / 5 utiles ; 18 des 40 « utiles » visent un temporaire
O2	Crochet fragile	il est lu depuis Tools/claude/hooks/, qui a disparu de la copie le 2026-10-13 ; les appels ont échoué en « hook error »	4 pannes (T1a) ; BOSS-JOURNAL l. 452 ; le fichier figure encore en D au git status
O3	Outils de copie partagée abandonnés en sprint	CopieEtat / GitEtat non nommés dans les fiches du sprint ; habitude de git status et md5sum à la main	0 appel en P3b ; 662 git status, 927 empreintes improvisées (543 en P2)
O4	PubCheck lancé trop tard	au commit, pas à l'écriture du livrable	3 refus PubCheck sur les commits de l'alpha (STE, STG, CAM) le 2026-10-14 (T2)
O5	Aucune trace automatique des essais	le découvreur, le KO et l'heure sont reconstitués à la main dans un bilan	bilans après coup (C8-C10 écrits ensemble, C13 + 104 min) ; COMMUN-1 sans fiche ni bilan (T4)
O6	Instantané non contrôlé	Snapshot.ps1 est une consigne, rien ne vérifie qu'il a tourné avant une écriture	7 relevés « instantané manquant » (3 cas distincts : ORG5-I2a, CAM-B2n, .h de DirectControl STG) et 2 tardifs (T5)
O7	Pièges de poste non documentés	Python du Store en MSIX ne voit pas AppData\Roaming\Claude ; git ls-remote bloque sur le gestionnaire d'identifiants	T1a, T6, T2 ; un processus de T2 resté bloqué
O8	FicheStats classe mal certains agents	lp-mcp-bp, lp-diag, lp-cart-max absents d'AGENTS_N3	lp-mcp-bp compté hors budget à 46 % au lieu de 14 % (T1b)

3.2 Skills

#	Défaut	Cause	Preuve
S1	Consignes de shell non intégrées : les agents tapent ce que le crochet refuse	la règle « pas de python -c, heredoc, > » est dans sk-protocol § 7, mais aucun skill ne dit comment tester ou lire un JSON autrement	17 refus dus à la propre consigne (14 en P3, 3 dans ce lot) ; 26 erreurs de guillemets en Bash (T6)
S2	Principales hors règle	les sessions principales n'ont pas de crochet et écrivent du Python en ligne	322 heredocs Python dans les principales ; 152 python -c de plus de 200 caractères toutes sessions (T6 § 2.8)
S3	Gabarits absents pour la fiche de tests et le bilan d'essai	chaque COMMUN est rédigé à la main par Big Boss (« Tenue par Big Boss », etat\BOSS\COMMUN-2-TESTS.md l. 3)	12 fiches différentes ; validations implicites 32, en bloc 24 ; bilans tardifs (T4)
S4	Registres de lot sans colonnes de mesure	lp-doc § TACHES non suivi par STG, CAM, STE	l'essai D-P7.16 (S, C9a) n'est mesurable que sur 16 fiches sur 52 (T5)
S5	Journal non tenu pendant un sprint	le CHG n'est écrit qu'au commit (règle du doc 33), et le sprint n'a commité qu'à la fin	≈ 29 h sans CHG ni ERR ; 50 ERR en un seul commit (T3)

3.3 Agents

#	Défaut	Cause	Preuve
A1	lp-mcp-bp premier poste de coût	Opus xhigh sur tous les correctifs Blueprint, y compris les petits ; fiches longues	37 passages, 144,2 M (26 % des sous-agents, 62 % d'Opus), 43,6 tours en moyenne, max 82 (T1b)
A2	lp-cart presque toujours hors budget	fiches trop larges, comme en P2 (55 %)	79 % sur 14 fiches, 4 lancés en Opus contre l'en-tête de l'agent (T1b)
A3	VAL statiques trop optimistes pour le jeu	une VAL PASS-STATIC vérifie le graphe, pas le comportement en jeu	3 PASS-STATIC suivis d'un KO en jeu, + B2s PASS suivi d'un KO (T5)
A4	Agent de build hors budget sur la vérification	la chaîne de contrôle après build est longue (64 / 65 étapes en C13)	COMMUN-9 : 55 tours contre 40 déclarés (T1b, T4)
A5	Écarts d'orchestrateur après un refus utile	l'orchestrateur fait lui-même l'écriture refusée à l'agent	STE-ORG4c : fichier déplacé sans MD5, VAL PASS (T6 § 3)

3.4 Organisation

#	Défaut	Cause	Preuve
G1	Big Boss trop cher	il reçoit 72,5 % des messages de l'utilisateur ; il tient les fiches de tests, les bilans et les journaux (BOSS-JOURNAL, etat\BOSS\COMMUN-* ; cause estimée, la répartition de son coût par activité n'est pas mesurée)	20,4 % de tous les jetons, 36 % des heures, 1 815 tours (STATS § 3) ; clause D-P7.8 franchie
G2	L'utilisateur fait la recette	pas de contrôle automatique en jeu avant l'essai de l'utilisateur	81 % des KO trouvés par lui ; 5 régressions de correctif trouvées après build (T4)
G3	Rotation des sessions incomplète	rotation de Big Boss faite, pas celle des sessions de lot	STE vivante 79,6 h ; 13 sessions sur 25 au-dessus de 250 k ; contexte médian 295 k (T1a)
G4	Sessions réutilisées sous un nom qui ne correspond plus au lot	règle « sessions réutilisées » sans renommage systématique	ARCH427 et TRACE1 rangées sous « STG », PUB3 sous « REL » dans l'application (T1a)
G5	Heures absentes du BOSS-JOURNAL	lignes écrites sans horodatage	376 lignes sur 462 sans heure ; délai décision → livraison mesurable sur 2 décisions sur 20 (T3)
G6	Release non poussée	à confirmer : décision ou oubli	tag et ue5.8 absents d'origin (T2)

---

4. Recommandations chiffrées (classées par gain attendu)

Les gains sont estimés à partir des chiffres de P3 ; aucun n'est mesuré à l'avance.

#	Recommandation	Axe	Gain attendu (estimé)	Coût	Risque
R1	Recentrer Big Boss sur la file UE, les arbitrages et les GO ; fiches de tests, bilans et journaux confiés à un lp-writer (gabarit S3) ; rotation quotidienne imposée	organisation	−40 à −50 % des jetons de Big Boss (≈ −250 M sur une période comme P3, soit −8 % du total)	un lot DOC (gabarits) + règle dans lp-lot	moyen : plus de messages entre sessions
R2	Crochet v2 : ignorer les motifs entre guillemets et apostrophes ; autoriser l'écriture dans le scratchpad et %TEMP% ; crochet chargé depuis le profil seulement	outils	−36 refus à tort sur une période comme P3 (−47 %), aucun refus utile perdu sur l'échantillon relu	½ lot (P7-H2 l'a commencé, VAL FAIL à reprendre)	moyen : une écriture déguisée en citation passerait (à couvrir par cas adverses)
R3	Contrôles en jeu automatiques avant l'essai de l'utilisateur : relecture scriptée du journal de jeu (Accessed None, -LPPersonsLog, positions hors pièce) par cas de la fiche, PASS / FAIL avant la remise	organisation, outils	20 à 30 % des KO détectés avant l'utilisateur (les défauts « agent » sont déjà 6 sur 48 par le journal) ; −1 à −2 builds par sprint de 13	un script Tools\EssaiJournal.ps1 et un gabarit de cas	faible
R4	lp-mcp-bp en Sonnet pour les petits correctifs (essai ORGA2 § 5, gabarit de SPEC exécutable, script de relecture)	agents	jusqu'à −60 % du coût de lp-mcp-bp sur les fiches éligibles (≈ −50 à −80 M sur P3)	essai ORGA2 déjà prévu après le 2026-10-18	moyen : plus de temps d'éditeur si l'essai échoue (règle de repli ORGA2 § 5.4)
R5	Journal au fil de l'eau : brouillon CHG et ERR écrit dans le lot à chaque BUILD-FIN et à chaque KO (fichier <LOT>-JOURNAL-BROUILLON.md), versé sous jeton au commit	skills	supprime les rattrapages (JOURNAUX1-2 tenus par la session EVAL : 3 agents lp-writer en 5 passes, constat de l'orchestrateur, non chiffré) ; trou de journal ramené de ≈ 29 h à < 2 h	règle dans lp-lot et lp-doc	faible
R6	PubCheck dès la fiche : PubCheck.ps1 sur chaque livrable écrit, dans la VAL et dans le BUILD-FIN	outils	−6 refus de commit par sprint, chaîne finale plus courte	une ligne dans lp-validate et lp-lot	faible
R7	Consignes de shell dans un skill : « tester par un fichier, lire un JSON par Read ou script, jamais python -c » dans sk-windows-shell et lp-inventory ; mêmes règles pour les principales	skills	−17 refus auto-infligés et 3 arrêts d'agent par période ; −26 erreurs de guillemets	un ticket addon	faible
R8	VAL « témoin en jeu » : toute VAL PASS-STATIC d'un correctif de comportement nomme le cas de la fiche de tests qui le prouvera, et le cas est relu au bilan	agents	3 à 4 KO après PASS par sprint reliés à leur VAL ; reprises plus courtes	règle lp-validate	faible
R9	Fiches lp-cart plus étroites (une question, liste fermée de fichiers) et respect du modèle de l'agent	agents	hors budget de 79 % vers < 40 % (objectif estimé ; P2 : 55 %, doc 33 § 4)	règle déjà écrite (E5) à faire appliquer par les sessions de lot	faible
R10	Outils de copie nommés dans les fiches de sprint (CopieEtat, GitEtat) et contrôle d'instantané avant écriture (avertissement si aucun Snapshot du lot depuis le GO)	outils	−50 % des git status et empreintes à la main ; 0 instantané manquant	petit lot outil	faible
R11	Registres de lot complets (colonnes Tours, statut « acceptée ») et BOSS-JOURNAL horodaté	organisation	rend D-P7.16 et les délais décision → livraison mesurables	discipline + gabarit	nul
R12	Renommer une session réutilisée au titre du lot qu'elle sert, à chaque changement de lot	organisation	mesures et messages attribués au bon lot	une ligne dans la règle des sessions	nul
R13	Pièges de poste (MSIX, ls-remote, FicheStats.AGENTS_N3) versés dans lp-paths, lp-inventory, FicheStats	outils, skills	évite 1 à 2 reprises par lot d'inventaire	un ticket addon	nul
R14	Budget de tours du build porté à 60 quand la chaîne de vérification dépasse 50 étapes, ou vérification confiée à un lp-validator	agents	0 build hors budget	une ligne dans lp-build	nul

---

5. Décisions à soumettre à l'utilisateur (liste fermée)

#	Décision	Options	Recommandation
F1	Clause D-P7.8 sur Big Boss (coût 20,4 % des jetons, 36 % des heures > 15 %)	(a) recentrer Big Boss (R1) et remesurer sur la prochaine période ; (b) réduire Big Boss à la file de compilation comme prévu par la clause ; (c) garder tel quel	(a) : la clause visait un coût de contrôles manuels ; en P3 le coût vient surtout de la tenue des essais, déléguable
F2	Clause de retrait du crochet (CAM 12 à tort / 5 utiles ; la clause dit « refus légitimes », lu ici « refus de commandes légitimes »)	(a) crochet v2 (R2) avant le prochain lot, sans retrait ; (b) retrait comme prévu par la clause ; (c) garder tel quel	(a) : 40 refus utiles dont une vraie écriture d'asset bloquée ; l'utilisateur confirme aussi la lecture de la clause
F3	Contrôles en jeu automatiques (R3)	(a) lot outil après l'alpha ; (b) non	(a)
F4	lp-mcp-bp en Sonnet à l'essai (R4, ORGA2 § 5)	(a) essai ORGA2 comme prévu après le 2026-10-18 ; (b) non	(a)
F5	Journal au fil de l'eau (R5) et PubCheck dès la fiche (R6)	(a) un lot DOC qui porte R5, R6, R7, R8, R11, R12, R13, R14 dans les skills ; (b) au cas par cas	(a)
F6	Rotation des sessions de lot (E1 non tenu)	(a) imposer la rotation à 250 k et à chaque FIN-LOT pour toutes les sessions, avec relevé dans le BOSS-JOURNAL ; (b) inchangé	(a)
F7	Release v2026.10.2.1a non poussée	(a) pousser le tag et ue5.8 (PUB3 : publication C2) ; (b) garder en local	aucune : relève de la publication (PUB3), hors du périmètre de cette évaluation. Décision de l'utilisateur (2026-10-14, relayée par Big Boss) : « on attends pour github » → (b), la release reste en local
F8	Doc numéroté (comme le doc 33)	(a) oui, à partir de ce rapport, numéro réservé par Big Boss ; (b) non, etat\EVAL2\ suffit	(a) si l'utilisateur veut la suite des docs 31 et 33
F9	Commit des livrables EVAL2	(a) ticket gardien après F8 ; (b) maintenant	(a) si F8 = a, sinon (b)

---

6. Établi, estimé, incertain

• Établi (rejoué par script, recompté) : volumes de sessions, sous-agents, jetons, commits, tickets, CHG, ERR, refus du crochet, builds et cas des fiches de tests.
• Estimé : découvreur des défauts (nature de la ligne du bilan), classement à tort / utile (règle v2, relecture de 15 lignes), gains des recommandations, retard des journaux (borne de 29 h).
• Incertain : coût en crédits (non mesuré) ; parallélisme maximal ; comparaison à travail égal avec P0 à P2.

Fichiers à commiter (après F9)

Docs/Migration/etat/EVAL2/ : EVAL2-TACHES.md, EVAL2-STATS.md, EVAL2-RAPPORT.md, EVAL2-T1a-INV.md à EVAL2-T6-INV.md (T1a, T1b, T2, T3, T4, T5, T6), EVAL2-T9-VAL.md, data/*.csv, data/*.md (normalisés en LF après la VAL T9) ; scripts et .txt ignorés par git.

VAL : EVAL2-T9-VAL.md, PASS avec réserves (aucun FAIL) ; écarts E1 à E9 et les deux arrondis corrigés dans STATS et dans ce rapport par l'orchestrateur ; E10 (lecture de la clause du crochet) porté dans F2.

Tours : sans objet (fiche de l'orchestrateur)