6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
28 lines
5.0 KiB
Markdown
28 lines
5.0 KiB
Markdown
# M2 加速与双 Agent 并行方案可行性裁决
|
||
|
||
日期：2026-09-29。只读核查：[加速模式裁决](../../加速模式裁决-2026-09-29.md) SHA256 `9C7584935834EB87E84648F2D1145A616BDB66D9A749610CD3E8A92F43A589B5`；[双 Agent 并行分工方案](../../双Agent并行分工方案-2026-09-29.md) SHA256 `D3D0C955864D93C64EFBC1270443322A0E8FFE5830A5FAB2F4C8B9F9012C63C6`。对照[CP2A 已获批边界](M2-CP2A独立方案审查主会话裁决与实施边界-2026-09-29.md)、[CP2A 预复核裁决](M2-CP2A独立实施预复核主会话裁决-2026-09-29.md)、[首场景依赖](M2-CP2首场景自动依赖核查-2026-09-29.md)及[224项当前调用矩阵](M2-当前调用矩阵-待核证.json)。本裁决只定流程可行性，不批准新生产编码。
|
||
|
||
## 总裁决
|
||
|
||
**接受提速目标与批量评审方向；不接受两份方案按现文直接进入 CP2B/CP3/CP4+5 编码，也不接受“终点复核”替代编码前完整方案评审。** 可以把同一业务合同的调用合并成大批方案、一次完整前置评审和批内多个检查点，不必逐调用走六步。开始每批代码前仍须有完整方案、受审版本、逐项裁决、精确文件白名单和验收边界；每个检查点更新开发日志。终点全量独立复核仍保留。三天或双端一两天属于未经依赖和回归核实的预期，不能作为交付承诺。
|
||
|
||
## 加速方案逐项判断
|
||
|
||
| 提议 | 裁决与理由 |
|
||
|---|---|
|
||
| CP2A+B 合并立即实施 | **不按现文执行。** CP2A 已按独立批准的 12 文件边界实施，仍欠 Player 编译与终审；用户选定 CP2A 首验只做登录/原 handle 交接、在 FishingStage 前停住。CP2B 的 Mail、Survey、排行榜、AntiCheat、Friend 等会触发新路由、身份语义及旧 PF 调用，需完整方案、白名单、失败/旧 epoch/路由验收后才能编码。可把 CP2A 终审与后续整体复核合并安排，但不能以此提前开放场景。
|
||
| CP3 约 200 项一次机械替换 | **不按现文执行。** 当前 224 个语法候选/81 文件中仅 200 个标为待迁移，矩阵逐项仍是 `implementationApproved=false`，并非 200 个等价替换点。`GetLocalData` 的 `string/null` 与 `ReadKV` 三态、旧 `void/bool` 与 `WriteKV`/票据/Unknown 不等价；部分调用涉及付费、资源、奖励、延迟回调和 `remote` 参数。必须按业务动作合并读写、固定原 handle 来源、首个内存变化、失败停止点与票据确认，再批准批级边界。
|
||
| CP4+5 一次清理 | **原则可合并计划，实施须在依赖清零证据后。** 旧 Manager 运行引用、组件/Prefab/反射、Guard 合同、SDK 直接调用及闲置实现都需完整盘点和验收。不能仅凭文本调用为零删除；最终代码必须清理闲置实现。
|
||
| 仅终点独立复核 | **不充分。** 可减少重复文档和中间独立实施复核，但不能省去相关方案编码前的完整评审与明确裁决。这也是工作区 AGENTS.md 和本会话既定边界。回归/Editor 编译不能代替设计审查或真实 Player 目标编译。
|
||
|
||
## 双端方案逐项判断
|
||
|
||
1. **现有文件隔离表不成立。** A 做 CP2B 的 Survey/Friend 等首场景依赖，B 的“Services/约81业务文件”又包含 `Services/SurveyService.cs` 4项候选与 `Services/FriendService.cs` 2项候选；B 的 `DataCenter/` 覆盖 CP2A Player 阻断补审 `DataCenter/FishingChallengeManager.cs`。目录级归属与真实功能、精确文件清单冲突。
|
||
2. **A 文件表含已否决的新 `PlayerKVRuntimeLifetime.cs`。** 原 CP2A 裁决明确使用既有 `PFLoginAct.OnDestroy` 和 `UserService.Application.quitting`，该文件不存在；不能从分工方案反向获得代码授权。
|
||
3. **B 指令只有两种方法名，范围与合同均不足。** 矩阵还包含 Sync、Compare、GetUserData 等候选；四个 KVMgr 入口要求显式原 handle，返回状态必须沿真实业务上游处理。仅从构造函数注入无法覆盖静态/全局数据中心、异步回调、延迟事件或生命周期；B01 模式只可用于已验证的相同合同。
|
||
4. **共享未提交工作树不适合两个编码端同时写/编译。** 两端会改变对方受审 hash 与编译输入，Unity CLI Loop 的同一项目测试也难归因。若未来确需并行编码，先在完整评审后按**精确文件**划分所有权、明确跨域接口与集成顺序，分别冻结基线；各端互不修改对方文件，整合后重新核 hash 并串行跑全量回归/Editor及可用的 Player 编译。仅目录粗分与事后终审不足以保证安全。
|
||
|
||
**当前可行的双端形式**：A 在既定 CP2A 边界内完成补审修复与验证；B 同时只读梳理 CP2B/CP3 业务动作矩阵、依赖、精确文件归属和完整方案，交完整评审后再决定是否分离编码。若要新开独立会话，应以当时已冻结的基线与上述边界为输入；本文不视为双端已实际启动的证明，也不创建会话。
|
||
|
||
固定 `http://s101.local:18080/`；Unity 只用 CLI Loop，不用 UnitySkills；暂不打包，不操作正式 101/102。保留现有工作树改动。
|