create-ailk 0.24.0 → 0.26.0

package/templates/apps/api/src/routes/project-listings/respond.ts

@@ -1,48 +0,0 @@
-/**
- * NOT marked `oss: false` (D-48/#5366 escalation, reversing this pass's
- * own D6 read — see `./me.ts`'s header comment): `sendValidated` is imported
- * by `./me.ts`, `./patch-draft.ts` and `./public.ts`, each of which must ship
- * unconditionally because `./index.ts`'s multi-tenant literal `import()`
- * forces it. A file imported by an always-shipping file cannot itself be
- * excluded — this is the ORIGINAL multi-tenant/#5088 card's own conclusion
- * about this exact file (module-architecture.ts lines 569-571), which D6's
- * "every other consumer is Pro Plus" premise doesn't override: two of its
- * three non-tenant consumers are these three always-shipping files, not a
- * gated one.
- *
- * Response-schema validation for the project-listings routes (#4998),
- * mirroring `waitlist-experiments/respond.ts`'s discipline: response schemas
- * are contract-only unless re-parsed against their own `.strict()` schema
- * before the value leaves the process. A shape drift here is a genuine
- * internal error (the service layer already guards every field), never a
- * client-facing 4xx.
- */
-import { logger } from "@working-theory/observability";
-import type { FastifyReply } from "fastify";
-import type { z } from "zod";
-
-/**
- * Parse `data` against `schema`; on success send the ORIGINAL `data` object
- * (not the parsed clone) at `200`, matching the waitlist-experiments
- * envelope. On failure, log the zod issues (never the raw `data`, which may
- * carry founder PII) and reply `500`.
- */
-export function sendValidated<T>(
-  reply: FastifyReply,
-  schema: z.ZodType<T>,
-  data: T,
-  routeName: string,
-): FastifyReply {
-  const parsed = schema.safeParse(data);
-  if (!parsed.success) {
-    logger.error(
-      { route: routeName, issues: parsed.error.issues },
-      "[project-listings] response failed its own contract schema",
-    );
-    return reply.status(500).send({
-      ok: false,
-      error: { code: "internal_error", message: "Response failed contract validation" },
-    });
-  }
-  return reply.status(200).send({ ok: true, data });
-}

package/templates/apps/api/src/routes/project-listings/resume-token.ts

@@ -1,27 +0,0 @@
-/**
- * NOT marked `oss: false` — see `./me.ts`'s header comment (D-48/#5366
- * escalation): imported only by `./patch-draft.ts` and `./submit.ts`, both
- * of which ship unconditionally (`./index.ts`'s multi-tenant literal
- * `import()`), so this file cannot be excluded either.
- *
- * The resume token's transport (#5036 D1).
- *
- * `start` hands the client an opaque token; `patch` and `submit` present it
- * back. It travels in the `Authorization: Bearer` header rather than in the
- * body or the query string for two reasons that matter on an anonymous
- * surface: a query parameter lands in access logs, proxy logs and
- * `Referer` headers, and a body field cannot be sent on a future GET. The
- * header is where a credential belongs, and these routes sit in `leadsScope`
- * where no auth preHandler runs, so nothing else in the stack reads it.
- */
-import type { FastifyRequest } from "fastify";
-
-const BEARER = /^Bearer (.+)$/;
-
-/** The presented token, or null when the header is absent or malformed. */
-export function resumeTokenFrom(request: FastifyRequest): string | null {
-  const header = request.headers.authorization;
-  if (typeof header !== "string") return null;
-  const match = BEARER.exec(header.trim());
-  return match ? match[1]! : null;
-}

package/templates/apps/api/src/routes/project-listings/start.ts

