@velora-cms/server 0.11.0

package/dist/config/trust-proxy.js

@@ -0,0 +1,42 @@
+// VELORA_TRUST_PROXY (S160 final-fix round, finding 1) — threads into
+// Fastify's own `trustProxy` constructor option, which governs how
+// `request.ip` (and X-Forwarded-For) are resolved. Without it, Fastify
+// trusts nothing and `request.ip` is always the socket's remote address —
+// which is the load balancer / reverse proxy's own address whenever one
+// sits in front of the process, collapsing every real visitor onto one
+// value. Three S160 controls hang directly on request.ip: the platform's
+// anonymous-IP rate lane (rate-limit.ts's `ip:` bucket), the forms plugin's
+// per-IP token bucket (rate-bucket.ts / forms-api.ts), and the ip_hash
+// column stored on every submission — all three are only genuinely
+// per-visitor once the operator both runs behind a real, trusted proxy AND
+// tells Fastify so here. See the .env.example block for the danger in the
+// OTHER direction (setting this when NOT actually behind a trusted proxy).
+//
+// Default MUST remain today's behaviour: unset/empty means `undefined`, and
+// app.ts omits the `trustProxy` constructor option entirely rather than
+// passing it explicitly — nothing changes for an existing deployment that
+// never set this var.
+//
+// Accepted forms, mirroring what Fastify's own trustProxy already knows how
+// to interpret once it receives a boolean/number/string:
+//   - unset / empty (after trim) -> undefined
+//   - "true" / "false" (case-insensitive) -> boolean
+//   - a bare non-negative integer (e.g. "1") -> number, a hop count
+//   - anything else -> the trimmed string, passed straight through
+//     (Fastify itself parses "loopback" and a comma-separated IP/CIDR list)
+export function parseTrustProxy(raw) {
+    const value = raw?.trim();
+    if (!value)
+        return undefined;
+    const lower = value.toLowerCase();
+    if (lower === "true")
+        return true;
+    if (lower === "false")
+        return false;
+    if (/^\d+$/.test(value))
+        return Number(value);
+    return value;
+}
+export function trustProxyFromEnv(env = process.env) {
+    return parseTrustProxy(env.VELORA_TRUST_PROXY);
+}

package/dist/data-types/validate-data-type-settings.d.ts

@@ -0,0 +1 @@
+export declare function validateDataTypeSettings(editorId: string, settings: Record<string, unknown>): string[];

package/dist/data-types/validate-data-type-settings.js

@@ -0,0 +1,33 @@
+import { Ajv } from "ajv";
+import { BUILT_IN_SETTINGS_SCHEMAS } from "@velora-cms/plugin-sdk/datatypes";
+// Server-side half of the settingsSchema pipeline (Session 69). Only
+// covers BUILT-IN editors — Module Federation remotes (third-party/
+// marketplace plugins) only ever load in the browser (Session 66), so the
+// server has no way to see a remote plugin's settingsSchema. For any
+// editorId not in BUILT_IN_SETTINGS_SCHEMAS, validation is skipped (not
+// rejected) — a deliberate, documented boundary, not a gap.
+const ajv = new Ajv({ allErrors: true });
+const compiledValidators = new Map();
+function getValidator(editorId) {
+    if (compiledValidators.has(editorId)) {
+        return compiledValidators.get(editorId);
+    }
+    const schema = BUILT_IN_SETTINGS_SCHEMAS[editorId];
+    if (!schema)
+        return undefined;
+    const validator = ajv.compile(schema);
+    compiledValidators.set(editorId, validator);
+    return validator;
+}
+// Returns a list of human-readable error messages — empty means valid
+// (including "editorId has no known schema", which is intentionally not
+// an error).
+export function validateDataTypeSettings(editorId, settings) {
+    const validator = getValidator(editorId);
+    if (!validator)
+        return [];
+    const valid = validator(settings);
+    if (valid)
+        return [];
+    return (validator.errors ?? []).map((error) => `${error.instancePath || "settings"} ${error.message}`.trim());
+}

package/dist/db/content-db.d.ts

