Skip to content

UI: Distinguish resolved vs active blockers in dependency section #14

@miguelramos

Description

@miguelramos

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 blocksdeps 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

  1. A "BLOCKED BY" dependency where the blocker is CLOSED renders visually distinct from one where the blocker is OPEN
  2. The dependency record itself is unchanged — no data mutation occurs
  3. The BLOCKED counter in the dashboard sidebar continues to show only actively-blocked tasks (existing behavior, no change needed)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions