main carries a commit nothing verified

[github-actions]

main-canary.yml's check-main-verified.sh job found commit(s) on
main that nothing has verified — as distinct from a commit a check said
no about, which main-canary.sh's own issue already owns.

  cd7d53c  missing
      brand: adopt the Oxagen house system — palette, marks, and the face (#6473)
  a3a6294  missing
      chore(release): sync versions to 0.9.411 [skip release] (#6474)
  bfc63d0  missing
      fix(core,tools): place the deadline ladder against the turn's own budget, and stop search overclaiming (#6463)
  8c10e91  missing
      chore(release): sync versions to 0.9.410 [skip release] (#6472)
  508b6a0  missing
      build(deps): bump next from 16.2.11 to 16.3.3 in /website (#6469)
  c5c9e17  missing
      chore(release): sync versions to 0.9.409 [skip release] (#6471)
  778919f  missing
      chore(release): sync versions to 0.9.408 [skip release] (#6470)
  42c5e7f  missing
      chore(release): sync versions to 0.9.407 [skip release] (#6468)
  bb77ca5  missing
      fix(skills): aim the holdout at the skills whose control arm is short (#6459)
  7760b66  missing
      docs(scr): AGENTS.md names the closes-nothing waiver (#6452)

This is NOT "main is red". A failing run is a verified commit and the canary
owns that. These commits have no answer at all, which every other mechanism
here reads as green: the canary files only when its job runs and fails, the
red-main hold passes when no issue is open, and gh run list shows no row
for a run that was never created.

How to fix

Re-dispatch the missing runs and let them finish before merging onto this
tree:

gh workflow run ci.yml --ref main

An Actions incident is one cause. There the runs start on their own once
capacity returns, and nothing was checking, which is the part this exists to
fix. A push made with the token a workflow run holds is the other cause, and
the release version write-back is one of those: that push raised no event at
all, so no run was ever created and none is coming. Nothing will start on its
own. Ask for it:

./scripts/dispatch-main-verification.sh

Definition of done

• Every recent commit on main has a completed ci run.

This script closes the issue itself on its next run that can answer clean, so
a box nobody ticks costs the issue nothing.

[macanderson]

macanderson 761f9872befd382d

Implementing this. The claim lapses after 90 minutes, so it
cannot hold the issue shut if this session dies
(scripts/issue-claim.sh, #5224).
The second word is this session's own, so another session of the same author
reads this as somebody else's claim.

[macanderson]

This was a false positive, and PR #6479 fixes what produced it.

Each of the ten commits this issue names does have a completed, successful ci run. Re-running the exact query the script uses:

$ gh run list --workflow ci.yml --branch main --limit 60 --json headSha,status,conclusion,createdAt
cd7d53c9 completed success 2026-09-09T16:57:59Z
a3a62948 completed success 2026-09-09T07:12:01Z
bfc63d0b completed success 2026-09-09T06:17:43Z
8c10e917 completed success 2026-09-09T01:46:46Z
508b6a08 completed success 2026-09-09T01:21:26Z
c5c9e171 completed success 2026-09-09T00:43:26Z
778919f9 completed success 2026-09-09T00:19:57Z
42c5e7fa completed success 2026-09-08T23:54:56Z
bb77ca5e completed success 2026-09-08T23:25:57Z
7760b663 completed success 2026-09-08T23:25:52Z

./scripts/check-main-verified.sh against the current tree now prints OK — each of the last 10 commit(s) on main has a completed ci run. and exits 0.

The cause: the script guards its commit read for emptiness and never guards its run read. The matching loop opens every commit at missing and only a matching row moves it, so one empty page from the Actions API reports the entire window as absent in one breath — and gh exits 0 on an empty page, so the existing failed-call check never sees it. #6479 makes an empty run list an unknown that exits 0 and says so, which is what the script's own header already promised, with a negative control so a list that carries rows but none for a given commit still reports the outage this monitor exists to catch.

[macanderson]

Correction to my comment above: this was closed by #6477, not #6479. My diagnosis stands unchanged — an empty gh run list page reads as ten findings because the run read had no emptiness guard — but a peer session reached it in parallel and landed the fix first. I closed #6479 as a duplicate; #6477's version is the better of the two and its tests cover a case mine did not.