Emit the caller's resource binding, matched by resolved declaration, and a located compile_error! where none is established (rung 2)

[gunbai-bot]

The Rust emitter passes the CALLER's resource binding, matched by resolved declaration, and renders a located compile_error! where the caller establishes none. Rung 2.

The defect

v1.compiler.emit_rust emit_typed_call appended the callee's resource binding name at every call site. For fn reads(path: String) -> String uses fs: Filesystem called from a synchronous fn plain(path: String) -> String { reads(path: path) }, it emitted reads(path.clone(), &fs).await? inside a function that binds no fs. Arity agreed with the declaration, and the argument named nothing in scope. The file was published, and only rustc refused it. That is DESIGN §5 silent wrongness at the realization boundary, filed as gunbc.recurring_failure_mode accepted_source_emits_uncompilable_target.

What changes

• Contract carrier: v1.compiler.infer_items ItemInfo.resource_requirements: List<ResourceRequirement> (binding name + resource node) replaces the resource_names string list. item_is_effectful_callee is the one effect predicate the emitter sites read.
• One matching fold: v1.compiler.infer established_resource_binding answers the caller's binding for a callee requirement. The emitter consults it, so it can never pass a spelling nothing established.
• Identity by declaration, not spelling: resource_declaration_identity reads the DeclarationRef off the node resolution selected in the declaring module, and nominal_ref_node's bare-name leaf now carries its declaration's spans. A first version compared resolved nodes: a bare Filesystem resolved to a kernel-spanned stand-in and std.resources.Filesystem to the declaration, so mixed spellings that compiled on main rendered compile_error! (review 70670). This repair was built by neat-lynx-128 (parked as Resource identity forks by spelling: <kernel:Filesystem> vs std.resources.Filesystem #12174) and is carried here.
• Refusal arm: compile_error!, not the emitter's ordinary error expression. Its template is panic!, whose type ! coerces to any parameter type, so rustc accepted the call and the program panicked at run time (review 69961).

Rung, stated honestly (DESIGN §4b(1))

Rung 2, mechanically preventable. An unestablished requirement renders a located compile_error!, so the target compiler refuses the artifact. The artifact is still written; nothing refuses before publishing. The emitter has no channel that stops publication.

A typecheck wall was built and withdrawn

This PR first refused an unestablished uses at the typecheck, with a counted frontier roster for the pre-existing sites. It was withdrawn because it required every caller to author a uses clause. That is the E1b migration DESIGN D13 superseded (dag/gunbc/plans/demand_engine_program.dag): a transparent function's dependency demand is derived, and #12125 deleted 174 authored rows as restatements. Removed with it: resource_requirement_diags and its arms, the frontier roster, the three ResourceRequirement* / ResourceFrontier* diagnostics and their compile_clean arms, and every authored clause the census rings added.

Next-rung trigger, a capability: D13's DependencyDemand, derived per resource declaration (and logical subject) and carrying a binding identity. That is sufficient for a call whose caller's derived demand does not cover its callee's requirement to refuse at the typecheck, before emission, and for a derived caller to receive a binding instead of the compile_error! arm. Recorded on accepted_source_emits_uncompilable_target.

Executed evidence

test.claim.resource_requirement_call_admission_witness, asserting emitted text:

• Reds that agree on arity: a caller with no resource, and a caller with the WRONG resource. Each renders the located refusal and never &fs).
• Positive control: a caller binding the resource under a different name emits &filesystem.
• Spelling-fork pair: a qualified callee with a bare caller emits &fs; the bare/bare control does too; and a qualified callee whose caller holds a different resource still refuses.
• Boundary: a callee with no requirement emits an ordinary call.

Population evidence (census receipts)

Three whole-corpus censuses ran during the withdrawn wall's re-derivation (gunbc compile --source-root dag --source-root src/v2 --target rust --repository gunbc --measured-root-demands tools/whole_corpus_compile_measured_root_demands.json, per gunbc.emit_stage_blocking_population_census). They measured the authored-uses population the D13 carrier will have to cover. Two findings from them are filed as gunbc.recurring_failure_mode a_sibling_refusal_masks_a_ratchet_rows_observation:

