Import-enforcement §5 gate: unresolved-import (dangling-import) lens gate

[gunbai-bot]

What

A §5 fail-closed CI gate that catches unresolved (dangling) imports — an import <module> whose target module is declared nowhere in the scanned tree. This is the import-enforcement the parse-gated whole-tree compile never reaches: front_end_sources (src/v1/compile.dag:1171-1184) short-circuits to graph: none on any parse error, so the live src/v2 parse-fixtures silently drop every resolve diagnostic — UnresolvedImport included (the v2-compile-no-entry-parse-only finding).

Mirrors the layering_imports gate end-to-end: a structural lens over a host projection, run by gunbc, wired into the ci_floor_plan scheduler. Independent of the load-bearing front_end_sources parse-resilience edit (that stays a separate compiler-path follow-up, not in this PR).

§3 single authority (not a fork)

The authoritative producer of "this import is unresolvable" is the resolver: resolve_import emits UnresolvedImport at v1_compiler_resolve.rs:271 when find_module(module_index, import_path) == Absent. This lens projects that exact rule into a cheap CI gate, REUSING the resolver's own build_module_path_index (declared-module set) + extract_import_paths + collect_dag_files_tolerant — no second module-index or import-extractor.

§5 proven by execution (not spec-without-execution)

• GREEN through the real consumer: CI green on b025bec — the gate runs non-vacuously via the literal ci_floor_plan claim_executor floor pass; its clean_tree_test witness is also auto-enrolled in the 377-witness discovery corpus.
• RED flips through the same floor-plan path: a planted dangling import turns FAIL [batch 2] resolved_imports_gate_passes (returned Bool(false)) via the literal claim_executor --plan-entry src/v2/workflow/ci_floor_plan.dag command.
• Self-caught vacuity: the gate initially read green regardless of the planted import — root-caused to a §3 flat-namespace collision (run_gate defined in six gate modules binds ambiguously in the floor closure). Fixed by uniquifying to run_resolved_imports_gate_body. The systemic uniquification of the other five gates is handled by slice 3: migrate source_root_ingest transport into src/v2 (serialize_bash groundwork) #5185 — expect a rebase onto slice 3: migrate source_root_ingest transport into src/v2 (serialize_bash groundwork) #5185's renames in the four shared wiring files (ci_spec/ci_gates/ci_floor_plan/floor_effect_gate_witness).

Files

• Lens: src/v2/lens/resolved_imports.dag
• Host projection: src/v1/stage0/src/import_resolution_project.rs (+ interpreter/infer_method/lib wiring)
• Gate + transport: dsl/tools/resolved_imports_{gate,transport}.dag
• Witnesses: src/v2/test/claim/resolved_imports/{clean_tree_test,scanner/parse_level_pre_resolve,lens_unit/unresolved_fixture}.dag
• CI wiring: ResolvedImportsGate variant in ci_spec/ci_gates/ci_floor_plan/floor_effect_gate_witness

🤖 Generated with Claude Code

[gunbai-bot]

Verified-resolved on current HEAD — not a stale dismissal.

The conflict markers this review flagged were in commit cd933c1 (WIP: Import-enforcement §5 gate), where the dashboard auto-committer snapshotted the working tree mid-merge with the #5185 rebase unresolved. That commit is no longer HEAD.

The merge was completed cleanly in 7d55bde67 (current HEAD, matches gh pr view). Evidence:

• dsl/tools/floor_effect_gate_witness.dag:14 is now the single merged import line:
  RustMonolithGate, EmitHostGate, LayeringImportsGate, ResolvedImportsGate, DslCompileCleanGate, CiYamlGate — no <<<<<<</=======/>>>>>>>.
• Tree-wide scan: grep -rn -E '^(<<<<<<<|=======$|>>>>>>>)' --include='*.dag' --include='*.rs' . → zero matches.
• git status clean; mergeable: MERGEABLE.

The resolution kept the HEAD side that adds ResolvedImportsGate (exactly as the review recommended), composed with #5185's run_X_gate_body uniquification. §5 non-vacuity was re-proven by execution on this SHA: planted dangling import → gate false, clean tree → true.

— sent from clever-bear-164

[gunbai-bot]

Fixed — thank you, this was a real bug and you pinpointed it exactly.

The review was against 951b2e19 (an intermediate the dashboard auto-committer pushed mid-edit): I had swapped the import on line 15 to resolved_imports_clean_nonvacuous_holds but left line 26's call as resolved_imports_clean_holds — a name/import mismatch that would fail to resolve, and (as you note) would have defeated the documented §5 non-vacuity floor if it had.

Line 26 now calls resolved_imports_clean_nonvacuous_holds (commit 284797536, current head 27c6635e0). Re-proven by execution on the new SHA:

• clean tree → resolved_imports_clean_over_live_tree_holds returns true (real tree clean and ≥1 import scanned — the non-vacuity floor is live);
• planted dangling import in src/v2/std → same witness returns false (fails closed, exactly the property you flagged);
• scanner over the committed fixture → true (detects the one planted unresolved import).

The non-vacuity floor itself (resolved_imports_clean_nonvacuous_holds = (is_empty(facts) == false) && resolved_imports_clean_holds) is what makes a zero-import scan fail closed instead of vacuous-green.

— sent from clever-bear-164