@@ -1,140 +0,0 @@
-/**
- * NOT marked `oss: false` — see `./me.ts`'s header comment (D-48/#5366
- * escalation: `./index.ts` is a mixed barrel multi-tenant's `server.ts`
- * reaches by a literal, always-resolved `import()`; this file ships
- * unconditionally, registration stays gated).
- *
- * POST /v1/project-listings
- *
- * `start` — step one of the application (#5036 D1). Anonymous, registered in
- * the same rate-limited `leadsScope` as `/v1/leads/*`. Validates with
- * `projectListingStartSchema` (the founder's name, email and consent, and
- * optionally a requested window) and writes the `ProjectListing` row at
- * `status: "draft"`. Returns 201 `{ ok: true, data: { id, resumeToken } }`.
- *
- * NO Lead is written here. The founder's contact details are already captured
- * on the listing row itself at step one, so a Lead would add no capture — and
- * `routeLead` sends an operator notification, which on an anonymous route
- * means a stranger could mail the operator by opening a draft they never
- * finish (PR #5042 security review, finding 4). `submit` writes the Lead.
- *
- * This route REPLACES the single anonymous create. The application became a
- * ten-step form that saves on every advance, so the create had to split into
- * start / patch / submit; validation moved with it, from write-time to
- * submit-time. Nothing here asserts the application is complete, because at
- * step one it never is.
- *
- * The response body is the ONLY place the resume token is ever readable: the
- * server stores a digest of it. A client that loses it has lost the draft.
- *
- * NO `siteId` (#5048 D2). The payload names the site by its PUBLIC KEY and
- * this route resolves the id through `siteIdForPublicKey` — a body-supplied
- * tenant identifier is exactly what the consuming site's proxy route existed
- * to prevent, and the resolution moving here is what lets that route go away.
- * An unknown key is a 400; it never falls back to the deployment's own site.
- *
- * NO `slug`, and no site config values (#5033 D1/D2): the slug is derived from
- * `name` at submit, and the site's window bounds are read server-side. The
- * applicant may REQUEST a window; the server clamps it rather than rejecting
- * the application, because a founder who could post their own bound could post
- * an unbounded one.
- *
- * PII-safe logging (mirrors `routes/leads/index.ts`): routing metadata only —
- * never founderEmail, founderName, or the resume token.
- *
- * SENDS THE RESUME EMAIL (#5406), fire-and-forget, after the row exists. The
- * 201 below is never delayed or failed by it: `sendListingResumeLink` returns
- * `void` and swallows everything, exactly as `sendListingDecisionEmail`'s
- * `fileIssueOnApprove` does on the approve path. The email is OPT-IN — a site
- * whose `SiteListingConfig` carries no `resumeEmail.fromAddress` gets none, so
- * a site sending its own today does not start sending two — and the request
- * and response shapes of this hard-floor route are unchanged.
- *
- * THE EMAIL IS ALSO THE ONLY CARRIER OF THE VERIFICATION NONCE (#5407).
- * `startProjectListingDraft` mints it, stores only its digest, and returns it
- * as a SIBLING of the result — never inside the value parsed below, because
- * `projectListingStartResponseSchema` is this route's hard-floor contract and
- * carries `id` and `resumeToken` and nothing else. The nonce reaches
- * `sendListingResumeLink` from a local variable and goes nowhere else: not
- * into the response, not into the log line above it. That is precisely what
- * makes `email_verified_at` mean something the resume token alone could not
- * prove — see `verifyProjectListingDraftEmail`.
- *
- * The response uses the API's own `{ ok, data }` / `{ ok, error }` envelope
- * (`apps/api/CLAUDE.md`) on BOTH the success and the failure path — the
- * anonymous create it replaces answered bare on success and enveloped on
- * failure, so a client branching on `body.ok` read a success as a failure.
- */
-import {
-  projectListingStartResponseSchema,
-  projectListingStartSchema,
-} from "@working-theory/validation";
-import type { FastifyPluginAsync } from "fastify";
-
-import { siteIdForPublicKey } from "../../services/listing-config.js";
-import { sendListingResumeLink } from "../../services/project-listing-resume-email.js";
-import { startProjectListingDraft } from "../../services/project-listings.js";
-
-export const startProjectListingRoute: FastifyPluginAsync = async (fastify) => {
-  fastify.post("/v1/project-listings", async (request, reply) => {
-    const parsed = projectListingStartSchema.safeParse(request.body);
-    if (!parsed.success) {
-      return reply.status(400).send({
-        ok: false,
-        error: {
-          code: "invalid_input",
-          message: parsed.error.issues[0]?.message ?? "invalid input",
-        },
-      });
-    }
-
-    // #5048 D2 — the site is resolved SERVER-SIDE from the payload's public
-    // key. The body never carries a `siteId`, and `projectListingStartSchema`
-    // is `.strict()`, so a body that still does is the 400 above naming the
-    // unrecognised key rather than a silently-honoured tenant override. This
-    // is the one property the consuming site's proxy route existed to
-    // guarantee, and resolving it here is what lets that route go away.
-    //
-    // An unknown key is a 400 and never falls back to the deployment's own
-    // site: a typo would otherwise file one site's applications against
-    // another with nothing to notice it.
-    const siteId = await siteIdForPublicKey(parsed.data.siteKey);
-    if (siteId === null) {
-      return reply.status(400).send({
-        ok: false,
-        error: { code: "unknown_site_key", message: "Unknown site key" },
-      });
-    }
-
-    const result = await startProjectListingDraft(siteId, parsed.data);
-    // #5275 — a `consents` map declining a REQUIRED purpose contradicts the
-    // body's own `consent: true`; no row was created.
-    if (!result.ok) {
-      // #6203 — `tenant_unresolved` is a server-side tenancy
-      // misconfiguration (the resolved `siteId` names no workspace this
-      // database holds), not a client input problem — 503, never 400.
-      const status = result.error.kind === "tenant_unresolved" ? 503 : 400;
-      return reply.status(status).send({
-        ok: false,
-        error: { code: result.error.kind, message: result.error.message },
-      });
-    }
-
-    request.log.info(
-      { siteId, listingId: result.id, ip: request.ip },
-      "project listing draft started",
-    );
-
-    // #5406 — the founder's way back to this draft. NOT awaited: the 201 must
-    // not wait on Resend, and must not fail if Resend does. Both credentials
-    // are handed over here and neither is ever logged — they ride the link
-    // inside the email, and the #5407 nonce rides NOTHING ELSE anywhere.
-    sendListingResumeLink(result.id, result.resumeToken, result.verifyNonce);
-
-    const body = projectListingStartResponseSchema.parse({
-      id: result.id,
-      resumeToken: result.resumeToken,
-    });
-    return reply.status(201).send({ ok: true, data: body });
-  });
-};

