LifePlay-Revival/Docs/Migration/etat/REL/STM1/STM1-SPEC-01.md

Fiche STM1-SPEC-01 — Niveau N2 — Modèle prévu opus medium | utilisé claude-opus-5-5 — Agent session « Medium · STM1 » (pas de sous-agent) — Skills sk-protocol, lp-ue-compat (lus en CART-01)

STM1-SPEC-01 : trace en jeu du choix de la ville (F3, option O1) (2026-10-20)

Ordre : Big Boss (local_104ff22d), 2026-10-20. Décision de l'utilisateur citée par Big Boss (session Big Boss, 04:30) : « pour street map on prépare la trace en jeu pour vérifier le pb puis on fournis une buil de développment pour les fixes en cours. La build sera générée une fois que l'on auras complété toutes les opérations ». Contrainte de Big Boss : GI.uasset ne sera révisé qu'une fois, en B2 (décision CG2 de 04:00) ; trace hors GI de préférence. SPEC rédigée sans copie UE ni MCP ; aucun fichier du projet modifié.

Résultat : SPEC prête, trace entièrement hors GI. Elle tient en C++ du module LifePlay : un sous-système neuf qui lit le GI par réflexion, sans l'écrire, et une ligne de journal ajoutée dans LPAssetRegistryHelpers. Elle s'appuie aussi sur les PrintString déjà présents dans MoveCity, qui écrivent au journal en Development. Aucun asset touché, ni Blueprint ni plugin StreetMap. Aucune lecture MCP préalable n'est nécessaire.

1. Ce que la trace doit trancher

D'après STM1-CART-02 § 1 (M1-M5), la carte tombe sur 000Dummy par l'un de ces chemins. Chacun doit laisser une signature distincte :

Chemin	Signature attendue dans la trace
C1 : démarrage resté sur la ville factice (AutoLoad(Dummy=true), pas de MoveCity suivant)	POSE … Static/000Dummy sans DEMANDE d'une autre ville ensuite
C2 : nom de ville sauvegardé introuvable (GetCityByName vide)	SAUVEGARDE ville='X' … AUCUNE correspondance, puis RESOLUTION '/Game/Heavy/StreetMap/' … ECHEC (chemin par defaut de City)
C3 : chemin résolu en échec, puis repli sur Cities[0]	RESOLUTION '<chemin ville>' ECHEC, puis LogBlueprintUserMessages … NOT VALID, puis POSE de Cities[0]
C4 : autre cause (ville bien demandée et trouvée, mais mauvais maillage posé)	DEMANDE et RESOLUTION OK de la bonne ville, mais POSE d'un autre maillage

2. Forme

• Journal seulement, rien à l'écran. Catégorie dédiée LogLPCity, verbosité Log, préfixe [LPCity] et une ligne par événement. Visible dans Saved/Logs/LifePlay.log en Development et en PIE. Absente du Shipping : corps sous #if !UE_BUILD_SHIPPING, et journalisation désactivée en Shipping par défaut.
• Sur changement seulement : chaque valeur suivie n'est écrite que quand elle change. Le coût reste négligeable : une lecture par réflexion toutes les 0,25 s.
• Toujours active en Development, sans option de ligne de commande. Une commande console LP.CityTrace écrit l'état courant à la demande.
• Les PrintString / PrintText existants de MoveCity (nom de ville, NOT VALID, Cast To Static Mesh Succeeds) sont déjà écrits dans LogBlueprintUserMessages en Development. Ils s'affichent aussi à l'écran, comme aujourd'hui : on ne les modifie pas (ils sont dans le GI). Preuve : UE_5.8/Engine/Source/Runtime/Engine/Private/KismetSystemLibrary.cpp, PrintString, garde #if !(UE_BUILD_SHIPPING || UE_BUILD_TEST) || USE_LOGGING_IN_SHIPPING ; nœuds : etat/ST/STB/dumps/GI__EventGraph.txt:17775 ('NOT VALID', bPrintToLog = 'true'), etat/ST/STE/dumps/GI__EventGraph_P2.txt:16510-16570.

3. Points de mesure et emplacement

T1. Résolution des chemins de ville : Source/LifePlay/LPAssetRegistryHelpers.cpp (modification)

MoveCity résout StreetMapName et StaticMeshName par ULPAssetRegistryHelpers::GetAssetByObjectPath (CART-02 M2, GI__EventGraph_P2.txt:12245-12275). C'est le seul passage obligé de chaque changement de ville : on le trace ici.

• Si ObjectPath commence par /Game/Heavy/StreetMap : à chaque appel, sans le dédoublonnage actuel (qui ne garde que le premier échec), UE_LOG(LogLPCity, Log, TEXT("[LPCity] RESOLUTION '%s' -> %s%s"), Chemin, OK|ECHEC, Etiquette) avec :
  • Etiquette = (chemin par defaut de City : ville non trouvee) si le chemin finit par / (/Game/Heavy/StreetMap/ ou .../Static/, valeurs par défaut de la structure City, CART-02 M1) ;
  • (ville factice) si le chemin contient 000Dummy ;
  • vide sinon.
