Grenze aus #51 (Punkt 3 der Entscheidungen): Kommt die Maschine an State branch/Set state aus einer Variablen oder einem Item at, gibt es keine Zustandsports – ein Port wird aus dem Graphen abgeleitet, nicht aus einem Laufzeitwert. Damit lässt sich eine Maschine zwar als Wert herumreichen (Art statemachine), aber nicht dynamisch bedienen.
Vorschlag: zwei Nodes, die mit dem Zustands-Namen arbeiten statt mit Ports:
Set state by name: exec, machine, state (Text) rein; setzt den Zustand, dessen Name (oder Id) passt, sonst nichts.
State branch bekommt zusätzlich einen festen Ausgang else/none für „kein Zustand“ – heute endet der Fluss dort stumm, was beim Debuggen schwer zu sehen ist.
Passt zu Current state (#57): Name raus, Name rein.
Folge-Issue zu #51 (State machine, Commit e7d82bd, 2026-09-12).
Grenze aus #51 (Punkt 3 der Entscheidungen): Kommt die Maschine an `State branch`/`Set state` aus einer **Variablen** oder einem `Item at`, gibt es **keine Zustandsports** – ein Port wird aus dem Graphen abgeleitet, nicht aus einem Laufzeitwert. Damit lässt sich eine Maschine zwar als Wert herumreichen (Art `statemachine`), aber nicht dynamisch bedienen.
**Vorschlag: zwei Nodes, die mit dem Zustands-*Namen* arbeiten** statt mit Ports:
- `Set state by name`: `exec`, `machine`, `state` (Text) rein; setzt den Zustand, dessen Name (oder Id) passt, sonst nichts.
- `State branch` bekommt zusätzlich einen festen Ausgang `else`/`none` für „kein Zustand“ – heute endet der Fluss dort stumm, was beim Debuggen schwer zu sehen ist.
Passt zu `Current state` (#57): Name raus, Name rein.
---
Folge-Issue zu #51 (State machine, Commit `e7d82bd`, 2026-09-12).
Die Lücke, gemessen:Set state und State branch leiten ihre Ports aus dem Graphen ab (machineIdOf() liest den Inline-Pick oder ein State machine-Literal). Kam die Maschine aus einer Variablen oder aus Item at, lieferte machineOf()null, statePorts() eine leere Liste — Set state hatte dann keinen einzigen Eingang, State branch keinen einzigen Ausgang. Die Maschine ließ sich herumreichen, aber nicht bedienen.
Vier Entscheidungen, abgestimmt:
Auflösung Id zuerst, dann Name.stateByName() in stateMachine.ts: passt der Text auf eine State-Id, wird die genommen, sonst der Zustand dieses Namens. Ein Name, den zwei Zustände tragen, antwortet mit nichts — dieselbe Regel, die transitionTo bei zwei gleichnamigen Übergängen befolgt, und aus demselben Grund: ohne etwas im Graphen, das zwischen ihnen entscheidet, wäre jede Wahl geraten.
State branch bekommt else — abgeleitet statt fest, damit der Ausgang unter den Zuständen sitzt, so wie die Ausnahme es am Branch auch tut. Er feuert, wann immer kein Zustands-Ausgang passt: kein Zustand gesetzt, ein Zustand einer fremden Maschine, oder eine Maschine, die als Wert ankommt und deshalb gar keine Zustands-Ausgänge hat. Ein Fluss, der in State branch läuft, kommt damit immer irgendwo heraus. Ein Guard verhindert die Schlüssel-Kollision, falls je eine State-Id else hieße.
Set state by name (neuer Node): exec, machine, Text state — und ein zweiter Exec-Ausgang not found, damit ein Tippfehler, ein gelöschter Zustand oder eine leere Maschine nicht still verschluckt wird, sondern beantwortet werden kann (Log, Standardzustand).
Datenseite unangetastet — Current state liefert bei dynamischer Maschine schon heute name und id, wer vergleichen will nimmt Equals. Kein vierter Weg, dasselbe zu fragen.
Belegt:
npm run check -> 86 Files, 1097 Tests, grün (vorher 1090)
npm run build -> ok
GM_STEPS=26 node e2e.mjs -> ALL PASSED - 63 checks
voller Lauf -> ALL PASSED - 932 checks, 0 FAIL
Der eigentliche Nachweis ist der neue e2e-Block 26j: ein String mit der Maschinen-Id speist Set state by name und einen State branch, der Graph kann die Maschine also nicht benennen — im Lauf funktioniert sie trotzdem. Geprüft wird alles drei in einer laufenden Runde: Zustand per Name gesetzt, dynamischer Branch verlässt über else, falscher Name landet auf not found.
Wiki:State-machines.md (der Absatz "Ports kommen aus dem Graphen" nennt jetzt auch den Ausweg samt Preis: ein Tippfehler ist nicht mehr unmöglich), Behaviors.md, Home.md, Development.md auf 932.
CI-Task 54 auf 1135205 läuft noch; fällt er rot, mache ich das Issue wieder auf.
Umgesetzt in `1135205`, Wiki in `eacf87e`.
**Die Lücke, gemessen:** `Set state` und `State branch` leiten ihre Ports aus dem *Graphen* ab (`machineIdOf()` liest den Inline-Pick oder ein `State machine`-Literal). Kam die Maschine aus einer Variablen oder aus `Item at`, lieferte `machineOf()` `null`, `statePorts()` eine leere Liste — `Set state` hatte dann keinen einzigen Eingang, `State branch` keinen einzigen Ausgang. Die Maschine ließ sich herumreichen, aber nicht bedienen.
**Vier Entscheidungen, abgestimmt:**
1. **Auflösung Id zuerst, dann Name.** `stateByName()` in `stateMachine.ts`: passt der Text auf eine State-Id, wird die genommen, sonst der Zustand dieses Namens. Ein Name, den **zwei** Zustände tragen, antwortet mit nichts — dieselbe Regel, die `transitionTo` bei zwei gleichnamigen Übergängen befolgt, und aus demselben Grund: ohne etwas im Graphen, das zwischen ihnen entscheidet, wäre jede Wahl geraten.
2. **`State branch` bekommt `else`** — abgeleitet statt fest, damit der Ausgang *unter* den Zuständen sitzt, so wie die Ausnahme es am `Branch` auch tut. Er feuert, wann immer kein Zustands-Ausgang passt: kein Zustand gesetzt, ein Zustand einer fremden Maschine, oder eine Maschine, die als Wert ankommt und deshalb gar keine Zustands-Ausgänge hat. Ein Fluss, der in `State branch` läuft, kommt damit immer irgendwo heraus. Ein Guard verhindert die Schlüssel-Kollision, falls je eine State-Id `else` hieße.
3. **`Set state by name`** (neuer Node): `exec`, `machine`, Text `state` — und ein zweiter Exec-Ausgang **`not found`**, damit ein Tippfehler, ein gelöschter Zustand oder eine leere Maschine nicht still verschluckt wird, sondern beantwortet werden kann (Log, Standardzustand).
4. **Datenseite unangetastet** — `Current state` liefert bei dynamischer Maschine schon heute `name` und `id`, wer vergleichen will nimmt `Equals`. Kein vierter Weg, dasselbe zu fragen.
**Belegt:**
```
npm run check -> 86 Files, 1097 Tests, grün (vorher 1090)
npm run build -> ok
GM_STEPS=26 node e2e.mjs -> ALL PASSED - 63 checks
voller Lauf -> ALL PASSED - 932 checks, 0 FAIL
```
Der eigentliche Nachweis ist der neue e2e-Block 26j: ein `String` mit der Maschinen-Id speist `Set state by name` und einen `State branch`, der Graph kann die Maschine also nicht benennen — im Lauf funktioniert sie trotzdem. Geprüft wird alles drei in einer laufenden Runde: Zustand per Name gesetzt, dynamischer Branch verlässt über `else`, falscher Name landet auf `not found`.
**Wiki:** `State-machines.md` (der Absatz "Ports kommen aus dem Graphen" nennt jetzt auch den Ausweg samt Preis: ein Tippfehler ist nicht mehr unmöglich), `Behaviors.md`, `Home.md`, `Development.md` auf 932.
CI-Task 54 auf `1135205` läuft noch; fällt er rot, mache ich das Issue wieder auf.
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.
Grenze aus #51 (Punkt 3 der Entscheidungen): Kommt die Maschine an
State branch/Set stateaus einer Variablen oder einemItem at, gibt es keine Zustandsports – ein Port wird aus dem Graphen abgeleitet, nicht aus einem Laufzeitwert. Damit lässt sich eine Maschine zwar als Wert herumreichen (Artstatemachine), aber nicht dynamisch bedienen.Vorschlag: zwei Nodes, die mit dem Zustands-Namen arbeiten statt mit Ports:
Set state by name:exec,machine,state(Text) rein; setzt den Zustand, dessen Name (oder Id) passt, sonst nichts.State branchbekommt zusätzlich einen festen Ausgangelse/nonefür „kein Zustand“ – heute endet der Fluss dort stumm, was beim Debuggen schwer zu sehen ist.Passt zu
Current state(#57): Name raus, Name rein.Folge-Issue zu #51 (State machine, Commit
e7d82bd, 2026-09-12).Umgesetzt in
1135205, Wiki ineacf87e.Die Lücke, gemessen:
Set stateundState branchleiten ihre Ports aus dem Graphen ab (machineIdOf()liest den Inline-Pick oder einState machine-Literal). Kam die Maschine aus einer Variablen oder ausItem at, liefertemachineOf()null,statePorts()eine leere Liste —Set statehatte dann keinen einzigen Eingang,State branchkeinen einzigen Ausgang. Die Maschine ließ sich herumreichen, aber nicht bedienen.Vier Entscheidungen, abgestimmt:
stateByName()instateMachine.ts: passt der Text auf eine State-Id, wird die genommen, sonst der Zustand dieses Namens. Ein Name, den zwei Zustände tragen, antwortet mit nichts — dieselbe Regel, dietransitionTobei zwei gleichnamigen Übergängen befolgt, und aus demselben Grund: ohne etwas im Graphen, das zwischen ihnen entscheidet, wäre jede Wahl geraten.State branchbekommtelse— abgeleitet statt fest, damit der Ausgang unter den Zuständen sitzt, so wie die Ausnahme es amBranchauch tut. Er feuert, wann immer kein Zustands-Ausgang passt: kein Zustand gesetzt, ein Zustand einer fremden Maschine, oder eine Maschine, die als Wert ankommt und deshalb gar keine Zustands-Ausgänge hat. Ein Fluss, der inState branchläuft, kommt damit immer irgendwo heraus. Ein Guard verhindert die Schlüssel-Kollision, falls je eine State-Idelsehieße.Set state by name(neuer Node):exec,machine, Textstate— und ein zweiter Exec-Ausgangnot found, damit ein Tippfehler, ein gelöschter Zustand oder eine leere Maschine nicht still verschluckt wird, sondern beantwortet werden kann (Log, Standardzustand).Current stateliefert bei dynamischer Maschine schon heutenameundid, wer vergleichen will nimmtEquals. Kein vierter Weg, dasselbe zu fragen.Belegt:
Der eigentliche Nachweis ist der neue e2e-Block 26j: ein
Stringmit der Maschinen-Id speistSet state by nameund einenState branch, der Graph kann die Maschine also nicht benennen — im Lauf funktioniert sie trotzdem. Geprüft wird alles drei in einer laufenden Runde: Zustand per Name gesetzt, dynamischer Branch verlässt überelse, falscher Name landet aufnot found.Wiki:
State-machines.md(der Absatz "Ports kommen aus dem Graphen" nennt jetzt auch den Ausweg samt Preis: ein Tippfehler ist nicht mehr unmöglich),Behaviors.md,Home.md,Development.mdauf 932.CI-Task 54 auf
1135205läuft noch; fällt er rot, mache ich das Issue wieder auf.