PLAN: Phasen einzeln abschliessbar machen, Phase 0 geschlossen

Offene Phase-0-Punkte in die konsumierenden Phasen verschoben:
Bytecode-Feindesign -> Phase 2, Ereignisschleifen-Architektur und
Text-.FRM-Serialisierung -> Phase 4, Literalschwelle -> Phase 1,
PRINT-USING-Ueberlauf und KEY-Makros -> Phase 3, Terminal-Matrix-
Tests -> Phase 6. Phase 0 ist damit vollstaendig abgeschlossen.

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

PLAN.md

@@ -47,6 +47,11 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
 
 ## 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,
@@ -57,23 +62,24 @@ Dokumentation nicht beantwortet.
 - [x] Sprachreferenz zusammengetragen und gegen die Original-Hilfe des
       Vorbilds (dos-help.soulsphere.org, README der Professional Edition)
       verifiziert → [docs/sprachreferenz.md](docs/sprachreferenz.md);
-      Rest-TODOs dort markiert (SINGLE/DOUBLE-Literalschwelle,
-      `PRINT USING`-Überlaufverhalten, `KEY n`-Makros)
+      die drei verbleibenden Detailfragen sind als Aufgaben zugeordnet:
+      SINGLE/DOUBLE-Literalschwelle → Phase 1, `PRINT USING`-Überlauf
+      und `KEY n`-Makros → Phase 3
 - [x] 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](docs/forms-referenz.md)
-- [~] Dateiformate dokumentieren → [docs/dateiformate.md](docs/dateiformate.md);
-      offen: exakte Text-`.FRM`-Serialisierung (kein Original-Beispiel
-      auffindbar — wir definieren nach Windows-1.0-Schema und dokumentieren)
+- [x] Dateiformate dokumentiert → [docs/dateiformate.md](docs/dateiformate.md);
+      die Definition der Text-`.FRM`-Serialisierung (kein Original-Beispiel
+      auffindbar) ist Eingangsaufgabe von Phase 4
 - [x] Laufzeitfehler-Katalog vollständig (1–76, ISAM 80–89, Forms 260–480)
       als `tb_runtime::errors` implementiert (inkl. Tests)
 - [x] IDE-UX-Referenz: Menüstruktur, Fensterverwaltung, Farbschema,
       Tastenbelegung, Editor-Verhalten aus Original-Hilfe und Screenshots
       → [docs/ide-referenz.md](docs/ide-referenz.md)
-- [~] Testkorpus aufbauen: kleine Referenzprogramme, deren erwartete Ausgabe
-      dokumentiert ist → erste Programme in `tests/compat/`, Harness folgt
-      mit Phase 2 (`tbdosc run` + Ausgabevergleich)
+- [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
 
 ### 0.2 VM-/Runtime-Entscheidung (Aufstellung der Optionen)
 
@@ -104,12 +110,10 @@ 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
-      für Diagnostik/Debugger, Aufrufkonventionen (SUB/FUNCTION vs. GOSUB)
-      → 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)
+- [x] Bytecode-**Grobdesign** und Speichermodell (Tagged Enum, Rc statt GC)
+      → [docs/tbvm-design.md](docs/tbvm-design.md). Das Feindesign
+      (Opcode-Satz, Konvertierungsmatrix, Runner-Verhalten) ist
+      Eingangsaufgabe von Phase 2
 
 ### 0.3 Ratatui-/Terminal-Spike
 
@@ -123,14 +127,19 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       (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
+- [x] 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`)
 - [ ] Lexer inkl. Typ-Suffixe, Zeilennummern/Labels, `REM`/`'`-Kommentare,
-      case-insensitive Keywords
+      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,
@@ -140,6 +149,10 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 - [ ] Meilenstein: kompletter Testkorpus parst und wird typgeprüft
 
 ## Phase 2 — Bytecode und VM (`tb-vm`)
+- [ ] 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 abarbeiten)
 - [ ] Bytecode-Format und Serialisierung (`.tbc`)
 - [ ] Codegenerator AST → Bytecode
 - [ ] Interpreter: Ausdrücke, Kontrollfluss (`IF`, `SELECT CASE`, Schleifen,
@@ -155,7 +168,8 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 ## Phase 3 — Laufzeitbibliothek (`tb-runtime`) und Bildschirm (`tb-ui::screen`)
 - [ ] Strings: `LEFT$`, `MID$` (auch als Anweisung), `INSTR`, `STR$`/`VAL`,
       `SPACE$`, `STRING$`, `LTRIM$`/`RTRIM$`, `UCASE$`/`LCASE$` …
-- [ ] Zahlenformatierung: `PRINT`-Zonen, `PRINT USING` (vollständig),
+- [ ] Zahlenformatierung: `PRINT`-Zonen, `PRINT USING` (vollständig;
+      dabei offene Detailfrage klären: `%`-Präfix bei Feldüberlauf),
       Banker's Rounding, `CINT`/`CLNG`/`CSNG`/`CDBL`/`CCUR`
 - [ ] Mathematik: `RND`/`RANDOMIZE` (kompatibler PRNG!), trigonometrische
       Funktionen, Integer-Überlaufverhalten (Fehler 6)
@@ -164,9 +178,15 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       Pfadsemantik plattformübergreifend
 - [ ] 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
+      (`KEY LIST`/`ON`/`OFF`) und in docs/sprachreferenz.md festhalten
 - [ ] Meilenstein: klassische Konsolenprogramme laufen unverändert
 
 ## Phase 4 — Forms-Engine (`tb-ui::forms`)
+- [ ] Eingangsaufgabe (aus Phase 0 übernommen): Ereignisschleifen-
+      Architektur — Terminal-Events → Event-Queue → VM-Ticks, kooperative
+      Zustellpunkte (`DOEVENTS`, `SLEEP`, blockierende Eingabe, Ende einer
+      Ereignisprozedur)
 - [ ] Formular-Modell: Eigenschaften, Lade-/Entladezyklus, `SHOW`/`HIDE`
       (modal/nicht-modal)
 - [ ] Steuerelemente: CommandButton, TextBox, ListBox, ComboBox, CheckBox,
@@ -174,7 +194,9 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
       Timer — mit allen Eigenschaften/Methoden/Ereignissen des Vorbilds
 - [ ] Menüsystem (Menüleiste, Shortcuts, Access Keys)
 - [ ] Fokus-/Tab-Reihenfolge, Access-Keys, Maussteuerung
-- [ ] `.FRM`-Dateiformat lesen/schreiben (Kompatibilität zu Originaldateien)
+- [ ] `.FRM`-Textformat: Serialisierung **definieren** (kein Original-
+      Beispiel verfügbar — Windows-1.0-Schema, siehe dateiformate.md),
+      dokumentieren, dann lesen/schreiben implementieren
 - [ ] Ereignisdispatch: Event-Queue ↔ VM (Ereignisprozeduren `Name_Ereignis`)
 - [ ] Meilenstein: Beispiel-Formularprogramme aus dem Testkorpus laufen
 
@@ -194,7 +216,10 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 
 ## Phase 6 — Kompatibilität, Politur, Distribution
 - [ ] Kompatibilitäts-Testsuite ausbauen (Snapshot-Tests der Bildschirmausgabe)
-- [ ] Plattformtests: Windows Terminal, Linux (mind. 2 Emulatoren), macOS
+- [ ] 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
 - [ ] Performance-Pass über die VM (nur falls nötig)
 - [ ] `tbdosc build` → binäres Ergebnis: `.tbc`-Bytecode bzw. eigenständig
       ausführbares Programm (Bytecode + eingebetteter Runner)