Verifizierung: phase-6-05-plattformmatrix

Stand 07.09.2026. Basis ist der auf Origin bestätigte Commit 5aa920b768a2ad29ed17c5da137e54675a7292d6 plus der lokale Change-05-Diff. 05a wurde auf Benutzeranweisung synchronisiert und mit den ausdrücklich weiterhin offenen Nachweisen 1.2/3.2/3.3 archiviert. Diese Nachweise werden hier weitergeführt; Archivierung wurde nicht als bestandene Zielprüfung gewertet.

Ergebnis

Dimension	Stand
Vollständigkeit	2/10 Aufgaben abgeschlossen; acht Aufgaben mit fehlenden echten Zielnachweisen offen
Korrektheit	Lokale Workspace-, native macOS-/TBL-/PTY- und Eingabeprüfungen bestanden; Windows-Code einschließlich Konsolentest cross-geprüft, nicht auf Windows ausgeführt
Kohärenz	Bestehende Prüfskripte, Formular-Engine und TerminalGuard wiederverwendet; keine neue Abhängigkeit, keine Änderung an Runnerdiensten

Der Change wird am 07.09.2026 auf ausdrückliche Benutzeranweisung archiviert. Der Benutzer hat die RGB-/Fensterflächenkorrektur mit „test is good“ bestätigt. Ein vollständiger Pflichtmatrixlauf ist weiterhin nicht belegt. Die acht unvollständigen Aufgaben bleiben im Archiv sichtbar und werden für die Paketfreigabe in 06 und die Phasenabnahme in 07 weitergeführt. Archivierung und Benutzerbestätigung des Farbtests ersetzen diese Nachweise nicht.

Umsetzung

docs/plattformmatrix.md: sechs verbindliche Emulatorzellen für vier Ziele, Versions-/Revisionsfelder, gesamte F1–F12-/Modifierfolge, Eingabe, Maus, Unicode, Resize, INPUT/Break, Shell und Theme-Gegenprobe aus 05a. Nicht ausgeführte Fälle und fehlende Ersatzwege sind ausdrücklich offen.
tests/support/platform-abnahme.py: führt vorhandene native-, Library- und Unix-PTY-Prüfungen auf dem tatsächlich erkannten Ziel aus. Bericht bindet Ziel, Checkout-/Diffstand, Skript- und Executable-Prüfsummen sowie die unveränderte TBL-Prüfsumme. Fehlende Windows-Konsolenprobe verhindert ein positives automatisiertes Gesamtergebnis. Manuelle Matrix bleibt ausdrücklich not_run / matrix_complete: false.
tests/support/ide-execution-pty.py: bestehende drei Bedienpfade erhalten; jetzt mit explizitem Kandidatenpfad und gespeicherten ANSI-Transkripten.
tests/platform/input.frm: interaktive Ereignis-/Zählerprobe für IDE und nativen Export. crates/tb-ide/tests/execution.rs prüft eine normale Taste einschließlich zusätzlichem rohem Release genau einmal, sowie F1 im IDE-Codekontext ohne zusätzliche BASIC-Zustellung.
crates/tb-ui/examples/spike.rs: vorhandene Rohdiagnose um nummeriertes Ereignislog erweitert; keine Überschreibung bestehender Logs. Der gemeinsame TerminalGuard übernimmt auch hier Cleanup bei Fehlern.
crates/tb-ui/src/terminal.rs: Windows-Eingabe-/Ausgabemodi werden vor dem Einstieg gesichert und bei Shell-Übergabe, Fehler und Ende wiederhergestellt. Der vorhandene Crossterm-Code setzte Raw-Flags pauschal zurück. Zusätzlich wird ANSI-Verarbeitung bei erneutem Eintritt aktiviert, weil Crossterm die Fähigkeit zwischenspeichert. Der neue explizite Windows-Test verwendet eine eigene Kindkonsole, Nichtstandard-Echozustand und begrenzte Laufzeit. Er deckt Shell 0/7, Abbruch, Rückkehr, Renderfehler und Teilinitialisierung ab. Die vorhandene Abbruchprüfung verlangt nicht länger einen Unix-spezifischen Exitcode auf Windows und erzeugt dort keinen verbleibenden Ping-Unterprozess.

