create-ailk 0.1.1 → 0.3.0

package/templates/database/inbox/schema.prisma

@@ -460,10 +460,116 @@ model ProjectListing {
   // #5036 D6 — a legal control, not a contact detail: visitors answering this
   // founder's diagnostic are owed the identity and address of the party
   // collecting their data. Carried on the PUBLIC read for that reason.
+  //
+  // #5279 — still the single-line DISPLAY string. Where the six part columns
+  // below are written, this is COMPOSED from them server-side; where they are
+  // not, it is the line the founder typed, verbatim.
   address        String?
+  // #5279 — the structured parts of the address above, beside it rather than
+  // instead of it. Nullable for the same reason as the #5036 D1 block above: a
+  // row written before #5279 has no parts, and none may ever be GUESSED from
+  // its `address` string. Parts compose into a line deterministically; a line
+  // does not decompose into parts, and a wrong split silently corrupts the
+  // party identification the listing's privacy notice points at — so the
+  // migration deliberately backfills nothing and a null part stays null for
+  // the life of the row. Composition runs one way only, in `draftUpdateData`
+  // (apps/api/src/services/project-listings.ts).
+  addressLine1      String? @map("address_line1")
+  addressLine2      String? @map("address_line2")
+  addressCity       String? @map("address_city")
+  addressRegion     String? @map("address_region")
+  addressPostalCode String? @map("address_postal_code")
+  addressCountry    String? @map("address_country")
   questions      Json?
+  // #5285 — the answers to the site's OWN questions: one flat JSON object of
+  // `{ questionId: answer }` for everything a site asks that the PLATFORM does
+  // not read. The field contract (packages/validation/.../listing-
+  // application-contract.ts) names what the platform reads and therefore what
+  // earns a column; everything else was previously unaskable without a
+  // migration and a release, which is what this column removes.
+  //
+  // BOUNDED, not free-form, and that is the point: the write path is
+  // anonymous (a resume token and nothing else), so an unbounded JSON bag on
+  // it is a place for a stranger to park arbitrary text in the table. The
+  // server accepts only ids the SITE declared in its own `SiteListingConfig`,
+  // at that site's own count and length caps, and refuses the whole request
+  // otherwise — so what lands here is never larger than the questions the
+  // operator chose to ask. Null on every row written before #5285 and on
+  // every site that asks nothing of its own.
+  //
+  // Only the `public`-visibility subset rides the public read; an
+  // `operator-only` answer reaches the dashboard and the review payload and
+  // stops there.
+  siteAnswers    Json?     @map("site_answers")
+  // #5407 — still the single-line DISPLAY name, and still NOT NULL: `start`
+  // has always required one and every reader below expects one. Where the two
+  // part columns beside it are written, this is COMPOSED from them
+  // server-side (`startProjectListingDraft`); where they are not, it is the
+  // line the founder typed, verbatim.
+  //
+  // Read by: the submit-time slug fallback, the approve/reject email's
+  // greeting, the Slack review card's Founder row, the build issue, and the
+  // `routeLead` identity. None of them changes.
   founderName    String    @map("founder_name")
+  // #5407 — the structured parts of the display name above, beside it rather
+  // than instead of it, exactly as #5279 put the six address parts beside
+  // `address`. Nullable for the #5036 D1 reason and one more: a row written
+  // before #5407 has no parts, and none may ever be GUESSED from its
+  // `founder_name`. "First Last" composes one way only; a name does not
+  // decompose (a two-word split mangles "van der Berg", "Maria del Carmen"
+  // and every mononym), so the migration backfills nothing and a null part
+  // stays null for the life of the row.
+  founderFirstName String? @map("founder_first_name")
+  founderLastName  String? @map("founder_last_name")
   founderEmail   String    @map("founder_email")
+  // #5407 — the founder's phone, collected on the default contact screen
+  // alongside the email (samhenry spec 316 D1). Nullable at rest for the
+  // #5036 D1 reason AND permanently: a row written before #5407 has none, and
+  // a site may declare the question optional through its own config.
+  //
+  // NEVER on the public read: `projectListingPublicSchema` omits it beside
+  // `founderEmail`. The address on this row is a legal control a visitor is
+  // owed; a phone number is a contact detail nobody outside the operator is.
+  founderPhone   String?   @map("founder_phone")
+  // #5407 — sha-256 of the EMAIL VERIFICATION NONCE, never the nonce itself.
+  //
+  // A second credential beside `resumeTokenHash`, and the reason
+  // `emailVerifiedAt` below means what its name says. The resume token is
+  // returned to WHOEVER POSTED `start`'s FORM, so presenting it proves only
+  // that you opened the draft. This nonce is minted at `start`, digested
+  // here, and handed to nothing except the resume-email builder
+  // (`services/project-listing-resume-email.ts`): it is never in a response
+  // body, never in a log, and never in the browser that filled the form. The
+  // only way to hold it is to have read mail sent to `founder_email`.
+  //
+  // Null on every row written before #5407, and on every row whose site has
+  // not switched the resume email on — there the nonce exists and is simply
+  // never delivered, so nothing can verify, which is the correct outcome.
+  // Cleared at `submit` beside `resumeTokenHash`, for the same reason: a
+  // credential that leaks after the draft stops being a draft is inert twice
+  // over.
+  emailVerifyNonceHash String? @unique @map("email_verify_nonce_hash")
+  // #5407 — when the founder proved control of `founder_email`, by opening
+  // the link mailed to it.
+  //
+  // WRITE-ONCE. `verifyProjectListingDraftEmail` sets it only where it is
+  // still null, so a founder who opens the link five times is stamped with
+  // the FIRST opening rather than the latest.
+  //
+  // WHAT IT PROVES, and its exact limit. The stamp requires the nonce above,
+  // which left this server only inside the email. So it says the holder can
+  // read mail sent to `founder_email` — which is the whole of what "email
+  // verified" claims. It says nothing about WHO they are: `owner_user_id`
+  // (#5295) is the column that carries an identity claim, and it still needs
+  // a signed-in user whose own address the auth system verified. A row can
+  // carry either, both, or neither.
+  //
+  // Permanently nullable, and NOT a backfill target. Every row written before
+  // #5407 predates the stamp; asserting verification on one would assert
+  // exactly the thing nobody proved. Null means "not verified", never
+  // "verification failed", and it is also what a site running no resume email
+  // reads forever.
+  emailVerifiedAt DateTime? @map("email_verified_at")
   founderCompany String?   @map("founder_company")
   status         String
   // #5036 D1/D6 — when the founder ticked step one's consent box. Never null:
@@ -512,6 +618,24 @@ model ProjectListing {
   // rolls back on a Slack failure).
   slackChannel   String?   @map("slack_channel")
   slackTs        String?   @map("slack_ts")
+  // Listing -> owner-user link (#5295). Plain scalars — no cross-namespace
+  // @relation into auth.User (ADR 0009 invariant #1), exactly as
+  // `Lead.promotedUserId` / `promotedAt` above. Set by
+  // apps/api/src/services/listing-promotion.ts once the reconciling user's own
+  // email is VERIFIED, that verified address matches `founderEmail`, and this
+  // row's `siteId` resolves to one of that user's own workspaces.
+  //
+  // `founderEmail` is an UNVERIFIED string typed into an anonymous form, so it
+  // can never by itself say who owns the row: two people who type the same
+  // address are two people. This column is the only ownership claim any read
+  // may join on, and nothing derives it from `founderEmail` at read time.
+  //
+  // Nullable PERMANENTLY, not pending a backfill. A listing submitted by
+  // someone who never signs in has no owner for the life of the row, and that
+  // is a legitimate resting state: a backfill from `founderEmail` would assert
+  // a link nobody proved, which is the bug this column exists to remove.
+  ownerUserId    String?   @map("owner_user_id")
+  ownerLinkedAt  DateTime? @map("owner_linked_at")
   createdAt      DateTime  @default(now()) @map("created_at")
   updatedAt      DateTime  @updatedAt @map("updated_at")
 
@@ -521,5 +645,46 @@ model ProjectListing {
   // rows on every submit, from an anonymous route. Indexed so a stranger
   // cannot make that count a table scan.
   @@index([siteId, founderEmail])
+  // The self-scoped read's whole WHERE clause (#5295) is `{ ownerUserId }` —
+  // the owner link IS the scope, so no site term joins it. Single-column by
+  // design: the promotion match (`founderEmail` + `siteId` + null owner) is
+  // already served by the (site_id, founder_email) index above.
+  @@index([ownerUserId])
   @@map("project_listings")
 }
+
+/// ConsentGrant — one person's answer to one consent purpose, with the exact
+/// wording they read (#5275). APPEND-ONLY: current state is the newest row
+/// per (subject, purpose), so a later withdrawal never destroys the evidence
+/// of the earlier grant (D9) — no `updatedAt`, and deliberately NO unique
+/// constraint on subject + purpose. DECLINES ARE STORED as `granted: false`
+/// (D8): an absent row cannot distinguish "they said no" from "we never
+/// asked", and on an optional purpose that distinction is the only thing the
+/// record is for. The subject is a type + id pair of plain scalars
+/// (`project_listing` / `subscriber` / …) with NO cross-namespace @relation
+/// (D10, ADR 0009 invariant 1) — which is what lets a new surface adopt
+/// consent with a service call and no migration. `statement` is the resolved
+/// text DENORMALIZED at write time (D7): a pointer into the site's config row
+/// would prove nothing once that row is edited, and `statementHash` groups
+/// identical wordings. `locale` is the locale the statement was actually
+/// served in, not the one requested. `purposeId` is the site-config registry
+/// id — the join key across surfaces. Written only by
+/// apps/api/src/services/consent.ts.
+model ConsentGrant {
+  id            String   @id @default(dbgenerated("('cnsnt_'::text || (uuidv7())::text)")) @db.Text
+  siteId        String   @map("site_id")
+  subjectType   String   @map("subject_type")
+  subjectId     String   @map("subject_id")
+  purposeId     String   @map("purpose_id")
+  granted       Boolean
+  locale        String
+  statement     String   @db.Text
+  statementHash String   @map("statement_hash")
+  createdAt     DateTime @default(now()) @map("created_at")
+
+  // "What did this subject agree to" — every row for one subject, newest last.
+  @@index([siteId, subjectType, subjectId])
+  // "Who agreed to this purpose" — the cross-surface count the id exists for (D1/D2).
+  @@index([siteId, purposeId])
+  @@map("consent_grants")
+}

package/templates/database/migrations/20260911140000_listing_structured_address/migration.sql

@@ -0,0 +1,32 @@
+-- The founder's address, in structured parts, on `project_listings` (#5279).
+--
+-- The application collected a whole business address in ONE free-text box
+-- (`address`, a single line). That line is a legal control rather than a
+-- contact detail — visitors answering a founder's diagnostic are owed the
+-- identity and address of the party collecting their data (#5036 D6) — and a
+-- notice that has to name a country or a region cannot reliably find one
+-- inside a line someone typed by hand.
+--
+-- These six columns carry the parts the fieldset now collects. They sit
+-- BESIDE `address`, not instead of it: `address` remains the single-line
+-- DISPLAY string, composed server-side from these columns when they are
+-- written, and left exactly as the founder typed it when they are not.
+--
+-- Every column is nullable, and there is DELIBERATELY NO BACKFILL. Parts
+-- compose into a line deterministically; a line does not decompose into
+-- parts. Address parsing guesses, and a wrong guess — a region read as a
+-- city, a house number read as a postcode — silently corrupts the party
+-- identification a listing's privacy notice points at, with nothing on the
+-- row to mark it as invented. A null part is honest; a guessed one is not.
+-- So every existing row keeps its `address` string byte-for-byte and keeps
+-- all six parts NULL, for the life of the row.
+--
+-- No index: every read of these columns is already keyed by the listing's own
+-- primary key or by an existing (site_id, …) index, and no query filters on a
+-- part.
+ALTER TABLE "project_listings" ADD COLUMN "address_line1" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address_line2" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address_city" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address_region" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address_postal_code" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address_country" TEXT;

package/templates/database/migrations/20260911180000_consent_grants/migration.sql

@@ -0,0 +1,71 @@
+-- #5275 — ConsentGrant: one person's answer to one consent purpose, with the
+-- exact wording they read. Mirrors the shape of
+-- 20260907180000_add_listing_csv_send (CreateTable + CreateIndex immediately
+-- followed by the ADR-0031 rule-3 id-format completion applied in the SAME
+-- migration since the table is new, no retrofit needed), then the listing
+-- BACKFILL.
+--
+-- The table is APPEND-ONLY (D9): no updated_at, and deliberately NO unique
+-- constraint on (subject, purpose) — current state is the newest row per
+-- pair, so a later withdrawal never erases the earlier grant. Declines are
+-- stored as granted = false (D8). subject_type/subject_id are plain scalars
+-- with no cross-namespace FK (D10, ADR 0009). statement is denormalized (D7).
+--
+-- BACKFILL: one row per pre-existing project_listings row (D11, spec §5.3
+-- second boundary). Those founders ticked a consent box, but the system never
+-- RENDERED any statement to them — the control was a select carrying one fake
+-- option, and the client sent a hardcoded `consent: true` — so there is no
+-- per-listing wording to recover. Each backfilled row is therefore marked
+-- WORDING-UNRECOVERABLE rather than stamped with today's default statement:
+-- stamping current wording onto a grant nobody read would fabricate evidence.
+-- The sentinel is the exact `UNRECOVERABLE_CONSENT_STATEMENT` literal from
+-- apps/api/src/services/consent.ts, its hash is COMPUTED here rather than
+-- hand-typed, locale is BCP-47 `und` (undetermined), and created_at is the
+-- listing's own consent_at — the one fact about the act that IS recoverable.
+-- This migration never UPDATEs or ALTERs project_listings; consent_at is left
+-- exactly as it was (spec §2.3).
+
+-- CreateTable
+CREATE TABLE "consent_grants" (
+    "id" TEXT NOT NULL DEFAULT ('cnsnt_'::text || (uuidv7())::text),
+    "site_id" TEXT NOT NULL,
+    "subject_type" TEXT NOT NULL,
+    "subject_id" TEXT NOT NULL,
+    "purpose_id" TEXT NOT NULL,
+    "granted" BOOLEAN NOT NULL,
+    "locale" TEXT NOT NULL,
+    "statement" TEXT NOT NULL,
+    "statement_hash" TEXT NOT NULL,
+    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+
+    CONSTRAINT "consent_grants_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE INDEX "consent_grants_site_id_subject_type_subject_id_idx" ON "consent_grants"("site_id", "subject_type", "subject_id");
+
+-- CreateIndex
+CREATE INDEX "consent_grants_site_id_purpose_id_idx" ON "consent_grants"("site_id", "purpose_id");
+
+-- ADR-0031 rule 3 — consent_grants: cnsnt_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.consentGrant; this migration's
+-- path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "consent_grants" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "consent_grants" ALTER COLUMN "id" SET DEFAULT ('cnsnt_'::text || (uuidv7())::text);
+ALTER TABLE "consent_grants" ADD CONSTRAINT "consent_grants_id_format" CHECK ("id" ~ '^cnsnt_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');
+
+-- Backfill (D11): one wording-unrecoverable `service_terms` grant per
+-- pre-existing listing, stamped at the listing's own consent_at. Read-only
+-- against project_listings.
+INSERT INTO "consent_grants" ("site_id", "subject_type", "subject_id", "purpose_id", "granted", "locale", "statement", "statement_hash", "created_at")
+SELECT
+    "site_id",
+    'project_listing',
+    "id",
+    'service_terms',
+    TRUE,
+    'und',
+    '[unrecoverable: no statement was rendered by this system for this grant]',
+    encode(sha256(convert_to('[unrecoverable: no statement was rendered by this system for this grant]', 'UTF8')), 'hex'),
+    "consent_at"
+FROM "project_listings";

package/templates/database/migrations/20260911200000_listing_site_answers/migration.sql

@@ -0,0 +1,30 @@
+-- The site's own answers store on `project_listings` (#5285).
+--
+-- The founder application used to couple the platform to a QUESTION: a step
+-- kind rendered one control and wrote one column, so a site could not ask
+-- anything of its own without an upstream release. The field contract names
+-- the fields the platform actually READS — the ones that derive a slug,
+-- render a card, key the concurrency limit, build the operator's issue — and
+-- those keep their columns. Everything else a site wants to ask is editorial,
+-- and lands here instead: one JSON object of `{ questionId: answer }`.
+--
+-- BOUNDED, not free-form. The write path is ANONYMOUS — a resume token and
+-- nothing else — and an unbounded JSON bag on an anonymous surface is a place
+-- for a stranger to park arbitrary text in the table. So the server accepts
+-- only ids the site declared in its own `SiteListingConfig.data.siteAnswers`,
+-- at that site's own count and length caps, and refuses the WHOLE request
+-- otherwise: an answer for an id the site does not ask is a 400 and nothing
+-- is written. What can land in this column is therefore never larger than the
+-- questions an operator chose to ask.
+--
+-- Nullable with no default and no backfill: null means "this site asks
+-- nothing of its own", which is every existing row and every site that has
+-- declared no questions. An empty object would claim the founder was asked
+-- and answered nothing, which is a different fact.
+--
+-- No index, and no GIN index in particular. Nothing queries INTO this column:
+-- every read of it is already keyed by the listing's primary key or by an
+-- existing (site_id, …) index, and an answer the platform searched on would
+-- by definition be an answer the platform reads — which is what a contract
+-- field and a column of its own are for.
+ALTER TABLE "project_listings" ADD COLUMN "site_answers" JSONB;

package/templates/database/migrations/20260912120000_listing_owner_link/migration.sql

@@ -0,0 +1,49 @@
+-- The verified owner link on `project_listings` (#5295).
+--
+-- A listing carried `founder_email` and `lead_id` and no user link, so there
+-- was no query for "the listings belonging to this signed-in person". The only
+-- join available was a session's email against `founder_email` — and
+-- `founder_email` is an UNVERIFIED string typed into an anonymous form, so that
+-- join hands a stranger someone else's submission the first time two people
+-- type the same address. These two columns are the ownership claim instead.
+--
+-- Plain scalars, no foreign key into `users`: ADR 0009 invariant #1 forbids a
+-- relation across the namespace boundary, and `leads.promoted_user_id` /
+-- `promoted_at` (20260714000000_add_lead_promotion_fields) are the same shape
+-- for the same reason. The join is stable-id matching in the service layer.
+--
+-- `apps/api/src/services/listing-promotion.ts` is the sole writer, and it sets
+-- the pair only when all three of these hold:
+--   1. the reconciling user's OWN email is verified (`users.email_verified`) —
+--      never a claimed or session-asserted address;
+--   2. that verified address matches the row's `founder_email`;
+--   3. the row's `site_id` is one of that user's own tenant workspaces.
+-- Any one failing writes nothing.
+--
+-- NO BACKFILL, deliberately and permanently. Every existing row predates
+-- verification, so deriving `owner_user_id` from `founder_email` here would
+-- assert exactly the link nobody proved — the bug the column exists to remove.
+-- Existing rows stay null, and a listing submitted by someone who never signs
+-- in stays null for the life of the row: that is a legitimate resting state,
+-- not a backlog to clean up.
+--
+-- The index backs the self-scoped read's whole WHERE clause
+-- (`GET /v1/project-listings/me` — `owner_user_id = $1`, and nothing else: the
+-- owner link IS the scope, so no site term joins it). Single-column by design —
+-- the promotion match (`founder_email` + `site_id` + a null owner) is already
+-- served by the existing (site_id, founder_email) index.
+--
+-- Forward-additive only: both columns are nullable with no default, so every
+-- existing read and write is unaffected.
+--
+-- Rollback:
+--   DROP INDEX "project_listings_owner_user_id_idx";
+--   ALTER TABLE "project_listings" DROP COLUMN "owner_linked_at";
+--   ALTER TABLE "project_listings" DROP COLUMN "owner_user_id";
+
+-- AlterTable
+ALTER TABLE "project_listings" ADD COLUMN     "owner_user_id" TEXT,
+ADD COLUMN     "owner_linked_at" TIMESTAMP(3);
+
+-- CreateIndex
+CREATE INDEX "project_listings_owner_user_id_idx" ON "project_listings"("owner_user_id");

package/templates/database/migrations/20260914120000_listing_founder_identity/migration.sql

@@ -0,0 +1,123 @@
+-- The founder's structured identity and PROVEN email address on
+-- `project_listings` (#5407).
+--
+-- Step one of the application collected ONE `founder_name` line and an email.
+-- samhenry spec 316 D1 asks for first name, last name, email and phone, with
+-- the two name parts stored separately, and 316 D6b asks that an application
+-- whose emailed resume link was opened be marked verified so the operator can
+-- filter on it at review.
+--
+-- FIVE NULLABLE COLUMNS, NO BACKFILL, NO CHANGE TO ANY EXISTING ONE.
+--
+-- `founder_first_name` / `founder_last_name` sit BESIDE `founder_name`, not
+-- instead of it — the #5279 precedent that put six address parts beside the
+-- single-line `address`. `founder_name` stays NOT NULL and stays the DISPLAY
+-- string every existing reader already reads (the submit-time slug fallback,
+-- the approve/reject email's greeting, the Slack review card's Founder row,
+-- the build issue, the `routeLead` identity); where the parts are written the
+-- server COMPOSES it from them, and where they are not it is the line the
+-- founder typed, verbatim.
+--
+-- Composition runs ONE WAY ONLY, and that is why nothing here backfills.
+-- "First" + "Last" composes into a display line deterministically; a display
+-- line does not decompose into parts. Splitting on the last space mangles
+-- "van der Berg", "Maria del Carmen" and every mononym, and a wrong split is
+-- silent — it would put an invented surname on the row the approve email
+-- greets and the operator reviews, with nothing to mark it as invented. A
+-- null part is honest; a guessed one is not. Every existing row therefore
+-- keeps `founder_name` byte-for-byte and keeps both parts NULL for the life
+-- of the row.
+--
+-- `founder_phone` is the contact detail spec 316 D1 adds. Nullable at rest
+-- for the #5036 D1 reason — every field the submit payload requires must be
+-- storable half-filled — and nullable permanently besides: a row written
+-- before #5407 has none, and a site may declare the question optional through
+-- its own listing config. It NEVER rides the public read; the public row
+-- shape omits it beside `founder_email`.
+--
+-- `email_verify_nonce_hash` and `email_verified_at` are the verification pair,
+-- and the first is what makes the second mean what it says.
+--
+-- The obvious design is to stamp verification when the emailed resume link is
+-- opened, keyed on the resume token that link carries. That design does not
+-- work, and the reason is worth stating here because the column name does not
+-- carry it: `start` returns the resume token to WHOEVER POSTED THE FORM, in
+-- its own 201 body. The emailed link is a second copy of a credential the
+-- applicant already holds — so two HTTP calls (open a draft under a
+-- stranger's address, take the token out of the response, present it back)
+-- would forge the stamp with no mailbox involved. Caught by this PR's
+-- security review before it shipped.
+--
+-- So verification requires a SECOND credential the applicant never receives
+-- any other way. `email_verify_nonce_hash` holds the sha-256 digest of a
+-- 256-bit nonce minted at `start`, handed to nothing except the resume-email
+-- builder (apps/api/src/services/project-listing-resume-email.ts), and
+-- present in no response body and no log line. It reaches exactly one place:
+-- the `?verify=` parameter of the link inside the email. Holding it means
+-- having read mail sent to `founder_email`, which is what the stamp claims.
+--
+-- `email_verified_at` is therefore genuine evidence of address control, and
+-- is still WRITE-ONCE: the verify call sets it only where it is still NULL,
+-- by compare-and-swap, so a founder who opens the link five times is stamped
+-- with the first opening and two concurrent openings produce one stamp
+-- between them.
+--
+-- WHAT IT STILL DOES NOT SAY is who the founder is. `owner_user_id`
+-- (20260912120000_listing_owner_link) is the identity claim and needs a
+-- signed-in user whose own address the auth system verified. A row can carry
+-- either, both, or neither.
+--
+-- Neither is a backfill target. Stamping an existing row would assert exactly
+-- the event nobody recorded. NULL means "not verified", never "verification
+-- failed" — and it is also what a site that has not switched the resume email
+-- on will read forever, because the nonce is minted there and simply never
+-- delivered. That is the correct outcome, not a gap.
+--
+-- `email_verify_nonce_hash` is UNIQUE, mirroring `resume_token_hash`: two
+-- rows can never share a nonce, and the digest lookup is indexed. It is
+-- cleared at `submit` beside the resume-token digest, so a credential that
+-- leaks after the draft stops being a draft is inert twice over. It has NO
+-- EXPIRY otherwise, by design and for the reason the service records: the
+-- same message carries the resume token, so a TTL on the nonce alone would
+-- bound nothing.
+--
+-- OPERATIONAL NOTE on the index. `CREATE UNIQUE INDEX` below is not
+-- `CONCURRENTLY`, so it takes a SHARE lock and blocks writes to
+-- `project_listings` while it builds. Every existing row is NULL there and
+-- Postgres treats NULLs as distinct in a unique index (no NULLS NOT
+-- DISTINCT), so it cannot fail on existing data and builds fast — and the
+-- same property is why `submit` setting many rows back to NULL never
+-- collides. Stated so whoever runs this against a large table knows it is
+-- write-blocking DDL; it matches the `resume_token_hash` precedent.
+--
+-- Distinct from `owner_user_id` (20260912120000_listing_owner_link), which
+-- needs a SIGNED-IN user whose own address the auth system verified. This
+-- column needs no account at all: it records that a capability sent to
+-- `founder_email` came back. A row can carry either, both, or neither.
+--
+-- NO INDEX on the other four. The verify write is keyed by the row's primary
+-- key plus two digests, both already UNIQUE, and the operator filters
+-- verified applications inside a site's already-indexed page of listings
+-- (`project_listings_site_id_status_idx`) rather than by scanning on
+-- `email_verified_at`.
+--
+-- Forward-additive only: all five columns are nullable with no default, so
+-- every existing read and write is unaffected.
+--
+-- Rollback:
+--   DROP INDEX "project_listings_email_verify_nonce_hash_key";
+--   ALTER TABLE "project_listings" DROP COLUMN "email_verified_at";
+--   ALTER TABLE "project_listings" DROP COLUMN "email_verify_nonce_hash";
+--   ALTER TABLE "project_listings" DROP COLUMN "founder_phone";
+--   ALTER TABLE "project_listings" DROP COLUMN "founder_last_name";
+--   ALTER TABLE "project_listings" DROP COLUMN "founder_first_name";
+
+-- AlterTable
+ALTER TABLE "project_listings" ADD COLUMN     "founder_first_name" TEXT,
+ADD COLUMN     "founder_last_name" TEXT,
+ADD COLUMN     "founder_phone" TEXT,
+ADD COLUMN     "email_verify_nonce_hash" TEXT,
+ADD COLUMN     "email_verified_at" TIMESTAMP(3);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "project_listings_email_verify_nonce_hash_key" ON "project_listings"("email_verify_nonce_hash");

package/templates/database/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@working-theory/database",
-  "version": "0.19.0",
+  "version": "0.22.0",
   "license": "Apache-2.0",
   "publishConfig": {
     "access": "public"

package/templates/package.json

@@ -60,7 +60,7 @@
     "yaml": "^2.9.0",
     "zod": "^4.2.1",
     "zod-to-ts": "^2.1.0",
-    "@working-theory/cli": "^0.19.0"
+    "@working-theory/cli": "^0.22.0"
   },
   "lint-staged": {
     "*.{ts,tsx}": [