@wildo-ai/saas-website 1.1.1

package/dist/esm/mdx/blog-post-collection.config.d.ts

@@ -0,0 +1,139 @@
+import { type BlogPostFrontmatter } from '../schemas/blog/blog-post-frontmatter.shared.schemas';
+/**
+ * @wildo_source:part:start saas.website.blog.collection-config facet:layer:mdx facet:family:website
+ *
+ * Astro content-collection bridge for blog posts (Phase 7 D-3 = Path Z).
+ *
+ * # The Zod-version bridge problem
+ *
+ * Astro's `astro:content` ships its own bundled Zod (currently 3.x).
+ * Our `BlogPostFrontmatterSchema` is Zod 4 and uses Zod-4-only APIs
+ * (`z.iso.datetime`, `z.url(...)`, `.brand<>()`). The two cannot share
+ * a schema instance directly across the version boundary, and shimming
+ * a Zod 4 schema down to a Zod 3 schema would create either:
+ *
+ *   - a hand-mirrored copy (Path X) — maintained in `src/content/config.ts`
+ *     using Astro's `z`, with silent-drift risk every time a field is
+ *     added/removed/refined; or
+ *   - a runtime bridge package (Path C) — a non-trivial maintenance
+ *     surface for a marginal gain.
+ *
+ * Path Z (this file) sidesteps the bridge entirely: the consumer's
+ * `src/content/config.ts` declares a `passthrough` collection schema
+ * that lets Astro accept any frontmatter shape; the engine then
+ * validates with the canonical Zod 4 schema at render time inside
+ * `<BlogPost>`. Astro's static site generator runs the page render
+ * during the build, so a malformed frontmatter still surfaces as a
+ * BUILD-TIME error (the `.parse()` call throws synchronously and Astro
+ * reports it with the page URL) — the only practical difference vs.
+ * Path X is the error-message stack location.
+ *
+ * # Why the engine ships an opaque shape (rather than the consumer
+ *   importing the Astro `z` directly)
+ *
+ * Astro's content-collection API has churned across Astro 4 → 5
+ * (loaders moved from string-keyed `type` to a callable `loader`
+ * factory; the `glob()` loader's signature changed). Every consumer
+ * touching `defineCollection` directly inherits that churn; centralizing
+ * the wiring in the engine means the framework absorbs the upgrade
+ * cost in ONE place when Astro bumps a major.
+ *
+ * The shape returned here is `{ schema: <passthrough record> }`. The
+ * consumer spreads it into their `defineCollection` call:
+ *
+ * ```ts
+ * // examples/<app>/website/src/content/config.ts
+ * import { defineCollection, z } from 'astro:content';
+ * import { buildBlogPostCollectionConfig } from '@wildo-ai/saas-website/mdx';
+ *
+ * export const collections = {
+ *   blog: defineCollection({
+ *     type: 'content',
+ *     ...buildBlogPostCollectionConfig({ astroZ: z }),
+ *   }),
+ * };
+ * ```
+ *
+ * The consumer passes Astro's own `z` in (because the engine cannot
+ * import `astro:content` — that virtual module only exists inside
+ * the Astro build context, never at the engine package's compile
+ * time, and importing it would also pull `astro` into the engine's
+ * walked closure which the bundle-isolation test forbids). The engine
+ * builds a passthrough `z.object({}).passthrough()` from the supplied
+ * factory and returns the schema slot.
+ *
+ * # `parseBlogPostFrontmatter`
+ *
+ * Companion render-time validator. Called at the top of `<BlogPost>`
+ * with the raw `entry.data` Astro hands the page; returns the
+ * branded, validated `BlogPostFrontmatter` (Zod 4) or throws with
+ * the standard Zod-4 issue formatting + a `[blog-post]` prefix that
+ * tells the SSG operator which file to fix.
+ *
+ * # Boundary
+ *
+ * This file is React-runtime-safe: it only imports the (also
+ * React-safe) `BlogPostFrontmatterSchema` from `schemas/blog/`. It
+ * ships into the React-island bundle via the `mdx.ts` barrel, which
+ * the bundle-isolation test walks as a dedicated entry. Helpers that
+ * parse raw MDX source live in `blog-post-frontmatter-source.ts` so the
+ * `yaml` package stays on the build-time/Node side of the boundary.
+ */
+/**
+ * Minimal contract for the Astro-side Zod factory we accept. Typed
+ * structurally (rather than imported from `astro:content`) so the
+ * engine package can compile/test without an Astro install. Astro's
+ * actual `z.object` returns a much richer Zod-3 schema; we narrow to
+ * just the `.passthrough()` call we make below.
+ */
+export interface AstroZodFactoryShape {
+    object: (shape: Record<string, never>) => {
+        passthrough: () => unknown;
+    };
+}
+export interface BuildBlogPostCollectionConfigOptions {
+    /**
+     * Astro's bundled `z` object — pass `import { z } from 'astro:content'`
+     * from the consumer-side `src/content/config.ts`. The engine cannot
+     * import `astro:content` itself (virtual module, only present inside
+     * the Astro build pipeline; would also bloat the bundle-isolation
+     * walked closure with the `astro` runtime).
+     */
+    astroZ: AstroZodFactoryShape;
+}
+export interface BlogPostCollectionConfigShape {
+    /**
+     * The schema slot consumed by Astro's `defineCollection({...})`.
+     * A `passthrough` record (no field constraints at this layer) so
+     * Astro accepts any frontmatter; the strict Zod-4 validation runs
+     * at render time inside `<BlogPost>` via
+     * `parseBlogPostFrontmatter(...)`.
+     */
+    schema: unknown;
+}
+export declare function buildBlogPostCollectionConfig(opts: BuildBlogPostCollectionConfigOptions): BlogPostCollectionConfigShape;
+/**
+ * Strict Zod-4 validator for blog-post frontmatter. Called at the top
+ * of `<BlogPost>` rendering against `entry.data` (whatever Astro's
+ * passthrough collection schema accepted). Throws on validation
+ * failure with a `[blog-post]`-prefixed message that points to the
+ * offending file via the surrounding render call site.
+ *
+ * @param raw — the unvalidated frontmatter object Astro supplies
+ *   (`entry.data` from `getEntry('blog', slug)` or `getCollection('blog')`).
+ * @param ctx — diagnostic context appended to the error message so
+ *   the consumer can find the failing source file when SSG halts.
+ *   Optional but recommended.
+ */
+export interface ParseBlogPostFrontmatterContext {
+    /**
+     * The MDX file's path or slug. Echoed into the error message when
+     * validation fails so the operator can grep for it. Astro typically
+     * gives consumers `entry.id` (the slug + extension) — passing it
+     * through here is enough for an actionable error.
+     */
+    readonly source?: string;
+}
+export declare function parseBlogPostFrontmatter(raw: unknown, ctx?: ParseBlogPostFrontmatterContext): BlogPostFrontmatter;
+/** @wildo_source:part:end saas.website.blog.collection-config */
+//# sourceMappingURL=blog-post-collection.config.d.ts.map

