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	Phase 5	Reproduzierbarer Abnahmesatz, Fremdkorpus, Inventarbasis und begründeter Performance-Pass
02	Native Executables	01	Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung
03	P-Code-Bibliotheken und Linker	02	TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher
04	IDE-Exportanbindung	02, 03	Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse
05	Plattformmatrix	01–04	Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen
06	Gitea Actions und Releases	01–05	Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad
07	Dokumentation und Phasenabnahme	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
Gitea-Runner werden über eindeutige Ziel-Labels gebunden. Vier Workflowzeilen beweisen keine vier vorhandenen Maschinen. Gitea 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.

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.

12 KiB Raw Permalink Blame History Unescape Escape