create-ailk 0.3.0 → 0.5.0

package/dist/site-chrome.js

@@ -0,0 +1,135 @@
+/**
+ * Template layout knobs (#5612) — the resolved chrome facts a scaffold's
+ * `apps/web/app/[locale]/layout.tsx` reads to mount Nav/Footer/Banner/
+ * MarketingShell: `nav` (full nav links vs. brand-mark-only), `footer`
+ * (columns vs. the existing centered variant), `announcementBanner` (mount
+ * the home-only announcement Banner or not) and `home` (the default
+ * document-scroll home vs. the scroll-snap deck, #5270/#5426).
+ *
+ * A site template is content + an `installMap`, never a route/layout/`.ts`
+ * file (spec 5462 D9/D16) — these are SITE-LEVEL facts a template DECLARES
+ * (on `TemplateManifest.layout` in the code registry, or on a bundle's
+ * `ailk-template.json` `layout` field), never a file it ships. This module is
+ * the single place that declares the vocabulary, fills defaults, validates an
+ * untrusted (bundle-sourced) value, and renders the generated
+ * `apps/web/lib/site-chrome.ts` every scaffold gets — beside `nav-config.ts`,
+ * the same GENERATED-header idiom (`surfaces.ts` `renderNavConfig`).
+ *
+ * Every field is optional and DEFAULTS to today's render (`full` / `columns`
+ * / `true` / `default`) — a scaffold naming no template, or a template naming
+ * no `layout` block, gets these defaults written, byte-identical to the
+ * monorepo's own committed `apps/web/lib/site-chrome.ts`.
+ */
+/** Byte-identical-to-today defaults (#5612 D1). */
+export const DEFAULT_SITE_CHROME = {
+    nav: "full",
+    footer: "columns",
+    announcementBanner: true,
+    home: "default",
+};
+/** Template-relative path of the generated site-chrome registry — beside `NAV_CONFIG_PATH`. */
+export const SITE_CHROME_PATH = "apps/web/lib/site-chrome.ts";
+/** Thrown by `validateTemplateLayout` on an unrecognized value, naming the field. */
+export class TemplateLayoutError extends Error {
+    constructor(message) {
+        super(message);
+        this.name = "TemplateLayoutError";
+    }
+}
+const NAV_VALUES = ["full", "mark-only"];
+const FOOTER_VALUES = ["columns", "centered"];
+const HOME_VALUES = ["default", "deck"];
+/**
+ * Validate an UNTRUSTED `layout` value (a bundle's `ailk-template.json`
+ * `layout` field — arbitrary JSON, never compile-time checked the way the
+ * code registry's `TemplateManifest.layout` is) against the vocabulary above.
+ * Refuses on the first unrecognized field value, naming the field and the
+ * value (#5612 D1). `undefined`/`null` is valid (no block declared); a
+ * non-object value, or a recognized field holding the wrong TYPE, is refused
+ * the same way as an unrecognized enum value — both are "not a value this
+ * field accepts".
+ *
+ * @param subject Caller-supplied context for the error message (e.g. `template "foo"`).
+ */
+export function validateTemplateLayout(value, subject) {
+    if (value === undefined || value === null)
+        return {};
+    if (typeof value !== "object" || Array.isArray(value)) {
+        throw new TemplateLayoutError(`${subject}: "layout" must be an object, got ${JSON.stringify(value)}`);
+    }
+    const raw = value;
+    const result = {};
+    if ("nav" in raw && raw.nav !== undefined) {
+        if (!NAV_VALUES.includes(raw.nav)) {
+            throw new TemplateLayoutError(`${subject}: layout.nav must be one of ${NAV_VALUES.join(", ")} — got ${JSON.stringify(raw.nav)}`);
+        }
+        result.nav = raw.nav;
+    }
+    if ("footer" in raw && raw.footer !== undefined) {
+        if (!FOOTER_VALUES.includes(raw.footer)) {
+            throw new TemplateLayoutError(`${subject}: layout.footer must be one of ${FOOTER_VALUES.join(", ")} — got ${JSON.stringify(raw.footer)}`);
+        }
+        result.footer = raw.footer;
+    }
+    if ("announcementBanner" in raw && raw.announcementBanner !== undefined) {
+        if (typeof raw.announcementBanner !== "boolean") {
+            throw new TemplateLayoutError(`${subject}: layout.announcementBanner must be a boolean — got ${JSON.stringify(raw.announcementBanner)}`);
+        }
+        result.announcementBanner = raw.announcementBanner;
+    }
+    if ("home" in raw && raw.home !== undefined) {
+        if (!HOME_VALUES.includes(raw.home)) {
+            throw new TemplateLayoutError(`${subject}: layout.home must be one of ${HOME_VALUES.join(", ")} — got ${JSON.stringify(raw.home)}`);
+        }
+        result.home = raw.home;
+    }
+    return result;
+}
+/** Fill every field a `TemplateLayout` leaves unset with `DEFAULT_SITE_CHROME`'s value. */
+export function resolveSiteChrome(layout) {
+    return {
+        nav: layout?.nav ?? DEFAULT_SITE_CHROME.nav,
+        footer: layout?.footer ?? DEFAULT_SITE_CHROME.footer,
+        announcementBanner: layout?.announcementBanner ?? DEFAULT_SITE_CHROME.announcementBanner,
+        home: layout?.home ?? DEFAULT_SITE_CHROME.home,
+    };
+}
+/**
+ * Render `apps/web/lib/site-chrome.ts` for a resolved layout — the same
+ * GENERATED-header idiom `renderNavConfig` uses. `layout.tsx` imports
+ * `siteChrome` to decide Nav's `navItems`, Footer's `layout` prop, whether
+ * the announcement Banner mounts, and whether the locale-root route passes
+ * `snap="mandatory"` + `deckHero` to MarketingShell.
+ */
+export function renderSiteChrome(resolved) {
+    return `// site-chrome.ts — resolved template layout knobs.
+//
+// GENERATED by create-ailk from the declared template's \`layout\` block
+// (#5612). A scaffold with no template, or a template with no \`layout\`
+// block, gets these defaults — byte-identical to every scaffold before this
+// file existed. \`apps/web/app/[locale]/layout.tsx\` reads this to decide:
+//   - nav: "mark-only" → Nav renders the brand mark + right-hand controls
+//     only (no nav links).
+//   - footer: "centered" → Footer renders its existing centered variant.
+//   - announcementBanner: false → the home-only announcement Banner is not
+//     mounted (the cookie-consent Banner is unaffected — it is not an
+//     announcement).
+//   - home: "deck" → the locale-root route mounts MarketingShell with
+//     snap="mandatory" + deckHero (spec 5426 D7); every other route is
+//     unaffected.
+
+export interface SiteChrome {
+  nav: "full" | "mark-only";
+  footer: "columns" | "centered";
+  announcementBanner: boolean;
+  home: "default" | "deck";
+}
+
+export const siteChrome: SiteChrome = {
+  nav: ${JSON.stringify(resolved.nav)},
+  footer: ${JSON.stringify(resolved.footer)},
+  announcementBanner: ${JSON.stringify(resolved.announcementBanner)},
+  home: ${JSON.stringify(resolved.home)},
+};
+`;
+}

