@wildo-ai/saas-website 1.1.1

package/src/config/__tests__/load-website-config.test.ts

@@ -0,0 +1,215 @@
+/**
+ * `loadWebsiteConfig` discovery + memoization contract.
+ *
+ * Pins the per-service `wildo.website.config.ts` lookup behavior the
+ * Astro build / dev pipeline depends on (Step 7.5 refactor —
+ * `saas-website-slice.md`, mirrors
+ * `platform/factory/wildo-dev-companion/src/technical-doc/services/__tests__/technical-doc.publish-openapi.service.test.ts`'s
+ * `cachedTechnicalDocConfig` pre-population trick to skip the jiti
+ * round-trip).
+ *
+ * The harness uses {@link primeWebsiteConfigCache} to inject the
+ * loader's memoized value for the resolved absolute path BEFORE the
+ * production loader gets a chance to read disk via jiti — keeping
+ * the test pure (no `.ts` evaluation, no temp directories) while
+ * still exercising every branch of the discovery + path-resolution
+ * + cache-hit logic. The "missing service" / "missing file" paths
+ * are exercised by NOT priming and pointing at an obviously-missing
+ * service, so they hit the throw branches directly.
+ */
+
+import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
+import { mkdirSync, mkdtempSync, rmSync, writeFileSync } from 'node:fs';
+import { tmpdir } from 'node:os';
+import { resolve as resolvePath } from 'node:path';
+import {
+  AppFrontendType,
+  loadConfig,
+  type WildoSaasConfig,
+} from '@wildo-ai/platform-config-lib';
+import { AvailableLanguage } from '@wildo-ai/saas-models/public-runtime';
+import {
+  PER_SERVICE_WEBSITE_CONFIG_FILE_NAME,
+  clearWebsiteConfigCache,
+  loadWebsiteConfig,
+  primeWebsiteConfigCache,
+} from '../load-website-config';
+import type { WildoMarketingWebsiteConfig } from '../wildo-website-config.schemas';
+
+/**
+ * Partial-mock pattern: only `loadConfig` is faked; `AppFrontendType`
+ * (and any other re-export) keeps its real value so the test can still
+ * declare service stubs against the production enum.
+ *
+ * Mocking `node:fs.existsSync` via `vi.mock` is unreliable on Node
+ * builtins under vitest 1.6 (the `node:` prefix routes through the
+ * Node native loader before vitest's interception layer); for the
+ * one test that needs `existsSync` to return `true` so the loader
+ * proceeds to `loadConfig`, we materialize a real config file in a
+ * tmpdir-rooted SAAS_ROOT instead of mocking the FS primitive.
+ */
+vi.mock('@wildo-ai/platform-config-lib', async (importOriginal) => {
+  const actual =
+    await importOriginal<typeof import('@wildo-ai/platform-config-lib')>();
+  return {
+    ...actual,
+    loadConfig: vi.fn(actual.loadConfig),
+  };
+});
+
+beforeEach(() => {
+  clearWebsiteConfigCache();
+  vi.mocked(loadConfig).mockReset();
+});
+
+afterEach(() => {
+  clearWebsiteConfigCache();
+  vi.restoreAllMocks();
+});
+
+const SAAS_ROOT = '/tmp/test-saas-root-doesnt-need-to-exist';
+
+const VALID_WEBSITE_CONFIG: WildoMarketingWebsiteConfig = {
+  publicOrigin: 'https://wonder-todos.example.com',
+  appOrigin: 'https://app.wonder-todos.example.com',
+  defaultLocale: AvailableLanguage.EN,
+  locales: [
+    { locale: AvailableLanguage.EN, path: 'en' },
+    { locale: AvailableLanguage.FR, path: 'fr' },
+  ],
+};
+
+/**
+ * Build a partial `WildoSaasConfig` containing only the fields the
+ * loader reads (the `services` map). `WildoSaasConfig` itself carries
+ * the full shape, but the loader narrows to `services` immediately —
+ * casting through `unknown` keeps the harness focused on the loader's
+ * actual contract instead of forcing every test to author a fully
+ * valid `WildoSaasConfig` payload.
+ */
+function buildSaasConfigStub(
+  services: Record<string, { path: string; frontendType?: AppFrontendType }>,
+): WildoSaasConfig {
+  return { services } as unknown as WildoSaasConfig;
+}
+
+describe('loadWebsiteConfig — discovery contract', () => {
+  it('returns the primed cached config when STATIC_WEBSITE service exists', async () => {
+    const websiteServicePath = './website';
+    const expectedConfigPath = resolvePath(
+      SAAS_ROOT,
+      websiteServicePath,
+      PER_SERVICE_WEBSITE_CONFIG_FILE_NAME,
+    );
+    primeWebsiteConfigCache(expectedConfigPath, VALID_WEBSITE_CONFIG);
+
+    const saasConfig = buildSaasConfigStub({
+      backendApi: { path: './backend-api' },
+      website: { path: websiteServicePath, frontendType: AppFrontendType.STATIC_WEBSITE },
+    });
+
+    const result = await loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig });
+    expect(result).toEqual(VALID_WEBSITE_CONFIG);
+  });
+
+  it('discovers the website service by frontendType (NOT by service-key convention)', async () => {
+    const websiteServicePath = './marketing';
+    const expectedConfigPath = resolvePath(
+      SAAS_ROOT,
+      websiteServicePath,
+      PER_SERVICE_WEBSITE_CONFIG_FILE_NAME,
+    );
+    primeWebsiteConfigCache(expectedConfigPath, VALID_WEBSITE_CONFIG);
+
+    // Note: service key is `'marketing'` (NOT `'website'`); the loader
+    // MUST find it via `frontendType: STATIC_WEBSITE` lookup, not by
+    // grepping for a magic key name.
+    const saasConfig = buildSaasConfigStub({
+      marketing: { path: websiteServicePath, frontendType: AppFrontendType.STATIC_WEBSITE },
+    });
+
+    const result = await loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig });
+    expect(result).toEqual(VALID_WEBSITE_CONFIG);
+  });
+
+  it('memoizes — second call returns the same reference without rehitting the cache map lookup', async () => {
+    const websiteServicePath = './website';
+    const expectedConfigPath = resolvePath(
+      SAAS_ROOT,
+      websiteServicePath,
+      PER_SERVICE_WEBSITE_CONFIG_FILE_NAME,
+    );
+    primeWebsiteConfigCache(expectedConfigPath, VALID_WEBSITE_CONFIG);
+
+    const saasConfig = buildSaasConfigStub({
+      website: { path: websiteServicePath, frontendType: AppFrontendType.STATIC_WEBSITE },
+    });
+
+    const first = await loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig });
+    const second = await loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig });
+    expect(first).toBe(second);
+  });
+
+  it('throws when no STATIC_WEBSITE service is declared (missing-service guard)', async () => {
+    const saasConfig = buildSaasConfigStub({
+      backendApi: { path: './backend-api' },
+      app: { path: './app', frontendType: AppFrontendType.SAAS_APP },
+    });
+
+    await expect(loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig })).rejects.toThrow(
+      /\[wildo-website-config\] No frontend service with `frontendType: STATIC_WEBSITE`/,
+    );
+  });
+
+  it('throws when the STATIC_WEBSITE service is declared but the per-service config file is missing', async () => {
+    const websiteServicePath = './website-no-file';
+    const saasConfig = buildSaasConfigStub({
+      website: { path: websiteServicePath, frontendType: AppFrontendType.STATIC_WEBSITE },
+    });
+
+    // Cache NOT primed → loader proceeds to existsSync(...) which
+    // returns false for the bogus SAAS_ROOT path.
+    await expect(loadWebsiteConfig({ saasRoot: SAAS_ROOT, saasConfig })).rejects.toThrow(
+      /\[wildo-website-config\].*wildo\.website\.config\.ts.*is missing/,
+    );
+  });
+
+  it('wraps a `loadConfig` (jiti) failure with the [wildo-website-config] CONFIGURATION-style message', async () => {
+    /**
+     * Materialize a real per-service config file in a tmpdir so the
+     * loader's `existsSync` guard returns `true` for real, then
+     * intercept the jiti-backed `loadConfig` to simulate a parse /
+     * default-export failure (the realistic root cause of this
+     * branch — `process.stderr` warnings cannot fail it; only
+     * jiti can).
+     */
+    const tmpRoot = mkdtempSync(resolvePath(tmpdir(), 'wildo-website-loader-'));
+    try {
+      const websiteServicePath = './website-bad-export';
+      const websiteServiceDir = resolvePath(tmpRoot, websiteServicePath);
+      mkdirSync(websiteServiceDir, { recursive: true });
+      writeFileSync(
+        resolvePath(websiteServiceDir, PER_SERVICE_WEBSITE_CONFIG_FILE_NAME),
+        '// placeholder — content does not matter; loadConfig is mocked\n',
+        'utf-8',
+      );
+
+      const saasConfig = buildSaasConfigStub({
+        website: { path: websiteServicePath, frontendType: AppFrontendType.STATIC_WEBSITE },
+      });
+
+      vi.mocked(loadConfig).mockRejectedValue(
+        new Error('jiti: Cannot find default export'),
+      );
+
+      await expect(loadWebsiteConfig({ saasRoot: tmpRoot, saasConfig })).rejects.toThrow(
+        /\[wildo-website-config\] Failed to load per-service marketing-website config/,
+      );
+      await expect(loadWebsiteConfig({ saasRoot: tmpRoot, saasConfig })).rejects.toThrow(
+        /Cause: jiti: Cannot find default export/,
+      );
+    } finally {
+      rmSync(tmpRoot, { recursive: true, force: true });
+    }
+  });
+});

