JARVIS-ARENA

Actualización 2.130

16/6/2026

v2.130.0.0MINORJarvis-ARENA

Informe de bloqueo de nivel de Arena+ Multi Dark Aeon en CLI (`--print-tier-lock`) + esquema de sidecar v1

(nueva capacidad: primer informe sin conexión que combina el catálogo v2 y el progreso del sidecar; nuevo esquema canónico de la instantánea LOCKED/READY/CLEARED). Nuevo RuntimeTools/ArenaMultiBossLab/TierLockReport.cs + 4 banderas en Program.cs: --print-tier-lock, --progress <path>, --out <json>, --json. El modo predeterminado imprime un informe de personal agrupado por nivel con motivo de control de acceso (← needs: arena.dark.valefor, ... en filas LOCKED) y fallback rt2:<status> risk:<...> token:<mode> en filas no-prueba d. Modo --out ou --json emite JSON estrito que casa com o novo schema mods/Spira Reforge/arena/spira-arena-tier-lock-state.schema.json v1 (formato, format_version, generated_utc, resumen{total,liquidado,listo,bloqueado}, rows[] com estado enum BLOQUEADO|LISTO|COMPROBADO + requisitos_de_desbloqueo/requisitos_faltantes). 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 de mods/Spira Reforge/arena/ reescrito com tabela completa dos 5 sidecars + comandos --print-tier-lock e --validar exemplificados. Lints clean. Build PASS. [anterior: v2.129.0.0]

v2.130.1.0PATCHJarvis-MAGIC

Ronso Mana (7.ª pasada): he leído el `DIAG`/`BLOB-PATCH` del RT2 `hudSafe=24` que me había SALTADO → el parche del blob indicaba «NODO NO VÁLIDO» (`subIdx=0x00`); reescrito para seleccionar un nodo VÁLIDO + `ODBLOB` deep dump

