## 1. Prüfpfade vorbereiten

- [x] 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.
- [x] 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. Die weiterhin offenen Archivaufgaben 05a/1.2 (konkretes Benutzerprofil, frische/gespeicherte Optionen, Transparenz/Dimmung), 05a/3.2 (visuelle Matrix) und 05a/3.3 (befundfreie Schlussverifizierung) müssen hier tatsächlich abgeschlossen werden. Die visuellen Nachweise müssen das umgesetzte Theme aus 05a einschließlich Profil-/Farbmodus und relevanter UI-Zustände abdecken. Native Prüfsysteme dürfen separat vom zentralen Buildrunner betrieben und Nachweise dokumentiert manuell erhoben werden.

Arbeitsstand 07.09.2026: Matrix/Bedienfolgen in `docs/plattformmatrix.md`, Eingabeprobe `tests/platform/input.frm`, gemeinsamer Aufruf `tests/support/platform-abnahme.py`. 1.2 ist implementiert und für Windows cross-geprüft, bleibt bis zum tatsächlichen Windows-Konsolenlauf offen. Automatisierte macOS-arm64-Nachweise liegen unter `evidence/2026-09-07-macos-arm64`; sie schließen keine manuelle Terminalzelle. Details und offene Befunde: `verification.md`.

RGB-Korrektur nach Benutzerbefund vom 07.09.2026 gehört zu 2.5: keine
ANSI-/256-Fallbackfarben; gemeinsame feste RGB-Palette für IDE und BASIC;
Fensterflächen ohne durchscheinendes Desktopmuster. Neue Delta-Spezifikationen
in `ide-oberflaeche` und `textbildschirm` ersetzen den früheren Fallbackvertrag.
Der Benutzer bestätigt den korrigierten Farbtest am 07.09.2026 mit „test is good“.
Archivierung ausdrücklich beauftragt; acht unvollständige Matrixaufgaben bleiben
als Nachweisbedarf an 06/07 übergeben, nicht als bestandene Prüfungen markiert.