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.

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.

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.