04 - SUPERTRACK D: Rollback Reopens-Bypass Review

Assumption: rollback happens under stress, possibly mid-cutover. Can it re-open legacy PUBLIC EXECUTE, a gateway overwrite, or leave mixed old/new authority?

Checks

check	result
S15 rollback does not restore unsafe PUBLIC EXECUTE while the new plane is partially active	PASS - XHB-02: S15 rollback returns to the exact pre-cutover baseline, which is itself safe-blocked (apply blocked since NOT_SAFE, no permit open); the new plane stays dormant, not deleted
rollback sequencing prevents mixed old/new authority	PASS-after-fix (MD-01) - made explicit: S15/S16 each run as a single atomic operator transaction with a guard-verified end state; a partial failure triggers immediate stub/snapshot restore to the prior coherent baseline
rollback after owner/ACL cutover does not hand authority back without readiness blocking	PASS - S16 rollback restores directus ownership => returns to the directus-owned BLOCKED state (the very condition that holds readiness blocked)
rollback after manifest activation returns readiness to BLOCKED	PASS - readiness stays BLOCKED until manifest active AND cutover done; S14 rollback re-activates prior payload; G-ROLLBACK-SAFE asserts apply/permit blocked
rollback after expected-constraint failure leaves no partial constraints	PASS - S08/S11 no-go halts before seal; candidate-only objects dropped in reverse order
rollback after DOT-overwrite-guard failure does not unfreeze DOT	PASS - a G-DOT-NOOVERWRITE/G-DOT-FROZEN failure is a no-go; no rollback path touches DOT freeze flags
rollback snapshot required before REVOKE/GRANT changes	PASS-after-fix - MX-3 covered S16; Max extends the same verified-snapshot discipline to S15's legacy-EXECUTE revoke (the S00-captured prior-EXECUTE state is read-back-verified before S15)
rollback verification defined after every privilege restoration	PASS - each S15/S16/S17/S18 rollback row has a post-verify; G-BIRTH-NEUTRAL re-checks the gateway hash after S15 rollback

Finding (folded)

MD-01 - mixed-authority window + gateway-overwrite-on-rollback made explicit

• Two latent ambiguities a stressed operator could hit: (a) a partial S15/S16 that fails midway could leave some objects on the new owner and some still PUBLIC-executable (mixed authority); (b) it was not stated that rollback restores the gateway by pinned source rather than a fresh CREATE OR REPLACE (which would itself be an overwrite vector).
• Fix (doc 04 dependency notes + doc 05 note 5): the live cutover steps S15/S16 each execute atomically with a guard-verified end state (G-NOLEGACY / G-OWNER-CUTOVER / G-DIRECTUS-READ); a partial failure triggers the immediate #27 rollback-stub (S15) or snapshot restore (S16) to the prior coherent baseline, so no mixed old/new authority persists. Rollback never CREATE-OR- REPLACEs the gateway - it restores the pinned source_sha256 / prior ACL, and G-BIRTH-NEUTRAL re-checks the gateway hash afterward, so rollback cannot reopen a gateway overwrite.
• Tied to MB-01: the S15 rollback restores the complete captured prior-EXECUTE baseline (all 46 PUBLIC), not a partial subset, so there is no partial-grant gap on rollback.

Verdict

ROLLBACK_BYPASS_PASS_AFTER_FIX - no rollback path re-opens legacy PUBLIC EXECUTE except as the return to the standing safe-blocked baseline (XHB-02), no rollback re-opens a gateway overwrite (pinned source + G-BIRTH-NEUTRAL), and atomic cutover + verified snapshots prevent any mixed old/new authority state.