Phase 5: Projekt- und Dokumentmodell implementieren und archivieren

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/.openspec.yaml

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

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/design.md

@@ -0,0 +1,29 @@
+## Context
+
+`tb-cli/src/main.rs` besitzt `input_sources`, `expand_includes`, `relative_case_insensitive`, `read_form` und `compile` als private Funktionen. `SourceUnit`/`SourceSegment` erhalten bereits physische Quelldateien. `FormFile` kann binäre und textuelle Formulare lesen und Text unverändert oder kanonisch schreiben. Der IDE-Einstieg ist ein Platzhalter. Grundlage: [proposal.md](proposal.md), `docs/dateiformate.md:129` und die bestehenden CLI-Projekt-/Include-Tests.
+
+## Goals / Non-Goals
+
+**Goals:** Eine gemeinsame Lade-/Speichergrundlage mit stabiler Dokumentidentität; ausführbare Backend-Tests bereits vor der Oberfläche.
+
+**Non-Goals:** Editorwidget (03), Designgesten (05), VM-Sitzung (04), neue Workspace-Crate oder alternatives Projektformat.
+
+## Decisions
+
+1. Die bisherigen Ladefunktionen werden in ein öffentliches Projekt-I/O-Modul der vorhandenen `tb-vm`-Crate verschoben; sie hängt schon von Frontend und FRM ab. Die CLI verwendet es unmittelbar weiter. Eingabe ist eine konkrete Sammlung geänderter Dokumente plus Dateisystem-Fallback. Kein Dateisystem-Plugin und keine zweite Include-Implementierung. Include-Suchpfade können explizit übergeben werden; die relative Auflösung gewinnt immer, leere Pfadliste erhält das heutige Verhalten.
+2. In `tb-ide` hält ein Projekt geordnete Mitglieder und Dokumente mit stabiler ID, optionalem Pfad, Revision, gespeichertem Ausgangsstand und Änderungsstatus. Mehrere Ansichten halten nur ID, Cursor und Scrollposition. Neue Dateien erhalten vor dem ersten Speichern eine eindeutige virtuelle Quellidentität; ab Save As wird die Pfadzuordnung konsistent aktualisiert. Dieselbe reale Datei wird bei mehrfacher Einbindung ein Dokument, behält aber getrennte Modulkontexte.
+3. Ein FRM-Dokument enthält genau ein `FormFile`; dessen Code ist der Editorinhalt. Designer und Editor arbeiten transaktional daran. Die Formbeschreibung wird nicht aus einer zweiten, unabhängig gespeicherten Vorschau zurückgeschrieben. Originaldaten des bestehenden FRM-Schreibers bleiben für unveränderte Dokumente nutzbar.
+4. **Projektentscheidung für Set Start-up File:** Die optionale Kommentarzeile `' $STARTUP: "relativer/pfad.bas"` speichert eine explizite Auswahl. Doppelte, fehlerhafte oder nicht auf Mitglieder zeigende Angaben sind Fehler. Ohne diesen neuen Metakommentar bleibt das heutige Verhalten unverändert. Reguläre MAK-Einträge und fremde Kommentare bleiben lesbar und in ihrer Reihenfolge erhalten. Ältere Leser sehen weiterhin eine Kommentarzeile; sie kennen deren Startwirkung nicht. Die gemeinsame Compile-Eingabe übergibt die Auswahl an 04; es wird kein eigenes IDE-Startverfahren erfunden. Neue Projekte schreiben die explizite Auswahl, sobald der Benutzer sie setzt.
+5. Speichern serialisiert zunächst in temporäre Dateien im Zielverzeichnis und ersetzt einzelne Ziele kontrolliert. Projektmitglieder werden vor der MAK-Datei gespeichert. Kein Versprechen einer atomaren Mehrdatei-Transaktion: bei Teilfehlern werden nur erfolgreiche Dokumente als gespeichert markiert, übrige bleiben offen und die Projektaktualisierung wird nicht als erfolgreich gemeldet. Vor Überschreiben wird gegen den beim Laden/Speichern gelesenen Stand verglichen. Save As rechnet relative Referenzen neu aus und wechselt die aktive Identität erst nach Erfolg.
+6. Binäre FRM-Dateien sind Importquellen. Ein Textziel muss ausdrücklich gewählt werden, auch wenn Save gedrückt wurde; der Binärpfad ist kein überschreibbares Textziel. Load Text fügt am Cursor ein, Save Text exportiert Auswahl oder kompletten Code; beide nutzen dieselben Dokumentaktionen wie der Editor.
+
+## Risks / Trade-offs
+
+- Pfadalias, unterschiedliche Großschreibung und mehrfaches Include → kanonische Dateiidentität bei vorhandenen Dateien, explizite Modulzugehörigkeit separat; Tests mit Unterverzeichnissen und Leerzeichen.
+- Neue Startup-Metadaten werden von älteren Programmen ignoriert → Erweiterung und Rückwärtsgrenze in dateiformate.md dokumentieren; alte Dateien ohne Metadaten verhalten sich identisch.
+- Teilweise gespeichertes Projekt → keine falsche Erfolgsmeldung, ursprüngliche Zielversion je fehlgeschlagener Datei erhalten, MAK zuletzt; kein aufwendiges globales Transaktionssystem.
+- Umzug eines Projekts → Projektpfad und Mitgliederpfade getrennt führen; Includes bleiben relativ zu ihren ursprünglichen Dokumenten.
+
+## Migration Plan
+
+Zuerst bestehende CLI-Ladetests auf die gemeinsame API umstellen und unverändert grün halten, dann Dokumentaktionen hinzufügen. Neue Metadaten sind optional. Rücknahme des Changes lässt gewöhnliche Quellen lesbar, die neue Startup-Auswahl würde ein älterer Leser ignorieren. Kein automatisches Umschreiben bestehender Projekte beim bloßen Öffnen.

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/phase-5-uebersicht.md

