[Reproducibility] Central coverage-evidence runner's uv version drifts, breaking repos that pin an exact uv required-version

[seonghobae]

Observed behavior

ContextualWisdomLab/.github's opencode-review-dispatch.yml coverage-evidence job failed for ContextualWisdomLab/RankWeave PR #36 (run 32571503654, 2026-08-22T11:53:34Z) with:

##[error]Could not materialize base Python locks: uv export failed for tracked base lock uv.lock: error: Required uv version `==0.11.29` does not match the running version `0.12.1`. Update `uv` by running `uv self update 0.11.29`.

RankWeave's pyproject.toml pins [tool.uv] required-version = "==0.11.29" intentionally, for build reproducibility. This is not a defect in RankWeave's PR — the diff under review didn't touch the uv pin at all. The central runner simply has a newer uv (0.12.1) installed than the target repo's own lockfile requires, so uv export refuses to run.

I independently reproduced the same failure class locally earlier this session: my local Homebrew uv was 0.12.0/0.12.1 at different points, also mismatched against RankWeave's 0.11.29 pin — I worked around it locally with mise install uv@0.11.29, but the central CI runner has no equivalent per-repo version resolution.

Why this matters

This is the same shape of bug as the EBADDEVENGINES npm devEngines.packageManager mismatch found earlier this session for JS-repo coverage-evidence runs (a fixed central tool version colliding with a target repo's own pinned tooling version) — just for Python/uv instead of npm. Any repo in the org that pins an exact uv required-version (a reasonable reproducibility practice, not a misconfiguration) can hit this the moment the central runner's installed uv drifts past that pin, and it will silently block that repo's OpenCode review approval with a message that looks like a real coverage failure rather than an infra mismatch — exactly what happened here: a real, current-head CHANGES_REQUESTED review citing "coverage evidence did not pass," when the actual cause was invisible to the PR author without digging into the central run's own log.

Suggested direction

The central coverage-evidence job (in opencode-review-dispatch.yml, scripts/ci/materialize_base_python_requirements.py or wherever the uv invocation lives) should read each target repo's own [tool.uv] required-version (if present) and install/select that exact uv version for that repo's coverage run, the same way per-repo Python version pins are presumably already respected — rather than relying on one fixed uv version baked into the runner image/setup step that drifts independently of what repos actually declare.

Cross-reference

Discovered while working ContextualWisdomLab/RankWeave PR #36 through the review→fix→merge loop this session; dismissed the resulting stale-looking-but-actually-infra-caused CHANGES_REQUESTED review on that PR with this same root-cause evidence rather than treating it as a real PR defect.

[seonghobae]

BandScope confirms this JavaScript/npm fixed-tooling mismatch again on the current canonical dependency-security head; the earlier evidence below remains historical but the owning failure class is still structurally present on protected central main.

Current exact evidence (2026-08-24/25 run):

• Target: ContextualWisdomLab/bandscope PR release: provide organization-owned exact-artifact SBOM attestation workflow #783, exact head 1168c8f4257de5de036ea54bf5ee73edb83e775e, protected base develop@acdbea6344fe1231c39535b575f4de35e4c607c9.
• Central protected source: .github/main@613a33e0cb1c6db9790fae99f6253445712ac37a.
• Current OpenCode dispatch: run 32755272356; coverage-evidence job 97535668597 is terminal-failure while source-tree materialization/syntax validation completed before the measurement boundary.
• Downloaded current coverage-source artifact 9532203044 materializes merge tree d1b0d80e4dd52588509bca8a3bb42909c79d3da2 (acdbea6 + exact PR head), so this is current-head evidence rather than predecessor source.
• That exact tree declares packageManager: npm@10.9.9 and devEngines.packageManager.version: 10.9.9 with onFail: error.
• Current central opencode-review-dispatch.yml@613a33e… builds the trusted coverage image with Node v24.18.0, only checks its bundled /usr/local/bin/npm --version, then later executes npm ci for the materialized base JavaScript packages; it does not activate the target repo's declared npm version before that install.
• Independent reproduction against the downloaded exact source tree proves the boundary is version-sensitive before dependency resolution: running npm ci --ignore-scripts --offline --no-audit --no-fund with npm 10.9.2 exits immediately with EBADDEVENGINES because required npm is exactly 10.9.9. Therefore any trusted-image npm different from 10.9.9 cannot consume this repo without violating the repo's declared reproducibility contract.

This does not justify a BandScope-local relaxation: #783's exact npm pin is itself part of the dependency/toolchain provenance repair and all nine repository-local workflows on the current head are terminal-success. The central boundary must select a trusted npm matching the target repo declaration (or fail closed for an untrusted/unsupported declaration) before npm ci.

Acceptance test remains: a central fixture whose target package declares exact npm 10.9.9, while the base image bundles a different npm, must install/select a trusted 10.9.9 and complete the trusted package-cache build; malformed/unallowlisted package-manager declarations must fail closed. The coverage job must then reach target tests rather than fail in trusted-image preparation.

Historical first exact occurrence (retained for lineage): run 32556868193 / job 96992386526, BandScope #783 predecessor head 96674b27852bb874e549831cbbb4f2bb122deb2b, where the job log explicitly recorded bundled npm 11.16.0 versus required 10.9.9 and Trusted coverage tool image build failed before PR execution.

[seonghobae]

Second confirmed occurrence, ~2 days after filing: ContextualWisdomLab/RankWeave PR #40, coverage-evidence run 32702752567 (dispatched via .github#1127), same annotation:

Could not materialize base Python locks: uv export failed for tracked base lock uv.lock: error: Required uv version ==0.11.29 does not match the running version 0.12.1.

This produced a real opencode-agent CHANGES_REQUESTED review on PR #40 citing the failed coverage-evidence as the sole reason — the PR's own diff was unaffected (RankWeave's own coverage-evidence GitHub Actions check on the identical head passed on a later retry: 661 tests, 100% coverage). Dismissed the stale review with this evidence rather than editing the PR.

This confirms the drift is not a one-off: the central runner's uv version has been observed at 0.12.1 on two separate occasions across a multi-day span, while RankWeave's pyproject.toml still pins ==0.11.29. Recommend prioritizing the fix (reading each target repo's own [tool.uv] required-version, or pinning the central runner's uv install itself) since it's now producing false CHANGES_REQUESTED reviews on unrelated PRs, not just failed runs.

[seonghobae]

Third confirmed occurrence within the same dispatch wave (RankWeave PR #41, 14:45:34Z) -- same run type (OpenCode Review Dispatch, .github#1127), same annotation. All three (PR #40, #36, #41) dismissed with evidence.

Precise root cause (correcting my earlier "drift" framing): this is not version drift over time. scripts/ci/materialize_base_python_requirements.py hardcodes a single trusted, SHA256-pinned uv binary:

TRUSTED_UV_VERSION = "0.12.1"
TRUSTED_UV_ARCHIVE_SHA256 = "90b2f223fb69d19db49e117da601f64978593417988530aa733d456141b4bcbb"

_install_trusted_uv() downloads and verifies exactly this one version every run (deliberate supply-chain hardening -- not a stale/undertended runner). _run_uv_export() then calls uv export --frozen against the target repo's own reconstructed pyproject.toml/uv.lock. uv export --frozen itself enforces that the invoking uv's version matches the project's own [tool.uv] required-version pin -- this is real uv CLI behavior, not a bug in this script. So any repo pinning a required-version other than exactly 0.12.1 can never pass this step, permanently, regardless of how recently the runner or the repo's pin was touched. RankWeave pins ==0.11.29 (in pyproject.toml plus 4 astral-sh/setup-uv version: fields across its own CI/release workflows) -- a structural mismatch, not drift.

Two independent fix directions, either sufficient on its own:

1. Central: extend the trusted-uv mechanism to a small {version: sha256} registry, select the entry matching the target repo's own declared required-version, and fail closed (as today) for any unlisted/untrusted version. Correct general fix, but nontrivial and security-sensitive (each new entry needs an independently verified SHA256) -- not something to rush.
2. Per-repo: repos pinning a required-version other than 0.12.1 (RankWeave included) bump their own pin to match. Simpler, lower blast radius, but a discretionary architecture decision each affected repo's owner should make deliberately (lock regeneration + full CI re-verification), not something to bolt onto a reactive review-dismissal fix.

Not attempting either from this session right now -- flagging with full precision so whoever picks this up (central-repo owner or each affected repo) has the exact mechanism, not just the symptom.