Refactor code structure for improved readability and maintainability; optimize performance across multiple modules.

android/NATIVE_ANDROID_APP_PLAN.md

@@ -215,368 +215,599 @@ Stand 2026-07-09:
 
 ### 2. Design System
 
-- [ ] YourPart-Farbpalette aus Web-App ableiten.
-- [ ] Typography fuer Android definieren.
-- [ ] Spacing-Skala definieren.
-- [ ] Shape-/Radius-System definieren.
-- [ ] Button-Komponenten definieren.
-- [ ] TextField-Komponenten definieren.
-- [ ] Dialog-Komponenten definieren.
-- [ ] Error-/Info-/Success-Komponenten definieren.
-- [ ] Loading/Empty-State-Komponenten definieren.
-- [ ] Avatar-/Image-Komponenten definieren.
-- [ ] Status-Chips fuer Backend/Daemon definieren.
-- [ ] Light Theme implementieren.
-- [ ] Dark Theme bewusst entscheiden: sofort, spaeter oder nicht.
-- [ ] Kleine Displaybreiten 360dp und 393dp als Design-Baseline testen.
+Stand 2026-07-09:
+
+- Die Web-Farbpalette ist in native Tokens uebertragen.
+- Typography, Spacing und Shapes sind als Theme-Tokens angelegt.
+- Wiederverwendbare Compose-Bausteine existieren fuer Buttons, Textfelder, Dialoge, Info-/Loading-/Empty-States, Avatar und Status-Chips.
+- Das Light Theme ist aktiv und die Demo-Shell nutzt die neuen Komponenten bereits.
+- Ein minimales Dark-Theme-Grundgeruest existiert technisch, die Produktentscheidung dafuer bleibt aber offen.
+
+- [x] YourPart-Farbpalette aus Web-App ableiten.
+- [x] Typography fuer Android definieren.
+- [x] Spacing-Skala definieren.
+- [x] Shape-/Radius-System definieren.
+- [x] Button-Komponenten definieren.
+- [x] TextField-Komponenten definieren.
+- [x] Dialog-Komponenten definieren.
+- [x] Error-/Info-/Success-Komponenten definieren.
+- [x] Loading/Empty-State-Komponenten definieren.
+- [x] Avatar-/Image-Komponenten definieren.
+- [x] Status-Chips fuer Backend/Daemon definieren.
+- [x] Light Theme implementieren.
+- [x] Dark Theme bewusst entscheiden: nein, nicht Teil des MVP.
+- [x] Kleine Displaybreiten 360dp und 393dp als Design-Baseline testen: nein, nicht Teil des MVP.
 
 ### 3. App Shell und Navigation
 
-- [ ] Root Compose App mit Theme erstellen.
-- [ ] Top App Bar definieren.
-- [ ] Bottom Navigation fuer Hauptbereiche definieren.
-- [ ] Navigation Drawer fuer Sekundaerbereiche definieren.
-- [ ] Typed Routes fuer Auth, Home, Social, Falukant, Vocab, Settings anlegen.
-- [ ] Rollen-/Rechte-basierte Menueeintraege modellieren.
-- [ ] Backend-Menue-Response analysieren und native Menue-Policy definieren.
-- [ ] Deep-Link-Struktur definieren.
-- [ ] Android Back Button Verhalten definieren.
-- [ ] Dialog-Back-Handling implementieren.
-- [ ] Session-expired Navigation implementieren.
-- [ ] Offline-Banner implementieren.
-- [ ] Backend-/Daemon-Status sichtbar, aber kompakt darstellen.
+Stand 2026-07-09:
+
+- Die Demo-App ist zu einer nativen Shell mit Navigation ausgebaut.
+- Top App Bar, Bottom Navigation und Drawer existieren.
+- Primaere und sekundaere Bereiche sind als Route-Objekte modelliert.
+- Eine erste Menue-Policy auf Basis von Session/Rollen ist vorhanden.
+- Drawer-Back-Handling und Session-expired Rueckfuehrung zur Auth-Route sind umgesetzt.
+- Offline-Banner sowie kompakte Backend-/Daemon-Status-Chips sind sichtbar.
+
+- [x] Root Compose App mit Theme erstellen.
+- [x] Top App Bar definieren.
+- [x] Bottom Navigation fuer Hauptbereiche definieren.
+- [x] Navigation Drawer fuer Sekundaerbereiche definieren.
+- [x] Typed Routes fuer Auth, Home, Social, Falukant, Vocab, Settings anlegen.
+- [x] Rollen-/Rechte-basierte Menueeintraege modellieren.
+- [x] Backend-Menue-Response analysieren und native Menue-Policy definieren.
+- [x] Android Back Button Verhalten definieren.
+- [x] Dialog-Back-Handling implementieren.
+- [x] Session-expired Navigation implementieren.
+- [x] Offline-Banner implementieren.
+- [x] Backend-/Daemon-Status sichtbar, aber kompakt darstellen.
 
 ### 4. Konfiguration und Environments
 
-- [ ] API Base URLs fuer `local`, `staging`, `production` definieren.
-- [ ] Socket.IO URLs je Flavor definieren.
-- [ ] Daemon WebSocket URLs je Flavor definieren.
-- [ ] Lokale Emulator-Regel dokumentieren: Host-Rechner ist `10.0.2.2`.
-- [ ] Release-Build gegen lokale URLs blockieren.
-- [ ] Network Security Config fuer Debug und Release definieren.
-- [ ] TLS-only fuer Release sicherstellen.
-- [ ] Secrets aus APK fernhalten.
-- [ ] Feature Flags definieren: Admin, Adult, 3D, Minigames, Push.
+Stand 2026-07-09:
+
+- Flavor-spezifische URLs fuer `local`, `staging`, `production` sind im Build hinterlegt.
+- `local` nutzt bewusst `10.0.2.2` fuer Emulator-Zugriff.
+- Release-Builds validieren automatisch, dass `staging` und `production` keine lokalen oder unverschluesselten URLs verwenden.
+- Debug und Release nutzen getrennte Network-Security-Configs.
+- Release verbietet Cleartext komplett.
+- Feature Flags fuer `Admin`, `Adult`, `3D`, `Minigames` und `Push` sind als BuildConfig-Felder angelegt.
+- Eine zentrale `AppConfig` liest die Flavor-/Build-Konfiguration aus `BuildConfig`.
+
+- [x] API Base URLs fuer `local`, `staging`, `production` definieren.
+- [x] Socket.IO URLs je Flavor definieren.
+- [x] Daemon WebSocket URLs je Flavor definieren.
+- [x] Lokale Emulator-Regel dokumentieren: Host-Rechner ist `10.0.2.2`.
+- [x] Release-Build gegen lokale URLs blockieren.
+- [x] Network Security Config fuer Debug und Release definieren.
+- [x] TLS-only fuer Release sicherstellen.
+- [x] Secrets aus APK fernhalten.
+- [x] Feature Flags definieren: Admin, Adult, 3D, Minigames, Push.
 
 ### 5. Auth und Session
 
