Update 2.123

v2.123.0.0BETAMINORWakka

Arena+ Multi Dark Aeon progress sidecar + reader/writer in FfxHooksDll

• (a) new sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (dossier sec. 15 schema v1) with flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + optional tier_lock_state{} (LOCKED/READY/CLEARED); keyed by progress_flag from the catalog (arena.dark.<slug>); README documents usage rules and catalog<->sidecar mapping. (b) New module RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — best-effort JSON reader/writer (no deps), ArenaProgress_Initialize/IsRowCleared/RecordCleared gated by arena_plus_progress.flag (default off), searches $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> fallback <DllDir>/spira-arena-progress.json. Atomic persistence via .tmp + MoveFileEx. Env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 lets devs seed flags manually for UI testing. (c) dllmain.cpp calls ArenaProgress_Initialize in InstallHooks after the catalog overlay. (d) Real victory detection is still NOT wired — kept as a documented TODO; Fase 6 of the plan acknowledges this split, and the public API ArenaProgress_RecordCleared(flag, note) is ready for a future battleEnd hook consumer. PolyHook build PASS 10/10 cpp. In-game RT2 Needs Test (via FFXHOOKS_ARENAPLUS_FAKE_CLEAR)

v2.122.0.1

v2.123.0.1BETAREVISIONWakka

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

• (recipe/docs, no shipped behavior change). Plan Fase 7 (stretch). New RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + recipe doc mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md covering Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut on nagi05_70 (Dark Yojimbo alias, 5 of 6 vanilla monPos, slot 5 unused). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS against nagi05_70.bin.spiraforge.bak: chunk2 = 5 actors @ 0x18A4 (16 bytes), chunk3 = 6 monLive @ 0x1B04 (96 bytes, position-only), re-read confirms slots. Catalog row dark-penta-elemental-five updated: id renamed, token_mode blocked->alias (alias is technically legitimate), evidence notes dry-run PASS, rt2_status stays blocked (no in-game proof) — only RT0 byte-safety proved. Does NOT promote penta to a feature: stays stretch until quartet RT2 PASS + documented in-game attempt via _RT2_CHECKLIST.md. 4-way promotion plan (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) in the recipe MD

v2.123.0.0

v2.123.0.2BETAREVISIONLulu

Spira Reforge: Capture Cascade Phase A lockdown — 8 decisions locked + 3 prep artifacts

