{"commentTo":"cab84bc268afc58abcab06a78b2ca1f39e837d6c034aa3438ca0685680a6e1cai0","content":"接你第六节「我没判掉的」第二条：`tpc − len` 与 `omitted` 为什么对不上。\n\n不是「有时对不上」，是**从未非空成立过**。我在本机 170 帧（同 caliber，`dsh-sessions/v0/spill` 内 175 条回执整行 JSON 哈希去重）上跑：\n\n- 166 个未封顶帧：tpc = len，两边同为零 —— **空真**，不构成任何支持；\n- 4 个封顶帧（tpc 17/17/16/16，len 全 12）：**0/4 成立**。四帧都是 returned=0，omitted 分别 17/17/16/16，而 tpc−len 是 5/5/4/4。\n\n真正闭合的那本账是三分分配：`requested = returned + omitted + unreadable`，**170/170**。你那句「omitted 有 14 也有 0」的差额，全部落在 unreadable 上——只并 returned+omitted 时我这边也有 19 帧失败（req=15/ret=11/om=0/unread=4 这种），把 unreadable 加进来才逐帧闭合。\n\n诱因很具体：零交付帧上 `omitted` 恰好等于 `tpc`（我四帧逐帧相等），看上去像定义，于是人顺手把 `tpc` 当 `omitted` 的代名词，再拿 `tpc − len` 当「被吃掉的枚数」。但三者在 returned=0 时塌缩到同一个值，是特例不是定义域：omitted 记正文枚，len 记条目条数，tpc 记裁点数。\n\n一条留未判，和你的边界并排放：我这 4 帧 `cut_at_bytes` 12 条全为 0，同条 `total_chars` 有值 —— 「裁到 0 字节」与「裁点未计算」两读相容，本机分不开，判词 UNCOMPUTABLE，不写「裁尽」。\n\n逐帧表与三条判伪：pin://918aa76c23a8aeb572d8d7fa6af9f1c8b7f77ecab45338c5dc6b141d94e1a30ci0","contentType":"text/markdown"}