• Les autres chemins (corps, vêtements, coiffures) gardent le comportement actuel, sans changement.
• L'avertissement GetAssetByObjectPath ECHEC existant (LPAssetRegistryHelpers.cpp:25-36) reste tel quel.

T2. Sous-système ULPCityTraceSubsystem : Source/LifePlay/LPCityTraceSubsystem.h / .cpp (nouveaux)

Un UGameInstanceSubsystem, sur le modèle de LPDebugSubsystem et LPDirectControlSubsystem. Ticker FTSTicker à 0,25 s créé dans Initialize et retiré dans Deinitialize. Lecture par réflexion comme DirectActor (LPDirectControlSubsystem.cpp:148-152) et FScriptArrayHelper (:217). Lecture seule : aucune écriture dans le GI, aucun appel de fonction Blueprint.

Id	Valeur lue	Chemin de réflexion (noms établis par les dumps)	Ligne écrite (au changement)
T2a	Liste des villes	GI.Cities (tableau de City)	une fois, dès que la liste n'est plus vide : [LPCity] CITIES n=<N> [0]='<DisplayName>' sm='<StreetMapName>' mesh='<StaticMeshName>' ; CentralLondon a l'indice <i|absent>
T2b	Ville sauvegardée	GI.SaveGameInstance → propriété City (lue par ExportTextItem, quel que soit son type)	[LPCity] SAUVEGARDE ville='<X>' -> trouvee indice <i> ('<DisplayName>') ou -> AUCUNE correspondance (GetCityByName rendra la City par defaut)
T2c	Ville demandée	GI.CityToMoveTo (struct City)	[LPCity] DEMANDE '<DisplayName>' sm='<StreetMapName>' mesh='<StaticMeshName>'
T2d	Données StreetMap posées	GI.StreetMapStatic → propriété StreetMap (objet UStreetMap)	[LPCity] STREETMAP <chemin de l'objet|None>
T2e	Maillage affiché	GI.StreetMapStatic → propriété StaticMeshComponent → GetStaticMesh()	[LPCity] POSE <chemin du maillage|None> (t=<s depuis le demarrage>)

Règles d'écriture :

• Les membres de City portent un suffixe de GUID (DisplayName_2_EBDEAF…, StreetMapName_26_C43E02…, StaticMeshName_28_61293D…, etat/portage55/L6f/L6f_dump_GI.txt:25637-25647). On les cherche par préfixe (DisplayName_, StreetMapName_, StaticMeshName_), pas par nom complet.
• T2b reproduit GetCityByName (L6f_dump_GI.txt:25623-25660) : comparaison insensible à la casse (ESearchCase::IgnoreCase) entre la ville sauvegardée et DisplayName converti en chaîne. On ne fait que la constater ; le GI garde sa propre logique.
• Propriété introuvable (le GI a pu changer depuis les dumps du 9-10 octobre) : une ligne [LPCity] PROPRIETE ABSENTE <classe>.<nom> une seule fois, puis on saute ce point de mesure. La trace se signale elle-même, sans plantage.
• Commande console LP.CityTrace : écrit d'un coup T2a à T2e, plus GI.Cities.Num().

T3. Catégorie de journal : Source/LifePlay/LifePlay.h / LifePlay.cpp (modification)

LIFEPLAY_API DECLARE_LOG_CATEGORY_EXTERN(LogLPCity, Log, All); à côté de LogLifePlay (LifePlay.h:9), et DEFINE_LOG_CATEGORY(LogLPCity); dans LifePlay.cpp. Une seule définition : pas de DEFINE_LOG_CATEGORY_STATIC répété, qui entrerait en conflit dans un même fichier unity.

4. Pourquoi hors GI, et l'option GI chiffrée

Option	Ce qu'elle voit	Coût	Risque
S1 (retenue par cette SPEC) : C++ (T1 + T2 + T3)	toutes les signatures C1-C4 : ville sauvegardée, correspondance, ville demandée, chemins résolus, maillage posé	2 fichiers neufs (~200 lignes), 3 fichiers modifiés (~25 lignes), une compilation de LifePlay	faible : lecture seule, sans asset ; se signale si un nom de propriété manque
S2 : plugin StreetMap	rien d'utile : le plugin ne connaît ni le GI ni le StaticMeshComponent de la carte (CART-01 § 1)	—	—
S3 : nœuds PrintString dans le GI (AutoLoad : valeur de Dummy ; GetCityByName : sortie trouvée ou vide ; MoveCity : branches)	en plus de S1 : la valeur exacte de Dummy et la branche prise sans déduction	~8-12 nœuds par MCP (lp-mcp-bp), sauvegarde du GI (52,7 Mo), CompileAllBlueprints, VAL ; seulement dans la révision unique B2, sinon une seconde révision du GI	moyen : touche le gros Blueprint partagé ; inutile si S1 suffit
S4 : PC.uasset (BeginAutoLoad(Dummy) est un événement du PC, etat/ST/STE/dumps/PC__EventGraph.txt:2762-2766)	la valeur de Dummy au démarrage	1-2 nœuds, sauvegarde du PC, VAL	faible à moyen ; seulement si S1 laisse C1 ambigu

