The migration mental model, the command flow, and the difference between rollout and runtime.

Migrations

comon_orm supports two different schema workflows:

If the database matters, use migrations.

Choose the right path

Situation	Recommended path
Shared PostgreSQL database	Reviewed CLI migrations
Shared SQLite database	Reviewed CLI migrations
Flutter local cache you can rebuild	Reset or bootstrap instead of versioned migrations
Flutter local SQLite with important offline data	Explicit app-side `SqliteFlutterMigrator` upgrades with Dart-coded schema builder
Browser app talking to a backend	Backend owns migrations

runtime adapters should open from generated metadata
migrate dev is the normal local command for creating and applying the next migration
migrate deploy applies reviewed local migrations to shared environments
migrate status is the first command to run when local files and the database may have diverged
db push updates a database without creating migration history
rollback exists, but production usually wants a forward fix rather than a blind revert

If the database is shared or long-lived, use the CLI workflow.
If the database is device-local and disposable, prefer reset over maintaining migration code.
If the database is device-local and contains important user data, upgrade it explicitly before runtime startup.
Do not mix migration planning into normal app runtime openers.