OpenSpec-Review dokumentieren und ISAM-Vertragsabweichungen beheben

openspec/changes/projektmodule-und-kompilat/specs/bytecode-kompilat/spec.md

@@ -0,0 +1,59 @@
+## MODIFIED Requirements
+
+### Requirement: Monomorpher Opcode-Satz
+Der Codegenerator SHALL jedes HIR-Konstrukt in typisierte, monomorphe
+Opcodes übersetzen: Arithmetik, Vergleiche und Konvertierungen tragen den
+Operandentyp im Opcode (kein Tag-Dispatch über Werte zur Laufzeit);
+implizite Konvertierungen erscheinen als explizite Konvertierungs-Opcodes
+an den vom HIR bestimmten Stellen. Der Opcode-Satz SHALL in
+docs/tbvm-design.md vollständig dokumentiert sein.
+
+Die Dokumentation SHALL sämtliche tatsächlich serialisierbaren Instruktionen einschließlich Forms, Ereignissteuerung und Dateioperationen mit Operanden und Encoding führen.
+
+#### Scenario: Gemischter Ausdruck wird monomorph
+- **WHEN** `d# = i% + 1.5#` übersetzt wird (INTEGER-Variable, DOUBLE-Ziel)
+- **THEN** enthält der Bytecode einen Konvertierungs-Opcode INTEGER→DOUBLE und eine DOUBLE-Addition, keinen generischen Additions-Opcode
+
+#### Scenario: Namen sind zur Laufzeit aufgelöst
+- **WHEN** eine Variable oder Prozedur im Bytecode referenziert wird
+- **THEN** geschieht das über Slot- bzw. Tabellenindizes, nicht über Namens-Lookups
+
+### Requirement: `.tbc`-Containerformat
+Das Kompilat SHALL als `.tbc`-Datei serialisierbar und wieder ladbar sein:
+Magic `TBC\0`, Formatversion und dokumentierte Abschnittstabelle.
+Der Container SHALL Quellen und Module, Konstantenpool, TYPE-Layouts,
+modulqualifizierte Prozeduren mit vollständiger Signatur, Locals und Code,
+DATA sowie die vollständigen Forms-Anfangsbeschreibungen führen.
+Code und Quellortinformationen SHALL inline in den Prozeduren liegen
+dürfen; eigenständige CODE-/LINES-Abschnitte sind nicht erforderlich. Laden und erneutes Serialisieren MUST verlustfrei sein;
+eine unbekannte Formatversion MUST mit einer klaren Fehlermeldung
+abgewiesen werden.
+
+Ein aus FRM- oder Projektquellen gebautes Kompilat SHALL ohne erneuten Zugriff auf diese Quellen ausführbar sein und ihre Anfangseigenschaften und Designzeit-Control-Arrays bewahren.
+
+#### Scenario: Roundtrip
+- **WHEN** ein kompiliertes Modul als `.tbc` geschrieben und wieder geladen wird
+- **THEN** ist das geladene Kompilat funktional identisch (gleiche Ausführung, gleiche Zeilenzuordnung)
+
+#### Scenario: Unbekannte Version
+- **WHEN** eine `.tbc`-Datei mit höherer Formatversion geladen wird
+- **THEN** wird das Laden mit einer Meldung abgelehnt, die die Version nennt
+
+#### Scenario: Formularwerte nach Kompilat-Rundlauf
+- **WHEN** ein Formular mit Text1.Text = "hello" kompiliert, gespeichert und ohne Quelldatei geladen wird
+- **THEN** liefert der erste Zugriff auf Text1.Text weiterhin hello
+
+### Requirement: Zeilentabelle für Fehlerortung
+Der Bytecode SHALL jede Anweisung ihrem Ursprung (Moduldatei, Zeile)
+zuordnen, sodass Laufzeitfehlermeldungen, `ERL`, Breakpoints und
+Einzelschritt die Quellzeile exakt benennen können.
+
+Die Zuordnung SHALL auch nach Include-Expansion und bei mehreren Projektmitgliedern die ursprüngliche Datei und physische Zeile bewahren. Numerische BASIC-Zeilenlabels für ERL SHALL davon getrennt bleiben.
+
+#### Scenario: Fehler nennt Zeile
+- **WHEN** in Zeile 42 eines Programms ein Laufzeitfehler ohne Handler auftritt
+- **THEN** nennt die Fehlermeldung Zeile 42
+
+#### Scenario: Fehler aus Projektbibliothek
+- **WHEN** lib.bas in physischer Zeile 2 einen Fehler auslöst und über app.mak aufgerufen wird
+- **THEN** nennt die Meldung lib.bas und Zeile 2 statt einer verketteten Projektzeile

