Zwei neue Capabilities in den Hauptspecs: - datei-eio: Dateiverwaltung, drei Zugriffsarten, UTF-32-Festtextfelder, Recordkonvertierung, Sperren, Dateisystem-Anweisungen - sprachinventar: das Vollstaendigkeits-Inventar als pruefbares Artefakt Fortgeschrieben: textbildschirm (Doppelzellen, Groessenunabhaengigkeit, Bildschirmanweisungen), konsolen-basisbibliothek (Host-Neuschnitt, volle String-/Format-/Datums-/Finanzbibliothek), kompat-testkorpus (Snapshot-Vergleich, Nachweis der Groessenunabhaengigkeit), sprach-frontend (Signaturpflicht, ON-ERROR-Scoping, DATA-Rohtext). Bilanz: +32 Anforderungen, 6 geaendert, 1 ersetzt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.4 KiB
ADDED Requirements
Requirement: Korpusabdeckung der Phase-3-Semantik
Der Korpus SHALL um Referenzprogramme mit dokumentierter Sollausgabe für
die Bildschirmsteuerung (LOCATE, COLOR, CLS, VIEW PRINT-Scrollen,
CSRLIN/POS, Zurücklesen per SCREEN), die Formatierung
(PRINT USING inklusive Feldüberlauf), breite Unicode-Zeichen
(Doppelzellen, Umbruch am rechten Rand), Datum und Zeit sowie die
Datei-E/A in allen drei Zugriffsarten erweitert werden. Dateiprogramme
MUST in einem temporären Arbeitsverzeichnis laufen und dürfen keine
Artefakte im Projektbaum hinterlassen.
Scenario: Bildschirmsteuerung als Korpustest
- WHEN die Testsuite läuft
- THEN existiert ein Korpusprogramm, das mit
LOCATEundCOLORan definierten Positionen ausgibt, und sein Snapshot entspricht der Sollausgabe
Scenario: Datei-Korpustest hinterlässt nichts
- WHEN ein Datei-E/A-Korpusprogramm gelaufen ist
- THEN ist das Arbeitsverzeichnis wieder entfernt und der Projektbaum unverändert
Requirement: Nachweis der Größenunabhängigkeit
Die Bildschirmgröße des Test-Hosts SHALL je Korpusprogramm explizit festgelegt und in der Sollausgabe vermerkt sein; ein Vorgabewert MUST NOT stillschweigend gelten. Mindestens ein Korpusprogramm SHALL bei zwei verschiedenen Bildschirmgrößen laufen und je Größe eine eigene Sollausgabe besitzen, um nachzuweisen, dass Löschen, Umbruch, Scrollen und Cursorgrenzen der jeweiligen Größe folgen. Mindestens ein Korpusprogramm SHALL eine Größenänderung während der Ausführung durchlaufen und danach die neuen Grenzen ausnutzen.
Scenario: Gleiches Programm bei zwei Größen
- WHEN dasselbe Bildschirm-Korpusprogramm bei 80×25 und bei 120×40 läuft
- THEN stimmt jede Ausgabe mit der Sollausgabe ihrer Größe überein und die Sollausgaben unterscheiden sich in Umbruch- und Scrollverhalten
Scenario: Größenänderung mitten im Programm
- WHEN der Test-Host während der Ausführung von 80×25 auf 120×40 wechselt
- THEN bleibt der bisherige Inhalt oben links erhalten und die anschließende Ausgabe nutzt die neuen Grenzen
MODIFIED Requirements
Requirement: Korpusdateien mit byte-genauer Sollausgabe
Jedes Korpusprogramm tests/compat/<name>.bas SHALL eine <name>.out
mit dem exakten Sollzustand des Bildschirms besitzen (UTF-8,
LF-Zeilenenden). Die Sollausgabe SHALL den Zellenpuffer als Textbild
abbilden, getrimmt bis zur letzten belegten Zeile und Spalte; nachgestellte
Leerzeichen innerhalb einer Zeile sind signifikant — PRINT gibt Zahlen
mit führendem Vorzeichen-/Leerzeichen und nachgestelltem Leerzeichen aus.
Verwendet ein Programm COLOR, SHALL die Sollausgabe zusätzlich eine
Attributebene gleicher Abmessung enthalten; ohne COLOR MUST sie
entfallen. .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)
Scenario: Getrimmter Snapshot
- WHEN ein Korpusprogramm nur zwei Zeilen ausgibt
- THEN umfasst die Sollausgabe genau diese zwei Zeilen und keine leeren Folgezeilen
Scenario: Attributebene nur bei COLOR
- WHEN ein Korpusprogramm ohne
COLORläuft - THEN enthält seine
.outkeine Attributebene
Requirement: Laufzeitvergleich über den Korpus
Ein automatischer Test SHALL jede Korpusdatei tests/compat/*.bas
kompilieren, über die VM mit einem Host ohne Terminal ausführen und den
resultierenden Bildschirmzustand gegen die zugehörige .out-Datei
vergleichen — getrimmt, mit signifikanten Leerzeichen innerhalb der
Zeilen und, sofern vorhanden, einschließlich der Attributebene. Bei
Abweichung MUST der Test Datei, erste abweichende Zeile sowie Soll und
Ist nennen; weicht nur die Attributebene ab, MUST er Zeile, Spalte, Soll-
und Ist-Attribut nennen.
Scenario: Korpus läuft mit korrekter Ausgabe
- WHEN die Laufzeit-Testsuite läuft
- THEN stimmt der Bildschirmzustand jeder Korpusdatei mit ihrer
.outüberein
Scenario: Abweichung wird benannt
- WHEN ein Korpusprogramm eine abweichende Ausgabe erzeugt
- THEN schlägt der Test fehl und nennt Datei, Zeilennummer, Soll- und Ist-Zeile
Scenario: Abweichendes Farbattribut
- WHEN ein Korpusprogramm dasselbe Textbild, aber ein abweichendes Attribut erzeugt
- THEN schlägt der Test fehl und nennt Zeile, Spalte, Soll- und Ist-Attribut