create-ailk 0.1.1 → 0.3.0

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

@@ -1,4 +1,11 @@
 /**
+ * NOT marked `oss: false` (D-48/#5366 escalation — see
+ * `routes/project-listings/me.ts`'s header comment): imported by
+ * `routes/project-listings/{start,patch-draft,submit,public,me}.ts`, each of
+ * which ships unconditionally because `routes/project-listings/index.ts`'s
+ * multi-tenant literal `import()` forces it. Registration of the routes that
+ * call into this service stays gated (`isModuleEnabled("signal-collectors")`).
+ *
  * @file project-listings.ts
  * @description The founder's-application-row service (#4998, reshaped by
  * #5036) — writes, reads, and transitions `ProjectListing` (ADR 0009 D3
@@ -42,10 +49,15 @@ import {
   clampWindowDays,
   buildProjectListingDraftPatchSchema,
   buildProjectListingSubmitSchema,
+  composeAddressLine,
+  composeFounderName,
+  flowAddressValueSchema,
+  publicSiteAnswers,
   PROJECT_LISTING_CONCURRENT_LIMIT,
   PROJECT_LISTING_NON_TERMINAL_STATUSES,
 } from "@working-theory/validation";
 import type {
+  FlowAddressValue,
   ProjectListing,
   ProjectListingDraftPatchInput,
   ProjectListingFaqs,
@@ -56,6 +68,13 @@ import type {
 
 import { prisma } from "../lib/prisma.js";
 
+import {
+  consentConfigForSite,
+  MAX_CONSENT_KEYS,
+  recordConsent,
+  recordLegacyConsent,
+  requiredConsentUnmet,
+} from "./consent.js";
 import { routeLead, type SourceMeta } from "./lead-routing.js";
 import { listingConfigFor } from "./listing-config.js";
 
@@ -205,9 +224,27 @@ const PROJECT_LISTING_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 site's own answers, and the window the applicant asked for.
+  // `windowDays` rides the select because `submit` re-validates the assembled
+  // application, and `requestedWindowDays` is one of its fields now.
+  siteAnswers: true,
+  windowDays: true,
   founderName: true,
+  // #5407 — the name parts beside the composed display string, the phone, and
+  // the resume-link verification stamp.
+  founderFirstName: true,
+  founderLastName: true,
   founderEmail: true,
+  founderPhone: true,
+  emailVerifiedAt: true,
   founderCompany: true,
   headline: true,
   logoMarkUrl: true,
@@ -228,6 +265,81 @@ type ProjectListingRow = Prisma.ProjectListingGetPayload<{
   select: typeof PROJECT_LISTING_SELECT;
 }>;
 
+/**
+ * The structured address parts of a row, or null (#5279).
+ *
+ * Exported because `project-listing-decision.ts` renders the same row shape
+ * and must answer the same way — two readers guessing separately at what
+ * "has parts" means is exactly how one of them starts emitting a half-filled
+ * object.
+ *
+ * The rule is the composite's REQUIRED set: the five non-optional parts are
+ * all present, or there are no parts. `addressLine2` is optional in the
+ * fieldset, so it rides along when present and is simply absent when not. A
+ * row written before #5279 has all six columns null and answers null here —
+ * never a partial object reconstructed from `address`, which nothing in this
+ * repo parses.
+ *
+ * `.safeParse` rather than a cast: these are six nullable TEXT columns, and
+ * the emitted object must satisfy `flowAddressValueSchema` or the row fails
+ * its own response schema downstream. A shape that somehow does not (a
+ * `country` that is not an alpha-2 code, say) answers null rather than
+ * putting an invalid address on the PUBLIC read.
+ */
+export function addressPartsFromRow(row: {
+  addressLine1: string | null;
+  addressLine2: string | null;
+  addressCity: string | null;
+  addressRegion: string | null;
+  addressPostalCode: string | null;
+  addressCountry: string | null;
+}): FlowAddressValue | null {
+  if (
+    row.addressLine1 === null ||
+    row.addressCity === null ||
+    row.addressRegion === null ||
+    row.addressPostalCode === null ||
+    row.addressCountry === null
+  ) {
+    return null;
+  }
+  const parsed = flowAddressValueSchema.safeParse({
+    addressLine1: row.addressLine1,
+    ...(row.addressLine2 !== null && { addressLine2: row.addressLine2 }),
+    city: row.addressCity,
+    region: row.addressRegion,
+    postalCode: row.addressPostalCode,
+    country: row.addressCountry,
+  });
+  return parsed.success ? parsed.data : null;
+}
+
+/**
+ * The site-answers object of a row, or null (#5285).
+ *
+ * Exported for the same reason `addressPartsFromRow` is: the operator's
+ * decision payload renders the same row shape and must answer the same way.
+ *
+ * The column is `Json?`, so Prisma types it as `JsonValue` — an array, a
+ * number and a string all satisfy it. Only ever written by
+ * `draftUpdateData` from a body the site's own declarations validated, so a
+ * row holding anything else is a row somebody wrote around this service.
+ * A non-object answers null rather than being cast: a value of the wrong
+ * SHAPE reaching the response schema would fail the whole read, and one
+ * malformed row must not take a listing page down.
+ *
+ * Non-string members are dropped for the same reason — the store is
+ * `Record<string, string>`, and what is handed back has to actually be one.
+ */
+export function siteAnswersFromRow(value: Prisma.JsonValue | null): Record<string, string> | null {
+  if (value === null || typeof value !== "object" || Array.isArray(value)) return null;
+  return Object.fromEntries(
+    Object.entries(value).filter(
+      (entry): entry is [string, string] => typeof entry[1] === "string",
+    ),
+  );
+}
+
 /**
  * `now` is passed rather than read inside so one read renders every row of a
  * list against a single instant. `featuredEnabled` is the site's config
@@ -257,12 +369,25 @@ function toResponseRow(
     faqs: row.faqs as unknown as ProjectListingFaqs | null,
     anythingElse: row.anythingElse,
     address: row.address,
+    addressParts: addressPartsFromRow(row),
     founderName: row.founderName,
+    founderFirstName: row.founderFirstName,
+    founderLastName: row.founderLastName,
     founderEmail: row.founderEmail,
+    founderPhone: row.founderPhone,
+    // #5407 — the operator's verification filter at review. Null means "no
+    // opening of the resume link recorded", never "verification failed".
+    emailVerifiedAt: row.emailVerifiedAt ? row.emailVerifiedAt.toISOString() : null,
     founderCompany: row.founderCompany,
     questions: row.questions as unknown as ProjectListingQuestions | null,
     logoMarkUrl: row.logoMarkUrl,
     logoWordmarkUrl: row.logoWordmarkUrl,
+    // #5285 — UNFILTERED here, deliberately. This row shape serves the tenant
+    // dashboard and the founder's own draft read, both of which are entitled
+    // to every answer. The PUBLIC read is the one that must not carry an
+    // `operator-only` answer, and it narrows this through `publicSiteAnswers`
+    // in `publicProjectListings` — one filter, on the one read that publishes.
+    siteAnswers: siteAnswersFromRow(row.siteAnswers),
     featured: featuredEnabled && row.featured,
     // The row's OWN flag decides the closed exemption (#5036 D6b), not the
     // site's `featuredEnabled` switch: that switch governs whether the flag
@@ -384,6 +509,42 @@ function hashResumeToken(token: string): string {
   return createHash("sha256").update(token).digest("hex");
 }
 
+// ─── The email-verification nonce (#5407) ──────────────────────────────────
+
+/**
+ * Mint the nonce that PROVES the founder read mail sent to `founderEmail`.
+ *
+ * WHY A SECOND CREDENTIAL EXISTS AT ALL, since the obvious design is to reuse
+ * the resume token the emailed link already carries. That design cannot work:
+ * `start` returns the resume token in its own 201 body, to whoever posted the
+ * form. The emailed link is a SECOND COPY of a credential the applicant
+ * already holds, so keying verification on it would let two HTTP calls — open
+ * a draft under a stranger's address, take the token out of the response,
+ * present it back — forge the stamp with no mailbox involved. Found by this
+ * change's own security review, before it shipped.
+ *
+ * This nonce closes that because of where it does NOT go. It is minted here,
+ * digested into `emailVerifyNonceHash`, and returned to exactly one caller —
+ * `start`, which hands it to `sendListingResumeLink` and to nothing else. It
+ * is in no response body, no log line, and no browser that filled the form.
+ * The only way to hold it is to have read the email.
+ *
+ * Same 256 bits as the resume token, for the same reason.
+ */
+function mintVerifyNonce(): string {
+  return randomBytes(RESUME_TOKEN_BYTES).toString("base64url");
+}
+
+/**
+ * What `emailVerifyNonceHash` holds. The same plain sha-256 as
+ * `hashResumeToken`, for the same reason — the input is CSPRNG output, not a
+ * human-chosen secret — and kept as its own function rather than aliased so
+ * no call site has to read "resume token" while meaning the nonce.
+ */
+function hashVerifyNonce(nonce: string): string {
+  return createHash("sha256").update(nonce).digest("hex");
+}
+
 /**
  * Resolve the ONE draft a token grants access to (#5036 D1).
  *
@@ -410,17 +571,38 @@ async function findDraftByToken(
 // ─── start (POST, anonymous) ────────────────────────────────────────────────
 
 /**
- * `start` has no failure mode of its own to report. It reads the site's config
- * (which falls back to the platform defaults rather than erroring) and writes
- * one row; a Prisma failure is a 500 through the framework, as everywhere else.
- * The Lead write — the one step that used to give this operation a
- * `persist_failed`/`config_missing` surface — moved to `submit`.
+ * `start` has one failure mode of its own to report (#5275): a `consents`
+ * map that does not GRANT every purpose the site's registry marks required —
+ * declined, or simply absent. The legacy literal says the founder consented;
+ * a `false` (or nothing) beside it for the required purpose says they did
+ * not — the body contradicts itself, and the row must not be created on it
+ * (it would go on to publish the founder's address against a recorded
+ * decline, or with no evidence row at all). An oversized map is the same
+ * 400. Everything else is as before: the site's config falls back to the
+ * platform defaults rather than erroring, and a Prisma failure is a 500
+ * through the framework. The Lead write — the step that used to give this
+ * operation a `persist_failed`/`config_missing` surface — moved to `submit`.
  */
