4.2 KiB
阶段4B2修订2审查裁决与实施批准
日期：2026-09-23。检查点0。用户明确要求核对基线、逐条裁决并批准修订2实施，按§9检查点0–4推进。
1. 受审版本和结论
主会话19:28 +08:00逐项重算《阶段4B2方案受审基线-修订2-2026-09-23.json》123项SHA256，全部匹配，无漂移。修订2审查报告为通过、无P1、2项P2确认项和5项P3。审查者披露参与原初稿、未参与修订2及附件编写；用户本轮明确指定对该报告裁决并实施，因此接受其作为本轮外部审查，不再重复索取审查。
接受A–J及三项变更的设计通过结论：单认证Lease/元数据/Close扩展、PlayFabMgr与模块纯入口扩围、公共kv禁止Done。原15项设计响应已闭合，不能等同代码验收。原受审主方案、附件、基线和审查原文保持不变，本文件为后续裁决覆盖层。
2. P2逐条裁决
| 编号 | 裁决和实施边界 |
|---|---|
| P2-α | 采纳，升级为正式启用前硬前置：存量真实PF档兼容性盘点、版本/字段识别、迁移/备份/失败退出/人工恢复方案、独立评审及用户产品确认必须先完成。4B2只用合成档验证既定严格规则，不读取/迁移真实存档，不把MissingCore直接用于真实玩家入口。用户本轮授权推进受控实施，不等同已批准未来真实档拒绝/迁移政策；4B3/4D/G4不能绕过此前置。 |
| P2-β | 采纳。保存当前ClubService基线副本和hash；实施M14时仅三处加载态及纯方法，单列相对本轮基线的最小diff说明，不把既有未提交改动纳入本轮成果，不回退旧改动。 |
3. 五条P3逐条裁决
| 编号 | 裁决 |
|---|---|
| P3-1 Editor恢复 | 采纳顶层try/catch/finally与幂等恢复；待后台排水时仍维持隔离、不提前归还GContext。仅承诺可捕获异常的恢复；进程崩溃/强制终止无法靠catch保证，记录需重启编辑器，不假称绝对恢复。 |
| P3-2 M05默认值 | 采纳；InitWheelTicket必须来自同一捕获表快照，测试检查快照标识及数值，不重新读取全局表。 |
| P3-3 配置错误码 | 明确归Input；只有等待gate取得权限超时才GateBusy。超时观察配置范围1000–15000，不合法则零认证、零Apply。 |
| P3-4 codec证据 | 采纳按M01–M31分组输出，每个codec含正/反/缺键及同对象隔离；模块组不能替代具体用例和字段断言。 |
| P3-5 32条诊断 | 首32条按模块ID和字段登记顺序保留；全部错误继续按模块/错误码计数，输出TotalErrors及OmittedDetails=TotalErrors-Details.Count，不重复计数、不输出被截断值。 |
4. 实施批准与顺序
批准修订2主方案§9及附件§5白名单内实施，受本文件裁决约束。检查点1 Lease/Registry及4B1原23组全量回归先行，再做字段/模块、编排/防写、Unity受控验证及完整回归。每检查点记录实际范围、失败、修正、命令/退出码和未完成项。
构建文件组织选择：原KVLoginContextTests显式链接Context.cs，旧测试csproj禁止变更；依主方案§9“新增类若组合在上述文件中不扩职责”许可，将Context直接依赖的Lease/只读认证描述及受控能力类型组合在PlayerKVLoginContext.cs内，使既有23组原宿主无需改项目即可编译。Registry保留单独新文件，新测试只放KVGameLoadTests目录。该选择不引入额外公开面/新行为，不以复制原测试或绕过原宿主代替全量回归。
新租约不得对玩家构建提供创建入口；替身创建能力仅UNITY_EDITOR编译（离线新宿主显式定义该符号）。真正网络默认工厂不能冒充受控替身。旧4B1公开API、结果类型、首token/历史Task/Volatile发布合同保持，context源码变化按4B2新hash验收。
4B2批准实施不代表4B2关闭，也不批准4B3、实际玩法启用、真实存档迁移、正式服访问或打包。固定地址http://s101.local:18080/；只用Unity CLI Loop，不使用UnitySkills。