package/dist/surfaces.d.ts

@@ -51,6 +51,12 @@ export interface Surface {
 export declare const GATEABLE_SURFACES: readonly Surface[];
 /** The recognized `--surfaces` vocabulary, sorted. */
 export declare const RECOGNIZED_SURFACES: readonly string[];
+/**
+ * Retired surface ids, kept for ONE release (#5563). Removal rides the same
+ * trigger as the `/schedule` legacyRoutes entries in routes-map.ts — see the
+ * comment on that row. Resolving through an alias prints a deprecation notice.
+ */
+export declare const SURFACE_ALIASES: Readonly<Record<string, string>>;
 /**
  * Surfaces each recognized module contributes.
  *
@@ -176,12 +182,21 @@ export declare const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
  * exists: two dead links, sitewide, by default. So the nav follows the declared
  * surface set for the same reason the route tree does.
  *
- * Only surfaces carrying a `navLabelKey` are linked, because a nav entry needs
- * a translated label and the template's `nav` namespace ships keys for exactly
- * `home`, `docs`, and `blog`. Emitting an entry whose `labelKey` has no
- * translation would trade a dead link for a missing-message error.
+ * The base items are the Free marketing-site chrome (#5469 D5, the approved
+ * chrome diff recorded on that card):
+ * a Product flyout (How it works · Features · FAQ), then How it works, Pricing
+ * and About. Every one of those pages is in EVERY scaffold — the four core
+ * routes plus the `[slug]` route over the overlay's LandingPage MDX — except
+ * Pricing, which is a gateable surface: its item is emitted only when the
+ * `pricing` surface is enabled (a template roster enables it, #5469 D10), so
+ * the nav still never links a page the scaffold does not carry.
+ *
+ * Only gateable surfaces carrying a `navLabelKey` are linked after the base
+ * items, because a nav entry needs a translated label. Emitting an entry whose
+ * `labelKey` has no translation would trade a dead link for a missing-message
+ * error.
  *
- * Deterministic: entries follow GATEABLE_SURFACES order (alphabetical by id),
- * after the always-present home entry.
+ * Deterministic: gateable entries follow GATEABLE_SURFACES order (alphabetical
+ * by id), after the fixed base items.
  */
 export declare function renderNavConfig(enabled: string[]): string;

package/dist/surfaces.js

@@ -49,6 +49,12 @@ export const CORE_SURFACE_PATHS = [
     "/contact",
     "/faq",
     "/thanks/{slug}",
+    // #5469 D2 — the one generic content route: `app/[locale]/[slug]/page.tsx`
+    // renders `content/<locale>/LandingPage/<slug>.mdx` and 404s otherwise.
+    // Next.js resolves a static segment before a dynamic one, so it never
+    // shadows a scaffolded route directory — which is exactly what lets a
+    // module's own route (the docs-blog `blog/`) win over a same-named MDX.
+    "/{slug}",
 ];
 /** Template-relative route directories that are always copied. */
 export const CORE_ROUTE_DIRS = [
@@ -61,6 +67,11 @@ export const CORE_ROUTE_DIRS = [
     // so joining CORE_ROUTE_DIRS only makes the REGISTRY match what already
     // ships — it does not change what a fresh scaffold carries.
     `${ROUTE_ROOT}/sign-in`,
+    // #5469 D2 — always copied: it is what serves the Free template's
+    // /how-it-works, /features and /blog pages, and it is inert for every slug
+    // that has no LandingPage MDX (notFound), so a scaffold carrying it and no
+    // content is byte-for-byte a scaffold with three more 404s, nothing else.
+    `${ROUTE_ROOT}/[slug]`,
 ];
 /**
  * Directory names skipped by `listTemplateRouteDirs`'s walker even though they
@@ -159,11 +170,40 @@ export const GATEABLE_SURFACES = [
         routes: [`${ROUTE_ROOT}/launch-service`],
         content: [],
     },
+    {
+        // The `scheduling` MODULE's presentation tier — the booking page, the
+        // per-booking-type page and the confirmation page the module OWNS
+        // (`/meet`, `/meet/:slug`, `/meet/confirmed`, one directory, so one entry
+        // gates all three; renamed from the schedule/ directory by #5563).
+        // API-backed like `flows`: the booker reads its slots from apps/api's
+        // `/v1/schedule/*` routes and the event name from `SCHEDULING_CAL_LINK`,
+        // so there is no MDX of its own.
+        id: "meet",
+        routes: [`${ROUTE_ROOT}/meet`],
+        content: [],
+        // `navLabelKey` names COPY, not a route — D1 R2 (#5563): renaming it would
+        // orphan an operator's customised `messages/<locale>.json` for zero
+        // functional gain, since no route derives from a message key.
+        navLabelKey: "schedule",
+    },
     {
         id: "partners",
         routes: [`${ROUTE_ROOT}/partners`],
         content: ["content/<locale>/PartnersList", "content/<locale>/Partner"],
     },
+    {
+        // Module-LESS by construction (#5479 D16): no MODULE_SURFACES value names
+        // it, so a site template may enable it by roster alone. Same for
+        // `privacy` and `terms` below.
+        id: "pricing",
+        routes: [`${ROUTE_ROOT}/pricing`],
+        content: ["content/<locale>/Pricing"],
+    },
+    {
+        id: "privacy",
+        routes: [`${ROUTE_ROOT}/privacy`],
+        content: ["content/<locale>/PrivacyPage"],
+    },
     {
         id: "products",
         routes: [`${ROUTE_ROOT}/products`],
@@ -182,17 +222,6 @@ export const GATEABLE_SURFACES = [
             "content/<locale>/ResourceDetail",
         ],
     },
-    {
-        // The `scheduling` MODULE's presentation tier — the booking page and the
-        // confirmation page the module OWNS (`/schedule` + `/schedule/confirmed`,
-        // one directory, so one entry gates both). API-backed like `flows`: the
-        // booker reads its slots from apps/api's `/v1/schedule/*` routes and the
-        // event name from `SCHEDULING_CAL_LINK`, so there is no MDX of its own.
-        id: "schedule",
-        routes: [`${ROUTE_ROOT}/schedule`],
-        content: [],
-        navLabelKey: "schedule",
-    },
     {
         id: "services",
         routes: [`${ROUTE_ROOT}/services`],
@@ -208,6 +237,11 @@ export const GATEABLE_SURFACES = [
         routes: [`${ROUTE_ROOT}/tech-articles`],
         content: ["content/<locale>/TechArticle"],
     },
+    {
+        id: "terms",
+        routes: [`${ROUTE_ROOT}/terms`],
+        content: ["content/<locale>/TermsPage"],
+    },
     {
         id: "testimonials",
         routes: [`${ROUTE_ROOT}/testimonials`],
@@ -226,6 +260,18 @@ export const GATEABLE_SURFACES = [
 ];
 /** The recognized `--surfaces` vocabulary, sorted. */
 export const RECOGNIZED_SURFACES = GATEABLE_SURFACES.map((s) => s.id);
+/**
+ * Retired surface ids, kept for ONE release (#5563). Removal rides the same
+ * trigger as the `/schedule` legacyRoutes entries in routes-map.ts — see the
+ * comment on that row. Resolving through an alias prints a deprecation notice.
+ */
+export const SURFACE_ALIASES = {
+    schedule: "meet",
+};
+/** Canonical id for a `--surfaces` value, resolving a retired alias. */
+function canonicalizeSurface(s) {
+    return SURFACE_ALIASES[s] ?? s;
+}
 /**
  * Surfaces each recognized module contributes.
  *
@@ -247,7 +293,13 @@ export const MODULE_SURFACES = {
     marketing: [],
     "docs-blog": ["docs", "blog"],
     "multi-tenant": [],
-    scheduling: ["schedule"],
+    // `workspace` contributes zero gateable surfaces (#5371 D4): every route it
+    // owns lives in the `(authed)` segment, never in the public marketing route
+    // tree a template's roster composes — the same reason `multi-tenant` above
+    // carries an empty list. The entry itself is still required: surface-gating's
+    // vocabulary assertion covers exactly the recognized module set.
+    workspace: [],
+    scheduling: ["meet"],
     "signal-collectors": ["flows"],
     commerce: [],
 };
@@ -273,7 +325,7 @@ export function parseSurfaces(raw) {
         return [];
     const requested = raw
         .split(",")
-        .map((s) => s.trim().toLowerCase())
+        .map((s) => canonicalizeSurface(s.trim().toLowerCase()))
         .filter(Boolean);
     for (const s of requested) {
         if (!RECOGNIZED_SURFACES.includes(s)) {
@@ -302,7 +354,8 @@ export function resolveSurfaces(modules = ["marketing"], explicit = []) {
             set.add(s);
     }
     const selected = new Set(modules.map((m) => m.trim().toLowerCase()));
-    for (const s of explicit) {
+    for (const raw of explicit) {
+        const s = canonicalizeSurface(raw);
         if (!RECOGNIZED_SURFACES.includes(s)) {
             throw new SurfaceError(`unknown surface "${s}". Recognized: ${RECOGNIZED_SURFACES.join(", ")}`);
         }
@@ -407,8 +460,19 @@ export const ROUTE_SINCE = {
     integrations: "0.0.0",
     "integrations/[slug]": "0.0.0",
     "launch-service": "0.0.0",
+    meet: "0.0.0",
+    // #5563 — the genuinely new row: a per-booking-type page with no
+    // predecessor, so it attaches at the create-ailk minor this rename ships
+    // in rather than the "predates the manifest" 0.0.0 above.
+    "meet/[slug]": "0.5.0",
+    "meet/confirmed": "0.0.0",
     partners: "0.0.0",
     "partners/[slug]": "0.0.0",
+    // #5479 — three genuinely new route directories, so they attach at today's
+    // fixed-group version rather than the "predates the manifest" 0.0.0 above,
+    // the same rule #5048 ("projects/apply") and #5014 ("(authed)") applied.
+    pricing: "0.22.0",
+    privacy: "0.22.0",
     products: "0.0.0",
     "products/[slug]": "0.0.0",
     projects: "0.0.0",
@@ -420,14 +484,13 @@ export const ROUTE_SINCE = {
     "projects/apply": "0.18.0",
     resources: "0.0.0",
     "resources/[slug]": "0.0.0",
-    schedule: "0.0.0",
-    "schedule/confirmed": "0.0.0",
     services: "0.0.0",
     "services/[slug]": "0.0.0",
     software: "0.0.0",
     "software/[slug]": "0.0.0",
     "tech-articles": "0.0.0",
     "tech-articles/[slug]": "0.0.0",
+    terms: "0.22.0",
     testimonials: "0.0.0",
     "thanks/[slug]": "0.14.0",
     "use-cases": "0.0.0",
@@ -444,10 +507,31 @@ export const ROUTE_SINCE = {
     // choice #5048's "projects/apply" entry already made for the same reason.
     "(authed)": "0.18.0",
     "(authed)/account": "0.18.0",
+    // The leads inbox (#5678). The ROUTE ships in every scaffold, Free
+    // included — lead capture is a never-gate surface, so reading a lead back
+    // is one too. Whether it shows a ROW is a separate question with two
+    // deployment preconditions (a resolvable workspace, and a `siteId` that
+    // equals a workspace id); both fail empty, never wide. See
+    // `apps/api/src/services/leads-inbox.ts` § "What it takes for this to
+    // return anything".
+    "(authed)/leads": "0.24.0",
+    // #5371 — the workspace module's three settings routes. Genuinely new route
+    // directories, so they attach at today's fixed-group version rather than the
+    // "predates the manifest" 0.0.0 above, the same rule #5479 and #5048 applied.
+    // Directory renamed apps/web/.../(authed)/workspace -> (authed)/admin by
+    // #5637 (Admin-vocabulary rename); the ROUTE_SINCE version is unchanged —
+    // it tracks when the route was introduced, not when it was renamed.
+    "(authed)/admin": "0.22.1",
+    "(authed)/admin/site": "0.22.1",
+    "(authed)/admin/team": "0.22.1",
     "(authed)/waitlist": "0.18.0",
     "(authed)/waitlist/[experimentId]": "0.18.0",
     "(authed)/waitlist/[experimentId]/signups/[leadId]": "0.18.0",
     "sign-in": "0.18.0",
+    // #5469 D2 — the generic `[slug]` content route. A genuinely new route
+    // directory, so it attaches at today's fixed-group version, the same rule
+    // #5479, #5371 and #5048 applied.
+    "[slug]": "0.23.0",
 };
 /**
  * Surface id of the registry that owns `routeDir` (ROUTE_ROOT-relative): the
@@ -490,6 +574,10 @@ export const ROUTE_DEPENDENCIES = {
         `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
         `${ROUTE_ROOT}/(authed)/waitlist/format.ts`,
     ],
+    "(authed)/admin": ["apps/web/lib/server-api.ts"],
+    "(authed)/leads": ["apps/web/lib/server-api.ts"],
+    "(authed)/admin/site": ["apps/web/lib/server-api.ts"],
+    "(authed)/admin/team": ["apps/web/lib/server-api.ts"],
     "(authed)/waitlist": ["apps/web/lib/server-api.ts"],
 };
 /**
@@ -504,6 +592,10 @@ export const ROUTE_DEPENDENCIES = {
 export const ROUTE_MESSAGE_NAMESPACES = {
     "sign-in": ["signIn"],
     "(authed)/account": ["account"],
+    "(authed)/admin": ["admin"],
+    "(authed)/leads": ["leadsInbox"],
+    "(authed)/admin/site": ["admin"],
+    "(authed)/admin/team": ["admin"],
     "(authed)/waitlist": ["waitlistDashboard.gate"],
 };
 /** Template-relative path of the generated site-nav registry. */
@@ -517,19 +609,43 @@ export const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
  * exists: two dead links, sitewide, by default. So the nav follows the declared
  * surface set for the same reason the route tree does.
  *
- * Only surfaces carrying a `navLabelKey` are linked, because a nav entry needs
- * a translated label and the template's `nav` namespace ships keys for exactly
- * `home`, `docs`, and `blog`. Emitting an entry whose `labelKey` has no
- * translation would trade a dead link for a missing-message error.
+ * The base items are the Free marketing-site chrome (#5469 D5, the approved
+ * chrome diff recorded on that card):
+ * a Product flyout (How it works · Features · FAQ), then How it works, Pricing
+ * and About. Every one of those pages is in EVERY scaffold — the four core
+ * routes plus the `[slug]` route over the overlay's LandingPage MDX — except
+ * Pricing, which is a gateable surface: its item is emitted only when the
+ * `pricing` surface is enabled (a template roster enables it, #5469 D10), so
+ * the nav still never links a page the scaffold does not carry.
+ *
+ * Only gateable surfaces carrying a `navLabelKey` are linked after the base
+ * items, because a nav entry needs a translated label. Emitting an entry whose
+ * `labelKey` has no translation would trade a dead link for a missing-message
+ * error.
  *
- * Deterministic: entries follow GATEABLE_SURFACES order (alphabetical by id),
- * after the always-present home entry.
+ * Deterministic: gateable entries follow GATEABLE_SURFACES order (alphabetical
+ * by id), after the fixed base items.
  */
 export function renderNavConfig(enabled) {
     const on = new Set(enabled);
     const linked = GATEABLE_SURFACES.filter((s) => s.navLabelKey !== undefined && on.has(s.id));
     const entries = [
-        '  { labelKey: "home", path: "/" },',
+        "  {",
+        '    labelKey: "product",',
+        "    flyout: {",
+        '      presentation: "list",',
+        '      width: "trigger",',
+        "      features: [",
+        '        { labelKey: "howItWorks", descKey: "howItWorksDesc", icon: Layers, path: "/how-it-works" },',
+        '        { labelKey: "features", descKey: "featuresDesc", icon: Sparkles, path: "/features" },',
+        '        { labelKey: "faq", descKey: "faqDesc", icon: HelpCircle, path: "/faq" },',
+        "      ],",
+        '      actions: [{ labelKey: "docs", icon: BookOpen, path: "/how-it-works" }],',
+        "    },",
+        "  },",
+        '  { labelKey: "howItWorks", path: "/how-it-works" },',
+        ...(on.has("pricing") ? ['  { labelKey: "pricing", path: "/pricing" },'] : []),
+        '  { labelKey: "about", path: "/about" },',
         ...linked.map((s) => `  { labelKey: "${s.navLabelKey}", path: "/${s.id}" },`),
     ];
     // The emitted file imports the consumer's `NavItem` type from the UI package.
@@ -554,6 +670,7 @@ export function renderNavConfig(enabled) {
 // \`apps/web/messages/<locale>.json\`. Paths are locale-agnostic — Nav prefixes
 // them with the active locale at render.
 ${navItemImport}
+import { BookOpen, HelpCircle, Layers, Sparkles } from "lucide-react";
 
 export const navItems: NavItem[] = [
 ${entries.join("\n")}

package/dist/template-manifest.d.ts

@@ -0,0 +1,144 @@
+import { type PageRosterRow } from "./module-architecture.js";
+import type { ModuleName } from "./parse-args.js";
+import type { TemplateLayout } from "./site-chrome.js";
+/**
+ * One site template: its fixed module list and the page rows it brings itself.
+ *
+ * THERE IS NO `tier`, `level` OR `price` MEMBER, and there never is one
+ * (parent § D4). Delivery tier is DERIVED from `requires` — by the client via
+ * `templateDelivery` below, and by the issuer via `TIER_SPECS` (#5480) — so
+ * declaring it here would be a second authority for a fact the module list
+ * already settles. The type, not a convention, is what makes adding one a
+ * compile error: a convention is a thing someone must remember.
+ *
+ * There is likewise no optional-module member (parent § D12). A template's
+ * level must be readable from ONE fixed list; a soft list would make the same
+ * template Free or Pro depending on the key.
+ */
+export interface TemplateManifest {
+    /** Template name. Equals this manifest's `TEMPLATE_MANIFESTS` key. */
+    name: string;
+    /**
+     * The modules whose PAGES this template's roster uses (parent § D15) — not
+     * the modules its level bundles. Typed against `ModuleName`, so an
+     * unrecognized name fails type-check rather than a runtime validation.
+     */
+    requires: readonly ModuleName[];
+    /**
+     * The template this one EXTENDS — its lineage, never its level (#5618 D2).
+     * A single parent, not a list: "later layers win file by file" needs a
+     * total order, and a list would make the winner depend on the list's order
+     * (the failure `normalizeModules` exists to prevent for modules). The
+     * chain terminates at `BASE_LAYER_DIR`, the one layer every template
+     * reaches; `resolveTemplateLineage` walks and validates it. The delivery
+     * level stays derived from `requires` — `saas-product` extends `_base`, not
+     * `marketing-site`, precisely because "Pro plus multi-tenant" is a level
+     * fact `requires` already states.
+     */
+    extends: string;
+    /** Base rows, before any module's contribution is merged. */
+    roster: readonly PageRosterRow[];
+    /** Bundle-relative source → scaffold-relative destination. */
+    installMap?: Record<string, string>;
+    /**
+     * Site-level chrome knobs (#5612 D1) — nav/footer/banner/home. Every field
+     * optional; a template declaring none (all four settled entries below)
+     * renders byte-identically to before this field existed. See
+     * `site-chrome.ts` for the vocabulary, defaults and the generated
+     * `apps/web/lib/site-chrome.ts` this resolves into.
+     */
+    layout?: TemplateLayout;
+}
+/**
+ * The base layer's directory under `site-templates/` (#5618 D1) — the seed
+ * files every template reaches by declaring `extends`, installed by
+ * `installBundleTree` before any module bundle and only when `--template`
+ * is named, so a scaffold naming no template is byte-identical to before it
+ * existed. It is NOT a template: it has no `TEMPLATE_MANIFESTS` entry (so
+ * `--template _base` stays unrecognized — `RECOGNIZED_TEMPLATES` is exactly
+ * that object's key set) and is never published as a registry bundle. The
+ * leading underscore is what `build-module-bundles.mjs`'s template loop and
+ * the directory-scanning tests key their skip on.
+ */
+export declare const BASE_LAYER_DIR = "_base";
+/** Thrown on an undeclared template name or a route claimed twice. Mirrors `SurfaceError`'s shape. */
+export declare class TemplateError extends Error {
+    constructor(message: string);
+}
+/**
+ * The three settled templates and their fixed `requires` lists — settled by
+ * Sam, 2026-09-14 (parent § D12). The plain name is the Pro one: it is the
+ * flagship and the demo.
+ *
+ * `workspace` appears in none of them. It is a Pro module, but an authed app
+ * surface contributing no PUBLIC page to a marketing site, and `requires`
+ * names what the roster uses (parent § D15). A Pro key unlocks it regardless
+ * of any template. `ModuleName` could express it either way — `workspace` is
+ * one of the seven `RECOGNIZED_MODULES` names; it is simply not one any
+ * template's fixed `requires` list names.
+ *
+ * `commerce` is likewise in none of them: it is a per-site add-on available at
+ * any level, so a template for it would contradict the offering model and
+ * multiply the set combinatorially (parent § D13). It still contributes rows
+ * to whichever template takes it, through `mergeRoster` below.
+ *
+ * Frozen (#5507): this registry is also the issuer's authorization allowlist
+ * (spec 5480 § C7) — a mutable global there could be monkey-patched at
+ * runtime. A caller needing a different registry for a test injects its own
+ * fixture rather than mutating this one.
+ */
+export declare const TEMPLATE_MANIFESTS: Readonly<Record<string, TemplateManifest>>;
+/** Look up a declared template. @throws TemplateError on an undeclared name. */
+export declare function resolveTemplate(name: string): TemplateManifest;
+/**
+ * Resolve a template's `extends` chain — `[name, …ancestors, "_base"]` — in
+ * the client registry, before any fetch (#5618 D2). `_base` is the only
+ * valid terminus: an `extends` naming neither it nor a declared template is
+ * refused naming the field, the value and the recognized set, in
+ * `resolveTemplate`'s message shape; a cycle is refused naming the whole
+ * chain. The registry is a parameter for the same reason `TEMPLATE_MANIFESTS`
+ * is frozen (#5507): a test needing a cyclic or dangling fixture injects its
+ * own rather than mutating the shipped one.
+ *
+ * @throws TemplateError on an undeclared name, an unknown parent or a cycle.
+ */
+export declare function resolveTemplateLineage(name: string, registry?: Readonly<Record<string, TemplateManifest>>): string[];
+/**
+ * Compose a template's roster: its base rows, then each taken module's
+ * contributed rows in `normalizeModules` order (parent § D7).
+ *
+ * `normalizeModules` is REUSED rather than re-sorted here. It already returns
+ * the unique set ordered by `RECOGNIZED_MODULES`, and `scaffold()` already
+ * calls it — a second sort at this call site would be a second ordering
+ * authority that could drift from the one `deriveArchitecture` depends on.
+ * That also makes the merge a pure function of the module SET: the same set in
+ * any argument order returns identical rows.
+ *
+ * The merge is pure and writes nothing. Staging a contributed row's seed
+ * content is the bundle producer's job (`build-module-bundles.mjs`, #5481);
+ * doing it here would put a filesystem dependency in a function three sibling
+ * units import for its return value.
+ *
+ * @param modules the modules this scaffold takes. A template's `requires` are
+ *   taken by definition — a required module whose bundle cannot be had refuses
+ *   the install outright (parent § D17, #5481) rather than merging short.
+ * @throws TemplateError when two sources claim one route (parent § D8). Both
+ *   the base roster and every contribution are compile-time known, so the
+ *   collision is caught by a test before a bundle exists — never resolved at
+ *   runtime by a base-wins or module-wins precedence rule, either of which
+ *   silently produces a site missing a page someone declared.
+ */
+export declare function mergeRoster(manifest: TemplateManifest, modules: readonly string[]): PageRosterRow[];
+/**
+ * Whether a template installs on the keyless path or needs a verified
+ * `AILK_LICENSE_KEY` — derived from `requires`, never declared (parent § D3).
+ *
+ * The derivation goes through the existing `classifyModules` rather than a
+ * second list of paid names, which would drift. This is deliberately the
+ * CLIENT half of a two-derivation split: the issuer derives the commercial
+ * LEVEL from the same `requires` via `TIER_SPECS` (#5480). One shared
+ * derivation would force this package to import
+ * `@working-theory/license-manifest` — a `restricted` package — breaking
+ * `pnpm install` for every Free consumer, not merely gating the paid path.
+ */
+export declare function templateDelivery(manifest: TemplateManifest): "free" | "paid";