Files
MailUI4Agents/docs
JianFeeeee 88f4b8ab5e fix(debt): 我上一条把 pi 的 hop 建议判成"假问题"——**判过头了**;实测有**三个带**,最坏那个会清零 hop 守卫
★ 更正我自己上一条 `a05509c`(同一天、我写的)。我写:
  "`CountTrailingRelayHops` 是重算 ⇒ '计不计'由有没有落库唯一决定 ⇒ **不该写进判据**"
**那半对,但我漏了两个形**,而漏掉的那个正是最坏的。实测(`/tmp/hop.db` 合成库):
```
基线 3 封全绑:                        序列 1 1 1        ⇒ hops = 3
加 1 条占位行(mail_id NULL,无 mail 行):  序列 1 1 1    ⇒ hops = 3  **不受影响**
加 1 封有 mail 行但未绑 relay:         序列 **0** 1 1 1  ⇒ break ⇒ **hops = 0**
```
⇒ 抑制点的位置有**三个带**,后果完全不同:
```
① 在 :384(CountTrailingRelayHops)之前 return ⇒ 既不落 mail 也不落 relay ⇒ 真正"不计" ✓
② :396(ClaimRelay) 之后、:474(CreateMail) 之前 ⇒ 落占位行 ⇒ hop 不变,但**白占幂等键** ⇒ 重试被挡
③ :474(CreateMail) **之后** ⇒ 落"有 mail 行、无 relay 绑定" ⇒ is_relay=0 ⇒
   CountTrailingRelayHops **break ⇒ hops 归零** ⇒ **hop 上限对该会话失效**
```
★ ③ 不是"多算或少算 1",而是**主动清零守卫** ⇒ 环可以**绕过 5 跳上限**。
   而 ③ 恰是"抑制逻辑写在 CreateMail 之后"这种最自然的写法会落进去的带(那里才拿到 mailID)。

⇒ 所以 pi 的直觉**是对的**,我错在把它当成"可配的口径"而整体否掉。
   正确的结论(取代上一条): 这不是口径,是**必须满足的顺序约束**,而顺序约束**更要**进判据:
```
「抑制必须在 CountTrailingRelayHops 之前 return」——理由: 落在其后会造出"有 mail 行无 relay 绑定"
的邮件,把 hop 守卫清零
判据形状: 构造一封因抑制而不发的报告,断言同会话 CountTrailingRelayHops 不降为 0
         (**能失败** —— 把抑制挪到 CreateMail 之后就红)
```
★ 教训与这条线同形: 我用"重算"这个**机制事实**否掉了一整条建议,而没有把机制在**所有落点**上跑一遍。
   pi 说的是"位置影响读数",我说的是"机制是重算" —— **两句都真,但我的那句不能推出"所以不必写"**。

验证: `TestDebtLedgerMatchesMeasurement`/`TestDebtSummaryReadsAuthoritativeLedger` 通过;
`debt-visibility.test.mjs` 1/1。
2026-09-25 06:56:29 +08:00
..