feat: rebuild rss-news backend, admin ui, and legal extraction pipeline

docs/PROJECT_PLAN.md

@@ -0,0 +1,67 @@
+# Projektplan (Neustart)
+
+## Leitentscheidungen
+- Bestehendes Repository wird weiterverwendet.
+- Kein harter Endtermin: lauffaehig werden, dann iterativ verbessern.
+- Hetzner bleibt Laufzeitplattform.
+- WordPress (IONOS) bleibt vorerst Ziel fuer Publikation.
+- Auth initial nur mit einem User/Password.
+
+## Zielbild
+Eine modulare News-Pipeline mit klaren Stufen:
+1. Feed-Ingestion
+2. Inhaltsanalyse und Normalisierung
+3. Rewrite/Anreicherung
+4. Legal- und Qualitaetschecks
+5. WordPress-Publikation (`pending`)
+6. Monitoring/Logging
+
+## Grobe Zeitplanung (ohne Fixtermine)
+- Phase 0: ca. 1 Woche
+- Phase 1: ca. 2-4 Wochen
+- Phase 2: ca. 2-3 Wochen
+- Phase 3: fortlaufend
+
+## Phasen
+
+### Phase 0 - Grundlagen (jetzt)
+- Doku und Wiki strukturieren
+- Source-Policy definieren
+- Redirect fuer `news.vanityontour.de` setzen
+- GitHub Project als zentrale Planung scharfstellen
+
+### Phase 1 - MVP Core
+- Neues FastAPI-Projektgeruest
+- SQLite-Datenmodell (feeds, articles, runs, source_policy)
+- Feed-Import mit Duplikaterkennung
+- Admin-Login (ein User)
+- Manuelle Review vor Publish
+
+### Phase 2 - Automation
+- Job-Queue (asynchron)
+- Regelbasierte Scheduler
+- Retry/Dead-Letter-Handling
+- Robustes Error-Reporting
+
+### Phase 3 - Compliance und Skalierung
+- Source-Whitelisting mit Pflichtfeldern
+- Pflicht-Attribution pro Artikel
+- Qualitaetsmetriken und Audit-Logs
+- Optional: Passkey/WebAuthn
+
+## Architekturprinzipien
+- Idempotente Jobs
+- Trennung von UI, API, Worker
+- Strikte Validierung bei Quell-/Lizenzdaten
+- Expliziter Publish-Schritt, kein blindes Autoposting
+
+## Risiken
+- Lizenz-/Nutzungsbedingungen je Quelle variieren stark
+- Feeds aendern Struktur/Verfuegbarkeit
+- WordPress-API und Auth koennen regressionsanfaellig sein
+
+## Erfolgsmetriken
+- Zeit von Feed-Eingang bis Review-Ready
+- Quote sauber attribuierter Artikel
+- Fehlerrate pro Pipeline-Stufe
+- Anzahl manueller Eingriffe pro Woche

docs/SOURCE_POLICY.md

