Atualização 2.123

v2.123.0.0BETAMINORWakka

Arena+ Multi Dark Aeon sidecar de progresso + reader/writer em FfxHooksDll

• (a) novo sidecar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (schema v1 da seção 15 do dossiê) com flags{} cleared/first_clear_utc/last_clear_utc/clear_count/evidence + tier_lock_state{} opcional (LOCKED/READY/CLEARED); chaveado por progress_flag do catálogo (arena.dark.<slug>); README documenta regras de uso e mapeamento catálogo<->sidecar. (b) Novo módulo RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp} — reader/writer best-effort JSON (sem deps), ArenaProgress_Initialize/IsRowCleared/RecordCleared gated por arena_plus_progress.flag (off default), busca $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> fallback <DllDir>/spira-arena-progress.json. Persistência atômica via .tmp + MoveFileEx. Env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 deixa devs semearem flags manualmente para teste UI. (c) dllmain.cpp chama ArenaProgress_Initialize em InstallHooks após o overlay do catálogo. (d) A detecção real de vitória ainda não está NOT ligada — mantida como TODO documentado; a Fase 6 do plano reconhece essa divisão, e o API público ArenaProgress_RecordCleared(flag, note) está pronto para um futuro consumidor de hook battleEnd. Build PolyHook 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: receita penta stretch + dry-run PASS

• (receita/docs, sem mudança de comportamento shipada). Plano Fase 7 (stretch). Novo RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + doc de receita mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md cobrindo Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut em nagi05_70 (alias Dark Yojimbo, 5 dos 6 monPos vanilla, slot 5 não usado). Pipeline ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS contra nagi05_70.bin.spiraforge.bak: chunk2 = 5 actors @ 0x18A4 (16 bytes), chunk3 = 6 monLive @ 0x1B04 (96 bytes, position-only), re-read confirma slots. Linha do catálogo dark-penta-elemental-five atualizada: id renamed, token_mode blocked->alias (alias é tecnicamente legítimo), evidence anota dry-run PASS, rt2_status permanece blocked (sem prova in-game) — só RT0 byte-safety provado. NOT promove penta a uma feature: permanece stretch até quartet RT2 PASS + tentativa in-game documentada via _RT2_CHECKLIST.md. Plano de promoção 4-way (PASS / blocked-by-camera / blocked-by-ai / blocked-by-crash) na receita MD

v2.123.0.0

v2.123.0.2BETAREVISIONLulu

Spira Reforge: Capture Cascade Fase A lockdown — 8 decisões travadas + 3 artefatos de preparo

