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