Phase 5 vollständig planen und native Exporte abgrenzen

PLAN.md

@@ -454,6 +454,14 @@ Maßgeblich ist seit 2026-09-03 das Inventar, nicht diese Liste.
 - [ ] Formular-Designer: Steuerelemente platzieren/verschieben/skalieren,
       Eigenschaftenfenster
 - [ ] Ausführen aus der IDE: Start/Unterbrechen/Fortsetzen/Neustart
+- [ ] **Export-Bedienung der IDE:** Run → Make EXE File und Make Library
+      mit vollständigen Dialogen, Zielsystem/-architektur, Ausgabepfad,
+      Eingabeprüfung, Status-/Fehleranzeige und Übergabe an den Exportpfad
+      vorbereiten. Die UI gehört vollständig zu Phase 5. Solange der
+      Exportpfad aus Phase 6 fehlt, bleiben die Dialoge bedienbar und erklären
+      die fehlende Erzeugungsfunktion; es wird kein erfolgreicher Export
+      vorgetäuscht. Make EXE zielt auf ein eigenständiges natives Executable,
+      Make Library auf eine native Bibliothek im Format des Zielsystems.
 - [x] **`$INCLUDE`** im Compile-Treiber auflösen — der Lexer liefert den
       Metabefehl bereits als Token. Datei einlesen, Pfade relativ zur
       einschließenden Datei, Zyklen erkennen und namentlich abweisen.
@@ -478,8 +486,22 @@ Maßgeblich ist seit 2026-09-03 das Inventar, nicht diese Liste.
       aus Phase 0 übernommen) und Dokumentation bekannter
       Terminal-Einschränkungen
 - [ ] Performance-Pass über die VM (nur falls nötig)
-- [ ] `tbc build` → binäres Ergebnis: `.tbc`-Bytecode bzw. eigenständig
+- [ ] **Native Standalone-Executables:** `tbc build --exe` und IDE →
-      ausführbares Programm (Bytecode + eingebetteter Runner)
+      Make EXE File erzeugen ein direkt vom Zielsystem ausführbares,
+      eigenständiges Programm in dessen nativem Executable-Format.
+      Der geplante vorkompilierte Runner mit eingebettetem Bytecode erfüllt
+      dies ohne Compiler-/Linker-Toolchain beim Anwender und ohne separat
+      installiertes `tb`/`tbc`. Ein bloßes `.tbc`-Kompilat erfüllt diesen
+      Punkt nicht. Die Erzeugung und Anbindung an die in Phase 5 vorbereitete
+      IDE-UI erfolgen in Phase 6.
+- [ ] **Native Systembibliotheken:** IDE → Make Library und der gemeinsame
+      Buildpfad erzeugen eine tatsächlich nutzbare Bibliothek im nativen
+      Bibliotheksformat des jeweiligen Zielsystems. Exportierte Symbole,
+      Aufruf-/Linkvertrag und erforderliche Runtime-Einbettung werden in
+      Phase 6 festgelegt und mit einem nativen Verbraucher geprüft; eine
+      umbenannte `.tbc`-Datei ist keine Systembibliothek. Dialoge und
+      Bedienung entstehen bereits in Phase 5, Erzeugung und Backend-Anbindung
+      in Phase 6.
 - [ ] Dokumentation: Sprachreferenz, Migrationshinweise, Beispielprogramme
 - [ ] CI (GitHub Actions: Build + Tests auf allen drei Plattformen), Releases
 - [ ] **Abnahme der Leitplanke „Vollständigkeit ist das Soll"**:

openspec/changes/phase-5-01-projekt-und-dokumentmodell/.openspec.yaml

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

openspec/changes/phase-5-01-projekt-und-dokumentmodell/design.md

@@ -0,0 +1,29 @@
+## Context
+
+`tb-cli/src/main.rs` besitzt `input_sources`, `expand_includes`, `relative_case_insensitive`, `read_form` und `compile` als private Funktionen. `SourceUnit`/`SourceSegment` erhalten bereits physische Quelldateien. `FormFile` kann binäre und textuelle Formulare lesen und Text unverändert oder kanonisch schreiben. Der IDE-Einstieg ist ein Platzhalter. Grundlage: [proposal.md](proposal.md), `docs/dateiformate.md:129` und die bestehenden CLI-Projekt-/Include-Tests.
+
+## Goals / Non-Goals
+
+**Goals:** Eine gemeinsame Lade-/Speichergrundlage mit stabiler Dokumentidentität; ausführbare Backend-Tests bereits vor der Oberfläche.
+
+**Non-Goals:** Editorwidget (03), Designgesten (05), VM-Sitzung (04), neue Workspace-Crate oder alternatives Projektformat.
+
+## Decisions
+
+1. Die bisherigen Ladefunktionen werden in ein öffentliches Projekt-I/O-Modul der vorhandenen `tb-vm`-Crate verschoben; sie hängt schon von Frontend und FRM ab. Die CLI verwendet es unmittelbar weiter. Eingabe ist eine konkrete Sammlung geänderter Dokumente plus Dateisystem-Fallback. Kein Dateisystem-Plugin und keine zweite Include-Implementierung. Include-Suchpfade können explizit übergeben werden; die relative Auflösung gewinnt immer, leere Pfadliste erhält das heutige Verhalten.
+2. In `tb-ide` hält ein Projekt geordnete Mitglieder und Dokumente mit stabiler ID, optionalem Pfad, Revision, gespeichertem Ausgangsstand und Änderungsstatus. Mehrere Ansichten halten nur ID, Cursor und Scrollposition. Neue Dateien erhalten vor dem ersten Speichern eine eindeutige virtuelle Quellidentität; ab Save As wird die Pfadzuordnung konsistent aktualisiert. Dieselbe reale Datei wird bei mehrfacher Einbindung ein Dokument, behält aber getrennte Modulkontexte.
+3. Ein FRM-Dokument enthält genau ein `FormFile`; dessen Code ist der Editorinhalt. Designer und Editor arbeiten transaktional daran. Die Formbeschreibung wird nicht aus einer zweiten, unabhängig gespeicherten Vorschau zurückgeschrieben. Originaldaten des bestehenden FRM-Schreibers bleiben für unveränderte Dokumente nutzbar.
+4. **Projektentscheidung für Set Start-up File:** Die optionale Kommentarzeile `' $STARTUP: "relativer/pfad.bas"` speichert eine explizite Auswahl. Doppelte, fehlerhafte oder nicht auf Mitglieder zeigende Angaben sind Fehler. Ohne diesen neuen Metakommentar bleibt das heutige Verhalten unverändert. Reguläre MAK-Einträge und fremde Kommentare bleiben lesbar und in ihrer Reihenfolge erhalten. Ältere Leser sehen weiterhin eine Kommentarzeile; sie kennen deren Startwirkung nicht. Die gemeinsame Compile-Eingabe übergibt die Auswahl an 04; es wird kein eigenes IDE-Startverfahren erfunden. Neue Projekte schreiben die explizite Auswahl, sobald der Benutzer sie setzt.
+5. Speichern serialisiert zunächst in temporäre Dateien im Zielverzeichnis und ersetzt einzelne Ziele kontrolliert. Projektmitglieder werden vor der MAK-Datei gespeichert. Kein Versprechen einer atomaren Mehrdatei-Transaktion: bei Teilfehlern werden nur erfolgreiche Dokumente als gespeichert markiert, übrige bleiben offen und die Projektaktualisierung wird nicht als erfolgreich gemeldet. Vor Überschreiben wird gegen den beim Laden/Speichern gelesenen Stand verglichen. Save As rechnet relative Referenzen neu aus und wechselt die aktive Identität erst nach Erfolg.
+6. Binäre FRM-Dateien sind Importquellen. Ein Textziel muss ausdrücklich gewählt werden, auch wenn Save gedrückt wurde; der Binärpfad ist kein überschreibbares Textziel. Load Text fügt am Cursor ein, Save Text exportiert Auswahl oder kompletten Code; beide nutzen dieselben Dokumentaktionen wie der Editor.
+
+## Risks / Trade-offs
+
+- Pfadalias, unterschiedliche Großschreibung und mehrfaches Include → kanonische Dateiidentität bei vorhandenen Dateien, explizite Modulzugehörigkeit separat; Tests mit Unterverzeichnissen und Leerzeichen.
+- Neue Startup-Metadaten werden von älteren Programmen ignoriert → Erweiterung und Rückwärtsgrenze in dateiformate.md dokumentieren; alte Dateien ohne Metadaten verhalten sich identisch.
+- Teilweise gespeichertes Projekt → keine falsche Erfolgsmeldung, ursprüngliche Zielversion je fehlgeschlagener Datei erhalten, MAK zuletzt; kein aufwendiges globales Transaktionssystem.
+- Umzug eines Projekts → Projektpfad und Mitgliederpfade getrennt führen; Includes bleiben relativ zu ihren ursprünglichen Dokumenten.
+
+## Migration Plan
+
+Zuerst bestehende CLI-Ladetests auf die gemeinsame API umstellen und unverändert grün halten, dann Dokumentaktionen hinzufügen. Neue Metadaten sind optional. Rücknahme des Changes lässt gewöhnliche Quellen lesbar, die neue Startup-Auswahl würde ein älterer Leser ignorieren. Kein automatisches Umschreiben bestehender Projekte beim bloßen Öffnen.

openspec/changes/phase-5-01-projekt-und-dokumentmodell/phase-5-uebersicht.md

