The drizzle/ folder is unreachable and wrong, and CONTRIBUTING tells you to regenerate it

[Artmann]

What's wrong

Three artifacts claim to own the database schema, and the one nothing runs is now actively wrong.

• drizzle/0000_graceful_whizzer.sql creates exactly chats, messages, providers
• src/database/schema.ts declares chats, databases, messages, settings, worksheets
• src/database/tables.ts — the real DDL per CLAUDE.md — declares chats, messages, databases, queries, settings, spans, worksheets

grep -rn "providers" src/database/ returns nothing. The committed migration creates a table that exists nowhere in the codebase and omits five that do.

Quantified: the committed SQL covers 2 of the 7 live tables; invents providers (drizzle/0000_graceful_whizzer.sql:17-21) and a messages.createdAt column (:13); declares uuid where the real DDL is TEXT; and omits all 4 indexes and every DEFAULT clause. Last touched in 4000f73 (2025-11-25), against 13 later schema.ts commits.

Nothing runs it: grep -rn "migrator\|migrate(" across src/ returns zero hits; no package.json script and no workflow invokes drizzle-kit; src/database/index.ts:14-31 calls createTables + reconcileColumns only. drizzle-kit@^0.31.7 sits in devDependencies (package.json:113) serving nothing.

The documentation actively contradicts itself

CONTRIBUTING.md:97-103 reads, verbatim:

## Database Migrations — "Generate migrations after schema changes:" — ```bash npx drizzle-kit generate ```

CLAUDE.md says schema changes do not go through drizzle-kit generate and that nothing applies drizzle/ at runtime.

Two documents give opposite instructions about the same tool, and the one a new contributor reads first is the wrong one. Following it today regenerates a diff against a nine-month-stale snapshot — plausibly emitting DROP TABLE providers plus five CREATE TABLEs — and lands a convincing migration that nothing executes, while the author believes the schema is managed.

drizzle.config.ts:4 is also the only importer of src/database/path.ts from outside src/, and path.ts:12 carries a comment (// Not running in Electron (e.g., drizzle-kit CLI)) written specifically for that dead consumer.

Proposed change — and it must be split in two

Land unconditionally (the deletion half): delete drizzle.config.ts, drizzle/0000_graceful_whizzer.sql, drizzle/meta/_journal.json, drizzle/meta/0000_snapshot.json; remove package.json:113; refresh yarn.lock; and strike the npx drizzle-kit generate instruction from CONTRIBUTING.md. The artifact is unreachable and wrong under every possible end-state.

Blocked (the positive doc statement): writing into CONTRIBUTING.md that tables.ts is the DDL owner conflicts directly with the proposal to generate createTables' body from appTables, which would make schema.ts the owner and tables.ts a generated artifact. Landing this doc rewrite and then that change re-creates the exact defect this issue exists to remove — documentation that confidently describes the wrong owner.

Do not merge the two halves into one commit. Write the positive statement to match whichever ownership model wins.

Risks

Low at runtime. The one thing to check first is .fallowrc.json — its explicit entry points (:2-8) do not include drizzle.config.ts and ignoreDependencies (:9) does not list drizzle-kit, so Fallow currently tolerates both via default config globs. Do both edits in one commit or the Fallow job in ci.yml:10-28 may flip.

drizzle-orm (package.json:61) is a runtime dependency and must not be touched.

The path.ts:12 comment becomes wrong, but the try/catch must stay — node-environment vitest also has no Electron app.

Reversal costs ~13 lines if anyone ever wants drizzle-kit studio.

Validation

yarn typecheck, yarn lint, yarn test (reconcile-columns.test.ts and spans-table.test.ts are the real guards); then the full CI matrix with attention to the Fallow job, since dependency-graph tooling is the only thing that observes these files.

Then yarn package and launch once against a pre-existing squeal.sqlite3 to confirm initializeDatabase still reconciles.

---

Found in a codebase-wide simplification audit (F-S29-a). Confidence: high.