# X_FRAMEWORK_SCHEMA_FAILED

## Means

a framework table could not be created at boot

## Typical cause

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

## Fix

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

[CLI and verify](/error-codes#cli-and-verify)