155 lines
12 KiB
Markdown
155 lines
12 KiB
Markdown
# Phase 6: Gesamtproposal und Exploration
|
||
|
||
Stand: 2026-09-07. Erkundungsbasis: Commit `86c3ebeb6d623e2f3e33f957ceb24b19cf6d1940`,
|
||
abgeschlossene Phase 5 und zunächst keine aktiven Changes. Dieses Dokument
|
||
plant die gesamte Phase 6; es behauptet keine neue Implementation oder Abnahme.
|
||
|
||
## Verbindliche Vorgaben
|
||
|
||
- Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64.
|
||
- Ausschließlich Gitea Actions am bestehenden Origin `git.rfc1437.de/hugo/TerminalBasic`.
|
||
- Die Actions bauen die tatsächlichen Zielprogramme; reine Platzhalter-/Cross-Buildmeldungen genügen nicht.
|
||
- Windows-Paket als `.7z`, macOS und beide Linux-Pakete als `.tar.gz`.
|
||
- Make EXE erzeugt ein eigenständiges natives Executable mit eingebetteter TB-Runtime, ohne Compiler-/Linker-Toolchain beim Anwender.
|
||
- Make Library liefert portable `.tbl`-P-Code-Bibliotheken. `tbc link` und IDE verwenden denselben Linkdienst; die nativ kompilierte Runtime ist Bestandteil von `tbrt`.
|
||
- Die in Phase 5 fertiggestellten Dialoge werden jetzt an reale Erzeugung angebunden.
|
||
- Stufe-2-Spracherweiterungen bleiben außerhalb dieser Phase.
|
||
|
||
## Feststellungen am bestehenden Code
|
||
|
||
| Bereich | Vorgefundener Stand | Konsequenz für Phase 6 |
|
||
| --- | --- | --- |
|
||
| CLI | `tb-cli/src/main.rs::cmd_build` schreibt ausschließlich `.tbc`; Native-Flags und Vorlagen fehlen | 02 ergänzt native Verpackung, bestehender TBC-Aufruf bleibt |
|
||
| Gemeinsame Ausführung | `project_io::new_execution`, CLI `run_chain`, IDE-Sitzung nutzen dieselbe TBVM; CLI enthält auch Druck-/Exit-/Hostlogik | Runnerpfad wiederverwenden, keine zweite Runtime |
|
||
| Kompilat | `TBC_VERSION = 4`; Projekt-, Forms-, DATA-, Signatur- und Quellortinformationen bereits vorhanden | Vorlagenversion prüfen, vollständiges TBC als eingebettete Nutzlast verwenden |
|
||
| Library | Projektlinker vorhanden, aber noch AST-abhängig; kein TBL-Container oder tbc-link-Befehl | 03 ergänzt serialisierbare Modul-/Symbolmetadaten und quellfreie Verknüpfung |
|
||
| IDE-Export | ExportRequest/ProjectStamp/ExportStatus vorhanden; gültiger Dialogauftrag endet in UNAVAILABLE | 04 bindet Erzeugung an; Staging erst nach gültiger Auftragsprüfung veröffentlichen |
|
||
| Zielauswahl | UI akzeptiert bisher unabhängig drei Systeme und zwei Architekturen | Vierziel-Matrix für EXE zentralisieren; Make Library erzeugt TBL ohne native Zielwahl |
|
||
| Korpus | `compat.rs`: Größen-/Zeit-/Ereignisdirektiven, Text-/Attributsnapshot, temporäre Dateien; weitere Projekt-/Forms-/Fehlerproben | Bestehende Pfade ergänzen und als Release-Abnahmesatz verbinden |
|
||
| Fremdprogramme | Sieben Programme aus cout/vbdos, fixierte Revision `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6`; explizit optionaler Test | Releaseprüfung ruft ihn zwingend mit bereitgestelltem Bestand auf; fehlender Bestand bleibt fehlender Nachweis |
|
||
| Inventar | Sprach- und vollständige Forms-Einträge; feste Sollziele, Absenkungs- und Ereignistests vorhanden | Nicht auf historische 285 Spracheinträge verkürzen; finale vollständige Null-offen-Abnahme |
|
||
| Leistung | Vorhandene Compile- und VM-Benchmarks; Phase-5-Compile 0,74/98 ms auf M5 Max | Aktuelle Referenzmessung statt vorsorglicher Optimierung; historische Werte nicht als Phase-6-Ergebnis ausgeben |
|
||
| Terminal | TestBackend und lokaler Unix-PTY-Test vorhanden | Tatsächliche Emulator-/Systemmatrix einschließlich Windows und Linux arm64 ergänzen |
|
||
| CI | Keine Workflowdateien; Origin meldet Gitea 1.25.4 | Vier passende Runner und tatsächliche Actions-Läufe nachweisen; Verfügbarkeit bisher nicht bestätigt |
|
||
| Doku | README „Projektrahmen“, alte Korpus-Phasenhinweise, Exportbackend noch als geplant beschrieben | 07 gleicht Installation, Hilfe, Migration, Beispiele und Plan an ausgelieferte Programme an |
|
||
|
||
## Change-Aufteilung und Abhängigkeiten
|
||
|
||
| Nr. | Change | Voraussetzungen | Eigenständige Leistung |
|
||
| --- | --- | --- | --- |
|
||
| 01 | [Kompatibilität und Leistungsabnahme](proposal.md) | Phase 5 | Reproduzierbarer Abnahmesatz, Fremdkorpus, Inventarbasis und begründeter Performance-Pass |
|
||
| 02 | [Native Executables](../2026-09-07-phase-6-02-native-executables/proposal.md) | 01 | Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung |
|
||
| 03 | [P-Code-Bibliotheken und Linker](../../phase-6-03-pcode-bibliotheken-und-linker/proposal.md) | 02 | TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher |
|
||
| 04 | [IDE-Exportanbindung](../../phase-6-04-ide-exportanbindung/proposal.md) | 02, 03 | Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse |
|
||
| 05 | [Plattformmatrix](../../phase-6-05-plattformmatrix/proposal.md) | 01–04 | Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen |
|
||
| 06 | [Gitea Actions und Releases](../../phase-6-06-gitea-actions-und-releases/proposal.md) | 01–05 | Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad |
|
||
| 07 | [Dokumentation und Phasenabnahme](../../phase-6-07-dokumentation-und-phasenabnahme/proposal.md) | 01–06 | Aktuelle Anleitungen/Hilfe, ausgelieferter Gesamtweg und belegter Phase-6-Abschluss |
|
||
|
||
Die Reihenfolge 01 bis 07 ist gültig. Native Zielprüfungen in 02/03/05 sind
|
||
vor 06 zunächst lokal auf passenden Prüfrechnern ausführbar; 06 automatisiert
|
||
diese Aufrufe in Actions und liefert die endgültigen Pakete. Dadurch entsteht
|
||
kein Kreis „Export benötigt Release, Release benötigt Export“. Endgültige
|
||
Evidenz mit Releasepaketen liegt in 07. Das Scaffolding von Changes und die
|
||
OpenSpec-Artefaktstatus erzwingen diese fachlichen Abhängigkeiten nicht.
|
||
Beim Anwenden sind umgesetzte/synchronisierte Vorgänger und ihre Ergebnisse
|
||
zu prüfen; nach Archivierung liegen sie unter `openspec/changes/archive/`.
|
||
|
||
## Zuordnung der acht PLAN-Punkte
|
||
|
||
| Phase-6-Planpunkt | Umsetzung | Endgültiger Nachweis |
|
||
| --- | --- | --- |
|
||
| Kompatibilitäts-Testsuite | 01, native Erweiterungen 02–04 | Korpus-/Native-Parität, 06/07 |
|
||
| Plattformtests | 05 | Windows Terminal, Terminal.app, je zwei Linux-Emulatoren auf amd64 und arm64; 07 |
|
||
| Performance-Pass nur falls nötig | 01 | Vergleichbare VM-Messung plus bestehende Compile-Budgets; finale Revision 07 |
|
||
| Native Standalone-Executables | 02, IDE 04 | Start ohne Quellen/TBC/tb/tbc; entpackte Actions-Pakete 06/07 |
|
||
| P-Code-Bibliotheken und Linker | 03, IDE 04 | Identische TBL mit separaten BASIC-Verbrauchern auf allen vier Zielen; Paketprüfung 06/07 |
|
||
| Dokumentation und Beispiele | Fachbegleitend 02–06, Abschluss 07 | Ausgeführte Anleitungen, Help-/Link-/Offlineprüfung |
|
||
| CI und Releases | 06 | Vier tatsächlich erfolgreiche Gitea-Zieljobs und geprüfte Archive |
|
||
| Vollständigkeit des Inventars | Grundlage 01, endgültig 07 | Vollständiges aktuelles Sprach-/Forms-Inventar, null offen, korrekte Non-Feature-Fundstellen |
|
||
|
||
## Verbindliche Release-Matrix
|
||
|
||
| System | Architektur | Rust-Target | Archiv |
|
||
| --- | --- | --- | --- |
|
||
| Windows | amd64 | `x86_64-pc-windows-msvc` | `terminalbasic-<version>-windows-amd64.7z` |
|
||
| macOS | arm64 | `aarch64-apple-darwin` | `terminalbasic-<version>-macos-arm64.tar.gz` |
|
||
| Linux | amd64 | `x86_64-unknown-linux-gnu` | `terminalbasic-<version>-linux-amd64.tar.gz` |
|
||
| Linux | arm64 | `aarch64-unknown-linux-gnu` | `terminalbasic-<version>-linux-arm64.tar.gz` |
|
||
|
||
Die Archive enthalten `tb`/`tbc` und die native Runtime-/Exportvorlage `tbrt`
|
||
(Windows mit `.exe`) sowie Metadaten, Lizenz und Benutzungshinweise. Jedes fertige Archiv wird
|
||
entpackt und auf seinem Ziel geprüft. Mindest-OS-/Systembibliotheksstände
|
||
werden aus dem festgelegten tatsächlichen Builder und Zieltest dokumentiert.
|
||
Standalone bedeutet keine separat installierte TB-Runtime; gewöhnliche
|
||
Betriebssystembibliotheken und explizite OPEN-/RUN-Ressourcen bleiben benannt.
|
||
|
||
## Architekturentscheidungen und Abnahmegrenzen
|
||
|
||
- Vorhandene Sprache und TBVM bleiben erhalten. Die Native-Erzeugung verpackt
|
||
Kompilat und Runtime, sie übersetzt BASIC nicht neu über LLVM/JIT.
|
||
- Vorlagenbau findet in den passenden Actions statt; `make exe` beim Anwender
|
||
benötigt keine C-/Rust-Compiler oder nativen Linker. Auch der TBL-Bau und P-Code-Linkpfad laufen allein mit TB-Tools. Verfügbarkeit eines Cross-Exports
|
||
hängt von Vorlage und korrekter Finalisierung ab, nicht nur von einem Dropdown.
|
||
- Mac-Nutzlasteinbau und Signierung werden vor Dateiveröffentlichung geprüft.
|
||
Die bisherige pauschale Aussage über portables Anhängen allein ist kein
|
||
Mach-O-Nachweis. [Apple Code Signing](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)
|
||
- Gitea-Runner werden über eindeutige Ziel-Labels gebunden. Vier Workflowzeilen
|
||
beweisen keine vier vorhandenen Maschinen. [Gitea Runner](https://docs.gitea.com/1.25/usage/actions/act-runner/)
|
||
- Der Phase-5-Exportvertrag wird in 04 bedingt fortgeführt: Ohne Backend bleibt
|
||
die verständliche Sperre geprüft, mit Backend muss wirkliche Dateierzeugung
|
||
nachgewiesen werden. Beide MODIFIED-Blöcke erhalten alle bisherigen Szenarien.
|
||
- Golden-Ausgaben, Inventareinträge und Non-Features dürfen nicht zur
|
||
Ergebnisbeschönigung verändert werden. Fachfehler gehören in ihren
|
||
bestehenden Implementierungspfad und erhalten eine Regression.
|
||
- Fehlende externe Rechner, Emulatoren, Releasezugänge oder Fremdkorpora bleiben
|
||
sichtbare Voraussetzungen. Nur lokale Headless-Prüfungen schließen Phase 6 nicht.
|
||
|
||
## Abnahmestrategie
|
||
|
||
Jeder Change liefert einen eigenen verification.md mit Spec-/Taskzuordnung,
|
||
konkreten Befehlen, Revision, Resultaten und Grenzen. Für 02–06 werden außerdem
|
||
native Ziel- beziehungsweise Actions-Nachweise benötigt. 07 prüft die gesamte
|
||
Kette mit den finalen Paketen. PLAN-Checkboxen bleiben während des Proposals offen.
|
||
Die jetzige Planung verändert keine Produktdateien, installiert keine Runner
|
||
und veröffentlicht keine Artefakte.
|
||
|
||
## Bestätigter Library- und Linkvertrag
|
||
|
||
`.tbl` ist die festgelegte Extension für portable P-Code-Bibliotheken.
|
||
Die Bezeichnung native Systembibliothek betrifft die eigentliche Runtime:
|
||
Sie wird nativ kompiliert und ist Bestandteil von `tbrt`. Ein eigener
|
||
C-ABI-/`.lib`-/`.a`-Export von BASIC ist nicht vorgesehen.
|
||
|
||
```text
|
||
BASIC-Quellen ── tbc build --library ──► Bibliothek.tbl
|
||
Hauptprojekt + Bibliothek.tbl ── tbc link ──► vollständiges Programm.tbc
|
||
Programm.tbc + tbrt des Zielsystems ── Verpackung ──► natives Executable
|
||
```
|
||
|
||
`tbc link --exe` verbindet beide letzten Schritte; `tbc build --exe` und
|
||
Make EXE verwenden dieselben Dienste. `.MAK` hält die TBL-Verweise, damit
|
||
auch IDE-Start/Check/Debugger dieselben Bibliotheken verwenden. Make Library
|
||
bietet `.tbl` ohne native Zielwahl an. Library-Bau und Linken benötigen beim
|
||
Anwender keinen C-/Rust-Compiler oder nativen Linker. Die EXE-Finalisierung
|
||
prüft ihre dokumentierten Systemvoraussetzungen separat.
|
||
|
||
Der vorhandene Modul-Linkpfad wird erweitert; ein TBL enthält die dafür
|
||
nötigen Deklarationen und unverknüpften Produkte. Native Runtime, P-Code und
|
||
Formatversionen werden eindeutig getrennt. Initialisierung, COMMON, Forms,
|
||
DATA und Fehlerorte werden mit entsprechenden Quellprojekten verglichen.
|
||
|
||
Alle sieben Changes enthalten Proposal, Design, Delta-Specs und prüfbare,
|
||
noch offene Implementierungsaufgaben. Es besteht keine offene Formatentscheidung.
|
||
Vollständige Planung bedeutet weiterhin keine umgesetzte Phase 6.
|
||
|
||
## Prüfung der Planung
|
||
|
||
Alle sieben Changes sind im OpenSpec-Planungsstatus vollständig und für
|
||
die Umsetzung bereit: 75 offene Aufgaben, 33 Delta-Anforderungen.
|
||
`openspec validate --all --strict --no-interactive` besteht mit 30 geprüften
|
||
Specs/Changes. Relative Dokumentverweise und der Erhalt bestehender
|
||
Szenarien in den MODIFIED-Blöcken wurden geprüft. Der Help-Katalogtest
|
||
`catalog_links_and_missing_targets_are_checked` besteht mit dem geänderten
|
||
PLAN. Phase 6 bleibt bei 0/8 abgeschlossenen Planpunkten; diese Prüfungen
|
||
sind Planungs-/Dokumentationsnachweise, keine Implementierungsabnahme.
|