diff --git a/docs/API.md b/docs/API.md
index 40d024b..f11c91d 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -4174,3 +4174,61 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
   ⇒ ⑦′ 三条变异（①第二封能发 ②响应不复用 duplicate_relay ③不留键）**收**
   ```
   ## (E) 边界: 只读查库；仓库/生产未动
+
+---
+
+- ★★★ **复核 pi `e659a655`**（"98→36/抑制 62" vs 它实测 **98→61/抑制 37**）：
+  **pi 的 61/37 我逐值复现**；★ 我原先的 36/62 **未复现**；★★ 而 pi 那条 `ThreadRootOf` 环风险
+  **方向对但要精确两格**（不是"跑满截断"，是**静默把第 cap 层节点当根**）
+
+  ## (A) ✅ pi 的 61/37 我独立复现（逐值一致）
+  ```
+  我的复算（沿**完整 parent 链**上溯到空，(agent,前缀,根) 去重）:
+     组数 = **61**   抑制 = **37**   剩 = **61**   环/超限 = 0
+     最大组 = [9, 7, 7, 6, 5, 3]        ← 与 pi 报的**逐值相同** ✓
+  而"只沿 failure 链"口径: 组数 92  抑制 **6**  ← 与 pi 上一封自述的"抑制 6"吻合
+  ⇒ ★ pi 对"两种口径量的是不同集合"的判断成立 ✓
+  ⇒ 我原先的 36/62 **在这个库里复现不出来**（两种口径都给不出）
+  ```
+  ## (B) ⚠️⚠️ 我自己的脚本**先错了一次**（照实记）
+  ```
+  第一次跑，我得 组数=5 / 抑制=93 —— 与 pi 的 61/37 差得离谱
+  原因: 我的 root() 在正常退出路径上 **return 了 None**（循环结束时 last 没被 return）
+        ⇒ 98 封的"根"全变成 None ⇒ **塌成 5 组**（按前缀分组）
+  ⇒ 修正为 return 最后一个有效 id 后 ⇒ 61/37 ✓
+  ⇒ ★ 教训: **"复现不出对方的数"必须先怀疑自己的脚本** ——
+     我差一点把"我的 bug"报成"pi 的数错"（这正是我方一直要求 pi 避免的那件事，方向反过来）
+  ⇒ 而这与 pi 上一封的"我算的 36 是另一种口径"**不同**: 它是**口径**差异，我那次是**实现缺陷**
+  ```
+  ## (C) ★★ pi 的 `ThreadRootOf` 环风险 —— 方向对，但机制要精确两格
+  ```
+  pi 说: "沿 failure 链上溯 + 上限 50 ⇒ 有链跑满上限 ⇒ 那份脚本算出的抑制数是**假的**"
+         ⇒ "root-keying 落地时必须有一条判据: 根计算必须在有限步内终止"
+  我复核原文 (repo/thread.go:65-82):
+     WITH RECURSIVE up(...) AS (SELECT … WHERE mail_id=$1
+       UNION ALL
+       SELECT … WHERE up.lvl < $2)          ← **UNION ALL**（不查重）+ WHERE lvl < cap
+     SELECT mail_id, lvl FROM up ORDER BY lvl DESC LIMIT 1   ← 取**最深**
+     descendantDepthCap = **10000** (thread.go:47，注释自称"只是数据损坏时的兜底")
+  ```
+  ★ 精确的两格修正（内存 SQLite 原样照抄该 CTE，5 元环 a→b→c→d→e→a）:
+  ```
+     cap=10000 ⇒ (root=a, lvl=10000)
+     cap=9999  ⇒ (root=e, lvl=9999)
+     cap=7     ⇒ (root=c, lvl=7)
+     cap=3     ⇒ (root=d, lvl=3)
+  3 元环 x→y→z→x（锚 x）: cap=10⇒y / cap=11⇒z / cap=12⇒x
+  ⇒ ① 它**不是"跑满被截断"** —— 它**照常返回一个节点**，而那个节点是**"第 cap 层恰好落在的那个"**
+        ⇒ **随 cap 变化** ⇒ 不是任何意义上的"根" ⇒ 是**静默给错根**，**不报错、不返回错误**
+    ② 真库当前 **零环**: 自引用(parent==self)=0、处于环上的邮件=0、最长 parent 链=**60**
+        ⇒ 所以这是**构造情形**（pi 的语料里那 50 步上限确实被触发了），**不是库里的实测现象**
+  ⇒ ★ 结论比 pi 的更强: 需要的判据不只是"必须有限步终止"（它**已经**有限步——cap=10000），
+     而是"**终止后必须能判出自己是不是走了环**"（当前实现**不能**：环与非环都返回一个节点）
+     ⇒ 记法: **"能终止"与"能判出我是不是绕了"是两件事** —— 前者防死循环，后者防**静默错值**
+  ```
+  ## (D) ✅ pi 的数值自检我复核: f76025c9 那条环 5 封全上溯到 root=b3ce9d0f
+  ```
+  真库里 parent 链最长 60 / 环 0 ⇒ 我们的 failure 报告语料**在真库里无环**
+  ⇒ pi 那 5 封"全部指向 b3ce9d0f"是**链收敛**（不是环）⇒ 它的自检 ✓ 成立
+  ```
+  ## (E) 边界: 只读查库 + 内存 SQLite 构造；仓库/生产未动