[KAT-04] Fehlendes Spiel melden #13

Open
opened 2026-11-02 13:40:51 +00:00 by cschlaefke · 8 comments
Owner

Story

Als Nutzer
möchte ich ein fehlendes Spiel melden und sofort als vorläufigen privaten Eintrag nutzen,
damit mich ein Katalogloch nicht beim Erfassen blockiert.

Akzeptanzkriterien

Quelle: requirements/20-r1-akzeptanzkriterien.md § KAT-04 (Referenz in Tests/PR: „KAT-04 Kriterium n“), Stand 2026-11-02 inkl. Klärungen und N12

  • 1. Gegeben ich finde ein Spiel nicht, wenn ich Titel (Pflicht), Verlag, Erscheinungsjahr und optional einen Link angebe, dann wird die Meldung gespeichert und ich erhalte eine Bestätigung.
  • 2. Gegeben es gibt schon einen sehr ähnlichen Katalogeintrag, wenn ich melden will, dann sehe ich ihn zuerst und muss ausdrücklich bestätigen, dass mein Spiel ein anderes ist. „Sehr ähnlich“ heißt: gleicher normalisierter Titel (Groß-/Kleinschreibung, Sonderzeichen und Artikel ignoriert) oder Titel-Ähnlichkeit von mindestens 0,8 (Trigramm) bei Erscheinungsjahr ± 1 (Klärung 15).
  • 3. Gegeben ich habe ein Spiel gemeldet, dann kann ich es als vorläufigen Eintrag in meine Sammlung oder Listen aufnehmen; der Eintrag ist nur für mich sichtbar.
  • 4. Gegeben die Meldung wurde freigegeben, dann ersetzt der Katalogeintrag meinen vorläufigen Eintrag, ohne dass meine eigenen Angaben verloren gehen, und ich sehe das als Hinweis in der App am Eintrag (Klärung 26).
  • 5. Gegeben die Meldung wurde mit einem anderen Eintrag zusammengeführt oder unter Verweis auf einen vorhandenen Eintrag abgelehnt, dann sehe ich das als Hinweis in der App am vorläufigen Eintrag (keine E-Mail), und mein vorläufiger Eintrag verweist auf den richtigen Eintrag (Klärungen 26, 45).
  • 6. (neu) Gegeben die Meldung wurde ohne Zieleintrag abgelehnt, dann bleibt mein vorläufiger Eintrag privat bestehen und ist als „abgelehnt“ markiert (Klärung 26).
  • 7. (neu) Gegeben ich habe heute schon 10 Meldungen abgeschickt, wenn ich eine weitere melden will, dann wird sie nicht gespeichert und ich sehe einen Hinweis auf das Tageslimit (Klärung 27). Meldungen, die der BGG-Import automatisch anlegt (SAM-08 Kriterium 4), zählen nicht auf dieses Limit (N12).
  • 8. (neu) Gegeben ich habe eine Meldung abgeschickt, dann bleibt sie im Status „offen“, bis der Admin sie manuell bearbeitet; eine automatische Freigabe gibt es nicht (Klärungen 6, 27, 44).

Querschnitt

Es gelten alle Querschnittskriterien aus 20-r1-akzeptanzkriterien.md § „Querschnitt für R1“ (Datenschutz QUE-04, Sicherheit der Daten, Sprachen QUE-05, Barrierefreiheit QUE-06, Zustände/Fehler/Netz, Plattformen).
Besonders relevant: Sicherheit der Daten Kriterium 1–3 (Meldungen und vorläufige Einträge nur für Melder und Admin), Zustände Kriterium 3.

