# 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.