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

openspec/changes/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/design.md

@@ -29,4 +29,4 @@
 
 ## Migration Plan
 
-Additive Dateiendung, MAK-Mitgliedsart und CLI-Befehle; reine Quellprojekte und vorhandenes vollständiges TBC behalten ihr Verhalten. Versionen bei inkompatiblen Änderungen explizit prüfen und Neubau der betroffenen Bibliothek verlangen. Keine Migration historischer DOS-LIB/QLB. IDE-Anbindung in 04, identische TBL auf allen Zielrunnern in 06, Benutzerweg in 07. Der verworfene native Bibliotheksentwurf war nicht implementiert und erfordert keine Produktdatenmigration.
+Additive Dateiendung, MAK-Mitgliedsart und CLI-Befehle; reine Quellprojekte und vorhandenes vollständiges TBC behalten ihr Verhalten. Versionen bei inkompatiblen Änderungen explizit prüfen und Neubau der betroffenen Bibliothek verlangen. Keine Migration historischer DOS-LIB/QLB. 03 wird mit Backend-/CLI-Regressionen, festem TBL-Artefakt samt Prüfsumme und Verbraucherprobe auf dem verfügbaren Host abgenommen. IDE-Anbindung in 04, echte Ausführung derselben TBL-Bytes auf allen vier Zielsystemen in 05, zentraler Cross-Paketbau und paketgebundene Zielnachweise in 06, Benutzerweg in 07. Diese Aufteilung ändert den Portabilitätsvertrag nicht; fehlende Zielausführungen bleiben dort offen. Der verworfene native Bibliotheksentwurf war nicht implementiert und erfordert keine Produktdatenmigration.

openspec/changes/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/proposal.md

@@ -8,6 +8,7 @@ BASIC wird als P-Code ausgeführt; wiederverwendbare BASIC-Bibliotheken benötig
 - `tbc build --library` erzeugt `.tbl`; `tbc link` verbindet ein Hauptprojekt und `.tbl`-Bibliotheken zu einem vollständigen `.tbc` beziehungsweise über `--exe` mit der passenden `tbrt`-Vorlage zu einem eigenständigen Executable.
 - Den vorhandenen Projektlinker erweitern: Bibliotheken sind ohne ihre BAS-/FRM-/Include-Quellen nutzbar, Auflösung und BASIC-Semantik bleiben gemeinsam.
 - `.tbl`-Verweise als geordnete `.MAK`-Einträge sowie explizite CLI-Eingaben unterstützen. Fehlende oder inkompatible Symbole, Typen, Formate und Abhängigkeiten vor Ausgabe diagnostizieren.
+- Die Abnahme dieses Changes umfasst Backend/CLI, ein festes gemeinsames TBL-Testartefakt und die lokal ausgeführte Verbraucherprobe. Echte Vierzielnachweise werden verbindlich in 05 und für Releasepakete in 06 erbracht.
 - Erzeugung und Linken benötigen weder C-/Rust-Compiler noch nativen Linker beim Anwender. Die IDE bindet denselben Dienst in 04 an.
 
 ## Capabilities
@@ -22,4 +23,4 @@ Keine. TBL ist eine additive Projekt-/Buildfähigkeit; die Anpassung der bisheri
 
 ## Impact
 
-`tb-vm/src/project.rs`, `bytecode.rs`, `project_io.rs`, Frontend-Deklarationsimport und `tb-cli/src/main.rs`; Wiederverwendung der sicheren Veröffentlichung und `tbrt`-Verpackung aus [02](../archive/2026-09-07-phase-6-02-native-executables/proposal.md). Abhängigkeit: 02. IDE-Dokumentmodell, Ausführung, Debugger und Make-Anbindung folgen in 04; plattformübergreifende Verbraucherprüfungen in 05/06, Dokumentation und Gesamtabnahme in 07. Dieser Entwurf ersetzt den noch nicht implementierten Entwurf `phase-6-03-native-bibliotheken` vollständig.
+`tb-vm/src/project.rs`, `bytecode.rs`, `project_io.rs`, Frontend-Deklarationsimport und `tb-cli/src/main.rs`; Wiederverwendung der sicheren Veröffentlichung und `tbrt`-Verpackung aus [02](../2026-09-07-phase-6-02-native-executables/proposal.md). Abhängigkeit: 02. IDE-Dokumentmodell, Ausführung, Debugger und Make-Anbindung folgen in 04; plattformübergreifende Verbraucherprüfungen in 05/06, Dokumentation und Gesamtabnahme in 07. Dieser Entwurf ersetzt den noch nicht implementierten Entwurf `phase-6-03-native-bibliotheken` vollständig.

openspec/changes/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/tasks.md

@@ -1,24 +1,33 @@
 ## 1. Bibliotheksprodukt und Format
 
-- [ ] 1.1 AST-abhängige Linkinformationen in kompakte gemeinsame Modulmetadaten überführen; bestehende reine Quellprojekt-/Cachetests müssen Verhalten, Diagnosen und Wiederverwendung erhalten.
-- [ ] 1.2 Versionierten TBL-Leser/-Schreiber für unverknüpfte Produkte, Deklarationen, COMMON, Forms und Quellorte implementieren; Roundtrip sowie beschädigte Längen, Referenzen, Versionen und Grenzwerte prüfen.
-- [ ] 1.3 Library-Kompilation mit typisierten offenen Imports und bestehender Exportsichtbarkeit anbinden; eine Bibliothek mit DECLARE-Import muss ohne dessen Implementierung baubar sein, ungültige Deklarationen müssen scheitern.
+- [x] 1.1 AST-abhängige Linkinformationen in kompakte gemeinsame Modulmetadaten überführen; bestehende reine Quellprojekt-/Cachetests müssen Verhalten, Diagnosen und Wiederverwendung erhalten.
+- [x] 1.2 Versionierten TBL-Leser/-Schreiber für unverknüpfte Produkte, Deklarationen, COMMON, Forms und Quellorte implementieren; Roundtrip sowie beschädigte Längen, Referenzen, Versionen und Grenzwerte prüfen.
+- [x] 1.3 Library-Kompilation mit typisierten offenen Imports und bestehender Exportsichtbarkeit anbinden; eine Bibliothek mit DECLARE-Import muss ohne dessen Implementierung baubar sein, ungültige Deklarationen müssen scheitern.
 
 ## 2. Gemeinsames Linken
 