Nicht im Scope

  • Öffentliche Anzeige gemeldeter Spiele
  • Bild-Upload zur Meldung (nicht gefordert)
  • E-Mail- oder Push-Benachrichtigung zum Ergebnis (Klärung 45; Benachrichtigungen QUE-01 ab R2)
  • Admin-Oberfläche in der App – Bearbeitung über Supabase Studio (KAT-05 #2, Klärung 44)
  • Automatisches Anlegen von Meldungen beim BGG-Import inkl. Kennzeichen „aus Import“ und Deduplizierung – gehört zu SAM-08 (#25, Kriterium 10)

Klärungen

Verbindlich laut requirements/r1-klaerungen.md (2026-11-02):

  • 6: Neue Tabelle für Meldungen (Status offen/freigegeben/abgelehnt/zusammengeführt, Link, Verweis auf Zieleintrag).
  • 15: „Sehr ähnlich“ = gleicher normalisierter Titel oder Trigramm-Ähnlichkeit ≥ 0,8 bei Erscheinungsjahr ± 1 → Kriterium 2.
  • 26: Ergebnis als Hinweis in der App am vorläufigen Eintrag, keine E-Mail; Ablehnung ohne Zieleintrag → Eintrag bleibt privat, markiert „abgelehnt“ → Kriterien 4–6.
  • 27: Chris prüft jede Meldung manuell; Limit 10 Meldungen je Nutzer und Tag → Kriterien 7, 8.
  • 44/25: Admin bearbeitet Meldungen über Supabase Studio/SQL.
  • 45: Keine E-Mail zum Meldungsergebnis.
  • N12: Automatisch beim BGG-Import erzeugte Meldungen zählen nicht auf das Tageslimit; sie sind je Spiel (BGG-ID) dedupliziert und als „aus Import“ gekennzeichnet → Kriterium 7 (Rest in SAM-08 #25).

Offene Fragen

Keine. (Folgefrage N12a zum Geltungsbereich der Deduplizierung steht in #25 und ändert die Kriterien dieser Story nicht.)

Planung

  • Epic: KAT Spielekatalog
  • Priorität: Must
  • Größe: L
  • Etappe: R1.2 Sammlung
  • Abhängigkeiten: KTO-01 (#1), KAT-01 (#3), KAT-05 (#2, Freigabe durch Admin)
  • Entscheidung O5: vorläufige private Einträge für gemeldete Spiele
  • Bezug: SAM-08 (#25) Kriterium 10 (Import-Meldungen)

Referenzen

  • Akzeptanzkriterien: requirements/20-r1-akzeptanzkriterien.md § KAT-04
  • Klärungen: requirements/r1-klaerungen.md (inkl. N12)
  • Story-Entwurf: requirements/r1-story-entwurf.md (freigegeben 2026-11-02)
  • Backlog: requirements/backlog.md
## Story **Als** Nutzer **möchte ich** ein fehlendes Spiel melden und sofort als vorläufigen privaten Eintrag nutzen, **damit** mich ein Katalogloch nicht beim Erfassen blockiert. ## Akzeptanzkriterien Quelle: `requirements/20-r1-akzeptanzkriterien.md` § KAT-04 (Referenz in Tests/PR: „KAT-04 Kriterium n“), Stand 2026-11-02 inkl. Klärungen und N12 - [ ] **1.** Gegeben ich finde ein Spiel nicht, wenn ich Titel (Pflicht), Verlag, Erscheinungsjahr und optional einen Link angebe, dann wird die Meldung gespeichert und ich erhalte eine Bestätigung. - [ ] **2.** Gegeben es gibt schon einen sehr ähnlichen Katalogeintrag, wenn ich melden will, dann sehe ich ihn zuerst und muss ausdrücklich bestätigen, dass mein Spiel ein anderes ist. „Sehr ähnlich“ heißt: gleicher normalisierter Titel (Groß-/Kleinschreibung, Sonderzeichen und Artikel ignoriert) oder Titel-Ähnlichkeit von mindestens 0,8 (Trigramm) bei Erscheinungsjahr ± 1 (Klärung 15). - [ ] **3.** Gegeben ich habe ein Spiel gemeldet, dann kann ich es als vorläufigen Eintrag in meine Sammlung oder Listen aufnehmen; der Eintrag ist nur für mich sichtbar. - [ ] **4.** Gegeben die Meldung wurde freigegeben, dann ersetzt der Katalogeintrag meinen vorläufigen Eintrag, ohne dass meine eigenen Angaben verloren gehen, und ich sehe das als Hinweis in der App am Eintrag (Klärung 26). - [ ] **5.** Gegeben die Meldung wurde mit einem anderen Eintrag zusammengeführt oder unter Verweis auf einen vorhandenen Eintrag abgelehnt, dann sehe ich das als Hinweis in der App am vorläufigen Eintrag (keine E-Mail), und mein vorläufiger Eintrag verweist auf den richtigen Eintrag (Klärungen 26, 45). - [ ] **6.** *(neu)* Gegeben die Meldung wurde ohne Zieleintrag abgelehnt, dann bleibt mein vorläufiger Eintrag privat bestehen und ist als „abgelehnt“ markiert (Klärung 26). - [ ] **7.** *(neu)* Gegeben ich habe heute schon 10 Meldungen abgeschickt, wenn ich eine weitere melden will, dann wird sie nicht gespeichert und ich sehe einen Hinweis auf das Tageslimit (Klärung 27). Meldungen, die der BGG-Import automatisch anlegt (SAM-08 Kriterium 4), zählen nicht auf dieses Limit (N12). - [ ] **8.** *(neu)* Gegeben ich habe eine Meldung abgeschickt, dann bleibt sie im Status „offen“, bis der Admin sie manuell bearbeitet; eine automatische Freigabe gibt es nicht (Klärungen 6, 27, 44). ## Querschnitt Es gelten alle Querschnittskriterien aus `20-r1-akzeptanzkriterien.md` § „Querschnitt für R1“ (Datenschutz QUE-04, Sicherheit der Daten, Sprachen QUE-05, Barrierefreiheit QUE-06, Zustände/Fehler/Netz, Plattformen). Besonders relevant: **Sicherheit der Daten Kriterium 1–3** (Meldungen und vorläufige Einträge nur für Melder und Admin), Zustände Kriterium 3. ## Nicht im Scope - Öffentliche Anzeige gemeldeter Spiele - Bild-Upload zur Meldung (nicht gefordert) - E-Mail- oder Push-Benachrichtigung zum Ergebnis (Klärung 45; Benachrichtigungen QUE-01 ab R2) - Admin-Oberfläche in der App – Bearbeitung über Supabase Studio (KAT-05 #2, Klärung 44) - Automatisches Anlegen von Meldungen beim BGG-Import inkl. Kennzeichen „aus Import“ und Deduplizierung – gehört zu SAM-08 (#25, Kriterium 10) ## Klärungen Verbindlich laut `requirements/r1-klaerungen.md` (2026-11-02): - **6:** Neue Tabelle für Meldungen (Status offen/freigegeben/abgelehnt/zusammengeführt, Link, Verweis auf Zieleintrag). - **15:** „Sehr ähnlich“ = gleicher normalisierter Titel oder Trigramm-Ähnlichkeit ≥ 0,8 bei Erscheinungsjahr ± 1 → Kriterium 2. - **26:** Ergebnis als Hinweis in der App am vorläufigen Eintrag, keine E-Mail; Ablehnung ohne Zieleintrag → Eintrag bleibt privat, markiert „abgelehnt“ → Kriterien 4–6. - **27:** Chris prüft jede Meldung manuell; Limit 10 Meldungen je Nutzer und Tag → Kriterien 7, 8. - **44/25:** Admin bearbeitet Meldungen über Supabase Studio/SQL. - **45:** Keine E-Mail zum Meldungsergebnis. - **N12:** Automatisch beim BGG-Import erzeugte Meldungen zählen nicht auf das Tageslimit; sie sind je Spiel (BGG-ID) dedupliziert und als „aus Import“ gekennzeichnet → Kriterium 7 (Rest in SAM-08 #25). ## Offene Fragen Keine. (Folgefrage N12a zum Geltungsbereich der Deduplizierung steht in #25 und ändert die Kriterien dieser Story nicht.) ## Planung - Epic: KAT Spielekatalog - Priorität: Must - Größe: L - Etappe: R1.2 Sammlung - Abhängigkeiten: KTO-01 (#1), KAT-01 (#3), KAT-05 (#2, Freigabe durch Admin) - Entscheidung O5: vorläufige private Einträge für gemeldete Spiele - Bezug: SAM-08 (#25) Kriterium 10 (Import-Meldungen) ## Referenzen - Akzeptanzkriterien: `requirements/20-r1-akzeptanzkriterien.md` § KAT-04 - Klärungen: `requirements/r1-klaerungen.md` (inkl. N12) - Story-Entwurf: `requirements/r1-story-entwurf.md` (freigegeben 2026-11-02) - Backlog: `requirements/backlog.md`
cschlaefke added the
type/story
prio/must
size/l
needs-clarification
epic/katalog
labels 2026-11-02 13:40:51 +00:00
cschlaefke added a new dependency 2026-11-02 13:43:20 +00:00
cschlaefke added a new dependency 2026-11-02 13:43:21 +00:00
cschlaefke added a new dependency 2026-11-02 13:43:22 +00:00
cschlaefke added a new dependency 2026-11-02 13:43:46 +00:00
Author
Owner

Offene fachliche Fragen aus requirements/r1-story-entwurf.md, Abschnitt 5 (Nummerierung wie im Entwurf). Bitte hier beantworten; nach Klärung wird needs-clarification entfernt.

Frage 6: KAT-04: Für Meldungen (Status offen/freigegeben/abgelehnt/zusammengeführt, Link, Verweis auf Zieleintrag) gibt es keine Tabelle. Bitte bestätigen, dass dies in R1 neu dazukommt (Umsetzung: architect).

Frage 15: KAT-04 Krit. 2: Ab wann ist ein Eintrag „sehr ähnlich“ (gleicher Titel, Titel + Jahr …)?

Frage 26: KAT-04 Krit. 5: Wie erfährt der Nutzer von Freigabe/Ablehnung/Zusammenführung? Benachrichtigungen (QUE-01) sind erst R2 – reicht ein Hinweis in der App? Was passiert mit dem vorläufigen Eintrag bei Ablehnung ohne Zieleintrag?

Frage 27: KAT-04 / Moderation: Gemeldete Titel und Links sind Nutzerinhalte. Prüft Chris jede Meldung manuell? Gibt es ein Limit gegen Spam-Meldungen?

Frage 45 (Querschnitt Benachrichtigungen): E-Mails in R1 (Bestätigung, Reset, Export fertig, ggf. Meldungsergebnis) – reichen Systemmails, Sprache der Mails nach Profil-locale?

**Offene fachliche Fragen** aus `requirements/r1-story-entwurf.md`, Abschnitt 5 (Nummerierung wie im Entwurf). Bitte hier beantworten; nach Klärung wird `needs-clarification` entfernt. **Frage 6:** KAT-04: Für Meldungen (Status offen/freigegeben/abgelehnt/zusammengeführt, Link, Verweis auf Zieleintrag) gibt es keine Tabelle. Bitte bestätigen, dass dies in R1 neu dazukommt (Umsetzung: architect). **Frage 15:** KAT-04 Krit. 2: Ab wann ist ein Eintrag „sehr ähnlich“ (gleicher Titel, Titel + Jahr …)? **Frage 26:** KAT-04 Krit. 5: Wie erfährt der Nutzer von Freigabe/Ablehnung/Zusammenführung? Benachrichtigungen (QUE-01) sind erst R2 – reicht ein Hinweis in der App? Was passiert mit dem vorläufigen Eintrag bei Ablehnung ohne Zieleintrag? **Frage 27:** KAT-04 / Moderation: Gemeldete Titel und Links sind Nutzerinhalte. Prüft Chris jede Meldung manuell? Gibt es ein Limit gegen Spam-Meldungen? **Frage 45 (Querschnitt Benachrichtigungen):** E-Mails in R1 (Bestätigung, Reset, Export fertig, ggf. Meldungsergebnis) – reichen Systemmails, Sprache der Mails nach Profil-`locale`?
cschlaefke added this to the R1 milestone 2026-11-02 13:53:44 +00:00
Author
Owner

Klärungen eingearbeitet (2026-11-02): Fragen 6, 15, 26, 27, 44/25, 45 laut requirements/r1-klaerungen.md. Kriterium 2 enthält jetzt die Definition von „sehr ähnlich“. Kriterien 4 und 5 bekommen den Hinweis in der App statt einer E-Mail. Neu sind Kriterium 6 (Ablehnung ohne Zieleintrag → Eintrag bleibt als „abgelehnt“ markiert), 7 (Tageslimit 10) und 8 (Meldung bleibt offen bis zur manuellen Prüfung). Keine offenen Fragen mehr, needs-clarification entfernt. Ob automatisch beim BGG-Import erzeugte Meldungen auf das Tageslimit zählen, ist als Frage N12 in #25 offen.

Klärungen eingearbeitet (2026-11-02): Fragen 6, 15, 26, 27, 44/25, 45 laut `requirements/r1-klaerungen.md`. Kriterium 2 enthält jetzt die Definition von „sehr ähnlich“. Kriterien 4 und 5 bekommen den Hinweis in der App statt einer E-Mail. Neu sind Kriterium 6 (Ablehnung ohne Zieleintrag → Eintrag bleibt als „abgelehnt“ markiert), 7 (Tageslimit 10) und 8 (Meldung bleibt offen bis zur manuellen Prüfung). Keine offenen Fragen mehr, `needs-clarification` entfernt. Ob automatisch beim BGG-Import erzeugte Meldungen auf das Tageslimit zählen, ist als Frage N12 in #25 offen.
cschlaefke removed the
needs-clarification
label 2026-11-02 14:33:50 +00:00
Author
Owner

Klärungen N12 eingearbeitet (2026-11-02)

  • N12 → Kriterium 7 ergänzt: Meldungen, die der BGG-Import automatisch anlegt (SAM-08 #25 Kriterium 4), zählen nicht auf das Tageslimit von 10. Kennzeichnung „aus Import“ und Deduplizierung je BGG-ID sind in SAM-08 (#25) Kriterium 10 geregelt.
  • Die Folgefrage N12a (Deduplizierung je Nutzer oder über alle Nutzer) steht in #25; sie ändert die Kriterien dieser Story nicht.

Quelle: requirements/r1-klaerungen.md, Abschnitt „Neue Fragen aus dem Einarbeiten (N1–N14)“.

Klärungen N12 eingearbeitet (2026-11-02) - **N12** → Kriterium 7 ergänzt: Meldungen, die der BGG-Import automatisch anlegt (SAM-08 #25 Kriterium 4), zählen nicht auf das Tageslimit von 10. Kennzeichnung „aus Import“ und Deduplizierung je BGG-ID sind in SAM-08 (#25) Kriterium 10 geregelt. - Die Folgefrage N12a (Deduplizierung je Nutzer oder über alle Nutzer) steht in #25; sie ändert die Kriterien dieser Story nicht. Quelle: `requirements/r1-klaerungen.md`, Abschnitt „Neue Fragen aus dem Einarbeiten (N1–N14)“.
Author
Owner

Hinweis aus der KAT-05-Spec (PR #51, Entscheidung von Chris 2026-11-03): Wird eine Meldung aus diesem Issue vom Admin freigegeben oder zusammengeführt, werden die Varianten des privaten vorläufigen Eintrags nicht in den öffentlichen Katalog kopiert (sonst würden private Nutzerdaten ohne Prüfung öffentlich). Verweise in Sammlung und Partien auf eine Variante (Edition) werden auf eine gleichnamige Variante des Zielspiels abgebildet, sonst auf null.

Folge für KAT-04 Kriterium 4 („eigene Angaben bleiben erhalten"): Für die Edition gilt das nur eingeschränkt; sie kann beim Umhängen verloren gehen. Bitte bei der Spec zu #13 berücksichtigen (z. B. Hinweis an Nutzer oder Edition als Freitext sichern). Die Meldungstabelle game_reports entsteht in PR 2c von #2; 2c muss vor der Umsetzung von #13 gemergt sein.

Hinweis aus der KAT-05-Spec (PR #51, Entscheidung von Chris 2026-11-03): Wird eine Meldung aus diesem Issue vom Admin freigegeben oder zusammengeführt, werden die **Varianten des privaten vorläufigen Eintrags nicht** in den öffentlichen Katalog kopiert (sonst würden private Nutzerdaten ohne Prüfung öffentlich). Verweise in Sammlung und Partien auf eine Variante (Edition) werden auf eine gleichnamige Variante des Zielspiels abgebildet, sonst auf `null`. Folge für KAT-04 Kriterium 4 („eigene Angaben bleiben erhalten"): Für die Edition gilt das nur eingeschränkt; sie kann beim Umhängen verloren gehen. Bitte bei der Spec zu #13 berücksichtigen (z. B. Hinweis an Nutzer oder Edition als Freitext sichern). Die Meldungstabelle `game_reports` entsteht in PR 2c von #2; 2c muss vor der Umsetzung von #13 gemergt sein.
Author
Owner

Spec-Entwurf zu KAT-04 liegt zur Freigabe bereit (architect, 2026-11-03)

Spec: docs/specs/13-fehlendes-spiel-melden.md auf Branch docs/13-kat04-spec (Commit ab438ac, noch kein PR).

Voraussetzung: #2 PR 2b und 2c müssen gemergt sein, bevor 13a (Backend) beginnt (Spec #2 E12). Der Hinweis aus PR #51 (Klärung N15, Edition) ist eingearbeitet: § 2 „Abweichung bei Krit. 4“, E7, § 5.4.

Kernentscheidungen in Kurzform: Zu jeder Meldung gehört genau ein vorläufiger privater Eintrag mit nur Titel und Jahr. Das Anlegen läuft über eine atomare RPC (security invoker). Die Datenbank schützt über Spaltenrechte, eine Insert-Policy und einen Limit-Trigger mit Sperre je Nutzer. Die Ähnlichkeitsprüfung läuft serverseitig mit pg_trgm. Bei „abgelehnt mit Verweis“ wechselt der Nutzer selbst auf den Zieleintrag (adopt_report_target, security definer, streng geprüft). Die Ergebnishinweise lassen sich wegklicken (result_seen_at). Geschnitten in zwei PRs: 13a Backend (Refs #13) und 13b Flutter (Closes #13).

Offene Fragen mit Empfehlung (§ 9.2). Keine blockiert die Umsetzung, deshalb setze ich kein needs-clarification. Wenn du nichts anderes entscheidest, gilt die Empfehlung mit der Freigabe.

  • Spec-F1: Sind Verlag und Jahr Pflicht? → Empfehlung: optional, nur der Titel ist Pflicht.
  • Spec-F2: Was gilt bei der Trigramm-Regel, wenn ein Jahr fehlt? → Empfehlung: Trigramm ≥ 0,8 ohne Jahresbedingung.
  • Spec-F3: Was zählt als Artikel und Sonderzeichen? → Empfehlung:
    • nur führende Artikel auf Deutsch und Englisch,
    • Umlaute und Akzente bleiben Buchstaben, ß wird zu ss,
    • alle übrigen Zeichen werden ignoriert.
  • Spec-F4: Was heißt „heute“ beim Tageslimit? → Empfehlung: Kalendertag Europe/Berlin.
  • Spec-F5: Wie lange bleibt der Hinweis sichtbar? → Empfehlung: bis „Verstanden“. Die Markierung „abgelehnt“ bleibt dauerhaft.
  • Spec-F6: Woran erkennt die App, dass die Edition geleert wurde? → Empfehlung: ableiten, ohne Änderung an 2b/2c. Alternative: Spalte edition_cleared, dann als Nachtrag in Spec #2, bevor 2b/2c gebaut werden.
  • Spec-F7: Sollen auch eigene frühere Meldungen als ähnlich angezeigt werden? → Empfehlung: nein in R1.
  • Spec-F8: Soll #13 zusätzlich von #4 und #6 abhängen (Listeneintrag, Hinweis „am Eintrag“)? → Empfehlung: ja.
  • Spec-F9: Welche Liste ist im Formular vorausgewählt? → Empfehlung: Sammlung.

Bitte Spec freigeben oder Änderungen nennen. Bis zur Freigabe wird nichts umgesetzt.

**Spec-Entwurf zu KAT-04 liegt zur Freigabe bereit** (architect, 2026-11-03) Spec: [`docs/specs/13-fehlendes-spiel-melden.md`](https://git.cshomelabs.work/cschlaefke/Shuffle/src/branch/docs/13-kat04-spec/docs/specs/13-fehlendes-spiel-melden.md) auf Branch `docs/13-kat04-spec` (Commit ab438ac, noch kein PR). **Voraussetzung:** #2 PR 2b und 2c müssen gemergt sein, bevor 13a (Backend) beginnt (Spec #2 E12). Der Hinweis aus PR #51 (Klärung N15, Edition) ist eingearbeitet: § 2 „Abweichung bei Krit. 4“, E7, § 5.4. **Kernentscheidungen in Kurzform:** Zu jeder Meldung gehört genau ein vorläufiger privater Eintrag mit nur Titel und Jahr. Das Anlegen läuft über eine atomare RPC (`security invoker`). Die Datenbank schützt über Spaltenrechte, eine Insert-Policy und einen Limit-Trigger mit Sperre je Nutzer. Die Ähnlichkeitsprüfung läuft serverseitig mit `pg_trgm`. Bei „abgelehnt mit Verweis“ wechselt der Nutzer selbst auf den Zieleintrag (`adopt_report_target`, `security definer`, streng geprüft). Die Ergebnishinweise lassen sich wegklicken (`result_seen_at`). Geschnitten in zwei PRs: 13a Backend (`Refs #13`) und 13b Flutter (`Closes #13`). **Offene Fragen mit Empfehlung (§ 9.2).** Keine blockiert die Umsetzung, deshalb setze ich kein `needs-clarification`. Wenn du nichts anderes entscheidest, gilt die Empfehlung mit der Freigabe. - **Spec-F1:** Sind Verlag und Jahr Pflicht? → Empfehlung: optional, nur der Titel ist Pflicht. - **Spec-F2:** Was gilt bei der Trigramm-Regel, wenn ein Jahr fehlt? → Empfehlung: Trigramm ≥ 0,8 ohne Jahresbedingung. - **Spec-F3:** Was zählt als Artikel und Sonderzeichen? → Empfehlung: - nur führende Artikel auf Deutsch und Englisch, - Umlaute und Akzente bleiben Buchstaben, ß wird zu ss, - alle übrigen Zeichen werden ignoriert. - **Spec-F4:** Was heißt „heute“ beim Tageslimit? → Empfehlung: Kalendertag Europe/Berlin. - **Spec-F5:** Wie lange bleibt der Hinweis sichtbar? → Empfehlung: bis „Verstanden“. Die Markierung „abgelehnt“ bleibt dauerhaft. - **Spec-F6:** Woran erkennt die App, dass die Edition geleert wurde? → Empfehlung: ableiten, ohne Änderung an 2b/2c. Alternative: Spalte `edition_cleared`, dann als Nachtrag in Spec #2, bevor 2b/2c gebaut werden. - **Spec-F7:** Sollen auch eigene frühere Meldungen als ähnlich angezeigt werden? → Empfehlung: nein in R1. - **Spec-F8:** Soll #13 zusätzlich von #4 und #6 abhängen (Listeneintrag, Hinweis „am Eintrag“)? → Empfehlung: ja. - **Spec-F9:** Welche Liste ist im Formular vorausgewählt? → Empfehlung: Sammlung. Bitte Spec freigeben oder Änderungen nennen. Bis zur Freigabe wird nichts umgesetzt.
cschlaefke added the
status/spec-review
label 2026-11-03 19:48:33 +00:00
Author
Owner

Nachtrag zur Spec (Commit ece8e3e, gleicher Branch docs/13-kat04-spec)

  • Spec-F3, Empfehlung geändert: Umlaute und Akzente werden jetzt gefaltet (ö = o, é = e, ß = ss). Das geschieht über eine feste translate()-Zuordnung.
    • Grund: Ohne Faltung erkennt die Prüfung „Mölkky“ und „Molkky“ nicht als ähnlich. Die Trigramm-Ähnlichkeit liegt bei etwa 0,4, also weit unter 0,8.
    • Weiter gilt: Nur führende Artikel (de/en) werden ignoriert, alle anderen Sonderzeichen ebenfalls.
  • Trigramm-Index gestrichen: Er wäre mit der exakten Prüfung similarity() >= 0.8 nicht nutzbar. Bei der Größe des Katalogs reicht ein sequenzieller Durchlauf.
  • Abweichung von Spec #2 § 3.4 ausdrücklich vermerkt: Nutzer dürfen genau eine Spalte ändern, result_seen_at, und nur an eigenen, bereits bearbeiteten Meldungen. Der Test 08 aus 2c wird entsprechend angepasst.
  • Tagesgrenze testbar gemacht: Die Hilfsfunktion report_day rechnet den Berliner Kalendertag aus.

Die übrigen Fragen und Empfehlungen sind unverändert.

**Nachtrag zur Spec** (Commit ece8e3e, gleicher Branch `docs/13-kat04-spec`) - **Spec-F3, Empfehlung geändert:** Umlaute und Akzente werden jetzt **gefaltet** (ö = o, é = e, ß = ss). Das geschieht über eine feste `translate()`-Zuordnung. - Grund: Ohne Faltung erkennt die Prüfung „Mölkky“ und „Molkky“ nicht als ähnlich. Die Trigramm-Ähnlichkeit liegt bei etwa 0,4, also weit unter 0,8. - Weiter gilt: Nur führende Artikel (de/en) werden ignoriert, alle anderen Sonderzeichen ebenfalls. - **Trigramm-Index gestrichen:** Er wäre mit der exakten Prüfung `similarity() >= 0.8` nicht nutzbar. Bei der Größe des Katalogs reicht ein sequenzieller Durchlauf. - **Abweichung von Spec #2 § 3.4 ausdrücklich vermerkt:** Nutzer dürfen genau eine Spalte ändern, `result_seen_at`, und nur an eigenen, bereits bearbeiteten Meldungen. Der Test `08` aus 2c wird entsprechend angepasst. - **Tagesgrenze testbar gemacht:** Die Hilfsfunktion `report_day` rechnet den Berliner Kalendertag aus. Die übrigen Fragen und Empfehlungen sind unverändert.
Author
Owner

Review-Befunde eingearbeitet (Commit f7a7c1e auf docs/13-kat04-spec)

Für dich zur Entscheidung, Chris:

  • Spec-F3 (Normalisierung): Diese Frage ist kleiner geworden. Die Normalisierung (Sonderzeichen, Groß- und Kleinschreibung, Akzente) liegt jetzt bei Spec #3 (search_normalize). Für #13 ist nur noch offen, welche Artikel ignoriert werden. Empfehlung: nur ein führender Artikel auf Deutsch oder Englisch.
  • Spec-F6 (Edition), Empfehlung geändert: Ich empfehle jetzt einen Zähler game_reports.editions_cleared. Dafür ist ein Nachtrag in Spec #2 nötig, solange 2b und 2c noch nicht gemergt sind.
    • So zählt die Datenbank genau, wie viele Editionen in Sammlung und Partien geleert wurden.
    • Rückfall bleibt die Ableitung aus den Daten. Sie ist ungenauer und deckt nur Sammlungseinträge mit Liste „Sammlung“ ab.
  • Abhängigkeit: #3 muss jetzt fest vor 13a gemergt sein, zusätzlich zu 2b und 2c.

Die übrigen Fragen und Empfehlungen sind unverändert.

**Review-Befunde eingearbeitet** (Commit f7a7c1e auf `docs/13-kat04-spec`) Für dich zur Entscheidung, Chris: - **Spec-F3 (Normalisierung):** Diese Frage ist kleiner geworden. Die Normalisierung (Sonderzeichen, Groß- und Kleinschreibung, Akzente) liegt jetzt bei Spec #3 (`search_normalize`). Für #13 ist nur noch offen, welche Artikel ignoriert werden. Empfehlung: nur ein führender Artikel auf Deutsch oder Englisch. - **Spec-F6 (Edition), Empfehlung geändert:** Ich empfehle jetzt einen Zähler `game_reports.editions_cleared`. Dafür ist ein Nachtrag in Spec #2 nötig, solange 2b und 2c noch nicht gemergt sind. - So zählt die Datenbank genau, wie viele Editionen in Sammlung und Partien geleert wurden. - Rückfall bleibt die Ableitung aus den Daten. Sie ist ungenauer und deckt nur Sammlungseinträge mit Liste „Sammlung“ ab. - **Abhängigkeit:** #3 muss jetzt fest vor 13a gemergt sein, zusätzlich zu 2b und 2c. Die übrigen Fragen und Empfehlungen sind unverändert.
Author
Owner

Spec an Spec #3 und PR 2c angeglichen (Commit a4c7b47 auf docs/13-kat04-spec)

Wichtig, Chris: Spec-F6 (Edition) bitte vor dem Merge von PR #57 (2c) entscheiden.

Empfehlung: ein Zähler game_reports.editions_cleared. 2c legt die Spalte an und setzt sie in admin_resolve_report aus dem schon vorhandenen variants_cleared. Der in der letzten Fassung genannte Nachtrag in 2b entfällt; dort war ich falsch.

Wenn die Entscheidung erst nach dem Merge von PR #57 fällt, müsste 13a admin_resolve_report per create or replace ändern.

Sonst nur Abgleich mit Spec #3, fachlich unverändert:

  • Ähnlichkeitsprüfung über title_search.
  • Gemeinsamer Absatz zur Normalisierung mit Spec #3.
  • Vorbedingungen: 13a braucht 2b, 2c und 3a; der Merge von 13b braucht 3b.
**Spec an Spec #3 und PR 2c angeglichen** (Commit a4c7b47 auf `docs/13-kat04-spec`) **Wichtig, Chris: Spec-F6 (Edition) bitte vor dem Merge von PR #57 (2c) entscheiden.** Empfehlung: ein Zähler `game_reports.editions_cleared`. 2c legt die Spalte an und setzt sie in `admin_resolve_report` aus dem schon vorhandenen `variants_cleared`. Der in der letzten Fassung genannte Nachtrag in 2b entfällt; dort war ich falsch. Wenn die Entscheidung erst nach dem Merge von PR #57 fällt, müsste 13a `admin_resolve_report` per `create or replace` ändern. Sonst nur Abgleich mit Spec #3, fachlich unverändert: - Ähnlichkeitsprüfung über `title_search`. - Gemeinsamer Absatz zur Normalisierung mit Spec #3. - Vorbedingungen: 13a braucht 2b, 2c und 3a; der Merge von 13b braucht 3b.
cschlaefke removed the
status/spec-review
label 2026-11-03 23:54:12 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference: cschlaefke/Shuffle#13
No description provided.