fix(move-task): Update move functionality for tagged task system compatibility
- incorporate GitHub commit fixes and resolve readJSON data handling
This commit is contained in:
File diff suppressed because it is too large
Load Diff
94
.taskmaster/tasks/task_092.txt
Normal file
94
.taskmaster/tasks/task_092.txt
Normal file
@@ -0,0 +1,94 @@
|
||||
# Task ID: 92
|
||||
# Title: Implement Project Root Environment Variable Support in MCP Configuration
|
||||
# Status: review
|
||||
# Dependencies: 1, 3, 17
|
||||
# Priority: medium
|
||||
# Description: Add support for a 'TASK_MASTER_PROJECT_ROOT' environment variable in MCP configuration, allowing it to be set in both mcp.json and .env, with precedence over other methods. This will define the root directory for the MCP server and take precedence over all other project root resolution methods. The implementation should be backward compatible with existing workflows that don't use this variable.
|
||||
# Details:
|
||||
Update the MCP server configuration system to support the TASK_MASTER_PROJECT_ROOT environment variable as the standard way to specify the project root directory. This provides better namespacing and avoids conflicts with other tools that might use a generic PROJECT_ROOT variable. Implement a clear precedence order for project root resolution:
|
||||
|
||||
1. TASK_MASTER_PROJECT_ROOT environment variable (from shell or .env file)
|
||||
2. 'projectRoot' key in mcp_config.toml or mcp.json configuration files
|
||||
3. Existing resolution logic (CLI args, current working directory, etc.)
|
||||
|
||||
Modify the configuration loading logic to check for these sources in the specified order, ensuring backward compatibility. All MCP tools and components should use this standardized project root resolution logic. The TASK_MASTER_PROJECT_ROOT environment variable will be required because path resolution is delegated to the MCP client implementation, ensuring consistent behavior across different environments.
|
||||
|
||||
Implementation steps:
|
||||
1. Identify all code locations where project root is determined (initialization, utility functions)
|
||||
2. Update configuration loaders to check for TASK_MASTER_PROJECT_ROOT in environment variables
|
||||
3. Add support for 'projectRoot' in configuration files as a fallback
|
||||
4. Refactor project root resolution logic to follow the new precedence rules
|
||||
5. Ensure all MCP tools and functions use the updated resolution logic
|
||||
6. Add comprehensive error handling for cases where TASK_MASTER_PROJECT_ROOT is not set or invalid
|
||||
7. Implement validation to ensure the specified directory exists and is accessible
|
||||
|
||||
# Test Strategy:
|
||||
1. Write unit tests to verify that the config loader correctly reads project root from environment variables and configuration files with the expected precedence:
|
||||
- Test TASK_MASTER_PROJECT_ROOT environment variable takes precedence when set
|
||||
- Test 'projectRoot' in configuration files is used when environment variable is absent
|
||||
- Test fallback to existing resolution logic when neither is specified
|
||||
|
||||
2. Add integration tests to ensure that the MCP server and all tools use the correct project root:
|
||||
- Test server startup with TASK_MASTER_PROJECT_ROOT set to various valid and invalid paths
|
||||
- Test configuration file loading from the specified project root
|
||||
- Test path resolution for resources relative to the project root
|
||||
|
||||
3. Test backward compatibility:
|
||||
- Verify existing workflows function correctly without the new variables
|
||||
- Ensure no regression in projects not using the new configuration options
|
||||
|
||||
4. Manual testing:
|
||||
- Set TASK_MASTER_PROJECT_ROOT in shell environment and verify correct behavior
|
||||
- Set TASK_MASTER_PROJECT_ROOT in .env file and verify it's properly loaded
|
||||
- Configure 'projectRoot' in configuration files and test precedence
|
||||
- Test with invalid or non-existent directories to verify error handling
|
||||
|
||||
# Subtasks:
|
||||
## 1. Update configuration loader to check for TASK_MASTER_PROJECT_ROOT environment variable [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify the configuration loading system to check for the TASK_MASTER_PROJECT_ROOT environment variable as the primary source for project root directory. Ensure proper error handling if the variable is set but points to a non-existent or inaccessible directory.
|
||||
### Details:
|
||||
|
||||
|
||||
## 2. Add support for 'projectRoot' in configuration files [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement support for a 'projectRoot' key in mcp_config.toml and mcp.json configuration files as a fallback when the environment variable is not set. Update the configuration parser to recognize and validate this field.
|
||||
### Details:
|
||||
|
||||
|
||||
## 3. Refactor project root resolution logic with clear precedence rules [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a unified project root resolution function that follows the precedence order: 1) TASK_MASTER_PROJECT_ROOT environment variable, 2) 'projectRoot' in config files, 3) existing resolution methods. Ensure this function is used consistently throughout the codebase.
|
||||
### Details:
|
||||
|
||||
|
||||
## 4. Update all MCP tools to use the new project root resolution [pending]
|
||||
### Dependencies: None
|
||||
### Description: Identify all MCP tools and components that need to access the project root and update them to use the new resolution logic. Ensure consistent behavior across all parts of the system.
|
||||
### Details:
|
||||
|
||||
|
||||
## 5. Add comprehensive tests for the new project root resolution [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create unit and integration tests to verify the correct behavior of the project root resolution logic under various configurations and edge cases.
|
||||
### Details:
|
||||
|
||||
|
||||
## 6. Update documentation with new configuration options [pending]
|
||||
### Dependencies: None
|
||||
### Description: Update the project documentation to clearly explain the new TASK_MASTER_PROJECT_ROOT environment variable, the 'projectRoot' configuration option, and the precedence rules. Include examples of different configuration scenarios.
|
||||
### Details:
|
||||
|
||||
|
||||
## 7. Implement validation for project root directory [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add validation to ensure the specified project root directory exists and has the necessary permissions. Provide clear error messages when validation fails.
|
||||
### Details:
|
||||
|
||||
|
||||
## 8. Implement support for loading environment variables from .env files [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add functionality to load the TASK_MASTER_PROJECT_ROOT variable from .env files in the workspace, following best practices for environment variable management in MCP servers.
|
||||
### Details:
|
||||
|
||||
|
||||
55
.taskmaster/tasks/task_093.txt
Normal file
55
.taskmaster/tasks/task_093.txt
Normal file
@@ -0,0 +1,55 @@
|
||||
# Task ID: 93
|
||||
# Title: Implement Google Vertex AI Provider Integration
|
||||
# Status: done
|
||||
# Dependencies: 19, 94
|
||||
# Priority: medium
|
||||
# Description: Develop a dedicated Google Vertex AI provider in the codebase, enabling users to leverage Vertex AI models with enterprise-grade configuration and authentication.
|
||||
# Details:
|
||||
1. Create a new provider class in `src/ai-providers/google-vertex.js` that extends the existing BaseAIProvider, following the established structure used by other providers (e.g., google.js, openai.js).
|
||||
2. Integrate the Vercel AI SDK's `@ai-sdk/google-vertex` package. Use the default `vertex` provider for standard usage, and allow for custom configuration via `createVertex` for advanced scenarios (e.g., specifying project ID, location, and credentials).
|
||||
3. Implement all required interface methods (such as `getClient`, `generateText`, etc.) to ensure compatibility with the provider system. Reference the implementation patterns from other providers for consistency.
|
||||
4. Handle Vertex AI-specific configuration, including project ID, location, and Google Cloud authentication. Support both environment-based authentication and explicit service account credentials via `googleAuthOptions`.
|
||||
5. Implement robust error handling for Vertex-specific issues, including authentication failures and API errors, leveraging the system-wide error handling patterns.
|
||||
6. Update `src/ai-providers/index.js` to export the new provider, and add the 'vertex' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`.
|
||||
7. Update documentation to provide clear setup instructions for Google Vertex AI, including required environment variables, service account setup, and configuration examples.
|
||||
8. Ensure the implementation is modular and maintainable, supporting future expansion for additional Vertex AI features or models.
|
||||
|
||||
# Test Strategy:
|
||||
- Write unit tests for the new provider class, covering all interface methods and configuration scenarios (default, custom, error cases).
|
||||
- Verify that the provider can successfully authenticate using both environment-based and explicit service account credentials.
|
||||
- Test integration with the provider system by selecting 'vertex' as the provider and generating text using supported Vertex AI models (e.g., Gemini).
|
||||
- Simulate authentication and API errors to confirm robust error handling and user feedback.
|
||||
- Confirm that the provider is correctly exported and available in the PROVIDERS object.
|
||||
- Review and validate the updated documentation for accuracy and completeness.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Google Vertex AI Provider Class [done]
|
||||
### Dependencies: None
|
||||
### Description: Develop a new provider class in `src/ai-providers/google-vertex.js` that extends the BaseAIProvider, following the structure of existing providers.
|
||||
### Details:
|
||||
Ensure the new class is consistent with the architecture of other providers such as google.js and openai.js, and is ready to integrate with the AI SDK.
|
||||
|
||||
## 2. Integrate Vercel AI SDK Google Vertex Package [done]
|
||||
### Dependencies: 93.1
|
||||
### Description: Integrate the `@ai-sdk/google-vertex` package, supporting both the default provider and custom configuration via `createVertex`.
|
||||
### Details:
|
||||
Allow for standard usage with the default `vertex` provider and advanced scenarios using `createVertex` for custom project ID, location, and credentials as per SDK documentation.
|
||||
|
||||
## 3. Implement Provider Interface Methods [done]
|
||||
### Dependencies: 93.2
|
||||
### Description: Implement all required interface methods (e.g., `getClient`, `generateText`) to ensure compatibility with the provider system.
|
||||
### Details:
|
||||
Reference implementation patterns from other providers to maintain consistency and ensure all required methods are present and functional.
|
||||
|
||||
## 4. Handle Vertex AI Configuration and Authentication [done]
|
||||
### Dependencies: 93.3
|
||||
### Description: Implement support for Vertex AI-specific configuration, including project ID, location, and authentication via environment variables or explicit service account credentials.
|
||||
### Details:
|
||||
Support both environment-based authentication and explicit credentials using `googleAuthOptions`, following Google Cloud and Vertex AI setup best practices.
|
||||
|
||||
## 5. Update Exports, Documentation, and Error Handling [done]
|
||||
### Dependencies: 93.4
|
||||
### Description: Export the new provider, update the PROVIDERS object, and document setup instructions, including robust error handling for Vertex-specific issues.
|
||||
### Details:
|
||||
Update `src/ai-providers/index.js` and `scripts/modules/ai-services-unified.js`, and provide clear documentation for setup, configuration, and error handling patterns.
|
||||
|
||||
103
.taskmaster/tasks/task_094.txt
Normal file
103
.taskmaster/tasks/task_094.txt
Normal file
@@ -0,0 +1,103 @@
|
||||
# Task ID: 94
|
||||
# Title: Implement Azure OpenAI Provider Integration
|
||||
# Status: done
|
||||
# Dependencies: 19, 26
|
||||
# Priority: medium
|
||||
# Description: Create a comprehensive Azure OpenAI provider implementation that integrates with the existing AI provider system, enabling users to leverage Azure-hosted OpenAI models through proper authentication and configuration.
|
||||
# Details:
|
||||
Implement the Azure OpenAI provider following the established provider pattern:
|
||||
|
||||
1. **Create Azure Provider Class** (`src/ai-providers/azure.js`):
|
||||
- Extend BaseAIProvider class following the same pattern as openai.js and google.js
|
||||
- Import and use `createAzureOpenAI` from `@ai-sdk/azure` package
|
||||
- Implement required interface methods: `getClient()`, `validateConfig()`, and any other abstract methods
|
||||
- Handle Azure-specific configuration: endpoint URL, API key, and deployment name
|
||||
- Add proper error handling for missing or invalid Azure configuration
|
||||
|
||||
2. **Configuration Management**:
|
||||
- Support environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, AZURE_OPENAI_DEPLOYMENT
|
||||
- Validate that both endpoint and API key are provided
|
||||
- Provide clear error messages for configuration issues
|
||||
- Follow the same configuration pattern as other providers
|
||||
|
||||
3. **Integration Updates**:
|
||||
- Update `src/ai-providers/index.js` to export the new AzureProvider
|
||||
- Add 'azure' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`
|
||||
- Ensure the provider is properly registered and accessible through the unified AI services
|
||||
|
||||
4. **Error Handling**:
|
||||
- Implement Azure-specific error handling for authentication failures
|
||||
- Handle endpoint connectivity issues with helpful error messages
|
||||
- Validate deployment name and provide guidance for common configuration mistakes
|
||||
- Follow the established error handling patterns from Task 19
|
||||
|
||||
5. **Documentation Updates**:
|
||||
- Update any provider documentation to include Azure OpenAI setup instructions
|
||||
- Add configuration examples for Azure OpenAI environment variables
|
||||
- Include troubleshooting guidance for common Azure-specific issues
|
||||
|
||||
The implementation should maintain consistency with existing provider implementations while handling Azure's unique authentication and endpoint requirements.
|
||||
|
||||
# Test Strategy:
|
||||
Verify the Azure OpenAI provider implementation through comprehensive testing:
|
||||
|
||||
1. **Unit Testing**:
|
||||
- Test provider class instantiation and configuration validation
|
||||
- Verify getClient() method returns properly configured Azure OpenAI client
|
||||
- Test error handling for missing/invalid configuration parameters
|
||||
- Validate that the provider correctly extends BaseAIProvider
|
||||
|
||||
2. **Integration Testing**:
|
||||
- Test provider registration in the unified AI services system
|
||||
- Verify the provider appears in the PROVIDERS object and is accessible
|
||||
- Test end-to-end functionality with valid Azure OpenAI credentials
|
||||
- Validate that the provider works with existing AI operation workflows
|
||||
|
||||
3. **Configuration Testing**:
|
||||
- Test with various environment variable combinations
|
||||
- Verify proper error messages for missing endpoint or API key
|
||||
- Test with invalid endpoint URLs and ensure graceful error handling
|
||||
- Validate deployment name handling and error reporting
|
||||
|
||||
4. **Manual Verification**:
|
||||
- Set up test Azure OpenAI credentials and verify successful connection
|
||||
- Test actual AI operations (like task expansion) using the Azure provider
|
||||
- Verify that the provider selection works correctly in the CLI
|
||||
- Confirm that error messages are helpful and actionable for users
|
||||
|
||||
5. **Documentation Verification**:
|
||||
- Ensure all configuration examples work as documented
|
||||
- Verify that setup instructions are complete and accurate
|
||||
- Test troubleshooting guidance with common error scenarios
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Azure Provider Class [done]
|
||||
### Dependencies: None
|
||||
### Description: Implement the AzureProvider class that extends BaseAIProvider to handle Azure OpenAI integration
|
||||
### Details:
|
||||
Create the AzureProvider class in src/ai-providers/azure.js that extends BaseAIProvider. Import createAzureOpenAI from @ai-sdk/azure package. Implement required interface methods including getClient() and validateConfig(). Handle Azure-specific configuration parameters: endpoint URL, API key, and deployment name. Follow the established pattern in openai.js and google.js. Ensure proper error handling for missing or invalid configuration.
|
||||
|
||||
## 2. Implement Configuration Management [done]
|
||||
### Dependencies: 94.1
|
||||
### Description: Add support for Azure OpenAI environment variables and configuration validation
|
||||
### Details:
|
||||
Implement configuration management for Azure OpenAI provider that supports environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, and AZURE_OPENAI_DEPLOYMENT. Add validation logic to ensure both endpoint and API key are provided. Create clear error messages for configuration issues. Follow the same configuration pattern as implemented in other providers. Ensure the validateConfig() method properly checks all required Azure configuration parameters.
|
||||
|
||||
## 3. Update Provider Integration [done]
|
||||
### Dependencies: 94.1, 94.2
|
||||
### Description: Integrate the Azure provider into the existing AI provider system
|
||||
### Details:
|
||||
Update src/ai-providers/index.js to export the new AzureProvider class. Add 'azure' entry to the PROVIDERS object in scripts/modules/ai-services-unified.js. Ensure the provider is properly registered and accessible through the unified AI services. Test that the provider can be instantiated and used through the provider selection mechanism. Follow the same integration pattern used for existing providers.
|
||||
|
||||
## 4. Implement Azure-Specific Error Handling [done]
|
||||
### Dependencies: 94.1, 94.2
|
||||
### Description: Add specialized error handling for Azure OpenAI-specific issues
|
||||
### Details:
|
||||
Implement Azure-specific error handling for authentication failures, endpoint connectivity issues, and deployment name validation. Provide helpful error messages that guide users to resolve common configuration mistakes. Follow the established error handling patterns from Task 19. Create custom error classes if needed for Azure-specific errors. Ensure errors are properly propagated and formatted for user display.
|
||||
|
||||
## 5. Update Documentation [done]
|
||||
### Dependencies: 94.1, 94.2, 94.3, 94.4
|
||||
### Description: Create comprehensive documentation for the Azure OpenAI provider integration
|
||||
### Details:
|
||||
Update provider documentation to include Azure OpenAI setup instructions. Add configuration examples for Azure OpenAI environment variables. Include troubleshooting guidance for common Azure-specific issues. Document the required Azure resource creation process with references to Microsoft's documentation. Provide examples of valid configuration settings and explain each required parameter. Include information about Azure OpenAI model deployment requirements.
|
||||
|
||||
@@ -24,3 +24,11 @@
|
||||
- Verify that historical data is preserved and that before/after summaries are accurate and clear.
|
||||
- Confirm that task dependencies remain intact and that batch operations work as intended.
|
||||
- Validate MCP tool integration and documentation updates.
|
||||
|
||||
# Subtasks:
|
||||
## 2. Set up Authentication System and User Management Backend [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement the complete authentication infrastructure including user registration, login, password reset, and session management with database schema and API endpoints.
|
||||
### Details:
|
||||
Create user database schema with fields for id, email, password_hash, name, bio, avatar_url, created_at, updated_at. Implement JWT-based authentication with refresh tokens. Set up API endpoints for /auth/register, /auth/login, /auth/logout, /auth/refresh, /auth/forgot-password, /auth/reset-password, /auth/verify-email. Include password hashing with bcrypt, email verification system, and role-based access control with user roles (admin, user). Implement middleware for route protection and session validation.
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
33538
.taskmaster/tasks/tasks.json.bak
Normal file
33538
.taskmaster/tasks/tasks.json.bak
Normal file
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user