Phase 6: Kompatibilitaetsabnahme abschliessen und archivieren

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/tasks.md

@@ -1,17 +1,17 @@
 ## 1. Kompatibilitätsnachweise
 
-- [ ] 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.
-- [ ] 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.
-- [ ] 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.
-- [ ] 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.
+- [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
 
-- [ ] 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.
-- [ ] 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.
-- [ ] 2.3 Nur bei nachgewiesenem Engpass eine gezielte Fachkorrektur umsetzen und denselben Semantik-/Leistungsnachweis wiederholen; andernfalls „kein Optimierungsbedarf“ mit Messbegründung dokumentieren.
+- [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
 
-- [ ] 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.
-- [ ] 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.
+- [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.

openspec/changes/phase-6-02-native-executables/proposal.md

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

openspec/specs/release-kompatibilitaet/spec.md

@@ -0,0 +1,35 @@
+# release-kompatibilitaet Specification
+
+## Purpose
+
+Sichert die nachvollziehbare Kompatibilitäts- und Leistungsgrundlage für auslieferbare Terminal-Basic-Artefakte auf dem bestehenden Sprachstandard.
+
+## 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