28 lines
3.3 KiB
Markdown
28 lines
3.3 KiB
Markdown
## 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.
|