Phase 6: IDE-Exportanbindung abschließen und Change archivieren

This commit is contained in:
2026-09-07 17:00:29 +02:00
parent 25176947ba
commit 69f2002481
31 changed files with 1310 additions and 136 deletions

View File

@@ -0,0 +1,46 @@
# ide-native-exporte Specification
## Purpose
Verbindet die IDE-Exportdialoge mit der tatsächlichen EXE-/TBL-Erzeugung und dem gemeinsamen P-Code-Linkdienst unter Erhalt von Projektstand, Bedienbarkeit und eindeutigem Auftragsstatus.
## Requirements
### Requirement: Reale Erzeugung aus aktuellem Projektstand
Make EXE File und Make Library SHALL bei verfügbaren Voraussetzungen dieselben nativen Executables beziehungsweise portablen TBL-Bibliotheken wie der gemeinsame CLI-Link-/Exportpfad erzeugen. Der Auftrag SHALL einen konsistenten Stand aller verwendeten Projekt-, Formular- und Include-Inhalte einschließlich ungespeicherter Bearbeitungen sowie der eingelesenen TBL-Bibliotheken erfassen. Export SHALL kein implizites Speichern oder Verwerfen von Dokumentänderungen erfordern.
#### Scenario: Ungespeichertes Include exportieren
- **WHEN** ein Include in der IDE geändert, noch nicht gespeichert und anschließend ein nativer Export gestartet wird
- **THEN** enthält das Artefakt die Änderung, während die Quelldatei auf dem Datenträger und der Bearbeitungsstatus erhalten bleiben
### Requirement: Verfügbarkeit und Zielkonsistenz
Für Make EXE SHALL die IDE Windows amd64, macOS arm64 und Linux amd64/arm64 entsprechend den tatsächlichen tbrt-Vorlagen und Finalisierungsmöglichkeiten anbieten. Make Library SHALL `.tbl` als plattformunabhängiges Ergebnis ausweisen und ohne native Zielauswahl oder Runtime-Vorlage funktionieren. Fehlende Backend-/Vorlagen-/Systemvoraussetzungen SHALL konkret angezeigt werden. Eine unzulässige Kombination oder TBC-Datei MUST NOT als erfolgreiche native Ausgabe erscheinen.
#### Scenario: Fehlende Zielvorlage
- **WHEN** ein gültiges Releaseziel gewählt wird, dessen Vorlage auf dem Host fehlt
- **THEN** bleibt der Dialog bedienbar und erklärt die fehlende Voraussetzung ohne Erzeugung eines anderen Zielformats
### Requirement: Abbruch und eindeutige Veröffentlichung
Die IDE SHALL während der Erzeugung bedienbar bleiben und einen wirksamen Abbruch erlauben. Nur der weiterhin gültige Auftrag SHALL sein fertig validiertes Artefakt veröffentlichen und Erfolg melden. Abgebrochene, überholte oder fremde Ergebnisse MUST NOT ein neueres Ergebnis überschreiben oder als Erfolg des aktuellen Projekts erscheinen; vorhandene Zieldateien SHALL bei solchen Abbrüchen erhalten bleiben.
#### Scenario: Ergebnis trifft nach Projektwechsel ein
- **WHEN** während eines Exports das Projekt gewechselt oder ein neuerer Auftrag begonnen wird und danach ein altes Ergebnis eintrifft
- **THEN** wird das alte Ergebnis nicht veröffentlicht und weder dem neuen Projekt noch dessen Dialog als Erfolg zugeordnet
### Requirement: Bedienung bis zur unabhängigen Nutzung
Tastatur- und Mauswege SHALL Export, Fehlerkorrektur und Rückkehr zum Projekt gleichwertig ermöglichen. Der vollständige IDE-Abnahmepfad SHALL tatsächlich erzeugte Executables starten und TBL-Bibliotheken mit einem separaten BASIC-Verbraucher über `tbc link` verwenden.
#### Scenario: Export aus der IDE benutzen
- **WHEN** ein Projekt über den Make-Dialog erfolgreich exportiert wird
- **THEN** lässt sich das Ergebnis unabhängig von der IDE nativ ausführen beziehungsweise ohne Library-Quellen in einem anderen BASIC-Projekt verknüpfen und die Dokumente bleiben unverändert bearbeitbar
### Requirement: Bibliotheken im IDE-Projekt
Die IDE SHALL TBL-Mitglieder über Add File/Remove File verwalten und ihre Reihenfolge und relativen Verweise beim MAK-Speichern erhalten. Bibliotheken MUST NOT als editierbarer Quelltext oder als Startdatei angeboten werden. Start, Check, Debugger und Export SHALL dieselbe Bibliotheksauflösung wie `tbc link` verwenden. Geänderte Bibliotheksinhalte SHALL veraltete Compiler-/Linkergebnisse und ausstehende Exportaufträge invalidieren.
#### Scenario: Bibliothek nach einem Lauf ersetzen
- **WHEN** eine TBL im Projekt nach einem Lauf durch eine geänderte Bibliothek ersetzt und das Projekt erneut gestartet wird
- **THEN** nutzt die IDE deren aktuelle Deklarationen und P-Code; ein noch ausstehender Export mit den alten Bytes wird nicht als aktueller Stand veröffentlicht
#### Scenario: Portable Library ohne native Vorlage
- **WHEN** Make Library für ein gültiges Projekt ohne verfügbare tbrt-Zielvorlage verwendet wird
- **THEN** erzeugt die IDE dennoch eine nutzbare `.tbl` ohne System-/Architekturwahl; ein späterer EXE-Export prüft seine eigenen Zielvoraussetzungen

