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
-      https://github.com/cout/vbdos ohne Non-Features kompilieren und
+- [x] Meilenstein (erster Kompatibilitätstest): die Programme des
+      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
-      Buildpfad erzeugen eine tatsächlich nutzbare Bibliothek im nativen
-      Bibliotheksformat des jeweiligen Zielsystems. Exportierte Symbole,
-      Aufruf-/Linkvertrag und erforderliche Runtime-Einbettung werden in
-      Phase 6 festgelegt und mit einem nativen Verbraucher geprüft; eine
-      umbenannte `.tbc`-Datei ist keine Systembibliothek. Dialoge und
-      Bedienung entstehen bereits in Phase 5, Erzeugung und Backend-Anbindung
-      in Phase 6.
+- [ ] **P-Code-Bibliotheken und Linker:** IDE → Make Library und
+      `tbc build --library` erzeugen portable `.tbl`-Bibliotheken mit
+      übersetzten Modulen, Symbolen, Signaturen und benötigten Daten.
+      `tbc link` verbindet Hauptprojekt und Libraries zu einem vollständigen
+      `.tbc` oder mit `--exe` und der passenden `tbrt`-Vorlage zu einem
+      eigenständigen Executable. Die IDE nutzt denselben Linkdienst für
+      Projekte mit `.tbl`-Verweisen und die Make-Aktionen. Wiederverwendung
+      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