# Sprint 4A/4B — Dashboard v5 Preview

Dashboard v5 ist eine parallele, nichtproduktive Preview. Dashboard v4 bleibt bis zur ausdrücklichen visuellen und fachlichen Abnahme der aktive Fallback.

## Informationsarchitektur

Die Preview besitzt echte, gegenseitig ausgeblendete Views:

- **Heute** — Momentaufnahme, höchstens drei Aufgaben, letzte tatsächliche und nächste geplante Medikation, vollständiger Check-in.
- **Cockpit** — sechs allowlistete Kennzahlenkarten, persönliche rückblickende Medianbasis, Gesundheitsverlauf und separate Ereignisspur.
- **Explorer** — Rohwertmodus mit höchstens zwei Metriken derselben freigegebenen Achsengruppe; persönlicher Indexmodus mit höchstens vier unterstützten Metriken und Basis `100`; sichere Presets, gleichentägiger transienter Scatter, Lag- und Phasenansichten sowie globale 7/30/90/180/Alle-Steuerung. Alle Zusammenhänge bleiben deskriptiv/explorativ.
- **Ernährung** — vollständig klassifizierter Histaminverlauf und Mapping-Review; unvollständige Zuordnungen bleiben unbekannt.
- **Arzt** — ausschließlich gegen Original verifizierte Laborwerte sowie getrennte Gabe-/Planungsinformationen.
- **Mehr** — technische Datenqualität und sekundäre Arbeitsansichten, getrennt von den primären Views.

## Architektur

```text
scripts/health/dashboard_v5/
  contracts.py          Bundle-Version, JSON- und Privacy-Grenzen
  metric_registry.py    erlaubte Metriken, Labels, Einheiten, Aggregation
  data_provider.py      read-only SQLite-Abfragen und Missingness-Regeln
  render.py             semantische HTML-Shell und eingebettetes JSON
scripts/health/assets/health-assets/
  dashboard-v5.css
  dashboard-v5.js
scripts/health/health_dashboard_v5.py
```

Der Generator akzeptiert einen expliziten DB-Pfad, öffnet SQLite read-only und schreibt HTML atomar mit Modus `0600`. Das Bundle wird als `application/json` eingebettet. `<` wird als Unicode-Escape ausgegeben, damit `</script>` den Datenblock nicht abbrechen kann.

## Bundle-Vertrag

Schema: `health_dashboard.bundle.v2`.

Zusätzlich zu den v1-Feldern enthält v2:

- `explorer` mit exakt validierten Modi und Presets,
- kanonische `unit_family`, `raw_overlay_group`, `index_mode` und `correlation_id` je Metrik,
- verschachtelte, streng validierte Korrelationsaggregate mit Lag-Richtung, Counts, Coverage, Statistik, Methode und Qualitätsflags.

Erlaubte Top-Level-Felder:

- `schema_version`, `generated_at`, `timezone`, `today`
- `metrics`, `explorer`, `series`, `events`
- `medication`, `labs`, `nutrition`
- `tasks`, `notices`, `freshness`, `correlations`

Dashboard-v5- und Korrelations-CLI-Aufrufe verlangen `--db` zwingend und schlagen ohne explizite Datenbankauswahl fehl. Dadurch kann ein synthetischer oder benutzerdefinierter Lauf nicht still auf die kanonische Gesundheitsdatenbank zurückfallen.

Nicht erlaubt sind Roh-JSONs, lokale Pfade, Drive-IDs, beliebige SQL-/Tabellennamen und nicht benötigte Freitexte. `NaN` und unendliche Zahlen werden abgewiesen. Metrikreihen dürfen nur IDs aus der Registry verwenden. Zusätzlich gelten feste Count-Grenzen je Sammlung und ein serialisiertes Bundle-Budget von 512.000 UTF-8-Bytes.

## Safety-Verträge

- Fehlende Werte bleiben `null`; explizite Null bleibt numerisch `0`.
- Ein Symptomtag ist nur bei exakt sieben dokumentierten Dimensionen vollständig.
- Die Medianbasis verwendet ausschließlich frühere Beobachtungen und mindestens drei Werte; der Index wird nur bei positiver Basis berechnet.
- Scatterwerte werden nur transient aus bereits freigegebenen Tagesreihen gleichentägig verbunden; keine Paarvektoren werden gespeichert oder zusätzlich ausgeliefert.
- Positive Lags bedeuten ausdrücklich Prädiktor an Tag `d` und Ziel an Tag `d + Lag`.
- Phasen werden nur deskriptiv nebeneinandergestellt; ein statistischer Phasenunterschied wird nicht behauptet.
- Nur `administered`/`verabreicht` zählt als tatsächliche Gabe.
- Nächste Planung: vollständiges Zukunftsdatum, frühester zulässiger Termin, abgesagte/verpasste Termine ausgeschlossen.
- Cockpit/Arzt verwenden nur `laborwerte` mit `verified_against_original=1`, validiertem Status und verifizierter Referenzquelle.
- Ein Histamin-Tageswert wird nur bei vollständiger Klassifikation dargestellt.
- Korrelationen bleiben explorativ; keine Diagnose-, Kausalitäts-, Therapie- oder Entwarnungsaussage.
- Keine Gesundheitswerte in `localStorage` oder `sessionStorage`.

## Servergrenze

Die bestehende gehärtete Serverkomponente kann optional bereitstellen:

- `/health-dashboard-v5`
- `/health-assets/dashboard-v5.css`
- `/health-assets/dashboard-v5.js`

Die Routen- und Asset-Allowlist bleibt exakt. CSP, Host-Allowlist, `no-store`, Same-Origin/CSRF und private Queue bleiben unverändert. v5 ersetzt `/health-dashboard` nicht.

## Tests

- synthetische Fixture aus dem kanonischen Schema,
- Missingness versus explizite Null,
- vollständige versus partielle Symptomtage,
- Status-sichere Medikation,
- verifizierte Laborgrenze,
- unvollständiges Food-Mapping,
- JSON-Escaping und read-only Generierung,
- optionale v5-Route und exakte Asset-Allowlist,
- Playwright-Checks bei 390×844, 768×1024, 1024×768 und 1366×768,
- reproduzierbare lokale Browserabhängigkeit über `package-lock.json` und `npm ci`,
- Tastatur-/Dialog-Fokus, alle sichtbaren Interaktionsziele, Privacy über alle Gesundheitsviews, Arzt-Druck, 200-%-Text, Reduced Motion und schema-leeres Bundle.

Screenshots, Traces und Testdatenbanken bleiben lokale Testartefakte und werden nicht committed.

## Sprint 4B Advanced Explorer

Umgesetzt sind:

- persönliche Indexdarstellung mit Basis `100` und maximal vier unterstützten Reihen,
- Rohwertmodus mit kanonischer Achsengruppen-Kompatibilität,
- feste allowlistete Presets,
- gleichentägige transiente Scatterdarstellung ohne neue Record-Level-Payload,
- Lag-Ansicht für Lags 0–3 mit expliziter Richtung,
- deskriptiver Phasenvergleich ohne Differenztest-Behauptung,
- einzelne, nur aus vollständig dokumentierten Tagen abgeleitete Symptomtargets,
- engine-identische Allowlist- und Statistikvalidierung an Persistenz- und Dashboardgrenze.

Weiterhin nicht Teil dieses Sprints sind kausale Modelle, Therapieempfehlungen, formale Tests auf Unterschiede zwischen Behandlungsphasen und eine öffentliche API.
