6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
36 lines
5.0 KiB
Markdown
36 lines
5.0 KiB
Markdown
# M2 合批 C2c 集中边界差异与后续连续开发方案
|
||
|
||
日期：2026-09-29。状态：**待一次差异审查，仅下列新增文件范围未获批**。现有已审范围仍可连续自修；不重新开启逐模块审核。
|
||
|
||
## 为什么这次确需边界裁决
|
||
|
||
正式独立方案审查 §5 明确：“候选白名单 110 现存 + 12 新增……白名单外文件零修改”；§7 仅在“白名单越界”等真实变化时要求针对差异补审。实际补单调用者与旧奖励验证宿主没有列入白名单。这里不是再次确认 PlayerId/KV 原则，也没有服务器合同变化；是原清单未覆盖真实调用链。
|
||
|
||
原报告 SHA256：`BB02441CFFE72AF18CF3B0D78F8E581FC39549C3F77E45257B5ED16CADCF2937`。原 manifest SHA256：`DBC965EDBF48FADA4C1508F2662562F4FD72C01711D8E2FE2022AC4956896EF3`。保持原清单字节，新增边界独立记录。受影响文件当前 hash 见配套《M2-合批-C2c集中边界差异hash.json》；必须审查当前组合检查点，不要求已批准实施后的代码回到旧 hash。
|
||
|
||
## 三个精确增量文件
|
||
|
||
| 文件 | 已核证问题 | 提议允许的最小改动 |
|
||
|---|---|---|
|
||
| `Client/Assets/Scripts/UI/Home/HomePanel.cs` | :886 调用 void ReleaseReplenishmentData 后立即继续 TriggerPack、暂存奖励和 ShowData。只把被调用方法改 Task 会变成无人等待。 | 只捕获当前玩家/固定 store 与界面生命周期，await 已存在 PlayerShopData 的补单 Task，成功且仍当前后继续原后续；失败留待处理、不重放、不显示成功。保留原 UI/活动功能，不冻结后续逻辑来假通过。 |
|
||
| `Client/Assets/Scripts/Services/UserService.KVFishingRewardValidation.cs` | 实际 CLI Loop fishing-reward 首败：手动 new GuideDataCenter，没有注入 playerSaveStore，Init:100 空引用；多处类似手动构建 Player/Fish/Event/奖励模型。 | 只修改隔离测试装配：为每个既有 fixture 注册固定 store，并注入实际消费对象/其嵌套模块；在 finally 恢复/释放。保留原真实 Init/奖励方法/失败断言/禁止正式网络检查，不改 reward runtime 实现，不弱化测试。 |
|
||
| `Client/Assets/Scripts/Services/UserService.KVFishingValidation.cs` | 实际 fishing-consume 在 MiniBattlePassDataProvider.GetMiniBattlePassRecord:143 空引用，调用者 FishingSubscribers.Bind:300；隔离容器缺 IPlayerSaveStore。 | 只修改离线消费 fixture 的注册、固定生命周期注入和 finally 清理；保留原真实耗能/恢复/活动订阅断言及原 loop 票据，线上逻辑零修改。 |
|
||
|
||
测试 store 优先复用 `PlayFabPlayerSaveStore` 的内部构造，绑定原 fixture 的未启动 PlayFabMgr 与本 fixture token。原因是原 kv-loop 的 PlayFabMgr 读写已经转交原 loop 收集器；直接另建 KV store 可能绕过该收集器并破坏旧证据。必须验证原路径计数与票据不变，不能为测试加第二 Owner/全局路由。纯加载 B2-20 已通过；装备 equipment-chain 也实际通过 9 组/28 断言。因此不请求扩 UserService.KVGameplayLoop.cs，也不修改已通过的装备装配；不要把全部加载/装备宿主宣称成阻断。旧消耗与旧奖励的失败分别有完整堆栈。
|
||
|
||
## 已在原白名单内的配套工作
|
||
|
||
- PlayerShopData.ReleaseReplenishmentData 改 Task，并按原订单号、原库存发放/业务通知，收集连带键和主档；确认后才清理对应待发条目。旧会话和失败不得自动再发。不改变平台确认协议，不伪称已解决远端确认与 KV 的事务窗口。
|
||
- 复用已有 PlayerSaveAction/固定 store；没有增加 Manager、接口、协调器、协议或启动开关。同步事件继续真实触发，延迟的是奖励成功展示。
|
||
- ServiceHost / 已批准测试文件增加补单关键错误路径测试；必要的 Unity 真实 fixture 回归从已有 CLI Loop 固定入口执行。
|
||
- 查实际调用者是否只有 HomePanel。若发现额外白名单外消费者，先纳入同一差异清单核证，不私下扩面。
|
||
|
||
## 验收与后续顺序
|
||
|
||
1. 独立侧一次审完上述三个文件精确边界，记录逐项裁决。若不同意 store 复用方式，给出保留原 loop 行为的具体装配修正；不改生产去容忍 null 依赖。
|
||
2. 同一个编码端连续实现补单服务+实际 UI、旧 fixture 装配、必要失败展示；编译/测试首败自行修复并记日志。
|
||
3. 重跑 ServiceHost 两条件、真实固定模块、原 fishing-reward 和装备 fixed validation，核恢复状态与正式请求 0；所有测试必须真实通过，失败不删断言。
|
||
4. 同批继续已审奖励/初场景验证；只在真实新合同/架构/文件越界时集中扩一次差异。常规通过自动进入后续，不再要求用户每小步“继续”。最终统一 C4 实施复核。
|
||
|
||
仍不批准服务器源码读写、正式 101/102 请求/写入、付费、Play、真实 Player/SignalR 操作验收或打包；保留现有两闸直到原 C3 条件满足。项目结束前所有开发性跳过、冻结和闲置实现必须恢复或清理，改名留最后。
|