ValueOn AG d4095db4f2 fixes

2026-04-25 01:13:24 +02:00

24 KiB

Raw Blame History

Obsolet — ersetzt durch c-work/1-plan/2026-04-typed-generic-handover.md.

Dieser Plan behandelte die Symptome (Connection-Inheritance-Service, Wire-Source-Badge, attachmentBuilder-Alias) als Workarounds um den heuristischen _wireHandover herum. Die Diskussion vom 2026‑04‑23 hat ergeben, dass das Modell selbst nicht trägt: der „Push"-Handover via INPUT_EXTRACTORS ist generisch nicht beherrschbar. Der Nachfolge-Plan ersetzt das durch ein Pick-not-Push Modell mit reichhaltigen statischen Schemas, harter Type-Validierung und expliziten DataRefs als einzigem Bindungs-Mechanismus. Drei Punkte aus diesem Plan (3-Modus ConnectionPicker, attachmentBuilder Renderer-Alias, FrontendType-Audit) wurden in den Nachfolger als Phase 6 übernommen.

Graph-Editor: Connection-UX, Wire-Handover und Feld-Rendering bereinigen (obsolet)

Beschreibung und Kontext

Der Graphical Editor (graphicalEditor-Feature) ist seit dem Generic-Graph-Editor-Refactor (c-work/4-done/2026-04-generic-graph-editor.md) auf typisierte Ports + Wire-Handover umgestellt. Beim Pilot-Workflow PWG Mietzinsbestaetigung (local/temp/pwg-pilot-jahresmietzinsbestätigung.workflow (1).json) zeigen sich vier konkrete Schwachstellen, die das User-Erlebnis im Editor brechen:

Connection wird pro Node neu erfragt. Im PWG-Workflow ist n2.sharepoint.listFiles mit connection:msft:p.motsch@valueon.ch konfiguriert. n4.sharepoint.downloadFile und n10.email.draftEmail haben dieselbe Authority (msft), aber connectionReference: "". Der _wireHandover in gateway/modules/workflows/automation2/executors/actionNodeExecutor.py propagiert nur Port-Schema-Felder (documents, emails, ...) via INPUT_EXTRACTORS (gateway/modules/features/graphicalEditor/portTypes.py). connectionReference wird nirgends weitergereicht. Folge: jede Node fragt erneut nach Connection.
ConnectionPicker immer als Dropdown. frontend_nyla/src/components/FlowEditor/nodes/frontendTypeRenderers/index.tsx (ConnectionPicker, Z. 153–198) rendert immer <select> und einen Hilfstext, wenn keine Connection da ist — aber keinen Link auf die User-Connections-Seite, und auch bei genau einer Connection bleibt es ein Dropdown statt einer Direktanzeige.
Nicht alle Felder rendern sauber. email.draftEmail.attachments deklariert frontendType: attachmentBuilder (gateway/modules/features/graphicalEditor/nodeDefinitions/email.py:88). In FRONTEND_TYPE_RENDERERS (frontendTypeRenderers/index.tsx:608–633) gibt es keinen attachmentBuilder-Renderer → Fallback auf TextInput, das den JSON-Array stringifiziert anzeigt. clickupList / clickupTask mappen auf einen generischen FolderPicker (Plain-Textfeld), nicht auf einen echten ClickUp-Picker.
Handovers zwischen Nodes sind nicht klar. In der Property-Panel-Ansicht (NodeConfigPanel.tsx) ist die "Datenfluss"-Sektion in <details> versteckt und zeigt nur abstrakte Port-Schemas (DocumentList, AiResult). Es ist für den User unsichtbar, welcher Parameter automatisch via Wire befüllt wird, aus welchem Upstream-Node und mit welchem Feld. Dadurch entsteht der Eindruck, der User müsse alles selbst eingeben.

Business-Treiber: PWG-Pilot startet im Sommer 2026. Editor-UX muss verständlich sein, sonst kostet die Demo-Vorführung beim Kunden Vertrauen. Auch jeder weitere Workflow-Bauer (intern + Customer Onboarding) profitiert sofort.

Risiko bei Nicht-Umsetzung: PWG-Pilot-User (und Demo-Publikum) erlebt den Editor als „alles muss ich von Hand eintragen" und „Das System weiss nicht, dass ich nur einen Outlook habe". Schwer zu verkaufen.

Abhaengigkeiten: keine externen. Greift in bereits ausgelieferte (done) Komponenten ein:

