feat(editor): user-saved layouts — save any subtree, re-insert it exactly

[DavidBabinec]

What

Layouts in the module inserter, three groups: the user's saved layouts, per-plugin groups (labelled with the plugin's display name), and the seeded built-in presets. Users create layouts by right-clicking any layer (DOM panel or canvas) → Save as layout…, which snapshots the element + its whole subtree (props, breakpoint overrides, every referenced style rule) for exact re-insertion. Plugins ship layouts in packs, authored as clean HTML.

How

One snapshot engine, two front doors. Capture/restore was extracted from the clipboard slice into @site/store/subtreeSnapshot, and both paste and layout insertion run through it — a saved layout inserts exactly like pasting the original selection: fresh node ids, scoped classes cloned with remapped scope.nodeId, framework classes re-matched by name, regular classes reused-or-reimported.

Persistence. A fourth locked system table layouts (kind layout) joins posts/pages/components. Saved layouts load onto SiteDocument.layouts and save through the same incremental roster protocol as pages/components (PUT /admin/api/cms/layouts, per-layout dirty tracking from Mutative patches). Strict write validation enforces unique ids/names against the merged post-save roster; the tolerant load path drops corrupt rows and sanitizes richtext props.

Migration — in-place upgrade, no DB re-creation. Seeded by a new 017_layouts_system_table migration (001 baseline untouched). PG swaps the data_tables kind CHECK and seeds; SQLite rebuilds data_tables with the widened CHECK. Because data_rows.table_id is ON DELETE RESTRICT (fires immediately even under defer_foreign_keys, and SQLite ≥3.25 renames always rewrite child FK clauses), the migration runner gains Migration.disableForeignKeys — it toggles PRAGMA foreign_keys around that one migration and verifies foreign_key_check before re-enabling enforcement.

Editor.

• layoutsSlice: saveNodeAsLayout / insertLayout / renameLayout / deleteLayout — all undoable site mutations.
• "Save as layout…" sits next to Componentize in the layer context menu (page mode; disabled with an inline reason on the page root). Naming via LayoutNameDialog with inline duplicate-name errors.
• Inserter items get wireFromTree previews and inline disabled reasons: snapshots carrying a base.outlet follow the outlet module's placement rules; in VC mode, snapshots whose component refs would create a dependency cycle are disabled. Refs to since-deleted VCs are stripped at insertion.
• The Layouts section is composed by composeLayoutsSection: Saved → per-plugin groups (display names from a new pluginRuntime name registry fed by the editor plugin loader) → Built-in. Labels render only when more than one group is present.
• Right-click a saved layout → Rename… / Delete (undoable, toast-confirmed). Layouts can be favorited into the canvas notch.

Plugin packs — HTML-authored layouts. definePack({ layouts: [{ id, name, html, css? }] }): authors write the markup they already have. compilePackLayout runs the host's HTML-import pipeline at plugin build time (instatic-plugin build installs a happy-dom window + the base module registry first): <style> blocks harvested, scripts stripped, elements mapped to base.* modules, CSS parsed into style rules with deterministic ids (<layoutId>/<className>) so re-inserting after a pack update reuses the site's class instead of importing a duplicate. Multi-root markup is wrapped in a container. The wire format (pack/site.json) carries compiled SavedLayout objects, so the host install path needs no DOM. Ids must be <pluginId>/-namespaced (validated at install) — re-syncs replace the plugin's own rows and never collide with user layouts; the prefix is also what the inserter groups on. Install summary, toast counts, and audit metadata report layouts; same visualComponents.register gate as the rest of the pack.

Module-size ceiling splits (700-line gate): uiSlice's save-dirty accumulator → saveTrackingSlice; the manage menu → SavedLayoutManageMenu; layout validation → persistence/validateLayouts with shared helpers in validationShared.

Integration hardening (post-implementation audit): import's SYSTEM_TABLE_IDS and the plugin cms.content.tables.create reserved-slug guard both know about layouts; export/import carries layout rows (round-trip-tested); the system-flag architecture gate checks all four tables.

Notes

• Built-in layout presets are untouched (LAYOUT_PRESETS, still HTML-only; CSS for built-ins is a later task as discussed).
• Pack layout CSS should stick to plain class/element rules — @media blocks compile to conditions the snapshot format doesn't carry yet.
• Docs updated: CLAUDE.md, docs/architecture.md, docs/editor.md ("Saved layouts" section incl. plugin grouping), docs/features/content-storage.md, docs/features/content-workspace.md, docs/features/plugin-system.md (pack layouts + ID rules), docs/reference/database-dialects.md (RESTRICT-parent rebuild pattern).

Testing

• New: layoutsSlice.test.ts (save/insert round-trip, scoped-class remap, outlet guard, dangling-VC-ref healing, rename/delete), layoutsWriteValidation.test.ts, schemas.test.ts, layoutFromRow.test.ts, pack layout cases in pluginPack.test.ts (namespacing, malformed/incoherent rejection, replace-by-id), HTML compile cases in builders.test.ts (class linking, <style> harvesting, multi-root wrap, deterministic ids, empty-HTML rejection), composeLayoutsSection ordering/label tests.
• Existing suites updated for the fourth collection (cmsAdapter wire shapes, dirty tracking, fetch mocks, system-table flags, import/export round-trip).
• bun test (5284 pass), bun run build, bun run lint all green.

🤖 Generated with Claude Code