Chili Palmer
7e6fa6ea88
Entscheidungen festgehalten: TBVM bestaetigt und eingebettet in die Executables; durchgaengig UTF-8 statt CP437 (dokumentierte Abweichung). - docs/: Sprachreferenz, Forms-Referenz, Dateiformate, TBVM-Design - tb-runtime::errors: klassischer Laufzeitfehler-Katalog (implementiert) - tb-ui::screen: 80x25-Unicode-Zellenpuffer mit 16-Farben-Abbildung, Scrollbereich (VIEW PRINT), Letterboxing; Ratatui-Widget + Tests - Spike: cargo run -p tb-ui --example spike (Farben, Unicode, Tasten, Maus) - tests/compat/: erste Referenzprogramme mit byte-genauer Sollausgabe Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Kompatibilitäts-Testkorpus
Kleine Referenzprogramme mit dokumentierter erwarteter Ausgabe. Jede
name.bas hat eine name.out mit der exakten Konsolenausgabe (UTF-8,
LF-Zeilenenden). Achtung: PRINT gibt Zahlen mit führendem Leerzeichen
(bzw. -) und nachgestelltem Leerzeichen aus — auch am Zeilenende. Die
.out-Dateien enthalten daher signifikante Leerzeichen am Zeilenende;
Editoren dürfen sie nicht wegtrimmen; .gitattributes schützt die Dateien
vor Zeilenenden-Konvertierung.
Ab Phase 2 führt ein Test-Harness (cargo test) jede Datei per
tbdosc run aus und vergleicht die Ausgabe. Bis dahin dienen die
.out-Dateien als festgehaltene Verhaltensspezifikation — wo möglich am
Vorbild (Emulator) verifiziert, sonst nach Referenzlage rekonstruiert
und mit TODO verify im Programmkopf markiert.
Konventionen:
- Nur Konsolen-E/A (keine Forms) bis Phase 4
- Kein Zufall/Zeit, außer der Test fixiert die Saat (
RANDOMIZEmit Konstante) bzw. prüft nur Invarianten