HomeIntent v7.13.1

HomeIntent 7.13.1

HomeIntent 7.13.1 sollte die offenen Fehler aus der unabhängigen Prüfung von
7.13.0 beheben. Die Nachprüfung fand jedoch verbliebene Fehler bei
zusammengesetzten Quellenbefehlen, Cover-Risiko und NLU-Latenz; diese werden
in 7.13.2 korrigiert. Der historische
Umsetzungsbericht
dokumentiert den damaligen Stand.

Korrektur vom 28. Oktober 2026: Die ursprünglichen Aussagen zum vollständig
fail-closed kompilierten Quellenverbund, zur Bestätigung aller nicht
unabhängigen Cover und zu „keiner Verschlechterung“ waren nicht belegt und
sind sachlich falsch. Die unten markierten Grenzen sind der tatsächliche
Stand von 7.13.1.

Sicherheitskorrekturen

• Kein Teilbefehl bei teilweise verstandenen Medienbefehlen.
  „Mach das Radio in der Küche aus und dann Quirlomat den Quirlomat.“
  pausierte in 7.13.0 das Radio (Gegenbeispiel des Nightly-Laufs
  40470216752).
  Der Medien-Fastpath übernimmt einen Schreibbefehl jetzt nur, wenn die neue
  Satzverbrauchsprüfung (media_coverage) jedes Wort erklärt: Operation,
  Medienziel, ein Ort, Sender-/Bibliotheksname, Wert, Warteschlange und
  Füllwörter. Rest, widersprüchliche Orte/Ziele oder Koordinationen übergeben
  den ganzen Satz an die gemeinsame Mehrbefehls-Pipeline, die alle Klauseln
  vor dem ersten Schreibzugriff kompiliert und den Satz atomar ablehnt. Das
  gilt für Pause, Play, Stop, Quelle, Lautstärke, Stumm, Titelwechsel und
  Ein/Aus. Gültige Mehrbefehle („Pausiere das Radio in der Küche und mach das
  Licht im Büro aus“) laufen vollständig – 7.13.0 verwarf deren zweite Klausel.
• Keine stillen Lücken in koordinierten Schreibsätzen. Eine leere
  koordinierte Klausel („… und dann das“), ein koordinierter Ort ohne
  geplantes Ziel („… in der Küche und im Wohnzimmer“) und ein koordiniertes
  Ziel ohne geplantes Ziel („Öffne die Rollläden im Wohnzimmer und das
  Garagentor“ – in 7.13.0 entfiel das Garagentor stumm) führen zu einer
  Ablehnung ohne Service Call.
• Garagentore und Tore sind auch beim Setzen einer Position CRITICAL.

Ehrliche Sammelergebnisse

• Licht- und Rollladen-Sammelaktionen werden vollständig vorgeprüft, dann pro
  Ziel aufgerufen. Alle angenommenen Ziele werden gemeinsam in einem
  begrenzten, ereignisbasierten Fenster (effect_wait_seconds) beobachtet;
  erst danach entsteht das unveränderliche BatchExecutionResult
  (success, failed, rejected, contrary, timeout, unverified,
  unavailable, unsupported, unauthorized, not_confirmed).
• Antwort, Audit (ein Eintrag pro Batch mit dem endgültigen Status jedes Ziels)
  und Undo entstehen aus demselben Ergebnis. Ein Gerät, das 100 ms nach dem
  Call bestätigt, gilt nicht mehr als „nicht verifiziert“; nur bestätigte
  Ziele kommen in den Undo-Plan. Keine nachträgliche, widersprechende
  Settle-Notiz mehr.

Rollläden wirklich pro Ziel

7.13.0 behauptete partielle Cover-Batches, führte sie aber nicht aus (Cover
sind MEDIUM, der Batch lief nur bei LOW). 7.13.1 modelliert die
Batch-Eignung getrennt von der Risikoklasse: Standard-Cover (shutter,
blind, shade, curtain) mit open_cover, close_cover oder
set_cover_position laufen pro Ziel und bleiben MEDIUM. Der Batch-Selektor
hielt Türen, Fenster, Klappen, Markisen, unklassifizierte
oder nicht freigegebene Cover zwar vom partiellen Pfad fern. Die
Risikoklassifizierung stufte in 7.13.1 aber nur Garage/Garagentor/Tor kritisch
ein; beispielsweise door und window blieben MEDIUM und konnten atomar,
aber ohne Bestätigung ausgeführt werden. Das ist ein Sicherheitsfehler und
wird in 7.13.2 behoben. Ab sechs Zielen galt bereits die höhere Risikostufe.

Release-Gate

scripts/release_gate.py verlangt für den exakten Release-SHA den neuesten
grünen Lauf von ci.yml und nightly-live.yml mit allen Pflichtjobs. Ein
fehlgeschlagener Sicherheits-Property-Job in irgendeinem Nightly-Lauf
desselben SHA blockiert dauerhaft. Das Gate gibt alle geprüften Run-IDs und
SHAs aus; der Release-Workflow hängt Commit- und Lauf-Links automatisch an
diesen Release-Text an, läuft global seriell und legt das Tag vor dem Release
fest auf den geprüften SHA. Mit den echten Läufen von 7.13.0 hätte das neue
Gate die Veröffentlichung blockiert.

