Aggiornamento 2.123

v2.123.0.0BETAMINORWakka

Sidecar progress Arena+ Multi Dark Aeon + lettore/scrittore in FfxHooksDll

• (a) nuovo sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (dossier sec. 15 schema v1) con flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + tier_lock_state{} opzionale (LOCKED/READY/CLEARED); chiavato da progress_flag del catalogo (arena.dark.<slug>); README documenta le regole d'uso e il mapping catalogo<->sidecar. (b) Nuovo modulo RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — lettore/scrittore JSON best-effort (nessuna dep), ArenaProgress_Initialize/IsRowCleared/RecordCleared gated da arena_plus_progress.flag (default off), cerca $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> fallback <DllDir>/spira-arena-progress.json. Persistenza atomica via .tmp + MoveFileEx. Env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 lascia i dev seminare flag manualmente per il testing UI. (c) dllmain.cpp chiama ArenaProgress_Initialize in InstallHooks dopo l'overlay catalogo. (d) La vera detection di vittoria NON è ancora cablata (letterale tecnico: NOT) — tenuta come TODO documentato; la Fase 6 del piano riconosce questo split, e l'API pubblica ArenaProgress_RecordCleared(flag, note) è pronta per un futuro consumer hook battleEnd. Build PolyHook PASS 10/10 cpp. RT2 in-game (letterale tecnico: In-game)Test richiesto (via FFXHOOKS_ARENAPLUS_FAKE_CLEAR)

v2.122.0.1

v2.123.0.1BETAREVISIONWakka

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