openspec/changes/projektmodule-und-kompilat/specs/forms-objektmodell/spec.md

@@ -0,0 +1,27 @@
+## MODIFIED Requirements
+
+### Requirement: Formulare und Steuerelemente als benannte Objekte
+Ein Formular SHALL unter seinem Namen ansprechbar sein, ein
+Steuerelement unter seinem Namen innerhalb seines Formulars. Eigenschaften
+SHALL über `objekt.eigenschaft` gelesen und geschrieben werden, mit dem
+in der Forms-Referenz festgelegten Typ und Wertebereich. Es SHALL keine
+Standardeigenschaft geben: `Text1 = "x"` MUST abgewiesen werden. Das
+Schreiben eines Wertes außerhalb des Wertebereichs MUST Laufzeitfehler 5
+auslösen; eine zur Laufzeit schreibgeschützte Eigenschaft MUST bei
+Zuweisung einen Fehler auslösen.
+
+#### Scenario: Eigenschaft lesen und schreiben
+- **WHEN** `Text1.Text = "hallo"` ausgeführt und danach `Text1.Text` gelesen wird
+- **THEN** liefert der Zugriff `hallo`
+
+#### Scenario: Keine Standardeigenschaft
+- **WHEN** ein Programm `Text1 = "x"` enthält
+- **THEN** wird es abgewiesen und die Meldung nennt `Text1`
+
+#### Scenario: Wert außerhalb des Bereichs
+- **WHEN** `Check1.Value = 3` ausgeführt wird
+- **THEN** tritt Laufzeitfehler 5 auf
+
+#### Scenario: Getrennte Werte gleichnamiger Controls
+- **WHEN** Form1!Text1.Text auf a und Form2!Text1.Text auf b gesetzt werden
+- **THEN** liefern die beiden Zugriffe unabhängig a und b

openspec/changes/projektmodule-und-kompilat/specs/sprach-frontend/spec.md

