LifePlay-Revival/Docs/Migration/Journal_Modifications.md

# Journal des modifications — migration 5.5

> Une entrée par modification. Format : identifiant, date, lot, fichiers, raison, empreintes,
> retour arrière. Les empreintes complètes sont dans `D:\Game\LifePlay_Backup_5.5\<lot>\manifest.csv`
> et dans l'historique git.

| ID | Date | Lot | Fichiers | Raison | Avant → après | Retour arrière |
|---|---|---|---|---|---|---|
| CHG-001 | 2026-09-29 | L0 | `.gitignore` | ignorer les fichiers générés (`Build/*/FileOpenOrder`, `Content/Collections`, `Content/Developers`, `.claude/settings.local.json`) | 31 → 38 lignes | retirer le bloc « CHG-001 » |
| CHG-002 | 2026-09-29 | L0 | `.gitattributes` (nouveau) | aucune conversion de fin de ligne : restauration git identique à l'octet | — → créé | supprimer le fichier |
| CHG-003 | 2026-09-29 | L0 | `.git/` (nouveau) | dépôt local, identité locale, `core.autocrlf=false`, `core.longpaths=true` ; commit `de64933`, tag `lot-L0-base` | — → créé | supprimer `.git/` |
| CHG-004 | 2026-09-29 | L0 | `Tools/Snapshot.ps1`, `Restore.ps1`, `AssetHeaders.ps1`, `CheckIntegrity.ps1`, `LogStats.ps1` (nouveaux) | outillage de traçabilité et de test | — → créés | `git rm` |
| CHG-005 | 2026-09-29 | L0 | `Docs/Migration/**` (nouveau) | documentation 01 à 04, journal, registre, empreintes `etat/L0_*` | — → créés | `git rm` |
| CHG-006 | 2026-09-29 | L0 | `D:\Game\LifePlay_Backup_5.5\L0\` (hors projet) | sauvegarde de `.claude`, `.mcp.json`, `LifePlay.uproject`, `Config`, `Saved/Backups`, `Saved/SaveGames`, `Content/BPs` (53 fichiers) | — → créé | sans objet |

## Vérifications du lot L0

| Test | Résultat |
|---|---|
| Aller-retour `Snapshot` → modification → `Restore` (`Config/DefaultEditorSettings.ini` + fichier créé) | ✅ MD5 `85D82E7F…` retrouvé ; fichier créé retiré vers `_retires/` |
| T-STAT-01 | ⚠️ 1 package UE4 (`Content/BPs/GI.uasset`) : défaut connu, traité en L1 |
| T-STAT-02 Modules = 4.27 | ✅ 2 051 fichiers |
| T-STAT-03 environnement = L0 | ✅ 20 fichiers |
| T-STAT-04 arbre 4.27 inchangé | ✅ 144 fichiers (empreinte créée : `etat/L0_ref427.csv`) |

Aucun fichier du projet n'a été modifié en L0 en dehors de `.gitignore` et des ajouts ci-dessus.

---

## Lot L1 — Base saine (2026-09-29)

Décisions utilisateur D-01 et D-02 : `04_Cahier_Des_Charges.md` §4. Tag d'entrée `lot-L1-avant`.
Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L1\` (387 fichiers).

| ID | Date | Lot | Fichiers | Raison | Avant → après | Retour arrière |
|---|---|---|---|---|---|---|
| CHG-007 | 2026-09-29 | L1 | `Content/{BPs,UI,Structs,Scenes,Render,Characters}` (385 fichiers, 293 packages) | retour à la base 4.27 : retire tous les correctifs de contenu non suivis (dont R-03, R-04) | contenu 5.5 (empreintes `etat/L0_md5_*.csv`) → identique à 4.27 (MD5 vérifiés, 0 écart) | `Tools\Restore.ps1 -Lot L1` ou `git checkout lot-L1-avant -- Content` |
| CHG-008 | 2026-09-29 | L1 | `Tools/RunCommandlet.ps1` (nouveau) | lancement de commandlet avec journal archivé et résumé dédoublonné | — → créé | `git rm` |
| CHG-009 | 2026-09-29 | L1 | `Docs/Migration/05_Correctifs_Isoles.md`, `correctifs/P01…P06.patch` (nouveaux) | isolement des correctifs : catalogue, protocole de réimport, patchs de code 4.27 → 5.5 | — → créés | `git rm` |
| CHG-010 | 2026-09-29 | L1 | `Config/DefaultEngine.ini` | essai de retrait des sections `AndroidFileServer`/`CookerSettings` **annulé** : l'éditeur recrée la section à chaque lancement (nouveau `SecurityToken`) | inchangé (restauré depuis `lot-L1-avant`) | sans objet ; traité en L2 |

### Relevé de base : moteur 5.5 sur le contenu 4.27, sans aucun correctif

| Commandlet | Résultat | Résumé |
|---|---|---|
| `LPCheckMeshAssignment` | 5 nœuds à broches orphelines dans `GI` : 3 `GetAssetsByClass` (classe perdue : `SkeletalMesh`, `StaticMesh`, `StreetMap`), 2 `Break AssetData` (`ObjectPath`) ; 6 nœuds `EditableTextBoxStyle` (`StatMenu`, `CharGen`) | `etat/L1_LPCheckMeshAssignment_20260929-010821.txt` |
| `CompileAllBlueprints` | **6 erreurs, 100 avertissements, 0 Blueprint en échec de chargement** ; échecs : `UI/StatMenu` (3), `UI/CharGen` (3) — broche `Font` d'`EditableTextBoxStyle` | `etat/L1_CompileAllBlueprints_20260929-010931.txt` |

Les commandlets de contrôle n'ont rien écrit : contenu toujours identique à 4.27 après passage (385/385).

### Vérifications de sortie L1

| Test | Résultat |
|---|---|
| Contenu de gameplay = 4.27 | ✅ 385/385 MD5 |
| T-STAT-01 | ⏳ 293 packages UE4 (attendu : base 4.27) — resave contrôlé en `L4-CX-B07` |
| T-STAT-02, 03, 04 | ✅ |
| T-LOAD-01 | ❌ attendu : 6 erreurs (`CX-B02`), à corriger en L4 |
| T-LOAD-02 | ❌ attendu : 5 broches (`CX-B01`), à corriger en L4 |

---

## Lot L2 — Compilation propre (2026-09-29)

Tag d'entrée `lot-L2-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L2\` (`.uproject`,
`DefaultEngine.ini`) ; dossiers mis de côté dans `L2\_purge\` (manifeste `L2\purge_manifest.csv`).

| ID | Date | Lot | Fichiers | Raison | Avant → après | Retour arrière |
|---|---|---|---|---|---|---|
| CHG-011 | 2026-09-29 | L2 | `LifePlay.uproject` | `TargetPlatforms` `WindowsNoEditor` → `Windows` ; section `Plugins` explicite : `ModdingExtra`, `StreetMap`, `EnhancedInput` activés ; `McpAutomationBridge` limité à la cible `Editor` (`TargetAllowList`) ; `AndroidFileServer` désactivé | MD5 `DA10325E…` → nouveau | `Tools\Restore.ps1 -Lot L2 -Only LifePlay.uproject` |
| CHG-012 | 2026-09-29 | L2 | `Config/DefaultEngine.ini` | retrait de la section `AndroidFileServerRuntimeSettings` (et de son `SecurityToken`) ; le plugin étant désactivé, l'éditeur ne la recrée plus (vérifié après un lancement) | 14 lignes retirées | `Tools\Restore.ps1 -Lot L2 -Only Config\DefaultEngine.ini` |
| CHG-013 | 2026-09-29 | L2 | `Binaries`, `Intermediate`, `Saved/Cooked`, `Saved/StagedBuilds`, `Plugins/*/Binaries`, `Plugins/*/Intermediate`, `Build/WindowsNoEditor`, `Build/LinuxNoEditor` (≈ 13,9 Go) | reconstruction à partir de zéro ; **déplacés**, pas supprimés | → `D:\Game\LifePlay_Backup_5.5\L2\_purge\` | `Move-Item` inverse (voir `purge_manifest.csv`) ; suppression définitive sur décision utilisateur |

### Vérifications de sortie L2

| Test | Résultat |
|---|---|
| T-BUILD-01 `LifePlayEditor Win64 Development` | ✅ code 0, 233 s, **0 erreur, 0 avertissement** dans le code du projet et de ses plugins (2 messages de configuration UBT propres à `McpAutomationBridge`) — `Saved/Logs/portage/L2_Build_LifePlayEditor_20260929-011800.log` |
| T-BUILD-02 `LifePlay Win64 Development` | ✅ code 0, 97 s, 0 erreur, 0 avertissement ; exécutable 300 Mo (328 Mo avant : `McpAutomationBridge` exclu du jeu) |
| T-LOAD-04 démarrage éditeur | ✅ 0 `LogClass: Error`, 0 échec de chargement de package ou de plugin |
| Non-régression `LPCheckMeshAssignment` | ✅ relevé identique à L1 (10 erreurs, 285 avertissements, mêmes signatures) |
| ERR-023 (`AndroidFileServer`) | ✅ `DefaultEngine.ini` non réécrit après lancement |
| T-STAT-02, 03, 04 | ✅ |


---

## Lot L3 — Journalisation efficace (2026-09-29)

Tag d'entrée `lot-L3-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L3\` (6 entrées, dont 2 fichiers
créés que `Restore.ps1` retirerait).

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-014 | 2026-09-29 | L3 | `Source/LifePlay/LifePlay.h`, `LifePlay.cpp` | catégorie `LogLifePlay` | `Tools\Restore.ps1 -Lot L3` |
| CHG-015 | 2026-09-29 | L3 | `Source/LifePlay/LPSessionLogSubsystem.h/.cpp` (nouveaux), `LifePlay.Build.cs` (+ `EngineSettings`) | sous-système de `GameInstance`, **sans modification de Blueprint** : résumé de démarrage (versions, modules, fichiers par type) ; bilan de session à la fermeture ou via la commande console `LifePlay.LogSummary` (messages par catégorie, 25 signatures d'avertissement/erreur les plus fréquentes, chiffres normalisés en `#`, pile d'appel Blueprint incluse, plafond de 4 000 signatures). Les messages du moteur ne sont **pas** modifiés (comparabilité A/B avec 4.27) | idem |
| CHG-016 | 2026-09-29 | L3 | `Plugins/ModdingExtra/.../ModdingExtraBPLibrary.cpp` | instrumentation `LogLPModdingTrace` (Warning) → `LogModdingExtra` (Verbose, même format de ligne) ; échec de `LoadTxt` signalé une seule fois par fichier ; échec de `SaveTxt` désormais signalé (il était silencieux) | idem |
| CHG-017 | 2026-09-29 | L3 | `Tools/LogStats.ps1`, `Docs/Migration/03_Plan_Migration_Tests.md` | prise en compte de `LogModdingExtra` ; procédure A/B (`-LogCmds="LogModdingExtra Verbose"`) | `git revert` |

### Vérifications de sortie L3

Sessions `UnrealEditor -game` (valables pour le journal, pas pour l'affichage des personnages —
règle §2 du document 03) : `Saved/Logs/portage/L3_game_20260929-012748.log` (niveau par défaut) et
`L3_game_verbose_20260929-013032.log` (trace détaillée).