Verhaltensänderungen

• Die beabsichtigte vollständige Ablehnung eines Play-Befehls mit Quellenwahl
  in einem zusammengesetzten Satz war in 7.13.1 nicht durchgängig wirksam.
  Die Conversation-Pipeline konnte die Quellenklausel verwerfen und die
  Operation der anderen Klausel auf eine globale Player-Menge übertragen.
  7.13.2 führt dafür klauselspezifische Bindungen ein.
• Korpus-Baseline corpus-signatures-7.13.1.json: genau eine Signatur
  ändert sich gegenüber 7.13.0. Der rohe Engine-Aufruf für
  „Schalte Garten- und Terrassenlicht ein.“ plante nur die Außenbeleuchtung
  und wird jetzt abgelehnt; über die Conversation-Pipeline (mit
  Koordinationsexpansion) werden weiterhin beide Lichter geschaltet.

Regressionstests

• tests/test_media_sentence_coverage_7131.py:
  fester Gegenbeispieltest, Varianten (und dann/danach, unbekanntes Verb,
  Ziel, Ausnahme, unvollständige Klausel, gültig/ungültig in beiden
  Reihenfolgen), positive Mehrbefehle, Metamorphie (Höflichkeit, Umstellung,
  unbekannte Zusätze) und Properties über Operationen, Quellen und Orte
• tests/test_safety_properties.py:
  REGRESSIONS enthält das Nightly-Gegenbeispiel und die weiteren Fälle
• tests/test_batch_settle_7131.py und
  tests/test_cover_batch_7131.py
• tests/test_release_gate_7131.py

Lokale Verifikation des Release-Stands

Prüfung	Ergebnis
Pytest Python 3.12 mit Coverage	10.252 bestanden, 12 übersprungen; Coverage 90 %
Pytest Python 3.13	10.252 bestanden, 12 übersprungen
Safety-Properties, CI-Profil	93 bestanden
Safety-Properties, Nightly-Profil, Seeds 7131/424242/99991	je 93 bestanden
Pyflakes, Pyright inkl. Strict-Profile	0 Befunde
Sprachgate	463 bestanden
Entwicklungsbenchmark	Entwicklung: 478 von 516 Fällen bestanden (573 Turns, 92,64 %); Held-out/OOD: 103 von 107 Fällen bestanden (126 Turns, 96,26 %); unsafe_execution_count = 0
Shadow / Arbiter / Korpus	2.131 äquivalent; 2.156 äquivalent, 5 Verhaltensänderungen (wie 7.13.0); 0 Abweichungen zur neuen Baseline
5.000-Entitäten-Benchmarks	absolute 100-ms-Budgets der damaligen CI bestanden; dennoch deutliche Regression gegenüber 7.13.0, unter anderem multi_target 4,51 → 46,61 ms und multi_clause_command 7,33 → 49,19 ms p95

Hassfest, HACS, Home-Assistant-Smoke-/Komponententests, Music-Assistant-Vertrag
und Live-Testbett laufen in der CI gegen echtes Home Assistant; die geprüften
Läufe für den exakten Release-Commit stehen im GitHub-Release.

Grenzen

Sonos, Music Assistant, Lichter und Rollläden sind gegen Home-Assistant-
Verträge, das simulierte Live-Testbett und Fakes mit Event-Bus geprüft. Echte
Hardware war nicht Teil der automatisierten Prüfung; die manuelle Testmatrix
im Umsetzungsbericht
ist ausdrücklich noch offen.

Geprüfte Freigabe

