test.claim witnesses: explicit imports for every bare provider (emit_subject_clean_frontier, deploy_access_privilege)

[gunbai-bot]

Work item: zero-import test witness files fail when a changed-declaration consumer pull brings them into the floor plan.

Change

• test.claim.emit_subject_clean_frontier_witness had zero imports, so it resolved only through the bare channel's whole-corpus census, and a corpus change elsewhere could break it. It now imports every declaration it uses (from gunbc.emit_subject_clean_frontier, tools.emission_entry_instrument, std.*, extdeps.*).
• test.claim.deploy_access_privilege_witness is not zero-import. It had one import, which turns its bare channel off, so 16 names resolved only by chance. On main it does not resolve on its own (effect-summary refusals naming the unimported callees). It now imports all 16, and their 16 rows in v2.workflow.floor_unimported_bare_provider_debt_roster move ActiveDebt -> Retired { cause: ImportsFixed }.

Evidence (and what is missing)

• emit_subject: 63/63 witnesses PASS standalone after the change (claim_batch run on that file alone). Caveat: the local claim_batch binary was built Sep 23, before Refuse an unimported bare provider at the file on both routes; 2103 standing pairs as monotone debt #12205 and Int->Nat refinement PR1: subtraction leaves Nat, count/length return Nat, Bool as Int refused by the checker #12227. A remote rebuild-and-run produced no output, so the exact-head receipt is this PR's floor run.
• deploy_access: the stale binary got past resolution and stopped in extdeps.languages.json.number. That is most likely the binary predating Int->Nat refinement PR1: subtraction leaves Nat, count/length return Nat, Bool as Int refused by the checker #12227's Nat typing; only the floor at head can settle it.

Not fixed here: the other zero-import files

About 250 test.claim files have no import lines. By design (unimported_bare_providers: "a zero-import file is on the bare channel and owes nothing here") they are not debt under the rule, and fixing them is not mechanical: name-to-declarer inference picks up lambda and local noise (single-letter binders matched to unrelated test modules), and each file needs its own resolve to verify. List: for f in $(grep -rl '^module test\.claim' dag src/v2); do grep -q '^import ' $f || echo $f; done. I recommend a follow-up that decides structurally whether a zero-import file may stay on the census channel, rather than 250 hand edits.

🤖 Generated with Claude Code

[gunbai-bot]

The reported failure, taken from the floor log (#12354's failing run 36265763185, head 0c65d9ce):

• [floor-plan] SeedDeclarationInterfaceChangedConsumer declaration=test.claim.runner.runner_microvm_slot_start_witness_test.u ground=SignatureChanged consumers_added=[] flat_channel_consumers=[...]. Changing the fixture u added 203 flat-channel consumers to the plan. emit_subject_clean_frontier_witness is one of them; its only uses of the spelling u are the named argument u:.
• floor refused: modules_resolved=2603 → emit_subject_clean_frontier_witness_test.dag:183:8: error: unresolved type 'PopulationUnreadable'. This is the only error among the 203 pulled modules.
• PopulationUnreadable is declared in gunbc.emit_subject_clean_frontier, which this PR now imports explicitly. The file's own import closure now contains that declaration, so resolving it no longer depends on the bare channel pulling it in.

I have not reproduced it end to end. No floor run of this head exists over a u change. A standalone claim_batch run does not tell the two versions apart: the zero-import original also resolves standalone.

The upstream cause is not fixed here. Consumer selection treats a named-argument label u: as a read of the declaration u, so one fixture edit plans 203 unrelated modules. That selection is where it first goes wrong (§6b); this PR only removes the file's dependence on the bare channel. It is reported to the lane manager for a separate item.

— sent from keen-deer-265