feat(sdk) Variable enhancement

[szymon-t-sc]

Workflow Builder introduced variable support some time ago, allowing sidebar controls to use variables from previous nodes or global variables.

This PR enhances the feature with the missing logic to make variable usage more robust and flexible.

Main changes

Variables provided by nodes to downstream nodes can now depend on:

• selected type in the sidebar - for example, selecting a time-based trigger returns schedule information, while selecting an event-based trigger returns information about the event type
• sourceHandle - if a node has success and error source handles, it can provide the actual node output to the success branch and the error output to the error-handling branch

Nagranie.z.ekranu.2026-08-14.o.18.32.10.mov

Node variables store:

Previously, variables from previous nodes were calculated when the control was mounted. We traversed the graph and calculated their values at the same time - now we keep nodes variables in the store and only collect them:

• The list of variables further down the flow is calculated faster, as we only collect the variables that are available
• It's now easier to check which variables are available from a node, and we can easily add a plugin to display them

New single variable control (previously used in conditions)

Nagranie.z.ekranu.2026-08-14.o.18.28.48.mov

It shows a date picker with {} when date variables are available.

Fixes

• When an edge was added or removed, we sometimes had incorrect highlighting of values in controls. This is now fixed thanks to totalVariables
• Global variables cannot be added in read-only mode

It's worth noting that the majority of the changes are encapsulated in packages/sdk/src/features/variables/. So while reviewing, we can identify what is used externally as a useful public API and note the core functions that could be valuable to expose.

[szymon-t-sc]

While the current format of suggestions is simple, its simplicity is limiting. For example, if we used a schema format similar to the node schema, with nesting and options, we could support much richer suggestions.

Even for simple non-object properties, such as strings, the schema can define options. We could support those here as well, allowing the condition builder to show a select with predefined options instead of an empty text field when someone picks variable received from the node in condition node later.

For object properties, returning just 'object' doesn't give us much to work with. If the object includes defined properties, we can build conditions based on those nested properties.

We should replace this format with a schema and use it similarly to how we use node schemas: to build dedicated controls for conditions and for 'set a value' nodes, allowing properties to be overridden while following the schema's types.