fix(design): renumber colliding ledger ids DL-327..330 to DL-334..337 (RIG-3107) - #927
Conversation
… (RIG-3107) A concurrent-merge window landed five records claiming overlapping ledger ids. This record (#905, RIG-3107 delivery cutover) allocated DL-327..333 off a main whose tail was DL-326, but four earlier-dated records merged first and already held the low four: - DL-327 — SubjectService token principal (#868, compass-server) - DL-328 — gateway-credentials at-rest encryption (#859, compass-server) - DL-329 — compass-stack supervision (#872, platform) - DL-330 — apple-container macOS runner (platform) The double-booked ids fail design-ledger-gate:check on main ("duplicate ledger id" x4), which blocks every lane's pre-push moon ci until it lands. Renumber this record's four rows to the next free ids (max on main is DL-333): DL-327 to DL-334 (OQ-1 held-deliver ack timing), DL-328 to DL-335 (OQ-2 callback-direct dispatch), DL-329 to DL-336 (OQ-3 part 1 DB-role split), DL-330 to DL-337 (OQ-3 part 2 publish-side recovery trigger). DL-331/332/333 are uniquely this record's already and stay put. The earlier claimants' ids do NOT move, per the DL-319/320 precedent (fab4a67, #851): the later claimant renumbers. Those ids are cited by merged frozen records other lanes implement from (DL-327 in 6 files, DL-328 in 4), and both the stack-supervision and apple-container records carry prose deriving their own id from main's then-current tail ("main's ledger tail was DL-328 ... so DL-329 is the first free number") — reasoning that stays correct precisely because only this record's rows move. DL-333's Decision cell cites the reconnect hook by id, so its internal DL-330 reference is retargeted to DL-337 in the same pass; the ledger's decision prose is otherwise byte-identical (verified: 304 rows before and after, diff empty once ids are masked). Annotates the frozen record header with the mapping and restates its Ledger-impact line as DL-331..337 (annotate-don't-rewrite house rule); the in-body citations read as point-in-time, with the ledger rows canonical. Standalone on purpose: main is red for every lane until this lands, so it is not bundled into the T3 implementation stack. Co-authored-by: Matt Wilkinson <matt@rigel.build>
|
😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details. |
|
Compass engineering docs preview: https://compass-managed-rig-3107-led.compass-eng-docs.pages.dev Deployed from Changed pages: |
DL-330 was claimed by the merged apple-container macOS-runner record, so Record A's row was a duplicate and would have red the fail-closed design-ledger-gate on merge. DL-340 sits above every in-flight mint (#927/#916 hold DL-333..337), not merely above main's tail — a tail check cannot see a concurrently-open claim, which is how this class of collision keeps recurring. Co-authored-by: Matt Wilkinson <matt@rigel.build>
Note for the merge decision: this clears the ledger cause, and main will still show one red checkMeasured on main's tip Two independent failures feed
Era control on
Six of six, back to 2026-09-05T23:35 — before the commit that introduced the ledger collision (04:10Z). Its log (run So: merging this clears the ledger cause and The ledger-side warrant is unchanged and none of it rests on this PR's own green
|
Correction to my note above:
|
| commit | rollup |
release-pr |
|---|---|---|
d857449b |
success | failure |
ab56c273 |
success | failure |
8fef2846 |
success | failure |
fab4a67f |
success | failure |
bf216c24 |
success | failure |
So a failing release-pr is fully compatible with a green required gate.
Corrected consequence: design-ledger-gate:check inside moon (bun) is the only failure in rollup's chain at this tip. Merging this PR removes it, and the required context goes green. release-pr will still show red on its own row — visible, not blocking.
Credit where it is due: another lane falsified my claim and asked for it to be re-run rather than asserting it; I re-ran all five commits and they hold. My own era-control table in the comment above listed d857449b — where release-pr was the only failure and rollup was green — so the counter-example was already in my own data and I read past it. An era control shows a thing is old; it says nothing about whether it is load-bearing, and those are different questions.
The ledger-side warrant is unchanged: effect (duplicate ids []), mechanism (deletes exactly the four colliding rows from #905, re-adds at free ids), content preservation (304 decision texts in, 304 distinct out, zero rulings lost; the one rewritten line is DL-333's cross-reference retargeted hook (DL-330) → hook (DL-337)), and an observed push-event authority chain. None of it rests on this PR's own green rollup — the gate does not run on a docs-only PR event.
Final note on that red check: it is a filed, owned, queued human action — RIG-2995Closing the loop on my two comments above so the merge decision needs no external context. I described RIG-2995 — release lane T6: provision release-please GitHub App + repoint It matches the failure exactly: So the complete picture for this merge:
Merging this PR removes the only failure inside Nothing further is owed on this PR from my side. The ledger warrant stands as stated: effect (duplicate ids |
|
Review-warrant disclosure on this PR, from applying two peer rules to my own work. My all-clear artifact covers The unreviewed delta is So the unreviewed 102 seconds contain this PR's only admitted rule exception. Verified
Verdict unchanged: the exception is correctly reasoned and correctly executed, and the One general note, since it applies to every status line I have written today: |
2 participants
fix(design): renumber colliding ledger ids DL-327..330 to DL-334..337 (RIG-3107)
A concurrent-merge window landed five records claiming overlapping ledger ids.
This record (#905, RIG-3107 delivery cutover) allocated DL-327..333 off a main
whose tail was DL-326, but four earlier-dated records merged first and already
held the low four:
The double-booked ids fail design-ledger-gate:check on main ("duplicate ledger
id" x4), which blocks every lane's pre-push moon ci until it lands.
Renumber this record's four rows to the next free ids (max on main is DL-333):
DL-327 to DL-334 (OQ-1 held-deliver ack timing), DL-328 to DL-335 (OQ-2
callback-direct dispatch), DL-329 to DL-336 (OQ-3 part 1 DB-role split), DL-330
to DL-337 (OQ-3 part 2 publish-side recovery trigger). DL-331/332/333 are
uniquely this record's already and stay put.
The earlier claimants' ids do NOT move, per the DL-319/320 precedent (fab4a67,
#851): the later claimant renumbers. Those ids are cited by merged frozen
records other lanes implement from (DL-327 in 6 files, DL-328 in 4), and both
the stack-supervision and apple-container records carry prose deriving their
own id from main's then-current tail ("main's ledger tail was DL-328 ... so
DL-329 is the first free number") — reasoning that stays correct precisely
because only this record's rows move.
DL-333's Decision cell cites the reconnect hook by id, so its internal
DL-330 reference is retargeted to DL-337 in the same pass; the ledger's
decision prose is otherwise byte-identical (verified: 304 rows before and
after, diff empty once ids are masked).
Annotates the frozen record header with the mapping and restates its
Ledger-impact line as DL-331..337 (annotate-don't-rewrite house rule); the
in-body citations read as point-in-time, with the ledger rows canonical.
Standalone on purpose: main is red for every lane until this lands, so it is
not bundled into the T3 implementation stack.
Review
Review loop: ALL-CLEAR (0 high, 0 medium, 3 low). The reviewer independently
reproduced the red-to-green proof (gate exits 1 with the 4 duplicate-id errors
on parent
e77becc5, exits 0 on this tree), and verified the OQ-to-id mappingcell-by-cell: each Decision cell carries its own
(OQ-n)marker and anchor,neither touched, so a swap would have shown up as a mismatch. None found.
Content non-mutation proven two independent ways (leading-id masking and full
id-column stripping): 304 rows before and after, one differing line, the
deliberate DL-333 retarget.
Lows folded as the additive second commit: the note claimed
"DL-331/DL-332/DL-333 are unchanged" while DL-333's cell is edited here, so
the one row that changed was the row the note said did not. Now stated
explicitly, and cited as a narrow exception to the ledger's
"immutable after append" rule so the next cross-citation renumber has a
precedent to point at.
Note for other lanes
#913(RIG-3326) currently claims DL-334/DL-335 in flight and will needDL-338/DL-339 once this lands;
#900claims DL-330, already double-booked onmain. Both lanes notified. Re-grep main's tail immediately before promoting:
a stale clone reads the gate as OK and GREEN even while main is red, which is
the trap that produced this incident.