WakkaBETA

Mise à jour 2.123

16/06/2026

v2.123.0.0BETAMINOR

Wakka

Arena+ Multi Dark Aeon : sidecar de progression + lecteur/écrivain dans FfxHooksDll

(a) nouveau sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (dossier sec. 15 schéma v1) avec flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + tier_lock_state{} optionnel (LOCKED/READY/CLEARED) ; clé par progress_flag du catalogue (arena.dark.<slug>) ; le README documente les règles d'usage et le mapping catalogue<->sidecar. (b) Nouveau module RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — lecteur/écrivain JSON best-effort (sans dépendances), ArenaProgress_Initialize/IsRowCleared/RecordCleared gardés par arena_plus_progress.flag (désactivé par défaut), cherche $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> repli <DllDir>/spira-arena-progress.json. Persistance atomique via .tmp + MoveFileEx. L'env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 permet aux devs de semer des drapeaux manuellement pour tester l'UI. (c) dllmain.cpp appelle ArenaProgress_Initialize dans InstallHooks après l'overlay de catalogue. (d) La vraie détection de victoire n'est toujours PAS câblée — gardée comme TODO documenté ; la Fase 6 du plan reconnaît cette scission, et l'API publique ArenaProgress_RecordCleared(flag, note) est prête pour un futur consommateur hook battleEnd. Build PolyHook PASS 10/10 cpp. RT2 en jeu Nécessite un Test (via FFXHOOKS_ARENAPLUS_FAKE_CLEAR)

v2.122.0.1

v2.123.0.1BETAREVISION

Wakka

Arena+ Multi Dark Aeon : recette stretch penta + dry-run PASS

