# Sprint 3 — Health Dashboard v4

## Ziel

Dashboard v4 macht die vorhandenen, lokal gespeicherten Gesundheitsinformationen auf Mobilgeräten nutzbarer, ohne die in Sprint 0–2 freigegebenen Daten-, Missingness- und Evidenzverträge aufzuweichen.

## Funktionsumfang

- **Heute & Aktionen:** Status des vollständigen Symptom-Check-ins, Ernährungsklassifikation und offene Dokumenten-Reviews.
- **Quellenfrische:** technische Frische für Apple Health, Ernährung, Symptom-Quick-Log und Dokumentimport. Ein Frischestatus ist ausdrücklich keine medizinische Risikobewertung.
- **Mobile Navigation:** feste Bottom Navigation und Touch-Ziele von mindestens 44 px.
- **Touch-Check-in:** vollständiges Formular für alle sieben Symptomdimensionen; fehlende Werte werden nicht als null gespeichert.
- **Trends:** persönliche 14-Tage-Median-Baseline ab mindestens sieben dokumentierten Beobachtungen sowie Medikations- und Health-Event-Marker.
- **Zeitraumfilter:** 7/30/90 Tage oder alle Einträge für die Timeline.
- **Arzt-/Printmodus:** druckoptimierte Darstellung mit Missingness-, Provenienz- und Evidenzhinweisen.
- **Privacy Mode:** blendet sensible Detailbereiche nur für die aktuelle Browseransicht aus. Der Zustand wird nicht gespeichert.
- **Accessibility:** semantische Landmarks, Skip-Link, sichtbarer Tastaturfokus, Kontrastmodus und `prefers-reduced-motion`.
- **Lokale Charts:** Chart.js 4.5.1 wird mit geprüftem SHA-256 lokal ausgeliefert; keine CDN-Abhängigkeit.

## Sicherheitsvertrag

- Das Dashboard bindet standardmäßig ausschließlich an `127.0.0.1`. Ein privater Netzwerkzugang muss über eine explizite Tailnet-IP oder einen authentisierten lokalen Reverse Proxy konfiguriert werden.
- Jede GET-, HEAD- und POST-Anfrage wird vor dem Routing gegen `HEALTH_DASHBOARD_ALLOWED_HOSTS` geprüft; der Client-`Host` bestimmt niemals selbst die Vertrauensgrenze.
- Der Server akzeptiert nur explizit allowlistete GET-Routen und genau einen POST-Endpunkt.
- Der Touch-Check-in verlangt Same-Origin, einen einmaligen CSRF-Token und ein `SameSite=Strict`-/`HttpOnly`-Cookie.
- Der Netzwerkdienst schreibt niemals direkt in die Gesundheitsdatenbank. Er legt ausschließlich eine atomare Queue-Datei mit Modus `0600` in einem eigenen State-Verzeichnis ab.
- Ein separater, netzwerkisolierter One-shot-Worker validiert die Queue erneut und ruft erst dann den bestehenden Quick-Log-Workflow auf.
- Request-Größe, Datum, Notizlänge und alle Scores werden serverseitig validiert.
- Alle sieben Dimensionen sind Pflicht und ausschließlich 0–3 zulässig.
- Der Schreibpfad verwendet den bestehenden, getesteten Quick-Log-Workflow; keine direkte Browser-SQLite-Verbindung.
- CSP nutzt pro Antwort einen Nonce und enthält weder `unsafe-inline` noch externe Scriptquellen.
- `Cache-Control: no-store`, `X-Frame-Options: DENY`, `nosniff`, `Referrer-Policy: no-referrer` und eine restriktive Permissions Policy sind aktiv.
- Keine Diagnose, Kausalitäts-, Therapie-, Absetz- oder Entwarnungsbehauptungen.
- Fehlende Daten bleiben unbekannt. Quellenfrische und Coverage beschreiben nur Datenqualität.

## N-of-1-Ansicht

Vorhandene Low-Histamine-Experimente bleiben als strukturierte Baseline-/Challenge-/Status-Tabelle sichtbar. Die Darstellung ist ein Dokumentationswerkzeug und keine kausale Auswertung. Sprint 3 führt keine automatischen Therapieentscheidungen oder Challenge-Empfehlungen ein.

## Versionierte Runtime

- Generator: `scripts/health/health_dashboard_v4.py`
- Server: `scripts/health/health_dashboard_server.py`
- Queue-Worker: `scripts/health/health_dashboard_action_worker.py`
- Queue-Units: `deploy/systemd/health-dashboard-action-worker.path` und `.service`
- Asset: `scripts/health/assets/health-assets/chart.umd.min.js`
- Servicevertrag: `deploy/systemd/health-dashboard.service`
- Pipeline: `python3 scripts/health/health_pipeline.py dashboard-v4`

Vor einem produktiven Wechsel sind Backup, Tests, Browser-/Accessibility-Review, Runtime-Hashabgleich, DB-Integrität, Foreign-Key-Check und HTTP/CSP-Smoke-Test erforderlich.