@@ -0,0 +1,161 @@
+# Phase 5: Exploration und vollständige Change-Kette
+
+Planungsstand: 2026-09-06, Codebasis `024336e29ce0494fc268452e5eaf48c4ff68fbb2`.
+Diese Artefakte planen die Umsetzung; sie bestätigen keine bereits implementierte IDE.
+Maßgeblich sind [PLAN.md](../../../../PLAN.md), die [IDE-Referenz](../../../../docs/ide-referenz.md) und die bestehenden Hauptspezifikationen.
+
+## Ergebnis der Exploration
+
+Zum Ausgangsstand hatte Phase 5 acht offene und zwei bereits erfüllte PLAN-Punkte. Die geklärte Export-UI ist jetzt ein zusätzlicher expliziter offener Punkt (neun offen, zwei erfüllt). `$INCLUDE` und `RUN` sind im CLI-/VM-Pfad vorhanden; ihre IDE-Anbindung ist Bestandteil der neuen Changes. `tb` selbst ist noch ein Platzhalter. Die fehlende Arbeit liegt überwiegend in Oberfläche, Dokumentzustand und Einbettung; die Sprache und das Forms-Dateiformat müssen nicht erneut implementiert werden.
+
+| Bereich | Beobachteter Stand | Konsequenz für die Planung |
+|---|---|---|
+| [IDE-Einstieg](../../../../crates/tb-ide/src/main.rs) | Nur Platzhalterausgabe; notwendige Workspace-Abhängigkeiten schon vorhanden | Rahmen, konkrete Fenster und Ereignisverteilung in 02 |
+| [CLI-Treiber](../../../../crates/tb-cli/src/main.rs) | Private Projekt-/Include-/FRM-Lader, Compile, RUN-Zielauflösung und Reset | Laden in 01 gemeinsam nutzbar machen; Sitzung/Reset in 04 |
+| [Quellmodell](../../../../crates/tb-frontend/src/source.rs) | SourceUnit/SourceSegment erhalten Originaldateien und physische Zeilen | Identitäten wiederverwenden; ungespeicherte Dokumente ergänzen |
+| [Projektcompiler](../../../../crates/tb-vm/src/project.rs) | Übersetzt alle Module erneut, verknüpft Module und Forms; erstes Formular wird Startformular | Modulcache in 03; explizite Startup-Auswahl in 01/04 |
+| [VM](../../../../crates/tb-vm/src/interp.rs) | RunEvents, Modul-/Zeilenbreakpoints, Step und einfache Inspektion vorhanden | Sichere Poll-/Wartezustände in 04; vollständiger Debugger in 06 |
+| [Runtime-Builtins](../../../../crates/tb-runtime/src/builtins.rs) | Wartende Eingaben/Dialogs und direkte SHELL-Kindprozesse | Nicht nur den Run-Aufruf einbetten: Fortsetzungen und Terminalübergabe explizit umsetzen |
+| [Terminalhost](../../../../crates/tb-ui/src/host.rs) | BASIC-Tastencodierung mit Ctrl+C-Abbruch und F1–F10 | IDE routet eigene Tasten einschließlich F11/F12 vor BASIC-Zustellung |
+| [ScreenWidget](../../../../crates/tb-ui/src/screen.rs) | Mindestgröße wird an der Zeichenfläche geprüft | Physisches Terminal und kleines Output-Unterfenster unterscheiden |
+| [FRM-Modell](../../../../crates/tb-ui/src/frm.rs) | Baum, Code, Binärimport, unveränderte/kanonische Textausgabe vorhanden | 05 editiert dieses Modell; keine zweite FRM-Implementierung |
+| [Forms-Metadaten](../../../../crates/tb-frontend/src/forms.rs) | Klassen, Eigenschaften, Ereignisse und Arrayverträge vorhanden | Toolbox, Propertyvalidierung und Handlererzeugung daraus ableiten |
+| [Dokumentation](../../../../docs/ide-referenz.md) | Rekonstruierte Menüs/Tasten, Farbschema, Designer und Hilfeverhalten beschrieben | Vollständige Befehlszuordnung unten; Dokumente als Offline-Hilfe in 07 |
+
+Besondere Risiken sind unverändert ausgeführte alte Kompilate nach einer Textänderung, Include-Breakpoints ohne Dateiidentität, wiederholte I/O-Nebenwirkungen nach einer Pause und voneinander abweichende Designer-/FRM-/Codezustände. Jeder dieser Fälle hat konkrete Szenarien und Tasks in seinem zuständigen Change.
+
+## Changes und Reihenfolge
+
+| Nr. | Change | Direkt benötigte Vorgänger | Ergebnis |
+|---|---|---|---|
+| 01 | [Projekt- und Dokumentmodell](proposal.md) | keine | Gemeinsame Lade-/Speicheraktionen, bearbeitete Quellen, MAK und Startup-Metadaten |
+| 02 | [IDE-Rahmen](../../phase-5-02-ide-rahmen/proposal.md) | 01 | Terminalbesitz, Menüs, Fenster, Dialoge, Optionen und Eingabetestpfad |
+| 03 | [Editor und inkrementelle Übersetzung](../../phase-5-03-editor-und-inkrementelle-uebersetzung/proposal.md) | 01, 02 | Vollständige Codebearbeitung, Diagnose und schneller aktueller Compile |
+| 04 | [Ausführung und Output](../../phase-5-04-ausfuehrung-und-output/proposal.md) | 01, 02, 03 | Fortsetzbare VM-Sitzung, Reset, Ausgabe, Shell und Textdruck |
+| 05 | [Formular-Designer](../../phase-5-05-formular-designer/proposal.md) | 01, 02, 03 | Visuelles Gestalten und konsistenter Ereigniscode |
+| 06 | [Debugger und Direktfenster](../../phase-5-06-debugger-und-direktfenster/proposal.md) | 03, 04 | Quellgenaues Debuggen, Watches, Immediate, History und Fehlerhalte |
+| 07 | [Hilfesystem](../../phase-5-07-hilfesystem/proposal.md) | 02, 03 | Offline-Markdown-Hilfe und Kontextnavigation |
+| 08 | [Integration und Phasenabnahme](../../phase-5-08-integration-und-phasenabnahme/proposal.md) | 01–07 | Durchgängiger Arbeitsablauf, Befehlsabdeckung und nachgewiesener PLAN-Status |
+
+```text
+01 --> 02 --> 03 --> 04 --> 06 --+
+ |      |      +--> 05 ---------+
+ |      +----------> 07 --------+--> 08
+ +---------------------------------+
+```
+
+Die Tabelle ist die vollständige Abhängigkeitsliste; das Diagramm zeigt den Hauptfluss. Umsetzung 01 bis 08 ist eine gültige Reihenfolge. 05 und 07 können nach ihren Vorgängern auch früher umgesetzt werden. Jeder Change besitzt genau eine neue Capability und vollständige Artefakte; kein Change überschreibt das Delta eines anderen.
+
+OpenSpec erzwingt diese Change-Abhängigkeiten nicht selbst. Vor Apply sind die genannten Vorgänger anhand ihrer Implementation und Verifikation zu prüfen; ein vorhandenes tasks.md bedeutet nur Planungsbereitschaft. Nach Archivierung sind Vorgänger unter `openspec/changes/archive/` anhand des Change-Namens aufzufinden und die dann synchronisierten Hauptspezifikationen maßgeblich. Relative Verweise dieser Übersicht müssen beim Archivieren zusammen mit der Übersicht nachgeführt werden.
+
+## Gemeinsame Übergaben und Zuständigkeiten
+
+- **01 → 02/03/05:** Dokument-ID, Revision, physischer/virtueller Pfad, bearbeiteter Text beziehungsweise FormFile, geordnete Projektmitglieder, Startauswahl und sichere Dokumentaktionen. 01 liefert das direkt testbare Modell; 02 die Dialog-/Menüanbindung, 03 den Texteditor, 05 die Designgesten.
+- **02 → alle Oberflächen:** konkrete Befehle, Fokus/Modus, Fenster, modale Dialoge und ein Terminalbesitzer. Ein späterer Fachbefehl darf während Aufbau von 02 sichtbar deaktiviert sein; seine tatsächliche Funktion gehört vollständig zum verantwortlichen Folgechange und muss vor 08 aktiv sein.
+- **03 → 04/06:** nur zum vollständigen Projektrevisionssatz passende Kompilate, Originalquellorte und Deklarationsinformationen. Laufcode wird nicht in einer pausierten VM ausgetauscht.
+- **04 → 06:** pausierbare Sitzung mit eindeutigem Run-/Wait-/Break-Zustand und sauberer Fortsetzung. Scheduling-Yield und Debug-Step sind verschiedene Zustände; Rc-basierte VM-Werte bleiben im besitzenden Thread.
+- **05 → 03/04:** geändertes FormFile und Code im selben Dokument; Katalogbildung aus diesem Stand. Die Vorschau führt keine Handler aus.
+- **02/03/05 → 07:** Token, Befehl beziehungsweise Formklasse/Property als Kontext. 07 braucht für isolierte Kontextprüfungen keinen zweiten Designer; 08 prüft den tatsächlichen Aufrufweg.
+- **08:** prüft Übergänge und Vollständigkeit. Fehlende Fachfunktionen werden im zuständigen Featurebereich geschlossen, nicht durch einen parallelen Integrationscode ersetzt.
+
+## Abdeckung der PLAN-Punkte
+
+| Phase-5-Punkt | Umsetzung | Abnahme |
+|---|---|---|
+| IDE-Rahmen | 02 | Menüs/Fenster/Farben/Resize; 08 Befehlsmatrix |
+| Export-UI für Make EXE / Make Library | 02 | Vollständige Dialoge und Auftrags-/Ergebnisübergabe; 08 UI-Abnahme. Native Erzeugung: Phase 6 |
+| Editor | 03 | Bearbeitung, Normalisierung, Suche, Prozeduren, Includeorte; 08 Hauptablauf |
+| Projektverwaltung | 01, UI-Anbindung 02 | Mehrmodul-/FRM-Save/Reopen; 08 CLI-Parität |
+| Formular-Designer | 05 | Geometrie, Properties Bar, Menüs, Palette, Handler; 08 Gestalten→Run |
+| Ausführen aus der IDE | 04 | Start/Break/Continue/Reset und Output; 08 Parität |
+| `$INCLUDE` bereits umgesetzt | Erhalt durch 01/03, Debugbindung 06 | Relative/Zyklus-/Overlaytests und physische Quellorte |
+| `RUN` bereits umgesetzt | Erhalt und IDE-Anbindung 04 | Gleicher Reset, Fremdziel, Startzeile, Dokumenterhalt |
+| Debugger | 06 auf 04 | Alle Halte-/Watch-/Immediate-/History-/Fehlerpfade |
+| Hilfe | 07 | Offline, Markdown, F1/Links/Verlauf; 08 echte Aufrufer |
+| Vollständiges Programm in der IDE | 08 auf 01–07 | Erstellen→Gestalten→Speichern→Debuggen→Ausführen→Wiederöffnen |
+
+## Vollständige Zuordnung der Referenzbedienung
+
+Nummern bezeichnen Featurezuständigkeit; 02 stellt stets den gemeinsamen Menü-/Eingabepfad, 08 den Abschlussabgleich. Zusammengefasste Zeilen benennen jeden enthaltenen Befehl ausdrücklich.
+
+| Referenzbereich | Befehle / Bedienung | Zuständig |
+|---|---|---|
+| File | New Project, Open Project, Save Project | 01, 02 |
+| File | New Form, New Module, Add File, Remove File | 01, 02 |
+| File | Save File, Save File As, Load Text, Save Text | 01; Textbearbeitung 03 |
+| File | Print | 04 |
+| File | Shell | 04 |
+| File | Exit / Alt+F4 | 02; Dokumententscheidungen 01, Sitzungsende 04 |
+| Edit | Undo/Ctrl+Z, Cut/Ctrl+X, Copy/Ctrl+C, Paste/Ctrl+V, Clear/Del | Text 03, Controls 05 |
+| Edit | New Sub, New Function | 03 |
+| Edit | Event Procedures / F12 | 05, Codeoperationen 03 |
+| View | Code / F2, Form / Shift+F12 | 02, 03, 05 |
+| View | Next Statement | 06 |
+| View | Output Screen / F4 | 04 |
+| View | Included File, Included Lines | 03 |
+| View (Designer) | Menu Bar / F10, Grid Lines | 05 auf 02 |
+| Search | Find, Selected Text/Ctrl+Backslash, Repeat Last Find/F3, Change | 03 |
+| Run | Start/Shift+F5, Restart, Continue/F5, Modify COMMAND$ | 04 |
+| Run | Unterbrechen / Ctrl+Break | 04; zusätzlicher zugänglicher IDE-Befehl |
+| Run | Set Start-up File | Persistenz 01, Ausführungswirkung 04 |
+| Run | Make EXE File, Make Library | Vollständige UI 02, UI-Abnahme 08; native Erzeugung und reale Backend-Anbindung Phase 6 |
+| Debug | Add Watch, Instant Watch/Shift+F9, Watchpoint, Delete Watch, Delete All Watch | 06 |
+| Debug | Trace On, History On, Shift+F8/Shift+F10 | 06 |
+| Debug | Toggle Breakpoint/F9, Clear All Breakpoints, Break on Errors, Set Next Statement | 06 |
+| Debug-Tasten | F7 bis Cursor, F8 Single Step, F10 Procedure Step | 06 |
+| Options | Display, Set Paths, Right Mouse, Save, Syntax Checking | 02; Wirkung in 01/03/07 |
+| Window | New Window, Arrange All, offene Codefensterliste | 02 |
+| Window | Calls, Debug, Immediate | Fenster 02, Inhalt 06 |
+| Window | Help, Output, Project | Fenster 02, Inhalt 07/04/01 |
+| Window (Designer) | Color Palette, Menu Design Window, Toolbox, Help, Formliste | 05, Hilfe 07 |
+| Help | Index, Contents, Keyboard, Topic/F1, Using Help/Shift+F1, Tutorial, About | 07 |
+| Menüs | Alt/F11, Mnemonic, Esc, Dialogkennzeichnung „…“, Help rechts | 02 |
+| Fenster | F6/Ctrl+F6, Shift+F6, Ctrl+F4, Ctrl+F7/F8/F9/F10/F5, Alt+Minus | 02 |
+| Projektfenster | Anfangs rechts, Form/Code-Buttons, Enter | 02 auf 01 |
+| Toolbox/Tools | Check Box, Combo Box, Command Button, Dir List, Drive List, File List, Frame, HScrollBar, Label, List Box, Option Button, Picture Box, Text Box, Timer, VScrollBar; zusätzlich bereits unterstützte Spinvarianten | 05 |
+| Designgesten | Toolbox-Doppelklick, Aufziehen, Drag, Sizing Handles, Pfeile, Ctrl+Pfeile, Shift+Pfeile, Tab/Shift+Tab, Ctrl+Klick | 05 |
+| Properties Bar | Property/Value-Dropdown, Koordinaten/Größe, F2 Value, F10 Barwechsel, keine Statuszeile | 05 auf 02 |
+| Menüdesigner | Caption (&/-), CtlName, Tag, Index, Checked/Enabled/Visible/Separator, Shortcut, Einfügen/Löschen/Ebene/Reihenfolge/Done | 05 |
+| Farbpalette | ForeColor/BackColor, Drag auf Form | 05 |
+| Editor | Line-Leave-Prüfung/-Normalisierung, Syntax-Checking-Toggle, DECLARE, DEFtype | 03 |
+| Editor-Tasten | CUA, Einfg, Pos1/Ende, WordStar Ctrl+Q, Ctrl+Y, Bookmarks Ctrl+K,0–3 / Ctrl+Q,0–3, Shift+F2/Ctrl+F2 | 03 |
+| Immediate | PRINT, Zuweisungen, Prozeduraufrufe, ERROR n im Break-Modus | 06 |
+| Hilfe | F1/Rechtsklick, Shift+F1, ◄Thema►, Tab/Shift+Tab, Enter, Alt+F1 (20), Ctrl+F1, Esc | 07 |
+| Darstellung | DOS-Farben, Magenta-Titel, Desktopzeichen, Tabweite, klickbare Statuskürzel, Zeile/Spalte | 02 |
+| Start | Begrüßung, Version/Copyright, Untitled-Code/Projekt, keine Easy/Full-Modi | 02, About 07 |
+| Terminal | Dynamische Größe, physisches Minimum 80×25 | 02; Runtime-/Output-Abgrenzung 04 |
+| Laufzeitparität | Dieselbe TBVM in IDE, CLI und TBC | 04/06; Gesamtnachweis 08 |
+
+## Explizite Projektvorgaben und Phasengrenzen
+
+Die lokale IDE-Referenz enthält bewusst offene beziehungsweise nur grob beschriebene Details. Folgende Vorschläge sind deshalb als Terminal-Basic-Entscheidungen benannt, nicht als nachgewiesene Originaleigenschaften:
+
+- Startbegrüßung blockiert nicht; About bleibt verfügbar. Caps/Num wird ohne belastbares Terminalsignal nicht vorgetäuscht.
+- „Eigenschaftenfenster“ aus PLAN.md wird durch die in der Referenz konkret belegte Properties Bar erfüllt.
+- Startup-Auswahl verwendet einen optionalen MAK-Kommentar; alte Projekte bleiben unverändert. Die explizite Auswahl wirkt im gemeinsamen Compiler auf Modulreihenfolge und Startformular.
+- WordStar-Chords werden in 03 konkretisiert; Zwischenablage für CUA ist innerhalb der IDE verfügbar.
+- File→Print ist Textausgabe in eine auswählbare Druckdatei, Standard LPT1.TXT. Shell erhält vorübergehend das echte Terminal.
+- Automatische Watches sind nebenwirkungsfrei; allgemeine Prozeduraufrufe stehen im Direktfenster bereit. Watchpoints halten bei wahrer Bedingung. History navigiert die letzten 1.024 Quellorte, ohne Laufzeitzustände zurückzuspulen. Set Next Statement lehnt inkompatible Kontrollkontexte ab.
+- Die bestehende Release-Leitplanke (<50 ms Referenzmodul, <1 s Referenzprojekt) gilt auch für den neuen Compilerweg. Die Phase-6-Plattformmatrix und Distribution werden dadurch nicht als bereits bestanden behauptet.
+
+**Geklärte Benutzervorgabe (2026-09-06):** Make EXE erstellt ein eigenständiges natives Executable, Make Library eine tatsächliche Bibliothek im jeweiligen Systemformat. Die vollständige IDE-Bedienung gehört zu Phase 5: beide Dialoge, Zielsystem/-architektur, Ausgabepfad, Prüfung, Überschreibentscheidung, Status/Fehler/Abbruch und die konkrete Auftrags-/Ergebnisübergabe. Diese Arbeit liegt in 02 und wird in 08 integriert geprüft. Bis Phase 6 fehlen ausschließlich die tatsächliche Erzeugung und die reale Backend-Anbindung; die Dialoge bleiben bedienbar und erklären die gesperrte Erzeugen-Aktion. Kontrollierte Ergebnisrückmeldungen sind UI-Tests und kein Beleg für native Artefakterzeugung.
+
+[PLAN.md](../../../../PLAN.md) enthält dafür getrennte Aufgaben: Export-UI in Phase 5 sowie native Standalone-Executables und native Systembibliotheken in Phase 6. Die dortige Executable-Erzeugung kann den bereits geplanten vorkompilierten Runner mit eingebettetem Bytecode verwenden; das Ergebnis muss ohne separat installiertes tb/tbc direkt ausführbar sein. Der Bibliothekspunkt verlangt natives Format, Symbol-/Aufruf-/Linkvertrag und einen nativen Verbraucher-Nachweis. Eine bloße oder umbenannte `.tbc`-Datei erfüllt keinen dieser beiden Exportpunkte. Format- und ABI-Details der Bibliothek werden beim Phase-6-Backend festgelegt, ohne in Phase 5 eine zweite Formatimplementierung in der UI vorwegzunehmen.
+
+## Abnahmepfad
+
+1. Jeden Featurechange anhand seiner Szenarien und der pro Task angegebenen Prüfung umsetzen; vorhandene CLI-/VM-/Forms-Regressionspfade weiterverwenden.
+2. Kein Spezifikationssync allein aufgrund grüner Artefaktstatus: die Implementierung muss zuvor nachgewiesen sein.
+3. In 08 alle Referenzbefehle gegen reale App-Eingaben abgleichen, den durchgängigen Arbeitsablauf ausführen und gespeicherte Quellen über CLI/TBC vergleichen.
+4. Release-Compile-Budget mit Hardware, Profil, Projektgröße und Messwerten belegen. Keine normalen Tests mit instabilen Debug-Zeitgrenzen versehen.
+5. Erst danach Phase-5-Checkboxen und Ist-Dokumentation aktualisieren. Die Befehlszuordnung und jeder Verifikationsbericht müssen frei von offenen Phase-5-Befunden sein.
+
+## Prüfung der Planungsartefakte
+
+Stand nach der geklärten Export-Zuordnung am 2026-09-06:
+
+- Acht Changes mit jeweils proposal.md, design.md, tasks.md und einer neuen Delta-Spezifikation: 47 Anforderungen, 67 Szenarien und 110 noch offene Umsetzungstasks.
+- `openspec validate --all --strict --json`: 23 von 23 Einträgen gültig (acht Changes und 15 Hauptspezifikationen); die acht neuen Changes haben keine Validator-Hinweise.
+- `openspec status --change <name> --json`: für jeden Change vollständige Planungsartefakte. `openspec instructions apply --change <name> --json`: alle Artefakte bereit, jeweils null Tasks erledigt. Die fachlichen Vorgänger aus der Abhängigkeitstabelle bleiben vor der Umsetzung zu beachten.
+- Zusätzlicher Strukturabgleich: jede neue Capability eindeutig, jedes Requirement mit WHEN/THEN-Szenario, Tasks eindeutig nummeriert, Abhängigkeiten azyklisch, lokale Markdown-Verweise auf vorhandene Ziele auflösbar.
+- Änderungen beschränken sich auf die acht neuen Planungsverzeichnisse und die angeforderte Präzisierung in PLAN.md. Produktcode und bestehende Hauptspezifikationen wurden nicht verändert; Produkttests wurden für diese reine Planung nicht erneut ausgeführt.

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/proposal.md