(recette/docs, aucun changement de comportement livré). Plan Fase 7 (stretch). Nouveau RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + doc de recette mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md couvrant Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut sur nagi05_70 (alias Yojimbo purgateur, 5 des 6 monPos vanilla, slot 5 inutilisé). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS contre nagi05_70.bin.spiraforge.bak : chunk2 = 5 acteurs @ 0x18A4 (16 octets), chunk3 = 6 monLive @ 0x1B04 (96 octets, position-only), la relecture confirme les slots. Ligne de catalogue dark-penta-elemental-five mise à jour : id renommé, token_mode blocked->alias (l'alias est techniquement légitime), evidence note le dry-run PASS, rt2_status reste blocked (aucune preuve en jeu) — seule la sûreté d'octets RT0 est prouvée. Ne promeut PAS le penta en fonctionnalité : reste en stretch jusqu'au RT2 PASS du quartet + tentative en jeu documentée via _RT2_CHECKLIST.md. Plan de promotion à 4 voies (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) dans le MD de recette

v2.123.0.0

v2.123.0.2BETAREVISION

Lulu

Spira Reforge : Cascade de Capture Phase A — verrouillage — 8 décisions verrouillées + 3 artefacts de préparation

(design/doc/schéma, aucun code). Session de planification Halyson 2026-06-16 : les 8 décisions ouvertes du §7 de la doc Cascade de Capture (v2.122.0.1) sont toutes fermées : D1 Les Magus → Mushroom Rock Road (pas Gagazet — nostalgie perverse pour l'Opération Mi'ihen + 3 fayths tragiques, une zone mi-précoce qui bascule en fin de partie T7) ; D2 Bestiaire F7 → onglet dédié + popup post-bataille, avec un emplacement pour de l'art généré par GPT par DA capturé ; D3 patrouille non-fleeable ; D4 butins = 1× éclat thématique + 1× consommable rare ; D5 la capture compte comme kill++ (débloque le 1v1 vanilla ET l'échelle SIN) ; D6 aucun prompt de confirmation ; D7 zone sûre respectée par les mobs T7 et la patrouille DA ; D8 buff annoncé uniquement à la première entrée post-capture. La Phase A livre 3 artefacts : (a) schéma sidecar mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (captures DA + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — dé-conflictué avec le sidecar spira-arena-progress.json de Jarvis-ARENA de v2.123.0.0, qui possède les clears de lignes d'arène) ; (b) carte des régions mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → zone canonique + sous-zones de patrouille + zones sûres + notes narratives) ; (c) plan de spike RE Phase B docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (playbook de 1–2 h pour localiser le bit capturable dans l'en-tête m### via diff hex + IDA optionnel). Doc maître mise à jour §7 (verrouillage) + §4 (carte finale) + §13 (réfs d'artefacts). VISION_AND_ROADMAP §11 a reçu un bloc « artefacts Phase A ». Plan en 4 phases défini (A=verrouillage fait, B=spike RE dans un chat séparé, C=écrivain Cap-1 en v0.5, D=pilote RT2)

v2.123.0.1

v2.123.1.0BETAPATCH

Lulu

Ronso Bimentale : correctif de ré-armement de l'Overdrive (bug #2) + 2e passe de RE de l'anneau de commandes

(corrige un bug de comportement du hook runtime + RE/docs). Bug #2 (« Emulattak ne se re-sélectionne plus en allant à gauche après une utilisation ») : RonsoManaHook.cpp a abaissé la porte d'affichage OD de gateMin=100 (la « barre pleine » vanilla) à 40 (= kRonsoSkillCosts[0], le coût de l'Overdrive Sauter). Avec la porte à 100, après une seule utilisation partielle (drain 40 → charge 60 < 100) chaque fonction de forçage returnait tôt et l'OD disparaissait jusqu'à ce que la barre se remplisse à 100 — contredisant le pool partiel 0–255 lui-même. Le greyout par ligne (G3) bloque toujours les compétences inabordables (coût > charge actuelle), donc baisser la porte est sûr. Bannière d'installation corrigée hudSafe=19→hudSafe=21 (le log imprimait la mauvaise version, gênant le diagnostic). RE 2e passe (après l'ÉCHEC RT2 hudSafe=20) : décompile complète de 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + un dump hors ligne de command.bin a prouvé : (a) la ligne de commande runtime = en-tête 0x14 + struct de fichier (ancre byte[25]=CharacterUser=file+5), donc byte[22]=MenuFlgs etc. ; (b) cmd282 (Emulattak) EST l'en-tête de l'anneau OD (MenuFlgs=0x11→en-tête, MainMenu=True, ODCat=19, MenuLeft) — l'ancienne lecture « 282→feuille cat4 +296 » était fausse ; (c) dans la boucle-2 de 79BB70, un en-tête avec Misc2 MenuLeft (0x10) → dword[28]&0x1000 → atterrit dans le tableau BSS +40, PAS +0 (en-têtes visibles) — c'est pourquoi forcer 282 disponible ne l'affiche jamais dans l'anneau du milieu ; (d) resolve=-1 est un faux indice (l'anneau principal s'affiche même avec -1) ; (e) 797D60 case 3 lit un blob par acteur (actor+0xF7C) ; (f) 79B500 écrit actor[0x590]=save[+16] tôt — notre forçage dans RefreshMenu_Shim (Prepare avant le trampoline) est écrasé/effacé par ce store → explique pourquoi répliquer l'édition de sauvegarde a échoué. Renames .i64 : 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ commentaires sur 79BB70/797D60/79B500). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Prochaine étape (bug #1) : une expérience édit-sauvegarde vs forçé pour diff le delta exact. Correctif #2 RT2 Nécessite un Test

v2.123.0.2

v2.123.1.1BETAREVISION

Lulu

Spira Reforge : prompt de passation Phase B de la Cascade de Capture (spike RE pour le bit `capturable`)

(doc de passation, aucun code). Nouveau docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — prompt complet pour lancer un chat dédié pour la Phase B de la Cascade de Capture. Identité de voie : Jarvis-CAPTURE-RE. Mission : localiser offset+bit capturable dans l'en-tête m###.bin via diff hex (Squamelle ↔ Valefore purgatrice + 2 échantillons de validation) + vérification croisée optionnelle IDA CanCapture. Livrables : tableau de preuves ≥4 lignes + doc RESULT + mise à jour du plan-doc + mise à jour de la doc maître Cap Cascade + PORT_STATUS + son propre bump REVISION. Non-objectifs explicites (n'implémente PAS l'écrivain, ne touche PAS le runtime, ne capture PAS en jeu). Estimation honnête 1,5–2 h. Débloque Cap-1 (Phase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISION

Lulu

Spira Reforge : double convention de nommage de la Cascade de Capture (nom de code interne + marque orientée joueur)

(design/doc, aucun code). Halyson a verrouillé le 2026-06-16 : la fonctionnalité garde deux noms aux rôles distincts. Interne (docs techniques, changelogs, champs de schéma, ids, prompts, signatures de voie) reste Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Orienté joueur (popups, README du mod, page du mod) = Yoke of Spira (EN) / Jugo de Spira (PT) — résonance biblique/Yevon (Matthieu 11:30 « car mon joug est doux ») qui fait écho au thème théocratique du FFX vanilla. Onglet Conquests de F7 = The Yoke (EN) / O Jugo (PT). Chaîne de popup par défaut : EN « Besaid is now under the yoke of Valefore purgatrice » / PT « Besaid está sob o jugo de Valefore purgatrice » ; battletext de capture EN « Valefore purgatrice has been tamed. Spira trembles. » / PT « Valefore purgatrice foi domado. Spira sente o tremor. » La doc Cascade de Capture a gagné le §0 (table de convention de nommage + justification Microsoft Threshold/Redstone). VISION_AND_ROADMAP §11 a gagné la table des 3 contextes avec lien croisé

v2.123.1.1

v2.123.2.0BETAPATCH

Lulu

Ronso Bimentale : correctif de CAUSE RACINE de l'anneau de commandes — la base du buffer d'anneau n'était jamais déréférencée (bug #1)

(corrige un bug de comportement du hook runtime + RE). Le constat : le buffer de l'anneau de commandes est alloué au runtime ; son pointeur absolu vit dans une cellule BSS (*(u32*)0x2310CD8). 7AEFC0/79BB70 font mov edi,[cell] (DÉRÉFÉRENCE) avant d'indexer +20592 (scratch de tri) / +1144*slot (anneau par acteur). RonsoManaHook.cpp utilisait RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 brut, sans la déréférence, et décalé de 0x1000 — donc TOUTES les écritures d'anneau (modèle, en-tête par slot +0, ligne OD +296) à travers hudSafe 11..21 atterrissaient dans une région BSS statique qui n'a jamais été le buffer affiché vivant. Cela explique pourquoi aucune injection d'anneau BSS n'est jamais apparue, et pourquoi CopyMenuTemplate_Shim (le détour 7AEFC0) retournait toujours tôt (delta = slotPtr - ringBase n'était jamais un multiple de 1144). Correctif : nouveau RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (la vraie cellule pointeur, prise de l'imm32 de mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() la déréférence désormais (*(u32*)(g_base+RVA), vérifiée null quand pas encore allouée). Avec cela, PatchKimahriCommandRingUi (+0 en-tête), PatchKimahriMainMenuOverdriveRow (+296 OD) et CopyMenuTemplate_Shim (+296 post-tri) écrivent dans le vrai anneau pour la première fois. RE prouvée (IDA) : 7AD980 = tri d'un tableau par priorité (key=*(u8*)(GetCommandEntryById+92), scratch=ring+20592) ; 7AEFC0 l'appelle 8× (une par catégorie) pour trier l'anneau par slot. Renames .i64 : 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + commentaire sur la cellule pointeur 0x2310CD8. DIAG (hudSafe=22) : DumpKimahriRingState journalise une relecture des vrais +0/+296 à G0-finalize pour confirmer si la cmd OD encodée (0x311A) atterrit. Build PolyHook PASS (10/10), déploiement apply-mode. RT2 Nécessite un Test (bug #1 : OD dans l'anneau du milieu). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §9

v2.123.1.2

v2.123.3.1BETAREVISION

Seymour

Spira Reforge : Cascade de Capture Cap-1 — bit `capturable` dans `m###.bin` LOCALISÉ (spike RE Phase B, doc-only)

(RE/doc, aucun changement de comportement ; enchaîné par-dessus le MINOR v2.123.3.0 d'une voie parallèle — cette RÉVISION est purement doc/RE et ne concurrence pas ce MINOR). Le spike de Phase B de la Cascade de Capture livré doc-only : l'octet qui contrôle capturable=true|false dans chaque m###.bin a été localisé au niveau octet et validé avec 58 échantillons. Verdict : position = bytes[StatSheetPointer + 0x78] (où StatSheetPointer = uint32_le(bytes[0x0C])) ; sémantique = 0xFF (sbyte -1) signifie non-capturable, 0x00..0x67 (sbyte 0..103) signifie capturable (index de slot dans la table 104-slots de la Monster Arena vanilla) ; le padding bytes[StatSheetPointer + 0x79] est toujours 0x00. Chaîne de preuves croisées (a) éditeur hérité v1.4 FFXmon4.ini (label « Capture index » en hex 16-bit, 00FF = non-capturable), (b) struct C# actuelle FfxLib/Monster/Monster_StatSheet.cs lignes 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) liaison UI live MonEditor_Control.axaml ligne 466 (« Capture index (Arena) »), (d) layout structurel complet (MonsterHeaderFile en-tête 0x40 octets + section StatSheet + StatBlock de Monster_StatSheet où ArenaId siège à l'offset +0x64 relatif au StatBlock qui commence à section + 0x14 → +0x78 relatif au fichier). Preuve : 21/21 capturables correspondaient au slot attendu (dont correspondance octet-exacte avec FFXmon4.ini pour m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 boss non-capturables = 0xFF, 10/10 Dark Aeons (m334..m343) = 0xFF, 3/3 entrées Der Richter (m344..m346) = 0xFF. Correction opérationnelle importante : l'ancienne hypothèse « les DA vivent dans m106..m113 » était FAUSSE — les vrais DA sont m334..m343 (prouvé dans FfxLib/Dictionaries/Monster_Dictionary.cs lignes 343-356), avec les Les Magus comme 3 entrées séparées (m341/m342/m343). DOC-ONLY : rien n'a été écrit dans m###.bin/DLL/runtime/save/hook dans cette session. Non exécuté : confirmation IDA du gardien CanCapture() (étape 3 optionnelle du PLAN) ; validation croisée contre l'arbre vanilla FFX Extracted\ (recommandé mais non bloquant — 58/58 modded correspondent déjà à l'attente vanilla via la cross-référence FFXmon4.ini). Artefacts : docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md (doc RESULT complet avec recette d'écrivain Phase C), work/_capture_re_2026-06-16/parse_capture_offset.ps1 (parseur CLI), work/_capture_re_2026-06-16/dump_arena_id_evidence.ps1 (dump en masse), work/_capture_re_2026-06-16/capture_re_evidence_summary.json (58 lignes), work/_capture_re_2026-06-16/capture_re_evidence_hexdump.txt. Le PLAN doc d'origine a gagné une bannière BLOQUEIO RESOLVIDO + les ids DA corrigés. PORT_STATUS.md a reçu une ligne « Capture Cascade Cap-1 — bit capturable localisé » comme Precisa Testar in-game (Phase C writer). L'écrivain Cap-1 (Phase C, prochaine session) écrit 1 octet par monstre en préservant l'identité d'octets des 8 champs d'identité adjacents. [précédent : v2.123.3.0 (voie parallèle ; leur entrée de changelog atterrira quand ils livreront)]

v2.123.4.0BETAPATCH

Lulu

Nul Ward : VERDICT RE de la surface teach/menu + CORRECTIF du hook lié au menu (il patchait le mauvais `cmp 320`)

(corrige un bug de comportement dans NulWardTeachHook + RE prouvée sur le vrai .i64 ; bump PATCH → réinitialisation de révision ; le HEAD précédent v2.123.3.1 était une RÉVISION de voie parallèle). Passe RE complète (idalib MCP sur le vrai FFX_recon.i64) répondant si enseigner Radiant(320)/Umbral(321) via la sphere grid + un command.bin agrandi fonctionne de bout en bout. Chaîne PROUVÉE : (1) FFX_GrantCommandToCharacter@0x785D10 route les id≥96 vers la banque party-wide g_PartyWideCommandBank@0x11307FC — 16 mots/256 bits = ids 96..351 ; Radiant=word14 bit0, Umbral=word14 bit1 ; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SÈME toute la banque dans actor+0x670 (la boucle de copie se termine à g_CmdAggregateAvailArrays@0x113081C → banque = 16 mots) ; (3) FFX_Btl_IsCommandAvailable@0x79AD40 lit le mot d'acteur 818+id/16 (id320→octet 0x68C bit0) — cohérent ; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 appelle grant(char, node.LearnedMove, 1) → un nœud avec LearnedMove=0x3140/0x3141 l'enseigne ; (5) persistance via FFX_IsCommandLearnedPersistent@0x7850E0 qui lit le même bit. BUG TROUVÉ & CORRIGÉ : BuildActorCommandMenu a 3 cmp r32,140h (deux 81 FE=esi sur les boucles d'agrégats, un 81 FF=edi sur la boucle de PLACEMENT qui insère l'id dans le sous-menu magie blanche). Seul le compare de placement contrôle si 320/321 atteignent le menu ; l'ancien NulWardTeachHook patchait la première correspondance (81 FE, un no-op pour l'affichage). CORRECTIF : il patche désormais tous les cmp r32,140h→0x142 (rebuild PolyHook PASS). Risques RT2 documentés : (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 est une table de plages avec un repli vers cmd 0 — le command.bin agrandi doit étendre la plage couvrant 320/321 (sinon Radiant se résout en cmd 0) ; (b) la persistance dépend de la limite/carte spéciale de ply_save assez large pour couvrir le bit 224/225 (word 14). Design : id≥96 = party-wide (toute la party l'apprend), pas par personnage (cap de 96 bits). Renames+commentaires appliqués au vrai .i64 (FFX_Btl_IsCommandAvailable, FFX_Btl_InitPartyWideCommandBank, FFX_Btl_PrepareSaveCommandState, FFX_Btl_BuildAggregateChildList, g_PartyWideCommandBank, g_PerCharCmdMenuState, etc.). Doc : docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md

v2.123.3.1

v2.123.4.1BETAPATCH

Lulu

Ronso Mana hudSafe=24 : PIN PERSISTANT de jauge pleine (`max:=charge`) — corrige « on ne peut même pas aller à GAUCHE dans Overdrive sauf si la barre est maxée »

(corrige un bug de comportement du hook runtime + RE). Le constat (prouvé par log + décompile) : FFX couple « Overdrive utilisable » à une jauge pleine (charge==max) et le re-vérifie PAR FRAME dans le renderer HUD/menu — hors de nos hooks. Le spoof transitoire hudSafe=23 posait max:=charge autour de chaque trampoline mais restaurait max=255 juste après (EndKimahriMaxSpoof), donc la frame où l'anneau est dessiné voyait max=255 (jauge pas pleine) → Overdrive caché / GAUCHE bloqué. Preuve de log RT2 (hudSafe=23) : G0 menu charge=100 max=100 (le spoof MARCHAIT pendant le build) et pourtant l'OD n'apparaissait jamais ; IsOdReady ... vanilla=1 ->1 (les bits 0x590 étaient posés, même par le vanilla) et c'était quand même bloqué. RE cette passe (idalib MCP) : 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — les deux forcés et =1, PAS la porte ; 792AB0 (FFX_Btl_BattleMenuInputDispatch) construit kind=12 l'anneau OD quand 79AF70 (donc l'anneau OD existe) ; 799AD0/799D60/7996E0/799830 sont des résolveurs de masque de cible, pas la porte OD-plein. Conclusion : la porte live est le compare par frame charge==max dans le renderer — hors de portée d'un spoof transitoire. Correctif : ApplyKimahriRuntimePoolMax épingle désormais de façon persistante max:=charge tant que charge>=gateMin (la jauge lit 100 % pleine pour chaque vérification par frame pendant que son menu de commandes est ouvert ; l'ATB/CTB est en pause pendant la saisie de commande, donc aucun gain d'overdrive n'est perdu) ; sous le seuil il rend le vrai pool (255) pour que la jauge se remplisse vers 0–255. Le spoof transitoire Begin/End est retiré (no-ops) ; le shim de dispatch appelle désormais le pin persistant. Compromis connu (RT2) : la barre lit pleine pendant que l'OD est utilisable ; le gain d'OD peut marquer une pause pendant que la charge siège dans la bande utilisable (à revoir si le RT2 montre un blocage de gain — restreindre le pin au menu-only). Build PolyHook PASS (10/10), déploiement apply-mode (SHA B092B4C6). RT2 Nécessite un Test (aller à GAUCHE + utiliser Ronso Rage en charge partielle). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §10

v2.123.4.0

v2.123.5.0BETAPATCH

Lulu

Nul Ward grid-teach : plage de command.bin PROUVÉE (pas de patch exe) + correctif d'encodage LearnedMove dans l'éditeur + vérificateur hors ligne

(corrige un bug de comportement de l'éditeur SphereGridExplorer + nouvelle preuve/vérificateur hors ligne + RE). DLL intouchée (la voie Ronso Mana l'utilise) — C#/editor/IDA seulement. Risque RT2 #1 ÉLIMINÉ hors ligne : la RE a prouvé que FFX_Kernel_LoadFileToTable@0x781E00 (case 0 "command") charge command.bin verbatim dans un pointeur global (g_CommandKernelTable@0x112A92C, memcpy fichier complet) — aucune synthèse de plage. FFX_Table_GetEntryByIdRange@0x7AB890 lit l'en-tête de plage directement depuis les octets du fichier, se mappant exactement sur EntryListFile : numRanges=int16@0(=Signature=1), lo=PreviousFileCount@8(=0), hi=(EntryCount-1)@10, stride=EntrySize@12(0x60), base=EntryTableFileOffset@16(0x14) ; record = file + 0x14 + id*0x60. Comme le command.bin agrandi écrit EntryCount-1=321, les ids 320/321 ∈ [0,321] → se résolvent vers exactement les lignes Radiant/Umbral ajoutées. Aucun patch exe/DLL. Nouveau CommandKernelLookupVerifier (FfxLib/Ability) rejoue les maths exactes du moteur contre les octets agrandis et est câblé dans la porte --nul-ward-static (vérification engine_lookup_resolves : preuve hors ligne que GetCommandEntryById(320/321) ne tombe PAS sur le repli cmd0). CORRECTIF ÉDITEUR (SphereGridExplorer) : le menu déroulant LearnedMove stockait l'id brut (0x0140), mais sur disque c'est l'id encodé (0x3000|id) — prouvé empiriquement par SphereGridRt2Lab (Armor Break dans panel.bin = 0x3012) et exigé par la porte (cmd & 0xFFFFF000)==0x3000 du grant. Le menu déroulant émet désormais 0x3000|id (Radiant→0x3140, Umbral→0x3141) et résout les noms en masquant & 0xFFF, donc l'utilisateur peut placer les wards sur la sphere grid et elles enseignent vraiment (avant, il stockait 0x0140 et le grant les rejetait). Renames .i64 : 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + commentaires prouvés sur 0x781E00/0x7AB890/0x790AE0 (sauvegardés via idalib_save). Builds C# PASS (0 erreurs). Doc : docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISION

Yuna

Finalisation balistica Aurora : kickoff Phase 0 (réconciliation de docs + correctif de commentaire hérité + badge variant UNVERIFIED)

(docs + annotation RE/honnêteté ; aucune nouvelle fonctionnalité ; aucun bump comportemental). Plan persisté à .cursor/plans/aurora_balistica.plan.md (10 phases, périmètre A+B confirmé par Halyson : 5 RT2s actifs + spike IDA W2S + spike IDA sélecteur de variantes). Cette RÉVISION livre la Phase 0 uniquement (réconciliation de docs avant l'instrumentation de sonde). Quatre modifications : (1) ligne « Aurora Chamber » de PORT_STATUS.md — texte Honestidade corrigé : était transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, reflète désormais la preuve IDA du 2026-06-05 (X/Z = identity, Y residual RT2 pending, réfs FFX_AURORA_BATTLE_TO_SCENE_TRANSFORM_IDA_PROVEN_2026-06-05.md + FFX_AURORA_MASTER_RT2_CHECKLIST_2026-06-15.md A01/A04/A10). (2) haut de PORT_STATUS.md — nouveau bloc Atualizacao 2026-06-16 (Aurora finalizacao balistica) résumant l'état Aurora réel réconcilié contre A15 + ordre RT2 confirmé (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, puis spike IDA). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — en-tête JSDoc (lignes 9-10) corrigé : était RAW battle-local - design-only/UNCALIBRATED, désormais IDA-proven IDENTITY in X/Z; Y residual per area/model height (actor+0x534) RT2 pending; flip-Z stays as comparison/debug only. (4) FFXProjectEditor/Modules/AuroraChamber/AuroraChamber_DataModel.cs — variantNote (affiché dans SceneDetail quand _resolver.ResolveScenes(MapKey) renvoie plus d'1 variante) ajoute désormais runtime selector UNVERIFIED à côté de la liste _a/_b/_c, pour que les utilisateurs sachent que la Chamber rend la variante que le catalogue choisit pendant que le vrai sélecteur (story-flag -> variante) n'a pas été prouvé par RE — voir A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. Ne touche pas : sonde, écrivains, portes hors ligne, FfxHooksDll. Suivant (Phase 1) : implémenter aurora-calib-v2 dans RuntimeTools/FfxDinput8Probe/ctl/Program.cs avec sortie CSV/JSON (résiduel identity_dx/dy/dz/rms, flipz_*, yaw180_*, énum winner, height_0x534, route + id de bataille) — spec dans docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md. RT2 Phase 0 : N/A (docs-only + chaîne UI)

v2.123.5.0

Retour aux mises à jour

WakkaBETA

Mise à jour 2.123

16/06/2026

v2.123.0.0BETAMINOR

Wakka

Arena+ Multi Dark Aeon : sidecar de progression + lecteur/écrivain dans FfxHooksDll

(a) nouveau sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (dossier sec. 15 schéma v1) avec flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + tier_lock_state{} optionnel (LOCKED/READY/CLEARED) ; clé par progress_flag du catalogue (arena.dark.<slug>) ; le README documente les règles d'usage et le mapping catalogue<->sidecar. (b) Nouveau module RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — lecteur/écrivain JSON best-effort (sans dépendances), ArenaProgress_Initialize/IsRowCleared/RecordCleared gardés par arena_plus_progress.flag (désactivé par défaut), cherche $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> repli <DllDir>/spira-arena-progress.json. Persistance atomique via .tmp + MoveFileEx. L'env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 permet aux devs de semer des drapeaux manuellement pour tester l'UI. (c) dllmain.cpp appelle ArenaProgress_Initialize dans InstallHooks après l'overlay de catalogue. (d) La vraie détection de victoire n'est toujours PAS câblée — gardée comme TODO documenté ; la Fase 6 du plan reconnaît cette scission, et l'API publique ArenaProgress_RecordCleared(flag, note) est prête pour un futur consommateur hook battleEnd. Build PolyHook PASS 10/10 cpp. RT2 en jeu Nécessite un Test (via FFXHOOKS_ARENAPLUS_FAKE_CLEAR)

v2.122.0.1

v2.123.0.1BETAREVISION

Wakka

Arena+ Multi Dark Aeon : recette stretch penta + dry-run PASS

(recette/docs, aucun changement de comportement livré). Plan Fase 7 (stretch). Nouveau RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + doc de recette mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md couvrant Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut sur nagi05_70 (alias Yojimbo purgateur, 5 des 6 monPos vanilla, slot 5 inutilisé). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS contre nagi05_70.bin.spiraforge.bak : chunk2 = 5 acteurs @ 0x18A4 (16 octets), chunk3 = 6 monLive @ 0x1B04 (96 octets, position-only), la relecture confirme les slots. Ligne de catalogue dark-penta-elemental-five mise à jour : id renommé, token_mode blocked->alias (l'alias est techniquement légitime), evidence note le dry-run PASS, rt2_status reste blocked (aucune preuve en jeu) — seule la sûreté d'octets RT0 est prouvée. Ne promeut PAS le penta en fonctionnalité : reste en stretch jusqu'au RT2 PASS du quartet + tentative en jeu documentée via _RT2_CHECKLIST.md. Plan de promotion à 4 voies (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) dans le MD de recette

v2.123.0.0

v2.123.0.2BETAREVISION

Lulu

Spira Reforge : Cascade de Capture Phase A — verrouillage — 8 décisions verrouillées + 3 artefacts de préparation

(design/doc/schéma, aucun code). Session de planification Halyson 2026-06-16 : les 8 décisions ouvertes du §7 de la doc Cascade de Capture (v2.122.0.1) sont toutes fermées : D1 Les Magus → Mushroom Rock Road (pas Gagazet — nostalgie perverse pour l'Opération Mi'ihen + 3 fayths tragiques, une zone mi-précoce qui bascule en fin de partie T7) ; D2 Bestiaire F7 → onglet dédié + popup post-bataille, avec un emplacement pour de l'art généré par GPT par DA capturé ; D3 patrouille non-fleeable ; D4 butins = 1× éclat thématique + 1× consommable rare ; D5 la capture compte comme kill++ (débloque le 1v1 vanilla ET l'échelle SIN) ; D6 aucun prompt de confirmation ; D7 zone sûre respectée par les mobs T7 et la patrouille DA ; D8 buff annoncé uniquement à la première entrée post-capture. La Phase A livre 3 artefacts : (a) schéma sidecar mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (captures DA + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — dé-conflictué avec le sidecar spira-arena-progress.json de Jarvis-ARENA de v2.123.0.0, qui possède les clears de lignes d'arène) ; (b) carte des régions mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → zone canonique + sous-zones de patrouille + zones sûres + notes narratives) ; (c) plan de spike RE Phase B docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (playbook de 1–2 h pour localiser le bit capturable dans l'en-tête m### via diff hex + IDA optionnel). Doc maître mise à jour §7 (verrouillage) + §4 (carte finale) + §13 (réfs d'artefacts). VISION_AND_ROADMAP §11 a reçu un bloc « artefacts Phase A ». Plan en 4 phases défini (A=verrouillage fait, B=spike RE dans un chat séparé, C=écrivain Cap-1 en v0.5, D=pilote RT2)

v2.123.0.1

v2.123.1.0BETAPATCH

Lulu

Ronso Bimentale : correctif de ré-armement de l'Overdrive (bug #2) + 2e passe de RE de l'anneau de commandes

(corrige un bug de comportement du hook runtime + RE/docs). Bug #2 (« Emulattak ne se re-sélectionne plus en allant à gauche après une utilisation ») : RonsoManaHook.cpp a abaissé la porte d'affichage OD de gateMin=100 (la « barre pleine » vanilla) à 40 (= kRonsoSkillCosts[0], le coût de l'Overdrive Sauter). Avec la porte à 100, après une seule utilisation partielle (drain 40 → charge 60 < 100) chaque fonction de forçage returnait tôt et l'OD disparaissait jusqu'à ce que la barre se remplisse à 100 — contredisant le pool partiel 0–255 lui-même. Le greyout par ligne (G3) bloque toujours les compétences inabordables (coût > charge actuelle), donc baisser la porte est sûr. Bannière d'installation corrigée hudSafe=19→hudSafe=21 (le log imprimait la mauvaise version, gênant le diagnostic). RE 2e passe (après l'ÉCHEC RT2 hudSafe=20) : décompile complète de 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + un dump hors ligne de command.bin a prouvé : (a) la ligne de commande runtime = en-tête 0x14 + struct de fichier (ancre byte[25]=CharacterUser=file+5), donc byte[22]=MenuFlgs etc. ; (b) cmd282 (Emulattak) EST l'en-tête de l'anneau OD (MenuFlgs=0x11→en-tête, MainMenu=True, ODCat=19, MenuLeft) — l'ancienne lecture « 282→feuille cat4 +296 » était fausse ; (c) dans la boucle-2 de 79BB70, un en-tête avec Misc2 MenuLeft (0x10) → dword[28]&0x1000 → atterrit dans le tableau BSS +40, PAS +0 (en-têtes visibles) — c'est pourquoi forcer 282 disponible ne l'affiche jamais dans l'anneau du milieu ; (d) resolve=-1 est un faux indice (l'anneau principal s'affiche même avec -1) ; (e) 797D60 case 3 lit un blob par acteur (actor+0xF7C) ; (f) 79B500 écrit actor[0x590]=save[+16] tôt — notre forçage dans RefreshMenu_Shim (Prepare avant le trampoline) est écrasé/effacé par ce store → explique pourquoi répliquer l'édition de sauvegarde a échoué. Renames .i64 : 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ commentaires sur 79BB70/797D60/79B500). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Prochaine étape (bug #1) : une expérience édit-sauvegarde vs forçé pour diff le delta exact. Correctif #2 RT2 Nécessite un Test

v2.123.0.2

v2.123.1.1BETAREVISION

Lulu

Spira Reforge : prompt de passation Phase B de la Cascade de Capture (spike RE pour le bit `capturable`)

(doc de passation, aucun code). Nouveau docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — prompt complet pour lancer un chat dédié pour la Phase B de la Cascade de Capture. Identité de voie : Jarvis-CAPTURE-RE. Mission : localiser offset+bit capturable dans l'en-tête m###.bin via diff hex (Squamelle ↔ Valefore purgatrice + 2 échantillons de validation) + vérification croisée optionnelle IDA CanCapture. Livrables : tableau de preuves ≥4 lignes + doc RESULT + mise à jour du plan-doc + mise à jour de la doc maître Cap Cascade + PORT_STATUS + son propre bump REVISION. Non-objectifs explicites (n'implémente PAS l'écrivain, ne touche PAS le runtime, ne capture PAS en jeu). Estimation honnête 1,5–2 h. Débloque Cap-1 (Phase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISION

Lulu

Spira Reforge : double convention de nommage de la Cascade de Capture (nom de code interne + marque orientée joueur)

(design/doc, aucun code). Halyson a verrouillé le 2026-06-16 : la fonctionnalité garde deux noms aux rôles distincts. Interne (docs techniques, changelogs, champs de schéma, ids, prompts, signatures de voie) reste Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Orienté joueur (popups, README du mod, page du mod) = Yoke of Spira (EN) / Jugo de Spira (PT) — résonance biblique/Yevon (Matthieu 11:30 « car mon joug est doux ») qui fait écho au thème théocratique du FFX vanilla. Onglet Conquests de F7 = The Yoke (EN) / O Jugo (PT). Chaîne de popup par défaut : EN « Besaid is now under the yoke of Valefore purgatrice » / PT « Besaid está sob o jugo de Valefore purgatrice » ; battletext de capture EN « Valefore purgatrice has been tamed. Spira trembles. » / PT « Valefore purgatrice foi domado. Spira sente o tremor. » La doc Cascade de Capture a gagné le §0 (table de convention de nommage + justification Microsoft Threshold/Redstone). VISION_AND_ROADMAP §11 a gagné la table des 3 contextes avec lien croisé

v2.123.1.1

v2.123.2.0BETAPATCH

Lulu

Ronso Bimentale : correctif de CAUSE RACINE de l'anneau de commandes — la base du buffer d'anneau n'était jamais déréférencée (bug #1)

(corrige un bug de comportement du hook runtime + RE). Le constat : le buffer de l'anneau de commandes est alloué au runtime ; son pointeur absolu vit dans une cellule BSS (*(u32*)0x2310CD8). 7AEFC0/79BB70 font mov edi,[cell] (DÉRÉFÉRENCE) avant d'indexer +20592 (scratch de tri) / +1144*slot (anneau par acteur). RonsoManaHook.cpp utilisait RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 brut, sans la déréférence, et décalé de 0x1000 — donc TOUTES les écritures d'anneau (modèle, en-tête par slot +0, ligne OD +296) à travers hudSafe 11..21 atterrissaient dans une région BSS statique qui n'a jamais été le buffer affiché vivant. Cela explique pourquoi aucune injection d'anneau BSS n'est jamais apparue, et pourquoi CopyMenuTemplate_Shim (le détour 7AEFC0) retournait toujours tôt (delta = slotPtr - ringBase n'était jamais un multiple de 1144). Correctif : nouveau RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (la vraie cellule pointeur, prise de l'imm32 de mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() la déréférence désormais (*(u32*)(g_base+RVA), vérifiée null quand pas encore allouée). Avec cela, PatchKimahriCommandRingUi (+0 en-tête), PatchKimahriMainMenuOverdriveRow (+296 OD) et CopyMenuTemplate_Shim (+296 post-tri) écrivent dans le vrai anneau pour la première fois. RE prouvée (IDA) : 7AD980 = tri d'un tableau par priorité (key=*(u8*)(GetCommandEntryById+92), scratch=ring+20592) ; 7AEFC0 l'appelle 8× (une par catégorie) pour trier l'anneau par slot. Renames .i64 : 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + commentaire sur la cellule pointeur 0x2310CD8. DIAG (hudSafe=22) : DumpKimahriRingState journalise une relecture des vrais +0/+296 à G0-finalize pour confirmer si la cmd OD encodée (0x311A) atterrit. Build PolyHook PASS (10/10), déploiement apply-mode. RT2 Nécessite un Test (bug #1 : OD dans l'anneau du milieu). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §9

v2.123.1.2

v2.123.3.1BETAREVISION

Seymour

Spira Reforge : Cascade de Capture Cap-1 — bit `capturable` dans `m###.bin` LOCALISÉ (spike RE Phase B, doc-only)

(RE/doc, aucun changement de comportement ; enchaîné par-dessus le MINOR v2.123.3.0 d'une voie parallèle — cette RÉVISION est purement doc/RE et ne concurrence pas ce MINOR). Le spike de Phase B de la Cascade de Capture livré doc-only : l'octet qui contrôle capturable=true|false dans chaque m###.bin a été localisé au niveau octet et validé avec 58 échantillons. Verdict : position = bytes[StatSheetPointer + 0x78] (où StatSheetPointer = uint32_le(bytes[0x0C])) ; sémantique = 0xFF (sbyte -1) signifie non-capturable, 0x00..0x67 (sbyte 0..103) signifie capturable (index de slot dans la table 104-slots de la Monster Arena vanilla) ; le padding bytes[StatSheetPointer + 0x79] est toujours 0x00. Chaîne de preuves croisées (a) éditeur hérité v1.4 FFXmon4.ini (label « Capture index » en hex 16-bit, 00FF = non-capturable), (b) struct C# actuelle FfxLib/Monster/Monster_StatSheet.cs lignes 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) liaison UI live MonEditor_Control.axaml ligne 466 (« Capture index (Arena) »), (d) layout structurel complet (MonsterHeaderFile en-tête 0x40 octets + section StatSheet + StatBlock de Monster_StatSheet où ArenaId siège à l'offset +0x64 relatif au StatBlock qui commence à section + 0x14 → +0x78 relatif au fichier). Preuve : 21/21 capturables correspondaient au slot attendu (dont correspondance octet-exacte avec FFXmon4.ini pour m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 boss non-capturables = 0xFF, 10/10 Dark Aeons (m334..m343) = 0xFF, 3/3 entrées Der Richter (m344..m346) = 0xFF. Correction opérationnelle importante : l'ancienne hypothèse « les DA vivent dans m106..m113 » était FAUSSE — les vrais DA sont m334..m343 (prouvé dans FfxLib/Dictionaries/Monster_Dictionary.cs lignes 343-356), avec les Les Magus comme 3 entrées séparées (m341/m342/m343). DOC-ONLY : rien n'a été écrit dans m###.bin/DLL/runtime/save/hook dans cette session. Non exécuté : confirmation IDA du gardien CanCapture() (étape 3 optionnelle du PLAN) ; validation croisée contre l'arbre vanilla FFX Extracted\ (recommandé mais non bloquant — 58/58 modded correspondent déjà à l'attente vanilla via la cross-référence FFXmon4.ini). Artefacts : docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md (doc RESULT complet avec recette d'écrivain Phase C), work/_capture_re_2026-06-16/parse_capture_offset.ps1 (parseur CLI), work/_capture_re_2026-06-16/dump_arena_id_evidence.ps1 (dump en masse), work/_capture_re_2026-06-16/capture_re_evidence_summary.json (58 lignes), work/_capture_re_2026-06-16/capture_re_evidence_hexdump.txt. Le PLAN doc d'origine a gagné une bannière BLOQUEIO RESOLVIDO + les ids DA corrigés. PORT_STATUS.md a reçu une ligne « Capture Cascade Cap-1 — bit capturable localisé » comme Precisa Testar in-game (Phase C writer). L'écrivain Cap-1 (Phase C, prochaine session) écrit 1 octet par monstre en préservant l'identité d'octets des 8 champs d'identité adjacents. [précédent : v2.123.3.0 (voie parallèle ; leur entrée de changelog atterrira quand ils livreront)]

v2.123.4.0BETAPATCH

Lulu

Nul Ward : VERDICT RE de la surface teach/menu + CORRECTIF du hook lié au menu (il patchait le mauvais `cmp 320`)

(corrige un bug de comportement dans NulWardTeachHook + RE prouvée sur le vrai .i64 ; bump PATCH → réinitialisation de révision ; le HEAD précédent v2.123.3.1 était une RÉVISION de voie parallèle). Passe RE complète (idalib MCP sur le vrai FFX_recon.i64) répondant si enseigner Radiant(320)/Umbral(321) via la sphere grid + un command.bin agrandi fonctionne de bout en bout. Chaîne PROUVÉE : (1) FFX_GrantCommandToCharacter@0x785D10 route les id≥96 vers la banque party-wide g_PartyWideCommandBank@0x11307FC — 16 mots/256 bits = ids 96..351 ; Radiant=word14 bit0, Umbral=word14 bit1 ; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SÈME toute la banque dans actor+0x670 (la boucle de copie se termine à g_CmdAggregateAvailArrays@0x113081C → banque = 16 mots) ; (3) FFX_Btl_IsCommandAvailable@0x79AD40 lit le mot d'acteur 818+id/16 (id320→octet 0x68C bit0) — cohérent ; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 appelle grant(char, node.LearnedMove, 1) → un nœud avec LearnedMove=0x3140/0x3141 l'enseigne ; (5) persistance via FFX_IsCommandLearnedPersistent@0x7850E0 qui lit le même bit. BUG TROUVÉ & CORRIGÉ : BuildActorCommandMenu a 3 cmp r32,140h (deux 81 FE=esi sur les boucles d'agrégats, un 81 FF=edi sur la boucle de PLACEMENT qui insère l'id dans le sous-menu magie blanche). Seul le compare de placement contrôle si 320/321 atteignent le menu ; l'ancien NulWardTeachHook patchait la première correspondance (81 FE, un no-op pour l'affichage). CORRECTIF : il patche désormais tous les cmp r32,140h→0x142 (rebuild PolyHook PASS). Risques RT2 documentés : (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 est une table de plages avec un repli vers cmd 0 — le command.bin agrandi doit étendre la plage couvrant 320/321 (sinon Radiant se résout en cmd 0) ; (b) la persistance dépend de la limite/carte spéciale de ply_save assez large pour couvrir le bit 224/225 (word 14). Design : id≥96 = party-wide (toute la party l'apprend), pas par personnage (cap de 96 bits). Renames+commentaires appliqués au vrai .i64 (FFX_Btl_IsCommandAvailable, FFX_Btl_InitPartyWideCommandBank, FFX_Btl_PrepareSaveCommandState, FFX_Btl_BuildAggregateChildList, g_PartyWideCommandBank, g_PerCharCmdMenuState, etc.). Doc : docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md

v2.123.3.1

v2.123.4.1BETAPATCH

Lulu

Ronso Mana hudSafe=24 : PIN PERSISTANT de jauge pleine (`max:=charge`) — corrige « on ne peut même pas aller à GAUCHE dans Overdrive sauf si la barre est maxée »

(corrige un bug de comportement du hook runtime + RE). Le constat (prouvé par log + décompile) : FFX couple « Overdrive utilisable » à une jauge pleine (charge==max) et le re-vérifie PAR FRAME dans le renderer HUD/menu — hors de nos hooks. Le spoof transitoire hudSafe=23 posait max:=charge autour de chaque trampoline mais restaurait max=255 juste après (EndKimahriMaxSpoof), donc la frame où l'anneau est dessiné voyait max=255 (jauge pas pleine) → Overdrive caché / GAUCHE bloqué. Preuve de log RT2 (hudSafe=23) : G0 menu charge=100 max=100 (le spoof MARCHAIT pendant le build) et pourtant l'OD n'apparaissait jamais ; IsOdReady ... vanilla=1 ->1 (les bits 0x590 étaient posés, même par le vanilla) et c'était quand même bloqué. RE cette passe (idalib MCP) : 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — les deux forcés et =1, PAS la porte ; 792AB0 (FFX_Btl_BattleMenuInputDispatch) construit kind=12 l'anneau OD quand 79AF70 (donc l'anneau OD existe) ; 799AD0/799D60/7996E0/799830 sont des résolveurs de masque de cible, pas la porte OD-plein. Conclusion : la porte live est le compare par frame charge==max dans le renderer — hors de portée d'un spoof transitoire. Correctif : ApplyKimahriRuntimePoolMax épingle désormais de façon persistante max:=charge tant que charge>=gateMin (la jauge lit 100 % pleine pour chaque vérification par frame pendant que son menu de commandes est ouvert ; l'ATB/CTB est en pause pendant la saisie de commande, donc aucun gain d'overdrive n'est perdu) ; sous le seuil il rend le vrai pool (255) pour que la jauge se remplisse vers 0–255. Le spoof transitoire Begin/End est retiré (no-ops) ; le shim de dispatch appelle désormais le pin persistant. Compromis connu (RT2) : la barre lit pleine pendant que l'OD est utilisable ; le gain d'OD peut marquer une pause pendant que la charge siège dans la bande utilisable (à revoir si le RT2 montre un blocage de gain — restreindre le pin au menu-only). Build PolyHook PASS (10/10), déploiement apply-mode (SHA B092B4C6). RT2 Nécessite un Test (aller à GAUCHE + utiliser Ronso Rage en charge partielle). Doc : docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §10

v2.123.4.0

v2.123.5.0BETAPATCH

Lulu

Nul Ward grid-teach : plage de command.bin PROUVÉE (pas de patch exe) + correctif d'encodage LearnedMove dans l'éditeur + vérificateur hors ligne

(corrige un bug de comportement de l'éditeur SphereGridExplorer + nouvelle preuve/vérificateur hors ligne + RE). DLL intouchée (la voie Ronso Mana l'utilise) — C#/editor/IDA seulement. Risque RT2 #1 ÉLIMINÉ hors ligne : la RE a prouvé que FFX_Kernel_LoadFileToTable@0x781E00 (case 0 "command") charge command.bin verbatim dans un pointeur global (g_CommandKernelTable@0x112A92C, memcpy fichier complet) — aucune synthèse de plage. FFX_Table_GetEntryByIdRange@0x7AB890 lit l'en-tête de plage directement depuis les octets du fichier, se mappant exactement sur EntryListFile : numRanges=int16@0(=Signature=1), lo=PreviousFileCount@8(=0), hi=(EntryCount-1)@10, stride=EntrySize@12(0x60), base=EntryTableFileOffset@16(0x14) ; record = file + 0x14 + id*0x60. Comme le command.bin agrandi écrit EntryCount-1=321, les ids 320/321 ∈ [0,321] → se résolvent vers exactement les lignes Radiant/Umbral ajoutées. Aucun patch exe/DLL. Nouveau CommandKernelLookupVerifier (FfxLib/Ability) rejoue les maths exactes du moteur contre les octets agrandis et est câblé dans la porte --nul-ward-static (vérification engine_lookup_resolves : preuve hors ligne que GetCommandEntryById(320/321) ne tombe PAS sur le repli cmd0). CORRECTIF ÉDITEUR (SphereGridExplorer) : le menu déroulant LearnedMove stockait l'id brut (0x0140), mais sur disque c'est l'id encodé (0x3000|id) — prouvé empiriquement par SphereGridRt2Lab (Armor Break dans panel.bin = 0x3012) et exigé par la porte (cmd & 0xFFFFF000)==0x3000 du grant. Le menu déroulant émet désormais 0x3000|id (Radiant→0x3140, Umbral→0x3141) et résout les noms en masquant & 0xFFF, donc l'utilisateur peut placer les wards sur la sphere grid et elles enseignent vraiment (avant, il stockait 0x0140 et le grant les rejetait). Renames .i64 : 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + commentaires prouvés sur 0x781E00/0x7AB890/0x790AE0 (sauvegardés via idalib_save). Builds C# PASS (0 erreurs). Doc : docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISION

Yuna

Finalisation balistica Aurora : kickoff Phase 0 (réconciliation de docs + correctif de commentaire hérité + badge variant UNVERIFIED)

(docs + annotation RE/honnêteté ; aucune nouvelle fonctionnalité ; aucun bump comportemental). Plan persisté à .cursor/plans/aurora_balistica.plan.md (10 phases, périmètre A+B confirmé par Halyson : 5 RT2s actifs + spike IDA W2S + spike IDA sélecteur de variantes). Cette RÉVISION livre la Phase 0 uniquement (réconciliation de docs avant l'instrumentation de sonde). Quatre modifications : (1) ligne « Aurora Chamber » de PORT_STATUS.md — texte Honestidade corrigé : était transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, reflète désormais la preuve IDA du 2026-06-05 (X/Z = identity, Y residual RT2 pending, réfs FFX_AURORA_BATTLE_TO_SCENE_TRANSFORM_IDA_PROVEN_2026-06-05.md + FFX_AURORA_MASTER_RT2_CHECKLIST_2026-06-15.md A01/A04/A10). (2) haut de PORT_STATUS.md — nouveau bloc Atualizacao 2026-06-16 (Aurora finalizacao balistica) résumant l'état Aurora réel réconcilié contre A15 + ordre RT2 confirmé (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, puis spike IDA). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — en-tête JSDoc (lignes 9-10) corrigé : était RAW battle-local - design-only/UNCALIBRATED, désormais IDA-proven IDENTITY in X/Z; Y residual per area/model height (actor+0x534) RT2 pending; flip-Z stays as comparison/debug only. (4) FFXProjectEditor/Modules/AuroraChamber/AuroraChamber_DataModel.cs — variantNote (affiché dans SceneDetail quand _resolver.ResolveScenes(MapKey) renvoie plus d'1 variante) ajoute désormais runtime selector UNVERIFIED à côté de la liste _a/_b/_c, pour que les utilisateurs sachent que la Chamber rend la variante que le catalogue choisit pendant que le vrai sélecteur (story-flag -> variante) n'a pas été prouvé par RE — voir A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. Ne touche pas : sonde, écrivains, portes hors ligne, FfxHooksDll. Suivant (Phase 1) : implémenter aurora-calib-v2 dans RuntimeTools/FfxDinput8Probe/ctl/Program.cs avec sortie CSV/JSON (résiduel identity_dx/dy/dz/rms, flipz_*, yaw180_*, énum winner, height_0x534, route + id de bataille) — spec dans docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md. RT2 Phase 0 : N/A (docs-only + chaîne UI)

v2.123.5.0