Update 2.123

v2.123.0.0BETAMINORWakka

Arena+ Multi-Dark-Aeon-Fortschritts-Sidecar + Reader/Writer in FfxHooksDll

• (a) neues Sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (Dossier-Sec.-15-Schema v1) mit flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + optionalem tier_lock_state{} (LOCKED/READY/CLEARED); keyed by progress_flag aus dem Katalog (arena.dark.<slug>); README dokumentiert Nutzungsregeln und Katalog↔Sidecar-Mapping. (b) Neues Modul RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — best-effort JSON-Reader/Writer (keine Abhängigkeiten), ArenaProgress_Initialize/IsRowCleared/RecordCleared gegated durch arena_plus_progress.flag (default off), sucht $FFXHOOKS_ARENAPLUS_PROGRESS_PATH → <DllDir>/mods/Spira Reforge/arena/progress/... → Fallback <DllDir>/spira-arena-progress.json. Atomare Persistenz via .tmp + MoveFileEx. Env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 erlaubt Entwicklern, Flags für UI-Tests manuell zu setzen. (c) dllmain.cpp ruft ArenaProgress_Initialize in InstallHooks nach dem Katalog-Overlay. (d) Echte Sieg-Erkennung ist noch NICHT verdrahtet — als dokumentiertes TODO belassen; Fase 6 des Plans erkennt diese Trennung an, und die öffentliche API ArenaProgress_RecordCleared(flag, note) ist bereit für einen zukünftigen 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-Rezept + Dry-Run-PASS

• (Rezept/Docs, keine gelieferte Verhaltensänderung). Plan Fase 7 (Stretch). Neues RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + Rezept-Doc mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md mit Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut auf nagi05_70 (Schwarzer Yojinbo-Alias, 5 von 6 Vanilla-monPos, Slot 5 ungenutzt). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS gegen nagi05_70.bin.spiraforge.bak: chunk2 = 5 Actors @ 0x18A4 (16 Bytes), chunk3 = 6 monLive @ 0x1B04 (96 Bytes, positions-only), Re-Read bestätigt Tombola. Katalog-Zeile dark-penta-elemental-five aktualisiert: id umbenannt, token_mode blocked->alias (Alias ist technisch legitim), evidence notiert dry-run PASS, rt2_status bleibt blocked (kein In-Game-Beweis) — nur RT0-Byte-Sicherheit bewiesen. Befördert Penta NICHT zum Feature: bleibt Stretch bis Quartet-RT2 PASS + dokumentierter In-Game-Versuch via _RT2_CHECKLIST.md. 4-Wege-Promotion-Plan (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) im Rezept-MD

v2.123.0.0

v2.123.0.2BETAREVISIONLulu

Spira Reforge: Capture Cascade Phase A Lockdown — 8 Entscheidungen festgelegt + 3 Prep-Artefakte

