## 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 einschließlich 05a 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 neun Planpunkte erhalten explizite Nachweise aus 01–06 einschließlich 05a 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.