GaCy-GO/docs/offline-gameplay-continuation.md

# Offline continuation and acceptance requirements

> Latest handoff: [ZCODE-HANDOFF.md](ZCODE-HANDOFF.md), 2026-10-24. This file
> retains chronological findings; some statuses below are superseded, including
> the user's confirmation of Aha Help, newly staged event previews and the CW
> role compatibility overlay. Use the handoff for current priorities/deployment.

The full CW objective remains active. Additional requests do not replace it.

The user subsequently specified that Stella Jump, activities, gacha and Aha's
Help must be handled before returning to CW. Preserve that order.

## Offline audit round, 2026-10-24 afternoon

With no server or game process running, both servers were rebuilt from the
latest source and deployed at 14:07 (root and `for ship`), then documented in
[ZCODE-HANDOFF.md](ZCODE-HANDOFF.md). Three source/resource changes went into
that build: the CW role-ID projection in `session.go` now also covers
`GridFightEnterBattleStageScRsp`, `GridFightEndBattleStageNotify` and
`GridFightGetArchiveScRsp` (the proto audit found no map transitively carrying
role references, and in-memory run state was already projected, so this is
defense in depth); `activity_preview.go` replaced silent first-match module
dedup with verified panel equivalence (module 1002101 legitimately spans
rerun panels 10021/10113 with an identical prefab; the published schedules are
unchanged at 12); and the stale `asset_verification_note` in
`GachaSandboxPolicy.json` now states all six captured prefab paths were
checked. No Client confirmation exists for any of this.

Stella Jump gateway analysis from `gameserver.log`/`server_debug.log`: the
"There's still more to do…" toast attempts are InteractProp on prop entities
1035/1012 with interact_id2=1100, answered with the real prop state; the
GameBoy UI itself opened once without an interaction (case 16 data request)
and closed without a start request, so the block is a client-side condition.
`ChenLingGetDataCsReq` (9612) is sent every floor load and still dropped by
the ChenLing danger family; a populated `ChenLingGetDataScRsp` capture is the
missing evidence before it can be answered safely.

## Latest steering and staged technique fix

The user confirmed Aha Help appears in combat. Their next report concerned
technique points before combat, not combat skill points: Endgame rooms start
with only five usable points despite a larger team capacity. Both the initial
Endgame lineup projection and session initialization used overworld initial_mp.
Endgame lineup construction now starts at its resource-derived MaxMp, and a new
room's session technique counter uses that same capacity. Overworld initialization
and per-cast deductions are unchanged. The inspected team's existing resource cap
is seven; the reported eight-point capacity has not been independently established,
and no new cap was invented. gameserver-go.next.exe compiled with this change.
It has not replaced the live Game server, whose last log still showed an active
Battle. The user explicitly said not to run more tests or ask for another gameplay
retry, and to continue the remaining work. Do not interrupt their active Battle
to deploy this staged binary.

## Aha Help follow-up, 2026-10-24

The user reported missing support in combat and a stuck web selector. Browser
inspection confirmed the open tab still ran the earlier JavaScript, and its
local static server was no longer listening. The existing local page service was
restarted, the tab reloaded, and its live Save Manager now shows enabled LV 1–3
options. The selector now explicitly shows `FreeSR (off)` when the legacy
`enable_invasion_support` is false; the API previously returned level null, and
no override had been saved. Aha Global is a separate passive setting.

The imported custom battle contains a Corruption buff matching the resource
invasion mapping, but the old support branch required ChallengeStageID. Support
selection now checks the outgoing battle's actual Corruption buffs after the
existing official-challenge injection. It does not inject Corruption from a
custom stage ID. Selecting a level removes other support levels before adding
one selected buff; explicit zero removes support for that Corruption battle.
Null follows the existing FreeSR switch. Selection is read afresh at battle
creation, and AHA_HELP diagnostics record the decision and sent IDs. Game and
SDK compiled and were restarted with visible consoles. The new web state is
confirmed; the user still needs to choose a level and verify the next battle.

## Current Client capture and staged work

### Client regression after deployment, 2026-10-24

After the user reopened the Client, its assembly hash was rechecked and a
bounded `AssetMgr.Exists` query checked all six captured prefab paths, without
loading them. Standard and novice returned true; all four limited character and
lightcone paths returned false. The research scripts were removed from scripts/
after capture. Evidence is retained in
`battle_diagnostics/gacha-asset-exists-20261024.log`. Standard is now the sole
verified browsable entry in the resource policy. It has no invented featured
avatar or prize list, and its draw request returns NOT_SUPPORT. Featured draws
remain unavailable pending real installed presentation assets. The rebuilt Game
server was restarted; actual Standard page entry/exit still awaits Client retry.

The user reported an empty Warp page followed by a black map on exit. Player.log
proves the captured Seele prefab is absent from the installed asset manifest
(`index=-1`), followed by `UIPrefabLoader._HandleLoadResult` ArgumentNullException
inside `GachaMainPage._create_pools_panel`. The earlier statement that two
captured paths represented usable banners was too strong: they are candidates,
not verified installed assets. Gacha entry now returns `RET_GACHA_NOT_SUPPORT`
when the resource policy has no verified banner prefab; DoGacha uses the same
verified set. No alternative prefab path or banner ID was invented.

