docs(catalog): note default privileges, studio role and schema test count

Refs #2

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

docs/specs/2-katalog-daten.md

@@ -96,6 +96,8 @@ Krit. 3 hat keinen Anteil am Datenmodell und wird vollständig mit dem Import sp
 
 Nur additiv. Bestehende Dateien bleiben unverändert; die Änderung der Rechte auf `games` erfolgt über `revoke`/`grant` in der neuen Datei.
 
+**Rechte-Regel für alle neuen Objekte (2a–2c):** Supabase vergibt für neue Tabellen, Views und Funktionen standardmäßig alle Rechte an `anon`, `authenticated` und `service_role`. Jede neue Tabelle und View bekommt deshalb zuerst `revoke all … from anon, authenticated` und danach nur die genannten Grants (wie in den bestehenden Migrationen und `supabase/README.md`); jede neue Funktion `revoke execute … from public, anon, authenticated`.
+
 **Neue Tabelle `catalog_sources`**
 
 | Spalte | Typ | Hinweis |
@@ -294,7 +296,7 @@ Keine Edge Functions, keine RPCs für die App in dieser Spec.
 
 ### 4.2 Admin-Zugang (self-hosted)
 
-- **Studio läuft als Datenbankrolle `postgres`** und umgeht RLS. Die `is_admin()`-Policies sind deshalb nicht der Studio-Pfad; Schutz bietet allein der Zugang zu Studio.
+- **Studio läuft als Datenbankrolle `postgres` bzw. `supabase_admin`** (je nach Self-Hosting-Setup; D1 bestätigt das mit `select current_user` im Studio-SQL-Editor) und umgeht RLS. Die Admin-Funktionen akzeptieren beide Rollen. Die `is_admin()`-Policies sind deshalb nicht der Studio-Pfad; Schutz bietet allein der Zugang zu Studio.
 - **Studio darf nicht öffentlich erreichbar sein.** Im Self-Hosting gibt es in Studio keine Benutzerverwaltung, nur die Basic-Auth des Gateways (`DASHBOARD_USERNAME`/`DASHBOARD_PASSWORD`). Vorgabe für devops (D1): Studio und der Postgres-Port sind nur über SSH-Tunnel oder VPN erreichbar; Basic-Auth bleibt als zweite Schicht mit starkem Passwort. Gilt ebenso für Staging.
 - **`app_metadata.role = 'admin'`** wird in R1 niemandem gesetzt (E10). Falls doch nötig (R4), geht das nur serverseitig: `update auth.users set raw_app_meta_data = raw_app_meta_data || '{"role":"admin"}' where id = …` als `postgres`; der Nutzer muss sich danach neu anmelden. Das Runbook dokumentiert das als „nicht in R1“.
 
@@ -421,7 +423,7 @@ Die Tests müssen auch mit eingespieltem Startbestand grün sein: Sie legen eige
 | # | Agent | Aufgabe | abhängig von |
 |---|---|---|---|
 | B1 | backend-dev | Migration `<ts>_catalog_foundation.sql` nach 3.2: `catalog_sources` (+ Zeile `bgg`), neue Spalten in `games` mit Checks und Indizes, `publishers`, `game_publishers`, Trigger `games_mark_manual_fields` und `game_links_mark_manual` (Variante nach F4), View `catalog_games`, Spaltenrechte auf `games`, RLS und Grants für alle neuen Tabellen | Freigabe Spec; F4 |
-| B2 | backend-dev | pgTAP `06_catalog_foundation.test.sql` nach 7.1 (Krit. 1, 2, 4, 6, 9, 10, Sicherheit Krit. 2); bestehende Tests mit Startbestand lauffähig halten | B1 |
+| B2 | backend-dev | pgTAP `06_catalog_foundation.test.sql` nach 7.1 (Krit. 1, 2, 4, 6, 9, 10, Sicherheit Krit. 2); bestehende Tests mit Startbestand lauffähig halten; `00_schema.test.sql` prüft fest „genau 17 Tabellen“ → auf 20 anpassen (`catalog_sources`, `publishers`, `game_publishers`), Zahlen in `supabase/README.md` („17 Tabellen, 2 Views“) nachziehen (3 Views mit `catalog_games`) | B1 |
 | B3 | backend-dev | Startbestand-Werkzeug nach 4.3 und F6: `supabase/catalog/vocabulary.sql` (Gerüst; Inhalt nach F8), Format/Skript `build_startbestand.ts` mit Prüfregeln und Deno-Tests, `startbestand.sql` (zunächst leer bzw. nur Kopf), `checks.sql`, `config.toml` `[db.seed] sql_paths`, `seed.sql` bereinigen (keine kollidierenden Begriffe) | B1; F6, F8 |
 | B4 | backend-dev | Doku: `docs/katalog-pflege.md` Abschnitte Zugang, Startbestand, Spiel anlegen/bearbeiten, Admin-Rolle (4.4); `docs/datenmodell-r1.md` (neue Objekte, doppelten Abschnitt zusammenführen); `supabase/README.md` | B1, B3 |
 | U1 | ui-designer | `GameCover` in `core/widgets/` nach 5 (Platzhalter nach F9, Größen, Ladezustand, Semantics, ARB-Schlüssel de/en) | F9 |
@@ -443,7 +445,7 @@ Die Tests müssen auch mit eingespieltem Startbestand grün sein: Sie legen eige
 | # | Agent | Aufgabe | abhängig von |
 |---|---|---|---|
 | B8 | backend-dev | Migration `<ts>_game_reports.sql` nach 3.4: Tabelle, Checks, Indizes, RLS (nur Lesen der eigenen), `admin_resolve_report`, `admin_merge_games` erweitert | 2b gemergt; F3 |
-| B9 | backend-dev | pgTAP `08_game_reports.test.sql` | B8 |
+| B9 | backend-dev | pgTAP `08_game_reports.test.sql`; `00_schema.test.sql` auf 21 Tabellen, README-Zahlen nachziehen | B8 |
 | B10 | backend-dev | Runbook: Abschnitt Meldungen bearbeiten | B8, B9 |
 
 ### 8.4 Reihenfolge und Parallelität
@@ -509,3 +511,5 @@ Fachliche Fragen, die ich nicht selbst entscheiden kann. Jede mit Optionen und E
 ### 2026-11-03 – Entwurf
 
 Erste Fassung durch architect, wartet auf Freigabe und Antworten zu F1–F9.
+
+Nachtrag am selben Tag: Rechte-Regel für neue Objekte (Standardrechte von Supabase erst entziehen) in 3.2 ausdrücklich ergänzt; Studio-Rolle `postgres` bzw. `supabase_admin` (4.2); B2/B9 um die Anpassung von `00_schema.test.sql` (fest „17 Tabellen“) und der README-Zahlen ergänzt.