@@ -0,0 +1,161 @@
+# Phase 5: Exploration und vollständige Change-Kette
+
+Planungsstand: 2026-09-06, Codebasis `024336e29ce0494fc268452e5eaf48c4ff68fbb2`.
+Diese Artefakte planen die Umsetzung; sie bestätigen keine bereits implementierte IDE.
+Maßgeblich sind [PLAN.md](../../../PLAN.md), die [IDE-Referenz](../../../docs/ide-referenz.md) und die bestehenden Hauptspezifikationen.
+
+## Ergebnis der Exploration
+
+Zum Ausgangsstand hatte Phase 5 acht offene und zwei bereits erfüllte PLAN-Punkte. Die geklärte Export-UI ist jetzt ein zusätzlicher expliziter offener Punkt (neun offen, zwei erfüllt). `$INCLUDE` und `RUN` sind im CLI-/VM-Pfad vorhanden; ihre IDE-Anbindung ist Bestandteil der neuen Changes. `tb` selbst ist noch ein Platzhalter. Die fehlende Arbeit liegt überwiegend in Oberfläche, Dokumentzustand und Einbettung; die Sprache und das Forms-Dateiformat müssen nicht erneut implementiert werden.
+
+| Bereich | Beobachteter Stand | Konsequenz für die Planung |
+|---|---|---|
+| [IDE-Einstieg](../../../crates/tb-ide/src/main.rs) | Nur Platzhalterausgabe; notwendige Workspace-Abhängigkeiten schon vorhanden | Rahmen, konkrete Fenster und Ereignisverteilung in 02 |
+| [CLI-Treiber](../../../crates/tb-cli/src/main.rs) | Private Projekt-/Include-/FRM-Lader, Compile, RUN-Zielauflösung und Reset | Laden in 01 gemeinsam nutzbar machen; Sitzung/Reset in 04 |
+| [Quellmodell](../../../crates/tb-frontend/src/source.rs) | SourceUnit/SourceSegment erhalten Originaldateien und physische Zeilen | Identitäten wiederverwenden; ungespeicherte Dokumente ergänzen |
+| [Projektcompiler](../../../crates/tb-vm/src/project.rs) | Übersetzt alle Module erneut, verknüpft Module und Forms; erstes Formular wird Startformular | Modulcache in 03; explizite Startup-Auswahl in 01/04 |
+| [VM](../../../crates/tb-vm/src/interp.rs) | RunEvents, Modul-/Zeilenbreakpoints, Step und einfache Inspektion vorhanden | Sichere Poll-/Wartezustände in 04; vollständiger Debugger in 06 |
+| [Runtime-Builtins](../../../crates/tb-runtime/src/builtins.rs) | Wartende Eingaben/Dialogs und direkte SHELL-Kindprozesse | Nicht nur den Run-Aufruf einbetten: Fortsetzungen und Terminalübergabe explizit umsetzen |
+| [Terminalhost](../../../crates/tb-ui/src/host.rs) | BASIC-Tastencodierung mit Ctrl+C-Abbruch und F1–F10 | IDE routet eigene Tasten einschließlich F11/F12 vor BASIC-Zustellung |
+| [ScreenWidget](../../../crates/tb-ui/src/screen.rs) | Mindestgröße wird an der Zeichenfläche geprüft | Physisches Terminal und kleines Output-Unterfenster unterscheiden |
+| [FRM-Modell](../../../crates/tb-ui/src/frm.rs) | Baum, Code, Binärimport, unveränderte/kanonische Textausgabe vorhanden | 05 editiert dieses Modell; keine zweite FRM-Implementierung |
+| [Forms-Metadaten](../../../crates/tb-frontend/src/forms.rs) | Klassen, Eigenschaften, Ereignisse und Arrayverträge vorhanden | Toolbox, Propertyvalidierung und Handlererzeugung daraus ableiten |
+| [Dokumentation](../../../docs/ide-referenz.md) | Rekonstruierte Menüs/Tasten, Farbschema, Designer und Hilfeverhalten beschrieben | Vollständige Befehlszuordnung unten; Dokumente als Offline-Hilfe in 07 |
+
+Besondere Risiken sind unverändert ausgeführte alte Kompilate nach einer Textänderung, Include-Breakpoints ohne Dateiidentität, wiederholte I/O-Nebenwirkungen nach einer Pause und voneinander abweichende Designer-/FRM-/Codezustände. Jeder dieser Fälle hat konkrete Szenarien und Tasks in seinem zuständigen Change.
+
+## Changes und Reihenfolge
+
+| Nr. | Change | Direkt benötigte Vorgänger | Ergebnis |
+|---|---|---|---|
+| 01 | [Projekt- und Dokumentmodell](proposal.md) | keine | Gemeinsame Lade-/Speicheraktionen, bearbeitete Quellen, MAK und Startup-Metadaten |
+| 02 | [IDE-Rahmen](../phase-5-02-ide-rahmen/proposal.md) | 01 | Terminalbesitz, Menüs, Fenster, Dialoge, Optionen und Eingabetestpfad |
+| 03 | [Editor und inkrementelle Übersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md) | 01, 02 | Vollständige Codebearbeitung, Diagnose und schneller aktueller Compile |
+| 04 | [Ausführung und Output](../phase-5-04-ausfuehrung-und-output/proposal.md) | 01, 02, 03 | Fortsetzbare VM-Sitzung, Reset, Ausgabe, Shell und Textdruck |
+| 05 | [Formular-Designer](../phase-5-05-formular-designer/proposal.md) | 01, 02, 03 | Visuelles Gestalten und konsistenter Ereigniscode |
+| 06 | [Debugger und Direktfenster](../phase-5-06-debugger-und-direktfenster/proposal.md) | 03, 04 | Quellgenaues Debuggen, Watches, Immediate, History und Fehlerhalte |
+| 07 | [Hilfesystem](../phase-5-07-hilfesystem/proposal.md) | 02, 03 | Offline-Markdown-Hilfe und Kontextnavigation |
+| 08 | [Integration und Phasenabnahme](../phase-5-08-integration-und-phasenabnahme/proposal.md) | 01–07 | Durchgängiger Arbeitsablauf, Befehlsabdeckung und nachgewiesener PLAN-Status |
+
+```text
+01 --> 02 --> 03 --> 04 --> 06 --+
+ |      |      +--> 05 ---------+
+ |      +----------> 07 --------+--> 08
+ +---------------------------------+
+```
+
+Die Tabelle ist die vollständige Abhängigkeitsliste; das Diagramm zeigt den Hauptfluss. Umsetzung 01 bis 08 ist eine gültige Reihenfolge. 05 und 07 können nach ihren Vorgängern auch früher umgesetzt werden. Jeder Change besitzt genau eine neue Capability und vollständige Artefakte; kein Change überschreibt das Delta eines anderen.
+
+OpenSpec erzwingt diese Change-Abhängigkeiten nicht selbst. Vor Apply sind die genannten Vorgänger anhand ihrer Implementation und Verifikation zu prüfen; ein vorhandenes tasks.md bedeutet nur Planungsbereitschaft. Nach Archivierung sind Vorgänger unter `openspec/changes/archive/` anhand des Change-Namens aufzufinden und die dann synchronisierten Hauptspezifikationen maßgeblich. Relative Verweise dieser Übersicht müssen beim Archivieren zusammen mit der Übersicht nachgeführt werden.
+
+## Gemeinsame Übergaben und Zuständigkeiten
+
+- **01 → 02/03/05:** Dokument-ID, Revision, physischer/virtueller Pfad, bearbeiteter Text beziehungsweise FormFile, geordnete Projektmitglieder, Startauswahl und sichere Dokumentaktionen. 01 liefert das direkt testbare Modell; 02 die Dialog-/Menüanbindung, 03 den Texteditor, 05 die Designgesten.
+- **02 → alle Oberflächen:** konkrete Befehle, Fokus/Modus, Fenster, modale Dialoge und ein Terminalbesitzer. Ein späterer Fachbefehl darf während Aufbau von 02 sichtbar deaktiviert sein; seine tatsächliche Funktion gehört vollständig zum verantwortlichen Folgechange und muss vor 08 aktiv sein.
+- **03 → 04/06:** nur zum vollständigen Projektrevisionssatz passende Kompilate, Originalquellorte und Deklarationsinformationen. Laufcode wird nicht in einer pausierten VM ausgetauscht.
+- **04 → 06:** pausierbare Sitzung mit eindeutigem Run-/Wait-/Break-Zustand und sauberer Fortsetzung. Scheduling-Yield und Debug-Step sind verschiedene Zustände; Rc-basierte VM-Werte bleiben im besitzenden Thread.
+- **05 → 03/04:** geändertes FormFile und Code im selben Dokument; Katalogbildung aus diesem Stand. Die Vorschau führt keine Handler aus.
+- **02/03/05 → 07:** Token, Befehl beziehungsweise Formklasse/Property als Kontext. 07 braucht für isolierte Kontextprüfungen keinen zweiten Designer; 08 prüft den tatsächlichen Aufrufweg.
+- **08:** prüft Übergänge und Vollständigkeit. Fehlende Fachfunktionen werden im zuständigen Featurebereich geschlossen, nicht durch einen parallelen Integrationscode ersetzt.
+
+## Abdeckung der PLAN-Punkte
+
+| Phase-5-Punkt | Umsetzung | Abnahme |
+|---|---|---|
+| IDE-Rahmen | 02 | Menüs/Fenster/Farben/Resize; 08 Befehlsmatrix |
+| Export-UI für Make EXE / Make Library | 02 | Vollständige Dialoge und Auftrags-/Ergebnisübergabe; 08 UI-Abnahme. Native Erzeugung: Phase 6 |
+| Editor | 03 | Bearbeitung, Normalisierung, Suche, Prozeduren, Includeorte; 08 Hauptablauf |
+| Projektverwaltung | 01, UI-Anbindung 02 | Mehrmodul-/FRM-Save/Reopen; 08 CLI-Parität |
+| Formular-Designer | 05 | Geometrie, Properties Bar, Menüs, Palette, Handler; 08 Gestalten→Run |
+| Ausführen aus der IDE | 04 | Start/Break/Continue/Reset und Output; 08 Parität |
+| `$INCLUDE` bereits umgesetzt | Erhalt durch 01/03, Debugbindung 06 | Relative/Zyklus-/Overlaytests und physische Quellorte |
+| `RUN` bereits umgesetzt | Erhalt und IDE-Anbindung 04 | Gleicher Reset, Fremdziel, Startzeile, Dokumenterhalt |
+| Debugger | 06 auf 04 | Alle Halte-/Watch-/Immediate-/History-/Fehlerpfade |
+| Hilfe | 07 | Offline, Markdown, F1/Links/Verlauf; 08 echte Aufrufer |
+| Vollständiges Programm in der IDE | 08 auf 01–07 | Erstellen→Gestalten→Speichern→Debuggen→Ausführen→Wiederöffnen |
+
+## Vollständige Zuordnung der Referenzbedienung
+
+Nummern bezeichnen Featurezuständigkeit; 02 stellt stets den gemeinsamen Menü-/Eingabepfad, 08 den Abschlussabgleich. Zusammengefasste Zeilen benennen jeden enthaltenen Befehl ausdrücklich.
+
+| Referenzbereich | Befehle / Bedienung | Zuständig |
+|---|---|---|
+| File | New Project, Open Project, Save Project | 01, 02 |
+| File | New Form, New Module, Add File, Remove File | 01, 02 |
+| File | Save File, Save File As, Load Text, Save Text | 01; Textbearbeitung 03 |
+| File | Print | 04 |
+| File | Shell | 04 |
+| File | Exit / Alt+F4 | 02; Dokumententscheidungen 01, Sitzungsende 04 |
+| Edit | Undo/Ctrl+Z, Cut/Ctrl+X, Copy/Ctrl+C, Paste/Ctrl+V, Clear/Del | Text 03, Controls 05 |
+| Edit | New Sub, New Function | 03 |
+| Edit | Event Procedures / F12 | 05, Codeoperationen 03 |
+| View | Code / F2, Form / Shift+F12 | 02, 03, 05 |
+| View | Next Statement | 06 |
+| View | Output Screen / F4 | 04 |
+| View | Included File, Included Lines | 03 |
+| View (Designer) | Menu Bar / F10, Grid Lines | 05 auf 02 |
+| Search | Find, Selected Text/Ctrl+Backslash, Repeat Last Find/F3, Change | 03 |
+| Run | Start/Shift+F5, Restart, Continue/F5, Modify COMMAND$ | 04 |
+| Run | Unterbrechen / Ctrl+Break | 04; zusätzlicher zugänglicher IDE-Befehl |
+| Run | Set Start-up File | Persistenz 01, Ausführungswirkung 04 |
+| Run | Make EXE File, Make Library | Vollständige UI 02, UI-Abnahme 08; native Erzeugung und reale Backend-Anbindung Phase 6 |
+| Debug | Add Watch, Instant Watch/Shift+F9, Watchpoint, Delete Watch, Delete All Watch | 06 |
+| Debug | Trace On, History On, Shift+F8/Shift+F10 | 06 |
+| Debug | Toggle Breakpoint/F9, Clear All Breakpoints, Break on Errors, Set Next Statement | 06 |
+| Debug-Tasten | F7 bis Cursor, F8 Single Step, F10 Procedure Step | 06 |
+| Options | Display, Set Paths, Right Mouse, Save, Syntax Checking | 02; Wirkung in 01/03/07 |
+| Window | New Window, Arrange All, offene Codefensterliste | 02 |
+| Window | Calls, Debug, Immediate | Fenster 02, Inhalt 06 |
+| Window | Help, Output, Project | Fenster 02, Inhalt 07/04/01 |
+| Window (Designer) | Color Palette, Menu Design Window, Toolbox, Help, Formliste | 05, Hilfe 07 |
+| Help | Index, Contents, Keyboard, Topic/F1, Using Help/Shift+F1, Tutorial, About | 07 |
+| Menüs | Alt/F11, Mnemonic, Esc, Dialogkennzeichnung „…“, Help rechts | 02 |
+| Fenster | F6/Ctrl+F6, Shift+F6, Ctrl+F4, Ctrl+F7/F8/F9/F10/F5, Alt+Minus | 02 |
+| Projektfenster | Anfangs rechts, Form/Code-Buttons, Enter | 02 auf 01 |
+| Toolbox/Tools | Check Box, Combo Box, Command Button, Dir List, Drive List, File List, Frame, HScrollBar, Label, List Box, Option Button, Picture Box, Text Box, Timer, VScrollBar; zusätzlich bereits unterstützte Spinvarianten | 05 |
+| Designgesten | Toolbox-Doppelklick, Aufziehen, Drag, Sizing Handles, Pfeile, Ctrl+Pfeile, Shift+Pfeile, Tab/Shift+Tab, Ctrl+Klick | 05 |
+| Properties Bar | Property/Value-Dropdown, Koordinaten/Größe, F2 Value, F10 Barwechsel, keine Statuszeile | 05 auf 02 |
+| Menüdesigner | Caption (&/-), CtlName, Tag, Index, Checked/Enabled/Visible/Separator, Shortcut, Einfügen/Löschen/Ebene/Reihenfolge/Done | 05 |
+| Farbpalette | ForeColor/BackColor, Drag auf Form | 05 |
+| Editor | Line-Leave-Prüfung/-Normalisierung, Syntax-Checking-Toggle, DECLARE, DEFtype | 03 |
+| Editor-Tasten | CUA, Einfg, Pos1/Ende, WordStar Ctrl+Q, Ctrl+Y, Bookmarks Ctrl+K,0–3 / Ctrl+Q,0–3, Shift+F2/Ctrl+F2 | 03 |
+| Immediate | PRINT, Zuweisungen, Prozeduraufrufe, ERROR n im Break-Modus | 06 |
+| Hilfe | F1/Rechtsklick, Shift+F1, ◄Thema►, Tab/Shift+Tab, Enter, Alt+F1 (20), Ctrl+F1, Esc | 07 |
+| Darstellung | DOS-Farben, Magenta-Titel, Desktopzeichen, Tabweite, klickbare Statuskürzel, Zeile/Spalte | 02 |
+| Start | Begrüßung, Version/Copyright, Untitled-Code/Projekt, keine Easy/Full-Modi | 02, About 07 |
+| Terminal | Dynamische Größe, physisches Minimum 80×25 | 02; Runtime-/Output-Abgrenzung 04 |
+| Laufzeitparität | Dieselbe TBVM in IDE, CLI und TBC | 04/06; Gesamtnachweis 08 |
+
+## Explizite Projektvorgaben und Phasengrenzen
+
+Die lokale IDE-Referenz enthält bewusst offene beziehungsweise nur grob beschriebene Details. Folgende Vorschläge sind deshalb als Terminal-Basic-Entscheidungen benannt, nicht als nachgewiesene Originaleigenschaften:
+
+- Startbegrüßung blockiert nicht; About bleibt verfügbar. Caps/Num wird ohne belastbares Terminalsignal nicht vorgetäuscht.
+- „Eigenschaftenfenster“ aus PLAN.md wird durch die in der Referenz konkret belegte Properties Bar erfüllt.
+- Startup-Auswahl verwendet einen optionalen MAK-Kommentar; alte Projekte bleiben unverändert. Die explizite Auswahl wirkt im gemeinsamen Compiler auf Modulreihenfolge und Startformular.
+- WordStar-Chords werden in 03 konkretisiert; Zwischenablage für CUA ist innerhalb der IDE verfügbar.
+- File→Print ist Textausgabe in eine auswählbare Druckdatei, Standard LPT1.TXT. Shell erhält vorübergehend das echte Terminal.
+- Automatische Watches sind nebenwirkungsfrei; allgemeine Prozeduraufrufe stehen im Direktfenster bereit. Watchpoints halten bei wahrer Bedingung. History navigiert die letzten 1.024 Quellorte, ohne Laufzeitzustände zurückzuspulen. Set Next Statement lehnt inkompatible Kontrollkontexte ab.
+- Die bestehende Release-Leitplanke (<50 ms Referenzmodul, <1 s Referenzprojekt) gilt auch für den neuen Compilerweg. Die Phase-6-Plattformmatrix und Distribution werden dadurch nicht als bereits bestanden behauptet.
+
+**Geklärte Benutzervorgabe (2026-09-06):** Make EXE erstellt ein eigenständiges natives Executable, Make Library eine tatsächliche Bibliothek im jeweiligen Systemformat. Die vollständige IDE-Bedienung gehört zu Phase 5: beide Dialoge, Zielsystem/-architektur, Ausgabepfad, Prüfung, Überschreibentscheidung, Status/Fehler/Abbruch und die konkrete Auftrags-/Ergebnisübergabe. Diese Arbeit liegt in 02 und wird in 08 integriert geprüft. Bis Phase 6 fehlen ausschließlich die tatsächliche Erzeugung und die reale Backend-Anbindung; die Dialoge bleiben bedienbar und erklären die gesperrte Erzeugen-Aktion. Kontrollierte Ergebnisrückmeldungen sind UI-Tests und kein Beleg für native Artefakterzeugung.
+
+[PLAN.md](../../../PLAN.md) enthält dafür getrennte Aufgaben: Export-UI in Phase 5 sowie native Standalone-Executables und native Systembibliotheken in Phase 6. Die dortige Executable-Erzeugung kann den bereits geplanten vorkompilierten Runner mit eingebettetem Bytecode verwenden; das Ergebnis muss ohne separat installiertes tb/tbc direkt ausführbar sein. Der Bibliothekspunkt verlangt natives Format, Symbol-/Aufruf-/Linkvertrag und einen nativen Verbraucher-Nachweis. Eine bloße oder umbenannte `.tbc`-Datei erfüllt keinen dieser beiden Exportpunkte. Format- und ABI-Details der Bibliothek werden beim Phase-6-Backend festgelegt, ohne in Phase 5 eine zweite Formatimplementierung in der UI vorwegzunehmen.
+
+## Abnahmepfad
+
+1. Jeden Featurechange anhand seiner Szenarien und der pro Task angegebenen Prüfung umsetzen; vorhandene CLI-/VM-/Forms-Regressionspfade weiterverwenden.
+2. Kein Spezifikationssync allein aufgrund grüner Artefaktstatus: die Implementierung muss zuvor nachgewiesen sein.
+3. In 08 alle Referenzbefehle gegen reale App-Eingaben abgleichen, den durchgängigen Arbeitsablauf ausführen und gespeicherte Quellen über CLI/TBC vergleichen.
+4. Release-Compile-Budget mit Hardware, Profil, Projektgröße und Messwerten belegen. Keine normalen Tests mit instabilen Debug-Zeitgrenzen versehen.
+5. Erst danach Phase-5-Checkboxen und Ist-Dokumentation aktualisieren. Die Befehlszuordnung und jeder Verifikationsbericht müssen frei von offenen Phase-5-Befunden sein.
+
+## Prüfung der Planungsartefakte
+
+Stand nach der geklärten Export-Zuordnung am 2026-09-06:
+
+- Acht Changes mit jeweils proposal.md, design.md, tasks.md und einer neuen Delta-Spezifikation: 47 Anforderungen, 67 Szenarien und 110 noch offene Umsetzungstasks.
+- `openspec validate --all --strict --json`: 23 von 23 Einträgen gültig (acht Changes und 15 Hauptspezifikationen); die acht neuen Changes haben keine Validator-Hinweise.
+- `openspec status --change <name> --json`: für jeden Change vollständige Planungsartefakte. `openspec instructions apply --change <name> --json`: alle Artefakte bereit, jeweils null Tasks erledigt. Die fachlichen Vorgänger aus der Abhängigkeitstabelle bleiben vor der Umsetzung zu beachten.
+- Zusätzlicher Strukturabgleich: jede neue Capability eindeutig, jedes Requirement mit WHEN/THEN-Szenario, Tasks eindeutig nummeriert, Abhängigkeiten azyklisch, lokale Markdown-Verweise auf vorhandene Ziele auflösbar.
+- Änderungen beschränken sich auf die acht neuen Planungsverzeichnisse und die angeforderte Präzisierung in PLAN.md. Produktcode und bestehende Hauptspezifikationen wurden nicht verändert; Produkttests wurden für diese reine Planung nicht erneut ausgeführt.

