Compiler floor: payload-carrying coproduct arm literals get an excess-field roster (the class is wider than sibling variants)

[gunbai-bot]

The class, corrected

A record literal on a payload-carrying coproduct arm received no excess-field judgment at all.
Not "admits sibling variants' fields" — the lane's original title. The discriminating control is the
nowhere-declared field:

type Shape = Circle { radius: Int } | Square { side: Int }
Circle { radius: 1, nowhere: 2 }     // compiled with zero FieldNotFound on origin/main
S { a: 1, nowhere: 2 }               // the same mistake on a product type refused

Four zeros on sibling-field probes cannot separate "the roster leaks to siblings" from "no roster is
consulted", and it was the second. A repair scoped to sibling arms would have left the class open,
and a §4b(3) row declared against the sibling class would have been retired by a trigger that never
restored the capability.

The asymmetry that hid it, on one literal. Against an arm declaring radius and color,
Circle { radius: 1 } reports MissingField == 1 while Circle { radius: 1, nowhere: 2 } reports
FieldNotFound == 0. The literal refused an omitted field and accepted an invented one, so
nothing downstream ever looked wrong.

Mechanism

variant_arm_type_projection projects an arm out of its owner only when the arm carries no
payload, so lookup_type_by_name hands infer_record_lit_structural the OWNER coproduct for a
payload arm. record_lit_construction_field_names required Conj, answered none, and the
unknown-field arm's Absent => [] was silence. Presence checking never had the hole because it
reads the arm through variant_owner_node — two halves of one judgment consulting two authorities,
one of them absent.

field_in_any_variant_named, which the lane title names, was not the admitting disjunct: it is
consulted only when construction_field_names is Present, which an arm name never produces.

The repair: one roster, not a second lookup

The excess check now reads presence_fields — the same cascade MissingField uses, which asks
variant_owner_node and the expected type before any bare-name fallback. field_in_any_variant_named
and record_lit_construction_field_names are both deleted, not narrowed: 91 lines of emitted
seed removed against 23 added.

none and [] stay distinct and the distinction is the wall. none = roster UNKNOWN (unresolved or
ambiguous name) → stay silent. [] = roster KNOWN and EMPTY = a nullary arm → Red { x: 1 } refuses
while the bare tag Red is untouched.

A first attempt this PR discarded, because the corpus falsified it

The first mutation invented its own roster via a bare-name lookup_type_by_name. It refused valid
code: CodexRuntimeBundle names a local coproduct arm in gunbc.host_converge and an unrelated
product type in gunbc.package_delivery, and the name-only lookup answered with the foreign
product's fields. Same for PullRequest { branches, types } in witness_floor_workflow — decisively
a false refusal, since the emitted witnesses.yml visibly carries those fields. No synthetic probe
could catch either: they are all single-module and cannot express a cross-module homonym. The
presence cascade has been deciding MissingField corpus-wide, so its resolution behavior is the one
with evidence behind it.

Evidence (executed)

probe	before	after
arm + valid fields	0	0 accept
arm + sibling arm's field	0	1 refuse
arm + nowhere-declared field	0	1 refuse
arm + unrelated coproduct's field	0	1 refuse
product + nowhere-declared field	1	1 refuse (pre-existing wall)
product + valid field	0	0 accept
arm omitting a required field	MissingField 1	MissingField 1, FieldNotFound 0
nullary arm, bare tag Red	0	0 accept
nullary arm handed a field	0	1 refuse

All 11 arms of test.claim.infer_record_lit_variant_field_witness_test appear in the
required-floor-disposition artifact as planned_as_changed_witness … passed — executed, not merely
enrolled. Its module prefix is inside required_gate_prefixes.

Corpus population: 3 refusing identities + 1 repaired defect that refuses nothing, all repaired here

The newly-refusing population is three — identities 1, 2 and 4 — every one observed by execution:

identity	field	arm	observed in
1 gunbc.fabric_control_plane_charge fabric_control_plane_charge_authority	reason	nullary SingleAuthority	floor + build, run 33448581154
2 gunbc.type_reference_containment_binding ..._scaffold	bind	nullary SingleAuthority	floor, run 33466952287
4 v2.test.claim.execution.emit_ingest_..._round_trip_test claim_...	label	BoolWitnessClaim	floor, run 33453548917

Identity 3 is a REPAIRED DEFECT, not a member of the newly-refusing population, stated separately rather than folded in:

identity	field	arm	why it refuses nothing
3 gunbc.annotation_parse_instrument_agreement ..._disposition	authority	Terminal	the module has zero importers corpus-wide and no required lane resolves it, so this floor change would never have refused it in a gated context

That module is resolved by no required lane, pinned by three independent facts: its name appears
nowhere in the floor log; the build lane passed with the defect present on a probe branch, so
its closure demonstrably excludes it; and nothing imports it. A scoped --entry compile — the last
route — OOM-killed the runner at 97% of 7.86 GB, because --entry scopes what is emitted, not
what is indexed. No available host can compile that module. It is a true defect (Terminal
declares only reason) and it is repaired here, but it is not promoted to "observed", and no
replica fixture is offered in place of the site.

SingleAuthority is a nullary arm of ConstructionMechanism and not a Disposition arm at
all, so the first two declared a Disposition by naming something that is not one. Every repair is
behaviour-preserving: the excess field was analysed and then discarded, so nothing read it.
(Initializer analysis measured independently by smart-moth-158.)

