refactor(db): move the Better Auth tables to schema identity (#60)

[Fluory]

Warum

Fixes #60 · Supabase belegt das Schema auth für sein eigenes Login-System. Unsere Better-Auth-Tabellen lagen im gleichen Schema – ohne Änderung läuft die Datenbank nicht auf Supabase (Vorbereitung Vercel + Supabase, #59/#64). Basis main (enthält #62 mit Migration 0017).

Arbeitsstand

• Ziel: Better-Auth-Tabellen im Schema identity (Name des Moduls) – auf frischen Datenbanken direkt, auf bestehenden per Umbenennung; Daten und Rechte unverändert.
• Nicht-Ziele: Umbenennung von Tabellen oder Code-Modulen; Änderungen an Better Auth.
• Erledigt: Test zuerst (RLS-Guard, Migrations-Guard), Schema-Name, Migrationen 0001–0017 auf identity, 0018 als besitzgebundene Umbenennung, drizzle.config.ts, Doku, CHANGELOG; frischer Review eingearbeitet (Blocker behoben); verify + E2E grün auf einer eigenen, migrierten DB; main eingemergt.
• Offen: CI, Merge.
• Annahmen: Der Drizzle-Migrator vergleicht nur Zeitstempel, nicht Hashes bereits angewendeter Migrationen (belegt: DB mit alter 0001 migriert sauber weiter).
• Nächster kleinster Schritt: Merge nach grüner CI; danach feat(deploy): prepare the Vercel showcase with Supabase (#59) #64.

Was ist passiert (Klartext)

Die Tabellen für Anmeldung, Firmen und Einladungen liegen in der Datenbank jetzt in einem Bereich namens identity statt auth. Grund: Supabase reserviert auth für sich selbst. Eine neue Datenbank (z. B. bei Supabase) bekommt identity direkt und fasst Supabases eigenes auth nie an. Eine bestehende Datenbank (lokal, Pilot) wird einmal umbenannt – ohne dass Daten verschoben oder kopiert werden; Verknüpfungen und Rechte bleiben.

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – keine Modulgrenze, öffentliche API, Migration, Auth/Rechte, kein Zahlungs-/Daten-/Infrapfad, höchstens zwei Module, keine Architekturvarianten, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Impact Manifest

• Betroffene Module: db (Schema, Migrationen), identity (nur der Schema-Name).
• Schnittstellen / Datenänderungen: 0001–0017 nennen identity statt auth (wirkt nur auf frischen DBs – bestehende führen sie nicht erneut aus); 0018_identity_schema.sql: ALTER SCHEMA "auth" RENAME TO "identity" nur, wenn auth der migrierenden Rolle gehört und identity fehlt. Der Generator schlug vor, alle Fremdschlüssel neu anzulegen – unnötig, entfernt; db:generate meldet „No schema changes“.
• Akzeptanzkriterien: Rename the Better Auth schema auth to identity (Supabase reserves auth) #60.
• Testplan: RLS-Guard erwartet identity; neuer Migrations-Guard: keine Migration außer 0018 nennt auth, 0018 ist besitzgebunden; alle Integrationstests und E2E unverändert.
• Verifizierte Fakten: (1) frische DB mit fremdem auth-Schema (wie Supabase) → identity von app_owner, fremdes auth samt Tabelle unberührt; (2) DB bis 0017 mit Daten → identity, Daten da, app_rw hat USAGE/INSERT; Rename behält Grants, Default-Privileges, Indizes, FKs.
• Offene Annahmen: –
• Nicht-Ziele: siehe oben.
• Risiken und Rollback: Kurzer Lock beim Rename. Rollback: ALTER SCHEMA identity RENAME TO auth (nur außerhalb von Supabase).

Geändert

• src/db/schema/auth.ts (pgSchema("identity")), src/db/schema/index.ts, drizzle.config.ts
• src/db/migrations/0001,0002,0003,0006,0011 (Schema-Name), neu 0018_identity_schema.sql, meta/
• tests/integration/rls-guard.test.ts, tests/integration/migrations.test.ts, tests/integration/helpers/stack.ts (Kommentar)
• docs/technical/{architecture,data-model,operations}.md, CHANGELOG.md

Nachweis (SYSTEM.md §11)

• verify:changed: grün
• verify: grün (unit 169, integration 127) gegen eine DB, die bis 0017 migriert war und dann 0018 bekam
• verify:full / E2E-Spec: review-smoke, line-items-smoke 2/2 grün gegen dieselbe DB
• Manueller Prüfnachweis: frische DB mit fremdem auth und bestehende DB mit Daten (siehe Verifizierte Fakten)
• Frischer Review (P1 vor Ready-for-review; Architektur/API/DB immer): refactor(db): move the Better Auth tables to schema identity (#60) #63 (comment) – Blocker behoben

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: –
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku (P0: README): –
  • Technische Doku: docs/technical/data-model.md, operations.md
  • Architekturkarte: docs/technical/architecture.md (Ausnahmenregister)
  • ADR: – (Amendment zu D11 in feat(deploy): prepare the Vercel showcase with Supabase (#59) #64)
  • CHANGELOG [Unreleased] (sichtbares Feature oder Verhalten – im selben PR, nie „später")

Entferntes oder Umbenanntes: Schema auth → identity; docs/ + README gegrept, Treffer bereinigt (ADR bleibt historisch)

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: –

Subagent-Einsätze

• Frischer Review-Subagent (read-only, Sonnet) – 1 Blocker, 1 should, 1 nit – alle behoben.

Risiken / offene Punkte

• Historische Migrationen wurden bewusst angepasst (nur der Schema-Name): bestehende DBs führen sie nicht erneut aus; frische DBs dürfen auth nie anlegen.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DJ5vaKvTYiMvdngT4d3xo1

[Fluory]

Frischer Review (read-only Subagent) – Ergebnis und Umgang

Befund	Umgang
blocking – auf einer frischen Supabase-DB gehört auth schon Supabase; Migration 0001 (CREATE SCHEMA "auth") scheitert, bevor 0018 umbenennt	behoben: 0001–0017 legen und nutzen direkt identity (auf bestehenden DBs laufen sie nicht erneut); 0018 benennt nur um, wenn auth der migrierenden Rolle gehört und identity fehlt. Test: keine Migration außer 0018 nennt auth, 0018 ist an den Besitz gebunden. Nachweis lokal: (1) frische DB mit einem fremden auth-Schema (wie Supabase) → identity angelegt, fremdes auth unberührt; (2) DB bis 0017 mit Daten → nach 0018 identity, Daten und Rechte von app_rw erhalten; verify und beide E2E-Smokes gegen diese DB grün
should – drizzle.config.ts schemaFilter nennt noch auth	behoben
nit – Kommentar in src/db/schema/index.ts	behoben; ADR-Texte bleiben historisch (das Amendment in #64 verweist auf die Umbenennung)

---

Generated by Claude Code