The resolution ledger never shrinks

[ccerv1]

Uniqueness protects identity integrity. It does not protect completeness. The ledger only had the first.

The gap

Three per-category tranches ran serially tonight (#431, #432, #433) and each rebase conflicted on sources/resolution_ledger.yaml, because every pass appends to it. The tempting resolution is to take one side — and doing so is invisible to every guard the file already has.

Demonstrated rather than argued. Simulating a side-pick that drops the two entries #431 appended:

real entries: 290 | floor: 290
side-pick drops #431's block: 290 -> 288
  loads clean, no DuplicateResolution: 288 entries  <- uniqueness misses it
  floor check 288 >= 290? -> the floor CATCHES it

The dropped file produces no duplicate, leaves the four sentinel cases in test_the_four_cases_that_produced_this_file intact, and loads without error. Two governance decisions would simply be gone, and the next bulk run would recreate both — which is the exact failure the ledger was built in #419 to prevent.

What this adds

One invariant: len(load()) >= LEDGER_FLOOR, currently 290. Raise it deliberately when a pass appends; never lower it. The failure message points at git log -p --follow for recovery rather than inviting a lower number.

Two design choices worth stating

A count floor, not a digest over the key set. A digest would also catch a swap, but it changes on every legitimate append, so it would be noise rather than signal. And a side-pick does not swap — it drops a block, which a count catches.

A floor, not named entries. The first draft of this pinned one entry per recent tranche, and it failed immediately on Mai-with-u/MaiBot because that decision is still sitting in open PR #433. Pinning specific decisions couples the test to the order passes merge in, which is the one thing a serialized queue cannot promise. That failure is the argument for the floor, so the docstring records it.

Note on ordering

Floor is 290, which is main today. #433 appends one more, so after it lands the floor can be raised to 291 — but it does not need to be for this to be correct: a floor is a lower bound, and leaving it one behind main costs only the sensitivity to a single-entry loss. Raise it at the next convenient pass.

[ccerv1]

Rebased onto main now that #433 has landed, and raised the floor 290 → 291. New head 3fb911a.

That closes the one-entry tolerance I had left deliberately. At 290 a side-pick dropping #433's single MaiBot entry would have given 290 and passed. Verified both directions at the new number:

drop #431's block: 291 -> 289, loads clean; floor 291 -> CATCHES
drop #433's block: 291 -> 290, loads clean; floor 291 -> CATCHES

Both load with no DuplicateResolution raised, which is the point — uniqueness cannot see either.

I also recorded in the constant's comment why it is hand-written rather than derived, since that is the non-obvious part of the design: a floor that computes itself from the current ledger would derive 289 from a damaged one and prove itself correct. The independent number is what gives the test memory.

One acknowledged limitation, stated so it is not discovered later: the floor only stays strong if append PRs ratchet it. If the ledger grows 291 → 340 with the constant untouched, losing 20 entries would pass. That is an argument for making "append a ledger decision → raise the floor" part of the contribution contract rather than for different machinery, and the failure message already points a maintainer at git log -p --follow rather than at lowering the number.