6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
75 lines
3.9 KiB
Markdown
75 lines
3.9 KiB
Markdown
# M2 CP3A独立实施复核
|
||
|
||
日期：2026-09-29。审查者：ZCode会话（M2全链审查者）。本轮只读＋hash重算＋源码核对＋**独立复跑**；未修改生产/测试源码/共享文档。
|
||
|
||
## 受审hash核对
|
||
|
||
`M2-CP3A-C11交付hash.json`：**10/10全部一致**；清单SHA256 `2E3E1EB14807709E…`与交付记录吻合。
|
||
|
||
## 总裁决
|
||
|
||
**通过（限定）。CP3A可限定关闭**（主会话裁决后）——两项限制保留：①真实Player编译未验（CP2A连带），②Editor直开真实启动验收未运行。
|
||
|
||
## 独立复跑
|
||
|
||
| 项目 | 交付记录 | 本复跑 | 退出码 |
|
||
|---|---|---|---|
|
||
| KVGameLoadTests | 89组/1962断言 | **89组/1964断言/0失败**（+2断言为CP3A新增覆盖） | 0 |
|
||
| B02RouteTests | — | **1组/61断言/0失败** | 0 |
|
||
|
||
## 逐项审查
|
||
|
||
### 1. 原handle/epoch/三原实例一致性：确认
|
||
|
||
交付§1.1：GameLoaded→同epoch核验→**现有**Setting/Club/Notification原实例预检→一次绑定——与CP3A方案§3.2一致。交付§1.2部分失败沿Coordinator撤销，同进程不重绑——与方案§3.2"部分失败撤销＋拒绝重登"一致。
|
||
|
||
### 2. 未绑定时PF失败关闭：确认
|
||
|
||
交付§1.2：Setting/Club正式KV无句柄期间对两键失败关闭，不触发PF——与方案§3.1"无句柄实例报可诊断错误，不调PlayFabMgr.Instance"一致。
|
||
|
||
### 3. 部分失败撤销与重登限制：确认
|
||
|
||
合成用例28断言覆盖部分绑定撤销＋跨epoch拒绝——V05场景覆盖。
|
||
|
||
### 4. 通知在途与B01语义：确认
|
||
|
||
交付§1.2：通知保持已初始化原实例、绑定前检查初始化/授权在途、恢复后核固定Setting——与方案§3.2/3.3一致。两键B01语义（缺键/已存在值/Accepted/不确定/陈旧Owner）保持。
|
||
|
||
### 5. Editor直开PF补审实现：确认符合单文件边界
|
||
|
||
交付§1.3：`InternalEditorBoost.Init()`在服务注册前取冻结选择→缺选仅精确`playfab`注册→已有沿用→KV/未知拒绝——与批准补审方案精确一致。§3.4纯Editor测试改用显式PF测试构造——合理（不依赖启动容器）。
|
||
|
||
### 6. 闲置实现检查：确认无闲置
|
||
|
||
CP1三接口（TryAcquireGameHandle/TryGetCurrentGameHandle/LoadForGameAsync）在UserService.KVLoad.cs中有真实消费者（本审查grep确认）——无闲置。CP3A新增的绑定方法在UserService.KVLoad.cs中有真实调用——无闲置。
|
||
|
||
### 7. 测试证据可证明什么与未验证限制
|
||
|
||
**已证明**（合成/Editor层）：
|
||
- 未绑定拒绝、同handle幂等、通知在途预检、部分绑定撤销、跨epoch拒绝（28断言）
|
||
- 全量加载89组含CP3A场景
|
||
- 旧B01/路由/M14/31模块回归
|
||
- Unity Editor编译0错误
|
||
- LoginStage不进FishingStage（静态核）
|
||
- 正式101/102请求0
|
||
|
||
**未证明（如实保留）**：
|
||
- **真实Player脚本编译**——CLI Loop Restricted拒绝
|
||
- **Editor直开真实启动**——`InternalEditorBoost`的真实Boost()调用未运行（仅源码＋编译＋受影响合成回归）
|
||
|
||
### 8. Editor直开验收是否可凭当前证据限定接受
|
||
|
||
**可以限定接受。** 理由：
|
||
- 该补审改动仅SubBoostrap.cs的Init()内注册一段冻结选择——逻辑简单（条件注册/不覆盖/拒绝KV）
|
||
- 已有受影响合成回归（两处解码测试改用显式PF构造后通过）验证了Club构造路径
|
||
- Editor直开是**开发调试路径**非正式运行路径——风险远低于正式Player构建
|
||
- 如需补验收，建议方法：在Unity CLI Loop Editor中用`execute-dynamic-code`直接调用`InternalEditorBoost.Boost()`并检查容器中PlayerKVRuntimeSelection存在——**无需Play/打包/不污染正常容器**（Boost自身创建独立容器上下文）
|
||
|
||
## P3
|
||
|
||
- **P3-1**：建议后续CP2B/CP3实施时一次性补Editor直开Boost()验证（方法如上），连同Player编译一起关闭CP2A/CP3A的Player验证缺口。
|
||
|
||
## 结论
|
||
|
||
**通过CP3A限定关闭。** 两项限制保留（Player编译/直开验收）由后续统一关闭。CP2B首场景为下一步。
|