• (Design/Doc/Schema, kein Code). Halyson-Planungssession 2026-06-16 schloss alle 8 offenen Entscheidungen aus §7 des Capture-Cascade-Docs (v2.122.0.1): D1 Magus-Trio → Mushroom Rock Road (nicht Gagazet — perverse Nostalgie für Operation Mi'ihen + 3 tragische Fayths, ein mittel-frühes Gebiet, das zu T7-Endgame kippt); D2 Bestiary F7 → dedizierter Tab + Post-Battle-Popup, mit Slot für GPT-generierte Kunst pro gefangenem DA; D3 Patrouille nicht fliehbar; D4 Drops = 1× thematischer Splitter + 1× seltenes Verbrauchsgut; D5 Capture zählt als kill++ (schaltet Vanilla-1v1 UND SIN-Leiter frei); D6 kein Bestätigungs-Prompt; D7 Safe-Zone von T7-Mobs UND DA-Patrouille respektiert; D8 Buff nur beim ersten Eintritt nach Capture angekündigt. Phase A liefert 3 Artefakte: (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-konfliktet mit Jarvis-ARENA's spira-arena-progress.json-Sidecar aus v2.123.0.0, das Arena-Zeilen-Clears besitzt); (b) Regions-Map mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → kanonische Region + patrol_subzones + safe_zones + narrative Notizen); (c) Phase-B-RE-Spike-Plan docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (1–2h-Playbook zum Auffinden des capturable-Bits im m###-Header via Hex-Diff + optional IDA). Master-Doc aktualisiert §7 (Lockdown) + §4 (finale Weltkarte) + §13 (Artefakt-Refs). VISION_AND_ROADMAP §11 erhielt einen „Phase A artifacts"-Block. 4-Phasen-Plan definiert (A=Lockdown done, B=RE-Spike in separatem 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) + 2. Pass Command-Ring-RE

• (behebt einen Laufzeit-Hook-Verhaltensbug + RE/Docs). Bug #2 („Feind-Tech lässt sich nach einmaliger Nutzung nicht mehr nach links auswählen"): RonsoManaHook.cpp senkte das OD-Anzeige-Gate von gateMin=100 (Vanilla „volle Leiste") auf 40 (= kRonsoSkillCosts[0], die Overdrive-Jump-Kosten). Mit Gate 100 kehrte nach einer einzigen Teilnutzung (Subvita 40 → Charge 60 < 100) jede Forcing-Funktion früh returnzurück und OD verschwand, bis die Leiste wieder 100 erreichte — im Widerspruch zum 0–255-Teilpool selbst. Per-Zeilen-Greyout (G3) blockiert weiterhin unbezahlbare Skills (Kosten > aktuelle Charge), daher ist das Senken des Gates sicher. Install-Banner hudSafe=19→hudSafe=21 korrigiert (das Log druckte die falsche Version, was die Diagnose erschwerte). 2nd-Pass-RE (nach RT2 hudSafe=20 FAIL): vollständige Dekompilierung von 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + ein Offline command.bin-Dump bewies: (a) die Laufzeit-Command-Zeile = 0x14-Header + File-Struct (Anker byte[25]=CharacterUser=file+5), also byte[22]=MenuFlgs usw.; (b) cmd282 (Feind-Tech) IST der OD-Ring-Header (MenuFlgs=0x11→header, MainMenu=True, ODCat=19, MenuLeft) — die alte „282→leaf cat4 +296"-Lesart war falsch; (c) in 79BB70-Loop-2 landet ein Header mit Misc2 MenuLeft (0x10) → dword[28]&0x1000 → im BSS-Array +40, NICHT +0 (sichtbare Header) — weshalb das Erzwingen von 282 nie im mittleren Ring erscheint; (d) resolve=-1 ist ein Red Herring (der Hauptring zeigt auch mit −1); (e) 797D60 case 3 liest einen Per-Actor-Blob (actor+0xF7C); (f) 79B500 schreibt actor[0x590]=save[+16] früh — unser Forcing in RefreshMenu_Shim (Prepare vor dem Trampolin) wird von diesem Store überschrieben/gewischt → erklärt, warum die Replikation des Save-Edits fehlschlug. .i64-Renames: 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ Kommentare auf 79BB70/797D60/79B500). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Nächster Schritt (Bug #1): ein Save-edited-vs-forced-Capture-Experiment zum Diff des exakten Deltas. Fix #2 RT2 Tests ausstehend. \

v2.123.0.2

v2.123.1.1BETAREVISIONLulu

Spira Reforge: Capture Cascade Phase B Handoff-Prompt (RE-Spike für das `capturable`-Bit)

• (Handoff-Doc, kein Code). Neues docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — vollständiger Prompt zum Starten eines dedizierten Chats für Capture Cascade Phase B. Lane-Identität: Jarvis-CAPTURE-RE. Mission: Offset+Bit capturable im m###.bin-Header via Hex-Diff lokalisieren (Sins Schuppenrest ↔ Schwarze Valfaris + 2 Validierungs-Stichproben) + optionaler IDA-CanCapture-Cross-Check. Deliverables: ≥4-Zeilen-Beweistabelle + RESULT-Doc + Plan-Doc-Update + Master-Cap-Cascade-Doc-Update + PORT_STATUS + eigener REVISION-Bump. Non-Goals explizit (implementiert keinen Writer, berührt keine Laufzeit, fängt nicht in-game). Ehrliche Schätzung 1.5–2h. Entblockt Cap-1 (Phase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISIONLulu

Spira Reforge: Capture Cascade duale Namenskonvention (interner Codename + spielerzugewandte Marke)

• (Design/Doc, kein Code). Halyson festgelegt 2026-06-16: das Feature behält zwei Namen mit unterschiedlichen Rollen. Intern (technische Docs, Changelogs, Schema-Felder, IDs, Prompts, Lane-Signaturen) bleibt Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Spielerzugewandt (Popups, Mod-README, Mod-Seite) = Yoke of Spira (EN) / Jugo de Spira (PT) — biblische/Yevon-Resonanz (Matthäus 11,30 „denn mein Joch ist sanft") spiegelt das theokratische Thema des Vanilla-FFX. F7-Conquests-Tab = The Yoke (EN) / O Jugo (PT). Standard-Popup-String: EN „Besaid is now under the yoke of Schwarze Valfaris" / PT „Besaid está sob o jugo de Schwarze Valfaris"; On-Capture-Battletext EN „Schwarze Valfaris has been tamed. Spira trembles." / PT „Schwarze Valfaris foi domado. Spira sente o tremor." Capture-Cascade-Doc erhielt §0 (Namenskonventions-Tabelle + Microsoft-Threshold/Redstone-Rationale). VISION_AND_ROADMAP §11 erhielt die 3-Kontext-Tabelle mit Cross-Link

v2.123.1.1

v2.123.2.0BETAPATCHLulu

Ronso-Mana: Root-Cause-FIX des Command-Rings — die Ring-Buffer-Basis wurde nie dereferenziert (Bug #1)

• (behebt einen Laufzeit-Hook-Verhaltensbug + RE). Der Befund: der Command-Ring-Buffer ist laufzeit-allokiert; sein absoluter Pointer lebt in einer BSS-Zelle (*(u32*)0x2310CD8). 7AEFC0/79BB70 machen mov edi,[cell] (DEREF) vor der Indizierung von +20592 (Sort-Scratch) / +1144*slot (Per-Actor-Ring). RonsoManaHook.cpp nutzte RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 roh, ohne Deref, und um 0x1000 daneben — also landeten ALLE Ring-Writes (Template, Per-Slot-Header +0, OD-Zeile +296) über hudSafe 11..21 in einem statischen BSS-Bereich, der nie der live angezeigte Buffer war. Das erklärt, warum nie eine BSS-Ring-Injektion erschien und warum CopyMenuTemplate_Shim (der 7AEFC0-Detour) immer früh zurückkehrte (delta = slotPtr - ringBase war nie ein Vielfaches von 1144). Fix: neue RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (die echte Pointer-Zelle, aus dem imm32 von mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() dereferenziert sie jetzt (*(u32*)(g_base+RVA), null-geprüft, wenn noch nicht allokiert). Damit schreiben PatchKimahriCommandRingUi (+0-Header), PatchKimahriMainMenuOverdriveRow (+296-OD) und CopyMenuTemplate_Shim (+296-post-sort) zum ersten Mal in den echten Ring. RE bewiesen (IDA): 7AD980 = sortiert ein Array nach Priorität (key=*(u8*)(GetCommandEntryById+92), Scratch=ring+20592); 7AEFC0 ruft es 8× auf (eine pro Kategorie), um den Per-Slot-Ring zu sortieren. .i64-Renames: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + Kommentar auf der Pointer-Zelle 0x2310CD8. DIAG (hudSafe=22): DumpKimahriRingState loggt ein Readback des echten +0/+296 bei G0-finalize, um zu bestätigen, ob der kodierte OD-cmd (0x311A) landet. PolyHook-Build PASS (10/10), Apply-Mode-Deploy. RT2 Needs Testing (Bug #1: OD im mittleren 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` LOKALISIERT (Phase-B-RE-Spike, nur Doc)

• (RE/Doc, keine Verhaltensänderung; auf v2.123.3.0 MINOR aus einer parallelen Lane verketten — diese REVISION ist rein Doc/RE und konkurriert nicht mit jenem MINOR). Capture-Cascade-Phase-B-Spike nur als Doc geliefert: das Byte, das capturable=true|false in jedem m###.bin steuert, wurde byte-präzise lokalisiert und mit 58 Stichproben validiert. Verdikt: Position = bytes[StatSheetPointer + 0x78] (wobei StatSheetPointer = uint32_le(bytes[0x0C])); Semantik = 0xFF (sbyte -1) bedeutet nicht-fangbar, 0x00..0x67 (sbyte 0..103) bedeutet fangbar (Slot-Index in der 104-Slot-Tabelle der Vanilla-Monster-Arena); Padding bytes[StatSheetPointer + 0x79] ist immer 0x00. Beweiskette gekreuzt mit (a) Legacy-Editor v1.4 FFXmon4.ini (Label „Capture index" als 16-Bit-Hex, 00FF = uncap), (b) aktuellem C#-Struct FfxLib/Monster/Monster_StatSheet.cs-Zeilen 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) Live-UI-Binding MonEditor_Control.axaml-Zeile 466 („Capture index (Arena)"), (d) vollständigem strukturellem Layout (MonsterHeaderFile-0x40-Byte-Header + StatSheet-Section + Monster_StatSheet-StatBlock, wo ArenaId bei Offset +0x64 relativ zum StatBlock sitzt, der bei section + 0x14 beginnt → dateirelativ +0x78). Beweis: 21/21 Fangbare stimmten mit erwartetem Slot überein (inkl. byte-exaktem Match mit FFXmon4.ini für m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 Boss-Uncap = 0xFF, 10/10 Dark Aeons (m334..m343) = 0xFF, 3/3 Der Richter-Einträge (m344..m346) = 0xFF. Wichtige operative Korrektur: die alte Annahme „DA live in m106..m113" war FALSCH — die echten DAs sind m334..m343 (bewiesen in FfxLib/Dictionaries/Monster_Dictionary.cs-Zeilen 343-356), mit Magus-Trio als 3 separaten Einträgen (m341/m342/m343). DOC-ONLY: In dieser Session wurde nichts in m###.bin/DLL/runtime/save/hook geschrieben. Nicht ausgeführt: IDA-Bestätigung des CanCapture()-Gatekeepers (optionaler Schritt 3 des Plans); Cross-Validierung gegen den Vanilla-FFX Extracted\-Baum (empfohlen, aber nicht blockierend — 58/58 modded stimmen bereits über die FFXmon4.ini-Cross-Referenz mit der Vanilla-Erwartung überein). Artefakte: docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md (vollständiges RESULT-Doc mit Phase-C-Writer-Rezept), 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 Zeilen), work/_capture_re_2026-06-16/capture_re_evidence_hexdump.txt. Das ursprüngliche PLAN-Doc erhielt ein BLOQUEIO-RESOLVIDO-Banner + korrigierte DA-IDs. PORT_STATUS.md bekam eine Zeile „Capture Cascade Cap-1 — capturable bit located" als Precisa Testar in-game (Phase C writer). Cap-1-Writer (Phase C, nächste Session) schreibt 1 Byte pro Monster, während die Byte-Identität der 8 angrenzenden Identitätsfelder erhalten bleibt. [previous: v2.123.3.0 (parallele Lane; ihr Changelog-Eintrag landet, wenn sie liefern)]

v2.123.4.0BETAPATCHLulu

Nul Ward: teach/menu-surface RE VERDICT + FIX des menu-bound Hooks (er patchte das falsche `cmp 320`)

• (behebt einen Verhaltensbug in NulWardTeachHook + RE auf der echten .i64 bewiesen; PATCH-Bump → Revision resets; vorheriger HEAD v2.123.3.1 war eine REVISION einer parallelen Lane). Vollständiger RE-Pass (idalib-MCP auf der echten FFX_recon.i64), der beantwortet, ob das Lehren von Radiant(320)/Umbral(321) über das Sphere-Grid + eine gewachsene command.bin end-to-end funktioniert. BEWIESENE Kette: (1) FFX_GrantCommandToCharacter@0x785D10 leitet id≥96 an die parteiweite Bank g_PartyWideCommandBank@0x11307FC — 16 Wörter/256 Bits = ids 96..351; Radiant=word14 bit0, Umbral=word14 bit1; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEEDET die ganze Bank in actor+0x670 (Copy-Loop endet bei g_CmdAggregateAvailArrays@0x113081C → Bank = 16 Wörter); (3) FFX_Btl_IsCommandAvailable@0x79AD40 liest actor-Wort 818+id/16 (id320→byte 0x68C bit0) — konsistent; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 ruft grant(char, node.LearnedMove, 1) → ein Node mit LearnedMove=0x3140/0x3141 lehrt es; (5) Persistenz via FFX_IsCommandLearnedPersistent@0x7850E0 liest dasselbe Bit. BUG GEFUNDEN & FIXIERT: BuildActorCommandMenu hat 3 cmp r32,140h (zwei 81 FE=esi auf den Aggregate-Loops, ein 81 FF=edi auf dem PLACEMENT-Loop, der die id in das White-Magic-Untermenü einfügt). Nur der Placement-Compare kontrolliert, ob 320/321 ins Menü gelangen; der alte NulWardTeachHook patchte den ersten Match (81 FE, ein No-op fürs Surfacing). FIX: Er patcht jetzt alle cmp r32,140h→0x142 (PolyHook-Rebuild PASS). Dokumentierte RT2-Risiken: (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 ist eine Range-Tabelle mit Fallback auf cmd 0 — die gewachsene command.bin muss den Bereich abdecken, der 320/321 umfasst (sonst löst Radiant zu cmd 0 auf); (b) Persistenz hängt davon ab, dass die ply_save-Limit/Special-Map breit genug ist, um Bit 224/225 (word 14) abzudecken. Design: id≥96 = parteiweit (die ganze Party lernt es), nicht pro Char (96-Bit-Cap). Renames+Comments auf die echte .i64 angewendet (FFX_Btl_IsCommandAvailable, FFX_Btl_InitPartyWideCommandBank, FFX_Btl_PrepareSaveCommandState, FFX_Btl_BuildAggregateChildList, g_PartyWideCommandBank, g_PerCharCmdMenuState usw.). 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: PERSISTENTER Gauge-full-PIN (`max:=charge`) — behebt „kann nicht mal nach LINKS in Overdrive, außer die Leiste ist voll"

• (behebt einen Laufzeit-Hook-Verhaltensbug + RE). Der Befund (durch Log + Dekompilierung bewiesen): FFX koppelt „Overdrive nutzbar" an eine volle Leiste (charge==max) und prüft es PRO-FRAME im HUD/Menü-Renderer — außerhalb unserer Hooks. Der hudSafe=23-transiente Spoof setzte max:=charge um jeden Trampoline, stellte aber max=255 direkt danach wieder her (EndKimahriMaxSpoof), sodass der Frame, in dem der Ring gezeichnet wird, max=255 sah (Leiste nicht voll) → Overdrive ausgeblendet / LEFT blockiert. RT2-Log-Beweis (hudSafe=23): G0 menu charge=100 max=100 (der Spoof funktionierte während des Builds) und OD erschien trotzdem nie; IsOdReady ... vanilla=1 ->1 (die 0x590-Bits waren gesetzt, sogar von Vanilla) und es war trotzdem blockiert. RE in diesem Pass (idalib-MCP): 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — beide erzwungen und =1, NICHT das Gate; 792AB0 (FFX_Btl_BattleMenuInputDispatch) baut den kind=12-OD-Ring, wenn 79AF70 (der OD-Ring existiert also); 799AD0/799D60/7996E0/799830 sind Target-Mask-Resolver, nicht das OD-full-Gate. Schlussfolgerung: Das Live-Gate ist der Per-Frame-charge==max-Vergleich im Renderer — außerhalb der Reichweite eines transienten Spoofs. Fix: ApplyKimahriRuntimePoolMax pinnt jetzt persistent max:=charge, solange charge>=gateMin (die Leiste liest für jeden Per-Frame-Check als 100% voll, während sein Command-Menü offen ist; die ATB/CTB ist pausiert während der Command-Eingabe, also geht kein Overdrive-Gewinn verloren); unterhalb der Schwelle gibt es den echten Pool (255) zurück, damit die Leiste Richtung 0–255 nachfüllt. Der transiente Begin/End-Spoof ist eingestellt (No-ops); der Dispatch-Shim ruft jetzt den persistenten Pin. Bekannter Tradeoff (RT2): die Leiste liest voll, während OD nutzbar ist; OD-Gewinn kann pausieren, während die Charge im nutzbaren Band sitzt (bei RT2-Gewinn-Stall neu bewerten — den Pin auf Menu-only beschränken). PolyHook-Build PASS (10/10), Apply-Mode-Deploy (SHA B092B4C6). RT2 Needs Testing (gehe LEFT + nutze Feind-Tech bei Teilcharge). 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: Bereich BEWIESEN (kein EXE-Patch) + command.bin-Encoding-FIX im Editor + Offline-Verifier LearnedMove

• (behebt einen SphereGridExplorer-Editor-Verhaltensbug + neuen Offline-Beweis/Verifier + RE). DLL unberührt (die Ronso-Mana-lane nutzt sie) — nur C#/editor/IDA; RT2 #1 OFFLINE ELIMINIERT: RE bewies, dass FFX_Kernel_LoadFileToTable@0x781E00 (case 0 "command") command.bin verbatim in einen globalen Pointer lädt (g_CommandKernelTable@0x112A92C, Full-File-memcpy) — keine Range-Synthese. FFX_Table_GetEntryByIdRange@0x7AB890 liest den Range-Header direkt aus den Datei-Bytes und mappt exakt auf 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. Da die gewachsene command.bin EntryCount-1=321 schreibt, liegen ids 320/321 ∈ [0,321] → lösen zu exakt den angehängten Radiant/Umbral-Zeilen auf. Kein EXE/DLL-Patch. Neuer CommandKernelLookupVerifier (FfxLib/Ability) spielt die exakte Engine-Mathematik gegen die gewachsenen Bytes ab und ist in das --nul-ward-static-Gate eingebunden (engine_lookup_resolves-Check: Offline-Beweis, dass GetCommandEntryById(320/321) NICHT den cmd0-Fallback trifft). Editor-FIX (SphereGridExplorer): das LearnedMove-Dropdown speicherte die rohe id (0x0140), aber on-disk ist die kodierte id (0x3000|id) — empirisch bewiesen durch SphereGridRt2Lab (Panzerbrecher in panel.bin = 0x3012) und gefordert durch das (cmd & 0xFFFFF000)==0x3000-Gate des Grants. Das Dropdown emittiert jetzt 0x3000|id (Radiant→0x3140, Umbral→0x3141) und löst Namen mit Maskierung & 0xFFF auf, der Nutzer die Wards auf dem Sphere Grid platzieren kann und sie tatsächlich lehren (vorher speicherte es und der Grant lehnte ab 0x0140). .i64-Renames: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + bewiesene Kommentare auf 0x781E00/0x7AB890/0x790AE0 (via idalib_save gespeichert). C#-Builds PASS (0 Fehler). 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-Finalisierung-Balistica: Phase-0-Kickoff (Docs-Abgleich + Legacy-Kommentar-Fix + Variant-UNVERIFIED-Badge)

• (Docs + RE/Ehrlichkeits-Annotation; kein neues Feature; kein Verhaltens-Bump). Plan persistiert unter .cursor/plans/aurora_balistica.plan.md (10 Phasen, Halyson-bestätigter Scope A+B: 5 aktive RT2s + IDA-W2S-Spike + Variant-Selector-IDA-Spike). Diese REVISION liefert nur Phase 0 (Docs-Abgleich vor der Probe-Instrumentierung). Vier Edits: (1) PORT_STATUS.md-Zeile „Aurora Chamber" — Honestidade-Text korrigiert: war transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, jetzt reflektiert es den IDA-Beweis von 2026-06-05 (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 oben — neuer Block Atualizacao 2026-06-16 (Aurora finalizacao balistica), der den realen Aurora-Zustand gegen A15 abgeglichen und die bestätigte RT2-Reihenfolge festhält (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, dann IDA-Spike). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — JSDoc-Header (Zeilen 9-10) korrigiert: war RAW battle-local - design-only/UNCALIBRATED, jetzt 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 (angezeigt in SceneDetail, wenn _resolver.ResolveScenes(MapKey) mehr als 1 Variante zurückgibt) hängt jetzt runtime selector UNVERIFIED neben die _a/_b/_c-Liste, damit Nutzer wissen, dass die Chamber die vom Katalog gewählte Variante rendert, während der echte Selektor (Story-Flag → Variante) noch nicht RE-bewiesen ist — siehe A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. Berührt nicht: Probe, Writer, Offline-Gates, FfxHooksDll. Nächster (Phase 1): aurora-calib-v2 in RuntimeTools/FfxDinput8Probe/ctl/Program.cs implementieren mit CSV/JSON-Ausgabe (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 (nur Docs + UI-String)

v2.123.5.0