TerminalBasic/openspec/changes/phase-5-02-ide-rahmen/design.md

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.