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