## Ergebnis

- Basisstand **96df2a255dcfb73ea56257997a15e64d58824d64** bestätigt.
- Arbeitsbaum ist sauber; **nichts erstellt oder geändert**.
- Bestehende Labor-, Akten-, Dokument-, Today-, Session- und Browserflüsse wurden end-to-end nachverfolgt.

## Ist-Zustand

- Die Gesundheitsakte nutzt bereits die zentrale Navigation `view=record&tab=labs`; es ist kein neuer View oder Router nötig.
- Sichtbare Bezeichnungen sind derzeit **„Labore“** und **„Labor-Finder“**.
- `renderLabs()` unterstützt bereits:
  - Parametersuche und Aliase,
  - Von-/Bis-Filter,
  - Gruppierung nach `metric_id`,
  - Einzelbeobachtungen,
  - neutralen Delta-Text,
  - Wechsel zu Verlauf, Untersuchungstag und geprüftem Quelldokument.
- `_record_labs()` liefert ausschließlich freigegebene, gegen das Original verifizierte Laborwerte. Referenzbereiche bleiben beobachtungsspezifisch; fehlende Referenzen bleiben unbekannt.
- Die Response enthält je Parameter bereits vollständige Historienmetadaten. Eine verständliche Gesamt-Coverage und ein Quellenfilter fehlen noch.
- Laborwerte bleiben sichtbar, wenn das verknüpfte Dokument noch nicht inhaltlich geprüft ist. Dann wird absichtlich **keine** öffnungsfähige `document_id` ausgegeben.
- `openDocument()` führt ausschließlich über die bestehende Dokumentprüfung. Originale werden privat, mit generischem Downloadnamen und ohne Pfad-/Dateinamenausgabe ausgeliefert.
- Die private V5-Seite bleibt durch Principal-Authentifizierung plus einmaligen Browser-Session-Bootstrap geschützt. Read-API-Antworten sind `no-store`.
- Today ist bereits doppelt begrenzt: `tasks[:3]` im Provider und `.slice(0, 3)` im Renderer.
- Laborprüfung besitzt aktuell keinen eigenen Today-Task. Laborbezogene Dokumententscheidungen gehören bereits zur Aufgabe **„Dokumente prüfen“**.
- Auffälligkeit: `renderLabs()` berechnet die sichtbare Veränderung erneut aus den aktuell gefilterten Zeilen. Dadurch kann ein Datumsfilter den Vergleichspartner verändern, obwohl `_record_labs()` bereits den korrekten vorherigen Wert und `absolute_change` über die vollständige Historie liefert.

## Minimaler migrationsfreier Touchpoint-Plan

### 1. Bereich und Navigation

Bestehenden Schlüssel `labs` und die Route unverändert lassen. Nur die sichtbare Sprache präzisieren:

- Akten-Tab und Schnellzugriff: **„Laborwerte prüfen“**
- Bereichsüberschrift: **„Laborwerte prüfen“**
- Untertitel: bestätigte Beobachtungen ansehen; keine erneute medizinische oder dokumentarische Freigabe.

Touchpoints:

- statischer `[data-record-tab='labs']`
- `tabLabels.labs`
- `renderOverview()` und `.record-quick-actions`
- `renderLabs()`
- `activate()`, `render()`, `setRoute()` und `route()` unverändert weiterverwenden.

### 2. Filter, Suche und Quelle

`FILTER_KEYS.labs` minimal von `q/from/to` um `source` erweitern. In `renderLabs()` neben Suche und Zeitraum einen allowlist-basierten Quellenfilter anbieten:

- `all` – alle bestätigten Laborbeobachtungen
- `reviewed_document` – geprüftes Quelldokument verknüpft
- `linked_review_pending` – Dokument verknüpft, Inhaltsprüfung ausstehend
- `unlinked` – kein kanonisches Dokument verknüpft

Backend-Touchpoints:

- `dispatch_api()` erlaubt für den bestehenden Laborendpunkt zusätzlich ausschließlich `source`.
- `_record_labs()` validiert den Enum fail-closed und filtert anhand von `document_link_status`, `document_review_status` und `document_id`.
- `_verified_lab_rows()` muss weder Schema noch SQL-Quelle ändern.
- Keine Rohwerte wie `source_type`, interne IDs, Pfade oder Dateinamen an die Oberfläche reichen.

Frontend-Touchpoints:

- `FILTER_KEYS.labs`
- `sanitizeFilters()`
- `renderLabs()`
- `.record-filter-form`, ergänzt um `[data-lab-source-filter]`
- bestehende History-State-Mechanik über `snapshotFilters()` und `restoreFilters()`.

### 3. Coverage und Gruppierung

Die bestehende Gruppierung nach `metric_id` beibehalten. Keine zweite Gruppierungslogik oder neue Tabelle einführen.

`_record_labs()` sollte zusätzlich eine filterbezogene `coverage` liefern:

