# Work Log - Trixy Voice Assistant

Protokoll der abgeschlossenen Arbeiten. Kurze Referenz - Details in Ticket-System.

## Format

- Datum (YYYY-MM-DD)
- Ticket-ID (falls vorhanden)
- Kurze Beschreibung
- Status
- Notizen

---

## 2026-03-15 — Installer Build-System mit TUI

**Status:** Abgeschlossen

**Beschreibung:**
Professionelles Installer-System mit Textual-basierter TUI. Baut Installer fuer 4 Modi (server/client/standalone/config) als .tar.gz Pakete. Eigenstaendiges Projekt ohne trixy_core-Import.

**Neue Dateien:**
- `make_installer/common.sh` — Gemeinsame Build-Funktionen (Version parsen, tar erstellen, install.sh generieren)
- `make_installer/make_installer_{server,client,standalone,config}.sh` — 4 modus-spezifische Build-Scripts
- `make_installer/exclude_patterns.txt` — tar-Excludes (Trainings-/Modelldaten, Cache, Tests)
- `make_installer/installer/app.py` — InstallerApp(textual.App) mit F-Key-Navigation
- `make_installer/installer/config.py` — InstallerConfig Dataclass mit Validierung
- `make_installer/installer/steps.py` — Gewichtete InstallationStep-Definitionen pro Modus
- `make_installer/installer/runner.py` — InstallRunner mit async Subprocess, Progress, Abbruch
- `make_installer/installer/menu_context.py` — Standalone-Kopie von trixy_core MenuContext/MenuBinding
- `make_installer/installer/views/{system,network,plugins,requirements,agreement,install}_view.py` — 6 Tab-Views (F1-F6)
- `make_installer/installer/widgets/{header,footer,log_field}.py` — TUI-Widgets
- `make_installer/installer/css/installer.tcss` — TUI-Styling
- `make_installer/installer/{agreement.md,plugins.json,requirements.txt}` — Ressourcen

**Build-Output pro Modus:**
- `trixy-{mode}-{version}.tar.gz` — Quellcode (Server: 375M, Client: 132M, Config: 512K)
- `trixy-installer-{mode}-{version}.tar.gz` — Installer TUI (15K)
- `install-{mode}.sh` — Bootstrap-Script (3K)

**Notizen:**
- tar-Excludes: trainer/assets (17GB), models/*.onnx/pth/pt/bin/gguf, plugins/*/models, __pycache__, tests
- install.sh: Prueft Python >= 3.10, erstellt temporaeres venv fuer textual/rich, startet TUI
- 9 Server-Schritte (Gewicht=100): extract, apt, hostname, wifi_ap, venv, plugin_deps, dirs, systemd, verify

---

## 2026-03-06 — Plugin-basiertes Trainer-Framework

**Status:** Abgeschlossen

**Beschreibung:**
Einheitliches ML-Trainer-Framework mit ITrainer ABC, TrainerRegistry (Core + Plugin Discovery), TrainerService (multiprocessing.Process mit Queue-Polling), 18 Netzwerk-Commands (9 Request/Response-Paare), 9 ConfigListener-Handler, ConfigConnection-API (9 Methoden), LossChart-Widget (Braille U+2800-U+28FF, Bresenham-Linien, Downsampling), 7 TUI-Views (Trainer-Liste + 6 Sub-Navigation: Info/Settings/Dataset/Optional/Validate/Training).

**Neue Dateien:**
- `trixy_core/trainer/__init__.py` — Package-Init mit Exports (inkl. TrainerApplication-Migration)
- `trixy_core/trainer/enums.py` — TrainingState (IDLE→FAILED), TrainerType (CORE/PLUGIN)
- `trixy_core/trainer/dataclasses.py` — TrainerInfo, TrainingProgress, ValidationResult, FormSchema
- `trixy_core/trainer/itrainer.py` — ITrainer ABC mit Schema/Train/Validate-Methoden
- `trixy_core/trainer/registry.py` — Discovery aus core/*.py + plugins/*/trainer.py
- `trixy_core/trainer/service.py` — TrainerService(IService) mit Subprocess-Training
- `trixy_core/trainer/application.py` — TrainerApplication (migriert aus trainer.py)
- `trixy_core/trainer/core/__init__.py` — Core-Trainer Package
- `trixy_core/trainer/core/wakeword_trainer.py` — PoC WakewordTrainer mit Settings/Dataset-Schema
- `trixy_core/tui/widgets/loss_chart.py` — Braille-Loss-Chart (Train=cyan, Val=magenta)
- `trixy_core/tui/css/trainer.tcss` — Trainer-Styles
- `trixy_core/tui/views/trainer_view.py` — F7 Trainer-Liste (DataTable)
- `trixy_core/tui/views/trainer_info_view.py` — F1 TrainerInfo (StatusTable)
- `trixy_core/tui/views/trainer_settings_view.py` — F2 Schema-basiertes Formular
- `trixy_core/tui/views/trainer_dataset_view.py` — F3 Dataset-Info + Formular
- `trixy_core/tui/views/trainer_optional_view.py` — F4 Optionale Daten (ausblendbar)
- `trixy_core/tui/views/trainer_validate_view.py` — F5 Validierung + GPU-Info
- `trixy_core/tui/views/trainer_training_view.py` — F6 Start/Pause/Stop/Resume + LossChart

**Geaenderte Dateien:**
- `trixy_core/network/cmd/config_cmd.py` — 18 neue Trainer-Command-Dataclasses
- `trixy_core/network/cmd/__init__.py` — Import + Export der Trainer-Commands
- `trixy_core/network/config_listener.py` — 9 Trainer-Handler + Imports
- `trixy_core/server.py` — TrainerService instanziiert und registriert
- `trixy_core/config_app.py` — 9 Trainer-API-Methoden, Trainer-Views-Setup
- `trixy_core/tui/app.py` — Trainer-Kontext (TRAINER_SUBVIEW_IDS, F7, Sub-Navigation)

---

## 2026-03-07 — Wakeword Trainer v3: Erweiterte Augmentation + Background-Mix

**Status:** Abgeschlossen

**Beschreibung:**
Wakeword-Trainer v3 mit umfassender Audio-Augmentation nach OpenWakeWord-Vorbild (data.py). Komma-separierte Wakeword-Aliase, Pitch-Shifting, Klangfarbe-/Prosodie-Variation (Piper noise_scale/noise_w_scale), Lautstaerke-Variation, Rausch-Augmentation (white/pink/brown), Background-Mix mit Musik aus assets/ (ffmpeg-Konvertierung in Temp-Dateien), TTS-Engine-Discovery.

