3.0 KiB
B2解析前置遗漏与修订1补审
2026-09-28，主会话发现并记录。本次是原方案技术遗漏，不是第三类真实存档问题；不把既有方案“通过”当作可以越过矛盾编码的依据。
已执行与证据
- B1：1277/1277基线一致，八项及三P3裁决，7文件修改前快照保存。
- CLI确认Unity 2022.3.62f2c1、当前项目、playing/enabled/ready=false、run=null、permit=false，11 claimed；未进入Play。
- B2：仅修改两个已批准的离线测试文件，保留全部其他模块严格断言。构建0错误0警告，精确执行KVGameLoadTests.dll，77组/1717次断言，74组通过、3组预期失败。
- 三组失败：M22-null-empty-list-preserves-fields-and-strictness（null列表应可接受）、M15-activity-all-saved-fields-strict（根null应为存在空态）、M15-explicit-null-raw-and-strict-boundaries（聚合应Valid）。不是编译失败，不是apphost错用。
- 原始结果：B2-red-build.log、B2-red-tests.log、B2-red-result.json、B2-red-artifact.json。B2-red-code-scope.json确认4生产文件和Editor验证host未变；只有2离线测试文件改变。
精确遗漏
PlayerKVSaveSchema.cs:145～168的共用Json先验证语法，再在:163执行if (reader.Read() || result.Type == JTokenType.Null) throw ...。原方案§3.1及原独立审查Q2假定Json能返回Null token，该假定错误。直接照旧方案编码，101的M15仍Malformed。
我编写原方案时漏核这一返回前检查，本轮在修改生产代码前发现。不能修改共用Json来消除错误，因为那会改变其他模块和原“共用helper不变”的边界。
唯一修订与理由
原4生产＋3测试白名单不变，仅修订DecodeChallenge内部的识别顺序：在Capture内对非C# null的文本，仅以四种JSON空白修剪后等于字面量null作为候选；对原字符串调用既有StrictJsonSyntax.Validate后返回ExplicitNull。其他输入保持原Object(Json(text))调用。共用Json、StrictJsonSyntax、Raw复制不修改；M22不受此问题影响。
StrictJsonSyntax.Validate现有全量耗尽检查以及Value的Literal("null")可验证这个唯一标量；这不是复制JSON解析器。非JSON空白、注释、额外token、尾逗号和注入字符串仍走原严格拒绝；原Raw空白字节仍保留。修订1新增这些边界断言以及原Json("null")仍拒绝的隔离断言，待补审批准后加入。
当前停点
暂停生产编码及后续B3。已经获审的红测代码和失败证据保留，不回退掩盖，也不称测试全绿。未请求服务器、未写存档、未运行真实101/102、未触发Play或打包。下一责任侧为独立方案差异补审；补审通过后主会话裁决即可继续原B2～B4，无需重审已关闭A。
补审对象为修订1§3.1、T1增量、本文及当前红测改动；其他八项/三P3已裁决的合同继续有效。原方案副本及原受审清单保持，可区分这次主动修正而非暗改受审版本。