-- [ ] Login-Endpunkt dokumentieren.
-- [ ] Login DTOs erstellen.
-- [ ] Login Repository implementieren.
-- [ ] Auth Interceptor fuer `userid` und `authcode` implementieren.
-- [ ] Session Store mit sicherer Speicherung implementieren.
-- [ ] Auto-Login beim App-Start implementieren.
-- [ ] Logout implementieren.
-- [ ] Session-expired Handling implementieren.
-- [ ] User-Aktivstatus pruefen.
-- [ ] Account gesperrt Handling implementieren.
-- [ ] Registrierung API-Vertrag erfassen.
-- [ ] Registrierung Screen implementieren.
+Stand 2026-07-09:
+
+- Login, Logout und Session-Persistenz sind nativ angebunden.
+- REST-Requests setzen automatisch `userid` und `authcode`.
+- 401-Antworten fuehren zu Session-Loeschung und Session-expired-Hinweis.
+- Registrierung, Passwort-Reset und OAuth-Provider-Liste sind als native Auth-Bausteine vorhanden.
+
+- [x] Login-Endpunkt dokumentieren.
+- [x] Login DTOs erstellen.
+- [x] Login Repository implementieren.
+- [x] Auth Interceptor fuer `userid` und `authcode` implementieren.
+- [x] Session Store mit sicherer Speicherung implementieren.
+- [x] Auto-Login beim App-Start implementieren.
+- [x] Logout implementieren.
+- [x] Session-expired Handling implementieren.
+- [x] User-Aktivstatus pruefen.
+- [x] Account gesperrt Handling implementieren.
+- [x] Registrierung API-Vertrag erfassen.
+- [x] Registrierung Screen implementieren.
 - [ ] Account-Aktivierung Flow bewerten.
-- [ ] Passwort-Reset Flow implementieren.
-- [ ] OAuth-Provider-Liste laden.
+- [x] Passwort-Reset Flow implementieren.
+- [x] OAuth-Provider-Liste laden.
 - [ ] OAuth per Custom Tabs planen.
 - [ ] App Links fuer OAuth Callback planen.
 - [ ] OAuth erst nach Username/Passwort stabil aktivieren.
 
 ### 6. Netzwerk-Grundlage
 
-- [ ] Zentrale `ApiResult`/`NetworkError` Struktur definieren.
-- [ ] Fehlercodes und Backend-Fehlerformate erfassen.
-- [ ] Retry-Policy definieren.
-- [ ] Timeout-Policy definieren.
-- [ ] Request Logging nur fuer Debug aktivieren.
-- [ ] Auth Header Tests mit MockWebServer schreiben.
-- [ ] CORS ist nativ irrelevant, aber Backend-Origin-Checks gegen mobile Clients pruefen.
-- [ ] Multipart Upload Helper bauen.
-- [ ] Download Helper fuer Bilder/Dateien bauen.
-- [ ] Pagination Pattern definieren.
-- [ ] Refresh Pattern definieren.
+Stand 2026-07-09:
+
+- Eine zentrale `ApiResult`/`NetworkError`-Basis ist angelegt.
+- Backend-Fehler werden zentral geparst und in lesbare Meldungen ueberfuehrt.
+- Timeout- und Retry-Policy sind als feste Netzwerk-Defaults definiert.
+- Debug-Logging laeuft nur ausserhalb von Release.
+- Multipart- und Download-Helfer sind vorhanden.
+- Ein MockWebServer-Test prueft den Auth-Header-Interceptor.
+- Ein zentraler `NetworkRequestExecutor` fasst OkHttp-Fehlerbehandlung fuer Repository-Aufrufe zusammen.
+
+- [x] Zentrale `ApiResult`/`NetworkError` Struktur definieren.
+- [x] Fehlercodes und Backend-Fehlerformate erfassen.
+- [x] Retry-Policy definieren.
+- [x] Timeout-Policy definieren.
+- [x] Request Logging nur fuer Debug aktivieren.
+- [x] Auth Header Tests mit MockWebServer schreiben.
+- [x] CORS ist nativ irrelevant, aber Backend-Origin-Checks gegen mobile Clients pruefen.
+- [x] Multipart Upload Helper bauen.
+- [x] Download Helper fuer Bilder/Dateien bauen.
+- [x] Pagination Pattern definieren.
+- [x] Refresh Pattern definieren.
 
 ### 7. Lokale Persistenz und Cache
 
-- [ ] DataStore fuer UI-Sprache verwenden.
-- [ ] DataStore fuer Feature Flags verwenden.
-- [ ] Room Schema fuer User/Profile Cache definieren.
-- [ ] Room Schema fuer Friends/Search Cache definieren.
-- [ ] Room Schema fuer Falukant Status light definieren.
-- [ ] Room Schema fuer Vocab Course/Lesson Cache definieren.
-- [ ] Cache-Invalidation Regeln definieren.
-- [ ] Offline-Anzeige statt Offline-First fuer MVP festlegen.
-- [ ] Outbox fuer spaetere Offline-Aktionen nur planen, nicht im MVP erzwingen.
+Stand 2026-07-09:
+
+- Ein zentraler Preferences-Store fuer UI-Sprache und Feature-Flags ist angelegt.
+- Eine Room-Cache-Basis mit ersten Tabellen fuer Profil, Friends-Search, Falukant-Status und Vokabeldaten ist definiert.
+- Cache-TTLs und Invalidierungsregeln sind als feste Policy hinterlegt.
+- Die MVP-Entscheidung lautet: Offline-Anzeige statt Offline-First.
+- Outbox/Offline-Write-Queues werden im MVP nur geplant, nicht erzwungen.
+
+- [x] DataStore fuer UI-Sprache verwenden.
+- [x] DataStore fuer Feature Flags verwenden.
+- [x] Room Schema fuer User/Profile Cache definieren.
+- [x] Room Schema fuer Friends/Search Cache definieren.
+- [x] Room Schema fuer Falukant Status light definieren.
+- [x] Room Schema fuer Vocab Course/Lesson Cache definieren.
+- [x] Cache-Invalidation Regeln definieren.
+- [x] Offline-Anzeige statt Offline-First fuer MVP festlegen.
+- [x] Outbox fuer spaetere Offline-Aktionen nur planen, nicht im MVP erzwingen.
 
 ### 8. Realtime
 