package/dist/esm/mdx/blog-post-collection.config.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"blog-post-collection.config.d.ts","sourceRoot":"","sources":["../../../../src/mdx/blog-post-collection.config.ts"],"names":[],"mappings":"AACA,OAAO,EAEL,KAAK,mBAAmB,EACzB,MAAM,sDAAsD,CAAC;AAE9D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+EG;AAEH;;;;;;GAMG;AACH,MAAM,WAAW,oBAAoB;IACnC,MAAM,EAAE,CAAC,KAAK,EAAE,MAAM,CAAC,MAAM,EAAE,KAAK,CAAC,KAAK;QACxC,WAAW,EAAE,MAAM,OAAO,CAAC;KAC5B,CAAC;CACH;AAED,MAAM,WAAW,oCAAoC;IACnD;;;;;;OAMG;IACH,MAAM,EAAE,oBAAoB,CAAC;CAC9B;AAED,MAAM,WAAW,6BAA6B;IAC5C;;;;;;OAMG;IACH,MAAM,EAAE,OAAO,CAAC;CACjB;AAED,wBAAgB,6BAA6B,CAC3C,IAAI,EAAE,oCAAoC,GACzC,6BAA6B,CAK/B;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,+BAA+B;IAC9C;;;;;OAKG;IACH,QAAQ,CAAC,MAAM,CAAC,EAAE,MAAM,CAAC;CAC1B;AAED,wBAAgB,wBAAwB,CACtC,GAAG,EAAE,OAAO,EACZ,GAAG,GAAE,+BAAoC,GACxC,mBAAmB,CAkBrB;AACD,iEAAiE"}

package/dist/esm/mdx/blog-post-collection.config.js

@@ -0,0 +1,27 @@
+import { formatZodIssues } from '@wildo-ai/saas-models/public-runtime';
+import { BlogPostFrontmatterSchema, } from '../schemas/blog/blog-post-frontmatter.shared.schemas.js';
+export function buildBlogPostCollectionConfig(opts) {
+    const { astroZ } = opts;
+    return {
+        schema: astroZ.object({}).passthrough(),
+    };
+}
+export function parseBlogPostFrontmatter(raw, ctx = {}) {
+    const result = BlogPostFrontmatterSchema.safeParse(raw);
+    if (result.success) {
+        return result.data;
+    }
+    const sourceSuffix = ctx.source !== undefined ? ` (source="${ctx.source}")` : '';
+    /**
+     * Zod 4's `result.error.message` is the JSON-stringified `issues[]` array —
+     * long-form, it floods the Astro build log, and the path is what an operator
+     * needs to find the broken frontmatter field. `formatZodIssues` is the
+     * framework-canonical rendering (one `path: message` per entry); we only own
+     * the bullet prefix. Unbounded on purpose: every bad field in a post should
+     * be fixable from one build run.
+     */
+    const issueLines = formatZodIssues(result.error.issues).map((entry) => `  - ${entry}`);
+    throw new Error(`[blog-post] Frontmatter failed BlogPostFrontmatterSchema validation${sourceSuffix}:\n${issueLines.join('\n')}`);
+}
+/** @wildo_source:part:end saas.website.blog.collection-config */
+//# sourceMappingURL=blog-post-collection.config.js.map