-- [ ] 2.1 TBL-Deklarationen vor der Verbraucher-Semantikanalyse importieren und Quell-/Libraryprodukte gemeinsam verknüpfen; zwei Bibliotheken mit Abhängigkeit müssen ohne Bibliotheksquellen funktionieren, fehlende/mehrdeutige/inkompatible Symbole und doppelte Module müssen konkrete Diagnosen liefern.
-- [ ] 2.2 Vollständiges Remapping und Initialisierung prüfen; Vergleichsprojekte müssen BYREF/BYVAL, Arrays, UDTs, COMMON, Konstanten, DATA/RESTORE, Forms-Ereignisse, Fehlerorte und RUN mit äquivalenten Quellmodulen abgleichen.
-- [ ] 2.3 MAK-Laden/-Schreiben um geordnete TBL-Einträge erweitern; Verschieben/Save-As, Fallunabhängigkeit, Duplikate, fehlende Dateien, TBL als unzulässige Startdatei und unveränderte reine Quellprojekte testen.
-- [ ] 2.4 Bibliotheksinhalt in die Compiler-Cacheidentität aufnehmen; Austausch einer TBL einschließlich gleicher Dateigröße muss Linkresultat und betroffene Deklarationen aktualisieren.
+- [x] 2.1 TBL-Deklarationen vor der Verbraucher-Semantikanalyse importieren und Quell-/Libraryprodukte gemeinsam verknüpfen; zwei Bibliotheken mit Abhängigkeit müssen ohne Bibliotheksquellen funktionieren, fehlende/mehrdeutige/inkompatible Symbole und doppelte Module müssen konkrete Diagnosen liefern.
+- [x] 2.2 Vollständiges Remapping und Initialisierung prüfen; Vergleichsprojekte müssen BYREF/BYVAL, Arrays, UDTs, COMMON, Konstanten, DATA/RESTORE, Forms-Ereignisse, Fehlerorte und RUN mit äquivalenten Quellmodulen abgleichen.
+- [x] 2.3 MAK-Laden/-Schreiben um geordnete TBL-Einträge erweitern; Verschieben/Save-As, Fallunabhängigkeit, Duplikate, fehlende Dateien, TBL als unzulässige Startdatei und unveränderte reine Quellprojekte testen.
+- [x] 2.4 Bibliotheksinhalt in die Compiler-Cacheidentität aufnehmen; Austausch einer TBL einschließlich gleicher Dateigröße muss Linkresultat und betroffene Deklarationen aktualisieren.
 
 ## 3. CLI und Ausgabe
 
-- [ ] 3.1 `tbc build --library` und `tbc link` mit expliziten TBL-Eingaben implementieren sowie run/build/check für MAK-Bibliotheken anbinden; CLI-Tests müssen gültige Beispiele, unveränderten TBC-Standard und unzulässige Flag-/Eingabekombinationen prüfen.
-- [ ] 3.2 `tbc link --exe` mit der tbrt-Verpackung aus 02 verbinden; ein ohne Bibliotheksquellen gelinktes Programm muss anschließend ohne TBL/TBC/tbrt/tb/tbc-Installation starten und dieselben Resultate liefern.
-- [ ] 3.3 TBL-/Linkausgabe über die geschützte Veröffentlichung aus 02 führen; Abbruch, Schreibfehler, No-clobber-Konflikt und Ausgabe auf eine Eingabebibliothek dürfen keine Eingabedaten oder alten Ziele beschädigen.
+- [x] 3.1 `tbc build --library` und `tbc link` mit expliziten TBL-Eingaben implementieren sowie run/build/check für MAK-Bibliotheken anbinden; CLI-Tests müssen gültige Beispiele, unveränderten TBC-Standard und unzulässige Flag-/Eingabekombinationen prüfen.
+- [x] 3.2 `tbc link --exe` mit der tbrt-Verpackung aus 02 verbinden; ein ohne Bibliotheksquellen gelinktes Programm muss anschließend ohne TBL/TBC/tbrt/tb/tbc-Installation starten und dieselben Resultate liefern.
+- [x] 3.3 TBL-/Linkausgabe über die geschützte Veröffentlichung aus 02 führen; Abbruch, Schreibfehler, No-clobber-Konflikt und Ausgabe auf eine Eingabebibliothek dürfen keine Eingabedaten oder alten Ziele beschädigen.
 
 ## 4. Abnahme und Übergabe
 
-- [ ] 4.1 Ein identisches TBL-Artefakt auf Windows amd64, macOS arm64 und Linux amd64/arm64 mit separaten BASIC-Verbrauchern verknüpfen; Prüfsumme und echte Zielausführung müssen Portabilität ohne Neubau der Library beweisen.
-- [ ] 4.2 Format-/Befehls-/Initialisierungsvertrag und Werkzeugfreiheit dokumentieren; Beispiele müssen mit ausgelieferten TB-Tools ohne C-/Rust-Compiler oder nativen Linker laufen und fehlende EXE-Voraussetzungen korrekt benennen.
-- [ ] 4.3 Sämtliche Spec-Szenarien mit Ergebnissen zuordnen und Übergabe an IDE 04/Actions 06 vorbereiten; fokussierte Link-/CLI-Tests, Workspace-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen ohne offenen Befund bestehen.
+- [x] 4.1 Ein festes gemeinsames TBL-Artefakt mit Prüfsumme und reproduzierbarer quellfreier TBC-/EXE-Verbraucherprobe bereitstellen und auf dem verfügbaren Host ausführen; echte Läufe derselben Bytes auf Windows amd64, macOS arm64 und Linux amd64/arm64 mit Befehlen und Erwartungen verbindlich an 05/06 übergeben.
+- [x] 4.2 Format-/Befehls-/Initialisierungsvertrag und Werkzeugfreiheit dokumentieren; Beispiele müssen mit ausgelieferten TB-Tools ohne C-/Rust-Compiler oder nativen Linker laufen und fehlende EXE-Voraussetzungen korrekt benennen.
+- [x] 4.3 Sämtliche Spec-Szenarien mit lokalen Ergebnissen beziehungsweise ausdrücklich in 05/06 ausstehenden Zielnachweisen zuordnen und Übergabe an IDE 04/Plattformabnahme 05/Actions 06 vorbereiten; fokussierte Link-/CLI-Tests, Workspace-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen ohne offenen Befund bestehen.
+
+## Abnahmestand am 2026-09-07
+
+Die Implementierung und lokalen Prüfungen sind abgeschlossen (13/13).
+Nach der am 2026-09-07 vom Benutzer bestätigten Aufteilung gehören die echten
+Vierziel-Verbraucherläufe in 05/06. macOS arm64 wurde mit dem gemeinsamen
+TBL-Artefakt geprüft; Windows amd64 und Linux amd64/arm64 sind noch nicht
+ausgeführt. Diese Nachweise bleiben in den Folgechanges offen und werden
+nicht als bestanden gezählt. Ergebnisse und Aufruf: [verification.md](verification.md).

