LifePlay-Revival/Docs/Migration/etat/sandbox/SB4/SB4-EVAL.md

SB4-EVAL — Évaluation des lots SB0 à SB4 (SB4-T3)

• Fiche : SB4-T3 — Agent : A-DOC + Orch — Modèle : prévu opus (M4) | utilisé opus (session principale)
• Entrées : SB0-VAL.md, SB1/*, SB2/* (dont SB2-REF, SB2-O1-BUILD), SB4/SB4-BUILD.md, SB4/SB4-VAL.md, doc 23 § 7, doc 21 (Acceptation).

1. Fiches : modèle prévu, utilisé, résultat

Fiche	Palier	Prévu	Utilisé	Résultat	Remarque
SB0-T1/T2/T3	M3/M4	opus	opus	conception approuvée
SB0-T4	M2	sonnet	sonnet	PASS	premier commit refait (ancien chemin de plan)
SB1-T1 SPEC	M4	opus	opus	fait
SB1-T2 registre	M3	opus	opus	fait	5 écarts documentés (SB1-IMPL)
SB1-T3 barre latérale	M2	sonnet	sonnet	fait	lambda pendante corrigée par la session principale
SB1-T4 build	M0	haiku	haiku	PASS
SB1-T5 VAL	M2	sonnet	sonnet	PASS + visuel	essai E4b ajouté de lui-même (ordre non alphabétique) : utile
SB1-T6 clôture	M2	sonnet	sonnet	PASS
SB2-T0 référence	M0	haiku	haiku	fait	verdict avertissement accepté sans s'arrêter alors que la fiche demandait ok ; vérifié a posteriori (avertissements de clips préexistants)
SB2-T1 carte	M3	opus	opus	fait	O1 détecté à la lecture
SB2-T2/T3 extraction	M3	opus	opus	compilé du premier coup
SB2-T4 build	M0	haiku	haiku	PASS
SB2-T5 VAL	M2	sonnet	sonnet	PASS + visuel	anomalie E3 (pièce construite sans bibliothèque) bien relevée
SB2-T6 clôture	M2	sonnet	sonnet	PASS	renommage vu D+A par git (contenu trop changé)
G-SB3	M4	opus + utilisateur	idem	SB3 abandonné
SB2-O1 (T1–T4)	M3/M0/–/M2	opus/haiku/utilisateur/sonnet	idem	PASS	build bloqué une fois par une sandbox restée ouverte ; compte de fichiers erroné (63 au lieu de 73) dans le rapport haiku, corrigé par contre-vérification
SB4-T0	M3	opus	opus	fait
SB4-T1a build	M0	haiku	haiku	PASS
SB4-T1b VAL	M2	sonnet	sonnet	PASS
SB4-T2 doc	M2	sonnet	sonnet	fait	a signalé lui-même ce qui n'était pas prouvé (cycle)
SB4-T3 éval	M4	opus	opus	ce document

Aucune fiche sous-classée ; aucun recours au palier de secours (fable). Deux défauts de niveau rapide (haiku) : critère d'arrêt non respecté (SB2-T0) et décompte faux (SB2-O1-T2) — tous deux rattrapés par la vérification du livrable par la session principale, qui reste indispensable.

2. Bilan technique

• Acquis (doc 23 § 7.1) : registre, descripteur étendu rétrocompatible, ordre système par index, persistance, refus mod → mod, prérequis signalés sans blocage, activé ≠ ouvert, contexte filtré, état des modes dans leur mod, non-régression stricte Mesure et LPAnimEval (trois passages identiques : SB2-T5, SB2-O1-T2, SB4-T1b).
• Limites (doc 23 § 7.2) : pas de séparation physique (abandonnée), persistance propre à la sandbox, cycle de prérequis non essayé, registre non essayé en Shipping.
• Défaut préexistant trouvé et corrigé en route : O1.

3. Décision : go / no-go pour transposer au jeu

GO, par petits lots, dans l'ordre de la § 7.3 du doc 23 :

1. E2 (prérequis) + E6 (lecture par clé) : relais C++ côté jeu, sans toucher l'ordre ni la persistance — même lecture que LPModInfoSubsystem, déjà prouvée sur les 16 .lpmod du jeu.
2. E13 (propriétés déclarées) : remplacer le verrouillage en dur de vin_Base ; demande des modifications de UI/ModuleTick et GI (Blueprint), donc lot à part avec captures avant / après.
3. Conception de la cohabitation registre ↔ GI.ModEnableds (point ouvert), avant tout module système réel.
4. Studio de création de personnage en module système, Pocolov en dépendant ; option legacy / modern.

Préalables : décision de l'utilisateur sur le commit des lots AP1–AP7 et SB dans le dépôt du jeu (toujours en attente) ; un essai du cycle de prérequis peut être ajouté au premier lot de transposition (règle déjà codée).