| Test | Résultat |
|---|---|
| T-BUILD-01, T-BUILD-02 | ✅ 0 erreur, 0 avertissement |
| T-LOG-01 résumé de démarrage | ✅ 20 lignes `LogLifePlay` ; 16 modules ; comptes par type identiques à l'inventaire 4.27 (`vin_Base` : 752 `.lpscene`, 286 `.lpaction`…) |
| T-LOG-01 bilan de session | ✅ écrit à la fermeture ; signatures dédoublonnées avec leur pile d'appel |
| Bruit d'instrumentation | ✅ `LogLPModdingTrace` : 0 ligne au niveau par défaut (1 300 à 5 400 avant) ; 58 lignes `LogLifePlay` pour toute la session |
| Trace détaillée | ✅ 1 284 lignes `LogModdingExtra` avec `-LogCmds` ; `ModLauncher.config` absent signalé **une** fois |
| A/B de format avec la build 4.27 | ✅ `LogStats -Compare` lit les deux journaux ; toutes les énumérations communes aux deux sessions sont identiques (écarts limités aux dossiers que seule l'une des sessions a atteints) |
| T-STAT-02, 03, 04 | ✅ |

Découverte au passage : les erreurs `ParseIntoArray` (ERR-004) viennent de `GI.populateClothes4`,
appelée par `Person.ReceiveBeginPlay`.


---

## Lot L4 — Réimport contrôlé des correctifs (2026-09-29)

### Sous-lot L4-CX-B01 — broches AssetRegistry de `GI` (ERR-020)

Tag d'entrée `L4-CX-B01-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B01\` (`GI.uasset`, MD5 `F4550DA5…`).

| Étape du protocole | Résultat | Preuve (`Docs/Migration/etat/`) |
|---|---|---|
| 2. Photographie avant | `GI::EventGraph` : 6 199 nœuds, 23 662 lignes | `L4-CX-B01_dump_avant.txt` |
| 3. Simulation `-DryRun` | 3 `[enum]` (`StreetMap`, `StaticMesh`, `SkeletalMesh`), 2 `[path]` (1 consommateur chacun), 0 non traité — **conforme à l'attendu** | `L4-CX-B01_dryrun.txt` |
| 4. Application | 3 énumérations, 2 chemins, 1 Blueprint enregistré, 0 cas non traité, 0 échec | `L4-CX-B01_application.txt` |
| 5. Photographie après + diff | 6 201 nœuds ; **35 lignes différentes, toutes attendues** : 3 nœuds `AssetRegistry::GetAssetsByClass` → `LPAssetRegistryHelpers::GetAssetsByClassName` avec leur classe d'origine ; 2 nœuds `GetAssetObjectPath` insérés, reprenant les consommateurs des sorties `ObjectPath` orphelines. Aucune autre ligne du graphe ne change | `L4-CX-B01_dump_apres.txt`, `L4-CX-B01_diff.txt` |
| 6. `LPCheckMeshAssignment` | 0 broche orpheline dans `GI` (restent les 6 nœuds de CX-B02) | `L4-CX-B01_LPCheckMeshAssignment_*.txt` |
| 6. `CompileAllBlueprints` | identique au relevé de base : 6 erreurs (CX-B02), 100 avertissements, 0 échec de chargement ; **aucune erreur nouvelle** | `L4-CX-B01_CompileAllBlueprints_*.txt` |
| 7. A/B d'exécution | **en attente** : la cuisson exige CX-B02 ; sera faite sur la build Development qui suit CX-B02 | — |

| ID | Date | Lot | Fichiers | Raison | Avant → après | Retour arrière |
|---|---|---|---|---|---|---|
| CHG-018 | 2026-09-29 | L4-CX-B01 | `Content/BPs/GI.uasset` | réimport de CX-B01 (`LPFixAssetRegistryPins`) | MD5 `F4550DA5…` (UE4) → `0AA14EDB…` (UE5, réenregistré par la commandlet) | `Tools\Restore.ps1 -Lot L4-CX-B01` ou `git checkout L4-CX-B01-avant -- Content/BPs/GI.uasset` |

### Sous-lot L4-CX-B02 — `EditableTextBoxStyle` (ERR-021) : essai 1 **rejeté**

Tag d'entrée `L4-CX-B02-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B02\`.
Preuves : `Docs/Migration/etat/L4-CX-B02_essai1_rejete/`.

| Étape | Résultat |
|---|---|
| Simulation | 6 nœuds sur 6 attendus |
| Application | « 6 traités, 0 liaison non gérée, 0 échec » |
| Compilation | 0 erreur (6 avant), 98 avertissements, 0 broche orpheline |
| **Relecture du diff** | ❌ `CharGen::Make_64` a perdu sa liaison `Font` **sans** recevoir la liaison `TextStyle` : sa police retombe sur la valeur par défaut (aucune police, couleur magenta). Défaut **silencieux** : compilation et rapport de la commandlet au vert |

Cause : `LPFixEditableTextBoxFont` coupait la broche `Font` de chaque nœud au fil du parcours. Dans
`CharGen`, `Break_62` est parcouru avant `Make_64` : la coupure effaçait aussi la liaison vue depuis
`Make_64`, qui n'était plus rebranché. Dépend de l'ordre des nœuds (sans effet dans `StatMenu`). La
campagne du 2026-09-07 avait utilisé cette commandlet : le défaut y était très probablement présent.

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-019 | 2026-09-29 | L4-CX-B02 | `Content/UI/StatMenu.uasset`, `CharGen.uasset` | essai 1 appliqué puis **annulé** par `Tools\Restore.ps1 -Lot L4-CX-B02` (MD5 `34807BE0…`, `63CA2A78…` retrouvés) | sans objet |
| CHG-020 | 2026-09-29 | L4-CX-B02 | `Source/LifePlayEditorTools/LPFixEditableTextBoxFontCommandlet.cpp` | les broches `Font` ne sont coupées qu'après le relevé complet de la topologie | `git revert` |
| CHG-021 | 2026-09-29 | L4 | `Tools/ReimportCorrectif.ps1` (nouveau) | automatisation des étapes 1 à 6 du protocole | `git rm` |

Enseignement pour le protocole : l'étape 5 (relecture du diff nœud par nœud) est indispensable ; ni la
compilation ni le rapport de la commandlet n'ont détecté ce défaut.

### Sous-lot L4-CX-B02b — `EditableTextBoxStyle` (ERR-021) : essai 2 **validé**

Tag d'entrée `L4-CX-B02b-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B02b\`. Exécuté avec
`Tools\ReimportCorrectif.ps1` et la commandlet corrigée (CHG-020).

| Étape | Résultat | Preuve (`etat/`) |
|---|---|---|
| 3. Simulation | 6 nœuds sur 6 attendus | `L4-CX-B02b_dryrun.txt` |
| 4. Application | 6 traités, 2 Blueprints, 0 liaison non gérée, 0 échec ; **4 rebranchements `TextStyle`** (2 par Blueprint) | `L4-CX-B02b_application.txt` |
| 5. Diff | `StatMenu` 425 → 422 lignes, `CharGen` 4 458 → 4 455 ; 9 lignes chacun, symétriques ; les 4 `Make` ont `TextStyle ← Break_62.TextStyle` ; plus aucune broche `Font` orpheline | `L4-CX-B02b_diff_*.txt`, `L4-CX-B02b_dump_*` |
| 6. `LPCheckMeshAssignment` | **0 broche orpheline dans tout le projet** | `L4-CX-B02b_LPCheckMeshAssignment_*.txt` |
| 6. `CompileAllBlueprints` | **0 erreur** (6 avant), 98 avertissements (100 avant : les 2 « Font obsolète » disparaissent), 0 échec de chargement | `L4-CX-B02b_CompileAllBlueprints_*.txt` |

| ID | Date | Lot | Fichiers | Raison | Avant → après | Retour arrière |
|---|---|---|---|---|---|---|
| CHG-022 | 2026-09-29 | L4-CX-B02b | `Content/UI/StatMenu.uasset`, `Content/UI/CharGen.uasset` | réimport de CX-B02 | `34807BE0…` → `131E4B96…` ; `63CA2A78…` → `8D4E4200…` | `Tools\Restore.ps1 -Lot L4-CX-B02b` ou `git checkout L4-CX-B02b-avant -- Content/UI` |

**Effet sur les tests** : T-LOAD-01 (0 erreur de compilation) et T-LOAD-02 (0 broche orpheline) passent
pour la première fois depuis le retour à la base saine.

### Sous-lot L4-CX-B03 — mur à échelle nulle dans `CentralLondon` (validé)

Tag d'entrée `L4-CX-B03-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B03\` (`CentralLondon.umap`
MD5 `C063EE72…` = 4.27, `CentralLondon_BuiltData.uasset`). Correctif sur une propriété d'acteur : le
contrôle se fait par rapport de la commandlet avant/après (pas de graphe).

| Étape | Résultat | Preuve (`etat/`) |
|---|---|---|
| Rapport avant | 1 composant : `Wall.StaticMeshComponent0`, échelle X=0 Y=12,56 Z=5,75, cube moteur visible, `BlockAll` | `L4-CX-B03_rapport_avant.txt` |
| Application `-Fix -Scale=0.1` | X 0 → 0,1 (panneau de 10 cm : corps physique valide, aspect de mur plat conservé) ; 1 carte enregistrée, 0 échec | `L4-CX-B03_application.txt` |
| Rapport après | 0 composant à échelle nulle | `L4-CX-B03_rapport_apres.txt` |
| Non-régression | `LPCheckMeshAssignment` 0 broche orpheline ; `CompileAllBlueprints` 0 erreur, 0 échec de chargement ; seule la carte a changé (`_BuiltData` inchangé) | résumés `L4-CX-B03_*` |

| ID | Date | Lot | Fichiers | Avant → après | Retour arrière |
|---|---|---|---|---|---|
| CHG-023 | 2026-09-29 | L4-CX-B03 | `Content/Scenes/CentralLondon.umap` | `C063EE72…` → `21912547…` | `Tools\Restore.ps1 -Lot L4-CX-B03` ou `git checkout L4-CX-B03-avant -- Content/Scenes` |

### Sous-lot L4-CX-B04 — événements `On Clicked` orphelins (validé)

Tag d'entrée `L4-CX-B04-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B04\`. `Tools\ReimportCorrectif.ps1`.

| Étape | Résultat | Preuve (`etat/`) |
|---|---|---|
| Simulation | 3 sur 3 attendus | `L4-CX-B04_dryrun.txt` |
| Application | `TopRight` : `StatButtonL` (1 nœud en aval) ; `CharGen` : `ButtonEyelashColor` (5), `ButtonPreviewErect` (1) ; 3 retirés, 0 échec | `L4-CX-B04_application.txt` |
| Diff | `TopRight` 907 → 906 nœuds, `CharGen` 1 320 → 1 318 : **seuls les 3 événements disparaissent**. Les nœuds en aval sont conservés (déjà inatteignables ; la photographie n'inclut pas les broches d'exécution) | `L4-CX-B04_diff_*.txt` |
| Contrôles | 0 broche orpheline ; `CompileAllBlueprints` 0 erreur, **95** avertissements (98 avant), 0 échec de chargement | résumés `L4-CX-B04_*` |

| ID | Date | Lot | Fichiers | Avant → après | Retour arrière |
|---|---|---|---|---|---|
| CHG-024 | 2026-09-29 | L4-CX-B04 | `Content/UI/TopRight.uasset`, `Content/UI/CharGen.uasset` | `C34F7BB0…` → `B3B0ED10…` ; `8D4E4200…` → `A7C718C6…` | `Tools\Restore.ps1 -Lot L4-CX-B04` ou `git checkout L4-CX-B04-avant -- Content/UI` |

### Build Development empaquetée `D:\Game\LifePlay_Build_5.5_L4` (2026-09-29)

État du code : `L4-CX-B04-apres`. Commande : `RunUAT BuildCookRun -platform=Win64 -clientconfig=Development
-build -cook -stage -archive` (journal `Saved/Logs/portage/L4_BuildCookRun_20260929-030445.log`).

| Test | Résultat |
|---|---|
| T-LOAD-05 cuisson | ✅ `Success - 0 error(s), 94 warning(s)` ; `BUILD SUCCESSFUL`, `ExitCode=0` |
| Données livrées en fichiers nus | ✅ `Windows/LifePlay/Content/Modules` présent ; résumé de démarrage : 16 modules, comptes identiques à 4.27 |
| Test de fumée (lancement automatisé) | ✅ 185 s sans plantage, fermeture propre, bilan de session écrit ; menu principal atteint (journal `Saved/Logs/portage/L4_build_smoke_20260929.log`) |
| T-RUN-02 à T-RUN-05 (génération de personnages, scène, sauvegarde, 30 min) | ⏳ **nécessite une partie jouée** : scénario `03_Plan_Migration_Tests.md` §4, sur cette build **et** sur la référence 4.27 |

Note : le `LifePlay.exe` à la racine de la build est un lanceur ; le processus du jeu est
`Windows/LifePlay/Binaries/Win64/LifePlay.exe`.

### Correction de l'empaquetage — ERR-026 (2026-09-29)

**Retour utilisateur sur `LifePlay_Build_5.5_L4`** : « le jeu ne fonctionne pas, la plupart des assets ne sont
pas intégrés ». Confirmé : **3 257 packages cuits au lieu de 8 561**. LifePlay charge maillages, vêtements,
coiffures et textures par chemin à l'exécution (`GetAssetsByClass`, `GetAssetByObjectPath`) ; le cuiseur,
qui ne suit que les références statiques, ne les voit pas. Les builds du 28/09 utilisaient `-CookAll` ; ce
paramètre n'avait pas été repris. **Erreur de ma part, non détectée faute de test du volume cuit** : le
test T-PKG-01 est ajouté au plan de tests.

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-025 | 2026-09-29 | L4 | `Config/DefaultGame.ini` | `+DirectoriesToAlwaysCook=(Path="/Game")` (exclusion `fBlah` conservée) : tout le contenu est cuit quelle que soit la méthode d'empaquetage, y compris le bouton « Package » de l'éditeur | `Tools\Restore.ps1 -Lot L4-cook` |
| CHG-026 | 2026-09-29 | L4 | `Docs/Migration/03_Plan_Migration_Tests.md`, `Registre_Erreurs.md` | test T-PKG-01 ; ERR-026 | `git revert` |

Build `D:\Game\LifePlay_Build_5.5_L4b` (`BuildCookRun` Development, journal `L4b_BuildCookRun_20260929-081054.log`) :

| Test | Résultat |
|---|---|
| T-LOAD-05 cuisson | ✅ `Success - 0 error(s), 95 warning(s)` |
| T-PKG-01 contenu cuit | ✅ **8 561** `.uasset`, 2,6 Go (= référence 4.27) |
| Test de fumée (150 s, sans intervention) | ✅ aucun plantage, fermeture propre ; une partie a démarré et 4 personnages ont été générés |
| Premier A/B (`LogStats -Compare`, échantillon faible) | `Accessed None` maillage/perso **0,50** (4.27 : 0,27 ; 5.5 du 28/09 : 16,6) ; **4 acteurs distincts sur 4** (5.5 du 28/09 : tous `Person_C_0`) → CX-B01 corrige très probablement ERR-002 ; **à confirmer visuellement** (T-RUN-02 à 04) |

`LifePlay_Build_5.5_L4` (incomplète) est conservée comme preuve et peut être supprimée.

---

## Lot L5 — Données et personnages (2026-09-29)

### Diagnostic d'ERR-027 (personnages de quête invisibles ou dévêtus)