§4b(3)

No declared drop is owed. A drop row covers a rung lowered; this raises one and refuses nothing
that was correct. The population is closed and repaired in this PR, so there is no bounded runway or
restoration trigger for a row to carry. Rung: mechanically preventable → structurally guaranteed
for the excess-field class on source→interpretation. Not impossible — the invalid state is still
authorable in source, which is why the RED probes stay enrolled.

Honest ceiling: the roster stays none (silent) where the cascade cannot resolve the name — an
unresolved or ambiguous bare name. Unchanged behaviour, the same guard MissingField uses, named
here so "structurally guaranteed" is not read as covering it.

Seed

Regenerated from the corrected .dag: drift in exactly one file, second --required-regen returned
first_generation_equal=true. Mirror v1_compiler_infer.rs sha256
0d1a308a806f7a9841840f4195d48872785baf6aa2857a8de202d0d0deefef1e.

Lane adhoc-0f99c6bc-193. Intake packet bound to tree ec48ae29ba (the merge of 09360be7d3b
into main 37e705c42e — a PR run compiles the merge ref, not the head), run 33455123780.

One changed byte in a stage0 seed file that is NOT this change

src/v1/stage0/src/gunbc_rust_source_type_bindings.rs differs from main by one line. It is
regenerated output, not authorship. Nobody edited it here, and it must not be reverted to main's
bytes to make this PR look tidier — those bytes are a known-false projection.

What it is. The proof field of the checkpoint_row_migration_rows row whose dag_name is
"String", disposition ProvenUniqueKernelBinding. The committed proof is 694 bytes and the
authority emits 3422; they agree for 296 characters and then diverge. The new text opens "THE
VERDICT STANDS AND ITS ORIGINAL ARGUMENT WAS EXACTLY INVERTED, corrected here rather than softened
because the inverted form would justify the wrong things if reused" and restates the old
shadowing-is-the-identity-on-one-token argument as the thing being corrected. gunbc#9949 moved that
authority row and did not regenerate its mirror, so main is authority-ahead-of-artifact on one row.

How it got here. The merge's own re-emission wrote it. Resolving the v1_compiler_infer.rs
conflict required rebuilding the emitter from the installed seed and re-emitting the merged
authority; that pass re-derives every projection, including this one. It was not sought and it is
not scoped work.

Why it is worth stating rather than hiding. It is why this PR's required-witnesses-build is
green while gunbc#9977, #9984 and #9985 are red on the same file — the only branch that regenerated
is the only branch whose mirror matches its authority. A natural experiment, not a claim.

It is deliberately not expanded here. The standalone repair is being cut off current main by
lively-koi-693. Whichever lands first makes the other trivial. This PR is a compiler-floor change
and stays one; the retracted phrase over a fixture module importing is present once on main and
zero times here, which is the whole of the difference.

[gunbai-bot]

This PR reads mergeable=MERGEABLE / mergeStateStatus=CLEAN on GitHub, and the repository's own merge driver refuses it.

Measured just now against current origin/main:

git merge-tree --write-tree origin/main <this head>   # rc=1
[generated-artifact] GeneratedArtifactConcurrentDivergence
CONFLICT (content)

Both sides changed a generated projection since the merge base, so neither side's bytes are the projection of the merged authorities. GitHub does not run this repo's merge driver — its mergeable is its own text merge, so it is structurally blind to the class the driver exists to catch, and the dashboard's merge criteria inherit that blindness because they read GitHub's field.

This is not hypothetical: squashing a PR in this state silently reverted two siblings' ledger rows earlier today (#9868), and #9937 exists only to put them back. The loss lands outside any conflict region, so nothing reds.

Fix — do not hand-resolve and do not pick a side:

1. Merge origin/main into the branch (merge commit, not rebase).
2. Regenerate the projection from the merged authority using the driver's own printed recipe rather than editing the bytes.
3. Verify by content that main's rows survived, comparing row key and cell length — a key-set comparison misses within-row truncation, which is how one of today's losses got through.

A census of all open PRs found 15 in this state; this is one of the ones GitHub is reporting as clean, which makes it among the more dangerous.

[gunbai-bot]

Correcting my own comment above: the remedy I gave is the wrong one for this PR.

I wrote the generic recipe — regenerate through tools.generated_artifact_gate. That is right for a documentation projection (docs/design-ledgers.md, DESIGN.md). It is not right here.

This PR's divergence is on src/v1/stage0/src/v1_compiler_infer.rs — an emitted seed file, not a doc. It needs the seed-emitter route:

cargo build --release --bin claim_executor
target/release/claim_executor --required-regen --source-root dag --source-root src/v2
# installs under target/stage0-regen-candidate/src BEFORE it judges; install every file it names
cargo build --release --bin claim_executor
target/release/claim_executor --required-regen --source-root dag --source-root src/v2 \
  && target/release/claim_executor --required-regen-fixed-point

The second rebuild-and-verify is not optional: the first pass runs a binary that predates the change it emits, so one pass can self-verify at divergence 0 for the wrong reason.

And this case is worse than the doc case, which is why I am correcting rather than leaving it. A bad resolution on a ledger produces a stale document that the next drift gate catches loudly. A bad resolution on v1_compiler_infer.rs silently drops inference logic out of the seed the entire bootstrap runs on — and that loss is the kind that compiles. It lands outside every region a checker examines while everything reports green.

Apologies for the noise; better a second comment than a wrong recipe standing.