# M2 合批审核节奏纠偏

日期：2026-09-29。用户指出审核频率未实际降低。主会话裁决：**上一检查点把 DP1 独立 KV 用户服务纵切单独备审，虽然只准备了一次提示，但仍新增一轮完整前审；这没有落实此前承诺的合批。立即停止把 DP1 作为独立送审批次。** 保留已形成的候选方案、18 项 hash 和提示词作设计底稿，不删除、不回写历史；若评审侧已自行开始此题，收到报告只吸收事实与问题，不再以它触发一轮 DP1 单独实施/批末复核。

> **后续用户身份纠正**：KV 模式使用认证会话提供的新 `PlayerId`；旧 PlayFab ID/`EntityKey` 仅留 PF 模式，不再发起“新旧 ID 如何映射”的审查问题。DP1 旧候选稿中此类问句视为被[当前合批工作稿](M2-合批实施方案工作稿-2026-09-29.md)覆盖。

## 后续只设一个可编码的完整前审批次

下次正式前审合并：

1. 双提供方启动选择、独立 KV 用户服务、31 模块与原 handle、登录/退出/失败/epoch、PF/AGG 保留；
2. CP2B 首场景自动调用的可信线上合同、公开身份、Mail/Survey/排行榜/Friend/AntiCheat 等同一入口的必要依赖；
3. 与上述合同同源的 CP3 存档和业务调用迁移，以及首场景开闸所必需的旧 `PlayFabMgr`/SDK 直调清理。

把[DP1 候选方案](M2-双提供方独立KV用户服务抽离方案-待完整评审-2026-09-29.md)和[CP2B 合同矩阵](M2-CP2B客户端首场景线上合同待核矩阵-2026-09-29.md)并入同一受审方案、一次受审 hash、一次原 ZCode 完整前审、一次主会话逐项裁决和精确文件白名单。**不会先审 DP1、再审 CP2B、再按每个调用审 CP3。** 后续用户裁决优先：KV 模式将原 PlayFab 玩家数据读写迁至 KV，原游戏服接口沿用原逻辑并接新 ID；不再把逐项旧接口合同或“数据存哪里”作为反复提问/送审前置。跨玩家等级榜聚合读取属于服务端实现依赖，由其他开发侧处理；本 Agent 不读/改服务器代码。完整客户端方案及精确白名单未评审裁决前，仍不改新生产代码。

## 编码与复核节奏

- 前审通过后，一个编码端在批准白名单内连续实施；内部可按模块分检查点，每点更新开发日志并跑相关测试，但不因常规测试通过或局部修复再发独立审查。
- 开发阶段不因常规实现细节、可在白名单内修复的编译/测试失败、单个检查点完成而暂停等待审核；记录首败，定位并修复后连续回归。只有新线上合同、受审方案外架构变更、代码白名单越界或不可逆真实操作才停在对应边界作精准裁决。
- 同一已审合同的重复调用合批实现，读/写/票据/Unknown/失败停止点一起处理；不做约 200 处机械替换。新增真实合同或架构边界超出白名单时只做**针对新增差异的补审**，不重审整个方案。
- 批内不再逐段做独立实施复核。完成已批准大批后，统一跑双模式回归、Unity CLI Loop 编译与可取得的 Player 证据；迁移终点做**一次全量独立实施复核**，逐项清理开发期门控与闲置 KV 过渡实现，同时保留仍供 PlayFab 模式使用的类、SDK 和资源。
- 项目根目录 `AGENTS.md` 的“编码前完整评审和明确裁决”仍有效；加速是扩大审查范围、减少往返和中途复核，不是省略前审。现有正式 URL、仅 101/102 有档准入、首场景阶段闸、工作树保留、不动本机服务器、只用 Unity CLI Loop、暂不打包继续有效。

## 当前检查点

CP2B-T 运输子批已限定关闭。DP1 在本工作区尚无独立报告，**未获代码白名单；本会话不再发起 DP1 单独送审**。下一步只读把首场景依赖、线上合同来源与同合同 CP3 调用归并成上述一份完整可编码方案；若目前拿不到可信线上合同，明确记录阻断，不通过拆出更多“小审查”制造表面进度。