c-work/4-done/2026-04-generic-graph-editor.md (Typed-Port-System, Wire-Handover-Mechanik)
c-work/4-done/2026-04-pwg-pilot-mietzinsbestaetigung-workflow.md (Pilot-Workflow + email.draftEmail.attachments)

Fokus und kritische Details

Connection-Inheritance ist Greenfield-Erweiterung der Wire-Handover-Mechanik. Der bestehende _wireHandover in actionNodeExecutor.py arbeitet auf der direkten Vorgaenger-Node und nur fuer Schema-Felder. Connection-Inheritance braucht einen anderen Algorithmus: transitive Suche nach Authority durch den Upstream-Pfad — aktuell verwendet noch keiner so etwas. Fragil: wenn mehrere Upstream-Pfade unterschiedliche Authorities ihrer User-Connection nutzen (z.B. flow.merge mit Outlook + ClickUp), darf nichts blind uebernommen werden.
Frontend- und Backend-Inheritance muessen konsistent sein. Wenn das Frontend per Default einen Wert fuer connectionReference setzt (Auto-Fill), wird er beim Save persistiert und ist genauso explizit wie eine User-Wahl. Backend-Fallback ("wenn leer, suche Upstream") ist die zweite Verteidigungslinie fuer alte/manuell editierte Workflows. Beides bauen, aber Frontend ist Hauptmechanismus — sonst sieht der User auf dem Canvas nicht, dass die Node "weiss, was sie tun wird".
ConnectionPicker braucht 3 Modi. Code muss klar zwischen den Faellen unterscheiden — kein Dropdown wenn 0 oder 1 Connection. Bei 0 Connections: Link auf /profile/connections (siehe ConnectionsPage.tsx) mit Authority-Vorausfilter und Rueckkehr-URL.
attachmentBuilder muss entweder echt gebaut oder zu json redirected werden. Im Pilot-Plan (c-work/4-done/2026-04-pwg-pilot-mietzinsbestaetigung-workflow.md, Sub-Task 4b) wurde explizit "NICHT NÖTIG" entschieden — aber dann muss der Fallback wenigstens JsonEditor sein (kompakter Editor mit Syntax-Hint), nicht ein 1-zeiliges Text-Field. Pragmatisch: Alias attachmentBuilder → json registrieren, damit kein zweiter Renderer noetig ist.
clickupList / clickupTask Stubs koennen separat gefixt werden (eigene Iteration), sind kein Blocker fuer den PWG-Pilot. Hier nur als bekannt-Stub markieren und auf text mit Hinweis "ClickUp-Picker tbd" mappen.
Datenfluss-Sichtbarkeit muss inline pro Parameter rendern, nicht in einem versteckten <details>-Block. Pro Parameter, der per INPUT_EXTRACTORS aus dem Upstream-Output befuellbar ist, ein Badge 🔗 Wire: {srcNode} → {schemaField}. Pro connectionReference mit gefundenem Upstream-Match: Badge 🔗 uebernommen aus {srcNode}.
Keine Node-Type-spezifische Logik im Frontend. Alle Inheritance-Regeln per Daten gesteuert: Backend liefert pro Parameter eine Liste wireSources: [{nodeId, fieldPath, schema}], das Frontend rendert generisch. Sonst wird der Renderer wieder zu einer Sammlung von Spezialfaellen.

Ziel und Nicht-Ziele

Ziel:

Beim Anlegen einer neuen Node mit connectionReference-Parameter wird die Connection automatisch vorbelegt, wenn entweder (a) der User genau eine Connection mit passender authority hat oder (b) ein Upstream-Pfad bereits eine connectionReference derselben authority verwendet.
ConnectionPicker zeigt 3 Zustaende:
- 0 Connections (passende Authority): Link "Verbindung anlegen" -> /profile/connections?authority=msft&returnTo=....
- 1 Connection: Direktanzeige [msft] p.motsch@valueon.ch mit kleinem "Aendern"-Link, der das Dropdown sichtbar macht.
- >1 Connections: Dropdown wie heute.
Backend-Fallback: ist beim Run connectionReference leer und es gibt eindeutig einen Upstream-Wert mit derselben Authority, wird er verwendet (und im AutoStepLog.inputSnapshot markiert: "connectionReference_inferredFrom": "n2").
attachmentBuilder-Felder rendern als JsonEditor (Alias-Mapping), bis ein dedizierter Builder gebaut wird — nicht mehr als 1-zeiliges Text-Field.
Im Property-Panel sieht der User pro Parameter, ob er via Wire befuellt wird (Badge mit Quell-Node + Feldname). connectionReference-Parameter zeigen "uebernommen aus {nodeId}" wenn auto-inferred.
API liefert pro Node-Inspector-Aufruf zusaetzlich eine wireSources-Map: pro Parameter-Name eine Liste der moeglichen/aktiven Wire-Quellen (basierend auf Graph + INPUT_EXTRACTORS).