Partie jouée par l'utilisateur sur `LifePlay_Build_5.5_L4b` (journal archivé
`Saved/Logs/portage/L4b_partie_utilisateur_20260929.log`) : PNJ aléatoires corrects ; personnages
créés par preset invisibles en dialogue, dévêtus dans le mini-jeu.

| Étape | Constat | Preuve |
|---|---|---|
| Indicateur | `Accessed None` maillage : 26,5 / personnage (1 219 / 46) contre 0,27 en 4.27 (4 / 15) | `Tools\LogStats.ps1` |
| Pile d'appel | `GeneratePerson → LoadPreset → GenerateAndApplyStrings/Bools` lit `MeshSexRace.Mesh` et `SMBool.SkeletalMesh` vides ; 0 occurrence en 4.27 | journal utilisateur |
| Pistes écartées (identiques en 4.27) | `clearVariable` (ERR-028, 211 contre ≈ même nombre en 4.27) ; `populateClothes4` / `ParseIntoArray` (631 contre 630) | `Grep` sur les deux journaux |
| Structures | `Mesh_2…` ∈ `Structs/MeshSexRace` ; `SkeletalMesh_2…` ∈ `Structs/SMBool` | recherche binaire |
| Diff de graphes 4.27 / 5.5 (`LPDumpFunction`) | `GenerateAndApplyStrings`, `GenerateAndApplyBools`, `LoadMeshIfNeeded`, `getSkeletalMeshFromPath`, `SMBoolToSkeletalMesh` : **logique identique** (seuls écarts : `SetSkeletalMesh` → `SetSkinnedAssetAndUpdate`, redirection moteur ; broche `Key` du `PrintString` UE5) | `etat/L5-diag_dump427_*`, `etat/L5-diag_dump55_*` |
| Mécanisme | `MeshSexRace` est chargé à la demande : `LoadMeshIfNeeded(Index)` → `getSkeletalMeshFromPath(AssetPath)` → `LPAssetRegistryHelpers::GetAssetByObjectPath(…, OnlyOnDisk=true)` → `GetAsset` → `Cast<SkeletalMesh>` | dumps |
| Réglages | `LegacyPercentage` absent des deux `GameSettings.sav` : valeur par défaut identique | lecture binaire |

Conclusion provisoire : code et réglages identiques ; le seul maillon qui change de moteur est la
résolution chemin → asset (`GetAssetByObjectPath`, porté de `FName` vers `FSoftObjectPath`).

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-027 | 2026-09-29 | L5 | `Source/LifePlay/LPAssetRegistryHelpers.cpp` | instrumentation permanente : tout chemin non résolu est signalé une fois (`LogLifePlay` Warning, chemin reçu et chemin interprété), réussites en `Verbose` | `Tools\Restore.ps1 -Lot L5-instr` |

Build `D:\Game\LifePlay_Build_5.5_L5a` (instrumentée) : éditeur et jeu compilés sans erreur ; cuisson `0 error(s), 0 warning(s)` ; T-PKG-01 : 8 561 packages ; test de fumée 180 s sans plantage (aucune partie démarrée : pas de sauvegarde dans cette build). En attente d'une scène de quête jouée.

### Relevé `MeshSexRace` pendant une partie (build L5b, `-LPDumpVars`, 2026-09-29)

| Constat | Preuve |
|---|---|
| Fin de partie : `MeshSexRace[3]` = `bridget_gp`, `MeshSexRace[4]` = `michael` **chargés** ; les 22 autres corps vides (non utilisés ; 6 corps legacy jamais chargés car `LegacyPercentage = 0`) | `[dump fin]`, `Saved/Logs/portage/L5b_partie_utilisateur_20260929.log` |
| 4 PNJ aléatoires : 0 erreur. Chaque personnage de quête : ≈ 38 lectures de `Mesh` vide | chronologie du journal |
| Pile : `LoadPreset → GenerateAndApplyStrings → PlayerChangeRace → UpdatePlayerMeshWithMorphs → UpdatePlayerMesh` (boucle sur `MeshSexRace`, lecture de `Mesh.Materials`) | idem |
| Hypothèse « résolution de chemin » : **écartée** (seuls `Pubes05/06`, faux en 4.27 aussi) | instrumentation CHG-027 |
| **Base de comparaison invalide** : la session 4.27 de référence n'a chargé **aucun** preset de quête (`GenerateAndApplyStrings` ×2). Le « 0 occurrence en 4.27 » ne prouve rien (piège §5.3 du rapport du 28/09). Journal archivé : `Saved/Logs/portage/REF427_session_20260928_sans_quete.log` | `Grep` |

Suite : session 4.27 jouant les mêmes scènes de quête, puis comparaison normalisée.

Note de traçabilité : la sauvegarde `L5-instr` de `LPSessionLogSubsystem.*` a été prise après modification ; la version antérieure est dans git (`0baf4cf`).

| CHG-028 | 2026-09-29 | L5 | `Source/LifePlay/LPSessionLogSubsystem.h/.cpp` | capteur d'exceptions de script (-LPTraceScriptEx, -LPTraceLocals, -LPTraceMax) : relève les variables locales du cadre Blueprint au moment de l'erreur ; actif seulement avec l'option (le moteur supprime sa pile d'appel quand un écouteur est branché : elle est réécrite). Validé en -game. | `Tools\Restore.ps1 -Lot L5-trace` |

### ERR-027 — cause racine identifiée (2026-09-29)

Chaîne causale, établie par le capteur L5c et le code source des deux moteurs :

1. La scène `vin_Pregnancy/Scenes/pregnant_trap.lpscene` appelle `generatePersonTemporary()` **sans argument**
   (personnage aléatoire).
2. Les arguments `()` sont découpés par `ParseIntoArray` (non culling). Sur une **chaîne vide** :
   - UE 4.27 (`String.cpp:947`, garde `*Start != '\0'`) → **0 élément** ;
   - UE 5.5 (`String.cpp.inl:1306`, réécrit sur `UE::String::ParseTokens`, qui visite toujours le dernier
     jeton) → **1 élément vide `[""]`**.
3. `GeneratePerson` teste `Length(Presets) > 0` : en 5.5, il prend le chemin « presets » au lieu du chemin aléatoire.
4. Il charge chaque `.lpcharacter` dont le nom se termine par `"" + ".lpcharacter"` : **les 141 presets**,
   appliqués successivement (journal L5c : stéréotypes, fantasy, âges, silhouettes… puis `phenotypes/*`).
5. Un preset de phénotype impose `INFO Race: African/Asian/Caucasian` → `PlayerChangeRace` → corps legacy
   `MeshSexRace[0..2|5..7]`, jamais chargé (`LegacyPercentage = 0`) → **corps vide : invisible ; vêtements
   Daz sans support : dévêtu**.

Le rapport du 2026-09-28 (§4) avait écarté `ParseIntoArray` (« implémentation identique ») : c'est exact pour
une chaîne non vide, **faux pour la chaîne vide**. Toutes les fonctions Blueprint de la chaîne sont identiques
entre 4.27 et 5.5 ; la divergence est dans le moteur.

Preuves : `Saved/Logs/portage/L5c_partie_utilisateur2_20260929.log`, `etat/L5-diag_dump55exec_GI_GeneratePerson.txt`,
`etat/L5-diag_dump55exec_GI_GenerateAndApplyStrings.txt`.

### Sous-lot L4-CX-B08 — `ParseIntoArray` au comportement UE 4.27 (ERR-027) — validé statiquement

Tag d'entrée `L4-CX-B08-avant`. Sauvegarde : `D:\Game\LifePlay_Backup_5.5\L4-CX-B08\` (17 Blueprints ; 4 fichiers
source créés, retirés par `Restore.ps1` en cas de retour).

