coverage-evidence: trusted coverage tool image build fails — requirements-noema-document-ci-hashes.txt never staged into build context, blocks every PR's opencode-review #2273

Symptom

coverage-evidence (part of the opencode-review gate) fails on every PR with:

#13 ERROR: failed to calculate checksum of ref ...: "/requirements-noema-document-ci-hashes.txt": not found
ERROR: failed to build: failed to solve: failed to compute cache key: ...
##[error]Trusted coverage tool image build failed before PR execution.

Observed live on .github PR #2065 (run 35283384170, job 105472318967, head f2b5ecae4865ef2ba630d15abcde007ba57bd126, base a1d00341a5d559d99e36e1c0d575c1597a9f88ba). Because coverage-evidence fails, opencode-review publishes COVERAGE_BLOCKED / REQUEST_CHANGES regardless of the PR's actual diff — PR #2065's own diff is one .gitleaks.toml allowlist entry, unrelated to this failure.

Root cause

opencode-review-dispatch.yml's coverage-tool-image build step assembles a minimal Docker build context in $coverage_build_dir before invoking docker build. The trusted Dockerfile heredoc COPYs two requirements-hash files:

COPY requirements-opencode-review-ci-hashes.txt requirements-noema-document-ci-hashes.txt /tmp/
RUN python3 -m pip install ... -r /tmp/requirements-opencode-review-ci-hashes.txt -r /tmp/requirements-noema-document-ci-hashes.txt ...

But the staging step right before the Dockerfile heredoc only copies the first file into that context:

trusted_ci_requirements="${GITHUB_WORKSPACE}/requirements-opencode-review-ci-hashes.txt"
...
install -m 0644 "$trusted_ci_requirements" \
  "$coverage_build_dir/requirements-opencode-review-ci-hashes.txt"

There is no matching trusted_..._requirements variable, existence/symlink check, or install -m 0644 call for requirements-noema-document-ci-hashes.txt, even though that file exists at the repo root on main (git ls-tree confirms it). The docker build context is the narrow $coverage_build_dir, not the full checkout, so the second COPY target is genuinely absent from what Docker sees — this is a real build defect, not a scanner false positive.

Why it started now

git log --oneline -- requirements-noema-document-ci-hashes.txt on main shows it was introduced by #2172 (04d0f65b, "fix(noema): extract office documents for review context"), which added the second requirements file and the Dockerfile's second COPY/-r reference but did not add the corresponding staging line. #2191 (open, coverage-only follow-up to #2172) doesn't touch this workflow file, so it doesn't fix this either.

Why it will affect every PR

coverage-evidence runs as part of the required opencode-review gate for every repository that routes through this central dispatch workflow, so every PR that reaches this step hits the same Docker build failure and gets COVERAGE_BLOCKED regardless of its own diff.

Proposed patch (narrow, mirrors the existing pattern exactly)

In .github/workflows/opencode-review-dispatch.yml, alongside the existing trusted_ci_requirements block (~line 634 area):

trusted_ci_requirements="${GITHUB_WORKSPACE}/requirements-opencode-review-ci-hashes.txt"
trusted_noema_document_ci_requirements="${GITHUB_WORKSPACE}/requirements-noema-document-ci-hashes.txt"
trusted_base_python_installer="${GITHUB_WORKSPACE}/scripts/ci/install_base_python_locks.py"
...
if [ ! -f "$trusted_noema_document_ci_requirements" ] || [ -L "$trusted_noema_document_ci_requirements" ]; then
  echo "::error::Trusted Noema document CI requirements must be a regular non-symlink file."
  exit 1
fi
...
install -m 0644 "$trusted_ci_requirements" \
  "$coverage_build_dir/requirements-opencode-review-ci-hashes.txt"
install -m 0644 "$trusted_noema_document_ci_requirements" \
  "$coverage_build_dir/requirements-noema-document-ci-hashes.txt"

i.e. add one variable, one symlink/existence guard, and one install -m 0644 call, following the exact shape already used for requirements-opencode-review-ci-hashes.txt. No Dockerfile change needed — only the context-staging step is missing its second file.

Notes for whoever picks this up

• I am not implementing this myself: my session is restricted to a single designated branch in this repo, which already carries an unrelated open PR (fix(security): allowlist redaction-test fixture strings in gitleaks config #2065, .gitleaks.toml only), and mixing this infra fix into that PR would violate this repo's single-writer/no-widening convention (see the fix(governance): enforce satisfiable solo-maintainer rulesets #1176 precedent in bandscope, and this repo's own "Supersession and constant-change review" guidance).
• This is release-blocking for the whole org's opencode-review gate, not a single-repo concern — worth prioritizing over the two independent false-positive findings in python-security/sast-semgrep: false-positive dynamic urllib-use findings (Bandit B310 + Semgrep dynamic-urllib-use-detected) now block every PR #2248, since those only fail two specific SAST rules while this fails 100% of coverage-evidence runs.
• Verify locally by reproducing the exact docker build --pull --no-cache --network=default --file "$coverage_build_dir/Dockerfile" "$coverage_build_dir" invocation from the workflow after staging both files, to confirm the fix actually gets past the COPY step before merging.