Add collapsible structural groups to workflow routes #18

New issue

Open

opened 2026-09-16 12:23:56 +02:00 by morten-olsen · 0 comments

morten-olsen commented

2026-09-16 12:23:56 +02:00

Owner

Context

Complex workflows need a way to reduce visual noise without changing what they execute. The editor is a vertically ordered route with branch lanes, so the appropriate abstraction is a structural group that contains a consecutive section of a route and can collapse to a concise summary—not a second graph or executable control-flow node.

Scope

Add a named Group node/container that owns child nodes solely for editor organization.
A group is execution-transparent: it introduces no action, trigger, port, input, output, scheduling, scope, or runtime value. The compiler/execution engine must see the same effective node order and connections as it would if the group were absent.
Allow users to create a group around a valid contiguous section of one route or branch lane, name/rename it, add nodes within it through the existing insertion affordances, and move its contained nodes back into the parent route by ungrouping.
Render an expanded group as a clearly bounded section of the existing vertical route. Its children retain their normal route/branch presentation and editing controls.
Let users collapse and expand a group. A collapsed group displays its name, contained-node count, and meaningful summary/diagnostic state while hiding children; it must remain obvious that the route continues through the group.
Persist group structure and collapsed presentation state with the workflow draft so reopening the editor restores the user’s organization. Persisted collapse state must never affect execution or headless/authoring-tool representations of workflow semantics.
Preserve graph validity and reference behavior across grouping, ungrouping, reordering, copy/cut/paste, and saving. Grouping must not create dangling connections, alter node IDs, change branch ordering, or change the visibility/availability of output references.
Keep the group model and validation shared between the app editor and external authoring surfaces, but permit non-UI consumers to treat groups as structural metadata.

Non-goals

Do not make groups executable scopes, error handlers, loops, transaction boundaries, variable scopes, or secret-assignment boundaries.
Do not add free-form canvas containers or arbitrary node coordinates.
Do not support a group spanning multiple unrelated routes/branch lanes, or nested groups, in this issue.
Do not change workflow behavior, execution history, or debugging semantics merely because nodes have been grouped.

Acceptance

A user can group a contiguous valid route/branch section, name it, save the workflow, reopen it, and observe the same group and expansion state.
Collapsing a group hides its children and presents an identifiable summary; expanding it restores normal child editing without losing draft changes.
Running an otherwise identical grouped and ungrouped workflow produces the same execution order, outputs, connections, and outcomes.
Grouping and ungrouping preserve existing node identities and references, and ungrouping returns children to the parent route at the group’s position.
The editor blocks or explains attempts to group a non-contiguous/cross-lane selection or perform a group operation that would violate graph validity.
Existing route operations, including add, remove, drag reorder, copy/cut/paste, branch protection, validation, and headless authoring, continue to work without bypassing graph invariants.
Focused tests cover structural persistence, collapse-state persistence, execution transparency, reference preservation, ungroup behavior, and invalid grouping attempts.

## Context Complex workflows need a way to reduce visual noise without changing what they execute. The editor is a vertically ordered route with branch lanes, so the appropriate abstraction is a structural group that contains a consecutive section of a route and can collapse to a concise summary—not a second graph or executable control-flow node. ## Scope - Add a named **Group** node/container that owns child nodes solely for editor organization. - A group is execution-transparent: it introduces no action, trigger, port, input, output, scheduling, scope, or runtime value. The compiler/execution engine must see the same effective node order and connections as it would if the group were absent. - Allow users to create a group around a valid contiguous section of one route or branch lane, name/rename it, add nodes within it through the existing insertion affordances, and move its contained nodes back into the parent route by ungrouping. - Render an expanded group as a clearly bounded section of the existing vertical route. Its children retain their normal route/branch presentation and editing controls. - Let users collapse and expand a group. A collapsed group displays its name, contained-node count, and meaningful summary/diagnostic state while hiding children; it must remain obvious that the route continues through the group. - Persist group structure and collapsed presentation state with the workflow draft so reopening the editor restores the user’s organization. Persisted collapse state must never affect execution or headless/authoring-tool representations of workflow semantics. - Preserve graph validity and reference behavior across grouping, ungrouping, reordering, copy/cut/paste, and saving. Grouping must not create dangling connections, alter node IDs, change branch ordering, or change the visibility/availability of output references. - Keep the group model and validation shared between the app editor and external authoring surfaces, but permit non-UI consumers to treat groups as structural metadata. ## Non-goals - Do not make groups executable scopes, error handlers, loops, transaction boundaries, variable scopes, or secret-assignment boundaries. - Do not add free-form canvas containers or arbitrary node coordinates. - Do not support a group spanning multiple unrelated routes/branch lanes, or nested groups, in this issue. - Do not change workflow behavior, execution history, or debugging semantics merely because nodes have been grouped. ## Acceptance - A user can group a contiguous valid route/branch section, name it, save the workflow, reopen it, and observe the same group and expansion state. - Collapsing a group hides its children and presents an identifiable summary; expanding it restores normal child editing without losing draft changes. - Running an otherwise identical grouped and ungrouped workflow produces the same execution order, outputs, connections, and outcomes. - Grouping and ungrouping preserve existing node identities and references, and ungrouping returns children to the parent route at the group’s position. - The editor blocks or explains attempts to group a non-contiguous/cross-lane selection or perform a group operation that would violate graph validity. - Existing route operations, including add, remove, drag reorder, copy/cut/paste, branch protection, validation, and headless authoring, continue to work without bypassing graph invariants. - Focused tests cover structural persistence, collapse-state persistence, execution transparency, reference preservation, ungroup behavior, and invalid grouping attempts.

morten-olsen added the

feature

label

2026-09-17 08:19:57 +02:00