The same log contains repeated ActiveActivity ItemFactory null references and
missing RaidCollection reward icons. Additional preview schedules are withheld
through their resource policy until each dependency is validated. Existing
non-preview schedules and saves were not changed. The guarded Game executable
was built and deployed; SDK was started with its visible console as well.
Recovering a Client already stuck in the failed UI transition requires a fresh
login. The user was asked to open the Client at the normal walking screen to
check available assets; no game process was present during this repair. Neither
safe rejection in the Client nor replacement banners have been verified yet.

The running Client was verified at runtime as a different assembly from the old
CW capture: SHA-256 `4aa08a0706f27d2cf9951b61920c179140ece9ea94f7e34422c18e46922939b6`.
The module path identified the user's current installation as 4.6.54. No old
native RVAs were reused against it. Exact named FromBinary methods, their flat
dictionary consumers, and bounded getters were traced and captured separately.
`PreviewGameplayCatalog.json` contains 6 gacha basic rows, 13 Parkour rows, 181
activity panels and 361 activity configurations. Original JSON number strings
were retained when exporting so 64-bit text hashes are not rounded.

Stella Jump is the side-view ChenLing GameBoy game, not Parkour. All 16 case rows
are retained in `StellaJumpConfig.json`. New handlers respond with a non-null
case payload, expose its configured challenge packs, and save actual best times
and submitted completions under a separate persistent key. No synthetic best
time is stored to unlock the menu. The request CmdID for RequireChenLingGameBoyData
was independently checked in current Client native code and matches the named
revision-tagged command table. The two cheat requests still have obfuscated table
names: ANDPLLAKCLE/CDJKLJDMJHO and EMDKLICDPKK/JHEHACPKKBL. Their case-ID and
case-ID/boolean shapes are mapped to the named Client sender methods; the exact
meaning of the extra response boolean still needs Client verification.

The gacha implementation now derives featured characters from actual captured
avatar-prefab basenames and returns that same character for each draw. The
captured basic table currently provides two character banners. This does not
establish support for a banner for every avatar. Sandbox draw counts/pricing and
duplicate handling are explicit resource policy. For the existing fully owned
roster, duplicate materials use the avatar's configured first Eidolon cost and
merge into the latest import under the common file lock. Rank, EX and Traces are
preserved. First-time acquisition for an avatar absent from the imported roster
is still rejected rather than constructing an incomplete avatar.

Activity preview policy currently exposes two captured panel types, minigames
and ActiveActivity, with their typed data callbacks. Mini-game scores are empty
unless provided by a dedicated subsystem; this does not claim full event gameplay.
ActiveActivity's module-ID to data-ID association is an initial mapping requiring
Client confirmation. Remaining event-specific actions/rewards are incomplete.

Aha's Help's loading bug was a frontend envelope mismatch: `/api/persistent`
returns `persistent`, but the page read `data` and returned before loading levels.
The level loader now runs independently, shows offline/API errors explicitly,
and reloads on a connection change. The actual API was observed returning LV 1–3.
The regression check exercises the real envelope, empty character cache, explicit
off and API failure; it passes. Frontend script/style cache keys were updated.

On 2026-10-24 the user explicitly authorized rebuilding and restarting both
servers. Both builds succeeded, previous root executables were backed up under
`.runtime/before-preview-*`, and the new root Game/SDK executables were started
with visible consoles. Both processes remained running and the SDK Aha endpoint
returned LV 1–3. Focused store tests for Aha, Stella Jump and duplicate gacha
grants pass. Client unlocks, event screens and gacha animations remain unverified.

## Implemented, awaiting Client verification

Aha's Help has a resource-backed level selector, independent persistent setting,
SDK endpoint and GaC-Srtool control. Values are from the user's supplied screenshot,
not a claim of a freshly captured Client table. Existing stage-invasion detection
gates the buff. Explicit off and resetting to the FreeSR setting are supported.
Reads do not write, and targeted writes preserve other persistent sections.

The focused persistence test passes, both executables compile, and srtool JavaScript
passes syntax checking. The broader common and SDK test packages pass. The game
server package has failures resolving resources in relic, scene and smoke tests;
there is no claim that the whole test suite passes or that Client gameplay works.

CW equipment Forge use and grants for Orb/consumable/Forge are implemented.
Automatic Orb drops, opening Orbs, consumable effects, Tea Break choices and full
later-room progression remain incomplete.

## Offline findings and remaining requests

- Reward comparison: 347 of 478 captured Client combination rows match the older
  reference by ID and both arrays. The reference has 372 combination rows and 966
  basic bonus rows; only 276 of 529 captured Orbs point directly to those basic
  rows. Do not promote the entire older reward table as current Client data.
- Stella Jump: all stages should be selectable and playable. No current stage
  catalog was located in this repository. Parkour request schemas exist, but that
  alone does not prove Stella Jump uses that subsystem or identify unlock fields.
- Activities: expose event pages and enough entry/data handlers for preview;
  complete reward/gameplay simulation was not requested. The current schedule
  handler deliberately exposes only Endgame/CW, and there is no generic event
  data implementation. Avoid publishing every ActivityConfig row with empty
  replies that leave the Client waiting.
- Gacha: one character per selectable banner, with each draw matching the displayed
  character. Current code hardcodes a standard banner and alternates unrelated
  result IDs. A matching Client banner-to-character table is still required;
  the older reference's Banners.json is not proof of current banner assets.
- Aha's Help: verify LV 1/2/3, off, legacy fallback, challenge-only application,
  and that changing the setting during battle affects the next battle only.

Keep all research probes outside scripts while the game is not being inspected.
No Client gameplay confirmation has been requested during this offline work.