@wildo-ai/saas-website 1.1.1

package/dist/esm/index.js

@@ -0,0 +1,129 @@
+/**
+ * @wildo-package @wildo-ai/saas-website
+ *
+ * SaaS marketing/landing website engine — schemas + helpers + layout
+ * placeholders + Astro/MDX adapters + SEO/AEO/GEO builder library.
+ *
+ * Per `saas-website-slice.md` D6/D15: this engine ships **NO concrete
+ * business sections** (no Hero, no CTA, no Pricing). It ships the
+ * structural and helper machinery; consumers author every business
+ * section themselves via the `defineWebsiteSection` factory and the
+ * accompanying SKILLs in `framework-knowledge`.
+ *
+ * @wildo-boundary
+ *   - This barrel MAY re-export from any subdirectory of `src/`.
+ *   - Subdirectories MUST observe their own boundary contracts (see
+ *     each subdirectory's own `index.ts` `@wildo-boundary` block):
+ *       - `schemas/`            : NO React, NO Astro, NO `~wildo-frontend-lib/**`
+ *       - `seo/`                : NO React, NO Astro
+ *       - `core/`               : MAY use React; NO `~wildo-frontend-lib/**` (Q17=B)
+ *       - `astro/`              : MAY use Astro; NO React component runtime imports
+ *       - `mdx/`                : MAY use `@mdx-js/*`
+ *       - `integration/`        : MAY use React; MAY import the
+ *                                 `@wildo-ai/saas-models/public-runtime` SUBPATH,
+ *                                 the `@wildo-ai/presets-components-models/public-runtime`
+ *                                 SUBPATH, `@wildo-ai/zod-decorators`,
+ *                                 plus the SSR / Astro-middleware tier
+ *                                 (`axios`, `jsonwebtoken`, `socket.io-client`,
+ *                                 `reflect-metadata`) — D12 revised
+ *                                 2026-04-19 (second same-day loosening);
+ *                                 the ROOT barrels of `@wildo-ai/saas-models`
+ *                                 and `@wildo-ai/presets-components-models`
+ *                                 are FORBIDDEN (they boot the decorator
+ *                                 framework / pull the heavy registry);
+ *                                 the saas-app DI / backend stack
+ *                                 (`inversify`, `mongoose`, `express`,
+ *                                 `pino`, `helmet`, `argon2`, `bcrypt`,
+ *                                 the `@wildo-ai/saas-frontend-lib` /
+ *                                 `@wildo-ai/saas-backend-lib` /
+ *                                 `@wildo-ai/external-connectors-models`
+ *                                 root + subpath surfaces) is FORBIDDEN;
+ *                                 MUST NOT import `~wildo-frontend-lib/**`
+ *                                 (Q17=B / D16)
+ *
+ *   D12 (client-bundle import discipline, all `core/`/`schemas/`/`integration/`
+ *   files): the entire saas-website source tree ships into a browser bundle
+ *   (Astro SSG + React islands). Every shared model atom MUST come from a
+ *   side-effect-free `/public-runtime` subpath:
+ *     - `@wildo-ai/saas-models/public-runtime` is the primary door
+ *       (saas-models-public-runtime.md K-6 — consumers see one path).
+ *     - `@wildo-ai/presets-components-models/public-runtime` is the
+ *       internal seam for symbols not (yet) re-exported by saas-models.
+ *     - `@wildo-ai/zod-decorators` is allowed to import (first revision
+ *       2026-04-19). The package itself is side-effect-free; only an
+ *       explicit `initZodDecorators()` call mutates `z.ZodType.prototype`,
+ *       which neither saas-website nor the saas-models /public-runtime
+ *       barrel does.
+ *     - `axios`, `jsonwebtoken`, `socket.io-client`, `reflect-metadata` are
+ *       allowed for SSR / Astro-middleware code paths (second same-day
+ *       revision 2026-04-19). The website engine needs them to provide
+ *       middleware utilities (HTTP proxying to the SaaS backend, JWT
+ *       verification of cross-frontend handoff codes, real-time push,
+ *       decorator-metadata reads). They are SSR-tier — discipline
+ *       (and a future strict/loose entry split for React islands vs
+ *       middleware) keeps them out of the React-island bundle.
+ *
+ *   The ROOT barrel of `@wildo-ai/saas-models` is forbidden everywhere in
+ *   this package — it calls `initZodDecorators()` at module load and pulls
+ *   `@wildo-ai/external-connectors-models` + the full schema graph into
+ *   the bundle. Same forbid applies to the root barrel of
+ *   `@wildo-ai/presets-components-models`, the saas-app DI runtime
+ *   (`inversify`, `@wildo-ai/saas-frontend-lib`, `@wildo-ai/saas-backend-lib`),
+ *   and pure-backend libs (`mongoose`, `express`, `pino`, `helmet`,
+ *   `argon2`, `bcrypt`). Enforced by `src/__tests__/bundle-isolation.test.ts`.
+ *
+ *   These boundaries are enforced by review + the bundle-isolation test
+ *   above until Phase 8 promotes them to a programmatic ESLint check
+ *   (cf. `saas-website-slice.md`
+ *   §"DEFERRED to Phase 8 — boundary lint mechanism design").
+ *
+ * Phase 1+2 status: schemas + runtime contexts/hooks + layout
+ * primitives + L1 placeholders + factories are all exported. Phase 5
+ * adds the Astro adapter; Phase 5.7 the `integration/` layer.
+ *
+ * D18 (L1 boundary, Phase 2): the L1 primitives (`WebsiteHeading`,
+ * `WebsiteText`, `WebsiteButton`, `WebsiteLink`, `WebsiteImage`) are
+ * self-contained placeholders — they do NOT consume
+ * `ComponentRegistryService` from `saas-frontend-lib` and do NOT
+ * re-export `saas-frontend-lib` primitives. Consumers override at the
+ * L1 boundary by barrel-re-exporting their preferred styled variant
+ * from their app's `app/website/primitives/<Primitive>.tsx`. Phase 6
+ * dogfood will revisit and decide whether to promote a registry-based
+ * override mechanism.
+ */
+export * from './schemas/refs/page-ref.schemas.js';
+export * from './schemas/refs/section-ref.schemas.js';
+export * from './schemas/label-keys/website-label-key.schemas.js';
+export * from './schemas/sections/website-section-category.shared.js';
+export * from './schemas/sections/website-section-definition.shared.schemas.js';
+export * from './schemas/structured-data/website-structured-data.shared.schemas.js';
+export * from './schemas/structured-data/structured-data-reconciliation.shared.js';
+export * from './schemas/design-tokens/website-design-tokens.shared.schemas.js';
+export * from './schemas/manifests/website-page-manifest.shared.schemas.js';
+export * from './schemas/manifests/website-root-config.shared.schemas.js';
+export * from './schemas/blog/blog-post-frontmatter.shared.schemas.js';
+export * from './schemas/validators/label-pack.validator.js';
+export * from './core/contexts/WebsiteRuntimeContext.js';
+export * from './core/contexts/useWebsiteRuntime.js';
+export * from './core/contexts/WebsitePageContext.js';
+export * from './core/contexts/useWebsitePage.js';
+export * from './core/contexts/WebsiteSectionContext.js';
+export * from './core/contexts/useWebsiteSection.js';
+export * from './core/hooks/useWebsiteLabel.js';
+export * from './core/hooks/useWebsiteDesignTokens.js';
+export * from './core/factories/define-website-section.js';
+export * from './core/factories/define-website-page-manifest.js';
+export * from './core/layouts/WebsitePageLayout.js';
+export * from './core/layouts/WebsiteSection.js';
+export * from './core/anonymous-session/website-anonymous-session-client.js';
+export * from './core/anonymous-session/inbound-contact-form.schema.js';
+export * from './core/anonymous-session/InboundContactForm.js';
+export * from './components/low-level/WebsiteHeading.js';
+export * from './components/low-level/WebsiteText.js';
+export * from './components/low-level/WebsiteLink.js';
+export * from './components/low-level/WebsiteInternalLink.js';
+export * from './core/routing/internal-routing.utils.js';
+export * from './components/low-level/WebsiteButton.js';
+export * from './components/low-level/WebsiteInternalButton.js';
+export * from './components/low-level/WebsiteImage.js';
+//# sourceMappingURL=index.js.map