| Étape | Résultat | Preuve (`etat/`) |
|---|---|---|
| Fonction de remplacement | `ULPStringCompat::ParseIntoArray` : transcription de l'algorithme 4.27 (chaîne vide → `[]` ; séparateur sensible à la casse), même signature que `UKismetStringLibrary::ParseIntoArray` | `Source/LifePlay/LPStringCompat.*` |
| Simulation | 114 nœuds, 17 Blueprints (GI 73, Person 10, Room 7, StreetMap_Static 4, 13 widgets) ; rien écrit | `L4-CX-B08_dryrun.txt` |
| Application | 114 rebranchés, 0 écart de liaison (contrôle intégré : liaisons et valeurs par défaut de chaque broche identiques avant/après), 0 échec | `L4-CX-B08_application.txt` |
| Contrôles | 0 broche orpheline ; `CompileAllBlueprints` 0 erreur, 95 avertissements (inchangé), 0 échec de chargement | résumés `L4-CX-B08_*` |

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-029 | 2026-09-29 | L4-CX-B08 | `Source/LifePlay/LPStringCompat.h/.cpp`, `Source/LifePlayEditorTools/LPFixParseIntoArrayCommandlet.h/.cpp` (nouveaux) ; 17 Blueprints | `ParseIntoArray` UE5 renvoie `[""]` pour une chaîne vide (UE4 : `[]`) : `generatePerson()` sans argument chargeait les 141 presets | `Tools\Restore.ps1 -Lot L4-CX-B08` ou `git checkout L4-CX-B08-avant -- Content Source` |
| CHG-030 | 2026-09-29 | L5 | `Source/LifePlayEditorTools/LPDumpFunctionCommandlet.cpp` | option `-Exec` (broches d'exécution) | `Tools\Restore.ps1 -Lot L5-dumpexec` |

### Validation d'exécution de CX-B08 — build `LifePlay_Build_5.5_L5d` (2026-09-30)

Partie jouée par l'utilisateur : **personnages de quête et personnages aléatoires visibles et habillés**.
Journal : `Saved/Logs/portage/L5d_partie_utilisateur_20260930.log`.

| Mesure | 5.5 avant (L5b/L5c) | 5.5 L5d | 4.27 (quête jouée) |
|---|---:|---:|---:|
| Personnages générés | 16 | 40 | 16 |
| Presets de phénotype/stéréotype chargés à tort | tous | **0** | 0 |
| Lectures `Mesh_2` / `SkeletalMesh_2` vides | 378+ | **0** | 0 |
| `Accessed None` maillage / personnage | 43,7 | **0,38** | 0,06 |
| Plantages | 0 | 0 | 0 |

Résidu : 15 lectures `GetSkeletalMesh_DEPRECATED` vides (composants proxy ; dette R-03, lot L7a) ; `ModLauncher.config`
(ERR-014) et `OldPlayer.lpcharacter` absents (build sans sauvegarde antérieure). Cuisson L5d : 0 erreur,
95 avertissements (à examiner : la cuisson L5c en comptait 0).

---

## Lot L6 — Validation V1 (2026-09-30)

Partie utilisateur sur `LifePlay_Build_5.5_L5d` : **42 min, 271 personnages, aucun plantage ; sauvegarde (`1.sav`,
le jeu numérote les emplacements) et rechargement fonctionnels**. Journaux : `Saved/Logs/portage/V1_partie_20260930*.log`.
Anomalies signalées : ERR-030 à ERR-034 (registre).

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-031 | 2026-09-30 | L6a | `Config/DefaultEngine.ini` | `r.DefaultFeature.AntiAliasing=2` (clé UE4, ignorée par UE5 : « dummy variable ») → `r.AntiAliasingMethod=2` (TAA, comme en 4.27) ; le jeu tournait en TSR (défaut UE5). Autres réglages vérifiés identiques à 4.27 : GI dynamique 0, reflets SSR, ombres virtuelles 0 | `Tools\Restore.ps1 -Lot L6a` |

Validation L6a (build `LifePlay_Build_5.5_L6a`, partie utilisateur 2026-09-30) : **scintillement disparu** (ERR-032 clos).
Capteur « read property Person » : relevé dans `GI::ReturnStatIfNeeded` (variable de scène `Player`, classe `Person`,
tableau `Person` vide). Comparaison par personnage : `Dress` 0 sur cette partie (situationnel) ; variables `Person` vides
3,3/perso en 4.27 contre 15 à 20 en 5.5 (ERR-003/ERR-030). Journal : `Saved/Logs/portage/L6a_LifePlay.log`.

### Lot L6e — ERR-034, marges des boutons (2026-09-30)

Captures utilisateur 4.27 / 5.5 : la rangée `<< < ❚❚ > >>` de `UI/TopRight` est plus espacée en 5.5 et déborde à droite.
Photographie de l'arbre (`LPDumpWidgetTree`) : chaque bouton est un `UButton` (style transparent) autour d'un cercle de 30 px ;
aucune marge n'est stockée dans l'asset. Source moteur : défaut 4.27 `FCoreStyle "Button"` NormalPadding (2,2,2,2),
PressedPadding (2,3,2,1) ; défaut 5.5 `FUMGCoreStyle "Button"` (12,1.5,12,1.5) pour les deux. `FMargin` est sérialisé
champ par champ par rapport au défaut : les assets 4.27 prennent donc la marge UE5 au chargement (+20 px par bouton).

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-032 | 2026-09-30 | L6e | `Source/LifePlayEditorTools/LPDumpWidgetTreeCommandlet.h/.cpp`, `LPFixButtonPaddingCommandlet.h/.cpp` (nouveaux) | outils : photographie des arbres UMG (`-BP=<nom>` ou `*`), correctif des marges | `git checkout L6e-avant -- Source` |
| CHG-033 | 2026-09-30 | L6e-CX-B09 | 46 Widget Blueprints de `Content/UI` (liste : `etat/L6e-CX-B09_assets.txt`) | 429 boutons (passe 1, marges égales au défaut UE5) + 1 bouton (passe 2, `TopRight::Button_8` Pressed (12,2,12,2) : marge 4.27 partielle, Left/Right hérités d'UE5) remis au défaut UE4 ; 3 boutons à marge 0 choisie par l'auteur conservés | `Tools\Restore.ps1 -Lot L6e-CX-B09` |

| Contrôle | Résultat | Preuve |
|---|---|---|
| Simulation | 432 boutons vus, 429 à corriger, 46 paquets | `etat/L6e-CX-B09_dryrun.txt` |
| Diff des 73 arbres UMG avant/après | hors lignes `WidgetStyle` : identiques ; dans `WidgetStyle`, seules `NormalPadding`/`PressedPadding` changent | `etat/L6e-CX-B09_widgets_{avant,apres,diff}.txt` |
| Idempotence | 3e simulation après passe 2 : 432 boutons vus, 0 à corriger | `etat/L6e-CX-B09c_LPFixButtonPadding_*.txt` |
| `CompileAllBlueprints` | 0 erreur, 190 avertissements (identique à L4-CX-B08) | `etat/L6e-CX-B09_CompileAllBlueprints_*.txt` |
| Build empaquetée `LifePlay_Build_5.5_L6e` | cuisson 0 erreur, 95 avertissements (inchangé) ; T-PKG-01 : 8561 `.uasset` | `Saved/Logs/portage/L6e_BuildCookRun.log` |

### Lot L6f — ERR-031, portrait vide lors d'un appel (2026-09-30) : diagnostic, sans correctif

Capture utilisateur 5.5 : l'encadré d'appel montre un dégradé de ciel. Chaîne établie : `GI::secondScreen` (contact lu dans
la variable DSL, `Person.secondScreen = true`, `Scene.FaceRender` visible) → `Render/SecondScreenMat` ← `SceneCapture2D`
`SecondScreen` de `CentralLondon` (rend seulement `Wall` et `PlayerCharacter`). La carte 4.27 d'origine (copie MD5 identique,
chargée temporairement sous `/Game/_Diag`, déplacée ensuite dans `D:\Game\LifePlay_Backup_5.5\L6f\_diag`) contient les
mêmes données : caméra sans racine, en position nulle. **L'utilisateur confirme le même défaut en 4.27** : ERR-031 est
préexistant, hors périmètre de la migration ; aucun asset modifié.

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-034 | 2026-09-30 | L6f | `Source/LifePlayEditorTools/LPDumpComponentsCommandlet.h/.cpp` (nouveau) | outil de diagnostic : composants d'un Blueprint (`-BP=`) ou acteurs d'une carte (`-Map= -Filter=`), propriétés différentes du défaut | `git checkout L6f-avant -- Source` |

Note d'outillage : `L6f_dump_GI.txt` a d'abord été écrasé par le vidage de `Person` (le script prenait le journal le plus
récent) ; il a été régénéré depuis `Saved/Logs/portage/L6f_LPDumpFunction_20260930-102202.log` (378 graphes).

Validation L6e (build `LifePlay_Build_5.5_L6e`, partie utilisateur 2026-09-30) : **barre de temps conforme à la 4.27**
(ERR-034 clos, CX-B09 validé en jeu).

ERR-033 (double clic) : **non reproduit** depuis le build L6e (constat utilisateur, 2026-09-30). Aucun correctif ciblé ;
laissé sous surveillance.

### Lot L4-CX-B07 — réenregistrement UE5 des derniers paquets UE4 (2026-09-30)

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-035 | 2026-09-30 | L4-CX-B07 | `Source/LifePlayEditorTools/LPAssetListUtils`, `LPDumpAssetsCommandlet`, `LPResavePackagesCommandlet` (nouveaux) ; `LifePlayEditorTools.Build.cs` (`bUseUnity = false` : les fonctions utilitaires de chaque commandlet sont dans un espace de noms anonyme, la compilation unity les faisait entrer en collision) ; 239 paquets (liste : `etat/L4-CX-B07_assets.txt`) | EX-03 : derniers paquets au format UE4 (ERR-022) | `Tools\Restore.ps1 -Lot L4-CX-B07` ; `git checkout L4-CX-B07-avant -- Source` |

| Contrôle | Résultat | Preuve |
|---|---|---|
| Photographie `LPDumpAssets` (292 paquets : les 239 + `BPs`, `UI`, `Structs`, `Render`, y compris GI et Person) | 1,28 million de lignes, 0 échec de chargement | `Saved/Logs/portage/L4-CX-B07_assets_{avant,avant2,apres}.txt` |
| Déterminisme | 2 photographies sans modification : seuls `NodeGuid`/`GraphGuid` diffèrent (régénérés au chargement des nœuds UE4) ; exclus du diff → 0 écart | idem |
| Simulation puis application | 239/239 sauvegardés, 0 échec | `etat/L4-CX-B07_dryrun.txt`, `etat/L4-CX-B07_application.txt` |
| T-STAT-01 (en-têtes) | **8563/8563 paquets UE5** | `etat/L4-CX-B07_headers_apres.csv` |
| Diff avant/après (409 lignes) | toutes neutres, voir ci-dessous | `etat/L4-CX-B07_diff_filtre.txt` |

Familles d'écarts du diff : (1) textures : stockage de la source PNG → `UEDELTA` (mêmes dimensions, format et mips ; données
éditeur, la cuisson en dérive) ; (2) 31 structures : `DefaultValue`/`CurrentDefaultValue` explicités avec les valeurs zéro
du type (identiques au défaut implicite) ; (3) 5 matériaux : copie UE4 dépréciée d'`EmissiveColor`/`Opacity` retirée de
`UMaterial`, les entrées restent identiques dans `MaterialEditorOnlyData` ; (4) 8 broches `Transform` : `-0` → `0` ;
(5) 5 signatures de délégué héritées (`SignatureClass/Name`) effacées sur des nœuds d'entrée ; (6) 2 avertissements de
dépréciation enregistrés sur des nœuds (`AI` R-04, `CharGenSlider` R-03, dette connue) ; (7) `PC` : broche
`TransformScaleMethod` du `SpawnActor` de `TestBall` (acteur de test) `SelectDefaultAtRuntime` → `MultiplyWithRoot`,
valeur déjà portée par les nœuds UE5 de `GI` ; (8) objets `PLACEHOLDER-CLASS` du chargeur (ordre de chargement).
| `CompileAllBlueprints` | 0 erreur, 190 avertissements (identique à L6e) | `etat/L4-CX-B07_CompileAllBlueprints_*.txt` |
| Build empaquetée `LifePlay_Build_5.5_V1rc` | cuisson 0 erreur, 95 avertissements (inchangé) ; T-PKG-01 : 8561 `.uasset` | `Saved/Logs/portage/L4-CX-B07_BuildCookRun.log` |

---

## V1 — validation finale (2026-09-30), étiquette `v1.0`

Partie utilisateur sur `LifePlay_Build_5.5_V1rc` (contenu = `L4-CX-B07-apres`) : environ 2 h, 339 personnages, sauvegardes
`1.sav` et `2.sav`, sortie normale, aucun dossier `Crashes` ; retour utilisateur : « pas de souci majeur constaté ».
Journaux : `Saved/Logs/portage/V1rc_partie_20260930*.log`.

| Exigence | Résultat |
|---|---|
| EX-01 compilation | `LifePlayEditor` compile sans erreur (L2, recompilé à chaque lot) |
| EX-02 Blueprints | `CompileAllBlueprints` 0 erreur (190 avertissements de dépréciation, dette R-03/R-04) |
| EX-03 format UE5 | 8563/8563 paquets (CX-B07) |
| EX-04 `Modules` | chargés comme en 4.27 (L3, T-STAT-02) |
| EX-05 build jouée | personnages distincts, visibles et habillés, scènes, sauvegarde et rechargement |
| EX-06 sans plantage | 42 min (L5d), environ 2 h (V1rc) : 0 plantage |
| EX-07 journalisation | `LogLifePlay`, résumé de démarrage et de session, traces de portage en `Verbose` |
| EX-08 traçabilité | CHG-001 à CHG-035, tags avant/après par lot, `Restore.ps1` testé (L0) |
| EX-09 environnement | `.claude/`, `.mcp.json`, `Saved/Backups/`, arbre 4.27 non modifiés |

Comparaison par personnage V1 (L5d) → V1rc des `Accessed None … Person` par fonction : `getActorVar` 4,6 → 4,0,
`ReturnStatIfNeeded` 3,6 → 3,8, `setActorVar` 0,8 → 0,8 ; seul `GI::Dress` varie (74,5 → 283,6), par rafales liées aux
lieux (ERR-030, lot L7i). Anomalies ouvertes après V1 : voir `Registre_Erreurs.md` et lots L7 de `04_Cahier_Des_Charges.md`.

## Publication GitHub (2026-09-30)

