Leitbild und Performance-Anforderungen verankern

- README: Leitbild Re-Imagination (Stufe 1 originalgetreu, Stufe 2
  additive Anreicherung fuer CLI-/TUI-Tool-Entwicklung)
- PLAN: Leitplanken (Online-Doku als Primaerquelle, Performance als
  Anforderung: Instant-Compile, Projekt-Build in Sekunden, Executable
  ohne Toolchain), Stufe-2-Ideenspeicher, Benchmark-Aufgaben in Phase 2
- tbvm-design: Performance-Abschnitt (Single-Pass, inkrementell,
  typisierte Opcodes, Slot-Aufloesung zur Compilezeit, Messlatten)

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

PLAN.md

@@ -10,11 +10,36 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
 
 ## Leitplanken
 
-- **Referenzverhalten schlägt Eleganz.** Bei Zweifeln zählt das beobachtbare
-  Verhalten des Vorbilds (inkl. Fehlercodes, Rundung, Formatierung), nicht
-  das, was „richtiger" wäre. Abweichungen werden dokumentiert.
+- **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.
 - **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.
+  - `tbdosc 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
   Kompatibilitäts-Testsuite (Verzeichnis `tests/compat`, geplant).
 
@@ -23,6 +48,12 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
 ## Phase 0 — Exploration und Grundsatzentscheidungen
 
 ### 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 zusammentragen: Anweisungen, Funktionen, Operatoren,
       Typsystem (INTEGER, LONG, SINGLE, DOUBLE, STRING, CURRENCY,
       feste Strings, `TYPE…END TYPE`), Typ-Suffixe (`% & ! # $ @`),
@@ -37,6 +68,9 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit
       → [docs/dateiformate.md](docs/dateiformate.md)
 - [x] Laufzeitfehler-Katalog (Codes + Meldungstexte) erfasst und als
       `tb_runtime::errors` implementiert (inkl. Tests)
+- [~] IDE-UX-Referenz: Menüstruktur, Fensterverwaltung, Farbschema,
+      Tastenbelegung, Editor-Verhalten des Vorbilds
+      → [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)
@@ -113,6 +147,9 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 - [ ] Fehlerbehandlung: `ON ERROR GOTO/RESUME`, `ERR`/`ERL`, Fehlerkaskaden
 - [ ] Unterbrechbarkeit: Tick-Grenzen, Breakpoints, Einzelschritt,
       Variableninspektion (Grundlage für IDE-Debugger)
+- [ ] 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`)
 
 ## Phase 3 — Laufzeitbibliothek (`tb-runtime`) und Bildschirm (`tb-ui::screen`)
@@ -166,6 +203,23 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert.
 
 ---
 
+## 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
+- Verteilung: `tbdosc build --exe` als Single-File-Tool-Baukasten
+
+---
+
 ## Offene Fragen
 
 - Umgang mit `CURRENCY` (`@`): als i64-Festkomma (×10 000) — klären, ob das

README.md

@@ -1,12 +1,29 @@
 # Terminal Basic
 
-Eine plattformübergreifende Re-Implementierung des letzten großen BASIC-Dialekts
+Eine plattformübergreifende **Re-Imagination** des letzten großen BASIC-Dialekts
 für DOS (1992) — Sprache, Laufzeitbibliothek, Forms-Engine und IDE — in Rust,
 mit [Ratatui](https://ratatui.rs) als Terminal-UI-Schicht.
 
 > Dieses Projekt ist eine unabhängige Neuentwicklung und steht in keiner
 > Verbindung zu Microsoft. Produktnamen Dritter werden bewusst nicht verwendet.
 
+## Leitbild
+
+Terminal Basic ist keine sklavische 1:1-Reimplementierung, sondern eine
+spirituelle Neuauflage: ein BASIC, mit dem man heute **Terminal-Tools baut** —
+CLI-Werkzeuge ebenso wie TUI-Anwendungen. Der Weg dorthin:
+
+1. **Erst die Re-Imagination:** gleiche UI/UX wie das Vorbild, gleicher
+   Sprachstandard, gleiche Standardbibliothek. Wer das Vorbild kannte, fühlt
+   sich sofort zu Hause; bestehende Programme laufen weitgehend unverändert.
+2. **Dann die Anreicherung:** über die Zeit kommen bewusst Elemente außerhalb
+   des Vorbilds dazu (moderne Terminal-Fähigkeiten, Sprachkomfort,
+   Bibliotheken). Erweiterungen sind additiv und brechen den Kernstandard
+   nicht.
+
+Wo Alt und Neu kollidieren, gewinnt die Plattform von heute — deshalb z. B.
+durchgängig UTF-8 statt Codepage 437 und keine Emulation von DOS-Hardware.
+
 ## Ziele
 
 - **Volle Sprachkompatibilität**: alle Sprachelemente des Dialekts —

docs/tbvm-design.md

@@ -78,6 +78,39 @@ Ressource an (Anhängen ans Binary + Fußzeile mit Offset/Magic; portabel für
 alle drei Plattformen). Alternative — `include_bytes!` + Cargo-Build beim
 Nutzer — verworfen: erfordert Rust-Toolchain beim Anwender.
 
+## Performance
+
+**Compiler (Instant-Compile, Anforderung siehe PLAN.md):**
+- Single-Pass pro Modul: Lexen, Parsen und Codegen in einem Durchlauf;
+  Vorwärtsreferenzen (Prozeduren, Labels) über Fixup-Listen statt zweitem
+  Pass. Die Sprache ist dafür gemacht — das Vorbild kompilierte auf
+  1992er-Hardware gefühlt sofort.
+- Modulweise inkrementell: `.BAS`/`.FRM` werden unabhängig zu Bytecode-
+  Einheiten übersetzt und beim Build nur zusammengebunden; die IDE
+  recompiliert nur geänderte Module (Hash über Quelltext).
+- Keine Optimierungspasses. Erlaubt sind nur Gratis-Optimierungen im
+  Codegen (Konstantenfaltung im Ausdruck, Peephole beim Emit).
+- Budget als Test verankern (Phase 2): Benchmark-Projekt (~50k Zeilen)
+  muss unter 1 s kompilieren (Release-Build der Toolchain, Referenzrechner);
+  einzelnes Modul < 50 ms.
+
+**VM-Ausführung:**
+- Alle Namen werden zur Compilezeit aufgelöst: Variablen/Parameter sind
+  Slot-Indizes, Prozeduren Tabellenindizes — zur Laufzeit keine
+  Hash-Lookups.
+- Statische Typen des Dialekts ausnutzen: typisierte Opcodes
+  (`ADD_I16`, `ADD_F64`, `CONCAT` …) statt generischem Dispatch über
+  `Value`-Tags in heißen Pfaden.
+- Dichte Opcodes, `match`-Dispatch in einer engen Schleife; Tick-Prüfung
+  (Events/Breakpoints) nur an Anweisungsgrenzen über ein einzelnes
+  Flag-Wort, nicht pro Opcode.
+- Strings immutabel via `Rc<str>` (Kopien sind Pointer-Kopien);
+  Konstantenpool dedupliziert.
+- Messlatte (Phase 2, Benchmarks in `benches/`): typische
+  Schleifen-/String-Lasten mindestens ~100× schneller als das Vorbild auf
+  Originalhardware; Richtwert grob Lua-Interpreter-Klasse, gemessen und
+  dokumentiert statt geraten.
+
 ## Offene Punkte
 
 - Opcode-Satz konkret ausformulieren (mit Phase 2)