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

Implements updateTask command to update a single task instead of all tasks as of a certain one. Useful when iterating and R&D'ing bit by bit and needing more research after what has been done.

Browse Source
This commit is contained in:
Eyal Toledano
2025-03-27 01:33:20 -04:00
parent c4f7de8845
commit e4cff5e671
9 changed files with 1395 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
tasks/task_023.txt
View File

@@ -5,38 +5,38 @@
# Priority: medium
# Description: Extend Task Master to function as an MCP server by leveraging FastMCP's JavaScript/TypeScript implementation for efficient context management services.
# Details:
This task involves implementing the Model Context Protocol server capabilities within Task Master using FastMCP. The implementation should:
This task involves implementing the Model Context Protocol server capabilities within Task Master. The implementation should:
1. Use FastMCP to create the MCP server module (`mcp-server.ts` or equivalent)
2. Implement the required MCP endpoints using FastMCP:
1. Create a new module `mcp-server.js` that implements the core MCP server functionality
2. Implement the required MCP endpoints:
- `/context` - For retrieving and updating context
- `/models` - For listing available models
- `/execute` - For executing operations with context
3. Utilize FastMCP's built-in features for context management, including:
- Efficient context storage and retrieval
- Context windowing and truncation
- Metadata and tagging support
4. Add authentication and authorization mechanisms using FastMCP capabilities
5. Implement error handling and response formatting as per MCP specifications
6. Configure Task Master to enable/disable MCP server functionality via FastMCP settings
7. Add documentation on using Task Master as an MCP server with FastMCP
8. Ensure compatibility with existing MCP clients by adhering to FastMCP's compliance features
9. Optimize performance using FastMCP tools, especially for context retrieval operations
10. Add logging for MCP server operations using FastMCP's logging utilities
3. Develop a context management system that can:
- Store and retrieve context data efficiently
- Handle context windowing and truncation when limits are reached
- Support context metadata and tagging
4. Add authentication and authorization mechanisms for MCP clients
5. Implement proper error handling and response formatting according to MCP specifications
6. Create configuration options in Task Master to enable/disable the MCP server functionality
7. Add documentation for how to use Task Master as an MCP server
8. Ensure the implementation is compatible with existing MCP clients
9. Optimize for performance, especially for context retrieval operations
10. Add logging for MCP server operations
The implementation should follow RESTful API design principles and leverage FastMCP's concurrency handling for multiple client requests. Consider using TypeScript for better type safety and integration with FastMCP[1][2].
The implementation should follow RESTful API design principles and should be able to handle concurrent requests from multiple clients.
# Test Strategy:
Testing for the MCP server functionality should include:
1. Unit tests:
- Test each MCP endpoint handler function independently using FastMCP
- Verify context storage and retrieval mechanisms provided by FastMCP
- Test each MCP endpoint handler function independently
- Verify context storage and retrieval mechanisms
- Test authentication and authorization logic
- Validate error handling for various failure scenarios
2. Integration tests:
- Set up a test MCP server instance using FastMCP
- Set up a test MCP server instance
- Test complete request/response cycles for each endpoint
- Verify context persistence across multiple requests
- Test with various payload sizes and content types
@@ -44,11 +44,11 @@ Testing for the MCP server functionality should include:
3. Compatibility tests:
- Test with existing MCP client libraries
- Verify compliance with the MCP specification
- Ensure backward compatibility with any MCP versions supported by FastMCP
- Ensure backward compatibility with any MCP versions supported
4. Performance tests:
- Measure response times for context operations with various context sizes
- Test concurrent request handling using FastMCP's concurrency tools
- Test concurrent request handling
- Verify memory usage remains within acceptable limits during extended operation
5. Security tests:
@@ -79,7 +79,7 @@ Testing approach:
- Test basic error handling with invalid requests
## 2. Implement Context Management System [done]
### Dependencies: 23.1
### Dependencies: 23.1
### Description: Develop a robust context management system that can efficiently store, retrieve, and manipulate context data according to the MCP specification.
### Details:
Implementation steps:
@@ -100,7 +100,7 @@ Testing approach:
- Test persistence mechanisms with simulated failures
## 3. Implement MCP Endpoints and API Handlers [done]
### Dependencies: 23.1, 23.2
### Dependencies: 23.1, 23.2
### Description: Develop the complete API handlers for all required MCP endpoints, ensuring they follow the protocol specification and integrate with the context management system.
### Details:
Implementation steps:
@@ -126,7 +126,7 @@ Testing approach:
- Benchmark endpoint performance
## 4. Implement Authentication and Authorization System [pending]
### Dependencies: 23.1, 23.3
### Dependencies: 23.1, 23.3
### Description: Create a secure authentication and authorization mechanism for MCP clients to ensure only authorized applications can access the MCP server functionality.
### Details:
Implementation steps:
@@ -148,7 +148,7 @@ Testing approach:
- Verify audit logs contain appropriate information
## 5. Optimize Performance and Finalize Documentation [pending]
### Dependencies: 23.1, 23.2, 23.3, 23.4
### Dependencies: 23.1, 23.2, 23.3, 23.4
### Description: Optimize the MCP server implementation for performance, especially for context retrieval operations, and create comprehensive documentation for users.
### Details:
Implementation steps:

