Arm `cleanroom` as a required status check — it fails honestly now but still cannot block a merge, and nothing tracks the arming step

[yakimoto]

Finding

registry clean-room acceptance now fails honestly on every trigger (that landed in #82, after #79 merged green on a run whose own log said REGISTRY CLEAN-ROOM FAILED: 8 check(s)). But it is still ADVISORY: a red cleanroom cannot block a merge, and nothing in this repo tracks the step that would change that.

Measured 2026-09-05

Rules actually in force on wave-av/sdks main:

gh api repos/wave-av/sdks/rules/branches/main
  deletion               <- org ruleset 20872817 (governance-c-branch-integrity)
  non_fast_forward       <- org ruleset 20872817
  required_status_checks <- org ruleset 17334941 (public-repo-guard-required)
                            contexts: ["Secrets + content policy"]

gh api repos/wave-av/sdks/branches/main/protection returns 404 Branch not protected — expected on a ruleset-protected repo, and exactly the response that makes a naive check read as "unprotected".

Control, so the short list above is a measurement and not a read-permission artifact: the same endpoint on a sibling repo returns a populated list (wave-av/wave-gateway -> enforce, gate / checks, conformance-smoke (T2 authed vs api)). The two public sibling SDK repos (wave-av/cli, wave-av/sdk-python) match sdks: Secrets + content policy only.

So: cleanroom is genuinely not required, on this repo or on either sibling whose artifacts it tests.

Why it is not required today, and why that is defensible for now

.github/workflows/registry-cleanroom.yml states the reasoning in its own header: the gate tests PUBLISHED artifacts, so an sdks PR can red it for a defect that PR did not introduce and cannot fix (see #85, #86 — both blocked on an operator-gated publish in a different repo). Making it required today would train reviewers to override a required check, which is worse than not having one. The stated arming condition is: required once GA-READINESS.md's "Arming window" reports zero outstanding clean-room failures.

That reasoning is sound. The gap is that nothing tracks the arming step, and the ledger it keys on is already stale.

Work

1. Refresh GA-READINESS.md's "Arming window" from a live gate run. It currently lists 7 outstanding failures including wave-av-sdk@2.0.0; the live count is 5 (wave-av-sdk 3.0.0 was published 2026-09-05T03:17:38Z and both of its checks now PASS). The ART-001 / VER-001 / SUPPLY-001 evidence blocks carry verified_revision / sha256 fields, so refresh them from a real run rather than hand-editing the prose.
2. Clear @wave-av/cli@1.0.8 fails 3 registry clean-room checks (no provenance, version lie, floating first-party range) — needs a republish #85 and wave-sdk@2.0.0 on PyPI is unimportable (top-level wave shadows the stdlib) — fixed in wave-av/sdk-python source, needs a publish #86 (both need only a publish).
3. When a full gate run is green, add cleanroom to the required contexts on main — a ruleset write, so operator-gated.
4. Consider the same for wave-av/cli and wave-av/sdk-python, since their artifacts are what the gate mostly tests.

Until step 3 lands, a gate that correctly finds five real published-artifact defects still cannot stop a merge. That is a quieter false green than #79's, but it is the same shape.