openspec/changes/phase-5-01-projekt-und-dokumentmodell/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Der CLI-Treiber kann Projekte und Includes laden, aber die IDE besitzt weder ein Projektmodell noch speicherbare Dokumente. Phase 5 braucht dieselben Quellen und Quellorte für Editor, Designer, Compiler und CLI.
+
+## What Changes
+
+- Gemeinsames Laden von BAS, FRM, MAK und Includes aus Dateisystem oder bearbeiteten Dokumenten; bisherige Pfad- und Diagnosesemantik erhalten.
+- Projekt- und Dokumentlebenszyklus mit Neuerstellung, Hinzufügen/Entfernen, Speichern, Save As, Änderungskennzeichnung und Schutz vor Datenverlust.
+- Explizite Startdatei im Projekt speichern; alte MAK-Dateien behalten ihre bisherige Startreihenfolge und Formularauswahl.
+- Text- und Formulardokumente als gemeinsame Grundlage mehrerer Ansichten; binäre FRM-Dateien kontrolliert in Text importieren.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-projekte`: Gemeinsames Laden von BAS, FRM, MAK und Includes aus Dateisystem oder bearbeiteten Dokumenten; bisherige Pfad- und Diagnosesemantik erhalten.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+crates/tb-cli/src/main.rs, crates/tb-vm/src/project.rs, crates/tb-frontend/src/source.rs, crates/tb-ui/src/frm.rs und das neue Dokumentmodell in tb-ide; docs/dateiformate.md. Keine neue Crate erforderlich.
+
+**Abhängigkeiten:** Keine offenen Vorgänger; Einstieg in Phase 5.
+
+**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-01-projekt-und-dokumentmodell/specs/ide-projekte/spec.md

@@ -0,0 +1,56 @@
+## Purpose
+
+Verwaltet Projekte, bearbeitbare Quell- und Formulardokumente sowie ihre Dateien konsistent zwischen IDE und Compiler, ohne Änderungen oder ursprüngliche Quellorte zu verlieren.
+
+## ADDED Requirements
+
+### Requirement: Gemeinsame Projekt- und Include-Auflösung
+IDE und CLI SHALL BAS-, FRM- und MAK-Quellen mit derselben relativen, DOS-großschreibungsunabhängigen Pfadauflösung laden. Verschachtelte Includes SHALL relativ zur einschließenden Datei aufgelöst werden; Diagnoseorte SHALL Modul, ursprüngliche Datei und physische Zeile erhalten. Offene Dokumente SHALL beim IDE-Übersetzen Vorrang vor ihrem Plattenstand haben.
+
+#### Scenario: Ungespeichertes gemeinsames Include
+- **WHEN** zwei Module dasselbe Include verwenden und dessen geöffneter Text geändert wird
+- **THEN** erhalten beide Module den bearbeiteten Text mit der Identität der Include-Datei; auf der Platte bleibt der bisherige Text bis zum Speichern bestehen
+
+#### Scenario: Fehler beim Öffnen
+- **WHEN** eine Projektdatei fehlt oder ein Include-Zyklus entdeckt wird
+- **THEN** nennt die Diagnose die beteiligten Pfade und das bisher geöffnete Projekt bleibt vollständig erhalten
+
+### Requirement: Projektmitglieder und Startdatei
+Die IDE SHALL New/Open/Save Project, New Module, New Form, Add File und Remove File anbieten. MAK-Mitglieder SHALL geordnet gespeichert werden. Set Start-up File SHALL genau ein vorhandenes BAS- oder FRM-Mitglied auswählbar und dauerhaft erkennbar machen. MAK ohne explizite Auswahl SHALL ihre bisherige Ausführungsreihenfolge und Startformularwahl behalten. Remove File SHALL nur die Mitgliedschaft entfernen und MUST NOT die Datei löschen.
+
+#### Scenario: Projekt wieder öffnen
+- **WHEN** Module und Formulare hinzugefügt, eine Startdatei gewählt und das Projekt gespeichert und erneut geöffnet werden
+- **THEN** bleiben Mitgliedschaft, Reihenfolge und Startdatei erhalten und dieselben Quellen sind auch über die CLI ladbar
+
+#### Scenario: Startdatei entfernen
+- **WHEN** die ausgewählte Startdatei entfernt werden soll
+- **THEN** wird eine Ersatzwahl oder die ausdrückliche Rückkehr zum bisherigen Standard verlangt; Abbrechen verändert nichts
+
+### Requirement: Gemeinsame Dokumente und Ansichten
+Mehrere Codefenster und der Formular-Designer SHALL denselben Dokumentstand benutzen. Fensterfokus, Cursor und Scrollposition SHALL ansichtsbezogen sein. Änderungen SHALL dokumentbezogen als ungespeichert erkennbar sein; Include-Ansichten MUST NOT expandierten Quelltext versehentlich als Ursprungsdatei speichern.
+
+#### Scenario: Zweites Codefenster
+- **WHEN** ein Dokument in zwei Fenstern offen ist und eines den Text ändert
+- **THEN** zeigt das andere denselben neuen Text mit eigener Cursorposition; Schließen einer Ansicht verwirft das Dokument nicht
+
+### Requirement: Verlustfreies Speichern und Wechseln
+Save File, Save File As, Save Project sowie Projektwechsel und IDE-Ende SHALL Änderungen mit Speichern/Verwerfen/Abbrechen behandeln. Fehlgeschlagenes Speichern MUST den bearbeiteten Stand erhalten und darf die letzte gültige Zieldatei nicht beschädigen. Externe Dateiänderungen und bestehende Save-As-Ziele SHALL vor Überschreiben erkennbar sein und eine ausdrückliche Wahl erfordern. Erst erfolgreich gespeicherte Dokumente SHALL als gespeichert gelten.
+
+#### Scenario: Schreibfehler im Projekt
+- **WHEN** ein Mitglied erfolgreich gespeichert wird, ein weiteres aber nicht geschrieben werden kann
+- **THEN** bleibt das zweite als geändert offen, der Fehler nennt den Pfad und das Projekt wird nicht als vollständig gespeichert oder geschlossen gemeldet
+
+#### Scenario: Save As in anderes Verzeichnis
+- **WHEN** ein Projekt unter einem neuen Pfad gespeichert wird
+- **THEN** werden relative Mitgliederverweise so angepasst, dass dieselben Dateien geladen werden; ein fehlgeschlagener Vorgang lässt den bisherigen Projektpfad aktiv
+
+### Requirement: Formularimport und Textaustausch
+Die IDE SHALL bestehende FRM-Leser und die kanonische Textausgabe gemäß forms-dateiformat verwenden. Binäre FRM-Originale MUST beim Import erhalten bleiben; die bearbeitete Textfassung SHALL über ein ausdrücklich gewähltes Ziel gespeichert werden. Load Text und Save Text SHALL Text in das aktive Codedokument einfügen beziehungsweise dessen Auswahl oder gesamten Inhalt exportieren, ohne die Projektmitgliedschaft unbemerkt zu ändern.
+
+#### Scenario: Binäres Formular bearbeiten
+- **WHEN** ein binäres Formular geöffnet, geändert und gespeichert wird
+- **THEN** fordert die IDE einen Text-Zielpfad an; Struktur, Array-Indizes und Code bleiben erhalten und die Binärquelle wird nicht überschrieben
+
+#### Scenario: Textimport rückgängig machen
+- **WHEN** Load Text eine Datei am Cursor einfügt und Undo folgt
+- **THEN** wird der ursprüngliche Dokumenttext wiederhergestellt

openspec/changes/phase-5-01-projekt-und-dokumentmodell/tasks.md

@@ -0,0 +1,21 @@
+## 1. Gemeinsame Quellen und Projektdateien
+
+- [ ] 1.1 Die privaten BAS/FRM/MAK-/Include-Ladefunktionen aus tb-cli in die vorhandene gemeinsame Crate übernehmen und alle CLI-Aufrufer umstellen; die bisherigen Projekt-, Include- und Diagnoseorttests müssen unverändert bestehen.
+- [ ] 1.2 Dokumentüberlagerung und stabile virtuelle/physische Quellidentitäten ergänzen; ein Test mit zwei Modulen und einem ungespeicherten Include belegt denselben neuen Inhalt bei getrennten Modulkontexten.
+- [ ] 1.3 Optionale Include-Suchpfade mit Vorrang der relativen Datei anbinden; Tests belegen Fallback, Großschreibung, Leerzeichen, fehlende Dateien und benannte Include-Zyklen.
+- [ ] 1.4 MAK-Mitgliedschaft, Reihenfolge und optionalen STARTUP-Metakommentar lesen/schreiben; Roundtrip-Tests belegen alte Dateien ohne Metadaten sowie Ablehnung doppelter/ungültiger Startangaben.
+
+## 2. Bearbeitbare Dokumente und sichere Dateiaktionen
+
+- [ ] 2.1 Projekt-/Dokumentzustand mit Revision, Pfad, gespeichertem Stand und mehreren Ansichten einführen; ein Test belegt gemeinsame Änderungen bei unabhängigen Cursor-/Scrollpositionen.
+- [ ] 2.2 New/Open Project, New Module/Form, Add/Remove File und Startdateiwahl als Dokumentaktionen implementieren; Tests belegen Abbruch ohne Teiländerung und Entfernen ohne Dateilöschung.
+- [ ] 2.3 FRM-Code und FormFile-Struktur als gemeinsames Dokument führen; ein Roundtrip mit Control-Array, Index 0 und Ereigniscode bestätigt den bestehenden Textvertrag.
+- [ ] 2.4 Save/Save As/Save Project mit geschützten Einzeldatei-Ersetzungen, Mitglieder-vor-MAK-Reihenfolge und Konflikterkennung implementieren; injizierte Schreibfehler und externe Änderungen erhalten jeweils den bearbeiteten Stand und letzte gültige Datei.
+- [ ] 2.5 Projekt-Save-As und Dokumentpfadwechsel korrekt auf relative Referenzen anwenden; ein Wiederöffnungstest aus einem anderen Verzeichnis lädt dieselben Mitglieder/Includes.
+- [ ] 2.6 Binär-FRM-Import mit ausdrücklichem Textziel sowie Load/Save Text implementieren; Tests belegen unveränderte Binärquelle und rückgängig machbaren Textimport.
+- [ ] 2.7 Speichern/Verwerfen/Abbrechen als gemeinsame Wechsel-/Schließaktion anbieten; Tests für mehrere geänderte Dokumente und Teilspeicherfehler verhindern falsches Schließen.
+
+## 3. Nachweise und Dokumentation
+
+- [ ] 3.1 docs/dateiformate.md um die optionale Startup-Erweiterung und Speicher-/Importregeln ergänzen; Beispiele werden vom gemeinsamen Loader als erwarteter Projektzustand gelesen.
+- [ ] 3.2 Die neue API durch IDE-Backend- und vorhandene CLI-Integrationstests gemeinsam prüfen und den Nachweis je Spec-Szenario in verification.md festhalten; cargo fmt --all -- --check und die betroffenen Crate-Tests müssen bestehen.

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.

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/.openspec.yaml

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

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/design.md

@@ -0,0 +1,31 @@
+## Context
+
+`SourceUnit::parse` erhält Segmentherkunft. `tb-vm/src/project.rs::compile_project` parst heute alle Module, löst Exportdeklarationen und Konstanten auf, senkt sie erneut ab und verknüpft alles. Es gibt keinen inkrementellen Cache und keine Editor-Normalisierung. Das bestehende Budget steht in `bytecode-kompilat` und `docs/tbvm-design.md`. Dokumente und UI stammen aus 01/02.
+
+## Goals / Non-Goals
+
+**Goals:** Text und Diagnose identisch zur bestehenden Sprache; nur tatsächlich betroffene Module erneut übersetzen; Quellorte bis zur Diagnose erhalten.
+
+**Non-Goals:** LSP, fremder Editorprozess, neuer BASIC-Parser, Rope ohne gemessenen Bedarf, teure Optimierung oder Live-Patching einer laufenden VM.
+
+## Decisions
+
+1. Ein dokumentbezogener Textpuffer mit Edit-Operationen reicht zunächst. Cursor/Selektion werden an Unicode-Grenzen geführt; Bildschirmspalten verwenden die vorhandene Unicode-Breitenlogik. Zusammengesetzte Aktionen (Paste, Replace All, Normalisierung, Prozedurerzeugung) sind eine Undo-Einheit. Die Zwischenablage ist IDE-intern verlässlich; ein späterer Betriebssystemadapter ist keine Voraussetzung für CUA-Kopieren zwischen IDE-Fenstern.
+2. Normierung nutzt Tokenarten und Quellspannen des vorhandenen Frontends, keinen Regex-Ersatz auf dem gesamten Text. Nur eindeutig erkannte Keywords/Trennräume werden geändert; Strings, Kommentare, DATA und Typ-Suffixe bleiben erhalten. Token-/AST-Vergleich der Vorher-/Nachher-Programme prüft Semantikerhalt. Unvollständige Konstrukte werden durch den bestehenden Parserkontext als unfertig markiert, nicht mit einem zweiten permissiven Parser ausgeführt. Line Leave aktualisiert den betroffenen Modulstand; ein noch unvollständiges Modul bleibt nicht startbar.
+3. Prozedurwahl zeigt Modulrumpf und SUB/FUNCTION-Einträge. Shift+F2 öffnet die Auswahl, Ctrl+F2 kehrt zur vorherigen Codeposition zurück. Die in der Spec konkretisierten Ctrl+Q-Chords sind Projektvorgaben für die in der Referenz nur allgemein genannte WordStar-Familie. Suchdialoge arbeiten zunächst auf dem aktiven Dokument oder dessen Auswahl; Projektweitsuche ist kein Phase-5-Punkt. Auswahl-Suche und F3 nutzen denselben Suchzustand.
+4. Generierte DECLARE-Zeilen liegen in einem eindeutig kommentierten IDE-Bereich und werden signaturbasiert gepflegt. Vorhandene explizite passende Deklarationen gewinnen; widersprüchliche Handdeklarationen werden diagnostiziert. Der Speicherhook schreibt niemals einen nur teilweise aktualisierten deklarativen Vorspann. Unfertiger oder fehlerhafter Quelltext bleibt ausdrücklich speicherbar: dann wird die automatische DECLARE-Pflege vollständig übersprungen und erklärt, während der eingegebene Text unverändert als Entwurf gespeichert wird. DEFtype-Übernahme verwendet die am Erzeugungsort gültigen Vorgaben und erzeugt keine doppelten Header. FRM-Code benutzt denselben Hook.
+5. Ein Cache innerhalb des vorhandenen Projektcompilers speichert Parsing und unverkettete Modulprodukte. Schlüssel umfassen Dokument-/Include-Inhalte, Modulidentität, Compilerkonfiguration, importierte öffentliche Vertragsinhalte und Forms-Metadaten. Abhängigkeiten folgen tatsächlicher Namensauflösung einschließlich CONST, TYPE, COMMON, DECLARE und Formularnamen. Private Rumpfänderungen invalidieren keine unabhängigen Module; Exportänderungen invalidieren transitive Verbraucher. Unsichere oder zuvor fehlerhafte Abhängigkeitsauflösung führt konservativ zur betroffenen vollständigen Neuauflösung, nicht zu einem vermeintlich gültigen alten Ergebnis.
+6. Der vorhandene Linker verknüpft gecachte unverkettete Produkte neu und remappt alle Slot-, Typ-, Prozedur-, String-, DATA-, Objekt- und Quell-IDs. Bereits verknüpfte Produkte werden nicht durch Feldpatches wiederverwendet. Der bisherige Vollcompile bleibt als Vergleichspfad und CLI-Einstieg erhalten. Kein dauerhaftes Cache-Dateiformat.
+7. Jede Diagnose und jedes Ergebnis gehört zu einem vollständigen Projektrevisionssatz. Start akzeptiert nur den aktuellen Satz; Compilefehler machen einen alten Erfolg nicht aktuell. Editieren während Break erzeugt eine neue Revision; die Laufentscheidung liegt bei 04. Ein einzelner UI-Prozess kann zunächst synchron auf Line Leave kompilieren, solange das bestehende Budget eingehalten wird; Hintergrund-Compiler und Cancellation werden nicht vorsorglich gebaut.
+8. Tests vergleichen Voll-/Cachepfad für private Änderungen, Includes, transitive Konstanten, Typ-/COMMON-Änderungen, Entfernen/Umordnen von Modulen und Forms-Arrayänderungen. Zähler belegen Wiederverwendung; Benchmarks messen inklusive Invalidierung/Link mit dem vorhandenen Referenzprojekt. Keine fragile Millisekunden-Assertion in normalen Debug-CI-Tests.
+
+## Risks / Trade-offs
+
+- Verdeckte Deklarationsabhängigkeit → Export-/Importsignaturen aus realer Auflösung, Differentialtests gegen frischen Compile; bei Zweifeln sicher neu auflösen.
+- Fehlerdialog beim unfertigen Block → zwischen unvollständig und eindeutig ungültig unterscheiden; Abbrechen lässt den Text stehen.
+- Textnormalisierung verändert Programme → geschützte Tokenklassen und Idempotenz-/Semantiktests, bei uneindeutigem Fragment keine Normalisierung.
+- Einfacher Textpuffer wird teuer → erst bei verfehltem Referenzbudget eine andere Datenstruktur erwägen.
+
+## Migration Plan
+
+Vollcompiler als Referenz beibehalten, Cache optional dazuschalten und mit denselben Quellen vergleichen. Generierte DECLARE-Blöcke sind normale BASIC-Kommentare und Deklarationen; Quellen bleiben mit der CLI lesbar. Cacheverlust bedeutet nur Neuübersetzung.

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Der vorhandene Frontend-/Projektcompiler übersetzt vollständige Einheiten, hat aber weder Editorfunktionen noch einen inkrementellen Cache. Phase 5 verlangt zeilenbezogene Rückmeldung und kurze Startzeiten auch bei mehreren Modulen.
+
+## What Changes
+
+- Quelltexteditor mit CUA- und WordStar-Bedienung, Undo, Suchen/Ersetzen, Include-Ansichten und Prozedurnavigation.
+- Syntaxprüfung und semantikerhaltende Normalisierung beim Verlassen einer Zeile; DECLARE-Pflege beim Speichern und DEFtype-Übernahme in neue Prozeduren.
+- Modulweiser Compiler-Cache mit Include- und Deklarationsabhängigkeiten, korrekter Invalidierung und identischen Ergebnissen zur vollständigen Übersetzung.
+- Quellgenaue Diagnosen und revisionsgebundene Kompilate; Messungen gegen das bestehende Instant-Compile-Budget.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-editor`: Quelltexteditor mit CUA- und WordStar-Bedienung, Undo, Suchen/Ersetzen, Include-Ansichten und Prozedurnavigation.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Editor, tb-frontend Lexer/Parser/Sema und tb-vm Projektcompiler/Linker; bestehende Compile-Budget-Tests und docs/tbvm-design.md. Kein zweiter BASIC-Parser und kein Optimizer.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/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-03-editor-und-inkrementelle-uebersetzung/specs/ide-editor/spec.md

@@ -0,0 +1,66 @@
+## Purpose
+
+Ermöglicht die vollständige Quelltextbearbeitung in der IDE und schnelle, quellgenaue Übersetzung des aktuellen Projektstands mit unveränderter BASIC-Semantik.
+
+## ADDED Requirements
+
+### Requirement: Editorbewegung und Änderungen
+Der Editor SHALL Einfügen/Überschreiben, Auswahl, CUA-Kopieren/Ausschneiden/Einfügen/Rückgängig, Pos1/Ende, seiten- und wortweise Navigation sowie Ctrl+Y zum Zeilenlöschen unterstützen. WordStar SHALL Ctrl+Q,S/D für Zeilenanfang/-ende, Ctrl+Q,R/C für Dateianfang/-ende und Ctrl+K,0–3 / Ctrl+Q,0–3 für Setzen/Anspringen von vier Lesezeichen unterstützen. Unicode-Zeichen und Tabulatoren SHALL ohne beschädigte Zeichen oder falsche Cursorpositionen bearbeitet werden.
+
+#### Scenario: Zusammengesetzte Bearbeitung
+- **WHEN** mehrzeiliger Text eingefügt, markiert, ausgeschnitten und rückgängig gemacht wird
+- **THEN** sind Text, Auswahl und Cursor nachvollziehbar wiederhergestellt; ein abgeschnittener WordStar-Chord führt keine zufällige Textänderung aus
+
+### Requirement: Suchen und Ersetzen
+Find, Selected Text mit Ctrl+Backslash, Repeat Last Find mit F3 und Change SHALL Suchtext, Richtung, Groß-/Kleinschreibung und Wortgrenzen berücksichtigen. Change SHALL Einzelersetzung und Ersetzen aller Treffer im gewählten Suchbereich erlauben; eine Ersetzungsaktion SHALL rückgängig machbar sein. Das Ende des Suchbereichs SHALL einen erkennbaren Rücksprung anbieten.
+
+#### Scenario: Leere und verkürzende Ersetzung
+- **WHEN** Treffer durch leeren oder kürzeren Text ersetzt werden
+- **THEN** werden alle vorgesehenen Treffer genau einmal verarbeitet; Undo stellt den gesamten Zustand vor der Aktion her
+
+### Requirement: Zeilenprüfung und Normalisierung
+Bei aktivem Syntax Checking SHALL das Verlassen einer geänderten Zeile eine Prüfung und bei eindeutig gültiger Syntax eine Normalisierung von Keywords und Leerzeichen auslösen. Zeichenketten, Kommentare, DATA-Nutztext, Bezeichner und Typ-Suffixe MUST semantisch unverändert bleiben. Unvollständige mehrzeilige Konstrukte SHALL als noch unvollständig behandelbar bleiben; sie dürfen die weitere Eingabe nicht blockieren. Abschalten SHALL automatische Formatierung und Fehlerdialoge unterbinden; Run SHALL weiterhin eine vollständige Gültigkeitsprüfung verlangen.
+
+#### Scenario: Nutztext unverändert
+- **WHEN** eine Zeile mit kleingeschriebenen Keywords, einem String, einem Kommentar und Typ-Suffixen verlassen wird
+- **THEN** werden nur syntaktische Keywords und zulässige Abstände normalisiert; erneute Normalisierung verändert nichts mehr
+
+#### Scenario: Unvollständiger Block
+- **WHEN** nach SUB oder einem mehrzeiligen IF die nächste Zeile begonnen wird, bevor END SUB beziehungsweise END IF vorhanden ist
+- **THEN** bleibt der Editor bedienbar und zeigt den unvollständigen Zustand, ohne das Fragment zu verwerfen oder ein altes Kompilat als aktuell startbar zu behandeln
+
+### Requirement: Prozeduren und Deklarationen
+New Sub und New Function SHALL gültige, eindeutig benannte Prozedurrümpfe mit den wirksamen DEFtype-Vorgaben anlegen. Shift+F2 und Ctrl+F2 SHALL Prozedurwahl beziehungsweise Rückkehr ermöglichen. Beim Speichern SHALL benötigte DECLARE-Prototypen erzeugt oder aktualisiert werden; benutzerdefinierte Deklarationen MUST NOT still überschrieben werden. Konflikte SHALL quellgenau gemeldet und der Dokumentstand erhalten werden. Unvollständige oder fehlerhafte Quellen SHALL als Entwurf speicherbar bleiben; dabei SHALL eine nicht sicher mögliche DECLARE-Pflege vollständig übersprungen und erklärt werden.
+
+#### Scenario: Wiederholtes Speichern
+- **WHEN** eine neue Prozedur angelegt und das Dokument mehrfach gespeichert wird
+- **THEN** existiert genau eine passende Deklaration; der zweite Speichervorgang erzeugt keine weitere Änderung
+
+#### Scenario: Unfertigen Entwurf speichern
+- **WHEN** eine noch unvollständige Prozedur gespeichert und erneut geöffnet wird
+- **THEN** bleibt der eingegebene Text erhalten; es wurde kein unvollständiger DECLARE-Vorspann erzeugt und die ausgelassene automatische Pflege wurde erklärt
+
+### Requirement: Include-Ansichten und Diagnosen
+Included File SHALL die Originaldatei der Einbindung öffnen; Included Lines SHALL die Expansion als klar gekennzeichnete Ansicht ein-/ausblenden. Diagnosewahl SHALL in das richtige Modul, die physische Datei und Zeile springen. Eingeblendete Expansion SHALL entweder zur Ursprungsdatei weiterleiten oder schreibgeschützt sein.
+
+#### Scenario: Gleichnamige Quellzeilen
+- **WHEN** zwei Includes derselben Übersetzung in derselben physischen Zeilennummer Fehler enthalten
+- **THEN** führen ihre Diagnosen jeweils zur richtigen Datei und nicht zur verketteten Modulzeile
+
+### Requirement: Korrekte inkrementelle Übersetzung
+Nach Änderungen SHALL nur die betroffene Übersetzungseinheit und ihre tatsächlich betroffenen abhängigen Einheiten neu übersetzt werden. Includes, öffentliche Signaturen, Konstanten, TYPE-/COMMON-Deklarationen, Modulreihenfolge und Forms-Struktur SHALL in die Gültigkeitsprüfung eingehen. Inkrementelle und frische vollständige Übersetzung desselben Stands SHALL dieselben Diagnosen und dasselbe Laufzeitverhalten liefern. Veraltete Ergebnisse MUST NOT einen neueren Dokumentstand überschreiben oder als dessen Kompilat ausgeführt werden.
+
+#### Scenario: Private Änderung
+- **WHEN** nur der Prozedurrumpf eines Moduls ohne Änderung seines öffentlichen Vertrags geändert wird
+- **THEN** wird dieses Modul neu übersetzt, unveränderte unabhängige Module werden wiederverwendet und das neu verknüpfte Projekt entspricht der vollständigen Übersetzung
+
+#### Scenario: Transitive Änderung
+- **WHEN** eine exportierte Konstante oder ein TYPE in einem gemeinsam eingebundenen Include geändert wird
+- **THEN** werden alle betroffenen direkten und transitiven Verbraucher aktualisiert; entfernte Symbole liefern dieselben Fehler wie eine frische Übersetzung
+
+### Requirement: Nachweisbarer Instant Compile
+Die IDE-Übersetzung SHALL das bestehende Release-Budget von unter 50 ms für das Referenz-Einzelmodul und unter 1 s für das ungefähr 50.000-Zeilen-Referenzprojekt auf dokumentierter Referenzhardware einhalten. Messungen SHALL vollständigen Compile und Änderungen mit Cache einschließlich Invalidierung und Link getrennt ausweisen.
+
+#### Scenario: Reproduzierbare Messung
+- **WHEN** der Release-Benchmark auf der ausgewiesenen Referenzhardware ausgeführt wird
+- **THEN** nennt er Hardware, Profil, Projektgröße, vollständige und inkrementelle Dauer sowie neu übersetzte Module und bewertet beide bestehenden Zeitgrenzen

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/tasks.md

