Shuffle/docs/specs/13-umsetzung.md

Spec #13 – KAT-04 Fehlendes Spiel melden: Umsetzungs-Nachtrag PR 13a (Backend)

Ergänzt docs/specs/13-fehlendes-spiel-melden.md (die Spec selbst wird hier nicht geändert). Stand: 2026-11-04, Branch feature/13a-fehlendes-spiel-backend (die Spec nennt feature/13a-meldungen-backend), Migration 20261104100000_game_reports_user.sql, Tests supabase/tests/database/10_game_reports_user.test.sql.

0. Entscheidung von Chris (2026-11-04, Option B, Spec-F10): kein „abgelehnt mit Verweis“

Dies ist eine Entscheidung von Chris, sie ändert Spec #2 Spec-F3. adopt_report_target (Funktion, Grants, Tests) wurde vollständig entfernt; ebenso entfallen die App-Zustände rejectedWithTarget, rejectedReference und rejectedAdopted. Wer auf einen vorhandenen Eintrag verweisen will, setzt merged (direktes Umhängen, ohne Nutzeraktion). rejected gibt es nur ohne Ziel.

• admin_resolve_report ist per create or replace ersetzt (Rumpf aus 2c unverändert, einzige Ergänzung: rejected mit p_target → report_reject_has_target, P0001; Kommentar zu rejected angepasst). Rechte-Revoke ausdrücklich wiederholt.
• Neuer Check game_reports_rejected_no_target (status <> 'rejected' or target_game_id is null). Verträglich mit admin_merge_games (hängt nur Ziele von approved/merged um) und repoint_game_references; keine Altdaten betroffen (2c ist nicht ausgerollt).
• Tests: 08 (Fixtures „rejected mit Ziel“ → merged, neuer Test für den Check, rejected mit Ziel → report_reject_has_target, Runbook-Baustein 3c ohne Ziel), 10 (Abschnitt „adopt“ ersetzt durch merged/rejected-Tests). result_seen_at (Spalte, Recht, Policy „Verstanden“) bleibt.
• Für 13b: nur noch Zustände pending / approved / merged / rejected (ohne Ziel); der Edition-Hinweis gilt bei approved und merged.
• Spec-F10 statt F9: Die Nummer F9 ist in der Spec schon durch die vorausgewählte Liste belegt.

1. Abweichungen und Präzisierungen zum Vertrag

• Spec-F6 ist entschieden und umgesetzt (2c): game_reports.editions_cleared und die Zuweisung in admin_resolve_report stehen schon in der Migration game_reports (PR 2c); 13a legt die Spalte nicht an.

• Tageslimit gilt auch für postgres: Der Trigger game_reports_daily_limit unterscheidet nicht nach Rolle (Spec 3.2). Fixtures, die als postgres mehr als 10 Nutzer-Meldungen „von heute“ für einen Nutzer anlegen, scheitern deshalb. Folge für die Tests: 08_game_reports.test.sql schaltet den Trigger am Anfang ab (alter table … disable trigger, mit dem Rollback am Ende zurückgenommen); in 10 bekommen Fixtures für gestern/älter feste Zeitstempel. Außerdem ist created_at nach dem Anlegen unveränderlich (Trigger set_updated_at), alte Zeitstempel müssen also beim Einfügen gesetzt werden.

• Limit-Zählung über report_day(created_at) = report_day(now()) (nicht die optionale Bereichsform aus Spec 3.2); bei höchstens 10 Zeilen je Nutzer und Tag spielt der Index (owner_id, created_at) keine Rolle.

• Trimmen: report_missing_game trimmt Leerzeichen, Tab, CR und LF (nicht nur Leerzeichen). Titel, Verlag und Link werden vor allen Prüfungen getrimmt, Längen gelten für den getrimmten Wert.

