## Context

`tb_ui::frm::FormFile`/`FormNode` enthalten Klassen, Eigenschaften, Kinder und Code. Der Writer erhält unveränderte Eingaben und kanonisiert geänderte Formulare; `Index = 0` ist strukturell relevant. Frontend-Forms-Metadaten kennen Klassen, Properties und Ereignissignaturen. Die Runtime kennt FormsModel und TextScreen. Der Designer nutzt die Dokumentaktionen aus 01, Fenster aus 02 und Codeoperationen aus 03.

## Goals / Non-Goals

**Goals:** Dasselbe gespeicherte Formular führt zu derselben Runtime-Struktur; alle Designaktionen lassen sich ohne Programmausführung prüfen.

**Non-Goals:** Neuer FRM-Parser, zweite Property-Datenbank, eigenes Layoutformat, Ausführen von Load/Click/Timer in der Vorschau.

## Decisions

1. Der Designer bearbeitet den vorhandenen FormFile-Baum. Editor und Designer teilen das Dokument, nicht nur gelegentlich synchronisierte Kopien. Stabile editorinterne Objektidentitäten werden nicht aus flüchtigen Runtime-Katalog-IDs abgeleitet. Der Compile-Katalog wird aus dem jeweiligen Baum neu erzeugt; ein reiner Wertwechsel und ein struktureller Wechsel invalidieren den Cache aus 03 entsprechend.
2. Eine isolierte Preview-FormsModel-Instanz wird aus dem Dokument aufgebaut und auf TextScreen gerendert. Ihre Aufgabe ist ausschließlich Geometrie/Darstellung; VM-Callbacks und Timer sind nicht aktiv. Auswahlrahmen, Raster und Handles legt die IDE darüber. Vorhandene Berechnung von Containerkoordinaten und Control-Defaults wird wiederverwendet; Runtime-Fokus-/Hit-Test darf Designer-Auswahl nicht verschlucken.
3. Toolbox, Properties und Event-Auswahl werden aus vorhandenen Klassen-/Property-/Event-Metadaten abgeleitet. Dazu gehören auch bereits ergänzte Spinvarianten; die kürzere historische Toolbox-Liste darf unterstützte Klassen nicht still ausschließen. Timer erhält eine sichtbare Designmarke, obwohl er zur Laufzeit unsichtbar ist. Ein Tabellen-Test bindet jede designfähige Klasse an einen Platzier-/Persistenznachweis.
4. Drag, Größenänderung, Mehrfachaktionen, Propertyedit und Menüumordnung sind Dokumenttransaktionen mit gemeinsamem Undo. Geometrie wird vor Commit gegen Container und gültige Wertebereiche geprüft. Text- und Control-Zwischenablage unterscheiden sich durch den aktiven Modus; Copy/Paste eines Containers nimmt seine Kinder mit. Einfügen vergibt konfliktfreie Namen/Indizes.
5. Properties Bar folgt der Referenz: F2 auf Value, F10 Menü/Properties, keine Statuszeile. Menüdesigner und Palette sind konkrete Kindfenster des Rahmens. Supported-Shortcut-Liste kommt aus den vorhandenen Forms-Verträgen; bekannte nicht unterstützte Importwerte werden nicht als gültige Wahl angeboten. Menu.Caption, Indent/Outdent, Reihenfolge, Index und Flags bleiben direkt im FormNode-Baum.
6. F12 erzeugt Code mit der vorhandenen Ereignissignatur einschließlich BYREF-/Typ- und Indexparametern. Vorhandene Handler werden parsergestützt gesucht, nicht durch bloße Teilstrings. Neue Handler verwenden den Prozedurerzeugungsweg aus 03. Beim Umbenennen werden gebundene Namen und sicher aufgelöste Objektverweise in allen betroffenen Projektdokumenten als eine Transaktion geändert; bei Konflikt oder unklaren betroffenen Referenzen wird vollständig abgebrochen. Ungebundener alter Code wird bei Löschen als solcher erkennbar erhalten, nicht automatisch entfernt.
7. Designer→Code→Designer und Save/Reopen verwenden dieselbe FRM-Ausgabe aus 01. Binärimporte benötigen einen Text-Zielpfad. Das gespeicherte Ergebnis wird zusätzlich vom bestehenden CLI-Compiler geladen, damit Preview-Erfolg keinen fehlerhaften FRM-Export verdeckt.

## Risks / Trade-offs

- Baumänderung verschiebt Katalog-IDs → editorinterne Identität separat, Katalog neu bilden; keine gespeicherten Runtime-Indizes als Editorreferenz.
- Rename beschädigt Code → token-/symbolgebundene Änderungen, Konfliktabbruch ohne Teiländerungen; keine globale String-Ersetzung.
- Vorschau führt Programmcode aus → nur Forms-Darstellung ohne VM; Test mit Load-/Timer-Handlern, deren Nebenwirkung ausbleiben muss.
- Preview und Runtime laufen auseinander → Save/Reopen plus Runtime-Rendervergleich für dasselbe Formular; Runtime-Nachweis im Integrationschange 08.

## Migration Plan

Designeraktionen bauen auf bestehenden Formaten auf; keine Formatmigration. Unveränderte Formulare behalten ihre Originalausgabe, geänderte die bestehenden kanonischen Regeln. Umsetzung ist nach 01–03 möglich; der gemeinsame Run-Arbeitsablauf wird nach 04 in 08 abgenommen.
