Tracking issue. Restore the AV-28 quorum assertion once CIRISRegistry's trust root settles. Twin of CIRISPersist#809 — the two repos should restore together rather than drift again.
What was downgraded, and why
CIRISEdge#571 rewrote the release pre-flight for CIRISRegistry v3.0.0's accord-bundle shape (live 2026-09-04 ~19:41Z), and asserted the bundle's own declared quorum was met — authorizations >= M, with M parsed from consensus_protocol (quorum:2/3 → 2).
That assertion is now report-only. CIRISPersist#809 made the same call first, and its reasoning applies here unchanged:
holders and authorizations move during the migration, and a tag run blocked on a mid-migration count is a release blocked on somebody else's deploy window.
Edge has a specific reason to weigh that heavily: v20.2.0 shipped with no GitHub Release at all because this same pre-flight refused a registry that was healthy. Losing a release to a registry state we don't control has already happened once.
What it costs — stated, because a check that cannot fail is a report
For the length of the transition, this leg cannot catch a registry serving a bundle whose quorum has collapsed. What still fails in that case is the register binary manifest step that follows; this leg is early warning, and this half of it is warning only.
What is still gated
The downgrade moves exactly one case. Verified by re-running the fault matrix from #571:
| case |
before |
after |
| live bundle, quorum met |
pass |
pass |
quorum NOT met (1 of quorum:2/3) |
fail |
pass + ::warning:: |
| no holders |
fail |
fail |
no charter_root_key_id |
fail |
fail |
unparseable consensus_protocol |
fail |
fail |
| old v0.8.x shape, deployed steward |
pass |
pass |
| old v0.8.x shape, none deployed |
fail |
fail |
| unrecognised third shape |
fail |
fail |
So an absent or unrecognisable root still reds the lane. Only a countable but short quorum is waved through.
Done when
- CIRISRegistry's trust-root migration is complete and the served bundle's quorum is stable.
- The
if len(signed_by) < need: branch in .github/workflows/ci.yml (pre-flight registry trust-root check) goes back to fail(...).
- The fault matrix above is re-run and the
quorum NOT met row returns to fail.
- Coordinated with CIRISPersist#809 so the two guards do not diverge — two sibling repos enforcing different thresholds against one registry means one can release while the other cannot, for reasons neither repo's code explains.
Tracking issue. Restore the AV-28 quorum assertion once CIRISRegistry's trust root settles. Twin of CIRISPersist#809 — the two repos should restore together rather than drift again.
What was downgraded, and why
CIRISEdge#571 rewrote the release pre-flight for CIRISRegistry v3.0.0's accord-bundle shape (live 2026-09-04 ~19:41Z), and asserted the bundle's own declared quorum was met —
authorizations >= M, withMparsed fromconsensus_protocol(quorum:2/3→ 2).That assertion is now report-only. CIRISPersist#809 made the same call first, and its reasoning applies here unchanged:
Edge has a specific reason to weigh that heavily: v20.2.0 shipped with no GitHub Release at all because this same pre-flight refused a registry that was healthy. Losing a release to a registry state we don't control has already happened once.
What it costs — stated, because a check that cannot fail is a report
For the length of the transition, this leg cannot catch a registry serving a bundle whose quorum has collapsed. What still fails in that case is the
register binary manifeststep that follows; this leg is early warning, and this half of it is warning only.What is still gated
The downgrade moves exactly one case. Verified by re-running the fault matrix from #571:
quorum:2/3)::warning::charter_root_key_idconsensus_protocolSo an absent or unrecognisable root still reds the lane. Only a countable but short quorum is waved through.
Done when
if len(signed_by) < need:branch in.github/workflows/ci.yml(pre-flight registry trust-root check) goes back tofail(...).quorum NOT metrow returns tofail.