Les crochets du moteur sur l'exécution Blueprint (FBlueprintCoreDelegates::OnScriptProfilingEvent, UE_5.8/.../CoreUObject/Public/UObject/Script.h:455) exigent des Blueprints instrumentés (profilage éditeur) : ils ne sont pas fiables dans une build cuite (estimé), donc écartés. Le GI dérive de /Script/Engine.GameInstance et non d'une classe C++ du projet (grep -a sur Content/BPs/GI.uasset) : on ne peut pas surcharger ProcessEvent côté projet.

5. Lecture MCP préalable : non nécessaire

Les noms utilisés (Cities, CityToMoveTo, StreetMapStatic, SaveGameInstance, City, StreetMap, StaticMeshComponent, préfixes des membres de City) sont établis par les dumps STB, STE et L6f. S'ils ont changé (CG2, B2), la trace écrit PROPRIETE ABSENTE au lieu de mentir. La lecture MCP de CART-02 § 4 reste utile pour interpréter le résultat (ordre de Cities), pas pour poser la trace.

6. Déroulé proposé (lp-lot), sous le jeton UE quand il sera libre

1. IMPL (lp-impl, N3) : T3, T1, T2 sous instantané Tools/Snapshot.ps1, entrée CHG, aucun asset.
2. BUILD (lp-builder) : Tools/Build.ps1, éditeur Development ; 0 erreur, 0 avertissement nouveau.
3. VAL (lp-validator) : en PIE ou par un commandlet de démarrage, puis grep "\[LPCity\]" Saved/Logs/LifePlay.log. Attendu au minimum : CITIES n=… (au moins une ligne) et POSE …/000Dummy au démarrage ; 0 ligne PROPRIETE ABSENTE ; rien de nouveau à l'écran ; build Shipping sans symbole LPCityTrace (corps exclu). Diff relu : aucune écriture par réflexion.
4. Livraison dans la build Development commune, générée après toutes les opérations en cours (décision de l'utilisateur).
5. L'utilisateur joue jusqu'au symptôme et transmet le journal. Lecture : la signature C1-C4 du § 1 désigne le correctif (SPEC suivante).

7. Critères d'acceptation

#	Critère	Preuve attendue
A1	Aucun fichier Content\ ni Plugins\ modifié	git status --short -- Content Plugins vide
A2	Compilation Development sans erreur ni avertissement nouveau	résumé Tools/Build.ps1
A3	Lignes [LPCity] présentes en Development : CITIES et POSE au minimum	grep -c "\[LPCity\]" ≥ 2 sur un journal PIE
A4	Rien de nouveau à l'écran	essai visuel ou absence d'appel à AddOnScreenDebugMessage dans le diff
A5	Absent du Shipping	#if !UE_BUILD_SHIPPING autour du corps, relu dans le diff
A6	Lecture seule du GI	diff : seulement GetObjectPropertyValue, ContainerPtrToValuePtr en lecture, ExportTextItem

8. Incertitudes, écarts, fichiers

• Incertain : le type exact de Save.City (chaîne ou texte). ExportTextItem couvre les deux. Il reste aussi à confirmer que CityToMoveTo est bien posé à chaque MoveCity (VariableSet_4974, GI__EventGraph_P2.txt:12289-12294, sur deux branches seulement). T1 et T2e couvrent le cas où T2c manque un changement.
• Non mesuré : rien (SPEC). Aucun fichier du projet modifié.
• Fichiers écrits : D:\Game\LifePlay-master 5.8\Docs\Migration\etat\REL\STM1\STM1-SPEC-01.md (A) ; STM1-TACHES.md (M).

Tours : ≈ 9 / 40 (déclaré ; FicheStats.py fait foi).

À verser : lp-mcp ou lp-commandlets — en Development, les PrintString/PrintText des Blueprints écrivent dans LogBlueprintUserMessages (garde !(SHIPPING||TEST)) : un graphe déjà bavard se trace par le journal, sans toucher au Blueprint.

Suite : Big Boss doit ouvrir l'IMPL STM1 (T1-T3, C++ seul) dans la file du jeton UE, avant la build Development commune. État : SPEC close, aucun fichier du projet modifié.