Fiche STM1-B4-VAL — Niveau N1 — Modèle prévu sonnet | utilisé claude-sonnet-5-5 — Agent lp-validator — Skills lp-validate, sk-recount, sk-protocol, debug-verification

# STM1-B4-VAL : validation statique du sous-système ULPCityWaterSubsystem (2026-10-20)

VAL STATIQUE : ni jeu, ni éditeur, ni MCP, ni build. Rien du projet n'a été modifié.

## 1. Fiches amont relues

- `STM1-SPEC-03.md` (§ 2.6, § 2.7, § 5 bis) : relue en entier.
- `STM1-B3-FIN.md` : relue en entier (assets d'eau créés, aucun sous-système avant l'étape 6).
- Résumés `STM1_Build_20261020-104737.txt` (éditeur) et `-104845.txt` (jeu Development) : lus en entier.
- Relevé `STM1_LPDumpComponents_20261020-104435.txt` et journal `Saved\Logs\portage\STM1_LPDumpComponents_20261020-104435.log` : lignes du Plane relues.
- Sources : `Source/LifePlay/LPCityWaterSubsystem.h` (50 lignes) et `.cpp` (167 lignes), lus en entier.
- Pas de fiche IMPL amont pour ce sous-système dans la demande : aucun « point à confirmer » d'IMPL à reprendre (§ 2).

## 2. Points à confirmer des IMPL

Aucune IMPL du sous-système n'a été fournie à la VAL ; `sans objet : aucun point à confirmer transmis (fiche STM1-B4-VAL ne cite que SPEC-03 et B3-FIN)`.
Points repris de SPEC-03 § 6 (non vérifiés) : Z et échelle du `Plane` -> reporté (lecture PIE § 2.7, voir réserve R1) ; repère commun maillage / UStreetMap -> hors périmètre (étape 4, déjà traité).

## 3. Critères rejoués

| Critère | Commande | Sortie brute (extrait) | Verdict |
|---|---|---|---|
| V1a résumé éditeur | Read `STM1_Build_20261020-104737.txt` ; recompte `Tools\Build.ps1 -Lot STM1-B4-VAL -FromLog ...104737.log` | fichier : `code de sortie : 0`, `Erreurs du compilateur : 0`, `Avertissements du compilateur : 0`, `Autres lignes ... : 20`, unités `LPCityWaterSubsystem.cpp`, `Module.LifePlay.cpp`. Recompte : `code=-1 duree=0s erreurs=0 avertissements=0 autres=20 unites=2` (le code -1 est normal avec -FromLog : le code vrai est celui du résumé du BUILD) | PASS avec réserve R2 (20 lignes UBT HyperAIStudio, 0 avertissement compilateur) |
| V1b résumé jeu | idem `...104845` | fichier : `code de sortie : 0`, erreurs 0, avertissements 0, autres 0, unités 2 (les mêmes). Recompte : `code=-1 duree=0s erreurs=0 avertissements=0 autres=0 unites=2` | PASS |
| V1c journaux | Grep `LPCityWater` dans `STM1_Build_20261020-104737.log` et `-104845.log` | 3 lignes de chaque : `[Adaptive Build] Excluded from LifePlay unity file: ... LPCityWaterSubsystem.cpp ...` (l. 37 / l. 15) et `Compile [x64] LPCityWaterSubsystem.cpp` (l. 44 / l. 21) ; aucune est un avertissement ou une erreur. Grep `(?i)(warning|error)` en comptage : 20 occurrences dans `-104737.log`, 0 dans `-104845.log` ; les 20 du résumé éditeur sont toutes `Warning: Plugin 'HyperAIStudio' does not list plugin ...` (aucune ne cite LPCityWater) | PASS |
| V1d fraîcheur | `ls -l` des sources : `.cpp` 10:47:24, `.h` 10:46:38 ; journaux nommés 10:47:37 et 10:48:45 | sources antérieures aux deux builds | PASS |
| V2 lecture seule du GI | Grep `ProcessEvent|SavePackage|MarkPackageDirty|SetPropertyValue|SetObjectPropertyValue|CallFunction` sur les 2 fichiers (comptage) + lecture | `No matches found` (0). Seul accès au GI : `ObjectProperty()` (.cpp:28-32) = `FindPropertyByName` + `GetObjectPropertyValue_InContainer`, appelé sur le GI (l. 81) et sur l'acteur `StreetMap_Static` (l. 82). Les seules écritures visent le composant créé par le code (`WaterComponent`, l. 136-161) | PASS-STATIC |
| V3 rien à l'écran | Grep `AddOnScreenDebugMessage|PrintString` (même comptage) | 0 occurrence ; uniquement `UE_LOG` | PASS |
| V4 conformité SPEC-03 § 2.6 | lecture `.cpp` | voir détail ci-dessous | PASS-STATIC |
| V5 fins de ligne, MD5 | `FileCheck.ps1 -Path @(.h, .cpp)` ; `tr -cd '\r' < fichier \| wc -c` | `LF 0 50 0 - DEB58EC1A0A361AD5995A890FB378E8C ...LPCityWaterSubsystem.h` ; `LF 0 167 0 - EC0946C5C1130D482E660BE3AC2C6BC3 ...LPCityWaterSubsystem.cpp` ; `fichiers=2 LF=2 alertes=0` ; CR comptés : 0 et 0 | PASS |
| V6 état git | `git status --short -- Source Content Config Plugins LifePlay.uproject` | voir ci-dessous | PASS avec signalements |

