# 给原 ZCode：M2 合批一次性正式前审

请对本包做**完整、hash门控的正式方案前审**，直接给出是否允许在精确边界内连续编码的裁决。此前两次工作稿复核已结束；本次不要再只出“事实抽验/方向正确、不构成前审”的预审报告。开发侧未修改本批生产/测试代码，等待本次正式裁决。

## 先核基线

- 工作区 `C:\projects\ft`，只审客户端，不读不改任何本机/远程服务器代码。
- 基线：`CodexOutput/upserver/B3BatchMigration/M2/M2-合批正式受审基线.json`。
- manifest SHA256：`DBC965EDBF48FADA4C1508F2662562F4FD72C01711D8E2FE2022AC4956896EF3`。
- 2165项长度/SHA256；另12个expectedAbsent（拟新增源码/测试及Unity.meta），必须仍不存在。
- 候选白名单仅110个现存文件和12个拟新增文件。其它Scripts均为只读回归快照，**不因列入基线就授权修改**。2165项不是2165项运行覆盖。
- manifest不含自身、此提示词及滚动入口/日志，避免自引用。发现漂移先写出路径和范围，不把无关日志更新当源码漂移。

## 阅读顺序

1. 项目根`AGENTS.md`、用户固定要求：完整评审后编码；一个编码端；批内持续实施、减少审核次数；KV替代PF玩家存储，新ID来自认证PlayerId；保留PF/AGG；正式地址固定；Unity仅CLI Loop，不打包。
2. `M2-合批修订复核裁决与正式前审边界-2026-09-29.md`。特别检查P3a：当前IUserService.CustomId确为getter-only，先前报告称已有setter与源码不符；接口setter修订仍有必要。关闭API复用原名，P3c已入集中问题单。
3. `M2-合批正式实施方案-待完整审查-2026-09-29.md`，逐节完整审，不只检查旧预审意见是否复制。
4. `M2-合批正式候选白名单.json`、`M2-合批存档调用实施台账.json`、`M2-合批动态配置投影.json`。
5. `M2-客户端致服务端线上合同集中问题单-2026-09-29.md`，以及旧双提供方约束和最终门控清理清单。旧DP1独立实施已暂停，不能把本包缩回DP1另开小轮。

## 必须一次审完的风险

- 独立KVUserService是否真正摆脱旧PF类和SDK类型；IUserService/CustomId/第31接收器/生命周期/SmallGameData DI/PFLoginAct/QuitAct完整性；成功Descriptor和身份事件发布时序；关闭失效/旧epoch/双登单发。
- 共用存档契约是否必要且足够简单，是否保留KV票据与PF原路线；固定store一次绑定、40秒调度、异步前后有效性、失败与缺键区分、remoteStore=false和即时消费的确认语义。禁止新的Core→Services依赖；现存KVMgr物理位置仍是明确待办。
- 224项台账的规则是否适用，PF内部/AGG/受控验证不能批量误改；台账并非运行证明。检查首场景Init、直接和条件订阅、泛型活动仓库、ItemAddedEvent、真实奖励/消耗回调；110文件上限能否覆盖实际调用者而不漏接。
- 本地配置直接LoginDays匹配0的准确含义：不能因此删除活动或省掉Init；不能把本地投影说成线上配置/101、102实际运行。
- Survey/邀请奖励的主档及连带存档、邮件批量HasRead/HasReward缺陷、个人邮件膨胀差异、提前ShowData、重复点击、Unknown/部分提交/崩溃。方案明确不承诺跨系统事务：请直接裁决原协议迁移可以实施到什么范围，若某动作不能安全放开，列具体原因和必要设计，**一次汇总**；不要重新问玩家数据应存哪。
- KV等级榜聚合/他人资料/原PF好友列表/匹配是真实跨账号或服务能力依赖；现有普通游戏服API按旧逻辑/新ID继续。客户端可编码范围、完整运行放行、最终通关三者必须区分，不能因外部能力缺少把全部客户端工作无限挂起，也不能伪造路由和空成功。
- formal ServiceHost必须改Program/Stubs/csproj用真实新服务；PF/AGG/kv-loop签名回归；真实Player/SignalR/正式账号未验如实标未验，不要求违规绕过CLI Loop的Restricted限制。
- 开发期临时冻结/跳过最终全部销账；保存原PF功能；命名延后；不读/改服务器，不打包。

## 输出

将报告写至同目录 `M2-合批正式独立方案审查-2026-09-29.md`，包括：

1. manifest核验总数、缺失/漂移及expectedAbsent；受审manifest hash。
2. PASS/有条件PASS/BLOCK及理由。区分阻止本批编码的问题、仅阻止相关动作/运行放行的依赖、最终通关未验项。
3. 一次汇总P1/P2/P3；每项具体文件/调用/故障、必要修正。不要拆成逐模块审核请求。
4. 明确批准/不批准的文件与行为范围，若收窄说明其仍形成的完整可实施链；不要笼统只说“方向正确”。
5. 获批后批内开发、修常规测试/编译失败不再送审；最终一次实施复核。只有真正架构/协议/文件边界变化才补充处理。

审核侧只读源码，可写此报告；不代替开发侧改代码，不请求正式101/102，不进入Play或打包。不需要给用户再次发ID/存储位置的问题。