## Findings

- **Important – Events-Limit kann gültige Medikamentengaben stillschweigend verlieren.**  
  `read_api.py:547–557` setzt `LIMIT 1001`, bevor `event_type` auf tatsächlich verabreichte Medikamente gefiltert wird. Synthetischer Gegenbeweis: 1.001 geplante Einträge vor einer gültigen Gabe führten zu `0` Events; die gültige Gabe fehlte ohne Fehler. Damit sind Vollständigkeit, Limitsemantik und medizinische Integrität verletzt.
- **Important – gültige ISO-Grenzdaten lösen ungefangenen `OverflowError` aus.**  
  Durch `start - timedelta(days=1)` beziehungsweise `end + timedelta(days=1)` in `read_api.py:175–178` crashen beispielsweise:
  - Serie mit `0001-01-01`
  - Day-Endpunkt mit `9999-12-31`  
  Statt einer kontrollierten JSON-4xx-Antwort mit `no-store` bricht die Verarbeitung ab.
- **Important – Katalog-Availability ist nicht für alle freigegebenen Quellen korrekt implementiert.**  
  `_availability()` (`metric_catalog_v2.py:169–222`) behandelt Apple, Labor und Symptome, aber nicht `nutrition_daily_summary_v2`. Synthetischer Gegenbeweis: vorhandener gültiger Histaminpunkt wurde über `/series` ausgegeben, während der Katalog gleichzeitig `supported_no_data`, `observations: 0` meldete.
- **Important – mehrere Source-Abfragen sind nicht auf SQL-/Cursor-Ebene begrenzt.**  
  Symptom- und Ernährungsserien (`read_api.py:262–346`) können unbegrenzt viele Rohzeilen laden; das Serienlimit wird erst nach Aggregation geprüft. Das widerspricht den dokumentierten getrennten harten Source-/Response-Limits.
- **Dokumentation:** Alle sechs Endpunkte sind tabellarisch beschrieben, konkrete JSON-/curl-Beispiele existieren jedoch nur für Katalog und Serie. Die curl-Beispiele definieren `API_TOKEN`, verwenden anschließend aber den Literalwert `Bearer ***`; sie sind daher nicht direkt ausführbar.

## Verifikation

- 86 relevante Sprint-6B/V5/Apple-/Snapshot-/Capture-/Explorer-Regressionstests bestanden.
- 11 V4-Regressionstests bestanden.
- Ruff für alle geänderten/neuen Python-Dateien: bestanden.
- AST-Compile-Prüfung aller geänderten/neuen Python-Dateien: bestanden.
- `git diff --check`: bestanden.
- Alle sechs Endpunkte zweimal synthetisch ausgeführt: bytegleich/deterministisch.
- Unbekannte und doppelte Queryparameter wurden in den geprüften Endpunkten abgewiesen.
- V4-Dateien und V4-Tests stimmen hashgleich mit `HEAD` überein.
- Keine UI-, Explorer-, Deploy-, Service- oder Produktionsdaten-Dateien geändert.
- Keine Produktionsdaten geöffnet; die dokumentierte reale Source-Zahl „64“ wurde daher nicht unabhängig nachgezählt.
- Review hat keine Repository-Dateien erstellt oder verändert; finaler Git-Status entspricht dem initialen Status.

BLOCK