What problem does it solve? Database migrations in the Operately codebase fail when developers hand-create migration files with colliding timestamp versions or when data migrations reference live application schemas that change over time, causing broken fresh installs and production errors like duplicate_column failures. ## Core Features & Use Cases - Schema migration generation: Mandates creating migration files via make gen.migration NAME=... so Ecto receives unique timestamp versions instead of hand-written filenames that collide across PRs. - Data migration pattern: Directs backfills into Operately.Data.ChangeNNN* modules under app/lib/operately/data/, invoked from thin schema migrations whose up/0 only delegates to ChangeNNN.run(). - Inline schema isolation: Requires data migrations to define minimal inline structs instead of aliasing live modules like Operately.Goals.Goal, preventing breakage on fresh installs months later. - Use Case: When adding a column that needs existing rows backfilled, generate the schema migration with make gen.migration, create the next-numbered change_NNN_*.ex module with an idempotent run/0, and add a matching test under app/test/operately/data/. ## Quick Start Ask the agent to create an Ecto migration that adds a new column and backfills existing rows following the Operately migration rules.