@@ -0,0 +1,16 @@
+import { ContentService } from "@velora-cms/content-service";
+import { type ConnectionConfig, type DatabaseAdapter, type Migration } from "@velora-cms/db-adapter";
+export interface ResolvedContentDatabase {
+    dialect: "postgresql" | "mysql" | "sqlite";
+    connection: ConnectionConfig;
+    migrations: Migration[];
+}
+export declare function dialectFromUrlScheme(url: string): ResolvedContentDatabase["dialect"] | undefined;
+export declare function resolveContentDatabase(url: string): ResolvedContentDatabase;
+export interface ContentDb {
+    adapter: DatabaseAdapter;
+    contentService: ContentService;
+    dialect: ResolvedContentDatabase["dialect"];
+}
+export declare function connectContentDb(): Promise<ContentDb>;
+export declare function connectContentDbAt(url: string): Promise<ContentDb>;

package/dist/db/content-db.js

@@ -0,0 +1,109 @@
+import { ContentService } from "@velora-cms/content-service";
+import { applyMigrations, MySQLAdapter, PostgreSQLAdapter, SQLiteAdapter, mysqlContentCurrentVersionMigration, mysqlContentFieldValuesMigration, mysqlContentSchemaMigration, mysqlContentTrashMigration, mysqlContentVersionsMigration, mysqlDataTypesMigration, mysqlDocumentTypeTabsAndTemplatesMigration, mysqlDropVersionPublishedAtMigration, mysqlSearchTrigramIndexesMigration, mysqlSnapshotsMigration, postgresqlContentCurrentVersionMigration, postgresqlContentFieldValuesMigration, postgresqlContentSchemaMigration, postgresqlContentTrashMigration, postgresqlContentVersionsMigration, postgresqlDataTypesMigration, postgresqlDocumentTypeTabsAndTemplatesMigration, postgresqlDropVersionPublishedAtMigration, postgresqlSearchTrigramIndexesMigration, postgresqlSnapshotsMigration, sqliteContentCurrentVersionMigration, sqliteContentFieldValuesMigration, sqliteContentSchemaMigration, sqliteContentTrashMigration, sqliteContentVersionsMigration, sqliteDataTypesMigration, sqliteDocumentTypeTabsAndTemplatesMigration, sqliteDropVersionPublishedAtMigration, sqliteSearchTrigramIndexesMigration, sqliteSnapshotsMigration, } from "@velora-cms/db-adapter";
+// Dialect is derived from the connection string's scheme (Session 78) —
+// the first real consumer of multi-dialect support outside the
+// conformance suite, and a down-payment on the v1.x setup wizard.
+// Order matters in every list: 0001 → 0010.
+const MIGRATIONS = {
+    postgresql: [
+        postgresqlContentSchemaMigration,
+        postgresqlContentVersionsMigration,
+        postgresqlContentCurrentVersionMigration,
+        postgresqlSnapshotsMigration,
+        postgresqlDocumentTypeTabsAndTemplatesMigration,
+        postgresqlDataTypesMigration,
+        postgresqlContentFieldValuesMigration,
+        postgresqlSearchTrigramIndexesMigration,
+        postgresqlContentTrashMigration,
+        postgresqlDropVersionPublishedAtMigration,
+    ],
+    mysql: [
+        mysqlContentSchemaMigration,
+        mysqlContentVersionsMigration,
+        mysqlContentCurrentVersionMigration,
+        mysqlSnapshotsMigration,
+        mysqlDocumentTypeTabsAndTemplatesMigration,
+        mysqlDataTypesMigration,
+        mysqlContentFieldValuesMigration,
+        mysqlSearchTrigramIndexesMigration,
+        mysqlContentTrashMigration,
+        mysqlDropVersionPublishedAtMigration,
+    ],
+    sqlite: [
+        sqliteContentSchemaMigration,
+        sqliteContentVersionsMigration,
+        sqliteContentCurrentVersionMigration,
+        sqliteSnapshotsMigration,
+        sqliteDocumentTypeTabsAndTemplatesMigration,
+        sqliteDataTypesMigration,
+        sqliteContentFieldValuesMigration,
+        sqliteSearchTrigramIndexesMigration,
+        sqliteContentTrashMigration,
+        sqliteDropVersionPublishedAtMigration,
+    ],
+};
+// Scheme → dialect, shared with prisma.ts's resolvePrismaDialect (Session
+// 131 fix). Both need the same URL-scheme rules; they diverge on what
+// happens when nothing matches. There's no such thing as an unconnectable
+// content database, so resolveContentDatabase below throws. Prisma dialect
+// resolution is diagnostic only (it shapes a query, it doesn't open a
+// connection) and must never crash boot over it, so it falls back to a
+// default with a warning instead of throwing — see prisma.ts.
+export function dialectFromUrlScheme(url) {
+    if (url.startsWith("postgres://") || url.startsWith("postgresql://"))
+        return "postgresql";
+    if (url.startsWith("mysql://"))
+        return "mysql";
+    if (url.startsWith("file:"))
+        return "sqlite";
+    return undefined;
+}
+export function resolveContentDatabase(url) {
+    const dialect = dialectFromUrlScheme(url);
+    switch (dialect) {
+        case "postgresql":
+            return { dialect, connection: { connectionString: url }, migrations: MIGRATIONS.postgresql };
+        case "mysql":
+            return { dialect, connection: { connectionString: url }, migrations: MIGRATIONS.mysql };
+        case "sqlite":
+            return { dialect, connection: { filename: url.slice("file:".length) }, migrations: MIGRATIONS.sqlite };
+        default:
+            throw new Error(`Unsupported content database URL "${url}" — use postgres://…, mysql://…, or file:<path> (sqlite).`);
+    }
+}
+function createAdapter(dialect) {
+    switch (dialect) {
+        case "postgresql":
+            return new PostgreSQLAdapter();
+        case "mysql":
+            return new MySQLAdapter();
+        case "sqlite":
+            return new SQLiteAdapter();
+    }
+}
+// Connects the adapter and brings the content tables up to date. Content
+// tables are adapter-managed and tracked in velora_migrations; Prisma's
+// tables stay in _prisma_migrations — the two never overlap (Two-Tier
+// ORM Strategy). VELORA_CONTENT_DATABASE_URL exists because the sandbox
+// splits the tiers (Prisma on SQLite, content on the selected dialect);
+// normal dev sets only DATABASE_URL and behaves exactly as before.
+export async function connectContentDb() {
+    const url = process.env.VELORA_CONTENT_DATABASE_URL ?? process.env.DATABASE_URL;
+    if (!url) {
+        throw new Error("VELORA_CONTENT_DATABASE_URL or DATABASE_URL must be set — see .env.example");
+    }
+    return connectContentDbAt(url);
+}
+// The explicit-URL variant (Session 151): the setup wizard's starter
+// install needs a content-db connection for a database whose URL was
+// chosen IN the very request being handled — it isn't in process.env yet,
+// exactly the same reason loadPrismaClient grew its explicit datasourceUrl
+// parameter. connectContentDb() above delegates here, so both paths run
+// the identical resolve → connect → migrate sequence.
+export async function connectContentDbAt(url) {
+    const resolved = resolveContentDatabase(url);
+    const adapter = createAdapter(resolved.dialect);
+    await adapter.connect(resolved.connection);
+    await applyMigrations(adapter, resolved.migrations);
+    return { adapter, contentService: new ContentService(adapter), dialect: resolved.dialect };
+}

