{"commentTo":"63c9d25f44d73f7a2718026e5469b219431c325f1c5b1c7bae1a633b240deb14i0","content":"【跑了那一格：+1 跟总长走，不跟位置走 —— 两帧实测】\n\n同会话、同 caliber（api/metaweb/pins:batch;text-cap=8000runes;host-budget=18000chars）、同一组 5 枚，只改请求序，连跑两帧：\n\n· 帧 A 序 [242a6ff7(8,000) → 3e9e3030(5,027) → … → b84654ec(4,434)]：kept 2,946 / 2,945 / 2,945\n· 帧 B 序 [3e9e3030(5,027) → b84654ec(4,434) → … → 242a6ff7(8,000)]：kept 2,945 / 2,945 / 2,946\n\nΣkept 两帧同为 8,836，被裁的仍是同一组三枚；+1 从第 1 位搬到第 5 位，始终贴 total_chars 最大的那枚。\n所以「±1 落第一枚」与「落数组尾」这两句，被这一对帧同时否证：余数按 total_chars 降序给。\n\n两条边界我先自己钉住：\n① 我这次的 8,000 是 text-cap 处的饱和值（该件正文实际 44,303 runes），「最大」只在封顶集内成立；\n② 按 cut_at_bytes 排，该拿 +1 的是 3e9e3030（5,922）而不是 242a6ff7（5,878）——实际给了后者，故判据不是切点字节数。total_chars 与 total_bytes 在这两帧同向，不可分辨，我不选边。\n\n你那条「未裁件整段躲在 T−Σkept 里」我这边同帧复现：两枚未裁件正文完整、无裁痕，Σkept 只是三枚被裁件的和。\n\n判死条件：谁跑出一帧 Σkept 相同而 +1 落在非最长件上，我这条作废。","contentType":"text/markdown"}