Remove Supabase

The database moved to a container of our own; the platform is gone.
This takes out what was left of it — and, where the leftovers were load
bearing, moves rather than deletes.

Moved, not deleted:

  supabase/migrations/  -> db/migrations/      the schema's source of truth
  supabase/build-org.ts -> scripts/build-org.ts
  lib/supabase/types.ts -> lib/types.ts        52 import sites repointed

The bookkeeping needed care. It lived in `supabase_migrations.schema_migrations`,
and simply renaming the schema would have left the runner facing an empty
table: it would have called all 67 migrations pending and replayed them
against a database that is long since current. So the runner now creates
`migrationen.schema_migrations` and, once, copies the old rows across —
guarded so a second run does nothing and a fresh database skips it entirely.
Only then does migration 20260907100000 drop the old schema.

Deleted: the CLI config, the seed, the historical schema/function dumps
(nothing read them), scripts/umzug-von-supabase.sh (the move is done), and
both Supabase packages plus the CLI. Nothing in the application imported
them — the build now succeeds with no environment variables at all, which
is the proof.

Integration tests: six of them signed in through Supabase Auth and asserted
against the anon key and the service role. That model is gone, so the tests
were not portable — they are deleted. session-context and
employee-status-filter already ran on pg and are untouched; om-reporting is
ported to a direct connection because it guards a real risk (the reporting
line rule exists twice, once in SQL and once in TypeScript).

CI: the integration job started a Supabase stack. It now runs a postgres
service, applies deploy/db-init and every migration to an empty database —
that was the valuable part, and it still holds — then checks that a second
run is a no-op, which is what proves the bookkeeping works.

Docs: security-review.md audited a service-role key, a cookie adapter and
auth.users, none of which exist. Restating findings about removed components
would suggest today's system had been reviewed; it has not. It now records
what was removed and says a fresh review is due. data-model.md was already
marked obsolete and described the pre-OM schema; azure-migration.md was a
plan for a route not taken. Both deleted.

Verified: npm ci, typecheck, lint, 445 tests, build — all clean without the
packages. Integration tests skip cleanly with no database. Migration SQL and
the runner are reviewed but NOT executed: no Docker here, and the old
instance no longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/build-org.ts

