## 1. Prüfpfade vorbereiten

- [ ] 1.1 Verbindliche Matrix und kurze Bediensequenzen für die vier Targets anlegen; Windows Terminal, Terminal.app sowie xterm/VTE auf beiden Linux-Architekturen müssen konkrete Versions-/Revisionsfelder und erwartete Resultate besitzen.
- [ ] 1.2 Bestehenden Unix-PTY-Test und passenden Windows-Konsolen-/ConPTY-Test für Shell, Abbruch und Wiederherstellung bereitstellen; positive Läufe und erzwungene Fehler dürfen keinen beschädigten Terminalmodus hinterlassen.
- [ ] 1.3 Die gemeinsame TBL-Verbraucherprobe aus 03 samt fester Prüfsumme in jede der vier Zielabnahmen aufnehmen (quellfreies TBC/EXE, RUN, tatsächliches Host-Target); IDE-/Programmprüfungen für F1–F12, Modifikatoren, Maus, Unicode/Attribute und Resize nachvollziehbar auflisten; jeder Fall muss sichtbaren Effekt und Ausschluss doppelter BASIC-Zustellung prüfen.

## 2. Tatsächliche Zielabnahme

- [ ] 2.1 Windows amd64 in Windows Terminal prüfen; Protokoll muss IDE, exportiertes Forms-Programm, INPUT/Break und Shell-Rückkehr mit tatsächlicher Zielausführung belegen.
- [ ] 2.2 macOS arm64 in Terminal.app prüfen; zusätzlich finalisierte/signierte native Ausgaben starten und die Ergebnisse mit der Matrix abgleichen.
- [ ] 2.3 Linux amd64 in xterm und einem VTE-Terminal prüfen; beide Emulatoren müssen dieselben Pflichtfunktionen beziehungsweise dokumentierte funktionierende Ersatzwege liefern.
- [ ] 2.4 Linux arm64 in xterm und einem VTE-Terminal prüfen; Cross-Build allein darf keinen Fall abschließen.
- [ ] 2.5 Gefundene Produktfehler im zuständigen Adapter beheben; gezielter Regressionstest und erneuter betroffener Emulatorlauf müssen den Befund schließen.

## 3. Übergabe

- [ ] 3.1 Terminalgrenzen und verifizierte Ersatzwege dokumentieren; kein Produktfehler oder fehlender Prüfrechner darf als bestandene Matrixzelle erscheinen.
- [ ] 3.2 Automatisierbare Zielprüfungen an 06 übergeben und Matrixbericht fertigstellen; alle Pflichtzellen, Revisionen, vier Ergebnisse derselben TBL-Verbraucherprobe und tatsächlichen Ergebnisse müssen vor Abschluss vorliegen. Native Prüfsysteme dürfen separat vom zentralen Buildrunner betrieben und Nachweise dokumentiert manuell erhoben werden.
