Full sweeps of 2026-09-26 failed and were recorded nowhere; the sweep alert itself failed #482

Summary

The two full sweeps dispatched on main on 2026-09-26, after the pin moved to mcpp 2026.9.26.2 (#470), failed, and no issue recorded either failure. The scheduled sweep of 2026-09-27 passed every member. This issue records the three readings and the two defects that kept the failures unread (the review of 2026-09-28, mcpp-community/mcpp .agents/docs/2026-09-28-ecosystem-review-of-two-days-of-mcpp-and-xlings.md §3.6; task N3 of the design that answers it).

Readings

Why nobody read them

1. The alert job failed. full sweep failed — open an issue checks nothing out, so gh issue list could not infer the repository: failed to run git: fatal: not a git repository. The sweep that should have opened an issue opened none. It also did not run for the first failure, because it watched only the workspace job, not mirror-cn-reachable.
2. No record said which members were red for a known reason. A red sweep lists failed shards; which member failed, and whether someone owns it, has to be dug out of the logs.

Changes

The pull request that moves this index to mcpp 2026.9.28.2 carries both fixes:

• the alert job names the repository (GH_REPO) and also runs when mirror-cn-reachable fails;
• tests/known-red.tsv lists the members known to fail, per leg, with the issue that owns each; the job red members name their issues (tests/red_members.py) lists every failing member with its issue in the run summary, and fails when a failing member has none, or when the members' job failed and no member row can be attributed.

The pull request's full sweep is the first reading under the new rule. pangocairo passed on 2026-09-27, so the list starts empty; if it fails again it gets its own issue and a line.