### V4 détail (fichier:ligne)

- Pose `/Game/Heavy/StreetMap/Water/<Ville>` : `.cpp:125` (chemin), `:128` `FPackageName::DoesPackageExist`, `:130` `LoadObject<UStaticMesh>`. Ville = `MapMesh->GetName()` (`:124`) : le nom court, sans contrôle du préfixe `/Game/Heavy/StreetMap/Static/` (écart mineur à « déduire du chemin », inoffensif : un nom sans paquet d'eau donne composant masqué).
- Sinon masqué : `:132-141` `SetVisibility(false)` + ligne `[LPCity] EAU ... aucun asset d'eau`.
- Sans collision, sans ombre : `:148` `NoCollision`, `:149` `SetCastShadow(false)` ; décalques coupés `:150`.
- Attaché au composant de la carte : `:146` `SetupAttachment(MapComp)`, propriétaire `Street` (`:145`) ; réutilisé tant que `GetOwner() == Street` (`:143`).
- Z = Z du Plane + 2 cm : `:19` (2.0), `:68` `GetComponentLocation().Z`, `:160` `PlaneZ + WaterAbovePlaneCm` ; repli `MapLoc.Z - 298` (`:23`, `:160`). Cohérence avec le relevé : `RelativeLocation = (X=0,Y=0,Z=-300)` du `[SCS] Plane` de `/Game/BPs/MapMarkers` (journal l. 1967 et 1991) ; -300 + 2 = -298. Correction quand le plan apparaît : `:104-114` (`bUsedFallbackZ`). Attente du plan au plus 5 s avant repli : `:26`, `:92-99`.
- Aucune dépendance à ClassicMap : Grep `ClassicMap` = 0.
- Une ligne `[LPCity]` (LogLPCity) par pose : `:165` ; lignes supplémentaires : `:139` (pas d'eau) et `:113` (correction de Z). `LogLPCity` déclaré `LifePlay.h:12`, défini `LifePlay.cpp:25`.
- Présent en Shipping : Grep `UE_BUILD_SHIPPING|WITH_EDITOR` = 0 ; modules inclus tous moteur (Engine, CoreUObject). Le Shipping n'a pas été compilé (seuls éditeur et Development l'ont été).
- Note : SPEC-03 § 2.6 parle de `LogLifePlay`; la fiche B4 et le code utilisent `LogLPCity` (conforme à la fiche).

### V6 détail

Sortie brute :
```
 M Config/DefaultInput.ini
 M LifePlay.uproject
 M Source/LifePlay/LPCameraModeSubsystem.cpp
 M Source/LifePlay/LPCameraModeSubsystem.h
 M Source/LifePlay/LPKeyboardSubsystem.cpp
 M Source/LifePlay/LPKeyboardSubsystem.h
 M Source/LifePlayEditorTools/LifePlayEditorTools.Build.cs
?? Source/LifePlay/LPCityWaterSubsystem.cpp
?? Source/LifePlay/LPCityWaterSubsystem.h
?? Source/LifePlayEditorTools/LPBuildCityWaterCommandlet.cpp
?? Source/LifePlayEditorTools/LPBuildCityWaterCommandlet.h
```
- Attendus STM1 : `LPCityWaterSubsystem.h/.cpp` (??), `LPBuildCityWaterCommandlet.*` (??), `LifePlayEditorTools.Build.cs` (M). Tous présents.
- Autres lots (signalés seulement) : `DefaultInput.ini`, `LifePlay.uproject`, `LPCameraModeSubsystem.*`, `LPKeyboardSubsystem.*`.
- Fichier inattendu : aucun.

## 4. Diff lu en entier

Les deux fichiers neufs (217 lignes) sont lus en entier (`??`, pas de diff git). Le commandlet et le `Build.cs` ne font pas partie de cette VAL (déjà couverts par B3). Aucun script n'a modifié de fichier du projet.

## 5. Verdict

**PASS avec réserves** (valeur technique : PASS-STATIC, rien d'exécuté en jeu ; V1 est rejoué sur les résumés et journaux).

Réserves et risques de code (rapportés, non corrigés) :
- R1 (incertain) : le repli `Z carte - 298 cm` suppose que `MapMarkers` est au Z de la carte et que `Plane` (enfant de `StaticMeshComponent0`) n'est pas déplacé par l'échelle du parent. Le relevé ne donne que le Z relatif (-300) et l'échelle 1e6 du Plane, pas le Z monde. Essai qui tranche : le journal `[LPCity] EAU ... Z eau=... (plan MapMarkers ...)` en PIE ou en Development (SPEC § 2.7).
- R2 : 20 avertissements UBT `HyperAIStudio does not list plugin ...` au build éditeur (connus du plugin tiers, pas de lien avec le lot) ; 0 avertissement compilateur.
- R3 : `FindPlaneZ` prend le premier acteur dont la classe contient « MapMarkers » ; après un changement de ville, un ancien `MapMarkers` encore vivant donnerait un Z périmé (même Z attendu pour toutes les villes ? non vérifié).
- R4 : `TActorIterator` : parcourt tous les acteurs, mais seulement au changement de carte (au plus 5 s d'attente, soit ≤ 20 passes) et tant que `bUsedFallbackZ` reste vrai (toutes les 0,25 s si le plan n'apparaît jamais, ex. mode sans `MapMarkers`). Coût limité mais permanent dans ce cas ; pas de borne d'arrêt de la correction.
- R5 : `LoadObject` synchrone sur le thread de jeu à chaque changement de carte (391 Ko pour Londres) : à-coup possible, faible. `DoesPackageExist` en build empaqueté non essayé.
- R6 : composant non recréé à chaque carte (réutilisé si même propriétaire, `:143`) : pas de fuite constatée. Si `StreetMap_Static` est détruit, `WaterComponent` devient invalide (`TObjectPtr` UPROPERTY, `IsValid` testé `:104`, `:134`, `:143`) : géré.
- R7 : la surveillance dépend du nom exact `StreetMapStatic` / `StaticMeshComponent` / `Plane` / « MapMarkers » ; une propriété absente donne un composant jamais posé, sans journal (le sous-système ne signale pas l'absence, contrairement à la trace `[LPCity]`).
- R8 : Shipping non compilé ; `LPTestStringCompat` et porte G-U3 sans objet (VAL statique, aucune compilation relancée).

Témoin en jeu : à créer (aucune fiche COMMUN ne couvre la pose de l'eau ; cas demandé à l'orchestrateur : eau visible sur la Tamise, modes par défaut et classique, autre ville sans eau, ligne `[LPCity] EAU` au journal).

## 6. Points à confirmer par l'utilisateur

- [ ] Z de l'eau juste sous le sol de pavé, sans scintillement ni eau enfouie (essai Development, SPEC § 4 P3).
- [ ] Eau visible aussi en mode classique (P4).
- [ ] Autre ville : aucun asset d'eau, rien posé (P5).

## Inventaire des modifications faites par la VAL

- Écrit : ce livrable.
- `Tools\Build.ps1 -FromLog` (commande prescrite par lp-validate) a écrit un résumé : `D:\Game\LifePlay-master 5.8\Docs\Migration\etat\ST\STM1\STM1-B4-VAL_BuildLog_20261020-105057.txt` (le second appel a écrasé le premier, même nom). `git status` ne le montre pas (dossier non suivi/ignoré). À ranger ou ignorer par l'orchestrateur.
- Aucun autre fichier modifié ; aucune commande git qui écrit.

## Fichiers à commiter

Aucun (livrable `STM1-B4-VAL.md` : A, sur ticket du gardien, avec les sources du lot).

Tours : 6 / 20