Let a variable declare struct fields

The value type was already there: StructValue, textOf, sameValue,
writeTyped/mergeStruct and the struct port type came with the first
part, and Get/Set variable carry any-ports, so a bundle already flowed
through the graph unchanged. What was missing was the declaration.

PropertyDef gains kind 'struct' with a list of fields, VARIABLE_KINDS a
fifth kind, variableDef a fifth parameter. A declared field is a
primitive - a list field would need a nested editor and therefore the
path in the slot address, the same step "a list of structs" is waiting
for. coerceValue now returns PropertyValue rather than FieldValue, the
first value type that is not a field; none of its five callers break.

In the inspector a struct variable is a block, not a tab. The list tab
exists because hundreds of rows fit in no inspector row; a struct is the
opposite case - few fields that fit under each other. It is the port
editor Pack already has, one level down and with a value column: type,
key and default value in one place. A placed object sees the same fields
as plain value rows: overriding yes, declaring no.

Adding or removing a field touches the declaration, the default, the
behavior's value and every instance override in one command, so a stored
value can never keep a shape its declaration no longer promises. The row
handlers read the bundle at the moment of the change rather than closing
over a snapshot - a field writes the whole bundle, so with a snapshot
the second edited row revives the first one's old value. defSignature
carries the fields, otherwise a new row appears only at the next
rebuild.

Fixes a fixture fault this uncovered: step 10 pushed its text object
into the scene without instanceEdits, which overrideSites walks with
Object.entries. AddStructFieldCommand is the first caller to reach it
from that state; the step was green alone and failed three checks in the
full suite.

Moves the dynamic-ports note to done - all three of its parts are built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

todo-notes/done/nodes-mit-dynamischer-port-zahl.md