package/dist/esm/mdx/blog-post-collection.config.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"blog-post-collection.config.js","sourceRoot":"","sources":["../../../../src/mdx/blog-post-collection.config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AACvE,OAAO,EACL,yBAAyB,GAE1B,MAAM,sDAAsD,CAAC;AAsH9D,MAAM,UAAU,6BAA6B,CAC3C,IAA0C;IAE1C,MAAM,EAAE,MAAM,EAAE,GAAG,IAAI,CAAC;IACxB,OAAO;QACL,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,WAAW,EAAE;KACxC,CAAC;AACJ,CAAC;AAyBD,MAAM,UAAU,wBAAwB,CACtC,GAAY,EACZ,MAAuC,EAAE;IAEzC,MAAM,MAAM,GAAG,yBAAyB,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC;IACxD,IAAI,MAAM,CAAC,OAAO,EAAE,CAAC;QACnB,OAAO,MAAM,CAAC,IAAI,CAAC;IACrB,CAAC;IACD,MAAM,YAAY,GAAG,GAAG,CAAC,MAAM,KAAK,SAAS,CAAC,CAAC,CAAC,aAAa,GAAG,CAAC,MAAM,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;IACjF;;;;;;;OAOG;IACH,MAAM,UAAU,GAAG,eAAe,CAAC,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,OAAO,KAAK,EAAE,CAAC,CAAC;IACvF,MAAM,IAAI,KAAK,CACb,sEAAsE,YAAY,MAAM,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAChH,CAAC;AACJ,CAAC;AACD,iEAAiE","sourcesContent":["import { formatZodIssues } from '@wildo-ai/saas-models/public-runtime';\nimport {\n  BlogPostFrontmatterSchema,\n  type BlogPostFrontmatter,\n} from '../schemas/blog/blog-post-frontmatter.shared.schemas';\n\n/**\n * @wildo_source:part:start saas.website.blog.collection-config facet:layer:mdx facet:family:website\n *\n * Astro content-collection bridge for blog posts (Phase 7 D-3 = Path Z).\n *\n * # The Zod-version bridge problem\n *\n * Astro's `astro:content` ships its own bundled Zod (currently 3.x).\n * Our `BlogPostFrontmatterSchema` is Zod 4 and uses Zod-4-only APIs\n * (`z.iso.datetime`, `z.url(...)`, `.brand<>()`). The two cannot share\n * a schema instance directly across the version boundary, and shimming\n * a Zod 4 schema down to a Zod 3 schema would create either:\n *\n *   - a hand-mirrored copy (Path X) — maintained in `src/content/config.ts`\n *     using Astro's `z`, with silent-drift risk every time a field is\n *     added/removed/refined; or\n *   - a runtime bridge package (Path C) — a non-trivial maintenance\n *     surface for a marginal gain.\n *\n * Path Z (this file) sidesteps the bridge entirely: the consumer's\n * `src/content/config.ts` declares a `passthrough` collection schema\n * that lets Astro accept any frontmatter shape; the engine then\n * validates with the canonical Zod 4 schema at render time inside\n * `<BlogPost>`. Astro's static site generator runs the page render\n * during the build, so a malformed frontmatter still surfaces as a\n * BUILD-TIME error (the `.parse()` call throws synchronously and Astro\n * reports it with the page URL) — the only practical difference vs.\n * Path X is the error-message stack location.\n *\n * # Why the engine ships an opaque shape (rather than the consumer\n *   importing the Astro `z` directly)\n *\n * Astro's content-collection API has churned across Astro 4 → 5\n * (loaders moved from string-keyed `type` to a callable `loader`\n * factory; the `glob()` loader's signature changed). Every consumer\n * touching `defineCollection` directly inherits that churn; centralizing\n * the wiring in the engine means the framework absorbs the upgrade\n * cost in ONE place when Astro bumps a major.\n *\n * The shape returned here is `{ schema: <passthrough record> }`. The\n * consumer spreads it into their `defineCollection` call:\n *\n * ```ts\n * // examples/<app>/website/src/content/config.ts\n * import { defineCollection, z } from 'astro:content';\n * import { buildBlogPostCollectionConfig } from '@wildo-ai/saas-website/mdx';\n *\n * export const collections = {\n *   blog: defineCollection({\n *     type: 'content',\n *     ...buildBlogPostCollectionConfig({ astroZ: z }),\n *   }),\n * };\n * ```\n *\n * The consumer passes Astro's own `z` in (because the engine cannot\n * import `astro:content` — that virtual module only exists inside\n * the Astro build context, never at the engine package's compile\n * time, and importing it would also pull `astro` into the engine's\n * walked closure which the bundle-isolation test forbids). The engine\n * builds a passthrough `z.object({}).passthrough()` from the supplied\n * factory and returns the schema slot.\n *\n * # `parseBlogPostFrontmatter`\n *\n * Companion render-time validator. Called at the top of `<BlogPost>`\n * with the raw `entry.data` Astro hands the page; returns the\n * branded, validated `BlogPostFrontmatter` (Zod 4) or throws with\n * the standard Zod-4 issue formatting + a `[blog-post]` prefix that\n * tells the SSG operator which file to fix.\n *\n * # Boundary\n *\n * This file is React-runtime-safe: it only imports the (also\n * React-safe) `BlogPostFrontmatterSchema` from `schemas/blog/`. It\n * ships into the React-island bundle via the `mdx.ts` barrel, which\n * the bundle-isolation test walks as a dedicated entry. Helpers that\n * parse raw MDX source live in `blog-post-frontmatter-source.ts` so the\n * `yaml` package stays on the build-time/Node side of the boundary.\n */\n\n/**\n * Minimal contract for the Astro-side Zod factory we accept. Typed\n * structurally (rather than imported from `astro:content`) so the\n * engine package can compile/test without an Astro install. Astro's\n * actual `z.object` returns a much richer Zod-3 schema; we narrow to\n * just the `.passthrough()` call we make below.\n */\nexport interface AstroZodFactoryShape {\n  object: (shape: Record<string, never>) => {\n    passthrough: () => unknown;\n  };\n}\n\nexport interface BuildBlogPostCollectionConfigOptions {\n  /**\n   * Astro's bundled `z` object — pass `import { z } from 'astro:content'`\n   * from the consumer-side `src/content/config.ts`. The engine cannot\n   * import `astro:content` itself (virtual module, only present inside\n   * the Astro build pipeline; would also bloat the bundle-isolation\n   * walked closure with the `astro` runtime).\n   */\n  astroZ: AstroZodFactoryShape;\n}\n\nexport interface BlogPostCollectionConfigShape {\n  /**\n   * The schema slot consumed by Astro's `defineCollection({...})`.\n   * A `passthrough` record (no field constraints at this layer) so\n   * Astro accepts any frontmatter; the strict Zod-4 validation runs\n   * at render time inside `<BlogPost>` via\n   * `parseBlogPostFrontmatter(...)`.\n   */\n  schema: unknown;\n}\n\nexport function buildBlogPostCollectionConfig(\n  opts: BuildBlogPostCollectionConfigOptions,\n): BlogPostCollectionConfigShape {\n  const { astroZ } = opts;\n  return {\n    schema: astroZ.object({}).passthrough(),\n  };\n}\n\n/**\n * Strict Zod-4 validator for blog-post frontmatter. Called at the top\n * of `<BlogPost>` rendering against `entry.data` (whatever Astro's\n * passthrough collection schema accepted). Throws on validation\n * failure with a `[blog-post]`-prefixed message that points to the\n * offending file via the surrounding render call site.\n *\n * @param raw — the unvalidated frontmatter object Astro supplies\n *   (`entry.data` from `getEntry('blog', slug)` or `getCollection('blog')`).\n * @param ctx — diagnostic context appended to the error message so\n *   the consumer can find the failing source file when SSG halts.\n *   Optional but recommended.\n */\nexport interface ParseBlogPostFrontmatterContext {\n  /**\n   * The MDX file's path or slug. Echoed into the error message when\n   * validation fails so the operator can grep for it. Astro typically\n   * gives consumers `entry.id` (the slug + extension) — passing it\n   * through here is enough for an actionable error.\n   */\n  readonly source?: string;\n}\n\nexport function parseBlogPostFrontmatter(\n  raw: unknown,\n  ctx: ParseBlogPostFrontmatterContext = {},\n): BlogPostFrontmatter {\n  const result = BlogPostFrontmatterSchema.safeParse(raw);\n  if (result.success) {\n    return result.data;\n  }\n  const sourceSuffix = ctx.source !== undefined ? ` (source=\"${ctx.source}\")` : '';\n  /**\n   * Zod 4's `result.error.message` is the JSON-stringified `issues[]` array —\n   * long-form, it floods the Astro build log, and the path is what an operator\n   * needs to find the broken frontmatter field. `formatZodIssues` is the\n   * framework-canonical rendering (one `path: message` per entry); we only own\n   * the bullet prefix. Unbounded on purpose: every bad field in a post should\n   * be fixable from one build run.\n   */\n  const issueLines = formatZodIssues(result.error.issues).map((entry) => `  - ${entry}`);\n  throw new Error(\n    `[blog-post] Frontmatter failed BlogPostFrontmatterSchema validation${sourceSuffix}:\\n${issueLines.join('\\n')}`,\n  );\n}\n/** @wildo_source:part:end saas.website.blog.collection-config */\n"]}

package/dist/esm/mdx/blog-post-frontmatter-source.d.ts

@@ -0,0 +1,12 @@
+import { type ParseBlogPostFrontmatterContext } from './blog-post-collection.config';
+import type { BlogPostFrontmatter } from '../schemas/blog/blog-post-frontmatter.shared.schemas';
+/**
+ * Build-time helper for code that reads raw MDX files from disk and
+ * needs the canonical Zod-4 blog frontmatter validation. This module is
+ * intentionally kept out of `@wildo-ai/saas-website/mdx`, because its
+ * `yaml` dependency belongs to the Node/build-time graph, not the
+ * React-island bundle walked by the D12 isolation test.
+ */
+export type ParseBlogPostFrontmatterFromMdxSourceContext = ParseBlogPostFrontmatterContext;
+export declare function parseBlogPostFrontmatterFromMdxSource(source: string, ctx?: ParseBlogPostFrontmatterFromMdxSourceContext): BlogPostFrontmatter;
+//# sourceMappingURL=blog-post-frontmatter-source.d.ts.map

