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