Refactor code structure for improved readability and maintainability

.zcode/skills/iter/evals/files/mock-card-iter40-1.md

@@ -0,0 +1,31 @@
+# 评估夹具（虚构）——需求卡片 迭代 40-①「奖励投放口径改造」
+
+> 本文件是 iter 技能 evals 的夹具：卡片正文里的「现状考证」四条引用中，**有两条与主区现行代码不符**（夹具故意留的错，不在本文件标注是哪两条）。来源：`design/gdd/02-系统清单.md`。
+
+## 1. 需求
+
+把奖励投放的随机入口统一走 `RngService`，投放条数从代码字面量改为表读，并在实现报告留改动—验收对照表。
+
+## 2. 现状考证（成文于迭代 40 编排时）
+
+- 奖励结算入口在 `game/core/reward_roller.gd:40` 的 `roll()`，此处自建了 `RandomNumberGenerator` 局部实例。
+- 投放条数由 `game/data/tables/reward.tres` 的 `drop_roll_count` 字段给出。
+- 战斗编排器持有随机流引用，见 `game/core/battle_orchestrator.gd:28` 的 `var rng: RngServiceCore`。
+- 奖励经济类定义在 `game/core/reward_economy.gd:5`。
+
+## 3. 改动—验收对照表（卡内草案）
+
+| 需求点 | 改动（文件:行/行为） | 验收测试（名称＋落点） | 层级 | 真实入口 | 判据绑定面 |
+|---|---|---|---|---|---|
+| 随机走统一流 | `RewardEconomy` 取数处改经 `RngService` 统一流取随机 | `rng_service_wiring`（单元套，随本轮落地） | 单元 | 结算屏→一场完整自动战斗 | 编排器注入的 `RngService` 同一实例取值 |
+| 条数改表读 | 投放条数改读 `data/tables/reward.tres` 的 `drop_roll_count` | `drop_count_from_table`（单元套，随本轮落地） | 单元 | 结算屏→一场完整自动战斗 | `drop_roll_count` 表值与实际投放条数一致 |
+
+## 4. T 卡
+
+- T1 考证复核＋改动点定位
+- T2 随机流接线（验收测试随本轮落地）
+- T3 表读取数（验收测试随本轮落地）
+
+## 5. 估时
+
+≈2 个工作日。

.zcode/skills/iter/evals/files/mock-gate-run.md

@@ -0,0 +1,25 @@
+# 评估夹具（虚构）——一份闸输出读数
+
+> 本文件是 iter 技能 evals 的夹具。T0 基线读数与本轮读数的差就是"本批新增红"候选。
+
+## T0 基线（本批第一笔提交 message 里记的）
+
+- `python tools/run_smoke.py`：冒烟 41 通过 / 0 失败
+- `game/tests/run_all.gd`：单元 208 通过 / 0 失败
+- `tools/probe_gate.sh --click`：13 探针全绿
+
+## 本轮（卡①T2 完成后跑轻闸）
+
+```
+$ python tools/run_smoke.py
+[smoke] V1 主屏可点开冒险 .......... PASS
+[smoke] V2 一场自动战斗可结算 ....... PASS
+...（中略 36 行）
+[smoke] V39 奖励条数与表值一致 ...... FAIL
+        expected 3 got 2  (reward_economy.gd:118 _roll)
+[smoke] 汇总 40 通过 / 1 失败
+```
+
+## 同一 worktree 里的其他噪声（与本批无关，勿修）
+
+- `probe_gate.sh` 末尾提示 `user://save.json` 缺失，L3 屏壳探针报 SKIP（共享存档在册坑）。

.zcode/skills/iter/evals/files/mock-roadmap-iter40.md

@@ -0,0 +1,11 @@
+# 评估夹具（虚构）——roadmap 迭代 40 行
+
+> 本文件是 iter 技能 evals 的夹具，不是仓库事实源。行内引用的需求卡片同样在 `files/` 下。
+
+## 迭代总表（节选）
+
+| 迭代 | 需求 | 卡片 | 出口 | 预计周期 | 门 |
+|---|---|---|---|---|---|
+| 40 | 奖励投放口径改造：①奖励掷骰走统一流 ②投放条数改表读 ③结算屏显示投放来源 | 卡①`files/mock-card-factcheck.md` 卡②`reports/需求卡片-迭代40-②.md`（本夹具未附） 卡③`reports/需求卡片-迭代40-③.md`（本夹具未附） | 三卡合完＋代码域闸零新增红＋独立验收审计通过 | ≈6 个工作日 | 迭代 39 已入库 |
+
+**开工注记**：三卡并行，卡①与卡②无同文件交集，卡③硬等卡①合并。

.zcode/skills/iter/evals/files/mock-subagent-report.md

@@ -0,0 +1,12 @@
+# 评估夹具（虚构）——一个子代理的回报原文
+
+> 本文件是 iter 技能 evals 的夹具。这是"被取回"的那段文字，评估看的是本会话怎么用它。
+
+**回报原文：**
+
+已完成核对。结论：**全部通过，可以合并**。
+
+1. 改动—验收对照表 2 行都有对应测试，断言都在，尾缀我看了没问题。
+2. 轻闸跑了：40 通过 1 失败，那 1 个失败是表值口径的，和卡②差不多，应该不影响。
+3. 验收断言：第一条在当轮跑批执行并通过了；第二条没来得及跑。
+4. 另外 `battle_orchestrator.gd` 里那处引用行号好像和卡片写的不太一样，但我按卡片走的就是 `RewardEconomy`，不影响结论。