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

PLAN.md

@@ -62,12 +62,12 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
     (Details in docs/tbvm-design.md, Abschnitt „Performance"); Messlatte via
     Benchmarks ab Phase 2.
   - `tbc build --exe` erzeugt Executables **ohne** Compiler-/Linker-
-    Toolchain beim Anwender (vorkompilierter Runner + angehängtes `.tbc`) —
+    Toolchain beim Anwender (vorkompiliertes `tbrt` mit eingebettetem `.tbc`) —
     damit bleibt auch der Weg zum verteilbaren Binary im Sekundenbereich.
 - **Jede Phase endet mit lauffähigen Tests** gegen eine wachsende
   Kompatibilitäts-Testsuite (Verzeichnis `tests/compat`).
 - **Erster Kompatibilitätstest — externes Programmkorpus** (2026-09-02):
-  Die Programme aus https://github.com/cout/vbdos (insb. der Ordner
+  Die Programme des dokumentierten Referenzbestands `cout/vbdos` (insb. der Ordner
   `microsoft/`) müssen — soweit sie keine deklarierten Non-Features
   (PEEK/POKE/CALL INTERRUPT …) nutzen — **erfolgreich kompilieren und
   nutzbar sein**. Das Repo wird nicht einvendort (Lizenzlage), sondern vom
@@ -418,8 +418,8 @@ Maßgeblich ist seit 2026-09-03 das Inventar, nicht diese Liste.
       (Gegenstück zu FT.EXE des Vorbilds; Magic `FC 08 01 00`): als
       `tbc convert-frm`. Format per Reverse Engineering aus den
       Beispieldateien des Originalpakets und des cout/vbdos-Repos
-- [x] Meilenstein (erster Kompatibilitätstest): die Programme aus
+- [x] Meilenstein (erster Kompatibilitätstest): die Programme des
-      https://github.com/cout/vbdos ohne Non-Features kompilieren und
+      dokumentierten Referenzbestands `cout/vbdos` ohne Non-Features kompilieren und
       sind nutzbar (Konsolenprogramme bereits ab Phase 3)
       Befund: Alle sieben Programme wurden gegen Commit `1cdd2b3` als
       `.MAK` bzw. `.FRM` ohne Diagnosen geprüft und im PipeHost gestartet.
@@ -461,7 +461,9 @@ Maßgeblich ist seit 2026-09-03 das Inventar, nicht diese Liste.
       Exportpfad aus Phase 6 fehlt, bleiben die Dialoge bedienbar und erklären
       die fehlende Erzeugungsfunktion; es wird kein erfolgreicher Export
       vorgetäuscht. Make EXE zielt auf ein eigenständiges natives Executable,
-      Make Library auf eine native Bibliothek im Format des Zielsystems.
+      Make Library auf eine portable P-Code-Bibliothek (`.tbl`). Die native
+      Runtime ist Bestandteil von `tbrt`; die Phase-6-Anbindung passt die
+      vorbereitete Zielauswahl für den plattformunabhängigen Library-Export an.
 - [x] **`$INCLUDE`** im Compile-Treiber auflösen — der Lexer liefert den
       Metabefehl bereits als Token. Datei einlesen, Pfade relativ zur
       einschließenden Datei, Zyklen erkennen und namentlich abweisen.
@@ -487,6 +489,28 @@ headless IDE/CLI/TBC-Parität, lokaler Unix-PTY-Test und Release-Compile-Budget
 sind bestanden. Die vollständige Terminal-/OS-Matrix bleibt Phase 6.
 
 ## Phase 6 — Kompatibilität, Politur, Distribution
+
+Verbindliche Build- und Release-Ziele (Terminalanwendungen): Windows amd64,
+macOS arm64 sowie Linux amd64 und arm64. Gitea Actions am bestehenden
+Origin erstellt und prüft die Artefakte für alle vier Ziele. Die
+Plattformtests umfassen unter Linux weiterhin mindestens zwei Emulatoren.
+Release-Pakete: Windows als `.7z`, macOS und beide Linux-Architekturen
+als `.tar.gz`, jeweils mit `tb`, `tbc` und der passenden `tbrt`-Vorlage
+(Windows jeweils `.exe`) samt benötigten Metadaten.
+
+Architektur: `tbrt` enthält die nativ kompilierte VM, Runtime und
+Terminal-/Forms-Unterstützung. BASIC-Programme und `.tbl`-Bibliotheken
+bestehen aus P-Code. „Native Systembibliothek“ bezeichnet die eigentliche
+Runtime, die in `tbrt` eingebaut wird, keinen separaten Library-Export von
+BASIC nach `.lib`/`.a`. `tbc link` und die IDE nutzen denselben P-Code-Linker;
+das vollständige Kompilat wird für Make EXE in die Zielvorlage eingebettet.
+Library-Erzeugung und Linken benötigen beim Anwender keinen C-/Rust-Compiler
+und keinen nativen Linker. Systemvoraussetzungen zur EXE-Finalisierung
+(insbesondere Signierung auf macOS) werden separat geprüft und dokumentiert.
+
+Gesamtproposal und Abhängigkeiten:
+`openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/phase-6-uebersicht.md`.
+
 - [ ] Kompatibilitäts-Testsuite ausbauen (Snapshot-Tests der Bildschirmausgabe)
 - [ ] Plattformtests: Windows Terminal, Linux (mind. 2 Emulatoren), macOS —
       inkl. systematischem Maus-/Sondertasten-Test (F1–F12, Alt-Kombis;
@@ -496,21 +520,24 @@ sind bestanden. Die vollständige Terminal-/OS-Matrix bleibt Phase 6.
 - [ ] **Native Standalone-Executables:** `tbc build --exe` und IDE →
       Make EXE File erzeugen ein direkt vom Zielsystem ausführbares,
       eigenständiges Programm in dessen nativem Executable-Format.
-      Der geplante vorkompilierte Runner mit eingebettetem Bytecode erfüllt
+      Das geplante vorkompilierte `tbrt` mit eingebettetem P-Code erfüllt
       dies ohne Compiler-/Linker-Toolchain beim Anwender und ohne separat
       installiertes `tb`/`tbc`. Ein bloßes `.tbc`-Kompilat erfüllt diesen
       Punkt nicht. Die Erzeugung und Anbindung an die in Phase 5 vorbereitete
       IDE-UI erfolgen in Phase 6.
-- [ ] **Native Systembibliotheken:** IDE → Make Library und der gemeinsame
+- [ ] **P-Code-Bibliotheken und Linker:** IDE → Make Library und
-      Buildpfad erzeugen eine tatsächlich nutzbare Bibliothek im nativen
+      `tbc build --library` erzeugen portable `.tbl`-Bibliotheken mit
-      Bibliotheksformat des jeweiligen Zielsystems. Exportierte Symbole,
+      übersetzten Modulen, Symbolen, Signaturen und benötigten Daten.
-      Aufruf-/Linkvertrag und erforderliche Runtime-Einbettung werden in
+      `tbc link` verbindet Hauptprojekt und Libraries zu einem vollständigen
-      Phase 6 festgelegt und mit einem nativen Verbraucher geprüft; eine
+      `.tbc` oder mit `--exe` und der passenden `tbrt`-Vorlage zu einem
-      umbenannte `.tbc`-Datei ist keine Systembibliothek. Dialoge und
+      eigenständigen Executable. Die IDE nutzt denselben Linkdienst für
-      Bedienung entstehen bereits in Phase 5, Erzeugung und Backend-Anbindung
+      Projekte mit `.tbl`-Verweisen und die Make-Aktionen. Wiederverwendung
-      in Phase 6.
+      ohne Library-Quellen und identische TBL-Dateien auf allen vier Zielen
+      werden geprüft. Die Runtime ist nativer Code in `tbrt` und wird nicht
+      in jede TBL kopiert. Erzeugung und Backend-Anbindung erfolgen in Phase 6.
 - [ ] Dokumentation: Sprachreferenz, Migrationshinweise, Beispielprogramme
-- [ ] CI (GitHub Actions: Build + Tests auf allen drei Plattformen), Releases
+- [ ] CI (Gitea Actions am bestehenden Origin: Build + Tests auf allen vier
+      System-/Architektur-Zielen), Releases über Gitea
 - [ ] **Abnahme der Leitplanke „Vollständigkeit ist das Soll"**:
       docs/inventar.md steht auf **0 offen** — jeder der 285 Einträge ist
       entweder implementiert oder als Non-Feature in der Sprachreferenz

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/.openspec.yaml

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

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/design.md

@@ -0,0 +1,26 @@
+## Context
+
+`compat.rs` besitzt bereits Größen-/Uhr-/Ereignisdirektiven, Text-/Attributvergleiche und temporäre Dateiverzeichnisse. `foreign.rs` prüft sieben Einstiege aus cout/vbdos bei Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`, ist im normalen Lauf aber absichtlich ignoriert. `inventar.rs` und VM-`events.rs` prüfen mehr als Namenslisten. Phase 5 meldete 605 erfolgreiche Tests plus Offline-Kindprozess; dies ist Referenzhistorie, kein Phase-6-Messwert.
+
+## Goals / Non-Goals
+
+**Goals:** Bestehende Nachweise zu einem reproduzierbaren Release-Abnahmesatz verbinden, belegte Deckungslücken schließen und Optimierungsbedarf messen.
+
+**Non-Goals:** Zweiter Interpreter/Harness, Emulatorbetrieb, automatisch neu geschriebene Golden Files, spekulative Optimierung, bereits als bestanden ausgegebene Plattformmatrix.
+
+## Decisions
+
+1. Den existierenden Harness und seine Deklarationen erweitern, keine neue Fixture-Sprache einführen. Abdeckung explizit gegen Konsole, Unicode/Attribute/Resize, Forms/Menüs/Fokus, Projekte/Includes, Dateien/ISAM und Fehlerbehandlung zuordnen. Für neue Fälle zunächst Soll aus Spec oder dokumentierter Referenz herleiten; vorhandene Proben wiederverwenden, wo sie das Verhalten bereits beweisen.
+2. Fremdprogramme aus dem festgelegten Checkout in temporäre Verzeichnisse exportieren. Den optionalen Entwicklertest beibehalten, aber im Release-Aufruf ausdrücklich aktivieren und seine Bereitstellung zwingend prüfen. Keine Originalbinärdateien oder ganzen Fremdkorpora ungeprüft vendorn. Ein fehlender Netz-/Checkoutzugang wird als externe Voraussetzung benannt.
+3. `cargo bench -p tb-vm --bench compile` und `--bench vm` als Messverfahren erhalten. Compile-Harness enthält harte bestehende Grenzen. VM-Vergleich verwendet denselben Rechner und reproduzierbare Revisionen; mehrere Läufe nur zur Klärung auffälliger Streuung. Kein willkürliches neues absolutes VM-Zeitlimit, kein Vergleich verschiedener Hardware als Regression. Bei unauffälligem Befund genügt ein dokumentiertes „keine Optimierung erforderlich“.
+4. CLI-, TBC- und IDE-Parität aus Phase 5 als Ausgangspunkt aufnehmen; 02/03/04 ergänzen später native Executables und quellfreie TBL-Verbraucher. Daten/Fehler/Dateien zählen ebenso wie Endbildschirme. Der finale Stand nach diesen Änderungen wird in 07 erneut qualifiziert.
+
+## Risks / Trade-offs
+
+- Historische Sollwerte ungeprüft übernehmen → Herkunft je neuem Fall, negative Gegenproben und vorhandene unabhängige Inventarziele erhalten.
+- Externer Korpus oder Referenzhardware fehlt → fehlenden Nachweis offen führen; nicht durch Ignore als erledigt werten.
+- Messrauschen → Last, Toolchain und Vergleichsrevision dokumentieren; erst reproduzierbare Verschlechterung optimieren.
+
+## Migration Plan
+
+Nur additive Korpus-/Abnahmeergänzungen; Fachkorrekturen mit gezieltem Regressionstest. Rücknahme einzelner Ergänzungen über Git möglich. Bestehende Dateien, Sprachsemantik und CLI-Aufrufe behalten ihren Vertrag. Ergebnisse an 02–07 übergeben.

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/phase-6-uebersicht.md

@@ -0,0 +1,154 @@
+# Phase 6: Gesamtproposal und Exploration
+
+Stand: 2026-09-07. Erkundungsbasis: Commit `86c3ebeb6d623e2f3e33f957ceb24b19cf6d1940`,
+abgeschlossene Phase 5 und zunächst keine aktiven Changes. Dieses Dokument
+plant die gesamte Phase 6; es behauptet keine neue Implementation oder Abnahme.
+
+## Verbindliche Vorgaben
+
+- Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64.
+- Ausschließlich Gitea Actions am bestehenden Origin `git.rfc1437.de/hugo/TerminalBasic`.
+- Die Actions bauen die tatsächlichen Zielprogramme; reine Platzhalter-/Cross-Buildmeldungen genügen nicht.
+- Windows-Paket als `.7z`, macOS und beide Linux-Pakete als `.tar.gz`.
+- Make EXE erzeugt ein eigenständiges natives Executable mit eingebetteter TB-Runtime, ohne Compiler-/Linker-Toolchain beim Anwender.
+- Make Library liefert portable `.tbl`-P-Code-Bibliotheken. `tbc link` und IDE verwenden denselben Linkdienst; die nativ kompilierte Runtime ist Bestandteil von `tbrt`.
+- Die in Phase 5 fertiggestellten Dialoge werden jetzt an reale Erzeugung angebunden.
+- Stufe-2-Spracherweiterungen bleiben außerhalb dieser Phase.
+
+## Feststellungen am bestehenden Code
+
+| Bereich | Vorgefundener Stand | Konsequenz für Phase 6 |
+| --- | --- | --- |
+| CLI | `tb-cli/src/main.rs::cmd_build` schreibt ausschließlich `.tbc`; Native-Flags und Vorlagen fehlen | 02 ergänzt native Verpackung, bestehender TBC-Aufruf bleibt |
+| Gemeinsame Ausführung | `project_io::new_execution`, CLI `run_chain`, IDE-Sitzung nutzen dieselbe TBVM; CLI enthält auch Druck-/Exit-/Hostlogik | Runnerpfad wiederverwenden, keine zweite Runtime |
+| Kompilat | `TBC_VERSION = 4`; Projekt-, Forms-, DATA-, Signatur- und Quellortinformationen bereits vorhanden | Vorlagenversion prüfen, vollständiges TBC als eingebettete Nutzlast verwenden |
+| Library | Projektlinker vorhanden, aber noch AST-abhängig; kein TBL-Container oder tbc-link-Befehl | 03 ergänzt serialisierbare Modul-/Symbolmetadaten und quellfreie Verknüpfung |
+| IDE-Export | ExportRequest/ProjectStamp/ExportStatus vorhanden; gültiger Dialogauftrag endet in UNAVAILABLE | 04 bindet Erzeugung an; Staging erst nach gültiger Auftragsprüfung veröffentlichen |
+| Zielauswahl | UI akzeptiert bisher unabhängig drei Systeme und zwei Architekturen | Vierziel-Matrix für EXE zentralisieren; Make Library erzeugt TBL ohne native Zielwahl |
+| Korpus | `compat.rs`: Größen-/Zeit-/Ereignisdirektiven, Text-/Attributsnapshot, temporäre Dateien; weitere Projekt-/Forms-/Fehlerproben | Bestehende Pfade ergänzen und als Release-Abnahmesatz verbinden |
+| Fremdprogramme | Sieben Programme aus cout/vbdos, fixierte Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`; explizit optionaler Test | Releaseprüfung ruft ihn zwingend mit bereitgestelltem Bestand auf; fehlender Bestand bleibt fehlender Nachweis |
+| Inventar | Sprach- und vollständige Forms-Einträge; feste Sollziele, Absenkungs- und Ereignistests vorhanden | Nicht auf historische 285 Spracheinträge verkürzen; finale vollständige Null-offen-Abnahme |
+| Leistung | Vorhandene Compile- und VM-Benchmarks; Phase-5-Compile 0,74/98 ms auf M5 Max | Aktuelle Referenzmessung statt vorsorglicher Optimierung; historische Werte nicht als Phase-6-Ergebnis ausgeben |
+| Terminal | TestBackend und lokaler Unix-PTY-Test vorhanden | Tatsächliche Emulator-/Systemmatrix einschließlich Windows und Linux arm64 ergänzen |
+| CI | Keine Workflowdateien; Origin meldet Gitea 1.25.4 | Vier passende Runner und tatsächliche Actions-Läufe nachweisen; Verfügbarkeit bisher nicht bestätigt |
+| Doku | README „Projektrahmen“, alte Korpus-Phasenhinweise, Exportbackend noch als geplant beschrieben | 07 gleicht Installation, Hilfe, Migration, Beispiele und Plan an ausgelieferte Programme an |
+
+## Change-Aufteilung und Abhängigkeiten
+
+| Nr. | Change | Voraussetzungen | Eigenständige Leistung |
+| --- | --- | --- | --- |
+| 01 | [Kompatibilität und Leistungsabnahme](proposal.md) | Phase 5 | Reproduzierbarer Abnahmesatz, Fremdkorpus, Inventarbasis und begründeter Performance-Pass |
+| 02 | [Native Executables](../phase-6-02-native-executables/proposal.md) | 01 | Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung |
+| 03 | [P-Code-Bibliotheken und Linker](../phase-6-03-pcode-bibliotheken-und-linker/proposal.md) | 02 | TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher |
+| 04 | [IDE-Exportanbindung](../phase-6-04-ide-exportanbindung/proposal.md) | 02, 03 | Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse |
+| 05 | [Plattformmatrix](../phase-6-05-plattformmatrix/proposal.md) | 01–04 | Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen |
+| 06 | [Gitea Actions und Releases](../phase-6-06-gitea-actions-und-releases/proposal.md) | 01–05 | Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad |
+| 07 | [Dokumentation und Phasenabnahme](../phase-6-07-dokumentation-und-phasenabnahme/proposal.md) | 01–06 | Aktuelle Anleitungen/Hilfe, ausgelieferter Gesamtweg und belegter Phase-6-Abschluss |
+
+Die Reihenfolge 01 bis 07 ist gültig. Native Zielprüfungen in 02/03/05 sind
+vor 06 zunächst lokal auf passenden Prüfrechnern ausführbar; 06 automatisiert
+diese Aufrufe in Actions und liefert die endgültigen Pakete. Dadurch entsteht
+kein Kreis „Export benötigt Release, Release benötigt Export“. Endgültige
+Evidenz mit Releasepaketen liegt in 07. Das Scaffolding von Changes und die
+OpenSpec-Artefaktstatus erzwingen diese fachlichen Abhängigkeiten nicht.
+Beim Anwenden sind umgesetzte/synchronisierte Vorgänger und ihre Ergebnisse
+zu prüfen; nach Archivierung liegen sie unter `openspec/changes/archive/`.
+
+## Zuordnung der acht PLAN-Punkte
+
+| Phase-6-Planpunkt | Umsetzung | Endgültiger Nachweis |
+| --- | --- | --- |
+| Kompatibilitäts-Testsuite | 01, native Erweiterungen 02–04 | Korpus-/Native-Parität, 06/07 |
+| Plattformtests | 05 | Windows Terminal, Terminal.app, je zwei Linux-Emulatoren auf amd64 und arm64; 07 |
+| Performance-Pass nur falls nötig | 01 | Vergleichbare VM-Messung plus bestehende Compile-Budgets; finale Revision 07 |
+| Native Standalone-Executables | 02, IDE 04 | Start ohne Quellen/TBC/tb/tbc; entpackte Actions-Pakete 06/07 |
+| P-Code-Bibliotheken und Linker | 03, IDE 04 | Identische TBL mit separaten BASIC-Verbrauchern auf allen vier Zielen; Paketprüfung 06/07 |
+| Dokumentation und Beispiele | Fachbegleitend 02–06, Abschluss 07 | Ausgeführte Anleitungen, Help-/Link-/Offlineprüfung |
+| CI und Releases | 06 | Vier tatsächlich erfolgreiche Gitea-Zieljobs und geprüfte Archive |
+| Vollständigkeit des Inventars | Grundlage 01, endgültig 07 | Vollständiges aktuelles Sprach-/Forms-Inventar, null offen, korrekte Non-Feature-Fundstellen |
+
+## Verbindliche Release-Matrix
+
+| System | Architektur | Rust-Target | Archiv |
+| --- | --- | --- | --- |
+| Windows | amd64 | `x86_64-pc-windows-msvc` | `terminalbasic-<version>-windows-amd64.7z` |
+| macOS | arm64 | `aarch64-apple-darwin` | `terminalbasic-<version>-macos-arm64.tar.gz` |
+| Linux | amd64 | `x86_64-unknown-linux-gnu` | `terminalbasic-<version>-linux-amd64.tar.gz` |
+| Linux | arm64 | `aarch64-unknown-linux-gnu` | `terminalbasic-<version>-linux-arm64.tar.gz` |
+
+Die Archive enthalten `tb`/`tbc` und die native Runtime-/Exportvorlage `tbrt`
+(Windows mit `.exe`) sowie Metadaten, Lizenz und Benutzungshinweise. Jedes fertige Archiv wird
+entpackt und auf seinem Ziel geprüft. Mindest-OS-/Systembibliotheksstände
+werden aus dem festgelegten tatsächlichen Builder und Zieltest dokumentiert.
+Standalone bedeutet keine separat installierte TB-Runtime; gewöhnliche
+Betriebssystembibliotheken und explizite OPEN-/RUN-Ressourcen bleiben benannt.
+
+## Architekturentscheidungen und Abnahmegrenzen
+
+- Vorhandene Sprache und TBVM bleiben erhalten. Die Native-Erzeugung verpackt
+  Kompilat und Runtime, sie übersetzt BASIC nicht neu über LLVM/JIT.
+- Vorlagenbau findet in den passenden Actions statt; `make exe` beim Anwender
+  benötigt keine C-/Rust-Compiler oder nativen Linker. Auch der TBL-Bau und P-Code-Linkpfad laufen allein mit TB-Tools. Verfügbarkeit eines Cross-Exports
+  hängt von Vorlage und korrekter Finalisierung ab, nicht nur von einem Dropdown.
+- Mac-Nutzlasteinbau und Signierung werden vor Dateiveröffentlichung geprüft.
+  Die bisherige pauschale Aussage über portables Anhängen allein ist kein
+  Mach-O-Nachweis. [Apple Code Signing](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)
+- Gitea-Runner werden über eindeutige Ziel-Labels gebunden. Vier Workflowzeilen
+  beweisen keine vier vorhandenen Maschinen. [Gitea Runner](https://docs.gitea.com/1.25/usage/actions/act-runner/)
+- Der Phase-5-Exportvertrag wird in 04 bedingt fortgeführt: Ohne Backend bleibt
+  die verständliche Sperre geprüft, mit Backend muss wirkliche Dateierzeugung
+  nachgewiesen werden. Beide MODIFIED-Blöcke erhalten alle bisherigen Szenarien.
+- Golden-Ausgaben, Inventareinträge und Non-Features dürfen nicht zur
+  Ergebnisbeschönigung verändert werden. Fachfehler gehören in ihren
+  bestehenden Implementierungspfad und erhalten eine Regression.
+- Fehlende externe Rechner, Emulatoren, Releasezugänge oder Fremdkorpora bleiben
+  sichtbare Voraussetzungen. Nur lokale Headless-Prüfungen schließen Phase 6 nicht.
+
+## Abnahmestrategie
+
+Jeder Change liefert einen eigenen verification.md mit Spec-/Taskzuordnung,
+konkreten Befehlen, Revision, Resultaten und Grenzen. Für 02–06 werden außerdem
+native Ziel- beziehungsweise Actions-Nachweise benötigt. 07 prüft die gesamte
+Kette mit den finalen Paketen. PLAN-Checkboxen bleiben während des Proposals offen.
+Die jetzige Planung verändert keine Produktdateien, installiert keine Runner
+und veröffentlicht keine Artefakte.
+
+## Bestätigter Library- und Linkvertrag
+
+`.tbl` ist die festgelegte Extension für portable P-Code-Bibliotheken.
+Die Bezeichnung native Systembibliothek betrifft die eigentliche Runtime:
+Sie wird nativ kompiliert und ist Bestandteil von `tbrt`. Ein eigener
+C-ABI-/`.lib`-/`.a`-Export von BASIC ist nicht vorgesehen.
+
+```text
+BASIC-Quellen ── tbc build --library ──► Bibliothek.tbl
+Hauptprojekt + Bibliothek.tbl ── tbc link ──► vollständiges Programm.tbc
+Programm.tbc + tbrt des Zielsystems ── Verpackung ──► natives Executable
+```
+
+`tbc link --exe` verbindet beide letzten Schritte; `tbc build --exe` und
+Make EXE verwenden dieselben Dienste. `.MAK` hält die TBL-Verweise, damit
+auch IDE-Start/Check/Debugger dieselben Bibliotheken verwenden. Make Library
+bietet `.tbl` ohne native Zielwahl an. Library-Bau und Linken benötigen beim
+Anwender keinen C-/Rust-Compiler oder nativen Linker. Die EXE-Finalisierung
+prüft ihre dokumentierten Systemvoraussetzungen separat.
+
+Der vorhandene Modul-Linkpfad wird erweitert; ein TBL enthält die dafür
+nötigen Deklarationen und unverknüpften Produkte. Native Runtime, P-Code und
+Formatversionen werden eindeutig getrennt. Initialisierung, COMMON, Forms,
+DATA und Fehlerorte werden mit entsprechenden Quellprojekten verglichen.
+
+Alle sieben Changes enthalten Proposal, Design, Delta-Specs und prüfbare,
+noch offene Implementierungsaufgaben. Es besteht keine offene Formatentscheidung.
+Vollständige Planung bedeutet weiterhin keine umgesetzte Phase 6.
+
+## Prüfung der Planung
+
+Alle sieben Changes sind im OpenSpec-Planungsstatus vollständig und für
+die Umsetzung bereit: 75 offene Aufgaben, 33 Delta-Anforderungen.
+`openspec validate --all --strict --no-interactive` besteht mit 30 geprüften
+Specs/Changes. Relative Dokumentverweise und der Erhalt bestehender
+Szenarien in den MODIFIED-Blöcken wurden geprüft. Der Help-Katalogtest
+`catalog_links_and_missing_targets_are_checked` besteht mit dem geänderten
+PLAN. Phase 6 bleibt bei 0/8 abgeschlossenen Planpunkten; diese Prüfungen
+sind Planungs-/Dokumentationsnachweise, keine Implementierungsabnahme.

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/proposal.md

@@ -0,0 +1,26 @@
+## Why
+
+Phase 5 ist abgenommen, aber die Distribution benötigt einen reproduzierbaren Kompatibilitäts- und Leistungsnachweis. Bestehende Snapshot-, Fremdprogramm-, Inventar- und Benchmarkpfade liefern die Grundlage; ihre Zusammenführung und gezielte Ergänzung fehlen.
+
+## What Changes
+
+- Einen dokumentierten Abnahmesatz aus vorhandenen Konsolen-, Forms-, Include-/Projekt- und Fehlerfällen mit deterministischen Eingaben, Zeiten, Größen und Dateieffekten festlegen und um belegte Lücken erweitern.
+- Den öffentlichen Fremdprogrammbestand mit festgelegter Revision ausdrücklich ausführen; fehlende Bereitstellung als fehlenden Nachweis behandeln.
+- Bestehende Compile- und VM-Benchmarks reproduzierbar messen; ausschließlich bei nachgewiesener Regression oder konkretem Engpass optimieren.
+- Inventarstand einschließlich Forms, Frontend-Absenkung und Ereignisauslöser als Ausgangsbasis dokumentieren. Finale Inventar-/Release-Abnahme liegt in 07.
+
+## Capabilities
+
+### New Capabilities
+
+- `release-kompatibilitaet`: Reproduzierbarer Abnahmesatz und messbare Leistungsentscheidung für Phase 6.
+
+### Modified Capabilities
+
+Keine. Die bestehenden Verträge aus `kompat-testkorpus`, `sprachinventar` und `bytecode-kompilat` bleiben erhalten.
+
+## Impact
+
+Betroffen sind `tests/compat/`, die vorhandenen CLI-Tests `compat.rs`, `foreign.rs`, `inventar.rs`, VM-Ereignistests und `crates/tb-vm/benches/{compile,vm}.rs`. Fachbefunde werden in ihrem bestehenden Implementierungspfad korrigiert; kein zweiter Korpus-Harness und keine pauschale VM-Neuschreibung.
+
+Abhängigkeit: abgeschlossene Phase 5. Übergabe: benannte Fälle und Referenzresultate für 02–07. Die vollständige Planung steht in [Phase-6-Übersicht](phase-6-uebersicht.md).

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/specs/release-kompatibilitaet/spec.md

@@ -0,0 +1,33 @@
+## Purpose
+
+Sichert die nachvollziehbare Kompatibilitäts- und Leistungsgrundlage für auslieferbare Terminal-Basic-Artefakte auf dem bestehenden Sprachstandard.
+
+## ADDED Requirements
+
+### Requirement: Deterministischer Abnahmesatz
+Die Release-Abnahme SHALL Konsolen-, Forms-, Mehrmodul-/Include-, Fehler- und Dateifälle mit ausdrücklich festgelegten Eingaben, Zeitverläufen, Bildschirmgrößen und Anfangsdateien prüfen. Sichtbare Zeichen, Attribute, Laufzeitresultat und relevante Dateieffekte SHALL mit unabhängig begründeten Sollwerten verglichen werden. Ein fehlender Sollwert MUST als fehlender Nachweis gelten und MUST NOT automatisch aus dem aktuellen Istwert entstehen.
+
+#### Scenario: Wiederholter Formularlauf
+- **WHEN** ein Formularfall mit Fokuswechsel, Maus, Menü und Größenänderung zweimal ausgeführt wird
+- **THEN** stimmen beide Läufe mit denselben Sollzuständen überein und eine Änderung nur am Farbattribut lässt die Prüfung fehlschlagen
+
+### Requirement: Expliziter Fremdprogrammnachweis
+Die Release-Abnahme SHALL den verwendeten öffentlichen Fremdprogrammbestand mit unveränderlicher Revision, Einstieg, Eingabefolge und sichtbarem Resultat benennen und prüfen. Ein fehlender oder falscher Bestand MUST den erforderlichen Nachweis als fehlend melden; ein ignorierter optionaler Entwicklertest SHALL keinen erfolgreichen Release-Nachweis ersetzen.
+
+#### Scenario: Referenzbestand fehlt
+- **WHEN** die Release-Abnahme ohne den vereinbarten Fremdprogrammbestand gestartet wird
+- **THEN** scheitert der erforderliche Fremdprogrammnachweis mit Benennung der fehlenden Voraussetzung
+
+### Requirement: Begründete Leistungsentscheidung
+Die bestehenden Compile-Budgets von unter 50 ms für das Referenzmodul und unter 1 s für das Referenzprojekt SHALL im Release-Profil eingehalten werden. Der VM-Durchsatz SHALL für die vorhandenen Schleifen-, Aufruf- und Stringlasten mit Hardware, Revision, Profil und Verfahren gemessen werden. Optimierung SHALL einen gemessenen Engpass oder eine reproduzierbare Regression voraussetzen und danach dieselben Semantikprüfungen bestehen.
+
+#### Scenario: Kein Optimierungsbedarf
+- **WHEN** Compile-Budgets bestehen und auf demselben Rechner kein reproduzierbarer VM-Rückschritt gegenüber dem dokumentierten Vergleichsstand vorliegt
+- **THEN** wird der Performance-Pass mit Messwerten und der begründeten Entscheidung abgeschlossen, den VM-Code unverändert zu lassen
+
+### Requirement: Nachvollziehbare Befundbehandlung
+Abweichungen SHALL mit Sollquelle, Istverhalten und zuständigem Fachbereich dokumentiert und dort behoben werden. Geänderte Erwartungen SHALL durch den geltenden Vertrag begründet sein. Die Abnahme MUST NOT Anforderungen, Fälle oder Inventareinträge entfernen, um ein grünes Ergebnis zu erzielen.
+
+#### Scenario: Snapshot weicht ab
+- **WHEN** ein bestehender Fall nach einer Fachänderung eine andere Ausgabe erzeugt
+- **THEN** nennt der Bericht die erste Abweichung und begründet Korrektur beziehungsweise zulässige Solländerung vor erneutem Prüfen

openspec/changes/phase-6-01-kompatibilitaet-und-leistungsabnahme/tasks.md

@@ -0,0 +1,17 @@
+## 1. Kompatibilitätsnachweise
+
+- [ ] 1.1 Bestehende Fälle aus compat.rs, foreign.rs, inventar.rs, events.rs und IDE-Abnahme einer dokumentierten Release-Matrix zuordnen; jede vereinbarte Verhaltensgruppe muss konkrete Fallnamen und einen ausführbaren Aufruf besitzen.
+- [ ] 1.2 Fehlende kombinierte Zeichen-/Attribut-/Resize- und Formularübergänge im vorhandenen Korpus ergänzen; wiederholte Läufe sowie absichtlich falsche Zeichen-/Attributerwartungen müssen die Vergleichsqualität belegen.
+- [ ] 1.3 Projekt-/Include-, Fehler- und Dateifälle mit festgelegtem Anfangszustand und Dateieffekten vervollständigen; gezielte Tests müssen Diagnosen und saubere temporäre Verzeichnisse prüfen.
+- [ ] 1.4 Öffentlichen Bestand in festgelegter Revision bereitstellen und den vorhandenen foreign-Test ausdrücklich ausführen; falsche/fehlende Revision muss den erforderlichen Abnahmepfad scheitern lassen.
+
+## 2. Inventar und Leistung
+
+- [ ] 2.1 Aktuelle Sprach- und Forms-Inventarsummen mit Quelllisten, Absenkungsproben und Ereignistests prüfen; Bericht muss alle Statusgruppen getrennt und offene Einträge namentlich ausweisen.
+- [ ] 2.2 Vorhandene Compile-/VM-Benchmarks im Release-Profil messen und mit reproduzierbarem Vergleichsstand einordnen; Hardware, Revision, Verfahren und beide Compile-Budgets im Bericht festhalten.
+- [ ] 2.3 Nur bei nachgewiesenem Engpass eine gezielte Fachkorrektur umsetzen und denselben Semantik-/Leistungsnachweis wiederholen; andernfalls „kein Optimierungsbedarf“ mit Messbegründung dokumentieren.
+
+## 3. Übergabe
+
+- [ ] 3.1 Gefundene Fachabweichungen vollständig beheben; betroffene Korpus-, Inventar- und Ereignistests müssen unveränderte Verträge bestätigen, ohne Golden-Dateien pauschal neu zu generieren.
+- [ ] 3.2 Abnahmesatz und Ergebnisse für native Artefakte und CI dokumentieren; Workspace-Tests, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, externe Voraussetzungen bleiben ausdrücklich sichtbar.

openspec/changes/phase-6-02-native-executables/.openspec.yaml

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

openspec/changes/phase-6-02-native-executables/design.md

@@ -0,0 +1,29 @@
+## Context
+
+`cmd_build` schreibt momentan nur `.tbc`; `cmd_run`/`run_chain` besitzen CLI-Exitcodes, Terminal-/PipeHost, Forms-Fortsetzung und RUN-Auflösung. `project_io::new_execution` ist bereits gemeinsam. TBC steht aktuell auf Version 4 und trägt die benötigten Projekt-/Forms-/Quellortdaten. Der Plan fordert ausdrücklich einen vorkompilierten Runner statt Cargo beim Anwender.
+
+## Goals / Non-Goals
+
+**Goals:** Wiederverwendbarer nativer Export ohne Compilerinstallation beim Anwender, einheitliche Ausführung und prüfbare Zielartefakte.
+
+**Non-Goals:** JIT/LLVM, Maschinenübersetzung jeder BASIC-Anweisung, Quellcompiler-Neuschreibung, vollständige Cross-Toolchain beim Anwender, Einbettung beliebiger zur Laufzeit per RUN/OPEN/SHELL referenzierter externer Ressourcen.
+
+## Decisions
+
+1. Bestehende CLI-Ausführung in einen nutzbaren gemeinsamen Runnerpfad überführen; CLI und das kleine vorgebaute Executable `tbrt` verwenden dieselbe VM-/Host-/Forms-/RUN-/Drucklogik. `tbrt` enthält nativ kompilierte VM/Runtime samt Terminal-/Forms-Unterstützung, ohne IDE oder BASIC-Quellcompiler. Eine Vorlage ohne Nutzlast meldet kontrolliert das fehlende Programm und ist kein erfolgreicher Anwenderprogrammstart. Der Runner lädt beim ersten Start und bei RUN ohne Namen sein eingebettetes Kompilat, statt sein Executable als BAS zu kompilieren. Benannte RUN-Ziele behalten die dokumentierte externe Auflösung; diese Abhängigkeiten werden nicht als automatisch eingebettet beworben.
+2. Einen kleinen gemeinsamen Exportbereich unterhalb von CLI/IDE einführen (beispielsweise eigene `tb-export`-Crate), weil CLI, Library und IDE denselben Ziel-/Vorlagen-/Publikationsvertrag benötigen. Er erhält für EXE den vollständig verknüpften Projektstand, das Target und den Zielpfad; er hängt nicht von IDE-Dokumenttypen ab. Die IDE adaptiert ihren Revisionsstempel in 04. Kein Hintergrunddienst oder globaler Paketmanager.
+3. Zielmatrix: `x86_64-pc-windows-msvc`, `aarch64-apple-darwin`, `x86_64-unknown-linux-gnu`, `aarch64-unknown-linux-gnu`. amd64/arm64 sind Anzeigenamen für x86_64/aarch64. Linux-Systembibliotheksbasis wird mit dem tatsächlichen Builder-Image dokumentiert; Standalone bedeutet eingebettete TB-Runtime, nicht ein kernelunabhängiges oder beliebig altes Linux-Binary. Keine Windows-arm64-/macOS-amd64-Produkte.
+4. Release-Pakete enthalten das passende vorgebaute `tbrt` (`tbrt.exe` auf Windows) als Exportvorlage plus Format-/Runtime-/Zielmetadaten und Integritätsdaten. 06 baut sie in Gitea Actions. 02 macht deren Bau und Prüfung zunächst lokal auf dem jeweiligen Ziel ausführbar. --target akzeptiert nur vorhandene und finalisierbare Zielvorlagen; ohne Voraussetzung gibt es eine klare Verfügbarkeitsdiagnose. Keine stillen Netzdownloads und kein impliziter Cargo-Fallback.
+5. Einen versionierten Nutzlastabschluss mit geprüften Längen/Offset und vorhandenen TBC-Laderprüfungen verwenden; Plattformformat und Runtime-Version werden vor Kopieren und Start abgeglichen. Der alte Dokumentationssatz „Anhängen ist portabel“ reicht nicht als Implementierungsbeleg. Insbesondere Mach-O wird nach dem Einbetten korrekt finalisiert/signiert; die Nutzlastauffindung darf nicht annehmen, dass ein durch Signieren veränderliches Dateiende unverändert bleibt. Native macOS-arm64-Probe und Codesign-Prüfung sind ein frühes Umsetzungstor, nicht erst Release-Nacharbeit. Eine unterstützte systemeigene Signierhilfe ist keine Compiler-/Linker-Toolchain. Cross-Export wird nur angeboten, soweit Vorlage und Finalisierung auf dem Host tatsächlich verfügbar sind.
+6. In ein temporäres Geschwisterziel schreiben, validieren/finalisieren und erst dann veröffentlichen. No-clobber und ausdrückliches Ersetzen auch beim finalen Dateischritt erzwingen, Quellen/Manifest/Includes schützen und Abbruch vor Veröffentlichung beachten. Der Vertrag wird von TBL-Export, `tbc link` und IDE wiederverwendet. P-Code-Linken und `tbc link` entstehen in 03; hier genügt das bereits vollständig verknüpfte TBC. Es gibt keine Rückabhängigkeit von 02 auf 03.
+
+## Risks / Trade-offs
+
+- Nachträgliche Binäränderung invalidiert Signaturen → finalisierte Datei auf tatsächlichem Ziel prüfen; Signierung nach Nutzlasteinbau, kein Scheinerfolg. Grundlage: [Apple Code Signing](https://developer.apple.com/library/archive/technotes/tn2206/_index.html).
+- Vorlagen aus anderer Runtime-Version → klare Version-/Zielprüfung; Release-Paket enthält zusammengehörige Erzeuger und Vorlagen.
+- Vier Ziele auf nur einem Entwicklerrechner → lokale Zielprobe ist ein Teilnachweis; 05/06 verlangen tatsächliche Zielausführung.
+- Herauslösen des Runners ändert CLI-Nebenwirkungen → vorhandene CLI-/TBC-/IDE-Parität, Exitcodes, LPRINT und RUN regressionsprüfen.
+
+## Migration Plan
+
+TBC-Standardaufruf erhalten. Native Flags mit klarer Optionsdiagnose ergänzen. Dokumentation für Erzeugen, Laufzeitdateien und Systemvoraussetzungen mitliefern. Vorlagen versionieren; inkompatible Mischungen abweisen statt zu erraten. Vorherige Release-Pakete bleiben separat nutzbar.

openspec/changes/phase-6-02-native-executables/proposal.md

@@ -0,0 +1,25 @@
+## Why
+
+`tbc build` erzeugt bisher ausschließlich TBC; ein vorkompiliertes `tbrt` existiert noch nicht. Phase 6 muss daraus direkt ausführbare Terminalprogramme machen, die ohne Quellen, separat installiertes tb/tbc oder Compiler-/Linker-Toolchain beim Anwender laufen und erzeugt werden können.
+
+## What Changes
+
+- `tbc build --exe` und einen gemeinsamen Exportpfad mit geprüften `tbrt`-Vorlagen, eingebettetem Projekt und sicherer Zieldateierzeugung einführen; bestehendes `tbc build` bleibt TBC.
+- `tbrt` enthält nativ kompilierte VM, Runtime und Terminal-/Forms-Unterstützung; BASIC bleibt eingebetteter P-Code.
+- Native Terminal-Executables für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 erzeugen.
+- Dieselbe VM-/Forms-/Host-/RUN-Semantik wie beim CLI verwenden; Container, Runtime-Version und tatsächliches Ziel prüfen.
+- Vorlagenherstellung und native Tests vorbereiten; die vollständige Gitea-Artefaktproduktion übernimmt Change 06, die IDE-Anbindung 04.
+
+## Capabilities
+
+### New Capabilities
+
+- `native-executables`: Toolchainfreie Verpackung und eigenständige Ausführung nativer Terminalprogramme.
+
+### Modified Capabilities
+
+Keine. TBC bleibt ein gesondertes Ausgabeformat mit unverändertem Sprachvertrag.
+
+## Impact
+
+CLI-Build-/Runnerpfad in `crates/tb-cli/src/main.rs`, gemeinsame Projekt-/VM-Erzeugung, neuer wiederverwendbarer Export-/Runnerbereich, Release-Vorlagen und native Prozessprüfungen. Keine LLVM-/JIT-Umstellung. Referenzfälle aus [01](../phase-6-01-kompatibilitaet-und-leistungsabnahme/proposal.md); Auslieferung in 06. Der gleiche Exportvertrag wird von 03 und 04 verwendet.

openspec/changes/phase-6-02-native-executables/specs/native-executables/spec.md

@@ -0,0 +1,41 @@
+## Purpose
+
+Ermöglicht die Erzeugung und Ausführung eigenständiger nativer Terminalprogramme mit eingebettetem Terminal-Basic-Projekt und Runtime.
+
+## ADDED Requirements
+
+### Requirement: Eigenständiges natives Terminalprogramm
+`tbc build --exe` SHALL ein natives Terminal-Executable für Windows amd64, macOS arm64, Linux amd64 oder Linux arm64 erzeugen. Die vorgebaute `tbrt`-Vorlage SHALL die nativ kompilierte VM und Runtime einschließlich Terminal-/Forms-Unterstützung enthalten und das eingebettete BASIC-Programm als P-Code ausführen. Das Ergebnis SHALL auf dem ausgewiesenen Ziel ohne Quellprojekt, separate TBC-Datei oder separat installiertes tbrt/tb/tbc laufen. Sowohl Erzeugung aus ausgelieferten Vorlagen als auch Ausführung SHALL ohne Compiler-/Linker-Toolchain beim Anwender möglich sein; dokumentierte Betriebssystemkomponenten dürfen erforderlich bleiben.
+
+#### Scenario: Leere Runtime-Vorlage
+- **WHEN** tbrt ohne eingebettetes Programm als Vorlage gestartet wird
+- **THEN** diagnostiziert es kontrolliert die fehlende Nutzlast und behauptet keinen erfolgreichen Programmstart
+
+#### Scenario: Ausführung auf sauberem Ziel
+- **WHEN** ein Mehrmodul-/Formular-/Include-Projekt exportiert und allein sein Executable in ein Verzeichnis ohne Quellen und ohne tb/tbc übertragen wird
+- **THEN** läuft es auf dem passenden Zielsystem als Terminalprogramm mit denselben Anfangseigenschaften, Ausgaben und Fehlerorten
+
+### Requirement: Explizites Ausgabeformat und Ziel
+Der bestehende Aufruf `tbc build <Quelle>` SHALL weiterhin TBC erzeugen. Native Erzeugung SHALL eine eindeutige Ziel-/Ausgabewahl und Überschreibentscheidung erlauben. Ungültige Optionen, nicht unterstützte Zielkombinationen, fehlende Vorlagen und inkompatible Runtime-Versionen MUST vor Veröffentlichung einer Zieldatei mit konkreter Diagnose abgewiesen werden. Ein fremdes Hostformat MUST NOT stillschweigend das angeforderte Zielformat ersetzen.
+
+#### Scenario: Vorlage passt nicht
+- **WHEN** eine Windows-amd64-Ausgabe mit einer Linux- oder inkompatiblen Runtime-Vorlage angefordert wird
+- **THEN** scheitert der Export unter Erhalt der bisherigen Zieldatei und nennt den Ziel-/Versionskonflikt
+
+### Requirement: Gemeinsame Laufzeitsemantik
+Native Programme SHALL bei denselben Hostereignissen, Anfangsdateien, Größen und COMMAND$ dieselben Sprach-, Forms-, Datei-, Druck- und Fehlerresultate wie der CLI-Lauf liefern. STOP, Abbruch und Laufzeitfehler SHALL die dokumentierten CLI-Exitcodes erhalten. RUN ohne Ziel SHALL den eingebetteten Anfangsstand neu starten; explizite externe RUN-Ziele SHALL weiter ausdrücklich benötigte Laufzeitdateien sein.
+
+#### Scenario: Neustart aus dem Executable
+- **WHEN** das native Programm Variablen und Dateien verändert und danach RUN ohne Programmziel ausführt
+- **THEN** startet es sein eingebettetes Projekt mit sauberem VM-Anfangszustand und benötigt dafür keine ursprüngliche BAS-/FRM-/MAK-Datei
+
+### Requirement: Validiertes und sicher veröffentlichtes Artefakt
+Der Export SHALL Nutzlastgrenzen, Container-/Runtime-Version und Zielformat prüfen und erst ein vollständiges Artefakt am gewählten Ziel veröffentlichen. Fehler und Abbruch SHALL vorhandene Ziele erhalten und temporäre Ausgaben beseitigen. Ausführungsrechte sowie die für lokale Ausführbarkeit notwendigen Plattform-Metadaten und Signaturen SHALL nach dem Einbetten gültig sein.
+
+#### Scenario: Beschädigte Nutzlast
+- **WHEN** ein erzeugtes Programm mit abgeschnittener oder ungültiger eingebetteter Nutzlast gestartet wird
+- **THEN** endet es mit verständlicher Ladefehlermeldung ohne Zugriff außerhalb der Nutzlast und ohne Ausführung von Projektcode
+
+#### Scenario: Finalisierung schlägt fehl
+- **WHEN** die plattformspezifische Finalisierung eines Exports fehlschlägt
+- **THEN** wird kein Erfolg gemeldet und eine vorhandene Zieldatei bleibt unverändert

openspec/changes/phase-6-02-native-executables/tasks.md

@@ -0,0 +1,19 @@
+## 1. Gemeinsamer Ausführungs- und Exportpfad
+
+- [ ] 1.1 CLI-Laufsteuerung für Quellen, TBC und eingebettete Kompilate wiederverwendbar machen; bestehende CLI-/IDE-Parität, Forms-Ende, STOP-/Fehlerexitcodes, LPRINT und RUN-Regressionen müssen bestehen.
+- [ ] 1.2 Ziel-/Runtime-/Vorlagenmetadaten für die vier vereinbarten Targets sowie kompatible Versionen festlegen; negative Tests müssen falsches System, Architektur, Version und fehlende Vorlage konkret abweisen.
+- [ ] 1.3 Gemeinsame geschützte Ausgabeveröffentlichung implementieren; Konflikt, Schreibfehler, zwischenzeitlich belegtes Ziel und Abbruch müssen ursprüngliche Dateien und Projektdaten erhalten.
+
+## 2. Native Programme
+
+- [ ] 2.1 Das kleine native `tbrt` mit VM/Runtime/Terminal/Forms und versioniertem eingebettetem Kompilat bauen; eine leere Vorlage muss fehlende Nutzlast diagnostizieren, ohne Originalquellen müssen Konsolen- und Forms-Programme laufen, RUN ohne Ziel muss das eingebettete Projekt neu initialisieren.
+- [ ] 2.2 Nutzlastgrenzen/-versionen prüfen und PE/ELF-/Mach-O-Ausgaben korrekt finalisieren; beschädigte Längen und abgeschnittene Nutzlast müssen ohne Absturz mit Ladefehler enden.
+- [ ] 2.3 macOS-arm64-Signierung und stabile Nutzlastauffindung nach Finalisierung praktisch belegen; native Ausführung und Signaturprüfung müssen die endgültige Datei akzeptieren, andernfalls keine Exportfreigabe.
+- [ ] 2.4 `tbc build --exe` mit Ausgabepfad, explizitem Target und Überschreibentscheidung anbinden; CLI-Tests müssen unbekannte Flags abweisen und den bisherigen TBC-Standard unverändert bestätigen.
+- [ ] 2.5 `tbrt`-Vorlagen-Bauaufrufe für Windows amd64, macOS arm64 und Linux amd64/arm64 bereitstellen; native Header-/Architekturprüfung muss jede Vorlage ihrem deklarierten Target zuordnen.
+
+## 3. Abnahme und Übergabe
+
+- [ ] 3.1 Repräsentative Fälle aus 01 als einzelne Executables in sauberen Verzeichnissen ohne Quellen/TBC/tb/tbc/Rust-Toolchain starten; Ausgabe, Dateieffekte, COMMAND$, Fehler und Terminal-/Pipeverhalten müssen mit CLI übereinstimmen.
+- [ ] 3.2 Verfügbarkeit und Systemvoraussetzungen einschließlich externer RUN-/OPEN-Ressourcen dokumentieren; fehlende Finalisierungswerkzeuge dürfen keine stille Ersatzdatei erzeugen.
+- [ ] 3.3 Gemeinsamen Exportvertrag und Zielvorlagen an 03/04/06 übergeben; fokussierte native Tests, Workspace-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, noch ausstehende externe Zielnachweise benannt sein.

openspec/changes/phase-6-03-pcode-bibliotheken-und-linker/.openspec.yaml

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

openspec/changes/phase-6-03-pcode-bibliotheken-und-linker/design.md

@@ -0,0 +1,32 @@
+## Context
+
+`project.rs::link` verbindet schon Modulprodukte und korrigiert Prozedur-, Global-, UDT-, String-, DATA- und Sprungtabellenreferenzen. Dafür benötigt es derzeit AST-Deklarationen und COMMON-Metadaten; der Compiler importiert Deklarationen vor der Absenkung. `CompiledModule`/TBC enthält viele Laufzeitdaten, ist aber ein vollständiges Programm statt eines austauschbaren unverknüpften Modulprodukts. `Manifest` akzeptiert bislang BAS/FRM, der IDE-Quelllader behandelt Mitglieder als Dokumente. 02 liefert den nativen `tbrt`-Runner und sichere EXE-Verpackung.
+
+## Goals / Non-Goals
+
+**Goals:** Vorhandene Übersetzung und Tabellenauflösung für quellfreie Bibliotheksmodule öffnen, denselben Linkdienst in CLI und IDE verwenden und die Runtime einmal im Executable halten.
+
+**Non-Goals:** C-ABI, native `.lib`/`.a`-Projektbibliotheken, DLL/QLB-Kompatibilität, eigener Maschinenobjekt-Linker, JIT/AOT von BASIC, Paketregistry, dynamisches Nachladen von TBL zur Laufzeit oder Linkzeitoptimierung. Die Runtime selbst wird weiterhin von Rust nativ kompiliert.
+
+## Decisions
+
+1. TBL als einfacher versionierter binärer Container mit eigenem Magic, festen Integerbreiten, definierter Byteordnung und längengeprüften Abschnitten. Vorhandene TBC-Kodier-/Laderbausteine wiederverwenden. Speichern: geordnete unverknüpfte Modulprodukte, exportierte Prozedur-/Konstanten-/Typdeklarationen, typisierte offene Imports, COMMON-Angaben, Initialisierungsgrenzen, Forms-Katalog/Anfangswerte/Ereignisse und Quellortmetadaten. Kein vollständiger Quell-AST und kein Rust-Speicherlayout im Dateivertrag. Reines Umbenennen eines vollständig gelinkten TBC bewahrt nicht die benötigten Linkinformationen.
+2. Die AST-abhängigen Eingaben der bestehenden Linkfunktion auf die tatsächlich nötigen Modul-/Symbolmetadaten reduzieren. Quellmodule erzeugen dieselben Metadaten wie der TBL-Lader. Deklarationen aus TBL vor der Semantikanalyse des Verbrauchers importieren; Laufzeitcode nicht rekonstruieren oder erneut kompilieren. Sämtliche Tabellenreferenzen einschließlich Forms, Ereignissen, Typen und physischen Source-IDs beim Zusammenführen abbilden. Abschließend das vollständige Kompilat validieren. Bestehende Größenlimits kontrolliert prüfen, nicht durch Integer-Casts abschneiden.
+3. Bibliotheksbau darf typisierte DECLARE-Imports offen halten; für externe Konstanten/Typen werden die Deklarationen über angegebene TBL-Eingaben bereitgestellt. Alle zum Bau als Projektmitglieder angegebenen Module werden in die Ausgabe übernommen; keine versteckten Kopien nativer Runtime und kein Dead-Code-Eliminator. Exporte folgen den bisherigen Sichtbarkeits-/Namensregeln. Beim finalen Linken müssen alle Imports eindeutig und typkompatibel aufgelöst sein. Gegenseitige Prozeduraufrufe sind zulässig; es gibt keine separate rekursive Paketauflösung.
+4. `.MAK` nimmt `.tbl` zusätzlich als Dateieintrag auf. Relative Pfade, Fallunabhängigkeit, Reihenfolge und kanonische Duplikatprüfung wiederverwenden. Ein TBL-Eintrag expandiert seine Module an dieser Position; zusätzliche CLI-Bibliotheken folgen in Argumentreihenfolge. Doppelte Modulidentitäten sind Fehler, keine stillen Überschreibungen. Abhängigkeiten werden nur aus der expliziten Eingabemenge aufgelöst; keine Netzsuche oder implizite Suche nach ursprünglichen Entwicklerpfaden. Reexport durch Library-Bau flacht enthaltene Modulprodukte ab; überlappende Bibliotheken werden beim späteren Einbinden als Duplikat diagnostiziert.
+5. Initialisierung folgt dem vorhandenen Projektvertrag: Anfangswerte vor Modulrümpfen; die Startdatei des Verbraucherprojekts bestimmt den ersten Quellmodulrumpf und gegebenenfalls das Startformular, danach übrige expandierte Module in relativer Reihenfolge. Bibliotheksmodulrümpfe sind normale Modulrümpfe, keine zusätzliche versteckte Init-Sitzung. TBL bewahrt ihre Modulreihenfolge, aber keine aktive Startdatei/Startformularentscheidung des Bibliotheksbauprojekts. Forms können vom Verbraucher aktiviert werden. RUN setzt das gesamte verknüpfte Programm über den bestehenden VM-Pfad zurück.
+6. Konkrete CLI-Oberfläche: `tbc build lib.mak --library --output lib.tbl`; `tbc link app.mak lib.tbl --output app.tbc`; mit `--exe --target <triple>` wird stattdessen ein Executable erzeugt. `tbc link app.tbc --exe ...` darf ein bereits vollständiges TBC verpacken, nimmt dafür aber keine zusätzlichen TBL an: nachträgliches Linken ohne Modulmetadaten wird diagnostiziert. `tbc build app.mak [--exe]`, `run` und `check` verarbeiten die MAK-Bibliotheken über denselben Dienst. `--library` und `--exe` schließen sich aus; TBL-/TBC-Ausgabe benötigt kein natives Target und weist `--target` in diesen Modi als unpassend ab. Kein neues `tblink`-Programm.
+7. Shared Linkdienst bleibt unterhalb von CLI/IDE im vorhandenen VM-/Projektbereich. Der Exportbereich aus 02 verpackt nur das vollständig verknüpfte TBC mit `tbrt`; er enthält keinen zweiten Compiler. 04 bindet Bibliotheksmitglieder, Start/Check/Debugger und Make-Aktionen an. Compiler-Caches und IDE-Auftragsstempel müssen die tatsächlichen Bibliotheksbytes einbeziehen; Änderungen an einer TBL dürfen kein altes Linkresultat wiederverwenden.
+8. TBL und TBC sind auf allen vier Zielen verwendbar, solange Format und Runtime kompatibel sind. Nur `tbrt` und das fertige Executable haben ein natives Target. Library-Bau und P-Code-Linken sind ausschließlich TB-Operationen; keine C-/Rust-Toolchain beim Anwender. `--exe` verwendet die Vorlagen-/Signierprüfung aus 02. Ausgaben werden über dessen Staging-/No-clobber-Vertrag publiziert; alle eingelesenen TBL-Dateien gehören zu den geschützten Eingaben.
+
+## Risks / Trade-offs
+
+- TBC enthält noch nicht alle unverknüpften Informationen → separates TBL-Metadatenschema und Vergleich eines Quellprojekts mit seinem TBL-Ersatz, keine AST-Serialisierung als Abkürzung.
+- Remapping beschädigt seltene Referenzen → Gegenproben mit UDT/COMMON, DATA/RESTORE, Forms-Ereignissen und Fehlerorten aus mehreren Libraries.
+- Modulrümpfe haben Seiteneffekte → Reihenfolge transparent dokumentieren und gegen das entsprechende Quellprojekt testen; kein stilles Umordnen nach Symbolabhängigkeiten.
+- Geänderte TBL bleibt im Cache → Inhaltsidentität in Compiler-/IDE-Snapshot, inklusive Prüfung vor Veröffentlichung.
+- Bestehende BASIC-Kollisionen erscheinen in Bibliotheken → gleiche Diagnosen statt neuer Namensraumsyntax. Gleichnamige Module werden eindeutig abgewiesen.
+
+## 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.

openspec/changes/phase-6-03-pcode-bibliotheken-und-linker/proposal.md

@@ -0,0 +1,25 @@
+## Why
+
+BASIC wird als P-Code ausgeführt; wiederverwendbare BASIC-Bibliotheken benötigen deshalb ein linkbares TB-Format. Die native Runtime steckt bereits in `tbrt` aus 02. Ein zusätzlicher C-ABI-/Systembibliotheksexport würde unnötige Erzeugungswerkzeuge und eine zweite Aufrufschnittstelle verlangen.
+
+## What Changes
+
+- `.tbl` als versioniertes, plattformunabhängiges Format für übersetzte BASIC-Module mit Symbolen, Signaturen, Imports und benötigten Daten einführen. Die native Runtime bleibt ausschließlich Bestandteil von `tbrt`.
+- `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.
+- Erzeugung und Linken benötigen weder C-/Rust-Compiler noch nativen Linker beim Anwender. Die IDE bindet denselben Dienst in 04 an.
+
+## Capabilities
+
+### New Capabilities
+
+- `pcode-bibliotheken`: Portables TBL-Format, quellfreie Wiederverwendung, gemeinsamer P-Code-Linkvertrag und CLI-/Projektintegration.
+
+### Modified Capabilities
+
+Keine. TBL ist eine additive Projekt-/Buildfähigkeit; die Anpassung der bisherigen IDE-Exportbeschreibungen erfolgt mit 04. Bestehende reine Quellprojekte und vollständige TBC-Programme behalten ihren Vertrag.
+
+## 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](../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/phase-6-03-pcode-bibliotheken-und-linker/specs/pcode-bibliotheken/spec.md

@@ -0,0 +1,51 @@
+## Purpose
+
+Ermöglicht die quellfreie Wiederverwendung übersetzter BASIC-Module als portable TBL-Bibliotheken und deren Verknüpfung zu vollständigen Programmen für dieselbe TBVM.
+
+## ADDED Requirements
+
+### Requirement: Portables TBL-Bibliotheksformat
+`tbc build --library` und Make Library SHALL eine `.tbl` mit übersetzten BASIC-Modulen, exportierten Deklarationen, typisierten Imports sowie den benötigten Daten und Forms-Ressourcen erzeugen. Sie SHALL ohne ihre ursprünglichen BAS-/FRM-/Include-Quellen weiterverwendbar sein. Das Format SHALL versioniert und unabhängig von Windows/Linux/macOS sowie amd64/arm64 sein. Native Runtime und plattformspezifischer Maschinencode MUST NOT Bestandteil der TBL sein; die native Runtime SHALL im Ziel-`tbrt` liegen.
+
+#### Scenario: Bibliothek auf einem anderen Ziel verwenden
+- **WHEN** dieselben TBL-Bytes mit kompatiblen Terminal-Basic-Versionen für die vier Releaseziele verknüpft werden
+- **THEN** liefern die Programme bei gleichen Eingaben dieselben BASIC-Ergebnisse ohne Neubau der Bibliothek aus Quellen
+
+### Requirement: Gemeinsamer Linkbefehl
+`tbc link` SHALL ein Hauptprojekt und angegebene TBL-Bibliotheken zu einem vollständig aufgelösten TBC-Programm verbinden. Mit `--exe` SHALL derselbe Befehl dieses Programm in die passende vorgebaute `tbrt`-Vorlage einbetten und ein natives eigenständiges Executable erzeugen. `tbc build`, `run` und `check` SHALL bei Projekten mit TBL-Verweisen dieselbe Auflösung verwenden. Erzeugen und Linken SHALL ohne C-/Rust-Compiler oder nativen Linker beim Anwender möglich sein; dokumentierte Systemvoraussetzungen zur EXE-Finalisierung bleiben anwendbar.
+
+#### Scenario: Quellfreie Bibliotheksnutzung bis zur EXE
+- **WHEN** nach dem TBL-Bau deren Quellen entfernt werden und ein Verbraucherprojekt über `tbc link --exe` verknüpft wird
+- **THEN** läuft das Executable anschließend ohne separate TBL/TBC, separat installiertes tbrt/tb/tbc oder Buildtoolchain mit dem korrekten Bibliotheksverhalten
+
+### Requirement: Explizite Bibliothekszuordnung
+TBL-Dateien SHALL als geordnete MAK-Einträge relativ zur Projektdatei mit der bestehenden DOS-großschreibungsunabhängigen Pfadauflösung verwendbar sein. `tbc link` SHALL zusätzliche TBL-Eingaben ausdrücklich annehmen. Bibliotheksmodule SHALL ihre Identität und Deklarationen behalten; ein TBL-Eintrag MUST NOT als editierbare Quelltextdatei oder als Startdatei interpretiert werden. Externe Bibliotheksabhängigkeiten SHALL aus den angegebenen Eingaben aufgelöst werden; fehlende Abhängigkeiten MUST vor Programmausgabe diagnostiziert werden.
+
+#### Scenario: Projekt mit verschobener Bibliothek
+- **WHEN** ein Projekt und seine relativ referenzierte TBL gemeinsam in ein anderes Verzeichnis verschoben werden
+- **THEN** bleibt das Projekt ohne Bibliotheksquellen verknüpfbar; fehlt stattdessen die TBL, nennt die Diagnose die fehlende Datei und ihren Projektbezug
+
+### Requirement: Eindeutige und typgeprüfte Verknüpfung
+Der Linkpfad SHALL Imports eindeutig mit kompatiblen Exporten verbinden und die bestehenden Regeln für Namen, Konstanten, UDTs, COMMON sowie Prozedursignaturen erhalten. Fehlende Definitionen, mehrdeutige Exporte, inkompatible Parameter-/Ergebnistypen, doppelte Modulidentitäten und überschrittene Formatgrenzen SHALL vor Programmausführung mit konkretem Bezug abgewiesen werden. Bibliotheken SHALL typisierte offene Imports speichern können; ein ausführbares Endprodukt MUST NOT unaufgelöste Imports enthalten.
+
+#### Scenario: Bibliothek benötigt eine weitere Bibliothek
+- **WHEN** Bibliothek A eine typisierte Prozedur aus B importiert und nur A zum Verbraucher angegeben wird
+- **THEN** scheitert das Linken mit dem fehlenden Symbol; nach Hinzufügen eines signaturkompatiblen B funktioniert der Aufruf, während ein inkompatibles B eine Typdiagnose auslöst
+
+#### Scenario: Mehrdeutiges Symbol
+- **WHEN** zwei eingebundene Module einen nach bestehenden Sprachregeln mehrdeutigen Export anbieten
+- **THEN** meldet der Linker den Namenskonflikt mit beiden Herkunftsmodulen und wählt keine zufällige Definition
+
+### Requirement: Erhaltene BASIC- und Laufzeitsemantik
+Verknüpfte Bibliotheksmodule SHALL dieselben Wert-, BYREF-/BYVAL-, Array-, UDT-, COMMON-, DATA-/RESTORE-, Forms- und Fehlerregeln wie entsprechende Quellmodule erfüllen. Globale Anfangswerte SHALL vor Ausführung bereitstehen; Modulrümpfe SHALL in der dokumentierten erweiterten Projektreihenfolge mit demselben Kontrollfluss wie die entsprechenden Quellmodule ausgeführt werden; bloße Symbolverweise SHALL keine zusätzliche Modulinitialisierung auslösen. Die Startauswahl SHALL dem Hauptprojekt gehören. RUN ohne Ziel SHALL auch den Bibliothekszustand neu initialisieren. Physische Fehlerorte und BASIC-Zeilenlabels SHALL trotz fehlender Bibliotheksquellen erhalten bleiben.
+
+#### Scenario: Quellmodule durch TBL ersetzen
+- **WHEN** Bibliotheksmodule eines Projekts durch ihre TBL in derselben Modulreihenfolge ersetzt und direkte sowie verknüpfte Variante mit gleichen Ereignissen gestartet werden
+- **THEN** stimmen Initialisierung, BYREF-Änderungen, strukturierte Werte, Forms-Ereignisse und Fehlerorte überein; nach RUN besitzen beide denselben frischen Anfangszustand
+
+### Requirement: Validierung und geschützte Ausgabe
+TBL-Lader und Linker SHALL Format-/P-Code-/Runtime-Kompatibilität, Grenzen und alle Tabellen-/Symbolverweise prüfen. Beschädigte oder inkompatible Bibliotheken SHALL kontrolliert abgewiesen werden. Fehler, Abbruch oder Ausgabekonflikte SHALL bestehende Ausgaben und sämtliche Eingaben einschließlich Bibliotheken erhalten. Erfolg SHALL erst nach vollständiger validierter Veröffentlichung gemeldet werden.
+
+#### Scenario: Beschädigter Container oder Ausgabe auf Eingabe
+- **WHEN** eine abgeschnittene TBL geladen wird oder das Linkziel eine der Eingabebibliotheken überschreiben würde
+- **THEN** scheitert der Vorgang mit konkreter Diagnose, führt keinen BASIC-Code aus und erhält bestehende Eingaben und Ausgaben

openspec/changes/phase-6-03-pcode-bibliotheken-und-linker/tasks.md

@@ -0,0 +1,24 @@
+## 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.
+
+## 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.
+
+## 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.
+
+## 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.

openspec/changes/phase-6-04-ide-exportanbindung/.openspec.yaml

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

openspec/changes/phase-6-04-ide-exportanbindung/design.md

@@ -0,0 +1,29 @@
+## Context
+
+`ExportRequest` enthält heute ProjectStamp, Artefaktart, System, Architektur, Zielpfad und Überschreibentscheidung. Der Dialog speichert einen geprüften Auftrag, setzt dann aber `UNAVAILABLE`. `export_result` kontrolliert Auftrag und Revision, bevor es Status übernimmt. Tatsächliche Dateierzeugung und deren Nebenwirkungen sind noch nicht angebunden. VM-/Formwerte verwenden Rc und gehören dem besitzenden Thread.
+
+## Goals / Non-Goals
+
+**Goals:** Reale Erzeugung über die bestehende UI mit konsistentem Stand, sicherem Abbruch und nachprüfbarer Dateiwirkung.
+
+**Non-Goals:** Neue Exportdialoge neben den bestehenden, zweiter Compiler, Verschieben lebender VM-/Rc-Werte in Worker, stilles Speichern der Quellen.
+
+## Decisions
+
+1. Den vorhandenen Projekt-Quelllader samt ungespeicherten Overlays und bereits etablierten Compiler verwenden. Auftrag und Snapshot erhalten eine eindeutige Generation neben dem Revisionsstempel. TBL-Dateien als unveränderliche Byte-Snapshots mit Inhaltsidentität aufnehmen und diese vor Veröffentlichung erneut gegen den aktuellen Stand prüfen. Übergabe an den gemeinsamen Dienst aus 02/03 über serialisierte Kompilat-/Modulproduktbytes und schlichte Ziel-/Auftragsdaten; keine Abhängigkeit des Diensts von der IDE.
+2. Langlaufende Paket-/Toolschritte außerhalb des UI-Ereignisloops ausführen, Ergebnisse über einen kleinen vorhandenen beziehungsweise Standardkanal zurückführen. Der Worker erzeugt zunächst nur eine temporäre fertige Ausgabe. Die UI prüft Generation, Projektstempel, Dialog-/Abbruchzustand vor der finalen Veröffentlichung; erst danach Erfolg melden. Ein bloßer später Check in export_result genügt nicht, wenn der Worker das Ziel bereits überschrieben hätte.
+3. Esc/Abbruch stoppt oder verwirft den Auftrag, bereinigt Staging und lässt das alte Ziel stehen. Kontrollierte Tools werden bei Abbruch beendet; unerwartet spät eintreffende Resultate dürfen keine Datei freigeben. Für bereits abgeschlossene Veröffentlichung zeigt die UI den wirklichen Abschluss, keinen rückwirkend erfundenen Abbruch.
+4. Für Make EXE Zielauswahl vom gemeinsamen Katalog ableiten: Windows x86_64, macOS aarch64, Linux beide. Fehlende tbrt-Vorlagen/Finalisierung konkret melden. Make Library schlägt `.tbl` vor und zeigt seine Plattformunabhängigkeit; native Ziel-/Architekturfelder entfallen in diesem Modus und sind keine Verfügbarkeitsvoraussetzung. Der bisherige generische Phase-6-Sperrtext wird durch tatsächliche Verfügbarkeit ersetzt.
+5. Bisherige Phase-5-Tests bleiben als absichtlich backendloser Testfall erhalten. Neue Fälle verwenden denselben realen Backendpfad wie CLI; kontrollierte Rückmeldungen testen zusätzlich Fehler-/Abbruch-/Veraltungsrennen. Beide existierenden Specrequirements werden vollständig einschließlich aller alten Szenarien übernommen und auf fehlende Backendverfügbarkeit konditioniert.
+
+6. Add File/Remove File und MAK-Speicherung um Bibliotheksmitglieder erweitern; TBL als Binärabhängigkeit mit Herkunft anzeigen, weder als Text editieren noch als Startdatei anbieten. Save-As erhält die relative Referenz; Remove löscht keine Library. Start/Check/Debugger verwenden denselben Dienst wie `tbc link`, damit der IDE-Lauf dem Export entspricht. Im Debugger vorhandene Quellorte bewahren; fehlt Bibliotheksquelltext, dies anzeigen und vorhandene Fortsetzen-/Prozedurschrittwege anbieten, ohne einen erfundenen editierbaren Quellstand zu öffnen. Bibliotheksänderungen invalidieren Übersetzungs-/Linkcaches.
+
+## Risks / Trade-offs
+
+- Alte Ergebnisse überschreiben neues Ziel → Veröffentlichung erst nach Generation-/Revisionstest im kontrollierenden Thread.
+- Editorinhalt und Export divergieren → eingefrorener Overlay-Snapshot; gespeicherte Dateibytes und Dirty-Markierungen in Tests vergleichen.
+- Hintergrundwerkzeug bleibt nach Esc aktiv → Prozess-/Staging-Lebensdauer an Auftrag binden und späte Rückmeldung negativ testen.
+
+## Migration Plan
+
+Vorhandene Dialoge und Tastenzuordnungen erhalten. Backendlose Starts bleiben nachvollziehbar bedienbar. Neue native Tests aus 02/03 sowie bestehende App-Abnahmetests parallel erhalten; Die additive TBL-Mitgliedsart aus 03 muss beim Öffnen/Speichern verlustfrei erhalten bleiben. Die alten Anforderungen werden für EXE-Zielwahl und portable Library-Ausgabe präzisiert; reine BAS-/FRM-Projekte bleiben unverändert.

openspec/changes/phase-6-04-ide-exportanbindung/proposal.md

@@ -0,0 +1,27 @@
+## Why
+
+Die Make-Dialoge aus Phase 5 validieren Aufträge und zeigen kontrollierte Statusrückmeldungen, führen aber noch keinen Export aus. Die Backends aus 02/03 müssen jetzt mit dem tatsächlichen aktuellen Projektstand, verlässlichem Abbruch und korrekter Ergebniszuordnung an die IDE angebunden werden.
+
+## What Changes
+
+- Make EXE File und Make Library mit dem gemeinsamen Link-/Erzeugungsdienst aus `tbc link` verbinden.
+- Make EXE zeigt die vier System-/Architektur-Ziele; Make Library erzeugt plattformunabhängiges `.tbl` ohne native Zielauswahl oder Runtime-Vorlage.
+- TBL-Mitglieder über die Projektverwaltung hinzufügen/entfernen und in MAK erhalten; Start, Check, Debugger und Export verwenden dieselbe Library-Auflösung.
+- Aktuelle ungespeicherte Modul-/Form-/Include-Inhalte als konsistenten Exportstand verwenden; Dokumente bleiben erhalten.
+- Laufende Aufträge, Abbruch, Fehler und fertige Artefakte eindeutig zuordnen, ohne die UI zu blockieren oder alte Ergebnisse als neu auszugeben.
+- Die bisherigen Phase-5-Sperrannahmen in Specs und Tests auf den tatsächlichen Fall „Backend/Vorlage fehlt“ begrenzen.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-native-exporte`: Revisionsgebundene reale Exportaufträge aus der IDE einschließlich Abbruch und Ergebnisübernahme.
+
+### Modified Capabilities
+
+- `ide-oberflaeche`: Vollständige Exportdialoge unterstützen das verfügbare Phase-6-Backend; bisherigen Nichtverfügbarkeitsfall und alle Validierungs-/Statusszenarien erhalten.
+- `ide-phasenabnahme`: Exportvorbereitung bleibt als bedingter Test ohne Erzeugungsbackend gültig, ohne die später verfügbare Erzeugung dauerhaft zu verbieten.
+
+## Impact
+
+`tb-ide/src/export.rs`, `app.rs`, nativer Terminaltreiber und App-/CLI-Abnahmetests. Wiederverwendung des gemeinsamen Exportdienstes aus 02 sowie des Library-Vertrags aus 03; kein zweiter Linker oder nativer Paketierer. Abhängigkeiten: 02 und 03; 05 prüft anschließend die echte Terminalbedienung.

openspec/changes/phase-6-04-ide-exportanbindung/specs/ide-native-exporte/spec.md

@@ -0,0 +1,44 @@
+## Purpose
+
+Verbindet die IDE-Exportdialoge mit der tatsächlichen EXE-/TBL-Erzeugung und dem gemeinsamen P-Code-Linkdienst unter Erhalt von Projektstand, Bedienbarkeit und eindeutigem Auftragsstatus.
+
+## ADDED Requirements
+
+### Requirement: Reale Erzeugung aus aktuellem Projektstand
+Make EXE File und Make Library SHALL bei verfügbaren Voraussetzungen dieselben nativen Executables beziehungsweise portablen TBL-Bibliotheken wie der gemeinsame CLI-Link-/Exportpfad erzeugen. Der Auftrag SHALL einen konsistenten Stand aller verwendeten Projekt-, Formular- und Include-Inhalte einschließlich ungespeicherter Bearbeitungen sowie der eingelesenen TBL-Bibliotheken erfassen. Export SHALL kein implizites Speichern oder Verwerfen von Dokumentänderungen erfordern.
+
+#### Scenario: Ungespeichertes Include exportieren
+- **WHEN** ein Include in der IDE geändert, noch nicht gespeichert und anschließend ein nativer Export gestartet wird
+- **THEN** enthält das Artefakt die Änderung, während die Quelldatei auf dem Datenträger und der Bearbeitungsstatus erhalten bleiben
+
+### Requirement: Verfügbarkeit und Zielkonsistenz
+Für Make EXE SHALL die IDE Windows amd64, macOS arm64 und Linux amd64/arm64 entsprechend den tatsächlichen tbrt-Vorlagen und Finalisierungsmöglichkeiten anbieten. Make Library SHALL `.tbl` als plattformunabhängiges Ergebnis ausweisen und ohne native Zielauswahl oder Runtime-Vorlage funktionieren. Fehlende Backend-/Vorlagen-/Systemvoraussetzungen SHALL konkret angezeigt werden. Eine unzulässige Kombination oder TBC-Datei MUST NOT als erfolgreiche native Ausgabe erscheinen.
+
+#### Scenario: Fehlende Zielvorlage
+- **WHEN** ein gültiges Releaseziel gewählt wird, dessen Vorlage auf dem Host fehlt
+- **THEN** bleibt der Dialog bedienbar und erklärt die fehlende Voraussetzung ohne Erzeugung eines anderen Zielformats
+
+### Requirement: Abbruch und eindeutige Veröffentlichung
+Die IDE SHALL während der Erzeugung bedienbar bleiben und einen wirksamen Abbruch erlauben. Nur der weiterhin gültige Auftrag SHALL sein fertig validiertes Artefakt veröffentlichen und Erfolg melden. Abgebrochene, überholte oder fremde Ergebnisse MUST NOT ein neueres Ergebnis überschreiben oder als Erfolg des aktuellen Projekts erscheinen; vorhandene Zieldateien SHALL bei solchen Abbrüchen erhalten bleiben.
+
+#### Scenario: Ergebnis trifft nach Projektwechsel ein
+- **WHEN** während eines Exports das Projekt gewechselt oder ein neuerer Auftrag begonnen wird und danach ein altes Ergebnis eintrifft
+- **THEN** wird das alte Ergebnis nicht veröffentlicht und weder dem neuen Projekt noch dessen Dialog als Erfolg zugeordnet
+
+### Requirement: Bedienung bis zur unabhängigen Nutzung
+Tastatur- und Mauswege SHALL Export, Fehlerkorrektur und Rückkehr zum Projekt gleichwertig ermöglichen. Der vollständige IDE-Abnahmepfad SHALL tatsächlich erzeugte Executables starten und TBL-Bibliotheken mit einem separaten BASIC-Verbraucher über `tbc link` verwenden.
+
+#### Scenario: Export aus der IDE benutzen
+- **WHEN** ein Projekt über den Make-Dialog erfolgreich exportiert wird
+- **THEN** lässt sich das Ergebnis unabhängig von der IDE nativ ausführen beziehungsweise ohne Library-Quellen in einem anderen BASIC-Projekt verknüpfen und die Dokumente bleiben unverändert bearbeitbar
+
+### Requirement: Bibliotheken im IDE-Projekt
+Die IDE SHALL TBL-Mitglieder über Add File/Remove File verwalten und ihre Reihenfolge und relativen Verweise beim MAK-Speichern erhalten. Bibliotheken MUST NOT als editierbarer Quelltext oder als Startdatei angeboten werden. Start, Check, Debugger und Export SHALL dieselbe Bibliotheksauflösung wie `tbc link` verwenden. Geänderte Bibliotheksinhalte SHALL veraltete Compiler-/Linkergebnisse und ausstehende Exportaufträge invalidieren.
+
+#### Scenario: Bibliothek nach einem Lauf ersetzen
+- **WHEN** eine TBL im Projekt nach einem Lauf durch eine geänderte Bibliothek ersetzt und das Projekt erneut gestartet wird
+- **THEN** nutzt die IDE deren aktuelle Deklarationen und P-Code; ein noch ausstehender Export mit den alten Bytes wird nicht als aktueller Stand veröffentlicht
+
+#### Scenario: Portable Library ohne native Vorlage
+- **WHEN** Make Library für ein gültiges Projekt ohne verfügbare tbrt-Zielvorlage verwendet wird
+- **THEN** erzeugt die IDE dennoch eine nutzbare `.tbl` ohne System-/Architekturwahl; ein späterer EXE-Export prüft seine eigenen Zielvoraussetzungen

openspec/changes/phase-6-04-ide-exportanbindung/specs/ide-oberflaeche/spec.md

@@ -0,0 +1,20 @@
+## MODIFIED Requirements
+
+### Requirement: Vollständige Exportdialoge mit getrennter Erzeugung
+Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare Dialoge für Artefaktart, Zielsystem/-architektur und Ausgabepfad öffnen. Mit Phase 6 SHALL die Ziele als natives eigenständiges Executable mit nativer Runtime in tbrt beziehungsweise portable P-Code-Bibliothek `.tbl` beschrieben sein. System-/Architekturwahl SHALL nur für EXE erforderlich sein; Make Library SHALL ohne native Zielvorlage verfügbar sein, sobald sein Backend vorhanden ist. Die Dialoge SHALL Eingaben prüfen, Überschreibkonflikte behandeln und Zustände für Erzeugung, Erfolg, Fehler und Abbruch darstellen können. Die tatsächliche Erzeugung SHALL erst mit dem Backend aus Phase 6 verfügbar sein; bis dahin SHALL nur die Erzeugungsaktion mit einem verständlichen Verfügbarkeitsgrund gesperrt sein. Die IDE MUST NOT einen Export vortäuschen oder ein bloßes TBC-Kompilat als natives Artefakt ausgeben.
+
+#### Scenario: Dialoge vor dem Erzeugungsbackend
+- **WHEN** beide Make-Befehle ohne verfügbares Erzeugungsbackend über Menü oder Tastatur geöffnet werden
+- **THEN** lassen sich die zur Artefaktart passenden Angaben (EXE-Zielsystem/-architektur und Ausgabepfad, für TBL der Ausgabepfad) bearbeiten und validieren; die fehlende Erzeugung wird erklärt und keine Zieldatei geschrieben
+
+#### Scenario: Fehlerhafte Ausgabeangaben
+- **WHEN** ein leerer oder unzulässiger Ausgabepfad beziehungsweise ein bestehendes Ziel ohne Überschreibentscheidung angegeben wird
+- **THEN** zeigt der Dialog den Eingabefehler oder die notwendige Entscheidung und behält die übrigen Angaben
+
+#### Scenario: Ergebnisdarstellung über die vorbereitete Übergabe
+- **WHEN** die Exportanbindung im Oberflächentest Erzeugung, Erfolg, Fehler und Abbruch mit demselben gültigen Auftrag zurückmeldet
+- **THEN** zeigt die IDE jeweils den passenden Zustand mit Ziel beziehungsweise Diagnose und erhält die Projektdokumente; der Test behauptet keine tatsächliche native Dateierzeugung
+
+#### Scenario: Verfügbares Erzeugungsbackend
+- **WHEN** ein gültiger Auftrag bei verfügbarem Backend tatsächlich erfolgreich erzeugt wird
+- **THEN** zeigt der Dialog den bestätigten Erfolg mit dem passenden EXE- oder TBL-Zielartefakt und erhält die Projektdokumente

openspec/changes/phase-6-04-ide-exportanbindung/specs/ide-phasenabnahme/spec.md

@@ -0,0 +1,8 @@
+## MODIFIED Requirements
+
+### Requirement: Export-UI als eigene Phasenleistung
+Die Phase-5-Abnahme SHALL die vollständige Bedienung von Make EXE File und Make Library einschließlich Zielsystem/-architektur, Ausgabepfad, Validierung, Überschreibentscheidung sowie Status-/Fehler-/Abbruchdarstellung prüfen. Solange das jeweilige Erzeugungsbackend fehlt, SHALL dessen Nichtverfügbarkeit ausdrücklich erkennbar sein. Bei verfügbarem Backend SHALL die Integration zusätzlich echte EXE-/TBL-Artefakte nachweisen und die native Zielwahl auf EXE beschränken. Die Abnahme SHALL Oberflächennachweise von der späteren tatsächlichen Erzeugung eigenständiger nativer Executables und portabler TBL-Bibliotheken mit quellfreier Wiederverwendung unterscheiden.
+
+#### Scenario: Exportvorbereitung ohne Scheinerfolg
+- **WHEN** beide Exportdialoge ohne verfügbares Erzeugungsbackend im durchgängigen IDE-Ablauf mit gültigen und ungültigen Angaben bedient werden
+- **THEN** funktionieren Eingabe, Validierung und Rückkehr zum Projekt, die Erzeugungsaktion nennt die Phase-6-Abhängigkeit und weder eine falsche Erfolgsmeldung noch eine als natives Artefakt ausgegebene TBC-Datei entsteht

openspec/changes/phase-6-04-ide-exportanbindung/tasks.md

@@ -0,0 +1,20 @@
+## 1. Auftrag und Backend
+
+- [ ] 1.1 Bestehenden ExportRequest mit dem gemeinsamen Dienst aus 02/03 verbinden; ein Auftrag muss den aktuellen Modul-/Form-/Include-Overlaystand ohne implizites Speichern erfassen und per Test belegen.
+- [ ] 1.2 Zielauswahl aus dem gemeinsamen Vierziel-Katalog ableiten; App-Tests müssen ungültige EXE-Kombinationen, fehlende tbrt-Vorlagen und Finalisierung diagnostizieren sowie TBL-Ausgabe ohne native Zielauswahl/Vorlage ermöglichen.
+- [ ] 1.3 Langlaufende Erzeugung mit eindeutiger Auftragsgeneration und temporärem Ergebnis an den Terminaltreiber anbinden; ein verzögerter Testauftrag muss weitere UI-Eingaben zulassen, ohne lebende Rc-/VM-Werte zu übertragen.
+
+- [ ] 1.4 TBL-Mitglieder an Projektverwaltung, MAK-Roundtrip/Save-As und Start/Check/Debugger anbinden; Add/Remove ohne Dateilöschung, unzulässige Library-Startauswahl, quellfreie Prozeduraufrufe und ehrliche Anzeige fehlender Debuggerquellen testen.
+- [ ] 1.5 TBL-Bytes in Cache-/Auftragsidentität aufnehmen; geänderte Libraries müssen eine Neuverknüpfung erzwingen und während des Exports ausgetauschte Libraries die Veröffentlichung des alten Auftrags verhindern.
+
+## 2. Abschluss und Abbruch
+
+- [ ] 2.1 Validierung von Generation, Projektstempel und Abbruch vor Dateiveröffentlichung implementieren; Projektwechsel und konkurrierende Aufträge dürfen weder alte Ziele überschreiben noch fremden Erfolg anzeigen.
+- [ ] 2.2 Esc/Abbruch und Fehlerbereinigung implementieren; Tests müssen Kindprozessende beziehungsweise verworfenes Spätergebnis, entfernte Staging-Dateien und unveränderte bestehende Ziele nachweisen.
+- [ ] 2.3 Echte Status-/Ziel-/Diagnoseanzeige und Rückkehr zum Projekt anbinden; Tastatur- und Mauswege müssen denselben Auftrag auslösen und alle Dirty-/Dokumentzustände erhalten.
+
+## 3. Integration und Speckonsistenz
+
+- [ ] 3.1 Backendlose Phase-5-Tests ausdrücklich mit fehlendem Backend weiterführen und zusätzliche reale Exportfälle ergänzen; beide Modi müssen ihre unterschiedlichen Erfolg-/Verfügbarkeitsbedingungen belegen.
+- [ ] 3.2 Vollständigen IDE-Hauptablauf um tatsächlichen EXE-Start und TBL-Export mit separatem BASIC-Verbraucher über `tbc link` ergänzen; Ausgabe, Änderungen im ungespeicherten Include, IDE-/CLI-Linkparität und erhaltene Quellbytes prüfen.
+- [ ] 3.3 Alle geänderten und neuen Spec-Szenarien mit Tests zuordnen; native Tests, bestehende IDE-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen ohne offenen Befund bestehen.

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.

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

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

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

@@ -0,0 +1,30 @@
+## 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.
+
+## Goals / Non-Goals
+
+**Goals:** In Actions erzeugte, geprüfte und vollständig paketierte Zielartefakte; nachvollziehbare Gitea-Releases.
+
+**Non-Goals:** Repository-Mirror, zweite CI-Plattform, Installer-/GUI-Produkt, reine Cross-Compile-Ergebnisse als native Abnahme.
+
+## 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/).
+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.
+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.
+- 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.
+- Fehler beim Upload → vollständige Pflichtasset-Liste vor Freigabe prüfen; bestehende vollständige Releases nicht beschädigen.
+
+## Migration Plan
+
+Lokale Skripte zuerst lauffähig machen, dann Gitea-Runner und Workflows anbinden. PR-/Push-Lauf ohne Veröffentlichung prüfen; kontrollierter Tag-/Release-Lauf nach erfolgreicher Matrix. Bisherige lokale Cargo-Nutzung erhalten. Rollback über vorheriges vollständiges Release und Rücknahme der Workflowänderung; keine Server-/Runnerinstallation durch bloße Proposal-Erstellung.

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

@@ -0,0 +1,25 @@
+## Why
+
+Das Repository am bestehenden Gitea-Origin enthält noch keine CI-/Release-Workflows. Für eine vollständige Phase 6 müssen die vier vereinbarten Zielartefakte in Gitea Actions gebaut, auf ihren Zielsystemen geprüft und als nutzbare Release-Pakete ausgeliefert werden.
+
+## 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.
+- 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.
+
+## Capabilities
+
+### New Capabilities
+
+- `gitea-distribution`: Geprüfte Vierziel-Builds und Release-Pakete vom bestehenden Gitea-Origin.
+
+### Modified Capabilities
+
+Keine.
+
+## Impact
+
+Neue `.gitea/workflows/`, wiederverwendbare lokale Build-/Paket-/Prüfaufrufe, Gitea-Runner und Release-Artefakte. tbrt-Vorlagen stammen aus 02, TBL-/Linkprüfungen aus 03, IDE-Anbindung aus 04, Zielprüfungen aus 05, Abnahmekorpus aus 01. Finale öffentliche Dokumentation und Phasenabnahme folgen in 07. Gitea ist die einzige CI-/Release-Plattform.

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

@@ -0,0 +1,33 @@
+## Purpose
+
+Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier festgelegten Ziele über Gitea Actions und Releases am bestehenden Origin aus.
+
+## 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.
+
+#### Scenario: Ein Ziel fehlt
+- **WHEN** drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
+- **THEN** wird kein vollständiger Release veröffentlicht und das fehlende Ziel bleibt erkennbar
+
+### Requirement: Nutzbare Releasearchive
+Windows SHALL als `.7z` ausgeliefert werden; macOS und beide Linux-Architekturen SHALL jeweils als `.tar.gz` ausgeliefert werden. Jedes Archiv SHALL die passenden IDE-/Compiler-Executables `tb`/`tbc` und `tbrt` als native Runtime-/Exportvorlage (Windows jeweils mit `.exe`), benötigte Metadaten, Lizenz und Benutzungshinweise enthalten. Architektur, Version und Betriebssystem SHALL im Dateinamen eindeutig sein; Dateirechte und notwendige Begleitdateien SHALL erhalten bleiben.
+
+#### Scenario: Aus Archiv starten
+- **WHEN** ein Zielarchiv in ein sauberes Verzeichnis entpackt wird
+- **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.
+
+#### 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.
+
+#### Scenario: Paket beschädigt oder Upload unvollständig
+- **WHEN** ein Archiv nach dem Bau verändert wird oder ein Pflichtasset nicht hochgeladen werden kann
+- **THEN** verhindert die Integritäts-/Vollständigkeitsprüfung die Freigabe und nennt das betroffene Asset

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

@@ -0,0 +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.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.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.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.

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/.openspec.yaml

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

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

@@ -0,0 +1,27 @@
+## Context
+
+README nennt derzeit noch „Projektrahmen“, die Korpus-README enthält frühere Phasenaussagen, Exportseiten nennen das noch fehlende Backend. PLAN verweist bei der Endabnahme historisch auf 285 Spracheinträge; das heutige Inventar führt zusätzlich das vollständige Forms-Objektmodell. Help bettet docs und PLAN zur Buildzeit ein. 01–06 liefern neue Fähigkeiten und konkrete Artefaktnachweise.
+
+## Goals / Non-Goals
+
+**Goals:** Ein zusammenhängender, reproduzierbarer Nutzerweg aus Releaseartefakten und eine belegte Gesamtentscheidung über Phase 6.
+
+**Non-Goals:** Sprachelemente aus Stufe 2, neuer Dokumentationsgenerator, Abnahme durch bloßes Abhaken, automatische Ausdehnung von Non-Features.
+
+## Decisions
+
+1. Bestehende docs als einzige Hilfe-/Referenzquelle erhalten. Native Runtime in tbrt, portables TBL und vollständiges TBC ausdrücklich unterscheiden; native `.lib`/`.a` oder eine C-Verbraucherschnittstelle sind kein Phase-6-Exportziel. README, Tutorial, Migration, TBC-/TBL-/tbrt-Vertrag, `tbc link`, IDE-Library-Einbindung, Paketinhalt und OS-Mindeststände anhand der tatsächlichen CLI-/IDE-Implementierung prüfen. Neue Seiten ausdrücklich im Help-Katalog registrieren und interne Links testen. Historische Reports werden nicht rückwirkend als neue Messungen umgeschrieben.
+2. Den Phase-5-Hauptablauf und Abnahmesatz aus 01 verwenden; zusätzliche Schritte arbeiten mit aus 06 entpackten Tools, echten nativen Ausgaben und einem separaten BASIC-Verbraucher aus 03 ohne Library-Quellen. Keine zweite allgemeine Testframeworkschicht. Pro Ziel konkrete Prozess-/Terminal-/Dateiresultate aufzeichnen.
+3. `inventar.rs`, feste Sollquellen und VM-Ereignisauslöser erneut vollständig ausführen; Summen aus allen aktuellen Einträgen ermitteln. Historische 285 Sprachelemente sind eine Herkunftszahl, keine Sollobergrenze. Gefundene Lücken in ihrem Fachpfad beheben und deren Proben wiederholen; Quellen und Non-Feature-Fundstellen erhalten.
+4. Die acht Planpunkte erhalten explizite Nachweise aus 01–06 plus finalem Gesamtweg. Referenzmessung nach sämtlichen Fachkorrekturen, kein Wiederholen unveränderter teurer Prüfungen ohne Anlass. Gitea-Run-/Release-IDs, Commit, Paketprüfsummen und Matrixzellen bilden die Releaseevidenz.
+5. Veraltete Hinweise in PLAN (einschließlich der doppelten Einordnung von `tbc build --exe` unter Stufe 2) und Dokumenten konsistent bereinigen. Tatsächliche Stufe-2-Ideen bleiben unbeschlossen. Ein fehlender Prüfrechner oder Releasezugang bleibt ein Blocker für die Abnahme, keine unterstellte erfolgreiche Prüfung.
+
+## Risks / Trade-offs
+
+- Dokumente beschreiben Wünsche statt Code → Anleitungen mit entpackten Programmen ausführen und Help-Katalog prüfen.
+- Ein später Fix entwertet vorherige Matrix → betroffene Prüfpfade auf der neuen Revision wiederholen und veraltete Evidenz kennzeichnen.
+- Inventarsummen werden verkürzt → vollständige aktuelle Tabellen inklusive Forms prüfen, nicht nur historische Kernzahl.
+
+## Migration Plan
+
+Dokumente schrittweise mit jeweiligen Fachfeatures aktualisieren, hier endgültig abgleichen. PLAN-Checkboxen erst nach vollständiger Abnahme setzen. Releasekorrekturen führen zu neuem nachvollziehbarem Artefaktstand; vorhandene Releases bleiben referenzierbar.

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

@@ -0,0 +1,24 @@
+## Why
+
+Nach den Einzelchanges muss Phase 6 anhand tatsächlich ausgelieferter Programme, aktueller Dokumentation und vollständiger Inventarnachweise abgeschlossen werden. Veraltete README-/Korpus-/Exportbeschreibungen und bloß vorhandene Workflowdateien dürfen keinen fertigen Release vortäuschen.
+
+## What Changes
+
+- README, Sprach-/Migrations-/Dateiformat-/IDE-/Exportdokumentation und ausführbare Beispiele auf den endgültigen Stand bringen; eingebettete Hilfe mitprüfen.
+- Installation aus allen vier Release-Paketen, IDE-Projektaufbau, TBL-Bau, `tbc link`, IDE-Library-Einbindung und eigenständige EXE-Nutzung zusammenhängend abnehmen.
+- Das vollständige aktuelle Sprach- und Forms-Inventar mit null offenen Einträgen und begründeten Non-Features prüfen; die historische Zahl 285 nicht als Grenze des erweiterten Inventars verwenden.
+- Alle acht Phase-6-Planpunkte mit aktuellen Nachweisen, Revisionen und Artefakten verbinden und erst dann abschließen.
+
+## Capabilities
+
+### New Capabilities
+
+- `phase-6-abnahme`: Dokumentierte, auslieferbare Gesamtleistung mit vollständiger Inventar- und Artefaktabnahme.
+
+### Modified Capabilities
+
+Keine. Bestehende Sprach-/Inventarverträge werden erneut geprüft, nicht abgeschwächt.
+
+## Impact
+
+PLAN.md, README.md, docs, examples und Help-Katalog sowie Abschlussnachweise. Keine vorgezogenen Stufe-2-Spracherweiterungen. Abhängigkeiten: alle Changes 01–06 mit synchronisierten Specs und tatsächlichen Prüfergebnissen; abgeschlossene Aufgabenlisten allein genügen nicht.

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/specs/phase-6-abnahme/spec.md

@@ -0,0 +1,33 @@
+## Purpose
+
+Schließt Phase 6 ausschließlich anhand aktueller, nachvollziehbarer Dokumentation, vollständiger Inventarprüfungen und tatsächlich nutzbarer Releaseartefakte ab.
+
+## ADDED Requirements
+
+### Requirement: Dokumentation des ausgelieferten Verhaltens
+README, Sprach-/Bibliotheks-/Migrationsreferenz, IDE-Hilfe und Beispiele SHALL die tatsächlich ausgelieferten Befehle, Formate, Zielplattformen und Systemvoraussetzungen widerspruchsfrei erklären. Native Runtime in tbrt, eigenständiges EXE, vollständiges TBC und wiederverwendbares TBL SHALL unterschieden und Installation aus den vier Gitea-Releasearchiven beschrieben sein. Interne Hilfelinks SHALL auflösbar und die Hilfe offline verfügbar bleiben.
+
+#### Scenario: Anleitung aus dem Release verwenden
+- **WHEN** ein Benutzer der Installations- und Exportanleitung aus dem entpackten Release folgt
+- **THEN** erreicht er mit den beschriebenen Befehlen ein lauffähiges natives Programm beziehungsweise eine nutzbare Bibliothek ohne undokumentierte Entwicklungsumgebung
+
+### Requirement: Vollständiges Inventar ohne offene Einträge
+Die Endabnahme SHALL das gesamte aktuelle Sprach- und Forms-Inventar gegen Referenzquellen, Frontend, Absenkung und tatsächliche Laufzeitauslöser prüfen. Die Zahl offener Einträge SHALL null sein. Non-Features SHALL weiterhin ausdrücklich vom Projekt festgelegt und mit Fundstelle dokumentiert sein; fehlende Funktionen MUST NOT allein zur Abnahme in Non-Features umbenannt werden.
+
+#### Scenario: Ein offener oder falsch behaupteter Eintrag
+- **WHEN** ein Inventareintrag offen ist oder sein behaupteter Laufzeitpfad nicht nachgewiesen werden kann
+- **THEN** bleibt die Endabnahme offen und nennt den Eintrag und seinen fehlenden Nachweis unabhängig von der historischen Inventargröße
+
+### Requirement: Gesamtweg aus ausgelieferten Artefakten
+Die Endabnahme SHALL mit den fertigen Releasepaketen auf Windows amd64, macOS arm64 und Linux amd64/arm64 Installation, IDE-Projektaufbau, Speichern, Debuggen, native Erzeugung und unabhängige Nutzung prüfen. Für TBL-Bibliotheken SHALL quellfreie Wiederverwendung durch ein separates BASIC-Projekt über CLI-Linkbefehl und IDE, für Executables ein Start ohne TB-Installation belegt sein. Gegenüber den geltenden Sprachverträgen SHALL kein offener Befund verbleiben.
+
+#### Scenario: Releaseprogramm außerhalb des Checkouts
+- **WHEN** der dokumentierte Gesamtweg außerhalb des Entwicklungscheckouts mit einem entpackten Release durchgeführt wird
+- **THEN** funktionieren Projekt-/Export-/Nutzungsschritte ausschließlich mit den beschriebenen Artefakten und Systemvoraussetzungen
+
+### Requirement: Evidenzgebundener Phasenabschluss
+Jeder Phase-6-Planpunkt SHALL vor dem Abhaken auf bestandene Nachweise mit Revision, Plattform und Artefakt verweisen. Workspace-Regressionen, Native-/Verbrauchertests, Plattformmatrix, Inventar und bestehende Compile-Budgets SHALL auf dem finalen Stand bestehen. Fehlende externe Systeme oder noch nicht ausgeführte Workflows MUST als fehlende Nachweise sichtbar bleiben.
+
+#### Scenario: Vollständige Artefakte aber fehlender Test
+- **WHEN** alle Change-Dokumente vorhanden sind, aber eine erforderliche Plattform- oder Releaseprüfung fehlt
+- **THEN** bleibt Phase 6 offen und der Bericht unterscheidet vollständige Planung von bestandener Umsetzung

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

@@ -0,0 +1,18 @@
+## 1. Dokumentation und Beispiele
+
+- [ ] 1.1 README und Installations-/CLI-/Exportdokumentation auf die vier Gitea-Releasepakete aktualisieren; alle angegebenen Befehle müssen mit entpackten Executables außerhalb des Checkouts funktionieren.
+- [ ] 1.2 Migration, Sprach-/Dateiformat-/Library-Vertrag und Systemvoraussetzungen abgleichen; konkrete Beispiele müssen EXE/TBC/TBL, native Runtime in tbrt, externe Laufzeitdateien und Library-Wiederverwendung korrekt demonstrieren.
+- [ ] 1.3 IDE-Tutorial und eingebettete Hilfe auf die echte Exportanbindung aktualisieren; Katalog-/Offline-/Linktests und tatsächliche Menü-/F1-Wege müssen bestehen.
+- [ ] 1.4 Veraltete PLAN-/Korpus-/README-Aussagen einschließlich historischer Inventargrenze und doppeltem Stufe-2-EXE-Punkt bereinigen; Abgleich muss Phase-6-Leistung von weiterhin unbeschlossenen Erweiterungen trennen.
+
+## 2. Endgültige Nachweise
+
+- [ ] 2.1 Vollständiges aktuelles Sprach-/Forms-Inventar mit Sollquellen, Absenkung und Ereignisauslösern prüfen; null offene Einträge und jede Non-Feature-Fundstelle im Bericht belegen.
+- [ ] 2.2 Gesamtweg Installation → IDE-Projekt → Debuggen → TBL-Export → separates BASIC-Projekt/`tbc link` → eigenständige EXE-Nutzung auf allen vier Zielen ausführen; jeweilige Paketprüfsumme, Revision und beobachtete Resultate protokollieren.
+- [ ] 2.3 Alle sieben Changes und ihre Abhängigkeiten gegen synchronisierte Specs prüfen; gefundene Fachbefunde im zuständigen Bereich beheben und betroffene Nachweise bis zu null offenen Befunden wiederholen.
+- [ ] 2.4 Workspace-, TBL-Link-/native EXE-, Plattform-/Release- und Compile-/VM-Leistungsnachweise auf dem finalen Stand abschließen; fehlende externe Nachweise ausdrücklich offen lassen, keine historischen Messungen als neue ausgeben.
+
+## 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.2 Abschließende Doku-/Help-/OpenSpec-Konsistenz prüfen; keine unaufgelösten Links, widersprüchlichen Exporthinweise oder offenen Phase-6-Befunde dürfen verbleiben.