Your project starts with the database schema and no migration files.

Drizzle replays one ordered journal. A migration shipped by NuxtStart and the first migration your project generates would claim the same position in that history, and each would describe a schema the other database never had. NuxtStart keeps its migration history through the ordinary development → staging → main promotion, then publishes a downstream-ready tree without that history.

flowchart LR
    D["development<br/>keeps migrations"] --> S["staging<br/>keeps migrations"]
    S --> M["main: production branch<br/>keeps migrations"]
    M --> P["published<br/>transformed, no migration files"]

What this means for your project

Generate your first migration from the schema you received, commit it, and own the lineage from there. Database has the commands.

Hotfixes belong on staging

Reproduce the fault on staging, fix it there, and verify against the staging deployment before promoting it. Then reconcile the fix into development, or the next promotion reverts it.

Publishing, in NuxtStart only

The publisher transforms main into the long-lived published branch. It removes apps/web/server/db/migrations and other NuxtStart-only material, and withholds NuxtStart-specific configuration. scripts/publish/transforms.ts is the complete list of transformations.

published is downstream-only. Generated Projects adopt updates from nuxtstart/published into their development branch, then promote the result normally. Never merge published back into development, staging, or main; an ordinary merge would reintroduce material the publication intentionally removed.