Update client overview and architecture

2026-04-17 14:45:45 +02:00
parent 98f4c1aa9f
commit 91708b5ae1
1 changed files with 137 additions and 22 deletions
@@ -2,7 +2,7 @@

 ## Überblick

-Medizinisches Diktiersystem für Ärzte. Aufnahmen werden per Pixel Watch erstellt, automatisch transkribiert, durch ein LLM aufbereitet und über ein schlichtes Webinterface abgerufen. Das System unterstützt mehrere Ärzte mit vollständig getrennten Daten.
+Medizinisches Diktiersystem für Ärzte. Aufnahmen werden per Pixel Watch (primäres Erfassungsgerät) oder weiteren Clients (Android-Handy, künftig optional Linux-/Windows-Desktop, iOS) erstellt, automatisch transkribiert, durch ein LLM aufbereitet und über ein schlichtes Webinterface abgerufen. Alle Clients — einschließlich Browser, Watch und jedes native App — sprechen dieselbe Server-HTTP-Schnittstelle; ihre Rolle ergibt sich allein daraus, *welchen Teil* der API sie nutzen. Das System unterstützt mehrere Ärzte mit vollständig getrennten Daten.

 **Datenphilosophie:** Das System ist kein Langzeitspeicher. Daten sollen so schnell wie möglich durch die Pipeline fließen und nach Übernahme ins Praxissystem vom Arzt zum Entfernen markiert werden. Je weniger Daten in der Pipeline verbleiben, desto besser. Die Watch löscht Aufnahmen erst nach Server-Bestätigung — so gehen keine Daten verloren, solange die Watch funktioniert. Serverseitig besteht bewusst kein Backup-Konzept — bei Datenverlust auf dem Server vor Übernahme ins Praxissystem gehen Daten verloren. Dieses Risiko wird den Nutzern kommuniziert.

@@ -13,10 +13,19 @@ Medizinisches Diktiersystem für Ärzte. Aufnahmen werden per Pixel Watch erstel
 ## Architektur

 ```
-Pixel Watch (Wear OS)
-    │  Aufnahmen → lokales Dateisystem
-    │  Foreground Sync Service (automatisch bei Netzwerk)
-    ↓ HTTPS direkt (LTE/WiFi) oder transparent über Phone (Wear OS Proxy)
+Clients (alle sprechen dieselbe HTTPS-API)
+  ┌────────────────────────────────────────────────────────────┐
+  │ Pixel Watch (Wear OS) — primär: Aufnahme + Oneliner-Polling│
+  │ Android-Handy (geplant) — Aufnahme + optional Review       │
+  │ Browser — Review, Admin, Audio-Streaming                   │
+  │ Linux / Windows / iOS (optional, später) — dieselbe Rolle  │
+  └────────────────────────────────────────────────────────────┘
+                │
+                │  HTTPS (einheitliche Server-API, keine
+                │  geräte-spezifischen Endpoints)
+                │  Watch ohne eigene Connectivity:
+                │  transparent via Wear OS Proxy über Phone
+                ↓
 Unraid Server
    └── nginx (reverse proxy, TLS)
            ↓ lokales Netz
@@ -29,8 +38,6 @@ Ubuntu Server (RTX 3060, 12 GB VRAM)
    ├── Ollama (Gemma 3 4B, Oneliner)
    │         ↓ HTTPS
    └── externer LLM-Provider (Ionos als Default, OpenAI-API-kompatibel, austauschbar)
-
-Webinterface (Browser) → nginx → Axum (SSE für Live-Updates)
 ```

 ---
@@ -49,11 +56,60 @@ Der Zustand eines Falls wird **ausschließlich aus dem Dateisystem** abgeleitet,

 **Bewusst verzichtet** auf: retry-Budget, Failed-Kategorie mit Error-Details. Wenn ein Audio dauerhaft an Whisper scheitert, loggt der Server im Crash-Loop — das fällt sofort auf und wird manuell entfernt. Diese Kategorie wird erst eingeführt, wenn ein realer Bedarf entsteht (z.B. hochvolumiger Betrieb).