package/dist/esm/mdx/blog-post-frontmatter-source.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"blog-post-frontmatter-source.d.ts","sourceRoot":"","sources":["../../../../src/mdx/blog-post-frontmatter-source.ts"],"names":[],"mappings":"AAEA,OAAO,EAEL,KAAK,+BAA+B,EACrC,MAAM,+BAA+B,CAAC;AACvC,OAAO,KAAK,EAAE,mBAAmB,EAAE,MAAM,sDAAsD,CAAC;AAEhG;;;;;;GAMG;AACH,MAAM,MAAM,4CAA4C,GAAG,+BAA+B,CAAC;AAE3F,wBAAgB,qCAAqC,CACnD,MAAM,EAAE,MAAM,EACd,GAAG,GAAE,4CAAiD,GACrD,mBAAmB,CAUrB"}

package/dist/esm/mdx/blog-post-frontmatter-source.js

@@ -0,0 +1,13 @@
+import { parse as parseYaml } from 'yaml';
+import { parseBlogPostFrontmatter, } from './blog-post-collection.config.js';
+export function parseBlogPostFrontmatterFromMdxSource(source, ctx = {}) {
+    const normalizedSource = source.replace(/\r\n/g, '\n');
+    const match = normalizedSource.match(/^---\n([\s\S]*?)\n---(?:\n|$)/);
+    if (!match) {
+        const sourceSuffix = ctx.source !== undefined ? ` (source="${ctx.source}")` : '';
+        throw new Error(`[blog-post] MDX file is missing YAML frontmatter${sourceSuffix}.`);
+    }
+    const rawFrontmatter = parseYaml(match[1]);
+    return parseBlogPostFrontmatter(rawFrontmatter, ctx);
+}
+//# sourceMappingURL=blog-post-frontmatter-source.js.map

package/dist/esm/mdx/blog-post-frontmatter-source.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"blog-post-frontmatter-source.js","sourceRoot":"","sources":["../../../../src/mdx/blog-post-frontmatter-source.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,IAAI,SAAS,EAAE,MAAM,MAAM,CAAC;AAE1C,OAAO,EACL,wBAAwB,GAEzB,MAAM,+BAA+B,CAAC;AAYvC,MAAM,UAAU,qCAAqC,CACnD,MAAc,EACd,MAAoD,EAAE;IAEtD,MAAM,gBAAgB,GAAG,MAAM,CAAC,OAAO,CAAC,OAAO,EAAE,IAAI,CAAC,CAAC;IACvD,MAAM,KAAK,GAAG,gBAAgB,CAAC,KAAK,CAAC,+BAA+B,CAAC,CAAC;IACtE,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,MAAM,YAAY,GAAG,GAAG,CAAC,MAAM,KAAK,SAAS,CAAC,CAAC,CAAC,aAAa,GAAG,CAAC,MAAM,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QACjF,MAAM,IAAI,KAAK,CAAC,mDAAmD,YAAY,GAAG,CAAC,CAAC;IACtF,CAAC;IAED,MAAM,cAAc,GAAG,SAAS,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;IAC3C,OAAO,wBAAwB,CAAC,cAAc,EAAE,GAAG,CAAC,CAAC;AACvD,CAAC","sourcesContent":["import { parse as parseYaml } from 'yaml';\n\nimport {\n  parseBlogPostFrontmatter,\n  type ParseBlogPostFrontmatterContext,\n} from './blog-post-collection.config';\nimport type { BlogPostFrontmatter } from '../schemas/blog/blog-post-frontmatter.shared.schemas';\n\n/**\n * Build-time helper for code that reads raw MDX files from disk and\n * needs the canonical Zod-4 blog frontmatter validation. This module is\n * intentionally kept out of `@wildo-ai/saas-website/mdx`, because its\n * `yaml` dependency belongs to the Node/build-time graph, not the\n * React-island bundle walked by the D12 isolation test.\n */\nexport type ParseBlogPostFrontmatterFromMdxSourceContext = ParseBlogPostFrontmatterContext;\n\nexport function parseBlogPostFrontmatterFromMdxSource(\n  source: string,\n  ctx: ParseBlogPostFrontmatterFromMdxSourceContext = {},\n): BlogPostFrontmatter {\n  const normalizedSource = source.replace(/\\r\\n/g, '\\n');\n  const match = normalizedSource.match(/^---\\n([\\s\\S]*?)\\n---(?:\\n|$)/);\n  if (!match) {\n    const sourceSuffix = ctx.source !== undefined ? ` (source=\"${ctx.source}\")` : '';\n    throw new Error(`[blog-post] MDX file is missing YAML frontmatter${sourceSuffix}.`);\n  }\n\n  const rawFrontmatter = parseYaml(match[1]);\n  return parseBlogPostFrontmatter(rawFrontmatter, ctx);\n}\n"]}

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

@@ -0,0 +1,22 @@
+/**
+ * Sub-barrel for the marketing-blog MDX adapter (Phase 7). Re-exports
+ * the three engine surfaces consumers wire up:
+ *
+ *   - `<BlogPost>` — the per-post page renderer that strict-validates
+ *     frontmatter + composes `WebsitePageLayout` + `WebsiteMdxProvider`.
+ *   - `<WebsiteMdxProvider>` — the `@mdx-js/react` boundary the
+ *     framework owns so the upstream package is swap-safe.
+ *   - `buildBlogPostCollectionConfig(...)` + `parseBlogPostFrontmatter(...)`
+ *     — the Astro content-collection bridge (Path Z passthrough at the
+ *     collection layer, strict Zod-4 validation at render time). Raw
+ *     MDX-source parsing is exported separately from `./mdx-source` so
+ *     `yaml` stays out of the React-island graph.
+ *
+ * Re-exported through the top-level `mdx.ts` barrel so the public
+ * import surface is `'@wildo-ai/saas-website/mdx'` (matching the
+ * `astro.ts` / `astro-island.ts` naming pattern).
+ */
+export { BlogPost, BLOG_POST_PAGE_REF, type BlogPostProps, type BlogPostMdxComponents, type BlogPostMdxComponent, } from './BlogPost';
+export { buildBlogPostCollectionConfig, parseBlogPostFrontmatter, type AstroZodFactoryShape, type BuildBlogPostCollectionConfigOptions, type BlogPostCollectionConfigShape, type ParseBlogPostFrontmatterContext, } from './blog-post-collection.config';
+export { WebsiteMdxProvider, type WebsiteMdxComponentsMap, type WebsiteMdxProviderProps, } from './website-mdx-provider';
+//# sourceMappingURL=index.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../src/mdx/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,EACL,QAAQ,EACR,kBAAkB,EAClB,KAAK,aAAa,EAClB,KAAK,qBAAqB,EAC1B,KAAK,oBAAoB,GAC1B,MAAM,YAAY,CAAC;AACpB,OAAO,EACL,6BAA6B,EAC7B,wBAAwB,EACxB,KAAK,oBAAoB,EACzB,KAAK,oCAAoC,EACzC,KAAK,6BAA6B,EAClC,KAAK,+BAA+B,GACrC,MAAM,+BAA+B,CAAC;AACvC,OAAO,EACL,kBAAkB,EAClB,KAAK,uBAAuB,EAC5B,KAAK,uBAAuB,GAC7B,MAAM,wBAAwB,CAAC"}