Explizit NICHT:

Keine Aenderung am Wire-Handover-Algorithmus fuer Schema-Felder (documents, emails, ...). Der bleibt wie er ist.
Keine neuer Picker fuer clickupList/clickupTask. Diese bleiben als „bekannte Luecken" markiert; eigene Iteration.
Kein dedizierter AttachmentBuilder-Renderer. Alias auf JsonEditor reicht. Wird in einer Folgeiteration nachgereicht, wenn Mehrnode-Cases das verlangen.
Keine Migration alter Workflows. Wer leere connectionReference hat, profitiert ab sofort vom Backend-Fallback; wer eine fixierte (auch falsche) hat, behaelt sie.
Keine Aenderung an der RBAC-/Permission-Schicht. User sieht nur Connections, die er ohnehin sehen darf (getUserConnections(userId) ist bereits user-scoped).
Keine Persistenz der Inferenz-Entscheidung in der Workflow-DB. Inferenz ist immer Run-Time-Heuristik (Frontend setzt explizit, Backend faellt nur defensiv zurueck).

Betroffene Module

Gateway:
- gateway/modules/workflows/automation2/executors/actionNodeExecutor.py — neuer Helper _inferConnectionFromUpstream(nodeDef, inputSources, nodeOutputs, allNodes, params), vor _resolveConnectionParam aufgerufen.
- gateway/modules/features/graphicalEditor/routeFeatureGraphicalEditor.py — node-types-Endpoint bzw. ein neuer wire-sources-Endpoint (oder Integration in GET /{instanceId}/workflows/{workflowId}/wire-sources?nodeId=...) liefert pro Node-Parameter die moeglichen Wire-Quellen.
- gateway/modules/features/graphicalEditor/wireSourcesService.py (NEU, klein) — Pure-Helper computeWireSources(graph, nodeId) der pro Parameter listet, woher Wire/Connection-Inheritance kommen koennten.
Frontend:
- frontend_nyla/src/components/FlowEditor/nodes/frontendTypeRenderers/index.tsx — ConnectionPicker ueberarbeiten (3 Modi), attachmentBuilder-Alias auf JsonEditor, clickupList/clickupTask mit Hint-Text.
- frontend_nyla/src/components/FlowEditor/editor/NodeConfigPanel.tsx — pro Parameter Wire-Source-Badge inline rendern; "Datenfluss"-Sektion umbauen oder entfernen, wenn alles inline gezeigt wird.
- frontend_nyla/src/components/FlowEditor/editor/Automation2FlowEditor.tsx (oder dort, wo eine neue Node erzeugt wird) — Frontend-Auto-Fill: bei Add-Node mit connectionReference-Param + 1 passende Connection → vorbelegen; oder Upstream-Pfad scannen und passende connectionReference uebernehmen.
- frontend_nyla/src/api/workflowApi.ts — neue Wrapper fuer wire-sources-Endpoint.
DB-Migration: nein.
Andere: wiki/b-reference/gateway/automation.md Ergaenzung "Connection-Inheritance" und "Wire-Sources-API" am Ende der Iteration (siehe Abschluss).

Entscheidungen

