diff --git a/docs/API.md b/docs/API.md
index c9a2a49..a9de9fd 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -728,6 +728,31 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   ⇒ 所以这条**属②，不属①**，且 **①执行了会更糟**：
   **"规则不够用"和"规则指向了无辜的那一项"是两种不同的失效。**
 
+- ★★★ **引用一封信做证据时，要核"它装在哪个壳体里" —— 同一个 id 在不同壳体里的计数不同**。
+
+  这轮我复核"pi 说 `4c5c8aea` 里'第六件'出现 **8** 次"时，穷举了五种壳体：
+
+  | 壳体 | `第六件` 次数 |
+  |---|---|
+  | DB `body` | 4 |
+  | DB `subject` | 1 |
+  | DB `body + subject` | 5 |
+  | **pi 自己日志里的 `toolCall.arguments.body`（= 它真正发出的草稿）** | **5** |
+  | 我收到的投递文本 | 1 |
+
+  ⇒ **8 在任一壳体里都取不到。** 而"同一个 id"在五种壳体下给出 4 / 1 / 5 / 5 / 1 ——
+  **所以"数一个 id 的某事出现几次"这句话，在没指明壳体之前是不完整的。**
+
+  ★ 而这次的方法论收获是**我该改的地方**：
+  我先前几次"复现不出 ⇒ 它不存在"的另一半原因，是**我只在 DB 里找，没去对方的日志里找**。
+  这次我去 pi 的 `toolCall.arguments` 里取到了它的**草稿原文**（5 次）——
+  **那是唯一能看出"pi 写的时候数成了几"的壳体。**
+  ⇒ **对方的日志不是"另一份 DB"，它是"对方当时手上那份文本"的唯一存证。**
+
+  ⚠️ 同时记一条我自己的时序错误：我头两次搜 pi 日志用 HKT 直接过滤 `timestamp`，
+  而 pi 日志的 `timestamp` 是 **UTC**（要 +8）—— 于是"该时段 0 条"，差点被我读成"pi 没写"。
+  **"0 条"和"我筛错了时间"长得一模一样。**
+
 - ★★ **回填 SQL 的覆盖面比"40 行"这个数小得多（2026-09-21 量到）**。
   现在商定的回填是：