feat: Task Affected Assets Tracking #131

New issue

Open

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

navan commented

2025-10-14 15:43:15 -06:00

Owner

Originally created by @fede-ciliberti on 9/1/2025

"It would be interesting to have a list of assets affected by the completion of a task or sub-task. For example, a task asks to develop a module with certain functions. Then, when updating the status of that task to 'in_progress' or 'done', a list of files affected by that task could be added."

Motivation

This feature is important because it provides a clear and auditable trail of changes made during task completion. Developers can easily see which files were modified, added, or deleted as part of a specific task, improving transparency and accountability. It helps in code reviews, debugging, and understanding the impact of a task on the codebase. This solves the problem of manually tracking affected files and provides a direct link between task progress and code changes.

Proposed Solution

The proposed feature involves enhancing the Taskmaster task structure to include a new field, affectedAssets, which will store a list of file paths (assets) that are modified, added, or deleted during the completion of a task or subtask. This list will be updated by the developer, either manually or through a new command, when the task status changes (e.g., to 'in-progress' or 'done').

High-level overview of the feature: Introduce a new affectedAssets array field in the task/subtask schema to store file paths. This field will be editable and viewable through Taskmaster commands.
Relevant technologies or integrations: This feature would primarily involve modifications to the task-master-ai core logic, specifically the task schema and the commands that modify task status or details. It would integrate with the existing tasks.json file structure. No external technologies are strictly required, but it could potentially integrate with Git for automatic detection of changed files (future consideration).
How it fits into the existing workflow or architecture: This feature seamlessly integrates into the existing task management workflow. Developers already update task statuses; this simply adds an optional step to record affected files, enriching the task's context without disrupting the core process. It would extend the current task schema and command-line interface.

High-Level Workflow

Schema Modification: Update the tasks.json schema to include a new optional field, affectedAssets, which will be an array of strings (file paths).
Command Line Interface (CLI) Updates:
- Modify task-master set-status to accept an optional --assets <file-paths> parameter when changing a task's status to 'in-progress' or 'done'.
- Modify task-master update-task and task-master update-subtask to allow adding/updating the affectedAssets field.
Core Logic Implementation:
- Implement logic within the Taskmaster core to parse the --assets parameter and store the file paths in the affectedAssets field of the corresponding task/subtask in tasks.json.
- Ensure that when a task/subtask is retrieved, its affectedAssets are also loaded.
Display in task-master show: Enhance the task-master show <id> command to display the list of affectedAssets for a given task or subtask.
Documentation Update: Update the Taskmaster documentation to reflect the new affectedAssets field and its usage.

Key Elements

New affectedAssets field: An optional array of strings (file paths) to be added to the task/subtask schema in tasks.json.
CLI Command Enhancements:
- task-master set-status --id=<id> --status=done --assets="src/file1.js,src/file2.ts": Allow specifying affected files when marking a task as done or in-progress.
- task-master update-task --id=<id> --prompt="Added new assets" --assets="src/new_feature.js": Allow updating the affectedAssets field for a task.
- task-master update-subtask --id=<id.subid> --prompt="Updated asset list" --assets="src/subtask_file.py": Allow updating the affectedAssets field for a subtask.
Display Logic: Update the task-master show <id> command to clearly display the affectedAssets list.
Data Model Changes: Modification of the internal task data structure to accommodate the new affectedAssets array.
Validation: Basic validation for file paths (e.g., ensuring they are strings).

Example Workflow

Provide a clear, concrete example demonstrating the feature:

# Initial task list
$ task-master list
ID  Title             Status
--  ----------------  --------
1   Implement Feature X  pending

# Start working on task 1 and specify affected files
$ task-master set-status --id=1 --status=in-progress --assets="src/featureX.js,src/utils/helper.js"
→ Task 1 status updated to 'in-progress'. Affected assets: src/featureX.js, src/utils/helper.js

# Later, mark task 1 as done and add more affected files
$ task-master set-status --id=1 --status=done --assets="src/featureX.test.js"
→ Task 1 status updated to 'done'. Affected assets: src/featureX.js, src/utils/helper.js, src/featureX.test.js

