# 24 — Évaluation des agents : chantier Video Quality (VQ0–VQ4)

> **VQ5-T1, 2026-10-07.** Évaluation du déroulé multi-agents du chantier VQ (doc `23_Video_Quality.md`).
> Annexe de preuve : `etat/VQ/VQ5/VQ5-VAL.md` (VQ5-T2). Journal : CHG-237 à CHG-240.
> Modèle : `claude-opus-5-5-medium` (M4).

## 1. Résumé exécutif

Le chantier VQ a livré la V1 prévue en cinq lots : un `DefaultScalability.ini` à 4 groupes, le sous-système `ULPVideoQualitySubsystem` (6 lignes `LPVideo*` avant `LPColor*`, 3 curseurs Blueprint masqués), un bouton Recommended basé sur la VRAM, et une clôture documentaire. Tout compile, le démarrage `-nullrhi` est propre, aucun verrou L7c n'est touché, et chaque lot a un verdict PASS.

Deux limites pèsent sur ce bilan :

1. **Aucun clic n'a été exécuté.** Les chemins Overall, Custom et Recommended sont prouvés par relecture du code, pas en jeu (BLOCKED-UI depuis VQ2).
2. **Un point de passage entre agents a été perdu.** VQ1-IMPL demandait de comparer les valeurs à `BaseScalability.ini` du moteur dans une fiche VQ1-VAL qui n'a jamais été produite. VQ5 a fait la comparaison : au niveau Epic (niveau actif au démarrage), le projet réduit les cascades d'ombre (10 → 4), relève le seuil d'ombre et le `DetailMode`, et dépasse le palier moteur pour `r.RefractionQuality` (2 → 3). Le rendu change donc pour tous les joueurs, même sans ouvrir l'onglet Video (`VQ5-VAL.md` §4).

**Décision : GO conditionnel** pour réutiliser ce schéma d'agents (§6).

## 2. Lots VQ0–VQ4

| Lot | Fiches tenues | Coupé / non livré | Rollback | Verdict |
|---|---|---|---|---|
| **VQ0** | T1 CART (inventaire Video, 18 lignes + 5 `LPColor*`), T2 VAL, T3 DOC (doc 23) | — (réserve mineure : décompte « 4 » au lieu de 5 en CART §8) | CHG-237 : supprimer doc 23 et `VQ0-VAL.md` | **PASS** |
| **VQ1** | T1 SPEC, T2 IMPL (`Config/DefaultScalability.ini`, 16 sections), T3 CART (audit grep des interdits L7c, 0 hit) | **VQ1-VAL non produit** : comparaison à `BaseScalability.ini` et lecture des cvars en jeu jamais faites ; **pas de CHG** | non journalisé (supprimer `DefaultScalability.ini`) | **PASS** sur le contrat L7c ; **réserve** sur les valeurs |
| **VQ2** | T1 SPEC, T2 + T3 fusionnés dans IMPL-H (sous-système + `CategoryOf`/`ApplyRows`), T4 VAL | delegate `OnControlsInjected` (Q2 : inutile, le ticker de `LPSettingsSubsystem` suffit) ; `PostProcessQuality` figé (Q1, choix assumé) ; correction du faux positif `NewAnimationsOnly` (doc 23 §1.4) **non livrée** ; **pas de CHG** | non journalisé (supprimer `LPVideoQualitySubsystem.*`, revenir sur `LPSettingsSubsystem.cpp`) | **PASS** + BLOCKED-UI |
| **VQ3** | T1 IMPL-H (VRAM → niveau), T2 VAL | `SharedSystemMemory` ignorée (GPU intégré → Low/Med, assumé) | CHG-238 : restaurer le stub, retirer `RHI` de `LifePlay.Build.cs` | **PASS** + BLOCKED-UI |
| **VQ4** | T1 VAL finale, §8 Acceptation du doc 23 | rejeu des cases d'acceptation in-game (BLOCKED-UI) | CHG-239 : supprimer `VQ4-VAL.md`, retirer §8 | **PASS** + BLOCKED-UI |

Aucun rollback n'a été exécuté. Rien n'est commité : tout le chantier est encore non suivi ou modifié dans l'arbre de travail.

## 3. Qualité des consignes et des passages entre agents

