The question: Should a shortcode's default colours be hardcoded, or should they follow the site's Color Presets (the theme palette) automatically — falling back to the hardcoded value only when the palette isn't available?

The questions: the opt-in --share flow sanitizes each conversion into a structural-only JSON and POSTs it to a Google Form. (1) Will an external developer's AI agent send us something we can actually use to improve the converter? (2) What's the right consent cadence — does it send cumulatively or per bug; does one "yes" cover the rest of the site; and is it OK to keep asking after a "no"?

The question: the Site Converter is deterministic, so an outside AI agent will hit cases it can't map. Will that make the agent ship a half-baked site? And to fully convert, should the agent fork the converter (or keep a custom converter folder/hook) and report its changes?

The question: when an agent creates a new shortcode, how does it choose where the shortcode lives — and should it ask the user how they want to install / distribute it (child theme vs an uploadable zip they can hand out), or just decide?

The question: the spacing scale (unysonplus_default_spacing_scale()) has no 32px or 40px step — the range 24→48px is one gap — so the Site Converter, which snaps a source's captured padding to the nearest slug, rendered e.g. a 40px bottom padding as 48px (up to 12px error). Should we renumber the whole scale to Tailwind numbering (pt-8=32px, pt-10=40px…) to fill the gap, or keep the scale and add arbitrary values (pt-[40px])?

The question: a decomposed element carries styling a shortcode has no option for (a heading's font-extrabold leading-[1.1], a paragraph's md:text-xl text-foreground/70). The Special Heading shortcode — and every shortcode's Advanced tab — has a CSS Class field. Rather than synthesizing Custom CSS for each effect, why not just put the source's own utility classes in that field and let the section's carried CSS render them? Isn't that cleaner and more editable?

The question: The new Card Rows designer lives on a Card tab, but the reusable border/corners/shadow/fill preset you apply to that card is called Box Style (from Box Presets). That looked inconsistent — should we rename everything to one word ("Box tab / Box Rows", or "Card Box Style / Card Box Presets")?

The question: the theme's Container Width setting (Theme Settings → General → Layout) drives .fw-container { max-width: … }. But the container also carries a left/right gutter as padding, and with box-sizing: border-box that padding is inside the max-width — so setting the width to 1280 (to match a source's max-w-7xl) rendered only ~1216px of actual content. Should "Container Width" mean the outer box (Bootstrap's model, current) or the content width (Tailwind's model, expected)?

The question: the wc_products (Products) element controlled a product card three overlapping ways — a Classic/Slot "Card Layout" dropdown, a column of per-element show/hide switches (Price, Rating, Rating Number, Short Description, Quick View, Add to Cart, Wishlist, Stock), and an editable Card Rows slot designer. Do we keep all three, or is one model enough? And with the fixed "Classic" markup gone, where should a card's visual skin (border, corners, shadow, hover) come from?

The question: the compact rounded-label shortcode — sub-tag, message, leading/trailing icons, optional link — was called announcement_pill. It renders status badges, "what's new" hero chips, eyebrow labels and announcement bars. Is "announcement pill" the right name for it, or should it be badge — and if we rename, do we need a migration?