create-ailk 0.4.0 → 0.5.0

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,6 +170,22 @@ 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`],
@@ -195,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`],
@@ -244,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.
  *
@@ -271,7 +299,7 @@ export const MODULE_SURFACES = {
     // carries an empty list. The entry itself is still required: surface-gating's
     // vocabulary assertion covers exactly the recognized module set.
     workspace: [],
-    scheduling: ["schedule"],
+    scheduling: ["meet"],
     "signal-collectors": ["flows"],
     commerce: [],
 };
@@ -297,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)) {
@@ -326,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(", ")}`);
         }
@@ -431,6 +460,12 @@ 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
@@ -449,8 +484,6 @@ 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",
@@ -474,16 +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.
-    "(authed)/workspace": "0.22.1",
-    "(authed)/workspace/site": "0.22.1",
-    "(authed)/workspace/team": "0.22.1",
+    // 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
@@ -526,9 +574,10 @@ export const ROUTE_DEPENDENCIES = {
         `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
         `${ROUTE_ROOT}/(authed)/waitlist/format.ts`,
     ],
-    "(authed)/workspace": ["apps/web/lib/server-api.ts"],
-    "(authed)/workspace/site": ["apps/web/lib/server-api.ts"],
-    "(authed)/workspace/team": ["apps/web/lib/server-api.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"],
 };
 /**
@@ -543,9 +592,10 @@ export const ROUTE_DEPENDENCIES = {
 export const ROUTE_MESSAGE_NAMESPACES = {
     "sign-in": ["signIn"],
     "(authed)/account": ["account"],
-    "(authed)/workspace": ["workspace"],
-    "(authed)/workspace/site": ["workspace"],
-    "(authed)/workspace/team": ["workspace"],
+    "(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. */
@@ -559,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.
@@ -596,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

@@ -1,5 +1,6 @@
 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.
  *
@@ -23,11 +24,43 @@ export interface TemplateManifest {
      * 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);
