@sudajs/cli 0.10.4 → 0.11.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sudajs/cli",
-  "version": "0.10.4",
+  "version": "0.11.0",
   "type": "module",
   "bin": {
     "suda": "./bin/suda.js"
@@ -34,7 +34,7 @@
     "react": "^19.2.7",
     "react-dom": "^19.2.7",
     "zod": "^3.24.1",
-    "@sudajs/theme-engine": "2.6.2"
+    "@sudajs/theme-engine": "3.0.0"
   },
   "devDependencies": {
     "@tailwindcss/postcss": "^4.3.0",
@@ -49,8 +49,8 @@
     "typescript": "^5.7.2",
     "vite": "^7.3.3",
     "vitest": "^3.2.4",
-    "@suda/build-config": "0.0.0",
     "@suda/eslint-config": "0.0.0",
+    "@suda/build-config": "0.0.0",
     "@suda/tsconfig": "0.0.0"
   },
   "scripts": {

package/templates/theme/AGENTS.md

@@ -4,17 +4,344 @@ This directory is a standalone Vite + React + Tailwind Suda theme generated by `
 
 Your job in a theme project is to create a complete, publishable theme with theme-specific components, realistic starter pages, scoped styling, assets, and AI metadata. Do not build pages by assembling generic engine components; those are reserved for end users who need supplemental editing blocks after the theme is installed.
 
+## Theme-building workflow
+
+When you add or change a section, complete the whole theme authoring loop in
+one pass:
+
+1. Define the props type. Use serializable values only. Use `Slot` only for
+   props that are backed by `blockSlots`.
+2. Export a `SudaComponentConfig<Props>` with `label`, `ai.instructions`,
+   `fields`, optional `blockSlots`, `defaultProps`, and `render`.
+3. Keep `fields` and `defaultProps` aligned. Every normal field should have a
+   sensible value in `defaultProps`; do not put block-slot props in
+   `defaultProps`. Do not put `id` in component `defaultProps`; `id` belongs
+   only to concrete top-level page/layout content items.
+4. Add every editor-facing label key to `src/locales/en.json` when you add the
+   component, field, option, or local block.
+5. Register the component in `src/config.ts` under `pageConfig.components`.
+   Register only shared chrome components such as `Header`, `Footer`, and
+   `PageOutlet` under `layoutConfig.components`.
+6. Use the component in starter pages and CMS templates with public component
+   keys from `pageConfig.components`.
+7. Wrap authored page data with `defineSudaPageData(pageConfig, data)` whenever
+   practical so TypeScript checks top-level component types and block-slot
+   nested `type` values.
+8. Run `pnpm typecheck`, `pnpm lint`, `pnpm build`, and `pnpm validate` before
+   handoff.
+
+Configure ordinary fields like this:
+
+```ts
+type HeroProps = {
+  eyebrow?: string;
+  title?: string;
+  body?: string;
+  align?: "left" | "center";
+  featured?: boolean;
+};
+
+export const Hero: SudaComponentConfig<HeroProps> = {
+  label: t("sections.hero.label"),
+  ai: {
+    instructions:
+      "Landing page hero section. Configure concise copy and a layout choice.",
+  },
+  fields: {
+    eyebrow: { type: "text", label: t("sections.hero.fields.eyebrow") },
+    title: { type: "text", label: t("sections.hero.fields.title") },
+    body: { type: "textarea", label: t("sections.hero.fields.body") },
+    align: {
+      type: "select",
+      label: t("sections.hero.fields.align"),
+      options: [
+        { label: t("common.options.left"), value: "left" },
+        { label: t("common.options.center"), value: "center" },
+      ],
+    },
+    featured: { type: "checkbox", label: t("sections.hero.fields.featured") },
+  },
+  defaultProps: {
+    eyebrow: "New",
+    title: "Welcome",
+    body: "Describe the main offer in one or two sentences.",
+    align: "left",
+    featured: true,
+  },
+  render: ({ eyebrow, title, body, align, featured }) => (
+    <section data-align={align} data-featured={featured ? "true" : "false"}>
+      {eyebrow ? <p>{eyebrow}</p> : null}
+      <h1>{title}</h1>
+      {body ? <p>{body}</p> : null}
+    </section>
+  ),
+};
+```
+
+Use normal fields for scalar section settings such as text, textarea, number,
+range, checkbox, select/radio options, media, URL, icon, color, object, and
+array values. Put those field values in the host component's `defaultProps`.
+Use `blockSlots` only when the section owns nested local blocks that editors
+and AI should add, remove, or reorder independently.
+
+Field source of truth:
+
+- Use TypeScript, not a hand-written runtime schema. Type props first, then let
+  `SudaComponentConfig<Props>`, `SudaFields<Props>`, `SudaField`, and
+  `defineSudaPageData(pageConfig, data)` catch mismatches.
+- There is no theme-authored zod schema for fields. Do not invent one in the
+  theme. Run `pnpm typecheck` and `pnpm validate` instead.
+- Every field entry needs a `type`. Add a localized `label` for every
+  editor-facing field.
+- Put a matching serializable value in `defaultProps` for every normal field.
+  Optional props can still have defaults; defaults make editor insertion and AI
+  generation reliable.
+- Use `description`, `placeholder`, and `visibleIf` only when they help the
+  editor or AI choose the right value.
+- Suda extended field types are `url`, `icon`, `font`, `menu`, `color`,
+  `range`, `spacing`, `media`, `image`, `video`, and `posts`. These are valid
+  in `fields` and are normalized by `@sudajs/theme-engine`.
+
+Use these field patterns:
+
+```ts
+fields: {
+  // Plain copy
+  title: { type: "text", label: t("common.fields.title") },
+  body: { type: "textarea", label: t("common.fields.description") },
+  richBody: { type: "richtext", label: t("common.fields.content") },
+
+  // Numbers and booleans
+  columns: { type: "number", label: t("common.fields.columns") },
+  featured: { type: "checkbox", label: t("common.fields.featured") },
+  opacity: {
+    type: "range",
+    label: t("common.fields.opacity"),
+    min: 0,
+    max: 100,
+    step: 5,
+    unit: "%",
+  },
+
+  // Choices: always provide options with localized labels and serializable values.
+  align: {
+    type: "radio",
+    label: t("common.fields.align"),
+    options: [
+      { label: t("common.options.left"), value: "left" },
+      { label: t("common.options.center"), value: "center" },
+    ],
+  },
+  tone: {
+    type: "select",
+    label: t("common.fields.tone"),
+    options: [
+      { label: t("common.options.light"), value: "light" },
+      { label: t("common.options.dark"), value: "dark" },
+    ],
+  },
+
+  // Suda extended fields
+  href: { type: "url", label: t("common.fields.link") },
+  image: { type: "image", label: t("common.fields.image") },
+  video: { type: "video", label: t("common.fields.video") },
+  download: { type: "media", kind: "file", label: t("common.fields.file") },
+  icon: { type: "icon", label: t("common.fields.icon") },
+  accentColor: { type: "color", label: t("common.fields.color") },
+  font: { type: "font", label: t("common.fields.font") },
+  links: { type: "menu", label: t("common.fields.menu") },
+  spacing: { type: "spacing", label: t("common.fields.spacing") },
+
+  // Dynamic post lists. Use this only on page sections that intentionally
+  // render post resources, not on fixed CMS main sections.
+  postList: { type: "posts", label: t("common.fields.posts") },
+
+  // Objects and arrays need nested typed fields.
+  badge: {
+    type: "object",
+    label: t("common.fields.badge"),
+    objectFields: {
+      label: { type: "text", label: t("common.fields.label") },
+      tone: { type: "text", label: t("common.fields.tone") },
+    },
+  },
+  cards: {
+    type: "array",
+    label: t("common.fields.cards"),
+    getItemSummary: (item) => item.title || "Card",
+    defaultItemProps: { title: "Card title", body: "Card body" },
+    arrayFields: {
+      title: { type: "text", label: t("common.fields.title") },
+      body: { type: "textarea", label: t("common.fields.description") },
+      href: { type: "url", label: t("common.fields.link") },
+    },
+  },
+}
+```
+
+Match those fields with defaults:
+
+```ts
+defaultProps: {
+  title: "Welcome",
+  body: "Describe the offer.",
+  richBody: "<p>Long-form content.</p>",
+  columns: 3,
+  featured: true,
+  opacity: 80,
+  align: "left",
+  tone: "light",
+  href: "/contact",
+  image: themeAsset("assets/hero.jpg"),
+  video: "",
+  download: "",
+  icon: "sparkles",
+  accentColor: "#2563eb",
+  font: "system",
+  links: [{ label: "Home", url: "/" }],
+  spacing: "md",
+  postList: { strategy: "featured", limit: 3 },
+  badge: { label: "New", tone: "primary" },
+  cards: [{ title: "Fast setup", body: "Launch quickly.", href: "/features" }],
+}
+```
+
+Starter page and CMS template data must use this shape:
+
+```ts
+defineSudaPageData(pageConfig, {
+  root: { props: {} },
+  content: [
+    {
+      type: "Hero",
+      props: {
+        id: "Hero-1",
+        title: "Welcome",
+        actions: [
+          {
+            type: "button",
+            props: { label: "Contact us", href: "/contact" },
+          },
+        ],
+      },
+    },
+  ],
+});
+```
+
+Top-level `content[].type` must be a key registered in `pageConfig.components`.
+Top-level `content[].props.id` is required in starter pages, CMS templates, and
+layout data. Do not put `id` in component `defaultProps`, local block
+`defaultProps`, `defaultBlocks`, or block-slot nested items.
+Nested block-slot items must use short local block kind names such as
+`"button"`, `"copy"`, or `"cards"`. Never write
+`__suda_local_block__/...` in source templates, starter pages, CMS templates,
+or AI examples.
+
 ## Theme contract
 
 - Keep `renderMode: "ssr"` in `src/manifest.ts`.
 - Keep source entries at `src/index.tsx`, `src/runtime.client.ts`, and `src/styles.css`.
-- Export a complete `ThemeModule` from `src/index.tsx`: `manifest`, `pageConfig`, `layoutConfig`, `defaultLayout`, and `starterPages`.
-- Starter page slugs preview at site-like root routes in `suda theme dev`: `home` is `/home`, `contact-us` is `/contact-us`. Do not use `/pages/...` as a preview route prefix.
+- Export a complete `ThemeModule` from `src/index.tsx`: `manifest`, `pageConfig`, `layoutConfig`, `defaultLayout`, `starterPages`, and `cmsTemplates`.
+- Starter page slugs preview at site-like root routes in `suda theme dev`: `index` is `/index`, `contact-us` is `/contact-us`. Do not use `/pages/...` as a preview route prefix.
 - Keep `pageConfig` focused on page content sections. Keep `layoutConfig` focused on shared site chrome such as root, header, page outlet, and footer.
 - Do not edit generated files under `dist/`; run `pnpm build` to regenerate them.
 - React, React DOM, Puck, and `@sudajs/theme-engine` are host-provided peers. Do not bundle private copies into the theme runtime.
 - Keep persisted props JSON-serializable. Do not store functions, React nodes, class instances, database ids for media, or environment-specific absolute filesystem paths.
 
+## CMS and starter templates
+
+Suda CMS is a built-in fixed post system. Themes must provide exactly these
+four CMS templates through `cmsTemplates`:
+
+- `posts`: post list template for `/posts`
+- `post`: post detail template for `/posts/:slug`
+- `tags`: tag/category list template for `/tags`
+- `tag`: posts filtered by one tag for `/tags/:slug`
+
+Each `cmsTemplates` value must be an object with `{ title: string; data:
+PageData }`. Do not point a key directly at raw `PageData`, and do not use
+intersection types such as `ThemeModule & { cmsTemplates:
+Record<string, PageData> }` to bypass the current contract.
+
+```ts
+export const cmsTemplates: ThemeCmsTemplates = {
+  posts: { title: "Posts", data: postIndexTemplate },
+  post: { title: "Post", data: postDetailTemplate },
+  tags: { title: "Tags", data: tagIndexTemplate },
+  tag: { title: "Tag", data: tagDetailTemplate },
+};
+```
+
+Do not create Shopify-style template variants such as `post.default`,
+`post.modern`, or `posts.magazine`. Do not add arbitrary collection/content
+types or manual data-source binding contracts. Keep CMS-only sections limited
+to the CMS templates where they belong.
+
+Create CMS template main sections like this:
+
+- `MainPosts`: place only on `posts` and optionally `tag` templates with
+  `placement: { cmsTemplates: ["posts", "tag"] }`; render `cms.posts`
+  directly and use `cms.pagination` for pagination controls. Use
+  `cms.currentTag` when a tag filter is active.
+- `MainPost`: place only on the `post` template; render the current article
+  when `cms.type === "post"`.
+- `MainTags`: place only on the `tags` template; render tag/category cards
+  when `cms.type === "tags"`.
+- `MainTagPosts` can be a separate tag-page list section, or `MainPosts` can
+  handle both `posts` and `tag` contexts. Choose the clearer API for the theme.
+
+In CMS template main sections, call `getCmsContent(puck?.metadata)` and render
+the matching CMS data. Do not add `type: "posts"` fields to those sections.
+
+For pagination controls, use `cms.pagination.page`,
+`cms.pagination.totalPages`, `cms.pagination.hasPreviousPage`, and
+`cms.pagination.hasNextPage` to decide what to show. Do not hand-build
+pagination query strings. Import `cmsPaginationUrl` from
+`@sudajs/theme-engine/runtime` and call
+`cmsPaginationUrl(cms.pagination, targetPage)` for numbered links so existing
+filter/search parameters stay in the URL. Use `cms.pagination.previousUrl` and
+`cms.pagination.nextUrl` for previous/next buttons when present.
+
+Themes must also provide at least one reusable ordinary-page post section, for
+example `FeaturedPosts`, `LatestPosts`, or `TopicPosts`. Use it for homepage
+insights, featured articles, case studies, news teasers, or tag-filtered post
+groups on ordinary pages.
+
+Define that section with exactly one top-level `type: "posts"` field and a
+default query on the same prop:
+
+```tsx
+fields: {
+  postList: { type: "posts" },
+},
+defaultProps: {
+  postList: { strategy: "featured", limit: 3 },
+},
+```
+
+Supported strategies are `latest`, `featured`, `by_tag`, and `manual`. In the
+section render function, call `getPostResource(puck?.metadata, id)` to get the
+posts. Never import Prisma, call platform APIs, or query the database from
+theme code.
+
+Starter pages must include one home/index page with `isHome: true`. Recommended
+starter pages include `index`, `about-us`, `contact-us`, `services`, and `team`.
+Those recommended pages are not hard requirements, but a publishable theme
+should usually include several realistic pages so AI site generation has a rich
+reference set.
+
+Treat repetition as a design and business judgment, not a fixed rule. Let the
+site strategy decide where pages should share patterns and where they should
+diverge. Reusing strong sections across starter pages is often right: CTA,
+contact, booking, newsletter, download, and other conversion sections may appear
+repeatedly when they help visitors move forward. Avoid only mechanical
+copy-paste that makes different pages feel interchangeable. When useful, give
+each page its own purpose, angle, proof points, media, or ordering, while
+keeping repeated business-driving sections where they serve the user journey.
+Richer starter pages make the theme easier for AI to adapt without making users
+learn CMS/template mechanics.
+
 ## Editor i18n and locales
 
 Theme editor labels are localized by the host editor. Use the template's
@@ -156,14 +483,20 @@ Good component instructions explain:
 
 ## Block slot authoring rules
 
-Use `blockSlots` when a section owns controlled local content that benefits from independent editor selection and configuration, such as hero actions, pricing cards, feature rows, stats, timeline items, or contact methods. Keep ordinary section props in `fields`.
+Use `blockSlots` when a section owns controlled local content such as hero
+actions, pricing cards, feature rows, stats, timeline items, or contact
+methods. Keep ordinary section props in `fields`.
 
-- Type the slot prop as Puck `Slot` and declare `blockSlots` with the same prop key. This is the Suda block-slot API; do not create a native `fields.<key>.type = "slot"` yourself.
-- Define local block kinds under `blockSlots.<slotName>.blocks`. Local blocks support normal Suda fields, `label`, `defaultProps`, `render`, `metadata`, `inline`, `permissions`, and optional `ai`.
+- Type the slot prop as Puck `Slot` and declare `blockSlots` with the same prop key.
+- Do not create a native `fields.<key>.type = "slot"` in page components.
+- Define local block kinds under `blockSlots.<slotName>.blocks`.
+- Give every local block `label`, useful fields, `defaultProps`, `render`, and
+  optional `ai.instructions` when the block needs generation guidance.
 - Keep local blocks specific to the owning section. They are not reusable global page components.
-- Do not add nested `blockSlots` or `cms` to local blocks. Block slots are one level deep in the theme authoring API.
+- Do not add nested `blockSlots` to local blocks. Block slots are one level deep in the theme authoring API.
 - Do not put the slot prop in the host component's `defaultProps`; use `defaultBlocks` on the slot instead.
 - Do not hand-write `id` in local block `defaultProps`, `defaultBlocks[].props`, or starter page nested block props. The editor/runtime owns block ids.
+- In authored page data, starter pages, CMS templates, and AI examples, nested block-slot items must use the short local block kind as `type`, exactly matching a key in `blockSlots.<slotName>.blocks`. Never write internal local block types such as `__suda_local_block__/Hero/actions/button`; `@sudajs/theme-engine` generates those only for Puck internals.
 
 Example:
 
@@ -171,29 +504,35 @@ Example:
 import type { Slot } from "@puckeditor/core";
 import type { SudaComponentConfig } from "@sudajs/theme-engine";
 
+import { t } from "./i18n.js";
+
 type HeroProps = {
   title?: string;
   actions?: Slot;
 };
 
 export const Hero: SudaComponentConfig<HeroProps> = {
-  label: "Hero",
+  label: t("sections.hero.label"),
   ai: {
     instructions:
       "Primary page introduction for landing pages. Use once near the top with one or two local action blocks.",
   },
   fields: {
-    title: { type: "text", label: "Title" },
+    title: { type: "text", label: t("sections.hero.fields.title") },
   },
   blockSlots: {
     actions: {
-      label: "Actions",
+      label: t("sections.hero.blocks.actions"),
       blocks: {
         button: {
-          label: "Button",
+          label: t("sections.hero.blocks.button"),
+          ai: {
+            instructions:
+              "Primary or secondary hero action. Use one or two buttons with clear labels and valid links.",
+          },
           fields: {
-            label: { type: "text", label: "Label" },
-            href: { type: "url", label: "Link" },
+            label: { type: "text", label: t("sections.hero.blocks.buttonLabel") },
+            href: { type: "url", label: t("sections.hero.blocks.buttonHref") },
           },
           defaultProps: {
             label: "Get started",
@@ -217,7 +556,7 @@ export const Hero: SudaComponentConfig<HeroProps> = {
 };
 ```
 
-Starter page data should use the public host component type and a standard array on the block-slot prop. Use local block `kind` values as nested `type` values.
+Starter page data should use the public host component type and a standard array on the block-slot prop. Use local block `kind` values as nested `type` values; for the example above, `actions[].type` can only be `"button"`.
 
 ```ts
 {
@@ -244,17 +583,12 @@ Starter page data should use the public host component type and a standard array
 - Every starter page is Puck `Data` with `root: { props: {} }` and `content: [...]`.
 - Each top-level component instance in starter page `content` must include a stable `props.id`.
 - Use only components registered in `pageConfig.components` for top-level page content.
+- For any `blockSlots` prop, use only short local block kinds as nested `type` values, never `__suda_local_block__/...` internal types.
+- Do not put local block `id` values in starter pages. Only top-level page components need `props.id`.
+- Where practical, wrap authored data with `defineSudaPageData(pageConfig, data)` so TypeScript checks top-level component keys and block-slot nested `type` values.
 - Match starter page content to the theme's intended audience and category. The home page should show the theme's best composition, not just every component in order.
 - Use `themeAsset("assets/...")` for bundled starter media.
 
-## CMS-aware themes
-
-- If the theme supports posts or tags, declare `content.views` on the exported `ThemeModule`.
-- Add one starter page with matching `cmsView` for every declared CMS view.
-- Declare component-level `cms` capabilities only on components that can render that CMS source.
-- Use `cmsBinding` in starter page props when a component should receive CMS data at render time.
-- Keep static fallback props for CMS components so the page still renders meaningfully when CMS payloads are absent.
-
 ## Commands
 
 ```bash

package/templates/theme/src/index.tsx

@@ -2,7 +2,7 @@ import type { ThemeManifest, ThemeModule } from "@sudajs/theme-engine";
 
 import { defaultLayout, layoutConfig, pageConfig } from "./config.js";
 import { sourceManifest } from "./manifest.js";
-import { starterPages } from "./templates.js";
+import { cmsTemplates, starterPages } from "./templates.js";
 
 // Single source of truth: theme version comes from package.json#version,
 // injected by Vite as a compile-time constant so the published bundle stays
@@ -15,7 +15,8 @@ const theme: ThemeModule = {
   layoutConfig,
   defaultLayout,
   starterPages,
+  cmsTemplates,
 };
 
 export default theme;
-export { pageConfig, layoutConfig, defaultLayout, starterPages };
+export { pageConfig, layoutConfig, defaultLayout, starterPages, cmsTemplates };

package/templates/theme/src/locales/en.json

@@ -48,6 +48,14 @@
         "featureDescription": "Description"
       }
     },