• (ricetta/docs, nessun cambio comportamento shipped). Piano Fase 7 (stretch). Nuova RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + doc ricetta mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md che copre Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut su nagi05_70 (alias Dark Yojimbo, 5 dei 6 monPos vanilla, slot 5 inutilizzato). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS contro nagi05_70.bin.spiraforge.bak: chunk2 = 5 actor @ 0x18A4 (16 byte), chunk3 = 6 monLive @ 0x1B04 (96 byte, solo-posizione), re-read conferma gli slot. Riga catalogo (letterale tecnico: position-only)dark-penta-elemental-five aggiornata: id rinominato, (letterale tecnico: renamed)token_mode blocked->alias (l'alias è tecnicamente legittimo), evidence nota dry-run PASS, rt2_status resta blocked (nessuna proof in-game) — solo la byte-safety RT0 provata. Non promuove (letterale tecnico: NOT) il penta a feature: resta stretch finché il quartetto non passa RT2 + tentativo in-game documentato via (letterale tecnico: RT2 PASS)_RT2_CHECKLIST.md. Piano di promozione a 4 vie (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) nel MD ricetta

v2.123.0.0

v2.123.0.2BETAREVISIONLulu

Spira Reforge: Capture Cascade Phase A lockdown — 8 decisioni bloccate + 3 artefatti prep

• (design/doc/schema, nessun codice). Sessione di pianificazione di Halyson 2026-06-16 chiude tutte le 8 decisioni aperte del §7 della doc Capture Cascade (v2.122.0.1): D1 Le 3 Magus → Mushroom Rock Road (non Gagazet — nostalgia perversa per l'Operation Mi'ihen + 3 fayth tragici, un'area mid-early che si ribalta a T7 endgame); D2 Bestiario F7 → tab dedicata + popup post-battaglia (letterale tecnico: post-battle), con uno slot per arte generata da GPT per ogni DA catturato (letterale tecnico: GPT-generated); D3 patrol non-fleeable; D4 drop = 1× shard tematico + 1× consumabile raro; D5 la cattura conta come kill++ (sblocca il vanilla 1v1 E la scala SIN); D6 (letterale tecnico: AND SIN)nessun prompt di conferma; D7 safe-zone rispettata sia dai mob T7 che dal patrol DA; D8 buff annunciato solo al primo ingresso post-cattura (letterale tecnico: post-capture). La Phase A consegna 3 artefatti: (a) schema sidecar mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (catture DA + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — de-conflicted col sidecar spira-arena-progress.json di Jarvis-ARENA di v2.123.0.0, che possiede i clear delle righe arena); (b) mappa regioni mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → area canonica + patrol_subzones + safe_zones + note narrative); (c) piano spike RE Fase B (letterale tecnico: B RE) docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (playbook 1–2h per localizzare il bit capturable nell'header m### via hex diff + IDA opzionale). Doc master aggiornata §7 (lockdown) + §4 (mappa finale) + §13 (ref artefatti). VISION_AND_ROADMAP §11 ha un blocco "Phase A artifacts". Piano a 4 fasi definito (A=lockdown fatto, B=RE spike in una chat separata, C=writer Cap-1 in v0.5, D=pilot RT2)

v2.123.0.1

v2.123.1.0BETAPATCHLulu

Ronso Majix 2: fix ri-arma Overdrive (bug #2) + 2° pass RE command-ring. (letterale tecnico: re-arm)

• (fixa un bug di comportamento runtime-hook + RE/docs). Bug #2 ("Nemitec non si ri-seleziona andando a sinistra dopo un uso"): (letterale tecnico: re-select) RonsoManaHook.cpp ha abbassato il gate di display OD da gateMin=100 (vanilla "barra piena") a 40 (= kRonsoSkillCosts[0], il costo dell'Overdrive Salto). Col gate a 100, dopo un singolo uso parziale (drain 40 → carica 60 < 100) ogni funzione di forcing return ritornava presto e l'OD spariva finché la barra non si riempiva a 100 — contraddicendo il pool parziale 0–255 stesso. Il greyout per-riga ( (letterale tecnico: Per-row)G3) blocca comunque le skill non abbordabili (costo > carica corrente), quindi abbassare il gate è sicuro. Banner install fixato hudSafe=19→hudSafe=21 (il log stampava la versione sbagliata, ostacolando la diagnosi). 2° pass RE (dopo il FAIL RT2 hudSafe=20 ): decompilazione completa di 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + dump offline command.bin hanno provato: (a) la riga comando runtime = header 0x14 + struct file (anchor byte[25]=CharacterUser=file+5), quindi byte[22]=MenuFlgs ecc; (b) cmd282 (Nemitec) È l'header dell'anello OD (letterale tecnico: IS) (MenuFlgs=0x11→header, MainMenu=True, ODCat=19, MenuLeft) — la vecchia lettura "282→leaf cat4 +296" era sbagliata; (c) in 79BB70 loop-2, un header con Misc2 MenuLeft (0x10) → dword[28]&0x1000 → atterra nell'array BSS +40, non +0 (header visibili) — ecco perché forzare 282 disponibile non lo mostra mai nell'anello centrale; (d) (letterale tecnico: NOT)resolve=-1 è un red herring (l'anello principale si mostra anche con -1); (e) 797D60 case 3 legge un blob per-actor (actor+0xF7C); (f) 79B500 scrive actor[0x590]=save[+16] presto — il nostro forcing in RefreshMenu_Shim (Prepare prima del trampoline) viene sovrascritto/spazzato da quello store → spiega perché replicare l'edit-save falliva. Rename. .i64 : 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ commenti su 79BB70/797D60/79B500). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Prossimo passo (bug #1): esperimento di cattura save-editato-vs-forzato per diffare il delta esatto. Fix #2 RT2 (letterale tecnico: save-edited-vs-forced)da testare

v2.123.0.2

v2.123.1.1BETAREVISIONLulu

Spira Reforge: prompt handoff Capture Cascade Phase B (spike RE per il bit `capturable`)

• (doc handoff, nessun codice). Nuova docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — prompt completo per avviare una chat dedicata a Capture Cascade Phase B. Identità lane: (letterale tecnico: identity)Jarvis-CAPTURE-RE. Mission: localizzare offset+bit capturable nell'header m###.bin via hex diff (Trito di Scaglia ↔ Dark Valefor + 2 sample di validazione) + cross-check IDA opzionale CanCapture. Deliverable: tabella evidenza ≥4 righe + doc RESULT + update doc piano + update doc master Cap Cascade + PORT_STATUS + il suo bump REVISION. Non-goal espliciti (NON implementa il writer, NON tocca il runtime, NON cattura in-game). Stima onesta 1.5–2h. Sblocca Cap-1 (Phase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISIONLulu

Spira Reforge: convenzione di naming duale Capture Cascade (codename interno + brand player-facing)

• (design/doc, nessun codice). Halyson ha bloccato 2026-06-16: la feature tiene due nomi con ruoli distinti. Interno (doc tecnici, changelog, campi schema, id, prompt, firme lane) resta (letterale tecnico: signatures)Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Player-facing (popup, mod README, pagina mod) = Yoke of Spira (EN) / Jugo de Spira (PT) — risonanza biblica/Yevon (Matteo 11:30 "il mio giogo è dolce") che riecheggia il tema teocratico del FFX vanilla. Tab F7 Conquests = The Yoke (EN) / O Jugo (PT). Stringa popup default: EN "Besaid is now under the yoke of Dark Valefor" / PT "Besaid está sob o jugo de Dark Valefor"; battletext on-capture EN "Dark Valefor has been tamed. Spira trembles." / PT "Dark Valefor foi domado. Spira sente o tremor." La doc Capture Cascade ha guadagnato §0 (tabella convenzione naming + razionale Microsoft Threshold/Redstone). VISION_AND_ROADMAP §11 ha guadagnato la tabella a 3 contesti con cross-link

v2.123.1.1

v2.123.2.0BETAPATCHLulu

Ronso Majix 2: fix ROOT CAUSE del command ring — la base del ring buffer non veniva mai dereferenziata (bug #1). (letterale tecnico: root-cause) (letterale tecnico: FIX)

• (fixa un bug di comportamento runtime-hook + RE). Il finding: il buffer del command ring è (letterale tecnico: command-ring)runtime-allocated; il suo puntatore assoluto vive in una cella BSS (*(u32*)0x2310CD8). 7AEFC0/79BB70 fanno mov edi,[cell] (DEREF) prima di indicizzare +20592 (scratch sort) / +1144*slot (ring per-actor). RonsoManaHook.cpp usava RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 grezza, senza deref, e sbagliata di 0x1000 — quindi TUTTI (letterale tecnico: ALL) i write al ring (template, header per-slot +0, riga OD +296) in hudSafe 11..21 atterravano in una regione BSS statica che non era mai il buffer live mostrato. Questo spiega perché nessuna iniezione BSS ring è mai apparsa, e perché CopyMenuTemplate_Shim (il detour 7AEFC0) faceva sempre early-return ( (letterale tecnico: early-returned)delta = slotPtr - ringBase non era mai un multiplo di 1144). Fix: nuova RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (la cella puntatore vera, presa dall'imm32 di mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() ora la dereferenzia (*(u32*)(g_base+RVA), null-checked quando non ancora allocata). Con questo, PatchKimahriCommandRingUi (+0 header), PatchKimahriMainMenuOverdriveRow (+296 OD) e CopyMenuTemplate_Shim (+296 post-sort) scrivono nel ring vero per la prima volta. RE provata (IDA): 7AD980 = sort di un array per priorità (key=*(u8*)(GetCommandEntryById+92), scratch=ring+20592); 7AEFC0 la chiama 8× (una per categoria) per ordinare il ring per-slot. Rename .i64: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + commento sulla cella puntatore 0x2310CD8. DIAG (hudSafe=22): DumpKimahriRingState logga un readback del +0/+296 reali a G0-finalize per confermare se il cmd OD encoded (0x311A) atterra. Build PolyHook PASS (10/10), deploy apply-mode. RT2 da testare (bug #1: OD nell'anello centrale). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §9

v2.123.1.2

v2.123.3.1BETAREVISIONSeymour

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

• (RE/doc, no behavior change; chained on top of v2.123.3.0 MINOR from a parallel lane — this REVISION is purely doc/RE and does not compete with that MINOR). Capture Cascade Phase B spike delivered doc-only: the byte that controls capturable=true|false in every m###.bin was located byte-precise and validated with 58 samples. Verdict: position = bytes[StatSheetPointer + 0x78] (where StatSheetPointer = uint32_le(bytes[0x0C])); semantics = 0xFF (sbyte -1) means uncapturable, 0x00..0x67 (sbyte 0..103) means capturable (slot index in the vanilla Monster Arena's 104-slot table); padding bytes[StatSheetPointer + 0x79] is always 0x00. Evidence chain crossed (a) legacy editor v1.4 FFXmon4.ini (label "Capture index" as 16-bit hex, 00FF = uncap), (b) current C# struct FfxLib/Monster/Monster_StatSheet.cs lines 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) live UI binding MonEditor_Control.axaml line 466 ("Capture index (Arena)"), (d) full structural layout (MonsterHeaderFile 0x40-byte header + StatSheet section + Monster_StatSheet StatBlock where ArenaId sits at offset +0x64 relative to the StatBlock that begins at section + 0x14 → file-relative +0x78). Proof: 21/21 capturables matched expected slot (including byte-exact match with FFXmon4.ini for m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 boss uncap = 0xFF, 10/10 Dark Aeons (m334..m343) = 0xFF, 3/3 Penance (nome ufficiale: Der Richter) entries (m344..m346) = 0xFF. Important operational correction: the old "DA live in m106..m113" assumption was WRONG — the real DAs are m334..m343 (proved in FfxLib/Dictionaries/Monster_Dictionary.cs lines 343-356), with Magus Sisters (nome ufficiale: Le 3 Magus) as 3 separate entries (m341/m342/m343). DOC-ONLY: nothing was written to m###.bin/DLL/runtime/save/hook in this session. Not executed: IDA confirmation of the CanCapture() gatekeeper (PLAN's optional Step 3); cross-validation against vanilla FFX Extracted\ tree (recommended but not blocking — 58/58 modded already match the vanilla expectation via the FFXmon4.ini cross-reference). Artifacts: docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md (full RESULT doc with Phase C writer recipe), work/_capture_re_2026-06-16/parse_capture_offset.ps1 (CLI parser), work/_capture_re_2026-06-16/dump_arena_id_evidence.ps1 (bulk dump), work/_capture_re_2026-06-16/capture_re_evidence_summary.json (58 rows), work/_capture_re_2026-06-16/capture_re_evidence_hexdump.txt. The original PLAN doc gained a BLOQUEIO RESOLVIDO banner + corrected DA IDs. PORT_STATUS.md got a row "Capture Cascade Cap-1 — capturable bit located" as Precisa Testar in-game (Phase C writer). Cap-1 writer (Phase C, next session) writes 1 byte per monster while preserving byte-identity of the 8 adjacent identity fields. [previous: v2.123.3.0 (parallel lane; their changelog entry will land when they ship)]

v2.123.4.0BETAPATCHLulu

Nul Ward: teach/menu-surface RE VERDICT + FIX of the menu-bound hook (it was patching the wrong `cmp 320`)

• (fixes a behavior bug in NulWardTeachHook + RE proven on the real .i64; PATCH bump → revision resets; prior HEAD v2.123.3.1 was a parallel-lane REVISION). Full RE pass (idalib MCP on the real FFX_recon.i64) answering whether teaching Radiant(320)/Umbral(321) via the sphere grid + a grown command.bin works end-to-end. PROVEN chain: (1) FFX_GrantCommandToCharacter@0x785D10 routes id≥96 to the party-wide bank g_PartyWideCommandBank@0x11307FC — 16 words/256 bits = ids 96..351; Radiant=word14 bit0, Umbral=word14 bit1; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEEDS the whole bank into actor+0x670 (copy loop ends at g_CmdAggregateAvailArrays@0x113081C → bank = 16 words); (3) FFX_Btl_IsCommandAvailable@0x79AD40 reads actor word 818+id/16 (id320→byte 0x68C bit0) — consistent; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 calls grant(char, node.LearnedMove, 1) → a node with LearnedMove=0x3140/0x3141 teaches it; (5) persistence via FFX_IsCommandLearnedPersistent@0x7850E0 reads the same bit. BUG FOUND & FIXED: BuildActorCommandMenu has 3 cmp r32,140h (two 81 FE=esi on the aggregate loops, one 81 FF=edi on the PLACEMENT loop that inserts the id into the White-magic submenu). Only the placement compare controls whether 320/321 reach the menu; the old NulWardTeachHook patched the first match (81 FE, a no-op for surfacing). FIX: it now patches all cmp r32,140h→0x142 (PolyHook rebuild PASS). Documented RT2 risks: (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 is a range-table with a fallback to cmd 0 — the grown command.bin must extend the range covering 320/321 (else Radiant resolves to cmd 0); (b) persistence depends on the ply_save limit/special map being wide enough to cover bit 224/225 (word 14). Design: id≥96 = party-wide (the whole party learns it), not per-char (96-bit cap). Renames+comments applied to the real .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.1BETAPATCHLulu

Ronso Mana hudSafe=24: PERSISTENT gauge-full PIN (`max:=charge`) — fixes "can't even go LEFT into Overdrive unless the bar is maxed"

• (fixes a runtime-hook behavior bug + RE). The finding (proven by log + decompile): FFX couples "Overdrive usable" to a full gauge (charge==max) and re-checks it PER-FRAME in the HUD/menu renderer — outside our hooks. The hudSafe=23 transient spoof set max:=charge around each trampoline but restored max=255 right after (EndKimahriMaxSpoof), so the frame the ring is drawn saw max=255 (gauge not full) → Overdrive hidden / LEFT blocked. RT2 log evidence (hudSafe=23): G0 menu charge=100 max=100 (the spoof DID work during the build) yet OD still never appeared; IsOdReady ... vanilla=1 ->1 (the 0x590 bits were set, even by vanilla) and it was still blocked. RE this pass (idalib MCP): 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — both forced and =1, NOT the gate; 792AB0 (FFX_Btl_BattleMenuInputDispatch) builds the kind=12 OD ring when 79AF70 (so the OD ring exists); 799AD0/799D60/7996E0/799830 are target-mask resolvers, not the OD-full gate. Conclusion: the live gate is the per-frame charge==max compare in the renderer — out of reach of a transient spoof. Fix: ApplyKimahriRuntimePoolMax now persistently pins max:=charge while charge>=gateMin (the gauge reads 100% full for every per-frame check while his command menu is up; the ATB/CTB is paused during command input, so no overdrive gain is lost); below the threshold it hands the real pool (255) back so the gauge refills toward 0–255. The transient Begin/End spoof is retired (no-ops); the dispatch shim now calls the persistent pin. Known tradeoff (RT2): the bar reads full while OD is usable; OD gain may pause while charge sits in the usable band (revisit if RT2 shows a gain stall — scope the pin to menu-only). PolyHook build PASS (10/10), apply-mode deploy (SHA B092B4C6). RT2 Needs Testing (go LEFT + use Ronso Rage at partial charge). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §10

v2.123.4.0

v2.123.5.0BETAPATCHLulu

Nul Ward grid-teach: command.bin range PROVEN (no exe patch) + LearnedMove encoding FIX in the editor + offline verifier

• (fixes a SphereGridExplorer editor behavior bug + new offline proof/verifier + RE). DLL untouched (the Ronso Mana lane is using it) — C#/editor/IDA only. RT2 risk #1 ELIMINATED offline: RE proved FFX_Kernel_LoadFileToTable@0x781E00 (case 0 "command") loads command.bin verbatim into a global pointer (g_CommandKernelTable@0x112A92C, full-file memcpy) — no range synthesis. FFX_Table_GetEntryByIdRange@0x7AB890 reads the range header straight from the file bytes, mapping exactly onto 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. Since the grown command.bin writes EntryCount-1=321, ids 320/321 ∈ [0,321] → resolve to exactly the appended Radiant/Umbral rows. No exe/DLL patch. New CommandKernelLookupVerifier (FfxLib/Ability) replays the engine's exact math against the grown bytes and is wired into the --nul-ward-static gate (engine_lookup_resolves check: offline proof that GetCommandEntryById(320/321) does NOT hit the cmd0 fallback). Editor FIX (SphereGridExplorer): the LearnedMove dropdown stored the raw id (0x0140), but on-disk is the encoded id (0x3000|id) — proven empirically by SphereGridRt2Lab (Armor Break in panel.bin = 0x3012) and required by the grant's (cmd & 0xFFFFF000)==0x3000 gate. The dropdown now emits 0x3000|id (Radiant→0x3140, Umbral→0x3141) and resolves names masking & 0xFFF, so the user can place the wards on the sphere grid and they actually teach (before it stored 0x0140 and the grant rejected it). .i64 renames: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + proven comments on 0x781E00/0x7AB890/0x790AE0 (saved via idalib_save). C# builds PASS (0 errors). Doc: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISIONYuna

Aurora finalization balistica: Phase 0 kickoff (docs reconciliation + legacy comment fix + variant UNVERIFIED badge)

• (docs + RE/honesty annotation; no new feature; no behavioral bump). Plan persisted at .cursor/plans/aurora_balistica.plan.md (10 phases, Halyson-confirmed scope A+B: 5 active RT2s + IDA W2S spike + variant-selector IDA spike). This REVISION ships Phase 0 only (docs reconciliation before probe instrumentation). Four edits: (1) PORT_STATUS.md "Aurora Chamber" row — Honestidade text corrected: was transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, now reflects the 2026-06-05 IDA-proof (X/Z = identity, Y residual RT2 pending, refs 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) PORT_STATUS.md top — new block Atualizacao 2026-06-16 (Aurora finalizacao balistica) summarizing real Aurora state reconciled against A15 + confirmed RT2 order (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, then IDA spike). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — JSDoc header (lines 9-10) corrected: was RAW battle-local - design-only/UNCALIBRATED, now 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 (shown in SceneDetail when _resolver.ResolveScenes(MapKey) returns more than 1 variant) now appends runtime selector UNVERIFIED next to the _a/_b/_c list, so users know the Chamber renders whichever variant the catalog picks while the real selector (story-flag -> variant) hasn't been RE-proven — see A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. Does not touch: probe, writers, offline gates, FfxHooksDll. Next (Phase 1): implement aurora-calib-v2 in RuntimeTools/FfxDinput8Probe/ctl/Program.cs with CSV/JSON output (residual identity_dx/dy/dz/rms, flipz_*, yaw180_*, enum winner enum, height_0x534, route + battle id) — spec in docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md. Phase 0 RT2: N/A (docs-only + UI string)

v2.123.5.0