• (design/doc/schema, sem código). Sessão de planejamento do Halyson 2026-06-16 fechou as 8 decisões em aberto do §7 do doc Capture Cascade (v2.122.0.1): D1 Magus Sisters → Mushroom Rock Road (não Gagazet — nostalgia perversa pela Operação Mi'ihen + 3 fayths trágicos, uma área mid-early que vira T7 endgame); D2 Bestiary F7 → aba dedicada + popup post-battle, com slot para GPT-generated art por DA capturado; D3 patrol non-fleeable; D4 drops = 1× shard temático + 1× consumível raro; D5 captura conta como kill++ (desbloqueia a escada vanilla 1v1 AND SIN); D6 sem prompt de confirmação; D7 safe-zone respeitado tanto pelos mobs T7 quanto pelo patrol DA; buff D8 anunciado só na primeira entrada post-capture. A Fase A entrega 3 artefatos: (a) schema de sidecar mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (capturas DA + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — de-conflicted com o sidecar Jarvis-ARENA de spira-arena-progress.json de v2.123.0.0, que é dono dos clears de linha da arena); (b) mapa de região mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → área canônica + patrol_subzones + safe_zones + notas narrativas); (c) plano de spike da Fase B RE docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (playbook de 1–2h para localizar o bit capturable no header m### via diff hex + IDA opcional). Doc mestre atualizado §7 (lockdown) + §4 (mapa final) + §13 (refs de artefatos). VISION_AND_ROADMAP §11 ganhou bloco "Fase A artefatos". Plano de 4 fases definido (A=lockdown feito, B=spike RE em chat separado, C=writer Cap-1 em v0.5, D=piloto RT2)

v2.123.0.1

v2.123.1.0BETAPATCHLulu

Ronso Mana: correção Overdrive re-arm (bug #2) + command-ring RE de 2º pass

• (corrige um bug de comportamento runtime-hook + RE/docs). Bug #2 ("Ronso Rage não re-select indo para a esquerda após um uso"): RonsoManaHook.cpp baixou o gate de exibição OD de gateMin=100 (vanilla "barra cheia") para 40 (= kRonsoSkillCosts[0], o custo Jump do Overdrive). Com o gate em 100, após um único uso parcial (drain 40 → charge 60 < 100) toda função de força return saía cedo e OD sumia até a barra encher para 100 — contradizendo o próprio pool parcial 0–255. Greyout Per-row (G3) ainda bloqueia habilidades inacessíveis (custo > charge atual), então baixar o gate é seguro. Banner de instalação corrigido hudSafe=19→hudSafe=21 (o log imprimia a versão errada, atrapalhando o diagnóstico). RE de 2º pass (após RT2 hudSafe=20 FAIL): decompile completo de 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + um offline command.bin dump provou: (a) a linha de comando do runtime = header 0x14 + struct de arquivo (âncora byte[25]=CharacterUser=file+5), então byte[22]=MenuFlgs etc; (b) cmd282 (Ronso Rage) IS o header do anel OD (MenuFlgs=0x11→header, MainMenu=True, ODCat=19, MenuLeft) — a leitura antiga "282→leaf cat4 +296" estava errada; (c) em 79BB70 loop-2, um header com Misc2 MenuLeft (0x10) → dword[28]&0x1000 → cai no array BSS +40, NOT +0 (headers visíveis) — por isso forçar 282 disponível nunca o mostra no anel do meio; (d) resolve=-1 é um red herring (o anel principal aparece mesmo com -1); (e) 797D60 case 3 lê um blob per-actor (actor+0xF7C); (f) 79B500 escreve actor[0x590]=save[+16] cedo — nosso forcing em RefreshMenu_Shim (Prepare antes do trampolim) é sobrescrito/apagado por esse store → explica por que replicar o save-edit falhou. Renames .i64: 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ comentários em 79BB70/797D60/79B500). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Próximo passo (bug #1): experimento de captura save-edited-vs-forced para diff do delta exato. Fix #2 RT2 Needs Testing

v2.123.0.2

v2.123.1.1BETAREVISIONLulu

Spira Reforge: prompt de handoff da Fase B do Capture Cascade (spike RE para o bit `capturable`)

• (doc de handoff, sem código). Novo docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md — prompt completo para subir um chat dedicado para o Capture Cascade Fase B. Lane identity: Jarvis-CAPTURE-RE. Missão: localizar offset+bit capturable no header m###.bin via diff hex (Sinscale ↔ Dark Valefor + 2 amostras de validação) + IDA opcional CanCapture cross-check. Entregáveis: tabela de evidência ≥4 linhas + doc RESULT + atualização plan-doc + atualização do doc mestre Cap Cascade + PORT_STATUS + seu próprio bump REVISION. Non-goals explícito (NOT implementa writer, NOT toca runtime, NOT captura in-game). Estimativa honesta 1.5–2h. Desbloqueia Cap-1 (Fase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISIONLulu

Spira Reforge: convenção de nome duplo do Capture Cascade (codename interno + marca player-facing)

• (design/doc, sem código). Halyson travou em 2026-06-16: a feature mantém dois nomes com papéis distintos. Interno (docs técnicos, changelogs, campos de schema, IDs, prompts, lane signatures) permanece Capture Cascade (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). Player-facing (popups, README do mod, página do mod) = Yoke of Spira (EN) / Jugo de Spira (PT) — ressonância bíblica/Yevon (Mateus 11:30 "porque o meu jugo é suave") ecoa o tema teocrático do FFX vanilla. Aba F7 Conquests = The Yoke (EN) / O Jugo (PT). String de popup padrão: EN "Besaid é 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." O doc Capture Cascade ganhou §0 (tabela de convenção de nomes + racional Microsoft Threshold/Redstone). VISION_AND_ROADMAP §11 ganhou a tabela de 3 contextos com cross-link

v2.123.1.1

v2.123.2.0BETAPATCHLulu

Ronso Mana: root-cause FIX do anel de comando — a base do ring buffer nunca foi dereferenciada (bug #1)

• (corrige um bug de comportamento runtime-hook + RE). O achado: o buffer command-ring é runtime-allocated; seu ponteiro absoluto vive numa célula BSS (*(u32*)0x2310CD8). 7AEFC0/79BB70 fazem mov edi,[cell] (DEREF) antes de indexar +20592 (sort scratch) / +1144*slot (anel per-actor). RonsoManaHook.cpp usava RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 cru, sem o deref, e errado por 0x1000 — então ALL escritas de anel (template, header per-slot +0, linha OD +296) em hudSafe 11..21 caíam numa região estática BSS que nunca era o buffer exibido ao vivo. Isso explica por que nenhuma injeção de anel BSS apareceu, e por que CopyMenuTemplate_Shim (o detour 7AEFC0) sempre early-returned (delta = slotPtr - ringBase nunca era múltiplo de 1144). Correção: novo RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (a célula de ponteiro real, tirada do imm32 de mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() agora dereferencia (*(u32*)(g_base+RVA), null-checked quando ainda não alocado). Com isso, PatchKimahriCommandRingUi (+0 header), PatchKimahriMainMenuOverdriveRow (+296 OD) e CopyMenuTemplate_Shim (+296 post-sort) escrevem no anel real pela primeira vez. RE provado (IDA): 7AD980 = ordena um array por prioridade (key=*(u8*)(GetCommandEntryById+92), scratch=ring+20592); 7AEFC0 o chama 8× (uma por categoria) para ordenar o anel per-slot. Renames .i64: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + comentário na célula de ponteiro 0x2310CD8. DIAG (hudSafe=22): DumpKimahriRingState loga um readback do +0/+296 real em G0-finalize para confirmar se o cmd OD codificado (0x311A) cai. Build PolyHook PASS (10/10), deploy apply-mode. RT2 Needs Testing (bug #1: OD no anel do meio). 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 — bit `capturable` em `m###.bin` LOCATED (spike da Fase B RE, doc-only)

• (RE/doc, sem mudança de comportamento; encadeado em cima de v2.123.3.0 MINOR de uma lane paralela — este REVISION é puramente doc/RE e não compete com aquele MINOR). Capture Cascade Fase B spike entregue doc-only: o byte que controla capturable=true|false em todo m###.bin foi localizado byte-precise e validado com 58 amostras. Veredito: posição = bytes[StatSheetPointer + 0x78] (onde StatSheetPointer = uint32_le(bytes[0x0C])); semântica = 0xFF (sbyte -1) significa não capturável, 0x00..0x67 (sbyte 0..103) significa capturável (índice de slot na tabela de 104 slots do Monster Arena vanilla); padding bytes[StatSheetPointer + 0x79] é sempre 0x00. Cadeia de evidência cruzada (a) editor legado v1.4 FFXmon4.ini (rótulo "Capture index" como hex 16-bit, 00FF = uncap), (b) struct atual C# FfxLib/Monster/Monster_StatSheet.cs linhas 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) binding UI ao vivo MonEditor_Control.axaml linha 466 ("Capture index (Arena)"), (d) layout estrutural completo (MonsterHeaderFile header de 0x40 bytes + seção StatSheet + Monster_StatSheet StatBlock onde ArenaId fica no offset +0x64 relativo ao StatBlock que começa em section + 0x14 → file-relative +0x78). Prova: 21/21 capturáveis bateram com o slot esperado (incl. match byte-exact com FFXmon4.ini para m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 uncap de boss = 0xFF, 10/10 Dark Aeons (m334..m343) = 0xFF, 3/3 entradas Penance (m344..m346) = 0xFF. Correção operacional importante: a suposição antiga "DA vivem em m106..m113" estava WRONG — os DAs reais são m334..m343 (provado em FfxLib/Dictionaries/Monster_Dictionary.cs linhas 343-356), com Magus Sisters como 3 entradas separadas (m341/m342/m343). DOC-ONLY: nada foi escrito em m###.bin/DLL/runtime/save/hook nesta sessão. Não executado: confirmação IDA do gatekeeper CanCapture() (Step 3 opcional do PLAN); cross-validation contra FFX Extracted\ tree (recomendado, mas não bloqueante — 58/58 modificados já coincidem 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 (doc de RESULTADO completo com receita de writer da Fase C), 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. O PLAN original ganhou um banner BLOQUEIO RESOLVIDO + IDs de DA corrigidos. 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 (lane paralela; a entrada de changelog deles virá quando a lane shipar)]

v2.123.4.0BETAPATCHLulu

Nul Ward: superfície de menu de ensino, VEREDITO da RE + CORREÇÃO do hook limitado ao menu (estava corrigindo o `cmp 320` errado)

• (corrige um bug de comportamento em NulWardTeachHook + RE provado no .i64 real; incremento PATCH → redefinições de revisão; o HEAD v2.123.3.1 anterior era uma REVISÃO de lane paralela). Passe completo de RE (idalib MCP no FFX_recon.i64 real) verificando se ensinar Radiant(320)/Umbral(321) via sphere grid + um command.bin ampliado funciona de ponta a ponta. Cadeia COMPROVADA: (1) FFX_GrantCommandToCharacter@0x785D10 roteia id≥96 para o banco para todo o grupo g_PartyWideCommandBank@0x11307FC — 16 palavras/256 bits = IDs 96..351; Radiant=word14 bit0, Umbral=word14 bit1; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEMEIA o banco inteiro para actor+0x670 (loop de cópia termina em g_CmdAggregateAvailArrays@0x113081C → banco = 16 words); (3) FFX_Btl_IsCommandAvailable@0x79AD40 lê a palavra 818+id/16 do actor (id320→byte 0x68C bit0) — consistente; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 chama grant(char, node.LearnedMove, 1) → um nó com LearnedMove=0x3140/0x3141 ensina isso; (5) persistência via FFX_IsCommandLearnedPersistent@0x7850E0 lê o mesmo bit. BUG ENCONTRADO E CORRIGIDO: BuildActorCommandMenu tem 3 cmp r32,140h (dois 81 FE=esi nos loops agregados, um 81 FF=edi no loop PLACEMENT que insere o id no submenu de magia branca). Somente a comparação de posicionamento controla se 320/321 chegam ao menu; o antigo NulWardTeachHook corrigia apenas a primeira ocorrência (81 FE, uma operação sem efeito para disponibilização). CORREÇÃO: agora ele corrige todas as ocorrências de cmp r32,140h→0x142 (recompilação do PolyHook PASS). Riscos de RT2 documentados: (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 é a tabela de intervalos com a alternativa para cmd 0 — o command.bin ampliado precisa estender o intervalo que cobre 320/321 (caso contrário, Radiant resolve para cmd 0); (b) a persistência depende de o limite/mapa especial de ply_save ser amplo o suficiente para cobrir bit 224/225 (palavra 14). Projeto: id≥96 = para todo o grupo (o grupo inteiro aprende isso), não por personagem (limite de 96 bits). Renomeações + comentários aplicados ao .i64 (FFX_Btl_IsCommandAvailable, FFX_Btl_InitPartyWideCommandBank, FFX_Btl_PrepareSaveCommandState, FFX_Btl_BuildAggregateChildList, g_PartyWideCommandBank, g_PerCharCmdMenuState, etc.). Documento: 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`) — corrige "nem dá para ir LEFT em Overdrive a menos que a barra esteja cheia"

• (corrige um bug de comportamento runtime-hook + RE). O achado (provado por log + decompile): FFX acopla "Overdrive utilizável" a uma barra cheia (charge==max) e re-checks isso PER-FRAME no renderer HUD/menu — fora dos nossos hooks. O spoof transiente hudSafe=23 setava max:=charge em volta de cada trampolim, mas restaurava max=255 logo depois (EndKimahriMaxSpoof), então o frame em que o anel é desenhado via max=255 (barra não cheia) → Overdrive oculto / LEFT bloqueado. Evidência de log RT2 (hudSafe=23): G0 menu charge=100 max=100 (o spoof DID funcionou durante o build) mas OD ainda nunca apareceu; IsOdReady ... vanilla=1 ->1 (os bits 0x590 estavam setados, até pelo vanilla) e ainda assim foi bloqueado. RE deste pass (idalib MCP): 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — ambos forçados e =1, NOT o gate; 792AB0 (FFX_Btl_BattleMenuInputDispatch) constrói o anel kind=12 OD quando 79AF70 (então o anel OD existe); 799AD0/799D60/7996E0/799830 são resolvers target-mask, não o gate OD-full. Conclusão: o gate vivo é a comparação per-frame charge==max no renderer — fora do alcance de um spoof transiente. Correção: ApplyKimahriRuntimePoolMax agora fixa persistentemente max:=charge enquanto charge>=gateMin (a barra lê 100% cheia para cada verificação per-frame enquanto o menu de comando dele está aberto; o ATB/CTB está pausado durante a entrada de comando, então nenhum ganho de overdrive é perdido); abaixo do limiar devolve o pool real (255) para a barra reencher em direção a 0–255. O spoof transiente Begin/End está aposentado (no-ops); o shim de dispatch agora chama o pin persistente. Tradeoff conhecido (RT2): a barra lê cheia enquanto OD é utilizável; o ganho OD pode pausar enquanto a carga fica na faixa utilizável (revisitar se RT2 mostrar um stall de ganho — escopar o pin para menu-only). Build PolyHook PASS (10/10), deploy apply-mode (SHA B092B4C6). RT2 Needs Testing (ir LEFT + usar Ronso Rage com charge parcial). 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: faixa command.bin PROVEN (sem patch de exe) + codificação LearnedMove FIX no editor + verifier offline

• (corrige um bug de comportamento SphereGridExplorer do editor + nova prova/verifier offline + RE). DLL intocado (a lane Ronso Mana é a que usa) — só C#/editor/IDA. RT2 risco #1 ELIMINATED offline: RE provou que FFX_Kernel_LoadFileToTable@0x781E00 (case 0 "command") carrega command.bin verbatim num ponteiro global (g_CommandKernelTable@0x112A92C, full-file memcpy) — sem síntese de faixa. FFX_Table_GetEntryByIdRange@0x7AB890 lê o header de faixa direto dos bytes do arquivo, mapeando exatamente em 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. Como o command.bin crescido escreve EntryCount-1=321, ids 320/321 ∈ [0,321] → resolvem para exatamente as linhas Radiant/Umbral anexadas. Sem patch de exe/DLL. Novo CommandKernelLookupVerifier (FfxLib/Ability) repete a matemática exata do engine contra os bytes crescidos e é ligado ao gate --nul-ward-static (check engine_lookup_resolves: prova offline de que GetCommandEntryById(320/321) NOT não cai no fallback cmd0). Editor FIX (SphereGridExplorer): o dropdown LearnedMove guardava o id cru (0x0140), mas on-disk é o id codificado (0x3000|id) — provado empiricamente por SphereGridRt2Lab (Armor Break em panel.bin = 0x3012) e exigido pelo gate (cmd & 0xFFFFF000)==0x3000 do grant. O dropdown agora emite 0x3000|id (Radiant→0x3140, Umbral→0x3141) e resolve nomes mascarando & 0xFFF, então o usuário pode colocar os wards no sphere grid e eles realmente ensinam (antes armazenava 0x0140 e o grant rejeitava). Renames .i64: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + comentários provados em 0x781E00/0x7AB890/0x790AE0 (salvos via idalib_save). Build C# PASS (0 erros). Doc: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISIONYuna

Finalização balística Aurora: kickoff da Fase 0 (reconciliação de docs + correção de comentário legado + badge de variante UNVERIFIED)

• (docs + anotação RE/honestidade; sem feature nova; sem bump comportamental). Plano persistido em .cursor/plans/aurora_balistica.plan.md (10 fases, escopo Halyson-confirmed A+B: 5 RT2s ativos + spike IDA W2S + spike variant-selector IDA). Este REVISION shipa só a Fase 0 (reconciliação de docs antes da instrumentação de probe). Quatro edições: (1) linha PORT_STATUS.md "Aurora Chamber" — texto Honestidade corrigido: era transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, agora reflete o IDA-proof de 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 topo — novo bloco Atualizacao 2026-06-16 (Aurora finalizacao balistica) resumindo o estado real da Aurora reconciliado contra A15 + ordem RT2 confirmada (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, depois spike IDA). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js — header JSDoc (linhas 9-10) corrigido: era RAW battle-local - design-only/UNCALIBRATED, agora 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 (mostrado em SceneDetail quando _resolver.ResolveScenes(MapKey) retorna mais de 1 variante) agora anexa runtime selector UNVERIFIED ao lado da lista _a/_b/_c, para os usuários saberem que a Chamber renderiza a variante que o catálogo escolher enquanto o seletor real (story-flag -> variante) não foi RE-proven — veja A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. Não toca: probe, writers, gates offline, FfxHooksDll. Próximo (Fase 1): implementar aurora-calib-v2 em RuntimeTools/FfxDinput8Probe/ctl/Program.cs com saída CSV/JSON (identity_dx/dy/dz/rms residual, flipz_*, yaw180_*, enum winner, height_0x534, rota + id de batalha) — spec em docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md. Fase 0 RT2: N/A (docs-only + string UI)

v2.123.5.0