GaCy-GO/docs/currency-wars-current-consumer-notes.md

CW current consumer evidence — 2026-10-25

Target assembly SHA256: 4aa08a0706f27d2cf9951b61920c179140ece9ea94f7e34422c18e46922939b6. These observations belong to this target; the older base catalog/reference has not thereby been recaptured in full.

Tea Break

The bounded read-only tools/cw_teabreak_runtime.lua capture confirms that the current Client session sees route 2801, chapter 1, section 5 as a Bonfire node. Its BonfireEventIds contains 10200601. The live node parameter itself already contains this list. Thus missing Bonfire flags/event IDs are not the blocker at this particular node. Do not add guessed node data to fix it.

GridFightGameEventData is a set of change collectors, not the Bonfire choice processor. Its captured methods are Reset/Dispatch/GetCollector/RegisterCollector and initialization; no missing game-event protobuf component was established.

Focused native disassembly of _RefreshBonfireEventIds at RVA 0xdc635b0 (AMD64 exception-table bounds) copies the event list from the node parameter into the cached list. It does not resolve event configuration. The direct caller at 0xdc631f0 copies the Bonfire flag from the node parameter. Leaf getters at 0xdc64be0 and 0xdc64c00 independently read the cached flag/list; those two artifacts use explicit ranges because leaf getters have no unique unwind entry.

Artifacts: battle_diagnostics/cw54-teabreak-runtime-20261025.log, cw54-bonfire-refresh.asm, cw54-bonfire-refresh-caller.asm, cw54-is-bonfire.asm, and cw54-bonfire-ids.asm.

The unresolved step is the actual EnterBonfire caller/callback and its expected choice/action/effect state. The reference has no EnterBonfire implementation. The existing retcode-only success does not establish functioning Tea Break.

Entrance and exit

Passive exact-name loadbuffer capture, requested through package loader closures without executing those closures, produced the current S2 entrance and season router chunks under .runtime/named-baked-capture/.

The S2 entrance's _on_btn_start names the actual next module: Ui.GridFight.Division.Start.GridFightDivisionStartPage. Its _on_dispose only stops the CW menu audio state; no blanket camera/Canvas restoration is justified by that function. The button-overlap screenshot belongs to the Division Start screen, so its status/continue/end callbacks are the next required consumer, not a reason to move arbitrary buttons.

The season router selects Legacy/Latest presentation using GridFightModule.Instance.IsCurSessionLatest. It supplies real prefab paths, not a Bonfire event module path. No invented Bonfire page names were loaded.

Orb boundary

Grant/list commands already cover captured Orb IDs, consumables and Forge items. That is separate from dropping/opening Orbs. Current resources retain 529 Orb display rows and 478 combination rows, but lack a complete matching basic bonus pool plus the current open-Orb sender/callback mapping. The older reference's custom basic-Orb rewards are not a complete current-revision reward table.

The current runtime capture now includes MethodHandle values for GridFightOrbServerData. Resolving the native entry at MethodHandle + 8 and disassembling against the assembly hash above establishes the following:

• GetOrb(List<uint>, bool), RVA 0xdbe3c50, forwards to the network sender at 0xe3ff8f0. That sender puts the list at request offset 0x18, the bool at 0x20, and sends command 0x21af (8623).
• The current protocol table names 8623 IKMOCJBMGOJ; its current schema is repeated uint32 field 4 plus is_get_all field 9. This agrees with the native argument layout. Historical reference names for its response/notification are leads only: no new response pair is registered from historical IDs.
• The nested <>c__DisplayClass11_0 is a count/filter closure, not the GetOrb response callback. Its method is <GetOrbCountByType>b__0 and its captured field is GridFightOrbType.
• The actual nested OrbSummarizer consumes the sync update context. At RVA 0xdbe5370, IsConcernedWith accepts enum value 1. At 0xdbe5520, UpdateBefore requires the same value and uses the first context uint as the Orb UID; it looks up or creates the result for that UID. UpdateRemoveOrb at 0xdbe58a0 records removed UIDs. PreUpdateDone at 0xdbe5bb0 dispatches accumulated results only for UIDs included in the removed set.

Accordingly, an eventual proven Orb payout must use one ABPLALCHNFA group per Orb UID, with grid_update_src enum value 1, OOEOCGLLHFO = [orbUID], and the actual removal/loot updates in JKPJFKCBIEM. Sending ungrouped updates under the default context cannot construct the Client's Orb result through this consumer. This establishes the consumer context, not the missing reward rolls or the response callback.

The live session's Bonus is RPG.Client.GridFightBonusServerData, a bonus distributor with trait/initial-supply results and a distributor queue. It is not evidence for a random bonus-pool config repository. Four previously recorded candidate row names are absent from the inspected current config assembly; this is not proof that the data itself is absent or cannot be resolved under other names.

Artifacts: cw54-get-orb-sender.asm, cw54-get-orb-network-sender.asm, cw54-orb-consumer-rvas-20261025.json, and cw54-orb-context-{filter,before, remove,complete}.asm under battle_diagnostics/. Native resolution was a read-only, bounded Frida attachment, with the current process and module range checked first; no hooks, native gameplay calls, or memory writes were used.

Pending current consumer capture

tools/cw_teabreak_current_consumer.lua is prepared outside scripts/. It exports only three established live Preparation callback functions, their source/upvalue names, and eight fields per heartbeat from the actual session and Stage types. It skips Battle and sends no gameplay requests. It has not yet been staged or captured. This can identify the real loader/service path before attempting any Tea Break pending action implementation.

The captured Division Start _setup_btn_state already uses mutually exclusive start/continue visibility: continue follows _is_in_game, start follows its negation. The settle button uses _should_show_settle_btn. The overlap report therefore requires observing the live visibility/state application; moving buttons arbitrarily would not fix the proven state consumer.