The question: The Site Converter's conversion knowledge lived in two places — a deep how-it-works (architecture + algorithm) under the extension docs, and a conceptual how-it-works (capture-first → outside-in → measure) under the AI Dev Kit — and neither was clearly the canonical home. Should we move all the extension's conversion subpages into the AI Dev Kit and reduce the extension section to a basic overview + a link, so all conversion info lives in one place?

The question: After the Site Converter walks a source and clusters every box skin into on-brand Box Presets, what happens to the plugin's four built-in defaults (Card / Outline / Soft Shadow / Hover Lift)? Do the site-derived presets replace them, or do both coexist — and if both, in what order?

The question: A single-URL conversion of an inner page (e.g. https://site/services) — should the user have to manually uncheck Create child theme, Capture header, Capture footer to get "just the sections content"? Will it create a new page or override the homepage? And if it can override the homepage, don't we need a "Create new page" checkbox?

The question: A converted store should get live WooCommerce shortcodes for its product grids ([wc_products], add-to-cart, etc.) rather than the static image_box cards a generic card grid becomes. Should the converter simply auto-detect WooCommerce from the source and map accordingly — or put a checkbox in the Convert panel, greyed out when WooCommerce isn't installed?

The question: How should the theme handle responsive typography long-term — keep stepping sizes at a breakpoint, add per-device controls to every field, or move to a fluid type system? And what has to be true for a fluid system to not fail accessibility?

The question: The Site Converter kept producing pages where a shortcode's own CSS or a unysonplus-theme default silently overruled the styles we mapped from the source — headings rendered bold when the source was regular, service-card icons came out green instead of grey, footer address text went black. Each was fixed one property at a time. Should we build a general "checker/detector" that stops shortcode and parent-theme styles from overruling the source?

The question: A typography overhaul this large can't safely be edited in place on the live control. How do we build and prove it without risking every site, and without leaving a messy v1 / v2 / v3 option-type namespace behind?

The question: Can the group container type carry a label of its own, so we stop faking section headings with a leading html option?

The question: a user wants a header that is transparent over the hero and shrinks its logo once you scroll. Today they can't — "Transparent overlay" and "Sticky + shrink" are two different values of the same Header Behavior dropdown. Why is a header's behavior a single choice at all, and how should we organize it so every setup is possible?

The question: Now that image-picker choices in the popover can be deselected (clearing the selection means "none"), should we remove the standalone "Enable page transitions" style switches across Site-wide UX and let "no image selected" mean "off"?