TerminalBasic/PLAN.md

PLAN — Terminal Basic

Arbeitsplan für die Re-Implementierung des DOS-BASIC-Dialekts (1992) in Rust. Dieses Dokument wird fortgeschrieben: erledigte Punkte werden abgehakt, Entscheidungen mit Datum und Begründung festgehalten.

Konvention: [ ] offen · [x] erledigt · [~] in Arbeit

---

Leitplanken

• Re-Imagination, nicht Emulation (2026-09-01): Ziel ist ein BASIC zum Bauen von Terminal-Tools (CLI und TUI). Stufe 1 ist die getreue Nachbildung von UI/UX, Sprachstandard und Standardbibliothek des Vorbilds — rekonstruiert aus vorhandener Online-Dokumentation (Manuals auf archive.org, Wiki-Referenzen, zeitgenössische Artikel). Stufe 2 (nach Phase 6) reichert die Sprache bewusst um Elemente außerhalb des Vorbilds an; Erweiterungen sind additiv und brechen den Kernstandard nicht.
• Referenzverhalten schlägt Eleganz — innerhalb von Stufe 1. Bei Zweifeln zählt das dokumentierte Verhalten des Vorbilds (inkl. Fehlercodes, Rundung, Formatierung), nicht das, was „richtiger" wäre. Wo das Vorbild aber mit der heutigen Plattform kollidiert (Codepages, DOS-Hardware, Segmente), gewinnt die Plattform; solche Abweichungen werden in der Sprachreferenz dokumentiert. Das gilt auch gegenüber den eigenen Spezifikationen (2026-09-04): Weicht eine Delta-Spec bei Semantik oder Syntax vom Vorbild ab, ohne dass eine Plattformkollision sie dazu zwingt, wird die Spec angeglichen, nicht das Vorbild nachgebildet. Befund aus phase-3-isam, wo drei Festlegungen (Cursorlage nach SETINDEX und nach DELETE, Fehlercode der Suche über den NULL-Index) auf die Original-Hilfe zurückgeführt wurden.
• Vollständigkeit ist das Soll (2026-09-02): Erwartet wird eine 100 % kompatible Sprachimplementierung und volle Standardbibliothek des Vorbilds — abzüglich ausschließlich der in der Sprachreferenz explizit benannten Non-Features. Aufzählungen von Anweisungen/Funktionen in diesem Plan sind Beispiele, keine Scope-Definition. Messbar wird das über ein Vollständigkeits-Inventar (alle Keywords, Anweisungen, Funktionen, Methoden, Eigenschaften, Ereignisse aus der Original-Hilfe) mit Abdeckungsstatus → Aufgabe in Phase 3, Abnahmekriterium in Phase 6. Guiding Principle — die Original-Dokumentation führt (2026-09-02): Alles, was dort dokumentiert ist, wird unterstützt oder durch eine explizite Fehlermeldung abgewiesen. Eine Abweisung setzt voraus, dass das Feature vorher vom Projektinhaber als Non-Feature deklariert und in der Sprachreferenz unter „Abweichungen" gelistet wurde. Stilles Weglassen oder generische Syntaxfehler für dokumentierte Features sind Bugs. Verschobene Elemente brauchen einen eigenen Punkt (2026-09-04): Wird ein Inventareintrag von einer Phase in eine spätere verlegt, MUSS er dort als eigene Aufgabe stehen. Ein Verweis im Fließtext („kommt mit Phase 4") genügt nicht — nur was als Punkt in der Zielphase steht, wird abgearbeitet.
• Markenrecht: Der Name des Vorbilds wird in Code, Doku und Artefakten nicht verwendet. Wir sprechen vom „Vorbild" bzw. „dem Dialekt".
• Performance ist Anforderung, nicht Politur (2026-09-01):
  • Instant-Compile: Der Compiler übersetzt so schnell, dass der Benutzer nie auf einen Build wartet — Start aus der IDE fühlt sich wie beim Vorbild an (Run drücken, Programm läuft). Budget: ein komplettes Projekt kompiliert in Sekunden und liefert ein ausführbares Ergebnis; einzelne Module im Millisekundenbereich.
  • Architektur-Konsequenzen: Single-Pass-Design (Lexer/Parser/Codegen ohne teure globale Analysen), modulweise inkrementelle Übersetzung (nur Geändertes neu), keine Optimierungspasses, die den Turnaround kosten — Schnelligkeit der VM kommt aus dem VM-Design, nicht aus einem Optimizer.
  • Schnelle Ausführung: Die TBVM führt generierten Code zügig aus (Details in docs/tbvm-design.md, Abschnitt „Performance"); Messlatte via Benchmarks ab Phase 2.
  • tbc build --exe erzeugt Executables ohne Compiler-/Linker- Toolchain beim Anwender (vorkompiliertes tbrt mit eingebettetem .tbc) — damit bleibt auch der Weg zum verteilbaren Binary im Sekundenbereich.
• Jede Phase endet mit lauffähigen Tests gegen eine wachsende Kompatibilitäts-Testsuite (Verzeichnis tests/compat).
• Erster Kompatibilitätstest — externes Programmkorpus (2026-09-02): Die Programme des dokumentierten Referenzbestands cout/vbdos (insb. der Ordner microsoft/) müssen — soweit sie keine deklarierten Non-Features (PEEK/POKE/CALL INTERRUPT …) nutzen — erfolgreich kompilieren und nutzbar sein. Das Repo wird nicht einvendort (Lizenzlage), sondern vom Test-Harness bei Bedarf geklont. Aufgaben: Frontend-Check ab Phase 1, Lauffähigkeit Konsole in Phase 3, Forms in Phase 4 (Meilenstein dort); binäre .FRM-Dateien erfordern ein Konvertierungstool → Phase 4.
• Dokumentation ist Teil der Definition of Done (2026-09-02): Im docs/-Ordner entsteht die vollständige Dokumentation der Sprache und der Bibliothek so wie implementiert (Ist-Stand): jede Phase schreibt docs/sprachreferenz.md fort und pflegt eine Bibliotheksreferenz (docs/bibliothek.md, entsteht mit Phase 3) mit jeder implementierten Anweisung/Funktion. Diese Markdown-Dokumente sind zugleich der Inhalt des IDE-Hilfesystems (Phase 5): Anzeige unter „Help" mit Konsolen-Markdown-Rendering, Umbruch dynamisch nach aktueller Fenstergröße.

---

Phase 0 — Exploration und Grundsatzentscheidungen

Status: abgeschlossen (2026-09-01). Detailarbeiten, die hier noch offen waren, sind als Eingangsaufgaben in die Phasen verschoben, die sie konsumieren (Regel: Phasen sind einzeln abschließbar; nichts bleibt in einer geschlossenen Phase zurück).

0.1 Sprach- und Bibliotheksreferenz rekonstruieren

Primärquelle ist vorhandene Online-Dokumentation (archive.org-Manuals, Wiki-Referenzen zur QB/PDS-Familie, zeitgenössische Artikel, Screenshots). Emulator-Sessions nur noch als Rückfallebene für Detailfragen, die die Dokumentation nicht beantwortet.

• Sprachreferenz zusammengetragen und gegen die Original-Hilfe des Vorbilds (dos-help.soulsphere.org, README der Professional Edition) verifiziert → docs/sprachreferenz.md; die drei verbleibenden Detailfragen sind als Aufgaben zugeordnet: SINGLE/DOUBLE-Literalschwelle → Phase 1, PRINT USING-Überlauf und KEY n-Makros → Phase 3
• Forms-/Steuerelemente-Referenz aus Original-Hilfe, CONSTANT.BI und Programm-Stringtabellen rekonstruiert (alle 16 Steuerelemente mit Eigenschaften/Methoden/Ereignissen, Defaults, SCREEN-Objekt, Modalität, Menüsystem) → docs/forms-referenz.md
• Dateiformate dokumentiert → docs/dateiformate.md; die Definition der Text-.FRM-Serialisierung (kein Original-Beispiel auffindbar) ist Eingangsaufgabe von Phase 4
• Laufzeitfehler-Katalog vollständig (1–76, ISAM 80–89, Forms 260–480) als tb_runtime::errors implementiert (inkl. Tests)
• IDE-UX-Referenz: Menüstruktur, Fensterverwaltung, Farbschema, Tastenbelegung, Editor-Verhalten aus Original-Hilfe und Screenshots → docs/ide-referenz.md
• Testkorpus-Grundstock gelegt (tests/compat/ mit dokumentierter Sollausgabe). Der Ausbau ist Daueraufgabe jeder Phase; das Test-Harness (tbc run + Ausgabevergleich) ist Phase-2-Aufgabe

0.2 VM-/Runtime-Entscheidung (Aufstellung der Optionen)

Anforderungen an die Ausführungsschicht: BASIC-Fehlersemantik (ON ERROR GOTO/RESUME mit ERR/ERL), GOSUB/RETURN, unterbrechbare Ausführung (Debugger-Einzelschritt, Strg+Untbr, ereignisgesteuerte Forms-Hauptschleife), dynamische Strings/Arrays mit BASIC-Semantik, serialisierbares Kompilat, gute Fehlerortung (Zeile/Spalte).

Option	Vorteile	Nachteile	Eignung
1. Eigene Bytecode-VM in Rust („TBVM")	Volle Kontrolle über Semantik (Fehlerbehandlung, GOSUB, Events, Suspend/Resume); Bytecode als .tbc serialisierbar; Debugger-Integration trivial (Zeileninfo im Bytecode); keine Fremdabhängigkeit	Eigenaufwand für VM, GC/Refcounting für Strings/Arrays; „nur" Interpreter-Geschwindigkeit	Empfohlen — Interpreter-Tempo genügt für 80×25-Programme bei Weitem
2. Tree-Walking-Interpreter	Schnellster Weg zu ersten laufenden Programmen; ideal zum Validieren der Semantik	Langsam; Debugger/Resume-Semantik unsauber; wäre später Wegwerfcode	Optional als Bootstrap in Phase 1, dann ersetzen
3. WebAssembly-Ziel (wasmtime/wasmer)	Ausgereifte VMs mit JIT (Cranelift); portables, standardisiertes Kompilat; Sandbox; theoretisch Browser-Ausführung	BASIC-Semantik passt schlecht: ON ERROR/RESUME, GOSUB und unterbrechbare Ausführung müssen aufwendig transformiert werden (Relooper/State-Machine); Strings/Arrays komplett selbst verwalten; Debugging über zwei Ebenen; schwere Abhängigkeit	Später als zweites Backend denkbar (gleiche IR), nicht als Start
4. Cranelift direkt (JIT auf nativen Code)	Native Geschwindigkeit; Rust-eigenes Projekt, gut eingebettet	Gleiche Semantik-Transformationsprobleme wie WASM; kein portables Kompilat; JIT auf allen drei Plattformen pflegen	Nur falls Performance je Thema wird — unwahrscheinlich
5. LLVM-AOT (inkwell)	Maximale Performance, echte Executables	Sehr schwere Toolchain-Abhängigkeit (LLVM-Build je Plattform); lange Kompilierzeiten; Debugger/Edit-Run-Zyklus der IDE leidet massiv	Ungeeignet für dieses Projekt
6. Transpilation auf fremde Skript-VM (Lua via mlua/piccolo)	Ausgereifte VM mit GC geschenkt	Semantik-Mismatch (Zahlentypen, Fehler-/Eventmodell, 1-basierte vs. BASIC-Arrays mit OPTION BASE); Fehlerortung und Debugger bilden schlecht ab	Ungeeignet
7. Transpilation nach Rust (AOT)	Native Binaries, keine VM	Kein Interpretermodus → IDE-Kernfeatures (Direktfenster, Start ohne Build-Wartezeit, Debugger) praktisch unmöglich; Rust-Toolchain als Laufzeitvoraussetzung	Ungeeignet als Primärziel

Entscheidung (2026-09-01, bestätigt): Eigene Stack-basierte Bytecode-VM (Option 1, TBVM), sowohl in der Entwicklungsphase als auch eingebettet in die Executables (tb-IDE und von tbc erzeugte Programme), damit der schnelle Edit-Run-Turnaround überall identisch ist. Die IR/Bytecode-Schicht wird sauber vom Interpreter getrennt, sodass später ein zweites Backend (WASM via Cranelift, Option 3) ergänzt werden kann, ohne das Frontend anzufassen. Für die Ausführungsgeschwindigkeit typischer Terminal-Programme ist ein Interpreter mehr als ausreichend; entscheidend sind Debugger-Fähigkeit, exakte Fehlersemantik und der schnelle Edit-Run-Zyklus der IDE.

• Optionen aufstellen und bewerten (siehe Tabelle)
• Bytecode-Grobdesign und Speichermodell (Tagged Enum, Rc statt GC) → docs/tbvm-design.md. Das Feindesign (Opcode-Satz, Konvertierungsmatrix, Runner-Verhalten) ist Eingangsaufgabe von Phase 2

0.3 Ratatui-/Terminal-Spike

Entscheidung (2026-09-01): Keine CP437-Emulation — der Textbildschirm ist durchgängig UTF-8/Unicode. Strings sind Unicode-Text, CHR$/ASC arbeiten auf Codepoints. Das ist eine bewusste Abweichung vom Vorbild und wird in der Sprachreferenz unter „Abweichungen" dokumentiert.

Entscheidung (2026-09-02): Dynamische Terminalgröße statt festem 80×25. IDE und erzeugte Programme passen sich der Fenstergröße an; Mindestgröße ist 80×25, darunter wird nur ein Hinweis gerendert (btop-artig). SCREEN.Height/Width, CSRLIN/POS/LOCATE arbeiten auf der tatsächlichen Größe; tb-ui::screen unterstützt resize().

• 80×25-Zellenpuffer (Zeichen + Farbattribut) als eigenes Widget rendern; kleinere Terminals: Hinweis „Terminal zu klein", größere: zentriert (Letterboxing) → tb-ui::screen, Demo: cargo run -p tb-ui --example spike
• 16-Farben-Palette (Vordergrund 0–15, Hintergrund 0–7) auf ANSI-Indexfarben abgebildet; Blink-Attribut vorerst ignoriert (offen)
• Maus-Ereignisse (crossterm) und Sondertasten (F1–F12, Alt-Kombis) im Spike sichtbar gemacht; der systematische Test je Terminal-Emulator ist Teil der Plattformtests in Phase 6 (Die Ereignisschleifen-Architektur — Terminal-Events → Event-Queue → VM-Ticks — ist Eingangsaufgabe von Phase 4.)

Phase 1 — Sprach-Frontend (tb-frontend)

Status: abgeschlossen (2026-09-02).

• Lexer inkl. Typ-Suffixe, Zeilennummern/Labels, REM/'-Kommentare, case-insensitive Keywords, Zeilenfortsetzung mit _, Hex-/Oktal- Literale, Literal-Typisierung, Metabefehle ($INCLUDE, $STATIC, $DYNAMIC)
• SINGLE/DOUBLE-Schwelle suffixloser Dezimalpunkt-Literale entschieden (> 7 signifikante Stellen → DOUBLE) und in docs/sprachreferenz.md §1 dokumentiert
• AST für Module, Prozeduren, Anweisungen, Ausdrücke, Deklarationen
• Parser (zeilenorientiert, fehlertolerant — Fehler pro Anweisung gesammelt, Synchronisation bis Anweisungsende): Zuweisung inkl. MID$-Anweisung, PRINT/LPRINT (inkl. USING/#), INPUT/LINE INPUT, IF (Block + einzeilig), SELECT CASE, FOR/DO/WHILE, GOTO/GOSUB/ON-GOTO, ON [LOCAL] ERROR/RESUME, DIM/REDIM/CONST/ DEFtype/OPTION/TYPE/DECLARE/SUB/FUNCTION/CALL, COMMON/SHARED/STATIC, DATA/READ/RESTORE, DEF FN (einzeilig + Blockform), VIEW PRINT, NAME…AS, Ereignissteuerung (TIMER/KEY(n)/… ON|OFF|STOP), komplette Datei-E/A-Grammatik (OPEN in beiden Syntaxen inkl. ISAM-Klausel, CLOSE, FIELD, GET/PUT, LSET/RSET, WRITE, SEEK, LOCK/UNLOCK)
• Semantik: Symboltabellen, implizite Deklaration, DEFtype-Regeln, Typprüfung, OPTION EXPLICIT/BASE, Arrays (implizit/DIM/REDIM), UDT-Feldtypen (kunde.name), SHARED-Import von Modulvariablen, COMMON, Konstantenfaltung (CONST, „Invalid constant"), Builtin-Signaturen, Label-Prüfung, Prozedur-Signaturprüfung; deklarierte Non-Features (Hardware-Nähe, CHAIN, Grafik, SOUND/PLAY) werden zur Compile-Zeit mit „Feature unavailable" abgewiesen
• Diagnostik mit exakten Positionen; Meldungstexte folgen dem Katalog des Vorbilds (Type mismatch, Duplicate definition, Label not defined, Feature unavailable, Invalid constant …). Neue Meldungen entstehen mit dem jeweiligen Feature (Teil der Definition of Done)
• Meilenstein: kompletter Testkorpus parst und wird typgeprüft (crates/tb-frontend/tests/corpus.rs; 33 Frontend-Tests)

Vollständigkeits-Hinweis: Die Sprachabdeckung wird in Phase 3 per Inventar systematisch gegen die Original-Hilfe abgeglichen; dort gefundene Frontend-Lücken sind Bugs im Sinne des Guiding Principle und werden sofort geschlossen (kein Wiedereröffnen der Phase nötig).

Phase 2 — Bytecode und VM (tb-vm)

Status: abgeschlossen (2026-09-02). OpenSpec-Änderung phase-2-bytecode-vm (Proposal/Design/Specs/Tasks). Zusätzliche Entscheidung: Die Sema liefert ein typisiertes HIR (Namen → Slots, Konvertierungen explizit) als Codegen-Eingabe; der Codegenerator ist ein reiner Tree-Walk.

• Eingangsaufgabe (aus Phase 0 übernommen): Bytecode-Feindesign — Opcode-Satz, Zahlenkonvertierungs-Matrix (implizite Casts, Rundung, Überlauf), STOP/CONT-Verhalten im Runner ohne IDE (offene Punkte in docs/tbvm-design.md abgearbeitet)
• Bytecode-Format und Serialisierung (.tbc, Formatversion 1; Roundtrip- und Versionsablehnungs-Tests)
• Codegenerator HIR → Bytecode (monomorphe Opcodes, Fixup-Listen)
• Interpreter: Ausdrücke, Kontrollfluss (IF, SELECT CASE, Schleifen, GOTO/GOSUB), Prozeduraufrufe, BYREF-Semantik (inkl. Klammer-BYVAL, STATIC, Rekursion, DEF FN, DATA/READ/RESTORE)
• Fehlerbehandlung: ON [LOCAL] ERROR GOTO/RESUME, ERR/ERL, Fehler im Handler fatal (keine Kaskaden), Propagation über Frames
• Unterbrechbarkeit: Tick-Grenzen, Breakpoints, Einzelschritt, Variableninspektion (Grundlage für IDE-Debugger); STOP ist in der Einbettung fortsetzbar (CONT-Grundlage)
• Benchmarks in benches/: Compile-Budget gemessen (49 760 Zeilen in 124 ms; Einzelmodul 1,2 ms — Budgets eingehalten) und VM-Durchsatz (≈5 Mio Schleifeniterationen/s); Ergebnisse in docs/tbvm-design.md
• Meilenstein: Konsolen-Testkorpus läuft mit korrekter Ausgabe (tbc run + Harness crates/tb-cli/tests/compat.rs; Korpus um konvertierung/fehlerbehandlung/byref erweitert)

Vorgezogen aus Phase 3 (Meilenstein-Voraussetzung): Host-Trait (Konsole/Capture), Builtin-Dispatch-Tabelle, PRINT-Formatierung mit Druckzonen sowie die Korpus-Stringfunktionen (tb-runtime).

Phase 3 — Laufzeitbibliothek (tb-runtime) und Bildschirm

Status: abgeschlossen (2026-09-04). Umgesetzt in den OpenSpec-Changes phase-3-runtime-bildschirm (Kern), phase-3-ortszeit und phase-3-isam, mit dem Phase 3 endet.

Ziel ist die vollständige Standardbibliothek des Vorbilds (siehe Leitplanke Vollständigkeit); die Aufzählungen unten sind Beispiele. Maßgeblich ist seit 2026-09-03 das Inventar, nicht diese Liste.

• Vollständigkeits-Inventar → docs/inventar.md: 285 Einträge aus den Themenlisten von bas7advr.hlp und qb45advr.hlp mit Status und Fundstelle. Ein Test (crates/tb-frontend/tests/inventar.rs) hält die Tabelle in beide Richtungen gegen den Code — der Abdeckungsstand kann nicht mehr veralten. Stand: 217 implementiert · 15 offen · 53 Non-Feature. Die 15 offenen sind 13 Forms und Ereignissteuerung (Phase 4) sowie RUN und $INCLUDE (Phase 5).
• Bildschirmpuffer in die Laufzeit (Entscheidung 2026-09-03): Cell/TextScreen liegen ratatui-frei in tb-runtime::screen; tb-ui behält Farbabbildung, Widget und den Terminal-Host. Damit erreicht die Bibliothek den Puffer, und Bildschirmverhalten ist ohne Terminal prüfbar.
• Host neu geschnitten (BREAKING): statt Zeichenstrom nun Anzeige des Zellenpuffers plus Ereignisse (Taste, Größenänderung, Abbruch). write/read_line konnten LOCATE, COLOR, CSRLIN und das Zurücklesen per SCREEN(z, s) nicht transportieren.
• Korpusvergleich auf Bildschirm-Snapshot (BREAKING): getrimmt auf die belegte Fläche, Attributebene nur bei gesetzten Farben. Die acht bestehenden Sollausgaben blieben dabei unverändert.
• 80×25 ist nirgends eine feste Grenze (Vorgabe 2026-09-03): alle Bildschirmpfade rechnen mit der aktuellen Größe; Größenänderungen während der Ausführung werden zugestellt (Inhalt oben links erhalten, Cursor und VIEW PRINT geklemmt). Der Korpus weist es nach: dasselbe Programm bei 80×25 und 120×40 mit je eigener Sollausgabe, plus ein Programm mit Größenwechsel mitten im Lauf.
• Breite Unicode-Zeichen belegen zwei Zellen (Emoji, CJK): Cursorfortschritt, POS, Umbruch am rechten Rand und das Leeren der Gegenhälfte beim Überschreiben.
• Bildschirm: CLS, COLOR, LOCATE, WIDTH, VIEW PRINT, SCREEN (Anweisung und Funktion), CSRLIN, POS, TAB, SPC
• Tastatur: INKEY$ (nicht blockierend, Sondertasten als CHR$(0)+code), INPUT$, Funktionstasten-Makros KEY n, text$ / KEY LIST / KEY ON|OFF (Umfang aus der Original-Hilfe geklärt)
• Strings vollständig; Randfälle (VAL-Präfix, STR$-Vorzeichenspalte, Fehler 5 bei Startposition < 1) im Korpus verankert
• Zahlenformatierung: Druckzonen, PRINT USING/LPRINT USING/ FORMAT$ vollständig inklusive %-Präfix bei Feldüberlauf und SetFormatCC; Banker's Rounding; CINT/CLNG/CSNG/CDBL/CCUR
• Mathematik inklusive kompatiblem PRNG: gleiche Saat ergibt dieselbe Folge, RND(0) wiederholt, RANDOMIZE ohne Argument erfragt den Startwert; Algorithmus dokumentiert
• Finanzmathematik (Befund des Inventars — im ursprünglichen Umfang übersehen): FV#, PV#, Pmt#, IPmt#, PPmt#, NPer#, Rate#, NPV#, IRR#, MIRR#, SLN#, SYD#, DDB#
• Datum und Zeit: Serienwerte, DATESERIAL/TIMESERIAL, DATEVALUE/TIMEVALUE, DAY…SECOND, NOW, DATE$/TIME$ als Funktion und Anweisung
• Datei-E/A: OPEN in beiden Syntaxen (sequenziell, RANDOM, BINARY), PRINT #/WRITE #/INPUT #/LINE INPUT #, GET/PUT mit Recordpuffer und mit UDT-Variablen, FIELD/LSET/RSET, EOF/LOF/LOC/SEEK/FREEFILE/ FILEATTR, LOCK/UNLOCK, LPRINT/LPOS, die Record-Konvertierungsfunktionen (MK…$/CV…) und die Dateisystem-Anweisungen. Feste Strings als UTF-32.
• System: ENVIRON/ENVIRON$, COMMAND$, FRE, CLEAR, TRON/TROFF, STACK, ERDEV/ERDEV$, ERR-Anweisung
• Aus Phase 2 verlagert — ON ERROR GOTO-Scoping: ein modulweiter Handler ist jetzt aus Prozeduren heraus ansprechbar (Sprungziel im Modulrumpf, prozedurübergreifender Fixup im Codegenerator); nur ON LOCAL ERROR bleibt prozedurlokal
• Aus Phase 2 verlagert — DATA-Rohtext: der Lexer liefert den Anweisungstext unverändert, unquotierte Elemente behalten Groß-/ Kleinschreibung und inneren Leerraum
• Aus Phase 2 verlagert — die vier TODO verify-Zellen der Konvertierungsmatrix sind aufgelöst. Die Original-Hilfe schweigt zu allen vieren; sie sind daher als datierte Projektentscheidung begründet dokumentiert und in konvertierung.bas verankert.
• Meilenstein: klassische Konsolenprogramme laufen unverändert — alle 22 Korpusprogramme laufen ohne Laufzeitfehler 73; der Fehler tritt nur noch bei bewusst offenen Elementen auf (ISAM, Forms, Ereignissteuerung).
• ISAM (Change phase-3-isam): OPEN … FOR ISAM, Indizes (ein- und mehrspaltig, eindeutig/mehrdeutig, auf-/absteigend), Cursor mit MOVE- und SEEK-Familie, Satzoperationen, Transaktionen mit Sicherungspunkten und die Fehler 81–89. Speicherschicht redb (Entscheidung 2026-09-03), ISAM-Semantik und ordnungserhaltende Schlüsselkodierung in tb-runtime::isam. Alle 22 ISAM-Elemente des Inventars sind damit implementiert. Damit endet Phase 3.

Befunde dieser Phase, die den Plan korrigiert haben

• Das Inventar deckte am ersten Tag zwölf Non-Features auf, die der Compiler entgegen der Phase-1-Spec nicht abwies (CALLS, SSEG, POINT, VIEW, COM, PEN, STRIG, STICK, die String*-Routinen sowie LINE und OPEN "COMn:" an ihrer Syntax). Alle geschlossen.
• Drei ganze Gruppen fehlten im ursprünglichen Umfang: Finanzmathematik, Record-Konvertierung und ein Rest an Dateisystemfunktionen.
• bas7advr.hlp allein ist keine vollständige Quelle: SGN, SQR, SPACE$, STRING$, CSRLIN, BEEP und DATE$ als Funktion fehlen dort. Das Inventar bildet deshalb die Vereinigung mit qb45advr.hlp.

Offene Entscheidungen, die in spätere Phasen zeigen

• Die Uhr lief zunächst in UTC, weil Ortszeit eine Zeitzonenbibliothek gebraucht hätte. Mit dem Change phase-3-ortszeit (2026-09-04) ist die Abweichung zurückgezogen: jiff liefert den UTC-Versatz zu einem Zeitpunkt, die Kalenderrechnung bleibt Eigenimplementierung.
• LPRINT schreibt am Programmende nach LPT1.TXT im Arbeitsverzeichnis; einen plattformübergreifenden Druckerkanal gibt es nicht.
• Neue Abhängigkeiten: unicode-width (Doppelzellen), jiff (Zeitzonenversatz) und redb (ISAM-Speicherschicht, auf tb-runtime::isam beschränkt).
• Die Original-Hilfe kennt bei CREATEINDEX keine Sortierrichtung; absteigende Indexspalten sind die einzige dokumentierte Erweiterung (- vor dem Spaltennamen), festgehalten in der Sprachreferenz. Die Cursor-Semantik folgt sonst durchweg dem Vorbild: die Delta-Spec hatte nach SETINDEX und DELETE zunächst einen unpositionierten Cursor vorgesehen und wurde am 2026-09-04 an die Original-Hilfe angeglichen (siehe Leitplanke „Referenzverhalten schlägt Eleganz").
• Die Argumentformen der ISAM-Elemente stammen erstmals aus den Einzelseiten der Original-Hilfe, nicht mehr nur aus der Themenliste. Das korrigierte eine Annahme des Entwurfs: die Spaltenliste von CREATEINDEX ist keine Zeichenkette mit Trennzeichen, sondern eine Folge einzelner Stringargumente. Belegt in der Change-Notiz umfang-und-signaturen.md; für spätere Phasen heißt das: die Themenliste klärt den Umfang, die Einzelseiten klären die Form.
• CLOSE beendet keine laufende ISAM-Transaktion (Befund der Verifikation, 2026-09-04). Anfangs schrieb es sie fest, womit das Schließen irgendeiner Dateinummer die Transaktion aller anderen mit beendete. Über das Ende einer Transaktion entscheiden allein COMMITTRANS und ROLLBACK ALL; eine beim Programmende offene Transaktion verfällt.

Phase 4 — Forms-Engine (tb-ui::forms)

Status: abgeschlossen (2026-09-05). Alle sieben Programme des öffentlichen VBDOS-Bestands kompilieren ohne Diagnose und starten im PipeHost.

• Eingangsaufgabe (aus Phase 0 übernommen): Ereignisschleifen- Architektur — Terminal-Events → Event-Queue → VM-Ticks, kooperative Zustellpunkte (DOEVENTS, SLEEP, blockierende Eingabe, Ende einer Ereignisprozedur) Befund: Die VM stellt klassische Traps über einen eigenen Frame zu; Forms-Ereignisprozeduren verwenden später denselben Rückrufweg.
• Formular-Modell: Eigenschaften, Lade-/Entladezyklus, SHOW/HIDE (modal/nicht-modal)
• Steuerelemente: CommandButton, TextBox, ListBox, ComboBox, CheckBox, OptionButton, Frame, Label, HScrollBar/VScrollBar, PictureBox (Text), Timer und VSpin/HSpin — mit ihren Eigenschaften, Methoden und Ereignissen
• Menüsystem (Menüleiste, Shortcuts, Access Keys)
• Fokus-/Tab-Reihenfolge, Access-Keys, Maussteuerung
• .FRM-Textformat: Serialisierung definieren (kein Original- Beispiel verfügbar — Windows-1.0-Schema, siehe dateiformate.md), dokumentieren, dann lesen/schreiben implementieren
• Konvertierungstool binäre .FRM → unsere Text-Serialisierung (Gegenstück zu FT.EXE des Vorbilds; Magic FC 08 01 00): als tbc convert-frm. Format per Reverse Engineering aus den Beispieldateien des Originalpakets und des cout/vbdos-Repos
• Meilenstein (erster Kompatibilitätstest): die Programme des dokumentierten Referenzbestands cout/vbdos ohne Non-Features kompilieren und sind nutzbar (Konsolenprogramme bereits ab Phase 3) Befund: Alle sieben Programme wurden gegen Commit 1cdd2b3 als .MAK bzw. .FRM ohne Diagnosen geprüft und im PipeHost gestartet. Dafür wurden Projekt-/Include-Auflösung, P-Code-Dekodierung, Zellgrafik und VSpin/HSpin vollständig geschlossen. Einzelheiten: openspec/changes/phase-4-steuerelemente/vbdos-befunde.md.
• Ereignisdispatch: Event-Queue ↔ VM (Ereignisprozeduren Name_Ereignis)
• Klassische Ereignis-Traps (ohne Forms, Sprachreferenz §8) — ON TIMER(n), ON KEY(n), ON UEVENT und ON SIGNAL(n) je mit GOSUB label, dazu die Steueranweisungen TIMER, KEY(n), UEVENT, SIGNAL(n) mit ON/OFF/STOP, das EVENT-Statement und SetUEvent. Setzt die Ereignisschleife (erste Aufgabe dieser Phase) voraus; COM/PEN/PLAY/STRIG bleiben Non-Feature (Fehler 73). 10 Inventareinträge Befund: EVENT besitzt nur ON/OFF; SIGNAL(1/2) bildet plattformübergreifend SIGINT/SIGTERM ab.
• Vordefinierte Dialoge: MSGBOX als Anweisung und als Funktion (liefert die gedrückte Schaltfläche) sowie INPUTBOX$. Sie hängen am Formularmodell, nicht an der Steuerelementliste, und fallen deshalb sonst zwischen die Aufgaben. 3 Inventareinträge
• Meilenstein: Beispiel-Formularprogramme aus dem Testkorpus laufen Befund: formular.frm speist Fokus, Tab, Access-Key, Mausklick, Menüwahl, Liste, Timer und modalen Dialog über eine deklarierte, virtuelle Ereignisfolge reproduzierbar ein.

Phase 5 — IDE (tb-ide)

• IDE-Rahmen: Menüleiste, MDI-artige Fensterverwaltung, Statuszeile, klassisches Farbschema
• Editor: Syntaxprüfung/-normalisierung pro Zeile (Keywords groß, Leerzeichen), Suchen/Ersetzen, Hilfe-Verweise
• Projektverwaltung (.MAK): mehrere Module/Formulare
• Formular-Designer: Steuerelemente platzieren/verschieben/skalieren, Properties Bar
• Ausführen aus der IDE: Start/Unterbrechen/Fortsetzen/Neustart
• Export-Bedienung der IDE: Run → Make EXE File und Make Library mit vollständigen Dialogen, Zielsystem/-architektur, Ausgabepfad, Eingabeprüfung, Status-/Fehleranzeige und Übergabe an den Exportpfad vorbereiten. Die UI gehört vollständig zu Phase 5. Solange der Exportpfad aus Phase 6 fehlt, bleiben die Dialoge bedienbar und erklären die fehlende Erzeugungsfunktion; es wird kein erfolgreicher Export vorgetäuscht. Make EXE zielt auf ein eigenständiges natives Executable, Make Library auf eine portable P-Code-Bibliothek (.tbl). Die native Runtime ist Bestandteil von tbrt; die Phase-6-Anbindung passt die vorbereitete Zielauswahl für den plattformunabhängigen Library-Export an.
• $INCLUDE im Compile-Treiber auflösen — der Lexer liefert den Metabefehl bereits als Token. Datei einlesen, Pfade relativ zur einschließenden Datei, Zyklen erkennen und namentlich abweisen. 1 Inventareintrag
• RUN — Programm neu starten bzw. ein anderes laden und starten. Nutzt denselben Zurücksetzpfad der VM wie „Neustart" oben. 1 Inventareintrag
• Debugger: Breakpoints, Einzelschritt/Prozedurschritt, Direktfenster, Überwachungsausdrücke
• Hilfe-System: rendert die Markdown-Dokumentation aus docs/ (Sprach- und Bibliotheksreferenz) im Help-Fenster — Konsolen- Markdown-Rendering mit Umbruch nach aktueller Fenstergröße, Hyperlink-Navigation wie im Vorbild (Tab/Enter/Alt+F1), F1 = kontextsensitiver Sprung zum Thema unter dem Cursor
• Meilenstein: Programm komplett in der IDE schreiben, gestalten, debuggen und ausführen

Abgenommen am 2026-09-07 durch Change phase-5-08-integration-und-phasenabnahme. Die zugehörigen verification.md und befehlsmatrix.md im OpenSpec-Change (bei Abschluss unter openspec/changes/archive/) ordnen alle elf Planpunkte und 45 Referenzbereiche den bestandenen Tests zu. Workspace-Regressionen, headless IDE/CLI/TBC-Parität, lokaler Unix-PTY-Test und Release-Compile-Budget sind bestanden. Die vollständige Terminal-/OS-Matrix bleibt Phase 6.

Phase 6 — Kompatibilität, Politur, Distribution

Verbindliche Build- und Release-Ziele (Terminalanwendungen): Windows amd64, macOS arm64 sowie Linux amd64 und arm64. Gitea Actions am bestehenden Origin erstellt ausschließlich beim Push neuer Release-Tags im Format vX.Y.Z die Artefakte für alle vier Ziele auf dem vorhandenen Linux-arm64-Runner: Linux arm64 nativ beziehungsweise mit festgelegter Zielbaseline, Linux amd64 und macOS arm64 über cargo-zigbuild, Windows amd64 über cargo-xwin. Cross-Toolchains einschließlich SDK/Sysroot werden in Change 06 reproduzierbar festgelegt; vier native Buildrunner sind nicht erforderlich. Echte Zielsystem- und Terminalprüfungen gehören in Change 05; Change 06 bindet diese Prüfungen und versions-/prüfsummengebundene Nachweise für die fertigen Pakete in die Releasefreigabe ein. Cross-Builds ersetzen keine Zielausführung. Unter Linux werden weiterhin mindestens zwei Emulatoren geprüft. Change 03 liefert Backend/CLI, das gemeinsame TBL-Testartefakt und die lokal verifizierte Verbraucherprobe; die vollständige Vierzielabnahme folgt in 05/06 und die abschließende Phasenabnahme in 07. Zusätzlicher Politur-Change phase-6-05a-vbdos-theme-und-kontrast: VBDOS-Referenzabgleich und verlässliche IDE-Farbabbildung einschließlich Kontrast aller UI-Zustände. Umsetzung nach 04, vor der abschließenden visuellen Plattformabnahme in 05; Releasefreigabe 06 und Phasenabschluss 07 setzen dessen bestandene Nachweise voraus. 05 kann seine übrigen Prüfpfade parallel vorbereiten. Die historische Gesamtübersicht bleibt erhalten; diese Ergänzung erweitert die Umsetzung auf acht Changes (01–07 plus 05a). 05a ist am 07.09.2026 auf Benutzeranweisung mit lokal verifizierter Implementierung archiviert; seine drei offenen visuellen Nachweise werden in 05 weitergeführt und bleiben Voraussetzung der Phasenabnahme. 05 ist am 07.09.2026 auf Benutzeranweisung synchronisiert und archiviert: RGB-/Fensterflächenkorrektur vom Benutzer bestätigt, automatisierte macOS- Prüfungen bestanden. Acht unvollständige Matrixaufgaben bleiben als Nachweisbedarf bei 06/07; Windows-Ausführung ist vorerst zurückgestellt. Aktiver Change ist 06 (Gitea Actions und Releases). Die Vierziel-Matrix und Pflichtabnahme sind in Actions belegt. Ab 08.09.2026 laufen Build, Tests und Artefaktuploads ausschließlich für neue Release-Tags, erstmals v1.0.0 mit Workspace-Version 1.0.0. Es gibt keine CI für normale Commits oder PRs und keinen manuellen Paketbuild. Tagformat und Versionsgleichheit werden vor dem Bau geprüft. Arbeit und Pushes erfolgen direkt auf main; Release-Tags werden zusätzlich erstellt und gepusht. Lokale Tests bleiben verfügbar. Eine manuelle Freigabe kann vorhandene Releasepakete nach deren Zielabnahme veröffentlichen, baut sie aber nicht erneut.

Release-Pakete: Windows als .7z, macOS und beide Linux-Architekturen als .tar.gz, jeweils mit tb, tbc und der passenden tbrt-Vorlage (Windows jeweils .exe) samt benötigten Metadaten.

Architektur: tbrt enthält die nativ kompilierte VM, Runtime und Terminal-/Forms-Unterstützung. BASIC-Programme und .tbl-Bibliotheken bestehen aus P-Code. „Native Systembibliothek“ bezeichnet die eigentliche Runtime, die in tbrt eingebaut wird, keinen separaten Library-Export von BASIC nach .lib/.a. tbc link und die IDE nutzen denselben P-Code-Linker; das vollständige Kompilat wird für Make EXE in die Zielvorlage eingebettet. Library-Erzeugung und Linken benötigen beim Anwender keinen C-/Rust-Compiler und keinen nativen Linker. Systemvoraussetzungen zur EXE-Finalisierung (insbesondere Signierung auf macOS) werden separat geprüft und dokumentiert.

Gesamtproposal und Abhängigkeiten: openspec/changes/archive/2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/phase-6-uebersicht.md.

• Kompatibilitäts-Testsuite ausbauen (Snapshot-Tests der Bildschirmausgabe)
• Plattformtests: Windows Terminal, Linux (mind. 2 Emulatoren), macOS — inkl. systematischem Maus-/Sondertasten-Test (F1–F12, Alt-Kombis; aus Phase 0 übernommen) und Dokumentation bekannter Terminal-Einschränkungen
• VBDOS-nahes IDE-Theme und Kontrast: Referenzansichten belegen, dunkelblaue Codefläche und nachvollziehbare Titelfarben verlässlich darstellen; alle Standardtexte mindestens 4,5:1, notwendige nichttextuelle Fokusmarkierungen mindestens 3:1. Auswahl, inaktive und deaktivierte Elemente, Menüs/Dialoge, Hilfe, Debugger und Designer prüfen; Benutzerfarben erhalten. Reale Theme-Nachweise in der Plattformmatrix, keine Abnahme allein anhand von ANSI-Farbnummern.
• Performance-Pass über die VM (nur falls nötig)
• Native Standalone-Executables: tbc build --exe und IDE → Make EXE File erzeugen ein direkt vom Zielsystem ausführbares, eigenständiges Programm in dessen nativem Executable-Format. Das geplante vorkompilierte tbrt mit eingebettetem P-Code erfüllt dies ohne Compiler-/Linker-Toolchain beim Anwender und ohne separat installiertes tb/tbc. Ein bloßes .tbc-Kompilat erfüllt diesen Punkt nicht. Die Erzeugung und Anbindung an die in Phase 5 vorbereitete IDE-UI erfolgen in Phase 6.
• P-Code-Bibliotheken und Linker: IDE → Make Library und tbc build --library erzeugen portable .tbl-Bibliotheken mit übersetzten Modulen, Symbolen, Signaturen und benötigten Daten. tbc link verbindet Hauptprojekt und Libraries zu einem vollständigen .tbc oder mit --exe und der passenden tbrt-Vorlage zu einem eigenständigen Executable. Die IDE nutzt denselben Linkdienst für Projekte mit .tbl-Verweisen und die Make-Aktionen. Wiederverwendung ohne Library-Quellen und identische TBL-Dateien auf allen vier Zielen werden geprüft. Die Runtime ist nativer Code in tbrt und wird nicht in jede TBL kopiert. Erzeugung und Backend-Anbindung erfolgen in Phase 6.
• Dokumentation: Sprachreferenz, Migrationshinweise, Beispielprogramme
• Release-Automatisierung (Gitea Actions am bestehenden Origin: Build + Tests und Pakete ausschließlich für neue Tags vX.Y.Z auf allen vier System-/Architektur-Zielen), Releases über Gitea; keine Commit-/PR-CI
• Abnahme der Leitplanke „Vollständigkeit ist das Soll": docs/inventar.md steht auf 0 offen — jeder der 285 Einträge ist entweder implementiert oder als Non-Feature in der Sprachreferenz gelistet. Der Abgleichstest inventar_stimmt_mit_code_ueberein hält das gegen den Code; hier wird es zum Abnahmekriterium.

---

Stufe 2 — Anreicherung (nach Phase 6, Ideenspeicher)

Bewusste Erweiterungen jenseits des Vorbilds — additiv, der Kernstandard bleibt gültig. Noch nichts davon ist beschlossen; Sammlung wächst:

• Sprachkomfort: OPTION EXPLICIT, Zeilenfortsetzung, BYVAL überall, längere Bezeichner, &&-Literale? (jeweils opt-in)
• Terminal von heute: Bildschirmgrößen jenseits 80×25, 256/24-Bit-Farben, Scrollback, Resize-Ereignisse als Forms-Ereignis
• Neue Steuerelemente (Tabelle/Grid, Baum, Statusleiste) im Stil der Forms-Engine
• Standardbibliothek: Prozessaufrufe mit Pipes, Umgebungs-/Argument-Handling für CLI-Tools, JSON/CSV, HTTP-Client, Pfad-/Verzeichnisfunktionen
• SQLite-Integration mit Embedded SQL (2026-09-02): Spracherweiterung für eingebettetes SQL — z. B. WHILE SELECT … / WEND-Konstrukte — mit Record-Buffer-Datentypen, auf denen SELECT/UPDATE/INSERT/ DELETE arbeiten (natürliche Weiterentwicklung der ISAM-Idee auf SQLite als Speicher)
• Runtime-Bibliotheken als BASIC-Bibliotheken (2026-09-02, erweitert 2026-09-04): in der Runtime integrierte Rust-Bibliotheken als eigene, importierbare Bibliotheken für BASIC-Programme bereitstellen —
  • crossterm für direkte Terminalsteuerung
  • jiff (seit dem Change phase-3-ortszeit in der Laufzeit): Zonennamen, Versatz zu einem Zeitpunkt, Umrechnung zwischen Zonen. Der Kernstandard braucht davon nur den Versatz für die Ortszeit; alles Weitere wäre eine Erweiterung.
• Verteilung: tbc build --exe als Single-File-Tool-Baukasten

---

Entschiedene Fragen (2026-09-02, alle offenen Punkte geklärt)

• CURRENCY (@): voll unterstützt als i64-Festkomma (×10 000); das Vorbild unterstützt den Typ laut Original-Hilfe vollständig.
• ISAM: wird implementiert (kein Non-Feature) → Aufgabe in Phase 3.
• PEEK/POKE/CALL INTERRUPT u. ä. Hardware-Nähe: nicht unterstützt; Ablehnung bereits zur Compile-Zeit (Meldung „Feature unavailable") — in der Semantik umgesetzt, dokumentiert in der Sprachreferenz.
• Breite Unicode-Zeichen (Emoji, CJK): belegen zwei Zellen → Umsetzung in Phase 3.
• GET/PUT-Records unter Unicode: feste Strings als UTF-32 (4 Bytes/Zeichen, feste Record-Länge); Inkompatibilität der Binärdateien zum Vorbild wird bewusst akzeptiert → Phase 3.
• Blink-Attribut (COLOR 16–31): kein echtes Blinken, Simulation als „hell" — in tb-ui::screen umgesetzt.
• Lizenz: MIT (LICENSE im Repo).

Neue offene Fragen werden hier gesammelt und mit Datum entschieden.