package/templates/apps/api/src/routes/project-listings/submit.ts

@@ -1,130 +0,0 @@
-/**
- * NOT marked `oss: false` — see `./me.ts`'s header comment (D-48/#5366
- * escalation: `./index.ts` is a mixed barrel multi-tenant's `server.ts`
- * reaches by a literal, always-resolved `import()`; this file ships
- * unconditionally, registration stays gated).
- *
- * POST /v1/project-listings/drafts/:id/submit
- *
- * `submit` — the moment an application stops being a draft (#5036 D1).
- * Anonymous, token-gated, registered in the rate-limited `leadsScope`.
- *
- * It carries NO body. Everything it validates is already on the row, put
- * there by ten steps of `patch`, and the server assembles and validates it
- * against `projectListingSubmitSchema`. An incomplete draft comes back `422`
- * with the offending fields NAMED, so the form can send the founder back to
- * the step that owns each one rather than saying "something is missing".
- *
- * Three server-side rules bind here and only here: completeness; the
- * concurrent-listing limit (`409 listing_limit_reached` — at most two
- * non-terminal listings per founder, drafts included, #5036 D7); and the
- * slug, derived from `name` at last (#5033 D2) and returned in the response,
- * which is the only place a caller learns it.
- *
- * The Lead write also happens here rather than at step one, via `routeLead` —
- * so an anonymous stranger cannot cause an operator notification by opening a
- * draft they never finish (PR #5042 security review, finding 4). The Slack
- * notification fires AFTER the transition, never before, and never fails a
- * submit that already succeeded (`postListingApplication` never throws). Both
- * moved here from the old create route because this — not step one — is the
- * moment an operator has an application worth looking at.
- *
- * Every response uses the API's own `{ ok, data }` / `{ ok, error }` envelope
- * (`apps/api/CLAUDE.md`), success included.
- */
-import { zProjectListingId } from "@working-theory/ids";
-import { projectListingSubmitResponseSchema } from "@working-theory/validation";
-import type { FastifyPluginAsync } from "fastify";
-import { z } from "zod";
-
-import { submitProjectListingDraft } from "../../services/project-listings.js";
-import { postListingApplication } from "../../services/slack-notify.js";
-
-import { resumeTokenFrom } from "./resume-token.js";
-
-const paramsSchema = z.object({ id: zProjectListingId });
-
-export const submitProjectListingRoute: FastifyPluginAsync = async (fastify) => {
-  fastify.post("/v1/project-listings/drafts/:id/submit", async (request, reply) => {
-    const parsedParams = paramsSchema.safeParse(request.params);
-    if (!parsedParams.success) {
-      return reply.status(400).send({
-        ok: false,
-        error: { code: "validation_failed", message: "Invalid project listing id" },
-      });
-    }
-
-    const resumeToken = resumeTokenFrom(request);
-    if (resumeToken === null) {
-      return reply.status(401).send({
-        ok: false,
-        error: { code: "unauthorized", message: "A resume token is required" },
-      });
-    }
-
-    const sourceMeta = {
-      ip: request.ip,
-      userAgent: request.headers["user-agent"],
-      receivedAt: new Date().toISOString(),
-    };
-
-    const result = await submitProjectListingDraft(
-      parsedParams.data.id,
-      resumeToken,
-      sourceMeta,
-    );
-
-    if (!result.ok) {
-      if (result.error.kind === "not_found") {
-        return reply.status(404).send({
-          ok: false,
-          error: { code: "not_found", message: "Draft not found" },
-        });
-      }
-      if (result.error.kind === "incomplete") {
-        return reply.status(422).send({
-          ok: false,
-          error: {
-            code: "incomplete_application",
-            message: result.error.message,
-            missingFields: result.error.missingFields,
-          },
-        });
-      }
-      if (result.error.kind === "listing_limit_reached") {
-        return reply.status(409).send({
-          ok: false,
-          error: { code: "listing_limit_reached", message: result.error.message },
-        });
-      }
-      return reply.status(409).send({
-        ok: false,
-        error: { code: "slug_taken", message: result.error.message },
-      });
-    }
-
-    request.log.info(
-      { siteId: result.listing.siteId, slug: result.slug, ip: request.ip },
-      "project listing applied",
-    );
-
-    // Awaited (not fire-and-forget) so it can't be killed mid-flight by a
-    // serverless runtime tearing down after the response.
-    await postListingApplication({
-      id: result.listing.id,
-      name: result.listing.name,
-      oneLiner: result.listing.oneLiner,
-      problem: result.listing.problem,
-      url: result.listing.url,
-      product: result.listing.product,
-      founderName: result.listing.founderName,
-      founderCompany: result.listing.founderCompany,
-      // #7522 D5 — the actions block names the listing's workspace; `siteId`
-      // IS the workspace id (the `project_listings_workspace_site_agree` CHECK).
-      workspaceId: result.listing.siteId,
-    });
-
-    const body = projectListingSubmitResponseSchema.parse({ id: result.id, slug: result.slug });
-    return reply.status(200).send({ ok: true, data: body });
-  });
-};