@@ -0,0 +1,81 @@
+# Source Policy und Feed-Vorschlaege
+
+## Grundsatz
+Es werden nur Quellen genutzt, deren Nutzungsbedingungen die geplante Nutzung erlauben oder fuer die eine explizite Genehmigung vorliegt.
+
+## Pflichtdaten pro Quelle
+- Quellname
+- Feed-URL
+- Originalartikel-URL
+- Autor/Herausgeber (wenn vorhanden)
+- Lizenz/Nutzungsgrundlage
+- Einschraenkungen (kommerziell, Bearbeitung, Bildrechte, Archivierung)
+- Datum der letzten Pruefung
+- Link auf Nutzungsbedingungen
+
+## Einstufung (Ampel)
+- Gruen: Nutzung fuer geplantes Modell klar erlaubt
+- Gelb: teilklar/mit Einschraenkungen, manuelle Pruefung erforderlich
+- Rot: fuer das Modell nicht geeignet ohne Zusatzvertrag
+
+## Verbindliche Regeln
+- Keine neue Quelle ohne Eintrag im Source-Register
+- Kein automatischer Publish bei Gelb/Rot
+- Bilder separat pruefen (Textrecht != Bildrecht)
+- Quartalsweiser Re-Check der Terms
+
+## Ersteinschaetzung (Stand: 16.02.2026)
+
+### Rot
+1. Reuters / Thomson Reuters
+- Grund: Inhalte sind urheberrechtlich geschuetzt; Reproduktion/Verteilung laut Terms nur mit vorheriger Zustimmung.
+- Folge: Nur mit explizitem Vertrag/Lizenz.
+- Referenz:
+  - https://www.thomsonreuters.com/en/terms-of-use
+
+2. tagesschau.de RSS
+- Grund: Inhalte nur privat/nicht-kommerziell; Veroeffentlichung grundsaetzlich nicht erlaubt (ausser explizit CC-lizenziert).
+- Folge: Nicht fuer das geplante Modell geeignet.
+- Referenz:
+  - https://www.tagesschau.de/infoservices/rssfeeds
+
+### Gelb
+1. Presseportal / ots
+- Grund: Redaktionelle Nutzung grundsaetzlich moeglich, aber Verantwortung liegt beim Verwender; darueber hinausgehende Geschaeftsnutzung nur mit Genehmigung.
+- Folge: Nur mit strikter Einzelpruefung pro Meldung (insb. Bild-/Drittrechte).
+- Referenz:
+  - https://www.presseportal.de/nutzungsbedingungen
+  - https://www.presseportal.de/feeds/
+
+2. Bundesbehoerden-RSS ohne explizite freie Weiterverwendungs-Lizenz
+- Grund: RSS wird bereitgestellt, aber nicht immer als offene Lizenz zur kommerziellen Nachnutzung formuliert.
+- Folge: Je Behoerde einzeln pruefen und dokumentieren.
+- Beispiele:
+  - https://www.bundesfinanzministerium.de/Content/DE/Standardartikel/Service/rss_base.html
+  - https://bmas.bund.de/EN/Services/RSS/rss.html
+
+### Gruen (mit korrekter Attribution)
+1. GovData / Open-Data-Portale mit `dl-de/by-2-0`, `dl-de/zero-2-0`, `CC BY 4.0` oder `CC0`
+- Grund: Diese Lizenzen erlauben grundsaetzlich auch kommerzielle Weiterverwendung (je nach Lizenzbedingungen).
+- Folge: Sehr gut fuer stabile Automatisierung geeignet.
+- Referenz:
+  - https://www.govdata.de/dl-de/by-2-0
+  - https://data.gov.de/informationen/lizenzen
+  - https://www.dcat-ap.de/def/licenses/dl-zero-de/2.0
+
+2. EU-Quellen mit expliziter `CC BY 4.0` Wiederverwendungsregel
+- Grund: EU-Inhalte sind haeufig unter CC BY 4.0 wiederverwendbar, sofern nicht anders gekennzeichnet.
+- Folge: Geeignet, wenn Drittinhalte ausgenommen werden.
+- Referenz:
+  - https://commission.europa.eu/legal-notice_en
+  - https://eur-lex.europa.eu/content/help/content/legal-notice/legal-notice.html
+
+## Quelle im Register freischalten (Definition of Done)
+- Terms-Link hinterlegt
+- Lizenzklasse (Gruen/Gelb/Rot) gesetzt
+- Pflicht-Attribution dokumentiert
+- Bildrechtsregel dokumentiert
+- Letzte Pruefung und Verantwortlicher gepflegt
+
+## Hinweis
+Keine Rechtsberatung. Bei unklaren oder wirtschaftlich kritischen Quellen ist eine juristische Prüfung sinnvoll.

docs/TODO.md

@@ -0,0 +1,33 @@
+# ToDo (Ein-Entwickler Setup)
+
+## Jetzt
+- [ ] GitHub Project #3 Felder/Views fuer Neustart vereinheitlichen
+- [ ] Alte/obsolet gewordene Issues kennzeichnen (z. B. User-Verwaltung)
+- [ ] Redirect `news.vanityontour.de -> vanityontour.de` aktiv halten
+- [ ] Wiki-Basis fertigstellen und verlinken
+
+## MVP
+- [x] Neues Backend-Skelett (`backend/`) aufsetzen (FastAPI)
+- [x] Datenmodell in SQLite anlegen
+- [x] Feed-Ingestion Service bauen (ETag/Last-Modified)
+- [x] Duplikaterkennung ueber `source_url`, `guid`, Hash
+- [x] Login mit 1 Admin-Account implementieren
+- [ ] Artikel-Review-Maske mit Statusworkflow
+- [ ] WordPress-Publisher als separaten Service implementieren
+
+## Recht/Qualitaet
+- [ ] Source-Policy in DB + Admin-UI abbilden
+- [ ] Pflichtfelder je Quelle erzwingen (Autor, URL, Lizenz, Hinweise)
+- [ ] Auto-Block bei fehlender Lizenzinfo
+- [ ] Pro Artikel Attribution-Block generieren
+
+## Betrieb
+- [ ] Systemd-Service(s) fuer API/Worker erstellen
+- [ ] Nginx-Routing fuer neue App einrichten
+- [ ] Healthcheck-Endpunkte + Monitoring einrichten
+- [ ] Backup/Restore fuer DB dokumentieren
+
+## Spaeter
+- [ ] Passkey/WebAuthn evaluieren und optional einfuehren
+- [ ] Migration auf PostgreSQL bewerten
+- [ ] Teilautomatische Freigabe-Regeln definieren

