JARVIS-ARENA
更新 2.130
2026/6/16
v2.130.0.0MINORJarvis-ARENA
Arena+ Multi Dark Aeon 等級鎖定報告 CLI (`--print-tier-lock`) + sidecar 架構 v1
- （新增功能：首份離線報告，整合 v2 目錄與 sidecar 進度；快照 LOCKED/READY/CLEARED 的新標準架構）。新
RuntimeTools/ArenaMultiBossLab/TierLockReport.cs+ 4 面旗幟在Program.cs:--print-tier-lock,--progress <path>,--out <json>,--json. 預設模式會根據閘口原因，按層級彙總並列印人員報告（← needs: arena.dark.valefor, ...在 LOCKED 行中）及備用方案rt2:<status> risk:<...> token:<mode>在 rows 中未通過測試 d. Modo--outou--jsonemite JSON estrito que casa com o novo schemamods/Spira Reforge/arena/spira-arena-tier-lock-state.schema.jsonv1 (格式,格式版本,generated_utc,summary{總計、已清除、已準備就緒、已鎖定},rows[]comstateenum已鎖定|已就緒|已清除+unlock_requires/missing_requires). Regras de gating ja documentadas no schema (sao as mesmas que o futuro hook de menu F7 vai aplicar). Run atual contra catalog + sidecar vazio: 13 rows total -> 9 READY (solos) + 4 LOCKED (duo/trio/quartet/penta gateados pelos solos), 0 CLEARED. README demods/Spira Reforge/arena/reescrito com tabela completa dos 5 sidecars + comandos--print-tier-locke--驗證exemplificados. Lints clean. Build PASS. [anterior:v2.129.0.0]
v2.130.1.0PATCHJarvis-MAGIC
羅恩索·馬納（上週七）：我讀了那篇`DIAG`/`BLOB-PATCH` 來自 RT2`hudSafe=24` 我原本是跳過了 → 該 blob 的修補程式顯示「節點無效」（`subIdx=0x00`); 已重新編寫，以選擇「有效」節點 +`ODBLOB` 深度轉儲
- （修正了損壞的啟發式演算法）
PatchCase2BlobForKimahri+ 在已發布的鉤子/RT2 中新增唯讀儀表；程式碼已完成，將於下個 DLL 版本中進行編譯/部署 — 另一間部門正在使用）。發現（行數DIAG/BLOB-PATCH從%TEMP%\ffx-hooks.log我從未讀過——只是用 grep 搜尋過B0 resolve):BLOB-PATCH #1 treeId=43 set entry=0x00 (was 0xFF)+DIAG G0-ring-post blob2=0x1B5C8D70 hdr=[03 8A] maxE=138 treeId=43 entry=0x00 slots41/42/43=[FF FF 00] OK— 也就是說，PatchCase2BlobForKimahri已經存在且正在運行（已設定）blob[45]來自0xFF→0x00) 但該Resolve(2,1,43)仍為 −1。⇒ 舊的備用方案（maxUsed→幾乎總是0x00) 指出 treeId 43 指向一個 結構上無效的節點：它通過了主要閘門的WalkMenuBlobIndex(idx!=0xFF,43<count) 但 次要選擇器ringKind爆發 (v4>=node.entryCount或entry[v4]==0xFFFF) →*a3=−1. 同一日誌中的其他證據：count=138(43 在範圍內 → 並非「計數過小」的情況／43>=count);slots 41/42 = 0xFF(此 blob 中未記錄任何派對 OD a2=1 → 沒有同級捐贈者)；DIAG G0-finalize slot=2 od=3065 3064 3066 311A(環形緩衝區層-A TEM)311A=cmd282 Ronso Rage** — 確認該傳送門百分之百是 B 層選單樹的解析結果，而非內容）。修正方案（程式碼、hudSafe=25): (1)PatchCas e2BlobForKimahrireescrito — agora decodifica o nó no formato EXATO doWalkMenuBlobIndex(v6=(count+1)/2+2*subIdx;nodeOff=*(i16)(blob+2*v6+4);entryCount=*(u16)(blob+nodeOff);entry[k]=*(u16)(blob+nodeOff+2+2*k), tudo bounds-clamped) e escolheblob[2+43]por prioridade: (a) nó que contém0x311A(assinatura exata do OD) e suportaringKind=1; (b) sibling party-OD 41..47 já registrado com nó selector-capaz; (c) nó mais rico que suportaringKind=1(de preferência também 12). Se NADA qualifica, deixa0xFF(a2=1 não tem nó OD usável → é fix-C/redirect pro a2=0) e logaNO 可行節點, em vez de escrever lixo0x00como antes. (2) novoDumpOdBlobStructureOnce(read-only, dispara 1× mesmo em log-only) — dumpa os índices party-OD 41..47 do a2=1, oentryCount+primeiras entradas dos nós 0..23 (marcando o que tem<<OD311A>>), e os índices 41..47/109..115 do a2=0 (MainRing) → 1 RT2 crava osubIdxcerto OU revela que é redirect pro a2=0. Helpers novos (todosstatic, bounds-clamped, sem dep de PolyHook):OdBlobNode/OdBlobEntry/OdNodeSupportsSelector/OdNodeContainsEncodedOd/ReadMainRingBlobPtr(a2=0 =_BASE0xD2A994). BannerhudSafe=24→25(confirma DLL nova no log). NÃO buildei/deployei (DLL em uso por outra sala — respeitado);ReadLintsclean; código pronto probuild_hooks.ps1 -WithPolyHook -Release. Arquivo tocado:RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. Doc:docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§13. [anterior:v2.130.0.0]
v2.130.2.0PATCHJarvis-MAGIC
Nul Ward：「白魔法選單中什麼都沒有顯示」的根本原因 已查明 + 已修正 — 全隊共享的銀行已從`party_data` 每次戰鬥初始化時，會在「騎乘」選單出現前清除該增益效果
- （修復了導致 Nul Ward 無法浮現的行為錯誤 — 與以下相同的 feature/lab：
v2.123.4.0/v2.124.0.2; 已證實的決定性RE位於.i64實際 + 新的 re-assert 繞道在NulWardTeachHook; 由 Halyson 釋出 的 DLL（已完成重新編譯與部署）。問題症狀： 即使在針對 menu-bound 的多站點修正後（v2.124.0.2) + 載入時授予權限 (日誌NulWardTeach grant ch=0..6 radiant=1 umbral=1)，這些護符在戰鬥中的白魔法中並未出現。已關閉的 RE（idalib MCP，經 byte 驗證，透過disasm):sub_7817D0("* BTL INIT") 呼叫FFX_Btl_PrepareSaveCommandState@0x786BC0("-- SAVE RAM CLEAR -- Preparing save game data") 在 每次戰鬥初始化時；於0x786CA3她會mov ecx,21h; mov edi,offset dst__0; rep movsd— 複製0x84(132) 位元組的內核party_data(表格 ID 4) 至dst__0=0x11307D8, 曲目[0x11307D8,0x113085C)完全涵蓋該g_PartyWideCommandBank@0x11307FC(偏移量+0x24在副本內；資料庫 = 16 個單詞，ID 為 96..351)。⇒ 整個全黨資料庫被覆寫自party_data每一場戰役，以及party_data沒有守護位 → word14=0 →IsCommandAvailable(320/321)=0→ 放置循環跳過了守衛 → 「什麼都沒有出現」。已排除的嫌疑對象：FFX_Btl_InitPartyWi 來自 CommandBank@0x784960só dáORem bits 0..130 e é debug-gated (if(unk_112A905){ DebugMaxAll(); Init(); }— não roda em jogo normal);sub_78F0B0(Lancet/blue) e o grant só mexem bit individual. Correção mental do §H:PrepareSaveCommandStatenão é só "persistência" — é o reload ATIVO por-batalha do banco a partir doparty_data; qualquer grant de id≥96 ausente doparty_data(sphere-grid teach incluído) reseta toda batalha. Categorização corrigida (empírica): dump docommand.bindeployado mostra os doadores Nul (NulShock id48, NulTide id49) e as wards (320/321) todos com子選單分類 (byte +24) = 0x02— wards são templatadas dos doadores, então caem na mesma categoria de magia branca dos Nul que já aparecem (categorização correta-por-construção; faltava só o bit de disponibilidade vivo). O FIX (labteach_grant, deployado):NulWardTeachHookagora instala umPLH::x86DetournoFFX_Btl_PrepareSaveCommandState; o shim chama o original (deixa recarregar o banco doparty_data) e re-afirmag_PartyWideCommandBank[word14] |= 0x3(Radiant bit0 + Umbral bit1) no retorno — ou seja, logo após o wipe e antes doFFX_Btl_BuildActorCommandMenusemear o ator. Escrita direta no banco (não chamada de grant) pra não re-entrar no menu builder de dentro do init. Log diag (4 primeiros disparos):NulWardTeach 重新設定 #n post-PrepareSaveCmdState：銀行字元組 14 0xPRE→0xPOST. Grant one-shot mantido pros menus de field/pré-batalha. Consequência de design (produção): comoparty_dataé a fonte por-batalha pra ids≥96, o caminho limpo pra uma ward sempre-disponível é adicionar o bit no próprio kernelparty_data(innata, party-wide), não no sphere grid — um id≥96 ensinado no grid não persiste pós-init sem (a) o bit doparty_dataou (b) re-assert em runtime como esse detour de lab. Build/deploy:build_hooks.ps1 -WithPolyHook -ReleasePASS (12/12 cpp), deployinstall_to_modules.ps1 -EnableApply -EnableTeach(backupffx-hooks.dll.backup-nul-ward-20260616-081633, novo SHA-prefix0DE302BDF13D5B14). Gate--nul-ward-staticVERDICT: PASS (sem regressão; command.bin/exe/flags intactos)..i64實際值：註解 在0x786BC0+0x786CA3（黃金法則）。2 個新的 RVA 位於shared/ffx_addresses.h(RVA_FFX_BTL_PREPARE_SAVE_COMMAND_STATE,RVA_FFX_PARTY_WIDE_COMMAND_BANK). 遊戲內 RT2： 發起戰鬥並確認「光輝/暗影守護」是否已施放於白法技能上，並檢查日誌reassert ... word14 0x0000->0x0003. 開放邊緣：寬度為ply_savepro bit 224/225 (§H) — 每次載入時，lab 都會重新套用。檔案：RuntimeTools/FfxHooksDll/hooks/NulWardTeachHook.cpp,shared/ffx_addresses.h. 文件：docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md§I. [前文：v2.130.1.0]
v2.130.2.1REVISIONJarvis-MAGIC
《斯皮拉重鑄：延伸黑魔法》 — 設計鎖定（多技能家族 > -ja 層級；`-ja` 轉為利基後備清單；Lulu Fury 包含所有內容）
- （設計文件 + 整合至 VISION；本次迭代中未涉及任何寫入器／行為／RT2）。Halyson 發起了關於創建新「黑魔法」的腦力激盪。我比較了兩條路線：(a)
-ja層級（Firaja/Blizzaja/Thundaja/Waterja = 帶有 +Power 的 -ga 克隆版，不包含 Fury）vs (b) 多技能（原版單體法術的範圍版，且這些法術沒有對應的範圍版本）。 決策（Halyson）： 多重技能作為主要路線勝出；-ja被歸類為利基待辦事項（每個元素 1 項，工作量極大～80–120，天界之後，錦上添花——不會與增益效果產生衝突）-ga在VISION §10.5); 露露·弗瑞 包含一切（「弗瑞·德萊恩加 16× 是美麗的混沌，過載的幻想」）。為什麼「多技能」能勝出： (1)TargetFlags.Multi已經是 引擎的原生功能 （FfxLib/Ability/Ability_Command.cs:125) — 單體 → 群體 = 指令列中佔用 1 位元；(2) 法術填補了 原版中的實際空缺（缺乏範圍性毒、範圍性吸血、範圍性滲透），並賦予其獨特風格；(3)-ja與「計畫」一詞重複VISION §10.5已經要開始增益了-ga搭配 Ignore MD EF / 威力調整（「重鑄的菲拉加」，而非「菲拉賈」）；(4)VISION §10.11已將 Holyra/Holyga/Wildra 歸類為「有趣，但可能永遠不會用」，原因相同（缺乏獨特性的技能池）；(5) Drainga/Osmose-ga 則用於支援其他戰線（T7 級「Capture Cascade」的長期戰鬥、SIN 模式的詛咒、怪物 OD 多重施法）。 技術上已驗證的第一批法術（v0.5+）： Biora（範圍毒效＋傷害，Bio分身＋多重施放），Drainga（範圍吸血，HP上限 9999／次施放）， Osmose-ga（範圍吸取 MP，上限 99/次施放），Demita（範圍 50% HP，上限 9999/目標）， 多重菲拉加系列（3× 菲拉加 範圍連發，MP消耗為三倍 — 直接源自 Halyson 的構想：「例如多重菲拉加>>>>>>」 — 可擴展至多重布利扎加／雷電加／水加／終極加的子系列）。 第二波（v0.6+）： 慢速咒、反射咒、半墜落（「次元碾壓」75% 生命值，單體，MP 消耗高），四分之一咒（25% 生命值，範圍，MP 消耗低）。 已記錄的真實阻擋機制： (a) 法術 ID 槽位0..95— 與……進行交叉審計FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md用以識別捐贈者；(b) 露露·弗瑞划船#12408–#12422待處理的傷害；(c) 依賴 RT2 的魔法值上限消耗（無上限 = 透過攻擊治療的 OP，上限過低 = 法術失效）；(d) 多重菲拉加hit_countplayer-cast RE spike 待定；(e) 視覺特效與單人模式完全相同（v0.5 版本適用，v0.6+ 版本透過 Flan Flood 引擎重新上色，已通過測試）v2.114.0.0); (f) Sphere Grid 線路相關決策另行處理。增量技術計畫（文件第 6.2 節）： A 階段：審核 ID 捐贈者（無代碼，本文件），B 階段：離線編寫（複製行 + 多重翻轉 + 調整力量/MP + 文字輸入），C 階段：寫入器實驗室，D 階段：RT2 遊戲內，E 階段：Fury 整合，F 階段-jabacklog niche (v0.7+)。與模組整合： 補充功能§10.5黑色增益魔法，提供能量§10.6露露·弗瑞，請保持§10.11《元素拼圖》，請回答§10.13支援 Drainga/Osmose-ga 的 mob OD 多播，支援§11記錄 Cascade T7 的戰鬥。 **VISION_AND_ROADMAP.md 已更新：**新增第 12 節「擴展黑魔法 — 多技能家族」（設計決策 + 第一／第二波法術 + 路線圖關聯內容 + 完整文件）；參考資料重新編號為第 13 節。 供持續腦力激盪的開放性問題： 多重菲拉加機制 A/B/C（硬編碼雙重施法 vs 隨機分配 vs 混合型 el ement — 建議 A)，目標為單位的「Drainga」與施法為單位的「Drainga」對比，球形網線，Demita 與 Demi 原版版本的共存，白魔法範圍攻擊（Esuna-ga？），供能者層級。 不涉及： 任何寫入程式、任何鉤子、任何探針、任何 DLL、任何離線閘道／RT2。僅限文件 + 路線圖整合。新文件：docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md（10 節，約 300 行）。涉及的檔案：FFXProjectEditor/FFXProjectEditor.csproj(bump 4-tuple)，mods/Spira Reforge/VISION_AND_ROADMAP.md（新增第12條＋重新編號「參考文獻」為第13條），CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [上一頁：v2.130.2.0]
v2.130.3.0PATCHJarvis-MAGIC
Ronso Mana CRASH 緊急修補程式 (`hudSafe=26`): 對 blob 的寫入操作不再觸發節點（原先是`via=rich>=1 subIdx=0x01` → 當機）；現在的寫入方式為「選擇加入」模式 + 僅安全節點 + 由 SEH 保護的讀取操作
- （修正由
hudSafe=25來自v2.130.1.0當 DLL 被重新編譯／部署至v2.130.2.0來自 Nul Ward 通道）。根本原因（日誌 RT2%TEMP%\ffx-hooks.log):RonsoMana BLOB-PATCH2 #1 treeId=43 set subIdx=0x01 via=rich>=1 nodeOff=0x1B4 ec=24 (was 0xFF)— 我所使用的 (3)「最豐富的節點」 備用方案hudSafe=25寫入了一個被踢出的節點索引 (0x01,ec=24) 在blob[2+43]. 這使得Resolve(2,1,43)「成功」於一個非 OD 環的節點上 →finishMenuTree載入／顯示了虛假內容 → 遊戲 當機。（該0x00舊的hudSafe<=24它只會傳回 −1，因此並不會導致程式當機：因為它從來不會被呼叫finishMenuTree.) 我的操作「讓原本『崩潰但仍可運作』的狀態演變成完全當機」。該熱修補程式（hudSafe=26): (1) blob 的寫入功能現已改為「選擇加入」模式 — 僅在blob[2+treeId]當寄件人FFXHOOKS_RONSO_OD_BLOBWRITE=1已設定；預設值 = 不寫入任何內容（防當機版本，純粹透過ODBLOB); (2) 即使採用選擇加入機制，也僅記錄「初級」節點 — (a) 其輸入中包含編碼 OD 指令的節點0x311A，或 (b) 遊戲已記錄過的同級方-OD 41..47；絕不自動記錄 c hute「最富有的節點」（此資訊僅記錄於日誌中，以便在讀取轉儲檔後進行硬編碼）；(3) 所有節點的讀取資料（OdBlobNode/OdBlobEntry) 以及 a2=0 的區塊DumpOdBlobStructureOnce現在已配備 SEH 裝甲（__try/__except) — 任何因越界偏移量（OOB）引起的存取違規，都會被處理為「無效節點」並清除，而非導致系統當機； (4)mainPtra2=0 通過了合理性檢查 (> 0x10000). 日誌現在會輸出BLOB-PATCH2 #n ... write=0|1 safe=0xXX(how) risky=0xXX(how,ec=..)（展示若不寫作會做什麼），而當選擇加入且節點安全時，BLOB-PATCH2 WROTE .... 橫幅hudSafe=25→26. 可逆性： 若未啟用 env，行為即為安全的原生模式（隱藏 OD，不會當機）。尚未編譯／部署（與其他 Jarvis-MAGIC 通道共用的 DLL）— 下次重新編譯時ffx-hooks.dll（無論哪條路線）都已取得該熱修補程式；ReadLintsclean。檔案：RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. 文件：docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§14. [前文：v2.130.2.1]
v2.130.3.1REVISIONJarvis-MAGIC
《Spira Reforge：延伸黑魔法》 — 4項關鍵決策：Halyson（多重Firaga選項B、最高單體目標吸血上限、Demita與Demi共存、包含所有細微差異的Fury）
- （Ronso Mana 針對另一條平行 Jarvis-MAGIC 路線的輕微熱修）。此為以下設計文件的直接延續：
v2.130.2.1: 與 H 的腦力激盪 艾莉森敲定了最後 4 項待定決策。(1) 多重菲拉加機制 — 選項 B（隨機分配）＋ 3-5 倍基礎 MP： 哈莉森：「選項 B，但『多重菲拉加』、『多重幹死你』將消耗基礎技能 MP 的 3~5 倍來彌補，這可是超猛的連擊啊」。 機制 = 1 次施放 → N 次命中（5-7 次），每次命中會隨機擊中一名敵人（透過聖光/彗星/雙重施放公式實現的原生引擎機制）。敵人可能根據隨機數值（RNG）受到同一個「多重菲拉加」的 1、2 或 3 次以上命中。 MP 消耗 = 4× 預設基礎值（Multi-Firaga = 64 MP），Multi-Ultima = 200 MP。Jarvis 建議：初期設定為 4× MP + 6 次命中，並調整 RT2。可擴展系列（漸進式推出）：v0.5 次多重菲拉加 + 多重布利扎加，v0.6 + 多重桑達加 + 多重沃特加，v0.7 + 多重烏爾蒂瑪（黑暗效果後 §10.11），v0.8+ 待處理的多重弗萊爾／多重聖光。 (2) 吸血上限 — 每目標 9999/目標（多目標上限）： Halyson 設定此數值時已充分考量其影響。4 名存活敵人 = 單次施法最多可恢復 39,996 HP = 頂級「進攻型治療者」。 ⚠ 可能破壞長時間的競技場戰局 — 此為刻意設計，屬 Halyson 的模組，屬於終局幻想設定。補償機制：若造成全面破壞，MP 消耗在 RT2 後可能攀升至 ~30。(3) Demita 對比 Demi 原版 — 可並存： 請保留兩者。 單體型 Demita（16 MP，頭目殺手）＋群體型 Demita（24 MP，波次清場）。玩家自行選擇工具。 代價：額外佔用 1 個 ID 槽位。(4) Lulu 的「全包式」狂怒機制（含細微差異，§4 決策已更新）： Biora 16× = 可行（毒波）； Drainga 16× = 僅限狂怒狀態下 9999/次上限（狂怒狀態下非按目標計算，否則最多可治療 639,936 HP ——「完全不合邏輯」）； Osmose-ga 16× = 可行（MP 上限 9999 = 硬性限制）；Demita 16× = 可行（Demi 不會命中已死亡目標）； 多重菲拉加 16× = 潛在 96 次命中 ⇒ 狂怒模式下的多重*技能使用 hit_count=1（在狂怒模式下恢復為單次施放） 或將多重技能從狂怒技能池中排除（這是「包含所有」規則的唯一例外）。最終決定將調整 RT2。 文件第 8 節中更新的未決問題： §8.1 已決（4 項確定）；§8.2 仍未決（Sphere Grid 線路、白魔法範圍效果、元素吸收混淆、捐贈者的層級）0..95封鎖 A** 階段，多 隨機分配command.binfield via spike）。文件已更新：docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md§2.2 裁員（按目標設定的上限），§2.4 解僱（c （已固定），§2。5 多重菲拉加（選項 B + 固定 3-5× MP + 完整元素表），§4 狂怒（各法術的細微差異），§8 待議事項（4 項已標記並決定，5 項仍待商榷），§9 更新後的提交版本。 下一步行動： A 階段法術 ID 來源交叉核對與FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md— Halyson 決定是現在就加入，還是等到 v0.5 接近發布時再加入。不涉及： writer/hook/probe/DLL/gate。檔案：FFXProjectEditor/FFXProjectEditor.csproj(瀑布v2.130.3.0→v2.130.3.1),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md（§2.2/§2.4/§2.5/§4/§8/§9 已更新），CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [上一頁：v2.130.3.0]
v2.130.3.2REVISIONJarvis-MAGIC
Spira Reforge：架構轉向 — 「擴展黑魔法」改名為「擴展角色指令」（RE D01 測試版 + 適用範圍擴展至 7 個角色）
- （立即續接
v2.130.3.1；沒有任何寫入器／行為）。Halyson 提議道：「如果不用這些滑雪板，而是 「既然『任何人』都能取得它們，我們為什麼不讓它們變成『僅限 X 角色』呢？」 ——我比對了現有的 RE，並發現 原生引擎已經原生支援按角色設定 ID 的所有權0..95. 關鍵發現（RE D01 —FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md):FFX_GrantCommandToCharacter @ 0x785D10包含 SPLIT AT INDEX 96：ids< 96去銀行聊聊吧word_11307FC[74*char+3151+(id&0xFFF)/16](stride 74 個單字 =ply_save按角色）；ID>= 96將其存入全派對銀行（無步長）。⇒ 每個角色的可學習空間精確為 96 位元，ID 範圍為 0..95。ID ≥ 96 無法透過「每個角色」的方式進行學習。影響： ID 的重新分配0..95= 原版引擎會篩選「誰」能看見每個法術，且完全不使用任何鉤子**。舊方法（ID ≥96 加上 Nul Ward 風格的繞道機制來進行限制）已被捨棄。 擴展分配方案（Halyson 於 2026-06-16 決議，引文保留）： 露露（6 個法術，爆發型施法者 + 吸血）——多重「菲拉加」系列 × 4 + 「吸血」+ 「滲透加」（從尤娜移至露露），可能包含「迪米塔」； 尤娜（5 個法術，白色/增益範圍攻擊） — 反射加 + 防護加 + 護殼加 + 復原加 + 驅散加（「反射加、防護加、護殼加、復原加、驅散加由尤娜負責」）； 莉庫（3 個法術，偷取大師） — 「Copycat」成為她的專屬技能 + Mugra（2連擊單體，2次偷取） + Mugga（範圍2連擊，低傷害，「可偷取6次!!!!」）； 瓦卡（待定，「更多狀態技能和更瘋狂的招式」）；基馬里（待定，「藍魔導士。 可學習怪物技能，甚至連牠們的超驅動都能透過魔力來使用」——由 Ronso 負責魔力路線協調）；提達（待定，「毫無頭緒，但或許會有多段擊中技能」）； 奧隆（「這遊戲裡他媽的坦克。哨兵的進化版，或許擁有更強力的範圍破防技能」）。預估總數：96個技能槽中的28-31個法術 = 約30%的配額，尚餘65+個技能槽可用於-ja待辦事項 v0.7+ + 未來規劃。文件 §9.1 中已確定 9 項決策，§9.2（解僱負責人、Wakka/Tidus/Auron 技能池、Rikku 模仿者替代方案、球網連線、捐贈者 0..95 審計、多重菲拉加隨機命中場、每次命中竊取的 Mugra/Mugga、Kimahri 藍魔導士協調 Ronso 路線）。 此模型的優勢： (a) 零鉤客製化 — 原生基礎引擎；(b) 球形網格樹獲得實際意義（轉移至另一棵樹＝真正的取捨）；(c) 露露的「狂怒」機制大幅簡化 — 狂怒池採用基礎設定的「每角色獨立」機制，「將 Multi-* 排除於狂怒之外」不再是問題； (d) 「連鎖捕獲」§11 與「SIN 模式」§10.13 將針對每位角色提供不同的戰術回應。技術計畫 (§7.2)： 第 0 階段：鎖定池（待定）→ 第 A 階段：捐贈者審計（阻斷啟動）→ 第 B 階段：按角色編寫（B. Lulu 試飛版、B.1 尤娜 白色範圍攻擊、B.2 莉庫 穆格家族搭配每次命中竊取突刺、B.3 池（待定）） → 階段 C/D：RT0/RT1/RT2 → 階段 E：球網連線（斯皮拉網格編輯器擴充） → 階段 F：露露狂怒行 → 階段 G：基馬里藍魔導士（取決於隆索路線） → 階段 H：-ja 待辦清單 v0.7+。 VISION_AND_ROADMAP.md 第 12 節重寫：「擴展黑魔法」→「擴展角色專屬指令」＋角色分配表＋封鎖機制＋更新路線圖。 文件名稱已進行概念性重命名（為保留歷史紀錄，檔案路徑維持不變）：docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md— 11 個章節，§1 採用「按角色」所有權模型，內建 D01 反編譯 RE 並經過位元組驗證，§3 按角色分配（3.1 露露、3.2 尤娜、3.3 瓦卡 待定、 3.4 莉庫、3.5 基馬里協調、3.6 提達（待定）、3.7 奧隆（待定）、3.8 摘要）。不涉及： writer/hook/probe/DLL/gate。僅限設計與路線圖整合。檔案：FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.1→v2.130.3.2),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md（大幅改寫：新增第1段 RE D01、第3段擴充7個字元、第5/7/8/9/10/11段重新編號並更新），mods/Spira Reforge/VISION_AND_ROADMAP.md（§12 重寫），CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [上一頁：v2.130.3.1]
v2.130.3.3REVISIONJarvis-MAGIC
《Spira Reforge》：第0階段 完成 A — Halyson 僅用一次操作就將所有角色待定（TBD）法術池全數鎖定（德米塔→基馬里、瓦卡 5 個法術、奧隆 MAX 包 6 個法術、提達多段攻擊＋自我增益、莉庫＋1 個新盜賊技能）
- （2026年6月16日第三次更新，緊接上文）
v2.130.3.2; 沒有任何寫手／行為模式）。 額外鎖定 4 項決策（從 9 → 13）： (1) 解僱隊長 = 基馬里（「奇異怪物」機制 + 藍魔導士主題；釋放露露專注於元素爆發）； (2) 瓦卡技能池 = A+B組合，5個法術 — 比奧拉（範圍中毒＋傷害）＋睡眠拉 （範圍睡眠）＋「四重犯規」（範圍三重犯規＋中毒＝4種狀態）＋「雙重破壞者」（2連擊單體，2種狀態隨機組合）＋「潮汐斬」（2連擊物理）——「狀態大師＋雙重擊＋瘋狂招式」； (3) 奧隆技能組 = 滿套技能，6 個法術 — 群體破防 + 群體破甲 + 群體破魔 + 群體破心 + 哨兵++（哨兵 + 物理/魔法格擋 + 全隊 1 回合） + 挑釁 （挑釁＋自動「哨兵」＋嘲諷所有敵人）—— 「奧隆就是這遊戲裡他媽的坦克」； (4) 提達的技能配置 = 多段攻擊 + 自我增益，4-5 個法術 — 螺旋斬（3 段單體攻擊，+5 力量／施法上限 25）+ 潮汐連擊（4 段範圍攻擊， +5 AGI/施放，上限 20) + 刀刃風暴（5 連擊隨機，+自身加速 1 回合）+ 野牛衝鋒（招牌技能，+固定 AGI + 加速 3 回合）+ 可選 應援一擊（2 連擊 + 自身應援）。 「提達斯向來都是最快的。快速一擊肯定會被削弱，因此需要多段攻擊技能來提供提升自身屬性的增益效果」 — 針對快速一擊削弱的直接補償 §10.6； (5) 莉庫 +1 新增盜賊技能 — 哈利森要求「自創盜賊技能」以完善技能池；賈維斯建議：手部技巧（精進版「搶劫」）、扒竊 （無回合消耗的偷竊；預設為 Jarvis），粘手（每次施放堆疊 +25%），背刺（無視物理防禦），藏匿（直接竊取技能池），煙霧彈（跳過隊伍 CTB）。 最終完整分配（第 0 階段）： 露露 6 + 尤娜 5 + 瓦卡 5 + 莉庫 4 + 基馬里 3 + 提達斯 4-5 + 奧隆 6 = 96 個法術槽中分配 33-34 個法術 = 約 35% 配額（剩餘 62+ 用於-jabacklog v0.7+ + white magic extras)。跨角色連段： 奧隆「集體精神崩潰」＋露露「多重菲拉加」（無 MDEF 的波動爆發）；奧隆「哨兵++」＋尤娜 P rotectga/Shellga（2回合近乎完全的無敵狀態）；奧隆「挑釁」＋瓦卡「四重犯規」（坦克＋群體狀態異常）；提達斯「刀刃風暴」＋奧隆「群體破甲」（提達斯爆發傷害＋目標無防禦力）。 提達斯自我增益帶來的風險： 無限堆疊 STR/AGI = 類似 QH 的退化現象；堆疊上限（5 STR / 4 AGI）的緩解效果 + 每場戰鬥結束後的衰減（戰鬥間不會持續）。 第9.2節中剩餘的11個未解問題 — 均為細微的次要決策（莉庫盜賊技能的最終名稱、提達斯4個對5個法術）或技術性突發狀況（多重菲拉加的隨機命中）command.bin場地效果、每擊竊取 Mugra/Mugga、Wakka 每擊狀態附加、Tidus 自我增益疊加、Auron Sentinel++ 全隊增益、Kimahri Lancet+ 持續效果）—— 不阻礙整體設計，僅阻礙特定階段的編寫。捐贈者審計0..95(§9.2 q18) 現已確定具體範圍：約需 33-34 個插槽。 文件更新： §3.1.4 將「Demita」移至 §3.5.1「Kimahri」；§3.3 Wakka 鎖定 5 種法術；§3.4 Rikku 增加 1 項盜賊技能，附 6 項建議； §3.5 基馬希完整法術池（「解僱」＋藍魔導士擴充 2-3）；§3.6 提達斯法術池 4-5 種多段擊中＋自我增益，搭配對抗 QH 的連擊；§3.7 奧隆 MAX 套組 6 種法術，包含跨角色連擊＋風險/減傷； §3.8 總結：共 33-34 個法術 = 佔預算 35%； §9.1 13 項決策； §9.2 11 項子決策／突發狀況； §10 開場v2.130.3.3. VISION §12 更新： 各角色最終分配表 + 彈出式連段。未涉及： writer/hook/probe/DLL/gate。檔案：FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.2→v2.130.3.3),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md（已移至第3.1.4節 + 已更新第3.3節／第3.4節／第3.5節／第3.6節／第3.7節／第3.8節／第9節／第10節），mods/Spira Reforge/VISION_AND_ROADMAP.md(§12 最後一桌 + 連擊)，CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [上一頁：v2.130.3.2]
v2.130.3.6REVISIONJarvis-MAGIC
Spira Reforge：REALITY CHECK + 3 次逆轉 — 路線 4 (`CharacterUser` （原生）固定 + 透過 Sphere Grid 固定的學習能力。Halyson 察覺到了我未曾注意到的細節
- （2026年6月16日上週四，續）
v2.130.3.3；無寫入器／行為）。本節的架構迭代順序：(1) v2.130.3.2 pivot： 發現 RE D01，其中 ids0..95這些應該是原生魚，我標記為「零釣鉤 + 剩餘 62 個魚槽」。(2) Halyson 開啟了FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md並問道：「這是怎麼回事？」： 2026年6月12日的審計報告已證實0/96免費插槽 — 所有 96 個 ID 均已被 vanilla 佔用。我先前所述的「尚餘 62 個」是 錯誤的。(3) v2.130.3.4 方案 3： 我提議採用 append 方式≥96+ 每角色白名單鉤子（通用版 Nul Ward 風格），Halyson 已批准。 (4) Halyson 提出第四種方案： 「在 CommandBin 中，難道不就是由我選擇某個角色的『使用技能』（例如 TIDUS），問題就解決了嗎？根本不需要任何鉤子。」 我之前並未注意到這個原生欄位[Data] public Character_Enum CharacterUser在Ability_Command.cs:29— 有符號位元組 nocommand.bin該設定會限制哪些使用者能執行各命令。字節精確的證明：FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md第 86 行引用了 Yojimbo Dismiss（ID 87），其中包含CharacterUser=0x0E(14=Yojimbo) — 原生引擎會根據此欄位自動篩選選單。現有使用者介面 (KernelCommands_Control.axaml:434下拉式選單 (ComboBox)。方法 4 取代方法 1/2/3 — append≥96與CharacterUser透過 UI 編輯器直接設定的每項技能。完全不使用選單過濾器的鉤子。(5) Halyson 強調：「技能將可透過 Sphere Grid 學習」 — 這重新觸發了 Nul Ward §H 針對 ID 的注意事項≥96（全伺服器初始化時重新載入會覆寫 grant grid）。解決方案：1 個通用鉤子，透過擴展NulWardTe achHook.cpp(já provado emv2.130.2.0) — (a) detourPrepareSaveCommandStatere-asserta bits ≥96 lendo sidecar; (b) detour panel_teach escreve sidecar quando node ativa. Net hook count: 1 (generalização, não hook novo). Sidecar JSON extendsspira-reforge-flags.schema.jsondo Capture Cascade. Plano técnico atualizado (15 bloqueios honestos catalogados): Fase 0 ✅ → Fase A appendcommand.bin≥96 comCharacterUser(A.1-A.7 por pool char) → Fase B sidecar schema → Fase C Sphere Grid editor scope expansion (LearnedMove = 0x3000 | id≥96) → Fase D hook generalizado → Fase E RT0/RT1 writer LAB → Fase F RT2 in-game piloto → Fase G Lulu Fury rows → Fase H-jabacklog v0.7+. Bloqueios pequenos pendentes (spikes): addr panel_teach runtime, sidecar JSON schema design, side-effectsCharacterUserfilter (Trio of 9999, Doublecast cross-char), Multi-Firaga random-hit field, steal-per-hit Mugra/Mugga, Wakka status-rider per hit, Tidus self-buff stacking, Auron Sentinel++ party-wide buff. Vantagens Caminho 4 vs alternativas: (a) zero sacrifício vanilla (coexistência total Firaga + Multi-Firaga, Demi + Demita, Mug + Mugra/Mugga, Sentinel + Sentinel++); (b) net 1 hook (vs 0 do pivot falso, vs 2-3 do Caminho 3); (c) infra ALREADY EXISTING (NulWardTeach hook + sidecar Capture Cascade + editor UI ComboBox); (d) identity vanilla intocada. Lição honesta documentada: "sempre que sentir 'zero hook' soando bom demais, abrir os audits existentes antes de propagar a narrativa". Doc atualizado: §0 verdade curta (3 reversões + 4ª decisão grid), §1 ownership model (Caminho 4 + grid teach), §7.2 plano técnico (Fases 0-H), §7.3 15 bloqueios honestos, §10 entriesv2.130.3.5ev2.130.3.6. Não toca: writer/hook/probe/DLL. Arquivos:FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.3→v2.130.3.6, pulou.4/.5por terem sido reversões dentro da mesma sessão de design),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md(§0/§1/§7.2/§7.3/§10 reescritos),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [anterior:v2.130.3.3]
v2.130.3.7REVISIONJarvis-MAGIC
參考文件：96 項角色技能的彙整目錄（ID：`0..95`) 與`Power`/`MP`/`Formula`/`Acc`/`Hits`/元素/效果 + AbiMap 架構 × 全隊銀行
- （登記文件／參考目錄；無撰稿人／行為／RT2；僅將原本分散於各處的知識整合至一份文件中
FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md+FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md+FFX_BATTLE_COMMAND_MENU_INFERNO_2026-06-15.md+CommandCharacter_Dictionary.cs+Ability_Command.cs). Halyson 要求提供 MD 中的 96 項技能表，作為此模組的運作參考。新文件docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md（8 節，約 250 行）：§0 TL;DR：在 95 上達到極限（AbiMap 96 位元實體）＋交叉 RE 驗證；§1 引擎如何決定選單（FFX_Btl_IsCommandAvailable @ 0x39BB70「單人」與「全隊」的區別CharacterUserfilter）；§2 編碼LearnedMove = 0x3000 | id從panel.bin(參考資料SphereGridExplorer_DataModel.cs:30-31); §3 完整目錄 0..95 分為 9 組（核心/選單 0-5、技能 6-21、特殊 22-25、應援 26-31、基馬里/防禦/社交 32-42、 白魔法 43-64、黑魔法 65-83、艾翁選單 84-87、莉庫終局 88-95），採用《FFX HD Remaster》（美版／日版）的正統數值 — MP／力量／公式／命中率／命中次數／元素／效果；§4 透過 3 個標記決定「魔法是什麼」的關鍵劇本（DamageFlags+DamageFormula_Enum+PreviewFlags) 包含「治療／復活／淨化／物理／魔法／狀態／增益／重力／吸取」技能表；§5 透過網格無法傳授的 11 個 ID（missing=[0,1,2,3,4,5,33,84,85,86,87]在所有 10 個區域中 — system/Defend/Aeon/Yojimbo）； §6 96+ ID 全隊效果（超驅動、永恆、死亡、混合、偽 AI），其分離設計有 3 項理由；§7 斯皮拉重鑄與「漫步者」連結所帶來的後果 第 4 項的v2.130.3.6; §8 交叉引用。不涉及： writer/hook/probe/DLL/gate。檔案：FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.6→v2.130.3.7),docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md(新)，CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [上一頁：v2.130.3.6]
v2.130.3.8REVISIONJarvis-MAGIC
Spira Reforge：第一階段「原版進攻平衡調整」已確定 — 16 項技能進攻加成 + 自動技能整理 + MP 球體提升
- （僅限設計／由 Halyson 敲定的決策；本次修訂未涉及劇本撰寫或角色行為）。Halyson 開啟了
FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md並斷言：「魔法確實發揮了應有的作用，甚至包括治療。但其餘的呢？簡直可悲。Full Break？去你的，不僅幾乎打不中，花掉99點MP卻只造成可笑的傷害。」 犀利評析：20項原版攻擊型技能，附帶Pow er = 16(= multiplier 1.0× = Attack base) ou功率 < 16(= pior que Attack); Auron Full Break Power 16 / Acc 36 / MP 99 = crime contra o jogador. Pacote final cravado (3 frentes em 1 pass): (1) Damage buff de 16 skills (Extracts removed): Wakka 8 status-riders (Sleep/Silence/Dark Attack P16→20 Acc 50→60, Zombie Attack P16→24 Acc 50→60, Busters P16→26 Acc 100, Triple Foul P16→32 Acc 100→90 MP 24→28), Auron 4 Breaks (Power/Magic Break P16→22 Acc 50→80 MP 8→10, Armor/Mental Break P16→24 Acc 36→70 MP 12→14), Full Break P16→48 (3× damage cravado Halyson) Acc 36→90 MP 99→75, Tidus 2 Delays (Delay Attack P12→18 MP 5→6, Delay Buster P14→22 MP 10→12), Rikku Mug P16→20. Filosofia: Power ≥ 18 sempre quando skill paga MP; premium MP ⇒ premium Power; Breaks Acc 36-50% sobem 65-90%. (2) Auto-Ability cleanup: Slot 12 Half MP Cost MANTÉM (justificativa Halyson: Lulu Magic Booster + custos altos = ainda paga Ether/Elixir = balance natural). Slot 13 (ex-One MP Cost, cheese de 1 MP universal) REMOVIDO → vira Mana Spring (+5 MP/turno em batalha; regen tick passivo; substitui economia sem virar cheese — em battle de 10 turnos = +50 MP cumulativo). Slot 23 (ex-Break HP Limit) vira "Break Limits" (bits0x0200 | 0x0400OR emability_flags_64, HP cap + MP cap juntos via engine vanilla; byte-edit puro, zero hook); §10.8 do VISION cravado. Slot 24 (ex-Break MP Limit) vira "Devil's Bargain" (+50% dano dado / +50% dano recebido — glass cannon switch simétrico; 2-pass: Pass 1 placeholder funcional agora com bit reassignment, Pass 2 hook damage calc depois com RT2). (3) MP Sphere node bump (escopo B cravado Halyson "B simplesmente B"): Standard Grid MP +40 → +60, Expert Grid MP +20 → +30 (escala proporcional 1.5× cross-grid). Edit trivial viaSphereGridNodeTypeEntry.IncreaseAmount(offset 0x14, ushort) emSphereGrid_File.cs:519。本次會議中敲定的決策順序： (a) Halyson 開啟目錄，確認問題；(b) 我提議建立包含 20 項技能 + 4 類自動能力之增益表； (c) Halyson 確定將「萃取物」移出並採用 3 次「完全分解」；(d) 確定移除 1 點 MP 且不採用「法力護盾」（建立新目標）；(e) 我確認第 10.8 條，將第 23 號插槽逆轉為 Br eak Limits 與第 24 槽位改為「xereca」用途；(f) 確定了第 24 槽位的「Devil's Bargain」配置，並理解了 2-pass 的注意事項；(g) 優化了第 13 槽位的「Mana Spring」及「Spell Spring」的待處理清單。 已歸檔的技術注意事項：「魔鬼交易」需計算鉤子傷害 + RE 位址FFX_DamageCalc_*待處理；Mana Spring 需要回合開始時觸發效果 + 識別出可用的位元在ability_flags_64; 擊中命中率 vs 狀態附加效果命中率——RT2 待定突增；三重犯規命中率 100→90 待定突增（驗證「三重保證」不會失效）； 後期遊戲中全破MP縮放無誤（75在半MP狀態下仍過於昂貴）；自動能力位元重新分配槽位24需掃描可用標誌於AutoAbilityHardcodedFlagCatalog.cs. 第一階段技術計畫（純字節編輯v2.131.x修補程式)： 1.1command.bin16 項技能攻擊加成，1.2 第 23 槽「突破極限」，1.3 第 13 槽「魔力之泉」佔位符，1.4 第 24 槽「魔鬼交易」佔位符，1.5panel.binMP 節點、1.6 文字池、1.7 RT0/RT1 閘門位元組標識、1.8 RT2 導引信號。第二階段（hooks LABv2.133.x+): 2.1 RE 傷害計算、2.2 魔力之泉回合計時鉤、2.3 惡魔交易傷害鉤、2.4 RT2 鉤。與 VISION 的協同效應： §10.4 QH 削弱（補充 — 技能強化 + QH 削弱 = 多元攻擊），§10.5 法術（不調整，下個版本），§10.6 OD 露露狂怒（下個版本），§10.8 破界 HP+MP 融合（本 1.2 階段已確定），§10.9 奧隆隱藏技能（強化 — 破界極限 + 惡魔交易 + 破界增益 = 「不死之身、敢於冒險的奧隆」），§10.10 魔法速度（Spell Spring 待處理清單），§10.11/§10.13（下輪處理），路徑 4 黑魔法擴展（間接 — 基礎原版設定為 ≥96 個法術提供背景）。 待解決問題清單： 法術泉正等待下一個空缺插槽（犧牲候選名單：插槽 18 雙倍 AP、19 三倍 AP、21 扒手、22 盜賊大師 — 進度/戰利品作弊手段）；角色專屬身分狀態/突破銳度 §10。9. 勿觸碰： 寫入端（writer-side）的 writer/hook/probe/DLL/csproj。檔案：FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.7→v2.130.3.8);docs/reverse/FFX_SPIRA_REFORGE_VANILLA_OFFENSIVE_REBALANCE_2026-06-16.md（新內容，約280行，7個節：§0 簡短事實，§1 標準大屠殺診斷，§2 整合包 c 包含表 16 技能 + 自動能力清理 + MP 球體、§3 技術性注意事項（6 項）、§4 實施計畫（第 1 階段與第 2 階段）、§5 待解決問題、§6 交付版本、§7 交叉參考）；CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md+mods/Spira Reforge/VISION_AND_ROADMAP.md（下一頁）。[上一頁：v2.130.3.7參考目錄]