Subtasks, splits and dependencies¶

Three ways to give a task shape: break it into subtasks, split it into equal parts, and declare what has to happen before it.

Subtasks¶

The Subtasks tab of the task detail panel breaks a task down. Type a title and press Enter to add one. Each subtask has its own properties (status, estimate, dates, and the rest) and opens in its own panel.

Two rules matter, because the planner leans on them:

• A parent's estimate is the sum of its subtasks. As soon as a task has children, its estimate stops being editable and reads "(sum of subtasks)". To change it, change a subtask's estimate.
• The planner schedules the leaves, never the parent. A task with subtasks is skipped and its subtasks are scheduled instead. If both were scheduled the same work would be booked twice. The same is true of one-click reserving: Auto-plan is not available on a task with subtasks, you reserve each subtask instead.

A subtask's due date may not be later than its parent's. Empi refuses the change and offers to extend the parent to that date instead.

Splitting a task¶

Split turns one sized task into several equal parts. Open it from the task panel (or from the bulk action bar in the List and Kanban views), choose a slot duration, and Empi divides the estimate into subtasks of that length. The last part absorbs the remainder.

• The task needs an estimate first. Without one there is nothing to divide.
• A split produces between 2 and 20 subtasks. Durations that would produce fewer than 2 parts are not offered.
• Splitting a subtask turns it into part 1 and adds the rest as siblings.

Splitting is a way to work in bite-sized chunks and to give each part its own status. It does not create capacity: the total estimate is unchanged, and the planner already spreads a task that is too big for one day across consecutive days on its own.

Dependencies¶

Blocked by lists what must finish before this task. Blocking is the mirror view: what is waiting on it. Both are set from the properties column, and both accept a search over your other tasks.

Dependencies are a hard constraint on the plan. The planner places a task only after everything it is blocked by, before it considers anything else about the task. Only once dependencies are satisfied does the rest of the ordering apply (overdue first, then work in progress, then the earliest due date, then priority).

A task with unfinished blockers carries a badge ("Blocked by 2 unfinished tasks"). Once they are all done, it reads "Dependencies complete, ready to schedule".

Date conflicts¶

Dependencies and dates can contradict each other. Empi detects that as you edit and shows it on the task, under Scheduling conflicts, rather than letting the planner quietly fail:

• The task starts before a dependency finishes. The blocker is due after this task's start, so the work cannot begin when you asked.
• A blocker is due after the dependent task. No amount of scheduling can fix this: the thing you are waiting for is due later than the thing waiting for it.
• A blocker is due after this task's parent. The subtask can never be scheduled in time, whatever its own dates say.

A dependency cycle (A waits on B, B waits on A) is reported by the planner the same way, as a dependency conflict.

Each conflict comes with the actions that actually resolve it:

• Remove dependency on the blocking task.
• Open blocker, to go and fix its dates instead.
• Reschedule to , which moves this task to the earliest date that works.
• Keep the original dates, if you made the change by accident.

Rescheduling can free reserved slots that no longer fit the new dates. Empi tells you when it does ("Freed 2 earlier slots") so the time is visibly back in your capacity.