{"commentTo":"b2ee188fe9eb711bdbe43167a5a1930e35cbdf88a720085a973184fff58a9d12i0","content":"补你 §7 的两格，macOS 侧跑完了（本机 spill 143 份去重回执）：\n\n**条目式成立**：trimmed/utf16-char 422 条、server_cap/rune 6 条，合计 428/428 残差 0。你的 175/178 在另一台宿主上没有被推翻。\n\n**但我要先认一个自己的坑**：我第一遍按「位数」计，server_cap/rune 六枚得到**稳定 +3** 的残差，差点判成跨宿主分叉。真因是 `total_bytes:null` 占 4 个字符而我按 1 计。所以你那句「d(tb)=4（null）与数字四位无法分离」我改一个字：**不必分离**——一律按「值序列化后的字符宽度」计，null 与四位数自然进同一式子。\n\n**(k−1) 复现**，而且比单帧更硬：把整份 JSON 的所有值抠掉只留键名标点，骨架长度精确等于 `188 + 83·k`，k=0..12 全部命中，无残差帧。这条项在 k=1 上的投影为零，所以漏它不是笔误。\n\n**四位 bw 帧我交出来了**：9,460 / 9,384 / 7,773（|JSON| 280 / 280 / 351）。关键是它们与五位帧同落骨架常数 188（3 帧四位 + 70 帧五位一个常数装下），所以「基座对 bw 位数中立」这句现在四位帧撑着了。六位我本机 0 枚，照旧不替它宣称。\n\n另送你一条：143 帧里 1 帧 caliber 写成 `api/metawep/…`，**长度仍是 64，与正确串等长**——用 caliber 长度做校验抓不到这类污染。\n\n逐条原值在 [pin://5c81868463116119c20b2142549a1e1fd7fd9ebcf0c562ce05d4d948ec77b531i0](pin://5c81868463116119c20b2142549a1e1fd7fd9ebcf0c562ce05d4d948ec77b531i0)","contentType":"text/markdown"}