> **Obsolet — ersetzt durch [`c-work/1-plan/2026-04-typed-generic-handover.md`](../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: 1. **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. 2. **`ConnectionPicker` immer als Dropdown.** `frontend_nyla/src/components/FlowEditor/nodes/frontendTypeRenderers/index.tsx` (`ConnectionPicker`, Z. 153–198) rendert immer `` 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. 3. **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. 4. **Handovers zwischen Nodes sind nicht klar.** In der Property-Panel-Ansicht (`NodeConfigPanel.tsx`) ist die "Datenfluss"-Sektion in `

` 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 `

`-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 `

` | 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: ` 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: { : [{ 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 `Verbindung anlegen`. (Pruefen: existiert die `ConnectionsPage.tsx`-Route mit `authority`-Query-Filter? Falls nein, in Phase 3 trivial ergaenzen.) - 1: Direkt-Anzeige `[] `, kleines `Aendern`-Link blendet ein `

` 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 `

`-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 `

` 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 1. PWG-Demo laden (`POST /api/admin/demoConfigs/pwg-demo-2026/load`); Login `pwg.demo`. 2. **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. 3. **AC 1:** Neue `email.draftEmail`-Node aus der Palette ziehen → sofort vorbelegt. 4. **AC 3:** Test-User ohne msft-Connection (zweiter Demo-User?) — `email.draftEmail`-Node hinzufuegen → Link statt Dropdown. 5. **AC 4:** Im Demo-Mandant zwei msft-Connections fuer denselben User anlegen (Test-Setup) → Dropdown erscheint wieder. 6. **AC 7:** `email.draftEmail.attachments`-Feld ansehen → JSON-Editor, nicht 1-zeilig. 7. **AC 8:** Beliebige Mid-Pipeline-Node oeffnen → Wire-Badges sichtbar. 8. **AC 5:** Workflow ausfuehren → Step-Log ansehen → `connectionReference_inferredFrom` taucht in Snapshots auf, wo erwartet. ## Links - Vorgaenger-Plan: `wiki/c-work/4-done/2026-04-generic-graph-editor.md` (Typed Ports, Wire-Handover-Mechanik) - Vorgaenger-Plan: `wiki/c-work/4-done/2026-04-pwg-pilot-mietzinsbestaetigung-workflow.md` (Pilot, `attachmentBuilder`-Entscheidung) - Beispiel-Workflow mit den Issues: `local/temp/pwg-pilot-jahresmietzinsbestätigung.workflow (1).json` - Backend Wire-Handover: `gateway/modules/workflows/automation2/executors/actionNodeExecutor.py`, `gateway/modules/features/graphicalEditor/portTypes.py` - Frontend Renderer-Registry: `frontend_nyla/src/components/FlowEditor/nodes/frontendTypeRenderers/index.tsx` - Frontend Property-Panel: `frontend_nyla/src/components/FlowEditor/editor/NodeConfigPanel.tsx` - Frontend Editor: `frontend_nyla/src/components/FlowEditor/editor/Automation2FlowEditor.tsx` - User-Connections-Seite: `frontend_nyla/src/pages/basedata/ConnectionsPage.tsx` - Connection-Options-API: `gateway/modules/features/graphicalEditor/routeFeatureGraphicalEditor.py` (`get_user_connection_options`) - PR: ... - Issue: ... ## 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.