The question: the converter kept producing sections with the wrong spacing, a missing overline color, a dropped background. One proposed fix: extract all of Tailwind's official utility classes (a finite, canonical set) and selectively pre-map each to a shortcode option, so coverage is "complete" and we stop missing things. Is that the right primary mechanism, or a regression to brittle class-name parsing?

The question: while reproducing a source site, the converted output had many small misses (a button missing its shadow-lg, a pill rendered as a plain <span>, borders and paddings off). The fast instinct is to hand-fix that one site — nudge misc_custom_css, tweak a preset value — until it matches. But should the AI hand-patch the output, or should every fix go into the deterministic Site Converter so it produces the correct result on its own?

The question: we already decided the converter's job is to fix the algorithm, not the output. But in practice, when a build hits a section the converter can't map yet (e.g. a WooCommerce product grid), what is the exact, repeatable iteration — and when do you actually write a recognizer versus just hand-build it?

The question: the copyright bar's alignment kept coming out wrong when cloning a source (centered in the source, left in ours). Do we give each copyright column its own alignment control, or infer the alignment from how many columns there are?

The question: every no-code post type builder has the same objection sitting under it — now my content schema depends on your plugin. It is a fair objection. Do we answer it with documentation, or with a feature?

The question: Custom Fields could not link content to content. No way to point a Property at its Agent, a Case Study at related Case Studies, a Team Member at a WordPress user. That is the single most common reason to reach for ACF instead. Do we build a relationship option type?

The question: removing a post type row from the Post Types screen doesn't delete anything, but it makes every item of that type invisible — no admin menu, no edit screen, URLs stop resolving. A user who "cleans up" a row loses access to their content with no warning and no obvious way back. What should the screen do about it?

The question: the Post Types extension already deferred flush_rewrite_rules() to the request after a save, which is the pattern most no-code CPT plugins get wrong. So why were third-party permalinks occasionally 404-ing after someone saved the screen?

The question: the Post Types screen silently dropped invalid rows — a reserved key, a duplicate, a taxonomy attached to nothing. The user saved, saw "Saved.", and nothing appeared, with no way to find out why. Adding validation was obvious. Whether validation should refuse the save was not.

The question: Phase 0 of the Animation Engine's motion roadmap is "make scrolling feel effortless everywhere, and give every scroll-driven effect one shared clock." That raised two forks. (1) Where should the new inertia smooth-scroll live — a new engine module, or an extension of the theme's existing anchor-link "Smooth Scroll"? (2) How do we unify the scroll-reactive modules so they stay in lockstep — port them all to GSAP's ScrollTrigger, or reuse the engine's own shared animation loop?