is not allowed in a text`) — move table-based layout out into `{"…

"}`. In explicit JSX markup, write `
` and `

`. Do not generate `img`, `iframe`, `script`, `style` without a separate live check; prefer an image via standalone `` or inside ``. Available attributes: `style`, `align`, `href`, `target`, `rel`, `model`, `data-rich-*`. Attributes inside rich-text markup must be plain strings or value-less markers only: `

`, spread attributes, and expressions are not allowed — the live backend returns the error `Attribute \`...\` on <...> must be a plain string`. Plain text (with no markup of its own) is automatically wrapped in `

…

`. The style of the text as a whole (font, size, color) is set via `style={{...}}` on `` — not to be confused with inline markup like `` inside it. ## Cards with aligned CTAs If you need cards in a row with buttons at the same height, do not assemble each card entirely within its own `Column` — column heights are independent, and the CTAs will drift. Assemble **synchronized rows** instead: separate `FlexRow`s (4+4+4 or 6+6) for images, headings, descriptions, and buttons — then all the CTAs sit in one row at the same top coordinate. The cost: on mobile stacking, the order becomes "all images → all headings → …" rather than card by card; if a card-by-card mobile order matters, that is a product decision (separate mobile rows via `visibilityOnDevices`) — discuss it with the user. Full example: `references/examples.md` §12. ## visibilityOnDevices and "blurred" blocks in the canvas Blocks hidden for the current device (`visibilityOnDevices="mobile"`/`"desktop"`) are shown by the Maestra canvas editor as **blurred — this is an editor visualization, not a defect in the email**: in the sent HTML, hiding works via media queries, and the PNG preview at desktop viewport shows only the desktop variant. Therefore: - do not remove device variants just to clean up the canvas — doing so silently sacrifices the mobile layout; - if the user is alarmed by "blurred cards" in the editor — explain that these are device-hidden duplicates, not broken images; - the decision to drop the responsive variants and keep a single layout is a product decision — discuss it with the user explicitly. ## Self-check (mandatory before output) - **Visual hierarchy** (for emails longer than one section): at least two sections with an opaque `background`, at least one of them contrasting with the rest; at least three different `fontSize` values; the CTA has a brand `background` set, if the brand or reference is known; lists are assembled as a grid, not a single column. An email made of sections with no background, text of a single size, and a black-and-white button is unfinished, even if valid. - **Grid:** the sum of `size` across all columns in every `FlexRow` and `` **equals 12** (strictly ==, not ≤). For example: `12` (one), `6+6` (two), `4+4+4` (three), `8+4`, `3+3+6`. - **Inter-block spacing:** in a new/modified layout, ordinary spacing is done via `innerSpacing`, so the section background is preserved. Every new `gapAfterBlock` is justified by an explicit request or a visible outer color gap in the layout; an untouched existing gap is preserved on an unrelated edit. - **Runtime-required attribute:** `Column.size`. For a new CTA, `Button.url` is required by policy, but the converter only validates the URL if the attribute is present. - **Minimum nesting:** `Template` ≥ 1 `Block`, `Block` ≥ 1 `FlexRow`, `FlexRow` ≥ 1 `Column`. - **Root tag:** exactly one `