Plan Phase 6 runtime, P-code libraries and Gitea releases

openspec/changes/phase-6-05-plattformmatrix/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-07

openspec/changes/phase-6-05-plattformmatrix/design.md

@@ -0,0 +1,27 @@
+## Context
+
+Phase 5 verwendete crossterm-Ereignisse, ratatui-TestBackend und `tests/support/ide-execution-pty.py`. Der vorhandene PTY-Test setzt Unix voraus. Die verbindlichen Release-Targets sind Windows amd64, macOS arm64 und Linux amd64/arm64; Plattform-/Emulatornachweise fehlen noch.
+
+## Goals / Non-Goals
+
+**Goals:** Tatsächliche Terminalgrenzen von Produktfehlern unterscheiden und sämtliche Zielkombinationen mit reproduzierbaren Bedienfolgen abnehmen.
+
+**Non-Goals:** Zweites UI-Toolkit, Emulation des historischen DOS-Programms, ein automatischer Test als Ersatz für reale Emulatorbedienung.
+
+## Decisions
+
+1. Eine Matrix mit Windows Terminal auf Windows amd64, Terminal.app auf macOS arm64 sowie xterm und einem VTE-Terminal auf beiden Linux-Architekturen verwenden. Konkrete installierte Versionsnummern sind Messmetadaten. Diese Kombinationen bilden den geplanten Mindestsatz, weitere Emulatoren sind keine Voraussetzung.
+2. Die vorhandenen Phase-5-Befehls-/Fokus-/Help-/Debuggerfälle zu kurzen tatsächlichen Eingabesequenzen verdichten. Screenshots/Transkripte, Eventdiagnosen und sichtbare Resultate werden je Matrixzelle festgehalten; ein Log „Prozess gestartet“ reicht nicht. F1–F12 und konfliktreiche Modifikatoren vollständig aufführen.
+3. Unix-PTY-Prüfung wiederverwenden; Windows-ConPTY-/Konsolenprüfung für automatisierbare Terminalübergänge ergänzen. Dieselben nativen Releaseprogramme und eine repräsentative exportierte Forms-Anwendung verwenden. Gitea-Jobs führen automatisierbare Prüfungen aus; echte Emulatorfolgen dürfen dokumentiert manuell erfolgen.
+4. Windows-/Unix-spezifische Tests und Hilfsprozesse mit passenden Plattformzweigen führen. Keine Unix-Shell-Kommandos unverändert auf Windows als vermeintliche Produktfehler werten. Produktsemantik und Testhost-Portabilität getrennt prüfen.
+5. Fehler im gemeinsamen Terminaladapter beheben und einen fokussierten Regressionstest ergänzen. Für vom Emulator reservierte Shortcuts einen bereits vorhandenen Menü-/Mausweg prüfen. Fehlende Pflichtfunktionen werden nicht als Terminalgrenze umetikettiert.
+
+## Risks / Trade-offs
+
+- CI ohne interaktiven Desktop → automatisierte Zieltests plus zugeordnete manuelle Emulatornachweise, keine Gleichsetzung beider Kategorien.
+- Nicht verfügbare Maschinen → benannter externer Nachweisbedarf; Change erst nach vollständiger Matrix abnehmen.
+- Globale Tastenbelegung des Benutzers beeinflusst Ergebnis → Terminalkonfiguration mitprotokollieren und Ersatzweg prüfen.
+
+## Migration Plan
+
+Bestehende Headless-Regressionen erhalten. Plattformkorrekturen inkrementell anwenden; Nachweise mit geprüfter Revision ablegen. Matrix an 06 und 07 übergeben; ihre Gültigkeit bei Änderungen am Terminaladapter oder Hostpfad erneut prüfen.

openspec/changes/phase-6-05-plattformmatrix/proposal.md

@@ -0,0 +1,24 @@
+## Why
+
+Die bisherige headless Abnahme und der lokale Unix-PTY-Test beweisen nicht die echte Terminalbedienung auf allen Release-Zielen. Phase 6 benötigt tatsächliche Zielausführung und eine nachprüfbare Matrix für Eingabe, Darstellung und Terminalwiederherstellung.
+
+## What Changes
+
+- Windows amd64 mit Windows Terminal, macOS arm64 und Linux amd64/arm64 mit mindestens zwei Terminalemulatoren systematisch abnehmen.
+- IDE und native Terminalprogramme mit F1–F12, Modifikatoren, Maus, Unicode, Resize, INPUT/Break und Shell-Rückkehr prüfen.
+- Ziel-/Terminalversionen, Eingabeprotokolle, Einschränkungen und funktionierende Ersatzwege dokumentieren.
+- Automatisierbare Zieltests von manuellen Emulatornachweisen unterscheiden; fehlende Systeme bleiben fehlende Nachweise.
+
+## Capabilities
+
+### New Capabilities
+
+- `terminal-plattformmatrix`: Verbindliche plattformübergreifende Terminalabnahme der vier Release-Ziele.
+
+### Modified Capabilities
+
+Keine. Bestehende IDE- und Host-Eingabeverträge bleiben maßgeblich.
+
+## Impact
+
+Terminaladapter in tb-ui/tb-ide, bisheriger PTY-Test, native Artefakttests aus 02–04 und neue Matrixdokumentation. Fachkorrekturen bleiben in bestehenden Adaptern. Abhängigkeiten: 01–04; automatisierte Aufrufe werden in 06 in Gitea Actions übernommen.

openspec/changes/phase-6-05-plattformmatrix/specs/terminal-plattformmatrix/spec.md