@@ -0,0 +1,28 @@
+## Why
+
+Der CLI-Treiber kann Projekte und Includes laden, aber die IDE besitzt weder ein Projektmodell noch speicherbare Dokumente. Phase 5 braucht dieselben Quellen und Quellorte für Editor, Designer, Compiler und CLI.
+
+## What Changes
+
+- Gemeinsames Laden von BAS, FRM, MAK und Includes aus Dateisystem oder bearbeiteten Dokumenten; bisherige Pfad- und Diagnosesemantik erhalten.
+- Projekt- und Dokumentlebenszyklus mit Neuerstellung, Hinzufügen/Entfernen, Speichern, Save As, Änderungskennzeichnung und Schutz vor Datenverlust.
+- Explizite Startdatei im Projekt speichern; alte MAK-Dateien behalten ihre bisherige Startreihenfolge und Formularauswahl.
+- Text- und Formulardokumente als gemeinsame Grundlage mehrerer Ansichten; binäre FRM-Dateien kontrolliert in Text importieren.
+
+## Capabilities
+
+### New Capabilities
+
+- `ide-projekte`: Gemeinsames Laden von BAS, FRM, MAK und Includes aus Dateisystem oder bearbeiteten Dokumenten; bisherige Pfad- und Diagnosesemantik erhalten.
+
+### Modified Capabilities
+
+Keine bestehenden Anforderungen werden ersetzt; die neue IDE-Fähigkeit ergänzt die vorhandenen Laufzeit- und Dateiformatverträge.
+
+## Impact
+
+crates/tb-cli/src/main.rs, crates/tb-vm/src/project.rs, crates/tb-frontend/src/source.rs, crates/tb-ui/src/frm.rs und das neue Dokumentmodell in tb-ide; docs/dateiformate.md. Keine neue Crate erforderlich.
+
+**Abhängigkeiten:** Keine offenen Vorgänger; Einstieg in Phase 5.
+
+**Gesamtplanung:** [Phase-5-Übersicht](phase-5-uebersicht.md). Die Nummern geben eine gültige Umsetzungsreihenfolge an; OpenSpec erzwingt Change-Abhängigkeiten nicht automatisch.

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/specs/ide-projekte/spec.md

