WakkaBETA

更新 2.123

2026/6/16

v2.123.0.0BETAMINOR

Wakka

Arena+ Multi Dark Aeon 進度附屬檔案 + 讀寫器於 FfxHooksDll 中

：(a) 新增附屬檔案 mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json}（機密文件第15節結構 v1），包含 flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence 以及選用的 tier_lock_state{}（LOCKED/READY/CLEARED）；以目錄中的 progress_flag 作為鍵值（arena.dark.<slug>）；README 文件說明瞭使用規則與目錄<->附屬檔案對應關係。(b) 新增模組 RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — best-effort JSON 讀寫器（無相依性），ArenaProgress_Initialize/IsRowCleared/RecordCleared 由 arena_plus_progress.flag 閘門控制（預設關閉），搜尋路徑 $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> 備用 <DllDir>/spira-arena-progress.json。透過 .tmp + MoveFileEx 實現原子性持久化。環境變數 FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 讓開發者可手動為 UI 測試植入旗標。(c) dllmain.cpp 在 ArenaProgress_Initialize 中於目錄覆蓋後呼叫 InstallHooks。(d) 真正的勝利偵測仍為 NOT 接線 — 保留為有文件記載的 TODO；計畫第六階段承認此分裂，且公開的 API ArenaProgress_RecordCleared(flag, note) 已準備好供未來的 battleEnd 掛鉤消費者使用。PolyHook 建置 PASS 10/10 cpp。In-game RT2 需要 Test（經由 FFXHOOKS_ARENAPLUS_FAKE_CLEAR）

v2.122.0.1

v2.123.0.1BETAREVISION

Wakka

鬥技場+多重暗黑 Aeon：五重拉伸配方 + dry-run PASS

（配方/文件，無出貨行為變更）。計畫階段7（拉伸）。新的 RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + 配方文件 mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md 涵蓋 Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut 於 nagi05_70（Dark Yojimbo 別名，原版 monPos 中的5個（共6個），插槽5未使用）。管線 ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS 針對 nagi05_70.bin.spiraforge.bak：區塊2 = 5 角色於 0x18A4（16 位元組），區塊3 = 6 個 monLive 於 0x1B04（96 位元組，position-only），re-read 確認插槽。目錄行 dark-penta-elemental-five 已更新：id renamed，token_mode blocked->alias（別名在技術上是合法的），evidence 備註 dry-run PASS，rt2_status 保持 blocked（無 in-game 證據）——僅 RT0 byte-safety 已證實。NOT 是否將 五重提升為功能：保持拉伸直到四重 RT2 PASS + 記錄的 in-game 嘗試經由 _RT2_CHECKLIST.md。4路提升計畫（PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash）在配方 MD 中

v2.123.0.0

v2.123.0.2BETAREVISION

Lulu

Spira 重鑄：Capture 串聯階段 A 封鎖 — 8 項決策已鎖定 + 3 件準備用成品

（設計/文件/綱要，無程式碼）。Halyson 規劃會議 2026-06-16 關閉了 Capture 串聯文件（v2.122.0.1）§7 中所有 8 項未決決策：D1 Magus Sisters → Mushroom Rock Road（非嘎嘎扎特——對米亨行動與 3 個悲劇祈之子的反常懷舊，一個 mid-early 區域，在 T7 終局時翻轉）；D2 怪物圖鑑 F7 → 專用分頁 + post-battle 彈出視窗，並為每個捕獲的 GPT-generated 預留 DA 美術圖插槽；D3 巡邏 non-fleeable；D4 掉落物 = 1× 主題碎片 + 1× 稀有消耗品；D5 捕獲 計入擊殺++（解鎖原版 1v1 AND SIN 階梯）；D6 無確認提示；D7 safe-zone 同時被 T7 怪物羣與 DA 巡邏隊尊重；D8 增益效果僅在首次進入 post-capture 時宣告。階段 A 交付 3 件成品：(a) 側車綱要 mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1（DA 捕獲 + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — de-conflicted 搭配來自 Jarvis-ARENA 的 spira-arena-progress.json 之 v2.123.0.0 側車，後者擁有競技場列清除權）；(b) 區域地圖 mods/Spira Reforge/arena/dark-aeon-region-map.json（8 個 DA → 標準區域 + 巡邏子區域 + 安全區域 + 敘事筆記）；(c) 階段 B RE 衝刺計畫 docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md（1–2 小時攻略手冊，透過十六進位差異比對 + 可選的 capturable 找到 m### 標頭中的 IDA 位元）。主文件已更新 §7（封鎖）+ §4（最終地圖）+ §13（成品參考）。VISION_AND_ROADMAP §11 新增了「階段 A 成品」區塊。已定義 4 階段計畫（A=封鎖完成，B=RE 衝刺在獨立聊天室中，C=Cap-1 寫手在 v0.5 中，D=RT2 試行）

v2.123.0.1

v2.123.1.0BETAPATCH

