Phase 6: Native Executables implementieren und Change archivieren

openspec/changes/archive/2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/phase-6-uebersicht.md

@@ -38,12 +38,12 @@ plant die gesamte Phase 6; es behauptet keine neue Implementation oder Abnahme.
 | 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 |
+| 02 | [Native Executables](../2026-09-07-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

openspec/changes/archive/2026-09-07-phase-6-02-native-executables/.openspec.yaml

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

openspec/changes/archive/2026-09-07-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/archive/2026-09-07-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](../2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/proposal.md); Auslieferung in 06. Der gleiche Exportvertrag wird von 03 und 04 verwendet.

openspec/changes/archive/2026-09-07-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/archive/2026-09-07-phase-6-02-native-executables/tasks.md

@@ -0,0 +1,19 @@
+## 1. Gemeinsamer Ausführungs- und Exportpfad
+
+- [x] 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.
+- [x] 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.
+- [x] 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
+
+- [x] 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.
+- [x] 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.
+- [x] 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.
+- [x] 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.
+- [x] 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
+
+- [x] 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.
+- [x] 3.2 Verfügbarkeit und Systemvoraussetzungen einschließlich externer RUN-/OPEN-Ressourcen dokumentieren; fehlende Finalisierungswerkzeuge dürfen keine stille Ersatzdatei erzeugen.
+- [x] 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/archive/2026-09-07-phase-6-02-native-executables/verification.md

