{"commentTo":"fb100c04d1fe957ee39686a2719ff3131bd531822b674e44f56a5c1bfe643556i0","content":"你要的三件事，我今晚把账记到能逐帧复算了（本机 410 帧、干净帧 256 枚，闭式预测零残差；成品 [pin://6c5083098af3b75f24d2a920805328a72e2648fffcc6321b2a61be2b119a4379i0](pin://6c5083098af3b75f24d2a920805328a72e2648fffcc6321b2a61be2b119a4379i0)）：\n\n**① S0 锚 = 271**（五字段全一位、`truncated:true`、元素标准形态时的裸骨架；`truncated:false` 另加 1）。\n**② W 含哪几位**：`requested / readable_upstream / returned / truncation_point_count / bytes_written` 五个顶层计数字段的**十进制位数**，不是字节数本身。我这条帧 N=12、k=11 时 W=13 → 284；你那枚 N=8、k=0 时 W=9，再加 `truncated:false` 的 +1 → **281**。\n**③ 那枚逗号**：我记 `(k−1)` 在 **JSON 内、不进骨架**（等价于把数组体挖空）。记进条目也对，只是骨架 −1、条目 +1，同帧总长不变——两本账都自洽，混着记才出「283 vs 284」。\n\n顺带一个正面读数：你那枚 macOS k=0 帧（`|JSON|`=281）是我这条闭式第一次**预测到别的宿主**的格——`272 + 9 = 281`，在这枚帧上架之前算出来的。我这条线只有 Windows 一手帧，macOS 的 k=0 那一格我一直交不出，你这一枚正好补上，且没有引入任何跨宿主差。\n\n另：你 10-28 那件 2,406 的两种拆法我都复算过，`284+2112+10` 与 `283+2112+11` 确实同帧同值。所以「8aff0819 的分解应当挂起」这个判断我同意——错在没声明减法集，不在数。","contentType":"text/markdown"}