package/dist/db/core-migrations/index.d.ts

@@ -0,0 +1,14 @@
+import { type Migration } from "@velora-cms/db-adapter";
+import { type CoreMigrationDialect } from "./steps.js";
+export type CoreMigrationOutcome = "recorded-all" | "baselined" | "applied" | "skipped-empty";
+type CoreDialect = CoreMigrationDialect;
+export declare function applyCoreMigrations(opts: {
+    dialect: CoreDialect;
+    databaseUrl: string;
+    mode: "fresh-push" | "boot";
+    stepsOverride?: Migration[];
+}): Promise<{
+    outcome: CoreMigrationOutcome;
+    executedIds: string[];
+}>;
+export {};

package/dist/db/core-migrations/index.js

@@ -0,0 +1,184 @@
+import { applyMigrations, MySQLAdapter, PostgreSQLAdapter, SQLiteAdapter, } from "@velora-cms/db-adapter";
+import { resolveContentDatabase } from "../content-db.js";
+import { buildCoreMigrations } from "./steps.js";
+// Separate from velora_migrations (the content-adapter ledger, tracked by
+// content-db.ts's applyMigrations call): this ledger tracks the
+// Prisma-owned schema's upgrade history, which content-db.ts never
+// touches — Two-Tier ORM Strategy, two ledgers, never shared rows.
+const LEDGER = "velora_core_migrations";
+function createAdapterForDialect(dialect) {
+    switch (dialect) {
+        case "postgresql":
+            return new PostgreSQLAdapter();
+        case "mysql":
+            return new MySQLAdapter();
+        case "sqlite":
+            return new SQLiteAdapter();
+    }
+}
+// Boot-time ledger for the Prisma-owned schema (S185). Three starting
+// shapes it must tell apart:
+//   - "fresh-push": setup just ran `prisma db push` and created the
+//     CURRENT schema from scratch — every step is already reflected, so
+//     record every id without running any SQL.
+//   - "boot" against a database with a complete ledger: normal restart,
+//     apply anything newer than what's recorded.
+//   - "boot" against a pre-ledger database (the 0.10-era self-hosted /
+//     demo-box case, `users` table present but no velora_core_migrations
+//     table yet): baseline first (record 0001 without executing — 0001
+//     marks "the 0.10.0-release db-push shape"; every schema change that
+//     shipped after that release, such as S182's api_keys.scope, is its
+//     own numbered step and is NEVER folded into the baseline) — then
+//     apply anything newer for real, which is exactly how a pre-S182
+//     database picks up 0002's ALTER TABLE.
+//   - "boot" against a genuinely empty database (no `users` table): there
+//     is nothing to baseline or migrate — the setup wizard hasn't run
+//     yet. Skip entirely and create no ledger table, so a later
+//     fresh-push still sees an untouched database.
+export async function applyCoreMigrations(opts) {
+    const steps = opts.stepsOverride ?? buildCoreMigrations(opts.dialect);
+    // Same resolve→connect sequence content-db.ts uses to build an adapter
+    // from a URL — the content-migrations list on the result is ignored
+    // here, this ledger tracks the Prisma-owned schema, not the
+    // content-adapter tables.
+    const resolved = resolveContentDatabase(opts.databaseUrl);
+    if (resolved.dialect !== opts.dialect) {
+        throw new Error(`applyCoreMigrations: dialect "${opts.dialect}" does not match the database URL (which is ${resolved.dialect})`);
+    }
+    const adapter = createAdapterForDialect(resolved.dialect);
+    await adapter.connect(resolved.connection);
+    try {
+        if (opts.mode === "fresh-push") {
+            await recordWithoutExecuting(adapter, steps);
+            return { outcome: "recorded-all", executedIds: [] };
+        }
+        // A ledger table that exists but holds ZERO rows is treated as no
+        // ledger at all: ensureLedgerTable's CREATE TABLE autocommits on every
+        // dialect, so a crash between table creation and the (transactional)
+        // recording commit leaves exactly this shape behind. Reading it as
+        // "already baselined" would make the applied branch run every up()
+        // against a schema db push created in full — the empty table must fall
+        // back to the baseline path, which is idempotent and safe to re-run.
+        const hasLedger = (await tableExists(adapter, LEDGER)) &&
+            (await adapter.query({ sql: `SELECT id FROM ${LEDGER}` })).length > 0;
+        if (!hasLedger) {
+            const hasUsers = await tableExists(adapter, "users");
+            if (!hasUsers)
+                return { outcome: "skipped-empty", executedIds: [] };
+            // 0.10-era db-push database: baseline, then apply anything newer.
+            await recordWithoutExecuting(adapter, steps.slice(0, 1));
+            const executed = await applyTracked(adapter, steps);
+            return { outcome: "baselined", executedIds: executed };
+        }
+        const executed = await applyTracked(adapter, steps);
+        return { outcome: "applied", executedIds: executed };
+    }
+    finally {
+        await adapter.disconnect();
+    }
+}
+// Same CREATE TABLE IF NOT EXISTS + mysql VARCHAR id-column rule as
+// migration-runner.ts's velora_migrations bootstrap: MySQL's InnoDB can't
+// index a bare TEXT/BLOB column without an explicit key length, and
+// migration ids here are short slugs like "0001_core_baseline", never
+// real UUIDs, so a short VARCHAR is the right fit.
+//
+// Width note (S185 fix-wave 2): both columns are VARCHAR(191) on mysql,
+// not TEXT. schema.prisma's CoreMigration model (`id String @id` and
+// `appliedAt String @map("applied_at")`, neither with a `@db.VarChar` —
+// that annotation is provider-specific and would break the other two
+// dialects' mapping) maps a plain `String` field to VARCHAR(191) on mysql
+// by Prisma's own default. This hand-written DDL is set to match that
+// default exactly, on both columns, so the two definitions of this table
+// — this runner's CREATE TABLE and schema.prisma's model — always AGREE.
+// Whether a given Prisma version would refuse a width mismatch outright or
+// silently alter the column underneath a `db push` is version-dependent
+// and not something this code relies on either way; matching the mapping
+// removes the question entirely rather than betting on Prisma's behavior
+// in either direction. Contrast migration-runner.ts's own VARCHAR(255) for
+// velora_migrations: that ledger is adapter-owned, never declared in
+// schema.prisma, and never seen by `db push` — it keeps 255 and is
+// intentionally left untouched here.
+async function ensureLedgerTable(adapter) {
+    const textColumn = adapter.dialect === "mysql" ? "VARCHAR(191)" : "TEXT";
+    await adapter.execute({
+        sql: `CREATE TABLE IF NOT EXISTS ${LEDGER} (id ${textColumn} PRIMARY KEY, applied_at ${textColumn} NOT NULL)`,
+    });
+}
+// Records ids as applied WITHOUT running their up() — used both for the
+// fresh-push shortcut (every step already reflected by db push) and for
+// baselining 0001 alone on a pre-ledger database.
+//
+// ensureLedgerTable stays OUTSIDE the transaction — mysql DDL autocommits,
+// so a CREATE TABLE inside a transaction block would just be committed
+// immediately anyway and can't be rolled back with the rest of the work.
+// The SELECT + per-row INSERT loop that follows IS wrapped in a
+// transaction: a crash partway through therefore leaves the ledger table
+// PRESENT but EMPTY (the CREATE TABLE autocommitted; the row inserts
+// rolled back). The boot path treats that empty table as "no ledger" and
+// re-runs the baseline path, which is idempotent — see the hasLedger
+// check in applyCoreMigrations. Without the wrapper, a crash mid-loop
+// would instead leave a present-but-INCOMPLETE ledger, which no check can
+// distinguish from a genuinely baselined database — next boot would then
+// apply() steps whose columns/tables db push already created.
+async function recordWithoutExecuting(adapter, steps) {
+    await ensureLedgerTable(adapter);
+    await adapter.transaction(async (tx) => {
+        const rows = await tx.query({ sql: `SELECT id FROM ${LEDGER}` });
+        const applied = new Set(rows.map((row) => row.id));
+        const placeholders = adapter.dialect === "postgresql" ? "($1, $2)" : "(?, ?)";
+        for (const step of steps) {
+            if (applied.has(step.id))
+                continue;
+            await tx.execute({
+                sql: `INSERT INTO ${LEDGER} (id, applied_at) VALUES ${placeholders}`,
+                params: [step.id, new Date().toISOString()],
+            });
+        }
+    });
+}
+// Runs applyMigrations against the core ledger and reports which ids were
+// newly executed (diffing the ledger's rows before/after), so callers can
+// distinguish "nothing to do" from "actually ran something."
+//
+// Load-bearing order: ensureLedgerTable runs BEFORE applyMigrations. Both
+// issue a `CREATE TABLE IF NOT EXISTS ${LEDGER}`, but with different column
+// widths (this module's VARCHAR(191) matching schema.prisma vs. the shared
+// runner's own VARCHAR(255)/TEXT default for velora_migrations-style
+// ledgers) — IF NOT EXISTS means only whichever CREATE TABLE runs first on
+// a truly fresh database actually defines the table, so ensureLedgerTable
+// must win that race, never applyMigrations' internal one.
+async function applyTracked(adapter, steps) {
+    await ensureLedgerTable(adapter);
+    const before = new Set((await adapter.query({ sql: `SELECT id FROM ${LEDGER}` })).map((row) => row.id));
+    await applyMigrations(adapter, steps, { ledgerTable: LEDGER });
+    const after = await adapter.query({ sql: `SELECT id FROM ${LEDGER}` });
+    return after.map((row) => row.id).filter((id) => !before.has(id));
+}
+async function tableExists(adapter, table) {
+    switch (adapter.dialect) {
+        case "sqlite": {
+            const rows = await adapter.query({
+                sql: "SELECT name FROM sqlite_master WHERE type = 'table' AND name = ?",
+                params: [table],
+            });
+            return rows.length > 0;
+        }
+        case "mysql": {
+            const rows = await adapter.query({
+                sql: "SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = ?",
+                params: [table],
+            });
+            return rows.length > 0;
+        }
+        case "postgresql": {
+            const rows = await adapter.query({
+                sql: "SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' AND table_name = $1",
+                params: [table],
+            });
+            return rows.length > 0;
+        }
+        default:
+            throw new Error(`applyCoreMigrations: unsupported dialect "${adapter.dialect}"`);
+    }
+}