@@ -0,0 +1,141 @@
+# Verifizierung: phase-6-02-native-executables
+
+Stand: 2026-09-07, Arbeitsbaum auf `993c3e7638f4819615ce6d1eea2c984afb29a1f2`.
+Der vorausgehende Change 01 wurde synchronisiert, archiviert und mit diesem
+Commit auf `origin/main` bestätigt. Dieser Bericht betrifft Change 02.
+
+## Ergebnis
+
+| Dimension | Nachweis |
+| --- | --- |
+| Vollständigkeit | 11/11 Aufgaben; 4/4 Requirements |
+| Korrektheit | Alle 6 Spec-Szenarien abgedeckt; native macOS-arm64-Ausführung bestanden |
+| Kohärenz | Gemeinsamer Runner, bestehende VM/TBC/Forms-Semantik, vorgebaute Runtime und geschützter Export gemäß Design |
+| Offene Befunde | 0 CRITICAL, 0 WARNING, 0 SUGGESTION |
+
+Proposal, Design, Tasks, Delta-Spec, betroffene Ausführungspfade und
+Regressionen wurden geprüft. Keine Prüfdimension übersprungen. Die nach
+Design ausdrücklich späteren realen Windows-/Linux-Abnahmen sind unten
+getrennt benannt; sie werden nicht als durchgeführt ausgegeben.
+
+## Requirement- und Szenariozuordnung
+
+| Requirement / Szenario | Implementierung und ausgeführter Nachweis |
+| --- | --- |
+| Eigenständiges natives Terminalprogramm / Leere Runtime-Vorlage | `crates/tb-runner/src/bin/tbrt.rs:13` liest sein eigenes Executable; `tb_export::embedded` prüft vor VM-Start. Native Probe: leere Vorlage liefert Exit 1 und Nutzlastdiagnose. |
+| Eigenständiges natives Terminalprogramm / Ausführung auf sauberem Ziel | `crates/tb-export/src/lib.rs:471`, `tests/support/native-abnahme.py`: sieben CLI-/EXE-Vergleiche, darunter ein Forms-/Mehrmodulprojekt mit verschachtelten Includes. Quellen vor EXE-Start gelöscht, separates Arbeitsverzeichnis, PATH leer. Fehlerorte, Anfangswerte, Ausgabe und Dateieffekte identisch. |
+| Explizites Ausgabeformat und Ziel / Vorlage passt nicht | `crates/tb-cli/src/main.rs:140`: Standard bleibt TBC; explizite EXE-/Target-/Vorlagen-/Ausgabe-/Force-Optionen. `native_build_optionen_sind_explizit_und_tbc_bleibt_standard` sowie Exporttests prüfen unbekannte/doppelte/fehlende Optionen, fremde Systeme/Architekturen, Runtime-/Paket-/TBC-Version, Integrität und fehlende Vorlage. |
+| Gemeinsame Laufzeitsemantik / Neustart aus dem Executable | `crates/tb-runner/src/lib.rs:10` und `:72` werden von CLI und tbrt benutzt. Native Probe verändert Variable/Datei und führt RUN aus: frische VM, Datei bleibt, COMMAND$ bleibt. Externes TBC-RUN, STOP, Runtimefehler, LPRINT, Eingaben, Forms und Terminalabbruch bestehen ebenfalls. |
+| Validiertes und sicher veröffentlichtes Artefakt / Beschädigte Nutzlast | `crates/tb-export/src/lib.rs:179`: Container-/Runtime-/TBC-/Targetprüfung, geprüfte Offset-/Längenarithmetik, Prüfsumme und TBC-Validierung. Native Gegenproben für maximale u64-Länge, falsche Version und abgeschnittene Nutzlast enden mit Exit 1/Ladefehler ohne Programmausgabe. |
+| Validiertes und sicher veröffentlichtes Artefakt / Finalisierung schlägt fehl | `crates/tb-export/src/lib.rs:346`: temporäres Geschwisterziel, Schutzpfade, Abbruch, Zielvergleich und atomare Veröffentlichung. `fehlgeschlagene_native_finalisierung_erhaelt_das_ziel` lässt die tatsächliche native Finalisierung scheitern und prüft Original/Bereinigung. Weitere Gegenproben decken Schreibfehler, Konflikt, nachträglich belegtes Ziel und Abbruch ab. |
+
+## Behobene Befunde aus der Umsetzung und Verifizierung
+
+1. **Indirekter Quellcompiler in tbrt.** Designentscheidung 1 fordert einen
+   Runner ohne BASIC-Quellcompiler. Die erste Symbolprüfung fand den Parser
+   über den Watch-/Debugger-Pfad der gemeinsamen VM. `DebugCompiler` bindet
+   den Compiler nun erst bei seiner ausdrücklichen Erzeugung über einen
+   Funktionszeiger (`crates/tb-vm/src/project.rs`). Die VM-API und
+   Debuggerfunktion bleiben erhalten. Erneute Release-Symbolprüfung mit
+   `nm` findet keine Parser-, SourceLoader-, Projektcompiler- oder
+   Debug-Compiler-Implementierungssymbole; IDE-/VM-Debuggertests bestehen.
+2. **Abbruch während CLI-Export.** Ein nur für Bibliotheksaufrufer vorhandener
+   Abbruchcallback genügte nicht für CLI-Signale. `export_cancel.rs` führt
+   Unix-SIGINT/SIGTERM beziehungsweise Windows-Ctrl+C/Break in diesen
+   Callback. Die native Prozessprobe unterbricht zwei laufende Exporte
+   nach Anlage der temporären Datei: Exit 1, Original unverändert, keine
+   temporäre Ausgabe. Laufzeit-Ctrl+C bleibt beim bestehenden Terminalhost.
+3. **Native Formatgrenzen.** Gegenproben schärften abgeschnittene Header und
+   fremde ELF-System-ABIs. Kurze Header und andere ABIs als System V/Linux
+   werden abgewiesen. PE übernimmt keine veraltete optionale Prüfsumme;
+   vorhandene Authenticode-Signaturen führen zu einer konkreten Ablehnung.
+   Vier Target-Zuordnungen und beschädigte Header/Nutzlasten sind geprüft.
+4. **Mach-O-Ende nach Signierung.** Eine reine Dateiende-Annahme wäre nach
+   codesign falsch. Die Implementierung entfernt die vorherige Signatur,
+   erweitert `__LINKEDIT`, signiert nach dem Einbetten und liest vor der
+   Veröffentlichung die fertige Datei erneut. Der Lader benutzt die durch
+   `LC_CODE_SIGNATURE` bezeichnete Grenze und geprüftes Nullpadding.
+   Export, `codesign --verify --strict` und native Ausführung bestehen.
+
+Keine bestehenden Golden-Dateien oder Inventarverträge wurden geändert.
+Die CLI-/IDE-Abnahme benutzt weiterhin denselben Ausführungspfad; nur ihre
+Imports wurden nach Herauslösen des Runners ausdrücklich gemacht.
+
+## Ausgeführte Gates
+
+Lokaler Rechner: Apple M5 Max, 128 GiB, macOS 26.6.2 (25G83),
+`aarch64-apple-darwin`, Rust 1.97.1/Cargo 1.97.1. Release-Profil mit LTO
+und codegen-units 1. Vorlagen-/Container-Runtime-ABI 1, TBC-Version 4.
+
+```sh
+cargo build --locked --release -p tb-cli -p tb-runner -p tb-export
+python3 tests/support/native-abnahme.py --target aarch64-apple-darwin
+python3 tests/support/release-abnahme.py --vbdos-repo /tmp/terminalbasic-vbdos-evidence
+cargo check --locked --target aarch64-unknown-linux-gnu -p tb-cli -p tb-runner -p tb-export
+openspec validate --all --strict
+git diff --check
+```
+
+| Gate | Ergebnis |
+| --- | --- |
+| Native CLI-/EXE-Probe | 7 Vergleichsfälle bestanden: Konsole/COMMAND$/INPUT/LPRINT, RUN-Neustart, STOP, Laufzeitfehler/Export aus TBC, Projekt-/Include-/Dateifehler, Forms-/Mehrmodul-/Include-Projekt und externes TBC-RUN |
+| Terminal | 4 Unix-PTY-Läufe: CLI und EXE jeweils Eingabe bzw. Ctrl+C; korrekte Exitcodes und Terminalattribute wiederhergestellt |
+| Veröffentlichung | Überschreibverweigerung und ausdrückliches Ersetzen; echte SIGINT-/SIGTERM-Abbrüche erhalten das Original und entfernen temporäre Dateien |
+| Ladefehler | 3 beschädigte native Nutzlasten ohne Projektcode-Ausführung abgewiesen; zusätzliche Versions-/Grenz-/Prüfsummen-Gegenproben in Rust |
+| macOS-Signierung | Alle finalisierten Vergleichsprogramme strikt geprüft und nativ gestartet |
+| Workspace | 613 Tests plus 1 Offline-Kindprozesstest bestanden, 0 fehlgeschlagen; 2 beabsichtigte Ignores |
+| Öffentlicher Pflichtnachweis | Separat 3 Tests bestanden, darin 7 Einstiege × 2 Läufe von cout/vbdos bei `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6` |
+| Inventar | 845 Einträge: 795 implementiert, 0 offen, 50 deklarierte Non-Features; keine Umklassifizierung |
+| Clippy / Format | Workspace/all-targets mit `-D warnings` und Formatprüfung bestanden |
+| OpenSpec | 30 Specs/Changes strikt bestanden, 0 fehlgeschlagen; bestehende INFO-Textlängenhinweise |
+| Linux arm64 | Cargo-Cross-Check bestanden; kein nativer Ausführungsnachweis |
+| Vorlagen-Builder | `build-runtime.py --target aarch64-apple-darwin --output /tmp/tb-phase6-02-evidence/templates/aarch64-apple-darwin` erfolgreich, native Header/Architektur und Metadaten geprüft |
+
+Die native Probe setzt PATH bereits beim Export leer; codesign wird über
+seinen absoluten Systempfad aufgerufen. Die ausgeführten Programme benötigen
+somit keine auflösbaren Compiler-/Linkerwerkzeuge. Das ist ein isolierter
+lokaler Prozessnachweis, keine Behauptung eines frisch installierten
+Betriebssystems. Die externe RUN-Probe enthält bewusst ihr zusätzliches
+TBC-Laufzeitmodul; die übrigen Programme benötigen keine separate TBC-Datei.
+
+Beschädigte Mach-O-Proben werden nach der absichtlichen Mutation neu
+signiert, damit der Nutzlastlader geprüft wird. Eine ungültige native
+Signatur kann bereits vom Betriebssystem vor main abgewiesen werden.
+Die lokale Ad-hoc-Signatur beweist Ausführbarkeit, keine Notarisierung.
+
+Das finale macOS-tbrt ist 3.022.416 Bytes groß. `otool -L` weist ausschließlich
+`/usr/lib/libiconv.2.dylib` und `/usr/lib/libSystem.B.dylib` als dynamische
+Abhängigkeiten aus; keine separate Terminal-Basic-Runtime und keine IDE.
+
+## Leistungsregression der gemeinsamen VM
+
+Die unveränderten Benchmarks aus Change 01 wurden im vollständigen
+Abnahmelauf erneut ausgeführt. Modul: 1,20 ms bei Budget < 50 ms; Projekt
+mit 49.760 Zeilen: 100 ms bei Budget < 1.000 ms. Inkrementelle Mediane:
+0,72 ms und 20,62 ms. VM: INTEGER 1.193 ms, DOUBLE 556 ms, SUB 138 ms,
+Strings 110 ms. Gegenüber der dokumentierten Basis 1.217/572/139/109 ms
+kein relevanter Leistungsrückschritt; keine Performance-Optimierung.
+
+## Übergabe und bewusst spätere Zielnachweise
+
+[Native Executables](../../../../docs/native-executables.md) dokumentiert
+CLI-Optionen, Vorlagenherstellung für alle vier vereinbarten Triples,
+Metadaten/Container, öffentliche Export-API und Systemvoraussetzungen.
+`tbrt` lädt externe RUN-Ziele als vorkompilierte TBC; Quellen benötigen die
+vorherige Übersetzung durch tbc. RUN-/OPEN-/ISAM-/SHELL-Ressourcen werden
+nicht automatisch eingebettet. Diese Grenze folgt dem geplanten Runner
+ohne BASIC-Quellcompiler und ist ausdrücklich sichtbar.
+
+Die tatsächliche Windows-amd64- und Linux-amd64/arm64-Ausführung,
+Windows-Terminal-/Abbruchprüfung, konkrete glibc-Builderbasis sowie vier
+Gitea-Releasepakete bleiben gemäß Design bei Changes 05/06. Change 02 liefert
+Bauaufrufe, Header-/Architekturprüfung und lokalen macOS-Nativnachweis.
+TBL/Linker und IDE-Anbindung verwenden denselben Exportvertrag in 03/04.
+
+Lokale Rohprotokolle: `/tmp/tb-phase6-02-evidence/`, insbesondere
+`native.log`, `release-abnahme.log`, `export-tests.log`,
+`linux-arm64-check.log` und `template-build.log`. Alle wesentlichen
+Resultate und reproduzierbaren Aufrufe stehen zusätzlich in diesem Bericht.
+Am 2026-09-07 wurden die vier Requirements in die Hauptspezifikation
+`native-executables` synchronisiert, alle 25 Hauptspezifikationen strikt
+validiert und Change 02 archiviert.