[ci] Every scheduled `check-links` sweep since the cron landed has failed — 5 of 5, and the last green run predates the scope that made the sweep meaningful

[baozhoutao]

Found while implementing objectui#7956 (deriving a job ceiling for check-links.yml::check-links from its own run distribution). Choosing the right sample forced this reading out; recording it rather than acting on it, because fixing broken links is not that card's scope.

Attribution as prose: generated by Claude Code, dev session session_01FhBNJcLRZLe8M87VcUgpKr, while implementing objectui#7956.

The measurement

Repo-scoped Actions REST, measured 2026-09-06T17:23Z.

GET /actions/workflows/check-links.yml/runs?event=schedule  -> total_count 5, all conclusion: failure

created	job wall clock	Lychee step	conclusion
2026-08-09T04:43Z	15s	9s	failure
2026-08-16T04:28Z	31s	24s	failure
2026-08-23T04:29Z	19s	10s	failure
2026-08-30T04:28Z	24s	17s	failure
2026-09-06T04:28Z	26s	20s	failure

Five scheduled sweeps, five failures. The cron (17 4 * * 0) landed with the scope fix; every run it has produced has been red.

⭐ The part that is easy to misread

?status=success returns a total_count of 217 for this workflow, which reads like a healthy history. Every one of those 217 is from 2026-01-24 .. 2026-01-28, on push and pull_request — triggers this workflow no longer declares — under the scan scope it had before objectui#3449 pointed it at the published tree. Those runs are a different job wearing this job's name.

⇒ The last time this sweep passed while looking at what it looks at today is never.

That matters beyond this card: objectui#3449's own argument was that the workflow had been "green because of what it was not looking at". Widening the scope worked exactly as intended — it turned a false green into a true red — and the red has been sitting there unread ever since.

Where it fails

Step-level detail from /actions/runs/ID/jobs shows Check links with Lychee reaching failure after 9-24s and the job then running its post steps normally. So the sweep COMPLETES and the failure is its verdict: fail: true plus at least one link Lychee could not accept.

⚠️ This card does not name which links. The run logs were outside what the API served here, and the honest next step is one workflow_dispatch run with its summary read — Lychee reports what it scanned and what it rejected.

Why nobody noticed

By design, and the design is defensible: check-links.yml's own header says the two disabled triggers stay disabled because an external link check goes over the network and "this workflow blocks nobody, so flakiness costs a second look and nothing else". It produces no required status check (re-measured on GET /repos/objectstack-ai/objectui/rules/branches/main at 2026-09-06T17:20Z). The cost of that choice is the one being paid: a workflow nobody is blocked by is a workflow nobody looks at, and its report has been red for a month with nothing surfacing it.

What triage decides

Two questions, and the second one is the real card:

1. The links. Dispatch it once, read the summary, fix or exclude what it names. Possibly small.
2. The reporting. A weekly sweep whose only output is a red mark on a page nobody opens is the same shape as the mechanism it replaced. Something has to carry the verdict to a person — a job summary is already written, an issue could be opened or updated, or the result could ride a page someone reads. ⛔ Not proposing which; that is a decision, and it should be made once rather than guessed at here.

⛔ What this does NOT claim

• ⛔ Not a claim that the sweep is wrong to be red. If there are broken external links, red is correct — that is the workflow working.
• ⛔ Not a claim that the two commented-out triggers should be enabled. objectui#3213's ruling B still stands and this card does not reopen it; a flaky third-party host must not redden an unrelated pull request.
• ⛔ Not a claim that this blocks anything today. Nothing is gated on it. The loss is that the sweep's answer, correct and freshly produced every Sunday, reaches no one.

Refs: objectui#7956, objectui#3449, objectui#3213, objectui#7825.