JARVIS-ARENA
Mise à jour 2.130
16/06/2026
v2.130.0.0MINORJarvis-ARENA
Rapport CLI sur le verrouillage de niveau Multi Dark Aeon dans Arena+ (`--print-tier-lock`) + schéma sidecar v1
- (nouvelle fonctionnalité : premier rapport hors ligne croisant le catalogue v2 et le sidecar de progression ; nouveau schéma canonique de l'instantané LOCKED/READY/CLEARED). Nouveau
RuntimeTools/ArenaMultiBossLab/TierLockReport.cs+ 4 indicateurs dans leProgram.cs:--print-tier-lock,--progress <path>,--out <json>,--json. Le mode par défaut imprime un rapport lisible regroupé par niveau avec motif de gate (← needs: arena.dark.valefor, ...dans les lignes LOCKED) et le mode de secoursrt2:<status> risk:<...> token:<mode>dans les lignes non-prove d. Modo--outou--jsonemite JSON estrito que casa com o novo schemamods/Spira Reforge/arena/spira-arena-tier-lock-state.schema.jsonv1 (format,format_version,generated_utc,summary{total,cleared,ready,locked},lignes[]cométatenumVERROUILLÉ|PRÊT|EFFACÉ+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--validateexemplificados. Lints clean. Build PASS. [anterior:v2.129.0.0]
v2.130.1.0PATCHJarvis-MAGIC
Ronso Mana (7e passage) : j'ai lu le `DIAG`/`BLOB-PATCH` du RT2 `hudSafe=24` que j’avais SAUTÉ → le patch du blob indiquait NŒUD NON VALIDE (`subIdx=0x00`); réécrit pour choisir un nœud VALIDE + `ODBLOB` deep dump
- (corrige l'heuristique défectueuse de
PatchCase2BlobForKimahri+ nouvelle instrumentation en lecture seule dans un hook déjà intégré/RT2 ; code prêt, compilation/déploiement dans la prochaine version de la DLL — une autre équipe l’utilise). La découverte (lignesDIAG/BLOB-PATCHde%TEMP%\ffx-hooks.logque je n’avais jamais lues — je ne faisais que rechercherB0 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— c'est-à-dire lePatchCase2BlobForKimahriexistait déjà et fonctionnait déjà (il a été mis en placeblob[45]de0xFF→0x00) mais leResolve(2,1,43)est resté à −1. ⇒ l'ancienne solution de secours (maxUsed→presque toujours0x00) pointait l'identifiant d'arborescence 43 vers un nœud structurellement invalide : il passe la porte primaire deWalkMenuBlobIndex(idx!=0xFF,43<count) mais le sélecteur secondaireringKindéchoue (v4>=node.entryCountouentry[v4]==0xFFFF) →*a3=−1. Preuves supplémentaires issues du même journal :count=138(43 est dans la plage → ce n'est PAS le cas d'un « petit nombre »/43>=count)) ;slots 41/42 = 0xFF(aucun OD de groupe enregistré dans ce blob a2=1 → il n'y a pas de donneur frère) ;DIAG G0-finalize slot=2 od=3065 3064 3066 311A(le tampon circulaire de la couche A CONTIENT311A=cmd282 Ronso Rage — ce qui confirme que la porte correspond à 100 % au résolveur de l’arborescence de menu de la couche B, et non au contenu). Le correctif (code,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 logaNœud non viable, 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 : CAUSE PRINCIPALE du problème « rien n'apparaissait dans le menu de la magie blanche » DÉCOUVERTE + CORRIGÉ — la banque commune à tout le groupe est RECHARGÉE à partir de `party_data` À CHAQUE initialisation de combat, effaçant ainsi le « grant » avant l’affichage du menu
- (corrige le bug de comportement qui empêchait l'apparition de Nul Ward — même fonctionnalité/lab que
v2.123.4.0/v2.124.0.2; RE décisive testée sur la version.i64réelle + nouveau contournement de ré-assertion dansNulWardTeachHook; DLL publiée par Halyson, recompilation et déploiement effectués). Le symptôme : même après le correctif multi-site du menu-bound (v2.124.0.2) + grant on-load (journalNulWardTeach grant ch=0..6 radiant=1 umbral=1), les protections n'apparaissaient pas dans la magie blanche en combat. La RE qui a permis de résoudre le problème (idalib MCP, vérifiée au niveau des octets viadisasm) :sub_7817D0(«* BTL INIT») appelleFFX_Btl_PrepareSaveCommandState@0x786BC0(«-- SAVE RAM CLEAR -- Preparing save game data») à chaque début de combat ; dans0x786CA3, elle effectuemov ecx,21h; mov edi,offset dst__0; rep movsd— elle copie0x84(132) octets du noyauparty_data(table id 4) versdst__0=0x11307D8, plage[0x11307D8,0x113085C)qui couvre l'intégralité leg_PartyWideCommandBank@0x11307FC(décalage+0x24dans la copie ; banque = 16 mots, identifiants 96..351). ⇒ la banque commune à tout le groupe est écrasée à partir departy_dataà chaque combat, etparty_datan'a pas de bit de garde → mot14=0 →IsCommandAvailable(320/321)=0→ la boucle de placement ignore les gardes → « rien n'est apparu ». Suspects écartés :FFX_Btl_InitPartyWi deCommandBank@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 comSubMenuCategorization (octet +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 reassert #n post-PrepareSaveCmdState : bank word14 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)..i64real : commenté dans0x786BC0+0x786CA3(RÈGLE D'OR). 2 nouveaux RVA dansshared/ffx_addresses.h(RVA_FFX_BTL_PREPARE_SAVE_COMMAND_STATE,RVA_FFX_PARTY_WIDE_COMMAND_BANK). RT2 en jeu : lancer le combat et confirmer Radiant/Umbral Ward dans la magie blanche + vérifier le journalreassert ... word14 0x0000->0x0003. Risque connu : largeur duply_savepour les bits 224/225 (§H) — le lab réapplique à chaque chargement. Fichiers :RuntimeTools/FfxHooksDll/hooks/NulWardTeachHook.cpp,shared/ffx_addresses.h. Doc :docs/reverse/FFX_NUL_WARD_TEACH_SURFACE_RE_VERDICT_2026-06-16.md§I. [précédent :v2.130.1.0]
v2.130.2.1REVISIONJarvis-MAGIC
Spira Reforge : Magie noire étendue — conception verrouillée (famille Multi-Skill > niveau -ja ; `-ja` passe en backlog de niche ; Lulu Fury inclut tout)
- (document de conception + intégration dans VISION ; aucun writer/comportement/RT2 lors de cette passe). Halyson a lancé une réflexion sur la création de nouvelles magies noires. J’ai comparé deux approches : (a)
-jatier (Firaja/Blizzaja/Thundaja/Waterja = clone -ga avec +Power, exclut Fury) vs (b) Multi-Skill (versions AoE de sorts à cible unique « vanilla » qui n’ont pas d’équivalent AoE). Décision (Halyson) : Le Multi-Skill l’emporte comme voie principale ;-jamis de côté comme projet de niche (1 par élément, MP exorbitants ~80–120, post-Céleste, cerise sur le gâteau — ne fait pas concurrence au buff de-gadansVISION §10.5) ; Lulu Fury inclut TOUT (« Fury Drainga 16×, c’est un chaos magnifique, un OD de rêve »). Pourquoi Multi-Skill l’emporte : (1)TargetFlags.Multiest déjà intégré au moteur (FfxLib/Ability/Ability_Command.cs:125) — simple → multiple = 1 bit dans la ligne de commande ; (2) les sorts comblent une lacune réelle de la version de base (absence de poison AoE, de drain AoE, d’osmose AoE) et confèrent une identité ; (3)-jaest redondant avec le planVISION §10.5qui va déjà renforcer-gaavec Ignore MD EF / Ajustement de puissance (« Firaga reforgée » et non « Firaja ») ; (4)VISION §10.11a déjà classé Holyra/Holyga/Wildra dans la catégorie « marrant, mais peut-être jamais » pour la même raison (pool d'inflation sans identité) ; (5) Drainga/Osmose-ga alimentent d’autres fronts (Capture Cascade T7 – combats longs, mode SIN – malédictions, OD de monstres – multicast). Sorts de la première vague (v0.5+) validés techniquement : Biora (poison AoE + dégâts, clone Bio + Multi), Drainga (drain de PV AoE, plafond de 9999 par lancement), Osmose-ga (drain de PM de zone, plafonné à 99 par lancement), Demita (drain de PV de zone de 50 %, plafonné à 9 999 par cible), Famille Multi-Firaga (3× Firaga de zone séquentiels, triple consommation de PM — idée directement inspirée de Halyson : « Multi-Firaga par exemple>>>>>> » — sous-famille évolutive vers Multi-Blizzaga/Thundaga/Waterga/Ultima). Deuxième vague (v0.6+) : Slowga, Reflectga, Demi-fall (« Dimensional Crush » 75 % des PV, cible unique, MP coûteux), Quartera (25 % des PV, zone d’effet, MP peu coûteux). Blocages avérés et documentés : (a) emplacement d’ID de sort0..95— vérification croisée avecFFX_SPELL_FREE_ID_AUDIT_2026-06-12.mdpour identifier les donneurs ; (b) lignes Lulu Fury#12408–#12422: dump en attente ; (c) plafond de Drainga dépendant de RT2 (sans plafond = soigneur-attaquant surpuissant, plafond trop serré = sort inutile) ; (d) Multi-Firagahit_countlancé par les joueurs, pic de RE en attente ; (e) Effets visuels identiques à ceux de la version simple (valable pour la v0.5, recoloration à partir de la v0.6 via le moteur Flan Flood déjà testév2.114.0.0); (f) Décision séparée concernant le Sphere Grid. Plan technique incrémental (§6.2 du document) : Phase A : audit des identifiants des donateurs (sans code, ce document), Phase B : création hors ligne (clonage de lignes + inversion Multi + ajustement de la puissance/MP + saisie de texte), Phase C : LAB de développement, Phase D : RT2 en jeu, Phase E : intégration de Fury, Phase F :-jabacklog de niche (v0.7+). Intégration avec le mod : complète§10.5le buff de magie noire, alimente§10.6Lulu Fury, préserve§10.11le puzzle élémentaire, réagit aux§10.13mob OD multicast avec Drainga/Osmose-ga, prend en charge§11les combats Capture Cascade T7. VISION_AND_ROADMAP.md mis à jour : nouvelle section 12 « Magie noire étendue — Famille Multi-Skill » (décision de conception + sorts de la première/deuxième vague + lien avec la feuille de route + documentation complète) ; références renumérotées à la section 13. Questions ouvertes pour une réflexion continue : Mécanique Multi-Firaga A/B/C (Doublecast intégré vs répartition aléatoire vs hybride el ement — recommandation A), Drainga : limite par cible vs par sort, connexion Sphere Grid, coexistence entre Demita et Demi vanilla, AoE de magie blanche (Esuna-ga ?), niveau des donneurs. Ne concerne pas : aucun writer, aucun hook, aucune sonde, aucune DLL, aucun gate hors ligne/RT2. Uniquement des documents + intégration de la feuille de route. Nouveau document :docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md(10 sections, environ 300 lignes). Fichiers modifiés :FFXProjectEditor/FFXProjectEditor.csproj(bump 4-tuple),mods/Spira Reforge/VISION_AND_ROADMAP.md(nouveau §12 + renumérotation des références §13),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [précédent :v2.130.2.0]
v2.130.3.0PATCHJarvis-MAGIC
Ronso Mana CRASH HOTFIX (`hudSafe=26`) : l'écriture du blob ne provoquait plus de plantage (auparavant `via=rich>=1 subIdx=0x01` → plantage) ; désormais, l'écriture est en mode OPT-IN + uniquement des nœuds sécurisés + lectures protégées par SEH
- (corrige le plantage de comportement introduit par
hudSafe=25dev2.130.1.0lorsque la DLL a été recompilée/déployée dans la versionv2.130.2.0de la voie Nul Ward). Cause première (journal RT2%TEMP%\ffx-hooks.log) :RonsoMana BLOB-PATCH2 #1 treeId=43 set subIdx=0x01 via=rich>=1 nodeOff=0x1B4 ec=24 (was 0xFF)— le fallback (3) « nœud le plus riche » de monhudSafe=25a écrit un index de nœud CHUTADO (0x01,ec=24) dansblob[2+43]. Cela a permis àResolve(2,1,43)« réussir » dans un nœud qui n'est pas l'anneau d'OD →finishMenuTreea affiché du contenu erroné → le jeu a planté. (L’ancien0x00dehudSafe<=24renvoyait simplement −1 et ne provoquait donc PAS de plantage : il n’appelait jamaisfinishMenuTree.) Mon modification « a transformé un état défectueux mais sans danger en plantage ». Le correctif (hudSafe=26) : (1) l'écriture du blob est désormais OPT-IN — elle n’enregistreblob[2+treeId]que lorsque l’environnementFFXHOOKS_RONSO_OD_BLOBWRITE=1est défini ; par défaut = n'écrit RIEN (version à l'épreuve des plantages, purement diagnostique viaODBLOB); (2) même avec l'opt-in, n'enregistre que le nœud PRINCIPAL — (a) nœud dont les entrées contiennent la commande OD codée0x311A, ou (b) nœud frère de type « party-OD » 41..47 que le jeu a déjà enregistré ; jamais n'enregistre automatiquement le c hute « nœud le plus riche » (celui-ci ne figure que dans le journal, pour un éventuel codage en dur après lecture du dump) ; (3) toutes les lectures de nœuds (OdBlobNode/OdBlobEntry) et le bloc a2=0 deDumpOdBlobStructureOncesont désormais protégés par SEH (__try/__except) — toute violation d'accès due à un décalage hors limites (OOB) se traduit par un « nœud invalide » propre au lieu d'un plantage ; (4)mainPtrde a2=0 bénéficie désormais d’un contrôle de cohérence (> 0x10000). Le journal affiche désormaisBLOB-PATCH2 #n ... write=0|1 safe=0xXX(how) risky=0xXX(how,ec=..)(indique ce qui se passerait sans écriture) et, en cas d’activation + nœud sécurisé,BLOB-PATCH2 WROTE .... BannièrehudSafe=25→26. Réversibilité : sans l’environnement, comportement = « vanilla » sécurisé (OD caché, pas de plantage). Je ne l'ai PAS compilé/déployé (DLL partagée avec d'autres lanes Jarvis-MAGIC) — la prochaine recompilation deffx-hooks.dll(par n'importe quelle voie) inclura déjà le correctif ;ReadLintspropre. Fichier :RuntimeTools/FfxHooksDll/hooks/RonsoManaHook.cpp. Doc :docs/reverse/FFX_RONSO_MANA_COMMAND_RING_PIPELINE_RE_2026-06-16.md§14. [précédent :v2.130.2.1]
v2.130.3.1REVISIONJarvis-MAGIC
Spira Reforge : Magie noire étendue — 4 décisions prises par Halyson (Multi-Firaga option B, Drainga avec plafond par cible suprême, Demita coexiste avec Demi, Fury « tout inclure » avec nuances)
- en cascade après
v2.130.3.0(hotfix MINEUR de Ronso Mana provenant d’un autre Jarvis-MAGIC parallèle). Suite immédiate du document de conception dev2.130.2.1: brainstorming avec H Halyson a tranché les 4 dernières décisions en suspens. (1) Mécanique Multi-Firaga — option B (répartition aléatoire) + 3 à 5 fois les PM de base : Halyson : « Option B, mais le “Multi-Firaga”, le “Multi-Fodase”, coûtera 3 à 5 fois le MP initial de la compétence de base pour compenser, ça va être une sacrée raclée ». Mécanique = 1 lancement → N coups (5-7), chaque coup touche un ennemi aléatoire (moteur natif via la formule Holy/Comet/Doublecast). Les ennemis peuvent subir 1, 2, 3+ coups du même Multi-Firaga selon le RNG. Coût en PM = 4× la valeur de base par défaut (Multi-Firaga = 64 PM), Multi-Ultima = 200 PM. Suggestion de Jarvis : commencez avec 4× PM + 6 coups, ajustez RT2. Famille évolutive (déploiement progressif) : 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) Plafond de Drainga — par cible 9 999/cible (plafond multiple) : Halyson a intégré cette fonctionnalité en pleine connaissance de son impact. 4 ennemis en vie = jusqu’à 39 996 PV de soins en un seul sort = soigneur offensif suprême. ⚠ Peut casser une longue arène — c’est intentionnel, c’est un mod d’Halyson, un fantasme de fin de jeu. Contrepartie : le coût en PM peut grimper jusqu’à environ 30 après RT2 si ça casse tout. (3) Demita vs Demi vanilla — elles coexistent : Gardez LES DEUX. Demi single (16 PM, tueur de boss) + Demita multi (24 PM, nettoyage de vagues). Le joueur choisit son outil. Coût : 1 emplacement d’ID supplémentaire. (4) Fury de Lulu « tout inclus » avec des nuances (décisions §4 mises à jour) : Biora 16× = ok (vague de poison) ; Drainga 16× = plafond de Fury uniquement à 9 999 par sélection (pas par cible en mode Fury, sinon jusqu’à 639 936 PV de soins — « ça n’a plus de sens ») ; Osmose-ga 16× = ok (plafond de PM à 9 999 = limite absolue) ; Demita 16× = ok (Demi cesse de toucher une cible morte) ; Multi-Firaga 16× = 96 coups potentiels ⇒ les sorts Multi- de Fury utilisent hit_count=1 (revient à un sort à lancement unique en Fury)* OU exclut les sorts Multi-* du pool de Fury (seule exception à la règle « include all »). La décision finale ajustera RT2. Questions en suspens mises à jour au §8 du document : §8.1 tranchées (4 confirmées) ; §8.2 encore en suspens (fil de la grille Sphere, portée de la magie blanche en zone, confusion liée à l’absorption d’éléments, le niveau des donneurs0..95bloque la phase A, la répartition aléatoire de Multi-*command.binvia un pic). Document mis à jour :docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md§2.2 Draigna (plafond par cible fixé), §2.4 Dismiss (c (il n'y a pas de « cravado »), §2.5 Multi-Firaga (option B + MP 3-5× fixé + tableau élémentaire complet), §4 Fury (nuances par sort), §8 questions en suspens (4 marquées comme résolues, 5 encore en suspens), §9 Version de livraison mise à jour. Prochaine étape sûre : Phase A : audit croisé des identifiants de sorts avecFFX_SPELL_FREE_ID_AUDIT_2026-06-12.md— Halyson décide s’il s’y met dès maintenant ou s’il attend que la v0.5 soit presque prête. À ne pas toucher : writer/hook/probe/DLL/gate. Fichiers :FFXProjectEditor/FFXProjectEditor.csproj(en cascadev2.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 mis à jour),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [précédent :v2.130.3.0]
v2.130.3.2REVISIONJarvis-MAGIC
Spira Reforge : PIVOT ARCHITECTURAL — la section « Magie noire étendue » a été renommée « Commandes par personnage étendues » (RE D01 testée + distribution étendue à 7 personnages)
- (suite immédiate
v2.130.3.1; aucun auteur/comportement). Halyson a proposé : « Et si, au lieu de ces ski « Si elles peuvent être acquises par « tout le monde », pourquoi ne pas les réserver à « uniquement le personnage X » ? » — J’ai comparé avec la RE existante et j’ai DÉCOUVERT que le moteur vanilla PREND DÉJÀ EN CHARGE NATIVEMENT la propriété par personnage pour les identifiants0..95. La découverte cruciale (RE D01 —FFX_SPELL_LEARN_ABIMAP_INFERNO_2026-06-15.md) :FFX_GrantCommandToCharacter @ 0x785D10comporte un SPLIT À L'INDEX 96 : les identifiants< 96sont dirigés vers la base de données par personnageword_11307FC[74*char+3151+(id&0xFFF)/16](stride de 74 mots =ply_savepar personnage) ; les identifiants>= 96sont stockés dans la banque FLAT commune à tout le groupe (sans stride). ⇒ L'espace d'apprentissage par personnage est EXACTEMENT de 96 bits, ID 0..95. Les ID ≥ 96 ne peuvent pas être appris par personnage. Implication : la réaffectation des identifiants0..95= le moteur vanilla filtre QUI voit chaque sort sans aucun hook. Ancienne méthode (identifiants ≥ 96 + détournement de type Nul Ward pour restreindre l’accès) écartée. Répartition élargie (décision de Halyson du 16/06/2026, citations conservées) : Lulu (6 sorts, lanceuse de rafales + drain de PV) — Famille Multi-Firaga × 4 + Drainga + Osmose-ga (transférée de Yuna à Lulu), éventuellement Demita ; Yuna (5 sorts, zone d'effet blanche/buff) — Reflectga + Protectga + Shellga + Esuna-ga + Dispelga (« Reflectga, Protectga, Shellga, Esunaga, Dispelga pour Yuna ») ; Rikku (3 sorts, experte en vol) — Copycat devient une compétence exclusive à Rikku + Mugra (attaque simple à 2 coups, 2× vol) + Mugga (attaque de zone à 2 coups, faibles dégâts, « pouvant voler jusqu’à 6 fois !!!! ») ; Wakka (à déterminer, « plus de compétences de statut et des trucs encore plus fous ») ; Kimahri (à déterminer, « Mage bleu. Les compétences des monstres et même ses propres Overdrivers pourront être appris pour être utilisés avec du mana » — coordination de la voie Ronso Mana) ; Tidus (à déterminer, « 0 idée, mais peut-être des compétences multi-coups ») ; Auron (« LE PUTAIN DE TANK DU JEU. Évolution du Sentinel, peut-être des Breaks de zone plus puissants »). Total estimé : 28 à 31 sorts sur 96 emplacements = environ 30 % du budget, il reste plus de 65 emplacements pour le-jabacklog v0.7+ + futur. 9 décisions figées dans le document §9.1, 10 encore en suspens au §9.2 (Licenciement du propriétaire, pools Wakka/Tidus/Auron, remplaçant de Rikku Copycat, connexion Sphere Grid, audit du donneur 0..95, champ de Multi-Firaga à coup aléatoire, vol par coup pour Mugra/Mugga, coordination Blue Mage de Kimahri sur la voie Ronso). Avantage du modèle : (a) zero hook custom — moteur vanilla natif ; (b) Les arbres de la grille Sphere prennent tout leur sens (passer à un autre arbre = véritable compromis) ; (c) Lulu Fury simplifie considérablement les choses — le pool de Fury est par personnage en mode vanilla, « exclure les Multi-* de la Fury » n'est plus un problème ; (d) Capture Cascade §11 et Mode SIN §10.13 offrent des réponses tactiques distinctes par personnage. Plan technique (§7.2) : Phase 0 : définir les réserves (à déterminer) → Phase A : audit des donneurs (bloque le démarrage) → Phase B : création par personnage (B Lulu pilote, B.1 Yuna White AoE, B.2 Rikku Mug family avec spike « steal-per-hit », B.3 réserves à déterminer) → Phase C/D : RT0/RT1/RT2 → Phase E : Sphere Grid wire (extension de l’éditeur Spira Grid) → Phase F : lignes de Lulu Fury → Phase G : Kimahri Blue Mage (dépend de la voie Ronso) → Phase H : backlog -ja v0.7+. VISION_AND_ROADMAP.md §12 réécrit : « Magie noire étendue » → « Commandes par personnage étendues » + tableau de répartition par personnage + blocages + feuille de route mise à jour. Document renommé d'un point de vue conceptuel (chemin d'accès conservé à des fins d'historique) :docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md— 11 sections, §1 Modèle de propriété par personnage avec décompilation RE D01 vérifiée au niveau des octets, §3 répartition par personnage (3.1 Lulu, 3.2 Yuna, 3.3 Wakka à déterminer, 3.4 Rikku, 3.5 Kimahri coord, 3.6 Tidus à déterminer, 3.7 Auron à déterminer, 3.8 résumé). Ne pas modifier : writer/hook/probe/DLL/gate. Uniquement conception + intégration de la feuille de route. Fichiers :FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.1→v2.130.3.2),docs/reverse/FFX_SPIRA_REFORGE_BLACK_MAGIC_EXTENDED_RESEARCH_2026-06-16.md(réécriture majeure : nouveau §1 RE D01, §3 distribution étendue à 7 caractères, §5/§7/§8/§9/§10/§11 renumérotés et mis à jour),mods/Spira Reforge/VISION_AND_ROADMAP.md(§12 réécrit),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [précédent :v2.130.3.1]
v2.130.3.3REVISIONJarvis-MAGIC
Spira Reforge : PHASE 0 TERMINÉE A — Halyson a rempli TOUS les pools TBD par personnage en une seule fois (Demita→Kimahri, Wakka 5 sorts, Auron pack MAX 6 sorts, Tidus multi-coups + auto-buff, Rikku +1 nouvelle compétence de voleur)
- (troisième passage du 16/06/2026, suite immédiate
v2.130.3.2; aucun writer/comportement). 4 décisions supplémentaires prises (de 9 → 13) : (1) Remplacer le propriétaire = Kimahri (gimmick « monstres bizarres » + thème du Mage Bleu ; libère Lulu pour qu’elle se concentre sur l’explosion élémentaire) ; (2) Pool de Wakka = combinaison A+B, 5 sorts — Biora (poison de zone + dégâts) + Sleepra (sommeil de zone) + Quad Foul (Triple Foul de zone + poison = 4 altérations) + Double Buster (attaque en 2 coups, combo de 2 altérations aléatoire) + Tide Slash (attaque physique en 2 coups) — « maître des altérations + double coup + trucs dingues » ; (3) Pool d’Auron = pack MAX, 6 sorts — Mass Power Break + Mass Armor Break + Mass Magic Break + Mass Mental Break + Sentinel++ (Sentinel + blocage physique et magique + effet sur tout le groupe pendant 1 tour) + Provokeja (Provoke + auto-Sentinel + provocation de tous les ennemis) — « Auron est le putain de TANKER du jeu » ; (4) Tidus : multi-coups + auto-buff, 4-5 sorts — Spiral Slash (3 coups individuels, +5 FOR/plafond de lancement à 25) + Tidal Combo (4 coups en zone, +5 AGI/lancement, plafond à 20) + Bladestorm (5 coups aléatoires, +Hâte sur soi-même pendant 1 tour) + Aurochs Rush (fête, +AGI fixe + Hâte pendant 3 tours) + en option Cheer-strike (2 coups + Cheer sur soi-même). « Tidus a toujours été le plus rapide. Quick Hit VA ÊTRE NERFÉ, donc les compétences à coups multiples qui confèrent des buffs augmentant la vitesse d’attaque du personnage lui-même » — compensation directe du nerf de QH §10.6 ; (5) Rikku +1 nouvelle compétence de voleur — Halyson a demandé une « compétence de voleur inventée » pour compléter le pool ; suggestions de Jarvis : Sleight of Hand (Mug amélioré), Pickpocket (vol sans coût de tour ; par défaut Jarvis), Sticky Fingers (cumul +25 % par lancement), Backstab (ignore la défense physique), Cache (vol direct du pool), Smoke Bomb (saut du CTB pour le groupe). Répartition finale complète (Phase 0) : Lulu 6 + Yuna 5 + Wakka 5 + Rikku 4 + Kimahri 3 + Tidus 4-5 + Auron 6 = 33-34 sorts sur 96 emplacements = ~35 % du budget (il reste 62+ pour le-jabacklog v0.7+ + les sorts de magie blanche supplémentaires). Combos émergents entre personnages : Auron Mass Mental Break + Lulu Multi-Firaga (vague d'attaques sans MDEF) ; Auron Sentinel++ + Yuna P rotectga/Shellga (2 tours d'invulnérabilité quasi totale) ; Auron Provokeja + Wakka Quad Foul (tank + altérations de statut de masse) ; Tidus Bladestorm + Auron Mass Armor Break (burst de Tidus + cibles sans DEF). Risque supplémentaire lié au self-buff de Tidus : cumul infini de STR/AGI = dégénérescence de type QH ; atténuation due au plafond de cumul (5 STR / 4 AGI) + décroissance à la fin du combat (ne persiste pas d’un combat à l’autre). 11 questions en suspens restantes au §9.2 — il s’agit soit de décisions de détail (nom définitif de la compétence de voleur de Rikku, 4 ou 5 sorts pour Tidus), soit de pics techniques (Multi-Firaga à coup aléatoirecommand.binaléatoire, vol par coup de Mugra/Mugga, effet d’état de Wakka par coup, cumul des auto-buff de Tidus, buff Sentinel++ d’Auron pour tout le groupe, persistance de Lancet+ de Kimahri) — Ils ne bloquent PAS la conception globale, mais bloquent des phases spécifiques de la création. L’audit des contributeurs0..95(§9.2 q18) a désormais une portée concrète : environ 33 à 34 emplacements requis. Document mis à jour : §3.1.4 « Demita » déplacé vers §3.5.1 Kimahri ; §3.3 Wakka : 5 sorts fixés ; §3.4 Rikku : +1 compétence de voleur avec 6 suggestions ; §3.5 Kimahri : pool complet (Demita + extension Blue Mage 2-3) ; §3.6 Tidus : pool de 4-5 sorts à coups multiples + auto-buff avec combos contre le nerf de QH ; §3.7 Auron : pack MAX de 6 sorts avec combos inter-personnages + risque/atténuation ; §3.8 résumé total : 33-34 sorts = 35 % du budget ; §9.1 13 décisions ; §9.2 11 sous-décisions/pics ; §10 entréev2.130.3.3. VISION §12 mise à jour : tableau de répartition finale par personnage + combos émergents. Ne pas toucher : writer/hook/probe/DLL/gate. Fichiers :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 déplacé + §3.3/§3.4/§3.5/§3.6/§3.7/§3.8/§9/§10 mis à jour),mods/Spira Reforge/VISION_AND_ROADMAP.md(§12 table de billard finale + combos),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [précédent :v2.130.3.2]
v2.130.3.6REVISIONJarvis-MAGIC
Spira Reforge : REALITY CHECK + 3 inversions — Chemin 4 (`CharacterUser` natif) verrouillé + apprentissage via la grille des sphères verrouillé. Halyson a vu ce que je n’ai pas vu
- (quatrième passe du 16/06/2026, suite
v2.130.3.3; aucun writer/comportement). Séquence d’itérations architecturales dans cette session : (1) v2.130.3.2 pivot : j’ai découvert dans RE D01 que les identifiants0..95sont natifs par personnage, je l’ai noté comme « zéro hook + 62 emplacements restants ». (2) Halyson a ouvertFFX_SPELL_FREE_ID_AUDIT_2026-06-12.mdet a demandé « Comment ça ? » : l'audit du 12/06/2026 a déjà prouvé0/96l'existence d'emplacements libres — les 96 identifiants sont tous occupés par la version vanilla. Mon affirmation « il en reste 62 » était fausse. (3) v2.130.3.4 Piste 3 : j’ai proposé d’ajouter≥96+ un hook de liste blanche par personnage (à la manière de Nul Ward généralisée), Halyson a donné son accord. (4) Halyson a envisagé la solution 4 : « Dans CommandBin, ne suffirait-il pas que je sélectionne simplement : CHARACTER USE (par exemple TIDUS) pour une compétence, et le problème serait réglé ? On n’aurait pas besoin de hook du tout ». JE N’AVAIS PAS REMARQUÉ le champ natif[Data] public Character_Enum CharacterUserdansAbility_Command.cs:29— un octet signé danscommand.binqui restreint l’accès à chaque commande. Preuve octet par octet :FFX_SPELL_FREE_ID_AUDIT_2026-06-12.mdla ligne 86 mentionne Yojimbo Dismiss (id 87) et comporteCharacterUser=0x0E(14=Yojimbo) — le moteur vanilla filtre lui-même le menu en fonction de ce champ. Interface utilisateur déjà existante (KernelCommands_Control.axaml:434ComboBox). La méthode 4 remplace les méthodes 1, 2 et 3 — ajouter≥96avecCharacterUserpar personnage, défini directement via l’éditeur d’interface utilisateur. AUCUN hook pour le filtrage du menu. (5) Halyson a précisé : « Les compétences pourront être apprises via la grille des sphères » — cela réactive la mise en garde Nul Ward §H pour les identifiants≥96(la banque commune à tout le groupe, rechargée à chaque initialisation, écrase la grille d'attributs). Solution : 1 hook généralisé étendantNulWardTe 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
Document de référence : catalogue consolidé des 96 compétences de personnage (ID `0..95`) avec `Power`/`MP`/`Formula`/`Acc`/`Hits`/élément/effet + architecture AbiMap × banque commune à tout le groupe
- (document d'enregistrement / catalogue de référence ; pas d'auteur/comportement/RT2 ; consolide simplement en un seul document les informations déjà dispersées dans
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 a demandé le tableau des 96 compétences en MD à des fins de référence opérationnelle pour le mod. Nouveau documentdocs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md(8 sections, environ 250 lignes) : §0 TL;DR : limite fixée à 95 (AbiMap 96 bits physiques) + vérifications RE croisées ; §1 : comment le moteur détermine le menu (FFX_Btl_IsCommandAvailable @ 0x39BB70par personnage vs pour tout le groupe avec le filtreCharacterUser); §2 encodageLearnedMove = 0x3000 | iddupanel.bin(référenceSphereGridExplorer_DataModel.cs:30-31); §3 catalogue complet 0..95 divisé en 9 groupes (Core/Menu 0-5, Skill 6-21, Special 22-25, Cheer 26-31, Kimahri/Def/Social 32-42, Wht Magic 43-64, Blk Magic 65-83, Menu Aeon 84-87, Rikku fin de jeu 88-95) avec les valeurs canoniques de FFX HD Remaster (US/JP) — MP/Puissance/Formule/Précision/Coups/Élément/Effet ; §4 scénario décisif de « what the magic IS » via 3 indicateurs (DamageFlags+DamageFormula_Enum+PreviewFlags) avec le tableau Soin/Réanimation/Purification/Physique/Magie/État/Amélioration/Gravité/Drain ; §5 les 11 ID non enseignables via la grille (missing=[0,1,2,3,4,5,33,84,85,86,87]dans les 10 régions — system/Defend/Aeon/Yojimbo) ; §6 les ID 96+ valables pour tout le groupe (Overdrives, Aeons, Mortes, Mix, pseudo-IA) avec 3 raisons de conception justifiant leur séparation ; §7 les conséquences pour Spira Reforge liées au Caminh le n° 4 dev2.130.3.6; §8 références croisées. Ne concerne pas : writer/hook/probe/DLL/gate. Fichiers :FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.6→v2.130.3.7),docs/reverse/FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.md(nouveau),CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md. [précédent :v2.130.3.6]
v2.130.3.8REVISIONJarvis-MAGIC
Spira Reforge : 1re phase du rééquilibrage offensif « Vanilla » finalisé — 16 compétences offensives améliorées + nettoyage des capacités automatiques + augmentation des sphères de PM
- (uniquement conception / décisions validées par Halyson ; aucun rédacteur/comportement dans cette passe). Halyson a ouvert
FFX_PLAYER_COMMAND_CATALOG_0_TO_95_2026-06-16.mdet a déclaré : « Les sorts remplissent leur rôle, y compris les sorts de soin. Mais le reste ? PATHÉTIQUE. Full Break ? Va te faire foutre, en plus ça ne touche presque jamais, et les dégâts sont ridicules pour 99 de PM. » Diagnostic sans concession : 20 compétences offensives de base avecPow er = 16(= multiplier 1.0× = Attack base) ouPower < 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. Séquence des décisions prises lors de cette session : (a) Halyson a ouvert le catalogue, identifié le problème ; (b) j’ai proposé un tableau de buffs pour 20 compétences + 4 catégories d’auto-compétences ; (c) Halyson a défini « Extracts » désactivés + « Full Break » 3× ; (d) a défini « One MP » supprimé + « Mana Shield » non (crée une nouvelle méta) ; (e) j’ai confirmé le §10.8 en inversant l’emplacement 23 qui devient Br eak Limits et l'emplacement 24 sont désormais réaffectés (« xereca ») ; (f) j'ai ajouté Devil's Bargain à l'emplacement 24 + j'ai compris la mise en garde concernant le 2-pass ; (g) j'ai optimisé Mana Spring à l'emplacement 13 + le backlog de Spell Spring. Réserves techniques répertoriées : Devil's Bargain nécessite un hook pour le calcul des dégâts + adresse REFFX_DamageCalc_*en attente ; Mana Spring nécessite un hook « turn-tick » + identification d’un bit libre dansability_flags_64; Précision du coup vs précision du pic de status-rider en attente RT2 ; pic de Triple Foul Acc 100→90 en attente (vérifier que la « triple garantie » ne se casse pas) ; Mise à l'échelle des MP en Full Break en fin de partie OK (75 reste très coûteux avec Half MP) ; la réaffectation du bit d'auto-capacité à l'emplacement 24 doit scanner les indicateurs libres dansAutoAbilityHardcodedFlagCatalog.cs. Plan technique Phase 1 (modification pure par octetv2.131.xPATCH) : 1.1command.bin1.1 Buff offensif de 16 compétences, 1.2 Emplacement 23 « Break Limits », 1.3 Emplacement 13 « Mana Spring » (espace réservé), 1.4 Emplacement 24 « Devil's Bargain » (espace réservé), 1.5panel.binnœuds de PM, 1.6 pool de texte, 1.7 identité d'octet de la porte RT0/RT1, 1.8 pilote RT2. Phase 2 (hooks LABv2.133.x+) : 2.1 Calcul des dégâts RE, 2.2 Hook de tick de tour de Mana Spring, 2.3 Hook de dégâts de Devil's Bargain, 2.4 Hooks RT2. Synergie avec VISION : §10.4 Nerf du QH (complémentaire — buff des compétences + nerf du QH = offensive diversifiée), §10.5 Magie (inchangée, prochaine version), §10.6 OD Lulu Fury (prochaine version), §10.8 « Break » HP+MP fusionnés (FIXÉ dans cette version 1.2), §10.9 compétence secrète d’Auron (RENFORCÉ — « Break Limits » + « Devil’s Bargain » + buff des « Breaks » = « Auron, le preneur de risques invincible »), §10.10 vitesse de magie (Spell Spring en attente), §10.11/§10.13 (prochain passage), Chemin 4 Black Magic Extended (indirect — la base vanilla crée un contexte pour ≥96 sorts). Liste des questions en suspens : Spell Spring attend le prochain emplacement libre (candidats au sacrifice : emplacement 18 Double AP, 19 Triple AP, 21 Pickpocket, 22 Master Thief — astuce de progression/butin) ; Status/Break Sharpness pour les prochaines identités par personnage §10.9. Ne pas toucher : writer/hook/probe/DLL/csproj côté writer. Fichiers :FFXProjectEditor/FFXProjectEditor.csproj(v2.130.3.7→v2.130.3.8) ;docs/reverse/FFX_SPIRA_REFORGE_VANILLA_OFFENSIVE_REBALANCE_2026-06-16.md(nouveau, ~280 lignes, 7 sections : §0 brève explication, §1 carnage diagnostique « vanilla », §2 paquet consolidé c avec le tableau 16 compétences + nettoyage des capacités automatiques + Sphère MP, §3 précisions techniques (6 éléments), §4 plan de mise en œuvre (phases 1 et 2), §5 questions en suspens, §6 version de livraison, §7 références croisées) ;CHANGELOG.md+changelogUS.md+docs/governance/VERSIONING.md+docs/ai/SESSION_HANDOFF.md+mods/Spira Reforge/VISION_AND_ROADMAP.md(étape suivante). [précédent :v2.130.3.7catalogue de référence]