The hosted E2E lane is MONTH_EXCEEDED again (30/30 in five days) — and CLAUDE.md still says it is unblocked

[TortoiseWolfe]

UPDATE 2026-09-09 — the trigger half SHIPPED. Only the aggregate is left, and it is still
moot until the quota resets on 2026-10-02.

The section below headed "the finding that probably changes the answer" said the hosted lane
still triggers on every push and every PR, and asked for that to be split out. It was
(#1119) and it landed today: the lane now runs on push-to-main, the Monday cron,
workflow_dispatch, and a full-e2e-labelled PR only.

That also removed a cost this issue did not account for: a blocked trigger was never free.
budget and hosted-lane-status are ordinary jobs, so each of the 61 blocked triggers booted
two runners to render a red X — roughly 122 runner-starts in five days that tested nothing.

Still open, unchanged: no E2E (hosted) result aggregate exists, and building one now
would report "did not run" on every PR while the lane is month-blocked. Revisit after
2026-10-02.

Also note: an ordinary PR now produces NO hosted-lane run at all, so Hosted E2E lane
and Cloud-quota budget reporting nothing on a PR is normal rather than a symptom.

---

The legibility work this issue asked for shipped in #1076/#1077 and demonstrably works. The
lane is quota-blocked again as of 2026-09-07, and this time genuinely — so the opening claim
below is now the stale part.

Current state, measured

Run 34165165127 (push to main, 2026-09-07T22:06:08Z), Cloud-quota budget job:

last 24h ....... 8 / 10
this cycle ..... 30 / 30   (since 2026-09-02)
mode ........... block
verdict ........ MONTH_EXCEEDED
##[error]E2E blocked by the cloud-quota circuit breaker — 30 E2E runs this billing
cycle, limit 30.

8/10 on the day window is the proof that matters: this is not the daily rate limiter that
ordinary work trips. The monthly cap is actually spent, five days into the cycle.
MONTH_LIMIT = 30 at scripts/ci/e2e-budget-guard.mjs:52. It resets on the 2nd, so the lane is
dark roughly 25 days.

What shipped, and is working

From the same run's Hosted E2E lane job — the availability report this issue asked for, doing
its job on the first real MONTH_EXCEEDED since it landed:

##[warning]Hosted E2E did NOT run: the cloud-quota guard blocked it.
  lane ........... BLOCKED by the cloud-quota guard — no tests ran

All four fixes verified present: scripts/ci/e2e-report-verdict.mjs invoked at
e2e.yml:1353-1355 under if: always(); the list reporter alongside blob on the shards;
Hosted E2E lane reporting RAN / BLOCKED / NOT CONFIGURED; and the budget guard's two-window
summary.

Unproven: the red path of the Test Report verdict has never fired in production — every
hosted run since #1076 was fully green. It is covered by unit tests only, and #1077 exists
because the first cut got the Playwright error shape wrong.

What remains

1. Correct the documentation, which now says the opposite of the truth. CLAUDE.md:441
reads "THE HOSTED LANE IS NOT DEAD, AND HAS NOT BEEN SINCE 2026-09-02 (#1069)". Read today,
that teaches a reader that a red Cloud-quota budget is the old ignorable state — precisely the
misreading this issue was opened to prevent, inverted.

2. The always-reporting aggregate is still genuinely open, verified rather than assumed: no
E2E (hosted) result job exists in e2e.yml, and branch protection still lists exactly the
seven documented contexts. It is also moot until 2026-10-02 — with the lane month-blocked,
an aggregate would report "did not run" on every PR.

The finding that probably changes the answer

The lane burned its whole month in five days: 30 quota-consuming runs out of 91 triggered
since 2026-09-02 — 36 triggers on 09-06 and 31 on 09-07 alone. That is #567's pattern repeating.

The guard's own comment (e2e-budget-guard.mjs:46-51) prescribes the cure: "If this fires
during normal work, the answer is #575 (move E2E off the shared cloud project), not a bigger
number here." But #575 already shipped — E2E (local) result is required and gives every
PR its coverage. The hosted lane is now supplementary, yet still triggers on every push and
every PR (e2e.yml:4-56). Nobody revisited its trigger set after the local lane became
required.

Narrowing it — push-to-main and schedule only, say — would likely keep the lane alive all month
on the same quota. Split out as its own ticket.

Refs #567, #575, #1076, #1077.