Plan Phase 6 runtime, P-code libraries and Gitea releases

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-07

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/design.md

@@ -0,0 +1,27 @@
+## Context
+
+README nennt derzeit noch „Projektrahmen“, die Korpus-README enthält frühere Phasenaussagen, Exportseiten nennen das noch fehlende Backend. PLAN verweist bei der Endabnahme historisch auf 285 Spracheinträge; das heutige Inventar führt zusätzlich das vollständige Forms-Objektmodell. Help bettet docs und PLAN zur Buildzeit ein. 01–06 liefern neue Fähigkeiten und konkrete Artefaktnachweise.
+
+## Goals / Non-Goals
+
+**Goals:** Ein zusammenhängender, reproduzierbarer Nutzerweg aus Releaseartefakten und eine belegte Gesamtentscheidung über Phase 6.
+
+**Non-Goals:** Sprachelemente aus Stufe 2, neuer Dokumentationsgenerator, Abnahme durch bloßes Abhaken, automatische Ausdehnung von Non-Features.
+
+## Decisions
+
+1. Bestehende docs als einzige Hilfe-/Referenzquelle erhalten. Native Runtime in tbrt, portables TBL und vollständiges TBC ausdrücklich unterscheiden; native `.lib`/`.a` oder eine C-Verbraucherschnittstelle sind kein Phase-6-Exportziel. README, Tutorial, Migration, TBC-/TBL-/tbrt-Vertrag, `tbc link`, IDE-Library-Einbindung, Paketinhalt und OS-Mindeststände anhand der tatsächlichen CLI-/IDE-Implementierung prüfen. Neue Seiten ausdrücklich im Help-Katalog registrieren und interne Links testen. Historische Reports werden nicht rückwirkend als neue Messungen umgeschrieben.
+2. Den Phase-5-Hauptablauf und Abnahmesatz aus 01 verwenden; zusätzliche Schritte arbeiten mit aus 06 entpackten Tools, echten nativen Ausgaben und einem separaten BASIC-Verbraucher aus 03 ohne Library-Quellen. Keine zweite allgemeine Testframeworkschicht. Pro Ziel konkrete Prozess-/Terminal-/Dateiresultate aufzeichnen.
+3. `inventar.rs`, feste Sollquellen und VM-Ereignisauslöser erneut vollständig ausführen; Summen aus allen aktuellen Einträgen ermitteln. Historische 285 Sprachelemente sind eine Herkunftszahl, keine Sollobergrenze. Gefundene Lücken in ihrem Fachpfad beheben und deren Proben wiederholen; Quellen und Non-Feature-Fundstellen erhalten.
+4. Die acht Planpunkte erhalten explizite Nachweise aus 01–06 plus finalem Gesamtweg. Referenzmessung nach sämtlichen Fachkorrekturen, kein Wiederholen unveränderter teurer Prüfungen ohne Anlass. Gitea-Run-/Release-IDs, Commit, Paketprüfsummen und Matrixzellen bilden die Releaseevidenz.
+5. Veraltete Hinweise in PLAN (einschließlich der doppelten Einordnung von `tbc build --exe` unter Stufe 2) und Dokumenten konsistent bereinigen. Tatsächliche Stufe-2-Ideen bleiben unbeschlossen. Ein fehlender Prüfrechner oder Releasezugang bleibt ein Blocker für die Abnahme, keine unterstellte erfolgreiche Prüfung.
+
+## Risks / Trade-offs
+
+- Dokumente beschreiben Wünsche statt Code → Anleitungen mit entpackten Programmen ausführen und Help-Katalog prüfen.
+- Ein später Fix entwertet vorherige Matrix → betroffene Prüfpfade auf der neuen Revision wiederholen und veraltete Evidenz kennzeichnen.
+- Inventarsummen werden verkürzt → vollständige aktuelle Tabellen inklusive Forms prüfen, nicht nur historische Kernzahl.
+
+## Migration Plan
+
+Dokumente schrittweise mit jeweiligen Fachfeatures aktualisieren, hier endgültig abgleichen. PLAN-Checkboxen erst nach vollständiger Abnahme setzen. Releasekorrekturen führen zu neuem nachvollziehbarem Artefaktstand; vorhandene Releases bleiben referenzierbar.

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/proposal.md

