-
Notifications
You must be signed in to change notification settings - Fork 7
UI: Distinguish resolved vs active blockers in dependency section #14
Description
Problem
When a task has a "BLOCKED BY" dependency and the blocking task is already CLOSED, the UI still renders it identically to an active (unresolved) blocker. This is confusing because it implies the task is still blocked when it is not.
The data model is correct — bd blocked already computes the right result (resolved blockers are not counted). The issue is purely presentational.
Example: Task jox.7 (IN PROGRESS) shows "BLOCKED BY jox.6", but jox.6 is CLOSED. The dashboard counter correctly shows BLOCKED: 0, yet the detail panel gives no visual distinction.
Proposed behavior
- Active blocker (open / in_progress): show as-is with current "BLOCKED BY" styling
- Resolved blocker (closed / wontdo): visually distinguish — e.g., strikethrough, greyed-out text, or a "resolved" badge
Why not handle this at the workflow level?
We considered mutating dependency types (e.g., changing blocks → deps when a task moves to IN PROGRESS), but this loses the historical semantics of the blocking relationship. The fix belongs in the presentation layer, not the data layer.
Acceptance criteria
- A "BLOCKED BY" dependency where the blocker is CLOSED renders visually distinct from one where the blocker is OPEN
- The dependency record itself is unchanged — no data mutation occurs
- The BLOCKED counter in the dashboard sidebar continues to show only actively-blocked tasks (existing behavior, no change needed)