@@ -0,0 +1,33 @@
+## Purpose
+
+Belegt die tatsächliche Terminalbedienbarkeit der IDE und erzeugter Programme auf allen vereinbarten System-/Architektur-Kombinationen.
+
+## ADDED Requirements
+
+### Requirement: Vollständige Ziel- und Terminalmatrix
+Die Plattformabnahme SHALL Windows amd64 mit Windows Terminal, macOS arm64 mit einem benannten Terminal sowie Linux amd64 und arm64 jeweils mit mindestens zwei verschiedenen Terminalemulatoren prüfen. Je Matrixzelle SHALL Ziel, Betriebssystem-, Terminal- und Programmversion sowie die geprüfte Revision dokumentiert sein. Reines Cross-Kompilieren MUST NOT als Ausführungsnachweis gelten.
+
+#### Scenario: Ziel wurde nur gebaut
+- **WHEN** ein Linux-arm64-Artefakt zwar kompiliert, aber auf keinem passenden Ziel ausgeführt wurde
+- **THEN** bleibt dessen Ausführungsnachweis offen und die vollständige Plattformabnahme gilt nicht als bestanden
+
+### Requirement: Reale Eingabe und Darstellung
+Die Matrix SHALL F1–F12, relevante Shift-/Ctrl-/Alt-Kombinationen, Menünavigation, Mausdruck/-loslassen/-bewegung, Unicode, Farben und Größenänderung für IDE und repräsentative erzeugte Programme prüfen. Eingaben SHALL genau einmal dem zuständigen IDE- oder BASIC-Kontext zugeordnet werden. Unterhalb der Mindestgröße SHALL die Anwendung bedienbar wiederherstellbar bleiben.
+
+#### Scenario: Tastenkonflikt im Terminal
+- **WHEN** der Emulator eine IDE-Tastenkombination selbst abfängt
+- **THEN** dokumentiert der Nachweis diese Grenze und prüft einen erreichbaren alternativen Bedienweg, statt die nicht zugestellte Taste als erfolgreich zu werten
+
+### Requirement: Wiederherstellung nach Unterbrechung
+INPUT-Warten, Break/Continue, normaler Exit, Laufzeitfehler und Shell-Rückkehr SHALL Terminalmodus, Eingabe und Anzeige konsistent erhalten beziehungsweise wiederherstellen. Native Programme SHALL diese Regeln ebenso erfüllen wie die IDE.
+
+#### Scenario: Shell-Kind abbrechen
+- **WHEN** ein Shell-Kind während einer IDE- oder Programmsitzung unterbrochen wird
+- **THEN** bleibt die übergeordnete Sitzung bedienbar und nach ihrem Ende sind Terminalmodus und Anzeige wiederhergestellt
+
+### Requirement: Nachprüfbare Einschränkungen
+Einschränkungen SHALL reproduzierbar, plattformspezifisch und mit Auswirkung sowie Ersatzweg beschrieben sein. Ein Produktfehler ohne funktionsgleichen erreichbaren Weg MUST als offener Befund gelten; reine TestBackend-Ergebnisse MUST NOT manuelle Emulatorprüfungen ersetzen.
+
+#### Scenario: Fehlender Prüfrechner
+- **WHEN** eine erforderliche System-/Emulatorkombination nicht verfügbar ist
+- **THEN** nennt der Bericht die fehlende Kombination und führt sie bis zum tatsächlichen Nachweis offen

openspec/changes/phase-6-05-plattformmatrix/tasks.md

@@ -0,0 +1,18 @@
+## 1. Prüfpfade vorbereiten
+
+- [ ] 1.1 Verbindliche Matrix und kurze Bediensequenzen für die vier Targets anlegen; Windows Terminal, Terminal.app sowie xterm/VTE auf beiden Linux-Architekturen müssen konkrete Versions-/Revisionsfelder und erwartete Resultate besitzen.
+- [ ] 1.2 Bestehenden Unix-PTY-Test und passenden Windows-Konsolen-/ConPTY-Test für Shell, Abbruch und Wiederherstellung bereitstellen; positive Läufe und erzwungene Fehler dürfen keinen beschädigten Terminalmodus hinterlassen.
+- [ ] 1.3 IDE-/Programmprüfungen für F1–F12, Modifikatoren, Maus, Unicode/Attribute und Resize nachvollziehbar auflisten; jeder Fall muss sichtbaren Effekt und Ausschluss doppelter BASIC-Zustellung prüfen.
+
+## 2. Tatsächliche Zielabnahme
+
+- [ ] 2.1 Windows amd64 in Windows Terminal prüfen; Protokoll muss IDE, exportiertes Forms-Programm, INPUT/Break und Shell-Rückkehr mit tatsächlicher Zielausführung belegen.
+- [ ] 2.2 macOS arm64 in Terminal.app prüfen; zusätzlich finalisierte/signierte native Ausgaben starten und die Ergebnisse mit der Matrix abgleichen.
+- [ ] 2.3 Linux amd64 in xterm und einem VTE-Terminal prüfen; beide Emulatoren müssen dieselben Pflichtfunktionen beziehungsweise dokumentierte funktionierende Ersatzwege liefern.
+- [ ] 2.4 Linux arm64 in xterm und einem VTE-Terminal prüfen; Cross-Build allein darf keinen Fall abschließen.
+- [ ] 2.5 Gefundene Produktfehler im zuständigen Adapter beheben; gezielter Regressionstest und erneuter betroffener Emulatorlauf müssen den Befund schließen.
+
+## 3. Übergabe
+
+- [ ] 3.1 Terminalgrenzen und verifizierte Ersatzwege dokumentieren; kein Produktfehler oder fehlender Prüfrechner darf als bestandene Matrixzelle erscheinen.
+- [ ] 3.2 Automatisierbare Zielprüfungen an 06 übergeben und Matrixbericht fertigstellen; alle Pflichtzellen, Revisionen und tatsächlichen Ergebnisse müssen vor Abschluss vorliegen.