@@ -0,0 +1,56 @@
+## Purpose
+
+Verwaltet Projekte, bearbeitbare Quell- und Formulardokumente sowie ihre Dateien konsistent zwischen IDE und Compiler, ohne Änderungen oder ursprüngliche Quellorte zu verlieren.
+
+## ADDED Requirements
+
+### Requirement: Gemeinsame Projekt- und Include-Auflösung
+IDE und CLI SHALL BAS-, FRM- und MAK-Quellen mit derselben relativen, DOS-großschreibungsunabhängigen Pfadauflösung laden. Verschachtelte Includes SHALL relativ zur einschließenden Datei aufgelöst werden; Diagnoseorte SHALL Modul, ursprüngliche Datei und physische Zeile erhalten. Offene Dokumente SHALL beim IDE-Übersetzen Vorrang vor ihrem Plattenstand haben.
+
+#### Scenario: Ungespeichertes gemeinsames Include
+- **WHEN** zwei Module dasselbe Include verwenden und dessen geöffneter Text geändert wird
+- **THEN** erhalten beide Module den bearbeiteten Text mit der Identität der Include-Datei; auf der Platte bleibt der bisherige Text bis zum Speichern bestehen
+
+#### Scenario: Fehler beim Öffnen
+- **WHEN** eine Projektdatei fehlt oder ein Include-Zyklus entdeckt wird
+- **THEN** nennt die Diagnose die beteiligten Pfade und das bisher geöffnete Projekt bleibt vollständig erhalten
+
+### Requirement: Projektmitglieder und Startdatei
+Die IDE SHALL New/Open/Save Project, New Module, New Form, Add File und Remove File anbieten. MAK-Mitglieder SHALL geordnet gespeichert werden. Set Start-up File SHALL genau ein vorhandenes BAS- oder FRM-Mitglied auswählbar und dauerhaft erkennbar machen. MAK ohne explizite Auswahl SHALL ihre bisherige Ausführungsreihenfolge und Startformularwahl behalten. Remove File SHALL nur die Mitgliedschaft entfernen und MUST NOT die Datei löschen.
+
+#### Scenario: Projekt wieder öffnen
+- **WHEN** Module und Formulare hinzugefügt, eine Startdatei gewählt und das Projekt gespeichert und erneut geöffnet werden
+- **THEN** bleiben Mitgliedschaft, Reihenfolge und Startdatei erhalten und dieselben Quellen sind auch über die CLI ladbar
+
+#### Scenario: Startdatei entfernen
+- **WHEN** die ausgewählte Startdatei entfernt werden soll
+- **THEN** wird eine Ersatzwahl oder die ausdrückliche Rückkehr zum bisherigen Standard verlangt; Abbrechen verändert nichts
+
+### Requirement: Gemeinsame Dokumente und Ansichten
+Mehrere Codefenster und der Formular-Designer SHALL denselben Dokumentstand benutzen. Fensterfokus, Cursor und Scrollposition SHALL ansichtsbezogen sein. Änderungen SHALL dokumentbezogen als ungespeichert erkennbar sein; Include-Ansichten MUST NOT expandierten Quelltext versehentlich als Ursprungsdatei speichern.
+
+#### Scenario: Zweites Codefenster
+- **WHEN** ein Dokument in zwei Fenstern offen ist und eines den Text ändert
+- **THEN** zeigt das andere denselben neuen Text mit eigener Cursorposition; Schließen einer Ansicht verwirft das Dokument nicht
+
+### Requirement: Verlustfreies Speichern und Wechseln
+Save File, Save File As, Save Project sowie Projektwechsel und IDE-Ende SHALL Änderungen mit Speichern/Verwerfen/Abbrechen behandeln. Fehlgeschlagenes Speichern MUST den bearbeiteten Stand erhalten und darf die letzte gültige Zieldatei nicht beschädigen. Externe Dateiänderungen und bestehende Save-As-Ziele SHALL vor Überschreiben erkennbar sein und eine ausdrückliche Wahl erfordern. Erst erfolgreich gespeicherte Dokumente SHALL als gespeichert gelten.
+
+#### Scenario: Schreibfehler im Projekt
+- **WHEN** ein Mitglied erfolgreich gespeichert wird, ein weiteres aber nicht geschrieben werden kann
+- **THEN** bleibt das zweite als geändert offen, der Fehler nennt den Pfad und das Projekt wird nicht als vollständig gespeichert oder geschlossen gemeldet
+
+#### Scenario: Save As in anderes Verzeichnis
+- **WHEN** ein Projekt unter einem neuen Pfad gespeichert wird
+- **THEN** werden relative Mitgliederverweise so angepasst, dass dieselben Dateien geladen werden; ein fehlgeschlagener Vorgang lässt den bisherigen Projektpfad aktiv
+
+### Requirement: Formularimport und Textaustausch
+Die IDE SHALL bestehende FRM-Leser und die kanonische Textausgabe gemäß forms-dateiformat verwenden. Binäre FRM-Originale MUST beim Import erhalten bleiben; die bearbeitete Textfassung SHALL über ein ausdrücklich gewähltes Ziel gespeichert werden. Load Text und Save Text SHALL Text in das aktive Codedokument einfügen beziehungsweise dessen Auswahl oder gesamten Inhalt exportieren, ohne die Projektmitgliedschaft unbemerkt zu ändern.
+
+#### Scenario: Binäres Formular bearbeiten
+- **WHEN** ein binäres Formular geöffnet, geändert und gespeichert wird
+- **THEN** fordert die IDE einen Text-Zielpfad an; Struktur, Array-Indizes und Code bleiben erhalten und die Binärquelle wird nicht überschrieben
+
+#### Scenario: Textimport rückgängig machen
+- **WHEN** Load Text eine Datei am Cursor einfügt und Undo folgt
+- **THEN** wird der ursprüngliche Dokumenttext wiederhergestellt

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/tasks.md

