The HoopAI website preserves the Webflow interaction runtime as a permanent engineering strategy. Passthrough pages ship with their exported markup and replay the required scripts, while CMS pages keep the same CSS and runtime around React-rendered content. The purpose is interaction fidelity across the existing site, including the behavior attached through jQuery, IX2, GSAP, and Swiper. This update describes a website implementation choice and does not introduce a new HoopAI product feature.
The interaction-fidelity requirement
The repository treats exported Webflow markup as the reference for passthrough pages. Visual structure and interactions are expected to behave as authored rather than being approximated in a separate component system. That requirement includes navigation, disclosure controls, motion, and other page-specific behavior tied to Webflow classes or runtime data. A markup-only export would preserve appearance at rest while leaving part of the experience inactive.
Fidelity also defines where fixes belong. A styling or interaction defect on a passthrough page is investigated in the Webflow CSS and runtime replay path. Engineers do not convert the page into an unrelated Astro-native design to avoid the issue. This keeps maintenance aligned with the source architecture and limits drift between the exported page and the deployed result.
What the runtime replays
Astro loads each passthrough page through apps/astro/src/lib/island.ts and wraps it with MarketingShell. The replay path supplies jQuery and the Webflow interaction code, with GSAP and Swiper available where the source page needs them. The implementation extracts the relevant island markup and scripts into the shipping document rather than exposing the raw island route as a standalone production page.
Runtime dependencies receive build-time scrutiny because one missing script can affect the entire site. The project guidance records a previous failure in which a blocked jQuery location stopped Webflow initialization and broke interactions. The current setup self-hosts jQuery and includes a generated-output guard. Functional checks must confirm script execution and real interaction behavior, not only successful asset requests.
How CMS pages fit the model
CMS pages differ in their content source and rendering path. They use CloneShell with React renderers and WebflowRuntime.astro, while Sanity supplies the document data. They still retain the Webflow CSS and required runtime. The CMS layer can therefore render structured publishing content without introducing an unrelated visual and interaction foundation.
This split gives the repository two live shells with one runtime commitment. A source file reveals the layer: MarketingShell identifies passthrough and CloneShell identifies CMS. Public badges that once exposed migration metadata have been removed, so the distinction remains an internal engineering concern rather than visitor-facing content.
What remains byte-faithful
Passthrough pages preserve the exported markup and Webflow behavior. The raw export and island files remain read-only references and build inputs. Engineers extend the passthrough or CMS patterns already in use instead of reviving the archived owned-rebuild route. That archived work remains recoverable in Git, but it does not define the current site.
Byte fidelity does not prevent infrastructure safeguards around the page. The shell can own self-hosted runtime assets, verification checks, accessibility overrides, or deployment wiring when those changes preserve the intended result. The boundary is clear: protect and replay the existing experience, and avoid re-authoring it into a second product surface that would need independent parity maintenance.