# View details of task 1, including affected assets
$ task-master show 1
ID: 1
Title: Implement Feature X
Status: done
Affected Assets:
  - src/featureX.js
  - src/utils/helper.js
  - src/featureX.test.js
... (other task details)

# Update a subtask and its affected assets
$ task-master update-subtask --id=1.1 --prompt="Refactored component" --assets="src/components/featureXComponent.js"
→ Subtask 1.1 updated. Affected assets: src/components/featureXComponent.js

Implementation Considerations

Dependencies: This feature primarily depends on the existing Taskmaster core logic and the tasks.json schema. No external components or APIs are strictly required for the basic implementation.
Backward Compatibility: The addition of a new optional field affectedAssets should be backward compatible with existing tasks.json files. Older versions of Taskmaster would simply ignore this new field.
Performance Impacts: Storing an array of file paths in tasks.json might slightly increase the file size, but for typical use cases, this impact should be negligible. The performance of reading and writing tasks.json should not be significantly affected.
User Experience: The CLI commands should be intuitive and provide clear feedback when affectedAssets are added or updated.
File Path Resolution: Consider how file paths will be stored (absolute, relative to project root, etc.) and ensure consistency. Relative paths are generally preferred for portability.

Out of Scope (Future Considerations)

Automatic Git Integration: Automatically detect changed files in the Git working directory and suggest them as affectedAssets when a task status is updated. This would require integration with Git commands.
IDE Integration: Provide a way to select affected files directly from the IDE's file explorer or source control view.
Visual Representation: Display affected assets in a more visual way, perhaps within a UI (e.g., a tree view or a dedicated panel in a VS Code extension).
Filtering/Searching by Assets: Allow users to search or filter tasks based on the files they affect.
Asset Type Categorization: Categorize assets by type (e.g., code, documentation, tests, configuration).
Impact Analysis: Develop a feature to analyze the potential impact of changes to a specific file by showing which tasks have historically affected it.

