# Sprint 6D — Kalender und zentraler Tages-Drill-down

## Scope

Sprint 6D ergänzt ausschließlich das opt-in V5-Feature `--calendar-day-6d`. Ohne Flag bleiben Standard-V5, V4, Schreibpfade und API-Nutzung unverändert. Das Flag aktiviert den abgenommenen 6C-Explorer mit, damit ECharts-Punkte den zentralen Tagesrouter verwenden.

Die Tagansicht führt dokumentierte Angaben zusammen. Sie erstellt keine Diagnose, Kausalitätsaussage, medizinische Ampel oder Therapieempfehlung.

## Programmatisch inventarisierte kanonische Quellen

| Funktionsfamilie | vorhandene kanonische Quelle | 6D-Vertrag |
|---|---|---|
| Apple-Messwerte | `apple_health_records.start_date`, ausschließlich `APPLE_SOURCE_SPECS` | kanonisch zugeordnete Zürich-Tageswerte mit Einheit, Aggregation, Quelle und Qualitätsstatus |
| Körper-/Vitalwerte | `vitalzeichen`, freigegebener Metrikkatalog | Tageswerte, sofern dokumentiert |
| Symptome | `symptom_log` mit `daily_quick_score` | sieben Dimensionen, echte Null, Total nur bei Vollständigkeit, vorhandene Notizen |
| Medikamente | `medication_administrations` | strikt getrennt: geplant, verabreicht, ausgelassen, korrigiert |
| Gesundheitsereignisse | `health_events` | Ereignisse am Tag |
| mehrtägige Phasen | `health_event_periods` | Überlappung des ausgewählten Tages |
| Labor | `laborwerte` plus kanonisch geprüfte `dokumente` | beobachtungsspezifischer Referenzbereich oder `missing_reference`, Quellenqualität, opaque Dokument-ID |
| Ernährung | `nutrition_daily_summary_v2` | vorhandene Tagessumme, Histaminwert nur bei vollständiger Klassifikation |
| Dokumente | geprüfte `dokumente` | sichere Metadaten und opaque ID; keine Pfade, URLs, Drive-IDs oder Inhalte |
| Arzttermine/-besuche | `arztbesuche` | vorhandene Einträge mit `documented_visit`; keine unbelegte Anwesenheits-/Absageableitung |

Die vorhandene Arztbesuch-Tabelle besitzt keine belastbare Uhrzeit-, Fachgebiets- oder Absage-Spalte. 6D erfindet diese Angaben nicht. **Backlog:** Eine spätere, gesondert freizugebende Erfassungsfunktion kann explizite Uhrzeit, Fachgebiet und Status inklusive abgesagt aufnehmen; sie ist kein Bestandteil von 6D.

## Day-Contract V2

`GET /api/v1/day/{YYYY-MM-DD}` liefert additiv Version 2 mit:

- `date`, `today`, `timezone=Europe/Zurich`, `is_today`, `is_future`;
- technische Coverage, Kategorien und begrenzte Counts;
- Messwerte, Symptome, vier getrennte Medikamentenzustände;
- Ereignisse und mehrtägige Phasen;
- Laborbeobachtungen mit beobachtungsspezifischer Referenzsemantik;
- Ernährung, sichere Dokumentmetadaten und vorhandene Termine;
- höchstens drei neutrale Hinweise.

Fehlend bleibt `null`, leer oder explizit `not_documented`/`supported_no_data`. Numerische Null bleibt eine Beobachtung. Der bestehende additive `metrics`-Block bleibt für 6B-Kompatibilität erhalten.

## Kalendervertrag

`GET /api/v1/calendar?from=YYYY-MM-DD&to=YYYY-MM-DD`:

- strikt validierte ISO-Daten;
- höchstens 62 inklusive Kalendertage;
- höchstens 366 Tage in die Zukunft;
- feste Tabellen-/Spaltenwahl im Servercode;
- Apple-Health-Rohkandidaten nutzen für angefragte Zeiträume `(metric,start_date)` mit einem Zürich-neutralen Rohrand von je einem Kalendertag; erst die kanonische Analytics-Schicht ordnet nach `Europe/Zurich` zu;
- fixe Quellenlimits und bestehendes SQLite-Laufzeitlimit;
- kompakte Tageskategorien und gedeckelte Counts;
- keine medizinische Bewertung.

## Navigation und Security

`dashboard-v5-day-controller.js` ist der einzige 6D-Tagesrouter. Er validiert ISO-Daten, synchronisiert `/health-dashboard-v5?view=day&date=YYYY-MM-DD`, unterstützt Reload und Browserhistorie, fokussiert die Tagesüberschrift und verwirft überholte Antworten per monotonem Request-Zähler.

Nur `dashboard-v5-api-explorer.js` erzeugt weiterhin die Same-Origin-Browsersession. Der Day-Controller wartet auf dessen Promise und verwendet keine Basic-/Bearer-Credentials, Cookies, Storage- oder URL-Credentials. Alle Assets bleiben lokal; API-Antworten bleiben `no-store` und größenbegrenzt.