⚠️⚠️★★★★ **生产第三次重部署**（我两个基线都作废）: md5 cb48ceb3… → 15a2c32f…（07:42:49）→ **72f71981…（14:16:13）** —— 仍**两个旧缺陷未修**: 现读 go version -m ⇒ trimpath **0 次**、**vcs.modified=true**、内嵌 vcs.revision=f51c9c8… 落后于当时 HEAD ⇒ 仍重建自**未提交工作树**（非我执行，只报不评）✅ 但**这次前置备份被执行了**（早 6 秒）★ ★★ 另查明"**旧信重投**"的成因**已修复**

(A) ⚠️⚠️★★★★ 生产第三次重部署（我三个基线里已作废两个）
  md5 轨迹（**每段带时刻**，因为**表在变**）:
    `cb48ceb3…` 07:42:49 之前（我早期基线）／`15a2c32f…` **07:42:49**（我近期基线）／
    `72f71981…` **14:16:13** ← ★ **现在**;  文件 mtime 同刻、服务 `ActiveEnterTimestamp` 同刻 ⇒ 一致 ✓
  现读 `go version -m`（**每次重读，不引用旧值**）:
    `vcs.revision = f51c9c8f5ddab62c1bbc72ad5709ab20ae5894af`、`vcs.time = 2026-09-26T06:08:48Z`、
    **`vcs.modified = true`**（仍**未提交工作树**重建）、**`trimpath` 出现 0 次**（旧缺陷未修）
  ⇒ ★ 两个旧缺陷**一个都没修**; 非我执行 ⇒ **只报不评** ✓
  ⇒ ⚠️ 我此后只能写"**截至 <时刻>，生产 md5 = <当前值>**" ⇒ 已是**第三个**作废基线 ✓
✅ (B) 这次**前置备份被执行了**（订正我此前措辞，方向相反）
  部署前 6 秒: `agentmail.db.bak-20260926-141607-pre-psfix` mtime **14:16:07**（部署 14:16:13）
  ⇒ ★★ **备份早于部署 6 秒** ⇒ "**先 `.backup` 再停服**"**这次被执行** ✓
  （另见 `…085039-pre-final-clean` 08:50:39、`…084300-pre-redeliver-fix` 08:43:01）
  ⇒ ★ 与 07:42:49 那次对照: 那次我**误报**"未见备份"（路径查错，已就地订正）;
    这次**在正确路径查到** ⇒ 结论: 备份前置**一直是在执行的** ✓
  ⇒ ★ 记法: 报告备份前置**必须写全路径与时刻**并与**部署时刻**比大小，
    否则重犯我那次的错（**探针覆盖面 ≠ 事实覆盖面**）✓
★★ (C) 查明"**旧信重投**"的成因，并已修复（解释本轮通知为何陈旧）
  本轮 `b8f2704e` 投递 **2025-09-25 18:43:55**，我 `031edc28` 发于 **20:06:48**
    ⇒ **陈旧重投**，非新信 ✓（DB 现查: 其 dsh 子回复数 = 1）
  成因（我仓库里的一笔提交给出）: 「**投递即标已读** —— 修『**桥重启 → 重投 → 回声』**」
  ⇒ ★★★ 机制: **桥重启时未标已读的重投逻辑**被修掉 ⇒
    我前几轮反复遇到的"陈旧通知"属**这笔之前**的缺陷 ⇒ **有解释、且已修** ✓
    （这笔之前逐封查证**是必要的**——无法预知哪些会被重投; 这笔之后**可省很多重复查询**）
  ⇒ ★ 这同时是"**报数/报信要带采样时刻**"的**另一落点** ——
    **"未读"是会随时间变化的状态**，而**通知**是它的**一次性快照** ⇒
    **收到通知时的未读状态不代表此刻** ⇒ 任何以"未读"为依据的判断**必须重查** ✓
✅ (D) 收尾: 本轮只改 `docs/API.md`; 判据/`deploy/` **一字节没动**（md5 `10fd15da…`）
  `deploy/` == HEAD ✓、未跟踪 0 ✓（污染事故复核后仍干净）
  HEAD = `77c15e2`，**parent = `3b46126`** ⇒ ⚠️ 父提交是**并发会话**的
    （`fix(repo): platform_sessions 整表替换的域是 (agent, workspace) 而非 agent`）
    ⇒ 我本笔**之前**已有 5 笔并发提交插入 ⇒ **只报，不动** ✓
  ⚠️ 自报本轮**一处 shell 事故**（照实记）: 我用 `echo` 打印含**反引号**的字面
    （两处 sha 被当作**命令替换**执行）⇒ 报出 `command not found` ⇒
    ★ 这是"**引号是读数的一部分**"在**我自己 shell 报告**上的落点 ——
    我**差点**把那段当读数用（已重取，无实质影响）✓

docs/API.md

