MailUI4Agents

Files

JianFeeeee dc064f40b8 量: 那个"少标末位"的 bug **仍在生产活着** —— 13 次调用 13 次漏末位，且它自己制造重投

顺着 pi 的 `4→8→2` 追下去时，把本会话日志里**每一条会标已读的** `read_inbox`
（`status != 'all'`；`all` 按 `idsToMarkRead` 定义**故意不标**）与 `mail_reads` 的
**同 `read_at` 串**批次对齐，得到比原先 3 行更完整、也更硬的一组读数：

    13 次调用 → 列出 81 封 / 同批标上 68 封 ⇒ **少 13 封**
    漏的**永远是列出的最后一个**，13/13，零例外

（原本 docs 里只有 04:10/04:33/06:00 三次；现在补到 13 次，跨 09-18~09-21。）

## 一、★ 它仍在生产活着：修复没部署

`17908c1`（04:25:17）修的就是这个。但线上二进制 **mtime = 09-19 13:04**、进程启于 09-20 04:01
⇒ **跑的还是旧代码**。09-21 的 5 次里**有 4 次在提交之后**，症状照旧。
⇒ **"修好了" ≠ "生效了"。**（04:10:57 那次在提交**之前**，不能当反例 —— 我初稿写成
"5 次全在提交之后"，复核时自己抓到。）

## 二、★★ 这个 bug 会**自己制造重投**（因果链，9/12 直接命中）

漏标的末位**仍算未读** ⇒ **紧接着的下一次 `read_inbox` 又把它列出来**：

    09-18 04:43 漏 2800c865 ⇒ 04:55 又列出 ✓   …（共 9 条直接命中）
    其余 3 次因换会话/中断未在紧邻调用里复发

本会话日志里同一封被重复列出过的共 **27 封**，其中 **12 封**正属于"被漏标"这批。
⇒ **重投不是另一个 bug，它就是漏标的直接后果。**
（这也回过头解释了 pi 观测到的 `4→8→2`：**收缩**来自 read_inbox 批量扫走，
而**膨胀**里有一部分是我上一轮漏标留下的。）

## 三、★ 我的读数方法自己纠正过我一次

第一版用"秒级窗口"匹配 ⇒ 得到 12 次漏末位 + **1 次"全标上"的假例外**。
改用**同 `read_at` 串**（一次 `POST` 的所有插入共享同一条 `strftime(...,'now')`）
⇒ 例外消失、**13/13 全部漏末位**。
⇒ **读数方法不严，会把一个完美一致的信号读成一个有噪声的信号** ——
而"有噪声"会让人放弃追查。我又差点因此把 13/13 记成 12/13。

## 四、顺带的算术自洽

表内 `列出 81 − 标上 68 = 13 = 漏标次数`（每次恰漏 1 封）—— 与"总数守恒"同族的免费交叉验证。

2026-09-21 07:29:33 +08:00

ALIGN-REFS.json

跨端: 左右滑动翻页（P6 第 3 步）+ 还 gesture-semantics 债 + 修跑不起来的判据基建

2026-09-19 14:01:21 +08:00

API.md

量: 那个"少标末位"的 bug **仍在生产活着** —— 13 次调用 13 次漏末位，且它自己制造重投

2026-09-21 07:29:33 +08:00

DEBTS.json

跨端: B 的交付物（跨端纯逻辑一致性判据）+ 照 skill 回扫修掉两处隐形债

2026-09-20 22:35:35 +08:00

DEV-TOOLING.md

docs(dev-tooling): 第 21 条 —— 夹具把生产形状简化掉的那一角（一天内第二个实例：agentDir 与首回合 cwd）