coverage-evidence: trusted coverage image build fails at base VCS step — 'locked VCS source fast-mlsirm has a missing or ambiguous import root' blocks every contextual-orchestrator PR

[seonghobae]

Problem

The central coverage-evidence job now fails before any PR code runs for ContextualWisdomLab/contextual-orchestrator PRs. The trusted coverage tool image build aborts at docker step #17 (install base VCS dependencies → opencode-base-vcs-dependencies.pth), so every contextual-orchestrator PR gets COVERAGE_BLOCKED regardless of its diff.

Evidence

Run https://github.com/ContextualWisdomLab/.github/actions/runs/34754638830/job/103717614270 (contextual-orchestrator#1166, head 17d6043e):

#17 [12/14] RUN set -eu; mkdir -p /opt/base-vcs-dependencies; ... path_file="${site_packages}/opencode-base-vcs-dependencies.pth" ...
#17 1.141 locked VCS source fast-mlsirm has a missing or ambiguous import root for fast_mlsirm
#17 ERROR: process "/bin/sh -c set -eu; ..." did not complete successfully
##[error]Trusted coverage tool image build failed before PR execution.

Same failure on contextual-orchestrator#1167 (head de27f3e3) and #1171 (head c6bdb713), all on 2026-09-13. None of the three diffs touch fast-mlsirm, requirements*.txt, or pyproject.toml.

Analysis

The base-image step resolves the locked fast-mlsirm @ git+… VCS dependency and expects to locate a single Python import root for fast_mlsirm. fast-mlsirm is Rust-first (maturin, fast_mlsirm._core), so its checkout has no unambiguous pure-Python package root; the step treats that as fatal instead of deferring.

This is a different failure mode from #1292 (which reaches pytest collection and fails on fast_mlsirm._core imports) and from #1250 (stale hash-lock / pnpm flag): here the image build itself fails, so consumer repos of fast-mlsirm are blocked, not only fast-mlsirm.

Expected

Either build the fast-mlsirm import root correctly (maturin/source layout aware) or classify the missing import root as DEFERRED evidence for consumer repos, so a contextual-orchestrator PR is judged on its own coverage instead of failing at image build.

Related: #1292, #1250, #1234.

🤖 Generated with Claude Code

[seonghobae]

Existing repair/integration evidence: PR #2123 remains OPEN at 7e3b1a40c7519409a6187a32332bfea210012487 (not merged). It adds the conventional python/<import> candidates to the trusted VCS materializer.

I read failing run 34754638830/job 103717614270: its materialization command still enumerates only src/<import>, src/<import>.py, root <import>, and root <import>.py. The consumer base is 012beaacd0631f8cd3391c77744eeb626269b5de, whose lock pins fast-mlsirm to 09f762ded35786dd1078222a4577ff09d649816f. This supports the existing repair not yet being integrated; it does not establish a newly changed dependency layout. The raw job does not identify a central workflow SHA, so no exact central SHA is asserted here.

Next step is to finish #2123's review/security remediation and revalidate the unchanged locked source through the trusted image build. Its pip-audit job 103582668686 reports known-vulnerable dependencies; I am retrieving the detailed audit evidence and will not bypass that finding. Do not weaken missing/ambiguous-root rejection or alter consumer source merely to get past this image-build failure. This comment is investigation evidence, not resolution of #2157.

[seonghobae]

Correction on the #2123 pip-audit evidence cited above: job 103582668686 contains no vulnerability findings — every audited file logs No known vulnerabilities found. The non-zero exit comes from the requirements-opencode-review-ci-hashes.txt group, where pip-audit 2.10.1 raised an unhandled ConnectionResetError: [Errno 104] Connection reset by peer (pip_audit/_service/pypi.py:64, PyPI advisory query). The workflow's single status=1 path then printed the misleading "known-vulnerable Python dependencies" message. Filed as #2158. So #2123's blockers are: (a) DIRTY — conflicts in CHANGELOG.md and tests/test_opencode_agent_contract.py (measured against main 64f483db9), and (b) gateway noema/opencode verdicts; the pip-audit check just needs a rerun on the next head, not dependency remediation.

[seonghobae]

#2123 merged to main as ebc69a401 (2026-09-13 23:37Z) via the §11 infrastructure bypass; evidence (pinned fast-mlsirm python-source = "python" layout verified at 09f762ded, local exact-head 3078 passed / cov+doc 100%, failing checks = CodeQL placeholders + runner-queue saturation) is in the PR comment. Not closing this issue yet: closure needs one consumer re-run — a contextual-orchestrator PR (e.g. #1145/#1166) whose coverage-evidence job gets past docker step #17 (opencode-base-vcs-dependencies.pth) with the central workflow at ≥ ebc69a401. Whoever sees that run first: link the job id here and close.

[seonghobae]

Repair #2123 merged into org main (ebc69a401). Re-validation in progress: contextual-orchestrator#1145's opencode-review run 34763155674 was re-run in full so the coverage gate rebuilds the trusted image with the python/<import> candidate. Will close this issue once that gate reports something other than the step #17 import-root failure.