# Dashboard V5 – Zielarchitektur für Sprint 6B–6J

**Status:** Zielbild aus Sprint 6A; noch keine produktive API- oder Frameworkmigration.
**Invarianten:** Python, SQLite, die V5-Shell, der statische Snapshot und die getrennte private Action Queue bleiben bestehen. Sprint 6A öffnet keine produktiven Gesundheitsdaten und übernimmt keine solchen Daten in Fixtures.

## Leitbild

```text
unveränderte Rohquellen + Provenienz
              ↓
kanonische Beobachtungen · Ereignisse · Dokumentverknüpfungen
              ↓
erlaubter Metrikkatalog · Suchindex · geprüfte Aggregate
              ↓
begrenzte read-only APIs mit Authentisierung/Allowlist/no-store
              ↓
Heute · Cockpit · Explorer · Ernährung · Akte · Kalender/Tag

Schreibaktionen ──> getrennte, idempotente Action Queue ──> lokaler Worker
```

Der Browser wählt und visualisiert bereits serverseitig validierte Daten. Er erhält keine freie SQL-, Tabellen-, Spalten- oder Pfadauswahl und berechnet keine neue medizinische Statistik. Fehlende Beobachtungen bleiben Lücken; eine numerische Null bleibt eine Beobachtung.

## Zielmodule

| Modul | Verantwortung | Eingabe | Ausgabe und harte Grenze | Geplanter Sprint |
| --- | --- | --- | --- | --- |
| `metric-catalog` | Stabile IDs, Aliasse, Einheit, Aggregation, Quelle, Overlay-, Baseline-, Referenz- und Datenschutzpolicy. | Kanonische Registry mit Parser-/Quellnachweis. | Allowlist; kein blindes Freischalten vorhandener DB-Spalten. | 6B |
| `series-client` | Begrenzte read-only Serienabfragen, Range/Resolution, Coverage und Lücken. | Erlaubte Metrik-ID und validierter Zeitraum. | Zeilen-/Zeitlimit, definierte Aggregation, `no-store`; keine freie Spaltenwahl. | 6B/6C |
| `search-command` | Gruppierte Suche nach erlaubten Metriken, Laboren, Ereignissen, Dokumentmetadaten und Tagen. | Normalisierte Suchphrase/Alias. | Begrenzte Treffer und sichere Snippets; kein Dokumentvolltext im globalen Bundle. | 6B/6E |
| `chart-controller` | ECharts-Optionen, Zoom, Pan, Brush, Legendenschalter, Solo, Crosshair, Punktselektion und Fallback. | Bereits validierte Serien-/Eventverträge. | Keine statistische Neuberechnung; ISO-Datum-Callback als stabile Schnittstelle. | 6C |
| `reference-band` | Persönliche Baseline, beobachtungsspezifischer Laborreferenzbereich und dokumentiertes Ziel sichtbar trennen. | Policy plus Herkunft/Gültigkeit. | Kein generisches „normal“, kein erfundenes Ampelband. | 6C/6E |
| `event-lanes` | Medikamente, Symptome, Ernährung, Termine und Kontext als getrennte Ereignisspuren. | Erlaubte Eventtypen mit ISO-Zeit. | Status zusätzlich mit Text/Icon; geplante und tatsächliche Medikation getrennt. | 6C/6D |
| `day-drilldown` | Einheitlicher Tagesvertrag für Chart, Kalender, Labor, Dokument und Suche. | ISO-Datum aus kontrollierter Navigation. | Desktop-Drawer/Mobil-Sheet; fehlende Domänen kompakt ausblenden. | 6D |
| `document-search` | Metadaten, lokale FTS5-Suche, Snippets, Viewer und Provenienz. | Erlaubte Filter und Suchphrase. | Keine lokalen Pfade/Drive-IDs; Volltext niemals im globalen Bundle. | 6E |
| `accessibility-table` | Tastatur-/Screenreader-Alternative für jeden analytischen Chart. | Dieselben angezeigten Punkte und Serien. | Datumsauswahl löst denselben Callback wie Chartpunkt aus. | 6A/6C |

