create-ailk 0.1.1 → 0.2.0

package/templates/apps/api/src/services/consent.ts

@@ -0,0 +1,236 @@
+/**
+ * @file consent.ts
+ * @description The consent-grant writer (#5275 Part B) — `recordConsent`,
+ * the one function that turns a person's answers to a site's consent
+ * purposes into `ConsentGrant` rows, plus `recordLegacyConsent`, the D11
+ * path for a caller that could only say `consent: true`.
+ *
+ * SURFACE-AGNOSTIC BY DESIGN (D10). A grant's subject is a `subjectType` +
+ * `subjectId` pair of plain scalars with no relation into any other table
+ * (ADR 0009 invariant 1), so a new surface — the newsletter subscribe path
+ * is the named follow-up — adopts consent by adding ONE call here and NO
+ * migration. Nothing in this module knows what a project listing is.
+ *
+ * THE EVIDENCE RULE (spec §5.2): no row is ever written with statement text
+ * the system did not actually render to that person. Two consequences:
+ *
+ *   - `recordConsent` resolves each statement from the SAME registry and the
+ *     SAME `resolveConsentStatement` the renderer used (D7), so the recorded
+ *     wording and the rendered wording are one string by construction, and a
+ *     request body never carries wording at all. A purpose id the registry
+ *     does not know is skipped, not written: no statement was rendered for it.
+ *   - A grant whose wording cannot be proven — a legacy `consent: true` body,
+ *     or the migration backfill — carries `UNRECOVERABLE_CONSENT_STATEMENT`,
+ *     never today's default text. Stamping current wording onto a grant
+ *     nobody read would fabricate evidence (D11).
+ *
+ * APPEND-ONLY (D9): every write is a `createMany`; this module never
+ * updates or upserts, so a later withdrawal sits beside the earlier grant
+ * rather than replacing it. Declines are written as `granted: false` (D8).
+ */
+
+import { createHash } from "node:crypto";
+
+import { logger } from "@working-theory/observability";
+import {
+  consentPurposeById,
+  resolveConsentStatement,
+  SITE_CONSENT_CONFIG_DEFAULTS,
+  type SiteConsentConfig,
+} from "@working-theory/validation";
+
+import { prisma } from "../lib/prisma.js";
+
+/**
+ * The one delegate this module writes through — the shape of `prisma` AND of
+ * the `tx` client an interactive `$transaction` hands out, so a caller that
+ * creates the subject row can write the grant in the SAME transaction (the
+ * listing's `start` does): either the row and its evidence both land, or
+ * neither does.
+ */
+export interface ConsentWriteClient {
+  consentGrant: {
+    createMany(args: { data: ConsentGrantRow[] }): Promise<{ count: number }>;
+  };
+}
+
+interface ConsentGrantRow {
+  siteId: string;
+  subjectType: string;
+  subjectId: string;
+  purposeId: string;
+  granted: boolean;
+  locale: string;
+  statement: string;
+  statementHash: string;
+}
+
+/**
+ * The most keys a `consents` map may carry on an anonymous request. Any real
+ * registry is a handful of purposes; the cap bounds the per-request work an
+ * unbounded map could buy (security review, Low 3).
+ */
+export const MAX_CONSENT_KEYS = 64;
+
+/**
+ * The statement sentinel for a grant whose wording cannot be proven — a row
+ * carrying it records THAT a person consented (and when), not WHAT they read.
+ * Written on exactly two paths: `recordLegacyConsent` (a body carrying only
+ * the legacy `consent: true` literal, D11) and the consent_grants migration's
+ * backfill of pre-existing listings, which must carry this exact literal.
+ * It is never a substitute for real wording: a caller that rendered a
+ * statement records it through `recordConsent`.
+ */
+export const UNRECOVERABLE_CONSENT_STATEMENT =
+  "[unrecoverable: no statement was rendered by this system for this grant]";
+
+/** BCP-47 `und` — the locale of a statement nobody read. */
+export const UNRECOVERABLE_CONSENT_LOCALE = "und";
+
+/** sha256 hex of a statement — the `statementHash` that groups identical wordings. */
+export function consentStatementHash(statement: string): string {
+  return createHash("sha256").update(statement).digest("hex");
+}
+
+/**
+ * The site's consent registry.
+ *
+ * There is no per-site consent config ROW yet (spec §4 deliberately adds
+ * none), so every site resolves to `SITE_CONSENT_CONFIG_DEFAULTS`. This
+ * function is the single seam a `SiteConsentConfig` row wires into later
+ * (the `listingConfigFor` shape: read the blob, `consentConfigFor(blob)`).
+ * The RENDERER (`packages/ui`) resolves its statements from the same
+ * `SITE_CONSENT_CONFIG_DEFAULTS`, which is what keeps the recorded statement
+ * identical to the rendered one until a config row exists — at which point
+ * both sides must read the same row.
+ */
+export async function consentConfigForSite(
+  _siteId: string,
+): Promise<SiteConsentConfig> {
+  return SITE_CONSENT_CONFIG_DEFAULTS;
+}
+
+/**
+ * The id of the first REQUIRED registry purpose `consents` does not GRANT —
+ * declined (`false`) or simply absent — or `undefined` when every required
+ * purpose is `true`. Absence counts as unmet on purpose (security review,
+ * Medium 1): a body carrying `consents: {}` beside `consent: true` would
+ * otherwise create the subject with no grant row at all, which is a worse
+ * record than the legacy sentinel. A surface whose subject cannot exist
+ * without the required purposes (the listing: the row goes on to publish the
+ * founder's address) checks this before creating the subject.
+ */
+export function requiredConsentUnmet(
+  config: SiteConsentConfig,
+  consents: Record<string, boolean>,
+): string | undefined {
+  for (const purpose of config.purposes) {
+    if (purpose.required && consents[purpose.id] !== true) return purpose.id;
+  }
+  return undefined;
+}
+
+export interface RecordConsentInput {
+  siteId: string;
+  /** e.g. `project_listing`, `subscriber` — a plain scalar, no relation (D10). */
+  subjectType: string;
+  subjectId: string;
+  /** The locale the statements were RENDERED in; the served locale is what gets recorded. */
+  locale: string;
+  config: SiteConsentConfig;
+  /** purposeId → the person's answer. `false` is a stored decline (D8). */
+  consents: Record<string, boolean>;
+}
+
+/**
+ * Write one `ConsentGrant` row per answered purpose in one `createMany`.
+ * Returns the number of rows written. Append-only — never update/upsert.
+ * `db` defaults to the shared client; pass a `$transaction` client to land
+ * the grant atomically with the subject row it belongs to.
+ */
+export async function recordConsent(
+  input: RecordConsentInput,
+  db: ConsentWriteClient = prisma,
+): Promise<number> {
+  const rows: ConsentGrantRow[] = [];
+  const unknown: string[] = [];
+
+  for (const [purposeId, granted] of Object.entries(input.consents)) {
+    const purpose = consentPurposeById(input.config, purposeId);
+    if (!purpose) {
+      // Not in the registry ⇒ no statement was rendered for it ⇒ nothing to
+      // record (the evidence rule). Collected and logged ONCE per call below,
+      // because a client naming a purpose the site does not declare is a
+      // drift someone should see — and a map full of junk keys must not buy
+      // a log line each.
+      unknown.push(purposeId);
+      continue;
+    }
+    const { statement, locale } = resolveConsentStatement(purpose, input.locale);
+    rows.push({
+      siteId: input.siteId,
+      subjectType: input.subjectType,
+      subjectId: input.subjectId,
+      purposeId,
+      granted,
+      locale,
+      statement,
+      statementHash: consentStatementHash(statement),
+    });
+  }
+
+  if (unknown.length > 0) {
+    logger.warn(
+      {
+        siteId: input.siteId,
+        subjectType: input.subjectType,
+        unknownCount: unknown.length,
+        sample: unknown.slice(0, 5),
+      },
+      "[consent] skipping unknown purpose ids — not in the site's consent registry, no statement was rendered for them",
+    );
+  }
+
+  if (rows.length === 0) return 0;
+  const result = await db.consentGrant.createMany({ data: rows });
+  return result.count;
+}
+
+export interface RecordLegacyConsentInput {
+  siteId: string;
+  subjectType: string;
+  subjectId: string;
+  config: SiteConsentConfig;
+}
+
+/**
+ * The D11 path: a body that carried only the legacy `consent: true` literal.
+ * Writes ONE grant against the site's first `required` purpose (falling back
+ * to its first purpose), `granted: true`, with the statement marked
+ * unrecoverable — the caller affirmed, but this system rendered it no
+ * wording to affirm.
+ */
+export async function recordLegacyConsent(
+  input: RecordLegacyConsentInput,
+  db: ConsentWriteClient = prisma,
+): Promise<number> {
+  const purpose =
+    input.config.purposes.find((p) => p.required) ?? input.config.purposes[0];
+  if (!purpose) return 0;
+
+  const result = await db.consentGrant.createMany({
+    data: [
+      {
+        siteId: input.siteId,
+        subjectType: input.subjectType,
+        subjectId: input.subjectId,
+        purposeId: purpose.id,
+        granted: true,
+        locale: UNRECOVERABLE_CONSENT_LOCALE,
+        statement: UNRECOVERABLE_CONSENT_STATEMENT,
+        statementHash: consentStatementHash(UNRECOVERABLE_CONSENT_STATEMENT),
+      },
+    ],
+  });
+  return result.count;
+}

