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>

openspec/specs/kompat-testkorpus/spec.md

@@ -10,16 +10,28 @@ geprüft werden.
 
 ### 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
+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: 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
@@ -32,19 +44,26 @@ hinzu.)
 
 ### Requirement: Laufzeitvergleich über den Korpus
 Ein automatischer Test SHALL jede Korpusdatei `tests/compat/*.bas`
-kompilieren, über die VM mit Capture-Host ausführen und die Ausgabe
-byte-genau (inklusive nachgestellter Leerzeichen und LF-Zeilenenden)
-gegen die zugehörige `.out`-Datei vergleichen. Bei Abweichung MUST der
-Test Datei, erste abweichende Zeile sowie Soll und Ist nennen.
+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 die Ausgabe jeder Korpusdatei byte-genau mit ihrer `.out` überein
+- **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
+
 ### Requirement: Korpusabdeckung der Phase-2-Semantik
 Der Korpus SHALL um Referenzprogramme mit dokumentierter Sollausgabe für
 die Zahlenkonvertierungs-Matrix (Rundung, Ganzzahldivision, logische
@@ -55,3 +74,39 @@ Prozeduraufrufe mit BYREF-/BYVAL-Wirkung erweitert werden.
 #### Scenario: Konvertierungsmatrix als Korpustest
 - **WHEN** die Laufzeit-Testsuite läuft
 - **THEN** existiert ein Korpusprogramm, das die Matrix-Randfälle ausgibt, und seine Ausgabe entspricht der dokumentierten Sollausgabe
+
+### 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