ros/claude-task-master
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: implement Phase 0 TDD autopilot dry-run foundation

Browse Source 
Implements the complete Phase 0 spike for autonomous TDD workflow with orchestration architecture.

## What's New

### Core Services (tm-core)
- **PreflightChecker**: Validates environment prerequisites
  - Test command detection from package.json
  - Git working tree status validation
  - Required tools availability (git, gh, node, npm)
  - Default branch detection

- **TaskLoaderService**: Comprehensive task validation
  - Task existence and structure validation
  - Subtask dependency analysis with circular detection
  - Execution order calculation via topological sort
  - Helpful expansion suggestions for unready tasks

### CLI Command
- **autopilot command**: `tm autopilot <taskId> --dry-run`
  - Displays complete execution plan without executing
  - Shows preflight check results
  - Lists subtasks in dependency order
  - Preview RED/GREEN/COMMIT phases per subtask
  - Registered in command registry

### Architecture Documentation
- **Phase 0 completion**: Marked tdd-workflow-phase-0-spike.md as complete
- **Orchestration model**: Added execution model section to main workflow doc
  - Clarifies orchestrator guides AI sessions vs direct execution
  - WorkflowOrchestrator API design (getNextWorkUnit, completeWorkUnit)
  - State machine approach for phase transitions

- **Phase 1 roadmap**: New tdd-workflow-phase-1-orchestrator.md
  - Detailed state machine specifications
  - MCP integration plan with new tool definitions
  - Implementation checklist with 6 clear steps
  - Example usage flows

## Technical Details

**Preflight Checks**:
- ✅ Test command detection
- ✅ Git working tree status
- ✅ Required tools validation
- ✅ Default branch detection

**Task Validation**:
- ✅ Task existence check
- ✅ Status validation (no completed/cancelled tasks)
- ✅ Subtask presence validation
- ✅ Dependency resolution with circular detection
- ✅ Execution order calculation

**Architecture Decision**:
Adopted orchestration model where WorkflowOrchestrator maintains state and generates work units, while Claude Code (via MCP) executes the actual work. This provides:
- Clean separation of concerns
- Human-in-the-loop capability
- Simpler implementation (no AI integration in orchestrator)
- Flexible executor support

## Out of Scope (Phase 0)
- Actual test generation
- Actual code implementation
- Git operations (commits, branches, PR)
- Test execution
→ All deferred to Phase 1

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Ralph Khreish
2025-10-07 18:43:33 +02:00
parent ad9355f97a
commit 8857417870
10 changed files with 1647 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
.taskmaster/docs/autonomous-tdd-git-workflow.md
View File

