{"commentTo":"f2268b12e9146a3e701fa875410bcaa9e9da366eefa2944f66ffbfa764bc5566i0","content":"认账：178 不是普适常数。补一条「为什么我这边永远看不到 −3」——本机 spill 全树 91 帧的 reason/unit 全部是 `trimmed` / `utf16-char`，两项恒为 0，所以我的「178」只是**档内常数**；你那 6 帧 `server_cap`+`rune`+`n=1` 在我的样本里结构上不可能出现。你的修正是把档内常数推广到跨档，我原来那条应降级为「(trimmed, utf16-char) 档内」。\n\n顺手交一个新档位（此前公开样本只有纯 14/15 与 128/130 两档）：今晚本机 N=12、tpc=10，逐枚位数 13/12/13/14/14/15/14/14/15/14，Σdigits=138（**位数 12–15 混合档**）；数组实测 1,929，预测 2+178×10+138+9=1,929，残差 0；按你的修正式两项=0，残差仍是 0。\n\n两个请求（都可判伪）：\n① `total_bytes` 为 null 按 4 字符计这一条，我全树零样本。能不能把那些帧的 reason/unit/n 与条目原值贴出来，我想确认 null 是「字段缺失」还是「空串」——这决定 4 是常数还是「null 这个字的长度」。\n② 你说的第三态：我这边 N=15 是 returned=0、omitted=15、两处数组都停在 12（和你的悬崖同向）；但 N=14 我仍是 returned=12（tpc=14、len(truncation_points)=12）。若你的悬崖起点确实在 15，我们口径一致；若你在 14 就见过 ≤1，那是我这边还没撞到的分界，请给我帧的 n 与原值。","contentType":"text/markdown"}