21c3cb8cda
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.
95 lines
5.9 KiB
Plaintext
95 lines
5.9 KiB
Plaintext
# Task ID: 44
|
|
# Title: Implement Task Automation with Webhooks and Event Triggers
|
|
# Status: pending
|
|
# Dependencies: None
|
|
# Priority: medium
|
|
# Description: Design and implement a system that allows users to automate task actions through webhooks and event triggers, enabling integration with external services and automated workflows.
|
|
# Details:
|
|
This feature will enable users to create automated workflows based on task events and external triggers. Implementation should include:
|
|
|
|
1. A webhook registration system that allows users to specify URLs to be called when specific task events occur (creation, status change, completion, etc.)
|
|
2. An event system that captures and processes all task-related events
|
|
3. A trigger definition interface where users can define conditions for automation (e.g., 'When task X is completed, create task Y')
|
|
4. Support for both incoming webhooks (external services triggering actions in Taskmaster) and outgoing webhooks (Taskmaster notifying external services)
|
|
5. A secure authentication mechanism for webhook calls
|
|
6. Rate limiting and retry logic for failed webhook deliveries
|
|
7. Integration with the existing task management system
|
|
8. Command-line interface for managing webhooks and triggers
|
|
9. Payload templating system allowing users to customize the data sent in webhooks
|
|
10. Logging system for webhook activities and failures
|
|
|
|
The implementation should be compatible with both the solo/local mode and the multiplayer/remote mode, with appropriate adaptations for each context. When operating in MCP mode, the system should leverage the MCP communication protocol implemented in Task #42.
|
|
|
|
# Test Strategy:
|
|
Testing should verify both the functionality and security of the webhook system:
|
|
|
|
1. Unit tests:
|
|
- Test webhook registration, modification, and deletion
|
|
- Verify event capturing for all task operations
|
|
- Test payload generation and templating
|
|
- Validate authentication logic
|
|
|
|
2. Integration tests:
|
|
- Set up a mock server to receive webhooks and verify payload contents
|
|
- Test the complete flow from task event to webhook delivery
|
|
- Verify rate limiting and retry behavior with intentionally failing endpoints
|
|
- Test webhook triggers creating new tasks and modifying existing ones
|
|
|
|
3. Security tests:
|
|
- Verify that authentication tokens are properly validated
|
|
- Test for potential injection vulnerabilities in webhook payloads
|
|
- Verify that sensitive information is not leaked in webhook payloads
|
|
- Test rate limiting to prevent DoS attacks
|
|
|
|
4. Mode-specific tests:
|
|
- Verify correct operation in both solo/local and multiplayer/remote modes
|
|
- Test the interaction with MCP protocol when in multiplayer mode
|
|
|
|
5. Manual verification:
|
|
- Set up integrations with common services (GitHub, Slack, etc.) to verify real-world functionality
|
|
- Verify that the CLI interface for managing webhooks works as expected
|
|
|
|
# Subtasks:
|
|
## 1. Design webhook registration API endpoints [pending]
|
|
### Dependencies: None
|
|
### Description: Create API endpoints for registering, updating, and deleting webhook subscriptions
|
|
### Details:
|
|
Implement RESTful API endpoints that allow clients to register webhook URLs, specify event types they want to subscribe to, and manage their subscriptions. Include validation for URL format, required parameters, and authentication requirements.
|
|
|
|
## 2. Implement webhook authentication and security measures [pending]
|
|
### Dependencies: 44.1
|
|
### Description: Develop security mechanisms for webhook verification and payload signing
|
|
### Details:
|
|
Implement signature verification using HMAC, rate limiting to prevent abuse, IP whitelisting options, and webhook secret management. Create a secure token system for webhook verification and implement TLS for all webhook communications.
|
|
|
|
## 3. Create event trigger definition interface [pending]
|
|
### Dependencies: None
|
|
### Description: Design and implement the interface for defining event triggers and conditions
|
|
### Details:
|
|
Develop a user interface or API that allows defining what events should trigger webhooks. Include support for conditional triggers based on event properties, filtering options, and the ability to specify payload formats.
|
|
|
|
## 4. Build event processing and queuing system [pending]
|
|
### Dependencies: 44.1, 44.3
|
|
### Description: Implement a robust system for processing and queuing events before webhook delivery
|
|
### Details:
|
|
Create an event queue using a message broker (like RabbitMQ or Kafka) to handle high volumes of events. Implement event deduplication, prioritization, and persistence to ensure reliable delivery even during system failures.
|
|
|
|
## 5. Develop webhook delivery and retry mechanism [pending]
|
|
### Dependencies: 44.2, 44.4
|
|
### Description: Create a reliable system for webhook delivery with retry logic and failure handling
|
|
### Details:
|
|
Implement exponential backoff retry logic, configurable retry attempts, and dead letter queues for failed deliveries. Add monitoring for webhook delivery success rates and performance metrics. Include timeout handling for unresponsive webhook endpoints.
|
|
|
|
## 6. Implement comprehensive error handling and logging [pending]
|
|
### Dependencies: 44.5
|
|
### Description: Create robust error handling, logging, and monitoring for the webhook system
|
|
### Details:
|
|
Develop detailed error logging for webhook failures, including response codes, error messages, and timing information. Implement alerting for critical failures and create a dashboard for monitoring system health. Add debugging tools for webhook delivery issues.
|
|
|
|
## 7. Create webhook testing and simulation tools [pending]
|
|
### Dependencies: 44.3, 44.5, 44.6
|
|
### Description: Develop tools for testing webhook integrations and simulating event triggers
|
|
### Details:
|
|
Build a webhook testing console that allows manual triggering of events, viewing delivery history, and replaying failed webhooks. Create a webhook simulator for developers to test their endpoint implementations without generating real system events.
|
|
|