package/src/config/define-website-config.ts

@@ -0,0 +1,134 @@
+/**
+ * @fileoverview Author helper for `wildo.website.config.ts` files.
+ *
+ * `defineWebsiteConfig({...})` mirrors the `defineSaasConfig` /
+ * `defineInfraEnvConfig` helpers from `@wildo-ai/platform-config-lib`
+ * and `defineTechnicalDocConfig` from `@wildo-ai/saas-technical-doc`:
+ * it wraps `WildoMarketingWebsiteConfigSchema.parse(...)` with full
+ * IDE autocompletion on the input shape, and emits a parse-time
+ * stderr warning for any authored field that has no runtime
+ * consumer yet.
+ *
+ * # `@unimplemented` channel — current state
+ *
+ * The warner has ZERO branches today because every OPTIONAL field that
+ * exists is already wired (`csp?` now flows through the website-local
+ * CSP sync step) and the only unwired field left is `appOrigin`, which
+ * is REQUIRED. After the seam-collapse (`saas-website-seam-collapse.md`
+ * — SHIPPED), the routing/origin fields (`publicOrigin`,
+ * `defaultLocale`, `locales`) are consumed directly by every Astro
+ * engine helper via `WebsiteSiteContext`, so they are no longer
+ * candidates for a "deferred wiring" warning either. The
+ * `@unimplemented` warner is for fields that are parsed-but-unused AND
+ * opt-in — firing on every Astro build for a required field would drown
+ * the dev console.
+ *
+ * Two valid futures will trigger adding warner branches:
+ *   1. A future optional field lands (e.g. `seo?.{title,description}`,
+ *      `structuredData?.organization`) whose runtime wiring ships
+ *      in a later PR — that would get
+ *      `if (config.seo !== undefined) warn('seo', ...)` until the
+ *      renderer reads it.
+ *   2. A required field temporarily loses its consumer (e.g. a
+ *      large refactor splits the SEO renderer into two PRs); the
+ *      branch fires unconditionally for the duration.
+ *
+ * The scaffold is kept (and the no-warning contract is pinned by
+ * the test suite) so the moment either case lands, the warning
+ * channel is one branch addition away — matching the
+ * `defineTechnicalDocConfig` shape exactly so future authors
+ * grepping for `@unimplemented` find a uniform pattern.
+ *
+ * Why we don't reuse `platform-config-lib`'s
+ * `createUnimplementedFieldWarner`:
+ *
+ * `platform-config-lib` is the platform-level boundary; this engine
+ * package is downstream of it for everything else. Importing the
+ * warner from `platform-config-lib` would invert the dependency
+ * direction (engine → platform-config), creating the same architectural
+ * defect Step 7.5 set out to fix. The warning format is small and
+ * stable enough to inline here — kept structurally similar to the
+ * platform-config-lib warner so readers grepping for `@unimplemented`
+ * still find both surfaces.
+ */
+
+import {
+  WildoMarketingWebsiteConfigSchema,
+  type WildoMarketingWebsiteConfig,
+  type WildoMarketingWebsiteConfigInput,
+} from './wildo-website-config.schemas';
+
+/**
+ * Define a per-service marketing-website config. Provides full IDE
+ * autocompletion on the input shape, runs Zod validation (fail-closed
+ * on typos / unknown keys / out-of-range values / cross-field
+ * invariants like `defaultLocale ∈ locales`), and emits parse-time
+ * `@unimplemented` warnings for fields that are authored but have no
+ * runtime consumer yet.
+ *
+ * Throws on validation failure — same contract as `defineSaasConfig`
+ * and `defineTechnicalDocConfig`.
+ *
+ * @example
+ * ```ts
+ * import { AvailableLanguage } from '@wildo-ai/saas-models/public-runtime';
+ * import { defineWebsiteConfig } from '@wildo-ai/saas-website';
+ *
+ * export default defineWebsiteConfig({
+ *   publicOrigin: 'https://wonder-todos.example.com',
+ *   appOrigin: 'https://app.wonder-todos.example.com',
+ *   defaultLocale: AvailableLanguage.EN,
+ *   locales: [
+ *     { locale: AvailableLanguage.EN, path: 'en' },
+ *     { locale: AvailableLanguage.FR, path: 'fr' },
+ *   ],
+ * });
+ * ```
+ */
+export function defineWebsiteConfig(
+  config: WildoMarketingWebsiteConfigInput,
+): WildoMarketingWebsiteConfig {
+  const parsed = WildoMarketingWebsiteConfigSchema.parse(config);
+  emitUnimplementedRuntimeWarnings(parsed);
+  return parsed;
+}
+
+/**
+ * Emit `@unimplemented` parse-time warnings for every authored
+ * OPTIONAL field on `WildoMarketingWebsiteConfig` that is parsed
+ * but has no runtime consumer yet.
+ *
+ * Branches today: ZERO. The one OPTIONAL field that exists (`csp?`) is
+ * fully wired through the website-local CSP sync/build path, while the
+ * only field that still lacks a runtime consumer (`appOrigin`) is
+ * REQUIRED. After the seam-collapse (`saas-website-seam-collapse.md` —
+ * SHIPPED) the routing/origin fields are consumed directly by every
+ * Astro engine helper via `WebsiteSiteContext`. Required-but-unwired
+ * fields cannot reasonably fire on every parse — that's a
+ * deferred-wiring surface tracked in the schema header, not an
+ * `@unimplemented` warner concern.
+ *
+ * The function exists as a structural mirror of
+ * `defineTechnicalDocConfig.emitUnimplementedRuntimeWarnings` so
+ * readers grepping for `emitUnimplementedRuntimeWarnings` find a
+ * uniform pattern across every `defineXxxConfig` helper.
+ *
+ * # Adding a branch (recipe)
+ *
+ * When the first OPTIONAL `@unimplemented` field lands (most
+ * likely candidate: `seo?.{title,description}`), add the warner
+ * machinery here: a `seen` set + a
+ * `warn(fieldPath, sliceId)` helper that formats as
+ * `[wildo-website-config] @unimplemented field '...'` and writes
+ * to `process.stderr`, then the matching `if (config.<field> !==
+ * undefined)` branch. Copy the exact shape from
+ * `define-tech-doc-config.ts > emitUnimplementedRuntimeWarnings`
+ * to keep the message format identical across helpers. The test
+ * suite pins the zero-warnings contract — flip its expectation in
+ * the same commit.
+ */
+function emitUnimplementedRuntimeWarnings(_config: WildoMarketingWebsiteConfig): void {
+  // Intentional no-op — see function JSDoc for why a no-op is the
+  // correct shape today (optional fields are either fully wired or
+  // absent) and the recipe for adding the first branch.
+}