@@ -0,0 +1,149 @@
+// Baut den Organisationsbaum im SAP-OM-Modell aus der fachlichen
+// Bereichsdefinition des Seeds.
+//
+// Bewusst frei von Zufall, Datenbank und IDs aus der Umgebung: die
+// Konstruktion ist die Stelle, an der sich Nummernkreise, Leitungsplanstellen
+// und die Elternbeziehung falsch verdrahten lassen, ohne dass es jemandem
+// auffällt — ein Team unter dem falschen Bereich sieht im Organigramm
+// plausibel aus. Deshalb ist sie eine reine Funktion mit Tests.
+
+export type OrgUnitType = "Gesellschaft" | "Bereich" | "Abteilung" | "Team";
+
+export type TeamDef = { name: string; leadTitle: string; icTitles: string[]; baseSize: number };
+export type DeptDef = { name: string; leadTitle: string; teams: TeamDef[] };
+export type DivisionDef = { name: string; headTitle: string; departments: DeptDef[] };
+
+export type BuiltUnit = {
+  id: string;
+  org_number: string;
+  name: string;
+  parent_id: string | null;
+  unit_type: OrgUnitType;
+};
+
+export type BuiltJob = { id: string; code: string; title: string };
+
+export type BuiltPosition = {
+  id: string;
+  position_number: string;
+  org_unit_id: string;
+  job_id: string;
+  is_chief: boolean;
+};
+
+export type BuiltOrg = {
+  units: BuiltUnit[];
+  jobs: BuiltJob[];
+  positions: BuiltPosition[];
+  /** Für jedes Team die Planstellen der Mitarbeitenden, in Reihenfolge. */
+  icPositionsByTeam: Map<string, BuiltPosition[]>;
+};
+
+// Nummernkreise wie im Altmodell, damit die Nummern der Einheiten über den
+// Umstieg hinweg wiedererkennbar bleiben.
+const PREFIX: Record<OrgUnitType, string> = {
+  Gesellschaft: "10",
+  Bereich: "20",
+  Abteilung: "21",
+  Team: "22",
+};
+
+function orgNumber(type: OrgUnitType, counter: number): string {
+  return `${PREFIX[type]}${String(counter).padStart(6, "0")}`;
+}
+
+/** Planstellennummern folgen dem bestehenden Muster ^6\d{7}$. */
+function positionNumber(counter: number): string {
+  return `6${String(counter).padStart(7, "0")}`;
+}
+
+function jobCode(counter: number): string {
+  return `J${String(counter).padStart(4, "0")}`;
+}
+
+/**
+ * `newId` wird hereingereicht, damit die Funktion in Tests deterministisch
+ * bleibt und im Seed randomUUID benutzt.
+ */
+export function buildOrg(
+  companyName: string,
+  divisions: DivisionDef[],
+  newId: () => string
+): BuiltOrg {
+  const units: BuiltUnit[] = [];
+  const positions: BuiltPosition[] = [];
+  const icPositionsByTeam = new Map<string, BuiltPosition[]>();
+
+  // Job-Katalog: gleiche Tätigkeit, ein Eintrag. Vorher war job_title
+  // Freitext je Person, weshalb sich Tätigkeiten nicht auswerten liessen.
+  const jobIdByTitle = new Map<string, string>();
+  const jobs: BuiltJob[] = [];
+  function jobFor(title: string): string {
+    const existing = jobIdByTitle.get(title);
+    if (existing) return existing;
+    const job = { id: newId(), code: jobCode(jobs.length + 1), title };
+    jobs.push(job);
+    jobIdByTitle.set(title, job.id);
+    return job.id;
+  }
+
+  let unitCounter = { Gesellschaft: 0, Bereich: 0, Abteilung: 0, Team: 0 };
+  let positionCounter = 0;
+
+  function addUnit(name: string, type: OrgUnitType, parentId: string | null): BuiltUnit {
+    unitCounter = { ...unitCounter, [type]: unitCounter[type] + 1 };
+    const unit: BuiltUnit = {
+      id: newId(),
+      org_number: orgNumber(type, unitCounter[type] * (type === "Team" ? 1000 : type === "Abteilung" ? 10000 : 100000)),
+      name,
+      parent_id: parentId,
+      unit_type: type,
+    };
+    units.push(unit);
+    return unit;
+  }
+
+  function addPosition(unitId: string, title: string, isChief: boolean): BuiltPosition {
+    positionCounter += 1;
+    const position: BuiltPosition = {
+      id: newId(),
+      position_number: positionNumber(positionCounter),
+      org_unit_id: unitId,
+      job_id: jobFor(title),
+      is_chief: isChief,
+    };
+    positions.push(position);
+    return position;
+  }
+
+  const company = addUnit(companyName, "Gesellschaft", null);
+  addPosition(company.id, "Geschäftsführer:in", true);
+  // Die Assistenz hängt an der Gesellschaft, führt sie aber nicht — genau
+  // die Unterscheidung, die es im Altmodell nicht gab.
+  addPosition(company.id, "Assistenz der Geschäftsführung", false);
+
+  for (const div of divisions) {
+    const bereich = addUnit(div.name, "Bereich", company.id);
+    addPosition(bereich.id, div.headTitle, true);
+
+    for (const dept of div.departments) {
+      const abteilung = addUnit(dept.name, "Abteilung", bereich.id);
+      // Die Ebene, die im Altmodell gefehlt hat: eine Abteilung hat jetzt
+      // eine eigene Leitungsplanstelle.
+      addPosition(abteilung.id, dept.leadTitle, true);
+
+      for (const team of dept.teams) {
+        const teamUnit = addUnit(team.name, "Team", abteilung.id);
+        addPosition(teamUnit.id, team.leadTitle, true);
+
+        const size = Math.max(1, team.baseSize);
+        const icPositions = Array.from({ length: size }, (_, i) =>
+          addPosition(teamUnit.id, team.icTitles[i % team.icTitles.length], false)
+        );
+        icPositionsByTeam.set(teamUnit.id, icPositions);
+      }
+    }
+  }
+
+  return { units, jobs, positions, icPositionsByTeam };
+}

scripts/check-schema-types.mjs

@@ -1,8 +1,8 @@
 #!/usr/bin/env node
-// Guards lib/supabase/types.ts against drifting away from the migrations.
+// Guards lib/types.ts against drifting away from the migrations.
 //
 // That file is maintained by hand (its own header explains why: no DB