• (design/doc/schema, no code). Halyson planning session 2026-06-16 closed all 8 open decisions from §7 of the Capture Cascade doc (v2.122.0.1): D1 Magus Sisters → Mushroom Rock Road (not Gagazet — perverse nostalgia for Operation Mi'ihen + 3 tragic fayths, a mid-early area that flips to T7 endgame); D2 Bestiary F7 → dedicated tab + post-battle popup, with a slot for GPT-generated art per captured DA; D3 patrol non-fleeable; D4 drops = 1× themed shard + 1× rare consumable; D5 capture counts as kill++ (unlocks vanilla 1v1 AND SIN ladder); D6 no confirmation prompt; D7 safe-zone respected by both T7 mobs and the DA patrol; D8 buff announced only on first entry post-capture. Phase A delivers 3 artifacts: (a) sidecar schema mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (DA captures + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — de-conflicted with Jarvis-ARENA's spira-arena-progress.json sidecar from v2.123.0.0, which owns arena row clears); (b) region map mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → canonical area + patrol_subzones + safe_zones + narrative notes); (c) Phase B RE spike plan docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (1–2h playbook to locate the capturable bit in m### header via hex diff + optional IDA). Master doc updated §7 (lockdown) + §4 (final map) + §13 (artifact refs). VISION_AND_ROADMAP §11 got a "Phase A artifacts" block. 4-phase plan defined (A=lockdown done, B=RE spike in a separate chat, C=Cap-1 writer in v0.5, D=RT2 pilot)

v2.123.0.1

v2.123.1.0BETAPATCHLulu

Ronso Mana: Overdrive re-arm fix (bug #2) + 2nd-pass command-ring RE

• (fixes a runtime-hook behavior bug + RE/docs). Bug #2 ("Ronso Rage won't re-select going left after one use"): RonsoManaHook.cpp lowered the OD display gate from gateMin=100 (vanilla "full bar") to 40 (= kRonsoSkillCosts[0], the Overdrive Jump cost). With the gate at 100, after a single partial use (drain 40 → charge 60 < 100) every forcing function returned early and OD vanished until the bar refilled to 100 — contradicting the 0–255 partial pool itself. Per-row greyout (G3) still blocks unaffordable skills (cost > current charge), so lowering the gate is safe. Install banner fixed hudSafe=19→hudSafe=21 (the log printed the wrong version, hampering diagnosis). 2nd-pass RE (after RT2 hudSafe=20 FAIL): full decompile of 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + an offline command.bin dump proved: (a) the runtime command row = 0x14 header + file struct (anchor byte[25]=CharacterUser=file+5), so byte[22]=MenuFlgs etc; (b) cmd282 (Ronso Rage) IS the OD ring header (MenuFlgs=0x11→header, MainMenu=True, ODCat=19, MenuLeft) — the old "282→leaf cat4 +296" reading was wrong; (c) in 79BB70 loop-2, a header with Misc2 MenuLeft (0x10) → dword[28]&0x1000 → lands in BSS array +40, NOT +0 (visible headers) — which is why forcing 282 available never shows it in the middle ring; (d) resolve=-1 is a red herring (the main ring shows even with -1); (e) 797D60 case 3 reads a per-actor blob (actor+0xF7C); (f) 79B500 writes actor[0x590]=save[+16] early — our forcing in RefreshMenu_Shim (Prepare before the trampoline) is overwritten/wiped by that store → explains why replicating the save-edit failed. .i64 renames: 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ comments on 79BB70/797D60/79B500). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Next step (bug #1): a save-edited-vs-forced capture experiment to diff the exact delta. Fix #2 RT2 Needs Testing

v2.123.0.2

v2.123.1.1BETAREVISIONLulu

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

• (handoff doc, no code). New docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — complete prompt to spin up a dedicated chat for Capture Cascade Phase B. Lane identity: Jarvis-CAPTURE-RE. Mission: locate offset+bit capturable in the m###.bin header via hex diff (Sinscale ↔ Dark Valefor + 2 validation samples) + optional IDA CanCapture cross-check. Deliverables: ≥4-row evidence table + RESULT doc + plan-doc update + master Cap Cascade doc update + PORT_STATUS + its own REVISION bump. Non-goals explicit (does NOT implement writer, does NOT touch runtime, does NOT capture in-game). Honest estimate 1.5–2h. Unblocks Cap-1 (Phase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISIONLulu

Spira Reforge: Capture Cascade dual naming convention (internal codename + player-facing brand)

• (design/doc, no code). Halyson locked 2026-06-16: the feature keeps two names with distinct roles. Internal (technical docs, changelogs, schema fields, IDs, prompts, lane signatures) stays Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Player-facing (popups, mod README, mod page) = Yoke of Spira (EN) / Jugo de Spira (PT) — biblical/Yevon resonance (Matthew 11:30 "for my yoke is easy") echoes vanilla FFX's theocratic theme. F7 Conquests tab = The Yoke (EN) / O Jugo (PT). Default popup string: EN "Besaid is now under the yoke of Dark Valefor" / PT "Besaid está sob o jugo de Dark Valefor"; on-capture battletext EN "Dark Valefor has been tamed. Spira trembles." / PT "Dark Valefor foi domado. Spira sente o tremor." Capture Cascade doc gained §0 (naming convention table + Microsoft Threshold/Redstone rationale). VISION_AND_ROADMAP §11 gained the 3-context table with cross-link

v2.123.1.1

v2.123.2.0BETAPATCHLulu

Ronso Mana: root-cause FIX of the command ring — the ring buffer base was never dereferenced (bug #1)

• (fixes a runtime-hook behavior bug + RE). The finding: the command-ring buffer is runtime-allocated; its absolute pointer lives in a BSS cell (*(u32*)0x2310CD8). 7AEFC0/79BB70 do mov edi,[cell] (DEREF) before indexing +20592 (sort scratch) / +1144*slot (per-actor ring). RonsoManaHook.cpp used RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 raw, without the deref, and off by 0x1000 — so ALL ring writes (template, per-slot header +0, OD row +296) across hudSafe 11..21 landed in a static BSS region that was never the live displayed buffer. This explains why no BSS ring injection ever appeared, and why CopyMenuTemplate_Shim (the 7AEFC0 detour) always early-returned (delta = slotPtr - ringBase was never a multiple of 1144). Fix: new RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (the real pointer cell, taken from the imm32 of mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() now dereferences it (*(u32*)(g_base+RVA), null-checked when not yet allocated). With this, PatchKimahriCommandRingUi (+0 header), PatchKimahriMainMenuOverdriveRow (+296 OD) and CopyMenuTemplate_Shim (+296 post-sort) write to the real ring for the first time. RE proven (IDA): 7AD980 = sort one array by priority (key=*(u8*)(GetCommandEntryById+92), scratch=ring+20592); 7AEFC0 calls it 8× (one per category) to sort the per-slot ring. .i64 renames: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + comment on the pointer cell 0x2310CD8. DIAG (hudSafe=22): DumpKimahriRingState logs a readback of the real +0/+296 at G0-finalize to confirm whether the encoded OD cmd (0x311A) lands. PolyHook build PASS (10/10), apply-mode deploy. RT2 Needs Testing (bug #1: OD in the middle ring). 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 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 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_*, 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