|
|
|
|
@@ -6573,11 +6573,69 @@
|
|
|
|
|
"testStrategy": "Test error handling by simulating various failure conditions. Verify that appropriate error messages are displayed. Test MCP tool integration and ensure consistent behavior between CLI and MCP interfaces. Perform end-to-end testing with real tasks to verify the complete workflow."
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"id": 105,
|
|
|
|
|
"title": "Implement Code Context Analysis for Task Generation",
|
|
|
|
|
"description": "Create a module that analyzes the project codebase to provide relevant context when generating new tasks, enhancing task quality with code-aware suggestions.",
|
|
|
|
|
"status": "pending",
|
|
|
|
|
"dependencies": [
|
|
|
|
|
17,
|
|
|
|
|
19,
|
|
|
|
|
94
|
|
|
|
|
],
|
|
|
|
|
"priority": "medium",
|
|
|
|
|
"details": "This task involves implementing a CodeContextAnalyzer module that follows the same architectural patterns as the existing ConfigManager at `scripts/modules/config-manager.js`. After analyzing the ConfigManager, here's how it works and what patterns should be adopted:\n\n## How ConfigManager Works (scripts/modules/config-manager.js)\n\nThe ConfigManager is a sophisticated configuration management system with these key components:\n\n**1. Configuration Loading & Caching:**\n- Uses a global cache (`loadedConfig`, `loadedConfigRoot`) to avoid repeated file reads\n- Implements `_loadAndValidateConfig()` for the core loading logic with intelligent root detection\n- Falls back gracefully through: explicit root → findProjectRoot() → process.cwd()\n- Supports both new (.taskmaster/config.json) and legacy (taskmaster.config.json) locations\n\n**2. Validation & Error Handling:**\n- Uses Zod schemas for structured validation (especially for Claude Code settings)\n- Implements custom ConfigurationError class for specific error types\n- Validates providers against MODEL_MAP loaded from supported-models.json\n- Graceful degradation: warns about issues but continues with defaults\n\n**3. API Design Patterns:**\n- Role-specific getters: `getMainProvider()`, `getResearchProvider()`, `getFallbackProvider()`\n- Parameter-specific getters: `getMainMaxTokens()`, `getResearchTemperature()`\n- Generic getters with role parameter: `getModelConfigForRole(role, explicitRoot)`\n- Deep merging of defaults with loaded config using spread operators\n\n**4. Environment Integration:**\n- Resolves environment variables via `resolveEnvVariable()` utility\n- Supports multiple environment contexts (process.env, session.env, .env files)\n- API key validation across multiple providers with placeholder detection\n\n**5. Performance Optimizations:**\n- Lazy loading of configuration files only when project markers exist\n- Caching with invalidation based on explicitRoot changes\n- Model-specific parameter overrides from MODEL_MAP for efficiency\n\n## CodeContextAnalyzer Implementation Plan\n\nFollowing these ConfigManager patterns, implement:\n\n**1. Core Module Structure (`src/utils/CodeContextAnalyzer.js`):**\n```javascript\n// Similar imports and structure as ConfigManager\nimport fs from 'fs';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\nimport { z } from 'zod';\n\n// Global cache variables (like ConfigManager)\nlet loadedContext = null;\nlet loadedContextRoot = null;\n\n// Main context loading function (mirrors _loadAndValidateConfig pattern)\nfunction _loadAndAnalyzeContext(explicitRoot = null) {\n // Follow ConfigManager's root resolution logic\n // Implement caching similar to ConfigManager\n}\n\n// Public API following ConfigManager getter patterns\nexport function getCodeContext(explicitRoot = null, forceReload = false) {\n // Mirror getConfig() caching logic\n}\n```\n\n**2. Context Analysis Capabilities:**\n- File structure scanning with configurable ignore patterns (like node_modules)\n- Package.json dependency analysis using ConfigManager's JSON parsing patterns \n- AST parsing with lazy loading of heavy parsing libraries\n- Function/class/module identification with validation schemas\n- Caching mechanism following ConfigManager's cache invalidation patterns\n\n**3. Integration Points:**\n- Add `--context` flag to task creation commands (similar to ConfigManager's role-specific flags)\n- Context relevance scoring algorithm with configurable thresholds\n- Integration with existing task generation workflow using ConfigManager's merge patterns\n\n**4. Configuration & Validation:**\n- Use Zod schemas for context analyzer settings validation (like validateClaudeCodeSettings)\n- Support configuration options for analysis depth, ignore patterns, cache settings\n- Follow ConfigManager's graceful degradation patterns for malformed code files\n\n**5. Performance Considerations:**\n- Implement file change detection and selective re-analysis\n- Use ConfigManager's lazy loading patterns for expensive operations\n- Cache analysis results with TTL similar to ConfigManager's cache strategy",
|
|
|
|
|
"testStrategy": "Testing should verify both the analysis capabilities and integration with task generation, following ConfigManager's testing patterns:\n\n1. **Unit Tests (mirror ConfigManager validation tests):**\n - Test context loading with various project structures (like ConfigManager's root detection tests)\n - Verify caching mechanism matches ConfigManager's cache behavior\n - Test file scanning with mock directory structures\n - Verify AST parsing with sample code files using validation patterns from ConfigManager\n - Test context relevance scoring algorithm with known inputs\n - Test graceful degradation following ConfigManager's error handling patterns\n\n2. **Integration Tests (following ConfigManager's integration patterns):**\n - Test end-to-end context-aware task creation workflow\n - Verify context merging follows ConfigManager's deep merge patterns\n - Test with various project structures and configurations\n - Performance testing with larger codebases using ConfigManager's optimization strategies\n\n3. **Validation Tests (using ConfigManager's validation approach):**\n - Test Zod schema validation for context analyzer configuration\n - Test error handling for malformed or unusual code structures\n - Verify API key-style checks for required analysis dependencies\n - Test configuration migration paths similar to ConfigManager's legacy support\n\n4. **Edge Case Testing (following ConfigManager's robustness patterns):**\n - Test behavior with empty files or directories (like ConfigManager's empty config handling)\n - Test graceful degradation when analysis fails (mirror ConfigManager's fallback behavior)\n - Test performance with very large files using ConfigManager's optimization techniques\n - Verify cache invalidation works correctly across different project roots",
|
|
|
|
|
"subtasks": [
|
|
|
|
|
{
|
|
|
|
|
"id": 1,
|
|
|
|
|
"title": "Study ConfigManager Architecture and Patterns",
|
|
|
|
|
"description": "Analyze the ConfigManager module at scripts/modules/config-manager.js to understand its caching, validation, error handling, and API design patterns that should be replicated in the CodeContextAnalyzer.",
|
|
|
|
|
"status": "pending",
|
|
|
|
|
"dependencies": [],
|
|
|
|
|
"details": "Deep dive into ConfigManager's architecture at scripts/modules/config-manager.js to understand:\n\n**Caching Strategy:**\n- Global cache variables: `loadedConfig`, `loadedConfigRoot` (lines 81-82)\n- Cache invalidation logic in `getConfig()` function (lines 250-272)\n- When to reload vs use cached values based on explicitRoot changes\n\n**Configuration Loading Patterns:**\n- `_loadAndValidateConfig()` core loading function (lines 92-241)\n- Root path resolution logic: explicitRoot → findProjectRoot() → process.cwd() (lines 99-111)\n- Deep merging of defaults with loaded config (lines 138-153)\n- Support for both new and legacy config locations (lines 129-132)\n\n**Validation & Error Handling:**\n- Custom ConfigurationError class (lines 85-90)\n- Provider validation using MODEL_MAP (lines 281-294)\n- Zod schema validation for complex settings (lines 321-373)\n- Graceful degradation with warnings vs hard failures\n\n**API Design Patterns:**\n- Role-specific getters: getMainProvider(), getResearchProvider() (lines 408-441)\n- Generic role-based getter: getModelConfigForRole() (lines 395-406)\n- Parameter-specific getters with fallbacks (lines 412-475)\n- Consistent explicitRoot parameter handling across all functions\n\nDocument these patterns with specific line references and code examples.",
|
|
|
|
|
"testStrategy": "Create comprehensive documentation of ConfigManager patterns with code snippets and line references. Have the documentation reviewed for accuracy and completeness by team members familiar with the ConfigManager implementation."
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"id": 2,
|
|
|
|
|
"title": "Create CodeContextAnalyzer Module Skeleton",
|
|
|
|
|
"description": "Create the basic module structure for CodeContextAnalyzer following ConfigManager's patterns including imports, cache variables, error classes, and core function signatures.",
|
|
|
|
|
"status": "pending",
|
|
|
|
|
"dependencies": [
|
|
|
|
|
1
|
|
|
|
|
],
|
|
|
|
|
"details": "Create `src/utils/CodeContextAnalyzer.js` with structure matching ConfigManager:\n\n**Module Setup (following lines 1-42 of ConfigManager):**\n- Import statements: fs, path, fileURLToPath, chalk, z (Zod)\n- Constants for analysis configuration (similar to DEFAULTS on lines 43-78)\n- Global cache variables: `loadedContext`, `loadedContextRoot` (mirroring lines 81-82)\n- Load analysis configuration from JSON file (similar to MODEL_MAP loading lines 25-41)\n\n**Error Handling (following lines 85-90):**\n- Custom ContextAnalysisError class\n- Error types for different analysis failures\n\n**Core Function Signatures (matching ConfigManager patterns):**\n- `_loadAndAnalyzeContext(explicitRoot = null)` - core analysis function\n- `getCodeContext(explicitRoot = null, forceReload = false)` - public API\n- Validation functions following validateProvider pattern (lines 281-294)\n- Getter functions following role-specific pattern (lines 408-441)\n\n**Configuration Defaults:**\n- Analysis depth settings\n- File type patterns to analyze\n- Ignore patterns (node_modules, .git, etc.)\n- Cache settings and TTL values\n- Performance thresholds\n\nEnsure all function signatures match ConfigManager's parameter patterns and naming conventions.",
|
|
|
|
|
"testStrategy": "Test module imports correctly, cache variables initialize properly, error classes work as expected, and all core functions can be called without errors. Verify the module structure matches ConfigManager's organization."
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"id": 3,
|
|
|
|
|
"title": "Implement Context Caching System",
|
|
|
|
|
"description": "Implement the caching mechanism for code context analysis following ConfigManager's caching patterns, including cache invalidation, root-based caching, and performance optimizations.",
|
|
|
|
|
"status": "pending",
|
|
|
|
|
"dependencies": [
|
|
|
|
|
2
|
|
|
|
|
],
|
|
|
|
|
"details": "Implement caching system based on ConfigManager's patterns:\n\n**Cache Management (following lines 250-272 of ConfigManager):**\n- Implement cache invalidation logic similar to `getConfig()`\n- Root-based cache tracking following `loadedConfigRoot` pattern\n- Force reload mechanism matching ConfigManager's forceReload parameter\n\n**Context Loading (following _loadAndValidateConfig pattern lines 92-241):**\n- File system scanning with project marker detection (similar to lines 119-127)\n- Root path resolution using same logic as ConfigManager (lines 99-111)\n- Analysis result merging and validation\n- Error handling with warnings vs failures\n\n**Performance Optimizations:**\n- File modification time tracking for selective re-analysis\n- Lazy loading of expensive analysis operations\n- Configurable analysis depth to control performance\n- Memory-efficient storage of analysis results\n\n**Cache Invalidation Triggers:**\n- File system changes in analyzed directories\n- Configuration changes to analysis settings\n- Project root changes\n- Manual force reload requests\n\nImplement cache persistence to disk for large projects following ConfigManager's file I/O patterns.",
|
|
|
|
|
"testStrategy": "Test cache invalidation works correctly when files change, project root changes, or force reload is requested. Verify cache performance with large codebases and ensure cache persistence survives application restarts. Test memory usage remains reasonable with large projects."
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"id": 4,
|
|
|
|
|
"title": "Implement File System Analysis with ConfigManager Patterns",
|
|
|
|
|
"description": "Implement file system scanning and analysis capabilities using ConfigManager's robust file handling, error management, and validation patterns.",
|
|
|
|
|
"status": "pending",
|
|
|
|
|
"dependencies": [
|
|
|
|
|
3
|
|
|
|
|
],
|
|
|
|
|
"details": "Implement file system analysis following ConfigManager's file handling patterns:\n\n**File Discovery (following ConfigManager's config file discovery lines 113-127):**\n- Project structure scanning with ignore pattern support\n- File type detection and filtering\n- Recursive directory traversal with depth limits\n- Support for .gitignore-style ignore patterns\n\n**File Analysis (using ConfigManager's JSON parsing approach lines 133-154):**\n- AST parsing for JavaScript/TypeScript files\n- Package.json dependency extraction (similar to ConfigManager's JSON parsing)\n- Configuration file analysis (following ConfigManager's config parsing patterns)\n- Function/class/module identification\n\n**Error Handling (following ConfigManager's error patterns lines 198-207):**\n- Graceful handling of malformed files\n- Warnings for analysis failures without stopping the process\n- Fallback behavior when parsing fails\n- Detailed error reporting with file paths and line numbers\n\n**Validation (using ConfigManager's validation approach lines 167-197):**\n- File content validation before analysis\n- Analysis result validation using Zod schemas\n- Provider-style validation for analysis plugins\n- Configuration validation for analysis settings\n\n**Integration with ConfigManager utilities:**\n- Use findProjectRoot() for consistent project detection\n- Leverage resolveEnvVariable() for configuration overrides\n- Follow ConfigManager's path resolution patterns\n- Use ConfigManager's logging patterns for consistency",
|
|
|
|
|
"testStrategy": "Test file system scanning with various project structures and ignore patterns. Verify AST parsing handles malformed code gracefully. Test error handling matches ConfigManager's robustness. Verify analysis results are validated correctly and integration with ConfigManager utilities works seamlessly."
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
],
|
|
|
|
|
"metadata": {
|
|
|
|
|
"created": "2025-06-13T23:52:56.848Z",
|
|
|
|
|
"updated": "2025-08-02T14:13:14.826Z",
|
|
|
|
|
"updated": "2025-08-28T15:00:06.183Z",
|
|
|
|
|
"description": "Main tag for the taskmaster project"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
|
Ralph Khreish