Phase 5 vollständig planen und native Exporte abgrenzen

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.