@@ -0,0 +1,21 @@
+## 1. Gemeinsame Quellen und Projektdateien
+
+- [x] 1.1 Die privaten BAS/FRM/MAK-/Include-Ladefunktionen aus tb-cli in die vorhandene gemeinsame Crate übernehmen und alle CLI-Aufrufer umstellen; die bisherigen Projekt-, Include- und Diagnoseorttests müssen unverändert bestehen.
+- [x] 1.2 Dokumentüberlagerung und stabile virtuelle/physische Quellidentitäten ergänzen; ein Test mit zwei Modulen und einem ungespeicherten Include belegt denselben neuen Inhalt bei getrennten Modulkontexten.
+- [x] 1.3 Optionale Include-Suchpfade mit Vorrang der relativen Datei anbinden; Tests belegen Fallback, Großschreibung, Leerzeichen, fehlende Dateien und benannte Include-Zyklen.
+- [x] 1.4 MAK-Mitgliedschaft, Reihenfolge und optionalen STARTUP-Metakommentar lesen/schreiben; Roundtrip-Tests belegen alte Dateien ohne Metadaten sowie Ablehnung doppelter/ungültiger Startangaben.
+
+## 2. Bearbeitbare Dokumente und sichere Dateiaktionen
+
+- [x] 2.1 Projekt-/Dokumentzustand mit Revision, Pfad, gespeichertem Stand und mehreren Ansichten einführen; ein Test belegt gemeinsame Änderungen bei unabhängigen Cursor-/Scrollpositionen.
+- [x] 2.2 New/Open Project, New Module/Form, Add/Remove File und Startdateiwahl als Dokumentaktionen implementieren; Tests belegen Abbruch ohne Teiländerung und Entfernen ohne Dateilöschung.
+- [x] 2.3 FRM-Code und FormFile-Struktur als gemeinsames Dokument führen; ein Roundtrip mit Control-Array, Index 0 und Ereigniscode bestätigt den bestehenden Textvertrag.
+- [x] 2.4 Save/Save As/Save Project mit geschützten Einzeldatei-Ersetzungen, Mitglieder-vor-MAK-Reihenfolge und Konflikterkennung implementieren; injizierte Schreibfehler und externe Änderungen erhalten jeweils den bearbeiteten Stand und letzte gültige Datei.
+- [x] 2.5 Projekt-Save-As und Dokumentpfadwechsel korrekt auf relative Referenzen anwenden; ein Wiederöffnungstest aus einem anderen Verzeichnis lädt dieselben Mitglieder/Includes.
+- [x] 2.6 Binär-FRM-Import mit ausdrücklichem Textziel sowie Load/Save Text implementieren; Tests belegen unveränderte Binärquelle und rückgängig machbaren Textimport.
+- [x] 2.7 Speichern/Verwerfen/Abbrechen als gemeinsame Wechsel-/Schließaktion anbieten; Tests für mehrere geänderte Dokumente und Teilspeicherfehler verhindern falsches Schließen.
+
+## 3. Nachweise und Dokumentation
+
+- [x] 3.1 docs/dateiformate.md um die optionale Startup-Erweiterung und Speicher-/Importregeln ergänzen; Beispiele werden vom gemeinsamen Loader als erwarteter Projektzustand gelesen.
+- [x] 3.2 Die neue API durch IDE-Backend- und vorhandene CLI-Integrationstests gemeinsam prüfen und den Nachweis je Spec-Szenario in verification.md festhalten; cargo fmt --all -- --check und die betroffenen Crate-Tests müssen bestehen.