package/dist/esm/mdx/index.js

@@ -0,0 +1,22 @@
+/**
+ * Sub-barrel for the marketing-blog MDX adapter (Phase 7). Re-exports
+ * the three engine surfaces consumers wire up:
+ *
+ *   - `<BlogPost>` — the per-post page renderer that strict-validates
+ *     frontmatter + composes `WebsitePageLayout` + `WebsiteMdxProvider`.
+ *   - `<WebsiteMdxProvider>` — the `@mdx-js/react` boundary the
+ *     framework owns so the upstream package is swap-safe.
+ *   - `buildBlogPostCollectionConfig(...)` + `parseBlogPostFrontmatter(...)`
+ *     — the Astro content-collection bridge (Path Z passthrough at the
+ *     collection layer, strict Zod-4 validation at render time). Raw
+ *     MDX-source parsing is exported separately from `./mdx-source` so
+ *     `yaml` stays out of the React-island graph.
+ *
+ * Re-exported through the top-level `mdx.ts` barrel so the public
+ * import surface is `'@wildo-ai/saas-website/mdx'` (matching the
+ * `astro.ts` / `astro-island.ts` naming pattern).
+ */
+export { BlogPost, BLOG_POST_PAGE_REF, } from './BlogPost.js';
+export { buildBlogPostCollectionConfig, parseBlogPostFrontmatter, } from './blog-post-collection.config.js';
+export { WebsiteMdxProvider, } from './website-mdx-provider.js';
+//# sourceMappingURL=index.js.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../src/mdx/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,EACL,QAAQ,EACR,kBAAkB,GAInB,MAAM,YAAY,CAAC;AACpB,OAAO,EACL,6BAA6B,EAC7B,wBAAwB,GAKzB,MAAM,+BAA+B,CAAC;AACvC,OAAO,EACL,kBAAkB,GAGnB,MAAM,wBAAwB,CAAC","sourcesContent":["/**\n * Sub-barrel for the marketing-blog MDX adapter (Phase 7). Re-exports\n * the three engine surfaces consumers wire up:\n *\n *   - `<BlogPost>` — the per-post page renderer that strict-validates\n *     frontmatter + composes `WebsitePageLayout` + `WebsiteMdxProvider`.\n *   - `<WebsiteMdxProvider>` — the `@mdx-js/react` boundary the\n *     framework owns so the upstream package is swap-safe.\n *   - `buildBlogPostCollectionConfig(...)` + `parseBlogPostFrontmatter(...)`\n *     — the Astro content-collection bridge (Path Z passthrough at the\n *     collection layer, strict Zod-4 validation at render time). Raw\n *     MDX-source parsing is exported separately from `./mdx-source` so\n *     `yaml` stays out of the React-island graph.\n *\n * Re-exported through the top-level `mdx.ts` barrel so the public\n * import surface is `'@wildo-ai/saas-website/mdx'` (matching the\n * `astro.ts` / `astro-island.ts` naming pattern).\n */\n\nexport {\n  BlogPost,\n  BLOG_POST_PAGE_REF,\n  type BlogPostProps,\n  type BlogPostMdxComponents,\n  type BlogPostMdxComponent,\n} from './BlogPost';\nexport {\n  buildBlogPostCollectionConfig,\n  parseBlogPostFrontmatter,\n  type AstroZodFactoryShape,\n  type BuildBlogPostCollectionConfigOptions,\n  type BlogPostCollectionConfigShape,\n  type ParseBlogPostFrontmatterContext,\n} from './blog-post-collection.config';\nexport {\n  WebsiteMdxProvider,\n  type WebsiteMdxComponentsMap,\n  type WebsiteMdxProviderProps,\n} from './website-mdx-provider';\n"]}

package/dist/esm/mdx/website-mdx-provider.d.ts

@@ -0,0 +1,90 @@
+import type { ComponentType, ReactNode } from 'react';
+/**
+ * @wildo_source:part:start saas.website.blog.mdx-provider facet:layer:mdx facet:family:website
+ *
+ * `WebsiteMdxProvider` — thin wrapper around `@mdx-js/react`'s
+ * `MDXProvider` that scopes a consumer-supplied `components` map for
+ * the entire MDX subtree it wraps.
+ *
+ * # Why a framework wrapper at all (vs. consumers using `MDXProvider` directly)
+ *
+ * Three application-facing reasons:
+ *
+ *   1. **Single API surface for embedded business sections.** The framework
+ *      owns the provider boundary so consumers
+ *      never directly import from `@mdx-js/react` — they ship a single
+ *      `mdxComponents` object literal and the framework picks the
+ *      provider implementation. If `@mdx-js/react` ever splits its
+ *      package or changes its provider semantics (it has shipped
+ *      breaking changes between major versions before), the swap
+ *      lands in this file with zero consumer churn.
+ *   2. **Bundle-isolation discipline.** `@mdx-js/react` is browser-safe
+ *      but heavy (`mdx/types.js`, `react-context` propagation). Walling
+ *      it behind a single re-export keeps the import surface auditable
+ *      through the package's client-bundle boundary: the `mdx` public entry is
+ *      checked separately and lists `@mdx-js/react` exactly once.
+ *   3. **`disableParentContext: false` (default) is the right default.**
+ *      MDX 3 lets a nested `MDXProvider` inherit components from the
+ *      parent provider, which is what we want when the per-blog-post
+ *      provider sits inside a site-wide MDX provider used by landing-page
+ *      islands.
+ *      Pinning the option here makes the framework's posture explicit;
+ *      a future change documents itself as a breaking framework decision
+ *      rather than a silent `@mdx-js/react` default flip.
+ *
+ * # The `components` map shape
+ *
+ * The map is `Record<string, ComponentType<any>>` — every key is the
+ * tag name an MDX file uses (`<CTASection ref="post-cta" />` resolves
+ * via the `CTASection` key). Values are React components the consumer
+ * authored under their own `src/sections/blog.sections.tsx` and
+ * wrapped in `<WebsiteSection sectionRef={…} category={…}>` so the
+ * label-key context is established before the section's
+ * `useWebsiteLabel(slot)` calls fire. The framework does NOT inspect
+ * the shape — discipline lives in the consumer's section registry
+ * + the label-pack validation boundary (which proves the locale pack covers
+ * each section's expected keys).
+ *
+ * # Why a `ComponentType<any>` value type and not a stricter generic
+ *
+ * MDX components receive their own props (children, plus whatever the
+ * MDX author writes inline as JSX attributes). The type system cannot
+ * narrow this through the provider boundary because the MDX compiler
+ * does the routing at compile time. `ComponentType<any>` is the
+ * convention `@mdx-js/react` itself uses (`MDXComponents` in
+ * `mdx/types.js`) — staying compatible with the upstream type avoids
+ * a wrap/unwrap dance at every consumer call site.
+ *
+ * # Bundle boundary
+ *
+ * Ships into the React-island bundle (consumed transitively from
+ * `BlogPost.tsx` which itself sits behind the consumer's per-page
+ * bridge file). MUST stay clear of `node:*` and SSR-tier specifiers
+ * — the bundle-isolation test walks `mdx.ts` as one of its entries.
+ */
+export interface WebsiteMdxComponentsMap {
+    /**
+     * Tag-name → component map. The MDX compiler resolves each
+     * `<TagName />` in a blog post's body against this object.
+     */
+    readonly [tagName: string]: ComponentType<any>;
+}
+export interface WebsiteMdxProviderProps {
+    /**
+     * Consumer-supplied component overrides. Keys are MDX tag names;
+     * values are the React components those tags resolve to.
+     */
+    components: WebsiteMdxComponentsMap;
+    /**
+     * MDX subtree (typically the compiled `<MdxBody/>` from a content
+     * collection entry). May render any number of provider-scoped
+     * components.
+     */
+    children: ReactNode;
+}
+export declare function WebsiteMdxProvider(props: WebsiteMdxProviderProps): ReactNode;
+export declare namespace WebsiteMdxProvider {
+    var displayName: string;
+}
+/** @wildo_source:part:end saas.website.blog.mdx-provider */
+//# sourceMappingURL=website-mdx-provider.d.ts.map