@@ -0,0 +1,24 @@
+## Why
+
+Nach den Einzelchanges muss Phase 6 anhand tatsächlich ausgelieferter Programme, aktueller Dokumentation und vollständiger Inventarnachweise abgeschlossen werden. Veraltete README-/Korpus-/Exportbeschreibungen und bloß vorhandene Workflowdateien dürfen keinen fertigen Release vortäuschen.
+
+## What Changes
+
+- README, Sprach-/Migrations-/Dateiformat-/IDE-/Exportdokumentation und ausführbare Beispiele auf den endgültigen Stand bringen; eingebettete Hilfe mitprüfen.
+- Installation aus allen vier Release-Paketen, IDE-Projektaufbau, TBL-Bau, `tbc link`, IDE-Library-Einbindung und eigenständige EXE-Nutzung zusammenhängend abnehmen.
+- Das vollständige aktuelle Sprach- und Forms-Inventar mit null offenen Einträgen und begründeten Non-Features prüfen; die historische Zahl 285 nicht als Grenze des erweiterten Inventars verwenden.
+- Alle acht Phase-6-Planpunkte mit aktuellen Nachweisen, Revisionen und Artefakten verbinden und erst dann abschließen.
+
+## Capabilities
+
+### New Capabilities
+
+- `phase-6-abnahme`: Dokumentierte, auslieferbare Gesamtleistung mit vollständiger Inventar- und Artefaktabnahme.
+
+### Modified Capabilities
+
+Keine. Bestehende Sprach-/Inventarverträge werden erneut geprüft, nicht abgeschwächt.
+
+## Impact
+
+PLAN.md, README.md, docs, examples und Help-Katalog sowie Abschlussnachweise. Keine vorgezogenen Stufe-2-Spracherweiterungen. Abhängigkeiten: alle Changes 01–06 mit synchronisierten Specs und tatsächlichen Prüfergebnissen; abgeschlossene Aufgabenlisten allein genügen nicht.

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/specs/phase-6-abnahme/spec.md

@@ -0,0 +1,33 @@
+## Purpose
+
+Schließt Phase 6 ausschließlich anhand aktueller, nachvollziehbarer Dokumentation, vollständiger Inventarprüfungen und tatsächlich nutzbarer Releaseartefakte ab.
+
+## ADDED Requirements
+
+### Requirement: Dokumentation des ausgelieferten Verhaltens
+README, Sprach-/Bibliotheks-/Migrationsreferenz, IDE-Hilfe und Beispiele SHALL die tatsächlich ausgelieferten Befehle, Formate, Zielplattformen und Systemvoraussetzungen widerspruchsfrei erklären. Native Runtime in tbrt, eigenständiges EXE, vollständiges TBC und wiederverwendbares TBL SHALL unterschieden und Installation aus den vier Gitea-Releasearchiven beschrieben sein. Interne Hilfelinks SHALL auflösbar und die Hilfe offline verfügbar bleiben.
+
+#### Scenario: Anleitung aus dem Release verwenden
+- **WHEN** ein Benutzer der Installations- und Exportanleitung aus dem entpackten Release folgt
+- **THEN** erreicht er mit den beschriebenen Befehlen ein lauffähiges natives Programm beziehungsweise eine nutzbare Bibliothek ohne undokumentierte Entwicklungsumgebung
+
+### Requirement: Vollständiges Inventar ohne offene Einträge
+Die Endabnahme SHALL das gesamte aktuelle Sprach- und Forms-Inventar gegen Referenzquellen, Frontend, Absenkung und tatsächliche Laufzeitauslöser prüfen. Die Zahl offener Einträge SHALL null sein. Non-Features SHALL weiterhin ausdrücklich vom Projekt festgelegt und mit Fundstelle dokumentiert sein; fehlende Funktionen MUST NOT allein zur Abnahme in Non-Features umbenannt werden.
+
+#### Scenario: Ein offener oder falsch behaupteter Eintrag
+- **WHEN** ein Inventareintrag offen ist oder sein behaupteter Laufzeitpfad nicht nachgewiesen werden kann
+- **THEN** bleibt die Endabnahme offen und nennt den Eintrag und seinen fehlenden Nachweis unabhängig von der historischen Inventargröße
+
+### Requirement: Gesamtweg aus ausgelieferten Artefakten
+Die Endabnahme SHALL mit den fertigen Releasepaketen auf Windows amd64, macOS arm64 und Linux amd64/arm64 Installation, IDE-Projektaufbau, Speichern, Debuggen, native Erzeugung und unabhängige Nutzung prüfen. Für TBL-Bibliotheken SHALL quellfreie Wiederverwendung durch ein separates BASIC-Projekt über CLI-Linkbefehl und IDE, für Executables ein Start ohne TB-Installation belegt sein. Gegenüber den geltenden Sprachverträgen SHALL kein offener Befund verbleiben.
+
+#### Scenario: Releaseprogramm außerhalb des Checkouts
+- **WHEN** der dokumentierte Gesamtweg außerhalb des Entwicklungscheckouts mit einem entpackten Release durchgeführt wird
+- **THEN** funktionieren Projekt-/Export-/Nutzungsschritte ausschließlich mit den beschriebenen Artefakten und Systemvoraussetzungen
+
+### Requirement: Evidenzgebundener Phasenabschluss
+Jeder Phase-6-Planpunkt SHALL vor dem Abhaken auf bestandene Nachweise mit Revision, Plattform und Artefakt verweisen. Workspace-Regressionen, Native-/Verbrauchertests, Plattformmatrix, Inventar und bestehende Compile-Budgets SHALL auf dem finalen Stand bestehen. Fehlende externe Systeme oder noch nicht ausgeführte Workflows MUST als fehlende Nachweise sichtbar bleiben.
+
+#### Scenario: Vollständige Artefakte aber fehlender Test
+- **WHEN** alle Change-Dokumente vorhanden sind, aber eine erforderliche Plattform- oder Releaseprüfung fehlt
+- **THEN** bleibt Phase 6 offen und der Bericht unterscheidet vollständige Planung von bestandener Umsetzung