(corrige la heurística defectuosa del PatchCase2BlobForKimahri + nueva instrumentación de solo lectura en un hook ya implementado/RT2; código listo, compilación/implementación en la próxima versión de la DLL — otro departamento lo está utilizando). El hallazgo (líneas DIAG/BLOB-PATCH del %TEMP%\ffx-hooks.log que nunca había leído —solo echaba un vistazo rápido— 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 — es decir, el PatchCase2BlobForKimahri ya existía y ya funcionaba (setou blob[45] de 0xFF→0x00) pero el Resolve(2,1,43) continuó −1. ⇒ el antiguo plan de contingencia (maxUsed→casi siempre 0x00) indicaba que el treeId 43 apuntaba a un nodo estructuralmente inválido: pasa la puerta principal del WalkMenuBlobIndex (idx!=0xFF, 43<count) pero el selector secundario ringKind estalla (v4>=node.entryCount o entry[v4]==0xFFFF) → *a3=−1. Pruebas adicionales del mismo registro: count=138 (43 está dentro del rango → NO se trata de un caso de «recuento pequeño»/43>=count); slots 41/42 = 0xFF (no hay ningún OD de grupo registrado en este blob a2=1 → no hay donante hermano); DIAG G0-finalize slot=2 od=3065 3064 3066 311A (la capa de búfer circular-A TEM 311A=cmd282 Ronso Rage** — confirma que la puerta es, sin lugar a dudas, la solución de la capa B del árbol de menús, no el contenido). La corrección (código, hudSafe=25): (1) PatchCas e2BlobForKimahri reescrito — agora decodifica o nó no formato EXATO do WalkMenuBlobIndex (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 escolhe blob[2+43] por prioridade: (a) nó que contém 0x311A (assinatura exata do OD) e suporta ringKind=1; (b) sibling party-OD 41..47 já registrado com nó selector-capaz; (c) nó mais rico que suporta ringKind=1 (de preferência também 12). Se NADA qualifica, deixa 0xFF (a2=1 não tem nó OD usável → é fix-C/redirect pro a2=0) e loga Nodo NO viable, em vez de escrever lixo 0x00 como antes. (2) novo DumpOdBlobStructureOnce (read-only, dispara 1× mesmo em log-only) — dumpa os índices party-OD 41..47 do a2=1, o entryCount+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 o subIdx certo OU revela que é redirect pro a2=0. Helpers novos (todos estático, bounds-clamped, sem dep de PolyHook): OdBlobNode/OdBlobEntry/OdNodeSupportsSelector/OdNodeContainsEncodedOd/ReadMainRingBlobPtr (a2=0 = _BASE 0xD2A994). Banner hudSafe=24→25 (confirma DLL nova no log). NÃO buildei/deployei (DLL em uso por outra sala — respeitado); ReadLints clean; código pronto pro build_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: CAUSA PRINCIPAL de que «no apareciera nada en el menú de White Magic» DETECTADA + CORREGIDA — el banco para todo el grupo se RECARGA desde el `party_data` En CADA inicio de batalla, se elimina el «grant» antes de que aparezca el menú de montura

(corrige el error de comportamiento que impedía que apareciera el Nul Ward — misma feature/lab que el v2.123.4.0/v2.124.0.2; RE decisiva demostrada en la .i64 real + nuevo desvío de re-assert en el NulWardTeachHook; DLL publicada por Halyson, con recompilación e implementación realizadas). El problema: incluso después de la corrección multisitio del error «menu-bound» (v2.124.0.2) + asignación al cargarse (registro NulWardTeach grant ch=0..6 radiant=1 umbral=1), los wards no aparecían en la magia blanca durante la batalla. La RE que se cerró (idalib MCP, verificada por byte a través de disasm): sub_7817D0 ("* BTL INIT") llama FFX_Btl_PrepareSaveCommandState@0x786BC0 ("-- SAVE RAM CLEAR -- Preparing save game data") en cada inicio de batalla; en 0x786CA3 ella hace mov ecx,21h; mov edi,offset dst__0; rep movsd — copia 0x84(132) bytes del núcleo party_data (tabla n.º 4) para dst__0=0x11307D8, pista [0x11307D8,0x113085C) que cubre íntegramente el g_PartyWideCommandBank@0x11307FC (desplazamiento +0x24 dentro de la copia; banco = 16 palabras, ID 96..351). ⇒ Todo el banco de todo el grupo se sobrescribe desde el party_data cada batalla, y party_data no tiene el bit de ward → word14=0 → IsCommandAvailable(320/321)=0 → El bucle de colocación se salta las torretas → «No ha aparecido nada». Sospechosos descartados: FFX_Btl_InitPartyWi deCommandBank@0x784960 só dá O em 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: PrepareSaveCommandState não é só "persistência" — é o reload ATIVO por-batalha do banco a partir do party_data; qualquer grant de id≥96 ausente do party_data (sphere-grid teach incluído) reseta toda batalha. Categorização corrigida (empírica): dump do command.bin deployado mostra os doadores Nul (NulShock id48, NulTide id49) e as wards (320/321) todos com SubMenuCategorization (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 (lab teach_grant, deployado): NulWardTeachHook agora instala um PLH::x86Detour no FFX_Btl_PrepareSaveCommandState; o shim chama o original (deixa recarregar o banco do party_data) e re-afirma g_PartyWideCommandBank[word14] |= 0x3 (Radiant bit0 + Umbral bit1) no retorno — ou seja, logo após o wipe e antes do FFX_Btl_BuildActorCommandMenu semear 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 reafirma #n post-PrepareSaveCmdState: banco palabra 14 0xPRE->0xPOST. Grant one-shot mantido pros menus de field/pré-batalha. Consequência de design (produção): como party_data é a fonte por-batalha pra ids≥96, o caminho limpo pra uma ward sempre-disponível é adicionar o bit no próprio kernel party_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 do party_data ou (b) re-assert em runtime como esse detour de lab. Build/deploy: build_hooks.ps1 -WithPolyHook -Release PASS (12/12 cpp), deploy install_to_modules.ps1 -EnableApply -EnableTeach (backup ffx-hooks.dll.backup-nul-ward-20260616-081633, novo SHA-prefix 0DE302BDF13D5B14). Gate --nul-ward-static VERDICT: PASS (sem regressão; command.bin/exe/flags intactos). .i64 real: comentario varios en 0x786BC0 + 0x786CA3 (REGLA DE ORO). 2 nuevos RVA en shared/ffx_addresses.h (RVA_FFX_BTL_PREPARE_SAVE_COMMAND_STATE, RVA_FFX_PARTY_WIDE_COMMAND_BANK). RT2 en el juego: iniciar la batalla y confirmar la Radiant/Umbral Ward en la magia blanca + revisar el registro reassert ... word14 0x0000->0x0003. Abertura: anchura de la ply_save pro bit 224/225 (§H) — lab se vuelve a aplicar en cada carga. Archivos: RuntimeTools/FfxHooksDll/hooks/NulWardTeachHook.cpp, shared/ffx_addresses.h. Doc: docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md §I. [anterior: v2.130.1.0]

v2.130.2.1REVISIONJarvis-MAGIC

Spira Reforge: Magia negra ampliada — diseño bloqueado (familia de habilidades múltiples > nivel -ja; `-ja` se convierte en backlog de nicho; Lulu Fury «include-all»)

(documento de diseño + integración en VISION; ningún escritor/comportamiento/RT2 en esta ronda). Halyson ha abierto una lluvia de ideas sobre la creación de nuevas Black Magic. He comparado dos vías: (a) -ja nivel (Firaja/Blizzaja/Thundaja/Waterja = clon -ga con +Potencia, excluye Furia) frente a (b) Multihabilidad (versiones de área de efecto de hechizos de un solo objetivo de la versión básica que no tienen equivalente de área de efecto). Decisión (Halyson): Multi-Skill se impone como vía principal; -ja aparcado como backlog de nicho (1 por elemento, MP brutal ~80–120, posterior a Celestial, la guinda del pastel — no compite con el buff de -ga en VISION §10.5); Lulu Fury lo incluye TODO («Fury Drainga 16× es un caos precioso, una fantasía a tope»). Por qué gana Multi-Skill: (1) TargetFlags.Multi ya es nativo del motor (FfxLib/Ability/Ability_Command.cs:125) — de un solo objetivo a múltiple = 1 bit en la fila de comandos; (2) los hechizos cubren el vacío real de la versión básica (sin veneno de área de efecto, drenaje de área de efecto ni ósmosis de área de efecto) y aportan identidad; (3) -ja es redundante con «plano» VISION §10.5 que ya va a dar un buff -ga con Ignore MD EF / Escalado de potencia («Firaga reforjada», no «Firaja»); (4) VISION §10.11 Ya ha descartado a Holyra/Holyga/Wildra como «graciosas, quizá nunca» por el mismo motivo (inflan el pool sin identidad); (5) Drainga/Osmose-ga alimentan otros frentes (Capture Cascade T7 en combates largos, modo SIN con maldiciones, OD de mobs con multicast). Hechizos de la primera tanda (v0.5+) validados técnicamente: Biora (veneno de área de efecto + daño, clon de Bio + Multi), Drainga (drenaje de HP de área de efecto con un límite de 9999 por lanzamiento), Osmose-ga (drenaje de MP de área de efecto con un límite de 99 por lanzamiento), Demita (50 % de HP de área de efecto con un límite de 9999 por objetivo), Familia Multi-Firaga (3× Firaga de área de efecto secuencial con triple MP —idea directa de Halyson: «Multi-Firaga, por ejemplo>>>>>>»— subfamilia escalable a Multi-Blizzaga/Thundaga/Waterga/Ultima). Segunda tanda (v0.6+): Slowga, Reflectga, Demi-fall («Dimensional Crush», 75 % de HP, objetivo único, MP caro), Quartera (25 % de HP, AoE, MP barato). Bloqueos confirmados y documentados: (a) ranura de ID de hechizo 0..95 — auditoría cruzada con FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md para identificar a los donantes; (b) Lulu Fury rema #12408–#12422 descarga pendiente; (c) Drenaje del límite de maná dependiente de RT2 (sin límite = OP de sanador mediante ataque, límite ajustado = hechizo inútil); (d) Multi-Firaga hit_count Reparto de jugadores: RE spike pendiente; (e) Efectos visuales idénticos a los del sencillo (vale para la v0.5; cambio de color en la v0.6+ mediante el motor Flan Flood, ya probado) v2.114.0.0); (f) Decisión independiente sobre Sphere Grid Wire. Plan técnico incremental (apartado 6.2 del documento): Fase A: auditoría de identificadores de donantes (sin código, este documento), Fase B: creación de contenido sin conexión (clonar filas + invertir Multi + ajustar Power/MP + entradas de texto), Fase C: LAB de escritura, Fase D: RT2 en el juego, Fase E: integración de Fury, Fase F -ja backlog niche (v0.7+). Integración con el mod: complementa §10.5 Magia negra, potenciadora, alimenta §10.6 Lulu Fury, conserva §10.11 Rompecabezas elemental, responde §10.13 mob OD multicast con Drainga/Osmose-ga, compatible con §11 Captura las batallas de Cascade T7. VISION_AND_ROADMAP.md actualizado: nueva sección 12 «Magia negra ampliada — Familia de habilidades múltiples» (decisión de diseño + hechizos de la primera y segunda tanda + vinculación con la hoja de ruta + documento completo); referencias renumeradas en la sección 13. Preguntas abiertas para la lluvia de ideas continua: mecánica Multi-Firaga A/B/C (lanzamiento doble fijo frente a distribución aleatoria frente a híbrido el ement — recomendación A), Draining de maná por objetivo frente a por lanzamiento, conexión de la Sphere Grid, coexistencia de Demita frente a Demi vanilla, AoE de magia blanca (¿Esuna-ga?), nivel de los donantes. No se toca: ningún «writer», ningún «hook», ningún «probe», ninguna DLL, ninguna «gate» offline/RT2. Solo documentación + integración de la hoja de ruta. Nuevo documento: docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (10 secciones, unas 300 líneas). Archivos reproducidos: FFXProjectEditor/FFXProjectEditor.csproj (cuarteto «bump»), mods/Spira Reforge/VISION_AND_ROADMAP.md (nuevo apartado 12 + renumeración de las referencias del apartado 13), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.2.0]

v2.130.3.0PATCHJarvis-MAGIC

Ronso Mana CRASH HOTFIX (`hudSafe=26`): la escritura del blob ya no da error (antes era `via=rich>=1 subIdx=0x01` → fallo); ahora la escritura es OPT-IN + solo nodo seguro + lecturas protegidas por SEH

(corrige el fallo de comportamiento introducido por el hudSafe=25 de la v2.130.1.0 cuando la DLL se volvió a compilar o se implementó en la v2.130.2.0 de la pista «Nul Ward»). Causa principal (log RT2 %TEMP%\ffx-hooks.log): RonsoMana BLOB-PATCH2 #1 treeId=43 set subIdx=0x01 via=rich>=1 nodeOff=0x1B4 ec=24 (was 0xFF) — el plan alternativo (3) «nodo más rico» de mi hudSafe=25 ha escrito un índice de nodo CHUTADO (0x01, ec=24) en blob[2+43]. Eso hizo que Resolve(2,1,43) «tener éxito» en un nodo que no es el anillo de OD → finishMenuTree cargó/mostró contenido falso → el juego se colgó. (El 0x00 antiguo del hudSafe<=24 simplemente devolvía −1 y, por eso, NO se bloqueaba: nunca llamaba finishMenuTree.) Mi intento «provocó que un estado «fallido pero seguro» acabara en un fallo». La corrección (hudSafe=26): (1) la escritura en el blob ahora es OPT-IN — solo se graba blob[2+treeId] cuando el env FFXHOOKS_RONSO_OD_BLOBWRITE=1 está activado; por defecto = NO escribe nada (compilación a prueba de fallos, puramente diagnóstica a través de ODBLOB); (2) incluso con la opción «opt-in», solo se registra el nodo PRINCIPIADO — (a) nodo cuyas entradas contienen el comando OD codificado 0x311A, o (b) una partida hermana (OD 41..47) que la partida ya haya registrado; nunca se guarda automáticamente el c hute «nodo más rico» (esto solo aparece en el registro, para una posible configuración fija tras leer el volcado); (3) todas las lecturas del nodo (OdBlobNode/OdBlobEntry) y el bloque a2=0 del DumpOdBlobStructureOnce ahora están blindados con SEH (__try/__except) — cualquier violación de acceso por un desplazamiento fuera de rango (OOB) se convierte en un «nodo no válido» que se elimina, en lugar de provocar un fallo del sistema; (4) mainPtr «a2=0» pasa la comprobación de validez (> 0x10000). El registro ahora muestra BLOB-PATCH2 #n ... write=0|1 safe=0xXX(how) risky=0xXX(how,ec=..) (muestra lo que haría sin escribir) y, cuando haya opt-in + nodo seguro, BLOB-PATCH2 WROTE .... Banner hudSafe=25→26. Reversibilidad: sin el env, comportamiento = vanilla seguro (OD oculto, sin fallos). NO lo he compilado ni implementado (DLL compartida con otras líneas de Jarvis-MAGIC) — la próxima recompilación de ffx-hooks.dll (en cualquier carril) ya tiene la corrección; ReadLints clean. Archivo: RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. Doc: docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md §14. [anterior: v2.130.2.1]

v2.130.3.1REVISIONJarvis-MAGIC

Spira Reforge: Magia Negra Ampliada — 4 decisiones clave de Halyson (opción B de Multi-Firaga, límite máximo de Drainga por objetivo, Demita coexiste con Demi, Fury «incluye todo» con matices)

en cascada posterior av2.130.3.0 (Parche menor de Ronso Mana de otra Jarvis-MAGIC paralela). Continuación inmediata del documento de diseño de v2.130.2.1: lluvia de ideas con H Halyson ha zanjado las últimas cuatro decisiones pendientes. (1) Mecánica «Multi-Firaga» — opción B (distribución aleatoria) + 3-5 veces los PM base: Halyson: «Opción B, pero el “Multi-Firaga”, el “Multi-Fodase”, costará entre 3 y 5 veces el MP inicial de la habilidad base para compensar, una auténtica paliza». Mecánica = 1 lanzamiento → N impactos (5-7), cada impacto afecta a un enemigo aleatorio (motor nativo mediante la fórmula Holy/Comet/Doublecast). Los enemigos pueden recibir 1, 2, 3 o más impactos del mismo «Multi-Firaga» según el RNG. Coste de MP = 4× el valor base predeterminado (Multi-Firaga = 64 MP), Multi-Ultima = 200 MP. Sugerencia de Jarvis: empieza con 4× MP + 6 impactos, ajusta RT2. Familia escalable (lanzamiento incremental): v0.5 Multi-Firaga + Multi-Blizzaga, v0.6 + Multi-Thundaga + Multi-Waterga, v0.7 + Multi-Ultima (post-Darkness §10.11), v0.8+ backlog Multi-Flare/Multi-Holy. (2) Límite de Drainga — por objetivo 9999/objetivo (límite múltiple): Halyson lo implementó consciente del impacto. 4 enemigos vivos = hasta 39 996 HP curados en un lanzamiento = sanador-ofensivo supremo. ⚠ Puede romper una arena larga — es intencionado, es un mod de Halyson, fantasía de endgame. Compensación: el coste de MP puede escalar hasta ~30 tras RT2 si lo rompe todo. (3) Demita vs Demi vanilla — coexisten: Mantén AMBAS. Demi individual (16 MP, asesino de jefes) + Demita múltiple (24 MP, limpieza de oleadas). El jugador elige la herramienta. Coste: 1 ranura de ID extra. (4) Furia de Lulu «todo incluido» con matices (decisiones del §4 actualizadas): Biora 16× = vale (ola de veneno); Drainga 16× = límite de Furia de 9999 por selección (no por objetivo en Furia, ya que de lo contrario se curarían hasta 639 936 HP — «deja de tener sentido»); Osmose-ga 16× = vale (límite de MP 9999 = barrera infranqueable); Demita 16× = vale (Demi deja de acertar a un objetivo muerto); Multi-Firaga 16× = 96 golpes potenciales ⇒ Multi- de Furia usa hit_count=1 (vuelve a ser de lanzamiento único en Furia)* O bien excluye Multi-* del pool de Furia (única excepción a «include all»). La decisión final ajusta RT2. Cuestiones pendientes actualizadas en el §8 del documento: §8.1 resueltas (4 confirmadas); §8.2 aún pendientes (cable de Sphere Grid, alcance del AoE de magia blanca, confusión por absorción de elementos, nivel de los donantes 0..95 bloquea la fase A**, distribución aleatoria Multi-* command.bin campo vía spike). Documento actualizado: docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md §2.2 Drainga (límite por objetivo fijo), §2.4 Despedir (c (no existe «cravado»), §2.5 Multi-Firaga (opción B + MP 3-5× fijado + tabla elemental completa), §4 Furia (matices por hechizo), §8 cuestiones pendientes (4 marcadas resueltas, 5 aún pendientes), §9 Versión de entrega actualizada. Próximo paso seguro: Fase A: auditoría cruzada de donantes de ID de hechizos con FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md — Halyson decide si se incorpora ahora o si espera hasta que la versión 0.5 esté a punto. No afecta a: writer/hook/probe/DLL/gate. Archivos: FFXProjectEditor/FFXProjectEditor.csproj (cascada 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 actualizados), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.3.0]

v2.130.3.2REVISIONJarvis-MAGIC

Spira Reforge: CAMBIO ARQUITECTÓNICO — La sección «Magia negra ampliada» pasa a llamarse «Comandos por personaje ampliados» (RE D01, prueba + distribución ampliada a 7 personajes)

(continuación inmediata v2.130.3.1; sin writer/comportamiento). Halyson propuso: «¿Y si en lugar de esas ski «Si «todo el mundo» puede adquirirlas, ¿por qué no las dejamos como «solo para el personaje X»?» — Lo comparé con el RE existente y DESCUBRÍ que el motor vanilla YA ADMITE DE FORMA NATIVA la propiedad por personaje para los ID 0..95. El hallazgo crítico (RE D01 — FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md): FFX_GrantCommandToCharacter @ 0x785D10 tiene SPLIT AT INDEX 96: ids < 96 ¿Vais al banco, por casualidad? word_11307FC[74*char+3151+(id&0xFFF)/16] (stride 74 palabras = ply_save por personaje); ids >= 96 van al banco común de toda la fiesta FLAT (sin stride). ⇒ El espacio aprendible por personaje es EXACTAMENTE de 96 bits, con ID del 0 al 95. Los ID ≥ 96 no se pueden aprender por personaje. Implicación: reutilización de los ID 0..95 = El motor «vanilla» filtra QUIÉN ve cada hechizo sin ningún tipo de hook. Se descarta el método antiguo (ids ≥96 + desvío al estilo Nul Ward para restringir). Distribución ampliada (decisión de Halyson del 16/06/2026, citas conservadas): Lulu (6 hechizos, lanzadora de ráfagas + drenaje de PV) — Familia Multi-Firaga × 4 + Drainga + Osmose-ga (trasladada de Yuna a Lulu), posiblemente Demita; Yuna (5 hechizos, área de efecto blanca/potenciadora) — Reflectga + Protectga + Shellga + Esuna-ga + Dispelga («Reflectga, Protectga, Shellga, Esuna-ga, Dispelga para Yuna»); Rikku (3 hechizos, maestra en robar) — Copycat pasa a ser exclusivo suyo + Mugra (ataque de 2 golpes, 2× robo) + Mugga (Área de efecto de 2 golpes, bajo daño, «¡¡¡puede robar hasta 6 veces!!!!»); Wakka (por determinar, «más habilidades de estado y cosas aún más locas»); Kimahri (por determinar, «Mago Azul. Se podrán aprender habilidades de monstruos e incluso sus propios overdrivers para usarlos con maná» — coordinación de la línea de maná de Ronso); Tidus (por determinar, «0 ideas, pero quizá habilidades multigolpe»); Auron («EL PUTO TANK DEL JUEGO. Evolución del Centinela, quizá «Breaks» de área con más potencia»). Total estimado: 28-31 hechizos de 96 ranuras = ~30 % del presupuesto, quedan más de 65 ranuras para -ja Backlog v0.7+ + futuro. 9 decisiones confirmadas en el documento, apartado §9.1; 10 aún pendientes en el §9.2 (Despedir al responsable, grupos de Wakka/Tidus/Auron, sustituto de Rikku Copycat, cable de la Sphere Grid, auditoría del donante 0..95, campo de impacto aleatorio de Multi-Firaga, «steal-per-hit» de Mugra/Mugga, coordinación de Kimahri Blue Mage en la ruta de Ronso). Ventajas del modelo: (a) zero hook custom — motor nativo «vanilla»; (b) Los árboles de la Sphere Grid adquieren un significado real (pasar a otro árbol = compensación real); (c) Lulu Fury se simplifica drásticamente — la reserva de Fury es por personaje «vanilla», «excluir Multi-* de la Fury» deja de ser un problema; (d) La «Capture Cascade» §11 y el «Modo SIN» §10.13 obtienen respuestas tácticas distintas para cada personaje. Plan técnico (§7.2): Fase 0: fijar reservas (por determinar) → Fase A: auditoría de donantes (bloquea el inicio) → Fase B: creación por personaje (B: Lulu piloto, B.1: Yuna White AoE, B.2: familia Mug de Rikku con robo por golpe, B.3: reservas por determinar) → Fase C/D: RT0/RT1/RT2 → Fase E: Sphere Grid wire (ampliación del editor de Spira Grid) → Fase F: filas de Lulu Fury → Fase G: Kimahri Blue Mage (depende de la ruta de Ronso) → Fase H: backlog de -ja v0.7+. VISION_AND_ROADMAP.md §12 reescrito: «Magia negra ampliada» → «Comandos por personaje ampliados» + tabla de distribución por personaje + bloqueos + hoja de ruta actualizada. Documento renombrado conceptualmente (se mantiene la ruta del archivo por motivos históricos): docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md — 11 secciones, §1 Modelo de propiedad por personaje con descompilador RE D01 verificado por bytes integrado, §3 distribución por personaje (3.1 Lulu, 3.2 Yuna, 3.3 Wakka por determinar, 3.4 Rikku, 3.5 Kimahri coord, 3.6 Tidus (por determinar), 3.7 Auron (por determinar), 3.8 resumen). No se toca: writer/hook/probe/DLL/gate. Solo diseño + integración de la hoja de ruta. Archivos: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.1 → v2.130.3.2), docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md (revisión importante: nuevo apartado 1 de RE D01, apartado 3 ampliado en 7 caracteres, apartados 5, 7, 8, 9, 10 y 11 renumerados y actualizados), mods/Spira Reforge/VISION_AND_ROADMAP.md (§12 reformulado), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.3.1]

v2.130.3.3REVISIONJarvis-MAGIC

Spira Reforge: FASE 0 COMPLETA A — Halyson completó TODOS los grupos TBD por personaje de una sola vez (Demita→Kimahri, Wakka 5 hechizos, Auron paquete MÁXIMO de 6 hechizos, Tidus con múltiples golpes + auto-potenciación, Rikku +1 nueva habilidad de Ladrón)

(tercera pasada del día 16/06/2026, continuación inmediata v2.130.3.2; sin escritor ni comportamiento). 4 decisiones más fijas (de 9 a 13): (1) Despedir al propietario = Kimahri (gimmick «monstruos extraños» + tema de Mago Azul; libera a Lulu para que se centre en el estallido elemental); (2) Pool de Wakka = A+B combinados, 5 hechizos — Biora (veneno de área + daño) + Sleepra (sueño de área de efecto) + Quad Foul (Triple Foul de área de efecto + veneno = 4 efectos de estado) + Double Buster (ataque de 2 golpes, combo de 2 efectos de estado aleatorios) + Tide Slash (ataque físico de 2 golpes) — «maestro de los efectos de estado + doble golpe + locuras»; (3) Combinación de Auron = paquete MAX, 6 hechizos — Mass Power Break + Mass Armor Break + Mass Magic Break + Mass Mental Break + Sentinel++ (Sentinel + bloqueo físico y mágico + para todo el grupo durante 1 turno) + Provokeja (Provoke + auto-Sentinel + provocar a todos los enemigos) — «Auron es el puto TANK del juego»; (4) Estrategia de Tidus = golpes múltiples + auto-buff, 4-5 hechizos — Spiral Slash (3 golpes individuales, +5 STR/límite de lanzamiento 25) + Tidal Combo (4 golpes de área de efecto, +5 AGI por lanzamiento, límite 20) + Bladestorm (5 golpes aleatorios, +Aceleración propia 1 turno) + Aurochs Rush (habilidad característica, +AGI fijo + Aceleración 3 turnos) + opcional Cheer-strike (2 golpes + Ánimo propio). «Tidus siempre ha sido el más rápido. Quick Hit VA A SUFRIR UN NERF, así que las habilidades de múltiples golpes que otorgan mejoras que aumentan la propia velocidad» — compensación directa por el nerf a QH §10.6; (5) Rikku +1 nueva habilidad de Ladrón — Halyson pidió una «habilidad de Ladrón inventada» para completar el conjunto; sugerencias de Jarvis: Sleight of Hand (Mug refinado), Pickpocket (robar sin coste de turno; por defecto Jarvis), Sticky Fingers (acumulación de +25 % por lanzamiento), Backstab (ignora PDEF), Cache (robar directamente del conjunto de habilidades), Smoke Bomb (el grupo se salta el CTB). Distribución final completa (Fase 0): Lulu 6 + Yuna 5 + Wakka 5 + Rikku 4 + Kimahri 3 + Tidus 4-5 + Auron 6 = 33-34 hechizos de 96 ranuras = ~35 % del presupuesto (quedan 62+ para -ja backlog v0.7+ + extras de magia blanca). Combinaciones emergentes entre personajes: Auron - Mass Mental Break + Lulu - Multi-Firaga (ataque en oleada sin MDEF); Auron - Sentinel++ + Yuna - P rotectga/Shellga (2 turnos de invulnerabilidad casi total); Auron Provokeja + Wakka Quad Foul (tanque + estado masivo); Tidus Bladestorm + Auron Mass Armor Break (ráfaga de Tidus + objetivos sin DEF). Riesgo añadido por el auto-buff de Tidus: acumulación infinita de STR/AGI = degeneración similar a la de QH; limitación de la acumulación (5 STR / 4 AGI) + decaimiento al final de la batalla (no persiste entre combates). 11 cuestiones pendientes en el apartado 9.2 — todas son decisiones secundarias precisas (nombre definitivo de la habilidad de Ladrón de Rikku, 4 frente a 5 hechizos de Tidus) o picos técnicos (Multi-Firaga de impacto aleatorio command.bin campo, robo por golpe de Mugra/Mugga, estado de Wakka por golpe, acumulación de auto-mejoras de Tidus, mejora para todo el grupo de Auron (Sentinel++), persistencia de Lancet+ de Kimahri) — NO bloquean el diseño general, sino que bloquean fases específicas de la creación. Auditoría de donantes 0..95 (§9.2 q18) ahora tiene un alcance concreto: se necesitan ~33-34 ranuras. Documento actualizado: §3.1.4 «Demita» se traslada a §3.5.1 Kimahri; §3.3 Wakka: 5 hechizos fijos; §3.4 Rikku: +1 habilidad de Ladrón con 6 sugerencias; §3.5 Kimahri: conjunto completo (Demita + extensión de Blue Mage 2-3); §3.6 Tidus: conjunto de 4-5 multihit + auto-buff con combos frente al nerf de QH; §3.7 Auron: paquete MÁXIMO de 6 hechizos con combos entre personajes + riesgo/mitigación; §3.8 resumen total: 33-34 hechizos = 35 % del presupuesto; §9.1 13 decisiones; §9.2 11 subdecisiones/picos; §10 entrada v2.130.3.3. VISION §12 actualizado: tabla de distribución final por personaje + combos emergentes. No afecta a: writer/hook/probe/DLL/gate. Archivos: 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 trasladado + §3.3/§3.4/§3.5/§3.6/§3.7/§3.8/§9/§10 actualizados), mods/Spira Reforge/VISION_AND_ROADMAP.md (§12 mesa de billar final + combos), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.3.2]

