Dragging a link end onto the canvas and dropping it on nothing should open a context menu to create a node filtered by the compatible types

[matt-edmondson]

[matt-edmondson]

Triage

• Priority: Low — a workflow/UX improvement for the node graph editor, not a bug. Valuable for discoverability but nothing is broken without it.
• Effort: Medium — needs: detecting a link-drag release over empty canvas (vs. over a pin), building a type-filtered candidate node list from AttributeBasedNodeFactory's registered node types compatible with the dragged pin's type, presenting it as a context menu, and wiring the created node's matching pin back into the link.

Plan

When a link drag ends with no pin under the cursor, open a context menu populated with node types whose pins are compatible with the dragged end's type (input or output, depending on which end was dragged). Selecting an entry creates that node at the drop position and completes the link to its first compatible pin.

Suggested next steps / acceptance criteria

• Confirm how "compatible types" should be determined — likely the same pin-type-compatibility check NodeEditorEngine/AttributeBasedNodeFactory already use for manual link creation, reused rather than re-implemented.
• New Coder.Graph/Coder.Editor headless test (or ImGuiAppHarness-driven test, per this repo's testing conventions) that drags a link end onto empty canvas, opens the menu, picks a node, and asserts the link completes to the new node.
• Decide UX for "no compatible node type exists" (menu shows nothing vs. an empty-state message) and for cancelling out of the menu (link should be discarded, not left dangling).

Blockers/dependencies: None identified — this is additive UI-editor work on top of the existing link-creation and node-factory machinery. Related to #36 and #35 (same context-menu affordance being added across different targets — node, pin, and now empty canvas); worth keeping the three consistent in interaction style if implemented close together.

---

Generated by Claude Code