54 lines
5.2 KiB
Markdown
54 lines
5.2 KiB
Markdown
# 阶段4B2检查点2字段差异独立审查
|
||
|
||
日期：2026-09-23。审查者：ZCode会话。
|
||
|
||
**身份披露**：未参与本补审方案编写（补审方案由主会话编制）。另须如实披露：本受审方案纠正的两处缺陷（附件§3.1的AD格式描述、§3/§5的FootPrint位宽承载）**存在于我此前审查通过的修订2附件中，当时未被我发现**——我的A组核查验证了19槽/键名/副作用，但未核对AD两种入口的JSON值类型差异与枚举承载位宽。本轮按源码逐项复核确认补审方案的正确性。
|
||
|
||
本轮只读＋仅新增本文件；未改代码/方案/入口/TODO/日志/原hash；无子Agent、无正式服、无PlayMode、无Unity执行（纯只读源码核对）。
|
||
|
||
## 基线核对
|
||
|
||
`阶段4B2检查点2差异受审基线-2026-09-23.json`共14项，逐项重算SHA256——**全部一致**。
|
||
|
||
## D1（旧AD格式）：通过
|
||
|
||
**源码证据核实**：
|
||
- `DataCenter.PlayerData.cs:992–996`：`NewPlayerDataDic["AD"]`→`LoadAchievementDataToObject`；顶层`AchievementData`→`LoadAchievementData`——两入口确实不同。
|
||
- `AchievementDataManager.cs:35–50`：`LoadAchievementData`反序列化`Dictionary<ConditionType, AchievementData>`（**对象值**）；`LoadAchievementDataToObject`反序列化`Dictionary<ConditionType, string>`（**字符串值**），按`|`切三槽调`ToObject`，且槽数≠3时**静默跳过**（现行宽松语义）。
|
||
- `AchievementData`字段：`Id:int`、`Target:ulong`、`day:int`；`ToObject`按`int/ulong/int`解析——补审方案的三槽类型合同逐字段正确。
|
||
|
||
**结论**：原附件"AD同AchievementData格式"确为错误定义（会把合法旧字符串档错拒、甚至错收对象值）。补审的三表示严格合同（顶层对象值／AD三槽字符串／ad紧凑串）、规范优先级`ad > AD > 顶层`、共存先各自严格解码再按修订2"共有字段冲突→ConflictingRepresentations、一致选新"规则——与修订2已审的同义表示规则（ld/LDD先例）完全同构，边界（null/对象冒充/缺槽多槽/空记录/溢出/重复属性/枚举别名重复/未定义枚举→Malformed；不坏转重试、不回落掩盖）自洽。**采纳，无修改意见。**
|
||
|
||
## D2（FootPrint位宽）：通过
|
||
|
||
**源码证据核实**：`FootPrintService.cs`：`public enum EFootPrint : int`；`private EFootPrint _footPrint`；`LoadData`为`_footPrint = (EFootPrint)ulong.Parse(data)`——**UInt64输入直接截断为32位承载**；`UploadData`仅上传`(ulong)_footPrint`。原附件"UInt64保持原值位宽"与32位实际承载确实矛盾（如`4294967296`第32位会静默丢失）。
|
||
|
||
**结论**：补审方案闭合——
|
||
1. 保持公开枚举/接口/PF原方法不动（PF路径字节等价）；
|
||
2. 受控KV加载增加`ulong`完整位集字段＋internal只读验证访问，低32位unchecked投影到既有视图且**明示视图不反映全部64位**；
|
||
3. 不收紧已审64位输入域、不因未声明高位拒档；
|
||
4. guard继续阻断受控范围内`UploadData`（其只能上传32位视图，不允许经旧入口保存64位KV状态）；
|
||
5. 4B3消费完整位集另审、退出受控后不承诺可玩——范围诚实。
|
||
|
||
备选路线否决理由成立（改枚举基类扩大兼容面；拒高位缩窄已审合同并新增拒档政策）。**采纳。**
|
||
|
||
**一项补充确认（非缺陷）**：高位→缺失同对象Reset测试要求"完整字段与视图同时归零"（§2验收末句）已覆盖状态合同变化；真实对象Unity宿主验证、离线算术不替代——与B2-20分层一致。
|
||
|
||
## 范围与边界核对
|
||
|
||
- 仅改附件§3.1的AD行与§5的M23行语义，形成覆盖层；无新增白名单文件（`FootPrintService.cs`本在M23白名单）；无公开接口/旧PF路径改动；无联网/持久化授权扩张 ✓
|
||
- 检查点顺序维持（不重做检查点1，3/4不越序）✓
|
||
- P2-α（真实档兼容/迁移＋用户产品确认为启用门硬前置）保持 ✓
|
||
|
||
## 发现清单
|
||
|
||
**无P1/P2。** P3三条：
|
||
|
||
- **P3-1**：D1按严格合同执行后，旧PF档中曾被`LoadAchievementDataToObject`静默跳过的坏槽条目（源码现行宽松语义）在KV下将整体Malformed——这与已裁决的"KV严于PF"政策一致，但属**真实存量档兼容性**的又一具体触点，建议主会话把"历史宽松跳过条目"列入P2-α迁移方案的盘点输入，避免启用门评估时遗漏。
|
||
- **P3-2**：D2投影建议在实现中以`unchecked`显式标注并加注释说明"视图=低32位"——防止后续维护者误读为完整位集（实施细节，不影响合同）。
|
||
- **P3-3**：补审后附件存在"原文＋覆盖层"两层语义，建议主会话裁决时把两处修订**回写进附件正式版**（保留历史版本注记），避免后续31组实施时读者只看原文出错。
|
||
|
||
## 结论
|
||
|
||
**D1通过、D2通过。** 两项差异修订均有准确源码依据、闭合的合同定义、充分的测试要求，且严格限定在既有文件与授权边界内。建议主会话逐条裁决（含P3-1的P2-α联动、P3-3的附件回写）后，作为附件覆盖层继续检查点2全部31组。本次为设计差异补审，不代替4B2完整独立实施复核；检查点1局部证据不解读为阶段通过。
|