TerminalBasic/openspec/changes/archive/2026-09-05-projektmodule-und-kompilat/review.md

Verifikation: projektmodule-und-kompilat

Stand: 05.09.2026, Arbeitsbaum auf Basis von 58b1f62. Keine offenen Befunde: 0 CRITICAL, 0 WARNING, 0 SUGGESTION.

Die sechs Befunde des ersten Reviews sind behoben. Weitere bei der Nachprüfung reproduzierte Abweichungen wurden ebenfalls korrigiert und mit Regressionen abgesichert. Der Change ist abnahmebereit.

Dimension	Ergebnis
Vollständigkeit	12/12 Tasks umgesetzt; alle 7 Requirements und 21 Delta-Szenarien abgeglichen.
Korrektheit	453 Workspace-Tests bestanden, 0 fehlgeschlagen, 1 vorhandener Golden-Generator ignoriert. Die 7 unveränderten ursprünglichen Review-Proben bestehen auch im unabhängigen temporären Treiber.
Kohärenz	D1–D4 erfüllt: physische Quellorte, getrennte Scopes, selbstständiges TBC 4 und dokumentierte Inline-Instruktionen.

Geschlossene Befunde

Befund	Korrektur und Nachweis
V1: Zweig-/Schleifenorte	Parser und HIR erhalten ELSEIF-, CASE-, NEXT-, LOOP- und WEND-Positionen. Codegen emittiert die tatsächlichen Anweisungsgrenzen. Fehler, Breakpoints, WHILE-Rücksprung, LOOP-RESUME, NEXT-RESUME NEXT und Include-Enden in Zeile 42/Spalte 3 sind geprüft. Numerische ERL-Labels bleiben getrennt.
V2: Importkontext	Exportierte Signaturen erhalten die DEFtype-Typen ihres Ursprungs. Konstanten werden dort gefaltet, einschließlich transitiver Abhängigkeiten über drei Module. TYPE-Abhängigkeiten werden geordnet und bei abweichenden lokalen Layouts intern qualifiziert. Echte lokale Duplikate bleiben Fehler.
V3: $FORM-Identitäten	FRM- und $FORM-Objekte stehen vor jeder Modulübersetzung in einem gemeinsamen Katalog. Getrennte Captions, gegenseitige Referenzen und unterschiedliche Form_Load-Bindungen sind auch für gemischte FRM/BAS-Projekte nach TBC-Rundlauf geprüft.
V4: COMMON	HIR übergibt Block, vollständigen Variablenschlüssel, Elementtyp und Arraygrenzen an den Linker. Typen, Ränge und bekannte Grenzen werden geprüft. CommonArr initialisiert einmal und prüft spätere dynamische Grenzen ohne Zurücksetzen des Handles oder der Werte. Offene Arraydeklarationen und gerundete Grenzen bleiben unterstützt.
V5: LOAD/UNLOAD	Beide Anweisungen verwenden dieselbe explizite Containerauflösung und Indexprüfung wie andere Objektzugriffe. Form2!Text1(3) wird geladen, beschrieben, gelesen und entladen, auch wenn Form1 ebenfalls Text1 besitzt.
V6: Diagnosen	Der Linker gibt strukturierte Diagnosen an den ursprünglichen Deklarationen zurück; Source-ID, Datei, Zeile und Spalte bleiben erhalten. Signaturkonflikte, COMMON-Konflikte im Include sowie doppelte Module sind geprüft.

Die erweiterten Proben fanden zusätzlich folgende inzwischen behobene Abweichungen: transitive Konstantenimports, fremde TYPE-Layouts bei lokal abweichenden Definitionen, prozedurübergreifendes Durchsickern von DEFtype, Verwechslung typisierter Debuggernamen, Verwechslung von Formnamen mit suffixdeklarierten Variablen und fehlende Literalpositionen in Diagnosen. Letzteres ist durch CALL F("wrong") in args.bi:42:10 abgesichert. Auch Konflikte erst in der dritten COMMON-Deklaration werden erkannt.

