[Diagram Editor] Frontend progress visualization

[ArizmendiWan]

Adds the first frontend-visible debugging slice for the diagram editor.

It adds live operation-start visualization in the graph, exposes the existing backend debug WebSocket through the REST API client, and moves Run/Debug controls into the persistent right side panel so runtime status no longer blocks the diagram canvas.

It also adds a small delayed calculator example so the progress visualization is easy to verify manually.

Changes

• Highlight the currently executing node and retain visited nodes during debug runs.
• Move Run/Debug UI from popover into the right side panel under a Run tab.
• Add optional wsDebugWorkflow support to the frontend API client.
• Add DebugSession handling for backend operationStarted and finish messages.
• Add delay_ms to the calculator example catalog.
• Add carry_object_progress.json as a latency-focused progress demo.

Demo Video

Screen.Recording.2026-05-21.at.20.34.02.mov

GenAI Use

We follow OSRA's policy on GenAI tools

• I used a GenAI tool in this PR.
• I did not use GenAI

Generated-by: Codex

[aaronchongth]

Thanks for hammering this out! Introspection and debugging will definitely help users more quickly test workflows.

Before I go through the review more thorough, I have some high-level comments about this feature. Some background reference, #86. Just to clarify, I believe these features regarding tracing events were called/referenced as "debug" , but it is part of introspection tools and should be provided out-of-the-box, and not just in debug mode for crossflow. Especially since they provide incredible value to users while incurring very little overhead, I'd suggest that UX-wise, we have the checkbox turned on by default beside the "Run" button in the Run panel, that only toggles the visualization, while all the tracing events are still provided. Let me know what you think or if I had the wrong understanding of this implementation.

I was able to follow the readme and run the example, but it would be cool to also include screen recordings of the new features and how to interact with them on PRs.

[ArizmendiWan]

Thanks for hammering this out! Introspection and debugging will definitely help users more quickly test workflows.

Before I go through the review more thorough, I have some high-level comments about this feature. Some background reference, #86. Just to clarify, I believe these features regarding tracing events were called/referenced as "debug" , but it is part of introspection tools and should be provided out-of-the-box, and not just in debug mode for crossflow. Especially since they provide incredible value to users while incurring very little overhead, I'd suggest that UX-wise, we have the checkbox turned on by default beside the "Run" button in the Run panel, that only toggles the visualization, while all the tracing events are still provided. Let me know what you think or if I had the wrong understanding of this implementation.

I was able to follow the readme and run the example, but it would be cool to also include screen recordings of the new features and how to interact with them on PRs.

I think you’re right about introspection. Progress visualization is broadly useful for monitoring workflows and intuitive understanding of execution, not only for debugging.

I originally approached this from the diagram editor debugging use case, where progress visualization felt necessary to make debugging usable, which is why the current commits use that naming and flow. I agree it would be better to reposition this as a normal introspection/progress feature. I’ll update the PR in that direction.

edit: I just realized that the progress visualization is entirely built on top of debugging backend, which passes the status information of nodes. If we want to make the introspection default, we may have to make debug default too. IMO the overhead is acceptable.