LifePlay-Revival/Docs/Migration/10_Protocole_Operations.md

10 — Protocole suivi pendant les opérations

Règles appliquées du 2026-09-29 au 2026-10-02 pour toute modification du projet, et leçons tirées des erreurs commises. Elles valent pour toute reprise du projet, par un développeur comme par un agent. Détail des tests : 03_Plan_Migration_Tests.md ; correctifs de contenu : 05_Correctifs_Isoles.md.

---

1. Principes

1. Documentation d'abord : comprendre et écrire avant de modifier (documents 01 à 03 avant le premier lot).
2. Lots bornés : un lot = un objectif mesurable, une famille de corrections, une session de travail. Un lot qui déborde est coupé : le validé est commité, le reste devient un autre lot.
3. Un correctif = un sous-lot = un commit. Jamais de regroupement.
4. Tout est tracé : entrée CHG-NNN au journal (date, lot, fichiers, raison, retour arrière), défaut au registre (ERR-NNN).
5. Tout est réversible : tag git avant, copie des fichiers hors git (Snapshot.ps1), aucune suppression sans copie préalable.
6. La référence 4.27 fait foi : D:\Game\LifePlay-master 4.27 n'est jamais modifié ; un comportement 5.5 est correct s'il est identique à 4.27 sur le même parcours.
7. Environnement préservé : .claude/, .mcp.json (jeton : jamais versionné ni affiché), .editorconfig, Saved/Backups/, Saved/SaveGames/, Saved/Config/WindowsEditor, Saved/Logs/portage/, D:\DDC.

2. Déroulé d'un lot

#	Étape	Preuve
1	Entrée : lot précédent validé, git status propre	—
2	git tag <lot>-avant	tag
3	Tools\Snapshot.ps1 -Lot <lot> -Path <fichiers visés>	manifeste MD5 dans D:\Game\LifePlay_Backup_5.5\<lot>
4	Photographie avant (LPDumpAssets ou LPDumpFunction)	fichier etat/ ou Saved/Logs/portage
5	Simulation (-DryRun) : le nombre d'éléments trouvés doit égaler le nombre attendu	journal de la commandlet ; tout écart arrête le lot
6	Application, avec le contrôle intégré de la commandlet	journal
7	Photographie après + diff indépendant (DiffRemplacementNoeuds.py) : seuls les éléments attendus diffèrent	diff
8	CompileAllBlueprints, compilation C++ : aucune erreur ni avertissement nouveau	résumé
9	Build Development empaquetée	D:\Game\LifePlay_Build_5.5_<lot>
10	Test en jeu par l'utilisateur (§4)	retour, captures, journal archivé
11	Vert : CHG au journal, registre, cahier des charges, commit, tag <lot>-valide, push	commit
12	Rouge : proposer le retour arrière (§3.4), l'exécuter après accord, CHG d'annulation	journal

3. Règles de diagnostic (leçons de la campagne)

3.1 Le défaut existe-t-il déjà ?

Avant toute analyse approfondie ou tout retour arrière, demander à l'utilisateur : le défaut existe-t-il en 4.27 ? dans le build 5.5 précédent ? Pendant la campagne, la plupart des défauts visuels signalés en jeu étaient d'origine (ERR-003, ERR-030, ERR-031, ERR-036, ERR-037, nuit claire, disque blanc).

3.2 Vérifier les conditions de jeu

Un symptôme visuel peut venir des conditions de jeu. Exemple : les « téléportations » de L7b n'étaient que l'accélération du temps. Vérifier la vitesse du jeu et le moment de la journée avant d'agir.

3.3 Comparer à l'identique

• Mêmes builds de même configuration (Development), jamais l'éditeur en -game.
• Même parcours : nouvelle partie, vitesse normale, mêmes lieux dans le même ordre.
• Compteurs normalisés par personnage généré ; deux journaux qui atteignent le même point.
• Pour une capture : même lieu, même cadrage, même heure. Deux captures prises sous des angles différents ne prouvent rien.

3.4 Retour arrière : proposer, jamais improviser

Deux retours arrière ont été lancés à tort pendant la campagne : L7b (CHG-038, réappliqué en CHG-039) et L7d (2026-10-02, annulé avant commit). Les deux reposaient sur une comparaison mal faite. Règle :

• présenter le retour arrière comme une proposition, avec la preuve de régression ;
• attendre l'accord de l'utilisateur avant de l'exécuter ;
• prendre d'abord un instantané de l'état courant (Snapshot.ps1 -Lot <lot>-retour), pour pouvoir défaire le retour lui-même.

