Phase 6: IDE-Exportanbindung abschließen und Change archivieren

openspec/changes/archive/2026-09-07-phase-6-04-ide-exportanbindung/.openspec.yaml

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

openspec/changes/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-phase-6-04-ide-exportanbindung/tasks.md

@@ -0,0 +1,22 @@
+## 1. Auftrag und Backend
+
+- [x] 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.
+- [x] 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.
+- [x] 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.
+
+- [x] 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.
+- [x] 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
+
+- [x] 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.
+- [x] 2.2 Esc/Abbruch und Fehlerbereinigung implementieren; Tests müssen Kindprozessende beziehungsweise verworfenes Spätergebnis, entfernte Staging-Dateien und unveränderte bestehende Ziele nachweisen.
+- [x] 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
+
+- [x] 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.
+- [x] 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.
+- [x] 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.
+
+Verifiziert am 2026-09-07: [Nachweise und Szenarioabgleich](verification.md). Keine offenen Befunde im Change-Umfang.

openspec/changes/archive/2026-09-07-phase-6-04-ide-exportanbindung/verification.md

@@ -0,0 +1,96 @@
+# Verifikation: phase-6-04-ide-exportanbindung
+
+Stand: 2026-09-07. Implementierung auf Basis von `25176947ba992520d6cf451f20097b6380fb9555`.
+Change 03 wurde zuvor synchronisiert, archiviert und mit diesem Commit auf
+`origin/main` bestätigt. Change 04 wurde am 2026-09-07 synchronisiert und archiviert; dieser Bericht
+wird gemeinsam mit der Implementierung committed.
+
+## Ergebnis
+
+| Dimension | Ergebnis |
+|---|---|
+| Vollständigkeit | 11/11 Aufgaben, 7 Requirements und 11 Szenarien abgedeckt |
+| Korrektheit | Keine offenen Befunde nach Korrekturen und erneuten Prüfungen |
+| Kohärenz | Bestehende Dokumentidentitäten, gemeinsamer Projektcompiler/Linker und Exportdienst; nur Bytes und Auftragsdaten im Worker |
+| Zielabnahme | Echte native Ausführung auf macOS arm64 bestanden; vollständige Plattform-/Releaseabnahme bleibt gemäß PLAN in 05/06 |
+
+## Requirement- und Szenarioabgleich
+
+| Requirement / Szenario | Umsetzung und Nachweis |
+|---|---|
+| Reale Erzeugung / ungespeichertes Include | `export.rs::Job::start` übersetzt den aktuellen `Project::sources`-Overlaystand ohne Speichern, übergibt TBC-/TBL-Bytes an den Worker. App-Test `real_library_export_uses_dirty_include_and_mouse_without_runtime_template` und echter CLI-/IDE-Abnahmetest `real_native_ide_exports_and_source_free_cli_library_consumer` prüfen geändertes Include, unveränderte Quelldateien, Dirty-Status und tatsächliches Ergebnis. |
+| Verfügbarkeit und Zielkonsistenz / fehlende Vorlage | Zielkombinationen stammen aus `tb_export::Target::ALL`. EXE-Validierung weist Windows arm64 und macOS amd64 ab; fehlende Vorlagen und fehlgeschlagene Finalisierung erscheinen im bedienbaren Dialog. App-Tests `executable_target_validation_and_missing_template_are_honest` und `finalization_failure_is_reported_and_preserves_existing_output`. |
+| Abbruch und eindeutige Veröffentlichung / Ergebnis nach Projektwechsel | `Job` liefert `PreparedPublication`; `App::tick_export` prüft Dialog, Generation, Projekt-/Include-/TBL-Stand und bisherigen Zielinhalt vor Veröffentlichung im UI-Thread. Drop verwirft Staging, setzt Abbruch und beendet den Worker; codesign wird bei Abbruch beendet. Kontrollierte verzögerte Resultate prüfen Resize während der Arbeit, Esc, Projektwechsel, neueren Auftrag, Bearbeitung und externe Zieländerung. Kein alter Auftrag veröffentlicht. |
+| Bedienung bis unabhängige Nutzung / IDE-Export benutzen | Tastatur- und Mauswege verwenden denselben Submit-Pfad. Echte native Abnahme erzeugt ein Forms-Projekt über den IDE-Hauptablauf, hält im Debugger, exportiert EXE und TBL, entfernt Library-Quellen, verwendet die TBL über den echten `tbc link`-Befehl und in einem zweiten IDE-Projekt. CLI-/IDE-Ergebnisse stimmen überein. Das native Programm startet anschließend mit leerem PATH und zeigt die ungespeicherte Include-Änderung einschließlich Dateieffekt. |
+| Bibliotheken im IDE-Projekt / nach Lauf ersetzen | TBL wird als validierte Binärabhängigkeit mit Dokumentidentität geführt, jedoch ohne Textansicht, Editieren, Text-/Dateispeicherung oder Startup-Auswahl. Loader überspringt TBL-Textoverlays; Start/Check/Debugger verwenden den gemeinsamen Linker. Dokumenttest prüft Add/Remove, Reihenfolge, relative MAK-Referenzen, Save As und erhaltene Librarydatei. `replaced_library_invalidates_pending_export_even_with_same_length` prüft Neuübersetzung und verworfenen Export trotz gleicher Dateigröße. |
+| Bibliotheken im IDE-Projekt / Library ohne native Vorlage | Make Library hat nur Artefaktbeschreibung, `.tbl`-Ausgabepfad und Überschreibentscheidung. Reale quellfreie Verwendung aus dem App-Test funktioniert ohne Runtime-Vorlage. |
+| Vollständige Exportdialoge / ohne Backend | Bestehender App-Oberflächentest und Phase-5-Hauptablauf setzen ausdrücklich `export_backend=false`; Verfügbarkeitsgrund, Angaben, Validierung und unveränderte Dateien werden weiter geprüft. |
+| Vollständige Exportdialoge / fehlerhafte Ausgabeangaben | Leere Pfade, fehlende Zielverzeichnisse, TBC als natives Artefakt, falsche Libraryendung und nicht freigegebene bestehende Ziele werden vor Arbeit abgewiesen. Bestehende App-/CLI-Oberflächentests bleiben erhalten und berücksichtigen die portable Library-Maske. |
+| Vollständige Exportdialoge / kontrollierte Ergebnisdarstellung | Die backendlosen Tests melden Laufend, Erfolg, Fehler und Abbruch mit demselben Auftrag zurück und prüfen Anzeige sowie unveränderte Projektstempel; sie behaupten keine Dateierzeugung. |
+| Vollständige Exportdialoge / verfügbares Backend | Zusätzliche reale Library- und native Abnahmen prüfen tatsächliche Dateien, Status und unabhängige Nutzung. Schließen nach erfolgreicher Veröffentlichung erhält den tatsächlichen Erfolg. |
+| Export-UI als Phasenleistung / ohne Scheinerfolg | Backendlose Phase-5-Abnahme bleibt explizit erhalten; zusätzlich wird die Phase-6-Erzeugung über dieselbe UI nachgewiesen. |
+
+Zusätzlicher Debuggernachweis: `debugger_reports_absent_library_source_and_can_step_back_to_caller`
+prüft den tatsächlichen Halt in quellfreiem Librarycode, die Meldung des fehlenden
+Quelltexts, Prozedurschritt/Fortsetzen und das richtige Ergebnis ohne erfundene
+Dokumente oder erzeugte Quelldateien.
+
+## Behobene Befunde
+
+- Die erste Revisionsprüfung bezog auch externe Änderungen gespeicherter,
+  bereits geöffneter Includes ein. Geöffnete Puffer bleiben jetzt maßgeblich;
+  TBL und nicht geöffnete Dateieingaben werden über ihre tatsächlichen Bytes
+  geprüft. Der bestehende Include-/Editor-Regressionsfall besteht.
+- Späte Ergebnisse dürfen keine Ausgabewirkung vor dem UI-Check haben:
+  gemeinsame Veröffentlichung in Vorbereitung und Freigabe getrennt;
+  zusätzlich wird der Zielinhalt bereits ab Auftragsbeginn geschützt.
+- Ein bereits erfolgreicher Export wurde beim Schließen als abgebrochen
+  gespeichert. Der abgeschlossene Erfolgsstatus bleibt jetzt erhalten.
+- Worker- und Signierprozesslebensdauer sowie Staging-Bereinigung sind an den
+  Auftrag gebunden, auch beim Beenden der IDE.
+- Bibliotheken sind aus Text-/Startup-Auswahl und Quellspeicherung ausgeschlossen;
+  auch das implizite Ausführungsziel wird aus Quellmitgliedern gewählt.
+- Alte Exporthinweise in Bedienung/Tutorial und fehlende eingebettete Hilfeziele
+  wurden korrigiert. Die Hilfe-Endprüfung verwendet den aufgelösten letzten
+  Dokumenteintrag statt einer festen Seitennummer.
+
+## Ausgeführte Prüfungen
+
+| Prüfung | Ergebnis |
+|---|---|
+| `cargo test --locked --workspace` | 633 bestanden, 0 fehlgeschlagen, 3 ausdrücklich ignoriert |
+| Echter nativer IDE-Abnahmetest mit `TB_IDE_RUNTIME_DIR` und `--ignored` | 1 bestanden auf macOS arm64; IDE→EXE→Prozessstart und IDE→TBL→CLI-/IDE-Verbraucher |
+| Zusätzlicher finaler IDE-Ausführungstest nach Quellzielkorrektur | 12 bestanden |
+| Finaler Help-Test nach Dokumentationsabgleich | 11 bestanden; zusätzlich Offline-Kindprozess bestanden |
+| `cargo clippy --locked --workspace --all-targets -- -D warnings` | Bestanden |
+| `cargo fmt --all -- --check`, `git diff --check` | Bestanden |
+| `openspec validate --all --strict` | 30 Elemente bestanden, 0 fehlgeschlagen |
+| Release-Build von IDE/CLI und nativer Runtime/Exportwerkzeug | Bestanden |
+| `native-abnahme.py --target aarch64-apple-darwin` | Echte native Programme, Forms, PTY, Exportabbruch, Signierung und Beschädigungsprüfungen bestanden |
+| `library-abnahme.py` | Identisches gemeinsames TBL-Artefakt, quellfreie TBC-/EXE-Verbraucher und RUN bestanden |
+| `cargo check --locked --target aarch64-unknown-linux-gnu -p tb-ide` | Bestanden; kein Linux-Ausführungsnachweis |
+
+Die regulär ignorierten Fälle sind Golden-Erzeugung, externer Fremdbestand und
+der neue native IDE-Test mit expliziter Runtime-Voraussetzung. Letzterer wurde
+separat tatsächlich ausgeführt. Ein früher Korpuslauf traf im unveränderten
+Zeitfall `timezonefallback.bas` eine Sekundengrenze; der vollständige abschließende
+Workspace-Lauf bestand ohne Anpassung dieses Tests oder seiner Sollwerte.
+
+Native IDE-Abnahme reproduzieren: geprüfte Host-Vorlage samt Metadaten unter
+`<runtime-root>/<target-triple>/tbrt[.exe]` bereitstellen (beispielsweise mit
+`tests/support/build-runtime.py`), `TB_IDE_RUNTIME_DIR=<runtime-root>` setzen und
+`cargo test --locked -p tb-cli --bin tbc ide_acceptance::real_native_ide_exports_and_source_free_cli_library_consumer -- --ignored`
+ausführen. Ohne diese explizite Voraussetzung wird kein nativer Nachweis behauptet.
+
+Rohprotokolle dieser Sitzung: `/tmp/tb04-workspace-final.log`,
+`/tmp/tb04-native-final.log`, `/tmp/tb04-execution-final.log`, `/tmp/tb04-help.log`,
+`/tmp/tb04-clippy-final.log`, `/tmp/tb04-openspec.log`,
+`/tmp/tb04-native-regression.log`, `/tmp/tb04-library-regression.log`,
+`/tmp/tb04-linux-check.log`, `/tmp/tb04-release-final.log`.
+
+## Übergabe
+
+Change 04 wurde nach erfolgreicher Verifikation synchronisiert und archiviert. Change 05 übernimmt
+die reale Terminalmatrix auf allen vier Zielsystemen, Change 06 den zentralen
+Cross-Paketbau und paketgebundene Ausführungsnachweise. Der lokale macOS-Nachweis
+und Linux-Cross-Check ersetzen diese noch ausstehenden Abnahmen nicht.