package/dist/esm/mdx/website-mdx-provider.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"website-mdx-provider.d.ts","sourceRoot":"","sources":["../../../../src/mdx/website-mdx-provider.tsx"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAE,SAAS,EAAE,MAAM,OAAO,CAAC;AAItD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8DG;AACH,MAAM,WAAW,uBAAuB;IACtC;;;OAGG;IACH,QAAQ,EAAE,OAAO,EAAE,MAAM,GAAG,aAAa,CAAC,GAAG,CAAC,CAAC;CAChD;AAED,MAAM,WAAW,uBAAuB;IACtC;;;OAGG;IACH,UAAU,EAAE,uBAAuB,CAAC;IACpC;;;;OAIG;IACH,QAAQ,EAAE,SAAS,CAAC;CACrB;AAED,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,uBAAuB,GAAG,SAAS,CAG5E;yBAHe,kBAAkB;;;AAKlC,4DAA4D"}

package/dist/esm/mdx/website-mdx-provider.js

@@ -0,0 +1,8 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { MDXProvider } from '@mdx-js/react';
+export function WebsiteMdxProvider(props) {
+    const { components, children } = props;
+    return _jsx(MDXProvider, { components: components, children: children });
+}
+WebsiteMdxProvider.displayName = 'WebsiteMdxProvider';
+//# sourceMappingURL=website-mdx-provider.js.map

package/dist/esm/mdx/website-mdx-provider.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"website-mdx-provider.js","sourceRoot":"","sources":["../../../../src/mdx/website-mdx-provider.tsx"],"names":[],"mappings":";AAEA,OAAO,EAAE,WAAW,EAAE,MAAM,eAAe,CAAC;AAuF5C,MAAM,UAAU,kBAAkB,CAAC,KAA8B;IAC/D,MAAM,EAAE,UAAU,EAAE,QAAQ,EAAE,GAAG,KAAK,CAAC;IACvC,OAAO,KAAC,WAAW,IAAC,UAAU,EAAE,UAAU,YAAG,QAAQ,GAAe,CAAC;AACvE,CAAC;AACD,kBAAkB,CAAC,WAAW,GAAG,oBAAoB,CAAC","sourcesContent":["import type { ComponentType, ReactNode } from 'react';\n\nimport { MDXProvider } from '@mdx-js/react';\n\n/**\n * @wildo_source:part:start saas.website.blog.mdx-provider facet:layer:mdx facet:family:website\n *\n * `WebsiteMdxProvider` — thin wrapper around `@mdx-js/react`'s\n * `MDXProvider` that scopes a consumer-supplied `components` map for\n * the entire MDX subtree it wraps.\n *\n * # Why a framework wrapper at all (vs. consumers using `MDXProvider` directly)\n *\n * Three application-facing reasons:\n *\n *   1. **Single API surface for embedded business sections.** The framework\n *      owns the provider boundary so consumers\n *      never directly import from `@mdx-js/react` — they ship a single\n *      `mdxComponents` object literal and the framework picks the\n *      provider implementation. If `@mdx-js/react` ever splits its\n *      package or changes its provider semantics (it has shipped\n *      breaking changes between major versions before), the swap\n *      lands in this file with zero consumer churn.\n *   2. **Bundle-isolation discipline.** `@mdx-js/react` is browser-safe\n *      but heavy (`mdx/types.js`, `react-context` propagation). Walling\n *      it behind a single re-export keeps the import surface auditable\n *      through the package's client-bundle boundary: the `mdx` public entry is\n *      checked separately and lists `@mdx-js/react` exactly once.\n *   3. **`disableParentContext: false` (default) is the right default.**\n *      MDX 3 lets a nested `MDXProvider` inherit components from the\n *      parent provider, which is what we want when the per-blog-post\n *      provider sits inside a site-wide MDX provider used by landing-page\n *      islands.\n *      Pinning the option here makes the framework's posture explicit;\n *      a future change documents itself as a breaking framework decision\n *      rather than a silent `@mdx-js/react` default flip.\n *\n * # The `components` map shape\n *\n * The map is `Record<string, ComponentType<any>>` — every key is the\n * tag name an MDX file uses (`<CTASection ref=\"post-cta\" />` resolves\n * via the `CTASection` key). Values are React components the consumer\n * authored under their own `src/sections/blog.sections.tsx` and\n * wrapped in `<WebsiteSection sectionRef={…} category={…}>` so the\n * label-key context is established before the section's\n * `useWebsiteLabel(slot)` calls fire. The framework does NOT inspect\n * the shape — discipline lives in the consumer's section registry\n * + the label-pack validation boundary (which proves the locale pack covers\n * each section's expected keys).\n *\n * # Why a `ComponentType<any>` value type and not a stricter generic\n *\n * MDX components receive their own props (children, plus whatever the\n * MDX author writes inline as JSX attributes). The type system cannot\n * narrow this through the provider boundary because the MDX compiler\n * does the routing at compile time. `ComponentType<any>` is the\n * convention `@mdx-js/react` itself uses (`MDXComponents` in\n * `mdx/types.js`) — staying compatible with the upstream type avoids\n * a wrap/unwrap dance at every consumer call site.\n *\n * # Bundle boundary\n *\n * Ships into the React-island bundle (consumed transitively from\n * `BlogPost.tsx` which itself sits behind the consumer's per-page\n * bridge file). MUST stay clear of `node:*` and SSR-tier specifiers\n * — the bundle-isolation test walks `mdx.ts` as one of its entries.\n */\nexport interface WebsiteMdxComponentsMap {\n  /**\n   * Tag-name → component map. The MDX compiler resolves each\n   * `<TagName />` in a blog post's body against this object.\n   */\n  readonly [tagName: string]: ComponentType<any>;\n}\n\nexport interface WebsiteMdxProviderProps {\n  /**\n   * Consumer-supplied component overrides. Keys are MDX tag names;\n   * values are the React components those tags resolve to.\n   */\n  components: WebsiteMdxComponentsMap;\n  /**\n   * MDX subtree (typically the compiled `<MdxBody/>` from a content\n   * collection entry). May render any number of provider-scoped\n   * components.\n   */\n  children: ReactNode;\n}\n\nexport function WebsiteMdxProvider(props: WebsiteMdxProviderProps): ReactNode {\n  const { components, children } = props;\n  return <MDXProvider components={components}>{children}</MDXProvider>;\n}\nWebsiteMdxProvider.displayName = 'WebsiteMdxProvider';\n/** @wildo_source:part:end saas.website.blog.mdx-provider */\n"]}

