fix(workflow): the Settings canvas draws every node as Idle, even mid-run #1448

Written-by: FlyBot Product

What happens

Open Settings → Workflow graphs for a workflow that has a live run, while the run is in progress. Every node on the canvas still reads Idle; nothing shows that the workflow is running, which node is in flight, or which ones are already done. The same graph in the sidebar drawer shows the real state, so the two surfaces disagree about the same run.

Reproduced with the plugin's own render harness (plugins/workflow/test/client.test.js runs 7 tests, all passing — none of them checks run status in Settings). Mounting WorkflowSettings with a workflow whose run.nodeStatus.coder is running gives six Idle chips:

PROBE A chips: ["Idle","Idle","Idle","Idle","Idle","Idle"]
PROBE A run.nodeStatus.coder = running
assertion "at least one Running chip" fails

Root cause

• plugins/workflow/client.js:791 — the Settings canvas passes h(FlowNode, { node, status: 'idle', roster: {} }). The per-node chip and the node Mark are hardcoded to idle and to an empty roster, so no run state can reach this surface.
• The drawer in the same file already does it correctly: :444 h(FlowNode, { node, status: status[node.id] ?? 'queued', roster }), with const status = run?.nodeStatus ?? {} at :352 and const run = workflow.run at :308 (the stage reads the same at :226).
• The data is already in the Settings payload: workflow/state gives every workflow run: publicRun(item, primaryRun(item.id)) (plugins/workflow/src/service.js:183), and WorkflowSettings already hands workflow: current to GraphCanvas (client.js:650-656). GraphCanvas (:730) simply never reads workflow.run.

Expected

The Settings canvas draws the same status as the drawer: the per-node chip comes from run.nodeStatus[node.id] (falling back to queued when the workflow has no run), the node highlight and the Mark resolve against the same run and the real roster instead of {}.

Acceptance (deterministic)

A test in plugins/workflow/test/client.test.js, same harness:

• mounts WorkflowSettings with run.nodeStatus = { planner: 'done', writer: 'done', coder: 'running', reviewer: 'queued', tester: 'queued', deployer: 'queued' } → the coder chip reads Running, the planner chip reads Done, and no chip reads Idle;
• mounts the same workflow with no run → chips fall back to Idle/queued.

The current code fails the first case.

Scope

S: one prop pass-through in WorkflowSettings (client.js:650-656) and GraphCanvas (:730, :791). No host change, no new endpoint, no storage change.

Reachability

The running instance is checkout e37f1f8, which predates the Workflows surface. This defect is not yet visible to users; it arrives with the next milestone update.

Ownership

plugins/workflow/** belongs to the workflow module. FlyBot reports this and does not implement it or open a PR for it.

Not a duplicate (as of my read)

• #1424 (open) and its fix #1431 are the opposite direction: a reaped run keeps nodeStatus: running, so the drawer's strip still says "Running now". That is a host-side reap() issue about a dead run; this one is client-side hardcoding in Settings and reproduces on a live run.
• #1438 (closed) asked for the canvas-first editor; this is a defect in what it shipped.
• #1393 (closed) made a node's system prompt editable in Settings.
• #1446 (open) is duplicate workflow names; #1441 (open) is deleting a workflow during a run; #1439 (open) is a run card showing its tools. None of them touches the Settings canvas status.
• Search workflow canvas status idle → 0 results; inspector node workflow → only #1438.