# M2正式接线依赖独立复审（修订2）

日期：2026-09-29。审查者：ZCode会话（M2修订1审查者）。本轮只读＋hash重算＋源码核对；未修改任何生产/测试源码/共享文档/历史报告。

## 受审hash核对

`M2-正式接线依赖受审基线-修订2.json`：**19/19重算全部一致**。

## 总裁决

| 对象 | 结论 |
|---|---|
| **CP1限定实施白名单** | **通过**（可批准编码） |
| **CP2前置设计盘点** | **通过**（五类阻断准确完整） |

无P1；P2一条；P3一条。

## 主会话新增事实复核

本审查独立核证全部四项：

| 事实 | 源码证据 | 对修订1判断的影响 |
|---|---|---|
| 普通启动无条件创建PF组件 | `SubBoostrap.cs:91 AddComponent<PlayFabMgr>()` | ✓ CP1不能要求"PF未启动"同时又沿用普通启动 |
| `kv`配置被拒 | `UserService.KVLoad.cs:17-23` `BackendNotEnabled` | ✓ 正式登录路径完全未接通 |
| 账号租约仅验证路由 | `CustomServerMgr.cs:45/53/65` `kvOnly`＋仅两条验证路径 | ✓ 正式业务API借用被阻断 |
| Bindings仅Editor | `PlayerKVGameplayBindings.cs:1` `#if UNITY_EDITOR && !SERVICE_HOST` | ✓ Player构建无31模块绑定 |

**对修订1"30–50行"判断的修正**：我当时的估算仅覆盖Coordinator内的Guard释放/handle交接——主会话指出的五类启动/认证/工厂/绑定/路由阻断确实不在其中。**修订2正确识别了"加载→释放→交接"（CP1）与"正式接线"（CP2）是两个不同系统边界**——这一拆分使CP1可在合成环境独立验证而不需先解决全部启动问题。

## CP1限定实施白名单裁决：通过

### 三个internal签名审查

**1. `PlayerKVLoginContext.TryAcquireGameHandle(long expectedEpoch, out handle)`**
- 条件链（prepared/未closing/未revoked/IsCurrent/epoch匹配）→返回现存原对象——**不创建新Owner、不公开Cookie**——正确；
- "取得句柄不代表公布可写状态，最终发布由协调器做"——两步交接（Context给→Coordinator发布）——**防止中间态泄漏**。

**2. `Coordinator.LoadForGameAsync(id, capability, token, identityCurrent)`**
- **共用现有Prepare/Decode/Apply主体，不复制200行**——满足用户最小代码要求；
- 成功时序：`Apply返回None→notify完成→epoch/context/Violations复核→取得原handle→释放Guard→发布GameLoaded`——精确且与Editor已验证时序一致（Apply后释放）；
- "失败继续原Revoke/Close；不得仅使KVMgr忽略Guard"——**不绕Guard**——正确。

**3. `Coordinator.TryGetCurrentGameHandle(epoch, out handle)`**
- 仅正式成功＋Guard已释放才返回——防止加载期间外泄；
- `Revoke`同步清除引用先于关闭排水——正确顺序。

### Guard/KVMgr保持原样

§2.4明确"Guard.cs及KVMgr.cs四入口方法体原样保持"——与用户"现阶段不动Guard"一致。

### 白名单精确

仅`PlayerKVLoginContext.cs`＋`PlayerKVGameLoadCoordinator.cs`＋合成测试宿主——**3个文件的改动面**，远小于此前任何批次。

### 并发测试覆盖

"Guard释放/状态发布/Revoke并发锁顺序列入实施测试，不在锁内await"——覆盖了关键竞争。

### CP1不会成为弃用代码

CP1的三个接口在CP2中**必须实际使用**（§1"若CP2评审认为不适用，应在合并前删掉"）——正确的防废措施。具体而言：
- `TryAcquireGameHandle`→CP2的正式登录完成后获取句柄
- `LoadForGameAsync`→CP2的正式加载入口
- `TryGetCurrentGameHandle`→CP2的业务操作获取可写句柄

**P2-1**：建议主会话裁决时将"CP1接口在CP2中的实际消费点"列表（3个接口各自被CP2的哪个具体场景调用），作为CP2设计的输入——使CP1→CP2的接口衔接在设计阶段即有闭环。

## CP2前置设计盘点裁决：通过

五类阻断（§3表格）全部源码核实属实，每类的"CP2所需设计证据"完整：

| 类别 | 阻断 | CP2设计要求 | 完整性 |
|---|---|---|---|
| 启动 | AddComponent无条件创建 | backend分流创建 | ✓ |
| 认证 | kv被拒/登录PF先行 | KV分支单S101认证/错误码/IsLogin | ✓ |
| 工厂 | 仅Editor验证工厂 | 正式工厂（API/Cookie/handler/CacheRoot） | ✓ |
| 绑定 | Bindings仅Editor | 提升Bind进Player编译/逐模块核注册 | ✓ |
| 网络 | 租约仅验证路由 | 单会话租约承接正式API/按域白名单 | ✓ |

**"CP2范围显著超过修订1估计的30–50行"**——本审查接受此修正。

## P2/P3落实检查

| 项 | 主会话裁决 | 修订2落实 | 判断 |
|---|---|---|---|
| P2-1（5项签名） | CP1条件不足 | §2三签名精确给出 | ✓ 落实 |
| P3-1（Guard映射） | 20处/5文件核证 | §4记录，不随CP1移动 | ✓ 落实（20处方法调用vs旧报告21处引用——计数口径差异已解释） |
| P3-2（PF触发差异） | CP3各域记录 | §4 CP4停用前对账 | ✓ 落实 |
| P3-3（Player编译） | 历史错误单列 | §4 CP1"未声称Player通过"＋CP2要求0错误 | ✓ 落实 |

## P3清单

- **P3-1**：如上述P2-1建议——CP2设计时列表CP1三接口的消费点，确保接口闭环。

## 结论

**CP1通过（可批准编码）。CP2前置设计通过（待完整设计审查后实施）。** 主会话核hash（已代验19/19）裁决后：
1. 按CP1白名单实施（LoginContext＋Coordinator＋合成测试）；
2. CP1批末独立实施复核；
3. 并行准备CP2完整设计（正式启动/认证/工厂/绑定/路由五类）。