Compile v1-compiler's test targets in CI: the population no gate compiled

[gunbai-bot]

The hole

v1-compiler carries 24 files with #[cfg(test)] modules and nothing in CI compiled any of them. So a test module referencing helpers it cannot see sits on main with every gate green — which is exactly what happened today, and is still live on main at b33a9c03d:

cargo check -p v1-compiler --all-targets   ->  exit 101
  error[E0425]: cannot find function `with_env_test_lock`
  error[E0433]: unresolved module or unlinked crate `floor_discovery_snapshot`
  error[E0433]: undeclared type `EnvGuard`
  error[E0425]: cannot find value `FLOOR_DISCOVERY_CONSUMER_ENV`
  error: could not compile `v1-compiler` (lib test) due to 4 previous errors

Why the three existing gates structurally cannot see it — measured, not assumed:

gate	covers	misses this
release build	binaries	test targets aren't built
ci_stage0_partition_compile_gate	7 generated crates, Check	no test targets — and all seven carry zero cfg(test) files
cargo test -p v1-compiler-tests --release	a different workspace crate	never compiles v1-compiler's own test modules

This is not a nextest re-enrollment

gunbc.commit_workflow commit_gate_rust_suite_removed_disposition rejects that, and every rationale in it is a fact about execution — ~37 GiB, red on main, seed runtime, ~42min. This is cargo.Build.Check, compile-only, and runs no test. It is the same separable-fact argument that re-enrolled fmt (2026-07-15) and the v1-compiler-tests compile half (2026-07-31); it closes the third and last uncovered target class.

Design choices, each of which could have gone the other way

Scoped to -p v1-compiler, not --workspace. Partition crates are already Check-ed and have no test targets to miss; v1-compiler-tests has its own gate. A workspace-wide check would re-check covered lib targets for no gain (§2).

--all-targets is supplied by the workflow layer through extra_args, exactly as ci_stage0_partition_compile_gate_extra_args supplies -p. DESIGN §3 names a bare --all-targets in an extdeps argv as the policy-leak tell, and v2.lens.extdeps_shape_transport_policy reds on it; that reading is respected rather than evaded — extdeps.cargo_build keeps the agnostic operation shape.

Cost: 99s measured (b33a9c03d, cargo check --workspace --all-targets, cold, remote) — an upper bound for this single-package step. Budget 10m, deliberately below the 15m the sibling gates carry, because those inherited a cold-host envelope with no dedicated receipt and copying an unmeasured number is how it becomes precedent. Placed after the release build so it reuses the release-profile artifact.

Evidence

emitted	ci.yml:142 — "$CARGO_BIN" 'check' '-p' 'v1-compiler' '--all-targets'
witness	PASS ci_build_job_backstop_is_step_sum_plus_prelude
red control	the gate's exact argv reproduces all 4 errors on main (exit 101)

The red control uses the gate's literal command, so it is validated against the real inherited defect rather than a synthetic fixture.

What this does not do

It does not execute those tests. Compiling a test module proves its references resolve, never that its assertions hold. The 24 files still have no executing consumer on any CI path — including the five union_dedup_import_facts_law tests #8162 added to the very file this specimen came from. Execution cost is left unmeasured on purpose: main's lib test target does not currently compile, so that number can only be taken on a green tree, and the module says so rather than implying tests will follow.

Sequencing — read before merging

This cannot go green until the 4 errors are fixed, and #8167 / #8173 carry that repair. Merge those first; this gate then prevents the recurrence. The fix is deliberately not duplicated here.

So a red CI on this PR is the gate working on its first execution, not a defect in it.

Separate finding, not in this PR

Cargo.lock on main is stale: it lists serde / serde_json under v1-compiler-tests while that crate's Cargo.toml no longer depends on them. Any cargo invocation syncs it, so anyone building locally gets a spurious modified file and a --locked build would refuse. One line, someone else's crate.

[gunbai-bot]

Both findings addressed

Finding 2 — no witness pinned the emitted script. Accepted; fixed in aa333a823.

You were right that updating the backstop sum establishes arithmetic over timeouts and nothing about what the gate emits. dag/test/claim/ci_v1_compiler_test_targets_compile_gate_witness_test.dag now mirrors test.claim.ci_stage0_partition_compile_gate_witness, green by execution:

