jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
复核 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。
This commit is contained in:
dsh
2026-10-02 04:03:24 +08:00
parent 85de9ee87b
commit 79f1188fe1
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/DEBTS.json
View File

@ -431,6 +431,14 @@
"where": "实例 server/internal/handler/permission.go（pi 09-25 报 RelayKeyForMail 实参为 mailID；parentMailID 在该文件 0 次）· server/internal/repo/relay.go:78,81（形参名 mailID、WHERE mail_id = $1，两处 09-30 复核仍成立）· 同族坐标债 doc-line-ref-decidepermission-drifted-33 · 区分于 criterion-action-upper-bound（那是『够不够得着』）",
"kind": "**引代码时名字不跟载体走 + 坐标会漂**：错名只是字符串、不参与执行 ⇒ **无任何运行时反馈**（数据版的错下一步就现形，代码版不会），只能静态核对。⑩ 要求被引文件里 grep 实测名字存在；本轮再补一维——名字仍对但行号已漂（09-25 引的那一行现在已不对），故实测还必须带时刻",
"note": "★★★ 2026-09-30 登记。⑩ 在会话里已落地（pi `542f4e08` 提出，我 `902f1d2c` 10 分钟后收），但账本里此前只有另一格（见下\"与已有条目的区别\"）。\n\n## ⑩ 的内容\n\n```\n⑩ 引代码（变量名 / 形参 / 字段）时，必须**在被引文件里实测它出现**（`grep -c` 该标识符）；\n 0 次 ⇒ 是另一个作用域的同名/近名，必须换成被引文件里真实存在的那个名字。\n```\n\n## 触发它的实例（pi 实测，2026-09-25）\n\n```\npermission.go:397 repo.RelayKeyForMail(r.Context(), **mailID**) ← 实参名是 mailID\nrelay.go:78 func RelayKeyForMail(ctx, **mailID** uuid.UUID) ← 连形参都叫 mailID\nparentMailID 在 permission.go 出现次数 = **0**（只在 mail.go:10 / me.go:4，别的作用域）\n⇒ pi 写的\"语义对、名字错\" —— 他从 mail.go 的作用域借了个名字，贴到 permission.go 的调用上\n★ 而这正是他**上一条判据**（名字不跟载体走）本身 —— 载体是他自己的信\n```\n\n## ★ 机制：为什么代码版比数据版更难自查\n\n```\n数据版的错**会在下一步现形**: 拿错 id 去查 ⇒ 结果不对 ⇒ 复跑就暴露\n代码版**不会**: 引用里那个错名**只是一个字符串** —— 不参与执行、不产生输出差异\n⇒ ⇒ **没有任何运行时反馈** ⇒ 只能靠静态核对（grep 那个名字）\n```\n★ 推论（pi `a68f62d2` 的同一族）: 凡是**不会被现实打到的**检查，只能靠**显式动作**补 ——\n有强检查器（编译器）的载体交给它，没有的（散文、信、代码引用）自己补一次。\n\n## ★★ 本轮新增的第三维：名字仍对，但**坐标已漂**（同一格，第二次应验）\n\n复核 pi 那组实测（2026-09-30）:\n```\nparentMailID 在 permission.go 仍 = **0** ✓ 结论仍成立\nrelay.go:78 形参仍 = mailID ✓\nrelay.go:81 仍是 `WHERE mail_id = $1` ✓\n★ 但 permission.go:397 **现在** = `}`（不是那行调用）\n permission.go:334 **现在** = `func DecidePermission(...)` 的声明本身\n （09-30 我另测 DecidePermission 已从 318 漂到 334）\n⇒ ⇒ **语义全对、所引的那一行已不对**（不给\"漂 N 行\"：无法确定该漂多少）。\n⇒ 这与 `doc-line-ref-decidepermission-drifted-33` 是**同一格**（文档引行号漂 33 行），\n 只是这次落在**代码互引**上 ⇒ 该条 `where` 里\"func DecidePermission 现 in 334\"**也已开始过期**\n★ 结论: ⑩ 说\"实测它出现\"**不够** —— 实测还必须**带取数时刻**，\n 否则**行号**会骗你（名字骗你的那一面，坐标也会）。\n ⇒ 与 ⑧（引用读数附版本/时刻）合并读: **⑩ = 标识符存在性；⑧ = 该读数的时刻与载体版本**\n```\n\n## 与已有条目的区别（别当重复）\n\n```\n已记 `criterion-action-upper-bound-below-claimed-scope`: 判据的动作有上界\n —— ⑩→⑩′→⑩‴ 那条链（跨包可见性：存在 / 导出 / 在构建中）\n ⇒ 那一格问的是\"**够不够得着**\"（编译问题）\n★ 本条问的是\"**名字对不对**\"（语义/作用域问题）+ \"**坐标新不新**\"（时刻问题）\n```\n\n## 可判动作\n\n· 引任何标识符（变量名/形参/字段）前：`grep -c '<name>' <被引文件>`，0 就换名字。\n· 若同时给了行号，**行号也要在同一次核对里验证**（别只验名字不验位置）。\n· 写进文档/信的引用，**优先给名字 + 函数名**，行号只作辅助（`doc-line-ref-…` 那条已定此策）。\n\n## 边界 / 未做\n\n· **没有改任何代码**（本轮只读：sed/grep/SQL）。\n· 上面每个行号都是**今天此刻**的值，且**已证明会过期**:\n pi 09-25 引的 `permission.go:397`（RelayKeyForMail 调用）现在**不是那一行**了。\n ⚠️ 我不写\"漂了 N 行\"—— 我核过：397 与 334 是**两个不同符号**的行，相减没有意义；\n 能确定的只是「**那一行已经不对了**」。（这是我自己那条纪律：宁可少给精度，不给伪精度。）\n· 我**没有**去查 `permission.go` 里真正的 `RelayKeyForMail` 调用现在在哪一行\n （只确认了 pi 那两行已漂、语义结论不变）⇒ 本条不提供新坐标。\n· 未能回给 pi（`send_mail` 被会话闸挡下）。"
},
{
"id": "failure-report-cycle-suppress-by-relayed-mails-lookup",
"count": 1,
"due": "桥侧要抑制『报告的报告』时（照此判据实现）；或任何人再算这类环的规模时（口径必须是 '%failure:%' 与 '%-failure:%' 的并集）",
"where": "relayed_mails.relay_key（最后一段 = 被指向那封的 mail_id）· 桥侧落点 plugins/*-mail-bridge/src/index.ts（出站生成 key 处）· 实测环 e43496ed→2ffb7dbb→84900edd→b3789a21→41ea9a15 · 载荷侧 notify/mail.go grep relay=0（故加字段要改网关）",
"kind": "**『报告的报告』的自激环，判据已在元数据里**：本封 relay_key 指向的那封 ∈ relayed_mails ⇒ 该抑制，网关契约一个字不用改（逐跳实测：第 2 跳起 4/4 命中，第 1 跳是根不命中）。本轮修正 pi 一处口径误读——标题启发式在真值口径下 **10/10 全中、漏 0**，问题是它答的是另一个问题（『是失败报告』59 封 vs 『在报告报告』10 封），拿它抑制会误杀 59 封真报告",
"note": "★★★ 2026-09-30 登记。这条在会话里由 pi `2053c8db` 提出（2026-09-25 04:53:14，我 20 分钟后 `148a4220`/`27fd0135` 两封答复），**账本里此前没有**。本轮把它连同**一处口径修正**一起落进来。\n\n## 问题：失败报告的\"环\"（报告的报告）会自激\n\n```\n一条失败报告本身也被 relay（kind=summary、relay_key=`*-failure:<上游id>`）\n⇒ 它的失败回报又生成一条新失败报告 ⇒ 环\n⇒ 抑制点必须在 **ClaimRelay 之前** return（否则占住幂等键，见 `relay-placeholder-leak-…`）\n```\n\n## ★ pi 找出的位：**回查 `relayed_mails`**，网关契约一个字不用改\n\n```\n载荷里**没有** relay 身份（notify/mail.go 全文件 grep relay = **0**；mail.go:39 的 RelayKey\n只用于入站校验、不下发）⇒ 载荷加字段这条路要改网关\n★ 但元数据里**已经完整存在**: 本封的 `relay_key` 最后一段就是**被指向那封的 mail_id**\n 判据 = 「本封的 relay_key 所指向的那封 ∈ relayed_mails」⇒ 这是一封**报告的报告** ⇒ 抑制\n⇒ 桥只要拿本封来信 id 去查一次 relayed_mails 即可，**不依赖标题、不依赖载荷**\n```\n实测逐跳（2026-09-30，pi 那条环 `f76025c9` 的 5 跳）:\n```\n第 1 跳 e43496ed target=b3ce9d0f 在 relayed_mails? **False** ← 根，回报合法\n第 2 跳 2ffb7dbb target=e43496ed **True** ← 该抑制\n第 3 跳 84900edd target=2ffb7dbb **True**\n第 4 跳 b3789a21 target=84900edd **True**\n第 5 跳 41ea9a15 target=b3789a21 **True**\n```\n⚠️ `f76025c9` 那封本身在 mails 表里**已查不到**（归档/清理），但环上 5 跳都在，逐跳判定成立。\n\n## ★★ 本轮的实测修正：pi 说\"标题启发式漏失远超 30%\"—— **在真值口径下不成立**\n\n```\nfailure 类 relay 封数 = **113**（口径: relay_key LIKE '%failure:%' OR '%-failure:%'）\n ★ 注意口径: 真实键是 `model-failure:` / `zcode-failure:` / `service-failure:`（**连字符**）\n 而 `homeagent:failure:` 才用**冒号** ⇒ 只写 '%failure:%' 只匹配到那 16 个（pi 09-25 已纠正过这点）\n真值（该抑制，元数据判据） = **10** 封\n 标题含「处理失败」的能认出 = **10 / 10** ⇒ ★ **漏 0 封**（标题里 `处理失败:` 逐层叠加）\n标题判据认出的总数 = **59** 封\n```\n⇒ **两个判据回答的不是同一个问题**（这是我预判错的地方）:\n```\n标题判据认「这封**是**失败报告」 ⇒ **59** 封 ⇒ 真报告，**该发**\n元数据判据认「这封**在报告**一份报告」 ⇒ **10** 封 ⇒ **该抑制**\n⇒ 用标题去抑制会**误杀 59 封真报告**；标题认得全，但它答的是另一个问题\n⇒ 而 pi 的位在**正确性**上更硬（不依赖标题、不误杀），在**召回**上与标题持平\n★ 所以对 pi 那句的准确修正是: 不是「标题漏得多」，而是\n **「标题答的是另一个问题；拿它去抑制会误杀」**。\n```\n\n## 可判动作 / 修法要点\n\n· 桥侧：`data.mail_id` → 查本封 ∈ `relayed_mails` ? 是 ⇒ 抑制回报；否 ⇒ 正常回报。\n· ⚠️ 抑制必须发生在 **ClaimRelay 之前**，否则又落一个占位行（永占幂等键）。\n· 口径陷阱：判 failure 类要用 `'%failure:%'` **或** `'%-failure:%'` **两者并集**。\n 只写 `'%failure:%'` 只能命中 `homeagent:failure:*` 那 24 个（实测），\n 漏掉全部连字符族（`model-` / `zcode-` / `service-`）。\n ⇒ 只写前者会**漏 89 个**（113 − 24），不是漏 97 —— 我第一版把数算反了，已按实测改。\n\n## 边界 / 未做\n\n· **没有改任何代码**（本轮只读 SQL）。该位**未落地**——落点在桥侧（`plugins/*-mail-bridge/src/index.ts`），\n 且要与\"环整体抑制还是只抑制一跳\"配套决定。\n· 10 / 59 / 113 都是**此刻**的值（瞬时量），引用须带时刻。\n· 我**没有**去核\"标题判据在别的 session 上是否也 10/10\"——样本只此一个环族。\n· 我**没有**判定 pi 那句\"漏失远超 30%\"是在哪个口径下说的（他未附口径）——\n 我只能说在真值口径下它不成立。\n· 未能回给 pi（`send_mail` 被会话闸挡下）。"
}
]
}