LifePlay-Revival/Docs/Migration/etat/EVAL2/EVAL2-RAPPORT.md
edujiro5972 8084622450 LifePlay UE 5.8 : état de développement au 2026-10-19
Tickets : REP1-T4

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-19 22:57:42 +02:00

155 lines
18 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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)