openspec/changes/phase-6-07-dokumentation-und-phasenabnahme/tasks.md

@@ -0,0 +1,18 @@
+## 1. Dokumentation und Beispiele
+
+- [ ] 1.1 README und Installations-/CLI-/Exportdokumentation auf die vier Gitea-Releasepakete aktualisieren; alle angegebenen Befehle müssen mit entpackten Executables außerhalb des Checkouts funktionieren.
+- [ ] 1.2 Migration, Sprach-/Dateiformat-/Library-Vertrag und Systemvoraussetzungen abgleichen; konkrete Beispiele müssen EXE/TBC/TBL, native Runtime in tbrt, externe Laufzeitdateien und Library-Wiederverwendung korrekt demonstrieren.
+- [ ] 1.3 IDE-Tutorial und eingebettete Hilfe auf die echte Exportanbindung aktualisieren; Katalog-/Offline-/Linktests und tatsächliche Menü-/F1-Wege müssen bestehen.
+- [ ] 1.4 Veraltete PLAN-/Korpus-/README-Aussagen einschließlich historischer Inventargrenze und doppeltem Stufe-2-EXE-Punkt bereinigen; Abgleich muss Phase-6-Leistung von weiterhin unbeschlossenen Erweiterungen trennen.
+
+## 2. Endgültige Nachweise
+
+- [ ] 2.1 Vollständiges aktuelles Sprach-/Forms-Inventar mit Sollquellen, Absenkung und Ereignisauslösern prüfen; null offene Einträge und jede Non-Feature-Fundstelle im Bericht belegen.
+- [ ] 2.2 Gesamtweg Installation → IDE-Projekt → Debuggen → TBL-Export → separates BASIC-Projekt/`tbc link` → eigenständige EXE-Nutzung auf allen vier Zielen ausführen; jeweilige Paketprüfsumme, Revision und beobachtete Resultate protokollieren.
+- [ ] 2.3 Alle sieben Changes und ihre Abhängigkeiten gegen synchronisierte Specs prüfen; gefundene Fachbefunde im zuständigen Bereich beheben und betroffene Nachweise bis zu null offenen Befunden wiederholen.
+- [ ] 2.4 Workspace-, TBL-Link-/native EXE-, Plattform-/Release- und Compile-/VM-Leistungsnachweise auf dem finalen Stand abschließen; fehlende externe Nachweise ausdrücklich offen lassen, keine historischen Messungen als neue ausgeben.
+
+## 3. Phasenabschluss
+
+- [ ] 3.1 Alle acht PLAN-Punkte einer bestandenen Evidenz zuordnen und erst dann abhaken; Bericht muss Gitea-Run-/Releasebezug, vier Targets und verbleibende Stufe-2-Abgrenzung zeigen.
+- [ ] 3.2 Abschließende Doku-/Help-/OpenSpec-Konsistenz prüfen; keine unaufgelösten Links, widersprüchlichen Exporthinweise oder offenen Phase-6-Befunde dürfen verbleiben.