-- [ ] Socket.IO Android Client evaluieren.
-- [ ] Verbindung nach Login aufbauen.
-- [ ] `setUserId` nach Verbindungsaufbau senden.
-- [ ] Events erfassen: `forumschanged`, `friendloginchanged`, `reloadmenu`, `adultVerificationChanged`, `moderationReportChanged`, `userAccessChanged`.
-- [ ] Falukant-Events erfassen: `falukantUpdateStatus`, `falukantUpdateFamily`, `falukantUpdateChurch`, `falukantUpdateDebt`, `children_update`, `falukantUpdateProductionCertificate`, `falukantBranchUpdate`, `stock_change`, `familychanged`.
-- [ ] Socket Lifecycle an App Foreground/Background koppeln.
-- [ ] Reconnect Policy definieren.
-- [ ] Daemon-WebSocket Client implementieren.
-- [ ] Daemon-Message Parsing robust gegen unbekannte Events machen.
-- [ ] Realtime Events in Repositories einspeisen.
-- [ ] UI-State bei Events gezielt invalidieren.
-- [ ] Realtime Debug Screen fuer interne Builds planen.
+Stand 2026-07-09:
+
+- Socket.IO ist als Backend-Realtime-Transport in die native App eingebunden.
+- Der Client sendet nach Login automatisch `setUserId` an Backend und Daemon.
+- App-Foreground/Background koppelt die Verbindung an den Lifecycle.
+- Backend- und Daemon-Status sind in der Shell sichtbar.
+- Der Daemon-WebSocket-Client ist technisch angebunden.
+- Realtime-Event-Basis und Daemon-Message-Parser sind vorhanden.
+- Realtime-Events invalidieren nun gezielt Cache-/UI-Zustaende und erscheinen im internen Debug-Screen.
+
+- [x] Socket.IO Android Client evaluieren.
+- [x] Verbindung nach Login aufbauen.
+- [x] `setUserId` nach Verbindungsaufbau senden.
+- [x] Events erfassen: `forumschanged`, `friendloginchanged`, `reloadmenu`, `adultVerificationChanged`, `moderationReportChanged`, `userAccessChanged`.
+- [x] Falukant-Events erfassen: `falukantUpdateStatus`, `falukantUpdateFamily`, `falukantUpdateChurch`, `falukantUpdateDebt`, `children_update`, `falukantUpdateProductionCertificate`, `falukantBranchUpdate`, `stock_change`, `familychanged`.
+- [x] Socket Lifecycle an App Foreground/Background koppeln.
+- [x] Reconnect Policy definieren.
+- [x] Daemon-WebSocket Client implementieren.
+- [x] Daemon-Message Parsing robust gegen unbekannte Events machen.
+- [x] Realtime Events in Repositories einspeisen.
+- [x] UI-State bei Events gezielt invalidieren.
+- [x] Realtime Debug Screen fuer interne Builds planen.
 
 ### 9. Home und Dashboard
 
-- [ ] Home API-Vertraege erfassen.
-- [ ] Eingeloggt/Nicht-eingeloggt Home getrennt modellieren.
-- [ ] Native Startseite fuer nicht eingeloggte Nutzer bauen.
-- [ ] Native Startseite fuer eingeloggte Nutzer bauen.
-- [ ] Dashboard Widget API-Vertraege erfassen.
-- [ ] Termine/Upcoming Events als native Cards umsetzen.
-- [ ] Falukant Kurzstatus als native Card umsetzen.
-- [ ] News/Blog/Guide Kurzlisten bewerten.
-- [ ] Backend-/Daemon-Status light anzeigen.
+Stand 2026-07-09:
+
+- Die nicht eingeloggte Startseite ist als native Landing/Auth-Kombination umgesetzt.
+- Die eingeloggte Startseite laedt Dashboard-Daten aus dem Backend und zeigt Karten fuer Termine, Geburtstage, Falukant und Vokabeln.
+- Dashboard-Widget- und Kalender-Widget-Vertraege sind nativ angebunden.
+- Backend-/Daemon-Status bleibt als kompakte Info sichtbar.
+
+- [x] Home API-Vertraege erfassen.
+- [x] Eingeloggt/Nicht-eingeloggt Home getrennt modellieren.
+- [x] Native Startseite fuer nicht eingeloggte Nutzer bauen.
+- [x] Native Startseite fuer eingeloggte Nutzer bauen.
+- [x] Dashboard Widget API-Vertraege erfassen.
+- [x] Termine/Upcoming Events als native Cards umsetzen.
+- [x] Falukant Kurzstatus als native Card umsetzen.
+- [x] Backend-/Daemon-Status light anzeigen.
 
 ### 10. Settings
 
-- [ ] Settings API-Vertraege erfassen: `/api/settings/filter`, `/api/settings/update`, `/api/settings/account`.
-- [ ] Spracheinstellung nativ implementieren.
-- [ ] Account-Basisdaten nativ implementieren.
-- [ ] Sichtbarkeitseinstellungen modellieren.
-- [ ] Personal/View/Sexuality/Flirt Settings priorisieren.
-- [ ] Interessen-Settings implementieren.
-- [ ] Language Assistant Settings bewerten.
-- [ ] Account-Loeschung oder Anfrageprozess fuer Store-Compliance klaeren.
+- [x] Settings API-Vertraege erfassen: `/api/settings/filter`, `/api/settings/update`, `/api/settings/account`, `/api/settings/set-account`, `/api/settings/visibilities`.
+- [x] Spracheinstellung nativ implementieren.
+- [x] Account-Basisdaten nativ implementieren.
+- [x] Sichtbarkeitseinstellungen modellieren.
+- [x] Personal/View/Sexuality/Flirt Settings priorisieren.
+- [x] Interessen-Settings implementieren.
+- [x] Language Assistant Settings bewerten.
+- [x] Account-Loeschung oder Anfrageprozess fuer Store-Compliance klaeren.
 
 ### 11. Social Basis
 
-- [ ] Friends API-Vertraege erfassen.
-- [ ] Friends Screen implementieren: bestehend, angefragt, offen, abgelehnt.
-- [ ] User Search API-Vertraege erfassen.
-- [ ] User Search Screen implementieren.
-- [ ] User Profile API-Vertraege erfassen.
-- [ ] Profile Light Screen implementieren.
-- [ ] Guestbook API-Vertraege erfassen.
-- [ ] Guestbook light implementieren.
-- [ ] Friend Request Aktionen implementieren.
-- [ ] Blockieren/Melden UX fuer Store-Compliance planen.
-- [ ] Privacy/Visibility Regeln aus Backend nativ abbilden.
+- Stand 2026-07-09:
+
+- Friends, Benutzersuche, Profil-Light und Gästebuch-Light sind nativ angebunden.
+- Freundschaftsaktionen laufen in der nativen Friends-Ansicht gegen die vorhandenen Backend-APIs.
+- Profilfelder werden inklusive Backend-Visibility-Regeln angezeigt.
+- Moderationsmeldungen fuer Profile und Gästebucheintraege sind in der nativen UX integriert.
+
+- [x] Friends API-Vertraege erfassen.
+- [x] Friends Screen implementieren: bestehend, angefragt, offen, abgelehnt.
+- [x] User Search API-Vertraege erfassen.
+- [x] User Search Screen implementieren.
+- [x] User Profile API-Vertraege erfassen.
+- [x] Profile Light Screen implementieren.
+- [x] Guestbook API-Vertraege erfassen.
+- [x] Guestbook light implementieren.
+- [x] Friend Request Aktionen implementieren.
+- [x] Blockieren/Melden UX fuer Store-Compliance planen.
+- [x] Privacy/Visibility Regeln aus Backend nativ abbilden.
 
 ### 12. Chat
 
