create-ailk 0.24.0 → 0.25.1

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

@@ -1,312 +0,0 @@
-/**
- * @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 whose organization grants the
- * caller `inbox-read` (the permission table in `@working-theory/validation`,
- * #7636 D2 — every role, a member included), 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. The caller's scope must resolve to a workspace. With the
- *      `multi-tenant` module that is `resolveOwnerWorkspaces`. Without it
- *      (#6730 D7) — Free and Pro — that resolver yields none by design (its
- *      own header, #5677), so the scope is instead the default workspace,
- *      granted ONLY through `resolveDefaultTenantForOperator`
- *      (`default-tenant.ts`): `AILK_OPERATOR_EMAIL` set, the caller's
- *      VERIFIED email equal to it, and the deployment unambiguously
- *      one-workspace. Any other caller gets the empty page, never a wider one.
- *   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 { can } from "@working-theory/validation";
-
-import { isModuleEnabled } from "../config/modules.js";
-import { prisma } from "../lib/prisma.js";
-
-import { resolveDefaultTenantForOperator } from "./default-tenant.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 } };
-
-/**
- * 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`).
- *
- * Exported so `inbox-messages.ts` reuses this exact narrowing — never a copy
- * (see that file's header for why the shaping stays here).
- */
-export 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;
-}
-
-// ─── Scope ────────────────────────────────────────────────────────────────────
-
-/**
- * The workspace ids whose leads the caller may read. With `multi-tenant`,
- * every workspace they own or administer (`resolveOwnerWorkspaces`,
- * unchanged). Without it (#6730 D7), the default workspace — only for the
- * pinned, verified operator on a one-workspace deployment; `null` from the
- * resolver means no scope at all.
- */
-async function resolveInboxSiteIds(
-  userId: Id<"user">,
-): Promise<{ ok: true; siteIds: string[] } | { ok: false; message: string }> {
-  if (!isModuleEnabled("multi-tenant")) {
-    try {
-      const tenant = await resolveDefaultTenantForOperator(userId);
-      return {
-        ok: true,
-        siteIds: tenant && can(tenant.role, "inbox-read") ? [tenant.workspaceId] : [],
-      };
-    } catch (err) {
-      return { ok: false, message: err instanceof Error ? err.message : String(err) };
-    }
-  }
-
-  const workspaces = await resolveOwnerWorkspaces(userId);
-  if (!workspaces.ok) return { ok: false, message: workspaces.error.message };
-  return {
-    ok: true,
-    siteIds: workspaces.value
-      .filter((workspace) => can(workspace.role, "inbox-read"))
-      .map((workspace) => workspace.id),
-  };
-}
-
-// ─── 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 scope = await resolveInboxSiteIds(params.userId);
-  if (!scope.ok) {
-    return {
-      ok: false,
-      error: { kind: "internal_error", message: scope.message },
-    };
-  }
-  const siteIds = scope.siteIds;
-
-  // 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,
-    },
-  };
-}
-
-// #6204's `listUnhandledMessages` / `markMessageHandled` — the tenant-scoped
-// "Needs-you" read/write pair over `tenantDb(tenant).leads` — moved OFF this
-// file to `./inbox-messages.js`. This file is a BASE-tier file every scaffold
-// ships (this header's own claim); `tenantDb` (`../lib/tenant-db.js`) is a
-// `multi-tenant`-slice file, and the paid-module exclusion closure
-// (`packages/create-ailk/src/lib/import-graph.ts`) is backward — a base file
-// that imports a paid seed is ITSELF added to the exclusion set, and so is
-// everything that imports IT. Importing `tenantDb` from here once already
-// pulled `server.ts`/`cli.ts`/`index.ts`/`vercel-handler.ts` out of a keyless
-// scaffold (caught by `__tests__/paid-module-exclusions.test.ts`, #5678's own
-// cascade recurring a third time). `readName()` above
-// stays here (exported) and `inbox-messages.ts` imports it — the row shape is
-// the SAME function, never a copy. The role floor is the `inbox-read` row of
-// the permission table (`@working-theory/validation`, #7636 D2), which a
-// package import reaches without dragging this base file into a slice.

package/templates/apps/api/src/services/listing-config.ts

