@wildo-ai/saas-website 1.1.1

package/dist/esm/astro/website-site-context.d.ts

@@ -0,0 +1,126 @@
+import type { WildoMarketingWebsiteConfig } from '../config/wildo-website-config.schemas';
+import type { WebsiteRootConfig } from '../schemas/manifests/website-root-config.shared.schemas';
+import type { FrontendProvidersBlock } from '@wildo-ai/saas-models/public-runtime';
+/**
+ * @wildo_source:part:start saas.website.astro.site-context facet:layer:astro facet:family:website
+ *
+ * `WebsiteSiteContext` — the aggregated site-level inputs every Astro
+ * build-time engine helper consumes. Composes the consumer-authored
+ * `WebsiteRootConfig` (page registry, design tokens, navigation chrome,
+ * site-level SEO branding) with the per-service `WildoMarketingWebsiteConfig`
+ * loaded from `wildo.website.config.ts` (locales, default locale,
+ * public origin, future `appOrigin` cross-origin handoff target).
+ *
+ * # Why a dedicated aggregator type (vs. threading both raw configs)
+ *
+ * The seam-collapse (`saas-website-seam-collapse.md`, Option B) made
+ * `WildoMarketingWebsiteConfig` the SINGLE source of truth for the
+ * marketing-site routing surface (`defaultLocale`, `locales`,
+ * `publicOrigin`). Every engine helper that previously read those
+ * fields from `WebsiteRootConfig` now reads them from
+ * `WildoMarketingWebsiteConfig` — and four out of five of those helpers
+ * also still read OTHER fields from `WebsiteRootConfig` (page
+ * manifests, chrome label keys, design tokens, `seo.siteName`,
+ * `seo.defaultOgImageUrl`, `skipToMainContentLabelKey`). Threading
+ * both raw configs through every helper signature would:
+ *
+ *   1. **Bloat call sites.** Every consumer `.astro` file would have
+ *      to import both `WEBSITE_ROOT_CONFIG` and the loaded
+ *      `WILDO_WEBSITE_CONFIG`, then forward both to every helper.
+ *   2. **Spread the consumer-side composition responsibility.**
+ *      Each `.astro` file would need to know which subset of the
+ *      configs each helper consumes — a refactor hazard the next time
+ *      we add a field that the head renderer reads from the website
+ *      config but the runtime loader does not.
+ *   3. **Defeat top-level `await` ergonomics.** The website config
+ *      load is async (`loadWebsiteConfig` does jiti-backed file I/O);
+ *      forcing every `.astro` file to `await` it would either spread
+ *      the await across every page or force every page to receive the
+ *      already-loaded config from a separate consumer module —
+ *      duplicating the composition logic this aggregator centralizes.
+ *
+ * One aggregator, composed once at the consumer's
+ * `<service-root>/src/website-site-context.ts`, is the minimum-blast
+ * shape: every engine helper takes `siteContext: WebsiteSiteContext`,
+ * every `.astro` file imports the singleton `WEBSITE_SITE_CONTEXT`
+ * once, and the next field move (consumer-config-only field, or
+ * root-config-only field) lands in this type's shape with no
+ * helper-signature ripple.
+ *
+ * # Why frozen (defensive)
+ *
+ * The composed value is shared across every page render in the build
+ * graph. A misbehaving Astro plugin (or a future consumer-side audit
+ * subprocess) that mutated either nested config in place would
+ * silently corrupt every subsequent page. `Object.freeze` is a cheap
+ * top-level guard — the inner configs are themselves already produced
+ * by Zod parsers (which return fresh objects), so mutating their
+ * fields would require a deliberate `as any` cast at the consumer's
+ * call site rather than an accidental in-place edit.
+ *
+ * # When this type WOULD grow
+ *
+ * Future inputs that are also "site-wide" but neither belong to
+ * `WebsiteRootConfig` (chrome-rendered) nor to
+ * `WildoMarketingWebsiteConfig` (per-service routing/origins) — e.g.
+ * a build-environment block (`production` / `preview` / `dev`), or
+ * a feature-flag bag — would land here as a third sibling field
+ * rather than being plumbed through every helper signature
+ * individually. The aggregator is the right place for that
+ * orchestration concern; per-call ergonomics ride along for free.
+ */
+export interface WebsiteSiteContext {
+    /**
+     * The consumer's `WebsiteRootConfig` — page registry, design tokens,
+     * navigation chrome, site-level SEO branding (`siteName`,
+     * `defaultOgImageUrl?`), `chromeLabelKeys`,
+     * `skipToMainContentLabelKey`. Single source of truth for chrome
+     * + per-page meta declarations.
+     */
+    readonly rootConfig: WebsiteRootConfig;
+    /**
+     * The per-service `WildoMarketingWebsiteConfig` loaded from
+     * `wildo.website.config.ts`. Single source of truth for the
+     * marketing-site ROUTING + ORIGIN surface (`defaultLocale`,
+     * `locales`, `publicOrigin`, future `appOrigin`).
+     */
+    readonly websiteConfig: WildoMarketingWebsiteConfig;
+    /**
+     * Optional website-facing public provider block materialized from the
+     * app's provider graph for the concrete `STATIC_WEBSITE` service.
+     * Build-time only: the consumer loads it once and forwards it into the
+     * React island as JSON-serializable data.
+     */
+    readonly frontendProviders?: FrontendProvidersBlock;
+}
+/**
+ * Compose a `WebsiteSiteContext` from the two source configs. Pure +
+ * synchronous — the I/O happens upstream in `loadWebsiteConfig` and
+ * in the consumer's `WEBSITE_ROOT_CONFIG` module evaluation.
+ *
+ * **Defensive freezing**: the returned object is `Object.freeze`-d
+ * top-level so the singleton handed to every helper cannot have its
+ * `rootConfig` / `websiteConfig` references swapped in place by a
+ * misbehaving plugin. The nested configs are NOT deep-frozen — Zod
+ * already produces fresh objects per parse, and a deep freeze would
+ * cost a recursive walk per build for protection that no realistic
+ * plugin would breach.
+ *
+ * @example
+ * ```ts
+ * // examples/<app>/website/src/website-site-context.ts
+ * import { composeWebsiteSiteContext } from '@wildo-ai/saas-website/astro';
+ * import { loadWebsiteConfig } from '@wildo-ai/saas-website/config-loader';
+ *
+ * import { WEBSITE_ROOT_CONFIG } from './website-root.config';
+ *
+ * const websiteConfig = await loadWebsiteConfig({ saasRoot: '...' });
+ * export const WEBSITE_SITE_CONTEXT = composeWebsiteSiteContext({
+ *   rootConfig: WEBSITE_ROOT_CONFIG,
+ *   websiteConfig,
+ * });
+ * ```
+ */
+export declare function composeWebsiteSiteContext(parts: WebsiteSiteContext): WebsiteSiteContext;
+/** @wildo_source:part:end saas.website.astro.site-context */
+//# sourceMappingURL=website-site-context.d.ts.map