package/src/config/index.ts

@@ -0,0 +1,38 @@
+/**
+ * `@wildo-ai/saas-website` — config surface.
+ *
+ * Per-service `wildo.website.config.ts` schema + `defineWebsiteConfig`
+ * helper. Co-located with the engine package that owns the marketing-
+ * site primitives so a new SEO field / locale-pack id ships in a
+ * single PR with no cross-package allow-list to keep in sync (see
+ * `wildo-website-config.schemas.ts` JSDoc for the architectural
+ * rationale behind moving this out of `platform-config-lib` —
+ * `saas-website-slice.md` Step 7.5 mirrors the
+ * `saas-technical-doc.md` Step 7.5 fix).
+ *
+ * @wildo-boundary
+ *   This sub-tree is split intentionally:
+ *
+ *     - `wildo-website-config.schemas.ts` — Zod-only, no Node-only
+ *       imports, no `process.*` references. Safe to bundle anywhere.
+ *     - `define-website-config.ts` — uses `process.stderr.write` for
+ *       the (currently empty) `@unimplemented` warner. Bundle-safe in
+ *       practice (the global `process` is polyfilled by every modern
+ *       bundler and the warner has no `node:*` bare specifier), so it
+ *       can ship through the root barrel alongside the schema.
+ *     - `load-website-config.ts` — Node-only. Imports `loadConfig` +
+ *       `AppFrontendType` from `@wildo-ai/platform-config-lib` and
+ *       `node:fs` / `node:path`. Re-exported via the dedicated
+ *       package subpath `./config-loader` (NOT from this barrel) so
+ *       the React-island closure stays free of Node-only specifiers
+ *       (enforced by `__tests__/bundle-isolation.test.ts`).
+ *
+ * Consumers:
+ *   - Author per-service config: `import { defineWebsiteConfig }`
+ *     from `'@wildo-ai/saas-website'`.
+ *   - Load per-service config from a Node-side build / dev pipeline:
+ *     `import { loadWebsiteConfig }` from `'@wildo-ai/saas-website/config-loader'`.
+ */
+
+export * from './define-website-config';
+export * from './wildo-website-config.schemas';

