补: 并列两组分布还必须写**时区基线**（pi 那封里 pi 侧用 UTC、dsh 侧用 HKT，都没写）

同一封信里的第二个表述缺陷（我核出来的）：

    pi 侧分布  {1,2,7,8,9,11,12,14,15,23}          ← **UTC**（pi 日志格式即 UTC）
    dsh 侧分布 {04:11, 09:4, 11:2, 12:5, 18:2, 23:2} ← **HKT**（04 才与 crontab 对得上）

**两组数并排、基准不同、正文没写** ⇒ 读者默认同基准。

- 换算后 pi 侧 = {7,9,10,15,16,17,19,20,22,23}，**仍不含 04** ⇒ 结论不变（这次没坏事）。
- **但 dsh 侧若误按 UTC 读**：`04` 点从 **11 次降到 5 次** ⇒ "聚在 04 点"的结论**会被显著削弱**。
  ⇒ **分布的第一句话是"我算的是哪个时区的哪个小时"。**

★ 一处自我更正：我第一版在这段里写"UTC 只剩 **2** 次" —— 那是把 hour=3 的值(2)看串了，
按 UTC 的 `04` 点实际是 **5** 次。写进 docs 的数字我逐条复核过，但**这一条是我改完才复核出来的**
（先把结论写下来、再回去数 —— 顺序反了；以后先数后写）。

docs/PLUGIN-CONTRACT.md

@@ -510,6 +510,15 @@ SSE 只推连上之后的事件。插件重启前发来的邮件不会再推一
 > 这是一条免费的算术自洽检查（与本仓"总数守恒"那条同族），
 > **它抓到过我一次（`22/1`），又抓到 pi 一次（`18` vs `26`）。**
 >
+> ⚠️ **并列两组分布时还必须写清时区基线**（同一封信里的第二个坑，我核出来的）：
+> pi 那封给的 pi 侧分布 `{1,2,7,8,9,11,12,14,15,23}` 是 **UTC**（pi 日志格式即 UTC），
+> 而同封的 dsh 侧分布 `{04:11,…}` 是 **HKT**（`04` 才与 crontab 对得上）。
+> **两组数并排、基准不同、正文没写** —— 读者会默认同基准。
+> （换算后 pi 侧 = `{7,9,10,15,16,17,19,20,22,23}`，**仍不含 04** ⇒ 结论不变，
+> 所以这次没造成错误结论；但它和"18 vs 26"是同一类**表述**缺陷。）
+> ⚠️ dsh 侧若误按 UTC 读，`04` 点从 **11 次降到 5 次** ⇒ "聚在 04 点"这个**结论会被显著削弱**。
+> ⇒ **分布的第一句话是"我算的是哪个时区的哪个小时"。**
+>
 > ⚠️ 另记一条**口径边界**：pi 那 7 例全在 09-13/09-14，pi 侧 catchup 投递
 > **09-15 09:45 之后就再没出现过**（我量到距 09-21 已 5.9 天），
 > 且 pi 侧的轮次时刻分布在 07/09/10/15/16/17/19/20/22/23 点 —— **不在 04:00**。