package/dist/esm/astro/website-site-context.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"website-site-context.d.ts","sourceRoot":"","sources":["../../../../src/astro/website-site-context.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,2BAA2B,EAAE,MAAM,wCAAwC,CAAC;AAC1F,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,yDAAyD,CAAC;AACjG,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,sCAAsC,CAAC;AAEnF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmEG;AACH,MAAM,WAAW,kBAAkB;IACjC;;;;;;OAMG;IACH,QAAQ,CAAC,UAAU,EAAE,iBAAiB,CAAC;IAEvC;;;;;OAKG;IACH,QAAQ,CAAC,aAAa,EAAE,2BAA2B,CAAC;IACpD;;;;;OAKG;IACH,QAAQ,CAAC,iBAAiB,CAAC,EAAE,sBAAsB,CAAC;CACrD;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,wBAAgB,yBAAyB,CACvC,KAAK,EAAE,kBAAkB,GACxB,kBAAkB,CAMpB;AACD,6DAA6D"}

package/dist/esm/astro/website-site-context.js

@@ -0,0 +1,37 @@
+/**
+ * Compose a `WebsiteSiteContext` from the two source configs. Pure +
+ * synchronous — the I/O happens upstream in `loadWebsiteConfig` and
+ * in the consumer's `WEBSITE_ROOT_CONFIG` module evaluation.
+ *
+ * **Defensive freezing**: the returned object is `Object.freeze`-d
+ * top-level so the singleton handed to every helper cannot have its
+ * `rootConfig` / `websiteConfig` references swapped in place by a
+ * misbehaving plugin. The nested configs are NOT deep-frozen — Zod
+ * already produces fresh objects per parse, and a deep freeze would
+ * cost a recursive walk per build for protection that no realistic
+ * plugin would breach.
+ *
+ * @example
+ * ```ts
+ * // examples/<app>/website/src/website-site-context.ts
+ * import { composeWebsiteSiteContext } from '@wildo-ai/saas-website/astro';
+ * import { loadWebsiteConfig } from '@wildo-ai/saas-website/config-loader';
+ *
+ * import { WEBSITE_ROOT_CONFIG } from './website-root.config.js';
+ *
+ * const websiteConfig = await loadWebsiteConfig({ saasRoot: '...' });
+ * export const WEBSITE_SITE_CONTEXT = composeWebsiteSiteContext({
+ *   rootConfig: WEBSITE_ROOT_CONFIG,
+ *   websiteConfig,
+ * });
+ * ```
+ */
+export function composeWebsiteSiteContext(parts) {
+    return Object.freeze({
+        rootConfig: parts.rootConfig,
+        websiteConfig: parts.websiteConfig,
+        frontendProviders: parts.frontendProviders,
+    });
+}
+/** @wildo_source:part:end saas.website.astro.site-context */
+//# sourceMappingURL=website-site-context.js.map

package/dist/esm/astro/website-site-context.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"website-site-context.js","sourceRoot":"","sources":["../../../../src/astro/website-site-context.ts"],"names":[],"mappings":"AAkGA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,MAAM,UAAU,yBAAyB,CACvC,KAAyB;IAEzB,OAAO,MAAM,CAAC,MAAM,CAAC;QACnB,UAAU,EAAE,KAAK,CAAC,UAAU;QAC5B,aAAa,EAAE,KAAK,CAAC,aAAa;QAClC,iBAAiB,EAAE,KAAK,CAAC,iBAAiB;KAC3C,CAAC,CAAC;AACL,CAAC;AACD,6DAA6D","sourcesContent":["import type { WildoMarketingWebsiteConfig } from '../config/wildo-website-config.schemas';\nimport type { WebsiteRootConfig } from '../schemas/manifests/website-root-config.shared.schemas';\nimport type { FrontendProvidersBlock } from '@wildo-ai/saas-models/public-runtime';\n\n/**\n * @wildo_source:part:start saas.website.astro.site-context facet:layer:astro facet:family:website\n *\n * `WebsiteSiteContext` — the aggregated site-level inputs every Astro\n * build-time engine helper consumes. Composes the consumer-authored\n * `WebsiteRootConfig` (page registry, design tokens, navigation chrome,\n * site-level SEO branding) with the per-service `WildoMarketingWebsiteConfig`\n * loaded from `wildo.website.config.ts` (locales, default locale,\n * public origin, future `appOrigin` cross-origin handoff target).\n *\n * # Why a dedicated aggregator type (vs. threading both raw configs)\n *\n * The seam-collapse (`saas-website-seam-collapse.md`, Option B) made\n * `WildoMarketingWebsiteConfig` the SINGLE source of truth for the\n * marketing-site routing surface (`defaultLocale`, `locales`,\n * `publicOrigin`). Every engine helper that previously read those\n * fields from `WebsiteRootConfig` now reads them from\n * `WildoMarketingWebsiteConfig` — and four out of five of those helpers\n * also still read OTHER fields from `WebsiteRootConfig` (page\n * manifests, chrome label keys, design tokens, `seo.siteName`,\n * `seo.defaultOgImageUrl`, `skipToMainContentLabelKey`). Threading\n * both raw configs through every helper signature would:\n *\n *   1. **Bloat call sites.** Every consumer `.astro` file would have\n *      to import both `WEBSITE_ROOT_CONFIG` and the loaded\n *      `WILDO_WEBSITE_CONFIG`, then forward both to every helper.\n *   2. **Spread the consumer-side composition responsibility.**\n *      Each `.astro` file would need to know which subset of the\n *      configs each helper consumes — a refactor hazard the next time\n *      we add a field that the head renderer reads from the website\n *      config but the runtime loader does not.\n *   3. **Defeat top-level `await` ergonomics.** The website config\n *      load is async (`loadWebsiteConfig` does jiti-backed file I/O);\n *      forcing every `.astro` file to `await` it would either spread\n *      the await across every page or force every page to receive the\n *      already-loaded config from a separate consumer module —\n *      duplicating the composition logic this aggregator centralizes.\n *\n * One aggregator, composed once at the consumer's\n * `<service-root>/src/website-site-context.ts`, is the minimum-blast\n * shape: every engine helper takes `siteContext: WebsiteSiteContext`,\n * every `.astro` file imports the singleton `WEBSITE_SITE_CONTEXT`\n * once, and the next field move (consumer-config-only field, or\n * root-config-only field) lands in this type's shape with no\n * helper-signature ripple.\n *\n * # Why frozen (defensive)\n *\n * The composed value is shared across every page render in the build\n * graph. A misbehaving Astro plugin (or a future consumer-side audit\n * subprocess) that mutated either nested config in place would\n * silently corrupt every subsequent page. `Object.freeze` is a cheap\n * top-level guard — the inner configs are themselves already produced\n * by Zod parsers (which return fresh objects), so mutating their\n * fields would require a deliberate `as any` cast at the consumer's\n * call site rather than an accidental in-place edit.\n *\n * # When this type WOULD grow\n *\n * Future inputs that are also \"site-wide\" but neither belong to\n * `WebsiteRootConfig` (chrome-rendered) nor to\n * `WildoMarketingWebsiteConfig` (per-service routing/origins) — e.g.\n * a build-environment block (`production` / `preview` / `dev`), or\n * a feature-flag bag — would land here as a third sibling field\n * rather than being plumbed through every helper signature\n * individually. The aggregator is the right place for that\n * orchestration concern; per-call ergonomics ride along for free.\n */\nexport interface WebsiteSiteContext {\n  /**\n   * The consumer's `WebsiteRootConfig` — page registry, design tokens,\n   * navigation chrome, site-level SEO branding (`siteName`,\n   * `defaultOgImageUrl?`), `chromeLabelKeys`,\n   * `skipToMainContentLabelKey`. Single source of truth for chrome\n   * + per-page meta declarations.\n   */\n  readonly rootConfig: WebsiteRootConfig;\n\n  /**\n   * The per-service `WildoMarketingWebsiteConfig` loaded from\n   * `wildo.website.config.ts`. Single source of truth for the\n   * marketing-site ROUTING + ORIGIN surface (`defaultLocale`,\n   * `locales`, `publicOrigin`, future `appOrigin`).\n   */\n  readonly websiteConfig: WildoMarketingWebsiteConfig;\n  /**\n   * Optional website-facing public provider block materialized from the\n   * app's provider graph for the concrete `STATIC_WEBSITE` service.\n   * Build-time only: the consumer loads it once and forwards it into the\n   * React island as JSON-serializable data.\n   */\n  readonly frontendProviders?: FrontendProvidersBlock;\n}\n\n/**\n * Compose a `WebsiteSiteContext` from the two source configs. Pure +\n * synchronous — the I/O happens upstream in `loadWebsiteConfig` and\n * in the consumer's `WEBSITE_ROOT_CONFIG` module evaluation.\n *\n * **Defensive freezing**: the returned object is `Object.freeze`-d\n * top-level so the singleton handed to every helper cannot have its\n * `rootConfig` / `websiteConfig` references swapped in place by a\n * misbehaving plugin. The nested configs are NOT deep-frozen — Zod\n * already produces fresh objects per parse, and a deep freeze would\n * cost a recursive walk per build for protection that no realistic\n * plugin would breach.\n *\n * @example\n * ```ts\n * // examples/<app>/website/src/website-site-context.ts\n * import { composeWebsiteSiteContext } from '@wildo-ai/saas-website/astro';\n * import { loadWebsiteConfig } from '@wildo-ai/saas-website/config-loader';\n *\n * import { WEBSITE_ROOT_CONFIG } from './website-root.config';\n *\n * const websiteConfig = await loadWebsiteConfig({ saasRoot: '...' });\n * export const WEBSITE_SITE_CONTEXT = composeWebsiteSiteContext({\n *   rootConfig: WEBSITE_ROOT_CONFIG,\n *   websiteConfig,\n * });\n * ```\n */\nexport function composeWebsiteSiteContext(\n  parts: WebsiteSiteContext,\n): WebsiteSiteContext {\n  return Object.freeze({\n    rootConfig: parts.rootConfig,\n    websiteConfig: parts.websiteConfig,\n    frontendProviders: parts.frontendProviders,\n  });\n}\n/** @wildo_source:part:end saas.website.astro.site-context */\n"]}

