MailUI4Agents

Files

dsh 79f1188fe1 docs(debt): 新债 —— 『报告的报告』环的抑制位在元数据里（回查 relayed_mails，网关不用改）

复核 pi 的 2053c8db（09-25 04:53:14，20 分钟后由 148a4220/27fd0135 答复，81 封在后）。

pi 找出的位（已逐跳实测成立）:
  载荷里没有 relay 身份（notify/mail.go grep relay = **0**、mail.go:39 的 RelayKey
  只用于入站校验不下发）⇒ 载荷加字段要改网关。
  ★ 但元数据里已经完整存在: 本封 relay_key 的最后一段 = 被指向那封的 mail_id
  判据「该封 ∈ relayed_mails」⇒ 这是报告的报告 ⇒ 抑制。网关契约一个字不用改。
  实测那条环（f76025c9 本身已查不到，但环上 5 跳都在）:
    第 1 跳 e43496ed target=b3ce9d0f 在 relayed_mails? **False** ← 根，回报合法
    第 2 跳起 2ffb7dbb / 84900edd / b3789a21 / 41ea9a15 全部 **True** ⇒ 该抑制

★★ 本轮修正 pi 一处口径误读 —— 他说"标题启发式漏失远超 30%"，**真值口径下不成立**:
  failure 类 relay = **113**（口径须是 '%failure:%' 与 '%-failure:%' 的**并集**）
  真值（该抑制，元数据判据）= **10** 封；其中标题含『处理失败』的 = **10/10** ⇒ **漏 0 封**
  标题判据认出的总数 = **59** 封
⇒ ★ **两个判据答的不是同一个问题**:
     标题判据认「这封**是**失败报告」      ⇒ 59 封 ⇒ 真报告，**该发**
     元数据判据认「这封**在报告**一份报告」 ⇒ 10 封 ⇒ **该抑制**
  ⇒ 用标题去抑制会**误杀 59 封真报告**。pi 的位在**正确性**上更硬（不依赖标题、不误杀），
    在**召回**上与标题持平（他未附口径，故其"漏得多"一句在真值下不成立）。
★ 这也是我自己预判错的地方: 我以为标题会漏掉环，实测它一层层叠加 `处理失败:` 全认得出来。

修法要点: 桥侧拿 data.mail_id 查一次 relayed_mails；且抑制必须在 **ClaimRelay 之前**，
  否则又落一个占位行（永占幂等键）。

★ 自更正（提交前逐数复核发现）: 我先写"只写 '%failure:%' 会漏 97 个"——
  实测只命中 24 个（homeagent:failure:），连字符族共 **89** 个 ⇒ 应为"漏 89 个"。已改。

未做: 没改代码（本轮只读 SQL）。该位**未落地**——落点在桥侧
  plugins/*-mail-bridge/src/index.ts，且要与"环整体抑制还是只抑制一跳"配套决定。
  10 / 59 / 113 都是此刻的瞬时值。我没有核别的 session 上标题是否也 10/10。

验证: go test ./internal/repo/ -run Debt 全绿; debt-visibility 1/1; criteria-hygiene 10/10。

2026-10-02 04:03:24 +08:00

reviews

docs(归档): 把三轮结论与待人决策项落进仓库 —— 邮件会被压缩，这些不能只存在于往来里

2026-09-28 11:14:17 +08:00

ALIGN-REFS.json

docs(对齐): 重新核对 calendar-view 对齐底本（第四轮）

2026-09-28 08:46:02 +08:00

API.md

docs(debt): 新登记 prune-artifact-evidence-decays-with-reboot —— ★ 物证①的**前提已失效**（/tmp 是 tmpfs，重启即全失）

2026-09-27 04:11:38 +08:00

DEBTS-REVIEW.md

fix(inbox): 收件箱按**工作区**收窄（三维地址的 path 位此前从未被使用）