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

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

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

openspec/changes/archive/2026-09-07-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. 03 wird mit Backend-/CLI-Regressionen, festem TBL-Artefakt samt Prüfsumme und Verbraucherprobe auf dem verfügbaren Host abgenommen. IDE-Anbindung in 04, echte Ausführung derselben TBL-Bytes auf allen vier Zielsystemen in 05, zentraler Cross-Paketbau und paketgebundene Zielnachweise in 06, Benutzerweg in 07. Diese Aufteilung ändert den Portabilitätsvertrag nicht; fehlende Zielausführungen bleiben dort offen. Der verworfene native Bibliotheksentwurf war nicht implementiert und erfordert keine Produktdatenmigration.

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

@@ -0,0 +1,26 @@
+## 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.
+- Die Abnahme dieses Changes umfasst Backend/CLI, ein festes gemeinsames TBL-Testartefakt und die lokal ausgeführte Verbraucherprobe. Echte Vierzielnachweise werden verbindlich in 05 und für Releasepakete in 06 erbracht.
+- Erzeugung und Linken benötigen weder C-/Rust-Compiler noch nativen Linker beim Anwender. Die IDE bindet denselben Dienst in 04 an.
+
+## Capabilities
+
+### 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](../2026-09-07-phase-6-02-native-executables/proposal.md). Abhängigkeit: 02. IDE-Dokumentmodell, Ausführung, Debugger und Make-Anbindung folgen in 04; plattformübergreifende Verbraucherprüfungen in 05/06, Dokumentation und Gesamtabnahme in 07. Dieser Entwurf ersetzt den noch nicht implementierten Entwurf `phase-6-03-native-bibliotheken` vollständig.

openspec/changes/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/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/archive/2026-09-07-phase-6-03-pcode-bibliotheken-und-linker/tasks.md

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

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

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