package/dist/esm/astro-island.d.ts

@@ -0,0 +1,56 @@
+/**
+ * @wildo-package @wildo-ai/saas-website (astro client-island sub-entry)
+ *
+ * Astro / React **client-island** sub-entry. This entry exposes ONLY
+ * `createWebsitePageBridgeIsland(...)` — the closure-based factory a
+ * consumer's per-page `*.bridge.tsx` module imports to mint the React
+ * island that an `.astro` page will hydrate with `client:idle` /
+ * `client:load`.
+ *
+ * **Why a dedicated subpath instead of folding into `./astro`**:
+ * Vite (Astro's bundler) must be able to follow every `import` from
+ * a client-bound module to a fully-resolvable browser graph. The
+ * `./astro` barrel re-exports Node-only helpers (`label-pack-loader`,
+ * `website-page-runtime.helper`, `website-page-head.renderer`, etc.)
+ * via `export *`, which forces Vite to RESOLVE `node:fs` / `node:path`
+ * for the client bundle even when the consumer only imports the
+ * bridge factory. Resolution happens BEFORE tree-shaking, so the
+ * unused Node imports surface as hard build errors
+ * (`"resolve" is not exported by "__vite-browser-external"`). Splitting
+ * the bridge factory into this dedicated entry keeps the client-side
+ * import graph 100% bundle-clean — Vite never has to resolve any
+ * Node specifier when following the consumer's `*.bridge.tsx` graph.
+ *
+ * @wildo-boundary
+ *   Strictly client-bundle-safe. MAY import:
+ *     - `react`, `react-dom`
+ *     - peer-shared shape modules from `@wildo-ai/saas-models/public-runtime`
+ *     - the framework's React layout / context modules (themselves bundle-clean)
+ *   MUST NOT import:
+ *     - `node:*` (any Node built-in)
+ *     - `fs`, `path`, or any filesystem / process helper
+ *     - the Astro runtime (`astro` package, `astro:*` virtual modules)
+ *     - SSR-tier specifiers (`axios`, `jsonwebtoken`, `socket.io-client`, …)
+ *
+ *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *   which walks `astro-island.ts` as one of `ENTRY_FILES` and runs a
+ *   targeted negative test that `node:fs` / `node:path` are NOT
+ *   reachable from this entry.
+ */
+export * from './astro/bridge-runtime';
+/**
+ * The marketing-blog adapter's per-locale bridge factory
+ * (`createWebsiteBlogPostBridgeIsland`) is DELIBERATELY NOT re-exported
+ * here, even though it lives beside `bridge-runtime.tsx` and follows the
+ * same closure-over-deps pattern. It hard-imports `../mdx/BlogPost`,
+ * whose `@mdx-js/react` peer is declared OPTIONAL — re-exporting it from
+ * this entry (the mandatory per-page bridge surface every marketing site
+ * consumes) made that optional peer a de-facto install requirement for
+ * every NON-blog site: Vite resolves the whole `export *` graph before
+ * tree-shaking, so a landing-page-only build failed on the unresolved
+ * `@mdx-js/react` specifier. Blog consumers import the factory from
+ * `@wildo-ai/saas-website/mdx` (the blog adapter's own entry) instead.
+ * Pinned by the "@mdx-js/react reaches the closure ONLY through mdx.ts"
+ * test in `__tests__/bundle-isolation.test.ts`.
+ */
+//# sourceMappingURL=astro-island.d.ts.map

package/dist/esm/astro-island.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"astro-island.d.ts","sourceRoot":"","sources":["../../../src/astro-island.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAOH,cAAc,wBAAwB,CAAC;AACvC;;;;;;;;;;;;;;GAcG"}

