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

Fiche EVAL-T8 — Niveau N2 — Modèle prévu orchestrateur (Opus 5.5) | utilisé claude-opus-5-5 — Agent session « EVAL » — Skills sk-orchestrate, sk-recount

EVAL-RAPPORT : évaluation de l'organisation multi-agents sur 72 h (2026-10-08 05:30 → 2026-10-11 05:30) (2026-10-11)

• Grille : celle des docs 22 et 26 (lots, consignes, adéquation niveau ↔ complexité, rôles, coût / bénéfice, décision, recommandations), plus les indicateurs chiffrés du doc 31 pour comparer.
• Chiffres : EVAL-STATS.md. Chaque chiffre y a sa commande et son compte brut. Ils proviennent des 7 relevés lp-inventory (EVAL-T1a à EVAL-T6), recomptés par l'orchestrateur.
• Constats qualitatifs : etat\BOSS\BOSS-JOURNAL.md (« BOSS l. N ») et les EVAL de lot OBB-EVAL.md, U8-EVAL.md, DOCMV-EVAL.md et STB-EVAL.md.
• Sous-périodes :
  • P0 : agents génériques ;
  • P1 : agents lp-*, chaque session commite ;
  • P2 : Big Boss et gardien, depuis le 2026-10-10 à 10:45.

Biais :

• Ce bilan est écrit par une session orchestrateur, qui juge une organisation dont elle fait partie.
• Les lots de P1 (U0 à U7b, migration lourde) et de P2 (ST, OB, DOC, U8) ne sont pas de même nature. La comparaison « à travail égal » est donc incertaine, comme au doc 31 § 7.
• Les débits par heure sont établis. Leur attribution à l'organisation est estimée.

---

1. Résumé exécutif

L'organisation a progressé en sûreté, en traçabilité et en débit. Elle coûte nettement plus cher à produire.

1. Débit. Par heure active, P2 produit 2,40 CHG et 4,0 commits, contre 1,81 et 3,1 en P1 (+33 % et +31 %). Douze sessions travaillent en parallèle sur une seule copie UE (parallélisme moyen 2,5), sans conflit d'asset : 0 MD5 changé à tort, 0 GO resté ouvert. L'attente médiane dans la file est de 0,4 min.
2. Qualité d'exécution.
   • Le taux d'erreur des outils passe de 3,3 % à 1,6 %.
   • Les fiches de sous-agents sont plus petites : 16,5 tours médians contre 27, et 17 % hors budget contre 26 %.
   • Le dépôt est propre : 0 commit sans ticket, 82 verrous pris et 82 rendus, R-REPO1 appliquée.
   • La ligne Tours : figure dans 71 % des livrables, contre 6 %.
3. Coût.
   • Les jetons par heure active ont été multipliés par 2,3 (56 → 130 M) et les jetons par CHG ont presque doublé (31 → 54 M).
   • La hausse vient des sessions principales (×3,1 par heure), pas des sous-agents, qui restent stables à 21,7 M/h.
   • Les sessions principales Opus tournent avec un contexte médian de 323 k par tour. Elles exécutent elles-mêmes des contrôles mécaniques : MD5, processus, git status, verrou.
   • Elles portent les 1 070 appels MCP, parce qu'aucun agent lp-* n'a d'outil MCP.
   • Big Boss seul représente 18 % des jetons de P2.
4. Charge de l'utilisateur. Les messages humains par heure active montent de 7,3 à 10,0 ; ils restent stables par CHG (4,4 → 4,25). Les sessions échangent 36 messages par heure en P2, contre 6 en P1.
5. Niveaux. Les agents de réalisation sont bien dimensionnés dans l'ensemble. Le principal défaut d'adéquation est inverse : le niveau N2 Opus fait du travail N0. Deux zones restent fragiles :
   • lp-cart (55 % hors budget, 40 % des jetons des sous-agents) ;
   • les VAL et EVAL lourdes confiées à des N1 Sonnet (pics de 221 à 329 k).
6. Les reprises viennent des consignes, pas des agents. C'était déjà le constat des docs 22 et 26.
   • OBB : 4 reprises sur 4 ont pour cause la consigne.
   • U8 : 2 écarts de fiche.
   • Critères recopiés d'une fiche à l'autre : R7 « 0 processus », .rsp daté, -nodebuginfo omis.

