backend/data/rss_news.db lag im Repo. Auf dem Server liegt unter demselben Pfad die Produktivdatenbank mit 95 MB, im Repo ein Entwicklungsstand mit 200 KB. Jeder Commit, der die Datei mitgenommen haette, haette beim naechsten Deploy die Live-Daten damit ueberschrieben. Die Datei wird untracked (bleibt auf der Platte liegen), *.db und backend/data/ wandern in die .gitignore. init_db() legt die Datenbank beim ersten Start selbst an. Ausserdem: docs/AUTOMATION.md behauptete automatisches Deployment ueber GitHub Actions. Das stimmt nicht - das Remote ist Forgejo ohne Runner, und der Server hat keinen Deploy-Key, `git pull origin main` scheitert dort mit Permission denied. Der tatsaechliche Handbetrieb per Git-Bundle ist jetzt dokumentiert, die Reparatur steht in der TODO. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
49 lines
2.6 KiB
Markdown
49 lines
2.6 KiB
Markdown
# ToDo (Ein-Entwickler Setup)
|
|
|
|
## Jetzt
|
|
- [ ] WordPress Beitragsbild-Upload implementieren (`featured_media` aus ausgewaehltem Hauptbild)
|
|
- [ ] WordPress-HTML-Ausgabe pro Artikel weiter verbessern (sauberes Layout, Quellenblock, Shortcodes falls noetig)
|
|
- [ ] Publisher Fehlertexte fuer WP-Auth/Media/API in UI klarer darstellen
|
|
- [ ] End-to-end Publish Smoke-Test dokumentieren (lokal + Hetzner)
|
|
|
|
## 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
|
|
- [x] Artikel-Review-Maske mit Statusworkflow
|
|
- [x] WordPress-Publisher als separaten Service implementieren (Queue + Retry + Mapping)
|
|
- [x] Bildvorschau + manuelle Bildauswahl im Admin-UI
|
|
- [x] Automatische Bildreduktion/Scoring fuer Presseportal-Quellen
|
|
- [x] Artikel-Datum + Relevanzscore im UI/Export
|
|
|
|
## Recht/Qualitaet
|
|
- [x] Redaktionelle Freigabe vor Veroeffentlichung (Art. 50 Abs. 4 KI-VO), siehe `docs/KI-VO.md`
|
|
- [ ] KI-Register/Export der Freigaben fuer die Dokumentation (CSV je Zeitraum)
|
|
- [ ] Erinnerung, wenn Artikel laenger als X Tage auf Freigabe warten
|
|
- [ ] Randfall: "Neu schreiben" auf einem bereits in WordPress eingeplanten Artikel
|
|
aktualisiert den Beitrag, ohne eine erneute Freigabe zu verlangen. Betrifft
|
|
nur Altbestand bzw. alte Telegram-Nachrichten (die neue Freigabe-Meldung hat
|
|
keinen Rewrite-Button). Sauber waere: Slot freigeben, WP-Beitrag auf `draft`
|
|
zuruecksetzen, Artikel erneut in die Freigabe-Warteschlange.
|
|
- [x] Source-Policy in DB + Admin-UI abbilden
|
|
- [x] Pflichtfelder je Quelle erzwingen (Autor, URL, Lizenz, Hinweise)
|
|
- [x] Auto-Block bei fehlender Lizenzinfo
|
|
- [x] Pro Artikel Attribution-Block generieren
|
|
- [x] Manuelle Rechtsfreigabe als Publish-Gate
|
|
|
|
## Betrieb
|
|
- [ ] Deploy reparieren: Server hat keinen Deploy-Key (`git pull` scheitert), Forgejo hat keinen
|
|
Runner fuer `.github/workflows/deploy.yml`. Bis dahin Handbetrieb per Bundle, siehe `docs/AUTOMATION.md`.
|
|
- [x] `backend/data/rss_news.db` aus der Versionierung genommen (Live-DB 95 MB, Repo-Stand 200 KB)
|
|
- [ ] 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
|
|
- [ ] KI-Rewrite mit Prompt-Versionierung + Qualitaetsmetriken wieder aktivieren
|