View File

@@ -57,11 +57,11 @@ Die IDE SHALL die aktuelle Terminalfläche nutzen und auf Größenänderungen re
- **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.
Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare Dialoge für Artefaktart, Zielsystem/-architektur und Ausgabepfad öffnen. Mit Phase 6 SHALL die Ziele als natives eigenständiges Executable mit nativer Runtime in tbrt beziehungsweise portable P-Code-Bibliothek `.tbl` beschrieben sein. System-/Architekturwahl SHALL nur für EXE erforderlich sein; Make Library SHALL ohne native Zielvorlage verfügbar sein, sobald sein Backend vorhanden ist. 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
- **WHEN** beide Make-Befehle ohne verfügbares Erzeugungsbackend über Menü oder Tastatur geöffnet werden
- **THEN** lassen sich die zur Artefaktart passenden Angaben (EXE-Zielsystem/-architektur und Ausgabepfad, für TBL der 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
@@ -70,3 +70,7 @@ Run→Make EXE File und Run→Make Library SHALL bereits in Phase 5 bedienbare D
#### 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
#### Scenario: Verfügbares Erzeugungsbackend
- **WHEN** ein gültiger Auftrag bei verfügbarem Backend tatsächlich erfolgreich erzeugt wird
- **THEN** zeigt der Dialog den bestätigten Erfolg mit dem passenden EXE- oder TBL-Zielartefakt und erhält die Projektdokumente

View File

@@ -35,8 +35,8 @@ Phase 5 SHALL erst als umgesetzt dokumentiert werden, wenn die Change-Szenarien,
- **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.
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. Solange das jeweilige Erzeugungsbackend fehlt, SHALL dessen Nichtverfügbarkeit ausdrücklich erkennbar sein. Bei verfügbarem Backend SHALL die Integration zusätzlich echte EXE-/TBL-Artefakte nachweisen und die native Zielwahl auf EXE beschränken. Die Abnahme SHALL Oberflächennachweise von der späteren tatsächlichen Erzeugung eigenständiger nativer Executables und portabler TBL-Bibliotheken mit quellfreier Wiederverwendung unterscheiden.
#### Scenario: Exportvorbereitung ohne Scheinerfolg
- **WHEN** beide Exportdialoge im durchgängigen IDE-Ablauf mit gültigen und ungültigen Angaben bedient werden
- **WHEN** beide Exportdialoge ohne verfügbares Erzeugungsbackend 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