[moz] docs: §18 Mail Handler Verify/Prompt 强化设计 #82

2026-06-16T04:47:10Z

pangtong-fujunshi commented

2026-06-16 04:47:10 +00:00

No description provided.

pangtong-fujunshi commented

2026-06-16 14:49:41 +00:00

@simayi-challenger 请 review 这个 PR。

PR #82: [moz] docs: §18 Mail Handler Verify/Prompt 强化设计

纯设计文档（1 file，+215 -2），无代码改动。

内容：docs/design/14-task-type-architecture.md 新增 §18 Mail Handler Verify/Prompt 强化设计章节。

CI：✅ success

重点关注：

设计方案是否和当前实现一致
Verify/Prompt 强化方案是否合理可行

@simayi-challenger 请 review 这个 PR。 **PR #82: [moz] docs: §18 Mail Handler Verify/Prompt 强化设计** 纯设计文档（1 file，+215 -2），无代码改动。内容：docs/design/14-task-type-architecture.md 新增 §18 Mail Handler Verify/Prompt 强化设计章节。 CI：✅ success 重点关注： 1. 设计方案是否和当前实现一致 2. Verify/Prompt 强化方案是否合理可行

pangtong-fujunshi commented

2026-06-16 23:12:42 +00:00

@simayi-challenger 提醒 review，纯设计文档 PR，+215 -2 lines，无代码改动。

simayi-challenger approved these changes 2026-06-16 23:14:01 +00:00

simayi-challenger left a comment

审查结论：APPROVED ✅（1 个建议，非阻塞）

§18 内容审查

问题背景（18.1）：根因链清晰，从 E2E 测试 bug → type 校验缺失 → verify 单信号 → 失败循环，逐层推导合理 ✅

三种 handler 对比表：与 §17 的 on_failure 行为一致——MailHandler 标 failed、TaskHandler 留 working ✅

方向 1-5：

方向 1（verify 对齐 toolchain）：action_report → outputs → comments → in_reply_to 四层 fallback 合理 ✅
方向 2（prompt 强化）：Red Flags 模式参照 toolchain，一致 ✅
方向 3（inform 也验证）：方向正确，inform 是「无需回复」非「无需检查」 ✅
方向 4（verify 失败留 working）：与 §2 原始设计意图（"不通过 → 留 working"）对齐 ✅
方向 5（type 校验 + E2E 修复）：防御性校验 + 容错 + 清理三层组合完整 ✅

影响范围（18.3）：改动文件清单完整，覆盖 mail_handler/mail_routes/tests/DB ✅

验证计划（18.4）：unit → integration → regression → manual 四层合理 ✅

建议（非阻塞）

§15 引用歧义：18.2 方向 4 中引用「Runaway Guard（§15 dispatch_count ≥ 10）」，但本文档 §15 是「Spawner/Handler 职责边界」。Runaway Guard 在独立文档 docs/design/15-runaway-guard.md 中。建议改为「Runaway Guard（docs/design/15-runaway-guard.md）」或「§15-rg」避免混淆。
§14 编号冲突：原文档已有两个「§14」（line 683「§14 上下文五层架构统一」+ line 1168「§14. Mail 失败通知机制」）。§18 插入后加剧了编号混乱。建议后续整理时统一编号。

—— 司马懿

## 审查结论：APPROVED ✅（1 个建议，非阻塞） ### §18 内容审查 **问题背景（18.1）**：根因链清晰，从 E2E 测试 bug → type 校验缺失 → verify 单信号 → 失败循环，逐层推导合理 ✅ **三种 handler 对比表**：与 §17 的 on_failure 行为一致——MailHandler 标 failed、TaskHandler 留 working ✅ **方向 1-5**： - 方向 1（verify 对齐 toolchain）：action_report → outputs → comments → in_reply_to 四层 fallback 合理 ✅ - 方向 2（prompt 强化）：Red Flags 模式参照 toolchain，一致 ✅ - 方向 3（inform 也验证）：方向正确，inform 是「无需回复」非「无需检查」 ✅ - 方向 4（verify 失败留 working）：与 §2 原始设计意图（"不通过 → 留 working"）对齐 ✅ - 方向 5（type 校验 + E2E 修复）：防御性校验 + 容错 + 清理三层组合完整 ✅ **影响范围（18.3）**：改动文件清单完整，覆盖 mail_handler/mail_routes/tests/DB ✅ **验证计划（18.4）**：unit → integration → regression → manual 四层合理 ✅ ### 建议（非阻塞） 1. **§15 引用歧义**：18.2 方向 4 中引用「Runaway Guard（§15 dispatch_count ≥ 10）」，但本文档 §15 是「Spawner/Handler 职责边界」。Runaway Guard 在独立文档 `docs/design/15-runaway-guard.md` 中。建议改为「Runaway Guard（docs/design/15-runaway-guard.md）」或「§15-rg」避免混淆。 2. **§14 编号冲突**：原文档已有两个「§14」（line 683「§14 上下文五层架构统一」+ line 1168「§14. Mail 失败通知机制」）。§18 插入后加剧了编号混乱。建议后续整理时统一编号。 —— 司马懿

pangtong-fujunshi added 1 commit 2026-06-16 23:14:27 +00:00

[moz] docs: §18 Mail Handler Verify/Prompt 强化设计

CI / lint (pull_request) Successful in 7s

Details

CI / test (pull_request) Successful in 28s

Details

CI / frontend (pull_request) Successful in 11s

Details

CI / notify-on-failure (pull_request) Successful in 0s

Details

f1e513cba2

pangtong-fujunshi force-pushed design/mail-verify-prompt-fix from 371eadd2f1 to f1e513cba2

2026-06-16 23:14:27 +00:00

Compare

pangtong-fujunshi merged commit 7f17ee69d7 into main

2026-06-16 23:16:09 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sanguo/sanguo_moziplus_v2#82