Lulu

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 （原版的"滿 條"）降低爲 40（= kRonsoSkillCosts[0], the Overdrive Jump 每一個強制函數 returned early and OD vanished until the bar refilled to 100 — contradicting the 0–255 partial pool itself. Per-row greyout (G3）仍然會阻擋無法負擔的技能（消耗當前充能），因此降低閘門是安全的。安裝橫幅修復了 hudSafe=19→hudSafe=21 （日誌打印了錯誤的版 本，阻礙了診斷）。 RE (after RT2 hudSafe=20 FAIL完整反 編譯 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + 一個離線 command.bin 轉儲證明：（a）運行時命令行 = 0x14 （錨 點 byte[25]=CharacterUser=file+5), so byte[22]=MenuFlgs etc; (b) cmd282 (Ronso Rage) IS the OD （ (MenuFlgs=0x11→標頭, MainMenu=True, ODCat=19, MenuLeft）—— 舊的"282→le af cat4 +296"解讀是錯誤的；（c）在 79BB70 loop-2, a header with Misc2 MenuLeft (0x10) 的標頭 → dword[28]&0x1000 → lands in BSS + 40 NOT +0 (visible headers) — which is why forcing 282 available never shows it in the middle ring; (d) resolve=-1 是一個紅鯡魚（主 環即使在 -1 時 也會顯示）；（e） 797D60 case 3 讀取一個 per-actor 數據塊（actor+0xF7C）；（f） 79B500 提前寫入 actor[0x590]=save[+16] —— 我們在 RefreshMenu_Shim 中的強制（在蹦 牀之前準備）被 該存儲覆蓋/抹除 save-edit failed. .i64 重新命名： 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState （加上對 79BB70/797D60/79B500的註釋）。文檔： 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 需要測 試。上一個： v2.123.0.2]

v2.123.1.1BETAREVISION

Lulu

Spira 重鑄: Capture 級聯階段 B 交接提示 (RE 針對 `capturable` 位元的技術探針)

(交接文件, 無程式碼). 新的 docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — 用於啟動專屬聊天的完整提示, 針對 Capture 級聯階段 B. 工作線 identity: Jarvis-CAPTURE-RE. 任務: 透過十六進位差異比對 (capturable ↔ m###.bin + 2 個驗證樣本) 在 Sinscale 標頭中定位偏移量+位元 Dark Valefor, 加上可選的 IDA CanCapture cross-check. 交付物: 至少4行的證據表格 + RESULT 文件 + plan-doc 更新 + 主要 Cap 級聯文件更新 + PORT_STATUS + 其自身的 REVISION 版本提升. Non-goals 明確 (NOT 是否實作寫入器, NOT 是否觸及執行時期, NOT 是否擷取 in-game). 誠實估計 1.5–2小時. 解除封鎖 Cap-1 (階段 C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISION

Lulu

Spira 重鑄：Capture Cascade 雙重命名慣例（內部代號 + player-facing 品牌）

（設計/文件，無代碼）。Halyson 鎖定於 2026-06-16：該功能保留 兩個名稱，各自具有不同角色。內部（技術文件、變更日誌、結構欄位、ID、提示、工作線 signatures）保持為 Capture Cascade（Cap-1/2/3、dark_aeons.captured.<id>、capture_cascade.patrol_kills、arena.dark.<id>）。Player-facing（彈出視窗、模組 README、模組頁面）= 之軛 Spira（EN）/ Jugo de Spira（PT）— 聖經/耶馮共鳴（馬太福音 11:30「因為我的軛是容易的」）呼應原始版 FFX 的神權主題。F7 征服分頁 = 軛（EN）/ O Jugo（PT）。預設彈出字串：EN「Besaid 現在處於軛之下，受 Dark Valefor 支配」/ PT「Besaid está sob o jugo de Dark Valefor」；on-capture 戰鬥文字 EN「Dark Valefor 已被馴服。Spira 顫抖。」/ PT「Dark Valefor foi domado. Spira sente o tremor.」Capture Cascade 文件新增 §0（命名慣例表格 + Microsoft Threshold/Redstone 理由）。VISION_AND_ROADMAP §11 新增了包含 cross-link 的三情境表格

v2.123.1.1

v2.123.2.0BETAPATCH

Lulu

Ronso Mana: root-cause FIX 工作

(fixes a runtime-hook behavior bug + RE發現： command-ring buffer is runtime-allocated; its absolute pointer lives in a BSS cell (*(u32*)0x2310CD8)。 7AEFC0/79BB70 在索引 mov edi,[cell] (DEREF) before indexing +20592 環) 之前執行 +1144*slot (per-actor )。 RonsoManaHook.cpp 使用了 RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 raw, without the deref, and off by 0x1000 — 所以 ALL ring writes (template, per-slot header +0, OD row +296) 跨越 hudSafe 11..21 landed in a static BSS 從來不是 實際顯示的緩衝區 BSS ring injection ever appeared, and why CopyMenuTemplate_Shim ( 7AEFC0 detour) always early-returned (delta = slotPtr - ringBase 從來不是 11 44 的倍數) 。修復：新的 RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (實際指標儲存單元，取自 mov edi,[..]@0x7AEFC8的 imm32) + BattleCommandRingUiBase() 現在解引 用它 ( 未分配時為*(u32*)(g_base+RVA), null-checked when not yet allocated). With this, PatchKimahriCommandRingUi (+0 標頭)、 PatchKimahriMainMenuOverdriveRow (+296 OD) and CopyMenuTemplate_Shim (+296 post-sort實際 real 環。 RE proven (IDA): 7AD980 = 按優先級排序一個陣列 (key=*(u8*)(GetCommandEntryById+92), 暫存區=ring+20592); 7AEFC0 calls it 8× (one per category) to sort the per-slot ring. .i64 重新命名: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + 關於指標儲存單元 0x2310CD8的註釋。 DIAG (hudSafe=22): DumpKimahriRingState 記錄對實際 +0/+296 在 G0-finalize to confirm whether the encoded OD cmd (0x311A) lands. PolyHook build PASS (10/10), apply-mode deploy. RT2 需要測試 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.1BETAREVISION

Seymour

Spira 重鑄：Capture 級聯 Cap-1 — `capturable` 位元於 `m###.bin` LOCATED（階段 B RE 尖峯，doc-only）

（RE/文檔，無行為變更；建立在來自平行工作線的 v2.123.3.0 MINOR 之上 — 此 REVISION 純屬文檔/RE，且不與該 MINOR 衝突）。Capture 級聯階段 B 尖峯交付 doc-only：控制每個 capturable=true|false 中 m###.bin 的位元組已定位於 byte-precise，並以 58 個樣本 驗證。結論： 位置 = bytes[StatSheetPointer + 0x78]（其中 StatSheetPointer = uint32_le(bytes[0x0C])）；語義 = 0xFF（sbyte -1）表示不可捕獲，0x00..0x67（有符號位元組 0..103）表示可捕獲（原版 Monster Arena 之 104 插槽表格中的插槽索引）；填充 bytes[StatSheetPointer + 0x79] 始終為 0x00。證據鏈交叉驗證 (a) 舊版編輯器 v1.4 FFXmon4.ini（標籤「Capture 索引」以 16 位元十六進位表示，00FF = 不可捕獲），(b) 當前 C# 結構體 FfxLib/Monster/Monster_StatSheet.cs 第 49-50 行（[Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding），(c) 即時 UI 綁定 MonEditor_Control.axaml 第 466 行（「Capture 索引（競技場）」），(d) 完整結構佈局（MonsterHeaderFile 0x40-位元組標頭 + StatSheet 區段 + Monster_StatSheet StatBlock，其中 ArenaId 位於相對於起始於 +0x64 之 StatBlock 的偏移量 section + 0x14 處 → file-relative +0x78）。證明：21/21 可捕獲者匹配預期插槽（包括 byte-exact 與 FFXmon4.ini 匹配於 m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56），16/16 頭目不可捕獲 = 0xFF，10/10 暗黑召喚獸（m334..m343）= 0xFF，3/3 Penance 條目（m344..m346）= 0xFF。重要操作修正： 舊有的「DA 存在於 m106..m113」假設是 WRONG — 真正的暗黑召喚獸是 m334..m343（在 FfxLib/Dictionaries/Monster_Dictionary.cs 第 343-356 行中證明），而 Magus Sisters 為 3 個獨立條目（m341/m342/m343）。DOC-ONLY：在此工作階段中未寫入任何內容至 m###.bin/DLL/runtime/save/hook。未執行：IDA 確認 CanCapture() 的把關者（PLAN 的可選步驟 3）；cross-validation 對照原版 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（平行工作線；他們的變更日誌條目將在發佈時落地）]

v2.123.4.0BETAPATCH

Lulu

Nul Ward: 教導/menu-surface RE VERDICT + FIX 的 menu-bound 掛鉤（它原本在修補錯誤的 `cmp 320`）

（修正 NulWardTeachHook + RE 中的一個行為錯誤，已在真實的 .i64 上驗證；PATCH 提升 → 版本重置；先前的 HEAD v2.123.3.1 是一個 parallel-lane REVISION）。完整的 RE 通過（idalib MCP 在真實的 FFX_recon.i64 上）回答是否透過幻光球盤 + 一個成長的 /Umbral 教導 Radiant(320)command.bin(321) 能運作 end-to-end。 PROVEN 鏈： (1) FFX_GrantCommandToCharacter@0x785D10 將 id≥96 路由到 party-wide 庫 g_PartyWideCommandBank@0x11307FC — 16 字組/256 位元 = id 96..351；Radiant=字組14位元0，Umbral=字組14位元1；(2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEEDS 整個庫到角色+0x670（複製迴圈結束於 g_CmdAggregateAvailArrays@0x113081C → 庫 = 16 字組）；(3) FFX_Btl_IsCommandAvailable@0x79AD40 讀取角色字組 818+id/16（id320→位元組 0x68C 位元0）— 一致；(4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 案例21 呼叫授予(角色, node.LearnedMove, 1) → 一個 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.1BETAPATCH

Lulu

Ronso Mana hudSafe=24: PERSISTENT gauge-full PIN (`max:=charge`) — fixes "can't even go LEFT into Overdrive 工作

(fixes a runtime-hook behavior bug + RE發現（經由 日誌+反編 譯證明）： FFX couples "Overdrive 滿量表 (charge==max) 以及 re-checks it PER-FRAME in the HUD耦合 — 在我們鉤子之外。 hudSafe=23 暫時性偽造在每個蹦牀周圍設置了 max:=charge ，但立即 還原了 max=255 right after (EndKimahriMaxSpoof)，因此繪製環的那一幀看到 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 ；; 792AB0 (FFX_Btl_BattleMenuInputDispatch) 在 kind=12 OD ring when 79AF70 環 OD ring exists); 799AD0/799D60/7996E0/799830 是 target-mask resolvers, not the OD-full gate. Conclusion: the live gate is the per-frame charge==max 比較 — 暫 時性偽造無法觸 及。修復： ApplyKimahriRuntimePoolMax 現在持 續固定 max:=charge ，當 charge>=gateMin (the gauge reads 100% full for every per-frame check while his command menu is up; the ATB/CTB 暫停，因此不會損失超量 驅動累積）；低於閾值時 ，它歸還真實池 (25 5)，讓量表重新填充至0–255。暫時性 Begin/End 偽造已退役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 需要測試 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.0BETAPATCH

Lulu

虛無護盾 grid-teach: command.bin 範圍 PROVEN (無 exe 補丁) + LearnedMove 編碼 FIX 在編輯器中 + 離線驗證器

(修復了一個 SphereGridExplorer 編輯器行為錯誤 + 新的離線證明/驗證器 + RE)。DLL 保持不變 (隆索 Mana 工作線 is 使用它) — 僅 C#/editor/IDA。RT2 風險 #1 ELIMINATED 離線: RE 證明 FFX_Kernel_LoadFileToTable@0x781E00 (情況 0 "command") 將 command.bin 逐字載入到一個全域指標中 (g_CommandKernelTable@0x112A92C, full-file memcpy) — 無範圍合成。FFX_Table_GetEntryByIdRange@0x7AB890 直接從檔案位元組 讀取範圍標頭，精確對應到 EntryListFile: numRanges=int16@0(=簽章=1), lo=PreviousFileCount@8(=0), hi=(EntryCount-1)@10, stride=EntrySize@12(0x60), base=EntryTableFileOffset@16(0x14); record = file + 0x14 + id*0x60。由於增長的 command.bin 寫入 EntryCount-1=321，ID 320/321 ∈ [0,321] → 解析為恰好附加的光輝/暗影行。無 exe/DLL 補丁。 新的 CommandKernelLookupVerifier (FfxLib/能力) 重現引擎對增長位元組的準確數學計算，並接入 --nul-ward-static 閘門 (engine_lookup_resolves 檢查: 離線證明 GetCommandEntryById(320/321) 確實 NOT 命中 cmd0 回退)。編輯器 FIX (SphereGridExplorer): LearnedMove 下拉選單儲存了原始 ID (0x0140)，但 on-disk 是 編碼後 的 ID (0x3000|id) — 由 SphereGridRt2Lab 實證證明 (Armor Break 在 panel.bin 中 = 0x3012) 且為授予的 (cmd & 0xFFFFF000)==0x3000 閘門所需。下拉選單現在輸出 0x3000|id (光輝→0x3140, 暗影→0x3141) 並解析遮蔽 & 0xFFF 的名稱，因此 使用者可以將護盾放置在晶球盤上，且它們實際上會教導 (之前它儲存了 0x0140 且授予拒絕了它)。.i64 重新命名: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + 關於 0x781E00/0x7AB890/0x790AE0 的經驗證註解 (經由 idalib_save 儲存)。C# 建置 PASS (0 個錯誤)。文件: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISION

Yuna

Aurora 最終化彈道學：第 0 階段啟動（文件核對 + 舊註解修正 + 變體 UNVERIFIED 徽章）

（文件 + RE/誠實註解；無新功能；無行為變動）。計畫持續於 .cursor/plans/aurora_balistica.plan.md（10 個階段，Halyson-confirmed 範圍 A+B：5 個活躍 RT2 + IDA W2S 尖峯 + variant-selector IDA 尖峯）。此 REVISION 僅提供第 0 階段（在探針儀器化之前的文件核對）。四項編輯： (1) PORT_STATUS.md「Aurora 室」列 — Honestidade 文字已修正：原為 transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis，現反映 2026-06-05 IDA-proof（X/Z = identity，Y residual RT2 pending，參考 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 頂部 — 新增區塊 Atualizacao 2026-06-16 (Aurora finalizacao balistica)，總結真實 Aurora 狀態，與 A15 核對 + 確認的 RT2 順序（azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo，然後 IDA 尖峯）。(3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — JSDoc 標頭（第 9-10 行）已修正：原為 RAW battle-local - design-only/UNCALIBRATED，現為 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（當 SceneDetail 傳回超過 1 個變體時，顯示在 _resolver.ResolveScenes(MapKey) 中）現在會在 runtime selector UNVERIFIED 列表旁附加 _a/_b/_c，讓使用者知道 Chamber 會渲染目錄所選的任何變體，而真正的選擇器（story-flag -> 變體）尚未被 RE-proven — 參見 A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md。不涉及： 探針、寫入器、離線閘門、FfxHooksDll。下一步（第 1 階段）： 在 aurora-calib-v2 中實現 RuntimeTools/FfxDinput8Probe/ctl/Program.cs，並帶有 CSV/JSON 輸出（殘餘 identity_dx/dy/dz/rms、flipz_*、yaw180_*、winner 列舉、height_0x534、路線 + 戰鬥 ID）— 規格在 docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md 中。第 0 階段 RT2：N/A（docs-only + UI 字串）

v2.123.5.0

返回更新列表

WakkaBETA

更新 2.123

2026/6/16

v2.123.0.0BETAMINOR

Wakka

Arena+ Multi Dark Aeon 進度附屬檔案 + 讀寫器於 FfxHooksDll 中

：(a) 新增附屬檔案 mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json}（機密文件第15節結構 v1），包含 flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence 以及選用的 tier_lock_state{}（LOCKED/READY/CLEARED）；以目錄中的 progress_flag 作為鍵值（arena.dark.<slug>）；README 文件說明瞭使用規則與目錄<->附屬檔案對應關係。(b) 新增模組 RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — best-effort JSON 讀寫器（無相依性），ArenaProgress_Initialize/IsRowCleared/RecordCleared 由 arena_plus_progress.flag 閘門控制（預設關閉），搜尋路徑 $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> 備用 <DllDir>/spira-arena-progress.json。透過 .tmp + MoveFileEx 實現原子性持久化。環境變數 FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 讓開發者可手動為 UI 測試植入旗標。(c) dllmain.cpp 在 ArenaProgress_Initialize 中於目錄覆蓋後呼叫 InstallHooks。(d) 真正的勝利偵測仍為 NOT 接線 — 保留為有文件記載的 TODO；計畫第六階段承認此分裂，且公開的 API ArenaProgress_RecordCleared(flag, note) 已準備好供未來的 battleEnd 掛鉤消費者使用。PolyHook 建置 PASS 10/10 cpp。In-game RT2 需要 Test（經由 FFXHOOKS_ARENAPLUS_FAKE_CLEAR）

v2.122.0.1

v2.123.0.1BETAREVISION

Wakka

鬥技場+多重暗黑 Aeon：五重拉伸配方 + dry-run PASS

（配方/文件，無出貨行為變更）。計畫階段7（拉伸）。新的 RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + 配方文件 mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md 涵蓋 Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut 於 nagi05_70（Dark Yojimbo 別名，原版 monPos 中的5個（共6個），插槽5未使用）。管線 ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS 針對 nagi05_70.bin.spiraforge.bak：區塊2 = 5 角色於 0x18A4（16 位元組），區塊3 = 6 個 monLive 於 0x1B04（96 位元組，position-only），re-read 確認插槽。目錄行 dark-penta-elemental-five 已更新：id renamed，token_mode blocked->alias（別名在技術上是合法的），evidence 備註 dry-run PASS，rt2_status 保持 blocked（無 in-game 證據）——僅 RT0 byte-safety 已證實。NOT 是否將 五重提升為功能：保持拉伸直到四重 RT2 PASS + 記錄的 in-game 嘗試經由 _RT2_CHECKLIST.md。4路提升計畫（PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash）在配方 MD 中

v2.123.0.0

v2.123.0.2BETAREVISION

Lulu

Spira 重鑄：Capture 串聯階段 A 封鎖 — 8 項決策已鎖定 + 3 件準備用成品

（設計/文件/綱要，無程式碼）。Halyson 規劃會議 2026-06-16 關閉了 Capture 串聯文件（v2.122.0.1）§7 中所有 8 項未決決策：D1 Magus Sisters → Mushroom Rock Road（非嘎嘎扎特——對米亨行動與 3 個悲劇祈之子的反常懷舊，一個 mid-early 區域，在 T7 終局時翻轉）；D2 怪物圖鑑 F7 → 專用分頁 + post-battle 彈出視窗，並為每個捕獲的 GPT-generated 預留 DA 美術圖插槽；D3 巡邏 non-fleeable；D4 掉落物 = 1× 主題碎片 + 1× 稀有消耗品；D5 捕獲 計入擊殺++（解鎖原版 1v1 AND SIN 階梯）；D6 無確認提示；D7 safe-zone 同時被 T7 怪物羣與 DA 巡邏隊尊重；D8 增益效果僅在首次進入 post-capture 時宣告。階段 A 交付 3 件成品：(a) 側車綱要 mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1（DA 捕獲 + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — de-conflicted 搭配來自 Jarvis-ARENA 的 spira-arena-progress.json 之 v2.123.0.0 側車，後者擁有競技場列清除權）；(b) 區域地圖 mods/Spira Reforge/arena/dark-aeon-region-map.json（8 個 DA → 標準區域 + 巡邏子區域 + 安全區域 + 敘事筆記）；(c) 階段 B RE 衝刺計畫 docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md（1–2 小時攻略手冊，透過十六進位差異比對 + 可選的 capturable 找到 m### 標頭中的 IDA 位元）。主文件已更新 §7（封鎖）+ §4（最終地圖）+ §13（成品參考）。VISION_AND_ROADMAP §11 新增了「階段 A 成品」區塊。已定義 4 階段計畫（A=封鎖完成，B=RE 衝刺在獨立聊天室中，C=Cap-1 寫手在 v0.5 中，D=RT2 試行）

v2.123.0.1

v2.123.1.0BETAPATCH

Lulu

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 （原版的"滿 條"）降低爲 40（= kRonsoSkillCosts[0], the Overdrive Jump 每一個強制函數 returned early and OD vanished until the bar refilled to 100 — contradicting the 0–255 partial pool itself. Per-row greyout (G3）仍然會阻擋無法負擔的技能（消耗當前充能），因此降低閘門是安全的。安裝橫幅修復了 hudSafe=19→hudSafe=21 （日誌打印了錯誤的版 本，阻礙了診斷）。 RE (after RT2 hudSafe=20 FAIL完整反 編譯 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + 一個離線 command.bin 轉儲證明：（a）運行時命令行 = 0x14 （錨 點 byte[25]=CharacterUser=file+5), so byte[22]=MenuFlgs etc; (b) cmd282 (Ronso Rage) IS the OD （ (MenuFlgs=0x11→標頭, MainMenu=True, ODCat=19, MenuLeft）—— 舊的"282→le af cat4 +296"解讀是錯誤的；（c）在 79BB70 loop-2, a header with Misc2 MenuLeft (0x10) 的標頭 → dword[28]&0x1000 → lands in BSS + 40 NOT +0 (visible headers) — which is why forcing 282 available never shows it in the middle ring; (d) resolve=-1 是一個紅鯡魚（主 環即使在 -1 時 也會顯示）；（e） 797D60 case 3 讀取一個 per-actor 數據塊（actor+0xF7C）；（f） 79B500 提前寫入 actor[0x590]=save[+16] —— 我們在 RefreshMenu_Shim 中的強制（在蹦 牀之前準備）被 該存儲覆蓋/抹除 save-edit failed. .i64 重新命名： 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState （加上對 79BB70/797D60/79B500的註釋）。文檔： 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 需要測 試。上一個： v2.123.0.2]

v2.123.1.1BETAREVISION

Lulu

Spira 重鑄: Capture 級聯階段 B 交接提示 (RE 針對 `capturable` 位元的技術探針)

(交接文件, 無程式碼). 新的 docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — 用於啟動專屬聊天的完整提示, 針對 Capture 級聯階段 B. 工作線 identity: Jarvis-CAPTURE-RE. 任務: 透過十六進位差異比對 (capturable ↔ m###.bin + 2 個驗證樣本) 在 Sinscale 標頭中定位偏移量+位元 Dark Valefor, 加上可選的 IDA CanCapture cross-check. 交付物: 至少4行的證據表格 + RESULT 文件 + plan-doc 更新 + 主要 Cap 級聯文件更新 + PORT_STATUS + 其自身的 REVISION 版本提升. Non-goals 明確 (NOT 是否實作寫入器, NOT 是否觸及執行時期, NOT 是否擷取 in-game). 誠實估計 1.5–2小時. 解除封鎖 Cap-1 (階段 C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISION

Lulu

Spira 重鑄：Capture Cascade 雙重命名慣例（內部代號 + player-facing 品牌）

（設計/文件，無代碼）。Halyson 鎖定於 2026-06-16：該功能保留 兩個名稱，各自具有不同角色。內部（技術文件、變更日誌、結構欄位、ID、提示、工作線 signatures）保持為 Capture Cascade（Cap-1/2/3、dark_aeons.captured.<id>、capture_cascade.patrol_kills、arena.dark.<id>）。Player-facing（彈出視窗、模組 README、模組頁面）= 之軛 Spira（EN）/ Jugo de Spira（PT）— 聖經/耶馮共鳴（馬太福音 11:30「因為我的軛是容易的」）呼應原始版 FFX 的神權主題。F7 征服分頁 = 軛（EN）/ O Jugo（PT）。預設彈出字串：EN「Besaid 現在處於軛之下，受 Dark Valefor 支配」/ PT「Besaid está sob o jugo de Dark Valefor」；on-capture 戰鬥文字 EN「Dark Valefor 已被馴服。Spira 顫抖。」/ PT「Dark Valefor foi domado. Spira sente o tremor.」Capture Cascade 文件新增 §0（命名慣例表格 + Microsoft Threshold/Redstone 理由）。VISION_AND_ROADMAP §11 新增了包含 cross-link 的三情境表格

v2.123.1.1

v2.123.2.0BETAPATCH

Lulu

Ronso Mana: root-cause FIX 工作

(fixes a runtime-hook behavior bug + RE發現： command-ring buffer is runtime-allocated; its absolute pointer lives in a BSS cell (*(u32*)0x2310CD8)。 7AEFC0/79BB70 在索引 mov edi,[cell] (DEREF) before indexing +20592 環) 之前執行 +1144*slot (per-actor )。 RonsoManaHook.cpp 使用了 RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 raw, without the deref, and off by 0x1000 — 所以 ALL ring writes (template, per-slot header +0, OD row +296) 跨越 hudSafe 11..21 landed in a static BSS 從來不是 實際顯示的緩衝區 BSS ring injection ever appeared, and why CopyMenuTemplate_Shim ( 7AEFC0 detour) always early-returned (delta = slotPtr - ringBase 從來不是 11 44 的倍數) 。修復：新的 RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (實際指標儲存單元，取自 mov edi,[..]@0x7AEFC8的 imm32) + BattleCommandRingUiBase() 現在解引 用它 ( 未分配時為*(u32*)(g_base+RVA), null-checked when not yet allocated). With this, PatchKimahriCommandRingUi (+0 標頭)、 PatchKimahriMainMenuOverdriveRow (+296 OD) and CopyMenuTemplate_Shim (+296 post-sort實際 real 環。 RE proven (IDA): 7AD980 = 按優先級排序一個陣列 (key=*(u8*)(GetCommandEntryById+92), 暫存區=ring+20592); 7AEFC0 calls it 8× (one per category) to sort the per-slot ring. .i64 重新命名: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + 關於指標儲存單元 0x2310CD8的註釋。 DIAG (hudSafe=22): DumpKimahriRingState 記錄對實際 +0/+296 在 G0-finalize to confirm whether the encoded OD cmd (0x311A) lands. PolyHook build PASS (10/10), apply-mode deploy. RT2 需要測試 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.1BETAREVISION

Seymour

Spira 重鑄：Capture 級聯 Cap-1 — `capturable` 位元於 `m###.bin` LOCATED（階段 B RE 尖峯，doc-only）

（RE/文檔，無行為變更；建立在來自平行工作線的 v2.123.3.0 MINOR 之上 — 此 REVISION 純屬文檔/RE，且不與該 MINOR 衝突）。Capture 級聯階段 B 尖峯交付 doc-only：控制每個 capturable=true|false 中 m###.bin 的位元組已定位於 byte-precise，並以 58 個樣本 驗證。結論： 位置 = bytes[StatSheetPointer + 0x78]（其中 StatSheetPointer = uint32_le(bytes[0x0C])）；語義 = 0xFF（sbyte -1）表示不可捕獲，0x00..0x67（有符號位元組 0..103）表示可捕獲（原版 Monster Arena 之 104 插槽表格中的插槽索引）；填充 bytes[StatSheetPointer + 0x79] 始終為 0x00。證據鏈交叉驗證 (a) 舊版編輯器 v1.4 FFXmon4.ini（標籤「Capture 索引」以 16 位元十六進位表示，00FF = 不可捕獲），(b) 當前 C# 結構體 FfxLib/Monster/Monster_StatSheet.cs 第 49-50 行（[Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding），(c) 即時 UI 綁定 MonEditor_Control.axaml 第 466 行（「Capture 索引（競技場）」），(d) 完整結構佈局（MonsterHeaderFile 0x40-位元組標頭 + StatSheet 區段 + Monster_StatSheet StatBlock，其中 ArenaId 位於相對於起始於 +0x64 之 StatBlock 的偏移量 section + 0x14 處 → file-relative +0x78）。證明：21/21 可捕獲者匹配預期插槽（包括 byte-exact 與 FFXmon4.ini 匹配於 m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56），16/16 頭目不可捕獲 = 0xFF，10/10 暗黑召喚獸（m334..m343）= 0xFF，3/3 Penance 條目（m344..m346）= 0xFF。重要操作修正： 舊有的「DA 存在於 m106..m113」假設是 WRONG — 真正的暗黑召喚獸是 m334..m343（在 FfxLib/Dictionaries/Monster_Dictionary.cs 第 343-356 行中證明），而 Magus Sisters 為 3 個獨立條目（m341/m342/m343）。DOC-ONLY：在此工作階段中未寫入任何內容至 m###.bin/DLL/runtime/save/hook。未執行：IDA 確認 CanCapture() 的把關者（PLAN 的可選步驟 3）；cross-validation 對照原版 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（平行工作線；他們的變更日誌條目將在發佈時落地）]

v2.123.4.0BETAPATCH

Lulu

Nul Ward: 教導/menu-surface RE VERDICT + FIX 的 menu-bound 掛鉤（它原本在修補錯誤的 `cmp 320`）

（修正 NulWardTeachHook + RE 中的一個行為錯誤，已在真實的 .i64 上驗證；PATCH 提升 → 版本重置；先前的 HEAD v2.123.3.1 是一個 parallel-lane REVISION）。完整的 RE 通過（idalib MCP 在真實的 FFX_recon.i64 上）回答是否透過幻光球盤 + 一個成長的 /Umbral 教導 Radiant(320)command.bin(321) 能運作 end-to-end。 PROVEN 鏈： (1) FFX_GrantCommandToCharacter@0x785D10 將 id≥96 路由到 party-wide 庫 g_PartyWideCommandBank@0x11307FC — 16 字組/256 位元 = id 96..351；Radiant=字組14位元0，Umbral=字組14位元1；(2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEEDS 整個庫到角色+0x670（複製迴圈結束於 g_CmdAggregateAvailArrays@0x113081C → 庫 = 16 字組）；(3) FFX_Btl_IsCommandAvailable@0x79AD40 讀取角色字組 818+id/16（id320→位元組 0x68C 位元0）— 一致；(4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 案例21 呼叫授予(角色, node.LearnedMove, 1) → 一個 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.1BETAPATCH

Lulu

Ronso Mana hudSafe=24: PERSISTENT gauge-full PIN (`max:=charge`) — fixes "can't even go LEFT into Overdrive 工作

(fixes a runtime-hook behavior bug + RE發現（經由 日誌+反編 譯證明）： FFX couples "Overdrive 滿量表 (charge==max) 以及 re-checks it PER-FRAME in the HUD耦合 — 在我們鉤子之外。 hudSafe=23 暫時性偽造在每個蹦牀周圍設置了 max:=charge ，但立即 還原了 max=255 right after (EndKimahriMaxSpoof)，因此繪製環的那一幀看到 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 ；; 792AB0 (FFX_Btl_BattleMenuInputDispatch) 在 kind=12 OD ring when 79AF70 環 OD ring exists); 799AD0/799D60/7996E0/799830 是 target-mask resolvers, not the OD-full gate. Conclusion: the live gate is the per-frame charge==max 比較 — 暫 時性偽造無法觸 及。修復： ApplyKimahriRuntimePoolMax 現在持 續固定 max:=charge ，當 charge>=gateMin (the gauge reads 100% full for every per-frame check while his command menu is up; the ATB/CTB 暫停，因此不會損失超量 驅動累積）；低於閾值時 ，它歸還真實池 (25 5)，讓量表重新填充至0–255。暫時性 Begin/End 偽造已退役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 需要測試 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.0BETAPATCH

Lulu

虛無護盾 grid-teach: command.bin 範圍 PROVEN (無 exe 補丁) + LearnedMove 編碼 FIX 在編輯器中 + 離線驗證器

(修復了一個 SphereGridExplorer 編輯器行為錯誤 + 新的離線證明/驗證器 + RE)。DLL 保持不變 (隆索 Mana 工作線 is 使用它) — 僅 C#/editor/IDA。RT2 風險 #1 ELIMINATED 離線: RE 證明 FFX_Kernel_LoadFileToTable@0x781E00 (情況 0 "command") 將 command.bin 逐字載入到一個全域指標中 (g_CommandKernelTable@0x112A92C, full-file memcpy) — 無範圍合成。FFX_Table_GetEntryByIdRange@0x7AB890 直接從檔案位元組 讀取範圍標頭，精確對應到 EntryListFile: numRanges=int16@0(=簽章=1), lo=PreviousFileCount@8(=0), hi=(EntryCount-1)@10, stride=EntrySize@12(0x60), base=EntryTableFileOffset@16(0x14); record = file + 0x14 + id*0x60。由於增長的 command.bin 寫入 EntryCount-1=321，ID 320/321 ∈ [0,321] → 解析為恰好附加的光輝/暗影行。無 exe/DLL 補丁。 新的 CommandKernelLookupVerifier (FfxLib/能力) 重現引擎對增長位元組的準確數學計算，並接入 --nul-ward-static 閘門 (engine_lookup_resolves 檢查: 離線證明 GetCommandEntryById(320/321) 確實 NOT 命中 cmd0 回退)。編輯器 FIX (SphereGridExplorer): LearnedMove 下拉選單儲存了原始 ID (0x0140)，但 on-disk 是 編碼後 的 ID (0x3000|id) — 由 SphereGridRt2Lab 實證證明 (Armor Break 在 panel.bin 中 = 0x3012) 且為授予的 (cmd & 0xFFFFF000)==0x3000 閘門所需。下拉選單現在輸出 0x3000|id (光輝→0x3140, 暗影→0x3141) 並解析遮蔽 & 0xFFF 的名稱，因此 使用者可以將護盾放置在晶球盤上，且它們實際上會教導 (之前它儲存了 0x0140 且授予拒絕了它)。.i64 重新命名: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + 關於 0x781E00/0x7AB890/0x790AE0 的經驗證註解 (經由 idalib_save 儲存)。C# 建置 PASS (0 個錯誤)。文件: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISION

Yuna

Aurora 最終化彈道學：第 0 階段啟動（文件核對 + 舊註解修正 + 變體 UNVERIFIED 徽章）

（文件 + RE/誠實註解；無新功能；無行為變動）。計畫持續於 .cursor/plans/aurora_balistica.plan.md（10 個階段，Halyson-confirmed 範圍 A+B：5 個活躍 RT2 + IDA W2S 尖峯 + variant-selector IDA 尖峯）。此 REVISION 僅提供第 0 階段（在探針儀器化之前的文件核對）。四項編輯： (1) PORT_STATUS.md「Aurora 室」列 — Honestidade 文字已修正：原為 transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis，現反映 2026-06-05 IDA-proof（X/Z = identity，Y residual RT2 pending，參考 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 頂部 — 新增區塊 Atualizacao 2026-06-16 (Aurora finalizacao balistica)，總結真實 Aurora 狀態，與 A15 核對 + 確認的 RT2 順序（azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo，然後 IDA 尖峯）。(3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — JSDoc 標頭（第 9-10 行）已修正：原為 RAW battle-local - design-only/UNCALIBRATED，現為 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（當 SceneDetail 傳回超過 1 個變體時，顯示在 _resolver.ResolveScenes(MapKey) 中）現在會在 runtime selector UNVERIFIED 列表旁附加 _a/_b/_c，讓使用者知道 Chamber 會渲染目錄所選的任何變體，而真正的選擇器（story-flag -> 變體）尚未被 RE-proven — 參見 A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md。不涉及： 探針、寫入器、離線閘門、FfxHooksDll。下一步（第 1 階段）： 在 aurora-calib-v2 中實現 RuntimeTools/FfxDinput8Probe/ctl/Program.cs，並帶有 CSV/JSON 輸出（殘餘 identity_dx/dy/dz/rms、flipz_*、yaw180_*、winner 列舉、height_0x534、路線 + 戰鬥 ID）— 規格在 docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md 中。第 0 階段 RT2：N/A（docs-only + UI 字串）

v2.123.5.0