nxtgauge-backend-rust/crates/db/migrations/20260318235959_customer_profiles_status_early.down.sql

-- No-op: 20260721020000_customer_profiles_status.down.sql already owns
-- dropping this column. Reverting it here too would break that migration's
-- own down.sql if both are ever rolled back in the same pass.
fix(db): 4 fresh-bootstrap migration chain bugs found + verified today Reconciling the local dev DB (63 migrations behind) surfaced 4 genuine bugs in the migration chain itself -- not just this DB's legacy scripts/init-db.sql seeding -- confirmed by replaying the full chain against a brand new, completely empty database from scratch: - 20260318235959: customer_profiles.status is UPDATEd by 20260319090000's backfill 4 months before it's ever ADDed (20260721020000). Adds it early (IF NOT EXISTS). - 20260401235959: 20260317190000 creates the old users-linked `employees` shape; 20260402030000's CREATE TABLE IF NOT EXISTS no-ops against it and fails creating an index on a column that was never added. Conditionally drops the old shape first (only if it's still pre-transition -- gated on the missing `email` column), restoring 20260402030000's own documented original intent. - 20260419235959: the schema `20260420000003_external_role_modules` needs (persona_types, modules, role_module_access, ...) was only ever defined in a disabled .up.sql.skip (its version slot was taken by ...seed.sql); the seed data that depends on it was never skipped. Creates that schema early -- verbatim content, purely additive. - 20260421235959: same disabled-migration pattern for the role_permissions -> role_admin_permissions / dashboard_configs -> role_sidebar_configs / runtime_configs -> role_runtime_configs / user_roles -> user_role_assignments renames that 20260422000000's widget seed needs. Conditionally renames each pair (only if old name exists and new name doesn't), verified against live Rust code that already queries the new names exclusively. payments/invoices were NOT chain bugs -- confirmed clean on the fresh bootstrap test -- so no fix needed for those; they only conflicted on this one DB because of its scripts/init-db.sql legacy seed, which is already a documented, known gap. Verified twice: applied cleanly as no-ops against the now-fully-migrated local dev DB, and applied successfully end-to-end (0 manual steps) against a brand new empty database created from scratch. Runbook updated with the full pending-migration list and today's findings. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> 2026-08-14 18:30:42 +05:30			`-- No-op: 20260721020000_customer_profiles_status.down.sql already owns`
			`-- dropping this column. Reverting it here too would break that migration's`
			`-- own down.sql if both are ever rolled back in the same pass.`