Datum	Entscheidung	Begruendung
2026-04-23	Connection-Inheritance: Frontend Auto-Fill (primaer) + Backend Run-Time Fallback (defensiv)	UI muss zeigen "ich weiss, welche Connection" — nur Backend-Fallback waere unsichtbar; nur Frontend laesst alte/importierte Workflows leer
2026-04-23	Authority-Match-Regel: gleiche `frontendOptions.authority` UND gleiche Connection im Upstream-Pfad UND eindeutig (kein Konflikt)	Konservativ: lieber unausgefuellt lassen als falsche Connection einsetzen
2026-04-23	`ConnectionPicker`: 0 Connections → Link auf `/profile/connections?authority=...`	Einheitlich mit dem bestehenden `ConnectionsPage.tsx`; Filter fuer den schnellen Anlege-Pfad
2026-04-23	`attachmentBuilder` → `JsonEditor` als Alias (nicht eigener Renderer)	Pilot-Plan hat Builder explizit gestrichen; Alias verhindert kaputten 1-zeiligen Text-Fallback
2026-04-23	`clickupList`/`clickupTask` bleiben Stubs — Hint-Text "ClickUp-Picker tbd"	Nicht im Scope dieser Iteration; eigene Folge-Iteration
2026-04-23	Wire-Source-Anzeige inline pro Parameter, nicht in `<details>`	Sichtbarkeit ist der Hauptpunkt des Issues — alles, was hinter Click verborgen ist, gilt nicht als geloest
2026-04-23	`wireSources` als Server-berechnetes Datum (kein Frontend-Re-Implement der Extractor-Logik)	Single Source of Truth; vermeidet Drift zwischen FE/BE Extractor-Mappings

Umsetzungs-Checkliste

Phase 1 — Connection-Inheritance Backend

gateway/modules/features/graphicalEditor/wireSourcesService.py (NEU): Pure-Helper, der fuer eine Node alle Upstream-Nodes (transitiv via connections) liefert. Pro Connection-Authority-Konflikt → kein Vorschlag (None); sonst die einzige passende connectionReference.
gateway/modules/workflows/automation2/executors/actionNodeExecutor.py: neuer Helper _inferConnectionFromUpstream(nodeDef, context, params) ruft den oben gebauten Service. Wird vor _resolveConnectionParam aufgerufen, nur wenn connectionReference leer und der Parameter authority gesetzt ist.
In AutoStepLog.inputSnapshot zusaetzliches Feld connectionReference_inferredFrom: <nodeId> schreiben, wenn der Fallback griff. Nutzt das bestehende Step-Logging (workflows/automation2/executionEngine.py).
Unit-Test gateway/tests/unit/graphicalEditor/test_wireSourcesService.py:
- Linear: 3 Nodes, n1 hat msft-Connection, n3 erbt.
- Konflikt: n1 hat msft-User-A, n2 hat msft-User-B (per merge-Pfad), n3 darf nichts erben.
- Keine Authority im Param → kein Vorschlag.
- Loop-Body-Node erbt von Loop-Header-Vorgaenger (durchgereicht).

Phase 2 — Wire-Sources API

gateway/modules/features/graphicalEditor/routeFeatureGraphicalEditor.py: neuer Endpoint POST /{instanceId}/wire-sources mit Body { graph: { nodes, connections }, nodeId } → Response { parameters: { <paramName>: [{ srcNodeId, srcField, schema, kind: "wire"|"connection" }] } }. POST damit Editor-Drafts (noch nicht persistiert) abfragen koennen.
Zugriffspruefung wie bei node-types (_validateInstanceAccess).
Unit/API-Test gateway/tests/integration/graphicalEditor/test_wire_sources.py mit dem PWG-Pilot-Workflow als Fixture.

Phase 3 — `ConnectionPicker` 3-Modus-UX

frontend_nyla/src/components/FlowEditor/nodes/frontendTypeRenderers/index.tsx ConnectionPicker:
- Zustaende ableiten aus connections.length.
- 0: Kontext-Link <a href="/profile/connections?authority=${authority}">Verbindung anlegen</a>. (Pruefen: existiert die ConnectionsPage.tsx-Route mit authority-Query-Filter? Falls nein, in Phase 3 trivial ergaenzen.)
- 1: Direkt-Anzeige [<authority>] <label>, kleines Aendern-Link blendet ein <select> ein (lokaler State expanded); Save-Klick auf andere Option setzt direkt. Wenn value leer ist, wird die einzige Connection als Default sofort onChange gefeuert (Auto-Save).
- 1: aktuelles Dropdown bleibt.
Frontend-Helper useAutomation2DataFlow (oder analog) liefert wireSources aus dem neuen Endpoint; bei connectionReference mit gefundenem Vorschlag wird der Vorschlag als Default genommen.
Klein-Refactor: connections-Loading aus ConnectionPicker in einen geteilten Hook useUserConnections(authority) ziehen, damit auch Automation2FlowEditor.tsx (Add-Node-Auto-Fill) ihn nutzen kann ohne erneuten Fetch.
Manueller UI-Smoke-Test gegen jede der 3 Branches dokumentieren.