- Anzahl kanonischer Parameter,
- Anzahl bestätigter Beobachtungen,
- mit beobachtungsspezifischem Referenzbereich,
- ohne dokumentierten Referenzbereich,
- mit geprüftem Quelldokument,
- mit verknüpftem, noch ungeprüftem Dokument,
- ohne Dokumentverknüpfung,
- effektiver Datumsbereich,
- explizit `complete_page`, solange keine Kürzung vorliegt.

Wichtig: Für intermittierende Laborwerte **keine erwarteten Tage und keine vermeintliche Tagesabdeckung** berechnen.

Frontend:

- neue kompakte `[data-lab-coverage]` vor `.lab-parameter-list`
- Parameterkarten bleiben `.lab-parameter-card`
- verständliche Quellenzeile pro Karte, z. B. „Geprüftes Quelldokument verknüpft“
- technische Statuscodes nicht direkt anzeigen.
- Delta aus `previous`/`absolute_change` des API-Vertrags übernehmen, nicht aus den gefilterten UI-Zeilen neu berechnen.

### 4. Dokumentprüfung unverändert respektieren

- „Quelldokument öffnen“ nur bei vorhandener opaker `document_id`.
- `openDocument(id, 'labs', {filters})` weiterverwenden.
- Bei ausstehender Dokumentprüfung nur neutralen Quellenstatus zeigen; kein Direktzugriff auf Original, Preview oder interne Identität.
- Dokumententscheidungen verbleiben in der bestehenden Dokumentprüfungs-Queue.
- Keine Worker-, Aktions-, CSRF- oder Originalroute ändern.

### 5. Today bewusst nicht erweitern

`build_bundle()`, `dispatchTaskAction()` und `renderToday()` bleiben für diesen Sprint unverändert.

Begründung:

- Die angezeigten Laborwerte sind bereits gegen das Original verifiziert und erzeugen keine eindeutige offene Nutzerentscheidung.
- Offene laborbezogene Dokumententscheidungen werden bereits durch **„Dokumente prüfen“** repräsentiert.
- Ein zusätzlicher Task **„Laborwerte prüfen“** wäre eine doppelte Aufgabe.
- Bestehende Obergrenze von drei Tasks bleibt erhalten.

### 6. CSS nur ergänzend

Bestehende Akten- und Laborklassen weiterverwenden. Nur falls erforderlich:

- `.lab-coverage`
- `[data-lab-coverage]`
- `[data-lab-source-filter]`

Keine neue Layoutstruktur; 44-Pixel-Ziele, mobile Einspaltigkeit und vorhandene Overflow-Regeln übernehmen.

## Playwright: exakt 6 fokussierte Szenarien

1. **Private Direktroute und Navigation**  
   Authentifizierter Aufruf von `view=record&tab=labs`, genau ein Session-Bootstrap, sichtbarer Bereich „Laborwerte prüfen“, aktiver `[data-record-tab='labs']`, Reload sowie Back/Forward bleiben im zentralen Router.

2. **Suche, Zeitraum und Quellenfilter**  
   CRP-Alias, Von/Bis und alle vier Quellenwerte prüfen; Request enthält ausschließlich `q`, `from`, `to`, `source`. Filter bleiben tabbezogen erhalten und gelangen nicht zu Dokumenten oder Terminen.

3. **Coverage und stabile Gruppierung**  
   `[data-lab-coverage]` gegen synthetische Vertragszahlen prüfen; genau eine `.lab-parameter-card` pro `metric_id`, korrekte Beobachtungsanzahl und neutrale Missing-Reference-Anzeige. Keine erwarteten Tage oder erfundene Nullwerte.

4. **Delta unabhängig vom sichtbaren Filter**  
   Einen Zeitraum wählen, der nur den neuesten Wert zeigt. Die Veränderung muss weiterhin dem API-Feld `absolute_change` zur vorherigen bestätigten Gesamt-Historienbeobachtung entsprechen und darf nicht zu „kein vorheriger Wert“ wechseln.

5. **Quelle, Dokumentprüfung und Navigation**  
   Geprüftes Quelldokument öffnet über `openDocument()` die bestehende Dokumentansicht und Back stellt Laborfilter wieder her. Bei `linked_review_pending` und `unlinked` fehlt die Öffnungsaktion. Kein Pfad, Dateiname, interner Schlüssel oder Rohstatus im sichtbaren Text.

6. **Mobile, Today und Fehlerfreiheit**  
   Bei 390 px und 200 % Text: kein Seitenüberlauf, alle sichtbaren Controls mindestens 44 px, Quelle und Coverage verständlich. Today hat höchstens drei eindeutige Aufgaben; eine laborbezogene Dokumententscheidung erscheint nur als bestehende Dokumentprüfungsaufgabe und nicht zusätzlich als Laboraufgabe. Keine Console-, 4xx/5xx- oder externen Requests.

## Änderungen und Probleme

- **Geänderte/erstellte Dateien:** keine.
- **Blocker:** keine.
- **Zu berücksichtigen:** Mehrere ältere Browserfälle decken bereits Verlauf, Tagesnavigation, Dokumentquelle und Mobile ab. Für 7C-E sollten diese nicht dupliziert, sondern durch die sechs obigen vertragsbezogenen Szenarien ersetzt beziehungsweise gezielt konsolidiert werden.