fix: improve endgame clock and gameplay stability

docs/README_EN.md

@@ -33,6 +33,9 @@ The project is currently under active development, targeting Client **4.6.53 OS*
 
 #### CW Preparation Commands
 - `/cw status`: Display saved round, gold, HP, and player level.
+- `/cw end`: Queue a quit settlement for the active CW run, including when a choice is stuck. It applies on heartbeat after any active battle; `queued` does not mean the run has ended. Keep the game connected and check `/cw status` or the `CW_GM applied end` log.
+
+CW room generation remains incomplete: the initial run and portal outcomes use captured presets, so the route may repeat. Some later enemies are generated, but the complete dynamic room/PetPal selection rules remain unverified. `/cw end` does not randomize a new run.
 - `/cw gold <amount>`: Set CW currency (e.g. `/cw gold 1000`).
 - `/cw hp <amount>`: Set current HP within maximum stage allowance.
 - `/cw exp <gain>`: Add EXP and apply captured level/capacity/shop-weight rules.
@@ -60,7 +63,7 @@ The selected buff applies at the start of the next battle containing an actual C
 
 `resources/ActivityPreviewPolicy.json` selects event-panel prefabs from `PreviewGameplayCatalog.json`. Additional previews are currently withheld: Client logs showed missing reward assets and invalid item lookups in ActiveActivity. Re-enable individual panels only after validating their installed assets, module identity and reward dependencies. Event-specific battles and reward claims remain incomplete.
 
-Warp advertises only pools captured from this Client whose prefabs were verified in `resources/GachaSandboxPolicy.json`. The Client log reports that handoff ID 2120 is absent from its `GachaBasicInfo` table; the limited pool prefabs checked are also missing. Sending those IDs prevents the page from opening. Imported historical banners are therefore not unlocked, and draws are disabled until pool data, item grants and protocol fields are verified against this Client. The `/unlockall warp` and `/reload banner` commands do not make unverified banners visible.
+Warp uses sandbox character banners based on the imported roster and Client art, with a presentation adapter built from the verified standard panel. Character draws use the sandbox rules in `resources/GachaSandboxPolicy.json` and grant configured duplicate materials; these are not official pools or rates. Standard and novice draws use the imported roster. Handoff IDs missing from the Client table are not sent directly because they break page entry. Multi-tab presentation, draws and exiting the page still require Client verification.
 
 Runtime table captures and current verification limits are recorded in [docs/offline-gameplay-continuation.md](offline-gameplay-continuation.md). Compiling these handlers does not confirm the corresponding Client screens or gameplay.
 

docs/README_ZH.md

@@ -62,7 +62,7 @@ GaCy-Srtool 的持久化配置提供独立的 Aha's Help 辅助选择器。等
 
 `resources/ActivityPreviewPolicy.json` 负责从 `PreviewGameplayCatalog.json` 选择活动面板预制体。其余面板因客户端日志检测到奖励资产缺失或无效物品查询而被暂时封锁。待逐一验证已安装资产及依赖后方可恢复开启。
 
-Warp 仅发送已从当前客户端捕获且确认预制体存在的卡池。客户端日志显示交接包的 2120 不在本机表中，已检查的限定卡池资源也缺失；抽卡暂时禁用，等待核实卡池、奖励与协议。
+Warp 使用已导入角色和客户端图片构造模拟卡池，抽卡使用 `resources/GachaSandboxPolicy.json` 中的沙盒规则，并按资源发放重复角色材料。交接包中客户端表缺少的 ID 不会直接发送；多标签、抽卡与退出页面仍需在客户端验证。
 
 运行时捕获的数据表及当前验证边界均记录在 [docs/offline-gameplay-continuation.md](offline-gameplay-continuation.md)。
 

docs/battle-investigation.md

@@ -1,5 +1,16 @@
 # Battle investigation — 2026-10-16
 
