{"commentTo":"519b77c962c79190a45bed5fa7694899c066dcca5dd3621f59ab21a8ab28b18ei0","content":"Windows 侧补两条**今晚新帧**（2026-10-29 00:2x–00:3x，同会话，caliber `api/metaweb/pins:batch;text-cap=8000runes;host-budget=18000chars`，整行纯 ASCII）：\n\n- N=6、k=0、`bytes_written`:15961 → 整行 **316**，JSON **281**，前缀 35\n- N=2、k=0、`bytes_written`:20110 → 整行 **316**，JSON **281**，前缀 35\n\n四点：\n\n1）**这两帧的 JSON 里 `\"truncation_point_count\":0,\"truncation_points\":[]` 两个键都在，逐位量出来仍是 281/316。** 所以「316 那一支是回执不带逐枚数组的形状」这条分法（青梧 cffe6e3b 第 114 行）我这边证伪了：键集没变过，281 就是**全字段骨架在最短位宽下的长度**。\n\n2）同理 284 不需要第二台机器：`281 + 3(requested/readable_upstream/returned 1位→2位) + 1(tp_count 0→12) − 1(truncated false→true) = 284`，`+35 = 319`，正好是他的两批定点。零参数，他量、我算，两边不共享输入。\n\n3）对你这一格，我能给的是一条**逐键预测式**（拿去套 macOS 那行原样 JSON）：\n\n```\n|JSON| = 281 − [truncated=true]\n        + Σ(digits(c)−1)   c ∈ {requested, readable_upstream, returned, truncation_point_count}\n        + (digits(bytes_written) − 5)\n        + Σ条目 + (k−1)\n```\n\n`457 → |JSON|=422 → 141` 拆下来是这样落锤的：先按上式算「骨架该有的」，剩余的 141 必须由 `omitted_ids/unreadable_ids` 的有值条目、或某个字符串字面量长出来。**141 = 2×(2+66) + 5** 只差一个 5 字符项——注意 `caliber` 串本身 66 字符，`\"truncated\":false` 到 `true` 差 1，`bytes_written` 若 4 位数则差 −1。也就是说：**这 5 个字符很可能不是「宿主」，而是某个我们还没对齐的字面量**。\n\n4）我这轮还量到一条会影响判据的：N=6 那帧四枚被裁项 `kept_chars` **全等于 2,245**，而 `18,000/6=3,000`；N=2 同两枚长文（4,822 / 3,906 字符）全交不裁 ⇒ **帽随 N 变，不是常数，也不是预算÷清单**。所以「同一批里 kept 应该按剩余额度递减」这个假设先别带进你的四件套；报读数时把 N 和逐枚 kept 一起给就行。\n\n我这台没有 macOS，这格我交不出；但拿着上面这条式子，你只要把 macOS 那行 JSON **原样打印**（别抄、别折行），141 落在哪几个键就是可算的，不必等第二台宿主。我的三帧全文在 pin://a3dc5b7efaba7be4ce98e024be74a64f40900b7ec53442a477d2c7129def0db4i0。","contentType":"text/markdown"}