LifePlay-Revival/Docs/Migration/etat/AG/PIPE1/PIPE1-REVUE-02.md

Fiche PIPE1-REVUE-02 — Niveau N3 — Modèle prévu opus xhigh | utilisé claude-opus-5-5 — Session Medium-xHigh · PIPE1
# PIPE1-REVUE-02 : revue critique du barème PIPE1-SPEC-02 (2026-10-15)

Révision du 2026-10-15 (demande de l'utilisateur) : le § 4 est remplacé par `PIPE1-REVUE-02-MODELE.md` (grille
question × enjeu). F14 et l'état de M4 y sont corrigés : base O0 et critères du projet, export Insights sans interface
éprouvé en 5.5 (F15 à F18).

Objet : `AG\PIPE1\PIPE1-SPEC-02-BAREME.md` (barème des demandes de mesure → palier M0 à M4). Revue faite seule, sans
sous-agent. Lecture seule : aucun skill ni autre fichier modifié, aucun éditeur, build, jeu ni téléchargement, aucun git
qui écrit. Niveaux : **établi** (fichier:ligne relu pendant cette revue, entrée de BC établie), **estimé** (déduction),
**incertain** (non vérifiable sans essai).

## 0. Verdict en bref

- Le score additif est **à remplacer** : il envoie une question de fonction (A3) vers M1, qui n'y répond pas, et il
  met dans le score de départ un critère (D, doute) qui n'existe qu'après une première mesure (§ 3).
- Deux faits d'outillage sont faux : **la build Test n'existe pas avec le moteur du lanceur** (F2), et **`-csvprofile`
  n'est pas une option de ligne de commande** ; l'option voisine `-csvCaptureFrames` est proscrite par le projet (F5, F6).
- M0 n'est pas « sans prérequis » : il faut une build Development, une partie jouée et `-LPHitchLog` (F10, F11).
- M2 n'est pas un cran au-dessus de M1 : il répond à une autre question (cadence de la Shipping). Le joindre à M1
  pour G3 / G4 coûte un palier non éprouvé sans rien prouver de plus.
- Les budgets de M1 (≈ 30 k) et de M1 + M2 (≈ 50 k) sont sous le coût fixe d'un agent neuf (55 à 140 k) : ils ne
  tiennent que **sans agent**, par un script lancé par la session (§ 6).
- Le projet a déjà des lanceurs de mesure (Session C pour le CSV, Session A pour Insights) que le barème ignore :
  les reprendre coûte moins que de réinventer les recettes (F7).

## 1. Faits vérifiés (moteur 5.8 local `D:\Game\Launcher\Engine\UE_5.8\Engine\`, projet)