package/dist/esm/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4FG;AAEH,cAAc,iCAAiC,CAAC;AAChD,cAAc,oCAAoC,CAAC;AACnD,cAAc,gDAAgD,CAAC;AAC/D,cAAc,oDAAoD,CAAC;AACnE,cAAc,8DAA8D,CAAC;AAC7E,cAAc,kEAAkE,CAAC;AACjF,cAAc,iEAAiE,CAAC;AAChF,cAAc,8DAA8D,CAAC;AAC7E,cAAc,0DAA0D,CAAC;AACzE,cAAc,wDAAwD,CAAC;AACvE,cAAc,qDAAqD,CAAC;AACpE,cAAc,2CAA2C,CAAC;AAE1D,cAAc,uCAAuC,CAAC;AACtD,cAAc,mCAAmC,CAAC;AAClD,cAAc,oCAAoC,CAAC;AACnD,cAAc,gCAAgC,CAAC;AAC/C,cAAc,uCAAuC,CAAC;AACtD,cAAc,mCAAmC,CAAC;AAClD,cAAc,8BAA8B,CAAC;AAC7C,cAAc,qCAAqC,CAAC;AACpD,cAAc,yCAAyC,CAAC;AACxD,cAAc,+CAA+C,CAAC;AAC9D,cAAc,kCAAkC,CAAC;AACjD,cAAc,+BAA+B,CAAC;AAE9C,cAAc,2DAA2D,CAAC;AAC1E,cAAc,sDAAsD,CAAC;AACrE,cAAc,6CAA6C,CAAC;AAE5D,cAAc,uCAAuC,CAAC;AACtD,cAAc,oCAAoC,CAAC;AACnD,cAAc,oCAAoC,CAAC;AACnD,cAAc,4CAA4C,CAAC;AAC3D,cAAc,uCAAuC,CAAC;AACtD,cAAc,sCAAsC,CAAC;AACrD,cAAc,8CAA8C,CAAC;AAC7D,cAAc,qCAAqC,CAAC","sourcesContent":["/**\n * @wildo-package @wildo-ai/saas-website\n *\n * SaaS marketing/landing website engine — schemas + helpers + layout\n * placeholders + Astro/MDX adapters + SEO/AEO/GEO builder library.\n *\n * Per `saas-website-slice.md` D6/D15: this engine ships **NO concrete\n * business sections** (no Hero, no CTA, no Pricing). It ships the\n * structural and helper machinery; consumers author every business\n * section themselves via the `defineWebsiteSection` factory and the\n * accompanying SKILLs in `framework-knowledge`.\n *\n * @wildo-boundary\n *   - This barrel MAY re-export from any subdirectory of `src/`.\n *   - Subdirectories MUST observe their own boundary contracts (see\n *     each subdirectory's own `index.ts` `@wildo-boundary` block):\n *       - `schemas/`            : NO React, NO Astro, NO `~wildo-frontend-lib/**`\n *       - `seo/`                : NO React, NO Astro\n *       - `core/`               : MAY use React; NO `~wildo-frontend-lib/**` (Q17=B)\n *       - `astro/`              : MAY use Astro; NO React component runtime imports\n *       - `mdx/`                : MAY use `@mdx-js/*`\n *       - `integration/`        : MAY use React; MAY import the\n *                                 `@wildo-ai/saas-models/public-runtime` SUBPATH,\n *                                 the `@wildo-ai/presets-components-models/public-runtime`\n *                                 SUBPATH, `@wildo-ai/zod-decorators`,\n *                                 plus the SSR / Astro-middleware tier\n *                                 (`axios`, `jsonwebtoken`, `socket.io-client`,\n *                                 `reflect-metadata`) — D12 revised\n *                                 2026-04-19 (second same-day loosening);\n *                                 the ROOT barrels of `@wildo-ai/saas-models`\n *                                 and `@wildo-ai/presets-components-models`\n *                                 are FORBIDDEN (they boot the decorator\n *                                 framework / pull the heavy registry);\n *                                 the saas-app DI / backend stack\n *                                 (`inversify`, `mongoose`, `express`,\n *                                 `pino`, `helmet`, `argon2`, `bcrypt`,\n *                                 the `@wildo-ai/saas-frontend-lib` /\n *                                 `@wildo-ai/saas-backend-lib` /\n *                                 `@wildo-ai/external-connectors-models`\n *                                 root + subpath surfaces) is FORBIDDEN;\n *                                 MUST NOT import `~wildo-frontend-lib/**`\n *                                 (Q17=B / D16)\n *\n *   D12 (client-bundle import discipline, all `core/`/`schemas/`/`integration/`\n *   files): the entire saas-website source tree ships into a browser bundle\n *   (Astro SSG + React islands). Every shared model atom MUST come from a\n *   side-effect-free `/public-runtime` subpath:\n *     - `@wildo-ai/saas-models/public-runtime` is the primary door\n *       (saas-models-public-runtime.md K-6 — consumers see one path).\n *     - `@wildo-ai/presets-components-models/public-runtime` is the\n *       internal seam for symbols not (yet) re-exported by saas-models.\n *     - `@wildo-ai/zod-decorators` is allowed to import (first revision\n *       2026-04-19). The package itself is side-effect-free; only an\n *       explicit `initZodDecorators()` call mutates `z.ZodType.prototype`,\n *       which neither saas-website nor the saas-models /public-runtime\n *       barrel does.\n *     - `axios`, `jsonwebtoken`, `socket.io-client`, `reflect-metadata` are\n *       allowed for SSR / Astro-middleware code paths (second same-day\n *       revision 2026-04-19). The website engine needs them to provide\n *       middleware utilities (HTTP proxying to the SaaS backend, JWT\n *       verification of cross-frontend handoff codes, real-time push,\n *       decorator-metadata reads). They are SSR-tier — discipline\n *       (and a future strict/loose entry split for React islands vs\n *       middleware) keeps them out of the React-island bundle.\n *\n *   The ROOT barrel of `@wildo-ai/saas-models` is forbidden everywhere in\n *   this package — it calls `initZodDecorators()` at module load and pulls\n *   `@wildo-ai/external-connectors-models` + the full schema graph into\n *   the bundle. Same forbid applies to the root barrel of\n *   `@wildo-ai/presets-components-models`, the saas-app DI runtime\n *   (`inversify`, `@wildo-ai/saas-frontend-lib`, `@wildo-ai/saas-backend-lib`),\n *   and pure-backend libs (`mongoose`, `express`, `pino`, `helmet`,\n *   `argon2`, `bcrypt`). Enforced by `src/__tests__/bundle-isolation.test.ts`.\n *\n *   These boundaries are enforced by review + the bundle-isolation test\n *   above until Phase 8 promotes them to a programmatic ESLint check\n *   (cf. `saas-website-slice.md`\n *   §\"DEFERRED to Phase 8 — boundary lint mechanism design\").\n *\n * Phase 1+2 status: schemas + runtime contexts/hooks + layout\n * primitives + L1 placeholders + factories are all exported. Phase 5\n * adds the Astro adapter; Phase 5.7 the `integration/` layer.\n *\n * D18 (L1 boundary, Phase 2): the L1 primitives (`WebsiteHeading`,\n * `WebsiteText`, `WebsiteButton`, `WebsiteLink`, `WebsiteImage`) are\n * self-contained placeholders — they do NOT consume\n * `ComponentRegistryService` from `saas-frontend-lib` and do NOT\n * re-export `saas-frontend-lib` primitives. Consumers override at the\n * L1 boundary by barrel-re-exporting their preferred styled variant\n * from their app's `app/website/primitives/<Primitive>.tsx`. Phase 6\n * dogfood will revisit and decide whether to promote a registry-based\n * override mechanism.\n */\n\nexport * from './schemas/refs/page-ref.schemas';\nexport * from './schemas/refs/section-ref.schemas';\nexport * from './schemas/label-keys/website-label-key.schemas';\nexport * from './schemas/sections/website-section-category.shared';\nexport * from './schemas/sections/website-section-definition.shared.schemas';\nexport * from './schemas/structured-data/website-structured-data.shared.schemas';\nexport * from './schemas/structured-data/structured-data-reconciliation.shared';\nexport * from './schemas/design-tokens/website-design-tokens.shared.schemas';\nexport * from './schemas/manifests/website-page-manifest.shared.schemas';\nexport * from './schemas/manifests/website-root-config.shared.schemas';\nexport * from './schemas/blog/blog-post-frontmatter.shared.schemas';\nexport * from './schemas/validators/label-pack.validator';\n\nexport * from './core/contexts/WebsiteRuntimeContext';\nexport * from './core/contexts/useWebsiteRuntime';\nexport * from './core/contexts/WebsitePageContext';\nexport * from './core/contexts/useWebsitePage';\nexport * from './core/contexts/WebsiteSectionContext';\nexport * from './core/contexts/useWebsiteSection';\nexport * from './core/hooks/useWebsiteLabel';\nexport * from './core/hooks/useWebsiteDesignTokens';\nexport * from './core/factories/define-website-section';\nexport * from './core/factories/define-website-page-manifest';\nexport * from './core/layouts/WebsitePageLayout';\nexport * from './core/layouts/WebsiteSection';\n\nexport * from './core/anonymous-session/website-anonymous-session-client';\nexport * from './core/anonymous-session/inbound-contact-form.schema';\nexport * from './core/anonymous-session/InboundContactForm';\n\nexport * from './components/low-level/WebsiteHeading';\nexport * from './components/low-level/WebsiteText';\nexport * from './components/low-level/WebsiteLink';\nexport * from './components/low-level/WebsiteInternalLink';\nexport * from './core/routing/internal-routing.utils';\nexport * from './components/low-level/WebsiteButton';\nexport * from './components/low-level/WebsiteInternalButton';\nexport * from './components/low-level/WebsiteImage';\n"]}

