Phase 5 vollständig planen und native Exporte abgrenzen

openspec/changes/phase-5-02-ide-rahmen/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-06

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

@@ -0,0 +1,31 @@
+## 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.

openspec/changes/phase-5-02-ide-rahmen/proposal.md

@@ -0,0 +1,29 @@
+## Why
+
+tb-ide zeigt bisher nur einen Platzhalter. Ohne einen gemeinsamen Terminalbesitzer, Fensterverwaltung und eindeutige Tastenverteilung lassen sich Editor, Designer und Debugger nicht verlässlich integrieren.
+
+## What Changes
+
+- IDE-Ereignisschleife, Menüs und Dialoge mit Environment- und Designer-Modus gemäß docs/ide-referenz.md.
+- MDI-Fenster, Projektansicht, Fokus, Fensterbefehle, klickbare Statuszeile und klassische konfigurierbare Farben.
+- Persistente Display-, Pfad-, Rechtsklick- und Syntax-Checking-Einstellungen; sichere Behandlung kleiner Terminals und Terminalwiederherstellung.
+- Gemeinsame Befehlsverteilung für Tastatur, Maus und Menü; kontextabhängige Verfügbarkeit fachlicher Befehle. Fachlogik liefern die nachfolgenden Changes.
+- Vollständige IDE-Dialoge für Make EXE File und Make Library mit Zielsystem/-architektur, Ausgabepfad, Prüfung und Ergebnis-/Fehlerdarstellung. Die native Erzeugung und reale Backend-Anbindung folgen in Phase 6; bis dahin bleibt der fehlende Erzeugungsdienst ausdrücklich sichtbar.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-oberflaeche`: IDE-Ereignisschleife, Menüs und Dialoge mit Environment- und Designer-Modus gemäß docs/ide-referenz.md.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+crates/tb-ide/src/main.rs sowie IDE-interne App-, Fenster- und Dialogmodule; vorhandenes ratatui/crossterm und tb-ui-Rendering. Der BASIC-Tastenpfad bleibt von IDE-Kürzeln getrennt.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md).
+
+**Gesamtplanung:** [Phase-5-Übersicht](../phase-5-01-projekt-und-dokumentmodell/phase-5-uebersicht.md). Die Nummern geben eine gültige Umsetzungsreihenfolge an; OpenSpec erzwingt Change-Abhängigkeiten nicht automatisch.

openspec/changes/phase-5-02-ide-rahmen/specs/ide-oberflaeche/spec.md

@@ -0,0 +1,70 @@
+## Purpose
+
+Definiert den bedienbaren Terminalrahmen der IDE mit zwei Arbeitsmodi, gemeinsamen Befehlen, Fenstern, Dialogen und beständigen Benutzereinstellungen.
+
+## ADDED Requirements
+
+### Requirement: Start und zwei Arbeitsmodi
+Die IDE SHALL mit Versions-/Copyright-Begrüßung und anschließend einem leeren Projekt mit Codefenster „[1] Untitled“ und rechts angeordnetem Project Window starten. Programmierumgebung und Designer SHALL im selben Prozess arbeiten. Die Umgebung SHALL File/Edit/View/Search/Run/Debug/Options/Window und rechts Help zeigen; der Designer File/Edit/View/Tools/Options/Window/Help. Der Designer SHALL eine Properties Bar statt einer Statuszeile besitzen.
+
+#### Scenario: Erster Start
+- **WHEN** die IDE ohne Projekt gestartet wird
+- **THEN** ist das leere Codefenster direkt bedienbar und das Project Window sichtbar; die Begrüßung blockiert keine Eingabe
+
+### Requirement: Einheitliche Menü- und Befehlsbedienung
+Alle Befehle aus docs/ide-referenz.md SHALL im jeweils beschriebenen Menü erscheinen. Alt oder F11 SHALL die Menüleiste aktivieren, Mnemonics auswählen und Esc abbrechen; mit „…“ bezeichnete Befehle SHALL einen Dialog öffnen. Menü, Kürzel und anklickbarer Statushinweis SHALL dieselbe Aktion auslösen. Kontextuell unzulässige Befehle SHALL deaktiviert und ihr Grund erkennbar sein.
+
+#### Scenario: Modusabhängige Funktionstaste
+- **WHEN** F10 im Designer und danach im pausierten Programmiermodus gedrückt wird
+- **THEN** wechselt es im Designer zwischen Menü- und Properties Bar und löst im Programmiermodus den Prozedurschritt aus
+
+#### Scenario: Vollständige Eingabeverteilung
+- **WHEN** Ctrl+C im Editor, F11 zur Menüaktivierung und F12 im Formularkontext gedrückt werden
+- **THEN** werden Kopieren, Menüaktivierung und Event Procedures ausgelöst, ohne als BASIC-Abbruch oder verlorene Taste behandelt zu werden
+
+### Requirement: MDI-Fenster und Fokus
+Fenster SHALL Titelleiste, Control-Menü, Rahmen und bei Bedarf Scrollbalken erhalten. New Window SHALL eine zusätzliche Ansicht erzeugen; Arrange All SHALL geöffnete Fenster kacheln. F6/Ctrl+F6, Shift+F6, Ctrl+F4, Ctrl+F7/F8/F9/F10/F5 und Alt+Minus SHALL Wechseln, Schließen, Verschieben, Skalieren, Minimieren, Maximieren, Wiederherstellen und Control-Menü bedienen. Die Window-Liste SHALL das aktive Codefenster markieren. Projektbuttons Form/Code und Enter SHALL die entsprechende Ansicht öffnen.
+
+#### Scenario: Fenster wiederherstellen
+- **WHEN** ein Codefenster verschoben, skaliert, minimiert, maximiert und wiederhergestellt wird
+- **THEN** bleiben Dokument, Cursor und vorherige Normalgeometrie erhalten und alle Bedienelemente erreichbar
+
+#### Scenario: Dialogfokus
+- **WHEN** ein modaler Dialog geöffnet und anschließend abgebrochen wird
+- **THEN** empfängt nur der Dialog die Eingaben und danach erhält das vorher aktive Fenster den Fokus zurück
+
+### Requirement: Farben und Statusanzeige
+Die IDE SHALL das Farbschema aus docs/ide-referenz.md verwenden, insbesondere blaue Codefläche, weiße aktive Titel auf Magenta, graue Menüs und schwarze Statusschrift auf Cyan. Die Statuszeile SHALL kontextuelle klickbare Kürzel und Zeile/Spalte im Format 00001:001 zeigen. Display SHALL Vorder-/Hintergrund aus 16 Farben, Desktop-Füllzeichen und Tabweite ändern können.
+
+#### Scenario: Farben ändern
+- **WHEN** der Benutzer Titelhintergrund, Desktopzeichen und Tabweite im Display-Dialog ändert
+- **THEN** erscheinen die Änderungen in der IDE, während die Farbvorgaben des ausgeführten BASIC-Programms unverändert bleiben
+
+### Requirement: Beständige und validierte Optionen
+Options SHALL Display, Set Paths, Right Mouse, Save und Syntax Checking anbieten. Syntax Checking SHALL anfangs aktiv sein. Rechtsklick SHALL konfigurierbar Kontext-Hilfe auslösen. Explizites Save SHALL die Optionen benutzerbezogen speichern; fehlerhafte oder unbekannte Konfiguration SHALL mit verständlicher Diagnose und benutzbaren Vorgaben behandelt werden.
+
+#### Scenario: Neustart mit Optionen
+- **WHEN** Optionen gespeichert und die IDE aus einem anderen Arbeitsverzeichnis neu gestartet wird
+- **THEN** gelten die gespeicherten Werte weiterhin, ohne Projektdateien als Konfigurationsspeicher zu benutzen
+
+### Requirement: Terminalgröße und Wiederherstellung
+Die IDE SHALL die aktuelle Terminalfläche nutzen und auf Größenänderungen reagieren. Unter 80×25 SHALL ausschließlich ein Mindestgrößenhinweis erscheinen, ohne Dokumente oder Sitzung zu verlieren. Normaler Exit und Fehlerabbruch SHALL Terminalmodus und Cursor wiederherstellen.
+
+#### Scenario: Verkleinern und zurück
+- **WHEN** ein Terminal mit offenen Dokumenten unter 80×25 schrumpft und anschließend wieder wächst
+- **THEN** kehrt die bedienbare Oberfläche mit erhaltenen Dokumenten und erreichbaren Fenstern zurück
+
+### Requirement: Vollständige Exportdialoge mit getrennter Erzeugung
+Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare Dialoge für Artefaktart, Zielsystem/-architektur und Ausgabepfad öffnen. Die Ziele SHALL als natives eigenständiges Executable beziehungsweise native Systembibliothek beschrieben sein. Die Dialoge SHALL Eingaben prüfen, Überschreibkonflikte behandeln und Zustände für Erzeugung, Erfolg, Fehler und Abbruch darstellen können. Die tatsächliche Erzeugung SHALL erst mit dem Backend aus Phase 6 verfügbar sein; bis dahin SHALL nur die Erzeugungsaktion mit einem verständlichen Verfügbarkeitsgrund gesperrt sein. Die IDE MUST NOT einen Export vortäuschen oder ein bloßes TBC-Kompilat als natives Artefakt ausgeben.
+
+#### Scenario: Dialoge vor dem Erzeugungsbackend
+- **WHEN** beide Make-Befehle in Phase 5 über Menü oder Tastatur geöffnet werden
+- **THEN** lassen sich Zielsystem, Architektur und Ausgabepfad bearbeiten und validieren; die fehlende Erzeugung wird erklärt und keine Zieldatei geschrieben
+
+#### Scenario: Fehlerhafte Ausgabeangaben
+- **WHEN** ein leerer oder unzulässiger Ausgabepfad beziehungsweise ein bestehendes Ziel ohne Überschreibentscheidung angegeben wird
+- **THEN** zeigt der Dialog den Eingabefehler oder die notwendige Entscheidung und behält die übrigen Angaben
+
+#### Scenario: Ergebnisdarstellung über die vorbereitete Übergabe
+- **WHEN** die Exportanbindung im Oberflächentest Erzeugung, Erfolg, Fehler und Abbruch mit demselben gültigen Auftrag zurückmeldet
+- **THEN** zeigt die IDE jeweils den passenden Zustand mit Ziel beziehungsweise Diagnose und erhält die Projektdokumente; der Test behauptet keine tatsächliche native Dateierzeugung

openspec/changes/phase-5-02-ide-rahmen/tasks.md

@@ -0,0 +1,28 @@
+## 1. Terminalrahmen und Befehle
+
+- [ ] 1.1 Den tb-Platzhalter durch App-Zustand, Renderloop und einen Terminal-Guard ersetzen; headless Starttest zeigt Untitled-Code, Project Window und nicht blockierende Begrüßung, Guard-Test belegt Cleanup auch im Fehlerpfad.
+- [ ] 1.2 Die zwei Menüsätze und Befehls-/Verfügbarkeitstabelle aus der Referenz erfassen; ein Tabellenabgleich bestätigt Reihenfolge, Mnemonics und vollständige Einträge.
+- [ ] 1.3 Den Dispatcher für Alt/F11, Menüs, Dialoge, Fenster/Modi und spätere BASIC-Zustellung implementieren; Eventtests belegen Esc-Abbruch und eindeutige Verarbeitung von F2/F10/F11/F12/Ctrl+C.
+- [ ] 1.4 Dialoggrundfunktionen für Auswahl, Texteingabe, Dateiwahl und Bestätigungen mit den Aktionen aus 01 verbinden; Eventtests belegen Fokusbindung, Abbrechen und Erhalt geänderter Dokumente.
+
+## 2. Fensterverwaltung und Darstellung
+
+- [ ] 2.1 Code-/Projekt- und Werkzeugfenster mit Control-Menü, Rahmen, Scrollbalken und eigener Geometrie implementieren; TestBackend-Snapshots prüfen Titelnummern, aktive Markierung und Projektschaltflächen.
+- [ ] 2.2 New Window, Arrange All und sämtliche F6-/Ctrl-Fensterbefehle aus der Spec anbinden; eine Eingabefolge belegt Wechseln, Schließen, Bewegen, Größe, Minimieren, Maximieren und Wiederherstellen ohne Dokumentverlust.
+- [ ] 2.3 Das referenzierte DOS-Farbschema und klickbare Statuskürzel mit Zeile/Spalte darstellen; Snapshots und Klicktests belegen Farben, Position und dieselbe Befehlswirkung wie die Tastatur.
+- [ ] 2.4 Terminal-Resize und Mindestgröße 80×25 behandeln; Tests schrumpfen unter die Grenze und zurück und prüfen erreichbare Fenster, erhaltenen Fokus und Dokumente.
+- [ ] 2.5 Den Designer-Modus mit Properties-Bar-Platz und ohne Statuszeile anbinden; ein Moduswechseltest erhält das Dokument und zeigt den richtigen Menüsatz.
+
+## 3. Native Exporte vorbereiten
+
+- [ ] 3.1 Make EXE File und Make Library als vollständige Dialoge mit Zielsystem/-architektur und Ausgabepfad implementieren; Menü-/Tastaturtests öffnen beide Dialoge und bearbeiten alle Angaben.
+- [ ] 3.2 Eingabeprüfung und Überschreibentscheidung an die geschützten Dateiaktionen aus 01 anbinden; Tests prüfen leere/ungültige Pfade, bestehende Ziele, Abbrechen und erhaltene übrige Angaben.
+- [ ] 3.3 Konkrete Exportaufträge und Ergebnis-/Statusdarstellung vorbereiten, im Produktionspfad bis Phase 6 nur Erzeugen sperren; kontrollierte Rückmeldungen prüfen Laufend/Erfolg/Fehler/Abbruch und ein realer Phase-5-Aufruf erzeugt keine Datei oder falsche Erfolgsmeldung.
+- [ ] 3.4 Export-UI, native Zielartefakte und die Phase-6-Backend-Grenze in der Bedienungsdokumentation festhalten; Abgleich mit den expliziten PLAN-Punkten bestätigt, dass TBC nicht als natives Executable oder Library angeboten wird.
+
+## 4. Optionen und Integrationsübergabe
+
+- [ ] 4.1 Display-, Pfad-, Rechtsklick- und Syntax-Checking-Dialoge implementieren und benutzerbezogen speichern; Tests prüfen geänderte Farben/Tabweite, Include-Fallback, Defaults und Neustart aus anderem Arbeitsverzeichnis.
+- [ ] 4.2 Ungültige Konfiguration und nicht schreibbare Optionsdatei diagnostizieren; Tests erhalten bedienbare Defaults beziehungsweise ungespeicherte Einstellungen ohne falsche Erfolgsmeldung.
+- [ ] 4.3 Den headless App-Testpfad für nachfolgende Changes verfügbar machen und Fachbefehle bis zu ihrer Umsetzung mit erklärter Verfügbarkeit versehen; die Abdeckungstabelle unterscheidet Rahmenaktion und noch ausstehende Featureaktion.
+- [ ] 4.4 Bedienung und Referenzdefaults dokumentieren und alle Oberflächen-Spec-Szenarien in verification.md zuordnen; cargo test -p tb-ide und Formatprüfung müssen bestehen.