@@ -0,0 +1,361 @@
+## Dynamische Portzahl bei Nodes ermöglichen
+
+Wenn das möglich ist, umsetzen. Folgende Dinge wären dafür praktisch:
+
+### 1. sequence node
+
+diese hat momentan fixe 3 outputs, diese könnten somit ebenfalls dynamisch sein
+
+### 2. eine variable vom typ struct
+
+sprich eine variable die mehreren properties (key mit allen bisher möglichen variablen typen + value).
+dazu passende nodes um von einer variable alle properties zu expanden und umgekehrt (alle werte eines structs setzen)
+
+## variablen vom typ struct und list im inspector
+
+bei typ list: momentan steht es einfach nur als string geparsed in einem textfeld.
+für die liste bräuchten wir eine view, sprich liste mit variablen.
+
+für typ struct: hier wäre natürlich auch eine passende view gut, wo man bei der variable type + key + default value angeben kann.
+
+---
+
+lass uns das mal ausarbeiten. wie weit das sinnvoll bzw. möglich ist.
+
+---
+
+**Umgesetzt (2026-09-10), Teil 1 und der Werttyp. Was offen bleibt, steht unten.**
+
+**Dynamische Ports gab es schon** — nur nicht aus Node-Einstellungen. Verschachtelte Behaviors
+leben seit jeher davon: `GraphNode.ports` speichert eine Deklaration **pro Node**, `resolveDef`
+loest den Def pro Node auf, `portSignature` ist der Ausloeser, an dem View und Inspector merken,
+dass sich eine abgeleitete Portliste geaendert hat. Die Regel dafuer stand als Dreier-Switch auf
+Node-Typen in `nested.ts` — die einzige Stelle im Projekt, die Node-Typen namentlich kannte.
+
+Der Switch ist jetzt **aufgeloest** in zwei Vertraege am `NodeDef`:
+
+- `declaresPorts: 'inputs' | 'outputs'` — der Node traegt seine eigene Portliste, editierbar im
+  Inspector. Das haben `Start`, `End` und neu `Pack`/`Expand`.
+- `derivePorts(source)` — der Node *rechnet* seine Ports aus sich und dem Graphen aus, in dem er
+  sitzt. Das haben `Sequence` (aus den eigenen Kanten) und `Run behavior` (Ports des benannten
+  Behaviors).
+
+**Sequence** hatte zuerst eine Einstellung *Outputs* (2…26). Die ist **wieder weg** — siehe den
+Nachtrag unten: die Ports wachsen jetzt mit den Kanten. Die Keys bleiben `a`, `b`, `c`, … statt
+`out1..N`, weil im Jump-and-Run zwei Nodes an einer Sequence haengen und deren Kanten heil bleiben
+sollen.
+
+**Die einzige echte Falle war das Schrumpfen.** `SetNodeParamCommand` war ein reiner Bag-Schreiber:
+verschwand ein Port, blieb seine Kante liegen — unsichtbar (`drawEdge` steigt bei unbekanntem Port
+still aus), aber sie ueberlebte jedes Speichern und waere beim Hochzaehlen wieder angesprungen.
+Der Befehl ist jetzt port-bewusst und nimmt solche Kanten mit, Undo gibt sie zurueck. Das schliesst
+**einen bestehenden Fehler mit**: derselbe Verwaisungs-Effekt trat schon immer auf, wenn man an
+einem `Run behavior`-Node das Behavior wechselte.
+
+**Struct als echter Werttyp (Weg C).** `PropertyValue` ist jetzt
+`number | string | boolean | ListValue | StructValue`. Felder sind Primitive oder Listen, **nie**
+wieder ein Struct — aus demselben Grund, aus dem eine Liste flach ist.
+
+Zwei Dinge waren dafuer noetig, und beide sind der eigentliche Preis von C:
+
+1. **Ein Objekt auf einer Datenkante hiess bisher zwangslaeufig Entity.** An drei Stellen in
+   `values.ts` bedeutete „Objekt, kein Array" ein Entity-Handle. `EntityHandle` traegt jetzt eine
+   **Symbol-Marke** (`ENTITY_HANDLE`) — ein Symbol, damit kein Struct-Feldname sie imitieren kann,
+   und es serialisiert nie, was fuer etwas richtig ist, das nur waehrend des Spiels existiert.
+   Der Typechecker hat jede betroffene Stelle selbst benannt.
+2. **`String(value)` haette einen Struct als `[object Object]` geschrieben** — an **39** Stellen.
+   Die gehen jetzt alle ueber `textOf()`. Das war kein Stilfehler, sondern eine echte Luecke, die
+   erst der neue Typ sichtbar gemacht hat.
+
+Dazu ein **gemessener, lebender Fehler**, der dabei aufflog und mitrepariert ist: der `List`-Node
+verlor seinen Wert beim Speichern. `normalizeGraph` liess bei Node-Params nur Primitive durch,
+Arrays fielen weg (`[3,1,4]` → `undefined` nach Round-Trip). Listen-*Variablen* waren nicht
+betroffen — die haben ein Schema. Params haben keins, weil sie Einstellungen und Inline-Werte
+mischen.
+
+**Belegt** (`tests/core/dynamic-ports.test.ts`): ein Bündel faehrt ueber **eine** Kante durch ein
+verschachteltes Behavior — `Pack{x:30,y:12}` → `Run behavior`-Port vom Typ `struct` → `Expand` →
+`Add` → 42. Genau die Form, die Tetris heute von Hand parallel fuehrt (`Next move`: 8 rein,
+7 raus; 49 deklarierte Ports ueber 9 Behaviors).
+
+**Offen, bewusst nicht gebaut:**
+- **Variablen vom Typ struct** (Teil 2 der Notiz). Dafuer braucht eine Variable eine editierbare
+  Feldliste im Inspector — die Deklaration liegt bisher nur am Node (`Pack`/`Expand`) und am
+  Behavior-Port. `writeTyped`/`mergeStruct` sind schon darauf vorbereitet: ein Struct-Slot behaelt
+  seine Felder, was ankommt fuellt die benannten, der Rest bleibt stehen.
+- **Die Views im Inspector** (Teil 3). *[Die Listen-Haelfte ist inzwischen gebaut — siehe den
+  Nachtrag „der List-Tab steht". Der Struct-Teil ist weiter offen.]* Das Textfeld war nicht nur
+  Kosmetik: `['red, green', 'blue']` wurde als `"red, green, blue"` geschrieben und las sich als
+  **drei** Items zurueck — ein Komma in einem Text-Item war nicht darstellbar. Fuer den Struct ist
+  Zeile-pro-Feld richtig, das sind wenige.
+- Ein unverbundener `list`-Eingang zeigt weiterhin ein **Zahlenfeld** (`inlineInputDef` hat keinen
+  `list`-Zweig), und eine Listen-Variable kann nur Zahlen-Items: `AddVariableCommand` nimmt `items`
+  gar nicht entgegen.
+
+---
+
+EDIT:
+
+> Eine Liste braucht eher einen **eigenen Editor als Overlay**
+
+ok, eigener tab "List"
+
+dann machen wir es so: es gibt dann einfach statt dem textfeld ein button wo drinnen steht "42 items".
+klickt man darauf switch zu Tab "List" und dort wird die liste aller items dargestellt die man bearbeiten kann.
+
+dort soll auch der selbe "renderer" verwendet werden wie beim inspector.
+
+wenn wir dann struct (teil 3) umsetzen, kann es auch eine liste aus struct variablen geben (bitte das bedenken) und
+im tab "List" sollen variablen (egal welcher type) im prinzip genauso dargestellt werden wie im inspector
+
+---
+
+## Antwort auf den Edit (2026-09-10): geht, mit drei Auflagen
+
+**Der Tab ist hier besser als das Overlay**, aus einem Grund, der erst beim Nachsehen auffiel: der
+Inspector haengt **nicht** im Tab-Bereich, sondern als eigene Spalte daneben (`Editor.ts:156`). Er
+bleibt in jedem Tab sichtbar, der Sprung verliert also keinen Kontext.
+
+**„Derselbe Renderer" ist fast geschenkt.** `createField` (`fieldFactory.ts:171`) braucht als
+Kontext nur `{ project(): Project }` — keine Inspector-Instanz, keinen Command-Stack. Die Zeile
+baut selbst kein Kommando, sie ruft `onInput`/`onChange`. `previewingHandlers` benutzt vom
+`InspectorHost` ausschliesslich `host.state`; den Parametertyp zu verengen macht auch die
+Undo-Mechanik wiederverwendbar. Ein Struct kommt spaeter an *einer* Stelle dazu: dem
+`switch (def.kind)` in `fieldFactory.ts:177`.
+
+**Der Weg in den Tab muss ueber den Zustand laufen, nicht ueber `showTab`.** Kein Tab kennt den
+`Editor`; Tab-Wechsel von innen gibt es nur selektionsgetrieben, gebuendelt in `Editor.ts:169-179`.
+
+### Woran der Tab haengt
+
+Die anderen Tabs haengen an einer Asset-Id. Eine Liste ist kein Asset, sondern ein *Slot*:
+Asset-Property (`assetId+key`), Objekt-Override (`holderId+objectId+key`) oder Node-Param
+(`assetId+nodeId+key`). Also eine explizite Adresse **mit Pfad**, die der Tab behaelt wie die
+anderen ihre Asset-Id und die auf „nichts" zurueckfaellt, wenn das Ziel verschwindet
+(`AssetTabEditor.refresh()` macht genau das). Der Drill-down spaeter ist derselbe Mechanismus
+eine Ebene tiefer.
+
+### Zeile-pro-Item traegt — gemessen
+
+Zeilen echt ueber `createFieldRow` gebaut, mit GPU im Browser, dabei **jeden Frame gescrollt**:
+
+| Zeilen | Aufbau | Display-Objekte | fps |
+|---|---|---|---|
+| 0 (Grundlinie) | – | 11 | 58 |
+| 200 | 15 ms | 2 011 | 51 |
+| 300 | 17 ms | 3 011 | 46 |
+| 3 000 | 122 ms | 30 011 | 18 |
+
+Dagegen die laengsten Listen im echten Bestand: **tetris 224** (`shapes`), **224** (eine
+Variablen-Vorgabe), **200** (`grid`); jumpRun und fixture haben keine. Der reale Hoechstfall liegt
+also bei 224 — **kein Windowing noetig**. Bei 3 000 Eintraegen faellt es auseinander, aber nichts
+kommt dem nahe.
+
+Der eigentliche Fund steckt in der Aufbau-Spalte: 15 ms pro Rebuild bei 200 Zeilen. Deshalb kam
+der Fokus-Schutz zuerst (siehe Nachtrag oben) — ein Rebuild pro Tastendruck waere dort die Regel.
+
+### Was „Liste aus Structs" kostet
+
+Gibt es heute **nicht**: `ListValue = readonly (number | string | boolean)[]` (`Properties.ts:5`),
+`FieldValue` schliesst Struct aus (`:8`), `sameValue` verlaesst sich auf „recurses exactly one level
+deep" (`:50`), `LIST_ITEM_KINDS` kennt kein `struct`, `coerceListItem` gibt ein Primitiv zurueck.
+Das macht `ListValue` und `StructValue` **gegenseitig rekursiv** (beliebige Tiefe, echter
+Deep-Compare) und die Items brauchen eine deklarierte Feldform — wieder „eine geteilte Struct-Form
+hat keine Heimat" (~29 Dateien fuer einen neuen Asset-Typ). Deshalb: Tab jetzt fuer flache Listen,
+aber um einen Pfad herum; die Typerweiterung kommt mit den Struct-Variablen.
+
+Beibehalten: eine **Liste ist homogen** (ein `ListItemKind`), der **Struct** ist das heterogene
+Ding. Das Textfeld sollte als Massenbearbeitung im Tab bleiben, sonst geht das Einfuegen einer
+Komma-Liste verloren. Der unverbundene `list`-Eingang (heute faelschlich ein Zahlenfeld) loest
+sich mit dem Knopf mit.
+
+---
+
+## Nachtrag (2026-09-10): Sequence waechst mit den Kanten, statt gezaehlt zu werden
+
+Das Zahlenfeld *Outputs* war **unbedienbar**: tippen ging nicht, Pfeil rauf/runter ging nicht, nur
+das Ziehen mit der Maus. Die Ursache ist allgemein und nicht `NumberField` zuzuschreiben:
+
+`onInput` (jeder Tastendruck, auch jede Pfeiltaste) → `previewingHandlers` schreibt in
+`node.params` → `state.preview()` → Event `project` → `Inspector.refreshValues()` → die
+`nodeSignature` enthaelt die Portliste, hat sich also geaendert → **`rebuild()` wirft die Zeile
+weg, in der gerade getippt wird.** Ziehen ueberlebt das, weil ein laufender Drag seine
+`globalpointermove`-Events weiter am alten (zerstoerten) Widget bekommt; Tippen braucht den Fokus,
+und den gibt es nach dem Rebuild nicht mehr.
+
+**Diese Falle ist inzwischen zu** (siehe „List-Tab" unten): `refreshValues()` verschiebt einen
+faelligen Rebuild, solange der Fokus im Inspector sitzt, und holt ihn nach, sobald das Feld
+verlassen wird (`FocusManager.changeHandlers` + `isWithin`). Werte sind waehrenddessen ohnehin
+sicher — `TextField.setValue` ignoriert eine laufende Eingabe (`TextField.ts:92`). Damit war der
+Fehler auch nie `NumberField` zuzuschreiben.
+
+Statt das Feld zu reparieren, ist es nach Wunsch des Users **ersetzt**: die Sequence haelt immer
+**einen freien Ausgang unter dem letzten verbundenen**. Nichts verbunden = 1 Ausgang; den
+Ersatz-Ausgang verbinden = ein neuer erscheint; die unterste Kante loesen = schrumpft wieder.
+Gezaehlt wird der letzte *verbundene* Port, nicht die Anzahl der Kanten — so kann keine Kante
+verschwinden, wenn in der Mitte eine geloest wird (dann bleibt eine Luecke stehen).
+
+Preis dafuer: `derivePorts` bekommt jetzt den **Graphen** statt nur der Params
+(`resolveDef(node, graph, lookup)`, ~15 Aufrufstellen, alle hatten den Graphen schon zur Hand),
+und `run` bekommt als viertes Argument den **aufgeloesten Def** — anders kann ein Node mit
+abgeleiteten Ports nicht wissen, wie viele er hat. `SetNodeParamCommand` bleibt port-bewusst, das
+braucht `Run behavior` weiterhin.
+
+Nebeneffekt: die Sequence braucht keinen Param mehr, also auch kein Aufraeumen von Kanten beim
+Verkleinern — eine Kante zu loesen *ist* das Verkleinern.
+
+---
+
+## Nachtrag (2026-09-10): der List-Tab steht
+
+**Gebaut wie im Edit gewuenscht:** eine Listen-Property ist im Inspector ein Knopf `N items`;
+er schaltet auf den neuen sechsten Tab **List**, wo jedes Item eine Zeile mit *demselben*
+Widget bekommt, das der Inspector fuer diese Item-Art baut (`createField` — Zahl, Text, Ja/Nein
+oder Farbe). Der Inspector bleibt daneben stehen, der Kontext geht also nicht verloren.
+
+**Der Weg dorthin laeuft ueber den Zustand**, nicht ueber `showTab`: `EditorState.listSlot` +
+`openList(slot)` + Event `list`; der Editor hoert darauf und schaltet um. Ein Slot ist eine
+**Asset-Property, ein Objekt-Override oder eine Node-Einstellung** — `ListSlot` steht in
+`state.ts` neben `Selection`, weil `state.ts` sonst in einen UI-Ordner importieren muesste.
+`resolveList(state, slot)` in `src/editor/list/slot.ts` liefert Wert, Item-Art, Titel und die
+zwei Schreibwege; die drei Faelle benutzen **exakt die Spec der passenden Inspector-Sektion**,
+also dasselbe Kommando, dieselbe Beschichtung, denselben Undo-Schritt.
+
+**Abweichung vom eigenen Vorschlag:** kein `path` in der Adresse. Ein immer leeres Feld, das
+niemand liest, ist Spekulation; die Naht, an der ein Pfad spaeter ansetzt, ist die **eine**
+Funktion `resolveList` — das ist dann eine Signaturaenderung, kein Umbau. Ehrlicher so.
+
+**Zwei Dinge, die erst die Gegenprobe gezeigt hat:**
+- Die Zeilen-Handler duerfen **nicht** auf einer Momentaufnahme der Liste sitzen. Sie ueberleben
+  einen Commit (der Tab baut nur bei geaenderter *Laenge* neu), also wuerde die zweite bearbeitete
+  Zeile die erste zuruecksetzen. Gemessen: mit Momentaufnahme faellt genau dieser Test.
+- Die Beschichtung in `replace` war **redundant** — alle drei Kommandos laufen selbst durch
+  `coerceValue`. Raus. In `toModel` ist sie noetig: dort entsteht der Wert, der als *Vorschau*
+  am Kommando vorbei direkt ins Modell geschrieben wird. Auch das ist jetzt bewacht.
+
+**Nebenbei mitgenommen:** `showTab` schaltete fuenf `visible`-Zeilen von Hand — nicht
+typgeschuetzt, ein sechster Tab waere dort still vergessen worden. Jetzt ein
+`Record<CentreTab, Widget>`, das jede Auslassung zum Typfehler macht.
+
+Der unverbundene `list`-Eingang zeigt weiterhin ein **Zahlenfeld**: `inlineInputDef` hat keinen
+`list`-Zweig, und der Inline-Pfad kann gar keine Liste erzeugen. Der Knopf loest das nicht mit.
+
+**Zahlen stehen mit drei Nachkommastellen** (`30.000`). Das ist Hausentscheidung, kein Versehen:
+`formatNumber` zeigt immer alle Stellen, „so a value can never look whole when it is not".
+
+**Weiterhin offen:** Variablen vom Typ struct, die Struct-View im Inspector, und „Liste aus
+Structs" (macht `ListValue`/`StructValue` gegenseitig rekursiv — siehe oben).
+
+---
+
+## Nachtrag (2026-09-10): drei Korrekturen am List-Tab
+
+**Kurze Liste baute sich nicht auf** (User: „muss die Fenstergroesse kurz aendern"). Die Ursache
+lag **nicht** im Tab, sondern im `ScrollContainer` — und traf jeden seiner Benutzer, auch `Menu`:
+
+`rebuild()` uebergibt die Zeilen-`VStack` an `setContent()`, solange sie noch **leer** ist. Der
+leere Inhalt wird ueber `Math.max(size.h, this.h)` auf die **Viewporthoehe** gesetzt. Danach kommen
+die Zeilen hinein, und `relayoutContent()` rechnet fuer eine kurze Liste wieder dieselbe Hoehe aus
+— `Widget.resize()` sieht keine Aenderung und **ueberspringt `layout()`** (`Widget.ts:41`). Alle
+Zeilen bleiben auf dem Ursprung gestapelt. Eine *lange* Liste aendert die Hoehe und faellt deshalb
+nie auf; die erste Oeffnung ueberhaupt auch nicht, weil der Tab dann noch `w=h=0` hat.
+
+Gemessen an Tetris, bevor etwas geaendert wurde: `colors` (7) nach `shapes` (224) → alle vier
+Zeilen auf `{245,116}`; `grid` (200) → sauber gestapelt; `test` (16) → wieder kaputt.
+
+Fix in `ScrollContainer.relayoutContent()`: wenn die Groesse gleich bleibt, `layout()` selbst
+rufen. Die Methode wird genau dann gerufen, wenn der Inhalt sich geaendert hat — sich auf die
+Aenderungserkennung von `resize` zu verlassen ist dort grundsaetzlich falsch.
+
+**Die Kommazeile im Fuss ist raus** (User-Wunsch). Damit ist auch der Komma-Fallback in
+`fieldFactory` unerreichbar geworden — jede Sektion, die eine Liste tragen kann, liefert
+`openList` (`assetSection:135`, `nodeSection:134`, `objectSection:325`). Fallback, `listToText`
+und `listFromText` sind geloescht; der Test dafuer ist auf `coerceValue` umgeschrieben statt
+gestrichen, sonst haette `coerceListItem` seine Abdeckung verloren (Boolean-Schreibweise, Farbe).
+
+**JSON-Speicherung war bereits da.** Gemessen an der Projektdatei: `props.shapes` ist ein
+JSON-Array mit 224 Zahlen, kein Komma-String; die PHP-API ist reines JSON. Das Komma war nur die
+*Anzeige* im geloeschten Textfeld. Es bleibt genau eine Stelle, an der ein Komma-Format wirklich
+persistiert wird: eine Liste, die in ein **Text**-Property rutscht, wird ueber `textOf()` zu
+`"1, 2, 3"` (`Properties.ts:33`, via `coerceValue` kind `text`) — betrifft auch die Ausgabe des
+`Log`-Nodes. Der User hat entschieden, das **so zu lassen**; falls eine Liste je verlustfrei durch
+ein Text-Feld muss, ist das die Stelle.
+
+---
+
+## Nachtrag (2026-09-10): Variablen vom Typ struct — Teil 2 und 3 sind zu
+
+**Der Werttyp war fertig, die Deklaration fehlte.** `StructValue`, `textOf`, `sameValue`,
+`writeTyped`/`mergeStruct` und der Port-Typ `struct` gab es seit dem ersten Teil; `Get`/`Set
+variable` haben `any`-Ports, ein Bündel fliesst also ohne Änderung durch den Graphen. Neu ist
+allein, dass eine Variable eine **Feldliste** deklarieren kann:
+`PropertyDef` bekommt `kind: 'struct'` mit `fields: StructFieldDef[]`, `VARIABLE_KINDS` das
+fünfte Kind, `variableDef` einen fünften Parameter.
+
+**Ein deklariertes Feld ist ein Primitiv** (`ListItemKind` — Zahl, Text, Ja/Nein, Farbe), obwohl
+`FieldValue` auch eine Liste zulässt. Grund: ein Listen-Feld bräuchte einen verschachtelten
+Editor und damit den Pfad in der Slot-Adresse — genau der Schritt, auf den auch „Liste aus
+Structs" wartet. Der Werttyp bleibt unverändert, die Erweiterung ist additiv.
+
+**`coerceValue` gibt jetzt `PropertyValue` statt `FieldValue` zurück** — der erste Werttyp, der
+kein Feld ist. Gemessen: das bricht **keine** der fünf Aufrufstellen.
+
+### Die UI: Block statt Zeile — und *nicht* der Tab
+
+Der List-Tab entstand, weil hunderte Zeilen in keine Inspector-Zeile passen. Ein Struct ist der
+Gegenfall: wenige Felder, die untereinander passen. Also kein siebter Tab, keine zweite
+Navigation. Eine Struct-Variable ist ein **Block**:
+
+```
+⊞ [piece   ]        [+ Field ▾] [×]
+    # [x    ] [ 30.000 ] [×]
+   Aa [tag  ] [ tee    ] [×]
+```
+
+Das ist der Port-Editor, den `Pack` schon hat (`portSection.ts`), eine Ebene tiefer und **mit
+Wertspalte**: Typ, Key und Default-Wert an einer Stelle — genau der Wortlaut aus Teil 3 der
+Notiz. Ein **platziertes Objekt** sieht dieselben Felder als reine Wertzeilen (`createField`
+liefert für `struct` einen Stapel beschrifteter Zeilen): überschreiben ja, deklarieren nein.
+
+### Drei Dinge, die den Ausschlag gaben
+
+**Eine Feldänderung muss jeden Wert erreichen.** `AddStructFieldCommand` &co. fassen die
+Deklaration, den Default, den Wert des Behaviors **und jeden Instanz-Override** in *einem*
+Kommando an (`structSites`); sonst behält ein gespeicherter Wert eine Form, die seine
+Deklaration nicht mehr verspricht. Gegenprobe: ohne die Override-Sites fallen 3 Unit-Tests.
+
+**Kein Retype-Knopf** — der Port-Editor hat auch keinen. Feld löschen und neu anlegen.
+
+**Die Handler dürfen nicht auf einer Momentaufnahme sitzen**, dieselbe Falle wie beim List-Tab:
+ein Feld schreibt das *ganze* Bündel, muss es also im Moment der Änderung lesen. Gegenprobe im
+Browser: mit Momentaufnahme wird `{"x":42,"tag":"ell"}` zu `{"x":30,"tag":"ell"}` — die zweite
+bearbeitete Zeile belebt den alten Wert der ersten wieder.
+
+**Die Signatur trägt jetzt die Felder** (`defSignature`): Felder sind eigene Zeilen, ein neues
+Feld muss die Sektion also neu bauen. Ohne das erscheint die Zeile erst beim nächsten Rebuild —
+gemessen, genau ein Browser-Check fällt.
+
+**Weiterhin offen:** „Liste aus Structs" (macht `ListValue`/`StructValue` gegenseitig rekursiv),
+ein Struct-Feld vom Typ Liste, und der unverbundene `list`-Eingang, der immer noch ein Zahlenfeld
+zeigt.
+
+### Der teuerste Fund lag nicht im Struct
+
+Der Schritt lief **solo grün und in der vollen Suite mit drei Fehlschlägen** — identische Klick-
+koordinaten, das Menü ging auf, `Boolean` lag genau unter dem Zeiger, und trotzdem passierte
+nichts. Kein Notice, also war es kein `CommandError`, sondern eine **echte Ausnahme**, die das
+Menü (`closeThen`: erst schliessen, dann ausfuehren) als „Klick auf den Hintergrund" aussehen
+liess.
+
+Halbiert (`GM_STEPS=1-9,22` gruen, `1-10,22` rot) und dann im Fenster abgefangen:
+`Cannot convert undefined or null to object`. Die Ursache ist ein **Fixture-Fehler**: Schritt 10
+schiebt sein Text-Objekt per `mutate` von Hand in die Szene — **ohne `instanceEdits`**, obwohl
+`SceneObject` das Feld verlangt. `overrideSites` laeuft mit `Object.entries` darueber. Mein
+`AddStructFieldCommand` ist die erste Stelle, die `overrideSites` aus diesem Zustand heraus ruft.
+
+Das Produkt bleibt unangetastet: geladen wird das Feld von `normalizeObjects` gefuellt, angelegt
+von den Kommandos — ein Objekt ohne `instanceEdits` kann echt nicht entstehen. Repariert ist das
+Objektliteral im Schritt.
+
+**Lehre fuer den naechsten Schritt:** ein Schritt, der solo gruen ist, ist nicht belegt. Nur der
+volle Lauf sieht, was die Vorgaenger hinterlassen.

todo-notes/show-gizmo-of-disabled-objects.md

@@ -0,0 +1,2 @@
+objects die nicht enabled sind, sind komplett unsichtbar, das passt
+aber: wenn ich sie im panel linksunten selektiere, sollte zumindest das "gizmo" (also der selektions rahmen) im scene viewport sichtbar sein

todo-notes/tetris-mit-structs-neu-bauen.md

@@ -0,0 +1 @@
+Tetris Game mit Structs neu bauen