+### Client-Prinzip
+
+Clients sind flüchtige Zugriffs- und Erfassungsstellen. Der Server ist die einzige autoritative Datenquelle; jeder Client nutzt dieselbe HTTP-API, aber nur so viel davon, wie für seine Form und sein Use-Case sinnvoll ist.
+
+- **Pixel Watch (primär):** minimaler API-Ausschnitt — Upload + Oneliner-Polling. Kein Playback, kein Review, kein lokaler Archivspeicher.
+- **Android-Handy (geplant):** identische Erfassung wie die Watch; darf zusätzlich Review-Endpoints (`/web/...`) nutzen, weil Display und Eingabe das sinnvoll machen.
+- **Browser:** klassisches Review-Frontend via `/web/...` + Audio-Streaming.
+- **Linux / Windows / iOS (optional, später):** gleiche Invariante, beliebiger Funktionsumfang — Tech-Stack pro Plattform offen (z.B. Compose Multiplatform, Tauri, nativ).
+
+#### Invariante (fixiert)
+
+> **Alle Clients sprechen ausschließlich die einheitliche Server-HTTP-Schnittstelle.** Es gibt keine gerätespezifische API und keinen geräteeigenen Backchannel. Die Rolle eines Clients ergibt sich allein daraus, *welchen Teil* der API er nutzt.
+>
+> **Lokale Datenhaltung ist strikt flüchtig:** Kein Client hält mehr Daten lokal, als für den aktuellen Upload- oder Render-Vorgang nötig. Alle dauerhaften Daten leben auf dem Server.
+
+**Lackmustest für neue Features:** *„Zwingt das Feature einen Client, Daten länger lokal zu halten als für den aktuellen Upload- oder Render-Vorgang nötig?"* Wenn ja, gehört das Feature ins Web-UI / auf den Server, nicht in den Client.
+
+**Konsequenzen:**
+- Server-Code bleibt client-agnostisch: ein neuer Client-Typ erfordert keinen neuen Endpoint.
+- Clients sind austauschbar und können unterschiedlich mächtig sein (Watch = 2 Endpoints, Browser ≈ 15, Handy dazwischen).
+- Review-Funktionen sind automatisch überall konsistent — ein nativer Client kann die Web-UI als WebView einbetten und ist damit sofort synchron mit dem Browser.
+
 ---

 ## Komponenten