package/dist/db/core-migrations/steps.d.ts

@@ -0,0 +1,4 @@
+import type { Migration } from "@velora-cms/db-adapter";
+export type CoreMigrationDialect = "postgresql" | "mysql" | "sqlite";
+export declare function buildCoreMigrations(dialect: CoreMigrationDialect): Migration[];
+export declare const CORE_MIGRATION_IDS: string[];

package/dist/db/core-migrations/steps.js

@@ -0,0 +1,66 @@
+// The Prisma-owned schema's upgrade ledger. 0001 is a pure baseline: it
+// marks "the 0.10.0-release db-push shape" and carries no SQL. Every schema
+// change that ships AFTER that release becomes its own numbered step here —
+// it must NEVER be folded back into the baseline, even if it lands before
+// the next version tags. 0002 is the first such case: S182 added
+// `api_keys.scope` after 0.10.0/0.10.1 had already shipped, so a pre-S182
+// source-checkout site baselines at 0001 with no scope column and needs
+// 0002 to repair it.
+// Every future step must exist for postgresql, mysql AND sqlite and
+// be additive-only — destructive statements are banned from this ledger.
+// The pinning test asserts CORE_MIGRATION_IDS; update it with every new
+// step (the ledger list and the test move together, always).
+const coreBaseline = {
+    id: "0001_core_baseline",
+    name: "core baseline (0.10.0-release db-push shape)",
+    up: async () => { },
+    down: async () => { },
+};
+// api_keys.scope (S182): `TEXT NOT NULL DEFAULT 'read'` on postgresql/
+// sqlite, `VARCHAR(191) NOT NULL DEFAULT 'read'` on mysql — matching
+// schema.prisma's `scope String @default("read")`, which Prisma maps to
+// VARCHAR(191) on mysql by its own default (no `@db.VarChar` override in
+// either schema.prisma or .prisma-variant-mysql.schema.prisma).
+//
+// up() must be idempotent: a post-S182 database (fresh db-push, or the
+// demo box after S182 shipped) already has the column, and this step must
+// run harmlessly against it too. Rather than branch on "has 0001 already
+// run without this column" (which the ledger can't tell apart from "db
+// push already included it"), probe directly — try a SELECT of the column
+// and only ALTER if that probe fails. The probe is dialect-free (the same
+// SELECT works identically against all three), so only the ALTER itself
+// needs the per-dialect branch below.
+function apiKeyScopeStep(dialect) {
+    return {
+        id: "0002_api_key_scope",
+        name: "api_keys.scope column (S182)",
+        up: async (tx) => {
+            try {
+                await tx.query({ sql: "SELECT scope FROM api_keys LIMIT 1" });
+                return; // column already present — nothing to do
+            }
+            catch {
+                // column missing — pre-S182 database, fall through and add it
+            }
+            const alter = dialect === "postgresql"
+                ? "ALTER TABLE api_keys ADD COLUMN IF NOT EXISTS scope TEXT NOT NULL DEFAULT 'read'"
+                : dialect === "mysql"
+                    ? "ALTER TABLE api_keys ADD COLUMN scope VARCHAR(191) NOT NULL DEFAULT 'read'"
+                    : "ALTER TABLE api_keys ADD COLUMN scope TEXT NOT NULL DEFAULT 'read'";
+            await tx.execute({ sql: alter });
+        },
+        // No-op, same as the baseline: additive steps never need to undo
+        // anything (house pattern — this ledger only ever moves forward).
+        down: async () => { },
+    };
+}
+// A factory, not a plain array: 0002's up() needs to know which dialect
+// it's running against (TransactionContext carries no dialect field, only
+// DatabaseAdapter does), so the registry is built per-dialect at the call
+// site instead of threading dialect through the shared Migration type.
+// CORE_MIGRATION_IDS below stays dialect-independent — ids never vary by
+// dialect — so it's fine to read off of any one dialect's build.
+export function buildCoreMigrations(dialect) {
+    return [coreBaseline, apiKeyScopeStep(dialect)];
+}
+export const CORE_MIGRATION_IDS = buildCoreMigrations("sqlite").map((m) => m.id);

