Phase 6: P-Code-Bibliotheken und Linker abschließen, Cross-Buildplan festhalten

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

@@ -12,9 +12,10 @@ Phase 5 verwendete crossterm-Ereignisse, ratatui-TestBackend und `tests/support/
 
 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.
+3. Buildhost und Prüfsystem unterscheiden: Pakete entstehen in 06 zentral auf Linux arm64, echte Zielprüfungen laufen auf passenden Systemen; vier native Buildrunner sind keine Voraussetzung. Für 05 können Kandidaten aus lokalen Repository-Buildaufrufen verwendet werden, sodass kein Vorababschluss von 06 nötig ist. 06 prüft später die tatsächlich gepackte Revision. Die unveränderte `tests/libraries/portable.tbl` aus 03 mit `tests/support/library-abnahme.py` auf allen vier Zielen prüfen; TBL-Prüfsumme, Toolrevision, tatsächliches Host-Target und Ergebnisse einschließlich quellfreier TBC-/EXE-Nutzung und RUN festhalten.
+4. 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.
+5. 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.
+6. 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
 

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

@@ -7,6 +7,7 @@ Die bisherige headless Abnahme und der lokale Unix-PTY-Test beweisen nicht die e
 - 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.
+- Dieselben TBL-Bytes aus 03 auf allen vier echten Zielen mit separaten quellfreien TBC-/EXE-Verbrauchern prüfen und Prüfsumme/Ergebnis protokollieren.
 - Automatisierbare Zieltests von manuellen Emulatornachweisen unterscheiden; fehlende Systeme bleiben fehlende Nachweise.
 
 ## Capabilities

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

@@ -31,3 +31,10 @@ Einschränkungen SHALL reproduzierbar, plattformspezifisch und mit Auswirkung so
 #### 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
+
+### Requirement: Identische Bibliothek auf vier Zielsystemen
+Die Plattformabnahme SHALL dieselben unveränderten TBL-Bytes aus Change 03 auf Windows amd64, macOS arm64 und Linux amd64/arm64 mit separaten BASIC-Verbrauchern zu TBC und eigenständigem Executable verknüpfen und tatsächlich ausführen. Library-Quellen SHALL nicht benötigt werden; Resultate und RUN-Neustart SHALL dem gemeinsamen Soll entsprechen. Jeder Nachweis SHALL TBL-Prüfsumme, Toolrevision, tatsächliches Host-Target und Ergebnis enthalten. Der zentrale Cross-Build in Change 06 MUST NOT diese Zielausführung ersetzen; separate Prüfsysteme und dokumentierte manuelle Läufe sind zulässig.
+
+#### Scenario: Cross-Bau erfolgreich, Bibliothekslauf fehlt
+- **WHEN** alle vier Toolpakete gebaut sind, aber die gemeinsame TBL-Probe auf Windows noch nicht ausgeführt wurde
+- **THEN** bleibt der Windows-Verbrauchernachweis offen und die Plattformabnahme ist nicht abgeschlossen

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

@@ -2,7 +2,7 @@
 
 - [ ] 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.
+- [ ] 1.3 Die gemeinsame TBL-Verbraucherprobe aus 03 samt fester Prüfsumme in jede der vier Zielabnahmen aufnehmen (quellfreies TBC/EXE, RUN, tatsächliches Host-Target); 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
 
@@ -15,4 +15,4 @@
 ## 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.
+- [ ] 3.2 Automatisierbare Zielprüfungen an 06 übergeben und Matrixbericht fertigstellen; alle Pflichtzellen, Revisionen, vier Ergebnisse derselben TBL-Verbraucherprobe und tatsächlichen Ergebnisse müssen vor Abschluss vorliegen. Native Prüfsysteme dürfen separat vom zentralen Buildrunner betrieben und Nachweise dokumentiert manuell erhoben werden.