LifePlay-Revival/Docs/Migration/24_Plan_Decouplage_Sandbox.md

name	overview	todos	isProject
Découplage jeu / sandbox (DC)	Rendre LifePlay-Revival compilable et jouable sans l'addon LifePlay-Sandbox (plugin LPSandbox vraiment optionnel) — partie runtime de LPAnimMeasure rapatriée dans un plugin LPAnimCore du jeu, mesure et tout l'outillage de mods (commandlets, scripts, sources de mods) déplacés dans la sandbox, qui devient l'atelier de fabrication et de recuisson des mods — en lots DC0–DC4 avec fiches DC#-Tn (consigne, livrable, handoff) et modèle IA assigné selon la complexité.	id content status lot-dc0 Lot DC0 — Cartographie et SPEC du découpage (DC0-T1..T4), porte utilisateur pending id content status lot-dc1 Lot DC1 — Plugin LPAnimCore dans le jeu, LPAnimMeasure réduit à la mesure (DC1-T1..T5) pending id content status lot-dc2 Lot DC2 — Commandlets de mods vers un module éditeur de la sandbox (DC2-T1..T5) pending id content status lot-dc3 Lot DC3 — Scripts, données et sources de mods vers la sandbox (DC3-T1..T5) pending id content status lot-dc4 Lot DC4 — Preuve « jeu seul », docs, évaluation (DC4-T1..T4) pending	false

Cahier : découplage du jeu et de la sandbox

Contexte