openspec/changes/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/verification.md

@@ -0,0 +1,122 @@
+# Verifikation: phase-6-03-pcode-bibliotheken-und-linker
+
+Stand: 2026-09-07. Verifiziert wurde die lokale Implementierung auf Basis von
+`60d37ec79ddfdebdfa71b893bf6b3a141d20ac3c` auf `main`. Der vorangehende Change
+02 wurde synchronisiert, als `2026-09-07-phase-6-02-native-executables`
+archiviert und mit diesem Commit auf `origin/main` bestätigt. Change 03 wurde am 2026-09-07 nach Spec-Synchronisierung archiviert;
+dieser Bericht wird gemeinsam mit der Implementierung committed.
+
+## Ergebnis
+
+| Dimension | Ergebnis |
+|---|---|
+| Vollständigkeit | 13/13 Aufgaben gemäß bestätigter Abnahmeaufteilung abgeschlossen |
+| Implementierung | Alle sechs Requirements im Backend-/CLI-Umfang von 03 umgesetzt; IDE-Anbindung gemäß Proposal in 04 |
+| Szenarien | Sechs vollständig lokal nachgewiesen; Vierziel-Portabilität auf macOS arm64 nachgewiesen, drei Zielausführungen fehlen |
+| Korrektheit | Keine offenen Codebefunde nach Korrektur und erneuten Prüfungen |
+| Kohärenz | Gemeinsamer Projektcompiler/Linker, kompakte Metadaten, bestehender TBC-Codec und sichere Veröffentlichung wiederverwendet |
+| Gesamtabnahme | Change 03 ohne offene Befunde; Vierziel-/Releaseabnahme in 05/06 noch offen |
+
+## Bestätigte Abnahmeaufteilung
+
+Am 2026-09-07 bestätigte der Benutzer den zentralen Cross-Paketbau auf dem
+vorhandenen Linux-arm64-Gitea-Runner und die getrennte echte Plattformabnahme.
+PLAN, Proposal, Design und Tasks ordnen die vollständigen Zielausführungen
+jetzt konsistent 05/06 zu. Der bisherige Befund zu Aufgabe 4.1 ist damit durch
+eine ausdrücklich bestätigte Änderung der Abnahmezuständigkeit geschlossen,
+nicht durch zusätzliche behauptete Testläufe. Der Portabilitätsvertrag bleibt
+unverändert. Die lokale Implementierungsverifikation enthält keine Codebefunde.
+
+Dieselben TBL-Bytes wurden auf macOS arm64 ohne Bibliotheksquellen verknüpft
+und als eigenständiges Executable ausgeführt. Windows amd64 sowie Linux amd64
+und arm64 wurden noch nicht ausgeführt; Linux-arm64-`cargo check` beweist keine
+Ausführung. Der vorhandene entfernte Gitea-Runner wurde als Linux aarch64
+bestätigt; TerminalBasic wurde darauf noch nicht über die Vierzielmatrix gebaut.
+
+05 muss `python3 tests/support/library-abnahme.py --bin-dir <native-TB-Werkzeuge>`
+mit unveränderter `tests/libraries/portable.tbl` auf allen vier echten Zielen
+nachweisen. 06 übernimmt dies für die entpackten Releasepakete und bindet die
+Nachweise an Revision und Paketprüfsumme; fehlende Nachweise sperren die
+Releasefreigabe. Die bisherigen lokalen Testergebnisse bleiben unverändert.
+
+## Requirement- und Szenarioabgleich
+
+| Requirement / Szenario | Umsetzung und Nachweis |
+|---|---|
+| Portables TBL-Format / Bibliothek auf anderem Ziel | [library.rs](../../../../crates/tb-vm/src/library.rs): TBL 1, P-Code 4, gemeinsamer Runtime-Vertrag 1, feste Breiten, Länge/Prüfsumme, unverknüpfte Modulprodukte, Export-/Importverträge. Gemeinsames [TBL-Artefakt](../../../../tests/libraries/portable.tbl) und [Zielprobe](../../../../tests/support/library-abnahme.py). macOS bestanden; drei Zielausführungen offen. |
+| Gemeinsamer Linkbefehl / quellfreie Nutzung bis EXE | [CLI](../../../../crates/tb-cli/src/main.rs), `ProjectSources::compile`/`compile_library`, `ProjectCompiler::link_library`. Der Verbrauchercheck löscht Quelle, TBL, TBC und Vorlage vor dem EXE-Lauf mit leerem PATH; Ausgabe und Dateieffekte stimmen einschließlich RUN. |
+| Explizite Bibliothekszuordnung / verschobenes Projekt | [project_io.rs](../../../../crates/tb-vm/src/project_io.rs): geordnete TBL-Mitglieder, Startmodul zuerst, Zusatzbibliotheken danach, fallunabhängige Pfade. [Projekt-I/O-Tests](../../../../crates/tb-vm/tests/project_io.rs) prüfen Verschieben, Save As, fehlende Datei mit MAK-Bezug, Duplikate, TBL nicht als Text/Startdatei. |
+| Typgeprüfte Verknüpfung / A benötigt B | [Projektlinker](../../../../crates/tb-vm/src/project.rs) bindet vor der Verbraucher-Semantik Deklarationen und danach vollständige Signaturen. [Library-Tests](../../../../crates/tb-vm/tests/library.rs) prüfen offene Imports, zwei quellfreie Bibliotheken, fehlendes B, Parameter-/Ergebnistypen, COMMON-Grenzen, ungültige Deklarationen und flache Abhängigkeiten. |
+| Typgeprüfte Verknüpfung / mehrdeutiges Symbol | Library-Tests mit zwei Definitionen und explizitem sowie implizitem Verbraucher-DECLARE: Konflikt nennt beide Herkunftsmodule; keine zufällige Auswahl. Doppelte Modulidentitäten werden separat abgewiesen. |
+| BASIC-Semantik / Quellmodule durch TBL ersetzen | Vergleichsprojekte prüfen BYREF/BYVAL, Arrays, UDTs/feste Strings, Konstanten, COMMON, DATA/RESTORE und Modulreihenfolge. Getrennte Forms-Libraries prüfen verschachtelte gleiche Controlnamen, Designarrays, Anfangsdaten und Form_Load-Ereignisse. Include-Fehler behalten physischen Ort und ERL=200. Der native Verbraucher erzeugt nach RUN nachweislich erneut frische Bibliotheksvariablen, DATA und Bildschirmzustand. |
+| Validierung/geschützte Ausgabe / beschädigte Datei oder Ausgabe auf Eingabe | TBL-Leser prüft Header, Versionen, Prüfsumme, Abschnitte, Tags, Referenzen, Export-/Code-Verträge und Grenzen. Tests für alle abgeschnittenen Präfixe, nachberechnete Prüfsummen auf ungültigen Strukturen und kontrollierte Mutationen. [CLI-Tests](../../../../crates/tb-cli/tests/project.rs) prüfen Ausgabe auf TBL/MAK, No-clobber, ungültige Optionen und defekte Eingaben ohne Änderung alter Ziele. Der gemeinsame [Publikationstest](../../../../crates/tb-export/src/tests.rs) prüft Abbruch vor/nach Vorbereitung, Schreibfehler, konkurrierende Änderungen und Bereinigung. |
+
+## Behobene Befunde aus den Prüfläufen
+
+- Die Quelltabellen-Normalisierung erzeugte zunächst zusätzliche Einträge und
+  verschob IDE-Bindungsorte. Module behalten jetzt ihre vollständige lokale
+  Quelltabellenreihenfolge; die vorhandenen vier betroffenen Designerfälle,
+  Projekt-, Cache- und Debuggertests bestehen. Bei eingeschobenen TBL-Modulen
+  bleiben außerdem die tatsächlichen Modul-IDs der Quell-Debugkontexte erhalten.
+- Objektzuordnung nur über Namen und übergeordneten Namen kollidierte bei
+  gleich benannten verschachtelten Controls in zwei Forms. Der Linker verwendet
+  den remappten Eltern-Slot; getrennte Form-Libraries ergeben dieselben Ereignisse
+  und Anfangswerte wie die äquivalenten Quellen.
+- Die strengere Importprüfung behandelte den unbenutzten NotReserved-Prototyp
+  in QLBVIEW als Linkabhängigkeit. Nicht referenzierte ungebundene Prototypen
+  werden aus dem Endprodukt entfernt; tatsächliche Aufrufe müssen auch in
+  unaufgerufenen mitgelieferten Prozeduren gebunden sein. Eine spätere
+  Debug-Ausführung eines entfernten Prototyps liefert ebenfalls eine Diagnose.
+  Der Fremdprogramm-Abnahmesatz besteht wieder vollständig.
+- Zusätzliche Grenz-/Vertragsprüfungen verhindern unter anderem leere
+  Konstantenexporte, inkonsistente COMMON-Slots und Überlauf remappter Tabellen.
+  Bytecode-Mutationen mit erneut berechneter Prüfsumme werden kontrolliert
+  behandelt; es trat keine Panic im Reader-/Linkpfad auf.
+
+## Ausgeführte Prüfungen
+
+| Prüfung | Ergebnis |
+|---|---|
+| `cargo test --locked --workspace` auf endgültigem Stand | 625 bestanden, 0 fehlgeschlagen, 2 vorgesehen ignoriert |
+| `release-abnahme.py --vbdos-repo /tmp/terminalbasic-vbdos-evidence` | Vollständig bestanden: Fremdbestand, Workspace, Inventar, Format, Clippy, Benchmarks |
+| Explizite Fremdabnahme in fixierter Revision | Drei Tests einschließlich 14 Programm-Ausführungen bestanden; kein Emulator/GUI gestartet |
+| Nachträglich ergänzte gezielte Library-/Projekt-/CLI-Prüfungen | Bestanden, einschließlich Include-ERL, identischer Dateigröße bei reinem Codeaustausch und TBL als unzulässigem Startprodukt |
+| `cargo fmt --all -- --check` | Bestanden |
+| `cargo clippy --locked --workspace --all-targets -- -D warnings` | Bestanden auf endgültigem Stand |
+| `openspec validate --all --strict` | 30 Elemente bestanden, 0 fehlgeschlagen; rein informative Längenhinweise in bestehenden Requirements |
+| Release-Build von `tb-cli`, `tb-runner`, `tb-export` | Bestanden |
+| `library-abnahme.py` auf macOS arm64 | Echter quellfreier TBL→TBC/EXE-Verbraucher und RUN bestanden |
+| `native-abnahme.py --target aarch64-apple-darwin` | Alle EXE-, PTY-, Abbruch-, Signierungs- und Beschädigungsprüfungen bestanden |
+| Linux arm64: `cargo check --locked --target aarch64-unknown-linux-gnu -p tb-cli -p tb-runner -p tb-export` | Bestanden; keine Zielausführung |
+| Runtime-Prüfung | `tbrt` 3.022.416 Bytes; keine BASIC-Parser-/Quellcompiler-Symbole; native Abhängigkeiten nur libiconv und libSystem |
+
+Die beiden regulär ignorierten Workspace-Tests sind bewusste Golden-Erzeugung
+und der externe Fremdbestand; letzterer wurde im gesonderten Abnahmesatz explizit
+ausgeführt. Das Inventar meldet 795 implementiert, 50 Non-Features, 0 offen.
+
+Leistung: Einzelmodul 0,79 ms bei 50-ms-Budget, Projekt mit 49.760 Zeilen
+100 ms bei 1000-ms-Budget; Cacheänderung 0,77 ms/28,37 ms für 1/20 Module.
+VM: INTEGER 1289 ms, DOUBLE 589 ms, BYREF-Aufrufe 148 ms,
+String-Funktionen 114 ms. Alle geltenden Budgets bestanden.
+
+Reproduzierbares gemeinsames Artefakt:
+`5d25c2f8c95ae535e55a6c84c1ddd0d964358863f4f3c780c50ac4a2eb3594df`
+(SHA-256 von `tests/libraries/portable.tbl`). Der aktuelle macOS-Nachweis meldet
+`native_execution=true`, `source_free=true`, `run_reset=true`.
+
+Lokale Rohprotokolle: `/tmp/tb-phase6-03-release-abnahme.log`,
+`/tmp/tb-phase6-03-workspace-final.log`, `/tmp/tb-phase6-03-focused.log`,
+`/tmp/tb-phase6-03-clippy-final.log`, `/tmp/tb-phase6-03-openspec.log`,
+`/tmp/tb-phase6-03-library-native.log`, `/tmp/tb-phase6-03-native-regression.log`,
+`/tmp/tb-phase6-03-linux-check.log`, `/tmp/tb-phase6-03-runtime-audit.log`.
+
+## Übergabe
+
+[Format und Befehle](../../../../docs/pcode-bibliotheken.md) beschreiben das
+Binärformat, Auflösung, Initialisierung, geschützte Ausgabe und Systemvoraussetzungen.
+04 erhält den gemeinsamen Dienst für IDE-Dokumentmodell und Make-Aktionen.
+05/06 erhalten ein einziges gespeichertes TBL-Artefakt und denselben
+plattformprüfenden Verbraucheraufruf für echte Zielsysteme; der Paketbau erfolgt
+zentral auf dem Linux-arm64-Gitea-Runner. Die fehlenden
+Zielnachweise sind noch offen und werden nicht durch das geplante spätere
+CI-Setup ersetzt.

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.