package/dist/esm/mdx/BlogPost.d.ts

@@ -0,0 +1,193 @@
+import type { ComponentType, ReactNode } from 'react';
+import type { WebsitePageRef } from '../schemas/refs/page-ref.schemas';
+import { type WebsiteMdxComponentsMap } from './website-mdx-provider';
+/**
+ * @wildo_source:part:start saas.website.blog.post-renderer facet:layer:mdx facet:family:website
+ *
+ * `<BlogPost>` — engine-owned per-post page renderer for the marketing
+ * blog adapter.
+ *
+ * # What it does, end-to-end
+ *
+ *   1. **Strict frontmatter parse.** Reads the raw `entry.data` Astro
+ *      hands the page (passthrough at the content-collection layer per
+ *      Path Z, see `blog-post-collection.config.ts`) and runs it
+ *      through `BlogPostFrontmatterSchema` (Zod 4) — branded `slug` /
+ *      `authorRef` / `tags`, ISO-8601 `publishedAt`, optional
+ *      `coverImageUrl`. A failure throws synchronously with a
+ *      `[blog-post] (source="…")` message; Astro halts the build and
+ *      points the operator to the offending MDX file.
+ *   2. **Renders `<WebsitePageLayout>` with a stable blog-post page
+ *      ref.** The framework reserves `'blog-post'` as the
+ *      `WebsitePageRef` for every blog post (see `BLOG_POST_PAGE_REF`
+ *      below for the rationale). All blog posts share one page ref
+ *      because the SECTION ref under that page is what's
+ *      blog-author-controlled (see point 3) — the page-level chrome,
+ *      label scope, and analytics signal are the same across the entire
+ *      blog surface.
+ *   3. **Wraps the MDX body in `<WebsiteMdxProvider>`.** The consumer
+ *      passes a `mdxComponents` map (typically containing one or two
+ *      business-section refs they want available inside post bodies —
+ *      `<CTASection ref="post-cta" />`, etc.). The provider scopes the
+ *      map for the duration of the render and ONLY the duration of the
+ *      render, so two blog posts on the same site can ship different
+ *      provider configs without leaking.
+ *   4. **Emits a hero block (title / summary / publish date / author
+ *      handle / cover image)** from the parsed frontmatter, then yields
+ *      to the MDX body. Hero markup is intentionally minimal — the
+ *      consumer styles it via `WebsiteDesignTokens` custom properties.
+ *      No CSS file ships from this component; everything is inline
+ *      style + design-token references.
+ *
+ * # Why a blog-specific page renderer (vs. the generic page bridge)
+ *
+ * The `createWebsitePageBridgeIsland` factory takes a `PageComponent`
+ * — a React component the page author writes. A blog post has NO React
+ * component; the MDX file IS the component (compiled by `@astrojs/mdx`
+ * to a default-export React tree). Reusing the page-bridge factory
+ * would force the consumer to write a ten-line wrapper per post that
+ * imports the MDX module, calls `<MdxBody />`, and re-passes the
+ * frontmatter — a cold violation of the "every blog post is one MDX
+ * file, period" principle. `<BlogPost>` is the framework's
+ * single ten-line wrapper, written once.
+ *
+ * # Why no per-post `pageRef` / per-section `sectionRef` knobs
+ *
+ * Two reasons:
+ *
+ *   - **Label-key scope semantics.** A blog post's body has no
+ *     framework-routed labels (the prose IS in the MDX). The section
+ *     refs that DO need labels are those an MDX file embeds via the
+ *     `mdxComponents` map — and those sections were already registered
+ *     in the consumer's `WEBSITE_SECTIONS` registry with their
+ *     own `expectedLabelKeys`. Letting blog authors pass arbitrary
+ *     `sectionRef`s would create unbounded label-key surface area that
+ *     `assertLabelPacksValid` cannot validate at build start.
+ *   - **Analytics + chrome consistency.** Marketing teams treat "the
+ *     blog" as one funnel. A single `pageRef='blog-post'` keeps the
+ *     `data-website-page-ref` attribute on the layout root constant
+ *     across every post, so the analytics ingest sees one blog-post
+ *     page event regardless of slug. Per-post overrides would fragment
+ *     this without buying any operator value.
+ *
+ * # Hydration + bundle boundary
+ *
+ * This component is NOT itself a Bridge factory — it's plain React
+ * meant to be rendered inside an Astro `.astro` page. The consumer's
+ * per-post Astro template (typically `src/pages/[locale]/blog/[slug].astro`)
+ * imports `<BlogPost>` directly and renders it; the surrounding
+ * `<WebsitePageBridgeIsland>` provides the runtime context. The MDX
+ * runtime (`@mdx-js/react`) is React-only and pulls into the React
+ * island bundle — bundle-isolation tests walk `mdx.ts` as their own
+ * entry to keep the browser-facing closure auditable.
+ *
+ * Authoring example:
+ *
+ * ```astro
+ * ---
+ * // src/pages/blog/[slug].astro
+ * import { getCollection, getEntry } from 'astro:content';
+ * import { BlogPost } from '@wildo-ai/saas-website/mdx';
+ * import { BLOG_POST_MDX_COMPONENTS } from '@/blog/mdx-components';
+ *
+ * export async function getStaticPaths() {
+ *   const posts = await getCollection('blog');
+ *   return posts
+ *     .filter((p) => p.data.locale === 'en')
+ *     .map((p) => ({ params: { slug: p.data.slug }, props: { entry: p } }));
+ * }
+ *
+ * const { entry } = Astro.props;
+ * const { Content } = await entry.render();
+ * ---
+ * <BlogPost
+ *   rawFrontmatter={entry.data}
+ *   source={entry.id}
+ *   mdxComponents={BLOG_POST_MDX_COMPONENTS}
+ *   client:load
+ * >
+ *   <Content />
+ * </BlogPost>
+ * ```
+ */
+/**
+ * Reserved `WebsitePageRef` for every blog post page. Exported so
+ * consumers can register a matching `BLOG_POST_PAGE_MANIFEST` in
+ * their site root config (the page manifest carries the navigation
+ * + label-pack scope; the renderer carries the structural layout).
+ *
+ * Branded as a plain string literal (cast through `unknown`) because:
+ *   - The `WebsitePageRef` brand is enforced via Zod's `.brand<>()`,
+ *     and parsing a string literal at module load time would require
+ *     dragging the Zod runtime into module init — gratuitous when the
+ *     ref is a compile-time constant.
+ *   - `WebsitePageLayout` re-parses any incoming `pageRef` string
+ *     defensively (see `WebsitePageLayoutProps.pageRef` JSDoc), so the
+ *     brand is re-asserted at render time anyway.
+ */
+export declare const BLOG_POST_PAGE_REF: WebsitePageRef;
+export interface BlogPostProps {
+    /**
+     * Raw frontmatter object Astro hands the page from `entry.data` (or
+     * equivalent). The renderer validates this through
+     * `BlogPostFrontmatterSchema` synchronously — invalid shapes throw
+     * with a `[blog-post]`-prefixed message. Pass `entry.data` directly;
+     * do NOT pre-parse on the consumer side (the framework owns the
+     * validation surface so a future schema change lands in ONE place).
+     */
+    rawFrontmatter: unknown;
+    /**
+     * Diagnostic source identifier echoed into validation errors —
+     * typically `entry.id` from Astro's content collection (`'en/why-context.mdx'`
+     * or similar). Optional but strongly recommended; without it,
+     * `parseBlogPostFrontmatter` throws with a generic
+     * `[blog-post] Frontmatter failed …` message that does not name the
+     * offending file.
+     */
+    source?: string;
+    /**
+     * MDX-tag → React-component map made available inside the post
+     * body via `<WebsiteMdxProvider>`. Typically a small object literal
+     * exporting one or two business sections the consumer wants
+     * available everywhere in the blog surface
+     * (`<CTASection ref="post-cta" />`, `<NewsletterSignup />`, etc.).
+     *
+     * Empty maps are valid — a post body using only standard markdown
+     * (no embedded React) needs no overrides.
+     */
+    mdxComponents?: WebsiteMdxComponentsMap;
+    /**
+     * Per-page chrome overrides forwarded straight into
+     * `<WebsitePageLayout>`. `null` suppresses the slot entirely;
+     * `undefined` (the default) inherits the runtime navigation
+     * config's header/footer components. Most blog posts leave both
+     * unset to inherit the site-wide chrome.
+     */
+    header?: ReactNode | null;
+    footer?: ReactNode | null;
+    /**
+     * The compiled MDX body — typically `<Content />` from Astro's
+     * `await entry.render()` call. Rendered inside the
+     * `<WebsiteMdxProvider>` boundary so its inline `<TagName />`
+     * references resolve against `mdxComponents`.
+     */
+    children: ReactNode;
+}
+export declare function BlogPost(props: BlogPostProps): ReactNode;
+export declare namespace BlogPost {
+    var displayName: string;
+}
+/**
+ * Type alias re-export so consumers writing `BLOG_POST_MDX_COMPONENTS:
+ * BlogPostMdxComponents = { … }` have a stable name (the underlying
+ * type is the same `WebsiteMdxComponentsMap` from the provider).
+ */
+export type BlogPostMdxComponents = WebsiteMdxComponentsMap;
+/**
+ * Convenience type — the Astro `ComponentType` consumers write inline
+ * inside a `mdxComponents` map. Re-exported so consumer authoring
+ * doesn't need to import from `react` directly.
+ */
+export type BlogPostMdxComponent = ComponentType<any>;
+/** @wildo_source:part:end saas.website.blog.post-renderer */
+//# sourceMappingURL=BlogPost.d.ts.map

