Phase 1: Sprach-Frontend (Lexer, AST, Parser, Semantik) + Entscheidungen

Frontend:
- Lexer komplett: Typ-Suffixe, Literal-Typisierung (Entscheidung: > 7
  signifikante Stellen -> DOUBLE), Hex/Oktal, Zeilenfortsetzung mit _,
  Strings mit ""-Escape, case-insensitive Keywords (Bibliotheksnamen
  bleiben Bezeichner)
- AST fuer Module/Prozeduren/Anweisungen/Ausdruecke
- Parser: fehlertolerant, zeilenorientiert; Kern-Anweisungssatz inkl.
  Bloecke, ON [LOCAL] ERROR, DEF FN (einzeilig); Datei-E/A als
  Phase-3-Platzhalter
- Semantik: Symboltabellen, implizite Deklaration, DEFtype, OPTION
  EXPLICIT, Arrays, Builtin-Signaturen, Labelpruefung; Hardware-Features
  (PEEK/POKE/...) werden zur Compile-Zeit abgewiesen
- Meilenstein: Testkorpus parst und wird typgeprueft (corpus.rs); 27 Tests

Entscheidungen eingearbeitet:
- Binaries heissen tb (IDE) und tbc (Compiler)
- Dynamische Terminalgroesse statt 80x25 (Minimum 80x25, btop-artiger
  Hinweis darunter); tb-ui::screen mit resize(), Spike angepasst
- Vollstaendigkeits-Leitplanke: 100% Sprache/Stdlib minus deklarierte
  Non-Features; Original-Doku als Guiding Principle; Inventar-Aufgabe
- CURRENCY als i64-Festkomma; ISAM wird implementiert; breite Zeichen
  belegen 2 Zellen; GET/PUT-Strings als UTF-32; Blink als hell simuliert
- LICENSE: MIT

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PLAN.md

@@ -22,6 +22,20 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
   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.
+- **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.
 - **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):
@@ -37,7 +51,7 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
   - **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.
-  - `tbdosc build --exe` erzeugt Executables **ohne** Compiler-/Linker-
+  - `tbc build --exe` erzeugt Executables **ohne** Compiler-/Linker-
     Toolchain beim Anwender (vorkompilierter Runner + angehängtes `.tbc`) —
     damit bleibt auch der Weg zum verteilbaren Binary im Sekundenbereich.
 - **Jede Phase endet mit lauffähigen Tests** gegen eine wachsende
@@ -79,7 +93,7 @@ Dokumentation nicht beantwortet.
       → [docs/ide-referenz.md](docs/ide-referenz.md)
 - [x] Testkorpus-Grundstock gelegt (`tests/compat/` mit dokumentierter
       Sollausgabe). Der Ausbau ist Daueraufgabe jeder Phase; das
-      Test-Harness (`tbdosc run` + Ausgabevergleich) ist Phase-2-Aufgabe
+      Test-Harness (`tbc run` + Ausgabevergleich) ist Phase-2-Aufgabe
 
 ### 0.2 VM-/Runtime-Entscheidung (Aufstellung der Optionen)
 
@@ -101,7 +115,7 @@ BASIC-Semantik, serialisierbares Kompilat, gute Fehlerortung (Zeile/Spalte).
 
 **Entscheidung (2026-09-01, bestätigt):** Eigene Stack-basierte Bytecode-VM
 (**Option 1, TBVM**), sowohl in der Entwicklungsphase als auch **eingebettet in
-die Executables** (`tbdos`-IDE und von `tbdosc` erzeugte Programme), damit der
+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
@@ -122,6 +136,12 @@ 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()`.
+
 - [x] 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`
@@ -134,19 +154,31 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       VM-Ticks — ist Eingangsaufgabe von Phase 4.)
 
 ## Phase 1 — Sprach-Frontend (`tb-frontend`)
