create-ailk 0.22.0 → 0.24.0

package/templates/apps/api/src/services/project-listings.ts

@@ -176,6 +176,14 @@ export function deriveListingSlug(name: string): string {
  */
 const SLUG_COLLISION_SCAN_LIMIT = 200;
 
+/**
+ * The most active rows the anonymous page-render read returns (#9243). No
+ * consumer in this repo names a shelf size, so the bound is the one the other
+ * anonymous listing read already carries — the directory's
+ * `LISTING_DIRECTORY_MAX_ENTRIES` — rather than a second number to keep in step.
+ */
+const PUBLIC_LISTINGS_MAX_ROWS = LISTING_DIRECTORY_MAX_ENTRIES;
+
 /**
  * The first free slug for `base` on this site. Uniqueness is already scoped
  * `@@unique([siteId, slug])`, so the suffix is too: a second "Atlas" on this
@@ -412,10 +420,10 @@ function toResponseRow(
  * Since #5036 D6d the listing stores the experiment's KEY rather than its id,
  * and that key is the same string `WaitlistScore.experimentKey` holds — so the
  * `WaitlistExperiment` read that existed purely to translate one into the
- * other is gone. One `WaitlistScore.count` per DISTINCT key remains, bounded
- * by the small number of distinct experiments a dashboard page carries rather
- * than by row count (`waitlist-dashboard.ts`'s "one read across every returned
- * row" discipline).
+ * other is gone. ONE `WaitlistScore.groupBy` over every DISTINCT key remains
+ * (#9243): one read across every returned row (`waitlist-dashboard.ts`'s
+ * discipline), however many experiments the page carries — the per-key
+ * `count()` fan-out this replaced ran on the anonymous public read.
  */
 async function attachWaitlistCounts(
   siteId: string,
@@ -426,29 +434,28 @@ async function attachWaitlistCounts(
   ];
   if (experimentKeys.length === 0) return new Map();
 
-  const counts = new Map<string, number>();
-  await Promise.all(
-    experimentKeys.map(async (experimentKey) => {
-      // fence: workspaceId === the scope id this query already filters siteId by
-      // (workspace_site_agree CHECK, 20260922120000_tenancy_fence). Filtering the
-      // CONSTRAINED column makes the scope correct by construction; the format
-      // CHECK makes a raw alias match nothing rather than by accident.
-      //
-      // What that id IS depends on the caller, and only two of the six are
-      // route-resolved: `listProjectListings` and `getProjectListing` receive
-      // `tenant.workspaceId`, so for them this is an isolation control.
-      // `listMyProjectListings` and the two `publicProjectListings` call sites
-      // pass a ProjectListing row's OWN `siteId`, so for them it is a
-      // CONSISTENCY control — the count agrees with the row it is reported
-      // against — exactly as `project-listing-decision.ts#waitlistCountFor`
-      // spells out (#6258 § 1.6 / § 5 D8, security review L-2).
-      const count = await prisma.waitlistScore.count({
-        where: { siteId, workspaceId: siteId, experimentKey },
-      });
-      counts.set(experimentKey, count);
-    }),
-  );
-  return counts;
+  // fence: workspaceId === the scope id this query already filters siteId by
+  // (workspace_site_agree CHECK, 20260922120000_tenancy_fence). Filtering the
+  // CONSTRAINED column makes the scope correct by construction; the format
+  // CHECK makes a raw alias match nothing rather than by accident.
+  //
+  // What that id IS depends on the caller, and only two of the six are
+  // route-resolved: `listProjectListings` and `getProjectListing` receive
+  // `tenant.workspaceId`, so for them this is an isolation control.
+  // `listMyProjectListings` and the two `publicProjectListings` call sites
+  // pass a ProjectListing row's OWN `siteId`, so for them it is a
+  // CONSISTENCY control — the count agrees with the row it is reported
+  // against — exactly as `project-listing-decision.ts#waitlistCountFor`
+  // spells out (#6258 § 1.6 / § 5 D8, security review L-2).
+  //
+  // A key with no score rows is absent from a GROUP BY result; `waitlistCountFor`
+  // reads it as 0, the same value the per-key `count()` produced.
+  const grouped = await prisma.waitlistScore.groupBy({
+    by: ["experimentKey"],
+    where: { siteId, workspaceId: siteId, experimentKey: { in: experimentKeys } },
+    _count: { _all: true },
+  });
+  return new Map(grouped.map((g) => [g.experimentKey, g._count._all]));
 }
 
 function waitlistCountFor(
@@ -1902,10 +1909,10 @@ function orderPublicListings<T extends { row: { id: string; decidedAt: Date | nu
 }
 
 /**
- * The page-render read (#4998 AC4, reshaped by #5033): every `active` row for
- * the site, the THREE newest by `decidedAt` first, then the rest by
- * `waitlistCount` desc, then `decidedAt` desc. `founderEmail` never leaves
- * this function.
+ * The page-render read (#4998 AC4, reshaped by #5033, bounded by #9243): the
+ * newest-decided `PUBLIC_LISTINGS_MAX_ROWS` `active` rows for the site, the
+ * THREE newest by `decidedAt` first, then the rest by `waitlistCount` desc,
+ * then `decidedAt` desc. `founderEmail` never leaves this function.
  *
  * Rows whose window has elapsed are returned and read `closed` — computed,
  * per row, against one instant, with no job having run. They are not filtered
@@ -1917,6 +1924,11 @@ export async function publicProjectListings(siteId: string): Promise<ProjectList
   const listingConfig = await listingConfigFor(siteId);
   const rows = await prisma.projectListing.findMany({
     where: { siteId, status: "active" },
+    // Same window as the directory read: with a `take`, the rows kept must be
+    // chosen, and "newest decided first, NULLS LAST" is the order the public
+    // shelf leads with anyway.
+    orderBy: [{ decidedAt: { sort: "desc", nulls: "last" } }, { id: "asc" }],
+    take: PUBLIC_LISTINGS_MAX_ROWS,
     select: PROJECT_LISTING_SELECT,
   });
   const counts = await attachWaitlistCounts(siteId, rows);

package/templates/apps/api/src/services/public-site-resolver.ts

@@ -62,13 +62,16 @@
  * prefix — and never reaches the wire.
  *
  * THE FLOWS ROUTES' WORKSPACE (#7844 D1). `resolveCallerWorkspace` below is
- * the one function the five `/v1/flows` routes resolve their workspace with:
- * a spoke resolves to its own workspace (`viaSpoke: true`), a keyless call to
- * the `AILK_SITE_ID` alias exactly as before, and anything else to
- * `unresolved` with one of two reasons, `spoke-refused` or `alias-unresolved`.
- * The reasons are for `request.log` only; the routes answer both the same
- * way. It lives here rather than under `routes/flows/` because the two flows
- * route files sit in different module slices, and this file is base tree.
+ * the one function the five `/v1/flows` routes (and the open deliverable)
+ * resolve their workspace with: a spoke resolves to its own workspace
+ * (`viaSpoke: true`), a keyless call through branch 2's one-workspace
+ * predicate (#9145 — never the `AILK_SITE_ID` alias, so every anonymous
+ * route answers the same workspace for the same deployment), and anything
+ * else to `unresolved` with one of two reasons, `spoke-refused` or
+ * `ambiguous`. The reasons are for `request.log` only; the routes answer both
+ * the same way. It lives here rather than under `routes/flows/` because the
+ * two flows route files sit in different module slices, and this file is
+ * base tree.
  */
 import {
   resolvedAdapterKind,
@@ -253,13 +256,15 @@ export type CallerWorkspace =
       /** #8771 D3 — set exactly when `viaSpoke` is true: the registered spoke's id. */
       spokeId?: string;
     }
-  | { kind: "unresolved"; reason: "spoke-refused" | "alias-unresolved" };
+  | { kind: "unresolved"; reason: "spoke-refused" | "ambiguous" };
 
 /**
  * Resolve the workspace a `/v1/flows` request serves. A spoke resolves to its
- * own workspace; a keyless call to the `AILK_SITE_ID` alias, exactly as the
- * flows routes did before #7844; a refused caller to nothing. There is no
- * fallback: a spoke never reaches the alias workspace (D5).
+ * own workspace; a keyless call through `resolveDefaultWorkspaceId`, the
+ * predicate `resolvePublicWorkspace` uses (#9145) — on any content adapter,
+ * since a flow is a database row whatever serves the pages; a refused caller
+ * to nothing. There is no fallback: a spoke never reaches the default
+ * workspace (D5).
  *
  * Calls `resolveCallerSite` with no options, so a failed hub-status read on a
  * keyless call rejects (#7844 C1).
@@ -280,10 +285,10 @@ export async function resolveCallerWorkspace(
     };
   }
   // Deferred, like every database import in this file.
-  const { resolveSiteWorkspaceId } = await import("../lib/site.js");
-  const workspaceId = await resolveSiteWorkspaceId();
+  const { resolveDefaultWorkspaceId } = await import("./default-tenant.js");
+  const workspaceId = await resolveDefaultWorkspaceId();
   return workspaceId === null
-    ? { kind: "unresolved", reason: "alias-unresolved" }
+    ? { kind: "unresolved", reason: "ambiguous" }
     : { kind: "resolved", workspaceId, viaSpoke: false };
 }
 

package/templates/apps/mcp/CLAUDE.md

@@ -43,8 +43,10 @@ Inherits root `CLAUDE.md`. This file adds MCP-specific rules.
   name points straight at the Vercel project; a second proxy in front keys every caller on
   that proxy. It is a function, not `trustProxy: 1`, because Fastify 5.12 treats a numeric
   hop count as trusting nothing. The long-running entry trusts no proxy.
-- **Per address, per instance.** 60 requests a minute across reads and writes (the write rate
-  is parsed but not enforced); `capture_lead` 50 a day, `start_purchase` 20 a day,
+- **Per address, per instance.** 60 requests a minute across every request
+  (`MCP_RATE_LIMIT_READ_PER_MIN`), plus a tighter 10 a minute on the six anonymous write tools
+  (`MCP_RATE_LIMIT_WRITE_PER_MIN`, #9251), refused with the same 429 shape; `capture_lead` 50 a
+  day, `start_purchase` 20 a day,
   `create_booking` 20 a day and `submit_flow_step` 50 a day, each on its own budget.
   `subscribe_newsletter` and `request_callback` have no daily cap. Each warm instance counts
   on its own and a cold start resets the counts, so a caller reaching N instances gets up to
@@ -73,36 +75,36 @@ Every tool maps 1:1 to an `apps/api` endpoint. When you change a tool, change th
 
 **The HTTP write branch (6).** `WRITE_TOOLS` in `src/http-transport.ts` — `capture_lead`, `subscribe_newsletter`, `request_callback`, `start_purchase`, `create_booking`, `submit_flow_step` — takes the write-origin allow-list and the AbuseGuard (UA, honeypot, email format, per-IP daily cap); every other tool takes the read branch (UA only). A tool that sends caller-chosen data to the hub belongs in it: `__tests__/write-tool-guard.test.ts` fails when a catalog tool that sends a non-GET request through `@working-theory/api-client` is missing, and makes every new catalog tool pick a branch (#8071).
 
-**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`
+**Read (9):** `list_pages`, `read_content`, `search_content`, `get_site_info`, `get_business_hours`, `get_locations`, `get_offerings`, `get_pricing`, `get_faq`. The first three adopted their `apps/api` routes' arguments and results (#7167, #7168, #7169 — the operator's decision of 2026-10-19): `search_content` takes `q` and answers the route's `ItemList` (`query`, `items`, `totalItems`); `list_pages` requires `type`, takes `page`/`pageSize` and answers the paginated `ItemList` (`items`, `pagination`); `read_content` takes `include` and answers the page's JSON-LD at the root with `page`, plus `body` only with `include: "body"` — a miss is the not-found body. Each parses the same `@working-theory/validation` export its route parses with and answers through the same `@working-theory/content-adapters` builder, so the parity guard holds them as `twin`s
+**Conversion-write (3):** `capture_lead`, `subscribe_newsletter`, `request_callback` — each takes the body its `POST /v1/leads/{submit,subscribe,callback}` route parses (`leadSubmitBodySchema`: `source`, `email`, `consent`, `payload`; `leadSubscribeBodySchema`: `email`, `source`; `leadCallbackBodySchema`: `name`, `phone`, `preferredTime`, `payload`) and returns the route's 201 body `{ id, persisted, email }` unchanged (#7171, #7172, #7173 — the operator's decision of 2026-10-19), so the parity guard holds the three as `twin`s. `source` is the agent's to choose — `mcp` unless the operator says otherwise — and a consent-bearing source needs `consent: true`, exactly as a form does; `capture_lead` still spreads the spoke marker `payload.site` from `AILK_LEAD_SITE` last. The AbuseGuard reads the first two's `email` at the top level, else inside `payload` (the route lifts it from there), so a malformed address is refused wherever it sits
 **Maintenance (2):** `audit`, `create_project`
 **Flow (2):** `get_flow`, `submit_flow_step` — module-gated (`module: "signal-collectors"`, D-48, #5366) and licence-feature-tagged (`feature: "flows-deliverables"`, #7136): identity-blind like every tool in this list, registered only when the signal-collectors module is present, and gated on the deployment's `flows-deliverables` licence feature under `MCP_FEATURE_GATE_MODE`, the same shape Booking below has. `submit_flow_step` takes the HTTP write branch (its own daily cap, `MCP_ABUSE_SUBMIT_FLOW_STEP_DAILY_CAP`, default 50 — #8071)
-**Booking (3):** `list_availability`, `get_event_meta`, `create_booking` — module-gated (`module: "scheduling"`) and licence-feature-tagged (`feature: "scheduling"`, #7136), gated on the deployment's `scheduling` licence feature under `MCP_FEATURE_GATE_MODE`. `create_booking` takes the HTTP write branch (its own daily cap, `MCP_ABUSE_CREATE_BOOKING_DAILY_CAP`, default 20, and an `attendee.email` format check — #8071)
+**Booking (4):** `list_availability`, `get_event_meta`, `list_meetings`, `create_booking` — module-gated (`module: "scheduling"`) and licence-feature-tagged (`feature: "scheduling"`, #7136), gated on the deployment's `scheduling` licence feature under `MCP_FEATURE_GATE_MODE`. `create_booking` takes the HTTP write branch (its own daily cap, `MCP_ABUSE_CREATE_BOOKING_DAILY_CAP`, default 20, and an `attendee.email` format check — #8071). `list_meetings` (#8843 D5) twins `GET /v1/schedule/meetings`: it takes no argument and returns the site's Live meetings — slug, visibility, position and whether each can be booked, plus a bookable one's calLink, title, length, description and price; `private` means unlisted, not secret
 
-### Why the parity test counts 20 and a keyless server registers 19
+### Why the parity test counts 21 and a keyless server registers 20
 
-- **20 in the `TOOLS` array / parity test**: the `TOOLS` array in
-  `packages/metadata/src/mcp-tool-catalog.ts` defines 20 anonymous tools; the
-  parity test counts that full array. It also holds the fifteen signed-in
+- **21 in the `TOOLS` array / parity test**: the `TOOLS` array in
+  `packages/metadata/src/mcp-tool-catalog.ts` defines 21 anonymous tools; the
+  parity test counts that full array. It also holds the eighteen signed-in
   workspace tools (#3591), which no anonymous view returns — see § The
   signed-in workspace surface below.
-- **19 registered on a KEYLESS deployment, 20 on a commerce-claimed one**
+- **20 registered on a KEYLESS deployment, 21 on a commerce-claimed one**
   (#5971): `createMcpServer` (`apps/mcp/src/server.ts`) registers
   `getMcpToolRegistrations()` minus `OSS_DISABLED_TOOLS` (now empty), minus
   module-gated tools whose module is off, minus any `addon`-tagged tool whose
   claim this deployment does not hold. `start_purchase` carries
   `addon: "commerce"`, so it is the one entry whose presence depends on the
-  licence — 19 without the claim, 20 with it.
-- **19 free anonymous tools**: since #5853 retired the three content-write
+  licence — 20 without the claim, 21 with it.
+- **20 free anonymous tools**: since #5853 retired the three content-write
   tools, every registered tool remains anonymous — call-time gating checks a
-  licence claim, never an identity. The five carrying `tier: "pro"`
+  licence claim, never an identity. The six carrying `tier: "pro"`
   (`get_flow`, `submit_flow_step`, `list_availability`, `get_event_meta`,
-  `create_booking`) are gated at REGISTRATION **and at call time** (#7315):
+  `list_meetings`, `create_booking`) are gated at REGISTRATION **and at call time** (#7315):
   each needs its module, and each catalog row names the licence `feature:`
   that entitles it. `start_purchase` is gated at call time by both this
   server-wide gate and its own Gate 2 in `tools/purchase.ts`.
   `MCP_FEATURE_GATE_MODE` (`packages/metadata`) decides what an unheld
-  feature does. In `"warn"` mode (this release) the five register on module
+  feature does. In `"warn"` mode (this release) the six register on module
   presence alone, and the boot (`bootMcp()`) logs one warning (stderr) per tool
   served without its feature. In `"refuse"` mode (the next release) they
   also need the deployment's licence to hold the feature, and
@@ -126,10 +128,14 @@ here. Spec: `docs/specs/3591-tenant-scoped-agent-auth-secure-spec.md` D13–D16.
 - **apps/mcp checks only the key's shape.** The key is attached as the SDK's `req.auth` for that
   request alone and reaches a tool as `extra.authInfo.token`. apps/api is the one place it is
   checked, and its tenant guard and the caller's clamped role decide every answer.
-- **Fifteen tools, each a `twin`.** The catalog rows carry `surface: "workspace"`, `tier: "pro"`
+- **Eighteen tools, each a `twin`.** The catalog rows carry `surface: "workspace"`, `tier: "pro"`
   and `modulesAnyOf` (the modules any one of which registers the tool — its twin route's gate):
   `get_agent_context`, the four message tools, the three submission tools, the three
-  application tools and (#8514) the two People notes tools, `get_person_notes` and
+  listing application tools (#9137: `list_listing_applications`, `get_listing_application`,
+  `decide_listing_application` — a `ProjectListing` row, never a job application, which is a Job
+  application magnet's submission; the pre-rename `list_inbox_applications`,
+  `get_inbox_application` and `decide_inbox_application` stay registered for one release as
+  deprecated aliases of the same handlers, each description opening `Deprecated: use …`) and (#8514) the two People notes tools, `get_person_notes` and
   `set_person_notes` — the team's private note on one client, which an agent reads and writes
   only with the `member-pieces-manage` grant; `set_person_notes` requires the `ifUpdatedAt` it
   read and is refused `notes_changed` when someone saved since — and (#8516) the two proposals
@@ -219,7 +225,15 @@ Example (lead routing):
 - Don't add a tool without the matching `apps/api` endpoint.
 - Don't put business logic in tool handlers — they're adapters.
 
-Last updated: 2026-10-14 — #8516: the signed-in workspace surface is fifteen tools — `list_proposals` and `create_proposal` (`tools/proposals.ts`) twin `GET`/`POST /v1/workspaces/:workspaceId/people/:personId/proposals` — verified against `packages/metadata/src/mcp-tool-catalog.ts`, `apps/mcp/src/workspace-server.ts` and `tests/parity/api-parity/kinds/site.ts`.
+Last updated: 2026-10-20 — #7171, #7172, #7173: the three lead writes adopted their routes' bodies and 201 results and are parity `twin`s — the Conversion-write line records the adopted shapes — verified against `apps/mcp/src/tools/{capture_lead,subscribe_newsletter,request_callback}.ts`, `packages/validation/src/schemas/leads.ts` and `tests/parity/api-parity/kinds/site.ts`.
+
+Prior: 2026-10-20 — #7167, #7168, #7169: the three content reads adopted their routes' arguments and results and are parity `twin`s — the Read line records the adopted shapes — verified against `apps/mcp/src/tools/{search_content,list_pages,read_content}.ts`, `packages/validation/src/schemas/content-reads.ts`, `packages/content-adapters/src/content-reads.ts` and `tests/parity/api-parity/kinds/site.ts`.
+
+Prior: 2026-10-18 — #9137: the three listing application tools are `list_listing_applications`, `get_listing_application` and `decide_listing_application`, and their pre-rename names stay one release as deprecated aliases — the signed-in workspace surface is eighteen tools — verified against `packages/metadata/src/mcp-tool-catalog.ts`, `apps/mcp/src/workspace-server.ts` and `tests/parity/api-parity/kinds/site.ts`.
+
+Prior: 2026-10-18 — #8843 PR A: `list_meetings` twins `GET /v1/schedule/meetings` — Booking is four tools, the counts are 21 in TOOLS, 20 registered keyless and 21 commerce-claimed, and six tools carry `tier: "pro"` — verified against `packages/metadata/src/mcp-tool-catalog.ts`, `apps/mcp/src/server.ts` and `tests/parity/api-parity/kinds/site.ts`.
+
+Prior: 2026-10-14 — #8516: the signed-in workspace surface is fifteen tools — `list_proposals` and `create_proposal` (`tools/proposals.ts`) twin `GET`/`POST /v1/workspaces/:workspaceId/people/:personId/proposals` — verified against `packages/metadata/src/mcp-tool-catalog.ts`, `apps/mcp/src/workspace-server.ts` and `tests/parity/api-parity/kinds/site.ts`.
 
 Prior: 2026-10-13 — #8514: the signed-in workspace surface is thirteen tools — `get_person_notes` and `set_person_notes` (`tools/person_notes.ts`) twin `GET`/`PUT /v1/workspaces/:workspaceId/people/:personId/notes` — verified against `packages/metadata/src/mcp-tool-catalog.ts`, `apps/mcp/src/workspace-server.ts` and `tests/parity/api-parity/kinds/site.ts`.
 

package/templates/apps/mcp/__tests__/app-entry.test.ts

@@ -134,9 +134,9 @@ function captureLead(id: number, name: string): object {
     params: {
       name: "capture_lead",
       arguments: {
-        name,
+        source: "mcp",
         email: `${name.toLowerCase()}@example.com`,
-        message: "Interested in your services.",
+        payload: { name, message: "Interested in your services." },
       },
     },
   };

package/templates/apps/mcp/__tests__/catalog-drift.test.ts

@@ -105,9 +105,14 @@ type GateMode = NonNullable<McpCatalogOptions["featureGate"]>;
 
 type McpFeature = NonNullable<McpToolCatalogEntry["feature"]>;
 
-/** The five licence-feature tools, by the feature that entitles them. */
+/** The six licence-feature tools, by the feature that entitles them. */
 const FEATURE_TOOLS: Record<McpFeature, readonly string[]> = {
-  scheduling: ["list_availability", "get_event_meta", "create_booking"],
+  scheduling: [
+    "list_availability",
+    "get_event_meta",
+    "list_meetings",
+    "create_booking",
+  ],
   "flows-deliverables": ["get_flow", "submit_flow_step"],
 };
 
@@ -318,14 +323,14 @@ describe.each([
       const bootNames = Object.keys(
         registeredToolsOf(createMcpServer()),
       ).sort();
-      // Both counts below are of the served catalog — the full catalog (20 at
+      // Both counts below are of the served catalog — the full catalog (21 at
       // boot, 14 after the re-read) minus this seam's UNSERVED_MCP_TOOLS (#8665).
       expect(bootNames).toEqual(
         servedCatalog(bootOptions)
           .map((t) => t.name)
           .sort(),
       );
-      expect(bootNames).toHaveLength(20 - UNSERVED_MCP_TOOLS.length);
+      expect(bootNames).toHaveLength(21 - UNSERVED_MCP_TOOLS.length);
 
       startMcpClaimRefresh({ checkLicense: resolving({ features: [] }) });
       await jest.advanceTimersByTimeAsync(MCP_CLAIM_REFRESH_MS);