Actualización 2.123

v2.123.0.0BETAMINORWakka

Archivo auxiliar de progreso Arena+ Multi Oscuro Aeon + lector/escritor en FfxHooksDll

• (a) nuevo archivo auxiliar mods/Spira Reforge/arena/progress/spira-arena-progress.{json,schema.json} (expediente sec. 15 esquema v1) con flags{} borrado/first_clear_utc/last_clear_utc/clear_count/evidencia + opcional tier_lock_state{} (BLOQUEADO/LISTO/BORRADO); con clave progress_flag del catálogo (arena.dark.<slug>); README documenta las reglas de uso y el catálogo<->mapeo de archivo auxiliar. (b) Nuevo módulo RuntimeTools/FfxHooksDll/hooks/ArenaProgressSidecar.{h,cpp}: lector/grabador JSON de mejor esfuerzo (sin departamentos), ArenaProgress_Initialize/IsRowCleared/RecordCleared controlado por arena_plus_progress.flag (desactivado predeterminado), búsquedas $FFXHOOKS_ARENAPLUS_PROGRESS_PATH -> <DllDir>/mods/Spira Reforge/arena/progress/... -> respaldo <DllDir>/spira-arena-progress.json. Persistencia atómica a través de .tmp + MoveFileEx. Env FFXHOOKS_ARENAPLUS_FAKE_CLEAR=flag1,flag2 permite a los desarrolladores generar indicadores manualmente para las pruebas de UI. (c) dllmain.cpp llama a ArenaProgress_Initialize en InstallHooks después de la superposición del catálogo. (d) La detección de victoria REAL todavía NO está cableada: se mantiene como un TODO documentado; La fase 6 del plan reconoce esta división y el público API ArenaProgress_RecordCleared(flag, note) está listo para un futuro consumidor de ganchos battleEnd. PolyHook compilación PASS 10/10 cpp. RT2 en el juego Necesita TEST (a través de FFXHOOKS_ARENAPLUS_FAKE_CLEAR)

v2.122.0.1

v2.123.0.1BETAREVISIONWakka

Arena+ Multi Oscuro Aeon: receta penta-stretch + ensayo PASS

• (receta/documentos, no se envió ningún cambio de comportamiento). Plan Fase 7 (estiramiento). Nuevo RuntimeTools/ArenaMultiBossLab/recipes/dark_penta_elemental_five.json + documento de receta mods/Spira Reforge/arena/recipes/dark_penta_elemental_five.md que cubre Dark Valefor + Dark Ifrit + Dark Ixion + Dark Shiva + Dark Bahamut en nagi05_70 (alias Yojimbo oscuro, 5 de 6 monPos básicos, ranura 5 sin usar). Canalización ArenaMultiBossLab --recipe dark_penta_elemental_five --dry-run PASS contra nagi05_70.bin.spiraforge.bak: chunk2 = 5 actores @ 0x18A4 (16 bytes), chunk3 = 6 monLive @ 0x1B04 (96 bytes, solo posición), re-leer confirma ranuras. Fila del catálogo dark-penta-elemental-five actualizada: id renombrado, token_mode blocked->alias (el alias es técnicamente legítimo), notas evidence en seco PASS, rt2_status permanece como blocked (sin prueba en el juego): solo seguridad de bytes RT0 demostrado. NO promueve penta a una característica: permanece extendido hasta el cuarteto RT2 PASS + intento documentado en el juego a través de _RT2_CHECKLIST.md. Plan de promoción de 4 vías (PASS / bloqueado-por-cámara / bloqueado-por-ai / bloqueado-por-fallo) en el MD de recetas

v2.123.0.0

v2.123.0.2BETAREVISIONLulu

Spira Reforge: Capture Bloqueo de fase A en cascada: 8 decisiones bloqueadas + 3 artefactos de preparación