**Neue Features (gegenueber v2):**
- Komma-separierte Aliase: "Hey Trixy, Trixy, Hallo Trixy, Servus Trixy"
- Pitch-Shifting per Resampling-Trick (±N Halbtoene)
- Piper noise_scale → Klangfarbe/Timbre-Variation
- Piper noise_w_scale → Prosodie/Rhythmus-Variation
- Lautstaerke-Variation (30%-100%)
- Rausch-Augmentation: white/pink/brown Noise bei 15-30 dB SNR
- Background-Mix: Musik aus assets/*/music/ wird per ffmpeg auf 16kHz/16-bit/mono konvertiert, dann mit positiven Samples bei 5-20 dB SNR gemischt
- TTS-Engine-Discovery: Piper-Modelle + Plugin-TTS-Modelle auflisten
- 60 deutsche Negativ-Saetze (erweitert von 40)

**Geaenderte Dateien:**
- `trixy_core/trainer/core/wakeword_trainer.py` — v3: Alle Augmentations, Background-Mix, Engine-Discovery

---

## 2026-03-06 — Wakeword Trainer (OpenWakeWord + TTS-Datengenerierung)

**Status:** Superseded by v3 (2026-03-07)

**Beschreibung:**
Realer Wakeword-Trainer basierend auf dem OpenWakeWord Custom-Verifier-Ansatz. Verwendet OWW-Preprocessor fuer Feature-Extraktion (Mel-Spectrogram + Embeddings) und scikit-learn LogisticRegression-Pipeline als Classifier. TTS-Datengenerierung via Piper TTS im F4 Optional Tab fuer synthetische Trainings-Samples.

**Architektur:**
1. Positive WAV-Clips (eigene Aufnahmen + TTS-generierte) → OWW-Feature-Extraktion
2. Negative WAV-Clips (andere Sprache) → OWW-Feature-Extraktion
3. LogisticRegression auf flattened Features → Pipeline mit StandardScaler
4. Export als pickle (.pkl) + metafile.json

**Neue Features:**
- `ITrainer.execute_action(action, params)` — Erweiterungspunkt fuer Trainer-Aktionen
- `ConfigTrainerActionRequest/Response` — Netzwerk-Commands fuer Trainer-Aktionen
- TTS-Datengenerierung (Piper TTS): Wakeword-Synthese mit Geschwindigkeitsvariation, Stille-Padding, Resampling auf 16kHz
- Negativ-Datengenerierung: 40 deutsche Alltagssaetze als TTS-Samples
- F4 Optional View: Aktions-Buttons (field_type="action") fuer "TTS-Daten generieren" und "Negativ-Daten generieren"

**Geaenderte Dateien:**
- `trixy_core/trainer/core/wakeword_trainer.py` — Komplett neu: Real OWW Training + TTS-Generierung
- `trixy_core/trainer/itrainer.py` — `execute_action()` Methode hinzugefuegt
- `trixy_core/trainer/service.py` — `execute_action()` Delegation
- `trixy_core/network/cmd/config_cmd.py` — ConfigTrainerActionRequest/Response
- `trixy_core/network/cmd/__init__.py` — Neue Command-Exports
- `trixy_core/network/config_listener.py` — `_handle_trainer_action()` Handler
- `trixy_core/config_app.py` — `execute_trainer_action()` API-Methode
- `trixy_core/tui/views/trainer_optional_view.py` — Aktions-Buttons + Status-Anzeige

---

## 2026-03-06 — Template-Formatter Erweiterung (PrintText-Port)

**Status:** Abgeschlossen

**Beschreibung:**
Template-Formatter komplett ueberarbeitet und um Features aus dem C++ PrintText-Projekt erweitert. 5-Phasen-Pipeline: Platzhalter → Math → Logic → String-Ops → Zahlenformat.

**Neue Dateien:**
- `trixy_core/utils/math_eval.py` — Recursive-Descent-Parser fuer mathematische Ausdruecke (+, -, *, /, %, ^, &, |, xor, not, nand, nor). Hex, Scientific Notation, Klammern.
- `trixy_core/utils/logic_eval.py` — Ternary-Evaluator (cond ? true : false), Else-If (::), Vergleiche (==, !=, <, >, <=, >=), Typ-Pruefung (===), Versionen, Boolean-Keywords.

**Geaenderte Dateien:**
- `trixy_core/utils/template_formatter.py` — Komplett neu: 5 Phasen, {app.*} Namespace fuer magische Klassenkonstanten, String-Ops (<upper>, <lower>, <trim>, <len>, <repeat>, <substr>, <strpos>, <replace>), Zahlenformat (<number>, <int>, <decimal>, <size>)
- `trixy_core/scheduler/service.py` — application + event_manager in Scheduler-Kontext injiziert
- `trixy_core/scheduler/action/tts.py` — format_template() erhaelt application fuer {app.*}

---

## 2026-03-06 — TTSSpeakAction + SchedulerService + Timing-Fixes

**Status:** Abgeschlossen

**Beschreibung:**
Neue Scheduler-Action fuer TTS-Sprachausgabe. SchedulerService in Server registriert. Timing-Bugs in IntervalTrigger/CronTrigger behoben (feuerten jede Sekunde statt konfiguriertem Intervall). TTS-Event-API korrigiert (emit→trigger mit TTSRequest). DuplicateIds in Config-Tool Schedule-Views behoben.

**Neue Dateien:**
- `trixy_core/scheduler/action/tts.py` — TTSSpeakAction mit Template-Support, Server/Standalone-Modus

**Geaenderte Dateien:**
- `trixy_core/scheduler/scheduler.py` — TTSSpeakAction registriert, last_fire_time in TriggerContext
- `trixy_core/scheduler/trigger/cron.py` — Doppel-Ausfuehrung in gleicher Sekunde verhindert
- `trixy_core/scheduler/service.py` — IService-konform (start/stop, Dependencies, application)
- `trixy_core/server.py` — SchedulerService registriert
- `trixy_core/tui/views/schedule_trigger_view.py` — Container-Replace statt remove_children()
- `trixy_core/tui/views/schedule_action_view.py` — Container-Replace (3 Stellen)
- `trixy_core/tui/views/schedule_condition_view.py` — Container-Replace (2 Stellen)

---

## 2026-03-05 — Satellite-Config Remote-Editing + Scrolling

**Status:** Abgeschlossen

**Beschreibung:**
Satellite F4 (Konfiguration) ermoeglicht jetzt das Lesen und Schreiben der Client-Config via Server-Proxy. Der Server leitet Config-Anfragen an den Satellite weiter (request_and_wait mit Future-Korrelation). Typ-spezifische Editoren (Select, Bool-Switch, Zahlen mit Validierung) funktionieren wie beim Haupt-Config-View. Ausserdem: PageUp/PageDown scrollt ±5 Zeilen, Mausrad scrollt ±1 Zeile.

**Neue Commands:**
- `ConfigSatelliteConfigReadRequest/Response` — Config-Lese-Proxy
- `ConfigSatelliteConfigWriteRequest/Response` — Config-Schreib-Proxy

**Geaenderte Dateien:**
- `trixy_core/satellite/satellite.py` — +_pending_responses, +request_and_wait(), +resolve_pending()
- `trixy_core/network/service.py` — ClientHandler._handle_message prueft pending responses vor dispatch
- `trixy_core/client.py` — +_handle_config_read_proxy(), +_handle_config_write_proxy(), config_listener_enabled Flag
- `trixy_core/config/datasets/client.py` — +config_listener_enabled: bool
- `config/client_config.json` — config_listener_enabled: false (gleicher Rechner)
- `trixy_core/network/config_listener.py` — +_handle_satellite_config_read/write (Proxy-Handler)
- `trixy_core/config_app.py` — +request_satellite_config(), +write_satellite_config()
- `trixy_core/tui/views/sat_config_view.py` — Komplett umgebaut: Tree + ConfigEditorPanel via Proxy
- `trixy_core/tui/app.py` — PageUp/PageDown Bindings, scroll_sensitivity_y=1.0

**Notizen:**
- Config-Proxy: ConfigTool → Server → Satellite → Response → Server → ConfigTool
- Client handelt ConfigReadRequest/ConfigWriteRequest auf Command-Socket
- request_and_wait nutzt message_id Korrelation + asyncio.Future
- config_listener_enabled=false verhindert Port-Konflikt bei Server+Client auf gleichem Rechner

---

## 2026-03-05 — Typ-spezifische Config-Editoren mit Validierung

**Status:** Abgeschlossen

**Beschreibung:**
Config-View (F2) verwendet jetzt typ-spezifische Editoren statt einfachem Text-Input. Jedes Feld bekommt den passenden Editor: Select-Dropdown (Log-Level, Sample-Rate, Channels), Boolean-Switch, validiertes Zahlenfeld (Min/Max), Multi-Select (Wakeword-Modelle, STT-Layer), IP-Adressen-Validierung, Readonly fuer Dicts. Dynamische Optionen (installierte Wakeword-Modelle) werden vom Server abgefragt.

**Neue Dateien:**
- `trixy_core/tui/config/__init__.py` — Package-Init
- `trixy_core/tui/config/field_registry.py` — FieldMeta Dataclass, EditorType Enum, Registry-Builder fuer Server/Standalone/Client, Auto-Inferenz Fallback
- `trixy_core/tui/widgets/config_editors.py` — ConfigEditorPanel (dynamischer Editor mit Validierung, emittiert Submitted-Message)

**Geaenderte Dateien:**
- `trixy_core/network/cmd/config_cmd.py` — +ConfigFieldOptionsRequest, +ConfigFieldOptionsResponse
- `trixy_core/network/cmd/__init__.py` — Neue Exports
- `trixy_core/network/config_listener.py` — +_handle_field_options(), +_scan_wakeword_models(), List-Typ-Konvertierung in _handle_config_write()
- `trixy_core/config_app.py` — +request_field_options() auf ConfigConnection
- `trixy_core/tui/views/config_view.py` — Komplett umgebaut: Registry+dynamische Optionen laden, ConfigEditorPanel statt Input+Button
- `trixy_core/tui/css/config.tcss` — Neue Styles fuer #config-editor
- `trixy_core/tui/widgets/__init__.py` — +ConfigEditorPanel Export

**Notizen:**
- Server: 60 Registry-Felder, Standalone: 65, Client: 31
- Felder die nicht in der Registry sind werden per Python-Typ inferiert (bool/int/float/list/dict/str)
- Validierung: IP-Oktett 0-255, Port 1024-65535, Float-Bereiche, Integer-Bereiche
- requires_restart Flag wird im Editor-Label und bei Speichern angezeigt

---

## 2026-03-05 — F3 Satellites View + Satellite Sub-Main Views

**Status:** Abgeschlossen

**Beschreibung:**
F3-Taste im Config-Tool zeigt je nach Instanz-Typ unterschiedliche Ansichten. Bei Server-Verbindung: Satellites-Liste mit Verbindungsstatus, Buttons fuer Registrierung/Trennen/Loeschen, Auto-Update alle 10s. Selektion oeffnet Satellite Sub-Navigation mit 5 eigenen F-Tasten-Views. Bei Client/Satellite-Verbindung: SubViews direkt als Haupt-Navigation.

**Satellite Sub-Main Views:**
- F1 Info: Alias, Raum, MAC, Version, Hostname, OS, Uptime, Ping
- F2 Verbindung: 4 Socket-Streams (Command, Audio In/Out, Music) mit Status/Adresse
- F3 Konversation: Wakeword-Modell/letzte Erkennung, VoiceRec, Konversations-Status (live)
- F4 Konfiguration: Uebersicht (vorerst readonly, Verwaltung ueber Satellite-eigenes Config-Tool)
- F5 Updates: Buttons fuer Modell-Updates, Script-Update, Reboot, Assets, Plugins, Test/Diagnose

**Neue Dateien:**
- `trixy_core/tui/views/satellites_view.py` — SatellitesView (ListView, Aktions-Buttons, periodisches Refresh)
- `trixy_core/tui/views/sat_info_view.py` — Satellite F1: Allgemeine Infos
- `trixy_core/tui/views/sat_connection_view.py` — Satellite F2: Socket-Verbindungen
- `trixy_core/tui/views/sat_conversation_view.py` — Satellite F3: Wakeword/VoiceRec/Konversation
- `trixy_core/tui/views/sat_config_view.py` — Satellite F4: Client-Konfiguration
- `trixy_core/tui/views/sat_updates_view.py` — Satellite F5: Update-Buttons
- `trixy_core/tui/css/satellites.tcss` — Styles fuer Satellite-Views

**Geaenderte Dateien:**
- `trixy_core/tui/app.py` — Komplett umgebaut: Dual-Modus (Haupt vs Satellite-Kontext), F1-F5/F9/F10 kontextabhaengig, MenuContext-Wechsel im Footer
- `trixy_core/tui/menu_context.py` — Numerische Sortierung (f10 nach f9)
- `trixy_core/config_app.py` — 5 Satellite-SubViews erstellen, bedingt nach Instanz-Typ
- `trixy_core/network/cmd/config_cmd.py` — +ConfigSatelliteDetailRequest/Response (detaillierte Satellite-Infos)
- `trixy_core/network/cmd/__init__.py` — Neue Exports
- `trixy_core/network/config_listener.py` — +_handle_satellite_detail() (Info/Sockets/Conversation Daten)
- `trixy_core/config_app.py` — +request_satellite_detail() auf ConfigConnection

**Notizen:**
- Server: SatellitesView (F3) → Satellite auswählen → Sub-Navigation (F1-F5) → F10 zurueck
- Client: Satellite SubViews direkt als Haupt-Navigation (F1-F5)
- Satellite-Detail-Daten per ConfigSatelliteDetailRequest (Socket-Status, Ping, OS-Info)
- Conversation-View refresht alle 4s statt 10s fuer Live-Status

---

## 2026-03-04 — Config-Tool mit TUI-Framework und Remote-Management

**Status:** Abgeschlossen

**Beschreibung:**
Neuer `main.py config` Modus — Textual-TUI die sich per TRXI-Protokoll mit einer laufenden Server/Client/Standalone-Instanz verbindet. Alle Instanzen bekommen einen ConfigListener auf Port 2105 fuer eingehende Config-Tool-Verbindungen. F1=Health (System-Metriken, periodisch aktualisiert), F2=Config (Remote-Config lesen/schreiben), F9=Log (Platzhalter).

**Neue Dateien:**
- `trixy_core/network/cmd/config_cmd.py` — 9 CommandMessage-Dataclasses (ConfigConnect/Accepted/Denied, StatusRequest/Response, ReadRequest/Response, WriteRequest/Response)
- `trixy_core/network/config_listener.py` — ConfigClientHandler + ConfigListener IService (Port 2105, Handshake, Status/Config-Handling mit psutil)
- `trixy_core/config_app.py` — ConfigConnection (TCP+TRXI Request/Response-Korrelation) + ConfigApplication (Textual-TUI Hauptschleife)
- `trixy_core/config/datasets/config_tool.py` — ConfigToolConfig Dataclass
- `config/config_tool_config.json` — Default-Konfiguration
- `trixy_core/tui/` — Komplettes TUI-Framework:
  - `app.py` — TrixyTUI (Textual App, F-Tasten, periodisches Refresh)
  - `menu_context.py` — MenuContext + MenuBinding
  - `views/base.py` — MainView / SubMainView Basisklassen
  - `views/health_view.py` — System-Metriken mit farbigen ASCII-Balken
  - `views/config_view.py` — Config-Baum mit Inline-Editing
  - `views/log_view.py` — Platzhalter fuer Live-Logs
  - `widgets/header.py` — TrixyHeader (Titel + Verbindungsinfo)
  - `widgets/footer.py` — TrixyFooter (F-Tasten-Leiste)
  - `widgets/status_table.py` — Key-Value-Tabelle
  - `widgets/popup.py` — PopupWindow (Modal)
  - `css/base.tcss`, `health.tcss`, `config.tcss`, `popup.tcss` — Styling

**Geaenderte Dateien:**
- `main.py` — Neuer `config` Subparser + `run_config()` + Docstring aktualisiert
- `trixy_core/network/cmd/__init__.py` — 9 neue Config-Exports
- `trixy_core/config/datasets/server.py` — `config_port: int = 2105` in NetworkConfig
- `trixy_core/config/datasets/standalone.py` — `config_port: int = 2105` in StandaloneConfig
- `trixy_core/config/datasets/client.py` — `config_port: int = 2105` in ClientConfig
- `trixy_core/config/datasets/__init__.py` — ConfigToolConfig Export
- `config/server_config.json` — `"config_port": 2105` hinzugefuegt
- `config/standalone_config.json` — `"config_port": 2105` hinzugefuegt
- `trixy_core/server.py` — ConfigListener Import + Instanziierung + Service-Registrierung
- `trixy_core/standalone.py` — ConfigListener Import + Instanziierung + Service-Registrierung
- `trixy_core/client.py` — ConfigListener Import + Instanziierung + Service-Registrierung

**Abhaengigkeiten:** textual, psutil (fuer System-Metriken)

---

## 2026-02-28 — Standalone ↔ Server Datensynchronisation

**Status:** Abgeschlossen

**Beschreibung:**
Bidirektionaler Daten-Sync zwischen Standalone und Server implementiert. Standalone verbindet sich automatisch zum Server wenn WLAN verfuegbar (Probe-Loop). Daten werden per Last-Write-Wins synchronisiert. Erster Consumer: Notes-Plugin.

**Neue Dateien:**
- `trixy_core/sync/models.py` — SyncItem Dataclass
- `trixy_core/sync/store.py` — SyncStore (JSON-per-Entity Persistenz in `./sync_data/`)
- `trixy_core/sync/__init__.py` — Paket-Exports
- `trixy_core/sync/connection.py` — SyncConnection (Command-Only TCP, Port 2101)
- `trixy_core/sync/service.py` — SyncService (Standalone-seitig, Probe-Loop + periodischer Sync)
- `trixy_core/sync/handler.py` — SyncHandler (Server-seitig, SyncPush/SyncRequest Verarbeitung)
- `trixy_core/network/cmd/sync.py` — SyncPush, SyncRequest, SyncResponse, SyncAck Commands
- `plugins/notes/main.py` — NotesPlugin (create/list/search/delete Notizen per Sprache)
- `plugins/notes/config.json` — Plugin-Konfiguration

**Geaenderte Dateien:**
- `trixy_core/application.py` — `_sync_store` Feld + `sync_store` Property auf IApplication
- `trixy_core/config/datasets/standalone.py` — SyncConfig Dataclass + Feld in StandaloneConfig
- `config/standalone_config.json` — Neuer `sync` Abschnitt
- `trixy_core/standalone.py` — SyncStore + SyncService Lifecycle
- `trixy_core/server.py` — SyncStore + SyncHandler + Message-Handler Registrierung
- `trixy_core/network/cmd/__init__.py` — Sync-Commands exportiert

**Architektur:**
- Nur Command-Socket (Port 2101), keine Audio-Ports
- Handshake identisch zum Client (TRXYHELO → SatelliteConnect → SatelliteAccepted)
- SyncStore: JSON-per-Entity analog zu Scheduler (`./cron/*.json`)
- Last-Write-Wins Merge per `updated_at` ISO 8601 Vergleich
- Probe-Loop alle 30s, Sync alle 5min (konfigurierbar)

---

## 2026-03-03 — File-Logging mit ContextVar-Routing und Plugin-Schutz

**Status:** Abgeschlossen

**Beschreibung:**
Automatisches File-Logging-System implementiert mit separaten Log-Dateien pro Plugin und fuer Core-Komponenten.

**Aenderungen:**
- Neue Datei `trixy_core/utils/logging/file_router.py`: FileLogRouter-Klasse mit ContextVar-basiertem Routing, `log_as()` Context-Manager, `init_file_router()`/`shutdown_file_router()` Funktionen
- `LoggingConfig` erweitert: `file_log_level`, `plugin_timeout_seconds`, `plugin_max_failures`
- `debug.py`: `_output()` routet jetzt zusaetzlich zum FileLogRouter (in beiden Modi)
- `IApplication`: `_init_file_logging()` und `_shutdown_file_logging()` Methoden
- `ServerApplication`/`StandaloneApplication`: File-Logging in initialize()/stop() integriert
- `PluginManager`: Timeout-Schutz via `_call_plugin()` mit `asyncio.wait_for()`, Auto-Disable nach N Fehlschlaegen, alle Plugin-Lifecycle-Calls in `log_as()` gewrappt
- `EventManager`: `component_name` Feld in EventHandler, automatische Plugin-Erkennung in `register_object()`, Handler-Invocation in `log_as()` gewrappt
- Config-JSONs aktualisiert mit neuen Feldern

**Ergebnis:** `logs/core.log` fuer Core, `logs/plugins/<name>.log` pro Plugin

---

## 2026-02-27 — Keyword Intent Matcher (Pre-Filter vor LLM)

**Status:** Abgeschlossen

**Beschreibung:**
LLM-basierte Intent-Erkennung (~9s) durch Keyword-Matcher Pre-Filter ergaenzt.
Eindeutige Befehle werden jetzt in <5ms erkannt, LLM nur noch als Fallback.

**Neue Dateien:**
- `trixy_core/nlp/keyword_matcher.py` — Kern-Matcher mit Pattern-Parsing, Fuzzy-Matching, Sentiment-Analyse

**Architektur:**
- Neue Dekoratoren: `@pattern()` (stackbar), `@example()`, Signatur-basierte Slot-Erkennung
- Pattern-Syntax: `(a|b)` Pflicht, `[a|b]` optional, `{slot}` Slot, `{a|b|}` inline-optional
- Doppel-Strategie: Patterns (hochpraezise) + Example-Fuzzy-Match (Fallback)
- Sentiment: polite/neutral/rude + urgent-Erkennung ueber Floskel-Listen
- Slots werden automatisch aus Funktionssignatur erkannt (Default = optional)
- Kompilierte Patterns werden gecached, Refresh nur bei Plugin-Load/Reload
- Plugins nutzen @intent/@pattern/@example Dekoratoren direkt auf Handler-Methoden

---

## Einträge

### 2026-01-31 - TRIXY-001: Core Framework Implementation

- **Status**: Abgeschlossen
- **Beschreibung**: Komplettes Trixy Core Framework implementiert
- **Komponenten**:
  - Utils (debug, version)
  - Service Container (IService, ServiceContainer)
  - Event System (EventManager, Decorators, EventData)
  - Config System (ConfigManager, Dataclasses)
  - Network Protocol (TrixyProtocol, Encryption)
  - Satellite Management (Satellite, SatelliteManager, RegistrationManager)
  - Plugin System (TrixyPlugin, PluginManager)
  - Application Classes (Server, Client, Standalone, Trainer)
  - CLI Entry Point (main.py)
- **Dateien**: 37 Python-Dateien, 4 JSON-Configs
- **Notizen**: Alle Module getestet und verifiziert

### 2026-01-31 - TRIXY-002: Unit Test Suite

- **Status**: Abgeschlossen
- **Beschreibung**: Umfassende Unit-Tests für alle Komponenten
- **Details**:
  - 244 Tests in 8 Testdateien
  - pytest + pytest-asyncio
  - 100% Testabdeckung für Core-Funktionalität
- **Testdateien**:
  - test_utils.py (19 Tests)
  - test_service.py (25 Tests)
  - test_events.py (32 Tests)
  - test_config.py (25 Tests)
  - test_network.py (35 Tests)
  - test_satellite.py (48 Tests)
  - test_plugins.py (33 Tests)
  - test_application.py (27 Tests)
- **Notizen**: Alle Tests bestanden

### 2026-01-31 - TRIXY-003: Project Knowledge System

- **Status**: Abgeschlossen
- **Beschreibung**: Projekt-Wissensbasis eingerichtet
- **Dateien**:
  - `.claude/project-knowledge/` (7 Knowledge-Dateien)
  - `docs/project_notes/` (4 Memory-Dateien)
- **Notizen**: CLAUDE.md aktualisiert mit Memory-Protokollen

### 2026-01-31 - TRIXY-004: Enterprise Extensions Phase 1-4

- **Status**: Abgeschlossen
- **Beschreibung**: Enterprise-Grade Erweiterungen für Core-Components
- **Komponenten**:
  - **Utils Extensions**: Structured Logging, Decorators (timed, cached, retry, deprecated, validate, rate_limit), Validation, Rate-Limiting
  - **Service Extensions**: ServiceScopes (Singleton/Transient/Scoped), LazyService, Metrics, CircuitBreaker, GracefulShutdown, DependencyGraph
  - **Event Extensions**: Middleware (Logging/Timing/Validation), Throttling, Persistence, DLQ, Filtering, Batching, AsyncQueue
  - **Network Extensions**: Security (AccessController, Rate-Limiting, DDoS-Schutz), TLS (Config, Manager, CertificateGenerator), ConnectionPool
  - **Satellite Extensions**: High-Level Plugin API (SatelliteAPI, SatelliteProxy, SatelliteCollection, StreamSession)
- **Neue Dateien**: ~60 Python-Dateien
- **Notizen**: Alle Tests bestanden, imports verifiziert

### 2026-02-01 - TRIXY-005: Enterprise Extensions Phase 5

- **Status**: Abgeschlossen
- **Beschreibung**: Satellite Extensions für Enterprise-Deployments
- **Komponenten**:
  - **Groups/Zones**: SatelliteGroup, GroupConfig, Zone, ZoneManager
  - **Load-Balancing**: LoadBalancingStrategy, RoundRobinStrategy, LeastConnectionsStrategy, WeightedStrategy, LoadBalancer
  - **Failover**: FailoverManager, FailoverResult, FailoverPolicy
  - **Health-Scoring**: HealthMetrics, HealthScorer, ViolationSeverity
- **Neue Dateien**: 12 Python-Dateien
- **Tests**: 71 Tests in test_satellite_extensions.py
- **Notizen**: Zone-Truthiness-Bug behoben, alle Tests bestanden

### 2026-02-01 - TRIXY-006: Enterprise Extensions Phase 6

- **Status**: Abgeschlossen
- **Beschreibung**: Plugin Extensions für Versionierung, Dependencies, Hot-Reload und Testing
- **Komponenten**:
  - **Versioning**: SemanticVersion, VersionRange, VersionChecker, CompatibilityLevel
  - **Dependencies**: DependencyGraph, DependencyNode, DependencyResolver, CycleError
  - **Registry**: PluginManifest, PluginCapability, PluginDiscovery, PluginRegistry
  - **Hooks**: PluginHook, HookPriority, HookResult, HookHandler, HookRegistry
  - **Hot-Reload**: FileWatcher, WatchEvent, PluginHotReloader, ReloadConfig
  - **Testing**: PluginTestHarness, TestContext, MockApplication, MockEventManager, MockSatelliteManager, MockPlugin, PluginTestFixture
- **Neue Dateien**: 15 Python-Dateien
- **Tests**: 65 Tests in test_plugin_extensions.py
- **Notizen**: Alle Tests bestanden, Server startet korrekt

### 2026-02-01 - TRIXY-007: API-Dokumentation

- **Status**: Abgeschlossen
- **Beschreibung**: Vollständige API-Dokumentation für alle Core-Module
- **Dokumentations-Dateien**:
  - `docs/api/README.md` - Index mit Architektur-Übersicht
  - `docs/api/utils.md` - Debug, Logging, Decorators, Validation, Rate-Limiting
  - `docs/api/service.md` - IService, ServiceContainer, CircuitBreaker, Scopes, Metrics
  - `docs/api/events.md` - EventManager, Middleware, Throttling, Persistence, DLQ
  - `docs/api/config.md` - ConfigManager, Environment, Secrets, Migration
  - `docs/api/network.md` - TrixyProtocol, Encryption, Security, TLS, ConnectionPool
  - `docs/api/satellite.md` - Satellite, Groups, LoadBalancing, Health, Failover
  - `docs/api/plugins.md` - TrixyPlugin, Versioning, Dependencies, Hooks, Hot-Reload, Testing
- **Neue Dateien**: 8 Markdown-Dateien
- **Notizen**: Deutsche Dokumentation mit Code-Beispielen

### 2026-02-01 - TRIXY-008: Wakeword-Arbitration

- **Status**: Abgeschlossen
- **Beschreibung**: Core-Modul für Multi-Satellite Wakeword-Arbitration
- **Komponenten**:
  - **Candidate**: ArbitrationCandidate, CandidateState
  - **Window**: ArbitrationWindow, WindowConfig, WindowState (1-Sekunden-Zeitfenster)
  - **Strategies**: LoudestStrategy, ConfidenceStrategy, CombinedStrategy, ProximityStrategy
  - **Arbitrator**: WakewordArbitrator, ArbitrationConfig, ArbitrationResult
- **Neue Dateien**:
  - `trixy_core/arbitration/__init__.py`
  - `trixy_core/arbitration/candidate.py`
  - `trixy_core/arbitration/window.py`
  - `trixy_core/arbitration/arbitrator.py`
  - `trixy_core/arbitration/strategies/__init__.py`
  - `trixy_core/arbitration/strategies/base.py`
  - `trixy_core/arbitration/strategies/loudest.py`
  - `trixy_core/arbitration/strategies/confidence.py`
  - `trixy_core/arbitration/strategies/combined.py`
  - `trixy_core/arbitration/strategies/proximity.py`
- **Tests**: 42 Tests in test_arbitration.py
- **Notizen**: Austauschbare Strategien, Deadlock-freies Lock-Handling

### 2026-02-01 - TRIXY-009: Enterprise Extensions - Network & Satellite

- **Status**: Abgeschlossen
- **Beschreibung**: Zusätzliche Enterprise-Komponenten für Network und Satellite
- **Komponenten**:
  - **Network Retry**: NetworkRetry, RetryConfig, RetryStrategy (Exponential/Linear/Constant/Fibonacci/Decorrelated), @with_retry Decorator
  - **Network KeepAlive**: KeepAliveManager, KeepAliveSession, ConnectionState, RTT-Berechnung
  - **Network Compression**: Compressor ABC, ZlibCompressor, GzipCompressor, CompressionRegistry
  - **Network RPC**: CorrelationManager, PendingRequest, RequestState für Request-Response Matching
  - **Satellite Capability**: CapabilityRegistry, Capability, CapabilityInfo, CapabilityDiscovery, Probes
  - **Satellite Metrics**: SatelliteMetricsCollector, MetricsAggregator, AggregationType, TimeWindow
- **Neue Dateien**: 10 Python-Dateien, 6 Test-Dateien
- **Tests**: 188 Tests für neue Komponenten
- **Notizen**: ExtensionPoint truthiness Bug behoben

### 2026-02-01 - TRIXY-010: API-Dokumentation Update

- **Status**: Abgeschlossen
- **Beschreibung**: API-Dokumentation für neue Enterprise-Komponenten
- **Aktualisierte Dateien**:
  - `docs/api/network.md` - Retry, KeepAlive, Compression, RPC
  - `docs/api/satellite.md` - Capability Discovery, Metrics (vollständig)
  - `docs/api/README.md` - Architektur-Diagramm aktualisiert
- **Notizen**: Deutsche Dokumentation mit vollständigen Code-Beispielen

### 2026-02-01 - TRIXY-011: Wakeword Detection & Conversation System

- **Status**: Abgeschlossen
- **Beschreibung**: Vollständiges Wakeword-Detection und Conversation-Tracking System
- **Wakeword-Modul** (`trixy_core/wakeword/`):
  - `detector.py`: WakewordDetector (OpenWakeWord-Wrapper), WakewordDetection, DetectorConfig
  - `audio_buffer.py`: AudioBuffer, AudioChunk, AudioBufferPool für Aufnahmen im RAM
  - `vad.py`: VoiceActivityDetector für Sprach-/Stille-Erkennung
  - `service.py`: WakewordService (IService) mit vollständigem Workflow
- **Conversation-Modul** (`trixy_core/conversation/`):
  - `session.py`: ConversationSession mit Turn-Tracking, Follow-Ups, Timeouts
  - `manager.py`: ConversationManager (IService) für Session-Lifecycle
  - `context.py`: ConversationContext mit Scopes (Turn, Session, User, Global)
- **Network-Commands** (erweitert in `trixy_core/network/cmd/wakeword.py`):
  - WakewordDetected (mit Audio-Chunks, Wakeword-Type)
  - WakewordSelected, WakewordAbort
  - RecordingComplete, RecordingAck
  - FollowUpRequest, FollowUpResponse
  - ConversationEnd, AssistantResponse, TranscriptionResult, IntentResult
- **Workflow**:
  1. Wakeword erkannt → Pause Detection → Arbitration-Request mit Lautstärke
  2. Audio-Aufnahme im RAM während Arbitration-Warte
  3. Bei Auswahl: Aufnahme bis Silence (3s) oder Timeout (60s)
  4. Audio an Server → Verarbeitung → ggf. Rückfragen
  5. Bei Rückfragen: Neue Aufnahme, bis keine Rückfragen mehr
  6. Session beenden → Wakeword Detection fortsetzen
- **Standalone**: Immer "ausgewählt", keine Arbitration
- **Tests**: 74 Tests in test_wakeword.py und test_conversation.py
- **Notizen**: OpenWakeWord-basiert, 16kHz Mono PCM, ONNX-Support

### 2026-02-01 - TRIXY-013: Network Transport Layer

- **Status**: Abgeschlossen
- **Beschreibung**: TCP-Netzwerk-Transport-Schicht für Server-Client-Kommunikation
- **Komponenten**:
  - **NetworkService** (`trixy_core/network/service.py`):
    - TCP-Server auf 4 Ports (2101-2104)
    - ClientHandler für Command-Verbindungen mit Handshake
    - AudioStreamHandler für Audio-In/Out/Music-Streams
    - KeepAlive-Integration, Broadcast, send_to_satellite
  - **ClientConnection** (`trixy_core/network/client_connection.py`):
    - Client-seitige Verbindung mit Handshake
    - Automatische Audio-Port-Verbindung nach Accept
    - Callbacks: on_connected, on_disconnected, on_message, on_audio_out, on_music
    - get_mac_address() Hilfsfunktion
  - **MessageHandler** (`trixy_core/network/message_handler.py`):
    - Zentrales Dispatching für Nachrichten
    - EventBridge: Konvertiert Nachrichten zu Events
    - setup_default_event_bridge() mit Standard-Mappings
- **Geänderte Dateien**:
  - `trixy_core/server.py` - NetworkService Integration
  - `trixy_core/client.py` - ClientConnection statt TODO
  - `trixy_core/network/__init__.py` - Neue Exports
- **Tests**: 30 Tests in test_network_transport.py
  - Integration: Server-Client Verbindung, Handshake, Registrierung
  - Commands: Senden/Empfangen, Broadcast
  - KeepAlive: Ping/Pong-Session
  - Fehlerbehandlung: Timeout, Disconnect-Callback
- **Notizen**: Problem behoben wo Server "läuft auf Ports 2101-2104" sagte aber keine echten Socket-Verbindungen existierten

### 2026-02-01 - TRIXY-012: Scheduler-System (Cronjob)

- **Status**: Abgeschlossen
- **Beschreibung**: Flexibles Job-Scheduling-System mit Cron-ähnlicher Syntax
- **Komponenten**:
  - **Triggers** (`trixy_core/scheduler/trigger/`):
    - `CronTrigger`: Cron-Ausdrücke (*/5 * * * *, 0 9-17 * * 1-5)
    - `IntervalTrigger`: Feste Intervalle (Sekunden, Minuten, Stunden)
    - `DateTimeTrigger`: Einmaliger Zeitpunkt
    - `EventTrigger`: Reagiert auf EventManager-Events
    - `AndTrigger`, `OrTrigger`: Composite Triggers
  - **Conditions** (`trixy_core/scheduler/condition/`):
    - Zeit: `TimeRangeCondition`, `DayOfWeekCondition`, `DateRangeCondition`
    - Aktivität: `RecentActivityCondition`, `ActivityCountCondition`
    - Sensor: `SensorThresholdCondition`, `SensorChangeCondition`, `ComparisonOperator`
    - State: `StateCondition`, `BooleanCondition`, `ExistsCondition`
    - Composite: `AndCondition`, `OrCondition`, `NotCondition`, `XorCondition`
  - **Actions** (`trixy_core/scheduler/action/`):
    - `EmitEventAction`, `MultiEventAction`: Event-Emittierung
    - `CallbackAction`, `MethodAction`: Python-Funktionen
    - `CommandAction`, `ScriptAction`: Shell-Befehle/Scripts
  - **Scheduler** (`trixy_core/scheduler/scheduler.py`):
    - Job-Verwaltung mit Persistierung in `./cron/*.json`
    - Automatisches Laden/Speichern
    - Kontext-Management für Conditions
    - Event-Integration
  - **Service** (`trixy_core/scheduler/service.py`):
    - `SchedulerService` (IService) für ServiceContainer
