11 — Level-B DOT / Migration Pipeline Review (SUPERTRACK K)

Design statement (02,09,11): "All privileged live changes run only through approved owner-credentialed Level-B DOT/migration pipeline … never manual SQL."

#	Question	Design answer	Verdict
K.1	Why must privileged deployment go through Level-B DOT/migration?	privileged changes need the NOLOGIN owner's credentials, append-only manifest discipline, recorded approval, and rollback — a manual psql session bypasses all of that and is unauditable	INTENT-OK (rationale sound)
K.2	What manual SQL is forbidden?	manual owner/ACL/role/extension/manifest-activation/repoint via ad-hoc psql	INTENT-OK; explicit forbidden list good
K.3	How is deployment proof recorded?	"artifact read-back"; pipeline records	NEEDS_CLARIFICATION — what the pipeline records (migration id, hash, approver, timestamp, read-back diff) is not specified
K.4	How is rollback staged?	"rollback snapshots" required for FIX7b (09)	NEEDS_CLARIFICATION — no rollback script/snapshot is published; prior fixes shipped explicit 99_rollback.sql
K.5	How is operator approval represented?	"exact active activation-policy quorum, independent principals … Operator alone cannot activate" (02)	INTENT-OK; the approval record schema (who/quorum/signature) not specified
K.6	Can T1 safely author/test but not activate?	"T1 may author/test FIX7a/b/c"; live deploy operator-gated; activation operator-only	PASS (intent) — the author/test vs activate boundary is the clearest, most correct part of the design

Analysis

The pipeline discipline is the right answer to "how do privileged changes happen without reintroducing manual hardcode/ad-hoc bypass." The tension worth flagging:

Tension between "Level-B DOT/migration pipeline" and the existing operational reality. Per project memory, all prior QT001 DDL was applied via ssh contabo → docker exec -i postgres psql -U directus -d directus with rehearsed BEGIN..ROLLBACK and a staged 99_rollback.sql — i.e. manual, owner-less psql as the directus superuser-of-its-own-tables. FIX7 declares that path forbidden for privileged changes and substitutes a "Level-B DOT/migration pipeline." But that pipeline is not shown to exist (no artifact, entrypoint, or DOT id in the FIX7 docs). Per muc-tieu-mo §3.6 (Artifact Runtime Pack) and Live Apply Hard Gate 0: "README claim is not execution artifact." If the Level-B pipeline does not yet exist as a runnable, owner-credentialed channel, then FIX7b/FIX7c are not OPERATOR_HANDOFF-ready — they are AUTHOR_MODE until the pipeline itself is built and proven.

This does not block FIX7a authoring, but it is a prerequisite to any privileged FIX7b/c deployment and must be made explicit so T1 does not assume the pipeline exists.

Level-B pipeline verdict

No ad-hoc privileged SQL path in the design intent (correct, and the author-vs-activate boundary is clean — PASS on K.6). But deployment-proof recording, rollback staging, and approval representation are unspecified, and the Level-B pipeline is asserted without being shown to exist as a runnable artifact. → PASS(K.6) + NEEDS_CLARIFICATION(rest). Required correction: define the pipeline artifact (entrypoint, owner credential source, approval/quorum record, read-back/proof log, rollback snapshot) or explicitly classify FIX7b/c as AUTHOR_MODE-until-pipeline-exists.