07 - BLOCKER F: workflow_admin Superuser / bypassrls Break-Glass Control (in-blueprint)

Codex recheck-2 finding (docs 01, 07)

workflow_admin has superuser/bypassrls and cannot be excluded as a mere "accepted out-of-band property." The blueprint must not pretend ACL can restrict it: treat superuser/bypassrls as outside the ACL-zero model, require operator-level / break-glass control, require a distinct sealed Level-B execution identity, reframe readiness from "superuser effective privilege = 0" (impossible) to "no unauthorized use path," and add a guard that flags active superuser use outside the approved Level-B artifact.

Live evidence (read-only, DB directus, 2026-06-08)

workflow_admin: rolsuper = true, rolbypassrls = true, rolcanlogin = true, rolcreaterole = true, rolcreatedb = true. It bypasses every object ACL and RLS policy and cannot be reduced to effective-privilege zero by any ownership/ACL change.

The fix — G-SUPERUSER-BREAKGLASS + operational policy (blueprint docs 04, 06, 08)

1. Outside ACL-zero. The blueprint states explicitly that superuser/bypassrls is outside the removable scope; no guard claims it is privilege-zero, and no "=0" aggregate silently includes it (guard-quality rule 5).
2. Break-glass, operator-gated. Any superuser use is break-glass only, tied to an explicitly authorized operator break-glass record — never a normal FIX7 path. Added as an OPERATOR_GATED hard-block row in doc 08 §A.
3. FIX7 runs as the Level-B principal, never as workflow_admin. Every FIX7 live step (S15/S16, PKG-E..H) runs as the Level-B-bound migrator/owner principal (CP-09 principal_registry), distinct and sealed — not the cluster superuser.
4. Readiness reframed. Readiness requires "no unauthorized superuser use path", NOT effective privilege = 0 (which is impossible for a superuser). The proof is: the operator session session_user is the Level-B principal, plus monitoring (pg_stat_activity / audit) shows no workflow_admin session performing FIX7 authority changes in the cutover window.
5. Guard. G-SUPERUSER-BREAKGLASS (doc 06) FAILS if any rolsuper/rolbypassrls session performs FIX7 authority changes outside an explicitly authorized Level-B break-glass record.

Relationship to blocker A

Blocker A makes the owner role unreachable (NOLOGIN + no membership + Level-B-only SET ROLE). Blocker F handles the superuser role, which A cannot touch (a superuser bypasses everything). The two together close the reachability question: the only principals that can act on the legacy/control objects are (a) the unreachable NOLOGIN owner, (b) the Level-B-bound operator principal acting under authorization, and (c) the superuser only via audited break-glass.

PG-native, no new surface

Reads pg_roles (superusers) + pg_stat_activity/audit + the FIX7 operator session_user. One new test/verification guard; no authority surface/column/family/hash. The break-glass policy itself is OPERATOR-gated and outside T1's authorable scope.

Self-check

PASS only if superuser is treated as break-glass (not ACL-zeroable), FIX7 runs as the Level-B principal, readiness is "no unauthorized use path," and a guard flags rogue superuser use. PASS — all four, via G-SUPERUSER-BREAKGLASS + the doc-08 hard-block row + the Level-B-only operator session.