## Aktualisierungsempfehlung für `docs/dashboard_v4_v5_parity.md`

**Empfohlener Dokumentkopf:** Stand Sprint 7A V5-RC-Konsolidierung, Quellenabgleich auf `e33ef9253d255b557fd998eef70c1d989ab24d87`.  
**Fallback-Grundsatz unverändert:** V4 bleibt erreichbar und darf weder geändert noch abgeschaltet werden.

| Funktionsfamilie | Empfohlener Status | Evidenz auf HEAD | Verbleibender Umfang |
|---|---|---|---|
| Globale Suche | **verbessert** | Gruppierte, serverseitig allowlistete Suche über Metriken, Labore, Ereignisse, Dokumente und Tage: `dashboard_v5/read_api.py`, `dashboard-v5-global-search.js`; Verträge in `test_dashboard_v5_sprint6b_api.py::test_event_and_search_apis_are_grouped_bounded_and_redacted` und `test_dashboard_v5_sprint6e_record.py::test_document_keyset_cursor_is_bound_and_complete`. | Kein Paritätsblocker; Allowlist und Drill-down-Verträge als Release-Gate beibehalten. |
| Datenprüfhinweise und To-dos | **teilweise** | Heute erzeugt Check-in-, Dokumentreview- und Mapping-Aufgaben sowie getrennte technische Aufbereitung: `data_provider.py:401-423`. Der Day-Contract liefert neutrale Hinweise für fehlende Dokumentation, unvollständige Symptome und fehlende Laborreferenz: `read_api.py:2413-2445`. | Bundle-`notices` und `freshness` bleiben leer; quellenweite, cadence-/importbezogene Datenqualitätsaufgaben fehlen. |
| Apple-Health-Trends | **verbessert** | Katalog und API unterstützen zwölf freigegebene Apple-Identifier mit Einheiten/Aggregationen; `docs/sprint6b-metric-catalog-read-api.md`, `metric_catalog_v2.py`, `test_dashboard_v5_sprint6b_api.py`, `test_dashboard_v5_sprint6c_api_contracts.py`. Explorer zeigt freigegebene Reihen samt Baseline und Lücken. | Weitere beobachtete Identifier nur einzeln nach Parser-, Einheiten-, Aggregations- und Fixture-Nachweis freigeben; keine pauschale V4-Breitenparität. |
| Apple-Coverage und Quellenqualität | **teilweise** | Serien liefern erwartete/beobachtete/fehlende Tage, Qualität und Quellenvertrag; UI zeigt Coverage je Reihe: `read_api.py`, `dashboard-v5-api-explorer.js:197-242`; Tests in `test_dashboard_v5_sprint6b_api.py` und `test_dashboard_v5_sprint6c_api_contracts.py`. | Konflikt-, Fallback-, Import- und Frischezustände fehlen weiterhin als zusammenhängender Bereich „Daten & System“. |
| Laborübersicht nach Themen | **teilweise** | Kanonischer Finder, beobachtungsspezifische Referenzen und Dokumentprovenienz sind vorhanden: `read_api.py`, `dashboard-v5-record.js`; `test_dashboard_v5_sprint6e_record.py`, `test_dashboard_v5_sprint6g_a2_labs.py`. | Quellenparität bleibt absichtlich unvollständig; der dokumentierte 6G-A.2-Abgleich weist weiterhin eine erhebliche Differenz zur Excel-Arbeitsmatrix aus. Neue Review-/Transferpfade ersetzen keine Originalprüfung. |
| Laborverläufe | **teilweise** | Akte bietet gruppierte Historien und „Verlauf öffnen“; URL-/Range-Vertrag und Referenzstatus sind getestet: `dashboard-v5-record.js:610-626`, `test_dashboard_v5_sprint6e_record.py::test_lab_chronology_report_range_and_next_planned_scaling`, `test_dashboard_v5_sprint6c_api_contracts.py::test_lab_series_points_emit_reference_or_explicit_missing_reference_state`. | Funktionsfähig nur für bestätigte katalogisierte Beobachtungen; breitere V4-Arbeitsmatrix bleibt außerhalb der V5-Freigabe. |
| Dokumenten-Review-Inbox | **verbessert** | Sichere lokale Aufnahme, getrennte technische/inhaltliche Zustände, kompakte Review-Queue, Seitenprüfung, Kandidatenabgleich und expliziter idempotenter Transfer: `document_review.py`, `document_reconciliation.py`, `dashboard-v5-record.js`; `test_dashboard_v5_sprint6i_a.py`, `test_dashboard_v5_sprint6i_c.py`. | Operative Reviewfälle bleiben abzuarbeiten; ungeprüfte Inhalte bleiben weiterhin aus verifizierter Suche, Arztbericht und medizinischen Ableitungen ausgeschlossen. |
| Gesundheitstimeline | **verbessert** | Kalender und zentraler Day-Contract bündeln Messwerte, Symptome, vier Medikationszustände, Ereignisse/Phasen, Labore, Ernährung, Dokumente und Termine: `docs/sprint6d-calendar-day-drilldown.md`, `read_api.py`, `dashboard-v5-day-controller.js`. HEAD-Fix ergänzt gemeldete Symptome und lange Telegram-Ereignisse; Regression in `test_dashboard_v5_sprint6d_day_calendar.py::test_user_reported_symptoms_and_long_note_events_remain_visible`. | Kein erkennbarer Paritätsblocker; Fallback und synthetische Browserabnahme beibehalten. |
| Medikations-Rohhistorie | **teilweise** | API trennt geplant, verabreicht, ausgelassen und korrigiert und liest Dosis, Route, Notiz und Quelle: `read_api.py:3350-3418`; Status-/Historientests in `test_dashboard_v5_sprint6e_record.py`. | Akten-UI zeigt derzeit nur Datum, Medikament, Dosis und Quelle (`dashboard-v5-record.js:636-644`). Route/Notiz sowie Charge/Injektionsstelle werden nicht vollständig dargestellt bzw. sind nicht durchgängig modelliert. |
| Health Events und Phasen | **verbessert** | Day-Contract und Events-API liefern konkrete Ereignisse und mehrtägige Phasen getrennt: `read_api.py`, `dashboard-v5-day-controller.js`; `test_dashboard_v5_sprint6d_day_calendar.py::test_multi_day_event_and_supported_future_appointment` und `test_dashboard_v5_sprint6b_api.py`. | Keine Restparität erkennbar; weiterhin keine aggregierte Phase als Ersatz für konkrete Ereignisse behandeln. |
| Symptome | **verbessert** | Total und sieben Einzeldimensionen sind katalogisiert; echte Null, unvollständige Tage und zusätzliche Beschwerden bleiben explizit: `metric_catalog_v2.py:165-168`, `read_api.py`; `test_dashboard_v5_sprint6d_day_calendar.py`, `test_dashboard_v5_sprint6c_api_contracts.py`. Aktueller HEAD schließt zusätzlich die Kalender-/Telegram-Sichtbarkeitslücke. | Kein wesentlicher Funktionsrest; Release-Gates für Null/Missingness, Kalender und Explorer beibehalten. |
| Mahlzeiten- und Tagesdetails | **teilweise** | Detail-API und UI zeigen Mahlzeitengruppen, Items, Mengen, Makros, Nährstoffe, Mappingstatus und Unsicherheit: `read_api.py`, `dashboard-v5.js:860-870`; `test_dashboard_v5_sprint6g_nutrition.py::test_nutrition_read_apis_are_bounded_allowlisted_and_incomplete_not_zero`. | Explizite Quellen-/Importfrische pro Tag fehlt; deshalb noch nicht vollständig „verbessert“. |
| Histamin und Symptomvergleich | **verbessert** | Histamin-Zuordnungsindex mit Coverage/Missingness, Explorer-Overlay und kontrollierte zeitliche Assoziationen sind vorhanden: `nutrition_contract.py`, `association_engine.py`, `dashboard-v5-associations.js`; Tests `test_dashboard_v5_sprint6g_b3.py` und `test_dashboard_v5_sprint6f_a.py`. | Kein Kausalitätsclaim; Coverage, Tageslinks und vollständige Klassifikation bleiben zwingende Gates. |
| Persönliche Lebensmittelverträglichkeit | **teilweise** | Persönlicher Status und Notiz werden getrennt von der allgemeinen Klassifikation gespeichert und in Tagesitems projiziert: `read_api.py:2116-2203`, `health_dashboard_action_worker.py`; `test_dashboard_v5_sprint6g_nutrition.py::test_mapping_worker_is_transactional_idempotent_and_recomputes_only_affected_days`. | Expliziter Beobachtungszeitraum und Coverage/Evidenzumfang pro Verträglichkeitsaussage fehlen. |
| Low-Histamin-Experimente | **teilweise** | Generische persönliche Beobachtungspläne unterstützen versionierte Baseline-, Beobachtungs-, Änderungs- und Follow-up-Phasen, Check-ins, Missingness und unveränderliche Resultate: `observation_contract.py`, `observation_engine.py`; `test_dashboard_v5_sprint6f_c.py`. | Kein eigener Low-Histamin-/Challenge-Vertrag; Expositionssemantik und spezifische Challenge-Abnahme fehlen bewusst. |
| Mapping-Queue | **teilweise** | Queue liefert opaque Key, Auftretensanzahl, erstes/letztes Auftreten, Vorschlag, Grund und Status; transaktionale/idempotente Review-Aktionen sind vorhanden: `read_api.py:2309-2340`, `test_dashboard_v5_sprint6g_nutrition.py`. | Confidence ist in der offenen Queue nicht durchgängig ausgewiesen; Review-/Entscheidungsstatus könnte differenzierter als nur `open` veröffentlicht werden. |
| Datenqualität | **teilweise** | Header berechnet Datenrezens aus dokumentierten Serien; „Daten & System“ zeigt Vertrag, freigegebene Metriken und minimierte Punktzahl: `dashboard-v5.js:507ff.,1383-1391`. Serien besitzen technische Coverage. | `bundle.freshness` bleibt leer; Quelle, letzter Datentag, erwartete Kadenz, Importstatus und quellenbezogene Coverage fehlen als vollständiger Vertrag. |
| System und Legacy | **offen** | Zielansicht existiert, enthält aber nur drei einfache Vertrags-/Zählerkarten: `render.py:211`, `dashboard-v5.js:1383-1391`. | Verbindliche Inventur jeder V4-Rohsicht fehlt: jeweils ersetzt, bewusst entfernt oder als lokaler Debugpfad dokumentieren. V4 dabei unverändert lassen. |
| Datenstatus-Karten und DB-Zähler | **teilweise** | Aggregiert sichtbar sind Vertragsversion, Zahl freigegebener Metriken und minimierte Beobachtungspunkte: `dashboard-v5.js:1383-1391`; Kalender liefert begrenzte Kategoriecounts. | Notwendige quellenbezogene Counts, Importzustände und Frische fehlen; keine Pfade oder Rohinhalte ergänzen. |

### Zusätzliche Dokumentkorrekturen

- Die Statusdefinition `offen` sollte nicht mehr auf „Umsetzung folgt in Sprint 6B–6J“ verweisen, sondern auf den verbleibenden Sprint-7A-/Post-RC-Umfang.
- Das Abschaltkriterium darf **nicht** als aktuelle Abschaltfreigabe gelesen werden: V4 bleibt ausdrücklich Fallback. Mindestens `System und Legacy` ist weiterhin offen; mehrere Zeilen bleiben teilweise.
- Die 6G-A.2-Laborabweichung sollte weiter als bewusste Trust-/Quellengrenze dokumentiert bleiben, nicht als bloßer Implementierungsrückstand.

**Verifikation:** Repository war vor und nach der Analyse sauber; keine Dateien geändert. Ein fokussierter Pytest-Lauf war nicht möglich, weil im verfügbaren Interpreter kein `pytest` installiert ist (`pytest: Befehl nicht gefunden`, `python3 -m pytest: No module named pytest`). Die Empfehlung stützt sich daher auf gelesene Produktionsquellen, vorhandene Testverträge und Sprint-Dokumente, nicht auf einen neu ausgeführten Testlauf.