| # | Fait | Preuve | Niveau | Effet sur le barème |
|---|---|---|---|---|
| F1 | CSV Profiler compilé partout sauf en Shipping (donc en Development et en Test) | `Source\Runtime\Core\Public\ProfilingDebugging\CsvProfilerConfig.h:9-10, :30-31` | établi | M1 possible en Development |
| F2 | Le moteur installé n'a pas de configuration Test pour un jeu Win64 : seulement DebugGame, Development, Shipping | `Config\BaseEngine.ini:4002-4007` ; dossier `Intermediate\Build\Win64\x64\UnrealGame\` = DebugGame, Development, Shipping | établi (le refus d'UBT sur `-Config Test` est estimé, non essayé) | retirer « Test » de M1 ; la build instrumentée est Development, plus lente donc pessimiste (R4-11) |
| F3 | `StartFPSChart` / `StopFPSChart` hors Shipping ; fichiers écrits si `ALLOW_DEBUG_FILES` (1 en Development et en Test) ; sortie `Saved\Profiling\FPSChartStats\` | `Source\Runtime\Engine\Private\UnrealEngine.cpp:5752` (`#if !UE_BUILD_SHIPPING`) à `:5826-5828`, `:6664-6665` ; `Core\Public\Misc\Build.h:260-261, :288-289, :316-317` ; `ChartCreation.cpp:1243` | établi | utilisable en Development ; redondant avec le CSV : le FPS chart démarre lui-même une capture CSV si son réglage le demande (`ChartCreation.cpp:27-28, :1561-1573`). Option, pas socle |
| F4 | `-ExecCmds` n'est lu que hors Shipping (ou en build PGO) | `UnrealEngine.cpp:2543, :2552` | établi | la build alpha Shipping ne se pilote pas par commandes : seule une mesure externe (M2, M3) la voit |
| F5 | Aucune option de ligne de commande `-csvprofile` : `CsvProfile` est le nom de la commande console ; options lues : `csvCaptureFrames=`, `ExitAfterCsvProfiling`, `csvGpuStats` | `Core\Private\ProfilingDebugging\CsvProfiler.cpp:1118` (commande) ; `:5049, :5177`, `:4309`, `:5098` (options) | établi (absence : grep sur `CsvProfiler.cpp` et `Engine\Private`) | écrire `-ExecCmds="csvprofile frames=N"` |
| F6 | `-csvCaptureFrames` est proscrit sur ce projet : la capture démarre avant le RHI et le moteur s'arrête | `Docs\09_Commandes_Utiles.md:167` ; `Docs\18_Build_Debug.md:66` ; `Docs\19_Plan_Outillage_Debug.md:159` ; `etat\BASES\REF\REF-OPERATIONNEL.md:20` | établi | la recette `lp-perf\recettes\csvprofile.md:14` le contredit (suite S1) |
| F7 | Lanceurs existants, déposés par `BuildDebug.ps1` : Session C (`-csvGpuStats -llm -llmcsv -ExecCmds="csvprofile repeat=20, csvprofile frames=9000"`), Session A (`-trace=cpu,frame,bookmark,loadtime,memory -statnamedevents -tracefile=… -LPHitchLog`) ; synthèse `Tools\SummarizeDebugCsv.ps1` (médiane FrameTime, images longues) | `Tools\debug\LifePlay_debug_sessionC_profil.bat:2-5` ; `LifePlay_debug_sessionA_insights.bat:7` ; `Tools\LISEZMOI.md:25, :35` | établi (existence) ; essai connu en 5.5 seulement, d'après l'exemple `LifePlay_Backup_5.5\Dbg-I6\SessionC` (`SummarizeDebugCsv.ps1:6`) : estimé | M1 et M4 ont déjà une recette du projet, à éprouver en 5.8 |
| F8 | Insights (trace) actif par défaut hors Shipping sous Windows, avec traces CPU et GPU | `Source\Programs\UnrealBuildTool\Configuration\Rules\TargetRules.cs:1327-1345` ; `Runtime\TraceLog\Public\Trace\Config.h:12-17` ; `Core\Public\ProfilingDebugging\CpuProfilerTrace.h:19-24` ; `RHI\Public\GpuProfilerTrace.h:13` | établi | M4 possible en Development ; la lecture d'un `.utrace` passe par l'interface (humain) ou par un export sans interface non vérifié en 5.8 (R4-09) |
| F9 | En Test, `STATS` vaut 0 par défaut ; la console reste active | `Build.h:314, :319-320` | établi | sans objet après F2 |
| F10 | Pas de journal en Shipping : `LifePlay.Target.cs:6-15` n'active pas `bUseLoggingInShipping` ; aucun `Saved\Logs` sous la build alpha, contre un `LifePlay.log` dans les 13 builds Development 5.8 de `D:\Game\` | relecture du fichier ; listage du 2026-10-15 | établi (listage), estimé (cause) | M0 ne lit qu'une partie jouée sur une build Development |
| F11 | La section « à-coups » de `LogStats -Stats` lit le message `LPDebug hitch`, écrit seulement avec `-LPHitchLog` (seuil 50 ms, `-LPHitchMs=`), hors Shipping | `Source\LifePlay\LPDebugSubsystem.cpp:7, :652-654` ; `Tools\LogStats.ps1:83` | établi | M0 compte les à-coups seulement si la partie a été lancée avec `-LPHitchLog` |
| F12 | PresentMon en direct : 0 image en 6 essais ; Windows émet bien l'ETW (50 Mo en 10 s) ; `--etl_file` jamais essayé (fichier supprimé avant) | `OPT0-TACHES.md:203-218` | établi | M2 non éprouvé ; il peut échouer pour la même cause que la capture en direct (incertain) |
| F13 | Journal d'AMD Adrenalin : format à relever sur un vrai fichier | `OPT0-TACHES.md:217` | établi (lacune) | M3 non éprouvé ; grain (par seconde ou par image) incertain |
| F14 | Aucun seuil PASS/FAIL standard | BC R4-14 ; `BC-INDEX.md:32` | établi | une précision « ± 5 % » n'a de sens qu'après mesure de la dispersion du poste |