package/dist/esm/astro-island.js

@@ -0,0 +1,61 @@
+/**
+ * @wildo-package @wildo-ai/saas-website (astro client-island sub-entry)
+ *
+ * Astro / React **client-island** sub-entry. This entry exposes ONLY
+ * `createWebsitePageBridgeIsland(...)` — the closure-based factory a
+ * consumer's per-page `*.bridge.tsx` module imports to mint the React
+ * island that an `.astro` page will hydrate with `client:idle` /
+ * `client:load`.
+ *
+ * **Why a dedicated subpath instead of folding into `./astro`**:
+ * Vite (Astro's bundler) must be able to follow every `import` from
+ * a client-bound module to a fully-resolvable browser graph. The
+ * `./astro` barrel re-exports Node-only helpers (`label-pack-loader`,
+ * `website-page-runtime.helper`, `website-page-head.renderer`, etc.)
+ * via `export *`, which forces Vite to RESOLVE `node:fs` / `node:path`
+ * for the client bundle even when the consumer only imports the
+ * bridge factory. Resolution happens BEFORE tree-shaking, so the
+ * unused Node imports surface as hard build errors
+ * (`"resolve" is not exported by "__vite-browser-external"`). Splitting
+ * the bridge factory into this dedicated entry keeps the client-side
+ * import graph 100% bundle-clean — Vite never has to resolve any
+ * Node specifier when following the consumer's `*.bridge.tsx` graph.
+ *
+ * @wildo-boundary
+ *   Strictly client-bundle-safe. MAY import:
+ *     - `react`, `react-dom`
+ *     - peer-shared shape modules from `@wildo-ai/saas-models/public-runtime`
+ *     - the framework's React layout / context modules (themselves bundle-clean)
+ *   MUST NOT import:
+ *     - `node:*` (any Node built-in)
+ *     - `fs`, `path`, or any filesystem / process helper
+ *     - the Astro runtime (`astro` package, `astro:*` virtual modules)
+ *     - SSR-tier specifiers (`axios`, `jsonwebtoken`, `socket.io-client`, …)
+ *
+ *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *   which walks `astro-island.ts` as one of `ENTRY_FILES` and runs a
+ *   targeted negative test that `node:fs` / `node:path` are NOT
+ *   reachable from this entry.
+ */
+// entrypoint-waiver: this subpath is a BUNDLE-TIER boundary (the client-island entry Vite must be
+// able to resolve without any Node specifier — see the rationale above), not a file alias. It
+// re-exports a single module only since the blog bridge deliberately moved behind ./mdx to keep the
+// optional @mdx-js/react peer off non-blog consumers; the tier boundary itself is load-bearing and
+// walked as its own entry by the bundle-isolation test.
+export * from './astro/bridge-runtime.js';
+/**
+ * The marketing-blog adapter's per-locale bridge factory
+ * (`createWebsiteBlogPostBridgeIsland`) is DELIBERATELY NOT re-exported
+ * here, even though it lives beside `bridge-runtime.tsx` and follows the
+ * same closure-over-deps pattern. It hard-imports `../mdx/BlogPost`,
+ * whose `@mdx-js/react` peer is declared OPTIONAL — re-exporting it from
+ * this entry (the mandatory per-page bridge surface every marketing site
+ * consumes) made that optional peer a de-facto install requirement for
+ * every NON-blog site: Vite resolves the whole `export *` graph before
+ * tree-shaking, so a landing-page-only build failed on the unresolved
+ * `@mdx-js/react` specifier. Blog consumers import the factory from
+ * `@wildo-ai/saas-website/mdx` (the blog adapter's own entry) instead.
+ * Pinned by the "@mdx-js/react reaches the closure ONLY through mdx.ts"
+ * test in `__tests__/bundle-isolation.test.ts`.
+ */
+//# sourceMappingURL=astro-island.js.map

package/dist/esm/astro-island.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"astro-island.js","sourceRoot":"","sources":["../../../src/astro-island.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AACH,kGAAkG;AAClG,8FAA8F;AAC9F,oGAAoG;AACpG,mGAAmG;AACnG,wDAAwD;AAExD,cAAc,wBAAwB,CAAC;AACvC;;;;;;;;;;;;;;GAcG","sourcesContent":["/**\n * @wildo-package @wildo-ai/saas-website (astro client-island sub-entry)\n *\n * Astro / React **client-island** sub-entry. This entry exposes ONLY\n * `createWebsitePageBridgeIsland(...)` — the closure-based factory a\n * consumer's per-page `*.bridge.tsx` module imports to mint the React\n * island that an `.astro` page will hydrate with `client:idle` /\n * `client:load`.\n *\n * **Why a dedicated subpath instead of folding into `./astro`**:\n * Vite (Astro's bundler) must be able to follow every `import` from\n * a client-bound module to a fully-resolvable browser graph. The\n * `./astro` barrel re-exports Node-only helpers (`label-pack-loader`,\n * `website-page-runtime.helper`, `website-page-head.renderer`, etc.)\n * via `export *`, which forces Vite to RESOLVE `node:fs` / `node:path`\n * for the client bundle even when the consumer only imports the\n * bridge factory. Resolution happens BEFORE tree-shaking, so the\n * unused Node imports surface as hard build errors\n * (`\"resolve\" is not exported by \"__vite-browser-external\"`). Splitting\n * the bridge factory into this dedicated entry keeps the client-side\n * import graph 100% bundle-clean — Vite never has to resolve any\n * Node specifier when following the consumer's `*.bridge.tsx` graph.\n *\n * @wildo-boundary\n *   Strictly client-bundle-safe. MAY import:\n *     - `react`, `react-dom`\n *     - peer-shared shape modules from `@wildo-ai/saas-models/public-runtime`\n *     - the framework's React layout / context modules (themselves bundle-clean)\n *   MUST NOT import:\n *     - `node:*` (any Node built-in)\n *     - `fs`, `path`, or any filesystem / process helper\n *     - the Astro runtime (`astro` package, `astro:*` virtual modules)\n *     - SSR-tier specifiers (`axios`, `jsonwebtoken`, `socket.io-client`, …)\n *\n *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`\n *   which walks `astro-island.ts` as one of `ENTRY_FILES` and runs a\n *   targeted negative test that `node:fs` / `node:path` are NOT\n *   reachable from this entry.\n */\n// entrypoint-waiver: this subpath is a BUNDLE-TIER boundary (the client-island entry Vite must be\n// able to resolve without any Node specifier — see the rationale above), not a file alias. It\n// re-exports a single module only since the blog bridge deliberately moved behind ./mdx to keep the\n// optional @mdx-js/react peer off non-blog consumers; the tier boundary itself is load-bearing and\n// walked as its own entry by the bundle-isolation test.\n\nexport * from './astro/bridge-runtime';\n/**\n * The marketing-blog adapter's per-locale bridge factory\n * (`createWebsiteBlogPostBridgeIsland`) is DELIBERATELY NOT re-exported\n * here, even though it lives beside `bridge-runtime.tsx` and follows the\n * same closure-over-deps pattern. It hard-imports `../mdx/BlogPost`,\n * whose `@mdx-js/react` peer is declared OPTIONAL — re-exporting it from\n * this entry (the mandatory per-page bridge surface every marketing site\n * consumes) made that optional peer a de-facto install requirement for\n * every NON-blog site: Vite resolves the whole `export *` graph before\n * tree-shaking, so a landing-page-only build failed on the unresolved\n * `@mdx-js/react` specifier. Blog consumers import the factory from\n * `@wildo-ai/saas-website/mdx` (the blog adapter's own entry) instead.\n * Pinned by the \"@mdx-js/react reaches the closure ONLY through mdx.ts\"\n * test in `__tests__/bundle-isolation.test.ts`.\n */\n"]}