Depuis S2/S3, LifePlay et LifePlayEditorTools déclarent LPAnimMeasure dans leurs Build.cs (Source/LifePlay/LifePlay.Build.cs:45, Source/LifePlayEditorTools/LifePlayEditorTools.Build.cs:22). Ce module vit dans le dépôt privé LifePlay-Sandbox. Le marquage "Optional": true du plugin dans LifePlay.uproject ne suffit donc pas : sans la sandbox, le jeu ne compile plus. Le commit local fba19bc (non poussé) porte ce couplage. Le pousser tel quel rendrait le dépôt public impossible à compiler et poserait un problème AGPL (code distribué avec le jeu dont la source n'est pas publiée).

LPAnimMeasure mélange deux choses :

Partie	Fichiers	Lignes	Utilisateurs
Runtime du jeu	LPAnimRedirect, LPCoupleSim.h + LPCoupleSimCore.cpp	≈ 780	LPDirectControlSubsystem (marche avec clips convertis), LPShowCoupleSubsystem, sandbox
Mesure	LPPoseMeasure, LPPoseOrchestrator, LPSkeletonProfile	≈ 2 470	sandbox (mode Mesure), commandlets LPAnim*

Constats de la cartographie préliminaire (2026-10-07) :

• La partie runtime n'inclut que le moteur (aucun en-tête de mesure).
• Les commandlets LPAnimEval, LPAnimTwist, LPAnimCatalog, LPAnimIdentify et les aides LPAnimChecks, LPAnimMethodSelect n'incluent aucun en-tête du module LifePlay : on peut les déplacer tels quels. Même chose pour LPHairFromStaticMesh.
• Le plugin LPSandbox ne dépend pas de LifePlay : pas de cycle à casser.
• Le jeu contient encore des fichiers propres à la sandbox : Config/LPSandbox.ini, Tools/debug/LifePlay_{pair,interaction,measure}_sandbox.bat.

Décisions verrouillées (utilisateur, 2026-10-07)

Décision	Choix
Objectif	LifePlay-Revival compile, se lance et se cuit sans le dossier LifePlay-Sandbox ; LPSandbox reste chargé quand il est présent
Runtime animation	LPAnimRedirect + LPCoupleSim rapatriés dans le dépôt du jeu, dans un plugin Plugins/LPAnimCore (un plugin ne peut pas dépendre d'un module de jeu ; LPSandbox doit pouvoir dépendre de LPAnimCore)
Mesure	LPPoseMeasure, LPPoseOrchestrator, LPSkeletonProfile restent dans LPAnimMeasure (sandbox)
Outillage de mods	tout l'outillage de création, cuisson et recuisson des mods part dans la sandbox, qui devient l'atelier des mods : commandlets d'animation et de coiffure, BuildMod, NewMod, EditMod, ModSource, HairPipeline et leurs .py, Tools/anim, Tools/hairs, Tools/mods
Reste dans le jeu	chargement des mods (ULPModInfoSubsystem, LPHairstyleSubsystem, LPModDailies, LPDataCache), Mod Manager, commandlets de migration et de diagnostic (LPFix*, LPDump*, LPCheck*, LPPatchDailies, LPEditWidget, LPTitleModManager…), publication du jeu (SplitModules.ps1, Tools/modules), Releases/<version> (référence de cuisson DLC)
Visibilité du dépôt Sandbox	reste privé (choix utilisateur). Après DC, rien de ce qui est distribué avec le jeu n'en provient
Noms des commandlets	inchangés (-run=LPAnimEval etc.) : ils sont trouvés dès que le plugin est chargé
Dépôt du jeu	un commit par lot, rien n'est poussé sans accord (compte GitHub signalé le 2026-10-07 : attendre le rétablissement) ; addon : commit puis mise à jour du pin

Points ouverts tranchés (utilisateur, 2026-10-07)

Point	Décision
Guide des moddeurs (Docs/Modding/FullGuides/Creating_Asset_Mods.md + explanation.lphair)	déplacé dans la doc de la sandbox (LifePlay-Sandbox\Docs\) pour le moment ; le README du jeu n'y renvoie plus
ModSources/	déplacé dans la sandbox
Dossier du jeu pour les scripts déplacés	paramètre -GameRoot, défaut = dossier frère lu dans Config/LPSandbox.ini
Historique (fba19bc)	gardé tel quel : pas de réécriture ; acceptable tant que le compte est signalé (rien n'est visible)

Architecture cible

flowchart TB
  subgraph GAME["LifePlay-Revival (public, AGPL)"]
    LP["LifePlay (Runtime)"]
    LPET["LifePlayEditorTools (Editor) : migration, diagnostic"]
    CORE["Plugins/LPAnimCore (Runtime) : LPAnimRedirect, LPCoupleSim"]
  end
  subgraph SB["LifePlay-Sandbox (privé) — optionnel"]
    LPS["LPSandbox (Runtime, hors Shipping)"]
    AM["LPAnimMeasure (Runtime) : mesure de pose"]
    MT["LPModTools (Editor) : LPAnim*, LPHairFromStaticMesh"]
    TOOLS["Tools/mods, Tools/anim, Tools/hairs, ModSources"]
  end
  LP --> CORE
  LPET --> LP
  LPS --> AM & CORE
  AM --> CORE
  MT --> AM & CORE
  TOOLS -. "UnrealEditor-Cmd LifePlay.uproject -run=..." .-> MT
  GAME -. "AdditionalPluginDirectories ../LifePlay-Sandbox/Plugins (absent = ignoré)" .-> SB

Aucune flèche ne va du jeu vers la sandbox. LPAnimMeasure dépend de LPAnimCore seulement si la SPEC le confirme (la mesure utilise-t-elle LPCoupleSim ? réponse en DC0-T1).

Stratégie git

1. Jeu : un commit par lot DC (règle des phases du 2026-10-07), message DC#: … ; tags lot-DC#-avant / lot-DC#-valide seulement si l'utilisateur les rouvre ; aucun push.
2. Addon : branche lot/DC#-*, commit à la clôture du lot, puis pin (hash dans Docs/Migration/etat/sandbox/S3/S3-INT.md, 21_Sandbox_Addon.md, README de l'addon).
3. Ordre dans un lot qui touche les deux dépôts : addon d'abord (le jeu doit toujours compiler avec la sandbox épinglée), puis jeu.
4. Instantanés avant toute modification : .\Tools\Snapshot.ps1 -Lot DC# -Path … (jeu) et .\Tools\Snapshot.ps1 -Lot DC#-addon -ProjectRoot D:\Game\LifePlay-Sandbox -Path … (addon) ; retour arrière proposé : .\Tools\Restore.ps1 -Lot …. Attention : à partir de DC3, Snapshot.ps1/Restore.ps1 restent dans le jeu (outils de migration), pas dans la sandbox.
5. Déplacement de fichiers entre dépôts : copie dans l'addon, vérification d'empreinte (SHA-256 identique), puis git rm côté jeu ; jamais de suppression avant que la copie soit commitée dans l'addon.

---

Matrice modèles IA ↔ complexité

Le parent (session principale, Opus) lance chaque sous-agent avec le modèle de la fiche. Sous-classer une fiche haute complexité est interdit ; surclasser exige un motif écrit dans le handoff. Chaque fiche porte « Modèle prévu | utilisé » (une VAL sans ce champ en amont = FAIL-TRACE).

Palier	Complexité	Modèle	Profil
M0	Faible, mécanique	haiku	compilation + lecture du journal, lancements, relevés factuels, empreintes
M1	Faible, exploration large	haiku (Explore)	inventaires, greps multi-chemins — localise, ne suit pas un graphe d'appels
M2	Moyenne, raisonnement ciblé	sonnet	déplacements spécifiés, adaptation de scripts, docs, VAL de parité, opérations inter-dépôts
M3	Haute, refactor qui change la structure	opus (session principale)	découpe de module, Build.cs/.uplugin/.uproject, chemins du jeu dans les scripts
M4	Synthèse / jugement	opus (session principale)	SPEC, portes de décision, évaluation
Orch	Coordination	session principale	fiches, handoffs, vérification des livrables, arbitrage

Règles de secours : M3 échoue 2 fois sur la même fiche → reprise DC#-Tn-fix en fable (exception notée en VAL). M0/M1 insuffisant → +1 palier une seule fois. Le niveau rapide peut réécrire un script fourni malgré l'interdit et rendre un résultat vide présenté comme un succès → fiche « n'écris ni ne modifie aucun script ; en cas d'échec, recopie l'erreur et arrête-toi » ; 0 résultat = échec probable.

Tableau récap des affectations

Fiche	Agent	Palier	Modèle
DC0-T1	A-CART	M1 + M3	haiku (inventaire) + opus (dépendances)
DC0-T2	A-ARCH	M4	opus
DC0-T3	Orch + utilisateur	M4	opus
DC0-T4	A-DOC	M2	sonnet
DC1-T1	A-IMPL-H	M3	opus
DC1-T2	A-BUILD	M0	haiku
DC1-T3	A-VAL	M2 + utilisateur	sonnet + contrôle visuel
DC1-T4	A-INT	M2	sonnet
DC1-T5	A-DOC	M2	sonnet
DC2-T1	A-IMPL-H	M3	opus
DC2-T2	A-BUILD	M0	haiku
DC2-T3	A-VAL	M2	sonnet
DC2-T4	A-INT	M2	sonnet
DC2-T5	A-DOC	M2	sonnet
DC3-T1	A-IMPL-H	M3	opus (résolution du dossier du jeu, BuildMod)
DC3-T2	A-IMPL-L	M2	sonnet (déplacements, autres scripts, lanceurs)
DC3-T3	A-VAL	M2 + utilisateur	sonnet
DC3-T4	A-INT	M2	sonnet
DC3-T5	A-DOC	M2	sonnet
DC4-T1	A-BUILD	M0	haiku
DC4-T2	A-VAL	M2 + utilisateur	sonnet
DC4-T3	A-DOC	M2	sonnet
DC4-T4	A-DOC + Orch	M4	opus

---

Protocole de passage de consignes

Toute sous-tâche est une fiche DC#-Tn. Un agent ne démarre que si le livrable amont existe et n'est pas vide.

Format obligatoire d'une fiche

• ID : DC#-Tn — Agent : rôle — Modèle : prévu | utilisé — Dépend de
• Consigne d'entrée (objectif, contexte minimal, chemins exacts, commandes exactes, pièges, interdits)
• Travail / Livrable / Critère Done (vérifiable) / Handoff

Lancement (parent)

Agent(subagent_type = Explore | general-purpose, model = <modèle de la fiche>,
      prompt = consigne d'entrée + chemins des livrables amont + « Modèle prévu : <x> » en tête)

Emplacement des livrables

D:\Game\LifePlay-master 5.5\Docs\Migration\etat\sandbox\DC#\ : DC#-CART.md, DC#-SPEC.md, DC#-IMPL.md, DC#-BUILD.md, DC#-VAL.md ; journaux de commandlets en .txt (non suivis par git depuis le 2026-10-07) ; docs techniques de l'outillage dans D:\Game\LifePlay-Sandbox\Docs\ ; CHG au journal du jeu.

Règles d'orchestration

1. Le parent colle le livrable amont (chemin + résumé ≤ 5 lignes) et le modèle.
2. Hors périmètre → stop + signaler.
3. FAIL VAL → pas de DOC de clôture ; fiche DC#-Tn-fix.
4. La compilation appartient à l'IMPL (A-BUILD juste après) ; la VAL ne recompile pas.
5. VAL en lecture seule sur les docs d'acceptation ; DOC distinct coche 21.
6. Registre des reports : chaque « reste à faire » entre dans la liste unique de 21_Sandbox_Addon.md avec un lot propriétaire.
7. Lot coupé → commit du validé ; reste = nouveau lot.

Rôles

ID	Rôle	Paliers
A-CART	Cartographe	M1 (localiser) ou M3 (suivre des dépendances)
A-ARCH	Architecte	M4
A-IMPL-H	Implémenteur lourd	M3
A-IMPL-L	Implémenteur léger	M2
A-BUILD	Compilation + journal	M0
A-INT	Intégrateur (commits addon et jeu, pin)	M2
A-VAL	Validateur	M2 (+ contrôle visuel utilisateur)
A-DOC	Rédacteur	M2 ; M4 pour l'évaluation

Pièges à recopier dans les fiches (mémoire lifeplay-build-pitfalls)

• Éditeur fermé avant de compiler ; une compilation à la fois ; commande : & 'D:\Game\Launcher\Engine\UE_5.5\Engine\Build\BatchFiles\Build.bat' LifePlayEditor Win64 Development -Project='D:\Game\LifePlay-master 5.5\LifePlay.uproject' -WaitMutex (compile aussi les plugins de l'addon et LPAnimCore).
• DLL périmées : vérifier que LifePlay-Sandbox\Plugins\LPSandbox\Binaries n'existe pas ou n'est pas plus ancien que LifePlay-master 5.5\Binaries\Win64 ; même contrôle pour Plugins\LPAnimCore\Binaries ; preuve de chargement = ligne de journal propre au nouveau code.
• Unity build : pas de même nom dans deux espaces de noms anonymes du module → espace de noms nommé.
• Lanceurs sandbox : jamais derrière un tuyau (| Out-Null) : Start-Process cmd.exe -ArgumentList '/c "<bat>"'.
• BuildMod -Retarget depuis un agent : cmd /c start "" /wait cmd /c "<fichier.cmd>", sortie redirigée vers un fichier ; résultat = lignes RETARGET … portant le jeton du lancement ; plantage à la fermeture de l'éditeur sans conséquence.
• Toute recuisson par RetargetPack.py défait LPAnimTwist : relancer LPAnimTwist puis LPAnimEval.
• -run=pythonscript : ajouter -FullStdOutLogOutput ; registre d'assets en commandlet : scan_paths_synchronous avant does_asset_exist.
• Jamais de commit ni de build avec Mods/ non vide (mod monté par ModSource.ps1).
• Test « jeu seul » : déplacer (pas supprimer) D:\Game\LifePlay-Sandbox vers un nom temporaire, puis le remettre ; vérifier qu'aucun éditeur ne tourne pendant le déplacement.

---

Lots et fiches

Lot DC0 — Cartographie et SPEC

• Objectif : découpage exact fichier par fichier, validé avant tout déplacement. Repo : docs du jeu.

DC0-T1 — Cartographie

• Agent : A-CART | Modèle : M1 haiku (inventaire) + M3 opus (dépendances)
• Travail : (a) inventaire M1 : tout fichier du jeu qui appartient à l'outillage de mods (scripts Tools/, commandlets Source/LifePlayEditorTools, Tools/anim|hairs|mods, ModSources/, Config/LPSandbox.ini, lanceurs Tools/debug/*sandbox*.bat), et toute référence à ces fichiers (docs, scripts, README, .gitignore) ; (b) M3 : graphe d'inclusion de LPAnimMeasure (la mesure utilise-t-elle LPCoupleSim/LPAnimRedirect ?), qui appelle SetUALRoot aujourd'hui, comment chaque script calcule ProjectRoot, appels croisés entre scripts (SplitModules → BuildMod, HairPipeline → LPHairFromStaticMesh, AnimPipeline → BuildMod -Retarget).
• Livrable : etat/sandbox/DC0/DC0-CART.md (tableau fichier → destination proposée → références à corriger).
• Handoff → DC0-T2.

DC0-T2 — SPEC

• Agent : A-ARCH | Modèle : M4 opus
• Livrable : etat/sandbox/DC0/DC0-SPEC.md : LPAnimCore.uplugin (type, phase de chargement avant LifePlay, plateformes, Shipping inclus), Build.cs des cinq modules, .uproject du jeu (plugin LPAnimCore, LPSandbox optionnel), LPSandbox.uplugin (modules LPSandbox, LPAnimMeasure, LPModTools + dépendance au plugin LPAnimCore), arborescence cible de l'addon (Tools/mods, Tools/anim, Tools/hairs, ModSources), règle de résolution du dossier du jeu, comportement attendu quand le dossier frère est absent, liste des docs à reprendre (dont le déplacement du guide des moddeurs).
• Handoff → DC0-T3.

DC0-T3 — Porte utilisateur

• Agent : Orch + utilisateur | Modèle : M4 opus
• Critère Done : SPEC approuvée (les 4 points ouverts sont déjà tranchés, voir « Décisions verrouillées »).

DC0-T4 — Clôture DC0

• Agent : A-DOC | Modèle : M2 sonnet
• Travail : CHG, 21_Sandbox_Addon.md (lots DC annoncés), DC0-VAL.md (modèles prévus | utilisés) ; commit jeu DC0.

---

Lot DC1 — Plugin LPAnimCore

• Objectif : le jeu ne dépend plus de LPAnimMeasure ; la sandbox dépend de LPAnimCore. Repos : addon puis jeu.

DC1-T1 — Découpe

• Agent : A-IMPL-H | Modèle : M3 opus
• Travail : créer Plugins/LPAnimCore (.uplugin, module LPAnimCore, macro d'export LPANIMCORE_API) avec LPAnimRedirect.*, LPCoupleSim.h, LPCoupleSimCore.cpp copiés depuis l'addon (empreintes notées), exports renommés ; LifePlay.Build.cs : LPAnimMeasure → LPAnimCore ; addon : retirer ces fichiers de LPAnimMeasure, dépendances LPSandbox/LPAnimMeasure → LPAnimCore, plugin LPAnimCore déclaré dans LPSandbox.uplugin ; LifePlayEditorTools.Build.cs garde LPAnimMeasure jusqu'à DC2 (le jeu compile alors avec la sandbox, pas encore sans).
• Livrable : DC1-IMPL.md (fichiers, empreintes avant/après, diff des Build.cs).

DC1-T2 — Compilation (A-BUILD, M0 haiku)

• Consigne : commande Build.bat exacte ; contrôle des dates de DLL (jeu, addon, LPAnimCore) ; recopier erreurs fichier:ligne ; ne rien corriger. Livrable : DC1-BUILD.md. Critère Done : code 0.

DC1-T3 — Validation (A-VAL, M2 sonnet + utilisateur)

• Cas : (a) jeu en éditeur et en build Development : marche avec clips convertis quand LPAnimTarget.ini = game (journal propre à LPAnimRedirect) ; (b) ShowCouple : placement, boîte, glissement identiques (contrôle visuel) ; (c) sandbox : lps_couple, lps_interaction, lps_asset_integration s'ouvrent ; tournée Mesure automatique identique à SB2-REF (JSON/CSV) ; (d) LPAnimEval sur Quaternius identique à SB4.
• Livrable : DC1-VAL.md PASS/FAIL + preuves.

DC1-T4 — Intégration (A-INT, M2 sonnet) — commit addon, pin, commit jeu DC1.

DC1-T5 — Docs (A-DOC, M2 sonnet) — CHG, 20_Chaine_Animations.md, 21 (graphe de modules), 07_Architecture_5.5.md.

---

Lot DC2 — Commandlets de mods dans la sandbox

• Objectif : LifePlayEditorTools ne dépend plus de LPAnimMeasure ; à la fin de DC2, le jeu compile sans la sandbox.

DC2-T1 — Déplacement

• Agent : A-IMPL-H | Modèle : M3 opus
• Travail : nouveau module éditeur LPModTools dans LPSandbox.uplugin ; y déplacer LPAnimEval, LPAnimTwist, LPAnimCatalog, LPAnimIdentify, LPAnimChecks, LPAnimMethodSelect, LPHairFromStaticMesh (+ .h) ; reprendre leurs dépendances moteur depuis LifePlayEditorTools.Build.cs ; retirer LPAnimMeasure de LifePlayEditorTools.Build.cs ; retirer du jeu les sources déplacées (après commit addon).
• Livrable : DC2-IMPL.md.

DC2-T2 — Compilation (A-BUILD, M0 haiku) — avec la sandbox et sans (dossier addon déplacé puis remis) ; deux codes 0.

DC2-T3 — Validation (A-VAL, M2 sonnet)

• Cas : (a) -run=LPAnimEval, -run=LPAnimTwist sur Quaternius : sorties identiques à SB4 ; (b) -run=LPHairFromStaticMesh sur une coiffure Pocolov de référence dans un dossier temporaire : asset équivalent (nombre d'os, poids, bornes) ; (c) sans sandbox, -run=LPAnimEval échoue proprement (commandlet inconnu), le jeu démarre en éditeur et en -game.
• Livrable : DC2-VAL.md.

DC2-T4 — Intégration (A-INT, M2 sonnet) — commit addon, pin, commit jeu DC2.

DC2-T5 — Docs (A-DOC, M2 sonnet) — CHG, 09_Commandes_Utiles.md, 20, 21, 08_Guide_Developpeur.md.

---

Lot DC3 — Scripts, données et sources de mods

• Objectif : l'atelier des mods est entièrement dans la sandbox.

DC3-T1 — Scripts structurants

• Agent : A-IMPL-H | Modèle : M3 opus
• Travail : BuildMod.ps1, ModSource.ps1, AnimPipeline.ps1 déplacés dans LifePlay-Sandbox\Tools\mods / Tools\anim ; ProjectRoot remplacé par la règle de la SPEC (-GameRoot, défaut lu dans Config/LPSandbox.ini) ; chemins vers Releases/, Mods/, Saved/, UnrealEditor-Cmd.exe, LifePlay.uproject résolus depuis le dossier du jeu ; chemins vers ModSources, Tools/anim, Tools/mods résolus depuis l'addon.
• Livrable : DC3-IMPL.md (table « ancien chemin → nouveau chemin » par script).

DC3-T2 — Déplacements simples et références

• Agent : A-IMPL-L | Modèle : M2 sonnet
• Travail : NewMod.ps1, EditMod.ps1, HairPipeline.ps1, HairImportFbx.py, HairMaterials.py, FbxMaterialMap.py, ImportQuaternius.py, Tools/anim/*, Tools/hairs, Tools/mods, ModSources/, guide des moddeurs (Docs/Modding/FullGuides/Creating_Asset_Mods.md, explanation.lphair) vers LifePlay-Sandbox\Docs\, Config/LPSandbox.ini, lanceurs Tools/debug/*sandbox*.bat ; mise à jour des références (SplitModules.ps1 message vers BuildMod, .gitignore du jeu et de l'addon) ; empreintes avant/après.
• Livrable : DC3-IMPL-L.md.

DC3-T3 — Validation (A-VAL, M2 sonnet + utilisateur)

• Cas : (a) BuildMod -Name lpr_hair_pocolov depuis l'addon : zip produit, contenu du pak identique à la version précédente (liste et tailles) ; (b) NewMod dans un dossier temporaire puis suppression ; (c) ModSource monte et démonte, Mods/ vide à la fin ; (d) BuildMod -Retarget rigs -RetargetOnly : ligne RETARGET rigs prets au bon jeton ; (e) lanceurs sandbox fonctionnels ; (f) aucun script restant dans le jeu ne référence un fichier déplacé.
• Livrable : DC3-VAL.md.

DC3-T4 — Intégration (A-INT, M2 sonnet) — commit addon, pin, commit jeu DC3.

DC3-T5 — Docs (A-DOC, M2 sonnet) — CHG, 13_Protocole_Coiffure.md, 16_H3_Mods_Paquets.md, 09 § 7 (publication), README de l'addon (atelier des mods).

---

Lot DC4 — Preuve « jeu seul » et clôture

DC4-T1 — Clone propre (A-BUILD, M0 haiku)

• git clone local du dépôt du jeu (HEAD) dans un dossier temporaire sans dossier frère LifePlay-Sandbox ; Build.bat LifePlayEditor et Build.bat LifePlay Win64 Development sur ce clone (C++ seul, sans Content lourd si non requis) ; codes de sortie ; suppression du clone après relevé.

DC4-T2 — Validation finale (A-VAL, M2 sonnet + utilisateur)

• Jeu de travail sans sandbox : éditeur, -game, build Development empaqueté (nouvelle partie + Continuer, règle feedback-packaging-test-paths) ; avec sandbox : trois mods de la sandbox, LPAnimEval, BuildMod.

DC4-T3 — Docs (A-DOC, M2 sonnet)

• 21_Sandbox_Addon.md (acceptation DC), README du jeu (la sandbox n'est plus requise, plus de lien vers le guide des moddeurs), 08_Guide_Developpeur.md, mémoire projet.

DC4-T4 — Évaluation (A-DOC + Orch, M4 opus)

• Tableau « modèle prévu vs utilisé vs résultat » par fiche ; état prêt à pousser (liste des commits, décision sur fba19bc).

---

Critères d'acceptation globaux

1. Un clone propre de LifePlay-Revival, sans LifePlay-Sandbox à côté, compile (éditeur et Development) et se lance.
2. Aucun Build.cs, .uproject ou script du jeu ne référence LPAnimMeasure, LPModTools ou un fichier déplacé.
3. Avec la sandbox présente : trois mods de la sandbox, tournée Mesure (identique à SB2-REF), LPAnimEval (identique à SB4).
4. Marche avec clips convertis et ShowCouple inchangés dans le jeu.
5. BuildMod depuis l'addon produit un mod identique à la version précédente.
6. CHG par lot, pin à jour, registre des reports tenu, modèles tracés.

Risques

• LPCoupleSim exporté par un nouveau module : symboles LPANIMMEASURE_API à renommer partout (jeu et addon), sinon liaison en échec → DC1-T1 en M3, empreintes avant/après.
• DLL périmées dans trois dossiers Binaries → contrôle des dates à chaque A-BUILD.
• Scripts déplacés qui calculaient ProjectRoot depuis leur propre dossier → règle unique de la SPEC, cas (f) de DC3-T3.
• Publication du jeu (SplitModules + zips de BuildMod) dépend désormais de la sandbox privée : acceptable (seul l'utilisateur publie), à écrire dans 09 § 7.
• Compte GitHub signalé : rien n'est poussé, ni jeu ni addon.

Vérification de bout en bout

1. Build.bat LifePlayEditor … code 0 avec et sans sandbox (A-BUILD).
2. Clone propre sans sandbox : compilation code 0 (DC4-T1).
3. Build Development : marche (clips convertis), ShowCouple, nouvelle partie et Continuer.
4. Sandbox : trois mods, tournée Mesure automatique comparée à SB2-REF.
5. -run=LPAnimEval (Quaternius) comparé à SB4 ; BuildMod -Name lpr_hair_pocolov comparé à la version précédente.

Livrables documentaires

• Docs/Migration/24_Plan_Decouplage_Sandbox.md (ce cahier)
• Docs/Migration/etat/sandbox/DC#/*
• Docs/Migration/21_Sandbox_Addon.md, 20_Chaine_Animations.md, 09_Commandes_Utiles.md, 13, 16, 07, 08
• README de l'addon (atelier des mods), README du jeu ; CHG par lot