KB-5EEF

BLOCKER D - No-Mixed-Authority Activation Order Fix

4 min read Revision 1
fix7codex-recheck-patchno-mixed-authorityactivation-order2026-06-08

05 - BLOCKER D: No-Mixed-Authority Activation Order Fix

Codex recheck finding

G-NOMIXED-AUTHORITY read ACTIVE manifest_activation + legacy effective executability. S14 activated the new manifest BEFORE S15, while legacy routines remained PUBLIC/owner-executable until S15/S16. Thus the guard's invariant was already violated immediately after S14 activation. Codex required: distinguish "manifest ACTIVE but unrouted" from "authoritative routed/executable" using a PG-native route/authority fact, and prefer STAGED/PENDING_CUTOVER before neutralization, ACTIVE only after G-NOLEGACY-POST and G-NOMIXED-AUTHORITY pass. (Codex recheck CHECK_E NEEDS_FIX.)

The fix - STAGED activation + activation moved into the atomic cutover (docs 04, 05, 06, 07, 08)

  • Activation is deferred and re-ordered. S14 now only stages: the sealed manifest stays manifest_set.activated_at = NULL (SEALED-not-ACTIVE), the #26 gateway routes fail-closed, readiness is BLOCKED, and the live writer remains on legacy. The manifest is not the authoritative path.
  • Activation happens at S15.4, inside the same atomic operator transaction as the legacy neutralization, and only AFTER S15.1-S15.3 have made legacy non-executable. PKG-E (create+seal+stage) no longer activates; PKG-F (atomic neutralize+activate+repoint) does.
  • G-NOMIXED-AUTHORITY tests a PG-native route/authority fact, not manifest existence. The fact is manifest_set.activated_at IS NOT NULL (and not superseded) → an ACTIVE manifest_activation for the writer type = the new path is authoritative-routed. A STAGED manifest beside executable legacy is NOT mixed (legacy is the sole authoritative path - the S14 state). An ACTIVE manifest beside executable legacy is forbidden and cannot occur, because activation (S15.4) follows neutralization (S15.1-S15.3) within one atomic transaction.

Permitted states / forbidden transitions (S14, S15, S16, rollback)

checkpoint new-path route state legacy executable? mixed?
after S14 STAGED (activated_at NULL) yes (sole authority) NO
during S15 (S15.1-S15.3) STAGED being neutralized NO (atomic, uncommitted)
after S15.4 commit ACTIVE (activated_at set) no NO
S15 rollback (ordered) deactivated FIRST (activated_at cleared) → THEN legacy restored restored last NO

Forbidden and structurally prevented: ACTIVE new path co-existing with any executable legacy path.

Rollback (doc 05 note 5) - proves the route state, not merely manifest lifecycle

The S15 rollback is deactivation-first: (1) deactivate the new path (clear/supersede activated_at); (2) verify readiness BLOCKED; (3) verify the gateway cannot route the new path; (4) only THEN restore legacy per disposition (STUB: sealed evidence_registry body + ACL; ALL: restore prior owner directus + ACL from the S14 snapshot); (5) verify G-NOMIXED-AUTHORITY + G-BIRTH-NEUTRAL. Because the new path is proven inactive before any legacy EXECUTE/owner is restored, no mixed window exists.

Self-check

PASS only if an ACTIVE new path cannot coexist with an executable legacy path. PASS - STAGED ≠ authoritative; activation follows neutralization atomically; G-NOMIXED-AUTHORITY keys on the ACTIVE route fact; rollback deactivates before restoring legacy.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-blueprint-patch-after-codex-recheck-owner-semantics-2026-06-08/05-no-mixed-authority-activation-order-fix.md