Pin the sort that main's deduplicate_identities repair depends on for correctness

[gunbai-bot]

Rewritten after main landed a competing repair for the same defect. The original PR replaced deduplicate_identities; that change is gone. What remains is 28 lines in one file: the control main's repair is missing.

What happened, and why my patch is not here

While this PR waited for a floor slot, main landed its own repair of the same quadratic dedup — sort first, then compare against the last kept element. Mine used a Set for membership and list_push for the accumulator. Both fix the quadratic scan; I argued mine additionally fixed a copied accumulator (concat(unique, [identity]) in a fold), which is the §6 bare-minimum-cost shape.

I measured that argument instead of asserting it, and it did not survive. Three variants over an amplified probe — ~720 identities with every one duplicated, ten dedup passes per run, two rounds, same host:

variant	round 1	round 2
mine (Set + list_push)	112.1s	110.3s
main's (sort + last + concat)	110.6s	127.3s
main's with list_push	110.9s	137.6s

Round 1 spans 1.5%; round 2 is dominated by host noise in the wrong direction. concat(unique, [identity]) is not a measurable O(n) copy in this interpreter, so §6 does not distinguish the two implementations — and forking a landed fix on an unmeasured preference is exactly what this project keeps catching. main's implementation is taken whole: dag/gunbc/self_host_compile_phase_frontier.dag is byte-identical to origin/main on this branch.

What survives is a gap in that fix, not a competing one

main's fold compares only against the last kept element. That is sound exactly because the input was sorted first, so equal identities are adjacent. The sort is a correctness precondition, not a presentation choice — and nothing in the corpus pins it. Delete |> sort_by(identity => identity) and the fold silently stops collapsing duplicates separated by any other identity, while still collapsing adjacent ones: a dedup that works on the easy inputs and quietly fails on the real ones.

Measured, including the part that decides whether it is worth landing

A  new witness against main's implementation                      PASS
B  same witness, `sort_by` deleted                                FAIL
C  the four pre-existing duplicate-wall witnesses vs that mutant  ALL PASS

C is the finding. a_repeated_population_entry_is_refused_rather_than_collapsed, a_duplicated_census_population_is_not_silently_collapsed_to_a_set, a_receipt_whose_refused_population_repeats_a_path_is_refused_by_coherence and current_persisted_compile_phase_frontier_holds all stay green with the sort removed. This arm is the only thing in the corpus that reddens on it.

The subject is chosen so the mutant cannot pass: ["b", "a", "b"] holds a duplicate that is not adjacent in encounter order — 2 elements under the sorted fold, 3 without the sort — with the all-adjacent cases beside it as the positive control the mutant still passes. That pairing is what makes the first arm discriminating rather than the set being merely two examples.

It asserts duplicate survival rather than output order, deliberately. Encounter order is unobservable through both consumers — canonical_identity_set sorts its result and census_population_is_duplicate_free reads only the count — so an order assertion would pin a property no caller can distinguish. The previous revision of this branch asserted exactly that, and main's change would have reddened it.

Floor

The prior head's floor reading is recorded in the comment above, including that it was the third attempt and therefore a counted retry-until-green mitigation under gunbc.rung_drop floor_cost_contention_verdict, not a verdict about the tree. This head needs its own run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W377Pq4Tp5eQjGBXtPQEoM

[gunbai-bot]

Floor: FloorClean — and the attempt count, because the green is a mitigation and not a verdict

required-witnesses-floor passed on head 76fd88e0 (run 33609023769): planned=3478 executed=3478 passed=3403 failed=0 unexpected_failures=0 interrupted_before_verdict=0, verdict=FloorClean. required-witnesses-build and the required witnesses aggregate pass.