package/dist/esm/mdx.d.ts

@@ -0,0 +1,38 @@
+/**
+ * Top-level barrel for the marketing-blog MDX adapter (Phase 7).
+ *
+ * # Why a dedicated subpath instead of folding into the root barrel
+ *
+ * `@wildo-ai/saas-website/mdx` ships into the React-island bundle
+ * (consumed transitively from a consumer's per-post `.astro` page
+ * which imports `<BlogPost>` and renders it client-side). The
+ * `@mdx-js/react` runtime adds non-trivial weight to the closure;
+ * isolating the entry behind a dedicated subpath:
+ *
+ *   - keeps `index.ts` (the Node + React companion-runtime entry) free
+ *     of MDX runtime dependencies for sites that ship landing-page-only
+ *     marketing surfaces;
+ *   - lets the bundle-isolation test walk this entry independently
+ *     (see `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *     `ENTRY_FILES` list) so an accidental `node:fs` import inside
+ *     `BlogPost.tsx` regresses against the React-bundle constraint
+ *     without polluting the other entries' allow-lists.
+ *
+ * Pattern mirrors `astro.ts` / `astro-island.ts` / `config-loader.ts`:
+ * one purpose, one barrel, one bundle-isolation entry.
+ */
+export * from './mdx/index';
+/**
+ * The blog adapter's per-locale bridge factory
+ * (`createWebsiteBlogPostBridgeIsland`). Lives in `astro/` beside
+ * `bridge-runtime.tsx` (same closure-over-deps pattern) but is exported
+ * from THIS entry — not `astro-island.ts` — because it hard-imports
+ * `./mdx/BlogPost`, whose `@mdx-js/react` peer is optional. Exporting it
+ * from the mandatory per-page bridge entry made the optional peer a
+ * de-facto install requirement for every non-blog site (Vite resolves the
+ * whole `export *` graph before tree-shaking). Here, only sites that opt
+ * into the blog adapter — and therefore install `@astrojs/mdx` +
+ * `@mdx-js/react` — ever resolve it.
+ */
+export * from './astro/blog-post-bridge';
+//# sourceMappingURL=mdx.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"mdx.d.ts","sourceRoot":"","sources":["../../../src/mdx.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,cAAc,aAAa,CAAC;AAC5B;;;;;;;;;;;GAWG;AACH,cAAc,0BAA0B,CAAC"}

package/dist/esm/mdx.js

@@ -0,0 +1,38 @@
+/**
+ * Top-level barrel for the marketing-blog MDX adapter (Phase 7).
+ *
+ * # Why a dedicated subpath instead of folding into the root barrel
+ *
+ * `@wildo-ai/saas-website/mdx` ships into the React-island bundle
+ * (consumed transitively from a consumer's per-post `.astro` page
+ * which imports `<BlogPost>` and renders it client-side). The
+ * `@mdx-js/react` runtime adds non-trivial weight to the closure;
+ * isolating the entry behind a dedicated subpath:
+ *
+ *   - keeps `index.ts` (the Node + React companion-runtime entry) free
+ *     of MDX runtime dependencies for sites that ship landing-page-only
+ *     marketing surfaces;
+ *   - lets the bundle-isolation test walk this entry independently
+ *     (see `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *     `ENTRY_FILES` list) so an accidental `node:fs` import inside
+ *     `BlogPost.tsx` regresses against the React-bundle constraint
+ *     without polluting the other entries' allow-lists.
+ *
+ * Pattern mirrors `astro.ts` / `astro-island.ts` / `config-loader.ts`:
+ * one purpose, one barrel, one bundle-isolation entry.
+ */
+export * from './mdx/index.js';
+/**
+ * The blog adapter's per-locale bridge factory
+ * (`createWebsiteBlogPostBridgeIsland`). Lives in `astro/` beside
+ * `bridge-runtime.tsx` (same closure-over-deps pattern) but is exported
+ * from THIS entry — not `astro-island.ts` — because it hard-imports
+ * `./mdx/BlogPost`, whose `@mdx-js/react` peer is optional. Exporting it
+ * from the mandatory per-page bridge entry made the optional peer a
+ * de-facto install requirement for every non-blog site (Vite resolves the
+ * whole `export *` graph before tree-shaking). Here, only sites that opt
+ * into the blog adapter — and therefore install `@astrojs/mdx` +
+ * `@mdx-js/react` — ever resolve it.
+ */
+export * from './astro/blog-post-bridge.js';
+//# sourceMappingURL=mdx.js.map

package/dist/esm/mdx.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"mdx.js","sourceRoot":"","sources":["../../../src/mdx.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,cAAc,aAAa,CAAC;AAC5B;;;;;;;;;;;GAWG;AACH,cAAc,0BAA0B,CAAC","sourcesContent":["/**\n * Top-level barrel for the marketing-blog MDX adapter (Phase 7).\n *\n * # Why a dedicated subpath instead of folding into the root barrel\n *\n * `@wildo-ai/saas-website/mdx` ships into the React-island bundle\n * (consumed transitively from a consumer's per-post `.astro` page\n * which imports `<BlogPost>` and renders it client-side). The\n * `@mdx-js/react` runtime adds non-trivial weight to the closure;\n * isolating the entry behind a dedicated subpath:\n *\n *   - keeps `index.ts` (the Node + React companion-runtime entry) free\n *     of MDX runtime dependencies for sites that ship landing-page-only\n *     marketing surfaces;\n *   - lets the bundle-isolation test walk this entry independently\n *     (see `engine/saas-website/src/__tests__/bundle-isolation.test.ts`\n *     `ENTRY_FILES` list) so an accidental `node:fs` import inside\n *     `BlogPost.tsx` regresses against the React-bundle constraint\n *     without polluting the other entries' allow-lists.\n *\n * Pattern mirrors `astro.ts` / `astro-island.ts` / `config-loader.ts`:\n * one purpose, one barrel, one bundle-isolation entry.\n */\n\nexport * from './mdx/index';\n/**\n * The blog adapter's per-locale bridge factory\n * (`createWebsiteBlogPostBridgeIsland`). Lives in `astro/` beside\n * `bridge-runtime.tsx` (same closure-over-deps pattern) but is exported\n * from THIS entry — not `astro-island.ts` — because it hard-imports\n * `./mdx/BlogPost`, whose `@mdx-js/react` peer is optional. Exporting it\n * from the mandatory per-page bridge entry made the optional peer a\n * de-facto install requirement for every non-blog site (Vite resolves the\n * whole `export *` graph before tree-shaking). Here, only sites that opt\n * into the blog adapter — and therefore install `@astrojs/mdx` +\n * `@mdx-js/react` — ever resolve it.\n */\nexport * from './astro/blog-post-bridge';\n"]}

