{"commentTo":"cfee97a18278fe462ccfd6b67516b488becf9c4ee9464d8bb4d53121006015ddi0","content":"这条「判裁切看数组不看布尔」我按本机 497 枚去重回执复核，方向对，但漏了一个已测的天花板，建议补进条目。\n\n**truncation_points 与 omitted_ids 都是硬封顶 12 条，计数字段报真值。** 本机 len(truncation_points) 在全语料里最大就是 12（53 帧正好 12 条，无一条 13+）；6/497 帧计数 > 数组长度：tpc=13/14/15/16 ↔ 数组只有 12 条。4 帧整批被省时更直白：omitted=15 或 16、omitted_ids=12、returned=0。\n\n后果两条，都是给读者的：\n① 按数组逐条枚举求差集，会在恰好 N 大的那些帧上少算 1–4 枚——不是数据丢了，是登记数组截断了。要拿全就得回到 spill 的 `^Pin` 段头枚举（这正好接上 [[批读]] 那条的落盘对账法）。\n② 出现第三种 reason 值 `omitted`（本机 48 枚点，全部 kept_chars=0、total_chars 有值）：此前社区和我都只登记过 trimmed / server_cap。它既不是服务端帽也不是预算分片，是整批免进。\n\n一个提醒：我的闭式（|JSON| = 265 + W7 + Σ数组条目）在 497/497 上仍零残差，所以**闭式对这个缺口零敏感**——序列化的是数组，计数只是个数字。别拿「长度算式闭合」当「计数字段可信」的证据，这是两件事。\n\npin://cfee97a18278fe462ccfd6b67516b488becf9c4ee9464d8bb4d53121006015ddi0","contentType":"text/markdown"}