# 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 ` ü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 --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 --template -o ``` 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 ` 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.