Dokumentation aktualisiert, CHANGELOG ergänzt, Version 0.2.0

- CHANGELOG.md neu (0.1.0, 0.2.0)
- Bedienungsanleitung: LLM-Korrektur in Überblick, Voraussetzungen, Installation, Deinstallation
- Entwicklerdoku: Output-Klasse, STT_LLM_*-Konfiguration, Nebenläufigkeitsregel für Ausgaben,
  Erweitern (LLM/Prompt), Grenzen und nächste Schritte
- README, CLAUDE.md: Verweise und Befehle ergänzt
- stt_core.__version__ = 0.2.0

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

docs/API.md

@@ -103,7 +103,7 @@ curl http://127.0.0.1:9998/health
   "load_seconds": 2.34,
   "wyoming_port": 10300,
   "error": null,
-  "version": "0.1.0"
+  "version": "0.2.0"
 }
 ```
 

docs/ENTWICKLER.md

@@ -32,6 +32,7 @@ Für Programmierer, die den Code verstehen, ändern oder erweitern wollen. Anwen
 | **Zuverlässig** | GPU→CPU-Fallback beim Laden; Halluzinationsfilter; robustes Dekodieren beliebiger Formate; Fehler einzelner Anfragen beenden keine Verbindung |
 | **Vielseitig anbindbar** | eine Engine, mehrere Schnittstellen: OpenAI-HTTP, Roh-HTTP, WebSocket, Wyoming, CLI |
 | **Testbar** | reine Logik ohne I/O im Kern; App-Fabrik mit injizierbarer Engine und VAD |
+| **Zusätze getrennt halten** | LLM-Korrektur nur optional in der CLI; Kern, Dienst und Wyoming bleiben davon unberührt |
 | **Gegenstück zu chatterbox-tts-cli** | gleiche Bauart: Kernmodul + FastAPI-Dienst + CLI + systemd-User-Unit |
 
 Das Projekt ersetzt das alte Einzelskript `legacy/stt.py`. Dessen Schwächen — Stoppwort-Erkennung in
@@ -345,6 +346,7 @@ Port `0` ist in Tests erlaubt (freien Port über `server._server.sockets[0]` erm
 | Funktion | Aufgabe |
 |---|---|
 | `main` | Argumente, Modus-Auswahl, Fehler → Exit-Code, Hinweis bei nicht erreichbarem Dienst |
+| `Output` | einzige Ausgabestelle: `put()` gibt direkt aus oder reicht an die LLM-Korrektur (eigener Thread, Reihenfolge bleibt); `warmup()` lädt das LLM vorab; `close()` wartet auf ausstehende Korrekturen |
 | `service_file` | `POST /transcribe` mit Datei als Body (Streaming-Upload über `requests`) |
 | `service_mic` | Mikrofon → `/ws/stream` (synchroner `websockets`-Client, Empfänger-Thread) |
 | `local_files` / `local_mic` | wie oben, aber `SttEngine` + `UtteranceSegmenter` im Prozess; Inferenz im `ThreadPoolExecutor(1)` |
@@ -364,8 +366,6 @@ ReSpeaker-Erkennung (→ Kanal 1).
 **Ausgabevertrag:** stdout nur Ergebnisse (Text oder JSON-Zeile), stderr alles andere.
 Exit-Codes `0/1/2/130` (siehe Bedienungsanleitung).
 
----
-
 ### LLM-Nachkorrektur (`stt_llm.py`)
 
 Optionaler Zusatz, bewusst **außerhalb** von Kern und Dienst: Smarthome-, ESP32- und Wyoming-Pfade bleiben
@@ -414,6 +414,8 @@ Prompt mit Tags und Beispielen):
 
 Das erste Laden eines Modells dauert 35–75 s; `Output.warmup()` stößt es im Mikrofon-Modus sofort an.
 
+---
+
 ## 8. Nebenläufigkeit — die wichtigsten Regeln
 
 1. **Nie** `engine.transcribe` (oder anderes Blockierendes) direkt in einer `async`-Funktion aufrufen —
@@ -423,7 +425,9 @@ Das erste Laden eines Modells dauert 35–75 s; `Output.warmup()` stößt es im
 4. `SttEngine` ist thread-sicher (`_load_lock`, `_run_lock`), aber der Dienst verlässt sich zusätzlich
    auf den Ein-Thread-Worker für die Warteschlangenlogik.
 5. `UtteranceSegmenter` und `StreamResampler` sind **nicht** thread-sicher — eine Instanz pro Stream.
-6. Silero-VAD läuft im Event-Loop (gemessen ≈ 0,4 ms Rechenzeit pro 100 ms Audio). Bei sehr vielen gleichzeitigen
+6. In der CLI nur über `Output.put` ausgeben — nie `print` aus Empfänger- oder Callback-Threads, sonst
+   geraten LLM-korrigierte und direkte Ausgaben durcheinander.
+7. Silero-VAD läuft im Event-Loop (gemessen ≈ 0,4 ms Rechenzeit pro 100 ms Audio). Bei sehr vielen gleichzeitigen
    Streams wäre das der erste Kandidat für einen eigenen Thread.
 
 ---
@@ -439,6 +443,7 @@ Stellen:
 | `stt_core.EngineConfig.from_env` | `STT_MODEL`, `STT_DEVICE`, `STT_COMPUTE_TYPE`, `STT_DEVICE_INDEX`, `STT_CPU_MODEL`, `STT_CPU_THREADS`, `STT_LANGUAGE`, `STT_BEAM_SIZE`, `STT_INITIAL_PROMPT`, `STT_DOWNLOAD_ROOT` |
 | `stt_core.VadConfig.from_env` | `STT_VAD_THRESHOLD`, `STT_VAD_MIN_SPEECH_MS`, `STT_VAD_SILENCE_MS`, `STT_VAD_PRE_ROLL_MS`, `STT_VAD_MAX_UTTERANCE_S` |
 | `stt_service.ServiceSettings.from_env` | `STT_MAX_QUEUE`, `STT_MAX_UPLOAD_MB`, `STT_PRELOAD`, `STT_WYOMING_HOST`, `STT_WYOMING_PORT` |
+| `stt_llm.LlmConfig.from_env` | `STT_LLM_URL`, `STT_LLM_MODEL`, `STT_LLM_API`, `STT_LLM_TIMEOUT`, `STT_LLM_KEEP_ALIVE`, `STT_LLM_NUM_CTX`, `STT_LLM_MIN_SIMILARITY` |
 
 Außerdem direkt: `STT_LOG_LEVEL`, `STT_HOST`, `STT_PORT` (`stt_service.py`), `STT_URL` (`stt_cli.py`).
 Hilfsfunktion `stt_core._env(name, default, cast)`: leere Werte gelten als „nicht gesetzt“,
@@ -546,10 +551,17 @@ Parametrisierung in `test_hallucinations_are_detected` **und** ein Gegenbeispiel
 **Andere Engine** (z. B. anderes STT-Backend) — Unterklasse von `SttEngine`, die `load` und `transcribe`
 überschreibt und ein `Transcript` liefert (`FakeEngine` zeigt das minimale Muster).
 
+**Anderes LLM oder Prompt anpassen** — Modell/Server nur per `STT_LLM_MODEL`/`STT_LLM_URL` wechseln. Vor
+einem neuen Standardmodell den Vergleich wiederholen (Fälle wie in §7 „LLM-Nachkorrektur“: echte
+Whisper-Fehler, korrekte Sätze inkl. Befehle mit Verneinung/Zahlen, eine „Anweisung“ im Diktat). Prompt-
+Änderungen in `SYSTEM_PROMPT`/`FEW_SHOT`, danach `pytest -m integration tests/test_llm.py`. Neue
+Ablehnungsregeln gehören in `_accept` und brauchen einen Test mit `ScriptedCorrector`.
+
 **Neuer Client** — gegen [docs/API.md](API.md) programmieren; `stt_cli.py` ist die Referenzimplementierung
 für Datei-Upload und WebSocket-Streaming.
 
-**Version erhöhen** — `stt_core.__version__` (wird von `/health`, FastAPI und Wyoming übernommen).
+**Version erhöhen** — `stt_core.__version__` (wird von `/health`, FastAPI und Wyoming übernommen),
+Beispiel in `docs/API.md` (`/health`) anpassen und Eintrag in `CHANGELOG.md` ergänzen.
 
 ---
 
@@ -582,6 +594,8 @@ für Datei-Upload und WebSocket-Streaming.
 - Keine Authentifizierung, kein TLS.
 - Ein Modell pro Dienstinstanz; Modellwechsel = Neustart.
 - Wyoming protokolliert Transkripttexte auf `INFO`.
+- LLM-Korrektur: ~1 s pro Text, erstes Laden 35–75 s, ~10 GB Grafikspeicher; stark verstümmelte Sätze
+  werden oft nicht sinnvoll repariert. Nur in der CLI verfügbar.
 - Die Mikrofonpfade der CLI sind mit synthetischer Sprache und Pegelmessung getestet, der WebSocket-Pfad
   mit echter Sprache in Echtzeit-Simulation — nicht automatisiert mit echtem Mikrofon.
 
@@ -590,6 +604,7 @@ für Datei-Upload und WebSocket-Streaming.
 - Optionales Bearer-Token (`STT_API_TOKEN`) für HTTP/WebSocket.
 - Metriken (`/metrics` im Prometheus-Format: Latenzen, Queue, Fehler).
 - Zwischenergebnisse (partielle Transkripte) während langer Äußerungen.
+- LLM-Korrektur optional auch im Dienst anbieten (z. B. `/transcribe?correct=true`), weiterhin standardmäßig aus.
 - MCP-Adapter analog zu chatterbox-tts-cli (`mcp_adapter.py`).
 - Remote-Repository auf kitux.de (Forgejo).
 - Anbindung als STT-Provider im Voice-Assistant v3 (OpenAI-kompatibel bereits möglich).