package/templates/apps/api/src/routes/project-listings/verify-email.ts

@@ -1,150 +0,0 @@
-/**
- * POST /v1/project-listings/drafts/:id/verify-email
- *
- * Records that the founder proved control of `founderEmail`, by opening the
- * resume link emailed at step one (#5407). Anonymous, credential-gated,
- * registered in the same rate-limited `leadsScope` as the other three
- * anonymous listing routes.
- *
- * WHY THE ROUTE EXISTS. The resume email (#5406) tells the founder to "verify
- * your email and continue", and until this route nothing made that sentence
- * true: `ListingApplicationFlow` rehydrated from `?draft=&token=` entirely in
- * the browser and touched the server only on the NEXT advance — so a founder
- * who opened the link and closed the tab left no record, and the operator had
- * no way to tell a proved address from a typed one at review (samhenry spec
- * 316 D6b).
- *
- * WHAT IT PROVES. That somebody who can read mail at `founderEmail` opened
- * this link — evidence about the ADDRESS, not about who is driving the draft
- * (`verifyProjectListingDraftEmail` carries the full note). It takes
- * TWO credentials and only the second carries that: the `Authorization:
- * Bearer` resume token says "you opened this draft" (it is in `start`'s own
- * 201 body, so anyone who posted the form has it), and the `verifyNonce` in
- * the body says "you read the email" — it is minted at `start`, digested onto
- * the row, and handed to nothing but the resume-email builder, reaching the
- * outside world only as the `?verify=` parameter inside the message. Keying
- * this route on the resume token ALONE was the first design and was
- * forgeable in two HTTP calls; `verifyProjectListingDraftEmail` carries the
- * full note.
- *
- * It still says nothing about WHO the founder is. `ownerUserId` (#5295) is
- * the column that carries an identity claim.
- *
- * A SITE THAT SENDS NO RESUME EMAIL CAN NEVER VERIFY, and that is correct:
- * the nonce is minted on every draft but delivered only by the email, so
- * where `SiteListingConfig` carries no `resumeEmail` the column stays null
- * forever — nobody has read anything at that address.
- *
- * IDEMPOTENT, AND WRITE-ONCE. The service stamps by compare-and-swap on
- * `emailVerifiedAt: null`, so a founder who opens the link five times is
- * stamped once and every call answers with that FIRST stamp.
- *
- * THE ERROR SURFACE IS `patch`'s AND `submit`'s, deliberately unchanged: a
- * malformed id or a body that is not `{ verifyNonce }` is `400
- * validation_failed`, a missing or malformed `Authorization: Bearer` is `401
- * unauthorized`, and a WRONG token, a WRONG nonce, a credential bound to
- * another listing, an unknown id and an already-submitted row are all one
- * `404 not_found`. The 400s describe the REQUEST's shape and reveal nothing
- * about any row; everything that depends on a row is the single 404. An
- * anonymous surface must not distinguish "exists but not yours" from "does
- * not exist", and this route least of all — a distinguishable answer would
- * make it both an oracle for which drafts exist and a guessing channel for
- * the nonce.
- *
- * THE NONCE TRAVELS IN THE BODY, not the query string, for the reason
- * `resume-token.ts` gives about the resume token: a query parameter lands in
- * access logs, proxy logs and `Referer` headers. The claim is about THIS hop
- * only, and it is worth being exact about that — the nonce's DELIVERY hop is
- * itself a query parameter on the consuming site's URL, so it lands in that
- * site's own access logs exactly as the resume token does. What the body
- * placement buys is that the API's logs and any proxy between the browser and
- * this server never see it. The resume token keeps its `Authorization:
- * Bearer` header. Neither credential is ever logged and neither is ever
- * returned.
- */
-import { zProjectListingId } from "@working-theory/ids";
-import { projectListingVerifyEmailResponseSchema } from "@working-theory/validation";
-import type { FastifyPluginAsync } from "fastify";
-import { z } from "zod";
-
-import { verifyProjectListingDraftEmail } from "../../services/project-listings.js";
-
-import { sendValidated } from "./respond.js";
-import { resumeTokenFrom } from "./resume-token.js";
-
-const paramsSchema = z.object({ id: zProjectListingId });
-
-/**
- * The nonce, as the emailed link carried it. Bounded so an oversized body is
- * refused before any digest is computed; the value is 256 bits of CSPRNG
- * output in base64url, which is 43 characters.
- */
-const bodySchema = z.object({ verifyNonce: z.string().min(1).max(256) }).strict();
-
-export const verifyProjectListingDraftEmailRoute: FastifyPluginAsync = async (
-  fastify,
-) => {
-  fastify.post(
-    "/v1/project-listings/drafts/:id/verify-email",
-    async (request, reply) => {
-      const parsedParams = paramsSchema.safeParse(request.params);
-      if (!parsedParams.success) {
-        return reply.status(400).send({
-          ok: false,
-          error: { code: "validation_failed", message: "Invalid project listing id" },
-        });
-      }
-
-      const resumeToken = resumeTokenFrom(request);
-      if (resumeToken === null) {
-        return reply.status(401).send({
-          ok: false,
-          error: { code: "unauthorized", message: "A resume token is required" },
-        });
-      }
-
-      // The message names the FIELD, never whether the value would have
-      // matched — that distinction is the 404's, below.
-      const parsedBody = bodySchema.safeParse(request.body);
-      if (!parsedBody.success) {
-        return reply.status(400).send({
-          ok: false,
-          error: {
-            code: "validation_failed",
-            message: "A verification nonce is required",
-          },
-        });
-      }
-
-      const result = await verifyProjectListingDraftEmail(
-        parsedParams.data.id,
-        resumeToken,
-        parsedBody.data.verifyNonce,
-      );
-      if (!result.ok) {
-        return reply.status(404).send({
-          ok: false,
-          error: { code: "not_found", message: "Draft not found" },
-        });
-      }
-
-      // Routing metadata only, the same PII boundary `start` documents: the
-      // listing id and the caller's ip, never the founder's email and never
-      // the token.
-      request.log.info(
-        { listingId: result.value.id, ip: request.ip },
-        "project listing draft email verified",
-      );
-
-      return sendValidated(
-        reply,
-        projectListingVerifyEmailResponseSchema,
-        {
-          id: result.value.id,
-          emailVerifiedAt: result.value.emailVerifiedAt.toISOString(),
-        },
-        "verify-email",
-      );
-    },
-  );
-};