layouts

The Layouts submodule owns `cms_layout` and its child table `cms_layout_region`. A layout has a `type` (vertical, horizontal, grid, blog_post, custom), an optional `schema` and `default_config` (both free-form JSON), an `is_active` flag, and a locale-translated name/description stored in a companion `cms_layout_locale` table. Regions belong to exactly one layout via `layout_id`, carry a `code` that must be unique within that layout (e.g. "header", "main", "sidebar"), an `order`, an optional `config` JSON blob, and their own locale-translated name/description in `cms_layout_region_locale`. A page's `layout_slug` is resolved to `layout_id` at page create/update time by the Pages submodule, and every component instance placed on a page must reference one of that page's own layout's region codes — the region/layout relationship is what the Pages submodule's `saveComponents` validates against.

Create and update on both layouts and regions follow the same two-step pattern used across the CMS module: the base row is written first, then each entry in the `locale` map is upserted — updated if a `cms_layout_locale`/`cms_layout_region_locale` row already exists for that locale, created otherwise — so submitting a translation for only one locale never touches the others. Neither layouts nor regions are soft-deleted: `DELETE /cms/layouts/:id` and `DELETE /cms/layouts/:id/regions/:regionId` issue a hard Prisma `.delete()`. Region deletes are additionally scoped to their parent layout (`layout_id` must match `:id` in the path), so a region ID belonging to a different layout returns 404 rather than deleting cross-layout.

There is no explicit guard in `CmsLayoutService` against deleting a layout that pages still reference — the protection comes entirely from the database: `cms_page.layout_id` is declared `onDelete: RESTRICT` in the table YAML, so attempting to delete an in-use layout surfaces as a raw foreign-key constraint failure rather than a friendly application-level error. The response shape also includes a `pages_count` field intended to show how many pages use a layout, but the underlying Prisma queries in `list()` and `getById()` do not request a `_count` relation — `mapLayout()` reads `layout._count?.cms_page ?? 0`, which is always `undefined` in practice, so `pages_count` currently reports `0` for every layout regardless of actual usage.

Unlike Pages, where `cms-editor` can create and update content, every write endpoint in this submodule (layouts and regions alike) is restricted to `admin`/`admin-cms` only — content editors can read layouts to pick one for a page but cannot define or modify layouts or their regions themselves.