@framework-cwf/sections

The customer-site page sections — Hero, ServicesSection, Stats, BarbersSection, GallerySection, Testi, FaqSection, VisitSection — plus the chrome they compose with (Nav, Foot, Marquee, PageHeader, BookingCta, SiteShell, Picture).

Why this package exists

These components used to live in apps/template/components/. apps/template is a scaffold source, not a dependency: scaffold-business copies it into a new per-business repo once, and the copy never receives another update.

That is what broke the QA testids (booking-web#845). PageHeader and the eight section components gained testId props in contracts 0.12.0/0.13.0, the generated manifest declared 93 testids, and qa:validate went green — while every deployed customer site rendered exactly zero of them, because every deployed site was still running its scaffold-time copy of the components. No dependency bump could have fixed it. The components were not a dependency.

Publishing them makes the manifest true by construction: the version that declares a testid is the version that renders it, and a site picks up both in the same bump.

What did not move

lib/catalog.ts and lib/testimonials.ts stay in the site. They turn a published OperationalConfig into these components' props, and which categories a business enables, how staff are filtered and what ordering the menu uses are per-deployment choices the framework should not bake in.

Their result shapes are exported from here (ServiceCatalogEntry, LocationCatalogEntry, StaffCatalogEntry, TestimonialView) because those are the contract between a site's derivation and this package's components. A site imports the types and keeps its own builders.

Server / Client

SiteShell, Nav, BookingCta and Testi are Client Components and carry "use client". Everything else is a Server Component — the static-export marketing pages stay free of client JS except where interaction genuinely requires it.

testIds

Every section takes an optional testId stem (e.g. "cust-visit") and derives full testids at the leaves (cust-visit-visit-root). Omitting the prop renders no data-testid at all, so the attributes cost nothing on sites that do not run the QA suite.

The stems are supplied by pages in apps/template/app/, and tools/testid-manifest/generate.ts scans that one hop — page stem × component suffix — to emit CUSTOMER_SITE_TESTID_MANIFEST in @framework-cwf/contracts. Run pnpm testids after changing a data-testid; pnpm testids:check fails CI when the committed manifest and the JSX disagree.

Peer dependencies

contracts, auth and booking-embed are peers, ranged >=x.y.0 <1.0.0 rather than with a caret. Below 1.0.0 a caret is patch-only, so ^0.14.0 would exclude 0.15.0 and re-break installs on the next minor — see docs/package-coupling.md.