-export type StartProjectListingDraftResult = {
-  ok: true;
-  id: string;
-  resumeToken: string;
-};
+export type StartProjectListingDraftResult =
+  | {
+      ok: true;
+      id: string;
+      resumeToken: string;
+      /**
+       * #5407 — the email-verification nonce, for the RESUME-EMAIL BUILDER
+       * and for nothing else.
+       *
+       * A sibling of the result rather than a field of anything the route
+       * hands to a response schema, deliberately (lesson 05): `start`'s 201
+       * body is `projectListingStartResponseSchema`, which is `.strict()` and
+       * carries `id` and `resumeToken` only. That route's request and
+       * response shapes are a declared hard floor and are unchanged — this
+       * value reaches `sendListingResumeLink` from the route's local
+       * variable and never touches the wire.
+       */
+      verifyNonce: string;
+    }
+  | { ok: false; error: { kind: "invalid_input"; message: string } };
 
 /**
  * Create a `draft` from step one — the founder's name, email and consent.
@@ -444,27 +626,211 @@ export async function startProjectListingDraft(
   siteId: string,
   input: ProjectListingStartInput,
 ): Promise<StartProjectListingDraftResult> {
-  const { founderName, requestedWindowDays } = input;
+  const { requestedWindowDays } = input;
+  // #5407 — the NOT NULL display column. `composeFounderName` builds it from
+  // the PARTS wherever both are written (even beside a `founderName` the body
+  // also sent, so the stored line and the stored parts can never disagree),
+  // and stores a line sent on its own verbatim. ONE WAY ONLY: nothing here or
+  // anywhere else derives parts back out of a line. The schema has already
+  // refused a body carrying neither shape, so this always produces a string.
+  const founderName = composeFounderName(input);
   const founderEmail = normalizeFounderEmail(input.founderEmail);
 
   const listingConfig = await listingConfigFor(siteId);
   const windowDays = clampWindowDays(requestedWindowDays, listingConfig);
 
+  // #5275 — refuse BEFORE the row exists: a required purpose not granted
+  // (declined or absent) is a body that contradicts its own `consent: true`,
+  // and an oversized map is not a form's answer.
+  const consentConfig = await consentConfigForSite(siteId);
+  if (input.consents) {
+    if (Object.keys(input.consents).length > MAX_CONSENT_KEYS) {
+      return {
+        ok: false,
+        error: {
+          kind: "invalid_input",
+          message: `consents carries more than ${MAX_CONSENT_KEYS} purposes`,
+        },
+      };
+    }
+    const unmet = requiredConsentUnmet(consentConfig, input.consents);
+    if (unmet !== undefined) {
+      return {
+        ok: false,
+        error: {
+          kind: "invalid_input",
+          message: `required consent purpose "${unmet}" was not granted`,
+        },
+      };
+    }
+  }
+
   const resumeToken = mintResumeToken();
-  const row = await prisma.projectListing.create({
-    data: {
-      siteId,
-      founderName,
-      founderEmail,
-      status: "draft",
-      consentAt: new Date(),
-      resumeTokenHash: hashResumeToken(resumeToken),
-      windowDays,
-    },
-    select: { id: true },
+  // #5407 — minted on EVERY draft, whether or not the site sends the resume
+  // email. `start` cannot know: the send is decided asynchronously inside
+  // `sendListingResumeLink`, against the site's own config. A site running no
+  // resume email therefore stores a nonce nobody is ever handed, and nothing
+  // on that row can ever verify — which is the correct outcome rather than a
+  // gap, because no one has read anything at that address.
+  const verifyNonce = mintVerifyNonce();
+  // #5275 — the row and its grant record land in ONE transaction: from here
+  // on `consentAt` and the ConsentGrant row are stamped by the SAME
+  // affirmative act, and a grant write that fails takes the row with it
+  // rather than stranding a "consented" listing with no evidence (security
+  // review, Medium 2). A body carrying `consents` records the wording the
+  // founder read (resolved server-side from the same registry the renderer
+  // used, D7); a body carrying only the legacy `consent: true` literal
+  // records one grant marked unrecoverable (D11) rather than today's
+  // wording, which nobody was shown.
+  const consents = input.consents;
+  const locale = input.locale ?? "en";
+  const row = await prisma.$transaction(async (tx) => {
+    const created = await tx.projectListing.create({
+      data: {
+        siteId,
+        founderName,
+        // #5407 — the parts as sent, beside the composed line. Absent where a
+        // caller sent only a display line, which is the shape every row
+        // written before #5407 carries; nothing here ever splits that line.
+        ...(input.founderFirstName !== undefined && {
+          founderFirstName: input.founderFirstName,
+        }),
+        ...(input.founderLastName !== undefined && {
+          founderLastName: input.founderLastName,
+        }),
+        founderEmail,
+        ...(input.founderPhone !== undefined && { founderPhone: input.founderPhone }),
+        status: "draft",
+        consentAt: new Date(),
+        resumeTokenHash: hashResumeToken(resumeToken),
+        emailVerifyNonceHash: hashVerifyNonce(verifyNonce),
+        windowDays,
+      },
+      select: { id: true },
+    });
+    const subject = { siteId, subjectType: "project_listing", subjectId: created.id };
+    if (consents) {
+      await recordConsent({ ...subject, locale, config: consentConfig, consents }, tx);
+    } else {
+      await recordLegacyConsent({ ...subject, config: consentConfig }, tx);
+    }
+    return created;
+  });
+
+  return { ok: true, id: row.id, resumeToken, verifyNonce };
+}
+
+// ─── verify-email (POST, anonymous, nonce-gated) ───────────────────────────
+
+/**
+ * THE NONCE HAS NO EXPIRY, and shares the resume token's lifetime exactly: it
+ * lives until `submit` clears both digests, and an unsubmitted draft is never
+ * swept (`DRAFT_HOLDS_A_SLOT_DAYS` bounds the QUOTA a draft occupies, not the
+ * row). A resume email sitting in a mailbox for a year still verifies that
+ * draft a year later.
+ *
+ * That is acceptable rather than overlooked, and for one reason: the same
+ * message carries the resume token, so anyone who can read it can already
+ * resume and submit the draft outright. A TTL would have to cover both
+ * credentials to mean anything, and that is a change to #5048's resume
+ * contract rather than to this column.
+ *
+ * It is also NOT cleared on a successful stamp — the fallback read below
+ * needs it to answer a repeat call idempotently.
+ */
+export type VerifyProjectListingDraftEmailResult =
+  | { ok: true; value: { id: string; emailVerifiedAt: Date } }
+  | { ok: false; error: { kind: "not_found"; message: string } };
+
+/**
+ * Record that somebody who can read mail at `founderEmail` opened this
+ * draft's emailed link (#5407).
+ *
+ * THE PRECISION IN THAT SENTENCE IS DELIBERATE. It is evidence about the
+ * ADDRESS, not about the person driving the draft. Whoever posted `start`
+ * chose the address and holds the resume token, so an attacker can open a
+ * draft under a stranger's address and the platform will mail that stranger a
+ * link; if they click it, the attacker's draft is stamped. Binding the stamp
+ * to the application's CONTENT, or to `ownerUserId`, is what would close that,
+ * and neither is in this issue. What the stamp rules out is the case it was
+ * built for: a stamp obtained with no mailbox involved at all.
+ *
+ * WHAT IT PROVES, and why it takes TWO credentials. The caller must present
+ * both the draft's resume token and its verification NONCE, and only the
+ * second one carries the proof:
+ *
+ *   - the RESUME TOKEN says "you opened this draft". `start` returns it in
+ *     its own 201 body, so anyone who posted the form has it. On its own it
+ *     proves nothing about an address, and a design that stamped on it alone
+ *     would be forgeable in two HTTP calls — open a draft under a stranger's
+ *     address, take the token out of the response, present it back. That is
+ *     the design this one replaced, caught by its own security review.
+ *   - the NONCE says "you read mail sent to `founderEmail`". It is minted at
+ *     `start`, digested onto the row, and handed to nothing but
+ *     `sendListingResumeLink`. It is in no response body and no log line, and
+ *     the only place it exists outside this server is the `?verify=`
+ *     parameter of the link inside the email.
+ *
+ * The token stays in the guard anyway: it costs one term in a `where` and it
+ * means a nonce that somehow leaked alone still opens nothing.
+ *
+ * What it does NOT say is who the founder is. `ownerUserId` (#5295) is the
+ * column that carries an identity claim and still needs a signed-in user
+ * whose own address the auth system verified.
+ *
+ * WRITE-ONCE, BY COMPARE-AND-SWAP. `emailVerifiedAt: null` is in the `where`,
+ * so the stamp is the atomic transition and two concurrent openings of the
+ * same link produce one stamp between them rather than a last-writer-wins
+ * race. A repeat opening reads back the FIRST stamp, so the call is
+ * idempotent in its effect and in its answer. It is not indistinguishable —
+ * a repeat answers an older timestamp than "now" — and does not need to be:
+ * only a holder of both credentials can make the call at all, and they are
+ * the one person entitled to know when their own link was first opened.
+ *
+ * ONE ANSWER FOR EVERY FAILURE. A wrong token, a wrong nonce, a credential
+ * bound to a different listing, an unknown id and an already-submitted row
+ * are all `not_found` — exactly what `patch` and `submit` answer. The
+ * anonymous surface must not distinguish "exists but not yours" from "does
+ * not exist", and a verification route least of all: its whole input is a
+ * guessable-in-principle id and two secrets, so a distinguishable response
+ * would turn it into an oracle for which drafts exist and, worse, into a
+ * nonce-guessing feedback channel.
+ *
+ * Neither credential is ever logged, returned, or compared in application
+ * code — only their sha-256 digests reach the query.
+ */
+export async function verifyProjectListingDraftEmail(
+  id: string,
+  resumeToken: string,
+  verifyNonce: string,
+): Promise<VerifyProjectListingDraftEmailResult> {
+  const guard = {
+    id,
+    status: "draft",
+    resumeTokenHash: hashResumeToken(resumeToken),
+    emailVerifyNonceHash: hashVerifyNonce(verifyNonce),
+  };
+  const emailVerifiedAt = new Date();
+
+  const stamped = await prisma.projectListing.updateMany({
+    where: { ...guard, emailVerifiedAt: null },
+    data: { emailVerifiedAt },
   });
+  if (stamped.count > 0) return { ok: true, value: { id, emailVerifiedAt } };
 
-  return { ok: true, id: row.id, resumeToken };
+  // Zero rows means one of two things, and they answer differently: the draft
+  // is already stamped (idempotent success, carrying the FIRST stamp), or the
+  // credentials do not open this draft (`not_found`). This read is what tells
+  // them apart, and it is gated by the same four terms the write was — so it
+  // cannot report a draft the caller's credentials do not open.
+  const row = await prisma.projectListing.findFirst({
+    where: guard,
+    select: { id: true, emailVerifiedAt: true },
+  });
+  if (row?.emailVerifiedAt) {
+    return { ok: true, value: { id: row.id, emailVerifiedAt: row.emailVerifiedAt } };
+  }
+  return { ok: false, error: { kind: "not_found", message: "Draft not found" } };
 }
 
 // ─── patch (PATCH, anonymous, token-gated) ──────────────────────────────────
