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

Offline continuation and acceptance requirements

Latest handoff: 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. 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.