• (diseño/doc/esquema, sin código). La sesión de planificación de Halyson del 2026-06-16 cerró las 8 decisiones abiertas del §7 del documento Capture Cascada (v2.122.0.1): D1 Hermanas Magus → Mushroom Rock Road (no Gagazet: nostalgia perversa por la Operación Mi'ihen + 3 fes trágicas, un área temprana que cambia al final del juego T7); D2 Bestiario F7 → pestaña dedicada + ventana emergente posterior a la batalla, con una ranura para arte generado por GPT por DA capturado; D3 patrulla no huible; D4 gotas = 1× fragmento temático + 1× consumible raro; D5 captura cuenta como muerte++ (desbloquea Vainilla 1v1 Y SIN escalera); D6 sin mensaje de confirmación; Zona segura D7 respetada tanto por las turbas T7 como por la patrulla DA; Se anunció la mejora D8 solo en la primera entrada después de la captura. La Fase A ofrece 3 artefactos: (a) esquema de archivo auxiliar mods/Spira Reforge/save-schemas/spira-reforge-flags.schema.json v1 (capturas de DA + sin_mode.region_overrides + conquistas_seen + capture_cascade.patrol_kills/first_entry_seen — sin conflicto con el archivo auxiliar Jarvis-ARENA de spira-arena-progress.json de v2.123.0.0, propietario de Arena Fila se aclara); (b) mapa de región mods/Spira Reforge/arena/dark-aeon-region-map.json (8 DA → área canónica + patrol_subzones + safe_zones + notas narrativas); (c) Plan de picos RE de fase B docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_PLAN_2026-06-16.md (libro de jugadas de 1 a 2 horas para ubicar el bit capturable en el encabezado m### mediante diferencia hexadecimal + IDA opcional). Documento maestro actualizado §7 (bloqueo) + §4 (mapa final) + §13 (referencias de artefactos). VISION_AND_ROADMAP §11 obtuvo un bloque "Artefactos de fase A". Plan de 4 fases definido (A=bloqueo finalizado, B=RE pico en un chat separado, C=escritor Cap-1 en v0.5, D=RT2 piloto)

v2.123.0.1

v2.123.1.0BETAPATCHLulu

Ronso Mente doble: Overdrive Corrección del brazo re (error n.º 2) + 2.º anillo de comando pasada RE

• (corrige un error de comportamiento del enlace de tiempo de ejecución + RE/docs). Error n.º 2 ("Técnica robada no selecciona re para ir a la izquierda después de un uso"): RonsoManaHook.cpp bajó la puerta de visualización OD de gateMin=100 ("barra completa" vainilla a 40 (= kRonsoSkillCosts[0], el costo de Overdrive Salto). Con la puerta en 100, después de un único uso parcial (drenaje 40 → carga 60 < 100) cada función forzada returned temprano y OD desapareció hasta que la barra se volvió a llenar a 100, lo que contradice el grupo parcial 0-255 en sí. La atenuación por fila (G3) aún bloquea habilidades inasequibles (costo > carga ACTUAL), por lo que bajar la puerta es seguro. Se corrigió el banner de instalación hudSafe=19→hudSafe=21 (el registro imprimió la versión incorrecta, lo que dificultó el diagnóstico). 2nd-pasar RE (después de RT2 hudSafe=20 FALLAR): descompilación completa de 79BB70/79B500/7B6BD0/79AD40/7A07D0/797D60 + un volcado fuera de línea de command.bin demostró: (a) la fila de comando de tiempo de ejecución = encabezado 0x14 + estructura de archivo (ancla byte[25]=CharacterUser=archivo+5), entonces byte[22]=MenuFlgs etc; (b) cmd282 (Técnica robada) ES el encabezado del anillo OD (MenuFlgs=0x11→encabezado, MainMenu=True, ODCat=19, MenuLeft): la antigua lectura "282→leaf cat4 +296" era incorrecta; (c) en 79BB70 bucle-2, un encabezado con Misc2 MenuLeft (0x10) → dword[28]&0x1000 → aterriza en la matriz BSS +40, NO +0 (encabezados visibles), razón por la cual forzar 282 disponibles nunca lo muestra en el anillo central; (d) resolve=-1 es una pista falsa (el anillo principal muestra par con -1); (e) 797D60 case 3 lee un blob por actor (actor+0xF7C); (f) 79B500 escribe actor[0x590]=save[+16] temprano: nuestro forzado en RefreshMenu_Shim (Prepararse antes del trampolín) es sobrescrito/borrado por esa tienda → explica por qué falló la replicación de la edición guardada. .i64 cambia el nombre: 7B6BD0→FFX_Btl_UI_BuildOverdriveTargetList, 79B500→FFX_Btl_RefreshActorMenuState (+ comentarios sobre 79BB70/797D60/79B500). Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §8. Siguiente paso (error n.° 1): un experimento de captura guardada, editada y forzada para diferenciar el delta exacto. Solución n.° 2 RT2 Necesita pruebas

v2.123.0.2

v2.123.1.1BETAREVISIONLulu

Spira Reforge: Capture Mensaje de transferencia de fase B en cascada (pico RE para el bit `capturable`)

• (documento de transferencia, sin código). Nuevo docs/ai/PROMPT_JARVIS_CAPTURE_BIT_M_HEADER_RE_SPIKE_2026-06-16.md: mensaje completo para activar un chat dedicado para Capture Cascada Fase B. Identidad de carril: Jarvis-CAPTURE-RE. Misión: localizar desplazamiento+bit capturable en el encabezado m###.bin mediante diferencia hexadecimal (Escoria ↔ Valefor oscuro + 2 muestras de validación) + verificación cruzada opcional de IDA CanCapture. Entregables: tabla de evidencia de ≥4 filas + documento RESULTADO + actualización del documento plan + actualización del documento maestro Cap Cascada + PORT_STATUS + su propio aumento REVISIÓN. No objetivos explícitos (NO implementa el escritor, NO toca el tiempo de ejecución, NO captura en el juego). Estimación honesta 1.5–2h. Desbloquea Cap-1 (Fase C, v0.5)

v2.123.1.0

v2.123.1.2BETAREVISIONLulu

Spira Reforge: Capture Convención de nomenclatura dual en cascada (nombre en clave interno + marca orientada al jugador)

• (diseño/doc, sin código). Halyson bloqueado el 2026-06-16: la función mantiene dos nombres con funciones distintas. Interno (documentos técnicos, registros de cambios, campos de esquema, ID, indicaciones, firmas de carril) permanece Capture Cascada (Cap-1/2/3, dark_aeons.captured.<id>, capture_cascade.patrol_kills, arena.dark.<id>). De cara al jugador (ventanas emergentes, mod README, página mod) = Yugo de Spira (EN) / Jugo de Spira (PT) — resonancia bíblica/Yevon (Mateo 11:30 "porque mi yugo es fácil") hace eco del tema teocrático vainilla de FFX. F7 Pestaña Conquistas = El Yugo (EN) / O Jugo (PT). Cadena emergente predeterminada: EN "Besaid está ahora bajo el yugo de Valefor oscuro" / PT "Besaid está sollozando o jugo de Valefor oscuro"; en-captura battletext ES "Valefor oscuro ha sido domesticado. Spira tiembla." / PT "Valefor oscuro foi domado. Spira siente o temblor." Capture Documento en cascada obtenido §0 (tabla de convenciones de nomenclatura + fundamento de Microsoft Umbral/Redstone). VISION_AND_ROADMAP §11 obtuvo la tabla de 3 contextos con enlace cruzado

v2.123.1.1

v2.123.2.0BETAPATCHLulu

Ronso Mente doble: ARREGLO de causa raíz del anillo de comando: nunca se eliminó la referencia a la base del búfer del anillo (error n.° 1)

• (corrige un error de comportamiento del enlace de tiempo de ejecución + RE). El hallazgo: el búfer del anillo de comandos está asignado en tiempo de ejecución; su puntero absoluto vive en una celda BSS (*(u32*)0x2310CD8). 7AEFC0/79BB70 haga mov edi,[cell] (DEREF) antes de indexar +20592 (ordenar desde cero) / +1144*slot (anillo por actor). RonsoManaHook.cpp usó RVA_FFX_BATTLE_COMMAND_RING_BSS_BASE=0x1F0FCD8 sin formato, sin deref y desactivado por 0x1000, por lo que TODAS las escrituras en anillo (plantilla, encabezado por ranura +0, fila OD +296) en hudSafe 11..21 aterrizaron en una región BSS estática que nunca fue el búfer mostrado en vivo. Esto explica por qué nunca apareció ninguna inyección de anillo BSS y por qué CopyMenuTemplate_Shim (el desvío 7AEFC0) siempre regresaba antes (delta = slotPtr - ringBase nunca fue un múltiplo de 1144). Solución: nuevo RVA_FFX_BATTLE_COMMAND_RING_BASE_PTR=0x1F10CD8 (la celda de puntero REAL, tomada del imm32 de mov edi,[..]@0x7AEFC8) + BattleCommandRingUiBase() ahora desreferencia (*(u32*)(g_base+RVA), marcado como nulo cuando aún no está asignado). Con esto, PatchKimahriCommandRingUi (+0 encabezado), PatchKimahriMainMenuOverdriveRow (+296 OD) y CopyMenuTemplate_Shim (+296 post-clasificación) escriben en el anillo REAL por primera vez. RE probado (IDA): 7AD980 = ordenar una matriz por prioridad (key=*(u8*)(GetCommandEntryById+92), borrador=ring+20592); 7AEFC0 lo llama 8× (uno por categoría) para ordenar el anillo por ranura. .i64 cambia el nombre: 7AEFC0→FFX_Btl_UI_SortCommandRingSlot, 7AD980→FFX_Btl_UI_SortCmdRingArrayByPrio + comentario en la celda del puntero 0x2310CD8. DIAG (hudSafe=22): DumpKimahriRingState registra una lectura del +0/+296 REAL en G0-finalize para confirmar si llega el cmd OD codificado (0x311A). PolyHook compilación PASS (10/10), implementación en modo de aplicación. RT2 Necesita pruebas (error n.º 1: OD en el anillo central). Documento: 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 Cascada Cap-1 — `capturable` bit en `m###.bin` UBICADO (Pico RE Fase B, solo documento)

• (RE/doc, sin cambios de comportamiento; encadenado encima de v2.123.3.0 MENOR desde un carril paralelo; este REVISIÓN es puramente doc/RE y no compite con ese MENOR). El pico de fase B en cascada de Capture se entregó solo en documentos: el byte que controla capturable=true|false en cada m###.bin se ubicó con precisión de byte y se validó con 58 muestras. Veredicto: posición = bytes[StatSheetPointer + 0x78] (donde StatSheetPointer = uint32_le(bytes[0x0C])); semántica = 0xFF (sbyte -1) significa incapturable, 0x00..0x67 (sbyte 0..103) significa capturable (índice de ranura en la tabla de 104 ranuras del Monster Arena estándar); el relleno bytes[StatSheetPointer + 0x79] es siempre 0x00. Cadena de evidencia cruzada (a) editor heredado v1.4 FFXmon4.ini (etiqueta "índice Capture" como hexadecimal de 16 bits, 00FF = destapar), (b) estructura C# ACTUAL FfxLib/Monster/Monster_StatSheet.cs líneas 49-50 ([Data] public sbyte ArenaId + [Data] public byte ArenaIdPadding), (c) en vivo UI vinculante MonEditor_Control.axaml línea 466 ("índice Capture (Arena)"), (d) diseño estructural completo (MonsterHeaderFile encabezado de bytes 0x40 + sección StatSheet + Monster_StatSheet StatBlock donde ArenaId se encuentra en el desplazamiento +0x64 relativo al StatBlock que comienza en section + 0x14 → relativo al archivo +0x78). Prueba: 21/21 capturables coincidieron con la ranura esperada (incluida la coincidencia exacta en bytes con FFXmon4.ini para m044=0x28/m045=0x29/m046=0x2A/m193=0x55/m194=0x56), 16/16 boss uncap = 0xFF, 10/10 Eones oscuros (m334..m343) = 0xFF, 3/3 entradas Verdugo final (m344..m346) = 0xFF Corrección operativa importante: la antigua suposición de "DA en vivo en m106..m113" era INCORRECTA: los DA reales son m334..m343 (probado en FfxLib/Dictionaries/Monster_Dictionary.cs líneas 343-356), con Hermanas Magus como 3 entradas separadas (m341/m342/m343). SOLO DOC: no se escribió nada en m###.bin/DLL/runtime/save/hook en esta sesión. No ejecutado: confirmación IDA del gatekeeper CanCapture() (paso 3 opcional de PLAN); validación cruzada contra el árbol básico FFX Extracted\ (recomendado pero no bloqueado; 58/58 modificados ya coinciden con la expectativa estándar a través de la referencia cruzada FFXmon4.ini). Artefactos: docs/reverse/FFX_SPIRA_REFORGE_CAPTURE_BIT_M_HEADER_RE_RESULT_2026-06-16.md (documento RESULTADO completo con receta de escritura de fase C), work/_capture_re_2026-06-16/parse_capture_offset.ps1 (analizador CLI), work/_capture_re_2026-06-16/dump_arena_id_evidence.ps1 (volcado masivo), work/_capture_re_2026-06-16/capture_re_evidence_summary.json (58 filas), work/_capture_re_2026-06-16/capture_re_evidence_hexdump.txt El documento PLAN original obtuvo un banner BLOQUEIO RESOLVIDO + ID de DA corregidas. PORT_STATUS.md obtuvo una fila "Capture Cascada Cap-1 - capturable bit localizado" mientras el escritor Precisa Testar in-game (Phase C writer) (Fase C, próxima sesión) escribe 1 byte por monstruo mientras preserva la identidad de byte de los 8 campos de identidad adyacentes [anterior: v2.123.3.0 (carril paralelo; su entrada de registro de cambios aterrizará cuando). ellos envían)]

v2.123.4.0BETAPATCHLulu

Nul Ward: enseñanza/superficie de menú RE VEREDICTO + REPARACIÓN del enlace vinculado al menú (estaba parcheando el `cmp 320` incorrecto)

• (corrige un error de comportamiento en NulWardTeachHook + RE probado en el .i64 REAL; golpe de PARCHE → se restablece REVISIÓN; el HEAD v2.123.3.1 anterior era un REVISIÓN de carril paralelo). RE pasada completo (idalib MCP en el FFX_recon.i64 REAL) que responde si enseñar Radiant(320)/Umbral(321) a través de la cuadrícula de esferas + un command.bin adulto funciona de un extremo a otro. Cadena PROBADA: (1) FFX_GrantCommandToCharacter@0x785D10 enruta id≥96 al banco de todo el partido g_PartyWideCommandBank@0x11307FC — 16 palabras/256 bits = identificadores 96..351; Radiante=word14 bit0, Umbral=word14 bit1; (2) FFX_Btl_BuildActorCommandMenu@0x79BB70 SEMILLA todo el banco en actor+0x670 (el bucle de copia termina en g_CmdAggregateAvailArrays@0x113081C → banco = 16 palabras); (3) FFX_Btl_IsCommandAvailable@0x79AD40 lee la palabra actor 818+id/16 (id320→byte 0x68C bit0) — consistente; (4) FFX_SphereGrid_NodeActivateStateMachine@0x8CC300 case21 llama a otorgar(carácter, node.LearnedMove, 1) → un nodo con LearnedMove=0x3140/0x3141 lo enseña; (5) la persistencia a través de FFX_IsCommandLearnedPersistent@0x7850E0 lee el mismo bit. ERROR ENCONTRADO Y CORREGIDO: BuildActorCommandMenu tiene 3 cmp r32,140h (dos 81 FE=esi en los bucles agregados, un 81 FF=edi en el bucle PLACEMENT que inserta el id en el submenú Blanco-magia). Sólo la comparación de ubicación controla si 320/321 llegan al menú; el antiguo NulWardTeachHook parchó la primera coincidencia (81 FE, una operación no operativa para salir a la superficie). REVISIÓN: ahora parchea todos cmp r32,140h→0x142 (PolyHook reconstruye PASS). Riesgos de RT2 documentados: (a) FFX_Kernel_GetCommandEntryById@0x790AE0→FFX_Table_GetEntryByIdRange@0x7AB890 es una tabla de rango con un retroceso a cmd 0: el command.bin crecido debe extender el rango que cubre 320/321 (de lo contrario, Radiant se resuelve en cmd 0); (b) la persistencia depende de que el límite/mapa especial ply_save sea lo suficientemente amplio como para cubrir el bit 224/225 (palabra 14). Diseño: id≥96 = para todo el grupo (todo el grupo lo aprende), no por carácter (límite de 96 bits). Cambia el nombre + comentarios aplicados al .i64 REAL (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 Mente doble hudSafe=24: PERSISTENTE medidor-completo PIN (`max:=charge`) — corrige "ni siquiera puedo ir IZQUIERDO a Overdrive a menos que la barra esté al máximo"

• (corrige un error de comportamiento tiempo de ejecución-GANCHO + RE). El hallazgo (probado por registro + descompilación): FFX acopla "Overdrive utilizable" a un medidor completo (charge==max) y re-comprobaciones PER-FRAME en el HUD/menú renderizador — fuera de nuestros ganchos. La parodia transitoria hudSafe=23 se establece max:=charge alrededor de cada trampolín, pero restauró max=255 justo después (EndKimahriMaxSpoof), por lo que el marco en el que se dibuja el anillo fue visto max=255 (indicador no lleno) → Overdrive oculto / IZQUIERDO bloqueado. RT2 evidencia de registro (hudSafe=23): G0 menu charge=100 max=100 (la parodia HIZO funciona durante la compilación) todavía OD todavía nunca apareció; IsOdReady ... vanilla=1 ->1 (los bits 0x590 estaban configurados, incluso con vainilla) y todavía estaba bloqueado. RE este pase (idalib MCP): 79AF70 = (actor[0x590]>>2)&1, 79AEE0 = (actor[0x590]>>3)&1 — ambos forzados y =1, NO la puerta; 792AB0 (FFX_Btl_BattleMenuInputDispatch) construye el anillo kind=12 OD cuando 79AF70 (por lo que el OD el anillo existe); 799AD0/799D60/7996E0/799830 son objetivo-mask solucionadores, no los OD-completo puerta. Conclusión: la puerta en vivo es la comparación por-fotograma charge==max en el renderizador, fuera del alcance de una parodia transitoria. Solución: ApplyKimahriRuntimePoolMax ahora fija persistentemente max:=charge mientras charge>=gateMin (el indicador indica 100 % lleno por cada por-fotograma verificada mientras su menú de comandos está abierto; el ATB/CTB está en pausa durante la entrada del comando, por lo que no se pierde ganancia de sobremarcha); por debajo del umbral, devuelve el grupo REAL (255) para que el medidor se rellene hacia 0–255. La parodia transitoria Begin/End está retirada (no-ops); la cuña de despacho ahora llama al pin persistente. Compensación conocida (RT2): la barra se lee completa mientras OD es utilizable; La ganancia de OD puede pausarse mientras la carga se encuentra en la banda utilizable (vuelva a visitarla si RT2 muestra una pérdida de ganancia; coloque el pin en menú-solo). PolyHook compilación PASS (10/10), aplicar-modo implementación (SHA B092B4C6). RT2 Necesita pruebas (vaya a IZQUIERDO + usar Técnica robada con carga parcial). Documento: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §10

v2.123.4.0

v2.123.5.0BETAPATCHLulu

Enseñanza de cuadrícula de Nul Ward: rango command.bin PROBADO (sin exe parche) + codificación LearnedMove CORREGIR en el editor + verificador fuera de línea

• (corrige un error de comportamiento del editor SphereGridExplorer + nueva prueba/verificador sin conexión + RE). DLL intacto (el carril Ronso Mente doble lo está usando): C#/editor/IDA únicamente. RT2 riesgo #1 ELIMINADO fuera de línea: RE probado FFX_Kernel_LoadFileToTable@0x781E00 (caso 0 "command") carga command.bin textalmente en un puntero GLOBAL (g_CommandKernelTable@0x112A92C, archivo completo memcpy) — sin síntesis de rango. FFX_Table_GetEntryByIdRange@0x7AB890 lee el encabezado del rango directamente desde los bytes del archivo, asignando exactamente a EntryListFile: numRanges=int16@0(=Firma=1), lo=PreviousFileCount@8(=0), hi=(EntryCount-1)@10, stride=EntrySize@12(0x60), base=EntryTableFileOffset@16(0x14); record = file + 0x14 + id*0x60. Dado que el command.bin adulto escribe EntryCount-1=321, los identificadores 320/321 ∈ [0,321] → se resuelven exactamente las filas Radiant/Umbral agregadas. No exe/DLL parche. El nuevo CommandKernelLookupVerifier (FfxLib/Ability) reproduce las matemáticas exactas del motor contra los bytes crecidos y está conectado a la puerta --nul-ward-static (comprobación engine_lookup_resolves: prueba fuera de línea de que GetCommandEntryById(320/321) NO alcanza el respaldo cmd0). Revisión del editor (SphereGridExplorer): el menú desplegable LearnedMove almacenó el id sin formato (0x0140), pero en el disco está el id codificado (0x3000|id), probado empíricamente por SphereGridRt2Lab (Rompecoraza en panel.bin = 0x3012) y requerido por la puerta (cmd & 0xFFFFF000)==0x3000 de la subvención. El menú desplegable ahora emite 0x3000|id (Radiant→0x3140, Umbral→0x3141) y resuelve nombres que enmascaran & 0xFFF, por lo que el usuario puede colocar las barreras en la cuadrícula de esferas y realmente enseñan (antes almacenaba 0x0140 y la concesión lo rechazaba). .i64 cambia el nombre: 0x781E00→FFX_Kernel_LoadFileToTable, g_CommandKernelTable/g_KernelFileSizes/g_AAbilityKernelTable/g_ItemKernelTable + comentarios probados sobre 0x781E00/0x7AB890/0x790AE0 (guardados a través de idalib_save). C# compila PASS (0 errores). Documento: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §F/§G

v2.123.4.1

v2.123.5.1BETAREVISIONYuna

Balística de finalización de Aurora: inicio de la fase 0 (conciliación de documentos + corrección de comentarios heredados + insignia variante NO VERIFICADA)

• (docs + RE/anotación de honestidad; sin características nuevas; sin cambios de comportamiento). El plan persistió en .cursor/plans/aurora_balistica.plan.md (10 fases, alcance A+B confirmado por Halyson: 5 RT2s activos + pico IDA W2S + pico IDA del selector de variantes). Este REVISIÓN se envía únicamente en la fase 0 (conciliación de documentos antes de la instrumentación de la sonda). Cuatro ediciones: (1) PORT_STATUS.md fila "Aurora Cámara" - Honestidade texto corregido: era transform battle->world is DESIGN/UNCALIBRATED (...) flip-Z is a hypothesis, ahora refleja la prueba IDA 2026-06-05 (X/Z = identity, Y residual RT2 pending, referencias 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 arriba: nuevo bloque Atualizacao 2026-06-16 (Aurora finalizacao balistica) que reanudar el estado REAL de Aurora conciliado con A15 + pedido RT2 confirmado (azit03_00 -> klyt00_00 -> drag -> grow -> camera -> photo, luego pico IDA). (3) RuntimeTools/FFXMapViewerWeb/aurora-overlay.js: encabezado JSDoc (líneas 9-10) corregido: era RAW battle-local - design-only/UNCALIBRATED, ahora 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 (que se muestra en SceneDetail cuando _resolver.ResolveScenes(MapKey) devuelve más de 1 variante) ahora agrega runtime selector UNVERIFIED junto a la lista _a/_b/_c, para que los usuarios sepan que la Cámara muestra cualquier variante que elija el catálogo, mientras que el selector REAL (historia-flag -> variante) no ha sido Probado por RE: consulte A04 FFX_AURORA_ARENA_VARIANT_SELECTION_RE_2026-06-15.md. No toca: sonda, escritores, puertas fuera de línea, FfxHooksDll. Siguiente (Fase 1): implemente aurora-calib-v2 en RuntimeTools/FfxDinput8Probe/ctl/Program.cs con salida CSV/JSON (residual identity_dx/dy/dz/rms, flipz_*, yaw180_*, winner enum, height_0x534, ruta + batalla id) — especificación en docs/reverse/FFX_AURORA_CALIBRATION_PROBE_SPEC_2026-06-15.md. Fase 0 RT2: N/A (solo documentos + cadena UI)

v2.123.5.0