Dependencies
Dependencies tell Plenar that one task cannot start until another finishes. They are the primary way you express ordering constraints in your plan.
How dependencies work
All dependencies in Plenar are finish-to-start: task B cannot start until task A is complete. This is the only dependency type Plenar supports. There are no start-to-start, finish-to-finish, or start-to-finish dependencies.
When you say “Task B depends on Task A,” Plenar guarantees that B’s scheduled start date is after A’s scheduled end date.
Dependencies are hard constraints. Plenar will never produce a schedule that violates one, regardless of deadlines or priorities.
Adding dependencies
From the dashboard
- Open a task in the Scope Table
- Click the dependency count (or the dependency field in the detail panel)
- Search for the predecessor task and add it
From Claude Code
"The webhook handler depends on the API middleware task"Or for multiple dependencies at once:
"Add dependencies: integration tests depends on both the
OAuth flow and the session storage tasks"Claude calls plenar_add_dependency or plenar_bulk_add_dependencies as needed. The preview shows how the dependency change affects the schedule.
Removing dependencies
From the dashboard
Open the task, click the dependency count, and remove the predecessor.
From Claude Code
"Remove the dependency between auth and logging"Removing a dependency frees tasks to be scheduled earlier. The preview shows whether anything moves.
Scope rules
Must-have tasks cannot depend on nice-to-have tasks. Nice-to-have items might not be scheduled if capacity is tight, so they must never block required work. Plenar enforces this rule — you cannot create a dependency where a Must task depends on a Nice task.
The reverse is fine: nice-to-have tasks can depend on must-have tasks.
Circular dependencies
If Task A depends on Task B, and Task B depends on Task A (directly or through a chain), the schedule is infeasible — no valid ordering exists. Plenar detects cycles and reports an error.
To fix a circular dependency, identify which relationship is unnecessary and remove it.
Cascading effects
Dependencies create chains. When one task in a chain moves, everything downstream shifts:
Task A (3d) -> Task B (2d) -> Task C (1d)If Task A’s estimate increases from 3 to 5 days, Task B starts 2 days later, and Task C starts 2 days later. The preview shows the full cascade so you can assess the impact before committing.
Critical path
The critical path is the longest chain of dependent tasks from the project start to the last task’s end. Tasks on the critical path have zero slack — any delay directly delays the project.
Tasks not on the critical path have slack: they can slip by some number of days without affecting the project end date. The amount of slack depends on how far off the critical path they are.
Best practices
Only add genuine dependencies. Each dependency constrains what schedules are possible. If Task B can start before Task A finishes (even if it is slightly inconvenient), do not add the dependency. Unnecessary dependencies make the schedule longer than it needs to be.
Keep chains short. Long dependency chains (A -> B -> C -> D -> E -> F) create rigid schedules with no slack. If some tasks in the chain can run in parallel, structure them that way.
Use milestones to group, not dependencies to sequence. If you want tasks to be done “roughly in order” but they are not strictly dependent, put them in separate milestones with appropriate ordering. Save dependencies for genuine technical prerequisites.
Watch for hidden dependencies. If two tasks modify the same system and would conflict if run simultaneously, they need a dependency even though neither is technically a prerequisite for the other. Without it, Plenar might schedule them in parallel (if assigned to different people).