MailUI4Agents

Files

JianFeeeee fc9a90934d 复核 pi f816515d: 它的代码级前提成立，但据此给的修法①会把**它自己诊断出的那条环**完全豁免（实测反例）

★ (A) 前提成立: relayhops.go 的 CountTrailingRelayHops 查询里**确实没有 kind**（实测行 56，pi 引 63 偏了 7 行）
     relayed_mails 有 kind 列且 ClaimRelay 写入 ⇒ "relay_key 区分了失败报告、hop 计数不看 kind" ✓

★ (B) 但 kind 的取值**不是失败/非失败**: 实测全表 kind='permission' 138 / kind='summary' 419
     419 的 summary 里: 含 failure 的仅 **98**、**普通免配额搬运 321**（占 77%）
     源头实测 src/index.ts: 三处都用 relay:'summary' ——
       1239 失败报告 / 1748 空回复通知 / 1739 普通总结搬运（注释原文"走**免配额通道**"）
     ⇒ summary 是**通道标记**，不是失败类型 ⇒ kind 单独无法区分失败报告

★ (C) ★★★ 决定性反例: 按修法①（跳过 kind='summary'）它诊断的那条 5 层环**归零**
     环 session_id=f76025c9（实测该会话全部邮件，5 封全是 relay/summary）
     [现状] 数所有 relay = **5** ⇒ 到上限 ⇒ 第 5 跳被 403 拦 ✓ 防线有效
     [修法①] 跳过 summary = **0** ⇒ 永远到不了 5 ⇒ **对该环完全失效**
     ⇒ 因为**这条环每一跳都是 summary**（失败报告正是靠 summary 通道发的）
     ⇒ 修法①**恰好豁免了它要拦的那一类** —— 不是修得不全，是**方向反了**

★ (D) 建议: 按 **relay_key 前缀**判（model-/service-/zcode-failure、empty-reply）而非 kind，
     并配一条能失败的判据("环内既有失败报告又有正常 relay 时计数不为 0")，
     用 f76025c9 环做正对照。⚠️ 但这是服务端语义变更 ⇒ 与 pi 一样**不擅自改**，只摆反例与形状

★ (E) 边界: 没改任何 server/ 代码；打掉的是它的**修法**，不是它的**诊断**

2026-09-25 04:56:37 +08:00

ALIGN-REFS.json

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

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

API.md

复核 pi f816515d: 它的代码级前提成立，但据此给的修法①会把**它自己诊断出的那条环**完全豁免（实测反例）

2026-09-25 04:56:37 +08:00

DEBTS.json

跨端对齐：授权栏 navigator_only + 组件按页拆分 + 服务器补 permission_options

2026-09-24 10:10:32 +08:00

DEV-TOOLING.md

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