create-ailk 0.24.0 → 0.26.0

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

@@ -1,30 +0,0 @@
--- #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

@@ -1,47 +0,0 @@
--- #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

@@ -1,16 +0,0 @@
--- #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

@@ -1,47 +0,0 @@
--- #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

@@ -1,10 +0,0 @@
--- #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

@@ -1,26 +0,0 @@
--- #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

@@ -1,90 +0,0 @@
--- #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

@@ -1,174 +0,0 @@
--- #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

@@ -1,14 +0,0 @@
--- #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

@@ -1,25 +0,0 @@
--- 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

@@ -1,32 +0,0 @@
--- 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

@@ -1,71 +0,0 @@
--- #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

@@ -1,30 +0,0 @@
--- 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;