• observed=0 does not prove dissolution when a sibling refusal on the same caller masks it;
• one census reports only one propagation ring per run.

neat-lynx-128 measured that 8 of the withdrawn Filesystem rows were false refusals from the spelling fork, not debt.

Also

• FrontierOccurrenceBudgetExceeded now prints the declared and observed counts it claimed to carry.
• The generated mirrors are regenerated from the merged authority. The regen still reports one refusal that belongs to main, not to this PR: the no-longer-emitted release_locus_seed_constants_generated.rs. No required job regenerates mirrors, which is why that drift stands on main.

🤖 Generated with Claude Code

[gunbai-bot]

Addressed review 69961 in 47d42d4, and the finding was right on both halves — with one thing worse than reported.

The panic! is not a compile refusal. emit_error_expr's Rust template is panic!({0}), and panic! has type !, which coerces to any parameter type. So reads(path.clone(), panic!("...")) is accepted by rustc and fails at run time — not an artifact the target compiler refuses, but one it compiles and that misbehaves. That arm now renders compile_error!, so the target compiler refuses it.

The unreachability claim was wrong and the rung was inflated. The emitter note asserted the typecheck blocks every instance so the arm is unreachable in an Accepted program. That holds for ordinary callers only: caller_is_test_root admits a TestMarked caller with no uses row, and test roots are rendered by extract_test_projections, so an Accepted program reaches the arm through exactly that door. The witness's rung paragraph is corrected downward and now states both paths separately — rung 3 for ordinary callers (refused before any file exists), rung 2 for test roots (compile_error! is a published artifact that cannot build, which is mitigation, not refusal-before-publishing) — and takes the class's rung as the minimum across its in-scope paths, so the class is rung 2, not 3.

compile_error! is an improvement, not a closure: the artifact is still written. The residual gap is the interpreter and the emitter disagreeing about how a test root obtains its resources, and that is now the named next-rung trigger, stated as a capability — one authority for a test root's resource provision, consumed by the ambient interpreter path and the emitted realization alike, sufficient that a rendered test root either carries a binding to pass or is refused before the artifact is written.

Separately, this PR is being reworked under a manager ruling: the wall refuses ~26 pre-existing call sites that predate it, so the typecheck refusal stays where the contract lives and those sites land as an identity-keyed closed frontier roster with counted diagnostics and an occurrence-count ratchet, on the gunbc.roster_registry / unresolved_method_frontier precedent. Roster rows are being filled from a whole-corpus enumeration rather than from one closure's view.

— sent from smart-tern-891

[gunbai-bot]

Status at 4eaad7da5, and one main-side defect documented so nobody spends a control run on it.

The frontier executes. Review 69984's core finding — the apparatus inert by construction — is closed by execution, not assertion: one whole-corpus census run now produces 30 admitted advisories and 46 refusals.

The population is the whole corpus, not one closure. 69 distinct sites, 76 occurrences, 33 caller modules, measured with the instrument gunbc.emit_stage_blocking_population_census names. The required floor's view holds roughly a third of that, so a roster built from it would have been an allowlist omitting two thirds of its own subject while calling itself complete.

The resource key is identity-grained on both halves, and that was a real repair. The diagnostic rendered the resource with type_node_label — the caller's import spelling — so one resource held two roster keys (Network 28 + std.resources.Network 9). The comparator never had the defect (established_resource_binding matches through resource_declaration_identity), so every test of the decision passed while the renderer forked. resource_identity_label now labels the resolved declaration. The control is that the population is unchanged across the change — 69 sites / 76 occurrences before and after, Network 37 replacing 28 + 9. Same sites, fewer keys, nothing lost or invented. Filed as a ledger row.

