6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
24 lines
4.9 KiB
Markdown
24 lines
4.9 KiB
Markdown
# 给原 ZCode：M2 CP2B-T 正式 KV 普通业务请求恢复一次性方案审查
|
||
|
||
用户明确：`CustomServerMgr` 的 KV 普通请求拒绝是开发期临时门，最终 KV 应正常走业务请求；同时坚持完整方案评审后编码、每检查点记日志、尽量减少审核往返。请只读审[CP2B-T 完整方案](M2-CP2B-T正式KV普通业务请求恢复完整方案-待独立审查.md)。先逐项重算[7 项受审基线](M2-CP2B-T受审基线.json)的长度/SHA256；清单自身 SHA256 为 `3DF008B9474D730C82CACA65FAE0306CC18B13DF6454C0ED0694A7273A368842`。受审源码、方案或基线有漂移请先指出，不据漂移文本下编码许可。
|
||
|
||
请一次评完运输合同、时序、精确白名单与合成验收，报告写入 `M2-CP2B-T独立方案审查.md`，列 PASS/条件通过/阻断、P1/P2/P3、可实施的最小修订。重点回答：
|
||
|
||
1. 利用同一 Context 拥有的正式 `PlayerKVAccountLease` 与 Cookie 发送正常相对业务请求、验证租约仍精确只认两路由，是否保持认证一次、三 handler 所有权和 Close 排水？当前 `BindKVForGame` 在 Apply 前发生，方案的 GameLoaded+CP3A 绑定后一次启用是否足以阻止加载期副作用？
|
||
2. 规范路径校验和保留 `account/Login`、`playerdata/*` 的专用传输是否足够；是否有已知合法现有调用被误拒？审核不应将“开发门暂时拒绝所有普通请求”误判为最终产品政策，也不能把客户端路由字符串冒充线上响应合同。
|
||
3. 401/403、Logout/Quit、旧响应、同账号新 epoch 和 Close 失败时，禁用普通请求、SessionVersion、Cookie/SignalR 连接与原 handle 撤销顺序是否闭合？`UserService.cs` 不在白名单能否只通过 `UserService.KVLoad.cs` 完成正式 KV 未授权接线？若不能，请列唯一必要补审文件和原因。
|
||
4. 在**不开放 `FishingStage`、不运行正式账号、无可信线上文档**的前提下，这一运输子批能否以合成 handler 和 Unity CLI Loop Editor 编译独立验收？列它不能证明的业务 route、公开身份、真实 Player/SignalR 范围；不要要求本机服务器源码证明线上行为。
|
||
5. 白名单、回归与闲置实现清理是否足够；若有新状态/接口，是否有消费者及最终清账条件？
|
||
|
||
另有以下尚未裁决的源码级疑点，请在**同一份报告**逐条给出结论、依据和可实施的最小修订；不能确认的标阻断条件，不要默认为通过：
|
||
|
||
6. `PlayerKVControlledLoadCapability` 的 formal/validation 模式怎样安全传给 `PlayerKVAccountLease`？正式模式不得借验证入口发送普通请求，验证模式不得因新增入口突破原两条精确路由；正式模式反过来也不得调用 `__kv_validation/*`。现有普通请求是否含方案路径校验会误拒的合法路径、查询或编码形式？原 `CustomServerMgr` 的约 15 秒超时、JSON/Content-Type 与失败返回语义能否由租约保持，超时不应误判成 401 撤销。
|
||
7. `BindKVForGame` 在 31 模块 Apply 之前执行；`UserService.KVLoad` 完成 GameLoaded/CP3A 交接时，`UserService.cs` 的公开 `IsLogin`/`ApiPlayerId` 仍未支持正式 KV。此时发布运输就绪是否有任何实际调用者会提前发请求或读取错误身份？请明确这是“普通请求运输可用”还是“首场景业务可用”，并指出若需延后发布/补身份，三文件生产白名单是否足够。
|
||
8. `ICustomServerMgr.Cookie` 返回同一可变 `CookieContainer` 给 `RTService.Connect()` 后，旧连接在 SessionChanged/SessionVersion、退出、401/403 和同账号新 epoch 下能否可靠失效？租约与管理器可能都调用 Close，活动请求排水或关闭失败时会不会双关、死锁或重新开放？401/403 回调在哪个线程执行，`LogoutFormalKV` 是否能在任何 await 前安全同步撤销 businessReady、原 handle 和公开状态，旧响应是否可能撤销新会话？如需改 `RTService.cs`、`UserService.cs` 或其他白名单外文件，请列唯一必要增量及理由。
|
||
|
||
请将上述疑点与前五项合并成一次裁决，尤其判定“无线上业务合同也能独立实施运输层、同时继续阻断 `FishingStage`”是否成立；不要据此批准首场景真实业务调用。若存在阻断项，只列最小方案修订和需重新封存的文件，不直接编码。
|
||
|
||
若已有只答前五项的报告，请在同一报告追加第 6—8 项补审与更新后的总裁决，并明确原先“通过”是否仍成立；本提示的更新晚于该旧报告，不能把旧结论当作新增疑点已经审过。
|
||
|
||
请不要改生产/测试源码、受审方案/基线、共享 TODO/状态/日志或本提示。只在指定报告文件给独立意见。不要访问或修改本机服务器代码，不发正式 101/102 请求，不打包；Unity 自动化如确需，仅 Unity CLI Loop。主会话收到报告后先复算 hash、逐项裁决，未批准前不编码。固定地址 `http://s101.local:18080/`。
|