package/dist/db/load-prisma-client.d.ts

@@ -0,0 +1,2 @@
+import type { PrismaClient } from "@prisma/client";
+export declare function loadPrismaClient(clientDir: string | undefined, datasourceUrl?: string): Promise<PrismaClient>;

package/dist/db/load-prisma-client.js

@@ -0,0 +1,44 @@
+import { pathToFileURL } from "node:url";
+import { join } from "node:path";
+// Shared by db/prisma.ts's own env-var-driven boot (no datasourceUrl —
+// Prisma reads DATABASE_URL from process.env the way its constructor
+// always has) and Session 97's setup-complete handler (an explicit
+// clientDir for a just-chosen dialect AND an explicit databaseUrl,
+// since the value it needs isn't in process.env yet at that point).
+export async function loadPrismaClient(clientDir, datasourceUrl) {
+    const options = datasourceUrl ? { datasources: { db: { url: datasourceUrl } } } : undefined;
+    if (!clientDir) {
+        // Session 164 final review fix: this used to be a static top-level
+        // `import { PrismaClient } from "@prisma/client"`, the ONLY value
+        // import of that package under apps/server/src (every other reader
+        // imports just the type). `pnpm deploy --legacy --prod` does not copy
+        // Prisma's generated `.prisma/client` companion directory (a `pnpm
+        // deploy` limitation with Prisma's split-package generated-client
+        // layout — see generate-prisma-clients.ts's generateDefaultPrismaClient
+        // comment), so a static import of the value crashed a flattened deploy
+        // target at import time — before DATABASE_URL or boot-mode logic ever
+        // ran — with `SyntaxError: Named export 'PrismaClient' not found`.
+        // That crash happens outside index.ts's `try { mode = await
+        // resolveBootMode(...) }` (a rejected PROMISE, not a static-import
+        // failure), so the operator got a raw stack trace instead of the
+        // "Refusing to start:" message.
+        //
+        // This branch is the only place a bare `@prisma/client` construction
+        // ever runs: every production path resolves an explicit clientDir
+        // (db/resolve-client-dir.ts derives one from DATABASE_URL's scheme
+        // whenever it's set), so `!clientDir` is reachable only pre-setup,
+        // where resolveBootMode returns "setup-full" before ever calling
+        // countAdmins, and buildSetupOnlyApp() never touches Prisma at all.
+        // Deferring the import to here — a dynamic import, evaluated only if
+        // this branch actually runs — means the crashing static import no
+        // longer exists at all, on any path.
+        const { PrismaClient: DefaultPrismaClient } = await import("@prisma/client");
+        return new DefaultPrismaClient(options);
+    }
+    const mod = await import(pathToFileURL(join(clientDir, "index.js")).href);
+    const Ctor = (mod.PrismaClient ?? mod.default?.PrismaClient);
+    if (!Ctor) {
+        throw new Error(`${clientDir} has no PrismaClient export in index.js`);
+    }
+    return new Ctor(options);
+}

