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>

.github/workflows/ci.yml

@@ -29,25 +29,45 @@ jobs:
       - name: Typecheck
         run: npm run typecheck
 
-      # Catches the drift that `tsc` cannot: lib/supabase/types.ts is
-      # hand-written, so a migration adding a column leaves it silently stale.
+      # Fängt die Abweichung, die `tsc` nicht sehen kann: lib/types.ts wird von
+      # Hand gepflegt, eine Migration mit einer neuen Spalte lässt sie also
+      # stillschweigend veralten.
       - name: Schema/Typen-Abgleich
         run: npm run types:check
 
       - name: Unit- und Komponententests
         run: npm test
 
+      # Ohne Umgebungsvariablen: seit dem Wegfall der Browser-Anbindung wird
+      # zur Bauzeit nichts mehr aus der Umgebung gelesen, und das Abbild ist
+      # für jede Umgebung dasselbe.
       - name: Build
         run: npm run build
-        env:
-          # Read at module scope by the Supabase browser client, so the build
-          # needs them present — never the real project's values.
-          NEXT_PUBLIC_SUPABASE_URL: http://127.0.0.1:54321
-          NEXT_PUBLIC_SUPABASE_ANON_KEY: build-time-placeholder
 
-  integration:
-    name: Integrationstests (echtes Postgres)
+  migrationen:
+    name: Migrationen auf leerer Datenbank
     runs-on: ubuntu-latest
+
+    # Derselbe Stand wie im Betrieb. Ein eigener Dienst statt einer fremden
+    # Plattform — die Datenbank gehört seit dem Umzug zum Projekt.
+    services:
+      postgres:
+        image: postgres:17-alpine
+        env:
+          POSTGRES_PASSWORD: ci
+          POSTGRES_DB: alpenwerk
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U postgres"
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 20
+
+    env:
+      MIGRATE_DATABASE_URL: postgresql://postgres:ci@127.0.0.1:5432/alpenwerk
+      DATABASE_SSL: "false"
+
     steps:
       - uses: actions/checkout@v4
 
@@ -58,40 +78,37 @@ jobs:
 
       - run: npm ci
 
-      - uses: supabase/setup-cli@v1
-        with:
-          version: latest
-
-      # Applies every migration to a fresh database — which also means a
-      # migration that cannot be replayed from scratch fails here rather than
-      # on a restore or a new environment.
-      - name: Supabase starten
-        run: supabase start
-
-      # `-o env` emits API_URL / ANON_KEY / SERVICE_ROLE_KEY / DB_URL; the app
-      # expects them under its own names. DATABASE_URL ist der direkte
-      # Postgres-Zugang — den braucht die neue Zugriffsschicht (lib/db) und
-      # vor allem der Nachweis zum Sitzungskontext.
-      - name: Testumgebung schreiben
+      # Was das Schema von der Umgebung erwartet: die Anwendungsrolle ohne
+      # BYPASSRLS, zwei Erweiterungen und die Attrappe des `auth`-Schemas, ohne
+      # die sich die Migrationen von Juni 2026 nicht abspielen lassen.
+      - name: Rollen, Erweiterungen, auth-Attrappe
+        env:
+          PGPASSWORD: ci
+          APP_DB_PASSWORD: ci-anwendungsrolle
         run: |
