# 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.