package/dist/esm/mdx/BlogPost.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"BlogPost.d.ts","sourceRoot":"","sources":["../../../../src/mdx/BlogPost.tsx"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAE,SAAS,EAAE,MAAM,OAAO,CAAC;AAGtD,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,kCAAkC,CAAC;AAMvE,OAAO,EAEL,KAAK,uBAAuB,EAC7B,MAAM,wBAAwB,CAAC;AAEhC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4GG;AAEH;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,kBAAkB,EAAE,cAAyD,CAAC;AAE3F,MAAM,WAAW,aAAa;IAC5B;;;;;;;OAOG;IACH,cAAc,EAAE,OAAO,CAAC;IACxB;;;;;;;OAOG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB;;;;;;;;;OASG;IACH,aAAa,CAAC,EAAE,uBAAuB,CAAC;IACxC;;;;;;OAMG;IACH,MAAM,CAAC,EAAE,SAAS,GAAG,IAAI,CAAC;IAC1B,MAAM,CAAC,EAAE,SAAS,GAAG,IAAI,CAAC;IAC1B;;;;;OAKG;IACH,QAAQ,EAAE,SAAS,CAAC;CACrB;AAWD,wBAAgB,QAAQ,CAAC,KAAK,EAAE,aAAa,GAAG,SAAS,CAiFxD;yBAjFe,QAAQ;;;AAoFxB;;;;GAIG;AACH,MAAM,MAAM,qBAAqB,GAAG,uBAAuB,CAAC;AAE5D;;;;GAIG;AACH,MAAM,MAAM,oBAAoB,GAAG,aAAa,CAAC,GAAG,CAAC,CAAC;AACtD,6DAA6D"}

package/dist/esm/mdx/BlogPost.js

@@ -0,0 +1,161 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { WebsitePageLayout } from '../core/layouts/WebsitePageLayout.js';
+import { parseBlogPostFrontmatter, } from './blog-post-collection.config.js';
+import { WebsiteMdxProvider, } from './website-mdx-provider.js';
+/**
+ * @wildo_source:part:start saas.website.blog.post-renderer facet:layer:mdx facet:family:website
+ *
+ * `<BlogPost>` — engine-owned per-post page renderer for the marketing
+ * blog adapter.
+ *
+ * # What it does, end-to-end
+ *
+ *   1. **Strict frontmatter parse.** Reads the raw `entry.data` Astro
+ *      hands the page (passthrough at the content-collection layer per
+ *      Path Z, see `blog-post-collection.config.ts`) and runs it
+ *      through `BlogPostFrontmatterSchema` (Zod 4) — branded `slug` /
+ *      `authorRef` / `tags`, ISO-8601 `publishedAt`, optional
+ *      `coverImageUrl`. A failure throws synchronously with a
+ *      `[blog-post] (source="…")` message; Astro halts the build and
+ *      points the operator to the offending MDX file.
+ *   2. **Renders `<WebsitePageLayout>` with a stable blog-post page
+ *      ref.** The framework reserves `'blog-post'` as the
+ *      `WebsitePageRef` for every blog post (see `BLOG_POST_PAGE_REF`
+ *      below for the rationale). All blog posts share one page ref
+ *      because the SECTION ref under that page is what's
+ *      blog-author-controlled (see point 3) — the page-level chrome,
+ *      label scope, and analytics signal are the same across the entire
+ *      blog surface.
+ *   3. **Wraps the MDX body in `<WebsiteMdxProvider>`.** The consumer
+ *      passes a `mdxComponents` map (typically containing one or two
+ *      business-section refs they want available inside post bodies —
+ *      `<CTASection ref="post-cta" />`, etc.). The provider scopes the
+ *      map for the duration of the render and ONLY the duration of the
+ *      render, so two blog posts on the same site can ship different
+ *      provider configs without leaking.
+ *   4. **Emits a hero block (title / summary / publish date / author
+ *      handle / cover image)** from the parsed frontmatter, then yields
+ *      to the MDX body. Hero markup is intentionally minimal — the
+ *      consumer styles it via `WebsiteDesignTokens` custom properties.
+ *      No CSS file ships from this component; everything is inline
+ *      style + design-token references.
+ *
+ * # Why a blog-specific page renderer (vs. the generic page bridge)
+ *
+ * The `createWebsitePageBridgeIsland` factory takes a `PageComponent`
+ * — a React component the page author writes. A blog post has NO React
+ * component; the MDX file IS the component (compiled by `@astrojs/mdx`
+ * to a default-export React tree). Reusing the page-bridge factory
+ * would force the consumer to write a ten-line wrapper per post that
+ * imports the MDX module, calls `<MdxBody />`, and re-passes the
+ * frontmatter — a cold violation of the "every blog post is one MDX
+ * file, period" principle. `<BlogPost>` is the framework's
+ * single ten-line wrapper, written once.
+ *
+ * # Why no per-post `pageRef` / per-section `sectionRef` knobs
+ *
+ * Two reasons:
+ *
+ *   - **Label-key scope semantics.** A blog post's body has no
+ *     framework-routed labels (the prose IS in the MDX). The section
+ *     refs that DO need labels are those an MDX file embeds via the
+ *     `mdxComponents` map — and those sections were already registered
+ *     in the consumer's `WEBSITE_SECTIONS` registry with their
+ *     own `expectedLabelKeys`. Letting blog authors pass arbitrary
+ *     `sectionRef`s would create unbounded label-key surface area that
+ *     `assertLabelPacksValid` cannot validate at build start.
+ *   - **Analytics + chrome consistency.** Marketing teams treat "the
+ *     blog" as one funnel. A single `pageRef='blog-post'` keeps the
+ *     `data-website-page-ref` attribute on the layout root constant
+ *     across every post, so the analytics ingest sees one blog-post
+ *     page event regardless of slug. Per-post overrides would fragment
+ *     this without buying any operator value.
+ *
+ * # Hydration + bundle boundary
+ *
+ * This component is NOT itself a Bridge factory — it's plain React
+ * meant to be rendered inside an Astro `.astro` page. The consumer's
+ * per-post Astro template (typically `src/pages/[locale]/blog/[slug].astro`)
+ * imports `<BlogPost>` directly and renders it; the surrounding
+ * `<WebsitePageBridgeIsland>` provides the runtime context. The MDX
+ * runtime (`@mdx-js/react`) is React-only and pulls into the React
+ * island bundle — bundle-isolation tests walk `mdx.ts` as their own
+ * entry to keep the browser-facing closure auditable.
+ *
+ * Authoring example:
+ *
+ * ```astro
+ * ---
+ * // src/pages/blog/[slug].astro
+ * import { getCollection, getEntry } from 'astro:content';
+ * import { BlogPost } from '@wildo-ai/saas-website/mdx';
+ * import { BLOG_POST_MDX_COMPONENTS } from '@/blog/mdx-components';
+ *
+ * export async function getStaticPaths() {
+ *   const posts = await getCollection('blog');
+ *   return posts
+ *     .filter((p) => p.data.locale === 'en')
+ *     .map((p) => ({ params: { slug: p.data.slug }, props: { entry: p } }));
+ * }
+ *
+ * const { entry } = Astro.props;
+ * const { Content } = await entry.render();
+ * ---
+ * <BlogPost
+ *   rawFrontmatter={entry.data}
+ *   source={entry.id}
+ *   mdxComponents={BLOG_POST_MDX_COMPONENTS}
+ *   client:load
+ * >
+ *   <Content />
+ * </BlogPost>
+ * ```
+ */
+/**
+ * Reserved `WebsitePageRef` for every blog post page. Exported so
+ * consumers can register a matching `BLOG_POST_PAGE_MANIFEST` in
+ * their site root config (the page manifest carries the navigation
+ * + label-pack scope; the renderer carries the structural layout).
+ *
+ * Branded as a plain string literal (cast through `unknown`) because:
+ *   - The `WebsitePageRef` brand is enforced via Zod's `.brand<>()`,
+ *     and parsing a string literal at module load time would require
+ *     dragging the Zod runtime into module init — gratuitous when the
+ *     ref is a compile-time constant.
+ *   - `WebsitePageLayout` re-parses any incoming `pageRef` string
+ *     defensively (see `WebsitePageLayoutProps.pageRef` JSDoc), so the
+ *     brand is re-asserted at render time anyway.
+ */
+export const BLOG_POST_PAGE_REF = 'blog-post';
+/**
+ * Empty default for `mdxComponents` — defined at module scope (NOT
+ * inline in the destructure default) so the object identity is
+ * stable across re-renders. Stable identity matters here because
+ * `<MDXProvider>`'s internal context value is `useMemo`-derived from
+ * the `components` prop; inline `{}` would invalidate every render.
+ */
+const EMPTY_MDX_COMPONENTS = Object.freeze({});
+export function BlogPost(props) {
+    const { rawFrontmatter, source, mdxComponents = EMPTY_MDX_COMPONENTS, header, footer, children, } = props;
+    /**
+     * Build the diagnostic context once per render. We do not memoize
+     * (one object literal per render is cheaper than the `useMemo`
+     * accounting), but we also do not pass `source: undefined`
+     * unconditionally because `parseBlogPostFrontmatter` switches on
+     * `ctx.source !== undefined` for the error-suffix; passing `{}`
+     * when undefined keeps the suffix absent in that case.
+     */
+    const parseCtx = source !== undefined ? { source } : {};
+    const frontmatter = parseBlogPostFrontmatter(rawFrontmatter, parseCtx);
+    /**
+     * The hero markup intentionally uses semantic HTML5 elements
+     * (`<header>`, `<h1>`, `<time>`, `<address>`) rather than raw
+     * `<div>`s so screen readers and crawlers see the post structure
+     * without consumer styling intervention. The styling story is:
+     * design tokens via the surrounding `WebsiteRuntimeContext` +
+     * the consumer's stylesheet — NO CSS ships from this file.
+     */
+    return (_jsx(WebsitePageLayout, { pageRef: BLOG_POST_PAGE_REF, header: header, footer: footer, children: _jsxs("article", { "data-website-blog-post-slug": frontmatter.slug, children: [_jsxs("header", { children: [frontmatter.coverImageUrl !== undefined ? (_jsx("img", { src: frontmatter.coverImageUrl, alt: "", loading: "eager", "data-website-blog-post-cover": true })) : null, _jsx("h1", { children: frontmatter.title }), _jsx("p", { "data-website-blog-post-summary": true, children: frontmatter.summary }), _jsxs("div", { "data-website-blog-post-meta": true, children: [_jsx("time", { dateTime: frontmatter.publishedAt, children: frontmatter.publishedAt }), ' · ', _jsx("address", { "data-website-blog-post-author": true, children: frontmatter.authorRef })] }), frontmatter.tags.length > 0 ? (_jsx("ul", { "data-website-blog-post-tags": true, children: frontmatter.tags.map((tag) => (_jsx("li", { children: tag }, tag))) })) : null] }), _jsx(WebsiteMdxProvider, { components: mdxComponents, children: children })] }) }));
+}
+BlogPost.displayName = 'BlogPost';
+//# sourceMappingURL=BlogPost.js.map

package/dist/esm/mdx/BlogPost.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"BlogPost.js","sourceRoot":"","sources":["../../../../src/mdx/BlogPost.tsx"],"names":[],"mappings":";AAEA,OAAO,EAAE,iBAAiB,EAAE,MAAM,mCAAmC,CAAC;AAGtE,OAAO,EACL,wBAAwB,GAEzB,MAAM,+BAA+B,CAAC;AACvC,OAAO,EACL,kBAAkB,GAEnB,MAAM,wBAAwB,CAAC;AAEhC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4GG;AAEH;;;;;;;;;;;;;;GAcG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAmB,WAAwC,CAAC;AAkD3F;;;;;;GAMG;AACH,MAAM,oBAAoB,GAA4B,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;AAExE,MAAM,UAAU,QAAQ,CAAC,KAAoB;IAC3C,MAAM,EACJ,cAAc,EACd,MAAM,EACN,aAAa,GAAG,oBAAoB,EACpC,MAAM,EACN,MAAM,EACN,QAAQ,GACT,GAAG,KAAK,CAAC;IAEV;;;;;;;OAOG;IACH,MAAM,QAAQ,GACZ,MAAM,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;IACzC,MAAM,WAAW,GAAG,wBAAwB,CAAC,cAAc,EAAE,QAAQ,CAAC,CAAC;IAEvE;;;;;;;OAOG;IACH,OAAO,CACL,KAAC,iBAAiB,IAChB,OAAO,EAAE,kBAAkB,EAC3B,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,YAEd,kDAAsC,WAAW,CAAC,IAAyB,aACzE,6BACG,WAAW,CAAC,aAAa,KAAK,SAAS,CAAC,CAAC,CAAC,CACzC,cACE,GAAG,EAAE,WAAW,CAAC,aAAa,EAC9B,GAAG,EAAC,EAAE,EACN,OAAO,EAAC,OAAO,yCAEf,CACH,CAAC,CAAC,CAAC,IAAI,EACR,uBAAK,WAAW,CAAC,KAAK,GAAM,EAC5B,8DAAmC,WAAW,CAAC,OAAO,GAAK,EAS3D,+DACE,eAAM,QAAQ,EAAE,WAAW,CAAC,WAAW,YACpC,WAAW,CAAC,WAAW,GACnB,EACN,KAAK,EACN,mEACG,WAAW,CAAC,SAA8B,GACnC,IACN,EACL,WAAW,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,CAC7B,4DACG,WAAW,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,GAAG,EAAE,EAAE,CAAC,CAC7B,uBACG,GAAwB,IADlB,GAAwB,CAE5B,CACN,CAAC,GACC,CACN,CAAC,CAAC,CAAC,IAAI,IACD,EACT,KAAC,kBAAkB,IAAC,UAAU,EAAE,aAAa,YAC1C,QAAQ,GACU,IACb,GACQ,CACrB,CAAC;AACJ,CAAC;AACD,QAAQ,CAAC,WAAW,GAAG,UAAU,CAAC","sourcesContent":["import type { ComponentType, ReactNode } from 'react';\n\nimport { WebsitePageLayout } from '../core/layouts/WebsitePageLayout';\nimport type { WebsitePageRef } from '../schemas/refs/page-ref.schemas';\n\nimport {\n  parseBlogPostFrontmatter,\n  type ParseBlogPostFrontmatterContext,\n} from './blog-post-collection.config';\nimport {\n  WebsiteMdxProvider,\n  type WebsiteMdxComponentsMap,\n} from './website-mdx-provider';\n\n/**\n * @wildo_source:part:start saas.website.blog.post-renderer facet:layer:mdx facet:family:website\n *\n * `<BlogPost>` — engine-owned per-post page renderer for the marketing\n * blog adapter.\n *\n * # What it does, end-to-end\n *\n *   1. **Strict frontmatter parse.** Reads the raw `entry.data` Astro\n *      hands the page (passthrough at the content-collection layer per\n *      Path Z, see `blog-post-collection.config.ts`) and runs it\n *      through `BlogPostFrontmatterSchema` (Zod 4) — branded `slug` /\n *      `authorRef` / `tags`, ISO-8601 `publishedAt`, optional\n *      `coverImageUrl`. A failure throws synchronously with a\n *      `[blog-post] (source=\"…\")` message; Astro halts the build and\n *      points the operator to the offending MDX file.\n *   2. **Renders `<WebsitePageLayout>` with a stable blog-post page\n *      ref.** The framework reserves `'blog-post'` as the\n *      `WebsitePageRef` for every blog post (see `BLOG_POST_PAGE_REF`\n *      below for the rationale). All blog posts share one page ref\n *      because the SECTION ref under that page is what's\n *      blog-author-controlled (see point 3) — the page-level chrome,\n *      label scope, and analytics signal are the same across the entire\n *      blog surface.\n *   3. **Wraps the MDX body in `<WebsiteMdxProvider>`.** The consumer\n *      passes a `mdxComponents` map (typically containing one or two\n *      business-section refs they want available inside post bodies —\n *      `<CTASection ref=\"post-cta\" />`, etc.). The provider scopes the\n *      map for the duration of the render and ONLY the duration of the\n *      render, so two blog posts on the same site can ship different\n *      provider configs without leaking.\n *   4. **Emits a hero block (title / summary / publish date / author\n *      handle / cover image)** from the parsed frontmatter, then yields\n *      to the MDX body. Hero markup is intentionally minimal — the\n *      consumer styles it via `WebsiteDesignTokens` custom properties.\n *      No CSS file ships from this component; everything is inline\n *      style + design-token references.\n *\n * # Why a blog-specific page renderer (vs. the generic page bridge)\n *\n * The `createWebsitePageBridgeIsland` factory takes a `PageComponent`\n * — a React component the page author writes. A blog post has NO React\n * component; the MDX file IS the component (compiled by `@astrojs/mdx`\n * to a default-export React tree). Reusing the page-bridge factory\n * would force the consumer to write a ten-line wrapper per post that\n * imports the MDX module, calls `<MdxBody />`, and re-passes the\n * frontmatter — a cold violation of the \"every blog post is one MDX\n * file, period\" principle. `<BlogPost>` is the framework's\n * single ten-line wrapper, written once.\n *\n * # Why no per-post `pageRef` / per-section `sectionRef` knobs\n *\n * Two reasons:\n *\n *   - **Label-key scope semantics.** A blog post's body has no\n *     framework-routed labels (the prose IS in the MDX). The section\n *     refs that DO need labels are those an MDX file embeds via the\n *     `mdxComponents` map — and those sections were already registered\n *     in the consumer's `WEBSITE_SECTIONS` registry with their\n *     own `expectedLabelKeys`. Letting blog authors pass arbitrary\n *     `sectionRef`s would create unbounded label-key surface area that\n *     `assertLabelPacksValid` cannot validate at build start.\n *   - **Analytics + chrome consistency.** Marketing teams treat \"the\n *     blog\" as one funnel. A single `pageRef='blog-post'` keeps the\n *     `data-website-page-ref` attribute on the layout root constant\n *     across every post, so the analytics ingest sees one blog-post\n *     page event regardless of slug. Per-post overrides would fragment\n *     this without buying any operator value.\n *\n * # Hydration + bundle boundary\n *\n * This component is NOT itself a Bridge factory — it's plain React\n * meant to be rendered inside an Astro `.astro` page. The consumer's\n * per-post Astro template (typically `src/pages/[locale]/blog/[slug].astro`)\n * imports `<BlogPost>` directly and renders it; the surrounding\n * `<WebsitePageBridgeIsland>` provides the runtime context. The MDX\n * runtime (`@mdx-js/react`) is React-only and pulls into the React\n * island bundle — bundle-isolation tests walk `mdx.ts` as their own\n * entry to keep the browser-facing closure auditable.\n *\n * Authoring example:\n *\n * ```astro\n * ---\n * // src/pages/blog/[slug].astro\n * import { getCollection, getEntry } from 'astro:content';\n * import { BlogPost } from '@wildo-ai/saas-website/mdx';\n * import { BLOG_POST_MDX_COMPONENTS } from '@/blog/mdx-components';\n *\n * export async function getStaticPaths() {\n *   const posts = await getCollection('blog');\n *   return posts\n *     .filter((p) => p.data.locale === 'en')\n *     .map((p) => ({ params: { slug: p.data.slug }, props: { entry: p } }));\n * }\n *\n * const { entry } = Astro.props;\n * const { Content } = await entry.render();\n * ---\n * <BlogPost\n *   rawFrontmatter={entry.data}\n *   source={entry.id}\n *   mdxComponents={BLOG_POST_MDX_COMPONENTS}\n *   client:load\n * >\n *   <Content />\n * </BlogPost>\n * ```\n */\n\n/**\n * Reserved `WebsitePageRef` for every blog post page. Exported so\n * consumers can register a matching `BLOG_POST_PAGE_MANIFEST` in\n * their site root config (the page manifest carries the navigation\n * + label-pack scope; the renderer carries the structural layout).\n *\n * Branded as a plain string literal (cast through `unknown`) because:\n *   - The `WebsitePageRef` brand is enforced via Zod's `.brand<>()`,\n *     and parsing a string literal at module load time would require\n *     dragging the Zod runtime into module init — gratuitous when the\n *     ref is a compile-time constant.\n *   - `WebsitePageLayout` re-parses any incoming `pageRef` string\n *     defensively (see `WebsitePageLayoutProps.pageRef` JSDoc), so the\n *     brand is re-asserted at render time anyway.\n */\nexport const BLOG_POST_PAGE_REF: WebsitePageRef = 'blog-post' as unknown as WebsitePageRef;\n\nexport interface BlogPostProps {\n  /**\n   * Raw frontmatter object Astro hands the page from `entry.data` (or\n   * equivalent). The renderer validates this through\n   * `BlogPostFrontmatterSchema` synchronously — invalid shapes throw\n   * with a `[blog-post]`-prefixed message. Pass `entry.data` directly;\n   * do NOT pre-parse on the consumer side (the framework owns the\n   * validation surface so a future schema change lands in ONE place).\n   */\n  rawFrontmatter: unknown;\n  /**\n   * Diagnostic source identifier echoed into validation errors —\n   * typically `entry.id` from Astro's content collection (`'en/why-context.mdx'`\n   * or similar). Optional but strongly recommended; without it,\n   * `parseBlogPostFrontmatter` throws with a generic\n   * `[blog-post] Frontmatter failed …` message that does not name the\n   * offending file.\n   */\n  source?: string;\n  /**\n   * MDX-tag → React-component map made available inside the post\n   * body via `<WebsiteMdxProvider>`. Typically a small object literal\n   * exporting one or two business sections the consumer wants\n   * available everywhere in the blog surface\n   * (`<CTASection ref=\"post-cta\" />`, `<NewsletterSignup />`, etc.).\n   *\n   * Empty maps are valid — a post body using only standard markdown\n   * (no embedded React) needs no overrides.\n   */\n  mdxComponents?: WebsiteMdxComponentsMap;\n  /**\n   * Per-page chrome overrides forwarded straight into\n   * `<WebsitePageLayout>`. `null` suppresses the slot entirely;\n   * `undefined` (the default) inherits the runtime navigation\n   * config's header/footer components. Most blog posts leave both\n   * unset to inherit the site-wide chrome.\n   */\n  header?: ReactNode | null;\n  footer?: ReactNode | null;\n  /**\n   * The compiled MDX body — typically `<Content />` from Astro's\n   * `await entry.render()` call. Rendered inside the\n   * `<WebsiteMdxProvider>` boundary so its inline `<TagName />`\n   * references resolve against `mdxComponents`.\n   */\n  children: ReactNode;\n}\n\n/**\n * Empty default for `mdxComponents` — defined at module scope (NOT\n * inline in the destructure default) so the object identity is\n * stable across re-renders. Stable identity matters here because\n * `<MDXProvider>`'s internal context value is `useMemo`-derived from\n * the `components` prop; inline `{}` would invalidate every render.\n */\nconst EMPTY_MDX_COMPONENTS: WebsiteMdxComponentsMap = Object.freeze({});\n\nexport function BlogPost(props: BlogPostProps): ReactNode {\n  const {\n    rawFrontmatter,\n    source,\n    mdxComponents = EMPTY_MDX_COMPONENTS,\n    header,\n    footer,\n    children,\n  } = props;\n\n  /**\n   * Build the diagnostic context once per render. We do not memoize\n   * (one object literal per render is cheaper than the `useMemo`\n   * accounting), but we also do not pass `source: undefined`\n   * unconditionally because `parseBlogPostFrontmatter` switches on\n   * `ctx.source !== undefined` for the error-suffix; passing `{}`\n   * when undefined keeps the suffix absent in that case.\n   */\n  const parseCtx: ParseBlogPostFrontmatterContext =\n    source !== undefined ? { source } : {};\n  const frontmatter = parseBlogPostFrontmatter(rawFrontmatter, parseCtx);\n\n  /**\n   * The hero markup intentionally uses semantic HTML5 elements\n   * (`<header>`, `<h1>`, `<time>`, `<address>`) rather than raw\n   * `<div>`s so screen readers and crawlers see the post structure\n   * without consumer styling intervention. The styling story is:\n   * design tokens via the surrounding `WebsiteRuntimeContext` +\n   * the consumer's stylesheet — NO CSS ships from this file.\n   */\n  return (\n    <WebsitePageLayout\n      pageRef={BLOG_POST_PAGE_REF}\n      header={header}\n      footer={footer}\n    >\n      <article data-website-blog-post-slug={frontmatter.slug as unknown as string}>\n        <header>\n          {frontmatter.coverImageUrl !== undefined ? (\n            <img\n              src={frontmatter.coverImageUrl}\n              alt=\"\"\n              loading=\"eager\"\n              data-website-blog-post-cover\n            />\n          ) : null}\n          <h1>{frontmatter.title}</h1>\n          <p data-website-blog-post-summary>{frontmatter.summary}</p>\n          {/*\n           * Meta line is a `<div>`, not a `<p>` — `<address>` is a flow-\n           * content element and cannot be a descendant of `<p>` per HTML5\n           * (browsers auto-close the `<p>` on `<address>`, which produces\n           * a hydration mismatch in React 19). The `<div>` keeps the\n           * semantic `<time>` + `<address>` landmarks intact for screen\n           * readers + crawlers without violating the parsing rules.\n           */}\n          <div data-website-blog-post-meta>\n            <time dateTime={frontmatter.publishedAt}>\n              {frontmatter.publishedAt}\n            </time>\n            {' · '}\n            <address data-website-blog-post-author>\n              {frontmatter.authorRef as unknown as string}\n            </address>\n          </div>\n          {frontmatter.tags.length > 0 ? (\n            <ul data-website-blog-post-tags>\n              {frontmatter.tags.map((tag) => (\n                <li key={tag as unknown as string}>\n                  {tag as unknown as string}\n                </li>\n              ))}\n            </ul>\n          ) : null}\n        </header>\n        <WebsiteMdxProvider components={mdxComponents}>\n          {children}\n        </WebsiteMdxProvider>\n      </article>\n    </WebsitePageLayout>\n  );\n}\nBlogPost.displayName = 'BlogPost';\n\n/**\n * Type alias re-export so consumers writing `BLOG_POST_MDX_COMPONENTS:\n * BlogPostMdxComponents = { … }` have a stable name (the underlying\n * type is the same `WebsiteMdxComponentsMap` from the provider).\n */\nexport type BlogPostMdxComponents = WebsiteMdxComponentsMap;\n\n/**\n * Convenience type — the Astro `ComponentType` consumers write inline\n * inside a `mdxComponents` map. Re-exported so consumer authoring\n * doesn't need to import from `react` directly.\n */\nexport type BlogPostMdxComponent = ComponentType<any>;\n/** @wildo_source:part:end saas.website.blog.post-renderer */\n"]}