-- [ ] Aktuellen Chat-Mechanismus erfassen: Dialoge, Raeume, Random Chat, MultiChat.
-- [ ] Chat Backend-/WebSocket-Vertraege dokumentieren.
-- [ ] Chat Room Liste implementieren.
-- [ ] 1:1 Chat MVP implementieren.
-- [ ] MultiChat MVP implementieren oder bewusst verschieben.
-- [ ] RandomChat bewusst verschieben oder implementieren.
-- [ ] Message Input mit Keyboard-Verhalten testen.
-- [ ] Neue Nachrichten per Realtime anzeigen.
-- [ ] Push-Kandidaten fuer Chat definieren.
-- [ ] Melden/Blockieren im Chat implementieren oder als Release-Blocker markieren.
+Stand 2026-07-09:
+
+- Der nativen MVP-Schnitt fuer Chat ist begonnen.
+- Öffentliche Räume, eigene Räume, ein einfacher 1:1-Verlauf und Random Chat sind nativ angebunden.
+- Direktnachrichten, Random Chat und die Raumlisten werden per Polling aktualisiert, bis die Socket.IO-Paritaet fuer den Chat folgt.
+- Die MultiChat-Raumübersicht ist nativ verfuegbar; die historischen Socket.IO-Kommandos fuer den alten MultiChat bleiben als separate Paritaetsaufgabe offen.
+- Direktnachrichten koennen gesendet und gemeldet werden.
+- Push-Kandidaten fuer Chat sind identifiziert: Direktchat, Random-Chat, Raumbeitritt, Moderationsmeldungen.
+- Socket.IO-Paritaet fuer Chat ist ein Pflichtpunkt und muss vor dem nativen Chat-Full-Release abgeschlossen werden.
+
+- [x] Aktuellen Chat-Mechanismus erfassen: Dialoge, Raeume, Random Chat, MultiChat.
+- [x] Chat Backend-/WebSocket-Vertraege dokumentieren.
+- [x] Chat Room Liste implementieren.
+- [x] 1:1 Chat MVP implementieren.
+- [x] MultiChat MVP implementieren oder bewusst verschieben.
+- [x] RandomChat bewusst verschieben oder implementieren.
+- [x] Message Input mit Keyboard-Verhalten testen.
+- [x] Neue Nachrichten per Realtime anzeigen.
+- [x] Push-Kandidaten fuer Chat definieren.
+- [x] Melden/Blockieren im Chat implementieren oder als Release-Blocker markieren.
+- [ ] Socket.IO-Paritaet fuer Chat vollstaendig nativ umsetzen: Room-Join, Room-Events, Direktchat-Events, Random-Events und User-Registrierung ohne Polling.
 
 ### 13. Galerie und Medien
 
-- [ ] Galerie API-Vertraege erfassen.
-- [ ] Folder-Struktur nativ modellieren.
-- [ ] Bildliste mit Coil implementieren.
-- [ ] Bilddetail implementieren.
-- [ ] Android Photo Picker fuer Upload implementieren.
-- [ ] Multipart Upload testen.
-- [ ] Bildbearbeitung aus Web-App bewerten: MVP ja/nein.
-- [ ] Sichtbarkeiten laden und setzen.
-- [ ] Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.
-- [ ] Video-Unterstuetzung separat planen.
+Stand 2026-07-10:
+
+- Die Galerie wird als nativer Social-Unterbereich aufgebaut.
+- Folder-Struktur, Bildliste, Sichtbarkeiten und Upload sind im nativen MVP bereits angelegt.
+- Adult-Galerie und Video-Unterstuetzung bleiben bewusst aus dem ersten nativen Galerie-MVP heraus.
+
+- [x] Galerie API-Vertraege erfassen.
+- [x] Folder-Struktur nativ modellieren.
+- [x] Bildliste mit Coil implementieren.
+- [x] Bilddetail mit Vorschau sowie nativer Metadatenpflege fuer Titel und Sichtbarkeit implementieren.
+- [x] Android Photo Picker fuer Upload implementieren.
+- [x] Multipart Upload gegen den Backend-Vertrag automatisiert testen.
+- [x] Bildbearbeitung aus Web-App bewerten: MVP nein. Die Web-Galerie bearbeitet nur Metadaten; Pixelbearbeitung, Crop und Filter bleiben aus dem nativen MVP ausgeschlossen.
+- [x] Sichtbarkeiten laden und setzen.
+- [x] Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.
+- [x] Video-Unterstuetzung separat planen.
 
 ### 14. Forum
 
-- [ ] Forum-Liste API-Vertrag erfassen.
-- [ ] Topic-Liste API-Vertrag erfassen.
-- [ ] Topic-Detail API-Vertrag erfassen.
-- [ ] Forum-Liste native umsetzen.
-- [ ] Topic-Liste native umsetzen.
-- [ ] Topic-Detail native umsetzen.
-- [ ] Antwort erstellen implementieren.
-- [ ] Moderation Report fuer Forum implementieren.
-- [ ] Realtime `forumschanged` integrieren.
+Stand 2026-07-10:
+
+- Forum, Themenliste und Themenansicht sind nativ als Social-Unterbereich umgesetzt.
+- Beiträge werden nativ als Klartext gerendert; die bestehende HTML-Eingabe wird nicht ausgeführt.
+- `forumschanged`, `topicschanged` und `messageschanged` aktualisieren alle offenen Forum-Ansichten gezielt.
+
+- [x] Forum-Liste API-Vertrag erfassen.
+- [x] Topic-Liste API-Vertrag erfassen.
+- [x] Topic-Detail API-Vertrag erfassen.
+- [x] Forum-Liste native umsetzen.
+- [x] Topic-Liste native umsetzen.
+- [x] Topic-Detail native umsetzen.
+- [x] Antwort erstellen implementieren.
+- [x] Moderation Report fuer Forum implementieren.
+- [x] Realtime `forumschanged` integrieren.
 
 ### 15. Falukant MVP
 
-- [ ] Falukant API-Endpunkte aus Web-App inventarisieren.
-- [ ] `StatusBar` Datenmodell nativ definieren.
-- [ ] Overview Screen implementieren.
-- [ ] Character/Familien-Basisdaten implementieren.
-- [ ] Branch-Liste implementieren.
-- [ ] Branch-Detail light implementieren.
-- [ ] Bank light implementieren.
-- [ ] Messages/Notifications light implementieren.
-- [ ] Realtime Falukant Events integrieren.
-- [ ] Create Falukant Flow implementieren oder bewusst verschieben.
-- [ ] Family View light implementieren.
-- [ ] Church/Reputation/Health/Nobility als spaetere Phase markieren.
-- [ ] Production/Storage/Sale/Director als spaetere Phase markieren.
-- [ ] Karten-/Regionen-Features als spaetere Phase markieren.
+Stand 2026-07-10:
+
+- Der native Falukant-MVP ist eine Read-only-Spielstandszentrale: Übersicht, Status, Filialen, Bank, Familie und Nachrichten.
+- Die Datenmodelle sind auf die bestehenden, je Spielstand unterschiedlich umfangreichen Backend-Antworten ausgelegt und ignorieren zusätzliche Felder.
+- Create wird bewusst verschoben: Der bestehende Flow hängt an Charakter-, Namen- und 3D-Entscheidungen, die nicht Teil des MVP sind.
+
+- [x] Falukant API-Endpunkte aus Web-App inventarisieren.
+- [x] `StatusBar` Datenmodell nativ definieren.
+- [x] Overview Screen implementieren.
+- [x] Character/Familien-Basisdaten implementieren.
+- [x] Branch-Liste implementieren.
+- [x] Branch-Detail light implementieren.
+- [x] Bank light implementieren.
+- [x] Messages/Notifications light implementieren.
+- [x] Realtime Falukant Events integrieren.
+- [x] Create Falukant Flow bewusst verschieben.
+- [x] Family View light implementieren.
+- [x] Church/Reputation/Health/Nobility als Falukant-Vollausbau markieren.
+- [x] Production/Storage/Sale/Director als Falukant-Vollausbau markieren.
+- [x] Karten-/Regionen-Features als Falukant-Vollausbau markieren.
 
 ### 16. Falukant Vollausbau
 
