e90f822bdd
Overhauls the project root detection system with a hierarchical precedence mechanism that intelligently locates tasks.json and identifies project roots. This improves user experience by reducing the need for explicit path parameters and enhances cross-platform compatibility. Key Improvements: - Implement hierarchical precedence for project root detection: * Environment variable override (TASK_MASTER_PROJECT_ROOT) * Explicitly provided --project-root parameter * Cached project root from previous successful operations * Current directory with project markers * Parent directory traversal to find tasks.json * Package directory as fallback - Create comprehensive PROJECT_MARKERS detection system with 20+ common indicators: * Task Master specific files (tasks.json, tasks/tasks.json) * Version control directories (.git, .svn) * Package manifests (package.json, pyproject.toml, Gemfile, go.mod, Cargo.toml) * IDE/editor configurations (.cursor, .vscode, .idea) * Dependency directories (node_modules, venv, .venv) * Configuration files (.env, tsconfig.json, webpack.config.js) * CI/CD files (.github/workflows, .gitlab-ci.yml, .circleci/config.yml) - DRY refactoring of path utilities: * Centralize path-related functions in core/utils/path-utils.js * Export PROJECT_MARKERS as a single source of truth * Add caching via lastFoundProjectRoot for performance optimization - Enhanced user experience: * Improve error messages with specific troubleshooting guidance * Add detailed logging to indicate project root detection source * Update tool parameter descriptions for better clarity * Add recursive parent directory searching for tasks.json Testing: - Verified in local dev environment - Added unit tests for the progress bar visualization - Updated "automatically detected" description in MCP tools This commit addresses Task #38: Implement robust project root handling for file paths.
40 lines
2.6 KiB
Plaintext
40 lines
2.6 KiB
Plaintext
# Task ID: 40
|
|
# Title: Implement 'plan' Command for Task Implementation Planning
|
|
# Status: pending
|
|
# Dependencies: None
|
|
# Priority: medium
|
|
# Description: Create a new 'plan' command that appends a structured implementation plan to tasks or subtasks, generating step-by-step instructions for execution based on the task content.
|
|
# Details:
|
|
Implement a new 'plan' command that will append a structured implementation plan to existing tasks or subtasks. The implementation should:
|
|
|
|
1. Accept an '--id' parameter that can reference either a task or subtask ID
|
|
2. Determine whether the ID refers to a task or subtask and retrieve the appropriate content from tasks.json and/or individual task files
|
|
3. Generate a step-by-step implementation plan using AI (Claude by default)
|
|
4. Support a '--research' flag to use Perplexity instead of Claude when needed
|
|
5. Format the generated plan within XML tags like `<implementation_plan as of timestamp>...</implementation_plan>`
|
|
6. Append this plan to the implementation details section of the task/subtask
|
|
7. Display a confirmation card indicating the implementation plan was successfully created
|
|
|
|
The implementation plan should be detailed and actionable, containing specific steps such as searching for files, creating new files, modifying existing files, etc. The goal is to frontload planning work into the task/subtask so execution can begin immediately.
|
|
|
|
Reference the existing 'update-subtask' command implementation as a starting point, as it uses a similar approach for appending content to tasks. Ensure proper error handling for cases where the specified ID doesn't exist or when API calls fail.
|
|
|
|
# Test Strategy:
|
|
Testing should verify:
|
|
|
|
1. Command correctly identifies and retrieves content for both task and subtask IDs
|
|
2. Implementation plans are properly generated and formatted with XML tags and timestamps
|
|
3. Plans are correctly appended to the implementation details section without overwriting existing content
|
|
4. The '--research' flag successfully switches the backend from Claude to Perplexity
|
|
5. Appropriate error messages are displayed for invalid IDs or API failures
|
|
6. Confirmation card is displayed after successful plan creation
|
|
|
|
Test cases should include:
|
|
- Running 'plan --id 123' on an existing task
|
|
- Running 'plan --id 123.1' on an existing subtask
|
|
- Running 'plan --id 123 --research' to test the Perplexity integration
|
|
- Running 'plan --id 999' with a non-existent ID to verify error handling
|
|
- Running the command on tasks with existing implementation plans to ensure proper appending
|
|
|
|
Manually review the quality of generated plans to ensure they provide actionable, step-by-step guidance that accurately reflects the task requirements.
|