[feature]: Support segmented/multiple date ranges for interrupted work items

Is there an existing issue for this?

• I have searched the existing issues

Summary

Problem

Plane currently supports only a single continuous date range (one start date + one end/target date) per work item. This breaks down when a task is paused mid-flight and resumed later, which is a very common pattern on teams that enforce a "one task in progress at a time" rule.

Real-world scenario

1. May 15 — I start Task A (low priority, ~1 week of work). Status: In Progress.
2. May 17 — Task B comes in (high priority, urgent). Team policy: only one task can be In Progress at a time.
3. Team lead freezes Task A and moves Task B to In Progress with dates May 17 – May 20.
4. May 20 — Task B is done. I resume Task A.

Now I'm stuck choosing between two bad options for Task A's dates:

• Keep May 15 – May 20: It looks like Task A was worked on continuously, hiding the 3-day pause. Time tracking, burndown, and analytics are wrong.
• Change to May 20 – May 25: I lose the fact that work actually started on May 15. Historical context and "time since started" are gone.

There is no way to express "worked May 15–17, paused, resumed May 20" in the current data model. Sub-tasks technically work but split a single piece of work into multiple items, which distorts reporting and breaks the "one task" abstraction.

Proposed solution

Allow a work item to hold multiple date segments instead of a single start_date / target_date pair. Each segment represents a contiguous period of active work.

Example data shape:

"date_segments": [
  { "start": "2026-05-15", "end": "2026-05-17", "reason": "paused for higher priority task" },
  { "start": "2026-05-20", "end": "2026-05-25", "reason": null }
]

UX expectations

• When a user moves a task out of "In Progress" while it has an open segment, close that segment automatically with today's date.
• When a user moves it back to "In Progress", open a new segment starting today.
• The Timeline / Gantt view renders the task as multiple bars on the same row, with visible gaps for paused periods.
• Burndown, cycle reports, and analytics use the sum of segment durations, not target_date − start_date.
• The work item header shows the first segment's start as "Started" and the last segment's end as "Target", with a small indicator (e.g., "paused 1×") when more than one segment exists.

Backwards compatibility

A single-segment task is identical to today's behavior (one start_date, one target_date), so existing data and integrations don't need to change. Multi-segment is opt-in — it only happens when a task is actually paused and resumed.

Why not just use sub-tasks or comments?

• Sub-tasks turn one piece of work into many work items. Assignee, priority, and labels get duplicated; reporting double-counts.
• Comments / activity log capture the history textually but don't feed analytics, Timeline, or cycle progress.
• Cycles are team-level, not task-level. A single task that spans a pause inside one cycle still has the same problem.

Related issues

• #5938 — Start/End time for issues (different scope: time-of-day, not segmentation)
• #6660 — Cycle date update bug (related to date handling but not feature gap)
• #6623 — Automated time tracking with timer (complementary; segments would be the natural data backbone for pause/resume on the timer too)

Use cases this unlocks

• Teams enforcing a "one task in progress" WIP limit (Kanban-style).
• Long-running tasks that get blocked by dependencies and resumed later.
• Accurate time-on-task reporting for client billing.
• Honest burndown charts that reflect actual work periods, not calendar gaps.

Happy to provide more detail or mock up the Timeline view if it helps.

Why should this be worked on?

Teams that enforce a "one task in progress at a time" WIP limit have no clean way to handle interruptions. When a high-priority task forces an in-progress task to be paused and resumed days later, the current single-range date model forces a bad trade-off: either keep the original start date (hiding the pause and breaking time tracking, burndown, and analytics) or shift the start date forward (losing the fact that work actually began earlier). Sub-tasks fragment one piece of work into many items and distort reporting, and comments/activity logs aren't picked up by Timeline or cycle progress. Supporting multiple date segments per work item solves this without breaking existing single-range data, and gives accurate reporting for any team whose work gets interrupted — Kanban WIP-limited teams, blocked-then-unblocked tasks, and client-billable time on task.