101 posts tagged with "Architecture"

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?

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 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)?