+    "featuredPosts": {
+      "label": "Featured posts",
+      "fields": {
+        "title": "Title",
+        "description": "Description",
+        "postList": "Post list"
+      }
+    },
     "testimonial": {
       "label": "Testimonial",
       "fields": {

package/templates/theme/src/sections.tsx

@@ -1,5 +1,11 @@
 import type { SudaComponentConfig, SudaLucideIconName } from "@sudajs/theme-engine";
-import { resolveAsset, SudaLucideIcon, type ThemeRenderMetadata } from "@sudajs/theme-engine/runtime";
+import {
+  getPostResource,
+  resolveAsset,
+  SudaLucideIcon,
+  type ThemePostResourceQuery,
+  type ThemeRenderMetadata,
+} from "@sudajs/theme-engine/runtime";
 
 import { t } from "./i18n.js";
 import { themeAsset } from "./theme-asset.js";
@@ -32,6 +38,12 @@ type CallToActionProps = {
   buttonLabel?: string;
   buttonHref?: string;
 };
+type FeaturedPostsProps = {
+  id?: string;
+  title?: string;
+  description?: string;
+  postList?: ThemePostResourceQuery;
+} & PuckExtras;
 
 export const Hero: SudaComponentConfig<HeroProps> = {
   label: t("sections.hero.label"),
@@ -209,4 +221,60 @@ export const CallToAction: SudaComponentConfig<CallToActionProps> = {
   ),
 };
 
-export const SECTION_COMPONENTS = { Hero, FeatureGrid, Testimonial, CallToAction };
+export const FeaturedPosts: SudaComponentConfig<FeaturedPostsProps> = {
+  label: t("sections.featuredPosts.label"),
+  ai: {
+    instructions:
+      "Reusable post resource section for ordinary pages such as home, services, cases, or insights teasers. " +
+      "Use it when a page should show dynamic CMS posts such as latest articles, featured posts, or posts from a specific tag. " +
+      "Set the posts field prop; do not generate static article cards.",
+  },
+  fields: {
+    title: { type: "text", label: t("sections.featuredPosts.fields.title") },
+    description: { type: "textarea", label: t("sections.featuredPosts.fields.description") },
+    postList: { type: "posts", label: t("sections.featuredPosts.fields.postList") },
+  },
+  defaultProps: {
+    title: "Featured insights",
+    description: "Highlight recent or strategically important posts from the CMS.",
+    postList: { strategy: "featured", limit: 3 },
+  },
+  render: ({ id, title, description, puck }) => {
+    const resource = getPostResource(puck?.metadata, id);
+    const posts = resource.posts;
+    return (
+      <section className="__SUDA_THEME_KEY__-section">
+        <h2>{title}</h2>
+        <p>{description}</p>
+        <div className="__SUDA_THEME_KEY__-grid" style={{ "--__SUDA_THEME_KEY__-columns": 3 }}>
+          {posts.length > 0 ? (
+            posts.map((post) => (
+              <article className="__SUDA_THEME_KEY__-card" key={post.id}>
+                <p className="__SUDA_THEME_KEY__-eyebrow">
+                  {post.tags[0]?.name ?? "Post"}
+                </p>
+                <h3>{post.title}</h3>
+                <p>{post.excerpt}</p>
+                <a href={post.url}>{post.title}</a>
+              </article>
+            ))
+          ) : (
+            <article className="__SUDA_THEME_KEY__-card">
+              <p className="__SUDA_THEME_KEY__-eyebrow">CMS</p>
+              <h3>No posts yet</h3>
+              <p>Create and publish posts in SudaCloud to populate this section.</p>
+            </article>
+          )}
+        </div>
+      </section>
+    );
+  },
+};
+
+export const SECTION_COMPONENTS = {
+  Hero,
+  FeatureGrid,
+  FeaturedPosts,
+  Testimonial,
+  CallToAction,
+};