6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
41 lines
5.3 KiB
Markdown
41 lines
5.3 KiB
Markdown
# M2修订2独立复审：主会话裁决与CP1实施边界
|
||
|
||
日期：2026-09-29。原ZCode报告 `M2-正式接线依赖独立复审-修订2.md` 已落盘，长度5577，SHA256 `AA8B72D58A09619929FE67BE8F37F3AAEF87509636D12034C3DB89DBB0D15173`。主会话复算19项长度和SHA256全部一致，证据见 `M2-修订2主会话hash核验.json`。原方案、报告及基线保持原样。
|
||
|
||
## 完整评审裁决
|
||
|
||
| 报告项 | 主会话裁决与开发边界 |
|
||
|---|---|
|
||
| CP1限定实施通过 | 接受。仅批准下列两份生产源码及合成测试宿主；原加载主体共用，验证路径保留持Guard语义。该批准不含普通启动、登录、正式接口或Player可运行声明。 |
|
||
| CP2前置设计盘点通过 | 接受五类阻断盘点，不视为CP2完整方案或编码批准。启动、认证、工厂、31模块绑定、业务路由的精确白名单与验收仍须完整设计和原ZCode审查。 |
|
||
| 四项事实及撤回30–50行估计 | 接受。当前源码与受审hash一致；SubBoostrap创建旧组件、kv被拒、网络验证路由限制、Bindings编译门均仍存在。 |
|
||
| 三个internal接口及成功时序 | 接受。Apply和notify完成后复核token/context/epoch/Guard，取得原对象，释放本次Guard，再发布GameLoaded。失败只保留证据，不发布handle。 |
|
||
| Revoke与并发 | 接受为必须验收项。发布/读取状态与Revoke使用协调器closeGate串行；外部身份回调不在Context的gate内执行。锁内不await，外部回调后重新核对epoch/closing/对象身份，禁止重入撤销后重新发布。Guard Dispose后补查最终计数，覆盖最终检查与释放之间的Reject竞争；不改Guard源码。 |
|
||
| Guard与KVMgr原样保持 | 接受。CP1不移动、不删除、不绕过Guard检查，不改变KVMgr四入口方法体。 |
|
||
| 三文件改动面 | 限定接受：生产源码严格为2个文件；测试宿主可以有测试源码和必要项目链接配置，不能把“3个文件”误写成允许修改第三份生产源码。 |
|
||
| CP1不会弃用 | 接受作为CP2交付门，不能把未来用途写成已经接线。下表给出消费关系；CP2若改用其他路径，合并前删除失效接口和相应测试，不留闲置实现。 |
|
||
| 本轮P2-1：消费点清单 | 接受，以下表落实。纠正报告示例：TryAcquireGameHandle不由CP2业务/登录调用方直接调用，而由协调器成功分支内部消费，保持两步交接封装。 |
|
||
| 本轮P3-1：同一消费点建议 | 接受，与本轮P2-1共用落实证据，但保留两条裁决；不虚构成两个独立缺陷。 |
|
||
| 修订1 P2-1五项落实 | CP1的签名、释放点、出口合同已完整；Player绑定及正式工厂只是明确划入CP2，尚未完成。拒绝把报告表中“已落实”扩大解释为全部正式接线完成。 |
|
||
| 修订1 P3-1 Guard引用 | 接受20处方法调用/5文件的既定计数口径；不扩展CP1范围。 |
|
||
| 修订1 P3-2 PF触发差异 | 接受，CP3逐域记录，CP4停用旧组件前对账；本检查点不声称完成。 |
|
||
| 修订1 P3-3 Player编译 | 接受。CP1合成/Editor验证不代表Player通过，CP2正式交付必须目标编译0错误，历史错误修复须单列白名单。 |
|
||
| 无P1结论 | 当前核对未发现足以否定CP1拆分的硬依赖；若实施发现需扩大生产白名单或改变合同，立即停在补审门。 |
|
||
|
||
## CP1到CP2消费关系（设计输入，尚未接线）
|
||
|
||
| 接口 | 唯一职责与拟消费场景 |
|
||
|---|---|
|
||
| Context.TryAcquireGameHandle | Coordinator.LoadForGameAsync共用主体的成功分支内部获取同一Context准备好的原handle；普通业务不能绕过协调器发布。 |
|
||
| Coordinator.LoadForGameAsync | CP2的UserService正式KV登录/加载分支完成配置捕获和正式能力构造后调用；其精确方法及认证次序在CP2完整方案确定，不能额外认证一次。 |
|
||
| Coordinator.TryGetCurrentGameHandle | CP2的UserService会话入口在正式加载成功后按预期epoch获取一次原对象，业务操作捕获并传给KVMgr；旧异步回调不得重查当前账号换Owner。 |
|
||
|
||
## 批级检查点与精确白名单
|
||
|
||
1. CP1-0：19/19基线核验、逐项裁决、保存已有Client工作树修改hash，记录本批准。
|
||
2. CP1-1：先在合成宿主证明现状缺少正式交接；再实施、跑原4B2和新增交接/撤销/失败/并发用例。生产仅 `Client/Assets/Scripts/Services/PlayerData/PlayerKVLoginContext.cs`、`Client/Assets/Scripts/Services/PlayerData/PlayerKVGameLoadCoordinator.cs`。测试采用 `CodexOutput/upserver/KVGameLoadTests/CoordinatorTests.cs`、`KVGameLoadTests.csproj`，必要的新测试放同一宿主目录。不修改其他历史测试行为。
|
||
3. CP1-2：B02四入口/Guard回归、Unity CLI Loop编译（非Play）、源码范围及既有工作树hash核验，交付当前hash和原ZCode独立实施复核提示词。批末复核之前不称CP1关闭。
|
||
4. CP2及后续：先完成正式接线完整方案与审查，再编码；CP3迁移调用、CP4清旧运行引用、CP5清闲置实现和最终流程图仍未完成。
|
||
|
||
每个检查点更新开发日志及当前状态。固定正式地址 `http://s101.local:18080/`，Unity只用CLI Loop，不用UnitySkills，暂不打包。不操作正式101/102账号、不做正式写入/付费，不reset、覆盖或提交已有工作树改动。
|