# 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.