6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
4.0 KiB
4.0 KiB
M2 合批审核节奏纠偏
日期：2026-09-29。用户指出审核频率未实际降低。主会话裁决：上一检查点把 DP1 独立 KV 用户服务纵切单独备审，虽然只准备了一次提示，但仍新增一轮完整前审；这没有落实此前承诺的合批。立即停止把 DP1 作为独立送审批次。 保留已形成的候选方案、18 项 hash 和提示词作设计底稿，不删除、不回写历史；若评审侧已自行开始此题，收到报告只吸收事实与问题，不再以它触发一轮 DP1 单独实施/批末复核。
后续用户身份纠正：KV 模式使用认证会话提供的新
PlayerId；旧 PlayFab ID/EntityKey仅留 PF 模式，不再发起“新旧 ID 如何映射”的审查问题。DP1 旧候选稿中此类问句视为被当前合批工作稿覆盖。
后续只设一个可编码的完整前审批次
下次正式前审合并：
- 双提供方启动选择、独立 KV 用户服务、31 模块与原 handle、登录/退出/失败/epoch、PF/AGG 保留；
- CP2B 首场景自动调用的可信线上合同、公开身份、Mail/Survey/排行榜/Friend/AntiCheat 等同一入口的必要依赖；
- 与上述合同同源的 CP3 存档和业务调用迁移，以及首场景开闸所必需的旧
PlayFabMgr/SDK 直调清理。
把DP1 候选方案和CP2B 合同矩阵并入同一受审方案、一次受审 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 调用归并成上述一份完整可编码方案；若目前拿不到可信线上合同，明确记录阻断，不通过拆出更多“小审查”制造表面进度。