## Ergebnis der Read-only-Analyse

### Ist-Zustand

- Basis/Arbeitsbaum: `95c9c03b222169c50b866e83129bbf2e497d80ee`, sauber.
- Kalender und Tagesansicht sind V5-only und opt-in über `--calendar-day-6d`; V4 bleibt unberührt.
- Kalender:
  - vollständig handgebaut in `dashboard-v5-day-controller.js`;
  - Monatsraster aus Buttons, eigene Pfeiltastensteuerung und Monats-Agenda;
  - Daten aus dem bestehenden, begrenzten `/api/v1/calendar`-Vertrag;
  - Desktop wirkt sehr flach und wenig kalenderartig; mobile werden Kategorien nur als identische Punkte dargestellt, während die dauerhaft sichtbare Agenda die Seite stark verlängert.
- Tagesansicht:
  - zentraler Router und stabiler Deep-Link `?view=day&date=YYYY-MM-DD`;
  - zweispaltige Karten, mobil einspaltig;
  - semantisch korrekt, aber überwiegend Textlisten, wenig visuelle Priorisierung;
  - leere Bereiche beanspruchen viel Fläche; technische Begriffe und lange Notizen erhöhen die Dichte.
- Chart-Stack:
  - Chart.js wird in V5 immer lokal geladen;
  - ECharts wird beim Kalender-Flag indirekt über den automatisch aktivierten Explorer geladen;
  - die Tagesansicht selbst benötigt keine Chartengine.
- Assets werden explizit über `ASSET_ROUTES` freigegeben. Für ECharts existiert bereits ein gutes Muster aus gepinnter Datei, Metadaten, SHA-256, Lizenz und NOTICE.
- Tests:
  - Python-Vertrags-/Render-/Assettests;
  - isolierte Playwright-Matrix mit synthetischer DB;
  - dedizierte Kalender-/Tagtests für Routing, Tastatur, Reload/History, 390 px, 44-px-Ziele und Screenshots.

## Minimaler FullCalendar-Vorschlag

**Exakt pinnen:** FullCalendar Standard `6.1.21` — npm meldet für Core, DayGrid und Interaction jeweils MIT. Keine Premium-/Scheduler-Pakete.

Lokale Runtime-Dateien:

- `fullcalendar-core-6.1.21.global.min.js` – ca. 182 KB
- `fullcalendar-daygrid-6.1.21.global.min.js` – ca. 27 KB
- `fullcalendar-interaction-6.1.21.global.min.js` – ca. 36 KB
- `fullcalendar-de-6.1.21.global.min.js` – 873 Byte
- `FULLCALENDAR-6.1.21-LICENSE.md`
- `fullcalendar-6.1.21.metadata.json` mit Quelle, Paket-Integrities und SHA-256 aller ausgelieferten Dateien

Die drei Pakete verwenden denselben MIT-Lizenztext; ermittelter SHA-256 des Lizenztexts:

`4c0b0dae26c99e3b11be70b990a703be4deb75e21884104582e0e217786d3209`

Zusätzlich sollten in `package.json`/Lockfile die drei Pakete exakt als `6.1.21`, ohne `^` oder `~`, erfasst werden. Die Global-Builds sind für die frameworkfreie Architektur passend; FullCalendar 6 bringt seine Styles über die JS-Bundles mit, daher ist kein CDN-Stylesheet erforderlich.

### Konkrete Einbindung

1. In `health_dashboard_server.py` vier feste Asset-Routen ergänzen.
2. In `render.py` die vier lokalen Scripts ausschließlich bei `calendar_day_6d=True` und vor `dashboard-v5-day-controller.js` ausgeben:
   1. Core
   2. deutsche Locale
   3. DayGrid
   4. Interaction
   5. eigener Controller
3. Bestehenden Kalender-Container beibehalten, aber das handgebaute Raster durch eine einmalig erzeugte `FullCalendar.Calendar`-Instanz ersetzen:
   - `initialView: 'dayGridMonth'`
   - `locale: 'de'`
   - `firstDay: 1`
   - `headerToolbar: false`, damit vorhandene V5-Steuerung und visuelles Design erhalten bleiben
   - `fixedWeekCount: false`
   - `showNonCurrentDates: false`
   - `editable: false`, `selectable: false`, `droppable: false`
   - `dateClick` aus Interaction ruft unverändert `openDay(...)` auf
   - `navLinks: true` plus `navLinkDayClick` für tastaturbedienbare Tagesnummern
   - `eventClick` öffnet denselben zentralen Tagesrouter
