import { defineConfig } from "drizzle-kit";

if (!process.env.DATABASE_URL) {
  throw new Error("DATABASE_URL, ensure the database is provisioned");
}

export default defineConfig({
  out: "./migrations",
  schema: "./shared/schema.ts",
  dialect: "postgresql",
  dbCredentials: {
    url: process.env.DATABASE_URL,
  },
  // Tables created by runtime / boot DDL (rls-init, or lazily on first use), NOT declared in the
  // drizzle schema, are excluded from `drizzle-kit push` management here. Two DISTINCT failure
  // modes have been seen on this boot-push path — do not conflate them:
  //
  //   session   — connect-pg-simple's session store; managed externally by the session middleware.
  //
  //   data_keys — the envelope KEK/DEK store (rls-init M63); holds NON-REGENERABLE wrapped keys.
  //               push --force DROPPED it in a 2026-07-08 incident that crash-looped the app; the
  //               exclusion has protected it since. The mechanism of that specific drop was never
  //               isolated, and the live PII estate is now v2/DEK-dependent — DO NOT remove this
  //               exclusion to find out whether the current drizzle-kit still drops it. Its
  //               necessity was demonstrated once and is untested-because-untestable (re-testing
  //               costs an irreplaceable key store). See feedback_restart_survival_gate.
  //
  //   timestamp_anchors, idempotency_keys, decision_scoring_outputs — runtime-created orphans
  //               (rfc3161-anchor.ts / the idempotency HA path / rls-init). push --force does NOT
  //               drop these: verified empirically by seeding a keyed row into idempotency_keys and
  //               confirming it SURVIVES a --force-recreate (2026-07-09). NB an earlier draft of this
  //               change claimed a silent data-loss drop; a negative control refuted it — there is no
  //               data-loss bug here. They are excluded for a DIFFERENT reason: drizzle's rename-
  //               detection pairs a newly-ADDED schema table against a column-similar orphan and
  //               emits an interactive "create or rename?" prompt. --force auto-answers DATA-LOSS
  //               confirmations ("truncate?") but NOT schema-resolution prompts — so the non-
  //               interactive entrypoint HANGS and the container crash-loops. This is what happened
  //               when kyc_screening_results was added (drizzle offered
  //               "timestamp_anchors › kyc_screening_results  rename table"). Excluding all three —
  //               not just the one that collided — prevents the same hang the next time a schema
  //               table resembles one of them.
  //
  //   login_anomalies, login_anomaly_baseline — the M67/M68 login-anomaly tables, created by
  //               rls-init (server/lib/rls-init.ts:4350 / :4399), NOT declared in the drizzle
  //               schema. Added 2026-07-21: on the #67 boot, push offered
  //               "login_anomaly_baseline › decision_scoring_outputs  rename table" — a create-or-
  //               rename prompt --force cannot answer. It defaulted to CREATE that boot, but any boot
  //               could default to RENAME and rename M68's baseline table out from under it (and the
  //               unanswered prompt also made push SILENTLY SKIP other diffed changes while still
  //               printing "schema is in sync"). Excluding both closes that standing M68 rename risk
  //               and restores an honest schema-sync claim.
  //
  // THE RULE: any table created outside the drizzle schema must be listed here.
  tablesFilter: ["!session", "!data_keys", "!timestamp_anchors", "!idempotency_keys", "!decision_scoring_outputs", "!login_anomalies", "!login_anomaly_baseline"],
});