Problem Statement

tm list and tm next show inconsistent information about what task should be worked on next. This reveals a deeper design question about Task Master's intended workflow: single-threaded vs multi-session.

Steps to Reproduce

1. Have a project with tasks that have dependencies and subtasks
2. Mark a parent task as in-progress (e.g., task 8 with subtasks 8.1, 8.2, 8.3)
3. Have another task available with satisfied dependencies (e.g., task 6)
4. Run tm list - Shows "Next Task: N/A - No task available"
5. Run tm next - Shows "Next Task: 8.1" (subtask of in-progress task)

Current Behavior

tm list output:

Next Task to Work On:
ID: N/A - No task available
Priority: N/A  Dependencies: None
Complexity: N/A

tm next output:

Next Task: 8.1 - Analyze current EnergyPollerFunction.asyncInvoke() implementation
Priority: medium  Dependencies: None
Complexity: ● 8

Dashboard shows:

• Task 6: pending (dependencies satisfied)
• Task 8: in-progress (being worked on)
• Task 9: pending (blocked by task 8)

The Core Issue: Design Philosophy

The inconsistency reveals a fundamental design question about Task Master's workflow model.

Current Implementation (Single-threaded)

From task-service.ts:278:

/**
 * Get next available task to work on
 * Prioritizes eligible subtasks from in-progress parent tasks before falling back to top-level tasks
 */

This assumes:

• One person/session working sequentially
• "Next" means "continue what you started"
• Subtasks are work items that should be suggested

Real-World Usage (Multi-session/Kanban)

Many users run multiple Claude Code sessions simultaneously:

• Session A: Working on task 8 → manages subtasks 8.1, 8.2, 8.3 internally
• Session B: Looking for work → should see task 6 is available
• Subtasks are implementation details, not board-level work items

Kanban Mental Model

TODO          | DOING              | DONE
--------------|--------------------|-------------
Task 6        | Task 8             | Task 1
Task 9        |   (8.1, 8.2, 8.3)  | Task 2
              |                    | Task 3

Question: What should tm next return?

• A: Subtask 8.1 (current behavior - helps finish started work)
• B: Task 6 (Kanban model - pull next item from TODO)

The Inconsistency Problem

Regardless of philosophy chosen, tm list and tm next must agree:

Current:

• tm list: "No task available"
• tm next: "Task 8.1 available"
• Result: Inconsistent ❌

Should be:

• Both say "Task 8.1" (subtask-first philosophy), OR
• Both say "Task 6" (top-level-only philosophy)
• Result: Consistent ✅

Impact

This affects:

1. Multi-session workflows - Multiple Claude Code sessions or developers working simultaneously
2. Trust in the system - Contradictory information causes confusion
3. Parallel work - Missed opportunities to work on task 6 while task 8 is in-progress

Technical Context

The issue is in packages/tm-core/src/services/task-service.ts:getNextTask():

Phase 1 logic (lines 315-370) - Prioritizes subtasks from in-progress parent tasks
Phase 2 logic (lines 372-396) - Falls back to top-level tasks only if Phase 1 finds nothing

The tm list command's dashboard appears to use different logic or only considers top-level tasks.

Proposed Solutions

Solution 1: Make Commands Consistent (Minimum Fix)

Whatever the philosophy, make tm list and tm next show the same information.

Solution 2: Support Both Workflows via Configuration

# In .taskmaster/config.json
{
  "workflow": "single-session" | "multi-session"
}

Single-session mode:

• tm next returns subtasks from in-progress tasks first
• Helps finish what you started

Multi-session mode:

• tm next returns top-level tasks only
• Subtasks are internal implementation details
• Better for parallel work

Solution 3: Provide Different Commands

tm next              # Current task's next subtask (if applicable)
tm next --available  # Next top-level task (ignore in-progress)
tm next --all        # Show all available work (both subtasks and tasks)

Solution 4: Better State Management

When marking task 8 as in-progress, automatically mark first subtask (8.1) as in-progress too:

• Accurately represents that 8.1 is being worked on
• Other sessions know to skip it
• Makes "next" logic clearer (skip in-progress items)

Discussion Questions

1. What is the intended workflow model? Single-session or multi-session?
2. What are subtasks? Board-level work items or implementation details?
3. What does "next" mean? Continue current work or pull from backlog?
4. Should we support both workflows? Via config, flags, or separate commands?

Real-World Use Case

User workflow:

1. Multiple Claude Code sessions in different git worktrees
2. Each session works on different tasks simultaneously
3. Session A marks task 8 as in-progress and works on its subtasks
4. Session B runs tm list → sees "No task available"
5. Session B runs tm next → sees "Work on subtask 8.1"
6. But Session A is already working on task 8 and managing its subtasks

Expected: Session B should see task 6 as available for parallel work.

Environment

• Task Master version: Latest
• Usage pattern: Multi-session development with git worktrees
• Multiple Claude Code sessions working on same project simultaneously
• Real-world production usage at scale