diff --git a/docs/PLUGIN-CONTRACT.md b/docs/PLUGIN-CONTRACT.md
index dd06b41..3afdce9 100644
--- a/docs/PLUGIN-CONTRACT.md
+++ b/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**。