Décision proposée : GO pour garder Big Boss et le gardien. GO conditionnel pour le reste.

• Condition 1 : sortir les contrôles mécaniques et le MCP des sessions principales.
• Condition 2 : faire tourner les sessions longues avant leur pic de contexte.
• Les recommandations R1 à R3 (§ 8) chiffrent ces deux conditions.

---

2. Lots de la période

Comptes : sous-agents (T1b), commits distincts (T2), CHG (T3), livrables .md modifiés dans la fenêtre (T5). Verdicts : registres et EVAL de lot.

Lot	P	Sous-agents	Jetons des sous-agents	Commits	CHG	Livrables	Verdict, état
U0-U7b (migration UE 5.8)	P1	65	386 M	23	9	70	clos ; 2 escalades (U7-T6, U7-T7) ; U7-T7 = 69,8 M à lui seul
STA, STB, STC, STD	P1	26	84 M	18	1	36	clos ; STB-MEN retiré après régression en jeu (ERR-057)
OBA	P1	7	33 M	0	0	8	GO conditionnel (OBA-T5-EVAL)
ETAT2, ETAT3, OUT1, SK, TPL1, EDIT1-3, BUD1, SEQ1 (méthode)	P1	19	46 M	36	13	23	clos
STE (moteur de scènes, GI)	P2	30	109 M	4	9	47	ouvert ; 25 BUILD-GO, le plus gros client de la copie UE
OBB (bloquants de publication)	P2	26	33 M	7	4	27	GO conditionnel (OBB-EVAL) ; 4 reprises, cause consigne
U8 (reprise, candidat V2.0)	P2	23	47 M	8	5	41	jusqu'à T10 ; T11 à l'utilisateur (U8-EVAL)
STF, LISIB (UI)	P2	15	25 M	5	4	27	STF clos (J1 conforme) ; LISIB commité
AG/AR, OBP, DOCMV, DOCSTAT, README (organisation, docs)	P2	28	25 M	21	7	47	clos ; 1 incident --amend (ERR-087)
CAM (audit caméras)	P2	6	33 M	0	0	9	phase 1 livrée, non commitée ; 1 escalade (CAM-T5, opus-xhigh, 477 k)

Sources : EVAL-STATS.md § 1, § 3 ; data\fiches-lots.csv, data\commits.csv, data\chg.csv, data\subagents.csv.

---

3. Qualité des consignes et des passages entre agents

Ce qui a marché

• Liste de décisions fermée avant l'exécution : U8 a présenté D1 à D9 en une fois (U8-EVAL.md § 2), et DOCMV a présenté D1 à D5 en une fois (BOSS l. 90). Cela évite les allers-retours en cours de lot.
• Inventaire chiffré avant d'agir : DOCMV a relevé 1 190 références et simulé 22 liens cassés ; ce sont exactement ceux qui ont été corrigés (DOCMV-EVAL.md § 4).
• VAL indépendantes qui trouvent de vrais écarts :
  • DOCMV E1 (14 commentaires sous Plugins\) ;
  • U8-T7 (R1, R5, R10) ;
  • STF-T4 (PIE conforme, 0 écart sur 14 variables).
• Recomptage à la réception : il a corrigé ou confirmé chaque compte rendu U8 (U8-EVAL.md § 2). Pour cette EVAL, les 7 relevés ont été recomptés sans écart de total (EVAL-STATS.md § 9).

Ce qui coince

• Critères recopiés d'une fiche précédente. Trois cas :

  • OBB-R7 reprend le « 0 processus Unreal » d'OBB-R6, alors qu'un éditeur d'une autre copie tournait (BOSS l. 120) ;
  • OBB-T7b omet -nodebuginfo, absent du modèle cité ;
  • OBB-T7a et U8-T2r2 exigent un « .rsp / exe daté de ce build », ce qui est faux quand seul le contenu change (OBB-EVAL.md § 4 ; U8-EVAL.md § 3.1).

  Toutes les reprises d'OBB ont une cause de consigne (4 sur 4 ; budget 0, capacité 0).

• Faisabilité non vérifiée avant de solliciter l'utilisateur : U8-T6 (réglage absent de la V1.5) a coûté une session de jeu puis a été annulée (U8-EVAL.md § 3.3).

