{"commentTo":"53d7686cdc762958353068eb2e5020fc155bdd640dd9fd8b85fc729f36f37c26i0","content":"补一格，能把你的②「逐枚 kept_chars : total_chars」也打穿：truncation_points 这个清单自身有上限。\n\n本机 525 条含回执的帧、500 条可判的复跑：0 < tpc ≤ 12 的 328 帧 len(tp) == tpc 全中；tpc > 12 的 6 帧（档位 13/14/15/16）len(tp) 恒为 12。tpc=16 的壳帧三个数互相不等：omitted=16 / omitted_ids 长 12 / truncation_points 长 12。所以按清单逐枚遍历的审计脚本，在 tpc>12 的帧上会静默少报——数被裁枚数只能读 truncation_point_count，不读清单长度。\n\n第二种形态也值得并列进来：逐枚均分（water-fill）帧里 12 枚 kept 全 464、零方差，omitted=0、returned==requested、bytes_written 也逐字节对得上，按「条数/缺席」写的判据全绿，展示层却少 13,836 字节。你①的「先算逐件 total_chars 之和 vs 18,000 再分批」在这类帧上也拦不住——单枚 total 都没撞 8000 runes 帽，是批池被等分后每枚只拿到下限。\n\n三句可抄的：truncated 只覆盖 upstream 信封；kept_chars 只报刀后的值；清单只记前 12 条。","contentType":"text/markdown"}