• Commit: 0f1e63d02fb97e23d626e924c62e9b3491147650
• ci.yml: Lauf 40605416517 (#530, Versuch 1, gleicher SHA)
• nightly-live.yml: Lauf 40605390788 (#44, Versuch 1, gleicher SHA)

HomeIntent v7.13.0

HomeIntent 7.13.0

HomeIntent 7.13.0 behebt den von HACS gemeldeten Event-Loop-Blocker und die
Autorisierungs- und Binding-Lücke von proactive_message. Darüber hinaus
werden die nachvollziehbaren Fälle aus Issue #38 über gemeinsame semantische
Modelle statt über Satzschablonen abgedeckt.

Änderungen

• Sämtliche HomeIntent- und Legacy-Speicherpfade werden beim Setup in einem
  Executor-Job aufgelöst und als unveränderliche Laufzeitdaten injiziert.
  Konstruktoren und Requestpfade prüfen oder migrieren keine Dateien mehr.
• Öffentliche ASK-/AUTO-Proaktivnachrichten benötigen einen authentifizierten
  Administrator. Interne Automationen verwenden einen zufälligen, widerrufbaren
  und exakt an Automation, Aktion und Zielmenge gebundenen Nachweis. Generische
  Unlock-/Disarm-Vorschläge sind gesperrt; Push-Texte nennen die echte Aktion.
• Bereiche, Bereichs- und Etagenaliase, Innen/Außen, Gesamthaushalt und
  Satellitenbereich verwenden dasselbe Place-Modell. Erkannte Orte sind harte
  Einschränkungen und werden durch zusätzliche Entitäten nicht erweitert.
• Komposita, Flexionsformen, Füllwörter, elliptische Lichtwerte und begrenzte
  LIST-Antworten werden kompositionell verarbeitet. Umgangssprachliche
  Skriptanforderungen bleiben an exakte, freigegebene Skriptnamen gebunden.
• Skriptläufe unterscheiden abgelehnt, angenommen, laufend, beendet,
  fehlgeschlagen und Zeitüberschreitung. Nur über den öffentlichen direkten
  Home-Assistant-Skriptdienst beobachtete Abschlüsse gelten als beendet.
• Unabhängige, risikoarme Licht-/Cover-Sammelaktionen werden vollständig
  vorgeprüft und pro Ziel ausgeführt. Antwort, Audit und Undo enthalten nur
  tatsächlich erfolgreiche Teilaktionen; kritische Aktionen bleiben atomar.
• Medienbefehle verwenden dasselbe Ortsmodell und die gemeldeten
  Player-Fähigkeiten. Sender werden ausschließlich aus belegten Quellen oder
  Music-Assistant-Favoriten eindeutig aufgelöst; Sonos wird ohne belegtes
  TURN_OFF pausiert oder gestoppt.

Verifikation und Grenzen

Die Release-Freigabe setzt die vollständige CI für den exakten Release-Commit
voraus: Python 3.12/3.13, Coverage, Pyright-Profile, Pyflakes, HACS, Hassfest,
Home-Assistant-Smoke-/Komponententests, Music-Assistant-Verträge, Sprach- und
OOD-Gates sowie die 5.000-Entitäten-Benchmarks. Die endgültigen Lauf-Links
stehen beim GitHub-Release.

Sonos und Music Assistant sind gegen Home-Assistant-Verträge und realistische
Fakes geprüft. Ein echter Sonos-Lautsprecher und ein echter Music-Assistant-
Server mit hörbarer Ausgabe waren nicht Teil der automatisierten Prüfung.
Mocks belegen daher keine reale Hardwarewiedergabe.

HomeIntent v7.12.0

HomeIntent 7.12.0

Automationsdialog

• Eigener typisierter, flüchtiger Slot-Draft für unvollständige zeitliche und
  solare Automationswünsche; Isolation nach Benutzer, Conversation,
  Satellit/Gerät und TTL.
• Schrittweises Füllen von Trigger, Ziel, Aktion und Wert; explizite
  Bedingungen sind typisiert, aber nicht pauschal Pflicht.
• Ziel-, Zeit- und Wertkorrekturen erzeugen eine neue Vorschau. Echte
  Entity-Mehrdeutigkeiten bleiben auf die angebotenen Kandidaten begrenzt;
  unbekannte bedeutungstragende Wörter bleiben bis zur Klärung erhalten.
  Abbruch, Ablauf, Themenwechsel, fremde oder anonyme Antworten schreiben
  nichts.
• Vollständige Entwürfe verwenden unverändert Grounding, Capability-Prüfung,
  Validator, Execution Policy, Vorschau, Bestätigung und AutomationExecutor.

Delta-History und Undo

• Schema 3 speichert bei neuen Einträgen ausschließlich Zielautomation und
  Zielmetadaten vor/nach der Änderung samt Positionen und kanonischen Digests.
• Pause/Fortsetzen verwenden atomare geordnete Mehrziel-Deltas für Ziel und
  Resume-Helper. Eine Abweichung blockiert den gesamten Undo-Vorgang.
• Fremde YAML-/Metadatenänderungen bleiben erhalten. Schema 1/2 wird nur
  beweiskräftig migriert oder fail-closed abgelehnt.
• Alte nicht unterstützte zusammengesetzte LIFO-Köpfe können ausschließlich
  von einem angemeldeten Administrator nach eigener Bestätigung verworfen
  werden; Automationen und Metadaten bleiben dabei unverändert.

Music Assistant

• Mehrere Instanzen werden über expliziten Player/Gruppenplayer, eindeutigen
  Raum, Satellitenbereich oder genau eine verfügbare Instanz aufgelöst.
• Bei Mehrdeutigkeit folgt eine benutzergebundene Player-/Raumrückfrage; Suche,
  Bestätigung und Wiedergabe bleiben auf derselben config_entry_id.
• Echte HA-Komponenten- und Service-Schemas sind automatisiert geprüft. Ein
  echter MA-Server und Audioplayer wurden nicht automatisiert gestartet; reale
  Wiedergabe wird nicht behauptet. Die manuelle Matrix steht in
  music-assistant.md.

Qualität vor Veröffentlichung

• Entwicklungsbenchmark: 471/507; Dev 365/393; Held-out 106/114; Automation
  30/38; Mehrturn 33/35; Confirmation 65/77; Clarification 26/31; No-write
  440/453. Alle Safety-Zähler sind 0.
• Zweites Korpus: 102/107; Dev 70/71; Held-out 32/36; Automation 12/14;
  Dialog 12/12; Confirmation 28/30; No-write 94/96; Safety 0.
• Korpus: 4.192 Signaturen; 4.153 gemeinsame Einträge gegenüber 7.11.0,
  0 geändert, 39 neu.
• Gesamtsuite auf Python 3.12: 10.033 bestanden, 12 übersprungen,
  0 fehlgeschlagen; 90 Prozent Coverage (53.808 Statements, 5.192 nicht
  abgedeckt). Python 3.13 ist ebenfalls grün. RuntimeWarning- und
  UnraisableException-Gates meldeten 0 Befunde.
• Vollständiges Pyright und alle vorhandenen Strict-Profile: 0 Fehler,
  0 Warnungen. Pyflakes, Exception-Inventar, Hassfest und HACS sind grün.
• Home-Assistant-Options-Flow, Stable-Smoke und Live-Testbett sowie der echte
  HA-Komponenten-/MA-Servicevertrag gegen HA 2026.4.0 und 2026.9.2 sind grün.
• Identity-Shadow: 2.131/2.131 äquivalent, Safety Drift 0. Arbiter-Shadow:
  2.157 äquivalent und vier versionierte Verhaltensänderungen, kein Safety
  Drift. Alle Runtime-/Event-Supervisionszähler blieben bei 0 Fehlern.
• Unveränderte 5.000-Entity-Budgets sind im isolierten CI-Runner grün:
  Automation-NLU 20,45 ms p95, MA-Instanzauflösung 0,296 ms p95,
  Engine-Konstruktion 37,71 ms p95 und Event-Zusammenfassung 153,5 ms p95.
  Ein lokaler Lauf unter einer Hostlast von etwa 54 auf vier CPUs war nicht
  als Performance-Gate verwertbar; die Grenzen wurden nicht angehoben.
• Der vollständige Code-RC 18a286d42bd88a174aea2ca748ad2924d7bc50e8
  ist in CI-Lauf 40173229191
  grün. Der Release-Workflow prüft zusätzlich denselben finalen SHA, den er
  taggt und veröffentlicht.

Verbleibende Grenzen

• Offene Automations-Slotentwürfe werden nicht persistiert und sind nach einem
  Neustart bewusst verworfen.
• Unvollständige wiederkehrende oder tiefer verschachtelte Formulierungen, die
  nicht sicher in den neuen Slottyp projiziert werden können, verbleiben im
  dokumentierten Compatibility-Pfad oder werden ohne Schreibplan abgelehnt.
• engine.py und event_runtime.py bleiben große Fassaden. Ihre bereits
  vorhandenen semantischen beziehungsweise Queue-/Supervisor-Module wurden
  beibehalten; in 7.12.0 wurden Dialog-Slotprojektion und Undo-Planung als neue
  eigenständige Fachgrenzen extrahiert.
• Ein echter Music-Assistant-Server und reale Audiowiedergabe sind nicht Teil
  der automatischen CI und werden nicht als getestet behauptet.

Echte Audiowiedergabe gehört ausdrücklich nicht zum automatisierten Nachweis.
Der endgültige Tag, Release-SHA und der dazu gehörige CI-Lauf werden im
GitHub Release ausgewiesen, weil diese Belege erst nach diesem versionierten
Dokument entstehen können.

Veröffentlichungsnachweis

• Release-SHA: 420ebee6dfc62b4f9903707e5d73c83a3574f7ac
• Vollständiger Main-CI: https://github.com/pquandel2-alt/homeintent/actions/runs/40194684290
• Release-Gate und Veröffentlichung: https://github.com/pquandel2-alt/homeintent/actions/runs/40198387559
• Tag und Release zeigen auf denselben geprüften SHA.

HomeIntent v7.11.0

HomeIntent 7.11.0

Music Assistant

• Angemeldete Benutzer können einen einzelnen, exakt gefundenen
  Music-Assistant-Bibliothekseintrag als persönlichen Medienalias vormerken.
  Gespeichert wird erst nach Vorschau und ausdrücklichem Ja.
• Der Eintrag enthält Besitzer, config_entry_id, Medientyp, kanonischen Namen
  und eine sichere, nicht webbasierte Media-ID. HTTP-, HTTPS-, FTP-, Datei- und
  Daten-URLs sind ausgeschlossen.
• Vor jeder Wiedergabe werden Existenz, Eindeutigkeit, MA-Instanz und Media-ID
  erneut geprüft. Veraltete oder mehrdeutige Aliase starten nichts.
• Anlegen und Verwenden sind benutzergebunden; Löschen ist nur dem Besitzer
  oder einem Administrator erlaubt. Konflikte mit Geräten, Räumen, Personen,
  HA-Benutzern und vorhandenen Aliasen werden abgelehnt.
• Bereits vorhandene, eindeutig benannte und freigegebene MA-Gruppen-Player
  werden wie normale Ziele verwendet. Dynamische Gruppenbildung ist bewusst
  nicht implementiert, weil für die unterstützten HA-Versionen kein eigener
  stabiler nativer MA-Aktionsvertrag belegt ist.

NLU-Roadmap Phase 4

• Ein erster enger Router-Ausschnitt konsumiert das bereits einmal erzeugte
  LanguageDocument und projiziert typisierte Automationsslots.
• Autoritativ migriert ist nur die fail-closed Erkennung unvollständiger
  zukünftiger beziehungsweise solarer Automationsfragmente. Sie darf lediglich
  eine gezielte Rückfrage öffnen und besitzt keinen Ausführungspfad.
• Datum, Uhrzeit, Sonnenereignis/-offset, Bedingung, Dauer, Zustand, Aktion,
  Ziel, Ausnahme, Wiederholung und Gültigkeitszeitraum sind in dieser Matrix
  typisiert. Negation, Hypothese und unvollständige Äußerungen erzeugen keinen
  reduzierten Plan.
• Der vollständige Automationscompiler, Management, Monitoring, Routinen,
  Queries und Gerätecontroller bleiben Compatibility-/Legacy-Pfade. Phase 4
  ist ausdrücklich nicht vollständig abgeschlossen.

Qualitätsstand vor dem Release

• Standardbenchmark: 467/503, Dev 362/390, Held-out 105/113,
  Automation 30/38, Mehrturn 29/31, Confirmation 55/67,
  Clarification 26/31 und No-write 440/453.
• Zweites 7.8-Korpus: 102/107, Dev 70/71, Held-out 32/36,
  Automation 12/14, Dialog 12/12, Confirmation 28/30 und No-write 94/96.
• Wrong Target, falsche Operation, unerwartetes Schreiben, Ausführung ohne
  Bestätigung, Safety-Fehler und unsafe_execution_count: jeweils exakt null.
• 4.173 Korpussätze wurden gegen 7.10.1 geprüft; es gab keine geänderte
  Signatur und keine abgesenkte Baseline.

Details: Music Assistant,
NLU-Migrationsstatus und
Benchmark-Qualitätsgrenzen.

HomeIntent v7.10.1

HomeIntent 7.10.1

Diese Datei beschreibt den vorgesehenen Patch-Inhalt. Sie bestätigt weder Tag
noch Veröffentlichung; beides ist erst nach grünen Pflichtjobs für denselben
main-Commit zulässig.

Korrektheit und Sicherheit

• Der Entwicklungsbenchmark verwendet denselben öffentlichen
  Conversation-Scope-Resolver wie die Produktion. Bestätigungen,
  Automationsentwürfe und Rückfragen werden nicht mehr unter der öffentlichen
  Conversation-ID im privaten Store gesucht.
• Versionierte Benchmark-Grenzen prüfen neben unsicheren Ausführungen auch
  Wrong-Target-/Safety-Fehler sowie Gesamt-, Split- und Dialogkategorien. Eine
  Verschlechterung kann nur mit einer separaten Begründungsdatei akzeptiert
  werden; Sicherheitsgrenzen sind nicht absenkbar.
• Automation-Undo verwendet ein zielbezogenes Schema-2-Delta. Fremde
  zwischenzeitliche Änderungen bleiben erhalten; veränderte Zielzustände
  werden fail-closed abgelehnt.
• Interne Lifecycle-Dienste verlangen einen einmaligen kryptografischen
  Nachweis für Operation, Ziel, Auftraggeber und offenen Status. Dies gilt
  identisch für die Legacy-Domain.

Music Assistant

• Bibliothekssuchen haben ein explizites Timeout von neun Sekunden. Timeout,
  HA-Dienstfehler, verschwundene Dienste und ungültige Antworten erzeugen
  keinen Wiedergabeplan; CancelledError wird weitergegeben.
• Ein Vertragstest lädt das echte Schema der installierten
  Home-Assistant-Music-Assistant-Komponente. Er startet keinen echten
  Music-Assistant-Server und führt keine Wiedergabe aus.

Persönliche Music-Assistant-Aliase, dynamische Gruppenbildung und die erste
NLU-Phase-4-Matrix sind nicht Teil dieses Patch-Releases. Sie benötigen einen
getrennten Minor-Release-Review.

Details: Delta-Undo,
Lifecycle-Nachweis,
Music Assistant und
Benchmark-Qualitätsgrenzen.

HomeIntent v7.10.0

HomeIntent 7.10.0

7.10.0 ist das getrennte Minor-Release für kompositionelles deutsches
Sprachverständnis, sicheren Dialogkontext und optionale Music-Assistant-
Unterstützung. Die Sicherheits- und Datenintegritätskorrekturen wurden bereits
separat als 7.9.11 veröffentlicht und werden hier nicht aufgeweicht.

Dialog und Sprachverständnis

• Kontextschlüssel kombinieren Conversation-ID mit dem authentifizierten
  Benutzer. Ohne Benutzerbindung wird ein bekannter Sprachsatellit verwendet;
  anonymer Kontext wird nicht zwischen Satelliten geteilt.
• Rückbezüge auf den vorherigen Heizungswert verwenden nur den unmittelbar
  beobachteten, typisierten Stellwert desselben Dialogkontexts. Fehlt dieser
  Nachweis oder ist das Ziel nicht mehr eindeutig, wird nichts ausgeführt.
• Relative Rollladenangaben wie „zehn Prozent weiter hoch“ werden aus Richtung,
  Grad und aktueller Position zusammengesetzt und auf 0 bis 100 begrenzt.
  Ohne aktuelle Position endet die Anfrage geschlossen.
• Kausale Fragen erklären anhand lokaler Ausführungsevidenz, was verstanden
  beziehungsweise warum nichts ausgeführt wurde. HomeIntent erfindet keine
  frühere Geräteaktion.
• Gruppen- und Ortsrückbezüge bleiben typisiert. Eine Korrektur oder ein
  Pronomen übernimmt keinen Kontext eines anderen Benutzers.

Die Umsetzung erweitert Lexeme, Bedeutungsmerkmale, typisierte Slots und
Diskursauflösung. Neue vollständige Beispielsätze sind Regressionstests, nicht
die primäre Produktivlogik. Das Regex-Inventar weist weiterhin 171 semantische
Satzmuster aus; deren Zahl wächst in diesem Release nicht.

Optionale Music-Assistant-Unterstützung

• HomeIntent erkennt die tatsächlich registrierten Dienste
  music_assistant.search und music_assistant.play_media. Ohne diese
  Fähigkeiten bleibt die bestehende allgemeine media_player-Steuerung aktiv.
• Künstler, Alben, Playlists, Titel und gespeicherte Radiosender werden über
  die Music-Assistant-Bibliothek gesucht. Nur exakt normalisierte, eindeutige
  Namen werden in einen typisierten MusicAssistantPlan übernommen.
• Der Plan enthält Medientyp, Suchname, geprüfte Media-ID, Zielplayer,
  Queue-Modus, Auflösungsquelle und Eindeutigkeitsstatus. Erst die bestehende
  Policy- und Executor-Schicht darf daraus einen Schreibaufruf machen.
• Unterstützte Queue-Modi sind Ersetzen, Anhängen und „als Nächstes“.
  Pause, Fortsetzen, Stop, Next, Previous, Lautstärke und Mute verwenden die
  vorhandenen sicheren media_player-Pläne.
• Player müssen verfügbar, Music Assistant eindeutig zugeordnet und dem Raum
  sicher auflösbar sein. Mehrere Player oder gleichnamige Medientypen führen zu
  einer Rückfrage, niemals zur Auswahl des ersten Treffers.
• Direkte HTTP-, Datei-, FTP- und Daten-URLs werden verworfen. Bibliotheks-IDs
  müssen einem begrenzten URI-Format entsprechen. Suchfehler liefern eine
  neutrale Meldung ohne Providerdetails und ohne Wiedergabeplan.

Bibliotheksdaten werden absichtlich nicht dauerhaft gecacht. Jede benannte
Wiedergabe fragt den aktuellen Music-Assistant-Bestand ab; entfernte Sender
werden dadurch nach Neustart oder Bibliotheksänderung nicht aus altem Zustand
gestartet. Einrichtung und Grenzen beschreibt
docs/music-assistant.md.

Sicherheit und Kompatibilität

• Die in 7.9.11 eingeführten Herkunfts-, Pause-/Resume-, Rollback-, Besitzer-
  und Event-Loop-Schutzmechanismen bleiben unverändert aktiv.
• NLU und Bibliothekssuche führen keine Geräteaktion direkt aus.
• Mehrdeutige oder unsichere Auflösung endet ohne Schreibplan.
• Der Music-Assistant-Adapter führt keine eigene Netzwerkverbindung ein und
  besitzt keine harte Python-Abhängigkeit auf Music Assistant.
• Es gibt keine automatische unscharfe Radiosenderwahl und keine implizite
  Playergruppenbildung.

Korpus und Veröffentlichung

Die Baseline umfasst 4.153 Signaturen. Gegenüber 7.9.11 sind 46 Test- und
Dokumentationssätze neu, keiner entfällt. Die zwei bewusst veränderten
Verhaltenssignaturen betreffen ausschließlich die zuvor fälschlich absolut
behandelten relativen Rollladenangaben; Details stehen in der
Korpusbegründung.

Tag und GitHub-Release dürfen erst nach erfolgreichen Pflichtjobs für den
exakten main-Commit erstellt werden. Diese Datei behauptet daher keine noch
nicht durchgeführte Veröffentlichung.

HomeIntent v7.9.11

HomeIntent 7.9.11

7.9.11 ist ein eng begrenzter Sicherheits-, Datenintegritäts- und
Event-Loop-Patch. Er enthält keine neue NLU- oder Medienfunktion.

Sichere Automationsdienste

• homeintent.delete_automation und der Legacy-Alias
  ha_nlu.delete_automation löschen nur Automationen mit einem konsistenten
  Sidecar-Eintrag created_by: homeintent. Prüfung und YAML-Änderung liegen
  unter derselben gemeinsamen Sperre. Fehlende, fremde, widersprüchliche oder
  beschädigte Metadaten beenden den Vorgang ohne Schreibzugriff, Reload,
  Registry-, History- oder Metadatenänderung.
• Der öffentliche Resume-Dienst aktiviert keine beliebige Automation mehr.
  Er verlangt Ziel-ID, Helper-ID und eine kryptographisch eindeutige Pause-ID,
  die exakt zu einem dauerhaften offenen HomeIntent-Pausenauftrag passen.
  Erfolgreich verwendete Aufträge werden als verbraucht markiert und können
  nicht wiederverwendet werden.
• Normale Aktivierung über die bestätigte HomeIntent-Automationsverwaltung
  bleibt getrennt und unterliegt weiterhin Eigentümer- oder Adminprüfung.

Datenintegrität bei „Rückgängig“

• History-Einträge speichern die exakten Digests des von HomeIntent
  hinterlassenen YAML- und Metadatenzustands sowie den betroffenen Besitzer.
• Vor jedem Rollback müssen beide aktuellen Digests übereinstimmen. Externe
  Änderungen werden deshalb weder überschrieben noch wiederhergestellt; bei
  einem Konflikt bleibt auch der History-Eintrag erhalten.
• Nur der gespeicherte Besitzer oder ein Home-Assistant-Administrator darf
  zurückrollen. Eine Ja/Nein-Bestätigung ersetzt diese Autorisierung nicht.

Event-Loop-Sicherheit

• Thermal-Dokumente werden in einem kontrollierten, zusammengefassten
  Hintergrund-Worker atomar geschrieben. Es läuft höchstens ein Schreib-Task;
  die jüngste Generation gewinnt und beim Unload wird der letzte Stand
  abgewartet.
• GoalRuns ohne passenden aktiven Thermal-Zyklus sowie deaktiviertes Lernen
  erzeugen keine Thermal-Persistenz.

Speicherformat und Migration

• Automation-Sidecars können nun pause_id, pause_target_automation_id,
  pause_resume_at, pause_status und pause_consumed_at enthalten.
  Bestehende Sidecars bleiben lesbar. Alte Resume-Helper ohne vollständigen
  kryptographischen Nachweis werden absichtlich nicht automatisch ausgeführt;
  HomeIntent rät keine Zuordnung.
• Neue History-Einträge enthalten post_write_digest,
  post_metadata_digest und owner_user_id. Alte Einträge ohne diese sicheren
  Felder bleiben erhalten, werden aber fail-closed abgelehnt.

Kompatibilität und Grenzen

• Sicherheits-, Bestätigungs-, Ambiguitäts- und NEVER_AUTO-Regeln werden
  nicht abgeschwächt.
• Die Korpusbaseline ist gegenüber 7.9.10 bytegleich, weil dieser Patch die
  Sprachverarbeitung nicht verändert.
• Veröffentlichung erfolgt nur, wenn die verpflichtenden CI- und
  Release-Gates für den exakten Release-Commit erfolgreich sind.

HomeIntent v7.9.10

HomeIntent 7.9.10

7.9.10 härtet Ereignisverarbeitung, Fehlergrenzen und die strukturelle
deutsche Sprachverarbeitung. Der Sicherheitsvertrag bleibt unverändert:
HomeIntent arbeitet weiterhin ohne LLM oder ML-Modell zur Laufzeit;
Grounding, Berechtigungen, Bestätigungen, NEVER_AUTO, ExecutionPolicy und
ServiceExecutor bleiben verbindlich.

EventRuntime und Wiederanlauf

• Circuit-Retry-Fristen werden unabhängig von neu eintreffenden Events
  eingehalten. Ein Event kann einen offenen Circuit nicht mehr vorzeitig
  umgehen.
• Begrenzte Wiederholungsversuche, Zustandsübergänge, Resets und
  Wiederanläufe sind explizit instrumentiert und diagnostizierbar.
• Queue, Metriken, Supervisor und Scheduler sind in klar getrennte
  Laufzeitkomponenten aufgeteilt, ohne den bestehenden Lebenszyklusvertrag zu
  verändern.

Fehlergrenzen und Datenschutz

• Die produktiven Ausnahmegrenzen wurden vollständig inventarisiert und um
  fehlende Rollback- und Diagnosepfade ergänzt.
• Unerwartete Provider-, Recorder- und Servicefehler bleiben intern mit
  Traceback analysierbar. Assist-Antworten und persistierte Fehler enthalten
  keine ungefilterten Ausnahmetexte, Pfade, Tokens oder sonstige sensible
  Details.

Deutsche Sprache

• Formelle Höflichkeitsformen, Mitternacht und umgangssprachliche Befehle wie
  „hau … runter“ werden strukturell erkannt.
• Geordnete Mehrfachbefehle und ein lokal gebundenes „erst“ behalten ihre
  Reihenfolge und ihren Geltungsbereich.
• Koordinierte Ziele werden in einem gemeinsamen Scan aufgelöst. Dadurch
  bleiben Zuordnung und Reihenfolge auch bei mehreren Räumen und Geräten
  stabil.

Dokumentation und Freigabe

• Die Dokumentation wurde bereinigt und an die aktuelle Laufzeitarchitektur
  und Fehlerbehandlung angepasst.
• Der Release-Workflow prüft Manifest, Release Notes, Tag-Freiheit und alle
  neun verpflichtenden CI-Jobs gegen exakt denselben vollständigen Commit-SHA,
  bevor der GitHub-Release erstellt wird.

Verifikation

Der Release-Kandidat wurde unter Python 3.12 und 3.13 sowie mit Hassfest,
HACS, Home-Assistant-Smoke- und Options-Flow-Tests geprüft. Zusätzlich liefen
die Sprach-, Learning-Center- und Live-Testbed-Suiten erfolgreich durch.

HomeIntent v7.9.9

HomeIntent 7.9.9

7.9.9 stabilisiert die Ereignisverarbeitung. Der Funktions- und
Sicherheitsvertrag bleibt unverändert: HomeIntent arbeitet weiterhin ohne LLM
oder ML-Modell zur Laufzeit; Grounding, Berechtigungen, Bestätigungen,
NEVER_AUTO, ExecutionPolicy und ServiceExecutor bleiben verbindlich.

EventRuntime

• Ein expliziter Queue-/Lease-/Finalize-Lebenszyklus hält entnommene Events
  bis zur Bestätigung als Live-Arbeit. Scheitert der HouseView-Aufbau oder ein
  anderer Batchschritt, werden nur die noch nicht bestätigten Einträge in
  FIFO-Reihenfolge zurückgestellt.
• Pro Generation existiert höchstens ein Supervisor-Task. Wiederholte Fehler
  verwenden begrenzten exponentiellen Backoff und einen Circuit-Zustand;
  neue Events oder der Retry-Timer können die Verarbeitung wieder wecken.
• Queue-, Lease-, Retention-, Retry-, Circuit- und Recovery-Zustände besitzen
  getrennte Diagnosezähler. Unload und Generationenwechsel verwerfen alte
  geleaste Arbeit, statt sie in die nächste Generation zu übertragen.

Lang laufende Zustände

• Eine Schwelle von 0 deaktiviert long_running_state vollständig, sofern
  kein anderer Consumer das Ereignis benötigt.
• Ein gemeinsamer, auf 4096 Intervalle begrenzter Scheduler löst die Prüfung
  auch ohne ein weiteres state_changed aus. Es gibt keinen Task pro Entity.
• Die Aktivitätsregeln sind domainspezifisch und konservativ. Climate nutzt
  hvac_action; Vacuum erkennt cleaning und returning. Die vollständige
  Tabelle und die bewusst nicht unterstützte Water-Heater-Semantik stehen in
  der Agenten-Konfiguration.

Zeitzonen und Fehlertexte

• Der HA-Teststub besitzt eine explizite Standardzeitzone. UTC,
  Europe/Berlin, Sommer-/Winterzeit und beide DST-Übergänge werden geprüft;
  das CI-Gate läuft zusätzlich unter zwei Host-TZ-Werten.
• Unerwartete Provider- und Serviceausnahmen bleiben mit Traceback im Log.
  Assist und persistente benutzerseitige Fehler erhalten eine stabile,
  verständliche Meldung ohne Pfade, Tokens oder ungefilterte Ausnahmetexte.

Freigabestatus

Veröffentlicht am 16. Oktober 2026 aus dem vollständig geprüften Commit
b6e3d88a674a13609714287b9ca64acfd4b92ecf.

HomeIntent 7.9.8

HomeIntent 7.9.8

7.9.8 korrigiert verbleibende Zustellungs- und Diagnosefehler der in 7.9.7
gehärteten EventRuntime. Es ändert weder NLU noch Ausführungs- oder
Safety-Regeln.

Korrekturen

• History- und Registry-Degradation sind getrennte Zustände. Ein
  unvollständiger globaler Verlauf deaktiviert konkrete geschützte Consumer
  nicht mehr pauschal.
• Aktive Thermal-Zyklen erhalten eine begrenzte, aus Snapshot, Batch und
  Restqueue zeitlich korrekt rekonstruierte Sicht auf Climate-, Temperatur-,
  Außen- und Fenster-Entities.
• Wenn die Historie einer konkret geschützten Entity selbst unsicher ist,
  wird der Consumer nicht mit geratenen Daten aufgerufen. Die Unterdrückung
  wird nach Grund, Consumerklasse und Eventpriorität gezählt und
  rate-limitiert protokolliert.
• ExpectedEffects sowie sichere Personen- und Werte-Monitore bleiben im
  History-Modus zustellbar. Nobody-home-Ziele erhalten eine zeitlich korrekte,
  begrenzte Sicht auf alle ausgewählten Haushaltspersonen.
  Hauskontextabhängige Monitor-/Proactive-Pfade werden nur mit nachweislich
  sicherem Kontext ausgeführt.
• processed bezeichnet jetzt ausdrücklich den abgeschlossenen
  eventbezogenen Dispatch, einschließlich bewusster Suppression, aber nicht
  eines Registry-Discards. Separate Delivery-, Suppression-,
  Registry-Discard- und Queue-Drop-Zähler verhindern einen falschen
  Zustellungseindruck.
• filtered_by_category, filtered_by_proactive und
  filtered_no_consumer sind disjunkte Filterursachen.
• worker_restarts zählt nun ausschließlich einen echten automatischen
  Ersatz nach unerwartetem Worker-Ende mit ausstehender Arbeit;
  worker_starts zählt jeden angelegten Worker.
• long_running_state ist end-to-end angebunden. Die neue Option
  agent_long_running_minutes ist standardmäßig 0 (deaktiviert), im Options
  Flow validiert und verhindert dadurch überraschende Meldungen bestehender
  Installationen.

Kompatibilität und Grenzen

Bestehende Installationen werden nicht migriert und erhalten keine neue
Langläufermeldung, solange die Schwelle nicht ausdrücklich gesetzt wird. Die
Single-Worker-Architektur, die begrenzte Queue und der I/O-freie synchrone
Callback bleiben erhalten.

Unter beliebiger Überlast wird keine Verlustfreiheit versprochen. Critical
und konkrete Protected-Events verdrängen niedrigere Ränge; an einer komplett
gleich- oder höherrangig gefüllten Queue kann auch ein wichtiges Event
verloren gehen. Das wird als Queue-Drop gezählt. Kann ein Consumer wegen
unsicherer Historie oder fehlender Registry-Daten nicht korrekt arbeiten,
wird er stattdessen ausdrücklich unterdrückt und separat diagnostiziert.

Technische Details, Metriksemantik und Testergebnisse stehen in
docs/umsetzung-7.9.8.md.