Bekannte Lücke aus #51: Zieht man im Behavior-Tab eine Exec-Kante ins Leere, bietet die Palette Nodes mit passendem Eingang an. Set state hat keinen festen Exec-Eingang – seine Exec-Eingänge sind pro Zustand abgeleitet (derivePorts), und dropTarget prüft nur def.inputs. Der Node erscheint deshalb in dieser Palette nicht; er lässt sich nur aus der normalen Palette platzieren und dann verdrahten.
Optionen:
dropTarget fragt für Nodes mit derivePorts einmal die abgeleiteten Ports ab (ohne Maschine gibt es aber noch keine) – oder ein Node darf ankündigen „nimmt Exec-Eingänge an“ (Flag am NodeDef), dann wird er angeboten und die Kante hängt, bis eine Maschine gewählt ist.
Alternativ ein fester Exec-Eingang execohne Wirkung – widerspricht dem Spiegelbild-Design aus #51.
Nachweis im e2e-Schritt 26: Exec-Kante von OnStart ins Leere ziehen, Set state muss in der Liste stehen.
Folge-Issue zu #51 (State machine, Commit e7d82bd, 2026-09-12).
Bekannte Lücke aus #51: Zieht man im Behavior-Tab eine Exec-Kante ins Leere, bietet die Palette Nodes mit passendem Eingang an. `Set state` hat **keinen festen Exec-Eingang** – seine Exec-Eingänge sind pro Zustand abgeleitet (`derivePorts`), und `dropTarget` prüft nur `def.inputs`. Der Node erscheint deshalb in dieser Palette nicht; er lässt sich nur aus der normalen Palette platzieren und dann verdrahten.
**Optionen:**
- `dropTarget` fragt für Nodes mit `derivePorts` einmal die abgeleiteten Ports ab (ohne Maschine gibt es aber noch keine) – oder ein Node darf ankündigen „nimmt Exec-Eingänge an“ (Flag am `NodeDef`), dann wird er angeboten und die Kante hängt, bis eine Maschine gewählt ist.
- Alternativ ein fester Exec-Eingang `exec` **ohne** Wirkung – widerspricht dem Spiegelbild-Design aus #51.
Nachweis im e2e-Schritt 26: Exec-Kante von `OnStart` ins Leere ziehen, `Set state` muss in der Liste stehen.
---
Folge-Issue zu #51 (State machine, Commit `e7d82bd`, 2026-09-12).
Geschlossen als wontfix — nach Nachmessen im Code steht der Aufwand nicht im Verhaeltnis zum Gewinn.
Was heute wirklich passiert:defAcceptsFrom (src/core/graph/dropTarget.ts:57) prueft def.inputs des rohen Defs. Set state (src/core/graph/nodes/flow/SetState.ts:18) hat dort nur den machine-Eingang; seine Exec-Eingaenge entstehen erst in derivePorts, sobald eine Maschine gewaehlt ist. Der Node fehlt deshalb in der Palette, die beim Kanten-Drop ins Leere aufgeht — mehr nicht. Es kracht nichts, es haengt keine halbe Kante, es entsteht kein kaputter Node. Der normale Weg (Node aus der regulaeren Palette, Maschine waehlen, Kante ziehen) funktioniert unveraendert, weil die Zustands-Eingaenge dann echt existieren.
Der Preis fuer den Fix waere eine der drei Varianten, und alle drei kosten mehr, als sie einbringen:
Eine Palettenzeile pro State-machine-Asset (analog zu Run behavior, das genau so aufgeloeste Defs mit echten Ports liefert). Sauber, aber: gilt das dann auch fuer das Spiegelbild State branch? Auf welchen Zustand haengt sich die Kante — den ersten in Knotenreihenfolge oder den Startzustand? Und bei drei Maschinen wachsen zwei Node-Arten auf je vier Palettenzeilen.
Flag am NodeDef ("nimmt Exec-Eingaenge an") — platziert einen Node, dessen Kante unverbunden haengen bleibt, bis man eine Maschine waehlt. Das ist ein Drop, der die Geste nicht zu Ende bringt.
Fester Exec-Eingang exec ohne Wirkung — widerspricht dem Spiegelbild-Design aus #51, wie im Issue schon vermerkt.
Kosten fuer "lassen wir": ein Handgriff mehr in einem Spezialfall.
Falls es im Gebrauch doch stoert, ist der Weg hier dokumentiert: Variante 1 mit Startzustand als Ziel-Port, symmetrisch fuer State branch.
Geschlossen als **wontfix** — nach Nachmessen im Code steht der Aufwand nicht im Verhaeltnis zum Gewinn.
**Was heute wirklich passiert:** `defAcceptsFrom` (`src/core/graph/dropTarget.ts:57`) prueft `def.inputs` des rohen Defs. `Set state` (`src/core/graph/nodes/flow/SetState.ts:18`) hat dort nur den `machine`-Eingang; seine Exec-Eingaenge entstehen erst in `derivePorts`, sobald eine Maschine gewaehlt ist. Der Node fehlt deshalb in der Palette, die beim Kanten-Drop ins Leere aufgeht — mehr nicht. Es kracht nichts, es haengt keine halbe Kante, es entsteht kein kaputter Node. Der normale Weg (Node aus der regulaeren Palette, Maschine waehlen, Kante ziehen) funktioniert unveraendert, weil die Zustands-Eingaenge dann echt existieren.
**Der Preis fuer den Fix** waere eine der drei Varianten, und alle drei kosten mehr, als sie einbringen:
- *Eine Palettenzeile pro State-machine-Asset* (analog zu `Run behavior`, das genau so aufgeloeste Defs mit echten Ports liefert). Sauber, aber: gilt das dann auch fuer das Spiegelbild `State branch`? Auf welchen Zustand haengt sich die Kante — den ersten in Knotenreihenfolge oder den Startzustand? Und bei drei Maschinen wachsen zwei Node-Arten auf je vier Palettenzeilen.
- *Flag am `NodeDef` ("nimmt Exec-Eingaenge an")* — platziert einen Node, dessen Kante unverbunden haengen bleibt, bis man eine Maschine waehlt. Das ist ein Drop, der die Geste nicht zu Ende bringt.
- *Fester Exec-Eingang `exec` ohne Wirkung* — widerspricht dem Spiegelbild-Design aus #51, wie im Issue schon vermerkt.
**Kosten fuer "lassen wir":** ein Handgriff mehr in einem Spezialfall.
Falls es im Gebrauch doch stoert, ist der Weg hier dokumentiert: Variante 1 mit Startzustand als Ziel-Port, symmetrisch fuer `State branch`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bekannte Lücke aus #51: Zieht man im Behavior-Tab eine Exec-Kante ins Leere, bietet die Palette Nodes mit passendem Eingang an.
Set statehat keinen festen Exec-Eingang – seine Exec-Eingänge sind pro Zustand abgeleitet (derivePorts), unddropTargetprüft nurdef.inputs. Der Node erscheint deshalb in dieser Palette nicht; er lässt sich nur aus der normalen Palette platzieren und dann verdrahten.Optionen:
dropTargetfragt für Nodes mitderivePortseinmal die abgeleiteten Ports ab (ohne Maschine gibt es aber noch keine) – oder ein Node darf ankündigen „nimmt Exec-Eingänge an“ (Flag amNodeDef), dann wird er angeboten und die Kante hängt, bis eine Maschine gewählt ist.execohne Wirkung – widerspricht dem Spiegelbild-Design aus #51.Nachweis im e2e-Schritt 26: Exec-Kante von
OnStartins Leere ziehen,Set statemuss in der Liste stehen.Folge-Issue zu #51 (State machine, Commit
e7d82bd, 2026-09-12).Geschlossen als wontfix — nach Nachmessen im Code steht der Aufwand nicht im Verhaeltnis zum Gewinn.
Was heute wirklich passiert:
defAcceptsFrom(src/core/graph/dropTarget.ts:57) prueftdef.inputsdes rohen Defs.Set state(src/core/graph/nodes/flow/SetState.ts:18) hat dort nur denmachine-Eingang; seine Exec-Eingaenge entstehen erst inderivePorts, sobald eine Maschine gewaehlt ist. Der Node fehlt deshalb in der Palette, die beim Kanten-Drop ins Leere aufgeht — mehr nicht. Es kracht nichts, es haengt keine halbe Kante, es entsteht kein kaputter Node. Der normale Weg (Node aus der regulaeren Palette, Maschine waehlen, Kante ziehen) funktioniert unveraendert, weil die Zustands-Eingaenge dann echt existieren.Der Preis fuer den Fix waere eine der drei Varianten, und alle drei kosten mehr, als sie einbringen:
Run behavior, das genau so aufgeloeste Defs mit echten Ports liefert). Sauber, aber: gilt das dann auch fuer das SpiegelbildState branch? Auf welchen Zustand haengt sich die Kante — den ersten in Knotenreihenfolge oder den Startzustand? Und bei drei Maschinen wachsen zwei Node-Arten auf je vier Palettenzeilen.NodeDef("nimmt Exec-Eingaenge an") — platziert einen Node, dessen Kante unverbunden haengen bleibt, bis man eine Maschine waehlt. Das ist ein Drop, der die Geste nicht zu Ende bringt.execohne Wirkung — widerspricht dem Spiegelbild-Design aus #51, wie im Issue schon vermerkt.Kosten fuer "lassen wir": ein Handgriff mehr in einem Spezialfall.
Falls es im Gebrauch doch stoert, ist der Weg hier dokumentiert: Variante 1 mit Startzustand als Ziel-Port, symmetrisch fuer
State branch.