@@ -478,15 +844,47 @@ export type PatchProjectListingDraftResult =
         | { kind: "invalid_input"; message: string };
     };
 
+/**
+ * What `draftUpdateData` cannot read off the patch body (#5285).
+ *
+ * Both members are the SERVER's, and that is why they are a second argument
+ * rather than two more payload fields: `windowDays` is the applicant's
+ * request already clamped against the site's own maximum, and
+ * `storedSiteAnswers` is what is on the row, which the merge needs and a
+ * request body must never be able to supply.
+ */
+interface DraftUpdateContext {
+  /** The clamped window, when the patch asked for one. */
+  windowDays?: number;
+  /** The answers already stored, for the merge. */
+  storedSiteAnswers?: Record<string, string>;
+}
+
 /**
  * Translate a validated partial application into a Prisma update.
  *
  * Only the keys the caller actually sent are written: an absent key is
  * `undefined`, which Prisma omits from the UPDATE, so patching one field
  * cannot blank the nine the founder filled in on earlier steps.
+ *
+ * #5279 — THIS IS WHERE THE DISPLAY ADDRESS IS COMPOSED, and the only place.
+ * `address` is a union of the legacy display STRING and the structured PARTS
+ * (`flowAddressValueSchema`), and the two branches write different columns:
+ *
+ *   string → `address` verbatim, no part column touched. A founder who typed
+ *            a line gets that line stored exactly as typed, and a draft
+ *            written before #5279 keeps patching as it always did.
+ *   parts  → the six part columns, PLUS `address` composed from them by
+ *            `composeAddressLine`.
+ *
+ * The derivation runs ONE WAY ONLY. Nothing anywhere derives parts from a
+ * line: address parsing guesses, and a wrong guess silently corrupts the
+ * party identification a listing's privacy notice points at (#5036 D6), with
+ * nothing on the row to mark it as invented.
  */
 function draftUpdateData(
   patch: ProjectListingDraftPatchInput,
+  context: DraftUpdateContext,
 ): Prisma.ProjectListingUpdateInput {
   return {
     ...(patch.name !== undefined && { name: patch.name }),
@@ -499,11 +897,45 @@ function draftUpdateData(
     ...(patch.teamComposition !== undefined && { teamComposition: patch.teamComposition }),
     ...(patch.faqs !== undefined && { faqs: patch.faqs as unknown as Prisma.InputJsonValue }),
     ...(patch.anythingElse !== undefined && { anythingElse: patch.anythingElse }),
-    ...(patch.address !== undefined && { address: patch.address }),
+    ...(patch.address !== undefined &&
+      (typeof patch.address === "string"
+        ? { address: patch.address }
+        : {
+            address: composeAddressLine(patch.address),
+            addressLine1: patch.address.addressLine1,
+            addressLine2: patch.address.addressLine2 ?? null,
+            addressCity: patch.address.city,
+            addressRegion: patch.address.region,
+            addressPostalCode: patch.address.postalCode,
+            addressCountry: patch.address.country,
+          })),
     ...(patch.founderCompany !== undefined && { founderCompany: patch.founderCompany }),
     ...(patch.questions !== undefined && {
       questions: patch.questions as unknown as Prisma.InputJsonValue,
     }),
+    ...(patch.logoMarkUrl !== undefined && { logoMarkUrl: patch.logoMarkUrl }),
+    ...(patch.logoWordmarkUrl !== undefined && {
+      logoWordmarkUrl: patch.logoWordmarkUrl,
+    }),
+    // #5285 — the applicant's REQUEST, already clamped by the caller against
+    // the site's own `maxWindowDays`. It is written to `windowDays`, the same
+    // column `start` writes, because there is one window per listing and the
+    // screen that asks for it is the site's choice of screen, not a second
+    // field. Clamped and not refused, for the reason `startProjectListingDraft`
+    // gives: a founder who could post their own bound could post an unbounded
+    // one.
+    ...(context.windowDays !== undefined && { windowDays: context.windowDays }),
+    // #5285 — MERGED, never replaced. A founder patches one screen at a time,
+    // so a body carrying screen four's two answers must not blank screen
+    // two's. The incoming keys win; everything already stored is carried.
+    // Every incoming id was checked against the site's declarations by the
+    // compiled patch schema, so nothing undeclared can enter here.
+    ...(patch.siteAnswers !== undefined && {
+      siteAnswers: {
+        ...context.storedSiteAnswers,
+        ...patch.siteAnswers,
+      } as Prisma.InputJsonValue,
+    }),
   };
 }
 
@@ -526,7 +958,13 @@ export async function patchProjectListingDraft(
   // still answers `not_found` before any body is inspected.
   const owner = await prisma.projectListing.findFirst({
     where: { id, status: "draft", resumeTokenHash: hashResumeToken(resumeToken) },
-    select: { siteId: true },
+    // #5285 — `siteAnswers` rides this read because the write MERGES into it
+    // (a founder patches one screen at a time). It is still not the write's
+    // guard: the compare-and-swap below is, and a concurrent patch of a
+    // DIFFERENT screen can still lose its answers to this one, exactly as it
+    // can already lose a column. The store is one row's worth of one
+    // founder's own form, not a shared document.
+    select: { siteId: true, siteAnswers: true },
   });
   if (!owner) {
     return { ok: false, error: { kind: "not_found", message: "Draft not found" } };
@@ -536,6 +974,7 @@ export async function patchProjectListingDraft(
   const parsed = buildProjectListingDraftPatchSchema(
     listingConfig.wordCaps,
     listingConfig.collectedFields,
+    listingConfig.siteAnswers,
   ).safeParse(body);
   if (!parsed.success) {
     return {
@@ -548,6 +987,21 @@ export async function patchProjectListingDraft(
   }
   const patch: ProjectListingDraftPatchInput = parsed.data;
 
+  const stored = siteAnswersFromRow(owner.siteAnswers);
+  const context: DraftUpdateContext = {
+    // THE CLAMP, and the reason `requestedWindowDays` is safe to accept from
+    // an anonymous body at all (#5285). The site's `maxWindowDays` is read
+    // server-side and caps everything; the payload carries a REQUEST. A
+    // founder who could post their own bound could post an unbounded one, and
+    // this is the only place a patched window reaches a column.
+    ...(patch.requestedWindowDays !== undefined && {
+      windowDays: clampWindowDays(patch.requestedWindowDays, listingConfig),
+    }),
+    // What is on the row already, so the merge below adds to it rather than
+    // replacing it. It comes from the ROW and never from the body.
+    ...(stored !== null && { storedSiteAnswers: stored }),
+  };
+
   // A GUARDED `updateMany`, not a read-then-write: the token check and the
   // write are one statement, so a concurrent `submit` cannot flip the row to
   // `requested` in between and let this patch land on an application the
@@ -555,7 +1009,7 @@ export async function patchProjectListingDraft(
   // same compare-and-swap shape `submit` and `decideListing` already use.
   const updated = await prisma.projectListing.updateMany({
     where: { id, status: "draft", resumeTokenHash: hashResumeToken(resumeToken) },
-    data: draftUpdateData(patch),
+    data: draftUpdateData(patch, context),
   });
   if (updated.count === 0) {
     return { ok: false, error: { kind: "not_found", message: "Draft not found" } };
@@ -613,6 +1067,15 @@ function applicationFromRow(
     address: row.address,
     ...(row.founderCompany !== null && { founderCompany: row.founderCompany }),
     questions: row.questions,
+    // #5285 — the three fields that became writable. Each is optional in the
+    // application schema, so a row that never carried one simply omits it and
+    // `submit` is unaffected. `requestedWindowDays` reads back the CLAMPED
+    // `windowDays` the row actually holds, not what was asked for: the
+    // request is not stored anywhere, and re-asserting it would be asserting
+    // a number nothing ever agreed to.
+    ...(row.logoMarkUrl !== null && { logoMarkUrl: row.logoMarkUrl }),
+    ...(row.logoWordmarkUrl !== null && { logoWordmarkUrl: row.logoWordmarkUrl }),
+    ...(row.windowDays !== null && { requestedWindowDays: row.windowDays }),
   };
   return Object.fromEntries(
     Object.entries(all).filter(([key]) => collected.has(key)),
@@ -754,7 +1217,15 @@ export async function submitProjectListingDraft(
     try {
       const updated = await prisma.projectListing.updateMany({
         where: { id, status: "draft" },
-        data: { status: "requested", slug: candidate, resumeTokenHash: null },
+        // #5407 — the verification nonce is cleared here too, for the reason
+        // the resume-token digest is: a credential that leaks after the draft
+        // stops being a draft is inert twice over.
+        data: {
+          status: "requested",
+          slug: candidate,
+          resumeTokenHash: null,
+          emailVerifyNonceHash: null,
+        },
       });
       return updated.count;
     } catch (err) {
@@ -879,6 +1350,88 @@ export async function getProjectListing(siteId: string, id: string): Promise<Get
   return { ok: true, value: toResponseRow(row, waitlistCountFor(row, counts), new Date(), true) };
 }
 
+// ─── The founder's own listings (auth scope; #5295) ─────────────────────────
+
+/**
+ * The listings the CALLING USER owns, newest first.
+ *
+ * The join is the owner link and ONLY the owner link:
+ * `ownerUserId === userId`, the scalar `listing-promotion.ts` stamps once that
+ * user's own email is verified, matches the row's `founderEmail`, and the row's
+ * site resolves to one of the user's own workspaces. `founderEmail` is NEVER
+ * compared here, at any stage — an un-linked listing that happens to carry the
+ * caller's address is not theirs until a promotion said so, and a read-time
+ * email match would reintroduce exactly the cross-founder capture the link
+ * exists to remove. (`flow-checkouts.ts` draws the same line for `Lead`.)
+ *
+ * No `siteId` parameter and no `currentSiteId()` scope, deliberately — and the
+ * reason is NOT that the two can never coincide. `siteIdForPublicKey`
+ * (`listing-config.ts`) does fall back to `currentSiteId()`, so a listing's
+ * `siteId` CAN be `AILK_SITE_ID` or the literal `"default"` on a single-tenant
+ * deployment. The reason is that the owner link is already the narrower scope:
+ * it is only ever stamped for a site inside the user's own tenancy
+ * (`listing-promotion.ts`, condition 3), so adding a site term could only
+ * remove rows the caller owns — and on the multi-tenant shape, where a
+ * listing's `siteId` is a WORKSPACE id rather than `AILK_SITE_ID`, it would
+ * remove all of them. The response omits `siteId` regardless, so no workspace
+ * id leaves the read.
+ *
+ * The one thing this gives up against the sibling `/me` routes: on a database
+ * shared by more than one site, a caller's rows from every such site come back
+ * together. They are all the caller's own rows, which is why that is acceptable
+ * here and not a disclosure.
+ *
+ * No verified-email re-check either. `flow-checkouts.ts` performs one as
+ * defence in depth beside its email-matching sibling
+ * (`waitlist-signups.ts`, where the gate is load-bearing because the match IS
+ * an email). Here the link is the proof, and it was only issuable under
+ * verification — so a re-check adds no safety, while failing a caller whose
+ * address later changed to an unverified one would wrongly hide the rows they
+ * already proved they own.
+ *
+ * `waitlistCount` is resolved PER SITE: the count is keyed by
+ * `(siteId, experimentKey)`, and a founder may own listings in more than one of
+ * their own workspaces, so counting them all under one site id would report
+ * another site's number.
+ *
+ * An empty array for a caller who owns nothing is the normal answer, not an
+ * error.
+ */
+export async function listMyProjectListings(userId: string): Promise<ProjectListing[]> {
+  const rows = await prisma.projectListing.findMany({
+    where: { ownerUserId: userId },
+    orderBy: { createdAt: "desc" },
+    select: PROJECT_LISTING_SELECT,
+  });
+  if (rows.length === 0) return [];
+
+  const rowsBySite = new Map<string, ProjectListingRow[]>();
+  for (const row of rows) {
+    const forSite = rowsBySite.get(row.siteId);
+    if (forSite) forSite.push(row);
+    else rowsBySite.set(row.siteId, [row]);
+  }
+  const countsBySite = new Map<string, Map<string, number>>();
+  await Promise.all(
+    [...rowsBySite].map(async ([siteId, siteRows]) => {
+      countsBySite.set(siteId, await attachWaitlistCounts(siteId, siteRows));
+    }),
+  );
+
+  const now = new Date();
+  // `featuredEnabled: true` — the founder's own row, like the operator's
+  // dashboard row, reports the flag as stored. It is the PUBLIC shelf the
+  // site's config switch governs, not what the row's owner may see.
+  return rows.map((row) =>
+    toResponseRow(
+      row,
+      waitlistCountFor(row, countsBySite.get(row.siteId) ?? new Map()),
+      now,
+      true,
+    ),
+  );
+}
+
 // ─── Patch (tenant scope; the featured flag) ───────────────────────────────
 
 export type SetListingFeaturedResult =
@@ -1113,12 +1666,32 @@ export async function publicProjectListings(siteId: string): Promise<ProjectList
 
   const now = new Date();
   return [...top3, ...rest].map(({ row, waitlistCount }) => {
-    const { founderEmail: _founderEmail, ...publicRow } = toResponseRow(
+    // #5407 — `founderPhone` and `emailVerifiedAt` leave here with
+    // `founderEmail`. `projectListingPublicSchema` omits all three and
+    // `sendValidated` re-parses `.strict()`, so a key that stopped being
+    // dropped here would 500 the public read rather than quietly publishing a
+    // founder's phone number — which is the failure mode worth having.
+    const {
+      founderEmail: _founderEmail,
+      founderPhone: _founderPhone,
+      emailVerifiedAt: _emailVerifiedAt,
+      ...publicRow
+    } = toResponseRow(
       row,
       waitlistCount,
       now,
       listingConfig.featuredEnabled,
     );
-    return publicRow;
+    // #5285 — the `public`-visibility answers ONLY. An `operator-only` answer
+    // is something a site asked for its own triage, and a founder who was
+    // told it would not be published has to be right about that; an answer
+    // whose id the site no longer declares is dropped for the same reason,
+    // because "no declaration" cannot be read as "public" on the read that
+    // publishes. The tenant dashboard and the review payload are the audience
+    // that sees the rest, and they do not come through here.
+    return {
+      ...publicRow,
+      siteAnswers: publicSiteAnswers(publicRow.siteAnswers, listingConfig.siteAnswers),
+    };
   });
 }