create-ailk 0.7.0 → 0.8.0

package/dist/starter-grid.js

@@ -0,0 +1,449 @@
+/**
+ * The three pages every starter carries whatever its shape (#6658 D5,
+ * `docs/decisions/starter-roster-page-set.md` D4/D7): a glossary, a newsletter
+ * signup and a book-a-call page. Each is a module-less `GATEABLE_SURFACES`
+ * entry the roster enables, with its seed in `_base`. A template carrying the
+ * scheduling module overrides `BookCall/book-call.mdx` in its own tree, so the
+ * call to action opens `/meet` rather than `/contact`.
+ */
+const SHAPE_INDEPENDENT_ROWS = [
+    { route: "/glossary", content: ["content/en/GlossaryList/glossary.mdx"] },
+    {
+        route: "/newsletter",
+        content: ["content/en/NewsletterSignup/newsletter.mdx"],
+    },
+    { route: "/book-a-call", content: ["content/en/BookCall/book-call.mdx"] },
+];
+/**
+ * The rows every `organization-product` template brings itself — one declared
+ * page set, whichever layer carries each seed. Re-derived by #6658 from the
+ * standard (`derive-roster.py --entity-type software --offering-type software
+ * --primary-goal convert --scale global`, the `--shape organization-product`
+ * equivalent), edited only by the deviations the Free manifest's § 3a records
+ * with their reasons. With a template named, `scaffold()` keeps a `_base` or
+ * overlay seed only when a merged roster row names it (#6646 D1): the roster
+ * decides what installs, and the manifest generator's `--check` proves it.
+ *
+ * Two layers, one roster:
+ *
+ *   - `/`, `/software/[slug]`, `/use-cases`, `/about`, `/faq`, `/contact` and
+ *     `/purchase-policy` take their content from the overlay
+ *     (`template-overlay/content/en/**`, copied whole into `templates/` by
+ *     `build-templates.mjs`). `/features` is the FeaturesList hub over one
+ *     Feature page per feature at `/features/[slug]` (#6721, reversing the
+ *     single `/software/product` page of #6658 D3); both ride the `features`
+ *     surface the roster enables.
+ *     `/use-cases` lists the three UseCase pages at `/use-cases/[slug]`
+ *     (#6658 D4).
+ *   - `/pricing`, `/privacy`, `/terms`, `/glossary`, `/newsletter`,
+ *     `/book-a-call` and the three UseCase pages take their content from 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. Their surfaces are module-less by
+ *     construction (parent § D16, #6658 D5): a template enables them by
+ *     NAMING them in its roster — `scaffold()` selects their
+ *     `GATEABLE_SURFACES` entries from the merged roster's routes (#5469 D10).
+ *
+ * `/software`, `/sign-in` and `/sign-up` carry no `content`: they are code
+ * routes (the SoftwareProduct listing, the SignInCard island, the sign-up
+ * form), like the API-backed rows the scheduling module contributes — listed
+ * so the manifest is a complete install record, where the generator marks
+ * them `kind: route` (#6646 D2).
+ *
+ * `/purchase-policy` is the product-shape purchase policy (#6646 D3): its
+ * overlay seed carries returns, shipping and refunds sections — the overlay,
+ * not `_base`, because the route is core and a scaffold naming no template
+ * serves it too. A service-shape template overrides that seed with its own
+ * cancellation and refunds file.
+ *
+ * `/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 teaser row is an
+ * `organization-product` shape row instead (#6753 D3), which the two aliases
+ * taking docs-blog drop.
+ */
+const TEMPLATE_BASE_ROSTER = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    // #6721 — the product's features: a FeaturesList hub over one Feature page
+    // per feature (replaces the single /software/product page, #6658 D3).
+    { route: "/features", content: ["content/en/FeaturesList/features.mdx"] },
+    { route: "/features/[slug]", contentDir: "content/en/Feature" },
+    {
+        route: "/use-cases",
+        content: ["content/en/UseCasesList/use-cases.mdx"],
+    },
+    { route: "/use-cases/[slug]", contentDir: "content/en/UseCase" },
+    { 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"] },
+    ...SHAPE_INDEPENDENT_ROWS,
+    { route: "/sign-in" },
+    { route: "/sign-up" },
+    { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
+    { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
+    {
+        route: "/purchase-policy",
+        content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"],
+    },
+];
+/**
+ * The Free `/blog` teaser (#5469 D3) — one static BlogList page (schema `Blog`
+ * with an empty `ItemList`; the correct page type, not a LandingPage) that
+ * says what the Pro docs-blog module gives you. It is served by the generic
+ * `[slug]` route — which probes `LandingPage` first, then `BlogList` — over
+ * `content/en/BlogList/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. An `organization-product` shape row
+ * (#6753 D3): the aliases taking docs-blog drop it, so on `marketing-site`
+ * the docs-blog contribution claims the route.
+ */
+const FREE_BLOG_TEASER_ROW = {
+    route: "/blog",
+    content: ["content/en/BlogList/blog.mdx"],
+};
+/**
+ * The rows for the `signal-collectors` bundle's six sample pages (#6646
+ * disposition (a)) — the project listing, its two project pages and the
+ * three thank-you pages its `installMap` lands. The module contributes no
+ * row for any of these routes (`module-architecture.ts`'s installMap
+ * comment), so a template that takes the module declares them, and the
+ * roster names every page the scaffold installs. `/projects` is a
+ * module-less `GATEABLE_SURFACES` entry, so naming it here also copies the
+ * route directory the samples render through (`rosterSurfaces`).
+ */
+const SIGNAL_COLLECTORS_SAMPLE_ROWS = [
+    { route: "/projects", content: ["content/en/ProjectsList/projects.mdx"] },
+    { route: "/projects/[slug]", contentDir: "content/en/Project" },
+    { route: "/thanks/[slug]", contentDir: "content/en/ThankYouPage" },
+];
+/**
+ * The portfolio pages (#6687) — before/after project comparisons: a
+ * PortfolioList hub on the /alternatives stack and one PortfolioItem page per
+ * comparison, each one `before-after` section carrying its header band and
+ * pager. They belong to the SHAPE, Free included (roadmap § 4, operator
+ * 2026-09-25, reversing #6687's "Pro and up"): every shape roster below
+ * carries them, and an alias sheds them only by an explicit `drop`. The seeds
+ * live in the `_base` layer under `content/en/PortfolioItem/`; the detail
+ * row's `contentDir` installs them (#6646 D1), exactly as `/use-cases/[slug]`
+ * serves `content/en/UseCase`.
+ */
+// NO_HAND_IMPLEMENT_OK: /build-starter operator-directed live pass (#6687).
+const PORTFOLIO_ROWS = [
+    { route: "/portfolio", content: ["content/en/PortfolioList/portfolio.mdx"] },
+    { route: "/portfolio/[slug]", contentDir: "content/en/PortfolioItem" },
+];
+/**
+ * `minimalism-site`'s two OWN rows (#5589, shrunk from its own 17-row roster
+ * by #6757 once the `organization-service` shape carried a standard roster of
+ * its own): the deck's two `LandingPage` slugs, positioned by `insert` (D7)
+ * at the two points this alias interleaves them into the shape's row order
+ * (§ 1.2) — `/reports` before `/about`, `/referral` before `/faq`. Neither
+ * carries a `GATEABLE_SURFACES` entry: both are single-segment slugs served
+ * by the generic `[slug]` route (#5469 D2), the same mechanism Free's
+ * `/how-it-works` used.
+ */
+const REPORTS_ROW = {
+    route: "/reports",
+    content: ["content/en/LandingPage/reports.mdx"],
+};
+const REFERRAL_ROW = {
+    route: "/referral",
+    content: ["content/en/LandingPage/referral.mdx"],
+};
+/**
+ * `organization-service`'s own rows (#6757 D1), derived from
+ * `derive-roster.py --shape organization-service --primary-goal generate-leads
+ * --registry packages/schema/src/registry/entries.ts` at harness commit
+ * `7bdaf148e1b0e639cd90a80008955e55cc4aa2b5`, edited only by the deviations
+ * `site-templates/shapes/organization-service/TEMPLATE-MANIFEST.md` § 3a
+ * records with their reasons. Row order matches `minimalism-site`'s (D3), so
+ * that alias's `differences` are additions and drops only.
+ */
+const ORGANIZATION_SERVICE_ROWS = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    { route: "/about", content: ["content/en/AboutPage/about.mdx"] },
+    { route: "/services", content: ["content/en/ServicesList/services.mdx"] },
+    { route: "/services/[slug]", contentDir: "content/en/Service" },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.mdx"] },
+    ...SHAPE_INDEPENDENT_ROWS,
+    { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
+    { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
+    {
+        route: "/purchase-policy",
+        content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"],
+    },
+];
+/**
+ * `local-business-service`'s own rows (#6757 D1), derived the same way with
+ * `--shape local-business-service`. It has no `--template` alias of its own
+ * since #6789 retired the one alias that composed it; `--shape` is its only entry.
+ */
+const LOCAL_BUSINESS_SERVICE_ROWS = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    { route: "/services", content: ["content/en/ServicesList/services.mdx"] },
+    { route: "/services/[slug]", contentDir: "content/en/Service" },
+    { route: "/about", content: ["content/en/AboutPage/about.mdx"] },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.mdx"] },
+    ...SHAPE_INDEPENDENT_ROWS,
+    {
+        route: "/purchase-policy",
+        content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"],
+    },
+    { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
+    { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
+];
+/**
+ * `person-service`'s own rows (#6758 D1, D3), derived from
+ * `derive-roster.py --shape person-service --primary-goal generate-leads
+ * --registry packages/schema/src/registry/entries.ts` at harness commit
+ * `7bdaf148e1b0e639cd90a80008955e55cc4aa2b5` (the vendored equivalent:
+ * `--entity-type person --offering-type services --primary-goal
+ * generate-leads --scale global`), edited only by the deviations
+ * `site-templates/shapes/person-service/TEMPLATE-MANIFEST.md` § 3a records
+ * with their reasons. Row order matches `local-business-service`'s (D3):
+ * services before about, because a consultant is hired for an engagement
+ * first.
+ */
+const PERSON_SERVICE_ROWS = [
+    { route: "/", content: ["content/en/HomePage/home.mdx"] },
+    { route: "/services", content: ["content/en/ServicesList/services.mdx"] },
+    { route: "/services/[slug]", contentDir: "content/en/Service" },
+    { route: "/about", content: ["content/en/AboutPage/about.mdx"] },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.mdx"] },
+    ...SHAPE_INDEPENDENT_ROWS,
+    {
+        route: "/purchase-policy",
+        content: ["content/en/PurchasePolicyPage/purchase-policy.mdx"],
+    },
+    { route: "/privacy", content: ["content/en/PrivacyPage/privacy.mdx"] },
+    { route: "/terms", content: ["content/en/TermsPage/terms.mdx"] },
+];
+/**
+ * Each buildable shape's standard roster (#6753 D3) — the rows an alias starts
+ * from before its `differences` apply.
+ *
+ * `organization-product` is today's base roster, the `/blog` teaser and the
+ * portfolio pair. `organization-service`, `local-business-service` (#6757)
+ * and `person-service` (#6758, roadmap § 6 Phase 2) are each their own rows,
+ * the `/blog` teaser and the portfolio pair.
+ */
+export const SHAPE_ROSTERS = Object.freeze({
+    "organization-product": [
+        ...TEMPLATE_BASE_ROSTER,
+        FREE_BLOG_TEASER_ROW,
+        ...PORTFOLIO_ROWS,
+    ],
+    "organization-service": [
+        ...ORGANIZATION_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...PORTFOLIO_ROWS,
+    ],
+    "local-business-service": [
+        ...LOCAL_BUSINESS_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...PORTFOLIO_ROWS,
+    ],
+    "person-service": [
+        ...PERSON_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...PORTFOLIO_ROWS,
+    ],
+});
+/**
+ * The `--template` names and the grid coordinates each stands for (#6753) —
+ * the one table `TEMPLATE_MANIFESTS` and `RECOGNIZED_TEMPLATES` derive from,
+ * in the declaration order both keep. The plain name is the Pro one: it is
+ * the flagship and the demo (Sam, 2026-09-14, parent § D12).
+ *
+ * `workspace` appears in no module list. It is a Pro module, but an authed app
+ * surface contributing no PUBLIC page to a marketing site, and `modules` names
+ * what the roster uses (parent § D15). A Pro key unlocks it regardless of any
+ * template.
+ *
+ * `commerce` is a per-site add-on available at any level, so no alias exists
+ * FOR it (parent § D13); it still contributes rows to whichever alias takes
+ * it, through `mergeRoster`.
+ *
+ * Frozen (#5507): the registry composed from this table is also the issuer's
+ * authorization allowlist (spec 5480 § C7). A test needing a different table
+ * passes its own to `resolveTemplate(name, aliases)` rather than mutating
+ * this one.
+ */
+export const ALIASES = 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
+     * template we ship anyway rather than by a throwaway fixture. The bare
+     * `organization-product` shape — no differences at all.
+     */
+    "marketing-site-free": {
+        shape: "organization-product",
+        design: "standard",
+        modules: ["marketing"],
+        categories: ["accounting", "legal", "technology"],
+        // The demo site carries the "Get started with this template" banner
+        // (operator ruling 2026-09-23); every other layout knob keeps its default.
+        layout: { announcementBanner: true },
+    },
+    /**
+     * The Pro flagship. Its module list is OFFERINGS § 4 offering 3's tiers line
+     * — "docs, scheduling and flows modules" — where "flows" is
+     * `signal-collectors` (`MODULE_SURFACES` maps it to `["flows"]`). It drops
+     * the shape's `/blog` teaser because docs-blog contributes the real `/blog`,
+     * and adds the signal-collectors sample rows ahead of the portfolio pair.
+     */
+    "marketing-site": {
+        shape: "organization-product",
+        design: "standard",
+        modules: ["marketing", "docs-blog", "scheduling", "signal-collectors"],
+        // The flagship is the general-purpose template: it carries the whole
+        // registry, so every group tile on the hub has at least one template.
+        categories: [
+            "accounting",
+            "legal",
+            "consulting",
+            "hvac",
+            "roofing",
+            "plumbing",
+            "electrical",
+            "landscaping",
+            "auto-repair",
+            "real-estate",
+            "technology",
+            "medical-specialty",
+        ],
+        differences: {
+            drop: ["/blog"],
+            add: SIGNAL_COLLECTORS_SAMPLE_ROWS,
+            before: "/portfolio",
+        },
+    },
+    /**
+     * Pro Plus — the Pro list plus `multi-tenant`, which is correctly in the
+     * list because it DOES contribute pages (the org and workspace surfaces).
+     * Its `pageContributions` is nonetheless unset today, deferred to its own
+     * instance, so this template's merged roster carries the same contributed
+     * rows as `marketing-site`'s and no more. That is a module which has
+     * declared no rows yet — visible in the diff — not a merge that dropped
+     * declared rows.
+     */
+    "saas-product": {
+        shape: "organization-product",
+        design: "standard",
+        modules: [
+            "marketing",
+            "docs-blog",
+            "scheduling",
+            "signal-collectors",
+            "multi-tenant",
+        ],
+        categories: ["technology", "medical-specialty"],
+        differences: {
+            drop: ["/blog"],
+            add: SIGNAL_COLLECTORS_SAMPLE_ROWS,
+            before: "/portfolio",
+        },
+    },
+    /**
+     * The second Pro template (#5589) — the reports-first, scroll-snap deck
+     * site. NOT `marketing-site` plus a module: its `modules` omit `docs-blog`,
+     * so the two Pro templates are siblings under `_base` (#5618 D2), never a
+     * lineage. Level still derives from `modules`: `scheduling` and
+     * `signal-collectors` are paid, so `templateDelivery` returns `"paid"`
+     * exactly as it does for `marketing-site`.
+     *
+     * It composes the `organization-service` shape roster (#6757) rather than
+     * the organization-product one: the deck home replaces the document-scroll
+     * home, and `/how-it-works`, the product page, `/pricing` and `/sign-in`
+     * are not pages this site has. The roster is what the
+     * template IS, so an unrostered page has neither a route directory
+     * (`rosterSurfaces`) nor its `_base`/overlay seed (#6646 D1).
+     *
+     * It declares NO `layout` block (#6638): the deck home, mark-only nav and
+     * centered footer are the `minimalism` design's, supplied by
+     * `DESIGN_LAYOUTS` from `design:` — the look any shape can wear. The
+     * roster rows the `organization-service` shape does not derive
+     * (`/reports`, `/referral`) are recorded with their reasons in this
+     * template's TEMPLATE-MANIFEST.md § 3a.
+     *
+     * `/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 its seed DIRECTORY as `contentDir`
+     * (`content/en/Service`, as `routes-map.ts` records it). The three
+     * samples ride the template tree unmapped, landing at that directory.
+     *
+     * Since #6757, `organization-service` carries a real standard roster
+     * (D1), so this alias's `differences` is additions and drops only: it
+     * drops the `/blog` teaser (a Pro alias does not upsell its own level,
+     * D8) and the portfolio pair (the reports are the proof, not a
+     * portfolio), adds the signal-collectors samples, and INSERTS its two own
+     * rows — `/reports` before `/about`, `/referral` before `/faq` (D7) — to
+     * reproduce its pre-#6757 row order (§ 1.2) exactly.
+     */
+    "minimalism-site": {
+        shape: "organization-service",
+        design: "minimalism",
+        modules: ["marketing", "scheduling", "signal-collectors"],
+        categories: ["real-estate", "technology", "legal"],
+        differences: {
+            drop: ["/blog", "/portfolio", "/portfolio/[slug]"],
+            add: SIGNAL_COLLECTORS_SAMPLE_ROWS,
+            insert: [
+                { before: "/about", rows: [REPORTS_ROW] },
+                { before: "/faq", rows: [REFERRAL_ROW] },
+            ],
+        },
+    },
+});
+/**
+ * The coordinates a keyless `--shape S` builds (#6757 D5) — the composed
+ * FREE manifest per shape, for a shape with no `--template` alias of its
+ * own. Frozen and `Partial`; `organization-product` needs none — its
+ * keyless tree is `marketing-site-free`'s (#6754 AC-2).
+ *
+ * No `differences` (a bare shape is its standard roster, D1) and no
+ * `layout`. Every category is a leaf of `packages/schema/src/categories.ts`,
+ * as `TemplateManifest.categories` requires. `person-service`'s single
+ * `consulting` category is the operator's disposition (2026-09-26,
+ * ai-launch-kit-internal#6758): the leaf did not exist when #6758's spec was
+ * written, and adding it replaced that spec's `["accounting", "legal",
+ * "technology"]` author-pick stand-in.
+ */
+export const SHAPE_STARTER_ALIASES = Object.freeze({
+    "organization-service": {
+        shape: "organization-service",
+        design: "standard",
+        modules: ["marketing"],
+        categories: ["accounting", "legal", "real-estate"],
+    },
+    "local-business-service": {
+        shape: "local-business-service",
+        design: "standard",
+        modules: ["marketing"],
+        categories: [
+            "hvac",
+            "roofing",
+            "plumbing",
+            "electrical",
+            "landscaping",
+            "auto-repair",
+        ],
+    },
+    "person-service": {
+        shape: "person-service",
+        design: "standard",
+        modules: ["marketing"],
+        categories: ["consulting"],
+    },
+});

package/dist/surfaces.d.ts

@@ -192,10 +192,10 @@ export declare 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.