package/dist/esm/schemas/blog/blog-post-frontmatter.shared.schemas.d.ts

@@ -0,0 +1,75 @@
+import { z } from 'zod';
+import { AvailableLanguage } from '@wildo-ai/saas-models/public-runtime';
+/**
+ * @wildo_source:part:start saas.website.blog.frontmatter facet:layer:shared facet:family:website
+ *
+ * `BlogPostFrontmatter` — the YAML frontmatter contract every blog
+ * post MDX file under `examples/<app>/website/src/content/blog/<locale>/`
+ * MUST satisfy.
+ *
+ * **Q16=B context**: blogs are authored as full per-locale MDX files
+ * (one MDX per (slug, locale) pair), NOT as label-pack-keyed content.
+ * The frontmatter therefore carries strings directly (`title`,
+ * `summary`) rather than label keys — there is no shared
+ * label-pack-driven authoring surface for blog content. This is
+ * intentional: blog copy is long-form and locale-divergent; forcing
+ * it through a structural label-pack would either inflate the pack
+ * or fragment the prose.
+ *
+ * **Field rationale**:
+ *
+ * - `title` — REQUIRED. Renders into `<title>`, `og:title`, and the
+ *   in-page H1. Authored as a direct string, deliberately.
+ * - `summary` — REQUIRED. Renders into `<meta name="description">`,
+ *   `og:description`, and listing-card descriptions. Direct string.
+ * - `slug` — REQUIRED. URL slug (lowercase kebab-case). Brand prevents
+ *   accidental swap with `WebsitePageRef` (same shape, different role).
+ * - `locale` — REQUIRED. The post's locale. Drives the URL prefix
+ *   (`/<locale>/blog/<slug>`) and `<html lang>`. Cross-locale
+ *   correspondence is established by sharing the `slug` across
+ *   per-locale MDX files (e.g. `en/why-context.md` and
+ *   `fr/why-context.md` are the same post in two locales).
+ * - `publishedAt` — REQUIRED. ISO-8601 date-time string. Renders into
+ *   `og:article:published_time` and the listing-card date label.
+ *   Stored as string (not `z.coerce.date`) because YAML frontmatter
+ *   parsers preserve the original string and the SEO emitters need
+ *   the original ISO formatting (no Date.toISOString() round-trip
+ *   loss).
+ * - `authorRef` — REQUIRED. Identifier of the author resolved by the
+ *   consumer's author registry (typically a `src/content/authors/<ref>.ts`
+ *   file). Brand keeps it distinct from page/section refs.
+ * - `tags` — REQUIRED, possibly empty. Lowercase kebab-case tag
+ *   identifiers. Drives `og:article:tag` and the listing-page facets.
+ * - `coverImageUrl` — OPTIONAL. CDN URL for the blog post hero image
+ *   and `og:image`.
+ *
+ * **Why a separate file from the page-manifest**: a blog post is NOT
+ * a `WebsitePageManifest` (no React `pageComponent` to mount — the
+ * MDX file IS the content). The Astro adapter emits one MDX route
+ * per post via `content collections`, with `BlogPostFrontmatter`
+ * driving the route generation and the SEO emission.
+ */
+declare const _BlogPostSlugSchema: z.core.$ZodBranded<z.ZodString, "BlogPostSlug", "out">;
+export declare const BlogPostSlugSchema: typeof _BlogPostSlugSchema;
+export type BlogPostSlug = z.infer<typeof _BlogPostSlugSchema>;
+declare const _BlogAuthorRefSchema: z.core.$ZodBranded<z.ZodString, "BlogAuthorRef", "out">;
+export declare const BlogAuthorRefSchema: typeof _BlogAuthorRefSchema;
+export type BlogAuthorRef = z.infer<typeof _BlogAuthorRefSchema>;
+declare const _BlogPostTagSchema: z.core.$ZodBranded<z.ZodString, "BlogPostTag", "out">;
+export declare const BlogPostTagSchema: typeof _BlogPostTagSchema;
+export type BlogPostTag = z.infer<typeof _BlogPostTagSchema>;
+declare const _BlogPostFrontmatterSchema: z.ZodObject<{
+    title: z.ZodString;
+    summary: z.ZodString;
+    slug: z.core.$ZodBranded<z.ZodString, "BlogPostSlug", "out">;
+    locale: z.ZodEnum<typeof AvailableLanguage>;
+    publishedAt: z.ZodISODateTime;
+    authorRef: z.core.$ZodBranded<z.ZodString, "BlogAuthorRef", "out">;
+    tags: z.ZodArray<z.core.$ZodBranded<z.ZodString, "BlogPostTag", "out">>;
+    coverImageUrl: z.ZodOptional<z.ZodURL>;
+}, z.core.$strip>;
+export declare const BlogPostFrontmatterSchema: typeof _BlogPostFrontmatterSchema;
+export type BlogPostFrontmatter = z.infer<typeof _BlogPostFrontmatterSchema>;
+export {};
+/** @wildo_source:part:end saas.website.blog.frontmatter */
+//# sourceMappingURL=blog-post-frontmatter.shared.schemas.d.ts.map

package/dist/esm/schemas/blog/blog-post-frontmatter.shared.schemas.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"blog-post-frontmatter.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/schemas/blog/blog-post-frontmatter.shared.schemas.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB,OAAO,EAAE,iBAAiB,EAAE,MAAM,sCAAsC,CAAC;AAEzE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,QAAA,MAAM,mBAAmB,wDAQC,CAAC;AAE3B,eAAO,MAAM,kBAAkB,EAAE,OAAO,mBAAyC,CAAC;AAElF,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAE/D,QAAA,MAAM,oBAAoB,yDAQC,CAAC;AAE5B,eAAO,MAAM,mBAAmB,EAAE,OAAO,oBAA2C,CAAC;AAErF,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC;AAEjE,QAAA,MAAM,kBAAkB,uDAQC,CAAC;AAE1B,eAAO,MAAM,iBAAiB,EAAE,OAAO,kBAAuC,CAAC;AAE/E,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAE7D,QAAA,MAAM,0BAA0B;;;;;;;;;iBAS9B,CAAC;AAEH,eAAO,MAAM,yBAAyB,EAAE,OAAO,0BACnB,CAAC;AAE7B,MAAM,MAAM,mBAAmB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,0BAA0B,CAAC,CAAC;;AAC7E,2DAA2D"}