docs/wiki/Architektur.md

@@ -0,0 +1,29 @@
+# Architektur
+
+## Zielarchitektur
+- API: FastAPI
+- Worker: Queue-basierte Hintergrundjobs
+- DB: SQLite (MVP), spaeter optional PostgreSQL
+- Publisher: WordPress REST API
+- Frontend/Admin: schlanke Web-UI mit Login
+
+## Pipeline
+1. Feed Fetch
+2. Parse + Normalize
+3. Deduplicate
+4. Enrichment (Rewrite/Tags)
+5. Legal/Policy Check
+6. Publish (pending)
+
+## Datenobjekte (MVP)
+- `sources`
+- `feeds`
+- `articles`
+- `article_versions`
+- `runs`
+- `policy_checks`
+
+## Nichtziele (MVP)
+- Multi-User und Rollen
+- Vollautomatische Freigabe ohne Review
+- Komplexe externe SSO-Integration

docs/wiki/Deployment.md

@@ -0,0 +1,20 @@
+# Deployment (Hetzner + CloudPanel)
+
+## Umgebung
+- Host: Hetzner
+- Reverse Proxy: Nginx via CloudPanel
+- Ziel-Domain: `news.vanityontour.de`
+
+## Aktueller Zustand
+- Domain ist bis zum Go-Live auf `https://vanityontour.de` umgeleitet.
+
+## Zielzustand
+- `news.vanityontour.de` zeigt auf neue App (interner Port, z. B. `127.0.0.1:8501`)
+- API/Worker laufen als systemd-Services
+- TLS bleibt ueber CloudPanel/Nginx
+
+## Mindest-Checks nach Deployment
+- `curl -I https://news.vanityontour.de`
+- Login erreichbar
+- Feed-Import laeuft
+- WordPress-Testpublikation (pending) erfolgreich

docs/wiki/Home.md

@@ -0,0 +1,19 @@
+# Wiki Home
+
+## Zweck
+Dieses Wiki dokumentiert Architektur, Betrieb, Sicherheit, Recht und Roadmap des Neuaufbaus von `rss-news`.
+
+## Inhalte
+- `Architektur.md`
+- `Deployment.md`
+- `Security-Auth.md`
+- `Recht-Quellen.md`
+- `Operations-Runbook.md`
+- `Roadmap.md`
+- `Project-Board.md`
+
+## Projektsteuerung
+- GitHub Project #3: https://github.com/users/OliverGiertz/projects/3/views/1
+
+## Prinzip
+Dokumentation wird bei jeder relevanten Aenderung im selben Pull Request aktualisiert.

docs/wiki/Operations-Runbook.md

@@ -0,0 +1,23 @@
+# Operations Runbook
+
+## Daily Checks
+- App erreichbar
+- Queue/Worker aktiv
+- Letzte Feed-Laeufe erfolgreich
+- Keine auffaelligen Fehler im Log
+
+## Incident: Feed-Import faellt aus
+1. RSS-Quelle erreichbar?
+2. Parser-Fehler im Log?
+3. Rate Limits oder Blockaden?
+4. Retry-Queue pruefen
+
+## Incident: WordPress Publish faellt aus
+1. WP API erreichbar?
+2. Credentials gueltig?
+3. Payload-Validation/Tag-Fehler?
+4. Artikel in `pending` statt `failed` markieren, wenn unklar
+
+## Backups
+- SQLite-Dump taeglich
+- Konfiguration und `.env` sicher sichern

docs/wiki/Project-Board.md

