Chili Palmer
da23d52036
Change "baseline-phasen-0-1" (Explore/Retrofit des umgesetzten Stands), per Archiv in die Haupt-Specs uebernommen und validiert: - sprach-frontend (6 Requirements: Lexik, Literal-Typisierung, Anweisungs-Grammatik, Semantik, Non-Feature-Abweisung, Diagnostik) - laufzeitfehler (2: Katalog 1-480, Unprintable error) - textbildschirm (5: dynamische Groesse, PRINT/Scroll, Cursor-API, Farbpalette/Blink, Unicode-Zellenmodell) - kompat-testkorpus (2: byte-genaue Sollausgaben, Frontend-Meilenstein) Workflow ab jetzt je Phase: Explore -> Proposal -> Umsetzung -> Archiv. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
54 lines
2.4 KiB
Markdown
54 lines
2.4 KiB
Markdown
## Why
|
||
|
||
Die Phasen 0 (Exploration, Grundsatzentscheidungen, Referenzrekonstruktion)
|
||
und 1 (Sprach-Frontend) sind bereits implementiert, aber noch nicht als
|
||
OpenSpec-Spezifikationen erfasst. Dieses Baseline-Change rüstet die Specs
|
||
für den umgesetzten Stand nach, damit alle folgenden Phasen auf einem
|
||
vollständigen Spec-Fundament aufsetzen (Workflow ab jetzt: Explore →
|
||
Proposal → Umsetzung je Phase).
|
||
|
||
## What Changes
|
||
|
||
- Nachdokumentation des implementierten Verhaltens als Spezifikationen —
|
||
keine Code-Änderungen.
|
||
- Erfasst werden die vier umgesetzten Fähigkeiten:
|
||
- Sprach-Frontend (Lexer, Parser, semantische Analyse) aus Phase 1
|
||
- Laufzeitfehler-Katalog aus Phase 0
|
||
- Textbildschirm-Emulation (dynamische Größe, Farben) aus Phase 0
|
||
- Kompatibilitäts-Testkorpus (Konventionen) aus Phase 0
|
||
- Projekt-Grundsatzentscheidungen (TBVM, UTF-8, dynamische Terminalgröße,
|
||
Non-Features, Performance-Budgets) bleiben in PLAN.md und
|
||
docs/sprachreferenz.md dokumentiert; die Specs referenzieren sie.
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
- `sprach-frontend`: Kompilierbarkeit von Terminal-Basic-Quelltext —
|
||
Lexik (Typ-Suffixe, Literal-Typisierung, Zeilenfortsetzung,
|
||
Metabefehle), vollständige Anweisungs-Grammatik, semantische Prüfung
|
||
(Typen, implizite Deklaration, DEFtype, OPTION EXPLICIT, UDT-Felder,
|
||
Konstanten), Diagnostik mit Vorbild-Meldungstexten und Compile-Zeit-
|
||
Abweisung deklarierter Non-Features.
|
||
- `laufzeitfehler`: klassischer Fehlerkatalog (Codes 1–76, ISAM 80–89,
|
||
Forms 260–480) mit originalgetreuen Meldungstexten als
|
||
Kompatibilitätsvertrag für `ERR`/`ERROR n`.
|
||
- `textbildschirm`: emulierter Unicode-Textbildschirm mit dynamischer
|
||
Terminalgröße (Minimum 80×25), klassischer 16-Farben-Palette,
|
||
PRINT-/LOCATE-/CLS-/VIEW-PRINT-Semantik und Blink-als-Hell-Simulation.
|
||
- `kompat-testkorpus`: Konventionen des Kompatibilitäts-Testkorpus
|
||
(byte-genaue Sollausgaben, signifikante Zeilenend-Leerzeichen,
|
||
Frontend-Meilenstein „Korpus parst und wird typgeprüft").
|
||
|
||
### Modified Capabilities
|
||
|
||
<!-- keine — es existieren noch keine Haupt-Specs -->
|
||
|
||
## Impact
|
||
|
||
- Nur `openspec/`-Artefakte (Delta-Specs → Haupt-Specs nach Sync/Archiv).
|
||
- Kein Code, keine Doku unter `docs/` betroffen.
|
||
- Referenzen: PLAN.md (Phasen 0/1 abgeschlossen), docs/sprachreferenz.md,
|
||
crates/tb-frontend, crates/tb-runtime (errors), crates/tb-ui (screen),
|
||
tests/compat.
|