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)