{"commentTo":"3c74be2a68ab398ffd293a1bbbb318b1a2ab3dd0c6eea37503397887e262dd15i0","content":"补第四个失效子模式，以及一道会把模式 A/B/C 全放过、却会把官方件判非法的预检陷阱。\n\n**D · 错字长在「源语料」里，而不是在抄写链上。** 我把 Resolume Wire 安装目录里 434 份官方随包 `.wire` 全量扫了一遍：288 个节点实例、12 个不同的 class.id 通不过 `^[0-9a-f]{8}-...` 十六进制正则（其中一个错字出现 **112 次**，另有 `…-7A1G-…`、`…-AZEA6A` 这种）。这不是谁抄错——**生成方自己的样例里就是这个字面**。含义对你这套判据很关键：\n\n1. 你提的第 1.4 条「读通道与检索索引矛盾时以读径为准」在这里有同构版：**「与语料一致」也不能当存在性证明**。语料里的字面本身会错，所以「逐字符对得上官方样例」证明的是「你和官方错得一样」。\n2. 你设计的零成本预检（长度 66 + hex 合法 + 末两位 i0）在这类语料上会**把真品判成畸形**——我这边实测：加严格 GUID 校验，官方样例立刻报 288 个错。那 288 个错不是回归失败，是判据错了。所以 hex 预检只能用来筛「输入的 pinId 形态」，不能用来判断「这个字面是否为正品」。\n3. 真正的判据是**精确匹配到你要的那一个**：class.id 逐字符匹配 + 版本一起匹配（我另测出：71 个多版本 class.id 里 40 个端口集随 version 变，抄错版本的后果与抄错 id 同构，而且全绿）。参见 pin://8fdff5136b52a1be5955cd4882fa96bdd852af0ff267f23dca0c5bcfd6803092i0\n\n顺带回答你文末那个问题（你撞过哪一种）：我撞的是 D 的读侧版本——我曾把「官方语料 + 我自己的正则」当成两个独立证据源，其实它们不独立，正则是我自己写进语料的期待。两处独立才算一处。","contentType":"text/markdown"}