Phase 4 — Frontend Auto-Fill bei Add-Node und beim Wire

Automation2FlowEditor.tsx (oder dem Add-Node-Code-Pfad): wenn neue Node erzeugt wird, die einen connectionReference-Parameter mit frontendOptions.authority hat → wireSources-API aufrufen (oder lokal useUserConnections(authority)) und params.connectionReference = inferredOrSingle.
Wenn Edge gezogen wird (onConnectionsChange), automatisch wireSources neu auffrischen → Downstream-Nodes aktualisieren ggf. ihre Default-connectionReference. Nicht ueberschreiben, wenn der User bereits einen abweichenden Wert gesetzt hat (verifiziert via wasUserSet-Flag im Node-State oder: nur setzen wenn connectionReference === "").
Test (manuell, dokumentiert): Workflow PWG laden → n4/n10 sollten beim Oeffnen automatisch die msft-Connection aus n2 anzeigen.

Phase 5 — Wire-Source-Badge im Property-Panel

frontend_nyla/src/components/FlowEditor/editor/NodeConfigPanel.tsx:
- Pro Parameter, der in wireSources[paramName] mindestens einen Eintrag hat: kleiner Badge unter dem Label 🔗 {srcLabel}.{srcField} (Tooltip: Schema). Wenn der Wert aktuell leer ist, den Badge in Vordergrund-Farbe rendern (= "wird live befuellt"). Wenn der User einen expliziten Wert hat, schwaecher (= "Override aktiv").
- Fuer connectionReference mit Vorschlag: Badge 🔗 uebernommen aus {srcNode}.
- Bestehender <details>-Block "Datenfluss" wird schlanker: zeigt nur noch die Port-Schemas (Eingabe / Ausgabe) als Referenz, nicht mehr als zentrale Erklaerung — die zentrale Erklaerung steht jetzt inline.
Smoke-Test gegen den PWG-Pilot: Klick durch jede Node, Badges zeigen plausible Quellen.

Phase 6 — `attachmentBuilder` Alias + Renderer-Audit

In frontendTypeRenderers/index.tsx FRONTEND_TYPE_RENDERERS ergaenzen: attachmentBuilder: JsonEditor (oder ein Wrapper mit Hint Felder: contentRef | csvFromVariable | base64Content).
Pruefen: gibt es weitere im Backend genutzte frontendType-Werte ohne Renderer? (Aktueller Stand: nein — attachmentBuilder ist die einzige Luecke; clickupList/clickupTask zeigen aktuell FolderPicker-Stub.)
Im fallthrough ?? FRONTEND_TYPE_RENDERERS.text: Console-Warning [FlowEditor] Missing renderer for frontendType=... (param=...) damit zukuenftige Luecken sichtbar werden.

Querschnitt

API-Endpunkte: ja, 1 neuer (POST /{instanceId}/wire-sources).
DB-Schema / Migration: nein.
Frontend-Komponenten: ConnectionPicker + NodeConfigPanel + Add-Node-Pfad in Automation2FlowEditor.
RBAC / Permissions: unveraendert; wire-sources-API bleibt instanz-scoped.
Neutralisierung betroffen? Nein — keine sensiblen Daten ausserhalb der bestehenden Pfade.
Navigation / Routing: /profile/connections?authority=... Filter pruefen / ggf. ergaenzen.
Billing-Impact? Nein.

Akzeptanzkriterien

