Schema awareness

When an AI assistant writes a database query, a model, or a migration without seeing the actual schema, three things tend to happen:

It uses a column name that doesn't exist (user.created_at when the project uses user.creation_date).
It writes a model field that duplicates one already on the table.
It writes a migration that conflicts with one further up the chain.

Each is small. Each is easy to fix. Each costs you ten to twenty minutes you didn't budget for, multiplied across the dozen times this happens per month per developer.

cix removes the guess. The assistant can ask "what columns does this table have?" and get a real answer, parsed from your migrations.

What it does

cix reads your migration files and assembles a structured view of every table and column in the project. The assistant can query that view directly:

"What tables does this project have?"
"What columns does the orders table have, with their types?"
"Which migration created this column?"
"Are there any tables defined in more than one place?"

The answer comes back grounded in your actual schema, not the assistant's training-time guess at what a typical orders table might look like.

What it parses

The current parsers cover the dominant patterns across the major web frameworks:

Laravel migrations (Eloquent schema builder)
Django migrations (the auto-generated and hand-written kind)
Alembic migrations (SQLAlchemy and FastAPI projects)
Prisma schema files
Raw SQL migrations (CREATE TABLE, ALTER TABLE, etc.)

For projects using something more custom — a hand-rolled migration runner, an obscure ORM — the schema view will be partial or empty. In those cases the system says so honestly rather than fabricating.

Why this matters

Queries that compile but fail at runtime. This is the fingerprint of an assistant guessing at schema. The TypeScript compiler is happy; the database returns "no such column"; you discover it in CI or, worse, in production. A single schema query before the assistant writes the query would have caught this.

Models that drift. If your User model already has a phone_number field and the assistant adds a phone field next to it, you now have two columns serving the same purpose. The schema view makes existing fields visible before the assistant proposes new ones.

Migration conflicts. When the assistant writes a new migration without seeing the migration history, it can produce migrations that conflict with what's already there — duplicate table definitions, columns that already exist, constraints that double up. The schema view, including the warning system for tables defined in multiple files, catches this category.

What it does not solve

Migration order. The schema view tells you the current state of tables. It does not run your migrations or simulate them. If you have a migration ordering bug, cix will reflect the resulting schema but won't tell you the order is wrong.

Custom column types and database extensions. Postgres-specific types like tsvector, JSONB schemas embedded in text columns, custom domains — these are surfaced as best-effort. Don't expect cix to understand the semantic shape of your full-text search column.

Application-level invariants. A field called user_id is a foreign key in your domain model, but if the migration didn't declare it as one, cix sees it as an integer column. The system reports what the migrations say, not what the domain says.

These are honest limits, not bugs. Schema parsing is one of those areas where 90% coverage is genuinely useful and 100% coverage is impossible without running every migration in every environment.

What it looks like in practice

Picture an assistant adding a new endpoint that filters users by signup date. Without schema awareness, it writes:

User.query.filter(User.created_at > start_date)

The query works in three of your four projects, because three of them happen to use created_at. The fourth uses signup_date. The query fails. You debug for fifteen minutes.

With schema awareness, the assistant queries the schema first, sees the actual column name, and writes the query correctly the first time. The category of "compile-time correct, runtime broken" assistant errors largely disappears.

What about partial coverage?

If cix can only parse 70% of your migrations, what happens to the remaining 30%?

Two things:

The schema view explicitly reports what was not parsed, including parse errors with file and line. You see the gap, not a silently incomplete answer.
Where ORM models exist, cix can sometimes fill in the gap from the model definition itself, with a confidence note about the source.

The system is designed to surface the boundary of what it knows, so the assistant doesn't operate as if the gap weren't there.

Impact analysis — when a column changes, this tells you what depends on it.
Find before you build — same idea applied to functions and components.
Limitations — where schema awareness falls short, in our own words.