API-Grundlage der Windows-Korrektur: GetConsoleMode, SetConsoleMode. Der tatsächliche Windows-Lauf bleibt Voraussetzung, um den Befund zu schließen.

Ausgeführte Prüfungen

cargo test --locked --workspace: 638 bestandene Testergebnisse, 0 Fehler, 3 bestehende ignorierte Tests. Die zusätzliche Windows-Prüfung ist auf macOS nicht enthalten und wurde nicht als bestanden gezählt.
cargo check --locked --target x86_64-pc-windows-msvc -p tb-ui --features terminal --tests: bestanden; ebenso Cross-Checks von IDE, CLI, Export und deren Targets.
Clippy für tb-ui/tb-ide inklusive aller Targets sowie für die Windows-Konsolentests mit -D warnings: bestanden.
Release-Build von tb/tbc/tbrt/tb-template und Spike: bestanden.
platform-abnahme.py --bin-dir target/release: auf macOS arm64 bestanden. Aktuelle Einzelbelege nach RGB-Korrektur im Verzeichnis evidence/2026-09-07-macos-arm64-rgb: native Console-/Forms-/Fehler-/RUN-/Mehrmodul- und quellfreie Exporte, CLI/native INPUT und Abbruch in Unix-PTY, Exportabbruch und Korruptionsfälle, dieselbe portable.tbl mit quellfreier TBC-/EXE-Nutzung und RUN, IDE-Shell 7, Kindabbruch und File→Shell mit Wiederherstellung.
Die Probe wurde separat kompiliert; IDE-Ereignistest besteht. Spike wurde headless über Unix-PTY mit x/Esc geprüft: genau zwei nummerierte Rohereignisse und ursprüngliche Terminalattribute nach Ende. Wiederverwendung desselben Logpfads wurde ohne Überschreiben abgelehnt.
Negativprüfung des Sammelaufrufs mit fehlenden Binaries: Exit 2, verständlicher Fehler, kein erzeugter Erfolgsreport.

Der erste ad-hoc Spike-Prüfversuch mit Python-preexec blieb beim Start hängen; die eigenen Prüfprozesse wurden beendet. Der erfolgreiche Wiederholungslauf verwendete dasselbe Fork-/Sitzungsbesitzmuster wie die bestehende IDE-PTY-Probe. Dies ist kein visueller Emulatornachweis. Rohlogs und Testergebnisse werden nur für die tatsächlich ausgeführten Pfade gewertet.

RGB-Korrektur nach erneutem Benutzerbefund

Der Screenshot vom 07.09.2026 um 20:54 zeigte zwei Produktfehler: Die Farbabbildung konnte weiterhin auf Terminalprofilfarben zurückfallen; außerdem änderten Block/Paragraph nur Zellstile, sodass das Desktopzeichen ▒ in unbeschriebenen Fensterflächen stehen blieb. Dieses Muster mischte optisch Vorder-/Hintergrund und erklärte die hellere Fläche neben dem Text.

IDE und BASIC verwenden jetzt die gemeinsame feste DOS-RGB-Palette in tb-ui::screen::basic_color; keine Farberkennung oder Indexfarben mehr. TerminalGuard aktiviert Farbausgabe auch bei NO_COLOR. Gespeicherte DOS-Farbnummern und BASIC-ForeColor/BackColor bleiben erhalten.
Jedes Fenster wird vor dem Rendern geleert. Der neue Regressionstest scheiterte vor der Korrektur mit Desktop in Fenster bei 9/2 und besteht danach einschließlich Auswahlwechsel und überlappenden Fenstern.
Vier Theme-Tests bestehen mit TERM=vt100 COLORTERM= NO_COLOR=1. Der echte Release-Prozess besteht zusätzlich alle drei IDE-PTY-Pfade mit env -u COLORTERM TERM=vt100 NO_COLOR=1; Transkripte enthalten explizit 38;2;170;170;170, 48;2;0;0;170, 48;2;170;0;170, keine Indexfarben und keine OSC-Palettenänderungen. Auch Shell-Rückkehr besteht.
Workspace: 638 bestanden, 0 Fehler, 3 bestehende ignorierte Tests. Clippy, Windows-Cross-Check und OpenSpec (30/30) bestehen. Debug-tb und Release-tb/tbc/tbrt/tb-template/Spike neu gebaut. Native-, TBL- und IDE-PTY-Abnahme mit diesen Release-Artefakten erneut bestanden.
Neue Delta-Spezifikationen in diesem Change ändern ide-oberflaeche und textbildschirm entsprechend der verbindlichen Benutzerkorrektur. Frühere ANSI-/256-Fallback-Verträge im Archiv dokumentieren nur den alten Stand; die Synchronisierung der neuen Deltas erfolgt beim Abschluss von 05.

