ros/claude-task-master
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(cli): Add --status/-s filter flag to show command and get-task MCP tool

Browse Source 
Implements the ability to filter subtasks displayed by the `task-master show <id>` command using the `--status` (or `-s`) flag. This is also available in the MCP context.

- Modified `commands.js` to add the `--status` option to the `show` command definition.

- Updated `utils.js` (`findTaskById`) to handle the filtering logic and return original subtask counts/arrays when filtering.

- Updated `ui.js` (`displayTaskById`) to use the filtered subtasks for the table, display a summary line when filtering, and use the original subtask list for the progress bar calculation.

- Updated MCP `get_task` tool and `showTaskDirect` function to accept and pass the `status` parameter.

- Added changeset entry.
This commit is contained in:
Eyal Toledano
2025-04-27 18:50:47 -04:00
parent 87d97bba00
commit ca7b0457f1
9 changed files with 245 additions and 306 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
tasks/task_054.txt
View File

@@ -1,6 +1,6 @@
# Task ID: 54
# Title: Add Research Flag to Add-Task Command
# Status: pending
# Status: done
# Dependencies: None
# Priority: medium
# Description: Enhance the add-task command with a --research flag that allows users to perform quick research on the task topic before finalizing task creation.

36
tasks/task_074.txt
View File

