create-ailk 0.4.0 → 0.5.0

package/templates/apps/api/src/services/lead-promotion.ts

@@ -0,0 +1,161 @@
+/**
+ * @file lead-promotion.ts
+ * @description Lead → user promotion across the inbox/auth namespace boundary
+ * (ADR 0009 D3 service-layer pattern; spec
+ * docs/specs/3586-lead-user-promotion-spec.md).
+ *
+ * Reconciles an anonymous inbox.Lead with an auth.User by stable email, once
+ * the reconciling user's own email is verified (D2 — the consent basis for
+ * linking anonymous-lead PII to a user) and only within that user's own
+ * tenant workspaces (D3 — the tenant-safety invariant). Workspace resolution
+ * is delegated to `owner-workspaces.ts` — the one site→workspace resolution in
+ * this app, which in turn delegates to the sole cross-namespace tenancy
+ * assembler — so this file never issues a raw membership or workspace model
+ * query of its own (architecture.yaml's tenant-scope forbidden pattern
+ * reserves those to the tenant-context / tenant-db modules).
+ *
+ * Mirrors lead-routing.ts's shape: discriminated `{ ok } | { ok: false, error }`
+ * result, no throw on the expected (no-op) paths, PII-safe (never logs email /
+ * payload / name / phone).
+ */
+
+import type { Id } from "@working-theory/ids";
+
+import { prisma } from "../lib/prisma.js";
+
+import { resolveOwnerWorkspaces } from "./owner-workspaces.js";
+
+/**
+ * Workspace resolution moved to `owner-workspaces.ts` (#5678) so the leads
+ * READ path can share it rather than write a second one. The module-
+ * conditional slice load, the zero-workspace semantics and the delegation to
+ * the tenancy assembler are unchanged — this file simply calls it now.
+ *
+ * It had to be a separate module rather than an export from here:
+ * `paidModuleTemplateExclusions()` drops every file that reaches a paid
+ * module's `ownedFiles` through the import graph, this file is inside that
+ * closure, and importing it from the leads read would have carried the
+ * closure all the way into `server.ts`. See `owner-workspaces.ts`'s own
+ * header.
+ *
+ * Semantics on a build without the multi-tenant module, CORRECTED by #5677
+ * and carried across the move. `services/default-tenant.ts` now resolves the
+ * seeded default Workspace on every build, so a module-less deployment DOES
+ * have a resolvable workspace — the shared resolver's empty result there is a
+ * deliberate scope limit, not a statement that there is nothing to resolve.
+ *
+ * PROMOTION specifically is not wired to that default resolution, and that is
+ * #5677's own disposition rather than an oversight of this move: single-tenant
+ * leads would start acquiring `promotedUserId`, which is what
+ * `/v1/flow-checkouts/me` and `/v1/waitlist-signups/me` join a respondent's own
+ * rows through — a respondent's `/account` would begin showing purchases where
+ * it shows none today. It also needs the deployment to pin `AILK_SITE_ID` to
+ * `DEFAULT_WORKSPACE_ID`, because `siteId` comes from `lib/site.ts`
+ * (`AILK_SITE_ID ?? "default"`) while `workspaceId` is the sentinel, and
+ * `siteId ∈ workspaceIds` only matches when those agree.
+ */
+
+// ─── Types ────────────────────────────────────────────────────────────────────
+
+export type PromotedLead = {
+  leadId: string;
+  siteId: string;
+  source: string;
+};
+
+export type PromoteLeadsResult =
+  | { ok: true; count: number; promoted: PromotedLead[] }
+  | {
+      ok: false;
+      error: { kind: "user_not_found" | "internal_error"; message: string };
+    };
+
+// ─── Main export ──────────────────────────────────────────────────────────────
+
+/**
+ * Promote every un-promoted `inbox.Lead` matching the verifying user's own
+ * email, within that user's own tenant workspaces (D1/D3). No-ops
+ * (`count: 0`) — never throws — when: the user's email is unverified (D2),
+ * the user belongs to no workspace, or no matching un-promoted lead exists.
+ * Idempotent: a lead already carrying `promotedUserId` is excluded from the
+ * match set, so re-invocation promotes nothing (AC-6).
+ */
+export async function promoteLeadsForVerifiedUser(params: {
+  userId: string;
+}): Promise<PromoteLeadsResult> {
+  const { userId } = params;
+
+  try {
+    const user = await prisma.user.findUnique({
+      where: { id: userId },
+      select: { id: true, email: true, emailVerified: true },
+    });
+
+    if (!user) {
+      return {
+        ok: false,
+        error: { kind: "user_not_found", message: "User not found" },
+      };
+    }
+
+    // D2 — the verified-email gate is a service-level invariant, not a
+    // caller obligation: it cannot be bypassed by a wrong call-site.
+    if (!user.emailVerified) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    // D3/D4 — resolve the verifying user's OWN workspaces through the one
+    // shared resolution (`owner-workspaces.ts`). Role-agnostic here:
+    // promotion links a lead to the person whose verified email it carries,
+    // in any workspace they belong to, exactly as it did before the move.
+    // Without the multi-tenant module the shared resolver yields nothing and
+    // the early return below fires — a scope limit since #5677, not an
+    // absence of anything to resolve; see the header.
+    const workspaces = await resolveOwnerWorkspaces(user.id as Id<"user">);
+    if (!workspaces.ok) {
+      return {
+        ok: false,
+        error: { kind: "internal_error", message: workspaces.error.message },
+      };
+    }
+    const workspaceIds = workspaces.value.map((workspace) => workspace.id);
+
+    if (workspaceIds.length === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    // D3/AC-4 (tenant-safety — load-bearing): the match set is siteId ∈ the
+    // user's OWN workspaceIds, so a lead captured under a different
+    // organization's workspace is never matched, by construction.
+    const candidates = await prisma.lead.findMany({
+      where: {
+        email: user.email,
+        siteId: { in: workspaceIds },
+        promotedUserId: null,
+      },
+      select: { id: true, siteId: true, source: true },
+    });
+
+    if (candidates.length === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    await prisma.lead.updateMany({
+      where: { id: { in: candidates.map((lead) => lead.id) } },
+      data: { promotedUserId: user.id, promotedAt: new Date() },
+    });
+
+    return {
+      ok: true,
+      count: candidates.length,
+      promoted: candidates.map((lead) => ({
+        leadId: lead.id,
+        siteId: lead.siteId,
+        source: lead.source,
+      })),
+    };
+  } catch (err) {
+    const message = err instanceof Error ? err.message : String(err);
+    return { ok: false, error: { kind: "internal_error", message } };
+  }
+}

package/templates/apps/api/src/services/leads-inbox.ts

@@ -0,0 +1,263 @@
+/**
+ * @file leads-inbox.ts
+ * @description The owner-side READ over captured leads (#5678) — the other
+ * half of `lead-routing.ts`, which only ever wrote them.
+ *
+ * Scope is resolved server-side and never supplied by the caller: the reader's
+ * identity is `request.userId`, their workspaces come from
+ * `owner-workspaces.ts`'s `resolveOwnerWorkspaces` — the ONE site→workspace
+ * resolution in this app, shared with `lead-promotion.ts` — and every query
+ * filters `siteId ∈ workspaceIds`.
+ * There is no site/org parameter to widen, so cross-tenant enumeration is
+ * structurally impossible rather than merely checked — the same posture
+ * `routes/waitlist-experiments/list.ts` takes.
+ *
+ * The scope is the UNION of every workspace the caller owns or administers,
+ * across every organization they belong to — not one active tenant, the way
+ * `waitlist-dashboard.ts` scopes to `tenant.workspaceId`. That difference is
+ * deliberate and structural: this route registers outside the tenant scope
+ * (it must work on a build with no multi-tenant module), so there is no
+ * active tenant to scope to. `Membership` is an organization-level grant, so
+ * the union stays inside what the caller may already see. When a workspace
+ * switcher reaches this surface, it is the thing that will narrow it.
+ *
+ * ## What it takes for this to return anything
+ *
+ * Two preconditions, neither of which this file can assert:
+ *
+ *   1. `resolveOwnerWorkspaces` must yield a workspace. On a build with no
+ *      `multi-tenant` module it yields none — see its own header, and #5677,
+ *      which made that a deliberate scope limit rather than a statement that
+ *      there is nothing to resolve.
+ *   2. The `siteId` the leads were WRITTEN under must equal a workspace id,
+ *      and there are TWO independent sources of it — both must agree with the
+ *      workspace, and neither is `currentSiteId()` on the primary path:
+ *
+ *        - The three POST capture routes take `siteId` from the REQUEST BODY
+ *          (`routes/leads/index.ts`), which the capture sections declare in
+ *          content and default to `"default"` (`ContactForm`, `Newsletter`,
+ *          `StepFlow` — `ext.siteId ?? "default"`). Neither
+ *          `routes/leads/index.ts` nor `lead-routing.ts` calls
+ *          `currentSiteId()` at all.
+ *        - The recommender's capture path (`routes/flows/recommender.ts`) is
+ *          the one that DOES use `currentSiteId()` (`lib/site.ts`,
+ *          `AILK_SITE_ID ?? "default"`).
+ *
+ *      A workspace id is `wksp_<uuidv7>`, so `siteId ∈ workspaceIds` only
+ *      matches when the content-declared value — and, for recommender leads,
+ *      `AILK_SITE_ID` — is set to it. This is the same convention
+ *      `waitlist-dashboard.ts` already relies on ("owner scope =
+ *      `siteId == tenant.workspaceId`"); it is a deployment and content fact,
+ *      not something either resolver can supply. Naming only `AILK_SITE_ID`
+ *      here would send an operator to the wrong knob for every contact-form,
+ *      newsletter and callback lead (PR #5705 security re-review, finding A).
+ *
+ * Both failures are EMPTY, never wide: the inbox shows no leads rather than
+ * someone else's. Raised by the PR #5705 security review, finding 2.
+ *
+ * PII boundary: this service returns lead PII by design, so it returns the
+ * NARROWEST row the inbox view renders — `id`, `name`, `email`, `source`,
+ * `createdAt` — and nothing else. `payload`'s remaining free-form keys
+ * (message, phone, and whatever else a site's form declares), `siteId`,
+ * `promotedUserId` and `promotedAt` are never selected out of the row that
+ * leaves this file, and the one value lifted out of `payload` is truncated
+ * (see `MAX_NAME_LENGTH`). Logs carry no lead field at all.
+ */
+
+import type { Prisma } from "@working-theory/database";
+import type { Id } from "@working-theory/ids";
+
+import { prisma } from "../lib/prisma.js";
+
+import { resolveOwnerWorkspaces } from "./owner-workspaces.js";
+
+// ─── Types ────────────────────────────────────────────────────────────────────
+
+/** One row of the inbox — exactly the five values the table renders. */
+export type LeadInboxRow = {
+  /** The lead id: the row key, and the cursor for the page after this one. */
+  id: string;
+  /**
+   * The contact's name, lifted from `payload.name` when the site's form
+   * captured one. `null` otherwise — `payload` is a free-form record
+   * (`boundedLeadPayload`), so a site whose form declares no name field has
+   * none to show.
+   */
+  name: string | null;
+  email: string;
+  /** Which capture produced the lead (`"web"`, `"conversational-intake"`, …). */
+  source: string;
+  /** ISO 8601. */
+  createdAt: string;
+};
+
+export type LeadInboxPage = {
+  items: LeadInboxRow[];
+  /** The `cursor` for the next page, or `null` when this is the last one. */
+  nextCursor: string | null;
+};
+
+export type ListLeadsErrorKind = "invalid_cursor" | "internal_error";
+export type ListLeadsResult =
+  | { ok: true; value: LeadInboxPage }
+  | { ok: false; error: { kind: ListLeadsErrorKind; message: string } };
+
+/**
+ * Reads require `owner` or `admin` in the organization the workspace belongs
+ * to — the inbox exposes contact PII, so membership alone is not
+ * authorization. Same floor, and the same reason, as
+ * `WAITLIST_DASHBOARD_ROLES` (`waitlist-dashboard.ts`); declared here rather
+ * than imported because that file is a `signal-collectors` slice the strip
+ * removes and this one ships at every level.
+ */
+const LEAD_INBOX_ROLES: ReadonlySet<string> = new Set(["owner", "admin"]);
+
+/**
+ * The ONLY columns read out of the Lead table on this path.
+ *
+ * `payload` is here because Prisma cannot `select` a JSON sub-path and
+ * `name` lives inside it — so the whole blob crosses the DB→API boundary for
+ * each of the `limit + 1` rows and is narrowed in this process, not by the
+ * query. Nothing but `payload.name` leaves this file (see `readName`), but the
+ * READ is the full record: the memory cost of a page is `(limit + 1) ×
+ * payload size`, independent of what is returned. Bounded above by Fastify's
+ * 1 MiB body limit on the write side and by `MAX_LIMIT` on this one.
+ */
+const LEAD_INBOX_SELECT = {
+  id: true,
+  email: true,
+  source: true,
+  payload: true,
+  createdAt: true,
+} as const satisfies Prisma.LeadSelect;
+
+// ─── Row shaping ──────────────────────────────────────────────────────────────
+
+/**
+ * The rendered `name` is truncated to this many characters. The write side
+ * bounds `payload` at 64 KEYS and nothing else (`boundedLeadPayload`,
+ * `packages/validation/src/schemas/leads.ts`) — no per-value length — so a
+ * `name` arrives with only Fastify's 1 MiB body limit above it, while every
+ * other rendered field is bounded at the schema (`email` 254, `source` 64).
+ *
+ * That gap is reachable by an anonymous caller: `siteId` is content-declared
+ * and shipped to the browser by the capture forms, `POST /v1/leads/submit`
+ * performs no ownership check on it, and the leads-scope rate limit keys on
+ * `req.ip` under instance-wide `trustProxy` (which `routes/leads/index.ts`
+ * documents as attacker-influenceable). Fifty-one ~900 KB names would
+ * otherwise be a ~45 MB response — and, because the order is `createdAt desc`
+ * and this PR ships no delete surface, permanently page one. Truncating here
+ * is what makes the inbox's size a function of the page size rather than of
+ * what a stranger typed. Raised by the PR #5705 security review, finding 1.
+ *
+ * 200 is the same order of magnitude as `callbackSchema`'s own declared
+ * `name` bound (128) with room for a long real one. Bounding `payload`'s
+ * string VALUES at the write boundary would fix this for every future reader,
+ * but that changes what the three POST routes accept, which this issue's
+ * scope fence forbids — so the bound lives on the read.
+ */
+const MAX_NAME_LENGTH = 200;
+
+/**
+ * `payload` is JSON of a shape the site's own form decides, so reading one
+ * key out of it is a boundary read: anything that is not a string is `null`,
+ * and a string is truncated (see `MAX_NAME_LENGTH`).
+ */
+function readName(payload: Prisma.JsonValue): string | null {
+  if (typeof payload !== "object" || payload === null || Array.isArray(payload)) {
+    return null;
+  }
+  const name = (payload as Record<string, unknown>)["name"];
+  return typeof name === "string" ? name.slice(0, MAX_NAME_LENGTH) : null;
+}
+
+// ─── Main export ──────────────────────────────────────────────────────────────
+
+/**
+ * List the leads the caller's own sites captured, newest first.
+ *
+ * Pagination is the cursor shape `waitlist-experiments/signups` already
+ * established in this codebase: `(createdAt desc, id desc)`, `take: limit + 1`
+ * to decide `hasMore`, and a `cursor` that is the previous page's last row id.
+ * A supplied cursor that does not resolve WITHIN the caller's scope is a
+ * client input error (`invalid_cursor` → 400), never a silent fall back to
+ * page 1 at THIS layer — the web inbox re-reads page one when a URL-supplied
+ * cursor 400s, which is its own rendering choice and leaves this contract
+ * intact (a foreign cursor and a nonexistent one stay indistinguishable
+ * either way) — and never a probe that distinguishes "another site's lead" from
+ * "no such lead", because the scope filter runs on the cursor lookup too.
+ */
+export async function listOwnedLeads(params: {
+  userId: Id<"user">;
+  cursor?: string | undefined;
+  limit: number;
+}): Promise<ListLeadsResult> {
+  const workspaces = await resolveOwnerWorkspaces(params.userId);
+  if (!workspaces.ok) {
+    return {
+      ok: false,
+      error: { kind: "internal_error", message: workspaces.error.message },
+    };
+  }
+
+  const siteIds = workspaces.value
+    .filter((workspace) => LEAD_INBOX_ROLES.has(workspace.role))
+    .map((workspace) => workspace.id);
+
+  // No workspace the caller owns or administers means no lead can match, so
+  // there is nothing to query. An empty page is the honest answer — the same
+  // zero-workspace no-op the promotion path returns.
+  if (siteIds.length === 0) return { ok: true, value: { items: [], nextCursor: null } };
+
+  let cursorLead: { createdAt: Date; id: string } | undefined;
+  if (params.cursor) {
+    cursorLead =
+      (await prisma.lead.findFirst({
+        where: { id: params.cursor, siteId: { in: siteIds } },
+        select: { id: true, createdAt: true },
+      })) ?? undefined;
+    if (!cursorLead) {
+      return {
+        ok: false,
+        error: {
+          kind: "invalid_cursor",
+          message: "cursor does not resolve within this scope",
+        },
+      };
+    }
+  }
+
+  const rows = await prisma.lead.findMany({
+    where: {
+      siteId: { in: siteIds },
+      ...(cursorLead
+        ? {
+            OR: [
+              { createdAt: { lt: cursorLead.createdAt } },
+              { createdAt: cursorLead.createdAt, id: { lt: cursorLead.id } },
+            ],
+          }
+        : {}),
+    },
+    orderBy: [{ createdAt: "desc" }, { id: "desc" }],
+    take: params.limit + 1,
+    select: LEAD_INBOX_SELECT,
+  });
+
+  const hasMore = rows.length > params.limit;
+  const page = hasMore ? rows.slice(0, params.limit) : rows;
+
+  return {
+    ok: true,
+    value: {
+      items: page.map((lead) => ({
+        id: lead.id,
+        name: readName(lead.payload),
+        email: lead.email,
+        source: lead.source,
+        createdAt: lead.createdAt.toISOString(),
+      })),
+      nextCursor: hasMore ? (page[page.length - 1]?.id ?? null) : null,
+    },
+  };
+}

package/templates/apps/api/src/services/owner-workspaces.ts

@@ -0,0 +1,132 @@
+/**
+ * @file owner-workspaces.ts
+ * @description The ONE site→workspace resolution in `apps/api`.
+ *
+ * A `Lead` is keyed on `siteId` and a `Workspace` on `id`, but the two are the
+ * SAME value space named per namespace — `database/config/schema.prisma` says
+ * as much of `ProjectListing`, "the one keyed on `siteId` rather than
+ * `workspaceId`". So ownership is the direct membership test
+ * `siteId ∈ workspaceIds`, never a join through a mapping table, and every
+ * caller that needs it resolves it here rather than writing a second path: a
+ * divergent isolation path across two PII surfaces is exactly the thing that
+ * turns into rework when the multi-tenant product arrives.
+ *
+ * Callers: `lead-promotion.ts` (lead → user promotion, #3586) and
+ * `leads-inbox.ts` (the owner's leads read, #5678).
+ *
+ * ## Why this is its own file rather than a `lead-promotion.ts` export
+ *
+ * `paidModuleTemplateExclusions()` (`packages/create-ailk/src/module-architecture.ts`)
+ * walks the import graph from each paid module's `ownedFiles` to a fixed point
+ * and drops every file that reaches one, so that a keyless scaffold carries no
+ * paid source. `lead-promotion.ts` is inside that closure and always has been,
+ * which means anything importing it is dropped too. Putting this function
+ * there and importing it from the leads read would have carried the closure
+ * through `leads-inbox.ts` and `routes/leads/list.ts` into `server.ts`, and a
+ * scaffold with no server entry point does not build — the same base-breaking
+ * cascade `module-architecture.ts` records twice in its own comments, measured
+ * here before this file existed. Keeping the resolution in a module that
+ * reaches nothing excluded is what lets both callers share it.
+ *
+ * Nothing in this file may name `tenant-context.js` in an import form,
+ * including inside a comment: the closure's scanner is a regular expression
+ * over the file's text and does not know which lines are code.
+ */
+
+import type { Id } from "@working-theory/ids";
+
+import { isModuleEnabled } from "../config/modules.js";
+import { loadSlice } from "../lib/slice-load.js";
+
+/**
+ * The tenant-context module is a multi-tenant SLICE the OSS strip removes
+ * (#5182), and `listTenancy` is a VALUE — a runtime call, not an erasable type
+ * — so a static import, or a specifier written literally at the call site,
+ * would be TS2307 on the public tree: `tsc` resolves a string-literal
+ * specifier whether or not the branch containing it can ever run.
+ *
+ * The remedy is the one `server.ts` and `lead-promotion.ts` already use: gate
+ * the call on `isModuleEnabled('multi-tenant')` and read the specifier from
+ * this constant, so it is not a literal at the call site. What defeats
+ * resolution is the INDIRECTION, not the type of the value. The constant form
+ * matters too — `@vercel/nft` constant-propagates a module-level binding into
+ * the dynamic call and emits the file, which a table lookup would hide from it
+ * (#5304 D3).
+ *
+ * `apps/api` is a `tsc`-only surface with no bundler, which is the
+ * precondition that makes this sound here.
+ */
+const TENANT_CONTEXT_SPECIFIER = "./tenant-context.js";
+
+/** The one export this file needs from the multi-tenant slice. */
+interface TenantContextSlice {
+  listTenancy: (params: {
+    userId: Id<"user">;
+    sessionTenant: undefined;
+  }) => Promise<
+    | {
+        ok: true;
+        value: {
+          organizations: Array<{
+            role: string;
+            workspaces: Array<{ id: string }>;
+          }>;
+        };
+      }
+    | { ok: false; error: { message: string } }
+  >;
+}
+
+/**
+ * One workspace the caller belongs to, carrying the role they hold in its
+ * organization. `role` is the organization-level `Membership.role`
+ * (`owner | admin | member`) the tenancy assembler already returns — typed as a
+ * plain string here rather than `MembershipRole`, because that type lives in
+ * the stripped slice this file may not name.
+ */
+export type OwnerWorkspace = { id: string; role: string };
+
+export type ResolveOwnerWorkspacesResult =
+  | { ok: true; value: OwnerWorkspace[] }
+  | { ok: false; error: { message: string } };
+
+/**
+ * Resolve the caller's OWN workspaces.
+ *
+ * Delegates to the sole cross-namespace tenancy assembler — this file never
+ * issues a raw membership or workspace model query of its own, which
+ * `architecture.yaml`'s tenant-scope forbidden pattern reserves to the
+ * tenant-context and tenant-db modules.
+ *
+ * Module-conditional, and #5677 changed what that MEANS rather than what it
+ * does. `services/default-tenant.ts` now resolves the seeded default
+ * Workspace on every build, so a module-less deployment does have a
+ * resolvable workspace — the empty result below is a deliberate scope limit,
+ * not a statement that there is nothing to resolve. Wiring this resolver to
+ * that default is a behavior change for BOTH callers at once (promotion would
+ * begin stamping `promotedUserId` on single-tenant leads, which
+ * `/v1/flow-checkouts/me` and `/v1/waitlist-signups/me` join through), and it
+ * needs the deployment to pin `AILK_SITE_ID` to `DEFAULT_WORKSPACE_ID` —
+ * `siteId` comes from `lib/site.ts` while `workspaceId` is the sentinel, and
+ * `siteId ∈ workspaceIds` only matches when those agree.
+ */
+export async function resolveOwnerWorkspaces(
+  userId: Id<"user">,
+): Promise<ResolveOwnerWorkspacesResult> {
+  if (!isModuleEnabled("multi-tenant")) return { ok: true, value: [] };
+
+  const specifier: string = TENANT_CONTEXT_SPECIFIER;
+  const { listTenancy } = (await loadSlice(
+    specifier,
+    () => import(specifier),
+  )) as TenantContextSlice;
+  const tenancy = await listTenancy({ userId, sessionTenant: undefined });
+  if (!tenancy.ok) return { ok: false, error: tenancy.error };
+
+  return {
+    ok: true,
+    value: tenancy.value.organizations.flatMap((org) =>
+      org.workspaces.map((workspace) => ({ id: workspace.id, role: org.role })),
+    ),
+  };
+}

package/templates/apps/mcp/CLAUDE.md

@@ -24,7 +24,7 @@ Every tool maps 1:1 to an `apps/api` endpoint. When you change a tool, change th
 
 **Read (9):** `list_pages`, `read_content`, `search_content`, `get_site_info`, `get_business_hours`, `get_locations`, `get_offerings`, `get_pricing`, `get_faq`
 **Conversion-write (3):** `capture_lead`, `subscribe_newsletter`, `request_callback`
-**Maintenance (2):** `audit`, `scaffold`
+**Maintenance (2):** `audit`, `create_project`
 **Flow (2):** `get_flow`, `submit_flow_step` — module-gated (`module: "signal-collectors"`, D-48, #5366): identity-blind and free of any `requirePaidTier()` call like every tool in this list, but registered only when the signal-collectors module is present, the same shape Booking below already has
 **Booking (3):** `list_availability`, `get_event_meta`, `create_booking` — module-gated (`module: "scheduling"`)
 

package/templates/apps/mcp/__tests__/parity.test.ts

@@ -105,7 +105,7 @@ const MCP_ONLY_TOOLS = new Set([
   "ailkAudit", // audit — AEO scoring tool, no web action equivalent (I5; ADR 0013)
   "ailkSubscribeNewsletter", // subscribe_newsletter — anonymous write via MCP; no Server Action (B7)
   "ailkRequestCallback", // request_callback — anonymous write via MCP; no Server Action (B7)
-  "ailkScaffold", // scaffold — agent-only scaffolder; no Server Action equivalent (#299)
+  "ailkCreateProject", // create_project — agent-only project creator; no Server Action equivalent (#299)
   "ailkCreatePage", // create_page — agent-first Pro content write; HTTP twin is apps/api, not a Server Action (D14a #55)
   "ailkUpdatePage", // update_page — agent-first Pro content write; HTTP twin is apps/api, not a Server Action (D14a #55)
   "ailkDeletePage", // delete_page — agent-first Pro content write; HTTP twin is apps/api, not a Server Action (D14a #55)
@@ -246,7 +246,7 @@ describe("MCP ↔ Server-Action parity (filesystem)", () => {
     // - ailkAudit: MCP-only (AEO scoring; I5; in MCP_ONLY_TOOLS allow-list).
     // - ailkSubscribeNewsletter, ailkRequestCallback:
     //   MCP-only anonymous-write tools (B7; in MCP_ONLY_TOOLS allow-list).
-    // - ailkScaffold: MCP-only agent scaffolder (#299; in MCP_ONLY_TOOLS).
+    // - ailkCreateProject: MCP-only agent project creator (#299; in MCP_ONLY_TOOLS).
     // - ailkCreatePage, ailkUpdatePage, ailkDeletePage: MCP-only agent-first
     //   Pro content writes; HTTP twin is apps/api, not Server Actions (D14a #55).
     // - ailkGetFlow: MCP-only agent-callable flow-engine read; HTTP twin is