-          supabase status -o env \
-            --override-name api.url=NEXT_PUBLIC_SUPABASE_URL \
-            --override-name auth.anon_key=NEXT_PUBLIC_SUPABASE_ANON_KEY \
-            --override-name auth.service_role_key=SUPABASE_SERVICE_ROLE_KEY \
-            --override-name db.url=DATABASE_URL \
-            | grep -E '^(NEXT_PUBLIC_SUPABASE_URL|NEXT_PUBLIC_SUPABASE_ANON_KEY|SUPABASE_SERVICE_ROLE_KEY|DATABASE_URL)=' \
-            | tr -d '"' > .env.test.local
-          # Lokal läuft Postgres ohne TLS; ohne das versucht `pg` es trotzdem.
-          echo "DATABASE_SSL=false" >> .env.test.local
-          grep -q '^DATABASE_URL=' .env.test.local \
-            || { echo "DATABASE_URL wurde nicht geschrieben — der Sitzungskontext-Nachweis liefe ins Leere."; exit 1; }
+          for f in deploy/db-init/*.sql; do
+            echo "── $f"
+            psql -v ON_ERROR_STOP=1 -h 127.0.0.1 -U postgres -d alpenwerk -f "$f"
+          done
 
-      - name: Seed
-        run: node --env-file=.env.test.local supabase/seed.ts
+      # Der eigentliche Zweck dieses Jobs: jede Migration muss sich auf einer
+      # leeren Datenbank abspielen lassen. Eine, die das nicht kann, fällt hier
+      # auf — und nicht beim Wiederherstellen einer Sicherung oder beim
+      # Aufsetzen einer neuen Umgebung.
+      - name: Migrationen einspielen
+        run: node scripts/migrate.mjs
 
-      - name: Integrationstests
-        run: npm run test:integration
+      # Zweiter Lauf: die Buchführung muss greifen. Meldet er etwas anderes als
+      # „nichts anzuwenden", verbucht der Läufer nicht richtig — und ein
+      # Ausrollen spielte Migrationen doppelt ein.
+      - name: Zweiter Lauf ist ein Nichts
+        run: |
+          ausgabe=$(node scripts/migrate.mjs)
+          echo "$ausgabe"
+          echo "$ausgabe" | grep -q "^Nichts anzuwenden" \
+            || { echo "Der zweite Lauf wollte erneut anwenden — die Buchführung greift nicht."; exit 1; }
 
-      - name: Supabase-Logs bei Fehlschlag
-        if: failure()
-        run: supabase status && docker ps -a
+      # Die Integrationstests brauchen einen befüllten Bestand; der Seed lag
+      # in der abgelösten Umgebung und ist noch nicht nachgezogen (siehe
+      # README, offene Punkte). Bis dahin laufen sie gegen eine erreichbare
+      # Datenbank von Hand, nicht hier.

.github/workflows/deploy.yml

@@ -96,7 +96,7 @@ jobs:
       - name: .env schreiben
         env:
           DATABASE_URL: ${{ secrets.DATABASE_URL }}
-          SUPABASE_DB_URL: ${{ secrets.SUPABASE_DB_URL }}
+          MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
           AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
           AUTH_URL: ${{ secrets.AUTH_URL }}
           AUTH_MICROSOFT_ENTRA_ID_ID: ${{ secrets.AUTH_MICROSOFT_ENTRA_ID_ID }}
@@ -106,7 +106,7 @@ jobs:
         run: |
           set -euo pipefail
           fehlend=""
-          for name in DATABASE_URL SUPABASE_DB_URL AUTH_SECRET AUTH_URL \
+          for name in DATABASE_URL MIGRATE_DATABASE_URL AUTH_SECRET AUTH_URL \
                       AUTH_MICROSOFT_ENTRA_ID_ID AUTH_MICROSOFT_ENTRA_ID_SECRET \
                       AUTH_MICROSOFT_ENTRA_ID_ISSUER CRON_SECRET; do
             eval "wert=\${$name:-}"
@@ -138,12 +138,12 @@ jobs:
       # wenn danach etwas schiefgeht.
       - name: Ausstehende Migrationen zeigen
         env:
-          SUPABASE_DB_URL: ${{ secrets.SUPABASE_DB_URL }}
+          MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
         run: node scripts/migrate.mjs --dry-run
 
       - name: Migrationen anwenden
         env:
-          SUPABASE_DB_URL: ${{ secrets.SUPABASE_DB_URL }}
+          MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
         run: node scripts/migrate.mjs
 
       # ── Container ───────────────────────────────────────────────────