PASS w_v1_compiler_test_targets_gate_script_carries_check_scope_and_all_targets
PASS w_v1_compiler_test_targets_gate_extra_args_are_exactly_scope_then_all_targets
PASS w_v1_compiler_test_targets_gate_shell_emit_is_scaffold_holds
PASS w_v1_compiler_test_targets_gate_emit_carries_dissolve_marker_holds
PASS w_v1_compiler_test_targets_gate_script_is_typed_plan_plus_marker
PASS w_build_job_enrolls_v1_compiler_test_targets_compile_gate_holds
PASS w_v1_compiler_test_targets_gate_RED_missing_operation_refuses

The argv is pinned token-by-token rather than as one string, because the three tokens rot independently: check → test would silently convert this into the execution gate the standing nextest ruling rejects; widening -p v1-compiler would re-check what the partition gate already covers; and dropping --all-targets is the quiet one — the step still passes, still looks enrolled, and covers exactly the population that was uncovered before this gate existed. That last case is what a single-string assertion misses most easily.

Finding 1 — merging reds the build job. Factually correct; now enforced instead of described.

I verified it rather than taking it on trust: #8167 and #8173 are both still open, and cli_run.rs:29991 still calls with_env_test_lock with no import in scope. The PR body carried a stacked-PR plan, but you're right that a plan in prose is not a merge guard — so this PR is now a draft and cannot be merged into a tree it would red.

On this PR's own red CI, which is the gate working

build → FAILED at "cargo check -p v1-compiler --all-targets (compile gate; ...)"
ci    → refused: "an upstream job already established this branch is red"

That is the designed behaviour on first execution, not a defect to repair. The step caught the live 4-error defect in v1-compiler (lib test); had it passed, the gate would be inert. ci then refused fail-closed rather than spending an hour to invent its own verdict.

I am deliberately not pushing a compile fix here. #8167/#8173 own that repair, and duplicating it into this PR would fork work already done. Merge those first; this gate then prevents the recurrence.

One correction to the review

The emit module is src/v2/workflow/ci_v1_compiler_test_targets_compile_gate_emit.dag, not src/v1/workflow/.... Doesn't affect either finding.

— sent from gentle-dove-143

[gunbai-bot]

The test half of "compile + test": measured, and declined with a reason

The compile half is done and proven — this gate went red on three real defects and green once they were fixed. The execution half I am deliberately not adding, and the reason is a standing program rather than a missing measurement, so the note claiming otherwise is corrected in 565d23cf1.

Measured 2026-08-13: cargo test -p v1-compiler --lib -- --list reports 537 tests. test.retirement.model retained_legacy_rust_test_modules governs src/v1/tests/src only — every row is a bare filename in the v1-compiler-tests crate, and zero rows name src/v1/stage0/src.

So those 537 are outside the retirement program: not retained, not deleted, not classified. Enrolling execution for them would:

• run the population the §7 seed burn-down exists to delete, whose declared direction is that an unretained module disappears with the seed;
• partially undo the cutover that cut the kernel to 9 modules / 30 tests from 98 / 740;
• reopen the execution-cost decision the nextest removal settled — that removal existed precisely to stop executing seed tests.

That is an operator decision, not a step to slip into a compile-gate PR.

A hole in the retention wall, and it is mine

The model reds a new Rust test file added without a retention row — but it discovers only src/v1/tests/src. So #[cfg(test)] tests added inline to an existing src/v1/stage0/src file are invisible to it.

That is exactly how #8162's five union_dedup_import_facts_law tests in cli_run.rs entered the unclassified 537: no retention row, no executing consumer, slated to vanish with the seed. They belonged in the retained crate, or should have been accepted as throwaway. Recorded in the module rather than left for rediscovery.

Three ways forward, none chosen here

1. leave the 537 unexecuted — consistent with the burn-down, and this compile gate is then the coverage
2. migrate the few carrying real contracts into src/v1/tests/src with retention rows — this would also cover my five
3. run all 537 — measurable, but reopens the settled execution-cost decision

Verified after the note edit, not assumed

ci.yml regenerates with no drift, and the four emission/enrollment witnesses still PASS. The note shares a module with the emit and the plan-plus-marker witness compares exact strings, so a prose edit there is not automatically inert.

— sent from gentle-dove-143