4. API und Serververtrag nicht verändern. `payload.days` wird clientseitig zu höchstens einem neutralen FullCalendar-Event je dokumentiertem Tag abgebildet; Kategorien und Counts bleiben `extendedProps`.
5. Event-/Zellinhalt nur über DOM-Knoten und `textContent`, nicht als ungeprüftes HTML erzeugen.
6. Vor/Zurück/Heute und Monatsfeld auf `calendar.prev()`, `next()`, `today()` und `gotoDate()` umstellen. Bestehende Request-Versionierung, Timeout-, Retry- und Sessionlogik bleibt bestehen.
7. Die lange Agenda als standardmäßig geschlossenes `<details>` „Monatsliste der dokumentierten Tage“ behalten. Das erhält einen zugänglichen Text-Fallback, ohne mobil die Hauptansicht zu dominieren.

## Visuelle Tagesansicht ohne neue Chartengine

Nur vorhandenes HTML/CSS und den unveränderten Day-V2-Vertrag verwenden:

- Direkt unter dem Datum ein **„Dokumentation an diesem Tag“**-Band aus acht kompakten Kategorie-Kacheln:
  - Messwerte, Symptome, Medikamente, Ernährung, Labor, Ereignisse, Termine, Dokumente;
  - Zahl aus `coverage.counts`, Status „dokumentiert“/„nicht dokumentiert“;
  - anklickbare Sprunglinks zu den vorhandenen Sektionen.
- Wichtig: als **Dokumentationsband**, nicht als Uhrzeit-Timeline bezeichnen. Der Vertrag enthält für viele Quellen keine belastbaren Uhrzeiten; eine Stundenachse wäre irreführend.
- Messwerte als kleine KPI-Kacheln statt einer Bullet-Liste: Label, Wert/Einheit, darunter Aggregation und Qualität.
- Symptomwerte als beschriftete, neutrale CSS-/native `<meter min="0" max="3">`-Zeilen darstellen; Wert und „nicht dokumentiert“ bleiben zusätzlich ausgeschrieben. Keine Rot-Gelb-Grün-Semantik.
- Medikamentenzustände als klar getrennte Gruppen/Badges „Geplant“, „Verabreicht“, „Ausgelassen“, „Korrigiert“.
- Leere Sektionen weiterhin sichtbar lassen, aber als kompakte, gedämpfte Statuszeile statt großer Leerkarte.
- Desktop bei zwei Spalten belassen; mobile Reihenfolge nach Relevanz: Übersicht → Messwerte → Symptome → Medikamente → Ernährung → Ereignisse/Termine → Labor → Dokumente → technische Details.

## Minimale Testanpassungen

- Python:
  - exakte Version, MIT-Lizenz, Hash und feste Asset-Routen prüfen;
  - Scripts nur beim Kalender-Flag vorhanden;
  - Standard-V5 und V4 enthalten keine FullCalendar-Assets;
  - weiterhin keine externen Runtime-URLs.
- Playwright:
  - deutsche Locale/Wochentage und Monatsnavigation;
  - Tagesnummer per Klick und Tastatur öffnet exakt einmal `/api/v1/day/...`;
  - Deep-Link, Back/Forward und Retry unverändert;
  - 390 px ohne horizontalen Overflow, sichtbare Controls mindestens 44 px;
  - Monatsliste zugänglich, aber initial geschlossen;
  - Request-Monitor: keine Nicht-Same-Origin-Anfrage.
- Bestehende `data-calendar-date`-Hooks über `dayCellDidMount` an den Tageslinks erhalten, damit möglichst wenige Tests umgeschrieben werden müssen.

### Dateien geändert/erstellt

- Keine. Repository blieb vollständig unverändert.
- Keine Probleme außer einer einmalig fehlerhaften Inhalts-Suchregex; relevante Dateien wurden anschließend direkt gelesen.