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>
Die Pipeline liess GPT Artikel umschreiben und legte sie direkt als
geplanten WordPress-Beitrag an - ohne dass ein Mensch sie gesehen hat.
Der KI-Hinweis auf dem Blog sagt aber redaktionelle Pruefung zu, und
genau daran haengt die Ausnahme in Art. 50 Abs. 4 KI-VO.
Neuer Status `pending_review` zwischen Rewrite und Publish: Die Pipeline
endet beim Rewrite, ohne WordPress-Beitrag und ohne Publish-Slot. Erst
die Freigabe im Portal stempelt Pruefer und Systemzeit, reserviert den
Slot und legt den Beitrag an.
- Migration: editorial_review_at/_by/_note, Status-CHECK erweitert
- Spalten-Migration laeuft nach den Tabellen-Neubauten erneut, sonst
verwirft der aeltere no_image-Rebuild die frisch angelegten Spalten
- Jeder Weg nach `approved` stempelt (Button, Statuswechsel, API)
- Jeder maschinelle Rewrite loescht einen alten Stempel
- Telegram: Info mit Portal-Link statt Draft-Meldung, kein Freigabe-Button
- Altbestand bleibt unberuehrt und veroeffentlicht weiter
- EDITORIAL_REVIEW_REQUIRED=false stellt den alten Ablauf wieder her
- 14 neue Tests, docs/KI-VO.md
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