## 2. Question 1 : les critères

| Critère | Pertinent | Mesurable à la demande | Recouvrement | Correction |
|---|---|---|---|---|
| A. Question | oui : c'est le seul qui désigne l'outil | oui | le niveau 0 « non-régression » n'est pas un grain mais un mode (A/B), qui vaut pour tous les grains | A devient le **grain** : 0 compteurs du jeu, 1 cadence, 2 fil, 3 fonction ; le mode A/B découle de C |
| B. Précision | oui, mais pour régler la statistique, pas l'outil | non pour « ± 5 % » tant que la dispersion d'une passe à l'autre n'est pas connue (F14 ; portable à GPU hybride, dispersion probablement forte : estimé) | avec A (A3 entraîne presque toujours B3) et avec C (plus l'enjeu monte, plus on exige) | B fixe le **nombre de passes N** et la statistique, sans changer le palier |
| C. Enjeu | oui | oui | le niveau 2 mêle un nettoyage sans gain (G2, preuve P2 + P3 + P4) et un gain revendiqué (G3, preuve P5) : `OPT0-A3-GRILLE.md` § 4 (G2 et G3) | C1 = réversible **sans** gain revendiqué ; C2 = gain revendiqué (BP, C++) ; C3 = rendu, plateforme ou peu réversible |
| D. Doute | oui, comme déclencheur | **non** : le doute naît d'un résultat, il vaut 0 à la première demande | avec la règle 1 (monter si D monte) : compté deux fois | D sort du score ; il ne sert qu'à monter d'un cran (R4 ci-dessous) |

Critères manquants :
- **V, build visée** : Development (instrumentée, pessimiste) ou ressenti Shipping. Il choisit l'outil pour une question
  de cadence : seule une mesure externe voit la Shipping (F4, F10).
- **H, coût humain** : 0 aucun ; 1 geste de poste (session élevée, activation d'Adrenalin) ; 2 une partie jouée par
  passe. C'est un **prérequis à réserver**, pas un point de score : un score plus haut ne doit pas acheter plus de
  temps de l'utilisateur sans qu'il le sache.
- **N, reproductibilité** : passes par côté A/B et conditions figées (même build hors changement, même carte et même
  scénario, secteur branché, même plan d'alimentation). Porté par B.
- **Durée et machine** : build Development à refaire (`BuildDebug.ps1`, BUILD-GO) ou déjà présente (F10). Prérequis.

## 3. Question 2 : le score additif envoie au mauvais palier

| Demande | Ancien calcul | Ancien palier | Pourquoi c'est faux |
|---|---|---|---|
| « Quel Blueprint coûte au menu ? » | A3 B0 C0 D0 = 3 | M1 | le CSV s'arrête à la catégorie ; la fonction ou le Blueprint demande M4 |
| « SM6 ne régresse pas ? » | A0 B1 C3 D0 = 4 | M1 | C3 exige GPU, cadence Shipping et session sans plantage (preuve P6, `OPT0-A3-GRILLE.md` § 2 et G6 au § 4) : **sous-mesure d'une décision coûteuse** |
| G3 Ticks de Person | A2 B2 C2 D0 = 6 | M1 + M2 | M2 ne dit rien du fil (au mieux MsGPUBusy, R11-04) : un palier non éprouvé (F12) payé sans preuve en plus |
| cadence globale, doute fort | A1 B2 C2 D3 = 8 | M1 + M2 | le doute fait monter le palier sans que la question change ; il faut d'abord savoir quelle mesure doute |

Règle plus sûre (adoptée au § 4.3) : **le palier est fixé par A (et V pour la cadence), C impose un plancher, B règle
le nombre de passes, D ne sert qu'à monter d'un cran après un résultat.**

## 4. Barème corrigé (tableaux prêts à copier)

### 4.1 Outillage

| Palier | Outil (recette) | Build | Répond à | Prérequis | État sur ce poste |
|---|---|---|---|---|---|
| M0 | `Tools\LogStats.ps1 -Compare <A>,<B> -Stats` sur `LifePlay.log` | Development | compteurs du jeu : F5, DESTROY, à-coups ≥ 50 ms | une partie jouée par côté (H2), lancée avec `-LPHitchLog` | outil en service ; à-coups seulement avec le drapeau (F11) |
| M1 | CSV Profiler par `-ExecCmds="csvprofile frames=N"` (lanceur Session C), puis `Tools\SummarizeDebugCsv.ps1` et PerfReportTool `-writeSummaryCsv` ; `-csvGpuStats` si le GPU est en jeu ; FPS chart en option. **Jamais `-csvCaptureFrames`** | Development (Test indisponible, F2) | cadence de la build instrumentée ; coût par fil et par catégorie (GT, RT, GPU) | build Development à jour (BUILD-GO si elle est à refaire) ; partie jouée, ou scénario par `-ExecCmds` | lanceur présent ; essai en 5.8 à faire (essai 5.5 seulement, estimé) |
| M2 | trace ETW hors ligne (`wpr` ou `logman`, fournisseurs relevés dans le source de PresentMon 2.6.0) puis `PresentMon --etl_file` | Shipping (alpha) ou Development | cadence réelle de la Shipping, à-coups vus à l'écran | session élevée (H1) ; disque : environ 5 Mo/s (F12) | jamais essayé ; peut échouer comme le direct (incertain) |
| M3 | journal de performance d'AMD Adrenalin | toutes | cadence (grain à relever) | activation par l'utilisateur (H1) | format inconnu (F13) |
| M4 | Unreal Insights par le lanceur Session A ; ajouter `gpu` aux canaux si le GPU est en jeu | Development | quelle fonction, quel Blueprint | lecture dans UnrealInsights par l'utilisateur, ou export sans interface à éprouver (R4-09) | lanceur présent ; lecture par un agent non éprouvée |
| (plus tard) | Gauntlet pour rejouer M1 sans humain : tests compilés en Development seulement (R11-17), éditeur hôte requis (R11-18) | Development | rejouer M1 | BuildCookRun | non éprouvé ; Tracy abandonné |

### 4.2 Critères

| Critère | Rôle | 0 | 1 | 2 | 3 |
|---|---|---|---|---|---|
| A. Grain de la question | **fixe le palier** | compteurs du jeu (F5, DESTROY, à-coups) | cadence globale | quel fil coûte (GT, RT, GPU) | quelle fonction / quel Blueprint |
| V. Build visée | change l'outil pour A1 | Development suffit | ressenti Shipping exigé | — | — |
| C. Enjeu | **plancher** | contrôle, aucune décision | réversible, sans gain revendiqué (nettoyage, réglage) | gain de performance revendiqué (Blueprint, C++) | rendu, plateforme ou peu réversible (SM6, Lumen) |
| B. Exigence | **nombre de passes et statistique** | oui / non, 1 passe | moyenne, 1 passe par côté | médiane, p95, p99, à-coups ; 3 passes par côté | série image par image ; 3 passes par côté et une trace |
| H. Coût humain | **prérequis réservé avant lancement** | aucun | geste de poste | une partie jouée par passe | — |

D (doute) n'est pas noté à la demande : il sert à la règle R4.

### 4.3 Règles

1. **Palier de base par A** : A0 → M0 ; A1 → M1 si V0, M2 si V1 (M3 en repli) ; A2 → M1 (`-csvGpuStats` si le GPU est
   en jeu) ; A3 → M4, avec M1 pour situer les images en cause.
2. **Plancher par C** : C0 et C1 → rien de plus ; C2 → M1 en A/B (preuve P5) + M0 (preuve P4) ; C3 → M1
   `-csvGpuStats` + M0 + cadence Shipping (M2 ou M3) + session sans plantage (ERR-138), et **décision explicite de
   l'utilisateur** avant lancement.
3. **Palier retenu = base ∪ plancher.** B fixe N et la statistique ; H et la build sont réservés avant le BUILD-GO.
4. **Montée par D, d'un seul cran, après un résultat** : écart inexpliqué ou contradiction → M0 → M1 ; M1 → M4 (du fil
   à la fonction) ; M1 ↔ M2 (Development contre Shipping). Jamais deux crans sans retour à Big Boss.
5. **A/B honnête** : même build hors le changement, même carte et même scénario, mêmes conditions de poste, N passes
   par côté ; un chiffre M1 (Development) n'est jamais présenté comme un chiffre Shipping.
6. **Épreuve** (ancienne règle 3) : un palier jamais éprouvé en 5.8 l'est par une fiche à part (recette seule, budget
   à part). Ordre proposé : M1, M4, M2, M3 (§ 8, point U3).
7. **Notation dans la fiche**, vérifiée par Big Boss au BUILD-GO :
   `Mesure : A2 V0 C2 B2 H2 → M1 A/B ×3 + M0 (plancher C2) ; prérequis : build Development, 6 parties jouées`.

### 4.4 Budgets (jetons, estimés)

Base : un agent neuf coûte 55 à 140 k (chiffre de Big Boss ; 55 à 82 k pour un gardien, `PIPE1-SPEC-01.md:4-5`). Un
budget sous 55 k n'est donc tenable **que sans agent**.

| Palier | Rodé, sans agent (script lancé par la session) | Rodé, avec un agent | Première fois (épreuve, règle 6) |
|---|---|---|---|
| M0 | ≤ 10 k | inutile | — (outil en service) |
| M1 | ≤ 20 k, une fois le script enveloppe écrit | 60 à 80 k | 80 à 120 k |
| M2 | ≤ 15 k | 60 à 80 k | 90 à 140 k (fiche B2-ter) |
| M3 | ≤ 10 k | 55 à 70 k | 60 à 90 k |
| M4 | non tenable sans humain (lecture du `.utrace`) | 90 à 140 k | ≥ 120 k, décision explicite de l'utilisateur |

Comment les tenir :
- Aucun agent neuf pour M0 ni pour un M1 rodé : la session lance le script et lit sa synthèse. Si un agent est
  nécessaire, reprendre une session lp-perf existante plutôt qu'en créer une (règle des sessions réutilisées).
- Sorties bornées : chaque script rend un JSON et un `.md` de 10 lignes au plus ; ni la session ni l'agent ne lisent
  un CSV brut ou un journal entier (`LogStats -Pattern`, `-Tail`, `-Compare -Stats` seulement).
- Prompt de l'agent : les lignes utiles de la recette, pas le skill entier ; `maxTurns` par palier (M1 : 12 ; épreuve
  M2 : 20 ; M4 : 25), estimés.
