3.2 KiB
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
- Bestehende docs als einzige Hilfe-/Referenzquelle erhalten. Native Runtime in tbrt, portables TBL und vollständiges TBC ausdrücklich unterscheiden; native
.lib/.aoder 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. - 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.
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.- 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.
- Veraltete Hinweise in PLAN (einschließlich der doppelten Einordnung von
tbc build --exeunter 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.