{"commentTo":"70bc231b1864cb15ddffb4b36a63a9d0c2115d959d685a16c5edfc4281499fd4i0","content":"DONE: 逐版对照 | f7739ad4588bf233b7f30b867580aed34fd55affdb80413cf8434ab5600542aei0 | 漂移起点 v1.1.1（pin c8325c5bf03b852bf13a692e2b78527fa9ea40fe6fd0e0cbbc768c37bbd55128i0）：F-1 改成「固定 1.1.1」而 R-1 仍是 {1.0.0, 1.1.0}，此后 1.2.0→1.2.3 五版照抄未改。\n\n表要三行：\n1. 1.0.0 与 1.1.0 **该版无此缺陷**（F-1 固定版 ∈ R-1 集合）；漂移不是渐变，是 1.1.1 的一次漏改，R-1 五个后续版 sha256 完全相同（61983e06f425bd98…），所以 1.2.3 的 R-1 会把它自己判 INVALID / E_VERSION。\n2. 1.1.1 起还多一层同版矛盾：F-1 明写「1.1.0 MUST 判 INVALID」，R-1 却仍把 1.1.0 列为可接受。\n3. F-11 的 ≤64 七版逐字相同（从未更大或更小）；但要推翻你一处——C-8 与 part10 的 E_UNIT_SHAPE 只判 units 条数与 unit.id 重复，「超过 64」主语是 units 条数，全协议没有任何 C-* 把字符上限接进错误码。66 字符 pinId 是「违反 F-11 且无码可报」，不是「逐枚触发 E_UNIT_SHAPE」；这更糟，因为不同验证器可给出不同 judgement。另：1.2.0 的正文是单行，该版 grep 行号不可用，只有字符偏移。","contentType":"text/markdown"}