# M2 CP3A独立方案审查（含CP2A增量实施意见）

日期：2026-09-29。审查者：ZCode会话。本轮只读＋hash重算＋源码核对；未修改生产/测试源码/共享文档/方案/manifest。

## 受审hash核对

| 清单 | 结果 |
|---|---|
| CP2A-C15补审后交付（20项） | **20/20全部一致** |
| CP3A受审基线（18项） | **18/18全部一致** |

---

## 第一部分：CP2A补审增量实施意见

`_cheatingScore`修复经源码核实：
- `FishingChallengeManager.cs:70–74`：`ResetForKVLoad()`中`_cheatingScore=0`已单独置于`#if UNITY_EDITOR`——与批准的单文件补审方案精确一致
- 其余字段赋零在所有目标执行——原语义保持

**CP2A增量实施通过。** Player真实编译未取得（CLI Loop动态Player编译被Restricted规则拒绝）——CP2A保持未关闭，此状态准确。

---

## 第二部分：CP3A前审结论

**通过。** 无P1/P2；P3三条不阻塞。可批准CP3A实施（主会话裁决后）。

### 方案核心评估

CP3A的正确性在于**最小正确切口**：只把CP2A交接的原handle送达两个已有B01验证的服务实例（SettingService＋ClubService），不做其他任何扩展。这比"全面替换容器"或"新建全局路由"的方案风险低几个数量级。

**同实例绑定设计**（§2.4）是本方案的关键正确决策：登录前SubBoostrap已注册/初始化这些服务→不能替换实例（会留旧引用）→只能在**已有实例上单次绑定原handle。失败关闭，不回退PF，同进程不许重登。这是唯一安全的方式。

### 四问逐答（§6要求）

**Q1：LocalNotificationService原实例绑定？**
**可以。**通知服务在登录前Init——沿用已初始化实例是正确选择（不重复请求系统权限/注册事件）。在途权限回调的竞态屏障：
- 方案§3.3已要求"回调必须同时验证原Setting实例和其原句柄"
- V03覆盖"在途回调不能跨绑定"
- 建议补一条：回调验证应在`await Init`恢复后的第一次操作前执行（当前合同已隐含，落为显式断言）

**Q2：ClubService构造时捕获PlayerKVRuntimeSelection可靠？**
**可靠。**时序核证：`SubBoostrap.RegisterServices`先注册RuntimeSelection→同方法内注册ClubService→ClubService构造时RuntimeSelection已在容器中。**无竞态**。如未来改为异步注册则需重审，当前同步注册无问题。

**Q3：部分绑定失败后"原对象保留陈旧句柄＋本进程拒绝重登"是否闭合？**
**闭合。**部分失败（如Setting绑定成功、Club绑定失败）时：
- 已绑定的Setting保留原句柄——后续读写被原句柄的撤销机制拒绝
- 未绑定的Club无句柄——正式KV分支的"无句柄拒绝"生效
- 本进程拒绝重登——防部分绑定后尝试"修复"导致状态混乱
- **不需要额外把所有实例同时置为不可用**——两个拒绝路径（有陈旧句柄/无句柄）已覆盖
- V05覆盖此场景

**Q4：白名单和V01–V07是否足够？真实ClubService验证？**
**足够。**白名单5文件限定到方法/入口级别，禁改清单明确。

真实ClubService验证手段：
- **合成宿主**：编译真实`ClubService.cs`＋真实`SettingService.cs`源文件＋CP1/CP2A协调器→用合成Bridge/handle→验证绑定/读写/撤销——**B01已证明此模式可行**（B01Tests即为此类）
- **Unity CLI Loop Editor**：实际容器/服务实例验证——CP2A已有89组先例
- `ClubSlice`为历史切片不能替代——方案已明确

### P3清单

- **P3-1**：§3.2的"已有同一原句柄的重复调用可作检查后幂等"——建议实现时记录重复调用计数到诊断输出（便于发现意外多次调用）。
- **P3-2**：§3.1的`DefaultSettingService`捕获"是否要求正式KV"——建议XML注释说明"此标志来自启动冻结选择，运行期不可变"，防后续维护者试图动态改。
- **P3-3**：V06"真实Player脚本编译若仍无不打包的CLI Loop方法"——建议CP3A实施时尝试Unity CLI Loop的`build`/`compile`命令带目标平台参数，如可行则同时关闭CP2A Player验证缺口。

## 结论

CP2A增量实施通过（`_cheatingScore`修复正确）。CP3A方案通过——5文件白名单＋V01–V07可批准实施。主会话核hash裁决后按白名单连续实施，批末复核可按加速模式与后续合并。