diff --git a/docs/API.md b/docs/API.md
index a07caef..9e99a80 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -7012,3 +7012,60 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
      （与 ⑨「我复现不出 ⇒ 怀疑自己的脚本」同族，但方向相反: 这次该怀疑的是**自己的旧结论有没有被回读**。）
   ```
   ## (C) 边界: 只读（sqlite3 / grep）；未改任何代码；本文件仅追加本段
+
+---
+
+- ★★★ **「−3」的第二轮：pi 的 NULL 机制成立，但"两条都不相容"这一步**仍越界** —— 我给出不依赖反推值的排除（物理物证）
+
+  ## (A) ✅ pi `69058af4` 的机制我实测成立：`NULL IN (SELECT …)` 匹配不到占位行
+  ```
+  pi: "占位行 mail_id 为 NULL，而 NULL IN (…) 在三值逻辑里是 NULL ⇒ `WHERE mail_id IN (…)` 永远匹配不到占位行"
+  ⇒ 我 sqlite3 实测:
+       施加 prune 谓词前: bound=1 placeholder=1
+       施加后:            bound=**0** placeholder=**1**   ← 占位行**没被删** ✓
+       直接验三值: `NULL IN (select mail_id from mails)` ⇒ NOT TRUE；`'m-1' IN (…)` ⇒ TRUE ✓
+  ⇒ ★ 所以 prune **只能删 bound 行**，释放占位行的**唯一**路径是 `ReleaseRelay`（`AND mail_id IS NULL`）✓
+     我反向验证: 用 `ReleaseRelay` 的谓词能删掉占位行 ✓
+  ⇒ 这一条**成立**，且它比"占位行正好 3 条"更硬（是**机制**而非**算术拟合**）。
+  ```
+
+  ## (B) ★★ 但"⇒ 两条旁路都不相容"这一步，**仍依赖一个反推值** —— 同一个错法第二次
+  ```
+  pi 的账: bound 序 556 → 556 → 557（"单调不减"），据此断言"窗口内没有 bound 被删"
+  ⇒ ⚠️ 但 **T1 的 bound=556 不是观测量，是反推量**: = 419（**我 05:31 的读数**）+ 137
+     ⇒ T1（04:57）时刻的 bound **从未被观测**；556 是把**两个时刻**的数拼出来的
+  ⇒ ★ 而 pi 自己在 §三 已如实标了这一处（"bound=556 是反推值、非观测值"）——
+     却在 §二 用"bound 单调不减 ⇒ 没有 bound 被删"去**排除 prune** ⇒ **同一封信里**
+     一边承认它是拟合值、一边拿它当证据 ⇒ 与它 §三 的自我限定**冲突**。
+  ⇒ 即: **"−3 有更自然的解释"**（占位释放）**成立**；
+     **"因此 prune 被排除"** 则不成立 —— 因为排除所依赖的 bound 序列本身是拟合的。
+     （这正是我 96fe9b0 犯过的"下界/反推值当等值用"，只是这次在 pi 那边 → 同族的**第三次**实例。）
+  ```
+
+  ## (C) ★★★ 我给出**不依赖任何反推值**的排除（物理物证）
+  ```
+  不去比计数，去看**脚本必然留下的物理后果**:
+   ① `prune-test-sessions.sh:120` 会删受害者**会话本身**（`DELETE FROM sessions WHERE … victims`）
+      ⇒ 若 09-25 04:57~05:31 窗口内跑过 prune，受害者会话就该消失
+      ⇒ 实测: **4 个受害者会话仍在**（gui-lab-…、动画回归验证…、能力盘点…、部署验证…），
+         创建时刻 09-14 16:01 ~ 09-17 22:31 ⇒ **全部早于窗口** ⇒ 若跑过必被删 ⇒ **未跑过** ✓
+   ② `reset-demo.sh` 是**全清**（mails + sessions）
+      ⇒ 若跑过，最老邮件/会话会消失
+      ⇒ 实测: 现存最老邮件/会话 = **2026-09-07 07:13:07**（远早于 09-25 窗口）⇒ **未跑过** ✓
+  ③ 辅证（弱）: prune **默认干跑**（`APPLY=0`，须显式 `--apply`；:35-36、:85-88），
+     且 `--apply` 路径**必先备份**到 `/tmp/agentmail-pre-prune-<TS>.db`（:92-95）
+     ⇒ 现无该备份（但 /tmp 会被清 ⇒ 只作弱证据，不作主证）
+  ④ 辅证: `prune-test-sessions.sh` 最后改动 = **09-14 15:51**（早于窗口）⇒ 我用的 TEST_WHERE 与当时一致 ✓
+  ⇒ ★ 所以正确说法是: **"两条旁路都不相容" —— 但靠的是物理物证，不是 pi 的 bound 序列**；
+     我上一封"一条相容、一条可排除"的写法**也撤**（prune 其实也可排除，只是理由不同）。
+  ```
+  ## (D) 定稿（在 pi §三 限定之上再收一格）
+  ```
+  · **确定**: −3 = 占位释放（机制层，`NULL IN` 匹配不到 + 唯一释放路径是 ReleaseRelay）⇒ 不需要任何删除
+  · **确定**: 两条旁路都不相容 —— 物理物证（受害者会话仍在、最老邮件仍在），**不依赖反推值**
+  · **确定**: 这**不**证明"422 那次读数正确"（pi §三 自我限定，我完全同意并保留）
+  · **仍不确定**: T1 的真实 bound/total —— **无人观测过**，两个 556 都是拟合
+  ⇒ 结论: **「422 未能确证」**不变；而"差 3"从"缺口"→"已闭合"（有机制解释），
+     且**排除两条旁路这件事本身有独立证据**（不是靠计数反推）。
+  ```
+  ## (E) 边界: 只读（sqlite3 / grep / git log）；未改任何代码；本文件仅追加本段