## Context

Die LISTINDEX-Prüfung konvertiert -1 vor dem oberen Grenzvergleich nach usize. Änderungen an INTERVAL/ENABLED löschen timer_last, dessen nächster Default 0 ist. Timerereignisse werden bereits über die bestehende Queue zugestellt. Siehe proposal.md und die Delta-Specs.

## Goals / Non-Goals

**Goals:** Gültige Übergänge an den bestehenden Property-/Listenmethoden korrigieren und Timerzustand an die Hostzeit koppeln.

**Non-Goals:** Keine neue Control-Bibliothek, keine Änderung der festgelegten Optik, keine zweite Ereignisschleife.

## Decisions

### D1 — Auswahl ist ein eigener gültiger Zustand

-1 vor dem oberen Grenzvergleich behandeln. Einfügungen vor dem ausgewählten Eintrag verschieben dessen Index; Entfernen des gewählten Eintrags hebt die Auswahl auf, Entfernen davor verschiebt sie zurück. ListBox.Text liefert ohne Auswahl leer, eine editierbare ComboBox behält ihren separaten Eingabetext.

### D2 — Aktivierungszeit statt Nullzeit

Beim Übergang auf einen aktiven Timer den aktuellen Hostzeitpunkt als Ausgangsfrist speichern. Ändernde Property-Zugriffe erhalten diesen Zeitpunkt über den bereits vorhandenen VM/Host-Pfad; kein Systemuhrzugriff und kein globaler Zeitcache. Interval=0/Enabled=0 entfernt anstehende Zustellungen dieses Timers. Explizites Umschalten des Intervalls beginnt eine neue Frist.

### D3 — Laufende Timer behalten Nachholregel

Ein kontinuierlich aktiver 100-ms-Timer bekommt bei 250 ms zwei Ereignisse; das gilt nur für Zeit innerhalb seiner aktiven Phase. Reihenfolge gleichzeitig fälliger Timer bleibt dokumentiert nach Namen und bei gleichem Arraynamen nach Index.

## Risks / Trade-offs

- Änderung an Auswahl kann ComboBox-Eingabetext löschen → Stilarten und editierbaren Text getrennt testen.
- Intervalländerung im eigenen Handler kann alte Queueeinträge übriglassen → Reset/Deaktivierung mit bereits wartenden Ereignissen prüfen.

## Migration Plan

Nach ereigniszustellung-und-hostgrenzen. Ändert nur die Requirements zu Listen und Timer, nicht Fokus/Menü desselben Capability-Pfads. Bestehende Spec-/Codeverträge erst nach erfolgreicher Umsetzung synchronisieren und archivieren. Bis dahin bleiben alle Tasks offen. Änderungen als zusammenhängenden Commit je Change integrieren; bei Fehlschlag auf den vorherigen Code zurückgehen und neue Datenformatversionen nicht mit alten Lesern öffnen.