create-ailk 0.5.0 → 0.6.1

package/templates/database/migrations/20260919130000_flow_definition_admin_columns/migration.sql

@@ -0,0 +1,172 @@
+-- #6156 — S5b: a magnet is a flow row. FlowDefinition gains four
+-- operator-facing columns — kind, title, landingPage, status — spec D1.
+--
+-- STRICTLY ADDITIVE. Nothing dropped, renamed or relaxed; @@unique
+-- ([siteId, slug]), the `flow_`+UUIDv7 id default, and `listing_id` are all
+-- untouched. The visitor-facing `config` column is byte-identical across
+-- this migration (FR4, asserted below) — these four columns are how the
+-- operator MANAGES a magnet, never what a visitor's session SEES
+-- (AD-3, spec D1/§1.2).
+--
+-- `status` is backfilled 'live' (every row that exists today is already
+-- serving — D1's availability half) and carries NO column default (D1's
+-- publication-safety half, SEC-08): a DEFAULT 'live' would make
+-- PUBLICATION the thing that happens when a future writer says nothing,
+-- which is the exact asymmetry the brief's "a magnet created from the
+-- Admin opens as a draft" commitment forbids. So `status` is added
+-- nullable, backfilled, then SET NOT NULL with no default — every future
+-- writer must name a status or fail to compile.
+--
+-- `title` is NOT NULL with no column default, by the same three-step, for
+-- the positive reason: a nameless magnet must never enter the table
+-- silently. The slug backfills every existing row's title — an honest
+-- placeholder the operator renames.
+--
+-- `kind` KEEPS its column default ('contact') — unlike `status`, a
+-- mis-classified magnet is a mislabel in a list, not a publication or
+-- security control (D1). The backfill below reclassifies the rows D3's
+-- structural rule actually matches; every other row stays the default.
+--
+-- `landing_page` is nullable with NO backfill (D1): a magnet has THREE
+-- public addresses (the indexed landing route, the walk route one segment
+-- deeper, and the results route), so seeding a derived guess would freeze
+-- a route as if it were an operator decision. NULL means "no
+-- operator-declared landing page; the canonical route serves it" — true of
+-- every existing row.
+--
+-- `flow_definitions_status_domain` (D2) is a closed two-value CHECK,
+-- deliberately narrower than the precedent this namespace otherwise follows
+-- (WaitlistExperiment.status, FlowCheckout.status, ProjectListing.status —
+-- all plain String with no CHECK): `status` is what makes D10's
+-- deny-list gate in `resolveSession` SAFE rather than merely convenient —
+-- an unstorable unknown value means "not 'draft'" and "'live'" are the same
+-- set at the database level. No CHECK on `kind`: its vocabulary is six
+-- values and growing (Epic #6025), so a CHECK there would make every new
+-- kind a migration that RELAXES a constraint.
+--
+-- Statement order (D9) is fixed and load-bearing, not incidental: the
+-- `ADD COLUMN` runs FIRST, acquiring ACCESS EXCLUSIVE on `flow_definitions`
+-- before the census is taken, so no concurrent committed write (a listing
+-- approval via `upsertFlowDefinition`, a waitlist-register materialize) can
+-- land between the census and the assertions and falsely trip them. The
+-- whole sequence blocks every read AND write to `flow_definitions` for its
+-- duration — acceptable only because the table is tiny today (§1.4's
+-- census: four seeded presets plus two generated families); a later unit
+-- that grows this table materially owes a re-read of this decision rather
+-- than an inherited assumption.
+--
+-- Not re-runnable by `IF NOT EXISTS` guards (unlike #6155's
+-- 20260919120000_flow_workspace_key, whose NFR3 needed it for a reason
+-- specific to that migration): `prisma migrate`'s per-migration transaction
+-- + the `_prisma_migrations` ledger already make re-runnability a
+-- non-requirement here.
+--
+-- Rollback: ALTER TABLE "flow_definitions" DROP COLUMN "kind", DROP COLUMN
+-- "title", DROP COLUMN "landing_page", DROP COLUMN "status". Safe
+-- unconditionally — dropping "status" drops "flow_definitions_status_domain"
+-- with it, the four columns carry no other constraint, no index and no
+-- relation, and nothing outside this diff references them.
+
+-- AlterTable — all four, one statement, taking ACCESS EXCLUSIVE before
+-- anything else in this transaction reads the table (D9).
+ALTER TABLE "flow_definitions"
+  ADD COLUMN "kind" TEXT NOT NULL DEFAULT 'contact',
+  ADD COLUMN "title" TEXT,
+  ADD COLUMN "landing_page" TEXT,
+  ADD COLUMN "status" TEXT;
+
+-- The census the post-assertions compare against — taken SECOND, under the
+-- lock the ADD COLUMN above already holds, so it is a stable baseline for
+-- every assertion below (D9 / SEC-07). ON COMMIT DROP: `prisma migrate`
+-- runs each migration in one transaction, so this disappears with it.
+CREATE TEMP TABLE "_6156_flow_def_census" ON COMMIT DROP AS
+  SELECT count(*) AS n,
+         md5(string_agg("config"::text, '' ORDER BY "id")) AS config_hash
+    FROM "flow_definitions";
+
+-- ── Backfill (D3 / D1) ───────────────────────────────────────────────────
+-- 1. `kind` — D3's structural rule, first match wins. Every row not
+--    matched by a branch below keeps the column default written above.
+UPDATE "flow_definitions"
+   SET "kind" = CASE
+     WHEN "listing_id" IS NOT NULL THEN 'diagnostic'
+     WHEN "config"->>'mode' = 'recommending' THEN 'diagnostic'
+     WHEN "config" ? 'deliverables' THEN 'special-report'
+     ELSE 'contact'
+   END;
+
+-- 2. `title` = the slug (an honest placeholder); `status` = 'live' (every
+--    row that exists today is already serving — D1's availability half).
+UPDATE "flow_definitions"
+   SET "title" = "slug",
+       "status" = 'live';
+
+-- SET NOT NULL + the status domain CHECK — AFTER the backfill, so neither
+-- constraint is ever evaluated against a NULL this migration itself wrote.
+ALTER TABLE "flow_definitions" ALTER COLUMN "title" SET NOT NULL;
+ALTER TABLE "flow_definitions" ALTER COLUMN "status" SET NOT NULL;
+ALTER TABLE "flow_definitions"
+  ADD CONSTRAINT "flow_definitions_status_domain"
+  CHECK ("status" IN ('draft', 'live'));
+
+-- ── POST-ASSERTIONS (FR2/FR3/FR4 — AC-1) ────────────────────────────────
+-- Asserted against the rows the target database actually holds, not a
+-- fixture's. A raised exception here rolls the whole migration back
+-- (`prisma migrate`'s per-migration transaction).
+DO $$
+DECLARE
+  before_n     bigint;
+  before_hash  text;
+  after_n      bigint;
+  after_hash   text;
+  null_cols    bigint;
+  wrong_kind   bigint;
+BEGIN
+  SELECT n, config_hash INTO before_n, before_hash FROM "_6156_flow_def_census";
+  SELECT count(*), md5(string_agg("config"::text, '' ORDER BY "id"))
+    INTO after_n, after_hash
+    FROM "flow_definitions";
+
+  -- 1. Nothing lost or gained: row count unchanged across a purely
+  --    additive-plus-backfill migration.
+  IF before_n <> after_n THEN
+    RAISE EXCEPTION
+      '#6156 post-assertion: flow_definitions row count changed (% -> %)',
+      before_n, after_n;
+  END IF;
+
+  -- 2. `config` is byte-identical (FR4) — this migration writes NO column
+  --    other than kind/title/landing_page/status.
+  IF before_hash IS DISTINCT FROM after_hash THEN
+    RAISE EXCEPTION
+      '#6156 post-assertion: flow_definitions.config changed across a migration that must not touch it';
+  END IF;
+
+  -- 3. Every pre-existing row leaves with a non-NULL status/title/kind
+  --    (landing_page is NOT asserted — D1: it is deliberately unbackfilled).
+  SELECT count(*) INTO null_cols FROM "flow_definitions"
+   WHERE "status" IS NULL OR "title" IS NULL OR "kind" IS NULL;
+  IF null_cols <> 0 THEN
+    RAISE EXCEPTION
+      '#6156 post-assertion: % flow_definitions row(s) came out of the backfill with a NULL status/title/kind',
+      null_cols;
+  END IF;
+
+  -- 4. Backfill rule correctness (D3) — every listing-projected row, and
+  --    every recommending-mode row, classified 'diagnostic'.
+  SELECT count(*) INTO wrong_kind FROM "flow_definitions"
+   WHERE "listing_id" IS NOT NULL AND "kind" <> 'diagnostic';
+  IF wrong_kind <> 0 THEN
+    RAISE EXCEPTION
+      '#6156 post-assertion: % flow_definitions row(s) with listing_id set did not classify as diagnostic',
+      wrong_kind;
+  END IF;
+
+  SELECT count(*) INTO wrong_kind FROM "flow_definitions"
+   WHERE "config"->>'mode' = 'recommending' AND "kind" <> 'diagnostic';
+  IF wrong_kind <> 0 THEN
+    RAISE EXCEPTION
+      '#6156 post-assertion: % flow_definitions row(s) with config.mode = recommending did not classify as diagnostic',
+      wrong_kind;
+  END IF;
+END $$;

package/templates/database/migrations/20260919130000_workspace_meetings/migration.sql

@@ -0,0 +1,41 @@
+-- #6183 (S9b) — the WorkspaceMeetings model: the operator's enabled-slug
+-- gate for meeting types (spec docs/specs/6183-s9b-enabled-meeting-slugs-live-spec.md
+-- D1, D11). A fourth workspace site-config blob, structurally identical to
+-- its three siblings (workspace_themes / workspace_site_identities /
+-- workspace_seos) — same `@unique(workspace_id)` key, same Json-column
+-- convention, validation happens at the API layer.
+--
+-- One new table, one unique index, in the house style of
+-- 20260918120000_add_appointment (CreateTable + CreateIndex immediately
+-- followed by the ADR-0031 rule-3 id-format completion, in ONE migration
+-- since the table is new and needs no retrofit). No `workspace_id_format`
+-- CHECK, matching that same precedent — the baseline migration's 12
+-- relation-free scope checks are pinned to it alone
+-- (packages/ids/src/__tests__/migration-sync.test.ts), and no per-entity
+-- migration since has added one.
+--
+-- No backfill, no constraint relaxed, no existing table touched.
+--
+-- Rollback: DROP TABLE "workspace_meetings". Safe unconditionally while
+-- nothing but #6183's own code reads it.
+
+-- CreateTable
+CREATE TABLE "workspace_meetings" (
+    "id" TEXT NOT NULL DEFAULT ('meet_'::text || (uuidv7())::text),
+    "workspace_id" TEXT NOT NULL,
+    "data" JSONB NOT NULL,
+    "created_at" TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    "updated_at" TIMESTAMPTZ NOT NULL,
+
+    CONSTRAINT "workspace_meetings_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "workspace_meetings_workspace_id_key" ON "workspace_meetings"("workspace_id");
+
+-- ADR-0031 rule 3 — workspace_meetings: meet_ (registered in
+-- packages/ids/src/registry.ts ENTITY_PREFIX.workspaceMeetings; this
+-- migration's path is added to migration-sync.test.ts's PK_CHECK_MIGRATIONS).
+ALTER TABLE "workspace_meetings" ALTER COLUMN "id" TYPE text COLLATE "C";
+ALTER TABLE "workspace_meetings" ALTER COLUMN "id" SET DEFAULT ('meet_'::text || (uuidv7())::text);
+ALTER TABLE "workspace_meetings" ADD CONSTRAINT "workspace_meetings_id_format" CHECK ("id" ~ '^meet_[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/20260919140000_inbox_workspace_key/migration.sql

@@ -0,0 +1,185 @@
+-- #6203 — ProjectListing and Lead gain a workspace isolation key.
+--
+-- The ownership brief (docs/internal/decisions/workspace-owns-data-surfaces-render.md)
+-- and AD-4 (docs/internal/decisions/flow-engine-admin-surface.md): a workspace
+-- owns data, and the Inbox's tenant-scope fence grows to cover the two
+-- models it reads. `siteId` stays a legacy alias for the anonymous write
+-- paths (unchanged); `workspaceId` is the isolation key every Admin read
+-- will go through (apps/api/src/lib/tenant-db.ts's new
+-- `projectListings`/`leads` accessors). Mirrors
+-- database/migrations/20260919120000_flow_workspace_key step for step
+-- (#6155's precedent for FlowDefinition/FlowSession).
+--
+-- NULLABLE, no default (spec D2) — a row whose `siteId` matches no workspace
+-- is left UNSET rather than guessed, and stays invisible to every accessor
+-- rather than visible to the wrong tenant (the same "fails empty, never
+-- wide" posture apps/api/src/services/leads-inbox.ts already takes).
+--
+-- RE-RUNNABLE (NFR3): `ADD COLUMN IF NOT EXISTS` / `CREATE INDEX IF NOT
+-- EXISTS` cover the column and index. Postgres has no
+-- `ADD CONSTRAINT IF NOT EXISTS`, so each format CHECK is wrapped in its own
+-- existence-guarded `DO $$` block, exactly as the #6155 precedent does.
+--
+-- Rollback: DROP INDEX "project_listings_workspace_id_idx",
+-- "leads_workspace_id_idx"; ALTER TABLE "project_listings" DROP
+-- CONSTRAINT "project_listings_workspace_id_format", DROP COLUMN
+-- "workspace_id"; ALTER TABLE "leads" DROP CONSTRAINT
+-- "leads_workspace_id_format", DROP COLUMN "workspace_id". Safe
+-- unconditionally at this pin — nothing reads the column until #6204+.
+
+-- The census the post-assertions compare against. ON COMMIT DROP: `prisma
+-- migrate` runs each migration in one transaction, so this disappears with it.
+CREATE TEMP TABLE "_6203_inbox_census" ON COMMIT DROP AS
+  SELECT (SELECT count(*) FROM "project_listings") AS p,
+         (SELECT count(*) FROM "leads")            AS l;
+
+-- AlterTable
+ALTER TABLE "project_listings" ADD COLUMN IF NOT EXISTS "workspace_id" TEXT;
+ALTER TABLE "leads"            ADD COLUMN IF NOT EXISTS "workspace_id" TEXT;
+
+-- Format CHECKs — NULL-permitting, in the exact shape of the CHECKs
+-- 20260713192429_prefixed_uuid_entity_ids/migration.sql already applies to
+-- every other `workspace_id` column. Existence-guarded because Postgres has
+-- no `ADD CONSTRAINT IF NOT EXISTS`. This is what makes the Lead.siteId
+-- provenance gap (spec §1.3, §9 SEC-1) non-exploitable as an id-SHAPE
+-- attack: a site_id that is not a well-formed wksp_<uuidv7> cannot land in
+-- this column at all.
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'project_listings_workspace_id_format'
+  ) THEN
+    ALTER TABLE "project_listings" ADD CONSTRAINT "project_listings_workspace_id_format"
+      CHECK ("workspace_id" IS NULL OR "workspace_id" ~ '^wksp_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'leads_workspace_id_format'
+  ) THEN
+    ALTER TABLE "leads" ADD CONSTRAINT "leads_workspace_id_format"
+      CHECK ("workspace_id" IS NULL OR "workspace_id" ~ '^wksp_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');
+  END IF;
+END $$;
+
+-- CreateIndex
+CREATE INDEX IF NOT EXISTS "project_listings_workspace_id_idx" ON "project_listings"("workspace_id");
+CREATE INDEX IF NOT EXISTS "leads_workspace_id_idx" ON "leads"("workspace_id");
+
+-- ── Backfill (spec D2, §5.4) ────────────────────────────────────────────────
+-- Both spellings of the alias, one statement per table. The literal alias
+-- "default" resolves to the seeded sentinel workspace
+-- (database/tenancy.ts DEFAULT_WORKSPACE_ID); every other alias resolves
+-- only by exact workspaces.id equality. An inner join to "workspaces" means a
+-- row whose alias resolves to nothing is simply not updated and stays NULL
+-- — the correct, stated behavior (D2), not an error.
+--
+-- The sentinel id is a literal because SQL cannot import
+-- database/tenancy.ts. It is ADR 0031's reserved-range sentinel and changes
+-- only with that ADR — no test pins it against SQL (#6155's own migration
+-- carries the identical correction: the sibling tenancy.test.ts compares
+-- only the imported constant, not this SQL literal).
+UPDATE "project_listings" p
+   SET "workspace_id" = w."id"
+  FROM "workspaces" w
+ WHERE p."workspace_id" IS NULL
+   AND w."id" = CASE WHEN p."site_id" = 'default'
+                      THEN 'wksp_00000000-0000-7000-8000-000000000001'
+                      ELSE p."site_id" END;
+
+UPDATE "leads" l
+   SET "workspace_id" = w."id"
+  FROM "workspaces" w
+ WHERE l."workspace_id" IS NULL
+   AND w."id" = CASE WHEN l."site_id" = 'default'
+                      THEN 'wksp_00000000-0000-7000-8000-000000000001'
+                      ELSE l."site_id" END;
+
+-- ── POST-ASSERTIONS ─────────────────────────────────────────────────────────
+-- AC-1's own enforcement: nothing lost, nothing guessed, nothing missed that
+-- was resolvable. The fourth check is a NOTICE, not an exception — an
+-- unpinned/unseeded deployment leaving rows NULL is the expected, documented
+-- case (spec §1.9, NFR4), never an error this migration should refuse to
+-- run over.
+DO $$
+DECLARE
+  before_p bigint;
+  before_l bigint;
+  after_p  bigint;
+  after_l  bigint;
+  guessed  bigint;
+  missed   bigint;
+  null_p   bigint;
+  null_l   bigint;
+BEGIN
+  SELECT p, l INTO before_p, before_l FROM "_6203_inbox_census";
+  SELECT count(*) INTO after_p FROM "project_listings";
+  SELECT count(*) INTO after_l FROM "leads";
+
+  -- 1. Nothing lost: row counts unchanged on both tables.
+  IF before_p <> after_p OR before_l <> after_l THEN
+    RAISE EXCEPTION
+      '#6203 post-assertion: row count changed across a purely additive migration (project_listings % -> %, leads % -> %)',
+      before_p, after_p, before_l, after_l;
+  END IF;
+
+  -- 2. Nothing guessed: no row's workspace_id was set to a value absent
+  --    from "workspaces" (the inner-join backfill above cannot produce this
+  --    on its own, but a re-run against a database missing the sentinel row
+  --    must never leave a dangling reference).
+  SELECT count(*) INTO guessed FROM "project_listings" p
+   WHERE p."workspace_id" IS NOT NULL
+     AND NOT EXISTS (SELECT 1 FROM "workspaces" w WHERE w."id" = p."workspace_id");
+  IF guessed <> 0 THEN
+    RAISE EXCEPTION
+      '#6203 post-assertion: % project_listings row(s) carry a workspace_id absent from workspaces',
+      guessed;
+  END IF;
+  SELECT count(*) INTO guessed FROM "leads" l
+   WHERE l."workspace_id" IS NOT NULL
+     AND NOT EXISTS (SELECT 1 FROM "workspaces" w WHERE w."id" = l."workspace_id");
+  IF guessed <> 0 THEN
+    RAISE EXCEPTION
+      '#6203 post-assertion: % leads row(s) carry a workspace_id absent from workspaces',
+      guessed;
+  END IF;
+
+  -- 3. Nothing missed: no row whose site_id names a workspace that actually
+  --    exists came out of the backfill with workspace_id still NULL.
+  SELECT count(*) INTO missed FROM "project_listings" p
+   WHERE p."workspace_id" IS NULL
+     AND EXISTS (
+       SELECT 1 FROM "workspaces" w
+        WHERE w."id" = CASE WHEN p."site_id" = 'default'
+                             THEN 'wksp_00000000-0000-7000-8000-000000000001'
+                             ELSE p."site_id" END
+     );
+  IF missed <> 0 THEN
+    RAISE EXCEPTION
+      '#6203 post-assertion: % project_listings row(s) had a resolvable site_id but came out of the backfill NULL',
+      missed;
+  END IF;
+  SELECT count(*) INTO missed FROM "leads" l
+   WHERE l."workspace_id" IS NULL
+     AND EXISTS (
+       SELECT 1 FROM "workspaces" w
+        WHERE w."id" = CASE WHEN l."site_id" = 'default'
+                             THEN 'wksp_00000000-0000-7000-8000-000000000001'
+                             ELSE l."site_id" END
+     );
+  IF missed <> 0 THEN
+    RAISE EXCEPTION
+      '#6203 post-assertion: % leads row(s) had a resolvable site_id but came out of the backfill NULL',
+      missed;
+  END IF;
+
+  -- 4. A NOTICE, never an exception: an unpinned/unseeded deployment leaving
+  --    rows NULL is the expected, documented case (spec §1.9).
+  SELECT count(*) INTO null_p FROM "project_listings" WHERE "workspace_id" IS NULL;
+  SELECT count(*) INTO null_l FROM "leads" WHERE "workspace_id" IS NULL;
+  IF null_p <> 0 OR null_l <> 0 THEN
+    RAISE NOTICE
+      '#6203: % project_listings row(s) and % leads row(s) left workspace_id unset — their site_id did not resolve to a workspace this database holds',
+      null_p, null_l;
+  END IF;
+END $$;

package/templates/database/migrations/20260920120000_lead_handled_at/migration.sql

@@ -0,0 +1,70 @@
+-- #6204 — Lead gains a nullable triage stamp.
+--
+-- Operator decision Q1(a) (#6026, 2026-09-18): a message is a lead that needs
+-- an answer — same capture path, same routing, same tenancy, different
+-- follow-up. One nullable column beats a second entity, and
+-- docs/internal/decisions/flow-engine-admin-surface.md AD-4 stays true: the
+-- Inbox is a READ PROJECTION over tables that already hold decidable state,
+-- never a new decision table.
+--
+-- PURELY ADDITIVE (spec NFR1): two ADD COLUMNs, one CREATE INDEX. No UPDATE, no
+-- backfill, no DEFAULT, no NOT NULL — every existing row keeps NULL, which is
+-- exactly "unhandled" (spec D5, AC-1). There is no data transformation here, so
+-- this migration carries none of the census/post-assertion apparatus
+-- 20260919140000_inbox_workspace_key needed to prove ITS backfill correct.
+--
+-- RE-RUNNABLE (spec NFR2): IF NOT EXISTS on every statement, the house style of
+-- 20260919140000_inbox_workspace_key/migration.sql.
+--
+-- ORDER-SAFE (spec NFR2, security finding S-9): the index references
+-- "workspace_id", which 20260919140000_inbox_workspace_key adds — a migration
+-- this one sorts strictly after (20260920 > 20260919), so in the normal case
+-- the guard below is a formality. It stays a guard rather than an assumption:
+-- `IF NOT EXISTS` guards the INDEX's own name, not the column it references,
+-- so an unguarded CREATE INDEX would abort inside prisma migrate's
+-- per-migration transaction and wedge the ledger for the whole deployment if
+-- that migration were ever skipped, renamed, or rolled back on a given
+-- database. The two ADD COLUMNs above it are unconditional because they
+-- reference nothing another migration owns.
+--
+-- CREATE INDEX is NOT CONCURRENT (security finding S-11), and cannot be:
+-- CONCURRENTLY may not run inside prisma migrate's per-migration transaction.
+-- It therefore takes a lock on "leads" for its duration, which blocks the three
+-- anonymous capture routes (a write failure there surfaces as 503
+-- persist_failed, routes/leads/index.ts), and every subsequent insert
+-- pays a fourth index write. Accepted: "leads" carries four indexes already
+-- (siteId, createdAt, email, workspaceId) and is small at this pin. A
+-- deployment with a large leads table should create this index out-of-band
+-- with CONCURRENTLY first — the IF NOT EXISTS guard then makes this
+-- statement a no-op.
+--
+-- Rollback: DROP INDEX "leads_workspace_id_handled_at_idx";
+--           ALTER TABLE "leads" DROP COLUMN "handled_at", DROP COLUMN "handled_by".
+-- Safe ONLY at this pin, and the qualifier is load-bearing: once the Needs-you
+-- section ships, dropping these columns destroys operator triage state. After
+-- that point the rollback is a forward migration, not a DROP.
+
+-- AlterTable
+ALTER TABLE "leads" ADD COLUMN IF NOT EXISTS "handled_at" TIMESTAMP(3);
+-- The actor (spec D4, security finding S-7) — the sibling of
+-- project_listings."decided_by". Plain TEXT, no FK:
+-- ADR 0009 D2 forbids a relation crossing from inbox into auth.
+ALTER TABLE "leads" ADD COLUMN IF NOT EXISTS "handled_by" TEXT;
+
+-- CreateIndex — the read is
+--   workspace_id = $1 AND handled_at IS NULL AND source = ANY($2)
+-- ordered by created_at desc. A two-column (workspace_id, handled_at) index is
+-- the one that serves it: it narrows to the tenant and then to the unhandled
+-- partition, which is the small side and the side that shrinks as an operator
+-- works the queue. `source` is deliberately NOT a third column (spec D10).
+DO $$ BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.columns
+     WHERE table_name = 'leads' AND column_name = 'workspace_id'
+  ) THEN
+    CREATE INDEX IF NOT EXISTS "leads_workspace_id_handled_at_idx"
+      ON "leads"("workspace_id", "handled_at");
+  ELSE
+    RAISE NOTICE '#6204: leads.workspace_id absent — index skipped. 20260919140000_inbox_workspace_key has not run against this database; the Needs-you read cannot be served until it does (spec § 10.1).';
+  END IF;
+END $$;

package/templates/database/migrations/20260920130000_lead_workspace_source_index/migration.sql

@@ -0,0 +1,57 @@
+-- #6246 — Lead gains a second workspace-scoped composite index, this one
+-- for the per-magnet Signups/Subscribers/Messages read.
+--
+-- The read is workspace_id = $1 AND source = $2, ordered by created_at desc
+-- (spec § 1.5/D1) — an EXACT-EQUALITY match on `source`, distinct from
+-- 20260920120000_lead_handled_at's own (workspace_id, handled_at)
+-- composite, which serves an `IN`-over-a-four-value-allowlist filter. The
+-- two indexes serve two different query shapes over the same two-column
+-- narrowing pattern; neither can stand in for the other.
+--
+-- PURELY ADDITIVE (mirrors 20260920120000_lead_handled_at's own NFR1): one
+-- CREATE INDEX, no column, no backfill, no data transformation — so this
+-- migration carries none of the census/post-assertion apparatus
+-- 20260919140000_inbox_workspace_key needed to prove ITS backfill correct.
+--
+-- RE-RUNNABLE (mirrors the same precedent's NFR2): IF NOT EXISTS on the
+-- index, guarded on the referenced column's presence.
+--
+-- ORDER-SAFE: the index references "workspace_id", which
+-- 20260919140000_inbox_workspace_key adds — a migration this one sorts
+-- strictly after (20260920130000 > 20260919140000), so in the normal case
+-- the guard below is a formality, kept for the same reason its precedent
+-- keeps one: IF NOT EXISTS guards the INDEX's own name, not the column it
+-- references, so an unguarded CREATE INDEX would abort inside prisma
+-- migrate's per-migration transaction and wedge the ledger for the whole
+-- deployment if that migration were ever skipped, renamed, or rolled back
+-- on a given database.
+--
+-- CREATE INDEX is NOT CONCURRENT, and cannot be: CONCURRENTLY may not run
+-- inside prisma migrate's per-migration transaction. It therefore takes a
+-- lock on "leads" for its duration, the SAME accepted risk
+-- 20260920120000_lead_handled_at's own header names — "leads" carries five
+-- indexes already (siteId, createdAt, email, workspaceId,
+-- (workspaceId, handledAt)) and is small at this pin. A deployment with a
+-- large leads table should create this index out-of-band with
+-- CONCURRENTLY first — the IF NOT EXISTS guard then makes this statement a
+-- no-op.
+--
+-- Rollback: DROP INDEX "leads_workspace_id_source_idx";
+-- Safe at any point — this migration adds no column and no application
+-- state depends on the index existing, only on its absence being slower.
+
+-- CreateIndex — the read is workspace_id = $1 AND source = $2, ordered by
+-- created_at desc (spec § 1.5/D1). A two-column (workspace_id, source)
+-- index serves it directly: it narrows to the tenant and then to the
+-- exact-match magnet source in one pass.
+DO $$ BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.columns
+     WHERE table_name = 'leads' AND column_name = 'workspace_id'
+  ) THEN
+    CREATE INDEX IF NOT EXISTS "leads_workspace_id_source_idx"
+      ON "leads"("workspace_id", "source");
+  ELSE
+    RAISE NOTICE '#6246: leads.workspace_id absent — index skipped. 20260919140000_inbox_workspace_key has not run against this database; the per-magnet list read cannot be served efficiently until it does.';
+  END IF;
+END $$;

package/templates/database/migrations/20260921120000_deliverable_grant_workspace_key/migration.sql

@@ -0,0 +1,68 @@
+-- #6310 D8/D15 — DeliverableGrant gains its own `workspace_id`.
+--
+-- The one migration this spec carries — it moves no `DeliverableAsset` row
+-- (D3: existing rows keep delivering, unmigrated; AC3's grounding is in the
+-- spec, not here). It restores the serve-time tenancy re-check the legacy
+-- arm already has (`asset.siteId !== grant.siteId`, routes/deliverables/index.ts)
+-- for the new `Asset`-backed grant class: `workspaceId` is written at mint,
+-- from the SAME value that authorized the mint-time resolution (D15), so the
+-- serve read is `{ id, workspaceId }` rather than an unscoped `{ id }`.
+--
+-- NULLABLE, no default — mirrors database/migrations/20260919140000_inbox_workspace_key's
+-- idiom step for step: a value this migration cannot derive (every grant
+-- that exists at migration time is a legacy `dasset_`/`playbook:` grant
+-- whose serve arm never reads this column) is left UNSET rather than
+-- guessed. NO BACKFILL: there is nothing to backfill — the column has no
+-- source column to derive from (unlike site_id -> workspace_id, this is a
+-- wholly new fact, captured only at a FUTURE mint).
+--
+-- RE-RUNNABLE: `ADD COLUMN IF NOT EXISTS` covers the column; the format
+-- CHECK is wrapped in an existence-guarded `DO $$` block since Postgres has
+-- no `ADD CONSTRAINT IF NOT EXISTS`. No index — the column is read only by
+-- `findFirst`-by-id, never filtered on.
+--
+-- Rollback: ALTER TABLE "deliverable_grants" DROP CONSTRAINT
+-- "deliverable_grants_workspace_id_format", DROP COLUMN "workspace_id".
+-- Safe unconditionally at this pin — no `asset_`-class grant exists yet to
+-- lose data from.
+
+-- The census the post-assertion compares against. ON COMMIT DROP: `prisma
+-- migrate` runs each migration in one transaction, so this disappears with it.
+CREATE TEMP TABLE "_6310_deliverable_grants_census" ON COMMIT DROP AS
+  SELECT count(*) AS n FROM "deliverable_grants";
+
+-- AlterTable
+ALTER TABLE "deliverable_grants" ADD COLUMN IF NOT EXISTS "workspace_id" TEXT;
+
+-- Format CHECK — NULL-permitting, in the exact shape of the CHECKs
+-- 20260713192429_prefixed_uuid_entity_ids/migration.sql already applies to
+-- every other `workspace_id` column (mirrored verbatim from #6203's own
+-- migration). Existence-guarded because Postgres has no
+-- `ADD CONSTRAINT IF NOT EXISTS`.
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'deliverable_grants_workspace_id_format'
+  ) THEN
+    ALTER TABLE "deliverable_grants" ADD CONSTRAINT "deliverable_grants_workspace_id_format"
+      CHECK ("workspace_id" IS NULL OR "workspace_id" ~ '^wksp_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$');
+  END IF;
+END $$;
+
+-- ── POST-ASSERTION ──────────────────────────────────────────────────────────
+-- NFR1's own enforcement: exactly one nullable column added, no row moved or
+-- rewritten. No "nothing guessed"/"nothing missed" checks (unlike #6203) —
+-- there is no backfill for those checks to verify.
+DO $$
+DECLARE
+  before_n bigint;
+  after_n  bigint;
+BEGIN
+  SELECT n INTO before_n FROM "_6310_deliverable_grants_census";
+  SELECT count(*) INTO after_n FROM "deliverable_grants";
+
+  IF before_n <> after_n THEN
+    RAISE EXCEPTION
+      '#6310 post-assertion: row count changed across a purely additive migration (deliverable_grants % -> %)',
+      before_n, after_n;
+  END IF;
+END $$;