Dependency chain display — Design

Date: 2026-08-11 Status: approved, not implemented

Problem

DependsOnTaskId is invisible in the UI. TaskRowViewModel has no DependsOnTaskId property and TaskRowView.axaml renders nothing for it — a chained task looks exactly like an unrelated one. The execution order the user declared is not readable anywhere in the list.

Target

A chain renders as a group: the head full width, its dependents indented behind a vertical rail, each carrying a small circular step badge on the rail.

┌──────────────────────────────────────────┐
│  chain head (full width, no badge)       │
└──────────────────────────────────────────┘
  ╷ ┌────────────────────────────────────┐
 (1)│  first dependent                   │
  ╷ └────────────────────────────────────┘
  ╷ ┌────────────────────────────────────┐
 (2)│  second                            │
  ╷ └────────────────────────────────────┘
  ╷ ┌────────────────────────────────────┐
 (2)│  parallel to the second            │
  ╷ └────────────────────────────────────┘
  ╷ ┌────────────────────────────────────┐
 (3)│  third                             │
    └────────────────────────────────────┘

Model reading

Step number = hop distance from the chain head, not a running counter. DependsOnTaskId is a single FK, so several tasks may share one predecessor → same depth → same number. Two rows showing 2 means "these two are both unblocked by step 1", which is the intended reading.
Chain head = a task with no DependsOnTaskId that at least one other task points at. A task with no dependents and no dependency is not a chain and renders exactly as today.
Cycles are impossible (TaskStateService.SetDependsOnAsync rejects them), so the depth walk always terminates. Still cap the walk defensively.

Decisions

One indent level only — parent wins. The 24 px indent track already exists for planning children (TaskRowView.axaml:22-28, gated on ShowAsChild). A planning child that also has a DependsOnTaskId keeps the parent indent and shows its chain membership as a small inline chip (after #123) instead of a second indent level. No nesting, no 48 px rows.

The group is pulled together; the head carries it. Chain members are re-ordered to sit directly under their head regardless of SortOrder, so displayed order always equals execution order. Dragging the head moves the whole group; members are not individually draggable.

Head not in view → no orphan rails. Exact precedent exists: ParentInView /ShowAsChild (TaskRowViewModel.cs:75, computed in Regroup at TasksIslandViewModel.cs:543). Same treatment — if the head is filtered out (other list, My Day, completed group), the row renders flat with the after #123 chip instead of a dangling rail.

Badge has no #. If task numbers (2026-08-11-task-numbers-design.md) also land, a row would show a rail badge and a #412 title prefix. The rail badge is a step position, not an identity — render it bare (2), never #2.

Slices

#	Slice	Depends on
1	VM: `DependsOnTaskId` + depth/head computation in `Regroup`, group pull-together, drag semantics	—
2	View: rail, step badge, `after …` chip, locale keys	1

Slice 1 exposes the contract Slice 2 binds to: ShowAsChainMember, ChainStep, ChainAfterLabel.

4.1 KiB Raw Blame History