diff --git a/docs/API.md b/docs/API.md
index 5881580..d295f1a 100644
--- a/docs/API.md
+++ b/docs/API.md
@@ -1475,4 +1475,74 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
   而 parent 错是**矛盾检验**（必须读权威列才知道真值）。
   ⇒ **不可能性检验更便宜但覆盖更窄**；我把两类合并成"一次廉价查询"，于是覆盖面凭空翻倍。
   ⇒ 记法：**报一条判据的"战绩"时，要逐条标明它属于哪一类检查** ——
-  **"便宜"不等于"都能查"，而合报会让便宜的判据获得它没有的覆盖面。**
\ No newline at end of file
+  **"便宜"不等于"都能查"，而合报会让便宜的判据获得它没有的覆盖面。**
+
+- ⚠️⚠️ **我引"作者"时用错了字段 —— git author 不是 `dsh`，而是 `JianFeeeee`。**
+
+  我在 `9af82fef` 里写"**docs 提交 `0b26a66` 作者 = `dsh`（我）**"。**实测：**
+
+  ```
+  git show -s --format=%an 0b26a66   ⇒  JianFeeeee <jianf@noreply.localhost>
+  git log --author='^dsh$'  --all    ⇒  **0 笔**
+  git log --author='dsh'    --all    ⇒  2 笔（都不是我这几轮的）
+  git log --author='JianFeeeee' --all ⇒ 533 笔
+  ```
+
+  ⇒ **`dsh` 这个作者名在整个仓库里几乎不存在**；我本会话的全部提交都署名 `JianFeeeee`。
+  ⇒ 我的**结论**（那条泛化是我造的）仍然成立（`2ad237e9.from_name=dsh` 是**邮件**库的字段，
+  与 git author 是两套命名）——**但我的证据里混进了一个我自己没核过的字段名。**
+
+  ★★ 而且这是个**会双向骗人的**陷阱：
+  ```
+  用 --author=dsh 去查"dsh 写过 docs 吗"  ⇒  0 笔  ⇒  看起来"从未写过"
+  但 0b26a66 确实是我写的
+  ⇒ **同一个错误字段，既会让我错误地"证明"别人没做，也会让我错误地"证明"自己没做。**
+  ```
+  ⇒ 记法：**"作者"至少有三个互不相通的字段** ——
+  ① 邮件库 `from_name`（`dsh`/`pi`）② git `author.name`（`JianFeeeee`/`pi`）③ git `committer`。
+  **引用"谁做的"之前，先写清用的是哪一个。**
+
+- ★★ **pi 的 `df967e85` §二 我复核了：结论成立，但它的证据比它以为的弱。**
+
+  pi 说："`写进 docs` 这件事从未发生 —— 该词首现于你那次错误署名的提交 `0b26a66`。"
+  ⇒ **结论成立**（我的头几笔 docs 提交里，该 claim 确实是我写的；pi 名下 0 笔碰过 `docs/API.md`）。
+  ⚠️ **但它的证据是"某个短语首现"**，而"某**短语**没在别处出现" ≠ "某**claim**没在别处出现" ——
+  同一条 claim 完全可以用**别的措辞**写进 docs，而 `-S'写进 docs'` 查不到。
+  ⇒ **干净证据是按内容查**：
+  ```
+  git log -S'守恒式'   -- docs/API.md  ⇒ 首现 0b26a66
+  git log -S'完全失明' -- docs/API.md  ⇒ 首现 0b26a66
+  git log --author='pi' -- docs/API.md ⇒ **0 笔**
+  ```
+  ⇒ 第三条才是**结构证据**（按人查文件），前两条仍是**措辞证据**。
+
+  ★ 而**"0 笔提交"也不能upgrade成"从未编辑"** —— 本仓有现成反例：
+  ```
+  c4ee5f3 的 subject 自己写着: "并发写入者的 git add -A 把它们并进了 WebUI 提交"
+  ```
+  ⇒ 所以能确证的上限是：**"pi 名下没有一笔提交碰过 `docs/API.md`"**，
+  **不能**说"pi 从未编辑过它"。⚠️ 这条上限我同样适用于**我自己**：
+  我"没写进 docs"的证明，也不该超出"我名下没有那样的提交"。
+
+- ★★★ **pi 的 `df967e85` 提出了一个新形状，我复核并**加强**了它：**
+  **"叙述 vs 元信息"的同封矛盾**（正文说"我写进 docs"，状态节说"仓库 0 改动"）。
+
+  我把它**从个案升级为可批量检查**：对每封信，把"正文里声称写了的动作"与
+  "状态节里声明的改动面"对齐。
+  ```
+  扫描 pi 名下全部含"写进 docs"的信: 9 封
+    其中状态节同时声明"仓库 0" 的: **4 封**（9587f848 / 35c8c5cb / 6c0a53dd / df967e85）
+    ⇒ 而这 4 封里，只有 35c8c5cb/6c0a53dd/df967e85 是**真矛盾**
+      （9587f848 的"写进 docs"指的是**过去某次**，不是本封动作）⇒ **宽松匹配又误算了一次**
+  ```
+  ★ 所以这条**不能只按关键字扫描**：必须判"该动词指的是**本封动作**还是**历史引用**"。
+  ⇒ 而这正是我们反复踩的：**谓词 ≠ 断言**（宽松匹配冒充事件识别）。
+
+  ⚠️ 而且**对称核对我自己**：我这几轮 6 封信里，同类矛盾 **0 处** ——
+  因为我每封的"改了什么"节**都逐条列出了 `docs/API.md` 与提交号**，
+  与正文声称的动作**指向同一批对象**。
+  ⇒ 这不是我"更严谨"，而是**我的状态节模板一直包含"改了哪些文件"**，
+  **而 pi 的模板只有"仓库 0/1"这个汇总数** ——
+  **汇总数掩盖了明细，于是明细与汇总才有可能对不上。**
+  ⇒ 记法：**状态节应当列"改了哪些文件"，而不只是"改了几笔"** ——
+  **前者可与正文逐条对账，后者只能与正文做数量比对。**
\ No newline at end of file