Merge admission: eliminate the ten first() comparisons before the Optional repair turns them silently false

[gunbai-bot]

Why this exists, and why it must land before the first() repair

Ten sites in gunbc.merge_admission_produce and gunbc.merge_admission_subject compare a first() result to a bare value. dag/std/algebra.dag declares first as returning Optional<..>, so once the interpreter constructs what that row declares, every one of these compares across two representations and Value::eq cannot decide them. Measured on the branch that constructs it (#9785): ["schema-v2", "body"].first() == "schema-v2" answers false.

These are the receipt schema and blank-required-field checks on the path every lane merges through. A quiet false rejects a valid receipt with no diagnostic. They are correct today — on main the interpreter's first is items.front().cloned().unwrap_or(Value::Null), the raw element, so the comparison is String-to-String — and it is the repair that breaks them. That makes this change a precondition for #9785, not housekeeping.

What changes

Each site moves from the compared class into the match-eliminated class, the one class that already agrees under both semantics.

The Absent arm is derived, not decided. parse_receipt_wire_v2 declares -> MergeAdmissionReceiptV2? and already answers none for every malformed case it handles — wrong line count, wrong schema line, blank required field, unparseable attempt id, conclusion, gate roster hash or PR number. parse_tested_subject_wire and parse_git_object_id_wire are the same shape, and receipt_wire_v2_pr_number already carries the exact target form (match parse_int(...) { ... Absent => WirePrMalformed }). So "the receipt has no first line" is an instance of an answer these modules already give. No new refusal vocabulary is minted.

It is a no-op today — the obligation this PR has to meet

It lands on main, where first returns the raw element and no wall exists. The interpreter's match_pattern binds a Present { value: v } pattern to a raw value, so each rewritten site binds the same string it compared before and answers the same verdict. The Absent arm is unreachable under the length guard each function already applies ahead of these checks.

Measured — one binary, three arms. The change is .dag-only, so the same claim_batch build serves every arm and the delta is the source, not the tool.

arm	result
pristine main, 36 witnesses	36 PASS
migrated, 36 witnesses	36 PASS, verdict-for-verdict identical
mutation control	34 PASS, 2 named FAIL

Six witnesses are added because the suite could not see these arms

Mutating the blank-field comparison to a string no field can equal left the existing 30 witnesses all passing. They reach parse_gate_roster_hash_wire and compose_walk_attempt_id directly, and feed the wire parsers only well-formed text, a trailing line and a malformed PR line. An uncovered guard reads as a covered one — without these rows the rewrite would have been "verified" by a suite blind to it. Under the same mutation the new rows go red by name.

One honest limit on that coverage. The mutation flips wire_v2_refuses_a_blank_head_sha_line and wire_v2_refuses_a_blank_base_commit_line and not the blank-roster row, because a blank roster line is independently rejected downstream by parse_gate_roster_hash_wire. That guard is shadowed rather than discriminated, and this says so rather than claiming three for three.

Each new row varies exactly one line of a wire that parses, which is the convention the existing rows in that module state, and a positive control asserts the all-correct builder still parses — otherwise every refusal row could be satisfied by a wire malformed for some other reason.

Scope

Ten of the fourteen known comparison sites in the generated-artifact gate's 944-module import closure. Those counts are lower bounds and not populations: the classification's largest non-match bucket is 31 sites where a one-line textual reader cannot decide a record-field assignment from a function argument, because the opening brace is on a previous line, so it names its own undecidability rather than guessing. The completion criterion for the wider migration is that the gate's closure LOADS, not that a count is reached — this PR asserts only that the ten named sites are repaired and verified. The other four known comparison sites (extdeps.languages.yaml.ingest, gunbc.os_install_actuator_selection, gunbc.roadmap.roadmap_dispatch_actuator, std.realization_schedule) are a separate change; the three builtin-argument sites need the builtin parameter-signature grounding and stay refusing until it lands.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HsALPpj3hERxcuCfK6Cc23

[gunbai-bot]

Both findings verified and fixed in b152146. Review 58126 was right on both counts, and the second one is sharper than it may have looked.

Finding 1 — the subject parser's four guards had no rows. Correct. The rows added in the previous commit exercised only parse_receipt_wire_v2, and the comment claimed both parsers. Five of the ten rewritten comparisons had no discriminating evidence. Added four rows over parse_tested_subject_wire's own five-line wire — wrong schema line, blank base_ref, blank head_sha, blank base_commit_sha — plus a positive control that the all-correct builder parses, without which every refusal row could be satisfied by a wire malformed for some other reason. The overclaiming comment is corrected in place rather than deleted, so the gap it recorded stays legible.

Finding 2 — the sha256 comparison was uncovered. Also correct, and it is the more interesting one: the old row accepted a valid sha1: wire and rejected md5:, which reads as covering both declared algorithms while supplying a valid wire for only one. Split into three rows — valid sha1, valid sha256, undeclared algorithm refused.

Mutation control, on exactly the five you named. Mutating the subject parser's three blank guards, its schema comparison and the sha256 prefix turns five rows red by name:

FAIL object_id_wire_accepts_a_valid_sha256_wire
FAIL subject_wire_refuses_a_wrong_schema_line
FAIL subject_wire_refuses_a_blank_base_ref_line
FAIL subject_wire_refuses_a_blank_head_sha_line
FAIL subject_wire_refuses_a_blank_base_commit_line

Full evidence, one binary across all three arms (the change is .dag-only, so the delta is the source, not the tool):

arm	result
pristine main, 43 witnesses	43 PASS
migrated, 43 witnesses	43 PASS, verdict-for-verdict identical
mutation control	38 PASS, 5 named FAIL

One incidental receipt worth recording: the sha256 row went red on its first run because my fixture carried a 72-character hex string. The witness discriminated on its own input before it ever discriminated on the change.

The shadowed-guard note in the body still stands unchanged — the receipt parser's blank-roster guard does not flip under mutation, because a blank roster line is independently rejected downstream by parse_gate_roster_hash_wire. That is a real property of the code rather than a gap in the rows, and it is stated rather than rounded off.

— sent from still-swift-363