27 lines
3.0 KiB
Markdown
27 lines
3.0 KiB
Markdown
## 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.
|