*Originally created by @fede-ciliberti on 9/1/2025* > "It would be interesting to have a list of assets affected by the completion of a task or sub-task. For example, a task asks to develop a module with certain functions. Then, when updating the status of that task to 'in_progress' or 'done', a list of files affected by that task could be added." ### Motivation This feature is important because it provides a clear and auditable trail of changes made during task completion. Developers can easily see which files were modified, added, or deleted as part of a specific task, improving transparency and accountability. It helps in code reviews, debugging, and understanding the impact of a task on the codebase. This solves the problem of manually tracking affected files and provides a direct link between task progress and code changes. ### Proposed Solution The proposed feature involves enhancing the Taskmaster task structure to include a new field, `affectedAssets`, which will store a list of file paths (assets) that are modified, added, or deleted during the completion of a task or subtask. This list will be updated by the developer, either manually or through a new command, when the task status changes (e.g., to 'in-progress' or 'done'). - **High-level overview of the feature**: Introduce a new `affectedAssets` array field in the task/subtask schema to store file paths. This field will be editable and viewable through Taskmaster commands. - **Relevant technologies or integrations**: This feature would primarily involve modifications to the `task-master-ai` core logic, specifically the task schema and the commands that modify task status or details. It would integrate with the existing `tasks.json` file structure. No external technologies are strictly required, but it could potentially integrate with Git for automatic detection of changed files (future consideration). - **How it fits into the existing workflow or architecture**: This feature seamlessly integrates into the existing task management workflow. Developers already update task statuses; this simply adds an optional step to record affected files, enriching the task's context without disrupting the core process. It would extend the current task schema and command-line interface. ### High-Level Workflow 1. **Schema Modification**: Update the `tasks.json` schema to include a new optional field, `affectedAssets`, which will be an array of strings (file paths). 2. **Command Line Interface (CLI) Updates**: * Modify `task-master set-status` to accept an optional `--assets <file-paths>` parameter when changing a task's status to 'in-progress' or 'done'. * Modify `task-master update-task` and `task-master update-subtask` to allow adding/updating the `affectedAssets` field. 3. **Core Logic Implementation**: * Implement logic within the Taskmaster core to parse the `--assets` parameter and store the file paths in the `affectedAssets` field of the corresponding task/subtask in `tasks.json`. * Ensure that when a task/subtask is retrieved, its `affectedAssets` are also loaded. 4. **Display in `task-master show`**: Enhance the `task-master show <id>` command to display the list of `affectedAssets` for a given task or subtask. 5. **Documentation Update**: Update the Taskmaster documentation to reflect the new `affectedAssets` field and its usage. ### Key Elements - **New `affectedAssets` field**: An optional array of strings (file paths) to be added to the task/subtask schema in `tasks.json`. - **CLI Command Enhancements**: * `task-master set-status --id=<id> --status=done --assets="src/file1.js,src/file2.ts"`: Allow specifying affected files when marking a task as done or in-progress. * `task-master update-task --id=<id> --prompt="Added new assets" --assets="src/new_feature.js"`: Allow updating the `affectedAssets` field for a task. * `task-master update-subtask --id=<id.subid> --prompt="Updated asset list" --assets="src/subtask_file.py"`: Allow updating the `affectedAssets` field for a subtask. - **Display Logic**: Update the `task-master show <id>` command to clearly display the `affectedAssets` list. - **Data Model Changes**: Modification of the internal task data structure to accommodate the new `affectedAssets` array. - **Validation**: Basic validation for file paths (e.g., ensuring they are strings). ### Example Workflow Provide a clear, concrete example demonstrating the feature: ```shell # Initial task list $ task-master list ID Title Status -- ---------------- -------- 1 Implement Feature X pending # Start working on task 1 and specify affected files $ task-master set-status --id=1 --status=in-progress --assets="src/featureX.js,src/utils/helper.js" → Task 1 status updated to 'in-progress'. Affected assets: src/featureX.js, src/utils/helper.js # Later, mark task 1 as done and add more affected files $ task-master set-status --id=1 --status=done --assets="src/featureX.test.js" → Task 1 status updated to 'done'. Affected assets: src/featureX.js, src/utils/helper.js, src/featureX.test.js # View details of task 1, including affected assets $ task-master show 1 ID: 1 Title: Implement Feature X Status: done Affected Assets: - src/featureX.js - src/utils/helper.js - src/featureX.test.js ... (other task details) # Update a subtask and its affected assets $ task-master update-subtask --id=1.1 --prompt="Refactored component" --assets="src/components/featureXComponent.js" → Subtask 1.1 updated. Affected assets: src/components/featureXComponent.js ``` ### Implementation Considerations - **Dependencies**: This feature primarily depends on the existing Taskmaster core logic and the `tasks.json` schema. No external components or APIs are strictly required for the basic implementation. - **Backward Compatibility**: The addition of a new optional field `affectedAssets` should be backward compatible with existing `tasks.json` files. Older versions of Taskmaster would simply ignore this new field. - **Performance Impacts**: Storing an array of file paths in `tasks.json` might slightly increase the file size, but for typical use cases, this impact should be negligible. The performance of reading and writing `tasks.json` should not be significantly affected. - **User Experience**: The CLI commands should be intuitive and provide clear feedback when `affectedAssets` are added or updated. - **File Path Resolution**: Consider how file paths will be stored (absolute, relative to project root, etc.) and ensure consistency. Relative paths are generally preferred for portability. ### Out of Scope (Future Considerations) - **Automatic Git Integration**: Automatically detect changed files in the Git working directory and suggest them as `affectedAssets` when a task status is updated. This would require integration with Git commands. - **IDE Integration**: Provide a way to select affected files directly from the IDE's file explorer or source control view. - **Visual Representation**: Display affected assets in a more visual way, perhaps within a UI (e.g., a tree view or a dedicated panel in a VS Code extension). - **Filtering/Searching by Assets**: Allow users to search or filter tasks based on the files they affect. - **Asset Type Categorization**: Categorize assets by type (e.g., `code`, `documentation`, `tests`, `configuration`). - **Impact Analysis**: Develop a feature to analyze the potential impact of changes to a specific file by showing which tasks have historically affected it.