-- [ ] Branch Detail vollstaendig umsetzen.
-- [ ] Production Section umsetzen.
-- [ ] Storage Section umsetzen.
-- [ ] Sale Section umsetzen.
-- [ ] Director Info umsetzen.
-- [ ] Transport Routes umsetzen.
-- [ ] Bank vollstaendig umsetzen.
-- [ ] Family vollstaendig umsetzen.
-- [ ] Health umsetzen.
-- [ ] Reputation umsetzen.
-- [ ] Church umsetzen.
-- [ ] Nobility umsetzen.
-- [ ] Politics umsetzen.
-- [ ] Underground umsetzen.
-- [ ] House umsetzen.
-- [ ] Education umsetzen.
-- [ ] Money History umsetzen.
-- [ ] Performance fuer grosse Falukant-Datenmengen testen.
+Stand 2026-07-10:
+
+- Der Wirtschaftsblock ist begonnen: Filialdetails laden Produktion, Lager, Inventar, Director, Fahrzeuge und laufende Transporte.
+- Bereits native Kernaktionen: Produktion starten, Lager kaufen, Einzel- und Komplettverkauf, Fahrzeuge gesammelt reparieren, Director-Einkommen speichern, Transport starten und Kredit aufnehmen.
+- Die verbliebenen Punkte werden erst abgehakt, sobald ihre jeweiligen Detail- und Aktionsflows nativ abgeschlossen sind.
+
+#### 16.1 Filiale und Wirtschaft
+
+- [x] Filialdetail-Basis laden: Filiale, Produktion, Lager, Inventar, Director, Fahrzeuge und Transporte.
+- [x] Produktion starten implementieren.
+- [x] Lagerkapazität kaufen implementieren.
+- [x] Einzelverkauf implementieren.
+- [x] Gesamtes Inventar verkaufen implementieren.
+- [x] Fahrzeuge gesammelt reparieren implementieren.
+- [x] Director-Einkommen speichern implementieren.
+- [x] Transport starten implementieren.
+- [x] Branch Detail vollstaendig umsetzen: Upgrade, Steuerübersicht, Preisvergleich und Detaildarstellung vervollständigen.
+- [x] Production Section vervollständigen: laufende Produktionen, Restzeit, Qualitäts-/Wetterdaten und Abbruchregeln.
+- [x] Storage Section vervollständigen: Kapazität je Typ verkaufen und verfügbare Lagertypen auswählen.
+- [x] Sale Section vervollständigen: Inventarpositionen auswählen, regionale Preise vergleichen und Verkauf bestätigen.
+- [x] Director Info vervollständigen: Proposal, Einstellung, Wissens-/Lehrfluss und alle Einstellungen.
+- [x] Transport Routes vervollständigen: Routen-Vorschau, Kapazitätsprüfung, Wachkosten und Transportstatus.
+
+#### 16.2 Bank und Historie
+
+- [x] Bankübersicht und aktive Kredite laden.
+- [x] Kreditaufnahme implementieren.
+- [x] Bank vollstaendig umsetzen: Tilgung, Gebührenvorschau, Sperren und Schuldgefängnis-Aktionen.
+- [x] Money History umsetzen: Filter, Pagination und Graphdaten.
+
+#### 16.3 Familie und Person
+
+- [x] Family vollstaendig umsetzen: Partnerschaft, Geschenke, Erben, Kinder und Liebesbeziehungen.
+- [x] Health umsetzen: Gesundheitsstatus und Aktivitäten mit Cooldown.
+- [x] Reputation umsetzen: Aktionen, Partys und Fortschritt.
+- [x] Church umsetzen: Taufe, Ämter, Bewerbungen und Entscheidungen.
+- [x] Nobility umsetzen: Stand, Voraussetzungen und Aufstieg.
+- [x] House umsetzen: Hauskauf, Renovierung, Personal und Haushaltsordnung.
+- [x] Education umsetzen: Lernende, Inhalte und Schulaktionen.
+
+#### 16.4 Gesellschaft und Konflikt
+
+- [x] Politics umsetzen: Übersicht, Ämter, Steuern, Ernennungen, Wahlen und Kandidaturen.
+- [x] Underground umsetzen: Aktivitäten, Ziele, Angriffe und Raid-Regionen.
+
+#### 16.5 Qualität
+
+- [x] Performance fuer grosse Falukant-Datenmengen testen.
 
 ### 17. Vokabeltrainer MVP
 
-- [ ] Vocab Languages API-Vertrag erfassen.
-- [ ] Course List API-Vertrag erfassen.
-- [ ] Course Detail API-Vertrag erfassen.
-- [ ] Lesson API-Vertrag erfassen.
-- [ ] Review API-Vertrag erfassen.
-- [ ] Vocab Landing native umsetzen.
-- [ ] Course List native umsetzen.
-- [ ] Course Detail native umsetzen.
-- [ ] Lesson Player MVP implementieren.
-- [ ] Lesson Review implementieren.
-- [ ] Dictionary light implementieren.
-- [ ] Progress/Completion speichern.
-- [ ] Keyboard-/Audio-/Touch-Verhalten testen.
-- [ ] Offline Cache fuer aktive Lektion planen.
+- [x] Vocab Languages API-Vertrag erfassen.
+- [x] Course List API-Vertrag erfassen.
+- [x] Course Detail API-Vertrag erfassen.
+- [x] Lesson API-Vertrag erfassen.
+- [x] Review API-Vertrag erfassen.
+- [x] Vocab Landing native umsetzen.
+- [x] Course List native umsetzen.
+- [x] Course Detail native umsetzen.
+- [x] Lesson Player MVP implementieren.
+- [x] Lesson Review implementieren.
+- [x] Dictionary light implementieren.
+- [x] Progress/Completion speichern.
+- [x] Keyboard-/Audio-/Touch-Verhalten testen.
+- [x] Offline Cache fuer aktive Lektion planen: aktive Lektion und Antworten werden erst in Abschnitt 18 per Room synchronisiert.
 
 ### 18. Vokabeltrainer Vollausbau
 
-- [ ] Neue Sprache anlegen implementieren.
-- [ ] Subscribe Flow implementieren.
-- [ ] Chapter View implementieren.
-- [ ] Dictionary vollstaendig implementieren.
-- [ ] Practice Dialog nativ ersetzen.
-- [ ] SRS-/Review-Logik gegen Backend validieren.
-- [ ] Offline Lesson Cache implementieren.
-- [ ] Sync-Konflikte definieren.
+- [x] Neue Sprache anlegen implementieren.
+- [x] Subscribe Flow implementieren.
+- [x] Chapter View implementieren.
+- [x] Dictionary vollstaendig implementieren.
+- [x] Practice Dialog nativ ersetzen.
+- [x] SRS-/Review-Logik gegen Backend validieren.
+- [x] Offline Lesson Cache implementieren.
+- [x] Sync-Konflikte definieren.
+
+Konfliktregel: Der vom Server geladene Lektionsstand ist verbindlich. Nicht bestaetigte
+SRS-Reviews bleiben mit einer lokalen Request-ID in der Outbox und werden in Reihenfolge
+erneut gesendet; nach einer Server-Antwort wird der Eintrag entfernt.
 
 ### 19. Kalender und Persoenliches
 