-### 1. Pixel Watch App (Wear OS / Kotlin)
+### 1. Clients (Erfassung + Review)
+
+Alle Clients folgen dem [Client-Prinzip](#client-prinzip): einheitliche Server-API, flüchtige lokale Datenhaltung, Rolle ergibt sich aus genutztem API-Teil.
+
+**Entwicklungs-Reihenfolge:**
+1. **Pixel Watch (primäres Entwicklungsziel, MVP-relevant)** — siehe unten.
+2. **Android-Handy** — geplant direkt nach der Watch, teilt Core-Module.
+3. **Linux / Windows / iOS** — optional, frühestens nach Handy-Abschluss; Tech-Stack pro Plattform zu entscheiden.
+
+**Gemeinsame Code-Basis (Android-Clients):**
+
+Die Watch-App und die spätere Handy-App werden als **Multi-Modul-Gradle-Projekt** aufgesetzt, sodass UI-unabhängige Business-Logik von Anfang an in geteilten Modulen liegt. Diese Struktur ist **nicht optional** — sie wird bereits beim Bau der Watch-App eingehalten, damit die Handy-App später ohne Refactoring andocken kann.
+
+```
+doctate-android/
+├── :core-domain    ← case_id, Modelle, State-Machine (reines Kotlin/JVM)
+├── :core-audio     ← MediaRecorder-Wrapper, Bluetooth-Headset-Routing
+├── :core-sync      ← Queue, WorkManager-Jobs, Retry-Logik
+├── :core-http      ← API-Client, API-Key-Auth, Endpoints
+├── :core-storage   ← Marker-Dateien, Room/DataStore, Lazy Cleanup
+│
+├── :app-wear       ← Watch-UI (Compose for Wear OS)
+└── :app-mobile     ← Handy-UI (Compose Material 3) — später
+```
+
+UI-unabhängige Tests laufen auf der JVM (keine Emulator-Runtime). Importe von `android.*`/`androidx.compose.*` sind in `:core-*` strukturell verboten — Verstöße schlagen beim Kompilieren fehl.
+
+#### 1a. Pixel Watch App (Wear OS / Kotlin) — primäres Entwicklungsziel

 **Funktion:**
 - Audioaufnahme direkt auf der Watch (MediaRecorder, AAC/m4a)
@@ -63,7 +119,8 @@ Der Zustand eines Falls wird **ausschließlich aus dem Dateisystem** abgeleitet,
 - Aufnahmen persistent ins lokale Dateisystem (überlebt Neustarts, Akku leer)
 - Nach Aufnahme: Stop → direkt in Sync-Queue, Korrekturen per Folge-Diktat
 - Vollautomatischer Sync im Hintergrund (Foreground Service)
- Kein eigener Code auf dem Phone nötig
+- Kein Review, kein Playback, kein Archiv — konsequent nach Client-Prinzip
+- Kein eigener Code auf dem Phone nötig (Wear OS Network Proxy tunnelt transparent, wenn Watch keine eigene Connectivity hat)

 **Sync-Service (Foreground Service):**
 - Läuft permanent im Hintergrund, überlebt Doze-Modus
@@ -225,10 +282,34 @@ GET /api/oneliner/{case_id}

 ---

-**Sicherheit Watch:**
+**Sicherheit Clients (API-Key-Auth für `/api/...`):**
 - API-Key pro Arzt im HTTPS-Header
 - Server mappt API-Key → Arzt-Identität (bestimmt Speicherpfad `/data/{arzt}/`)
- Einmalig auf der Watch konfiguriert
+- Einmalig pro Client-Gerät konfiguriert (Watch und Handy verwenden denselben Key pro Arzt; verschiedene Geräte desselben Arztes teilen sich den Key)
+
+---
+
+#### 1b. Android-Handy-App — sekundäres Erfassungsgerät (geplant)
+
+Wird nach Abschluss der Watch-App gebaut, andockt an dieselben `:core-*`-Module. Funktional-Set in zwei Blöcken:
+
+**Erfassungs-Features (identisch zur Watch):**
+- Audioaufnahme, case_id-Verwaltung, Marker-Dateien, Sync-Queue, ACK-Protokoll, Oneliner-Polling, exponentieller Backoff, Lazy Cleanup — nichts davon wird neu geschrieben, alles kommt aus `:core-*`.
+- UI ist eigenständig (Compose Material 3, Bottom-Nav, größeres Display), folgt aber demselben „flüchtiges Erfassungsgerät"-Ansatz.
+
+**Review-Features (nur Handy, nutzen bestehende Web-Endpoints):**
+- Zugriff auf `/web/cases`, `/web/cases/{case_id}`, `/web/cases/{case_id}/document`, `/web/audio/{user}/{case_id}/{filename}` etc.
+- **Keine neuen Server-APIs nötig** — das Handy ist aus Server-Sicht ein weiterer Web-Client.
+- Erste Ausbaustufe kann als **WebView auf `/web/...`** umgesetzt werden (kein doppelter UI-Code, automatisch synchron zum Browser-UI); spätere Ausbaustufen dürfen selektiv Teile nativ ersetzen.
+
+**Invariante bleibt gewahrt:** Das Handy zeigt mehr als die Watch, hält aber keinen lokalen Archiv-Cache — Review-Daten werden on-demand vom Server gerendert.
+
+**Data Layer Sync (optional, später):**
+Wenn Watch und Handy gekoppelt sind (klassisches Wear-OS-Pairing), *könnten* beide Geräte die heutige Fallliste via `DataClient` (Wear OS Data Layer API) replizieren — nur Marker-Dateien, keine Audios. Das ist eine reine UX-Verbesserung (beide Geräte sehen denselben Fall), nicht MVP-relevant und wird erst nach Handy-App-Grundfunktion evaluiert.
+
+#### 1c. Weitere Plattformen (Linux / Windows / iOS) — optional, Ausblick
+
+Wegen der fixierten Invariante ist jeder weitere Client lediglich „ein weiterer HTTP-Client". Tech-Stack ist pro Plattform offen — denkbare Optionen: **Compose Multiplatform** (Code-Sharing über Android hinaus), **Tauri + Rust** (Desktop, kleine Binaries, teilt ggf. Logik mit dem Server), **nativ** (SwiftUI für iOS). Entscheidung erst nach Handy-App-Erfahrung.

 ---

@@ -239,7 +320,7 @@ Axum ist der zentrale Koordinator. Er empfängt Uploads, startet die sequentiell
 **Endpunkte (Ist-Stand):**

 ```
-# Watch API
+# Erfassungs-API (API-Key-Auth; Watch, Handy, künftige Erfassungs-Clients)
 POST /api/upload                              → Aufnahme empfangen, ACK zurück
 GET  /api/health                              → Liveness-Probe für Deployments
 GET  /api/debug/whoami                        → API-Key → slug (Entwicklungshilfe)
@@ -264,7 +345,7 @@ GET  /web/audio/{user}/{case_id}/{filename}   → Audio-Streaming (Cookie-Auth;
 GET  /web/                                    → Admin-Übersicht (später auf role="admin" eingrenzen)
 ```

-**Geplant, noch nicht implementiert:** `GET /api/oneliner/{case_id}` (Watch-Polling), `GET /web/events` (SSE), Preset- und Undo-Endpoints für Dokument-Versionen. Siehe Phase 4 und Watch-API-Pläne weiter unten.
+**Geplant, noch nicht implementiert:** `GET /api/oneliner/{case_id}` (Client-Polling, genutzt von Watch und Handy), `GET /web/events` (SSE), Preset- und Undo-Endpoints für Dokument-Versionen. Siehe Phase 4 und Client-Pläne weiter unten.

 **Kein `{arzt}` in URLs (IDOR-Prävention):**
 Die Arzt-Identität wird ausschließlich aus dem Session-Cookie abgeleitet, nie aus der URL. Ein Axum-Extractor (`AuthenticatedArzt`) liest das Session-Token, schlägt den zugehörigen Arzt nach und gibt ihn als typisierte Struct zurück. Alle `/web/`-Handler erhalten den Arzt nur über diesen Extractor — der Dateisystempfad `/data/{arzt}/` wird serverseitig aus der Session konstruiert. Dadurch kann ein eingeloggter Arzt prinzipbedingt nicht auf Daten eines anderen Arztes zugreifen, selbst wenn er URLs manuell ändert. `case_id` wird zusätzlich als UUIDv4 validiert (`uuid::Uuid::parse_str`), um Path-Traversal über manipulierte IDs auszuschließen.
@@ -729,7 +810,8 @@ Wichtig: LLM-Antworten werden **nicht** geloggt (potenziell patientenbezogene Da

 | Schicht | Technologie |
 |---|---|
-| Watch App | Kotlin, Jetpack Compose for Wear OS |
+| Android-Clients (Watch primär, Handy geplant) | Kotlin, Multi-Modul-Gradle. UI: Compose for Wear OS (`:app-wear`) bzw. Jetpack Compose Material 3 (`:app-mobile`). Geteilte Core-Module (`:core-*`) sind UI-unabhängig und JVM-testbar. |
+| Weitere Clients (Linux/Windows/iOS, optional) | Stack offen — Kandidaten: Compose Multiplatform, Tauri + Rust, nativ (SwiftUI). Entscheidung nach Handy-App-Erfahrung. |
 | Server | Rust (edition 2024), Axum 0.8, askama, reqwest, tracing, `strsim` + `spellbook` (Gazetteer); SSE für Live-Updates ist Phase-4-TODO |
 | STT | faster-whisper (CTranslate2, large-v3, eigener Docker Container mit HTTP-API) |
 | Preprocessing | Ollama, Gemma 3 4B (keep_alive: 0 für VRAM-Freigabe nach Request) |
@@ -798,9 +880,10 @@ wiremock = "0.6"

 | Gerät | Rolle |
 |---|---|
-| Pixel Watch 2 oder 3 (LTE empfohlen) | Aufnahme + Upload |
+| Pixel Watch 2 oder 3 (LTE empfohlen) | Primäres Erfassungsgerät (Aufnahme + Upload + Oneliner-Polling) |
 | Bluetooth-Headset (optional) | Bessere Aufnahmequalität |
-| Android Phone | Wear OS Companion (kein eigener Code) |
+| Android Phone | Sekundäres Erfassungsgerät (eigene App, geplant — Erfassung + Review) **und** Wear OS Companion. Für LTE-lose Watches bleibt der Wear-OS-Network-Proxy als Framework-Mechanismus erhalten — kein eigener Code auf der Companion-Ebene nötig. |
+| Linux-/Windows-Desktop, iOS-Gerät (optional, später) | Weitere Client-Plattformen — sprechen dieselbe Server-API wie alle anderen Clients |
 | Unraid Server | nginx reverse proxy, TLS-Terminierung |
 | Ubuntu Server (RTX 3060, 12 GB VRAM) | Docker: Axum (kein GPU), faster-whisper (GPU), Ollama (GPU) |

@@ -887,17 +970,26 @@ wiremock = "0.6"
 - [x] `hash-password` CLI (`cargo run --bin hash-password`) — erzeugt bcrypt-Hashes für `users.toml`, mit `toml_edit`-Schreibzugriff ohne Kommentarverlust.
 - [ ] Zugriffsschutz: `GET /web/` und Admin-Audio auf `role = "admin"` einschränken (aktuell noch offen für alle).

-### Phase 5 — Watch App
+### Phase 5 — Clients (Erfassung + Review)
+
+**Reihenfolge:** 5a (gemeinsame Code-Basis) → 5b (Watch, primäres Entwicklungsziel) → 5c (Handy) → 5d (optional: Data Layer Sync) → 5e (Ausblick: weitere Plattformen).

 **Hinweis:** Ein früher Proof-of-Concept (minimale Aufnahme + Upload auf echter Pixel Watch) sollte parallel zu Phase 2–3 stattfinden, um Wear-OS-spezifische Einschränkungen (Doze-Mode, Foreground-Service-Limits, Battery-Optimization) frühzeitig aufzudecken.

-**Stand-in, solange keine Hardware:** `scripts/dictate.sh` simuliert den Watch-Flow via ffmpeg-PulseAudio-Aufnahme + Upload gegen den laufenden Server (Modi: neuer Fall / aktuellen Fall fortsetzen / refresh). State in `/tmp/doctate-current-case`. So lassen sich Transkription und Oneliner ohne Watch testen.
+**Stand-in, solange keine Hardware:** `scripts/dictate.sh` simuliert den Client-Flow via ffmpeg-PulseAudio-Aufnahme + Upload gegen den laufenden Server (Modi: neuer Fall / aktuellen Fall fortsetzen / refresh). State in `/tmp/doctate-current-case`. So lassen sich Transkription und Oneliner ohne native Clients testen.

- [ ] Wear OS Projekt in Android Studio
+#### 5a — Gemeinsame Code-Basis (vor jeder UI-Arbeit)
+- [ ] Gradle-Multi-Modul-Projekt aufsetzen (`:core-domain`, `:core-audio`, `:core-sync`, `:core-http`, `:core-storage`, `:app-wear`, `:app-mobile` als Platzhalter)
+- [ ] `:core-*`-Module strikt UI-frei halten (kein Import von `android.*`/`androidx.compose.*` erlaubt — Build schlägt sonst fehl)
+- [ ] JVM-Unit-Tests für `:core-domain` und `:core-sync` (case_id-Generierung, ACK-Zustandsautomat, Backoff-Kurve)
+- [ ] API-Client (`:core-http`): Endpoints typisiert, API-Key im Header, Reqwest-Äquivalent (Ktor oder OkHttp)
+
+#### 5b — Pixel Watch App (primäres Entwicklungsziel)
+- [ ] Wear OS Projekt in Android Studio (`:app-wear`)
 - [ ] Jetpack Compose UI (ein Screen pro Eintrag, fullscreen, Swipe-Navigation)
 - [ ] Vertikale Fallliste (Neu ganz oben, heutige Fälle darunter)
 - [ ] Nach Stop: Screen bleibt auf aktuellem Fall (→ "Fortsetzen" direkt sichtbar)
- [ ] MediaRecorder (AAC/m4a)
+- [ ] MediaRecorder-Integration via `:core-audio`
 - [ ] Bluetooth-Headset Erkennung + Indikator
 - [ ] case_id (UUIDv4) Generierung: Neu → neue case_id, Fortsetzen → bestehende
 - [ ] Persistente Speicherung im lokalen Dateisystem (UTC-Timestamps in Dateinamen)
@@ -914,6 +1006,26 @@ wiremock = "0.6"
 - [ ] Oneliner-Polling (alle paar Sekunden für den sichtbaren Fall, bis Oneliner empfangen)
 - [ ] Emulator-Tests + Pixel Watch Hardware-Test

+#### 5c — Android-Handy-App (nach Watch-Abschluss)
+- [ ] `:app-mobile`-Modul auf bestehende `:core-*`-Basis aufsetzen
+- [ ] Erfassungs-UI (Compose Material 3): Fallliste, Neu/Fortsetzen, Recording-Screen — funktional-identisch zur Watch, aber an Handy-Ergonomie angepasst
+- [ ] Alle Erfassungs-Features via `:core-*` (keine Duplizierung von Sync/Queue/ACK/Marker-Logik)
+- [ ] Review-UI: Erste Ausbaustufe als WebView auf `/web/...`-Endpoints (schneller, kein doppelter Code, automatisch synchron zum Browser-UI)
+- [ ] Auth-Integration für `/web/...` (siehe „Offene Entscheidungen": Handy-App-Auth)
+- [ ] **Invariante prüfen:** kein lokaler Archiv-Cache für Transkripte/Audios außerhalb des aktiven Upload-Vorgangs
+- [ ] End-to-End-Test: Erfassung Handy → Server → Review in Handy-App
+
+#### 5d — Data Layer Sync zwischen Watch und Handy (optional, später)
+- [ ] `DataClient` (Wear OS Data Layer API) in `:core-storage` einbetten
+- [ ] Nur Marker-Dateien syncen (keine Audios — Audio-Upload bleibt beim Aufnahmegerät)
+- [ ] Tombstone-Strategie für „gestern gelöscht" (TTL ~25 h, um Auferstehung zu vermeiden)
+- [ ] Test: Watch + Handy offline → beide nehmen auf → bei erneuter Bluetooth-Verbindung gleicht sich die Liste ab
+
+#### 5e — Weitere Plattformen (Ausblick, nicht MVP)
+- [ ] Tech-Stack-Entscheidung für Linux-/Windows-Desktop (Compose Multiplatform vs. Tauri vs. nativ)
+- [ ] iOS-App (SwiftUI oder Compose Multiplatform)
+- [ ] Invariante gilt weiterhin: jeder neue Client = weiterer HTTP-Client, kein Server-Code-Ausbau nötig
+
 ### Phase 6 — Integration & Testing
 - [ ] End-to-End Test (Watch → Server → Webinterface)
 - [ ] SSE Live-Updates testen
@@ -961,18 +1073,21 @@ wiremock = "0.6"
 | Sicheres Löschen | Reicht rm oder Overwrite nötig? — offen |
 | faster-whisper HTTP-API | **Entschieden:** eigener FastAPI-Wrapper (`whisper/`). Grund siehe Phase 2b.5 / Abweichungen. |
 | Recovery-UI (Webinterface) | Dedizierte Ansicht für verspätet eingetroffene Aufnahmen (Anhören / Ins Dokument / Verwerfen) — optional, Bedarf im Echtbetrieb evaluieren |
+| Handy-App-Authentifizierung | Aktuell zwei Mechanismen: API-Key für `/api/...` (Erfassung), Cookie-Session für `/web/...` (Review). Varianten für die Handy-App: (a) beide parallel, (b) API-Key für alles vereinheitlichen (Cookie-Pfad erweitern oder Token-basiert), (c) WebView mit Cookie-Login für Review + API-Key für Upload. Entscheidung zu Beginn von Phase 5c. |
+| Weitere Client-Plattformen (Linux/Windows/iOS) | Tech-Stack-Kandidaten: Compose Multiplatform (Code-Sharing über Android hinaus), Tauri + Rust (Desktop, kleine Binaries), nativ (SwiftUI). Entscheidung nach Handy-App-Erfahrung; Server-seitig keine Änderungen nötig (Client-Invariante). |

 ---

 ## Nicht im Scope (vorerst)

- iOS / Apple Watch
- Mobile Client-App (Tauri/React)
+- Apple Watch (iOS-App für iPhone/iPad ist in Phase 5e als optionaler Ausblick enthalten)
 - Praxissoftware-Integration (Medical Office / GDT)
 - Multi-Tenant / Cloud-Hosting
 - Echtzeit-Transkription
 - Automatische Patientenzuordnung

+**Hinweis zu Client-Plattformen:** Android-Handy, Linux-/Windows-Desktop und iOS sind nach dem [Client-Prinzip](#client-prinzip) explizit *erlaubt* — ihre Umsetzung ist in Phase 5c bzw. 5e geplant, aber zeitlich nach der Watch-App priorisiert.
+
 ---

 ## Abweichungen von der Originalplanung