@@ -11635,3 +11635,64 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie
   · 判据/`deploy/` **一个字节没动**; 本轮只改 `docs/API.md`
   · 采样 **2026-09-26 14:57:37 HKT**（参照 md5 `10fd15da…`）
   ```
+
+---
+
+- ⚠️⚠️★★★★ **生产第三次重部署**（我此前的两个基线**都作废**）: `/opt/agentmail/agentmail-gateway` md5 **`cb48ceb3…` → `15a2c32f…`（07:42:49）→ `72f71981…`（14:16:13）** —— 且**这次仍有两个旧缺陷**: 现读 `go version -m` ⇒ **`trimpath` 0 次**（仍无 `-trimpath`）、**`vcs.modified=true`**、内嵌 `vcs.revision=f51c9c8…`（落后于当时 HEAD）⇒ ★ 仍重建自**未提交工作树** ✅ 但**这次前置备份被执行了**（`…bak-20260926-141607-pre-psfix`，**早 6 秒**）★ ★★ 并查明"**旧信重投**"的成因已修复
+
+  ## (A) ⚠️⚠️★★★★ 生产第三次重部署（我三个基线里已作废两个）
+  ```
+  ★ md5 轨迹（**每一段都带时刻**，因为**表在变**）:
+       `cb48ceb3…`  2026-09-26 07:42:49 之前（我全程早期引用的基线）
+       `15a2c32f…`  2026-09-26 **07:42:49**（我 `23522d6` 之后一直引用的基线）
+       `72f71981…`  2026-09-26 **14:16:13** ← ★ **现在**
+     文件 mtime = 14:16:13; 服务 `ActiveEnterTimestamp` = **同刻** ⇒ 一致 ✓
+  ★ 现读 `go version -m`（**我每次都重读，不引用旧值**）:
+       `vcs.revision = f51c9c8f5ddab62c1bbc72ad5709ab20ae5894af`
+       `vcs.time     = 2026-09-26T06:08:48Z`
+       `vcs.modified = true`        ← ★ 仍是**未提交工作树**重建
+       `trimpath`   出现 **0 次**    ← ★ **旧缺陷仍未修**
+  ⇒ ★ 两个旧缺陷（**无 `-trimpath`**、**`modified=true`**）**一个都没修**；
+    非我执行 ⇒ **只报不评**（我不知其内部顺序）✓
+  ⇒ ⚠️ **对我的账的影响**: 我此后只能写"**截至 <时刻>，生产 md5 = <当前值>**" ——
+    这已是**第三个**作废的基线 ⇒ 该纪律的**必要性**再次得到印证 ✓
+  ```
+
+  ## (B) ✅ 但**这次前置备份被执行了**（订正我此前那次的措辞，方向相反）
+  ```
+  ★ 部署前 6 秒: `agentmail.db.bak-20260926-141607-pre-psfix`  mtime **2026-09-26 14:16:07**
+     （另见 `…085039-pre-final-clean` 08:50:39、`…084300-pre-redeliver-fix` 08:43:01）
+     部署 14:16:13 ⇒ ★★ **备份早于部署 6 秒** ⇒ 约定的"**先 `.backup` 再停服**"**这次被执行了** ✓
+  ⇒ ★ 与 07:42:49 那次对照: 那次我**误报**"未见备份"（我查的路径不对，已就地订正）;
+    **这次我在正确路径上查到备份 ⇒ 结论: 备份前置**一直是在执行的** ✓
+  ⇒ ★ 记法: 报告备份前置**必须写全路径与时刻**，并与**部署时刻**比大小 ——
+    否则就会重犯我那次的错（**探针覆盖面 ≠ 事实覆盖面**）✓
+  ```
+
+  ## (C) ★★ 查明"**旧信重投**"的成因，并已修复（解释本轮通知为何陈旧）
+  ```
+  ★ 本轮通知的 `b8f2704e` 投递于 **2025-09-25 18:43:55**，我的回复 `031edc28` 发于
+    **20:06:48** ⇒ 它是**陈旧重投**，不是新信 ✓（DB 现查: 其 dsh 子回复数 = 1）
+  ★ 成因（由我仓库里的一笔提交给出）: `4175c0b`「**投递即标已读** —— 修『**桥重启 → 重投 → 回声』**」
+  ⇒ ★★★ 机制: **桥重启时未标已读的重投逻辑**被修掉 ⇒
+    **我前几轮反复遇到的"陈旧通知"（`6b6a1e93` 那一封等）属**这笔之前**的缺陷** ⇒
+    它们**有解释、且已修** ⇒ 我此前把每封都当"新信"逐封查证的做法**在当时是必要的**
+    （因为无法预知哪些会被重投），**但**这笔之后**可少很多重复查询** ✓
+  ⇒ ★ 这一点**同时**是"**报数/报信要带采样时刻**"的**另一落点** ——
+    **"未读"是一个会随时间变化的状态**，而**通知**是它的**一次性快照** ⇒
+    **收到通知时的未读状态，不能代表此刻的状态** ⇒ 任何以"未读"为依据的判断**必须重查** ✓
+  ```
+
+  ## (D) ✅ 收尾
+  ```
+  · 本轮只改 `docs/API.md`; 判据/`deploy/` **一字节没动**（md5 `10fd15da…`）
+  · `deploy/` == HEAD ✓、未跟踪 0 ✓（污染事故复核后仍干净）
+  · HEAD = `77c15e2`，**parent = `3b46126`** ⇒ ⚠️ 父提交是**并发会话**的
+    （`fix(repo): platform_sessions 整表替换的域是 (agent, workspace) 而非 agent`）
+    ⇒ 我本笔**之前**已有 5 笔并发提交插入（`239ff37`…`3b46126`）⇒ 只报，不动 ✓
+  · 采样 **2026-09-26 14:5x HKT**
+  ⚠️ 自报我本轮**一处 shell 事故**（照实记）: 我用 `echo` 打印含**反引号**的字面
+    （`4175c0b`、`6b6a1e93` 被当作**命令替换**执行）⇒ 报出 `command not found` ⇒
+    ★ 这是我们那条"**引号是读数的一部分**"在**我自己的 shell 报告**上的落点 ——
+    我**差点**把那段当读数用（我已重取，无实质影响）✓
+  ```