Phase 6: Plattformprüfungen und absolute RGB-Farben, Change 05 archivieren

openspec/changes/archive/2026-09-07-phase-6-05-plattformmatrix/verification.md

@@ -0,0 +1,163 @@
+# 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](https://learn.microsoft.com/en-us/windows/console/getconsolemode),
+[SetConsoleMode](https://learn.microsoft.com/en-us/windows/console/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.