package/src/config/load-website-config.ts

@@ -0,0 +1,229 @@
+/**
+ * @fileoverview Per-service `wildo.website.config.ts` loader.
+ *
+ * Mirrors the `loadTechnicalDocConfig()` shape used by
+ * `platform/factory/wildo-dev-companion/src/technical-doc/services/technical-doc.companion.service.ts`
+ * (see `saas-technical-doc.md` Step 7.5). Discovers the unique
+ * `frontendType: STATIC_WEBSITE` service in the SaaS config, joins
+ * `<saasRoot>/<service.path>/wildo.website.config.ts`, and loads it
+ * via the jiti-backed `loadConfig` from `@wildo-ai/platform-config-lib`.
+ *
+ * The actual Zod validation runs INSIDE `defineWebsiteConfig` (which
+ * the per-service config file invokes via
+ * `export default defineWebsiteConfig({...})`), so by the time
+ * `loadConfig` returns we already hold a parsed
+ * `WildoMarketingWebsiteConfig`.
+ *
+ * @wildo-boundary
+ *   This module is **Node-only**. It imports `loadConfig` and
+ *   `AppFrontendType` from `@wildo-ai/platform-config-lib`, which
+ *   transitively pulls `jiti`, `node:fs`, `node:path`, `node:crypto`,
+ *   and other Node-only API surface. It MUST NOT be imported from
+ *   any browser-bundled entry of this engine package — specifically
+ *   NOT from `index.ts`, `companion-exports.ts`, or `astro-island.ts`.
+ *   The dedicated `./config-loader` package subpath exists precisely
+ *   to keep this surface OUT of the React-island bundle (enforced by
+ *   `__tests__/bundle-isolation.test.ts`).
+ *
+ *   The Astro build's `astro.config.ts` (a Node-side file by
+ *   construction) is the canonical caller. A future companion
+ *   subprocess that audits the marketing surface would also call
+ *   from here. Browser bundles MUST NOT.
+ */
+
+import { existsSync } from 'node:fs';
+import { resolve as resolvePath } from 'node:path';
+import { AppFrontendType, loadConfig } from '@wildo-ai/platform-config-lib';
+import type { WildoSaasConfig } from '@wildo-ai/platform-config-lib';
+import type { WildoMarketingWebsiteConfig } from './wildo-website-config.schemas';
+
+/**
+ * Conventional file name for the per-service marketing-website
+ * configuration (Step 7.5 refactor — `saas-website-slice.md` /
+ * `saas-technical-doc.md` Step 7.5 mirror). Authored at the website
+ * service root next to `package.json` / `astro.config.ts`.
+ *
+ * Discovery is "by convention, not by configuration":
+ *
+ *   - The loader locates this file by walking the `services` entry
+ *     whose `frontendType === STATIC_WEBSITE` and joining
+ *     `<saasRoot>/<service.path>/`. The saas-config schema's
+ *     `superRefine` already enforces "at most one STATIC_WEBSITE
+ *     service per app", so the lookup is deterministic — apps can
+ *     name the website service anything (`'website'`, `'marketing'`,
+ *     `'site'`).
+ *
+ *   - File presence is the enable signal — there is NO `enabled`
+ *     field on `WildoMarketingWebsiteConfigSchema`. A STATIC_WEBSITE
+ *     service without this file is treated as a misconfiguration
+ *     and the loader throws (rather than silently shipping an Astro
+ *     build with no `i18n` routing / no canonical origin).
+ */
+export const PER_SERVICE_WEBSITE_CONFIG_FILE_NAME = 'wildo.website.config.ts';
+
+/**
+ * Memoization slot scoped to the loader module. Keyed by absolute
+ * config file path so multiple SaaS configs evaluated in the same
+ * process (rare in production — possible in tests) do not collide.
+ *
+ * Lifetime: the loader is invoked from the Astro build / dev-server
+ * pipeline, both of which restart the Node process on every dev-stack
+ * reload (the watcher that picks up changes to `wildo.website.config.ts`
+ * is the same watcher that reboots the build). A stale entry here
+ * therefore cannot outlive a config edit.
+ *
+ * Tests can pre-populate a known path via {@link primeWebsiteConfigCache}
+ * to skip the jiti round-trip when exercising downstream consumers.
+ */
+const WEBSITE_CONFIG_CACHE = new Map<string, WildoMarketingWebsiteConfig>();
+
+/**
+ * Test helper — pre-populate the loader's memoization slot for a
+ * given absolute config path. Mirrors the
+ * `cachedTechnicalDocConfig` pre-population trick used by
+ * `technical-doc.publish-openapi.service.test.ts` so the loader's
+ * downstream consumers can be exercised in tests without writing a
+ * `.ts` file to disk + invoking jiti.
+ *
+ * Production callers MUST NOT use this helper.
+ */
+export function primeWebsiteConfigCache(
+  absoluteConfigPath: string,
+  config: WildoMarketingWebsiteConfig,
+): void {
+  WEBSITE_CONFIG_CACHE.set(resolvePath(absoluteConfigPath), config);
+}
+
+/**
+ * Test helper — clear every cached entry. Use in `beforeEach`/`afterEach`
+ * to prevent test cross-contamination.
+ */
+export function clearWebsiteConfigCache(): void {
+  WEBSITE_CONFIG_CACHE.clear();
+}
+
+/**
+ * Arguments for {@link loadWebsiteConfig}. Kept as a structured shape
+ * (rather than positional `loadWebsiteConfig(saasRoot, saasConfig)`)
+ * so that future per-call options (e.g. an explicit `serviceKey`
+ * override for multi-website apps the day the singleton invariant
+ * relaxes) slot in without breaking callers.
+ */
+export interface LoadWebsiteConfigArgs {
+  /**
+   * Absolute path to the SaaS app root — the directory holding
+   * `wildo.saas.config.ts`. Used to resolve `<saasRoot>/<service.path>/`
+   * for the website service folder.
+   */
+  saasRoot: string;
+  /**
+   * The already-parsed SaaS config (load once via
+   * `loadConfig<WildoSaasConfig>(...)` upstream and pass it down here
+   * — re-parsing per call would invoke jiti twice for one logical
+   * load).
+   */
+  saasConfig: WildoSaasConfig;
+}
+
+/**
+ * Discover and load the per-service marketing-website config.
+ *
+ * Resolution algorithm (mirrors
+ * `TechnicalDocCompanionService.loadTechnicalDocConfig`):
+ *
+ *   1. Find the unique service in `saasConfig.services` whose
+ *      `frontendType === STATIC_WEBSITE`. The saas-config
+ *      `superRefine` guarantees there is at most one — if there is
+ *      none, throw with the misconfiguration message.
+ *   2. Resolve `<saasRoot>/<service.path>/wildo.website.config.ts`.
+ *   3. If the file does not exist, throw (file presence IS the
+ *      enable signal — a STATIC_WEBSITE service without this file
+ *      is broken).
+ *   4. Check the memoization slot keyed on the absolute path; return
+ *      the cached value if present.
+ *   5. Call `loadConfig<WildoMarketingWebsiteConfig>(absolutePath)`.
+ *      jiti evaluates the file, which invokes `defineWebsiteConfig`,
+ *      which invokes `WildoMarketingWebsiteConfigSchema.parse` and
+ *      emits any `@unimplemented` warnings. The returned object is
+ *      already-validated — we trust the in-file `defineWebsiteConfig`
+ *      contract here (mirrors the technical-doc loader pattern in
+ *      `TechnicalDocCompanionService.loadTechnicalDocConfig`, which
+ *      also does NOT re-parse). A file that hand-rolls the default
+ *      export without going through `defineWebsiteConfig` would
+ *      surface as a downstream type mismatch — acceptable given the
+ *      authoring contract is explicit and grep-discoverable.
+ *   6. Memoize and return.
+ *
+ * @throws Error with a `[wildo-website-config]` prefix if no
+ *         STATIC_WEBSITE service is declared, the per-service config
+ *         file is missing, or the file's default export does not
+ *         pass `WildoMarketingWebsiteConfigSchema`. The loader
+ *         intentionally throws plain `Error`s rather than building a
+ *         `WildoBackendError` so it stays usable from the Astro
+ *         build pipeline (which has no DI container) — the companion
+ *         can wrap with `errorBuilder` at the call site if needed
+ *         (mirrors how `loadConfig` itself throws plain `Error`).
+ */
+export async function loadWebsiteConfig(
+  args: LoadWebsiteConfigArgs,
+): Promise<WildoMarketingWebsiteConfig> {
+  const { saasRoot, saasConfig } = args;
+
+  const websiteServiceEntry = Object.entries(saasConfig.services).find(
+    ([, service]) => service.frontendType === AppFrontendType.STATIC_WEBSITE,
+  );
+  if (!websiteServiceEntry) {
+    throw new Error(
+      '[wildo-website-config] No frontend service with `frontendType: STATIC_WEBSITE` is declared in '
+        + 'wildo.saas.config.ts. The marketing-website Astro build / loader requires an authored '
+        + 'STATIC_WEBSITE service because that service folder owns the per-service '
+        + '`wildo.website.config.ts` (publicOrigin, appOrigin, defaultLocale, locales). '
+        + 'Add a STATIC_WEBSITE service in wildo.saas.config.ts and ship the per-service '
+        + 'config file under it.',
+    );
+  }
+
+  const [websiteServiceKey, websiteService] = websiteServiceEntry;
+  const websiteConfigPath = resolvePath(
+    saasRoot,
+    websiteService.path,
+    PER_SERVICE_WEBSITE_CONFIG_FILE_NAME,
+  );
+
+  const cached = WEBSITE_CONFIG_CACHE.get(websiteConfigPath);
+  if (cached !== undefined) {
+    return cached;
+  }
+
+  if (!existsSync(websiteConfigPath)) {
+    throw new Error(
+      `[wildo-website-config] STATIC_WEBSITE service '${websiteServiceKey}' is declared in `
+        + `wildo.saas.config.ts but the required per-service config file `
+        + `'${PER_SERVICE_WEBSITE_CONFIG_FILE_NAME}' is missing under `
+        + `'${websiteService.path}/'. File presence IS the enable signal `
+        + '(saas-website-slice.md / saas-technical-doc.md Step 7.5 — the legacy '
+        + '`marketingWebsite` block on wildo.saas.config.ts was dropped in favor of '
+        + 'a per-service file). Create '
+        + `'${websiteConfigPath}' with `
+        + '`export default defineWebsiteConfig({ ... })` from `@wildo-ai/saas-website`.',
+    );
+  }
+
+  let loaded: WildoMarketingWebsiteConfig;
+  try {
+    loaded = await loadConfig<WildoMarketingWebsiteConfig>(websiteConfigPath);
+  } catch (e) {
+    const cause = e instanceof Error ? e.message : String(e);
+    throw new Error(
+      `[wildo-website-config] Failed to load per-service marketing-website config at `
+        + `${websiteConfigPath}. The file MUST do `
+        + '`export default defineWebsiteConfig({...})` and pass '
+        + 'WildoMarketingWebsiteConfigSchema (`z.strictObject` — unknown keys reject; '
+        + '`defaultLocale` must appear in `locales`). '
+        + `Cause: ${cause}`,
+    );
+  }
+
+  WEBSITE_CONFIG_CACHE.set(websiteConfigPath, loaded);
+  return loaded;
+}