Die 16 dauerhaften Regressionstests enthalten die sieben ursprünglichen Proben mit unveränderten Erwartungen sowie neun ergänzende Tests mit mehreren verwandten Fällen. Die ursprüngliche Probe-Datei wurde nicht geändert. Es wurden keine Goldens neu erzeugt und keine Fehlererwartungen abgeschwächt.

Abgleich aller Requirements und Szenarien

Requirement	Szenarien / Nachweise
Monomorpher Opcode-Satz	Gemischter Ausdruck und aufgelöste Namen: vorhandene HIR-/Codegentests; numerische Projektverknüpfung. Alle 153 Opcode-Kennungen, Operandenfolgen und Encodingbreiten gegen die Dokumentation geprüft.
TBC-Container	Bytegleicher Roundtrip; klare Ablehnung alter/unbekannter Versionen; vollständige Formularwerte und Designarrays. CLI-Projekttests entfernen sämtliche BAS-/BI-/FRM-/MAK-Quellen und führen das TBC selbstständig aus.
Quellorte	Fehler in physischer Zeile 42; Fehler in lib.bas:2; verschachtelte Includes; zusätzliche ausführbare Zweig-/Schleifengrenzen und Initialisierungen.
Benannte Objekte	Eigenschaften lesen/schreiben; keine Standardeigenschaft; Check1.Value=3 erzeugt Fehler 5; voneinander unabhängige Werte gleichnamiger Controls. Zwei FRM- und gemischte FRM/$FORM-Projekte geprüft.
Diagnostik	1-basierte Datei-/Zeilen-/Spaltenangaben in Lexer, Parser, Semantik und Linker; Include-Fehler einschließlich Literalargumenten.
Objektgrammatik/-semantik	Unbekanntes Objekt und unbekannte Eigenschaft benennen; Eigenschaftstyp prüfen; TYPEOF; expliziter Form1/Form2-Container bei gleichnamigen Controls. Qualifiziertes LOAD/UNLOAD nutzt dieselbe Auflösung.
Unterbrechung/Inspektion	Modulbezogener Breakpoint; scalar-, array- und UDT-Inspektion; Fortsetzen und Einzelschritt. Gleiche physische Zeile in MAIN und LIB bleibt getrennt, explizite Typ-Suffixe unterscheiden Variablen. ERR/ERL bleiben 6/200.

Die konkreten ursprünglichen Szenario-/Testnamen und weitere Containerproben stehen im Implementierungsnachweis, den VM-Projekttests und den CLI-Projekttests.

Abschließende Prüfläufe

• cargo test --workspace: 453 bestanden, 0 fehlgeschlagen, 1 ignoriert.
• Unabhängiger Treiber aus review-initial.md: 7 bestanden.
• cargo clippy --workspace --all-targets --all-features -- -D warnings: bestanden.
• cargo fmt --all -- --check: bestanden.
• cargo bench -p tb-vm --bench compile: 508 Zeilen 0,56 ms (Budget 50 ms); 49.760 Zeilen in 20 verbundenen Modulen 77 ms (Budget 1000 ms).
• Formatabgleich: 153/153 Opcodes, Operandentypen und Gesamtbreiten; 9/9 Abschnittskennungen stimmen zwischen Writer, Reader und Dokumentation überein.
• openspec validate projektmodule-und-kompilat --strict: bestanden.
• git diff --check: bestanden.

Die Verifikation prüft den aktuellen Code und die gesamten Change-Artefakte lokal und headless auf macOS. Ein neuer interaktiver Originalsystemvergleich oder eine Windows-/Linux-Testmatrix war nicht Teil dieses Prüflaufs. Die vier betroffenen Hauptspecs wurden am 05.09.2026 synchronisiert und mit openspec validate --specs --strict validiert (15/15 bestanden). Alle sieben Delta-Requirements stimmen vollständig mit den Hauptspecs überein; alle zuvor vorhandenen Szenarien und unberührten Requirements bleiben erhalten. Der Change ist unter openspec/changes/archive/2026-09-05-projektmodule-und-kompilat archiviert.