The question: To make the Steps/Process shortcode "future-proof," should it adopt the shared Card
Rows slot designer that Posts, Testimonials, wc_products and team-member use — a drag-to-reorder
row/slot layout with a live card preview — or take the smaller step of adding a Box Preset (box_style)
that layers onto its existing layout engine?
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?