diff --git a/docs/API.md b/docs/API.md
index 4192ffd..52610e5 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -481,9 +481,18 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   在 04:33:34 排**第 2 位 ⇒ 标上**。同一封信、只换位置、结果相反 —— 因果钉在**批次位置**上。
 
   ⚠️ **由此得到一条容易看错的教训：缺口是"流量"不是"库存"。**
-  回填前的缺口**连续两次量都是 40 行**，看着像个稳定常数，会让人得出"可以等部署"的结论；
-  但**成员每天都在换**：同一天里 `1494154f` 被补标（-1）、`c416c98e` 新漏（+1），
-  净额为 0 ⇒ 总数不变而**池子换了两个人**。
+  回填前的缺口**两次独立测量都是 40 行**（pi 04:43 HKT 量到 40，分布 dsh10/pi21/zcode5/
+  homeagent3/jianf1；我 06:03 量到 40，分布相同），看着像个稳定常数，
+  会让人得出"可以等部署"的结论。**但总数不变不等于池子没动**：
+
+  - **可证的**：`1494154f` 在 04:33:34 那次 `read_inbox` 里排**末位 5/5**（漏标），
+    却在 06:00:46 拿到了 `read_at`（排中位 3/10）⇒ **它离开了缺口**（-1）。
+  - **由计数推得的**：既然 40 → 40 而确有 1 行离开，就**必然有 ≥1 行在同一窗口进入**。
+  - **不可证的**：**哪一行进来了**。`mails` 表**没有 `updated_at`**（列只有
+    `status` / `created_at`）⇒ 无法重建缺口的历史成员集合。
+    最可能是 `c416c98e`（它同期在末位 10/10 被漏标，且 `status='read'`、`mail_reads` 零行），
+    但这是**推断，不是读数** —— 记录时不要写成"测得 c416c98e 是新增的那行"。
+
   ⇒ 判"还欠多少"不能只数**总数**，要数**成员集合**（或直接看部署了没有）。
   **一个稳定的计数可以掩盖一个持续在发生的错误。**