WebUI 脱 Electron Playbook 复审补充

日期: 2026-05-07
审查对象:
- docs/backend-migration/plans/2026-05-07-webui-decouple-team-playbook.md
目的: 记录 playbook 最新修订后仍建议继续收紧的 2 个点

结论

这版 playbook 已经明显补强了此前的几个主要阻碍点:

目前剩下的 2 个问题已经不是方向性问题，而是执行时序和失败诊断颗粒度还可以再锁死。

playbook 前面写的是:

但在 checkpoint 章节里:

与此同时，M9 的真实 release 验证又明确写成“由人类在真实 release 后触发，agent 不跑”。

这会导致时序上的不一致:

这样会让协调者和 executor 对“什么时候算本里程碑完成”出现不同理解。

建议把门禁语义拆成两层，避免把 feature 分支 gate 和真实发布 gate 混在一起:

里程碑放行门禁
- 仅要求 executor 在 feature 分支阶段可完成的本地 + CI 验证
- 这决定 handoff 是否可以被接受
发布后验证门禁
- 在真实 release / tag 之后执行
- 由人类或专门的发布流程负责
- 这决定“发布链路是否最终闭环”，但不应阻塞 executor 的 feature 分支完成

更具体地说:

playbook 已经明确要求:

这已经比之前强很多。

但对于 M6 这种全链路最高风险节点，playbook 里仍然主要停留在原则层:

还没有在 playbook 层直接规定最低限度的固定抓手。

M6 一旦失败，最容易出现的问题不是“没有思路”，而是:

这会降低故障定位效率，也让 handoff 里的失败证据不够标准化。

建议在 playbook 里单独补一个非常短的“M6 固定诊断抓手”小节，哪怕只锁下面几项:

日志优先级
- 先看 Playwright trace / screenshot / video
- 再看 Electron 主进程日志
- 再看 backend 日志
端口来源
- backend port 从哪条日志或哪个对象字段读取
- host port 从哪条日志或哪个返回值读取
最小失败证据
- 失败 case 必须在 handoff 里附:
  - 失败命令
  - 失败截图或 trace 路径
  - backend / host 端口值
  - 第一条异常日志

这不需要取代 plan-writer 的详细诊断设计，只是给 M6 先提供一个跨会话一致的最低标准。

如果只想最小成本继续收口:

做完这两步后，playbook 在执行层面的口径会更稳。