@@ -1,36 +0,0 @@
# Task ID: 74
# Title: Task 74: Implement Local Kokoro TTS Support
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Integrate Text-to-Speech (TTS) functionality using a locally running Google Cloud Text-to-Speech (Kokoro) instance, enabling the application to synthesize speech from text.
# Details:
Implementation Details:
1. **Kokoro Setup:** Assume the user has a local Kokoro TTS instance running and accessible via a network address (e.g., http://localhost:port).
2. **Configuration:** Introduce new configuration options (e.g., in `.taskmasterconfig`) to enable/disable TTS, specify the provider ('kokoro_local'), and configure the Kokoro endpoint URL (`tts.kokoro.url`). Consider adding options for voice selection and language if the Kokoro API supports them.
3. **API Interaction:** Implement a client module to interact with the local Kokoro TTS API. This module should handle sending text input and receiving audio data (likely in formats like WAV or MP3).
4. **Audio Playback:** Integrate a cross-platform audio playback library (e.g., `playsound`, `simpleaudio`, or platform-specific APIs) to play the synthesized audio received from Kokoro.
5. **Integration Point:** Identify initial areas in the application where TTS will be used (e.g., a command to read out the current task's title and description). Design the integration to be extensible for future use cases.
6. **Error Handling:** Implement robust error handling for scenarios like: Kokoro instance unreachable, API errors during synthesis, invalid configuration, audio playback failures. Provide informative feedback to the user.
7. **Dependencies:** Add any necessary HTTP client or audio playback libraries as project dependencies.
# Test Strategy:
1. **Unit Tests:**
* Mock the Kokoro API client. Verify that the TTS module correctly formats requests based on input text and configuration.
* Test handling of successful API responses (parsing audio data placeholder).
* Test handling of various API error responses (e.g., 404, 500).
* Mock the audio playback library. Verify that the received audio data is passed correctly to the playback function.
* Test configuration loading and validation logic.
2. **Integration Tests:**
* Requires a running local Kokoro TTS instance (or a compatible mock server).
* Send actual text snippets through the TTS module to the local Kokoro instance.
* Verify that valid audio data is received (e.g., check format, non-zero size). Direct audio playback verification might be difficult in automated tests, focus on the data transfer.
* Test the end-to-end flow by triggering TTS from an application command and ensuring no exceptions occur during synthesis and playback initiation.
* Test error handling by attempting synthesis with the Kokoro instance stopped or misconfigured.
3. **Manual Testing:**
* Configure the application to point to a running local Kokoro instance.
* Trigger TTS for various text inputs (short, long, special characters).
* Verify that the audio is played back clearly and accurately reflects the input text.
* Test enabling/disabling TTS via configuration.
* Test behavior when the Kokoro endpoint is incorrect or the server is down.
* Verify performance and responsiveness.

13
tasks/tasks.json
View File

@@ -2852,7 +2852,7 @@
"id": 54,
"title": "Add Research Flag to Add-Task Command",
"description": "Enhance the add-task command with a --research flag that allows users to perform quick research on the task topic before finalizing task creation.",
"status": "pending",
"status": "done",
"dependencies": [],
"priority": "medium",
"details": "Modify the existing add-task command to accept a new optional flag '--research'. When this flag is provided, the system should pause the task creation process and invoke the Perplexity research functionality (similar to Task #51) to help users gather information about the task topic before finalizing the task details. The implementation should:\n\n1. Update the command parser to recognize the new --research flag\n2. When the flag is present, extract the task title/description as the research topic\n3. Call the Perplexity research functionality with this topic\n4. Display research results to the user\n5. Allow the user to refine their task based on the research (modify title, description, etc.)\n6. Continue with normal task creation flow after research is complete\n7. Ensure the research results can be optionally attached to the task as reference material\n8. Add appropriate help text explaining this feature in the command help\n\nThe implementation should leverage the existing Perplexity research command from Task #51, ensuring code reuse where possible.",
@@ -3920,17 +3920,6 @@
"dependencies": [],
"priority": "medium",
"subtasks": []
},
{
"id": 74,
"title": "Task 74: Implement Local Kokoro TTS Support",
"description": "Integrate Text-to-Speech (TTS) functionality using a locally running Google Cloud Text-to-Speech (Kokoro) instance, enabling the application to synthesize speech from text.",
"details": "Implementation Details:\n1. **Kokoro Setup:** Assume the user has a local Kokoro TTS instance running and accessible via a network address (e.g., http://localhost:port).\n2. **Configuration:** Introduce new configuration options (e.g., in `.taskmasterconfig`) to enable/disable TTS, specify the provider ('kokoro_local'), and configure the Kokoro endpoint URL (`tts.kokoro.url`). Consider adding options for voice selection and language if the Kokoro API supports them.\n3. **API Interaction:** Implement a client module to interact with the local Kokoro TTS API. This module should handle sending text input and receiving audio data (likely in formats like WAV or MP3).\n4. **Audio Playback:** Integrate a cross-platform audio playback library (e.g., `playsound`, `simpleaudio`, or platform-specific APIs) to play the synthesized audio received from Kokoro.\n5. **Integration Point:** Identify initial areas in the application where TTS will be used (e.g., a command to read out the current task's title and description). Design the integration to be extensible for future use cases.\n6. **Error Handling:** Implement robust error handling for scenarios like: Kokoro instance unreachable, API errors during synthesis, invalid configuration, audio playback failures. Provide informative feedback to the user.\n7. **Dependencies:** Add any necessary HTTP client or audio playback libraries as project dependencies.",
"testStrategy": "1. **Unit Tests:** \n * Mock the Kokoro API client. Verify that the TTS module correctly formats requests based on input text and configuration.\n * Test handling of successful API responses (parsing audio data placeholder).\n * Test handling of various API error responses (e.g., 404, 500).\n * Mock the audio playback library. Verify that the received audio data is passed correctly to the playback function.\n * Test configuration loading and validation logic.\n2. **Integration Tests:**\n * Requires a running local Kokoro TTS instance (or a compatible mock server).\n * Send actual text snippets through the TTS module to the local Kokoro instance.\n * Verify that valid audio data is received (e.g., check format, non-zero size). Direct audio playback verification might be difficult in automated tests, focus on the data transfer.\n * Test the end-to-end flow by triggering TTS from an application command and ensuring no exceptions occur during synthesis and playback initiation.\n * Test error handling by attempting synthesis with the Kokoro instance stopped or misconfigured.\n3. **Manual Testing:**\n * Configure the application to point to a running local Kokoro instance.\n * Trigger TTS for various text inputs (short, long, special characters).\n * Verify that the audio is played back clearly and accurately reflects the input text.\n * Test enabling/disabling TTS via configuration.\n * Test behavior when the Kokoro endpoint is incorrect or the server is down.\n * Verify performance and responsiveness.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"subtasks": []
}
]
}