@@ -0,0 +1,50 @@
+## MODIFIED Requirements
+
+### Requirement: Diagnostik mit Vorbild-Meldungen
+Diagnosen SHALL exakte 1-basierte Quelltextpositionen (Zeile, Spalte)
+tragen; die Meldungstexte SHALL dem Katalog des Vorbilds folgen, wo eine
+Entsprechung existiert (z. B. „Type mismatch", „Duplicate definition",
+„Label not defined", „Subprogram not defined", „Overflow").
+
+Bei Projekten und Includes SHALL jede Diagnose den ursprünglichen Dateinamen mit dessen physischer Zeile und Spalte tragen.
+
+#### Scenario: Position in der Diagnose
+- **WHEN** in Zeile 3 ein Typkonflikt auftritt
+- **THEN** nennt die Diagnose Zeile 3 und die Spalte des Ausdrucks
+
+#### Scenario: Include-Diagnose
+- **WHEN** ein eingebundenes Include einen Typfehler enthält
+- **THEN** nennt die Diagnose die Include-Datei und ihre eigene Quellposition
+
+### Requirement: Objektzugriffe in Grammatik und Semantik
+Der Parser SHALL Punktpfade auf Formulare und Steuerelemente
+(`objekt.eigenschaft`), den Container-Operator
+`form!steuerelement[.eigenschaft]`, `IF TYPEOF ausdruck IS klasse`, den
+Metabefehl `$FORM` und die Datentypen `FORM` und `CONTROL` als
+Parametertypen erkennen. Die Semantik SHALL Eigenschaften gegen die
+Klasse des Objekts prüfen und ihren Typ bestimmen. Ein Punktpfad, dessen
+Basis weder ein benutzerdefinierter Typ noch ein bekanntes Objekt ist,
+MUST eine Diagnose erzeugen, die Basis und Eigenschaft namentlich nennt;
+er MUST NOT zu einer impliziten Variablen mit Punkt im Namen werden.
+
+Gleichnamige Steuerelemente unterschiedlicher Formulare SHALL im jeweiligen Formularnamensraum aufgelöst werden; die explizite Containerangabe SHALL vor der lokalen Namenssuche wirken.
+
+#### Scenario: Unbekanntes Objekt wird benannt
+- **WHEN** ein Modul `Text9.Text = "a"` ohne Steuerelement `Text9` enthält
+- **THEN** nennt die Diagnose `Text9` als unbekanntes Objekt statt „Type mismatch" zu melden
+
+#### Scenario: Unbekannte Eigenschaft wird benannt
+- **WHEN** ein Modul `Text1.Farbe = 3` enthält
+- **THEN** nennt die Diagnose `Farbe` als unbekannte Eigenschaft von `TextBox`
+
+#### Scenario: Eigenschaftstyp wird geprüft
+- **WHEN** ein Modul `Text1.Text = 5` enthält
+- **THEN** meldet die Semantik einen Typkonflikt mit Nennung der Eigenschaft
+
+#### Scenario: TYPEOF
+- **WHEN** ein Modul `IF TYPEOF Ziel IS CommandButton THEN` enthält
+- **THEN** wird es übersetzt und die Klasse gegen die bekannten Steuerelementklassen geprüft
+
+#### Scenario: Gleichnamige Controls verschiedener Formulare
+- **WHEN** Form1 und Form2 jeweils Text1 enthalten und Form2!Text1.Text gelesen wird
+- **THEN** wird Text1 in Form2 aufgelöst und das Programm übersetzt diagnosefrei

openspec/changes/projektmodule-und-kompilat/specs/vm-ausfuehrung/spec.md

@@ -0,0 +1,24 @@
+## MODIFIED Requirements
+
+### Requirement: Unterbrechbare step()-Ausführung
+Die VM SHALL als zustandsbehaftete, vom Einbetter getriebene Struktur
+ausführbar sein: An Anweisungsgrenzen prüft sie ein Flag-Wort und kann
+anhalten (Breakpoint auf (Modul, Zeile), Einzelschritt, Abbruchwunsch).
+Im angehaltenen Zustand MUST der Einbetter Variableninhalte (Skalare,
+Arrayelemente, UDT-Felder) inspizieren und die Ausführung fortsetzen
+können. Die Tick-Prüfung erfolgt nur an Anweisungsgrenzen, nicht pro
+Opcode.
+
+Ein Breakpoint SHALL durch Modulidentität und physische Quellzeile bestimmt sein. Gleiche Zeilennummern anderer Module MUST NOT denselben Breakpoint auslösen.
+
+#### Scenario: Breakpoint hält an
+- **WHEN** ein Breakpoint auf Zeile 10 gesetzt ist und die Ausführung Zeile 10 erreicht
+- **THEN** hält die VM vor der Anweisung an und meldet Modul und Zeile
+
+#### Scenario: Inspektion im Halt
+- **WHEN** die VM an einem Breakpoint steht
+- **THEN** liefert die Inspektions-API den aktuellen Wert einer benannten Variablen
+
+#### Scenario: Gleiche Zeile in zwei Modulen
+- **WHEN** ein Breakpoint auf Modul A, Zeile 10 gesetzt ist und Modul B Zeile 10 ausführt
+- **THEN** läuft B weiter; erst A Zeile 10 hält an