feat(mcp): Add tagInfo to responses and integrate ContextGatherer
Enhances the MCP server to include 'tagInfo' (currentTag, availableTags) in all tool responses, providing better client-side context.
- Introduces a new 'ContextGatherer' utility to standardize the collection of file, task, and project context for AI-powered commands. This refactors several task-manager modules ('expand-task', 'research', 'update-task', etc.) to use the new utility.
- Fixes an issue in 'get-task' and 'get-tasks' MCP tools where the 'projectRoot' was not being passed correctly, preventing tag information from being included in their responses.
- Adds subtask '103.17' to track the implementation of the task template importing feature.
- Updates documentation ('.cursor/rules', 'docs/') to align with the new tagged task system and context gatherer logic.
This commit is contained in:
Eyal Toledano
@@ -20,19 +20,21 @@ alwaysApply: false
|
||||
- **[`task-manager.js`](mdc:scripts/modules/task-manager.js) & `task-manager/` directory: Task Data & Core Logic**
|
||||
- **Purpose**: Contains core functions for task data manipulation (CRUD), AI interactions, and related logic.
|
||||
- **Responsibilities**:
|
||||
- Reading/writing `tasks.json`.
|
||||
- Reading/writing `tasks.json` with tagged task lists support.
|
||||
- Implementing functions for task CRUD, parsing PRDs, expanding tasks, updating status, etc.
|
||||
- **Tagged Task Lists**: Handles task organization across multiple contexts (tags) like "master", branch names, or project phases.
|
||||
- **Tag Resolution**: Provides backward compatibility by resolving tagged format to legacy format transparently.
|
||||
- **Delegating AI interactions** to the `ai-services-unified.js` layer.
|
||||
- Accessing non-AI configuration via `config-manager.js` getters.
|
||||
- **Key Files**: Individual files within `scripts/modules/task-manager/` handle specific actions (e.g., `add-task.js`, `expand-task.js`).
|
||||
|
||||
- **[`dependency-manager.js`](mdc:scripts/modules/dependency-manager.js): Dependency Management**
|
||||
- **Purpose**: Manages task dependencies.
|
||||
- **Responsibilities**: Add/remove/validate/fix dependencies.
|
||||
- **Responsibilities**: Add/remove/validate/fix dependencies across tagged task contexts.
|
||||
|
||||
- **[`ui.js`](mdc:scripts/modules/ui.js): User Interface Components**
|
||||
- **Purpose**: Handles CLI output formatting (tables, colors, boxes, spinners).
|
||||
- **Responsibilities**: Displaying tasks, reports, progress, suggestions.
|
||||
- **Responsibilities**: Displaying tasks, reports, progress, suggestions, and migration notices for tagged systems.
|
||||
|
||||
- **[`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js): Unified AI Service Layer**
|
||||
- **Purpose**: Centralized interface for all LLM interactions using Vercel AI SDK.
|
||||
@@ -53,6 +55,7 @@ alwaysApply: false
|
||||
- **Responsibilities** (See also: [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)):
|
||||
- Reads and merges `.taskmasterconfig` with defaults.
|
||||
- Provides getters (e.g., `getMainProvider`, `getLogLevel`, `getDefaultSubtasks`) for accessing settings.
|
||||
- **Tag Configuration**: Manages `global.defaultTag` and `tags` section for tag system settings.
|
||||
- **Note**: Does **not** store or directly handle API keys (keys are in `.env` or MCP `session.env`).
|
||||
|
||||
- **[`utils.js`](mdc:scripts/modules/utils.js): Core Utility Functions**
|
||||
@@ -62,6 +65,8 @@ alwaysApply: false
|
||||
- Task utils (`findTaskById`), Dependency utils (`findCycles`).
|
||||
- API Key Resolution (`resolveEnvVariable`).
|
||||
- Silent Mode Control (`enableSilentMode`, `disableSilentMode`).
|
||||
- **Tagged Task Lists**: Silent migration system, tag resolution, current tag management.
|
||||
- **Migration System**: `performCompleteTagMigration`, `migrateConfigJson`, `createStateJson`.
|
||||
|
||||
- **[`mcp-server/`](mdc:mcp-server/): MCP Server Integration**
|
||||
- **Purpose**: Provides MCP interface using FastMCP.
|
||||
@@ -71,16 +76,42 @@ alwaysApply: false
|
||||
- Tool `execute` methods call **direct function wrappers** (`mcp-server/src/core/direct-functions/*.js`), passing the normalized `projectRoot` and other args.
|
||||
- Direct functions use path utilities (`mcp-server/src/core/utils/`) to resolve paths based on `projectRoot` from session.
|
||||
- Direct functions implement silent mode, logger wrappers, and call core logic functions from `scripts/modules/`.
|
||||
- **Tagged Task Lists**: MCP tools need updating to handle tagged format (Part 2 implementation).
|
||||
- Manages MCP caching and response formatting.
|
||||
|
||||
- **[`init.js`](mdc:scripts/init.js): Project Initialization Logic**
|
||||
- **Purpose**: Sets up new Task Master project structure.
|
||||
- **Responsibilities**: Creates directories, copies templates, manages `package.json`, sets up `.cursor/mcp.json`.
|
||||
- **Responsibilities**: Creates directories, copies templates, manages `package.json`, sets up `.cursor/mcp.json`, initializes state.json for tagged system.
|
||||
|
||||
## Tagged Task Lists System Architecture
|
||||
|
||||
**Data Structure**: Task Master now uses a tagged task lists system where the `tasks.json` file contains multiple named task lists as top-level keys:
|
||||
|
||||
```json
|
||||
{
|
||||
"master": {
|
||||
"tasks": [/* standard task objects */]
|
||||
},
|
||||
"feature-branch": {
|
||||
"tasks": [/* separate task context */]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- **Silent Migration**: Automatically transforms legacy `{"tasks": [...]}` format to tagged format `{"master": {"tasks": [...]}}` on first read
|
||||
- **Tag Resolution Layer**: Provides 100% backward compatibility by intercepting tagged format and returning legacy format to existing code
|
||||
- **Configuration Integration**: `global.defaultTag` and `tags` section in config.json manage tag system settings
|
||||
- **State Management**: `.taskmaster/state.json` tracks current tag, migration status, and tag-branch mappings
|
||||
- **Migration Notice**: User-friendly notification system for seamless migration experience
|
||||
|
||||
**Backward Compatibility**: All existing CLI commands and MCP tools continue to work unchanged. The tag resolution layer ensures that existing code receives the expected legacy format while the underlying storage uses the new tagged structure.
|
||||
|
||||
- **Data Flow and Module Dependencies (Updated)**:
|
||||
|
||||
- **CLI**: `bin/task-master.js` -> `scripts/dev.js` (loads `.env`) -> `scripts/modules/commands.js` -> Core Logic (`scripts/modules/*`) -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **MCP**: External Tool -> `mcp-server/server.js` -> Tool (`mcp-server/src/tools/*`) -> Direct Function (`mcp-server/src/core/direct-functions/*`) -> Core Logic (`scripts/modules/*`) -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **CLI**: `bin/task-master.js` -> `scripts/dev.js` (loads `.env`) -> `scripts/modules/commands.js` -> Core Logic (`scripts/modules/*`) -> **Tag Resolution Layer** -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **MCP**: External Tool -> `mcp-server/server.js` -> Tool (`mcp-server/src/tools/*`) -> Direct Function (`mcp-server/src/core/direct-functions/*`) -> Core Logic (`scripts/modules/*`) -> **Tag Resolution Layer** -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **Configuration**: Core logic needing non-AI settings calls `config-manager.js` getters (passing `session.env` via `explicitRoot` if from MCP). Unified AI Service internally calls `config-manager.js` getters (using `role`) for AI params and `utils.js` (`resolveEnvVariable` with `session.env`) for API keys.
|
||||
|
||||
## Silent Mode Implementation Pattern in MCP Direct Functions
|
||||
@@ -197,6 +228,7 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Integration Tests**: Located in `tests/integration/`, test interactions between modules
|
||||
- **End-to-End Tests**: Located in `tests/e2e/`, test complete workflows from a user perspective
|
||||
- **Test Fixtures**: Located in `tests/fixtures/`, provide reusable test data
|
||||
- **Tagged System Tests**: Test migration, tag resolution, and multi-context functionality
|
||||
|
||||
- **Module Design for Testability**:
|
||||
- **Explicit Dependencies**: Functions accept their dependencies as parameters rather than using globals
|
||||
@@ -205,12 +237,14 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Clear Module Interfaces**: Each module has well-defined exports that can be mocked in tests
|
||||
- **Callback Isolation**: Callbacks are defined as separate functions for easier testing
|
||||
- **Stateless Design**: Modules avoid maintaining internal state where possible
|
||||
- **Tag Resolution Testing**: Test both tagged and legacy format handling
|
||||
|
||||
- **Mock Integration Patterns**:
|
||||
- **External Libraries**: Libraries like `fs`, `commander`, and `@anthropic-ai/sdk` are mocked at module level
|
||||
- **Internal Modules**: Application modules are mocked with appropriate spy functions
|
||||
- **Testing Function Callbacks**: Callbacks are extracted from mock call arguments and tested in isolation
|
||||
- **UI Elements**: Output functions from `ui.js` are mocked to verify display calls
|
||||
- **Tagged Data Mocking**: Test both legacy and tagged task data structures
|
||||
|
||||
- **Testing Flow**:
|
||||
- Module dependencies are mocked (following Jest's hoisting behavior)
|
||||
@@ -218,6 +252,7 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- Spy functions are set up on module methods
|
||||
- Tests call the functions under test and verify behavior
|
||||
- Mocks are reset between test cases to maintain isolation
|
||||
- Tagged system behavior is tested for both migration and normal operation
|
||||
|
||||
- **Benefits of this Architecture**:
|
||||
|
||||
@@ -226,8 +261,11 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Mocking Support**: The clear dependency boundaries make mocking straightforward
|
||||
- **Test Isolation**: Each component can be tested without affecting others
|
||||
- **Callback Testing**: Function callbacks can be extracted and tested independently
|
||||
- **Multi-Context Testing**: Tagged system enables testing different task contexts independently
|
||||
- **Reusability**: Utility functions and UI components can be reused across different parts of the application.
|
||||
- **Scalability**: New features can be added as new modules or by extending existing ones without significantly impacting other parts of the application.
|
||||
- **Multi-Context Support**: Tagged task lists enable working across different contexts (branches, environments, phases) without conflicts.
|
||||
- **Backward Compatibility**: Seamless migration and tag resolution ensure existing workflows continue unchanged.
|
||||
- **Clarity**: The modular structure provides a clear separation of concerns, making the codebase easier to navigate and understand for developers.
|
||||
|
||||
This architectural overview should help AI models understand the structure and organization of the Task Master CLI codebase, enabling them to more effectively assist with code generation, modification, and understanding.
|
||||
@@ -249,6 +287,7 @@ Follow these steps to add MCP support for an existing Task Master command (see [
|
||||
- Call core logic.
|
||||
- Return `{ success: true/false, data/error, fromCache: boolean }`.
|
||||
- Export the wrapper function.
|
||||
- **Note**: Tag-aware MCP tools will be implemented in Part 2 of the tagged system.
|
||||
|
||||
3. **Update `task-master-core.js` with Import/Export**: Add imports/exports for the new `*Direct` function.
|
||||
|
||||
@@ -275,12 +314,8 @@ The `initialize_project` command provides a way to set up a new Task Master proj
|
||||
- **MCP Tool**: `initialize_project`
|
||||
- **Functionality**:
|
||||
- Creates necessary directories and files for a new project
|
||||
- Sets up `tasks.json` and initial task files
|
||||
- Configures project metadata (name, description, version)
|
||||
- Handles shell alias creation if requested
|
||||
- Works in both interactive and non-interactive modes
|
||||
- Creates necessary directories and files for a new project
|
||||
- Sets up `tasks.json` and initial task files
|
||||
- Sets up `tasks.json` with tagged structure and initial task files
|
||||
- Configures project metadata (name, description, version)
|
||||
- Initializes state.json for tag system
|
||||
- Handles shell alias creation if requested
|
||||
- Works in both interactive and non-interactive modes
|
||||
@@ -18,6 +18,7 @@ Task Master offers two primary ways to interact:
|
||||
- Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details on the MCP architecture and available tools.
|
||||
- A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
- **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
|
||||
- **Note**: MCP tools will be updated for tagged task lists support in Part 2 of the implementation.
|
||||
|
||||
2. **`task-master` CLI (For Users & Fallback)**:
|
||||
- The global `task-master` command provides a user-friendly interface for direct terminal interaction.
|
||||
@@ -25,10 +26,43 @@ Task Master offers two primary ways to interact:
|
||||
- Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
|
||||
- The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
|
||||
- Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a detailed command reference.
|
||||
- **Tagged Task Lists**: CLI fully supports the new tagged system with seamless migration.
|
||||
|
||||
## Tagged Task Lists System
|
||||
|
||||
Task Master now supports **tagged task lists** for multi-context task management:
|
||||
|
||||
- **Data Structure**: Tasks are organized into separate contexts (tags) like "master", "feature-branch", or "v2.0"
|
||||
- **Seamless Migration**: Existing projects automatically migrate to use a "master" tag with zero disruption
|
||||
- **Backward Compatibility**: All existing commands continue to work exactly as before
|
||||
- **Context Isolation**: Tasks in different tags are completely separate and isolated
|
||||
- **Silent Migration**: The first time you run any Task Master command, your existing tasks.json will be automatically migrated to the new tagged format
|
||||
- **Migration Notice**: You'll see a friendly FYI notice after migration explaining the new system
|
||||
|
||||
**Migration Example**:
|
||||
```json
|
||||
// Before (legacy format)
|
||||
{
|
||||
"tasks": [
|
||||
{ "id": 1, "title": "Setup API", ... }
|
||||
]
|
||||
}
|
||||
|
||||
// After (tagged format - automatic)
|
||||
{
|
||||
"master": {
|
||||
"tasks": [
|
||||
{ "id": 1, "title": "Setup API", ... }
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Coming in Part 2**: CLI commands for tag management (`add-tag`, `use-tag`, `list-tags`) and enhanced MCP support.
|
||||
|
||||
## Standard Development Workflow Process
|
||||
|
||||
- Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json
|
||||
- Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json with tagged structure
|
||||
- Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to see current tasks, status, and IDs
|
||||
- Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
|
||||
- Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before breaking down tasks
|
||||
@@ -107,9 +141,10 @@ Taskmaster configuration is managed through two main mechanisms:
|
||||
1. **`.taskmaster/config.json` File (Primary):**
|
||||
* Located in the project root directory.
|
||||
* Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
|
||||
* **Tagged System Settings**: Includes `global.defaultTag` (defaults to "master") and `tags` section for tag management configuration.
|
||||
* **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
|
||||
* **View/Set specific models via `task-master models` command or `models` MCP tool.**
|
||||
* Created automatically when you run `task-master models --setup` for the first time.
|
||||
* Created automatically when you run `task-master models --setup` for the first time or during tagged system migration.
|
||||
|
||||
2. **Environment Variables (`.env` / `mcp.json`):**
|
||||
* Used **only** for sensitive API keys and specific endpoint URLs.
|
||||
@@ -117,6 +152,11 @@ Taskmaster configuration is managed through two main mechanisms:
|
||||
* For MCP/Cursor integration, configure these keys in the `env` section of `.cursor/mcp.json`.
|
||||
* Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.mdc`).
|
||||
|
||||
3. **`.taskmaster/state.json` File (Tagged System State):**
|
||||
* Tracks current tag context, migration status, and tag-branch mappings.
|
||||
* Automatically created during tagged system migration.
|
||||
* Contains: `currentTag`, `lastSwitched`, `branchTagMapping`, `migrationNoticeShown`.
|
||||
|
||||
**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
|
||||
**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.cursor/mcp.json`.
|
||||
**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
|
||||
|
||||
@@ -3,7 +3,6 @@ description: Git workflow integrated with Task Master for feature development an
|
||||
globs: "**/*"
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Git Workflow with Task Master Integration
|
||||
|
||||
## **Branch Strategy**
|
||||
@@ -27,6 +26,26 @@ fix-database-issue
|
||||
random-branch-name
|
||||
```
|
||||
|
||||
## **Tagged Task Lists Integration**
|
||||
|
||||
Task Master's **tagged task lists system** provides significant benefits for Git workflows:
|
||||
|
||||
### **Multi-Context Development**
|
||||
- **Branch-Specific Tasks**: Each branch can have its own task context using tags
|
||||
- **Merge Conflict Prevention**: Tasks in different tags are completely isolated
|
||||
- **Context Switching**: Seamlessly switch between different development contexts
|
||||
- **Parallel Development**: Multiple team members can work on separate task contexts
|
||||
|
||||
### **Migration and Compatibility**
|
||||
- **Seamless Migration**: Existing projects automatically migrate to use a "master" tag
|
||||
- **Zero Disruption**: All existing Git workflows continue unchanged
|
||||
- **Backward Compatibility**: Legacy projects work exactly as before
|
||||
|
||||
### **Future Enhancements (Part 2)**
|
||||
- **Automatic Tag Creation**: Create tags based on git branch names
|
||||
- **Branch-Tag Mapping**: Automatically switch tag contexts with branch changes
|
||||
- **Git Integration**: Enhanced git branch integration features
|
||||
|
||||
## **Workflow Overview**
|
||||
|
||||
```mermaid
|
||||
@@ -34,7 +53,7 @@ flowchart TD
|
||||
A[Start: On main branch] --> B[Pull latest changes]
|
||||
B --> C[Create task branch<br/>git checkout -b task-XXX]
|
||||
C --> D[Set task status: in-progress]
|
||||
D --> E[Get task context & expand if needed]
|
||||
D --> E[Get task context & expand if needed<br/>Tasks automatically use current tag]
|
||||
E --> F[Identify next subtask]
|
||||
|
||||
F --> G[Set subtask: in-progress]
|
||||
@@ -79,13 +98,13 @@ git branch # Verify you're on main
|
||||
# 3. Create task-specific branch
|
||||
git checkout -b task-004 # For Task 4
|
||||
|
||||
# 4. Set task status in Task Master
|
||||
# 4. Set task status in Task Master (tasks automatically use current tag context)
|
||||
# Use: set_task_status tool or `task-master set-status --id=4 --status=in-progress`
|
||||
```
|
||||
|
||||
### **Phase 2: Task Analysis & Planning**
|
||||
```bash
|
||||
# 5. Get task context and expand if needed
|
||||
# 5. Get task context and expand if needed (uses current tag automatically)
|
||||
# Use: get_task tool or `task-master show 4`
|
||||
# Use: expand_task tool or `task-master expand --id=4 --research --force` (if complex)
|
||||
|
||||
@@ -215,7 +234,7 @@ Task 4: Setup Express.js Server Project - Testing complete"
|
||||
|
||||
### **Essential Commands for Git Workflow**
|
||||
```bash
|
||||
# Task management
|
||||
# Task management (uses current tag context automatically)
|
||||
task-master show <id> # Get task/subtask details
|
||||
task-master next # Find next task to work on
|
||||
task-master set-status --id=<id> --status=<status>
|
||||
@@ -302,16 +321,17 @@ Mention any dependent tasks or follow-up work needed.
|
||||
|
||||
## **Conflict Resolution**
|
||||
|
||||
### **Task Conflicts**
|
||||
### **Task Conflicts with Tagged System**
|
||||
```bash
|
||||
# If multiple people work on overlapping tasks:
|
||||
# 1. Use Task Master's move functionality to reorganize
|
||||
task-master move --from=5 --to=25 # Move conflicting task
|
||||
# With tagged task lists, merge conflicts are significantly reduced:
|
||||
# 1. Different branches can use different tag contexts
|
||||
# 2. Tasks in separate tags are completely isolated
|
||||
# 3. Use Task Master's move functionality to reorganize if needed
|
||||
|
||||
# 2. Update task dependencies
|
||||
task-master add-dependency --id=6 --depends-on=5
|
||||
|
||||
# 3. Coordinate through PR comments and task updates
|
||||
# Future (Part 2): Enhanced git integration
|
||||
# - Automatic tag creation based on branch names
|
||||
# - Branch-tag mapping for seamless context switching
|
||||
# - Git hooks for automated tag management
|
||||
```
|
||||
|
||||
### **Code Conflicts**
|
||||
@@ -359,6 +379,23 @@ git push origin --delete task-<id>
|
||||
task-master update-task --id=<id> --prompt="Task cancelled due to..."
|
||||
```
|
||||
|
||||
## **Tagged System Benefits for Git Workflows**
|
||||
|
||||
### **Multi-Team Development**
|
||||
- **Isolated Contexts**: Different teams can work on separate tag contexts without conflicts
|
||||
- **Feature Branches**: Each feature branch can have its own task context
|
||||
- **Release Management**: Separate tags for different release versions or environments
|
||||
|
||||
### **Merge Conflict Prevention**
|
||||
- **Context Separation**: Tasks in different tags don't interfere with each other
|
||||
- **Clean Merges**: Reduced likelihood of task-related merge conflicts
|
||||
- **Parallel Development**: Multiple developers can work simultaneously without task conflicts
|
||||
|
||||
### **Future Git Integration (Part 2)**
|
||||
- **Branch-Tag Mapping**: Automatic tag switching based on git branch
|
||||
- **Git Hooks**: Automated tag management during branch operations
|
||||
- **Enhanced Workflow**: Seamless integration between git branches and task contexts
|
||||
|
||||
---
|
||||
|
||||
**References:**
|
||||
|
||||
@@ -7,20 +7,20 @@ alwaysApply: true
|
||||
|
||||
This file provides a quick reference to the purpose of each rule file located in the `.cursor/rules` directory.
|
||||
|
||||
- **[`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)**: Describes the high-level architecture of the Task Master CLI application.
|
||||
- **[`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)**: Describes the high-level architecture of the Task Master CLI application, including the new tagged task lists system.
|
||||
- **[`changeset.mdc`](mdc:.cursor/rules/changeset.mdc)**: Guidelines for using Changesets (npm run changeset) to manage versioning and changelogs.
|
||||
- **[`commands.mdc`](mdc:.cursor/rules/commands.mdc)**: Guidelines for implementing CLI commands using Commander.js.
|
||||
- **[`cursor_rules.mdc`](mdc:.cursor/rules/cursor_rules.mdc)**: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
|
||||
- **[`dependencies.mdc`](mdc:.cursor/rules/dependencies.mdc)**: Guidelines for managing task dependencies and relationships.
|
||||
- **[`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)**: Guide for using Task Master to manage task-driven development workflows.
|
||||
- **[`dependencies.mdc`](mdc:.cursor/rules/dependencies.mdc)**: Guidelines for managing task dependencies and relationships across tagged task contexts.
|
||||
- **[`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)**: Guide for using Task Master to manage task-driven development workflows with tagged task lists support.
|
||||
- **[`glossary.mdc`](mdc:.cursor/rules/glossary.mdc)**: This file; provides a glossary of other Cursor rules.
|
||||
- **[`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)**: Guidelines for implementing and interacting with the Task Master MCP Server.
|
||||
- **[`new_features.mdc`](mdc:.cursor/rules/new_features.mdc)**: Guidelines for integrating new features into the Task Master CLI.
|
||||
- **[`new_features.mdc`](mdc:.cursor/rules/new_features.mdc)**: Guidelines for integrating new features into the Task Master CLI with tagged system considerations.
|
||||
- **[`self_improve.mdc`](mdc:.cursor/rules/self_improve.mdc)**: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
|
||||
- **[`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)**: Comprehensive reference for Taskmaster MCP tools and CLI commands.
|
||||
- **[`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)**: Guidelines for implementing task management operations.
|
||||
- **[`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)**: Comprehensive reference for Taskmaster MCP tools and CLI commands with tagged task lists information.
|
||||
- **[`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)**: Guidelines for implementing task management operations with tagged task lists system support.
|
||||
- **[`tests.mdc`](mdc:.cursor/rules/tests.mdc)**: Guidelines for implementing and maintaining tests for Task Master CLI.
|
||||
- **[`ui.mdc`](mdc:.cursor/rules/ui.mdc)**: Guidelines for implementing and maintaining user interface components.
|
||||
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions.
|
||||
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions including tagged task lists utilities.
|
||||
- **[`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc)**: Guidelines for integrating AI usage telemetry across Task Master.
|
||||
|
||||
|
||||
@@ -634,3 +634,287 @@ When implementing project initialization commands:
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Feature Planning
|
||||
|
||||
- **Core Logic First**:
|
||||
- ✅ DO: Implement core logic in `scripts/modules/` before CLI or MCP interfaces
|
||||
- ✅ DO: Consider tagged task lists system compatibility from the start
|
||||
- ✅ DO: Design functions to work with both legacy and tagged data formats
|
||||
- ✅ DO: Use tag resolution functions (`getTasksForTag`, `setTasksForTag`) for task data access
|
||||
- ❌ DON'T: Directly manipulate tagged data structure in new features
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Design tagged-aware core functions
|
||||
async function newFeatureCore(tasksPath, featureParams, options = {}) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Perform feature logic on tasks array
|
||||
const result = performFeatureLogic(tasks, featureParams);
|
||||
|
||||
// Save back using tag resolution
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
- **Backward Compatibility**:
|
||||
- ✅ DO: Ensure new features work with existing projects seamlessly
|
||||
- ✅ DO: Test with both legacy and tagged task data formats
|
||||
- ✅ DO: Support silent migration during feature usage
|
||||
- ❌ DON'T: Break existing workflows when adding tagged system features
|
||||
|
||||
## CLI Command Implementation
|
||||
|
||||
- **Command Structure**:
|
||||
- ✅ DO: Follow the established pattern in [`commands.js`](mdc:scripts/modules/commands.js)
|
||||
- ✅ DO: Use Commander.js for argument parsing
|
||||
- ✅ DO: Include comprehensive help text and examples
|
||||
- ✅ DO: Support tagged task context awareness
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement CLI commands with tagged system awareness
|
||||
program
|
||||
.command('new-feature')
|
||||
.description('Description of the new feature with tagged task lists support')
|
||||
.option('-t, --tag <tag>', 'Specify tag context (defaults to current tag)')
|
||||
.option('-p, --param <value>', 'Feature-specific parameter')
|
||||
.option('--force', 'Force operation without confirmation')
|
||||
.action(async (options) => {
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) {
|
||||
console.error('Not in a Task Master project directory');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Use specified tag or current tag
|
||||
const targetTag = options.tag || getCurrentTag() || 'master';
|
||||
|
||||
const result = await newFeatureCore(
|
||||
path.join(projectRoot, '.taskmaster', 'tasks', 'tasks.json'),
|
||||
{ param: options.param },
|
||||
{
|
||||
force: options.force,
|
||||
targetTag: targetTag,
|
||||
outputFormat: 'text'
|
||||
}
|
||||
);
|
||||
|
||||
console.log('Feature executed successfully');
|
||||
} catch (error) {
|
||||
console.error(`Error: ${error.message}`);
|
||||
process.exit(1);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
- **Error Handling**:
|
||||
- ✅ DO: Provide clear error messages for common failures
|
||||
- ✅ DO: Handle tagged system migration errors gracefully
|
||||
- ✅ DO: Include suggestion for resolution when possible
|
||||
- ✅ DO: Exit with appropriate codes for scripting
|
||||
|
||||
## MCP Tool Implementation
|
||||
|
||||
- **Direct Function Pattern**:
|
||||
- ✅ DO: Create direct function wrappers in `mcp-server/src/core/direct-functions/`
|
||||
- ✅ DO: Follow silent mode patterns to prevent console output interference
|
||||
- ✅ DO: Use `findTasksJsonPath` for consistent path resolution
|
||||
- ✅ DO: Ensure tagged system compatibility
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement MCP direct functions with tagged awareness
|
||||
export async function newFeatureDirect(args, log, context = {}) {
|
||||
try {
|
||||
const tasksPath = findTasksJsonPath(args, log);
|
||||
|
||||
// Enable silent mode for clean MCP responses
|
||||
enableSilentMode();
|
||||
|
||||
try {
|
||||
const result = await newFeatureCore(
|
||||
tasksPath,
|
||||
{ param: args.param },
|
||||
{
|
||||
force: args.force,
|
||||
targetTag: args.tag || 'master', // Support tag specification
|
||||
mcpLog: log,
|
||||
session: context.session,
|
||||
outputFormat: 'json'
|
||||
}
|
||||
);
|
||||
|
||||
return {
|
||||
success: true,
|
||||
data: result,
|
||||
fromCache: false
|
||||
};
|
||||
} finally {
|
||||
disableSilentMode();
|
||||
}
|
||||
} catch (error) {
|
||||
log.error(`Error in newFeatureDirect: ${error.message}`);
|
||||
return {
|
||||
success: false,
|
||||
error: { code: 'FEATURE_ERROR', message: error.message },
|
||||
fromCache: false
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **Tool Registration**:
|
||||
- ✅ DO: Create tool definitions in `mcp-server/src/tools/`
|
||||
- ✅ DO: Use Zod for parameter validation
|
||||
- ✅ DO: Include optional tag parameter for multi-context support
|
||||
- ✅ DO: Follow established naming conventions
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Register MCP tools with tagged system support
|
||||
export function registerNewFeatureTool(server) {
|
||||
server.addTool({
|
||||
name: "new_feature",
|
||||
description: "Description of the new feature with tagged task lists support",
|
||||
inputSchema: z.object({
|
||||
param: z.string().describe("Feature-specific parameter"),
|
||||
tag: z.string().optional().describe("Target tag context (defaults to current tag)"),
|
||||
force: z.boolean().optional().describe("Force operation without confirmation"),
|
||||
projectRoot: z.string().optional().describe("Project root directory")
|
||||
}),
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
try {
|
||||
const result = await newFeatureDirect(
|
||||
{ ...args, projectRoot: args.projectRoot },
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
return handleApiResult(result, log);
|
||||
} catch (error) {
|
||||
return handleApiResult({
|
||||
success: false,
|
||||
error: { code: 'EXECUTION_ERROR', message: error.message }
|
||||
}, log);
|
||||
}
|
||||
})
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- **Unit Tests**:
|
||||
- ✅ DO: Test core logic independently with both data formats
|
||||
- ✅ DO: Mock file system operations appropriately
|
||||
- ✅ DO: Test tag resolution behavior
|
||||
- ✅ DO: Verify migration compatibility
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Test new features with tagged system awareness
|
||||
describe('newFeature', () => {
|
||||
beforeEach(() => {
|
||||
jest.clearAllMocks();
|
||||
});
|
||||
|
||||
it('should work with legacy task format', async () => {
|
||||
const legacyData = { tasks: [/* test data */] };
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(legacyData));
|
||||
|
||||
const result = await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
expect(result).toBeDefined();
|
||||
// Test legacy format handling
|
||||
});
|
||||
|
||||
it('should work with tagged task format', async () => {
|
||||
const taggedData = {
|
||||
master: { tasks: [/* test data */] },
|
||||
feature: { tasks: [/* test data */] }
|
||||
};
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(taggedData));
|
||||
|
||||
const result = await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
expect(result).toBeDefined();
|
||||
// Test tagged format handling
|
||||
});
|
||||
|
||||
it('should handle tag migration during feature usage', async () => {
|
||||
const legacyData = { tasks: [/* test data */] };
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(legacyData));
|
||||
|
||||
await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
// Verify migration occurred
|
||||
expect(fs.writeFileSync).toHaveBeenCalledWith(
|
||||
'/test/tasks.json',
|
||||
expect.stringContaining('"master"')
|
||||
);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
- **Integration Tests**:
|
||||
- ✅ DO: Test CLI and MCP interfaces with real task data
|
||||
- ✅ DO: Verify end-to-end workflows across tag contexts
|
||||
- ✅ DO: Test error scenarios and recovery
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
- **Rule Updates**:
|
||||
- ✅ DO: Update relevant `.cursor/rules/*.mdc` files
|
||||
- ✅ DO: Include tagged system considerations in architecture docs
|
||||
- ✅ DO: Add examples showing multi-context usage
|
||||
- ✅ DO: Update workflow documentation as needed
|
||||
|
||||
- **User Documentation**:
|
||||
- ✅ DO: Add feature documentation to `/docs` folder
|
||||
- ✅ DO: Include tagged system usage examples
|
||||
- ✅ DO: Update command reference documentation
|
||||
- ✅ DO: Provide migration notes if relevant
|
||||
|
||||
## Migration Considerations
|
||||
|
||||
- **Silent Migration Support**:
|
||||
- ✅ DO: Ensure new features trigger migration when needed
|
||||
- ✅ DO: Handle migration errors gracefully in feature code
|
||||
- ✅ DO: Test feature behavior with pre-migration projects
|
||||
- ❌ DON'T: Assume projects are already migrated
|
||||
|
||||
- **Tag Context Handling**:
|
||||
- ✅ DO: Default to current tag when not specified
|
||||
- ✅ DO: Support explicit tag selection in advanced features
|
||||
- ✅ DO: Validate tag existence before operations
|
||||
- ✅ DO: Provide clear messaging about tag context
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
- **Efficient Tag Operations**:
|
||||
- ✅ DO: Minimize file I/O operations per feature execution
|
||||
- ✅ DO: Cache tag resolution results when appropriate
|
||||
- ✅ DO: Use streaming for large task datasets
|
||||
- ❌ DON'T: Load all tags when only one is needed
|
||||
|
||||
- **Memory Management**:
|
||||
- ✅ DO: Process large task lists efficiently
|
||||
- ✅ DO: Clean up temporary data structures
|
||||
- ✅ DO: Avoid keeping all tag data in memory simultaneously
|
||||
|
||||
## Deployment and Versioning
|
||||
|
||||
- **Changesets**:
|
||||
- ✅ DO: Create appropriate changesets for new features
|
||||
- ✅ DO: Use semantic versioning (minor for new features)
|
||||
- ✅ DO: Include tagged system information in release notes
|
||||
- ✅ DO: Document breaking changes if any
|
||||
|
||||
- **Feature Flags**:
|
||||
- ✅ DO: Consider feature flags for experimental functionality
|
||||
- ✅ DO: Ensure tagged system features work with flags
|
||||
- ✅ DO: Provide clear documentation about flag usage
|
||||
|
||||
By following these guidelines, new features will integrate smoothly with the Task Master ecosystem while supporting the enhanced tagged task lists system for multi-context development workflows.
|
||||
|
||||
@@ -11,6 +11,8 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
|
||||
**Important:** Several MCP tools involve AI processing... The AI-powered tools include `parse_prd`, `analyze_project_complexity`, `update_subtask`, `update_task`, `update`, `expand_all`, `expand_task`, and `add_task`.
|
||||
|
||||
**Tagged Task Lists System:** Task Master now supports tagged task lists for multi-context task management. Existing projects automatically migrate to use a "master" tag with zero disruption. All commands continue to work unchanged while providing the foundation for enhanced multi-context workflows. MCP tools will be updated for full tagged support in Part 2 of the implementation.
|
||||
|
||||
---
|
||||
|
||||
## Initialization & Setup
|
||||
|
||||
@@ -3,9 +3,19 @@ description: Guidelines for implementing task management operations
|
||||
globs: scripts/modules/task-manager.js
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Task Management Guidelines
|
||||
|
||||
## Tagged Task Lists System
|
||||
|
||||
Task Master now uses a **tagged task lists system** for multi-context task management:
|
||||
|
||||
- **Data Structure**: Tasks are organized into separate contexts (tags) within `tasks.json`
|
||||
- **Legacy Format**: `{"tasks": [...]}`
|
||||
- **Tagged Format**: `{"master": {"tasks": [...]}, "feature-branch": {"tasks": [...]}}`
|
||||
- **Silent Migration**: Legacy format automatically converts to tagged format on first use
|
||||
- **Tag Resolution**: Core functions receive legacy format for 100% backward compatibility
|
||||
- **Default Tag**: "master" is used for all existing and new tasks unless otherwise specified
|
||||
|
||||
## Task Structure Standards
|
||||
|
||||
- **Core Task Properties**:
|
||||
@@ -28,6 +38,25 @@ alwaysApply: false
|
||||
};
|
||||
```
|
||||
|
||||
- **Tagged Data Structure**:
|
||||
- ✅ DO: Access tasks through tag resolution layer
|
||||
- ✅ DO: Use `getTasksForTag(data, tagName)` to retrieve tasks for a specific tag
|
||||
- ✅ DO: Use `setTasksForTag(data, tagName, tasks)` to update tasks for a specific tag
|
||||
- ❌ DON'T: Directly manipulate the tagged structure in core functions
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use tag resolution functions
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Manipulate tasks as normal...
|
||||
|
||||
// Save back to the tagged structure
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
- **Subtask Structure**:
|
||||
- ✅ DO: Use consistent properties across subtasks
|
||||
- ✅ DO: Maintain simple numeric IDs within parent tasks
|
||||
@@ -48,53 +77,56 @@ alwaysApply: false
|
||||
## Task Creation and Parsing
|
||||
|
||||
- **ID Management**:
|
||||
- ✅ DO: Assign unique sequential IDs to tasks
|
||||
- ✅ DO: Calculate the next ID based on existing tasks
|
||||
- ❌ DON'T: Hardcode or reuse IDs
|
||||
- ✅ DO: Assign unique sequential IDs to tasks within each tag context
|
||||
- ✅ DO: Calculate the next ID based on existing tasks in the current tag
|
||||
- ❌ DON'T: Hardcode or reuse IDs within the same tag
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Calculate the next available ID
|
||||
const highestId = Math.max(...data.tasks.map(t => t.id));
|
||||
// ✅ DO: Calculate the next available ID within the current tag
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
const highestId = Math.max(...tasks.map(t => t.id));
|
||||
const nextTaskId = highestId + 1;
|
||||
```
|
||||
|
||||
- **PRD Parsing**:
|
||||
- ✅ DO: Extract tasks from PRD documents using AI
|
||||
- ✅ DO: Create tasks in the current tag context (defaults to "master")
|
||||
- ✅ DO: Provide clear prompts to guide AI task generation
|
||||
- ✅ DO: Validate and clean up AI-generated tasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Validate AI responses
|
||||
try {
|
||||
// Parse the JSON response
|
||||
taskData = JSON.parse(jsonContent);
|
||||
|
||||
// Check that we have the required fields
|
||||
if (!taskData.title || !taskData.description) {
|
||||
throw new Error("Missing required fields in the generated task");
|
||||
}
|
||||
} catch (error) {
|
||||
log('error', "Failed to parse AI's response as valid task JSON:", error);
|
||||
process.exit(1);
|
||||
}
|
||||
// ✅ DO: Parse into current tag context
|
||||
const tasksData = readJSON(tasksPath) || {};
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
|
||||
// Parse tasks and add to current tag
|
||||
const newTasks = await parseTasksFromPRD(prdContent);
|
||||
setTasksForTag(tasksData, currentTag, newTasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
## Task Updates and Modifications
|
||||
|
||||
- **Status Management**:
|
||||
- ✅ DO: Provide functions for updating task status
|
||||
- ✅ DO: Provide functions for updating task status within current tag context
|
||||
- ✅ DO: Handle both individual tasks and subtasks
|
||||
- ✅ DO: Consider subtask status when updating parent tasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle status updates for both tasks and subtasks
|
||||
// ✅ DO: Handle status updates within tagged context
|
||||
async function setTaskStatus(tasksPath, taskIdInput, newStatus) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Check if it's a subtask (e.g., "1.2")
|
||||
if (taskIdInput.includes('.')) {
|
||||
const [parentId, subtaskId] = taskIdInput.split('.').map(id => parseInt(id, 10));
|
||||
|
||||
// Find the parent task and subtask
|
||||
const parentTask = data.tasks.find(t => t.id === parentId);
|
||||
const parentTask = tasks.find(t => t.id === parentId);
|
||||
const subtask = parentTask.subtasks.find(st => st.id === subtaskId);
|
||||
|
||||
// Update subtask status
|
||||
@@ -109,7 +141,7 @@ alwaysApply: false
|
||||
}
|
||||
} else {
|
||||
// Handle regular task
|
||||
const task = data.tasks.find(t => t.id === parseInt(taskIdInput, 10));
|
||||
const task = tasks.find(t => t.id === parseInt(taskIdInput, 10));
|
||||
task.status = newStatus;
|
||||
|
||||
// If marking as done, also mark subtasks
|
||||
@@ -119,16 +151,24 @@ alwaysApply: false
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
// Save updated tasks back to tagged structure
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
}
|
||||
```
|
||||
|
||||
- **Task Expansion**:
|
||||
- ✅ DO: Use AI to generate detailed subtasks
|
||||
- ✅ DO: Use AI to generate detailed subtasks within current tag context
|
||||
- ✅ DO: Consider complexity analysis for subtask counts
|
||||
- ✅ DO: Ensure proper IDs for newly created subtasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Generate appropriate subtasks based on complexity
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
if (taskAnalysis) {
|
||||
log('info', `Found complexity analysis for task ${taskId}: Score ${taskAnalysis.complexityScore}/10`);
|
||||
|
||||
@@ -138,6 +178,11 @@ alwaysApply: false
|
||||
log('info', `Using recommended number of subtasks: ${numSubtasks}`);
|
||||
}
|
||||
}
|
||||
|
||||
// Generate subtasks and save back
|
||||
// ... subtask generation logic ...
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
## Task File Generation
|
||||
@@ -155,67 +200,65 @@ alwaysApply: false
|
||||
|
||||
// Format dependencies with their status
|
||||
if (task.dependencies && task.dependencies.length > 0) {
|
||||
content += `# Dependencies: ${formatDependenciesWithStatus(task.dependencies, data.tasks)}\n`;
|
||||
content += `# Dependencies: ${formatDependenciesWithStatus(task.dependencies, tasks)}\n`;
|
||||
} else {
|
||||
content += '# Dependencies: None\n';
|
||||
}
|
||||
```
|
||||
|
||||
- **Subtask Inclusion**:
|
||||
- ✅ DO: Include subtasks in parent task files
|
||||
- ✅ DO: Use consistent indentation for subtask sections
|
||||
- ✅ DO: Display subtask dependencies with proper formatting
|
||||
- **Tagged Context Awareness**:
|
||||
- ✅ DO: Generate task files from current tag context
|
||||
- ✅ DO: Include tag information in generated files
|
||||
- ❌ DON'T: Mix tasks from different tags in file generation
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Format subtasks correctly in task files
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
content += '\n# Subtasks:\n';
|
||||
// ✅ DO: Generate files for current tag context
|
||||
async function generateTaskFiles(tasksPath, outputDir) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
task.subtasks.forEach(subtask => {
|
||||
content += `## ${subtask.id}. ${subtask.title} [${subtask.status || 'pending'}]\n`;
|
||||
|
||||
// Format subtask dependencies
|
||||
if (subtask.dependencies && subtask.dependencies.length > 0) {
|
||||
// Format the dependencies
|
||||
content += `### Dependencies: ${formattedDeps}\n`;
|
||||
} else {
|
||||
content += '### Dependencies: None\n';
|
||||
}
|
||||
|
||||
content += `### Description: ${subtask.description || ''}\n`;
|
||||
content += '### Details:\n';
|
||||
content += (subtask.details || '').split('\n').map(line => line).join('\n');
|
||||
content += '\n\n';
|
||||
});
|
||||
// Add tag context to file header
|
||||
let content = `# Tag Context: ${currentTag}\n`;
|
||||
content += `# Task ID: ${task.id}\n`;
|
||||
// ... rest of file generation
|
||||
}
|
||||
```
|
||||
|
||||
## Task Listing and Display
|
||||
|
||||
- **Filtering and Organization**:
|
||||
- ✅ DO: Allow filtering tasks by status
|
||||
- ✅ DO: Allow filtering tasks by status within current tag context
|
||||
- ✅ DO: Handle subtask display in lists
|
||||
- ✅ DO: Use consistent table formats
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement clear filtering and organization
|
||||
// ✅ DO: Implement clear filtering within tag context
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Filter tasks by status if specified
|
||||
const filteredTasks = statusFilter
|
||||
? data.tasks.filter(task =>
|
||||
? tasks.filter(task =>
|
||||
task.status && task.status.toLowerCase() === statusFilter.toLowerCase())
|
||||
: data.tasks;
|
||||
: tasks;
|
||||
```
|
||||
|
||||
- **Progress Tracking**:
|
||||
- ✅ DO: Calculate and display completion statistics
|
||||
- ✅ DO: Calculate and display completion statistics for current tag
|
||||
- ✅ DO: Track both task and subtask completion
|
||||
- ✅ DO: Use visual progress indicators
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Track and display progress
|
||||
// ✅ DO: Track and display progress within tag context
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Calculate completion statistics
|
||||
const totalTasks = data.tasks.length;
|
||||
const completedTasks = data.tasks.filter(task =>
|
||||
const totalTasks = tasks.length;
|
||||
const completedTasks = tasks.filter(task =>
|
||||
task.status === 'done' || task.status === 'completed').length;
|
||||
const completionPercentage = totalTasks > 0 ? (completedTasks / totalTasks) * 100 : 0;
|
||||
|
||||
@@ -223,7 +266,7 @@ alwaysApply: false
|
||||
let totalSubtasks = 0;
|
||||
let completedSubtasks = 0;
|
||||
|
||||
data.tasks.forEach(task => {
|
||||
tasks.forEach(task => {
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
totalSubtasks += task.subtasks.length;
|
||||
completedSubtasks += task.subtasks.filter(st =>
|
||||
@@ -232,99 +275,52 @@ alwaysApply: false
|
||||
});
|
||||
```
|
||||
|
||||
## Complexity Analysis
|
||||
## Migration and Compatibility
|
||||
|
||||
- **Scoring System**:
|
||||
- ✅ DO: Use AI to analyze task complexity
|
||||
- ✅ DO: Include complexity scores (1-10)
|
||||
- ✅ DO: Generate specific expansion recommendations
|
||||
- **Silent Migration Handling**:
|
||||
- ✅ DO: Implement silent migration in `readJSON()` function
|
||||
- ✅ DO: Detect legacy format and convert automatically
|
||||
- ✅ DO: Preserve all existing task data during migration
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle complexity analysis properly
|
||||
const report = {
|
||||
meta: {
|
||||
generatedAt: new Date().toISOString(),
|
||||
tasksAnalyzed: tasksData.tasks.length,
|
||||
thresholdScore: thresholdScore,
|
||||
projectName: tasksData.meta?.projectName || 'Your Project Name',
|
||||
usedResearch: useResearch
|
||||
},
|
||||
complexityAnalysis: complexityAnalysis
|
||||
};
|
||||
```
|
||||
|
||||
- **Analysis-Based Workflow**:
|
||||
- ✅ DO: Use complexity reports to guide task expansion
|
||||
- ✅ DO: Prioritize complex tasks for more detailed breakdown
|
||||
- ✅ DO: Use expansion prompts from complexity analysis
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Apply complexity analysis to workflow
|
||||
// Sort tasks by complexity if report exists, otherwise by ID
|
||||
if (complexityReport && complexityReport.complexityAnalysis) {
|
||||
log('info', 'Sorting tasks by complexity...');
|
||||
// ✅ DO: Handle silent migration (implemented in utils.js)
|
||||
function readJSON(filepath) {
|
||||
let data = JSON.parse(fs.readFileSync(filepath, 'utf8'));
|
||||
|
||||
// Create a map of task IDs to complexity scores
|
||||
const complexityMap = new Map();
|
||||
complexityReport.complexityAnalysis.forEach(analysis => {
|
||||
complexityMap.set(analysis.taskId, analysis.complexityScore);
|
||||
});
|
||||
// Silent migration for tasks.json files
|
||||
if (data.tasks && Array.isArray(data.tasks) && !data.master && isTasksFile) {
|
||||
const migratedData = {
|
||||
master: {
|
||||
tasks: data.tasks
|
||||
}
|
||||
};
|
||||
writeJSON(filepath, migratedData);
|
||||
data = migratedData;
|
||||
}
|
||||
|
||||
// Sort tasks by complexity score (high to low)
|
||||
tasksToExpand.sort((a, b) => {
|
||||
const scoreA = complexityMap.get(a.id) || 0;
|
||||
const scoreB = complexityMap.get(b.id) || 0;
|
||||
return scoreB - scoreA;
|
||||
});
|
||||
return data;
|
||||
}
|
||||
```
|
||||
|
||||
## Next Task Selection
|
||||
|
||||
- **Eligibility Criteria**:
|
||||
- ✅ DO: Consider dependencies when finding next tasks
|
||||
- ✅ DO: Prioritize by task priority and dependency count
|
||||
- ✅ DO: Skip completed tasks
|
||||
- **Tag Resolution**:
|
||||
- ✅ DO: Use tag resolution functions to maintain backward compatibility
|
||||
- ✅ DO: Return legacy format to core functions
|
||||
- ❌ DON'T: Expose tagged structure to existing core logic
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use proper task prioritization logic
|
||||
function findNextTask(tasks) {
|
||||
// Get all completed task IDs
|
||||
const completedTaskIds = new Set(
|
||||
tasks
|
||||
.filter(t => t.status === 'done' || t.status === 'completed')
|
||||
.map(t => t.id)
|
||||
);
|
||||
// ✅ DO: Use tag resolution layer
|
||||
function getTasksForTag(data, tagName) {
|
||||
if (data.tasks && Array.isArray(data.tasks)) {
|
||||
// Legacy format - return as-is
|
||||
return data.tasks;
|
||||
}
|
||||
|
||||
// Filter for pending tasks whose dependencies are all satisfied
|
||||
const eligibleTasks = tasks.filter(task =>
|
||||
(task.status === 'pending' || task.status === 'in-progress') &&
|
||||
task.dependencies &&
|
||||
task.dependencies.every(depId => completedTaskIds.has(depId))
|
||||
);
|
||||
if (data[tagName] && data[tagName].tasks) {
|
||||
// Tagged format - return tasks for specified tag
|
||||
return data[tagName].tasks;
|
||||
}
|
||||
|
||||
// Sort by priority, dependency count, and ID
|
||||
const priorityValues = { 'high': 3, 'medium': 2, 'low': 1 };
|
||||
|
||||
const nextTask = eligibleTasks.sort((a, b) => {
|
||||
// Priority first
|
||||
const priorityA = priorityValues[a.priority || 'medium'] || 2;
|
||||
const priorityB = priorityValues[b.priority || 'medium'] || 2;
|
||||
|
||||
if (priorityB !== priorityA) {
|
||||
return priorityB - priorityA; // Higher priority first
|
||||
}
|
||||
|
||||
// Dependency count next
|
||||
if (a.dependencies.length !== b.dependencies.length) {
|
||||
return a.dependencies.length - b.dependencies.length; // Fewer dependencies first
|
||||
}
|
||||
|
||||
// ID last
|
||||
return a.id - b.id; // Lower ID first
|
||||
})[0];
|
||||
|
||||
return nextTask;
|
||||
return [];
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Guidelines for implementing utility functions
|
||||
globs: scripts/modules/utils.js, mcp-server/src/**/*
|
||||
description:
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
# Utility Function Guidelines
|
||||
@@ -600,4 +600,578 @@ export {
|
||||
- ✅ DO: Sort discovered task IDs numerically for better readability
|
||||
- ❌ DON'T: Replace explicit user task selections with fuzzy results
|
||||
|
||||
Refer to [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for detailed implementation patterns, [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
Refer to [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for detailed implementation patterns, [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
|
||||
## File System Operations
|
||||
|
||||
- **JSON File Handling**:
|
||||
- ✅ DO: Use `readJSON` and `writeJSON` for all JSON operations
|
||||
- ✅ DO: Include error handling for file operations
|
||||
- ✅ DO: Validate JSON structure after reading
|
||||
- ❌ DON'T: Use raw `fs.readFileSync` or `fs.writeFileSync` for JSON
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use utility functions with error handling
|
||||
function readJSON(filepath) {
|
||||
try {
|
||||
if (!fs.existsSync(filepath)) {
|
||||
return null; // or appropriate default
|
||||
}
|
||||
|
||||
let data = JSON.parse(fs.readFileSync(filepath, 'utf8'));
|
||||
|
||||
// Silent migration for tasks.json files: Transform old format to tagged format
|
||||
const isTasksFile = filepath.includes('tasks.json') || path.basename(filepath) === 'tasks.json';
|
||||
|
||||
if (data && data.tasks && Array.isArray(data.tasks) && !data.master && isTasksFile) {
|
||||
// Migrate from old format { "tasks": [...] } to new format { "master": { "tasks": [...] } }
|
||||
const migratedData = {
|
||||
master: {
|
||||
tasks: data.tasks
|
||||
}
|
||||
};
|
||||
|
||||
writeJSON(filepath, migratedData);
|
||||
|
||||
// Set global flag for CLI notice and perform complete migration
|
||||
global.taskMasterMigrationOccurred = true;
|
||||
performCompleteTagMigration(filepath);
|
||||
|
||||
data = migratedData;
|
||||
}
|
||||
|
||||
return data;
|
||||
} catch (error) {
|
||||
log('error', `Failed to read JSON from ${filepath}: ${error.message}`);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
function writeJSON(filepath, data) {
|
||||
try {
|
||||
const dirPath = path.dirname(filepath);
|
||||
if (!fs.existsSync(dirPath)) {
|
||||
fs.mkdirSync(dirPath, { recursive: true });
|
||||
}
|
||||
fs.writeFileSync(filepath, JSON.stringify(data, null, 2));
|
||||
} catch (error) {
|
||||
log('error', `Failed to write JSON to ${filepath}: ${error.message}`);
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **Path Resolution**:
|
||||
- ✅ DO: Use `path.join()` for cross-platform path construction
|
||||
- ✅ DO: Use `path.resolve()` for absolute paths
|
||||
- ✅ DO: Validate paths before file operations
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle paths correctly
|
||||
function findProjectRoot(startPath = process.cwd()) {
|
||||
let currentPath = path.resolve(startPath);
|
||||
const rootPath = path.parse(currentPath).root;
|
||||
|
||||
while (currentPath !== rootPath) {
|
||||
const taskMasterPath = path.join(currentPath, '.taskmaster');
|
||||
if (fs.existsSync(taskMasterPath)) {
|
||||
return currentPath;
|
||||
}
|
||||
currentPath = path.dirname(currentPath);
|
||||
}
|
||||
|
||||
return null; // Not found
|
||||
}
|
||||
```
|
||||
|
||||
## Tagged Task Lists System Utilities
|
||||
|
||||
- **Tag Resolution Functions**:
|
||||
- ✅ DO: Use tag resolution layer for all task data access
|
||||
- ✅ DO: Provide backward compatibility with legacy format
|
||||
- ✅ DO: Default to "master" tag when no tag is specified
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement tag resolution functions
|
||||
function getTasksForTag(data, tagName = 'master') {
|
||||
if (!data) {
|
||||
return [];
|
||||
}
|
||||
|
||||
// Handle legacy format - direct tasks array
|
||||
if (data.tasks && Array.isArray(data.tasks)) {
|
||||
return data.tasks;
|
||||
}
|
||||
|
||||
// Handle tagged format - tasks under specific tag
|
||||
if (data[tagName] && data[tagName].tasks && Array.isArray(data[tagName].tasks)) {
|
||||
return data[tagName].tasks;
|
||||
}
|
||||
|
||||
return [];
|
||||
}
|
||||
|
||||
function setTasksForTag(data, tagName = 'master', tasks) {
|
||||
// Ensure data object exists
|
||||
if (!data) {
|
||||
data = {};
|
||||
}
|
||||
|
||||
// Create tag structure if it doesn't exist
|
||||
if (!data[tagName]) {
|
||||
data[tagName] = {};
|
||||
}
|
||||
|
||||
// Set tasks for the tag
|
||||
data[tagName].tasks = tasks;
|
||||
|
||||
return data;
|
||||
}
|
||||
|
||||
function getCurrentTag() {
|
||||
// Get current tag from state.json or default to 'master'
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) return 'master';
|
||||
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
if (fs.existsSync(statePath)) {
|
||||
const state = readJSON(statePath);
|
||||
return state.currentTag || 'master';
|
||||
}
|
||||
} catch (error) {
|
||||
log('debug', `Error reading current tag: ${error.message}`);
|
||||
}
|
||||
|
||||
return 'master';
|
||||
}
|
||||
```
|
||||
|
||||
- **Migration Functions**:
|
||||
- ✅ DO: Implement complete migration for all related files
|
||||
- ✅ DO: Handle configuration and state file creation
|
||||
- ✅ DO: Provide migration status tracking
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement complete migration system
|
||||
function performCompleteTagMigration(tasksJsonPath) {
|
||||
try {
|
||||
// Derive project root from tasks.json path
|
||||
const projectRoot = findProjectRoot(path.dirname(tasksJsonPath)) || path.dirname(tasksJsonPath);
|
||||
|
||||
// 1. Migrate config.json - add defaultTag and tags section
|
||||
const configPath = path.join(projectRoot, '.taskmaster', 'config.json');
|
||||
if (fs.existsSync(configPath)) {
|
||||
migrateConfigJson(configPath);
|
||||
}
|
||||
|
||||
// 2. Create state.json if it doesn't exist
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
if (!fs.existsSync(statePath)) {
|
||||
createStateJson(statePath);
|
||||
}
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Completed tagged task lists migration for project');
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error during complete tag migration: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function migrateConfigJson(configPath) {
|
||||
try {
|
||||
const config = readJSON(configPath);
|
||||
if (!config) return;
|
||||
|
||||
let modified = false;
|
||||
|
||||
// Add global.defaultTag if missing
|
||||
if (!config.global) {
|
||||
config.global = {};
|
||||
}
|
||||
if (!config.global.defaultTag) {
|
||||
config.global.defaultTag = 'master';
|
||||
modified = true;
|
||||
}
|
||||
|
||||
// Add tags section if missing
|
||||
if (!config.tags) {
|
||||
config.tags = {
|
||||
enabledGitworkflow: false,
|
||||
autoSwitchTagWithBranch: false
|
||||
};
|
||||
modified = true;
|
||||
}
|
||||
|
||||
if (modified) {
|
||||
writeJSON(configPath, config);
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Updated config.json with tagged task system settings');
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error migrating config.json: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function createStateJson(statePath) {
|
||||
try {
|
||||
const initialState = {
|
||||
currentTag: 'master',
|
||||
lastSwitched: new Date().toISOString(),
|
||||
branchTagMapping: {},
|
||||
migrationNoticeShown: false
|
||||
};
|
||||
|
||||
writeJSON(statePath, initialState);
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Created initial state.json for tagged task system');
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error creating state.json: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function markMigrationForNotice() {
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) return;
|
||||
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
const state = readJSON(statePath) || {};
|
||||
|
||||
state.migrationNoticeShown = false; // Reset to show notice
|
||||
writeJSON(statePath, state);
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error marking migration for notice: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Logging Functions
|
||||
|
||||
- **Consistent Logging**:
|
||||
- ✅ DO: Use the central `log` function for all output
|
||||
- ✅ DO: Use appropriate log levels (info, warn, error, debug)
|
||||
- ✅ DO: Support silent mode for programmatic usage
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement consistent logging with silent mode
|
||||
let silentMode = false;
|
||||
|
||||
function log(level, ...messages) {
|
||||
if (silentMode && level !== 'error') {
|
||||
return; // Suppress non-error logs in silent mode
|
||||
}
|
||||
|
||||
const timestamp = new Date().toISOString();
|
||||
const formattedMessage = messages.join(' ');
|
||||
|
||||
switch (level) {
|
||||
case 'error':
|
||||
console.error(`[ERROR] ${formattedMessage}`);
|
||||
break;
|
||||
case 'warn':
|
||||
console.warn(`[WARN] ${formattedMessage}`);
|
||||
break;
|
||||
case 'info':
|
||||
console.log(`[INFO] ${formattedMessage}`);
|
||||
break;
|
||||
case 'debug':
|
||||
if (getDebugFlag()) {
|
||||
console.log(`[DEBUG] ${formattedMessage}`);
|
||||
}
|
||||
break;
|
||||
default:
|
||||
console.log(formattedMessage);
|
||||
}
|
||||
}
|
||||
|
||||
function enableSilentMode() {
|
||||
silentMode = true;
|
||||
}
|
||||
|
||||
function disableSilentMode() {
|
||||
silentMode = false;
|
||||
}
|
||||
|
||||
function isSilentMode() {
|
||||
return silentMode;
|
||||
}
|
||||
```
|
||||
|
||||
## Task Utilities
|
||||
|
||||
- **Task Finding and Manipulation**:
|
||||
- ✅ DO: Use tagged task system aware functions
|
||||
- ✅ DO: Handle both task and subtask operations
|
||||
- ✅ DO: Validate task IDs before operations
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement tag-aware task utilities
|
||||
function findTaskById(tasks, taskId) {
|
||||
if (!Array.isArray(tasks)) {
|
||||
return null;
|
||||
}
|
||||
return tasks.find(task => task.id === taskId) || null;
|
||||
}
|
||||
|
||||
function findSubtaskById(tasks, parentId, subtaskId) {
|
||||
const parentTask = findTaskById(tasks, parentId);
|
||||
if (!parentTask || !parentTask.subtasks) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return parentTask.subtasks.find(subtask => subtask.id === subtaskId) || null;
|
||||
}
|
||||
|
||||
function getNextTaskId(tasks) {
|
||||
if (!Array.isArray(tasks) || tasks.length === 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
const maxId = Math.max(...tasks.map(task => task.id));
|
||||
return maxId + 1;
|
||||
}
|
||||
|
||||
function getNextSubtaskId(parentTask) {
|
||||
if (!parentTask.subtasks || parentTask.subtasks.length === 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
const maxId = Math.max(...parentTask.subtasks.map(subtask => subtask.id));
|
||||
return maxId + 1;
|
||||
}
|
||||
```
|
||||
|
||||
## String Utilities
|
||||
|
||||
- **Text Processing**:
|
||||
- ✅ DO: Handle text truncation appropriately
|
||||
- ✅ DO: Provide consistent formatting functions
|
||||
- ✅ DO: Support different output formats
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement useful string utilities
|
||||
function truncate(str, maxLength = 50) {
|
||||
if (!str || typeof str !== 'string') {
|
||||
return '';
|
||||
}
|
||||
|
||||
if (str.length <= maxLength) {
|
||||
return str;
|
||||
}
|
||||
|
||||
return str.substring(0, maxLength - 3) + '...';
|
||||
}
|
||||
|
||||
function formatDuration(ms) {
|
||||
const seconds = Math.floor(ms / 1000);
|
||||
const minutes = Math.floor(seconds / 60);
|
||||
const hours = Math.floor(minutes / 60);
|
||||
|
||||
if (hours > 0) {
|
||||
return `${hours}h ${minutes % 60}m ${seconds % 60}s`;
|
||||
} else if (minutes > 0) {
|
||||
return `${minutes}m ${seconds % 60}s`;
|
||||
} else {
|
||||
return `${seconds}s`;
|
||||
}
|
||||
}
|
||||
|
||||
function capitalizeFirst(str) {
|
||||
if (!str || typeof str !== 'string') {
|
||||
return '';
|
||||
}
|
||||
|
||||
return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
|
||||
}
|
||||
```
|
||||
|
||||
## Dependency Management Utilities
|
||||
|
||||
- **Dependency Analysis**:
|
||||
- ✅ DO: Detect circular dependencies
|
||||
- ✅ DO: Validate dependency references
|
||||
- ✅ DO: Support cross-tag dependency checking (future enhancement)
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement dependency utilities
|
||||
function findCycles(tasks) {
|
||||
const cycles = [];
|
||||
const visited = new Set();
|
||||
const recStack = new Set();
|
||||
|
||||
function dfs(taskId, path = []) {
|
||||
if (recStack.has(taskId)) {
|
||||
// Found a cycle
|
||||
const cycleStart = path.indexOf(taskId);
|
||||
const cycle = path.slice(cycleStart).concat([taskId]);
|
||||
cycles.push(cycle);
|
||||
return;
|
||||
}
|
||||
|
||||
if (visited.has(taskId)) {
|
||||
return;
|
||||
}
|
||||
|
||||
visited.add(taskId);
|
||||
recStack.add(taskId);
|
||||
|
||||
const task = findTaskById(tasks, taskId);
|
||||
if (task && task.dependencies) {
|
||||
task.dependencies.forEach(depId => {
|
||||
dfs(depId, path.concat([taskId]));
|
||||
});
|
||||
}
|
||||
|
||||
recStack.delete(taskId);
|
||||
}
|
||||
|
||||
tasks.forEach(task => {
|
||||
if (!visited.has(task.id)) {
|
||||
dfs(task.id);
|
||||
}
|
||||
});
|
||||
|
||||
return cycles;
|
||||
}
|
||||
|
||||
function validateDependencies(tasks) {
|
||||
const validationErrors = [];
|
||||
const taskIds = new Set(tasks.map(task => task.id));
|
||||
|
||||
tasks.forEach(task => {
|
||||
if (task.dependencies) {
|
||||
task.dependencies.forEach(depId => {
|
||||
if (!taskIds.has(depId)) {
|
||||
validationErrors.push({
|
||||
taskId: task.id,
|
||||
invalidDependency: depId,
|
||||
message: `Task ${task.id} depends on non-existent task ${depId}`
|
||||
});
|
||||
}
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
return validationErrors;
|
||||
}
|
||||
```
|
||||
|
||||
## Environment and Configuration Utilities
|
||||
|
||||
- **Environment Variable Resolution**:
|
||||
- ✅ DO: Support both `.env` files and MCP session environment
|
||||
- ✅ DO: Provide fallbacks for missing values
|
||||
- ✅ DO: Handle API key resolution correctly
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement flexible environment resolution
|
||||
function resolveEnvVariable(key, sessionEnv = null) {
|
||||
// First check session environment (for MCP)
|
||||
if (sessionEnv && sessionEnv[key]) {
|
||||
return sessionEnv[key];
|
||||
}
|
||||
|
||||
// Then check process environment
|
||||
if (process.env[key]) {
|
||||
return process.env[key];
|
||||
}
|
||||
|
||||
// Finally try .env file if in project root
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (projectRoot) {
|
||||
const envPath = path.join(projectRoot, '.env');
|
||||
if (fs.existsSync(envPath)) {
|
||||
const envContent = fs.readFileSync(envPath, 'utf8');
|
||||
const lines = envContent.split('\n');
|
||||
|
||||
for (const line of lines) {
|
||||
const [envKey, envValue] = line.split('=');
|
||||
if (envKey && envKey.trim() === key) {
|
||||
return envValue ? envValue.trim().replace(/^["']|["']$/g, '') : undefined;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
log('debug', `Error reading .env file: ${error.message}`);
|
||||
}
|
||||
|
||||
return undefined;
|
||||
}
|
||||
|
||||
function getDebugFlag() {
|
||||
const debugFlag = resolveEnvVariable('TASKMASTER_DEBUG') ||
|
||||
resolveEnvVariable('DEBUG') ||
|
||||
'false';
|
||||
return debugFlag.toLowerCase() === 'true';
|
||||
}
|
||||
```
|
||||
|
||||
## Export Pattern
|
||||
|
||||
- **Module Exports**:
|
||||
- ✅ DO: Export all utility functions explicitly
|
||||
- ✅ DO: Group related functions logically
|
||||
- ✅ DO: Include new tagged system utilities
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Export utilities in logical groups
|
||||
module.exports = {
|
||||
// File system utilities
|
||||
readJSON,
|
||||
writeJSON,
|
||||
findProjectRoot,
|
||||
|
||||
// Tagged task system utilities
|
||||
getTasksForTag,
|
||||
setTasksForTag,
|
||||
getCurrentTag,
|
||||
performCompleteTagMigration,
|
||||
migrateConfigJson,
|
||||
createStateJson,
|
||||
markMigrationForNotice,
|
||||
|
||||
// Logging utilities
|
||||
log,
|
||||
enableSilentMode,
|
||||
disableSilentMode,
|
||||
isSilentMode,
|
||||
|
||||
// Task utilities
|
||||
findTaskById,
|
||||
findSubtaskById,
|
||||
getNextTaskId,
|
||||
getNextSubtaskId,
|
||||
|
||||
// String utilities
|
||||
truncate,
|
||||
formatDuration,
|
||||
capitalizeFirst,
|
||||
|
||||
// Dependency utilities
|
||||
findCycles,
|
||||
validateDependencies,
|
||||
|
||||
// Environment utilities
|
||||
resolveEnvVariable,
|
||||
getDebugFlag,
|
||||
|
||||
// Legacy utilities (maintained for compatibility)
|
||||
aggregateTelemetry
|
||||
};
|
||||
```
|
||||
|
||||
Refer to [`utils.js`](mdc:scripts/modules/utils.js) for implementation examples and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for integration patterns.
|
||||
|
||||
Reference in New Issue
Block a user