chore: Planungs-Docs in lokale Ideen-Sammlung verschieben

MULTITOOL_AUSBAU_PLAN.md und VERSCHLUESSELUNGS_ANALYSE.md nach Ideen/
(gitignored) verschoben -> aus dem Repo genommen, lokal erhalten.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

MULTITOOL_AUSBAU_PLAN.md

@@ -1,222 +0,0 @@
-# MULTITOOL-AUSBAU — Orchestrierungs-KI, Sicherheit & feinkörnige Nutzerprofile
-
-> Planungsdokument. Erstellt 2026-06-26. Umsetzung geplant ab nächster Woche
-> (neues Wochen-Kontingent). Selbst-enthaltend, damit eine frische Session den
-> Kontext ohne Vorwissen versteht.
->
-> Status: **PLAN — noch nichts implementiert.** Branch: `jamulix-optimized`.
-
----
-
-## 0. Ausgangsfrage (wörtlich sinngemäß vom Nutzer)
-
-> „Könnte unser System auch so umgebaut werden, dass es ein Orchestrierungs-KI-Tool
-> als zentrales KI-Modell benutzt, das seinerseits wieder OpenRouter-KI-Modelle
-> aufruft, um bestimmte Dienste (z. B. Recherche im Internet) zu leisten?"
-
-Zusatzwunsch des Nutzers: feinkörniges **Management der Nutzerprofile** — festlegen,
-**wer was darf**, um Gefahren auszuschließen und Risiken klein zu halten. Begründung:
-Senioren sind unterschiedlich kompetent; ab einem gewissen Stadium ist schon der
-Umgang mit dem Mobilgerät eine Überforderung.
-
----
-
-## 1. Architektur-Befund: das System ist dafür gebaut
-
-Die LLM-Achse ist eine **austauschbare Achse hinter einem winzigen Interface**
-(`app/providers/llm/base.py`):
-
-```python
-async def complete(text, history, session_id, language) -> str
-async def stream(...) -> AsyncIterator[str]   # Default: complete() als ein Chunk
-```
-
-Ein „Orchestrierungs-Tool" ist aus Kern-Sicht **nur ein weiterer LLM-Provider**, der
-intern beliebig viel tun darf (Tool-Calls, mehrere Modelle, Websuche) und am Ende
-Text liefert/streamt. **Kein Kern-Code muss geändert werden** — ein Registry-Eintrag
-(`LLM_REGISTRY` in `app/dependencies.py`) genügt. Der **gerade gebaute Modell-Dropdown**
-(Admin › System › Status, `config/models.yaml`, `app/model_presets.py`) ist der
-natürliche Umschalter; Auswahl/Umstellung läuft über die Laufzeit-Overrides
-(`RUNTIME_SETTABLE`, wirkt ohne Neustart).
-
-### Drei Andock-Formen (alle ohne Architektur-Bruch)
-1. **OpenRouter-nativ (am leichtesten).** Der OpenRouter-Provider baut nur ein simples
-   `{model, messages, stream}`-JSON (`app/providers/llm/openrouter.py`). Erweiterbar um
-   OpenRouters **Websuche** (Web-Plugin bzw. `modell:online`) und/oder den **Auto-Router**
-   `openrouter/auto`. → „Recherche" + „Modell-Orchestrierung light" praktisch ohne Agent-Code,
-   nur ein neues Preset im Dropdown.
-2. **Eigener Orchestrator-Provider.** `app/providers/llm/orchestrator.py` implementiert das
-   ABC und fährt intern eine **begrenzte Tool-Schleife** (OpenRouter-Tool-Calling) mit Werkzeugen
-   wie `web_search`, `call_model(model, prompt)`, `datum/zeit`. Plug-in als
-   `default_llm_provider="orchestrator"` (ein Registry-Eintrag, ein Preset). **= genau das vom
-   Nutzer gewünschte Bild.**
-3. **Externer Orchestrierungs-Dienst.** Agent-Framework (LangGraph/Flowise/n8n/eigener
-   MCP-Host) mit **OpenAI-kompatibler `/chat/completions`**-Fassade; der vorhandene
-   `local_openai_compatible`-Provider zeigt per `base_url` darauf → **null neuer Provider-Code**.
-
-**Verifizieren (gegen aktuelle OpenRouter-Doku, Wissensstand kann hinterherhinken):**
-Web-Plugin / `:online`-Suffix, Perplexity-„sonar"-Modelle (native Online-Suche),
-`openrouter/auto`-Router, Tool-/Function-Calling-Passthrough, Kosten der Websuche.
-
----
-
-## 2. Diskussion & Entscheidungen
-
-### 2.1 Latenz — gelöst über Füllsprache (Nutzer-Idee, bestätigt)
-Voice braucht „erster Ton in ~1–2 s"; eine Agenten-Schleife + Web-Fetch dauern 5–20 s mit
-Totstille. Lösung (Nutzer): Frage **zusammenfassen + vorlesen**, dann in **30–50 Varianten**
-sinngemäß „Ich kümmere mich darum, eine gute Antwort zu finden. Lass mich kurz lesen und
-nachdenken." → zwischendurch „Habe noch ein bisschen Geduld, ich bin gleich soweit." → dann
-die Antwort.
-
-**Ergänzungen/Verbesserungen:**
-- Das **Vorlesen der zusammengefassten Frage = Verständnis-Rückversicherung** (gegen STT-/
-  Missverständnis-Fehler) — doppelter Nutzen.
-- Varianten **an verstrichene/erwartete Restzeit koppeln** (nicht „gleich soweit" beim Start).
-- Füllsätze müssen **barge-in-fähig** sein (Nutzer korrigiert → sofort abbrechen + neu zuhören).
-  Nutzt die bereits gebaute **entkoppelte, satzweise TTS + Barge-in**: Füllsatz wird sofort
-  gesprochen, während die Recherche läuft; danach streamt die echte Antwort in dieselbe
-  geordnete TTS-Queue.
-- **Graceful give-up**, falls Zeitbudget reißt („ich konnte es nicht sicher herausfinden").
-- Optional multimodale Beruhigung (Bubble „🔎 liest…").
-- Varianten + Sicherheits-Antworten **pro Sprache** pflegen.
-
-### 2.2 Selektives Routing — Muss (Nutzer bestätigt)
-- **Intent-Gate** (billig/schnell, Regeln oder kleines Modell): „einfacher Plausch/Frage" vs.
-  „braucht Recherche/Tools". Die meisten Senioren-Turns dürfen NICHT die Agenten-Steuer zahlen.
-- Entscheidung berücksichtigt **auch Nutzerprofil/Berechtigungen** (§ 2.6), nicht nur das Intent.
-- Im Zweifel **rückfragen** statt selbstsicher veraltet antworten. Entscheidung **protokollieren**.
-- Muster existiert schon: der nicht-blockierende Notruf-LLM-Klassifikator (`app/safety/`).
-
-### 2.3 Kosten — Deckel + Logging (Nutzer bestätigt)
-- Budget **pro Turn _und_ pro Nutzer/Tag _und_ global**; **inkl. Websuche-Kosten** (extra zu Tokens).
-- **Circuit-Breaker** bei Kostenausreißern; Kosten als **Admin-Metrik** sichtbar
-  (`app/metrics.py`, vorhandenes Tageskontingent `app/quota.py` zählt heute nur Turns → um
-  Token-/Kosten-Konten erweitern).
-
-### 2.4 Sicherheit — der EIGENTLICHE Kern (Nutzer-Schwerpunkt: Medizin/gefährliche Ratschläge)
-Prompt-Injection ist beherrschbar; **falsche/gefährliche, v. a. medizinische Ratschläge** sind
-das große Risiko (Senioren reden gern über Krankheiten). **Eigener Arbeitsstrang.**
-- **Unterscheiden:** *über Krankheit reden* (Empathie, zuhören, KEINE Ratschläge) vs.
-  *um medizinischen Rat fragen* (immer an Arzt/Apotheke/Betreuer verweisen). Themen-Detektor
-  (analog Notruf-Klassifikator) → **sicherer Antwortmodus**.
-- **Harte Tabus:** keine Dosierungen, keine Diagnosen, kein „Medikament absetzen/ändern".
-  Nachgelagerter Output-Check (billiger Klassifikator), der unsicheren medizinischen Inhalt
-  blockt/umschreibt.
-- **Web bei Gesundheit:** ganz aus ODER nur **kuratierte, seriöse Quellen**.
-- **Datenschutz:** Gesundheitsdaten = DSGVO-**besondere Kategorie**. Sensible medizinische Frage
-  evtl. **lokal (Ollama, keine Cloud, kein Web)** beantworten → verbindet Routing + Sicherheit +
-  Datenschutz.
-- **Betreuer-Schleife:** riskante Themen → Kontakt informieren (nutzt Notruf-Benachrichtigungs-
-  Infrastruktur `app/safety/emergency.py`).
-- **Scam-/Betrugsschutz:** „soll ich Geld an … überweisen?" → Warn-Layer (Senioren sind Ziel).
-
-### 2.5 Notruf-Invariante bleibt schnell & getrennt (Klarstellung zu meinem Punkt 5)
-Heute läuft die **Notruf-Stichwort-Erkennung VOR dem LLM**, unabhängig von jedem Modell
-(`app/safety/emergency.py`, Hot-Path). Wenn das „zentrale Modell" ein **langsamer Orchestrator**
-(5–20 s) wird, darf die Notruf-Erkennung **nicht** durch ihn laufen — sonst verzögert eine
-Recherche einen echten Notruf. **Der schnelle Sicherheits-Pfad bleibt getrennt und schnell.**
-
-### 2.6 Feinkörnige Nutzerprofile = Policy-Schicht des Systems (Nutzer-Grundsatzpunkt)
-Kein Nebenpunkt, sondern **die zentrale Policy-Schicht**, die Router/Orchestrator/Sicherheit
-konsultieren. Passt auf die vorhandenen **Pro-Nutzer-Prefs** (`user.prefs`, gerade um
-per-User-Notrufpause erweitert).
-- **Kompetenz-Stufen als Vorlagen** (z. B. *Selbstständig · Begleitet · Stark eingeschränkt*)
-  mit Defaults + **Pro-Nutzer-Feinjustierung** (nicht 20 Schalter pro Person).
-- Jede Stufe legt fest: **Web-Recherche an/aus, Medizin-Modus, Modell-Stufe (schnell vs.
-  Orchestrator), Antwort-Komplexität/-Länge, Freitext vs. „einfacher Modus", Auslöser für
-  Betreuer-Benachrichtigung.**
-- **„Einfacher Modus"-UI** für Überforderte (großer Sprechknopf + SOS, keine Menüs/Tabs) —
-  eigener kleiner Strang (UX).
-- **Vom Betreuer/Admin konfiguriert** (Admin › Nutzer › Notfall-/Profil-Bereich), der Senior
-  kann Sicherheitseinstellungen **nicht selbst aufweichen**.
-
-### 2.7 Verlässlichkeit (Nutzer bestätigt)
-Agenten sind weniger deterministisch. Orchestrierung **opt-in/selektiv**, nicht Default —
-der normale, schnelle Assistenzbetrieb darf nicht leiden.
-
----
-
-## 3. Querschnitts-Anforderungen (gelten für alle Phasen)
-- **Hartes Wall-Clock-Budget** je Turn (z. B. ≤ 6–8 s) + max. 1–2 Tool-Schritte + Timeouts.
-- **Füllsprache** (barge-in-fähig, zeit-gekoppelt, mehrsprachig, graceful give-up).
-- **Routing-Policy** konsultiert Intent **und** Nutzerprofil/Berechtigungen.
-- **Kostenkonto** (Turn/Nutzer/global) inkl. Websuche; Circuit-Breaker; Admin-Sichtbarkeit.
-- **Sicherheits-Guardrails** (Medizin/gefährlich/Scam) mit sicherem Antwortmodus + Output-Check.
-- **Notruf-Hot-Path bleibt getrennt & schnell.**
-- **Graceful Degradation** (Web/Modell/Budget aus → sichere gesprochene Notlösung; Fallback-Ketten
-  `app/providers/fallback.py` nutzen).
-- **DSGVO/Consent** für Sprach- & Gesundheitsdaten; sensible Themen ggf. lokal (Ollama).
-- **Auditierbarkeit** (Routing, Tool-Use, Kosten, Sicherheits-Trigger) für Betreuer/Admin
-  (`app/audit.py`, Admin-Log).
-- **Eval-/Guardrail-Testset** (Medizin-Verweigerung, Injection, Latenz, Routing-Korrektheit).
-- Hinweis: Profil nimmt **ein Nutzer pro Gerät/Login** an (Besuch/zweite Person nicht modelliert).
-
----
-
-## 4. Phasenplan
-
-### Phase 0 — Realitätstest „Recherche" (fast gratis)
-Ziel: **Ist die Latenz für Senioren überhaupt erträglich?** — vor jedem Agenten-Bau.
-- OpenRouter-Websuche (Web-Plugin / `:online`) an EINEM Modell aktivieren; als Dropdown-Preset
-  „… (Recherche)" in `config/models.yaml` (Provider-Payload in `openrouter.py` um Plugin/Suffix
-  erweitern).
-- Erste, einfache **Füllsprache** (1–2 Varianten) im Streaming-Pfad testen.
-- Messen: End-to-End-Latenz, „Time-to-first-Füllsatz", Antwortqualität, Kosten/Turn.
-- **Akzeptanzkriterium** (mit Nutzer festzulegen): z. B. „bis ~5 s, mit gesprochenem ‚ich schaue nach'".
-
-### Phase 1 — Eigener Orchestrator-Provider (falls Phase 0 trägt)
-- `app/providers/llm/orchestrator.py` (ABC): **Intent-Gate → begrenzte Tool-Schleife
-  (web_search, call_model) → Füllsatz-Streaming → hartes Zeitbudget**. Registry-Eintrag + Preset.
-- **Routing** mit Profil-Berücksichtigung (§ 2.6) verdrahten.
-- **Kostenkonto** + Circuit-Breaker (`app/quota.py`/`metrics.py` erweitern).
-- **Füllsprache** voll ausbauen (30–50 Varianten, zeit-gekoppelt, mehrsprachig, barge-in).
-
-### Phase 2 — Medizin-/Sicherheits-Guardrails (parallel ab Phase 1, hohe Priorität)
-- Themen-Detektor (Medizin/gefährlich/Scam) → **sicherer Antwortmodus** (Empathie + Verweis,
-  harte Tabus, Output-Check).
-- Sensible Themen → **lokales Modell (Ollama), kein Web**; optional Betreuer-Benachrichtigung.
-- Eval-/Guardrail-Testset.
-
-### Phase 3 — Nutzerprofil-/Berechtigungs-Management
-- **Kompetenz-Stufen (Vorlagen) + Pro-Nutzer-Overrides** in `user.prefs`
-  (Schema `AdminUserPrefsUpdate`, Admin-UI im Notfall-/Profil-Bereich erweitern).
-- Policy-Schicht, die Router/Orchestrator/Guardrails konsultieren.
-- **„Einfacher Modus"-UI** (großer Sprechknopf + SOS, keine Menüs) als gegateter Strang.
-
-### Phase 4 (optional, falls es wächst) — Externer Agenten-Dienst
-- Orchestrator in separaten Dienst auslagern (OpenAI-kompatible Fassade → `local_openai_compatible`
-  per `base_url`); Gateway bleibt schlank; Tools via MCP.
-
----
-
-## 5. Risiken & offene Fragen (für nächste Woche)
-- **Latenz-Akzeptanz** der Senioren — durch Phase 0 empirisch klären.
-- **Medizin-Sicherheit**: genaue Linie „zuhören vs. verweisen", kuratierte Quellenliste, Output-Check-Modell.
-- **Kostenmodell**: konkrete Deckel pro Turn/Nutzer/Tag; Websuche-Preis.
-- **Profil-Stufen**: welche Stufen genau, welche Schalter pro Stufe (Default-Matrix entwerfen).
-- **DSGVO**: Consent-Fluss, Speicherung von Gesundheitsthemen (auch im Auto-Memory-Extractor).
-- **Wer testet die Guardrails** (Red-Team-Promptset) und wie oft (CI?).
-- **OpenRouter-Features** gegen aktuelle Doku verifizieren (Namen/Preise/Verfügbarkeit).
-
-## 6. Konkrete erste Schritte (Start nächste Woche)
-1. OpenRouter-Doku prüfen: Websuche/`:online`, `openrouter/auto`, sonar, Tool-Calling, Preise.
-2. Phase 0: Recherche-Preset + minimale Füllsprache, Latenz/Kosten messen, Akzeptanzkriterium mit
-   Nutzer fixieren.
-3. Default-Matrix der Kompetenz-Stufen entwerfen (Tabelle Stufe × Schalter).
-4. Medizin-Safety-Linie skizzieren (was sagt das System bei Krankheitsthemen — Beispiele sammeln).
-
----
-
-## 7. Bezug zum bestehenden Code (Andockpunkte)
-- LLM-Provider/Interface: `app/providers/llm/{base,openrouter,local_openai_compatible}.py`
-- Registry/Routing: `app/dependencies.py` (`LLM_REGISTRY`, `resolve_route`)
-- Laufzeit-Umschaltung: `app/runtime_config.py` (`RUNTIME_SETTABLE`) + Admin-Config-Endpunkte
-- Modell-Dropdown (Umschalter): `config/models.yaml`, `app/model_presets.py`, Admin › System › Status
-- Pro-Nutzer-Policy: `user.prefs`, `app/schemas.py` (`AdminUserPrefsUpdate`), Admin › Nutzer
-- Sicherheit/Notruf (Muster + Invariante): `app/safety/` (`emergency.py`, `llm_classifier.py`)
-- Kosten/Quota/Metriken: `app/quota.py`, `app/metrics.py`
-- Resilienz/Fallback: `app/providers/fallback.py`
-- Audit: `app/audit.py`
-- Streaming/TTS-Entkopplung + Barge-in (Basis für Füllsprache): `app/core/orchestrator.py`,
-  `app/pipeline/sentence_chunker.py`, `app/api/ws.py`

VERSCHLUESSELUNGS_ANALYSE.md

@@ -1,162 +0,0 @@
-# Verschlüsselungs-Analyse — Datenbank & Backups
-
-> Stand: Entwurf / Diskussionsgrundlage. Betrifft die SQLite-DB mit Userdaten,
-> Gesprächsverläufen, Erinnerungen und Notfall-Profilen (Name, Adresse,
-> Geburtsdatum, **medizinische Notizen**, Telefon). Ziel: Schutz der Daten **at
-> rest** gegen Diebstahl von DB-Datei, Backups oder Datenträger.
->
-> Leitsatz: **Der Cipher ist der einfache Teil — entscheidend ist das
-> Schlüsselmanagement und das Bedrohungsmodell.**
-
-## 1. Bedrohungsmodell — wogegen schützt at-rest-Verschlüsselung überhaupt?
-
-| Szenario | Hilft Verschlüsselung? |
-|---|---|
-| **Gestohlenes Backup** (kopiert, geleakt, alter USB/Cloud-Ordner) | **Ja** — wahrscheinlichster & am leichtesten zu schließender Fall |
-| **Gestohlene/ausgemusterte Platte** (Box aus, Disk-Image) | **Ja — nur wenn der Schlüssel NICHT auf derselben Platte liegt** |
-| **Live-Kompromittierung** (root/App-Zugriff auf dem laufenden Server) | **Nein** — die App muss entschlüsseln können → Schlüssel im RAM |
-| **Hypervisor / Rechenzentrum** (RAM- & Disk-Snapshot durch Betreiber) | **Kaum** — RAM-Snapshot greift den Schlüssel ab |
-
-**Kernfalle:** Liegt der Schlüssel als Datei/`.env` auf **derselben** Platte wie
-die DB, bekommt ein Disk-/Backup-Dieb beides → die Verschlüsselung ist wertlos.
-
-## 2. Ganze DB einmal verschlüsseln vs. jeden User einzeln?
-
-**Empfehlung: ganze DB (eine Verschlüsselung), NICHT pro User.**
-
-- Pro-User-Verschlüsselung bringt nur dann Mehrwert, wenn die User-Schlüssel
-  **nicht** serverseitig verfügbar sind (aus User-Geheimnis abgeleitet, nur bei
-  aktiver Sitzung).
-- Der Assistent ist aber ein **autonomer, immer-laufender Server**: er verarbeitet
-  Userdaten **ohne** anwesenden Nutzer (Auto-Erinnerungs-Extraktion, LLM-Kontext,
-  Safety, Admin). Er muss also jederzeit entschlüsseln können → hält/leitet alle
-  Schlüssel ab → ein Dieb des Schlüsselmaterials bekommt **trotzdem alles**.
-- Authelia/SSO liefert **keinen** stabilen pro-User-Krypto-Schlüssel. Echte
-  Client-seitige Verschlüsselung würde den LLM-Assistenten unmöglich machen.
-- Pro-Feld-Verschlüsselung zerstört zudem Indizes/Suche/SQL, leakt Metadaten
-  (wer/wann/wie viel) und lässt WAL-/Temp-Dateien im Klartext.
-
-→ Pro-User = **sehr hoher Aufwand, kaum Sicherheitsgewinn** in dieser Architektur
-(Security-Theater). Whole-DB ist richtig und ausreichend.
-
-## 3. Methoden für Whole-DB
-
-- **(a) SQLCipher** (verschlüsseltes SQLite): App öffnet die DB mit `PRAGMA key`,
-  verschlüsselt DB + WAL transparent. Aufwand: Dependency (`pysqlcipher3`) +
-  `store._connect` + Einmal-Migration. App-contained.
-- **(b) Verschlüsseltes Volume** (LUKS-Loopback, **gocryptfs** userspace, fscrypt)
-  fürs `data/`: **app-transparent** (kein Code), deckt DB + WAL + Temp + dort
-  liegende Backups ab. Aufwand: OS-Setup + **Entsperren beim Boot**.
-- **(c) LUKS Full-Disk-Encryption** (ganze Platte): deckt zusätzlich **Logs,
-  Swap, OS** ab; ideal gegen physischen Diebstahl (s. Heim-Szenario).
-
-**Der eigentliche Hebel — Schlüssel-Ort:** nicht auf der Datenplatte. Optionen:
-Passphrase **beim Service-Start** injizieren (`systemd-ask-password`), Schlüssel
-beim Start **extern** holen (nur im RAM halten), oder **TPM** (s. u.). Trade-off:
-bricht den **unbeaufsichtigten Auto-Neustart** — bei einem Always-On-Care-System
-ein echter Betriebsnachteil.
-
-## 4. Aufwand vs. Sicherheit
-
-| Maßnahme | Aufwand | Sicherheitsgewinn |
-|---|---|---|
-| Backups off-host/-site + `age`/GPG | **niedrig** | **hoch** (häufigstes Leck) |
-| Whole-DB, Schlüssel auf gleicher Platte | mittel | **niedrig** (nur „nackte .db-Kopie") |
-| Whole-DB, Schlüssel off-disk / Start-Injektion | mittel–hoch (Ops) | mittel–hoch (echter Disk-Diebstahl) |
-| LUKS-FDE + TPM2 (Heim-PC) | mittel | **hoch** (deckt alles, löst Key-Problem) |
-| Pro-User-Feldverschlüsselung | **sehr hoch** | marginal hier, bricht Features |
-
-## 5. Empfohlenes Vorgehen (vHost), nach ROI sortiert
-
-1. **Backups verschlüsselt & off-host — sofort, größter Nutzen, kleinster Aufwand.**
-   Jedes Backup mit `age`/GPG (Public-Key); privater Schlüssel **nur offline/Heim-Host**.
-   Backups **weg vom Server**.
-2. **Live-DB verschlüsseln** (SQLCipher oder gocryptfs/LUKS).
-3. **Schlüssel vom Datenträger trennen** (Start-Injektion) — macht Stufe 2 erst wirksam.
-4. **Datensparsamkeit/Retention**: alte Verläufe automatisch löschen (Tools vorhanden) —
-   weniger Daten = weniger Schaden.
-
-## 6. Was leicht vergessen wird
-
-- **Backups liegen aktuell NEBEN der DB** auf demselben Datenträger (inkl. der
-  `…bak-*`-Dateien) → ein Disk-Dieb bekommt DB **und** Backups. Größte aktuelle
-  Schwachstelle → auslagern.
-- **WAL/-shm/-journal & SQLite-Temp** enthalten Klartext-Fragmente → spricht für
-  Whole-DB/Volume statt Feld-Ebene.
-- **Logs / journald**: Gesprächsinhalte können in App-Logs landen → Log-Level prüfen.
-- **Swap**: Schlüssel & Klartext können in den Swap geraten → **verschlüsselter Swap**.
-- **Schlüsselverlust = Datenverlust**: Für ein Care-System ist **Verfügbarkeit**
-  teils kritischer als Vertraulichkeit → **Key-Escrow/sicheres Backup des Schlüssels**.
-- **Sensibelste Daten = Notfall-Profil** (DSGVO-Gesundheitsdaten) — Hauptziel;
-  evtl. zusätzliche Feldverschlüsselung als Defense-in-Depth (nur Stufe 2).
-- **Realismus vHost**: Gegen bösartigen RZ-Betreiber (RAM-Snapshot) schützt
-  at-rest mit auto-verfügbarem Schlüssel **nicht** — ehrlich kommunizieren.
-
----
-
-## 7. Wenn der Server LOKAL (zuhause) läuft — wie ändert sich das Bild?
-
-Der Standortwechsel verschiebt das Bedrohungsmodell **überwiegend zugunsten der
-Sicherheit**:
-
-### 7.1 Der schwierigste Gegner verschwindet
-Kein Rechenzentrums-Betreiber/Hypervisor mehr, der RAM **und** Disk snapshotten
-kann. Du kontrollierst die physische Hardware → **at-rest-Verschlüsselung liefert
-nahezu ihren vollen Wert.** Wichtigste Änderung.
-
-### 7.2 Neuer Hauptgegner: physischer Diebstahl / Einbruch
-Vorher abstrakt, jetzt konkret: Einbruch, Mitnahme von Rechner/Platten, Reparatur-/
-Besuchszugriff, Platten-Entsorgung. **LUKS-Full-Disk-Encryption** ist dagegen das
-natürliche, starke Mittel: gestohlener Heim-PC mit LUKS = Briefbeschwerer.
-
-### 7.3 Schlüsselmanagement wird einfacher UND besser: TPM
-Ein echter Heim-PC hat meist ein **TPM 2.0** (der vHost nicht). LUKS an das TPM
-binden →
-- entsperrt **automatisch, nur auf genau dieser Maschine** (kein Key auf Platte,
-  keine manuelle Eingabe) → **unbeaufsichtigter Neustart** funktioniert wieder;
-- **Platte ausbauen & woanders auslesen** scheitert;
-- **Trade-off:** ganze Maschine gestohlen **und eingeschaltet** → TPM entsperrt.
-  Wer das abdecken will: **TPM + PIN** (wieder Eingabe nötig — Verfügbarkeit vs.
-  Diebstahlschutz).
-
-→ Zuhause empfohlene Primärmaßnahme: **LUKS-FDE mit TPM2-Auto-Unlock (optional +PIN)**
-— deckt **alles** ab (DB, WAL, Logs, Swap, Temp), OS-nativ, löst zugleich das
-Schlüssel-/Neustart-Problem.
-
-### 7.4 Backups: aus „off-host" wird „off-SITE"
-Zweites Laufwerk im selben Raum nützt wenig — Einbruch/Brand nimmt alles mit.
-→ **verschlüsselte Off-Site-Backups** (`age`/GPG, Schlüssel getrennt) an einen
-zweiten Ort. Deckt Vertraulichkeit **und** Disaster-Recovery (Totalverlust) ab.
-
-### 7.5 Was zuhause schwieriger wird / auf dich übergeht
-- **Physische Sicherheit**: abschließbarer Raum, gesperrter Bildschirm,
-  Haushalts-/Gästevertrauen.
-- **Verfügbarkeit**: kein redundanter Strom/Kühlung/Remote-Hands → **USV** (auch
-  gegen DB-Korruption bei Stromausfall).
-- **Netzwerk-/Live-Kompromittierung kann GRÖSSER werden**: Heim-LAN heterogen
-  (IoT, schwache Segmentierung). Ist der Server **internet-exponiert**, kann ein
-  gekapertes Gerät seitlich angreifen. **Verschlüsselung hilft hier nicht** →
-  Netz-Härtung: möglichst **nur per VPN/Tunnel**, Reverse-Proxy, fail2ban,
-  minimale Ports, SSO behalten, **eigenes VLAN** weg von IoT.
-- **Platten-Entsorgung** wird durch FDE unkritisch.
-
-### 7.6 Unverändert
-- **Whole-DB schlägt weiter Pro-User.**
-- **Live-Kompromittierung** bleibt der Fall, den Verschlüsselung **nicht** abdeckt —
-  durch mögliche Heim-Internet-Exposition evtl. das **dominante** Restrisiko →
-  Netz-Härtung mindestens so ernst nehmen wie Verschlüsselung.
-
-## 8. Fazit
-
-- **Whole-DB-Verschlüsselung reicht**; pro User lohnt sich nicht.
-- **vHost:** Fokus auf (1) verschlüsselte Off-Host-Backups, (2) Live-DB
-  (SQLCipher/Volume), (3) Schlüssel vom Datenträger trennen.
-- **Heim-Server (besser & einfacher):** **LUKS-FDE + TPM2 (optional +PIN)** +
-  **verschlüsselte Off-Site-Backups** + **Netz-Härtung gegen Live-Angriffe** +
-  **physische Sicherheit & USV**. Der TPM löst zugleich Verschlüsselung und das
-  Schlüssel-/Neustart-Dilemma.
-
-### Offene Entscheidung
-Soll der Heim-Server **internet-exponiert** oder **nur per VPN/Tunnel** erreichbar
-sein? Davon hängt das Gewicht des Live-Kompromittierungs-Risikos ab — der einzige
-große Punkt, den Verschlüsselung nicht abdeckt.