Dépôt : https://github.com/edujiro5972/LifePlay-Revival (fork de `vinfamy/LifePlay`, AGPL-3.0), compte `edujiro5972`.
Préparation dans `D:\Game\LifePlay_Publication` (copies ; ni ce dépôt ni l'arbre 4.27 modifiés).

| Branche | Commit | Contenu |
|---|---|---|
| `archive/original` | 42dc72b | `master` d'origine (V3.6) |
| `archive/ue4.27` | 9e61ec5 | arbre 4.27 filtré selon le `.gitignore` d'origine (sans `Content/Heavy`, `Content/Saves`, binaires, `*.png`, `*.7z`, `*.mp4`), 2 773 fichiers |
| `ue5.5-v1` = `main` (branche par défaut) | a55a43f | V1 ; 34 commits et 40 tags, dont `v1.0` |

Historique V1 réécrit pour la publication (`git filter-branch`, script `D:\Game\LifePlay_Publication\scrub.sh`) :
auteur, committer et signataire de `v1.0` = `edujiro5972 <336072401+edujiro5972@users.noreply.github.com>` ; valeurs
`SecurityToken` remplacées par `<retire-pour-publication>` (`Config/DefaultEngine.ini`, `correctifs/P05_Config.patch`) ;
`Plugins/McpAutomationBridge` retiré (outil de l'environnement de développement, MIT, hors jeu). Arbre final identique à
ce dépôt, hors ces deux retraits. Les identifiants de commit publiés diffèrent donc de ceux de ce dépôt local.

Rattachement du dépôt local à l'historique publié (2026-09-30) : `.git` sauvegardé dans
`D:\Game\LifePlay_Backup_5.5\git_avant_rattachement` (HEAD 41d5e1e, 40 tags) ; `git reset --mixed origin/main`
(ni fichier modifié ni fichier supprimé sur disque) ; tags remplacés par ceux publiés ; identité locale
`edujiro5972` (adresse noreply). `Plugins/McpAutomationBridge/` ajouté au `.gitignore` (reste sur disque) ;
`README.md` ajouté à la racine. Retour arrière : restaurer le `.git` sauvegardé.

## Archive « Full Source Code » V1 (2026-09-30)

`LifePlay_Revival_V1_UE5.5_Full_Source_Code.7z` (4 851 560 856 octets, SHA-256
`38ee16640f960317348a044195a23b55ac8eda34aec085e661034dc9c26cc594`), déposée par l'utilisateur sur Mega :
<https://mega.nz/file/zloFkL7T#3P5GDfcfF5U352T0s472vCtyNh131RLgNWn__PSNL2I>. Principe de l'archive de l'auteur
(`LifePlay_5_9_UE4_Full_Source_Code.7z`) : dossier projet à la racine, 7z `LZMA2:24 BCJ` solide. Contenu : `Content` complet
(24 912 fichiers, dont `Heavy` 8 350, au format UE5), `Binaries`, plugins `StreetMap` et `ModdingExtra`, `.git` d'un clone
propre du dépôt publié. Exclus : `Saved` (comme l'auteur), `Intermediate`, `McpAutomationBridge`, `.mcp.json`, `.claude`,
captures d'écran, `.git` local. Test d'intégrité 7-Zip réussi. Script : `D:\Game\LifePlay_Publication\make_archive.cmd`.
`README.md` réécrit en anglais avec le lien de l'archive.

---

## Lot L7a — R-03 refait : nœuds `Get SkeletalMesh` dépréciés (2026-09-30)

Analyse (source UE 5.5) : la lecture de `USkinnedMeshComponent::SkeletalMesh` passe par `GetSkeletalMesh_DEPRECATED()`,
qui renvoie `Cast<USkeletalMesh>(GetSkinnedAsset())`. CX-B05 avait pris `USkeletalMeshComponent::GetSkeletalMeshAsset()`,
qui n'existe pas sur les proxies (`USkinnedMeshComponent`) : d'où ERR-002 aggravé. Remplacement exact retenu :
`ULPMeshCompat::GetSkeletalMesh(Component)`, même calcul, pour tout `USkinnedMeshComponent`. Inventaire structurel
(instantané CX-B07) : 56 nœuds sources (les appels `GetSkeletalMesh_DEPRECATED` relevés ne sont que les copies compilées ;
la variable `SkeletalMesh` de `GenitalSlider` est une variable Blueprint, non concernée).

| ID | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-036 | 2026-09-30 | L7a (CX-B10) | `Source/LifePlay/LPMeshCompat.h/.cpp`, `Source/LifePlayEditorTools/LPFixSkeletalMeshGetCommandlet.h/.cpp` (nouveaux), `Tools/DiffRemplacementNoeuds.py` ; 8 Blueprints (`etat/L7a_assets.txt`) | ERR-012 / R-03 : 56 nœuds dépréciés | `Tools\Restore.ps1 -Lot L7a` ; `git checkout L7a-avant -- Source Tools` |

| Contrôle | Résultat | Preuve |
|---|---|---|
| Simulation | 56 nœuds, 0 cas non pris en charge (cible `self`, nœud impur) | `etat/L7a_dryrun.txt` |
| Application (contrôle intégré des liaisons) | 56/56 remplacés, 8 Blueprints sauvegardés, 0 écart | `etat/L7a_application.txt` |
| Diff indépendant `LPDumpAssets` avant/après (`Tools/DiffRemplacementNoeuds.py`) | 56 paires (même graphe, même position) ; liaisons `self`→`Component` et `SkeletalMesh`→`ReturnValue` identiques pour 56/56 ; **0 autre objet modifié** (hors copies compilées, graphes anonymes régénérés, GUID, positions des graphes-souches, messages de compilation) | `Saved/Logs/portage/L7a_assets_{avant,apres}.txt` |
| Chargement des 8 Blueprints | avertissements 112 → 6 | journaux `L7a_LPDumpAssets_*` |

Effet de mesure : le nœud d'origine émettait `Accessed None … SkeletalMesh` sur un composant None ; la nouvelle fonction
renvoie None sans message (trace `LogLifePlay` en `Verbose`). Les compteurs `AccessedNoneMaillage` de `LogStats.ps1`
baissent donc mécaniquement : comparer les sessions sur les autres signatures.
| `CompileAllBlueprints` | 0 erreur, **6 avertissements** (190 avant) : restent seulement les 6 nœuds R-04 `GetRandomPointInNavigableRadius` (`AI`, `Person`, `Room`) | `etat/L7a_CompileAllBlueprints_*.txt` |
| Build empaquetée `LifePlay_Build_5.5_L7a` | cuisson 0 erreur, **3 avertissements** (95 avant) ; T-PKG-01 : 8561 `.uasset` | `Saved/Logs/portage/L7a_BuildCookRun.log` |

### Nettoyage des builds UE5 obsolètes (2026-09-30, demande utilisateur)

Supprimés (environ 37 Go, binaires régénérables depuis les tags git) : `LifePlay_Build_5.5`, `_5.5_Dev`, `_5.5_NoR03`
(premier portage) et `_5.5_L4`, `L4b`, `L5a`, `L5b`, `L5c`, `L5d`, `L6a`, `L6e`. Au préalable, leurs `Saved/Logs`,
`Saved/SaveGames`, `Saved/Crashes` et scripts `.bat` ont été copiés dans `D:\Game\LifePlay_Backup_5.5\builds_supprimees`.
Conservés : `LifePlay_Build_5.5_V1rc` (build validée `v1.0`), `LifePlay_Build_5.5_L7a` (test en cours),
`LifePlay_Build_427_Dev` et `LifePlay_Build_2026.9` (UE4).

Validation L7a (build `LifePlay_Build_5.5_L7a`, partie utilisateur 2026-09-30, environ 1 h) : 294 personnages, 0 plantage,
sortie normale, sauvegardes `1.sav`/`2.sav` ; tests utilisateur effectués sans anomalie signalée. Journal :
`Saved/Logs/portage/L7a_partie_20260930.log`. `Accessed None` par personnage : 334 (V1rc) → 127, surtout `GI::Dress`
(situationnel, ERR-030). Messages moteur `GetSocketInfoByName … No SkeletalMesh for Component(CharacterMesh0)` : même
signature et mêmes 5 sockets qu'en V1rc, volume lié aux scènes jouées (ERR-011, existe en 4.27) : non imputable à L7a.
Fonctions de variables DSL (`getActorVar`, `clearVariable`, `CallFunction`) non touchées par L7a, en hausse par personnage
sur cette partie : famille ERR-003, à suivre en L7i.

### L7b — R-04 : derniers nœuds dépréciés (2026-09-30)

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-037 | 2026-09-30 | L7b (CX-B11) | `Source/LifePlayEditorTools/LPFixNavRandomPointCommandlet.h/.cpp` (nouveau) ; `Tools/DiffRemplacementNoeuds.py` (profils par lot : `L7a`, `L7b`) ; `Content/BPs/AI`, `Person`, `Room` (`etat/L7b_assets.txt`) | ERR-035 / R-04 : 6 nœuds `GetRandomPointInNavigableRadius` dépréciés | `Tools\Restore.ps1 -Lot L7b` ; `git checkout L7b-avant -- Source Tools` |

Choix : le remplaçant proposé par le moteur (`K2_GetRandomLocationInNavigableRadius`) est `BlueprintCallable`, alors que
l'ancien nœud est pur ; le brancher imposerait de recâbler le flux d'exécution. On réutilise `LPNavigationHelpers`
(enrobage pur déjà présent, CX-C09) : mêmes broches, et même corps que la fonction dépréciée en 4.27 comme en 5.5
(simple appel de `K2_GetRandomLocationInNavigableRadius`). `LPFixDeprecatedNodes` (CX-B06) n'est pas réutilisée : elle
ne contrôle rien et embarque aussi la variante R-03 rejetée.

| Contrôle | Résultat | Preuve |
|---|---|---|
| Simulation | 6 nœuds (`Room::moveToBedIfPossible`, `Room::getStandSpots`, `Person::standIdle` ×2, `Person::jumpOffFnt`, `AI::EventGraph`), 0 cas non pris en charge | `etat/L7b_LPFixNavRandomPoint_20260930-183406.txt` |
| Application (contrôle intégré : liaisons et valeurs par défaut de chaque broche) | 6/6 remplacés, 3 Blueprints sauvegardés, 0 écart | `etat/L7b_LPFixNavRandomPoint_20260930-183707.txt` |
| Diff indépendant `LPDumpAssets` (`DiffRemplacementNoeuds.py … L7b`) | 6 paires ; 7 broches identiques (liaisons et défauts, ex. `Radius` 100 / 200 / 1000 / 2000 / 100000) ; **0 autre objet modifié** ; le profil `L7a` rejoué sur les données L7a donne toujours 56/56 et 0 écart | `Saved/Logs/portage/L7b_assets_{avant,apres}.txt` |
| `CompileAllBlueprints` | 0 erreur, **0 avertissement** (6 avant) | `etat/L7b_CompileAllBlueprints_20260930-183909.txt` |
| Build empaquetée `LifePlay_Build_5.5_L7b` | cuisson 0 erreur, **0 avertissement** (3 avant) ; T-PKG-01 : 8561 `.uasset` | `Saved/Logs/portage/L7b_BuildCookRun.log` |

Validation en jeu en attente (déplacements des personnages : `standIdle`, `jumpOffFnt`, `moveToBedIfPossible`, IA).

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-038 | 2026-09-30 | L7b | `Content/BPs/AI`, `Person`, `Room` restaurés (`Tools\Restore.ps1 -Lot L7b`, MD5 = `L7b-avant`) ; versions L7b conservées dans `LifePlay_Backup_5.5\L7b\_avant-restauration‚60930-193820` | test en jeu du build L7b (utilisateur) : les personnages se téléportent dans la pièce au lieu de marcher, pieds parfois masqués par un objet ; « la build précédente était meilleure » | réappliquer : `Restore.ps1` depuis `_avant-restauration`, ou relancer `LPFixNavRandomPoint` |

Analyse : aucune cause trouvée dans le code. Ancienne et nouvelle fonction exécutent le même appel moteur
(`K2_GetRandomLocationInNavigableRadius`), mêmes broches et valeurs par défaut (diff 6/6), et le compilateur remplit la
broche cachée `WorldContextObject` de la même façon pour les deux (`FKCHandler_CallFunction::RegisterNets`, métadonnée
`WorldContext`). Le journal de la partie ne contient aucun message de navigation. Prochaine étape : A/B au même endroit
avec le build L7a (identique au contenu actuel), et vérifier le comportement en 4.27, avant toute nouvelle tentative.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-039 | 2026-09-30 | L7b | `Content/BPs/AI`, `Person`, `Room` remis à `L7b-apres` (`git checkout L7b-apres`, MD5 identiques aux versions conservées dans `_avant-restauration‚60930-193820`) | retour utilisateur : la téléportation venait de l'accélération du temps (en vitesse normale les personnages marchent) ; les personnages enfoncés dans le sol en extérieur existent aussi en 4.27 et en L7a/V1 (ERR-036, hors périmètre). Le retrait CHG-038 n'était donc pas justifié | `Tools\Restore.ps1 -Lot L7b` |

L7b validé en jeu : le build testé `LifePlay_Build_5.5_L7b` contient exactement ces 3 paquets. Leçon : avant de retirer
un lot sur un symptôme visuel, vérifier la vitesse de jeu et demander si le défaut existe en 4.27 et dans le build précédent.

### L7i — variables DSL `Person` vides (ERR-003 / ERR-030), 2026-09-30

Mesure (journaux `L7a_partie`, `L7b_partie`, 4.27 `LifePlay_Build_427_Dev\...\LifePlay.log`, par minute) :

| Signature | 4.27 (23 min) | L7a (62 min) | L7b (45 min) |
|---|---|---|---|
| `Accessed None … Person` dans `GI::Dress` | 376 | 326 | 641 |
| `index 0 … array 'Person'` (variable DSL vide) | 9 | 179 | 56 |
| `index … array 'Floats'` | 2,4 | 31 | 64 |
| `Accessed None … Person` dans `getActorVar` | 0 | 45 | 7,6 |
| `Accessed None … Person` dans `ReturnStatIfNeeded` | 0,35 | 33 | 5,6 |

Conclusion : **ERR-030 (`Dress`) existe en 4.27** (même signature `Dress:0E35`, même ordre de grandeur) : préexistant,
hors périmètre. L'écart propre à 5.5 porte sur les variables DSL vides (ERR-003). Lecture du graphe
(`GI::GetVariable`) : la variable `Player` est construite avec `Person = [Special]`, `Special = GI.PlayerCharacter`
(`SwitchString_55`, branche `Player`) ; le capteur L6a montre `Special = None`. Les erreurs surviennent tout au long de
la partie, pas seulement au chargement.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-040 | 2026-09-30 | L7i | `Source/LifePlay/LPSessionLogSubsystem.h/.cpp` : options `-LPTraceFunctions`, `-LPTraceDepth` (variables locales des cadres appelants), `-LPTraceGIVars` (variables de l'instance de jeu) ; inactives sans `-LPTraceScriptEx` | capteur ciblé ERR-003 : quelle scène et quelle variable restent vides | `git checkout L7i-avant -- Source` |

Build de diagnostic `LifePlay_Build_5.5_L7i` (contenu identique à L7b, 8561 `.uasset`), lancement par
`LifePlay_diagnostic_L7i.bat` (300 relevés, 4 cadres appelants, `-ScriptStackOnWarnings`).

Session capteur n° 1 (`L7i_partie2_20261001.log`, 53 min, 300 relevés) : les variables vides viennent surtout des
scripts d'IA des PNJ (`.lpai` : `meal`, `church`, `grocery`, `entertainment`…), via `UpdateAI → PlayScene →
ReadSceneLine → CallFunction → getActorVar/setActorVar`. La variable vide est **`AI`**, alimentée par `GI.AIDummy`
(personnage factice du pool `DummyPersons`, attribué par `SpawnDummy`). `GI.PlayerCharacter` n'est pas None. Dans
`GetVariable`, toutes les variables spéciales (`Player`, `Ptr`, `Interacting`, `CurrentCompanion`, `A1`…`A5`)
passent par le même `MakeStruct` dont le nom est figé à « Player » : l'étiquette relevée en L6a était trompeuse.

Nouveau défaut signalé (utilisateur, 2026-10-01) : **Quick dress laisse souvent le personnage principal nu ; correct
en 4.27** → ERR-037, régression UE5. Chemin : `Action` (bouton « Quick dress ») → `GI::Dress(PersonVariable="Player",
ClothVariables=[], QuickDress=true)` → pour chaque emplacement obligatoire (`Top`, `Bottom`, `Foot`), filtre de
l'inventaire du joueur (sexe, emplacement, `Overlaps`, `Daz == (Race == "Daz")`, exclusion `Wedding/Nurse/Doctor`).
Inventaire de la sauvegarde `1.sav` cohérent (80 vêtements, `Daz=True`).

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-041 | 2026-10-01 | L7i | `Source/LifePlayEditorTools/LPDumpSaveCommandlet.h/.cpp` (nouveau : contenu d'un `.sav` en texte, lecture seule) ; `Source/LifePlay/LPSessionLogSubsystem.h/.cpp` : relevé déclenché par un motif du journal (`-LPDumpOnLog`, `-LPDumpPaths`, `-LPDumpMax`), inactif sans l'option | ERR-037 : relever l'état du joueur au moment du Quick dress ; ERR-003 : état d'`AIDummy` | `git checkout L7i-capteur -- Source` |

Build `LifePlay_Build_5.5_L7i` reconstruite (contenu identique), lancement `LifePlay_diagnostic_L7i_2.bat`.

Session capteur n° 2 (`L7i_partie3_20261001.log`, 5 min, 8 relevés Quick dress, 60 relevés IA) :

- **Quick dress (ERR-037)** : à la maison, 4 essais sur 4 corrects (haut, bas, chaussures, accessoires). Au travail,
  3 essais sur 3 ne mettent que `Trench-Coat-Outfit-Top`. État relevé : `Race = "Daz"`, `IsMale = False`,
  inventaire de 80 vêtements. Au travail (`CurrentAmenity = work`), `GI::Dress` n'accepte que les vêtements
  `Bool3` (étiquette « Formal ») ; l'inventaire n'en contient que 2 (`HC-Business-Jacket` en `Outerwear`,
  `Trench-Coat-Outfit-Top` en `Top`), aucun bas ni chaussure formels. Quand aucun vêtement ne convient à un
  emplacement, la sortie `Completed` de la boucle n'est pas câblée : l'emplacement reste vide. Graphe identique à
  4.27 → comportement d'origine, à confirmer par un essai 4.27 au travail.
- **Variable `AI` vide** : `GI.AIDummy` est valide au moment de l'erreur ; les erreurs portent toujours sur les
  emplacements de PNJ `CheckingAiIndex` 5 et 8. `UpdateAI` charge le PNJ dans `AIDummy` (`LoadPreset`,
  `StatOnly`) puis `AddVariable("AI", [AIDummy])` ; à l'erreur, `GetVariable("AI")` renvoie une variable vide
  (non trouvée). Piste suivante : ce qui retire ou masque `AI` pour ces deux PNJ.

Suite L7i (2026-10-01) :

- ERR-037 (Quick dress) **préexistant** : même comportement en 4.27 au travail (essai utilisateur). Journal 4.27 de
  l'essai archivé : `Saved/Logs/portage/ref427_quickdress_20261001.log` ; la session 4.27 de référence (23 min) est
  archivée sous `ref427_partie_20260930.log` (le `LifePlay.log` 4.27 avait été remplacé par l'essai).
- Variable `AI` introuvable : au moment de l'erreur, la boucle de vérification des scènes du joueur (`CHECKING:`)
  s'exécute entre les lignes du script d'IA ; les deux boucles avancent par `Delay(0)` (macro `GI:Async`) et
  partagent la table des variables DSL. Moteur : `FDelayAction`, `UKismetSystemLibrary::Delay` et
  `FLatentActionManager::ProcessLatentActions` équivalents 4.27/5.5 ; images par seconde équivalentes (≈ 55).
  Écart mesuré : par cycle de vérification, ≈ 140 scènes en 4.27 contre ≈ 430 en 5.5 dont 100 vérifiées 2 à 3 fois
  (redémarrages : `CheckingSceneIndex` remis à -1 et liste remélangée à chaque changement de `CurrentAmenity`).
  Les sessions comparées n'ont pas suivi le même parcours (déplacements, accélération du temps) : une comparaison
  A/B sur un parcours identique est nécessaire avant de conclure à une régression.

A/B à parcours identique (2026-10-01, nouvelle partie, vitesse normale, maison puis travail ; 4.27 47 min,
`AB427_20261001.log` ; 5.5 33 min, `AB55_20261001.log`) :

| Par minute | 4.27 | 5.5 |
|---|---|---|
| Vérifications de scènes | 626 | 614 |
| `AI` introuvable (`getActorVar`…) | 0 | 0 |
| Variables `Person` vides | 124 | 123 |
| `getBeautyValue` (`Floats` vide) | 1,3 | 52 |

Les erreurs `AI` dépendaient du rythme de jeu (accélération du temps) : absentes à parcours égal, classées comme
préexistantes (même mécanisme en 4.27). Seul écart réel : `getBeautyValue`.

Cause (ERR-005) : `BeautyStandards` est indexé par forme (`round`, `oval`…, fichier
`Modules/beauty_standards_default.txt` identique dans les deux versions) ; la première recherche par nom de morph
échoue normalement (62 avertissements en 4.27 aussi). L'écart vient du nombre d'appels : `filterMorphList` est
appelé sans étiquette et teste `Contains(tags, "")`. Moteur : `FString::Find` 4.27 → `FCString::Stristr`, qui
cherche le caractère nul et ne trouve rien ; 5.5 → `TCString::Strnistr`, qui renvoie le début de la chaîne. Les
autres modes (sensible à la casse, depuis la fin) et `StartsWith`, `EndsWith`, `Replace` sont identiques.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-042 | 2026-10-01 | L7i (CX-B12) | `Source/LifePlay/LPStringCompat.h/.cpp` (`FindUE4`, `Contains`, `FindSubstring`, `Split`) ; `Source/LifePlayEditorTools/LPFixStringSearchCommandlet`, `LPTestStringCompatCommandlet`, `LPDumpCDOCommandlet` (nouveaux) ; `Tools/DiffRemplacementNoeuds.py` (profil `CX-B12`, broches absentes des deux côtés) ; 28 Blueprints (`etat/L7i_CX-B12_assets.txt`) | ERR-005 : recherche de texte avec motif vide | `Tools\Restore.ps1 -Lot L7i-CX-B12` ; `git checkout L7i-CX-B12-avant -- Source Tools` |

| Contrôle | Résultat | Preuve |
|---|---|---|
| Test `LPTestStringCompat` : transcription littérale de `FString::Find` 4.27 contre `LPStringCompat` et contre le moteur 5.5 | 3 120 cas : compat = 4.27 dans 100 % des cas ; moteur 5.5 ≠ 4.27 dans 60 cas, tous « sous-chaîne vide, insensible à la casse, depuis le début » | `Saved/Logs/portage/L7i_LPTestStringCompat_*.log` |
| Simulation | 385 nœuds (`Contains` 160, `Split` 222, `FindSubstring` 3), 28 Blueprints, 0 cas non pris en charge | `etat/L7i_LPFixStringSearch_20261001-191027.txt` |
| Application (contrôle intégré) | 385/385 remplacés, 28 Blueprints sauvegardés, 0 écart | `etat/L7i_LPFixStringSearch_20261001-191311.txt` |
| Diff indépendant (`DiffRemplacementNoeuds.py … CX-B12`) | 385 paires, liaisons et valeurs par défaut identiques ; 0 autre objet modifié ; profils L7a (56/56) et L7b (6/6) inchangés | `Saved/Logs/portage/L7i_CX-B12_assets_{avant,apres}.txt` |
| `CompileAllBlueprints` | 0 erreur, 0 avertissement | `etat/L7i_CompileAllBlueprints_20261001-191653.txt` |
| Build empaquetée `LifePlay_Build_5.5_L7i_B12` | cuisson 0 erreur, 0 avertissement (164 paquets recuits) ; T-PKG-01 : 8561 `.uasset` | `Saved/Logs/portage/L7i_CX-B12_BuildCookRun.log` |

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-043 | 2026-10-01 | L7i (CX-B12) | — (validation) | partie utilisateur de 46 min sur `LifePlay_Build_5.5_L7i_B12`, même parcours que l'A/B : « pas de soucis en vue » | — |

| Par personnage (`LogStats.ps1`) | 4.27 (`AB427`) | 5.5 avant (`AB55`) | 5.5 + CX-B12 (`B12_validation_20261001.log`) |
|---|---|---|---|
| Personnages | 788 | 562 | 1 044 |
| `Accessed None` | 16,5 | 17,8 | 18,3 |
| Index hors bornes | 8,7 | 12,4 | 9,7 |
| Erreurs (session) | 6 | 30 | 7 |
| `getBeautyValue` (par minute) | 1,3 | 52 | 2,3 |
| Plantage | 0 | 0 | 0 |

**Lot L7i clos.** Leçon : comparer 4.27 et 5.5 sur un parcours identique (nouvelle partie, vitesse normale) ;
les sessions libres (accélération du temps, lieux différents) faussent les taux et ont conduit à deux fausses pistes
(variable `AI`, Quick dress).

### L7h — vérification StreetMap (ERR-018), 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-044 | 2026-10-01 | L7h | `Source/LifePlayEditorTools/LPCheckStreetMapCommandlet` (option `-Path`), `LPCheckMeshesCommandlet` (nouveau), `LifePlayEditorTools.Build.cs` (module `MeshDescription`) | ERR-018 : tailles de fichiers StreetMap divisées par 3 à 15 | `git checkout L7h-avant -- Source` |

Méthode : copie temporaire de `Heavy/StreetMap` 4.27 (560 fichiers, 276 Mo, lecture seule de la source) sous
`Content/_Temp427`, mesurée par l'éditeur 5.5 avec les mêmes commandlets que les assets 5.5, puis supprimée.

| Contrôle | 4.27 | 5.5 | Preuve |
|---|---|---|---|
| 280 villes `UStreetMap` : routes, nœuds, bâtiments, eaux, parcs, bâtiments nommés, aménités | — | **0 ligne différente** (ex. `CentralLondon` : 18 460 routes, 49 425 bâtiments, 5 191 aménités) | `etat/L7h_streetmap_{427,55}.csv` |
| 280 maillages `Static` : LOD, sommets et triangles sources et de rendu, sections, matériaux, dimensions | — | **0 ligne différente** (ex. `CentralLondon` : 1 084 265 triangles) | `etat/L7h_meshes_{427,55}.csv` |

Conclusion : aucune perte de données. La réduction de taille vient du format UE5, qui ne stocke plus les données de
rendu construites dans le fichier de l'éditeur (reconstruites depuis les données sources et mises en cache). Le
niveau `Scenes/CentralLondon.umap` (1,0 → 0,4 Mo) est joué dans toutes les sessions de validation sans défaut de
carte signalé.

### L7k — erreurs d'exécution fréquentes, 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-045 | 2026-10-01 | L7k | — (analyse des journaux `AB427`, `AB55`, `B12_validation`) | ERR-006, ERR-007 et signatures résiduelles | — |

| Par personnage | 4.27 | 5.5 avant CX-B12 | 5.5 + CX-B12 |
|---|---|---|---|
| `ContactMenu` dans `Person::UpdateDailyPose` (ERR-007) | 0,12 | 0,62 | 0,20 |
| `Near` dans `Person::standIdle` (ERR-006) | 0,05 | 0,38 | 0,09 |
| `currentMatchRace` dans `GI::determinePersonVars` | 0,04 | 0,33 | 0,09 |
| `OccupyingFnt`, `HeadtrackStatic` (`Person`) | 0,03 ; 0,04 | 0,22 ; 0,21 | 0,07 ; 0,07 |
| `clearVariable` (vérifications « qui » des scènes) | 7,2 | 6,7 | 15,3 |
| … rapporté aux vérifications de scènes | 0,37 | 0,36 | 0,39 |

ERR-006 et ERR-007 étaient des effets secondaires de la recherche de texte vide (ERR-005) : ils reviennent au niveau
4.27 sans autre correctif. `clearVariable` suit le volume de vérifications de scènes (même chaîne d'appel et mêmes
proportions `GetSpecific` / `getRelative` / `getPerson` dans les trois sessions) : la session de validation a
vérifié davantage de scènes par personnage (843/min contre 626). **Lot L7k clos sans modification.**

### L7g — build Shipping, 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-046 | 2026-10-01 | L7g | `Source/LifePlay/LPSessionLogSubsystem.cpp` : comparaison au nom `LogLifePlay` (`FName`) au lieu de `LogLifePlay.GetCategoryName()` | la configuration Shipping ne compilait pas : `NO_LOGGING` y remplace les catégories de journal par des objets vides (`FNoLoggingCategory`, sans `GetCategoryName`) | `git checkout L7g-avant -- Source` |

Choix de structure : la version publiée par l'auteur (`LifePlay_Build_2026.9`, UE4) est une build Shipping **en
fichiers séparés** (pas de `.pak`), conforme à `UsePakFile=False` du projet : conservé tel quel (modding). Commande :
`RunUAT BuildCookRun -platform=Win64 -clientconfig=Shipping -build -cook -iterate -stage -archive
-archivedirectory=D:\Game\LifePlay_Build_5.5_Shipping`. `McpAutomationBridge` est déjà exclu des builds de jeu
(`TargetAllowList: Editor` dans le `.uproject`).

| Contrôle | Auteur (UE4) | 5.5 Shipping | Preuve |
|---|---|---|---|
| Compilation `LifePlay Win64 Shipping` et `LifePlayEditor Win64 Development` | — | 0 erreur | `Build.bat` |
| Paquets `.uasset` | 8 561 | 8 561 | comptage |
| Fichiers `Content/Modules` (hors paquets) | 2 051 | 2 051 | comptage |
| Taille totale | 5,2 Go | 3,3 Go | format UE5 (voir L7h) |
| Cuisson | — | réussie, sans avertissement | `Saved/Logs/portage/L7g_BuildCookRun_Shipping.log` |

En Shipping, le jeu n'écrit pas de journal (comme la version de l'auteur) : la validation se fait par une partie.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-047 | 2026-10-01 | L7g | — (validation) | partie utilisateur sur `LifePlay_Build_5.5_Shipping` (nouvelle partie, scènes, sauvegarde et rechargement) : « pas de soucis constaté » | — |

**Lot L7g clos.** La build Shipping est la version distribuable de référence.

### Publication V1.1 (2026-10-01)

Tag annoté `v1.1` (`0d6dc55`, signataire edujiro5972), branche `ue5.5-v1.1`, README anglais mis à jour.
Archive `D:\Game\LifePlay_Publication\LifePlay_Revival_V1.1_UE5.5_Full_Source_Code.7z` (script
`make_archive_v1_1.cmd`, mêmes exclusions que V1) : 4,94 Go, 25 644 fichiers, 8,74 Go décompressés, test 7-Zip OK,
SHA-256 `6dbfb18e55e51558708239856b54f757b6044307d2d1cf261e88c94baaf617ae`. Les deux fichiers `Config` modifiés par
L7c pendant l'archivage ont été vérifiés dans l'archive : identiques à `v1.1`. Lien Mega à ajouter au README après dépôt.

### L7c — configuration, 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-049 | 2026-10-01 | L7c | `Config/DefaultEngine.ini` : `r.DynamicGlobalIlluminationMethod=0`, `r.ReflectionMethod=2`, `r.Shadow.Virtual.Enable=0`, `DefaultGraphicsRHI=DefaultGraphicsRHI_DX12` ; `Config/DefaultGame.ini` : 5 clés de nativisation retirées | rendre explicites les valeurs jouées et validées (valeurs par défaut du code moteur 5.5 : `IndirectLightRendering.cpp`, `VirtualShadowMapArray.cpp` ; RHI D3D12 relevé dans les journaux) ; nativisation supprimée depuis UE 5.0 (`UE_DEPRECATED(5.0)`) | `git checkout L7c-avant -- Config` |

`PhysXTreeRebuildRate` est conservé : propriété toujours valide de `UPhysicsSettings` en 5.5.

### L7d — visuel, 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-050 | 2026-10-01 | L7d | `Source/LifePlayEditorTools/LPConvertAtmosphericFogCommandlet` (nouveau) ; `Content/Scenes/CentralLondon.umap` | `AAtmosphericFog` déprécié depuis 4.26 : remplacé par un `ASkyAtmosphere` équivalent | `Tools\Restore.ps1 -Lot L7d` |

Constats : en 5.5, `UAtmosphericFogComponent` dérive de `USkyAtmosphereComponent` et se convertit au chargement
(`SetPositionToMatchDeprecatedAtmosphericFog` : planète posée à Z = −100 000, mode `PlanetTopAtComponentTransform`) ;
le rendu passait donc déjà par SkyAtmosphere. Éclairage précalculé : `CentralLondon_BuiltData` 40 Ko (4.27) /
43 Ko (5.5), aucun message de reconstruction : rien à reconstruire (la ville est éclairée dynamiquement).

| Contrôle | Résultat | Preuve |
|---|---|---|
| Simulation | 1 acteur, 26 propriétés SkyAtmosphere relevées (valeurs effectives) | `etat/L7d_LPConvertAtmosphericFog_20261001-215150.txt` |
| 1er essai | écart de transformation détecté (transformation monde non recalculée hors monde enregistré) : **carte non sauvegardée** ; corrigé (`UpdateComponentToWorld`) | `etat/L7d_LPConvertAtmosphericFog_20261001-215247.txt` |
| Application | 26/26 propriétés et transformations relative et monde identiques ; carte sauvegardée | `etat/L7d_LPConvertAtmosphericFog_20261001-215445.txt` |
| Diff `LPDumpAssets` de la carte | 387 objets avant et après ; seuls changements : `AtmosphericFog_1` (+3 composants) → `SkyAtmosphere_0` (+3 composants), même étiquette, `RelativeLocation` Z = −100 000 et `TransformMode` explicités (valeurs effectives de l'ancien composant) | `Saved/Logs/portage/L7d_map_{avant,apres}.txt` |

### L7e, L7f — évaluation, 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-051 | 2026-10-01 | L7e, L7f | — | évaluation | — |

- **L7e** : 4 systèmes Cascade (`Heavy/New3/Particles` : `ParticleBurst`, `ParticleGravity`, `ParticleLiquid`,
  `ParticleSquirt`), toujours pris en charge par UE 5.5 ; une conversion vers Niagara changerait l'aspect des effets
  par rapport à 4.27 : reportée au jour où le moteur retirera Cascade. Aucun actif ne contient de vêtement physique
  (`ClothingAssetCommon` absent en 4.27 comme en 5.5) : rien à migrer de NvCloth vers Chaos.
- **L7f** : `DefaultPlayerInputClass=EnhancedPlayerInput` et `DefaultInputComponentClass=EnhancedInputComponent`
  sont déjà actifs ; ils exécutent les 34 actions et axes hérités de `DefaultInput.ini`. Une migration complète
  (Input Actions, Mapping Contexts, réécriture des événements d'entrée des Blueprints) n'apporterait rien au joueur
  et demanderait un test manuel des 34 commandes : reportée.

### L7j — image du contact pendant un appel (ERR-031, amélioration), 2026-10-01

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-052 | 2026-10-01 | L7j | `Source/LifePlayEditorTools/LPFixSceneCaptureCommandlet` (nouveau) ; `Content/Scenes/CentralLondon.umap` | ERR-031 (présent en 4.27) : la caméra `SecondScreen` filme le ciel | `Tools\Restore.ps1 -Lot L7j` |

Chaîne (L6f et L7j) : `GI::secondScreen` marque le contact (`Person.secondScreen`) ; `GI::Show` le place sur la position
de son emplacement de scène (`ActorTransforms[i]`) **décalée de −10 000 000 en Y**, sur la copie de studio
`SecondScreenFloor` (−3 131 543 ; −24 967 212, soit le studio des scènes − 10 000 000 Y) ; l'encadré affiche
`Render/SecondScreen`, rendu par la caméra `SecondScreen`. Aucun Blueprint ne déplace cette caméra ; dans la carte
(4.27 comme 5.5) elle n'a pas de racine (`RootComponent = None`) et ses composants sont à l'origine.

Correctif : racine = son `SceneComponent` existant, capture rattachée, position = `CameraScene` (cadrage des scènes du
studio : −3 131 132 ; −14 967 241 ; 50, lacet 180°) − 10 000 000 Y. Contrôle intégré (racine, rattachement, position
monde = cible) puis diff `LPDumpAssets` de la carte : **3 lignes modifiées**, toutes sur `SecondScreen`
(`Saved/Logs/portage/L7d_map_apres.txt` → `L7j_map_apres.txt`). Le cadrage (scène entière plutôt que portrait) est à
ajuster d'après le test en jeu si nécessaire (`-From=CameraPortrait`).

### L7l — personnages enfoncés dans le sol en extérieur (ERR-036, amélioration), 2026-10-01 : diagnostic

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-053 | 2026-10-01 | L7l | `Source/LifePlayEditorTools/LPCheckMeshesCommandlet` (colonnes `MinZ`, `MaxZ`) | diagnostic | — |

Le lieu `Modules/vin_Base/World/forest___vin01.lpworld` (donnée de module, identique en 4.27) pose comme sol le meuble
`fnt_new208` (dalle 230 × 99 × 0,6) en Z = −31,2 avec une échelle (0,713 ; 1,481 ; **100**) ; ailleurs (`bathroom`,
`shower`, `sports_centre`) le même meuble est un petit objet (Z = 60, échelle 5). Les meubles sont rattachés à un point
d'ancrage en Z = 60 (`Room::addObject`). La hauteur exacte de la surface de neige par rapport au sol de marche dépend
de la chaîne de composants du meuble : une mesure en jeu est nécessaire avant de corriger le fichier (ou d'ajuster la
dalle avec l'éditeur de lieu intégré au jeu, « Edit building »).

Test utilisateur (build `LifePlay_Build_5.5_L7cdj`) : le contact apparaît désormais dans l'encadré d'appel (en pied,
avec le sol de `SecondScreenFloor`) ; demande : cadrer le visage.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-054 | 2026-10-01 | L7j | `Source/LifePlay/LPSecondScreenSubsystem.h/.cpp` (nouveau sous-système d'instance de jeu) | cadrer le visage du contact quel que soit son emplacement de scène : à chaque image, la caméra `SecondScreen` est placée à 80 cm devant la tête de `GI.SecondScreenPerson` (os `head`, sinon haut de la capsule), dans l'axe du personnage, champ 30° ; composant rendu mobile au premier usage. Aucun asset ni Blueprint modifié | `git checkout L7j2-avant -- Source` |

Compilation `LifePlayEditor` Development et `LifePlay` Shipping : 0 erreur. La position fixe posée par CHG-052 reste
la position de repli (avant tout appel).

Suite L7l (2026-10-01) : inspection en direct dans l'éditeur (serveur MCP, lecture seule) : la racine de l'acteur
`Room` porte l'échelle de la première ligne du `.lpworld` (studio : 8 ; 8 ; 0,2 ; forêt : 6 ; 16 ; **0,01**) ; positions
et échelles des meubles sont donc multipliées par 0,01 en hauteur : la dalle `fnt_new208` affleure le sol (≈ +0,3 cm
contre ≈ +0,5 cm). **La dalle n'est pas surélevée** : l'écart vient de la hauteur à laquelle les personnages sont
posés. Mesure en jeu préparée :

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-055 | 2026-10-01 | L7l | `Source/LifePlay/LPSessionLogSubsystem.cpp` : option `-LPDumpDelay` (délai du relevé sur motif) | relever, 4 s après chaque changement de lieu (`test0706 amenity`), le sol du lieu (`Room`), la capsule du joueur et du personnage en interaction ; script `LifePlay_releve_L7l.bat` du build `LifePlay_Build_5.5_L7cdj` | `git checkout L7j2-apres -- Source` |

Mesures L7l (2026-10-01, `L7l_releve2_20261001.log`) : **tous les lieux sont construits dans le studio**
(acteur unique `Room_C_0` en −3 131 543 ; −14 967 213 ; −115), la ville étant masquée (`StreetMapStatic.bHidden`). Au
centre sportif (échelle Z 0,2) : sol à −105, pieds du joueur à −100 (capsule −12, demi-hauteur 88) : correct.
Échelles verticales déclarées : 81 lieux à 0,2, 5 à 0,3, 1 à 0,4 et les **7 lieux extérieurs à 0,01** (beach, forest,
mountain, park, pool, river, street). Hypothèse : le plafond `WallT` (cube blanc, Z relatif 2 040, sans collision)
suit l'échelle : 4,08 m en intérieur mais **20 cm au-dessus du sol en extérieur**, où il masque tout ce qui est plus bas
(pieds, pieds des meubles) et apparaît comme le « sol » blanc ; les personnages marchent sur le vrai sol, dessous.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-056 | 2026-10-01 | L7l | `Source/LifePlay/LPSessionLogSubsystem.h/.cpp` : option `-LPDumpEvery=N` (relevé périodique) | confirmer l'hypothèse du plafond par une mesure en extérieur (`LifePlay_releve_L7l.bat`) | `git checkout L7j2-apres -- Source` |

Mesure L7l (2026-10-01, `L7l_releve3_20261001.log`, relevé toutes les 5 s) : lieu extérieur « rue » (échelle racine
3,5 ; 18 ; **0,01**) : sol à −114,5, pieds du joueur à −112 (capsule −24,2, demi-hauteur 88) : posés ;
`WallT` visible, Z relatif 2 040 → **−94,6 en monde, 18 cm au-dessus des pieds** : hypothèse confirmée. En intérieur
(café, police, échelle 0,2) : `WallT` à +293, pieds à −100 : correct (capture utilisateur sans défaut).

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-057 | 2026-10-01 | L7l | `Source/LifePlay/LPOutdoorRoomSubsystem.h/.cpp` (nouveau sous-système) | masquer le plafond `WallT` de `GI.Room` tant que l'échelle Z de sa racine est < 0,05 (lieux extérieurs), le rendre visible quand la pièce redevient intérieure (seulement s'il l'a masqué) ; aucun Blueprint ni asset modifié ; build `LifePlay_Build_5.5_L7cdj` | supprimer les 2 fichiers (`git checkout fa3d98e -- Source`) |

Validation en jeu (2026-10-01, build `LifePlay_Build_5.5_L7cdj`) : en forêt, pieds des personnages et sol texturé visibles (ERR-036 corrigé) ; pendant un appel, visage du contact cadré (ERR-031 corrigé) ; ciel de jour correct (L7c/L7d), nuit non vérifiée. Tags `L7j-valide`, `L7l-valide`.

Validation L7c/L7d (2026-10-02, parc, même cadrage) : la nuit reste claire (soleil fixe) **en 4.27, en L7i_B12 et en L7cdj** : comportement d'origine. Le grand disque blanc à l'horizon est présent **en L7i_B12 comme en L7cdj** : il ne vient pas de L7d (déjà présent en V1, origine non étudiée). Un retour arrière de L7d, lancé à tort avant cette comparaison, a été annulé avant tout commit ou build (`Tools\Restore.ps1 -Lot L7d-retour`, empreinte de la carte revenue à `8BD9C4A9…`). Tags `L7c-valide`, `L7d-valide`.

| CHG | Date | Lot | Fichiers | Raison | Retour arrière |
|---|---|---|---|---|---|
| CHG-058 | 2026-10-02 | Doc | nouveaux `07_Architecture_5.5.md`, `08_Guide_Developpeur.md`, `09_Commandes_Utiles.md`, `10_Protocole_Operations.md` ; mis à jour `README.md` (migration et racine), `01`, `03`, `04` (bilan §5), `05` (CX-C14 à C18, statuts), `06` (résultat V1), registre (ERR-020) | finalisation de la documentation de migration : architecture finale, guide développeur, commandes, protocole et leçons | `git revert` du commit |
| CHG-059 | 2026-10-02 | O0 | nouveaux `Tools/AuditAssets.py`, `Docs/Migration/11_Audit_Optimisation.md` ; lanceur `LifePlay_profil_O0.bat` (build L7cdj, hors dépôt) | audit d'optimisation en lecture seule : inventaire des assets, build livré, leviers et lots proposés ; aucune modification du projet | `git revert` du commit |
| CHG-060 | 2026-10-02 | O0 | `Docs/Migration/11_Audit_Optimisation.md` §9-10 ; lanceur `LifePlay_profil_O0.bat` corrigé (capture par `-ExecCmds`) | résultats de la mesure en jeu (60 images/s tenues, à-coups du thread de jeu dus aux minuteries Blueprint, 463 Mo de physique) ; produits utiles de la bibliothèque Fab ; lots révisés | `git revert` du commit |
| CHG-061 | 2026-10-02 | O1 | `LifePlay.uproject` (20 plugins limités à l'éditeur), `Config/DefaultGame.ini` (16 `DirectoriesToNeverCook`), nouveau `Tools/AuditScriptDeps.py` ; `README.md` : lien Mega de la V1.1 | build Shipping allégé de 387 Mo sans changement de contenu ; build `LifePlay_Build_5.5_O1` | `Tools\Restore.ps1 -Lot O1` ou `git checkout O1-avant -- LifePlay.uproject Config` |
| CHG-062 | 2026-10-02 | O9 | nouvelle commandlet `LPSetComponentCollision` ; `Content/BPs/MapMarkers.uasset` : composants `Tree` et `Car` en `NoCollision` (diff avant/après : 2 lignes) | chargement de partie de 71 s (identique en 4.27) dû aux ≈ 160 000 corps physiques des arbres et voitures décoratifs de la carte (décision utilisateur : option 1) ; build `LifePlay_Build_5.5_O9` | `Tools\Restore.ps1 -Lot O9` |
| CHG-063 | 2026-10-02 | O9b | `LPSetComponentCollision` (modèles des nœuds « Add Component ») ; `Content/BPs/MapMarkers.uasset` : modèles `NODE_AddHISM-0` et `-1` (`HISM_C`, marqueurs de bâtiments) en `NoCollision` (diff : 2 lignes) | les clics se font sur les icônes, pas sur les bâtiments (utilisateur) ; ≈ 49 500 corps physiques restants au chargement ; build `LifePlay_Build_5.5_O9b` | `Tools\Restore.ps1 -Lot O9b` |
| CHG-064 | 2026-10-02 | O2 | `Config/DefaultGame.ini` : `UsePakFile=True`, `bUseIoStore=True`, `bCompressed=True` (réglages par défaut du moteur : Oodle Kraken) ; `Modules` reste en fichiers nus | build Development 3 367 → 2 002 Mo (−40 %), 23 928 → 2 104 fichiers ; build `LifePlay_Build_5.5_O2` ; validé en jeu le 2026-10-02 (7 contrôles) | `Tools\Restore.ps1 -Lot O2` ou `git checkout O2-avant -- Config` |
| CHG-065 | 2026-10-02 | O4 | nouveau `Tools/FixTextureMips.py` ; 29 textures (`Clothes4` 27, route, trottoir) : `MipGenSettings` = groupe de texture, `NeverStream` = faux (diff : ces 2 propriétés + `LightingGuid` régénéré) | textures de couleur 3D sans mipmaps : scintillement à distance, pleine résolution toujours en mémoire ; exclus : cheveux et masques de transparence (29), interface et textures sans matériau (44), dimensions non puissance de 2 (733) ; build `LifePlay_Build_5.5_O4` | `Tools\Restore.ps1 -Lot O4` |
| CHG-066 | 2026-10-02 | O | build Shipping de distribution `LifePlay_Build_5.5_Shipping_V1.2` (O1, O2, O4, O9, O9b) | 3 246 → 1 494 Mo (−54 %), 24 249 → 2 084 fichiers ; premier essai sans ville (corrigé par CHG-067), reconstruit et validé en jeu le 2026-10-02 | — (build seulement) |
| CHG-067 | 2026-10-02 | O2b | `Plugins/ModdingExtra` : `GetAllFilesFromFolder` reconstruit la liste des `.uasset`/`.umap` depuis le registre d'assets quand le disque n'en renvoie aucun (contenu compressé IoStore) ; dépendance `AssetRegistry` | régression d'O2 constatée sur le build Shipping : aucune ville proposée (`UI/CityMenu` liste les fichiers `Heavy/StreetMap/*.uasset` du disque, `UI/City` vérifie chaque ville par suffixe `/<nom>.uasset`) ; seul appel concerné, les autres lisent des fichiers texte de `Modules` ; build `LifePlay_Build_5.5_Shipping_V1.2` reconstruit | `git checkout O2b-avant -- Plugins/ModdingExtra` |
| CHG-068 | 2026-10-02 | V1.2 | `README.md` (section V1.2, branche `ue5.5-v1.2`) ; tag annoté `v1.2` ; archive `D:\Game\LifePlay_Publication\LifePlay_Revival_V1.2_UE5.5_Full_Source_Code.7z` (4 937 914 101 octets, 25 681 fichiers, SHA-256 `fb298583743497799dd274cc62b8cf80fbef3445766be5898201924c64674f1a`, script `make_archive_v1_2.cmd`) | publication de la V1.2 (optimisation) ; contrôles : test 7-Zip, aucun `.mcp.json`/`.claude`/`McpAutomationBridge`/`Saved`/`Intermediate`, `Config`, `.uproject` et `ModdingExtra` identiques au tag | lien Mega à ajouter après envoi |
| CHG-069 | 2026-10-02 | Réconciliation | fusion `-s ours` de `vinfamy/master` dans `main` (commit `82a64d9`, arbre inchangé) ; `Docs/Migration/12_Reconciliation_Vinfamy.md` | historique de l'auteur rattaché ; aucun fichier récupérable ; les 33 scènes `corruption` vides de `vin_Base` existent dans `vin_Corruption` (non restaurées : doublons) | `git reset --hard reconcil-avant` (avant toute autre publication) |
| CHG-070 | 2026-10-02 | ERR-038 | nouveau `Source/LifePlay/LPRoomTransitionSubsystem.h/.cpp` | relevé (`ERR038_releve_20261002.log`) : la nouvelle pièce est construite ≈ 2 s avant que `destroyDummy` rende les personnages de l'ancienne à la réserve ; le sous-système cache aussitôt, au changement de pièce, les personnages actifs juste avant (hors compagnon et scène en cours), cesse de les suivre dès que le jeu les rend ou les réaffiche, et les réaffiche après 10 s par sécurité ; aucun Blueprint modifié ; build `LifePlay_Build_5.5_ERR038` ; test en jeu en attente | supprimer les 2 fichiers (`git checkout ERR038-avant -- Source`) |
| CHG-071 | 2026-10-02 | Ménage | `README.md` : V1.2 en téléchargement principal (lien Mega), V1.1 et V1 en versions précédentes ; suppression de 13 builds 5.5 obsolètes (V1rc, L7a, L7b, L7i, L7i_B12, L7cdj, O1, O1_essai1, O2, O4, O9, O9b, Shipping_V1.2_essai1, ≈ 43 Go) après copie vérifiée de `Saved`, `Content\Saves` et des lanceurs dans `D:\Game\LifePlay_Backup_5.5\builds_supprimees\` ; `08_Guide_Developpeur.md` §4 | lien V1.2 reçu ; place disque | builds : reconstruction depuis les tags git |
| CHG-072 | 2026-10-02 | ERR-038 | `LPRoomTransitionSubsystem` : détection par la seule échelle de la racine de `Room`, délai de réaffichage 10 s → 3 s | premier test en jeu concluant (anciens personnages cachés, compagnon présent, nouveaux personnages apparus), mais 2 faux positifs au relevé : nom de lieu vidé un instant sans changement de pièce ; arrivée au restaurant peuplée 3 s avant la construction de la pièce (personnages apparus 10 s en retard) ; build `LifePlay_Build_5.5_ERR038` reconstruit | `git checkout ERR038-apres -- Source/LifePlay/LPRoomTransitionSubsystem.*` |
| CHG-073 | 2026-10-02 | ERR-038 | `Source/LifePlay/LPRoomTransitionSubsystem.h/.cpp` supprimés (copie dans `D:\Game\LifePlay_Backup_5.5\ERR038_retrait`) ; build `LifePlay_Build_5.5_ERR038` reconstruit sans le sous-système (vérifié dans l'exécutable) | second test « plus problématique » : relevé `ERR038_apres2_20261002` = 2 déclenchements, tous deux à tort (clients du lieu d'arrivée cachés 3 s) ; le critère temporel ne distingue pas les personnages créés pendant le trajet puis retirés de ceux qui sont conservés ; retrait proposé et accepté par l'utilisateur ; ERR-038 reste ouvert | `git checkout ERR038-apres -- Source/LifePlay` |
| CHG-074 | 2026-10-02 | O7 | O7a : `Content/Saves` (14 125 fichiers, parties de test) → `D:\Game\LifePlay_Backup_5.5\O7\Content_Saves` (vérifié), `Content/Developers` et `Content/Collections` (dossiers vides) retirés, 3 captures de la racine rangées ; O7b : `08_Guide_Developpeur.md` §2.1 (carte de `Content/Heavy`, dossiers à ne pas déplacer) | ménage sans risque et documentation, à la place d'un renommage des dossiers jugé trop risqué (préfixes de chemins en dur, contrat de modding) | déplacer en retour le contenu de `O7\Content_Saves` |
| CHG-075 | 2026-10-02 | DATA1 | `Plugins/ModdingExtra/.../ModdingExtraBPLibrary.cpp` : statistiques de `LoadTxt` par type de fichier (bilan à la fermeture, commande `ModdingExtra.LoadTxtStats`) ; `11_Audit_Optimisation.md` §17 (stratégie de couche de données) | étape 1 de la couche de données : mesurer avant de construire ; `PopulateRaws` = 12,6 s par chargement de partie (trace O2) ; build `LifePlay_Build_5.5_DATA1` | `git checkout DATA1-avant -- Plugins/ModdingExtra` |
| CHG-076 | 2026-10-02 | DATA23 | nouveaux `Plugins/ModdingExtra/.../LPDataCache.h/.cpp` ; `ModdingExtra.cpp` (démarrage en arrière-plan), `ModdingExtraBPLibrary.cpp` (`LoadTxt` depuis la mémoire, `SaveTxt`, vérification, statistiques cache/disque), `ModdingExtra.Build.cs` (`Json`) | couche de données étapes 2 et 3 : `Modules` chargé une fois en arrière-plan, cache compilé JSON par type avec champs et calque ; 2 031 fichiers en 0,14 s depuis le cache ; build `LifePlay_Build_5.5_DATA23` ; validation en jeu en attente | `git checkout DATA23-avant -- Plugins/ModdingExtra` ; ou option `-LPNoDataCache` |
| CHG-077 | 2026-10-02 | O1b / DATA23 | `Config/DefaultGame.ini` : `+DirectoriesToNeverCook=(Path="/HairStrands")` retiré ; validation de la couche de données (CHG-076) : 2 658 textes servis par le cache, 0 écart, lecture 0,074 s pour la session | ERR-039 : erreurs `GroomComponent` au démarrage depuis O1 (module conservé par dépendance, contenu non cuit) ; vérifié : 0 erreur après reconstruction | remettre la ligne dans `DefaultGame.ini` |
| CHG-078 | 2026-10-02 | DATA4b | nouveaux `Source/LifePlay/LPDataCompat.h/.cpp` (`WhatWhereToArray` en C++, vérification `-LPVerifyWhatWhere` contre la fonction Blueprint d'origine) et `Source/LifePlayEditorTools/LPFixWhatWhereCommandlet.h/.cpp` ; `Content/BPs/GI.uasset` : 2 appels de l'EventGraph rebranchés (diff : 22 lignes, uniquement les 2 nœuds et les liaisons de leurs voisins) | `WhatWhereToArray` = 94 % de `PopulateScenes` (3,4 s par passage) ; premier essai refusé par le contrôle intégré (broche `Target` non exclue), rien sauvegardé, commandlet corrigée ; build `LifePlay_Build_5.5_DATA4b` ; validé en jeu le 2026-10-02 : plus de 3 000 appels vérifiés, 0 écart ; `PopulateRaws` 12,6 s → 1,26 s | `Tools\Restore.ps1 -Lot DATA4b` |
| CHG-079 | 2026-10-02 | V1.3 | `README.md` (section V1.3, branche `ue5.5-v1.3`) ; tag annoté `v1.3` ; build `LifePlay_Build_5.5_Shipping_V1.3` validé en jeu ; archive `LifePlay_Revival_V1.3_UE5.5_Full_Source_Code.7z` (4 945 770 158 octets, 11 583 fichiers, SHA-256 `24e7d58f759ca8998fe0d7ddc8c6a4c30262978806903e6d3deb68b37c46512a`, contrôles : test 7-Zip, aucun secret ni outil local, 14 fichiers identiques au tag) | publication de la V1.3 (couche de données, `WhatWhereToArray` en C++, ERR-039) | — |
| CHG-080 | 2026-10-02 | V1.3 | `README.md` : V1.3 en téléchargement principal (lien Mega), V1.2 et V1.1 en versions précédentes ; lien de la V1 retiré (archive supprimée de Mega faute d'espace, état git conservé par le tag `v1.0`) | lien V1.3 reçu | — |
| CHG-081 | 2026-10-02 | O7d | nouveau `Tools/BuildCollections.py` ; 13 collections statiques `Content/Collections/LifePlay*.collection` (hors dépôt, régénérables) ; `11_Audit_Optimisation.md` §16.5, `08_Guide_Developpeur.md` §2.1, `09_Commandes_Utiles.md` §3 | suite d'O7 (choix utilisateur) : regrouper les 8 561 assets par thème dans l'éditeur sans renommer de dossier ; collection transversale `LifePlay_Chemins_Fixes` (4 984 assets à ne pas déplacer) ; 13 545 chemins, 0 inconnu, chargées par l'éditeur ; aucun asset modifié, pas de build | supprimer `Content/Collections/LifePlay*.collection` (`git checkout O7d-avant` pour le reste) |