126 lines
8 KiB
Markdown
126 lines
8 KiB
Markdown
# 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.
|