ft/CodexOutput/upserver/其他AI审查提示词-4B2修订2方案-2026-09-23.md

交给评审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三项变化。
• 最终给“通过/有条件通过/退回”，逐项列编码前必须补齐内容。若方案仍有必要定义缺失，退回补齐，不授权实现者临时决定。

后续逐条裁决、实施批准和共享文档更新由主会话负责。审查者不代改共享状态，不自动开始代码开发。