@@ -0,0 +1,26 @@
+## 1. Editor und Navigation
+
+- [ ] 1.1 Den Texteditor auf dem Dokumentmodell aus 01 integrieren; Tests mit Unicode, Tabs, Zeilenumbrüchen, Einfügen/Überschreiben, Auswahl und Undo belegen korrekten Text und Cursor.
+- [ ] 1.2 CUA-, Wort-/Seitennavigation, Ctrl+Y und die spezifizierten WordStar-Chords/Lesezeichen anbinden; eingespeiste Tastenfolgen prüfen auch abgebrochene Chords und Mehrfenster-Kopieren.
+- [ ] 1.3 Find, Selected Text, F3 und Change mit Einzel-/Gesamtersetzung implementieren; Tests prüfen Wortgrenzen, Suchrichtung, Großschreibung, Rücksprung, leere Ersetzung und gemeinsames Undo.
+- [ ] 1.4 Prozedurauswahl und Shift+F2/Ctrl+F2 sowie Include-Ansichten umsetzen; Navigationstests treffen physische Dateien und verhindern Speichern einer Expansion als Ursprungsdatei.
+
+## 2. Prüfung und Quelltextpflege
+
+- [ ] 2.1 Token-/Spanneninformationen des vorhandenen Frontends für semantikerhaltende Zeilennormalisierung verwenden; Tests belegen Idempotenz und erhalten Strings, Kommentare, DATA, Bezeichner und Typ-Suffixe.
+- [ ] 2.2 Line Leave an Syntax Checking und Diagnoseanzeige anbinden; Eingabetests unterscheiden unfertige SUB-/IF-Blöcke von echten Fehlern und belegen das deaktivierte Verhalten.
+- [ ] 2.3 New Sub/New Function mit Namenprüfung und wirksamer DEFtype-Übernahme implementieren; erzeugte Quellen müssen über den bestehenden Compiler gültig sein.
+- [ ] 2.4 DECLARE-Erzeugung/-Aktualisierung in den gemeinsamen Speicherhook aufnehmen; Tests belegen wiederholtes Speichern ohne Änderungen, Handdeklarationskonflikte, unverändertes Speichern unfertiger Entwürfe und denselben Weg für FRM-Code.
+
+## 3. Inkrementeller Compiler
+
+- [ ] 3.1 Den Projektcompiler in wiederverwendbare Parse-/Modulcompile-/Link-Schritte zerlegen und den bisherigen Vollcompile darüber erhalten; bestehende Compiler-/CLI-Regressionen bleiben grün.
+- [ ] 3.2 Modulcache mit Dokument-/Include-Revisionssatz und Import-/Exportsignaturen einführen; Zählertests belegen Wiederverwendung unveränderter Module nach privater Rumpfänderung.
+- [ ] 3.3 Transitive Invalidierung für CONST, TYPE, COMMON, DECLARE und Includes umsetzen; Differentialtests mit Änderungen und gelöschten Symbolen liefern dieselben Diagnosen wie ein frischer Compile.
+- [ ] 3.4 Forms-Struktur, Modulreihenfolge und sämtliche beim Link remappten Identitäten berücksichtigen; Tests vergleichen umgeordnete Module, Control-Arrays, DATA und Prozedurverweise mit dem Vollcompile.
+- [ ] 3.5 Fehlerzustände und Ergebnisrevisionen an den Editor anbinden; ein Test mit gültig→fehlerhaft→gültig belegt, dass niemals ein veraltetes Ergebnis als aktueller Stand startet.
+
+## 4. Leistung und Abnahme
+
+- [ ] 4.1 Die vorhandenen Release-Compile-Benchmarks um Änderungen mit Cache einschließlich Invalidierung/Link ergänzen; dokumentierte Messungen prüfen Einzelmodul unter 50 ms und Referenzprojekt unter 1 s sowie tatsächlich neu übersetzte Module.
+- [ ] 4.2 Editor-/Compilerbedienung und Cachegrenzen in docs erläutern und alle Szenarien in verification.md zuordnen; relevante Frontend-, VM-, CLI- und IDE-Tests sowie Formatprüfung müssen bestehen.

openspec/changes/phase-5-04-ausfuehrung-und-output/.openspec.yaml

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

openspec/changes/phase-5-04-ausfuehrung-und-output/design.md

@@ -0,0 +1,31 @@
+## Context
+
+`Vm::run` und `run_visible_forms` laufen synchron bis zu einem RunEvent; Host-Warten und mehrere Eingabe-/Dialog-Builtins blockieren. VM-Werte verwenden Rc und sind nicht Send. Der CLI-Runner baut bei RUN eine frische VM. `ScreenWidget` prüft bisher auch seine Zeichenfläche gegen 80×25. BASIC-SHELL startet aktuell direkt ein Kind mit geerbter Standard-I/O. Diese Pfade müssen gemeinsam integriert werden; nur F5 an `run` zu hängen würde die IDE blockieren.
+
+## Goals / Non-Goals
+
+**Goals:** Eine weiter bedienbare IDE, fortsetzbare Runtime-Zustände und gemeinsamer Reset; unveränderte CLI-Semantik ohne aktivierte IDE-Steuerung.
+
+**Non-Goals:** Zweite VM, native Prozesse als BASIC-Ausführung, unsafe Send, generische Task-Runtime, VM-Worker pro Fenster oder Live-Patching.
+
+## Decisions
+
+1. **Kooperatives Treiben im selben Prozess und Thread:** VM-Ausführung erhält eine begrenzte Poll-/Slice-Schnittstelle, die an sicheren Anweisungsgrenzen Yield melden kann. Yield ist kein Step und kein Breakpoint. Die UI verarbeitet danach Ereignisse und rendert. Bestehendes `run` treibt denselben Mechanismus für die CLI bis zum bisherigen RunEvent weiter. Ein fester Anweisungszähler reicht für das Slice-Budget; es wird keine Zeitabfrage pro Opcode und kein neuer Clock-Zugriff im bisherigen trapfreien Fastpath eingeführt.
+2. **Blockierende Runtime-Pfade gehören ausdrücklich zur Umsetzung:** INPUT/LINE INPUT, INPUT$, SLEEP, Modal-Forms/MSGBOX/INPUTBOX und die sichtbare Forms-Schleife erhalten bei IDE-Betrieb fortsetzbare Wartezustände. Bereits gelesene Zeichen, Prompt, Stackargumente, Deadline und Return-Ziel bleiben gespeichert. Erneutes Polling führt weder den Builtin-Aufruf noch seine Nebenwirkungen von vorne aus. Bei CLI-Betrieb wird der Zustand intern weitergetrieben. Nur den Host mit einem Timeout zu versehen oder einen beliebigen Fehler als „Pause“ zu verwenden genügt nicht. Das verhindert eine zusätzliche Worker-/Debug-Synchronisation mit nicht-Send-Werten.
+3. Die Sitzung unterscheidet Bearbeitung, Übersetzen, Laufend, Wartend, Angehalten und Beendet/Fehler. Ein Lauf trägt Kompilatrevision und separates Laufziel. Ctrl+Break und der IDE-Unterbrechen-Befehl wirken auch bei Editorfokus; Ctrl+C kopiert dort, unterbricht aber bei Output-Fokus. Pause aus einer ausstehenden Eingabe zeigt deren Quellstelle; Continue führt die gespeicherte Operation weiter. Während eines laufenden Programms haben Modifikation/Neustart klare Übergänge, keine zweite parallele Sitzung.
+4. Gemeinsame Reset-/Laufzielhelfer werden aus `run_chain`/`run_target` gezogen. RUN verwirft die alte VM und Runtime, nicht die bearbeiteten IDE-Dokumente. Bei gleichem Ziel wird dessen aktueller zulässiger Dokumentstand gemäß gewählter Neustartentscheidung übersetzt; fremde RUN-Ziele benutzen denselben Loader und eigene Laufquellen. Breakpoints können nach Neustart neu gebunden werden; Frames und Watchwerte werden nie übernommen.
+5. Die optionale Startdatei aus 01 ordnet beim Compile das ausgewählte Modul zuerst und die anderen stabil danach. Explizites FRM wird `startup_form`, explizites BAS setzt kein automatisches Startformular. Ohne Metadaten bleibt das jetzige Verhalten (Modulreihenfolge, erstes Formular) erhalten. Diese Regel liegt im gemeinsamen Projektcompiler, damit CLI, IDE und geschriebenes TBC übereinstimmen; der vorhandene TBC-Container kann die Startformular-ID bereits speichern.
+6. `TextScreen` bleibt die einzige Programmausgabe. Die physische Mindestgrößenprüfung gehört in den Terminalrahmen; eine Output-Ansicht rendert Ausschnitt/Scrollposition. Nur tatsächliches Resize ändert Runtime-Geometrie über den vorhandenen Hostpfad. F4 verändert ausschließlich die Ansicht. IDE-Thema und BASIC-Farben werden nicht vermischt.
+7. Shell ist eine kontrollierte Terminalübergabe: Ausführung pausiert, Guard gibt Raw/Alternate-Screen/Mouse ab, Kind läuft mit normaler Standard-I/O, danach werden Terminal und Fokus wiederhergestellt. Ein kleiner Host-Einstieg ermöglicht dieselbe Übergabe für BASIC-SHELL; die CLI behält ihren Exit-Code-Vertrag. Während interaktiver Shell gehört das Terminal dem Kind, das ist kein weiterlaufender IDE-Dialog. Benutzerabbruch muss Kindbeendigung und Terminalrückgabe durchlaufen; es werden keine Prozesse losgelöst hinterlassen.
+8. File→Print ist eine dokumentierte Plattformanpassung: Dialog für Quelltext/Selektion, Ziel UTF-8-Textdatei, Standard LPT1.TXT passend zum bisherigen Druckerpfad. Kein Hardwaredruckertreiber. Datei- und Überschreibschutz verwenden 01.
+
+## Risks / Trade-offs
+
+- Eine übersehene blockierende Operation friert weiter ein → alle Host-Warteaufrufe und deren Builtin-Aufrufer inventarisieren, repräsentative Eingabe-, Schlaf- und Modalpfade über echten App-Eventweg testen.
+- Fortsetzbare Operationen verlieren Stack oder wiederholen I/O → dedizierte Suspend/Resume-Tests mit teilweise gelesener Eingabe, Timer und Fehlerhandler; CLI-Vergleich derselben Ereignisfolge.
+- Kooperative Grenzen unterbrechen kein beliebiges blockierendes Betriebssystem-Datei-I/O → Eingabe-/Timer-/Forms-Warten wird resumierbar; reale synchrone Dateioperationen behalten ihre bisherige Semantik. Keine Zusage harter Echtzeitunterbrechung fremder Systemaufrufe.
+- VM-Umbau verändert Ereignis- oder Fehlersemantik → komplette vorhandene VM-/Runtime-/Forms-Regressionen plus GUI-freier CLI-Vergleich. Scheduling-Yield und Debug-Step strikt trennen.
+
+## Migration Plan
+
+Poll-Pfad neben den bisherigen Run-Einstieg setzen, dann dessen interne Schleife darüber führen. Jeder wartende Builtin wird zusammen mit seinem Fortsetzungstest umgestellt. CLI-Ausgabe/Exit-Codes bleiben die Vergleichsreferenz. Es wird kein neues Bytecode-Dateiformat benötigt; Laufzustände sind ausschließlich im Speicher.

