boundary-coverage wall: model the CI minimum-safe-floor as boundary-coverage non-redundancy

[gunbai-bot]

What & why

Models the "minimum safe floor" as boundary-coverage non-redundancy (DESIGN.md §2), enforced as an up-front construction wall (§5) — not cost, not layer-span, not a folder proxy. (Supersedes the layer-span approach from the earlier, now-closed #6054.)

A Boundary is the contract between adjacent pipeline stages (a→b). The floor is the minimal set covering every boundary once with a faithful mock; composed/integration paths (a→d) are redundant because faithful b/c mocks already cover each edge.

Two axes, enforced at compile time

• Completeness — every required boundary has a faithful-mock test; uncovered = compile error ("an untested boundary is a compiler error").
• Faithfulness — a mock must exercise every field of the real contract; an anemic stub is a compile error even where nominally covered.

Grounded & live

• boundary_coverage.dag — model + both walls. 8 witnesses green by execution.
• boundary_coverage_corpus.dag — grounded over the real corpus: boundaries from the real pipeline (tokenize→parse→resolve→infer→translate→emit); coverage from real import facts (import_resolution_facts_live). 3 witnesses green live.

Composition with affected-set

Wall = the always-checked invariant (cheap, structural). Affected-set = the execution minimizer. The wall makes affected-set pruning sound (every boundary provably covered ⇒ running only affected mocks suffices). Affected-set execution pruning is blocked on the resolver root fix; the wall goes live without it.

🤖 Generated with Claude Code

What the corpus wall currently proves (scope)

• Completeness (grounded now): every pipeline boundary is exercised by at least one test touching both endpoints, via the import-fact proxy in boundary_coverage_corpus.dag.
• Faithfulness (pure spec now; grounding dispatched): coverage_wall_holds/mock_is_faithful model the anti-anemic axis; grounding Contract.required_fields from the producer TypeItem — and distinguishing a faithful mock from a redundant integration bridge — is the dispatched follow-on.

[gunbai-bot]

Thanks — both advisory findings are fair; noting scope for the record:

1. Boundary.producer/consumer as bare String (§3 module identity). Agreed it's QualifiedName/ModulePath territory in principle. It's deliberately consistent with the upstream authority this lens consumes — ImportResolutionFact.import_module is itself String in module_graph.dag. Switching Boundary to QualifiedName while the fact source stays String would introduce conversions/mismatch at the seam, so this dissolves correctly with the module-graph lens, not ahead of it. Left as preexisting substrate debt, as you note.

2. fact_covers_boundary = "some test imports both endpoints" is a weak proxy. Correct, and this is the honest scope: the corpus wall (corpus_coverage_wall_holds) currently proves completeness — every pipeline boundary is exercised by at least one test that touches both endpoints. It does NOT yet prove the bridge is a faithful mock (vs a redundant integration/round-trip test), nor that it exercises every field of the contract. That stronger claim is the faithfulness axis — already modeled in the pure spec (coverage_wall_holds / mock_is_faithful in boundary_coverage.dag) and dispatched as a follow-on to ground Contract.required_fields from the producer's TypeItem reflection. So the two layers are intentionally split: pure spec proves both axes; the corpus instantiation currently grounds only completeness via the import proxy, with faithfulness landing next. I'll sharpen the naming/PR-description to state exactly this.

— sent from bright-cat-462

[gunbai-bot]

CI status: the floor is 1169/1170 green. The single red is ci_floor_spawn_width_live_budget_witnesses (witness_floor_spawn_width_zero_budget_falls_back), which is a pre-existing #6059 regression on main, not introduced here:

• it returns false with all four boundary-coverage files removed;
• it's corpus-independent (tests the zero-budget fallback path);
• it lives in ci_floor_plan.dag, which is byte-identical to main on this branch.

All boundary-coverage witnesses pass in-floor. This PR is content-complete (2 approvals, 0 request-changes, merged with main). The remaining red is inherited and needs an upstream fix to ci_floor_plan.dag (load-bearing — out of scope for this brief).

— sent from bright-cat-462

[gunbai-bot]

Good nit, agreed in principle. Scoping it: anemic_contracts is in the pure-spec model, which runs over small in-memory example lists (a handful of contracts/mocks), so the O(N·M) is negligible there. The place where corpus-scale perf actually mattered — boundary_coverage_corpus.dag — was already the O(n²)-over-the-whole-import-graph problem, and that's fixed (filter-to-stage-imports before the nested scan, ~90s→<1s).

The clean form is to lift a typed contract_is_anemic(c: Contract, mocks) helper that does mocks_for_boundary(c.boundary, mocks) first, then !mock_is_faithful (typed param needed because field access on a filter lambda param doesn't infer here). Happy to fold that in — holding only because this PR's direction is under review with the operator (boundary-coverage model vs. the affected-set lever for the original 'run fewer tests' goal), and it can't merge yet regardless (inherited #6059 spawn-width red).

— sent from bright-cat-462

[gunbai-bot]

Both findings are valid. Status:

Finding 2 (missing_fields duplicates missing_keys) — fixed. mock_is_faithful now routes through v2.lens.coverage.missing_keys; the parallel fold is deleted. Witnesses green.

Finding 1 (pipeline_stages skips normalize) — valid, and correcting it exposes a deeper issue I don't want to paper over. The real compile spine per 00_compile.dag:compile_ingest_staging is tokenize → parse → normalize → resolve → translate (emit folds into stage_translate; infer is a helper translate imports, not a pipeline stage). So my list was built from module existence, not pipeline composition — you're right.

But when I ground the spine on that authority and re-check coverage with the current import-bridging proxy, resolve → translate shows 0 bridging tests — even though it's exercised by every compile round-trip, because those go through the compile() wrapper rather than importing v2.compiler.resolve and v2.compiler.translate directly. So naively correcting the spine makes the wall falsely red: the import-bridging proxy (already flagged as weak in a prior review) is inadequate once the spine is correct.

The honest fix is therefore both corrections together: ground the spine on compile_ingest_staging and strengthen the coverage notion beyond direct dual-import (count tests that exercise a boundary through the compile authority). That's real rework, and I'm pausing on it pending an operator direction call on this PR (boundary-coverage corpus derivation vs. prioritizing the affected-set lever for the original 'run fewer tests' goal). Keeping REQUEST_CHANGES open is correct until the spine is grounded — I won't ship the wrong spine or a false-red one.

— sent from bright-cat-462

[gunbai-bot]

Agreed, trivial nit — field_eq (kernel) and string_eq (corpus) are the same String == wrapper and should collapse to one shared helper. I'll fold it into the spine/coverage rework if we proceed (option B in the direction discussion). Holding on a standalone commit for it since there's an open REQUEST_CHANGES on the spine and this PR's direction is pending an operator call. — sent from bright-cat-462

[gunbai-bot]

Acknowledged — this REQUEST_CHANGES is correct and I'm keeping it open. To restate the plan (from my prior reply): the fix isn't just inserting normalize — grounding the spine on compile_ingest_staging (tokenize→parse→normalize→resolve→translate) with the current import-bridging proxy makes resolve→translate falsely red (it's exercised via the compile() wrapper, 0 direct dual-imports). So the faithful fix is: (1) derive required_boundaries from the compile pipeline authority, AND (2) replace the import-bridging coverage proxy with one that counts boundary exercise through the compile authority. That's a real rework, and this PR's direction (do that rework vs. scope #6081 to the pure-spec model and let the in-flight affected-set PRs deliver the 'run fewer tests' goal) is an open decision with the operator. I won't ship a wrong or false-red spine to clear the check; the RC stays until it's grounded properly. — sent from bright-cat-462

[gunbai-bot]

Thanks — both points addressed:

Scope creep (fixed). The runner_spec_from_offer + ci_runner_seam_witness edits were on this branch only because the auto-committer landed them here; they've been split out to #6107 ("CI: move required runners to Ubicloud standard"). This branch is now boundary-coverage only (4 files: boundary_coverage{,_corpus}{,_test}.dag). ci.yml + both .dag files restored to main here.

§3 (single authority). On #6107: the Ubicloud runner isn't a fleet ComputeOffer and runner_spec_from_offer isn't its authority. That seam derives a self-hosted spec from one of our physical hosts (kernel+arch → SelfHosted{labels}); Ubicloud is a distinct hosted-runner realization (runs-on: ubicloud-standard-16-arm, a third-party service), so it's modeled as a cited single-authority decl gunbc_ci_ubicloud_runner_label through the existing RunsOnExpression variant — not a fork of one concept but two authorities for two genuinely different runner sources (runner_spec_from_offer still owns fleet placement at ci_runner_placement.dag:162). Forcing Ubicloud through the fleet-offer seam would be the nickname. #6107's review concurred (APPROVE).

Re-review of the trimmed boundary-coverage diff appreciated.

— sent from bright-cat-462