package/dist/esm/astro.d.ts

@@ -0,0 +1,151 @@
+/**
+ * @wildo-package @wildo-ai/saas-website (astro adapter SSR/frontmatter entry)
+ *
+ * Astro **frontmatter / SSR** sub-entry. Re-exports the TypeScript
+ * helpers a consumer's per-page `.astro` files consume INSIDE
+ * frontmatter to render a marketing-site page (locale resolution,
+ * label-pack loading, `<head>` HTML rendering, design-token CSS
+ * rendering, i18n routing config, expected-label-key collection).
+ *
+ * **The `createWebsitePageBridgeIsland` factory lives in a SEPARATE
+ * subpath — `@wildo-ai/saas-website/astro-island`** — and is NOT
+ * re-exported here. The split exists because the consumer's per-page
+ * `*.bridge.tsx` module is bundled into BOTH the SSR graph (via the
+ * `.astro` page that statically imports it) AND the client graph
+ * (Astro's hydration pipeline). Re-exporting the bridge factory
+ * alongside the Node-using helpers here would force Vite to resolve
+ * `node:fs` / `node:path` for the client bundle even though
+ * tree-shaking would later drop them — resolution happens BEFORE
+ * tree-shaking, so the build hard-fails with
+ * `"resolve" is not exported by "__vite-browser-external"`. The
+ * dedicated `astro-island` subpath keeps the client import graph
+ * 100% bundle-clean.
+ *
+ * **No `.astro` shell shipped.** The Phase-5 redesign deliberately
+ * removed the previously-planned `WebsitePageBridge.astro` shell
+ * because:
+ *   1. A `.astro` file cannot be re-exported from a TS subpath barrel
+ *      and `tsc` does not copy non-TS files to `dist/`, so the shell
+ *      was unreachable from `@wildo-ai/saas-website/astro`.
+ *   2. The shell would have had to pass `pageComponent` /
+ *      `headerComponent` / `footerComponent` (`ComponentType` refs)
+ *      as React-island props — Astro's `devalue`-style island prop
+ *      serialization cannot transport function values, so hydration
+ *      would have mismatched on first interaction.
+ * Both failure modes are sidestepped by giving consumers two
+ * primitive-string-only TS helpers (`renderWebsitePageHeadHtml`,
+ * `renderWebsiteDesignTokensCss`) for the Astro-side `<head>` work
+ * and a closure-based island factory (`createWebsitePageBridgeIsland`,
+ * exported from `@wildo-ai/saas-website/astro-island`) for the
+ * React-island side. The consumer authors a thin per-page `.astro`
+ * file that statically imports the per-page bridge island — Astro's
+ * compiler then resolves the `client:*` directive against a static
+ * module export, which is the only pattern that makes Astro's
+ * hydration bundling work correctly. See `bridge-runtime.tsx`'s
+ * file-level JSDoc for the full rationale.
+ *
+ * @wildo-boundary
+ *   This entry is on the SSR / Astro-build-time side of the bundle
+ *   boundary (D12 second loosening). It MAY import:
+ *     - `node:fs`, `node:path` (label-pack-loader, runtime-helper)
+ *   It MUST NOT import:
+ *     - the bridge-runtime module — that module ships into the
+ *       client island bundle and is exposed via the
+ *       `@wildo-ai/saas-website/astro-island` subpath instead.
+ *     - the Astro runtime (`astro` package, `astro:*` virtual modules)
+ *       — those live exclusively inside `.astro` files. Adding
+ *       `astro` here would make the engine package unimportable
+ *       from any context that does not boot the Astro compiler
+ *       (Vitest tests, the `wildo website audit` CLI, companion
+ *       subprocesses).
+ *
+ *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *   which walks `astro.ts` as one of `ENTRY_FILES` AND runs a targeted
+ *   negative test that `node:fs` / `node:path` are reachable from
+ *   `astro.ts` ONLY — never from `index.ts`, `companion-exports.ts`,
+ *   or `astro-island.ts`.
+ */
+export * from './astro/website-site-context';
+export * from './astro/i18n-routing.helper';
+export * from './astro/collect-expected-label-keys';
+export * from './astro/label-pack-loader';
+/**
+ * `pick-labels-for-page` is INTENTIONALLY NOT re-exported here.
+ * It is an internal helper consumed only by `loadWebsitePageRuntime`
+ * (which IS exported via the runtime helper below). Exposing it as a
+ * public sub-entry surface would (a) invite consumers to call it
+ * directly from `.astro` frontmatter — which they should never do
+ * (the runtime helper already wires the slicing transparently), and
+ * (b) lock the engine into an extra public API the audit step would
+ * have to keep stable. Tests import the helper via its relative
+ * path, which keeps the behavior covered without leaking the surface.
+ * (Phase 6 audit fix M-B.)
+ */
+export * from './astro/website-page-runtime.helper';
+export * from './astro/website-page-head.renderer';
+export * from './astro/structured-data.renderer';
+/**
+ * Phase 7 — sibling head renderer for blog posts. Reads from a
+ * validated `BlogPostFrontmatter` instead of the page manifest's
+ * `metaLabelKeys`; emits `og:type=article` plus the
+ * `article:published_time` / `article:author` / `article:tag` lines
+ * the OG "article" vertical requires. See the renderer file's
+ * preamble for why this is a sibling rather than a flag on
+ * `renderWebsitePageHeadHtml`.
+ */
+export * from './astro/blog-post-head.renderer';
+/**
+ * Phase 8 close-out — `renderRobotsTxt(siteContext)` pure string
+ * builder for the marketing site's `robots.txt` body. Sibling of
+ * `renderWebsitePageHeadHtml` (same Astro-frontmatter consumption
+ * shape: pure TypeScript, no Astro runtime dependency, vitest-
+ * friendly). See `engine/saas-website/src/astro/robots-renderer.ts`
+ * for the field-by-field rationale and
+ * `.cursor/plans/saas-website-seo-sitemap.md` for the slice context.
+ */
+export * from './astro/robots-renderer';
+/**
+ * Phase 8 close-out — `enumerateMarketingPageSitemapUrls(siteContext)`
+ * pure helper that returns every (page-manifest × locale) absolute
+ * URL the marketing site's sitemap MUST advertise, paired with its
+ * hreflang alternates. Two consumption surfaces:
+ *
+ *   1. Vitest enforcement — a regression that drops a manifest-
+ *      registered route fails fast in unit tests, well before
+ *      `astro build` would surface it.
+ *   2. `@astrojs/sitemap` `customPages` integration — when the
+ *      consumer needs to surface routes Astro's file-based router
+ *      cannot auto-discover (data-driven landing variants, etc.),
+ *      this helper computes the canonical URL list to spread into
+ *      the plugin config.
+ *
+ * See `engine/saas-website/src/astro/sitemap-coverage.ts` and
+ * `.cursor/plans/saas-website-seo-sitemap.md` for the full
+ * rationale + scope boundary.
+ */
+export * from './astro/sitemap-coverage';
+/**
+ * AEO — `renderPageStructuredData(opts)` pure string builder that
+ * collects every section's `getStructuredData()` (when present),
+ * dedupes by `@id`, and emits one
+ * `<script type="application/ld+json">` block per surviving payload.
+ * Sibling of `renderWebsitePageHeadHtml` (same pure-TS, vitest-
+ * friendly contract). See
+ * `engine/saas-website/src/astro/structured-data.renderer.ts`
+ * for the safety + dedupe semantics and
+ * `.cursor/plans/saas-website-aeo-geo.md` for the slice context.
+ */
+export * from './astro/structured-data.renderer';
+export * from './astro/headers-renderer';
+export * from './astro/llms-txt-server';
+/**
+ * AEO — runtime payload type (`WebsiteStructuredDataPayload`) and
+ * convenience return-shape union (`WebsiteStructuredDataReturn`)
+ * the section author imports to type their `getStructuredData()`.
+ * Defined locally in `saas-website` (not in `saas-specifications`)
+ * because the runtime engine cannot depend on the spec layer; the
+ * companion catalog at `_catalogs/schema-org/` describes the same
+ * vocabulary at the COMPANION layer.
+ */
+export * from './schemas/structured-data/website-structured-data.shared.schemas';
+//# sourceMappingURL=astro.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"astro.d.ts","sourceRoot":"","sources":["../../../src/astro.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkEG;AAEH,cAAc,8BAA8B,CAAC;AAC7C,cAAc,6BAA6B,CAAC;AAC5C,cAAc,qCAAqC,CAAC;AACpD,cAAc,2BAA2B,CAAC;AAC1C;;;;;;;;;;;GAWG;AACH,cAAc,qCAAqC,CAAC;AACpD,cAAc,oCAAoC,CAAC;AACnD,cAAc,kCAAkC,CAAC;AACjD;;;;;;;;GAQG;AACH,cAAc,iCAAiC,CAAC;AAChD;;;;;;;;GAQG;AACH,cAAc,yBAAyB,CAAC;AACxC;;;;;;;;;;;;;;;;;;GAkBG;AACH,cAAc,0BAA0B,CAAC;AACzC;;;;;;;;;;GAUG;AACH,cAAc,kCAAkC,CAAC;AACjD,cAAc,0BAA0B,CAAC;AACzC,cAAc,yBAAyB,CAAC;AACxC;;;;;;;;GAQG;AACH,cAAc,kEAAkE,CAAC"}