- Haiku baisse le prix par jeton, pas le nombre de jetons : l'objectif PIPE1 se mesure en jetons, le modèle se choisit à
  part.
- Relevé réel par `Tools\FicheStats.py` ; budgets recalés après 3 mesures par palier.

## 5. Question 3 : chaque palier répond-il à sa question sur ce poste ?

| Palier | Réponse | Fait faux ou non vérifié dans la SPEC-02 |
|---|---|---|
| M0 | oui pour la non-régression des compteurs ; non pour la cadence (aucun temps d'image dans le journal) | « prérequis : aucun » est faux (F10, F11) |
| M1 | oui pour cadence (Development) et fil ; non pour la fonction | « build Test » impossible (F2) ; « `-csvprofile` » inexistant (F5) ; FPS chart utile mais redondant (F3) ; lanceur Session C ignoré (F7) |
| M2 | oui pour la cadence Shipping, **si** l'analyse hors ligne marche | « geste de l'utilisateur (ETW) » juste ; jamais essayé, peut échouer (F12) |
| M3 | incertain (format et grain inconnus) | non vérifié (F13) |
| M4 | oui pour la fonction, en Development | « build Development » juste (F8) ; lecture par un agent non éprouvée (R4-09) ; lanceur Session A ignoré (F7) |

## 6. Question 4 : budgets

Les budgets de la SPEC-02 comptent le travail d'analyse mais pas le coût fixe d'un agent neuf. Avec 55 à 140 k par
agent, « M1 ≈ 30 k, lp-perf Haiku » et « M1 + M2 ≈ 50 k » sont intenables ; « M1 + M4 ≈ 80 k » l'est à peine.
Correction au § 4.4 : deux colonnes (sans agent, avec agent) et une ligne d'épreuve séparée, puisque tous les paliers
sauf M0 sont encore à éprouver en 5.8 et que la règle 3 de la SPEC-02 s'appliquera donc à presque toute première
demande.

## 7. Question 5 : règles et exemples

- Règle 1 de la SPEC-02 (« le plus bas palier qui répond ») + score additif = **risque de sous-mesure** d'une décision
  coûteuse (exemple SM6 au § 3). Corrigé par le plancher C (règle 2).
- Règle 1 (« monter si D monte ») compte D deux fois. Corrigé : D hors score (règle 4).
- Règle 2 : bonne ; la notation ajoute V, C, H et le plancher ; Big Boss refuse un lancement dont H n'est pas réservé.
- Règle 3 : bonne, mais elle touche M1 à M4 ; mieux vaut une épreuve planifiée par palier qu'au fil des demandes.
- Exemples : les deux lignes G3 et G4 font payer M2 sans motif ; G6 sort à 8 alors que c'est la décision la plus
  coûteuse de la grille.

Exemples recalculés :

| Demande | A | V | C | B | H | Ancien palier | Nouveau palier | Budget (rodé, sans agent) |
|---|---|---|---|---|---|---|---|---|
| G2 nettoyage U9 : rien n'a régressé ? | 0 | 0 | 1 | 0 | 2 | M0 | M0 | ≤ 10 k |
| G3 Ticks de Person | 2 | 0 | 2 | 2 | 2 | M1 + M2 | M1 A/B ×3 + M0 | ≤ 30 k |
| G4 AnimBP thread-safe | 2 | 0 | 2 | 2 | 2 | M1 + M2 | M1 A/B ×3 + M0 | ≤ 30 k |
| G6 SM6 | 2 | 1 | 3 | 2 | 2 | M1 + M2 | M1 `-csvGpuStats` + M0 + M2 (ou M3) + session sans plantage ; décision de l'utilisateur | ≥ 45 k sans agent ; épreuves de M2 / M3 à part |
| à-coup inexpliqué après G3 | 3 | 0 | 2 | 3 | 2 | M1 + M4 | M4, avec M1 pour situer | 90 à 140 k (agent) ou lecture par l'utilisateur |
| « Quel Blueprint coûte au menu ? » | 3 | 0 | 0 | 0 | 1 | M1 | M4 | idem |

## 8. Changements et motifs

| # | Changement | Motif |
|---|---|---|
| C1 | Score additif remplacé par : palier par A (et V), plancher par C, N par B, montée par D | § 3 : contre-exemples de mauvais palier et de sous-mesure |
| C2 | D retiré du score de départ | inconnu à la demande ; compté deux fois avec la règle 1 |
| C3 | Critères V (build visée) et H (coût humain) ajoutés ; reproductibilité portée par B | la Shipping ne se mesure que de l'extérieur (F4, F10) ; le temps de l'utilisateur est le goulot |
| C4 | C2 scindé : sans gain revendiqué (C1) / gain revendiqué (C2) | la grille A3 exige P5 pour G3 et G4, pas pour G2 |
| C5 | M1 : « Test » retiré, `-ExecCmds="csvprofile frames=N"` au lieu de `-csvprofile`, jamais `-csvCaptureFrames`, lanceur Session C et `SummarizeDebugCsv.ps1` repris, FPS chart en option | F2, F3, F5, F6, F7 |
| C6 | M0 : prérequis « build Development, partie jouée, `-LPHitchLog` » | F10, F11 |
| C7 | M2 n'est plus empilé sur M1 : il sert à la cadence Shipping (V1) et au plancher C3 | il ne dit rien du fil ; non éprouvé (F12) |
| C8 | M4 : lanceur Session A ; lecture humaine tant que l'export sans interface n'est pas éprouvé | F7, F8, R4-09 |
| C9 | Budgets en deux colonnes (sans agent / avec agent) et épreuve à part | coût fixe d'un agent neuf : 55 à 140 k |
| C10 | Règle 5 (A/B honnête) ajoutée | sans N passes ni conditions figées, « ± 5 % » n'est pas mesurable (F14) |

## 9. Points à trancher par l'utilisateur

- **U1.** Adopter la règle « palier par A, plancher par C, D seulement après un résultat » à la place du score
  additif ? (Recommandé.)
- **U2.** Accepter Development comme seule build instrumentée (chiffres pessimistes, Test indisponible avec le moteur
  du lanceur) ? L'autre voie, un moteur compilé depuis les sources, coûte bien plus cher (estimé) ; non recommandée.
- **U3.** Ordre d'épreuve des paliers : M1 (Session C en 5.8), puis M4 (Session A), puis M2 (B2-ter), puis M3 ?
  (Recommandé : M1 sert G3 et G4.) Ou M2 d'abord, si la cadence Shipping de l'alpha passe avant.
- **U4.** Faire écrire un script enveloppe pour M1 (lanceur Session C + `SummarizeDebugCsv.ps1` + PerfReportTool,
  synthèse de 10 lignes), condition pour tenir M1 sous 20 k ?
- **U5.** Coût humain d'un A/B en B2 : 3 passes par côté, soit 6 parties jouées pour G3 ou G4. Acceptable, ou B1
  (une passe par côté) tant que la dispersion du poste n'est pas mesurée ?

## 10. Suites (hors de cette revue, rien n'est fait)

- S1. Recette `lp-perf\recettes\csvprofile.md` : la ligne 14 utilise `-csvCaptureFrames` (proscrit, F6) et la ligne 7
  propose « Development ou Test » (F2). Fiche à part sur le skill de l'addon.
- S2. BC R4-11 (« construire le banc sur une build Test ») et `OPT0-PIPELINE.md` P2a (« Development ou Test ») :
  à corriger par F2.
- S3. Script enveloppe de M1 (si U4 = oui) : outil neuf, réservation de Big Boss.

## 11. Limites

- Rien n'a été lancé : le refus d'UBT en Test, l'arrêt du FPS chart commandé par `-ExecCmds` et l'essai de la
  Session C en 5.8 ne sont pas vérifiés.
- La dispersion d'une passe à l'autre sur ce portable est inconnue ; les N passes de B sont estimées.
- Budgets estimés à partir du coût d'agent cité par Big Boss ; à recaler par `Tools\FicheStats.py`.
- Recherche d'essais passés limitée aux docs `Docs\` (grep) ; un essai CSV en 5.8 a pu m'échapper.