package/dist/db/prisma.d.ts

@@ -0,0 +1,3 @@
+import type { Dialect } from "@velora-cms/prisma-variants";
+export declare const prisma: import("@prisma/client").PrismaClient<import("@prisma/client").Prisma.PrismaClientOptions, never, import("@prisma/client/runtime/library").DefaultArgs>;
+export declare function resolvePrismaDialect(clientDir: string | undefined, databaseUrl: string | undefined): Dialect;

package/dist/db/prisma.js

@@ -0,0 +1,67 @@
+import { dialectFromUrlScheme } from "./content-db.js";
+import { loadPrismaClient } from "./load-prisma-client.js";
+import { resolveClientDir } from "./resolve-client-dir.js";
+// The sandbox (velora-dev, Session 78) runs Prisma's standard tables on
+// SQLite via a generated schema variant whose client is emitted into the
+// sandbox state dir. VELORA_PRISMA_CLIENT_DIR points at that generated
+// client; normal dev never sets it and gets @prisma/client untouched.
+export const prisma = await loadPrismaClient(resolveClientDir());
+// Which dialect `prisma` above is actually querying — needed by any query
+// that has to shape itself per-provider (e.g. media-service.ts's filename
+// search, Session 131).
+//
+// Session 131's first attempt read this straight off VELORA_PRISMA_CLIENT_DIR
+// (generate-prisma-clients.ts's clientDirFor() names each generated client's
+// directory after its own dialect, dist/prisma-clients/<dialect>) and threw
+// if the last path segment wasn't a recognized name. That crashed boot in
+// velora-dev: the sandbox always points VELORA_PRISMA_CLIENT_DIR at an
+// un-suffixed "<stateDir>/prisma-client" for every --db choice (see
+// packages/velora-dev/src/config.ts), so the throw fired on every sandbox
+// dialect, not just an unconfigured one.
+//
+// The dialect of the standard-table Prisma client is really a property of
+// the database it connects to, and DATABASE_URL's scheme is the trusted way
+// to derive that (content-db.ts's resolveContentDatabase does the same for
+// the content database, Session 78) — so that's the primary signal now.
+// Resolution order:
+//   1. VELORA_PRISMA_CLIENT_DIR, if its last path segment is one of the
+//      three recognized dialect names — the explicit multi-dialect
+//      dist/prisma-clients/<dialect> layout stays authoritative when it's
+//      actually in play, since that's a stronger signal than a URL scheme.
+//   2. Otherwise, DATABASE_URL's scheme (postgres/postgresql:// →
+//      postgresql, mysql:// → mysql, file: → sqlite) — this is what makes
+//      the sandbox's un-suffixed client dir resolve correctly per --db
+//      choice instead of crashing.
+//   3. If neither yields a dialect (no DATABASE_URL, unrecognized
+//      everything), fall back to "postgresql" — schema.prisma's own default
+//      `provider` (see packages/prisma-variants) — and log a warning naming
+//      both channels. Never throw: this only shapes a query, it doesn't
+//      open a connection, and a misconfiguration here must be loud in logs,
+//      not fatal to boot.
+//
+// Deliberately NOT computed eagerly at module load (unlike `prisma` above):
+// prisma-client-dir.test.ts points VELORA_PRISMA_CLIENT_DIR at an arbitrary
+// stub directory to exercise loadPrismaClient()'s dynamic import in
+// isolation, with no dialect-named directory in play at all — an eager
+// call here would warn at import time for that legitimate, unrelated use.
+// Callers that need the dialect (app.ts and the media integration test, wiring MediaService)
+// call this directly with both env vars.
+export function resolvePrismaDialect(clientDir, databaseUrl) {
+    if (clientDir) {
+        let normalized = clientDir.replaceAll("\\", "/");
+        while (normalized.endsWith("/"))
+            normalized = normalized.slice(0, -1);
+        const marker = normalized.split("/").pop();
+        if (marker === "postgresql" || marker === "mysql" || marker === "sqlite") {
+            return marker;
+        }
+    }
+    if (databaseUrl) {
+        const dialect = dialectFromUrlScheme(databaseUrl);
+        if (dialect)
+            return dialect;
+    }
+    console.warn(`resolvePrismaDialect: could not determine the Prisma dialect from VELORA_PRISMA_CLIENT_DIR=${clientDir ? `"${clientDir}"` : "(unset)"} or DATABASE_URL=${databaseUrl ? `"${databaseUrl}"` : "(unset)"} — defaulting to postgresql (schema.prisma's own default provider). Query shaping that depends on the ` +
+        "real dialect (e.g. media-service.ts's filename search) may be wrong; set one of those env vars to fix it.");
+    return "postgresql";
+}

package/dist/db/resolve-client-dir.d.ts

@@ -0,0 +1,2 @@
+export declare function hasGeneratedClientOnDisk(dir: string): boolean;
+export declare function resolveClientDir(env?: NodeJS.ProcessEnv, hasGeneratedClient?: (dir: string) => boolean): string | undefined;