create-ailk 0.4.0 → 0.6.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 = [
@@ -60,7 +66,32 @@ export const CORE_ROUTE_DIRS = [
     // copies all of apps/web verbatim, no `--surfaces` gating on this route),
     // 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`,
+    //
+    // #5963 moved `sign-in` INTO the `(auth)` route group and added four
+    // siblings, so the group is what is listed now. It stays CORE rather than
+    // taking its own surface id the way `(authed)` did: `(authed)` is gated
+    // authed-app surface reported under its own identity, whereas these five
+    // are the public auth entry points that have always shipped ungated —
+    // registering the group keeps `sign-in`'s existing `core` identity exactly.
+    `${ROUTE_ROOT}/(auth)`,
+    // #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]`,
+    // #6084 D12 (the operator's shape-2 disposition) — the checkout return
+    // pair. The launchers pointing at them (`apps/mcp/src/tools/purchase.ts`,
+    // `apps/web/.../dev/purchase/purchase.actions.ts`) are ALREADY
+    // unconditional base-tree code under D-64, so gating the return pages
+    // behind a scaffold-time surface would leave a licence-added commerce
+    // site with a working checkout and a 404 return page — the exact defect
+    // this issue exists to close. `CORE_ROUTE_DIRS` is the right home for the
+    // same reason `[slug]` immediately above is: inert (a request-time
+    // `notFound()`, `src/lib/commerce-claim.ts`) for every scaffold that never
+    // buys the `commerce` claim, so carrying it costs nothing beyond two more
+    // 404s. Neither `GATEABLE_SURFACES` nor `MODULE_SURFACES.commerce` gains
+    // an entry — the claim decides whether the pages serve, not the scaffold.
+    `${ROUTE_ROOT}/purchase`,
 ];
 /**
  * Directory names skipped by `listTemplateRouteDirs`'s walker even though they
@@ -159,6 +190,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 +242,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 +280,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 +319,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 +345,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 +374,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 +480,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
@@ -447,10 +502,13 @@ export const ROUTE_SINCE = {
     // question set is the SITE's content. A scaffolded site adds its own route
     // beside this file and passes its own config.
     "projects/apply": "0.18.0",
+    // #6084 — two genuinely new route directories, attaching at today's
+    // fixed-group version, the same "attach at today's version" rule #5977,
+    // #5678, #5479, #5371 and #5048 applied.
+    "purchase/success": "0.24.0",
+    "purchase/cancel": "0.24.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 +532,57 @@ 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",
+    // #5977 — the Pro content host's editor routes (spec 5872 FR1/FR2), added
+    // to apps/web by #5957. Genuinely new route directories, so they attach at
+    // today's fixed-group version, the same "attach at today's version" rule
+    // #5678, #5479, #5371 and #5048 applied.
+    //
+    // They are registered here but do NOT ship in a scaffold: the pair is
+    // excluded from the template snapshot by `EXCLUDE_TEMPLATE_DIRS` in
+    // `scripts/build-templates.mjs` (see that entry for the two spec-5872-D11
+    // constraints behind the choice). The entries are kept because ROUTE_SINCE
+    // is the route registry for `apps/web`, not a mirror of what the snapshot
+    // happens to carry — sync-routes' AC-5 coverage test knows the exclusion
+    // and treats the absence as justified.
+    "(authed)/edit": "0.24.0",
+    "(authed)/edit/[type]/[slug]": "0.24.0",
     "(authed)/waitlist": "0.18.0",
     "(authed)/waitlist/[experimentId]": "0.18.0",
     "(authed)/waitlist/[experimentId]/signups/[leadId]": "0.18.0",
-    "sign-in": "0.18.0",
+    // #5963 — the `(auth)` route group. `sign-in` keeps its ORIGINAL version
+    // under its new key: ROUTE_SINCE tracks when a route was introduced, not
+    // when it was moved, exactly as the #5637 workspace -> admin rename above
+    // left `(authed)/admin` at 0.22.1. The group's own layout and the four new
+    // pages are genuinely new route directories, so they attach at today's
+    // fixed-group version — the same rule #5977, #5678, #5479, #5371 and #5048
+    // applied.
+    "(auth)": "0.24.0",
+    "(auth)/sign-in": "0.18.0",
+    "(auth)/sign-up": "0.24.0",
+    "(auth)/forgot-password": "0.24.0",
+    "(auth)/reset-password": "0.24.0",
+    "(auth)/verify-email": "0.24.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
@@ -518,7 +617,17 @@ export function surfaceForRouteDir(routeDir) {
  * that the waitlist dashboard also uses, rather than duplicating them.
  */
 export const ROUTE_DEPENDENCIES = {
-    "sign-in": ["apps/web/lib/auth-env.ts", "apps/web/lib/site-brand.tsx"],
+    // #5963 — the (auth) group's layout renders the brand mark through
+    // `siteLogo()`, and the LOCALE layout above it branches on
+    // `isAuthPath()` to drop the marketing chrome for these five paths: without
+    // `auth-routes.ts` a synced group renders inside the Nav + Footer it exists
+    // to replace. The sign-in page no longer imports `site-brand` — the mark is
+    // the shell's since #5963 — so its own list is just the env reader.
+    "(auth)": ["apps/web/lib/site-brand.tsx", "apps/web/lib/auth-routes.ts"],
+    "(auth)/sign-in": ["apps/web/lib/auth-env.ts"],
+    "(auth)/sign-up": ["apps/web/lib/auth-env.ts"],
+    "(auth)/forgot-password": ["apps/web/lib/auth-env.ts"],
+    "(auth)/reset-password": ["apps/web/lib/auth-env.ts"],
     "(authed)": ["apps/web/auth.ts", "apps/web/lib/auth-env.ts"],
     "(authed)/account": [
         "apps/web/lib/account-config.ts",
@@ -526,10 +635,37 @@ 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",
+        `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
+    ],
+    "(authed)/leads": ["apps/web/lib/server-api.ts"],
+    // #5977 — the editor routes' own imports, read from their sources: both
+    // pages call `forwardedCookieInit`/`unwrapApiResult` from `lib/server-api`
+    // and render the shared `ForbiddenState` on the tenant guard's 403, the
+    // same pair `(authed)/admin` already declares. Declared for registry
+    // completeness; inert in practice while the routes are excluded from the
+    // snapshot (see ROUTE_SINCE above).
+    "(authed)/edit": [
+        "apps/web/lib/server-api.ts",
+        `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
+    ],
+    "(authed)/edit/[type]/[slug]": [
+        "apps/web/lib/server-api.ts",
+        `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
+    ],
+    "(authed)/admin/site": [
+        "apps/web/lib/server-api.ts",
+        `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
+    ],
+    "(authed)/admin/team": [
+        "apps/web/lib/server-api.ts",
+        `${ROUTE_ROOT}/(authed)/waitlist/components/ForbiddenState.tsx`,
+    ],
     "(authed)/waitlist": ["apps/web/lib/server-api.ts"],
+    // #6183 S9b D5 — both /meet pages call the shared enabled-slug read.
+    meet: ["apps/web/lib/meeting-slugs.ts"],
+    "meet/[slug]": ["apps/web/lib/meeting-slugs.ts"],
 };
 /**
  * i18n message namespaces (dot-path into `apps/web/messages/<locale>.json`) a
@@ -541,11 +677,23 @@ export const ROUTE_DEPENDENCIES = {
  * to the site owner, same as any other reported gap.
  */
 export const ROUTE_MESSAGE_NAMESPACES = {
-    "sign-in": ["signIn"],
+    // #5963 — `signIn` is untouched and still the sign-in page's namespace; the
+    // group's layout and the four new pages read the new `auth` namespace.
+    "(auth)": ["auth"],
+    "(auth)/sign-in": ["signIn"],
+    "(auth)/sign-up": ["auth"],
+    "(auth)/forgot-password": ["auth"],
+    "(auth)/reset-password": ["auth"],
+    "(auth)/verify-email": ["auth"],
     "(authed)/account": ["account"],
-    "(authed)/workspace": ["workspace"],
-    "(authed)/workspace/site": ["workspace"],
-    "(authed)/workspace/team": ["workspace"],
+    "(authed)/admin": ["admin"],
+    "(authed)/leads": ["leadsInbox"],
+    // #5977 — every string on both editor routes comes from the `edit`
+    // namespace (spec 5872 D10).
+    "(authed)/edit": ["edit"],
+    "(authed)/edit/[type]/[slug]": ["edit"],
+    "(authed)/admin/site": ["admin"],
+    "(authed)/admin/team": ["admin"],
     "(authed)/waitlist": ["waitlistDashboard.gate"],
 };
 /** Template-relative path of the generated site-nav registry. */
@@ -559,19 +707,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 +768,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,23 @@
+/**
+ * Site-template registry, and the roster merge that composes a template with
+ * the modules it takes (spec 5478, unit A of the site-templates mechanism;
+ * design record docs/specs/5462-site-templates-module-bundles-spec.md).
+ *
+ * A site template is DATA AND CONTENT, NOT CODE: a page roster, seed content
+ * and config — never a `page.tsx` (parent § D16). This file declares what a
+ * template IS. It declares no delivery channel, reads no licence, and touches
+ * no disk: the `--template` flag, the bundle fetch and the landing order are
+ * #5481's, and `GET /v1/templates/:name/:version` is #5480's.
+ *
+ * A CODE registry, not per-template JSON (parent § D2): in TypeScript,
+ * `requires` is checked against `RECOGNIZED_MODULES` at compile time, and this
+ * package already twice records that a fixed template FILE is the drift a
+ * registry removes.
+ */
+import type { CategorySlug } from "@working-theory/schema/categories";
 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 +41,59 @@ export interface TemplateManifest {
      * unrecognized name fails type-check rather than a runtime validation.
      */
     requires: readonly ModuleName[];
+    /**
+     * The business categories this template is FOR — one or more LEAF slugs from
+     * the site-category registry (`@working-theory/schema/categories`, #5830),
+     * shared with content's frontmatter `categories`. Required, and typed against
+     * `CategorySlug`, for the same reason `requires` is typed against
+     * `ModuleName`: an unrecognized name fails type-check rather than a runtime
+     * validation, and every template must be findable under at least one
+     * category on the hub's "Browse by business" band.
+     *
+     * LEAVES ONLY. A group slug (`professional-services`, `home-and-trades`, …)
+     * is never a valid value: the group is DERIVED through `groupOf`, so a
+     * template that fits "professional services" names `accounting` and `legal`.
+     * Where a leaf is genuinely missing, the operator adds a leaf to the
+     * registry — never a group here.
+     */
+    categories: readonly CategorySlug[];
+    /**
+     * 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 +106,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).