3.5 Mesurer l'exécution plutôt que déduire

Ne pas corriger à partir de la seule lecture des données ou des graphes.

• Exemple : pour ERR-036, l'analyse statique désignait une dalle de neige. Le relevé en jeu (-LPDumpEvery) a montré la vraie cause : le plafond.
• Instrumenter (§4 de 09_Commandes_Utiles.md), faire jouer, puis conclure.

3.6 Lire les sources du moteur

Un graphe identique peut donner un autre résultat (07_Architecture_5.5.md §4). Quand un écart reste inexpliqué, comparer le code moteur 4.27 et 5.5 de la fonction appelée, sur ses cas limites. Cela a permis de trouver CX-B08 (ParseIntoArray) et CX-B12 (FString::Find).

3.7 Toujours lire les diffs

Une commandlet peut perdre une liaison sans erreur ; un diff non relu ne prouve rien. Exemple : la perte de police de CX-B02 (ERR-025), dépendante de l'ordre de traitement, n'a été trouvée qu'en lisant le diff.

3.8 Analyser le relevé même quand le test en jeu passe

Un correctif « en surveillance » (sous-système qui agit sur un état du jeu) se valide d'abord sur le relevé, puis sur l'impression de l'utilisateur. Exemple : ERR-038 (CHG-070 à 073). Le premier test était jugé concluant, mais le relevé montrait déjà des déclenchements à tort, masqués par un délai de sécurité long. Le correctif a été retiré, faute de critère fiable. Si un tel critère ne peut pas distinguer les cas d'après les mesures, il faut corriger dans le Blueprint qui décide, pas autour de lui.

4. Tests en jeu avec l'utilisateur

1. Fournir une build complète dans D:\Game\LifePlay_Build_5.5_<lot>\Windows et, si une mesure est nécessaire, un .bat de lancement avec les options de diagnostic. Préciser de lancer le .bat et non LifePlay.exe.
2. Dire précisément quoi faire : lieu, durée, actions, ce qu'il faut regarder, captures attendues.
3. Après la partie, archiver le journal : Saved/Logs/portage/<lot>_<objet>_<date>.log.
4. Analyser le journal avant de conclure ; demander une capture quand le défaut est visuel.
5. Une question de comparaison (4.27, build précédent) se pose avant d'interpréter le résultat.
6. Un changement de packaging (format des fichiers, plugins, cuisson) se teste sur tous les chemins qui lisent des fichiers. Charger une partie existante ne suffit pas : il faut aussi une nouvelle partie (choix de la ville, création du personnage), la liste des mods, une sauvegarde et un rechargement, et les images externes. Leçon d'O2 : la liste des villes était vide, et seul le chemin « Continue » avait été testé.

5. Traçabilité

Support	Contenu	Règle
Journal_Modifications.md	CHG-001 à CHG-057	une entrée par modification, avec la commande de retour arrière
Registre_Erreurs.md	ERR-001 à ERR-037	statut : ouvert, corrigé (CHG), accepté, préexistant en 4.27
04_Cahier_Des_Charges.md	lots et statut	mis à jour à chaque validation
05_Correctifs_Isoles.md	correctifs CX-C (code) et CX-B (contenu)	un correctif par ligne, statut
git	commits et tags <lot>-avant, <lot>-apres, <lot>-valide, v1.0, v1.1	message en français, une ligne par lot
D:\Game\LifePlay_Backup_5.5	copies par lot, manifestes MD5	jamais supprimé
Saved/Logs/portage	journaux de parties et de commandlets	jamais supprimé

6. Publication

• Vérifier le compte actif (gh auth status) et l'identité de commit avant tout push.
• Relire ce qui part : ni jeton, ni adresse e-mail, ni outil local (McpAutomationBridge), ni contenu lourd ou binaire (.gitignore d'origine).
• Une version publiée est figée : tag (v1.0, v1.1), branche (ue5.5-v1.1), archive 7z dont l'empreinte SHA-256 est publiée.
• Depuis H3 (mods d'assets) : le build de distribution produit la version de référence de la version publiée (Releases/<ProjectVersion>), livrée dans l'archive des sources ; sans elle, aucun mod d'assets ne peut être cuit pour cette version. Mods/ doit être vide pendant le build (sources des mods dans ModSources/). Liste de contrôle : 09_Commandes_Utiles.md §7.
• Avant tout commit ou build : Mods/ vide (un mod monté par EditMod.ps1, HairPipeline.ps1 ou BuildMod.ps1 est absent de ModSources/ : git add -A enregistrerait la suppression de ses sources, CHG-110).