Phase 6: Kompatibilitaetsabnahme abschliessen und archivieren

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

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

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

@@ -0,0 +1,87 @@
+# Release-Grundabnahme: Fälle und Voraussetzungen
+
+Basis: `54ee427c1c676170450068c5436e5875c84c9dce`, lokale Änderungen dieses
+Changes. Alle folgenden Tests sind headless. Keine DOS-/GUI-Emulatoren.
+
+## Ausführbare Aufrufe
+
+Vom Repository aus; `--locked` bewahrt die Abhängigkeitsrevisionen:
+
+```sh
+# K: gesamter Korpus einschließlich Vergleichs-Gegenproben
+cargo test --locked -p tb-cli --test compat
+# P: Projekte, Includes, TBC, Diagnosen und Dateieffekte
+cargo test --locked -p tb-cli --test project
+# I: Inventar, Sollquellen, Absenkungsziele und Statusgruppen
+cargo test --locked -p tb-cli --test inventar -- --nocapture
+# E: tatsächliche Ereignisauslöser bis BASIC
+cargo test --locked -p tb-vm --test events
+# A: IDE-Projektablauf, CLI-/TBC-Parität und Befehlsmatrix
+cargo test --locked -p tb-cli --bin tbc ide_acceptance::
+# F: Pflichtnachweis des fixierten öffentlichen Bestands
+TB_VBDOS_REPO=/absoluter/pfad/zu/vbdos cargo test --locked -p tb-cli --test foreign -- --include-ignored --nocapture
+# G: zusammenhängende Grundabnahme, zuerst F, dann Workspace/Inventar/Gates/Benchmarks
+python3 tests/support/release-abnahme.py --vbdos-repo /absoluter/pfad/zu/vbdos
+```
+
+Unter Windows wird TB_VBDOS_REPO als Prozessumgebungsvariable gesetzt;
+G übernimmt dies plattformunabhängig. Alle Aufrufe liefern bei Fehler einen
+von null verschiedenen Exitcode. Die reale Windows-/Linux-Prüfung folgt in
+05/06, diese Matrix behauptet nur die ausgeführten lokalen Nachweise.
+
+## Verhaltensgruppen und unabhängiges Soll
+
+| Gruppe | Fälle | Aufruf | Soll und festgelegter Anfangszustand |
+| --- | --- | --- | --- |
+| Konsole/Zahlen/Steuerung | `hello`, `printzahlen`, `konvertierung`, `byref`, `kontrollfluss` | K: `korpus_laeuft_mit_korrekter_ausgabe` | Jeweilige `.out`, explizite tb-screen-Größe, keine Eingaben, Hostuhr 0; bestehende Sprach-/VM-Specs |
+| Unicode/Attribute/Größe | `breitezeichen`, `bildschirm`, `groesse`, `groessenaenderung`, `release-formular` | K | COLOR/LOCATE-/Unicodevertrag; 80×25 bzw. 120×40, deklarierte Resize-Schritte; für release-formular 100×30 und Zeichen ab Spalte 90 |
+| Forms/Fokus/Maus/Menü | `formular`, `formular-access-backtab`, `eingabe-maus-taste`, `eingabe-taste-maus`, `release-formular` | K | Geordnete Kopfereignisse; LostFocus vor GotFocus, genau ein Click, Menüauswahl; separate Zeichen-/Farberwartungen und zwei Läufe |
+| Listen/Timer/modal | `listenauswahl`, `timer-aktivierung`, `formular` | K | Deklarierte Tasten/Maus/Zeit; bestehende `.out` mit Listenauswahl, Timertext und Dialogresultat |
+| Zeit/Traps | `traps`, `trap-masken`, `datumzeit`, `timezoneknown`, `timezonefallback` | K, E | Virtuelle Uhr oder ausdrücklich gesetzte Zeit/Zone; KEY/UEVENT/TIMER-Masken und Reihenfolge. Zeitlose Invarianten bleiben als solche benannt |
+| Dateien/ISAM | `dateien`, `eingabefortschritt`, alle `isam*.bas` | K | Frisches leeres Tempverzeichnis, deklarierte Bildschirmgröße, feste Dateiinhalte aus dem BASIC-Programm; `.out` prüft Lese-/Record-/Transaktionsresultate |
+| Projekt-/Include-/Dateikette | `release_projekt_prueft_anfangsdateien_dateieffekte_und_include_fehler` | P | Zwei Module, verschachtelte Includes; seed.txt=`Grüße\n`, result.txt=`Start\n`; Ergebnis exakt `Start\nGrüße\n`, Quelle unverändert, Exit 2 und inner.bi Zeile 8 Spalte 5; Quell-/TBC-Lauf jeweils zweimal, Library-Quellen vor TBC-Lauf entfernt |
+| Fehler/physische Orte | `fehlerbehandlung`; `cli_meldet_physische_quellorte_auch_nach_verschachtelten_includes`; `tbc_run_stop_exitcode`, `tbc_run_laufzeitfehler_exitcode` | K, P | ERR/ERL getrennt von Dateizeile; STOP=3, Runtimefehler=2; Sollstellen im jeweiligen Test, keine Systemzeitabhängigkeit |
+| Quellfreie Projekte und Startdatei | `projekt_und_formular_laufen_nach_entfernen_saemtlicher_quellen`, `explicit_startup_order_and_form_selection_survive_tbc` | P | Festes Projekt/Form/Include, danach Quellen entfernt; identische Ausgabe und richtige Startformularwahl aus TBC |
+| Vollständiges Inventar | `inventar_stimmt_mit_code_ueberein`, `jeder_inventareintrag_erreicht_hir_und_laufzeitziel`, `forms_inventar_stimmt_mit_der_klassentabelle_ueberein`, `abdeckungsstand_wird_ausgewiesen` | I | docs/inventar plus feste Inventar-Quellliste und unabhängige Absenkungsziele; Gegenproben für falsche Status-/Builtin-/Forms-Bindung |
+| Ereignisvollständigkeit | `registrierte_form_ereignisse_erreichen_basic_aus_realen_quellen`, `registrierte_control_ereignisse_erreichen_basic_aus_realen_quellen`, `fehlender_ereignispfad_wird_namentlich_erkannt` | E | Jede registrierte Quelle löst ihren BASIC-Handler aus; künstlich fehlender Auslöser wird benannt |
+| IDE/CLI/TBC | `create_save_debug_help_exports_and_reopen`, `saved_project_ide_source_cli_and_tbc_have_identical_sessions`, `reference_matrix_is_complete_and_points_to_runnable_tests` | A | Feste Tastensequenzen, Hostzeiten, Anfangsdateien und konkrete Ausgabe/Dateieffekte; bestehende 45-zeilige Phase-5-Befehlsmatrix. Native Exporterzeugung ist hier noch nicht implementiert |
+| Dialog-EOF | `eof_im_dialog_eines_formularhandlers_beendet_die_ereignispumpe`, `eof_leert_angenommene_eingaben_bei_modalen_und_modellosen_forms` | E | EOF in einem Dialog beendet die Pumpe; bereits angenommene normale Formularereignisse bleiben vor EOF zustellbar |
+| Vergleichsqualität | `release_formular_vergleicht_zeichen_und_attribute_unabhaengig`, `farbabweichung_nennt_zeile_spalte_soll_und_ist`, `fehlende_groessenangabe_wird_abgewiesen` | K | Vorab geschriebene Sollausgabe; gezielte Text-/Farbmutation, verkürzte Attributzeile und CJK-Spaltenposition müssen konkrete Diagnosen liefern |
+
+Jede Korpus-Sollausgabe muss bereits existieren. Der Harness erzeugt bei
+fehlendem Soll keine Ersatzdatei. Neue Ausgabe `release-formular.out` wurde
+aus Handlerfolge und COLOR/LOCATE-Vorgaben geschrieben, nicht vom Istwert
+übernommen. Bestehende Golden-Dateien bleiben unverändert.
+
+## Öffentlicher Bestand
+
+`cout/vbdos`, Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`.
+Lokaler Prüfbestand: `/tmp/terminalbasic-vbdos-evidence`; die Bereitstellung
+ist extern und wird nicht einvendort. `git archive` liefert für jeden Lauf
+frische Dateien exakt dieser Revision. Größe 100×30, virtuelle Hostuhr 0,
+keine echten Wartezeiten; je Einstieg zwei Läufe mit gleichen Eingaben.
+
+| Einstieg | Eingabe | Erwartete sichtbare Wirkung |
+| --- | --- | --- |
+| `graphics/graphics.mak` | Alt+X | Startformular sichtbar, danach entladen |
+| `microsoft/check.mak` | Alt+F, X, N im Save-Dialog | Menü und Save-Dialog nachgewiesen, N konsumiert, Exit entlädt Formular |
+| `microsoft/qlbview.mak` | Esc | Cancel entlädt Startformular |
+| `microsoft/seek.mak` | Alt+X | Exit entlädt Startformular |
+| `microsoft/spindemo.mak` | Tab, Tab, Pfeil hoch | Text1 wird ` 1`, sichtbarer Snapshot ändert sich |
+| `microsoft/notepad.frm` | Alt+F, X, N im Save-Dialog | Menü und Save-Dialog nachgewiesen, N konsumiert, Formular entladen |
+| `misc/mentors/mentors.frm` | Alt+F, X, N im Save-Dialog | Menü und Save-Dialog nachgewiesen, N konsumiert, Exit entlädt Formular |
+
+Snapshots/Zustände müssen zwischen beiden Läufen identisch sein; die
+obigen konkreten Wirkungen werden zusätzlich geprüft. Ein bloßer Vergleich
+zweier gleich falscher Starts genügt nicht. Fehlendes TB_VBDOS_REPO, ein
+unlesbares Repository und eine falsche HEAD-Revision scheitern mit Sollrevision
+und konkreter Ursache. Temporäre Dateien werden bei Erfolg und beim Entrollen
+von Assertions aufgeräumt.
+
+## Übergabe an 02–07
+
+G ist der wiederverwendbare lokale Abnahmeaufruf für spätere Actions; F
+bleibt zwingend. 02–04 ergänzen EXE-/TBL-/IDE-Link-Parität mit diesem Sollsatz,
+05 echte Terminalziele, 06 Zielpakete und Gitea-Läufe. Die finale Inventar-
+und Leistungsprüfung nach deren Fachänderungen gehört in 07. Dieser Change
+baut keine nativen Exportartefakte und nimmt keine fremden Plattformen ab.

openspec/changes/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-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/archive/2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/tasks.md

@@ -0,0 +1,17 @@
+## 1. Kompatibilitätsnachweise
+
+- [x] 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.
+- [x] 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.
+- [x] 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.
+- [x] 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
+
+- [x] 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.
+- [x] 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.
+- [x] 2.3 Nur bei nachgewiesenem Engpass eine gezielte Fachkorrektur umsetzen und denselben Semantik-/Leistungsnachweis wiederholen; andernfalls „kein Optimierungsbedarf“ mit Messbegründung dokumentieren.
+
+## 3. Übergabe
+
+- [x] 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.
+- [x] 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/archive/2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/verification.md

@@ -0,0 +1,183 @@
+# Verifizierung: phase-6-01-kompatibilitaet-und-leistungsabnahme
+
+Stand: 2026-09-07. Geprüft wurden Proposal, Design, Tasks, Delta-Spec und
+Implementierung im Arbeitsbaum auf Basis von
+`54ee427c1c676170450068c5436e5875c84c9dce`.
+
+## Ergebnis
+
+| Dimension | Ergebnis |
+| --- | --- |
+| Vollständigkeit | 9/9 Aufgaben umgesetzt; 4/4 Requirements nachgewiesen |
+| Korrektheit | 4/4 Szenarien geprüft; alle gefundenen Abweichungen behoben |
+| Kohärenz | Bestehende Harnesses, Inventare und Benchmarks weiterverwendet; keine neue Abhängigkeit |
+| Offene Befunde | 0 CRITICAL, 0 WARNING, 0 SUGGESTION |
+
+Alle Prüfungen dieses Changes bestanden. Keine Prüfdimension übersprungen.
+Die [Abnahmematrix](abnahmematrix.md) enthält konkrete Fallnamen, Eingaben,
+Sollzustände, Aufrufe und Voraussetzungen für die weitere Phase 6.
+
+## Requirements und Szenarien
+
+| Requirement / Szenario | Implementierung und Nachweis |
+| --- | --- |
+| Deterministischer Abnahmesatz / Wiederholter Formularlauf | `tests/compat/release-formular.frm` verbindet Fokus, Maus, Menü und Resize mit Unicode und Farbe. `crates/tb-cli/tests/compat.rs`: `release_formular_vergleicht_zeichen_und_attribute_unabhaengig` prüft zwei Läufe und absichtlich falsche Text-/Farberwartungen. Das Soll wurde aus Handlerfolge, COLOR und LOCATE geschrieben. Der bestehende Korpus prüft fehlende Sollwerte als Fehler. |
+| Deterministischer Abnahmesatz: Projekte, Includes, Fehler, Dateien | `crates/tb-cli/tests/project.rs`: `release_projekt_prueft_anfangsdateien_dateieffekte_und_include_fehler` prüft zwei Quell- und zwei quellfreie TBC-Läufe, Anfangsdateien, exakte Ergebnisbytes, Exitcode 2, physischen Include-Ort 8:5 und Aufräumen. Die Matrix ordnet die übrigen bestehenden Verhaltensgruppen zu. |
+| Expliziter Fremdprogrammnachweis / Referenzbestand fehlt | `crates/tb-cli/tests/foreign.rs`: `pruefe_bestand` erzwingt Revision und lesbares Repository; Gegenprobe prüft fehlende Variable, ungültigen Pfad und falsche Revision. `tests/support/release-abnahme.py` aktiviert den Fremdtest ausdrücklich vor allen weiteren Gates. Der vollständige Lauf mit sieben Einstiegen, jeweils zweimal, bestand. |
+| Begründete Leistungsentscheidung / Kein Optimierungsbedarf | Unveränderte Compile-/VM-Benchmarks auf identischer Hardware vor und nach der Änderung; Messwerte und Einordnung unten. Compile-Budgets bestanden. Keine Performance-Optimierung durchgeführt; die einzige VM-Änderung behebt einen funktionalen Dialog-EOF-Fehler. |
+| Nachvollziehbare Befundbehandlung / Snapshot weicht ab | Vergleichs-Gegenproben nennen erste Text-/Farbabweichung mit Soll/Ist. Befunde und Korrekturen unten; vorhandene Golden-Dateien und Inventare unverändert. Regressionstests und vollständige erneute Abnahme bestanden. |
+
+## Behobene Befunde
+
+### 1. Fehlerhafte Attributdiagnose im Korpusvergleich
+
+Sollquelle: `kompat-testkorpus`, Requirement zum Sollvergleich mit erster
+Abweichung; `textbildschirm`, Unicode-/Attributdarstellung. Zuständig:
+`crates/tb-cli/tests/compat.rs`, `assert_output_matches`.
+
+Ist: Eine verkürzte Attributzeile mit gleichem Präfix führte zu Spalte 0 und
+anschließendem Integer-Unterlauf. Nach einem breiten Unicode-Zeichen wurde
+die logische Zeichenposition als Bildschirmspalte gemeldet.
+
+Korrektur: Der Vergleich berechnet zunächst den Attributindex, auch bei
+unterschiedlicher Länge, und daraus die physische Spalte mit der bereits
+verfügbaren Textbreitenfunktion. Die Regression prüft verkürzte Attribute
+und `中a`: Eine Farbabweichung bei `a` muss Spalte 3 nennen. Die separate
+Formularprobe weist sowohl falsche Zeichen als auch ausschließlich falsche
+Farben zurück. Bestehende Sollausgaben wurden nicht angepasst.
+
+### 2. Unvollständige Dialogeingaben im öffentlichen Pflichtnachweis
+
+Sollquelle: `release-kompatibilitaet`, explizite Eingabefolge und sichtbares
+Resultat des fixierten Bestands. Zuständig: `crates/tb-cli/tests/foreign.rs`.
+
+Ist: Der ausdrücklich aktivierte Lauf erreichte bei `check.mak` den
+Save-Dialog ohne Antwort und überschritt seine Prozessfrist. Auch Mentors
+benötigt eine Save-Antwort. Der Testhost lieferte vorbereitete Antworten
+bisher nur bei blockierenden Hostaufrufen; kooperatives Polling verwendet
+nichtblockierende Aufrufe.
+
+Korrektur: Die Eingabefolge für Check und Mentors enthält ausdrücklich N.
+Der Host liefert die Antwort erst nach Darstellung des erwarteten Dialogs;
+für Check/Mentors `Save these records?`, für Notepad `Save changes to`.
+Dialoganzeige, Verbrauch der Antwort, sichtbare Menüwirkung und Entladen
+werden weiter geprüft. Alle sieben bisherigen Einstiege bleiben erhalten;
+beide Läufe jedes Einstiegs stimmen überein.
+
+### 3. Dialog-EOF wurde in der Formularpumpe verschluckt
+
+Sollquelle: `release-kompatibilitaet`, nachvollziehbare Fachkorrektur;
+bestehender kooperativer Ausführungs-/EOF-Vertrag der VM-Ereignispumpe.
+Zuständig: `crates/tb-vm/src/interp.rs`, `poll_visible_forms`.
+
+Ist: EOF während eines MSGBOX in einem modellosen Formularhandler ließ
+`poll` enden. Die Formularpumpe wandelte dies wie ein normales Modulende
+in Yield um und konnte endlos weiterlaufen. Dies wurde unabhängig vom
+Fremdhost mit einem begrenzten Regressionstest reproduziert.
+
+Korrektur: Die gemeinsame Formularpumpe gibt bei aktivem Dialog und EOF
+Ended zurück. CLI und IDE benutzen diesen Pfad. Der neue Test
+`eof_im_dialog_eines_formularhandlers_beendet_die_ereignispumpe` scheiterte
+vor der Korrektur mit „Dialog-EOF wurde als Yield verschluckt“ und besteht
+danach. Er prüft auch, dass nach dem Dialog kein BASIC-Code ausgeführt wird.
+Der bestehende Test für bereits angenommene Eingaben vor EOF bleibt grün;
+33 Ereignis- und 7 kooperative Tests bestanden zusammen.
+
+## Ausgeführte Gates
+
+Gesamtabnahme:
+
+```sh
+python3 tests/support/release-abnahme.py --vbdos-repo /tmp/terminalbasic-vbdos-evidence
+openspec validate --all --strict
+git diff --check
+```
+
+| Prüfung | Ergebnis |
+| --- | --- |
+| Expliziter Fremdtest mit `--include-ignored` | 3 Tests bestanden, darin 7 Einstiege × 2 Läufe; Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6` |
+| `cargo test --locked --workspace` | 609 Tests sowie 1 Offline-Kindprozesstest bestanden; 0 fehlgeschlagen |
+| Absichtlich ignorierte Entwicklertests | 2: Golden-Erzeugung und optionaler Fremdtest; Fremdtest separat verpflichtend bestanden, Golden-Erzeugung nicht ausgeführt |
+| Korpus | 38 BAS + 7 FRM, 46 größenbezogene Sollausgaben, jeder Fall zweimal; zusätzliche Vergleichs-Gegenproben |
+| Inventarbericht | 845 Einträge, siehe getrennte Statusgruppen unten |
+| `cargo fmt --all -- --check` | Bestanden |
+| `cargo clippy --locked --workspace --all-targets -- -D warnings` | Bestanden |
+| Compile-/VM-Benchmarks | Bestanden, beide Compile-Budgets eingehalten |
+| OpenSpec, alle Specs und Changes, strikt | 30 bestanden, 0 fehlgeschlagen; vorhandene INFO-Hinweise zu Textlängen sind keine Validierungsfehler |
+| `git diff --check` | Bestanden |
+
+Zusätzliche Gegenproben des tatsächlichen Release-Aufrufs: Ohne
+`--vbdos-repo` Exit 2 mit Benennung des Pflichtarguments; mit falschem
+Repository Exit 101 und „falsche Revision“; mit nicht vorhandenem Pfad
+Exit 101 und fehlendem/ungültigem Git-Bestand. Letzterer Aufruf erfolgte
+außerhalb des Checkouts über den absoluten Skriptpfad. Kein Fehlfall wurde
+als erfolgreicher Release-Nachweis gewertet.
+
+## Inventar
+
+| Gruppe | Implementiert | Offen | Non-Feature | Gesamt |
+| --- | ---: | ---: | ---: | ---: |
+| Sprache | 241 | 0 | 50 | 291 |
+| Forms-Objektmodell | 554 | 0 | 0 | 554 |
+| Gesamt | 795 | 0 | 50 | 845 |
+
+Offene Einträge: keine. Quelllisten, unabhängige Absenkungsziele,
+Forms-Klassentabelle und tatsächliche BASIC-Ereignisauslöser wurden geprüft.
+Es wurden keine Inventareinträge entfernt oder als Non-Feature umklassifiziert.
+
+## Leistung und Entscheidung
+
+Hardware: Apple M5 Max, 128 GiB RAM, macOS 26.6.2 (25G83),
+`aarch64-apple-darwin`. Rust 1.97.1 (`8bab26f4f`), Cargo 1.97.1,
+LLVM 22.1.6. Alle Messungen auf demselben Rechner mit
+`cargo bench --locked -p tb-vm --bench compile --bench vm`, optimiertem
+Bench-/Release-Profil, opt-level 3, LTO und codegen-units 1.
+
+Vergleich: sauberer Basiscommit `54ee427c1c676170450068c5436e5875c84c9dce`
+vor Änderungen. Endstand: dieser Arbeitsbaum einschließlich Dialog-EOF-Fix.
+Die erste Endmessung folgte dem vollständigen Abnahmelauf und Rebuild;
+eine zusätzliche Messung ohne Rebuild klärte die beobachtete Streuung.
+
+| Last | Basis | Endstand, erster Lauf | Endstand, Bestätigung |
+| --- | ---: | ---: | ---: |
+| Modul, 508 Zeilen, Budget < 50 ms | 0,73 ms | 1,26 ms | 0,80 ms |
+| Projekt, 49.760 Zeilen / 20 Module, Budget < 1.000 ms | 93 ms | 107 ms | 91 ms |
+| Inkrementell, 1 Modul | 0,77 ms | 0,79 ms | 0,73 ms |
+| Inkrementell, 20 Module | 22,46 ms | 22,38 ms | 21,19 ms |
+| INTEGER, 10 Mio. Iterationen | 1.217 ms | 1.251 ms | 1.184 ms |
+| DOUBLE, 5 Mio. Iterationen | 572 ms | 621 ms | 557 ms |
+| SUB/BYREF, 1 Mio. Aufrufe | 139 ms | 141 ms | 140 ms |
+| Stringfunktionen, 200.000 Runden | 109 ms | 118 ms | 110 ms |
+
+Verfahren unverändert: Modul als bester von zehn Läufen nach Aufwärmen;
+Projekt als vollständige Übersetzung mit 335.421 Instruktionen;
+inkrementell Median aus sieben Änderungen einschließlich Invalidierung
+und Link, beim Projekt ein Modul neu und 19 wiederverwendet. VM-Zeiten
+messen Ausführung ohne Compilation. Bestätigter VM-Durchsatz: 8,4 Mio.
+INTEGER- und 9,0 Mio. DOUBLE-Iterationen/s, 7,1 Mio. Aufrufe/s sowie
+1,8 Mio. Stringrunden/s.
+
+Entscheidung: **Kein Optimierungsbedarf im gemessenen Abnahmesatz.** Beide
+Compile-Budgets bestehen mit deutlichem Abstand. Die anfänglichen
+VM-Abstände von ungefähr 1–9 % bestätigten sich nicht: Schleifen waren
+anschließend schneller als die Basis, Aufruf-/Stringzeiten lagen jeweils
+nur 1 ms darüber. Das belegt keinen belastbaren Engpass. Es wurde kein
+neues VM-Zeitlimit eingeführt und kein VM-Code zur Optimierung verändert.
+Der funktionale EOF-Fix wurde mit denselben Semantik- und Leistungstests
+abgenommen. Die Messung behauptet keine statistisch exakte Performanceparität.
+
+## Übergabe
+
+Der Abnahmeaufruf benötigt Rust/Cargo, Python 3, Git, tar und den extern
+bereitgestellten fixierten Fremdbestand. Er lädt nichts herunter und
+erzeugt keine Golden-Dateien. Fallmatrix und Zahlen stehen im Repository;
+lokale Rohprotokolle liegen ergänzend in `/tmp/tb-phase6-01-evidence/`
+(`baseline-environment.txt`, `baseline-bench.log`, `release-abnahme.log`,
+`bench-confirmation.log`, `dialog-eof-before.log`, `vm-regression.log`).
+
+Changes 02–07 übernehmen diese Grundlage für tbrt, TBL/Linker, IDE-Export,
+reale Zielplattformen, Gitea Actions und finale Abnahme. Windows/Linux,
+native Exportartefakte und Release-Pakete sind hier nicht als abgenommen
+ausgewiesen. Am 2026-09-07 wurden die vier Requirements in die Hauptspezifikation
+`release-kompatibilitaet` synchronisiert, alle 24 Hauptspezifikationen strikt
+validiert und der Change archiviert.