Refactor: Modularize Task Master CLI into Modules Directory
Simplified the Task Master CLI by organizing code into modules within the directory. **Why:** - **Better Organization:** Code is now grouped by function (AI, commands, dependencies, tasks, UI, utilities). - **Easier to Maintain:** Smaller modules are simpler to update and fix. - **Scalable:** New features can be added more easily in a structured way. **What Changed:** - Moved code from single _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master file into these new modules: - : AI interactions (Claude, Perplexity) - : CLI command definitions (Commander.js) - : Task dependency handling - : Core task operations (create, list, update, etc.) - : User interface elements (display, formatting) - : Utility functions and configuration - : Exports all modules - Replaced direct use of _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master with the global command (see ). - Updated documentation () to reflect the new command. **Benefits:** Code is now cleaner, easier to work with, and ready for future growth. Use the command (or ) to run the CLI. See for command details.
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
# Task ID: 17
|
||||
# Title: Implement Comprehensive Logging System
|
||||
# Status: done
|
||||
# Dependencies: 2 ✅, 16 ✅
|
||||
# Dependencies: ✅ 2 (done), ✅ 16 (done)
|
||||
# Priority: medium
|
||||
# Description: Create a flexible logging system with configurable levels and output formats.
|
||||
# Details:
|
||||
@@ -18,68 +18,33 @@ Implement logging system including:
|
||||
Test logging at different verbosity levels. Verify that logs contain appropriate information for debugging. Test log file rotation with large volumes of logs.
|
||||
|
||||
# Subtasks:
|
||||
## Subtask ID: 1
|
||||
## Title: Implement Core Logging Framework with Log Levels
|
||||
## Status: done
|
||||
## Dependencies: None
|
||||
## Description: Create a modular logging framework that supports multiple log levels (debug, info, warn, error). Implement a Logger class that handles message formatting, timestamp addition, and log level filtering. The framework should allow for global log level configuration through the configuration system and provide a clean API for logging messages at different levels.
|
||||
## Acceptance Criteria:
|
||||
- Logger class with methods for each log level (debug, info, warn, error)
|
||||
- Log level filtering based on configuration settings
|
||||
- Consistent log message format including timestamp, level, and context
|
||||
- Unit tests for each log level and filtering functionality
|
||||
- Documentation for logger usage in different parts of the application
|
||||
## 1. Implement Core Logging Framework with Log Levels [done]
|
||||
### Dependencies: None
|
||||
### Description: Create a modular logging framework that supports multiple log levels (debug, info, warn, error). Implement a Logger class that handles message formatting, timestamp addition, and log level filtering. The framework should allow for global log level configuration through the configuration system and provide a clean API for logging messages at different levels.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 2
|
||||
## Title: Implement Configurable Output Destinations
|
||||
## Status: done
|
||||
## Dependencies: 17.1 ✅
|
||||
## Description: Extend the logging framework to support multiple output destinations simultaneously. Implement adapters for console output, file output, and potentially other destinations (like remote logging services). Create a configuration system that allows specifying which log levels go to which destinations. Ensure thread-safe writing to prevent log corruption.
|
||||
## Acceptance Criteria:
|
||||
- Abstract destination interface that can be implemented by different output types
|
||||
- Console output adapter with color-coding based on log level
|
||||
- File output adapter with proper file handling and path configuration
|
||||
- Configuration options to route specific log levels to specific destinations
|
||||
- Ability to add custom output destinations through the adapter pattern
|
||||
- Tests verifying logs are correctly routed to configured destinations
|
||||
|
||||
## Subtask ID: 3
|
||||
## Title: Implement Command and API Interaction Logging
|
||||
## Status: done
|
||||
## Dependencies: 17.1 ✅, 17.2 ✅
|
||||
## Description: Create specialized logging functionality for command execution and API interactions. For commands, log the command name, arguments, options, and execution status. For API interactions, log request details (URL, method, headers), response status, and timing information. Implement sanitization to prevent logging sensitive data like API keys or passwords.
|
||||
## Acceptance Criteria:
|
||||
- Command logger that captures command execution details
|
||||
- API logger that records request/response details with timing information
|
||||
- Data sanitization to mask sensitive information in logs
|
||||
- Configuration options to control verbosity of command and API logs
|
||||
- Integration with existing command execution flow
|
||||
- Tests verifying proper logging of commands and API calls
|
||||
## 2. Implement Configurable Output Destinations [done]
|
||||
### Dependencies: 1 (done)
|
||||
### Description: Extend the logging framework to support multiple output destinations simultaneously. Implement adapters for console output, file output, and potentially other destinations (like remote logging services). Create a configuration system that allows specifying which log levels go to which destinations. Ensure thread-safe writing to prevent log corruption.
|
||||
### Details:
|
||||
|
||||
|
||||
## 3. Implement Command and API Interaction Logging [done]
|
||||
### Dependencies: 1 (done), 2 (done)
|
||||
### Description: Create specialized logging functionality for command execution and API interactions. For commands, log the command name, arguments, options, and execution status. For API interactions, log request details (URL, method, headers), response status, and timing information. Implement sanitization to prevent logging sensitive data like API keys or passwords.
|
||||
### Details:
|
||||
|
||||
|
||||
## 4. Implement Error Tracking and Performance Metrics [done]
|
||||
### Dependencies: 1 (done)
|
||||
### Description: Enhance the logging system to provide detailed error tracking and performance metrics. For errors, capture stack traces, error codes, and contextual information. For performance metrics, implement timing utilities to measure execution duration of key operations. Create a consistent format for these specialized log types to enable easier analysis.
|
||||
### Details:
|
||||
|
||||
|
||||
## 5. Implement Log File Rotation and Management [done]
|
||||
### Dependencies: 2 (done)
|
||||
### Description: Create a log file management system that handles rotation based on file size or time intervals. Implement compression of rotated logs, automatic cleanup of old logs, and configurable retention policies. Ensure that log rotation happens without disrupting the application and that no log messages are lost during rotation.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 4
|
||||
## Title: Implement Error Tracking and Performance Metrics
|
||||
## Status: done
|
||||
## Dependencies: 17.1 ✅
|
||||
## Description: Enhance the logging system to provide detailed error tracking and performance metrics. For errors, capture stack traces, error codes, and contextual information. For performance metrics, implement timing utilities to measure execution duration of key operations. Create a consistent format for these specialized log types to enable easier analysis.
|
||||
## Acceptance Criteria:
|
||||
- Error logging with full stack trace capture and error context
|
||||
- Performance timer utility for measuring operation duration
|
||||
- Standard format for error and performance log entries
|
||||
- Ability to track related errors through correlation IDs
|
||||
- Configuration options for performance logging thresholds
|
||||
- Unit tests for error tracking and performance measurement
|
||||
|
||||
## Subtask ID: 5
|
||||
## Title: Implement Log File Rotation and Management
|
||||
## Status: done
|
||||
## Dependencies: 17.2 ✅
|
||||
## Description: Create a log file management system that handles rotation based on file size or time intervals. Implement compression of rotated logs, automatic cleanup of old logs, and configurable retention policies. Ensure that log rotation happens without disrupting the application and that no log messages are lost during rotation.
|
||||
## Acceptance Criteria:
|
||||
- Log rotation based on configurable file size or time interval
|
||||
- Compressed archive creation for rotated logs
|
||||
- Configurable retention policy for log archives
|
||||
- Zero message loss during rotation operations
|
||||
- Proper file locking to prevent corruption during rotation
|
||||
- Configuration options for rotation settings
|
||||
- Tests verifying rotation functionality with large log volumes
|
||||
- Documentation for log file location and naming conventions
|
||||
|
||||
Reference in New Issue
Block a user