Hover Cloud：内置 Heal Queue 的 Playwright CI 看板

你的 Playwright 套件已经在 GitHub Actions 里跑着了，但它不会主动告诉你：哪些 spec 开始变 flaky、哪些失败是真 bug 而不是 selector 挪了位置、套件还漏了哪些没测。Hover Cloud 读取你已经跑出来的运行结果，替你回答这些问题，而它本身不跑任何浏览器。

Hover Cloud 做什么

用 GitHub 登录，接入一个 repo。Hover 会装好 App、写好 CI workflow、配好上报用的 secrets。从此每次运行都会回传，看板再把这些运行整理成趋势、分诊队列和告警。公测期间免费。

一块 Playwright CI 看板

看板跨项目汇总每次运行：通过率、运行历史，还有一个 flakiness 打分——按 spec 在通过和失败之间来回翻转的频率，把最不稳的排在前面。不用再翻原始的 Actions 日志，你就能看清哪条 spec 在拖垮你的信心、已经这样多久了。

Heal Queue：drift 还是 bug

一次红色运行无非两种情况：要么 UI 挪了位置、测试需要换新 selector（drift），要么应用真的坏了（bug）。Hover Cloud 会给每个失败分类，丢进一个 Heal Queue。属于 drift 的，把一条 heal 命令回传到你的编辑器，你在本地修好、审一遍 diff；属于真 bug 的，就一直标记着。云端绝不会自作主张重写你的 spec。

业务图与知识库

Cloud 会读取你 repo 里已经提交在 .hover/ 下的业务图和记下来的规则。你会拿到一张流程覆盖图（哪些区域测到了、哪些还是缺口），以及一条 Hover 摸清你应用的规则时间线，全团队都看得到。

告警、PR 摘要、环境

本来绿的套件一开始失败，回归告警就通过邮件或 Slack 通知你。Pull request 上会附一条覆盖说明和一段大白话的失败摘要。环境功能让同一套件分别面向 staging、production 或预览部署，而测试账号的 secret 不会写进 spec。

它不跑浏览器

执行始终在你自己的 CI、花的是你自己的 Actions 分钟数，Cloud 只读结果。你的 spec 一直是 repo 里普通的 @playwright/test，哪天不想用 Hover 了，每条测试照样跑。这正是CI 里不留模型的自愈闭环，只不过延伸到了你的整个团队。

开始

用 Hover MCP 写好 spec，在 CI 里跑起来，再到 cloud.gethover.dev 接入 repo。Cloud 文档会带你走一遍接入 repo、配置环境和跑通 heal 闭环的全过程。