Latent type errors from #12114: Optional port groups are matched; reference_deps imports its Outcome

[gunbai-bot]

Fixes the two latent type errors that #12114 (sleek-cat-104) surfaced and dropped (floor run 35817717033).

(1) test.claim.network_switch_catalog_witness

port_inventory.first() / skip(n:).first() is Optional<SwitchPortGroup>, and the claims read .data_rates / .connector / .port_count straight off it. Now crs812_group returns Optional<SwitchPortGroup>, and every claim matches it. Absent is stated as a failure through group_port_count_is, group_connector_scales_to and arista_first_group_is_52_sfp_plus_at_10g. Bandwidth is imported from std.measure (this is #12114's dropped import).

Local control (seed gunbc run, this head's binary): old test plus only the Bandwidth import → resolve failed … :183:75 value does not inhabit its declared type … declared List<Bandwidth>, produced Optional<List<Bandwidth>>. New test → resolves and the claim evaluates true.

(2) v2.lens.reference_deps admission_from_module_root

The earliest boundary that fails (§6b) is the module's import list, not the function. reference_deps never imported Outcome / Accepted / Rejected / None from v2.std.diagnostic, so Outcome<Admission> was an unresolved name. The checker read it as Primitive(T). Every other Outcome<…> in the file passed vacuously the same way. Only this site produced a Product (Admission) where the unresolved parameter was expected, so only this site reported. The fix is the import (this is #12114's dropped Outcome/Accepted), and the signature is correct as written.

Why the floor never seeds this closure

compile_door_ledger_ownership_test is module v2.test.compile_door_ledger_ownership. The "v2.test." row was withdrawn from v2.workflow.required_floor required_gate_prefixes, as recorded in the comment beside it: 14.3 min of strict preparation over a 3,199-module closure. So the module is seeded only when its own file changes (changed-witness). No required lane type-checks v2.lens.reference_deps through this claim. That is the §3 inhabitance gap: a production module sits inside an enrolled claim's closure, and nothing checks it.

Should a required lane reach it? Yes. The claim is the only enrolled route to reference_deps → compile_door_ledger. The existing mechanism already covers it: the withdrawn "v2.test." row is named as "the first to return" once preparation is reused or diff-scoped. A narrower route is an exact-module selector (the second selector kind that required_floor documents). No job is added here, because new jobs need operator sign-off.

Receipt

Floor log receipt: see the PR comment once this head's floor run lands.

🤖 Generated with Claude Code

[gunbai-bot]

Floor receipt, head cd4d9a9 (floor job, pass):

• [floor-phase] phase=touched-entry-compile-subject seeds=2 modules=["test.claim.network_switch_catalog_witness", "v2.lens.reference_deps"]. Both touched modules were compiled as floor subjects.
• v2.lens.reference_deps appears in both required-ci: judged-module-identities and admitted-module-identities. The Primitive(T) vs Product(Admission) refusal from run 35817717033 is gone.
• Every test.claim.network_switch_catalog_witness.* claim reports standing=planned-and-passed disposition=planned_as_changed_witness. The log has no does not inhabit line.

The floor reached reference_deps only because this PR touches it (the touched-entry seed). The standing gap described in the PR body is unchanged: an untouched reference_deps is still reached by no required lane.

— sent from cool-stag-519