@@ -0,0 +1,28 @@
+# Project Board Workflow
+
+## Zentrale Steuerung
+- Board: https://github.com/users/OliverGiertz/projects/3/views/1
+- Board ist die einzige Quelle fuer Planungsstatus.
+
+## Arbeitsmodus (1 Entwickler)
+- Neue Arbeit immer als Issue anlegen
+- Issue direkt ins Project aufnehmen
+- Status nur im Project pflegen
+- PR/Commit auf Issue referenzieren
+
+## Empfohlene Status-Disziplin
+- `Todo`: noch nicht begonnen
+- `In Progress`: aktiv in Arbeit
+- `Done`: umgesetzt und dokumentiert
+
+## Konventionen fuer Issues
+- Prefix fuer Klarheit:
+  - `[MVP]`
+  - `[Infra]`
+  - `[Legal]`
+  - `[Bug]`
+- Definition of Done in jedem Issue notieren
+
+## Aktueller Backlog-Hinweis
+- Thema Userverwaltung ist fuer MVP obsolet (ein Admin-User).
+- Entsprechende Issues als `deferred` oder `closed` kennzeichnen.

docs/wiki/Recht-Quellen.md

@@ -0,0 +1,35 @@
+# Recht und Quellen
+
+## Grundregeln
+- Nur freigegebene Quellen aus Source-Register
+- Pflicht-Attribution pro Artikel
+- Rechte fuer Bilder separat pruefen
+- Kein Autopublish bei unklarer Lizenz
+
+## Bewertungsmodell
+- Gruen: Freie Nachnutzung klar erlaubt
+- Gelb: Nutzung mit Einschraenkungen/Einzelfallpruefung
+- Rot: Ohne Zusatzlizenz nicht geeignet
+
+## Aktuelle Referenzen
+- Reuters/Thomson Reuters Terms: https://www.thomsonreuters.com/en/terms-of-use
+- Presseportal Nutzungsbedingungen: https://www.presseportal.de/nutzungsbedingungen
+- tagesschau RSS-Hinweise: https://www.tagesschau.de/infoservices/rssfeeds
+- Datenlizenz Deutschland BY 2.0: https://www.govdata.de/dl-de/by-2-0
+- GovData Lizenzen: https://data.gov.de/informationen/lizenzen
+- EU Legal Notice (CC BY 4.0): https://commission.europa.eu/legal-notice_en
+
+## Review-Checkliste je Quelle
+1. Sind Bearbeitung und Veroeffentlichung erlaubt?
+2. Ist kommerzielle Nutzung erlaubt?
+3. Gibt es gesonderte Bildrechte?
+4. Ist die Quellenangabe vorgeschrieben?
+5. Gibt es Archivierungs- oder Weitergabebeschraenkungen?
+
+## Operativer Schutz
+- Source-Register als Pflicht vor Feed-Aktivierung
+- Auto-Block bei fehlenden Lizenzdaten
+- Quartalsweiser Terms-Recheck
+
+## Hinweis
+Keine Rechtsberatung. Finale Freigabe kritischer Quellen bei Bedarf juristisch validieren.

docs/wiki/Roadmap.md

@@ -0,0 +1,19 @@
+# Roadmap
+
+## Jetzt
+- Doku und Projektstruktur bereinigen
+- Redirect aktiv
+- Backlog auf Neustart ausrichten
+
+## Naechster Schritt
+- FastAPI-MVP implementieren
+- Login + Feed-Ingestion + Review + WordPress pending
+
+## Danach
+- Worker/Queue
+- Source-Policy Enforcement
+- Monitoring/Reporting
+- Optional Passkey
+
+## Steuerung
+Alle Arbeitsitems liegen im GitHub Project #3.

docs/wiki/Security-Auth.md

@@ -0,0 +1,16 @@
+# Security und Auth
+
+## Mindestanforderungen
+- Zugriff auf die WebApp nur mit Login
+- Ein aktiver Admin-User (kein Rollenmodell im MVP)
+- Passwort nicht im Repo, nur als Secret auf Server
+
+## Empfohlene Umsetzung
+- Session-basierte Auth (HTTP-only Cookies)
+- Passwort gehasht (Argon2 oder bcrypt)
+- Rate Limiting auf Login-Endpunkt
+- CSRF-Schutz fuer Form-Aktionen
+
+## Spaeter (optional)
+- Passkey/WebAuthn als zusaetzlicher Login-Faktor
+- IP-Allowlist fuer Admin-Zugang