# 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.
