46 lines
5.4 KiB
Markdown
46 lines
5.4 KiB
Markdown
# 交给评审AI：4B2修订2完整方案独立审查
|
||
|
||
你在 `C:/projects/ft` 工作。请审查**修订2**的设计完整性与可实现性，不实施代码。主会话已处理原初稿作者自审的15条意见，但没有批准编码；本次新增接口、扩大白名单及受控加载输出变化必须整体审查，不能只核对原P编号后宣布通过。
|
||
|
||
## 1. 职责及输出边界
|
||
|
||
- 首先披露是否参与原初稿或本修订的编写；参与本修订编写者不能把自审写成独立通过。原初稿作者继续审查时保留参与关系披露，不覆盖已有自审报告。
|
||
- 只新增 `CodexOutput/upserver/阶段4B2修订2方案独立审查-2026-09-23.md`。如果该文件已存在，保留它，新增带轮次后缀的报告。不修改方案、基线、原报告、共享入口、TODO、日志、生产或测试代码。
|
||
- 不使用子Agent，不访问正式服，不写业务KV，不打包。设计审查以只读为主；如确需Unity仅用CLI Loop，不能用UnitySkills。固定正式地址 `http://s101.local:18080/`，本轮不使用101/102历史fixture授权进行业务加载。
|
||
|
||
## 2. 必读及版本门
|
||
|
||
1. `阶段4B2方案受审基线-修订2-2026-09-23.json`：逐项重算SHA256；任何差异逐项说明，不把不同版本混在通过结论中。新增计划文件尚不存在不算缺失；基线只列本次实际存在文件。
|
||
2. `阶段4B2游戏加载与内存隔离方案-修订2-待评审-2026-09-23.md`。
|
||
3. `阶段4B2字段与模块加载合同-2026-09-23.md`，与主方案具有同等约束力。
|
||
4. `阶段4B2初稿审查裁决与修订说明-2026-09-23.md`、`阶段4B2方案独立审查-2026-09-23.md`及`阶段4B2方案作者自审补充-2026-09-23.md`，明确后两者的作者身份披露与初稿hash，不能当作修订2已通过。
|
||
5. 4B1关闭裁决、4B分期与4B1原方案、阶段4分期和存档调用盘点。
|
||
6. 主方案§9与附件§5全部相关源码，重点核对当前实际格式/字段/副作用，而不是仅阅读文档。
|
||
|
||
上述文档均位于 `CodexOutput/upserver/`，源码相对项目根路径在基线中。报告开头记录主方案、附件、裁决、提示词的完整hash，以及其他基线项目匹配数/漂移列表。
|
||
|
||
## 3. 必须给出结论的检查项
|
||
|
||
| 组 | 独立核查要求 |
|
||
|---|---|
|
||
| A 字段完整性 | 是否穷尽LoadPlayerData/LoadPlayerDataNew及其同步模块消费键；现代19槽/完整旧键/别名货币/内嵌旧格式/动态地图/紧凑战令与活动是否准确；缺失与坏值、表缺失与活动过期是否自洽；严格拒绝历史残档的兼容取舍是否明确 |
|
||
| B 业务内存 | 附件31组是否有遗漏字段或错误空态；同对象A→B缺键能否实现隔离；纯Decode/Reset/Replace是否仍触发GContext/事件/UI/奖励/异步业务；Poisoned后不能继续使用；禁止抽样替代整组 |
|
||
| C 会话拓扑 | 单次4B1认证及Lease发放原子性、active计数、撤销/排水/异常责任、CustomServerMgr版本隔离、Close→Lease→Bridge→session顺序是否会互等；新增接口是否破坏4B1已批准语义 |
|
||
| D 有界观察 | 10秒登录/gate、5秒Quit仅限制等待者；排水继续、超时获锁竞争/迟到Prepare不会Apply；跨Root Registry会否丢任务/保留Unity对象；失败锁屏不会被新实例/重建Root绕过 |
|
||
| E 副作用 | PlayFabMgr guard是否在缓存/队列/PlayerPrefs/网络之前，覆盖remote=false、立即、定时、暂停和销毁；直接SDK/Prefs路径是否真被纯入口排除；不能因guard命中后catch而仍算成功 |
|
||
| F 受控入口 | 公共kv/未知配置不能Done，Agg早退不旁路；能力仅Editor创建、缺替身拒绝；真实业务代码可测而不进入玩法；不将LoadedForValidation冒充游戏迁移完成 |
|
||
| G 意图/身份 | 最多2项意图、丢弃与未持久化语义、MMTest的PF新旧身份与S101 NewlyCreated区别、linkedAccout/EAccoutUrl清理、CleanupFailed/OriginalError双检查 |
|
||
| H 载体与范围 | HotUpdate内Host＋Editor固定反射是否可达，真实模块的依赖/静止容器/恢复是否可构造；Android条件分支离线与Unity证据边界；白名单是否覆盖必需类型且无任意扩围 |
|
||
| I PF回归 | 新backend/guard/401/注销分支是否保留PF原行为；原InitData位置与时间校准、TapJoy、AGG路径能否验证；不以生产hash不变替代修改后的行为回归 |
|
||
| J 阶段边界 | 本修订相对4B2原目标的受控入口与输出调整是否合理，是否暗中删掉必要游戏加载能力；4B3/4C等启用条件是否完整，是否应再拆审，但不能把未明确细节留到编码 |
|
||
|
||
## 4. 报告格式和判定
|
||
|
||
- 先写身份披露、受审版本、实际读取范围/实际执行的命令（未执行测试明确写未执行）。
|
||
- 分P1/P2/P3逐条给：编号、精确方案节/附件行、源码位置、可发生场景、影响、最小修订建议。
|
||
- 原15项逐条标记“设计层已响应/仍未闭合/新方案替换了原规则”，同时列新的问题；不要把文档响应当成实现验收。
|
||
- 对A～J各给可审性判断，并分别裁决4B1接口扩展、PlayFabMgr及模块扩围、公共kv禁止Done三项变化。
|
||
- 最终给“通过/有条件通过/退回”，逐项列编码前必须补齐内容。若方案仍有必要定义缺失，退回补齐，不授权实现者临时决定。
|
||
|
||
后续逐条裁决、实施批准和共享文档更新由主会话负责。审查者不代改共享状态，不自动开始代码开发。
|