openspec/changes/phase-5-04-ausfuehrung-und-output/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Die VM kann laufen und anhalten, der CLI-Runner besitzt aber den Terminalhost und den Neustartpfad. Die IDE braucht eine fortsetzbare Sitzung mit eigener Eingabeverteilung und Ausgabe, ohne die Laufzeitsemantik zu verändern.
+
+## What Changes
+
+- Start, Unterbrechen, Fortsetzen, Neustart, COMMAND$ und Startdatei mit derselben TBVM; STOP hält in der IDE an.
+- RUN innerhalb eines Programms nutzt denselben vollständigen Reset wie IDE-Neustart, einschließlich Wechsel des Laufziels.
+- Bedienbare IDE während Rechenschleifen, Eingabewarten und Forms-Ereignissen; kontrollierter Lebenszyklus von VM und Terminal.
+- Output-Fenster und F4-Vollbildansicht, File→Shell und BASIC-SHELL mit Terminalübergabe sowie File→Print als kontrollierte Textausgabe.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-ausfuehrung`: Start, Unterbrechen, Fortsetzen, Neustart, COMMAND$ und Startdatei mit derselben TBVM; STOP hält in der IDE an.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Sitzung, tb-vm/interp.rs, CLI-run_chain, tb-runtime/host.rs und builtins.rs sowie tb-ui/host.rs und screen.rs. Vorhandene Ereignisse, TextScreen und CLI-Ausführung bleiben die Grundlage.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/proposal.md), [phase-5-03-editor-und-inkrementelle-uebersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/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-04-ausfuehrung-und-output/specs/ide-ausfuehrung/spec.md

@@ -0,0 +1,59 @@
+## Purpose
+
+Führt bearbeitete Projekte innerhalb der IDE mit derselben TBVM wie die CLI aus und erhält dabei verlässliche Unterbrechung, Ausgabe und Terminalbedienung.
+
+## ADDED Requirements
+
+### Requirement: Start und revisionsgebundene Sitzung
+Shift+F5/Start SHALL den aktuellen gültigen Projektstand mit gewähltem COMMAND$ in einer frischen Sitzung starten. Eine explizite Startdatei SHALL als erstes Modul ausgeführt werden; übrige Modulrümpfe folgen in ihrer relativen Projektreihenfolge. Ist die explizite Startdatei ein Formular, SHALL dieses das Startformular sein; bei explizitem BAS-Start SHALL kein Formular allein aufgrund seiner Projektmitgliedschaft automatisch gestartet werden. Ohne Auswahl SHALL die bisherige CLI-Semantik gelten. Kompilierfehler MUST einen neuen Lauf verhindern.
+
+#### Scenario: Startauswahl in IDE und CLI
+- **WHEN** dasselbe gespeicherte Projekt mit expliziter BAS- oder FRM-Startdatei in IDE und CLI gestartet wird
+- **THEN** stimmen Modulreihenfolge, initial sichtbare Formulare und COMMAND$ überein
+
+#### Scenario: Änderung während einer Pause
+- **WHEN** Quelltext einer pausierten Sitzung geändert wird und Continue gewählt wird
+- **THEN** verlangt die IDE einen Neustart oder die ausdrückliche Fortsetzung des gekennzeichneten alten Stands; sie ersetzt keinen laufenden Code unbemerkt
+
+### Requirement: Unterbrechen und Fortsetzen
+Die IDE SHALL laufende Rechenschleifen, Forms-Ereignisverarbeitung und Eingabewarten kontrolliert unterbrechen können. Ctrl+Break, Strg+C in der Programmausgabe und ein Unterbrechen-Befehl SHALL den Break-Modus an einer sicheren Grenze aktivieren. F5/Continue SHALL den erhaltenen VM-Zustand fortsetzen. STOP SHALL in der IDE pausieren; END und SYSTEM SHALL die Sitzung beenden und die IDE offen lassen. Der CLI-STOP-Vertrag SHALL unverändert bleiben.
+
+#### Scenario: Abbruch während INPUT
+- **WHEN** ein Programm auf INPUT wartet und der Benutzer unterbricht
+- **THEN** reagiert die IDE ohne zusätzliche BASIC-Eingabe, zeigt die Unterbrechungsstelle und kann die ausstehende Eingabe beim Fortsetzen ohne doppelte Nebenwirkungen weiterführen
+
+#### Scenario: Enge Schleife und Formular
+- **WHEN** ein Programm in einer leeren Schleife oder einer sichtbaren Form auf Ereignisse wartet
+- **THEN** bleiben Output-Umschaltung und Unterbrechen bedienbar und ein Fortsetzen erhält Variablen und Formularzustand
+
+### Requirement: Einheitlicher Reset und RUN
+Restart und BASIC-RUN SHALL denselben vollständigen Sitzungsreset nutzen: Variablen, Frames, DATA-Zeiger, Fehler-/Trapzustand, Forms, Timer, Laufzeithandles und Ausgabezustand werden wie bei einem frischen Lauf neu aufgebaut. RUN mit Ziel SHALL die bestehende relative Zielauflösung und optionale Startzeile behalten. Ein fehlendes oder ungültiges Ziel SHALL eine Diagnose liefern und die IDE sowie bearbeitete Dokumente erhalten. BASIC-RUN zu einem anderen Ziel SHALL das bearbeitete IDE-Projekt nicht ersetzen.
+
+#### Scenario: Wiederholter Neustart
+- **WHEN** ein Programm Variablen, Dateien und Timer verändert und danach mehrfach neu startet
+- **THEN** beginnt jeder Lauf mit den spezifizierten Anfangswerten und es bleiben keine alten Timer, Dateihandles oder parallelen Sitzungen zurück
+
+### Requirement: Output-Fenster und Vollbild
+Window→Output und F4 SHALL denselben Programmbildschirm als Fenster beziehungsweise Vollbild zeigen. Eine kleinere Fensteransicht SHALL den Bildschirm abschneiden oder scrollen und MUST NOT allein durch den Ansichtswechsel die für BASIC sichtbaren Bildschirmmaße ändern. Echte Terminalgrößenänderungen SHALL über den vorhandenen Laufzeitpfad zugestellt werden. Nach Programmende SHALL die letzte Ausgabe sichtbar bleiben.
+
+#### Scenario: Kleines Ausgabefenster
+- **WHEN** auf einem ausreichend großen Terminal ein Output-Fenster kleiner als 80×25 dargestellt und mit F4 umgeschaltet wird
+- **THEN** bleiben Programminhalt und logische Laufzeitgröße erhalten; im kleinen Fenster erscheint die Ausgabe statt des Terminal-Mindestgrößenhinweises
+
+### Requirement: Eigentum an Eingaben und Beenden
+Eine Taste oder Mausaktion SHALL genau einmal dem aktiven IDE-Kontext oder dem laufenden Programm zugestellt werden. IDE-eigene Steueraktionen MUST NOT zusätzlich in BASIC-Eingabepuffern landen. IDE-Ende und Neustart SHALL die bisherige Sitzung kontrolliert beenden, bevor Terminalressourcen freigegeben oder eine neue Sitzung gestartet werden.
+
+#### Scenario: Copy und Programmeingabe
+- **WHEN** Ctrl+C bei Editorfokus und danach ein normales Zeichen bei Programmfokus eingegeben wird
+- **THEN** kopiert die erste Aktion nur im Editor und die zweite erreicht genau einmal das BASIC-Programm
+
+### Requirement: Shell und Druckausgabe
+File→Shell und BASIC-SHELL SHALL für ein interaktives Kindprogramm den Terminalmodus kontrolliert abgeben und anschließend die IDE wiederherstellen; BASIC-SHELLFN SHALL den bisherigen Exit-Code-Vertrag behalten. File→Print SHALL Auswahl oder gesamten aktiven Quelltext über einen Dialog in eine wählbare UTF-8-Druckdatei ausgeben und Fehler sichtbar machen. Dies SHALL keine Druckerhardware voraussetzen und als Plattformanpassung dokumentiert sein.
+
+#### Scenario: Shell kehrt zurück
+- **WHEN** ein Shell-Kommando regulär, mit Fehler oder durch Benutzerabbruch endet
+- **THEN** sind Terminal und IDE-Fokus wiederhergestellt und das Programm erhält den passenden bestehenden Rückgabewert beziehungsweise Fehler
+
+#### Scenario: Druckziel nicht schreibbar
+- **WHEN** File→Print ein unbeschreibbares Ziel erhält
+- **THEN** erscheint eine Dateidiagnose und Quelltext sowie bestehende Zieldatei bleiben erhalten

openspec/changes/phase-5-04-ausfuehrung-und-output/tasks.md

@@ -0,0 +1,27 @@
+## 1. Fortsetzbare Ausführung
+
+- [ ] 1.1 Einen begrenzten VM-Pollpfad mit eigenem Yield-Zustand ergänzen und run darüber treiben; Tests belegen Unterbrechbarkeit leerer Schleifen, unveränderte RunEvents und keine zusätzlichen Clock-Abfragen im trapfreien Standardlauf.
+- [ ] 1.2 INPUT/LINE INPUT einschließlich teilweise gelesener Eingabe als fortsetzbare Operation modellieren; Pause/Resume-Tests belegen einmaligen Prompt, erhaltenen Stack und keine doppelten Zuweisungen.
+- [ ] 1.3 INPUT$ und SLEEP an fortsetzbare Eingabe-/Deadline-Zustände anbinden; Tests belegen Zeichenreste, Timeout und Pause ohne wiederholte Nebenwirkungen.
+- [ ] 1.4 MSGBOX, INPUTBOX, modales SHOW und die sichtbare Forms-Schleife kooperativ treiben; Tests belegen Unterbrechen/Fortsetzen einschließlich Timer-, Fokus- und Handlerzustand.
+- [ ] 1.5 Alle weiteren Host-Warteaufrufer gegen den Pollpfad abgleichen und eine konkrete Liste in verification.md führen; jede wartende Operation besitzt einen Fortsetzungsnachweis oder eine dokumentierte synchrone Betriebssystemgrenze.
+
+## 2. IDE-Sitzung und gemeinsamer Reset
+
+- [ ] 2.1 Die Sitzungszustände und aktuellen Kompilatrevisionen an Start/Continue/Unterbrechen anbinden; App-Eventtests prüfen F5/Shift+F5/Ctrl+Break und die explizite Wahl bei Quelländerung im Break-Modus.
+- [ ] 2.2 STOP, END, SYSTEM und Fehler auf IDE-Zustände abbilden; Tests bestätigen Pause bei STOP, offene IDE nach Ende und unveränderte CLI-Exit-Codes.
+- [ ] 2.3 Explizite Startup-Auswahl aus 01 im gemeinsamen Compiler umsetzen; IDE-/CLI-/TBC-Tests belegen BAS ohne implizites Startformular, ausgewähltes FRM und unverändertes Verhalten alter MAK-Dateien.
+- [ ] 2.4 run_target/run_chain-Reset wiederverwenden und IDE-Restart/BASIC-RUN anschließen; Tests belegen neue VM/Runtime, relative Fremdziele, Startzeile und Erhalt des bearbeiteten Projekts bei fehlendem Ziel.
+- [ ] 2.5 COMMAND$-Dialog und kontrolliertes Sitzungsende implementieren; wiederholte Starts/Resets prüfen Argumente sowie fehlende alte Timer, Handles und ausstehende Aktionen.
+
+## 3. Terminal und Ausgabe
+
+- [ ] 3.1 IDE-/Programmeingaben über den Dispatcher aus 02 exklusiv zustellen; Eventtests prüfen Copy bei Editorfokus, Break bei Outputfokus und normale BASIC-Tasten genau einmal.
+- [ ] 3.2 Output-Fenster und F4-Vollbild auf demselben TextScreen darstellen und die physische Mindestgrößenprüfung vom Viewport lösen; Snapshots prüfen kleine Output-Fenster, echtes Resize und erhaltene Endausgabe.
+- [ ] 3.3 Terminalübergabe für File→Shell und BASIC-SHELL über einen gemeinsamen Hostpfad implementieren; kontrollierte Kindprozess-Tests prüfen Erfolg, Exit-Code, Benutzerabbruch und Terminalwiederherstellung.
+- [ ] 3.4 File→Print mit Auswahl/Gesamttext und UTF-8-Zieldatei an die geschützte Dateiausgabe aus 01 binden; Tests belegen Inhalt, Überschreibentscheidung und Schreibfehler ohne Datenverlust.
+
+## 4. Gemeinsame Regression und Dokumentation
+
+- [ ] 4.1 IDE- und CLI-Läufe mit identischem Input-/Zeit-/Forms-Skript vergleichen; vorhandene VM-, Fehlerhandler-, Runtime-, Forms- und CLI-Regressionen müssen nach dem Poll-Umbau bestehen.
+- [ ] 4.2 Sitzungsübergänge, Startup-Metadatenwirkung, Shell-/Druckanpassung und Unterbrechungsgrenzen dokumentieren; verification.md ordnet alle Spec-Szenarien den ausgeführten Nachweisen zu und Format-/Clippy-Prüfung besteht.

openspec/changes/phase-5-05-formular-designer/.openspec.yaml

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

openspec/changes/phase-5-05-formular-designer/design.md

@@ -0,0 +1,30 @@
+## Context
+
+`tb_ui::frm::FormFile`/`FormNode` enthalten Klassen, Eigenschaften, Kinder und Code. Der Writer erhält unveränderte Eingaben und kanonisiert geänderte Formulare; `Index = 0` ist strukturell relevant. Frontend-Forms-Metadaten kennen Klassen, Properties und Ereignissignaturen. Die Runtime kennt FormsModel und TextScreen. Der Designer nutzt die Dokumentaktionen aus 01, Fenster aus 02 und Codeoperationen aus 03.
+
+## Goals / Non-Goals
+
+**Goals:** Dasselbe gespeicherte Formular führt zu derselben Runtime-Struktur; alle Designaktionen lassen sich ohne Programmausführung prüfen.
+
+**Non-Goals:** Neuer FRM-Parser, zweite Property-Datenbank, eigenes Layoutformat, Ausführen von Load/Click/Timer in der Vorschau.
+
+## Decisions
+
+1. Der Designer bearbeitet den vorhandenen FormFile-Baum. Editor und Designer teilen das Dokument, nicht nur gelegentlich synchronisierte Kopien. Stabile editorinterne Objektidentitäten werden nicht aus flüchtigen Runtime-Katalog-IDs abgeleitet. Der Compile-Katalog wird aus dem jeweiligen Baum neu erzeugt; ein reiner Wertwechsel und ein struktureller Wechsel invalidieren den Cache aus 03 entsprechend.
+2. Eine isolierte Preview-FormsModel-Instanz wird aus dem Dokument aufgebaut und auf TextScreen gerendert. Ihre Aufgabe ist ausschließlich Geometrie/Darstellung; VM-Callbacks und Timer sind nicht aktiv. Auswahlrahmen, Raster und Handles legt die IDE darüber. Vorhandene Berechnung von Containerkoordinaten und Control-Defaults wird wiederverwendet; Runtime-Fokus-/Hit-Test darf Designer-Auswahl nicht verschlucken.
+3. Toolbox, Properties und Event-Auswahl werden aus vorhandenen Klassen-/Property-/Event-Metadaten abgeleitet. Dazu gehören auch bereits ergänzte Spinvarianten; die kürzere historische Toolbox-Liste darf unterstützte Klassen nicht still ausschließen. Timer erhält eine sichtbare Designmarke, obwohl er zur Laufzeit unsichtbar ist. Ein Tabellen-Test bindet jede designfähige Klasse an einen Platzier-/Persistenznachweis.
+4. Drag, Größenänderung, Mehrfachaktionen, Propertyedit und Menüumordnung sind Dokumenttransaktionen mit gemeinsamem Undo. Geometrie wird vor Commit gegen Container und gültige Wertebereiche geprüft. Text- und Control-Zwischenablage unterscheiden sich durch den aktiven Modus; Copy/Paste eines Containers nimmt seine Kinder mit. Einfügen vergibt konfliktfreie Namen/Indizes.
+5. Properties Bar folgt der Referenz: F2 auf Value, F10 Menü/Properties, keine Statuszeile. Menüdesigner und Palette sind konkrete Kindfenster des Rahmens. Supported-Shortcut-Liste kommt aus den vorhandenen Forms-Verträgen; bekannte nicht unterstützte Importwerte werden nicht als gültige Wahl angeboten. Menu.Caption, Indent/Outdent, Reihenfolge, Index und Flags bleiben direkt im FormNode-Baum.
+6. F12 erzeugt Code mit der vorhandenen Ereignissignatur einschließlich BYREF-/Typ- und Indexparametern. Vorhandene Handler werden parsergestützt gesucht, nicht durch bloße Teilstrings. Neue Handler verwenden den Prozedurerzeugungsweg aus 03. Beim Umbenennen werden gebundene Namen und sicher aufgelöste Objektverweise in allen betroffenen Projektdokumenten als eine Transaktion geändert; bei Konflikt oder unklaren betroffenen Referenzen wird vollständig abgebrochen. Ungebundener alter Code wird bei Löschen als solcher erkennbar erhalten, nicht automatisch entfernt.
+7. Designer→Code→Designer und Save/Reopen verwenden dieselbe FRM-Ausgabe aus 01. Binärimporte benötigen einen Text-Zielpfad. Das gespeicherte Ergebnis wird zusätzlich vom bestehenden CLI-Compiler geladen, damit Preview-Erfolg keinen fehlerhaften FRM-Export verdeckt.
+
+## Risks / Trade-offs
+
+- Baumänderung verschiebt Katalog-IDs → editorinterne Identität separat, Katalog neu bilden; keine gespeicherten Runtime-Indizes als Editorreferenz.
+- Rename beschädigt Code → token-/symbolgebundene Änderungen, Konfliktabbruch ohne Teiländerungen; keine globale String-Ersetzung.
+- Vorschau führt Programmcode aus → nur Forms-Darstellung ohne VM; Test mit Load-/Timer-Handlern, deren Nebenwirkung ausbleiben muss.
+- Preview und Runtime laufen auseinander → Save/Reopen plus Runtime-Rendervergleich für dasselbe Formular; Runtime-Nachweis im Integrationschange 08.
+
+## Migration Plan
+
+Designeraktionen bauen auf bestehenden Formaten auf; keine Formatmigration. Unveränderte Formulare behalten ihre Originalausgabe, geänderte die bestehenden kanonischen Regeln. Umsetzung ist nach 01–03 möglich; der gemeinsame Run-Arbeitsablauf wird nach 04 in 08 abgenommen.

openspec/changes/phase-5-05-formular-designer/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+FormFile, Klassenmetadaten und Forms-Rendering existieren, aber Formulare können noch nicht in der IDE gestaltet werden. Der Designer soll dieselbe FRM-Struktur bearbeiten, die Compiler und Laufzeit bereits verstehen.
+
+## What Changes
+
+- Integrierter Designer mit Toolbox/Tools, Platzieren, Auswahl, Verschieben, Skalieren, Raster und Undo.
+- Properties Bar, Menüdesigner und Farbpalette gemäß IDE-Referenz; alle unterstützten Designzeit-Controlklassen einschließlich Arrays.
+- Gemeinsames Formulardokument für Designer und Code, sichere Namen-/Containeränderungen und persistente FRM-Ausgabe.
+- F12/Event Procedures und Shift+F12/Form mit signaturgerechter Ereignisprozedur-Erzeugung und Navigation.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-formulardesigner`: Integrierter Designer mit Toolbox/Tools, Platzieren, Auswahl, Verschieben, Skalieren, Raster und Undo.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Designer, vorhandenes tb-ui::frm::FormFile, FormsModel und tb-frontend-Forms-Metadaten. Keine zweite FRM-Implementierung und keine Programmausführung als Designvorschau.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/proposal.md), [phase-5-03-editor-und-inkrementelle-uebersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/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-05-formular-designer/specs/ide-formulardesigner/spec.md

@@ -0,0 +1,47 @@
+## Purpose
+
+Ermöglicht das visuelle Erstellen und Bearbeiten der bestehenden Formular- und Controlmodelle mit gemeinsamem Ereigniscode und kompatibler FRM-Persistenz.
+
+## ADDED Requirements
+
+### Requirement: Designfläche und vollständige Toolbox
+Der Designer SHALL Formularfläche, Toolbox und gleichwertiges Tools-Menü anbieten. Alle in den bestehenden Forms-Metadaten unterstützten Designzeit-Controlklassen SHALL platzierbar sein, einschließlich Datei-/Verzeichnis-/Laufwerkslisten, Timer, Container, Scroll- und Spin-Controls. Werkzeugwahl mit Aufziehen und Toolbox-Doppelklick SHALL neue Controls mit gültigen Defaults und eindeutigen Namen erzeugen. Die Designvorschau MUST NOT Ereigniscode oder Laufzeittimer ausführen.
+
+#### Scenario: Jede Controlklasse
+- **WHEN** jede unterstützte Designzeitklasse einmal aus Toolbox oder Tools eingefügt wird
+- **THEN** entsteht ein gültiger Eintrag im Formulardokument und nach Speichern/Wiederöffnen dieselbe Klasse mit ihren Eigenschaften
+
+### Requirement: Auswahl und Geometrie
+Ausgewählte Controls SHALL Sizing Handles zeigen. Drag SHALL verschieben und Handles SHALL skalieren; Pfeile SHALL um eine Zelle, Ctrl+Pfeile um fünf Zellen und Shift+Pfeile die Größe ändern. Tab/Shift+Tab SHALL die Controlauswahl wechseln, Ctrl+Klick SHALL eine Mehrfachauswahl bilden, Grid Lines SHALL das Raster umschalten. Koordinaten SHALL sich auf den tatsächlichen Container beziehen und ungültige Größen SHALL ohne Dokumentbeschädigung abgewiesen werden.
+
+#### Scenario: Container und Mehrfachauswahl
+- **WHEN** mehrere Controls innerhalb eines Frame ausgewählt und per Tastatur verschoben werden
+- **THEN** ändern sich ihre relativen Positionen um denselben Betrag, andere Controls bleiben unverändert und Undo stellt die gesamte Aktion zurück
+
+### Requirement: Properties Bar und Bearbeitungsaktionen
+Die Properties Bar SHALL Property-/Value-Auswahl, Spalte/Zeile und Breite/Höhe anzeigen. F2 SHALL die Value-Box fokussieren und F10 zwischen Menüleiste und Properties Bar wechseln. Im Designer SHALL keine Statuszeile erscheinen. Edit→Cut/Copy/Paste/Clear/Undo SHALL auf die ausgewählten Controls wirken und beim Einfügen gültige Namen, Eltern und Array-Indizes herstellen. Klassenabhängige Propertytypen, Wertebereiche und schreibgeschützte Eigenschaften SHALL berücksichtigt werden.
+
+#### Scenario: Ungültige Eigenschaft
+- **WHEN** eine Eigenschaft außerhalb ihres gültigen Bereichs oder mit falschem Typ eingegeben wird
+- **THEN** bleibt ihr alter Wert erhalten und die Fehlermeldung benennt Control und Eigenschaft
+
+### Requirement: Menüdesigner und Farbpalette
+Menu Design Window SHALL Caption mit Access-Key/Separator, CtlName, Tag, Index, Checked, Enabled, Visible, Separator und unterstützte Shortcuts bearbeiten. Einfügen, Löschen, Ebene und Reihenfolge SHALL die Menühierarchie konsistent ändern. Color Palette SHALL ForeColor/BackColor und das Auftragen auf die Form unterstützen. Window SHALL Toolbox, Color Palette, Menu Design Window, Help und die Formliste bedienen.
+
+#### Scenario: Menü mit Array und Untermenü
+- **WHEN** ein Untermenü mit Access-Key und ein indiziertes Menüelement erstellt, umgeordnet und gespeichert werden
+- **THEN** bleiben Hierarchie, Reihenfolge, Index, Shortcut und Darstellung nach Wiederöffnen und Kompilieren erhalten
+
+### Requirement: Dokumentkonsistenz und Umbenennen
+Designer und Code SHALL dasselbe FRM-Dokument ändern. Änderungen an Formularstruktur, Properties und Code SHALL gemeinsam gespeichert und rückgängig gemacht werden können. Control-/Form-Umbenennen SHALL gebundene Ereignisnamen und eindeutig auflösbare Codeverweise anpassen; Namenskonflikte oder nicht sicher auflösbare betroffene Verweise SHALL die Umbenennung ohne Teiländerung verhindern. Löschen SHALL vorhandenen Code nicht stillschweigend entfernen.
+
+#### Scenario: Umbenennen mit Ereigniscode
+- **WHEN** ein Button mit Click-Prozedur umbenannt wird
+- **THEN** sind Control, Handler und eindeutig gebundene Verweise konsistent umbenannt; Undo stellt alle betroffenen Teile gemeinsam wieder her
+
+### Requirement: Ereignisprozeduren und Moduswechsel
+F12/Event Procedures SHALL Objekt und zulässiges Ereignis wählen und die vorhandene passende Prozedur öffnen oder genau eine Prozedur mit der dokumentierten Signatur erzeugen. Control-Arrays SHALL die richtigen Indexparameter erhalten. Shift+F12/View→Form SHALL zum zugehörigen Formular und Control zurückkehren. Der Wechsel MUST ungespeicherte Änderungen erhalten.
+
+#### Scenario: Ereignis zweimal öffnen
+- **WHEN** das Click-Ereignis eines Control-Arrays zweimal über F12 geöffnet wird
+- **THEN** existiert genau eine signaturgerechte Prozedur mit Indexparameter und beide Aufrufe führen dorthin

openspec/changes/phase-5-05-formular-designer/tasks.md

@@ -0,0 +1,20 @@
+## 1. Designmodell und Vorschau
+
+- [ ] 1.1 Den FormFile-Dokumentbaum aus 01 mit stabilen Designobjekt-IDs an einen isolierten Preview-FormsModel/TextScreen anbinden; Tests belegen identische Geometrie und ausbleibende Load-/Timer-Nebenwirkungen.
+- [ ] 1.2 Toolbox und Tools-Menü aus den vorhandenen Klassenmetadaten ableiten und Platzieren per Doppelklick/Aufziehen umsetzen; ein tabellarischer Test erzeugt jede unterstützte Designzeitklasse einschließlich Spinvarianten und Timer.
+- [ ] 1.3 Auswahl, Tab-Reihenfolge, Ctrl+Klick-Mehrfachauswahl, Drag, Handles und Raster implementieren; Maus-/Tastentests belegen Containerkoordinaten sowie 1-/5-Zellen-Schritte und Shift-Skalierung.
+
+## 2. Eigenschaften und strukturierte Änderungen
+
+- [ ] 2.1 Properties Bar mit F2-/F10-Fokus und typisierter Propertybearbeitung implementieren; Tests prüfen gültige/ungültige Werte, sichtbare Koordinaten und fehlende Designer-Statuszeile.
+- [ ] 2.2 Control-Cut/Copy/Paste/Clear und Undo über gemeinsame Dokumenttransaktionen umsetzen; Tests belegen Containerkinder, konfliktfreie Namen/Array-Indizes und vollständige Rücknahme einer Mehrfachaktion.
+- [ ] 2.3 Den Menüdesigner für Caption, CtlName, Tag, Index, Flags, Shortcut, Ebenen und Reihenfolge implementieren; ein FRM-Roundtrip prüft Access-Keys, Separatoren und indizierte Untermenüs.
+- [ ] 2.4 Color Palette und Designer-Window-Befehle anbinden; Eventtests prüfen Fore-/BackColor-Auftrag, Werkzeugfenster und Formauswahl.
+- [ ] 2.5 Form-/Control-Umbenennung über gebundene Codeverweise transaktional ausführen und Löschfolgen sichtbar machen; Tests belegen Handleranpassung, konfliktbedingten Gesamtabbruch und Erhalt vorhandenen Codes.
+
+## 3. Ereignisse und Dateivertrag
+
+- [ ] 3.1 F12/Event Procedures mit vorhandenen Eventsignaturen an die Prozedurerzeugung aus 03 binden; Tests prüfen Wiederaufruf ohne Duplikat, BYREF-/Typ- und Control-Array-Indexparameter.
+- [ ] 3.2 Shift+F12/View→Form und Codewechsel an dieselbe Dokumentidentität binden; eine Eingabefolge belegt unveränderte ungespeicherte Struktur und Cursor-/Controlauswahl.
+- [ ] 3.3 Save/Reopen und Binärimport→Textziel für gestaltete Formulare prüfen; bestehender FRM-Parser und CLI-Compiler müssen Struktur, Array-Indizes, Properties und Code gemeinsam akzeptieren.
+- [ ] 3.4 Designerbedienung dokumentieren und alle Spec-Szenarien in verification.md zuordnen; IDE-/FRM-/Forms-Metadaten-Tests und Formatprüfung müssen bestehen.

openspec/changes/phase-5-06-debugger-und-direktfenster/.openspec.yaml

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

openspec/changes/phase-5-06-debugger-und-direktfenster/design.md

@@ -0,0 +1,31 @@
+## Context
+
+Die VM hat `add_module_breakpoint(module, line)`, `set_step`, Quellortabfragen und `inspect` für aktuelle Locals/Globals, Arrayelemente und UDT-Felder. Die Breakpoint-Identität enthält noch keine Datei; Calls-Ansicht, Ausdrucks-Compiler im pausierten Frame, Step Over, Watchpoints, History und Set Next Statement fehlen. Fehlerhandler werden intern durch `handle_error` gewählt und Frames gegebenenfalls abgewickelt. Die fortsetzbare Sitzung kommt aus 04.
+
+## Goals / Non-Goals
+
+**Goals:** Debugger als opt-in-Steuerung derselben VM; sichtbare Quellorte und beobachtete Werte gehören immer zur pausierten Kompilatrevision.
+
+**Non-Goals:** Zweiter BASIC-Interpreter, Rückgängigmachen von Datei-/Timer-/Netzwerknebenwirkungen, ungeprüftes Setzen des rohen Programmzählers oder persistentes Debugger-Bytecodeformat.
+
+## Decisions
+
+1. IDE-Breakpoints verwenden Dokument-/Modulidentität und eine durch Textedits mitgeführte Marke. Beim Compile werden sie an vorhandene Source-/Stmt-Grenzen des konkreten Kompilats gebunden, einschließlich Datei-ID. Die bestehende Modul-/Zeilen-API bleibt für bisherige Einbetter erhalten; die IDE benutzt die präzisere API. Eine Zeile mit mehreren Statements hält beim Eintritt in die Zeile, ein Step kann jede einzelne Anweisung zeigen. Nicht ausführbare Zeilen werden sichtbar ungebunden und nicht still auf eine fremde Datei verschoben.
+2. Fortsetzen überspringt nur die gerade gemeldete Halteprüfung am aktuellen Stmt und nicht einen späteren erneuten Besuch. Step Over verfolgt konkrete Frameidentität und Tiefe, nicht nur Prozedurname oder Zeilennummer. Run to Cursor besitzt einen temporären Halt mit begrenzter Lebensdauer. Events, rekursive Frames, GOSUB und Fehlerhandler behalten ihre bestehenden Eintritts-/Rückkehrregeln; Breakpoints haben Vorrang vor einem Step-Over-Ende.
+3. Eine lesbare Frame-/Symbolansicht liefert Calls und Watch-Kontext. Ausgewählter Inspektionsrahmen und aktiver Ausführungsrahmen sind getrennt. Ausdrücke werden mit Frontend/Sema/Codegen in einen kurzlebigen Debug-Kontext übersetzt, der tatsächliche Slots referenziert. Es wird keine eigene Arithmetik oder Typkonvertierung implementiert. Watches erlauben Literale, Operatoren, erreichbare Variablen, Arrays/UDTs und nachweislich reine Intrinsics; Benutzerprozeduren und zustandsverändernde Funktionen sind dort mit Diagnose ausgeschlossen. Das ist eine ausdrücklich dokumentierte Schutzregel für automatische Beobachtung; solche Aufrufe sind im Direktfenster möglich.
+4. **Watchpoint-Vorgabe:** Halt bei wahrer boolescher Bedingung an der nächsten Statement-Grenze. Nach Continue wird die aktuelle Prüfung einmal übersprungen; eine weiterhin wahre Bedingung kann an der nächsten Grenze wieder halten. Watchpoints werden nur bei aktiven Einträgen ausgewertet; fehlerhafte Einträge zeigen einen Fehler und werden bis zur Korrektur nicht als „wahr“ behandelt. Keine dauerhafte Mehrarbeit im CLI-Standardpfad.
+5. Immediate übersetzt erlaubte Anweisungen über denselben Frontend-/VM-Pfad in einen temporären Debug-Aufrufrahmen. Bestehende Symbole referenzieren die pausierte Sitzung einschließlich BYREF. Normale Seiteneffekte sind ausdrücklich wirksam. Der ursprüngliche Fortsetzungspunkt und die Debug-Kommandogrenze werden gesichert; Syntax-/Sema-Fehler verändern nichts. Runtime-Fehler und ERROR verwenden den bestehenden Fehlerpfad, ohne den Debug-Eintritt mit einer normalen Programmzeile zu verwechseln. Ein erfolgreich abgearbeitetes Kommando kehrt zur Pause zurück; END/SYSTEM/RUN innerhalb eines aufgerufenen Programmpfads werden an die Sitzung aus 04 weitergegeben. Interrupt/Warten benutzt deren fortsetzbare Operationen.
+6. Trace aktualisiert Quellmarkierung, History führt einen begrenzten Ring aus Quellorten. Projektvorgabe: 1.024 Einträge, älteste fallen heraus. Die Tasten navigieren nur diesen Trace, nicht VM-Zustände. Aktuell und historisch werden deutlich getrennt; alle Werte gehören weiterhin zum aktuellen Halt. Die Referenz beschreibt keine Rückabwicklung von Nebenwirkungen, deshalb wird kein Zeitreise-System gebaut.
+7. Break on Errors ergänzt einen Halt nach Auswahl/Unwinding des zuständigen Handlers, vor dessen erster Anweisung. Fehlerort, ERR/ERL und das vorgesehene RESUME-Ziel werden gesichert. Continue verarbeitet nicht denselben Fehler erneut. Für unbehandelte Fehler bleibt der entsprechende End-/Fehlerzustand unterscheidbar. Tests vergleichen die gesamte Handler-/RESUME-Folge mit deaktivierter Option.
+8. Set Next Statement benutzt eine Tabelle zulässiger Statement-Einstiege und Kontrollkontexte aus Codegen/VM. Nur derselbe aktive Frame und kompatible Schleifen-/GOSUB-/Fehlerkontexte sind erlaubt; Eintritt in einen fremden Block oder Handler ist kein roher PC-Sprung. Die Prüfung erfolgt vollständig vor Mutation. Erfolgreicher Sprung hält den Zustand und führt übersprungenen Code nicht aus.
+
+## Risks / Trade-offs
+
+- Gleiche Zeile in mehreren Includes → Binding mit tatsächlicher Datei-ID, expliziter Regressionstest im selben Modul.
+- Nebenwirkungen durch Watches → wiederverwendeter Expression-Compiler mit ausdrücklicher Reinheitsgrenze, Zustandsvergleich vor/nach mehrfacher Auswertung.
+- Debug-Aufruf und normaler Stack geraten durcheinander → separate Eintrittsmarke, Tests für BYREF, Rekursion, ERROR, Handler, Unterbrechen und RUN.
+- Set Next Statement springt in inkonsistente Strukturen → konservativ begründete Ablehnung; keine stillschweigende Reparatur des Programms.
+
+## Migration Plan
+
+Neue Debuggerfunktionen bleiben opt-in. Bestehende Breakpoint- und Run-APIs weiterprüfen; TBC-Quelldaten werden wiederverwendet. Ein Compile-Neustart bindet Breakpoints neu, löscht Frames, History und Watchwerte und behält nur die vom Benutzer definierten Watchausdrücke.

openspec/changes/phase-5-06-debugger-und-direktfenster/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Die VM bietet Modul-/Zeilenbreakpoints und einfache Inspektion, aber keine vollständige IDE-Debugger-Sitzung. Besonders Includes, Prozedurschritte, Direktfenster und behandelte Fehler brauchen explizite Verträge, damit Debuggen dieselbe TBVM-Semantik behält.
+
+## What Changes
+
+- Dateigenaue Breakpoints, Run to Cursor, Einzelschritt, Prozedurschritt, Next Statement und Calls-Fenster.
+- Ausdruckswatches, Instant Watch, Watchpoints und Direktfenster im pausierten VM-Kontext.
+- Trace, navigierbare Ausführungshistorie, Break on Errors und validiertes Set Next Statement.
+- Opt-in-Debugger-Erweiterungen der bestehenden VM mit unverändertem Standardverhalten des CLI-Runners.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-debugger`: Dateigenaue Breakpoints, Run to Cursor, Einzelschritt, Prozedurschritt, Next Statement und Calls-Fenster.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-vm/interp.rs, Debug-Quellorte und Frontend/Codegen für Ausdrücke und Direktfenster; tb-ide-Debugfenster. Keine zweite Auswertungsmaschine, kein Zeitreise-Debugger.
+
+**Abhängigkeiten:** [phase-5-03-editor-und-inkrementelle-uebersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md), [phase-5-04-ausfuehrung-und-output](../phase-5-04-ausfuehrung-und-output/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-06-debugger-und-direktfenster/specs/ide-debugger/spec.md

@@ -0,0 +1,70 @@
+## Purpose
+
+Stellt quellgenaues Debuggen innerhalb derselben TBVM bereit, einschließlich Ausführungssteuerung, Variablenbeobachtung, Direktfenster und nachvollziehbarer Fehlerhalte.
+
+## ADDED Requirements
+
+### Requirement: Dateigenaue Breakpoints
+F9 und Toggle Breakpoint SHALL Haltepunkte nach Modul, physischer Quelldatei und Zeile setzen und entfernen. Nur ausführbare Anweisungsgrenzen SHALL binden; nicht bindbare Marken SHALL sichtbar als inaktiv gelten. Clear All SHALL alle entfernen. Continue SHALL die angehaltene Anweisung genau einmal ausführen, bevor derselbe Halt erneut ausgelöst werden kann.
+
+#### Scenario: Zwei Includes mit gleicher Zeile
+- **WHEN** ein Modul zwei Includes mit ausführbarer Zeile 2 verwendet und nur die zweite Datei einen Haltepunkt besitzt
+- **THEN** hält ausschließlich die Anweisung der zweiten Datei an, mit richtigem Quellort und unverändertem Zustand vor ihrer Ausführung
+
+#### Scenario: Einfügen oberhalb einer Marke
+- **WHEN** oberhalb eines Breakpoints Zeilen eingefügt und danach neu übersetzt wird
+- **THEN** wird die Marke mit dem Dokumentedit verschoben und an der neuen Revision neu gebunden oder sichtbar deaktiviert; sie trifft keine fremde Anweisung
+
+### Requirement: Schrittsteuerung und Calls
+F8 SHALL eine BASIC-Anweisung einschließlich Betreten eines Aufrufs ausführen. F10 SHALL den aktuellen Aufruf bis zur nächsten Anweisung desselben Aufrufrahmens ausführen; Breakpoints und Fehlerhalte SHALL dabei Vorrang behalten. F7 SHALL temporär bis zum Cursor laufen, ohne vorhandene Breakpoints zu verlieren. Calls SHALL die Aufrufkette mit Prozedur und Quellort zeigen; Next Statement SHALL zur tatsächlichen Ausführungsstelle navigieren.
+
+#### Scenario: Rekursion und Prozedurschritt
+- **WHEN** F10 an einem rekursiven Aufruf verwendet wird
+- **THEN** endet der Schritt im ursprünglichen Aufrufrahmen hinter dem Aufruf und nicht in einem gleichnamigen rekursiven Rahmen
+
+#### Scenario: Temporäres Laufziel
+- **WHEN** Run to Cursor zuvor durch einen anderen Breakpoint unterbrochen oder das Programm beendet wird
+- **THEN** bleiben dauerhafte Breakpoints erhalten und ein beendeter oder abgebrochener Cursorlauf hinterlässt keinen ungewollten temporären Haltepunkt
+
+### Requirement: Watches und Watchpoints
+Add Watch, Instant Watch/Shift+F9, Watchpoint, Delete Watch und Delete All Watch SHALL typisierte BASIC-Ausdrücke im ausgewählten erreichbaren Aufrufrahmen einschließlich Modulqualifizierung, Arrayelementen und UDT-Feldern anbieten. Automatische Beobachtung SHALL den Programmzustand unverändert lassen; nicht nebenwirkungsfrei auswertbare Ausdrücke SHALL mit Grund abgewiesen werden. Watchpoints SHALL bei wahrer Bedingung an einer Anweisungsgrenze halten. Auswertungsfehler SHALL den jeweiligen Eintrag markieren und die Sitzung erhalten.
+
+#### Scenario: Beobachtung im lokalen Kontext
+- **WHEN** eine rekursive Prozedur pausiert und ein anderer erreichbarer Rahmen in Calls gewählt wird
+- **THEN** zeigen dessen Watches die Werte dieses Rahmens einschließlich lokaler Arrays und qualifizierter Globals, ohne den Ausführungsrahmen zu wechseln
+
+#### Scenario: Watchpoint wird wahr
+- **WHEN** eine Zuweisung eine zuvor falsche Watchpoint-Bedingung wahr macht
+- **THEN** hält die Ausführung an der nächsten sicheren Anweisungsgrenze mit aktualisierten Werten
+
+### Requirement: Direktfenster im pausierten Kontext
+Window→Immediate SHALL ein bedarfsweise sichtbares Direktfenster öffnen. Im Break-Modus SHALL es PRINT, Zuweisungen, Prozeduraufrufe und ERROR n über dieselben Sprach-, Typ- und Laufzeitregeln wie Projektcode ausführen. Änderungen an erreichbaren Variablen SHALL danach im Programm sichtbar sein. Ungültige Eingaben SHALL eine Diagnose liefern, ohne den angehaltenen Fortsetzungspunkt zu verlieren. Während eines laufenden Kommandos SHALL Unterbrechen möglich bleiben.
+
+#### Scenario: Wert ändern und fortsetzen
+- **WHEN** im lokalen Break-Kontext eine Zuweisung und ein BYREF-Prozeduraufruf eingegeben werden und anschließend F5 folgt
+- **THEN** verwendet das Programm die geänderten Werte und setzt am vorherigen Programmpunkt fort; temporärer Direktcode bleibt kein Teil des gespeicherten Projekts
+
+#### Scenario: Fehler im Direktfenster
+- **WHEN** ERROR n oder ein fehlerhaftes Direktkommando ausgeführt wird
+- **THEN** wird der Fehler nach den geltenden Laufzeitregeln angezeigt beziehungsweise behandelt, die IDE bleibt bedienbar und der Zustand der pausierten Sitzung ist eindeutig erkennbar
+
+### Requirement: Trace und Ausführungshistorie
+Trace On SHALL die aktuelle Quellstelle während des Laufs sichtbar verfolgen. History On SHALL ausgeführte Quellstellen in einem begrenzten Verlauf halten; Shift+F8/Shift+F10 SHALL darin rückwärts/vorwärts navigieren. Historische Auswahl SHALL sich von der aktuellen Ausführungsstelle unterscheiden und MUST NOT Variablen, Uhr, Dateien oder andere Nebenwirkungen zurückspulen. Ein Neustart SHALL den Verlauf zurücksetzen.
+
+#### Scenario: Historie betrachten
+- **WHEN** nach drei Zuweisungen zweimal rückwärts in History navigiert wird
+- **THEN** zeigt die IDE frühere Quellorte als Historie, während Variablenwerte und nächster realer Ausführungspunkt unverändert bleiben
+
+### Requirement: Break on Errors
+Bei aktivem Break on Errors SHALL die IDE auch vor der ersten Anweisung eines ausgewählten Fehlerhandlers anhalten und Fehlernummer, verursachenden Quellort und Handlerziel zeigen. Continue SHALL die bestehende Fehlerbehandlung genau einmal fortführen; ohne Debuggeroption SHALL das bisherige Verhalten unverändert bleiben. Unbehandelte Fehler SHALL als solche unterscheidbar bleiben.
+
+#### Scenario: Behandelter Fehler
+- **WHEN** ein Laufzeitfehler einen ON-ERROR-Handler auswählt und Break on Errors aktiv ist
+- **THEN** hält die IDE vor dem Handlercode; nach Continue stimmen ERR, ERL, Unwinding und RESUME-Verhalten mit dem Lauf ohne Debuggerhalt überein
+
+### Requirement: Sicheres Set Next Statement
+Set Next Statement SHALL im Break-Modus den nächsten Ausführungspunkt auf eine ausführbare Stelle desselben aktiven Prozedurrahmens setzen können, sofern Kontroll-, Schleifen-, GOSUB- und Fehlerzustand kompatibel bleiben. Ein unzulässiger Wechsel SHALL begründet und vollständig ohne Zustandsänderung abgewiesen werden. Erfolgreiches Setzen SHALL keine übersprungenen Anweisungen ausführen.
+
+#### Scenario: Gültiger und ungültiger Sprung
+- **WHEN** zunächst eine gleichrangige Folgeanweisung und danach eine Stelle in einer anderen Prozedur als nächstes Statement gewählt wird
+- **THEN** ist die erste Wahl wirksam und die zweite abgewiesen, ohne den ersten gültigen Fortsetzungspunkt zu verändern

openspec/changes/phase-5-06-debugger-und-direktfenster/tasks.md

@@ -0,0 +1,27 @@
+## 1. Quellgenaue Halte und Schritte
+
+- [ ] 1.1 Eine dateigenaue Breakpoint-Bindung ergänzen und bestehende Modul-/Zeilen-API erhalten; Tests mit zwei Includes derselben physischen Zeile im selben Modul halten nur im gewählten Include.
+- [ ] 1.2 Editierbare Breakpoint-Marken mit Neubindung an Kompilatrevisionen integrieren; Tests für Einfügen/Löschen und nicht ausführbare Zeilen belegen richtige Verschiebung oder sichtbare Deaktivierung.
+- [ ] 1.3 Continue-/Single-Step-Verhalten und F9/Clear All im IDE-Dispatcher anbinden; Tests belegen Ausführung einer angehaltenen Anweisung genau einmal und erneuten Halt bei späterem Schleifendurchlauf.
+- [ ] 1.4 Step Over mit Frameidentität sowie Run to Cursor mit temporärem Halt implementieren; Tests prüfen Rekursion, GOSUB, Eventhandler, vorrangige Breakpoints und Aufräumen des Cursorziels.
+- [ ] 1.5 Calls-Fenster und Next Statement mit getrenntem Inspektions-/Ausführungsrahmen anbinden; ein Rekursionstest navigiert in ältere Frames, ohne den aktiven PC zu verändern.
+
+## 2. Ausdrücke und Direktfenster
+
+- [ ] 2.1 Bestehenden Frontend-/Codegen-Pfad für temporäre Debug-Ausdrücke mit Slotbindung im gewählten Frame zugänglich machen; Tests vergleichen Zahlenkonvertierung, Modulqualifizierung, Arrays und UDT-Felder mit normalem BASIC-Code.
+- [ ] 2.2 Add/Instant/Delete/Delete All Watch und das read-only Debug Window integrieren; Tests zeigen Fehler pro Eintrag und nachweislich unveränderten Zustand nach wiederholter Beobachtung.
+- [ ] 2.3 Reinheitsprüfung für automatische Ausdrücke und bedingte Watchpoints implementieren; Tests lehnen zustandsverändernde Aufrufe ab und halten nach einer falsch→wahr-Änderung an der nächsten Grenze.
+- [ ] 2.4 Immediate Window mit temporärem Debug-Eintritt für PRINT und Zuweisungen implementieren; Tests belegen sichtbare Werteänderung und erhaltenen ursprünglichen Fortsetzungspunkt.
+- [ ] 2.5 Prozeduraufrufe einschließlich BYREF, ERROR und Runtimefehler im Direktfenster integrieren; Tests prüfen Handler/RESUME, Unterbrechen, wartende Aufrufe sowie END/RUN-Übergänge ohne verlorenen oder doppelten Frame.
+
+## 3. Historie, Fehler und Ausführungsziel
+
+- [ ] 3.1 Trace, begrenzte History und Shift+F8/Shift+F10 mit eindeutiger historischer Markierung implementieren; Tests belegen Ringgrenze, Navigation und unveränderte aktuelle Variablen/Dateieffekte.
+- [ ] 3.2 Break on Errors zwischen Handlerwahl und erster Handleranweisung einführen; Differentialtests mit deaktivierter Option belegen identische ERR/ERL-, Unwinding- und RESUME-Folge nach Continue.
+- [ ] 3.3 Zulässige Ziele für Set Next Statement aus Statement-/Kontrollkontexten ableiten und vor Mutation prüfen; Tests erlauben gleichrangige Ziele und lehnen fremde Frames, Schleifen-/GOSUB-/Fehlerkontexte ohne Teiländerung ab.
+- [ ] 3.4 Debuggerzustand an Neustart und Quellrevisionen binden; Tests belegen neu gebundene Breakpoints, erhaltene Watchdefinitionen und verworfene Frames/History/Werte.
+
+## 4. Abnahme und Bedienung
+
+- [ ] 4.1 Die vollständigen Debugger-Menüs und F7/F8/F9/F10/Shift+F9 über App-Ereignisse prüfen; dieselben Szenarien müssen auch mit Include- und Formularereigniscode korrekt anhalten.
+- [ ] 4.2 Debuggerverträge und die expliziten Grenzen für Watches, History und Set Next Statement dokumentieren; verification.md weist alle Szenarien sowie bestandene VM-/Fehlerhandler-/CLI-Regressionen und Format-/Clippy-Prüfung nach.

openspec/changes/phase-5-07-hilfesystem/.openspec.yaml

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

openspec/changes/phase-5-07-hilfesystem/design.md

@@ -0,0 +1,28 @@
+## Context
+
+Die Hilfe soll laut PLAN.md die tatsächlich implementierte Dokumentation unter docs anzeigen. Fensterverwaltung und F1-Befehlsweg stammen aus 02; Token-/Prozedurkontext aus 03. Die existierenden Markdown-Dateien enthalten Tabellen, Codeblöcke, Überschriften und relative Verweise. Es gibt noch keinen Markdown-Hilferenderer.
+
+## Goals / Non-Goals
+
+**Goals:** Eine Dokumentationsquelle für CLI-Leser und IDE, offline paketiert, stabile Link- und Kontextziele.
+
+**Non-Goals:** Browser, Webserver, HTML-/JavaScript-Ausführung, Download von Hilfethemen oder separate handgepflegte Kopie der Referenztexte.
+
+## Decisions
+
+1. Die relevanten docs-Dateien werden beim Build direkt eingebettet. Ein kleiner Themenkatalog ordnet Dateipfad und Überschriftenanker den Inhalten zu. Er enthält Index/Contents und Kontextaliasse, aber keine duplizierten Erklärungstexte. Include-Struktur und Katalogprüfung müssen fehlende Dokumente beim Build/Test sichtbar machen. Eine Laufzeitinstallation benötigt keinen Checkout.
+2. Markdown wird in logische Blöcke und Inline-Spans übersetzt und mit vorhandenen ratatui-Mitteln gerendert. Vor Implementierung kurz vorhandene Workspace-Abhängigkeiten prüfen; falls kein Parser verfügbar ist, ist ein einzelner fokussierter CommonMark-Parser zweckmäßiger als ein eigener Parser für Tabellen, Escapes, Code und Links. Keine volle Terminal-Markdown-Anwendung als Subprozess. Bibliothekswahl wird erst in der Umsetzung nach API-/Lizenzprüfung festgelegt, der Vertrag bleibt unabhängig davon.
+3. Fensterbreite bestimmt Fließtextumbruch; Code und breite Tabellen verwenden horizontales Scrollen. Der Leseanker besteht aus Thema, Block/Offset und fokussiertem Link, nicht aus einer alten Bildschirmzeile. Unicode-Breiten kommen aus der vorhandenen Darstellung. Resize berechnet nur das Layout neu.
+4. Interne Ziele werden relativ zur Quelldatei normalisiert und gegen eingebettete Dateien/Anker aufgelöst. Pfade außerhalb der eingebetteten Dokumente werden nicht als beliebige lokale Dateien gelesen. Externe Links erhalten eine sichtbare URL und Hinweis, öffnen aber nicht automatisch Browser oder Shell. Unbekannte/fehlende interne Ziele sind prüfbare Fehler, keine stillen Nullaktionen.
+5. Kontextauflösung verwendet normalisierte Token mit Typ-Suffixen, Forms-Klasse/Property und konkrete IDE-Befehls-ID. Bei Mehrdeutigkeit erscheint die Trefferliste, ohne Treffer der Index mit übernommenem Suchwort. Designer liefert einfache Kontextdaten über den Rahmen; 07 benötigt seine Implementierung nicht als Compilerabhängigkeit, 08 prüft die echte Integration.
+6. Besuchshistorie speichert maximal 20 Rücksprungzustände einschließlich Leseposition. Ctrl+F1 geht in der Reihenfolge des Contents-Katalogs zum nächsten Thema und bleibt am Ende mit erkennbarem Hinweis stehen. Esc stellt den vorherigen Fokus wieder her. Tutorial, Keyboard und Using Help sind normale Markdown-Seiten; About verwendet die Paketversion des gebauten Programms.
+
+## Risks / Trade-offs
+
+- Anker ändern sich bei Dokumentpflege → Linkprüfung über alle eingebetteten Inhalte und Kontextaliasse.
+- Eingebettete Dateien vergrößern das Binary → nur Dokumentation, keine Originalarchive oder Testdaten einbetten; keine Laufzeit-Netzwerkabhängigkeit.
+- Eigener Markdownparser wächst → vorhandene/fokussierte Parserbibliothek verwenden, Darstellung bleibt kleines IDE-Modul.
+
+## Migration Plan
+
+Dokumenttexte bleiben unter docs die Quelle. Fehlende Bedienungsseiten werden dort ergänzt und in den Katalog aufgenommen. Keine Benutzerdatenmigration; neue Releases liefern die passende Hilfe automatisch mit.

openspec/changes/phase-5-07-hilfesystem/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Die Markdown-Referenzen sind vorhanden, aber in der IDE nicht erreichbar. Phase 5 verlangt daraus ein offline nutzbares Hilfesystem mit Kontextsuche, dynamischem Umbruch und der dokumentierten Tastaturnavigation.
+
+## What Changes
+
+- Markdown-Hilfefenster aus den mitgelieferten docs mit Überschriften, Absätzen, Listen, Tabellen, Code und sichtbaren Links.
+- F1-Kontextauflösung für Sprache, Bibliothek, Formulare, Eigenschaften und IDE-Befehle; Index, Contents, Keyboard, Tutorial und About.
+- Tab/Shift+Tab, Enter, Alt+F1 mit 20 Rücksprüngen, Ctrl+F1, Shift+F1 und Esc einschließlich Resize-/Fokuserhalt.
+- Offline-Paketierung ohne Abhängigkeit vom aktuellen Arbeitsverzeichnis und reproduzierbare Prüfung interner Links.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-hilfe`: Markdown-Hilfefenster aus den mitgelieferten docs mit Überschriften, Absätzen, Listen, Tabellen, Code und sichtbaren Links.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Hilfe, docs/ und Paketierung von tb; nutzt Fensterverwaltung und Editor-Kontext. Kein Webdienst und keine eigene zweite Dokumentationssammlung.
+
+**Abhängigkeiten:** [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/proposal.md), [phase-5-03-editor-und-inkrementelle-uebersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/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-07-hilfesystem/specs/ide-hilfe/spec.md

@@ -0,0 +1,41 @@
+## Purpose
+
+Macht die mitgelieferte Markdown-Dokumentation als offline verfügbare, kontextsensitive IDE-Hilfe mit verlässlicher Navigation und variabler Fenstergröße nutzbar.
+
+## ADDED Requirements
+
+### Requirement: Mitgelieferte Dokumente und Markdown-Darstellung
+Die Hilfe SHALL die aktuelle Dokumentation aus docs einschließlich Sprach-, Bibliotheks-, Forms- und IDE-Bedienungsreferenz ohne Netzwerk und unabhängig vom Arbeitsverzeichnis bereitstellen. Überschriften, Absätze, Listen, Codeblöcke, Tabellen und Links SHALL lesbar dargestellt werden; Fließtext SHALL nach Fensterbreite umbrechen, Code und Tabellen SHALL ohne Informationsverlust umgebrochen oder horizontal scrollbar sein. Resize SHALL Thema und logische Leseposition erhalten.
+
+#### Scenario: Start außerhalb des Repositorys
+- **WHEN** das gebaute tb aus einem Verzeichnis ohne docs gestartet wird
+- **THEN** sind Index, Referenzthemen und Tutorial weiterhin vollständig erreichbar
+
+#### Scenario: Schmales Hilfefenster
+- **WHEN** ein Thema mit Tabelle, Unicode und Code bei schmaler Fensterbreite geöffnet und anschließend vergrößert wird
+- **THEN** bleiben alle Inhalte erreichbar, Links bedienbar und die Leseposition demselben Inhalt zugeordnet
+
+### Requirement: Kontextsensitive Themenwahl
+F1/Topic und entsprechend konfigurierter Rechtsklick SHALL das Thema zum Token unter dem Editorcursor, zur Designerklasse/-eigenschaft oder zum fokussierten IDE-Befehl öffnen. Sprache und Bibliothek SHALL unabhängig von Großschreibung und mit Typ-Suffixen gefunden werden. Bei mehreren passenden Themen SHALL eine Auswahl erscheinen; ohne passenden Kontext SHALL eine verständliche Suche beziehungsweise der Index erscheinen.
+
+#### Scenario: Property und BASIC-Funktion
+- **WHEN** F1 zuerst auf einer Formulareigenschaft und danach auf einer BASIC-Funktion mit Dollar-Suffix ausgelöst wird
+- **THEN** öffnet die Hilfe jeweils das zugehörige dokumentierte Thema einschließlich dessen passendem Abschnitt
+
+### Requirement: Links und Verlauf
+Interne Links SHALL als ◄Thema► sichtbar sein. Tab/Shift+Tab SHALL den Linkfokus bewegen, Enter SHALL folgen, Alt+F1 SHALL bis zu 20 besuchte Zustände zurückführen und Ctrl+F1 SHALL das nächste Thema in der dokumentierten Themenreihenfolge öffnen. Esc SHALL die Hilfe schließen und den vorherigen Fokus wiederherstellen. Fehlende Ziele SHALL eine Diagnose liefern; externe Links SHALL als extern erkennbar sein und nicht automatisch einen Prozess oder Netzwerkzugriff auslösen.
+
+#### Scenario: Rücksprung mit Leseposition
+- **WHEN** ein Link nach Scrollen verfolgt und Alt+F1 gedrückt wird
+- **THEN** kehrt die Hilfe zu Thema, Leseposition und Linkfokus vor dem Sprung zurück
+
+#### Scenario: Grenze des Verlaufs
+- **WHEN** mehr als 20 Themenwechsel erfolgen
+- **THEN** bleiben die letzten 20 Rücksprünge möglich, ältere Einträge werden nachvollziehbar verdrängt und weiterer Rücksprung verändert den Zustand nicht
+
+### Requirement: Hilfe-Einstiege
+Help SHALL Index, Contents, Keyboard, Topic/F1, Using Help/Shift+F1, Tutorial und About anbieten. Index SHALL Themen alphabetisch auffindbar machen und Contents SHALL die Dokumenthierarchie abbilden. Keyboard und Tutorial SHALL die tatsächlich implementierte IDE-Bedienung erklären; About SHALL Version und Copyright anzeigen.
+
+#### Scenario: Tutorial folgen
+- **WHEN** der Benutzer Tutorial öffnet und den dort beschriebenen Weg zum Erstellen, Gestalten, Debuggen und Ausführen verfolgt
+- **THEN** stimmen Befehle und Tasten mit der Oberfläche überein und alle internen Verweise sind auflösbar

openspec/changes/phase-5-07-hilfesystem/tasks.md

@@ -0,0 +1,17 @@
+## 1. Dokumente und Darstellung
+
+- [ ] 1.1 Die relevanten docs-Inhalte mit stabilem Datei-/Themen-/Ankerkatalog in tb einbetten; ein Test startet die Hilfe aus einem temporären Verzeichnis ohne Checkout und findet alle Referenzseiten.
+- [ ] 1.2 Den Markdown-Block-/Inline-Pfad mit vorhandenen Abhängigkeiten oder einem einzelnen geeigneten Parser anbinden; Renderproben prüfen Überschriften, Listen, Escapes, Links, Codeblöcke und Tabellen.
+- [ ] 1.3 Dynamischen Umbruch und horizontales Scrollen für breite Inhalte implementieren; TestBackend-Prüfungen mit Unicode und Resize erhalten Thema, Leseposition und Linkfokus.
+
+## 2. Kontext und Navigation
+
+- [ ] 2.1 F1-/Rechtsklick-Kontext aus Editor, Forms-Property und IDE-Befehl auf Themen/Anker abbilden; Tests prüfen Typ-Suffixe, Großschreibung, Mehrdeutigkeit und fehlenden Treffer.
+- [ ] 2.2 Tab/Shift+Tab, Enter, Alt+F1, Ctrl+F1 und Esc integrieren; Eingabetests belegen Linkfolge, 20 Rücksprünge, Ende der Themenreihenfolge und vorherigen Fensterfokus.
+- [ ] 2.3 Interne Pfade/Anker prüfen und externe Ziele sichtbar ohne automatische Ausführung behandeln; Tests belegen fehlende Ziele, Pfadbegrenzung und unterbleibende Prozess-/Netzwerkaufrufe.
+
+## 3. Hilfe-Einstiege und Abnahme
+
+- [ ] 3.1 Index, Contents, Keyboard, Using Help, Tutorial und About anbinden und fehlende Bedienungsseiten unter docs ergänzen; Menü-/Shortcut-Tests öffnen jeden Einstieg und zeigen die gebaute Version.
+- [ ] 3.2 Alle eingebetteten relativen Links und Kontextaliasse mit einer ausführbaren Katalogprüfung absichern; sie muss bei absichtlich fehlendem Ziel scheitern.
+- [ ] 3.3 Die Hilfe-Spec-Szenarien in verification.md zuordnen und cargo test -p tb-ide sowie Formatprüfung ausführen; der Tutorial-/Designer-Gesamtweg wird zusätzlich in 08 geprüft.

openspec/changes/phase-5-08-integration-und-phasenabnahme/.openspec.yaml

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

openspec/changes/phase-5-08-integration-und-phasenabnahme/design.md

@@ -0,0 +1,30 @@
+## Context
+
+Die Vorgänger 01–07 besitzen abgegrenzte Fähigkeiten und eigene Szenarien. Bereits vorhandene CLI-/VM-/Forms-Regressionen und Release-Compile-Benchmarks bleiben maßgeblich. Die Referenz enthält mehr Befehle als die acht offenen Phase-5-Checkboxen; die Gesamtübersicht enthält deshalb eine vollständige Zuordnung statt einer erneuten allgemeinen Codeprüfung.
+
+## Goals / Non-Goals
+
+**Goals:** Echte Benutzerwege und ihre Übergänge belegen, Abnahmestand reproduzierbar dokumentieren und Phase 5 nur bei vollständiger Umsetzung schließen.
+
+**Non-Goals:** Neue Parallelimplementierung fehlender Features, Ersatz aller vorhandenen Tests, vorgezogene vollständige Terminal-/OS-Matrix aus Phase 6 oder pauschale Performanceoptimierung.
+
+## Decisions
+
+1. Der Rahmen-Testpfad aus 02 treibt die echte App mit crossterm-Ereignissen und ratatui-TestBackend. Dokumente entstehen für End-to-End-Szenarien durch Eingaben und Dialoge. Unmittelbar vorbereitete VM-Objekte bleiben für fokussierte Unit-Tests nützlich, ersetzen aber keinen Create/Save/Reopen-Nachweis.
+2. Ein dokumentierter Hauptablauf erstellt ein Projekt mit zwei BAS-Modulen, FRM, Control-Array, Menü und Include, erzeugt Ereigniscode über F12, nutzt Hilfe, startet, setzt Breakpoints, steppt über einen Aufruf, ändert einen Wert im Immediate Window, setzt fort und öffnet das gespeicherte Projekt erneut. Ergänzende kurze Fehlerabläufe prüfen Schreibfehler, externe Änderungen, Compilefehler, Include-Quellorte, kleine Terminals und Shell-Rückkehr. Das vermeidet einen einzigen undiagnostizierbar großen Test.
+3. Eine Befehlsabdeckungstabelle bindet jeden Eintrag aus der Gesamtübersicht an Aktion, zulässige Modi und mindestens einen ausführbaren Nachweis. Tastatur-, Menü- und Mausäquivalenz wird am gemeinsamen Dispatcher geprüft; konfliktträchtige F-Tasten zusätzlich im vollständigen Ablauf. Nicht implementierte Phase-5-Befehle bleiben offene Befunde ihres zuständigen Feature-Changes, statt hier mit einem zweiten Codepfad kaschiert zu werden.
+4. Parität verwendet dieselben gespeicherten Quellen, initialen Dateien, COMMAND$, Terminalmaße und deterministischen Ereignis-/Zeitfolgen. Verglichen werden IDE-VM, CLI-Quellcompile und geladenes TBC. STOP/Break und Debug-Nebenwirkungen werden gezielt gesteuert, normale Programmläufe dagegen ohne Debuggeroptionen verglichen.
+5. Vorhandene Referenzprogramme und Benchmarks werden wiederverwendet; es wird kein fremder Korpus vendort. Der Abschlussbericht nennt Revision, Befehle, konkrete Ergebnisse, Referenzhardware und bekannte Terminalgrenzen. Normale Tests prüfen Cache-Wiederverwendung deterministisch, Release-Messungen die bestehenden Zeitbudgets. Wiederholungen nur bei Änderung oder ungeklärtem Fehler.
+6. PLAN.md wird erst nach bestandenem Nachweis aktualisiert, einschließlich präziser Bezeichnung der Properties Bar. Die Phase-6-Plattformmatrix bleibt separat; die lokale headless Abnahme wird nicht als vollständiger Emulator-/OS-Nachweis ausgegeben. IDE-Bedienungsseiten aus 07 werden auf die endgültigen Tasten und Abläufe abgeglichen.
+
+7. Die Exportdialoge aus 02 sind ein eigener vollständiger Phase-5-UI-Nachweis. Der Hauptablauf öffnet beide Make-Dialoge und prüft Zieleingaben, Validierung, Überschreibentscheidung und den erklärten fehlenden Erzeugungsdienst. Kontrollierte Ergebnisrückmeldungen testen Status/Erfolg/Fehler/Abbruch an der vorbereiteten Übergabe, ohne eine native Erzeugung zu behaupten. Der Phase-6-Plan hält echte Standalone-Executables und native Bibliotheken mit Verbraucherprüfung als getrennte offene Aufgaben fest.
+
+## Risks / Trade-offs
+
+- Synthetische UI-Tests übersehen tatsächliche Tastencodierung → native Eingabe-Eventtypen bis zum Dispatcher einspeisen; reale Plattformmatrix weiter in Phase 6 verfolgen.
+- Grünes Teilfeature wird mit fertiger IDE verwechselt → Abschluss nur mit allen Vorgängerszenarien und integrierter Befehlsmatrix.
+- Monolithischer End-to-End-Test ist schwer zu warten → ein lesbarer Hauptablauf plus wenige gezielte Fehlerabläufe und vorhandene modulare Regressionen.
+
+## Migration Plan
+
+Keine neuen Dateiformate. Nach vollständiger Verifikation Spezifikationen der Vorgänger und dieses Changes gemäß normalem Workflow synchronisieren/archivieren; PLAN-Checkboxen beziehen sich auf nachgewiesene Fähigkeiten, nicht auf die bloße Existenz der Planungsartefakte.

openspec/changes/phase-5-08-integration-und-phasenabnahme/proposal.md

@@ -0,0 +1,29 @@
+## Why
+
+Einzelne fertige IDE-Funktionen beweisen noch keinen vollständigen Arbeitsablauf. Phase 5 endet erst, wenn ein Mehrmodul-/Formularprogramm vollständig über die IDE erstellt, gespeichert, debuggt und ausgeführt werden kann.
+
+## What Changes
+
+- Durchgängige IDE-Arbeitsabläufe über reale Eingabeereignisse einschließlich Save/Reopen, Forms, Includes, Debugger und Hilfe.
+- Verbindlicher Abgleich aller Phase-5-Punkte und Referenzbefehle mit den zuständigen Changes und ihren Nachweisen.
+- CLI-/IDE-Parität, Compile-Budget und Fehler-/Abbruchpfade als gemeinsame Abnahme; vorhandene Regressionen weiterverwenden.
+- IDE-Bedienungsdokumentation und nachweisgestützte Aktualisierung der Phase-5-Checkboxen in PLAN.md.
+- Export-Dialoge für native Standalone-Executables und Systembibliotheken vollständig als Phase-5-UI prüfen; tatsächliche Artefakterzeugung und native Verbraucherprüfung bleiben ausdrücklich Phase 6.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-phasenabnahme`: Durchgängige IDE-Arbeitsabläufe über reale Eingabeereignisse einschließlich Save/Reopen, Forms, Includes, Debugger und Hilfe.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Integrationstests, vorhandene CLI-/VM-/Forms-Tests und Benchmarks, docs/ sowie PLAN.md. Featureimplementierung bleibt jeweils beim verantwortlichen Change; dieser Change schließt Integration und Nachweise.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/proposal.md), [phase-5-03-editor-und-inkrementelle-uebersetzung](../phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md), [phase-5-04-ausfuehrung-und-output](../phase-5-04-ausfuehrung-und-output/proposal.md), [phase-5-05-formular-designer](../phase-5-05-formular-designer/proposal.md), [phase-5-06-debugger-und-direktfenster](../phase-5-06-debugger-und-direktfenster/proposal.md), [phase-5-07-hilfesystem](../phase-5-07-hilfesystem/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-08-integration-und-phasenabnahme/specs/ide-phasenabnahme/spec.md

@@ -0,0 +1,40 @@
+## Purpose
+
+Sichert die vollständige Nutzbarkeit der Phase-5-IDE über zusammenhängende Arbeitsabläufe, gemeinsame Laufzeitsemantik und reproduzierbare Abnahmekriterien.
+
+## ADDED Requirements
+
+### Requirement: Vollständiger IDE-Arbeitsablauf
+Ein Benutzer SHALL ausschließlich über die IDE ein Projekt mit mindestens zwei BAS-Modulen, einem Formular, einem Control-Array, einem Menü und einem Include erstellen, bearbeiten, speichern, schließen und erneut öffnen können. Danach SHALL dasselbe Projekt mit Ereigniscode ausführbar und mit Breakpoints, Prozedurschritt, Watch und Direktfenster debugbar sein. Kontext-Hilfe SHALL aus Editor und Designer erreichbar sein.
+
+#### Scenario: Schreiben bis Wiederaufnahme
+- **WHEN** dieser Arbeitsablauf durch Menüs, Tastatur und Maus durchgeführt wird und während eines Halts ein Wert im Direktfenster geändert wird
+- **THEN** läuft das Programm mit der Änderung weiter, die gespeicherten Quellen bleiben konsistent und nach erneutem Öffnen sind Projekt, Formularstruktur, Ereigniscode und Startdatei erhalten
+
+### Requirement: Nachgewiesene Befehlsabdeckung
+Alle Phase-5-Funktionen und die ihnen zugeordneten Menü-, Tastatur- und Mauswege aus docs/ide-referenz.md SHALL einen zuständigen Change und einen ausführbaren Nachweis besitzen. Ein Test nur des internen Befehls SHALL keinen Nachweis für die tatsächliche Tasten-/Mausverteilung ersetzen. Noch nicht implementierte Phase-5-Aktionen MUST NOT als vollständige Phasenabnahme gelten.
+
+#### Scenario: Mehrfach belegte Funktionstasten
+- **WHEN** die Abnahme F2, F4, F10, F11 und F12 in ihren verschiedenen Kontexten einspeist
+- **THEN** bestätigt sie die jeweils erwartete Aktion und den Ausschluss einer zweiten Zustellung an das BASIC-Programm
+
+### Requirement: CLI-Parität und robuste Übergänge
+Gespeicherte Projekte SHALL über IDE, CLI-Quellstart und CLI-Kompilatstart bei gleichen Eingaben, Zeiten, Größen und COMMAND$ dieselben BASIC-Ausgaben, Datenwerte und Fehler liefern, abgesehen von den ausdrücklich spezifizierten IDE-Halten. Speichern, Projektwechsel, Reset, Shell-Rückkehr und Resize SHALL auch nach Fehlern die Dokumente und Terminalbedienbarkeit erhalten.
+
+#### Scenario: Vergleich derselben Sitzung
+- **WHEN** ein Forms-/Include-Projekt mit identischer Ereignisfolge über die drei Ausführungswege gestartet wird
+- **THEN** stimmen Ausgabe, Dateieffekte und Laufzeitresultat überein und ein anschließender IDE-Neustart enthält keinen Zustand des vorherigen Laufs
+
+### Requirement: Leistungs- und Dokumentationsabnahme
+Phase 5 SHALL erst als umgesetzt dokumentiert werden, wenn die Change-Szenarien, die relevanten bisherigen Regressionen und das bestehende Release-Compile-Budget nachgewiesen sind. PLAN.md und die IDE-Hilfe SHALL den verifizierten Stand wiedergeben. Prüfberichte SHALL konkrete Befehle, Ergebnisse, Revision und verbleibende Grenzen nennen; vollständige OpenSpec-Artefakte allein SHALL nicht als Implementierungsnachweis gelten.
+
+#### Scenario: Abschlussbericht
+- **WHEN** Phase 5 abgenommen wird
+- **THEN** verweisen alle Phase-5-Checkboxen auf bestandene Nachweise und der Bericht unterscheidet die lokale headless Abnahme von der weiterhin separat geplanten Plattformmatrix aus Phase 6
+
+### Requirement: Export-UI als eigene Phasenleistung
+Die Phase-5-Abnahme SHALL die vollständige Bedienung von Make EXE File und Make Library einschließlich Zielsystem/-architektur, Ausgabepfad, Validierung, Überschreibentscheidung sowie Status-/Fehler-/Abbruchdarstellung prüfen. Dabei SHALL die noch nicht verfügbare native Erzeugung aus Phase 6 ausdrücklich erkennbar sein. Die Abnahme SHALL Oberflächennachweise von der späteren tatsächlichen Erzeugung eigenständiger nativer Executables und nativer Systembibliotheken unterscheiden.
+
+#### Scenario: Exportvorbereitung ohne Scheinerfolg
+- **WHEN** beide Exportdialoge im durchgängigen IDE-Ablauf mit gültigen und ungültigen Angaben bedient werden
+- **THEN** funktionieren Eingabe, Validierung und Rückkehr zum Projekt, die Erzeugungsaktion nennt die Phase-6-Abhängigkeit und weder eine falsche Erfolgsmeldung noch eine als natives Artefakt ausgegebene TBC-Datei entsteht

openspec/changes/phase-5-08-integration-und-phasenabnahme/tasks.md

@@ -0,0 +1,21 @@
+## 1. Vollständiger Arbeitsablauf
+
+- [ ] 1.1 Den headless App-Testpfad aus 02 für Datei-/Dialogaktionen und deterministische VM-Ereignisse verwenden; ein Einstiegstest startet die echte App und erstellt ein leeres Projekt ohne vorbereitete Dokumentobjekte.
+- [ ] 1.2 Den Hauptablauf mit zwei BAS-Modulen, FRM, Control-Array, Menü, Include, F12-Ereigniscode und Startdatei über UI-Ereignisse aufbauen; Save/Close/Reopen muss den gleichen Projekt-/Formularstand ergeben.
+- [ ] 1.3 Den Ablauf um Start, Include-Breakpoint, Prozedurschritt, Watch, Immediate-Wertänderung und Continue ergänzen; Sollausgabe und Variablenwerte belegen die erwartete Wirkung.
+- [ ] 1.4 F1 aus Editor und Designer sowie Tab/Enter/Alt+F1 in denselben Ablauf aufnehmen; Hilfeziel und wiederhergestellter Fokus müssen stimmen.
+
+## 2. Grenzfälle und vollständige Bedienung
+
+- [ ] 2.1 Die gesamte Befehlsmatrix der Phase-5-Übersicht mit konkreten Tests verknüpfen und auf fehlende Einträge prüfen; alle Phase-5-Aktionen müssen im zulässigen Kontext mehr als einen Platzhaltereffekt besitzen.
+- [ ] 2.2 Mehrfachbelegungen von F2/F4/F10/F11/F12 sowie Tastatur-/Menü-/Mausäquivalenz über native Eingabeevents prüfen; kein Event darf zugleich als IDE-Aktion und BASIC-Eingabe wirksam werden.
+- [ ] 2.3 Kurze Fehlerabläufe für Teilspeichern, externe Änderung, Compilefehler, Pause beim Eingabewarten, RUN-Zielfehler, Shell-Rückkehr und Shrink/Resize hinzufügen; Dokumenterhalt und anschließende Bedienbarkeit müssen belegt sein.
+
+- [ ] 2.4 Beide nativen Exportdialoge vollständig über App-Ereignisse prüfen; gültige/ungültige Ziele, Überschreibentscheidung und kontrollierte Status-/Fehlerrückmeldungen funktionieren, während der Phase-5-Produktionspfad die fehlende Erzeugung erklärt und keine native Datei vortäuscht.
+
+## 3. Parität, Leistung und Abschluss
+
+- [ ] 3.1 Dasselbe gespeicherte Projekt als IDE-Lauf, CLI-Quelllauf und TBC-Lauf mit identischem Hostskript vergleichen; Ausgabe, Anfangszustand, Dateieffekte und Fehler müssen bis auf dokumentierte IDE-Halte übereinstimmen.
+- [ ] 3.2 Die vorhandenen relevanten Workspace-Regressionen und Release-Compile-Benchmarks einmal auf dem finalen Stand ausführen; Ergebnisse, Referenzhardware, Profil, Größen und Zeitgrenzen in verification.md festhalten.
+- [ ] 3.3 Die endgültige IDE-Bedienung mit Keyboard/Tutorial/Hilfe abgleichen und PLAN.md ausschließlich anhand bestandener Nachweise aktualisieren; die Zuordnung jeder Phase-5-Checkbox und die separat offene Phase-6-Plattformmatrix sind im Abschlussbericht prüfbar.
+- [ ] 3.4 Alle acht Changes zusammen gegen die Hauptspezifikation und Befehlsmatrix verifizieren; offene Befunde an ihrem zuständigen Change beheben und den betroffenen Nachweis erneut ausführen, bis keine Phase-5-Befunde übrig sind.