Delete the keys/values/has algebra nicknames: the emit refusal was a three-row family, not one method

[gunbai-bot]

Delete the keys/values/has algebra nicknames: emit's refusal was a three-row family, not one method (five call sites, four of them silent)

The brief asked whether the emit refusal on keys was one method or a
population. It is a family of three, and the count of compile_error!
literals in the emitted tree undercounts it in both directions.

WHAT WAS MEASURED. Emitting the 03_ingest closure
(gunbc compile --entry src/v2/compiler/03_ingest.dag --source-root dag --source-root src/v2 --target rust --dependency-pool-index primary-precedence, 176 files) produced ONE compile_error!("method keys is neither a resolved callable receiver field nor a registered v1_rt bridge function"), at src/v2/std/compilers/target_model.dag
target_derive_supplemental_generic_bound_requirement_nodes_for_contract.
But .keys() has FIVE production call sites in that closure, and the
other four did not refuse -- they emitted (m.clone().keys)(), a field
access on a HashMap, from rust_receiver_has_callable_method_field.
That probe answers yes because std.algebra PartialFunction declares a
callable field literally named keys, so the emitter read a Map receiver
as a record with a keys closure field. Four of five sites therefore
FABRICATED rather than refused; only rustc would have caught them. A
histogram over emitted compile_error! literals cannot see them.

THE ROOT CAUSE IS SS3 NICKNAMING, FORKED ACROSS TWO REALIZATIONS.
partial_function_templates declared both keys and map_keys, both
values and map_values, and has beside map_has -- one concept, two
names. v1_interpreter.rs carried method_call.keys and
method_call.values arms byte-identical to their map_* siblings, and
has as a spelling alternate on method_call.contains. The Rust emitter
registered only the map_* half. So the interpreter accepted a spelling
the emitter could not emit: a path divergence, not an emit-surface gap.

THE CUT (delete-first, SS3): the three nickname rows are gone from
partial_function_templates; the PartialFunction interface fields are
renamed to the surviving canonical spelling (map_keys / map_values /
map_has), which is what removes the callable-field collision; the two
duplicate interpreter arms and the "has" alternate are deleted, and
v1_interpreter_dispatch_generated.rs regenerated from the roster; the
dead std.methods rows are dropped. All 11 .keys() call sites (5
production, 6 test) are rewritten to map_keys(...). values and has
had zero call sites.

WHY THIS IS ADMISSIBLE UNDER THE v1 FREEZE: it is deletion in direct
service of the v2 self-host emission, not growth.

EVIDENCE, BY EXECUTION.