This was the third floor attempt on this head, and I am reporting that rather than presenting the green on its own. gunbc.rung_drop floor_cost_contention_verdict (declared 2026-09-01, standing) says in its own words: "re-running an undecided row until it answers is retry-until-green — fail-open wearing a fail-closed label — admissible only as a counted, visible mitigation carrying this row's trigger as its dissolution condition." That is what these re-runs are. The count is three, the mitigation is visible here, and its dissolution condition is that row's trigger — a claim-owned cost basis invariant across execution envelopes — not this green.

The two prior attempts on the identical commit were FloorRefused with failed=0 and disjoint victim sets:

attempt	interrupted	victims
1	1	rust_produced_decl_name_discriminates
2	4	the_live_census_partitions_on_both_axes, an_empty_receipt_series_leaves_the_live_tree_unmeasured_rather_than_held, produced_decl_two_targets_render_own_order, rust_call_fold_closure_swap_discriminates
3	0	—

Attempt 1's victim passed in attempt 2 at 479ms. Four unrelated families. None of those rows is reachable from this diff.

The measurement this PR is actually about

claim	last clean main (fb481ae0)	clean sibling #10014	this PR (clean)
current_persisted_compile_phase_frontier_holds	422	446	404
the_published_frontier_standing_…	438	437	395

cpu_ms against the 500ms ceiling, three independent clean runs. The quadratic repair moves both claims down and the direction is consistent.

It does not clear the tip, and this PR does not claim to. The population over the 100ms line on the green run is 267 further rows beyond the 25 printed; the band sits well inside contention range of the ceiling, and the victim rotates with host load rather than with the tree. That is the standing drop's subject, not this PR's.

Remaining red

rust-unit-tests fails on shell_service_unmodeled_output_key_refuses. It is main's: sibling PR #10014 reports the identical 644 passed; 1 failed with the same identity, and this branch changes no Rust. It does not feed the required witnesses aggregate (.github/workflows/witnesses.yml — needs: [required-witnesses-build, required-witnesses-floor]), which is why GitHub reports UNSTABLE and admissible rather than blocked.

— sent from stern-lark-508

[gunbai-bot]

New head 48bf811a — FloorClean on the first attempt, and that is not a fourth retry

required-witnesses-floor pass, required-witnesses-build pass, the required witnesses aggregate pass, fabric-evidence pass (run 33625112248). verdict=FloorClean, planned=3487 executed=3487 passed=3412 failed=0 unexpected_failures=0 interrupted_before_verdict=0.

The attempt accounting, because a run list cannot distinguish these two things and the previous comment on this PR would otherwise be read as a count of four.

• The three attempts recorded above were on head 76fd88e0, on one unchanged commit, re-run because a claim went undecided on budget. Those are the counted retry-until-green mitigation under gunbc.rung_drop floor_cost_contention_verdict, and that count stopped at three.
• This is not a fourth. 48bf811a is a different commit — it drops my deduplicate_identities implementation in favour of main's and replaces the order witness with the sort-precondition control — and it is the first floor run of that commit. Nothing was retried; a new subject was evaluated once and came back clean.

Three-of-one-kind and one-of-another. A bare count of four would be dishonest in the direction that flatters this PR, which is why it is spelled out.

The measurement, for the record

claim	cpu_ms
current_persisted_compile_phase_frontier_holds	433
the_published_frontier_standing_…	424

These are not evidence for this PR and are recorded only so the series stays continuous. This head carries main's deduplicate_identities, not mine, so both figures are properties of main's repair plus this run's host load — they sit between the 404/395 and 446/437 already observed on other clean runs of the same implementation family, which is the band moving, not a change in the code.

On the earlier rust-unit-tests red

shell_service_unmodeled_output_key_refuses was repaired on main by another lane (green across five SHAs from 10:54Z), and this head already carries that base — baf6a7ce is an ancestor of 48bf811a. So the red that stood on the previous head was an artifact of a merge ref pinned before the fix, and no re-run was needed to clear it: the rewrite that resolved the merge conflict picked up the repair as a side effect.

— sent from stern-lark-508