Adds a distinct "Reviewing" status badge that surfaces on TaskCard and ListView rows while a task's optional plan-review workflow step is actively running, reusing the unified progress predicate so board and list surfaces stay in sync.
- Add isPlanReviewRunning(task) helper in taskProgress.ts, derived from getUnifiedTaskProgress's workflow-plan-review item status
- Render a pulsing "Reviewing" badge on TaskCard header (additive to existing status badges, with title/data-testid) while plan-review is running
- Render the matching "Reviewing" badge on both grouped and ungrouped ListView row layouts for parity with TaskCard
- Add supporting CSS for .card-status-badge--reviewing and .list-status-badge--reviewing
- Add unit tests for isPlanReviewRunning and component tests for the new badge across TaskCard and ListView
- Add minor changeset documenting the new operator-facing badge
Files changed:
.changeset/tidy-reviewing-badges.md | 7 ++
packages/dashboard/app/components/ListView.css | 10 +++
packages/dashboard/app/components/ListView.tsx | 22 +++++-
packages/dashboard/app/components/TaskCard.css | 10 +++
packages/dashboard/app/components/TaskCard.tsx | 25 ++++++-
.../app/components/__tests__/ListView.test.tsx | 78 ++++++++++++++++++++++
.../app/components/__tests__/TaskCard.test.tsx | 31 +++++++++
.../app/utils/__tests__/taskProgress.test.ts | 16 ++++-
packages/dashboard/app/utils/taskProgress.ts | 10 +++
9 files changed, 205 insertions(+), 4 deletions(-)
Fusion-Task-Id: FN-7831
Fusion-Task-Lineage: d36f8c63-9b84-400a-8b10-3b9f3b04212b
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
Record skill-backed workflow nodes into workflowStepResults and teach task progress surfaces to include those graph-node records without re-showing disabled optional workflow checks.
An enabled-but-not-yet-run workflow step has no recorded result, so the progress bar
previously showed the raw graph node id (e.g. 'code-review'). Humanize the id fallback to
Title Case ('Code Review', 'Browser Verification', 'Frontend UX Design'). Once the step
runs, the graph-recorded config.name still wins; humanization is only the pre-run fallback.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- workflow-graph-executor: wrap each post-merge walk() in try/catch so a malformed
post-merge IR / traversal error is logged and skipped, never flipping an already-
merged task to failed (non-blocking post-merge contract) [T9, real bug].
- Refresh stale FNXC comments now that graphNativePostMerge is default-ON and the
legacy merger post-merge path was removed (experimental-features, workflow-graph-
executor, workflow-graph-post-merge.test) [T6/T7/T8].
- Normalize FNXC timestamps to yyyy-MM-dd-hh:mm (TaskCard.test, taskProgress.test) [T2/T3].
- Changeset: category fix → feature to match the minor bump [T0].
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
getUnifiedTaskProgress reads task.workflowStepResults (graph-written in U2) and
no longer needs workflowStepNameLookup — names come from result.workflowStepName.
Removed the lookup prop + fetchWorkflowSteps-name plumbing end-to-end (App,
MainContent, RightDock, Board, Column, Lane, WorktreeGroup, TaskCard). Added the
running state (pending + startedAt) and a distinct advisory_failure (amber, non-
blocking) vs failed (red) treatment; advisory_failure counts as complete.
Plan U3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