**Ce qui a bien marché**

- **Les SPEC sont exécutables.** VQ2-SPEC fixe les types, l'ordre strict de `SetLevels`, les noms de widgets, l'algorithme d'insertion et son repli, les risques (R1–R7) et les questions ouvertes. L'implémentation a compilé au premier passage avec des écarts minimes et documentés (`bConfigured`, signature d'`AddRow`).
- **Les interdits sont explicites.** La liste L7c (GI, VSM, méthode d'AA, reflets) est répétée dans chaque SPEC et rejouée par grep en VQ1-CART et VQ4-VAL ; elle n'a jamais été violée.
- **Les écarts sont signalés.** IMPL-H liste ses écarts ; les VAL marquent honnêtement BLOCKED-UI au lieu de cocher les cases de jeu.
- **Les preuves sont traçables.** Chaque VAL donne la commande, l'exit code, le journal (`Saved/Logs/VQ{2,3,4}VAL.log`) et les lignes de code.

**Ce qui a manqué**

- **Les points à confirmer ne sont pas suivis.** La liste « Points à confirmer en validation » de VQ1-IMPL §4 n'a pas été reprise : VQ1-T3 a reçu une consigne d'audit limitée au grep des interdits, VQ4 a rejoué les cases de la SPEC sans relire IMPL. C'est la cause directe de l'écart Epic non détecté.
- **La SPEC VQ1 n'a pas été vérifiée.** Elle annonçait des paliers « au plus égaux à Epic moteur » sans avoir lu le fichier moteur (IMPL le reconnaît). Une hypothèse non vérifiée a ensuite été recopiée comme acquise (« sans INI, aucun changement », VQ2-SPEC §6.2, doc 23 §2.1).
- **Le journal est incomplet.** VQ1 et VQ2, les deux seuls lots qui créent des fichiers de code ou de configuration, n'ont pas de CHG ; leur rollback n'est donc écrit nulle part.
- **Le modèle réellement utilisé n'est pas toujours noté.** VQ0-CART, VQ1-SPEC/IMPL et VQ2-SPEC ne notent que le modèle attendu, ou rien.
- **Le doc 23 contient une section périmée.** §6 « Prochaines fiches » décrit encore un VQ1 qui ne correspond pas au découpage réel.

## 4. Adéquation modèle ↔ complexité

| Fiche | Complexité | Modèle prévu | Modèle réel | Appréciation |
|---|---|---|---|---|
| VQ0-T1 CART | moyenne (lecture de code + `.uasset`) | non noté | non noté | livrable complet ; modèle non traçable |
| VQ0-T2 VAL | faible (recoupement) | composer-2.5-fast (M0) | idem | adapté |
| VQ1-T1/T2 SPEC + IMPL | moyenne (valeurs moteur) | claude-sonnet-5-5-high (M2) | non noté | rédaction solide, mais aucune lecture de `BaseScalability.ini` (contexte d'installation absent) |
| VQ1-T3 CART | faible (grep) | gemini-3.8-flash-high (M1) | idem | adapté au contrat, mais contrat trop étroit (§3) |
| VQ2-T1 SPEC | élevée (UMG, Scalability, priorités cvar) | claude-sonnet-5-5-high (M2) | non noté | très bonne qualité |
| **VQ2-T2 IMPL-H** | **élevée** | **claude-fable-5-1-thinking-high (bloqué par la policy)** | **claude-sonnet-5-5-high (repli)** | le repli a suffi : compile au premier passage, écarts justifiés. La SPEC détaillée a compensé l'écart de modèle |
| VQ2-T4 VAL | moyenne | sonnet (M2) | idem | adapté |
| VQ3-T1/T2 | faible (seuils VRAM, API RHI) | sonnet (repli M3) | idem | surdimensionné ; un M1 aurait suffi, mais la vérification de l'API dans les sources UE 5.5 est de bonne qualité |
| VQ4-T1 VAL | faible (rejeu) | sonnet | idem | adapté ; aurait dû relire les IMPL, pas seulement les SPEC |
| VQ5-T1/T2 EVAL | moyenne (synthèse critique) | claude-opus-5-5-medium (M4) | idem | adapté |

Conclusion : le blocage de Fable n'a pas dégradé le résultat, parce que la SPEC VQ2 portait l'essentiel de la complexité. Le vrai risque ne venait pas d'un modèle trop faible, mais d'une consigne trop étroite (VQ1-T3) et d'une fiche VAL absente.

## 5. Exigence de sync respectée ?

**Oui en code, non prouvée en jeu (BLOCKED-UI manuel).**

| Règle (doc 23 §2) | État |
|---|---|
| Une seule commande visible par cvar Scalability | **oui** : `ShadowQuality`, `PostProcessQuality`, `PostProcessAAQuality` → `TabHidden`, maintenus repliés par `ApplyRows` |
| Overall ↔ 4 curseurs sans boucle | **oui** : point d'entrée unique `SetLevels` ; `FromOverall` / `Normalize` ; garde `bRefreshing` (`VQ5-VAL.md` §3) |
| Ré-application après le Blueprint | **oui** : nouveau monde de jeu (`Tick`) et chaque injection du menu (`EnsureControls`) |
| Persistance | **oui** (code) : `LPVideoQuality.ini` relu à `Initialize` ; `GameUserSettings.ini` volontairement non écrit |
| Preuve en jeu | **BLOCKED-UI** : 5 tests manuels listés en VQ4-VAL §4, jamais exécutés |

Limites acceptées : un `sg.*` tapé en console n'est pas repris dans les curseurs une fois le joueur configuré ; `PostProcessQuality` n'est plus pilotable ; chaque cran de curseur réécrit l'INI.

## 6. Go / no-go réutilisation

**GO conditionnel.** Le schéma SPEC → IMPL → VAL avec rôles séparés, interdits répétés et verdicts honnêtes est réutilisable pour un chantier C++/config de taille comparable. Deux conditions : la recommandation 1 doit être appliquée avant de déclarer VQ « livré joueur », et les recommandations 2 et 3 doivent être intégrées au gabarit des prochains chantiers.

### Recommandations

1. **Tracer chaque « point à confirmer » d'une IMPL jusqu'à une case de VAL, et ouvrir un lot VQ1b.** Chaque VAL doit relire la ou les IMPL amont, pas seulement la SPEC, et reporter chaque point : PASS, BLOCKED ou reporté avec un identifiant. Lot immédiat VQ1b : aligner `[*Quality@3]` (et `@2` si voulu) sur `BaseScalability.ini` (au minimum `r.Shadow.CSM.MaxCascades`, `r.Shadow.RadiusThreshold`, `r.DetailMode`, `r.RefractionQuality`), ou valider explicitement l'écart par une comparaison visuelle jour/nuit type L7c. Corriger ensuite la phrase « sans INI, aucun changement » dans le doc 23.
2. **Rendre le BLOCKED-UI automatisable.** Ajouter des commandes console de debug (par exemple `LP.Video.Set <groupe> <niveau>`, `LP.Video.Overall <n>`, `LP.Video.Recommended`, `LP.Video.Dump`) qui appellent `SetLevels` / `OnRecommendedClicked` et affichent `sg.*` et les cvars clés. Le smoke `-nullrhi -ExecCmds` couvrira alors Overall, Custom et la persistance, et un lancement D3D12 court couvrira Recommended avec une vraie VRAM. Il ne restera en manuel que le rendu visuel de l'onglet.
3. **Discipline de clôture par lot.** Un CHG par lot qui touche du code ou de la configuration (ici, VQ1 et VQ2 manquent) avec son rollback ; modèle prévu et réel dans l'en-tête de chaque fiche ; contrôle de disponibilité du modèle au dispatch (l'indisponibilité de Fable n'a été vue qu'à l'exécution) ; commit et tag du chantier en fin de lot (VQ est entièrement hors commit).

## 7. Annexes

- `etat/VQ/VQ5/VQ5-VAL.md` — chemins de code Overall / Custom / Recommended (PASS code), preuve de démarrage `-nullrhi` relue, écarts `DefaultScalability.ini` ↔ `BaseScalability.ini`.
- `etat/VQ/VQ0` … `VQ4` — fiches CART, SPEC, IMPL et VAL évaluées.
- `23_Video_Quality.md` — référence fonctionnelle du chantier.