feat: Apply tag information into task-complexity-report.json #292

New issue

Closed

opened 2025-10-14 15:48:23 -06:00 by navan · 0 comments

navan commented

2025-10-14 15:48:23 -06:00

Owner

Originally created by @chun92 on 7/18/2025

As a user managing multiple tags in a task-master project, I want task-complexity-report.json to store tag-specific data so that complexity analysis remains accurate when switching tags.

Motivation

Currently, task-complexity-report.json is written without any awareness of tags. When the user switches to a different tag, task-master continues referencing the complexity report generated from the previously active tag. This leads to incorrect complexity values being displayed in commands such as task-master show.

More critically, if the user performs operations like expand without rerunning analyze-complexity, task-master may act on an outdated or irrelevant complexity report, potentially producing incorrect task structures. This makes tag-based workflows fragile and error-prone.

Proposed Solution

Update the structure and behavior of task-complexity-report.json so it can store per-tag complexity analysis results. This ensures that the correct complexity data is used when the user switches between tags.

Modify the format of task-complexity-report.json to include tag keys at the top level.
Ensure analyze-complexity writes results under the current tag.
Ensure show, expand, and other commands read complexity only from the active tag section.

High-Level Workflow

Run analyze-complexity while on tag main.
→ Complexity is stored under main in the report file.
Switch to dev tag and run analyze-complexity.
→ Complexity is separately stored under dev.
When running task-master show or expand, complexity values are read only from the current tag's section.

Key Elements

Update format of task-complexity-report.json to:

{
  "main": {
    "complexityAnalysis": [
      { "taskId": 1, "complexityScore": 2 }
      { "taskId": 2, "complexityScore": 5  }
    ]
  },
  "dev": {
    "complexityAnalysis": [
      { "taskId": 1, "complexityScore": 7  }
    ]
  },
}

Update analyze-complexity to write under the active tag
Fallback behavior if no data is available for current tag

Example Workflow

$ task-master analyze-complexity
✔ Complexity report written for tag: main

$ task-master use-tag dev

$ task-master show
→ Complexity not shown for tasks under dev

$ task-master expand --id=1
→ Doesn't refer the wrong complexity report for main

Implementation Considerations

Must preserve backward compatibility with existing flat-format task-complexity-report.json or migration
Require logic to handle missing data for a tag gracefully (e.g., warn or auto-trigger analysis)
Consider auto-cleanup or expiration of outdated complexity data if necessary

Out of Scope (Future Considerations)

Cross-tag complexity analysis

*Originally created by @chun92 on 7/18/2025* As a user managing multiple tags in a task-master project, I want `task-complexity-report.json` to store tag-specific data so that complexity analysis remains accurate when switching tags. ### Motivation Currently, `task-complexity-report.json` is written without any awareness of tags. When the user switches to a different tag, task-master continues referencing the complexity report generated from the previously active tag. This leads to incorrect complexity values being displayed in commands such as `task-master show`. More critically, if the user performs operations like `expand `without rerunning `analyze-complexity`, task-master may act on an outdated or irrelevant complexity report, potentially producing incorrect task structures. This makes tag-based workflows fragile and error-prone. ### Proposed Solution Update the structure and behavior of `task-complexity-report.json` so it can store per-tag complexity analysis results. This ensures that the correct complexity data is used when the user switches between tags. * Modify the format of task-complexity-report.json to include tag keys at the top level. * Ensure analyze-complexity writes results under the current tag. * Ensure show, expand, and other commands read complexity only from the active tag section. ### High-Level Workflow 1. Run analyze-complexity while on tag `main`. → Complexity is stored under `main` in the report file. 2. Switch to `dev` tag and run `analyze-complexity`. → Complexity is separately stored under dev. 3. When running `task-master show` or `expand`, complexity values are read only from the current tag's section. ### Key Elements Update format of `task-complexity-report.json` to: ``` { "main": { "complexityAnalysis": [ { "taskId": 1, "complexityScore": 2 } { "taskId": 2, "complexityScore": 5 } ] }, "dev": { "complexityAnalysis": [ { "taskId": 1, "complexityScore": 7 } ] }, } ``` * Update `analyze-complexity` to write under the active tag * Fallback behavior if no data is available for current tag ### Example Workflow ``` $ task-master analyze-complexity ✔ Complexity report written for tag: main $ task-master use-tag dev $ task-master show → Complexity not shown for tasks under dev $ task-master expand --id=1 → Doesn't refer the wrong complexity report for main ``` ### Implementation Considerations * Must preserve backward compatibility with existing flat-format `task-complexity-report.json` or migration * Require logic to handle missing data for a tag gracefully (e.g., warn or auto-trigger analysis) * Consider auto-cleanup or expiration of outdated complexity data if necessary ### Out of Scope (Future Considerations) * Cross-tag complexity analysis