fix(move): adjusts logic to prevent an issue when moving from parent to subtask if the target parent has no subtasks.

This commit is contained in:
Eyal Toledano
2025-05-25 17:49:32 -04:00
parent de58e9ede5
commit f74d639110
19 changed files with 1648 additions and 4388 deletions

View File

@@ -90,20 +90,26 @@ async function moveTask(
);
}
if (!destParentTask.subtasks || destParentTask.subtasks.length === 0) {
throw new Error(
`Destination parent task ${parentIdNum} has no subtasks`
// Initialize subtasks array if it doesn't exist
if (!destParentTask.subtasks) {
destParentTask.subtasks = [];
}
// If there are existing subtasks, try to find the specific destination subtask
if (destParentTask.subtasks.length > 0) {
destSubtaskIndex = destParentTask.subtasks.findIndex(
(st) => st.id === subtaskIdNum
);
if (destSubtaskIndex !== -1) {
destSubtask = destParentTask.subtasks[destSubtaskIndex];
} else {
// Subtask doesn't exist, we'll insert at the end
destSubtaskIndex = destParentTask.subtasks.length - 1;
}
} else {
// No existing subtasks, this will be the first one
destSubtaskIndex = -1; // Will insert at position 0
}
destSubtaskIndex = destParentTask.subtasks.findIndex(
(st) => st.id === subtaskIdNum
);
if (destSubtaskIndex === -1) {
throw new Error(`Destination subtask ${destinationId} not found`);
}
destSubtask = destParentTask.subtasks[destSubtaskIndex];
} else {
// Destination is a task
const destIdNum = parseInt(destinationId, 10);
@@ -337,7 +343,10 @@ function moveTaskToSubtaskPosition(
};
// Insert at specific position
destParentTask.subtasks.splice(destSubtaskIndex + 1, 0, newSubtask);
// If destSubtaskIndex is -1, insert at the beginning (position 0)
// Otherwise, insert after the specified subtask
const insertPosition = destSubtaskIndex === -1 ? 0 : destSubtaskIndex + 1;
destParentTask.subtasks.splice(insertPosition, 0, newSubtask);
// Remove the original task from the tasks array
data.tasks.splice(sourceTaskIndex, 1);
@@ -474,7 +483,10 @@ function moveSubtaskToAnotherParent(
}
// Insert at the destination position
destParentTask.subtasks.splice(destSubtaskIndex + 1, 0, newSubtask);
// If destSubtaskIndex is -1, insert at the beginning (position 0)
// Otherwise, insert after the specified subtask
const insertPosition = destSubtaskIndex === -1 ? 0 : destSubtaskIndex + 1;
destParentTask.subtasks.splice(insertPosition, 0, newSubtask);
// Remove the subtask from the original parent
sourceParentTask.subtasks.splice(sourceSubtaskIndex, 1);
@@ -549,19 +561,20 @@ function moveTaskToNewId(
}
});
// Remove the original task from its position
// We need to be careful about the order of operations to avoid index issues
// The strategy: remove the source first, then replace the destination
// This avoids index shifting problems
// Remove the source task first
data.tasks.splice(sourceTaskIndex, 1);
// If we're moving to a position after the original, adjust the destination index
// since removing the original shifts everything down by 1
// Adjust the destination index if the source was before the destination
// Since we removed the source, indices after it shift down by 1
const adjustedDestIndex =
sourceTaskIndex < destTaskIndex ? destTaskIndex - 1 : destTaskIndex;
// Remove the placeholder destination task
data.tasks.splice(adjustedDestIndex, 1);
// Insert the moved task at the destination position
data.tasks.splice(adjustedDestIndex, 0, movedTask);
// Replace the placeholder destination task with the moved task
data.tasks[adjustedDestIndex] = movedTask;
log('info', `Moved task ${sourceIdNum} to new ID ${destIdNum}`);

View File

@@ -1,7 +1,7 @@
# Task ID: 45
# Title: Implement GitHub Issue Import Feature
# Status: pending
# Dependencies: 97
# Dependencies: None
# Priority: medium
# Description: Add a '--from-github' flag to the add-task command that accepts a GitHub issue URL and automatically generates a corresponding task with relevant details. This feature works in conjunction with the GitHub export feature (Task #97) to provide bidirectional linking between Task Master tasks and GitHub issues.
# Details:

525
tasks/task_081.txt Normal file
View File