Belege: evidence/2026-09-07-macos-arm64-rgb. Der gespeicherte Diff stimmt mit dem Hash des Zielberichts überein; spätere Berichtsänderungen betreffen keinen geprüften Produktcode. Das ältere Verzeichnis ohne -rgb belegt den Vorgängerstand und ist kein Nachweis für die aktuelle Farbausgabe. Der Benutzer hat den Farbtest am 07.09.2026 als erfolgreich bestätigt. Diese Bestätigung schließt den gemeldeten RGB-/Fensterflächenbefund; eine vollständige versionsgebundene Emulatorfolge wurde damit nicht bestätigt.

Benutzerentscheidung: Windows-Ausführung vorerst offen lassen. DOSBox ist kein Windows-PE-Prüfsystem. Linux nutzt denselben ANSI-/RGB-Pfad wie macOS; das begründet eine Verhaltenserwartung, ersetzt aber keine xterm-/VTE-Zielprüfung.

Offene Befunde

Jede der folgenden Aufgaben bleibt CRITICAL für die vollständige Abnahme:

Aufgabe	Fehlender Nachweis / erforderliche Aktion
1.2	Windows-Konsolenprüfung auf echtem Windows ausführen; Code/Cross-Check vorhanden, die Wiederherstellung einschließlich Fehlerpfaden ist dort noch nicht bewiesen.
2.1	Windows amd64 in Windows Terminal: IDE, natives Formular, INPUT/Break, Shell und TBL tatsächlich ausführen und protokollieren.
2.2	Terminal.app auf macOS arm64 manuell prüfen. Native/PTY-/TBL-Läufe sind bestanden, die echte Emulatorbedienung und Theme-Gegenprobe fehlen.
2.3	Linux amd64 in xterm und VTE einschließlich derselben TBL tatsächlich prüfen.
2.4	Linux arm64 in xterm und VTE einschließlich derselben TBL tatsächlich prüfen.
2.5	Windows-Wiederherstellungsbefund durch den tatsächlichen Zieltest schließen. Code und lokale Regressionen bestehen.
3.1	Reservierte Shortcuts und gegebenenfalls funktionierende Ersatzwege in den echten Emulatoren belegen. Regeln sind dokumentiert, keine Ersatzwege ohne Versuch als erfolgreich eingetragen.
3.2	Alle Pflichtmatrixzellen und TBL-Ergebnisse vervollständigen, 05a-Profil-/Theme-Gegenprobe und abschließende Verifizierung schließen; danach aktuelle revisions-/artefaktgebundene Nachweise an 06/07 übergeben.

Verfügbare Systeme und konkrete Grenzen

Lokal bestätigt: macOS 26.6.2 (25G83), arm64; Terminal.app 2.15 ist installiert. Computer Use hat den Zugriff auf Terminal.app im früheren Versuch ausdrücklich gesperrt. Ein automatisierter PTY-Lauf ersetzt den erforderlichen manuellen Lauf nicht; die Sperre wird nicht umgangen.
Windows sowie Linux mit xterm/VTE: bislang kein nutzbarer Zugang benannt.
Gitea-Host: read-only als Linux aarch64 bestätigt, die benötigten GUI-Terminals fehlen. Der Runnercontainer meldete beim Lesezugriff status=restarting, restarts=2319, letzter Start 2026-09-07T18:49:08.081383305Z. Es wurden keine Dienste oder Runnerkonfigurationen verändert. Das ist ein Infrastrukturzustand, keine ausgeführte Zielabnahme.

Für die fehlenden Systeme sind Zugänge beziehungsweise ausgefüllte manuelle Prüfprotokolle nötig. Nach deren Eingang die vorbereitete Folge ausführen, Befunde beheben und betroffene Prüfungen wiederholen; bis dahin bleiben Aufgaben und Matrixzellen offen.

10 KiB Raw Blame History Unescape Escape