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