- **Neue Dateien**: 18 Python-Dateien
- **Tests**: 66 Tests in test_scheduler.py
- **Notizen**: Jobs werden als individuelle JSON-Dateien in ./cron/*.json gespeichert

### 2026-02-01 - TRIXY-014: Event-basierte Integration

- **Status**: Abgeschlossen
- **Beschreibung**: TODOs für Event-basierte Warte-Logik implementiert
- **Komponenten**:
  - **Satellite.speak()**: Event-Manager Zugriff über Application-Referenz, löst `tts_request` Event aus
  - **Satellite.play()**: Löst `stream_start` Event aus für Audio/Musik-Wiedergabe
  - **Satellite.stop_playback()**: Löst `stream_stop` Event aus
  - **SatelliteAPI.say()**: Warte-Logik mit asyncio.Future für `tts_completed` Event
  - **WakewordService._wait_for_processing_result()**: Event-basiertes Warten für Standalone-Modus
- **Neue Event-Datenklassen** (`trixy_core/events/event_data/basic.py`):
  - `TTSRequest`: TTS-Anfrage mit request_id, satellite_id, text, voice, speed, volume
  - `TTSCompleted`: TTS-Abschluss mit success, audio_duration, error
  - `StreamStart`: Audio-Stream starten mit source, volume, stream_type
  - `StreamStop`: Audio-Stream stoppen
  - `ProcessingResult`: Verarbeitungsergebnis für Standalone-Modus
- **Geänderte Dateien**:
  - `trixy_core/satellite/satellite.py` - Application-Referenz, speak(), play(), stop_playback()
  - `trixy_core/satellite/satellite_manager.py` - Setzt Application-Referenz bei add()
  - `trixy_core/satellite/api.py` - Warte-Logik mit Future und Handler
  - `trixy_core/wakeword/service.py` - _wait_for_processing_result() implementiert
  - `trixy_core/events/event_data/basic.py` - Neue Event-Klassen
  - `trixy_core/events/event_data/__init__.py` - Neue Exports
- **Tests**: 24 Tests in test_event_integration.py
- **Notizen**: ML-Trainer TODOs bleiben (wird später implementiert)

### 2026-02-01 - TRIXY-015: Client Audio Player & Audio Processing Pipeline

- **Status**: Abgeschlossen
- **Beschreibung**: Streaming-Audio-Player für Client/Satellite und Audio-Processing-Pipeline für Plugins
- **Komponenten**:
  - **Streaming Audio Player** (`trixy_core/audio/player.py`):
    - `StreamingAudioPlayer`: Queue-basierter Audio-Player mit PyAudio
    - `AudioOutputManager`: Verwaltet TTS und Musik getrennt
    - Sofortiger Playback bei erstem Chunk, Stop-Command-Unterstützung
    - Dynamische Audio-Format-Konfiguration (Sample-Rate, Channels, Sample-Width)
  - **Audio Processing Pipeline** (`trixy_core/audio/processing/`):
    - `AudioProcessingContext`: Kontext mit Position, Track, Wakeword-Status, etc.
    - `AudioProcessor`: Abstract Base Class für Prozessoren
    - `ProcessorPriority`: Enum für Pipeline-Reihenfolge (DUCKING, CROSSFADE, VOLUME, etc.)
    - `AudioProcessingPipeline`: Thread-safe Pipeline-Manager
    - Hilfsfunktionen: `apply_volume()`, `mix_chunks()`, `fade_chunk()`
  - **Extension Point** (`trixy_core/plugins/extensions/points/audio.py`):
    - `AUDIO_PROCESSOR_POINT`: Extension Point für Audio-Prozessoren
    - `AudioProcessorExtension`: Basis-Extension für Plugins
  - **Netzwerk-Befehle** (`trixy_core/network/cmd/satellite.py`):
    - `SatelliteAccepted` erweitert um TTS/Musik Audio-Format
    - `AudioConfigUpdate`: Neue Nachricht für TTS-Plugin-Wechsel
- **Geänderte Dateien**:
  - `trixy_core/client.py` - AudioOutputManager Integration, Audio-Format-Handling
  - `trixy_core/network/client_connection.py` - Audio-Format aus SatelliteAccepted
  - `trixy_core/music/player.py` - Pipeline-Integration in Playback-Loop
  - `trixy_core/music/queue.py` - peek_next() Methode
  - `trixy_core/music/playlist/playlist.py` - peek_next() Methode
  - `trixy_core/plugins/extensions/points/__init__.py` - Audio Exports
- **Neue Dateien**:
  - `trixy_core/audio/player.py`
  - `trixy_core/audio/processing/__init__.py`
  - `trixy_core/audio/processing/context.py`
  - `trixy_core/audio/processing/processor.py`
  - `trixy_core/audio/processing/pipeline.py`
  - `trixy_core/plugins/extensions/points/audio.py`
- **Tests**:
  - 57 Tests in test_audio_player.py
  - 43 Tests in test_audio_processing.py
- **Notizen**:
  - TTS: 22050 Hz Mono (Piper Standard), Musik: 44100 Hz Stereo
  - Audio-Format wird vom Server bei Connect und Plugin-Wechsel mitgeteilt
  - Pipeline ermöglicht Plugins: Ducking, Crossfade, Equalizer, Effekte

### 2026-02-01 - TRIXY-016: Music System Tests

- **Status**: Abgeschlossen
- **Beschreibung**: Umfassende Unit-Tests für das Musik-System
- **Testbereiche**:
  - **Track & Metadata** (16 Tests): TrackMetadata, Track Datenklassen, Zustandsübergänge
  - **Audio Formate** (10 Tests): AudioFormat, AudioInfo, DecodedAudio, MP3Decoder
  - **LocalFileSource** (9 Tests): Scan, Pfad-Management, echte Musikdateien
  - **DecoderRegistry** (4 Tests): Decoder-Lookup, Extensions
  - **Streaming** (19 Tests): StreamConfig, StreamStats, StreamSession, AudioStreamer
  - **PlayQueue** (17 Tests): Queue-Management, Navigation, Play-Next
  - **Playlist** (15 Tests): Shuffle, Repeat-Modi, Navigation, peek_next
  - **Integration** (3 Tests): Scan→Queue, Scan→Playlist, Full Pipeline
  - **Performance** (3 Tests): Scan, Queue, Shuffle mit 1000 Tracks
- **Testdateien**: tests/test_music.py
- **Tests**: 100 Tests (1 übersprungen wenn kein Decoder)
- **Notizen**:
  - Tests mit echten MP3-Dateien aus assets/default/music/
  - Graceful handling wenn pydub/mutagen/ffmpeg nicht verfügbar
  - Performance-Tests bestätigen < 2s für 1000-Track-Operationen

### 2026-02-01 - TRIXY-017: Zeit-basiertes Puffer-Management

- **Status**: Abgeschlossen
- **Beschreibung**: Client-seitiges Puffer-Management mit 2-3 Sekunden Limit für Musik-Streaming
- **Änderungen**:
  - **PlayerConfig** (erweitert):
    - `max_buffer_ms`: Maximale Pufferzeit in Millisekunden (Standard: 2000ms)
    - `prebuffer_ms`: Vor-Pufferung bevor Wiedergabe startet (Standard: 200ms)
    - `__post_init__()`: Berechnet `max_queue_size` und `start_threshold` automatisch
    - `bytes_per_second` Property für Audio-Format-Berechnung
    - `buffer_ms` Property für aktuelle Queue-Kapazität in ms
  - **StreamingAudioPlayer** (erweitert):
    - `buffer_ms`: Aktuelle Pufferzeit in Millisekunden
    - `buffer_level`: Puffer-Füllstand (0.0 - 1.0)
    - `buffer_full`: True wenn Puffer >90% voll (Backpressure-Signal)
    - `buffer_low`: True wenn Puffer <20% (Nachfüll-Signal)
    - `stats` erweitert um buffer_ms, buffer_level, max_buffer_ms
  - **AudioOutputManager** (erweitert):
    - TTS: 1 Sekunde max_buffer, 50ms prebuffer (geringe Latenz)
    - Musik: 3 Sekunden max_buffer, 500ms prebuffer (User: "2-3 seconds")
    - Sample-Rate für Musik auf 48kHz geändert
    - Backpressure-Properties: music_buffer_full, music_buffer_low, music_buffer_ms
    - Methoden: can_accept_music_chunk(), can_accept_tts_chunk()
- **Geänderte Dateien**:
  - `trixy_core/audio/player.py`
  - `tests/test_audio_player.py` (17 neue Tests)
- **Tests**: 74 Tests in test_audio_player.py (vorher 57)
- **Notizen**:
  - Server-seitige StreamSession hat bereits Backpressure (feed() returns False)
  - Chunk-Cleanup passiert automatisch via queue.get() im Playback-Loop
  - Kontinuierliches Streaming mit Flow-Control durch buffer_full/buffer_low Properties

### 2026-02-01 - TRIXY-018: Crossfade-Plugin

- **Status**: Abgeschlossen
- **Beschreibung**: Plugin für nahtlose Übergänge zwischen Musik-Tracks
- **Plugin-Struktur**:
  - `plugins/crossfade/main.py` - CrossfadePlugin (TrixyPlugin)
  - `plugins/crossfade/processor.py` - CrossfadeProcessor (AudioProcessor)
  - `plugins/crossfade/config.json` - Konfiguration
  - `plugins/crossfade/tests/test_crossfade.py` - 34 Tests
  - `plugins/crossfade/tests/generate_test_mixes.py` - Demo-Generator
- **Komponenten**:
  - **CrossfadeConfig**: duration_ms, fade_curve, min_track_duration_ms, prebuffer_duration_ms
  - **CrossfadeProcessor**:
    - Integriert in AudioProcessingPipeline (Priorität: 400/CROSSFADE)
    - Erkennt Track-Ende via `context.is_near_end` und `context.has_next_track`
    - Pre-buffert nächsten Track (6 Sekunden Standard)
    - Mischt Chunks mit `mix_chunks()` Hilfsfunktion
    - Fade-Kurven: linear, cosine, exponential
    - Nur Crossfade wenn nächster Track vorhanden
  - **Standalone-Funktionen**:
    - `crossfade_audio()`: Mischt zwei Audio-Bytestreams
    - `save_wav()`: Speichert PCM als WAV
    - `load_wav()`: Lädt WAV-Datei
- **Test-Audio-Dateien** (in `assets/default/music/crossfade_tests/`):
  - `frequency_crossfade_*.wav` - Sinuswellen mit verschiedenen Kurven
  - `duration_crossfade_*.wav` - Verschiedene Crossfade-Dauern
  - `sweep_crossfade.wav` - Frequenz-Sweeps
  - `beat_crossfade.wav` - Beat-Übergänge
  - `chain_crossfade_4_tracks.wav` - 4-Track Demo-Mix
- **Tests**: 34 Tests (29 passed, 5 skipped ohne ffmpeg)
- **Notizen**:
  - Für MP3-Tests: ffmpeg/ffprobe installieren
  - Generator-Script: `python plugins/crossfade/tests/generate_test_mixes.py`
  - Mit echten Musikdateien: `--with-music` Flag (erfordert ffmpeg)

### 2026-02-01 - TRIXY-019: Asset-Manager

- **Status**: Abgeschlossen
- **Beschreibung**: Profil-basiertes Asset-Management-System für Trixy
- **Komponenten**:
  - **AssetManager** (`trixy_core/assets/manager.py`):
    - Pfad-Auflösung mit Profil-Fallback auf "default"
    - Asset-Typ-Erkennung (Audio, Music, Image, Video, Config, Data, Model)
    - LRU-Cache mit konfigurierbarem TTL für Performance
    - Thread-safe Implementierung
    - Statistik-Funktionen und Asset-Listing
    - Profil-Wechsel mit automatischer Cache-Invalidierung
    - Asset-Kopieren zwischen Profilen
  - **AssetService** (`trixy_core/assets/service.py`):
    - IService-Implementation für ServiceContainer
    - ServicePriority.CRITICAL für frühen Start
    - Delegierte Methoden für einfachen Zugriff
    - Konfiguration aus Application.config (assets_directory, profile)
  - **AssetInfo**: Detaillierte Asset-Metadaten (Pfad, Größe, Typ, Checksum, MIME)
  - **AssetType**: Enum für Asset-Kategorisierung
  - **AssetNotFoundError**: Spezifische Exception mit Suchpfad-Details
- **Features**:
  - `manager.get("audio/success.wav")` → Sucht in Profil, Fallback auf Default
  - `manager.get_audio("success.wav")` → Typ-spezifischer Zugriff
  - `manager.list_assets(AssetType.AUDIO)` → Alle Audio-Assets
  - `manager.get_stats()` → Statistiken über alle Assets
  - `manager.copy_to_profile("audio/error.wav")` → Asset in Profil kopieren
- **Neue Dateien**:
  - `trixy_core/assets/__init__.py`
  - `trixy_core/assets/manager.py`
  - `trixy_core/assets/service.py`
  - `tests/test_assets.py`
- **Tests**: 72 Tests in test_assets.py
- **Notizen**: Profil "default" wird immer als Fallback verwendet

### 2026-02-01 - TRIXY-020: NLP Plugin System

- **Status**: Abgeschlossen
- **Beschreibung**: Pluggable NLP-System für Intent-Erkennung und Antwortgenerierung
- **Komponenten**:
  - `trixy_core/nlp/` - Core NLP-Infrastruktur
    - `provider.py` - NLPProvider, NLPConfig, NLPContext, NLPResult, NLPState
    - `intent_registry.py` - IntentRegistry (Singleton), IntentDefinition, IntentSlot
    - `decorators.py` - @intent Decorator für Plugin-Methoden
    - `handler.py` - IntentReceivedData, IntentResult Datenklassen
  - `plugins/nlp_llm/` - LLM-basiertes NLP-Plugin
    - Unterstützt llama-cpp-python und Ollama Backends
    - Optimiert für Raspberry Pi 5 (4GB RAM)
    - Dual-Backend: lokal (llama-cpp) oder Server (Ollama)
  - Event-System erweitert: CreateOutputText, OutputTextCreated
  - PluginManager: Automatische Intent-Handler-Entdeckung via @intent
- **Tests**: 38 Tests in tests/test_nlp.py (alle bestanden)
- **Event-Flow**:
  1. `speech_recognized` → NLP Plugin
  2. NLP verarbeitet → `intent_received` (mit optionalem response_text)
  3. Intent-Handler ausführen
  4. Falls keine Antwort → `create_output_text` → Response Generator → TTS
- **Notizen**:
  - Empfohlene Modelle für Pi 5: Llama 3.2 1B (~800MB), Qwen2.5-0.5B (~400MB)
  - System-Prompt baut verfügbare Intents dynamisch ein

---

## Nach Woche gruppiert

### Woche 2026-01-27 bis 2026-02-01

**Abgeschlossen:**
- TRIXY-001: Core Framework Implementation
- TRIXY-002: Unit Test Suite
- TRIXY-003: Project Knowledge System
- TRIXY-004: Enterprise Extensions Phase 1-4
- TRIXY-005: Enterprise Extensions Phase 5
- TRIXY-006: Enterprise Extensions Phase 6
- TRIXY-007: API-Dokumentation
- TRIXY-008: Wakeword-Arbitration
- TRIXY-009: Enterprise Extensions - Network & Satellite
- TRIXY-010: API-Dokumentation Update
- TRIXY-011: Wakeword Detection & Conversation System
- TRIXY-012: Scheduler-System (Cronjob)
- TRIXY-013: Network Transport Layer
- TRIXY-014: Event-basierte Integration
- TRIXY-015: Client Audio Player & Audio Processing Pipeline
- TRIXY-016: Music System Tests
- TRIXY-017: Zeit-basiertes Puffer-Management
- TRIXY-018: Crossfade-Plugin
- TRIXY-019: Asset-Manager
- TRIXY-020: NLP Plugin System

### 2026-02-21 - TRIXY-021: Client Wakeword Detection

- **Status**: Abgeschlossen
- **Beschreibung**: Wakeword-Erkennung auf Client/Satellite mit Mikrofon, Audio-Streaming und Server-Arbitration
- **Neue Dateien**:
  - `trixy_core/audio/microphone.py` - MicrophoneCapture (sounddevice-basiert, 16kHz mono, 80ms Frames)
- **Geänderte Dateien**:
  - `trixy_core/config/datasets/client.py` - ClientWakewordConfig um enabled, silence_timeout, max_recording, pre_buffer erweitert
  - `trixy_core/wakeword/service.py` - DEPENDENCIES Fix, Mikrofon-Integration, Audio-Streaming via Port 2102, Future-basierte Arbitration, handle_wakeword_selected/abort/conversation_end, setup_for_client()
  - `trixy_core/client.py` - WakewordService + MicrophoneCapture Integration, Command-Routing (WakewordSelected/Abort/RecordingStop)
- **Workflow**:
  1. Mikrofon (sounddevice-Thread) → asyncio.Queue → WakewordService._audio_loop
  2. LISTENING: WakewordDetector erkennt Wakeword → PAUSED → WAITING_RESPONSE
  3. WakewordDetected Command → Server, Future wartet auf Arbitration
  4. WakewordSelected → RECORDING: Pre-Buffer + Live-Audio via Port 2102
  5. 3s Stille oder 60s Timeout → RecordingDone Command → LISTENING
  6. WakewordAbort → Buffer leeren → LISTENING
- **Notizen**: OpenWakeWord optional (graceful degradation), Keyboard-Input funktioniert weiterhin

### 2026-02-21 - TRIXY-016: Fix Arbitration-Timeout (Wakeword)

- **Status**: Abgeschlossen
- **Beschreibung**: Client erhielt sofort "Arbitration-Timeout" nach Wakeword-Erkennung
- **Ursachen** (3 Bugs):
  1. `WakewordArbitrator` wurde nie in `server.py` erstellt/gestartet → niemand hörte auf `wakeword_detected` Event
  2. Arbitrator nutzte falsche Property-Namen: `event_manager` statt `events`, `satellite_manager` statt `satellites`
  3. Arbitrator nutzte `self.logger` (Python logging) statt `pinfo/pdebug/perror/pwarn` (TUI-Output)
- **Geänderte Dateien**:
  - `trixy_core/server.py` - WakewordArbitrator erstellen, starten und stoppen
  - `trixy_core/arbitration/arbitrator.py` - Property-Namen Fix, self.logger → pinfo/pdebug/perror/pwarn, fehlender await bei emit()

### 2026-02-22 - TRIXY-022: Live-Audio-Streaming zwischen Satellites

- **Status**: Abgeschlossen
- **Beschreibung**: Live-Audio-Streaming von Satellite A (Mikrofon) zu Satellite B (Lautsprecher) für Debugging/Wartung
- **Komponenten**:
  - **EventData-Klassen**: SatelliteStreamStarted, SatelliteStreamStopped, SatelliteStreamRecordStarted, SatelliteStreamRecordStopped
  - **Satellite-Streaming**: start_stream(), stop_stream(), start_record_stream(), stop_record_stream()
  - **Handler**: _on_stream_audio_received (Audio-Weiterleitung), _on_stream_record_stopped_event (Wakeword-Stop), _on_stream_timeout
  - **Mutual Exclusion**: Recording und Streaming schließen sich gegenseitig aus
  - **Guards**: disconnect() stoppt Stream, start_recording() blockiert bei Stream
- **Architektur**: Keine neuen Network-Commands — nutzt bestehende SatelliteRecordStart/Stop. Unterscheidung rein server-seitig.
- **Audio-Pfad**: Satellite A Mikrofon → Port 2102 → Server (audio_input_received) → Socket-Write auf Satellite B audio_out (Port 2103)
- **Stop-Wege**: manual, timeout, wakeword, target_disconnect
- **Geänderte Dateien**:
  - `trixy_core/events/event_data/basic.py` — 4 neue EventData-Klassen
  - `trixy_core/events/event_data/__init__.py` — Exports erweitert
  - `trixy_core/satellite/satellite.py` — Attribute, Properties, 4 Methoden, 3 Handler, Guards
- **Tests**: 64 Tests in tests/test_satellite_streaming.py (alle bestanden)
- **Notizen**: Optional parallele WAV-Aufnahme des Streams via start_record_stream()

### 2026-02-22 — Wakeword-Audio aus STT-Input trimmen

- **Status**: Abgeschlossen
- **Beschreibung**: Wakeword-Audio (Pre-Buffer + Wakeword-Tail) wurde ungefiltert an STT gesendet → "davis spiele musik" statt "spiele musik"
- **Lösung**: Server-seitiges Trimmen im AudioAccumulatorService — erste N Sekunden (default 1.0s) werden abgeschnitten
- **Konfigurierbar**: `wakeword_trim_seconds` in WakewordConfig (0.0 = kein Trim)
- **Geänderte Dateien**: config/datasets/server.py, audio/accumulator.py, server.py
- **Tests**: 102 Tests bestanden

**In Arbeit:**
- Keine

**Blockiert:**
- Keine

---

### 2026-02-22 — Bugfix: Silence-Detection + Server-seitige Audio-Verarbeitung

**Status:** Abgeschlossen

- VAD: NO_SPEECH State + no_speech_timeout_ms (5s) — bricht ab wenn keine Sprache erkannt wird
- WakewordService: sendet jetzt RecordingComplete (statt RecordingDone) mit speech_detected, ended_by, vad_stats
- Neuer AudioAccumulatorService: sammelt gestreamte Audio-Frames pro Conversation, emittiert raw_audio_input_received bei Recording-Ende
- No-Speech → ConversationEnd an Satellite (reason="no_speech")
- Config: no_speech_timeout_seconds in ClientWakewordConfig konfigurierbar
- **Geänderte Dateien**: vad.py, wakeword/service.py, config/datasets/client.py, client.py, server.py, audio/accumulator.py (neu)

---

### 2026-02-22 — Music Plugin Phase 1 (MVP)

**Status:** Abgeschlossen

- Neues Music-Plugin (`plugins/music/`) mit YouTube-Suche (yt-dlp) und lokaler Musikbibliothek
- YouTubeSource: Suche, Download, Cache-Management, graceful degradation ohne yt-dlp
- Intent-Handler: play_music, next_track, previous_track, what_is_playing (via IntentRegistry)
- Neue System-Intents: stop, pause, resume (in system_intents.py)
- IntentDispatcher: stop/pause/resume emittieren Events; Volume-Handler auf async Events umgebaut (_handle_volume_intent entfernt)
- MusicPlayerService: music_volume_change Event-Handler (set_volume/mute/unmute)
- "Stop" aus cancel-Examples entfernt (Disambiguierung stop vs cancel)
- **Neue Dateien**: plugins/music/{config.json, __init__.py, main.py, sources/__init__.py, sources/youtube.py, tests/test_music_plugin.py}
- **Geänderte Dateien**: trixy_core/nlp/system_intents.py, trixy_core/nlp/intent_dispatcher.py, trixy_core/music/service.py
- 17 Tests, alle bestehen

---

### 2026-02-27 — STT → NLP Event-Brücke

**Status:** Abgeschlossen

- **Problem**: Nach STT-Transkription brach die Pipeline ab — NLP wurde nie aufgerufen
- **Ursache**: STT-Plugins emittierten `stt_completed` (dict via `emit()`), aber NLP-Plugin lauscht auf `speech_recognized` (EventData via `trigger()`)
- **Lösung**: Nach `stt_completed` zusätzlich `speech_recognized` Event mit `SpeechRecognized` EventData emittieren (nur bei nicht-leerem Text)
- **session_id**: Wird via `metadata["session_id"]` transportiert (SpeechRecognized hat kein eigenes session_id-Feld)
- **Geänderte Dateien**: plugins/stt_vosk/main.py, plugins/stt_whisper/main.py, plugins/stt_deepspeech/main.py
- **Tests**: py_compile OK, Event/NLP-Tests bestanden

---

### 2026-02-27 — Download-System Refactoring auf EventData-Events

**Status:** Abgeschlossen

- **Beschreibung**: Download-Events von unstrukturierten Dicts (`emit()`) auf typisierte EventData-Klassen (`trigger()`) umgestellt
- **Neue Datei**: `trixy_core/events/event_data/download.py` — 6 EventData-Klassen (BeforeDownload, DownloadProgress, DownloadCompleted, DownloadFailed, BeforeExtract, ExtractCompleted)
- **Entfernt**: `progress_callback` Parameter aus allen Download-Funktionen, `default_progress_callback()`, `DownloadProgress.callback` Feld
- **Plugin-Einfluss**: Plugins koennen Downloads jetzt redirecten, verbieten, Speicherort aendern oder eigene Extraktoren nutzen (via cancel/modify auf BeforeDownload/BeforeExtract)
- **Klasse umbenannt**: `DownloadProgress` → `DownloadProgressTracker` (Alias beibehalten fuer Kompatibilitaet)
- **Geaenderte Dateien**: trixy_core/events/event_data/download.py (neu), trixy_core/events/event_data/__init__.py, trixy_core/utils/download.py, tests/utils/test_download.py
- **Plugins benoetigen keine Aenderung**: Vosk, DeepSpeech, Piper uebergeben bereits kein progress_callback; Whisper nutzt eigenen Download-Mechanismus
- **Tests**: py_compile OK, 9 passed + 6 skipped (async ohne pytest-asyncio)

---

### 2026-02-27 — Calendar Cloud Plugin

**Status:** Abgeschlossen

- **Beschreibung**: Kalender-Anbindung an Cloud-Dienste (Microsoft Outlook, Google Calendar, CalDAV/Nextcloud) per Sprache
- **Plugin-Struktur** (`plugins/calendar/`):
  - `main.py` — CalendarPlugin (Orchestrator): Provider-Init, Sync, Notifications, Intent-Handler
  - `models.py` — CalendarEvent, CalendarInfo, NotificationRecord, EventStatus
  - `utils.py` — Datums-/Zeit-Parsing (deutsch), TTS-Formatierung
  - `providers/base.py` — CalendarProvider ABC (connect, disconnect, fetch_events, create_event, health_check)
  - `providers/microsoft.py` — Microsoft Graph API (Client Credentials + Device Code Flow, httpx + msal)
  - `providers/google.py` — Google Calendar API (Service Account + OAuth2, google-auth + google-api-python-client)
  - `providers/caldav_provider.py` — CalDAV (caldav + icalendar Libraries)
  - `mapping.py` — SatelliteCalendarMapper (Satellite ↔ Kalender per Alias/Room, globale Kalender)
  - `sync.py` — CalendarSyncManager (periodischer Sync via Scheduler, In-Memory Cache, asyncio.Lock)
  - `notifications.py` — NotificationManager (60s Check-Loop, Reminder + Start-Sounds, Quiet Hours, Duplikat-Vermeidung)
  - `intents.py` — 6 Intent-Definitionen (next/search/attendees/person/create/list appointments)
  - `config.json` — Provider-Credentials, Kalender-Definitionen, Satellite-Mapping, Sync/Notification-Optionen
- **Features**:
  - Optionale Dependencies per try/import (Plugin laeuft auch ohne spezifische Libraries)
  - Automatischer Token-Refresh bei 401 (Microsoft)
  - Retry-Logik mit Backoff beim Sync
  - Standalone-Modus: Fallback auf ersten Mapping-Eintrag, TTS via Event
  - Scheduler-Integration: IntervalTrigger + CallbackAction fuer periodischen Sync
- **Neue Dateien**: 12 Python-Dateien + config.json
- **Tests**: py_compile OK fuer alle Dateien, JSON valide
- **Notizen**: Sounds erwartet in assets/default/audio/ (calender.wav, calender_remember.wav)

---

### 2026-02-28 — Standalone-Modus Grundfunktionalitaet

**Status:** Abgeschlossen

**Beschreibung:**
Standalone-Modus (`python3 main.py standalone`) hatte keine funktionierende Audio-Pipeline — WakewordService, MicrophoneCapture und AudioOutputManager fehlten.

**Aenderungen:**
- **Bugfix** `wakeword/service.py:767`: `self.application.event_manager.emit()` → `await self._application.events.emit()`
- **Config-Fix** `config/datasets/standalone.py`: `WakewordConfig` (Server) → `ClientWakewordConfig` (hat `model_directory`, `use_onnx`, `enabled`, etc.)
- **standalone.py**: WakewordService (standalone_mode=True), MicrophoneCapture, AudioOutputManager integriert + TTS-Handler fuer lokale Wiedergabe via `tts_completed` Event

**Neue Event-Pipeline:**
Mikrofon → WakewordService → raw_audio_received → STT → speech_recognized → NLP → intent_received → IntentDispatcher → output_text_created → TTS → tts_completed → AudioOutputManager

---

### 2026-02-28 — Notes-Plugin Rewrite + Reminders-Plugin

**Status:** Abgeschlossen

**Beschreibung:**
Notes-Plugin v2.0 komplett ueberarbeitet und neues Reminders-Plugin erstellt. Dazu Standalone Follow-Up-Bruecke und Recording-Config-Override implementiert.

**Phase 1 — Infrastruktur:**
- `trixy_core/wakeword/service.py`: `recording_config_override` Event-Handler — Plugins koennen Silence-Timeout und Max-Recording temporaer aendern. Werte werden in `_complete_session()` automatisch zurueckgesetzt.
- `trixy_core/standalone.py`: `_setup_standalone_followup()` — Bruecke fuer `followup_expected` Event → WakewordService `_handle_follow_up()`. Ermoeglicht Multi-Turn-Dialoge im Standalone-Modus mit Sprachaufnahme.

**Phase 2 — Notes-Plugin v2.0 (`plugins/notes/`):**
- 11 Intents: create_note, record_note, record_note_content, list_notes, get_note_today, get_note_yesterday, get_note_by_date, play_note_audio, search_notes, delete_note, delete_all_notes, note_count
- Audio-Mitschnitt: PCM-Dateien neben JSON in `./sync_data/notes.note/{item_id}.pcm`
- Multi-Turn fuer record_note (Rueckfrage "Was moechtest du notieren?") und delete_all_notes (Rueckfrage "Bist du sicher?")
- Datumsabfragen: heute, gestern, Wochentage, DD.MM.YYYY
- Audio-Wiedergabe via tts_completed Event

**Phase 3 — Reminders-Plugin (`plugins/reminders/`):**
- 6 Intents: create_reminder, create_reminder_full, list_reminders, list_reminders_today, delete_reminder, delete_all_reminders, confirm_delete_all_reminders
- Multi-Turn-Dialog: Was? → Wann? → VM/NM-Klaerung (bis zu 3 Rueckfragen)
- Zeitparser (`time_parser.py`): "morgen", "in 2 Stunden", "naechsten Montag", "heute Abend", VM/NM-Erkennung
- Timer-Loop: Prueft alle 60s auf faellige Erinnerungen, TTS-Benachrichtigung
- Dialog-State intern im Plugin (nicht Session-abhaengig)

**Neue Dateien:**
- `plugins/notes/main.py` (Rewrite), `plugins/notes/config.json`
- `plugins/reminders/__init__.py`, `plugins/reminders/main.py`, `plugins/reminders/config.json`, `plugins/reminders/time_parser.py`

**Geaenderte Dateien:**
- `trixy_core/wakeword/service.py` — recording_config_override Event + Reset
- `trixy_core/standalone.py` — followup_expected Bridge

---

### 2026-02-28 — STT Post-Correction Service

**Status:** Abgeschlossen

**Beschreibung:**
Konfigurierbarer, mehrstufiger STT-Nachkorrektur-Service als IService. Registriert sich mit HIGH-Prioritaet auf `speech_recognized` und korrigiert Text in-place, bevor das NLP-Plugin (NORMAL-Prioritaet) ihn verarbeitet. Ersetzt die primitive `_correct_stt_text()` im NLP-Plugin.

**Architektur-Entscheidung:** Event-Prioritaet statt neues Event. STTCorrectorService nutzt EventPriority.HIGH, NLP-Plugin hat default NORMAL. Korrektur per in-place Modifikation von event_data.text.

**6 optionale Korrektur-Schichten:**
1. SymSpell — Wort-Segmentierung, Nicht-Wort-Fehler (symspellpy)
2. Phonetic — Domain-Vokabular schuetzen via Koelner Phonetik (cologne_phonetics)
3. KenLM — Kontextuelle N-Gram Kandidatenauswahl (kenlm)
4. JamSpell — Neuronaler kontextueller Spellchecker (jamspell)
5. Hunspell — Woerterbuch-basierte Korrektur (pyhunspell)
6. LanguageTool — Volle Grammatik-Korrektur (language_tool_python)

Jede Schicht graceful skip per try/import. Default-Layers: symspell, phonetic, kenlm.

**Neue Dateien:**
- `trixy_core/stt/__init__.py` — Paket-Exports
- `trixy_core/stt/corrector.py` — STTCorrectorService (IService)
- `trixy_core/stt/layers/__init__.py` — Layer-Registry
- `trixy_core/stt/layers/base.py` — CorrectionLayer ABC
- `trixy_core/stt/layers/symspell_layer.py` — SymSpell-Korrektur
- `trixy_core/stt/layers/phonetic_layer.py` — Cologne Phonetics
- `trixy_core/stt/layers/kenlm_layer.py` — KenLM N-Gram
- `trixy_core/stt/layers/jamspell_layer.py` — JamSpell Neural
- `trixy_core/stt/layers/hunspell_layer.py` — Hunspell-Woerterbuch
- `trixy_core/stt/layers/languagetool_layer.py` — LanguageTool Grammatik

**Geaenderte Dateien:**
- `trixy_core/config/datasets/server.py` — STTCorrectionConfig Dataclass + Feld in ServerConfig
- `trixy_core/config/datasets/standalone.py` — STTCorrectionConfig Import + Feld in StandaloneConfig
- `config/standalone_config.json` — `stt_correction` Abschnitt
- `config/server_config.json` — `stt_correction` Abschnitt
- `trixy_core/standalone.py` — STTCorrectorService erstellt + registriert
- `trixy_core/server.py` — STTCorrectorService erstellt + registriert

---

### 2026-03-06 — Schedule Sub-Views interaktiv gemacht

**Beschreibung:** Die 4 Schedule Sub-Views (F1-F4 im Schedule-Kontext) waren nur lesend.
Jetzt sind alle Views interaktiv mit Eingabefeldern, Typ-Auswahl und dynamischen Formularen.

**Geaenderte Dateien:**
- `trixy_core/tui/views/schedule_info_view.py` — Input-Felder fuer Name, Beschreibung, Config + Speichern-Button
- `trixy_core/tui/views/schedule_trigger_view.py` — Typ-Select + dynamische FormField-Widgets
- `trixy_core/tui/views/schedule_condition_view.py` — DataTable + Add/Remove + Edit-Bereich mit dynamischen Feldern
- `trixy_core/tui/views/schedule_action_view.py` — DataTable + Add/Remove/Hoch/Runter + Edit-Bereich
- `trixy_core/tui/app.py` — FormMeta-Laden beim Betreten des Schedule-Kontexts + save_schedule_job()
- `trixy_core/tui/css/schedule.tcss` — Styles fuer neue Formular-Elemente

---

### 2026-03-06 — TTSSpeakAction + Template-Formatter
**Status:** Abgeschlossen

Neue Scheduler-Action `TTSSpeakAction` fuer TTS-Sprachausgabe auf Satellites.
Unterstuetzt Template-Platzhalter ({date.now.hour}, {sys.hostname}, {env.USER}, etc.)
und kann an einen bestimmten Satellite oder alle verbundenen Satellites senden.

**Neue Dateien:**
- `trixy_core/utils/template_formatter.py` — Platzhalter-System mit date/sys/env/ctx-Namespaces
- `trixy_core/scheduler/action/tts.py` — TTSSpeakAction mit FormField-Definitionen

**Geaenderte Dateien:**
- `trixy_core/scheduler/action/__init__.py` — TTSSpeakAction exportiert
- `trixy_core/scheduler/scheduler.py` — In ACTION_TYPES registriert
- `trixy_core/scheduler/service.py` — satellite_manager automatisch in Kontext injiziert

---

### 2026-03-14 — Multi-Engine TTS + Voice-Morphing + Bug-Fix fuer Wakeword-Trainer
**Status:** Abgeschlossen

Wakeword-Trainer unterstuetzt nun 7 TTS-Engines statt nur Piper, plus DSP-basiertes
Voice-Morphing (8 Presets) und optionale KI-Voice-Cloning. Bug-Fix: abgehackte Enden
bei generierten Samples durch Fade-In/Out behoben.

**Neue Dateien:**
- `trixy_core/trainer/core/tts_engines/__init__.py` — Exports, get_all_engines()
- `trixy_core/trainer/core/tts_engines/base.py` — ITTSEngine ABC, TTSVoice, TTSResult
- `trixy_core/trainer/core/tts_engines/piper_engine.py` — PiperTTSEngine
- `trixy_core/trainer/core/tts_engines/gtts_engine.py` — GoogleTranslateTTSEngine
- `trixy_core/trainer/core/tts_engines/edge_engine.py` — EdgeTTSEngine (ThreadPoolExecutor)
- `trixy_core/trainer/core/tts_engines/coqui_engine.py` — CoquiTTSEngine (Thorsten)
- `trixy_core/trainer/core/tts_engines/espeak_engine.py` — EspeakTTSEngine
- `trixy_core/trainer/core/tts_engines/bark_engine.py` — BarkTTSEngine (GPU)
- `trixy_core/trainer/core/tts_engines/clone_engine.py` — VoiceCloningEngine (XTTS/YourTTS)
- `trixy_core/trainer/core/tts_engines/voice_morph.py` — DSP Voice-Morphing (VTLP + LPC + Breathiness + Jitter/Shimmer)

**Geaenderte Dateien:**
- `trixy_core/trainer/core/wakeword_trainer.py` — Engine-agnostisch, Voice-Morph, Fade-Fix
- `trixy_core/tui/views/trainer_optional_view.py` — Button-Variant, Schema-Refresh
- `install_requirements.sh` — --tts-engines Flag

---

## Tipps

- Beschreibungen kurz halten (1-2 Zeilen)
- Immer Ticket-URL angeben wenn verfügbar
- Status aktualisieren wenn blockiert
- Optional: Nach Woche oder Sprint gruppieren
- Sehr alte Einträge (3+ Monate) aufräumen