3.8 KiB
P2-alpha-B修订1解析前置独立补审
日期：2026-09-28。审查者：ZCode会话。独立性声明：未参与修订1编写；诚实披露：原方案审查Q2中"先原严格Json一次、仅token.Type==Null走工厂"的可达性判断同样依赖了"共用Json可返回Null"这一错误假设，本审查者当时未核:163的返回前拒绝——本轮据源码逐项复核修订的正确性。本轮只读＋hash重算＋源码核查。
受审hash核对
P2AlphaNullCompatibility/revision1-review-hashes.json：1301/1301重算全部一致。
总判定
接受。批准按修订1恢复B2～B4。 无P1/P2；P3两条（其一为实施精确性提醒）。
四项逐条
1. 原阻塞成立、StrictJsonSyntax支持修订：确认。 本审查核实PlayerKVSaveSchema.cs共用Json在:163执行if (reader.Read() || result.Type == JTokenType.Null) throw——根null在返回前即被拒，原方案§3.1分支确实不可达。同时核实StrictJsonSyntax.Validate（:1093）＝Value(0); Space(); if(position!=text.Length) throw：①Value对'n'走Literal("null")(:1121)——null字面量可验证；②末尾全量耗尽检查——"null x"/"null,null"等多余token拒绝；③Space()恰只跳过' ','\t','\r','\n'四种JSON空白；④无注释语法——/*null*/拒绝。修订的技术基础完整成立，且不是复制解析器（复用既有类）。
2. 修订顺序满足三态/严格负例/Raw合同：成立。 候选识别（四种JSON空白修剪后==字面量null）→StrictJsonSyntax.Validate(原字符串)→ExplicitNull()；其他一切输入仍走原Object(Json(text))。共用Json/StrictJsonSyntax/Raw复制零修改（其他26+模块不受影响）；C# null/空串/"null"字符串(带非JSON垃圾)/对象字段null与根null的分离保持；Raw原字节（含空白变体）由既有复制保留。
3. 新增负例断言充分：是。 非JSON空白(\v/\f等)、注释、额外token、尾逗号、注入字符串、Json("null")经共用helper仍拒的隔离断言、三态与对象字段null分离——覆盖了修订引入的全部新边界。M22判断准确：DecodeBargain的父对象经Object(Json(...))正常解析、嵌套obj["selections"]的token.Type判null在JObject层面进行——不依赖共用Json返回Null，嵌套null检测不受:163影响，原方案M22合同无需任何改动。
4. 白名单与红测边界：保持。 B2-red-code-scope.json确认4生产文件＋Editor host未动、仅2个已批离线测试文件修改；红测77组/1717断言中3组失败均为目标兼容断言（M22-null-empty-list/M15-root-null/M15-explicit-null-aggregate）——预期失败非编译/apphost问题（apphost教训已按约定用精确DLL执行）；停点纪律正确（发现矛盾→停→补审，不越矛盾编码）。可按修订1恢复B2～B4。
P3清单
- P3-1（实施精确性）：候选修剪必须逐字符只用
' ','\t','\r','\n'——禁止string.Trim()或char.IsWhiteSpace（两者接受\v、\f、\u0085、\u00a0等非JSON空白，会把非法输入误判为候选并经Validate……实际会被Validate拒绝，但候选集扩大徒增审计噪音且偏离"四种JSON空白"合同字面）。建议T1同步断言\v/\f/\u00a0包裹的null被拒。 - P3-2：修订落码时建议在DecodeChallenge内加一行注释说明"Json(:163)返回前拒绝根null，故null识别前置于Object调用"——为后续维护者保留不可达分支的教训。
结论
接受修订1。 主会话核hash（已代验1301/1301）裁决后按修订§3.1/T1增量恢复B2（生产四文件编码＋新负例）→B3→B4→B5独立实施复核。原八项/三P3裁决合同继续有效；本补审不改白名单、不涉及真实账号写入。