create-ailk 0.1.0 → 0.2.0

package/templates/database/migrations/20260904000000_add_waitlist_followup_send/migration.sql

@@ -0,0 +1,30 @@
+-- #4732 — WaitlistFollowUpSend: the audit stamp for one attempted follow-up
+-- email. Mirrors the shape of 20260903010000_add_playbook_instance
+-- (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).
+
+-- CreateTable
+CREATE TABLE "waitlist_followup_sends" (
+    "id" TEXT NOT NULL DEFAULT ('wlfu_'::text || (uuidv7())::text),
+    "site_id" TEXT NOT NULL,
+    "lead_id" TEXT NOT NULL,
+    "follow_up_key" TEXT NOT NULL,
+    "sent_at" TIMESTAMP(3) NOT NULL,
+    "status" TEXT NOT NULL,
+
+    CONSTRAINT "waitlist_followup_sends_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "waitlist_followup_sends_lead_id_follow_up_key_key" ON "waitlist_followup_sends"("lead_id", "follow_up_key");
+
+-- CreateIndex
+CREATE INDEX "waitlist_followup_sends_site_id_idx" ON "waitlist_followup_sends"("site_id");
+
+-- ADR-0031 rule 3 — waitlist_followup_sends: wlfu_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.waitlistFollowUpSend; this
+-- migration's path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "waitlist_followup_sends" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "waitlist_followup_sends" ALTER COLUMN "id" SET DEFAULT ('wlfu_'::text || (uuidv7())::text);
+ALTER TABLE "waitlist_followup_sends" ADD CONSTRAINT "waitlist_followup_sends_id_format" CHECK ("id" ~ '^wlfu_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');

package/templates/database/migrations/20260905230000_add_flow_checkout/migration.sql

@@ -0,0 +1,47 @@
+-- #4837 — FlowCheckout: the recommender buyer record, one row per checkout
+-- attempt. Mirrors the shape of 20260904000000_add_waitlist_followup_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).
+
+-- CreateTable
+CREATE TABLE "flow_checkouts" (
+    "id" TEXT NOT NULL DEFAULT ('flchk_'::text || (uuidv7())::text),
+    "site_id" TEXT NOT NULL,
+    "flow_slug" TEXT NOT NULL,
+    "experiment_key" TEXT NOT NULL,
+    "session_id" TEXT NOT NULL,
+    "lead_id" TEXT NOT NULL,
+    "offer_key" TEXT NOT NULL,
+    "seats" INTEGER NOT NULL,
+    "period" TEXT NOT NULL,
+    "credit_stop" JSONB NOT NULL,
+    "amount_minor" INTEGER NOT NULL,
+    "currency" TEXT NOT NULL,
+    "quote" JSONB NOT NULL,
+    "permalink" TEXT NOT NULL,
+    "stripe_session_id" TEXT,
+    "stripe_customer_id" TEXT,
+    "status" TEXT NOT NULL,
+    "completed_at" TIMESTAMP(3),
+    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updated_at" TIMESTAMP(3) NOT NULL,
+
+    CONSTRAINT "flow_checkouts_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "flow_checkouts_stripe_session_id_key" ON "flow_checkouts"("stripe_session_id");
+
+-- CreateIndex
+CREATE INDEX "flow_checkouts_site_id_experiment_key_status_idx" ON "flow_checkouts"("site_id", "experiment_key", "status");
+
+-- CreateIndex
+CREATE INDEX "flow_checkouts_lead_id_idx" ON "flow_checkouts"("lead_id");
+
+-- ADR-0031 rule 3 — flow_checkouts: flchk_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.flowCheckout; this migration's
+-- path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "flow_checkouts" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "flow_checkouts" ALTER COLUMN "id" SET DEFAULT ('flchk_'::text || (uuidv7())::text);
+ALTER TABLE "flow_checkouts" ADD CONSTRAINT "flow_checkouts_id_format" CHECK ("id" ~ '^flchk_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');

package/templates/database/migrations/20260906000000_add_flow_checkout_idempotency/migration.sql

@@ -0,0 +1,16 @@
+-- #4912 (REL-013.2 H2) — FlowCheckout idempotency: the server-derived
+-- fingerprint one checkout attempt is keyed by, plus the hosted Checkout page
+-- URL an identical resubmission is replayed with. Mirrors the column-add shape
+-- of 20260903004112_add_flow_session_flags_aeo_score (one AlterTable under an
+-- `-- AlterTable` header).
+--
+-- Both columns are nullable, so no pre-existing row needs a backfill and none
+-- collides on the new unique — Postgres treats NULLs as distinct, the same
+-- property the existing flow_checkouts_stripe_session_id_key relies on.
+
+-- AlterTable
+ALTER TABLE "flow_checkouts" ADD COLUMN     "checkout_url" TEXT,
+ADD COLUMN     "idempotency_key" TEXT;
+
+-- CreateIndex
+CREATE UNIQUE INDEX "flow_checkouts_site_id_idempotency_key_key" ON "flow_checkouts"("site_id", "idempotency_key");

package/templates/database/migrations/20260907120000_add_project_listing/migration.sql

@@ -0,0 +1,47 @@
+-- #4998 — ProjectListing: the founder's application row for the
+-- project-listings workflow (apply -> Slack approve/reject -> build issue ->
+-- data-driven page + diagnostic -> weekly CSV). Mirrors the shape of
+-- 20260905230000_add_flow_checkout (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).
+
+-- CreateTable
+CREATE TABLE "project_listings" (
+    "id" TEXT NOT NULL DEFAULT ('prjl_'::text || (uuidv7())::text),
+    "site_id" TEXT NOT NULL,
+    "lead_id" TEXT NOT NULL,
+    "slug" TEXT NOT NULL,
+    "name" TEXT NOT NULL,
+    "one_liner" TEXT NOT NULL,
+    "audience" TEXT NOT NULL,
+    "problem" TEXT NOT NULL,
+    "url" TEXT,
+    "stage" TEXT NOT NULL,
+    "questions" JSONB NOT NULL,
+    "founder_name" TEXT NOT NULL,
+    "founder_email" TEXT NOT NULL,
+    "founder_company" TEXT,
+    "status" TEXT NOT NULL,
+    "decided_at" TIMESTAMP(3),
+    "decided_by" TEXT,
+    "issue_url" TEXT,
+    "experiment_id" TEXT,
+    "backlink_until" TIMESTAMP(3),
+    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updated_at" TIMESTAMP(3) NOT NULL,
+
+    CONSTRAINT "project_listings_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "project_listings_site_id_slug_key" ON "project_listings"("site_id", "slug");
+
+-- CreateIndex
+CREATE INDEX "project_listings_site_id_status_idx" ON "project_listings"("site_id", "status");
+
+-- ADR-0031 rule 3 — project_listings: prjl_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.projectListing; this
+-- migration's path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "project_listings" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "project_listings" ALTER COLUMN "id" SET DEFAULT ('prjl_'::text || (uuidv7())::text);
+ALTER TABLE "project_listings" ADD CONSTRAINT "project_listings_id_format" CHECK ("id" ~ '^prjl_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');

package/templates/database/migrations/20260907130000_add_project_listing_slack_columns/migration.sql

@@ -0,0 +1,10 @@
+-- #4999 — ProjectListing Slack message coordinates: the posted application
+-- message's channel + ts, stamped right after `chat.postMessage` succeeds so
+-- the Approve/Reject decision handler can `chat.update` the SAME message in
+-- place. Mirrors the column-add shape of 20260906000000_add_flow_checkout_idempotency
+-- (one AlterTable, both columns nullable — no backfill, no pre-existing row
+-- collides).
+
+-- AlterTable
+ALTER TABLE "project_listings" ADD COLUMN     "slack_channel" TEXT,
+ADD COLUMN     "slack_ts" TEXT;

package/templates/database/migrations/20260907180000_add_listing_csv_send/migration.sql

@@ -0,0 +1,26 @@
+-- #5001 — ListingCsvSend: the weekly founder-CSV send stamp, one row per
+-- DELIVERED CSV for one project listing. Mirrors the shape of
+-- 20260904000000_add_waitlist_followup_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).
+
+-- CreateTable
+CREATE TABLE "listing_csv_sends" (
+    "id" TEXT NOT NULL DEFAULT ('lcsv_'::text || (uuidv7())::text),
+    "listing_id" TEXT NOT NULL,
+    "sent_at" TIMESTAMP(3) NOT NULL,
+    "row_count" INTEGER NOT NULL,
+    "grant_id" TEXT NOT NULL,
+
+    CONSTRAINT "listing_csv_sends_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE INDEX "listing_csv_sends_listing_id_sent_at_idx" ON "listing_csv_sends"("listing_id", "sent_at");
+
+-- ADR-0031 rule 3 — listing_csv_sends: lcsv_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.listingCsvSend; this migration's
+-- path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "listing_csv_sends" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "listing_csv_sends" ALTER COLUMN "id" SET DEFAULT ('lcsv_'::text || (uuidv7())::text);
+ALTER TABLE "listing_csv_sends" ADD CONSTRAINT "listing_csv_sends_id_format" CHECK ("id" ~ '^lcsv_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');

package/templates/database/migrations/20260909120000_project_listings_platform/migration.sql

@@ -0,0 +1,90 @@
+-- #5033 — project listings become a platform feature.
+--
+-- Two things happen here. A new per-SITE config table takes the listing-window
+-- bounds and the featured switch out of the published package, where one
+-- site's ninety-day/twenty-one-day commercial terms had been compiled in as a
+-- constant. And `project_listings` gains the presentation columns a listing
+-- card needs, renames its window column, and remaps its status vocabulary to
+-- the five-state lifecycle whose fifth state is never stored.
+--
+-- Ordering matters below: the status remaps run oldest-value-first so no row
+-- is rewritten twice, and the `closed` remap runs LAST because it is the one
+-- that reads the column the earlier statements leave alone.
+
+-- ─── SiteListingConfig ──────────────────────────────────────────────────────
+-- The fourth site-config table, shaped exactly like workspace_themes /
+-- workspace_site_identities / workspace_seos: one @unique key over a
+-- Zod-validated JSON blob. Keyed on site_id rather than workspace_id because
+-- the listing create path is anonymous — at create time there is no workspace
+-- to resolve.
+
+-- CreateTable
+CREATE TABLE "site_listing_configs" (
+    "id" TEXT NOT NULL DEFAULT ('sltcfg_'::text || (uuidv7())::text),
+    "site_id" TEXT NOT NULL,
+    "data" JSONB NOT NULL,
+    "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updated_at" TIMESTAMPTZ NOT NULL,
+
+    CONSTRAINT "site_listing_configs_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "site_listing_configs_site_id_key" ON "site_listing_configs"("site_id");
+
+-- ADR-0031 rule 3 — site_listing_configs: sltcfg_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.siteListingConfig; this
+-- migration's path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "site_listing_configs" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "site_listing_configs" ALTER COLUMN "id" SET DEFAULT ('sltcfg_'::text || (uuidv7())::text);
+ALTER TABLE "site_listing_configs" ADD CONSTRAINT "site_listing_configs_id_format" CHECK ("id" ~ '^sltcfg_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');
+
+-- ─── project_listings: the window column rename ─────────────────────────────
+-- RENAME, not drop-and-add: the column already carries an approve-time stamp
+-- on every approved row, and those stamps are what the computed `closed`
+-- status is read from. Dropping it would lose every live listing's expiry.
+-- The name changes because the field now bounds the whole listing rather than
+-- a backlink.
+ALTER TABLE "project_listings" RENAME COLUMN "backlink_until" TO "window_ends_at";
+
+-- ─── project_listings: the new columns ──────────────────────────────────────
+-- `window_days` is the applicant's requested window, already clamped at create
+-- against the site's config, and spent at approval. Null on every pre-existing
+-- row: a listing still awaiting a decision when this ships takes the site's
+-- configured default instead (see `windowDaysFor` in
+-- apps/api/src/services/project-listing-decision.ts).
+-- The two logo columns ship nullable with NO upload path — there is no storage
+-- dependency in this repo and no route writes them yet. They are useful null:
+-- a card with both absent renders a designed name-only treatment.
+ALTER TABLE "project_listings" ADD COLUMN "headline" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "logo_mark_url" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "logo_wordmark_url" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "featured" BOOLEAN NOT NULL DEFAULT false;
+ALTER TABLE "project_listings" ADD COLUMN "window_days" INTEGER;
+
+-- ─── project_listings: the status remap ─────────────────────────────────────
+-- Every existing value maps, and nothing is left holding a value the new
+-- vocabulary does not contain:
+--
+--   applied   -> requested   (a rename; same meaning)
+--   approved  -> active      ) collapsed: approval starts the clock, so these
+--   live      -> active      ) were always the same moment
+--   rejected  -> rejected    (unchanged)
+--   closed    -> active, with window_ends_at forced into the past
+--
+-- `closed` is not a stored value any more. A previously-closed row is stored
+-- `active` with an elapsed window, so the computed read reproduces it exactly
+-- — the same status, from the same row, with no scheduled job in the picture.
+
+UPDATE "project_listings" SET "status" = 'requested' WHERE "status" = 'applied';
+UPDATE "project_listings" SET "status" = 'active' WHERE "status" IN ('approved', 'live');
+
+-- LEAST(...) so a closed row that already carries a past window end keeps its
+-- real expiry rather than being restamped to yesterday.
+UPDATE "project_listings"
+SET "status" = 'active',
+    "window_ends_at" = LEAST(
+      COALESCE("window_ends_at", CURRENT_TIMESTAMP - INTERVAL '1 day'),
+      CURRENT_TIMESTAMP - INTERVAL '1 day'
+    )
+WHERE "status" = 'closed';

package/templates/database/migrations/20260909180000_listing_draft_and_fields/migration.sql

@@ -0,0 +1,174 @@
+-- #5036 — the application becomes a resumable draft, and the listing carries
+-- the fields its page and tile render.
+--
+-- Four groups of change, in dependency order:
+--
+--   1. project_listings: every submit-required column becomes NULLABLE, so a
+--      half-filled draft is storable at all; the application's new columns
+--      land; `audience` is dropped; `stage` is remapped onto the six-rung
+--      `product` ladder.
+--   2. project_listings: `experiment_id` becomes `experiment_key`, backfilled
+--      from the experiment it pointed at.
+--   3. waitlist_scores: the uniqueness key is scoped per experiment.
+--   4. flow_definitions / flow_sessions: an explicit listing reference.
+--
+-- Ordering matters: the `stage` remap runs while the column still exists and
+-- BEFORE the rename, and the `experiment_key` backfill runs while
+-- `experiment_id` still holds the pointer it is derived from.
+
+-- ─── 1a. project_listings — nullable at rest (#5036 D1) ─────────────────────
+-- Validation moved from write-time to submit-time when the application became
+-- a ten-step form that saves as it goes. A draft is a legitimately incomplete
+-- row; a NOT NULL on any of these would make one unstorable. Only `submit`
+-- asserts completeness, in the application layer, where the missing fields can
+-- be NAMED back to the founder.
+--
+-- Dropping NOT NULL is not a rewrite and cannot fail on existing data: every
+-- current row already satisfies the stricter constraint.
+ALTER TABLE "project_listings" ALTER COLUMN "slug" DROP NOT NULL;
+-- `lead_id` joins this group for a second reason on top of the first: the Lead
+-- is written at SUBMIT rather than at start, so a draft legitimately has none.
+-- Writing one at step one added no capture (the founder's contact details are
+-- already on THIS row) while giving an anonymous stranger a way to send the
+-- operator a notification email per abandoned first step.
+ALTER TABLE "project_listings" ALTER COLUMN "lead_id" DROP NOT NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "name" DROP NOT NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "one_liner" DROP NOT NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "problem" DROP NOT NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "questions" DROP NOT NULL;
+
+-- ─── 1b. project_listings — the fields the page and tile render (#5036 D5) ──
+-- `commitment` and `team_composition` are the two segmentation axes the
+-- application shares with the diagnostic; `faqs` is exactly three
+-- {question, answer} entries; `anything_else` is the operator's read.
+--
+-- `address` is a legal control rather than a contact detail (#5036 D6):
+-- visitors answering a founder's diagnostic hand personal data to THAT
+-- FOUNDER, and are owed the identity and address of the party collecting it.
+-- It is carried on the public read for that reason.
+ALTER TABLE "project_listings" ADD COLUMN "commitment" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "team_composition" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "faqs" JSONB;
+ALTER TABLE "project_listings" ADD COLUMN "anything_else" TEXT;
+ALTER TABLE "project_listings" ADD COLUMN "address" TEXT;
+
+-- `audience` is DROPPED, not made nullable (#5036 D5). No question feeds it
+-- any more — its guidance folded into `one_liner` — so a retained column would
+-- only ever hold a placeholder. Existing values are not migrated anywhere: the
+-- field has no successor.
+ALTER TABLE "project_listings" DROP COLUMN "audience";
+
+-- ─── 1c. project_listings — consent (#5036 D1/D6) ───────────────────────────
+-- The step-one consent checkbox is the paired control for publishing the
+-- founder's name and address on a page they do not control, so the row records
+-- when it was ticked.
+--
+-- Backfilled from `created_at` rather than `now()`: an existing row's consent
+-- was given when its application was submitted, and stamping today's date onto
+-- it would be a false record of a legal fact. Added nullable, backfilled, then
+-- constrained — the standard three-step so the NOT NULL can never fail.
+ALTER TABLE "project_listings" ADD COLUMN "consent_at" TIMESTAMPTZ;
+UPDATE "project_listings" SET "consent_at" = "created_at" WHERE "consent_at" IS NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "consent_at" SET NOT NULL;
+ALTER TABLE "project_listings" ALTER COLUMN "consent_at" SET DEFAULT CURRENT_TIMESTAMP;
+
+-- ─── 1d. project_listings — the resume token (#5036 D1) ─────────────────────
+-- Holds a sha-256 DIGEST of the token, never the token itself: it is the only
+-- credential on an anonymous surface, so reading this table must not yield one.
+-- Null on every existing row (all of them are past the draft state) and null
+-- again after submit, which is what makes a leaked token inert.
+ALTER TABLE "project_listings" ADD COLUMN "resume_token_hash" TEXT;
+CREATE UNIQUE INDEX "project_listings_resume_token_hash_key" ON "project_listings"("resume_token_hash");
+
+-- ─── 1e. project_listings — the product ladder replaces `stage` (#5036 D2) ──
+-- The same axis at finer resolution. The old four rungs were coarse enough
+-- that a founder with clickable wireframes and one with a working build both
+-- answered "building".
+--
+-- The map is EXPLICIT and lossy by construction — `building` spans wireframes
+-- through prototype and the old data cannot say which, so it lands on the
+-- rung a "building" answer most often meant rather than on a guess dressed up
+-- as precision. No mapping shim exists in code: the two ladders do not align
+-- rung-for-rung, so a silent runtime translation would invent data. This
+-- one-time remap is the whole of it.
+--
+--   idea      -> new-idea-written
+--   building  -> working-prototype
+--   beta      -> live-no-users
+--   launched  -> live-some-users
+UPDATE "project_listings" SET "stage" = 'new-idea-written'  WHERE "stage" = 'idea';
+UPDATE "project_listings" SET "stage" = 'working-prototype' WHERE "stage" = 'building';
+UPDATE "project_listings" SET "stage" = 'live-no-users'     WHERE "stage" = 'beta';
+UPDATE "project_listings" SET "stage" = 'live-some-users'   WHERE "stage" = 'launched';
+
+ALTER TABLE "project_listings" RENAME COLUMN "stage" TO "product";
+ALTER TABLE "project_listings" ALTER COLUMN "product" DROP NOT NULL;
+
+-- ─── 2. project_listings — the experiment KEY, not its id (#5036 D6d) ───────
+-- `waitlist_scores` stores `experiment_key`, so holding the experiment's id
+-- here meant every listing-to-submissions read fetched the experiment purely
+-- to learn its key. Same string on both sides now, one hop.
+--
+-- RENAME then backfill, so a row whose experiment has since been deleted keeps
+-- a null rather than silently pointing at nothing: the rename carries the old
+-- id across, the UPDATE overwrites it with the real key where one resolves,
+-- and the final statement clears anything left holding an unresolved id.
+ALTER TABLE "project_listings" RENAME COLUMN "experiment_id" TO "experiment_key";
+
+UPDATE "project_listings" pl
+SET "experiment_key" = we."key"
+FROM "waitlist_experiments" we
+WHERE we."id" = pl."experiment_key";
+
+UPDATE "project_listings"
+SET "experiment_key" = NULL
+WHERE "experiment_key" IS NOT NULL
+  AND "experiment_key" LIKE 'wlexp\_%';
+
+-- ─── 1f. project_listings — the concurrent-listing index (#5036 D7) ─────────
+-- A founder may hold at most two non-terminal listings, and that count runs on
+-- every submit from an ANONYMOUS route. Indexed so a stranger cannot make it a
+-- table scan.
+CREATE INDEX "project_listings_site_id_founder_email_idx" ON "project_listings"("site_id", "founder_email");
+
+-- ─── 3. waitlist_scores — one score per (lead, EXPERIMENT) (#5036 D6d) ──────
+-- `UNIQUE(lead_id)` was right for a single instrument and wrong for a
+-- marketplace of them. A visitor who joins two founders' waitlists is one lead
+-- with two scores; the old key permitted one, so the second write overwrote the
+-- first, one founder's evidence disappeared, and their weekly CSV
+-- under-reported with no error raised. Scoping the key to the experiment keeps
+-- the overwrite-on-retake behaviour `scoreCompletedSignup` relies on, per
+-- project rather than globally.
+--
+-- The widening direction is the safe one: every row that satisfied
+-- UNIQUE(lead_id) also satisfies UNIQUE(lead_id, experiment_key), so this
+-- cannot fail on existing data whatever the table holds.
+DROP INDEX "waitlist_scores_lead_id_key";
+CREATE UNIQUE INDEX "waitlist_scores_lead_id_experiment_key_key" ON "waitlist_scores"("lead_id", "experiment_key");
+
+-- ─── 4. flow_definitions / flow_sessions — an explicit listing reference ────
+-- (#5036 D6d.) Before this, the only link from a submission back to a listing
+-- was that the generated flow's slug HAPPENED to equal the listing's slug, and
+-- nothing enforced that — a slug collision would have attributed a founder's
+-- submission to someone else. ADR 0009 forbids a relation across the namespace
+-- boundary, so these stay plain strings; the point is that the join is now
+-- stated rather than inferred.
+--
+-- Backfilled from the slug match that WAS the convention, scoped by site, which
+-- is the last time that inference is trusted. New rows carry the reference
+-- directly: `generateListingFlow` stamps the definition, and a session copies
+-- it from the definition at create.
+ALTER TABLE "flow_definitions" ADD COLUMN "listing_id" TEXT;
+ALTER TABLE "flow_sessions" ADD COLUMN "listing_id" TEXT;
+
+UPDATE "flow_definitions" fd
+SET "listing_id" = pl."id"
+FROM "project_listings" pl
+WHERE pl."site_id" = fd."site_id" AND pl."slug" = fd."slug";
+
+UPDATE "flow_sessions" fs
+SET "listing_id" = fd."listing_id"
+FROM "flow_definitions" fd
+WHERE fd."id" = fs."flow_id" AND fd."listing_id" IS NOT NULL;
+
+CREATE INDEX "flow_sessions_listing_id_idx" ON "flow_sessions"("listing_id");

package/templates/database/migrations/20260910120000_listing_public_site_key/migration.sql

@@ -0,0 +1,14 @@
+-- #5048 D2 — the public site key.
+--
+-- An anonymous application named its site with a `siteId` in the request body.
+-- A body-supplied tenant identifier is exactly what the consuming site's proxy
+-- route existed to prevent, so the body now carries a PUBLIC KEY and the server
+-- resolves the site from it. This column is that mapping.
+--
+-- Nullable: a site that has not minted a key is simply unreachable by key, and
+-- the single-tenant path (AILK_LISTING_PUBLIC_KEY -> AILK_SITE_ID) needs no row
+-- at all. Unique: a key resolves to exactly one site or to nothing.
+ALTER TABLE "site_listing_configs" ADD COLUMN "public_key" TEXT;
+
+CREATE UNIQUE INDEX "site_listing_configs_public_key_key"
+  ON "site_listing_configs" ("public_key");

package/templates/database/migrations/20260911120000_listing_copy_edit_audit/migration.sql

@@ -0,0 +1,25 @@
+-- The operator's copy-edit audit trio on `project_listings`.
+--
+-- A listing whose copy needs a trim could previously only be published exactly
+-- as written or rejected outright: the legal transitions out of `requested` are
+-- `active` and `rejected`, there is no route back to `draft`, and the draft
+-- patch is scoped to the applicant's own resume token. These three columns back
+-- the third outcome — an operator copy edit of the five PUBLISHED copy fields
+-- (`headline`, `one_liner`, `problem`, `faqs`, `questions`).
+--
+-- `submitted_copy` is WRITE-ONCE, on the first edit only, and holds those five
+-- fields exactly as the applicant submitted them. Nullable and never
+-- backfilled: the untouched majority keeps NULL, so "what did the applicant
+-- actually send" reads as the snapshot when present and as the row itself
+-- otherwise. Nothing ever clears it, so the submitted copy stays recoverable
+-- for the life of the row.
+--
+-- `copy_edited_at` / `copy_edited_by` mirror the existing `decided_at` /
+-- `decided_by` audit pair on this same table and are re-stamped on every edit.
+-- `copy_edited_by` holds the operator's user id, matching `decided_by`.
+--
+-- No index: every read of these columns is already keyed by the listing's own
+-- primary key or by an existing (site_id, …) index.
+ALTER TABLE "project_listings" ADD COLUMN "submitted_copy" JSONB;
+ALTER TABLE "project_listings" ADD COLUMN "copy_edited_at" TIMESTAMP(3);
+ALTER TABLE "project_listings" ADD COLUMN "copy_edited_by" TEXT;

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;