## Context

`tb-ide` hängt bereits von ratatui, crossterm, Frontend, VM und UI ab. `tb-ui::TerminalHost` gehört dem BASIC-Lauf und übersetzt Ctrl+C in Abbruch; seine Funktionscodierung endet bei F10. `tb-ui/src/events.rs` ist ein Platzhalter und keine wiederverwendbare IDE-Ereignisschleife. Die Oberfläche folgt `docs/ide-referenz.md`; das Dokumentmodell kommt aus 01.

## Goals / Non-Goals

**Goals:** Ein Terminalbesitzer, nachvollziehbarer Fokus und derselbe Befehlsweg für Maus, Tasten und Menüs; Oberfläche headless prüfbar.

**Non-Goals:** Fachlogik für Compiler, VM, Designer und Hilfe vorwegnehmen; universelles Widgetframework oder Plugin-System bauen.

## Decisions

1. `tb-ide` erhält einen kleinen App-Zustand und eine zentrale Ereignis-/Render-Schleife. Vorhandene ratatui-/crossterm-Typen reichen aus. Ein Terminal-Guard besitzt Raw Mode, Alternate Screen, Mausmodus und Cursor und stellt sie auch im Fehlerpfad zurück. Es wird kein zweiter `TerminalHost` innerhalb der IDE geöffnet.
2. Konkrete Befehls-Enums und Tabellen tragen Menütext, Mnemonic, Kontext und Verfügbarkeitsgrund. Dieselbe Aktion wird durch Menü, Tastatur und Statusklick aufgerufen. Reihenfolge: modaler Dialog, aktives Menü, aktiver Modus/Fenster, globale zulässige Aktionen, zuletzt BASIC-Eingabe bei Programmfokus. F11/F12 werden vor der BASIC-Umwandlung behandelt. Eine kleine Kontextmatrix prüft insbesondere F2/F10, Ctrl+C und Escape; kein generischer Event-Bus.
3. Fenster sind konkrete Varianten für Code, Project, Output, Calls, Debug, Immediate und Help. IDs verweisen auf Dokumente aus 01. Normalgeometrie und minimiert/maximiert werden getrennt gespeichert; Resize begrenzt Fenster auf die verfügbare Fläche. Dialoge kapseln Fokus und Eingabe, halten Daten aber nicht doppelt. Designer-spezifische Fenster ergänzt 05 über dieselbe Verwaltung.
4. Modals für Öffnen/Speichern und Änderungsentscheidungen werden jetzt an 01 angebunden. Spätere Fachbefehle erhalten erst mit ihrem Change eine aktive Implementierung. Für den Abschluss von 02 sind solche Befehle sichtbar deaktiviert; für Phase-5-Abnahme muss jeder Phase-5-Befehl aktiv im gültigen Kontext nachgewiesen sein. Das ist eine Integrationsreihenfolge, keine Scope-Kürzung.
5. Optionen verwenden eine kleine versionierte Datei im benutzerbezogenen Konfigurationsverzeichnis, keinen Projektschreibzugriff. Display, Rechtsklick, Syntax Checking und Standardverzeichnisse werden atomar gespeichert; Include-Suchpfade gehen explizit an 01, relative Includes bleiben vorrangig. Die Hilfe verwendet eingebettete Dokumente aus 07 und braucht keinen Pflicht-Hilfepfad. Ungültige Werte erhalten Diagnose und Default, unbekannte Schlüssel werden zur Vorwärtsverträglichkeit ignoriert. Vorhandene Serialisierung wiederverwenden, bevor eine zusätzliche Abhängigkeit erwogen wird.
6. **Dokumentierte Vorgaben bei offenen Referenzdetails:** nicht blockierende Startbegrüßung, Versionsinfo auch in About; keine vorgetäuschte Caps-/Num-Anzeige ohne Terminalsignal. Mindestgröße gilt für das physische Terminal. Das Output-Unterfenster darf kleiner sein (Umsetzung 04). Der Designer nutzt die belegte Properties Bar statt des unspezifischen Wortes „Eigenschaftenfenster“ in PLAN.md.
7. App-Zustand und Renderfunktion werden ohne echtes Terminal mit ratatui-TestBackend und eingespeisten crossterm-Events geprüft. Die Tests müssen Fokusänderungen und tatsächliche Eingabeverteilung beobachten; allein ein direkter Aufruf von Befehlsfunktionen genügt nicht.

8. **Export-UI in Phase 5, Erzeugung in Phase 6 (Benutzervorgabe 2026-09-06):** Beide Make-Menübefehle öffnen bereits vollständig bedienbare Dialoge. Der konkrete Auftrag enthält Projektidentität/-revision, Artefaktart (natives Standalone-Executable oder native Systembibliothek), Zielsystem/-architektur, Ausgabepfad und Überschreibentscheidung. Vorgabe ist das laufende Zielsystem; Feldvalidierung und Status-/Fehler-/Abbruchdarstellung sind unabhängig von der Erzeugung testbar. Eine kleine konkrete Auftrags-/Ergebnisübergabe genügt, kein generisches Build-Plugin-System. Der Produktionspfad meldet in Phase 5 „Native Erzeugung folgt in Phase 6“ und sperrt nur die Erzeugen-Aktion, nicht den gesamten Dialog. Tests liefern kontrollierte Ergebnisse an dieselbe UI. Die echte Backend-Anbindung, native Formate, Symbol-/Aufrufvertrag der Library und der native Verbraucher-Nachweis gehören zu den expliziten Phase-6-Punkten in PLAN.md; `.tbc` ist kein Ersatzartefakt. Zielabhängige Formatdetails werden vom späteren Backend beschrieben, nicht als zweites Formatwissen in der IDE fest verdrahtet.

## Risks / Trade-offs

- Terminals verschlucken einzelne Alt-/F-Tasten → Menü- und Mauspfade bleiben erreichbar; tatsächliche Emulator-Matrix ist Phase 6, hier deterministische Codierung und dokumentierte Alternativen.
- Zu kleine Fenster → Clipping und Mindestfenstergeometrie; Rückkehr aus einem kleinen Terminal verliert keine Dokumente.
- UI-Rahmen wird zum Framework → konkrete Fenstervarianten und vorhandene Widgets, Abstraktionen nur für tatsächlich mehrfach vorkommende Bedienung.

## Migration Plan

Platzhalter durch den Rahmen ersetzen. Die CLI behält ihren eigenständigen Host. Benutzerkonfiguration entsteht erst bei explizitem Save; Entfernen der Konfigurationsdatei stellt Defaults wieder her. Dokumentdaten werden durch Layout-/Optionsänderungen nicht migriert.