The question: A converted "About" section used the source's container-narrow class (max-width: 64rem). The section shortcode's Container Width control offered only fixed presets — Narrow 768 / Medium 896 / Wide 1024 / Custom. 64rem is 1024px, so this one mapped to Wide — but the general problem stood: when a site uses a container width the theme has no named slot for (and reuses it across many pages), how should the converter represent it so the result is faithful and reusable, not a value copy-pasted onto every section?

The question. A converted "About" section's subtitle paragraph carried max-w-2xl mx-auto (a 672px centered content measure). The converter dropped it: the section rendered full-width. Two questions fell out of that: (1) what's the rule for putting converted CSS in Theme Settings → Miscellaneous → Custom CSS vs the child theme stylesheet? And (2) what's the strict rule so a class that can't map to a native shortcode option is never silently dropped — it MUST land somewhere?

The question. A source logo is a text wordmark: <a class="font-serif text-2xl md:text-3xl tracking-tight text-foreground hover:text-primary …">Maison</a>. The converter captured the text, colour, size and weight — but the output rendered "Maison" in the theme's sans default, with none of the source's serif, tight tracking, or hover colour. So: when an element's classes can't ALL map to native options, how should we translate them — and does the rule we adopted for content sections apply to chrome (logo / header / footer) too?

The question: In practice the special_heading subtitle was almost never used by the Site Converter — a heading's intro line came through as a separate text_block. Two things to settle: (1) should the converter fold a paragraph right after a title into the subtitle, and (2) should the subtitle option stop being a single-line text field and become a rich editor?

The question: A converted button (scandi-haven-shop's hero "Shop Now") dropped its hover animation — a translucent overlay that rises from the bottom to fill the button. The effect lives entirely on .btn-premium::after + .btn-premium:hover::after, which getComputedStyle(el) never exposes. Once we teach the capture to harvest those rules, what do we DO with them: reproduce the source CSS verbatim on the button, or map it to one of the theme's named hover-effect presets?

The question: The [newsletter] element already renders a form, validates a signup and emails the site admin — but nothing stores it. Building that storage layer means choosing a shape now that still works when campaigns, automations, contact timelines and Mailchimp/MailerLite/Brevo sync arrive. So: custom post type or custom tables? And once that is settled, how are lists, tags and segments modelled — because that is the decision that is expensive to reverse.

The question: When a converted <div class="text-center max-w-2xl mx-auto"><h2>…</h2><p>…</p></div> comes out left-aligned, where does alignment belong? Should we add text_align to the column/section — and if we do, is special_heading's master Alignment option now redundant and safe to remove?

The question: We want the docs site to explain how the deterministic Site Converter turns a source element into a UnysonPlus shortcode — the Priority / Recognizer / Matches when / Becomes table, plus the native options each mapping sets. Two open questions: where does it go — a row added to each /docs/shortcodes/<element> page, or one consolidated table — and do we hand-write it or generate it?

The question: As the AI Dev Kit grew, its root filled with a mix of hand-authored files and machine-fetched folders. Should the fetched/assembled folders be collected into one directory — and if so, what should it be called?

The question: Should the Live Editor's flat "Sections" panel become a full nested Structure tree (section → column → element), like the navigators in Bricks / Elementor / Webflow?