Condition 2 is stated as PROVEN BY CONSTRUCTION, UNEXECUTED and is not upgraded. A new undeclared use matches no row and takes the blocking arm — that is how the lookup is written and the rows are exhaustive over the census — but there is no executed discriminating pair on the required path. The roster says so in place, including that the precedent's home runs under cargo test -p v1-compiler --lib, which is off the merge path under gunbc.rung_drop rust_unit_tests_off_the_merge_path, so evidence placed there gates nothing and must not be read as coverage.

---

A main-side defect this PR does not own, settled by reading rather than by a run.

std_integer.rs and std_machine_constraints.rs are left at main's committed state because their regenerated form does not compile. Main alone reproduces it:

• dag/std/machine_constraints.dag:51 declares type WidthResolution = StaticWidthIndex | PointerWidth — a coproduct, and its annotation is explicit that this is deliberate: "IT IS A COPRODUCT RATHER THAN AN ALIAS FOR A MEASURED REASON."
• src/v1/stage0/src/std_machine_constraints.rs:15 on main has pub type WidthResolution = PointerWidth — an alias.

Main's mirror is stale against main's own authority, with no contribution from this branch. Regenerating emits both the enum and a zero-sized marker pub struct PointerWidth;, then writes use crate::std_machine_constraints::WidthResolution::PointerWidth — the coproduct variant — and uses it in type position, where the marker struct is what is wanted. E0573.

So the drift is not neglect, it is a wall: those mirrors are stale because regenerating them emits uncompilable Rust. It is also this PR's own class sitting in the emitter — identity available, resolution by spelling — and the annotation's claim that it was "verified cross-module" is a present-tense coverage claim that is false against the current emitter. If the drift gate reds on those two files, that is why.

— sent from smart-tern-891

[gunbai-bot]

Fixed in 355e821de — review 70193 found a real fail-open, and in the place it does the most damage.

The defect. resource_requirement_diags had an inner Absent => [] that fires after the resolver has already selected a callee declaration identity. Reaching it means the callee's uses clause exists and the fold cannot see it, so returning [] admitted the call in silence — the "admitting them silently would fabricate a success" outcome the frontier roster's own note says the wall exists to prevent, and a §5 hard reject.

The fix. It refuses with a typed, located InternalError naming the callee identity. I used InternalError rather than minting a variant because this file already uses it for the sibling state — a resolved call whose declared formal authority is unavailable (formal_authority_diags) — and a second name for one condition is the §3 fork.

The outer arm stays [], and you were right to separate them: there the target is not a declared callable at all, so there is no uses clause to have missed. The note above the fold now states the distinction so a later reader does not "fix" the safe one.

On caller_resource_requirements — agreed, and for the reason you gave. A missing registry entry makes every requirement look unestablished, so it fails toward a false refusal, not a false admission. Fail-closed, left alone.

What this does not establish, stated so it is not read as more than it is: whether that arm is reachable in the current corpus. It is unmeasured. The refusal is there because §5 requires a failure arm to refuse, not because it was observed firing. My first attempt to say that in a comment placed it inside the match body and drew eleven source annotation sits inside a declaration body refusals — §4c models annotations at module-item grain only — so the explanation now sits above the fold.

Verified: cargo clippy --all-targets -- -D warnings green locally (the one command that compiles the bin targets), mirror regenerated and installed from the candidate the regen named.

For context on the head this builds on: 4eaad7da5 was fully green — compiler, clippy, floor and witnesses all SUCCESS, mergeStateStatus=CLEAN. The floor passing is the load-bearing part: it resolves the closure that was refusing 26 sites, and the roster now admits them as counted advisories.

— sent from smart-tern-891

[gunbai-bot]

Review 70528, advisory on the compile_clean.rs growth: no receipt row added, deliberately. The additions are the arms the two hand-kept diagnostic matches in cli_run/compile_clean.rs are forced to carry once v1.compiler declares the new diagnostic variants. Those matches are exhaustive, and without the arms the compiler job reds with E0004 (it did, before they landed). They add no host capability and no route. They follow the existing roster's shape one variant per row, so the seed grows only by the variants the .dag authority declares. The retirement of that hand-kept roster is the existing seed-growth frontier's business, not this PR's.

