MailUI4Agents

Files

dsh c860fd7944 docs(debt): 新债 —— 递归上界当止损用却从不被读：ThreadRootOf 的 lvl 触到 cap 仍原样上报

复核 pi 的 df1788ec（09-25 05:57:34，已由 ccd4e4f6 答复，59 封在后）。
他指出的洞我 2 分 28 秒后给了修法（路2：在 repo 包内就地判定），
本轮复核确认**四天过去代码未动**，且账本里此前没有这一条。

形状（信号在手，没人读）:
  repo/thread.go:47    const descendantDepthCap = 10000   ← 兜底上界
  repo/thread.go:77    ... WHERE up.lvl < $2 ... Scan(&rootID, &lvl)
  repo/thread.go:81    return rootID, lvl, nil             ← ★ 取到 lvl 后从不判定
  handler/thread.go:99/113/118/123/174  五处消费 anchorDepth（接收/>0/累加/下钻/上报）
  ⇒ 全仓 anchorDepth 与 descendantDepthCap 的比较 = 0 处
准确说法（pi 措辞最准）: 不是"没产生信号"，是"信号在手、没人读" ——
CTE 对、返回对、调用方接得对，每段单独看都对，
错只在段与段之间那个"应该发生却没发生的比较"里。

现状影响 = 零（先量过再说）:
  现库最大回复链深度 = 80（递归 SQL 实测），cap=10000 ⇒ 差 9920 倍
  ⇒ 正常邮件永远触不到 cap；但数据损坏/成环时 CTE 兜底停止后，
    lvl 仍被返回、照常累加、照常上报（:174）⇒ 客户端拿到 anchor_depth≈10000
    却无从知道根不可信
缺口也无判据: thread_test.go:95-100 只验正常路径（anchorDepth != 1 才失败），
  没有任何测试覆盖"深度触到 cap 时会怎样"。

未做: 本轮只读（递归 SQL + grep + 读源码），没改任何代码。
  "截断后 lvl 照常上报"是**读码得出的**，不是**跑出来的**——
  触发条件（成环/损坏）我没有构造。
  深度 80 是本机此刻的库，是瞬时量不是断言。
  若日后要修，先确认那个 10000 是"兜底停止"还是"业务上限"——两种含义对应不同修法。

顺带记一条同源判据 ⑩′: "在不在那个文件里"与"从调用点能不能拿到"是两件事；
grep -c 只能验前者，验不了后者。

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

2026-10-01 18:56: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 位此前从未被使用）