Problem or opportunity
Ban Kan is strong at executing tasks once they exist, but there is still a gap in the workflow before execution begins.
Today, users must manually:
break down a feature or idea into tasks
decide execution order
determine which tasks can run in parallel
keep track of related tasks
This becomes especially difficult when:
multiple tasks belong to the same feature or “spec”
tasks depend on each other
tasks target the same repository
Because each agent runs in an isolated workspace, agents cannot see each other’s unmerged work. This creates a realistic but important limitation:
Task B may depend on Task A’s code
Task B cannot safely run until Task A is completed and integrated
Without explicit coordination, this leads to incorrect execution order or wasted work
In practice, this makes it hard to scale beyond a few coordinated tasks without introducing manual overhead.
This is an opportunity to move Ban Kan from a task execution tool to an idea → execution system.
Proposed solution
Introduce a Build from Spec workflow that:
1. Generates a backlog from a spec
Allow users to input a high-level spec (e.g. “Build SaaS billing with Stripe”), and generate:
- a set of tasks
- suggested execution order
- dependency relationships
- repo assignment per task
Each task is linked to a specId.
2. Add task dependencies and blocking
Introduce:
dependsOnTaskIds[]blocksTaskIds[]- a new
Blocked state
Behavior:
- Tasks with unmet dependencies are marked as
Blocked
- Tasks automatically unblock when dependencies are satisfied
- Only unblocked tasks can move into Planning/Implementation
3. Respect isolated workspaces (same-repo handling)
Because agents run in separate workspaces:
- Same-repo dependent tasks must not execute in parallel if they rely on each other’s code
- A dependency is only satisfied when:
- the prerequisite task is Done
- and its changes are integrated into the repo baseline
When a blocked task becomes unblocked:
- its workspace should be created from the latest integrated repo state
4. Visual spec grouping
Tasks generated from the same spec should be visibly related.
Add to task cards:
- spec badge (e.g.
Billing)
- blocked indicator
- dependency count
- related task count
In task details:
- show related tasks
- show dependency graph or list
- show blocked and unblocked relationships
Optional:
- highlight related tasks on hover
- show spec-level progress
5. Execution model
- Independent tasks run in parallel
- Dependent tasks remain blocked
- When prerequisites complete and are integrated, blocked tasks are reevaluated
- Newly eligible tasks move into execution
Alternatives considered
1. No dependency system (manual coordination)
Users manually manage execution order.
Rejected because:
- does not scale beyond a few tasks
- leads to incorrect execution order
- contradicts Ban Kan’s goal of reducing chaos
2. Allow dependent tasks to run in parallel
Let agents run even if dependencies are unmet.
Rejected because:
- agents cannot see each other’s unmerged work
- leads to incorrect implementations
- increases rework and failed reviews
3. Share workspaces between agents
Allow agents to access each other’s in-progress changes.
Rejected because:
- breaks isolation model
- introduces race conditions
- deviates from real-world workflows
4. Dependency satisfied at “review passed”
Unblock tasks as soon as review succeeds.
Rejected because:
- code may not yet be integrated
- dependent tasks would still not see required changes
Additional context
This feature is a key step toward making Ban Kan an end-to-end AI development system.
It enables:
- spec-driven development
- safe coordination of multiple agents
- realistic team-like workflows
- scaling across many tasks and repos
It also aligns with Agile workflows:
- spec ≈ epic
- tasks ≈ stories
- dependencies ≈ ordering
A good first iteration should focus on:
- spec creation
- task generation
- basic dependency model (finish-to-start)
- blocked and unblocked state
- simple visual grouping
More advanced orchestration can be added later.
Problem or opportunity
Ban Kan is strong at executing tasks once they exist, but there is still a gap in the workflow before execution begins.
Today, users must manually:
break down a feature or idea into tasks
decide execution order
determine which tasks can run in parallel
keep track of related tasks
This becomes especially difficult when:
multiple tasks belong to the same feature or “spec”
tasks depend on each other
tasks target the same repository
Because each agent runs in an isolated workspace, agents cannot see each other’s unmerged work. This creates a realistic but important limitation:
Task B may depend on Task A’s code
Task B cannot safely run until Task A is completed and integrated
Without explicit coordination, this leads to incorrect execution order or wasted work
In practice, this makes it hard to scale beyond a few coordinated tasks without introducing manual overhead.
This is an opportunity to move Ban Kan from a task execution tool to an idea → execution system.
Proposed solution
Introduce a Build from Spec workflow that:
1. Generates a backlog from a spec
Allow users to input a high-level spec (e.g. “Build SaaS billing with Stripe”), and generate:
Each task is linked to a
specId.2. Add task dependencies and blocking
Introduce:
dependsOnTaskIds[]blocksTaskIds[]BlockedstateBehavior:
Blocked3. Respect isolated workspaces (same-repo handling)
Because agents run in separate workspaces:
When a blocked task becomes unblocked:
4. Visual spec grouping
Tasks generated from the same spec should be visibly related.
Add to task cards:
Billing)In task details:
Optional:
5. Execution model
Alternatives considered
1. No dependency system (manual coordination)
Users manually manage execution order.
Rejected because:
2. Allow dependent tasks to run in parallel
Let agents run even if dependencies are unmet.
Rejected because:
3. Share workspaces between agents
Allow agents to access each other’s in-progress changes.
Rejected because:
4. Dependency satisfied at “review passed”
Unblock tasks as soon as review succeeds.
Rejected because:
Additional context
This feature is a key step toward making Ban Kan an end-to-end AI development system.
It enables:
It also aligns with Agile workflows:
A good first iteration should focus on:
More advanced orchestration can be added later.