## Frontend-Pfad

- Kein React-/Vue-Wechsel in Sprint 6.
- Der 6A-Prototyp bleibt ein gekapseltes lokales JavaScript-Modul, damit die Chartentscheidung unabhängig von einem Buildsystem geprüft wird.
- Ab 6B/6C werden die genannten Module als TypeScript-Module mit kleinem Vite-Build eingeführt; ECharts wird über einen Adapter gekapselt.
- Die V5-Shell und CSP kennen nur lokal gepinnte Assets. Keine CDNs, Remote-Fetches oder Inline-Handler.
- Chart.js bleibt während 6A–6C Default/Fallback und kann für kleine Sparklines beziehungsweise Druck beibehalten werden.

## API-Zielvertrag

Geplante Endpunkte, noch **nicht** in Sprint 6A implementiert:

- `GET /api/v1/metric-catalog?q=`
- `GET /api/v1/series?metric=&from=&to=&resolution=`
- `GET /api/v1/day/{date}`
- `GET /api/v1/events?from=&to=&types=`
- `GET /api/v1/labs?...`
- `GET /api/v1/documents?...`
- `GET /api/v1/search?q=`

Jeder Endpunkt benötigt Authentisierung, Host-/Origin-/Methodengrenzen soweit anwendbar, harte Feld- und Typ-Allowlist, Zeit-/Zeilenlimit, deterministische Aggregation, `Cache-Control: no-store`, sichere Fehlermeldungen und Redaction lokaler Pfade. Große Apple-Reihen, Dokumenttexte und Medien werden nicht in das statische HTML-Bundle eingebettet.

## Ereignis- und Tagessemantik

- Zürich ist die verbindliche Tageszeitzone.
- Punktselektion liefert kanonisches `YYYY-MM-DD` an `health:day-select` beziehungsweise in Sprint 6A testweise `health:prototype-day-select`.
- Kalender, Chart, Labor, Dokument und Suchtreffer navigieren später auf denselben Day-Contract.
- Ereignisintervalle behalten Start und Ende. Tagesaggregation darf sie nicht auf einen einzelnen Marker reduzieren.
- Geplante, verabreichte, ausgelassene und korrigierte Medikamentenereignisse bleiben getrennt.

## Datenschutz- und Schreibgrenze

Read-only Dashboardprozesse dürfen freigegebene Serien und Metadaten lesen, aber keine Gesundheitsdaten mutieren. Mutationen laufen ausschließlich über streng typisierte Action-Queue-Verträge mit CSRF/Origin/Auth, Idempotenz, privater Ablage und erneuter Workervalidierung. Dokumentvolltext, Fotos und Originaldateien erhalten höhere Schutzgrenzen und werden weder an Worker/Subagenten noch in öffentliche Fixtures kopiert.

## Feature Flags und Rollback

- `echarts_prototype` ist in 6A standardmäßig aus.
- Der Prototyp kann nur mit explizitem CLI-Flag, markierter read-only DB und neuer `0600`-Ausgabe in einem eigentümergeprüften privaten `0700`-Verzeichnis unter der festen Wurzel `/tmp` erzeugt werden. Symlinks und bestehende Ziele werden fail-closed abgewiesen.
- Default-v5 lädt weder ECharts noch das Prototypmodul.
- Fällt ECharts in 6C durch Accessibility-, CSP-, Performance- oder Wartbarkeitstests, bleibt Chart.js der aktive Controller.
- V4 bleibt bis zur abgeschlossenen Paritätsmatrix erreichbar.

## Nicht-Ziele von Sprint 6A

- keine produktiven APIs,
- keine produktive Metrikerweiterung,
- keine Dokument-/Labor-/Gesundheitsdatenmigration,
- keine Änderung der produktiven Chart-Engine,
- kein Deployment,
- keine medizinischen Ziel-, Warn- oder Referenzbereiche,
- keine Skill-/Profiländerung.