create-ailk 0.7.0 → 0.9.0

package/dist/starter-grid.js

@@ -0,0 +1,545 @@
+/**
+ * The two pages every starter carries whatever its shape (#6658 D5,
+ * `docs/decisions/starter-roster-page-set.md` D4/D7): a glossary and a
+ * newsletter signup. Each is a module-less `GATEABLE_SURFACES` entry the
+ * roster enables, with its seed in `_base`.
+ *
+ * The third — `/book-a-call` — was retired by #6897 D10: every scaffold's
+ * former `/book-a-call` link now points at `/meet/book-a-call`, served by
+ * `FREE_MEET_PLACEHOLDER_ROWS` below (a Free placeholder) or by the
+ * scheduling module's own live `/meet/[slug]` page.
+ */
+const SHAPE_INDEPENDENT_ROWS = [
+    { route: "/glossary", content: ["content/en/GlossaryList/glossary.mdx"] },
+    {
+        route: "/newsletter",
+        content: ["content/en/NewsletterSignup/newsletter.mdx"],
+    },
+];
+/**
+ * The Free `/meet` placeholder pages (#6897 D5) — a meeting-types hub
+ * (`LandingPage`, served by the generic `[slug]` route) and its four
+ * `BookCall` detail seeds (served by the `[slug]/[detail]` route, D2). Both
+ * ship in the always-copied overlay, beside `FREE_BLOG_TEASER_ROW`, so a
+ * template-less scaffold's Contact tiles (which link `/meet/*` too) reach
+ * real pages. The second row uses an explicit `content` list, not
+ * `contentDir`, because only a `content`-list row is removed by
+ * `planRosterAppend`'s add-module supersede (F4's add-module half,
+ * `site-roster.ts`).
+ *
+ * Every alias that takes the `scheduling` module drops `"/meet"` and
+ * `"/meet/[slug]"` (D5) — otherwise `mergeRoster` refuses the duplicate
+ * route the module's own rows also contribute. The ROWS go; the SEEDS stay
+ * (#6942, operator 2026-09-28, partly reversing D5): until
+ * `SCHEDULING_CAL_LINK` is configured the module's pages hand off to the Free
+ * placeholder routes, which serve these seeds. `withMeetPlaceholderSeeds`
+ * (`site-roster.ts`) folds them onto the module's rows.
+ */
+const FREE_MEET_PLACEHOLDER_ROWS = [
+    { route: "/meet", content: ["content/en/LandingPage/meet.mdx"] },
+    {
+        route: "/meet/[slug]",
+        content: [
+            "content/en/BookCall/book-a-call.mdx",
+            "content/en/BookCall/onsite-estimate.mdx",
+            "content/en/BookCall/start-project.mdx",
+            "content/en/BookCall/onsite-service.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]`, `/for`, `/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.
+ *     `/for` lists the three UseCase pages at `/for/[slug]`
+ *     (#6658 D4).
+ *   - `/pricing`, `/privacy`, `/terms`, `/glossary`, `/newsletter`,
+ *     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" },
+    {
+        // #6878 D7 — the persona hub, renamed from /use-cases.
+        route: "/for",
+        content: ["content/en/UseCasesList/for.mdx"],
+    },
+    { route: "/for/[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 `/for/[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/ReportsList/reports.mdx"],
+};
+const REFERRAL_ROW = {
+    route: "/referral",
+    content: ["content/en/LandingPage/referral.mdx"],
+};
+/**
+ * The signal-collectors module's report/referral sample rows (spec 6892 D3):
+ * `/reports`, a `ReportsList` hub over the module's four `ReportPage` seeds,
+ * and `/referral`, a sample flow landing page. `marketing-site` and
+ * `saas-product` add these before `/portfolio`, alongside
+ * `SIGNAL_COLLECTORS_SAMPLE_ROWS`; `minimalism-site` keeps its own two
+ * `insert` groups instead (its pre-existing row order, D1).
+ */
+const SIGNAL_COLLECTORS_REPORT_ROWS = [
+    REPORTS_ROW,
+    REFERRAL_ROW,
+];
+/**
+ * `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" },
+    // #6878 D7 — every shape carries the /for family now, service shapes
+    // included: the seeds are shape-neutral (D7), so no per-shape override is
+    // needed.
+    {
+        route: "/for",
+        content: ["content/en/UseCasesList/for.mdx"],
+    },
+    { route: "/for/[slug]", contentDir: "content/en/UseCase" },
+    { route: "/contact", content: ["content/en/ContactPage/contact.mdx"] },
+    { route: "/faq", content: ["content/en/FAQPage/faq.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"],
+    },
+];
+/**
+ * `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" },
+    // #6878 D7 — every shape carries the /for family now (D7 shape-neutral seeds).
+    {
+        route: "/for",
+        content: ["content/en/UseCasesList/for.mdx"],
+    },
+    { route: "/for/[slug]", contentDir: "content/en/UseCase" },
+    { 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: "/sign-in" },
+    { route: "/sign-up" },
+    {
+        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" },
+    // #6878 D7 — every shape carries the /for family now (D7 shape-neutral seeds).
+    {
+        route: "/for",
+        content: ["content/en/UseCasesList/for.mdx"],
+    },
+    { route: "/for/[slug]", contentDir: "content/en/UseCase" },
+    { 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: "/sign-in" },
+    { route: "/sign-up" },
+    {
+        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. Every shape's own rows carry
+ * `/sign-in` and `/sign-up` (#6797): the locale layout's header links both on
+ * every shape, so the roster of record lists them as code routes.
+ */
+export const SHAPE_ROSTERS = Object.freeze({
+    "organization-product": [
+        ...TEMPLATE_BASE_ROSTER,
+        FREE_BLOG_TEASER_ROW,
+        ...FREE_MEET_PLACEHOLDER_ROWS,
+        ...PORTFOLIO_ROWS,
+    ],
+    "organization-service": [
+        ...ORGANIZATION_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...FREE_MEET_PLACEHOLDER_ROWS,
+        ...PORTFOLIO_ROWS,
+    ],
+    "local-business-service": [
+        ...LOCAL_BUSINESS_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...FREE_MEET_PLACEHOLDER_ROWS,
+        ...PORTFOLIO_ROWS,
+    ],
+    "person-service": [
+        ...PERSON_SERVICE_ROWS,
+        FREE_BLOG_TEASER_ROW,
+        ...FREE_MEET_PLACEHOLDER_ROWS,
+        ...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", "/meet", "/meet/[slug]"],
+            add: [...SIGNAL_COLLECTORS_SAMPLE_ROWS, ...SIGNAL_COLLECTORS_REPORT_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", "/meet", "/meet/[slug]"],
+            add: [...SIGNAL_COLLECTORS_SAMPLE_ROWS, ...SIGNAL_COLLECTORS_REPORT_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 own `layout` (its
+     * `DESIGN.md`, resolved by `resolveDesign` off `design:` — #6813 D4) — the
+     * look any shape can wear. This alias ships no tree of its own (`ownTree:
+     * false`, spec 6892 D1); its GENERATED roster record (no narrative `.md`,
+     * D5) lives at `site-templates/aliases/minimalism-site.TEMPLATE-MANIFEST.json`.
+     *
+     * `/reports` (a `ReportsList` hub over `ReportPage`) and `/referral` (a
+     * flow landing page) are signal-collectors module samples (spec 6892 D3);
+     * neither carries a `GATEABLE_SURFACES` entry: `/referral` is a
+     * single-segment `LandingPage` slug served by the generic `[slug]` route
+     * (#5469 D2), the same mechanism Free's `/how-it-works` uses, and `/reports`
+     * is its own routes-map row. `/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), the portfolio pair (the reports are the proof, not a
+     * portfolio) and the two auth code routes the shape rosters (#6797 —
+     * this site has no `/sign-in`, above), 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"],
+        // Spec 6892 D1 — this alias ships no `site-templates/minimalism-site/`
+        // tree of its own: it resolves purely from the grid. Its seed layer is
+        // its shape's tree (`templateTreeDir`), its deck home + SVGs are a
+        // sample the `minimalism` design installs (D4), and its `/reports` +
+        // `/referral` rows are signal-collectors module samples (D3).
+        ownTree: false,
+        differences: {
+            drop: [
+                "/sign-in",
+                "/sign-up",
+                "/blog",
+                "/meet",
+                "/meet/[slug]",
+                "/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

@@ -181,6 +181,33 @@ export declare const ROUTE_DEPENDENCIES: Readonly<Record<string, readonly string
 export declare const ROUTE_MESSAGE_NAMESPACES: Readonly<Record<string, readonly string[]>>;
 /** Template-relative path of the generated site-nav registry. */
 export declare const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
+/**
+ * Verify a rendered nav's self-hashing stamp (#6908 D1/F1–F2): `"valid"` when
+ * the first line's hash matches every byte after it, `"invalid"` when a
+ * stamp line is present but the hash fails (an edited, still-stamped nav),
+ * `"absent"` when there is no stamp line at all. A stamp that verifies proves
+ * the file unedited whatever generator wrote it — the check needs only the
+ * file, never the generator's code.
+ */
+export declare function readNavConfigStamp(text: string): "valid" | "invalid" | "absent";
+/**
+ * Every byte after a nav's stamp line, or `text` unchanged when it carries
+ * none. The one place the D1 stamp-line shape is matched outside
+ * `readNavConfigStamp` itself, so a test simulating an edit below the stamp
+ * (or a bare pre-D1 body) never re-derives `NAV_STAMP_RE`'s pattern by hand.
+ */
+export declare function stripNavConfigStamp(text: string): string;
+/** Options for `renderNavConfig` (#6878 D6). */
+export interface RenderNavConfigOptions {
+    /**
+     * Service page slugs — the basenames, minus `.mdx`, of a site's
+     * `content/en/Service/*.mdx` — for the Services flyout column on a
+     * service shape. Sorted, then cut to the first three. Absent/empty →
+     * the offering column emits no Services links even when the `services`
+     * surface is on (there is nothing to link yet).
+     */
+    serviceSlugs?: readonly string[];
+}
 /**
  * Render `apps/web/lib/nav-config.ts` for an enabled surface set.
  *
@@ -191,14 +218,19 @@ export declare const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
  * surface set for the same reason the route tree does.
  *
  * 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
- * 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.
+ * chrome diff recorded on that card, re-pointed by #6658 D8, then by #6878 D6):
+ * ONE flyout rule for every shape — an offering column (Features on product
+ * shapes, Services on service shapes) beside a Customers column linking the
+ * /for persona pages — then Blog, Pricing and About. `/blog` is always linked
+ * (the teaser or the docs-blog module serves it). Pricing and every other
+ * gateable surface: 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. Portfolio is never a flyout link (D6): on a
+ * service shape it is a plain top-level link directly after the Services
+ * flyout, and every shape's footer Site pages column links it (#6895), both
+ * under the `portfolio` surface's gate. No empty flyout is ever emitted: with
+ * neither column non-empty, no flyout item is emitted at all (closes #6766's
+ * AC-1).
  *
  * Only gateable surfaces carrying a `navLabelKey` are linked after the base
  * items, because a nav entry needs a translated label. Emitting an entry whose
@@ -212,4 +244,4 @@ export declare const NAV_CONFIG_PATH = "apps/web/lib/nav-config.ts";
  * Deterministic: gateable entries follow GATEABLE_SURFACES order (alphabetical
  * by id), after the fixed base items.
  */
-export declare function renderNavConfig(enabled: string[]): string;
+export declare function renderNavConfig(enabled: string[], options?: RenderNavConfigOptions): string;