create-ailk 0.7.0 → 0.8.0

package/dist/surfaces.js

@@ -81,13 +81,6 @@ export const CORE_ROUTE_DIRS = [
     // scaffold carrying it and no content is byte-for-byte a scaffold with one
     // more 404, nothing else.
     `${ROUTE_ROOT}/[slug]`,
-    // #6658 D3 — the product's own detail page (`/software/product`, a
-    // SoftwareProduct → SoftwareApplication), which replaced the /features
-    // stand-in. Core for the same reason [slug] is: its content
-    // (`content/en/SoftwareProduct/product.mdx`) is in the always-copied overlay
-    // and the generated nav always links it, so every scaffold — template or
-    // not — must carry the route.
-    `${ROUTE_ROOT}/software`,
     // #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
@@ -180,6 +173,13 @@ export const GATEABLE_SURFACES = [
         routes: [`${ROUTE_ROOT}/events`],
         content: ["content/<locale>/EventsList", "content/<locale>/Event"],
     },
+    {
+        // #6721 — the product's feature pages: a FeaturesList hub over one
+        // Feature page per feature. The Free roster enables it by its rows.
+        id: "features",
+        routes: [`${ROUTE_ROOT}/features`],
+        content: ["content/<locale>/FeaturesList", "content/<locale>/Feature"],
+    },
     {
         // API-backed (the flow engine); no MDX of its own.
         id: "flows",
@@ -240,6 +240,11 @@ export const GATEABLE_SURFACES = [
         routes: [`${ROUTE_ROOT}/partners`],
         content: ["content/<locale>/PartnersList", "content/<locale>/Partner"],
     },
+    {
+        id: "portfolio",
+        routes: [`${ROUTE_ROOT}/portfolio`],
+        content: ["content/<locale>/PortfolioList", "content/<locale>/PortfolioItem"],
+    },
     {
         // Module-LESS by construction (#5479 D16): no MODULE_SURFACES value names
         // it, so a site template may enable it by roster alone. Same for
@@ -276,6 +281,13 @@ export const GATEABLE_SURFACES = [
         routes: [`${ROUTE_ROOT}/services`],
         content: ["content/<locale>/ServicesList", "content/<locale>/Service"],
     },
+    {
+        // #6721 — the product's own page (#6658 D3), a gateable surface again now
+        // that the Free roster links /features instead of /software/product.
+        id: "software",
+        routes: [`${ROUTE_ROOT}/software`],
+        content: ["content/<locale>/SoftwareProduct"],
+    },
     {
         id: "tech-articles",
         routes: [`${ROUTE_ROOT}/tech-articles`],
@@ -319,7 +331,10 @@ export const SURFACE_ALIASES = {
  * so a site scaffolded with `--surfaces software` keeps working: its route
  * is copied regardless.
  */
-export const CORE_PROMOTED_SURFACES = new Set(["software"]);
+// #6721 — `software` is a gateable surface again (the Free roster now carries
+// /features + /features/[slug] instead); the set is kept, empty, so the
+// accept-and-drop read sites stay in place for the next promotion.
+export const CORE_PROMOTED_SURFACES = new Set([]);
 /** Canonical id for a `--surfaces` value, resolving a retired alias. */
 function canonicalizeSurface(s) {
     return SURFACE_ALIASES[s] ?? s;
@@ -509,6 +524,9 @@ export const ROUTE_SINCE = {
     downloads: "0.0.0",
     events: "0.0.0",
     "events/[slug]": "0.0.0",
+    // #6721 — the feature pages, a new route pair at today's line.
+    features: "0.27.0",
+    "features/[slug]": "0.27.0",
     faq: "0.0.0",
     "flows/[slug]": "0.0.0",
     "flows/[slug]/results/[payload]": "0.14.0",
@@ -531,6 +549,9 @@ export const ROUTE_SINCE = {
     // #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.
+    // #6687 — the before/after portfolio, a new route pair at today's line.
+    portfolio: "0.27.0",
+    "portfolio/[slug]": "0.27.0",
     pricing: "0.22.0",
     privacy: "0.22.0",
     products: "0.0.0",
@@ -750,10 +771,10 @@ export const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
  *
  * The base items are the Free marketing-site chrome (#5469 D5, the approved
  * chrome diff recorded on that card, re-pointed by #6658 D8):
- * a Product flyout (Use cases · Features · FAQ), then Use cases, Blog, Pricing
- * and About. Features links the product's own page (`/software/product`), a
- * core route like `/faq` and `/about`; `/blog` is always linked (the teaser or
- * the docs-blog module serves it). Use cases and Pricing are gateable
+ * a Product flyout in two columns (Features · Use Cases, #6721), then Blog,
+ * Pricing and About. The feature and use-case links ride the `features` and
+ * `use-cases` surfaces; `/blog` is always linked (the teaser or the docs-blog
+ * module serves it). Pricing is gateable
  * surfaces: each item is emitted only when its surface is enabled (a template
  * roster enables it, #5469 D10), so the nav still never links a page the
  * scaffold does not carry.
@@ -781,49 +802,77 @@ export function renderNavConfig(enabled) {
         s.id !== "blog" &&
         s.id !== "use-cases");
     const useCases = on.has("use-cases");
+    const features = on.has("features");
+    // #6721 (operator ruling 2026-09-25): the Product flyout is two columns —
+    // Features and Use Cases — each a heading over three label-only links. The
+    // `groups` render the desktop panel; `features` carries the same links for
+    // the mobile disclosure and the active-path match. "Use cases" left the top
+    // nav (it lives in the flyout and its own footer column).
+    const featureLinks = features
+        ? [
+            '        { labelKey: "feature1", path: "/features/feature-1" },',
+            '        { labelKey: "feature2", path: "/features/feature-2" },',
+            '        { labelKey: "feature3", path: "/features/feature-3" },',
+        ]
+        : [];
+    const useCaseLinks = useCases
+        ? [
+            '        { labelKey: "useCase1", path: "/use-cases/persona-1" },',
+            '        { labelKey: "useCase2", path: "/use-cases/persona-2" },',
+            '        { labelKey: "useCase3", path: "/use-cases/persona-3" },',
+        ]
+        : [];
+    const indent = (line) => `    ${line}`;
+    const group = (headingKey, links) => links.length === 0
+        ? []
+        : [
+            "        {",
+            `          headingKey: "${headingKey}",`,
+            "          items: [",
+            ...links.map(indent),
+            "          ],",
+            "        },",
+        ];
     const entries = [
         "  {",
         '    labelKey: "product",',
         "    flyout: {",
-        // SOFT_LOCK_OK: #6508 — width "panel" (D4/D5): a fixed 640px, two-column
-        // grid, replacing the "list"/"trigger" one-column menu. `presentation` is
-        // omitted — it defaults to "grid" (D5). The `docs` action is dropped (it
-        // duplicated the first feature's /how-it-works destination, § 1.4).
+        // SOFT_LOCK_OK: #6508 — width "panel" (D4/D5): a fixed 640px panel.
         '      width: "panel",',
         "      features: [",
-        ...(useCases
-            ? ['        { labelKey: "useCases", descKey: "useCasesDesc", icon: Layers, path: "/use-cases" },']
-            : []),
-        '        { labelKey: "features", descKey: "featuresDesc", icon: Sparkles, path: "/software/product" },',
-        '        { labelKey: "faq", descKey: "faqDesc", icon: HelpCircle, path: "/faq" },',
+        ...featureLinks,
+        ...useCaseLinks,
+        "      ],",
+        "      groups: [",
+        ...group("flyoutFeaturesHeading", featureLinks),
+        ...group("flyoutUseCasesHeading", useCaseLinks),
         "      ],",
         "      actions: [],",
         "    },",
         "  },",
-        // Operator ruling 2026-09-23: Product · Use cases · Blog · Pricing · About.
+        // Operator ruling 2026-09-25: Product · Blog · Pricing · About.
         // `/blog` is always linked — the `blog` surface serves the real route, and
         // with it off the `[slug]` route serves the overlay's module page.
-        ...(useCases ? ['  { labelKey: "useCases", path: "/use-cases" },'] : []),
         '  { labelKey: "blog", path: "/blog" },',
         ...(on.has("pricing") ? ['  { labelKey: "pricing", path: "/pricing" },'] : []),
         '  { labelKey: "about", path: "/about" },',
         ...linked.map((s) => `  { labelKey: "${s.navLabelKey}", path: "/${s.id}" },`),
     ];
-    // The footer's column groups (operator ruling 2026-09-23, replacing #6468's
-    // Product/Company pair): Site pages, Features, Resources. Pricing rides the
-    // same `pricing` gate as the header item; `/blog` is always linked (above).
-    // The product links point at the product's own page, `/software/product`
-    // (#6658 D3): `software` is core, so they stay unconditional. Book a call,
-    // Glossary and Newsletter (#6658 D8) each ride their own surface's gate.
+    // The footer's column groups (operator rulings 2026-09-23 + 2026-09-25):
+    // Site pages, Features, Use Cases, Resources. Pricing rides the same
+    // `pricing` gate as the header item; `/blog` is always linked (above). The
+    // Features column links the three feature pages and the /features hub; the
+    // Use Cases column the three use cases and the /use-cases hub — each rides
+    // its surface's gate. Book a call, Glossary and Newsletter (#6658 D8) each
+    // ride their own surface's gate.
     const footerEntries = [
         "  {",
         '    headingKey: "footerSitePagesHeading",',
         "    items: [",
-        '      { labelKey: "features", path: "/software/product" },',
+        ...(features ? ['      { labelKey: "features", path: "/features" },'] : []),
         ...(on.has("pricing")
             ? ['      { labelKey: "pricing", path: "/pricing" },']
             : []),
-        ...(useCases ? ['      { labelKey: "useCases", path: "/use-cases" },'] : []),
         '      { labelKey: "about", path: "/about" },',
         '      { labelKey: "contact", path: "/contact" },',
         ...(on.has("book-a-call")
@@ -831,17 +880,28 @@ export function renderNavConfig(enabled) {
             : []),
         "    ],",
         "  },",
-        "  {",
-        '    headingKey: "footerFeaturesHeading",',
-        "    items: [",
-        '      { labelKey: "feature1", path: "/software/product" },',
-        '      { labelKey: "feature2", path: "/software/product" },',
-        '      { labelKey: "feature3", path: "/software/product" },',
-        '      { labelKey: "feature4", path: "/software/product" },',
-        '      { labelKey: "feature5", path: "/software/product" },',
-        '      { labelKey: "allFeatures", path: "/software/product" },',
-        "    ],",
-        "  },",
+        ...(features
+            ? [
+                "  {",
+                '    headingKey: "footerFeaturesHeading",',
+                "    items: [",
+                ...featureLinks.map((l) => l.slice(2)),
+                '      { labelKey: "allFeatures", path: "/features" },',
+                "    ],",
+                "  },",
+            ]
+            : []),
+        ...(useCases
+            ? [
+                "  {",
+                '    headingKey: "footerUseCasesHeading",',
+                "    items: [",
+                ...useCaseLinks.map((l) => l.slice(2)),
+                '      { labelKey: "allUseCases", path: "/use-cases" },',
+                "    ],",
+                "  },",
+            ]
+            : []),
         "  {",
         '    headingKey: "footerResourcesHeading",',
         "    items: [",
@@ -878,7 +938,6 @@ export function renderNavConfig(enabled) {
 // \`apps/web/messages/<locale>.json\`. Paths are locale-agnostic — Nav prefixes
 // them with the active locale at render.
 ${navItemImport}
-import { HelpCircle, Layers, Sparkles } from "lucide-react";
 
 export const navItems: NavItem[] = [
 ${entries.join("\n")}

package/dist/template-manifest.d.ts

@@ -18,6 +18,7 @@ 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";
+import { type BuildableShape, type TemplateAlias } from "./starter-grid.js";
 /**
  * The closed **shape** enum (starter-template contract § The three axes,
  * operator-disposed 2026-09-24) — `<primary node>-<offering node>` in
@@ -155,21 +156,10 @@ 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.
+ * The declared templates, each composed once at load from its `ALIASES` row
+ * (#6753) — no manifest here is hand-typed, so a template's shape, design,
+ * modules and roster have one authority: `starter-grid.ts`. Declaration order
+ * is `ALIASES`'s, which is `RECOGNIZED_TEMPLATES`'s.
  *
  * Frozen (#5507): this registry is also the issuer's authorization allowlist
  * (spec 5480 § C7) — a mutable global there could be monkey-patched at
@@ -177,8 +167,37 @@ export declare class TemplateError extends Error {
  * 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;
+/**
+ * The composed FREE manifest per shape with no `--template` alias of its own
+ * (#6757 D5) — the coordinates a keyless `--shape S` builds. `Object.freeze`d,
+ * composed once at load by the same module-private `composeManifest` over
+ * `SHAPE_STARTER_ALIASES`, each manifest's `name` the shape. Data holding
+ * composed manifests, the status D5 gives `TEMPLATE_MANIFESTS`;
+ * `resolveTemplate` stays the only exported function that yields a
+ * template's roster, and its behavior is unchanged — it does NOT resolve a
+ * shape name (NFR-3, the issuer allowlist stays `TEMPLATE_MANIFESTS`-only).
+ */
+export declare const SHAPE_STARTERS: Readonly<Partial<Record<BuildableShape, TemplateManifest>>>;
+/**
+ * Where a starter's files live under `site-templates/` (#6757 D5) — the one
+ * place that says so. A `SHAPE_STARTERS` key (a bare-shape starter with no
+ * `--template` alias) lives at `shapes/<name>`, out of the template showcase
+ * (§ 1.6); every other name (a declared `--template` alias) is unchanged.
+ */
+export declare function templateTreeDir(name: string): string;
+/**
+ * Look up a declared template — the one exported function that yields a
+ * template's roster (#6753 AC-1); `TEMPLATE_MANIFESTS`, the frozen record it
+ * reads, holds only manifests composed from `ALIASES`.
+ *
+ * With no `aliases`, returns the frozen `TEMPLATE_MANIFESTS` entry itself.
+ * With an injected alias table — the `resolveTemplateLineage` precedent
+ * (#5507) — composes `aliases[name]` against the shipped shape rosters, so a
+ * test exercises the composer's refusals without touching the shipped table.
+ *
+ * @throws TemplateError on an undeclared name, or a malformed injected alias.
+ */
+export declare function resolveTemplate(name: string, aliases?: Readonly<Record<string, TemplateAlias>>): TemplateManifest;
 /**
  * Resolve a template's `extends` chain — `[name, …ancestors, "_base"]` — in
  * the client registry, before any fetch (#5618 D2). `_base` is the only