@@ -1,178 +0,0 @@
-/**
- * NOT marked `oss: false` (D-48/#5366 escalation — see
- * `routes/project-listings/me.ts`'s header comment): imported by
- * `routes/project-listings/{start,public}.ts`, each of which ships
- * unconditionally because `routes/project-listings/index.ts`'s multi-tenant
- * literal `import()` forces it. Registration stays gated.
- *
- * @file listing-config.ts
- * @description The per-site project-listings config read (#5033) — one
- * function, `listingConfigFor`, that resolves a site's window bounds and
- * featured switch.
- *
- * This is the whole reason the surface is a platform feature rather than one
- * site's: the ninety-day maximum window and twenty-one-day default that used
- * to be `BACKLINK_DAYS = 90` in `project-listing-decision.ts` were
- * salessmyth/samhenry's commercial terms compiled into the published package.
- * They are configuration now.
- *
- * The read is SERVER-SIDE ONLY. No route accepts any of these values from a
- * request body — the apply payload carries a *requested* window and the
- * server clamps it (`clampWindowDays`). A founder who could post their own
- * bound could post an unbounded one.
- *
- * A site with no `SiteListingConfig` row gets `SITE_LISTING_CONFIG_DEFAULTS`,
- * the schema's own conservative defaults — deliberately not any site's terms.
- *
- * A row whose stored blob fails the schema gets the same defaults rather than
- * throwing: an anonymous application must not 500 because an operator saved a
- * malformed config. That fallback is the one direction in which this read can
- * end up MORE permissive than the operator wrote, which is why
- * `siteListingConfigSchema` clamps the operator mistakes it can (a default
- * that no longer fits under a tightened maximum) instead of rejecting them,
- * and why this logs at ERROR: reaching here means a site is running on
- * platform terms rather than its own, and someone needs to know.
- */
-
-import { logger } from "@working-theory/observability";
-import {
-  siteListingConfigSchema,
-  SITE_LISTING_CONFIG_DEFAULTS,
-  type SiteListingConfig,
-} from "@working-theory/validation";
-
-import { prisma } from "../lib/prisma.js";
-import { resolveSiteWorkspaceId } from "../lib/site.js";
-
-export async function listingConfigFor(siteId: string): Promise<SiteListingConfig> {
-  // #6257 — every caller hands this function an ALREADY-RESOLVED workspace id
-  // (a `ProjectListing` row's own `siteId`, an authenticated tenant's
-  // `workspaceId`, or `siteIdForPublicKey`'s return below), so `workspaceId`
-  // rides beside the unique `siteId` selector rather than being resolved a
-  // second time. `site_listing_configs_workspace_site_agree` makes the pair
-  // redundant by construction — which is the point: the tenant scope is now
-  // something the QUERY states, not something the caller is trusted to have.
-  const row = await prisma.siteListingConfig.findUnique({
-    where: { siteId, workspaceId: siteId },
-    select: { data: true },
-  });
-  if (!row) return SITE_LISTING_CONFIG_DEFAULTS;
-
-  const parsed = siteListingConfigSchema.safeParse(row.data);
-  if (!parsed.success) {
-    logger.error(
-      { siteId, issues: parsed.error.issues },
-      "[listing-config] stored config failed its schema — this site is running on PLATFORM defaults, not its own terms",
-    );
-    return SITE_LISTING_CONFIG_DEFAULTS;
-  }
-  warnOnDroppedField(siteId, row.data, parsed.data);
-  return parsed.data;
-}
-
-/**
- * The two `.catch(undefined)` members of `siteListingConfigSchema` are silent
- * by construction (#5406): a malformed `resumeEmail` or `siteName` is DROPPED
- * rather than failing the whole blob, so the site keeps its own window bounds
- * and collected fields instead of silently reverting to the platform's more
- * permissive defaults.
- *
- * Silent is the right BEHAVIOUR and the wrong OBSERVABILITY. An operator who
- * typos a subject key gets a site that quietly stops sending the resume email
- * with nothing anywhere saying why. This closes that: when the stored blob has
- * the key and the parsed config does not, the drop is logged.
- *
- * Field NAMES only, never values — `resumeEmail` carries the site's addresses
- * and the founder-facing copy, and this module sits on the anonymous path.
- */
-function warnOnDroppedField(
-  siteId: string,
-  stored: unknown,
-  parsed: SiteListingConfig,
-): void {
-  if (typeof stored !== "object" || stored === null) return;
-  const raw = stored as Record<string, unknown>;
-  for (const field of ["resumeEmail", "siteName"] as const) {
-    if (raw[field] !== undefined && parsed[field] === undefined) {
-      logger.warn(
-        { siteId, field },
-        "[listing-config] stored field failed its schema and was DROPPED — the rest of this site's config still applies, but this field is not in effect",
-      );
-    }
-  }
-
-  // `resumeEmail.maxSendsPerHour` carries its OWN `.catch(undefined)` (#5414),
-  // so a bad cap is dropped while the block around it survives — which the
-  // loop above, comparing whole members, cannot see. Checked only when the
-  // block itself parsed: a dropped block is already reported once above, and
-  // reporting it twice would make the narrower line the less trustworthy one.
-  const storedEmail = raw["resumeEmail"];
-  if (
-    typeof storedEmail === "object" &&
-    storedEmail !== null &&
-    (storedEmail as Record<string, unknown>)["maxSendsPerHour"] !== undefined &&
-    parsed.resumeEmail !== undefined &&
-    parsed.resumeEmail.maxSendsPerHour === undefined
-  ) {
-    logger.warn(
-      { siteId, field: "resumeEmail.maxSendsPerHour" },
-      "[listing-config] stored field failed its schema and was DROPPED — the rest of this site's config still applies, but this field is not in effect",
-    );
-  }
-}
-
-/**
- * Resolve a site from its PUBLIC SITE KEY (#5048 D2).
- *
- * This is the function that lets the consuming site's proxy route go away. The
- * anonymous application names its site with a public key; the server maps that
- * key to a `siteId` HERE, so no request body ever carries a tenant identifier
- * and no site has to stand up a route whose only job is to append one.
- *
- * The key is not a credential. It ships in browser JavaScript and in an agent's
- * request by design (#5039 keeps that channel open), and holding it grants
- * nothing beyond the ability to open a draft the holder must then complete.
- * Treating it as a secret would buy nothing and would break both callers.
- *
- * Two resolution paths, in order:
- *
- *   1. A `SiteListingConfig` row whose `publicKey` matches. This is the
- *      multi-tenant path and the only one that can name a site other than the
- *      deployment's own.
- *   2. `AILK_LISTING_PUBLIC_KEY`, matched against the env, resolving to the
- *      RESOLVED workspace id for `currentSiteId()` (#6254 AC-6/AC-10 —
- *      `resolveSiteWorkspaceId()`, not the raw alias: `project_listings`
- *      now rejects a `site_id` that disagrees with `workspace_id`,
- *      database/migrations/20260922120000_tenancy_fence). This is the
- *      SINGLE-TENANT path: the default `create-ailk` scaffold is one
- *      customer per deployment and has no config row, so requiring one
- *      would mean a site could not accept an application until an operator
- *      wrote a database row.
- *
- * An unmatched key resolves to `null` and the route answers 400. It does NOT
- * fall through to the env path: a typo would otherwise silently file one
- * site's applications against another.
- *
- * The env comparison is a plain `===` on an opaque public identifier — there is
- * no secret here to leak through a timing difference, and pretending otherwise
- * would imply a guarantee this value does not carry.
- */
-export async function siteIdForPublicKey(publicKey: string): Promise<string | null> {
-  // fence: global-key — `SiteListingConfig.publicKey`, a site's own public
-  // listing key, unique across every workspace. This is the query that
-  // RESOLVES the tenant: it is handed nothing but the key, and a workspace
-  // term here would have to come from the very answer it is computing. The
-  // key is not a credential (it ships in browser JavaScript by design, #5039)
-  // and holding it grants only the ability to open a draft; an unmatched key
-  // returns `null` and the route answers 400 rather than falling through.
-  const row = await prisma.siteListingConfig.findUnique({
-    where: { publicKey },
-    select: { siteId: true },
-  });
-  if (row) return row.siteId;
-
-  const envKey = process.env["AILK_LISTING_PUBLIC_KEY"];
-  if (envKey && envKey === publicKey) return resolveSiteWorkspaceId();
-
-  return null;
-}