This commit implements AI usage telemetry for the `expand-all-tasks` command/tool and refactors its CLI output for clarity and consistency. Key Changes: 1. **Telemetry Integration for `expand-all-tasks` (Subtask 77.8):**\n - The `expandAllTasks` core logic (`scripts/modules/task-manager/expand-all-tasks.js`) now calls the `expandTask` function for each eligible task and collects the individual `telemetryData` returned.\n - A new helper function `_aggregateTelemetry` (in `utils.js`) is used to sum up token counts and costs from all individual expansions into a single `telemetryData` object for the entire `expand-all` operation.\n - The `expandAllTasksDirect` wrapper (`mcp-server/src/core/direct-functions/expand-all-tasks.js`) now receives and passes this aggregated `telemetryData` in the MCP response.\n - For CLI usage, `displayAiUsageSummary` is called once with the aggregated telemetry. 2. **Improved CLI Output for `expand-all`:**\n - The `expandAllTasks` core function now handles displaying a final "Expansion Summary" box (showing Attempted, Expanded, Skipped, Failed counts) directly after the aggregated telemetry summary.\n - This consolidates all summary output within the core function for better flow and removes redundant logging from the command action in `scripts/modules/commands.js`.\n - The summary box border is green for success and red if any expansions failed. 3. **Code Refinements:**\n - Ensured `chalk` and `boxen` are imported in `expand-all-tasks.js` for the new summary box.\n - Minor adjustments to logging messages for clarity.
86 lines
5.9 KiB
Plaintext
86 lines
5.9 KiB
Plaintext
# Task ID: 69
|
|
# Title: Enhance Analyze Complexity for Specific Task IDs
|
|
# Status: pending
|
|
# Dependencies: None
|
|
# Priority: medium
|
|
# Description: Modify the analyze-complexity feature (CLI and MCP) to allow analyzing only specified task IDs and append/update results in the report.
|
|
# Details:
|
|
|
|
Implementation Plan:
|
|
|
|
1. **Core Logic (`scripts/modules/task-manager/analyze-task-complexity.js`):**
|
|
* Modify the function signature to accept an optional `options.ids` parameter (string, comma-separated IDs).
|
|
* If `options.ids` is present:
|
|
* Parse the `ids` string into an array of target IDs.
|
|
* Filter `tasksData.tasks` to *only* include tasks matching the target IDs. Use this filtered list for analysis.
|
|
* Handle cases where provided IDs don't exist in `tasks.json`.
|
|
* If `options.ids` is *not* present: Continue with existing logic (filtering by active status).
|
|
* **Report Handling:**
|
|
* Before generating the analysis, check if the `outputPath` report file exists.
|
|
* If it exists, read the existing `complexityAnalysis` array.
|
|
* Generate the new analysis *only* for the target tasks (filtered by ID or status).
|
|
* Merge the results: Remove any entries from the *existing* array that match the IDs analyzed in the *current run*. Then, append the *new* analysis results to the array.
|
|
* Update the `meta` section (`generatedAt`, `tasksAnalyzed` should reflect *this run*).
|
|
* Write the *merged* `complexityAnalysis` array and updated `meta` back to the report file.
|
|
* If the report file doesn't exist, create it as usual.
|
|
* **Prompt Generation:** Ensure `generateInternalComplexityAnalysisPrompt` receives the correctly filtered list of tasks.
|
|
|
|
2. **CLI (`scripts/modules/commands.js`):**
|
|
* Add a new option `--id <ids>` to the `analyze-complexity` command definition. Description: "Comma-separated list of specific task IDs to analyze".
|
|
* In the `.action` handler:
|
|
* Check if `options.id` is provided.
|
|
* If yes, pass `options.id` (as the comma-separated string) to the `analyzeTaskComplexity` core function via the `options` object.
|
|
* Update user feedback messages to indicate specific task analysis.
|
|
|
|
3. **MCP Tool (`mcp-server/src/tools/analyze.js`):**
|
|
* Add a new optional parameter `ids: z.string().optional().describe("Comma-separated list of task IDs to analyze specifically")` to the Zod schema for the `analyze_project_complexity` tool.
|
|
* In the `execute` method, pass `args.ids` to the `analyzeTaskComplexityDirect` function within its `args` object.
|
|
|
|
4. **Direct Function (`mcp-server/src/core/direct-functions/analyze-task-complexity.js`):**
|
|
* Update the function to receive the `ids` string within the `args` object.
|
|
* Pass the `ids` string along to the core `analyzeTaskComplexity` function within its `options` object.
|
|
|
|
5. **Documentation:** Update relevant rule files (`commands.mdc`, `taskmaster.mdc`) to reflect the new `--id` option/parameter.
|
|
|
|
|
|
# Test Strategy:
|
|
|
|
1. **CLI:**
|
|
* Run `task-master analyze-complexity --id=<id1>` (where report doesn't exist). Verify report created with only task id1.
|
|
* Run `task-master analyze-complexity --id=<id2>` (where report exists). Verify report updated, containing analysis for both id1 and id2 (id2 replaces any previous id2 analysis).
|
|
* Run `task-master analyze-complexity --id=<id1>,<id3>`. Verify report updated, containing id1, id2, id3.
|
|
* Run `task-master analyze-complexity` (no id). Verify it analyzes *all* active tasks and updates the report accordingly, merging with previous specific analyses.
|
|
* Test with invalid/non-existent IDs.
|
|
2. **MCP:**
|
|
* Call `analyze_project_complexity` tool with `ids: "<id1>"`. Verify report creation/update.
|
|
* Call `analyze_project_complexity` tool with `ids: "<id1>,<id2>"`. Verify report merging.
|
|
* Call `analyze_project_complexity` tool without `ids`. Verify full analysis and merging.
|
|
3. Verify report `meta` section is updated correctly on each run.
|
|
|
|
|
|
# Subtasks:
|
|
## 1. Modify core complexity analysis logic [pending]
|
|
### Dependencies: None
|
|
### Description: Update the core complexity analysis function to accept specific task IDs as input parameters
|
|
### Details:
|
|
Refactor the existing complexity analysis module to allow filtering by task IDs. This involves modifying the data processing pipeline to filter tasks before analysis, ensuring the complexity metrics are calculated only for the specified tasks while maintaining context awareness.
|
|
|
|
## 2. Update CLI interface for task-specific complexity analysis [pending]
|
|
### Dependencies: 69.1
|
|
### Description: Extend the CLI to accept task IDs as parameters for the complexity analysis command
|
|
### Details:
|
|
Add a new flag or parameter to the CLI that allows users to specify task IDs for targeted complexity analysis. Update the command parser, help documentation, and ensure proper validation of the provided task IDs.
|
|
|
|
## 3. Integrate task-specific analysis with MCP tool [pending]
|
|
### Dependencies: 69.1
|
|
### Description: Update the MCP tool interface to support analyzing complexity for specific tasks
|
|
### Details:
|
|
Modify the MCP tool's API endpoints and UI components to allow users to select specific tasks for complexity analysis. Ensure the UI provides clear feedback about which tasks are being analyzed and update the visualization components to properly display partial analysis results.
|
|
|
|
## 4. Create comprehensive tests for task-specific complexity analysis [pending]
|
|
### Dependencies: 69.1, 69.2, 69.3
|
|
### Description: Develop test cases to verify the correct functioning of task-specific complexity analysis
|
|
### Details:
|
|
Create unit and integration tests that verify the task-specific complexity analysis works correctly across both CLI and MCP interfaces. Include tests for edge cases such as invalid task IDs, tasks with dependencies outside the selected set, and performance tests for large task sets.
|
|
|