Settings canvas draws a skipped workflow node as Queued, while the Room calls it Skipped #1789

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: a8dca9983ffc4a819d39ce810668fd91
Branch: dev/1-workflow-skipped-chip
Base: 92a4cf2
At: 2026-10-30T05:14:47Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What a person sees

After a run through a workflow with a conditional branch, the branch that was not taken is drawn in Settings → Workflows with a Queued chip — as if it were still waiting — while the same run in the Room's Flow panel labels that same node Skipped. A person reading the Settings canvas concludes the run is stuck.

Where (main 92a4cf262cb8f2469f800f12e5cfe006abb4d538)

• core/src/client/workflows.js:103-109 statusLabel() knows running/done/failed/idle and falls back to 'Queued' for anything else; :264 draws every card's chip with it, and :156 takes the state from graph.run?.nodeStatus.
• The engine does write skipped: plugins/workflow/src/graph.js:7 (STATUSES) and :641 (status[node.id] = 'skipped' when an untaken edge closes).
• The Room panel already maps it: plugins/workflow/client.js:242 (STATUS_KEY has skipped: 'Skipped'), used at :1313.

Reproduction

1. Settings → Workflows, open a definition with a conditional branch.
2. Run it so one branch's condition is false.
3. Open that run's graph: the untaken node shows Queued; expected Skipped, the word the Room already uses.

Expected

The Settings canvas and the Room panel name the same node state with the same word; a node the run will never visit is never drawn as queued.

Scope

One branch in statusLabel() (skipped → the same word the Room uses, plus the i18n key), one case in core/test/workflows-page.test.js feeding graph.run.nodeStatus = { a: 'skipped' } and asserting the chip text, one changelog.d/ fragment. Under 10 lines of source. This file is on the client bundle path (0008), so the PR needs build + generate; it must not be opened while another 0008 PR is in flight.

Dedupe (searched 2026-10-30, open + closed)

• "Skipped" "Queued" workflow → 11 hits, none about this chip.
• skipped nodeStatus → 6 hits, none this.
• Nearest closed issue is fix(workflow): the Settings canvas draws every node as Idle, even mid-run #1448 "Settings canvas draws every node as Idle" — a different label bug in the same canvas, already fixed.

Red first, run on main 92a4cf26 (2026-10-30)

A copy of core/test/workflows-page.test.js with one added case — render with run: { status: 'done', nodeStatus: { planner: 'skipped', coder: 'done' } } and read the bt-wf-chip texts:

not ok 15 - QA probe: a skipped node is labelled Skipped in the Settings graph
  + actual - expected
  + [ [ 'Queued' ], [ 'Done' ] ]
  - [ 'Skipped', 'Done' ]
# tests 15 / # pass 14 / # fail 1

The second card reads Done, so the run's node state is read correctly — the miss is only in statusLabel()'s fallback, exactly as described above.