openspec/changes/archive/2026-09-06-phase-5-01-projekt-und-dokumentmodell/verification.md

@@ -0,0 +1,108 @@
+# Verifizierung: Phase 5 – Projekt- und Dokumentmodell
+
+Stand: 2026-09-06. Geprüft wurden die Implementierungsänderungen auf Basis
+von `747ec34c6a18fb40ed3f915998e58801f2c36bc9` gegen Proposal, Design,
+Tasks und `specs/ide-projekte/spec.md` dieses Changes.
+
+## Ergebnis
+
+| Dimension | Ergebnis |
+| --- | --- |
+| Vollständigkeit | 13/13 Tasks, 5/5 Anforderungen und 9/9 Szenarien umgesetzt und geprüft |
+| Korrektheit | Szenarien durch Backend-/Loader-Tests und bestehende CLI-Integration abgesichert |
+| Kohärenz | Gemeinsamer Lader in tb-vm, ein Dokumentstand je Datei, bestehendes FormFile und dessen Leser/Schreiber wiederverwendet |
+| Offene Befunde | 0 CRITICAL, 0 WARNING, 0 SUGGESTION |
+
+Die Prüfung umfasst die unmittelbar ausführbare Backend-API dieses Changes.
+Terminalmenüs und Dialoge sind gemäß Design und Phase-5-Übersicht Change 02
+zugeordnet. Die zusätzliche Ausführungswirkung der gespeicherten Startdatei
+ist Change 04 zugeordnet; hier wird die Auswahl validiert, gespeichert und
+in `ProjectSources.manifest.startup` bereitgestellt. Diese Abgrenzungen sind
+auch in `docs/dateiformate.md` festgehalten.
+
+## Anforderungen und Implementierung
+
+Alle Codepfade sind relativ zur Repository-Wurzel angegeben.
+
+| Anforderung | Implementierung und Prüfung |
+| --- | --- |
+| Gemeinsame Projekt- und Include-Auflösung | `crates/tb-vm/src/project_io.rs`: `SourceLoader::{resolve,read,load,load_manifest,expand}` und `relative_case_insensitive`; `crates/tb-cli/src/main.rs::compile` verwendet denselben Lader wie `Project::sources`. Overlay-Inhalte, relative Includes vor Suchpfaden, virtuelle und kanonische Identitäten, Modulkontexte und physische Quellzeilen geprüft. |
+| Projektmitglieder und Startdatei | `Manifest::{parse,text,rename}` sowie `crates/tb-ide/src/documents.rs`: `Project::{new,open,new_module,new_form,add_file,remove_file,set_startup,save_project}`. Geordnete Mitglieder, gewöhnliche Kommentare, optionale eindeutige Startup-Metadaten und alle drei Entscheidungen beim Entfernen der Startdatei geprüft. Bestehende CLI-Projekttests bleiben unverändert grün. |
+| Gemeinsame Dokumente und Ansichten | `Document`, `View`, `Project::{open_document,open_view,close_view,replace_text,edit_form,undo}`. Stabile Dokument-IDs, gemeinsame Inhalte, separate Cursor-/Scrollwerte, Revision und gespeicherter Inhaltsstand; FRM-Struktur und Code liegen in genau einem `FormFile`. Originaldokumente werden getrennt von der Include-Expansion gespeichert. |
+| Verlustfreies Speichern und Wechseln | `Project::{save_file,save_project,prepare_close,open_project,new_project}`, `check_destination`, `atomic_write` und `SourceLoader::relocate`. Temporäre Einzeldateien im Zielverzeichnis, Konfliktprüfung vor Ersetzen, explizite Überschreibentscheidung, Mitglieder vor MAK und Zustandswechsel erst nach erfolgreicher Ausgabe. Teilfehler, Zielkollisionen, externe Änderungen und Save As geprüft. |
+| Formularimport und Textaustausch | `read_document` verwendet vorhandene FRM-Leser; `Content::text` verwendet den vorhandenen Schreiber. `Project::{protect_binary,load_text,save_text,edit_form,undo}` schützt Binäroriginale, verlangt ein separates Textziel und erhält Dokumentidentität/Mitgliedschaft beim Textaustausch. |
+
+## Nachweis je Spec-Szenario
+
+Testnamen ohne weiteren Pfad liegen in `crates/tb-ide/tests/documents.rs`.
+
+| Szenario | Ausführbarer Nachweis |
+| --- | --- |
+| Ungespeichertes gemeinsames Include | `edited_include_wins_in_both_modules_without_writing_the_expansion`; zusätzlich `crates/tb-vm/tests/project_io.rs::overlays_keep_original_files_and_distinct_module_contexts` prüft Quellidentität und getrennte Modulkontexte. |
+| Fehler beim Öffnen | `failed_open_add_and_cancel_do_not_replace_existing_documents`; Loader-Test `cycle_missing_include_and_literal_directives_are_distinguished` prüft fehlende Dateien, benannte Zyklen und Diagnosepfade. |
+| Projekt wieder öffnen | `project_create_save_reopen_preserves_forms_members_startup_and_cli_sources`: zwei BAS-Module, FRM mit Control-Array einschließlich Index 0 und Ereigniscode, Startup-Auswahl, Speicherung/Wiederöffnung sowie Laden und Kompilieren über die gemeinsame CLI-Grundlage. Loader-Test `startup_metadata_roundtrip_and_invalid_contracts` prüft zusätzlich Reihenfolge und ungültige Metadaten. |
+| Startdatei entfernen | `startup_removal_requires_explicit_replacement_and_never_deletes_a_file`: fehlende Entscheidung, Abbruch, ungültiger Ersatz, gültiger Ersatz und Rückkehr zum Standard; physische Datei und geöffnetes Dokument bleiben erhalten. |
+| Zweites Codefenster | `shared_views_text_import_and_undo_are_document_transactions`: zwei Ansichten teilen Änderungen, eigene Positionen bleiben erhalten, Schließen einer Ansicht entfernt das Dokument nicht. |
+| Schreibfehler im Projekt | `partial_save_preserves_unsaved_data_and_does_not_finish_close`: zweites Mitglied schreibgeschützt, erstes erfolgreich gespeichert, zweites unverändert auf Platte und weiterhin dirty, MAK unverändert, Schließen verhindert; erfolgreicher Wiederholungsversuch und Tempdatei-Aufräumen geprüft. |
+| Save As in anderes Verzeichnis | `project_save_as_rebases_members_and_keeps_include_targets`: Wiederöffnung lädt dieselben Inhalte über angepasste relative Mitgliedspfade; fehlendes Zielverzeichnis erhält den bisherigen Projektpfad. `module_save_as_rebases_includes_and_failed_save_does_not_change_identity_or_text` deckt zusätzlich Dokument-Save-As ab. |
+| Binäres Formular bearbeiten | `binary_import_only_saves_to_explicit_text_target_and_preserves_original_forever`: vorhandene Binärfixture importiert, Code bearbeitet, normales Save abgelehnt, ausdrückliches Textziel gespeichert und wieder geöffnet; Originalbytes bleiben unverändert, auch ausdrückliches späteres Überschreiben des Binärpfads wird verhindert. Struktur-/Array-Vertrag zusätzlich durch FRM-Roundtrip im Projekt-Test und bestehende tb-ui-Tests abgesichert. |
+| Textimport rückgängig machen | `shared_views_text_import_and_undo_are_document_transactions`: Text am Cursor eingefügt, Undo stellt ursprünglichen Unicode-Text und Ansichtspositionen wieder her; Auswahl-/Gesamtexport verändert die Mitgliedschaft nicht. |
+
+## Behobene Befunde und zusätzliche Grenzfälle
+
+- Include-Erkennung verwendet den vorhandenen Lexer: Stringliterale, DATA und gewöhnliche Kommentare lösen keine Dateizugriffe aus; Code vor einem echten Inline-Include bleibt erhalten.
+- Bei veränderter Formularstruktur werden physische Codezeilen aus der tatsächlichen Textausgabe ermittelt. `aliases_share_documents_and_form_code_offsets_match_saved_text` prüft dies zusammen mit Großschreibungs- und Symlink-Aliasen.
+- Cursorverschiebung bei verkürzendem Ersetzen verwendet die ursprüngliche Position. Öffnen nach erfolgreichem Speichern liest den neuen Plattenstand. Nachweis: `cursor_after_shortening_uses_original_position_and_open_after_save_uses_fresh_disk`.
+- Dokument-Save-As passt relative Includes an; bei einem fehlgeschlagenen Schreibversuch bleiben ursprünglicher Text und Pfad aktiv. Der Regressionstest prüft auch Kommentare am Include und unveränderte Originaldateien.
+- Großschreibungsunabhängige Pfadauflösung über `..` startet bei einer absoluten Basis. Nachweis: `case_insensitive_parent_lookup_works_from_relative_base_without_changing_cwd` im Loader-Testziel.
+- Nicht als Textverweis darstellbare Ausgabepfade werden vor dem Schreiben abgelehnt. `unrepresentable_save_paths_fail_before_writing_or_changing_documents` prüft Nicht-UTF-8- und Zeilenumbruchpfade sowie verlustfreie Ablehnung bei MAK-Serialisierung.
+- `external_changes_and_save_as_collisions_need_explicit_decisions` und `save_plan_prevents_same_destination_and_project_overwrite` sichern Konfliktentscheidungen und kollidierende Ausgaben ab.
+- `documented_mak_example_is_accepted_by_the_shared_loader` lädt den tatsächlichen MAK-Beispielblock aus `docs/dateiformate.md`.
+
+Die abschließende Wiederholungsprüfung nach den Korrekturen ergab keine
+weiteren Befunde. Die Einzeldatei-Ersetzung bietet bewusst keine globale
+Mehrdatei-Transaktion oder Sperre gegen fremde Editoren; das entspricht der
+ausdrücklichen Designentscheidung und ist dokumentiert.
+
+## Ausgeführte Prüfungen
+
+| Prüfung | Ergebnis |
+| --- | --- |
+| `cargo test --workspace` nach den letzten Codekorrekturen | 501 bestanden, 0 fehlgeschlagen, 2 bereits explizit ignorierte Tests |
+| Neue IDE-Backend-Tests innerhalb dieses Laufs | 14/14 bestanden |
+| Neue gemeinsame Loader-Tests innerhalb dieses Laufs | 6/6 bestanden |
+| Bestehende CLI-Projektintegration innerhalb dieses Laufs | 3/3 bestanden; weitere CLI-, VM-, Frontend-, Runtime- und FRM-Tests ebenfalls grün |
+| `cargo fmt --all -- --check` | bestanden |
+| `cargo clippy -p tb-ide -p tb-cli -p tb-vm --all-targets -- -D warnings` | bestanden |
+| `openspec validate --all --strict --json` | 23/23 gültig: 15 Hauptspecs und 8 Changes |
+| `git diff --check` und Whitespace-Prüfung neuer Dateien | bestanden |
+
+Die beiden ignorierten Tests sind die absichtlich manuell auszulösende
+Golden-File-Erzeugung und der zusätzliche Fremdprogrammtest mit externem
+`TB_VBDOS_REPO`. Kein Test wurde für diesen Change deaktiviert. OpenSpec
+meldet bei bestehenden Hauptspecs lediglich INFO-Hinweise zur Textlänge;
+der aktuelle Change hat keine Validator-Hinweise.
+
+Tests arbeiten mit absoluten temporären Pfaden und verändern das globale
+Arbeitsverzeichnis nicht. Der abschließende Repository-Status enthält die
+Änderungen dieses Changes und keine erzeugten Datenbank-, Druck- oder
+temporären Speicherdateien.
+
+## Erneute Prüfung vor Synchronisation und Archivierung
+
+Am 2026-09-06 wurden Proposal, Design, alle 13 Tasks und alle fünf
+Anforderungen mit neun Szenarien erneut gegen Lader, Dokumentaktionen,
+Speicherpfade und deren Tests abgeglichen. Ergebnis: keine offenen Befunde
+in Vollständigkeit, Korrektheit oder Kohärenz. Die erneut ausgeführten
+Workspace-Tests bestanden mit 501 erfolgreichen und zwei bereits
+ignorierten Tests; Formatprüfung und Clippy für tb-ide, tb-cli und tb-vm
+mit allen Targets und Warnungen als Fehler bestanden ebenfalls.
+
+Die Synchronisation hat `openspec/specs/ide-projekte/spec.md` mit allen
+fünf Anforderungen und neun Szenarien angelegt. Der vollständige Vergleich
+mit der Delta-Spec bestätigt identische Inhalte bei kanonischer
+Hauptspec-Struktur. Vor der Archivierung bestanden 16/16 Hauptspecs die
+strikte Validierung. Danach bestanden erneut 23/23 aktive Einträge
+(16 Hauptspecs, sieben offene Changes). Archivierungsbedingt angepasste
+Markdown-Verweise auf Übersicht, Folgechanges und Repository-Dateien
+wurden auf vorhandene Ziele geprüft.