6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
70 lines
4.3 KiB
Markdown
70 lines
4.3 KiB
Markdown
# 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裁决后按白名单连续实施，批末复核可按加速模式与后续合并。
|