LifePlay-Revival/Docs/Migration/26_Eval_Agents_VideoQuality.md

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

VQ5-T1, 2026-10-07. Évaluation du déroulé multi-agents du chantier VQ (doc 25_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.
• 25_Video_Quality.md — référence fonctionnelle du chantier.