06 - Directus SELECT Retention / No-Authority Cutover Review (SUPERTRACK F)

Source: artifact 06 (full read, content_length 1209). Verdict: DIRECTUS_CUTOVER_NEED_CORRECTION (one blocking ambiguity CP-07).

Verified strong

• Authority removal exact: post-cutover Directus = schema USAGE + SELECT only; no DML/TRUNCATE/REFERENCES/TRIGGER/CREATE/TEMP/EXECUTE/ownership/grant-option; no authority-role membership; PUBLIC none.
• Authority is a sealed ACTIVE PRIVILEGE_SET, "never handwritten list" - matches privilege_set_manifest #21; not a manual inventory.
• Preflight is thorough: captures access-log + registered read inventory, current/proposed owner ACL/default privileges, smoke-request expected hashes, denied-authority tests, rollback ACL hash.
• No-go is real: "Any observed read missing from proposed manifest => BLOCKED_READ_PATH, no ad-hoc grant"; any read mismatch/4xx/5xx/missing/uncertain/unmanifested -> abort BLOCKED_READ_PATH.
• Atomic cutover under epoch lock with revalidate -> transfer -> revoke -> apply SELECT/USAGE -> fix default privileges -> prove denied authority -> prove every read smoke hash -> increment epoch and keep apply blocked.
• Rollback: postcommit regression revokes writer and owner-gated rollback restores prior reviewed SELECT only (never unsafe authority); rollback increments epoch and sets readiness false.
• Readiness blocked before cutover; no authority remains Directus-editable after cutover. Both required properties met.

Blocking ambiguity

F-1 Base-table SELECT vs presentation-view read preservation is internally inconsistent (CP-07)

The doc says Directus keeps "SELECT only manifest-listed presentation views (base-table SELECT only separately proven)" and "Reads continue through sealed views." This is the crux of the original feasibility concern (prior correction #5: retain Directus SELECT so REVOKE does not break app read paths), and as written it is ambiguous in a way that can break production reads:

• Directus generates SQL from its own schema cache against the collections/tables it is configured for. If it currently SELECTs base tables/columns, those reads cannot be transparently redirected to views unless either (a) Directus retains base-table SELECT, or (b) the base tables are renamed and views created under the old names, or (c) Directus is reconfigured to read the views - each with different risk.
• The parenthetical "base-table SELECT only separately proven" suggests base-table SELECT may be retained, while "Reads continue through sealed views" suggests migration to views. These cannot both be the default; one path must be chosen and proven.

If the chosen path is view-only but Directus still issues base-table queries, the cutover's own no-go (observed read missing from manifest) would fire post-revoke and the rollback restores SELECT - safe, but it means the cutover predictably cannot complete, i.e. the design is not implementable as a forward step. Codex must state definitively which path is taken and prove the preflight inventory is captured from Directus's ACTUAL emitted queries (base table vs view), with the no-go evaluated before any revoke.

Verdict

DIRECTUS_CUTOVER_NEED_CORRECTION. The cutover is fail-closed and rollback-safe (it cannot silently break reads - worst case it aborts/rolls back). The correction is to remove the base-table-vs-view ambiguity and prove read-path preservation against Directus's real query surface, so the cutover is a completable forward step rather than a guaranteed abort (CP-07).