coverage-evidence sandbox never builds fast-mlsirm's compiled Rust extension, failing every test file that imports fast_mlsirm._core directly

[seonghobae]

Problem

The central coverage-evidence job (OpenCode Review Dispatch workflow, "Measure test and docstring evidence" step) fails fast-mlsirm#951 at current head 286bd2dbba5da8348643b6ad8145967972813ae9 with Coverage Decision: FAIL, Failure count: 2 — but neither failure reflects a real problem in the PR's diff.

Evidence

Run: https://github.com/ContextualWisdomLab/.github/actions/runs/32620501327/job/97147899712

Failure 1 — 11 test files fail to collect:

collected 4609 items / 11 errors / 1 skipped
...
tests/test_cat_rust_ownership.py:14: in <module>
    import fast_mlsirm._core as core
E   ModuleNotFoundError: No module named 'fast_mlsirm._core'

(same for test_cat_selection_rust_ownership.py, test_cov_f_fit.py, test_inference_nonfinite_uncertainty.py, test_inference_rust_vcov_ownership.py, test_linking_fixed_anchor_rust_ownership.py, test_observed_information_rust_ownership.py, test_observed_information_work_budget.py, test_rt_rust_max_iter_backstop.py, test_test_form_rust_ownership.py, test_validation_policy_contract.py)

I confirmed these same unguarded import fast_mlsirm._core as core module-level imports already exist on main today (e.g. tests/test_cat_rust_ownership.py), not introduced by PR #951 — so this isn't the PR's doing. fast-mlsirm is Rust-first by design (ARCHITECTURE.md/CLAUDE.md: "the Rust core is the primary numeric path," built via maturin as fast_mlsirm._core), and these specific test files are the fail-first ownership contracts that require the compiled core to exist — a graceful skip isn't appropriate for them (that would silently hide a rust-ownership regression). The coverage-evidence sandbox apparently never builds this extension (the log shows no maturin/cargo build step at all, only pip-level Python toolchain checks), so any PR touching these paths — or possibly any fast-mlsirm PR at all, since these files are unconditionally collected — hits 11 fatal collection errors before a single test in the affected files can run.

Failure 2 — GPU parity test:

$ pytest tests/test_marginal_parity.py::test_marginal_gpu_agrees_with_cpu_loosely -q --junitxml=gpu-junit.xml
ERROR: found no collectors for /work/tests/test_marginal_parity.py::test_marginal_gpu_agrees_with_cpu_loosely

Likely downstream of the same missing-_core problem (or a stale/renamed test id) — not independently investigated.

Likely same root cause as a known issue

This looks like the same class of gap as #591 ("fix(review): update offline Rust coverage toolchain" — the trusted offline coverage image's baked-in Rust toolchain was too old to build a target crate for codec-carver, silently failing the compiled-extension step before any test ran). fast-mlsirm pins rust-toolchain.toml to channel = "1.97.1"; I did not confirm whether the coverage sandbox even attempts a Rust/maturin build for fast-mlsirm (no such step appears in this job's log at all, unlike #591's evidence which shows an explicit failing Rust step) — that distinction matters for whoever fixes this: either the build step is missing entirely for this repo's pyproject/maturin shape, or it runs and fails silently upstream of what I could see in the tail of the log.

Impact

Blocks OpenCode approval (REQUEST_CHANGES posted regardless of actual PR content) for any fast-mlsirm PR whose coverage-evidence run collects the full tests/ directory — i.e. potentially most/all of them, independent of the PR's own changes.

Not attempting a fix

Same reasoning as #1250 and #591: the coverage sandbox's build/install pipeline is intentionally hardened (offline, tokenless, hash-pinned) and I don't have visibility into how it provisions the Rust/maturin toolchain or whether that's even attempted for this repo's pyproject.toml (maturin build-backend). Recording reproducible evidence for whoever owns that provisioning step rather than guessing at a fix.

Related

