Seed-growth roster cites eval_match/match_pattern once (claim red on main; floor declined, not passed)

[gunbai-bot]

Work item adhoc-8b3eef0a-13d (reported by bold-swift-383 on gunbc#13090).

Which route was right

claim_batch/gunbc run --claim-run was right. The required floor gave no verdict: test.claim.seed_growth_admission_witness matches neither required_gate_prefixes nor required_gate_authored_modules, and floor run 37110271994 (03b96ed) lists the module's identity as outside this run's universe — preparation never offered them. A green run that declined a claim did not pass it. This is a population difference, not a disagreement between evaluation orders or closures.

Root cause (6b)

All three reds come from seed_growth_roster_mechanical_checks_holds. Probing its conjuncts on main ca79f2c found every justification well-formed, but seed_growth_roster_duplicate_keys() = v1_interpreter::eval_match, v1_interpreter::match_pattern, each listed twice. #12846 (Nat de-fork) added both to kernel_grounding_interpreter_seed_growth_justification, but #12903's match_arm_guard / value_depth rows already roster them. The roster cites each declaration once (see the convention stated in value_drop_binding_adaptation_seed_growth_justification). #12846 touched only a module the witness imports, so the witness never ran on its PR.

The earliest unjustified link is the #12846 row. The duplicate check and the witness are both correct. This PR removes the two refs from that row, and its reason now names them as already justified by their own rows.

Control

The existing witness is the discriminating control. BuildBuddy, GUNBC_MEMORY_BUDGET_BYTES=20000000000:

• main ca79f2c: 4 PASS / 3 FAIL (the three named in the report)
• this branch: 7/7 PASS

Failure-mode row

This is an existing class, so I appended a receipt to witness_outside_gate_closure_falsified_by_other_file rather than minting a duplicate row.

Not done here: needs a ruling

Admitting this module to the required gate would apply the class's trigger to one module, but a gate row is a standing cost on every required run. I'm asking the parent rather than adding it.

🤖 Generated with Claude Code

[briansrls]

Approved at exact head 3db0bc5.

The diagnosis is correct: the required floor's green was not a contrary verdict; this witness is outside that floor population. The claim route exposed a real duplicate-key defect. eval_match and match_pattern were each cited in exactly two justification rows on base; removing them from kernel_grounding_interpreter_seed_growth_justification leaves their existing item-grain homes (match_arm_guard_seed_growth_justification and value_depth_seed_growth_justification) while the kernel-grounding row retains the later edit, trigger, and boundary in prose. This follows the repository's established convention that one declaration is cited once even when a later change also modifies it.

Appending this occurrence to witness_outside_gate_closure_falsified_by_other_file is the right classification: #12846 changed an imported dependency, the out-of-gate witness did not run, and the existing witness discriminates red on base versus 7/7 green after the authority repair. Gate enrolment is a separate standing-cost/operator ruling and does not block this correction.

All four exact-head checks are green. Queue for merge.