v1.2.3 — CSS editability guard

Keep agent-written CSS editable in Bricks

The whole point of Bricks is a visual builder, so CSS the assistant writes should stay editable in Bricks — not vanish into a private bundle you can't reach. This release adds a guard that keeps editable layout/responsive/visual CSS in Bricks-native channels.

Added

• CSS editability guard. bricks_update_page_assets now classifies the css field and warns when it carries human-editable rules (layout/responsive/visual) instead of infrastructure CSS. The bundle behind that field (_bab_page_assets) is injected at wp_head priority 9997 — before element CSS — and has no Bricks editing UI, so it silently overrides what the builder shows.
  • Plugin: BAB_GUARD_EDITABLE_CSS in wp-config.php — off (default) / warn (response warnings[]) / block (HTTP 422, nothing written). Covers non-MCP callers too.
  • MCP: warns by default; BRICKS_MCP_BLOCK_EDITABLE_CSS=1 to hard-block.
  • Reserve the css field for infra (@font-face, :root{--vars}, @keyframes, critical CSS); editable CSS belongs in element _cssCustom, page customCss, or global classes.

Changed

• Build global classes with native settings, not _cssCustom (the latter isn't compiled into page CSS via the API path). Tool descriptions + server preamble steer accordingly.

See the README section "Keeping your CSS editable in Bricks" and the CHANGELOG.

Plugin install/update: download bricks-api-bridge.zip below (or via the README's latest-download link).