sitesThe shared shell
Owns the global head, navigation, footer, branded CSS, and trusted site JavaScript—including the single canonical widget embed.
Website Developer Agent
The Website Developer Agent builds inside Salesbooth’s native site model: shared presentation in the site shell, page-specific content in page records, a protected preview, and approval before publishing.
Shared concerns stay shared, pages stay focused, and reusable components have a clear home. That means the preview and the live renderer work from the same structure.
sitesOwns the global head, navigation, footer, branded CSS, and trusted site JavaScript—including the single canonical widget embed.
site_pagesStores each page’s semantic body, title, description, path, status, and version without duplicating global presentation.
site_blocksStores repeated page sections once when reuse is appropriate, then expands them for preview and publication.
The workflow keeps customer-facing changes inspectable at each stage and verifies the committed result after publishing.
Use business context, real products, page goals, and the intended customer journey.
Check structure, copy, links, responsive behavior, SEO, proof, and widget handoff.
Render the stored shell and page content together before the change is public.
Publish only after approval, keep a backup, and verify the live records after commit.
The stored site is checked for completeness and convergence, rather than relying on a model saying the page looks finished.
Responsive layouts, phone-width overflow, readable type, and complete visible content are evaluated before readiness.
Dead navigation, placeholder forms, missing widget handoffs, and broken customer paths block readiness.
The final re-check uses the saved shell and page records that the preview route actually renders.
The Website Developer Agent never invents a key. Salesbooth provisions an origin-restricted publishable key, stores the canonical element in the shared shell, and lets page buttons open it.
The custom element is shared across every composed page while page calls to action use simple, accessible trigger attributes.
The widget reads the active tenant catalogue and calculates configuration choices there, keeping pricing out of fragile hard-coded forms.
The design can move quickly because publishing and verification are separate, explicit stages.
No. Draft work and protected previews are created before the approval-gated publish action.
Yes. Each native page carries its own customer-facing title and description while shared head and presentation concerns remain at site level.
The publish workflow records backup evidence before replacement and verifies the committed live rows afterward.
Tell the widget what the site needs to achieve and which real products or services it should help customers explore.