@wave-av/cli@1.0.8 fails 3 registry clean-room checks. The fixes exist in wave-av/cli source and are blocked only on a republish.
Grounded
Measured 2026-09-05 by running this repo's own gate against the LIVE public npm registry, from a clean detached worktree at origin/main (6fe7c01), with no checkout on any module path:
node scripts/ga/registry-cleanroom.mjs --python python3 --out-dir ga-out
-- npm-cli (npm: @wave-av/cli)
PASS install: installed @wave-av/cli@1.0.8 from https://registry.npmjs.org into a clean directory
FAIL npm-provenance-attested: @wave-av/cli@1.0.8 has NO provenance attestation on npm
(dist.attestations=null). The published artifact cannot be traced to an approved CI
build of an immutable source revision.
PASS bin-help-exit-zero: `wave --help` exited 0 (72 lines)
FAIL bin-version-matches-package: VERSION LIE: npm served @wave-av/cli@1.0.8 but
`wave --version` prints 1.0.0. A user cannot tell which build they are running,
and a bug report cannot be tied to a revision.
PASS bin-help-banner-version-consistent: help output advertises no version string
FAIL declared-dep-ranges-pinned: @wave-av/cli@1.0.8 declares floating first-party range(s)
@wave-av/sdk: "^2.0.11" — today they resolve to @wave-av/sdk@2.1.3, but tomorrow the
same published artifact can ship a different sibling with no commit anywhere.
The same three checks fail identically in CI on three unrelated PR branches (runs 33940473680, 33933317710, 33933289317 — the latter two are Renovate lockfile bumps that touch only sdk-typescript/pnpm-lock.yaml). This is a property of the published artifact, not of any branch.
Why a PR in this repository cannot fix it
@wave-av/cli is published from wave-av/cli, a different repository. All three root causes are already fixed on that repo's main (runtime version derivation instead of a hardcoded literal, npm publish --provenance under OIDC trusted publishing, and an exact pin of @wave-av/sdk). 1.0.8 predates all three. Nothing in wave-av/sdks can change what npm currently serves.
What clears it
An operator-gated publish of @wave-av/cli from wave-av/cli main. After that publish, re-run registry clean-room acceptance (workflow_dispatch, or wait for the 09:00 UTC nightly) and all three checks should flip to PASS with no source change in this repo.
Why this matters beyond three red checks
cleanroom is not currently a REQUIRED status check on main — the only required context is Secrets + content policy, from the org public-repo-guard-required ruleset (verified with a sibling-repo control, so the short result is a measurement and not a permissions artifact). The workflow's own comment makes arming it conditional on this backlog reaching zero. Until then the strongest artifact gate in the repo can fail loudly but cannot block a merge.
Related: #37 (broader artifact staleness), #42 (packages published from repos other than the one they declare).
@wave-av/cli@1.0.8fails 3 registry clean-room checks. The fixes exist inwave-av/clisource and are blocked only on a republish.Grounded
Measured 2026-09-05 by running this repo's own gate against the LIVE public npm registry, from a clean detached worktree at
origin/main(6fe7c01), with no checkout on any module path:node scripts/ga/registry-cleanroom.mjs --python python3 --out-dir ga-outThe same three checks fail identically in CI on three unrelated PR branches (runs 33940473680, 33933317710, 33933289317 — the latter two are Renovate lockfile bumps that touch only
sdk-typescript/pnpm-lock.yaml). This is a property of the published artifact, not of any branch.Why a PR in this repository cannot fix it
@wave-av/cliis published fromwave-av/cli, a different repository. All three root causes are already fixed on that repo'smain(runtime version derivation instead of a hardcoded literal,npm publish --provenanceunder OIDC trusted publishing, and an exact pin of@wave-av/sdk).1.0.8predates all three. Nothing inwave-av/sdkscan change what npm currently serves.What clears it
An operator-gated publish of
@wave-av/clifromwave-av/climain. After that publish, re-runregistry clean-room acceptance(workflow_dispatch, or wait for the 09:00 UTC nightly) and all three checks should flip to PASS with no source change in this repo.Why this matters beyond three red checks
cleanroomis not currently a REQUIRED status check onmain— the only required context isSecrets + content policy, from the orgpublic-repo-guard-requiredruleset (verified with a sibling-repo control, so the short result is a measurement and not a permissions artifact). The workflow's own comment makes arming it conditional on this backlog reaching zero. Until then the strongest artifact gate in the repo can fail loudly but cannot block a merge.Related: #37 (broader artifact staleness), #42 (packages published from repos other than the one they declare).