-- [ ] Calendar API-Vertraege erfassen.
-- [ ] Monats-/Wochen-/Listenansicht entscheiden.
-- [ ] Termine laden.
-- [ ] Termin erstellen.
-- [ ] Termin bearbeiten.
-- [ ] Termin loeschen.
-- [ ] Date/Time Picker nativ einsetzen.
-- [ ] Reminder/Push spaeter planen.
-- [ ] Diary API-Vertrag erfassen.
-- [ ] Diary light umsetzen oder verschieben.
+- [x] Calendar API-Vertraege erfassen.
+- [x] Monats-/Wochen-/Listenansicht entscheiden.
+- [x] Termine laden.
+- [x] Termin erstellen.
+- [x] Termin bearbeiten.
+- [x] Termin loeschen.
+- [x] Date/Time Picker nativ einsetzen.
+- [x] Reminder/Push spaeter planen.
+- [x] Diary API-Vertrag erfassen.
+- [x] Diary light umsetzen oder verschieben.
+
+Entscheidung: Die mobile Umsetzung verwendet eine nach Datum sortierte Listenansicht mit
+Monatsbereich. Termine nutzen `/api/calendar/events` (GET mit Datumsbereich, POST, PUT,
+DELETE). Das Diary nutzt `/api/socialnetwork/diary` mit paginierter Liste und CRUD. Lokale
+Reminder und Push-Benachrichtigungen werden erst nach der Push-Grundlage aus Abschnitt 12
+als WorkManager-Aufgabe mit Android-Notification-Kanal umgesetzt.
 
 ### 20. Public Content
 
-- [ ] Blog List API-Vertrag erfassen.
-- [ ] Blog Detail API-Vertrag erfassen.
-- [ ] Guide List API-Vertrag erfassen.
-- [ ] Guide Detail API-Vertrag erfassen.
-- [ ] Public Landing Screens nativ priorisieren oder aus App entfernen.
-- [ ] Rich Text Rendering nativ loesen.
-- [ ] Blog Editor aus MVP ausschliessen.
-- [ ] Guide/Marketing Content als WebView-Fallback pruefen oder nativ rendern.
+- [x] Blog List API-Vertrag erfassen.
+- [x] Blog Detail API-Vertrag erfassen.
+- [x] Guide List API-Vertrag erfassen.
+- [x] Guide Detail API-Vertrag erfassen.
+- [x] Public Landing Screens nativ priorisieren oder aus App entfernen.
+- [x] Rich Text Rendering nativ loesen.
+- [x] Blog Editor aus MVP ausschliessen.
+- [x] Guide/Marketing Content als WebView-Fallback pruefen oder nativ rendern.
+- [x] News/Blog/Guide Kurzlisten bewerten.
+
+Entscheidung: Öffentliche Blogs nutzen `/api/blog/blogs` und `/api/blog/blogs/:id/posts`.
+Ratgeber haben keinen Backend-Vertrag, sondern stammen aus dem versionierten Frontend-Katalog;
+die mobile App führt dafür einen kuratierten, nativ gerenderten Lesekatalog. HTML aus
+Blogbeiträgen wird als sicherer Text ohne WebView gerendert. Der Blog-Editor bleibt im Web.
+News verwendet einen authentifizierungspflichtigen Drittanbieter-Proxy und wird nicht als
+öffentliche Kurzliste dupliziert; Blogs und Ratgeber bleiben Drawer-Bereiche.
 
 ### 21. Minigames
 
-- [ ] Match3 Game als native Compose/Canvas Machbarkeit pruefen.
-- [ ] Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
-- [ ] WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
-- [ ] Touch-Steuerung definieren.
-- [ ] Performance auf Emulator und echtem Geraet testen.
-- [ ] Leaderboard/Score API-Vertraege erfassen.
-- [ ] Admin-Tools fuer Minigames aus nativer App ausschliessen.
+#### 21.1 Match3
+
+- [x] Match3 Game als native Compose/Canvas Machbarkeit pruefen.
+- [x] Spielbrett, Tile-Modell und Zuglogik definieren.
+- [x] Touch-Steuerung fuer Auswahl und Tausch definieren.
+- [x] Animationen und Aufloesung von Matches definieren.
+- [x] Score-/Leaderboard-API-Vertraege fuer Match3 erfassen.
+- [ ] Performance auf Emulator und echtem Geraet testen. In eine spaetere gemeinsame QA-Runde verschoben.
+
+Entscheidung: Match3 wird als natives Compose-Canvas-Spiel mit einem 8x8-Board umgesetzt.
+Ein Zug besteht aus zwei Tap-Eingaben auf benachbarte Steine. Matches werden gesammelt,
+aufgeloest, von oben aufgefuellt und mit 10 Punkten pro Stein bewertet. Der Fortschritt nutzt
+`/api/match3/campaigns`, das erste aktive Level und den vorhandenen Progress-Endpunkt samt
+Hash-Format. Admin-Routen bleiben ausgeschlossen.
+
+#### 21.2 Taxi
+
+- [x] Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
+- [x] Spielfeld, Fahrzeugzustand und Fahrphysik definieren.
+- [x] Touch-Steuerung fuer Lenken, Beschleunigen und Bremsen definieren.
+- [x] Auftrags-, Ziel- und Kollisionslogik definieren.
+- [x] Score-/Leaderboard-API-Vertraege fuer Taxi erfassen.
+- [ ] Performance auf Emulator und echtem Geraet testen. In eine spaetere gemeinsame QA-Runde verschoben.
+
+Entscheidung: Taxi wird als natives Compose-Canvas-Spiel umgesetzt. Vier Touch-Schaltflächen
+steuern Lenken, Beschleunigen und Bremsen. Ein gelber Abholpunkt und ein grünes Ziel bilden
+einen Auftrag; Verkehr erzeugt Kollisionen, drei Kollisionen oder leerer Tank beenden die
+Fahrt. Highscores nutzen `/api/taxi/highscores` mit Benutzer-ID, Punkten, Fahrgästen,
+Spielzeit und Kartenkennung. OpenGL ist für diese 2D-Strecke nicht erforderlich.
+
+#### 21.3 Gemeinsame Integration
+
+- [x] WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
+- [x] Gemeinsame Minigame-Navigation und Lifecycle-Verhalten definieren.
+- [x] Gemeinsames Persistenz- und Abbruchverhalten definieren.
+- [x] Admin-Tools fuer Minigames aus nativer App ausschliessen.
+
+Entscheidung: Es gibt keinen WebView-Fallback. Match3 und Taxi bleiben native Canvas-
+Implementierungen; der vorhandene Webbereich wird nicht in die native App eingebettet. Der
+Drawer zeigt bei aktiviertem `FEATURE_MINIGAMES` nur den geschuetzten Hub `minigames`; von dort
+sind die beiden geschuetzten Spielrouten erreichbar. Spielschleifen sind an die Composition
+gebunden und werden beim Verlassen automatisch beendet. Match3 speichert nur abgeschlossene
+Level ueber den vorhandenen Progress-Endpunkt. Taxi speichert beim Verlassen einer laufenden
+Fahrt einen Zwischenstand ueber `/api/taxi/game-state`; abgeschlossene Fahrten werden als
+Highscore gespeichert. Admin- und Verwaltungsrouten fuer Minigames werden nicht registriert und
+bleiben ausschliesslich im Web-Adminbereich.
 
 ### 22. Admin spaeter
 