package/dist/esm/astro.js

@@ -0,0 +1,151 @@
+/**
+ * @wildo-package @wildo-ai/saas-website (astro adapter SSR/frontmatter entry)
+ *
+ * Astro **frontmatter / SSR** sub-entry. Re-exports the TypeScript
+ * helpers a consumer's per-page `.astro` files consume INSIDE
+ * frontmatter to render a marketing-site page (locale resolution,
+ * label-pack loading, `<head>` HTML rendering, design-token CSS
+ * rendering, i18n routing config, expected-label-key collection).
+ *
+ * **The `createWebsitePageBridgeIsland` factory lives in a SEPARATE
+ * subpath — `@wildo-ai/saas-website/astro-island`** — and is NOT
+ * re-exported here. The split exists because the consumer's per-page
+ * `*.bridge.tsx` module is bundled into BOTH the SSR graph (via the
+ * `.astro` page that statically imports it) AND the client graph
+ * (Astro's hydration pipeline). Re-exporting the bridge factory
+ * alongside the Node-using helpers here would force Vite to resolve
+ * `node:fs` / `node:path` for the client bundle even though
+ * tree-shaking would later drop them — resolution happens BEFORE
+ * tree-shaking, so the build hard-fails with
+ * `"resolve" is not exported by "__vite-browser-external"`. The
+ * dedicated `astro-island` subpath keeps the client import graph
+ * 100% bundle-clean.
+ *
+ * **No `.astro` shell shipped.** The Phase-5 redesign deliberately
+ * removed the previously-planned `WebsitePageBridge.astro` shell
+ * because:
+ *   1. A `.astro` file cannot be re-exported from a TS subpath barrel
+ *      and `tsc` does not copy non-TS files to `dist/`, so the shell
+ *      was unreachable from `@wildo-ai/saas-website/astro`.
+ *   2. The shell would have had to pass `pageComponent` /
+ *      `headerComponent` / `footerComponent` (`ComponentType` refs)
+ *      as React-island props — Astro's `devalue`-style island prop
+ *      serialization cannot transport function values, so hydration
+ *      would have mismatched on first interaction.
+ * Both failure modes are sidestepped by giving consumers two
+ * primitive-string-only TS helpers (`renderWebsitePageHeadHtml`,
+ * `renderWebsiteDesignTokensCss`) for the Astro-side `<head>` work
+ * and a closure-based island factory (`createWebsitePageBridgeIsland`,
+ * exported from `@wildo-ai/saas-website/astro-island`) for the
+ * React-island side. The consumer authors a thin per-page `.astro`
+ * file that statically imports the per-page bridge island — Astro's
+ * compiler then resolves the `client:*` directive against a static
+ * module export, which is the only pattern that makes Astro's
+ * hydration bundling work correctly. See `bridge-runtime.tsx`'s
+ * file-level JSDoc for the full rationale.
+ *
+ * @wildo-boundary
+ *   This entry is on the SSR / Astro-build-time side of the bundle
+ *   boundary (D12 second loosening). It MAY import:
+ *     - `node:fs`, `node:path` (label-pack-loader, runtime-helper)
+ *   It MUST NOT import:
+ *     - the bridge-runtime module — that module ships into the
+ *       client island bundle and is exposed via the
+ *       `@wildo-ai/saas-website/astro-island` subpath instead.
+ *     - the Astro runtime (`astro` package, `astro:*` virtual modules)
+ *       — those live exclusively inside `.astro` files. Adding
+ *       `astro` here would make the engine package unimportable
+ *       from any context that does not boot the Astro compiler
+ *       (Vitest tests, the `wildo website audit` CLI, companion
+ *       subprocesses).
+ *
+ *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`
+ *   which walks `astro.ts` as one of `ENTRY_FILES` AND runs a targeted
+ *   negative test that `node:fs` / `node:path` are reachable from
+ *   `astro.ts` ONLY — never from `index.ts`, `companion-exports.ts`,
+ *   or `astro-island.ts`.
+ */
+export * from './astro/website-site-context.js';
+export * from './astro/i18n-routing.helper.js';
+export * from './astro/collect-expected-label-keys.js';
+export * from './astro/label-pack-loader.js';
+/**
+ * `pick-labels-for-page` is INTENTIONALLY NOT re-exported here.
+ * It is an internal helper consumed only by `loadWebsitePageRuntime`
+ * (which IS exported via the runtime helper below). Exposing it as a
+ * public sub-entry surface would (a) invite consumers to call it
+ * directly from `.astro` frontmatter — which they should never do
+ * (the runtime helper already wires the slicing transparently), and
+ * (b) lock the engine into an extra public API the audit step would
+ * have to keep stable. Tests import the helper via its relative
+ * path, which keeps the behavior covered without leaking the surface.
+ * (Phase 6 audit fix M-B.)
+ */
+export * from './astro/website-page-runtime.helper.js';
+export * from './astro/website-page-head.renderer.js';
+export * from './astro/structured-data.renderer.js';
+/**
+ * Phase 7 — sibling head renderer for blog posts. Reads from a
+ * validated `BlogPostFrontmatter` instead of the page manifest's
+ * `metaLabelKeys`; emits `og:type=article` plus the
+ * `article:published_time` / `article:author` / `article:tag` lines
+ * the OG "article" vertical requires. See the renderer file's
+ * preamble for why this is a sibling rather than a flag on
+ * `renderWebsitePageHeadHtml`.
+ */
+export * from './astro/blog-post-head.renderer.js';
+/**
+ * Phase 8 close-out — `renderRobotsTxt(siteContext)` pure string
+ * builder for the marketing site's `robots.txt` body. Sibling of
+ * `renderWebsitePageHeadHtml` (same Astro-frontmatter consumption
+ * shape: pure TypeScript, no Astro runtime dependency, vitest-
+ * friendly). See `engine/saas-website/src/astro/robots-renderer.ts`
+ * for the field-by-field rationale and
+ * `.cursor/plans/saas-website-seo-sitemap.md` for the slice context.
+ */
+export * from './astro/robots-renderer.js';
+/**
+ * Phase 8 close-out — `enumerateMarketingPageSitemapUrls(siteContext)`
+ * pure helper that returns every (page-manifest × locale) absolute
+ * URL the marketing site's sitemap MUST advertise, paired with its
+ * hreflang alternates. Two consumption surfaces:
+ *
+ *   1. Vitest enforcement — a regression that drops a manifest-
+ *      registered route fails fast in unit tests, well before
+ *      `astro build` would surface it.
+ *   2. `@astrojs/sitemap` `customPages` integration — when the
+ *      consumer needs to surface routes Astro's file-based router
+ *      cannot auto-discover (data-driven landing variants, etc.),
+ *      this helper computes the canonical URL list to spread into
+ *      the plugin config.
+ *
+ * See `engine/saas-website/src/astro/sitemap-coverage.ts` and
+ * `.cursor/plans/saas-website-seo-sitemap.md` for the full
+ * rationale + scope boundary.
+ */
+export * from './astro/sitemap-coverage.js';
+/**
+ * AEO — `renderPageStructuredData(opts)` pure string builder that
+ * collects every section's `getStructuredData()` (when present),
+ * dedupes by `@id`, and emits one
+ * `<script type="application/ld+json">` block per surviving payload.
+ * Sibling of `renderWebsitePageHeadHtml` (same pure-TS, vitest-
+ * friendly contract). See
+ * `engine/saas-website/src/astro/structured-data.renderer.ts`
+ * for the safety + dedupe semantics and
+ * `.cursor/plans/saas-website-aeo-geo.md` for the slice context.
+ */
+export * from './astro/structured-data.renderer.js';
+export * from './astro/headers-renderer.js';
+export * from './astro/llms-txt-server.js';
+/**
+ * AEO — runtime payload type (`WebsiteStructuredDataPayload`) and
+ * convenience return-shape union (`WebsiteStructuredDataReturn`)
+ * the section author imports to type their `getStructuredData()`.
+ * Defined locally in `saas-website` (not in `saas-specifications`)
+ * because the runtime engine cannot depend on the spec layer; the
+ * companion catalog at `_catalogs/schema-org/` describes the same
+ * vocabulary at the COMPANION layer.
+ */
+export * from './schemas/structured-data/website-structured-data.shared.schemas.js';
+//# sourceMappingURL=astro.js.map