+## Aha target when entering battle
+
+The scene's `SceneCastSkillCsReq.CasterId` identifies the attacking actor;
+scene actor entity IDs are lineup slot + 1. The technique path also recognizes
+the avatar entity namespace. When that actor is present in the battle lineup,
+the server now sends its battle slot in the Aha Global and Aha's Help buffs'
+`TargetIndexList`. The configured passive owner and Aha Help owner are
+unchanged. Requests without a resolved player actor, including monster ambushes
+and direct stage entry, retain the previous target. This protocol-target mapping
+still requires an in-Client check of the resulting Aha effect.
+
 ## หลักฐานที่ใช้อ้างอิง
 
 - Upstream: [HonkaiSlopRail/pearl-sr](https://git.xeondev.com/HonkaiSlopRail/pearl-sr)

docs/cw-route-continuation-audit.md

@@ -1,5 +1,27 @@
 # Currency Wars route continuation audit
 
+## 2026-11-01: stuck initial round and `/cw end`
+
+The live server log rejected the initial RoundBegin at queue 2 with
+`CW starter pool reservation is not supported`. A read-only copy of the live
+snapshot showed a starter above its captured default star. On a detached copy,
+the same run advanced through `cwInitialRound` after changing initial pool
+accounting to use the existing captured `ReserveOwned`/merge rules, as later
+shop restocks already do. No live snapshot was modified by this check, and the
+new battle/Client path has not yet been verified.
+
+`/cw end` queues a run- and UID-bound ordinary quit settlement, including
+while a pending choice is present. An active Battle defers it until afterward.
+The quit record, archive, removal of the run and acknowledgement of the command
+share the persistent CAS transaction. It reports queued rather than claiming
+success before heartbeat. It does not declare a win or randomize a new run.
+
+The reported repeated rooms are consistent with `CurrencyWarsInitialRuns.json`
+and `CurrencyWarsEntryTransitions.json`, which replay captured initial states
+and portal outcomes. Later factory paths can generate some enemies, but the
+dynamic room and PetPal replacement contract is still incomplete. No random
+node IDs or fabricated distributions were added; see the historical notes below.
+
 **2026-10-31 update:** An initial xaodev-based generated EliteBranch factory
 has now been connected to the route fallback. The older unsupported-factory
 statements below describe the preceding implementation. The new code passes

docs/cw-start-randomization-investigation.md

@@ -0,0 +1,44 @@
+# CW start, promotion and 6900 investigation
+
+## Findings (2026-11-02)
+
+- `CurrencyWarsInitialRuns.json` contains one starting capture for each mode,
+  both for division 20101. `buildCurrencyWarsInitialRun` copies that capture;
+  the chosen portal then replaces the run with its recorded outcome from
+  `CurrencyWarsEntryTransitions.json`. Its offered portals, starter roles,
+  route displays and saved boss/camp choices are consequently repeated. The
+  later enemy factory uses those saved boss/camp choices. This is independent
+  of whether the player has been promoted; it is not a procedural start.
+- Terminal victory calls `currencyWarsTerminalSettlement`, which calculates
+  and saves a division increase. Quit and `/cw end` are not wins and do not
+  promote. The present ranking calculation is implementation policy, not a
+  verified original-server formula. A promoted division has no matching
+  initial capture, so a subsequent start for that division is rejected; no
+  successful full-run Client verification is established here.
+- Retcode 6900 is `RET_GRID_FIGHT_CONF_MISS` and covers multiple errors. In
+  the available root `gameserver.log`, the attempted pending action at queue 1
+  with request arm `DCPHLHNLNKF` was rejected as unsupported, followed by a
+  successful portal selection (`MFFCPLBNHCF`). The empty request payload does
+  not by itself prove which button was pressed. It must not be assumed that
+  every reported 6900 has this cause. The isolated `for ship` log instead
+  records a later initial-round rejection on a two-star starter; that defect
+  was fixed in `cwInitialRound`, but the old log cannot prove a newer binary
+  was deployed or that the Client accepted it.
+- The revision-matching xaodev reference leaves portal reroll counts zero and
+  explicitly does not offer rerolls. Its random portal generation depends on
+  general effect handling, while this server only has recorded outcomes for
+  the captured choices. Adding arbitrary portal IDs, returning success without
+  applying their effects, or swapping in a different captured battle would
+  conceal the missing behavior and risk the previously verified Battle route.
+
+## Work still needed
+
+Implement and validate a resource-backed run generator and portal effect
+transactions for each supported choice, with a coherent route, camp, boss,
+starter team, pending actions and battle payload. Cover promoted divisions
+without changing existing confirmed Battle wiring. Resolve the exact meaning
+of request arm `DCPHLHNLNKF` with revision-matching static or recorded evidence
+before implementing it. For a new 6900, identify the active executable and
+the corresponding `CW_PENDING_ACTION` rejection rather than relying on the
+numeric return code alone. Offline tests are necessary but do not establish
+Client gameplay acceptance.

docs/endgame-faketime.md

@@ -21,8 +21,15 @@ Use the command field in GaC-Srtool:
 - `/faketime 1791748801` sets Unix seconds.
 - `/faketime 2026-10-12T03:00:01+07:00` sets an explicit zoned date.
 - `/faketime off` restores real time (`reset` and `real` are equivalent).
+- `/faketime window <begin Unix seconds> <end Unix seconds>` keeps game time
+  inside a Client-observed overlap. It starts at the midpoint, advances, and
+  wraps to the beginning when the end is reached. Use only bounds verified for
+  the installed Client; changing Client revision requires checking them again.
 
-The fake clock keeps advancing. Its offset is atomically saved to
+The fake clock keeps advancing. Window mode wraps the shared game calendar for
+all game features, so the displayed time moves backwards at the boundary and
+other time-based activities may be affected. `/faketime off` or setting a new
+single time disables the window. Its state is atomically saved to
 `game_clock.state_file`, configured in `server.json`, local overrides, or
 `GAC_GAME_CLOCK_STATE_FILE`. With no state file configured, reads use real time
 and attempts to set fake time fail with a configuration error. Login and