Init: freigegebener Projekt-Prompt + AGENTS.md
This commit is contained in:
21
AGENTS.md
Normal file
21
AGENTS.md
Normal file
@@ -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.
|
||||
31
PROMPT.md
Normal file
31
PROMPT.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user