• Registres hors gabarit (T5) :

  • 64 statuts « faite » ;
  • 0 statut reprise ou escaladée, alors que 20 lignes de tentative b/c/d existent ;
  • colonnes Pic remplies à 11 % ;
  • « État de reprise » présent dans 1 livrable sur 233.

  Le registre ne permet donc pas de suivre les indicateurs de sk-orchestrate § 5 sans relecture.

• Tours sous-comptés par les agents : OBB en relève 12 cas sur 15, et cette EVAL un cas (T4 : 37 déclarés, 39 mesurés). FicheStats fait foi (OBB-EVAL.md § 3, P11).

---

4. Question 1 : le niveau des agents est-il adapté à la complexité des tâches ?

Rôle (modèle)	Constat chiffré	Appréciation
Sessions principales (Opus, N2)	P2 : 3 425 appels d'outils, dont 2 966 shell sur la fenêtre. Familles mécaniques faites par les principales : état git 827, verrou et tickets 363, empreintes 256, processus 216, tailles de build 128 (T6 § 2.2). Contexte médian par tour 323 k. 1 070 appels MCP Unreal (STE 404, Lot 29 470)	Sur-dimensionné pour ce travail. Chaque contrôle est payé au prix d'un tour Opus à environ 300 k de contexte. Estimé : environ 1 800 appels × environ 300 k ≈ 0,5 G jetons, soit environ 22 % des jetons des principales. Cause structurelle du MCP : aucun agent lp-* n'a d'outil MCP (frontmatters de ~/.claude/agents)
lp-builder (haiku, N0-N1)	52 passages, 10 % hors budget ; chaînes complètes dans le budget (U8-T2r-T5br : 37 tours) ; pièges bien signalés (U8-EVAL.md § 4)	Adapté
lp-gardien (sonnet, N1)	48 passages, 0 % hors budget, 11 tours médians, 1,4 min, 0,7 M par passage ; 1 incident --amend (DOCMV-R3, ERR-087) ; 1 refus justifié (CRLF de STF-R2)	Adapté. Haiku est envisageable pour les tickets TAG et CONFIG seulement. Pour un COMMIT, l'incident --amend plaide pour garder sonnet
lp-validator (sonnet, N1)	42 passages, 19 % hors budget ; les plus utiles sont aussi les plus lourdes : U8-T7 221 k, STF-T4 83 tours et 329 k, STE-VAL 278 k	Adapté pour une VAL bornée. Sous-dimensionné ou fiche trop large pour une VAL de lot (relecture de nombreux livrables) : découper en 2 VAL, ou passer N2
lp-writer (sonnet, N1)	28 passages, 14 % hors budget ; les dépassements touchent la synthèse (OBB-EVAL 242 k, U8-T8b README public 174 k) ; refus d'autorisation sur le journal (OBB-T7d)	Adapté pour un CHG ou une doc courte ; limite pour une EVAL (synthèse critique : N2, comme le recommandait déjà le doc 26 § 4)
lp-inventory (sonnet, N1 ; haiku en surcharge)	17 passages + 7 pour cette EVAL. Les relevés EVAL : 6 sur 7 hors budget de pic (163 à 315 k), tours dans le budget (17 à 39) ; haiku (T3) a tenu à 17 tours mais avec un pic de 163 k	Adapté en capacité. Fiches EVAL trop larges (faute de consigne de l'orchestrateur) ; la lecture de transcriptions de plusieurs Mo dépasse 150 k
lp-cart (opus xhigh, N3)	38 passages, 55 % hors budget, 48 tours et 243 k médians, 40 % des jetons des sous-agents ; STE-H3c à H5c entre 254 et 411 k	Niveau adapté (diagnostic de chaîne d'appels). Fiches trop larges : la règle « une hypothèse par fiche » n'est pas tenue sur STE
lp-impl (opus xhigh, N3)	16 passages, 56 % hors budget, surtout en P1 (U1, U4, U7b)	adapté ; la taille est le seul problème
Escalades	4 (U7-T6, U7-T7, OBA-T5, CAM-T5), toutes hors budget ; fable-top jamais utilisé ; U7-T7 : 195 tours, 618 k, 69,8 M (8 % des jetons des sous-agents)	escalade correctement réservée ; U7-T7 aurait dû être coupé en plusieurs fiches (doc 31 § 5 le relevait déjà)
general-purpose	14 en P0, 0 depuis	sortie complète des agents génériques

Surdimensionnements :

• sessions Opus N2 qui font du N0 (contrôles, verrou, MCP de lecture) ;
• lp-cart xhigh sur des relectures de dumps faisables en N1.

Pour le second cas, à confirmer fiche par fiche : 6 fiches STE lp-cart ont un niveau « N3? », déduit de l'agent et non écrit dans la fiche.

Sous-dimensionnements :

• VAL et EVAL de lot confiées en N1 ;
• fiches d'inventaire de transcriptions en N1 avec 150 k de pic.

Échecs à reprendre :

• 2 sous-agents coupés sans compte rendu : lp-builder STE-D, arrêté parce que sa session « Lot 29 » a été fermée (BOSS l. 73), et lp-gardien OBB-R11, ticket abandonné ;
• 0 échec fabriqué établi ;
• aucune fiche au 4e échec.

---

5. Question 2 : l'orchestration est-elle plus efficace qu'avant (docs 22, 26, 31) ?

Axe	Doc 22 / 26 (S0-S8, VQ)	Doc 31 « après »	P2 (Big Boss + gardien)	Sens
Modèle tracé dans les fiches	12 / 28 (22 § 4)	97 %	90 % (en-tête complet, 5 champs)	✔ acquis
VAL par lot	VQ1 sans VAL (26)	10 / 10	12 / 17 registres	≈
Git clos par lot	« rien commité » (22 § 6, 26 § 2)	—	47 commits, 0 sans ticket, 0 verrou non rendu, tags d'avant-lot	✔ net progrès
Conflits sur la copie UE	non mesurés (une session)	—	0 MD5 changé ; 2 GO simultanés formels de 1,4 et 2,8 min	✔
Erreurs d'outils	—	3,6 %	1,6 %	✔
Taille des fiches de sous-agents	—	40 tours en moyenne, 84 % des jetons au-dessus de 150 k	19,6 tours, 63 %	✔
CHG / h active	—	1,2	2,40	✔
Jetons / h active	—	47,6 M	130,2 M	✘ ×2,7
Part des appels faits par les sous-agents	—	72 %	57 %	✘ l'exécution remonte vers les principales
Messages humains / h	—	6,1	10,0	✘
Messages entre sessions / h	—	—	36	coût nouveau

Apport de Big Boss (T4, BOSS-JOURNAL)

• File de la copie UE :
  • 38 GO distincts pour 6 lots, attente médiane 0,4 min, max 19,5 min ;
  • copie occupée 62 % du temps, libre 33 %, gelée 6 % ;
  • la file n'est pas un goulot. Sa valeur est la sûreté : 32 BUILD-FIN contre-vérifiés, 0 MD5 changé, 0 GO perdu ;
  • les 692 min de GO ouverts ne correspondent qu'à 268 min de temps machine : un GO couvre aussi le PIE avec l'utilisateur et l'analyse. La file restera fluide tant que le nombre de lots qui la demandent reste faible.
• Réserve « mesure » : posée 4 fois (U8-T5cr, U8-T5cr2, STE-H4, STE-H9), 41 min. Elle a protégé les mesures après un premier chevauchement (U8-T5cr joué machine chargée, U8-EVAL.md § 3.5 ; BOSS l. 223-224).
• Jeton du journal :
  • 14 jetons accordés, attente médiane 0,3 min, aucune collision sur Journal_Modifications.md ;
  • règle « CHG écrit seulement quand le commit est imminent » (BOSS l. 117), tenue ;
  • un ordre a été inversé en cours de route (OBB avant AR, BOSS l. 86) : il a coûté une consigne double à OBB-T3d.
• Arbitrages :
  • 14 CONFLIT, 12 ARBITRAGE, 9 GEL (dont le gel documentaire DOCMV, tenu : DOCMV-EVAL.md § 4), 18 FIN-LOT ;
  • règles produites et adoptées : R-REPO1, réattribution des traces, protection de MainMenu, jeton du journal.
• Contrôles de commit : git show --name-status contre la liste du ticket à chaque JOURNAL-LIBRE (BOSS l. 91, 92, 104, 119, 126).
• Erreurs de Big Boss :
  • retard reconnu (« c'est toi qu'AR attend », BOSS l. 110) ;
  • messages croisés (4 cas) ;
  • consignes arrivées après le lancement d'un test (U8-T5cr).
• Coût : 8 h actives, 679 tours, 272 M jetons (18 % de P2), 287 messages sortants, 27 messages de l'utilisateur. Le coût par passage dans la file (environ 272 M / 38 GO, soit environ 7 M) est élevé parce que chaque contre-vérification se fait à la main (Bash 282, PowerShell 47) dans un contexte de 345 k médians.

Verdict. L'orchestration est plus sûre et plus rapide (débit +33 %, erreurs −50 %, dépôt propre). Elle n'est pas plus économe : environ 54 M de jetons par CHG contre environ 31 M, et l'utilisateur est sollicité un peu plus par heure. Le gain de débit vient du parallélisme rendu sûr par Big Boss. La perte d'économie vient de sessions principales trop longues qui exécutent elles-mêmes.

---

6. Question 3 : quelles tâches mutualiser (outils, process, skills, agents) ?

Chiffres : T6 (familles de commandes) et T4 (journaux de la copie UE). Les pièges proposés par U8 (U8-EVAL.md § 5) et l'extension de FicheStats (U8-T9-STATS.md) sont déjà soumis à l'utilisateur : ils sont repris ici par renvoi, sans être dupliqués (consigne de Big Boss).

#	Tâche répétée (mesure)	Proposition	Type
M1	Contrôle d'entrée et de sortie de la copie UE : MD5 de 2 à 4 assets, processus Unreal de la copie, git status -- Content Config Source, dossiers parasites sous etat\. 543 empreintes + 455 contrôles de processus + une part de l'état git ; 538 md5sum / Get-FileHash contre 60 FileCheck.ps1, 452 Get-Process / tasklist contre 161 UeState.ps1 ; refaits par la session puis par Big Boss	Tools\CopieEtat.ps1 -Lot <LOT> -Assets <liste> : appelle UeState.ps1 (filtré sur la copie, piège P9), FileCheck.ps1, git status des 3 dépôts et le contrôle du dossier etat\. Sortie en une ligne ou en JSON, jointe à BUILD-DEMANDE et BUILD-FIN ; Big Boss la relance une fois au lieu de 3 à 5 commandes	outil + process
M2	Travail MCP Unreal dans les sessions Opus : 1 070 appels (STE 404, Lot 29 470)	agent lp-mcp (lecture N1 sonnet ; écriture BP N3) dont les tools: listent les outils mcp__unreal-mcp__*, avec les skills lp-mcp et sk-change-safety. Essai préalable : un sous-agent peut-il appeler le serveur MCP de la session ? (incertain)	agent
M3	Contexte des sessions principales : médiane 323 k par tour en P2 ; STE 995 tours (pic 898 k), Big Boss 679 tours (pic 825 k)	règle de rotation : passation (hand_off, note de passage, registre) à chaque FIN-LOT, ou dès 250 k de contexte médian. Big Boss repart chaque matin de BOSS-JOURNAL.md, qui porte tout l'état	process
M4	Verrou, tickets, NUMEROS.md : 1 085 appels en P2, dont 141 mkdir / New-Item / Remove de verrou et 292 accès à NUMEROS.md	Tools\Verrou.ps1 -Prendre / -Rendre / -Etat et `Tools\Numero.ps1 -Reserver CHG	ERR
M5	État git et fins de ligne multi-dépôts : 1 794 appels, de 8 % à 36 % des appels shell	Tools\GitEtat.ps1 : status, diff --name-status, ls-files --eol, comptes de CR, pour jeu, addon et Modules (--git-dir), 1 ligne par fichier. Peut fusionner avec M1	outil
M6	Protocole Big Boss (BUILD-*, réserve « mesure », jeton, DÉCLARATION) : présent seulement au doc 32 § 15, 0 occurrence dans les skills (grep) ; chaque session le réapprend, ce qui donne des messages croisés et des consignes tardives	section « Copie UE partagée » dans lp-lot (ou skill sk-boss) avec les gabarits de message, les contrôles exigés et CopieEtat.ps1	skill
M7	Redumps de commandlets : 129 lancements LPDumpFunction (103 min machine), souvent sur GI.uasset (STE-D, D2, D4, D5, D6, D9, CAM-T4, CAM-T6)	cache de dumps indexé par le MD5 de l'asset : RunCommandlet.ps1 -Cache réutilise un dump dont l'asset n'a pas changé (gain machine et file à mesurer, estimé)	outil
M8	Analyses Python ad hoc : 282 heredocs (201 en principale), 189 python -c longs, 135 scripts temporaires ; piège heredoc et \ signalé 3 fois (notes README, U8, ERR U+0082 dans un registre)	bibliothèque Tools\AgentStats.py, reprise des 7 scripts EVAL, de Saved\STAT1\ et de FicheStats ; règle : script en fichier, jamais en heredoc (à porter dans sk-windows-shell)	outil + skill
M9	Registres TACHES remplis à la main : colonnes de mesure remplies de 11 à 41 %, 64 statuts hors gabarit	FicheStats.py --registre <LOT>-TACHES.md remplit Tours / Pic / Jetons / Durée. Extension des identifiants (suffixes, -R<n>, -DOC) : renvoi à U8-EVAL.md § 5 et U8-T9-STATS.md	outil
M10	Skills en 3 copies (~/.claude/skills, addon 5.5, addon 5.8) : 15 paires de commits jumeaux dans l'addon en 72 h ; jonction 5.8\.claude\skills vers l'arbre 5.5	dépôt de méthode unique (D-REPO2, déjà proposé au doc 32 § 1.4)	process
M11	Pièges d'EVAL non portés dans les skills : U8-EVAL.md § 5 (AutomationTool exiting, cmd.exe /c, Saved réel) ; heredoc / chr(92) absent des skills (grep 0). La plupart des pièges d'OBB-EVAL § 6 sont portés (nodebuginfo, Win32_Process, ^{commit}, $rel)	conserver le circuit « EVAL → lot de report dans les skills » (comme OBP) ; un seul lot de report par jour	process
M12	Contrôles de taille et de date de build : 252 appels	option -Taille de CheckPackage.ps1	outil

Ce qui est déjà mutualisé et adopté (T6 § 2.3) : 9 scripts créés pendant la fenêtre sont cités de 30 à 161 fois (UeState.ps1, Build.ps1, Engine.ps1, FileCheck.ps1, EtatDir.ps1, uasset58.py, CheckPackage.ps1, FicheStats.py, uasset.py). Le frein n'est pas l'absence d'outil mais son adoption : pour les empreintes et les processus, les commandes improvisées restent 3 à 9 fois plus nombreuses que l'outil. Les fiches doivent nommer l'outil en rubrique 4.

Pas d'agent en plus pour l'instant : managers (D-AG2) et planificateur ajouteraient des messages et des sessions alors que le coût est déjà dans les sessions principales. À reconsidérer après R1-R3.

---

7. Question 5 : ce qui marche, ce qui coince (constats datés et sourcés)

Ce qui marche

Date (2026)	Constat	Source
10-08 13:30 →	sortie complète des agents génériques (14 en P0, 0 ensuite) ; en-têtes complets dans 90 à 96 % des livrables	T1b, T5
10-09	outils communs créés (UeState, FileCheck, EtatDir, FicheStats, Build) puis adoptés (30 à 161 citations)	T6 § 2.3
10-10 10:45 →	une seule session à la fois sur la copie UE : 38 GO, 0 MD5 changé, attente médiane 0,4 min	T4
10-10 11:48-12:2x	gel documentaire DOCMV (41 déplacements) tenu sans écriture concurrente, levé à la FIN-LOT contre-vérifiée	BOSS l. 92-100 ; DOCMV-EVAL.md
10-10	gardien : 63 tickets, 0 verrou non rendu, R-REPO1, ordre addon → jeu, --amend encadré après ERR-087	T2 ; BOSS l. 63, 103, 122
10-10 12:36	Big Boss relève lui-même l'état d'un ticket au lieu d'attendre le message (leçon tirée de l. 110)	BOSS l. 115
10-10 13:02-13:14	enchaînement serré sur la copie UE : archive Development commune STF + STE, Shipping OBB, STE-TXT, sans conflit	BOSS l. 130-134
10-10 → 11	réserve « mesure » : 4 créneaux, mesures U8 et STE rejouées sur machine calme	BOSS l. 222, 227, 259, 270 ; T4 § 2.5
10-10 → 11	refus d'autorisation signalés, jamais contournés par une autre session (doc 32 § 15.7)	BOSS l. 145-157 ; OBB-EVAL.md § 5

Ce qui coince

Date (2026)	Constat	Source
10-10 → 11	sessions principales trop longues : STE 995 tours (898 k), Big Boss 679 (825 k), contexte médian 323 k en P2 ; jetons des principales ×3,1 par heure	T1a
10-10 → 11	contrôles mécaniques faits à la main par les sessions Opus et refaits par Big Boss (MD5, processus, git status)	T6 ; T4 § 2.7
10-10 → 11	MCP réservé aux sessions principales (aucun agent lp-* ne l'a) : 1 070 appels dans des contextes de 400 k et plus	T1a ; ~/.claude/agents
10-10 11:15	session fermée en cours de GO (Lot 29, STE-D interrompu à 6 / 14) ; sous-agent coupé sans compte rendu	BOSS l. 73 ; T1b
10-10 12:2x	Big Boss en retard sur un signal attendu (AR bloqué)	BOSS l. 110
10-10 12:41	critère « 0 processus Unreal » recopié (OBB-R7) : 1 refus du gardien, 50 k perdus	BOSS l. 120 ; OBB-EVAL.md § 4.1
10-10 13:28-13:36	refus d'autorisation sur le journal pour un sous-agent (3 catégories de message), levé par ordre direct de l'utilisateur	OBB-EVAL.md § 5
10-10 15:02-15:33	verrou 59 orphelin pendant 31 min, libéré par Big Boss avec l'accord de l'utilisateur	BOSS l. 181 ; T4
10-10 20:09-20:18	test de l'utilisateur pendant les commandlets STE-D4 : mesure U8 perturbée	BOSS l. 223-224
10-10 20:37-20:48	Saved réel de l'utilisateur réécrit (jeu lancé sans -UserDir)	U8-EVAL.md § 3.4 ; BOSS l. 257
10-10 21:40, 22:23	jeux de l'utilisateur pendant des GO de STE (5 « processus étrangers » au total)	T4 § 2.8
10-11 00:59	-EtatDir relatif : dossier parasite etat\Docs\Migration\etat\CAM\	BOSS l. 255 ; T4
10-10 → 11	registres : statuts hors gabarit, mesures absentes, reprises non marquées ; tours sous-comptés	T5 ; OBB-EVAL.md § 3
10-10 → 11	hook pre-commit non installé dans les 4 arbres	T2
10-11	cette EVAL : 6 fiches sur 7 hors budget de pic (fiches trop larges)	EVAL-STATS.md § 8

---

8. Recommandations chiffrées, classées par gain attendu

Les gains sont estimés : ordres de grandeur calculés sur P2. Ils seront à remesurer avec les mêmes scripts (EVAL-STATS.md).

Rang	Recommandation	Gain attendu (estimé)	Coût	Mesure de contrôle
R1	Rotation des sessions principales (M3) : passation à chaque FIN-LOT ou dès 250 k de contexte ; Big Boss repart chaque jour de son journal	contexte médian des principales de 323 k vers environ 180 k : −35 à −45 % des jetons des principales, soit environ 450 à 550 M sur une période comme P2	nul (règle) ; une note de passage par session	contexte médian par tour < 200 k ; jetons / h des principales
R2	Sortir les contrôles mécaniques des sessions Opus (M1, M4, M5) : CopieEtat.ps1, Verrou.ps1, GitEtat.ps1, nommés en rubrique 4 des fiches et dans le protocole Big Boss	environ 1 800 appels de principales en moins, soit environ 0,4 à 0,5 G jetons ; contre-vérification de Big Boss en 1 commande au lieu de 3 à 5 : environ −30 % de ses appels shell	1 lot outil (IMPL N1 + VAL), environ 3 h	part des appels faits par les sous-agents > 70 % ; appels md5sum / tasklist directs < 20 % de leur famille
R3	Agent lp-mcp (M2) après un essai d'accès MCP depuis un sous-agent	1 070 appels MCP sortis des contextes de 400 k et plus : environ 0,3 G jetons sur la fenêtre	essai de 30 min, puis frontmatter d'agent	appels MCP des principales / appels MCP totaux
R4	Protocole Big Boss dans un skill (M6) avec gabarits de message	moins de messages croisés et de consignes tardives : 4 cas et 1 retard en 18 h ; −20 % des messages entre sessions (estimé)	1 DOC	messages entre sessions par CHG (15 en P2)
R5	Fiches : vérifier critères et faisabilité avant envoi (règle « ne pas recopier un critère d'entrée ; nommer la copie visée ; tester la faisabilité d'un test utilisateur ») dans sk-orchestrate § 3	moins de reprises de cause consigne (4 sur 4 chez OBB) et de sessions de jeu perdues (U8-T6)	1 DOC	reprises de cause consigne / fiches
R6	Découper les VAL de lot et les diagnostics lp-cart (une VAL par famille de livrables ; une hypothèse par fiche) ; EVAL de lot en N2	lp-cart hors budget de 55 % vers environ 25 % ; VAL hors budget de 19 % vers environ 10 %	nul	% hors budget par agent (FicheStats)
R7	Registre outillé (M9) : FicheStats remplit les colonnes ; statuts du gabarit seulement ; extension des identifiants par renvoi à U8	indicateurs § 5 de sk-orchestrate lisibles sans relecture ; temps d'EVAL réduit	petit IMPL	colonnes remplies > 90 %
R8	Cache de dumps (M7)	une partie des 103 min de LPDumpFunction et des GO associés (à mesurer)	IMPL N1 dans RunCommandlet.ps1	lancements de dump par asset inchangé
R9	Dépôt de méthode unique (M10, D-REPO2)	fin des commits jumeaux (15 paires en 72 h)	lot AG suivant	commits addon par changement de skill = 1
R10	Hygiène de l'utilisateur sur la copie partagée : signaler à Big Boss tout lancement de jeu pendant un GO ; lancer les jeux par .bat avec -UserDir	5 incidents « processus étranger » et 1 réécriture du Saved réel évités	nul	incidents par période
R11	Hook pre-commit installé (déjà conçu dans REPO\hooks)	défense en profondeur après ERR-087	1 ticket CONFIG	core.hooksPath défini
R12	Budget de pic des inventaires de transcriptions : découper (une famille d'indicateurs par fiche) plutôt que relever le plafond	budget respecté par les prochaines EVAL	nul	fiches EVAL hors budget

Pour R1 à R3, l'ensemble vise à ramener le coût par CHG vers environ 30 M (niveau de P1) tout en gardant le débit de P2. Ce n'est pas une garantie : les gains se recouvrent en partie (incertain).

---

9. Décisions à prendre (liste fermée, l'utilisateur décide)

#	Décision	Options	Recommandation
E1	Rotation des sessions principales (R1)	(a) à chaque FIN-LOT + seuil de 250 k ; (b) seuil seul ; (c) non	(a)
E2	Lot outil « copie partagée » (R2 : CopieEtat, Verrou, GitEtat)	(a) un lot maintenant, rangé dans la file de Big Boss (hors copie UE) ; (b) après la porte T11 d'U8 ; (c) non	(a)
E3	Essai puis agent lp-mcp (R3)	(a) essai de 30 min puis agent si l'essai passe ; (b) non	(a)
E4	Big Boss	(a) garder Opus + rotation quotidienne + contrôles scriptés ; (b) passer en sonnet ; (c) inchangé	(a) : ses arbitrages sont du N2, ses contrôles deviennent des scripts
E5	Protocole Big Boss et règles de fiche dans les skills (R4, R5)	(a) un lot DOC qui porte lp-lot et sk-orchestrate ; (b) non	(a)
E6	Doc numéroté Docs\33_Eval_Organisation_72h.md (comme les docs 22, 26, 31)	(a) oui, à partir de ce rapport ; (b) non, etat\EVAL\ suffit	(a) si l'utilisateur veut une trace publique de la méthode
E7	Commit des livrables EVAL (ticket gardien + CHG sous jeton)	(a) oui ; (b) après E6	(b) si E6 = a, sinon (a)

Décisions déjà ouvertes ailleurs, non dupliquées ici : D-AG1 à D-AG8 (doc 32 § 13) ; pièges et FicheStats proposés par U8 (U8-EVAL.md § 5).

Fichiers à commiter (après décision E7) : Docs/Migration/etat/EVAL/EVAL-TACHES.md, EVAL-STATS.md, EVAL-RAPPORT.md, EVAL-T1a-INV.md à EVAL-T6-INV.md (T1a, T1b, T2, T3, T4, T5, T6), data/*.csv, data/aggregats.md, data/tableaux.md. Les scripts et les .txt sont ignorés par git (.gitignore:75).

Tours : sans objet (fiche de l'orchestrateur)