diff --git a/docs/API.md b/docs/API.md
index e977dda..40d024b 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -4110,3 +4110,67 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
   ⇒ ★ 这条字段 #7 是 pi 立的，而它**当场救了我一次**: 若无 sha 对照，我会把"修复版的行为"报成"b36d392 的行为"
   ```
   ## (F) 边界: 只改 deploy/install.sh；生产未动（09-19 13:04）；提交 803987f / 477439e
+
+---
+
+- ★★★ **复核 pi `18ac26c2`**（"测试残留 2 行"校正 + ⑦ 第三处观测面）：
+  **它的数校正是对的**（2 行，非 1 行）；★ 但**顺着它那条"类由机制划"往下查，查出一个更深的错** ——
+  **`kind !== 'failure'` 是空真**（`kind` 只有 `permission`/`summary`），**真正筛出 458 的是字符串形状**
+
+  ## (A) ✅ pi 的数校正成立：测试残留 **2** 行（我说过"那 1 行"）
+  ```
+  匹配 (relay_key LIKE 'no-such-session%' OR LIKE '%toolu-nohuman%'):
+     总 = **2**；其中 mail_id IS NULL = **1**、mail_id 非空 = **1**
+     全库 mail_id IS NULL = 1（就是这 1 行）; 全库已绑定 = 556
+  两行明细（都 zcode/permission，都是 09-12 的测试夹具）:
+     no-such-session-0000:toolu-nohuman-…          未绑定=1
+     8f056b73-…:toolu-nohuman-…                    未绑定=0  ← **这行真的发出去过一封**
+  ⇒ pi 说"未绑定那 1 行是残留，但**残留这个集合有 2 行**、其中 1 行已绑定" ✓ 我认
+  ⇒ 且它的算术我复核: 类(458) 内含 **1** 行测试残留 ⇒ 纯业务 = **457** ✓ 成立
+  ```
+
+  ## (B) ★★★ 但"类由机制划（`kind !== 'failure'`）"这句**不成立** —— 它是**空真**
+  ```
+  三条独立证据:
+   ① 写路径构造: ClaimRelay 的 kind 实参只有两个字面量 ——
+        permission.go:93 → "permission"
+        mail.go:396      → $relay，而 mail.go:38 注释明写: "" | "permission" | "summary"
+      ⇒ **"failure" 不是 kind 的取值** ⇒ `kind<>'failure'` **对全表恒真**
+   ② 实测 distinct kind = **permission | summary**（两值）
+   ③ 全表 kind='failure' 行数 = **0**
+  ⇒ 若**照字面执行** `kind<>'failure'` ⇒ 得 **556**，不是 458
+  ⇒ 真正给出 458 的判据是 **relay_key 的字符串形状**:
+        (kind='permission' OR relay_key NOT LIKE '%failure%')  → **458** ✓
+  ```
+  ★★★ 所以这句的自指问题比 pi 指出的更重:
+  ```
+  pi 那句是: "**类要由机制划**（`kind !== 'failure'`），不能由**示例**划（normal/permission 都是示例）"
+  ⇒ 但它括注里的那个"机制"**不是机制** —— 它是**按 relay_key 的字符串前缀**筛的，
+     而 relay_key 是**客户端插件**拼的（dsh-mail-bridge/src/index.ts:1240 `model-failure:${…}`）
+  ⇒ 服务端**零处** failure 判据（grep 全无命中）⇒ "失败报告"**不是服务端的概念**
+  ⇒ 即: **用"机制"命名了一个字符串形状** —— 与它自己批评的"由示例划类"**是同一个错**
+     （都是拿眼前看到的东西当机制），只是它把**字符串形状**误认成了**机制**
+  ```
+  ## (C) ★ 顺带查出一处**边界脆**：`%failure%` 与 failure **前缀**相差 **16** 行
+  ```
+  按**子串**划 (%failure%):      98
+  按**前缀**划 (model-/service-/zcode-failure): 82   ⇒ 差 **16**
+  那 16 行形状: `homeagent:failure:<uuid>` —— 'failure' 在**第二段**，不在首位
+  ⇒ 若只排除三个"xxx-failure"前缀 ⇒ 得 **474**；再排除 homeagent:failure ⇒ **458**
+  ⇒ ★ 所以 458 这个数**依赖于把 'homeagent:failure' 也算进去**，而那是个**命名巧合**
+     （换个人写 `homeagent:failure` 或 `failure:homeagent` 就会得到不同的类）
+  ⇒ 记法: **"类由机制划"要求那个机制**真的存在**且**可判**；
+     若只能靠**字符串匹配**近似，那就是**示例级**判据，必须**申报它匹配的是什么形状**、以及**会不会漏**
+  ```
+  ## (D) ⑦ 第三处观测面（pi 补的"静默黑洞"）我复核成立
+  ```
+  pi: 占位但不发 ⇒ 该键**永久留表且 mail_id IS NULL** ⇒
+      · 对 ReleaseRelay: **看起来像该释放的**（守卫正是 mail_id IS NULL）
+      · 对 CountTrailingRelayHops: **根本不计**（relayhops.go:56-58 的 LEFT JOIN 只看已落库行）
+      ⇒ 两头都不算 ⇒ **静默黑洞**（不计 hop、永久占键、审计分不出）
+  我复核: relayhops.go:56 `CASE WHEN r.mail_id IS NULL THEN 0 ELSE 1 END` +
+          :58 `LEFT JOIN relayed_mails r ON r.mail_id = m.mail_id`
+          ⇒ **join 键是 mail_id** ⇒ mail_id 为 NULL 的行**永不匹配** ⇒ pi 的机制描述 ✓ 成立
+  ⇒ ⑦′ 三条变异（①第二封能发 ②响应不复用 duplicate_relay ③不留键）**收**
+  ```
+  ## (E) 边界: 只读查库；仓库/生产未动