The question: The Portfolio extension has its own Settings page (archive columns, per-page, order, single-view toggles). The theme is gaining a Theme Settings → Portfolio tab. Who owns which settings — and how do the two coexist without drifting or double-defining everything?
The question: [posts post_type="fw-portfolio"] already renders project listings with
layouts, card styles and pagination. Should [portfolio] stay a lightweight filter-grid and
steer users to [posts], or grow into the full portfolio element?
The question: we keep building cinematic scroll-driven sites (a pinned "camera ride" frame-sequence background with full-screen text scenes keyed to scroll segments). Should that become a brand-new Animation Engine module / shortcode, or grow out of something that already exists — and either way, how does a typical builder user author one without touching code?
The question: An AI browsing agent reads a page two ways — through the accessibility tree (roles, names, states) and through the server-rendered HTML (text, links, and machine-readable structured data). Should UnysonPlus invest in being "agent-ready" across both channels? And does that investment include building a WebMCP integration (page-exposed tools an in-browser agent can call) now?
The question: The Posts "Card Style" list felt redundant — several styles are just an image mask or a fill on top of a base layout, and we already have Box Presets. How should image treatments be organized, and should they become a reusable Theme Settings preset?
The question: How should the footer support 5+ distinct bands cleanly — a child theme
dropping a footer-container-4.php / footer-container-5.php options file per extra bar, or
something lighter?
The question: The footer Column Ratio slider can't reproduce a real design's columns (a wide brand block beside three content-sized link lists). Do we hit a grid limitation — and if so, do we build a new flex container/section, or fix the existing column control?
The question: Internal Page-Builder pages ship with no <h1>. Should we require a
special_heading (H1) in each page's builder content, or have the theme render the page title
as the H1?
The question: Should other developers using the AI Dev Kit have their agents change the Site Converter — and if we instead want them to report improvements back, is GitHub the right place, given not everyone has an account?
The question: Should the kit's theme-settings-reference.md go deeper — documenting every
preset's options and all their choices — and split into a folder, one file per main tab?