# 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 -avant` | tag | | 3 | `Tools\Snapshot.ps1 -Lot -Path ` | manifeste MD5 dans `D:\Game\LifePlay_Backup_5.5\` | | 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_` | | 10 | **Test en jeu par l'utilisateur** (§4) | retour, captures, journal archivé | | 11 | Vert : `CHG` au journal, registre, cahier des charges, commit, tag `-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 -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_\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/__.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 `-avant`, `-apres`, `-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.