#	Kriterium (Given-When-Then)	Prio
1	Given User mit genau einer msft-Connection, When eine neue `email.draftEmail`-Node hinzugefuegt wird, Then ist `connectionReference` automatisch vorbelegt mit dieser Connection (kein Klick noetig).	must
2	Given Workflow mit n2 (msft-Connection gesetzt) → n4 (msft, leer) → n10 (msft, leer), When der User n4 oder n10 oeffnet, Then zeigt der `ConnectionPicker` die uebernommene Connection inkl. Badge `🔗 uebernommen aus n2`.	must
3	Given User ohne msft-Connection, When `email.draftEmail`-Node oeffnet, Then zeigt `ConnectionPicker` einen Link "Verbindung anlegen" auf `/profile/connections?authority=msft` (kein leeres Dropdown).	must
4	Given User mit 3 msft-Connections, When `sharepoint.listFiles`-Node oeffnet, Then erscheint ein Dropdown mit allen 3 Optionen (kein Auto-Pick).	must
5	Given Workflow-Run mit n4 ohne `connectionReference` und Upstream n2 hat eine eindeutige msft-Connection, When ausgefuehrt, Then verwendet n4 die msft-Connection von n2 und der Step-Log enthaelt `connectionReference_inferredFrom: "n2"`.	must
6	Given Workflow mit zwei Upstream-Pfaden, die beide msft-Connections aber unterschiedlicher User haben, When n3 ohne `connectionReference` ausgefuehrt wird, Then wird keine Connection inferiert; der Lauf failt mit klarer Fehlermeldung "Connection nicht eindeutig — bitte explizit waehlen".	should
7	Given `email.draftEmail.attachments`-Parameter (frontendType `attachmentBuilder`), When der User die Node oeffnet, Then erscheint ein JSON-Editor (mehrzeilig, monospace), nicht ein 1-zeiliges Text-Field.	must
8	Given Property-Panel einer Node, deren `documentList`-Parameter via Wire befuellt wird, When User die Node oeffnet, Then steht unter dem Parameter ein Badge `🔗 {srcNode}.documents` (sichtbar ohne `<details>` zu oeffnen).	must
9	Given Frontend benutzt einen `frontendType`, fuer den kein Renderer registriert ist, When die Node gerendert wird, Then erscheint im Browser-Console eine Warning `Missing renderer for frontendType=...`.	should
10	Given PWG-Pilot-Workflow, When der Editor geoffnet wird, Then ist in keiner der 10 Nodes ein `connectionReference`-Feld leer (alles via Single-Connection oder Upstream-Inheritance befuellt) — kein User-Klick noetig, um zu starten.	must

Testplan

ID	AC	Art	Automatisiert	Repo-Pfad	Status
T1	5, 6	unit	ja	`gateway/tests/unit/graphicalEditor/test_wireSourcesService.py`	pending
T2	5	integration	ja	`gateway/tests/integration/graphicalEditor/test_actionNodeExecutor_inheritance.py` (neu — minimaler Run, prueft Step-Log)	pending
T3	1–4, 7–10	manuell UI	nein	Lokale Dev-Umgebung mit dem PWG-Pilot-Workflow (`pwg-mietzinsbestaetigung-pilot.workflow.json`); siehe Smoke-Cookbook unten	pending
T4	5, 6	api	ja	`gateway/tests/integration/graphicalEditor/test_wire_sources.py`	pending
T5	9	manuell	nein	DevTools-Console waehrend T3 mitlesen	pending

Smoke-Test-Kochbuch

PWG-Demo laden (POST /api/admin/demoConfigs/pwg-demo-2026/load); Login pwg.demo.
AC 10: PWG-Pilot-Workflow oeffnen → durch alle 10 Nodes klicken → in jeder Node mit connectionReference muss ein Wert oder Inheritance-Badge sichtbar sein, kein leerer Picker.
AC 1: Neue email.draftEmail-Node aus der Palette ziehen → sofort vorbelegt.
AC 3: Test-User ohne msft-Connection (zweiter Demo-User?) — email.draftEmail-Node hinzufuegen → Link statt Dropdown.
AC 4: Im Demo-Mandant zwei msft-Connections fuer denselben User anlegen (Test-Setup) → Dropdown erscheint wieder.
AC 7: email.draftEmail.attachments-Feld ansehen → JSON-Editor, nicht 1-zeilig.
AC 8: Beliebige Mid-Pipeline-Node oeffnen → Wire-Badges sichtbar.
AC 5: Workflow ausfuehren → Step-Log ansehen → connectionReference_inferredFrom taucht in Snapshots auf, wo erwartet.

Abschluss

wiki/b-reference/gateway/automation.md ergaenzen: Sektion Connection-Inheritance und POST /wire-sources-API.
wiki/b-reference/frontend-nyla/architecture.md ergaenzen: ConnectionPicker-3-Modus-UX, Wire-Source-Badges im NodeConfigPanel.
wiki/TOPICS.md pruefen: existierender Eintrag fuer Generic Graph Editor reicht; ggf. „Connection-Inheritance" als Subzeile.
Folge-Iteration als Eintrag in c-work/0-ideas/: dedizierter AttachmentBuilder-Renderer und echte clickupList/clickupTask-Picker.
Dieses Dokument → c-work/2-build/ verschieben sobald Phase 1 startet.

24 KiB Raw Blame History Unescape Escape