package/dist/esm/astro.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"astro.js","sourceRoot":"","sources":["../../../src/astro.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkEG;AAEH,cAAc,8BAA8B,CAAC;AAC7C,cAAc,6BAA6B,CAAC;AAC5C,cAAc,qCAAqC,CAAC;AACpD,cAAc,2BAA2B,CAAC;AAC1C;;;;;;;;;;;GAWG;AACH,cAAc,qCAAqC,CAAC;AACpD,cAAc,oCAAoC,CAAC;AACnD,cAAc,kCAAkC,CAAC;AACjD;;;;;;;;GAQG;AACH,cAAc,iCAAiC,CAAC;AAChD;;;;;;;;GAQG;AACH,cAAc,yBAAyB,CAAC;AACxC;;;;;;;;;;;;;;;;;;GAkBG;AACH,cAAc,0BAA0B,CAAC;AACzC;;;;;;;;;;GAUG;AACH,cAAc,kCAAkC,CAAC;AACjD,cAAc,0BAA0B,CAAC;AACzC,cAAc,yBAAyB,CAAC;AACxC;;;;;;;;GAQG;AACH,cAAc,kEAAkE,CAAC","sourcesContent":["/**\n * @wildo-package @wildo-ai/saas-website (astro adapter SSR/frontmatter entry)\n *\n * Astro **frontmatter / SSR** sub-entry. Re-exports the TypeScript\n * helpers a consumer's per-page `.astro` files consume INSIDE\n * frontmatter to render a marketing-site page (locale resolution,\n * label-pack loading, `<head>` HTML rendering, design-token CSS\n * rendering, i18n routing config, expected-label-key collection).\n *\n * **The `createWebsitePageBridgeIsland` factory lives in a SEPARATE\n * subpath — `@wildo-ai/saas-website/astro-island`** — and is NOT\n * re-exported here. The split exists because the consumer's per-page\n * `*.bridge.tsx` module is bundled into BOTH the SSR graph (via the\n * `.astro` page that statically imports it) AND the client graph\n * (Astro's hydration pipeline). Re-exporting the bridge factory\n * alongside the Node-using helpers here would force Vite to resolve\n * `node:fs` / `node:path` for the client bundle even though\n * tree-shaking would later drop them — resolution happens BEFORE\n * tree-shaking, so the build hard-fails with\n * `\"resolve\" is not exported by \"__vite-browser-external\"`. The\n * dedicated `astro-island` subpath keeps the client import graph\n * 100% bundle-clean.\n *\n * **No `.astro` shell shipped.** The Phase-5 redesign deliberately\n * removed the previously-planned `WebsitePageBridge.astro` shell\n * because:\n *   1. A `.astro` file cannot be re-exported from a TS subpath barrel\n *      and `tsc` does not copy non-TS files to `dist/`, so the shell\n *      was unreachable from `@wildo-ai/saas-website/astro`.\n *   2. The shell would have had to pass `pageComponent` /\n *      `headerComponent` / `footerComponent` (`ComponentType` refs)\n *      as React-island props — Astro's `devalue`-style island prop\n *      serialization cannot transport function values, so hydration\n *      would have mismatched on first interaction.\n * Both failure modes are sidestepped by giving consumers two\n * primitive-string-only TS helpers (`renderWebsitePageHeadHtml`,\n * `renderWebsiteDesignTokensCss`) for the Astro-side `<head>` work\n * and a closure-based island factory (`createWebsitePageBridgeIsland`,\n * exported from `@wildo-ai/saas-website/astro-island`) for the\n * React-island side. The consumer authors a thin per-page `.astro`\n * file that statically imports the per-page bridge island — Astro's\n * compiler then resolves the `client:*` directive against a static\n * module export, which is the only pattern that makes Astro's\n * hydration bundling work correctly. See `bridge-runtime.tsx`'s\n * file-level JSDoc for the full rationale.\n *\n * @wildo-boundary\n *   This entry is on the SSR / Astro-build-time side of the bundle\n *   boundary (D12 second loosening). It MAY import:\n *     - `node:fs`, `node:path` (label-pack-loader, runtime-helper)\n *   It MUST NOT import:\n *     - the bridge-runtime module — that module ships into the\n *       client island bundle and is exposed via the\n *       `@wildo-ai/saas-website/astro-island` subpath instead.\n *     - the Astro runtime (`astro` package, `astro:*` virtual modules)\n *       — those live exclusively inside `.astro` files. Adding\n *       `astro` here would make the engine package unimportable\n *       from any context that does not boot the Astro compiler\n *       (Vitest tests, the `wildo website audit` CLI, companion\n *       subprocesses).\n *\n *   Enforced by `engine/saas-website/src/__tests__/bundle-isolation.test.ts`\n *   which walks `astro.ts` as one of `ENTRY_FILES` AND runs a targeted\n *   negative test that `node:fs` / `node:path` are reachable from\n *   `astro.ts` ONLY — never from `index.ts`, `companion-exports.ts`,\n *   or `astro-island.ts`.\n */\n\nexport * from './astro/website-site-context';\nexport * from './astro/i18n-routing.helper';\nexport * from './astro/collect-expected-label-keys';\nexport * from './astro/label-pack-loader';\n/**\n * `pick-labels-for-page` is INTENTIONALLY NOT re-exported here.\n * It is an internal helper consumed only by `loadWebsitePageRuntime`\n * (which IS exported via the runtime helper below). Exposing it as a\n * public sub-entry surface would (a) invite consumers to call it\n * directly from `.astro` frontmatter — which they should never do\n * (the runtime helper already wires the slicing transparently), and\n * (b) lock the engine into an extra public API the audit step would\n * have to keep stable. Tests import the helper via its relative\n * path, which keeps the behavior covered without leaking the surface.\n * (Phase 6 audit fix M-B.)\n */\nexport * from './astro/website-page-runtime.helper';\nexport * from './astro/website-page-head.renderer';\nexport * from './astro/structured-data.renderer';\n/**\n * Phase 7 — sibling head renderer for blog posts. Reads from a\n * validated `BlogPostFrontmatter` instead of the page manifest's\n * `metaLabelKeys`; emits `og:type=article` plus the\n * `article:published_time` / `article:author` / `article:tag` lines\n * the OG \"article\" vertical requires. See the renderer file's\n * preamble for why this is a sibling rather than a flag on\n * `renderWebsitePageHeadHtml`.\n */\nexport * from './astro/blog-post-head.renderer';\n/**\n * Phase 8 close-out — `renderRobotsTxt(siteContext)` pure string\n * builder for the marketing site's `robots.txt` body. Sibling of\n * `renderWebsitePageHeadHtml` (same Astro-frontmatter consumption\n * shape: pure TypeScript, no Astro runtime dependency, vitest-\n * friendly). See `engine/saas-website/src/astro/robots-renderer.ts`\n * for the field-by-field rationale and\n * `.cursor/plans/saas-website-seo-sitemap.md` for the slice context.\n */\nexport * from './astro/robots-renderer';\n/**\n * Phase 8 close-out — `enumerateMarketingPageSitemapUrls(siteContext)`\n * pure helper that returns every (page-manifest × locale) absolute\n * URL the marketing site's sitemap MUST advertise, paired with its\n * hreflang alternates. Two consumption surfaces:\n *\n *   1. Vitest enforcement — a regression that drops a manifest-\n *      registered route fails fast in unit tests, well before\n *      `astro build` would surface it.\n *   2. `@astrojs/sitemap` `customPages` integration — when the\n *      consumer needs to surface routes Astro's file-based router\n *      cannot auto-discover (data-driven landing variants, etc.),\n *      this helper computes the canonical URL list to spread into\n *      the plugin config.\n *\n * See `engine/saas-website/src/astro/sitemap-coverage.ts` and\n * `.cursor/plans/saas-website-seo-sitemap.md` for the full\n * rationale + scope boundary.\n */\nexport * from './astro/sitemap-coverage';\n/**\n * AEO — `renderPageStructuredData(opts)` pure string builder that\n * collects every section's `getStructuredData()` (when present),\n * dedupes by `@id`, and emits one\n * `<script type=\"application/ld+json\">` block per surviving payload.\n * Sibling of `renderWebsitePageHeadHtml` (same pure-TS, vitest-\n * friendly contract). See\n * `engine/saas-website/src/astro/structured-data.renderer.ts`\n * for the safety + dedupe semantics and\n * `.cursor/plans/saas-website-aeo-geo.md` for the slice context.\n */\nexport * from './astro/structured-data.renderer';\nexport * from './astro/headers-renderer';\nexport * from './astro/llms-txt-server';\n/**\n * AEO — runtime payload type (`WebsiteStructuredDataPayload`) and\n * convenience return-shape union (`WebsiteStructuredDataReturn`)\n * the section author imports to type their `getStructuredData()`.\n * Defined locally in `saas-website` (not in `saas-specifications`)\n * because the runtime engine cannot depend on the spec layer; the\n * companion catalog at `_catalogs/schema-org/` describes the same\n * vocabulary at the COMPANION layer.\n */\nexport * from './schemas/structured-data/website-structured-data.shared.schemas';\n"]}