• Re-emit of the same closure: RC=0, 176 files, 502 advisory (unchanged
  from before the cut), 0 compile_error!("method ..., 0 .keys)().
  The one production keys call now emits
  Rc::new(v1_rt::map_keys(&incoming.entries.clone())).
• DISCRIMINATING RED, post-cut binary: m.keys() on a Map is now
  refused at resolve with a located diagnostic -- probe.dag:4:40: error: method 'keys' not found on receiver type 'Map(...)'. Before
  the cut the same input compiled with "0 diagnostics" and emitted the
  compile_error! macro. The class climbed from a rustc-visible emit
  marker to a refusal on the source->.dag-acceptance path.
• POSITIVE CONTROL: count(map_keys(map_insert(empty_map(), "a", 1)))
  evaluates to 1 through the interpreter.
• claim_executor --required-regen: FAIL on std_algebra.rs drift
  (the candidate diff was exactly this change and nothing else), mirror
  installed, re-run first_generation_equal=true planned=128 executed=128.
• cargo build --release --bins green (the deleted arms redded E0004
  until the generated dispatch enum was regenerated -- the closed
  vocabulary did its job).

WHAT IS NOT CLOSED, NAMED RATHER THAN LEFT TO BE REDISCOVERED. get /
map_get is the same nickname pair and survives, because both halves are
routable today so it produces no refusal; closing it is a 547-site
rewrite that this diff does not attempt. No witness is enrolled for
"no algebra template name has a map_-prefixed twin", because such a
witness would red on get/map_get on its first run and would need an
exception list -- a second roster beside the algebra authority, which is
the violation it is meant to police. The next-rung trigger for the class
is the get/map_get consolidation, not a lens.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[gunbai-bot]

The red on this PR is a pre-existing defect in the receipt phase, not this change

Recording it here rather than only in chat, because whoever merges this will see a red check.

This PR's own content is green. From run 32448150852:

• floor: planned=9914 executed=9914 terminal=9914 passed=9607 known_red_held=206 failed=0
• required-ci: parse OK 50 file(s) parse-clean
• required-ci: regen first_generation_equal=true
• required-ci: regen-fixed-point fixed_point_equal=true

The failing phase is receipt, and it fails for two causes, neither of which is a behavioral change introduced here.

Cause 1 — the gate reports DIVERGENT over a byte-identical file

In that same run, regen established that the emitted std_algebra.rs is byte-identical to the committed mirror. The behavioral receipt then installed that candidate over the mirror and reported DIVERGENT. It compared a file against itself and could not answer EQUIVALENT.

The first_difference it printed is kernel_algebra_profile_value() — a function this PR does not touch — with the same seven entries in a different order.

generate_receipt_driver renders every derived call as println!("... = {:?}", call), and that function returns Rc<HashMap<String, AlgebraProfile>>. The two halves of the differential are produced by two separate driver processes, and Rust's HashMap iterates in per-process randomized order.

Proved by execution, independent of how CI scored any run. A one-line driver built against the committed libv1_compiler.rlib, printing that call through {:?}, run 20 times on an unchanged tree:

20 distinct transcripts out of 20 runs

So this is the normal outcome for a map-returning function in a selected authority, not a bad night. The gate does not fail open here — it fails wrong.

Cause 2 — an authority whose mirror this emit cannot produce

behavioral-receipt: gunbc.v1_interpreter_primitive_surface REFUSED — the emit produced no
v1_interpreter_dispatch_generated.rs, so there is no candidate to compare.
Not equivalence: a missing candidate is ignorance

That artifact is produced by main_wet on tools/generated_artifact_gate.dag, not by the stage0 mirror emit, so no candidate can ever exist for that authority. The refusal is correct as written — ignorance is not equivalence — but it means any PR touching that roster reds this phase by construction.

Disposition

Both are being handled in a separate PR, coordinated with the session already editing this phase (#8699), so the per-cause counter vocabulary is shared rather than forked. Not fixed here: riding a CI-gate repair in under an algebra-nickname review is how a green PR becomes a red one.

Noting one limit on the fix I proposed, so it is not read as more than it is: keying the exclusion on the outermost return type is a proxy for the real property, which is the value's transitive shape — a record containing a HashMap renders nondeterministically and would pass a return-type check cleanly, and HashSet has the same property. The higher rung is deterministic emission (BTreeMap), which makes the nondeterminism unwritable rather than detected and excluded.

— sent from snappy-ferret-99

[gunbai-bot]

Correction and current status, on green main

My earlier comment on this PR is now partly superseded, and one prediction I made about this run was wrong. Correcting both here rather than leaving the stale version as the record.

What changed since that comment

Main was red for about an hour on dag/gunbc/fleet_desired_admission.dag:169 (a non-exhaustive match; FleetDesiredRevision grew from two variants to four in #8701 and this consumer was not updated in the same commit). That is fixed by #8744, main is green again, and this branch has merged it. The floor now passes on this PR: planned=9921 executed=9921 terminal=9921 passed=9614 known_red_held=206 failed=0.

I had also attributed that defect to #8643. That was wrong — #8643 merely last-touched the file and its two-arm match was exhaustive and correct when written. #8701 grew the type. For a type/consumer mismatch the owner is whichever side landed second, not whoever last edited the file with the match in it.

The prediction I got wrong

I predicted this run would fail on the missing-candidate cause alone. It failed on both receipt causes:

behavioral-receipt: gunbc.v1_interpreter_primitive_surface REFUSED — the emit produced no
  v1_interpreter_dispatch_generated.rs, so there is no candidate to compare
behavioral-receipt: std.algebra DIVERGENT over 31 derived calls — seed:
  kernel_algebra_profile_value() = {...}

The reason is simple and I should have caught it: the fix for the DIVERGENT cause is in #8743, a different PR. This branch carries the unpatched gate, so that cause still fires here. I had "that cause is fixed" in mind without asking which tree carries the fix — the same class of error as reading a green from a merge ref that predates the change you care about.

Where this actually stands

Everything this diff owns is clean:

required-ci: parse OK 50 file(s) parse-clean
required-ci: regen first_generation_equal=true
required-ci: regen-fixed-point fixed_point_equal=true
required-ci: receipt-selftest OK both arms discriminate
required-floor: ... failed=0
required-ci: phases_run=6 failed=1   (FAILED PHASE receipt)

Two gate causes remain, neither in this diff:

1. std.algebra DIVERGENT — the receipt renders every derived call through {:?}, and kernel_algebra_profile_value returns Rc<HashMap<..>>, which iterates in per-process random order. Measured: 20 distinct transcripts over 20 runs of one unchanged binary. In the run before this one, required-regen reported first_generation_equal=true for std_algebra.rs and the receipt then reported DIVERGENT over that byte-identical file. Fixed by The behavioral receipt reported DIVERGENT over a byte-identical file: measure instability instead of rendering it as a difference #8743, which is green and approved; verified end-to-end against this exact tree, where the verdict becomes EQUIVALENT over 30 derived calls, with 1 EXCLUDED as nondeterministically rendered — kernel_algebra_profile_value.

2. the missing candidate — v1_interpreter_dispatch_generated.rs is produced by gunbc.generated_artifact_emit through main_wet, not by the mirror emit, so this fragment asks the wrong generator. The refusal is correct as written (ignorance is not equivalence). Not fixed, and deliberately not worked around: the clean fix routes through the single artifact→content authority, and calling the per-artifact emitter directly would be a second dispatch beside the real one.

So this PR needs #8743 merged, then cause 2 resolved. I am not re-running before #8743 lands, since a re-run would reproduce both failures.

— sent from snappy-ferret-99