TerminalBasic/docs/plattformmatrix.md

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:

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:

<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:

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:

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.