create-ailk 0.4.0 → 0.6.0

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

@@ -10,6 +10,18 @@
  *
  * PII boundary: only { siteId, kind, ip, persisted, emailKind } appear in logs.
  * Never log email, phone, name, or payload values.
+ *
+ * TENANCY (#6203). `input.siteId` is the caller's RESOLVED workspace id —
+ * `routes/leads/index.ts` resolves it server-side before calling `routeLead`
+ * and never a client-supplied value (see that file's header). `Lead` gets a
+ * `workspaceId` stamp of the same value, and since #6374 so do `Subscriber`
+ * and `Callback` — both gained a required `workspaceId` column in the fence
+ * fan-out, stamped from the same resolved id by the three `create` sites
+ * below. (This line previously said those two models had no such column;
+ * that stopped being true when the keystone migration landed, and the code
+ * under it already contradicted it.) The one READ in this file — the
+ * duplicate-subscriber lookup on the P2002 arm — is scoped by it too
+ * (#6257).
  */
 
 import { randomUUID } from "node:crypto";
@@ -23,6 +35,7 @@ import { appendLeadRecord } from "../lib/lead-capture-store.js";
 import { prisma } from "../lib/prisma.js";
 
 import { enrichLead } from "./enrichment-shim.js";
+import { requestConfirmSupersedesNotification } from "./request-confirm.js";
 
 // ─── Types ────────────────────────────────────────────────────────────────────
 
@@ -103,6 +116,23 @@ async function persistToDb(input: RouteLeadInput): Promise<PersistResult> {
     const row = (await prisma.lead.create({
       data: {
         siteId: input.siteId,
+        // #6203/#6254 — the isolation key, equal to `siteId` by
+        // construction. `input.siteId` is the RESOLVED workspace id at
+        // EVERY `routeLead(kind: "submit")` caller now — the primary route
+        // (`routes/leads/index.ts`, never reads it from the body — see that
+        // file's header) and the three service-layer callers
+        // (`flow-engine.ts`'s `completeSubmission`,
+        // `recommender-capture.ts`'s `captureRecommenderChoice`,
+        // `project-listings.ts`'s `submitProjectListingDraft`) all resolve
+        // the site alias before calling in (#6254 AC-6/AC-10). `workspaceId`
+        // is NOT NULL as of
+        // database/migrations/20260922120000_tenancy_fence, so this can no
+        // longer stamp `null` for an unresolved alias the way it once did
+        // (spec D2's old rule) — a caller that somehow still passed one
+        // would instead hit the pre-existing `<table>_workspace_id_format`
+        // CHECK loudly, via the AC-11 re-raise below, rather than landing a
+        // silently-unfenced row.
+        workspaceId: input.siteId,
         source: input.source,
         email: input.email,
         payload: input.payload as Prisma.InputJsonValue,
@@ -117,6 +147,13 @@ async function persistToDb(input: RouteLeadInput): Promise<PersistResult> {
       const row = (await prisma.subscriber.create({
         data: {
           siteId: input.siteId,
+          // #6374 — the isolation key, equal to `siteId` by construction,
+          // exactly as `lead.create` above stamps it. `input.siteId` is the
+          // RESOLVED workspace id at every `routeLead` caller (see the
+          // `submit` branch's own note); a caller that somehow passed a raw
+          // alias would hit `subscribers_workspace_id_format` loudly rather
+          // than landing a silently-unfenced row. Never from a request body.
+          workspaceId: input.siteId,
           email: input.email,
           source: input.source,
         },
@@ -131,8 +168,15 @@ async function persistToDb(input: RouteLeadInput): Promise<PersistResult> {
         "code" in err &&
         (err as { code: string }).code === "P2002"
       ) {
+        // #6257 — the duplicate lookup is scoped by the same resolved
+        // workspace id the `create` above stamps (`input.siteId` is the
+        // RESOLVED id at every caller — see the `submit` branch's note), so a
+        // P2002 on another tenant's row can never resolve to its id.
         const existing = (await prisma.subscriber.findUnique({
-          where: { siteId_email: { siteId: input.siteId, email: input.email } },
+          where: {
+            siteId_email: { siteId: input.siteId, email: input.email },
+            workspaceId: input.siteId,
+          },
           select: { id: true },
         })) as DbRow | null;
         const existingId = existing?.id ?? "duplicate-no-id";
@@ -152,6 +196,10 @@ async function persistToDb(input: RouteLeadInput): Promise<PersistResult> {
   const row = (await prisma.callback.create({
     data: {
       siteId: input.siteId,
+      // #6374 — the isolation key, equal to `siteId` by construction; same
+      // resolution guarantee and same loud-failure posture as the two
+      // branches above. Never from a request body (AC-6).
+      workspaceId: input.siteId,
       name: input.name,
       phone: input.phone,
       ...(input.preferredTime !== undefined && {
@@ -164,6 +212,56 @@ async function persistToDb(input: RouteLeadInput): Promise<PersistResult> {
   return { ok: true, id: row.id, source: "db", skipEmail: false };
 }
 
+// ─── Constraint-violation detection (#6254 AC-11) ──────────────────────────────
+
+/**
+ * SQLSTATE class 23 — "integrity constraint violation" — covers a NOT NULL
+ * (23502), a CHECK (23514), a unique (23505) or a foreign-key (23503)
+ * violation. Two of Prisma's own mapped codes correspond to a class-23
+ * violation on a `.create()` call: P2002 (unique) and P2011 (null
+ * constraint) — both `PrismaClientKnownRequestError`s Prisma classifies
+ * from its OWN schema knowledge. The new `<table>_workspace_site_agree`
+ * CHECK (database/migrations/20260922120000_tenancy_fence) has no such
+ * schema-level representation — Prisma cannot classify a raw CHECK it does
+ * not know about, so the raw Postgres SQLSTATE is read defensively from
+ * wherever the error actually carries it: `error.meta.code` (some engine/
+ * adapter combinations thread it through there) or the error message text
+ * (every Postgres client library's message includes the SQLSTATE and/or the
+ * words "constraint"/"null value" verbatim).
+ */
+// P2000 (value too long) is deliberately excluded — a data-length validation
+// error, not a SQLSTATE class-23 integrity-constraint violation (security
+// review finding, PR #6360): it doesn't correspond to 23502/23503/23505/
+// 23514, so treating it as one would take this path for a case AC-11 does
+// not target.
+const PRISMA_CLASS_23_CODES = new Set(["P2002", "P2003", "P2004", "P2011"]);
+
+function isConstraintViolation(error: unknown): boolean {
+  if (error == null || typeof error !== "object") return false;
+
+  const code = (error as { code?: unknown }).code;
+  if (typeof code === "string" && PRISMA_CLASS_23_CODES.has(code)) return true;
+
+  const metaCode = (error as { meta?: { code?: unknown } }).meta?.code;
+  if (typeof metaCode === "string" && /^23\d{3}$/.test(metaCode)) return true;
+
+  const message = (error as { message?: unknown }).message;
+  if (typeof message === "string") {
+    // Labeled SQLSTATE only — "code: '23514'", "(SQLSTATE 23502)", etc. A
+    // bare `\b23\d{3}\b` anywhere in the message (security review finding,
+    // PR #6360) would also match a coincidental 5-digit number in a genuine
+    // outage's own text (a port, a byte count, a timeout in ms), stealing
+    // that case away from the file fallback it should still take.
+    if (/\b(?:sqlstate|code)[:\s]*['"]?23\d{3}['"]?/i.test(message)) return true;
+    if (/violates (check|not-null|unique|foreign key) constraint/i.test(message)) {
+      return true;
+    }
+    if (/null value in column/i.test(message)) return true;
+  }
+
+  return false;
+}
+
 // ─── Email ────────────────────────────────────────────────────────────────────
 
 type EmailResult =
@@ -174,7 +272,38 @@ type EmailResult =
 async function sendEmail(
   input: RouteLeadInput,
   id: string,
+  persisted: "db" | "file",
 ): Promise<EmailResult> {
+  // Request-and-confirm SUPERSEDES this notification for a callback (#5970
+  // D6). AC-1 requires the tenant to receive exactly one email, and the
+  // confirm message carries strictly more than this one does — the same
+  // request details, plus the link that confirms a time and a price. Sending
+  // both would be two; sending this one and not that one would lose the
+  // feature. `submit` and `subscribe` are untouched.
+  //
+  // The predicate lives in request-confirm.ts and is read by both sides, so
+  // the two cannot both fire. It does NOT by itself rule out zero — see that
+  // function's header for what the coupling does and does not guarantee, and
+  // for the `persisted` term below, which is what closed the one zero case
+  // that was reachable in production. With the feature unconfigured — the
+  // default, and what every existing leads suite runs under — this is false
+  // and every byte below is reached as before.
+  // `persisted === "db"` is load-bearing, not decoration (#5970 security
+  // review round 3, M1). The confirm message can only supersede this one if it
+  // is actually going to be sent, and it can only be sent against a ROW: the
+  // credential is minted by an `updateMany` on `callbacks`. On the FILE
+  // FALLBACK path — a DB outage, an unset DATABASE_URL, an exhausted pool —
+  // there is no row, so suppressing here would have produced ZERO operator
+  // emails for every callback captured during the outage, on the one surface
+  // whose whole purpose is that an outage must not lose a lead.
+  if (
+    input.kind === "callback" &&
+    persisted === "db" &&
+    requestConfirmSupersedesNotification()
+  ) {
+    return { skipped: true, reason: "request_confirm" };
+  }
+
   const to = process.env.AILK_LEAD_NOTIFICATION_TO;
   const from = process.env.AILK_LEAD_NOTIFICATION_FROM;
 
@@ -265,6 +394,36 @@ export async function routeLead(
     skipEmail = dbResult.skipEmail;
     skipReason = dbResult.skipReason;
   } catch (dbErr) {
+    // #6254 AC-11 (spec D6, SEC-02) — a constraint violation is OUR OWN
+    // derivation producing a row Postgres itself refuses (an unresolved
+    // workspaceId hitting NOT NULL, or a site<->workspace disagreement
+    // hitting the new equality CHECK) — a bug to surface, never an outage
+    // to degrade through. Falling back here would return a silent 201 while
+    // the Lead never lands in Postgres, invisible to the Inbox forever —
+    // the exact silent data loss AC-7 exists to close, merely relocated
+    // onto this never-gate surface.
+    //
+    // A DELIBERATE error response, not a bare re-raise (spec § 7's
+    // api-versioning waiver is conditioned on exactly this: "a documented
+    // error body, never a bare re-raise surfacing as an unhandled throw").
+    // `persist_failed` already maps to a 503 with a documented body
+    // (`routes/leads/index.ts`) — the SAME shape a genuine DB-outage
+    // failure (both DB and file fail) already returns, so this adds no new
+    // response shape, only a new path that reaches the existing one
+    // WITHOUT first trying — and losing time to — a file write for an
+    // error the file fallback can never fix.
+    //
+    // A GENUINE infrastructure failure (an unreachable DB, an exhausted
+    // pool, an unset DATABASE_URL) is NOT a constraint violation and still
+    // takes the file fallback below, unchanged.
+    if (isConstraintViolation(dbErr)) {
+      const dbMsg = dbErr instanceof Error ? dbErr.message : String(dbErr);
+      return {
+        ok: false,
+        error: { kind: "persist_failed", message: `db: ${dbMsg}` },
+      };
+    }
+
     // 5. File fallback
     // Include a UUID suffix so concurrent fallbacks produce unique IDs even
     // within the same millisecond. Format still matches /^[a-z0-9_-]{8,64}$/i.
@@ -331,7 +490,7 @@ export async function routeLead(
   if (skipEmail) {
     emailResult = { skipped: true, reason: skipReason ?? "skipped" };
   } else {
-    emailResult = await sendEmail(input, id!);
+    emailResult = await sendEmail(input, id!, persisted!);
   }
 
   return { ok: true, id: id!, persisted, email: emailResult };

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

@@ -0,0 +1,284 @@
+/**
+ * @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.
+ *
+ * Exported so `inbox-messages.ts` (#6204's tenant-scoped read/write, moved
+ * off this base file's own dependency edge — see that file's header) enforces
+ * the SAME floor rather than a copy.
+ */
+export 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`).
+ *
+ * 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;
+}
+
+// ─── 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,
+    },
+  };
+}
+
+// #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()` and `LEAD_INBOX_ROLES` above
+// stay here (both exported) and `inbox-messages.ts` imports them — the row
+// shape and the role floor are the SAME constants, never a copy.

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

@@ -42,11 +42,18 @@ import {
 } from "@working-theory/validation";
 
 import { prisma } from "../lib/prisma.js";
-import { currentSiteId } from "../lib/site.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 },
+    where: { siteId, workspaceId: siteId },
     select: { data: true },
   });
   if (!row) return SITE_LISTING_CONFIG_DEFAULTS;
@@ -132,14 +139,18 @@ function warnOnDroppedField(
  *   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
- *      `currentSiteId()`. 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.
+ *   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 `currentSiteId()`: a typo would otherwise silently file one
+ * 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
@@ -147,6 +158,13 @@ function warnOnDroppedField(
  * 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 },
@@ -154,7 +172,7 @@ export async function siteIdForPublicKey(publicKey: string): Promise<string | nu
   if (row) return row.siteId;
 
   const envKey = process.env["AILK_LISTING_PUBLIC_KEY"];
-  if (envKey && envKey === publicKey) return currentSiteId();
+  if (envKey && envKey === publicKey) return resolveSiteWorkspaceId();
 
   return null;
 }