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> |
||
|---|---|---|
| .. | ||
| app | ||
| static | ||
| templates | ||
| tests | ||
| .env.example | ||
| __init__.py | ||
| README.md | ||
| requirements-test.txt | ||
| requirements.txt | ||
Backend Skeleton (FastAPI)
Dieses Verzeichnis enthaelt das technische Grundgeruest fuer den Rebuild von rss-news.
Start (lokal)
python -m venv .venv
source .venv/bin/activate
pip install -r backend/requirements.txt
uvicorn backend.app.main:app --reload --port 8501
Admin UI
- Login:
http://127.0.0.1:8501/admin/login - Dashboard:
http://127.0.0.1:8501/admin/dashboard
Environment
- Datei:
backend/.env - Vorlage:
backend/.env.example
Endpoints
GET /health- HealthcheckPOST /auth/login- Login mit Admin-UserPOST /auth/logout- LogoutGET /auth/me- Aktiver UserGET /api/protected- Geschuetzter Test-EndpointGET /api/pipeline/status- Basisstatus inkl. DatensatzzaehlerGET /api/sources- QuellenlistePOST /api/sources- Quelle anlegenGET /api/sources/{source_id}/policy-check- Policy-Pruefung fuer QuelleGET /api/feeds- FeedlistePOST /api/feeds- Feed anlegenGET /api/feeds/{feed_id}/policy-check- Policy-Pruefung fuer FeedGET /api/runs- Import-/Job-Runs anzeigenGET /api/runs/{run_id}- Detailansicht eines RunsPOST /api/runs- Run startenPOST /api/runs/{run_id}/finish- Run abschliessenGET /api/articles- Artikel anzeigenGET /api/articles/{article_id}- ArtikeldetailPOST /api/articles/upsert- Artikel idempotent anlegen/aktualisierenPOST /api/articles/{article_id}/transition- Statuswechsel nach Workflow-RegelnPOST /api/articles/{article_id}/review- Review-Entscheidung (approve/reject)POST /api/ingestion/run- Feed-Ingestion starten (optional pro Feed)
Datenbank
- SQLite-Datei unter
backend/data/rss_news.db - Tabellen werden beim App-Start initialisiert.
- Tabellen:
sources,feeds,runs,articles - Dedupe-Strategie Artikel:
source_url->(feed_id, source_article_id)->source_hash
Policy-Enforcement
- Ingestion blockiert Feeds automatisch, wenn die zugeordnete Quelle nicht policy-konform ist.
- Mindestanforderungen:
risk_level=green,terms_url,license_name,last_reviewed_at,is_enabled=1. - Pro importiertem Artikel wird ein
attribution-Block inmeta_jsongespeichert.
Review-Workflow
- Statuskette:
new -> review -> approved -> published - Ablehnung im Review setzt auf
rewrite - Ungueltige Statuswechsel werden per API blockiert
Verifikation
python -m unittest backend.tests.test_db_repositories
python -m unittest backend.tests.test_ingestion
python -m unittest backend.tests.test_api_auth
CI / Online-Auswertung
- GitHub Actions Workflow:
.github/workflows/test.yml - Fuehrt Tests inkl. Coverage auf Push/PR gegen
mainaus.
Hetzner Smoketest
BASE_URL="https://news.vanityontour.de" \
APP_ADMIN_USERNAME="admin" \
APP_ADMIN_PASSWORD="..." \
bash scripts/smoke_backend.sh
Hinweis
Passwort-Hashing und CSRF/Rate-Limit sind als naechste Ausbaustufe vorgesehen.