156
tasks/task_034.txt Normal file
View File

@@ -0,0 +1,156 @@
# Task ID: 34
# Title: Implement updateTask Command for Single Task Updates
# Status: in-progress
# Dependencies: None
# Priority: high
# Description: Create a new command that allows updating a specific task by ID using AI-driven refinement while preserving completed subtasks and supporting all existing update command options.
# Details:
Implement a new command called 'updateTask' that focuses on updating a single task rather than all tasks from an ID onwards. The implementation should:
1. Accept a single task ID as a required parameter
2. Use the same AI-driven approach as the existing update command to refine the task
3. Preserve the completion status of any subtasks that were previously marked as complete
4. Support all options from the existing update command including:
- The research flag for Perplexity integration
- Any formatting or refinement options
- Task context options
5. Update the CLI help documentation to include this new command
6. Ensure the command follows the same pattern as other commands in the codebase
7. Add appropriate error handling for cases where the specified task ID doesn't exist
8. Implement the ability to update task title, description, and details separately if needed
9. Ensure the command returns appropriate success/failure messages
10. Optimize the implementation to only process the single task rather than scanning through all tasks
The command should reuse existing AI prompt templates where possible but modify them to focus on refining a single task rather than multiple tasks.
# Test Strategy:
Testing should verify the following aspects:
1. **Basic Functionality Test**: Verify that the command successfully updates a single task when given a valid task ID
2. **Preservation Test**: Create a task with completed subtasks, update it, and verify the completion status remains intact
3. **Research Flag Test**: Test the command with the research flag and verify it correctly integrates with Perplexity
4. **Error Handling Tests**:
- Test with non-existent task ID and verify appropriate error message
- Test with invalid parameters and verify helpful error messages
5. **Integration Test**: Run a complete workflow that creates a task, updates it with updateTask, and then verifies the changes are persisted
6. **Comparison Test**: Compare the results of updating a single task with updateTask versus using the original update command on the same task to ensure consistent quality
7. **Performance Test**: Measure execution time compared to the full update command to verify efficiency gains
8. **CLI Help Test**: Verify the command appears correctly in help documentation with appropriate descriptions
Create unit tests for the core functionality and integration tests for the complete workflow. Document any edge cases discovered during testing.
# Subtasks:
## 1. Create updateTaskById function in task-manager.js [done]
### Dependencies: None
### Description: Implement a new function in task-manager.js that focuses on updating a single task by ID using AI-driven refinement while preserving completed subtasks.
### Details:
Implementation steps:
1. Create a new `updateTaskById` function in task-manager.js that accepts parameters: taskId, options object (containing research flag, formatting options, etc.)
2. Implement logic to find a specific task by ID in the tasks array
3. Add appropriate error handling for cases where the task ID doesn't exist (throw a custom error)
4. Reuse existing AI prompt templates but modify them to focus on refining a single task
5. Implement logic to preserve completion status of subtasks that were previously marked as complete
6. Add support for updating task title, description, and details separately based on options
7. Optimize the implementation to only process the single task rather than scanning through all tasks
8. Return the updated task and appropriate success/failure messages
Testing approach:
- Unit test the function with various scenarios including:
- Valid task ID with different update options
- Non-existent task ID
- Task with completed subtasks to verify preservation
- Different combinations of update options
## 2. Implement updateTask command in commands.js [done]
### Dependencies: 34.1
### Description: Create a new command called 'updateTask' in commands.js that leverages the updateTaskById function to update a specific task by ID.
### Details:
Implementation steps:
1. Create a new command object for 'updateTask' in commands.js following the Command pattern
2. Define command parameters including a required taskId parameter
3. Support all options from the existing update command:
- Research flag for Perplexity integration
- Formatting and refinement options
- Task context options
4. Implement the command handler function that calls the updateTaskById function from task-manager.js
5. Add appropriate error handling to catch and display user-friendly error messages
6. Ensure the command follows the same pattern as other commands in the codebase
7. Implement proper validation of input parameters
8. Format and return appropriate success/failure messages to the user
Testing approach:
- Unit test the command handler with various input combinations
- Test error handling scenarios
- Verify command options are correctly passed to the updateTaskById function
## 3. Add comprehensive error handling and validation [done]
### Dependencies: 34.1, 34.2
### Description: Implement robust error handling and validation for the updateTask command to ensure proper user feedback and system stability.
### Details:
Implementation steps:
1. Create custom error types for different failure scenarios (TaskNotFoundError, ValidationError, etc.)
2. Implement input validation for the taskId parameter and all options
3. Add proper error handling for AI service failures with appropriate fallback mechanisms
4. Implement concurrency handling to prevent conflicts when multiple updates occur simultaneously
5. Add comprehensive logging for debugging and auditing purposes
6. Ensure all error messages are user-friendly and actionable
7. Implement proper HTTP status codes for API responses if applicable
8. Add validation to ensure the task exists before attempting updates
Testing approach:
- Test various error scenarios including invalid inputs, non-existent tasks, and API failures
- Verify error messages are clear and helpful
- Test concurrency scenarios with multiple simultaneous updates
- Verify logging captures appropriate information for troubleshooting
## 4. Write comprehensive tests for updateTask command [in-progress]
### Dependencies: 34.1, 34.2, 34.3
### Description: Create a comprehensive test suite for the updateTask command to ensure it works correctly in all scenarios and maintains backward compatibility.
### Details:
Implementation steps:
1. Create unit tests for the updateTaskById function in task-manager.js
- Test finding and updating tasks with various IDs
- Test preservation of completed subtasks
- Test different update options combinations
- Test error handling for non-existent tasks
2. Create unit tests for the updateTask command in commands.js
- Test command parameter parsing
- Test option handling
- Test error scenarios and messages
3. Create integration tests that verify the end-to-end flow
- Test the command with actual AI service integration
- Test with mock AI responses for predictable testing
4. Implement test fixtures and mocks for consistent testing
5. Add performance tests to ensure the command is efficient
6. Test edge cases such as empty tasks, tasks with many subtasks, etc.
Testing approach:
- Use Jest or similar testing framework
- Implement mocks for external dependencies like AI services
- Create test fixtures for consistent test data
- Use snapshot testing for command output verification
## 5. Update CLI documentation and help text [pending]
### Dependencies: 34.2
### Description: Update the CLI help documentation to include the new updateTask command and ensure users understand its purpose and options.
### Details:
Implementation steps:
1. Add comprehensive help text for the updateTask command including:
- Command description
- Required and optional parameters
- Examples of usage
- Description of all supported options
2. Update the main CLI help documentation to include the new command
3. Add the command to any relevant command groups or categories
4. Create usage examples that demonstrate common scenarios
5. Update README.md and other documentation files to include information about the new command
6. Add inline code comments explaining the implementation details
7. Update any API documentation if applicable
8. Create or update user guides with the new functionality
Testing approach:
- Verify help text is displayed correctly when running `--help`
- Review documentation for clarity and completeness
- Have team members review the documentation for usability
- Test examples to ensure they work as documented

