# Catalogue-schema migrations

Migrations for the SHARED master catalogue schema (`master_projects` — the
`catalogue` connection). See `docs/planning/master-catalogue-shared-database-plan.md`.

Rules:

- A change to any catalogue-family table (`catalog_*` on the catalogue
  connection, `developers`, `developer_relationships`, the `market_*` reference
  family, master `media`, master `countries`/`data_providers`) lives HERE,
  never in `database/migrations/`. Since 2026-09-25 that includes
  `catalog_floor_plan_rent_bases`, `catalog_floor_plan_key_sizes`,
  `layout_analyses`, `catalog_vr_bakes`, `media_cleanup_tasks` and the seven
  `propertylab_*` reference tables — plus `catalog_vr_tours` (2026-09-26) (see
  docs/modules_handbook/shared/project-catalogue/site-data-on-master.md).
- A migration that MOVES existing site rows up to the master calls
  `App\Actions\Catalogue\MoveSiteDataToCatalogue::fromMigration()`, which
  copies only when the run targets a database other than the site's.
- Each migration is applied to **both** connections — the master schema and
  every site's local catalogue tables (sites keep the same shape for their own
  local projects). The deploy runs:

      php artisan migrate --path=database/migrations/catalogue --database=catalogue
      php artisan migrate --path=database/migrations/catalogue

  One file, two targets, no drift.
- Only the Hub's deploy pipeline may run the `--database=catalogue` line
  against production. A site deploy must never ALTER the master.
- The master schema's BASELINE is the seeded copy of the prod catalogue —
  there is deliberately no create-from-scratch history here.