feat: #72

New issue

Open

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

navan commented

2025-10-14 15:40:33 -06:00

Owner

Originally created by @DonBamboo on 9/23/2025

Here’s a modified template with your update-subtask request included. I’ve adapted the structure so it fits well as a feature request or bug report for your task-master CLI tool.

Feature Request: Updated State in `task-master show` After Subtask Update

User Story:
As a user, I want the task-master show command to display the most recent state of a subtask after running task-master update-subtask, so that I can rely on it as an accurate log of the current status.

Motivation

Currently, when I run:

task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>"

The CLI correctly shows the updated subtasks immediately after the update.

However, when I later run:

task-master show --id=<parentId.subtaskId>

It only displays the previous state of the subtasks, not the most recent changes.

This inconsistency makes it difficult to track progress or use task-master show as a reliable log for the current task status.

Proposed Solution

Update the task-master show command to always fetch and display the latest subtask data, ensuring it reflects updates made through update-subtask.

High-Level Overview:

When a subtask is updated, the changes should be persisted in storage (DB, file, or API).
task-master show should read directly from this latest state.
Ensure both commands (update-subtask and show) are fully synchronized.

Relevant Technologies:

Current data storage mechanism (e.g., PostgreSQL, JSON file, Supabase, etc.)
CLI architecture for read/write operations

High-Level Workflow

Update Subtask
- User runs task-master update-subtask
- CLI validates input and saves changes to the current storage layer.
Verify Updated State
- User runs task-master show
- CLI fetches the latest data and displays updated subtasks.
Confirm Sync
- Ensure no caching or outdated reads interfere with real-time updates.

Key Elements

Enhance update-subtask to ensure persistent updates.
Update show command logic to pull the current state directly from storage.
Add logging or timestamp metadata to track when updates occur.
Ensure compatibility with existing task and subtask data models.

Example Workflow

# Update subtask
$ task-master update-subtask --id=123.456 --prompt="Update the UI design"
→ Subtask updated successfully:
  {
    "id": "4",
    "status": "in-progress",
    "description": "Update the UI design"
  }

# Show updated task
$ task-master show --id=1.4
→ Current task state as well as the appended/updated subtasks information:
  {
    "id": "4",
    "status": "in-progress",
    "description": "Update the UI design"
  }

Implementation Considerations

Ensure data persistence is reliable (e.g., avoid in-memory-only updates).
Validate that update-subtask triggers proper save operations.
Optimize for performance when fetching large task trees.
Maintain backward compatibility with older task data formats.

Out of Scope (Future Considerations)

Bulk subtask updates (update-subtask on multiple IDs at once).
Advanced history or audit trail for each subtask.
Role-based access control for updating and viewing tasks.

Would you like me to convert this into a GitHub issue template so you can use it directly for tracking?

*Originally created by @DonBamboo on 9/23/2025* Here’s a **modified template** with your `update-subtask` request included. I’ve adapted the structure so it fits well as a feature request or bug report for your `task-master` CLI tool. --- ## **Feature Request: Updated State in `task-master show` After Subtask Update** > **User Story:** > As a user, I want the `task-master show` command to display the most recent state of a subtask after running `task-master update-subtask`, so that I can rely on it as an accurate log of the current status. --- ### **Motivation** Currently, when I run: ```shell task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>" ``` The CLI correctly shows the updated subtasks immediately after the update. However, when I later run: ```shell task-master show --id=<parentId.subtaskId> ``` It only displays the **previous state** of the subtasks, not the most recent changes. This inconsistency makes it difficult to track progress or use `task-master show` as a reliable log for the current task status. --- ### **Proposed Solution** Update the `task-master show` command to **always fetch and display the latest subtask data**, ensuring it reflects updates made through `update-subtask`. **High-Level Overview:** * When a subtask is updated, the changes should be persisted in storage (DB, file, or API). * `task-master show` should read directly from this latest state. * Ensure both commands (`update-subtask` and `show`) are fully synchronized. **Relevant Technologies:** * Current data storage mechanism (e.g., PostgreSQL, JSON file, Supabase, etc.) * CLI architecture for read/write operations --- ### **High-Level Workflow** 1. **Update Subtask** * User runs `task-master update-subtask` * CLI validates input and saves changes to the current storage layer. 2. **Verify Updated State** * User runs `task-master show` * CLI fetches the latest data and displays updated subtasks. 3. **Confirm Sync** * Ensure no caching or outdated reads interfere with real-time updates. --- ### **Key Elements** * Enhance `update-subtask` to ensure persistent updates. * Update `show` command logic to pull the **current state** directly from storage. * Add logging or timestamp metadata to track when updates occur. * Ensure compatibility with existing task and subtask data models. --- ### **Example Workflow** ```shell # Update subtask $ task-master update-subtask --id=123.456 --prompt="Update the UI design" → Subtask updated successfully: { "id": "4", "status": "in-progress", "description": "Update the UI design" } # Show updated task $ task-master show --id=1.4 → Current task state as well as the appended/updated subtasks information: { "id": "4", "status": "in-progress", "description": "Update the UI design" } ``` --- ### **Implementation Considerations** * Ensure data persistence is reliable (e.g., avoid in-memory-only updates). * Validate that `update-subtask` triggers proper save operations. * Optimize for performance when fetching large task trees. * Maintain backward compatibility with older task data formats. --- ### **Out of Scope (Future Considerations)** * Bulk subtask updates (`update-subtask` on multiple IDs at once). * Advanced history or audit trail for each subtask. * Role-based access control for updating and viewing tasks. --- Would you like me to convert this into a **GitHub issue template** so you can use it directly for tracking?