任务与协作
T003审查T003 审查意见
- 审查人：总策划
- 日期：2026-10-21
- 结论：通过，附 3 项修改。P0 平台层可以立即开工；R1 到 R3 要在方案 v0.2 中改完，最迟在 P2 开工前完成。
总评
质量很高。7 项验收标准全部达到，待验证项标注得很诚实，故障隔离"做不到的部分"也如实写了。以下设计我特别认可，要求实现时保持不变：
- 幂等键由业务事实决定，而不是随机号（4.2）。这是整套防重复发放的核心。
- 金币和点券卡在 GRANTING 状态时进入人工队列，不自动重发。宁可多核对一笔，也不重复发放。
- 网易模块做成独立 jar；回调由独立服务接收，不在游戏进程里开放公网端口。
- 编年史的匿名处理放在读取时判断，玩家随时可以切换。
- 云副本"混淆对象禁止调用"的边界守得很严。
必须修改
| 编号 | 位置 | 问题 | 要求 |
|---|---|---|---|
| R1 | 1.2 worldclock、2.3 chronicle_event、6.1 |
规则已过时。方案写的是"每个游戏日的随机特性、满月大事件"，但交付前一天已经改定为 I32：每日事件按现实日刷新，每周六一次大事件。月相只作为稀有生物等内容的出现条件 | worldclock 改为：现实日事件调度（刷新时刻和每日重启对齐）、每周六大事件调度、事件池防连续重复、游戏内时间与月相作为条件服务。编年史事件增加"纪元内第几周"字段；game_day 和 moon_phase 保留，作为附带信息 |
| R2 | 5.4 冒险世界重置 | 漏了离线玩家。关服前把在线玩家送回主城这一步没问题，但前一天就在冒险世界里下线的玩家，存档位置还在冒险世界。重置后他再上线，会落在旧坐标上。种子虽然没变，但玩家挖过的地形已经恢复，人可能卡进方块里窒息 | 玩家进服时检查：上次所在的世界是冒险世界，并且世界代号已经变了，就送回主城（或者送到冒险世界的出生点，策划倾向送回主城），同时提示"冒险世界已经刷新"。back 点按现有设计一起作废 |
| R3 | 2.1 存储选型 | 计划是首发用 SQLite，网站上线前再迁移到 MySQL。这样就要在运营中迁移账本和货币数据，风险最高的一次操作被放在了最不该出事的时候 | 正式服开服就用 MySQL。开发和测试服可以继续用 SQLite，双方言和双测试照常保留。100 人规模下 MySQL 的运维成本可以接受，网站也能直接用。停服迁移工具仍然要做，作为备用 |
对回报里"问题与建议"的答复
| 编号 | 答复 |
|---|---|
| 1 网易 UUID（V1） | 同意，已加入用户要问网易的问题清单。在得到答复前，profile 模块预留"内部玩家 ID"这一层，所有模块统一使用内部 ID。即使答复是 UUID 固定，这层也只是一一映射，成本很低；如果不固定，就不用返工 |
| 2 副本奖励 | 采纳研发建议，定为规则：高价值奖励一律由 AcornCore 监听 Clear 事件，经账本发放；end.yml 的 rewards 只放低价值物品，或者不放；门票退还仍然交给云副本。用户填副本配置的模板按此编写 |
| 3 高价值清单 | 已写入 D003 第七节"账本范围" |
| 4 强杀测试 | 采纳，已加进 T006 |
| 5 金币取整 | 确认：金币一律用整数，不设小数。神奇橡果本身就是整数 |
| 6 迁移 MySQL | 见 R3，改为开服即用 MySQL |
| 7 占位符写法 | 采纳。D002 已注明 {item} 和 <item> 写法等价，代码统一使用 MiniMessage 的 <item> |
| 8 git 仓库 | 同意。在 研发/AcornCore/ 初始化仓库；闭源 jar 放在 libs/，授权文件不纳入版本管理。云系列的 jar 由用户购买后提供 |
| 9 补抓知识库 | 同意，第二批开工前完成。由用户交给负责知识库的 GPT |
| 10 P0 开工 | 批准，见 T007 |