commit 72f016a2639c0e43b4d8514dfb3cbf27d55116f1 Author: Flo Hartmann Date: Fri Aug 21 18:00:57 2026 +0000 Init: freigegebener Projekt-Prompt + AGENTS.md diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..d986771 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,21 @@ +# Spiele-Redaktion + +## Ziel +Multi-User-Webanwendung „KI-Assistenz für Spielemagazin-Redaktionen": Neuheitenliste (BGG), Dedup-Prüfungen, Planungsliste, Archivierung, Erinnerungen, Benachrichtigungen (E-Mail/Telegram/In-App), Audit-Log, Export. + +## Status +Setup — Prompt freigegeben 2026-08-21, Implementierung noch nicht begonnen. + +## Struktur +| Pfad | Inhalt | +|------|--------| +| PROMPT.md | Ursprünglicher Projekt-Prompt (freigegebene Fassung) | + +## Konventionen +- Stack: FastAPI + Plugin-Architektur (Entry-Points/Namensraum-Pakete), SQLite→Postgres-fähig, HTMX + Jinja2 + Tailwind + Alpine.js +- Jede Funktion = Plugin mit eigener Migration/Routen/Templates; Kern schlank +- UI: Deutsch. Rollen: Admin/Redakteur vs. Rezensent +- Deployment: Docker/Podman Compose, portabel (Lab → Kundenhardware) + +## Für KI-Agenten +Zuerst PROMPT.md lesen — enthält die vollständigen Anforderungen. Plugin-Kontrakt nicht umgehen: keine Feature-Logik im Kern. diff --git a/PROMPT.md b/PROMPT.md new file mode 100644 index 0000000..8109e01 --- /dev/null +++ b/PROMPT.md @@ -0,0 +1,31 @@ +# Spiele-Redaktion — KI-Assistenz für Spielemagazin-Redaktionen + +Erstelle eine Multi-User-Webanwendung „KI-Assistenz für Spielemagazin-Redaktionen". + +## Architektur (harte Anforderung) +Vollständig modular — jede Funktion ist ein Plugin. Neue Funktionen ergänzen, ohne bestehende zu beschädigen. + +Stack: Python/FastAPI mit Plugin-Loader über Python-Entry-Points (`importlib.metadata`) + Namensraum-Pakete; jedes Plugin eigener Ordner mit eigener Migration, eigenen Routen und Templates; Kern bleibt schlank. SQLite (später Postgres-fähig), Frontend HTMX + Jinja2 + Tailwind (kein React-Build-Step), Alpine.js für kleine Interaktionen. + +## Plugins +1. `neuheiten` — KI-gestützte Abfrage von Internet-Datenbanken zur Erstellung/Aktualisierung der Neuheitenliste (Spieltitel, Verlag, Autor, Erscheinungsdatum). Prototypen und Erweiterungen filtern. Datenquelle: BoardGameGeek-API (XML API2). Sync als Hintergrund-Job (APScheduler), Rate-Limit beachten. +2. `dedup` — Prüfungen bei Import und händischem Eintrag: + a) gleichzeitige Erscheinung in verschiedenen Verlagen/Vertrieb → Verlag-Auswahl dem Nutzer vorlegen + b) gleiches Spiel mit unterschiedlichen Titeln → deutsche Version bevorzugen + c) Spiel oder Vorgänger bereits besprochen? (BGG `boardgameexpansion`-Relation + Fuzzy-Match) + d) Titel schon in Planungsliste eines anderen Rezensenten? +3. `planung` — Rezensent wählt Titel aus Neuheitenliste → Verschiebung in Planungsliste mit Zuordnung; händisches Nachtragen mit automatischer dedup-Prüfung, bei Treffer Benachrichtigung an den Eintragenden. +4. `archiv` — Titel älter als 12 Monate automatisch in Sicherungsdatei/Archiv verschieben. +5. `erinnerung` — Vier Wochen vor Redaktionsschluss Erinnerung an alle Rezensenten; Redaktionsschluss als konfigurierbares Datum pro Ausgabe (mehrere Ausgaben parallel möglich). +6. `benachrichtigung` — Kanal je User einstellbar: E-Mail, Telegram, In-App im Portal. Adapter-Pattern; Mailserver erst in Produktion vorhanden (dev = Log/Console). +7. `audit-log` — Wer hat was wann verschoben/eingetragen/geändert. +8. `export` — Listen als CSV (stdlib) und PDF (WeasyPrint). + +## Auth & Rollen +Redakteur/Admin vs. Rezensent. + +## Hosting +Erst Henry-Lab (Docker/Podman, Compose), später Kundenhardware — Deployment portabel halten. + +## Konventionen +UI-Sprache: Deutsch only. Geringe Nutzerzahl — Performance-Optimierungen nicht übertreiben. Remote-Repo: gitea.ragtag.rocks/b0rbor4d/spiele-redaktion.