sanguo_moziplus_v2/docs/design/18-toolchain-e2e-test.md

§18. 工具链端到端验证测试

日期：2026-06-09 状态：已完成 ✅ 目标：用真实 Webhook 触发验证整条 Mail 通知链路

前置确认

• Gitea 用户名 ↔ Agent ID 映射：完全一致（admin, guanyu-dev, jiangwei-infra, pangtong-fujunshi, simayi-challenger, zhangfei-dev, zhaoyun-data）
• Gitea 组织级 Webhook（Hook ID=28）：姜维确认最近 5 条投递全部 is_succeed=1
• Daemon 在线：sanguo-moziplus-v2 运行中
• 测试仓库：sanguo/moziplus-v2

命名规范

• Issue 标题：[E2E-TEST] xxx
• PR 标题：[E2E-TEST] xxx
• 分支名：test/e2e-<timestamp>

验证步骤

步骤	操作	触发事件	预期 Mail 通知	验证点
1	创建 Issue [E2E-TEST] Issue指派测试，assignee=zhangfei-dev	issues (assigned)	zhangfei-dev 收到 "Issue 指派" Mail	Mail to/模板正确
2	开分支 test/e2e-<ts>，创建 PR [E2E-TEST] Review请求测试	pull_request (opened)	simayi-challenger 收到 "Review 请求" Mail	Mail to/风险级别/文件列表
3	PR Review APPROVED	pull_request_review (approved)	PR 作者(pangtong-fujunshi) 收到 "Review 通过 ✓" Mail	result=通过 ✓
4	PR Review REQUEST_CHANGES	pull_request_review (rejected)	PR 作者收到 "Review 驳回 ✗" Mail	result=驳回 ✗
5	Issue 上发评论 [CI] CI 失败 — 分支: test/e2e-xxx, 错误: build timeout	issue_comment	Issue 作者收到 "CI 失败" Mail	模板含分支/错误摘要
6	创建标题含"部署失败"的 Issue（无指派）	issues (opened)	jiangwei-infra + pangtong-fujunshi 各收到 "部署失败" Mail	双收件人
7	关闭步骤 1 的 Issue，再发 CI 失败评论	issue_comment (closed issue)	不产生 Mail（负面测试）	handler 跳过 closed
8	重发步骤 1 Webhook（相同 delivery ID）	重复事件	不产生新 Mail（幂等测试）	返回 duplicate

签名校验

已测试（GITEA_WEBHOOK_SECRET 已配置且生效）：

• ✅ 正确签名：请求正常处理
• ✅ 无签名：返回 403 signature verification failed

Review 意见来源

• 姜维（基础设施确认 + 边界验证建议）
• 司马懿（遗漏点补充 + 命名规范 + 风险防范）

---

执行记录

2026-06-09 00:40~00:50 CST

步骤 1：Issue 指派 ✅

• 操作：创建 Issue #22 [E2E-TEST] Issue指派测试，assignee=zhangfei-dev
• Mail：mail-1780936736480，from=system, to=zhangfei-dev, title=Issue 指派: [E2E-TEST] Issue指派测试
• 模板渲染正确（含 Issue 链接、标签、描述、建议分支名）

步骤 2：PR Review 请求 ✅

• 操作：创建分支 test/e2e-1780936838，创建 PR #23
• Mail：mail-1780936851715，from=system, to=simayi-challenger
• 模板含 PR 链接、标题、作者(pangtong-fujunshi)、分支、风险级别(standard)
• 附带：CI 失败通知 mail-1780936876572（CI 自动触发，符合预期）

步骤 3：Review APPROVED ✅

• 操作：用 simayi-challenger token 提交 APPROVED review
• Mail：mail-1780936968411，from=system, to=pangtong-fujunshi, title=Review 通过 ✓
• 描述含审查者(simayi-challenger)、review body
• ⚠️ 收到 2 封重复 Mail（org webhook + repo webhook 双触发）

步骤 4：Review REQUEST_CHANGES ✅

• 操作：用 simayi-challenger token 提交 REQUEST_CHANGES review
• Mail：mail-1780936972207，from=system, to=pangtong-fujunshi, title=Review 驳回 ✗
• ⚠️ 同上，收到 2 封重复 Mail

步骤 5：CI 失败评论 ✅