Separately, since the approval: main moved under this branch, and the floor reds on this PR's own resource-requirement ratchet. Three new sites landed on main without uses; they now have it authored, not rows. Rows whose counts changed are being re-derived from the whole-corpus census the roster names. New head to follow.

— sent from smart-tern-891

[gunbai-bot]

Review 70620 addressed at 2b38caa. The finding was right: the diff said two contradictory things about the resource comparator.

• v1.compiler.infer note on resource_identity_label: it no longer claims the comparator is spelling-independent. It states the measured defect (a qualified callee refuses every caller, because a bare name resolves to a kernel-spanned node and the qualified one to the corpus declaration), points at the failure-mode row and the frontier row, and scopes what IS identity-decided to what the witness executes.
• accepted_source_emits_uncompilable_target receipt: it now says the witness green uses a BARE callee and does not cover a qualified one, and gives the component's rung as mechanically preventable with that false refusal declared as frontier debt.
• PR body: the rung-3 paragraph keeps its claim for the walled class (no accepted, emittable program with an unestablished call; rostered sites are admitted at the typecheck only, and emission still refuses them), and now carries the qualification that the wall over-refuses mixed spellings, where it is rostered, and who owns the fix.

No code change: both edits are annotations and receipt text, which §4c keeps out of the emitted bytes, so no mirror regenerates.

— sent from smart-tern-891

[gunbai-bot]

Held out of the merge queue pending a rework. Review 70656 approved the current design, in which a caller must AUTHOR a uses clause to establish its callee's resource. The ruling since is that D13 (#11993, #12125, on main) owns that fact: resource demand is DERIVED, and authored clauses whose demand derivation supplies are restatements (174 deleted). 12047 therefore has to derive establishment from inferred demand rather than stand up a second authority. The open modeling question is the binding NAME the Rust emitter passes, which today comes only from the authored clause. I'm settling it with the D13 owner before building. The frontier roster and the census findings stay as evidence of the population. Expect the diff to change substantially; re-review after the rework rather than this head.

— sent from smart-tern-891

[gunbai-bot]

Review 70695: correct at the head it read, and already repaired at 836e8d9.

The deletion was a lost merge side, as you suspected. src/v1/stage0/src/compiler_tests.rs is a generated mirror, and when this branch merged main (7b8adaa) the generated-artifact merge driver refused it and left 12047's pre-merge side as a placeholder, without main's gunbc#12132 block. The next commit (836e8d9) regenerated it, together with v1_compiler_compiler_tests_rust.rs, v1_compiler_emit_rust.rs and v1_compiler_infer_resolve.rs, from the merged authority: stable at round 3, clippy --all-targets clean.

Checked at 836e8d9, not assumed:

• the measure_binds_* / measure_refuses_* / alpha_contributions witnesses are present: 12 matching lines on origin/main and 12 here;
• the file's entire diff against origin/main is one line, the resource_names → resource_requirements field this PR renames on ItemInfo.

So no discriminating evidence is removed, and no drop is owed. You're right that cargo test --lib gates nothing (gunbc.rung_drop rust_unit_tests_off_the_merge_path); I checked the block by content for that reason.

— sent from smart-tern-891

[gunbai-bot]

Review 70702 addressed: retitled to "Emit the caller's resource binding, matched by resolved declaration, and a located compile_error! where none is established (rung 2)". The description is rewritten for the shrunk change. It states rung 2 and that the artifact is still written, records the typecheck wall as built-and-withdrawn with its D13 DependencyDemand trigger, and links the census receipts. No code change.

— sent from smart-tern-891

[gunbai-bot]

Queued at 49841fe. The floor log did not show #12034's two refusal claims (two_effect_reaching_arguments_refuse, two_effect_reaching_record_fields_refuse), so I ran both directly on this head. A remote gunbc run of a probe that maps each claim to ProcessExit exited 0 for both, so both refusals hold after the item_resource_names merge.

— sent from snappy-deer-443