@@ -0,0 +1,525 @@
# Task ID: 81
# Title: Implement Separate Context Window and Output Token Limits
# Status: pending
# Dependencies: None
# Priority: high
# Description: Replace the ambiguous MAX_TOKENS configuration with separate contextWindowTokens and maxOutputTokens fields to properly handle model token limits and enable dynamic token allocation.
# Details:
Currently, the MAX_TOKENS configuration entry is ambiguous and doesn't properly differentiate between:
1. Context window tokens (total input + output capacity)
2. Maximum output tokens (generation limit)
This causes issues where:
- The system can't properly validate prompt lengths against model capabilities
- Output token allocation is not optimized based on input length
- Different models with different token architectures are handled inconsistently
This epic will implement a comprehensive solution that:
- Updates supported-models.json with accurate contextWindowTokens and maxOutputTokens for each model
- Modifies config-manager.js to use separate maxInputTokens and maxOutputTokens in role configurations
- Implements a token counting utility for accurate prompt measurement
- Updates ai-services-unified.js to dynamically calculate available output tokens
- Provides migration guidance and validation for existing configurations
- Adds comprehensive error handling and validation throughout the system
The end result will be more precise token management, better cost control, and reduced likelihood of hitting model context limits.
# Test Strategy:
1. Verify all models have accurate token limit data from official documentation
2. Test dynamic token allocation with various prompt lengths
3. Ensure backward compatibility with existing .taskmasterconfig files
4. Validate error messages are clear and actionable
5. Test with multiple AI providers to ensure consistent behavior
6. Performance test token counting utility with large prompts
# Subtasks:
## 1. Update supported-models.json with token limit fields [pending]
### Dependencies: None
### Description: Modify the supported-models.json file to include contextWindowTokens and maxOutputTokens fields for each model, replacing the ambiguous max_tokens field.
### Details:
For each model entry in supported-models.json:
1. Add `contextWindowTokens` field representing the total context window (input + output tokens)
2. Add `maxOutputTokens` field representing the maximum tokens the model can generate
3. Remove or deprecate the ambiguous `max_tokens` field if present
Research and populate accurate values for each model from official documentation:
- For OpenAI models (e.g., gpt-4o): contextWindowTokens=128000, maxOutputTokens=16384
- For Anthropic models (e.g., Claude 3.7): contextWindowTokens=200000, maxOutputTokens=8192
- For other providers, find official documentation or use reasonable defaults
Example entry:
```json
{
"id": "claude-3-7-sonnet-20250219",
"swe_score": 0.623,
"cost_per_1m_tokens": { "input": 3.0, "output": 15.0 },
"allowed_roles": ["main", "fallback"],
"contextWindowTokens": 200000,
"maxOutputTokens": 8192
}
```
## 2. Update config-manager.js defaults and getters [pending]
### Dependencies: None
### Description: Modify the config-manager.js module to replace maxTokens with maxInputTokens and maxOutputTokens in the DEFAULTS object and update related getter functions.
### Details:
1. Update the `DEFAULTS` object in config-manager.js:
```javascript
const DEFAULTS = {
// ... existing defaults
main: {
// Replace maxTokens with these two fields
maxInputTokens: 16000, // Example default
maxOutputTokens: 4000, // Example default
temperature: 0.7
// ... other fields
},
research: {
maxInputTokens: 16000,
maxOutputTokens: 4000,
temperature: 0.7
// ... other fields
},
fallback: {
maxInputTokens: 8000,
maxOutputTokens: 2000,
temperature: 0.7
// ... other fields
}
// ... rest of DEFAULTS
};
```
2. Update `getParametersForRole` function to return the new fields:
```javascript
function getParametersForRole(role, explicitRoot = null) {
const config = _getConfig(explicitRoot);
return {
maxInputTokens: config[role]?.maxInputTokens,
maxOutputTokens: config[role]?.maxOutputTokens,
temperature: config[role]?.temperature
// ... any other parameters
};
}
```
3. Add a new function to get model capabilities:
```javascript
function getModelCapabilities(providerName, modelId) {
const models = MODEL_MAP[providerName?.toLowerCase()];
const model = models?.find(m => m.id === modelId);
return {
contextWindowTokens: model?.contextWindowTokens,
maxOutputTokens: model?.maxOutputTokens
};
}
```
4. Deprecate or update the role-specific maxTokens getters:
```javascript
// Either remove these or update them to return maxInputTokens
function getMainMaxTokens(explicitRoot = null) {
console.warn('getMainMaxTokens is deprecated. Use getParametersForRole("main") instead.');
return getParametersForRole("main", explicitRoot).maxInputTokens;
}
// Same for getResearchMaxTokens and getFallbackMaxTokens
```
5. Export the new functions:
```javascript
module.exports = {
// ... existing exports
getParametersForRole,
getModelCapabilities
};
```
## 3. Implement token counting utility [pending]
### Dependencies: None
### Description: Create a utility function to count tokens for prompts based on the model being used, primarily using tiktoken for OpenAI and Anthropic models with character-based fallbacks for other providers.
### Details:
1. Install the tiktoken package:
```bash
npm install tiktoken
```
2. Create a new file `scripts/modules/token-counter.js`:
```javascript
const tiktoken = require('tiktoken');
/**
* Count tokens for a given text and model
* @param {string} text - The text to count tokens for
* @param {string} provider - The AI provider (e.g., 'openai', 'anthropic')
* @param {string} modelId - The model ID
* @returns {number} - Estimated token count
*/
function countTokens(text, provider, modelId) {
if (!text) return 0;
// Convert to lowercase for case-insensitive matching
const providerLower = provider?.toLowerCase();
try {
// OpenAI models
if (providerLower === 'openai') {
// Most OpenAI chat models use cl100k_base encoding
const encoding = tiktoken.encoding_for_model(modelId) || tiktoken.get_encoding('cl100k_base');
return encoding.encode(text).length;
}
// Anthropic models - can use cl100k_base as an approximation
// or follow Anthropic's guidance
if (providerLower === 'anthropic') {
try {
// Try to use cl100k_base as a reasonable approximation
const encoding = tiktoken.get_encoding('cl100k_base');
return encoding.encode(text).length;
} catch (e) {
// Fallback to Anthropic's character-based estimation
return Math.ceil(text.length / 3.5); // ~3.5 chars per token for English
}
}
// For other providers, use character-based estimation as fallback
// Different providers may have different tokenization schemes
return Math.ceil(text.length / 4); // General fallback estimate
} catch (error) {
console.warn(`Token counting error: ${error.message}. Using character-based estimate.`);
return Math.ceil(text.length / 4); // Fallback if tiktoken fails
}
}
module.exports = { countTokens };
```
3. Add tests for the token counter in `tests/token-counter.test.js`:
```javascript
const { countTokens } = require('../scripts/modules/token-counter');
describe('Token Counter', () => {
test('counts tokens for OpenAI models', () => {
const text = 'Hello, world! This is a test.';
const count = countTokens(text, 'openai', 'gpt-4');
expect(count).toBeGreaterThan(0);
expect(typeof count).toBe('number');
});
test('counts tokens for Anthropic models', () => {
const text = 'Hello, world! This is a test.';
const count = countTokens(text, 'anthropic', 'claude-3-7-sonnet-20250219');
expect(count).toBeGreaterThan(0);
expect(typeof count).toBe('number');
});
test('handles empty text', () => {
expect(countTokens('', 'openai', 'gpt-4')).toBe(0);
expect(countTokens(null, 'openai', 'gpt-4')).toBe(0);
});
});
```
## 4. Update ai-services-unified.js for dynamic token limits [pending]
### Dependencies: None
### Description: Modify the _unifiedServiceRunner function in ai-services-unified.js to use the new token counting utility and dynamically adjust output token limits based on input length.
### Details:
1. Import the token counter in `ai-services-unified.js`:
```javascript
const { countTokens } = require('./token-counter');
const { getParametersForRole, getModelCapabilities } = require('./config-manager');
```
2. Update the `_unifiedServiceRunner` function to implement dynamic token limit adjustment:
```javascript
async function _unifiedServiceRunner({
serviceType,
provider,
modelId,
systemPrompt,
prompt,
temperature,
currentRole,
effectiveProjectRoot,
// ... other parameters
}) {
// Get role parameters with new token limits
const roleParams = getParametersForRole(currentRole, effectiveProjectRoot);
// Get model capabilities
const modelCapabilities = getModelCapabilities(provider, modelId);
// Count tokens in the prompts
const systemPromptTokens = countTokens(systemPrompt, provider, modelId);
const userPromptTokens = countTokens(prompt, provider, modelId);
const totalPromptTokens = systemPromptTokens + userPromptTokens;
// Validate against input token limits
if (totalPromptTokens > roleParams.maxInputTokens) {
throw new Error(
`Prompt (${totalPromptTokens} tokens) exceeds configured max input tokens (${roleParams.maxInputTokens}) for role '${currentRole}'.`
);
}
// Validate against model's absolute context window
if (modelCapabilities.contextWindowTokens && totalPromptTokens > modelCapabilities.contextWindowTokens) {
throw new Error(
`Prompt (${totalPromptTokens} tokens) exceeds model's context window (${modelCapabilities.contextWindowTokens}) for ${modelId}.`
);
}
// Calculate available output tokens
// If model has a combined context window, we need to subtract input tokens
let availableOutputTokens = roleParams.maxOutputTokens;
// If model has a context window constraint, ensure we don't exceed it
if (modelCapabilities.contextWindowTokens) {
const remainingContextTokens = modelCapabilities.contextWindowTokens - totalPromptTokens;
availableOutputTokens = Math.min(availableOutputTokens, remainingContextTokens);
}
// Also respect the model's absolute max output limit
if (modelCapabilities.maxOutputTokens) {
availableOutputTokens = Math.min(availableOutputTokens, modelCapabilities.maxOutputTokens);
}
// Prepare API call parameters
const callParams = {
apiKey,
modelId,
maxTokens: availableOutputTokens, // Use dynamically calculated output limit
temperature: roleParams.temperature,
messages,
baseUrl,
...(serviceType === 'generateObject' && { schema, objectName }),
...restApiParams
};
// Log token usage information
console.debug(`Token usage: ${totalPromptTokens} input tokens, ${availableOutputTokens} max output tokens`);
// Rest of the function remains the same...
}
```
3. Update the error handling to provide clear messages about token limits:
```javascript
try {
// Existing code...
} catch (error) {
if (error.message.includes('tokens')) {
// Token-related errors should be clearly identified
console.error(`Token limit error: ${error.message}`);
}
throw error;
}
```
## 5. Update .taskmasterconfig schema and user guide [pending]
### Dependencies: None
### Description: Create a migration guide for users to update their .taskmasterconfig files and document the new token limit configuration options.
### Details:
1. Create a migration script or guide for users to update their existing `.taskmasterconfig` files:
```javascript
// Example migration snippet for .taskmasterconfig
{
"main": {
// Before:
// "maxTokens": 16000,
// After:
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
},
"research": {
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
},
"fallback": {
"maxInputTokens": 8000,
"maxOutputTokens": 2000,
"temperature": 0.7
}
}
```
2. Update the user documentation to explain the new token limit fields:
```markdown
# Token Limit Configuration
Task Master now provides more granular control over token limits with separate settings for input and output tokens:
- `maxInputTokens`: Maximum number of tokens allowed in the input prompt (system prompt + user prompt)
- `maxOutputTokens`: Maximum number of tokens the model should generate in its response
## Benefits
- More precise control over token usage
- Better cost management
- Reduced likelihood of hitting model context limits
- Dynamic adjustment to maximize output space based on input length
## Migration from Previous Versions
If you're upgrading from a previous version, you'll need to update your `.taskmasterconfig` file:
1. Replace the single `maxTokens` field with separate `maxInputTokens` and `maxOutputTokens` fields
2. Recommended starting values:
- Set `maxInputTokens` to your previous `maxTokens` value
- Set `maxOutputTokens` to approximately 1/4 of your model's context window
## Example Configuration
```json
{
"main": {
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
}
}
```
```
3. Update the schema validation in `config-manager.js` to validate the new fields:
```javascript
function _validateConfig(config) {
// ... existing validation
// Validate token limits for each role
['main', 'research', 'fallback'].forEach(role => {
if (config[role]) {
// Check if old maxTokens is present and warn about migration
if (config[role].maxTokens !== undefined) {
console.warn(`Warning: 'maxTokens' in ${role} role is deprecated. Please use 'maxInputTokens' and 'maxOutputTokens' instead.`);
}
// Validate new token limit fields
if (config[role].maxInputTokens !== undefined && (!Number.isInteger(config[role].maxInputTokens) || config[role].maxInputTokens <= 0)) {
throw new Error(`Invalid maxInputTokens for ${role} role: must be a positive integer`);
}
if (config[role].maxOutputTokens !== undefined && (!Number.isInteger(config[role].maxOutputTokens) || config[role].maxOutputTokens <= 0)) {
throw new Error(`Invalid maxOutputTokens for ${role} role: must be a positive integer`);
}
}
});
return config;
}
```
## 6. Implement validation and error handling [pending]
### Dependencies: None
### Description: Add comprehensive validation and error handling for token limits throughout the system, including helpful error messages and graceful fallbacks.
### Details:
1. Add validation when loading models in `config-manager.js`:
```javascript
function _validateModelMap(modelMap) {
// Validate each provider's models
Object.entries(modelMap).forEach(([provider, models]) => {
models.forEach(model => {
// Check for required token limit fields
if (!model.contextWindowTokens) {
console.warn(`Warning: Model ${model.id} from ${provider} is missing contextWindowTokens field`);
}
if (!model.maxOutputTokens) {
console.warn(`Warning: Model ${model.id} from ${provider} is missing maxOutputTokens field`);
}
});
});
return modelMap;
}
```
2. Add validation when setting up a model in the CLI:
```javascript
function validateModelConfig(modelConfig, modelCapabilities) {
const issues = [];
// Check if input tokens exceed model's context window
if (modelConfig.maxInputTokens > modelCapabilities.contextWindowTokens) {
issues.push(`maxInputTokens (${modelConfig.maxInputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
}
// Check if output tokens exceed model's maximum
if (modelConfig.maxOutputTokens > modelCapabilities.maxOutputTokens) {
issues.push(`maxOutputTokens (${modelConfig.maxOutputTokens}) exceeds model's maximum output tokens (${modelCapabilities.maxOutputTokens})`);
}
// Check if combined tokens exceed context window
if (modelConfig.maxInputTokens + modelConfig.maxOutputTokens > modelCapabilities.contextWindowTokens) {
issues.push(`Combined maxInputTokens and maxOutputTokens (${modelConfig.maxInputTokens + modelConfig.maxOutputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
}
return issues;
}
```
3. Add graceful fallbacks in `ai-services-unified.js`:
```javascript
// Fallback for missing token limits
if (!roleParams.maxInputTokens) {
console.warn(`Warning: maxInputTokens not specified for role '${currentRole}'. Using default value.`);
roleParams.maxInputTokens = 8000; // Reasonable default
}
if (!roleParams.maxOutputTokens) {
console.warn(`Warning: maxOutputTokens not specified for role '${currentRole}'. Using default value.`);
roleParams.maxOutputTokens = 2000; // Reasonable default
}
// Fallback for missing model capabilities
if (!modelCapabilities.contextWindowTokens) {
console.warn(`Warning: contextWindowTokens not specified for model ${modelId}. Using conservative estimate.`);
modelCapabilities.contextWindowTokens = roleParams.maxInputTokens + roleParams.maxOutputTokens;
}
if (!modelCapabilities.maxOutputTokens) {
console.warn(`Warning: maxOutputTokens not specified for model ${modelId}. Using role configuration.`);
modelCapabilities.maxOutputTokens = roleParams.maxOutputTokens;
}
```
4. Add detailed logging for token usage:
```javascript
function logTokenUsage(provider, modelId, inputTokens, outputTokens, role) {
const inputCost = calculateTokenCost(provider, modelId, 'input', inputTokens);
const outputCost = calculateTokenCost(provider, modelId, 'output', outputTokens);
console.info(`Token usage for ${role} role with ${provider}/${modelId}:`);
console.info(`- Input: ${inputTokens.toLocaleString()} tokens ($${inputCost.toFixed(6)})`);
console.info(`- Output: ${outputTokens.toLocaleString()} tokens ($${outputCost.toFixed(6)})`);
console.info(`- Total cost: $${(inputCost + outputCost).toFixed(6)}`);
console.info(`- Available output tokens: ${availableOutputTokens.toLocaleString()}`);
}
```
5. Add a helper function to suggest configuration improvements:
```javascript
function suggestTokenConfigImprovements(roleParams, modelCapabilities, promptTokens) {
const suggestions = [];
// If prompt is using less than 50% of allowed input
if (promptTokens < roleParams.maxInputTokens * 0.5) {
suggestions.push(`Consider reducing maxInputTokens from ${roleParams.maxInputTokens} to save on potential costs`);
}
// If output tokens are very limited due to large input
const availableOutput = Math.min(
roleParams.maxOutputTokens,
modelCapabilities.contextWindowTokens - promptTokens
);
if (availableOutput < roleParams.maxOutputTokens * 0.5) {
suggestions.push(`Available output tokens (${availableOutput}) are significantly less than configured maxOutputTokens (${roleParams.maxOutputTokens}) due to large input`);
}
return suggestions;
}
```

View File

@@ -1,34 +1,23 @@
# Task ID: 82
# Title: Update supported-models.json with token limit fields
# Title: Introduce Prioritize Command with Enhanced Priority Levels
# Status: pending
# Dependencies: None
# Priority: high
# Description: Modify the supported-models.json file to include contextWindowTokens and maxOutputTokens fields for each model, replacing the ambiguous max_tokens field.
# Priority: medium
# Description: Implement a prioritize command with --up/--down/--priority/--id flags and shorthand equivalents (-u/-d/-p/-i). Add 'lowest' and 'highest' priority levels, updating CLI output accordingly.
# Details:
For each model entry in supported-models.json:
1. Add `contextWindowTokens` field representing the total context window (input + output tokens)
2. Add `maxOutputTokens` field representing the maximum tokens the model can generate
3. Remove or deprecate the ambiguous `max_tokens` field if present
The new prioritize command should allow users to adjust task priorities using the specified flags. The --up and --down flags will modify the priority relative to the current level, while --priority sets an absolute priority. The --id flag specifies which task to prioritize. Shorthand equivalents (-u/-d/-p/-i) should be supported for user convenience.
Research and populate accurate values for each model from official documentation:
- For OpenAI models (e.g., gpt-4o): contextWindowTokens=128000, maxOutputTokens=16384
- For Anthropic models (e.g., Claude 3.7): contextWindowTokens=200000, maxOutputTokens=8192
- For other providers, find official documentation or use reasonable defaults
The priority levels should now include 'lowest', 'low', 'medium', 'high', and 'highest'. The CLI output should be updated to reflect these new priority levels accurately.
Example entry:
```json
{
"id": "claude-3-7-sonnet-20250219",
"swe_score": 0.623,
"cost_per_1m_tokens": { "input": 3.0, "output": 15.0 },
"allowed_roles": ["main", "fallback"],
"contextWindowTokens": 200000,
"maxOutputTokens": 8192
}
```
Considerations:
- Ensure backward compatibility with existing commands and configurations.
- Update the help documentation to include the new command and its usage.
- Implement proper error handling for invalid priority levels or missing flags.
# Test Strategy:
1. Validate JSON syntax after changes
2. Verify all models have the new fields with reasonable values
3. Check that the values align with official documentation from each provider
4. Ensure backward compatibility by maintaining any fields other systems might depend on
To verify task completion, perform the following tests:
1. Test each flag (--up, --down, --priority, --id) individually and in combination to ensure they function as expected.
2. Verify that shorthand equivalents (-u, -d, -p, -i) work correctly.
3. Check that the new priority levels ('lowest' and 'highest') are recognized and displayed properly in CLI output.
4. Test error handling for invalid inputs (e.g., non-existent task IDs, invalid priority levels).
5. Ensure that the help command displays accurate information about the new prioritize command.

View File

@@ -1,95 +1,288 @@
# Task ID: 83
# Title: Update config-manager.js defaults and getters
# Title: Implement Git Workflow Integration
# Status: pending
# Dependencies: 82
# Dependencies: None
# Priority: high
# Description: Modify the config-manager.js module to replace maxTokens with maxInputTokens and maxOutputTokens in the DEFAULTS object and update related getter functions.
# Description: Add `task-master git` command suite to automate git workflows based on established patterns from Task 4, eliminating manual overhead and ensuring 100% consistency
# Details:
1. Update the `DEFAULTS` object in config-manager.js:
```javascript
const DEFAULTS = {
// ... existing defaults
main: {
// Replace maxTokens with these two fields
maxInputTokens: 16000, // Example default
maxOutputTokens: 4000, // Example default
temperature: 0.7
// ... other fields
},
research: {
maxInputTokens: 16000,
maxOutputTokens: 4000,
temperature: 0.7
// ... other fields
},
fallback: {
maxInputTokens: 8000,
maxOutputTokens: 2000,
temperature: 0.7
// ... other fields
}
// ... rest of DEFAULTS
};
```
Create a comprehensive git workflow automation system that integrates deeply with TaskMaster's task management. The feature will:
2. Update `getParametersForRole` function to return the new fields:
```javascript
function getParametersForRole(role, explicitRoot = null) {
const config = _getConfig(explicitRoot);
return {
maxInputTokens: config[role]?.maxInputTokens,
maxOutputTokens: config[role]?.maxOutputTokens,
temperature: config[role]?.temperature
// ... any other parameters
};
}
```
1. **Automated Branch Management**:
- Create branches following `task-{id}` naming convention
- Validate branch names and prevent conflicts
- Handle branch switching with uncommitted changes
- Clean up local and remote branches post-merge
3. Add a new function to get model capabilities:
```javascript
function getModelCapabilities(providerName, modelId) {
const models = MODEL_MAP[providerName?.toLowerCase()];
const model = models?.find(m => m.id === modelId);
return {
contextWindowTokens: model?.contextWindowTokens,
maxOutputTokens: model?.maxOutputTokens
};
}
```
2. **Intelligent Commit Generation**:
- Auto-detect commit type (feat/fix/test/refactor/docs) from file changes
- Generate standardized commit messages with task context
- Support subtask-specific commits with proper references
- Include coverage delta in test commits
4. Deprecate or update the role-specific maxTokens getters:
```javascript
// Either remove these or update them to return maxInputTokens
function getMainMaxTokens(explicitRoot = null) {
console.warn('getMainMaxTokens is deprecated. Use getParametersForRole("main") instead.');
return getParametersForRole("main", explicitRoot).maxInputTokens;
}
// Same for getResearchMaxTokens and getFallbackMaxTokens
```
3. **PR Automation**:
- Generate comprehensive PR descriptions from task/subtask data
- Include implementation details, test coverage, breaking changes
- Format using GitHub markdown with task hierarchy
- Auto-populate PR template with relevant metadata
5. Export the new functions:
```javascript
module.exports = {
// ... existing exports
getParametersForRole,
getModelCapabilities
};
```
4. **Workflow State Management**:
- Track current task branch and status
- Validate task readiness before PR creation
- Ensure all subtasks completed before finishing
- Handle merge conflicts gracefully
5. **Integration Points**:
- Seamless integration with existing task commands
- MCP server support for IDE integrations
- GitHub CLI (`gh`) authentication support
- Coverage report parsing and display
**Technical Architecture**:
- Modular command structure in `scripts/modules/task-manager/git-*`
- Git operations wrapper using simple-git or native child_process
- Template engine for commit/PR generation in `scripts/modules/`
- State persistence in `.taskmaster/git-state.json`
- Error recovery and rollback mechanisms
**Key Files to Create**:
- `scripts/modules/task-manager/git-start.js` - Branch creation and task status update
- `scripts/modules/task-manager/git-commit.js` - Intelligent commit message generation
- `scripts/modules/task-manager/git-pr.js` - PR creation with auto-generated description
- `scripts/modules/task-manager/git-finish.js` - Post-merge cleanup and status update
- `scripts/modules/task-manager/git-status.js` - Current git workflow state display
- `scripts/modules/git-operations.js` - Core git functionality wrapper
- `scripts/modules/commit-analyzer.js` - File change analysis for commit types
- `scripts/modules/pr-description-generator.js` - PR description template generator
**MCP Integration Files**:
- `mcp-server/src/core/direct-functions/git-start.js`
- `mcp-server/src/core/direct-functions/git-commit.js`
- `mcp-server/src/core/direct-functions/git-pr.js`
- `mcp-server/src/core/direct-functions/git-finish.js`
- `mcp-server/src/core/direct-functions/git-status.js`
- `mcp-server/src/tools/git-start.js`
- `mcp-server/src/tools/git-commit.js`
- `mcp-server/src/tools/git-pr.js`
- `mcp-server/src/tools/git-finish.js`
- `mcp-server/src/tools/git-status.js`
**Configuration**:
- Add git workflow settings to `.taskmasterconfig`
- Support for custom commit prefixes and PR templates
- Branch naming pattern customization
- Remote repository detection and validation
# Test Strategy:
1. Unit test the updated getParametersForRole function with various configurations
2. Verify the new getModelCapabilities function returns correct values
3. Test with both default and custom configurations
4. Ensure backward compatibility by checking that existing code using the old getters still works (with warnings)
Implement comprehensive test suite following Task 4's TDD approach:
1. **Unit Tests** (target: 95%+ coverage):
- Git operations wrapper with mocked git commands
- Commit type detection with various file change scenarios
- PR description generation with different task structures
- Branch name validation and generation
- State management and persistence
2. **Integration Tests**:
- Full workflow simulation in test repository
- Error handling for git conflicts and failures
- Multi-task workflow scenarios
- Coverage integration with real test runs
- GitHub API interaction (mocked)
3. **E2E Tests**:
- Complete task lifecycle from start to finish
- Multiple developer workflow simulation
- Merge conflict resolution scenarios
- Branch protection and validation
4. **Test Implementation Details**:
- Use Jest with git repository fixtures
- Mock simple-git for isolated unit tests
- Create test tasks.json scenarios
- Validate all error messages and edge cases
- Test rollback and recovery mechanisms
5. **Coverage Requirements**:
- Minimum 90% overall coverage
- 100% coverage for critical paths (branch creation, PR generation)
- All error scenarios must be tested
- Performance tests for large task hierarchies
# Subtasks:
## 1. Update config-manager.js with specific token limit fields [pending]
## 1. Design and implement core git operations wrapper [pending]
### Dependencies: None
### Description: Modify the DEFAULTS object in config-manager.js to replace maxTokens with more specific token limit fields (maxInputTokens, maxOutputTokens, maxTotalTokens) and update related getter functions while maintaining backward compatibility.
### Description: Create a robust git operations layer that handles all git commands with proper error handling and state management
### Details:
1. Replace maxTokens in the DEFAULTS object with maxInputTokens, maxOutputTokens, and maxTotalTokens
2. Update any getter functions that reference maxTokens to handle both old and new configurations
3. Ensure backward compatibility so existing code using maxTokens continues to work
4. Update any related documentation or comments to reflect the new token limit fields
5. Test the changes to verify both new specific token limits and legacy maxTokens usage work correctly
Create `scripts/modules/git-operations.js` with methods for:
- Branch creation/deletion (local and remote)
- Commit operations with message formatting
- Status checking and conflict detection
- Remote operations (fetch, push, pull)
- Repository validation and setup
Use simple-git library or child_process for git commands. Implement comprehensive error handling with specific error types for different git failures. Include retry logic for network operations.
## 2. Implement git start command [pending]
### Dependencies: None
### Description: Create the entry point for task-based git workflows with automated branch creation and task status updates
### Details:
Implement `scripts/modules/task-manager/git-start.js` with functionality to:
- Validate task exists and is ready to start
- Check for clean working directory
- Create branch with `task-{id}` naming
- Update task status to 'in-progress'
- Store workflow state in `.taskmaster/git-state.json`
- Handle existing branch scenarios
- Support --force flag for branch recreation
Integrate with existing task-master commands and ensure MCP compatibility.
## 3. Build intelligent commit analyzer and generator [pending]
### Dependencies: None
### Description: Create a system that analyzes file changes to auto-detect commit types and generate standardized commit messages
### Details:
Develop `scripts/modules/commit-analyzer.js` with:
- File change detection and categorization
- Commit type inference rules:
- feat: new files in scripts/, new functions
- fix: changes to existing logic
- test: changes in tests/ directory
- docs: markdown and comment changes
- refactor: file moves, renames, cleanup
- Smart message generation with task context
- Support for custom commit templates
- Subtask reference inclusion
Create `scripts/modules/task-manager/git-commit.js` that uses the analyzer to generate commits with proper formatting.
## 4. Create PR description generator and command [pending]
### Dependencies: None
### Description: Build a comprehensive PR description generator that creates detailed, formatted descriptions from task data
### Details:
Implement `scripts/modules/pr-description-generator.js` to generate:
- Task overview with full context
- Subtask completion checklist
- Implementation details summary
- Test coverage metrics integration
- Breaking changes section
- Related tasks and dependencies
Create `scripts/modules/task-manager/git-pr.js` to:
- Validate all subtasks are complete
- Generate PR title and description
- Use GitHub CLI for PR creation
- Handle draft PR scenarios
- Support custom PR templates
- Include labels based on task metadata
## 5. Implement git finish command with cleanup [pending]
### Dependencies: None
### Description: Create the workflow completion command that handles post-merge cleanup and task status updates
### Details:
Build `scripts/modules/task-manager/git-finish.js` with:
- PR merge verification via GitHub API
- Local branch cleanup
- Remote branch deletion (with confirmation)
- Task status update to 'done'
- Workflow state cleanup
- Switch back to main branch
- Pull latest changes
Handle scenarios where PR isn't merged yet or merge failed. Include --skip-cleanup flag for manual branch management.
## 6. Add git status command for workflow visibility [pending]
### Dependencies: None
### Description: Create a status command that shows current git workflow state with task context
### Details:
Implement `scripts/modules/task-manager/git-status.js` to display:
- Current task and branch information
- Subtask completion status
- Uncommitted changes summary
- PR status if exists
- Coverage metrics comparison
- Suggested next actions
Integrate with existing task status displays and provide actionable guidance based on workflow state.
## 7. Integrate with Commander.js and add command routing [pending]
### Dependencies: None
### Description: Add the git command suite to TaskMaster's CLI with proper help text and option handling
### Details:
Update `scripts/modules/commands.js` to:
- Add 'git' command with subcommands
- Implement option parsing for all git commands
- Add comprehensive help text
- Ensure proper error handling and display
- Validate command prerequisites
Create proper command structure:
- `task-master git start [taskId] [options]`
- `task-master git commit [options]`
- `task-master git pr [options]`
- `task-master git finish [options]`
- `task-master git status [options]`
## 8. Add MCP server integration for git commands [pending]
### Dependencies: None
### Description: Implement MCP tools and direct functions for git workflow commands to enable IDE integration
### Details:
Create MCP integration in:
- `mcp-server/src/core/direct-functions/git-start.js`
- `mcp-server/src/core/direct-functions/git-commit.js`
- `mcp-server/src/core/direct-functions/git-pr.js`
- `mcp-server/src/core/direct-functions/git-finish.js`
- `mcp-server/src/core/direct-functions/git-status.js`
- `mcp-server/src/tools/git-start.js`
- `mcp-server/src/tools/git-commit.js`
- `mcp-server/src/tools/git-pr.js`
- `mcp-server/src/tools/git-finish.js`
- `mcp-server/src/tools/git-status.js`
Implement tools for:
- git_start_task
- git_commit_task
- git_create_pr
- git_finish_task
- git_workflow_status
Ensure proper error handling, logging, and response formatting. Include telemetry data for git operations.
## 9. Create comprehensive test suite [pending]
### Dependencies: None
### Description: Implement full test coverage following Task 4's high standards with unit, integration, and E2E tests
### Details:
Create test files:
- `tests/unit/git/` - Unit tests for all git components
- `tests/integration/git-workflow.test.js` - Full workflow tests
- `tests/e2e/git-automation.test.js` - End-to-end scenarios
Implement:
- Git repository fixtures and mocks
- Coverage tracking and reporting
- Performance benchmarks
- Error scenario coverage
- Multi-developer workflow simulations
Target 95%+ coverage with focus on critical paths.
## 10. Add configuration and documentation [pending]
### Dependencies: None
### Description: Create configuration options and comprehensive documentation for the git workflow feature
### Details:
Configuration tasks:
- Add git workflow settings to `.taskmasterconfig`
- Support environment variables for GitHub tokens
- Create default PR and commit templates
- Add branch naming customization
Documentation tasks:
- Update README with git workflow section
- Create `docs/git-workflow.md` guide
- Add examples for common scenarios
- Document configuration options
- Create troubleshooting guide
Update rule files:
- Create `.cursor/rules/git_workflow.mdc`
- Update existing workflow rules

View File

@@ -1,93 +1,639 @@
# Task ID: 84
# Title: Implement token counting utility
# Title: Enhance Parse-PRD with Intelligent Task Expansion and Detail Preservation
# Status: pending
# Dependencies: 82
# Dependencies: None
# Priority: high
# Description: Create a utility function to count tokens for prompts based on the model being used, primarily using tiktoken for OpenAI and Anthropic models with character-based fallbacks for other providers.
# Description: Transform parse-prd from a simple task generator into an intelligent system that preserves PRD detail resolution through context-aware task expansion. This addresses the critical issue where highly detailed PRDs lose their specificity when parsed into too few top-level tasks, and ensures that task expansions are grounded in actual PRD content rather than generic AI assumptions.
# Details:
1. Install the tiktoken package:
```bash
npm install tiktoken
```
## Core Problem Statement
2. Create a new file `scripts/modules/token-counter.js`:
The current parse-prd implementation suffers from a fundamental resolution loss problem:
1. **Detail Compression**: Complex, detailed PRDs get compressed into a fixed number of top-level tasks (default 10), losing critical specificity
2. **Orphaned Expansions**: When tasks are later expanded via expand-task, the AI lacks the original PRD context, resulting in generic subtasks that don't reflect the PRD's specific requirements
3. **Binary Approach**: The system either creates too few high-level tasks OR requires manual expansion that loses PRD context
## Solution Architecture
### Phase 1: Enhanced PRD Analysis Engine
- Implement intelligent PRD segmentation that identifies natural task boundaries based on content structure
- Create a PRD context preservation system that maintains detailed mappings between PRD sections and generated tasks
- Develop adaptive task count determination based on PRD complexity metrics (length, technical depth, feature count)
### Phase 2: Context-Aware Task Generation
- Modify generateTasksFromPRD to create tasks with embedded PRD context references
- Implement a PRD section mapping system that links each task to its source PRD content
- Add metadata fields to tasks that preserve original PRD language and specifications
### Phase 3: Intelligent In-Flight Expansion
- Add optional `--expand-tasks` flag to parse-prd that triggers immediate expansion after initial task generation
- Implement context-aware expansion that uses the original PRD content for each task's expansion
- Create a two-pass system: first pass generates tasks with PRD context, second pass expands using that context
### Phase 4: PRD-Grounded Expansion Logic
- Enhance the expansion prompt generation to include relevant PRD excerpts for each task being expanded
- Implement smart context windowing that includes related PRD sections when expanding tasks
- Add validation to ensure expanded subtasks maintain fidelity to original PRD specifications
## Technical Implementation Details
### File Modifications Required:
1. **scripts/modules/task-manager/parse-prd.js**
- Add PRD analysis functions for intelligent segmentation
- Implement context preservation during task generation
- Add optional expansion pipeline integration
- Create PRD-to-task mapping system
2. **scripts/modules/task-manager/expand-task.js**
- Enhance to accept PRD context as additional input
- Modify expansion prompts to include relevant PRD excerpts
- Add PRD-grounded validation for generated subtasks
3. **scripts/modules/ai-services-unified.js**
- Add support for context-aware prompting with PRD excerpts
- Implement intelligent context windowing for large PRDs
- Add PRD analysis capabilities for complexity assessment
### New Data Structures:
```javascript
const tiktoken = require('tiktoken');
/**
* Count tokens for a given text and model
* @param {string} text - The text to count tokens for
* @param {string} provider - The AI provider (e.g., 'openai', 'anthropic')
* @param {string} modelId - The model ID
* @returns {number} - Estimated token count
*/
function countTokens(text, provider, modelId) {
if (!text) return 0;
// Convert to lowercase for case-insensitive matching
const providerLower = provider?.toLowerCase();
try {
// OpenAI models
if (providerLower === 'openai') {
// Most OpenAI chat models use cl100k_base encoding
const encoding = tiktoken.encoding_for_model(modelId) || tiktoken.get_encoding('cl100k_base');
return encoding.encode(text).length;
}
// Anthropic models - can use cl100k_base as an approximation
// or follow Anthropic's guidance
if (providerLower === 'anthropic') {
try {
// Try to use cl100k_base as a reasonable approximation
const encoding = tiktoken.get_encoding('cl100k_base');
return encoding.encode(text).length;
} catch (e) {
// Fallback to Anthropic's character-based estimation
return Math.ceil(text.length / 3.5); // ~3.5 chars per token for English
}
}
// For other providers, use character-based estimation as fallback
// Different providers may have different tokenization schemes
return Math.ceil(text.length / 4); // General fallback estimate
} catch (error) {
console.warn(`Token counting error: ${error.message}. Using character-based estimate.`);
return Math.ceil(text.length / 4); // Fallback if tiktoken fails
}
// Enhanced task structure with PRD context
{
id: "1",
title: "User Authentication System",
description: "...",
prdContext: {
sourceSection: "Authentication Requirements (Lines 45-78)",
originalText: "The system must implement OAuth 2.0...",
relatedSections: ["Security Requirements", "User Management"],
contextWindow: "Full PRD excerpt relevant to this task"
},
// ... existing fields
}
module.exports = { countTokens };
// PRD analysis metadata
{
prdAnalysis: {
totalComplexity: 8.5,
naturalTaskBoundaries: [...],
recommendedTaskCount: 15,
sectionMappings: {...}
}
}
```
3. Add tests for the token counter in `tests/token-counter.test.js`:
```javascript
const { countTokens } = require('../scripts/modules/token-counter');
### New CLI Options:
- `--expand-tasks`: Automatically expand generated tasks using PRD context
- `--preserve-detail`: Maximum detail preservation mode
- `--adaptive-count`: Let AI determine optimal task count based on PRD complexity
- `--context-window-size`: Control how much PRD context to include in expansions
describe('Token Counter', () => {
test('counts tokens for OpenAI models', () => {
const text = 'Hello, world! This is a test.';
const count = countTokens(text, 'openai', 'gpt-4');
expect(count).toBeGreaterThan(0);
expect(typeof count).toBe('number');
## Implementation Strategy
### Step 1: PRD Analysis Enhancement
- Create PRD parsing utilities that identify natural section boundaries
- Implement complexity scoring for different PRD sections
- Build context extraction functions that preserve relevant details
### Step 2: Context-Aware Task Generation
- Modify the task generation prompt to include section-specific context
- Implement task-to-PRD mapping during generation
- Add metadata fields to preserve PRD relationships
### Step 3: Intelligent Expansion Pipeline
- Create expansion logic that uses preserved PRD context
- Implement smart prompt engineering that includes relevant PRD excerpts
- Add validation to ensure subtask fidelity to original requirements
### Step 4: Integration and Testing
- Integrate new functionality with existing parse-prd workflow
- Add comprehensive testing with various PRD types and complexities
- Implement telemetry for tracking detail preservation effectiveness
## Success Metrics
- PRD detail preservation rate (measured by semantic similarity between PRD and generated tasks)
- Reduction in manual task refinement needed post-parsing
- Improved accuracy of expanded subtasks compared to PRD specifications
- User satisfaction with task granularity and detail accuracy
## Edge Cases and Considerations
- Very large PRDs that exceed context windows
- PRDs with conflicting or ambiguous requirements
- Integration with existing task expansion workflows
- Performance impact of enhanced analysis
- Backward compatibility with existing parse-prd usage
# Test Strategy:
# Subtasks:
## 1. Implement PRD Analysis and Segmentation Engine [pending]
### Dependencies: None
### Description: Create intelligent PRD parsing that identifies natural task boundaries and complexity metrics
### Details:
## Implementation Requirements
### Core Functions to Implement:
1. **analyzePRDStructure(prdContent)**
- Parse PRD into logical sections using headers, bullet points, and semantic breaks
- Identify feature boundaries, technical requirements, and implementation sections
- Return structured analysis with section metadata
2. **calculatePRDComplexity(prdContent)**
- Analyze technical depth, feature count, integration requirements
- Score complexity on 1-10 scale for different aspects
- Return recommended task count based on complexity
3. **extractTaskBoundaries(prdAnalysis)**
- Identify natural breaking points for task creation
- Group related requirements into logical task units
- Preserve context relationships between sections
### Technical Approach:
- Use regex patterns and NLP techniques to identify section headers
- Implement keyword analysis for technical complexity assessment
- Create semantic grouping algorithms for related requirements
- Build context preservation mappings
### Output Structure:
```javascript
{
sections: [
{
title: "User Authentication",
content: "...",
startLine: 45,
endLine: 78,
complexity: 7,
relatedSections: ["Security", "User Management"]
}
],
overallComplexity: 8.5,
recommendedTaskCount: 15,
naturalBoundaries: [...],
contextMappings: {...}
}
```
### Integration Points:
- Called at the beginning of parse-prd process
- Results used to inform task generation strategy
- Analysis stored for later use in expansion phase
## 2. Enhance Task Generation with PRD Context Preservation [pending]
### Dependencies: None
### Description: Modify generateTasksFromPRD to embed PRD context and maintain source mappings
### Details:
## Implementation Requirements
### Core Modifications to generateTasksFromPRD:
1. **Add PRD Context Embedding**
- Modify task generation prompt to include relevant PRD excerpts
- Ensure each generated task includes source section references
- Preserve original PRD language and specifications in task metadata
2. **Implement Context Windowing**
- For large PRDs, implement intelligent context windowing
- Include relevant sections for each task being generated
- Maintain context relationships between related tasks
3. **Enhanced Task Structure**
- Add prdContext field to task objects
- Include sourceSection, originalText, and relatedSections
- Store contextWindow for later use in expansions
### Technical Implementation:
```javascript
// Enhanced task generation with context
const generateTaskWithContext = async (prdSection, relatedSections, fullPRD) => {
const contextWindow = buildContextWindow(prdSection, relatedSections, fullPRD);
const prompt = `
Generate a task based on this PRD section:
PRIMARY SECTION:
${prdSection.content}
RELATED CONTEXT:
${contextWindow}
Ensure the task preserves all specific requirements and technical details.
`;
// Generate task with embedded context
const task = await generateTask(prompt);
task.prdContext = {
sourceSection: prdSection.title,
originalText: prdSection.content,
relatedSections: relatedSections.map(s => s.title),
contextWindow: contextWindow
};
return task;
};
```
### Context Preservation Strategy:
- Map each task to its source PRD sections
- Preserve technical specifications and requirements language
- Maintain relationships between interdependent features
- Store context for later use in expansion phase
### Integration with Existing Flow:
- Modify existing generateTasksFromPRD function
- Maintain backward compatibility with simple PRDs
- Add new metadata fields without breaking existing structure
- Ensure context is available for subsequent operations
## 3. Implement In-Flight Task Expansion Pipeline [pending]
### Dependencies: None
### Description: Add optional --expand-tasks flag and intelligent expansion using preserved PRD context
### Details:
## Implementation Requirements
### Core Features:
1. **Add --expand-tasks CLI Flag**
- Optional flag for parse-prd command
- Triggers automatic expansion after initial task generation
- Configurable expansion depth and strategy
2. **Two-Pass Processing System**
- First pass: Generate tasks with PRD context preservation
- Second pass: Expand tasks using their embedded PRD context
- Maintain context fidelity throughout the process
3. **Context-Aware Expansion Logic**
- Use preserved PRD context for each task's expansion
- Include relevant PRD excerpts in expansion prompts
- Ensure subtasks maintain fidelity to original specifications
### Technical Implementation:
```javascript
// Enhanced parse-prd with expansion pipeline
const parsePRDWithExpansion = async (prdContent, options) => {
// Phase 1: Analyze and generate tasks with context
const prdAnalysis = await analyzePRDStructure(prdContent);
const tasksWithContext = await generateTasksWithContext(prdAnalysis);
// Phase 2: Expand tasks if requested
if (options.expandTasks) {
for (const task of tasksWithContext) {
if (shouldExpandTask(task, prdAnalysis)) {
const expandedSubtasks = await expandTaskWithPRDContext(task);
task.subtasks = expandedSubtasks;
}
}
}
return tasksWithContext;
};
// Context-aware task expansion
const expandTaskWithPRDContext = async (task) => {
const { prdContext } = task;
const expansionPrompt = `
Expand this task into detailed subtasks using the original PRD context:
TASK: ${task.title}
DESCRIPTION: ${task.description}
ORIGINAL PRD CONTEXT:
${prdContext.originalText}
RELATED SECTIONS:
${prdContext.contextWindow}
Generate subtasks that preserve all technical details and requirements from the PRD.
`;
return await generateSubtasks(expansionPrompt);
};
```
### CLI Integration:
- Add --expand-tasks flag to parse-prd command
- Add --expansion-depth option for controlling subtask levels
- Add --preserve-detail flag for maximum context preservation
- Maintain backward compatibility with existing parse-prd usage
### Expansion Strategy:
- Determine which tasks should be expanded based on complexity
- Use PRD context to generate accurate, detailed subtasks
- Preserve technical specifications and implementation details
- Validate subtask accuracy against original PRD content
### Performance Considerations:
- Implement batching for large numbers of tasks
- Add progress indicators for long-running expansions
- Optimize context window sizes for efficiency
- Cache PRD analysis results for reuse
## 4. Enhance Expand-Task with PRD Context Integration [pending]
### Dependencies: None
### Description: Modify existing expand-task functionality to leverage preserved PRD context for more accurate expansions
### Details:
## Implementation Requirements
### Core Enhancements to expand-task.js:
1. **PRD Context Detection**
- Check if task has embedded prdContext metadata
- Extract relevant PRD sections for expansion
- Fall back to existing expansion logic if no PRD context
2. **Context-Enhanced Expansion Prompts**
- Include original PRD excerpts in expansion prompts
- Add related section context for comprehensive understanding
- Preserve technical specifications and requirements language
3. **Validation and Quality Assurance**
- Validate generated subtasks against original PRD content
- Ensure technical accuracy and requirement compliance
- Flag potential discrepancies for review
### Technical Implementation:
```javascript
// Enhanced expand-task with PRD context
const expandTaskWithContext = async (taskId, options, context) => {
const task = await getTask(taskId);
// Check for PRD context
if (task.prdContext) {
return await expandWithPRDContext(task, options);
} else {
// Fall back to existing expansion logic
return await expandTaskStandard(task, options);
}
};
const expandWithPRDContext = async (task, options) => {
const { prdContext } = task;
const enhancedPrompt = `
Expand this task into detailed subtasks using the original PRD context:
TASK DETAILS:
Title: ${task.title}
Description: ${task.description}
Current Details: ${task.details}
ORIGINAL PRD CONTEXT:
Source Section: ${prdContext.sourceSection}
Original Requirements:
${prdContext.originalText}
RELATED CONTEXT:
${prdContext.contextWindow}
EXPANSION REQUIREMENTS:
- Preserve all technical specifications from the PRD
- Maintain requirement accuracy and completeness
- Generate ${options.num || 'appropriate number of'} subtasks
- Include implementation details that reflect PRD specifics
Generate subtasks that are grounded in the original PRD content.
`;
const subtasks = await generateSubtasks(enhancedPrompt, options);
// Add PRD context inheritance to subtasks
subtasks.forEach(subtask => {
subtask.prdContext = {
inheritedFrom: task.id,
sourceSection: prdContext.sourceSection,
relevantExcerpt: extractRelevantExcerpt(prdContext, subtask)
};
});
test('counts tokens for Anthropic models', () => {
const text = 'Hello, world! This is a test.';
const count = countTokens(text, 'anthropic', 'claude-3-7-sonnet-20250219');
expect(count).toBeGreaterThan(0);
expect(typeof count).toBe('number');
return subtasks;
};
```
### Integration Points:
1. **Modify existing expand-task.js**
- Add PRD context detection logic
- Enhance prompt generation with context
- Maintain backward compatibility
2. **Update expansion validation**
- Add PRD compliance checking
- Implement quality scoring for context fidelity
- Flag potential accuracy issues
3. **CLI and MCP Integration**
- Update expand-task command to leverage PRD context
- Add options for context-aware expansion
- Maintain existing command interface
### Context Inheritance Strategy:
- Pass relevant PRD context to generated subtasks
- Create context inheritance chain for nested expansions
- Preserve source traceability throughout expansion tree
- Enable future re-expansion with maintained context
### Quality Assurance Features:
- Semantic similarity checking between subtasks and PRD
- Technical requirement compliance validation
- Automated flagging of potential context drift
- User feedback integration for continuous improvement
## 5. Add New CLI Options and MCP Parameters [pending]
### Dependencies: None
### Description: Implement new command-line flags and MCP tool parameters for enhanced PRD parsing
### Details:
## Implementation Requirements
### New CLI Options for parse-prd:
1. **--expand-tasks**
- Automatically expand generated tasks using PRD context
- Boolean flag, default false
- Triggers in-flight expansion pipeline
2. **--preserve-detail**
- Maximum detail preservation mode
- Boolean flag, default false
- Ensures highest fidelity to PRD content
3. **--adaptive-count**
- Let AI determine optimal task count based on PRD complexity
- Boolean flag, default false
- Overrides --num-tasks when enabled
4. **--context-window-size**
- Control how much PRD context to include in expansions
- Integer value, default 2000 characters
- Balances context richness with performance
5. **--expansion-depth**
- Control how many levels deep to expand tasks
- Integer value, default 1
- Prevents excessive nesting
### MCP Tool Parameter Updates:
```javascript
// Enhanced parse_prd MCP tool parameters
{
input: "Path to PRD file",
output: "Output path for tasks.json",
numTasks: "Number of top-level tasks (overridden by adaptiveCount)",
expandTasks: "Boolean - automatically expand tasks with PRD context",
preserveDetail: "Boolean - maximum detail preservation mode",
adaptiveCount: "Boolean - AI determines optimal task count",
contextWindowSize: "Integer - context size for expansions",
expansionDepth: "Integer - levels of expansion to perform",
research: "Boolean - use research model for enhanced analysis",
force: "Boolean - overwrite existing files"
}
```
### CLI Command Updates:
```bash
# Enhanced parse-prd command examples
task-master parse-prd prd.txt --expand-tasks --preserve-detail
task-master parse-prd prd.txt --adaptive-count --expansion-depth=2
task-master parse-prd prd.txt --context-window-size=3000 --research
```
### Implementation Details:
1. **Update commands.js**
- Add new option definitions
- Update parse-prd command handler
- Maintain backward compatibility
2. **Update MCP tool definition**
- Add new parameter schemas
- Update tool description and examples
- Ensure parameter validation
3. **Parameter Processing Logic**
- Validate parameter combinations
- Set appropriate defaults
- Handle conflicting options gracefully
### Validation Rules:
- expansion-depth must be positive integer ≤ 3
- context-window-size must be between 500-5000 characters
- adaptive-count overrides num-tasks when both specified
- expand-tasks requires either adaptive-count or num-tasks > 5
### Help Documentation Updates:
- Update command help text with new options
- Add usage examples for different scenarios
- Document parameter interactions and constraints
- Include performance considerations for large PRDs
## 6. Implement Comprehensive Testing and Validation [pending]
### Dependencies: None
### Description: Create test suite for PRD analysis, context preservation, and expansion accuracy
### Details:
## Implementation Requirements
### Test Categories:
1. **PRD Analysis Testing**
- Test section identification with various PRD formats
- Validate complexity scoring accuracy
- Test boundary detection for different document structures
- Verify context mapping correctness
2. **Context Preservation Testing**
- Validate PRD context embedding in generated tasks
- Test context window generation and sizing
- Verify source section mapping accuracy
- Test context inheritance in subtasks
3. **Expansion Accuracy Testing**
- Compare PRD-grounded vs standard expansions
- Measure semantic similarity between PRD and subtasks
- Test technical requirement preservation
- Validate expansion depth and quality
4. **Integration Testing**
- Test full parse-prd pipeline with expansion
- Validate CLI option combinations
- Test MCP tool parameter handling
- Verify backward compatibility
### Test Data Requirements:
```javascript
// Test PRD samples
const testPRDs = {
simple: "Basic PRD with minimal technical details",
complex: "Detailed PRD with extensive technical specifications",
structured: "Well-organized PRD with clear sections",
unstructured: "Free-form PRD with mixed content",
technical: "Highly technical PRD with specific requirements",
large: "Very large PRD testing context window limits"
};
```
### Validation Metrics:
1. **Detail Preservation Score**
- Semantic similarity between PRD and generated tasks
- Technical requirement coverage percentage
- Specification accuracy rating
2. **Context Fidelity Score**
- Accuracy of source section mapping
- Relevance of included context windows
- Quality of context inheritance
3. **Expansion Quality Score**
- Subtask relevance to parent task and PRD
- Technical accuracy of implementation details
- Completeness of requirement coverage
### Test Implementation:
```javascript
// Example test structure
describe('Enhanced Parse-PRD', () => {
describe('PRD Analysis', () => {
test('should identify sections correctly', async () => {
const analysis = await analyzePRDStructure(testPRDs.structured);
expect(analysis.sections).toHaveLength(expectedSectionCount);
expect(analysis.overallComplexity).toBeGreaterThan(0);
});
test('should calculate appropriate task count', async () => {
const analysis = await analyzePRDStructure(testPRDs.complex);
expect(analysis.recommendedTaskCount).toBeGreaterThan(10);
});
});
test('handles empty text', () => {
expect(countTokens('', 'openai', 'gpt-4')).toBe(0);
expect(countTokens(null, 'openai', 'gpt-4')).toBe(0);
describe('Context Preservation', () => {
test('should embed PRD context in tasks', async () => {
const tasks = await generateTasksWithContext(testPRDs.technical);
tasks.forEach(task => {
expect(task.prdContext).toBeDefined();
expect(task.prdContext.sourceSection).toBeTruthy();
expect(task.prdContext.originalText).toBeTruthy();
});
});
});
describe('Expansion Accuracy', () => {
test('should generate relevant subtasks from PRD context', async () => {
const task = createTestTaskWithPRDContext();
const subtasks = await expandTaskWithPRDContext(task);
const relevanceScore = calculateRelevanceScore(subtasks, task.prdContext);
expect(relevanceScore).toBeGreaterThan(0.8);
});
});
});
```
# Test Strategy:
1. Unit test the countTokens function with various inputs and models
2. Compare token counts with known examples from OpenAI and Anthropic documentation
3. Test edge cases: empty strings, very long texts, non-English texts
4. Test fallback behavior when tiktoken fails or is not applicable
### Performance Testing:
- Test with large PRDs (>10,000 words)
- Measure processing time for different complexity levels
- Test memory usage with extensive context preservation
- Validate timeout handling for long-running operations
### Quality Assurance Tools:
- Automated semantic similarity checking
- Technical requirement compliance validation
- Context drift detection algorithms
- User acceptance testing framework
### Continuous Integration:
- Add tests to existing CI pipeline
- Set up performance benchmarking
- Implement quality gates for PRD processing
- Create regression testing for context preservation

View File

@@ -1,104 +0,0 @@
# Task ID: 85
# Title: Update ai-services-unified.js for dynamic token limits
# Status: pending
# Dependencies: 83, 84
# Priority: medium
# Description: Modify the _unifiedServiceRunner function in ai-services-unified.js to use the new token counting utility and dynamically adjust output token limits based on input length.
# Details:
1. Import the token counter in `ai-services-unified.js`:
```javascript
const { countTokens } = require('./token-counter');
const { getParametersForRole, getModelCapabilities } = require('./config-manager');
```
2. Update the `_unifiedServiceRunner` function to implement dynamic token limit adjustment:
```javascript
async function _unifiedServiceRunner({
serviceType,
provider,
modelId,
systemPrompt,
prompt,
temperature,
currentRole,
effectiveProjectRoot,
// ... other parameters
}) {
// Get role parameters with new token limits
const roleParams = getParametersForRole(currentRole, effectiveProjectRoot);
// Get model capabilities
const modelCapabilities = getModelCapabilities(provider, modelId);
// Count tokens in the prompts
const systemPromptTokens = countTokens(systemPrompt, provider, modelId);
const userPromptTokens = countTokens(prompt, provider, modelId);
const totalPromptTokens = systemPromptTokens + userPromptTokens;
// Validate against input token limits
if (totalPromptTokens > roleParams.maxInputTokens) {
throw new Error(
`Prompt (${totalPromptTokens} tokens) exceeds configured max input tokens (${roleParams.maxInputTokens}) for role '${currentRole}'.`
);
}
// Validate against model's absolute context window
if (modelCapabilities.contextWindowTokens && totalPromptTokens > modelCapabilities.contextWindowTokens) {
throw new Error(
`Prompt (${totalPromptTokens} tokens) exceeds model's context window (${modelCapabilities.contextWindowTokens}) for ${modelId}.`
);
}
// Calculate available output tokens
// If model has a combined context window, we need to subtract input tokens
let availableOutputTokens = roleParams.maxOutputTokens;
// If model has a context window constraint, ensure we don't exceed it
if (modelCapabilities.contextWindowTokens) {
const remainingContextTokens = modelCapabilities.contextWindowTokens - totalPromptTokens;
availableOutputTokens = Math.min(availableOutputTokens, remainingContextTokens);
}
// Also respect the model's absolute max output limit
if (modelCapabilities.maxOutputTokens) {
availableOutputTokens = Math.min(availableOutputTokens, modelCapabilities.maxOutputTokens);
}
// Prepare API call parameters
const callParams = {
apiKey,
modelId,
maxTokens: availableOutputTokens, // Use dynamically calculated output limit
temperature: roleParams.temperature,
messages,
baseUrl,
...(serviceType === 'generateObject' && { schema, objectName }),
...restApiParams
};
// Log token usage information
console.debug(`Token usage: ${totalPromptTokens} input tokens, ${availableOutputTokens} max output tokens`);
// Rest of the function remains the same...
}
```
3. Update the error handling to provide clear messages about token limits:
```javascript
try {
// Existing code...
} catch (error) {
if (error.message.includes('tokens')) {
// Token-related errors should be clearly identified
console.error(`Token limit error: ${error.message}`);
}
throw error;
}
```
# Test Strategy:
1. Test with prompts of various lengths to verify dynamic adjustment
2. Test with different models to ensure model-specific limits are respected
3. Verify error messages are clear when limits are exceeded
4. Test edge cases: very short prompts, prompts near the limit
5. Integration test with actual API calls to verify the calculated limits work in practice

View File

@@ -1,107 +0,0 @@
# Task ID: 86
# Title: Update .taskmasterconfig schema and user guide
# Status: pending
# Dependencies: 83
# Priority: medium
# Description: Create a migration guide for users to update their .taskmasterconfig files and document the new token limit configuration options.
# Details:
1. Create a migration script or guide for users to update their existing `.taskmasterconfig` files:
```javascript
// Example migration snippet for .taskmasterconfig
{
"main": {
// Before:
// "maxTokens": 16000,
// After:
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
},
"research": {
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
},
"fallback": {
"maxInputTokens": 8000,
"maxOutputTokens": 2000,
"temperature": 0.7
}
}
```
2. Update the user documentation to explain the new token limit fields:
```markdown
# Token Limit Configuration
Task Master now provides more granular control over token limits with separate settings for input and output tokens:
- `maxInputTokens`: Maximum number of tokens allowed in the input prompt (system prompt + user prompt)
- `maxOutputTokens`: Maximum number of tokens the model should generate in its response
## Benefits
- More precise control over token usage
- Better cost management
- Reduced likelihood of hitting model context limits
- Dynamic adjustment to maximize output space based on input length
## Migration from Previous Versions
If you're upgrading from a previous version, you'll need to update your `.taskmasterconfig` file:
1. Replace the single `maxTokens` field with separate `maxInputTokens` and `maxOutputTokens` fields
2. Recommended starting values:
- Set `maxInputTokens` to your previous `maxTokens` value
- Set `maxOutputTokens` to approximately 1/4 of your model's context window
## Example Configuration
```json
{
"main": {
"maxInputTokens": 16000,
"maxOutputTokens": 4000,
"temperature": 0.7
}
}
```
```
3. Update the schema validation in `config-manager.js` to validate the new fields:
```javascript
function _validateConfig(config) {
// ... existing validation
// Validate token limits for each role
['main', 'research', 'fallback'].forEach(role => {
if (config[role]) {
// Check if old maxTokens is present and warn about migration
if (config[role].maxTokens !== undefined) {
console.warn(`Warning: 'maxTokens' in ${role} role is deprecated. Please use 'maxInputTokens' and 'maxOutputTokens' instead.`);
}
// Validate new token limit fields
if (config[role].maxInputTokens !== undefined && (!Number.isInteger(config[role].maxInputTokens) || config[role].maxInputTokens <= 0)) {
throw new Error(`Invalid maxInputTokens for ${role} role: must be a positive integer`);
}
if (config[role].maxOutputTokens !== undefined && (!Number.isInteger(config[role].maxOutputTokens) || config[role].maxOutputTokens <= 0)) {
throw new Error(`Invalid maxOutputTokens for ${role} role: must be a positive integer`);
}
}
});
return config;
}
```
# Test Strategy:
1. Verify documentation is clear and provides migration steps
2. Test the validation logic with various config formats
3. Test backward compatibility with old config format
4. Ensure error messages are helpful when validation fails

View File

@@ -1,119 +0,0 @@
# Task ID: 87
# Title: Implement validation and error handling
# Status: pending
# Dependencies: 85
# Priority: low
# Description: Add comprehensive validation and error handling for token limits throughout the system, including helpful error messages and graceful fallbacks.
# Details:
1. Add validation when loading models in `config-manager.js`:
```javascript
function _validateModelMap(modelMap) {
// Validate each provider's models
Object.entries(modelMap).forEach(([provider, models]) => {
models.forEach(model => {
// Check for required token limit fields
if (!model.contextWindowTokens) {
console.warn(`Warning: Model ${model.id} from ${provider} is missing contextWindowTokens field`);
}
if (!model.maxOutputTokens) {
console.warn(`Warning: Model ${model.id} from ${provider} is missing maxOutputTokens field`);
}
});
});
return modelMap;
}
```
2. Add validation when setting up a model in the CLI:
```javascript
function validateModelConfig(modelConfig, modelCapabilities) {
const issues = [];
// Check if input tokens exceed model's context window
if (modelConfig.maxInputTokens > modelCapabilities.contextWindowTokens) {
issues.push(`maxInputTokens (${modelConfig.maxInputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
}
// Check if output tokens exceed model's maximum
if (modelConfig.maxOutputTokens > modelCapabilities.maxOutputTokens) {
issues.push(`maxOutputTokens (${modelConfig.maxOutputTokens}) exceeds model's maximum output tokens (${modelCapabilities.maxOutputTokens})`);
}
// Check if combined tokens exceed context window
if (modelConfig.maxInputTokens + modelConfig.maxOutputTokens > modelCapabilities.contextWindowTokens) {
issues.push(`Combined maxInputTokens and maxOutputTokens (${modelConfig.maxInputTokens + modelConfig.maxOutputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
}
return issues;
}
```
3. Add graceful fallbacks in `ai-services-unified.js`:
```javascript
// Fallback for missing token limits
if (!roleParams.maxInputTokens) {
console.warn(`Warning: maxInputTokens not specified for role '${currentRole}'. Using default value.`);
roleParams.maxInputTokens = 8000; // Reasonable default
}
if (!roleParams.maxOutputTokens) {
console.warn(`Warning: maxOutputTokens not specified for role '${currentRole}'. Using default value.`);
roleParams.maxOutputTokens = 2000; // Reasonable default
}
// Fallback for missing model capabilities
if (!modelCapabilities.contextWindowTokens) {
console.warn(`Warning: contextWindowTokens not specified for model ${modelId}. Using conservative estimate.`);
modelCapabilities.contextWindowTokens = roleParams.maxInputTokens + roleParams.maxOutputTokens;
}
if (!modelCapabilities.maxOutputTokens) {
console.warn(`Warning: maxOutputTokens not specified for model ${modelId}. Using role configuration.`);
modelCapabilities.maxOutputTokens = roleParams.maxOutputTokens;
}
```
4. Add detailed logging for token usage:
```javascript
function logTokenUsage(provider, modelId, inputTokens, outputTokens, role) {
const inputCost = calculateTokenCost(provider, modelId, 'input', inputTokens);
const outputCost = calculateTokenCost(provider, modelId, 'output', outputTokens);
console.info(`Token usage for ${role} role with ${provider}/${modelId}:`);
console.info(`- Input: ${inputTokens.toLocaleString()} tokens ($${inputCost.toFixed(6)})`);
console.info(`- Output: ${outputTokens.toLocaleString()} tokens ($${outputCost.toFixed(6)})`);
console.info(`- Total cost: $${(inputCost + outputCost).toFixed(6)}`);
console.info(`- Available output tokens: ${availableOutputTokens.toLocaleString()}`);
}
```
5. Add a helper function to suggest configuration improvements:
```javascript
function suggestTokenConfigImprovements(roleParams, modelCapabilities, promptTokens) {
const suggestions = [];
// If prompt is using less than 50% of allowed input
if (promptTokens < roleParams.maxInputTokens * 0.5) {
suggestions.push(`Consider reducing maxInputTokens from ${roleParams.maxInputTokens} to save on potential costs`);
}
// If output tokens are very limited due to large input
const availableOutput = Math.min(
roleParams.maxOutputTokens,
modelCapabilities.contextWindowTokens - promptTokens
);
if (availableOutput < roleParams.maxOutputTokens * 0.5) {
suggestions.push(`Available output tokens (${availableOutput}) are significantly less than configured maxOutputTokens (${roleParams.maxOutputTokens}) due to large input`);
}
return suggestions;
}
```
# Test Strategy:
1. Test validation functions with valid and invalid configurations
2. Verify fallback behavior works correctly when configuration is missing
3. Test error messages are clear and actionable
4. Test logging functions provide useful information
5. Verify suggestion logic provides helpful recommendations

View File

@@ -1,57 +0,0 @@
# Task ID: 88
# Title: Enhance Add-Task Functionality to Consider All Task Dependencies
# Status: done
# Dependencies: None
# Priority: medium
# Description: Improve the add-task feature to accurately account for all dependencies among tasks, ensuring proper task ordering and execution.
# Details:
1. Review current implementation of add-task functionality.
2. Identify existing mechanisms for handling task dependencies.
3. Modify add-task to recursively analyze and incorporate all dependencies.
4. Ensure that dependencies are resolved in the correct order during task execution.
5. Update documentation to reflect changes in dependency handling.
6. Consider edge cases such as circular dependencies and handle them appropriately.
7. Optimize performance to ensure efficient dependency resolution, especially for projects with a large number of tasks.
8. Integrate with existing validation and error handling mechanisms (from Task 87) to provide clear feedback if dependencies cannot be resolved.
9. Test thoroughly with various dependency scenarios to ensure robustness.
# Test Strategy:
1. Create test cases with simple linear dependencies to verify correct ordering.
2. Develop test cases with complex, nested dependencies to ensure recursive resolution works correctly.
3. Include tests for edge cases such as circular dependencies, verifying appropriate error messages are displayed.
4. Measure performance with large sets of tasks and dependencies to ensure efficiency.
5. Conduct integration testing with other components that rely on task dependencies.
6. Perform manual code reviews to validate implementation against requirements.
7. Execute automated tests to verify no regressions in existing functionality.
# Subtasks:
## 1. Review Current Add-Task Implementation and Identify Dependency Mechanisms [done]
### Dependencies: None
### Description: Examine the existing add-task functionality to understand how task dependencies are currently handled.
### Details:
Conduct a code review of the add-task feature. Document any existing mechanisms for handling task dependencies.
## 2. Modify Add-Task to Recursively Analyze Dependencies [done]
### Dependencies: 88.1
### Description: Update the add-task functionality to recursively analyze and incorporate all task dependencies.
### Details:
Implement a recursive algorithm that identifies and incorporates all dependencies for a given task. Ensure it handles nested dependencies correctly.
## 3. Ensure Correct Order of Dependency Resolution [done]
### Dependencies: 88.2
### Description: Modify the add-task functionality to ensure that dependencies are resolved in the correct order during task execution.
### Details:
Implement logic to sort and execute tasks based on their dependency order. Handle cases where multiple tasks depend on each other.
## 4. Integrate with Existing Validation and Error Handling [done]
### Dependencies: 88.3
### Description: Update the add-task functionality to integrate with existing validation and error handling mechanisms (from Task 87).
### Details:
Modify the code to provide clear feedback if dependencies cannot be resolved. Ensure that circular dependencies are detected and handled appropriately.
## 5. Optimize Performance for Large Projects [done]
### Dependencies: 88.4
### Description: Optimize the add-task functionality to ensure efficient dependency resolution, especially for projects with a large number of tasks.
### Details:
Profile and optimize the recursive dependency analysis algorithm. Implement caching or other performance improvements as needed.

View File

@@ -1,23 +0,0 @@
# Task ID: 89
# Title: Introduce Prioritize Command with Enhanced Priority Levels
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Implement a prioritize command with --up/--down/--priority/--id flags and shorthand equivalents (-u/-d/-p/-i). Add 'lowest' and 'highest' priority levels, updating CLI output accordingly.
# Details:
The new prioritize command should allow users to adjust task priorities using the specified flags. The --up and --down flags will modify the priority relative to the current level, while --priority sets an absolute priority. The --id flag specifies which task to prioritize. Shorthand equivalents (-u/-d/-p/-i) should be supported for user convenience.
The priority levels should now include 'lowest', 'low', 'medium', 'high', and 'highest'. The CLI output should be updated to reflect these new priority levels accurately.
Considerations:
- Ensure backward compatibility with existing commands and configurations.
- Update the help documentation to include the new command and its usage.
- Implement proper error handling for invalid priority levels or missing flags.
# Test Strategy:
To verify task completion, perform the following tests:
1. Test each flag (--up, --down, --priority, --id) individually and in combination to ensure they function as expected.
2. Verify that shorthand equivalents (-u, -d, -p, -i) work correctly.
3. Check that the new priority levels ('lowest' and 'highest') are recognized and displayed properly in CLI output.
4. Test error handling for invalid inputs (e.g., non-existent task IDs, invalid priority levels).
5. Ensure that the help command displays accurate information about the new prioritize command.

View File

@@ -1,49 +0,0 @@
# Task ID: 91
# Title: Implement Move Command for Tasks and Subtasks
# Status: done
# Dependencies: 1, 3
# Priority: medium
# Description: Introduce a 'move' command to enable moving tasks or subtasks to a different id, facilitating conflict resolution by allowing teams to assign new ids as needed.
# Details:
The move command will consist of three core components: 1) Core Logic Function in scripts/modules/task-manager/move-task.js, 2) Direct Function Wrapper in mcp-server/src/core/direct-functions/move-task.js, and 3) MCP Tool in mcp-server/src/tools/move-task.js. The command will accept source and destination IDs, handling various scenarios including moving tasks to become subtasks, subtasks to become tasks, and subtasks between different parents. The implementation will handle edge cases such as invalid ids, non-existent parents, circular dependencies, and will properly update all dependencies.
# Test Strategy:
Testing will follow a three-tier approach: 1) Unit tests for core functionality including moving tasks to subtasks, subtasks to tasks, subtasks between parents, dependency handling, and validation error cases; 2) Integration tests for the direct function with mock MCP environment and task file regeneration; 3) End-to-end tests for the full MCP tool call path. This will verify all scenarios including moving a task to a new id, moving a subtask under a different parent while preserving its hierarchy, and handling errors for invalid operations.
# Subtasks:
## 1. Design and implement core move logic [done]
### Dependencies: None
### Description: Create the fundamental logic for moving tasks and subtasks within the task management system hierarchy
### Details:
Implement the core logic function in scripts/modules/task-manager/move-task.js with the signature that accepts tasksPath, sourceId, destinationId, and generateFiles parameters. Develop functions to handle all movement operations including task-to-subtask, subtask-to-task, and subtask-to-subtask conversions. Implement validation for source and destination IDs, and ensure proper updating of parent-child relationships and dependencies.
## 2. Implement edge case handling [done]
### Dependencies: 91.1
### Description: Develop robust error handling for all potential edge cases in the move operation
### Details:
Create validation functions to detect invalid task IDs, non-existent parent tasks, and circular dependencies. Handle special cases such as moving a task to become the first/last subtask, reordering within the same parent, preventing moving a task to itself, and preventing moving a parent to its own subtask. Implement proper error messages and status codes for each edge case, and ensure system stability if a move operation fails.
## 3. Update CLI interface for move commands [done]
### Dependencies: 91.1
### Description: Extend the command-line interface to support the new move functionality with appropriate flags and options
### Details:
Create the Direct Function Wrapper in mcp-server/src/core/direct-functions/move-task.js to adapt the core logic for MCP, handling path resolution and parameter validation. Implement silent mode to prevent console output interfering with JSON responses. Create the MCP Tool in mcp-server/src/tools/move-task.js that exposes the functionality to Cursor, handles project root resolution, and includes proper Zod parameter definitions. Update MCP tool definition in .cursor/mcp.json and register the tool in mcp-server/src/tools/index.js.
## 4. Ensure data integrity during moves [done]
### Dependencies: 91.1, 91.2
### Description: Implement safeguards to maintain data consistency and update all relationships during move operations
### Details:
Implement dependency handling logic to update dependencies when converting between task/subtask, add appropriate parent dependencies when needed, and validate no circular dependencies are created. Create transaction-like operations to ensure atomic moves that either complete fully or roll back. Implement functions to update all affected task relationships after a move, and add verification steps to confirm data integrity post-move.
## 5. Create comprehensive test suite [done]
### Dependencies: 91.1, 91.2, 91.3, 91.4
### Description: Develop and execute tests covering all move scenarios and edge cases
### Details:
Create unit tests for core functionality including moving tasks to subtasks, subtasks to tasks, subtasks between parents, dependency handling, and validation error cases. Implement integration tests for the direct function with mock MCP environment and task file regeneration. Develop end-to-end tests for the full MCP tool call path. Ensure tests cover all identified edge cases and potential failure points, and verify data integrity after moves.
## 6. Export and integrate the move function [done]
### Dependencies: 91.1
### Description: Ensure the move function is properly exported and integrated with existing code
### Details:
Export the move function in scripts/modules/task-manager.js. Update task-master-core.js to include the direct function. Reuse validation logic from add-subtask.js and remove-subtask.js where appropriate. Follow silent mode implementation pattern from other direct functions and match parameter naming conventions in MCP tools.

View File

@@ -1,104 +0,0 @@
# Task ID: 92
# Title: Add Global Joke Flag to All CLI Commands
# Status: pending
# Dependencies: 2
# Priority: medium
# Description: Implement a global --joke flag that can be added to any command to include a programming-related joke with the command's output.
# Details:
Implement a global joke feature that enhances all CLI commands with optional humor. The implementation should:
1. **Global Flag Implementation**: Add a global --joke flag (with -j shorthand) to the Commander.js configuration in the CLI foundation that can be used with any command.
2. **Joke Service Module**: Create a new module (scripts/modules/joke-service.js) that:
- Maintains a curated collection of programming, development, and tech-related jokes
- Provides a getRandomJoke() function that returns a formatted joke
- Includes categories like programming languages, debugging, project management, etc.
- Ensures jokes are appropriate and professional
3. **Output Integration**: Modify the existing output formatting utilities to:
- Check for the --joke flag in global options
- Append a formatted joke section to command results when the flag is present
- Maintain proper formatting and spacing between regular output and jokes
- Ensure jokes don't interfere with JSON output mode (--json flag)
4. **Command Integration**: Update all existing commands to support the joke flag by:
- Modifying output functions to check for the joke flag
- Ensuring consistent joke placement across all command types
- Maintaining backward compatibility with existing command behavior
5. **Configuration Options**: Add configuration support for:
- Enabling/disabling joke categories
- Custom joke collections via configuration files
- Joke frequency settings for repeated command usage
The implementation should be non-intrusive, maintaining all existing functionality while adding this optional enhancement feature.
# Test Strategy:
Verify implementation through comprehensive testing:
1. **Flag Recognition Testing**: Test that the --joke and -j flags are properly recognized across all existing commands (list, add, update, move, plan, etc.)
2. **Output Format Testing**:
- Verify jokes appear correctly formatted after normal command output
- Test that jokes don't appear when flag is not used
- Confirm JSON output mode (--json) excludes jokes or formats them appropriately
- Test joke formatting with various command output lengths and types
3. **Joke Content Testing**:
- Verify jokes are appropriate and professional
- Test that getRandomJoke() returns different jokes on multiple calls
- Confirm joke categories are working correctly
4. **Integration Testing**: Test the joke flag with:
- Simple commands (list, help)
- Complex commands with multiple outputs (update, plan)
- Error scenarios to ensure jokes don't appear with error messages
- Combination with other global flags (--quiet, --debug, --json)
5. **Performance Testing**: Ensure the joke feature doesn't impact command execution speed or memory usage significantly
6. **Regression Testing**: Run existing test suite to confirm no existing functionality is broken by the joke feature implementation
# Subtasks:
## 1. Update CLI foundation to support global flags [pending]
### Dependencies: None
### Description: Modify the core CLI framework to recognize and handle global flags like --joke across all commands, ensuring proper flag parsing and propagation throughout the application.
### Details:
Implement global flag parsing mechanism, update command dispatcher to handle global flags, ensure flag inheritance across subcommands, and maintain backward compatibility with existing flag handling.
## 2. Develop the joke-service module with joke management and category support [pending]
### Dependencies: None
### Description: Create a dedicated service module for managing jokes, including joke retrieval, categorization, and content management functionality.
### Details:
Build joke storage/retrieval system, implement category-based joke selection, create joke content validation, add support for custom joke sources, and ensure thread-safe operations.
## 3. Integrate joke output into existing output utilities [pending]
### Dependencies: 92.1, 92.2
### Description: Modify output formatting utilities to seamlessly incorporate joke content without disrupting existing output formats, especially JSON output.
### Details:
Update output formatters to handle joke injection, ensure JSON output compatibility, implement conditional joke display logic, and maintain output consistency across different formats.
## 4. Update all CLI commands for joke flag compatibility [pending]
### Dependencies: 92.1, 92.3
### Description: Modify every existing CLI command to recognize and properly handle the global --joke flag while maintaining their core functionality.
### Details:
Update command handlers to process joke flag, integrate with output utilities, ensure no interference with command-specific logic, and maintain existing command behavior when flag is not used.
## 5. Add configuration options for joke categories and custom jokes [pending]
### Dependencies: 92.2
### Description: Implement configuration management for joke preferences, including category selection, custom joke sources, and user-defined joke content.
### Details:
Create configuration schema for joke settings, implement category preference management, add custom joke import/export functionality, and ensure configuration persistence across sessions.
## 6. Implement comprehensive testing [pending]
### Dependencies: 92.1, 92.2, 92.3, 92.4, 92.5
### Description: Develop thorough test coverage including flag recognition, output verification, content validation, integration testing, performance testing, and regression testing.
### Details:
Create unit tests for joke service, integration tests for flag handling, output format validation tests, performance benchmarks, regression test suite, and end-to-end testing scenarios.
## 7. Update documentation and usage examples [pending]
### Dependencies: 92.6
### Description: Comprehensive documentation update including usage examples, configuration guides, and integration instructions for the new --joke flag functionality.
### Details:
Update CLI help text, create usage examples for different scenarios, document configuration options, add troubleshooting guide, and update API documentation for developers.

View File

@@ -1,288 +0,0 @@
# Task ID: 93
# Title: Implement Git Workflow Integration
# Status: pending
# Dependencies: None
# Priority: high
# Description: Add `task-master git` command suite to automate git workflows based on established patterns from Task 4, eliminating manual overhead and ensuring 100% consistency
# Details:
Create a comprehensive git workflow automation system that integrates deeply with TaskMaster's task management. The feature will:
1. **Automated Branch Management**:
- Create branches following `task-{id}` naming convention
- Validate branch names and prevent conflicts
- Handle branch switching with uncommitted changes
- Clean up local and remote branches post-merge
2. **Intelligent Commit Generation**:
- Auto-detect commit type (feat/fix/test/refactor/docs) from file changes
- Generate standardized commit messages with task context
- Support subtask-specific commits with proper references
- Include coverage delta in test commits
3. **PR Automation**:
- Generate comprehensive PR descriptions from task/subtask data
- Include implementation details, test coverage, breaking changes
- Format using GitHub markdown with task hierarchy
- Auto-populate PR template with relevant metadata
4. **Workflow State Management**:
- Track current task branch and status
- Validate task readiness before PR creation
- Ensure all subtasks completed before finishing
- Handle merge conflicts gracefully
5. **Integration Points**:
- Seamless integration with existing task commands
- MCP server support for IDE integrations
- GitHub CLI (`gh`) authentication support
- Coverage report parsing and display
**Technical Architecture**:
- Modular command structure in `scripts/modules/task-manager/git-*`
- Git operations wrapper using simple-git or native child_process
- Template engine for commit/PR generation in `scripts/modules/`
- State persistence in `.taskmaster/git-state.json`
- Error recovery and rollback mechanisms
**Key Files to Create**:
- `scripts/modules/task-manager/git-start.js` - Branch creation and task status update
- `scripts/modules/task-manager/git-commit.js` - Intelligent commit message generation
- `scripts/modules/task-manager/git-pr.js` - PR creation with auto-generated description
- `scripts/modules/task-manager/git-finish.js` - Post-merge cleanup and status update
- `scripts/modules/task-manager/git-status.js` - Current git workflow state display
- `scripts/modules/git-operations.js` - Core git functionality wrapper
- `scripts/modules/commit-analyzer.js` - File change analysis for commit types
- `scripts/modules/pr-description-generator.js` - PR description template generator
**MCP Integration Files**:
- `mcp-server/src/core/direct-functions/git-start.js`
- `mcp-server/src/core/direct-functions/git-commit.js`
- `mcp-server/src/core/direct-functions/git-pr.js`
- `mcp-server/src/core/direct-functions/git-finish.js`
- `mcp-server/src/core/direct-functions/git-status.js`
- `mcp-server/src/tools/git-start.js`
- `mcp-server/src/tools/git-commit.js`
- `mcp-server/src/tools/git-pr.js`
- `mcp-server/src/tools/git-finish.js`
- `mcp-server/src/tools/git-status.js`
**Configuration**:
- Add git workflow settings to `.taskmasterconfig`
- Support for custom commit prefixes and PR templates
- Branch naming pattern customization
- Remote repository detection and validation
# Test Strategy:
Implement comprehensive test suite following Task 4's TDD approach:
1. **Unit Tests** (target: 95%+ coverage):
- Git operations wrapper with mocked git commands
- Commit type detection with various file change scenarios
- PR description generation with different task structures
- Branch name validation and generation
- State management and persistence
2. **Integration Tests**:
- Full workflow simulation in test repository
- Error handling for git conflicts and failures
- Multi-task workflow scenarios
- Coverage integration with real test runs
- GitHub API interaction (mocked)
3. **E2E Tests**:
- Complete task lifecycle from start to finish
- Multiple developer workflow simulation
- Merge conflict resolution scenarios
- Branch protection and validation
4. **Test Implementation Details**:
- Use Jest with git repository fixtures
- Mock simple-git for isolated unit tests
- Create test tasks.json scenarios
- Validate all error messages and edge cases
- Test rollback and recovery mechanisms
5. **Coverage Requirements**:
- Minimum 90% overall coverage
- 100% coverage for critical paths (branch creation, PR generation)
- All error scenarios must be tested
- Performance tests for large task hierarchies
# Subtasks:
## 1. Design and implement core git operations wrapper [pending]
### Dependencies: None
### Description: Create a robust git operations layer that handles all git commands with proper error handling and state management
### Details:
Create `scripts/modules/git-operations.js` with methods for:
- Branch creation/deletion (local and remote)
- Commit operations with message formatting
- Status checking and conflict detection
- Remote operations (fetch, push, pull)
- Repository validation and setup
Use simple-git library or child_process for git commands. Implement comprehensive error handling with specific error types for different git failures. Include retry logic for network operations.
## 2. Implement git start command [pending]
### Dependencies: None
### Description: Create the entry point for task-based git workflows with automated branch creation and task status updates
### Details:
Implement `scripts/modules/task-manager/git-start.js` with functionality to:
- Validate task exists and is ready to start
- Check for clean working directory
- Create branch with `task-{id}` naming
- Update task status to 'in-progress'
- Store workflow state in `.taskmaster/git-state.json`
- Handle existing branch scenarios
- Support --force flag for branch recreation
Integrate with existing task-master commands and ensure MCP compatibility.
## 3. Build intelligent commit analyzer and generator [pending]
### Dependencies: None
### Description: Create a system that analyzes file changes to auto-detect commit types and generate standardized commit messages
### Details:
Develop `scripts/modules/commit-analyzer.js` with:
- File change detection and categorization
- Commit type inference rules:
- feat: new files in scripts/, new functions
- fix: changes to existing logic
- test: changes in tests/ directory
- docs: markdown and comment changes
- refactor: file moves, renames, cleanup
- Smart message generation with task context
- Support for custom commit templates
- Subtask reference inclusion
Create `scripts/modules/task-manager/git-commit.js` that uses the analyzer to generate commits with proper formatting.
## 4. Create PR description generator and command [pending]
### Dependencies: None
### Description: Build a comprehensive PR description generator that creates detailed, formatted descriptions from task data
### Details:
Implement `scripts/modules/pr-description-generator.js` to generate:
- Task overview with full context
- Subtask completion checklist
- Implementation details summary
- Test coverage metrics integration
- Breaking changes section
- Related tasks and dependencies
Create `scripts/modules/task-manager/git-pr.js` to:
- Validate all subtasks are complete
- Generate PR title and description
- Use GitHub CLI for PR creation
- Handle draft PR scenarios
- Support custom PR templates
- Include labels based on task metadata
## 5. Implement git finish command with cleanup [pending]
### Dependencies: None
### Description: Create the workflow completion command that handles post-merge cleanup and task status updates
### Details:
Build `scripts/modules/task-manager/git-finish.js` with:
- PR merge verification via GitHub API
- Local branch cleanup
- Remote branch deletion (with confirmation)
- Task status update to 'done'
- Workflow state cleanup
- Switch back to main branch
- Pull latest changes
Handle scenarios where PR isn't merged yet or merge failed. Include --skip-cleanup flag for manual branch management.
## 6. Add git status command for workflow visibility [pending]
### Dependencies: None
### Description: Create a status command that shows current git workflow state with task context
### Details:
Implement `scripts/modules/task-manager/git-status.js` to display:
- Current task and branch information
- Subtask completion status
- Uncommitted changes summary
- PR status if exists
- Coverage metrics comparison
- Suggested next actions
Integrate with existing task status displays and provide actionable guidance based on workflow state.
## 7. Integrate with Commander.js and add command routing [pending]
### Dependencies: None
### Description: Add the git command suite to TaskMaster's CLI with proper help text and option handling
### Details:
Update `scripts/modules/commands.js` to:
- Add 'git' command with subcommands
- Implement option parsing for all git commands
- Add comprehensive help text
- Ensure proper error handling and display
- Validate command prerequisites
Create proper command structure:
- `task-master git start [taskId] [options]`
- `task-master git commit [options]`
- `task-master git pr [options]`
- `task-master git finish [options]`
- `task-master git status [options]`
## 8. Add MCP server integration for git commands [pending]
### Dependencies: None
### Description: Implement MCP tools and direct functions for git workflow commands to enable IDE integration
### Details:
Create MCP integration in:
- `mcp-server/src/core/direct-functions/git-start.js`
- `mcp-server/src/core/direct-functions/git-commit.js`
- `mcp-server/src/core/direct-functions/git-pr.js`
- `mcp-server/src/core/direct-functions/git-finish.js`
- `mcp-server/src/core/direct-functions/git-status.js`
- `mcp-server/src/tools/git-start.js`
- `mcp-server/src/tools/git-commit.js`
- `mcp-server/src/tools/git-pr.js`
- `mcp-server/src/tools/git-finish.js`
- `mcp-server/src/tools/git-status.js`
Implement tools for:
- git_start_task
- git_commit_task
- git_create_pr
- git_finish_task
- git_workflow_status
Ensure proper error handling, logging, and response formatting. Include telemetry data for git operations.
## 9. Create comprehensive test suite [pending]
### Dependencies: None
### Description: Implement full test coverage following Task 4's high standards with unit, integration, and E2E tests
### Details:
Create test files:
- `tests/unit/git/` - Unit tests for all git components
- `tests/integration/git-workflow.test.js` - Full workflow tests
- `tests/e2e/git-automation.test.js` - End-to-end scenarios
Implement:
- Git repository fixtures and mocks
- Coverage tracking and reporting
- Performance benchmarks
- Error scenario coverage
- Multi-developer workflow simulations
Target 95%+ coverage with focus on critical paths.
## 10. Add configuration and documentation [pending]
### Dependencies: None
### Description: Create configuration options and comprehensive documentation for the git workflow feature
### Details:
Configuration tasks:
- Add git workflow settings to `.taskmasterconfig`
- Support environment variables for GitHub tokens
- Create default PR and commit templates
- Add branch naming customization
Documentation tasks:
- Update README with git workflow section
- Create `docs/git-workflow.md` guide
- Add examples for common scenarios
- Document configuration options
- Create troubleshooting guide
Update rule files:
- Create `.cursor/rules/git_workflow.mdc`
- Update existing workflow rules

View File

@@ -1,292 +0,0 @@
# Task ID: 94
# Title: Implement Standalone 'research' CLI Command for AI-Powered Queries
# Status: in-progress
# Dependencies: 2, 4, 16
# Priority: medium
# Description: Develop a new 'task-master research' (alias 'tm research') CLI command for fast, context-aware AI research queries using the ai-services-unified.js infrastructure.
# Details:
- Add a new CLI command 'research' to commands.js, following established CLI patterns and conventions.
- Command should accept a research query as the main parameter, with optional flags for task IDs (--tasks), file paths (--files), custom context (--context), output detail level (--detail), and result saving (--save).
- Integrate with ai-services-unified.js, invoking its research mode to process the query and context, leveraging project file tree and task context as needed.
- Implement logic to gather and inject relevant context from specified tasks, files, or custom input, and generate a project file tree snapshot if required.
- Ensure output is formatted for terminal readability, including citations and references where available.
- Support saving research results to a specified file if --save is provided.
- Provide both brief and comprehensive output modes, controlled by a flag.
- Ensure the command is non-interactive (one-shot execution) and complements the existing 'explore' command.
- Update help documentation and usage examples for the new command.
# Test Strategy:
- Write unit and integration tests to verify correct parsing of command-line arguments and flags.
- Test that the command invokes ai-services-unified.js in research mode with the correct parameters and context.
- Validate that context from tasks, files, and custom input is correctly gathered and passed to the research engine.
- Confirm that output is properly formatted, includes citations, and is displayed in the terminal as expected.
- Test saving results to files and handling of file system errors.
- Ensure the command works in both brief and comprehensive modes.
- Verify that the command does not enter interactive mode and exits cleanly after execution.
- Check help output and usage documentation for accuracy and completeness.
# Subtasks:
## 1. Command Registration [done]
### Dependencies: None
### Description: Register the 'research' command with the CLI framework, ensuring it appears in the list of available commands and supports standard CLI conventions.
### Details:
Integrate the new command into the CLI's command registry. Ensure it is discoverable via the CLI's help system and follows established naming and grouping conventions.
## 2. Parameter and Flag Handling [done]
### Dependencies: 94.1
### Description: Define and implement parsing for all arguments, flags, and options accepted by the 'research' command, including validation and default values.
### Details:
Use a command-line parsing framework to handle parameters. Ensure support for optional and required arguments, order-independence, and clear error messages for invalid input.
<info added on 2025-05-25T06:00:42.350Z>
✅ **Parameter and Flag Handling Implementation Complete**
Successfully implemented comprehensive parameter validation and processing for the research command:
**✅ Implemented Features:**
1. **Comprehensive Parameter Validation:**
- Prompt validation (required, non-empty string)
- Detail level validation (low, medium, high)
- Task ID format validation (supports "15" and "15.2" formats)
- File path validation (comma-separated, existence checks)
- Save target validation (security checks for path traversal)
2. **Advanced Parameter Processing:**
- Comma-separated value parsing for task IDs and file paths
- Whitespace trimming and normalization
- Project root detection using `findProjectRoot()`
- Relative/absolute path handling for files
- Default value application
3. **Informative Error Messages:**
- Specific error messages for each validation failure
- Clear examples of correct usage
- Helpful suggestions for fixing errors
- Much more informative than basic Commander.js errors
4. **Structured Output:**
- Creates validated parameters object with all processed values
- Proper type conversion and normalization
- Ready for consumption by core research function
**✅ Validation Examples Tested:**
- Missing prompt: Shows Commander.js error (expected behavior)
- Invalid detail level: "Error: Detail level must be one of: low, medium, high"
- Invalid task ID format: "Error parsing task IDs: Invalid task ID format: "invalid_format". Expected format: "15" or "15.2""
- Valid parameters: Successfully processes and creates structured parameter object
**✅ Security Features:**
- Path traversal protection for save targets
- File existence validation
- Input sanitization and trimming
The parameter validation is now production-ready and follows the same patterns used throughout the Task Master codebase. Ready to proceed to subtask 94.3 (Context Gathering Utility).
</info added on 2025-05-25T06:00:42.350Z>
## 3. Context Gathering [done]
### Dependencies: 94.2
### Description: Implement logic to gather necessary context for the research operation, such as reading from files, stdin, or other sources as specified by the user.
### Details:
Support reading input from files or stdin using '-' as a convention. Validate and preprocess the gathered context to ensure it is suitable for AI processing.
<info added on 2025-05-25T05:24:58.107Z>
Create a comprehensive, reusable context gathering utility `utils/contextGatherer.js` that can be shared between the research command and explore REPL functionality.
**Core Features:**
**Task/Subtask Context Extraction:**
- Parse task IDs and subtask IDs (formats: "15", "15.2", "16,17.1")
- Extract task titles, descriptions, details, and dependencies from the task system
- Include parent task context automatically for subtasks
- Format task data optimally for AI consumption
**File Path Context Processing:**
- Handle single or comma-separated file paths
- Implement safe file reading with comprehensive error handling
- Support multiple file types (JavaScript, markdown, text, JSON, etc.)
- Include file metadata (path, size, type, last modified)
**Project File Tree Generation:**
- Create structured project overview with configurable depth
- Filter out irrelevant directories (.git, node_modules, .env files)
- Include file counts and directory statistics
- Support custom filtering patterns
**Custom Context Integration:**
- Accept and merge custom context strings
- Maintain clear context hierarchy and organization
- Preserve context source attribution
**Unified API Design:**
```javascript
const contextGatherer = new ContextGatherer(projectRoot);
const context = await contextGatherer.gather({
tasks: ["15", "16.2"],
files: ["src/main.js", "README.md"],
customContext: "Additional context...",
includeProjectTree: true,
format: "research" // or "chat", "system-prompt"
});
```
**Output Formatting:**
- Support multiple output formats (research, chat, system-prompt)
- Ensure consistent context structure across different use cases
- Optimize for AI model consumption and token efficiency
This utility will eliminate code duplication between task 51 (explore REPL) and task 94 (research command) while providing a robust, extensible foundation for context gathering operations.
</info added on 2025-05-25T05:24:58.107Z>
<info added on 2025-05-25T06:13:19.991Z>
✅ **Context Gathering Implementation Complete**
Successfully implemented the comprehensive ContextGatherer utility in `scripts/modules/utils/contextGatherer.js`:
**✅ Core Features Implemented:**
1. **Task/Subtask Context Extraction:**
- ✅ Parse task IDs and subtask IDs (formats: "15", "15.2", "16,17.1")
- ✅ Extract task titles, descriptions, details, and dependencies from the task system
- ✅ Include parent task context automatically for subtasks
- ✅ Format task data optimally for AI consumption
- ✅ Proper integration with existing `findTaskById` utility function
2. **File Path Context Processing:**
- ✅ Handle single or comma-separated file paths
- ✅ Implement safe file reading with comprehensive error handling
- ✅ Support multiple file types (JavaScript, markdown, text, JSON, etc.)
- ✅ Include file metadata (path, size, type, last modified)
- ✅ File size limits (50KB max) to prevent context explosion
3. **Project File Tree Generation:**
- ✅ Create structured project overview with configurable depth (max 3 levels)
- ✅ Filter out irrelevant directories (.git, node_modules, .env files)
- ✅ Include file counts and directory statistics
- ✅ Support custom filtering patterns
4. **Custom Context Integration:**
- ✅ Accept and merge custom context strings
- ✅ Maintain clear context hierarchy and organization
- ✅ Preserve context source attribution
5. **Unified API Design:**
- ✅ Clean class-based API with factory function
- ✅ Flexible options object for configuration
- ✅ Multiple output formats (research, chat, system-prompt)
- ✅ Proper error handling and graceful degradation
**✅ Output Formatting:**
- ✅ Support for 'research', 'chat', and 'system-prompt' formats
- ✅ Consistent context structure across different use cases
- ✅ Optimized for AI model consumption and token efficiency
**✅ Testing:**
- ✅ Successfully tested with real task data (Task 94 and subtask 94.1)
- ✅ Verified task context extraction works correctly
- ✅ Confirmed proper formatting and structure
**✅ Integration Ready:**
- ✅ Designed to be shared between task 51 (explore REPL) and task 94 (research command)
- ✅ Follows existing codebase patterns and utilities
- ✅ Proper ES6 module exports for easy importing
The ContextGatherer utility is now ready for integration into the core research function (subtask 94.4).
</info added on 2025-05-25T06:13:19.991Z>
## 4. Core Function Implementation [done]
### Dependencies: 94.2, 94.3
### Description: Implement the core research function in scripts/modules/task-manager/ following the add-task.js pattern
### Details:
Create a new core function (e.g., research.js) in scripts/modules/task-manager/ that:
- Accepts parameters: query, context options (task IDs, file paths, custom context), project tree flag, detail level
- Implements context gathering using the contextGatherer utility from subtask 94.3
- Integrates with ai-services-unified.js using research role
- Handles both CLI and MCP output formats
- Returns structured results with telemetry data
- Follows the same parameter validation and error handling patterns as add-task.js
<info added on 2025-05-25T06:29:01.194Z>
✅ COMPLETED: Added loading spinner to research command
**Implementation Details:**
- Imported `startLoadingIndicator` and `stopLoadingIndicator` from ui.js
- Added loading indicator that shows "Researching with AI..." during AI service calls
- Properly wrapped AI service call in try/catch/finally blocks to ensure spinner stops on both success and error
- Loading indicator only shows in CLI mode (outputFormat === 'text'), not in MCP mode
- Follows the same pattern as add-task.js for consistent user experience
**Testing:**
- Tested with `node bin/task-master.js research "What is TypeScript?" --detail=low`
- Confirmed spinner appears during AI processing and disappears when complete
- Telemetry display works correctly after spinner stops
The research command now provides the same polished user experience as other AI-powered commands in the system.
</info added on 2025-05-25T06:29:01.194Z>
## 5. Direct Function Implementation [pending]
### Dependencies: 94.4
### Description: Create the MCP direct function wrapper in mcp-server/src/core/direct-functions/ following the add-task pattern
### Details:
Create a new direct function (e.g., research.js) in mcp-server/src/core/direct-functions/ that:
- Follows the addTaskDirect pattern for parameter handling and error management
- Uses enableSilentMode/disableSilentMode to prevent console output interference
- Creates logger wrapper using createLogWrapper utility
- Validates required parameters (query, projectRoot)
- Calls the core research function with proper context (session, mcpLog, projectRoot)
- Returns standardized result object with success/error structure
- Handles telemetry data propagation
- Export and register in task-master-core.js
## 6. MCP Tool Implementation [pending]
### Dependencies: 94.5
### Description: Create the MCP tool in mcp-server/src/tools/ following the add-task tool pattern
### Details:
Create a new MCP tool (e.g., research.js) in mcp-server/src/tools/ that:
- Defines zod schema for all research command parameters (query, id, files, context, project-tree, save, detail)
- Uses withNormalizedProjectRoot HOF to handle project path normalization
- Calls findTasksJsonPath to locate tasks.json file
- Invokes the direct function with proper parameter mapping
- Uses handleApiResult for standardized response formatting
- Registers the tool as 'research' (snake_case) in the MCP server
- Handles errors with createErrorResponse
- Register in mcp-server/src/tools/index.js
- Update .cursor/mcp.json with tool definition
## 7. Add research save-to-file functionality [pending]
### Dependencies: None
### Description: Implement functionality to save research results to /research/ folder with optional interactive prompts
### Details:
Add capability to save research results to files in a /research/ directory at project root. For CLI mode, use inquirer to prompt user if they want to save the research. For MCP mode, accept a saveToFile parameter.
Key implementation details:
- Create /research/ directory if it doesn't exist (similar to how tasks/ is handled)
- Generate meaningful filenames based on query and timestamp
- Support both CLI interactive mode (inquirer prompts) and MCP parameter mode
- Follow project root detection pattern from add-task.js stack
- Handle file writing with proper error handling
- Return saved file path in response for confirmation
File structure:
- /research/YYYY-MM-DD_query-summary.md (markdown format)
- Include query, timestamp, context used, and full AI response
- Add metadata header with query details and context sources
## 8. Add research-to-task linking functionality [pending]
### Dependencies: 94.7
### Description: Implement functionality to link saved research to specific tasks with interactive task selection
### Details:
Add capability to link research results to specific tasks by updating task details with research references. For CLI mode, use inquirer to prompt user if they want to link research to tasks and provide task selection. For MCP mode, accept linkToTasks parameter.
Key implementation details:
- Prompt user if they want to link research to existing tasks (CLI mode)
- Provide task selection interface using inquirer with task list (ID, title, status)
- Support multiple task selection (checkbox interface)
- Update selected tasks' details section with research reference
- Add timestamped research link in format: "Research: [Query Title](file:///path/to/research.md) - YYYY-MM-DD"
- Follow add-task.js pattern for task file updates and regeneration
- Handle task.json reading/writing with proper error handling
- Support both single and multiple task linking
- Return list of updated task IDs in response
Research link format in task details:
```
## Research References
- [How to implement authentication](file:///research/2024-01-15_authentication-research.md) - 2024-01-15
```

View File

@@ -1,639 +0,0 @@
# Task ID: 95
# Title: Enhance Parse-PRD with Intelligent Task Expansion and Detail Preservation
# Status: pending
# Dependencies: None
# Priority: high
# Description: Transform parse-prd from a simple task generator into an intelligent system that preserves PRD detail resolution through context-aware task expansion. This addresses the critical issue where highly detailed PRDs lose their specificity when parsed into too few top-level tasks, and ensures that task expansions are grounded in actual PRD content rather than generic AI assumptions.
# Details:
## Core Problem Statement
The current parse-prd implementation suffers from a fundamental resolution loss problem:
1. **Detail Compression**: Complex, detailed PRDs get compressed into a fixed number of top-level tasks (default 10), losing critical specificity
2. **Orphaned Expansions**: When tasks are later expanded via expand-task, the AI lacks the original PRD context, resulting in generic subtasks that don't reflect the PRD's specific requirements
3. **Binary Approach**: The system either creates too few high-level tasks OR requires manual expansion that loses PRD context
## Solution Architecture
### Phase 1: Enhanced PRD Analysis Engine
- Implement intelligent PRD segmentation that identifies natural task boundaries based on content structure
- Create a PRD context preservation system that maintains detailed mappings between PRD sections and generated tasks
- Develop adaptive task count determination based on PRD complexity metrics (length, technical depth, feature count)
### Phase 2: Context-Aware Task Generation
- Modify generateTasksFromPRD to create tasks with embedded PRD context references
- Implement a PRD section mapping system that links each task to its source PRD content
- Add metadata fields to tasks that preserve original PRD language and specifications
### Phase 3: Intelligent In-Flight Expansion
- Add optional `--expand-tasks` flag to parse-prd that triggers immediate expansion after initial task generation
- Implement context-aware expansion that uses the original PRD content for each task's expansion
- Create a two-pass system: first pass generates tasks with PRD context, second pass expands using that context
### Phase 4: PRD-Grounded Expansion Logic
- Enhance the expansion prompt generation to include relevant PRD excerpts for each task being expanded
- Implement smart context windowing that includes related PRD sections when expanding tasks
- Add validation to ensure expanded subtasks maintain fidelity to original PRD specifications
## Technical Implementation Details
### File Modifications Required:
1. **scripts/modules/task-manager/parse-prd.js**
- Add PRD analysis functions for intelligent segmentation
- Implement context preservation during task generation
- Add optional expansion pipeline integration
- Create PRD-to-task mapping system
2. **scripts/modules/task-manager/expand-task.js**
- Enhance to accept PRD context as additional input
- Modify expansion prompts to include relevant PRD excerpts
- Add PRD-grounded validation for generated subtasks
3. **scripts/modules/ai-services-unified.js**
- Add support for context-aware prompting with PRD excerpts
- Implement intelligent context windowing for large PRDs
- Add PRD analysis capabilities for complexity assessment
### New Data Structures:
```javascript
// Enhanced task structure with PRD context
{
id: "1",
title: "User Authentication System",
description: "...",
prdContext: {
sourceSection: "Authentication Requirements (Lines 45-78)",
originalText: "The system must implement OAuth 2.0...",
relatedSections: ["Security Requirements", "User Management"],
contextWindow: "Full PRD excerpt relevant to this task"
},
// ... existing fields
}
// PRD analysis metadata
{
prdAnalysis: {
totalComplexity: 8.5,
naturalTaskBoundaries: [...],
recommendedTaskCount: 15,
sectionMappings: {...}
}
}
```
### New CLI Options:
- `--expand-tasks`: Automatically expand generated tasks using PRD context
- `--preserve-detail`: Maximum detail preservation mode
- `--adaptive-count`: Let AI determine optimal task count based on PRD complexity
- `--context-window-size`: Control how much PRD context to include in expansions
## Implementation Strategy
### Step 1: PRD Analysis Enhancement
- Create PRD parsing utilities that identify natural section boundaries
- Implement complexity scoring for different PRD sections
- Build context extraction functions that preserve relevant details
### Step 2: Context-Aware Task Generation
- Modify the task generation prompt to include section-specific context
- Implement task-to-PRD mapping during generation
- Add metadata fields to preserve PRD relationships
### Step 3: Intelligent Expansion Pipeline
- Create expansion logic that uses preserved PRD context
- Implement smart prompt engineering that includes relevant PRD excerpts
- Add validation to ensure subtask fidelity to original requirements
### Step 4: Integration and Testing
- Integrate new functionality with existing parse-prd workflow
- Add comprehensive testing with various PRD types and complexities
- Implement telemetry for tracking detail preservation effectiveness
## Success Metrics
- PRD detail preservation rate (measured by semantic similarity between PRD and generated tasks)
- Reduction in manual task refinement needed post-parsing
- Improved accuracy of expanded subtasks compared to PRD specifications
- User satisfaction with task granularity and detail accuracy
## Edge Cases and Considerations
- Very large PRDs that exceed context windows
- PRDs with conflicting or ambiguous requirements
- Integration with existing task expansion workflows
- Performance impact of enhanced analysis
- Backward compatibility with existing parse-prd usage
# Test Strategy:
# Subtasks:
## 1. Implement PRD Analysis and Segmentation Engine [pending]
### Dependencies: None
### Description: Create intelligent PRD parsing that identifies natural task boundaries and complexity metrics
### Details:
## Implementation Requirements
### Core Functions to Implement:
1. **analyzePRDStructure(prdContent)**
- Parse PRD into logical sections using headers, bullet points, and semantic breaks
- Identify feature boundaries, technical requirements, and implementation sections
- Return structured analysis with section metadata
2. **calculatePRDComplexity(prdContent)**
- Analyze technical depth, feature count, integration requirements
- Score complexity on 1-10 scale for different aspects
- Return recommended task count based on complexity
3. **extractTaskBoundaries(prdAnalysis)**
- Identify natural breaking points for task creation
- Group related requirements into logical task units
- Preserve context relationships between sections
### Technical Approach:
- Use regex patterns and NLP techniques to identify section headers
- Implement keyword analysis for technical complexity assessment
- Create semantic grouping algorithms for related requirements
- Build context preservation mappings
### Output Structure:
```javascript
{
sections: [
{
title: "User Authentication",
content: "...",
startLine: 45,
endLine: 78,
complexity: 7,
relatedSections: ["Security", "User Management"]
}
],
overallComplexity: 8.5,
recommendedTaskCount: 15,
naturalBoundaries: [...],
contextMappings: {...}
}
```
### Integration Points:
- Called at the beginning of parse-prd process
- Results used to inform task generation strategy
- Analysis stored for later use in expansion phase
## 2. Enhance Task Generation with PRD Context Preservation [pending]
### Dependencies: 95.1
### Description: Modify generateTasksFromPRD to embed PRD context and maintain source mappings
### Details:
## Implementation Requirements
### Core Modifications to generateTasksFromPRD:
1. **Add PRD Context Embedding**
- Modify task generation prompt to include relevant PRD excerpts
- Ensure each generated task includes source section references
- Preserve original PRD language and specifications in task metadata
2. **Implement Context Windowing**
- For large PRDs, implement intelligent context windowing
- Include relevant sections for each task being generated
- Maintain context relationships between related tasks
3. **Enhanced Task Structure**
- Add prdContext field to task objects
- Include sourceSection, originalText, and relatedSections
- Store contextWindow for later use in expansions
### Technical Implementation:
```javascript
// Enhanced task generation with context
const generateTaskWithContext = async (prdSection, relatedSections, fullPRD) => {
const contextWindow = buildContextWindow(prdSection, relatedSections, fullPRD);
const prompt = `
Generate a task based on this PRD section:
PRIMARY SECTION:
${prdSection.content}
RELATED CONTEXT:
${contextWindow}
Ensure the task preserves all specific requirements and technical details.
`;
// Generate task with embedded context
const task = await generateTask(prompt);
task.prdContext = {
sourceSection: prdSection.title,
originalText: prdSection.content,
relatedSections: relatedSections.map(s => s.title),
contextWindow: contextWindow
};
return task;
};
```
### Context Preservation Strategy:
- Map each task to its source PRD sections
- Preserve technical specifications and requirements language
- Maintain relationships between interdependent features
- Store context for later use in expansion phase
### Integration with Existing Flow:
- Modify existing generateTasksFromPRD function
- Maintain backward compatibility with simple PRDs
- Add new metadata fields without breaking existing structure
- Ensure context is available for subsequent operations
## 3. Implement In-Flight Task Expansion Pipeline [pending]
### Dependencies: 95.2
### Description: Add optional --expand-tasks flag and intelligent expansion using preserved PRD context
### Details:
## Implementation Requirements
### Core Features:
1. **Add --expand-tasks CLI Flag**
- Optional flag for parse-prd command
- Triggers automatic expansion after initial task generation
- Configurable expansion depth and strategy
2. **Two-Pass Processing System**
- First pass: Generate tasks with PRD context preservation
- Second pass: Expand tasks using their embedded PRD context
- Maintain context fidelity throughout the process
3. **Context-Aware Expansion Logic**
- Use preserved PRD context for each task's expansion
- Include relevant PRD excerpts in expansion prompts
- Ensure subtasks maintain fidelity to original specifications
### Technical Implementation:
```javascript
// Enhanced parse-prd with expansion pipeline
const parsePRDWithExpansion = async (prdContent, options) => {
// Phase 1: Analyze and generate tasks with context
const prdAnalysis = await analyzePRDStructure(prdContent);
const tasksWithContext = await generateTasksWithContext(prdAnalysis);
// Phase 2: Expand tasks if requested
if (options.expandTasks) {
for (const task of tasksWithContext) {
if (shouldExpandTask(task, prdAnalysis)) {
const expandedSubtasks = await expandTaskWithPRDContext(task);
task.subtasks = expandedSubtasks;
}
}
}
return tasksWithContext;
};
// Context-aware task expansion
const expandTaskWithPRDContext = async (task) => {
const { prdContext } = task;
const expansionPrompt = `
Expand this task into detailed subtasks using the original PRD context:
TASK: ${task.title}
DESCRIPTION: ${task.description}
ORIGINAL PRD CONTEXT:
${prdContext.originalText}
RELATED SECTIONS:
${prdContext.contextWindow}
Generate subtasks that preserve all technical details and requirements from the PRD.
`;
return await generateSubtasks(expansionPrompt);
};
```
### CLI Integration:
- Add --expand-tasks flag to parse-prd command
- Add --expansion-depth option for controlling subtask levels
- Add --preserve-detail flag for maximum context preservation
- Maintain backward compatibility with existing parse-prd usage
### Expansion Strategy:
- Determine which tasks should be expanded based on complexity
- Use PRD context to generate accurate, detailed subtasks
- Preserve technical specifications and implementation details
- Validate subtask accuracy against original PRD content
### Performance Considerations:
- Implement batching for large numbers of tasks
- Add progress indicators for long-running expansions
- Optimize context window sizes for efficiency
- Cache PRD analysis results for reuse
## 4. Enhance Expand-Task with PRD Context Integration [pending]
### Dependencies: 95.2
### Description: Modify existing expand-task functionality to leverage preserved PRD context for more accurate expansions
### Details:
## Implementation Requirements
### Core Enhancements to expand-task.js:
1. **PRD Context Detection**
- Check if task has embedded prdContext metadata
- Extract relevant PRD sections for expansion
- Fall back to existing expansion logic if no PRD context
2. **Context-Enhanced Expansion Prompts**
- Include original PRD excerpts in expansion prompts
- Add related section context for comprehensive understanding
- Preserve technical specifications and requirements language
3. **Validation and Quality Assurance**
- Validate generated subtasks against original PRD content
- Ensure technical accuracy and requirement compliance
- Flag potential discrepancies for review
### Technical Implementation:
```javascript
// Enhanced expand-task with PRD context
const expandTaskWithContext = async (taskId, options, context) => {
const task = await getTask(taskId);
// Check for PRD context
if (task.prdContext) {
return await expandWithPRDContext(task, options);
} else {
// Fall back to existing expansion logic
return await expandTaskStandard(task, options);
}
};
const expandWithPRDContext = async (task, options) => {
const { prdContext } = task;
const enhancedPrompt = `
Expand this task into detailed subtasks using the original PRD context:
TASK DETAILS:
Title: ${task.title}
Description: ${task.description}
Current Details: ${task.details}
ORIGINAL PRD CONTEXT:
Source Section: ${prdContext.sourceSection}
Original Requirements:
${prdContext.originalText}
RELATED CONTEXT:
${prdContext.contextWindow}
EXPANSION REQUIREMENTS:
- Preserve all technical specifications from the PRD
- Maintain requirement accuracy and completeness
- Generate ${options.num || 'appropriate number of'} subtasks
- Include implementation details that reflect PRD specifics
Generate subtasks that are grounded in the original PRD content.
`;
const subtasks = await generateSubtasks(enhancedPrompt, options);
// Add PRD context inheritance to subtasks
subtasks.forEach(subtask => {
subtask.prdContext = {
inheritedFrom: task.id,
sourceSection: prdContext.sourceSection,
relevantExcerpt: extractRelevantExcerpt(prdContext, subtask)
};
});
return subtasks;
};
```
### Integration Points:
1. **Modify existing expand-task.js**
- Add PRD context detection logic
- Enhance prompt generation with context
- Maintain backward compatibility
2. **Update expansion validation**
- Add PRD compliance checking
- Implement quality scoring for context fidelity
- Flag potential accuracy issues
3. **CLI and MCP Integration**
- Update expand-task command to leverage PRD context
- Add options for context-aware expansion
- Maintain existing command interface
### Context Inheritance Strategy:
- Pass relevant PRD context to generated subtasks
- Create context inheritance chain for nested expansions
- Preserve source traceability throughout expansion tree
- Enable future re-expansion with maintained context
### Quality Assurance Features:
- Semantic similarity checking between subtasks and PRD
- Technical requirement compliance validation
- Automated flagging of potential context drift
- User feedback integration for continuous improvement
## 5. Add New CLI Options and MCP Parameters [pending]
### Dependencies: 95.3
### Description: Implement new command-line flags and MCP tool parameters for enhanced PRD parsing
### Details:
## Implementation Requirements
### New CLI Options for parse-prd:
1. **--expand-tasks**
- Automatically expand generated tasks using PRD context
- Boolean flag, default false
- Triggers in-flight expansion pipeline
2. **--preserve-detail**
- Maximum detail preservation mode
- Boolean flag, default false
- Ensures highest fidelity to PRD content
3. **--adaptive-count**
- Let AI determine optimal task count based on PRD complexity
- Boolean flag, default false
- Overrides --num-tasks when enabled
4. **--context-window-size**
- Control how much PRD context to include in expansions
- Integer value, default 2000 characters
- Balances context richness with performance
5. **--expansion-depth**
- Control how many levels deep to expand tasks
- Integer value, default 1
- Prevents excessive nesting
### MCP Tool Parameter Updates:
```javascript
// Enhanced parse_prd MCP tool parameters
{
input: "Path to PRD file",
output: "Output path for tasks.json",
numTasks: "Number of top-level tasks (overridden by adaptiveCount)",
expandTasks: "Boolean - automatically expand tasks with PRD context",
preserveDetail: "Boolean - maximum detail preservation mode",
adaptiveCount: "Boolean - AI determines optimal task count",
contextWindowSize: "Integer - context size for expansions",
expansionDepth: "Integer - levels of expansion to perform",
research: "Boolean - use research model for enhanced analysis",
force: "Boolean - overwrite existing files"
}
```
### CLI Command Updates:
```bash
# Enhanced parse-prd command examples
task-master parse-prd prd.txt --expand-tasks --preserve-detail
task-master parse-prd prd.txt --adaptive-count --expansion-depth=2
task-master parse-prd prd.txt --context-window-size=3000 --research
```
### Implementation Details:
1. **Update commands.js**
- Add new option definitions
- Update parse-prd command handler
- Maintain backward compatibility
2. **Update MCP tool definition**
- Add new parameter schemas
- Update tool description and examples
- Ensure parameter validation
3. **Parameter Processing Logic**
- Validate parameter combinations
- Set appropriate defaults
- Handle conflicting options gracefully
### Validation Rules:
- expansion-depth must be positive integer ≤ 3
- context-window-size must be between 500-5000 characters
- adaptive-count overrides num-tasks when both specified
- expand-tasks requires either adaptive-count or num-tasks > 5
### Help Documentation Updates:
- Update command help text with new options
- Add usage examples for different scenarios
- Document parameter interactions and constraints
- Include performance considerations for large PRDs
## 6. Implement Comprehensive Testing and Validation [pending]
### Dependencies: 95.4, 95.5
### Description: Create test suite for PRD analysis, context preservation, and expansion accuracy
### Details:
## Implementation Requirements
### Test Categories:
1. **PRD Analysis Testing**
- Test section identification with various PRD formats
- Validate complexity scoring accuracy
- Test boundary detection for different document structures
- Verify context mapping correctness
2. **Context Preservation Testing**
- Validate PRD context embedding in generated tasks
- Test context window generation and sizing
- Verify source section mapping accuracy
- Test context inheritance in subtasks
3. **Expansion Accuracy Testing**
- Compare PRD-grounded vs standard expansions
- Measure semantic similarity between PRD and subtasks
- Test technical requirement preservation
- Validate expansion depth and quality
4. **Integration Testing**
- Test full parse-prd pipeline with expansion
- Validate CLI option combinations
- Test MCP tool parameter handling
- Verify backward compatibility
### Test Data Requirements:
```javascript
// Test PRD samples
const testPRDs = {
simple: "Basic PRD with minimal technical details",
complex: "Detailed PRD with extensive technical specifications",
structured: "Well-organized PRD with clear sections",
unstructured: "Free-form PRD with mixed content",
technical: "Highly technical PRD with specific requirements",
large: "Very large PRD testing context window limits"
};
```
### Validation Metrics:
1. **Detail Preservation Score**
- Semantic similarity between PRD and generated tasks
- Technical requirement coverage percentage
- Specification accuracy rating
2. **Context Fidelity Score**
- Accuracy of source section mapping
- Relevance of included context windows
- Quality of context inheritance
3. **Expansion Quality Score**
- Subtask relevance to parent task and PRD
- Technical accuracy of implementation details
- Completeness of requirement coverage
### Test Implementation:
```javascript
// Example test structure
describe('Enhanced Parse-PRD', () => {
describe('PRD Analysis', () => {
test('should identify sections correctly', async () => {
const analysis = await analyzePRDStructure(testPRDs.structured);
expect(analysis.sections).toHaveLength(expectedSectionCount);
expect(analysis.overallComplexity).toBeGreaterThan(0);
});
test('should calculate appropriate task count', async () => {
const analysis = await analyzePRDStructure(testPRDs.complex);
expect(analysis.recommendedTaskCount).toBeGreaterThan(10);
});
});
describe('Context Preservation', () => {
test('should embed PRD context in tasks', async () => {
const tasks = await generateTasksWithContext(testPRDs.technical);
tasks.forEach(task => {
expect(task.prdContext).toBeDefined();
expect(task.prdContext.sourceSection).toBeTruthy();
expect(task.prdContext.originalText).toBeTruthy();
});
});
});
describe('Expansion Accuracy', () => {
test('should generate relevant subtasks from PRD context', async () => {
const task = createTestTaskWithPRDContext();
const subtasks = await expandTaskWithPRDContext(task);
const relevanceScore = calculateRelevanceScore(subtasks, task.prdContext);
expect(relevanceScore).toBeGreaterThan(0.8);
});
});
});
```
### Performance Testing:
- Test with large PRDs (>10,000 words)
- Measure processing time for different complexity levels
- Test memory usage with extensive context preservation
- Validate timeout handling for long-running operations
### Quality Assurance Tools:
- Automated semantic similarity checking
- Technical requirement compliance validation
- Context drift detection algorithms
- User acceptance testing framework
### Continuous Integration:
- Add tests to existing CI pipeline
- Set up performance benchmarking
- Implement quality gates for PRD processing
- Create regression testing for context preservation

File diff suppressed because it is too large Load Diff

61
tasks/task_098.txt Normal file
View File

@@ -0,0 +1,61 @@
# Task ID: 98
# Title: Implement Separate Context Window and Output Token Limits
# Status: pending
# Dependencies: None
# Priority: high
# Description: Replace the ambiguous MAX_TOKENS configuration with separate contextWindowTokens and maxOutputTokens fields to properly handle model token limits and enable dynamic token allocation.
# Details:
Currently, the MAX_TOKENS configuration entry is ambiguous and doesn't properly differentiate between:
1. Context window tokens (total input + output capacity)
2. Maximum output tokens (generation limit)
This causes issues where:
- The system can't properly validate prompt lengths against model capabilities
- Output token allocation is not optimized based on input length
- Different models with different token architectures are handled inconsistently
This epic will implement a comprehensive solution that:
- Updates supported-models.json with accurate contextWindowTokens and maxOutputTokens for each model
- Modifies config-manager.js to use separate maxInputTokens and maxOutputTokens in role configurations
- Implements a token counting utility for accurate prompt measurement
- Updates ai-services-unified.js to dynamically calculate available output tokens
- Provides migration guidance and validation for existing configurations
- Adds comprehensive error handling and validation throughout the system
The end result will be more precise token management, better cost control, and reduced likelihood of hitting model context limits.
# Test Strategy:
1. Verify all models have accurate token limit data from official documentation
2. Test dynamic token allocation with various prompt lengths
3. Ensure backward compatibility with existing .taskmasterconfig files
4. Validate error messages are clear and actionable
5. Test with multiple AI providers to ensure consistent behavior
6. Performance test token counting utility with large prompts
# Subtasks:
## 1. Update supported-models.json with token limit fields [pending]
### Dependencies: None
### Description: Modify the supported-models.json file to include contextWindowTokens and maxOutputTokens fields for each model, replacing the ambiguous max_tokens field.
### Details:
For each model entry in supported-models.json:
1. Add `contextWindowTokens` field representing the total context window (input + output tokens)
2. Add `maxOutputTokens` field representing the maximum tokens the model can generate
3. Remove or deprecate the ambiguous `max_tokens` field if present
Research and populate accurate values for each model from official documentation:
- For OpenAI models (e.g., gpt-4o): contextWindowTokens=128000, maxOutputTokens=16384
- For Anthropic models (e.g., Claude 3.7): contextWindowTokens=200000, maxOutputTokens=8192
- For other providers, find official documentation or use reasonable defaults
Example entry:
```json
{
"id": "claude-3-7-sonnet-20250219",
"swe_score": 0.623,
"cost_per_1m_tokens": { "input": 3.0, "output": 15.0 },
"allowed_roles": ["main", "fallback"],
"contextWindowTokens": 200000,
"maxOutputTokens": 8192
}
```

File diff suppressed because one or more lines are too long