• find_similar_catalog_games: Der Titel wird vor der Normalisierung getrimmt und die Länge (1 bis 200) am getrimmten Wert geprüft. Ist der normalisierte Titel leer (kann nach normalize_game_title nur bei leerem Rest vorkommen), gibt es keine Treffer. Je Spiel wird der beste Kandidatentitel gewählt: gleicher Schlüssel vor Ähnlichkeit, dann Haupttitel vor alternativen Titeln, dann Schreibweise. Verlage sind nach publishers.name_search, dann name sortiert (wie in search_catalog_games). Bei gleicher Ähnlichkeit sortiert das Ergebnis nach title, dann game_id. Die Ähnlichkeit bei same_title ist immer 1.0.

• report_provisional_in_use: Der Handler um den Insert in game_reports wertet den Namen des verletzten Index (game_reports_provisional_game_id_key) aus; andere Unique-Verletzungen laufen unverändert weiter. Über die RPC ist der Fall nicht erreichbar (jeder Aufruf legt ein frisches Spiel an); der Test lenkt ihn mit einem temporären Trigger herbei.

• Testplan: 00_schema unverändert (22 Tabellen), 07/08-Fremdschlüssel-Wächter unberührt (kein neuer Fremdschlüssel), 08 um das Abschalten des Limit-Triggers ergänzt und nach Spec-F10 angepasst (Fixtures „rejected mit Ziel“ → merged, Tests zu report_reject_has_target und zum Check game_reports_rejected_no_target, Runbook-Baustein 3c ohne Ziel); die Spaltenrechte-Tests aus 08 waren schon auf result_seen_at und die Insert-Spalten ausgelegt.

• Review-Nachbesserungen: find_similar_catalog_games behandelt ein Jahr außerhalb 1800-2100 wie null (kein Überlauf, kein 22003). Zusätzliche Tests: Tagesgrenze Berlin (10 Meldungen kurz nach Mitternacht Berlin, Trigger und Vorprüfung), Trimmen von Tab/Zeilenumbruch.

• 08-Fixtures (N3) bleiben bei disable trigger: Ben und weitere Nutzer haben dort über 20 Fixture-Inserts mit Standard-created_at; sie alle auf feste alte Zeitstempel umzustellen wäre ein großer, fehleranfälliger Eingriff in 2c-Tests. Das Limit prüft 10 ausführlich.

• Zielsperre (N1) unverändert for update: nicht umgestellt, weil admin_resolve_report und admin_merge_games ebenfalls for update sperren und eine gemischte Sperrstufe die Verklemmungsanalyse (Spec R2) ändern würde.

• Check ohne NOT VALID (Einspielen auf Staging/Prod): game_reports_rejected_no_target prüft beim Anlegen alle vorhandenen Zeilen. Vor dem Einspielen von 13a prüfen: select count(*) from public.game_reports where status = 'rejected' and target_game_id is not null; Bei Treffern vorher bereinigen (Ziel auf null setzen oder Status auf merged umstellen). Der Punkt steht in docs/release-checkliste.md.

• Uhrzeitabhängigkeit: Die Mitternachtstests (Tagesgrenze) hängen an der Uhrzeit: Läuft der Test zwischen Mitternacht Berlin und Mitternacht UTC, hat created_at dasselbe UTC-Datum wie now() und die Mutante created_at::date = now()::date überlebt. Das Verhalten der Funktion ist davon nicht betroffen.

2. Mutationsprüfung

Die Mutanten sind veränderte Kopien der Migration, jeweils in einer Transaktion zusammen mit dem Testlauf angewendet und mit dem Rollback des Tests zurückgenommen (am echten Schema bleibt nichts). Die Skripte liegen nicht im Repo. Ergebnis siehe Bericht an Chris; die überlebenden Mutanten sind entweder Doppelabsicherungen (zum Beispiel origin = 'user' in der Insert-Policy, die schon durch die Spaltenrechte gesichert ist) oder nur mit Parallelität testbar (Advisory-Lock).

3. Offene Punkte

• Paralleltest des Limits (zwei psql-Sitzungen unter READ COMMITTED) ist nicht automatisiert (Spec 7.1) und gehört zu T1.