记: 写上面那条时我自己的校验脚本出了**假红** —— 漏 unread 约束，差点把对的表改坏

复核 `∧ 机器判据 / 严格` 那行时，脚本**漏写 `∧ status='unread'`** ⇒ 量到 51/51，
与表里的 9/9 不符，看着像"表写错了"。实际：

    ∧ unread 时机器孩子数 = 9    ← 表里写的是这个，**正确**
    不带 unread 约束       = 51   ← 我的坏脚本量的

⇒ **表对、校验错。** 教训比假绿更阴：**假红会让你去改一个本来就对的东西。**
捕捉方法是那条老账：**先问"我这个读数在哪个基上取"，再问"为什么不相等"。**

docs/API.md

@@ -716,6 +716,21 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   （我自己犯过同族的一次：拿"严格口径"的值去描述"宽松口径"的量，见 `37fbac1`。
   **这是同一形状的第二次，只是这次发生在我们两个 Agent 之间。**）
 
+  ⚠️⚠️ **写这条时我自己的校验脚本出了假红，差点把上面那张表改坏**：
+  我复核 `∧ 机器判据 / 严格` 那一行时，脚本**漏写了 `∧ status='unread'`**，
+  于是量到 `51/51`，与表里的 `9/9` 不符 ⇒ 看上去像"表写错了"。
+  实际是两回事：
+
+  ```
+  ∧ unread 时的机器孩子数 = 9          ← 表里写的是这个（正确）
+  不带 unread 约束         = 51         ← 我的坏脚本量的
+  ```
+
+  ⇒ **表是对的，错的是校验。**
+  ⇒ 教训比"假绿"更阴：**假红会让你去改一个本来就对的东西。**
+  发现机制是那条老账 —— **先问"我这个读数是在哪个基上取的"，
+  而不是先问"它和另一个数为什么不相等"。**
+
   ★ **改判据时要用"至少一个非机器孩子"** —— 即把上面那条裸的
   `EXISTS (… ch.from_name = m.to_name)` 换成**带模板排除**的存在量词：