Files
Chili Palmer d0461bea34 OpenSpec: phase-3-runtime-bildschirm archiviert, Delta-Specs gesynct
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>
2026-09-04 06:55:02 +02:00

4.4 KiB
Raw Blame History

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 LOCATE und COLOR an 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; 3 enthä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 COLOR läuft
  • THEN enthält seine .out keine 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