BLOCKER D - No-Mixed-Authority Activation Order Fix
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 ACTIVEmanifest_activationfor 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.