48
tasks/task_035.txt Normal file
View File

@@ -0,0 +1,48 @@
# Task ID: 35
# Title: Integrate Grok3 API for Research Capabilities
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Replace the current Perplexity API integration with Grok3 API for all research-related functionalities while maintaining existing feature parity.
# Details:
This task involves migrating from Perplexity to Grok3 API for research capabilities throughout the application. Implementation steps include:
1. Create a new API client module for Grok3 in `src/api/grok3.ts` that handles authentication, request formatting, and response parsing
2. Update the research service layer to use the new Grok3 client instead of Perplexity
3. Modify the request payload structure to match Grok3's expected format (parameters like temperature, max_tokens, etc.)
4. Update response handling to properly parse and extract Grok3's response format
5. Implement proper error handling for Grok3-specific error codes and messages
6. Update environment variables and configuration files to include Grok3 API keys and endpoints
7. Ensure rate limiting and quota management are properly implemented according to Grok3's specifications
8. Update any UI components that display research provider information to show Grok3 instead of Perplexity
9. Maintain backward compatibility for any stored research results from Perplexity
10. Document the new API integration in the developer documentation
Grok3 API has different parameter requirements and response formats compared to Perplexity, so careful attention must be paid to these differences during implementation.
# Test Strategy:
Testing should verify that the Grok3 API integration works correctly and maintains feature parity with the previous Perplexity implementation:
1. Unit tests:
- Test the Grok3 API client with mocked responses
- Verify proper error handling for various error scenarios (rate limits, authentication failures, etc.)
- Test the transformation of application requests to Grok3-compatible format
2. Integration tests:
- Perform actual API calls to Grok3 with test credentials
- Verify that research results are correctly parsed and returned
- Test with various types of research queries to ensure broad compatibility
3. End-to-end tests:
- Test the complete research flow from UI input to displayed results
- Verify that all existing research features work with the new API
4. Performance tests:
- Compare response times between Perplexity and Grok3
- Ensure the application handles any differences in response time appropriately
5. Regression tests:
- Verify that existing features dependent on research capabilities continue to work
- Test that stored research results from Perplexity are still accessible and displayed correctly
Create a test environment with both APIs available to compare results and ensure quality before fully replacing Perplexity with Grok3.

