Zentraler Audio-Transkriptionsdienst

Der zentrale Dienst verarbeitet Audio mehrerer lokaler Projekte über einen privaten Unix-Domain-Socket. Es gibt keinen TCP-Listener, keine Uberspace-Webroute und keine OAuth- oder HTTP-MCP-Veröffentlichung. Der externe OAuth-MCP bleibt ausdrücklich ein separater Folgelauf.

Verifizierter Betrieb

GET /healthz liefert knappe Liveness. GET /readyz meldet ausschließlich redigierte Prüffelder für Config, Key-Präsenz, FFmpeg, FFprobe, Datenbank und Workerlimit. POST /v1/transcriptions nimmt Multipart-Originalaudio an. GET /v1/transcriptions/{requester}/{request_id} reconciled denselben logischen Auftrag nach einer unklaren Transportunterbrechung.

Sicherheits- und Dispatchvertrag

• Erlaubt sind OGG/Opus, MP3, M4A, WAV, FLAC und WebM; Dateiname und MIME gelten nicht als Beweis.
• /usr/bin/ffprobe muss genau einen Audiostream und keinen Video- oder Zusatzstream bestätigen.
• /usr/bin/ffmpeg normalisiert zentral zu MP3, mono, 16 kHz und 48 kbit/s.
• Eine ASGI-Grenze verwirft deklarierte sowie chunked Requests oberhalb der Audiogrenze plus 1 MiB Multipart-Toleranz bereits vor Starlette-Spooling. Die eigentliche Audiodateigrenze bleibt zusätzlich wirksam.
• Original, Normalform, Dauer, Prozessausgabe, Providerantwort, Laufzeit und Upload sind hart begrenzt. Providerantworten werden gestreamt, optionales Content-Length und tatsächlich gelesene Chunks werden geprüft; akzeptiert wird nur JSON mit nichtleerem Textfeld.
• Pro Auftrag existiert ein privates 0700-Arbeitsverzeichnis; Dateien sind 0600 und werden deterministisch entfernt.
• (requester, request_id) ist eindeutig. Daraus entstehen opake stabile Idempotency-Key- und X-Client-Request-Id-Header; der rohe Requester verlässt den Account nicht.
• queued und normalizing werden bei Restart oder Cancellation terminal not_dispatched und fallback-sicher. Ab provider_inflight gilt terminal unknown, nicht fallback-sicher und ohne automatischen Zweitdispatch. Abgebrochene FFmpeg-/ffprobe-Prozessgruppen werden beendet.
• Nur Connect-, ConnectTimeout- und PoolTimeout-Fehler sowie explizite HTTP-Transienten sind begrenzt retrybar. Read-, Write- und Protokollmehrdeutigkeit ist kein sicherer Retry.

Strukturierte Antworten tragen dispatch_state und fallback_safe. Transkript, Audio, Key, Providerrohantwort und rohe Exceptiontexte erscheinen weder in allgemeinen Logs noch in Fehlerantworten. Config-Parsing und -Validierung enden content-free; der Key muss getrimmt, längenbegrenzt und frei von CR, LF und NUL sein. Unerwartete Laufzeit- oder Cleanupfehler terminalisieren abhängig von der Dispatchphase konservativ und erlauben keinen zweiten Provideraufruf.

Fertige Transkripte bleiben zur privaten Reconciliation höchstens 24 Stunden in SQLite. Ein privater Lifecycle-Task löscht abgelaufene Einträge spätestens im begrenzten periodischen Intervall und wird beim Shutdown sauber beendet; zusätzlich läuft Cleanup beim Start. Diese Datenschutzentscheidung ermöglicht Reconciliation, ohne Ergebnisse unbegrenzt aufzubewahren.

Lokale CLI und stdio-MCP

/home/wpmcp/codex-projects/transcription-service/.venv/bin/transcription-service --config /home/wpmcp/codex-projects/transcription-service/config.json transcribe --requester local.example /pfad/audio.ogg
TRANSCRIPTION_SERVICE_CONFIG=/home/wpmcp/codex-projects/transcription-service/config.json /home/wpmcp/codex-projects/transcription-service/.venv/bin/transcription-service-mcp

Das lokale no-auth stdio-MCP liest ausschließlich newline-delimited JSON-RPC von stdin und schreibt Protokollantworten nach stdout. Es stellt audio_transcription__transcribe für reguläre nicht verlinkte lokale Dateien und audio_transcription__status für kompakten redigierten Status bereit. Diagnose geht nur redigiert nach stderr. initialize, tools/list und beide tools/call-Wege sind getestet.

QA und Rollback

Die Dienstsuite umfasst 30 Tests für reale FFmpeg-/ffprobe-Verarbeitung, Parallelitäts- und Queuegrenze, vorgezogene Requestgrenzen, Idempotenz und Providerkorrelation, Reconciliation, alle Restart-/Cancellationphasen, periodische Retention, Configredaktion, deterministischen Cleanup, Streaming-Responsegrenzen, Provider-Connect-Sicherheit, Read-/Write-Mehrdeutigkeit, MCP und realen Socketmode. Eine erste synthetische Probe im Härtungslauf deckte eine zu enge Provider-Metadatenvalidierung auf; nach dem fokussierten Fix war die einmalige Verifikationsprobe erfolgreich (21 Zeichen, Modell gpt-transcribe). Kein Transkript oder Key wurde ausgegeben. Stop/Start des Dienstes ist der betriebliche Rückweg; der Channel Manager verwendet bei nachweislicher Nichterreichbarkeit seinen unveränderten lokalen Fallback.