v2.130.3.6REVISIONJarvis-MAGIC

Spira Reforge: REALITY CHECK + 3 reversiones — Ruta 4 (`CharacterUser` (nativo) fijo + capacidad de aprendizaje a través de la Sphere Grid fija. Halyson vio lo que yo no vi

(el pasado jueves 16 de junio de 2026, continuación v2.130.3.3; sin writer ni comportamiento). Secuencia de iteraciones arquitectónicas en esta sesión: (1) v2.130.3.2 pivot: he descubierto el RE D01 en el que los ids 0..95 Son, por lo que parece, nativos; los he marcado como «cero ganchos + 62 ranuras libres». (2) Halyson ha abierto FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md y preguntó «¿Qué quieres decir?»: la auditoría del 12 de junio de 2026 ya lo ha demostrado 0/96 slots libres: los 96 ID están ocupados con vanilla. Mi afirmación de que «quedaban 62» era falsa. (3) v2.130.3.4 Vía 3: propuse «append» ≥96 + Lista blanca por personaje (al estilo de Nul Ward generalizado), Halyson lo ha aprobado. (4) Halyson se dio cuenta de la opción 4: «¿En CommandBin no bastaría con que yo seleccionara allí: CHARACTER USE (por ejemplo, TIDUS) de una habilidad, y se acabaría el problema? No haría falta ningún hook». NO ME HABÍA FIJADO en el campo nativo [Data] public Character_Enum CharacterUser en Ability_Command.cs:29 — byte con signo no command.bin que restringe quién puede utilizar cada comando. Prueba con precisión de un byte: FFX_SPELL_FREE_ID_AUDIT_2026-06-12.md La línea 86 hace referencia a Yojimbo Dismiss (id 87) y tiene CharacterUser=0x0E (14=Yojimbo) — El motor «vanilla» filtra el menú automáticamente según este campo. Interfaz de usuario ya existente (KernelCommands_Control.axaml:434 ComboBox). La opción 4 sustituye a las opciones 1, 2 y 3 — añadir ≥96 con CharacterUser por carácter configurado directamente a través del editor de la interfaz de usuario. CERO hook para el filtro del menú. (5) Halyson ha confirmado: «Las habilidades se podrán aprender a través de la Sphere Grid» — esto reactiva la salvedad de Nul Ward §H para los ID ≥96 (la recarga global del banco al iniciar el juego sobrescribe la concesión de la red). Solución: 1 hook generalizado que amplíe NulWardTe achHook.cpp (já provado em v2.130.2.0) — (a) detour PrepareSaveCommandState re-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 extends spira-reforge-flags.schema.json do Capture Cascade. Plano técnico atualizado (15 bloqueios honestos catalogados): Fase 0 ✅ → Fase A append command.bin ≥96 com CharacterUser (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 -ya backlog v0.7+. Bloqueios pequenos pendentes (spikes): addr panel_teach runtime, sidecar JSON schema design, side-effects CharacterUser filter (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 entries v2.130.3.5 e v2.130.3.6. Não toca: writer/hook/probe/DLL. Arquivos: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.3 → v2.130.3.6, pulou .4/.5 por 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

Documento de referencia: catálogo consolidado de las 96 habilidades de los personajes (ID `0..95`) con `Power`/`MP`/`Formula`/`Acc`/`Hits`/elemento/efecto + arquitectura AbiMap × banco para todo el grupo

(documento de registro / catálogo de referencia; sin autor/comportamiento/RT2; solo consolida en un único documento el conocimiento que ya se encuentra disperso en 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 ha solicitado la tabla de las 96 habilidades en MD como referencia operativa para el mod. Nuevo documento docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md (8 secciones, ~250 líneas): §0 TL;DR: alcanzando el límite en 95 (AbiMap de 96 bits físicos) + pruebas RE cruzadas; §1 cómo decide el motor el menú (FFX_Btl_IsCommandAvailable @ 0x39BB70 por personaje frente a para todo el grupo con CharacterUser filtro); §2 codificación LearnedMove = 0x3000 | id del panel.bin (referencia SphereGridExplorer_DataModel.cs:30-31); §3 catálogo completo 0..95 dividido en 9 grupos (Core/Menú 0-5, Habilidades 6-21, Especiales 22-25, Ánimo 26-31, Kimahri/Defensa/Social 32-42, Wht Magic 43-64, Blk Magic 65-83, menú de Aeon 84-87, final de juego de Rikku 88-95) con valores canónicos de FFX HD Remaster (EE. UU./Japón) — MP/Potencia/Fórmula/Precisión/Golpes/elemento/efecto; §4 guion decisivo de «what the magic IS» mediante 3 indicadores (DamageFlags + DamageFormula_Enum + PreviewFlags) con la tabla Cura/Revive/Cleanse/Físico/Mágico/Estado/Buff/Gravedad/Drenaje; §5 los 11 ID que no se pueden enseñar a través de la cuadrícula (missing=[0,1,2,3,4,5,33,84,85,86,87] en las 10 regiones — system/Defend/Aeon/Yojimbo); §6 ID de 96 o más para todo el grupo (Overdrives, Aeons, Mortes, Mix, pseudo-IA) con tres razones de diseño para la separación; §7 consecuencias para Spira Reforge al conectarse con el Camino el punto 4 del v2.130.3.6; §8 referencias cruzadas. No afecta a: writer/hook/probe/DLL/gate. Archivos: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.6 → v2.130.3.7), docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md (nuevo), CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md. [anterior: v2.130.3.6]

v2.130.3.8REVISIONJarvis-MAGIC

Spira Reforge: Pass 1. Reequilibrio ofensivo «Vanilla» confirmado — 16 mejoras ofensivas de habilidades + limpieza de habilidades automáticas + aumento de la esfera de PM

(solo diseño / decisiones confirmadas por Halyson; sin guionistas ni comportamiento en esta ronda). Halyson abrió FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md y sentenció: «Los hechizos cumplen su función, incluso curan. ¿Pero el resto? PATÉTICO. ¿Full Break? Que me den por el culo, además de que casi nunca acierta, el daño es ridículo para 99 de PM». Diagnóstico sin rodeos: 20 habilidades ofensivas básicas con Pow er = 16 (= multiplier 1.0× = Attack base) ou Potencia < 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" (bits 0x0200 | 0x0400 OR em ability_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 via SphereGridNodeTypeEntry.IncreaseAmount (offset 0x14, ushort) em SphereGrid_File.cs:519. Secuencia de decisiones tomadas en esta sesión: (a) Halyson abrió el catálogo e identificó el problema; (b) propuse una tabla de potenciadores de 20 habilidades + 4 categorías de habilidades automáticas; (c) Halyson estableció «Extracts» fuera + «Full Break» 3 veces; (d) estableció «One MP» eliminado + «Mana Shield» no (crea un nuevo meta); (e) confirmé el §10.8 invirtiendo la ranura 23, que pasa a ser Br eak Limits y la ranura 24 pasan a ser «xereca»; (f) he configurado Devil's Bargain en la ranura 24 y he entendido la salvedad de los 2 pases; (g) he perfeccionado Mana Spring en la ranura 13 y el backlog de Spell Spring. Salvedades técnicas catalogadas: «Devil's Bargain» necesita un cálculo del daño de «hook» + dirección RE FFX_DamageCalc_* pendiente; Mana Spring necesita un «turn-tick hook» + identificar un bit libre en ability_flags_64; Precisión del golpe frente a precisión del estado: pico pendiente de RT2; Triple falta: precisión 100→90, pico pendiente (validar «garantía triple», no se rompe); Escalado de MP en «Full Break» en la fase final del juego, OK (75 sigue siendo muy caro con «Half MP»); la reasignación de bits de la habilidad automática en la ranura 24 necesita escanear indicadores libres en AutoAbilityHardcodedFlagCatalog.cs. Plan técnico de la Fase 1 (edición pura de bytes v2.131.x PARCHE): 1.1 command.bin 16: mejora de habilidades ofensivas; 1.2: ranura 23 «Break Limits»; 1.3: ranura 13, marcador de posición de «Mana Spring»; 1.4: ranura 24, marcador de posición de «Devil's Bargain»; 1.5 panel.bin Nodos MP, 1.6 conjunto de textos, 1.7 identidad de bytes de puerta RT0/RT1, 1.8 piloto RT2. Fase 2 (hooks LAB v2.133.x+): 2.1 Cálculo del daño de RE, 2.2 Hook del tick por turno de Mana Spring, 2.3 Hook del daño de Devil's Bargain, 2.4 Hooks de RT2. Sinergia con VISION: §10.4 Nerf a QH (complementario — mejora de habilidades + nerf a QH = ofensiva diversificada), §10.5 Magia (sin cambios, próxima actualización), §10.6 OD Lulu Fury (próxima actualización), §10.8 «Break» de HP+MP fusionados (FIJADO en esta fase 1.2), §10.9 habilidad secreta de Auron (REFORZADA — «Break Limits» + «Devil's Bargain» + mejora de «Breaks» = «Auron, el intrépido que no puede ser derrotado»), §10.10 velocidad de magia (pendiente de «Spell Spring»), §10.11/§10.13 (próxima ronda), Ruta 4 «Black Magic Extended» (indirecta — la línea base «vanilla» crea contexto para ≥96 hechizos). Pendientes por resolver: Spell Spring espera la próxima ranura libre (candidatos a ser sacrificados: Ranura 18 Double AP, 19 Triple AP, 21 Pickpocket, 22 Master Thief — «cheese» de progresión/botín); Estado/Break Sharpness para las próximas identidades por personaje §10.9. No tocar: writer/hook/probe/DLL/csproj del lado del escritor. Archivos: FFXProjectEditor/FFXProjectEditor.csproj (v2.130.3.7 → v2.130.3.8); docs/reverse/FFX_SPIRA_REFORGE_VANILLA_OFFENSIVE_REBALANCE_2026-06-16.md (nuevo, ~280 líneas, 7 secciones: §0 verdad breve, §1 diagnóstico «carnificina vanilla», §2 paquete consolidado c con la tabla 16 de habilidades + limpieza de auto-habilidades + Esfera de PM, §3: consideraciones técnicas (6 elementos), §4: plan de implementación (Fases 1 y 2), §5: cuestiones pendientes, §6: versión de entrega, §7: referencias cruzadas); CHANGELOG.md + changelogUS.md + docs/governance/VERSIONING.md + docs/ai/SESSION_HANDOFF.md + mods/Spira Reforge/VISION_AND_ROADMAP.md (siguiente paso). [anterior: v2.130.3.7 catálogo de referencia]

Volver a actualizaciones