48
tasks/task_036.txt Normal file
View File

@@ -0,0 +1,48 @@
# Task ID: 36
# Title: Add Ollama Support for AI Services as Claude Alternative
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Implement Ollama integration as an alternative to Claude for all main AI services, allowing users to run local language models instead of relying on cloud-based Claude API.
# Details:
This task involves creating a comprehensive Ollama integration that can replace Claude across all main AI services in the application. Implementation should include:
1. Create an OllamaService class that implements the same interface as the ClaudeService to ensure compatibility
2. Add configuration options to specify Ollama endpoint URL (default: http://localhost:11434)
3. Implement model selection functionality to allow users to choose which Ollama model to use (e.g., llama3, mistral, etc.)
4. Handle prompt formatting specific to Ollama models, ensuring proper system/user message separation
5. Implement proper error handling for cases where Ollama server is unavailable or returns errors
6. Add fallback mechanism to Claude when Ollama fails or isn't configured
7. Update the AI service factory to conditionally create either Claude or Ollama service based on configuration
8. Ensure token counting and rate limiting are appropriately handled for Ollama models
9. Add documentation for users explaining how to set up and use Ollama with the application
10. Optimize prompt templates specifically for Ollama models if needed
The implementation should be toggled through a configuration option (useOllama: true/false) and should maintain all existing functionality currently provided by Claude.
# Test Strategy:
Testing should verify that Ollama integration works correctly as a drop-in replacement for Claude:
1. Unit tests:
- Test OllamaService class methods in isolation with mocked responses
- Verify proper error handling when Ollama server is unavailable
- Test fallback mechanism to Claude when configured
2. Integration tests:
- Test with actual Ollama server running locally with at least two different models
- Verify all AI service functions work correctly with Ollama
- Compare outputs between Claude and Ollama for quality assessment
3. Configuration tests:
- Verify toggling between Claude and Ollama works as expected
- Test with various model configurations
4. Performance tests:
- Measure and compare response times between Claude and Ollama
- Test with different load scenarios
5. Manual testing:
- Verify all main AI features work correctly with Ollama
- Test edge cases like very long inputs or specialized tasks
Create a test document comparing output quality between Claude and various Ollama models to help users understand the tradeoffs.

98
tasks/tasks.json
View File

@@ -1731,6 +1731,104 @@
"priority": "medium",
"details": "This task involves creating a mechanism to generate a Windsurf-specific rules document by combining three existing MDC (Markdown Content) files that are currently used for Cursor Rules. The implementation should:\n\n1. Identify and locate the three primary .mdc files used for Cursor Rules\n2. Extract content from these files and merge them into a single document\n3. Refactor the content to make it Windsurf-specific, replacing Cursor-specific terminology and adapting guidelines as needed\n4. Create a function that generates a .windsurfrules document from this content\n5. Integrate this function into the initialization pipeline\n6. Implement logic to check if a .windsurfrules document already exists:\n - If it exists, append the new content to it\n - If it doesn't exist, create a new document\n7. Ensure proper error handling for file operations\n8. Add appropriate logging to track the generation and modification of the .windsurfrules document\n\nThe implementation should be modular and maintainable, with clear separation of concerns between content extraction, refactoring, and file operations.",
"testStrategy": "Testing should verify both the content generation and the integration with the initialization pipeline:\n\n1. Unit Tests:\n - Test the content extraction function with mock .mdc files\n - Test the content refactoring function to ensure Cursor-specific terms are properly replaced\n - Test the file operation functions with mock filesystem\n\n2. Integration Tests:\n - Test the creation of a new .windsurfrules document when none exists\n - Test appending to an existing .windsurfrules document\n - Test the complete initialization pipeline with the new functionality\n\n3. Manual Verification:\n - Inspect the generated .windsurfrules document to ensure content is properly combined and refactored\n - Verify that Cursor-specific terminology has been replaced with Windsurf-specific terminology\n - Run the initialization process multiple times to verify idempotence (content isn't duplicated on multiple runs)\n\n4. Edge Cases:\n - Test with missing or corrupted .mdc files\n - Test with an existing but empty .windsurfrules document\n - Test with an existing .windsurfrules document that already contains some of the content"
},
{
"id": 34,
"title": "Implement updateTask Command for Single Task Updates",
"description": "Create a new command that allows updating a specific task by ID using AI-driven refinement while preserving completed subtasks and supporting all existing update command options.",
"status": "in-progress",
"dependencies": [],
"priority": "high",
"details": "Implement a new command called 'updateTask' that focuses on updating a single task rather than all tasks from an ID onwards. The implementation should:\n\n1. Accept a single task ID as a required parameter\n2. Use the same AI-driven approach as the existing update command to refine the task\n3. Preserve the completion status of any subtasks that were previously marked as complete\n4. Support all options from the existing update command including:\n - The research flag for Perplexity integration\n - Any formatting or refinement options\n - Task context options\n5. Update the CLI help documentation to include this new command\n6. Ensure the command follows the same pattern as other commands in the codebase\n7. Add appropriate error handling for cases where the specified task ID doesn't exist\n8. Implement the ability to update task title, description, and details separately if needed\n9. Ensure the command returns appropriate success/failure messages\n10. Optimize the implementation to only process the single task rather than scanning through all tasks\n\nThe command should reuse existing AI prompt templates where possible but modify them to focus on refining a single task rather than multiple tasks.",
"testStrategy": "Testing should verify the following aspects:\n\n1. **Basic Functionality Test**: Verify that the command successfully updates a single task when given a valid task ID\n2. **Preservation Test**: Create a task with completed subtasks, update it, and verify the completion status remains intact\n3. **Research Flag Test**: Test the command with the research flag and verify it correctly integrates with Perplexity\n4. **Error Handling Tests**:\n - Test with non-existent task ID and verify appropriate error message\n - Test with invalid parameters and verify helpful error messages\n5. **Integration Test**: Run a complete workflow that creates a task, updates it with updateTask, and then verifies the changes are persisted\n6. **Comparison Test**: Compare the results of updating a single task with updateTask versus using the original update command on the same task to ensure consistent quality\n7. **Performance Test**: Measure execution time compared to the full update command to verify efficiency gains\n8. **CLI Help Test**: Verify the command appears correctly in help documentation with appropriate descriptions\n\nCreate unit tests for the core functionality and integration tests for the complete workflow. Document any edge cases discovered during testing.",
"subtasks": [
{
"id": 1,
"title": "Create updateTaskById function in task-manager.js",
"description": "Implement a new function in task-manager.js that focuses on updating a single task by ID using AI-driven refinement while preserving completed subtasks.",
"dependencies": [],
"details": "Implementation steps:\n1. Create a new `updateTaskById` function in task-manager.js that accepts parameters: taskId, options object (containing research flag, formatting options, etc.)\n2. Implement logic to find a specific task by ID in the tasks array\n3. Add appropriate error handling for cases where the task ID doesn't exist (throw a custom error)\n4. Reuse existing AI prompt templates but modify them to focus on refining a single task\n5. Implement logic to preserve completion status of subtasks that were previously marked as complete\n6. Add support for updating task title, description, and details separately based on options\n7. Optimize the implementation to only process the single task rather than scanning through all tasks\n8. Return the updated task and appropriate success/failure messages\n\nTesting approach:\n- Unit test the function with various scenarios including:\n - Valid task ID with different update options\n - Non-existent task ID\n - Task with completed subtasks to verify preservation\n - Different combinations of update options",
"status": "done",
"parentTaskId": 34
},
{
"id": 2,
"title": "Implement updateTask command in commands.js",
"description": "Create a new command called 'updateTask' in commands.js that leverages the updateTaskById function to update a specific task by ID.",
"dependencies": [
1
],
"details": "Implementation steps:\n1. Create a new command object for 'updateTask' in commands.js following the Command pattern\n2. Define command parameters including a required taskId parameter\n3. Support all options from the existing update command:\n - Research flag for Perplexity integration\n - Formatting and refinement options\n - Task context options\n4. Implement the command handler function that calls the updateTaskById function from task-manager.js\n5. Add appropriate error handling to catch and display user-friendly error messages\n6. Ensure the command follows the same pattern as other commands in the codebase\n7. Implement proper validation of input parameters\n8. Format and return appropriate success/failure messages to the user\n\nTesting approach:\n- Unit test the command handler with various input combinations\n- Test error handling scenarios\n- Verify command options are correctly passed to the updateTaskById function",
"status": "done",
"parentTaskId": 34
},
{
"id": 3,
"title": "Add comprehensive error handling and validation",
"description": "Implement robust error handling and validation for the updateTask command to ensure proper user feedback and system stability.",
"dependencies": [
1,
2
],
"details": "Implementation steps:\n1. Create custom error types for different failure scenarios (TaskNotFoundError, ValidationError, etc.)\n2. Implement input validation for the taskId parameter and all options\n3. Add proper error handling for AI service failures with appropriate fallback mechanisms\n4. Implement concurrency handling to prevent conflicts when multiple updates occur simultaneously\n5. Add comprehensive logging for debugging and auditing purposes\n6. Ensure all error messages are user-friendly and actionable\n7. Implement proper HTTP status codes for API responses if applicable\n8. Add validation to ensure the task exists before attempting updates\n\nTesting approach:\n- Test various error scenarios including invalid inputs, non-existent tasks, and API failures\n- Verify error messages are clear and helpful\n- Test concurrency scenarios with multiple simultaneous updates\n- Verify logging captures appropriate information for troubleshooting",
"status": "done",
"parentTaskId": 34
},
{
"id": 4,
"title": "Write comprehensive tests for updateTask command",
"description": "Create a comprehensive test suite for the updateTask command to ensure it works correctly in all scenarios and maintains backward compatibility.",
"dependencies": [
1,
2,
3
],
"details": "Implementation steps:\n1. Create unit tests for the updateTaskById function in task-manager.js\n - Test finding and updating tasks with various IDs\n - Test preservation of completed subtasks\n - Test different update options combinations\n - Test error handling for non-existent tasks\n2. Create unit tests for the updateTask command in commands.js\n - Test command parameter parsing\n - Test option handling\n - Test error scenarios and messages\n3. Create integration tests that verify the end-to-end flow\n - Test the command with actual AI service integration\n - Test with mock AI responses for predictable testing\n4. Implement test fixtures and mocks for consistent testing\n5. Add performance tests to ensure the command is efficient\n6. Test edge cases such as empty tasks, tasks with many subtasks, etc.\n\nTesting approach:\n- Use Jest or similar testing framework\n- Implement mocks for external dependencies like AI services\n- Create test fixtures for consistent test data\n- Use snapshot testing for command output verification",
"status": "in-progress",
"parentTaskId": 34
},
{
"id": 5,
"title": "Update CLI documentation and help text",
"description": "Update the CLI help documentation to include the new updateTask command and ensure users understand its purpose and options.",
"dependencies": [
2
],
"details": "Implementation steps:\n1. Add comprehensive help text for the updateTask command including:\n - Command description\n - Required and optional parameters\n - Examples of usage\n - Description of all supported options\n2. Update the main CLI help documentation to include the new command\n3. Add the command to any relevant command groups or categories\n4. Create usage examples that demonstrate common scenarios\n5. Update README.md and other documentation files to include information about the new command\n6. Add inline code comments explaining the implementation details\n7. Update any API documentation if applicable\n8. Create or update user guides with the new functionality\n\nTesting approach:\n- Verify help text is displayed correctly when running `--help`\n- Review documentation for clarity and completeness\n- Have team members review the documentation for usability\n- Test examples to ensure they work as documented",
"status": "pending",
"parentTaskId": 34
}
]
},
{
"id": 35,
"title": "Integrate Grok3 API for Research Capabilities",
"description": "Replace the current Perplexity API integration with Grok3 API for all research-related functionalities while maintaining existing feature parity.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"details": "This task involves migrating from Perplexity to Grok3 API for research capabilities throughout the application. Implementation steps include:\n\n1. Create a new API client module for Grok3 in `src/api/grok3.ts` that handles authentication, request formatting, and response parsing\n2. Update the research service layer to use the new Grok3 client instead of Perplexity\n3. Modify the request payload structure to match Grok3's expected format (parameters like temperature, max_tokens, etc.)\n4. Update response handling to properly parse and extract Grok3's response format\n5. Implement proper error handling for Grok3-specific error codes and messages\n6. Update environment variables and configuration files to include Grok3 API keys and endpoints\n7. Ensure rate limiting and quota management are properly implemented according to Grok3's specifications\n8. Update any UI components that display research provider information to show Grok3 instead of Perplexity\n9. Maintain backward compatibility for any stored research results from Perplexity\n10. Document the new API integration in the developer documentation\n\nGrok3 API has different parameter requirements and response formats compared to Perplexity, so careful attention must be paid to these differences during implementation.",
"testStrategy": "Testing should verify that the Grok3 API integration works correctly and maintains feature parity with the previous Perplexity implementation:\n\n1. Unit tests:\n - Test the Grok3 API client with mocked responses\n - Verify proper error handling for various error scenarios (rate limits, authentication failures, etc.)\n - Test the transformation of application requests to Grok3-compatible format\n\n2. Integration tests:\n - Perform actual API calls to Grok3 with test credentials\n - Verify that research results are correctly parsed and returned\n - Test with various types of research queries to ensure broad compatibility\n\n3. End-to-end tests:\n - Test the complete research flow from UI input to displayed results\n - Verify that all existing research features work with the new API\n\n4. Performance tests:\n - Compare response times between Perplexity and Grok3\n - Ensure the application handles any differences in response time appropriately\n\n5. Regression tests:\n - Verify that existing features dependent on research capabilities continue to work\n - Test that stored research results from Perplexity are still accessible and displayed correctly\n\nCreate a test environment with both APIs available to compare results and ensure quality before fully replacing Perplexity with Grok3."
},
{
"id": 36,
"title": "Add Ollama Support for AI Services as Claude Alternative",
"description": "Implement Ollama integration as an alternative to Claude for all main AI services, allowing users to run local language models instead of relying on cloud-based Claude API.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"details": "This task involves creating a comprehensive Ollama integration that can replace Claude across all main AI services in the application. Implementation should include:\n\n1. Create an OllamaService class that implements the same interface as the ClaudeService to ensure compatibility\n2. Add configuration options to specify Ollama endpoint URL (default: http://localhost:11434)\n3. Implement model selection functionality to allow users to choose which Ollama model to use (e.g., llama3, mistral, etc.)\n4. Handle prompt formatting specific to Ollama models, ensuring proper system/user message separation\n5. Implement proper error handling for cases where Ollama server is unavailable or returns errors\n6. Add fallback mechanism to Claude when Ollama fails or isn't configured\n7. Update the AI service factory to conditionally create either Claude or Ollama service based on configuration\n8. Ensure token counting and rate limiting are appropriately handled for Ollama models\n9. Add documentation for users explaining how to set up and use Ollama with the application\n10. Optimize prompt templates specifically for Ollama models if needed\n\nThe implementation should be toggled through a configuration option (useOllama: true/false) and should maintain all existing functionality currently provided by Claude.",
"testStrategy": "Testing should verify that Ollama integration works correctly as a drop-in replacement for Claude:\n\n1. Unit tests:\n - Test OllamaService class methods in isolation with mocked responses\n - Verify proper error handling when Ollama server is unavailable\n - Test fallback mechanism to Claude when configured\n\n2. Integration tests:\n - Test with actual Ollama server running locally with at least two different models\n - Verify all AI service functions work correctly with Ollama\n - Compare outputs between Claude and Ollama for quality assessment\n\n3. Configuration tests:\n - Verify toggling between Claude and Ollama works as expected\n - Test with various model configurations\n\n4. Performance tests:\n - Measure and compare response times between Claude and Ollama\n - Test with different load scenarios\n\n5. Manual testing:\n - Verify all main AI features work correctly with Ollama\n - Test edge cases like very long inputs or specialized tasks\n\nCreate a test document comparing output quality between Claude and various Ollama models to help users understand the tradeoffs."
},
{
"id": 37,
"title": "Add Gemini Support for Main AI Services as Claude Alternative",
"description": "Implement Google's Gemini API integration as an alternative to Claude for all main AI services, allowing users to switch between different LLM providers.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"details": "This task involves integrating Google's Gemini API across all main AI services that currently use Claude:\n\n1. Create a new GeminiService class that implements the same interface as the existing ClaudeService\n2. Implement authentication and API key management for Gemini API\n3. Map our internal prompt formats to Gemini's expected input format\n4. Handle Gemini-specific parameters (temperature, top_p, etc.) and response parsing\n5. Update the AI service factory/provider to support selecting Gemini as an alternative\n6. Add configuration options in settings to allow users to select Gemini as their preferred provider\n7. Implement proper error handling for Gemini-specific API errors\n8. Ensure streaming responses are properly supported if Gemini offers this capability\n9. Update documentation to reflect the new Gemini option\n10. Consider implementing model selection if Gemini offers multiple models (e.g., Gemini Pro, Gemini Ultra)\n11. Ensure all existing AI capabilities (summarization, code generation, etc.) maintain feature parity when using Gemini\n\nThe implementation should follow the same pattern as the recent Ollama integration (Task #36) to maintain consistency in how alternative AI providers are supported.",
"testStrategy": "Testing should verify Gemini integration works correctly across all AI services:\n\n1. Unit tests:\n - Test GeminiService class methods with mocked API responses\n - Verify proper error handling for common API errors\n - Test configuration and model selection functionality\n\n2. Integration tests:\n - Verify authentication and API connection with valid credentials\n - Test each AI service with Gemini to ensure proper functionality\n - Compare outputs between Claude and Gemini for the same inputs to verify quality\n\n3. End-to-end tests:\n - Test the complete user flow of switching to Gemini and using various AI features\n - Verify streaming responses work correctly if supported\n\n4. Performance tests:\n - Measure and compare response times between Claude and Gemini\n - Test with various input lengths to verify handling of context limits\n\n5. Manual testing:\n - Verify the quality of Gemini responses across different use cases\n - Test edge cases like very long inputs or specialized domain knowledge\n\nAll tests should pass with Gemini selected as the provider, and the user experience should be consistent regardless of which provider is selected."
}
]
}