@@ -637,6 +637,56 @@ Each test run stores detailed results:
}
```
## Execution Model
### Orchestration vs Direct Execution
The autopilot system uses an **orchestration model** rather than direct code execution:
**Orchestrator Role** (tm-core WorkflowOrchestrator):
- Maintains state machine tracking current phase (RED/GREEN/COMMIT) per subtask
- Validates preconditions (tests pass, git state clean, etc.)
- Returns "work units" describing what needs to be done next
- Records completion and advances to next phase
- Persists state for resumability
**Executor Role** (Claude Code/AI session via MCP):
- Queries orchestrator for next work unit
- Executes the work (generates tests, writes code, runs tests, makes commits)
- Reports results back to orchestrator
- Handles file operations and tool invocations
**Why This Approach?**
- Leverages existing AI capabilities (Claude Code) rather than duplicating them
- MCP protocol provides clean separation between state management and execution
- Allows human oversight and intervention at each phase
- Simpler to implement: orchestrator is pure state logic, no code generation needed
- Enables multiple executor types (Claude Code, other AI tools, human developers)
**Example Flow**:
```typescript
// Claude Code (via MCP) queries orchestrator
const workUnit = await orchestrator.getNextWorkUnit('42');
// => {
// phase: 'RED',
// subtask: '42.1',
// action: 'Generate failing tests for metrics schema',
// context: { title, description, dependencies, testFile: 'src/__tests__/schema.test.js' }
// }
// Claude Code executes the work (writes test file, runs tests)
// Then reports back
await orchestrator.completeWorkUnit('42', '42.1', 'RED', {
success: true,
testsCreated: ['src/__tests__/schema.test.js'],
testsFailed: 3
});
// Query again for next phase
const nextWorkUnit = await orchestrator.getNextWorkUnit('42');
// => { phase: 'GREEN', subtask: '42.1', action: 'Implement code to pass tests', ... }
```
## Design Decisions
### Why commit per subtask instead of per task?
@@ -807,15 +857,24 @@ Topological traversal (implementation order):
- Detect test runner (package.json) and git state; render a preflight report.
- Phase 1: Core Rails
- Phase 1: Core Rails (State Machine & Orchestration)
- Implement WorkflowOrchestrator in tm-core with event stream; add Git/Test adapters.
- Implement WorkflowOrchestrator in tm-core as a **state machine** that tracks TDD phases per subtask.
- Support subtask loop (red/green/commit) with framework-agnostic test generation and detected test command; commit gating on passing tests and coverage.
- Orchestrator **guides** the current AI session (Claude Code/MCP client) rather than executing code itself.
- Add Git/Test adapters for status checks and validation (not direct execution).
- WorkflowOrchestrator API:
- `getNextWorkUnit(taskId)` → returns next phase to execute (RED/GREEN/COMMIT) with context
- `completeWorkUnit(taskId, subtaskId, phase, result)` → records completion and advances state
- `getRunState(taskId)` → returns current progress and resumability data
- MCP integration: expose work unit endpoints so Claude Code can query "what to do next" and report back.
- Branch/tag mapping via existing tag-management APIs.
- Run report persisted under .taskmaster/reports/runs/.
- Run report persisted under .taskmaster/reports/runs/ with state checkpoints for resumability.
- Phase 2: PR + Resumability

7
.taskmaster/docs/tdd-workflow-phase-0-spike.md
View File

@@ -1,8 +1,13 @@
# Phase 0: Spike - Autonomous TDD Workflow
# Phase 0: Spike - Autonomous TDD Workflow ✅ COMPLETE
## Objective
Validate feasibility and build foundational understanding before full implementation.
## Status
**COMPLETED** - All deliverables implemented and validated.
See `apps/cli/src/commands/autopilot.command.ts` for implementation.
## Scope
- Implement CLI skeleton `tm autopilot` with dry-run mode
- Show planned steps from a real task with subtasks

369
.taskmaster/docs/tdd-workflow-phase-1-orchestrator.md Normal file
View File

@@ -0,0 +1,369 @@
# Phase 1: Core Rails - State Machine & Orchestration
## Objective
Build the WorkflowOrchestrator as a state machine that guides AI sessions through TDD workflow, rather than directly executing code.
## Architecture Overview
### Execution Model
The orchestrator acts as a **state manager and guide**, not a code executor:
```
┌─────────────────────────────────────────────────────────────┐
│ Claude Code (MCP Client) │
│ - Queries "what to do next" │
│ - Executes work (writes tests, code, runs commands) │
│ - Reports completion │
└────────────────┬────────────────────────────────────────────┘
│ MCP Protocol
▼
┌─────────────────────────────────────────────────────────────┐
│ WorkflowOrchestrator (tm-core) │
│ - Maintains state machine (RED → GREEN → COMMIT) │
│ - Returns work units with context │
│ - Validates preconditions │
│ - Records progress │
│ - Persists state for resumability │
└─────────────────────────────────────────────────────────────┘
```
### Why This Approach?
1. **Separation of Concerns**: State management separate from code execution
2. **Leverage Existing Tools**: Uses Claude Code's capabilities instead of reimplementing
3. **Human-in-the-Loop**: Easy to inspect state and intervene at any phase
4. **Simpler Implementation**: Orchestrator is pure logic, no AI model integration needed
5. **Flexible Executors**: Any tool (Claude Code, human, other AI) can execute work units
## Core Components
### 1. WorkflowOrchestrator Service
**Location**: `packages/tm-core/src/services/workflow-orchestrator.service.ts`
**Responsibilities**:
- Track current phase (RED/GREEN/COMMIT) per subtask
- Generate work units with context for each phase
- Validate phase completion criteria
- Advance state machine on successful completion
- Handle errors and retry logic
- Persist run state for resumability
**API**:
```typescript
interface WorkflowOrchestrator {
// Start a new autopilot run
startRun(taskId: string, options?: RunOptions): Promise<RunContext>;
// Get next work unit to execute
getNextWorkUnit(runId: string): Promise<WorkUnit | null>;
// Report work unit completion
completeWorkUnit(
runId: string,
workUnitId: string,
result: WorkUnitResult
): Promise<void>;
// Get current run state
getRunState(runId: string): Promise<RunState>;
// Pause/resume
pauseRun(runId: string): Promise<void>;
resumeRun(runId: string): Promise<void>;
}
interface WorkUnit {
id: string; // Unique work unit ID
phase: 'RED' | 'GREEN' | 'COMMIT';
subtaskId: string; // e.g., "42.1"
action: string; // Human-readable description
context: WorkUnitContext; // All info needed to execute
preconditions: Precondition[]; // Checks before execution
}
interface WorkUnitContext {
taskId: string;
taskTitle: string;
subtaskTitle: string;
subtaskDescription: string;
dependencies: string[]; // Completed subtask IDs
testCommand: string; // e.g., "npm test"
// Phase-specific context
redPhase?: {
testFile: string; // Where to create test
testFramework: string; // e.g., "vitest"
acceptanceCriteria: string[];
};
greenPhase?: {
testFile: string; // Test to make pass
implementationHints: string[];
expectedFiles: string[]; // Files likely to modify
};
commitPhase?: {
commitMessage: string; // Pre-generated message
filesToCommit: string[]; // Files modified in RED+GREEN
};
}
interface WorkUnitResult {
success: boolean;
phase: 'RED' | 'GREEN' | 'COMMIT';
// RED phase results
testsCreated?: string[];
testsFailed?: number;
// GREEN phase results
testsPassed?: number;
filesModified?: string[];
attempts?: number;
// COMMIT phase results
commitSha?: string;
// Common
error?: string;
logs?: string;
}
interface RunState {
runId: string;
taskId: string;
status: 'running' | 'paused' | 'completed' | 'failed';
currentPhase: 'RED' | 'GREEN' | 'COMMIT';
currentSubtask: string;
completedSubtasks: string[];
failedSubtasks: string[];
startTime: Date;
lastUpdateTime: Date;
// Resumability
checkpoint: {
subtaskId: string;
phase: 'RED' | 'GREEN' | 'COMMIT';
attemptNumber: number;
};
}
```
### 2. State Machine Logic
**Phase Transitions**:
```
START → RED(subtask 1) → GREEN(subtask 1) → COMMIT(subtask 1)
↓
RED(subtask 2) ← ─ ─ ─ ┘
↓
GREEN(subtask 2)
↓
COMMIT(subtask 2)
↓
(repeat for remaining subtasks)
↓
FINALIZE → END
```
**Phase Rules**:
- **RED**: Can only transition to GREEN if tests created and failing
- **GREEN**: Can only transition to COMMIT if tests passing (attempt < maxAttempts)
- **COMMIT**: Can only transition to next RED if commit successful
- **FINALIZE**: Can only start if all subtasks completed
**Preconditions**:
- RED: No uncommitted changes (or staged from previous GREEN that failed)
- GREEN: RED phase complete, tests exist and are failing
- COMMIT: GREEN phase complete, all tests passing, coverage meets threshold
### 3. MCP Integration
**New MCP Tools** (expose WorkflowOrchestrator via MCP):
```typescript
// Start an autopilot run
mcp__task_master_ai__autopilot_start(taskId: string, dryRun?: boolean)
// Get next work unit
mcp__task_master_ai__autopilot_next_work_unit(runId: string)
// Complete current work unit
mcp__task_master_ai__autopilot_complete_work_unit(
runId: string,
workUnitId: string,
result: WorkUnitResult
)
// Get run state
mcp__task_master_ai__autopilot_get_state(runId: string)
// Pause/resume
mcp__task_master_ai__autopilot_pause(runId: string)
mcp__task_master_ai__autopilot_resume(runId: string)
```
### 4. Git/Test Adapters
**GitAdapter** (`packages/tm-core/src/services/git-adapter.service.ts`):
- Check working tree status
- Validate branch state
- Read git config (user, remote, default branch)
- **Does NOT execute** git commands (that's executor's job)
**TestAdapter** (`packages/tm-core/src/services/test-adapter.service.ts`):
- Detect test framework from package.json
- Parse test output (failures, passes, coverage)
- Validate coverage thresholds
- **Does NOT run** tests (that's executor's job)
### 5. Run State Persistence
**Storage Location**: `.taskmaster/reports/runs/<runId>/`
**Files**:
- `state.json` - Current run state (for resumability)
- `log.jsonl` - Event stream (timestamped work unit completions)
- `manifest.json` - Run metadata
- `work-units.json` - All work units generated for this run
**Example `state.json`**:
```json
{
"runId": "2025-01-15-142033",
"taskId": "42",
"status": "paused",
"currentPhase": "GREEN",
"currentSubtask": "42.2",
"completedSubtasks": ["42.1"],
"failedSubtasks": [],
"checkpoint": {
"subtaskId": "42.2",
"phase": "GREEN",
"attemptNumber": 2
},
"startTime": "2025-01-15T14:20:33Z",
"lastUpdateTime": "2025-01-15T14:35:12Z"
}
```
## Implementation Plan
### Step 1: WorkflowOrchestrator Skeleton
- [ ] Create `workflow-orchestrator.service.ts` with interfaces
- [ ] Implement state machine logic (phase transitions)
- [ ] Add run state persistence (state.json, log.jsonl)
- [ ] Write unit tests for state machine
### Step 2: Work Unit Generation
- [ ] Implement `getNextWorkUnit()` with context assembly
- [ ] Generate RED phase work units (test file paths, criteria)
- [ ] Generate GREEN phase work units (implementation hints)
- [ ] Generate COMMIT phase work units (commit messages)
### Step 3: Git/Test Adapters
- [ ] Create GitAdapter for status checks only
- [ ] Create TestAdapter for output parsing only
- [ ] Add precondition validation using adapters
- [ ] Write adapter unit tests
### Step 4: MCP Integration
- [ ] Add MCP tool definitions in `packages/mcp-server/src/tools/`
- [ ] Wire up WorkflowOrchestrator to MCP tools
- [ ] Test MCP tools via Claude Code
- [ ] Document MCP workflow in CLAUDE.md
### Step 5: CLI Integration
- [ ] Update `autopilot.command.ts` to call WorkflowOrchestrator
- [ ] Add `--interactive` mode that shows work units and waits for completion
- [ ] Add `--resume` flag to continue paused runs
- [ ] Test end-to-end flow
### Step 6: Integration Testing
- [ ] Create test task with 2-3 subtasks
- [ ] Run autopilot start → get work unit → complete → repeat
- [ ] Verify state persistence and resumability
- [ ] Test failure scenarios (test failures, git issues)
## Success Criteria
- [ ] WorkflowOrchestrator can generate work units for all phases
- [ ] MCP tools allow Claude Code to query and complete work units
- [ ] State persists correctly between work unit completions
- [ ] Run can be paused and resumed from checkpoint
- [ ] Adapters validate preconditions without executing commands
- [ ] End-to-end: Claude Code can complete a simple task via work units
## Out of Scope (Phase 1)
- Actual git operations (branch creation, commits) - executor handles this
- Actual test execution - executor handles this
- PR creation - deferred to Phase 2
- TUI interface - deferred to Phase 3
- Coverage enforcement - deferred to Phase 2
## Example Usage Flow
```bash
# Terminal 1: Claude Code session
$ claude
# In Claude Code (via MCP):
> Start autopilot for task 42
[Calls mcp__task_master_ai__autopilot_start(42)]
→ Run started: run-2025-01-15-142033
> Get next work unit
[Calls mcp__task_master_ai__autopilot_next_work_unit(run-2025-01-15-142033)]
→ Work unit: RED phase for subtask 42.1
→ Action: Generate failing tests for metrics schema
→ Test file: src/__tests__/schema.test.js
→ Framework: vitest
> [Claude Code creates test file, runs tests]
> Complete work unit
[Calls mcp__task_master_ai__autopilot_complete_work_unit(
run-2025-01-15-142033,
workUnit-42.1-RED,
{ success: true, testsCreated: ['src/__tests__/schema.test.js'], testsFailed: 3 }
)]
→ Work unit completed. State saved.
> Get next work unit
[Calls mcp__task_master_ai__autopilot_next_work_unit(run-2025-01-15-142033)]
→ Work unit: GREEN phase for subtask 42.1
→ Action: Implement code to pass failing tests
→ Test file: src/__tests__/schema.test.js
→ Expected implementation: src/schema.js
> [Claude Code implements schema.js, runs tests, confirms all pass]
> Complete work unit
[...]
→ Work unit completed. Ready for COMMIT.
> Get next work unit
[...]
→ Work unit: COMMIT phase for subtask 42.1
→ Commit message: "feat(metrics): add metrics schema (task 42.1)"
→ Files to commit: src/__tests__/schema.test.js, src/schema.js
> [Claude Code stages files and commits]
> Complete work unit
[...]
→ Subtask 42.1 complete! Moving to 42.2...
```
## Dependencies
- Existing TaskService (task loading, status updates)
- Existing PreflightChecker (environment validation)
- Existing TaskLoaderService (dependency ordering)
- MCP server infrastructure
## Estimated Effort
7-10 days
## Next Phase
Phase 2 will add:
- PR creation via gh CLI
- Coverage enforcement
- Enhanced error recovery
- Full resumability testing

122
.taskmaster/tasks/tasks.json
View File

@@ -9390,7 +9390,7 @@
"testStrategy": "Unit tests for command parsing, argument validation, and help text display. Test both with and without task ID argument.",
"priority": "high",
"dependencies": [],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9398,7 +9398,7 @@
"description": "Create the basic autopilot.command.ts file with Commander class extension and basic structure",
"dependencies": [],
"details": "Create apps/cli/src/commands/autopilot.command.ts extending Commander's Command class. Set up basic class structure with constructor, command name 'autopilot', description, and empty execute method. Follow the pattern used in existing commands like StartCommand for consistency.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for command instantiation and basic structure validation"
},
{
@@ -9409,7 +9409,7 @@
1
],
"details": "Add task ID as required positional argument with validation to ensure it exists in tasks.json. Implement --dry-run boolean flag with proper Commander.js syntax. Add argument validation logic to check task ID format and existence. Include error handling for invalid inputs.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for argument parsing with valid/invalid task IDs and flag combinations"
},
{
@@ -9420,7 +9420,7 @@
2
],
"details": "Add detailed command description, usage examples showing 'tm autopilot <taskId>' and 'tm autopilot <taskId> --dry-run'. Include examples with real task IDs, explain dry-run mode behavior, and provide troubleshooting tips. Follow help text patterns from existing commands.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for help text display and content validation"
},
{
@@ -9431,7 +9431,7 @@
3
],
"details": "Add autopilot command registration to the main CLI application in apps/cli/src/index.ts or appropriate registration file. Ensure command is properly exported and available when running 'tm autopilot'. Follow existing command registration patterns used by other commands.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests for command registration and CLI availability"
},
{
@@ -9442,7 +9442,7 @@
4
],
"details": "Implement the execute method that loads the specified task from tasks.json, validates task existence, and handles dry-run mode by displaying what would be executed without performing actions. Add basic task loading using existing task utilities and prepare structure for future autopilot logic.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for execute method with valid tasks and dry-run mode behavior"
}
]
@@ -9457,7 +9457,7 @@
"dependencies": [
1
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9465,7 +9465,7 @@
"description": "Implement the core PreflightChecker class with method to detect test command from package.json scripts.test field",
"dependencies": [],
"details": "Create src/autopilot/preflight-checker.js with PreflightChecker class. Implement detectTestCommand() method that reads package.json and extracts scripts.test field. Handle cases where package.json doesn't exist or scripts.test is undefined. Return structured result with success/failure status and detected command. Follow existing patterns from other service classes in the codebase.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for detectTestCommand() with various package.json configurations: missing file, missing scripts, missing test script, valid test script. Mock fs.readFileSync for different scenarios."
},
{
@@ -9476,7 +9476,7 @@
1
],
"details": "Add checkGitWorkingTree() method to PreflightChecker that uses existing functions from scripts/modules/utils/git-utils.js. Use isGitRepository() to verify git repo, then check for uncommitted changes using git status. Return structured status indicating if working tree is clean, has staged changes, or has unstaged changes. Include helpful messages about what needs to be committed.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests with mocked git-utils functions for different git states: clean working tree, staged changes, unstaged changes, not a git repository. Integration tests with actual git repository setup."
},
{
@@ -9487,7 +9487,7 @@
2
],
"details": "Add validateRequiredTools() method that checks availability of git, gh CLI, node, and npm commands using execSync with 'which' or 'where' depending on platform. Handle platform differences (Unix vs Windows). Return structured results for each tool with version information where available. Use existing isGhCliAvailable() function from git-utils for gh CLI checking.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests mocking execSync for different scenarios: all tools available, missing tools, platform differences. Test version detection and error handling for command execution failures."
},
{
@@ -9498,7 +9498,7 @@
3
],
"details": "Add detectDefaultBranch() method that uses getDefaultBranch() function from existing git-utils.js. Handle cases where default branch cannot be determined and provide fallback logic. Return structured result with detected branch name and confidence level. Include handling for repositories without remote tracking.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests mocking git-utils getDefaultBranch() for various scenarios: GitHub repo with default branch, local repo without remote, repositories with different default branches (main vs master)."
},
{
@@ -9509,7 +9509,7 @@
4
],
"details": "Add runAllChecks() method that executes all preflight checks in sequence: detectTestCommand(), checkGitWorkingTree(), validateRequiredTools(), detectDefaultBranch(). Collect all results into structured PreflightResult object with overall success status, individual check results, and actionable error messages. Include summary of what passed/failed and next steps for resolving issues.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests running full preflight checks in different project configurations. Test error aggregation and result formatting. Verify that partial failures are handled gracefully with appropriate user guidance."
}
]
@@ -9524,7 +9524,7 @@
"dependencies": [
1
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9532,7 +9532,7 @@
"description": "Create a service class that wraps TaskService from @tm/core to load task data and handle initialization properly",
"dependencies": [],
"details": "Create TaskLoadingService that instantiates TaskService with ConfigManager, handles initialization, and provides methods for loading tasks by ID. Include proper error handling for cases where TaskService fails to initialize or tasks cannot be loaded. Follow existing patterns from tm-core for service instantiation.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for service initialization, task loading success cases, and error handling for initialization failures"
},
{
@@ -9543,7 +9543,7 @@
1
],
"details": "Create validation functions that check: 1) Task exists in TaskMaster state, 2) Task has valid structure according to Task interface from @tm/core types, 3) Task is not in 'done' or 'cancelled' status. Return structured validation results with specific error messages for each validation failure.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests with various task scenarios: valid tasks, non-existent tasks, malformed tasks, completed tasks"
},
{
@@ -9554,7 +9554,7 @@
2
],
"details": "Build validation logic that: 1) Checks if task has subtasks defined, 2) Validates subtask structure matches Subtask interface, 3) Analyzes dependency order to ensure subtasks can be executed sequentially, 4) Identifies any circular dependencies or missing dependencies. Provide detailed feedback on dependency issues.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for tasks with valid subtasks, tasks without subtasks, tasks with circular dependencies, and tasks with missing dependencies"
},
{
@@ -9565,7 +9565,7 @@
3
],
"details": "When validation detects tasks without subtasks, provide helpful messages explaining: 1) Why subtasks are needed for autopilot, 2) How to use 'task-master expand' to create subtasks, 3) Link to existing task expansion patterns from other commands. Include suggestions for complexity analysis if the task appears complex.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for message generation with different task scenarios and integration tests to verify messaging appears correctly"
},
{
@@ -9576,7 +9576,7 @@
4
],
"details": "Create ValidationResult interface that includes: 1) Success/failure status, 2) Specific error types (task not found, no subtasks, dependency issues), 3) Detailed error messages with actionable guidance, 4) Task data when validation succeeds. Implement error handling that provides clear feedback for each validation failure scenario.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for all validation result scenarios and integration tests to verify error handling provides helpful user feedback"
}
]
@@ -9592,7 +9592,7 @@
2,
3
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9600,7 +9600,7 @@
"description": "Create the base ExecutionPlanDisplay class with proper imports and basic structure following existing CLI patterns",
"dependencies": [],
"details": "Create src/display/ExecutionPlanDisplay.ts with class structure. Import boxen and chalk libraries. Set up constructor to accept execution plan data. Define private methods for each display section. Follow existing CLI styling patterns from other commands.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for class instantiation and basic structure validation"
},
{
@@ -9611,7 +9611,7 @@
1
],
"details": "Implement displayPreflightChecks() method that formats check results using chalk for colored status indicators (green checkmarks, red X's). Use boxen for section containers. Display task validation, dependency checks, and branch status results.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for preflight display formatting with passing and failing checks"
},
{
@@ -9622,7 +9622,7 @@
1
],
"details": "Implement displayBranchInfo() method that shows planned branch name, current tag, and branch creation strategy. Use consistent styling with other sections. Display branch existence warnings if applicable.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for branch info display with different tag configurations"
},
{
@@ -9633,7 +9633,7 @@
1
],
"details": "Implement displayExecutionOrder() method that shows ordered subtasks with phase indicators (RED: tests fail, GREEN: tests pass, COMMIT: changes committed). Use color coding and clear phase separation. Include dependency information and estimated duration per subtask.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for execution order display with various dependency patterns and phase transitions"
},
{
@@ -9646,7 +9646,7 @@
4
],
"details": "Implement main display() method that calls all section display methods in proper order. Add displayFinalizationSteps() for PR creation and cleanup steps. Include estimated total duration and final summary. Ensure consistent spacing and styling throughout.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests for complete display output and visual regression tests for CLI formatting"
}
]
@@ -9661,7 +9661,7 @@
"dependencies": [
2
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9669,7 +9669,7 @@
"description": "Create the BranchPlanner class with constructor and main method signatures to establish the foundation for branch name generation",
"dependencies": [],
"details": "Create src/commands/autopilot/branch-planner.js with BranchPlanner class. Include constructor that accepts TaskMaster config and task data. Define main method planBranch() that will return branch name and tag information. Set up basic error handling structure.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for class instantiation and basic method structure"
},
{
@@ -9680,7 +9680,7 @@
1
],
"details": "Implement convertToKebabCase() method that handles special characters, spaces, and length limits. Remove non-alphanumeric characters except hyphens, convert to lowercase, and truncate to reasonable length (e.g., 50 chars). Handle edge cases like empty titles or titles with only special characters.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests with various task title formats including special characters, long titles, and edge cases"
},
{
@@ -9691,7 +9691,7 @@
2
],
"details": "Implement generateBranchName() method that combines active tag from TaskMaster config, task ID, and kebab-case slug. Format as 'tag/task-id-slug'. Handle cases where tag is undefined or empty by using 'feature' as default. Validate generated names against git branch naming rules.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for branch name generation with different tags, task IDs, and slugs"
},
{
@@ -9702,7 +9702,7 @@
1
],
"details": "Create getActiveTag() method that reads from TaskMaster state.json to determine current active tag. Use existing TaskService patterns to access configuration. Handle cases where no tag is set or config is missing. Return default tag 'feature' when no active tag is configured.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for tag detection with various config states including missing config and undefined tags"
},
{
@@ -9714,7 +9714,7 @@
4
],
"details": "Create checkBranchExists() method using git-utils.js to check if generated branch name already exists locally or remotely. Implement conflict resolution by appending incremental numbers (e.g., -2, -3) to branch name. Provide warnings about existing branches in planning output.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for branch conflict detection and resolution with mocked git commands"
}
]
@@ -9729,7 +9729,7 @@
"dependencies": [
3
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9737,7 +9737,7 @@
"description": "Implement the core dependency resolution algorithm that reads subtask dependencies and creates execution order",
"dependencies": [],
"details": "Create src/utils/dependency-resolver.ts with DependencyResolver class. Implement topological sort algorithm that takes subtasks array and returns ordered execution plan. Handle basic dependency chains and ensure tasks without dependencies can execute first. Include proper TypeScript interfaces for subtask data and execution order results.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for basic dependency resolution with linear chains, parallel independent subtasks, and empty dependency arrays"
},
{
@@ -9748,7 +9748,7 @@
1
],
"details": "Extend DependencyResolver to detect circular dependencies using depth-first search with visit tracking. Throw descriptive error when circular dependencies are found, including the cycle path. Add validation before attempting topological sort to fail fast on invalid dependency graphs.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for various circular dependency scenarios: direct cycles (A→B→A), indirect cycles (A→B→C→A), and self-dependencies (A→A)"
},
{
@@ -9759,7 +9759,7 @@
1
],
"details": "Implement parallelization logic that groups subtasks into execution phases. Subtasks with no dependencies or whose dependencies are satisfied in previous phases can execute in parallel. Return execution plan with phase information showing which subtasks can run simultaneously.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for parallel grouping with mixed dependency patterns, ensuring correct phase separation and parallel group identification"
},
{
@@ -9770,7 +9770,7 @@
1
],
"details": "Create interfaces in types/ directory for ExecutionPlan, ExecutionPhase, and SubtaskDependencyInfo. Include fields for subtask ID, dependencies status, execution phase, and parallel group information. Ensure interfaces support both display formatting and autopilot execution needs.",
"status": "pending",
"status": "done",
"testStrategy": "Type checking tests and interface validation with sample data structures matching real subtask scenarios"
},
{
@@ -9784,7 +9784,7 @@
4
],
"details": "Add calculateSubtaskExecutionOrder method to TaskService that uses DependencyResolver. Create UI utilities in apps/cli/src/utils/ui.ts for formatting execution order display with chalk colors and dependency status indicators. Follow existing patterns for task loading and error handling.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests with TaskService loading real task data, and visual tests for CLI display formatting with various dependency scenarios"
}
]
@@ -9799,7 +9799,7 @@
"dependencies": [
6
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9807,7 +9807,7 @@
"description": "Design and implement the core TDDPhasePlanner class that handles phase planning for TDD workflow execution",
"dependencies": [],
"details": "Create a new TDDPhasePlanner class in src/tdd/ directory with methods for: 1) Analyzing subtask data to extract implementation files, 2) Determining appropriate test file paths based on project structure, 3) Generating conventional commit messages, 4) Estimating complexity. The class should accept subtask data and project configuration as inputs.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for class instantiation and method existence. Mock subtask data to verify the class can be initialized properly."
},
{
@@ -9818,7 +9818,7 @@
1
],
"details": "Implement method to analyze project structure and determine test file paths for implementation files. Support common patterns: src/ with tests/, src/ with __tests__/, src/ with .test.js files alongside source, and packages/*/src with packages/*/tests. Use filesystem operations to check existing patterns and generate consistent test file paths.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests with mock filesystem structures testing various project layouts (Jest, Vitest, Node.js patterns). Verify correct test file paths are generated for different source file locations."
},
{
@@ -9829,7 +9829,7 @@
1
],
"details": "Create method to analyze subtask details text and extract file paths mentioned or implied. Use regex patterns and natural language processing to identify: file names mentioned directly, directory structures implied by descriptions, and component/class names that translate to file paths. Handle various file extensions (.js, .ts, .tsx, .vue, .py, etc.).",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests with various subtask detail examples. Test extraction accuracy with different description formats and file types. Verify edge cases like missing file paths or ambiguous descriptions."
},
{
@@ -9840,7 +9840,7 @@
1
],
"details": "Implement method to generate conventional commit messages following the format: type(scope): description. Support commit types: test (for RED phase), feat/fix (for GREEN phase), and refactor (for COMMIT phase). Extract scope from subtask context and generate descriptive messages. Follow the pattern seen in existing hooks: feat(task-<id>): <description>.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for commit message generation with various subtask types and scopes. Verify conventional commit format compliance and message clarity."
},
{
@@ -9853,7 +9853,7 @@
4
],
"details": "Create method to estimate implementation complexity based on: number of files involved, description length and complexity keywords, dependencies between subtasks. Organize the output into three distinct phases: RED (test creation), GREEN (implementation), COMMIT (cleanup/refactor). Include estimated time, file lists, and commit messages for each phase.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for complexity calculation with various subtask scenarios. Integration tests verifying complete phase planning output includes all required metadata and follows TDD workflow structure."
}
]
@@ -9869,7 +9869,7 @@
2,
6
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9877,7 +9877,7 @@
"description": "Create the basic FinalizationPlanner class with interface definition and core methods for planning finalization steps",
"dependencies": [],
"details": "Create a new FinalizationPlanner class that will handle planning final steps after subtask completion. Include interface definitions for finalization steps (test execution, branch push, PR creation, duration estimation) and basic class structure with methods for each planning component. The class should accept subtask data and project context as input.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for class instantiation and method structure. Test interface definitions and basic method signatures."
},
{
@@ -9888,7 +9888,7 @@
1
],
"details": "Implement test command detection by reading package.json scripts for 'test', 'test:coverage', 'test:ci' commands. Parse coverage configuration from package.json, jest.config.js, vitest.config.js, or other config files to detect coverage thresholds. Generate execution plan showing which test command would be run and expected coverage requirements. Handle projects without test commands gracefully.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for package.json parsing, config file detection, and coverage threshold extraction. Test with various project structures (Jest, Vitest, no tests)."
},
{
@@ -9899,7 +9899,7 @@
1
],
"details": "Use existing git-utils.js functions like getDefaultBranch(), getCurrentBranch(), and isGhCliAvailable() to plan git operations. Generate branch push confirmation plan showing current branch and target remote. Detect default branch for PR creation planning. Check if gh CLI is available for PR operations. Plan git status checks and dirty working tree warnings.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for git-utils integration, branch detection, and gh CLI availability checking. Mock git-utils functions to test various git states."
},
{
@@ -9910,7 +9910,7 @@
3
],
"details": "Generate PR creation plan that includes conventional commit-style title generation based on subtask changes, PR body template with task/subtask references, target branch detection using git-utils, and gh CLI command planning. Include checks for existing PR detection and conflict resolution. Plan PR description formatting with task context and implementation notes.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for PR title generation, body template creation, and gh CLI command planning. Test with various task types and subtask combinations."
},
{
@@ -9923,7 +9923,7 @@
4
],
"details": "Create duration estimation algorithm that factors in number of subtasks, complexity indicators (file count, test coverage requirements, git operations), and historical patterns. Provide time estimates for each finalization step (testing, git operations, PR creation) and total completion time. Include confidence intervals and factors that might affect duration. Format estimates in human-readable time units.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for duration calculation algorithms, complexity analysis, and time formatting. Test with various subtask configurations and complexity scenarios."
}
]
@@ -9939,7 +9939,7 @@
1,
4
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -9947,7 +9947,7 @@
"description": "Create the AutopilotCommand class file following the existing command pattern used by StartCommand",
"dependencies": [],
"details": "Create apps/cli/src/commands/autopilot.command.ts with basic class structure extending Commander's Command class. Include constructor, command configuration, and placeholder action method. Follow the exact pattern from StartCommand including imports, error handling, and class structure.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for class instantiation and basic command configuration"
},
{
@@ -9958,7 +9958,7 @@
1
],
"details": "Add import statement for AutopilotCommand in apps/cli/src/command-registry.ts following the existing import pattern. Place it in the appropriate position with other command imports maintaining alphabetical order.",
"status": "pending",
"status": "done",
"testStrategy": "Verify import resolves correctly and doesn't break existing imports"
},
{
@@ -9969,7 +9969,7 @@
2
],
"details": "Add autopilot command entry to the commands array in CommandRegistry class. Use 'development' category, provide appropriate description, and reference AutopilotCommand class. Follow the existing pattern with name, description, commandClass, and category fields.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests to verify command is registered and appears in registry listing"
},
{
@@ -9980,7 +9980,7 @@
1
],
"details": "Add AutopilotCommand export to apps/cli/src/index.ts in the Commands section following the existing export pattern. Ensure it's properly exported for external usage and testing.",
"status": "pending",
"status": "done",
"testStrategy": "Verify export is available and can be imported from @tm/cli package"
},
{
@@ -9991,7 +9991,7 @@
3
],
"details": "Verify that the autopilot command appears in the CLI help system through the CommandRegistry.getFormattedCommandList() method. The 'development' category should be included in help output with autopilot command listed. Test help display functionality.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests for help system displaying autopilot command. Test CLI help output includes autopilot in development category."
}
]
@@ -10008,7 +10008,7 @@
2,
3
],
"status": "pending",
"status": "done",
"subtasks": [
{
"id": 1,
@@ -10016,7 +10016,7 @@
"description": "Add error handling for git repository validation, dirty working tree detection, and missing git tool",
"dependencies": [],
"details": "Create validation functions to check if current directory is a git repository, detect dirty working tree status using git-utils.js patterns, and verify git CLI tool availability. Return specific error messages for each failure case with helpful suggestions for resolution.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for git validation with mocked git states. Test clean/dirty working tree detection and missing git tool scenarios."
},
{
@@ -10027,7 +10027,7 @@
1
],
"details": "Create TaskValidator class that checks task existence in tasks.json, validates task has subtasks for autopilot execution, detects invalid dependency references, and identifies circular dependency chains. Use existing dependency validation patterns from other commands.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for each validation scenario with mock task data. Test circular dependency detection with various dependency graphs."
},
{
@@ -10038,7 +10038,7 @@
1
],
"details": "Create ToolValidator that checks availability of gh CLI, node, npm, and other required tools using spawn or which-like detection. Provide specific error messages with installation instructions for each missing tool based on the user's platform.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for tool detection with mocked command availability. Test error messages for different missing tool combinations."
},
{
@@ -10049,7 +10049,7 @@
2
],
"details": "Extend PreflightChecker to handle cases where package.json is missing, has no scripts section, or no test script defined. Provide helpful error messages suggesting common test script configurations and link to documentation for test setup.",
"status": "pending",
"status": "done",
"testStrategy": "Unit tests for various package.json configurations. Test error messages for missing test scripts and invalid package.json files."
},
{
@@ -10063,7 +10063,7 @@
4
],
"details": "Create ErrorReporter class that collects all validation errors, formats them with clear descriptions and resolution steps, and provides a summary of required actions before autopilot can run. Follow existing error formatting patterns from other TaskMaster commands.",
"status": "pending",
"status": "done",
"testStrategy": "Integration tests combining multiple error scenarios. Test error message clarity and formatting. Verify all error types are properly handled and reported."
}
]
@@ -10071,7 +10071,7 @@
],
"metadata": {
"created": "2025-10-07T14:08:52.047Z",
"updated": "2025-10-07T14:13:46.675Z",
"updated": "2025-10-07T15:23:43.279Z",
"description": "Tasks for tdd-workflow-phase-0 context"
}
}