Partner Flutter App

Anfangs hängte jede Feature-Tabelle an einer `relation_id` — also fest an genau zwei Konten. Jede Erweiterung hätte an jeder Tabelle einzeln nachgezogen werden müssen, und die Rechteregeln waren über die Module verteilt.

Umstellung auf ein Gruppenmodell: eine Gruppe, Mitgliedschaften, und überall `group_id`. Row-Level-Security prüft nur noch gegen die Mitgliedschaft. Die Krypto-Tabellen blieben absichtlich bei `relation_id` — dort ist die Zweierbindung die Zusicherung, nicht ein Altlast-Detail.

Das Backend lag in der gehosteten Supabase-Cloud. Der Umzug auf eigene Infrastruktur betraf 83 Tabellen mit Row-Level-Security, Storage, Edge Functions und die laufende Anmeldung — alles gleichzeitig.

Umzug auf eine self-hosted Instanz hinter Coolify, mit Schema- und Vollbackup als Makefile-Ziel und der alten Cloud-Referenz als Rückfallebene. Datenbankzugriff seitdem über SSH und `docker exec`, der Ablauf steht in der Betriebsdoku.

Store-Webhooks können kein Nutzer-JWT mitschicken. Der bequeme Weg ist `--no-verify-jwt` beim Deploy — dann ist die Funktion aber für jeden offen, der die URL kennt.

Die JWT-Pflicht wird pro Funktion in der `config.toml` gesetzt, nicht pauschal per Flag. Die drei öffentlichen Funktionen prüfen dafür ihre eigene Signatur beziehungsweise ein Secret; die Verifikationsfunktion bleibt JWT-pflichtig. Jede neue öffentliche Funktion braucht eine dokumentierte Ersatz-Authentifizierung.

Über die Zeit waren Bereiche dazugekommen, die weder zum Kern gehörten noch Store-Abnahmen leichter machten — KI-Funktionen, ein zweiter Speicher, mehrere Spielereien.

Bewusster Rückbau statt Mitschleppen: KI-Dienste und die zugehörige Edge Function entfernt, zweite Speicherinstanz aufgelöst, Nebenfunktionen gestrichen. Was nicht enthalten ist, steht ausdrücklich in der Produktdoku — auch das ist eine Zusage.