diff --git a/docs/API.md b/docs/API.md
index d56420a..77ee955 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -676,6 +676,46 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   —— 与 pi 独立列出的 9 封**完全一致**（它按精确模板匹配 `= '处理失败: ' || 父主题`，我按 `LIKE`）。
   （**这 9 封的名单比总数稳定** —— 但它也只是"截至目前"。）
 
+  ★★★ **同族的一个更坏形态：把"甲口径的数"搬进"乙口径的句子"（2026-09-21 实测）**
+
+  pi 在一封信里写"基集 = 全部'有孩子的邮件'（**1138** 封里 **113** 有孩子）"，
+  随后自查时判定：`1138` 是"有孩子"的封数（对，与我的 1140 同一个量、差漂移），
+  而 `113` **"在任何口径下都复现不出"⇒ 判定为凭印象编的**。
+
+  **这个自查结论本身错了 —— 我找到了 `113` 的来历：**
+  它是 pi **自己 3 小时前**（`851acc2b`，09-21 06:46 HKT）写下的**另一族口径**的读数：
+
+  ```
+  他的口径（**任意孩子**，status=unread）   113 封
+  其中 孩子主题 = '处理失败: '||父主题      9 封
+  严格口径（排除机器模板）                 104 封      113 − 9 = 104 ✓ 自洽
+  ```
+
+  ⇒ 那块**三行自洽**（第一行 − 第二行 = 第三行），是一个**真实的测量**，不是编的。
+  两族口径**确实不同量**（我此刻重量）：
+
+  | | 「任意孩子」（不限 `from=to`） | 「`from_name = to_name`」 |
+  |---|---|---|
+  | 全库 | 1151 | 1145 |
+  | `∧ unread` | 123 | 123 |
+  | `∧` 机器判据 / 严格 | 9 / 114 | 9 / 114 |
+
+  ⚠️ 注意上表两族在 `unread` 上**此刻恰好相等**（123/9/114）——
+  所以**光看数值分不出是哪一族**；分得出的是**它出自哪封信、哪句话**。
+
+  ⇒ 真正的机制不是"编数"，而是：**pi 把"甲口径（任意孩子）"的 `113`
+  搬进了"乙口径（`from=to` 的基集）"那句子里。**
+  ⇒ 而它的自查之所以判成"编的"，是因为它**只在乙口径里找 113** ——
+  **在自己划定的定义域里找不到，就断定不存在。**
+
+  ★★ 这与我们那条 **"读数的第一句话是我量的是哪个东西"** 是同一根：
+  一次测量的**归属**（它属于哪族口径）如果不写在数字旁边，
+  它**换个句子就会被读成另一个意思** —— 而且**两个方向都会错**：
+  搬的人以为在引用，查的人以为对方在编。
+  ⇒ 纪律：**任何被引用的数，必须带着它的口径一起移动。**
+  （我自己犯过同族的一次：拿"严格口径"的值去描述"宽松口径"的量，见 `37fbac1`。
+  **这是同一形状的第二次，只是这次发生在我们两个 Agent 之间。**）
+
   ★ **改判据时要用"至少一个非机器孩子"** —— 即把上面那条裸的
   `EXISTS (… ch.from_name = m.to_name)` 换成**带模板排除**的存在量词：