X_FRAMEWORK_SCHEMA_FAILED

a framework table could not be created at boot

a statement in FRAMEWORK_SCHEMA did not apply — the two real ones are a role that cannot apply DDL (42501: no create on schema public, or not the owner of an existing framework table — a production runtime role, which is why only the migrate step applies it), and a relation of that name already present with an incompatible shape. Raised in place of the driver's own rejection, which names neither the framework table being created nor the package that wants it, and a boot failure is read by an operator with no source tree open: cause names both and meta.tables lists every relation that entry creates. The list is reached on every boot path through startQueue: ROLE=migrate, x db migrate, x dev and x mcp serve apply it; a serving role on an external database only verifies the stamp the migrate step left; every other CLI command (x db backfill, x jobs, x auth) applies it only when this build's stamp is absent, because Postgres refuses even create index if not exists to a role that does not own the table — so "installed in dev and not in production" is not a state this framework can be in, and a runtime role with DML only runs no DDL provided this build's stamp is present — on a database the migrate step has not stamped, or stamped by another build, that command attempts the DDL and fails here, which is the signal to run the migrate step first. What it closed: x_users, x_sessions, x_accounts, x_verifications and x_api_keys were exported as DDL for an app to paste into a migration nobody wrote, and applied by NOTHING. They are not entity() declarations, so x db gen never saw them either, and the reference app recorded the symptom — nobody could hold a session — without anyone reaching the cause

x db migrate with DATABASE_URL naming the role that owns schema public, as ROLE=migrate runs