openspec/changes/phase-6-06-gitea-actions-und-releases/design.md

@@ -1,6 +1,6 @@
 ## Context
 
-Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Im Repository existieren noch keine Actions-Workflows. Runner-Verfügbarkeit, Labels und Release-Zugang wurden nicht behauptet oder verändert. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
+Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Im Repository existieren noch keine Actions-Workflows. Der bestehende Runner wurde am 2026-09-07 per read-only SSH als Linux aarch64 mit laufendem Gitea-Runner-Container bestätigt. Andere Projekte am Origin verwenden bereits `linux-arm64` mit cargo-zigbuild und cargo-xwin. Das tatsächliche Label, Toolchain-/SDK-Versionen und der Release-Zugang werden bei der Anbindung dieses Projekts geprüft; eine erfolgreiche TerminalBasic-Cross-Matrix wurde noch nicht nachgewiesen. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
 
 ## Goals / Non-Goals
 
@@ -10,19 +10,19 @@ Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versio
 
 ## Decisions
 
-1. `.gitea/workflows/` verwendet explizite Einzel-Labels für die vier nativen Runner: Windows-amd64, macOS-arm64, Linux-amd64, Linux-arm64. Tatsächliche Labels bei Anbindung inventarisieren und dokumentieren; nicht davon ausgehen, dass mehrere Labels logisch UND bedeuten. Runner werden passend zum Ziel betrieben. Grundlage: [Gitea-1.25-Runnerdokumentation](https://docs.gitea.com/1.25/usage/actions/act-runner/).
+1. `.gitea/workflows/` nutzt den vorhandenen Linux-arm64-Runner für alle vier Build-/Paketziele. Vorhandene Workflowmuster der anderen Origin-Projekte wiederverwenden: cargo-zigbuild für Linux amd64 und macOS arm64, cargo-xwin für Windows amd64/MSVC; Linux arm64 nativ oder mit derselben festgelegten Linux-Zielbaseline. Container/Tools und benötigte SDKs/Sysroots reproduzierbar pinnen; konkrete Rust-/OS-/glibc-Versionen mit TerminalBasic prüfen. Das Runnerlabel `linux-arm64` bei Anbindung bestätigen. Vier native Buildrunner sind nicht erforderlich. `build-runtime.py` erzeugt Vorlagenmetadaten mit dem Hostwerkzeug für das jeweilige Target; fremde Executables werden auf dem Buildhost nicht nativ ausgeführt.
 2. Wiederverwendbare Repository-Skripte erledigen Build, Tests, Paketierung und Prüfung auch lokal. Source-Checkout vom Gitea-Origin, alle zusätzlichen Actions nur über explizite Gitea-URLs und feste Revisionen, soweit überhaupt nötig; keine implizite fremde Action-Auflösung. Rust und benötigte Systemwerkzeuge versioniert bereitstellen. Server-/Runner-Kompatibilität praktisch prüfen, statt lediglich YAML zu validieren.
 3. Matrixprodukte: `terminalbasic-<version>-windows-amd64.7z`, `terminalbasic-<version>-macos-arm64.tar.gz`, `terminalbasic-<version>-linux-amd64.tar.gz`, `terminalbasic-<version>-linux-arm64.tar.gz`. Windows enthält `tb.exe`/`tbc.exe`/`tbrt.exe`, übrige `tb`/`tbc`/`tbrt`; tbrt ist die native Exportvorlage, dazu deren Metadaten, Lizenz, Kurzinstallation. Archive dürfen keine Buildverzeichnis-/Quellbaumabhängigkeiten haben. Exportierte Anwenderprogramme bleiben normale native Einzelartefakte; die Archivformate betreffen die Distribution.
-4. Windows nutzt 7-Zip zum Erzeugen/Prüfen, Unix tar+gzip unter Erhalt der Executable-Bits. Jobs entpacken das fertige Archiv in ein neues Verzeichnis und führen die darin liegenden Tools aus. Ein gemeinsames TBL-Testartefakt wird einmal erzeugt und mit nachgewiesen identischen Bytes auf allen vier Zieljobs verwendet. Separate BASIC-Verbraucher werden mit den entpackten TB-Tools verknüpft, als TBC ausgeführt und mit tbrt als EXE exportiert. Library-Quellen sind dabei nicht verfügbar. Erzeugung/Linken werden in einer Umgebung ohne erreichbaren C-/Rust-Compiler oder nativen Linker geprüft; Systemhilfen zur EXE-Finalisierung dürfen verfügbar bleiben. Fertige EXEs laufen anschließend ohne externe TBL/TBC oder TB-Installation.
-5. In jedem Zieljob `cargo test --workspace`; Clippy/Formatprüfung zentral mit passender Toolchain, native Tests aus 02/03/04 und automatisierbare Plattformtests aus 05 auf ihren tatsächlichen Zielen. Den fixierten Fremdprogrammbestand ausdrücklich im erforderlichen Abnahmelauf bereitstellen. Compile-/VM-Messungen auf dokumentiertem Referenzrunner statt instabiler Debug-Zeitlimits in allen Jobs.
-6. Gitea-Release erst nach allen Pflichtjobs und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. PR-Jobs ohne Veröffentlichungsrechte und ohne Release-Secrets; fremder PR-Code darf nicht mit solchen Rechten auf persönlichen Runnern laufen. Zugangswerte werden als Gitea-Secrets konfiguriert, nicht committed. Tests erzeugen keine öffentlichen Testreleases.
+4. Der Linux-Buildhost erzeugt/prüft Windows-Archive mit 7-Zip und Unix-Archive mit tar+gzip unter Erhalt der Executable-Bits. Inhalts-/Formatprüfungen laufen dort; tatsächliche Start-/Exportprüfungen verwenden neu entpackte Pakete auf passenden Zielsystemen aus 05, automatisiert oder dokumentiert manuell. Externe Nachweise müssen an Revision und exakte Paketprüfsumme gebunden und vor Freigabe geprüft sein. Ein gemeinsames TBL-Testartefakt wird einmal erzeugt und mit nachgewiesen identischen Bytes auf allen vier Zielsystemen verwendet. Separate BASIC-Verbraucher werden mit den entpackten TB-Tools verknüpft, als TBC ausgeführt und mit tbrt als EXE exportiert. Library-Quellen sind dabei nicht verfügbar. Erzeugung/Linken werden in einer Umgebung ohne erreichbaren C-/Rust-Compiler oder nativen Linker geprüft; Systemhilfen zur EXE-Finalisierung dürfen verfügbar bleiben. Fertige EXEs laufen anschließend ohne externe TBL/TBC oder TB-Installation.
+5. `cargo test --locked --workspace`, Clippy und Formatprüfung zentral auf dem Linux-arm64-Host; zielabhängige Rust-Testprogramme bei Bedarf cross-kompilieren und auf passenden Prüfsystemen ausführen. Native Tests aus 02/03/04 und automatisierbare Plattformtests aus 05 auf ihren tatsächlichen Zielen ausführen. Buildstatus und Ausführungsnachweise getrennt ausweisen; macOS-EXE-Finalisierung mit codesign erfolgt auf macOS. Den fixierten Fremdprogrammbestand ausdrücklich im erforderlichen Abnahmelauf bereitstellen. Compile-/VM-Messungen auf dokumentiertem Referenzrunner statt instabiler Debug-Zeitlimits in allen Jobs.
+6. Gitea-Release erst nach allen Pflichtjobs, zugeordneten echten Zielnachweisen und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. PR-Jobs ohne Veröffentlichungsrechte und ohne Release-Secrets; fremder PR-Code darf nicht mit solchen Rechten auf persönlichen Runnern laufen. Zugangswerte werden als Gitea-Secrets konfiguriert, nicht committed. Tests erzeugen keine öffentlichen Testreleases.
 7. README-/PLAN-/Releasehinweise nennen die tatsächlich gemessenen minimalen OS-/Systembibliotheksversionen. Developer-ID-/öffentliche Vertrauenssignatur ist kein Ersatz für lokale Ausführbarkeit; wenn entsprechende Identitäten nicht konfiguriert sind, deren Download-/Vertrauensgrenzen ehrlich dokumentieren. Mac-Artefakte müssen trotzdem lokal korrekt finalisiert und startbar sein.
 
 ## Risks / Trade-offs
 
-- Native Runner fehlen → explizite Bereitstellungsaufgabe und fehlender Zieljob verhindern Abschluss; Workflowdateien allein sind kein CI-Nachweis.
+- Cross-Toolchain/SDK fehlt oder ist inkompatibel → Buildbootstrap korrigieren und echte Vierzielpakete nachweisen. Fehlende Zielausführung auf Prüfsystemen sperrt weiterhin Abschluss/Release; erfolgreiche Cross-Builds allein reichen nicht.
 - Vorlagen passen nicht zum Tool → Manifest-/Prüfsummen-/Versionscheck und Export aus entpacktem Paket.
-- Plattformwerkzeuge variieren → Zieljob prüft tatsächliche 7z-/tar-/Rust-Build-/Signierwerkzeuge; keine stillen Ersatzformate.
+- Plattformwerkzeuge variieren → Buildhost prüft Archiv-/Cross-Werkzeuge, Prüfsysteme prüfen benötigte Signierwerkzeuge; keine stillen Ersatzformate.
 - Fehler beim Upload → vollständige Pflichtasset-Liste vor Freigabe prüfen; bestehende vollständige Releases nicht beschädigen.
 
 ## Migration Plan

openspec/changes/phase-6-06-gitea-actions-und-releases/proposal.md

@@ -5,10 +5,11 @@ Das Repository am bestehenden Gitea-Origin enthält noch keine CI-/Release-Workf
 ## What Changes
 
 - Gitea Actions am bestehenden Origin für Push-/PR-Prüfungen und taggebundene Releases einrichten.
-- Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 bauen; keine zusätzlichen Zielplattformen und kein Mirror.
+- Auf dem vorhandenen Linux-arm64-Gitea-Runner Terminalanwendungen für Windows amd64 (cargo-xwin), macOS arm64 und Linux amd64 (cargo-zigbuild) sowie Linux arm64 bauen; keine zusätzlichen Zielplattformen und kein Mirror.
 - Windows als `.7z`, macOS und beide Linux-Ziele als `.tar.gz` mit `tb`, `tbc` und der nativen `tbrt`-Vorlage samt Metadaten paketieren.
 - Entpackte Pakete einschließlich `tbc link`, nativer Exporte und separater BASIC-Verbraucher von `.tbl` prüfen, Prüfsummen und nachvollziehbare Buildmetadaten liefern.
-- Releases erst nach vollständigen erforderlichen Prüfungen veröffentlichen; fehlende Runner oder Assets dürfen keinen grünen vollständigen Release ergeben.
+- Echte Zielausführung aus 05 getrennt vom Cross-Bau einbinden, automatisiert oder als revisions-/paketprüfsummengebundenen Nachweis von separaten Prüfsystemen. Vier native Buildrunner werden nicht vorausgesetzt.
+- Releases erst nach vollständigen erforderlichen Prüfungen veröffentlichen; fehlende Zielnachweise oder Assets dürfen keinen grünen vollständigen Release ergeben.
 
 ## Capabilities
 

openspec/changes/phase-6-06-gitea-actions-und-releases/specs/gitea-distribution/spec.md

@@ -5,7 +5,7 @@ Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier fest
 ## ADDED Requirements
 
 ### Requirement: Vier verbindliche Buildziele
-Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision bauen und prüfen. Fehlende Runner, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Für normale Änderungen SHALL ein reproduzierbarer Build-/Teststatus vorliegen.
+Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision auf dem vorhandenen Linux-arm64-Runner bauen und paketieren. Cross-Kompilierung SHALL für fremde Ziele verwendet werden; vier native Buildrunner MUST NOT vorausgesetzt werden. Buildprüfungen und echte Zielausführung SHALL getrennt nachvollziehbar sein. Fehlende Build- oder Ausführungsnachweise, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Für normale Änderungen SHALL ein reproduzierbarer Build-/Teststatus vorliegen.
 
 #### Scenario: Ein Ziel fehlt
 - **WHEN** drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
@@ -19,14 +19,14 @@ Windows SHALL als `.7z` ausgeliefert werden; macOS und beide Linux-Architekturen
 - **THEN** starten IDE und Compiler als native Terminalanwendungen und ein Beispielprojekt kann mit den mitgelieferten Vorlagen exportiert und nativ verwendet werden
 
 ### Requirement: Tatsächliche Artefaktprüfung
-Die Actions SHALL die fertig gepackten und erneut entpackten Artefakte auf dem jeweiligen Ziel testen. Native Executables SHALL ohne TB-Installation und Quellen laufen, Library-Ausgaben SHALL mit separaten BASIC-Verbrauchern über `tbc link` ohne Library-Quellen funktionieren. Dieselbe TBL-Probe SHALL mit identischen Bytes auf allen vier Zielen verknüpft und ausgeführt werden. Library-Bau und Link-/EXE-Export SHALL mit den entpackten Tools ohne C-/Rust-Compiler oder nativen Linker beim Anwender geprüft werden; dokumentierte Systemhilfen zur EXE-Finalisierung dürfen vorhanden sein. Ein erfolgreiches Cargo-Kompilieren oder korrekt benannter Archivname MUST NOT diese Prüfung ersetzen.
+Der Actions-Releasepfad SHALL tatsächliche Prüfungen der fertig gepackten und erneut entpackten Artefakte auf dem jeweiligen Ziel verlangen. Diese SHALL als automatisierte Zielprüfungen oder dokumentierte manuelle Nachweise von separaten Prüfsystemen aus Change 05 eingebunden und vor Freigabe an die geprüfte Revision und exakte Paketprüfsumme gebunden werden. Fehlende oder nicht passende Nachweise MUST die Freigabe verhindern. Native Executables SHALL ohne TB-Installation und Quellen laufen, Library-Ausgaben SHALL mit separaten BASIC-Verbrauchern über `tbc link` ohne Library-Quellen funktionieren. Dieselbe TBL-Probe SHALL mit identischen Bytes auf allen vier Zielen verknüpft und ausgeführt werden. Library-Bau und Link-/EXE-Export SHALL mit den entpackten Tools ohne C-/Rust-Compiler oder nativen Linker beim Anwender geprüft werden; dokumentierte Systemhilfen zur EXE-Finalisierung dürfen vorhanden sein. Ein erfolgreiches Cargo-Kompilieren oder korrekt benannter Archivname MUST NOT diese Prüfung ersetzen.
 
 #### Scenario: Falsches Binary im richtigen Archiv
 - **WHEN** ein Windows-amd64-Archiv versehentlich ein Binary eines anderen Ziels enthält
 - **THEN** scheitert die Format-/Startprüfung vor der Veröffentlichung
 
 ### Requirement: Nachvollziehbare Veröffentlichung
-Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; PR-Prüfungen MUST keine Release-Secrets benötigen. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
+Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Buildhost, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; PR-Prüfungen MUST keine Release-Secrets benötigen. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
 
 #### Scenario: Paket beschädigt oder Upload unvollständig
 - **WHEN** ein Archiv nach dem Bau verändert wird oder ein Pflichtasset nicht hochgeladen werden kann

openspec/changes/phase-6-06-gitea-actions-und-releases/tasks.md

@@ -1,19 +1,19 @@
 ## 1. Gitea und Runner
 
-- [ ] 1.1 Verfügbare Gitea-1.25-kompatible Runner und Labels für Windows amd64, macOS arm64, Linux amd64/arm64 inventarisieren und fehlende Zielrunner anbinden; ein kleiner Gitea-Prüfjob muss tatsächliches OS/Architektur je Ziel nachweisen.
-- [ ] 1.2 Repositorylokale Build-/Testaufrufe und feste Toolchain-/Systemvoraussetzungen bereitstellen; jeder Aufruf muss lokal auf seinem Ziel mit --locked bauen und erforderliche Regressionen starten können.
+- [ ] 1.1 Vorhandenen Linux-arm64-Gitea-Runner und tatsächliches Label bestätigen; Cross-Buildumgebungen mit cargo-zigbuild, cargo-xwin und benötigten SDKs/Sysroots reproduzierbar festlegen. Ein Gitea-Prüfjob muss den Buildhost nachweisen; separate echte Prüfsysteme aus 05 zuordnen, ohne vier native Buildrunner vorauszusetzen.
+- [ ] 1.2 Repositorylokale Build-/Testaufrufe und feste Toolchain-/Systemvoraussetzungen bereitstellen; alle vier Ziele müssen auf Linux arm64 mit --locked baubar sein. Zentrale Workspace-Regressionen und getrennte Aufrufe für echte Zielprüfungen bereitstellen; fremde Executables nicht als nativ auf dem Buildhost getestet ausweisen.
 - [ ] 1.3 Push-/PR-Workflow unter .gitea/workflows anbinden; ein tatsächlicher Origin-Lauf muss vier Zielergebnisse und Fehlerstatus liefern, ohne Release-Secrets im PR-Pfad.
 
 ## 2. Artefakte und Pakete
 
 - [ ] 2.1 IDE, CLI und native `tbrt`-Exportvorlage je Ziel in Gitea Actions bauen; Format-/Architektur-/Versionsprüfungen müssen Windows amd64, macOS arm64 und beide Linux-Architekturen eindeutig bestätigen.
 - [ ] 2.2 Windows-Paket als .7z und macOS-/Linux-Pakete als .tar.gz erzeugen; Archivtests müssen Dateinamen, Paketinhalt, Executable-Rechte und notwendige Begleitdateien prüfen.
-- [ ] 2.3 Jedes fertige Paket neu entpacken und die enthaltenen Programme starten; `tbc link` und EXE-/TBL-Beispiele müssen mit separaten BASIC-Verbrauchern ohne Library-Quellen/Entwicklungscheckout sowie ohne erreichbaren C-/Rust-Compiler oder nativen Linker funktionieren.
+- [ ] 2.3 Jedes fertige Paket auf dem tatsächlichen Ziel neu entpacken und die enthaltenen Programme starten; automatisierte oder dokumentiert manuelle Nachweise aus separaten Prüfsystemen an Revision und Paketprüfsumme binden; `tbc link` und EXE-/TBL-Beispiele müssen mit separaten BASIC-Verbrauchern ohne Library-Quellen/Entwicklungscheckout sowie ohne erreichbaren C-/Rust-Compiler oder nativen Linker funktionieren.
 - [ ] 2.4 Einmal erzeugte TBL-Probe mit identischen Bytes an alle vier Zielprüfungen verteilen sowie Artefaktmanifest und Prüfsummen erzeugen; absichtlich beschädigte oder vertauschte Zielartefakte müssen die Prüfung scheitern lassen.
 
 ## 3. Releasepfad
 
-- [ ] 3.1 Taggebundenen Gitea-Releasepfad mit vollständiger Pflichtasset-Liste und getrennten Rechten einrichten; fehlgeschlagene/fehlende Zieljobs müssen die Freigabe verhindern.
+- [ ] 3.1 Taggebundenen Gitea-Releasepfad mit vollständiger Pflichtasset-Liste und getrennten Rechten einrichten; fehlgeschlagene/fehlende Zielbuilds oder zugeordnete echte Paket-/Zielprüfungen müssen die Freigabe verhindern.
 - [ ] 3.2 Upload zunächst als nicht freigegebenen Stand prüfen und erst vollständig freigeben; ein simulierter fehlender Upload darf keinen vollständigen bestehenden Release überschreiben.
 - [ ] 3.3 Fremdprogramm-, Inventar-, native und automatisierte Plattformnachweise sowie Referenzbenchmarks in den erforderlichen Abnahmelauf integrieren; ignorierte Pflichtfälle müssen als fehlend sichtbar bleiben.
-- [ ] 3.4 Einen tatsächlichen vollständigen Gitea-Lauf mit vier Paketartefakten nachweisen; Run-/Commit-/Targetdaten und entpackte Prüfergebnisse an 07 übergeben, bevor der Change als fertig gilt.
+- [ ] 3.4 Einen tatsächlichen vollständigen Gitea-Lauf mit vier Paketartefakten nachweisen; Run-/Commit-/Buildhost-/Targetdaten und paketprüfsummengebundene entpackte Prüfergebnisse an 07 übergeben, bevor der Change als fertig gilt.

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/tasks.md

@@ -14,5 +14,5 @@
 
 ## 3. Phasenabschluss
 
-- [ ] 3.1 Alle acht PLAN-Punkte einer bestandenen Evidenz zuordnen und erst dann abhaken; Bericht muss Gitea-Run-/Releasebezug, vier Targets und verbleibende Stufe-2-Abgrenzung zeigen.
+- [ ] 3.1 Alle acht PLAN-Punkte einer bestandenen Evidenz zuordnen und erst dann abhaken; Bericht muss Gitea-Run-/Releasebezug, zentralen Cross-Paketbau und davon getrennte echte Zielausführung, vier Targets und verbleibende Stufe-2-Abgrenzung zeigen.
 - [ ] 3.2 Abschließende Doku-/Help-/OpenSpec-Konsistenz prüfen; keine unaufgelösten Links, widersprüchlichen Exporthinweise oder offenen Phase-6-Befunde dürfen verbleiben.