wiki/z-archive/c-work/2026-04-graph-editor-node-config-fixes-obsolete.md

<!-- status: obsolete -->
<!-- archivedFrom: c-work/4-done/2026-04-graph-editor-node-config-fixes.md -->
<!-- archivedAt: 2026-04-23 -->
<!-- started: 2026-04-23 -->
<!-- obsoletedAt: 2026-04-23 -->
<!-- supersededBy: c-work/1-plan/2026-04-typed-generic-handover.md -->
<!-- component: gateway | frontend-nyla -->
<!-- relatedTo: c-work/4-done/2026-04-generic-graph-editor.md, c-work/4-done/2026-04-pwg-pilot-mietzinsbestaetigung-workflow.md -->

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

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.