-// connection string is available to run `supabase gen types`), so a new
+// Werkzeug erzeugt sie), so a new
 // column reaches the database without the TypeScript side noticing — and
 // `tsc` stays perfectly happy while the app reads a field that is typed but
 // absent, or writes one that exists but is not typed.
@@ -16,7 +16,7 @@ import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
 
 const root = join(dirname(fileURLToPath(import.meta.url)), "..");
-const migrationsDir = join(root, "supabase", "migrations");
+const migrationsDir = join(root, "db", "migrations");
 
 // Columns are compared, not their types: the hand-written file deliberately
 // uses richer unions than the SQL (`EmploymentStatus` for a text column with
@@ -98,9 +98,9 @@ function parseMigrations() {
 }
 
 function parseTypes() {
-  const source = readFileSync(join(root, "lib", "supabase", "types.ts"), "utf8");
+  const source = readFileSync(join(root, "lib", "types.ts"), "utf8");
   const start = source.indexOf("Tables: {");
-  if (start === -1) throw new Error("Tables block not found in lib/supabase/types.ts");
+  if (start === -1) throw new Error("Tables block not found in lib/types.ts");
 
   const tables = new Map();
   // Each entry looks like `name: NoRelationships & { Row: { … } … }`; the Row
@@ -149,7 +149,7 @@ for (const [name, columns] of tsTables) {
 }
 
 if (problems.length > 0) {
-  console.error("Schema-Drift zwischen supabase/migrations und lib/supabase/types.ts:\n");
+  console.error("Schema-Drift zwischen db/migrations und lib/types.ts:\n");
   for (const p of problems.sort()) console.error("  - " + p);
   console.error(`\n${problems.length} Abweichung(en). types.ts entsprechend nachziehen.`);
   process.exit(1);

scripts/migrate.mjs

@@ -1,23 +1,19 @@
 #!/usr/bin/env node
 // Spielt ausstehende Migrationen ein — und führt Buch darüber.
 //
-// ═══ Warum ein eigener Läufer und nicht `supabase db push` ═══
+// ═══ Warum ein eigener Läufer ═══
 //
 // Zwei Gründe, beide praktisch:
 //
-// 1. **Er braucht nur `pg`.** Das Paket liegt ohnehin im Projekt. Die
-//    Supabase-CLI müsste im Runner-Container bei jedem Lauf heruntergeladen
-//    werden, und ihre Version driftet unabhängig von diesem Repository.
-// 2. **Er tut genau eine Sache.** `db push` vergleicht Schemata, erzeugt
-//    Diffs und kann bei einer Abweichung mehr tun als nur die fehlenden
-//    Dateien anzuwenden. Beim automatischen Ausrollen ist „nur die fehlenden
-//    Dateien, in Reihenfolge, jede in ihrer eigenen Transaktion" genau das
-//    gewünschte Verhalten und nichts darüber hinaus.
+// 1. **Er braucht nur `pg`.** Das Paket liegt ohnehin im Projekt. Jedes
+//    zusätzliche Werkzeug müsste im Runner-Container bei jedem Lauf
+//    heruntergeladen werden, und seine Version driftet unabhängig von
+//    diesem Repository.
+// 2. **Er tut genau eine Sache.** Nur die fehlenden Dateien, in Reihenfolge,
+//    jede in ihrer eigenen Transaktion. Beim automatischen Ausrollen ist das
+//    genau das gewünschte Verhalten und nichts darüber hinaus.
 //
-// Die Buchführung liegt bewusst in `supabase_migrations.schema_migrations` —
-// derselben Tabelle in derselben Form, die die CLI benutzt. Damit bleibt
-// `supabase db push` weiterhin möglich, etwa von der Arbeitsstation aus: es
-// sieht dieselben Einträge und überspringt, was hier schon lief.
+// Die Buchführung liegt in `migrationen.schema_migrations`.
 //
 // ═══ Aufrufe ═══
 //
@@ -29,14 +25,14 @@
 // `--baseline` ist für den einen Fall gedacht, in dem eine Datenbank schon auf
 // dem Stand ist, die Buchführung aber fehlt — genau die Lage dieses Projekts
 // im August 2026, weil die Migrationen bis dahin von Hand eingespielt wurden.
-// Ohne diesen Schritt hielte der Läufer alle 65 für ausstehend und würde sie
+// Ohne diesen Schritt hielte der Läufer alle 67 für ausstehend und würde sie
 // gegen eine bereits migrierte Datenbank laufen lassen.
 
 import { readdirSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 import pg from "pg";
 
-const VERZEICHNIS = "supabase/migrations";
+const VERZEICHNIS = "db/migrations";
 
 const argumente = new Set(process.argv.slice(2));
 const nurZeigen = argumente.has("--dry-run");
@@ -45,13 +41,8 @@ const baseline = argumente.has("--baseline");
 // Der **direkte** Zugang als Verwalter — nicht DATABASE_URL.
 //
 // DATABASE_URL gehört der Anwendungsrolle, und die darf bewusst kein Schema
-// ändern; ausserdem zeigte sie bei Supabase auf den Transaktions-Pooler, der
-// mehrteilige Transaktionen nicht mitmacht.
-//
-// `SUPABASE_DB_URL` heisst nach dem Umzug auf einen eigenen Container nicht
-// mehr, was es ist — der Name bleibt als Rückfallebene, damit bestehende
-// .env-Dateien und Arbeitsstationen weiterlaufen.
-const verbindung = process.env.MIGRATE_DATABASE_URL || process.env.SUPABASE_DB_URL;
+// ändern.
+const verbindung = process.env.MIGRATE_DATABASE_URL;
 if (!verbindung) {
   console.error(
     "MIGRATE_DATABASE_URL fehlt. Erwartet wird der **direkte** Zugang als Verwalter,\n" +
@@ -79,17 +70,39 @@ const client = new pg.Client({
 await client.connect();
 
 try {
-  // Dieselbe Form, die die Supabase-CLI anlegt und erwartet.
-  await client.query(`create schema if not exists supabase_migrations`);
+  await client.query(`create schema if not exists migrationen`);
   await client.query(`
-    create table if not exists supabase_migrations.schema_migrations (
+    create table if not exists migrationen.schema_migrations (
       version text primary key,
       statements text[],
       name text
     )`);
 
+  // ── Einmalige Übernahme der alten Buchführung ──────────────────────
+  //
+  // Bis zum Umzug lagen die Einträge in `supabase_migrations.schema_migrations`.
+  // Ohne diese Übernahme fände der Läufer eine leere Tabelle vor, hielte alle
+  // 67 Migrationen für ausstehend und spielte sie gegen eine Datenbank ein,
+  // die längst auf dem Stand ist — mit einem Fehler beim ersten `create table`,
+  // das es schon gibt.
+  //
+  // Übernommen wird nur in eine noch **leere** Tabelle: ein zweiter Lauf tut
+  // nichts mehr. Auf einer frischen Datenbank gibt es die alte Tabelle nicht,
+  // dann fällt die Abfrage ganz weg.
+  const alteTabelle = (
+    await client.query(`select to_regclass('supabase_migrations.schema_migrations') is not null as da`)
+  ).rows[0]?.da;
+  if (alteTabelle) {
+    const { rowCount } = await client.query(`
+      insert into migrationen.schema_migrations (version, statements, name)
+      select version, statements, name from supabase_migrations.schema_migrations
+      where not exists (select 1 from migrationen.schema_migrations)
+      on conflict (version) do nothing`);
+    if (rowCount > 0) console.log(`${rowCount} Einträge aus der alten Buchführung übernommen.`);
+  }
+
   const verbucht = new Set(
-    (await client.query(`select version from supabase_migrations.schema_migrations`)).rows.map((r) => r.version)
+    (await client.query(`select version from migrationen.schema_migrations`)).rows.map((r) => r.version)
   );
 
   const ausstehend = dateien.filter((f) => !verbucht.has(zerlegen(f).version));
@@ -112,7 +125,7 @@ try {
       const { version, name } = zerlegen(datei);
       const inhalt = readFileSync(join(VERZEICHNIS, datei), "utf8");
       await client.query(
-        `insert into supabase_migrations.schema_migrations (version, statements, name)
+        `insert into migrationen.schema_migrations (version, statements, name)
          values ($1, $2, $3) on conflict (version) do nothing`,
         [version, [inhalt], name]
       );
@@ -135,7 +148,7 @@ try {
     try {
       await client.query(inhalt);
       await client.query(
-        `insert into supabase_migrations.schema_migrations (version, statements, name) values ($1, $2, $3)`,
+        `insert into migrationen.schema_migrations (version, statements, name) values ($1, $2, $3)`,
         [version, [inhalt], name]
       );
       await client.query("commit");

scripts/umzug-von-supabase.sh

@@ -1,77 +0,0 @@
-#!/usr/bin/env bash
-# Holt den Datenbestand von Supabase und spielt ihn in den db-Container.
-#
-# ═══ Der Ablauf, und warum er so aussieht ═══
-#
-# Das **Schema** kommt nicht aus dem Abzug, sondern aus den Migrationen:
-# scripts/migrate.mjs baut es im Container von Grund auf. Nachgewiesen ist,
-# dass dabei Spalte für Spalte, Index für Index, Policy für Policy dasselbe
-# herauskommt wie in der Produktion. Der Weg über die Migrationen hat zwei
-# Vorteile gegenüber einem Schema-Abzug: die Buchführung stimmt danach von
-# selbst, und was Supabase an eigenen Rechten und Eigentümern hineingeschrieben
-# hat, kommt gar nicht erst mit.
-#
-# Übernommen werden nur die **Daten**, mit --disable-triggers: sonst stolpert
-# jede Fremdschlüsselprüfung über die Ladereihenfolge. (RLS steht dem nicht im
-# Weg — keine der 19 Tabellen hat FORCE ROW LEVEL SECURITY, der Eigentümer
-# schreibt also durch.)
-#
-# Auf dem Host wird **nur Docker** gebraucht: psql und pg_dump kommen aus dem
-# Dienst `psql`, Node aus dem Dienst `migrate` — beide im Profil `tools`, das
-# bei einem gewöhnlichen `docker compose up` nicht mitläuft.
-#
-# Aufruf im Deploy-Verzeichnis:
-#
-#   SUPABASE_DB_URL='postgresql://…@…supabase.com:5432/postgres' \
-#     ./scripts/umzug-von-supabase.sh
-#
-# Der Abzug bleibt als Datei liegen und wird nicht gelöscht: geht das
-# Einspielen schief, ist der Bestand sonst nur noch bei Supabase.
-
-set -euo pipefail
-
-: "${SUPABASE_DB_URL:?SUPABASE_DB_URL fehlt — der direkte Zugang zur alten Datenbank (Supabase: Port 5432)}"
-
-ABZUG="${ABZUG:-supabase-daten-$(date +%Y%m%d-%H%M%S).sql}"
-
-echo "── 1/5  Datenbank starten und abwarten"
-docker compose up -d db
-docker compose ps db
-
-echo
-echo "── 2/5  Schema aus den Migrationen aufbauen"
-docker compose run --rm migrate
-
-echo
-echo "── 3/5  Daten von Supabase abziehen  → ${ABZUG}"
-# Läuft im psql-Abbild, damit pg_dump nicht auf dem Host installiert sein muss.
-# --entrypoint überschreibt den psql-Aufruf des Dienstes.
-docker compose run --rm --no-deps --entrypoint pg_dump psql \
-  "${SUPABASE_DB_URL}" \
-  --data-only \
-  --disable-triggers \
-  --schema=public \
-  --no-owner \
-  --no-privileges \
-  > "${ABZUG}"
-echo "     $(wc -l < "${ABZUG}") Zeilen, $(du -h "${ABZUG}" | cut -f1)"
-
-echo
-echo "── 4/5  Einspielen"
-docker compose run --rm -T psql < "${ABZUG}"
-
-echo
-echo "── 5/5  Gegenprobe — Zeilenzahlen hier und dort"
-echo "     neue Datenbank:"
-docker compose run --rm -T psql -qAt -c "
-  select '       '||table_name||': '||(xpath('/row/c/text()',
-         query_to_xml('select count(*) as c from public.'||quote_ident(table_name), false, true, '')))[1]::text
-    from information_schema.tables
-   where table_schema='public' and table_type='BASE TABLE' order by table_name"
-
-echo
-echo "Fertig. Nächster Schritt: DATABASE_URL in .env auf den Container zeigen"
-echo "lassen (siehe DEPLOYMENT.md), dann  docker compose up -d --build"
-echo
-echo "Der Abzug bleibt unter ${ABZUG} liegen — erst löschen, wenn die Anwendung"
-echo "gegen die neue Datenbank nachweislich läuft."