• fix(review): update offline Rust coverage toolchain #591 (open — offline Rust coverage toolchain, likely same root cause class)
• coverage-evidence sandbox: stale requirements hash-lock (missing asyncpg/psycopg2) + invalid pnpm --trust-lockfile flag block LineageWeave approvals #1250 (closed pattern precedent — sandbox missing a target repo's real runtime dependencies, same "coverage-evidence blocks on environment gap, not PR content" shape)
• fix(config,backend): harden controls and close auto-backend buyer surfaces fast-mlsirm#951 (the PR currently blocked by this)

Agent: Claude

[seonghobae]

Fresh owner-boundary triage identifies existing canonical central PR #789 (fix/pyo3-native-peer-gate) rather than a fast-mlsirm leaf change or a competing micro-PR.

Why it matches this reproduction:

• feat(coverage): add bounded PyO3 peer-evidence gate #789 classifies only collection failures caused exclusively by an unchanged declared maturin/PyO3 module being unavailable in the source-only sandbox.
• It emits DEFERRED, not PASS, and requires exact-current-head successful CI::python, CI::rust, and CI::package CheckRuns before approval.
• fast-mlsirm#951 is still at 286bd2dbba5da8348643b6ad8145967972813ae9; its changed files include Python/product/test/docs paths but no Cargo/native crate, pyproject, lock, workflow, or packaging input.
• Its exact-head CI run 32435257997 is successful and contains successful jobs python, rust, and package (plus the versioned Python jobs), so it is a valid operational canary for that bounded peer-evidence design.

However, #789 exact head 861478bb11ba89f71b97dbbdd874b3d872372125 has a valid unresolved security review: its deferral marker is written above ## Coverage Decision, while the published summary begins at that heading, so the peer-check requirement can disappear and approval can fail open. That head must not integrate or be used as acceptance evidence until the marker survives publication and the exact peer checks are demonstrably enforced.

Next causal owner action is therefore to repair #789 test-first, sync it non-destructively to live protected main, regenerate exact-head checks/reviews, then rerun unchanged fast-mlsirm#951. No consumer source workaround or graceful test skip is warranted.

[seonghobae]

Canonical owner #789 advanced to exact head 31c8d207a5d5cbdde3e0ea98dcd7f50c383b6e4b on protected main 0c6b9a6459c9dbdf5e23fb01df7a32a8a14964b3.

The reproduced fail-open boundary is repaired: the source-only native deferral marker now survives compact coverage publication, so approval must verify exact-head CI::python, CI::rust, and CI::package. Focused 140 tests and full 1,513 tests·16 subtests passed locally; all current review threads are resolved. Hosted exact-head checks and a qualifying formal review remain required before integration, followed by a fresh unchanged ContextualWisdomLab/fast-mlsirm#951 canary. This issue remains open until protected-main and downstream operational evidence.

[seonghobae]

Current-main control-plane note from the 2026-08-25 loop:

• feat(coverage): add bounded PyO3 peer-evidence gate #789 remains the existing PyO3 peer-evidence deferral candidate. It can classify a source-only ModuleNotFoundError: fast_mlsirm._core as DEFERRED, but it does not run maturin/cargo and therefore does not restore RMSE/recovery ownership tests.
• Central scripts/ci still has no maturin build step. Rust coverage doctoring (docs/doctoring/opencode-rust-coverage-runtime-boundary.md) binds LLVM 19 for cargo llvm-cov, not for a Python extension module.
• Do not close this issue when feat(coverage): add bounded PyO3 peer-evidence gate #789 merges. Do not stack a maturin build onto fix(e2e): restrict readiness polling to loopback destinations #1314 (loopback readiness SSRF successor).

Next action: after #1314’s current-head Checks are collected, open a dedicated current-main repair that either builds the declared maturin extension inside the coverage sandbox or fail-closes with an operator message that names the missing _core artifact and the exact rust-toolchain pin.