Kanonisches Home für Spracheingabe und Transkription. Fachlich erforderlich, Ausprägung offen (`produktvision_und_produktidentitaet.md` §19.5). Interview G3 ist nicht abgeschlossen.
## 1. Anforderung
Auf dem Smartphone darf Reflexion nicht zwingend Tippen erfordern. Transkription ist eine zentrale technische Funktion.
Sie ist kein Freibrief für Cloud-Speech ohne Policy.
## 2. Egress-Klasse
Transkriptionsdienste sind eine **eigene Trust- und Policy-Zone** (`guardrails.md` §13). Ein ZDR-LLM-Endpoint legalisiert nicht denselben Audiostream oder denselben Klartext an einen Speech-Provider.
Klasse-A-Identität und unnötige Quasi-Identifikatoren gelten auch für Metadaten von Audio (Dateiname, GPS, Geräte-ID).
## 3. Offene Ausprägung
Nicht entschieden, daher kein Implementierungszwang in v0.1:
- Live vs. nachträgliche Transkription
- lokal vs. serverseitig vs. externer Speech-Dienst
- Bearbeitung vor Übernahme in den Dialog
- Sprecher-/Pausenlogik
- lange Aufnahmen
- Audio löschen nach Transkript vs. als Medium behalten
- Push-to-talk vs. Daueraufnahme
- Offline-Transkription
## 4. Leitplanken für jede spätere Wahl
- Das Transkript wird zur Originalrepräsentation des Dialogs oder zu einer klar gekennzeichneten Ableitung; die Regel muss dokumentiert werden, bevor Re-Grounding darauf aufsetzt.
- Nutzerkorrektur vor Persistenz als bevorzugte Richtung (fachlich offen, technisch vorbereiten).
- Fail Closed: kein unsicherer Cloud-Speech-Fallback.
- Journal- und Writing-Profile laufen auf Text nach Korrektur, nicht auf Roh-ASR-Fehlern als „persönlicher Stil“.
Spracheingabe bleibt offen. Davon getrennt: im Journal-Editor eingebettete Bilder und Videos sind lokale Dateien (`media_assets`), Auslieferung nur an die Session, kein Provider-Egress. EXIF bei JPEG/PNG wird gestrippt. Video-Container-Metadaten (einschließlich GPS) werden derzeit **nicht** entfernt.
Das ist keine Videoverwaltung und kein Ersatz für Transkription.
