Ein any-Port ist heute grau und bleibt grau, egal was daran hängt. Ports, die inhaltlich denselben Wert tragen (a, b und value bei First not empty aus #205 (Schalter: #206), ähnlich bei Item at), könnten ihren Typ von dem übernehmen, was angeschlossen ist.
Die Regel (Vorschlag aus dem Chat, 2026-09-22)
Der Typ kommt von den verbundenen Eingängen der Gruppe.
Sind beide verbunden und verschieden, oder ist keiner verbunden, bleibt die ganze Gruppe any.
Der Ausgang folgt dem Typ der Eingänge.
Sichtbar wird das an drei Stellen, die alle schon an diesem Typ hängen: Portfarbe (portColor in NodeView.ts), Verbindungsprüfung beim Ziehen (portsCompatible, dropTarget.ts) und das Inline-Feld eines unverbundenen Eingangs (inlineInputDef, NodeRegistry.ts:181 — any fällt heute auf ein Textfeld zurück, typisiert gäbe es ein Zahlenfeld, eine Checkbox oder einen Picker).
Zur Laufzeit ändert sich nichts. Der Interpreter reicht ohnehin Value durch, die Typen sind reine Editor-Sache.
Die Maschinerie ist da, aber nicht ganz
derivePorts (NodeRegistry.ts:104) bekommt node, graph und lookup, kann also die Kanten an a und b nachschlagen. Aber:resolveDef (nested.ts:109) hängt die abgeleiteten Ports nur an die fest registrierten an ([...def.inputs, ...grown.inputs, ...own]). Ein fester Port lässt sich damit nicht umtypisieren, er käme doppelt vor. Entweder der Node registriert seine Ports gar nicht fest und leitet sie komplett ab (dann zeigt die Palette einen Node ohne Ports, solange er nirgends steht), oder resolveDef ersetzt abgeleitete Ports mit gleichem Key statt sie anzuhängen. Die zweite Variante wäre der allgemeine Weg und würde auch Item at und Freunden nützen.
Drei Fallen
Rückkopplung beim Auflösen. Um den Typ des Nachbarn zu erfahren, muss dessen Definition aufgelöst werden — und wenn der Nachbar auch so ein Node ist, fragt der zurück. In einem Datenzyklus läuft das endlos. Vorschlag: Ein solcher Node meldet nach außen immer any und erbt nur von Nodes mit festem Typ. Eine Kette aus zwei First not empty typisiert sich dann nicht durch.
Bestehende Kanten werden nicht nachgeprüft.canConnect läuft nur beim Ziehen. Hängt an b ein Text und man verbindet danach a mit einer Zahl, bleibt die Textkante liegen und ist plötzlich ungültig. Vorschlag: Sie bleibt liegen und wird rot gezeichnet, gelöscht wird nichts von selbst.
Die Reihenfolge wird sichtbar. Wer zuerst a anschließt, legt fest, was b noch annimmt. Das ist gewollt streng, fühlt sich aber anders an als heute.
Rückfragen
Umfang: Nur First not empty, oder gleich allgemein als „Port-Gruppe mit gemeinsamem Typ", die auch Item at, Join und Ähnliche nutzen können? (Empfehlung: allgemein, der Aufwand ist fast derselbe.)
Falle 1, Ketten: Reicht „nur von Nodes mit festem Typ erben" (einfach, vorhersehbar), oder soll sich der Typ über mehrere solche Nodes durchziehen (braucht einen Zyklus-Schutz beim Auflösen)?
Falle 2, ungültig gewordene Kante: rot zeichnen und dulden, oder beim Verbinden gleich wegwerfen (mit Undo-Schritt)?
Gemischt verbunden:a ist eine Zahl, b ist nicht verbunden. Nimmt b dann die Zahl an (Empfehlung, sonst bringt die Sache wenig) oder bleibt b offen für alles?
Inline-Feld: Soll ein unverbundener Eingang wirklich das typgerechte Feld bekommen (Zahlenfeld statt Textfeld)? Dann ändert sich ein schon eingetipptes Inline-any von Text auf Zahl — der alte Text geht dabei verloren, wenn er keine Zahl ist.
value ohne Eingang: Wenn beide Eingänge unverbunden sind, bleibt alles any — auch dann, wenn am Ausgang schon eine typisierte Kante hängt. Soll der Ausgang in dem Fall vom Ziel erben, oder ist das zu viel Magie?
Nicht Teil davon
Die Laufzeit, die Umwandlung von Werten (asTypeOf bleibt wie sie ist) und gespeicherte Graphen — die Ports stehen nicht in der Datei, nur die Kanten.
Ein `any`-Port ist heute grau und bleibt grau, egal was daran hängt. Ports, die inhaltlich denselben Wert tragen (`a`, `b` und `value` bei `First not empty` aus #205 (Schalter: #206), ähnlich bei `Item at`), könnten ihren Typ von dem übernehmen, was angeschlossen ist.
## Die Regel (Vorschlag aus dem Chat, 2026-09-22)
- Der Typ kommt von den **verbundenen** Eingängen der Gruppe.
- Sind beide verbunden und **verschieden**, oder ist **keiner** verbunden, bleibt die ganze Gruppe `any`.
- Der Ausgang folgt dem Typ der Eingänge.
Sichtbar wird das an drei Stellen, die alle schon an diesem Typ hängen: Portfarbe (`portColor` in `NodeView.ts`), Verbindungsprüfung beim Ziehen (`portsCompatible`, `dropTarget.ts`) und das Inline-Feld eines unverbundenen Eingangs (`inlineInputDef`, `NodeRegistry.ts:181` — `any` fällt heute auf ein Textfeld zurück, typisiert gäbe es ein Zahlenfeld, eine Checkbox oder einen Picker).
Zur Laufzeit ändert sich nichts. Der Interpreter reicht ohnehin `Value` durch, die Typen sind reine Editor-Sache.
## Die Maschinerie ist da, aber nicht ganz
`derivePorts` (`NodeRegistry.ts:104`) bekommt `node`, `graph` und `lookup`, kann also die Kanten an `a` und `b` nachschlagen. **Aber:** `resolveDef` (`nested.ts:109`) hängt die abgeleiteten Ports nur **an die fest registrierten an** (`[...def.inputs, ...grown.inputs, ...own]`). Ein fester Port lässt sich damit nicht umtypisieren, er käme doppelt vor. Entweder der Node registriert seine Ports gar nicht fest und leitet sie komplett ab (dann zeigt die Palette einen Node ohne Ports, solange er nirgends steht), oder `resolveDef` ersetzt abgeleitete Ports mit gleichem Key statt sie anzuhängen. Die zweite Variante wäre der allgemeine Weg und würde auch `Item at` und Freunden nützen.
## Drei Fallen
1. **Rückkopplung beim Auflösen.** Um den Typ des Nachbarn zu erfahren, muss dessen Definition aufgelöst werden — und wenn der Nachbar auch so ein Node ist, fragt der zurück. In einem Datenzyklus läuft das endlos. Vorschlag: Ein solcher Node meldet nach außen immer `any` und erbt nur von Nodes mit festem Typ. Eine Kette aus zwei `First not empty` typisiert sich dann nicht durch.
2. **Bestehende Kanten werden nicht nachgeprüft.** `canConnect` läuft nur beim Ziehen. Hängt an `b` ein Text und man verbindet danach `a` mit einer Zahl, bleibt die Textkante liegen und ist plötzlich ungültig. Vorschlag: Sie bleibt liegen und wird rot gezeichnet, gelöscht wird nichts von selbst.
3. **Die Reihenfolge wird sichtbar.** Wer zuerst `a` anschließt, legt fest, was `b` noch annimmt. Das ist gewollt streng, fühlt sich aber anders an als heute.
## Rückfragen
1. **Umfang:** Nur `First not empty`, oder gleich allgemein als „Port-Gruppe mit gemeinsamem Typ", die auch `Item at`, `Join` und Ähnliche nutzen können? (Empfehlung: allgemein, der Aufwand ist fast derselbe.)
2. **Falle 1, Ketten:** Reicht „nur von Nodes mit festem Typ erben" (einfach, vorhersehbar), oder soll sich der Typ über mehrere solche Nodes durchziehen (braucht einen Zyklus-Schutz beim Auflösen)?
3. **Falle 2, ungültig gewordene Kante:** rot zeichnen und dulden, oder beim Verbinden gleich wegwerfen (mit Undo-Schritt)?
4. **Gemischt verbunden:** `a` ist eine Zahl, `b` ist nicht verbunden. Nimmt `b` dann die Zahl an (Empfehlung, sonst bringt die Sache wenig) oder bleibt `b` offen für alles?
5. **Inline-Feld:** Soll ein unverbundener Eingang wirklich das typgerechte Feld bekommen (Zahlenfeld statt Textfeld)? Dann ändert sich ein schon eingetipptes Inline-`any` von Text auf Zahl — der alte Text geht dabei verloren, wenn er keine Zahl ist.
6. **`value` ohne Eingang:** Wenn beide Eingänge unverbunden sind, bleibt alles `any` — auch dann, wenn am Ausgang schon eine typisierte Kante hängt. Soll der Ausgang in dem Fall vom **Ziel** erben, oder ist das zu viel Magie?
## Nicht Teil davon
Die Laufzeit, die Umwandlung von Werten (`asTypeOf` bleibt wie sie ist) und gespeicherte Graphen — die Ports stehen nicht in der Datei, nur die Kanten.
lassen wir es einfach vorerst - über mehrere nodes => extra issue anlegen
rot zeichnen passt fürs erste
klingt komisch aber "b" offen für alles - entsprechender output (falls es gibt) wird einfach zu any
ja, wird verworfen, pech gehabt, inline fliegt raus falls typ nicht mehr passt oder gut geparsed werden kann
wäre zu viel magie, any bleibt any
1. gute empfehlung, allgemein passt
2. lassen wir es einfach vorerst - über mehrere nodes => extra issue anlegen
3. rot zeichnen passt fürs erste
4. klingt komisch aber "b" offen für alles - entsprechender output (falls es gibt) wird einfach zu any
5. ja, wird verworfen, pech gehabt, inline fliegt raus falls typ nicht mehr passt oder gut geparsed werden kann
6. wäre zu viel magie, any bleibt any
admin
added this to the Development project 2026-09-22 20:34:42 +02:00
admin
moved this to Next in Development on 2026-09-22 20:34:44 +02:00
Ein NodeDef kann jetzt sagen, welche seiner Ports denselben Wert tragen (sharedType: { inputs, outputs }). Angewandt ist das bisher auf First not empty (a, b → value), die Regel selbst liegt als reine Funktion agreedType in src/core/graph/portTypes.ts.
Variante A, wie in der Rückfrage entschieden:
Nur der Ausgang erbt. Sind alle Eingänge der Gruppe verbunden und tragen denselben Typ, wird der Ausgang dieser Typ — gefärbt und nur noch dorthin verbindbar, wo dieser Typ passt. Sonst bleibt er any.
Die Eingänge bleiben any und nehmen weiter alles an. Das ist kein Detail: canConnect prüft gegen den Porttyp, und ein belegter Eingang wird beim Verbinden ersetzt. Wäre a erst einmal Zahl, ließe sich seine Kante nie mehr durch einen Text ersetzen.
Keine Kette (Antwort 2): Beim Nachschlagen, was einen Eingang speist, meldet ein Node derselben Art das any, mit dem er registriert ist. Zwei First not empty hintereinander typisieren sich also nicht durch — und können sich in einem Datenzyklus nicht im Kreis fragen.
Eine ungültig gewordene Kante bleibt liegen und wird rot (Antwort 3). Das kam geschenkt: EdgeLayer färbt eine Kante schon immer mit danger, wenn die Enden nicht zusammenpassen. Getrennt wird nichts von selbst.
Zur Laufzeit ändert sich nichts.
Nachtrag: farbige Eingangs-Pins
Im Gespräch kam die Frage auf, warum die Eingänge grau bleiben, obwohl die Kante farbig ist. Das ist mit hineingezogen worden:
Neues Feld PortDef.paintType — reine Malfarbe, nirgends Wahrheit. Gesetzt in drawnDef, gelesen nur in NodeView.redraw. resolveDef ist unberührt, also sehen canConnect, Interpreter und Compiler weiter any.
Jeder verbundene any-Eingang wird in der Farbe seiner eigenen Kante gezeichnet, generisch, nicht nur in einer sharedType-Gruppe. Geister-Ports bleiben hohl und rot umrandet.
Damit ist auch der Mischfall sichtbar: a von einer Zahl, b von einem Text → zwei Farben, und das erklärt, warum der Ausgang grau bleibt.
Befunde
resolveDef hängt abgeleitete Ports nur an die registrierten an — ein fester Port lässt sich so nicht umtypisieren, er käme doppelt vor. Der gemeinsame Typ wird deshalb aufgelöst, bevor die Ports gebaut werden.
Antwort 5 (Inline-Feld) hat keinen Fall mehr. Ein unverbundener Eingang bleibt unter Variante A any und behält sein Textfeld.
Item at, Join und Equals profitieren nicht:Item at hat keinen any-Eingang, die anderen beiden haben feste Ausgänge. Die naheliegenden nächsten Nutzer wären die Shader-Arithmetik-Nodes (a, b → result, alle any); die sind bewusst nicht angefasst.
14 neue Unit-Tests in tests/core/shared-port-type.test.ts: die reine Regel, ein Eingang allein, beide gleich, beide verschieden, Undo, Umstecken über canConnect, keine Kette, die ungültig gewordene Kante, dazu die sechs Fälle zur Malfarbe.
9 neue e2e-Checks (Block 6z, Modul 06): legen ein Wegwerf-Behavior an, ziehen die Kanten wirklich mit der Maus und lesen die gezeichneten Typen und Kantenfarben. Einer davon ist ein Pixelcheck direkt am Pin (pixelAt auf portAt) gegen themeColor('portString') bzw. ('portNumber').
Vier Gegenproben, alle greifen: unverbundene Eingänge in agreedType herausfiltern → 3 Unit-Tests fallen; inherit ignorieren → 1 Unit-Test fällt; die Ableitung im Bundle wirkungslos machen → genau die 2 erwarteten e2e-Checks fallen (value bleibt any, Kantenfarbe #bdbdbd statt #e0553f); paintType nie setzen → 4 Unit-Tests und die 3 Pin-Checks fallen. Originale per cmp zurück, danach neu gebaut.
Screenshot angesehen:a rosa (string), b grün (number), Ausgang value grau, Kanten in denselben Farben.
Drei neue Hooks:__gm.graph.portTypes(id) (meldet Typ und Malfarbe getrennt), __gm.graph.edgeColor(id), __gm.themeColor(name).
Check-Summe 1302 (1293 von CI gemessen an 1a3babf, + 9). Auf den CI-Lauf zu d7a2521 wurde nicht gewartet.
Doku im Wiki: Behaviors (Ports mit gemeinsamem Typ, bemalte Pins) und Development (Summe).
Umgesetzt in `d7a2521`, Wiki `0c04ceb`.
## Was gebaut wurde
Ein `NodeDef` kann jetzt sagen, welche seiner Ports **denselben Wert tragen** (`sharedType: { inputs, outputs }`). Angewandt ist das bisher auf `First not empty` (`a`, `b` → `value`), die Regel selbst liegt als reine Funktion `agreedType` in `src/core/graph/portTypes.ts`.
**Variante A, wie in der Rückfrage entschieden:**
- **Nur der Ausgang erbt.** Sind alle Eingänge der Gruppe verbunden und tragen denselben Typ, wird der Ausgang dieser Typ — gefärbt und nur noch dorthin verbindbar, wo dieser Typ passt. Sonst bleibt er `any`.
- **Die Eingänge bleiben `any`** und nehmen weiter alles an. Das ist kein Detail: `canConnect` prüft gegen den Porttyp, und ein belegter Eingang wird beim Verbinden ersetzt. Wäre `a` erst einmal Zahl, ließe sich seine Kante nie mehr durch einen Text ersetzen.
- **Keine Kette** (Antwort 2): Beim Nachschlagen, was einen Eingang speist, meldet ein Node derselben Art das `any`, mit dem er registriert ist. Zwei `First not empty` hintereinander typisieren sich also nicht durch — und können sich in einem Datenzyklus nicht im Kreis fragen.
- **Eine ungültig gewordene Kante bleibt liegen und wird rot** (Antwort 3). Das kam geschenkt: `EdgeLayer` färbt eine Kante schon immer mit `danger`, wenn die Enden nicht zusammenpassen. Getrennt wird nichts von selbst.
- Zur Laufzeit ändert sich nichts.
## Nachtrag: farbige Eingangs-Pins
Im Gespräch kam die Frage auf, warum die Eingänge grau bleiben, obwohl die Kante farbig ist. Das ist mit hineingezogen worden:
- **Neues Feld `PortDef.paintType`** — reine Malfarbe, nirgends Wahrheit. Gesetzt in `drawnDef`, gelesen nur in `NodeView.redraw`. `resolveDef` ist unberührt, also sehen `canConnect`, Interpreter und Compiler weiter `any`.
- **Jeder verbundene `any`-Eingang** wird in der Farbe seiner eigenen Kante gezeichnet, generisch, nicht nur in einer `sharedType`-Gruppe. Geister-Ports bleiben hohl und rot umrandet.
- Damit ist auch der **Mischfall sichtbar**: `a` von einer Zahl, `b` von einem Text → zwei Farben, und das erklärt, warum der Ausgang grau bleibt.
## Befunde
- `resolveDef` hängt abgeleitete Ports nur **an die registrierten an** — ein fester Port lässt sich so nicht umtypisieren, er käme doppelt vor. Der gemeinsame Typ wird deshalb aufgelöst, bevor die Ports gebaut werden.
- **Antwort 5 (Inline-Feld) hat keinen Fall mehr.** Ein unverbundener Eingang bleibt unter Variante A `any` und behält sein Textfeld.
- **`Item at`, `Join` und `Equals` profitieren nicht:** `Item at` hat keinen `any`-Eingang, die anderen beiden haben feste Ausgänge. Die naheliegenden nächsten Nutzer wären die Shader-Arithmetik-Nodes (`a`, `b` → `result`, alle `any`); die sind bewusst nicht angefasst.
## Tests
```
./check.sh → 143 Files, 2127 Tests, CHECK EXIT 0 (vorher 142 / 2113)
GM_STEPS=1-6 (frisch) → ALL PASSED – 245 checks (vorher 242)
npm run build → BUILD EXIT 0
```
- **14 neue Unit-Tests** in `tests/core/shared-port-type.test.ts`: die reine Regel, ein Eingang allein, beide gleich, beide verschieden, Undo, Umstecken über `canConnect`, keine Kette, die ungültig gewordene Kante, dazu die sechs Fälle zur Malfarbe.
- **9 neue e2e-Checks (Block 6z, Modul 06):** legen ein Wegwerf-Behavior an, ziehen die Kanten wirklich mit der Maus und lesen die gezeichneten Typen und Kantenfarben. Einer davon ist ein **Pixelcheck direkt am Pin** (`pixelAt` auf `portAt`) gegen `themeColor('portString')` bzw. `('portNumber')`.
- **Vier Gegenproben, alle greifen:** unverbundene Eingänge in `agreedType` herausfiltern → 3 Unit-Tests fallen; `inherit` ignorieren → 1 Unit-Test fällt; die Ableitung im Bundle wirkungslos machen → genau die 2 erwarteten e2e-Checks fallen (`value` bleibt `any`, Kantenfarbe `#bdbdbd` statt `#e0553f`); `paintType` nie setzen → 4 Unit-Tests und die 3 Pin-Checks fallen. Originale per `cmp` zurück, danach neu gebaut.
- **Screenshot angesehen:** `a` rosa (string), `b` grün (number), Ausgang `value` grau, Kanten in denselben Farben.
- **Drei neue Hooks:** `__gm.graph.portTypes(id)` (meldet Typ und Malfarbe getrennt), `__gm.graph.edgeColor(id)`, `__gm.themeColor(name)`.
- Check-Summe **1302** (1293 von CI gemessen an `1a3babf`, + 9). Auf den CI-Lauf zu `d7a2521` wurde nicht gewartet.
Doku im Wiki: *Behaviors* (Ports mit gemeinsamem Typ, bemalte Pins) und *Development* (Summe).
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.
Ein
any-Port ist heute grau und bleibt grau, egal was daran hängt. Ports, die inhaltlich denselben Wert tragen (a,bundvaluebeiFirst not emptyaus #205 (Schalter: #206), ähnlich beiItem at), könnten ihren Typ von dem übernehmen, was angeschlossen ist.Die Regel (Vorschlag aus dem Chat, 2026-09-22)
any.Sichtbar wird das an drei Stellen, die alle schon an diesem Typ hängen: Portfarbe (
portColorinNodeView.ts), Verbindungsprüfung beim Ziehen (portsCompatible,dropTarget.ts) und das Inline-Feld eines unverbundenen Eingangs (inlineInputDef,NodeRegistry.ts:181—anyfällt heute auf ein Textfeld zurück, typisiert gäbe es ein Zahlenfeld, eine Checkbox oder einen Picker).Zur Laufzeit ändert sich nichts. Der Interpreter reicht ohnehin
Valuedurch, die Typen sind reine Editor-Sache.Die Maschinerie ist da, aber nicht ganz
derivePorts(NodeRegistry.ts:104) bekommtnode,graphundlookup, kann also die Kanten anaundbnachschlagen. Aber:resolveDef(nested.ts:109) hängt die abgeleiteten Ports nur an die fest registrierten an ([...def.inputs, ...grown.inputs, ...own]). Ein fester Port lässt sich damit nicht umtypisieren, er käme doppelt vor. Entweder der Node registriert seine Ports gar nicht fest und leitet sie komplett ab (dann zeigt die Palette einen Node ohne Ports, solange er nirgends steht), oderresolveDefersetzt abgeleitete Ports mit gleichem Key statt sie anzuhängen. Die zweite Variante wäre der allgemeine Weg und würde auchItem atund Freunden nützen.Drei Fallen
anyund erbt nur von Nodes mit festem Typ. Eine Kette aus zweiFirst not emptytypisiert sich dann nicht durch.canConnectläuft nur beim Ziehen. Hängt anbein Text und man verbindet danachamit einer Zahl, bleibt die Textkante liegen und ist plötzlich ungültig. Vorschlag: Sie bleibt liegen und wird rot gezeichnet, gelöscht wird nichts von selbst.aanschließt, legt fest, wasbnoch annimmt. Das ist gewollt streng, fühlt sich aber anders an als heute.Rückfragen
First not empty, oder gleich allgemein als „Port-Gruppe mit gemeinsamem Typ", die auchItem at,Joinund Ähnliche nutzen können? (Empfehlung: allgemein, der Aufwand ist fast derselbe.)aist eine Zahl,bist nicht verbunden. Nimmtbdann die Zahl an (Empfehlung, sonst bringt die Sache wenig) oder bleibtboffen für alles?anyvon Text auf Zahl — der alte Text geht dabei verloren, wenn er keine Zahl ist.valueohne Eingang: Wenn beide Eingänge unverbunden sind, bleibt allesany— auch dann, wenn am Ausgang schon eine typisierte Kante hängt. Soll der Ausgang in dem Fall vom Ziel erben, oder ist das zu viel Magie?Nicht Teil davon
Die Laufzeit, die Umwandlung von Werten (
asTypeOfbleibt wie sie ist) und gespeicherte Graphen — die Ports stehen nicht in der Datei, nur die Kanten.Umgesetzt in
d7a2521, Wiki0c04ceb.Was gebaut wurde
Ein
NodeDefkann jetzt sagen, welche seiner Ports denselben Wert tragen (sharedType: { inputs, outputs }). Angewandt ist das bisher aufFirst not empty(a,b→value), die Regel selbst liegt als reine FunktionagreedTypeinsrc/core/graph/portTypes.ts.Variante A, wie in der Rückfrage entschieden:
any.anyund nehmen weiter alles an. Das ist kein Detail:canConnectprüft gegen den Porttyp, und ein belegter Eingang wird beim Verbinden ersetzt. Wäreaerst einmal Zahl, ließe sich seine Kante nie mehr durch einen Text ersetzen.any, mit dem er registriert ist. ZweiFirst not emptyhintereinander typisieren sich also nicht durch — und können sich in einem Datenzyklus nicht im Kreis fragen.EdgeLayerfärbt eine Kante schon immer mitdanger, wenn die Enden nicht zusammenpassen. Getrennt wird nichts von selbst.Nachtrag: farbige Eingangs-Pins
Im Gespräch kam die Frage auf, warum die Eingänge grau bleiben, obwohl die Kante farbig ist. Das ist mit hineingezogen worden:
PortDef.paintType— reine Malfarbe, nirgends Wahrheit. Gesetzt indrawnDef, gelesen nur inNodeView.redraw.resolveDefist unberührt, also sehencanConnect, Interpreter und Compiler weiterany.any-Eingang wird in der Farbe seiner eigenen Kante gezeichnet, generisch, nicht nur in einersharedType-Gruppe. Geister-Ports bleiben hohl und rot umrandet.avon einer Zahl,bvon einem Text → zwei Farben, und das erklärt, warum der Ausgang grau bleibt.Befunde
resolveDefhängt abgeleitete Ports nur an die registrierten an — ein fester Port lässt sich so nicht umtypisieren, er käme doppelt vor. Der gemeinsame Typ wird deshalb aufgelöst, bevor die Ports gebaut werden.anyund behält sein Textfeld.Item at,JoinundEqualsprofitieren nicht:Item athat keinenany-Eingang, die anderen beiden haben feste Ausgänge. Die naheliegenden nächsten Nutzer wären die Shader-Arithmetik-Nodes (a,b→result, alleany); die sind bewusst nicht angefasst.Tests
tests/core/shared-port-type.test.ts: die reine Regel, ein Eingang allein, beide gleich, beide verschieden, Undo, Umstecken übercanConnect, keine Kette, die ungültig gewordene Kante, dazu die sechs Fälle zur Malfarbe.pixelAtaufportAt) gegenthemeColor('portString')bzw.('portNumber').agreedTypeherausfiltern → 3 Unit-Tests fallen;inheritignorieren → 1 Unit-Test fällt; die Ableitung im Bundle wirkungslos machen → genau die 2 erwarteten e2e-Checks fallen (valuebleibtany, Kantenfarbe#bdbdbdstatt#e0553f);paintTypenie setzen → 4 Unit-Tests und die 3 Pin-Checks fallen. Originale percmpzurück, danach neu gebaut.arosa (string),bgrün (number), Ausgangvaluegrau, Kanten in denselben Farben.__gm.graph.portTypes(id)(meldet Typ und Malfarbe getrennt),__gm.graph.edgeColor(id),__gm.themeColor(name).1a3babf, + 9). Auf den CI-Lauf zud7a2521wurde nicht gewartet.Doku im Wiki: Behaviors (Ports mit gemeinsamem Typ, bemalte Pins) und Development (Summe).