@@ -40,17 +73,36 @@ export declare class TemplateError extends Error {
  * `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 not express it in any case —
- * `RECOGNIZED_MODULES` is the six names and `workspace` is not among them.
+ * 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: Record<string, TemplateManifest>;
+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).

package/dist/template-manifest.js

@@ -16,6 +16,18 @@
  */
 import { classifyModules } from "./lib/module-tier.js";
 import { MODULE_SLICES, normalizeModules, } from "./module-architecture.js";
+/**
+ * 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 const BASE_LAYER_DIR = "_base";
 /** Thrown on an undeclared template name or a route claimed twice. Mirrors `SurfaceError`'s shape. */
 export class TemplateError extends Error {
     constructor(message) {
@@ -24,17 +36,92 @@ export class TemplateError extends Error {
     }
 }
 /**
- * `/pricing`, `/privacy` and `/terms` — the three module-less rows every
- * declared template brings itself.
+ * The ten rows every declared template brings itself — one declared page set,
+ * whichever mechanism scaffolds each (the Free manifest § 3, #5469 D4).
+ *
+ * Two mechanisms, one roster:
+ *
+ *   - `/`, `/how-it-works`, `/features`, `/about`, `/faq`, `/contact` and
+ *     `/sign-in` are in EVERY scaffold, template or not: their content is the
+ *     always-copied overlay (`template-overlay/content/en/**`, copied whole by
+ *     `build-templates.mjs`) and their routes are core (`CORE_ROUTE_DIRS` —
+ *     the three LandingPage pages render through the generic `[slug]` route,
+ *     #5469 D2). They are declared here anyway, so the manifest a template
+ *     publishes (`build-template-manifest.mjs`) lists the whole page set and
+ *     the roster is what a template IS, not merely what it adds.
+ *   - `/pricing`, `/privacy` and `/terms` are module-less by construction
+ *     (parent § D16): no module owns these surfaces, their route files live in
+ *     `apps/web` and are snapshotted into the starter like every other route,
+ *     and a template enables them by NAMING them in its roster — `scaffold()`
+ *     selects their `GATEABLE_SURFACES` entries from the merged roster's
+ *     routes (#5469 D10). Their seed content ships ONCE, in the base layer
+ *     (`site-templates/_base/content/**`, #5618 D1), which every template
+ *     reaches by declaring `extends` — installed before the module bundles
+ *     and the template's own tree, so a template may override a base page
+ *     by shipping the same path.
  *
- * Module-less by construction (parent § D16): no module owns these surfaces,
- * their route files live in `apps/web` and are snapshotted into the starter
- * like every other route, and a template enables them by NAMING them in its
- * roster. Registering the three as `GATEABLE_SURFACES` entries is #5479's; the
- * rows are declared here because the roster is what a template is.
+ * `/sign-in` carries no `content`: it is a code route (the SignInCard island),
+ * like the API-backed rows the scheduling module contributes.
+ *
+ * `/blog` is deliberately NOT here (#5469 D3): the docs-blog module
+ * contributes its own `/blog` row, so a base row would make `mergeRoster`
+ * refuse every template that takes that module. The Free teaser row is
+ * declared on `marketing-site-free` alone, below.
  */
 const TEMPLATE_BASE_ROSTER = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    {
+        route: "/how-it-works",
+        content: ["content/en/LandingPage/how-it-works.mdx"],
+    },
+    { route: "/features", content: ["content/en/LandingPage/features.mdx"] },
     { route: "/pricing", content: ["content/en/Pricing/pricing.mdx"] },
+    { route: "/about", content: ["content/en/AboutPage/about.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.mdx"] },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/sign-in" },
+    { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
+    { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
+];
+/**
+ * The Free `/blog` teaser (#5469 D3) — one static LandingPage (`schema: Blog`)
+ * that says what the Pro docs-blog module gives you. It is served by the
+ * generic `[slug]` route over `content/en/LandingPage/blog.mdx`, which ships
+ * in the always-copied overlay. `/blog` degrades by DIRECTORY PRECEDENCE, not
+ * by a module gate: in a keyed docs-blog scaffold the module's own
+ * `blog/[[...slug]]/page.tsx` directory exists and Next.js resolves the static
+ * segment first, so the teaser file is inert; keyless, no `blog/` directory
+ * exists and the teaser renders. Declared on the Free template only — on
+ * `marketing-site` the docs-blog contribution claims the route.
+ */
+const FREE_BLOG_TEASER_ROW = {
+    route: "/blog",
+    content: ["content/en/LandingPage/blog.mdx"],
+};
+/**
+ * `minimalism-site`'s own rows (#5589) — the one declared template that does
+ * not reuse `TEMPLATE_BASE_ROSTER`. Its page set is the issue's ROSTER, and
+ * the rows it does NOT carry are as deliberate as the ones it does: no
+ * `/how-it-works`, `/features` or `/pricing` (a reports-first site sells
+ * nothing from a pricing table), and no `/sign-in` (a code route every
+ * scaffold carries regardless — `CORE_ROUTE_DIRS` — which this template
+ * simply does not advertise as one of its pages).
+ *
+ * `/meet`, `/meet/[slug]`, `/meet/confirmed`, `/reports/[slug]` and the three
+ * `/flows/*` rows are absent here on purpose: they are the `scheduling` and
+ * `signal-collectors` modules' own `pageContributions`, merged in by
+ * `mergeRoster`. Declaring one here would make that merge refuse the
+ * template outright (§ D8's both-claimants refusal).
+ */
+const MINIMALISM_ROSTER = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    { route: "/reports", content: ["content/en/LandingPage/reports.mdx"] },
+    { route: "/about", content: ["content/en/AboutPage/about.mdx"] },
+    { route: "/services", content: ["content/en/ServicesList/services.mdx"] },
+    { route: "/services/[slug]" },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/referral", content: ["content/en/LandingPage/referral.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.mdx"] },
     { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
     { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
 ];
@@ -46,15 +133,21 @@ const TEMPLATE_BASE_ROSTER = [
  * `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 not express it in any case —
- * `RECOGNIZED_MODULES` is the six names and `workspace` is not among them.
+ * 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 const TEMPLATE_MANIFESTS = {
+export const TEMPLATE_MANIFESTS = Object.freeze({
     /**
      * The Free template, and the mechanism's own proof (parent § D11): it
      * requires only `marketing`, so the keyless merge path is exercised by a
@@ -63,7 +156,8 @@ export const TEMPLATE_MANIFESTS = {
     "marketing-site-free": {
         name: "marketing-site-free",
         requires: ["marketing"],
-        roster: TEMPLATE_BASE_ROSTER,
+        extends: BASE_LAYER_DIR,
+        roster: [...TEMPLATE_BASE_ROSTER, FREE_BLOG_TEASER_ROW],
     },
     /**
      * The Pro flagship. Its module list is OFFERINGS § 4 offering 3's tiers line
@@ -73,6 +167,7 @@ export const TEMPLATE_MANIFESTS = {
     "marketing-site": {
         name: "marketing-site",
         requires: ["marketing", "docs-blog", "scheduling", "signal-collectors"],
+        extends: BASE_LAYER_DIR,
         roster: TEMPLATE_BASE_ROSTER,
     },
     /**
@@ -93,9 +188,50 @@ export const TEMPLATE_MANIFESTS = {
             "signal-collectors",
             "multi-tenant",
         ],
+        extends: BASE_LAYER_DIR,
         roster: TEMPLATE_BASE_ROSTER,
     },
-};
+    /**
+     * The second Pro template (#5589) — the reports-first, scroll-snap deck
+     * site. NOT `marketing-site` plus a module: its `requires` omits
+     * `docs-blog`, so the two Pro templates are siblings under `_base`
+     * (#5618 D2), never a lineage. Level still derives from `requires`:
+     * `scheduling` and `signal-collectors` are paid, so `templateDelivery`
+     * returns `"paid"` exactly as it does for `marketing-site`.
+     *
+     * It declares its OWN roster rather than reusing `TEMPLATE_BASE_ROSTER`
+     * (the only declared template that does): the deck home replaces the
+     * document-scroll home, and `/how-it-works`, `/features`, `/pricing` and
+     * `/sign-in` are not pages this site has. `/pricing`'s absence is not a
+     * missing file — the `_base` layer still lands its seed content, and the
+     * roster is what the template IS, so an unrostered page simply has no
+     * route directory copied (`rosterSurfaces`).
+     *
+     * `/reports` and `/referral` carry no `GATEABLE_SURFACES` entry and need
+     * none: both are single-segment `LandingPage` slugs served by the generic
+     * `[slug]` route (#5469 D2), the same mechanism Free's `/how-it-works`
+     * uses. `/reports/[slug]` (the reader) is the signal-collectors module's
+     * own contributed row.
+     *
+     * `/services/[slug]` declares no `content`: its seed is a whole DIRECTORY
+     * (`content/en/Service`, as `routes-map.ts` records it), and a roster
+     * row's `content` names files the manifest generator reads frontmatter
+     * from. The three samples ride the template tree unmapped, landing at
+     * that directory.
+     */
+    "minimalism-site": {
+        name: "minimalism-site",
+        requires: ["marketing", "scheduling", "signal-collectors"],
+        extends: BASE_LAYER_DIR,
+        roster: MINIMALISM_ROSTER,
+        layout: {
+            nav: "mark-only",
+            footer: "centered",
+            announcementBanner: false,
+            home: "deck",
+        },
+    },
+});
 /** Look up a declared template. @throws TemplateError on an undeclared name. */
 export function resolveTemplate(name) {
     const manifest = TEMPLATE_MANIFESTS[name];
@@ -104,6 +240,39 @@ export function resolveTemplate(name) {
     }
     return manifest;
 }
+/**
+ * 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 function resolveTemplateLineage(name, registry = TEMPLATE_MANIFESTS) {
+    const chain = [];
+    let current = name;
+    for (;;) {
+        if (chain.includes(current)) {
+            throw new TemplateError(`template "${name}": cyclic "extends" chain ${[...chain, current].join(" → ")}`);
+        }
+        chain.push(current);
+        if (current === BASE_LAYER_DIR)
+            return chain;
+        const manifest = registry[current];
+        if (!manifest) {
+            const declared = [...Object.keys(registry), BASE_LAYER_DIR].join(", ");
+            if (chain.length === 1) {
+                throw new TemplateError(`unknown template "${current}". Declared: ${declared}`);
+            }
+            throw new TemplateError(`template "${chain[chain.length - 2]}": "extends" names unknown template "${current}". Declared: ${declared}`);
+        }
+        current = manifest.extends;
+    }
+}
 /**
  * Compose a template's roster: its base rows, then each taken module's
  * contributed rows in `normalizeModules` order (parent § D7).

package/dist/template-names.d.ts

@@ -37,5 +37,5 @@
  * is consumed as a plain array across the package.
  */
 /** The declared site templates, in `TEMPLATE_MANIFESTS` declaration order. */
-export declare const RECOGNIZED_TEMPLATES: readonly ["marketing-site-free", "marketing-site", "saas-product"];
+export declare const RECOGNIZED_TEMPLATES: readonly ["marketing-site-free", "marketing-site", "saas-product", "minimalism-site"];
 export type TemplateName = (typeof RECOGNIZED_TEMPLATES)[number];

package/dist/template-names.js

@@ -41,4 +41,5 @@ export const RECOGNIZED_TEMPLATES = [
     "marketing-site-free",
     "marketing-site",
     "saas-product",
+    "minimalism-site",
 ];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ailk",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Scaffolder for AI Launch Kit — `pnpm create ailk@latest <dir>` produces a starter repo consuming @working-theory/* from npm (per ADR 0007).",
   "type": "module",
   "main": "./dist/index.js",
@@ -12,6 +12,8 @@
     "dist",
     "templates",
     "site-templates",
+    "versions.json",
+    "component-catalog.json",
     "component-catalog.md",
     "README.md",
     "LICENSE"
@@ -22,6 +24,9 @@
   "dependencies": {
     "tar": "^7.5.21"
   },
+  "devDependencies": {
+    "@working-theory/templates": "0.24.0"
+  },
   "repository": {
     "type": "git",
     "url": "git+https://github.com/working-theory-labs/ai-launch-kit.git",
@@ -50,6 +55,8 @@
     "test:coverage": "jest --coverage",
     "build-templates": "tsc -b && node scripts/build-templates.mjs",
     "build-catalog": "node scripts/build-component-catalog.mjs",
-    "check-catalog": "node scripts/build-component-catalog.mjs --check"
+    "check-catalog": "node scripts/build-component-catalog.mjs --check",
+    "manifest:build": "node scripts/build-template-manifest.mjs --template marketing-site-free",
+    "manifest:check": "node scripts/build-template-manifest.mjs --template marketing-site-free --check && node scripts/build-template-manifest.mjs --template marketing-site --check"
   }
 }