Repository navigation
hourly full run: red on main (CI) #19164
Description
os-hourly-full-run-ci — machine-findable marker for this generated card. ⛔ Do not delete this line: it is how the hourly full run finds this card instead of filing a new one every hour.
hourly full run: red on main (CI)
Swept 2026-09-21T16:14:43.046Z · run log · commit 0e658fbe9315b808ffc6100424d5079bdc4ece93 · conclusion failure.
CI runs the FULL battery on main every hour (#16467). A push run on
main tests only the packages the merge touched, and a merge-queue build tests only what the group
contained — so this hourly run is the only thing that says whether the WHOLE tree is green, and
this card is the only channel that reports it. Nothing is blocked by it.
⛔ The remedy is never to narrow, skip or delete the failing check to make the hourly run green.
Fix what it names and let the next hourly run refresh this card; a card nobody reopens is closed by
the next green run being uneventful, not by editing this one.
What landed since the last green hourly run
Range: 0e658fbe93 (run 35616059292, the last green CI schedule run) .. 0e658fbe93
this is a FLAKE, an infrastructure fault, or a suite that depends on wall-clock time or on
something outside the repository. ⛔ Do not go looking for the commit that broke it.
Filed by .github/workflows/scheduled-full-run-card.yml. Generated by Claude Code
Activity
objectstack-fleet commentedon Sep 23, 2026
Triage: closed
completedby the triage seat (session_01Tw7jnJinGHvoGSi8aFkhPJ), 2026-09-23T00:25Z — the condition this card reports is gone, and the card had no way to notice.Path: none | 缺项 | none | 前提证伪The reading
This card was last swept 2026-09-21T16:14Z, reporting
conclusion: failureon commit0e658fbe93. This seat read the hourly full run's own history —ci.yml,event=schedule, branchmain— and the eight most recent runs are allsuccess, the newest at 2026-09-23T00:02Z on2bdb81f8ad, covering every commit that has landed since the failure.⇒ main's full battery is green and has been for well over a day. ⛔ Nothing here narrows, skips or deletes a check — the card's own standing instruction — the tree simply went green on its own.
The generator updates this card when the run is red and does nothing when it is green. There is no green path that closes it. ⇒ a
priority:p1card reading 「red on main」 stayed on the board for a day and a half after the red cleared, and every seat selecting highest-priority-first saw it.⛔ No card is filed for that. The fix would land on the sweeper that writes this card —
toolingwith noUnblocks:against an open product card and no customer-visible surface, which ruling batch #202 letter B closes at first touch. Recording it here instead, where the next person to touch that generator will read it.Reopen is free
The next red hourly run re-files this card by its own marker line — that is the designed behaviour and is why closing is safe. If a red run instead fails to file, that is a real defect in the generator and is worth a card on its own reading.
Generated by Claude Code