fix(design): renumber colliding ledger ids DL-327..330 to DL-334..337 (RIG-3107)

[rigel-mintaka]

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:

• DL-327 — SubjectService token principal (docs(server): design the SubjectService token principal (RIG-2863) #868, compass-server)
• DL-328 — gateway-credentials at-rest encryption (docs(design): gateway-credentials at-rest encryption + two-layer secret providers (RIG-2863) #859, compass-server)
• DL-329 — compass-stack supervision (docs(platform): design self-host stack supervision — keep pgid, decline Quadlet (RIG-3239) #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.

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 mapping
cell-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 need
DL-338/DL-339 once this lands; #900 claims DL-330, already double-booked on
main. 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.

[linear-code]

RIG-3107

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

Compass engineering docs preview: https://compass-managed-rig-3107-led.compass-eng-docs.pages.dev

Deployed from compass-managed/rig-3107-ledger-renumber at 1e0f76c.

Changed pages:

• docs/designs/DECISIONS.md
• docs/designs/infra/runtime/compass-managed-delivery-cutover/design.md

[rigel-mintaka]

Note for the merge decision: this clears the ledger cause, and main will still show one red check

Measured on main's tip e77becc5f557 with a paginated check-run census (total_count=33; an unpaginated read returns 20 of 33 and silently hides the second failure):

5 failure · 5 skipped · 23 success

rollup       run=34030910029
moon (bun)   run=34030910029
rollup       run=34010810021
moon (bun)   run=34010810021
release-pr   run=34010809960   <- separate workflow run

Two independent failures feed rollup:

• moon (bun) — fails on design-ledger-gate:check, reporting duplicate ledger id for DL-327, DL-328, DL-329, DL-330. This is what this PR fixes.
• release-pr — a standing failure in the release workflow, unrelated to the ledger.

Era control on release-pr across the last six main commits:

commit	committed	release-pr
e77becc5	2026-09-06T04:10:01Z	failure
d3488ff7	2026-09-06T04:09:58Z	failure
fcec444a	2026-09-06T03:59:44Z	failure
efe8712a	2026-09-06T03:59:41Z	failure
d857449b	2026-09-05T23:55:34Z	failure
d524f022	2026-09-05T23:35:40Z	failure

Six of six, back to 2026-09-05T23:35 — before the commit that introduced the ledger collision (04:10Z). Its log (run 34010809960) shows a Node module-load stack plus Token is not set and a deprecated app-id input warning, so it looks like a workflow/credential problem in the release surface rather than anything in the design corpus. Not diagnosed further here and not routed — flagging it as measured fact.

So: merging this clears the ledger cause and design-ledger-gate:check goes green, but main's rollup stays red on release-pr. A persistent red after this merge is not this fix having failed.

The ledger-side warrant is unchanged and none of it rests on this PR's own green rollup (the gate does not run on a docs-only PR event — its affected closure is computed over projects, and no project owns docs/designs/):

• effect — duplicate ids [] on the resulting tree
• mechanism — deletes exactly the four colliding rows introduced by docs(runtime): freeze T3 delivery→EventFabric cutover design (RIG-3107) #905 and re-adds them at free ids
• content preservation — 304 decision texts on main, 304 distinct after; zero rulings lost. The one non-preserved line is DL-333's cross-reference, rewritten from hook (DL-330) to hook (DL-337) so it still points at its own subject. Independently re-derived by two other lanes.
• authority chain — observed on the push event: the gate's verdict is what fails moon (bun), which propagates to rollup, the sole required context.

[rigel-mintaka]

Correction to my note above: release-pr does not gate rollup. Merging this will green the required context.

My previous comment said main would stay red on release-pr after this merges. That is wrong, and the error was in the inference, not the data. release-pr is a standing failure, but it is also non-gating — I checked that it was old and never checked whether it was load-bearing.

Two legs, both measured:

Structural — rollup is compass main's sole required context, and its dependency list does not include release-pr:

.github/workflows/ci.yml:2224
  needs: [setup, moon, e2e, pgtest, microvm, forge-oracle, gtk4-e2e, darwin]

release-pr lives in .github/workflows/release.yml:58 — a separate workflow,
separate run id, outside that chain.

Empirical — five recent main commits have rollup = success while release-pr = failure:

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.

[rigel-mintaka]

Final note on that red check: it is a filed, owned, queued human action — RIG-2995

Closing the loop on my two comments above so the merge decision needs no external context.

I described release-pr as unrouted. It is not. Another lane identified it and I verified the row independently:

RIG-2995 — release lane T6: provision release-please GitHub App + repoint v* ruleset — Todo, label human-action, Owner: compass-native, assigned to Matt, filed 2026-08-30, parent RIG-1746.

It matches the failure exactly: release.yml's release-pr job authenticates through actions/create-github-app-token, which needs RELEASE_PLEASE_APP_ID and RELEASE_PLEASE_APP_PRIVATE_KEY. Those secrets are not provisioned yet, which is the Token is not set line in run 34010809960. The issue explains why it cannot be code: release-please must use a scoped App installation token rather than GITHUB_TOKEN, because a GITHUB_TOKEN-opened PR receives no pull_request CI under GitHub's recursion guard — so the App creation, secret storage, and ruleset repoint are one-time settings actions with no Pulumi rail in this repo today.

So the complete picture for this merge:

check	cause	in rollup's chain?	owner
moon (bun)	design-ledger-gate:check, duplicate DL-327..330	yes	this PR
release-pr	GitHub App not yet provisioned	no (release.yml, separate workflow)	RIG-2995, queued for Matt

Merging this PR removes the only failure inside rollup's chain and the required context goes green. The release-pr row stays red until RIG-2995's provisioning happens; it blocks nothing and is not related to the design corpus.

Nothing further is owed on this PR from my side. The ledger warrant stands as stated: effect (duplicate ids []), mechanism (deletes exactly the four colliding rows introduced by #905, re-adds at free ids), content preservation (304 decision texts in, 304 distinct out, zero rulings lost; DL-333's cross-reference retargeted hook (DL-330) → hook (DL-337) so it still points at its own subject), and an observed push-event authority chain — none of it resting on this PR's own green rollup, since the gate does not run on a docs-only PR event.