package/templates/apps/api/src/services/flow-engine.ts

@@ -33,6 +33,7 @@ import { logger } from "@working-theory/observability";
 import {
   aeoScoreResultSchema,
   deriveFlags,
+  flowAddressValueSchema,
   flowConfigSchema,
   hiddenAnswers,
   isStepVisible,
@@ -388,6 +389,23 @@ function extractStepValues(
         };
       }
       if (!present) continue;
+      // #5279 — an `address` field submits ONE nested parts object under its
+      // own name (six separable values, never a concatenated line), so it is
+      // checked against that shape rather than against any of the string
+      // branches below. `raw` is `unknown` here (boundedStepValues), so this
+      // is the same "type it before it reaches JSONB" discipline the text/tel
+      // cap below documents: an anonymous POST cannot park an arbitrary
+      // object in `flow_sessions.state` by naming an address field.
+      if (field.inputType === "address") {
+        if (!flowAddressValueSchema.safeParse(raw).success) {
+          return {
+            ok: false,
+            message: `field "${field.name}" must be a structured address`,
+          };
+        }
+        data[field.name] = raw;
+        continue;
+      }
       if (field.inputType === "select") {
         const allowed = new Set(field.options?.map((o) => o.value) ?? []);
         if (typeof raw !== "string" || !allowed.has(raw)) {

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

@@ -0,0 +1,342 @@
+/**
+ * @file listing-promotion.ts
+ * @description ProjectListing → owner-user linking across the inbox/auth
+ * namespace boundary (#5295; ADR 0009 D3 service-layer pattern).
+ *
+ * The sibling of `lead-promotion.ts`, for the same shape of problem. A
+ * `ProjectListing` is written on an ANONYMOUS route: `founderEmail` is a string
+ * a stranger typed into a form, and nothing about typing an address proves you
+ * own it. So `founderEmail` can never by itself say whose row it is — two
+ * people who type the same address are two people — and this service
+ * materializes the ownership claim that a read may actually join on.
+ *
+ * The link is stamped only when ALL THREE hold:
+ *
+ *   1. the reconciling user's OWN email is VERIFIED (`User.emailVerified`) —
+ *      the consent basis, inherited from `lead-promotion.ts` D2, and a
+ *      service-level invariant rather than a caller obligation, so a wrong
+ *      call-site cannot bypass it;
+ *   2. that verified address matches the listing's `founderEmail`;
+ *   3. the listing's `siteId` is one of that user's OWN tenant workspaces —
+ *      the tenant-safety invariant (`lead-promotion.ts` D3), which is what
+ *      makes a row captured under another organization's workspace unmatchable
+ *      by construction rather than by a later filter.
+ *
+ * Any one failing is a NO-OP returning `count: 0`, never a throw — the lead
+ * service's posture, for the same reason: this runs on a reconciliation path
+ * (an email-verification callback, a sign-in), where a throw would fail an
+ * unrelated request that had nothing to do with listings.
+ *
+ * And one condition the lead service does NOT have: the match must be
+ * UNAMBIGUOUS. Two strangers can type the same address into the anonymous form,
+ * and when they do nothing says which of the two rows is whose — so a row is
+ * claimed only when it is the only un-linked row carrying that address at its
+ * site. See the refusal block in the body; this is the difference between
+ * mirroring the lead service's mechanism and inheriting a disclosure from it.
+ *
+ * Workspace resolution is delegated to `tenant-context.ts`'s `listTenancy` —
+ * 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
+ * `tenant-context.ts` / `tenant-db.ts`). That delegation is module-conditional;
+ * see the note above TENANT_CONTEXT_SPECIFIER.
+ *
+ * PII boundary: this module never logs or returns `founderEmail`,
+ * `founderName`, or any application answer. The result carries ids only — a
+ * listing id and the workspace id it sits in.
+ *
+ * NOTE for whoever wires this to a verification hook: `internal_error` carries
+ * the raw `Error.message`, which can be a database error string. It is for the
+ * caller's log, not for a response body. Same shape as `lead-promotion.ts`.
+ */
+
+import type { Id } from "@working-theory/ids";
+import { logger } from "@working-theory/observability";
+import { PROJECT_LISTING_STORED_STATUSES } from "@working-theory/validation";
+
+import { isModuleEnabled } from "../config/modules.js";
+import { prisma } from "../lib/prisma.js";
+
+/**
+ * `tenant-context.ts` is a multi-tenant SLICE file the OSS strip removes
+ * (#5182), and `listTenancy` is a VALUE — a runtime call, not an erasable type
+ * — so neither a static import nor a literal `await import("./tenant-context.js")`
+ * survives the strip: `tsc` resolves a string-literal specifier whether or not
+ * the branch containing it can ever run, and either form is TS2307 on the
+ * public tree.
+ *
+ * The remedy is the one `lead-promotion.ts`, `server.ts` and
+ * `routes/content/index.ts` already use: gate the call on
+ * `isModuleEnabled('multi-tenant')` and read the specifier from this constant
+ * so it is not a literal written at the call site. What defeats resolution is
+ * the INDIRECTION, not the type of the value.
+ *
+ * Restated here rather than shared with `lead-promotion.ts`: the mechanism is
+ * three lines and a constant, and extracting it would mean editing the Lead
+ * promotion path this file deliberately only mirrors.
+ *
+ * Semantics on a build without the module: there is no workspace concept at
+ * all, so a user has no workspaces, so no listing can match
+ * `siteId ∈ workspaceIds` — which is exactly the zero-workspace early return
+ * below. The no-op is correct rather than degraded.
+ */
+const TENANT_CONTEXT_SPECIFIER = "./tenant-context.js";
+
+/**
+ * The statuses a row must be in to be claimable: every stored status EXCEPT
+ * `draft`.
+ *
+ * Two reasons, and the second is a security one.
+ *
+ * A `draft` is addressed by its RESUME TOKEN, which is that draft's whole
+ * credential, and `resumeTokenHash` is cleared at submit — so the token and the
+ * owner link hand off to each other cleanly. Before submit the token is the
+ * access path; after it, the link is. A draft needs no link and gains nothing
+ * from one.
+ *
+ * And `POST /v1/project-listings` is ANONYMOUS with the concurrent-listing
+ * quota enforced at SUBMIT rather than at start, so anyone holding a site's
+ * public key — it ships in browser JavaScript by design — can create unbounded
+ * `draft` rows carrying any address they choose. If drafts were claimable, one
+ * such row would be enough either to hand a stranger's text to whoever verifies
+ * that address, or (under the ambiguity refusal below) to block that person
+ * from ever claiming their own listing. Excluding drafts raises the cost of
+ * that from one anonymous request to a COMPLETE application that passes submit
+ * validation, counts against the two-row quota for that address at that site,
+ * and sends an operator notification to the address itself.
+ *
+ * Derived from the exported vocabulary rather than restated, so a new stored
+ * status is a deliberate decision here rather than a silent inclusion.
+ */
+const CLAIMABLE_STATUSES: readonly string[] = PROJECT_LISTING_STORED_STATUSES.filter(
+  (status) => status !== "draft",
+);
+
+/** 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<{ workspaces: Array<{ id: string }> }> };
+      }
+    | { ok: false; error: { message: string } }
+  >;
+}
+
+// ─── Types ────────────────────────────────────────────────────────────────────
+
+export type PromotedListing = {
+  listingId: string;
+  siteId: string;
+};
+
+export type PromoteListingsResult =
+  | { ok: true; count: number; promoted: PromotedListing[] }
+  | {
+      ok: false;
+      error: { kind: "user_not_found" | "internal_error"; message: string };
+    };
+
+// ─── Main export ──────────────────────────────────────────────────────────────
+
+/**
+ * Link every un-linked `ProjectListing` whose `founderEmail` is the verifying
+ * user's own verified address, within that user's own tenant workspaces.
+ *
+ * No-ops (`count: 0`) — never throws — when: the user's email is unverified,
+ * the user belongs to no workspace, no matching un-linked listing exists, or
+ * the match is ambiguous (more than one un-linked listing carries the address
+ * at one site).
+ *
+ * Idempotent, and proved so on both sides of the write: a listing already
+ * carrying `ownerUserId` is excluded from the candidate read AND from the
+ * update's own `where`, so a re-invocation links nothing and a concurrent run
+ * cannot transfer a row away from the user who already claimed it.
+ */
+export async function promoteListingsForVerifiedUser(params: {
+  userId: string;
+}): Promise<PromoteListingsResult> {
+  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" },
+      };
+    }
+
+    // Condition 1 — the verified-email gate. 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: [] };
+    }
+
+    // Condition 3 — resolve the verifying user's OWN workspaces via the sole
+    // tenant-context assembler (never a raw membership or workspace model query
+    // in this file). Module-conditional per the note on
+    // TENANT_CONTEXT_SPECIFIER above: no multi-tenant module, no workspaces.
+    let workspaceIds: string[] = [];
+    if (isModuleEnabled("multi-tenant")) {
+      const specifier: string = TENANT_CONTEXT_SPECIFIER;
+      const { listTenancy } = (await import(specifier)) as TenantContextSlice;
+      const tenancy = await listTenancy({
+        userId: user.id as Id<"user">,
+        sessionTenant: undefined,
+      });
+      if (!tenancy.ok) {
+        return {
+          ok: false,
+          error: { kind: "internal_error", message: tenancy.error.message },
+        };
+      }
+
+      workspaceIds = tenancy.value.organizations.flatMap((org) =>
+        org.workspaces.map((workspace) => workspace.id as string),
+      );
+    }
+
+    if (workspaceIds.length === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    /**
+     * Conditions 2 + 3, both in the WHERE clause so neither is a post-filter.
+     *
+     * The email comparison is EXACT equality against the same normalization
+     * `startProjectListingDraft` applies when it writes the column
+     * (`normalizeFounderEmail` — trim + lower-case), so the two sides of the
+     * match are normalized the same way by construction.
+     *
+     * Deliberately NOT `{ equals, mode: "insensitive" }`, the form
+     * `waitlist-signups.ts` uses on `Lead.email`: Prisma compiles an
+     * insensitive `equals` to `founder_email ILIKE $1`, which makes `_` and
+     * `%` in the CALLER'S own verified address LIKE wildcards. A user whose
+     * real address is `a_c@example.com` then matches a different founder's
+     * `abc@example.com` in the same workspace — verified in this repo against
+     * a live Postgres, two rows in, two rows out. That is precisely the
+     * cross-founder capture this link exists to remove, so the stricter
+     * comparison wins. The cost is a listing whose stored `founderEmail`
+     * predates `normalizeFounderEmail` and carries upper case: it stays
+     * un-linked, which is the safe direction (a missing link is a no-op; a
+     * wrong one hands over a stranger's submission) and the same resting
+     * state every un-promoted row already sits in.
+     *
+     * `ownerUserId: null` is what makes this idempotent.
+     */
+    const candidates = await prisma.projectListing.findMany({
+      where: {
+        founderEmail: user.email.trim().toLowerCase(),
+        siteId: { in: workspaceIds },
+        ownerUserId: null,
+        // See CLAIMABLE_STATUSES: a draft is token-addressed, and an anonymous
+        // caller can create them without passing the quota.
+        status: { in: [...CLAIMABLE_STATUSES] },
+      },
+      select: { id: true, siteId: true },
+    });
+
+    if (candidates.length === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    /**
+     * AMBIGUITY REFUSAL — the case a verified email cannot resolve.
+     *
+     * Two strangers can both type the same address into the anonymous form, and
+     * when they do there are two un-linked rows carrying it and NOTHING that
+     * says which is whose. Linking both to whoever verifies the address hands
+     * one person the other's whole application — the exact disclosure this
+     * column exists to remove, arriving by the back door. `lead-promotion.ts`
+     * links every match and therefore has this shape; it is out of scope to
+     * change there, and it is not inherited here.
+     *
+     * So the rule is: within ONE site, a verified address claims a row only
+     * when it is the ONLY un-linked row carrying that address. Otherwise every
+     * row in that ambiguous group stays null. The grain is the site because
+     * that is where the collision happens and where the concurrent-listing
+     * limit is already counted (`countOtherNonTerminalListings`); a second site
+     * of the same user is judged on its own.
+     *
+     * The cost is a founder who legitimately submitted TWO applications at one
+     * site (`PROJECT_LISTING_CONCURRENT_LIMIT` is 2): neither is linked, and
+     * they reach those rows the way they do today. That is the deliberate
+     * trade. Nothing in the data distinguishes their second application from a
+     * stranger's first, so the honest answer is to claim neither — and an
+     * unclaimed row is the resting state this column already treats as
+     * legitimate, not a failure.
+     *
+     * `users.email` is UNIQUE, so there is never a SECOND verifier competing
+     * for the refused rows: refusing costs no other claimant anything.
+     */
+    const perSite = new Map<string, number>();
+    for (const listing of candidates) {
+      perSite.set(listing.siteId, (perSite.get(listing.siteId) ?? 0) + 1);
+    }
+    const attributable = candidates.filter(
+      (listing) => perSite.get(listing.siteId) === 1,
+    );
+
+    const ambiguousRows = candidates.length - attributable.length;
+    if (ambiguousRows > 0) {
+      // PII-safe: counts and the user id only — never the address, the
+      // founder's name, or a listing id that would identify whose row it is.
+      logger.warn(
+        {
+          kind: "ambiguous_listing_owner",
+          userId: user.id,
+          ambiguousRows,
+          attributableRows: attributable.length,
+        },
+        "[listing-promotion] more than one un-linked listing shares this address at one site; leaving those rows unlinked",
+      );
+    }
+
+    if (attributable.length === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    /**
+     * `ownerUserId: null` is repeated on the WRITE, not only on the read above.
+     * Without it the update is a blind write over whatever the row holds now,
+     * and two reconciliation runs that both saw the row un-linked would let the
+     * second one TRANSFER ownership away from the first — which contradicts the
+     * idempotency this service documents. With it the write is a
+     * compare-and-swap: the loser of the race matches 0 rows.
+     *
+     * `count` therefore reports rows this call actually claimed, not rows it
+     * intended to.
+     */
+    const written = await prisma.projectListing.updateMany({
+      where: {
+        id: { in: attributable.map((listing) => listing.id) },
+        ownerUserId: null,
+      },
+      data: { ownerUserId: user.id, ownerLinkedAt: new Date() },
+    });
+
+    if (written.count === 0) {
+      return { ok: true, count: 0, promoted: [] };
+    }
+
+    return {
+      ok: true,
+      count: written.count,
+      promoted: attributable.map((listing) => ({
+        listingId: listing.id,
+        siteId: listing.siteId,
+      })),
+    };
+  } 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/project-listing-decision.ts

@@ -80,7 +80,11 @@ import { prisma } from "../lib/prisma.js";
 import { listingConfigFor } from "./listing-config.js";
 import { generateListingFlow } from "./project-listing-flow.js";
 import { fileListingIssue } from "./project-listing-issue.js";
-import { computeListingStatus } from "./project-listings.js";
+import {
+  addressPartsFromRow,
+  computeListingStatus,
+  siteAnswersFromRow,
+} from "./project-listings.js";
 
 export type ListingDecision = "active" | "rejected";
 
@@ -102,7 +106,19 @@ const SELECT = {
   faqs: true,
   anythingElse: true,
   address: true,
+  // #5279 — the structured parts beside the display string.
+  addressLine1: true,
+  addressLine2: true,
+  addressCity: true,
+  addressRegion: true,
+  addressPostalCode: true,
+  addressCountry: true,
   questions: true,
+  // #5285 — the operator's review payload carries EVERY site answer, the
+  // `operator-only` ones included. That visibility is what it is for: an
+  // answer a site asked for its own triage reaches the reviewer and stops
+  // short of the public read, which narrows through `publicSiteAnswers`.
+  siteAnswers: true,
   founderName: true,
   founderEmail: true,
   founderCompany: true,
@@ -159,10 +175,14 @@ function toListing(row: Row, waitlistCount: number): ProjectListing {
     faqs: row.faqs as unknown as ProjectListingFaqs | null,
     anythingElse: row.anythingElse,
     address: row.address,
+    // #5279 — one reader of the parts, shared with `project-listings.ts`, so
+    // the two row renderers cannot drift on what "has parts" means.
+    addressParts: addressPartsFromRow(row),
     founderName: row.founderName,
     founderEmail: row.founderEmail,
     founderCompany: row.founderCompany,
     questions: row.questions as unknown as ProjectListingQuestions | null,
+    siteAnswers: siteAnswersFromRow(row.siteAnswers),
     logoMarkUrl: row.logoMarkUrl,
     logoWordmarkUrl: row.logoWordmarkUrl,
     featured: row.featured,