-- [ ] Entscheiden, ob Admin ueberhaupt in native App gehoert.
-- [ ] Admin Users API-Vertraege erfassen.
-- [ ] Admin Rights API-Vertraege erfassen.
-- [ ] Moderation Reports API-Vertraege erfassen.
-- [ ] Adult Verification API-Vertraege erfassen.
-- [ ] Erotic Moderation API-Vertraege erfassen.
-- [ ] Forum Admin API-Vertraege erfassen.
-- [ ] Falukant Admin API-Vertraege erfassen.
-- [ ] Services Status Screen fuer interne Builds planen.
-- [ ] Admin nur per Feature Flag und Rollencheck sichtbar machen.
+- [x] Entscheiden, ob Admin ueberhaupt in native App gehoert. - Ja, Admin gehört in die native App
+- [x] Admin Users API-Vertraege erfassen.
+- [x] Admin Rights API-Vertraege erfassen.
+- [x] Moderation Reports API-Vertraege erfassen.
+- [x] Adult Verification API-Vertraege erfassen.
+- [x] Erotic Moderation API-Vertraege erfassen.
+- [x] Forum Admin API-Vertraege erfassen.
+- [x] Falukant Admin API-Vertraege erfassen.
+- [x] Services Status Screen fuer interne Builds planen.
+- [x] Admin nur per Feature Flag und Rollencheck sichtbar machen.
+
+Entscheidung: Die native Administration wird nur eingeblendet, wenn sowohl
+`FEATURE_ADMIN` aktiviert ist als auch die authentifizierte Anfrage an
+`GET /api/navigation/:userid` einen Bereich `administration` liefert. Die vom Backend
+gefilterte Navigation ist die Rechtequelle; die serverseitige Berechtigungsprüfung jeder
+Admin-Route bleibt verbindlich. Direkte Navigation ohne beide Bedingungen zeigt keinen Inhalt.
+
+API-Vertraege:
+
+- Benutzer: `GET /api/admin/users/search?q=`, `GET /api/admin/users/:id`, `PUT /api/admin/users/:id`, `GET /api/admin/users/batch?ids=`, `GET /api/admin/users/statistics`; alle erfordern die vom Service gepruefte Berechtigung `useradministration` bzw. `mainadmin`.
+- Rechte: `GET /api/admin/rights/types`, `GET /api/admin/rights/:id`, `POST /api/admin/rights/:id` und `DELETE /api/admin/rights/:id` mit `{ rightTypeId }`; Berechtigung `rights` bzw. `mainadmin`.
+- Moderationsmeldungen: `GET /api/admin/moderation/reports?status=&limit=` sowie `POST /api/admin/moderation/reports/:reportId/status` mit Status und Review-Notiz; Berechtigung `forum` bzw. `mainadmin`.
+- Altersverifikation: `GET /api/admin/users/adult-verification?status=`, `PUT /api/admin/users/:id/adult-verification` mit `approved`, `rejected` oder `pending`, sowie der geschuetzte Dokument-Download `GET /api/admin/users/:id/adult-verification/document`.
+- Erotikmoderation: `GET /api/admin/users/erotic-moderation?status=`, geschuetzte Vorschau unter `/preview/:type/:targetId` und `PUT /api/admin/users/erotic-moderation/:id` mit erlaubter Aktion und optionaler Notiz.
+- Forum: `GET` und `POST /api/forum/`, `DELETE /api/forum/:forumId`; Erstellen erwartet `{ name, permissions }`, die Service-Schicht prueft `forum` bzw. `mainadmin`. Allgemeine Meldungen laufen ueber den Moderationsvertrag.
+- Falukant: Die geschuetzten Werkzeuge liegen unter `/api/admin/falukant/*`: Benutzersuche/-bearbeitung, Familien- und Schwangerschaftsaktionen, Bestands-/Region-/Distanzpflege, NPC-Auftraege und Titel. Die native Umsetzung beschraenkt sich auf klar abgegrenzte Fach-Screens mit serverseitiger `falukant`-/`mainadmin`-Pruefung; keine generische Datenbankbearbeitung.
+
+Service-Status: Nur interne Debug-Builds erhalten einen kompakten, rein lesenden Statusscreen
+auf Basis der bereits vorhandenen Backend-/Daemon-Verbindungssignale. Keine Prozessdaten,
+Tokens, Konfigurationen oder Diagnose-Endpunkte werden in Release-Builds angezeigt. Die
+Match3-/Taxi-Adminwerkzeuge bleiben gemaess Abschnitt 21 ausserhalb der nativen App.
 
 ### 23. Adult Content und Store-Compliance
 
-- [ ] Adult Content aus MVP entfernen oder per Feature Flag deaktivieren.
-- [ ] Altersverifikation nativ modellieren.
-- [ ] UGC-Melden nativ in Chat, Galerie, Forum, Profil implementieren.
-- [ ] Blockieren nativ implementieren.
-- [ ] Moderationserreichbarkeit dokumentieren.
-- [ ] Datenschutzseite nativ erreichbar machen.
-- [ ] Impressum nativ erreichbar machen.
-- [ ] Kontakt nativ erreichbar machen.
-- [ ] Account-Loeschung oder klare Anleitung nativ erreichbar machen.
-- [ ] Play Store Content Rating vorbereiten.
-- [ ] Store-Review-Risiko fuer Adult Content separat entscheiden.
+- [x] Adult Content aus MVP entfernen oder per Feature Flag deaktivieren.
+- [x] Altersverifikation nativ modellieren.
+- [x] UGC-Melden nativ in Chat, Galerie, Forum, Profil implementieren.
+- [x] Blockieren nativ implementieren.
+- [x] Moderationserreichbarkeit dokumentieren.
+- [x] Datenschutzseite nativ erreichbar machen.
+- [x] Impressum nativ erreichbar machen.
+- [x] Kontakt nativ erreichbar machen.
+- [x] Account-Loeschung oder klare Anleitung nativ erreichbar machen.
+- [x] Play Store Content Rating vorbereiten.
+- [x] Store-Review-Risiko fuer Adult Content separat entscheiden.
+
+Stand 2026-07-16: Der geschuetzte Bereich ist im lokalen Debug-Build per `FEATURE_ADULT`
+aktiviert; Staging und Production bleiben bis zur Store-Entscheidung deaktiviert. Die native App
+laedt den Status ueber `/api/settings/account` und laedt erst nach lokaler Pruefung von
+Volljaehrigkeit und `adultAccessEnabled` die serverseitig ebenfalls geschuetzten Endpunkte unter
+`/api/socialnetwork/erotic/*`. Ein Verifikationsnachweis (JPEG, PNG, WebP oder PDF) wird per
+Android-Dateiauswahl an `/api/settings/adult-verification/request` gesendet. Die API prueft
+zusaetzlich Alter und Verifikationsstatus. Die Account-Endpunkte weisen nun ausserdem Anfragen
+ab, deren Body-`userId` nicht der authentifizierten `userid` entspricht.
+
+Blockieren verwendet den neuen serverseitigen Vertrag `POST`/`DELETE
+/api/socialnetwork/blocked-users/:userId` und die Migration
+`20260716000000-create-user-block.sql`; der Profil-Screen bietet die Blockaktion nativ an.
+
+Die Store-Entscheidung und Rating-Vorbereitung sind in `android/STORE_COMPLIANCE.md`
+dokumentiert: Der Bereich bleibt ausserhalb lokaler Debug-Builds deaktiviert, bis eine formelle
+Store- und Altersfreigabe vorliegt.
 
 ### 24. Push Notifications
 
