enhancement(workflow): a run's node card should show the tools and connectors that actually took effect, not the configured list #1439

Written-by: FlyBot Product

Owner approved this request. plugins/workflow/** belongs to the workflow module, not to us, so this is a requirement handed to that module: we do not implement it and will not open a PR for it.

What

A run's chat should show, per node card, the tools and connectors that actually took effect for that node's run Bot at run time — not the list copied from the node config.

• Effective grants, e.g. github · workspace-write, plus the connectors the run Bot could actually use.
• Configured but refused: rendered as configured-but-not-in-effect, visually distinct from "never configured", with the reason (e.g. composio not granted to this run).
• Display only. No change to the authorization logic, to where presets come from, or to any config key.

Why (one line)

Once a run Bot is denied the team-tool writes a node never asked for (the deny change our side is raising separately), a node whose table lists message_bot is in a denied state; the owner has to see that in the UI instead of reading logs or the stepTools record.

Where

• plugins/workflow/client.js:227 renders the node bubble as h('div', { className: 'wf-bub' }, message.text) — the place for one extra line plus a hover detail (style near :890).
• The configured list is plugins/workflow/src/ephemeral.js:29 (tools: cleanTools(node.tools)), while the runtime grant is the stepTools record the host writes on the run Bot (core/src/host/connector-access.js:49-53 reads it) — the two can be compared with no new storage and no new wire field.
• Tests: plugins/workflow/test/client.test.js — assert the line is absent before, rendered after, and that a configured-but-denied entry is distinguishable from an absent one.

Acceptance

1. Each node card shows the effective tools/connectors for that node's run Bot, read from the runtime record, not from the node config.
2. An entry present in config but refused at run time renders as configured-but-not-in-effect with its reason, and is distinguishable from an entry never configured.
3. No behaviour change: grants, refusals, presets and config keys are untouched, and a test pins that the rendered set equals the runtime set.