Hover/docs
EN中文
← HomeGitHub

Runs, alerts & self-heal

Once CI reports to Cloud, the project page becomes the place you watch your suite: run history, per-spec results, PR checks, regression alerts, and the self-heal queue. All of it is computed from what your CI already ran.

Triggering a run

  • Run now dispatches the workflow against the selected environment. A live "running" banner appears while CI works, and the result drops in when the reporter step finishes — the page refreshes itself, no manual reload.
  • Pull requests always run. Cloud posts a summary comment on the PR with the pass/fail/flaky verdict and a short diagnosis of any failure.
  • Scheduled runs (see Team & lifecycle) monitor a chosen environment on a cron.

Reading results

The project page lists runs for the selected environment with their spec counts, branch, source, and time. Open a run for the detail: each failing spec shows its error, the failing locator (the heal hint), and links to the CI log. If your CI uploaded traces or reports as artifacts, they're linked at the top of the run — they download straight from GitHub, since that's where they live.

Open pull requests get their own strip on the project page: one chip per branch, colored by its latest verdict, linking to the run.

Regression alerts

A regression is when the previous run on the same environment and branch was green and this one is red. When Cloud sees that on ingest, it alerts — by email to the project's team, and to Slack if you've configured a webhook. PR runs don't alert (the PR comment already covers them); this is for your default branch and your monitored environments.

Self-heal orchestration

When a spec drifts — a selector moved, a label changed — Cloud queues a heal request for it. This is where the "AI only on what already ran, fixes stay local" rule plays out:

  1. Cloud detects the failure on ingest and opens one heal request per drifted spec (deduplicated — one open request per spec).
  2. Cloud routes it to your editor. Nothing in the cloud can reach your machine, so your VS Code extension and MCP agent pull the queue (see Connect your editor).
  3. You heal locally. Your own coding agent re-locates the element in your real browser via /mcp__hover__heal <spec>, and you review the diff before keeping it.
  4. CI closes the loop. The heal request auto-closes only when CI sees that spec pass again — never on an editor claim, never by Cloud rewriting your code.

Where the AI runs

The diagnosis and PR summary are generated Cloud-side (a small model first, escalating only if needed) on the already-failed result. The heal itself runs in your editor, on your model, against your real browser. Cloud orchestrates; it doesn't execute.

What's next