## 1. Kompatibilitätsnachweise

- [ ] 1.1 Bestehende Fälle aus compat.rs, foreign.rs, inventar.rs, events.rs und IDE-Abnahme einer dokumentierten Release-Matrix zuordnen; jede vereinbarte Verhaltensgruppe muss konkrete Fallnamen und einen ausführbaren Aufruf besitzen.
- [ ] 1.2 Fehlende kombinierte Zeichen-/Attribut-/Resize- und Formularübergänge im vorhandenen Korpus ergänzen; wiederholte Läufe sowie absichtlich falsche Zeichen-/Attributerwartungen müssen die Vergleichsqualität belegen.
- [ ] 1.3 Projekt-/Include-, Fehler- und Dateifälle mit festgelegtem Anfangszustand und Dateieffekten vervollständigen; gezielte Tests müssen Diagnosen und saubere temporäre Verzeichnisse prüfen.
- [ ] 1.4 Öffentlichen Bestand in festgelegter Revision bereitstellen und den vorhandenen foreign-Test ausdrücklich ausführen; falsche/fehlende Revision muss den erforderlichen Abnahmepfad scheitern lassen.

## 2. Inventar und Leistung

- [ ] 2.1 Aktuelle Sprach- und Forms-Inventarsummen mit Quelllisten, Absenkungsproben und Ereignistests prüfen; Bericht muss alle Statusgruppen getrennt und offene Einträge namentlich ausweisen.
- [ ] 2.2 Vorhandene Compile-/VM-Benchmarks im Release-Profil messen und mit reproduzierbarem Vergleichsstand einordnen; Hardware, Revision, Verfahren und beide Compile-Budgets im Bericht festhalten.
- [ ] 2.3 Nur bei nachgewiesenem Engpass eine gezielte Fachkorrektur umsetzen und denselben Semantik-/Leistungsnachweis wiederholen; andernfalls „kein Optimierungsbedarf“ mit Messbegründung dokumentieren.

## 3. Übergabe

- [ ] 3.1 Gefundene Fachabweichungen vollständig beheben; betroffene Korpus-, Inventar- und Ereignistests müssen unveränderte Verträge bestätigen, ohne Golden-Dateien pauschal neu zu generieren.
- [ ] 3.2 Abnahmesatz und Ergebnisse für native Artefakte und CI dokumentieren; Workspace-Tests, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, externe Voraussetzungen bleiben ausdrücklich sichtbar.