Phase 5 vollständig planen und native Exporte abgrenzen

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-06

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/design.md

@@ -0,0 +1,31 @@
+## Context
+
+`SourceUnit::parse` erhält Segmentherkunft. `tb-vm/src/project.rs::compile_project` parst heute alle Module, löst Exportdeklarationen und Konstanten auf, senkt sie erneut ab und verknüpft alles. Es gibt keinen inkrementellen Cache und keine Editor-Normalisierung. Das bestehende Budget steht in `bytecode-kompilat` und `docs/tbvm-design.md`. Dokumente und UI stammen aus 01/02.
+
+## Goals / Non-Goals
+
+**Goals:** Text und Diagnose identisch zur bestehenden Sprache; nur tatsächlich betroffene Module erneut übersetzen; Quellorte bis zur Diagnose erhalten.
+
+**Non-Goals:** LSP, fremder Editorprozess, neuer BASIC-Parser, Rope ohne gemessenen Bedarf, teure Optimierung oder Live-Patching einer laufenden VM.
+
+## Decisions
+
+1. Ein dokumentbezogener Textpuffer mit Edit-Operationen reicht zunächst. Cursor/Selektion werden an Unicode-Grenzen geführt; Bildschirmspalten verwenden die vorhandene Unicode-Breitenlogik. Zusammengesetzte Aktionen (Paste, Replace All, Normalisierung, Prozedurerzeugung) sind eine Undo-Einheit. Die Zwischenablage ist IDE-intern verlässlich; ein späterer Betriebssystemadapter ist keine Voraussetzung für CUA-Kopieren zwischen IDE-Fenstern.
+2. Normierung nutzt Tokenarten und Quellspannen des vorhandenen Frontends, keinen Regex-Ersatz auf dem gesamten Text. Nur eindeutig erkannte Keywords/Trennräume werden geändert; Strings, Kommentare, DATA und Typ-Suffixe bleiben erhalten. Token-/AST-Vergleich der Vorher-/Nachher-Programme prüft Semantikerhalt. Unvollständige Konstrukte werden durch den bestehenden Parserkontext als unfertig markiert, nicht mit einem zweiten permissiven Parser ausgeführt. Line Leave aktualisiert den betroffenen Modulstand; ein noch unvollständiges Modul bleibt nicht startbar.
+3. Prozedurwahl zeigt Modulrumpf und SUB/FUNCTION-Einträge. Shift+F2 öffnet die Auswahl, Ctrl+F2 kehrt zur vorherigen Codeposition zurück. Die in der Spec konkretisierten Ctrl+Q-Chords sind Projektvorgaben für die in der Referenz nur allgemein genannte WordStar-Familie. Suchdialoge arbeiten zunächst auf dem aktiven Dokument oder dessen Auswahl; Projektweitsuche ist kein Phase-5-Punkt. Auswahl-Suche und F3 nutzen denselben Suchzustand.
+4. Generierte DECLARE-Zeilen liegen in einem eindeutig kommentierten IDE-Bereich und werden signaturbasiert gepflegt. Vorhandene explizite passende Deklarationen gewinnen; widersprüchliche Handdeklarationen werden diagnostiziert. Der Speicherhook schreibt niemals einen nur teilweise aktualisierten deklarativen Vorspann. Unfertiger oder fehlerhafter Quelltext bleibt ausdrücklich speicherbar: dann wird die automatische DECLARE-Pflege vollständig übersprungen und erklärt, während der eingegebene Text unverändert als Entwurf gespeichert wird. DEFtype-Übernahme verwendet die am Erzeugungsort gültigen Vorgaben und erzeugt keine doppelten Header. FRM-Code benutzt denselben Hook.
+5. Ein Cache innerhalb des vorhandenen Projektcompilers speichert Parsing und unverkettete Modulprodukte. Schlüssel umfassen Dokument-/Include-Inhalte, Modulidentität, Compilerkonfiguration, importierte öffentliche Vertragsinhalte und Forms-Metadaten. Abhängigkeiten folgen tatsächlicher Namensauflösung einschließlich CONST, TYPE, COMMON, DECLARE und Formularnamen. Private Rumpfänderungen invalidieren keine unabhängigen Module; Exportänderungen invalidieren transitive Verbraucher. Unsichere oder zuvor fehlerhafte Abhängigkeitsauflösung führt konservativ zur betroffenen vollständigen Neuauflösung, nicht zu einem vermeintlich gültigen alten Ergebnis.
+6. Der vorhandene Linker verknüpft gecachte unverkettete Produkte neu und remappt alle Slot-, Typ-, Prozedur-, String-, DATA-, Objekt- und Quell-IDs. Bereits verknüpfte Produkte werden nicht durch Feldpatches wiederverwendet. Der bisherige Vollcompile bleibt als Vergleichspfad und CLI-Einstieg erhalten. Kein dauerhaftes Cache-Dateiformat.
+7. Jede Diagnose und jedes Ergebnis gehört zu einem vollständigen Projektrevisionssatz. Start akzeptiert nur den aktuellen Satz; Compilefehler machen einen alten Erfolg nicht aktuell. Editieren während Break erzeugt eine neue Revision; die Laufentscheidung liegt bei 04. Ein einzelner UI-Prozess kann zunächst synchron auf Line Leave kompilieren, solange das bestehende Budget eingehalten wird; Hintergrund-Compiler und Cancellation werden nicht vorsorglich gebaut.
+8. Tests vergleichen Voll-/Cachepfad für private Änderungen, Includes, transitive Konstanten, Typ-/COMMON-Änderungen, Entfernen/Umordnen von Modulen und Forms-Arrayänderungen. Zähler belegen Wiederverwendung; Benchmarks messen inklusive Invalidierung/Link mit dem vorhandenen Referenzprojekt. Keine fragile Millisekunden-Assertion in normalen Debug-CI-Tests.
+
+## Risks / Trade-offs
+
+- Verdeckte Deklarationsabhängigkeit → Export-/Importsignaturen aus realer Auflösung, Differentialtests gegen frischen Compile; bei Zweifeln sicher neu auflösen.
+- Fehlerdialog beim unfertigen Block → zwischen unvollständig und eindeutig ungültig unterscheiden; Abbrechen lässt den Text stehen.
+- Textnormalisierung verändert Programme → geschützte Tokenklassen und Idempotenz-/Semantiktests, bei uneindeutigem Fragment keine Normalisierung.
+- Einfacher Textpuffer wird teuer → erst bei verfehltem Referenzbudget eine andere Datenstruktur erwägen.
+
+## Migration Plan
+
+Vollcompiler als Referenz beibehalten, Cache optional dazuschalten und mit denselben Quellen vergleichen. Generierte DECLARE-Blöcke sind normale BASIC-Kommentare und Deklarationen; Quellen bleiben mit der CLI lesbar. Cacheverlust bedeutet nur Neuübersetzung.

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Der vorhandene Frontend-/Projektcompiler übersetzt vollständige Einheiten, hat aber weder Editorfunktionen noch einen inkrementellen Cache. Phase 5 verlangt zeilenbezogene Rückmeldung und kurze Startzeiten auch bei mehreren Modulen.
+
+## What Changes
+
+- Quelltexteditor mit CUA- und WordStar-Bedienung, Undo, Suchen/Ersetzen, Include-Ansichten und Prozedurnavigation.
+- Syntaxprüfung und semantikerhaltende Normalisierung beim Verlassen einer Zeile; DECLARE-Pflege beim Speichern und DEFtype-Übernahme in neue Prozeduren.
+- Modulweiser Compiler-Cache mit Include- und Deklarationsabhängigkeiten, korrekter Invalidierung und identischen Ergebnissen zur vollständigen Übersetzung.
+- Quellgenaue Diagnosen und revisionsgebundene Kompilate; Messungen gegen das bestehende Instant-Compile-Budget.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-editor`: Quelltexteditor mit CUA- und WordStar-Bedienung, Undo, Suchen/Ersetzen, Include-Ansichten und Prozedurnavigation.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+tb-ide-Editor, tb-frontend Lexer/Parser/Sema und tb-vm Projektcompiler/Linker; bestehende Compile-Budget-Tests und docs/tbvm-design.md. Kein zweiter BASIC-Parser und kein Optimizer.
+
+**Abhängigkeiten:** [phase-5-01-projekt-und-dokumentmodell](../phase-5-01-projekt-und-dokumentmodell/proposal.md), [phase-5-02-ide-rahmen](../phase-5-02-ide-rahmen/proposal.md).
+
+**Gesamtplanung:** [Phase-5-Übersicht](../phase-5-01-projekt-und-dokumentmodell/phase-5-uebersicht.md). Die Nummern geben eine gültige Umsetzungsreihenfolge an; OpenSpec erzwingt Change-Abhängigkeiten nicht automatisch.

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/specs/ide-editor/spec.md

@@ -0,0 +1,66 @@
+## Purpose
+
+Ermöglicht die vollständige Quelltextbearbeitung in der IDE und schnelle, quellgenaue Übersetzung des aktuellen Projektstands mit unveränderter BASIC-Semantik.
+
+## ADDED Requirements
+
+### Requirement: Editorbewegung und Änderungen
+Der Editor SHALL Einfügen/Überschreiben, Auswahl, CUA-Kopieren/Ausschneiden/Einfügen/Rückgängig, Pos1/Ende, seiten- und wortweise Navigation sowie Ctrl+Y zum Zeilenlöschen unterstützen. WordStar SHALL Ctrl+Q,S/D für Zeilenanfang/-ende, Ctrl+Q,R/C für Dateianfang/-ende und Ctrl+K,0–3 / Ctrl+Q,0–3 für Setzen/Anspringen von vier Lesezeichen unterstützen. Unicode-Zeichen und Tabulatoren SHALL ohne beschädigte Zeichen oder falsche Cursorpositionen bearbeitet werden.
+
+#### Scenario: Zusammengesetzte Bearbeitung
+- **WHEN** mehrzeiliger Text eingefügt, markiert, ausgeschnitten und rückgängig gemacht wird
+- **THEN** sind Text, Auswahl und Cursor nachvollziehbar wiederhergestellt; ein abgeschnittener WordStar-Chord führt keine zufällige Textänderung aus
+
+### Requirement: Suchen und Ersetzen
+Find, Selected Text mit Ctrl+Backslash, Repeat Last Find mit F3 und Change SHALL Suchtext, Richtung, Groß-/Kleinschreibung und Wortgrenzen berücksichtigen. Change SHALL Einzelersetzung und Ersetzen aller Treffer im gewählten Suchbereich erlauben; eine Ersetzungsaktion SHALL rückgängig machbar sein. Das Ende des Suchbereichs SHALL einen erkennbaren Rücksprung anbieten.
+
+#### Scenario: Leere und verkürzende Ersetzung
+- **WHEN** Treffer durch leeren oder kürzeren Text ersetzt werden
+- **THEN** werden alle vorgesehenen Treffer genau einmal verarbeitet; Undo stellt den gesamten Zustand vor der Aktion her
+
+### Requirement: Zeilenprüfung und Normalisierung
+Bei aktivem Syntax Checking SHALL das Verlassen einer geänderten Zeile eine Prüfung und bei eindeutig gültiger Syntax eine Normalisierung von Keywords und Leerzeichen auslösen. Zeichenketten, Kommentare, DATA-Nutztext, Bezeichner und Typ-Suffixe MUST semantisch unverändert bleiben. Unvollständige mehrzeilige Konstrukte SHALL als noch unvollständig behandelbar bleiben; sie dürfen die weitere Eingabe nicht blockieren. Abschalten SHALL automatische Formatierung und Fehlerdialoge unterbinden; Run SHALL weiterhin eine vollständige Gültigkeitsprüfung verlangen.
+
+#### Scenario: Nutztext unverändert
+- **WHEN** eine Zeile mit kleingeschriebenen Keywords, einem String, einem Kommentar und Typ-Suffixen verlassen wird
+- **THEN** werden nur syntaktische Keywords und zulässige Abstände normalisiert; erneute Normalisierung verändert nichts mehr
+
+#### Scenario: Unvollständiger Block
+- **WHEN** nach SUB oder einem mehrzeiligen IF die nächste Zeile begonnen wird, bevor END SUB beziehungsweise END IF vorhanden ist
+- **THEN** bleibt der Editor bedienbar und zeigt den unvollständigen Zustand, ohne das Fragment zu verwerfen oder ein altes Kompilat als aktuell startbar zu behandeln
+
+### Requirement: Prozeduren und Deklarationen
+New Sub und New Function SHALL gültige, eindeutig benannte Prozedurrümpfe mit den wirksamen DEFtype-Vorgaben anlegen. Shift+F2 und Ctrl+F2 SHALL Prozedurwahl beziehungsweise Rückkehr ermöglichen. Beim Speichern SHALL benötigte DECLARE-Prototypen erzeugt oder aktualisiert werden; benutzerdefinierte Deklarationen MUST NOT still überschrieben werden. Konflikte SHALL quellgenau gemeldet und der Dokumentstand erhalten werden. Unvollständige oder fehlerhafte Quellen SHALL als Entwurf speicherbar bleiben; dabei SHALL eine nicht sicher mögliche DECLARE-Pflege vollständig übersprungen und erklärt werden.
+
+#### Scenario: Wiederholtes Speichern
+- **WHEN** eine neue Prozedur angelegt und das Dokument mehrfach gespeichert wird
+- **THEN** existiert genau eine passende Deklaration; der zweite Speichervorgang erzeugt keine weitere Änderung
+
+#### Scenario: Unfertigen Entwurf speichern
+- **WHEN** eine noch unvollständige Prozedur gespeichert und erneut geöffnet wird
+- **THEN** bleibt der eingegebene Text erhalten; es wurde kein unvollständiger DECLARE-Vorspann erzeugt und die ausgelassene automatische Pflege wurde erklärt
+
+### Requirement: Include-Ansichten und Diagnosen
+Included File SHALL die Originaldatei der Einbindung öffnen; Included Lines SHALL die Expansion als klar gekennzeichnete Ansicht ein-/ausblenden. Diagnosewahl SHALL in das richtige Modul, die physische Datei und Zeile springen. Eingeblendete Expansion SHALL entweder zur Ursprungsdatei weiterleiten oder schreibgeschützt sein.
+
+#### Scenario: Gleichnamige Quellzeilen
+- **WHEN** zwei Includes derselben Übersetzung in derselben physischen Zeilennummer Fehler enthalten
+- **THEN** führen ihre Diagnosen jeweils zur richtigen Datei und nicht zur verketteten Modulzeile
+
+### Requirement: Korrekte inkrementelle Übersetzung
+Nach Änderungen SHALL nur die betroffene Übersetzungseinheit und ihre tatsächlich betroffenen abhängigen Einheiten neu übersetzt werden. Includes, öffentliche Signaturen, Konstanten, TYPE-/COMMON-Deklarationen, Modulreihenfolge und Forms-Struktur SHALL in die Gültigkeitsprüfung eingehen. Inkrementelle und frische vollständige Übersetzung desselben Stands SHALL dieselben Diagnosen und dasselbe Laufzeitverhalten liefern. Veraltete Ergebnisse MUST NOT einen neueren Dokumentstand überschreiben oder als dessen Kompilat ausgeführt werden.
+
+#### Scenario: Private Änderung
+- **WHEN** nur der Prozedurrumpf eines Moduls ohne Änderung seines öffentlichen Vertrags geändert wird
+- **THEN** wird dieses Modul neu übersetzt, unveränderte unabhängige Module werden wiederverwendet und das neu verknüpfte Projekt entspricht der vollständigen Übersetzung
+
+#### Scenario: Transitive Änderung
+- **WHEN** eine exportierte Konstante oder ein TYPE in einem gemeinsam eingebundenen Include geändert wird
+- **THEN** werden alle betroffenen direkten und transitiven Verbraucher aktualisiert; entfernte Symbole liefern dieselben Fehler wie eine frische Übersetzung
+
+### Requirement: Nachweisbarer Instant Compile
+Die IDE-Übersetzung SHALL das bestehende Release-Budget von unter 50 ms für das Referenz-Einzelmodul und unter 1 s für das ungefähr 50.000-Zeilen-Referenzprojekt auf dokumentierter Referenzhardware einhalten. Messungen SHALL vollständigen Compile und Änderungen mit Cache einschließlich Invalidierung und Link getrennt ausweisen.
+
+#### Scenario: Reproduzierbare Messung
+- **WHEN** der Release-Benchmark auf der ausgewiesenen Referenzhardware ausgeführt wird
+- **THEN** nennt er Hardware, Profil, Projektgröße, vollständige und inkrementelle Dauer sowie neu übersetzte Module und bewertet beide bestehenden Zeitgrenzen

openspec/changes/phase-5-03-editor-und-inkrementelle-uebersetzung/tasks.md

@@ -0,0 +1,26 @@
+## 1. Editor und Navigation
+
+- [ ] 1.1 Den Texteditor auf dem Dokumentmodell aus 01 integrieren; Tests mit Unicode, Tabs, Zeilenumbrüchen, Einfügen/Überschreiben, Auswahl und Undo belegen korrekten Text und Cursor.
+- [ ] 1.2 CUA-, Wort-/Seitennavigation, Ctrl+Y und die spezifizierten WordStar-Chords/Lesezeichen anbinden; eingespeiste Tastenfolgen prüfen auch abgebrochene Chords und Mehrfenster-Kopieren.
+- [ ] 1.3 Find, Selected Text, F3 und Change mit Einzel-/Gesamtersetzung implementieren; Tests prüfen Wortgrenzen, Suchrichtung, Großschreibung, Rücksprung, leere Ersetzung und gemeinsames Undo.
+- [ ] 1.4 Prozedurauswahl und Shift+F2/Ctrl+F2 sowie Include-Ansichten umsetzen; Navigationstests treffen physische Dateien und verhindern Speichern einer Expansion als Ursprungsdatei.
+
+## 2. Prüfung und Quelltextpflege
+
+- [ ] 2.1 Token-/Spanneninformationen des vorhandenen Frontends für semantikerhaltende Zeilennormalisierung verwenden; Tests belegen Idempotenz und erhalten Strings, Kommentare, DATA, Bezeichner und Typ-Suffixe.
+- [ ] 2.2 Line Leave an Syntax Checking und Diagnoseanzeige anbinden; Eingabetests unterscheiden unfertige SUB-/IF-Blöcke von echten Fehlern und belegen das deaktivierte Verhalten.
+- [ ] 2.3 New Sub/New Function mit Namenprüfung und wirksamer DEFtype-Übernahme implementieren; erzeugte Quellen müssen über den bestehenden Compiler gültig sein.
+- [ ] 2.4 DECLARE-Erzeugung/-Aktualisierung in den gemeinsamen Speicherhook aufnehmen; Tests belegen wiederholtes Speichern ohne Änderungen, Handdeklarationskonflikte, unverändertes Speichern unfertiger Entwürfe und denselben Weg für FRM-Code.
+
+## 3. Inkrementeller Compiler
+
+- [ ] 3.1 Den Projektcompiler in wiederverwendbare Parse-/Modulcompile-/Link-Schritte zerlegen und den bisherigen Vollcompile darüber erhalten; bestehende Compiler-/CLI-Regressionen bleiben grün.
+- [ ] 3.2 Modulcache mit Dokument-/Include-Revisionssatz und Import-/Exportsignaturen einführen; Zählertests belegen Wiederverwendung unveränderter Module nach privater Rumpfänderung.
+- [ ] 3.3 Transitive Invalidierung für CONST, TYPE, COMMON, DECLARE und Includes umsetzen; Differentialtests mit Änderungen und gelöschten Symbolen liefern dieselben Diagnosen wie ein frischer Compile.
+- [ ] 3.4 Forms-Struktur, Modulreihenfolge und sämtliche beim Link remappten Identitäten berücksichtigen; Tests vergleichen umgeordnete Module, Control-Arrays, DATA und Prozedurverweise mit dem Vollcompile.
+- [ ] 3.5 Fehlerzustände und Ergebnisrevisionen an den Editor anbinden; ein Test mit gültig→fehlerhaft→gültig belegt, dass niemals ein veraltetes Ergebnis als aktueller Stand startet.
+
+## 4. Leistung und Abnahme
+
+- [ ] 4.1 Die vorhandenen Release-Compile-Benchmarks um Änderungen mit Cache einschließlich Invalidierung/Link ergänzen; dokumentierte Messungen prüfen Einzelmodul unter 50 ms und Referenzprojekt unter 1 s sowie tatsächlich neu übersetzte Module.
+- [ ] 4.2 Editor-/Compilerbedienung und Cachegrenzen in docs erläutern und alle Szenarien in verification.md zuordnen; relevante Frontend-, VM-, CLI- und IDE-Tests sowie Formatprüfung müssen bestehen.