Fold phase 1: the registry slice is conferred, not configured

[emooreatx]

Phase 1 of the CIRISRegistry fold — the role gate. Composes nothing yet, and says so.

Full scope in the new FSD/REGISTRY_SLICE_ROLE_GATE.md.

The ordering constraint

No server converts to a canonical node until CIRISServer can serve registry capabilities under the granted role.

Convert first and you turn three working registries into three blessed nodes that cannot do registry work. This gate is what makes "can serve registry capabilities" something the node evaluates rather than something the operator asserts.

Why the boolean was the wrong shape

The slice is selected today by cfg.slices.registry. An operator setting a boolean is exactly the self-assertion the accord-scrub model exists to remove: a node is canonical because the trust root signed off, and the same should be true of the authority slice it runs.

The good news: no charter amendment

This was the open question. The baked genesis-charter declares [infra:attest, infra:serve, infra:store, infra:transport], and genesis-grant:ciris-canonical-1-d7bdeu223k carries all four. Registry's work is attestation-shaped, so it rides infra:attest + infra:serve — verbs a canonical node holds the moment it's blessed.

That matters because the scopes live in the signed bytes, so amending the charter is an m-of-n re-scrub by the holder roster, not an edit. This needs none.

What lands

registry_slice_conferred() walks capability_roots_to_trusted_root(dir, me, me, INFRA_ATTEST_SCOPE).

Both key ids are ours deliberately — the question is "do I hold this capability, from a root I myself accept?". The second half is the operator's un-trust lever: delete the trust:accepts row and the walk returns None, the slice goes dark on its own, and nothing special-cased it.

The check lives inside compose_registry rather than at the call site, because an authority check belongs with the thing it authorises. cfg.slices.registry survives as an operator opt-out only: it can keep a blessed node from serving, and can never make an unblessed node serve.

It cannot join Capabilities, which is evaluated before the Engine is open — a pre-corpus structural gate, which is exactly why DEFAULT_LENS_STORE_MIN_GIB is a baked constant rather than a config:* object. A delegation-graph walk needs the corpus, so this gate is necessarily post-corpus.

The trap this PR is shaped around

compose_registry was todo!(), unreachable only because the config bool defaults to false.

Swapping the boolean for the grant check without first giving the function a non-panicking body would panic at boot on exactly the nodes that are blessed — canonical-1 holds all four charter verbs. That is a production outage dressed as a one-line change.

So the body is honest instead. Conferred nodes log that they're blessed and that the surfaces aren't composed yet; unblessed nodes log the withholding as the ordinary steady state it is. Ok(None) is not an error — a node that was never blessed must still finish booting and serve everything else.

Tests

Three, pinning that regression directly:

• an unblessed node resolves to Ok(None) — a steady state, not a fault
• withholding is not a boot failure (matches!(.., Ok(None)))
• asking about a stranger's key confers nothing

379 lib tests green (376 pre-existing + 3).

Not in this PR

Phases 2–4, scoped in §6 of the FSD: the persist-native rewrite of builds / verify / revocation / integrity / transparency; Portal's UI arriving as client cards rather than a re-hosted RPC surface; and the public GenesisBundle broadcast that retires /v1/steward-key.

On that last one — steward-key retires rather than being carried because there is no working contract to preserve. Three mutually incompatible schemas exist and no two agree: verify's actual HTTP client expects single-steward {classical{}, pqc{}, …} whose non-Option fields are absent from what registry serves, so it fails to deserialize outright. The live response also declares signature_mode: "HYBRID_REQUIRED" while carrying no signature field at all. The GenesisBundle is self-authenticating — it carries its own hybrid authorizations from two accord holders over the charter — so it satisfies CIRISRegistry#133 by construction rather than by patch.

Upstream

CIRISRegistry#76 is done (CIRISRegistry#136, CI green): registry-core now resolves on this repo's exact triple — persist v32.3.0 / edge v17.4.1 / verify v13.3.1 — which is what makes it composable here at all. It absorbed 31 majors of persist drift with zero library changes; all six edits were test code.

Refs CIRISRegistry#62, CIRISRegistry#76, CIRISRegistry#133, #441

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[emooreatx]

Rationale for this PR's shape — the ordering constraint, why the gate lives inside compose_registry, the no-charter-amendment finding, the boot-panic trap it is built around, and why /v1/steward-key is retired rather than repaired — is recorded in #537 so it survives the PR body. That issue also states what this PR deliberately does not do (the surfaces, the manifest consumer in #25, and conversion behind the #441 quorum decision).

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

[emooreatx]

Rebased onto main at 0.5.218 (53d1ffb5): clean across 251 commits, no conflicts. cargo check --lib --tests is clean, cargo fmt --check is clean, and the six tests this PR adds pass (3 role-gate, 3 trust-root broadcast).

Upstream is ready for it: CIRISRegistry PR #140 puts ciris-registry-core on this repo's exact triple (persist v52.0.1 / edge v38.1.0 / verify v18.0.0), and its no-default-features build carries no sqlx, tonic or tokio-postgres. This answers the rebase-or-recut question the rc6 changelog raises for this PR.

[emooreatx]

Pushed 0edbb2c7: the registry slice now holds and serves CEG-native build manifests, and a new mesh ladder proves it end to end on the synthetic trust root.

harness/mesh-repro/scenarios/manifest.sh, three docker nodes (two blessed for the registry slice, one bystander), final sample:

1.rooted=3 2.conferred=2 3.holds_commons=1 4.peered=2 5.owners_accept=3 6.refused=1
7.admitted=1 8.served_on_a=1 9.row_on_b=1 10.blob_on_b=1 11.unblessed_is_nowhere=1
→ SUCCESS: full chain green

A pipeline with its own keypair, blessed by delegates_to(root → pipeline, infra:attest), publishes a Contribution and its manifest bytes to registry A only. The Contribution, the pipeline's key and its grant replicate to registry B; B's puller fetches the blob (outcome=Stored { announced: true }), and B serves the build with provenance it re-verified against its own accepted root, the returned bytes hashing to the attested value. An unblessed pipeline with a valid signature is refused pipeline_not_blessed and served nowhere. The bystander holds the row and not the bytes. Row and blob reached B about five and a half minutes after publish, on the anti-entropy cadence.

Fixed on the way, each found by the ladder:

• the slice could never be conferred (slices.registry defaulted off; the gate asked about the alias, not the wire key);
• commons blobs were declined on every node, so a manifest could not move; a conferred node now consents, with the canonical roster as its holders;
• the harness bless granted the canonical infra:serve only.

Filed: CIRISVerify#299 (verify v18's manifest Contribution is not storable by persist v52), CIRISEdge#785 (the commons holder roster is fixed at puller spawn), #710 (a first-run claim leaves the node Attributed, not Rooted).

ciris-registry-core is pinned by rev to CIRISRegistry#143 until that is merged and tagged. Local gates: fmt, clippy -D warnings with and without test-anchor, 604 lib tests.