-- [ ] Lexer inkl. Typ-Suffixe, Zeilennummern/Labels, `REM`/`'`-Kommentare,
-      case-insensitive Keywords, Zeilenfortsetzung mit `_`
-- [ ] Offene Detailfrage aus der Sprachreferenz klären: exakte
-      SINGLE/DOUBLE-Schwelle suffixloser Dezimalpunkt-Literale
-      (Quelle widersprüchlich → per Testkorpus festlegen und in
-      docs/sprachreferenz.md dokumentieren)
-- [ ] AST für Module, Prozeduren, Anweisungen, Ausdrücke, Deklarationen
-- [ ] Parser (zeilenorientiert, fehlertolerant — die IDE prüft pro Zeile)
-- [ ] Semantik: Symboltabellen, implizite Deklaration, `DEFINT`-Regeln,
-      Typprüfung und -konvertierung, `OPTION EXPLICIT`/`OPTION BASE`,
-      Array-Dimensionierung (statisch/dynamisch, `REDIM`)
-- [ ] Diagnostik mit exakten Positionen und den Meldungstexten des Vorbilds
-- [ ] Meilenstein: kompletter Testkorpus parst und wird typgeprüft
+- [x] Lexer inkl. Typ-Suffixe, Zeilennummern/Labels, `REM`/`'`-Kommentare,
+      case-insensitive Keywords, Zeilenfortsetzung mit `_`, Hex-/Oktal-
+      Literale, Literal-Typisierung
+- [x] SINGLE/DOUBLE-Schwelle suffixloser Dezimalpunkt-Literale entschieden
+      (> 7 signifikante Stellen → DOUBLE) und in docs/sprachreferenz.md §1
+      dokumentiert
+- [x] AST für Module, Prozeduren, Anweisungen, Ausdrücke, Deklarationen
+- [~] Parser (zeilenorientiert, fehlertolerant — Fehler pro Anweisung
+      gesammelt, Synchronisation bis Anweisungsende). Kern komplett:
+      Zuweisung, PRINT (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, DATA/READ/RESTORE, DEF FN (einzeilig).
+      Offen: MID$-Anweisung, DEF FN-Blockform, Datei-E/A-Anweisungen
+      (werden als Platzhalter geparst → Phase 3), `$INCLUDE`-Metabefehl
+- [~] Semantik: Symboltabellen, implizite Deklaration, `DEFtype`-Regeln,
+      Typprüfung, `OPTION EXPLICIT`, Arrays (implizit/DIM/REDIM),
+      Builtin-Signaturen, Label-Prüfung, Prozedur-Signaturprüfung.
+      Offen: `COMMON`/`SHARED` über Prozedurgrenzen, UDT-Feldtypen,
+      `OPTION BASE`-Auswertung, Konstantenfaltung
+- [~] Diagnostik mit exakten Positionen; Meldungstexte am Vorbild
+      orientiert (Type mismatch, Duplicate definition, Label not defined …)
+      — vollständiger Abgleich mit den Compile-Meldungen des Vorbilds offen
+- [x] Meilenstein: kompletter Testkorpus parst und wird typgeprüft
+      (`crates/tb-frontend/tests/corpus.rs`)
 
 ## Phase 2 — Bytecode und VM (`tb-vm`)
 - [ ] Eingangsaufgabe (aus Phase 0 übernommen): Bytecode-**Feindesign** —
@@ -163,9 +195,18 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 - [ ] Benchmarks in `benches/`: Compile-Budget messen (Projekt ≈50k Zeilen
       < 1 s, einzelnes Modul < 50 ms) und VM-Durchsatz (Schleifen/Strings);
       Ergebnisse in docs/tbvm-design.md festhalten
-- [ ] Meilenstein: Konsolen-Testkorpus läuft mit korrekter Ausgabe (`tbdosc run`)
+- [ ] Meilenstein: Konsolen-Testkorpus läuft mit korrekter Ausgabe (`tbc run`)
 
 ## Phase 3 — Laufzeitbibliothek (`tb-runtime`) und Bildschirm (`tb-ui::screen`)
+
+Ziel ist die **vollständige** Standardbibliothek des Vorbilds (siehe
+Leitplanke Vollständigkeit); die Aufzählungen unten sind Beispiele.
+
+- [ ] Vollständigkeits-Inventar erstellen: maschinenlesbare Liste aller
+      Anweisungen/Funktionen des Vorbilds aus der Original-Hilfe
+      (dos-help.soulsphere.org, Topic-Listen) mit Status
+      implementiert/offen/Non-Feature → `docs/inventar.md`; ab dann
+      Abdeckung je Phase fortschreiben
 - [ ] Strings: `LEFT$`, `MID$` (auch als Anweisung), `INSTR`, `STR$`/`VAL`,
       `SPACE$`, `STRING$`, `LTRIM$`/`RTRIM$`, `UCASE$`/`LCASE$` …
 - [ ] Zahlenformatierung: `PRINT`-Zonen, `PRINT USING` (vollständig;
@@ -175,7 +216,16 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       Funktionen, Integer-Überlaufverhalten (Fehler 6)
 - [ ] Datei-E/A: `OPEN` (sequenziell/random/binär), `INPUT#`/`LINE INPUT#`,
       `PRINT#`/`WRITE#`, `GET`/`PUT` mit Record-Typen, `EOF`/`LOF`/`SEEK`,
-      Pfadsemantik plattformübergreifend
+      Pfadsemantik plattformübergreifend. Record-Layout: feste Strings als
+      **UTF-32** (Entscheidung 2026-09-02 — 4 Bytes/Zeichen, feste
+      Record-Länge; bewusst inkompatibel zu Vorbild-Dateien)
+- [ ] ISAM-Dateiunterstützung (Entscheidung 2026-09-02: wird implementiert,
+      nicht Non-Feature): Anweisungen/Funktionen der Professional Edition
+      (`OPEN … FOR ISAM`, Tabellen/Indizes, `SEEKGT`-Familie …) — Umfang
+      aus der Original-Hilfe inventarisieren, dann implementieren
+- [ ] Breite Unicode-Zeichen (Emoji, CJK): belegen **zwei Zellen**
+      (Entscheidung 2026-09-02) — Zellenmodell und `LOCATE`/`POS`-Semantik
+      entsprechend umsetzen (unicode-width), Verhalten dokumentieren
 - [ ] Bildschirm: `PRINT`, `LOCATE`, `COLOR`, `CLS`, `INPUT`, `INKEY$`,
       `CSRLIN`/`POS`, `WIDTH`, `VIEW PRINT` auf dem Zellenpuffer
 - [ ] Offene Detailfrage klären: Umfang der `KEY n`-Funktionstasten-Makros
@@ -221,7 +271,7 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       aus Phase 0 übernommen) und Dokumentation bekannter
       Terminal-Einschränkungen
 - [ ] Performance-Pass über die VM (nur falls nötig)
-- [ ] `tbdosc build` → binäres Ergebnis: `.tbc`-Bytecode bzw. eigenständig
+- [ ] `tbc build` → binäres Ergebnis: `.tbc`-Bytecode bzw. eigenständig
       ausführbares Programm (Bytecode + eingebetteter Runner)
 - [ ] Dokumentation: Sprachreferenz, Migrationshinweise, Beispielprogramme
 - [ ] CI (GitHub Actions: Build + Tests auf allen drei Plattformen), Releases
@@ -241,23 +291,25 @@ bleibt gültig. Noch nichts davon ist beschlossen; Sammlung wächst:
   Forms-Engine
 - Standardbibliothek: Prozessaufrufe mit Pipes, Umgebungs-/Argument-Handling
   für CLI-Tools, JSON/CSV, HTTP-Client, Pfad-/Verzeichnisfunktionen
-- Verteilung: `tbdosc build --exe` als Single-File-Tool-Baukasten
+- Verteilung: `tbc build --exe` als Single-File-Tool-Baukasten
 
 ---
 
-## Offene Fragen
+## Entschiedene Fragen (2026-09-02, alle offenen Punkte geklärt)
 
-- Umgang mit `CURRENCY` (`@`): als i64-Festkomma (×10 000) — klären, ob das
-  Vorbild ihn überhaupt in allen Kontexten unterstützt
-- ISAM-Dateiunterstützung des Vorbilds: nachbilden oder als Nicht-Ziel erklären?
-- `PEEK`/`POKE`/`CALL INTERRUPT` u. ä. Hardware-Nähe: sinnvolle Teilmenge
-  emulieren (z. B. Bildschirmspeicher B800) oder Laufzeitfehler?
-- Unicode-Zeichen mit Darstellungsbreite ≠ 1 (Emoji, CJK): das Zellenmodell
-  ist strikt 1 Zeichen = 1 Zelle. Breite Zeichen ablehnen (Fehler 5),
-  ersetzen oder 2 Zellen belegen?
-- `GET`/`PUT` mit Record-Typen unter UTF-8: feste Strings (`STRING * n`)
-  waren im Vorbild n Bytes — bei uns n Zeichen. Binärlayout der Records
-  festlegen (Vorschlag: UTF-8 mit Padding auf feste Bytelänge? Oder UTF-32?)
-- Blink-Attribut (`COLOR` mit Vordergrund 16–31): ignorieren, als „hell"
-  darstellen oder echtes Terminal-Blink nutzen (nicht überall unterstützt)?
-- Lizenzwahl (MIT im Rahmen angenommen — bestätigen)
+- **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.