Phase 0: Referenzdokumente, Fehlerkatalog, Testkorpus, Ratatui-Spike

Entscheidungen festgehalten: TBVM bestaetigt und eingebettet in die
Executables; durchgaengig UTF-8 statt CP437 (dokumentierte Abweichung).

- docs/: Sprachreferenz, Forms-Referenz, Dateiformate, TBVM-Design
- tb-runtime::errors: klassischer Laufzeitfehler-Katalog (implementiert)
- tb-ui::screen: 80x25-Unicode-Zellenpuffer mit 16-Farben-Abbildung,
  Scrollbereich (VIEW PRINT), Letterboxing; Ratatui-Widget + Tests
- Spike: cargo run -p tb-ui --example spike (Farben, Unicode, Tasten, Maus)
- tests/compat/: erste Referenzprogramme mit byte-genauer Sollausgabe

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

PLAN.md

@@ -23,17 +23,23 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
 ## Phase 0 — Exploration und Grundsatzentscheidungen
 
 ### 0.1 Sprach- und Bibliotheksreferenz rekonstruieren
-- [ ] Sprachreferenz zusammentragen: Anweisungen, Funktionen, Operatoren,
+- [~] Sprachreferenz zusammentragen: Anweisungen, Funktionen, Operatoren,
       Typsystem (INTEGER, LONG, SINGLE, DOUBLE, STRING, CURRENCY,
       feste Strings, `TYPE…END TYPE`), Typ-Suffixe (`% & ! # $ @`),
       `DEFINT`-Familie, Sichtbarkeitsregeln (`SHARED`, `COMMON`, `STATIC`)
-- [ ] Forms-/Steuerelemente-Referenz: Steuerelementtypen, Eigenschaften,
+      → Grundgerüst in [docs/sprachreferenz.md](docs/sprachreferenz.md);
+      Detailfragen (exaktes Verhalten) werden dort als TODO markiert
+- [~] Forms-/Steuerelemente-Referenz: Steuerelementtypen, Eigenschaften,
       Methoden, Ereignisse, Standardwerte, Fokus- und Z-Reihenfolge
-- [ ] Dateiformate dokumentieren: Quelltext (`.BAS`), Formulare (`.FRM`,
+      → Grundgerüst in [docs/forms-referenz.md](docs/forms-referenz.md)
+- [~] Dateiformate dokumentieren: Quelltext (`.BAS`), Formulare (`.FRM`,
       Textformat mit `VERSION`/`Begin…End`-Blöcken), Projekt (`.MAK`)
-- [ ] Laufzeitfehler-Katalog (Codes + Meldungstexte) erfassen
-- [ ] Testkorpus aufbauen: kleine Referenzprogramme, deren erwartete Ausgabe
-      dokumentiert ist (Grundlage der Kompatibilitäts-Testsuite)
+      → [docs/dateiformate.md](docs/dateiformate.md)
+- [x] Laufzeitfehler-Katalog (Codes + Meldungstexte) erfasst und als
+      `tb_runtime::errors` implementiert (inkl. Tests)
+- [~] Testkorpus aufbauen: kleine Referenzprogramme, deren erwartete Ausgabe
+      dokumentiert ist → erste Programme in `tests/compat/`, Harness folgt
+      mit Phase 2 (`tbdosc run` + Ausgabevergleich)
 
 ### 0.2 VM-/Runtime-Entscheidung (Aufstellung der Optionen)
 
@@ -53,7 +59,10 @@ BASIC-Semantik, serialisierbares Kompilat, gute Fehlerortung (Zeile/Spalte).
 | **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):** Eigene Stack-basierte Bytecode-VM (**Option 1, TBVM**).
+**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
+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
@@ -61,19 +70,28 @@ Terminal-Programme ist ein Interpreter mehr als ausreichend; entscheidend sind
 Debugger-Fähigkeit, exakte Fehlersemantik und der schnelle Edit-Run-Zyklus der IDE.
 
 - [x] Optionen aufstellen und bewerten (siehe Tabelle)
-- [ ] Bytecode-Grobdesign: Stack-Maschine, Konstantenpool, Zeilentabelle
+- [~] Bytecode-Grobdesign: Stack-Maschine, Konstantenpool, Zeilentabelle
       für Diagnostik/Debugger, Aufrufkonventionen (SUB/FUNCTION vs. GOSUB)
-- [ ] Speichermodell für Werte: Tagged Enum vs. NaN-Boxing; Refcounting
+      → Entwurf in [docs/tbvm-design.md](docs/tbvm-design.md)
+- [~] Speichermodell für Werte: Tagged Enum (kein NaN-Boxing); Refcounting
       für Strings/Arrays (kein Zyklenrisiko im Dialekt → Rc genügt)
+      → Entwurf in [docs/tbvm-design.md](docs/tbvm-design.md)
 
 ### 0.3 Ratatui-/Terminal-Spike
-- [ ] 80×25-Zellenpuffer (Zeichen + Farbattribut) als eigenes Widget rendern;
-      Verhalten bei kleineren/größeren Terminals festlegen (Letterboxing?)
-- [ ] Codepage-437-Abbildung auf Unicode (Rahmenzeichen, Symbole) prüfen —
-      Darstellungstest unter Windows Terminal, gnome-terminal, iTerm2
-- [ ] 16-Farben-Palette und Blink/Intensity-Attribut abbilden
-- [ ] Maus-Ereignisse (crossterm) und Sondertasten (F1–F12, Alt-Kombis) testen;
-      bekannte Terminal-Einschränkungen dokumentieren
+
+**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.
+
+- [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`
+- [x] 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; systematischer Test unter Windows Terminal,
+      gnome-terminal, iTerm2 steht aus
 - [ ] Ereignisschleifen-Architektur: Terminal-Events → Event-Queue → VM-Ticks
 
 ## Phase 1 — Sprach-Frontend (`tb-frontend`)
@@ -155,5 +173,12 @@ Debugger-Fähigkeit, exakte Fehlersemantik und der schnelle Edit-Run-Zyklus der
 - 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?
-- Verhalten bei Terminals < 80×25: Mindestgröße erzwingen oder scrollen?
+- 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)