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>
1.3 KiB
Purpose
Der Kompatibilitäts-Testkorpus hält das Sollverhalten des Dialekts als ausführbare Spezifikation fest: Referenzprogramme mit byte-genau dokumentierter Ausgabe, gegen die Frontend und (ab Phase 2) Laufzeit geprüft werden.
ADDED Requirements
Requirement: Korpusdateien mit byte-genauer Sollausgabe
Jedes Korpusprogramm tests/compat/<name>.bas SHALL eine <name>.out
mit der exakten Konsolenausgabe besitzen (UTF-8, LF-Zeilenenden).
Nachgestellte Leerzeichen sind signifikant — PRINT gibt Zahlen mit
führendem Vorzeichen-/Leerzeichen und nachgestelltem Leerzeichen aus,
auch am Zeilenende; .gitattributes MUST die .out-Dateien vor
Zeilenenden-Konvertierung schützen.
Scenario: Zahlformatierung in der Sollausgabe
- WHEN ein Korpusprogramm
PRINT 1; 2; 3enthält - THEN lautet die Sollzeile
1 2 3(mit nachgestelltem Leerzeichen)
Requirement: Frontend-Meilenstein über den Korpus
Ein automatischer Test SHALL alle tests/compat/*.bas durch das
Sprach-Frontend führen und fehlschlagen, sobald eine Datei Diagnosen
liefert. (Ab Phase 2 kommt der Laufzeitvergleich tbc run ↔ .out
hinzu.)
Scenario: Korpus bleibt kompilierbar
- WHEN die Frontend-Testsuite läuft
- THEN parsen alle Korpusdateien diagnose-frei und der Test nennt andernfalls Datei und Diagnose