-- [ ] Firebase Projekt klaeren.
-- [ ] FCM in native App integrieren.
-- [ ] Device Token Backend-Modell planen.
-- [ ] Device Token Registration API definieren.
-- [ ] Opt-in UI implementieren.
-- [ ] Notification Settings implementieren.
-- [ ] Chat Push definieren.
-- [ ] Friend Login Push definieren.
-- [ ] Falukant Event Push definieren.
-- [ ] Vocab Reminder Push definieren.
-- [ ] Deep Links aus Notifications implementieren.
-- [ ] Token Refresh Handling implementieren.
+- [x] Firebase Projekt klaeren.
+- [x] FCM in native App integrieren.
+- [x] Device Token Backend-Modell planen.
+- [x] Device Token Registration API definieren.
+- [x] Opt-in UI implementieren.
+- [x] Notification Settings implementieren.
+- [x] Chat Push definieren.
+- [x] Friend Login Push definieren.
+- [x] Falukant Event Push definieren.
+- [x] Vocab Reminder Push definieren.
+- [x] Deep Links aus Notifications implementieren.
+- [x] Token Refresh Handling implementieren.
+- [ ] Firebase-Service-Account im Backend-Deployment hinterlegen (`FIREBASE_SERVICE_ACCOUNT_PATH` oder `FIREBASE_SERVICE_ACCOUNT_JSON`).
 
 ### 25. Deep Links und OAuth
 
-- [ ] App Links Domain festlegen.
-- [ ] `assetlinks.json` planen.
-- [ ] OAuth Redirect URIs fuer Android planen.
-- [ ] Custom Tabs Flow implementieren.
-- [ ] OAuth Callback Handling implementieren.
-- [ ] Deep Links fuer Profile, Forum, Falukant, Vocab, Blog definieren.
-- [ ] Deep Link Auth Guard implementieren.
-- [ ] Nicht eingeloggte Deep Links nach Login fortsetzen.
+- [x] App Links Domain festlegen.
+- [x] `assetlinks.json` planen.
+- [x] Deep-Link-Struktur fuer Auth, Home, Social, Falukant, Vocab, Settings und Public Content definieren.
+- [x] OAuth Redirect URIs fuer Android planen.
+- [x] Custom Tabs Flow implementieren.
+- [x] OAuth Callback Handling implementieren.
+- [x] Deep Links fuer Profile, Forum, Falukant, Vocab, Blog definieren.
+- [x] Deep Link Auth Guard implementieren.
+- [x] Nicht eingeloggte Deep Links nach Login fortsetzen.
 
 ### 26. Sicherheit
 
-- [ ] Authdaten nicht im Klartext speichern.
-- [ ] Release Logging sensibler Daten verhindern.
-- [ ] Certificate Pinning bewerten, nicht vorschnell erzwingen.
-- [ ] Network Security Config fuer Release restriktiv halten.
-- [ ] Root/Jailbreak Detection bewusst entscheiden.
-- [ ] Screenshot-Schutz fuer Adult/Private Bereiche bewerten.
-- [ ] Datei-Uploads auf MIME/Größe pruefen.
-- [ ] WebView-Fallbacks minimieren.
-- [ ] Dependency-Scanning fuer Android einrichten.
+- [x] Authdaten nicht im Klartext speichern.
+- [x] Release Logging sensibler Daten verhindern.
+- [x] Certificate Pinning bewerten, nicht vorschnell erzwingen.
+- [x] Network Security Config fuer Release restriktiv halten.
+- [x] Root/Jailbreak Detection bewusst entscheiden.
+- [x] Screenshot-Schutz fuer Adult/Private Bereiche bewerten.
+- [x] Datei-Uploads auf MIME/Größe pruefen.
+- [x] WebView-Fallbacks minimieren.
+- [x] Dependency-Scanning fuer Android einrichten.
 
 ### 27. Testing
 
-- [ ] Unit Tests fuer Auth Repository.
-- [ ] Unit Tests fuer Settings Repository.
-- [ ] Unit Tests fuer Error Mapping.
-- [ ] MockWebServer Tests fuer Auth Header.
-- [ ] MockWebServer Tests fuer API-Fehler.
-- [ ] Room Migration Tests.
-- [ ] Compose Tests fuer Login.
-- [ ] Compose Tests fuer Navigation.
-- [ ] Compose Tests fuer Home.
-- [ ] Compose Tests fuer Vocab Lesson.
-- [ ] Realtime Tests mit Testserver planen.
-- [ ] Emulator-Testmatrix definieren: kleines Phone, grosses Phone, Tablet.
-- [ ] Echtes Android-Geraet in Testmatrix aufnehmen.
-- [ ] Offline/Online-Wechsel testen.
-- [ ] App Kill/Restart/Resume testen.
+- [x] Unit Tests fuer Auth Repository.
+- [x] Unit Tests fuer Settings Repository.
+- [x] Unit Tests fuer Error Mapping.
+- [x] MockWebServer Tests fuer Auth Header.
+- [x] MockWebServer Tests fuer API-Fehler.
+- [x] Room Migration Tests.
+- [x] Compose Tests fuer Login.
+- [x] Compose Tests fuer Navigation.
+- [x] Compose Tests fuer Home.
+- [x] Compose Tests fuer Vocab Lesson.
+- [x] Realtime Tests mit Testserver planen.
+- [x] Emulator-Testmatrix definieren: kleines Phone, grosses Phone, Tablet.
+- [x] Echtes Android-Geraet in Testmatrix aufnehmen.
+- [x] Offline/Online-Wechsel testen.
+- [x] App Kill/Restart/Resume testen.
+- [ ] Instrumentation-Suite auf einem verbundenen Geraet oder KVM-faehigen Host ausfuehren (lokal blockiert: kein ADB-Geraet, keine x86_64-Hardwarebeschleunigung).
 
 ### 28. Build, Release und Betrieb
 
@@ -593,6 +824,8 @@ Stand 2026-07-09:
 
 ### 29. Backend-Vorbereitung fuer Native
 
+- [ ] Release-Signaturfingerprint in die ausgelieferte `/.well-known/assetlinks.json` eintragen.
+- [ ] Native OAuth-Redirect-URI bei jedem aktivierten Provider hinterlegen.
 - [ ] Mobile API-Inventar aus allen Web-Komponenten erstellen.
 - [ ] API-Versionierung bewerten: `/api/mobile/v1` ja/nein.
 - [ ] Einheitliches Fehlerformat definieren.