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

docs/plattformmatrix.md

@@ -0,0 +1,193 @@
+# Plattformabnahme – Phase 6, Change 05
+
+Diese Matrix prüft die tatsächliche IDE und native Exporte auf den vier
+Release-Zielen. Automatisierte Headless-/PTY-/Konsolentests und die manuelle
+Emulatorbedienung sind getrennte Nachweise. Eine grüne Compilation oder ein
+archivierter Fachchange schließt keine noch ungeprüfte Matrixzelle.
+
+## Verbindliche Matrix
+
+| ID | Tatsächliches Ziel | Emulator | OS-Version | Terminalversion | Revision / Executable-SHA-256 | Visueller Stand |
+|---|---|---|---|---|---|---|
+| W | Windows amd64 | Windows Terminal | offen | offen | offen | nicht ausgeführt |
+| M | macOS arm64 | Terminal.app | 26.6.2 (25G83) | 2.15 | je Lauf eintragen | nicht ausgeführt |
+| X64 | Linux amd64 | xterm | offen | offen | offen | nicht ausgeführt |
+| V64 | Linux amd64 | VTE-Terminal, Produkt benennen | offen | offen | offen | nicht ausgeführt |
+| XA | Linux arm64 | xterm | offen | offen | offen | nicht ausgeführt |
+| VA | Linux arm64 | VTE-Terminal, Produkt benennen | offen | offen | offen | nicht ausgeführt |
+
+Je Zelle zusätzlich Datum/Prüfer, `TERM`, `COLORTERM`, `NO_COLOR`, Profil,
+Transparenz/Dimmung, Größe und OS-/Terminal-Shortcutbelegungen protokollieren.
+Unbekannte Werte sind offen, keine Defaultannahmen. Ein Prüfcontainer auf
+Linux ersetzt weder Windows/macOS noch einen echten xterm-/VTE-Lauf.
+
+## Automatisierte Zielprüfungen
+
+Kandidaten im passenden Checkout bauen:
+
+```sh
+cargo build --locked --release -p tb-ide -p tb-cli -p tb-runner -p tb-export --bins
+python3 tests/support/platform-abnahme.py --bin-dir target/release --output /tmp/tb-platform-proof
+```
+
+Unter Windows `python` und ein neues, absolutes Ausgabeverzeichnis verwenden;
+zusätzlich `--windows-console-test <tb-ui-Testexecutable.exe>` übergeben.
+Dieses Testexecutable entsteht mit
+`cargo test --locked -p tb-ui --features terminal --lib --no-run` auf Windows
+oder wird als passendes Cross-Testartefakt bereitgestellt. Direkter Aufruf:
+
+```text
+<tb-ui-Testexecutable.exe> --exact terminal::tests::windows_console_restores_modes --ignored --nocapture
+```
+
+Der Test verwendet eine eigene Kindkonsole mit 30-Sekunden-Frist. Er prüft
+nichtstandardmäßige Eingabeflags, Shell-Ergebnisse 0/7, Abbruch, Rückkehr zu
+Raw Mode sowie Cleanup nach Render- und Initialisierungsfehlern. Die
+Windows-Terminal-Bedienung der Matrix wird dadurch nicht abgedeckt. Der
+fehlende Windows-Test wird vom Sammelaufruf als fehlend gewertet.
+
+`platform-abnahme.py` sammelt Bericht, Logdateien und Unix-PTY-Transkripte in
+einem neuen Verzeichnis; es überschreibt keine vorhandenen Nachweise. Es
+verwendet die vorhandenen `native-abnahme.py`, `library-abnahme.py` und
+`ide-execution-pty.py`. `report.json` enthält tatsächliches Host-Target,
+OS-/Pythonversion, Checkout-Revision, Dirty-Status/Diff-Prüfsumme,
+Executable-/Harness-Prüfsummen und Ergebnisse. Bei lokalen Änderungen gehört
+`working-tree.patch` zum Nachweis. Binaries müssen aus genau diesem Stand
+gebaut werden; eine Checkout-Revision allein belegt ihre Herkunft nicht.
+Für 06 kommen Buildmanifest und exakte Paketprüfsumme hinzu.
+
+`all_automated_passed` bezeichnet nur diese automatisierten Prüfungen.
+`manual_terminal_status` bleibt `not_run` und `matrix_complete` bleibt
+`false`. Ein erfolgreicher Skript-Exit ist keine Releasefreigabe.
+`tb-template` wird hier als Prüf-/Buildhilfe benötigt; Anwenderprogramme
+benötigen es nicht.
+
+Die TBL-Probe verwendet auf allen vier Zielen unverändert
+`tests/libraries/portable.tbl`, SHA-256
+`5d25c2f8c95ae535e55a6c84c1ddd0d964358863f4f3c780c50ac4a2eb3594df`.
+Das jeweilige `library.log` muss quellfreies Linken nach TBC und EXE,
+tatsächliche Ausführung und den gleichen RUN-Neustart belegen. Ein neues,
+pro Target anders erzeugtes TBL ist kein Ersatz.
+
+## Eingabeprobe vorbereiten
+
+`tests/platform/input.frm` in ein eigenes Prüfverzeichnis kopieren. Die Probe
+schreibt bei jedem Start dort `platform-events.log` neu; frühere Logs vorher
+unter der jeweiligen Matrix-ID sichern. IDE mit der kopierten Form starten.
+Als native Probe dieselbe Form über Run → Make EXE File exportieren (passende
+vorbereitete tbrt-Vorlage), die IDE schließen und das Executable direkt aus
+dem Prüfverzeichnis starten. Alternativ:
+
+```text
+tbc build input.frm --exe --target <Target-Triple> --template <vorbereitete-tbrt-Vorlage> -o <Probe-Executable>
+```
+
+Die Triples sind `x86_64-pc-windows-msvc`, `aarch64-apple-darwin`,
+`x86_64-unknown-linux-gnu`, `aarch64-unknown-linux-gnu`. Mac-Ausgaben müssen
+mit `codesign --verify --strict <Probe-Executable>` geprüft und tatsächlich
+gestartet werden. Fenster und Zähler sichtbar erfassen; Datei → Ende oder
+der Ende-Button beenden die Probe.
+
+Im Textfeld zählt die Probe KeyDown/KeyUp/KeyPress, am Zählen-Button Click,
+auf freier Formfläche MouseDown/MouseUp/MouseMove. Ein einzelnes `a` ohne
+Halten erzeugt genau Down 97, Press 97, Up 97. Ein zusätzlicher roher
+Release darf keine zweite BASIC-Zustellung erzeugen. Erweiterte Tasten
+führen im bestehenden Forms-Vertrag KeyCode 0 und kein KeyPress; ihre
+Identität wird deshalb zusätzlich in der Rohdiagnose geprüft. Modifierbits
+werden im Log mitgeschrieben. Repeat bei absichtlich gehaltenen Tasten ist
+von ungewollter Doppelzustellung zu unterscheiden.
+
+Rohdiagnose aus dem bestehenden Spike:
+
+```sh
+cargo build --locked --release -p tb-ui --features terminal --example spike
+# Auf Windows: spike.exe; --log verlangt eine noch nicht existierende Datei.
+target/release/examples/spike --log /tmp/tb-raw-events.txt
+```
+
+Die Diagnose protokolliert nummerierte Crossterm-Ereignisse einschließlich
+Press/Release/Repeat, Modifier, Mauskoordinaten und Resize. Esc beendet sie.
+Sie prüft den Eingang; das Formularlog prüft die BASIC-Wirkung. Beide müssen
+zur jeweiligen physischen Einzelfolge passen. Diagnose und Formular werden
+nacheinander mit derselben Belegung geprüft, nicht als vermeintlich identischer
+Eventstream zweier gleichzeitiger Empfänger.
+
+## Bedienfolge pro Matrixzelle
+
+Für IDE-Tasten ein kleines Modul mit mehreren Anweisungen, `STOP`, einer
+Prozedur und gesetztem Breakpoint bereithalten. Tests im jeweils angegebenen
+Kontext ausführen. Die Rohdiagnose und die native Formularprobe mit F1 bis
+F12 zusätzlich einzeln prüfen; im nativen Textfeld müssen je zugestellter
+Funktionstaste genau ein Down/Up-Paar und kein KeyPress erscheinen.
+
+| Taste | IDE-Kontext und sichtbares Soll |
+|---|---|
+| F1 | Codekontext: passende Hilfe; Shift+F1 Using Help; Alt+F1 zurück, Ctrl+F1 nächstes Thema |
+| F2 | Form/Projekt: Code öffnen; im Designer Value-Box fokussieren |
+| F3 | Nach vorbereiteter Suche: nächsten Treffer markieren |
+| F4 | Output Screen öffnen/zurück; Ctrl+F4 Fenster schließen; Alt+F4 Exit-Dialog |
+| F5 | STOP/Breakpoint: fortsetzen; Shift+F5 neu starten; Ctrl+F5 Fenster wiederherstellen |
+| F6 | Nächstes Fenster; Shift+F6 vorheriges, Fokus sichtbar |
+| F7 | Pausierter Code: bis Cursor laufen; Ctrl+F7 Fensterverschiebung |
+| F8 | Einzelschritt; Ctrl+F8 Fenstergröße; Shift+F8 vorherige History-Position bei aktivierter History |
+| F9 | Breakpoint einmal umschalten; Shift+F9 Instant Watch; Ctrl+F9 minimieren |
+| F10 | Prozedurschritt; im Designer Properties/Menü wechseln; Ctrl+F10 maximieren; Shift+F10 nächste History-Position |
+| F11 | Menü aktivieren und Eintrag mit Pfeilen/Enter ausführen |
+| F12 | Event Procedures; Shift+F12 Form Designer |
+
+Nach jeder IDE-Aktion bei laufender Formularprobe deren Log prüfen: Die
+IDE-Taste darf nicht zusätzlich als BASIC-Ereignis auftauchen. Umgekehrt
+muss ein normales Zeichen im aktiven Output genau einmal in der Probe
+ankommen. Editor-Kopieren mit Ctrl+C verändert weder Programmzustand noch
+Formularlog; im Output muss Ctrl+C den BASIC-Lauf unterbrechen. Ctrl+Break
+prüft denselben Abbruchweg. Nach Break/Continue ein weiteres Zeichen senden:
+es darf kein altes Ereignis erneut zugestellt werden.
+
+Weitere Pflichtfolgen:
+
+- Alt+F und Menümnemonics, Escape und Tab/Shift+Tab: Menü/Dialog öffnet,
+  genau eine Aktion, korrekt zurückkehrender Fokus; Formularlog ohne Leck.
+- Ein Klick auf Zählen: Click-Zähler steigt genau um eins. Mausdruck und
+  Loslassen auf freier Formfläche: genau ein passendes Logpaar; Mausbewegung
+  erzeugt Move-Einträge ohne Click. Bewegung darf vom Emulator zusammengefasst
+  werden; Koordinaten und logische Ereignisse müssen konsistent sein.
+- Unicode in Form und Editor (`Äöß`, `中界`, Rahmen): keine versetzten
+  Folgezeichen oder zerstörten Rahmen. Farben und Attribute mit Spike,
+  IDE-Zustände und Profil-Gegenprobe nach `ide-referenz.md`, Abschnitt 4a.
+- Von 100×30 nach 79×24 und zurück: IDE zeigt nur den Größenhinweis und kehrt
+  ohne Dokument-/Cursorverlust zurück; native Probe bleibt konsistent und
+  bedienbar. Danach Mauskoordinaten und Formularzähler erneut prüfen.
+- `INPUT`/`LINE INPUT`: auf Eingabe warten, Text eingeben, abbrechen,
+  fortsetzen beziehungsweise neu starten. IDE und native Ausgabe prüfen.
+- Normaler Exit, `ERROR 6` und Shell-Rückkehr: Shell-Echo, Zeilenmodus,
+  sichtbarer Cursor und normale Anzeige erhalten. SHELL mit Exit 0 und 7,
+  nicht vorhandenem Kindkommando und unterbrochenem Kind prüfen. Anschließend
+  in der IDE Eingabe/Continue und abschließenden Exit prüfen.
+- Für Shell-Abbruch einen interaktiven Kindprozess verwenden und Ctrl+C
+  dort auslösen; sein Abbruch darf nicht nochmals an BASIC zugestellt werden.
+  Unter Unix unterstützt `sleep 30`, unter Windows ein passendes Kindkommando
+  die Probe. Keine Unix-Kommandozeile unverändert als Windows-Soll verwenden.
+
+## Befunde und Nachweisformat
+
+Je Testfall ID, Kontext, Eingabe, erwarteten Effekt, tatsächlichen Effekt,
+Zähler/Logbezug, Screenshot/Transkript und Status erfassen. Pro Shortcut, den
+OS oder Emulator abfängt: genaue Belegung benennen und denselben vorhandenen
+Menü-/Mausweg tatsächlich prüfen. Erst ein funktionierender Ersatzweg belegt
+eine Terminalgrenze; ein Produktfehler bleibt ein Befund. Derzeit ist kein
+solcher Ersatzweg durch eine echte Pflichtmatrixzelle verifiziert.
+
+Offene Zugänge, Stand 07.09.2026: Computer Use hat Terminal.app ausdrücklich
+gesperrt. Windows sowie Linux mit xterm/VTE sind noch nicht als Prüfsysteme
+zugänglich. Der erreichbare Gitea-Host ist Linux aarch64 ohne die benötigten
+GUI-Terminals; beim aktuellen Lesezugriff startet sein Runnercontainer
+wiederholt neu. Die Runnerkonfiguration wurde nicht geändert. Das sind
+fehlende Nachweise beziehungsweise Infrastrukturzustände, keine bestandenen
+Zieltests und keine unterstellten Produktfehler.
+
+Die aus 05a übernommenen offenen Aufgaben 1.2, 3.2 und 3.3 werden durch die
+Profil-Gegenprobe, sämtliche visuellen Matrixzellen und die abschließende
+befundfreie Verifizierung geschlossen. Für 06/07 müssen Prüfsystem,
+Toolrevision und konkrete Artefakte zusammenpassen. Nach Änderungen an
+Terminaladapter, Eingaberouting oder Theme sind die betroffenen Zielnachweise
+auf der neuen Revision erneut zu erheben.