• 操作：在 Issue #22 发评论 [CI] CI 失败 — 分支: test/e2e-1780936838, 错误: build timeout
• Mail：mail-1780936994513，from=system, to=pangtong-fujunshi, title=CI 失败: sanguo/moziplus-v2#22
• 模板含分支提取和错误摘要

步骤 6：部署失败 Issue ✅

• 操作：创建 Issue #24 [E2E-TEST] 部署失败: test deploy（无指派）
• Mail：mail-1780936999660 to=jiangwei-infra, mail-1780936999684 to=pangtong-fujunshi
• 双收件人验证通过 ✅

步骤 7：已关闭 Issue 负面测试 ✅

• 操作：关闭 Issue #22 后发 [CI] CI 失败 — 应被过滤
• 结果：未产生新 Mail ✅（只有步骤 5 的 1 封 CI Mail，步骤 7 的评论被正确过滤）

步骤 8：幂等测试 ✅

• 操作：构造带正确 HMAC-SHA256 签名的 Webhook，用同一 delivery ID test-idempotency-002 发两次
• 第一次：返回 ok，产生 Mail ✅
• 第二次：返回 duplicate，无新 Mail ✅
• 额外验证：不带签名的请求返回 403 signature verification failed（签名校验正常工作）

---

汇总

步骤	状态	备注
1. Issue 指派	✅ 通过	Mail to/模板正确
2. PR Review 请求	✅ 通过	Mail to/风险级别/文件列表正确
3. Review APPROVED	✅ 通过	E2E 测试中产生 2 封 Mail（根因已查明，非平台问题）
4. Review REQUEST_CHANGES	✅ 通过	同上
5. CI 失败评论	✅ 通过	分支提取正确
6. 部署失败 Issue	✅ 通过	双收件人验证通过
7. 已关闭 Issue 过滤	✅ 通过	负面测试通过，无新 Mail
8. 幂等测试	✅ 通过	第二次返回 duplicate，无新 Mail；签名校验正常拦截无签名请求

发现的问题

Review 事件双 Mail（已修复）

• 现象：E2E 测试步骤 3/4 中 Review 事件产生 2 封 Mail
• 根因（姜维深入调查确认）：E2E 测试中庞统手动用 simayi token 提交了 Review，同时 simayi agent 收到 Review 请求 Mail 后也自主提交了 Review。是两次独立的 API 调用，不是 Gitea bug 或平台配置问题
  • 姜维控制实验：一次 review API 调用只产生 1 个 hook_task
  • Gitea 路由日志确认两次 POST 间隔 7 秒，payload 有差异（review_comments、updated_at 不同）
  • 之前的错误分析（"Gitea webhookNotifier + actionsNotifier 双投递"）已被推翻：actionsNotifier 走 handleWorkflows() 不创建 hook_task
• 修复：payload 内容去重作为防御性编程保留（_is_duplicate 新增内容去重 key = event + pr_num + sender + sha256(body_or_content)），司马懿 APPROVED
• 验证：PR #27 实测只产生 1 封 Mail ✅

根因分析教训

• 姜维第一次分析给出了错误根因（Gitea 双 notifier），第二次深入调查后自我纠正
• 庞统把姜维的第一次结论当事实汇报给主公，没有标注"这是姜维的调查结论，尚未独立验证"
• 改进：SOUL.md 新增规则——推测 vs 事实显式标注、引用他人结论时标注来源、结论被推翻时及时更正

---

PR #38 新增场景（synchronize fallback + merge 通知）

2026-06-12 新增，对应 PR #38 的设计变更

步骤 9：synchronize fallback ✅

• 操作：创建 PR（无 review 历史）→ push 新 commit 到 PR 分支
• 触发事件：pull_request (synchronize)
• 预期：simayi-challenger（默认 reviewer）收到"请重新 review" Mail
• 验证点：
  • PR 无 review 历史时，_fetch_latest_reviewer() 返回 None → fallback 到 simayi-challenger
  • Mail to 正确（默认 reviewer 而非跳过通知）
  • 模板使用 review_updated.md

步骤 10：merge 通知 ✅

• 操作：PR 通过 Review 后 merge
• 触发事件：pull_request (closed) + merged=true
• 预期：PR 作者收到"PR 已合并" Mail
• 验证点：
  • Mail to 正确（PR 作者）
  • merged_by 字段正确提取（payload merged_by → fallback sender）
  • 模板使用 review_merged.md
  • 纯 closed（非 merged）不触发通知