Plugin dashboard views have no per-task lane traits, so plugin-rendered cards read the legacy vocabulary

[gsxdsm]

Surfaced by #3002, which widened check-inert-flag-seams to scan plugins/.

What

plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx:72 calls:

const isStuck = isTaskStuck(task, taskStuckTimeoutMs, lastFetchTimeMs);

Six of the seven other isTaskStuck call sites in the tree pass resolved column flags as the fourth argument. This one can't: the plugin has no lane-trait source anywhere.

• DependencyGraph receives tasks: Task[] and nothing else;
• the view is mounted through PluginDashboardViewContext, which carries no per-task traits;
• TaskCardBridgeProps doesn't include them either.

So on a board with renamed lanes, stuck detection in the dependency-graph view falls back to the legacy ids and answers for a vocabulary the operator isn't using. Same class as the fan-out and ticker defects (#2993, #2996, #2997, #3001), one boundary out.

Why it wasn't just fixed in #3002

Passing the argument from what's currently in scope would pass undefined — an unsupplied optional parameter. That's the first failure shape in docs/solutions/workflow-learnings/lifecycle-conversions-that-score-as-wins.md: strictly worse than the literal it replaces, because it reads as converted, satisfies every instrument, and answers legacy forever. It's recorded as a bounded exemption in the gate with that reasoning rather than bodged.

What the fix needs

A decision from whoever owns the plugin view contract, because it changes a published surface:

1. extend PluginDashboardViewContext (or TaskCardBridgeProps) with a per-task flags accessor — the host already builds one for the footer, footerColumnFlagsByTaskId in App.tsx:552;
2. thread it through registerBundledPluginViews → DependencyGraph → GraphTaskNode;
3. drop the exemption in scripts/check-inert-flag-seams.mjs — it's count-bounded, so it fails the moment the site is fixed and left behind.

Per-task, not a board-wide union. blocker-fanout.ts documents why: a column id means something only relative to its own workflow, and a union serves one workflow's traits to another's card.

Scope check

The dependency-graph plugin is the only current instance — the glasses plugin references lane flags in src/cards.ts and src/routes/board-routes.ts but resolves them server-side, so it isn't affected. This is one site today and a contract gap that any future card-rendering plugin inherits.

[neggmmm]

Hello, can i fix this ?

[gsxdsm]

Correcting the rationale in this issue: I claimed supply needs a published-API change. That is wrong — PluginDashboardViewContext lives in packages/dashboard/app/plugins/types.ts (private) and @fusion/plugin-sdk is private: true. Every consumer is in-repo.

The real obstacle, found by building the whole chain and watching it fail: the plugin compiles against different dashboard type declarations than the dashboard source. Adding the field and consuming it produces three errors from the plugin's side —

dashboard-view.tsx  Property 'columnFlagsByTaskId' does not exist on type 'PluginDashboardViewContext'
GraphTaskNode.tsx   Property 'taskColumnFlags' does not exist on TaskCardBridgeProps
GraphTaskNode.tsx   isTaskStuck: Expected 1-3 arguments, but got 4

— i.e. the plugin sees a stale @fusion/dashboard surface. So this is build/type plumbing, not an API-design decision, and it is smaller than I first said. Whoever knows how plugin type resolution is wired here can likely land it quickly.

Related: the host-side half is fixed in the PR above — plugin-rendered cards now receive their traits through renderTaskCard, which covers every plugin view that draws cards that way. This issue is now only about the dependency-graph view's own isTaskStuck call.