Compare commits
41 Commits
chore/crea
...
gateway
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
16e6326010 | ||
|
|
a9c1b6bbcf | ||
|
|
f12fc476d3 | ||
|
|
31178e2f43 | ||
|
|
3fa3be4e1b | ||
|
|
685365270d | ||
|
|
58aa0992f6 | ||
|
|
2819be51d3 | ||
|
|
9b87dd23de | ||
|
|
769275b3bc | ||
|
|
4e9d58a1b0 | ||
|
|
e573db3b3b | ||
|
|
75b7b93fa4 | ||
|
|
6ec3a10083 | ||
|
|
8ad31ac5eb | ||
|
|
2773e347f9 | ||
|
|
bfc39dd377 | ||
|
|
9e6c190af3 | ||
|
|
ab64437ad2 | ||
|
|
cb95a07771 | ||
|
|
c096f3fe9d | ||
|
|
b6a3b8d385 | ||
|
|
78397fe0be | ||
|
|
f9b89dc25c | ||
|
|
ca69e1294f | ||
|
|
ce09d9cdc3 | ||
|
|
b5c2cf47b0 | ||
|
|
ac36e2497e | ||
|
|
1d4b80fe6f | ||
|
|
023f51c579 | ||
|
|
1e020023ed | ||
|
|
325f5a2aa3 | ||
|
|
de46bfd84b | ||
|
|
cc26c36366 | ||
|
|
15ad34928d | ||
|
|
f74d639110 | ||
|
|
de58e9ede5 | ||
|
|
947541e4ee | ||
|
|
275cd55da7 | ||
|
|
67ac212973 | ||
|
|
235371ff47 |
44
.changeset/bright-windows-sing.md
Normal file
44
.changeset/bright-windows-sing.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
'task-master-ai': minor
|
||||
---
|
||||
|
||||
Add comprehensive AI-powered research command with intelligent context gathering and interactive follow-ups.
|
||||
|
||||
The new `research` command provides AI-powered research capabilities that automatically gather relevant project context to answer your questions. The command intelligently selects context from multiple sources and supports interactive follow-up questions in CLI mode.
|
||||
|
||||
**Key Features:**
|
||||
- **Intelligent Task Discovery**: Automatically finds relevant tasks and subtasks using fuzzy search based on your query keywords, supplementing any explicitly provided task IDs
|
||||
- **Multi-Source Context**: Gathers context from tasks, files, project structure, and custom text to provide comprehensive answers
|
||||
- **Interactive Follow-ups**: CLI users can ask follow-up questions that build on the conversation history while allowing fresh context discovery for each question
|
||||
- **Flexible Detail Levels**: Choose from low (concise), medium (balanced), or high (comprehensive) response detail levels
|
||||
- **Token Transparency**: Displays detailed token breakdown showing context size, sources, and estimated costs
|
||||
- **Enhanced Display**: Syntax-highlighted code blocks and structured output with clear visual separation
|
||||
|
||||
**Usage Examples:**
|
||||
```bash
|
||||
# Basic research with auto-discovered context
|
||||
task-master research "How should I implement user authentication?"
|
||||
|
||||
# Research with specific task context
|
||||
task-master research "What's the best approach for this?" --id=15,23.2
|
||||
|
||||
# Research with file context and project tree
|
||||
task-master research "How does the current auth system work?" --files=src/auth.js,config/auth.json --tree
|
||||
|
||||
# Research with custom context and low detail
|
||||
task-master research "Quick implementation steps?" --context="Using JWT tokens" --detail=low
|
||||
```
|
||||
|
||||
**Context Sources:**
|
||||
- **Tasks**: Automatically discovers relevant tasks/subtasks via fuzzy search, plus any explicitly specified via `--id`
|
||||
- **Files**: Include specific files via `--files` for code-aware responses
|
||||
- **Project Tree**: Add `--tree` to include project structure overview
|
||||
- **Custom Context**: Provide additional context via `--context` for domain-specific information
|
||||
|
||||
**Interactive Features (CLI only):**
|
||||
- Follow-up questions that maintain conversation history
|
||||
- Fresh fuzzy search for each follow-up to discover newly relevant tasks
|
||||
- Cumulative context building across the conversation
|
||||
- Clean visual separation between exchanges
|
||||
|
||||
The research command integrates with the existing AI service layer and supports all configured AI providers. MCP integration provides the same functionality for programmatic access without interactive features.
|
||||
13
.changeset/cold-pears-poke.md
Normal file
13
.changeset/cold-pears-poke.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
'task-master-ai': patch
|
||||
---
|
||||
|
||||
Fix critical bugs in task move functionality:
|
||||
|
||||
- **Fixed moving tasks to become subtasks of empty parents**: When moving a task to become a subtask of a parent that had no existing subtasks (e.g., task 89 → task 98.1), the operation would fail with validation errors.
|
||||
|
||||
- **Fixed moving subtasks between parents**: Subtasks can now be properly moved between different parent tasks, including to parents that previously had no subtasks.
|
||||
|
||||
- **Improved comma-separated batch moves**: Multiple tasks can now be moved simultaneously using comma-separated IDs (e.g., "88,90" → "92,93") with proper error handling and atomic operations.
|
||||
|
||||
These fixes enables proper task hierarchy reorganization for corner cases that were previously broken.
|
||||
17
.changeset/moody-results-clean.md
Normal file
17
.changeset/moody-results-clean.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
'task-master-ai': minor
|
||||
---
|
||||
|
||||
Add comprehensive `research` MCP tool for AI-powered research queries
|
||||
|
||||
- **New MCP Tool**: `research` tool enables AI-powered research with project context
|
||||
- **Context Integration**: Supports task IDs, file paths, custom context, and project tree
|
||||
- **Fuzzy Task Discovery**: Automatically finds relevant tasks using semantic search
|
||||
- **Token Management**: Detailed token counting and breakdown by context type
|
||||
- **Multiple Detail Levels**: Support for low, medium, and high detail research responses
|
||||
- **Telemetry Integration**: Full cost tracking and usage analytics
|
||||
- **Direct Function**: `researchDirect` with comprehensive parameter validation
|
||||
- **Silent Mode**: Prevents console output interference with MCP JSON responses
|
||||
- **Error Handling**: Robust error handling with proper MCP response formatting
|
||||
|
||||
This completes subtasks 94.5 (Direct Function) and 94.6 (MCP Tool) for the research command implementation, providing a powerful research interface for integrated development environments like Cursor.
|
||||
19
.changeset/stale-bats-sin.md
Normal file
19
.changeset/stale-bats-sin.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
'task-master-ai': minor
|
||||
---
|
||||
|
||||
Enhanced get-task/show command to support comma-separated task IDs for efficient batch operations
|
||||
|
||||
**New Features:**
|
||||
- **Multiple Task Retrieval**: Pass comma-separated IDs to get/show multiple tasks at once (e.g., `task-master show 1,3,5` or MCP `get_task` with `id: "1,3,5"`)
|
||||
- **Smart Display Logic**: Single ID shows detailed view, multiple IDs show compact summary table with interactive options
|
||||
- **Batch Action Menu**: Interactive menu for multiple tasks with copy-paste ready commands for common operations (mark as done/in-progress, expand all, view dependencies, etc.)
|
||||
- **MCP Array Response**: MCP tool returns structured array of task objects for efficient AI agent context gathering
|
||||
|
||||
**Benefits:**
|
||||
- **Faster Context Gathering**: AI agents can collect multiple tasks/subtasks in one call instead of iterating
|
||||
- **Improved Workflow**: Interactive batch operations reduce repetitive command execution
|
||||
- **Better UX**: Responsive layout adapts to terminal width, maintains consistency with existing UI patterns
|
||||
- **API Efficiency**: RESTful array responses in MCP format enable more sophisticated integrations
|
||||
|
||||
This enhancement maintains full backward compatibility while significantly improving efficiency for both human users and AI agents working with multiple tasks.
|
||||
@@ -1,19 +1,44 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"task-master-ai": {
|
||||
"command": "node",
|
||||
"args": ["./mcp-server/server.js"],
|
||||
"env": {
|
||||
"ANTHROPIC_API_KEY": "ANTHROPIC_API_KEY_HERE",
|
||||
"PERPLEXITY_API_KEY": "PERPLEXITY_API_KEY_HERE",
|
||||
"OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
|
||||
"GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
|
||||
"XAI_API_KEY": "XAI_API_KEY_HERE",
|
||||
"OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE",
|
||||
"MISTRAL_API_KEY": "MISTRAL_API_KEY_HERE",
|
||||
"AZURE_OPENAI_API_KEY": "AZURE_OPENAI_API_KEY_HERE",
|
||||
"OLLAMA_API_KEY": "OLLAMA_API_KEY_HERE"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"mcpServers": {
|
||||
"task-master-ai-tm": {
|
||||
"command": "node",
|
||||
"args": [
|
||||
"./mcp-server/server.js"
|
||||
],
|
||||
"env": {
|
||||
"ANTHROPIC_API_KEY": "ANTHROPIC_API_KEY_HERE",
|
||||
"PERPLEXITY_API_KEY": "PERPLEXITY_API_KEY_HERE",
|
||||
"OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
|
||||
"GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
|
||||
"XAI_API_KEY": "XAI_API_KEY_HERE",
|
||||
"OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE",
|
||||
"MISTRAL_API_KEY": "MISTRAL_API_KEY_HERE",
|
||||
"AZURE_OPENAI_API_KEY": "AZURE_OPENAI_API_KEY_HERE",
|
||||
"OLLAMA_API_KEY": "OLLAMA_API_KEY_HERE"
|
||||
}
|
||||
},
|
||||
"task-master-ai": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"--package=task-master-ai",
|
||||
"task-master-ai"
|
||||
],
|
||||
"env": {
|
||||
"ANTHROPIC_API_KEY": "ANTHROPIC_API_KEY_HERE",
|
||||
"PERPLEXITY_API_KEY": "PERPLEXITY_API_KEY_HERE",
|
||||
"OPENAI_API_KEY": "OPENAI_API_KEY_HERE",
|
||||
"GOOGLE_API_KEY": "GOOGLE_API_KEY_HERE",
|
||||
"XAI_API_KEY": "XAI_API_KEY_HERE",
|
||||
"OPENROUTER_API_KEY": "OPENROUTER_API_KEY_HERE",
|
||||
"MISTRAL_API_KEY": "MISTRAL_API_KEY_HERE",
|
||||
"AZURE_OPENAI_API_KEY": "AZURE_OPENAI_API_KEY_HERE",
|
||||
"OLLAMA_API_KEY": "OLLAMA_API_KEY_HERE"
|
||||
}
|
||||
}
|
||||
},
|
||||
"env": {
|
||||
"TASKMASTER_TELEMETRY_API_KEY": "339a81c9-5b9c-4d60-92d8-cba2ee2a8cc3",
|
||||
"TASKMASTER_TELEMETRY_USER_EMAIL": "user_1748640077834@taskmaster.dev"
|
||||
}
|
||||
}
|
||||
@@ -50,6 +50,7 @@ This rule guides AI assistants on how to view, configure, and interact with the
|
||||
- **Key Locations** (See [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc) - Configuration Management):
|
||||
- **MCP/Cursor:** Set keys in the `env` section of `.cursor/mcp.json`.
|
||||
- **CLI:** Set keys in a `.env` file in the project root.
|
||||
- As the AI agent, you do not have access to read the .env -- but do not attempt to recreate it!
|
||||
- **Provider List & Keys:**
|
||||
- **`anthropic`**: Requires `ANTHROPIC_API_KEY`.
|
||||
- **`google`**: Requires `GOOGLE_API_KEY`.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
description: Guidelines for interacting with the unified AI service layer.
|
||||
globs: scripts/modules/ai-services-unified.js, scripts/modules/task-manager/*.js, scripts/modules/commands.js
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# AI Services Layer Guidelines
|
||||
@@ -91,7 +92,7 @@ This document outlines the architecture and usage patterns for interacting with
|
||||
* ✅ **DO**: Centralize **all** LLM calls through `generateTextService` or `generateObjectService`.
|
||||
* ✅ **DO**: Determine the appropriate `role` (`main`, `research`, `fallback`) in your core logic and pass it to the service.
|
||||
* ✅ **DO**: Pass the `session` object (received in the `context` parameter, especially from direct function wrappers) to the service call when in MCP context.
|
||||
* ✅ **DO**: Ensure API keys are correctly configured in `.env` (for CLI) or `.cursor/mcp.json` (for MCP).
|
||||
* ✅ **DO**: Ensure API keys are correctly configured in `.env` (for CLI) or `.cursor/mcp.json` (for MCP). FYI: As the AI agent, you do not have access to read the .env -- so do not attempt to recreate it!
|
||||
* ✅ **DO**: Ensure `.taskmasterconfig` exists and has valid provider/model IDs for the roles you intend to use (manage via `task-master models --setup`).
|
||||
* ✅ **DO**: Use `generateTextService` and implement robust manual JSON parsing (with Zod validation *after* parsing) when structured output is needed, as `generateObjectService` has shown unreliability with some providers/schemas.
|
||||
* ❌ **DON'T**: Import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
|
||||
|
||||
@@ -39,12 +39,12 @@ alwaysApply: false
|
||||
- **Responsibilities** (See also: [`ai_services.mdc`](mdc:.cursor/rules/ai_services.mdc)):
|
||||
- Exports `generateTextService`, `generateObjectService`.
|
||||
- Handles provider/model selection based on `role` and `.taskmasterconfig`.
|
||||
- Resolves API keys (from `.env` or `session.env`).
|
||||
- Resolves API keys (from `.env` or `session.env`). As the AI agent, you do not have access to read the .env -- but do not attempt to recreate it!
|
||||
- Implements fallback and retry logic.
|
||||
- Orchestrates calls to provider-specific implementations (`src/ai-providers/`).
|
||||
- Telemetry data generated by the AI service layer is propagated upwards through core logic, direct functions, and MCP tools. See [`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc) for the detailed integration pattern.
|
||||
|
||||
- **[`src/ai-providers/*.js`](mdc:src/ai-providers/): Provider-Specific Implementations**
|
||||
- **[`src/ai-providers/*.js`](mdc:src/ai-providers): Provider-Specific Implementations**
|
||||
- **Purpose**: Provider-specific wrappers for Vercel AI SDK functions.
|
||||
- **Responsibilities**: Interact directly with Vercel AI SDK adapters.
|
||||
|
||||
@@ -63,7 +63,7 @@ alwaysApply: false
|
||||
- API Key Resolution (`resolveEnvVariable`).
|
||||
- Silent Mode Control (`enableSilentMode`, `disableSilentMode`).
|
||||
|
||||
- **[`mcp-server/`](mdc:mcp-server/): MCP Server Integration**
|
||||
- **[`mcp-server/`](mdc:mcp-server): MCP Server Integration**
|
||||
- **Purpose**: Provides MCP interface using FastMCP.
|
||||
- **Responsibilities** (See also: [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)):
|
||||
- Registers tools (`mcp-server/src/tools/*.js`). Tool `execute` methods **should be wrapped** with the `withNormalizedProjectRoot` HOF (from `tools/utils.js`) to ensure consistent path handling.
|
||||
|
||||
@@ -329,6 +329,60 @@ When implementing commands that delete or remove data (like `remove-task` or `re
|
||||
};
|
||||
```
|
||||
|
||||
## Context-Aware Command Pattern
|
||||
|
||||
For AI-powered commands that benefit from project context, follow the research command pattern:
|
||||
|
||||
- **Context Integration**:
|
||||
- ✅ DO: Use `ContextGatherer` utility for multi-source context extraction
|
||||
- ✅ DO: Support task IDs, file paths, custom context, and project tree
|
||||
- ✅ DO: Implement fuzzy search for automatic task discovery
|
||||
- ✅ DO: Display detailed token breakdown for transparency
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Follow this pattern for context-aware commands
|
||||
programInstance
|
||||
.command('research')
|
||||
.description('Perform AI-powered research queries with project context')
|
||||
.argument('<prompt>', 'Research prompt to investigate')
|
||||
.option('-i, --id <ids>', 'Comma-separated task/subtask IDs to include as context')
|
||||
.option('-f, --files <paths>', 'Comma-separated file paths to include as context')
|
||||
.option('-c, --context <text>', 'Additional custom context')
|
||||
.option('--tree', 'Include project file tree structure')
|
||||
.option('-d, --detail <level>', 'Output detail level: low, medium, high', 'medium')
|
||||
.action(async (prompt, options) => {
|
||||
// 1. Parameter validation and parsing
|
||||
const taskIds = options.id ? parseTaskIds(options.id) : [];
|
||||
const filePaths = options.files ? parseFilePaths(options.files) : [];
|
||||
|
||||
// 2. Initialize context gatherer
|
||||
const projectRoot = findProjectRoot() || '.';
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// 3. Auto-discover relevant tasks if none specified
|
||||
if (taskIds.length === 0) {
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const discoveredIds = fuzzySearch.getTaskIds(
|
||||
fuzzySearch.findRelevantTasks(prompt)
|
||||
);
|
||||
taskIds.push(...discoveredIds);
|
||||
}
|
||||
|
||||
// 4. Gather context with token breakdown
|
||||
const contextResult = await gatherer.gather({
|
||||
tasks: taskIds,
|
||||
files: filePaths,
|
||||
customContext: options.context,
|
||||
includeProjectTree: options.projectTree,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
|
||||
// 5. Display token breakdown and execute AI call
|
||||
// Implementation continues...
|
||||
});
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- **Exception Management**:
|
||||
|
||||
268
.cursor/rules/context_gathering.mdc
Normal file
268
.cursor/rules/context_gathering.mdc
Normal file
@@ -0,0 +1,268 @@
|
||||
---
|
||||
description: Standardized patterns for gathering and processing context from multiple sources in Task Master commands, particularly for AI-powered features.
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
# Context Gathering Patterns and Utilities
|
||||
|
||||
This document outlines the standardized patterns for gathering and processing context from multiple sources in Task Master commands, particularly for AI-powered features.
|
||||
|
||||
## Core Context Gathering Utility
|
||||
|
||||
The `ContextGatherer` class (`scripts/modules/utils/contextGatherer.js`) provides a centralized, reusable utility for extracting context from multiple sources:
|
||||
|
||||
### **Key Features**
|
||||
- **Multi-source Context**: Tasks, files, custom text, project file tree
|
||||
- **Token Counting**: Detailed breakdown using `gpt-tokens` library
|
||||
- **Format Support**: Different output formats (research, chat, system-prompt)
|
||||
- **Error Handling**: Graceful handling of missing files, invalid task IDs
|
||||
- **Performance**: File size limits, depth limits for tree generation
|
||||
|
||||
### **Usage Pattern**
|
||||
```javascript
|
||||
import { ContextGatherer } from '../utils/contextGatherer.js';
|
||||
|
||||
// Initialize with project paths
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// Gather context with detailed token breakdown
|
||||
const result = await gatherer.gather({
|
||||
tasks: ['15', '16.2'], // Task and subtask IDs
|
||||
files: ['src/api.js', 'README.md'], // File paths
|
||||
customContext: 'Additional context text',
|
||||
includeProjectTree: true, // Include file tree
|
||||
format: 'research', // Output format
|
||||
includeTokenCounts: true // Get detailed token breakdown
|
||||
});
|
||||
|
||||
// Access results
|
||||
const contextString = result.context;
|
||||
const tokenBreakdown = result.tokenBreakdown;
|
||||
```
|
||||
|
||||
### **Token Breakdown Structure**
|
||||
```javascript
|
||||
{
|
||||
customContext: { tokens: 150, characters: 800 },
|
||||
tasks: [
|
||||
{ id: '15', type: 'task', title: 'Task Title', tokens: 245, characters: 1200 },
|
||||
{ id: '16.2', type: 'subtask', title: 'Subtask Title', tokens: 180, characters: 900 }
|
||||
],
|
||||
files: [
|
||||
{ path: 'src/api.js', tokens: 890, characters: 4500, size: '4.5 KB' }
|
||||
],
|
||||
projectTree: { tokens: 320, characters: 1600 },
|
||||
total: { tokens: 1785, characters: 8000 }
|
||||
}
|
||||
```
|
||||
|
||||
## Fuzzy Search Integration
|
||||
|
||||
The `FuzzyTaskSearch` class (`scripts/modules/utils/fuzzyTaskSearch.js`) provides intelligent task discovery:
|
||||
|
||||
### **Key Features**
|
||||
- **Semantic Matching**: Uses Fuse.js for similarity scoring
|
||||
- **Purpose Categories**: Pattern-based task categorization
|
||||
- **Relevance Scoring**: High/medium/low relevance thresholds
|
||||
- **Context-Aware**: Different search configurations for different use cases
|
||||
|
||||
### **Usage Pattern**
|
||||
```javascript
|
||||
import { FuzzyTaskSearch } from '../utils/fuzzyTaskSearch.js';
|
||||
|
||||
// Initialize with tasks data and context
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
|
||||
// Find relevant tasks
|
||||
const searchResults = fuzzySearch.findRelevantTasks(query, {
|
||||
maxResults: 8,
|
||||
includeRecent: true,
|
||||
includeCategoryMatches: true
|
||||
});
|
||||
|
||||
// Get task IDs for context gathering
|
||||
const taskIds = fuzzySearch.getTaskIds(searchResults);
|
||||
```
|
||||
|
||||
## Implementation Patterns for Commands
|
||||
|
||||
### **1. Context-Aware Command Structure**
|
||||
```javascript
|
||||
// In command action handler
|
||||
async function commandAction(prompt, options) {
|
||||
// 1. Parameter validation and parsing
|
||||
const taskIds = options.id ? parseTaskIds(options.id) : [];
|
||||
const filePaths = options.files ? parseFilePaths(options.files) : [];
|
||||
|
||||
// 2. Initialize context gatherer
|
||||
const projectRoot = findProjectRoot() || '.';
|
||||
const tasksPath = path.join(projectRoot, 'tasks', 'tasks.json');
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// 3. Auto-discover relevant tasks if none specified
|
||||
if (taskIds.length === 0) {
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const discoveredIds = fuzzySearch.getTaskIds(
|
||||
fuzzySearch.findRelevantTasks(prompt)
|
||||
);
|
||||
taskIds.push(...discoveredIds);
|
||||
}
|
||||
|
||||
// 4. Gather context with token breakdown
|
||||
const contextResult = await gatherer.gather({
|
||||
tasks: taskIds,
|
||||
files: filePaths,
|
||||
customContext: options.context,
|
||||
includeProjectTree: options.projectTree,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
|
||||
// 5. Display token breakdown (for CLI)
|
||||
if (outputFormat === 'text') {
|
||||
displayDetailedTokenBreakdown(contextResult.tokenBreakdown);
|
||||
}
|
||||
|
||||
// 6. Use context in AI call
|
||||
const aiResult = await generateTextService(role, session, systemPrompt, userPrompt);
|
||||
|
||||
// 7. Display results with enhanced formatting
|
||||
displayResults(aiResult, contextResult.tokenBreakdown);
|
||||
}
|
||||
```
|
||||
|
||||
### **2. Token Display Pattern**
|
||||
```javascript
|
||||
function displayDetailedTokenBreakdown(tokenBreakdown, systemTokens, userTokens) {
|
||||
const sections = [];
|
||||
|
||||
// Build context breakdown
|
||||
if (tokenBreakdown.tasks?.length > 0) {
|
||||
const taskDetails = tokenBreakdown.tasks.map(task =>
|
||||
`${task.type === 'subtask' ? ' ' : ''}${task.id}: ${task.tokens.toLocaleString()}`
|
||||
).join('\n');
|
||||
sections.push(`Tasks (${tokenBreakdown.tasks.reduce((sum, t) => sum + t.tokens, 0).toLocaleString()}):\n${taskDetails}`);
|
||||
}
|
||||
|
||||
if (tokenBreakdown.files?.length > 0) {
|
||||
const fileDetails = tokenBreakdown.files.map(file =>
|
||||
` ${file.path}: ${file.tokens.toLocaleString()} (${file.size})`
|
||||
).join('\n');
|
||||
sections.push(`Files (${tokenBreakdown.files.reduce((sum, f) => sum + f.tokens, 0).toLocaleString()}):\n${fileDetails}`);
|
||||
}
|
||||
|
||||
// Add prompts breakdown
|
||||
sections.push(`Prompts: system ${systemTokens.toLocaleString()}, user ${userTokens.toLocaleString()}`);
|
||||
|
||||
// Display in clean box
|
||||
const content = sections.join('\n\n');
|
||||
console.log(boxen(content, {
|
||||
title: chalk.cyan('Token Usage'),
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'cyan'
|
||||
}));
|
||||
}
|
||||
```
|
||||
|
||||
### **3. Enhanced Result Display Pattern**
|
||||
```javascript
|
||||
function displayResults(result, query, detailLevel, tokenBreakdown) {
|
||||
// Header with query info
|
||||
const header = boxen(
|
||||
chalk.green.bold('Research Results') + '\n\n' +
|
||||
chalk.gray('Query: ') + chalk.white(query) + '\n' +
|
||||
chalk.gray('Detail Level: ') + chalk.cyan(detailLevel),
|
||||
{
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 1, bottom: 0 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'green'
|
||||
}
|
||||
);
|
||||
console.log(header);
|
||||
|
||||
// Process and highlight code blocks
|
||||
const processedResult = processCodeBlocks(result);
|
||||
|
||||
// Main content in clean box
|
||||
const contentBox = boxen(processedResult, {
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'gray'
|
||||
});
|
||||
console.log(contentBox);
|
||||
|
||||
console.log(chalk.green('✓ Research complete'));
|
||||
}
|
||||
```
|
||||
|
||||
## Code Block Enhancement
|
||||
|
||||
### **Syntax Highlighting Pattern**
|
||||
```javascript
|
||||
import { highlight } from 'cli-highlight';
|
||||
|
||||
function processCodeBlocks(text) {
|
||||
return text.replace(/```(\w+)?\n([\s\S]*?)```/g, (match, language, code) => {
|
||||
try {
|
||||
const highlighted = highlight(code.trim(), {
|
||||
language: language || 'javascript',
|
||||
theme: 'default'
|
||||
});
|
||||
return `\n${highlighted}\n`;
|
||||
} catch (error) {
|
||||
return `\n${code.trim()}\n`;
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Integration Guidelines
|
||||
|
||||
### **When to Use Context Gathering**
|
||||
- ✅ **DO**: Use for AI-powered commands that benefit from project context
|
||||
- ✅ **DO**: Use when users might want to reference specific tasks or files
|
||||
- ✅ **DO**: Use for research, analysis, or generation commands
|
||||
- ❌ **DON'T**: Use for simple CRUD operations that don't need AI context
|
||||
|
||||
### **Performance Considerations**
|
||||
- ✅ **DO**: Set reasonable file size limits (50KB default)
|
||||
- ✅ **DO**: Limit project tree depth (3-5 levels)
|
||||
- ✅ **DO**: Provide token counts to help users understand context size
|
||||
- ✅ **DO**: Allow users to control what context is included
|
||||
|
||||
### **Error Handling**
|
||||
- ✅ **DO**: Gracefully handle missing files with warnings
|
||||
- ✅ **DO**: Validate task IDs and provide helpful error messages
|
||||
- ✅ **DO**: Continue processing even if some context sources fail
|
||||
- ✅ **DO**: Provide fallback behavior when context gathering fails
|
||||
|
||||
### **Future Command Integration**
|
||||
Commands that should consider adopting this pattern:
|
||||
- `analyze-complexity` - Could benefit from file context
|
||||
- `expand-task` - Could use related task context
|
||||
- `update-task` - Could reference similar tasks for consistency
|
||||
- `add-task` - Could use project context for better task generation
|
||||
|
||||
## Export Patterns
|
||||
|
||||
### **Context Gatherer Module**
|
||||
```javascript
|
||||
export {
|
||||
ContextGatherer,
|
||||
createContextGatherer // Factory function
|
||||
};
|
||||
```
|
||||
|
||||
### **Fuzzy Search Module**
|
||||
```javascript
|
||||
export {
|
||||
FuzzyTaskSearch,
|
||||
PURPOSE_CATEGORIES,
|
||||
RELEVANCE_THRESHOLDS
|
||||
};
|
||||
```
|
||||
|
||||
This context gathering system provides a foundation for building more intelligent, context-aware commands that can leverage project knowledge to provide better AI-powered assistance.
|
||||
367
.cursor/rules/git_workflow.mdc
Normal file
367
.cursor/rules/git_workflow.mdc
Normal file
@@ -0,0 +1,367 @@
|
||||
---
|
||||
description: Git workflow integrated with Task Master for feature development and collaboration
|
||||
globs: "**/*"
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Git Workflow with Task Master Integration
|
||||
|
||||
## **Branch Strategy**
|
||||
|
||||
### **Main Branch Protection**
|
||||
- **main** branch contains production-ready code
|
||||
- All feature development happens on task-specific branches
|
||||
- Direct commits to main are prohibited
|
||||
- All changes merge via Pull Requests
|
||||
|
||||
### **Task Branch Naming**
|
||||
```bash
|
||||
# ✅ DO: Use consistent task branch naming
|
||||
task-001 # For Task 1
|
||||
task-004 # For Task 4
|
||||
task-015 # For Task 15
|
||||
|
||||
# ❌ DON'T: Use inconsistent naming
|
||||
feature/user-auth
|
||||
fix-database-issue
|
||||
random-branch-name
|
||||
```
|
||||
|
||||
## **Workflow Overview**
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Start: On main branch] --> B[Pull latest changes]
|
||||
B --> C[Create task branch<br/>git checkout -b task-XXX]
|
||||
C --> D[Set task status: in-progress]
|
||||
D --> E[Get task context & expand if needed]
|
||||
E --> F[Identify next subtask]
|
||||
|
||||
F --> G[Set subtask: in-progress]
|
||||
G --> H[Research & collect context<br/>update_subtask with findings]
|
||||
H --> I[Implement subtask]
|
||||
I --> J[Update subtask with completion]
|
||||
J --> K[Set subtask: done]
|
||||
K --> L[Git commit subtask]
|
||||
|
||||
L --> M{More subtasks?}
|
||||
M -->|Yes| F
|
||||
M -->|No| N[Run final tests]
|
||||
|
||||
N --> O[Commit tests if added]
|
||||
O --> P[Push task branch]
|
||||
P --> Q[Create Pull Request]
|
||||
Q --> R[Human review & merge]
|
||||
R --> S[Switch to main & pull]
|
||||
S --> T[Delete task branch]
|
||||
T --> U[Ready for next task]
|
||||
|
||||
style A fill:#e1f5fe
|
||||
style C fill:#f3e5f5
|
||||
style G fill:#fff3e0
|
||||
style L fill:#e8f5e8
|
||||
style Q fill:#fce4ec
|
||||
style R fill:#f1f8e9
|
||||
style U fill:#e1f5fe
|
||||
```
|
||||
|
||||
## **Complete Task Development Workflow**
|
||||
|
||||
### **Phase 1: Task Preparation**
|
||||
```bash
|
||||
# 1. Ensure you're on main branch and pull latest
|
||||
git checkout main
|
||||
git pull origin main
|
||||
|
||||
# 2. Check current branch status
|
||||
git branch # Verify you're on main
|
||||
|
||||
# 3. Create task-specific branch
|
||||
git checkout -b task-004 # For Task 4
|
||||
|
||||
# 4. Set task status in Task Master
|
||||
# Use: set_task_status tool or `task-master set-status --id=4 --status=in-progress`
|
||||
```
|
||||
|
||||
### **Phase 2: Task Analysis & Planning**
|
||||
```bash
|
||||
# 5. Get task context and expand if needed
|
||||
# Use: get_task tool or `task-master show 4`
|
||||
# Use: expand_task tool or `task-master expand --id=4 --research --force` (if complex)
|
||||
|
||||
# 6. Identify next subtask to work on
|
||||
# Use: next_task tool or `task-master next`
|
||||
```
|
||||
|
||||
### **Phase 3: Subtask Implementation Loop**
|
||||
For each subtask, follow this pattern:
|
||||
|
||||
```bash
|
||||
# 7. Mark subtask as in-progress
|
||||
# Use: set_task_status tool or `task-master set-status --id=4.1 --status=in-progress`
|
||||
|
||||
# 8. Gather context and research (if needed)
|
||||
# Use: update_subtask tool with research flag or:
|
||||
# `task-master update-subtask --id=4.1 --prompt="Research findings..." --research`
|
||||
|
||||
# 9. Collect code context through AI exploration
|
||||
# Document findings in subtask using update_subtask
|
||||
|
||||
# 10. Implement the subtask
|
||||
# Write code, tests, documentation
|
||||
|
||||
# 11. Update subtask with completion details
|
||||
# Use: update_subtask tool or:
|
||||
# `task-master update-subtask --id=4.1 --prompt="Implementation complete..."`
|
||||
|
||||
# 12. Mark subtask as done
|
||||
# Use: set_task_status tool or `task-master set-status --id=4.1 --status=done`
|
||||
|
||||
# 13. Commit the subtask implementation
|
||||
git add .
|
||||
git commit -m "feat(task-4): Complete subtask 4.1 - [Subtask Title]
|
||||
|
||||
- Implementation details
|
||||
- Key changes made
|
||||
- Any important notes
|
||||
|
||||
Subtask 4.1: [Brief description of what was accomplished]
|
||||
Relates to Task 4: [Main task title]"
|
||||
```
|
||||
|
||||
### **Phase 4: Task Completion**
|
||||
```bash
|
||||
# 14. When all subtasks are complete, run final testing
|
||||
# Create test file if needed, ensure all tests pass
|
||||
npm test # or jest, or manual testing
|
||||
|
||||
# 15. If tests were added/modified, commit them
|
||||
git add .
|
||||
git commit -m "test(task-4): Add comprehensive tests for Task 4
|
||||
|
||||
- Unit tests for core functionality
|
||||
- Integration tests for API endpoints
|
||||
- All tests passing
|
||||
|
||||
Task 4: [Main task title] - Testing complete"
|
||||
|
||||
# 16. Push the task branch
|
||||
git push origin task-004
|
||||
|
||||
# 17. Create Pull Request
|
||||
# Title: "Task 4: [Task Title]"
|
||||
# Description should include:
|
||||
# - Task overview
|
||||
# - Subtasks completed
|
||||
# - Testing approach
|
||||
# - Any breaking changes or considerations
|
||||
```
|
||||
|
||||
### **Phase 5: PR Merge & Cleanup**
|
||||
```bash
|
||||
# 18. Human reviews and merges PR into main
|
||||
|
||||
# 19. Switch back to main and pull merged changes
|
||||
git checkout main
|
||||
git pull origin main
|
||||
|
||||
# 20. Delete the feature branch (optional cleanup)
|
||||
git branch -d task-004
|
||||
git push origin --delete task-004
|
||||
```
|
||||
|
||||
## **Commit Message Standards**
|
||||
|
||||
### **Subtask Commits**
|
||||
```bash
|
||||
# ✅ DO: Consistent subtask commit format
|
||||
git commit -m "feat(task-4): Complete subtask 4.1 - Initialize Express server
|
||||
|
||||
- Set up Express.js with TypeScript configuration
|
||||
- Added CORS and body parsing middleware
|
||||
- Implemented health check endpoints
|
||||
- Basic error handling middleware
|
||||
|
||||
Subtask 4.1: Initialize project with npm and install dependencies
|
||||
Relates to Task 4: Setup Express.js Server Project"
|
||||
|
||||
# ❌ DON'T: Vague or inconsistent commits
|
||||
git commit -m "fixed stuff"
|
||||
git commit -m "working on task"
|
||||
```
|
||||
|
||||
### **Test Commits**
|
||||
```bash
|
||||
# ✅ DO: Separate test commits when substantial
|
||||
git commit -m "test(task-4): Add comprehensive tests for Express server setup
|
||||
|
||||
- Unit tests for middleware configuration
|
||||
- Integration tests for health check endpoints
|
||||
- Mock tests for database connection
|
||||
- All tests passing with 95% coverage
|
||||
|
||||
Task 4: Setup Express.js Server Project - Testing complete"
|
||||
```
|
||||
|
||||
### **Commit Type Prefixes**
|
||||
- `feat(task-X):` - New feature implementation
|
||||
- `fix(task-X):` - Bug fixes
|
||||
- `test(task-X):` - Test additions/modifications
|
||||
- `docs(task-X):` - Documentation updates
|
||||
- `refactor(task-X):` - Code refactoring
|
||||
- `chore(task-X):` - Build/tooling changes
|
||||
|
||||
## **Task Master Commands Integration**
|
||||
|
||||
### **Essential Commands for Git Workflow**
|
||||
```bash
|
||||
# Task management
|
||||
task-master show <id> # Get task/subtask details
|
||||
task-master next # Find next task to work on
|
||||
task-master set-status --id=<id> --status=<status>
|
||||
task-master update-subtask --id=<id> --prompt="..." --research
|
||||
|
||||
# Task expansion (for complex tasks)
|
||||
task-master expand --id=<id> --research --force
|
||||
|
||||
# Progress tracking
|
||||
task-master list # View all tasks and status
|
||||
task-master list --status=in-progress # View active tasks
|
||||
```
|
||||
|
||||
### **MCP Tool Equivalents**
|
||||
When using Cursor or other MCP-integrated tools:
|
||||
- `get_task` instead of `task-master show`
|
||||
- `next_task` instead of `task-master next`
|
||||
- `set_task_status` instead of `task-master set-status`
|
||||
- `update_subtask` instead of `task-master update-subtask`
|
||||
|
||||
## **Branch Management Rules**
|
||||
|
||||
### **Branch Protection**
|
||||
```bash
|
||||
# ✅ DO: Always work on task branches
|
||||
git checkout -b task-005
|
||||
# Make changes
|
||||
git commit -m "..."
|
||||
git push origin task-005
|
||||
|
||||
# ❌ DON'T: Commit directly to main
|
||||
git checkout main
|
||||
git commit -m "..." # NEVER do this
|
||||
```
|
||||
|
||||
### **Keeping Branches Updated**
|
||||
```bash
|
||||
# ✅ DO: Regularly sync with main (for long-running tasks)
|
||||
git checkout task-005
|
||||
git fetch origin
|
||||
git rebase origin/main # or merge if preferred
|
||||
|
||||
# Resolve any conflicts and continue
|
||||
```
|
||||
|
||||
## **Pull Request Guidelines**
|
||||
|
||||
### **PR Title Format**
|
||||
```
|
||||
Task <ID>: <Task Title>
|
||||
|
||||
Examples:
|
||||
Task 4: Setup Express.js Server Project
|
||||
Task 7: Implement User Authentication
|
||||
Task 12: Add Stripe Payment Integration
|
||||
```
|
||||
|
||||
### **PR Description Template**
|
||||
```markdown
|
||||
## Task Overview
|
||||
Brief description of the main task objective.
|
||||
|
||||
## Subtasks Completed
|
||||
- [x] 4.1: Initialize project with npm and install dependencies
|
||||
- [x] 4.2: Configure TypeScript, ESLint and Prettier
|
||||
- [x] 4.3: Create basic Express app with middleware and health check route
|
||||
|
||||
## Implementation Details
|
||||
- Key architectural decisions made
|
||||
- Important code changes
|
||||
- Any deviations from original plan
|
||||
|
||||
## Testing
|
||||
- [ ] Unit tests added/updated
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Manual testing completed
|
||||
|
||||
## Breaking Changes
|
||||
List any breaking changes or migration requirements.
|
||||
|
||||
## Related Tasks
|
||||
Mention any dependent tasks or follow-up work needed.
|
||||
```
|
||||
|
||||
## **Conflict Resolution**
|
||||
|
||||
### **Task Conflicts**
|
||||
```bash
|
||||
# If multiple people work on overlapping tasks:
|
||||
# 1. Use Task Master's move functionality to reorganize
|
||||
task-master move --from=5 --to=25 # Move conflicting task
|
||||
|
||||
# 2. Update task dependencies
|
||||
task-master add-dependency --id=6 --depends-on=5
|
||||
|
||||
# 3. Coordinate through PR comments and task updates
|
||||
```
|
||||
|
||||
### **Code Conflicts**
|
||||
```bash
|
||||
# Standard Git conflict resolution
|
||||
git fetch origin
|
||||
git rebase origin/main
|
||||
# Resolve conflicts in files
|
||||
git add .
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
## **Emergency Procedures**
|
||||
|
||||
### **Hotfixes**
|
||||
```bash
|
||||
# For urgent production fixes:
|
||||
git checkout main
|
||||
git pull origin main
|
||||
git checkout -b hotfix-urgent-issue
|
||||
|
||||
# Make minimal fix
|
||||
git commit -m "hotfix: Fix critical production issue
|
||||
|
||||
- Specific fix description
|
||||
- Minimal impact change
|
||||
- Requires immediate deployment"
|
||||
|
||||
git push origin hotfix-urgent-issue
|
||||
# Create emergency PR for immediate review
|
||||
```
|
||||
|
||||
### **Task Abandonment**
|
||||
```bash
|
||||
# If task needs to be abandoned or significantly changed:
|
||||
# 1. Update task status
|
||||
task-master set-status --id=<id> --status=cancelled
|
||||
|
||||
# 2. Clean up branch
|
||||
git checkout main
|
||||
git branch -D task-<id>
|
||||
git push origin --delete task-<id>
|
||||
|
||||
# 3. Document reasoning in task
|
||||
task-master update-task --id=<id> --prompt="Task cancelled due to..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**References:**
|
||||
- [Task Master Workflow](mdc:.cursor/rules/dev_workflow.mdc)
|
||||
- [Architecture Guidelines](mdc:.cursor/rules/architecture.mdc)
|
||||
- [Task Master Commands](mdc:.cursor/rules/taskmaster.mdc)
|
||||
@@ -24,17 +24,22 @@ alwaysApply: false
|
||||
The standard pattern for adding a feature follows this workflow:
|
||||
|
||||
1. **Core Logic**: Implement the business logic in the appropriate module (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
|
||||
2. **AI Integration (If Applicable)**:
|
||||
2. **Context Gathering (If Applicable)**:
|
||||
- For AI-powered commands that benefit from project context, use the standardized context gathering patterns from [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc).
|
||||
- Import `ContextGatherer` and `FuzzyTaskSearch` utilities for reusable context extraction.
|
||||
- Support multiple context types: tasks, files, custom text, project tree.
|
||||
- Implement detailed token breakdown display for transparency.
|
||||
3. **AI Integration (If Applicable)**:
|
||||
- Import necessary service functions (e.g., `generateTextService`, `streamTextService`) from [`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js).
|
||||
- Prepare parameters (`role`, `session`, `systemPrompt`, `prompt`).
|
||||
- Call the service function.
|
||||
- Handle the response (direct text or stream object).
|
||||
- **Important**: Prefer `generateTextService` for calls sending large context (like stringified JSON) where incremental display is not needed. See [`ai_services.mdc`](mdc:.cursor/rules/ai_services.mdc) for detailed usage patterns and cautions.
|
||||
3. **UI Components**: Add any display functions to [`ui.js`](mdc:scripts/modules/ui.js) following [`ui.mdc`](mdc:.cursor/rules/ui.mdc).
|
||||
4. **Command Integration**: Add the CLI command to [`commands.js`](mdc:scripts/modules/commands.js) following [`commands.mdc`](mdc:.cursor/rules/commands.mdc).
|
||||
5. **Testing**: Write tests for all components of the feature (following [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
|
||||
6. **Configuration**: Update configuration settings or add new ones in [`config-manager.js`](mdc:scripts/modules/config-manager.js) and ensure getters/setters are appropriate. Update documentation in [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc). Update the `.taskmasterconfig` structure if needed.
|
||||
7. **Documentation**: Update help text and documentation in [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
4. **UI Components**: Add any display functions to [`ui.js`](mdc:scripts/modules/ui.js) following [`ui.mdc`](mdc:.cursor/rules/ui.mdc). Consider enhanced formatting with syntax highlighting for code blocks.
|
||||
5. **Command Integration**: Add the CLI command to [`commands.js`](mdc:scripts/modules/commands.js) following [`commands.mdc`](mdc:.cursor/rules/commands.mdc).
|
||||
6. **Testing**: Write tests for all components of the feature (following [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
|
||||
7. **Configuration**: Update configuration settings or add new ones in [`config-manager.js`](mdc:scripts/modules/config-manager.js) and ensure getters/setters are appropriate. Update documentation in [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc). Update the `.taskmasterconfig` structure if needed.
|
||||
8. **Documentation**: Update help text and documentation in [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
|
||||
## Critical Checklist for New Features
|
||||
|
||||
|
||||
@@ -112,9 +112,10 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **CLI Command:** `task-master show [id] [options]`
|
||||
* **Description:** `Display detailed information for a specific Taskmaster task or subtask by its ID.`
|
||||
* **Key Parameters/Options:**
|
||||
* `id`: `Required. The ID of the Taskmaster task, e.g., '15', or subtask, e.g., '15.2', you want to view.` (CLI: `[id]` positional or `-i, --id <id>`)
|
||||
* `id`: `Required. The ID of the Taskmaster task, e.g., '15', or subtask, e.g., '15.2', you want to view.` (CLI: `[id]. Supports comma-separated list of tasks to get multiple tasks at once.` positional or `-i, --id <id>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Understand the full details, implementation notes, and test strategy for a specific task before starting work.
|
||||
* **CRITICAL INFORMATION** If you need to collect information from multiple tasks, use comma-separated IDs (i.e. 1,2,3) to receive an array of tasks. Do not needlessly get tasks one at a time if you need to get many as that is wasteful.
|
||||
|
||||
---
|
||||
|
||||
@@ -366,6 +367,43 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
|
||||
---
|
||||
|
||||
## AI-Powered Research
|
||||
|
||||
### 25. Research (`research`)
|
||||
|
||||
* **MCP Tool:** `research`
|
||||
* **CLI Command:** `task-master research [options]`
|
||||
* **Description:** `Perform AI-powered research queries with project context to get fresh, up-to-date information beyond the AI's knowledge cutoff.`
|
||||
* **Key Parameters/Options:**
|
||||
* `query`: `Required. Research query/prompt (e.g., "What are the latest best practices for React Query v5?").` (CLI: `[query]` positional or `-q, --query <text>`)
|
||||
* `taskIds`: `Comma-separated list of task/subtask IDs for context (e.g., "15,16.2,17").` (CLI: `-i, --id <ids>`)
|
||||
* `filePaths`: `Comma-separated list of file paths for context (e.g., "src/api.js,docs/readme.md").` (CLI: `-f, --files <paths>`)
|
||||
* `customContext`: `Additional custom context text to include in the research.` (CLI: `-c, --context <text>`)
|
||||
* `includeProjectTree`: `Include project file tree structure in context (default: false).` (CLI: `--tree`)
|
||||
* `detailLevel`: `Detail level for the research response: 'low', 'medium', 'high' (default: medium).` (CLI: `--detail <level>`)
|
||||
* `projectRoot`: `The directory of the project. Must be an absolute path.` (CLI: Determined automatically)
|
||||
* **Usage:** **This is a POWERFUL tool that agents should use FREQUENTLY** to:
|
||||
* Get fresh information beyond knowledge cutoff dates
|
||||
* Research latest best practices, library updates, security patches
|
||||
* Find implementation examples for specific technologies
|
||||
* Validate approaches against current industry standards
|
||||
* Get contextual advice based on project files and tasks
|
||||
* **When to Consider Using Research:**
|
||||
* **Before implementing any task** - Research current best practices
|
||||
* **When encountering new technologies** - Get up-to-date implementation guidance (libraries, apis, etc)
|
||||
* **For security-related tasks** - Find latest security recommendations
|
||||
* **When updating dependencies** - Research breaking changes and migration guides
|
||||
* **For performance optimization** - Get current performance best practices
|
||||
* **When debugging complex issues** - Research known solutions and workarounds
|
||||
* **Research + Action Pattern:**
|
||||
* Use `research` to gather fresh information
|
||||
* Use `update_subtask` to commit findings with timestamps
|
||||
* Use `update_task` to incorporate research into task details
|
||||
* Use `add_task` with research flag for informed task creation
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. The research provides FRESH data beyond the AI's training cutoff, making it invaluable for current best practices and recent developments.
|
||||
|
||||
---
|
||||
|
||||
## File Management
|
||||
|
||||
### 24. Generate Task Files (`generate`)
|
||||
|
||||
408
.cursor/rules/tdd_workflow.mdc
Normal file
408
.cursor/rules/tdd_workflow.mdc
Normal file
@@ -0,0 +1,408 @@
|
||||
---
|
||||
description:
|
||||
globs:
|
||||
alwaysApply: true
|
||||
---
|
||||
# Test Workflow & Development Process
|
||||
|
||||
## **Test-Driven Development (TDD) Integration**
|
||||
|
||||
### **Core TDD Cycle with Jest**
|
||||
```bash
|
||||
# 1. Start development with watch mode
|
||||
npm run test:watch
|
||||
|
||||
# 2. Write failing test first
|
||||
# Create test file: src/utils/newFeature.test.ts
|
||||
# Write test that describes expected behavior
|
||||
|
||||
# 3. Implement minimum code to make test pass
|
||||
# 4. Refactor while keeping tests green
|
||||
# 5. Add edge cases and error scenarios
|
||||
```
|
||||
|
||||
### **TDD Workflow Per Subtask**
|
||||
```bash
|
||||
# When starting a new subtask:
|
||||
task-master set-status --id=4.1 --status=in-progress
|
||||
|
||||
# Begin TDD cycle:
|
||||
npm run test:watch # Keep running during development
|
||||
|
||||
# Document TDD progress in subtask:
|
||||
task-master update-subtask --id=4.1 --prompt="TDD Progress:
|
||||
- Written 3 failing tests for core functionality
|
||||
- Implemented basic feature, tests now passing
|
||||
- Adding edge case tests for error handling"
|
||||
|
||||
# Complete subtask with test summary:
|
||||
task-master update-subtask --id=4.1 --prompt="Implementation complete:
|
||||
- Feature implemented with 8 unit tests
|
||||
- Coverage: 95% statements, 88% branches
|
||||
- All tests passing, TDD cycle complete"
|
||||
```
|
||||
|
||||
## **Testing Commands & Usage**
|
||||
|
||||
### **Development Commands**
|
||||
```bash
|
||||
# Primary development command - use during coding
|
||||
npm run test:watch # Watch mode with Jest
|
||||
npm run test:watch -- --testNamePattern="auth" # Watch specific tests
|
||||
|
||||
# Targeted testing during development
|
||||
npm run test:unit # Run only unit tests
|
||||
npm run test:unit -- --coverage # Unit tests with coverage
|
||||
|
||||
# Integration testing when APIs are ready
|
||||
npm run test:integration # Run integration tests
|
||||
npm run test:integration -- --detectOpenHandles # Debug hanging tests
|
||||
|
||||
# End-to-end testing for workflows
|
||||
npm run test:e2e # Run E2E tests
|
||||
npm run test:e2e -- --timeout=30000 # Extended timeout for E2E
|
||||
```
|
||||
|
||||
### **Quality Assurance Commands**
|
||||
```bash
|
||||
# Full test suite with coverage (before commits)
|
||||
npm run test:coverage # Complete coverage analysis
|
||||
|
||||
# All tests (CI/CD pipeline)
|
||||
npm test # Run all test projects
|
||||
|
||||
# Specific test file execution
|
||||
npm test -- auth.test.ts # Run specific test file
|
||||
npm test -- --testNamePattern="should handle errors" # Run specific tests
|
||||
```
|
||||
|
||||
## **Test Implementation Patterns**
|
||||
|
||||
### **Unit Test Development**
|
||||
```typescript
|
||||
// ✅ DO: Follow established patterns from auth.test.ts
|
||||
describe('FeatureName', () => {
|
||||
beforeEach(() => {
|
||||
jest.clearAllMocks();
|
||||
// Setup mocks with proper typing
|
||||
});
|
||||
|
||||
describe('functionName', () => {
|
||||
it('should handle normal case', () => {
|
||||
// Test implementation with specific assertions
|
||||
});
|
||||
|
||||
it('should throw error for invalid input', async () => {
|
||||
// Error scenario testing
|
||||
await expect(functionName(invalidInput))
|
||||
.rejects.toThrow('Specific error message');
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### **Integration Test Development**
|
||||
```typescript
|
||||
// ✅ DO: Use supertest for API endpoint testing
|
||||
import request from 'supertest';
|
||||
import { app } from '../../src/app';
|
||||
|
||||
describe('POST /api/auth/register', () => {
|
||||
beforeEach(async () => {
|
||||
await integrationTestUtils.cleanupTestData();
|
||||
});
|
||||
|
||||
it('should register user successfully', async () => {
|
||||
const userData = createTestUser();
|
||||
|
||||
const response = await request(app)
|
||||
.post('/api/auth/register')
|
||||
.send(userData)
|
||||
.expect(201);
|
||||
|
||||
expect(response.body).toMatchObject({
|
||||
id: expect.any(String),
|
||||
email: userData.email
|
||||
});
|
||||
|
||||
// Verify database state
|
||||
const user = await prisma.user.findUnique({
|
||||
where: { email: userData.email }
|
||||
});
|
||||
expect(user).toBeTruthy();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### **E2E Test Development**
|
||||
```typescript
|
||||
// ✅ DO: Test complete user workflows
|
||||
describe('User Authentication Flow', () => {
|
||||
it('should complete registration → login → protected access', async () => {
|
||||
// Step 1: Register
|
||||
const userData = createTestUser();
|
||||
await request(app)
|
||||
.post('/api/auth/register')
|
||||
.send(userData)
|
||||
.expect(201);
|
||||
|
||||
// Step 2: Login
|
||||
const loginResponse = await request(app)
|
||||
.post('/api/auth/login')
|
||||
.send({ email: userData.email, password: userData.password })
|
||||
.expect(200);
|
||||
|
||||
const { token } = loginResponse.body;
|
||||
|
||||
// Step 3: Access protected resource
|
||||
await request(app)
|
||||
.get('/api/profile')
|
||||
.set('Authorization', `Bearer ${token}`)
|
||||
.expect(200);
|
||||
}, 30000); // Extended timeout for E2E
|
||||
});
|
||||
```
|
||||
|
||||
## **Mocking & Test Utilities**
|
||||
|
||||
### **Established Mocking Patterns**
|
||||
```typescript
|
||||
// ✅ DO: Use established bcrypt mocking pattern
|
||||
jest.mock('bcrypt');
|
||||
import bcrypt from 'bcrypt';
|
||||
const mockHash = bcrypt.hash as jest.MockedFunction<typeof bcrypt.hash>;
|
||||
const mockCompare = bcrypt.compare as jest.MockedFunction<typeof bcrypt.compare>;
|
||||
|
||||
// ✅ DO: Use Prisma mocking for unit tests
|
||||
jest.mock('@prisma/client', () => ({
|
||||
PrismaClient: jest.fn().mockImplementation(() => ({
|
||||
user: {
|
||||
create: jest.fn(),
|
||||
findUnique: jest.fn(),
|
||||
},
|
||||
$connect: jest.fn(),
|
||||
$disconnect: jest.fn(),
|
||||
})),
|
||||
}));
|
||||
```
|
||||
|
||||
### **Test Fixtures Usage**
|
||||
```typescript
|
||||
// ✅ DO: Use centralized test fixtures
|
||||
import { createTestUser, adminUser, invalidUser } from '../fixtures/users';
|
||||
|
||||
describe('User Service', () => {
|
||||
it('should handle admin user creation', async () => {
|
||||
const userData = createTestUser(adminUser);
|
||||
// Test implementation
|
||||
});
|
||||
|
||||
it('should reject invalid user data', async () => {
|
||||
const userData = createTestUser(invalidUser);
|
||||
// Error testing
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## **Coverage Standards & Monitoring**
|
||||
|
||||
### **Coverage Thresholds**
|
||||
- **Global Standards**: 80% lines/functions, 70% branches
|
||||
- **Critical Code**: 90% utils, 85% middleware
|
||||
- **New Features**: Must meet or exceed global thresholds
|
||||
- **Legacy Code**: Gradual improvement with each change
|
||||
|
||||
### **Coverage Reporting & Analysis**
|
||||
```bash
|
||||
# Generate coverage reports
|
||||
npm run test:coverage
|
||||
|
||||
# View detailed HTML report
|
||||
open coverage/lcov-report/index.html
|
||||
|
||||
# Coverage files generated:
|
||||
# - coverage/lcov-report/index.html # Detailed HTML report
|
||||
# - coverage/lcov.info # LCOV format for IDE integration
|
||||
# - coverage/coverage-final.json # JSON format for tooling
|
||||
```
|
||||
|
||||
### **Coverage Quality Checks**
|
||||
```typescript
|
||||
// ✅ DO: Test all code paths
|
||||
describe('validateInput', () => {
|
||||
it('should return true for valid input', () => {
|
||||
expect(validateInput('valid')).toBe(true);
|
||||
});
|
||||
|
||||
it('should return false for various invalid inputs', () => {
|
||||
expect(validateInput('')).toBe(false); // Empty string
|
||||
expect(validateInput(null)).toBe(false); // Null value
|
||||
expect(validateInput(undefined)).toBe(false); // Undefined
|
||||
});
|
||||
|
||||
it('should throw for unexpected input types', () => {
|
||||
expect(() => validateInput(123)).toThrow('Invalid input type');
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## **Testing During Development Phases**
|
||||
|
||||
### **Feature Development Phase**
|
||||
```bash
|
||||
# 1. Start feature development
|
||||
task-master set-status --id=X.Y --status=in-progress
|
||||
|
||||
# 2. Begin TDD cycle
|
||||
npm run test:watch
|
||||
|
||||
# 3. Document test progress in subtask
|
||||
task-master update-subtask --id=X.Y --prompt="Test development:
|
||||
- Created test file with 5 failing tests
|
||||
- Implemented core functionality
|
||||
- Tests passing, adding error scenarios"
|
||||
|
||||
# 4. Verify coverage before completion
|
||||
npm run test:coverage
|
||||
|
||||
# 5. Update subtask with final test status
|
||||
task-master update-subtask --id=X.Y --prompt="Testing complete:
|
||||
- 12 unit tests with full coverage
|
||||
- All edge cases and error scenarios covered
|
||||
- Ready for integration testing"
|
||||
```
|
||||
|
||||
### **Integration Testing Phase**
|
||||
```bash
|
||||
# After API endpoints are implemented
|
||||
npm run test:integration
|
||||
|
||||
# Update integration test templates
|
||||
# Replace placeholder tests with real endpoint calls
|
||||
|
||||
# Document integration test results
|
||||
task-master update-subtask --id=X.Y --prompt="Integration tests:
|
||||
- Updated auth endpoint tests
|
||||
- Database integration verified
|
||||
- All HTTP status codes and responses tested"
|
||||
```
|
||||
|
||||
### **Pre-Commit Testing Phase**
|
||||
```bash
|
||||
# Before committing code
|
||||
npm run test:coverage # Verify all tests pass with coverage
|
||||
npm run test:unit # Quick unit test verification
|
||||
npm run test:integration # Integration test verification (if applicable)
|
||||
|
||||
# Commit pattern for test updates
|
||||
git add tests/ src/**/*.test.ts
|
||||
git commit -m "test(task-X): Add comprehensive tests for Feature Y
|
||||
|
||||
- Unit tests with 95% coverage (exceeds 90% threshold)
|
||||
- Integration tests for API endpoints
|
||||
- Test fixtures for data generation
|
||||
- Proper mocking patterns established
|
||||
|
||||
Task X: Feature Y - Testing complete"
|
||||
```
|
||||
|
||||
## **Error Handling & Debugging**
|
||||
|
||||
### **Test Debugging Techniques**
|
||||
```typescript
|
||||
// ✅ DO: Use test utilities for debugging
|
||||
import { testUtils } from '../setup';
|
||||
|
||||
it('should debug complex operation', () => {
|
||||
testUtils.withConsole(() => {
|
||||
// Console output visible only for this test
|
||||
console.log('Debug info:', complexData);
|
||||
service.complexOperation();
|
||||
});
|
||||
});
|
||||
|
||||
// ✅ DO: Use proper async debugging
|
||||
it('should handle async operations', async () => {
|
||||
const promise = service.asyncOperation();
|
||||
|
||||
// Test intermediate state
|
||||
expect(service.isProcessing()).toBe(true);
|
||||
|
||||
const result = await promise;
|
||||
expect(result).toBe('expected');
|
||||
expect(service.isProcessing()).toBe(false);
|
||||
});
|
||||
```
|
||||
|
||||
### **Common Test Issues & Solutions**
|
||||
```bash
|
||||
# Hanging tests (common with database connections)
|
||||
npm run test:integration -- --detectOpenHandles
|
||||
|
||||
# Memory leaks in tests
|
||||
npm run test:unit -- --logHeapUsage
|
||||
|
||||
# Slow tests identification
|
||||
npm run test:coverage -- --verbose
|
||||
|
||||
# Mock not working properly
|
||||
# Check: mock is declared before imports
|
||||
# Check: jest.clearAllMocks() in beforeEach
|
||||
# Check: TypeScript typing is correct
|
||||
```
|
||||
|
||||
## **Continuous Integration Integration**
|
||||
|
||||
### **CI/CD Pipeline Testing**
|
||||
```yaml
|
||||
# Example GitHub Actions integration
|
||||
- name: Run tests
|
||||
run: |
|
||||
npm ci
|
||||
npm run test:coverage
|
||||
|
||||
- name: Upload coverage reports
|
||||
uses: codecov/codecov-action@v3
|
||||
with:
|
||||
file: ./coverage/lcov.info
|
||||
```
|
||||
|
||||
### **Pre-commit Hooks**
|
||||
```bash
|
||||
# Setup pre-commit testing (recommended)
|
||||
# In package.json scripts:
|
||||
"pre-commit": "npm run test:unit && npm run test:integration"
|
||||
|
||||
# Husky integration example:
|
||||
npx husky add .husky/pre-commit "npm run test:unit"
|
||||
```
|
||||
|
||||
## **Test Maintenance & Evolution**
|
||||
|
||||
### **Adding Tests for New Features**
|
||||
1. **Create test file** alongside source code or in `tests/unit/`
|
||||
2. **Follow established patterns** from `src/utils/auth.test.ts`
|
||||
3. **Use existing fixtures** from `tests/fixtures/`
|
||||
4. **Apply proper mocking** patterns for dependencies
|
||||
5. **Meet coverage thresholds** for the module
|
||||
|
||||
### **Updating Integration/E2E Tests**
|
||||
1. **Update templates** in `tests/integration/` when APIs change
|
||||
2. **Modify E2E workflows** in `tests/e2e/` for new user journeys
|
||||
3. **Update test fixtures** for new data requirements
|
||||
4. **Maintain database cleanup** utilities
|
||||
|
||||
### **Test Performance Optimization**
|
||||
- **Parallel execution**: Jest runs tests in parallel by default
|
||||
- **Test isolation**: Use proper setup/teardown for independence
|
||||
- **Mock optimization**: Mock heavy dependencies appropriately
|
||||
- **Database efficiency**: Use transaction rollbacks where possible
|
||||
|
||||
---
|
||||
|
||||
**Key References:**
|
||||
- [Testing Standards](mdc:.cursor/rules/tests.mdc)
|
||||
- [Git Workflow](mdc:.cursor/rules/git_workflow.mdc)
|
||||
- [Development Workflow](mdc:.cursor/rules/dev_workflow.mdc)
|
||||
- [Jest Configuration](mdc:jest.config.js)
|
||||
- [Auth Test Example](mdc:src/utils/auth.test.ts)
|
||||
@@ -150,4 +150,91 @@ alwaysApply: false
|
||||
));
|
||||
```
|
||||
|
||||
Refer to [`ui.js`](mdc:scripts/modules/ui.js) for implementation examples and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines.
|
||||
## Enhanced Display Patterns
|
||||
|
||||
### **Token Breakdown Display**
|
||||
- Use detailed, granular token breakdowns for AI-powered commands
|
||||
- Display context sources with individual token counts
|
||||
- Show both token count and character count for transparency
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Display detailed token breakdown
|
||||
function displayDetailedTokenBreakdown(tokenBreakdown, systemTokens, userTokens) {
|
||||
const sections = [];
|
||||
|
||||
if (tokenBreakdown.tasks?.length > 0) {
|
||||
const taskDetails = tokenBreakdown.tasks.map(task =>
|
||||
`${task.type === 'subtask' ? ' ' : ''}${task.id}: ${task.tokens.toLocaleString()}`
|
||||
).join('\n');
|
||||
sections.push(`Tasks (${tokenBreakdown.tasks.reduce((sum, t) => sum + t.tokens, 0).toLocaleString()}):\n${taskDetails}`);
|
||||
}
|
||||
|
||||
const content = sections.join('\n\n');
|
||||
console.log(boxen(content, {
|
||||
title: chalk.cyan('Token Usage'),
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'cyan'
|
||||
}));
|
||||
}
|
||||
```
|
||||
|
||||
### **Code Block Syntax Highlighting**
|
||||
- Use `cli-highlight` library for syntax highlighting in terminal output
|
||||
- Process code blocks in AI responses for better readability
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Enhance code blocks with syntax highlighting
|
||||
import { highlight } from 'cli-highlight';
|
||||
|
||||
function processCodeBlocks(text) {
|
||||
return text.replace(/```(\w+)?\n([\s\S]*?)```/g, (match, language, code) => {
|
||||
try {
|
||||
const highlighted = highlight(code.trim(), {
|
||||
language: language || 'javascript',
|
||||
theme: 'default'
|
||||
});
|
||||
return `\n${highlighted}\n`;
|
||||
} catch (error) {
|
||||
return `\n${code.trim()}\n`;
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### **Multi-Section Result Display**
|
||||
- Use separate boxes for headers, content, and metadata
|
||||
- Maintain consistent styling across different result types
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use structured result display
|
||||
function displayResults(result, query, detailLevel) {
|
||||
// Header with query info
|
||||
const header = boxen(
|
||||
chalk.green.bold('Research Results') + '\n\n' +
|
||||
chalk.gray('Query: ') + chalk.white(query) + '\n' +
|
||||
chalk.gray('Detail Level: ') + chalk.cyan(detailLevel),
|
||||
{
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 1, bottom: 0 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'green'
|
||||
}
|
||||
);
|
||||
console.log(header);
|
||||
|
||||
// Process and display main content
|
||||
const processedResult = processCodeBlocks(result);
|
||||
const contentBox = boxen(processedResult, {
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'gray'
|
||||
});
|
||||
console.log(contentBox);
|
||||
|
||||
console.log(chalk.green('✓ Operation complete'));
|
||||
}
|
||||
```
|
||||
|
||||
Refer to [`ui.js`](mdc:scripts/modules/ui.js) for implementation examples, [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for context display patterns, and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines.
|
||||
@@ -46,7 +46,7 @@ alwaysApply: false
|
||||
- **Location**:
|
||||
- **Core CLI Utilities**: Place utilities used primarily by the core `task-master` CLI logic and command modules (`scripts/modules/*`) into [`scripts/modules/utils.js`](mdc:scripts/modules/utils.js).
|
||||
- **MCP Server Utilities**: Place utilities specifically designed to support the MCP server implementation into the appropriate subdirectories within `mcp-server/src/`.
|
||||
- Path/Core Logic Helpers: [`mcp-server/src/core/utils/`](mdc:mcp-server/src/core/utils/) (e.g., `path-utils.js`).
|
||||
- Path/Core Logic Helpers: [`mcp-server/src/core/utils/`](mdc:mcp-server/src/core/utils) (e.g., `path-utils.js`).
|
||||
- Tool Execution/Response Helpers: [`mcp-server/src/tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
|
||||
|
||||
## Documentation Standards
|
||||
@@ -110,7 +110,7 @@ Taskmaster configuration (excluding API keys) is primarily managed through the `
|
||||
- ✅ DO: Use appropriate icons for different log levels
|
||||
- ✅ DO: Respect the configured log level
|
||||
- ❌ DON'T: Add direct console.log calls outside the logging utility
|
||||
- **Note on Passed Loggers**: When a logger object (like the FastMCP `log` object) is passed *as a parameter* (e.g., as `mcpLog`) into core Task Master functions, the receiving function often expects specific methods (`.info`, `.warn`, `.error`, etc.) to be directly callable on that object (e.g., `mcpLog[level](...)`). If the passed logger doesn't have this exact structure, a wrapper object may be needed. See the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for the standard pattern used in direct functions.
|
||||
- **Note on Passed Loggers**: When a logger object (like the FastMCP `log` object) is passed *as a parameter* (e.g., as `mcpLog`) into core Task Master functions, the receiving function often expects specific methods (`.info`, `.warn`, `.error`, etc.) to be directly callable on that object (e.g., `mcpLog[level](mdc:...)`). If the passed logger doesn't have this exact structure, a wrapper object may be needed. See the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for the standard pattern used in direct functions.
|
||||
|
||||
- **Logger Wrapper Pattern**:
|
||||
- ✅ DO: Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors:
|
||||
@@ -548,4 +548,56 @@ export {
|
||||
};
|
||||
```
|
||||
|
||||
Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
## Context Gathering Utilities
|
||||
|
||||
### **ContextGatherer** (`scripts/modules/utils/contextGatherer.js`)
|
||||
|
||||
- **Multi-Source Context Extraction**:
|
||||
- ✅ DO: Use for AI-powered commands that need project context
|
||||
- ✅ DO: Support tasks, files, custom text, and project tree context
|
||||
- ✅ DO: Implement detailed token counting with `gpt-tokens` library
|
||||
- ✅ DO: Provide multiple output formats (research, chat, system-prompt)
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use ContextGatherer for consistent context extraction
|
||||
import { ContextGatherer } from '../utils/contextGatherer.js';
|
||||
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
const result = await gatherer.gather({
|
||||
tasks: ['15', '16.2'],
|
||||
files: ['src/api.js'],
|
||||
customContext: 'Additional context',
|
||||
includeProjectTree: true,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
```
|
||||
|
||||
### **FuzzyTaskSearch** (`scripts/modules/utils/fuzzyTaskSearch.js`)
|
||||
|
||||
- **Intelligent Task Discovery**:
|
||||
- ✅ DO: Use for automatic task relevance detection
|
||||
- ✅ DO: Configure search parameters based on use case context
|
||||
- ✅ DO: Implement purpose-based categorization for better matching
|
||||
- ✅ DO: Sort results by relevance score and task ID
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use FuzzyTaskSearch for intelligent task discovery
|
||||
import { FuzzyTaskSearch } from '../utils/fuzzyTaskSearch.js';
|
||||
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const searchResults = fuzzySearch.findRelevantTasks(query, {
|
||||
maxResults: 8,
|
||||
includeRecent: true,
|
||||
includeCategoryMatches: true
|
||||
});
|
||||
const taskIds = fuzzySearch.getTaskIds(searchResults);
|
||||
```
|
||||
|
||||
- **Integration Guidelines**:
|
||||
- ✅ DO: Use fuzzy search to supplement user-provided task IDs
|
||||
- ✅ DO: Display discovered task IDs to users for transparency
|
||||
- ✅ DO: Sort discovered task IDs numerically for better readability
|
||||
- ❌ DON'T: Replace explicit user task selections with fuzzy results
|
||||
|
||||
Refer to [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for detailed implementation patterns, [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
33
.gitignore
vendored
33
.gitignore
vendored
@@ -19,13 +19,26 @@ npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
lerna-debug.log*
|
||||
tests/e2e/_runs/
|
||||
tests/e2e/log/
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
coverage
|
||||
coverage/
|
||||
*.lcov
|
||||
|
||||
# Jest cache
|
||||
.jest/
|
||||
|
||||
# Test temporary files and directories
|
||||
tests/temp/
|
||||
tests/e2e/_runs/
|
||||
tests/e2e/log/
|
||||
tests/**/*.log
|
||||
tests/**/coverage/
|
||||
|
||||
# Test database files (if any)
|
||||
tests/**/*.db
|
||||
tests/**/*.sqlite
|
||||
tests/**/*.sqlite3
|
||||
|
||||
# Optional npm cache directory
|
||||
.npm
|
||||
|
||||
@@ -64,3 +77,17 @@ dev-debug.log
|
||||
|
||||
# NPMRC
|
||||
.npmrc
|
||||
|
||||
# Added by Claude Task Master
|
||||
# Editor directories and files
|
||||
.idea
|
||||
.vscode
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
# OS specific
|
||||
# Task files
|
||||
tasks.json
|
||||
tasks/
|
||||
@@ -1,32 +1,37 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-sonnet-4-20250514",
|
||||
"maxTokens": 50000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 128000,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Taskmaster",
|
||||
"ollamaBaseURL": "http://localhost:11434/api",
|
||||
"userId": "1234567890",
|
||||
"azureBaseURL": "https://your-endpoint.azure.com/"
|
||||
}
|
||||
}
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-sonnet-4-20250514",
|
||||
"maxTokens": 64000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-5-sonnet-20241022",
|
||||
"maxTokens": 64000,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Taskmaster",
|
||||
"ollamaBaseURL": "http://localhost:11434/api",
|
||||
"azureBaseURL": "https://your-endpoint.azure.com/"
|
||||
},
|
||||
"account": {
|
||||
"userId": "1234567890",
|
||||
"email": "",
|
||||
"mode": "byok",
|
||||
"telemetryEnabled": true
|
||||
}
|
||||
}
|
||||
@@ -130,7 +130,10 @@ Use your AI assistant to:
|
||||
- Parse requirements: `Can you parse my PRD at scripts/prd.txt?`
|
||||
- Plan next step: `What’s the next task I should work on?`
|
||||
- Implement a task: `Can you help me implement task 3?`
|
||||
- View multiple tasks: `Can you show me tasks 1, 3, and 5?`
|
||||
- Expand a task: `Can you help me expand task 4?`
|
||||
- **Research fresh information**: `Research the latest best practices for implementing JWT authentication with Node.js`
|
||||
- **Research with context**: `Research React Query v5 migration strategies for our current API implementation in src/api.js`
|
||||
|
||||
[More examples on how to use Task Master in chat](docs/examples.md)
|
||||
|
||||
@@ -173,6 +176,12 @@ task-master list
|
||||
# Show the next task to work on
|
||||
task-master next
|
||||
|
||||
# Show specific task(s) - supports comma-separated IDs
|
||||
task-master show 1,3,5
|
||||
|
||||
# Research fresh information with project context
|
||||
task-master research "What are the latest best practices for JWT authentication?"
|
||||
|
||||
# Generate task files
|
||||
task-master generate
|
||||
```
|
||||
|
||||
@@ -1,31 +0,0 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 120000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-5-sonnet-20240620",
|
||||
"maxTokens": 8192,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Taskmaster",
|
||||
"ollamaBaseURL": "http://localhost:11434/api",
|
||||
"azureOpenaiBaseURL": "https://your-endpoint.openai.azure.com/"
|
||||
}
|
||||
}
|
||||
@@ -9,7 +9,7 @@ Welcome to the Task Master documentation. Use the links below to navigate to the
|
||||
|
||||
## Reference
|
||||
|
||||
- [Command Reference](command-reference.md) - Complete list of all available commands
|
||||
- [Command Reference](command-reference.md) - Complete list of all available commands (including research and multi-task viewing)
|
||||
- [Task Structure](task-structure.md) - Understanding the task format and features
|
||||
|
||||
## Examples & Licensing
|
||||
|
||||
@@ -43,10 +43,28 @@ task-master show <id>
|
||||
# or
|
||||
task-master show --id=<id>
|
||||
|
||||
# View multiple tasks with comma-separated IDs
|
||||
task-master show 1,3,5
|
||||
task-master show 44,55
|
||||
|
||||
# View a specific subtask (e.g., subtask 2 of task 1)
|
||||
task-master show 1.2
|
||||
|
||||
# Mix parent tasks and subtasks
|
||||
task-master show 44,44.1,55,55.2
|
||||
```
|
||||
|
||||
**Multiple Task Display:**
|
||||
|
||||
- **Single ID**: Shows detailed task view with full implementation details
|
||||
- **Multiple IDs**: Shows compact summary table with interactive action menu
|
||||
- **Action Menu**: Provides copy-paste ready commands for batch operations:
|
||||
- Mark all as in-progress/done
|
||||
- Show next available task
|
||||
- Expand all tasks (generate subtasks)
|
||||
- View dependency relationships
|
||||
- Generate task files
|
||||
|
||||
## Update Tasks
|
||||
|
||||
```bash
|
||||
@@ -262,3 +280,42 @@ task-master models --setup
|
||||
```
|
||||
|
||||
Configuration is stored in `.taskmasterconfig` in your project root. API keys are still managed via `.env` or MCP configuration. Use `task-master models` without flags to see available built-in models. Use `--setup` for a guided experience.
|
||||
|
||||
## Research Fresh Information
|
||||
|
||||
```bash
|
||||
# Perform AI-powered research with fresh, up-to-date information
|
||||
task-master research "What are the latest best practices for JWT authentication in Node.js?"
|
||||
|
||||
# Research with specific task context
|
||||
task-master research "How to implement OAuth 2.0?" --id=15,16
|
||||
|
||||
# Research with file context for code-aware suggestions
|
||||
task-master research "How can I optimize this API implementation?" --files=src/api.js,src/auth.js
|
||||
|
||||
# Research with custom context and project tree
|
||||
task-master research "Best practices for error handling" --context="We're using Express.js" --tree
|
||||
|
||||
# Research with different detail levels
|
||||
task-master research "React Query v5 migration guide" --detail=high
|
||||
|
||||
# Save research results to a file
|
||||
task-master research "Database optimization techniques" --save=research/db-optimization.md
|
||||
```
|
||||
|
||||
**The research command is a powerful tool that provides:**
|
||||
|
||||
- **Fresh information beyond AI knowledge cutoffs**
|
||||
- **Project-aware context** from your tasks and files
|
||||
- **Automatic task discovery** using fuzzy search
|
||||
- **Multiple detail levels** (low, medium, high)
|
||||
- **Token counting and cost tracking**
|
||||
- **Interactive follow-up questions**
|
||||
|
||||
**Use research frequently to:**
|
||||
|
||||
- Get current best practices before implementing features
|
||||
- Research new technologies and libraries
|
||||
- Find solutions to complex problems
|
||||
- Validate your implementation approaches
|
||||
- Stay updated with latest security recommendations
|
||||
|
||||
@@ -21,6 +21,20 @@ What's the next task I should work on? Please consider dependencies and prioriti
|
||||
I'd like to implement task 4. Can you help me understand what needs to be done and how to approach it?
|
||||
```
|
||||
|
||||
## Viewing multiple tasks
|
||||
|
||||
```
|
||||
Can you show me tasks 1, 3, and 5 so I can understand their relationship?
|
||||
```
|
||||
|
||||
```
|
||||
I need to see the status of tasks 44, 55, and their subtasks. Can you show me those?
|
||||
```
|
||||
|
||||
```
|
||||
Show me tasks 10, 12, and 15 and give me some batch actions I can perform on them.
|
||||
```
|
||||
|
||||
## Managing subtasks
|
||||
|
||||
```
|
||||
@@ -109,3 +123,56 @@ Please add a new task to implement user profile image uploads using Cloudinary,
|
||||
```
|
||||
|
||||
(Agent runs: `task-master add-task --prompt="Implement user profile image uploads using Cloudinary" --research`)
|
||||
|
||||
## Research-Driven Development
|
||||
|
||||
### Getting Fresh Information
|
||||
|
||||
```
|
||||
Research the latest best practices for implementing JWT authentication in Node.js applications.
|
||||
```
|
||||
|
||||
(Agent runs: `task-master research "Latest best practices for JWT authentication in Node.js"`)
|
||||
|
||||
### Research with Project Context
|
||||
|
||||
```
|
||||
I'm working on task 15 which involves API optimization. Can you research current best practices for our specific implementation?
|
||||
```
|
||||
|
||||
(Agent runs: `task-master research "API optimization best practices" --id=15 --files=src/api.js`)
|
||||
|
||||
### Research Before Implementation
|
||||
|
||||
```
|
||||
Before I implement task 8 (React Query integration), can you research the latest React Query v5 patterns and any breaking changes?
|
||||
```
|
||||
|
||||
(Agent runs: `task-master research "React Query v5 patterns and breaking changes" --id=8`)
|
||||
|
||||
### Research and Update Pattern
|
||||
|
||||
```
|
||||
Research the latest security recommendations for Express.js applications and update our authentication task with the findings.
|
||||
```
|
||||
|
||||
(Agent runs:
|
||||
|
||||
1. `task-master research "Latest Express.js security recommendations" --id=12`
|
||||
2. `task-master update-subtask --id=12.3 --prompt="Updated with latest security findings: [research results]"`)
|
||||
|
||||
### Research for Debugging
|
||||
|
||||
```
|
||||
I'm having issues with our WebSocket implementation in task 20. Can you research common WebSocket problems and solutions?
|
||||
```
|
||||
|
||||
(Agent runs: `task-master research "Common WebSocket implementation problems and solutions" --id=20 --files=src/websocket.js`)
|
||||
|
||||
### Research Technology Comparisons
|
||||
|
||||
```
|
||||
We need to choose between Redis and Memcached for caching. Can you research the current recommendations for our use case?
|
||||
```
|
||||
|
||||
(Agent runs: `task-master research "Redis vs Memcached 2024 comparison for session caching" --tree`)
|
||||
|
||||
@@ -198,10 +198,15 @@ Ask the agent to list available tasks:
|
||||
What tasks are available to work on next?
|
||||
```
|
||||
|
||||
```
|
||||
Can you show me tasks 1, 3, and 5 to understand their current status?
|
||||
```
|
||||
|
||||
The agent will:
|
||||
|
||||
- Run `task-master list` to see all tasks
|
||||
- Run `task-master next` to determine the next task to work on
|
||||
- Run `task-master show 1,3,5` to display multiple tasks with interactive options
|
||||
- Analyze dependencies to determine which tasks are ready to be worked on
|
||||
- Prioritize tasks based on priority level and ID order
|
||||
- Suggest the next task(s) to implement
|
||||
@@ -221,6 +226,21 @@ You can ask:
|
||||
Let's implement task 3. What does it involve?
|
||||
```
|
||||
|
||||
### 2.1. Viewing Multiple Tasks
|
||||
|
||||
For efficient context gathering and batch operations:
|
||||
|
||||
```
|
||||
Show me tasks 5, 7, and 9 so I can plan my implementation approach.
|
||||
```
|
||||
|
||||
The agent will:
|
||||
|
||||
- Run `task-master show 5,7,9` to display a compact summary table
|
||||
- Show task status, priority, and progress indicators
|
||||
- Provide an interactive action menu with batch operations
|
||||
- Allow you to perform group actions like marking multiple tasks as in-progress
|
||||
|
||||
### 3. Task Verification
|
||||
|
||||
Before marking a task as complete, verify it according to:
|
||||
@@ -423,3 +443,55 @@ Can you analyze the complexity of our tasks to help me understand which ones nee
|
||||
```
|
||||
Can you show me the complexity report in a more readable format?
|
||||
```
|
||||
|
||||
### Research-Driven Development
|
||||
|
||||
Task Master includes a powerful research tool that provides fresh, up-to-date information beyond the AI's knowledge cutoff. This is particularly valuable for:
|
||||
|
||||
#### Getting Current Best Practices
|
||||
|
||||
```
|
||||
Before implementing task 5 (authentication), research the latest JWT security recommendations.
|
||||
```
|
||||
|
||||
The agent will execute:
|
||||
|
||||
```bash
|
||||
task-master research "Latest JWT security recommendations 2024" --id=5
|
||||
```
|
||||
|
||||
#### Research with Project Context
|
||||
|
||||
```
|
||||
Research React Query v5 migration strategies for our current API implementation.
|
||||
```
|
||||
|
||||
The agent will execute:
|
||||
|
||||
```bash
|
||||
task-master research "React Query v5 migration strategies" --files=src/api.js,src/hooks.js
|
||||
```
|
||||
|
||||
#### Research and Update Pattern
|
||||
|
||||
A powerful workflow is to research first, then update tasks with findings:
|
||||
|
||||
```
|
||||
Research the latest Node.js performance optimization techniques and update task 12 with the findings.
|
||||
```
|
||||
|
||||
The agent will:
|
||||
|
||||
1. Run research: `task-master research "Node.js performance optimization 2024" --id=12`
|
||||
2. Update the task: `task-master update-subtask --id=12.2 --prompt="Updated with latest performance findings: [research results]"`
|
||||
|
||||
#### When to Use Research
|
||||
|
||||
- **Before implementing any new technology**
|
||||
- **When encountering security-related tasks**
|
||||
- **For performance optimization tasks**
|
||||
- **When debugging complex issues**
|
||||
- **Before making architectural decisions**
|
||||
- **When updating dependencies**
|
||||
|
||||
The research tool automatically includes relevant project context and provides fresh information that can significantly improve implementation quality.
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
export default {
|
||||
// Use Node.js environment for testing
|
||||
testEnvironment: 'node',
|
||||
// Use Node.js environment for testing
|
||||
testEnvironment: "node",
|
||||
|
||||
// Automatically clear mock calls between every test
|
||||
clearMocks: true,
|
||||
// Automatically clear mock calls between every test
|
||||
clearMocks: true,
|
||||
|
||||
// Indicates whether the coverage information should be collected while executing the test
|
||||
collectCoverage: false,
|
||||
// Indicates whether the coverage information should be collected while executing the test
|
||||
collectCoverage: false,
|
||||
|
||||
// The directory where Jest should output its coverage files
|
||||
coverageDirectory: 'coverage',
|
||||
// The directory where Jest should output its coverage files
|
||||
coverageDirectory: "coverage",
|
||||
|
||||
// A list of paths to directories that Jest should use to search for files in
|
||||
roots: ['<rootDir>/tests'],
|
||||
// A list of paths to directories that Jest should use to search for files in
|
||||
roots: ["<rootDir>/tests"],
|
||||
|
||||
// The glob patterns Jest uses to detect test files
|
||||
testMatch: ['**/__tests__/**/*.js', '**/?(*.)+(spec|test).js'],
|
||||
// The glob patterns Jest uses to detect test files
|
||||
testMatch: ["**/__tests__/**/*.js", "**/?(*.)+(spec|test).js"],
|
||||
|
||||
// Transform files
|
||||
transform: {},
|
||||
// Transform files
|
||||
transform: {},
|
||||
|
||||
// Disable transformations for node_modules
|
||||
transformIgnorePatterns: ['/node_modules/'],
|
||||
// Disable transformations for node_modules
|
||||
transformIgnorePatterns: ["/node_modules/"],
|
||||
|
||||
// Set moduleNameMapper for absolute paths
|
||||
moduleNameMapper: {
|
||||
'^@/(.*)$': '<rootDir>/$1'
|
||||
},
|
||||
// Set moduleNameMapper for absolute paths
|
||||
moduleNameMapper: {
|
||||
"^@/(.*)$": "<rootDir>/$1",
|
||||
},
|
||||
|
||||
// Setup module aliases
|
||||
moduleDirectories: ['node_modules', '<rootDir>'],
|
||||
// Setup module aliases
|
||||
moduleDirectories: ["node_modules", "<rootDir>"],
|
||||
|
||||
// Configure test coverage thresholds
|
||||
coverageThreshold: {
|
||||
global: {
|
||||
branches: 80,
|
||||
functions: 80,
|
||||
lines: 80,
|
||||
statements: 80
|
||||
}
|
||||
},
|
||||
// Configure test coverage thresholds
|
||||
coverageThreshold: {
|
||||
global: {
|
||||
branches: 80,
|
||||
functions: 80,
|
||||
lines: 80,
|
||||
statements: 80,
|
||||
},
|
||||
},
|
||||
|
||||
// Generate coverage report in these formats
|
||||
coverageReporters: ['text', 'lcov'],
|
||||
// Generate coverage report in these formats
|
||||
coverageReporters: ["text", "lcov"],
|
||||
|
||||
// Verbose output
|
||||
verbose: true,
|
||||
// Verbose output
|
||||
verbose: true,
|
||||
|
||||
// Setup file
|
||||
setupFilesAfterEnv: ['<rootDir>/tests/setup.js']
|
||||
// Setup file
|
||||
setupFilesAfterEnv: ["<rootDir>/tests/setup.js"],
|
||||
};
|
||||
|
||||
@@ -13,10 +13,11 @@ import {
|
||||
* Move a task or subtask to a new position
|
||||
* @param {Object} args - Function arguments
|
||||
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file
|
||||
* @param {string} args.sourceId - ID of the task/subtask to move (e.g., '5' or '5.2')
|
||||
* @param {string} args.destinationId - ID of the destination (e.g., '7' or '7.3')
|
||||
* @param {string} args.sourceId - ID of the task/subtask to move (e.g., '5' or '5.2' or '5,6,7')
|
||||
* @param {string} args.destinationId - ID of the destination (e.g., '7' or '7.3' or '7,8,9')
|
||||
* @param {string} args.file - Alternative path to the tasks.json file
|
||||
* @param {string} args.projectRoot - Project root directory
|
||||
* @param {boolean} args.generateFiles - Whether to regenerate task files after moving (default: true)
|
||||
* @param {Object} log - Logger object
|
||||
* @returns {Promise<{success: boolean, data?: Object, error?: Object}>}
|
||||
*/
|
||||
@@ -64,12 +65,13 @@ export async function moveTaskDirect(args, log, context = {}) {
|
||||
// Enable silent mode to prevent console output during MCP operation
|
||||
enableSilentMode();
|
||||
|
||||
// Call the core moveTask function, always generate files
|
||||
// Call the core moveTask function with file generation control
|
||||
const generateFiles = args.generateFiles !== false; // Default to true
|
||||
const result = await moveTask(
|
||||
tasksPath,
|
||||
args.sourceId,
|
||||
args.destinationId,
|
||||
true
|
||||
generateFiles
|
||||
);
|
||||
|
||||
// Restore console output
|
||||
@@ -78,7 +80,7 @@ export async function moveTaskDirect(args, log, context = {}) {
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
movedTask: result.movedTask,
|
||||
...result,
|
||||
message: `Successfully moved task/subtask ${args.sourceId} to ${args.destinationId}`
|
||||
}
|
||||
};
|
||||
|
||||
159
mcp-server/src/core/direct-functions/research.js
Normal file
159
mcp-server/src/core/direct-functions/research.js
Normal file
@@ -0,0 +1,159 @@
|
||||
/**
|
||||
* research.js
|
||||
* Direct function implementation for AI-powered research queries
|
||||
*/
|
||||
|
||||
import { performResearch } from '../../../../scripts/modules/task-manager.js';
|
||||
import {
|
||||
enableSilentMode,
|
||||
disableSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import { createLogWrapper } from '../../tools/utils.js';
|
||||
|
||||
/**
|
||||
* Direct function wrapper for performing AI-powered research with project context.
|
||||
*
|
||||
* @param {Object} args - Command arguments
|
||||
* @param {string} args.query - Research query/prompt (required)
|
||||
* @param {string} [args.taskIds] - Comma-separated list of task/subtask IDs for context
|
||||
* @param {string} [args.filePaths] - Comma-separated list of file paths for context
|
||||
* @param {string} [args.customContext] - Additional custom context text
|
||||
* @param {boolean} [args.includeProjectTree=false] - Include project file tree in context
|
||||
* @param {string} [args.detailLevel='medium'] - Detail level: 'low', 'medium', 'high'
|
||||
* @param {string} [args.projectRoot] - Project root path
|
||||
* @param {Object} log - Logger object
|
||||
* @param {Object} context - Additional context (session)
|
||||
* @returns {Promise<Object>} - Result object { success: boolean, data?: any, error?: { code: string, message: string } }
|
||||
*/
|
||||
export async function researchDirect(args, log, context = {}) {
|
||||
// Destructure expected args
|
||||
const {
|
||||
query,
|
||||
taskIds,
|
||||
filePaths,
|
||||
customContext,
|
||||
includeProjectTree = false,
|
||||
detailLevel = 'medium',
|
||||
projectRoot
|
||||
} = args;
|
||||
const { session } = context; // Destructure session from context
|
||||
|
||||
// Enable silent mode to prevent console logs from interfering with JSON response
|
||||
enableSilentMode();
|
||||
|
||||
// Create logger wrapper using the utility
|
||||
const mcpLog = createLogWrapper(log);
|
||||
|
||||
try {
|
||||
// Check required parameters
|
||||
if (!query || typeof query !== 'string' || query.trim().length === 0) {
|
||||
log.error('Missing or invalid required parameter: query');
|
||||
disableSilentMode();
|
||||
return {
|
||||
success: false,
|
||||
error: {
|
||||
code: 'MISSING_PARAMETER',
|
||||
message:
|
||||
'The query parameter is required and must be a non-empty string'
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
// Parse comma-separated task IDs if provided
|
||||
const parsedTaskIds = taskIds
|
||||
? taskIds
|
||||
.split(',')
|
||||
.map((id) => id.trim())
|
||||
.filter((id) => id.length > 0)
|
||||
: [];
|
||||
|
||||
// Parse comma-separated file paths if provided
|
||||
const parsedFilePaths = filePaths
|
||||
? filePaths
|
||||
.split(',')
|
||||
.map((path) => path.trim())
|
||||
.filter((path) => path.length > 0)
|
||||
: [];
|
||||
|
||||
// Validate detail level
|
||||
const validDetailLevels = ['low', 'medium', 'high'];
|
||||
if (!validDetailLevels.includes(detailLevel)) {
|
||||
log.error(`Invalid detail level: ${detailLevel}`);
|
||||
disableSilentMode();
|
||||
return {
|
||||
success: false,
|
||||
error: {
|
||||
code: 'INVALID_PARAMETER',
|
||||
message: `Detail level must be one of: ${validDetailLevels.join(', ')}`
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
log.info(
|
||||
`Performing research query: "${query.substring(0, 100)}${query.length > 100 ? '...' : ''}", ` +
|
||||
`taskIds: [${parsedTaskIds.join(', ')}], ` +
|
||||
`filePaths: [${parsedFilePaths.join(', ')}], ` +
|
||||
`detailLevel: ${detailLevel}, ` +
|
||||
`includeProjectTree: ${includeProjectTree}, ` +
|
||||
`projectRoot: ${projectRoot}`
|
||||
);
|
||||
|
||||
// Prepare options for the research function
|
||||
const researchOptions = {
|
||||
taskIds: parsedTaskIds,
|
||||
filePaths: parsedFilePaths,
|
||||
customContext: customContext || '',
|
||||
includeProjectTree,
|
||||
detailLevel,
|
||||
projectRoot
|
||||
};
|
||||
|
||||
// Prepare context for the research function
|
||||
const researchContext = {
|
||||
session,
|
||||
mcpLog,
|
||||
commandName: 'research',
|
||||
outputType: 'mcp'
|
||||
};
|
||||
|
||||
// Call the performResearch function
|
||||
const result = await performResearch(
|
||||
query.trim(),
|
||||
researchOptions,
|
||||
researchContext,
|
||||
'json', // outputFormat - use 'json' to suppress CLI UI
|
||||
false // allowFollowUp - disable for MCP calls
|
||||
);
|
||||
|
||||
// Restore normal logging
|
||||
disableSilentMode();
|
||||
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
query: result.query,
|
||||
result: result.result,
|
||||
contextSize: result.contextSize,
|
||||
contextTokens: result.contextTokens,
|
||||
tokenBreakdown: result.tokenBreakdown,
|
||||
systemPromptTokens: result.systemPromptTokens,
|
||||
userPromptTokens: result.userPromptTokens,
|
||||
totalInputTokens: result.totalInputTokens,
|
||||
detailLevel: result.detailLevel,
|
||||
telemetryData: result.telemetryData
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
// Make sure to restore normal logging even if there's an error
|
||||
disableSilentMode();
|
||||
|
||||
log.error(`Error in researchDirect: ${error.message}`);
|
||||
return {
|
||||
success: false,
|
||||
error: {
|
||||
code: error.code || 'RESEARCH_ERROR',
|
||||
message: error.message
|
||||
}
|
||||
};
|
||||
}
|
||||
}
|
||||
@@ -66,32 +66,91 @@ export async function showTaskDirect(args, log) {
|
||||
|
||||
const complexityReport = readComplexityReport(reportPath);
|
||||
|
||||
const { task, originalSubtaskCount } = findTaskById(
|
||||
tasksData.tasks,
|
||||
id,
|
||||
complexityReport,
|
||||
status
|
||||
);
|
||||
// Parse comma-separated IDs
|
||||
const taskIds = id
|
||||
.split(',')
|
||||
.map((taskId) => taskId.trim())
|
||||
.filter((taskId) => taskId.length > 0);
|
||||
|
||||
if (!task) {
|
||||
if (taskIds.length === 0) {
|
||||
return {
|
||||
success: false,
|
||||
error: {
|
||||
code: 'TASK_NOT_FOUND',
|
||||
message: `Task or subtask with ID ${id} not found`
|
||||
code: 'INVALID_TASK_ID',
|
||||
message: 'No valid task IDs provided'
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
log.info(`Successfully retrieved task ${id}.`);
|
||||
// Handle single task ID (existing behavior)
|
||||
if (taskIds.length === 1) {
|
||||
const { task, originalSubtaskCount } = findTaskById(
|
||||
tasksData.tasks,
|
||||
taskIds[0],
|
||||
complexityReport,
|
||||
status
|
||||
);
|
||||
|
||||
const returnData = { ...task };
|
||||
if (originalSubtaskCount !== null) {
|
||||
returnData._originalSubtaskCount = originalSubtaskCount;
|
||||
returnData._subtaskFilter = status;
|
||||
if (!task) {
|
||||
return {
|
||||
success: false,
|
||||
error: {
|
||||
code: 'TASK_NOT_FOUND',
|
||||
message: `Task or subtask with ID ${taskIds[0]} not found`
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
log.info(`Successfully retrieved task ${taskIds[0]}.`);
|
||||
|
||||
const returnData = { ...task };
|
||||
if (originalSubtaskCount !== null) {
|
||||
returnData._originalSubtaskCount = originalSubtaskCount;
|
||||
returnData._subtaskFilter = status;
|
||||
}
|
||||
|
||||
return { success: true, data: returnData };
|
||||
}
|
||||
|
||||
return { success: true, data: returnData };
|
||||
// Handle multiple task IDs
|
||||
const foundTasks = [];
|
||||
const notFoundIds = [];
|
||||
|
||||
taskIds.forEach((taskId) => {
|
||||
const { task, originalSubtaskCount } = findTaskById(
|
||||
tasksData.tasks,
|
||||
taskId,
|
||||
complexityReport,
|
||||
status
|
||||
);
|
||||
|
||||
if (task) {
|
||||
const taskData = { ...task };
|
||||
if (originalSubtaskCount !== null) {
|
||||
taskData._originalSubtaskCount = originalSubtaskCount;
|
||||
taskData._subtaskFilter = status;
|
||||
}
|
||||
foundTasks.push(taskData);
|
||||
} else {
|
||||
notFoundIds.push(taskId);
|
||||
}
|
||||
});
|
||||
|
||||
log.info(
|
||||
`Successfully retrieved ${foundTasks.length} of ${taskIds.length} requested tasks.`
|
||||
);
|
||||
|
||||
// Return multiple tasks with metadata
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
tasks: foundTasks,
|
||||
requestedIds: taskIds,
|
||||
foundCount: foundTasks.length,
|
||||
notFoundIds: notFoundIds,
|
||||
isMultiple: true
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log.error(`Error showing task ${id}: ${error.message}`);
|
||||
return {
|
||||
|
||||
@@ -31,6 +31,7 @@ import { removeTaskDirect } from './direct-functions/remove-task.js';
|
||||
import { initializeProjectDirect } from './direct-functions/initialize-project.js';
|
||||
import { modelsDirect } from './direct-functions/models.js';
|
||||
import { moveTaskDirect } from './direct-functions/move-task.js';
|
||||
import { researchDirect } from './direct-functions/research.js';
|
||||
|
||||
// Re-export utility functions
|
||||
export { findTasksJsonPath } from './utils/path-utils.js';
|
||||
@@ -62,7 +63,8 @@ export const directFunctions = new Map([
|
||||
['removeTaskDirect', removeTaskDirect],
|
||||
['initializeProjectDirect', initializeProjectDirect],
|
||||
['modelsDirect', modelsDirect],
|
||||
['moveTaskDirect', moveTaskDirect]
|
||||
['moveTaskDirect', moveTaskDirect],
|
||||
['researchDirect', researchDirect]
|
||||
]);
|
||||
|
||||
// Re-export all direct function implementations
|
||||
@@ -92,5 +94,6 @@ export {
|
||||
removeTaskDirect,
|
||||
initializeProjectDirect,
|
||||
modelsDirect,
|
||||
moveTaskDirect
|
||||
moveTaskDirect,
|
||||
researchDirect
|
||||
};
|
||||
|
||||
@@ -44,7 +44,11 @@ export function registerShowTaskTool(server) {
|
||||
name: 'get_task',
|
||||
description: 'Get detailed information about a specific task',
|
||||
parameters: z.object({
|
||||
id: z.string().describe('Task ID to get'),
|
||||
id: z
|
||||
.string()
|
||||
.describe(
|
||||
'Task ID(s) to get (can be comma-separated for multiple tasks)'
|
||||
),
|
||||
status: z
|
||||
.string()
|
||||
.optional()
|
||||
@@ -66,7 +70,7 @@ export function registerShowTaskTool(server) {
|
||||
'Absolute path to the project root directory (Optional, usually from session)'
|
||||
)
|
||||
}),
|
||||
execute: withNormalizedProjectRoot(async (args, { log }) => {
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
const { id, file, status, projectRoot } = args;
|
||||
|
||||
try {
|
||||
@@ -110,7 +114,8 @@ export function registerShowTaskTool(server) {
|
||||
status: status,
|
||||
projectRoot: projectRoot
|
||||
},
|
||||
log
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
|
||||
if (result.success) {
|
||||
|
||||
@@ -29,6 +29,7 @@ import { registerRemoveTaskTool } from './remove-task.js';
|
||||
import { registerInitializeProjectTool } from './initialize-project.js';
|
||||
import { registerModelsTool } from './models.js';
|
||||
import { registerMoveTaskTool } from './move-task.js';
|
||||
import { registerResearchTool } from './research.js';
|
||||
|
||||
/**
|
||||
* Register all Task Master tools with the MCP server
|
||||
@@ -74,6 +75,9 @@ export function registerTaskMasterTools(server) {
|
||||
registerRemoveDependencyTool(server);
|
||||
registerValidateDependenciesTool(server);
|
||||
registerFixDependenciesTool(server);
|
||||
|
||||
// Group 7: AI-Powered Features
|
||||
registerResearchTool(server);
|
||||
} catch (error) {
|
||||
logger.error(`Error registering Task Master tools: ${error.message}`);
|
||||
throw error;
|
||||
|
||||
@@ -41,83 +41,20 @@ export function registerMoveTaskTool(server) {
|
||||
}),
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
try {
|
||||
// Find tasks.json path if not provided
|
||||
let tasksJsonPath = args.file;
|
||||
// Let the core logic handle comma-separated IDs and validation
|
||||
const result = await moveTaskDirect(
|
||||
{
|
||||
sourceId: args.from,
|
||||
destinationId: args.to,
|
||||
file: args.file,
|
||||
projectRoot: args.projectRoot,
|
||||
generateFiles: true // Always generate files for MCP operations
|
||||
},
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
|
||||
if (!tasksJsonPath) {
|
||||
tasksJsonPath = findTasksJsonPath(args, log);
|
||||
}
|
||||
|
||||
// Parse comma-separated IDs
|
||||
const fromIds = args.from.split(',').map((id) => id.trim());
|
||||
const toIds = args.to.split(',').map((id) => id.trim());
|
||||
|
||||
// Validate matching IDs count
|
||||
if (fromIds.length !== toIds.length) {
|
||||
return createErrorResponse(
|
||||
'The number of source and destination IDs must match',
|
||||
'MISMATCHED_ID_COUNT'
|
||||
);
|
||||
}
|
||||
|
||||
// If moving multiple tasks
|
||||
if (fromIds.length > 1) {
|
||||
const results = [];
|
||||
// Move tasks one by one, only generate files on the last move
|
||||
for (let i = 0; i < fromIds.length; i++) {
|
||||
const fromId = fromIds[i];
|
||||
const toId = toIds[i];
|
||||
|
||||
// Skip if source and destination are the same
|
||||
if (fromId === toId) {
|
||||
log.info(`Skipping ${fromId} -> ${toId} (same ID)`);
|
||||
continue;
|
||||
}
|
||||
|
||||
const shouldGenerateFiles = i === fromIds.length - 1;
|
||||
const result = await moveTaskDirect(
|
||||
{
|
||||
sourceId: fromId,
|
||||
destinationId: toId,
|
||||
tasksJsonPath,
|
||||
projectRoot: args.projectRoot
|
||||
},
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
|
||||
if (!result.success) {
|
||||
log.error(
|
||||
`Failed to move ${fromId} to ${toId}: ${result.error.message}`
|
||||
);
|
||||
} else {
|
||||
results.push(result.data);
|
||||
}
|
||||
}
|
||||
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
moves: results,
|
||||
message: `Successfully moved ${results.length} tasks`
|
||||
}
|
||||
};
|
||||
} else {
|
||||
// Moving a single task
|
||||
return handleApiResult(
|
||||
await moveTaskDirect(
|
||||
{
|
||||
sourceId: args.from,
|
||||
destinationId: args.to,
|
||||
tasksJsonPath,
|
||||
projectRoot: args.projectRoot
|
||||
},
|
||||
log,
|
||||
{ session }
|
||||
),
|
||||
log
|
||||
);
|
||||
}
|
||||
return handleApiResult(result, log);
|
||||
} catch (error) {
|
||||
return createErrorResponse(
|
||||
`Failed to move task: ${error.message}`,
|
||||
|
||||
82
mcp-server/src/tools/research.js
Normal file
82
mcp-server/src/tools/research.js
Normal file
@@ -0,0 +1,82 @@
|
||||
/**
|
||||
* tools/research.js
|
||||
* Tool to perform AI-powered research queries with project context
|
||||
*/
|
||||
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
createErrorResponse,
|
||||
handleApiResult,
|
||||
withNormalizedProjectRoot
|
||||
} from './utils.js';
|
||||
import { researchDirect } from '../core/task-master-core.js';
|
||||
|
||||
/**
|
||||
* Register the research tool with the MCP server
|
||||
* @param {Object} server - FastMCP server instance
|
||||
*/
|
||||
export function registerResearchTool(server) {
|
||||
server.addTool({
|
||||
name: 'research',
|
||||
description: 'Perform AI-powered research queries with project context',
|
||||
parameters: z.object({
|
||||
query: z.string().describe('Research query/prompt (required)'),
|
||||
taskIds: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
'Comma-separated list of task/subtask IDs for context (e.g., "15,16.2,17")'
|
||||
),
|
||||
filePaths: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
'Comma-separated list of file paths for context (e.g., "src/api.js,docs/readme.md")'
|
||||
),
|
||||
customContext: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe('Additional custom context text to include in the research'),
|
||||
includeProjectTree: z
|
||||
.boolean()
|
||||
.optional()
|
||||
.describe(
|
||||
'Include project file tree structure in context (default: false)'
|
||||
),
|
||||
detailLevel: z
|
||||
.enum(['low', 'medium', 'high'])
|
||||
.optional()
|
||||
.describe('Detail level for the research response (default: medium)'),
|
||||
projectRoot: z
|
||||
.string()
|
||||
.describe('The directory of the project. Must be an absolute path.')
|
||||
}),
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
try {
|
||||
log.info(
|
||||
`Starting research with query: "${args.query.substring(0, 100)}${args.query.length > 100 ? '...' : ''}"`
|
||||
);
|
||||
|
||||
// Call the direct function
|
||||
const result = await researchDirect(
|
||||
{
|
||||
query: args.query,
|
||||
taskIds: args.taskIds,
|
||||
filePaths: args.filePaths,
|
||||
customContext: args.customContext,
|
||||
includeProjectTree: args.includeProjectTree || false,
|
||||
detailLevel: args.detailLevel || 'medium',
|
||||
projectRoot: args.projectRoot
|
||||
},
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
|
||||
return handleApiResult(result, log);
|
||||
} catch (error) {
|
||||
log.error(`Error in research tool: ${error.message}`);
|
||||
return createErrorResponse(error.message);
|
||||
}
|
||||
})
|
||||
});
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
23924
package-lock.json
generated
23924
package-lock.json
generated
File diff suppressed because it is too large
Load Diff
@@ -54,6 +54,7 @@
|
||||
"ai": "^4.3.10",
|
||||
"boxen": "^8.0.1",
|
||||
"chalk": "^5.4.1",
|
||||
"cli-highlight": "^2.1.11",
|
||||
"cli-table3": "^0.6.5",
|
||||
"commander": "^11.1.0",
|
||||
"cors": "^2.8.5",
|
||||
@@ -62,16 +63,20 @@
|
||||
"fastmcp": "^1.20.5",
|
||||
"figlet": "^1.8.0",
|
||||
"fuse.js": "^7.1.0",
|
||||
"gpt-tokens": "^1.3.14",
|
||||
"gradient-string": "^3.0.0",
|
||||
"helmet": "^8.1.0",
|
||||
"inquirer": "^12.5.0",
|
||||
"jsonwebtoken": "^9.0.2",
|
||||
"lru-cache": "^10.2.0",
|
||||
"ollama-ai-provider": "^1.2.0",
|
||||
"open": "^10.1.2",
|
||||
"openai": "^4.89.0",
|
||||
"ora": "^8.2.0",
|
||||
"task-master-ai": "^0.15.0",
|
||||
"uuid": "^11.1.0",
|
||||
"zod": "^3.23.8"
|
||||
"zod": "^3.23.8",
|
||||
"zod-to-json-schema": "^3.24.5"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=18.0.0"
|
||||
|
||||
1869
scripts/init.js
1869
scripts/init.js
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -24,6 +24,7 @@ import removeTask from './task-manager/remove-task.js';
|
||||
import taskExists from './task-manager/task-exists.js';
|
||||
import isTaskDependentOn from './task-manager/is-task-dependent.js';
|
||||
import moveTask from './task-manager/move-task.js';
|
||||
import { performResearch } from './task-manager/research.js';
|
||||
import { readComplexityReport } from './utils.js';
|
||||
// Export task manager functions
|
||||
export {
|
||||
@@ -48,5 +49,6 @@ export {
|
||||
taskExists,
|
||||
isTaskDependentOn,
|
||||
moveTask,
|
||||
performResearch,
|
||||
readComplexityReport
|
||||
};
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
747
scripts/modules/task-manager/research.js
Normal file
747
scripts/modules/task-manager/research.js
Normal file
@@ -0,0 +1,747 @@
|
||||
/**
|
||||
* research.js
|
||||
* Core research functionality for AI-powered queries with project context
|
||||
*/
|
||||
|
||||
import path from 'path';
|
||||
import chalk from 'chalk';
|
||||
import boxen from 'boxen';
|
||||
import inquirer from 'inquirer';
|
||||
import { highlight } from 'cli-highlight';
|
||||
import { ContextGatherer } from '../utils/contextGatherer.js';
|
||||
import { FuzzyTaskSearch } from '../utils/fuzzyTaskSearch.js';
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
import { log as consoleLog, findProjectRoot, readJSON } from '../utils.js';
|
||||
import {
|
||||
displayAiUsageSummary,
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator
|
||||
} from '../ui.js';
|
||||
|
||||
/**
|
||||
* Perform AI-powered research with project context
|
||||
* @param {string} query - Research query/prompt
|
||||
* @param {Object} options - Research options
|
||||
* @param {Array<string>} [options.taskIds] - Task/subtask IDs for context
|
||||
* @param {Array<string>} [options.filePaths] - File paths for context
|
||||
* @param {string} [options.customContext] - Additional custom context
|
||||
* @param {boolean} [options.includeProjectTree] - Include project file tree
|
||||
* @param {string} [options.detailLevel] - Detail level: 'low', 'medium', 'high'
|
||||
* @param {string} [options.projectRoot] - Project root directory
|
||||
* @param {Object} [context] - Execution context
|
||||
* @param {Object} [context.session] - MCP session object
|
||||
* @param {Object} [context.mcpLog] - MCP logger object
|
||||
* @param {string} [context.commandName] - Command name for telemetry
|
||||
* @param {string} [context.outputType] - Output type ('cli' or 'mcp')
|
||||
* @param {string} [outputFormat] - Output format ('text' or 'json')
|
||||
* @param {boolean} [allowFollowUp] - Whether to allow follow-up questions (default: true)
|
||||
* @returns {Promise<Object>} Research results with telemetry data
|
||||
*/
|
||||
async function performResearch(
|
||||
query,
|
||||
options = {},
|
||||
context = {},
|
||||
outputFormat = 'text',
|
||||
allowFollowUp = true
|
||||
) {
|
||||
const {
|
||||
taskIds = [],
|
||||
filePaths = [],
|
||||
customContext = '',
|
||||
includeProjectTree = false,
|
||||
detailLevel = 'medium',
|
||||
projectRoot: providedProjectRoot
|
||||
} = options;
|
||||
|
||||
const {
|
||||
session,
|
||||
mcpLog,
|
||||
commandName = 'research',
|
||||
outputType = 'cli'
|
||||
} = context;
|
||||
const isMCP = !!mcpLog;
|
||||
|
||||
// Determine project root
|
||||
const projectRoot = providedProjectRoot || findProjectRoot();
|
||||
if (!projectRoot) {
|
||||
throw new Error('Could not determine project root directory');
|
||||
}
|
||||
|
||||
// Create consistent logger
|
||||
const logFn = isMCP
|
||||
? mcpLog
|
||||
: {
|
||||
info: (...args) => consoleLog('info', ...args),
|
||||
warn: (...args) => consoleLog('warn', ...args),
|
||||
error: (...args) => consoleLog('error', ...args),
|
||||
debug: (...args) => consoleLog('debug', ...args),
|
||||
success: (...args) => consoleLog('success', ...args)
|
||||
};
|
||||
|
||||
// Show UI banner for CLI mode
|
||||
if (outputFormat === 'text') {
|
||||
console.log(
|
||||
boxen(chalk.cyan.bold(`🔍 AI Research Query`), {
|
||||
padding: 1,
|
||||
borderColor: 'cyan',
|
||||
borderStyle: 'round',
|
||||
margin: { top: 1, bottom: 1 }
|
||||
})
|
||||
);
|
||||
}
|
||||
|
||||
try {
|
||||
// Initialize context gatherer
|
||||
const contextGatherer = new ContextGatherer(projectRoot);
|
||||
|
||||
// Auto-discover relevant tasks using fuzzy search to supplement provided tasks
|
||||
let finalTaskIds = [...taskIds]; // Start with explicitly provided tasks
|
||||
let autoDiscoveredIds = [];
|
||||
|
||||
try {
|
||||
const tasksPath = path.join(projectRoot, 'tasks', 'tasks.json');
|
||||
const tasksData = await readJSON(tasksPath);
|
||||
|
||||
if (tasksData && tasksData.tasks && tasksData.tasks.length > 0) {
|
||||
// Flatten tasks to include subtasks for fuzzy search
|
||||
const flattenedTasks = flattenTasksWithSubtasks(tasksData.tasks);
|
||||
const fuzzySearch = new FuzzyTaskSearch(flattenedTasks, 'research');
|
||||
const searchResults = fuzzySearch.findRelevantTasks(query, {
|
||||
maxResults: 8,
|
||||
includeRecent: true,
|
||||
includeCategoryMatches: true
|
||||
});
|
||||
|
||||
autoDiscoveredIds = fuzzySearch.getTaskIds(searchResults);
|
||||
|
||||
// Remove any auto-discovered tasks that were already explicitly provided
|
||||
const uniqueAutoDiscovered = autoDiscoveredIds.filter(
|
||||
(id) => !finalTaskIds.includes(id)
|
||||
);
|
||||
|
||||
// Add unique auto-discovered tasks to the final list
|
||||
finalTaskIds = [...finalTaskIds, ...uniqueAutoDiscovered];
|
||||
|
||||
if (outputFormat === 'text' && finalTaskIds.length > 0) {
|
||||
// Sort task IDs numerically for better display
|
||||
const sortedTaskIds = finalTaskIds
|
||||
.map((id) => parseInt(id))
|
||||
.sort((a, b) => a - b)
|
||||
.map((id) => id.toString());
|
||||
|
||||
// Show different messages based on whether tasks were explicitly provided
|
||||
if (taskIds.length > 0) {
|
||||
const sortedProvidedIds = taskIds
|
||||
.map((id) => parseInt(id))
|
||||
.sort((a, b) => a - b)
|
||||
.map((id) => id.toString());
|
||||
|
||||
console.log(
|
||||
chalk.gray('Provided tasks: ') +
|
||||
chalk.cyan(sortedProvidedIds.join(', '))
|
||||
);
|
||||
|
||||
if (uniqueAutoDiscovered.length > 0) {
|
||||
const sortedAutoIds = uniqueAutoDiscovered
|
||||
.map((id) => parseInt(id))
|
||||
.sort((a, b) => a - b)
|
||||
.map((id) => id.toString());
|
||||
|
||||
console.log(
|
||||
chalk.gray('+ Auto-discovered related tasks: ') +
|
||||
chalk.cyan(sortedAutoIds.join(', '))
|
||||
);
|
||||
}
|
||||
} else {
|
||||
console.log(
|
||||
chalk.gray('Auto-discovered relevant tasks: ') +
|
||||
chalk.cyan(sortedTaskIds.join(', '))
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
// Silently continue without auto-discovered tasks if there's an error
|
||||
logFn.debug(`Could not auto-discover tasks: ${error.message}`);
|
||||
}
|
||||
|
||||
const contextResult = await contextGatherer.gather({
|
||||
tasks: finalTaskIds,
|
||||
files: filePaths,
|
||||
customContext,
|
||||
includeProjectTree,
|
||||
format: 'research', // Use research format for AI consumption
|
||||
includeTokenCounts: true
|
||||
});
|
||||
|
||||
const gatheredContext = contextResult.context;
|
||||
const tokenBreakdown = contextResult.tokenBreakdown;
|
||||
|
||||
// Build system prompt based on detail level
|
||||
const systemPrompt = buildResearchSystemPrompt(detailLevel, projectRoot);
|
||||
|
||||
// Build user prompt with context
|
||||
const userPrompt = buildResearchUserPrompt(
|
||||
query,
|
||||
gatheredContext,
|
||||
detailLevel
|
||||
);
|
||||
|
||||
// Count tokens for system and user prompts
|
||||
const systemPromptTokens = contextGatherer.countTokens(systemPrompt);
|
||||
const userPromptTokens = contextGatherer.countTokens(userPrompt);
|
||||
const totalInputTokens = systemPromptTokens + userPromptTokens;
|
||||
|
||||
if (outputFormat === 'text') {
|
||||
// Display detailed token breakdown in a clean box
|
||||
displayDetailedTokenBreakdown(
|
||||
tokenBreakdown,
|
||||
systemPromptTokens,
|
||||
userPromptTokens
|
||||
);
|
||||
}
|
||||
|
||||
// Only log detailed info in debug mode or MCP
|
||||
if (outputFormat !== 'text') {
|
||||
logFn.info(
|
||||
`Calling AI service with research role, context size: ${tokenBreakdown.total} tokens (${gatheredContext.length} characters)`
|
||||
);
|
||||
}
|
||||
|
||||
// Start loading indicator for CLI mode
|
||||
let loadingIndicator = null;
|
||||
if (outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator('Researching with AI...\n');
|
||||
}
|
||||
|
||||
let aiResult;
|
||||
try {
|
||||
// Call AI service with research role
|
||||
aiResult = await generateTextService({
|
||||
role: 'research', // Always use research role for research command
|
||||
session,
|
||||
projectRoot,
|
||||
systemPrompt,
|
||||
prompt: userPrompt,
|
||||
commandName,
|
||||
outputType
|
||||
});
|
||||
} catch (error) {
|
||||
if (loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
}
|
||||
throw error;
|
||||
} finally {
|
||||
if (loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
}
|
||||
}
|
||||
|
||||
const researchResult = aiResult.mainResult;
|
||||
const telemetryData = aiResult.telemetryData;
|
||||
|
||||
// Format and display results
|
||||
if (outputFormat === 'text') {
|
||||
displayResearchResults(
|
||||
researchResult,
|
||||
query,
|
||||
detailLevel,
|
||||
tokenBreakdown
|
||||
);
|
||||
|
||||
// Display AI usage telemetry for CLI users
|
||||
if (telemetryData) {
|
||||
displayAiUsageSummary(telemetryData, 'cli');
|
||||
}
|
||||
|
||||
// Offer follow-up question option (only for initial CLI queries, not MCP)
|
||||
if (allowFollowUp && !isMCP) {
|
||||
await handleFollowUpQuestions(
|
||||
options,
|
||||
context,
|
||||
outputFormat,
|
||||
projectRoot,
|
||||
logFn,
|
||||
query,
|
||||
researchResult
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
logFn.success('Research query completed successfully');
|
||||
|
||||
return {
|
||||
query,
|
||||
result: researchResult,
|
||||
contextSize: gatheredContext.length,
|
||||
contextTokens: tokenBreakdown.total,
|
||||
tokenBreakdown,
|
||||
systemPromptTokens,
|
||||
userPromptTokens,
|
||||
totalInputTokens,
|
||||
detailLevel,
|
||||
telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
logFn.error(`Research query failed: ${error.message}`);
|
||||
|
||||
if (outputFormat === 'text') {
|
||||
console.error(chalk.red(`\n❌ Research failed: ${error.message}`));
|
||||
}
|
||||
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Build system prompt for research based on detail level
|
||||
* @param {string} detailLevel - Detail level: 'low', 'medium', 'high'
|
||||
* @param {string} projectRoot - Project root for context
|
||||
* @returns {string} System prompt
|
||||
*/
|
||||
function buildResearchSystemPrompt(detailLevel, projectRoot) {
|
||||
const basePrompt = `You are an expert AI research assistant helping with a software development project. You have access to project context including tasks, files, and project structure.
|
||||
|
||||
Your role is to provide comprehensive, accurate, and actionable research responses based on the user's query and the provided project context.`;
|
||||
|
||||
const detailInstructions = {
|
||||
low: `
|
||||
**Response Style: Concise & Direct**
|
||||
- Provide brief, focused answers (2-4 paragraphs maximum)
|
||||
- Focus on the most essential information
|
||||
- Use bullet points for key takeaways
|
||||
- Avoid lengthy explanations unless critical
|
||||
- Skip pleasantries, introductions, and conclusions
|
||||
- No phrases like "Based on your project context" or "I'll provide guidance"
|
||||
- No summary outros or alignment statements
|
||||
- Get straight to the actionable information
|
||||
- Use simple, direct language - users want info, not explanation`,
|
||||
|
||||
medium: `
|
||||
**Response Style: Balanced & Comprehensive**
|
||||
- Provide thorough but well-structured responses (4-8 paragraphs)
|
||||
- Include relevant examples and explanations
|
||||
- Balance depth with readability
|
||||
- Use headings and bullet points for organization`,
|
||||
|
||||
high: `
|
||||
**Response Style: Detailed & Exhaustive**
|
||||
- Provide comprehensive, in-depth analysis (8+ paragraphs)
|
||||
- Include multiple perspectives and approaches
|
||||
- Provide detailed examples, code snippets, and step-by-step guidance
|
||||
- Cover edge cases and potential pitfalls
|
||||
- Use clear structure with headings, subheadings, and lists`
|
||||
};
|
||||
|
||||
return `${basePrompt}
|
||||
|
||||
${detailInstructions[detailLevel]}
|
||||
|
||||
**Guidelines:**
|
||||
- Always consider the project context when formulating responses
|
||||
- Reference specific tasks, files, or project elements when relevant
|
||||
- Provide actionable insights that can be applied to the project
|
||||
- If the query relates to existing project tasks, suggest how the research applies to those tasks
|
||||
- Use markdown formatting for better readability
|
||||
- Be precise and avoid speculation unless clearly marked as such
|
||||
|
||||
**For LOW detail level specifically:**
|
||||
- Start immediately with the core information
|
||||
- No introductory phrases or context acknowledgments
|
||||
- No concluding summaries or project alignment statements
|
||||
- Focus purely on facts, steps, and actionable items`;
|
||||
}
|
||||
|
||||
/**
|
||||
* Build user prompt with query and context
|
||||
* @param {string} query - User's research query
|
||||
* @param {string} gatheredContext - Gathered project context
|
||||
* @param {string} detailLevel - Detail level for response guidance
|
||||
* @returns {string} Complete user prompt
|
||||
*/
|
||||
function buildResearchUserPrompt(query, gatheredContext, detailLevel) {
|
||||
let prompt = `# Research Query
|
||||
|
||||
${query}`;
|
||||
|
||||
if (gatheredContext && gatheredContext.trim()) {
|
||||
prompt += `
|
||||
|
||||
# Project Context
|
||||
|
||||
${gatheredContext}`;
|
||||
}
|
||||
|
||||
prompt += `
|
||||
|
||||
# Instructions
|
||||
|
||||
Please research and provide a ${detailLevel}-detail response to the query above. Consider the project context provided and make your response as relevant and actionable as possible for this specific project.`;
|
||||
|
||||
return prompt;
|
||||
}
|
||||
|
||||
/**
|
||||
* Display detailed token breakdown for context and prompts
|
||||
* @param {Object} tokenBreakdown - Token breakdown from context gatherer
|
||||
* @param {number} systemPromptTokens - System prompt token count
|
||||
* @param {number} userPromptTokens - User prompt token count
|
||||
*/
|
||||
function displayDetailedTokenBreakdown(
|
||||
tokenBreakdown,
|
||||
systemPromptTokens,
|
||||
userPromptTokens
|
||||
) {
|
||||
const parts = [];
|
||||
|
||||
// Custom context
|
||||
if (tokenBreakdown.customContext) {
|
||||
parts.push(
|
||||
chalk.cyan('Custom: ') +
|
||||
chalk.yellow(tokenBreakdown.customContext.tokens.toLocaleString())
|
||||
);
|
||||
}
|
||||
|
||||
// Tasks breakdown
|
||||
if (tokenBreakdown.tasks && tokenBreakdown.tasks.length > 0) {
|
||||
const totalTaskTokens = tokenBreakdown.tasks.reduce(
|
||||
(sum, task) => sum + task.tokens,
|
||||
0
|
||||
);
|
||||
const taskDetails = tokenBreakdown.tasks
|
||||
.map((task) => {
|
||||
const titleDisplay =
|
||||
task.title.length > 30
|
||||
? task.title.substring(0, 30) + '...'
|
||||
: task.title;
|
||||
return ` ${chalk.gray(task.id)} ${chalk.white(titleDisplay)} ${chalk.yellow(task.tokens.toLocaleString())} tokens`;
|
||||
})
|
||||
.join('\n');
|
||||
|
||||
parts.push(
|
||||
chalk.cyan('Tasks: ') +
|
||||
chalk.yellow(totalTaskTokens.toLocaleString()) +
|
||||
chalk.gray(` (${tokenBreakdown.tasks.length} items)`) +
|
||||
'\n' +
|
||||
taskDetails
|
||||
);
|
||||
}
|
||||
|
||||
// Files breakdown
|
||||
if (tokenBreakdown.files && tokenBreakdown.files.length > 0) {
|
||||
const totalFileTokens = tokenBreakdown.files.reduce(
|
||||
(sum, file) => sum + file.tokens,
|
||||
0
|
||||
);
|
||||
const fileDetails = tokenBreakdown.files
|
||||
.map((file) => {
|
||||
const pathDisplay =
|
||||
file.path.length > 40
|
||||
? '...' + file.path.substring(file.path.length - 37)
|
||||
: file.path;
|
||||
return ` ${chalk.gray(pathDisplay)} ${chalk.yellow(file.tokens.toLocaleString())} tokens ${chalk.gray(`(${file.sizeKB}KB)`)}`;
|
||||
})
|
||||
.join('\n');
|
||||
|
||||
parts.push(
|
||||
chalk.cyan('Files: ') +
|
||||
chalk.yellow(totalFileTokens.toLocaleString()) +
|
||||
chalk.gray(` (${tokenBreakdown.files.length} files)`) +
|
||||
'\n' +
|
||||
fileDetails
|
||||
);
|
||||
}
|
||||
|
||||
// Project tree
|
||||
if (tokenBreakdown.projectTree) {
|
||||
parts.push(
|
||||
chalk.cyan('Project Tree: ') +
|
||||
chalk.yellow(tokenBreakdown.projectTree.tokens.toLocaleString()) +
|
||||
chalk.gray(
|
||||
` (${tokenBreakdown.projectTree.fileCount} files, ${tokenBreakdown.projectTree.dirCount} dirs)`
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
// Prompts breakdown
|
||||
const totalPromptTokens = systemPromptTokens + userPromptTokens;
|
||||
const promptDetails = [
|
||||
` ${chalk.gray('System:')} ${chalk.yellow(systemPromptTokens.toLocaleString())} tokens`,
|
||||
` ${chalk.gray('User:')} ${chalk.yellow(userPromptTokens.toLocaleString())} tokens`
|
||||
].join('\n');
|
||||
|
||||
parts.push(
|
||||
chalk.cyan('Prompts: ') +
|
||||
chalk.yellow(totalPromptTokens.toLocaleString()) +
|
||||
chalk.gray(' (generated)') +
|
||||
'\n' +
|
||||
promptDetails
|
||||
);
|
||||
|
||||
// Display the breakdown in a clean box
|
||||
if (parts.length > 0) {
|
||||
const content = parts.join('\n\n');
|
||||
const tokenBox = boxen(content, {
|
||||
title: chalk.blue.bold('Context Analysis'),
|
||||
titleAlignment: 'left',
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'blue'
|
||||
});
|
||||
console.log(tokenBox);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Process research result text to highlight code blocks
|
||||
* @param {string} text - Raw research result text
|
||||
* @returns {string} Processed text with highlighted code blocks
|
||||
*/
|
||||
function processCodeBlocks(text) {
|
||||
// Regex to match code blocks with optional language specification
|
||||
const codeBlockRegex = /```(\w+)?\n([\s\S]*?)```/g;
|
||||
|
||||
return text.replace(codeBlockRegex, (match, language, code) => {
|
||||
try {
|
||||
// Default to javascript if no language specified
|
||||
const lang = language || 'javascript';
|
||||
|
||||
// Highlight the code using cli-highlight
|
||||
const highlightedCode = highlight(code.trim(), {
|
||||
language: lang,
|
||||
ignoreIllegals: true // Don't fail on unrecognized syntax
|
||||
});
|
||||
|
||||
// Add a subtle border around code blocks
|
||||
const codeBox = boxen(highlightedCode, {
|
||||
padding: { top: 0, bottom: 0, left: 1, right: 1 },
|
||||
margin: { top: 0, bottom: 0 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'dim'
|
||||
});
|
||||
|
||||
return '\n' + codeBox + '\n';
|
||||
} catch (error) {
|
||||
// If highlighting fails, return the original code block with basic formatting
|
||||
return (
|
||||
'\n' +
|
||||
chalk.gray('```' + (language || '')) +
|
||||
'\n' +
|
||||
chalk.white(code.trim()) +
|
||||
'\n' +
|
||||
chalk.gray('```') +
|
||||
'\n'
|
||||
);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Display research results in formatted output
|
||||
* @param {string} result - AI research result
|
||||
* @param {string} query - Original query
|
||||
* @param {string} detailLevel - Detail level used
|
||||
* @param {Object} tokenBreakdown - Detailed token usage
|
||||
*/
|
||||
function displayResearchResults(result, query, detailLevel, tokenBreakdown) {
|
||||
// Header with query info
|
||||
const header = boxen(
|
||||
chalk.green.bold('Research Results') +
|
||||
'\n\n' +
|
||||
chalk.gray('Query: ') +
|
||||
chalk.white(query) +
|
||||
'\n' +
|
||||
chalk.gray('Detail Level: ') +
|
||||
chalk.cyan(detailLevel),
|
||||
{
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 1, bottom: 0 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'green'
|
||||
}
|
||||
);
|
||||
console.log(header);
|
||||
|
||||
// Process the result to highlight code blocks
|
||||
const processedResult = processCodeBlocks(result);
|
||||
|
||||
// Main research content in a clean box
|
||||
const contentBox = boxen(processedResult, {
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'gray'
|
||||
});
|
||||
console.log(contentBox);
|
||||
|
||||
// Success footer
|
||||
console.log(chalk.green('✅ Research completed'));
|
||||
}
|
||||
|
||||
/**
|
||||
* Flatten tasks array to include subtasks as individual searchable items
|
||||
* @param {Array} tasks - Array of task objects
|
||||
* @returns {Array} Flattened array including both tasks and subtasks
|
||||
*/
|
||||
function flattenTasksWithSubtasks(tasks) {
|
||||
const flattened = [];
|
||||
|
||||
for (const task of tasks) {
|
||||
// Add the main task
|
||||
flattened.push({
|
||||
...task,
|
||||
searchableId: task.id.toString(), // For consistent ID handling
|
||||
isSubtask: false
|
||||
});
|
||||
|
||||
// Add subtasks if they exist
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
for (const subtask of task.subtasks) {
|
||||
flattened.push({
|
||||
...subtask,
|
||||
searchableId: `${task.id}.${subtask.id}`, // Format: "15.2"
|
||||
isSubtask: true,
|
||||
parentId: task.id,
|
||||
parentTitle: task.title,
|
||||
// Enhance subtask context with parent information
|
||||
title: `${subtask.title} (subtask of: ${task.title})`,
|
||||
description: `${subtask.description} [Parent: ${task.description}]`
|
||||
});
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return flattened;
|
||||
}
|
||||
|
||||
/**
|
||||
* Handle follow-up questions in interactive mode
|
||||
* @param {Object} originalOptions - Original research options
|
||||
* @param {Object} context - Execution context
|
||||
* @param {string} outputFormat - Output format
|
||||
* @param {string} projectRoot - Project root directory
|
||||
* @param {Object} logFn - Logger function
|
||||
* @param {string} initialQuery - Initial query for context
|
||||
* @param {string} initialResult - Initial AI result for context
|
||||
*/
|
||||
async function handleFollowUpQuestions(
|
||||
originalOptions,
|
||||
context,
|
||||
outputFormat,
|
||||
projectRoot,
|
||||
logFn,
|
||||
initialQuery,
|
||||
initialResult
|
||||
) {
|
||||
try {
|
||||
// Initialize conversation history with the initial Q&A
|
||||
const conversationHistory = [
|
||||
{
|
||||
question: initialQuery,
|
||||
answer: initialResult,
|
||||
type: 'initial'
|
||||
}
|
||||
];
|
||||
|
||||
while (true) {
|
||||
// Ask if user wants to ask a follow-up question
|
||||
const { wantFollowUp } = await inquirer.prompt([
|
||||
{
|
||||
type: 'confirm',
|
||||
name: 'wantFollowUp',
|
||||
message: 'Would you like to ask a follow-up question?',
|
||||
default: false // Default to 'n' as requested
|
||||
}
|
||||
]);
|
||||
|
||||
if (!wantFollowUp) {
|
||||
break;
|
||||
}
|
||||
|
||||
// Get the follow-up question
|
||||
const { followUpQuery } = await inquirer.prompt([
|
||||
{
|
||||
type: 'input',
|
||||
name: 'followUpQuery',
|
||||
message: 'Enter your follow-up question:',
|
||||
validate: (input) => {
|
||||
if (!input || input.trim().length === 0) {
|
||||
return 'Please enter a valid question.';
|
||||
}
|
||||
return true;
|
||||
}
|
||||
}
|
||||
]);
|
||||
|
||||
if (!followUpQuery || followUpQuery.trim().length === 0) {
|
||||
continue;
|
||||
}
|
||||
|
||||
console.log('\n' + chalk.gray('─'.repeat(60)) + '\n');
|
||||
|
||||
// Build cumulative conversation context from all previous exchanges
|
||||
const conversationContext = buildConversationContext(conversationHistory);
|
||||
|
||||
// Create enhanced options for follow-up with full conversation context
|
||||
// Remove explicit task IDs to allow fresh fuzzy search based on new question
|
||||
const followUpOptions = {
|
||||
...originalOptions,
|
||||
taskIds: [], // Clear task IDs to allow fresh fuzzy search
|
||||
customContext:
|
||||
conversationContext +
|
||||
(originalOptions.customContext
|
||||
? `\n\n--- Original Context ---\n${originalOptions.customContext}`
|
||||
: '')
|
||||
};
|
||||
|
||||
// Perform follow-up research with fresh fuzzy search and conversation context
|
||||
// Disable follow-up prompts for nested calls to prevent infinite recursion
|
||||
const followUpResult = await performResearch(
|
||||
followUpQuery.trim(),
|
||||
followUpOptions,
|
||||
context,
|
||||
outputFormat,
|
||||
false // allowFollowUp = false for nested calls
|
||||
);
|
||||
|
||||
// Add this exchange to the conversation history
|
||||
conversationHistory.push({
|
||||
question: followUpQuery.trim(),
|
||||
answer: followUpResult.result,
|
||||
type: 'followup'
|
||||
});
|
||||
}
|
||||
} catch (error) {
|
||||
// If there's an error with inquirer (e.g., non-interactive terminal),
|
||||
// silently continue without follow-up functionality
|
||||
logFn.debug(`Follow-up questions not available: ${error.message}`);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Build conversation context string from conversation history
|
||||
* @param {Array} conversationHistory - Array of conversation exchanges
|
||||
* @returns {string} Formatted conversation context
|
||||
*/
|
||||
function buildConversationContext(conversationHistory) {
|
||||
if (conversationHistory.length === 0) {
|
||||
return '';
|
||||
}
|
||||
|
||||
const contextParts = ['--- Conversation History ---'];
|
||||
|
||||
conversationHistory.forEach((exchange, index) => {
|
||||
const questionLabel =
|
||||
exchange.type === 'initial' ? 'Initial Question' : `Follow-up ${index}`;
|
||||
const answerLabel =
|
||||
exchange.type === 'initial' ? 'Initial Answer' : `Answer ${index}`;
|
||||
|
||||
contextParts.push(`\n${questionLabel}: ${exchange.question}`);
|
||||
contextParts.push(`${answerLabel}: ${exchange.answer}`);
|
||||
});
|
||||
|
||||
return contextParts.join('\n');
|
||||
}
|
||||
|
||||
export { performResearch };
|
||||
384
scripts/modules/telemetry-queue.js
Normal file
384
scripts/modules/telemetry-queue.js
Normal file
@@ -0,0 +1,384 @@
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
import { submitTelemetryData } from "./telemetry-submission.js";
|
||||
import { getDebugFlag } from "./config-manager.js";
|
||||
import { log } from "./utils.js";
|
||||
|
||||
class TelemetryQueue {
|
||||
constructor() {
|
||||
this.queue = [];
|
||||
this.processing = false;
|
||||
this.backgroundInterval = null;
|
||||
this.stats = {
|
||||
pending: 0,
|
||||
processed: 0,
|
||||
failed: 0,
|
||||
lastProcessedAt: null,
|
||||
};
|
||||
this.logFile = null;
|
||||
}
|
||||
|
||||
/**
|
||||
* Initialize the queue with comprehensive logging file path
|
||||
* @param {string} projectRoot - Project root directory for log file
|
||||
*/
|
||||
initialize(projectRoot) {
|
||||
if (projectRoot) {
|
||||
this.logFile = path.join(projectRoot, ".taskmaster-activity.log");
|
||||
this.loadPersistedQueue();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Add telemetry data to queue without blocking
|
||||
* @param {Object} telemetryData - Command telemetry data
|
||||
*/
|
||||
addToQueue(telemetryData) {
|
||||
const queueItem = {
|
||||
...telemetryData,
|
||||
queuedAt: new Date().toISOString(),
|
||||
attempts: 0,
|
||||
};
|
||||
|
||||
this.queue.push(queueItem);
|
||||
this.stats.pending = this.queue.length;
|
||||
|
||||
// Log the activity immediately to .log file
|
||||
this.logActivity("QUEUED", {
|
||||
commandName: telemetryData.commandName,
|
||||
queuedAt: queueItem.queuedAt,
|
||||
userId: telemetryData.userId,
|
||||
success: telemetryData.success,
|
||||
executionTimeMs: telemetryData.executionTimeMs,
|
||||
});
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log("debug", `Added ${telemetryData.commandName} to telemetry queue`);
|
||||
}
|
||||
|
||||
// Persist queue state if file is configured
|
||||
this.persistQueue();
|
||||
}
|
||||
|
||||
/**
|
||||
* Log activity to comprehensive .log file
|
||||
* @param {string} action - The action being logged (QUEUED, SUBMITTED, FAILED, etc.)
|
||||
* @param {Object} data - The data to log
|
||||
*/
|
||||
logActivity(action, data) {
|
||||
if (!this.logFile) return;
|
||||
|
||||
try {
|
||||
const timestamp = new Date().toISOString();
|
||||
const logEntry = `${timestamp} [${action}] ${JSON.stringify(data)}\n`;
|
||||
|
||||
fs.appendFileSync(this.logFile, logEntry);
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log("error", `Failed to write to activity log: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Process all queued telemetry items
|
||||
* @returns {Object} Processing result with stats
|
||||
*/
|
||||
async processQueue() {
|
||||
if (this.processing || this.queue.length === 0) {
|
||||
return { processed: 0, failed: 0, errors: [] };
|
||||
}
|
||||
|
||||
this.processing = true;
|
||||
const errors = [];
|
||||
let processed = 0;
|
||||
let failed = 0;
|
||||
|
||||
this.logActivity("PROCESSING_START", { queueSize: this.queue.length });
|
||||
|
||||
// Process items in batches to avoid overwhelming the gateway
|
||||
const batchSize = 5;
|
||||
const itemsToProcess = [...this.queue];
|
||||
|
||||
for (let i = 0; i < itemsToProcess.length; i += batchSize) {
|
||||
const batch = itemsToProcess.slice(i, i + batchSize);
|
||||
|
||||
for (const item of batch) {
|
||||
try {
|
||||
item.attempts++;
|
||||
const result = await submitTelemetryData(item);
|
||||
|
||||
if (result.success) {
|
||||
// Remove from queue on success
|
||||
const index = this.queue.findIndex(
|
||||
(q) => q.queuedAt === item.queuedAt
|
||||
);
|
||||
if (index > -1) {
|
||||
this.queue.splice(index, 1);
|
||||
}
|
||||
processed++;
|
||||
|
||||
// Log successful submission
|
||||
this.logActivity("SUBMITTED", {
|
||||
commandName: item.commandName,
|
||||
queuedAt: item.queuedAt,
|
||||
attempts: item.attempts,
|
||||
});
|
||||
} else {
|
||||
// Retry failed items up to 3 times
|
||||
if (item.attempts >= 3) {
|
||||
const index = this.queue.findIndex(
|
||||
(q) => q.queuedAt === item.queuedAt
|
||||
);
|
||||
if (index > -1) {
|
||||
this.queue.splice(index, 1);
|
||||
}
|
||||
failed++;
|
||||
const errorMsg = `Failed to submit ${item.commandName} after 3 attempts: ${result.error}`;
|
||||
errors.push(errorMsg);
|
||||
|
||||
// Log final failure
|
||||
this.logActivity("FAILED", {
|
||||
commandName: item.commandName,
|
||||
queuedAt: item.queuedAt,
|
||||
attempts: item.attempts,
|
||||
error: result.error,
|
||||
});
|
||||
} else {
|
||||
// Log retry attempt
|
||||
this.logActivity("RETRY", {
|
||||
commandName: item.commandName,
|
||||
queuedAt: item.queuedAt,
|
||||
attempts: item.attempts,
|
||||
error: result.error,
|
||||
});
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
// Network or unexpected errors
|
||||
if (item.attempts >= 3) {
|
||||
const index = this.queue.findIndex(
|
||||
(q) => q.queuedAt === item.queuedAt
|
||||
);
|
||||
if (index > -1) {
|
||||
this.queue.splice(index, 1);
|
||||
}
|
||||
failed++;
|
||||
const errorMsg = `Exception submitting ${item.commandName}: ${error.message}`;
|
||||
errors.push(errorMsg);
|
||||
|
||||
// Log exception failure
|
||||
this.logActivity("EXCEPTION", {
|
||||
commandName: item.commandName,
|
||||
queuedAt: item.queuedAt,
|
||||
attempts: item.attempts,
|
||||
error: error.message,
|
||||
});
|
||||
} else {
|
||||
// Log retry for exception
|
||||
this.logActivity("RETRY_EXCEPTION", {
|
||||
commandName: item.commandName,
|
||||
queuedAt: item.queuedAt,
|
||||
attempts: item.attempts,
|
||||
error: error.message,
|
||||
});
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Small delay between batches
|
||||
if (i + batchSize < itemsToProcess.length) {
|
||||
await new Promise((resolve) => setTimeout(resolve, 100));
|
||||
}
|
||||
}
|
||||
|
||||
this.stats.pending = this.queue.length;
|
||||
this.stats.processed += processed;
|
||||
this.stats.failed += failed;
|
||||
this.stats.lastProcessedAt = new Date().toISOString();
|
||||
|
||||
this.processing = false;
|
||||
this.persistQueue();
|
||||
|
||||
// Log processing completion
|
||||
this.logActivity("PROCESSING_COMPLETE", {
|
||||
processed,
|
||||
failed,
|
||||
remainingInQueue: this.queue.length,
|
||||
});
|
||||
|
||||
if (getDebugFlag() && (processed > 0 || failed > 0)) {
|
||||
log(
|
||||
"debug",
|
||||
`Telemetry queue processed: ${processed} success, ${failed} failed`
|
||||
);
|
||||
}
|
||||
|
||||
return { processed, failed, errors };
|
||||
}
|
||||
|
||||
/**
|
||||
* Start background processing at specified interval
|
||||
* @param {number} intervalMs - Processing interval in milliseconds (default: 30000)
|
||||
*/
|
||||
startBackgroundProcessor(intervalMs = 30000) {
|
||||
if (this.backgroundInterval) {
|
||||
clearInterval(this.backgroundInterval);
|
||||
}
|
||||
|
||||
this.backgroundInterval = setInterval(async () => {
|
||||
try {
|
||||
await this.processQueue();
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
"error",
|
||||
`Background telemetry processing error: ${error.message}`
|
||||
);
|
||||
}
|
||||
}
|
||||
}, intervalMs);
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
"debug",
|
||||
`Started telemetry background processor (${intervalMs}ms interval)`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Stop background processing
|
||||
*/
|
||||
stopBackgroundProcessor() {
|
||||
if (this.backgroundInterval) {
|
||||
clearInterval(this.backgroundInterval);
|
||||
this.backgroundInterval = null;
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log("debug", "Stopped telemetry background processor");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Get queue statistics
|
||||
* @returns {Object} Queue stats
|
||||
*/
|
||||
getQueueStats() {
|
||||
return {
|
||||
...this.stats,
|
||||
pending: this.queue.length,
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Load persisted queue from file (now reads from .log file)
|
||||
*/
|
||||
loadPersistedQueue() {
|
||||
// For the .log file, we'll look for a companion .json file for queue state
|
||||
if (!this.logFile) return;
|
||||
|
||||
const stateFile = this.logFile.replace(".log", "-queue-state.json");
|
||||
if (!fs.existsSync(stateFile)) {
|
||||
return;
|
||||
}
|
||||
|
||||
try {
|
||||
const data = fs.readFileSync(stateFile, "utf8");
|
||||
const persistedData = JSON.parse(data);
|
||||
|
||||
this.queue = persistedData.queue || [];
|
||||
this.stats = { ...this.stats, ...persistedData.stats };
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
"debug",
|
||||
`Loaded ${this.queue.length} items from telemetry queue state`
|
||||
);
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
"error",
|
||||
`Failed to load persisted telemetry queue: ${error.message}`
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Persist queue state to companion file
|
||||
*/
|
||||
persistQueue() {
|
||||
if (!this.logFile) return;
|
||||
|
||||
const stateFile = this.logFile.replace(".log", "-queue-state.json");
|
||||
|
||||
try {
|
||||
const data = {
|
||||
queue: this.queue,
|
||||
stats: this.stats,
|
||||
lastUpdated: new Date().toISOString(),
|
||||
};
|
||||
|
||||
fs.writeFileSync(stateFile, JSON.stringify(data, null, 2));
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log("error", `Failed to persist telemetry queue: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Global instance
|
||||
const telemetryQueue = new TelemetryQueue();
|
||||
|
||||
/**
|
||||
* Add command telemetry to queue (non-blocking)
|
||||
* @param {Object} commandData - Command execution data
|
||||
*/
|
||||
export function queueCommandTelemetry(commandData) {
|
||||
telemetryQueue.addToQueue(commandData);
|
||||
}
|
||||
|
||||
/**
|
||||
* Initialize telemetry queue with project root
|
||||
* @param {string} projectRoot - Project root directory
|
||||
*/
|
||||
export function initializeTelemetryQueue(projectRoot) {
|
||||
telemetryQueue.initialize(projectRoot);
|
||||
}
|
||||
|
||||
/**
|
||||
* Start background telemetry processing
|
||||
* @param {number} intervalMs - Processing interval in milliseconds
|
||||
*/
|
||||
export function startTelemetryBackgroundProcessor(intervalMs = 30000) {
|
||||
telemetryQueue.startBackgroundProcessor(intervalMs);
|
||||
}
|
||||
|
||||
/**
|
||||
* Stop background telemetry processing
|
||||
*/
|
||||
export function stopTelemetryBackgroundProcessor() {
|
||||
telemetryQueue.stopBackgroundProcessor();
|
||||
}
|
||||
|
||||
/**
|
||||
* Get telemetry queue statistics
|
||||
* @returns {Object} Queue statistics
|
||||
*/
|
||||
export function getTelemetryQueueStats() {
|
||||
return telemetryQueue.getQueueStats();
|
||||
}
|
||||
|
||||
/**
|
||||
* Manually process telemetry queue
|
||||
* @returns {Object} Processing result
|
||||
*/
|
||||
export function processTelemetryQueue() {
|
||||
return telemetryQueue.processQueue();
|
||||
}
|
||||
|
||||
export { telemetryQueue };
|
||||
238
scripts/modules/telemetry-submission.js
Normal file
238
scripts/modules/telemetry-submission.js
Normal file
@@ -0,0 +1,238 @@
|
||||
/**
|
||||
* Telemetry Submission Service
|
||||
* Handles sending telemetry data to remote gateway endpoint
|
||||
*/
|
||||
|
||||
import { z } from "zod";
|
||||
import { getConfig } from "./config-manager.js";
|
||||
import { getTelemetryEnabled } from "./config-manager.js";
|
||||
import { resolveEnvVariable } from "./utils.js";
|
||||
|
||||
// Telemetry data validation schema
|
||||
const TelemetryDataSchema = z.object({
|
||||
timestamp: z.string().datetime(),
|
||||
userId: z.string().min(1),
|
||||
commandName: z.string().min(1),
|
||||
modelUsed: z.string().optional(),
|
||||
providerName: z.string().optional(),
|
||||
inputTokens: z.number().optional(),
|
||||
outputTokens: z.number().optional(),
|
||||
totalTokens: z.number().optional(),
|
||||
totalCost: z.number().optional(),
|
||||
currency: z.string().optional(),
|
||||
commandArgs: z.any().optional(),
|
||||
fullOutput: z.any().optional(),
|
||||
});
|
||||
|
||||
// Hardcoded configuration for TaskMaster telemetry gateway
|
||||
const TASKMASTER_BASE_URL = "http://localhost:4444";
|
||||
const TASKMASTER_TELEMETRY_ENDPOINT = `${TASKMASTER_BASE_URL}/api/v1/telemetry`;
|
||||
const TASKMASTER_USER_REGISTRATION_ENDPOINT = `${TASKMASTER_BASE_URL}/auth/init`;
|
||||
const MAX_RETRIES = 3;
|
||||
const RETRY_DELAY = 1000; // 1 second
|
||||
|
||||
/**
|
||||
* Get telemetry configuration from hardcoded service ID, user token, and config
|
||||
* @returns {Object} Configuration object with serviceId, apiKey, userId, and email
|
||||
*/
|
||||
function getTelemetryConfig() {
|
||||
// Get the config which contains userId and email
|
||||
const config = getConfig();
|
||||
|
||||
// Hardcoded service ID for TaskMaster telemetry service
|
||||
const hardcodedServiceId = "98fb3198-2dfc-42d1-af53-07b99e4f3bde";
|
||||
|
||||
// Get user's API token from .env (managed by user-management.js)
|
||||
const userApiKey = resolveEnvVariable("TASKMASTER_API_KEY");
|
||||
|
||||
return {
|
||||
serviceId: hardcodedServiceId, // Hardcoded service identifier
|
||||
apiKey: userApiKey || null, // User's Bearer token from .env
|
||||
userId: config?.account?.userId || null, // From config
|
||||
email: config?.account?.email || null, // From config
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Register or lookup user with the TaskMaster telemetry gateway using /auth/init
|
||||
* @param {string} email - User's email address
|
||||
* @param {string} userId - User's ID
|
||||
* @returns {Promise<{success: boolean, apiKey?: string, userId?: string, email?: string, isNewUser?: boolean, error?: string}>}
|
||||
*/
|
||||
export async function registerUserWithGateway(email = null, userId = null) {
|
||||
try {
|
||||
const requestBody = {};
|
||||
if (email) requestBody.email = email;
|
||||
if (userId) requestBody.userId = userId;
|
||||
|
||||
const response = await fetch(TASKMASTER_USER_REGISTRATION_ENDPOINT, {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
},
|
||||
body: JSON.stringify(requestBody),
|
||||
});
|
||||
|
||||
if (!response.ok) {
|
||||
return {
|
||||
success: false,
|
||||
error: `Gateway registration failed: ${response.status} ${response.statusText}`,
|
||||
};
|
||||
}
|
||||
|
||||
const result = await response.json();
|
||||
|
||||
// Handle the /auth/init response format
|
||||
if (result.success && result.data) {
|
||||
return {
|
||||
success: true,
|
||||
apiKey: result.data.token,
|
||||
userId: result.data.userId,
|
||||
email: email,
|
||||
isNewUser: result.data.isNewUser,
|
||||
};
|
||||
} else {
|
||||
return {
|
||||
success: false,
|
||||
error: result.error || result.message || "Unknown registration error",
|
||||
};
|
||||
}
|
||||
} catch (error) {
|
||||
return {
|
||||
success: false,
|
||||
error: `Gateway registration error: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Submits telemetry data to the remote gateway endpoint
|
||||
* @param {Object} telemetryData - The telemetry data to submit
|
||||
* @returns {Promise<Object>} - Result object with success status and details
|
||||
*/
|
||||
export async function submitTelemetryData(telemetryData) {
|
||||
try {
|
||||
// Check user opt-out preferences first, but hosted mode always sends telemetry
|
||||
const config = getConfig();
|
||||
const isHostedMode = config?.account?.mode === "hosted";
|
||||
|
||||
if (!isHostedMode && !getTelemetryEnabled()) {
|
||||
return {
|
||||
success: true,
|
||||
skipped: true,
|
||||
reason: "Telemetry disabled by user preference",
|
||||
};
|
||||
}
|
||||
|
||||
// Get telemetry configuration
|
||||
const telemetryConfig = getTelemetryConfig();
|
||||
if (
|
||||
!telemetryConfig.apiKey ||
|
||||
!telemetryConfig.userId ||
|
||||
!telemetryConfig.email
|
||||
) {
|
||||
return {
|
||||
success: false,
|
||||
error:
|
||||
"Telemetry configuration incomplete. Please ensure you have completed 'task-master init' to set up your user account.",
|
||||
};
|
||||
}
|
||||
|
||||
// Validate telemetry data
|
||||
try {
|
||||
TelemetryDataSchema.parse(telemetryData);
|
||||
} catch (validationError) {
|
||||
return {
|
||||
success: false,
|
||||
error: `Telemetry data validation failed: ${validationError.message}`,
|
||||
};
|
||||
}
|
||||
|
||||
// Send FULL telemetry data to gateway (including commandArgs and fullOutput)
|
||||
// Note: Sensitive data filtering is handled separately for user-facing responses
|
||||
const completeTelemetryData = {
|
||||
...telemetryData,
|
||||
userId: telemetryConfig.userId, // Ensure correct userId
|
||||
};
|
||||
|
||||
// Attempt submission with retry logic
|
||||
let lastError;
|
||||
for (let attempt = 1; attempt <= MAX_RETRIES; attempt++) {
|
||||
try {
|
||||
const response = await fetch(TASKMASTER_TELEMETRY_ENDPOINT, {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
"x-taskmaster-service-id": telemetryConfig.serviceId, // Hardcoded service ID
|
||||
Authorization: `Bearer ${telemetryConfig.apiKey}`, // User's Bearer token
|
||||
"X-User-Email": telemetryConfig.email, // User's email from config
|
||||
},
|
||||
body: JSON.stringify(completeTelemetryData),
|
||||
});
|
||||
|
||||
if (response.ok) {
|
||||
const result = await response.json();
|
||||
return {
|
||||
success: true,
|
||||
id: result.id,
|
||||
attempt,
|
||||
};
|
||||
} else {
|
||||
// Handle HTTP error responses
|
||||
const errorData = await response.json().catch(() => ({}));
|
||||
const errorMessage = `HTTP ${response.status} ${response.statusText}`;
|
||||
|
||||
// Don't retry on certain status codes (rate limiting, auth errors, etc.)
|
||||
if (
|
||||
response.status === 429 ||
|
||||
response.status === 401 ||
|
||||
response.status === 403
|
||||
) {
|
||||
return {
|
||||
success: false,
|
||||
error: errorMessage,
|
||||
statusCode: response.status,
|
||||
};
|
||||
}
|
||||
|
||||
// For other HTTP errors, continue retrying
|
||||
lastError = new Error(errorMessage);
|
||||
}
|
||||
} catch (networkError) {
|
||||
lastError = networkError;
|
||||
}
|
||||
|
||||
// Wait before retry (exponential backoff)
|
||||
if (attempt < MAX_RETRIES) {
|
||||
await new Promise((resolve) =>
|
||||
setTimeout(resolve, RETRY_DELAY * Math.pow(2, attempt - 1))
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
// All retries failed
|
||||
return {
|
||||
success: false,
|
||||
error: lastError.message,
|
||||
attempts: MAX_RETRIES,
|
||||
};
|
||||
} catch (error) {
|
||||
// Graceful error handling - never throw
|
||||
return {
|
||||
success: false,
|
||||
error: `Telemetry submission failed: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Submits telemetry data asynchronously without blocking execution
|
||||
* @param {Object} telemetryData - The telemetry data to submit
|
||||
*/
|
||||
export function submitTelemetryDataAsync(telemetryData) {
|
||||
// Fire and forget - don't block execution
|
||||
submitTelemetryData(telemetryData).catch((error) => {
|
||||
// Silently log errors without blocking
|
||||
console.debug("Telemetry submission failed:", error);
|
||||
});
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
516
scripts/modules/user-management.js
Normal file
516
scripts/modules/user-management.js
Normal file
@@ -0,0 +1,516 @@
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
import { log, findProjectRoot } from "./utils.js";
|
||||
import { getConfig, writeConfig, getUserId } from "./config-manager.js";
|
||||
|
||||
/**
|
||||
* Registers or finds a user via the gateway's /auth/init endpoint
|
||||
* @param {string|null} email - Optional user's email address (only needed for billing)
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {Promise<{success: boolean, userId: string, token: string, isNewUser: boolean, error?: string}>}
|
||||
*/
|
||||
async function registerUserWithGateway(email = null, explicitRoot = null) {
|
||||
try {
|
||||
const gatewayUrl =
|
||||
process.env.TASKMASTER_GATEWAY_URL || "http://localhost:4444";
|
||||
|
||||
// Check for existing userId and email to pass to gateway
|
||||
const existingUserId = getUserId(explicitRoot);
|
||||
const existingEmail = email || getUserEmail(explicitRoot);
|
||||
|
||||
// Build request body with existing values (gateway can handle userId for existing users)
|
||||
const requestBody = {};
|
||||
if (existingUserId && existingUserId !== "1234567890") {
|
||||
requestBody.userId = existingUserId;
|
||||
}
|
||||
if (existingEmail) {
|
||||
requestBody.email = existingEmail;
|
||||
}
|
||||
|
||||
const response = await fetch(`${gatewayUrl}/auth/init`, {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
},
|
||||
body: JSON.stringify(requestBody),
|
||||
});
|
||||
|
||||
if (!response.ok) {
|
||||
const errorText = await response.text();
|
||||
return {
|
||||
success: false,
|
||||
userId: "",
|
||||
token: "",
|
||||
isNewUser: false,
|
||||
error: `Gateway registration failed: ${response.status} ${errorText}`,
|
||||
};
|
||||
}
|
||||
|
||||
const result = await response.json();
|
||||
|
||||
if (result.success && result.data) {
|
||||
return {
|
||||
success: true,
|
||||
userId: result.data.userId,
|
||||
token: result.data.token,
|
||||
isNewUser: result.data.isNewUser,
|
||||
};
|
||||
} else {
|
||||
return {
|
||||
success: false,
|
||||
userId: "",
|
||||
token: "",
|
||||
isNewUser: false,
|
||||
error: "Invalid response format from gateway",
|
||||
};
|
||||
}
|
||||
} catch (error) {
|
||||
return {
|
||||
success: false,
|
||||
userId: "",
|
||||
token: "",
|
||||
isNewUser: false,
|
||||
error: `Network error: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Updates the user configuration with gateway registration results
|
||||
* @param {string} userId - User ID from gateway
|
||||
* @param {string} token - User authentication token from gateway (stored in .env)
|
||||
* @param {string} mode - User mode ('byok' or 'hosted')
|
||||
* @param {string|null} email - Optional user email to save
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {boolean} Success status
|
||||
*/
|
||||
function updateUserConfig(
|
||||
userId,
|
||||
token,
|
||||
mode,
|
||||
email = null,
|
||||
explicitRoot = null
|
||||
) {
|
||||
try {
|
||||
const config = getConfig(explicitRoot);
|
||||
|
||||
// Ensure account section exists
|
||||
if (!config.account) {
|
||||
config.account = {};
|
||||
}
|
||||
|
||||
// Ensure global section exists for email
|
||||
if (!config.global) {
|
||||
config.global = {};
|
||||
}
|
||||
|
||||
// Update user configuration in account section
|
||||
config.account.userId = userId;
|
||||
config.account.mode = mode; // 'byok' or 'hosted'
|
||||
|
||||
// Save email if provided
|
||||
if (email) {
|
||||
config.account.email = email;
|
||||
}
|
||||
|
||||
// Write user authentication token to .env file (not config)
|
||||
if (token) {
|
||||
writeApiKeyToEnv(token, explicitRoot);
|
||||
}
|
||||
|
||||
// Save updated config
|
||||
const success = writeConfig(config, explicitRoot);
|
||||
if (success) {
|
||||
const emailInfo = email ? `, email=${email}` : "";
|
||||
log(
|
||||
"info",
|
||||
`User configuration updated: userId=${userId}, mode=${mode}${emailInfo}`
|
||||
);
|
||||
} else {
|
||||
log("error", "Failed to write updated user configuration");
|
||||
}
|
||||
|
||||
return success;
|
||||
} catch (error) {
|
||||
log("error", `Error updating user config: ${error.message}`);
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Writes the user authentication token to the .env file
|
||||
* This token is used as Bearer auth for gateway API calls
|
||||
* @param {string} token - Authentication token to write
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
*/
|
||||
function writeApiKeyToEnv(token, explicitRoot = null) {
|
||||
try {
|
||||
// Determine project root
|
||||
let rootPath = explicitRoot;
|
||||
if (!rootPath) {
|
||||
rootPath = findProjectRoot();
|
||||
if (!rootPath) {
|
||||
log("warn", "Could not determine project root for .env file");
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
const envPath = path.join(rootPath, ".env");
|
||||
let envContent = "";
|
||||
|
||||
// Read existing .env content if file exists
|
||||
if (fs.existsSync(envPath)) {
|
||||
envContent = fs.readFileSync(envPath, "utf8");
|
||||
}
|
||||
|
||||
// Check if TASKMASTER_API_KEY already exists
|
||||
const lines = envContent.split("\n");
|
||||
let keyExists = false;
|
||||
|
||||
for (let i = 0; i < lines.length; i++) {
|
||||
if (lines[i].startsWith("TASKMASTER_API_KEY=")) {
|
||||
lines[i] = `TASKMASTER_API_KEY=${token}`;
|
||||
keyExists = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
// Add key if it doesn't exist
|
||||
if (!keyExists) {
|
||||
if (envContent && !envContent.endsWith("\n")) {
|
||||
envContent += "\n";
|
||||
}
|
||||
envContent += `TASKMASTER_API_KEY=${token}\n`;
|
||||
} else {
|
||||
envContent = lines.join("\n");
|
||||
}
|
||||
|
||||
// Write updated content
|
||||
fs.writeFileSync(envPath, envContent);
|
||||
} catch (error) {
|
||||
log("error", `Failed to write user token to .env: ${error.message}`);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets the current user mode from configuration
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {string} User mode ('byok', 'hosted', or 'unknown')
|
||||
*/
|
||||
function getUserMode(explicitRoot = null) {
|
||||
try {
|
||||
const config = getConfig(explicitRoot);
|
||||
return config?.account?.mode || "unknown";
|
||||
} catch (error) {
|
||||
log("error", `Error getting user mode: ${error.message}`);
|
||||
return "unknown";
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Checks if user is in hosted mode
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {boolean} True if user is in hosted mode
|
||||
*/
|
||||
function isHostedMode(explicitRoot = null) {
|
||||
return getUserMode(explicitRoot) === "hosted";
|
||||
}
|
||||
|
||||
/**
|
||||
* Checks if user is in BYOK mode
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {boolean} True if user is in BYOK mode
|
||||
*/
|
||||
function isByokMode(explicitRoot = null) {
|
||||
return getUserMode(explicitRoot) === "byok";
|
||||
}
|
||||
|
||||
/**
|
||||
* Complete user setup: register with gateway and configure TaskMaster
|
||||
* @param {string|null} email - Optional user's email (only needed for billing)
|
||||
* @param {string} mode - User's mode: 'byok' or 'hosted'
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {Promise<{success: boolean, userId: string, mode: string, error?: string}>}
|
||||
*/
|
||||
async function setupUser(email = null, mode = "hosted", explicitRoot = null) {
|
||||
try {
|
||||
// Step 1: Register with gateway (email optional)
|
||||
const registrationResult = await registerUserWithGateway(
|
||||
email,
|
||||
explicitRoot
|
||||
);
|
||||
|
||||
if (!registrationResult.success) {
|
||||
return {
|
||||
success: false,
|
||||
userId: "",
|
||||
mode: "",
|
||||
error: registrationResult.error,
|
||||
};
|
||||
}
|
||||
|
||||
// Step 2: Update config with userId, mode, and email
|
||||
const configResult = updateUserConfig(
|
||||
registrationResult.userId,
|
||||
registrationResult.token,
|
||||
mode,
|
||||
email,
|
||||
explicitRoot
|
||||
);
|
||||
|
||||
if (!configResult) {
|
||||
return {
|
||||
success: false,
|
||||
userId: registrationResult.userId,
|
||||
mode: "",
|
||||
error: "Failed to update user configuration",
|
||||
};
|
||||
}
|
||||
|
||||
return {
|
||||
success: true,
|
||||
userId: registrationResult.userId,
|
||||
mode: mode,
|
||||
message: email
|
||||
? `User setup complete with email ${email}`
|
||||
: "User setup complete (email will be collected during billing setup)",
|
||||
};
|
||||
} catch (error) {
|
||||
return {
|
||||
success: false,
|
||||
userId: "",
|
||||
mode: "",
|
||||
error: `Setup failed: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Initialize TaskMaster user (typically called during init)
|
||||
* Gets userId from gateway without requiring email upfront
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {Promise<{success: boolean, userId: string, error?: string}>}
|
||||
*/
|
||||
async function initializeUser(explicitRoot = null) {
|
||||
const config = getConfig(explicitRoot);
|
||||
const mode = config.account?.mode || "byok";
|
||||
|
||||
if (mode === "byok") {
|
||||
return await initializeBYOKUser(explicitRoot);
|
||||
} else {
|
||||
return await initializeHostedUser(explicitRoot);
|
||||
}
|
||||
}
|
||||
|
||||
async function initializeBYOKUser(projectRoot) {
|
||||
try {
|
||||
const gatewayUrl =
|
||||
process.env.TASKMASTER_GATEWAY_URL || "http://localhost:4444";
|
||||
|
||||
// Check if we already have an anonymous user ID stored
|
||||
let config = getConfig(projectRoot);
|
||||
const existingAnonymousUserId = config?.account?.userId;
|
||||
|
||||
// Prepare headers for the request
|
||||
const headers = {
|
||||
"Content-Type": "application/json",
|
||||
"X-TaskMaster-Service-ID": "98fb3198-2dfc-42d1-af53-07b99e4f3bde",
|
||||
};
|
||||
|
||||
// If we have an existing anonymous user ID, try to reuse it
|
||||
if (existingAnonymousUserId && existingAnonymousUserId !== "1234567890") {
|
||||
headers["X-Anonymous-User-ID"] = existingAnonymousUserId;
|
||||
}
|
||||
|
||||
// Call gateway /auth/anonymous to create or reuse a user account
|
||||
// BYOK users still get an account for potential future hosted mode switch
|
||||
const response = await fetch(`${gatewayUrl}/auth/anonymous`, {
|
||||
method: "POST",
|
||||
headers,
|
||||
body: JSON.stringify({}),
|
||||
});
|
||||
|
||||
if (response.ok) {
|
||||
const result = await response.json();
|
||||
|
||||
// Store the user token (same as hosted users)
|
||||
// BYOK users won't use this for AI calls, but will have it for potential mode switch
|
||||
if (result.session && result.session.access_token) {
|
||||
writeApiKeyToEnv(result.session.access_token, projectRoot);
|
||||
}
|
||||
|
||||
// Update config with BYOK user info, ensuring we store the anonymous user ID
|
||||
if (!config.account) {
|
||||
config.account = {};
|
||||
}
|
||||
config.account.userId = result.anonymousUserId || result.user.id;
|
||||
config.account.mode = "byok";
|
||||
config.account.email =
|
||||
result.user.email ||
|
||||
`anon-${result.anonymousUserId || result.user.id}@taskmaster.temp`;
|
||||
config.account.telemetryEnabled = true;
|
||||
|
||||
writeConfig(config, projectRoot);
|
||||
|
||||
return {
|
||||
success: true,
|
||||
userId: result.anonymousUserId || result.user.id,
|
||||
token: result.session?.access_token || null,
|
||||
mode: "byok",
|
||||
isAnonymous: true,
|
||||
isReused: result.isReused || false,
|
||||
};
|
||||
} else {
|
||||
const errorText = await response.text();
|
||||
return {
|
||||
success: false,
|
||||
error: `Gateway not available: ${response.status} ${errorText}`,
|
||||
};
|
||||
}
|
||||
} catch (error) {
|
||||
return {
|
||||
success: false,
|
||||
error: `Network error: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
async function initializeHostedUser(projectRoot) {
|
||||
try {
|
||||
// For hosted users, we need proper authentication
|
||||
// This would typically involve OAuth flow or registration
|
||||
const gatewayUrl =
|
||||
process.env.TASKMASTER_GATEWAY_URL || "http://localhost:4444";
|
||||
|
||||
// Check if we already have stored credentials
|
||||
const existingToken = getUserToken(projectRoot);
|
||||
const existingUserId = getUserId(projectRoot);
|
||||
|
||||
if (existingToken && existingUserId && existingUserId !== "1234567890") {
|
||||
// Try to validate existing credentials
|
||||
try {
|
||||
const response = await fetch(`${gatewayUrl}/auth/validate`, {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
Authorization: `Bearer ${existingToken}`,
|
||||
"X-TaskMaster-Service-ID": "98fb3198-2dfc-42d1-af53-07b99e4f3bde",
|
||||
},
|
||||
});
|
||||
|
||||
if (response.ok) {
|
||||
return {
|
||||
success: true,
|
||||
userId: existingUserId,
|
||||
token: existingToken,
|
||||
mode: "hosted",
|
||||
isExisting: true,
|
||||
};
|
||||
}
|
||||
} catch (error) {
|
||||
// Fall through to re-authentication
|
||||
}
|
||||
}
|
||||
|
||||
// If no valid credentials, use the existing registration flow
|
||||
const registrationResult = await registerUserWithGateway(null, projectRoot);
|
||||
|
||||
if (registrationResult.success) {
|
||||
// Update config for hosted mode
|
||||
updateUserConfig(
|
||||
registrationResult.userId,
|
||||
registrationResult.token,
|
||||
"hosted",
|
||||
null,
|
||||
projectRoot
|
||||
);
|
||||
|
||||
return {
|
||||
success: true,
|
||||
userId: registrationResult.userId,
|
||||
token: registrationResult.token,
|
||||
mode: "hosted",
|
||||
isNewUser: registrationResult.isNewUser,
|
||||
};
|
||||
} else {
|
||||
return {
|
||||
success: false,
|
||||
error: `Hosted mode setup failed: ${registrationResult.error}`,
|
||||
};
|
||||
}
|
||||
} catch (error) {
|
||||
return {
|
||||
success: false,
|
||||
error: `Hosted user initialization failed: ${error.message}`,
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets the current user authentication token from .env file
|
||||
* This is the Bearer token used for gateway API calls
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {string|null} User authentication token or null if not found
|
||||
*/
|
||||
function getUserToken(explicitRoot = null) {
|
||||
try {
|
||||
// Determine project root
|
||||
let rootPath = explicitRoot;
|
||||
if (!rootPath) {
|
||||
rootPath = findProjectRoot();
|
||||
if (!rootPath) {
|
||||
log("error", "Could not determine project root for .env file");
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
const envPath = path.join(rootPath, ".env");
|
||||
if (!fs.existsSync(envPath)) {
|
||||
return null;
|
||||
}
|
||||
|
||||
const envContent = fs.readFileSync(envPath, "utf8");
|
||||
const lines = envContent.split("\n");
|
||||
|
||||
for (const line of lines) {
|
||||
if (line.startsWith("TASKMASTER_API_KEY=")) {
|
||||
return line.substring("TASKMASTER_API_KEY=".length).trim();
|
||||
}
|
||||
}
|
||||
|
||||
return null;
|
||||
} catch (error) {
|
||||
log("error", `Error getting user token from .env: ${error.message}`);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets the current user email from configuration
|
||||
* @param {string|null} explicitRoot - Optional explicit project root path
|
||||
* @returns {string|null} User email or null if not found
|
||||
*/
|
||||
function getUserEmail(explicitRoot = null) {
|
||||
try {
|
||||
const config = getConfig(explicitRoot);
|
||||
return config?.account?.email || null;
|
||||
} catch (error) {
|
||||
log("error", `Error getting user email: ${error.message}`);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
export {
|
||||
registerUserWithGateway,
|
||||
updateUserConfig,
|
||||
writeApiKeyToEnv,
|
||||
getUserMode,
|
||||
isHostedMode,
|
||||
isByokMode,
|
||||
setupUser,
|
||||
initializeUser,
|
||||
initializeBYOKUser,
|
||||
initializeHostedUser,
|
||||
getUserToken,
|
||||
getUserEmail,
|
||||
};
|
||||
659
scripts/modules/utils/contextGatherer.js
Normal file
659
scripts/modules/utils/contextGatherer.js
Normal file
@@ -0,0 +1,659 @@
|
||||
/**
|
||||
* contextGatherer.js
|
||||
* Comprehensive context gathering utility for Task Master AI operations
|
||||
* Supports task context, file context, project tree, and custom context
|
||||
*/
|
||||
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
import pkg from 'gpt-tokens';
|
||||
import { readJSON, findTaskById, truncate } from '../utils.js';
|
||||
|
||||
const { encode } = pkg;
|
||||
|
||||
/**
|
||||
* Context Gatherer class for collecting and formatting context from various sources
|
||||
*/
|
||||
export class ContextGatherer {
|
||||
constructor(projectRoot) {
|
||||
this.projectRoot = projectRoot;
|
||||
this.tasksPath = path.join(projectRoot, 'tasks', 'tasks.json');
|
||||
}
|
||||
|
||||
/**
|
||||
* Count tokens in a text string using gpt-tokens
|
||||
* @param {string} text - Text to count tokens for
|
||||
* @returns {number} Token count
|
||||
*/
|
||||
countTokens(text) {
|
||||
if (!text || typeof text !== 'string') {
|
||||
return 0;
|
||||
}
|
||||
try {
|
||||
return encode(text).length;
|
||||
} catch (error) {
|
||||
// Fallback to rough character-based estimation if tokenizer fails
|
||||
// Rough estimate: ~4 characters per token for English text
|
||||
return Math.ceil(text.length / 4);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Main method to gather context from multiple sources
|
||||
* @param {Object} options - Context gathering options
|
||||
* @param {Array<string>} [options.tasks] - Task/subtask IDs to include
|
||||
* @param {Array<string>} [options.files] - File paths to include
|
||||
* @param {string} [options.customContext] - Additional custom context
|
||||
* @param {boolean} [options.includeProjectTree] - Include project file tree
|
||||
* @param {string} [options.format] - Output format: 'research', 'chat', 'system-prompt'
|
||||
* @returns {Promise<string>} Formatted context string
|
||||
*/
|
||||
async gather(options = {}) {
|
||||
const {
|
||||
tasks = [],
|
||||
files = [],
|
||||
customContext = '',
|
||||
includeProjectTree = false,
|
||||
format = 'research',
|
||||
includeTokenCounts = false
|
||||
} = options;
|
||||
|
||||
const contextSections = [];
|
||||
const tokenBreakdown = {
|
||||
customContext: null,
|
||||
tasks: [],
|
||||
files: [],
|
||||
projectTree: null,
|
||||
total: 0
|
||||
};
|
||||
|
||||
// Add custom context first if provided
|
||||
if (customContext && customContext.trim()) {
|
||||
const formattedCustom = this._formatCustomContext(customContext, format);
|
||||
contextSections.push(formattedCustom);
|
||||
if (includeTokenCounts) {
|
||||
tokenBreakdown.customContext = {
|
||||
tokens: this.countTokens(formattedCustom),
|
||||
characters: formattedCustom.length
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
// Add task context
|
||||
if (tasks.length > 0) {
|
||||
const taskContextResult = await this._gatherTaskContext(
|
||||
tasks,
|
||||
format,
|
||||
includeTokenCounts
|
||||
);
|
||||
if (taskContextResult.context) {
|
||||
contextSections.push(taskContextResult.context);
|
||||
if (includeTokenCounts) {
|
||||
tokenBreakdown.tasks = taskContextResult.breakdown;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Add file context
|
||||
if (files.length > 0) {
|
||||
const fileContextResult = await this._gatherFileContext(
|
||||
files,
|
||||
format,
|
||||
includeTokenCounts
|
||||
);
|
||||
if (fileContextResult.context) {
|
||||
contextSections.push(fileContextResult.context);
|
||||
if (includeTokenCounts) {
|
||||
tokenBreakdown.files = fileContextResult.breakdown;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Add project tree context
|
||||
if (includeProjectTree) {
|
||||
const treeContextResult = await this._gatherProjectTreeContext(
|
||||
format,
|
||||
includeTokenCounts
|
||||
);
|
||||
if (treeContextResult.context) {
|
||||
contextSections.push(treeContextResult.context);
|
||||
if (includeTokenCounts) {
|
||||
tokenBreakdown.projectTree = treeContextResult.breakdown;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Join all sections based on format
|
||||
const finalContext = this._joinContextSections(contextSections, format);
|
||||
|
||||
if (includeTokenCounts) {
|
||||
tokenBreakdown.total = this.countTokens(finalContext);
|
||||
return {
|
||||
context: finalContext,
|
||||
tokenBreakdown: tokenBreakdown
|
||||
};
|
||||
}
|
||||
|
||||
return finalContext;
|
||||
}
|
||||
|
||||
/**
|
||||
* Parse task ID strings into structured format
|
||||
* Supports formats: "15", "15.2", "16,17.1"
|
||||
* @param {Array<string>} taskIds - Array of task ID strings
|
||||
* @returns {Array<Object>} Parsed task identifiers
|
||||
*/
|
||||
_parseTaskIds(taskIds) {
|
||||
const parsed = [];
|
||||
|
||||
for (const idStr of taskIds) {
|
||||
if (idStr.includes('.')) {
|
||||
// Subtask format: "15.2"
|
||||
const [parentId, subtaskId] = idStr.split('.');
|
||||
parsed.push({
|
||||
type: 'subtask',
|
||||
parentId: parseInt(parentId, 10),
|
||||
subtaskId: parseInt(subtaskId, 10),
|
||||
fullId: idStr
|
||||
});
|
||||
} else {
|
||||
// Task format: "15"
|
||||
parsed.push({
|
||||
type: 'task',
|
||||
taskId: parseInt(idStr, 10),
|
||||
fullId: idStr
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
return parsed;
|
||||
}
|
||||
|
||||
/**
|
||||
* Gather context from tasks and subtasks
|
||||
* @param {Array<string>} taskIds - Task/subtask IDs
|
||||
* @param {string} format - Output format
|
||||
* @param {boolean} includeTokenCounts - Whether to include token breakdown
|
||||
* @returns {Promise<Object>} Task context result with breakdown
|
||||
*/
|
||||
async _gatherTaskContext(taskIds, format, includeTokenCounts = false) {
|
||||
try {
|
||||
const tasksData = readJSON(this.tasksPath);
|
||||
if (!tasksData || !tasksData.tasks) {
|
||||
return { context: null, breakdown: [] };
|
||||
}
|
||||
|
||||
const parsedIds = this._parseTaskIds(taskIds);
|
||||
const contextItems = [];
|
||||
const breakdown = [];
|
||||
|
||||
for (const parsed of parsedIds) {
|
||||
let formattedItem = null;
|
||||
let itemInfo = null;
|
||||
|
||||
if (parsed.type === 'task') {
|
||||
const result = findTaskById(tasksData.tasks, parsed.taskId);
|
||||
if (result.task) {
|
||||
formattedItem = this._formatTaskForContext(result.task, format);
|
||||
itemInfo = {
|
||||
id: parsed.fullId,
|
||||
type: 'task',
|
||||
title: result.task.title,
|
||||
tokens: includeTokenCounts ? this.countTokens(formattedItem) : 0,
|
||||
characters: formattedItem.length
|
||||
};
|
||||
}
|
||||
} else if (parsed.type === 'subtask') {
|
||||
const parentResult = findTaskById(tasksData.tasks, parsed.parentId);
|
||||
if (parentResult.task && parentResult.task.subtasks) {
|
||||
const subtask = parentResult.task.subtasks.find(
|
||||
(st) => st.id === parsed.subtaskId
|
||||
);
|
||||
if (subtask) {
|
||||
formattedItem = this._formatSubtaskForContext(
|
||||
subtask,
|
||||
parentResult.task,
|
||||
format
|
||||
);
|
||||
itemInfo = {
|
||||
id: parsed.fullId,
|
||||
type: 'subtask',
|
||||
title: subtask.title,
|
||||
parentTitle: parentResult.task.title,
|
||||
tokens: includeTokenCounts
|
||||
? this.countTokens(formattedItem)
|
||||
: 0,
|
||||
characters: formattedItem.length
|
||||
};
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (formattedItem && itemInfo) {
|
||||
contextItems.push(formattedItem);
|
||||
if (includeTokenCounts) {
|
||||
breakdown.push(itemInfo);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (contextItems.length === 0) {
|
||||
return { context: null, breakdown: [] };
|
||||
}
|
||||
|
||||
const finalContext = this._formatTaskContextSection(contextItems, format);
|
||||
return {
|
||||
context: finalContext,
|
||||
breakdown: includeTokenCounts ? breakdown : []
|
||||
};
|
||||
} catch (error) {
|
||||
console.warn(`Warning: Could not gather task context: ${error.message}`);
|
||||
return { context: null, breakdown: [] };
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format a task for context inclusion
|
||||
* @param {Object} task - Task object
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted task context
|
||||
*/
|
||||
_formatTaskForContext(task, format) {
|
||||
const sections = [];
|
||||
|
||||
sections.push(`**Task ${task.id}: ${task.title}**`);
|
||||
sections.push(`Description: ${task.description}`);
|
||||
sections.push(`Status: ${task.status || 'pending'}`);
|
||||
sections.push(`Priority: ${task.priority || 'medium'}`);
|
||||
|
||||
if (task.dependencies && task.dependencies.length > 0) {
|
||||
sections.push(`Dependencies: ${task.dependencies.join(', ')}`);
|
||||
}
|
||||
|
||||
if (task.details) {
|
||||
const details = truncate(task.details, 500);
|
||||
sections.push(`Implementation Details: ${details}`);
|
||||
}
|
||||
|
||||
if (task.testStrategy) {
|
||||
const testStrategy = truncate(task.testStrategy, 300);
|
||||
sections.push(`Test Strategy: ${testStrategy}`);
|
||||
}
|
||||
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
sections.push(`Subtasks: ${task.subtasks.length} subtasks defined`);
|
||||
}
|
||||
|
||||
return sections.join('\n');
|
||||
}
|
||||
|
||||
/**
|
||||
* Format a subtask for context inclusion
|
||||
* @param {Object} subtask - Subtask object
|
||||
* @param {Object} parentTask - Parent task object
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted subtask context
|
||||
*/
|
||||
_formatSubtaskForContext(subtask, parentTask, format) {
|
||||
const sections = [];
|
||||
|
||||
sections.push(
|
||||
`**Subtask ${parentTask.id}.${subtask.id}: ${subtask.title}**`
|
||||
);
|
||||
sections.push(`Parent Task: ${parentTask.title}`);
|
||||
sections.push(`Description: ${subtask.description}`);
|
||||
sections.push(`Status: ${subtask.status || 'pending'}`);
|
||||
|
||||
if (subtask.dependencies && subtask.dependencies.length > 0) {
|
||||
sections.push(`Dependencies: ${subtask.dependencies.join(', ')}`);
|
||||
}
|
||||
|
||||
if (subtask.details) {
|
||||
const details = truncate(subtask.details, 500);
|
||||
sections.push(`Implementation Details: ${details}`);
|
||||
}
|
||||
|
||||
return sections.join('\n');
|
||||
}
|
||||
|
||||
/**
|
||||
* Gather context from files
|
||||
* @param {Array<string>} filePaths - File paths to read
|
||||
* @param {string} format - Output format
|
||||
* @param {boolean} includeTokenCounts - Whether to include token breakdown
|
||||
* @returns {Promise<Object>} File context result with breakdown
|
||||
*/
|
||||
async _gatherFileContext(filePaths, format, includeTokenCounts = false) {
|
||||
const fileContents = [];
|
||||
const breakdown = [];
|
||||
|
||||
for (const filePath of filePaths) {
|
||||
try {
|
||||
const fullPath = path.isAbsolute(filePath)
|
||||
? filePath
|
||||
: path.join(this.projectRoot, filePath);
|
||||
|
||||
if (!fs.existsSync(fullPath)) {
|
||||
console.warn(`Warning: File not found: ${filePath}`);
|
||||
continue;
|
||||
}
|
||||
|
||||
const stats = fs.statSync(fullPath);
|
||||
if (!stats.isFile()) {
|
||||
console.warn(`Warning: Path is not a file: ${filePath}`);
|
||||
continue;
|
||||
}
|
||||
|
||||
// Check file size (limit to 50KB for context)
|
||||
if (stats.size > 50 * 1024) {
|
||||
console.warn(
|
||||
`Warning: File too large, skipping: ${filePath} (${Math.round(stats.size / 1024)}KB)`
|
||||
);
|
||||
continue;
|
||||
}
|
||||
|
||||
const content = fs.readFileSync(fullPath, 'utf-8');
|
||||
const relativePath = path.relative(this.projectRoot, fullPath);
|
||||
|
||||
const fileData = {
|
||||
path: relativePath,
|
||||
size: stats.size,
|
||||
content: content,
|
||||
lastModified: stats.mtime
|
||||
};
|
||||
|
||||
fileContents.push(fileData);
|
||||
|
||||
// Calculate tokens for this individual file if requested
|
||||
if (includeTokenCounts) {
|
||||
const formattedFile = this._formatSingleFileForContext(
|
||||
fileData,
|
||||
format
|
||||
);
|
||||
breakdown.push({
|
||||
path: relativePath,
|
||||
sizeKB: Math.round(stats.size / 1024),
|
||||
tokens: this.countTokens(formattedFile),
|
||||
characters: formattedFile.length
|
||||
});
|
||||
}
|
||||
} catch (error) {
|
||||
console.warn(
|
||||
`Warning: Could not read file ${filePath}: ${error.message}`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
if (fileContents.length === 0) {
|
||||
return { context: null, breakdown: [] };
|
||||
}
|
||||
|
||||
const finalContext = this._formatFileContextSection(fileContents, format);
|
||||
return {
|
||||
context: finalContext,
|
||||
breakdown: includeTokenCounts ? breakdown : []
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Generate project file tree context
|
||||
* @param {string} format - Output format
|
||||
* @param {boolean} includeTokenCounts - Whether to include token breakdown
|
||||
* @returns {Promise<Object>} Project tree context result with breakdown
|
||||
*/
|
||||
async _gatherProjectTreeContext(format, includeTokenCounts = false) {
|
||||
try {
|
||||
const tree = this._generateFileTree(this.projectRoot, 5); // Max depth 5
|
||||
const finalContext = this._formatProjectTreeSection(tree, format);
|
||||
|
||||
const breakdown = includeTokenCounts
|
||||
? {
|
||||
tokens: this.countTokens(finalContext),
|
||||
characters: finalContext.length,
|
||||
fileCount: tree.fileCount || 0,
|
||||
dirCount: tree.dirCount || 0
|
||||
}
|
||||
: null;
|
||||
|
||||
return {
|
||||
context: finalContext,
|
||||
breakdown: breakdown
|
||||
};
|
||||
} catch (error) {
|
||||
console.warn(
|
||||
`Warning: Could not generate project tree: ${error.message}`
|
||||
);
|
||||
return { context: null, breakdown: null };
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format a single file for context (used for token counting)
|
||||
* @param {Object} fileData - File data object
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted file context
|
||||
*/
|
||||
_formatSingleFileForContext(fileData, format) {
|
||||
const header = `**File: ${fileData.path}** (${Math.round(fileData.size / 1024)}KB)`;
|
||||
const content = `\`\`\`\n${fileData.content}\n\`\`\``;
|
||||
return `${header}\n\n${content}`;
|
||||
}
|
||||
|
||||
/**
|
||||
* Generate file tree structure
|
||||
* @param {string} dirPath - Directory path
|
||||
* @param {number} maxDepth - Maximum depth to traverse
|
||||
* @param {number} currentDepth - Current depth
|
||||
* @returns {Object} File tree structure
|
||||
*/
|
||||
_generateFileTree(dirPath, maxDepth, currentDepth = 0) {
|
||||
const ignoreDirs = [
|
||||
'.git',
|
||||
'node_modules',
|
||||
'.env',
|
||||
'coverage',
|
||||
'dist',
|
||||
'build'
|
||||
];
|
||||
const ignoreFiles = ['.DS_Store', '.env', '.env.local', '.env.production'];
|
||||
|
||||
if (currentDepth >= maxDepth) {
|
||||
return null;
|
||||
}
|
||||
|
||||
try {
|
||||
const items = fs.readdirSync(dirPath);
|
||||
const tree = {
|
||||
name: path.basename(dirPath),
|
||||
type: 'directory',
|
||||
children: [],
|
||||
fileCount: 0,
|
||||
dirCount: 0
|
||||
};
|
||||
|
||||
for (const item of items) {
|
||||
if (ignoreDirs.includes(item) || ignoreFiles.includes(item)) {
|
||||
continue;
|
||||
}
|
||||
|
||||
const itemPath = path.join(dirPath, item);
|
||||
const stats = fs.statSync(itemPath);
|
||||
|
||||
if (stats.isDirectory()) {
|
||||
tree.dirCount++;
|
||||
if (currentDepth < maxDepth - 1) {
|
||||
const subtree = this._generateFileTree(
|
||||
itemPath,
|
||||
maxDepth,
|
||||
currentDepth + 1
|
||||
);
|
||||
if (subtree) {
|
||||
tree.children.push(subtree);
|
||||
}
|
||||
}
|
||||
} else {
|
||||
tree.fileCount++;
|
||||
tree.children.push({
|
||||
name: item,
|
||||
type: 'file',
|
||||
size: stats.size
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
return tree;
|
||||
} catch (error) {
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format custom context section
|
||||
* @param {string} customContext - Custom context string
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted custom context
|
||||
*/
|
||||
_formatCustomContext(customContext, format) {
|
||||
switch (format) {
|
||||
case 'research':
|
||||
return `## Additional Context\n\n${customContext}`;
|
||||
case 'chat':
|
||||
return `**Additional Context:**\n${customContext}`;
|
||||
case 'system-prompt':
|
||||
return `Additional context: ${customContext}`;
|
||||
default:
|
||||
return customContext;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format task context section
|
||||
* @param {Array<string>} taskItems - Formatted task items
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted task context section
|
||||
*/
|
||||
_formatTaskContextSection(taskItems, format) {
|
||||
switch (format) {
|
||||
case 'research':
|
||||
return `## Task Context\n\n${taskItems.join('\n\n---\n\n')}`;
|
||||
case 'chat':
|
||||
return `**Task Context:**\n\n${taskItems.join('\n\n')}`;
|
||||
case 'system-prompt':
|
||||
return `Task context: ${taskItems.join(' | ')}`;
|
||||
default:
|
||||
return taskItems.join('\n\n');
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format file context section
|
||||
* @param {Array<Object>} fileContents - File content objects
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted file context section
|
||||
*/
|
||||
_formatFileContextSection(fileContents, format) {
|
||||
const fileItems = fileContents.map((file) => {
|
||||
const header = `**File: ${file.path}** (${Math.round(file.size / 1024)}KB)`;
|
||||
const content = `\`\`\`\n${file.content}\n\`\`\``;
|
||||
return `${header}\n\n${content}`;
|
||||
});
|
||||
|
||||
switch (format) {
|
||||
case 'research':
|
||||
return `## File Context\n\n${fileItems.join('\n\n---\n\n')}`;
|
||||
case 'chat':
|
||||
return `**File Context:**\n\n${fileItems.join('\n\n')}`;
|
||||
case 'system-prompt':
|
||||
return `File context: ${fileContents.map((f) => `${f.path} (${f.content.substring(0, 200)}...)`).join(' | ')}`;
|
||||
default:
|
||||
return fileItems.join('\n\n');
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Format project tree section
|
||||
* @param {Object} tree - File tree structure
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Formatted project tree section
|
||||
*/
|
||||
_formatProjectTreeSection(tree, format) {
|
||||
const treeString = this._renderFileTree(tree);
|
||||
|
||||
switch (format) {
|
||||
case 'research':
|
||||
return `## Project Structure\n\n\`\`\`\n${treeString}\n\`\`\``;
|
||||
case 'chat':
|
||||
return `**Project Structure:**\n\`\`\`\n${treeString}\n\`\`\``;
|
||||
case 'system-prompt':
|
||||
return `Project structure: ${treeString.replace(/\n/g, ' | ')}`;
|
||||
default:
|
||||
return treeString;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Render file tree as string
|
||||
* @param {Object} tree - File tree structure
|
||||
* @param {string} prefix - Current prefix for indentation
|
||||
* @returns {string} Rendered tree string
|
||||
*/
|
||||
_renderFileTree(tree, prefix = '') {
|
||||
let result = `${prefix}${tree.name}/`;
|
||||
|
||||
if (tree.fileCount > 0 || tree.dirCount > 0) {
|
||||
result += ` (${tree.fileCount} files, ${tree.dirCount} dirs)`;
|
||||
}
|
||||
|
||||
result += '\n';
|
||||
|
||||
if (tree.children) {
|
||||
tree.children.forEach((child, index) => {
|
||||
const isLast = index === tree.children.length - 1;
|
||||
const childPrefix = prefix + (isLast ? '└── ' : '├── ');
|
||||
const nextPrefix = prefix + (isLast ? ' ' : '│ ');
|
||||
|
||||
if (child.type === 'directory') {
|
||||
result += this._renderFileTree(child, childPrefix);
|
||||
} else {
|
||||
result += `${childPrefix}${child.name}\n`;
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
return result;
|
||||
}
|
||||
|
||||
/**
|
||||
* Join context sections based on format
|
||||
* @param {Array<string>} sections - Context sections
|
||||
* @param {string} format - Output format
|
||||
* @returns {string} Joined context string
|
||||
*/
|
||||
_joinContextSections(sections, format) {
|
||||
if (sections.length === 0) {
|
||||
return '';
|
||||
}
|
||||
|
||||
switch (format) {
|
||||
case 'research':
|
||||
return sections.join('\n\n---\n\n');
|
||||
case 'chat':
|
||||
return sections.join('\n\n');
|
||||
case 'system-prompt':
|
||||
return sections.join(' ');
|
||||
default:
|
||||
return sections.join('\n\n');
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Factory function to create a context gatherer instance
|
||||
* @param {string} projectRoot - Project root directory
|
||||
* @returns {ContextGatherer} Context gatherer instance
|
||||
*/
|
||||
export function createContextGatherer(projectRoot) {
|
||||
return new ContextGatherer(projectRoot);
|
||||
}
|
||||
|
||||
export default ContextGatherer;
|
||||
376
scripts/modules/utils/fuzzyTaskSearch.js
Normal file
376
scripts/modules/utils/fuzzyTaskSearch.js
Normal file
@@ -0,0 +1,376 @@
|
||||
/**
|
||||
* fuzzyTaskSearch.js
|
||||
* Reusable fuzzy search utility for finding relevant tasks based on semantic similarity
|
||||
*/
|
||||
|
||||
import Fuse from 'fuse.js';
|
||||
|
||||
/**
|
||||
* Configuration for different search contexts
|
||||
*/
|
||||
const SEARCH_CONFIGS = {
|
||||
research: {
|
||||
threshold: 0.5, // More lenient for research (broader context)
|
||||
limit: 20,
|
||||
keys: [
|
||||
{ name: 'title', weight: 2.0 },
|
||||
{ name: 'description', weight: 1.0 },
|
||||
{ name: 'details', weight: 0.5 },
|
||||
{ name: 'dependencyTitles', weight: 0.5 }
|
||||
]
|
||||
},
|
||||
addTask: {
|
||||
threshold: 0.4, // Stricter for add-task (more precise context)
|
||||
limit: 15,
|
||||
keys: [
|
||||
{ name: 'title', weight: 2.0 },
|
||||
{ name: 'description', weight: 1.5 },
|
||||
{ name: 'details', weight: 0.8 },
|
||||
{ name: 'dependencyTitles', weight: 0.5 }
|
||||
]
|
||||
},
|
||||
default: {
|
||||
threshold: 0.4,
|
||||
limit: 15,
|
||||
keys: [
|
||||
{ name: 'title', weight: 2.0 },
|
||||
{ name: 'description', weight: 1.5 },
|
||||
{ name: 'details', weight: 1.0 },
|
||||
{ name: 'dependencyTitles', weight: 0.5 }
|
||||
]
|
||||
}
|
||||
};
|
||||
|
||||
/**
|
||||
* Purpose categories for pattern-based task matching
|
||||
*/
|
||||
const PURPOSE_CATEGORIES = [
|
||||
{ pattern: /(command|cli|flag)/i, label: 'CLI commands' },
|
||||
{ pattern: /(task|subtask|add)/i, label: 'Task management' },
|
||||
{ pattern: /(dependency|depend)/i, label: 'Dependency handling' },
|
||||
{ pattern: /(AI|model|prompt|research)/i, label: 'AI integration' },
|
||||
{ pattern: /(UI|display|show|interface)/i, label: 'User interface' },
|
||||
{ pattern: /(schedule|time|cron)/i, label: 'Scheduling' },
|
||||
{ pattern: /(config|setting|option)/i, label: 'Configuration' },
|
||||
{ pattern: /(test|testing|spec)/i, label: 'Testing' },
|
||||
{ pattern: /(auth|login|user)/i, label: 'Authentication' },
|
||||
{ pattern: /(database|db|data)/i, label: 'Data management' },
|
||||
{ pattern: /(api|endpoint|route)/i, label: 'API development' },
|
||||
{ pattern: /(deploy|build|release)/i, label: 'Deployment' },
|
||||
{ pattern: /(security|auth|login|user)/i, label: 'Security' },
|
||||
{ pattern: /.*/, label: 'Other' }
|
||||
];
|
||||
|
||||
/**
|
||||
* Relevance score thresholds
|
||||
*/
|
||||
const RELEVANCE_THRESHOLDS = {
|
||||
high: 0.25,
|
||||
medium: 0.4,
|
||||
low: 0.6
|
||||
};
|
||||
|
||||
/**
|
||||
* Fuzzy search utility class for finding relevant tasks
|
||||
*/
|
||||
export class FuzzyTaskSearch {
|
||||
constructor(tasks, searchType = 'default') {
|
||||
this.tasks = tasks;
|
||||
this.config = SEARCH_CONFIGS[searchType] || SEARCH_CONFIGS.default;
|
||||
this.searchableTasks = this._prepareSearchableTasks(tasks);
|
||||
this.fuse = new Fuse(this.searchableTasks, {
|
||||
includeScore: true,
|
||||
threshold: this.config.threshold,
|
||||
keys: this.config.keys,
|
||||
shouldSort: true,
|
||||
useExtendedSearch: true,
|
||||
limit: this.config.limit
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Prepare tasks for searching by expanding dependency titles
|
||||
* @param {Array} tasks - Array of task objects
|
||||
* @returns {Array} Tasks with expanded dependency information
|
||||
*/
|
||||
_prepareSearchableTasks(tasks) {
|
||||
return tasks.map((task) => {
|
||||
// Get titles of this task's dependencies if they exist
|
||||
const dependencyTitles =
|
||||
task.dependencies?.length > 0
|
||||
? task.dependencies
|
||||
.map((depId) => {
|
||||
const depTask = tasks.find((t) => t.id === depId);
|
||||
return depTask ? depTask.title : '';
|
||||
})
|
||||
.filter((title) => title)
|
||||
.join(' ')
|
||||
: '';
|
||||
|
||||
return {
|
||||
...task,
|
||||
dependencyTitles
|
||||
};
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Extract significant words from a prompt
|
||||
* @param {string} prompt - The search prompt
|
||||
* @returns {Array<string>} Array of significant words
|
||||
*/
|
||||
_extractPromptWords(prompt) {
|
||||
return prompt
|
||||
.toLowerCase()
|
||||
.replace(/[^\w\s-]/g, ' ') // Replace non-alphanumeric chars with spaces
|
||||
.split(/\s+/)
|
||||
.filter((word) => word.length > 3); // Words at least 4 chars
|
||||
}
|
||||
|
||||
/**
|
||||
* Find tasks related to a prompt using fuzzy search
|
||||
* @param {string} prompt - The search prompt
|
||||
* @param {Object} options - Search options
|
||||
* @param {number} [options.maxResults=8] - Maximum number of results to return
|
||||
* @param {boolean} [options.includeRecent=true] - Include recent tasks in results
|
||||
* @param {boolean} [options.includeCategoryMatches=true] - Include category-based matches
|
||||
* @returns {Object} Search results with relevance breakdown
|
||||
*/
|
||||
findRelevantTasks(prompt, options = {}) {
|
||||
const {
|
||||
maxResults = 8,
|
||||
includeRecent = true,
|
||||
includeCategoryMatches = true
|
||||
} = options;
|
||||
|
||||
// Extract significant words from prompt
|
||||
const promptWords = this._extractPromptWords(prompt);
|
||||
|
||||
// Perform fuzzy search with full prompt
|
||||
const fuzzyResults = this.fuse.search(prompt);
|
||||
|
||||
// Also search for each significant word to catch different aspects
|
||||
let wordResults = [];
|
||||
for (const word of promptWords) {
|
||||
if (word.length > 5) {
|
||||
// Only use significant words
|
||||
const results = this.fuse.search(word);
|
||||
if (results.length > 0) {
|
||||
wordResults.push(...results);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Merge and deduplicate results
|
||||
const mergedResults = [...fuzzyResults];
|
||||
|
||||
// Add word results that aren't already in fuzzyResults
|
||||
for (const wordResult of wordResults) {
|
||||
if (!mergedResults.some((r) => r.item.id === wordResult.item.id)) {
|
||||
mergedResults.push(wordResult);
|
||||
}
|
||||
}
|
||||
|
||||
// Group search results by relevance
|
||||
const highRelevance = mergedResults
|
||||
.filter((result) => result.score < RELEVANCE_THRESHOLDS.high)
|
||||
.map((result) => ({ ...result.item, score: result.score }));
|
||||
|
||||
const mediumRelevance = mergedResults
|
||||
.filter(
|
||||
(result) =>
|
||||
result.score >= RELEVANCE_THRESHOLDS.high &&
|
||||
result.score < RELEVANCE_THRESHOLDS.medium
|
||||
)
|
||||
.map((result) => ({ ...result.item, score: result.score }));
|
||||
|
||||
const lowRelevance = mergedResults
|
||||
.filter(
|
||||
(result) =>
|
||||
result.score >= RELEVANCE_THRESHOLDS.medium &&
|
||||
result.score < RELEVANCE_THRESHOLDS.low
|
||||
)
|
||||
.map((result) => ({ ...result.item, score: result.score }));
|
||||
|
||||
// Get recent tasks (newest first) if requested
|
||||
const recentTasks = includeRecent
|
||||
? [...this.tasks].sort((a, b) => b.id - a.id).slice(0, 5)
|
||||
: [];
|
||||
|
||||
// Find category-based matches if requested
|
||||
let categoryTasks = [];
|
||||
let promptCategory = null;
|
||||
if (includeCategoryMatches) {
|
||||
promptCategory = PURPOSE_CATEGORIES.find((cat) =>
|
||||
cat.pattern.test(prompt)
|
||||
);
|
||||
categoryTasks = promptCategory
|
||||
? this.tasks
|
||||
.filter(
|
||||
(t) =>
|
||||
promptCategory.pattern.test(t.title) ||
|
||||
promptCategory.pattern.test(t.description) ||
|
||||
(t.details && promptCategory.pattern.test(t.details))
|
||||
)
|
||||
.slice(0, 3)
|
||||
: [];
|
||||
}
|
||||
|
||||
// Combine all relevant tasks, prioritizing by relevance
|
||||
const allRelevantTasks = [...highRelevance];
|
||||
|
||||
// Add medium relevance if not already included
|
||||
for (const task of mediumRelevance) {
|
||||
if (!allRelevantTasks.some((t) => t.id === task.id)) {
|
||||
allRelevantTasks.push(task);
|
||||
}
|
||||
}
|
||||
|
||||
// Add low relevance if not already included
|
||||
for (const task of lowRelevance) {
|
||||
if (!allRelevantTasks.some((t) => t.id === task.id)) {
|
||||
allRelevantTasks.push(task);
|
||||
}
|
||||
}
|
||||
|
||||
// Add category tasks if not already included
|
||||
for (const task of categoryTasks) {
|
||||
if (!allRelevantTasks.some((t) => t.id === task.id)) {
|
||||
allRelevantTasks.push(task);
|
||||
}
|
||||
}
|
||||
|
||||
// Add recent tasks if not already included
|
||||
for (const task of recentTasks) {
|
||||
if (!allRelevantTasks.some((t) => t.id === task.id)) {
|
||||
allRelevantTasks.push(task);
|
||||
}
|
||||
}
|
||||
|
||||
// Get top N results for final output
|
||||
const finalResults = allRelevantTasks.slice(0, maxResults);
|
||||
|
||||
return {
|
||||
results: finalResults,
|
||||
breakdown: {
|
||||
highRelevance,
|
||||
mediumRelevance,
|
||||
lowRelevance,
|
||||
categoryTasks,
|
||||
recentTasks,
|
||||
promptCategory,
|
||||
promptWords
|
||||
},
|
||||
metadata: {
|
||||
totalSearched: this.tasks.length,
|
||||
fuzzyMatches: fuzzyResults.length,
|
||||
wordMatches: wordResults.length,
|
||||
finalCount: finalResults.length
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Get task IDs from search results
|
||||
* @param {Object} searchResults - Results from findRelevantTasks
|
||||
* @returns {Array<string>} Array of task ID strings
|
||||
*/
|
||||
getTaskIds(searchResults) {
|
||||
return searchResults.results.map((task) => {
|
||||
// Use searchableId if available (for flattened tasks with subtasks)
|
||||
// Otherwise fall back to regular id
|
||||
return task.searchableId || task.id.toString();
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Get task IDs including subtasks from search results
|
||||
* @param {Object} searchResults - Results from findRelevantTasks
|
||||
* @param {boolean} [includeSubtasks=false] - Whether to include subtask IDs
|
||||
* @returns {Array<string>} Array of task and subtask ID strings
|
||||
*/
|
||||
getTaskIdsWithSubtasks(searchResults, includeSubtasks = false) {
|
||||
const taskIds = [];
|
||||
|
||||
for (const task of searchResults.results) {
|
||||
taskIds.push(task.id.toString());
|
||||
|
||||
if (includeSubtasks && task.subtasks && task.subtasks.length > 0) {
|
||||
for (const subtask of task.subtasks) {
|
||||
taskIds.push(`${task.id}.${subtask.id}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return taskIds;
|
||||
}
|
||||
|
||||
/**
|
||||
* Format search results for display
|
||||
* @param {Object} searchResults - Results from findRelevantTasks
|
||||
* @param {Object} options - Formatting options
|
||||
* @returns {string} Formatted search results summary
|
||||
*/
|
||||
formatSearchSummary(searchResults, options = {}) {
|
||||
const { includeScores = false, includeBreakdown = false } = options;
|
||||
const { results, breakdown, metadata } = searchResults;
|
||||
|
||||
let summary = `Found ${results.length} relevant tasks from ${metadata.totalSearched} total tasks`;
|
||||
|
||||
if (includeBreakdown && breakdown) {
|
||||
const parts = [];
|
||||
if (breakdown.highRelevance.length > 0)
|
||||
parts.push(`${breakdown.highRelevance.length} high relevance`);
|
||||
if (breakdown.mediumRelevance.length > 0)
|
||||
parts.push(`${breakdown.mediumRelevance.length} medium relevance`);
|
||||
if (breakdown.lowRelevance.length > 0)
|
||||
parts.push(`${breakdown.lowRelevance.length} low relevance`);
|
||||
if (breakdown.categoryTasks.length > 0)
|
||||
parts.push(`${breakdown.categoryTasks.length} category matches`);
|
||||
|
||||
if (parts.length > 0) {
|
||||
summary += ` (${parts.join(', ')})`;
|
||||
}
|
||||
|
||||
if (breakdown.promptCategory) {
|
||||
summary += `\nCategory detected: ${breakdown.promptCategory.label}`;
|
||||
}
|
||||
}
|
||||
|
||||
return summary;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Factory function to create a fuzzy search instance
|
||||
* @param {Array} tasks - Array of task objects
|
||||
* @param {string} [searchType='default'] - Type of search configuration to use
|
||||
* @returns {FuzzyTaskSearch} Fuzzy search instance
|
||||
*/
|
||||
export function createFuzzyTaskSearch(tasks, searchType = 'default') {
|
||||
return new FuzzyTaskSearch(tasks, searchType);
|
||||
}
|
||||
|
||||
/**
|
||||
* Quick utility function to find relevant task IDs for a prompt
|
||||
* @param {Array} tasks - Array of task objects
|
||||
* @param {string} prompt - Search prompt
|
||||
* @param {Object} options - Search options
|
||||
* @returns {Array<string>} Array of relevant task ID strings
|
||||
*/
|
||||
export function findRelevantTaskIds(tasks, prompt, options = {}) {
|
||||
const {
|
||||
searchType = 'default',
|
||||
maxResults = 8,
|
||||
includeSubtasks = false
|
||||
} = options;
|
||||
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasks, searchType);
|
||||
const results = fuzzySearch.findRelevantTasks(prompt, { maxResults });
|
||||
|
||||
return includeSubtasks
|
||||
? fuzzySearch.getTaskIdsWithSubtasks(results, true)
|
||||
: fuzzySearch.getTaskIds(results);
|
||||
}
|
||||
|
||||
export default FuzzyTaskSearch;
|
||||
186
scripts/modules/utils/gatewayErrorHandler.js
Normal file
186
scripts/modules/utils/gatewayErrorHandler.js
Normal file
@@ -0,0 +1,186 @@
|
||||
/**
|
||||
* Enhanced error handler for gateway responses
|
||||
* @param {Error} error - The error from the gateway call
|
||||
* @param {string} commandName - The command being executed
|
||||
*/
|
||||
function handleGatewayError(error, commandName) {
|
||||
try {
|
||||
// Extract status code and response from error message
|
||||
const match = error.message.match(/Gateway AI call failed: (\d+) (.+)/);
|
||||
if (!match) {
|
||||
throw new Error(`Unexpected error format: ${error.message}`);
|
||||
}
|
||||
|
||||
const [, statusCode, responseText] = match;
|
||||
const status = parseInt(statusCode);
|
||||
|
||||
let response;
|
||||
try {
|
||||
response = JSON.parse(responseText);
|
||||
} catch {
|
||||
// Handle non-JSON error responses
|
||||
console.error(`[ERROR] Gateway error (${status}): ${responseText}`);
|
||||
return;
|
||||
}
|
||||
|
||||
switch (status) {
|
||||
case 400:
|
||||
handleValidationError(response, commandName);
|
||||
break;
|
||||
case 401:
|
||||
handleAuthError(response, commandName);
|
||||
break;
|
||||
case 402:
|
||||
handleCreditError(response, commandName);
|
||||
break;
|
||||
case 403:
|
||||
handleAccessDeniedError(response, commandName);
|
||||
break;
|
||||
case 429:
|
||||
handleRateLimitError(response, commandName);
|
||||
break;
|
||||
case 500:
|
||||
handleServerError(response, commandName);
|
||||
break;
|
||||
default:
|
||||
console.error(
|
||||
`[ERROR] Unexpected gateway error (${status}):`,
|
||||
response
|
||||
);
|
||||
}
|
||||
} catch (parseError) {
|
||||
console.error(`[ERROR] Failed to parse gateway error: ${error.message}`);
|
||||
}
|
||||
}
|
||||
|
||||
function handleValidationError(response, commandName) {
|
||||
if (response.error?.includes("Unsupported model")) {
|
||||
console.error("🚫 The selected AI model is not supported by the gateway.");
|
||||
console.error(
|
||||
"💡 Try running `task-master models` to see available models."
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
if (response.error?.includes("schema is required")) {
|
||||
console.error("🚫 This command requires a schema for structured output.");
|
||||
console.error("💡 This is likely a bug - please report it.");
|
||||
return;
|
||||
}
|
||||
|
||||
console.error(`🚫 Invalid request: ${response.error}`);
|
||||
if (response.details?.length > 0) {
|
||||
response.details.forEach((detail) => {
|
||||
console.error(` • ${detail.message || detail}`);
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
function handleAuthError(response, commandName) {
|
||||
console.error("🔐 Authentication failed with TaskMaster gateway.");
|
||||
|
||||
if (response.message?.includes("Invalid token")) {
|
||||
console.error("💡 Your auth token may have expired. Try running:");
|
||||
console.error(" task-master init");
|
||||
} else if (response.message?.includes("Missing X-TaskMaster-Service-ID")) {
|
||||
console.error(
|
||||
"💡 Service authentication issue. This is likely a bug - please report it."
|
||||
);
|
||||
} else {
|
||||
console.error("💡 Please check your authentication settings.");
|
||||
}
|
||||
}
|
||||
|
||||
function handleCreditError(response, commandName) {
|
||||
console.error("💳 Insufficient credits for this operation.");
|
||||
console.error(`💡 ${response.message || "Your account needs more credits."}`);
|
||||
console.error(" • Visit your dashboard to add credits");
|
||||
console.error(" • Or upgrade to a plan with more credits");
|
||||
console.error(
|
||||
" • You can also switch to BYOK mode to use your own API keys"
|
||||
);
|
||||
}
|
||||
|
||||
function handleAccessDeniedError(response, commandName) {
|
||||
const { details, hint } = response;
|
||||
|
||||
if (
|
||||
details?.planType === "byok" &&
|
||||
details?.subscriptionStatus === "inactive"
|
||||
) {
|
||||
console.error(
|
||||
"🔒 BYOK users need active subscriptions for hosted AI services."
|
||||
);
|
||||
console.error("💡 You have two options:");
|
||||
console.error(" 1. Upgrade to a paid plan for hosted AI services");
|
||||
console.error(" 2. Switch to BYOK mode and use your own API keys");
|
||||
console.error("");
|
||||
console.error(" To use your own API keys:");
|
||||
console.error(
|
||||
" • Set your API keys in .env file (e.g., ANTHROPIC_API_KEY=...)"
|
||||
);
|
||||
console.error(" • The system will automatically use direct API calls");
|
||||
return;
|
||||
}
|
||||
|
||||
if (details?.subscriptionStatus === "past_due") {
|
||||
console.error("💳 Your subscription payment is overdue.");
|
||||
console.error(
|
||||
"💡 Please update your payment method to continue using AI services."
|
||||
);
|
||||
console.error(
|
||||
" Visit your account dashboard to update billing information."
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
if (details?.planType === "free" && commandName === "research") {
|
||||
console.error("🔬 Research features require a paid subscription.");
|
||||
console.error("💡 Upgrade your plan to access research-powered commands.");
|
||||
return;
|
||||
}
|
||||
|
||||
console.error(`🔒 Access denied: ${response.message}`);
|
||||
if (hint) {
|
||||
console.error(`💡 ${hint}`);
|
||||
}
|
||||
}
|
||||
|
||||
function handleRateLimitError(response, commandName) {
|
||||
const retryAfter = response.retryAfter || 60;
|
||||
console.error("⏱️ Rate limit exceeded - too many requests.");
|
||||
console.error(`💡 Please wait ${retryAfter} seconds before trying again.`);
|
||||
console.error(" Consider upgrading your plan for higher rate limits.");
|
||||
}
|
||||
|
||||
function handleServerError(response, commandName) {
|
||||
const retryAfter = response.retryAfter || 10;
|
||||
|
||||
if (response.error?.includes("Service temporarily unavailable")) {
|
||||
console.error("🚧 TaskMaster gateway is temporarily unavailable.");
|
||||
console.error(
|
||||
`💡 The service should recover automatically. Try again in ${retryAfter} seconds.`
|
||||
);
|
||||
console.error(
|
||||
" You can also switch to BYOK mode to use direct API calls."
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
if (response.message?.includes("No user message found")) {
|
||||
console.error("🚫 Invalid request format - missing user message.");
|
||||
console.error("💡 This is likely a bug - please report it.");
|
||||
return;
|
||||
}
|
||||
|
||||
console.error("⚠️ Gateway server error occurred.");
|
||||
console.error(
|
||||
`💡 Try again in ${retryAfter} seconds. If the problem persists:`
|
||||
);
|
||||
console.error(" • Check TaskMaster status page");
|
||||
console.error(" • Switch to BYOK mode as a workaround");
|
||||
console.error(" • Contact support if the issue continues");
|
||||
}
|
||||
|
||||
// Export the main handler function
|
||||
export { handleGatewayError };
|
||||
@@ -1,9 +1,9 @@
|
||||
{
|
||||
"meta": {
|
||||
"generatedAt": "2025-05-22T05:48:33.026Z",
|
||||
"tasksAnalyzed": 6,
|
||||
"totalTasks": 88,
|
||||
"analysisCount": 43,
|
||||
"generatedAt": "2025-05-27T16:34:53.088Z",
|
||||
"tasksAnalyzed": 1,
|
||||
"totalTasks": 84,
|
||||
"analysisCount": 45,
|
||||
"thresholdScore": 5,
|
||||
"projectName": "Taskmaster",
|
||||
"usedResearch": true
|
||||
@@ -313,14 +313,6 @@
|
||||
"expansionPrompt": "Break down the update of ai-services-unified.js for dynamic token limits into subtasks such as: (1) Import and integrate the token counting utility, (2) Refactor _unifiedServiceRunner to calculate and enforce dynamic token limits, (3) Update error handling for token limit violations, (4) Add and verify logging for token usage, (5) Write and execute tests for various prompt and model scenarios.",
|
||||
"reasoning": "This task involves significant code changes to a core function, integration of a new utility, dynamic logic for multiple models, and robust error handling. It also requires comprehensive testing for edge cases and integration, making it moderately complex and best managed by splitting into focused subtasks."
|
||||
},
|
||||
{
|
||||
"taskId": 86,
|
||||
"taskTitle": "Update .taskmasterconfig schema and user guide",
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand this task into subtasks: (1) Draft a migration guide for users, (2) Update user documentation to explain new config fields, (3) Modify schema validation logic in config-manager.js, (4) Test and validate backward compatibility and error messaging.",
|
||||
"reasoning": "The task spans documentation, schema changes, migration guidance, and validation logic. While not algorithmically complex, it requires careful coordination and thorough testing to ensure a smooth user transition and robust validation."
|
||||
},
|
||||
{
|
||||
"taskId": 87,
|
||||
"taskTitle": "Implement validation and error handling",
|
||||
@@ -352,6 +344,30 @@
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand this task into: (1) Implement move logic for tasks and subtasks, (2) Handle edge cases (invalid ids, non-existent parents, circular dependencies), (3) Update CLI to support move command with flags, (4) Ensure data integrity and update relationships, (5) Write and execute tests for various move scenarios.",
|
||||
"reasoning": "Moving tasks and subtasks requires careful handling of hierarchical data, edge cases, and data integrity. The command must be robust and user-friendly, necessitating multiple focused subtasks for safe implementation."
|
||||
},
|
||||
{
|
||||
"taskId": 92,
|
||||
"taskTitle": "Add Global Joke Flag to All CLI Commands",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Break down the implementation of the global --joke flag into the following subtasks: (1) Update CLI foundation to support global flags, (2) Develop the joke-service module with joke management and category support, (3) Integrate joke output into existing output utilities, (4) Update all CLI commands for joke flag compatibility, (5) Add configuration options for joke categories and custom jokes, (6) Implement comprehensive testing (flag recognition, output, content, integration, performance, regression), (7) Update documentation and usage examples.",
|
||||
"reasoning": "This task requires changes across the CLI foundation, output utilities, all command modules, and configuration management. It introduces a new service module, global flag handling, and output logic that must not interfere with existing features (including JSON output). The need for robust testing and backward compatibility further increases complexity. The scope spans multiple code areas and requires careful integration, justifying a high complexity score and a detailed subtask breakdown to manage risk and ensure maintainability.[2][3][5]"
|
||||
},
|
||||
{
|
||||
"taskId": 94,
|
||||
"taskTitle": "Implement Standalone 'research' CLI Command for AI-Powered Queries",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Break down the implementation of the 'research' CLI command into logical subtasks covering command registration, parameter handling, context gathering, AI service integration, output formatting, and documentation.",
|
||||
"reasoning": "This task has moderate to high complexity (7/10) due to multiple interconnected components: CLI argument parsing, integration with AI services, context gathering from various sources, and output formatting with different modes. The cyclomatic complexity would be significant with multiple decision paths for handling different flags and options. The task requires understanding existing patterns and extending the codebase in a consistent manner, suggesting the need for careful decomposition into manageable subtasks."
|
||||
},
|
||||
{
|
||||
"taskId": 86,
|
||||
"taskTitle": "Implement GitHub Issue Export Feature",
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 10,
|
||||
"expansionPrompt": "Break down the implementation of the GitHub Issue Export Feature into detailed subtasks covering: command structure and CLI integration, GitHub API client development, authentication and error handling, task-to-issue mapping logic, content formatting and markdown conversion, bidirectional linking and metadata management, extensible architecture and adapter interfaces, configuration and settings management, documentation, and comprehensive testing (unit, integration, edge cases, performance).",
|
||||
"reasoning": "This task involves designing and implementing a robust, extensible export system with deep integration into GitHub, including bidirectional workflows, complex data mapping, error handling, and support for future platforms. The requirements span CLI design, API integration, content transformation, metadata management, extensibility, configuration, and extensive testing. The breadth and depth of these requirements, along with the need for maintainability and future extensibility, place this task at a high complexity level. Breaking it into at least 10 subtasks will ensure each major component and concern is addressed systematically, reducing risk and improving quality."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -3,56 +3,132 @@
|
||||
# Status: pending
|
||||
# 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.
|
||||
# Description: Implement a comprehensive LLM-powered 'import_task' command that can intelligently import tasks from GitHub Issues and Discussions. The system uses our existing ContextGatherer.js infrastructure to analyze the full context of GitHub content and automatically generate well-structured tasks with appropriate subtasks, priorities, and implementation 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:
|
||||
Implement a new flag '--from-github' for the add-task command that allows users to create tasks directly from GitHub issues. The implementation should:
|
||||
Implement a new 'import_task' command that leverages LLM-powered analysis to create comprehensive tasks from GitHub Issues and Discussions. The system should be designed as an extensible import framework that can support multiple platforms in the future.
|
||||
|
||||
1. Accept a GitHub issue URL as an argument (e.g., 'taskmaster add-task --from-github https://github.com/owner/repo/issues/123')
|
||||
2. Parse the URL to extract the repository owner, name, and issue number
|
||||
3. Use the GitHub API to fetch the issue details including:
|
||||
- Issue title (to be used as task title)
|
||||
- Issue description (to be used as task description)
|
||||
- Issue labels (to be potentially used as tags)
|
||||
- Issue assignees (for reference)
|
||||
- Issue status (open/closed)
|
||||
4. Generate a well-formatted task with this information
|
||||
5. Include a reference link back to the original GitHub issue
|
||||
6. Handle authentication for private repositories using GitHub tokens from environment variables or config file
|
||||
7. Implement proper error handling for:
|
||||
- Invalid URLs
|
||||
- Non-existent issues
|
||||
- API rate limiting
|
||||
- Authentication failures
|
||||
- Network issues
|
||||
8. Allow users to override or supplement the imported details with additional command-line arguments
|
||||
9. Add appropriate documentation in help text and user guide
|
||||
Core functionality:
|
||||
1. **New Command Structure**: Create 'import_task' command with source-specific subcommands:
|
||||
- 'taskmaster import_task github <URL>' for GitHub imports
|
||||
- Future: 'taskmaster import_task gitlab <URL>', 'taskmaster import_task linear <URL>', etc.
|
||||
|
||||
2. **Multi-Source GitHub Support**: Automatically detect and handle:
|
||||
- GitHub Issues: https://github.com/owner/repo/issues/123
|
||||
- GitHub Discussions: https://github.com/owner/repo/discussions/456
|
||||
- Auto-detect URL type and use appropriate API endpoints
|
||||
|
||||
3. **LLM-Powered Context Analysis**: Integrate with ContextGatherer.js to:
|
||||
- Fetch complete GitHub content (main post + all comments/replies)
|
||||
- Analyze discussion threads and extract key insights
|
||||
- Identify references to our project components and codebase
|
||||
- Generate comprehensive task descriptions based on full context
|
||||
- Automatically create relevant subtasks from complex discussions
|
||||
- Determine appropriate priority levels based on content analysis
|
||||
- Suggest dependencies based on mentioned components/features
|
||||
|
||||
4. **Smart Content Processing**: The LLM should:
|
||||
- Parse markdown content and preserve important formatting
|
||||
- Extract actionable items from discussion threads
|
||||
- Identify implementation requirements and technical details
|
||||
- Convert complex discussions into structured task breakdowns
|
||||
- Generate appropriate test strategies based on the scope
|
||||
- Preserve important context while creating focused task descriptions
|
||||
|
||||
5. **Enhanced GitHub API Integration**:
|
||||
- Support GITHUB_API_KEY environment variable for authentication
|
||||
- Handle both public and private repository access
|
||||
- Fetch issue/discussion metadata (labels, assignees, status)
|
||||
- Retrieve complete comment threads with proper threading
|
||||
- Implement rate limiting and error handling
|
||||
|
||||
6. **Rich Metadata Storage**:
|
||||
- Source platform and original URL
|
||||
- Import timestamp and LLM model version used
|
||||
- Content hash for change detection and sync capabilities
|
||||
- Participant information and discussion context
|
||||
- GitHub-specific metadata (labels, assignees, status)
|
||||
- **Use consistent metadata schema with export feature (Task #97)**
|
||||
|
||||
7. **Future-Proof Architecture**:
|
||||
- Modular design supporting multiple import sources
|
||||
- Plugin-style architecture for new platforms
|
||||
- Extensible content type handling (issues, PRs, discussions, etc.)
|
||||
- Configurable LLM prompts for different content types
|
||||
|
||||
8. **Bidirectional Integration**:
|
||||
- Maintain compatibility with GitHub export feature
|
||||
- Enable round-trip workflows (import → modify → export)
|
||||
- Preserve source linking for synchronization capabilities
|
||||
- Support identification of imported vs. native tasks
|
||||
|
||||
9. **Error Handling and Validation**:
|
||||
- Validate GitHub URLs and accessibility
|
||||
- Handle API rate limiting gracefully
|
||||
- Provide meaningful error messages for various failure scenarios
|
||||
- Implement retry logic for transient failures
|
||||
- Validate LLM responses and handle generation errors
|
||||
|
||||
10. **Configuration and Customization**:
|
||||
- Allow users to customize LLM prompts for task generation
|
||||
- Support different import strategies (full vs. summary)
|
||||
- Enable filtering of comments by date, author, or relevance
|
||||
- Provide options for manual review before task creation
|
||||
|
||||
# Test Strategy:
|
||||
Testing should cover the following scenarios:
|
||||
Testing should cover the comprehensive LLM-powered import system:
|
||||
|
||||
1. Unit tests:
|
||||
- Test URL parsing functionality with valid and invalid GitHub issue URLs
|
||||
- Test GitHub API response parsing with mocked API responses
|
||||
- Test error handling for various failure cases
|
||||
1. **Unit Tests**:
|
||||
- Test URL parsing for GitHub Issues and Discussions
|
||||
- Test GitHub API client with mocked responses
|
||||
- Test LLM integration with ContextGatherer.js
|
||||
- Test metadata schema consistency with export feature
|
||||
- Test content processing and task generation logic
|
||||
- Test error handling for various failure scenarios
|
||||
|
||||
2. Integration tests:
|
||||
- Test with real GitHub public issues (use well-known repositories)
|
||||
- Test with both open and closed issues
|
||||
- Test with issues containing various elements (labels, assignees, comments)
|
||||
2. **Integration Tests**:
|
||||
- Test with real GitHub Issues and Discussions (public repos)
|
||||
- Test LLM-powered analysis with various content types
|
||||
- Test ContextGatherer integration with GitHub content
|
||||
- Test bidirectional compatibility with export feature
|
||||
- Test metadata structure and storage
|
||||
- Test with different GitHub content complexities
|
||||
|
||||
3. Error case tests:
|
||||
- Invalid URL format
|
||||
- Non-existent repository
|
||||
- Non-existent issue number
|
||||
- API rate limit exceeded
|
||||
3. **LLM and Context Analysis Tests**:
|
||||
- Test task generation quality with various GitHub content types
|
||||
- Test subtask creation from complex discussions
|
||||
- Test priority and dependency inference
|
||||
- Test handling of code references and technical discussions
|
||||
- Test content summarization and structure preservation
|
||||
- Validate LLM prompt effectiveness and response quality
|
||||
|
||||
4. **Error Case Tests**:
|
||||
- Invalid or malformed GitHub URLs
|
||||
- Non-existent repositories or issues/discussions
|
||||
- API rate limit handling
|
||||
- Authentication failures for private repos
|
||||
- LLM service unavailability or errors
|
||||
- Network connectivity issues
|
||||
- Malformed or incomplete GitHub content
|
||||
|
||||
4. End-to-end tests:
|
||||
- Verify that a task created from a GitHub issue contains all expected information
|
||||
- Verify that the task can be properly managed after creation
|
||||
- Test the interaction with other flags and commands
|
||||
5. **End-to-End Tests**:
|
||||
- Complete import workflow from GitHub URL to created task
|
||||
- Verify task quality and completeness
|
||||
- Test metadata preservation and linking
|
||||
- Test compatibility with existing task management features
|
||||
- Verify bidirectional workflow with export feature
|
||||
|
||||
Create mock GitHub API responses for testing to avoid hitting rate limits during development and testing. Use environment variables to configure test credentials if needed.
|
||||
6. **Performance and Scalability Tests**:
|
||||
- Test with large GitHub discussions (many comments)
|
||||
- Test LLM processing time and resource usage
|
||||
- Test API rate limiting behavior
|
||||
- Test concurrent import operations
|
||||
|
||||
7. **Future Platform Preparation Tests**:
|
||||
- Test modular architecture extensibility
|
||||
- Verify plugin-style platform addition capability
|
||||
- Test configuration system flexibility
|
||||
|
||||
Create comprehensive mock data for GitHub API responses including various issue/discussion types, comment structures, and edge cases. Use environment variables for test credentials and LLM service configuration.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design GitHub API integration architecture [pending]
|
||||
@@ -85,3 +161,63 @@ Map GitHub issue fields to task fields (title, description, etc.). Convert GitHu
|
||||
### Details:
|
||||
Design and implement UI for URL input and import confirmation. Show loading states during API calls. Display meaningful error messages for various failure scenarios. Allow users to review and modify imported task details before saving. Add automated tests for the entire import flow.
|
||||
|
||||
## 6. Implement GitHub metadata schema and link management [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a consistent metadata schema for GitHub links that works with both import and export features, ensuring bidirectional compatibility.
|
||||
### Details:
|
||||
Design and implement metadata structure that matches the export feature (Task #97). Include fields for GitHub issue URL, repository information, issue number, and sync status. Implement link validation to ensure GitHub URLs are accessible and valid. Create utilities for managing GitHub link metadata consistently across import and export operations.
|
||||
|
||||
## 7. Add bidirectional integration with export feature [pending]
|
||||
### Dependencies: 45.6
|
||||
### Description: Ensure imported tasks work seamlessly with the GitHub export feature and maintain consistent link management.
|
||||
### Details:
|
||||
Verify that tasks imported from GitHub can be properly exported back to GitHub. Implement checks to prevent duplicate exports of imported issues. Add metadata flags to identify imported tasks and their source repositories. Test round-trip workflows (import → modify → export) to ensure data integrity.
|
||||
|
||||
## 8. Design extensible import_task command architecture [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create the foundational architecture for the new import_task command that supports multiple platforms and content types.
|
||||
### Details:
|
||||
Design modular command structure with platform-specific subcommands. Create plugin-style architecture for adding new import sources. Define interfaces for different content types (issues, discussions, PRs). Plan configuration system for platform-specific settings and LLM prompts. Document extensibility patterns for future platform additions.
|
||||
|
||||
## 9. Extend GitHub URL parsing for Issues and Discussions [pending]
|
||||
### Dependencies: 45.2, 45.8
|
||||
### Description: Enhance URL parsing to support both GitHub Issues and Discussions with automatic type detection.
|
||||
### Details:
|
||||
Extend existing URL parser to handle GitHub Discussions URLs. Implement automatic detection of content type (issue vs discussion). Update validation logic for both content types. Ensure consistent data extraction for owner, repo, and content ID regardless of type.
|
||||
|
||||
## 10. Implement comprehensive GitHub API client [pending]
|
||||
### Dependencies: 45.3, 45.9
|
||||
### Description: Create enhanced GitHub API client supporting both Issues and Discussions APIs with complete content fetching.
|
||||
### Details:
|
||||
Extend existing API client to support GitHub Discussions API. Implement complete content fetching including all comments and replies. Add support for GITHUB_API_KEY environment variable. Handle threaded discussions and comment hierarchies. Implement robust error handling and rate limiting for both API types.
|
||||
|
||||
## 11. Integrate ContextGatherer for LLM-powered analysis [pending]
|
||||
### Dependencies: 45.10
|
||||
### Description: Integrate with existing ContextGatherer.js to enable LLM-powered analysis of GitHub content.
|
||||
### Details:
|
||||
Adapt ContextGatherer.js to work with GitHub content as input source. Create GitHub-specific context gathering strategies. Implement content preprocessing for optimal LLM analysis. Add project component identification for GitHub discussions. Create prompts for task generation from GitHub content.
|
||||
|
||||
## 12. Implement LLM-powered task generation [pending]
|
||||
### Dependencies: 45.11
|
||||
### Description: Create the core LLM integration that analyzes GitHub content and generates comprehensive tasks with subtasks.
|
||||
### Details:
|
||||
Design LLM prompts for task generation from GitHub content. Implement automatic subtask creation from complex discussions. Add priority and dependency inference based on content analysis. Create test strategy generation from technical discussions. Implement quality validation for LLM-generated content. Add fallback mechanisms for LLM failures.
|
||||
|
||||
## 13. Enhance metadata system for rich import context [pending]
|
||||
### Dependencies: 45.6, 45.12
|
||||
### Description: Extend the metadata schema to store comprehensive import context and enable advanced features.
|
||||
### Details:
|
||||
Extend existing metadata schema with import-specific fields. Add source platform, import timestamp, and LLM model tracking. Implement content hash storage for change detection. Store participant information and discussion context. Add support for custom metadata per platform type. Ensure backward compatibility with existing export feature metadata.
|
||||
|
||||
## 14. Implement import_task command interface [pending]
|
||||
### Dependencies: 45.8, 45.12, 45.13
|
||||
### Description: Create the user-facing command interface for the new import_task system with GitHub support.
|
||||
### Details:
|
||||
Implement the main import_task command with GitHub subcommand. Add command-line argument parsing and validation. Create progress indicators for LLM processing. Implement user review and confirmation workflow. Add verbose output options for debugging. Create help documentation and usage examples.
|
||||
|
||||
## 15. Add comprehensive testing and validation [pending]
|
||||
### Dependencies: 45.14
|
||||
### Description: Implement comprehensive testing suite covering all aspects of the LLM-powered import system.
|
||||
### Details:
|
||||
Create unit tests for all new components. Implement integration tests with real GitHub content. Add LLM response validation and quality tests. Create performance tests for large discussions. Implement end-to-end workflow testing. Add mock data for consistent testing. Test bidirectional compatibility with export feature.
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Task ID: 51
|
||||
# Title: Implement Perplexity Research Command
|
||||
# Title: Implement Interactive 'Explore' Command REPL
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Create an interactive REPL-style chat interface for AI-powered research that maintains conversation context, integrates project information, and provides session management capabilities.
|
||||
# Description: Create an interactive 'explore' command that launches a REPL-style chat interface for AI-powered research and project exploration with conversation context and session management.
|
||||
# Details:
|
||||
Develop an interactive REPL-style chat interface for AI-powered research that allows users to have ongoing research conversations with context awareness. The system should:
|
||||
Develop an interactive 'explore' command that provides a REPL-style chat interface for AI-powered research and project exploration. The system should:
|
||||
|
||||
1. Create an interactive REPL using inquirer that:
|
||||
- Maintains conversation history and context
|
||||
@@ -31,6 +31,7 @@ Develop an interactive REPL-style chat interface for AI-powered research that al
|
||||
- `/copy` - Copy last response to clipboard
|
||||
- `/summary` - Generate summary of conversation
|
||||
- `/detail` - Adjust research depth level
|
||||
- `/context` - Show current context information
|
||||
|
||||
5. Create session management capabilities:
|
||||
- Generate and track unique session IDs
|
||||
@@ -44,13 +45,19 @@ Develop an interactive REPL-style chat interface for AI-powered research that al
|
||||
- Progressive display of AI responses
|
||||
- Clear visual hierarchy and readability
|
||||
|
||||
7. Follow the "taskmaster way":
|
||||
7. Command specification:
|
||||
- Command name: `task-master explore` or `tm explore`
|
||||
- Accept optional parameters: --tasks, --files, --session
|
||||
- Generate project file tree for system context
|
||||
- Launch interactive REPL session
|
||||
|
||||
8. Follow the "taskmaster way":
|
||||
- Create something new and exciting
|
||||
- Focus on usefulness and practicality
|
||||
- Avoid over-engineering
|
||||
- Maintain consistency with existing patterns
|
||||
|
||||
The REPL should feel like a natural conversation while providing powerful research capabilities that integrate seamlessly with the rest of the system.
|
||||
The explore command should feel like a natural conversation while providing powerful research capabilities that integrate seamlessly with the rest of the system.
|
||||
|
||||
# Test Strategy:
|
||||
1. Unit tests:
|
||||
@@ -66,7 +73,7 @@ The REPL should feel like a natural conversation while providing powerful resear
|
||||
- Verify context switching between different tasks and files
|
||||
|
||||
3. User acceptance testing:
|
||||
- Have team members use the REPL for real research needs
|
||||
- Have team members use the explore command for real research needs
|
||||
- Test the conversation flow and command usability
|
||||
- Verify the UI is intuitive and responsive
|
||||
- Test with various terminal sizes and environments
|
||||
@@ -83,6 +90,7 @@ The REPL should feel like a natural conversation while providing powerful resear
|
||||
- Verify export features create properly formatted files
|
||||
- Test session recovery from simulated crashes
|
||||
- Validate handling of special characters and unicode
|
||||
- Test command line parameter parsing for --tasks, --files, --session
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Perplexity API Client Service [cancelled]
|
||||
@@ -162,31 +170,30 @@ REFACTORED IMPLEMENTATION:
|
||||
This approach leverages our existing sophisticated search logic rather than rebuilding from scratch, while making it more flexible and reusable across the application.
|
||||
</info added on 2025-05-23T21:11:44.560Z>
|
||||
|
||||
## 3. Build Research Command CLI Interface [pending]
|
||||
### Dependencies: 51.1, 51.2
|
||||
### Description: Implement the Commander.js command structure for the 'research' command with all required options and parameters.
|
||||
## 3. Build Explore Command CLI Interface [pending]
|
||||
### Dependencies: 51.2
|
||||
### Description: Implement the Commander.js command structure for the 'explore' command with all required options and parameters to launch the interactive REPL.
|
||||
### Details:
|
||||
Implementation details:
|
||||
1. Create a new command file `commands/research.js`
|
||||
1. Create a new command file `commands/explore.js`
|
||||
2. Set up the Commander.js command structure with the following options:
|
||||
- Required search query parameter
|
||||
- `--task` or `-t` option for task/subtask ID
|
||||
- `--prompt` or `-p` option for custom research prompt
|
||||
- `--save` or `-s` option to save results to a file
|
||||
- `--copy` or `-c` option to copy results to clipboard
|
||||
- `--summary` or `-m` option to generate a summary
|
||||
- `--detail` or `-d` option to set research depth (default: medium)
|
||||
3. Implement command validation logic
|
||||
4. Connect the command to the Perplexity service created in subtask 1
|
||||
5. Integrate the context extraction logic from subtask 2
|
||||
- `--tasks` or `-t` option for task/subtask IDs (comma-separated)
|
||||
- `--files` or `-f` option for file paths (comma-separated)
|
||||
- `--session` or `-s` option to resume a previous session
|
||||
- `--context` or `-c` option for custom initial context
|
||||
3. Implement command validation logic for parameters
|
||||
4. Create entry point that launches the interactive REPL
|
||||
5. Integrate context initialization from command line parameters
|
||||
6. Register the command in the main CLI application
|
||||
7. Add help text and examples
|
||||
7. Add help text and usage examples
|
||||
8. Implement parameter parsing for task IDs and file paths
|
||||
|
||||
Testing approach:
|
||||
- Test command registration and option parsing
|
||||
- Verify command validation logic works correctly
|
||||
- Test with various combinations of options
|
||||
- Ensure proper error messages for invalid inputs
|
||||
- Test parameter parsing for complex task ID formats
|
||||
<info added on 2025-05-23T21:09:08.478Z>
|
||||
Implementation details:
|
||||
1. Create a new module `repl/research-chat.js` for the interactive research experience
|
||||
@@ -222,30 +229,45 @@ Testing approach:
|
||||
- Validate UI consistency across different terminal environments
|
||||
</info added on 2025-05-23T21:09:08.478Z>
|
||||
|
||||
## 4. Implement Results Processing and Output Formatting [pending]
|
||||
### Dependencies: 51.1, 51.3
|
||||
### Description: Create functionality to process, format, and display research results in the terminal with options for saving, copying, and summarizing.
|
||||
## 4. Implement Chat Formatting and Display System [pending]
|
||||
### Dependencies: 51.3
|
||||
### Description: Create functionality to format and display conversational research interactions in the terminal with streaming responses and markdown support.
|
||||
### Details:
|
||||
Implementation details:
|
||||
1. Create a new module `utils/researchFormatter.js`
|
||||
2. Implement terminal output formatting with:
|
||||
- Color-coded sections for better readability
|
||||
- Proper text wrapping for terminal width
|
||||
- Highlighting of key points
|
||||
3. Add functionality to save results to a file:
|
||||
- Create a `research-results` directory if it doesn't exist
|
||||
- Save results with timestamp and query in filename
|
||||
- Support multiple formats (text, markdown, JSON)
|
||||
4. Implement clipboard copying using a library like `clipboardy`
|
||||
5. Create a summarization function that extracts key points from research results
|
||||
6. Add progress indicators during API calls
|
||||
7. Implement pagination for long results
|
||||
1. Create a new module `utils/chatFormatter.js` for REPL interface formatting
|
||||
2. Implement terminal output formatting for conversational display:
|
||||
- Color-coded messages distinguishing user inputs and AI responses
|
||||
- Proper text wrapping and indentation for readability
|
||||
- Support for markdown rendering in terminal
|
||||
- Visual indicators for system messages and status updates
|
||||
3. Implement streaming/progressive display of AI responses:
|
||||
- Character-by-character or chunk-by-chunk display
|
||||
- Cursor animations during response generation
|
||||
- Ability to interrupt long responses
|
||||
4. Design chat history visualization:
|
||||
- Scrollable history with clear message boundaries
|
||||
- Timestamp display options
|
||||
- Session identification
|
||||
5. Create specialized formatters for different content types:
|
||||
- Code blocks with syntax highlighting
|
||||
- Bulleted and numbered lists
|
||||
- Tables and structured data
|
||||
- Citations and references
|
||||
6. Implement export functionality:
|
||||
- Save conversations to markdown or text files
|
||||
- Export individual responses
|
||||
- Copy responses to clipboard
|
||||
7. Adapt existing ui.js patterns for conversational context:
|
||||
- Maintain consistent styling while supporting chat flow
|
||||
- Handle multi-turn context appropriately
|
||||
|
||||
Testing approach:
|
||||
- Test output formatting with various result lengths and content types
|
||||
- Verify file saving functionality creates proper files with correct content
|
||||
- Test clipboard functionality
|
||||
- Verify summarization produces useful results
|
||||
- Test streaming display with various response lengths and speeds
|
||||
- Verify markdown rendering accuracy for complex formatting
|
||||
- Test history navigation and scrolling functionality
|
||||
- Verify export features create properly formatted files
|
||||
- Test display on various terminal sizes and configurations
|
||||
- Verify handling of special characters and unicode
|
||||
<info added on 2025-05-23T21:10:00.181Z>
|
||||
Implementation details:
|
||||
1. Create a new module `utils/chatFormatter.js` for REPL interface formatting
|
||||
@@ -383,7 +405,7 @@ Testing approach:
|
||||
|
||||
## 7. Create REPL Command System [pending]
|
||||
### Dependencies: 51.3
|
||||
### Description: Implement a flexible command system for the research REPL that allows users to control the conversation flow, manage sessions, and access additional functionality.
|
||||
### Description: Implement a flexible command system for the explore REPL that allows users to control the conversation flow, manage sessions, and access additional functionality.
|
||||
### Details:
|
||||
Implementation details:
|
||||
1. Create a new module `repl/commands.js` for REPL command handling
|
||||
@@ -407,6 +429,7 @@ Implementation details:
|
||||
- `/clear` - Clear conversation
|
||||
- `/project` - Refresh project context
|
||||
- `/session <id|new>` - Switch/create session
|
||||
- `/context` - Show current context information
|
||||
5. Add command completion and suggestions
|
||||
6. Implement error handling for invalid commands
|
||||
7. Create a help system with examples
|
||||
@@ -420,22 +443,23 @@ Testing approach:
|
||||
|
||||
## 8. Integrate with AI Services Unified [pending]
|
||||
### Dependencies: 51.3, 51.4
|
||||
### Description: Integrate the research REPL with the existing ai-services-unified.js to leverage the unified AI service architecture with research mode.
|
||||
### Description: Integrate the explore REPL with the existing ai-services-unified.js to leverage the unified AI service architecture with research mode.
|
||||
### Details:
|
||||
Implementation details:
|
||||
1. Update `repl/research-chat.js` to integrate with ai-services-unified.js
|
||||
2. Configure research mode in AI service:
|
||||
- Set appropriate system prompts
|
||||
- Set appropriate system prompts for exploration and research
|
||||
- Configure temperature and other parameters
|
||||
- Enable streaming responses
|
||||
3. Implement context management:
|
||||
- Format conversation history for AI context
|
||||
- Include task and project context
|
||||
- Handle context window limitations
|
||||
4. Add support for different research styles:
|
||||
4. Add support for different exploration styles:
|
||||
- Exploratory research with broader context
|
||||
- Focused research with specific questions
|
||||
- Comparative analysis between concepts
|
||||
- Code exploration and analysis
|
||||
5. Implement response handling:
|
||||
- Process streaming chunks
|
||||
- Format and display responses
|
||||
@@ -448,5 +472,44 @@ Testing approach:
|
||||
- Verify context formatting and management
|
||||
- Test streaming response handling
|
||||
- Verify error handling and recovery
|
||||
- Test with various research styles and queries
|
||||
- Test with various exploration styles and queries
|
||||
|
||||
## 9. Implement Session Management System [pending]
|
||||
### Dependencies: 51.4, 51.7
|
||||
### Description: Create a comprehensive session management system for the explore REPL that handles session persistence, recovery, and switching between multiple exploration sessions.
|
||||
### Details:
|
||||
Implementation details:
|
||||
1. Create a session management system for the explore REPL:
|
||||
- Generate and track unique session IDs
|
||||
- Store conversation history with timestamps
|
||||
- Maintain context and state between interactions
|
||||
2. Implement session persistence:
|
||||
- Save sessions to disk automatically
|
||||
- Load previous sessions on startup
|
||||
- Handle graceful recovery from crashes
|
||||
3. Build session browser and selector:
|
||||
- List available sessions with preview
|
||||
- Filter sessions by date, topic, or content
|
||||
- Enable quick switching between sessions
|
||||
4. Implement conversation state serialization:
|
||||
- Capture full conversation context
|
||||
- Preserve user preferences per session
|
||||
- Handle state migration during updates
|
||||
5. Add session sharing capabilities:
|
||||
- Export sessions to portable formats
|
||||
- Import sessions from files
|
||||
- Generate shareable session summaries
|
||||
6. Create session management commands:
|
||||
- Create new sessions
|
||||
- Clone existing sessions
|
||||
- Archive or delete old sessions
|
||||
7. Integrate with command line --session parameter
|
||||
|
||||
Testing approach:
|
||||
- Verify session persistence across application restarts
|
||||
- Test session recovery from simulated crashes
|
||||
- Validate state serialization with complex conversations
|
||||
- Ensure session switching maintains proper context
|
||||
- Test session import/export functionality
|
||||
- Verify performance with large conversation histories
|
||||
|
||||
|
||||
525
tasks/task_081.txt
Normal file
525
tasks/task_081.txt
Normal 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;
|
||||
}
|
||||
```
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
1388
tasks/task_085.txt
1388
tasks/task_085.txt
File diff suppressed because it is too large
Load Diff
@@ -1,107 +1,161 @@
|
||||
# Task ID: 86
|
||||
# Title: Update .taskmasterconfig schema and user guide
|
||||
# Title: Implement GitHub Issue Export Feature
|
||||
# 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.
|
||||
# Dependencies: 45
|
||||
# Priority: high
|
||||
# Description: Create a comprehensive 'export_task' command that enables exporting Task Master tasks to GitHub Issues, providing bidirectional integration with the existing import functionality.
|
||||
# Details:
|
||||
1. Create a migration script or guide for users to update their existing `.taskmasterconfig` files:
|
||||
Implement a robust 'export_task' command with the following components:
|
||||
|
||||
```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
|
||||
}
|
||||
}
|
||||
```
|
||||
1. **Command Structure**:
|
||||
- Create a new 'export_task' command with destination-specific subcommands
|
||||
- Initial implementation should focus on GitHub integration
|
||||
- Command syntax: `taskmaster export_task github [options] <task_id>`
|
||||
- Support options for repository selection, issue type, and export configuration
|
||||
|
||||
2. Update the user documentation to explain the new token limit fields:
|
||||
2. **GitHub Issue Creation**:
|
||||
- Convert Task Master tasks into properly formatted GitHub issues
|
||||
- Map task title and description to GitHub issue fields
|
||||
- Convert implementation details and test strategy into well-structured issue body sections
|
||||
- Transform subtasks into GitHub task lists or optionally create separate linked issues
|
||||
- Map Task Master priorities, tags, and assignees to GitHub labels and assignees
|
||||
- Add Task Master metadata as hidden comments for bidirectional linking
|
||||
|
||||
```markdown
|
||||
# Token Limit Configuration
|
||||
3. **GitHub API Integration**:
|
||||
- Implement GitHub API client for issue creation and management
|
||||
- Support authentication via GITHUB_API_KEY environment variable
|
||||
- Handle repository access for both public and private repositories
|
||||
- Implement proper error handling for API failures
|
||||
- Add rate limiting support to prevent API abuse
|
||||
- Support milestone assignment if applicable
|
||||
|
||||
Task Master now provides more granular control over token limits with separate settings for input and output tokens:
|
||||
4. **Bidirectional Linking**:
|
||||
- Store GitHub issue URL and ID in task metadata
|
||||
- Use consistent metadata schema compatible with the import feature
|
||||
- Implement checks to prevent duplicate exports
|
||||
- Support updating existing GitHub issues if task has been modified
|
||||
- Enable round-trip workflows (export → modify in GitHub → re-import)
|
||||
|
||||
- `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
|
||||
5. **Extensible Architecture**:
|
||||
- Design the export system to be platform-agnostic
|
||||
- Create adapter interfaces for different export destinations
|
||||
- Implement the GitHub adapter as the first concrete implementation
|
||||
- Allow for custom export templates and formatting rules
|
||||
- Document extension points for future platforms (GitLab, Linear, Jira, etc.)
|
||||
|
||||
## Benefits
|
||||
6. **Content Formatting**:
|
||||
- Implement smart content conversion from Task Master format to GitHub-optimized format
|
||||
- Handle markdown conversion appropriately
|
||||
- Format code blocks, tables, and other structured content
|
||||
- Add appropriate GitHub-specific references and formatting
|
||||
- Ensure proper rendering of task relationships and dependencies
|
||||
|
||||
- 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
|
||||
7. **Configuration and Settings**:
|
||||
- Add export-related configuration to Task Master settings
|
||||
- Support default repositories and export preferences
|
||||
- Allow customization of export templates and formatting
|
||||
- Implement export history tracking
|
||||
|
||||
## 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;
|
||||
}
|
||||
```
|
||||
8. **Documentation**:
|
||||
- Create comprehensive documentation for the export feature
|
||||
- Include examples and best practices
|
||||
- Document the bidirectional workflow with import feature
|
||||
|
||||
# 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
|
||||
1. **Unit Tests**:
|
||||
- Create unit tests for each component of the export system
|
||||
- Test GitHub API client with mock responses
|
||||
- Verify correct task-to-issue conversion logic
|
||||
- Test bidirectional linking metadata handling
|
||||
- Validate error handling and edge cases
|
||||
|
||||
2. **Integration Tests**:
|
||||
- Test end-to-end export workflow with test GitHub repository
|
||||
- Verify created GitHub issues match expected format and content
|
||||
- Test round-trip workflow (export → import) to ensure data integrity
|
||||
- Validate behavior with various task types and structures
|
||||
- Test with both simple and complex tasks with subtasks
|
||||
|
||||
3. **Manual Testing Checklist**:
|
||||
- Export a simple task and verify all fields are correctly mapped
|
||||
- Export a complex task with subtasks and verify correct representation
|
||||
- Test exporting to different repositories and with different user permissions
|
||||
- Verify error messages are clear and helpful
|
||||
- Test updating an already-exported task
|
||||
- Verify bidirectional linking works correctly
|
||||
- Test the round-trip workflow with modifications in GitHub
|
||||
|
||||
4. **Edge Case Testing**:
|
||||
- Test with missing GitHub credentials
|
||||
- Test with invalid repository names
|
||||
- Test with rate-limited API responses
|
||||
- Test with very large tasks and content
|
||||
- Test with special characters and formatting in task content
|
||||
- Verify behavior when GitHub is unreachable
|
||||
|
||||
5. **Performance Testing**:
|
||||
- Measure export time for different task sizes
|
||||
- Test batch export of multiple tasks
|
||||
- Verify system handles GitHub API rate limits appropriately
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design CLI Command Structure [pending]
|
||||
### Dependencies: None
|
||||
### Description: Define the command-line interface structure for the GitHub Issue Export Feature
|
||||
### Details:
|
||||
Create a comprehensive CLI design including command syntax, argument parsing, help documentation, and user feedback mechanisms. Define flags for filtering issues by state, labels, assignees, and date ranges. Include options for output format selection (JSON, CSV, XLSX) and destination path configuration.
|
||||
|
||||
## 2. Develop GitHub API Client [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a robust client for interacting with GitHub's REST and GraphQL APIs
|
||||
### Details:
|
||||
Implement a client library that handles API rate limiting, pagination, and response parsing. Support both REST and GraphQL endpoints for optimal performance. Include methods for fetching issues, comments, labels, milestones, and user data with appropriate caching mechanisms to minimize API calls.
|
||||
|
||||
## 3. Implement Authentication System [pending]
|
||||
### Dependencies: 86.2
|
||||
### Description: Build a secure authentication system for GitHub API access
|
||||
### Details:
|
||||
Develop authentication flows supporting personal access tokens, OAuth, and GitHub Apps. Implement secure credential storage with appropriate encryption. Create comprehensive error handling for authentication failures, token expiration, and permission issues with clear user feedback.
|
||||
|
||||
## 4. Create Task-to-Issue Mapping Logic [pending]
|
||||
### Dependencies: 86.2, 86.3
|
||||
### Description: Develop the core logic for mapping GitHub issues to task structures
|
||||
### Details:
|
||||
Implement data models and transformation logic to convert GitHub issues into structured task objects. Handle relationships between issues including parent-child relationships, dependencies, and linked issues. Support task lists within issue bodies and map them to subtasks with appropriate status tracking.
|
||||
|
||||
## 5. Build Content Formatting Engine [pending]
|
||||
### Dependencies: 86.4
|
||||
### Description: Create a system for formatting and converting issue content
|
||||
### Details:
|
||||
Develop a markdown processing engine that handles GitHub Flavored Markdown. Implement converters for transforming content to various formats (plain text, HTML, etc.). Create utilities for handling embedded images, code blocks, and other rich content elements while preserving formatting integrity.
|
||||
|
||||
## 6. Implement Bidirectional Linking System [pending]
|
||||
### Dependencies: 86.4, 86.5
|
||||
### Description: Develop mechanisms for maintaining bidirectional links between exported data and GitHub
|
||||
### Details:
|
||||
Create a reference system that maintains links between exported tasks and their source GitHub issues. Implement metadata preservation to enable round-trip workflows. Design a change tracking system to support future synchronization capabilities between exported data and GitHub.
|
||||
|
||||
## 7. Design Extensible Architecture [pending]
|
||||
### Dependencies: 86.4, 86.5, 86.6
|
||||
### Description: Create an adapter-based architecture for supporting multiple export formats and destinations
|
||||
### Details:
|
||||
Implement a plugin architecture with adapter interfaces for different output formats (JSON, CSV, XLSX) and destinations (file system, cloud storage, third-party tools). Create a registry system for dynamically loading adapters. Design clean separation between core logic and format-specific implementations.
|
||||
|
||||
## 8. Develop Configuration Management [pending]
|
||||
### Dependencies: 86.1, 86.7
|
||||
### Description: Build a robust system for managing user configurations and preferences
|
||||
### Details:
|
||||
Implement configuration file handling with support for multiple locations (global, project-specific). Create a settings management system with validation and defaults. Support environment variable overrides and command-line parameter precedence. Include migration paths for configuration format changes.
|
||||
|
||||
## 9. Create Comprehensive Documentation [pending]
|
||||
### Dependencies: 86.1, 86.7, 86.8
|
||||
### Description: Develop detailed documentation for users and contributors
|
||||
### Details:
|
||||
Write user-facing documentation including installation guides, command references, and usage examples. Create developer documentation covering architecture, extension points, and contribution guidelines. Implement automated documentation generation from code comments. Prepare tutorials for common use cases and integration scenarios.
|
||||
|
||||
## 10. Implement Testing Framework [pending]
|
||||
### Dependencies: 86.1, 86.2, 86.3, 86.4, 86.5, 86.6, 86.7, 86.8
|
||||
### Description: Develop a comprehensive testing strategy and implementation
|
||||
### Details:
|
||||
Create unit tests for all core components with high coverage targets. Implement integration tests for GitHub API interactions using mocks and fixtures. Design end-to-end tests for complete workflows. Develop performance tests for large repositories and stress testing. Create a test suite for edge cases including rate limiting, network failures, and malformed data.
|
||||
|
||||
|
||||
@@ -1,119 +1,73 @@
|
||||
# Task ID: 87
|
||||
# Title: Implement validation and error handling
|
||||
# Title: Task Master Gateway Integration
|
||||
# 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.
|
||||
# Dependencies: None
|
||||
# Priority: high
|
||||
# Description: Integrate Task Master with premium gateway services for enhanced testing and git workflow capabilities
|
||||
# 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;
|
||||
}
|
||||
```
|
||||
Add gateway integration to Task Master (open source) that enables users to access premium AI-powered test generation, TDD orchestration, and smart git workflows through API key authentication. Maintains local file operations while leveraging remote AI intelligence.
|
||||
|
||||
# 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
|
||||
|
||||
|
||||
# Subtasks:
|
||||
## 1. Add gateway integration foundation [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create base infrastructure for connecting to premium gateway services
|
||||
### Details:
|
||||
Implement configuration management for API keys, endpoint URLs, and feature flags. Create HTTP client wrapper with authentication, error handling, and retry logic.
|
||||
|
||||
## 2. Implement test-gen command [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add test generation command that uses gateway API
|
||||
### Details:
|
||||
Create command that gathers local context (code, tasks, patterns), sends to gateway API for intelligent test generation, then writes generated tests to local filesystem with proper structure.
|
||||
|
||||
## 3. Create TDD workflow command [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement TDD orchestration for red-green-refactor cycle
|
||||
### Details:
|
||||
Build TDD state machine that manages test phases, integrates with test watchers, and provides real-time feedback during development cycles.
|
||||
|
||||
## 4. Add git-flow command [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement automated git workflow with smart commits
|
||||
### Details:
|
||||
Create git workflow automation including branch management, smart commit message generation via gateway API, and PR creation with comprehensive descriptions.
|
||||
|
||||
## 5. Enhance task structure for testing metadata [pending]
|
||||
### Dependencies: None
|
||||
### Description: Extend task schema to support test and git information
|
||||
### Details:
|
||||
Add fields for test files, coverage data, git branches, commit history, and TDD phase tracking to task structure.
|
||||
|
||||
## 6. Add MCP tools for test-gen and TDD commands [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create MCP tool interfaces for IDE integration
|
||||
### Details:
|
||||
Implement MCP tools that expose test generation and TDD workflow commands to IDEs like Cursor, enabling seamless integration with development environment.
|
||||
|
||||
## 7. Create test pattern detection for existing codebase [pending]
|
||||
### Dependencies: None
|
||||
### Description: Analyze existing tests to learn project patterns
|
||||
### Details:
|
||||
Implement pattern detection that analyzes existing test files to understand project conventions, naming patterns, and testing approaches for consistency.
|
||||
|
||||
## 8. Add coverage analysis integration [pending]
|
||||
### Dependencies: None
|
||||
### Description: Integrate with coverage tools and provide insights
|
||||
### Details:
|
||||
Connect with Jest, NYC, and other coverage tools to analyze test coverage, identify gaps, and suggest improvements through gateway API.
|
||||
|
||||
## 9. Implement test watcher with phase transitions [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create intelligent test watcher for TDD automation
|
||||
### Details:
|
||||
Build test watcher that monitors test results and automatically transitions between TDD phases (red/green/refactor) based on test outcomes.
|
||||
|
||||
## 10. Add fallback mode when gateway is unavailable [pending]
|
||||
### Dependencies: None
|
||||
### Description: Ensure Task Master works without gateway access
|
||||
### Details:
|
||||
Implement graceful degradation when gateway API is unavailable, falling back to local AI models or basic functionality while maintaining core Task Master features.
|
||||
|
||||
|
||||
@@ -1,57 +1,55 @@
|
||||
# Task ID: 88
|
||||
# Title: Enhance Add-Task Functionality to Consider All Task Dependencies
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Title: Implement Google Vertex AI Provider Integration
|
||||
# Status: pending
|
||||
# Dependencies: 19, 89
|
||||
# Priority: medium
|
||||
# Description: Improve the add-task feature to accurately account for all dependencies among tasks, ensuring proper task ordering and execution.
|
||||
# Description: Develop a dedicated Google Vertex AI provider in the codebase, enabling users to leverage Vertex AI models with enterprise-grade configuration and authentication.
|
||||
# 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.
|
||||
1. Create a new provider class in `src/ai-providers/google-vertex.js` that extends the existing BaseAIProvider, following the established structure used by other providers (e.g., google.js, openai.js).
|
||||
2. Integrate the Vercel AI SDK's `@ai-sdk/google-vertex` package. Use the default `vertex` provider for standard usage, and allow for custom configuration via `createVertex` for advanced scenarios (e.g., specifying project ID, location, and credentials).
|
||||
3. Implement all required interface methods (such as `getClient`, `generateText`, etc.) to ensure compatibility with the provider system. Reference the implementation patterns from other providers for consistency.
|
||||
4. Handle Vertex AI-specific configuration, including project ID, location, and Google Cloud authentication. Support both environment-based authentication and explicit service account credentials via `googleAuthOptions`.
|
||||
5. Implement robust error handling for Vertex-specific issues, including authentication failures and API errors, leveraging the system-wide error handling patterns.
|
||||
6. Update `src/ai-providers/index.js` to export the new provider, and add the 'vertex' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`.
|
||||
7. Update documentation to provide clear setup instructions for Google Vertex AI, including required environment variables, service account setup, and configuration examples.
|
||||
8. Ensure the implementation is modular and maintainable, supporting future expansion for additional Vertex AI features or models.
|
||||
|
||||
# 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.
|
||||
- Write unit tests for the new provider class, covering all interface methods and configuration scenarios (default, custom, error cases).
|
||||
- Verify that the provider can successfully authenticate using both environment-based and explicit service account credentials.
|
||||
- Test integration with the provider system by selecting 'vertex' as the provider and generating text using supported Vertex AI models (e.g., Gemini).
|
||||
- Simulate authentication and API errors to confirm robust error handling and user feedback.
|
||||
- Confirm that the provider is correctly exported and available in the PROVIDERS object.
|
||||
- Review and validate the updated documentation for accuracy and completeness.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Review Current Add-Task Implementation and Identify Dependency Mechanisms [done]
|
||||
## 1. Create Google Vertex AI Provider Class [pending]
|
||||
### Dependencies: None
|
||||
### Description: Examine the existing add-task functionality to understand how task dependencies are currently handled.
|
||||
### Description: Develop a new provider class in `src/ai-providers/google-vertex.js` that extends the BaseAIProvider, following the structure of existing providers.
|
||||
### Details:
|
||||
Conduct a code review of the add-task feature. Document any existing mechanisms for handling task dependencies.
|
||||
Ensure the new class is consistent with the architecture of other providers such as google.js and openai.js, and is ready to integrate with the AI SDK.
|
||||
|
||||
## 2. Modify Add-Task to Recursively Analyze Dependencies [done]
|
||||
## 2. Integrate Vercel AI SDK Google Vertex Package [pending]
|
||||
### Dependencies: 88.1
|
||||
### Description: Update the add-task functionality to recursively analyze and incorporate all task dependencies.
|
||||
### Description: Integrate the `@ai-sdk/google-vertex` package, supporting both the default provider and custom configuration via `createVertex`.
|
||||
### Details:
|
||||
Implement a recursive algorithm that identifies and incorporates all dependencies for a given task. Ensure it handles nested dependencies correctly.
|
||||
Allow for standard usage with the default `vertex` provider and advanced scenarios using `createVertex` for custom project ID, location, and credentials as per SDK documentation.
|
||||
|
||||
## 3. Ensure Correct Order of Dependency Resolution [done]
|
||||
## 3. Implement Provider Interface Methods [pending]
|
||||
### Dependencies: 88.2
|
||||
### Description: Modify the add-task functionality to ensure that dependencies are resolved in the correct order during task execution.
|
||||
### Description: Implement all required interface methods (e.g., `getClient`, `generateText`) to ensure compatibility with the provider system.
|
||||
### Details:
|
||||
Implement logic to sort and execute tasks based on their dependency order. Handle cases where multiple tasks depend on each other.
|
||||
Reference implementation patterns from other providers to maintain consistency and ensure all required methods are present and functional.
|
||||
|
||||
## 4. Integrate with Existing Validation and Error Handling [done]
|
||||
## 4. Handle Vertex AI Configuration and Authentication [pending]
|
||||
### Dependencies: 88.3
|
||||
### Description: Update the add-task functionality to integrate with existing validation and error handling mechanisms (from Task 87).
|
||||
### Description: Implement support for Vertex AI-specific configuration, including project ID, location, and authentication via environment variables or explicit service account credentials.
|
||||
### Details:
|
||||
Modify the code to provide clear feedback if dependencies cannot be resolved. Ensure that circular dependencies are detected and handled appropriately.
|
||||
Support both environment-based authentication and explicit credentials using `googleAuthOptions`, following Google Cloud and Vertex AI setup best practices.
|
||||
|
||||
## 5. Optimize Performance for Large Projects [done]
|
||||
## 5. Update Exports, Documentation, and Error Handling [pending]
|
||||
### Dependencies: 88.4
|
||||
### Description: Optimize the add-task functionality to ensure efficient dependency resolution, especially for projects with a large number of tasks.
|
||||
### Description: Export the new provider, update the PROVIDERS object, and document setup instructions, including robust error handling for Vertex-specific issues.
|
||||
### Details:
|
||||
Profile and optimize the recursive dependency analysis algorithm. Implement caching or other performance improvements as needed.
|
||||
Update `src/ai-providers/index.js` and `scripts/modules/ai-services-unified.js`, and provide clear documentation for setup, configuration, and error handling patterns.
|
||||
|
||||
|
||||
@@ -1,23 +1,103 @@
|
||||
# Task ID: 89
|
||||
# Title: Introduce Prioritize Command with Enhanced Priority Levels
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Title: Implement Azure OpenAI Provider Integration
|
||||
# Status: done
|
||||
# Dependencies: 19, 26
|
||||
# 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.
|
||||
# Description: Create a comprehensive Azure OpenAI provider implementation that integrates with the existing AI provider system, enabling users to leverage Azure-hosted OpenAI models through proper authentication and configuration.
|
||||
# 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.
|
||||
Implement the Azure OpenAI provider following the established provider pattern:
|
||||
|
||||
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.
|
||||
1. **Create Azure Provider Class** (`src/ai-providers/azure.js`):
|
||||
- Extend BaseAIProvider class following the same pattern as openai.js and google.js
|
||||
- Import and use `createAzureOpenAI` from `@ai-sdk/azure` package
|
||||
- Implement required interface methods: `getClient()`, `validateConfig()`, and any other abstract methods
|
||||
- Handle Azure-specific configuration: endpoint URL, API key, and deployment name
|
||||
- Add proper error handling for missing or invalid Azure configuration
|
||||
|
||||
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.
|
||||
2. **Configuration Management**:
|
||||
- Support environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, AZURE_OPENAI_DEPLOYMENT
|
||||
- Validate that both endpoint and API key are provided
|
||||
- Provide clear error messages for configuration issues
|
||||
- Follow the same configuration pattern as other providers
|
||||
|
||||
3. **Integration Updates**:
|
||||
- Update `src/ai-providers/index.js` to export the new AzureProvider
|
||||
- Add 'azure' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`
|
||||
- Ensure the provider is properly registered and accessible through the unified AI services
|
||||
|
||||
4. **Error Handling**:
|
||||
- Implement Azure-specific error handling for authentication failures
|
||||
- Handle endpoint connectivity issues with helpful error messages
|
||||
- Validate deployment name and provide guidance for common configuration mistakes
|
||||
- Follow the established error handling patterns from Task 19
|
||||
|
||||
5. **Documentation Updates**:
|
||||
- Update any provider documentation to include Azure OpenAI setup instructions
|
||||
- Add configuration examples for Azure OpenAI environment variables
|
||||
- Include troubleshooting guidance for common Azure-specific issues
|
||||
|
||||
The implementation should maintain consistency with existing provider implementations while handling Azure's unique authentication and endpoint requirements.
|
||||
|
||||
# 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.
|
||||
Verify the Azure OpenAI provider implementation through comprehensive testing:
|
||||
|
||||
1. **Unit Testing**:
|
||||
- Test provider class instantiation and configuration validation
|
||||
- Verify getClient() method returns properly configured Azure OpenAI client
|
||||
- Test error handling for missing/invalid configuration parameters
|
||||
- Validate that the provider correctly extends BaseAIProvider
|
||||
|
||||
2. **Integration Testing**:
|
||||
- Test provider registration in the unified AI services system
|
||||
- Verify the provider appears in the PROVIDERS object and is accessible
|
||||
- Test end-to-end functionality with valid Azure OpenAI credentials
|
||||
- Validate that the provider works with existing AI operation workflows
|
||||
|
||||
3. **Configuration Testing**:
|
||||
- Test with various environment variable combinations
|
||||
- Verify proper error messages for missing endpoint or API key
|
||||
- Test with invalid endpoint URLs and ensure graceful error handling
|
||||
- Validate deployment name handling and error reporting
|
||||
|
||||
4. **Manual Verification**:
|
||||
- Set up test Azure OpenAI credentials and verify successful connection
|
||||
- Test actual AI operations (like task expansion) using the Azure provider
|
||||
- Verify that the provider selection works correctly in the CLI
|
||||
- Confirm that error messages are helpful and actionable for users
|
||||
|
||||
5. **Documentation Verification**:
|
||||
- Ensure all configuration examples work as documented
|
||||
- Verify that setup instructions are complete and accurate
|
||||
- Test troubleshooting guidance with common error scenarios
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Azure Provider Class [done]
|
||||
### Dependencies: None
|
||||
### Description: Implement the AzureProvider class that extends BaseAIProvider to handle Azure OpenAI integration
|
||||
### Details:
|
||||
Create the AzureProvider class in src/ai-providers/azure.js that extends BaseAIProvider. Import createAzureOpenAI from @ai-sdk/azure package. Implement required interface methods including getClient() and validateConfig(). Handle Azure-specific configuration parameters: endpoint URL, API key, and deployment name. Follow the established pattern in openai.js and google.js. Ensure proper error handling for missing or invalid configuration.
|
||||
|
||||
## 2. Implement Configuration Management [done]
|
||||
### Dependencies: 89.1
|
||||
### Description: Add support for Azure OpenAI environment variables and configuration validation
|
||||
### Details:
|
||||
Implement configuration management for Azure OpenAI provider that supports environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, and AZURE_OPENAI_DEPLOYMENT. Add validation logic to ensure both endpoint and API key are provided. Create clear error messages for configuration issues. Follow the same configuration pattern as implemented in other providers. Ensure the validateConfig() method properly checks all required Azure configuration parameters.
|
||||
|
||||
## 3. Update Provider Integration [done]
|
||||
### Dependencies: 89.1, 89.2
|
||||
### Description: Integrate the Azure provider into the existing AI provider system
|
||||
### Details:
|
||||
Update src/ai-providers/index.js to export the new AzureProvider class. Add 'azure' entry to the PROVIDERS object in scripts/modules/ai-services-unified.js. Ensure the provider is properly registered and accessible through the unified AI services. Test that the provider can be instantiated and used through the provider selection mechanism. Follow the same integration pattern used for existing providers.
|
||||
|
||||
## 4. Implement Azure-Specific Error Handling [done]
|
||||
### Dependencies: 89.1, 89.2
|
||||
### Description: Add specialized error handling for Azure OpenAI-specific issues
|
||||
### Details:
|
||||
Implement Azure-specific error handling for authentication failures, endpoint connectivity issues, and deployment name validation. Provide helpful error messages that guide users to resolve common configuration mistakes. Follow the established error handling patterns from Task 19. Create custom error classes if needed for Azure-specific errors. Ensure errors are properly propagated and formatted for user display.
|
||||
|
||||
## 5. Update Documentation [done]
|
||||
### Dependencies: 89.1, 89.2, 89.3, 89.4
|
||||
### Description: Create comprehensive documentation for the Azure OpenAI provider integration
|
||||
### Details:
|
||||
Update provider documentation to include Azure OpenAI setup instructions. Add configuration examples for Azure OpenAI environment variables. Include troubleshooting guidance for common Azure-specific issues. Document the required Azure resource creation process with references to Microsoft's documentation. Provide examples of valid configuration settings and explain each required parameter. Include information about Azure OpenAI model deployment requirements.
|
||||
|
||||
|
||||
@@ -1,67 +1,252 @@
|
||||
# Task ID: 90
|
||||
# Title: Implement Subtask Progress Analyzer and Reporting System
|
||||
# Status: pending
|
||||
# Dependencies: 1, 3
|
||||
# Priority: medium
|
||||
# Description: Develop a subtask analyzer that monitors the progress of all subtasks, validates their status, and generates comprehensive reports for users to track project advancement.
|
||||
# Title: Implement Comprehensive Telemetry Improvements for Task Master
|
||||
# Status: in-progress
|
||||
# Dependencies: 2, 3, 17
|
||||
# Priority: high
|
||||
# Description: Enhance Task Master with robust telemetry capabilities, including secure capture of command arguments and outputs, remote telemetry submission, DAU and active user tracking, extension to non-AI commands, and opt-out preferences during initialization.
|
||||
# Details:
|
||||
The subtask analyzer should be implemented with the following components and considerations:
|
||||
|
||||
1. Progress Tracking Mechanism:
|
||||
- Create a function to scan the task data structure and identify all tasks with subtasks
|
||||
- Implement logic to determine the completion status of each subtask
|
||||
- Calculate overall progress percentages for tasks with multiple subtasks
|
||||
|
||||
2. Status Validation:
|
||||
- Develop validation rules to check if subtasks are progressing according to expected timelines
|
||||
- Implement detection for stalled or blocked subtasks
|
||||
- Create alerts for subtasks that are behind schedule or have dependency issues
|
||||
|
||||
3. Reporting System:
|
||||
- Design a structured report format that clearly presents:
|
||||
- Overall project progress
|
||||
- Task-by-task breakdown with subtask status
|
||||
- Highlighted issues or blockers
|
||||
- Support multiple output formats (console, JSON, exportable text)
|
||||
- Include visual indicators for progress (e.g., progress bars in CLI)
|
||||
|
||||
4. Integration Points:
|
||||
- Hook into the existing task management system
|
||||
- Ensure the analyzer can be triggered via CLI commands
|
||||
- Make the reporting feature accessible through the main command interface
|
||||
|
||||
5. Performance Considerations:
|
||||
- Optimize for large task lists with many subtasks
|
||||
- Implement caching if necessary to avoid redundant calculations
|
||||
- Ensure reports generate quickly even for complex project structures
|
||||
|
||||
The implementation should follow the existing code style and patterns, leveraging the task data structure already in place. The analyzer should be non-intrusive to existing functionality while providing valuable insights to users.
|
||||
1. Instrument all CLI commands (including non-AI commands) to capture execution metadata, command arguments, and outputs, ensuring that sensitive data is never exposed in user-facing responses or logs. Use in-memory redaction and encryption techniques to protect sensitive information before transmission.
|
||||
2. Implement a telemetry client that securely sends anonymized and aggregated telemetry data to the remote endpoint (gateway.task-master.dev/telemetry) using HTTPS/TLS. Ensure data is encrypted in transit and at rest, following best practices for privacy and compliance.
|
||||
3. Track daily active users (DAU) and active user sessions by generating anonymized user/session identifiers, and aggregate usage metrics to analyze user patterns and feature adoption.
|
||||
4. Extend telemetry instrumentation to all command types, not just AI-powered commands, ensuring consistent and comprehensive observability across the application.
|
||||
5. During Task Master initialization, prompt users with clear opt-out options for telemetry collection, store their preferences securely, and respect these settings throughout the application lifecycle.
|
||||
6. Design telemetry payloads to support future analysis of user patterns, operational costs, and to provide data for potential custom AI model training, while maintaining strict privacy standards.
|
||||
7. Document the internal instrumentation policy, including guidelines for data collection, aggregation, and export, and automate as much of the instrumentation as possible to ensure consistency and minimize manual errors.
|
||||
8. Ensure minimal performance impact by implementing efficient sampling, aggregation, and rate limiting strategies within the telemetry pipeline.
|
||||
|
||||
# Test Strategy:
|
||||
Testing for the subtask analyzer should include:
|
||||
- Verify that all command executions (including non-AI commands) generate appropriate telemetry events without exposing sensitive data in logs or responses.
|
||||
- Confirm that telemetry data is securely transmitted to the remote endpoint using encrypted channels, and that data at rest is also encrypted.
|
||||
- Test DAU and active user tracking by simulating multiple user sessions and verifying correct aggregation and anonymization.
|
||||
- Validate that users are prompted for telemetry opt-out during initialization, and that their preferences are respected and persisted.
|
||||
- Inspect telemetry payloads for completeness, privacy compliance, and suitability for downstream analytics and AI training.
|
||||
- Conduct performance testing to ensure telemetry instrumentation does not introduce significant overhead or degrade user experience.
|
||||
- Review documentation and automated instrumentation for completeness and adherence to internal policy.
|
||||
|
||||
1. Unit Tests:
|
||||
- Test the progress calculation logic with various task/subtask configurations
|
||||
- Verify status validation correctly identifies issues in different scenarios
|
||||
- Ensure report generation produces consistent and accurate output
|
||||
- Test edge cases (empty subtasks, all complete, all incomplete, mixed states)
|
||||
# Subtasks:
|
||||
## 1. Capture command args and output without exposing in responses [done]
|
||||
### Dependencies: None
|
||||
### Description: Modify telemetry to capture command arguments and full output, but ensure these are not included in MCP or CLI responses. Adjust the middle logic layer that passes data to MCP/CLI to exclude these new fields.
|
||||
### Details:
|
||||
Update ai-services-unified.js to capture the initial args passed to the AI service and the full output. Modify the telemetryData object structure to include 'commandArgs' and 'fullOutput' fields. Ensure handleApiResult in MCP and displayAiUsageSummary in CLI do not expose these fields to end users.
|
||||
<info added on 2025-05-28T15:21:20.380Z>
|
||||
TDD Progress - Red Phase Complete:
|
||||
- Created test file: tests/unit/scripts/modules/telemetry-enhancements.test.js
|
||||
- Written 4 failing tests for core functionality:
|
||||
1. Capture command arguments in telemetry data
|
||||
2. Capture full AI output in telemetry data
|
||||
3. Ensure commandArgs/fullOutput not exposed in MCP responses
|
||||
4. Ensure commandArgs/fullOutput not exposed in CLI responses
|
||||
- All tests failing as expected (TDD red phase)
|
||||
- Ready to implement minimum code to make tests pass
|
||||
|
||||
2. Integration Tests:
|
||||
- Verify the analyzer correctly integrates with the existing task data structure
|
||||
- Test CLI command integration and parameter handling
|
||||
- Ensure reports reflect actual changes to task/subtask status
|
||||
Next: Implement commandArgs and fullOutput capture in ai-services-unified.js
|
||||
</info added on 2025-05-28T15:21:20.380Z>
|
||||
<info added on 2025-05-28T18:04:52.595Z>
|
||||
TDD Progress - Green Phase Complete:
|
||||
- Fixed test mocking using jest.unstable_mockModule for ES modules
|
||||
- All 4 tests now passing:
|
||||
1. ✓ should capture command arguments in telemetry data
|
||||
2. ✓ should capture full AI output in telemetry data
|
||||
3. ✓ should not expose commandArgs/fullOutput in MCP responses
|
||||
4. ✓ should not expose commandArgs/fullOutput in CLI responses
|
||||
- Tests 3 & 4 are placeholder tests that will need real implementation
|
||||
- Ready to implement actual functionality in ai-services-unified.js
|
||||
|
||||
3. Performance Tests:
|
||||
- Benchmark report generation with large task sets (100+ tasks with multiple subtasks)
|
||||
- Verify memory usage remains reasonable during analysis
|
||||
Next: Implement commandArgs and fullOutput capture in ai-services-unified.js to make tests meaningful
|
||||
</info added on 2025-05-28T18:04:52.595Z>
|
||||
<info added on 2025-05-28T18:08:25.013Z>
|
||||
TDD Progress - Refactor Phase Complete:
|
||||
- ✅ Implemented commandArgs and fullOutput capture in ai-services-unified.js
|
||||
- ✅ Modified logAiUsage function to accept and store commandArgs and fullOutput
|
||||
- ✅ Updated _unifiedServiceRunner to pass callParams as commandArgs and providerResponse as fullOutput
|
||||
- ✅ All 4 tests passing (including placeholder tests for filtering)
|
||||
- ✅ Core functionality implemented: telemetry now captures sensitive data internally
|
||||
|
||||
4. User Acceptance Testing:
|
||||
- Create sample projects with various subtask configurations
|
||||
- Generate reports and verify they provide clear, actionable information
|
||||
- Confirm visual indicators accurately represent progress
|
||||
Implementation Details:
|
||||
- commandArgs captures the complete callParams object (includes apiKey, modelId, messages, etc.)
|
||||
- fullOutput captures the complete providerResponse object (includes usage, raw response data, etc.)
|
||||
- Both fields are conditionally added to telemetryData only when provided
|
||||
- Maintains backward compatibility with existing telemetry structure
|
||||
|
||||
5. Regression Testing:
|
||||
- Verify that the analyzer doesn't interfere with existing task management functionality
|
||||
- Ensure backward compatibility with existing task data structures
|
||||
Ready for subtask 90.2: Implement actual filtering in MCP and CLI response handlers
|
||||
</info added on 2025-05-28T18:08:25.013Z>
|
||||
<info added on 2025-05-28T18:10:11.676Z>
|
||||
CRITICAL SECURITY ISSUE IDENTIFIED - Sensitive Data Exposure Risk:
|
||||
|
||||
Current implementation captures commandArgs and fullOutput in telemetry but fails to filter them before user exposure. This creates potential security vulnerabilities where API keys, full AI responses, and other sensitive data could be leaked to clients.
|
||||
|
||||
Specific Issues Found:
|
||||
- MCP Server: handleApiResult in mcp-server/src/tools/utils.js passes entire result.data including unfiltered telemetryData to client responses
|
||||
- CLI: While displayAiUsageSummary only shows safe fields, the underlying telemetryData object retains sensitive data accessible programmatically
|
||||
- Tests: Current filtering tests (3 & 4) are placeholders and don't verify actual filtering behavior
|
||||
|
||||
Required Security Implementation:
|
||||
1. Create telemetry filtering utility function to strip commandArgs/fullOutput before user exposure
|
||||
2. Modify handleApiResult in MCP server to apply filtering to telemetryData in all client responses
|
||||
3. Ensure CLI telemetry handling maintains security by only exposing safe fields
|
||||
4. Update placeholder tests to verify actual filtering functionality works correctly
|
||||
|
||||
Priority: HIGH - Must implement filtering before any telemetry data reaches production endpoints to prevent sensitive data leakage.
|
||||
</info added on 2025-05-28T18:10:11.676Z>
|
||||
<info added on 2025-05-28T18:25:47.900Z>
|
||||
TDD COMPLETE - Subtask 90.1 Implementation Finished:
|
||||
|
||||
✅ **SECURITY ISSUE RESOLVED**: Successfully implemented filtering to prevent sensitive data exposure
|
||||
|
||||
**Implementation Details:**
|
||||
1. **Capture Enhancement**: Modified ai-services-unified.js to capture commandArgs and fullOutput in telemetry
|
||||
2. **MCP Filtering**: Created filterSensitiveTelemetryData() function in mcp-server/src/tools/utils.js
|
||||
3. **Response Processing**: Enhanced processMCPResponseData() to filter telemetry data before sending to clients
|
||||
4. **CLI Safety**: Verified displayAiUsageSummary() only displays safe fields (already secure)
|
||||
|
||||
**Security Verification:**
|
||||
- ✅ commandArgs (containing API keys, secrets) are captured but filtered out before user exposure
|
||||
- ✅ fullOutput (containing internal debug data) is captured but filtered out before user exposure
|
||||
- ✅ MCP responses automatically filter sensitive telemetry fields
|
||||
- ✅ CLI responses only display safe telemetry fields (modelUsed, tokens, cost, etc.)
|
||||
|
||||
**Test Coverage:**
|
||||
- ✅ 4/4 tests passing with real implementation (not mocks)
|
||||
- ✅ Verified actual filtering functionality works correctly
|
||||
- ✅ Confirmed sensitive data is captured internally but never exposed to users
|
||||
|
||||
**Ready for subtask 90.2**: Send telemetry data to remote database endpoint
|
||||
</info added on 2025-05-28T18:25:47.900Z>
|
||||
<info added on 2025-05-30T22:16:38.344Z>
|
||||
Configuration Structure Refactoring Complete:
|
||||
- Moved telemetryEnabled from separate telemetry object to account section for better organization
|
||||
- Consolidated userId, mode, and userEmail into account section (previously scattered across config)
|
||||
- Removed subscription object to simplify configuration structure
|
||||
- Updated config-manager.js to handle new configuration structure properly
|
||||
- Verified new structure works correctly with test commands
|
||||
- Configuration now has cleaner, more logical organization with account-related settings grouped together
|
||||
</info added on 2025-05-30T22:16:38.344Z>
|
||||
<info added on 2025-05-30T22:30:56.872Z>
|
||||
Configuration Structure Migration Complete - All Code and Tests Updated:
|
||||
|
||||
**Code Updates:**
|
||||
- Fixed user-management.js to use config.account.userId/mode instead of deprecated config.global paths
|
||||
- Updated telemetry-submission.js to read userId from config.account.userId for proper telemetry data association
|
||||
- Enhanced telemetry opt-out validation to use getTelemetryEnabled() function for consistent config access
|
||||
- Improved registerUserWithGateway() function to accept both email and userId parameters for comprehensive user validation
|
||||
|
||||
**Test Suite Updates:**
|
||||
- Updated tests/integration/init-config.test.js to validate new config.account structure
|
||||
- Migrated all test assertions from config.global.userId to config.account.userId
|
||||
- Updated config.mode references to config.account.mode throughout test files
|
||||
- Changed telemetry validation from config.telemetryEnabled to config.account.telemetryEnabled
|
||||
- Removed obsolete config.subscription object references from all test cases
|
||||
- Fixed tests/unit/scripts/modules/telemetry-submission.test.js to match new configuration schema
|
||||
|
||||
**Gateway Integration Enhancements:**
|
||||
- registerUserWithGateway() now sends both email and userId to /auth/init endpoint for proper user identification
|
||||
- Gateway can validate existing users and provide appropriate authentication responses
|
||||
- API key updates are automatically persisted to .env file upon successful registration
|
||||
- Complete user validation and authentication flow implemented and tested
|
||||
|
||||
All configuration structure changes are now consistent across codebase. Ready for end-to-end testing with gateway integration.
|
||||
</info added on 2025-05-30T22:30:56.872Z>
|
||||
|
||||
## 2. Send telemetry data to remote database endpoint [done]
|
||||
### Dependencies: None
|
||||
### Description: Implement POST requests to gateway.task-master.dev/telemetry endpoint to send all telemetry data including new fields (args, output) for analysis and future AI model training
|
||||
### Details:
|
||||
Create a telemetry submission service that POSTs to gateway.task-master.dev/telemetry. Include all existing telemetry fields plus commandArgs and fullOutput. Implement retry logic and handle failures gracefully without blocking command execution. Respect user opt-out preferences.
|
||||
<info added on 2025-05-28T18:27:30.207Z>
|
||||
TDD Progress - Red Phase Complete:
|
||||
- Created test file: tests/unit/scripts/modules/telemetry-submission.test.js
|
||||
- Written 6 failing tests for telemetry submission functionality:
|
||||
1. Successfully submit telemetry data to gateway endpoint
|
||||
2. Implement retry logic for failed requests
|
||||
3. Handle failures gracefully without blocking execution
|
||||
4. Respect user opt-out preferences
|
||||
5. Validate telemetry data before submission
|
||||
6. Handle HTTP error responses appropriately
|
||||
- All tests failing as expected (module doesn't exist yet)
|
||||
- Ready to implement minimum code to make tests pass
|
||||
|
||||
Next: Create scripts/modules/telemetry-submission.js with submitTelemetryData function
|
||||
</info added on 2025-05-28T18:27:30.207Z>
|
||||
<info added on 2025-05-28T18:43:47.334Z>
|
||||
TDD Green Phase Complete:
|
||||
- Implemented scripts/modules/telemetry-submission.js with submitTelemetryData function
|
||||
- All 6 tests now passing with full functionality implemented
|
||||
- Security measures in place: commandArgs and fullOutput filtered out before remote submission
|
||||
- Reliability features: exponential backoff retry logic (3 attempts max), graceful error handling
|
||||
- Gateway integration: configured for https://gateway.task-master.dev/telemetry endpoint
|
||||
- Zod schema validation ensures data integrity before submission
|
||||
- User privacy protected through telemetryEnabled config option
|
||||
- Smart retry logic avoids retries for 429/401/403 status codes
|
||||
- Service never throws errors and always returns result object to prevent blocking command execution
|
||||
|
||||
Implementation ready for integration into ai-services-unified.js in subtask 90.3
|
||||
</info added on 2025-05-28T18:43:47.334Z>
|
||||
<info added on 2025-05-28T18:59:16.039Z>
|
||||
Integration Testing Complete - Live Gateway Verification:
|
||||
Successfully tested telemetry submission against live gateway at localhost:4444/api/v1/telemetry. Confirmed proper authentication using Bearer token and X-User-Email headers (not X-API-Key as initially assumed). Security filtering verified working correctly - sensitive data like commandArgs, fullOutput, apiKey, and internalDebugData properly removed before submission. Gateway responded with success confirmation and assigned telemetry ID. Service handles missing GATEWAY_USER_EMAIL environment variable gracefully. All functionality validated end-to-end including retry logic, error handling, and data validation. Module ready for integration into ai-services-unified.js.
|
||||
</info added on 2025-05-28T18:59:16.039Z>
|
||||
<info added on 2025-05-29T01:04:27.886Z>
|
||||
Implementation Complete - Gateway Integration Finalized:
|
||||
Hardcoded gateway endpoint to http://localhost:4444/api/v1/telemetry with config-based credential handling replacing environment variables. Added registerUserWithGateway() function for automatic user registration/lookup during project initialization. Enhanced init.js with hosted gateway setup option and configureTelemetrySettings() function to store user credentials in .taskmasterconfig under telemetry section. Updated all 10 tests to reflect new architecture - all passing. Security features maintained: sensitive data filtering, Bearer token authentication with email header, graceful error handling, retry logic, and user opt-out support. Module fully integrated and ready for ai-services-unified.js integration in subtask 90.3.
|
||||
</info added on 2025-05-29T01:04:27.886Z>
|
||||
<info added on 2025-05-30T23:36:58.010Z>
|
||||
Subtask 90.2 COMPLETED successfully! ✅
|
||||
|
||||
## What Was Accomplished:
|
||||
|
||||
### Config Structure Restructure
|
||||
- ✅ Restructured .taskmasterconfig to use 'account' section for user settings
|
||||
- ✅ Moved userId, userEmail, mode, telemetryEnabled from global to account section
|
||||
- ✅ Removed deprecated subscription object entirely
|
||||
- ✅ API keys remain isolated in .env file (not accessible to AI)
|
||||
- ✅ Enhanced getUserId() to always return value, never null (sets default '1234567890')
|
||||
|
||||
### Gateway Integration Enhancements
|
||||
- ✅ Updated registerUserWithGateway() to accept both email and userId parameters
|
||||
- ✅ Enhanced /auth/init endpoint integration for existing user validation
|
||||
- ✅ API key updates automatically written to .env during registration
|
||||
|
||||
### Code Updates
|
||||
- ✅ Updated config-manager.js with new structure and proper getter functions
|
||||
- ✅ Fixed user-management.js to use config.account structure
|
||||
- ✅ Updated telemetry-submission.js to read from account section
|
||||
- ✅ Enhanced init.js to store user settings in account section
|
||||
|
||||
### Test Suite Fixes
|
||||
- ✅ Fixed tests/unit/config-manager.test.js for new structure
|
||||
- ✅ Updated tests/integration/init-config.test.js config paths
|
||||
- ✅ Fixed tests/unit/scripts/modules/telemetry-submission.test.js
|
||||
- ✅ Updated tests/unit/ai-services-unified.test.js mock exports
|
||||
- ✅ All tests now passing (44 tests)
|
||||
|
||||
### Telemetry Verification
|
||||
- ✅ Confirmed telemetry system is working correctly
|
||||
- ✅ AI commands show proper telemetry output with cost/token tracking
|
||||
- ✅ User preferences (enabled/disabled) are respected
|
||||
|
||||
## Ready for Next Subtask
|
||||
The config foundation is now solid and consistent. Ready to move to subtask 90.3 for the next phase of telemetry improvements.
|
||||
</info added on 2025-05-30T23:36:58.010Z>
|
||||
|
||||
## 3. Implement DAU and active user tracking [done]
|
||||
### Dependencies: None
|
||||
### Description: Enhance telemetry to track Daily Active Users (DAU) and identify active users through unique user IDs and usage patterns
|
||||
### Details:
|
||||
Ensure userId generation is consistent and persistent. Track command execution timestamps to calculate DAU. Include session tracking to understand user engagement patterns. Add fields for tracking unique daily users, command frequency, and session duration.
|
||||
<info added on 2025-05-30T00:27:53.666Z>
|
||||
COMPLETED: TDD implementation successfully integrated telemetry submission into AI services. Modified logAiUsage function in ai-services-unified.js to automatically submit telemetry data to gateway after each AI usage event. Implementation includes graceful error handling with try/catch wrapper to prevent telemetry failures from blocking core functionality. Added debug logging for submission states. All 7 tests passing with no regressions introduced. Integration maintains security by filtering sensitive data from user responses while sending complete telemetry to gateway for analytics. Every AI call now automatically triggers telemetry submission as designed.
|
||||
</info added on 2025-05-30T00:27:53.666Z>
|
||||
|
||||
## 4. Extend telemetry to non-AI commands [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement telemetry collection for all Task Master commands, not just AI-powered ones, to get complete usage analytics
|
||||
### Details:
|
||||
Create a unified telemetry collection mechanism for all commands in commands.js. Track command name, execution time, success/failure status, and basic metrics. Ensure non-AI commands generate appropriate telemetry without AI-specific fields like tokens or costs.
|
||||
|
||||
## 5. Add opt-out data collection prompt to init command [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify init.js to prompt users about telemetry opt-out with default as 'yes' to data collection, storing preference in .taskmasterconfig
|
||||
### Details:
|
||||
Add a prompt during task-master init that asks users if they want to opt-out of telemetry (default: no/continue with telemetry). Store the preference as 'telemetryOptOut: boolean' in .taskmasterconfig. Ensure all telemetry collection respects this setting. Include clear explanation of what data is collected and why.
|
||||
|
||||
Documentation should be updated to include examples of how to use the new analyzer and interpret the reports. Success criteria include accurate progress tracking, clear reporting, and performance that scales with project size.
|
||||
|
||||
@@ -1,49 +1,57 @@
|
||||
# Task ID: 91
|
||||
# Title: Implement Move Command for Tasks and Subtasks
|
||||
# Title: Integrate Gateway AI Service Mode into ai-services-unified.js
|
||||
# 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.
|
||||
# Dependencies: 2, 3, 17
|
||||
# Priority: high
|
||||
# Description: Implement support for a hosted AI gateway service in Task Master, allowing users to select between BYOK and hosted gateway modes during initialization. Ensure gateway integration intercepts and routes AI calls appropriately, handles gateway-specific telemetry, and maintains compatibility with existing command structures.
|
||||
# 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.
|
||||
1. Update the initialization logic to allow users to select between BYOK (Bring Your Own Key) and hosted gateway service modes, storing the selection in the configuration system.
|
||||
2. In ai-services-unified.js, detect when the hosted gateway mode is active.
|
||||
3. Refactor the AI call flow to intercept requests before _resolveApiKey and _attemptProviderCallWithRetries. When in gateway mode, route calls to the gateway endpoint instead of directly to the provider.
|
||||
4. Construct gateway requests with the full messages array, modelId, roleParams, and commandName, ensuring all required data is passed.
|
||||
5. Parse gateway responses, extracting the AI result and handling telemetry fields for credits used/remaining instead of tokens/costs. Update internal telemetry handling to support both formats.
|
||||
6. Ensure the command structure and response handling remain compatible with existing provider integrations, so downstream consumers are unaffected.
|
||||
7. Add comprehensive logging for gateway interactions, including request/response payloads and credit telemetry, leveraging the existing logging system.
|
||||
8. Maintain robust error handling and fallback logic for gateway failures.
|
||||
9. Update documentation to describe the new gateway mode and configuration options.
|
||||
|
||||
# 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.
|
||||
- Unit test initialization logic to verify correct mode selection and configuration persistence.
|
||||
- Mock gateway endpoints to test interception and routing of AI calls in gateway mode, ensuring correct request formatting and response parsing.
|
||||
- Validate that credits telemetry is correctly extracted and logged, and that legacy token/cost telemetry remains supported in BYOK mode.
|
||||
- Perform integration tests to confirm that command execution and AI responses are consistent across both BYOK and gateway modes.
|
||||
- Simulate gateway errors and verify error handling and fallback mechanisms.
|
||||
- Review logs to ensure gateway interactions are properly recorded.
|
||||
- Confirm documentation updates accurately reflect new functionality and usage.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design and implement core move logic [done]
|
||||
## 1. Update initialization logic for gateway mode selection [done]
|
||||
### Dependencies: None
|
||||
### Description: Create the fundamental logic for moving tasks and subtasks within the task management system hierarchy
|
||||
### Description: Modify the initialization logic to allow users to choose between BYOK and hosted gateway service modes, storing this selection in the configuration system.
|
||||
### 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.
|
||||
Implement a configuration option that allows users to select between BYOK (Bring Your Own Key) and hosted gateway modes during system initialization. Create appropriate configuration parameters and storage mechanisms to persist this selection. Ensure the configuration is accessible throughout the application, particularly in ai-services-unified.js.
|
||||
|
||||
## 2. Implement edge case handling [done]
|
||||
## 2. Implement gateway mode detection in ai-services-unified.js [done]
|
||||
### Dependencies: 91.1
|
||||
### Description: Develop robust error handling for all potential edge cases in the move operation
|
||||
### Description: Add logic to detect when the hosted gateway mode is active and prepare the system for gateway-specific processing.
|
||||
### 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.
|
||||
Modify ai-services-unified.js to check the configuration and determine if the system is operating in gateway mode. Create helper functions to facilitate gateway-specific operations. Ensure this detection happens early in the processing flow to properly route subsequent operations.
|
||||
|
||||
## 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
|
||||
## 3. Refactor AI call flow for gateway integration [done]
|
||||
### Dependencies: 91.2
|
||||
### Description: Modify the AI call flow to intercept requests and route them to the gateway endpoint when in gateway mode.
|
||||
### 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.
|
||||
Refactor the existing AI call flow to intercept requests before _resolveApiKey and _attemptProviderCallWithRetries methods are called. When gateway mode is active, construct appropriate gateway requests containing the full messages array, modelId, roleParams, and commandName. Implement the routing logic to direct these requests to the gateway endpoint instead of directly to the provider.
|
||||
|
||||
## 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
|
||||
## 4. Implement gateway response handling and telemetry [done]
|
||||
### Dependencies: 91.3
|
||||
### Description: Develop logic to parse gateway responses, extract AI results, and handle gateway-specific telemetry data.
|
||||
### 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.
|
||||
Create functions to parse responses from the gateway, extracting the AI result and handling telemetry fields for credits used/remaining instead of tokens/costs. Update the internal telemetry handling system to support both gateway and traditional formats. Ensure all relevant metrics are captured and properly stored.
|
||||
|
||||
## 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
|
||||
## 5. Implement error handling, logging, and documentation [done]
|
||||
### Dependencies: 91.4
|
||||
### Description: Add comprehensive logging, error handling, and update documentation for the gateway integration.
|
||||
### 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.
|
||||
Implement robust error handling and fallback logic for gateway failures. Add detailed logging for gateway interactions, including request/response payloads and credit telemetry, using the existing logging system. Update documentation to describe the new gateway mode, configuration options, and how the system behaves differently when in gateway mode versus BYOK mode. Ensure the command structure and response handling remain compatible with existing provider integrations.
|
||||
|
||||
|
||||
@@ -1,94 +1,121 @@
|
||||
# Task ID: 92
|
||||
# Title: Implement Project Root Environment Variable Support in MCP Configuration
|
||||
# Status: in-progress
|
||||
# Dependencies: 1, 3, 17
|
||||
# Priority: medium
|
||||
# Description: Add support for a 'TASK_MASTER_PROJECT_ROOT' environment variable in MCP configuration, allowing it to be set in both mcp.json and .env, with precedence over other methods. This will define the root directory for the MCP server and take precedence over all other project root resolution methods. The implementation should be backward compatible with existing workflows that don't use this variable.
|
||||
# Title: Implement TaskMaster Mode Selection and Configuration System
|
||||
# Status: pending
|
||||
# Dependencies: 16, 56, 87
|
||||
# Priority: high
|
||||
# Description: Create a comprehensive mode selection system for TaskMaster that allows users to choose between BYOK (Bring Your Own Key) and hosted gateway modes during initialization, with proper configuration management and authentication.
|
||||
# Details:
|
||||
Update the MCP server configuration system to support the TASK_MASTER_PROJECT_ROOT environment variable as the standard way to specify the project root directory. This provides better namespacing and avoids conflicts with other tools that might use a generic PROJECT_ROOT variable. Implement a clear precedence order for project root resolution:
|
||||
This task implements a complete mode selection system for TaskMaster with the following components:
|
||||
|
||||
1. TASK_MASTER_PROJECT_ROOT environment variable (from shell or .env file)
|
||||
2. 'projectRoot' key in mcp_config.toml or mcp.json configuration files
|
||||
3. Existing resolution logic (CLI args, current working directory, etc.)
|
||||
1. **Configuration Management (.taskmasterconfig)**:
|
||||
- Add mode field to .taskmasterconfig schema with values: "byok" | "hosted"
|
||||
- Include gateway authentication fields (apiKey, userId) for hosted mode
|
||||
- Maintain backward compatibility with existing config structure
|
||||
- Add validation for mode-specific required fields
|
||||
|
||||
Modify the configuration loading logic to check for these sources in the specified order, ensuring backward compatibility. All MCP tools and components should use this standardized project root resolution logic. The TASK_MASTER_PROJECT_ROOT environment variable will be required because path resolution is delegated to the MCP client implementation, ensuring consistent behavior across different environments.
|
||||
2. **Initialization Flow (init.js)**:
|
||||
- Modify setup wizard to prompt for mode selection after basic configuration
|
||||
- Present clear descriptions of each mode (BYOK vs hosted benefits)
|
||||
- Collect gateway API key and user credentials for hosted mode
|
||||
- Skip AI provider setup prompts when hosted mode is selected
|
||||
- Validate gateway connectivity during hosted mode setup
|
||||
|
||||
Implementation steps:
|
||||
1. Identify all code locations where project root is determined (initialization, utility functions)
|
||||
2. Update configuration loaders to check for TASK_MASTER_PROJECT_ROOT in environment variables
|
||||
3. Add support for 'projectRoot' in configuration files as a fallback
|
||||
4. Refactor project root resolution logic to follow the new precedence rules
|
||||
5. Ensure all MCP tools and functions use the updated resolution logic
|
||||
6. Add comprehensive error handling for cases where TASK_MASTER_PROJECT_ROOT is not set or invalid
|
||||
7. Implement validation to ensure the specified directory exists and is accessible
|
||||
3. **AI Services Integration (ai-services-unified.js)**:
|
||||
- Add mode detection logic that reads from .taskmasterconfig
|
||||
- Implement gateway routing for hosted mode to https://api.taskmaster.ai/v1/ai
|
||||
- Create gateway request wrapper with authentication headers
|
||||
- Maintain existing BYOK provider routing as fallback
|
||||
- Add error handling for gateway unavailability with graceful degradation
|
||||
|
||||
4. **Authentication System**:
|
||||
- Implement secure API key storage and retrieval
|
||||
- Add request signing/authentication for gateway calls
|
||||
- Include user identification in gateway requests
|
||||
- Handle authentication errors with clear user messaging
|
||||
|
||||
5. **Backward Compatibility**:
|
||||
- Default to BYOK mode for existing installations without mode config
|
||||
- Preserve all existing AI provider functionality
|
||||
- Ensure seamless migration path for current users
|
||||
- Maintain existing command interfaces and outputs
|
||||
|
||||
6. **Error Handling and Fallbacks**:
|
||||
- Graceful degradation when gateway is unavailable
|
||||
- Clear error messages for authentication failures
|
||||
- Fallback to BYOK providers when gateway fails
|
||||
- Network connectivity validation and retry logic
|
||||
|
||||
# Test Strategy:
|
||||
1. Write unit tests to verify that the config loader correctly reads project root from environment variables and configuration files with the expected precedence:
|
||||
- Test TASK_MASTER_PROJECT_ROOT environment variable takes precedence when set
|
||||
- Test 'projectRoot' in configuration files is used when environment variable is absent
|
||||
- Test fallback to existing resolution logic when neither is specified
|
||||
**Testing Strategy**:
|
||||
|
||||
2. Add integration tests to ensure that the MCP server and all tools use the correct project root:
|
||||
- Test server startup with TASK_MASTER_PROJECT_ROOT set to various valid and invalid paths
|
||||
- Test configuration file loading from the specified project root
|
||||
- Test path resolution for resources relative to the project root
|
||||
1. **Configuration Testing**:
|
||||
- Verify .taskmasterconfig accepts both mode values
|
||||
- Test configuration validation for required fields per mode
|
||||
- Confirm backward compatibility with existing config files
|
||||
|
||||
3. Test backward compatibility:
|
||||
- Verify existing workflows function correctly without the new variables
|
||||
- Ensure no regression in projects not using the new configuration options
|
||||
2. **Initialization Testing**:
|
||||
- Test fresh installation with both mode selections
|
||||
- Verify hosted mode setup collects proper credentials
|
||||
- Test BYOK mode maintains existing setup flow
|
||||
- Validate gateway connectivity testing during setup
|
||||
|
||||
4. Manual testing:
|
||||
- Set TASK_MASTER_PROJECT_ROOT in shell environment and verify correct behavior
|
||||
- Set TASK_MASTER_PROJECT_ROOT in .env file and verify it's properly loaded
|
||||
- Configure 'projectRoot' in configuration files and test precedence
|
||||
- Test with invalid or non-existent directories to verify error handling
|
||||
3. **Mode Detection Testing**:
|
||||
- Test ai-services-unified.js correctly reads mode from config
|
||||
- Verify routing logic directs calls to appropriate endpoints
|
||||
- Test fallback behavior when mode is undefined (backward compatibility)
|
||||
|
||||
4. **Gateway Integration Testing**:
|
||||
- Test successful API calls to https://api.taskmaster.ai/v1/ai
|
||||
- Verify authentication headers are properly included
|
||||
- Test error handling for invalid API keys
|
||||
- Validate request/response format compatibility
|
||||
|
||||
5. **End-to-End Testing**:
|
||||
- Test complete task generation flow in hosted mode
|
||||
- Verify BYOK mode continues to work unchanged
|
||||
- Test mode switching by modifying configuration
|
||||
- Validate all existing commands work in both modes
|
||||
|
||||
6. **Error Scenario Testing**:
|
||||
- Test behavior when gateway is unreachable
|
||||
- Verify fallback to BYOK providers when configured
|
||||
- Test authentication failure handling
|
||||
- Validate network timeout scenarios
|
||||
|
||||
# Subtasks:
|
||||
## 92.1. Update configuration loader to check for TASK_MASTER_PROJECT_ROOT environment variable [pending]
|
||||
## 1. Add Mode Configuration to .taskmasterconfig Schema [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify the configuration loading system to check for the TASK_MASTER_PROJECT_ROOT environment variable as the primary source for project root directory. Ensure proper error handling if the variable is set but points to a non-existent or inaccessible directory.
|
||||
### Description: Extend the .taskmasterconfig file structure to include mode selection (byok vs hosted) and gateway authentication fields while maintaining backward compatibility.
|
||||
### Details:
|
||||
Add mode field to configuration schema with values 'byok' or 'hosted'. Include gateway authentication fields (apiKey, userId) for hosted mode. Ensure backward compatibility by defaulting to 'byok' mode for existing installations. Add validation for mode-specific required fields.
|
||||
|
||||
|
||||
## 92.2. Add support for 'projectRoot' in configuration files [pending]
|
||||
### Dependencies: None
|
||||
### Description: Implement support for a 'projectRoot' key in mcp_config.toml and mcp.json configuration files as a fallback when the environment variable is not set. Update the configuration parser to recognize and validate this field.
|
||||
## 2. Modify init.js for Mode Selection During Setup [pending]
|
||||
### Dependencies: 92.1
|
||||
### Description: Update the initialization wizard to prompt users for mode selection and collect appropriate credentials for hosted mode.
|
||||
### Details:
|
||||
Add mode selection prompt after basic configuration. Present clear descriptions of BYOK vs hosted benefits. Collect gateway API key and user credentials for hosted mode. Skip AI provider setup prompts when hosted mode is selected. Validate gateway connectivity during hosted mode setup.
|
||||
|
||||
|
||||
## 92.3. Refactor project root resolution logic with clear precedence rules [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a unified project root resolution function that follows the precedence order: 1) TASK_MASTER_PROJECT_ROOT environment variable, 2) 'projectRoot' in config files, 3) existing resolution methods. Ensure this function is used consistently throughout the codebase.
|
||||
## 3. Update ai-services-unified.js for Gateway Routing [pending]
|
||||
### Dependencies: 92.1
|
||||
### Description: Modify the unified AI service runner to detect mode and route calls to the hard-coded gateway URL when in hosted mode.
|
||||
### Details:
|
||||
Add mode detection logic that reads from .taskmasterconfig. Implement gateway routing for hosted mode to https://api.taskmaster.ai/v1/ai (hard-coded URL). Create gateway request wrapper with authentication headers. Maintain existing BYOK provider routing as fallback. Ensure identical response format for backward compatibility.
|
||||
|
||||
|
||||
## 92.4. Update all MCP tools to use the new project root resolution [pending]
|
||||
### Dependencies: None
|
||||
### Description: Identify all MCP tools and components that need to access the project root and update them to use the new resolution logic. Ensure consistent behavior across all parts of the system.
|
||||
## 4. Implement Gateway Authentication System [pending]
|
||||
### Dependencies: 92.3
|
||||
### Description: Create secure authentication system for gateway requests including API key management and request signing.
|
||||
### Details:
|
||||
Implement secure API key storage and retrieval. Add request signing/authentication for gateway calls. Include user identification in gateway requests. Handle authentication errors with clear user messaging. Add token refresh logic if needed.
|
||||
|
||||
|
||||
## 92.5. Add comprehensive tests for the new project root resolution [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create unit and integration tests to verify the correct behavior of the project root resolution logic under various configurations and edge cases.
|
||||
## 5. Add Error Handling and Fallback Logic [pending]
|
||||
### Dependencies: 92.4
|
||||
### Description: Implement comprehensive error handling for gateway unavailability with graceful degradation to BYOK mode when possible.
|
||||
### Details:
|
||||
Add error handling for gateway unavailability with graceful degradation. Implement clear error messages for authentication failures. Add fallback to BYOK providers when gateway fails (if keys are available). Include network connectivity validation and retry logic. Handle rate limiting and quota exceeded scenarios.
|
||||
|
||||
|
||||
## 92.6. Update documentation with new configuration options [pending]
|
||||
### Dependencies: None
|
||||
### Description: Update the project documentation to clearly explain the new TASK_MASTER_PROJECT_ROOT environment variable, the 'projectRoot' configuration option, and the precedence rules. Include examples of different configuration scenarios.
|
||||
## 6. Ensure Backward Compatibility and Migration [pending]
|
||||
### Dependencies: 92.1, 92.2, 92.3, 92.4, 92.5
|
||||
### Description: Ensure seamless backward compatibility for existing TaskMaster installations and provide smooth migration path to hosted mode.
|
||||
### Details:
|
||||
|
||||
|
||||
## 92.7. Implement validation for project root directory [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add validation to ensure the specified project root directory exists and has the necessary permissions. Provide clear error messages when validation fails.
|
||||
### Details:
|
||||
|
||||
|
||||
## 92.8. Implement support for loading environment variables from .env files [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add functionality to load the TASK_MASTER_PROJECT_ROOT variable from .env files in the workspace, following best practices for environment variable management in MCP servers.
|
||||
### Details:
|
||||
|
||||
Default to BYOK mode for existing installations without mode config. Preserve all existing AI provider functionality. Ensure seamless migration path for current users. Maintain existing command interfaces and outputs. Add migration utility for users wanting to switch modes. Test with existing .taskmasterconfig files.
|
||||
|
||||
|
||||
@@ -1,55 +1,64 @@
|
||||
# Task ID: 93
|
||||
# Title: Implement Google Vertex AI Provider Integration
|
||||
# Title: Implement Telemetry Testing Framework with Humorous Response Capability
|
||||
# Status: pending
|
||||
# Dependencies: 19, 94
|
||||
# Dependencies: 90, 77
|
||||
# Priority: medium
|
||||
# Description: Develop a dedicated Google Vertex AI provider in the codebase, enabling users to leverage Vertex AI models with enterprise-grade configuration and authentication.
|
||||
# Description: Create a comprehensive testing framework for validating telemetry functionality across all TaskMaster components, including the ability to respond with jokes during test scenarios to verify response handling mechanisms.
|
||||
# Details:
|
||||
1. Create a new provider class in `src/ai-providers/google-vertex.js` that extends the existing BaseAIProvider, following the established structure used by other providers (e.g., google.js, openai.js).
|
||||
2. Integrate the Vercel AI SDK's `@ai-sdk/google-vertex` package. Use the default `vertex` provider for standard usage, and allow for custom configuration via `createVertex` for advanced scenarios (e.g., specifying project ID, location, and credentials).
|
||||
3. Implement all required interface methods (such as `getClient`, `generateText`, etc.) to ensure compatibility with the provider system. Reference the implementation patterns from other providers for consistency.
|
||||
4. Handle Vertex AI-specific configuration, including project ID, location, and Google Cloud authentication. Support both environment-based authentication and explicit service account credentials via `googleAuthOptions`.
|
||||
5. Implement robust error handling for Vertex-specific issues, including authentication failures and API errors, leveraging the system-wide error handling patterns.
|
||||
6. Update `src/ai-providers/index.js` to export the new provider, and add the 'vertex' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`.
|
||||
7. Update documentation to provide clear setup instructions for Google Vertex AI, including required environment variables, service account setup, and configuration examples.
|
||||
8. Ensure the implementation is modular and maintainable, supporting future expansion for additional Vertex AI features or models.
|
||||
This task implements a robust testing framework for telemetry validation with the following components:
|
||||
|
||||
1. **Telemetry Test Suite Creation**:
|
||||
- Create `tests/telemetry/` directory structure with comprehensive test files
|
||||
- Implement unit tests for telemetry data capture, sanitization, and transmission
|
||||
- Add integration tests for end-to-end telemetry flow validation
|
||||
- Create mock telemetry endpoints to simulate external analytics services
|
||||
|
||||
2. **Joke Response Testing Module**:
|
||||
- Implement a test utility that can inject humorous responses during telemetry testing
|
||||
- Create a collection of programming-related jokes for test scenarios
|
||||
- Add response validation to ensure joke responses are properly handled by telemetry systems
|
||||
- Implement timing tests to verify joke responses don't interfere with telemetry performance
|
||||
|
||||
3. **Telemetry Data Validation**:
|
||||
- Create validators for telemetry payload structure and content
|
||||
- Implement tests for sensitive data redaction and encryption
|
||||
- Add verification for proper anonymization of user data
|
||||
- Test telemetry opt-out functionality and preference handling
|
||||
|
||||
4. **Performance and Reliability Testing**:
|
||||
- Implement load testing for telemetry submission under various conditions
|
||||
- Add network failure simulation and retry mechanism testing
|
||||
- Create tests for telemetry buffer management and data persistence
|
||||
- Validate telemetry doesn't impact core TaskMaster functionality
|
||||
|
||||
5. **Cross-Mode Testing**:
|
||||
- Test telemetry functionality in both BYOK and hosted gateway modes
|
||||
- Validate mode-specific telemetry data collection and routing
|
||||
- Ensure consistent telemetry behavior across different AI providers
|
||||
|
||||
6. **Test Utilities and Helpers**:
|
||||
- Create mock telemetry services for isolated testing
|
||||
- Implement test data generators for various telemetry scenarios
|
||||
- Add debugging utilities for telemetry troubleshooting
|
||||
- Create automated test reporting for telemetry coverage
|
||||
|
||||
# Test Strategy:
|
||||
- Write unit tests for the new provider class, covering all interface methods and configuration scenarios (default, custom, error cases).
|
||||
- Verify that the provider can successfully authenticate using both environment-based and explicit service account credentials.
|
||||
- Test integration with the provider system by selecting 'vertex' as the provider and generating text using supported Vertex AI models (e.g., Gemini).
|
||||
- Simulate authentication and API errors to confirm robust error handling and user feedback.
|
||||
- Confirm that the provider is correctly exported and available in the PROVIDERS object.
|
||||
- Review and validate the updated documentation for accuracy and completeness.
|
||||
1. **Unit Test Validation**: Run all telemetry unit tests to verify individual component functionality, ensuring 100% pass rate for data capture, sanitization, and transmission modules.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Google Vertex AI Provider Class [pending]
|
||||
### Dependencies: None
|
||||
### Description: Develop a new provider class in `src/ai-providers/google-vertex.js` that extends the BaseAIProvider, following the structure of existing providers.
|
||||
### Details:
|
||||
Ensure the new class is consistent with the architecture of other providers such as google.js and openai.js, and is ready to integrate with the AI SDK.
|
||||
2. **Integration Test Execution**: Execute end-to-end telemetry tests across all TaskMaster commands, validating that telemetry data is properly collected and transmitted without affecting command performance.
|
||||
|
||||
## 2. Integrate Vercel AI SDK Google Vertex Package [pending]
|
||||
### Dependencies: 93.1
|
||||
### Description: Integrate the `@ai-sdk/google-vertex` package, supporting both the default provider and custom configuration via `createVertex`.
|
||||
### Details:
|
||||
Allow for standard usage with the default `vertex` provider and advanced scenarios using `createVertex` for custom project ID, location, and credentials as per SDK documentation.
|
||||
3. **Joke Response Verification**: Test the joke response mechanism by triggering test scenarios and verifying that humorous responses are delivered correctly while maintaining telemetry data integrity.
|
||||
|
||||
## 3. Implement Provider Interface Methods [pending]
|
||||
### Dependencies: 93.2
|
||||
### Description: Implement all required interface methods (e.g., `getClient`, `generateText`) to ensure compatibility with the provider system.
|
||||
### Details:
|
||||
Reference implementation patterns from other providers to maintain consistency and ensure all required methods are present and functional.
|
||||
4. **Data Privacy Validation**: Verify that all sensitive data is properly redacted or encrypted in telemetry payloads, with no personally identifiable information exposed in test outputs.
|
||||
|
||||
## 4. Handle Vertex AI Configuration and Authentication [pending]
|
||||
### Dependencies: 93.3
|
||||
### Description: Implement support for Vertex AI-specific configuration, including project ID, location, and authentication via environment variables or explicit service account credentials.
|
||||
### Details:
|
||||
Support both environment-based authentication and explicit credentials using `googleAuthOptions`, following Google Cloud and Vertex AI setup best practices.
|
||||
5. **Performance Impact Assessment**: Run performance benchmarks comparing TaskMaster execution with and without telemetry enabled, ensuring minimal performance degradation (< 5% overhead).
|
||||
|
||||
## 5. Update Exports, Documentation, and Error Handling [pending]
|
||||
### Dependencies: 93.4
|
||||
### Description: Export the new provider, update the PROVIDERS object, and document setup instructions, including robust error handling for Vertex-specific issues.
|
||||
### Details:
|
||||
Update `src/ai-providers/index.js` and `scripts/modules/ai-services-unified.js`, and provide clear documentation for setup, configuration, and error handling patterns.
|
||||
6. **Network Failure Simulation**: Test telemetry behavior under various network conditions including timeouts, connection failures, and intermittent connectivity to validate retry mechanisms and data persistence.
|
||||
|
||||
7. **Cross-Mode Compatibility**: Execute telemetry tests in both BYOK and hosted gateway modes, verifying consistent behavior and appropriate mode-specific data collection.
|
||||
|
||||
8. **Opt-out Functionality Testing**: Validate that telemetry opt-out preferences are properly respected and no data is collected or transmitted when users have opted out.
|
||||
|
||||
9. **Mock Service Integration**: Verify that mock telemetry endpoints properly simulate real analytics services and capture expected data formats and frequencies.
|
||||
|
||||
10. **Automated Test Coverage**: Ensure test suite achieves minimum 90% code coverage for all telemetry-related modules and generates comprehensive test reports.
|
||||
|
||||
@@ -1,103 +0,0 @@
|
||||
# Task ID: 94
|
||||
# Title: Implement Azure OpenAI Provider Integration
|
||||
# Status: done
|
||||
# Dependencies: 19, 26
|
||||
# Priority: medium
|
||||
# Description: Create a comprehensive Azure OpenAI provider implementation that integrates with the existing AI provider system, enabling users to leverage Azure-hosted OpenAI models through proper authentication and configuration.
|
||||
# Details:
|
||||
Implement the Azure OpenAI provider following the established provider pattern:
|
||||
|
||||
1. **Create Azure Provider Class** (`src/ai-providers/azure.js`):
|
||||
- Extend BaseAIProvider class following the same pattern as openai.js and google.js
|
||||
- Import and use `createAzureOpenAI` from `@ai-sdk/azure` package
|
||||
- Implement required interface methods: `getClient()`, `validateConfig()`, and any other abstract methods
|
||||
- Handle Azure-specific configuration: endpoint URL, API key, and deployment name
|
||||
- Add proper error handling for missing or invalid Azure configuration
|
||||
|
||||
2. **Configuration Management**:
|
||||
- Support environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, AZURE_OPENAI_DEPLOYMENT
|
||||
- Validate that both endpoint and API key are provided
|
||||
- Provide clear error messages for configuration issues
|
||||
- Follow the same configuration pattern as other providers
|
||||
|
||||
3. **Integration Updates**:
|
||||
- Update `src/ai-providers/index.js` to export the new AzureProvider
|
||||
- Add 'azure' entry to the PROVIDERS object in `scripts/modules/ai-services-unified.js`
|
||||
- Ensure the provider is properly registered and accessible through the unified AI services
|
||||
|
||||
4. **Error Handling**:
|
||||
- Implement Azure-specific error handling for authentication failures
|
||||
- Handle endpoint connectivity issues with helpful error messages
|
||||
- Validate deployment name and provide guidance for common configuration mistakes
|
||||
- Follow the established error handling patterns from Task 19
|
||||
|
||||
5. **Documentation Updates**:
|
||||
- Update any provider documentation to include Azure OpenAI setup instructions
|
||||
- Add configuration examples for Azure OpenAI environment variables
|
||||
- Include troubleshooting guidance for common Azure-specific issues
|
||||
|
||||
The implementation should maintain consistency with existing provider implementations while handling Azure's unique authentication and endpoint requirements.
|
||||
|
||||
# Test Strategy:
|
||||
Verify the Azure OpenAI provider implementation through comprehensive testing:
|
||||
|
||||
1. **Unit Testing**:
|
||||
- Test provider class instantiation and configuration validation
|
||||
- Verify getClient() method returns properly configured Azure OpenAI client
|
||||
- Test error handling for missing/invalid configuration parameters
|
||||
- Validate that the provider correctly extends BaseAIProvider
|
||||
|
||||
2. **Integration Testing**:
|
||||
- Test provider registration in the unified AI services system
|
||||
- Verify the provider appears in the PROVIDERS object and is accessible
|
||||
- Test end-to-end functionality with valid Azure OpenAI credentials
|
||||
- Validate that the provider works with existing AI operation workflows
|
||||
|
||||
3. **Configuration Testing**:
|
||||
- Test with various environment variable combinations
|
||||
- Verify proper error messages for missing endpoint or API key
|
||||
- Test with invalid endpoint URLs and ensure graceful error handling
|
||||
- Validate deployment name handling and error reporting
|
||||
|
||||
4. **Manual Verification**:
|
||||
- Set up test Azure OpenAI credentials and verify successful connection
|
||||
- Test actual AI operations (like task expansion) using the Azure provider
|
||||
- Verify that the provider selection works correctly in the CLI
|
||||
- Confirm that error messages are helpful and actionable for users
|
||||
|
||||
5. **Documentation Verification**:
|
||||
- Ensure all configuration examples work as documented
|
||||
- Verify that setup instructions are complete and accurate
|
||||
- Test troubleshooting guidance with common error scenarios
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Azure Provider Class [done]
|
||||
### Dependencies: None
|
||||
### Description: Implement the AzureProvider class that extends BaseAIProvider to handle Azure OpenAI integration
|
||||
### Details:
|
||||
Create the AzureProvider class in src/ai-providers/azure.js that extends BaseAIProvider. Import createAzureOpenAI from @ai-sdk/azure package. Implement required interface methods including getClient() and validateConfig(). Handle Azure-specific configuration parameters: endpoint URL, API key, and deployment name. Follow the established pattern in openai.js and google.js. Ensure proper error handling for missing or invalid configuration.
|
||||
|
||||
## 2. Implement Configuration Management [done]
|
||||
### Dependencies: 94.1
|
||||
### Description: Add support for Azure OpenAI environment variables and configuration validation
|
||||
### Details:
|
||||
Implement configuration management for Azure OpenAI provider that supports environment variables: AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_KEY, and AZURE_OPENAI_DEPLOYMENT. Add validation logic to ensure both endpoint and API key are provided. Create clear error messages for configuration issues. Follow the same configuration pattern as implemented in other providers. Ensure the validateConfig() method properly checks all required Azure configuration parameters.
|
||||
|
||||
## 3. Update Provider Integration [done]
|
||||
### Dependencies: 94.1, 94.2
|
||||
### Description: Integrate the Azure provider into the existing AI provider system
|
||||
### Details:
|
||||
Update src/ai-providers/index.js to export the new AzureProvider class. Add 'azure' entry to the PROVIDERS object in scripts/modules/ai-services-unified.js. Ensure the provider is properly registered and accessible through the unified AI services. Test that the provider can be instantiated and used through the provider selection mechanism. Follow the same integration pattern used for existing providers.
|
||||
|
||||
## 4. Implement Azure-Specific Error Handling [done]
|
||||
### Dependencies: 94.1, 94.2
|
||||
### Description: Add specialized error handling for Azure OpenAI-specific issues
|
||||
### Details:
|
||||
Implement Azure-specific error handling for authentication failures, endpoint connectivity issues, and deployment name validation. Provide helpful error messages that guide users to resolve common configuration mistakes. Follow the established error handling patterns from Task 19. Create custom error classes if needed for Azure-specific errors. Ensure errors are properly propagated and formatted for user display.
|
||||
|
||||
## 5. Update Documentation [done]
|
||||
### Dependencies: 94.1, 94.2, 94.3, 94.4
|
||||
### Description: Create comprehensive documentation for the Azure OpenAI provider integration
|
||||
### Details:
|
||||
Update provider documentation to include Azure OpenAI setup instructions. Add configuration examples for Azure OpenAI environment variables. Include troubleshooting guidance for common Azure-specific issues. Document the required Azure resource creation process with references to Microsoft's documentation. Provide examples of valid configuration settings and explain each required parameter. Include information about Azure OpenAI model deployment requirements.
|
||||
|
||||
1229
tasks/tasks.json
1229
tasks/tasks.json
File diff suppressed because one or more lines are too long
1130
tasks/tasks.json.bak
1130
tasks/tasks.json.bak
File diff suppressed because one or more lines are too long
227
test-move-fix.js
Normal file
227
test-move-fix.js
Normal file
@@ -0,0 +1,227 @@
|
||||
/**
|
||||
* Test script for move-task functionality
|
||||
*
|
||||
* This script tests various scenarios for the move-task command to ensure
|
||||
* it works correctly without creating duplicate tasks or leaving orphaned data.
|
||||
*
|
||||
* Test scenarios covered:
|
||||
* 1. Moving a subtask to become a standalone task (with specific target ID)
|
||||
* 2. Moving a task to replace another task
|
||||
*
|
||||
* Usage:
|
||||
* node test-move-fix.js # Run all tests
|
||||
*
|
||||
* Or import specific test functions:
|
||||
* import { testMoveSubtaskToTask } from './test-move-fix.js';
|
||||
*
|
||||
* This was created to verify the fix for the bug where moving subtasks
|
||||
* to standalone tasks was creating duplicate entries.
|
||||
*/
|
||||
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
import moveTask from "./scripts/modules/task-manager/move-task.js";
|
||||
|
||||
// Create a test tasks.json file
|
||||
const testData = {
|
||||
tasks: [
|
||||
{
|
||||
id: 1,
|
||||
title: "Parent Task",
|
||||
description: "A parent task with subtasks",
|
||||
status: "pending",
|
||||
priority: "medium",
|
||||
details: "Parent task details",
|
||||
testStrategy: "Parent test strategy",
|
||||
subtasks: [
|
||||
{
|
||||
id: 1,
|
||||
title: "Subtask 1",
|
||||
description: "First subtask",
|
||||
status: "pending",
|
||||
details: "Subtask 1 details",
|
||||
testStrategy: "Subtask 1 test strategy",
|
||||
},
|
||||
{
|
||||
id: 2,
|
||||
title: "Subtask 2",
|
||||
description: "Second subtask",
|
||||
status: "pending",
|
||||
details: "Subtask 2 details",
|
||||
testStrategy: "Subtask 2 test strategy",
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
id: 2,
|
||||
title: "Another Task",
|
||||
description: "Another standalone task",
|
||||
status: "pending",
|
||||
priority: "low",
|
||||
details: "Another task details",
|
||||
testStrategy: "Another test strategy",
|
||||
},
|
||||
{
|
||||
id: 3,
|
||||
title: "Third Task",
|
||||
description: "A third standalone task",
|
||||
status: "done",
|
||||
priority: "high",
|
||||
details: "Third task details",
|
||||
testStrategy: "Third test strategy",
|
||||
},
|
||||
],
|
||||
};
|
||||
|
||||
const testFile = "./test-tasks.json";
|
||||
|
||||
function logSeparator(title) {
|
||||
console.log(`\n${"=".repeat(60)}`);
|
||||
console.log(` ${title}`);
|
||||
console.log(`${"=".repeat(60)}`);
|
||||
}
|
||||
|
||||
function logTaskState(data, label) {
|
||||
console.log(`\n${label}:`);
|
||||
console.log(
|
||||
"Tasks:",
|
||||
data.tasks.map((t) => ({ id: t.id, title: t.title, status: t.status }))
|
||||
);
|
||||
|
||||
data.tasks.forEach((task) => {
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
console.log(
|
||||
`Task ${task.id} subtasks:`,
|
||||
task.subtasks.map((st) => ({ id: st.id, title: st.title }))
|
||||
);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
async function testMoveSubtaskToTask() {
|
||||
try {
|
||||
logSeparator("TEST: Move Subtask to Standalone Task");
|
||||
|
||||
// Write test data
|
||||
fs.writeFileSync(testFile, JSON.stringify(testData, null, 2));
|
||||
|
||||
const beforeData = JSON.parse(fs.readFileSync(testFile, "utf8"));
|
||||
logTaskState(beforeData, "Before move");
|
||||
|
||||
// Move subtask 1.2 to become task 26
|
||||
console.log("\n🔄 Moving subtask 1.2 to task 26...");
|
||||
const result = await moveTask(testFile, "1.2", "26", false);
|
||||
|
||||
const afterData = JSON.parse(fs.readFileSync(testFile, "utf8"));
|
||||
logTaskState(afterData, "After move");
|
||||
|
||||
// Verify the result
|
||||
const task26 = afterData.tasks.find((t) => t.id === 26);
|
||||
if (task26) {
|
||||
console.log("\n✅ SUCCESS: Task 26 created with correct content:");
|
||||
console.log(" Title:", task26.title);
|
||||
console.log(" Description:", task26.description);
|
||||
console.log(" Details:", task26.details);
|
||||
console.log(" Dependencies:", task26.dependencies);
|
||||
console.log(" Priority:", task26.priority);
|
||||
} else {
|
||||
console.log("\n❌ FAILED: Task 26 not found");
|
||||
}
|
||||
|
||||
// Check for duplicates
|
||||
const taskIds = afterData.tasks.map((t) => t.id);
|
||||
const duplicates = taskIds.filter(
|
||||
(id, index) => taskIds.indexOf(id) !== index
|
||||
);
|
||||
if (duplicates.length > 0) {
|
||||
console.log("\n❌ FAILED: Duplicate task IDs found:", duplicates);
|
||||
} else {
|
||||
console.log("\n✅ SUCCESS: No duplicate task IDs");
|
||||
}
|
||||
|
||||
// Check that original subtask was removed
|
||||
const task1 = afterData.tasks.find((t) => t.id === 1);
|
||||
const hasSubtask2 = task1.subtasks?.some((st) => st.id === 2);
|
||||
if (hasSubtask2) {
|
||||
console.log("\n❌ FAILED: Original subtask 1.2 still exists");
|
||||
} else {
|
||||
console.log("\n✅ SUCCESS: Original subtask 1.2 was removed");
|
||||
}
|
||||
|
||||
return true;
|
||||
} catch (error) {
|
||||
console.error("\n❌ Test failed:", error.message);
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
async function testMoveTaskToTask() {
|
||||
try {
|
||||
logSeparator("TEST: Move Task to Replace Another Task");
|
||||
|
||||
// Reset test data
|
||||
fs.writeFileSync(testFile, JSON.stringify(testData, null, 2));
|
||||
|
||||
const beforeData = JSON.parse(fs.readFileSync(testFile, "utf8"));
|
||||
logTaskState(beforeData, "Before move");
|
||||
|
||||
// Move task 2 to replace task 3
|
||||
console.log("\n🔄 Moving task 2 to replace task 3...");
|
||||
const result = await moveTask(testFile, "2", "3", false);
|
||||
|
||||
const afterData = JSON.parse(fs.readFileSync(testFile, "utf8"));
|
||||
logTaskState(afterData, "After move");
|
||||
|
||||
// Verify the result
|
||||
const task3 = afterData.tasks.find((t) => t.id === 3);
|
||||
const task2Gone = !afterData.tasks.find((t) => t.id === 2);
|
||||
|
||||
if (task3 && task3.title === "Another Task" && task2Gone) {
|
||||
console.log("\n✅ SUCCESS: Task 2 replaced task 3 correctly");
|
||||
console.log(" New Task 3 title:", task3.title);
|
||||
console.log(" New Task 3 description:", task3.description);
|
||||
} else {
|
||||
console.log("\n❌ FAILED: Task replacement didn't work correctly");
|
||||
}
|
||||
|
||||
return true;
|
||||
} catch (error) {
|
||||
console.error("\n❌ Test failed:", error.message);
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
async function runAllTests() {
|
||||
console.log("🧪 Running Move Task Tests");
|
||||
|
||||
const results = [];
|
||||
|
||||
results.push(await testMoveSubtaskToTask());
|
||||
results.push(await testMoveTaskToTask());
|
||||
|
||||
const passed = results.filter((r) => r).length;
|
||||
const total = results.length;
|
||||
|
||||
logSeparator("TEST SUMMARY");
|
||||
console.log(`\n📊 Results: ${passed}/${total} tests passed`);
|
||||
|
||||
if (passed === total) {
|
||||
console.log("🎉 All tests passed!");
|
||||
} else {
|
||||
console.log("⚠️ Some tests failed. Check the output above.");
|
||||
}
|
||||
|
||||
// Clean up
|
||||
if (fs.existsSync(testFile)) {
|
||||
fs.unlinkSync(testFile);
|
||||
console.log("\n🧹 Cleaned up test files");
|
||||
}
|
||||
}
|
||||
|
||||
// Run tests if this file is executed directly
|
||||
if (import.meta.url === `file://${process.argv[1]}`) {
|
||||
runAllTests();
|
||||
}
|
||||
|
||||
// Export for use in other test files
|
||||
export { testMoveSubtaskToTask, testMoveTaskToTask, runAllTests };
|
||||
95
test-telemetry-integration.js
Normal file
95
test-telemetry-integration.js
Normal file
@@ -0,0 +1,95 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* Integration test for telemetry submission with real gateway
|
||||
*/
|
||||
|
||||
import { submitTelemetryData } from "./scripts/modules/telemetry-submission.js";
|
||||
|
||||
// Test data from the gateway registration
|
||||
const TEST_API_KEY = "554d9e2a-9c07-4f69-a449-a2bda0ff06e7";
|
||||
const TEST_USER_ID = "c81e686a-a37c-4dc4-ac23-0849f70a9a52";
|
||||
|
||||
async function testTelemetrySubmission() {
|
||||
console.log("🧪 Testing telemetry submission with real gateway...\n");
|
||||
|
||||
// Create test telemetry data
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: TEST_USER_ID,
|
||||
commandName: "add-task",
|
||||
modelUsed: "claude-3-sonnet",
|
||||
providerName: "anthropic",
|
||||
inputTokens: 150,
|
||||
outputTokens: 75,
|
||||
totalTokens: 225,
|
||||
totalCost: 0.0045,
|
||||
currency: "USD",
|
||||
// These should be filtered out before submission
|
||||
commandArgs: {
|
||||
id: "15",
|
||||
prompt: "Test task creation",
|
||||
apiKey: "sk-secret-key-should-be-filtered",
|
||||
},
|
||||
fullOutput: {
|
||||
title: "Generated Task",
|
||||
description: "AI generated task description",
|
||||
internalDebugData: "This should not be sent to gateway",
|
||||
},
|
||||
};
|
||||
|
||||
console.log("📤 Submitting telemetry data...");
|
||||
console.log("Data to submit:", JSON.stringify(telemetryData, null, 2));
|
||||
console.log(
|
||||
"\n⚠️ Note: commandArgs and fullOutput should be filtered out before submission\n"
|
||||
);
|
||||
|
||||
try {
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
console.log("✅ Telemetry submission result:");
|
||||
console.log(JSON.stringify(result, null, 2));
|
||||
|
||||
if (result.success) {
|
||||
console.log("\n🎉 SUCCESS: Telemetry data submitted successfully!");
|
||||
if (result.id) {
|
||||
console.log(`📝 Gateway assigned ID: ${result.id}`);
|
||||
}
|
||||
console.log(`🔄 Completed in ${result.attempt || 1} attempt(s)`);
|
||||
} else {
|
||||
console.log("\n❌ FAILED: Telemetry submission failed");
|
||||
console.log(`Error: ${result.error}`);
|
||||
}
|
||||
} catch (error) {
|
||||
console.error(
|
||||
"\n💥 EXCEPTION: Unexpected error during telemetry submission"
|
||||
);
|
||||
console.error(error);
|
||||
}
|
||||
}
|
||||
|
||||
// Test with manual curl to verify endpoint works
|
||||
async function testWithCurl() {
|
||||
console.log("\n🔧 Testing with direct curl for comparison...\n");
|
||||
|
||||
const testData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: TEST_USER_ID,
|
||||
commandName: "curl-test",
|
||||
modelUsed: "claude-3-sonnet",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
};
|
||||
|
||||
console.log("Curl command that should work:");
|
||||
console.log(`curl -X POST http://localhost:4444/api/v1/telemetry \\`);
|
||||
console.log(` -H "Content-Type: application/json" \\`);
|
||||
console.log(` -H "X-API-Key: ${TEST_API_KEY}" \\`);
|
||||
console.log(` -d '${JSON.stringify(testData)}'`);
|
||||
}
|
||||
|
||||
// Run the tests
|
||||
console.log("🚀 Starting telemetry integration tests...\n");
|
||||
await testTelemetrySubmission();
|
||||
await testWithCurl();
|
||||
console.log("\n✨ Integration test complete!");
|
||||
16
tests/fixtures/.taskmasterconfig
vendored
16
tests/fixtures/.taskmasterconfig
vendored
@@ -1,16 +0,0 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "openai",
|
||||
"modelId": "gpt-4o"
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro"
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-haiku-20240307"
|
||||
}
|
||||
}
|
||||
}
|
||||
253
tests/integration/init-config.test.js
Normal file
253
tests/integration/init-config.test.js
Normal file
@@ -0,0 +1,253 @@
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
import { execSync } from "child_process";
|
||||
import { jest } from "@jest/globals";
|
||||
import { fileURLToPath } from "url";
|
||||
|
||||
const __filename = fileURLToPath(import.meta.url);
|
||||
const __dirname = path.dirname(__filename);
|
||||
|
||||
describe("TaskMaster Init Configuration Tests", () => {
|
||||
const testProjectDir = path.join(__dirname, "../../test-init-project");
|
||||
const configPath = path.join(testProjectDir, ".taskmasterconfig");
|
||||
const envPath = path.join(testProjectDir, ".env");
|
||||
|
||||
beforeEach(() => {
|
||||
// Clear all mocks and reset modules to prevent interference from other tests
|
||||
jest.clearAllMocks();
|
||||
jest.resetAllMocks();
|
||||
jest.resetModules();
|
||||
|
||||
// Clean up test directory
|
||||
if (fs.existsSync(testProjectDir)) {
|
||||
execSync(`rm -rf "${testProjectDir}"`);
|
||||
}
|
||||
fs.mkdirSync(testProjectDir, { recursive: true });
|
||||
process.chdir(testProjectDir);
|
||||
});
|
||||
|
||||
afterEach(() => {
|
||||
// Clean up after tests
|
||||
process.chdir(__dirname);
|
||||
if (fs.existsSync(testProjectDir)) {
|
||||
execSync(`rm -rf "${testProjectDir}"`);
|
||||
}
|
||||
|
||||
// Clear mocks again
|
||||
jest.clearAllMocks();
|
||||
jest.resetAllMocks();
|
||||
});
|
||||
|
||||
describe("getUserId functionality", () => {
|
||||
it("should read userId from config.account.userId", async () => {
|
||||
// Create config with userId in account section
|
||||
const config = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
userId: "test-user-123",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
// Import and test getUserId
|
||||
const { getUserId } = await import(
|
||||
"../../scripts/modules/config-manager.js"
|
||||
);
|
||||
const userId = getUserId(testProjectDir);
|
||||
|
||||
expect(userId).toBe("test-user-123");
|
||||
});
|
||||
|
||||
it("should set default userId if none exists", async () => {
|
||||
// Create config without userId
|
||||
const config = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
const { getUserId } = await import(
|
||||
"../../scripts/modules/config-manager.js"
|
||||
);
|
||||
const userId = getUserId(testProjectDir);
|
||||
|
||||
// Should set default userId
|
||||
expect(userId).toBe("1234567890");
|
||||
|
||||
// Verify it was written to config
|
||||
const savedConfig = JSON.parse(fs.readFileSync(configPath, "utf8"));
|
||||
expect(savedConfig.account.userId).toBe("1234567890");
|
||||
});
|
||||
|
||||
it("should return existing userId even if it's the default value", async () => {
|
||||
// Create config with default userId already set
|
||||
const config = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
userId: "1234567890",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
const { getUserId } = await import(
|
||||
"../../scripts/modules/config-manager.js"
|
||||
);
|
||||
const userId = getUserId(testProjectDir);
|
||||
|
||||
// Should return the existing userId (even if it's the default)
|
||||
expect(userId).toBe("1234567890");
|
||||
});
|
||||
});
|
||||
|
||||
describe("Init process integration", () => {
|
||||
it("should store mode (byok/hosted) in config", () => {
|
||||
// Test that mode gets stored correctly
|
||||
const config = {
|
||||
account: {
|
||||
mode: "hosted",
|
||||
userId: "test-user-789",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
// Read config back
|
||||
const savedConfig = JSON.parse(fs.readFileSync(configPath, "utf8"));
|
||||
expect(savedConfig.account.mode).toBe("hosted");
|
||||
expect(savedConfig.account.userId).toBe("test-user-789");
|
||||
});
|
||||
|
||||
it("should store API key in .env file (NOT config)", () => {
|
||||
// Create .env with API key
|
||||
const envContent =
|
||||
"TASKMASTER_SERVICE_ID=test-api-key-123\nOTHER_VAR=value\n";
|
||||
fs.writeFileSync(envPath, envContent);
|
||||
|
||||
// Test that API key is in .env
|
||||
const envFileContent = fs.readFileSync(envPath, "utf8");
|
||||
expect(envFileContent).toContain(
|
||||
"TASKMASTER_SERVICE_ID=test-api-key-123"
|
||||
);
|
||||
|
||||
// Test that API key is NOT in config
|
||||
const config = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
userId: "test-user-abc",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
const configContent = fs.readFileSync(configPath, "utf8");
|
||||
expect(configContent).not.toContain("test-api-key-123");
|
||||
expect(configContent).not.toContain("apiKey");
|
||||
});
|
||||
});
|
||||
|
||||
describe("Telemetry configuration", () => {
|
||||
it("should get API key from .env file", async () => {
|
||||
// Create .env with API key
|
||||
const envContent = "TASKMASTER_SERVICE_ID=env-api-key-456\n";
|
||||
fs.writeFileSync(envPath, envContent);
|
||||
|
||||
// Test reading API key from .env
|
||||
const { resolveEnvVariable } = await import(
|
||||
"../../scripts/modules/utils.js"
|
||||
);
|
||||
const apiKey = resolveEnvVariable(
|
||||
"TASKMASTER_SERVICE_ID",
|
||||
null,
|
||||
testProjectDir
|
||||
);
|
||||
|
||||
expect(apiKey).toBe("env-api-key-456");
|
||||
});
|
||||
|
||||
it("should prioritize environment variables", async () => {
|
||||
// Clean up any existing env var first
|
||||
delete process.env.TASKMASTER_SERVICE_ID;
|
||||
|
||||
// Set environment variable
|
||||
process.env.TASKMASTER_SERVICE_ID = "process-env-key";
|
||||
|
||||
// Also create .env file
|
||||
const envContent = "TASKMASTER_SERVICE_ID=file-env-key\n";
|
||||
fs.writeFileSync(envPath, envContent);
|
||||
|
||||
const { resolveEnvVariable } = await import(
|
||||
"../../scripts/modules/utils.js"
|
||||
);
|
||||
|
||||
// Test with explicit projectRoot to avoid caching issues
|
||||
const apiKey = resolveEnvVariable("TASKMASTER_SERVICE_ID");
|
||||
|
||||
// Should prioritize process.env over .env file
|
||||
expect(apiKey).toBe("process-env-key");
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_SERVICE_ID;
|
||||
});
|
||||
});
|
||||
|
||||
describe("Config structure consistency", () => {
|
||||
it("should maintain consistent structure for both BYOK and hosted modes", () => {
|
||||
// Test BYOK mode structure
|
||||
const byokConfig = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
userId: "byok-user-123",
|
||||
telemetryEnabled: false,
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(byokConfig, null, 2));
|
||||
|
||||
let config = JSON.parse(fs.readFileSync(configPath, "utf8"));
|
||||
expect(config.account.mode).toBe("byok");
|
||||
expect(config.account.userId).toBe("byok-user-123");
|
||||
expect(config.account.telemetryEnabled).toBe(false);
|
||||
|
||||
// Test hosted mode structure
|
||||
const hostedConfig = {
|
||||
account: {
|
||||
mode: "hosted",
|
||||
userId: "hosted-user-456",
|
||||
telemetryEnabled: true,
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(hostedConfig, null, 2));
|
||||
|
||||
config = JSON.parse(fs.readFileSync(configPath, "utf8"));
|
||||
expect(config.account.mode).toBe("hosted");
|
||||
expect(config.account.userId).toBe("hosted-user-456");
|
||||
expect(config.account.telemetryEnabled).toBe(true);
|
||||
});
|
||||
|
||||
it("should use consistent userId location (config.account.userId)", async () => {
|
||||
const config = {
|
||||
account: {
|
||||
mode: "byok",
|
||||
userId: "consistent-user-789",
|
||||
},
|
||||
global: {
|
||||
logLevel: "info",
|
||||
},
|
||||
};
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
|
||||
// Clear any cached modules to ensure fresh import
|
||||
jest.resetModules();
|
||||
|
||||
const { getUserId } = await import(
|
||||
"../../scripts/modules/config-manager.js"
|
||||
);
|
||||
const userId = getUserId(testProjectDir);
|
||||
|
||||
expect(userId).toBe("consistent-user-789");
|
||||
|
||||
// Verify it's in account section, not root
|
||||
const savedConfig = JSON.parse(fs.readFileSync(configPath, "utf8"));
|
||||
expect(savedConfig.account.userId).toBe("consistent-user-789");
|
||||
expect(savedConfig.userId).toBeUndefined(); // Should NOT be in root
|
||||
});
|
||||
});
|
||||
});
|
||||
@@ -1,59 +1,62 @@
|
||||
import { jest } from '@jest/globals';
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
import os from 'os';
|
||||
import { execSync } from 'child_process';
|
||||
import { jest } from "@jest/globals";
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
import os from "os";
|
||||
import { execSync } from "child_process";
|
||||
|
||||
describe('Roo Files Inclusion in Package', () => {
|
||||
// This test verifies that the required Roo files are included in the final package
|
||||
describe("Roo Files Inclusion in Package", () => {
|
||||
// This test verifies that the required Roo files are included in the final package
|
||||
|
||||
test('package.json includes assets/** in the "files" array for Roo source files', () => {
|
||||
// Read the package.json file
|
||||
const packageJsonPath = path.join(process.cwd(), 'package.json');
|
||||
const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
|
||||
test('package.json includes assets/** in the "files" array for Roo source files', () => {
|
||||
// Read the package.json file
|
||||
const packageJsonPath = path.join(process.cwd(), "package.json");
|
||||
const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, "utf8"));
|
||||
|
||||
// Check if assets/** is included in the files array (which contains Roo files)
|
||||
expect(packageJson.files).toContain('assets/**');
|
||||
});
|
||||
// Check if assets/** is included in the files array (which contains Roo files)
|
||||
expect(packageJson.files).toContain("assets/**");
|
||||
});
|
||||
|
||||
test('init.js creates Roo directories and copies files', () => {
|
||||
// Read the init.js file
|
||||
const initJsPath = path.join(process.cwd(), 'scripts', 'init.js');
|
||||
const initJsContent = fs.readFileSync(initJsPath, 'utf8');
|
||||
test("init.js creates Roo directories and copies files", () => {
|
||||
// Read the init.js file
|
||||
const initJsPath = path.join(process.cwd(), "scripts", "init.js");
|
||||
const initJsContent = fs.readFileSync(initJsPath, "utf8");
|
||||
|
||||
// Check for Roo directory creation (using more flexible pattern matching)
|
||||
const hasRooDir = initJsContent.includes(
|
||||
"ensureDirectoryExists(path.join(targetDir, '.roo"
|
||||
);
|
||||
expect(hasRooDir).toBe(true);
|
||||
// Check for Roo directory creation (flexible quote matching)
|
||||
const hasRooDir =
|
||||
/ensureDirectoryExists\(path\.join\(targetDir,\s*['""]\.roo/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(hasRooDir).toBe(true);
|
||||
|
||||
// Check for .roomodes file copying
|
||||
const hasRoomodes = initJsContent.includes("copyTemplateFile('.roomodes'");
|
||||
expect(hasRoomodes).toBe(true);
|
||||
// Check for .roomodes file copying (flexible quote matching)
|
||||
const hasRoomodes = /copyTemplateFile\(\s*['""]\.roomodes['""]/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(hasRoomodes).toBe(true);
|
||||
|
||||
// Check for mode-specific patterns (using more flexible pattern matching)
|
||||
const hasArchitect = initJsContent.includes('architect');
|
||||
const hasAsk = initJsContent.includes('ask');
|
||||
const hasBoomerang = initJsContent.includes('boomerang');
|
||||
const hasCode = initJsContent.includes('code');
|
||||
const hasDebug = initJsContent.includes('debug');
|
||||
const hasTest = initJsContent.includes('test');
|
||||
// Check for mode-specific patterns (using more flexible pattern matching)
|
||||
const hasArchitect = initJsContent.includes("architect");
|
||||
const hasAsk = initJsContent.includes("ask");
|
||||
const hasBoomerang = initJsContent.includes("boomerang");
|
||||
const hasCode = initJsContent.includes("code");
|
||||
const hasDebug = initJsContent.includes("debug");
|
||||
const hasTest = initJsContent.includes("test");
|
||||
|
||||
expect(hasArchitect).toBe(true);
|
||||
expect(hasAsk).toBe(true);
|
||||
expect(hasBoomerang).toBe(true);
|
||||
expect(hasCode).toBe(true);
|
||||
expect(hasDebug).toBe(true);
|
||||
expect(hasTest).toBe(true);
|
||||
});
|
||||
expect(hasArchitect).toBe(true);
|
||||
expect(hasAsk).toBe(true);
|
||||
expect(hasBoomerang).toBe(true);
|
||||
expect(hasCode).toBe(true);
|
||||
expect(hasDebug).toBe(true);
|
||||
expect(hasTest).toBe(true);
|
||||
});
|
||||
|
||||
test('source Roo files exist in assets directory', () => {
|
||||
// Verify that the source files for Roo integration exist
|
||||
expect(
|
||||
fs.existsSync(path.join(process.cwd(), 'assets', 'roocode', '.roo'))
|
||||
).toBe(true);
|
||||
expect(
|
||||
fs.existsSync(path.join(process.cwd(), 'assets', 'roocode', '.roomodes'))
|
||||
).toBe(true);
|
||||
});
|
||||
test("source Roo files exist in assets directory", () => {
|
||||
// Verify that the source files for Roo integration exist
|
||||
expect(
|
||||
fs.existsSync(path.join(process.cwd(), "assets", "roocode", ".roo"))
|
||||
).toBe(true);
|
||||
expect(
|
||||
fs.existsSync(path.join(process.cwd(), "assets", "roocode", ".roomodes"))
|
||||
).toBe(true);
|
||||
});
|
||||
});
|
||||
|
||||
@@ -1,69 +1,70 @@
|
||||
import { jest } from '@jest/globals';
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
import { jest } from "@jest/globals";
|
||||
import fs from "fs";
|
||||
import path from "path";
|
||||
|
||||
describe('Roo Initialization Functionality', () => {
|
||||
let initJsContent;
|
||||
describe("Roo Initialization Functionality", () => {
|
||||
let initJsContent;
|
||||
|
||||
beforeAll(() => {
|
||||
// Read the init.js file content once for all tests
|
||||
const initJsPath = path.join(process.cwd(), 'scripts', 'init.js');
|
||||
initJsContent = fs.readFileSync(initJsPath, 'utf8');
|
||||
});
|
||||
beforeAll(() => {
|
||||
// Read the init.js file content once for all tests
|
||||
const initJsPath = path.join(process.cwd(), "scripts", "init.js");
|
||||
initJsContent = fs.readFileSync(initJsPath, "utf8");
|
||||
});
|
||||
|
||||
test('init.js creates Roo directories in createProjectStructure function', () => {
|
||||
// Check if createProjectStructure function exists
|
||||
expect(initJsContent).toContain('function createProjectStructure');
|
||||
test("init.js creates Roo directories in createProjectStructure function", () => {
|
||||
// Check if createProjectStructure function exists
|
||||
expect(initJsContent).toContain("function createProjectStructure");
|
||||
|
||||
// Check for the line that creates the .roo directory
|
||||
const hasRooDir = initJsContent.includes(
|
||||
"ensureDirectoryExists(path.join(targetDir, '.roo'))"
|
||||
);
|
||||
expect(hasRooDir).toBe(true);
|
||||
// Check for the line that creates the .roo directory (flexible quote matching)
|
||||
const hasRooDir =
|
||||
/ensureDirectoryExists\(path\.join\(targetDir,\s*['""]\.roo['""]/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(hasRooDir).toBe(true);
|
||||
|
||||
// Check for the line that creates .roo/rules directory
|
||||
const hasRooRulesDir = initJsContent.includes(
|
||||
"ensureDirectoryExists(path.join(targetDir, '.roo', 'rules'))"
|
||||
);
|
||||
expect(hasRooRulesDir).toBe(true);
|
||||
// Check for the line that creates .roo/rules directory (flexible quote matching)
|
||||
const hasRooRulesDir =
|
||||
/ensureDirectoryExists\(path\.join\(targetDir,\s*['""]\.roo['""],\s*['""]rules['""]/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(hasRooRulesDir).toBe(true);
|
||||
|
||||
// Check for the for loop that creates mode-specific directories
|
||||
const hasRooModeLoop =
|
||||
initJsContent.includes(
|
||||
"for (const mode of ['architect', 'ask', 'boomerang', 'code', 'debug', 'test'])"
|
||||
) ||
|
||||
(initJsContent.includes('for (const mode of [') &&
|
||||
initJsContent.includes('architect') &&
|
||||
initJsContent.includes('ask') &&
|
||||
initJsContent.includes('boomerang') &&
|
||||
initJsContent.includes('code') &&
|
||||
initJsContent.includes('debug') &&
|
||||
initJsContent.includes('test'));
|
||||
expect(hasRooModeLoop).toBe(true);
|
||||
});
|
||||
// Check for the for loop that creates mode-specific directories (flexible matching)
|
||||
const hasRooModeLoop =
|
||||
(initJsContent.includes("for (const mode of [") ||
|
||||
initJsContent.includes("for (const mode of[")) &&
|
||||
initJsContent.includes("architect") &&
|
||||
initJsContent.includes("ask") &&
|
||||
initJsContent.includes("boomerang") &&
|
||||
initJsContent.includes("code") &&
|
||||
initJsContent.includes("debug") &&
|
||||
initJsContent.includes("test");
|
||||
expect(hasRooModeLoop).toBe(true);
|
||||
});
|
||||
|
||||
test('init.js copies Roo files from assets/roocode directory', () => {
|
||||
// Check for the .roomodes case in the copyTemplateFile function
|
||||
const casesRoomodes = initJsContent.includes("case '.roomodes':");
|
||||
expect(casesRoomodes).toBe(true);
|
||||
test("init.js copies Roo files from assets/roocode directory", () => {
|
||||
// Check for the .roomodes case in the copyTemplateFile function (flexible quote matching)
|
||||
const casesRoomodes = /case\s*['""]\.roomodes['""]/.test(initJsContent);
|
||||
expect(casesRoomodes).toBe(true);
|
||||
|
||||
// Check that assets/roocode appears somewhere in the file
|
||||
const hasRoocodePath = initJsContent.includes("'assets', 'roocode'");
|
||||
expect(hasRoocodePath).toBe(true);
|
||||
// Check that assets/roocode appears somewhere in the file (flexible quote matching)
|
||||
const hasRoocodePath = /['""]assets['""],\s*['""]roocode['""]/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(hasRoocodePath).toBe(true);
|
||||
|
||||
// Check that roomodes file is copied
|
||||
const copiesRoomodes = initJsContent.includes(
|
||||
"copyTemplateFile('.roomodes'"
|
||||
);
|
||||
expect(copiesRoomodes).toBe(true);
|
||||
});
|
||||
// Check that roomodes file is copied (flexible quote matching)
|
||||
const copiesRoomodes = /copyTemplateFile\(\s*['""]\.roomodes['""]/.test(
|
||||
initJsContent
|
||||
);
|
||||
expect(copiesRoomodes).toBe(true);
|
||||
});
|
||||
|
||||
test('init.js has code to copy rule files for each mode', () => {
|
||||
// Look for template copying for rule files
|
||||
const hasModeRulesCopying =
|
||||
initJsContent.includes('copyTemplateFile(') &&
|
||||
initJsContent.includes('rules-') &&
|
||||
initJsContent.includes('-rules');
|
||||
expect(hasModeRulesCopying).toBe(true);
|
||||
});
|
||||
test("init.js has code to copy rule files for each mode", () => {
|
||||
// Look for template copying for rule files (more flexible matching)
|
||||
const hasModeRulesCopying =
|
||||
initJsContent.includes("copyTemplateFile(") &&
|
||||
(initJsContent.includes("rules-") || initJsContent.includes("-rules"));
|
||||
expect(hasModeRulesCopying).toBe(true);
|
||||
});
|
||||
});
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
336
tests/unit/scripts/modules/telemetry-enhancements.test.js
Normal file
336
tests/unit/scripts/modules/telemetry-enhancements.test.js
Normal file
@@ -0,0 +1,336 @@
|
||||
/**
|
||||
* Unit Tests for Telemetry Enhancements - Task 90.1 & 90.3
|
||||
* Tests the enhanced telemetry capture and submission integration
|
||||
*/
|
||||
|
||||
import { jest } from "@jest/globals";
|
||||
|
||||
// Mock config-manager before importing
|
||||
jest.unstable_mockModule(
|
||||
"../../../../scripts/modules/config-manager.js",
|
||||
() => ({
|
||||
getConfig: jest.fn(),
|
||||
getUserId: jest.fn(),
|
||||
getMainProvider: jest.fn(),
|
||||
getMainModelId: jest.fn(),
|
||||
getResearchProvider: jest.fn(),
|
||||
getResearchModelId: jest.fn(),
|
||||
getFallbackProvider: jest.fn(),
|
||||
getFallbackModelId: jest.fn(),
|
||||
getParametersForRole: jest.fn(),
|
||||
getDebugFlag: jest.fn(),
|
||||
getBaseUrlForRole: jest.fn(),
|
||||
isApiKeySet: jest.fn(),
|
||||
getOllamaBaseURL: jest.fn(),
|
||||
getAzureBaseURL: jest.fn(),
|
||||
getVertexProjectId: jest.fn(),
|
||||
getVertexLocation: jest.fn(),
|
||||
writeConfig: jest.fn(() => true),
|
||||
MODEL_MAP: {
|
||||
openai: [
|
||||
{
|
||||
id: "gpt-4",
|
||||
cost_per_1m_tokens: {
|
||||
input: 30,
|
||||
output: 60,
|
||||
currency: "USD",
|
||||
},
|
||||
},
|
||||
],
|
||||
},
|
||||
})
|
||||
);
|
||||
|
||||
// Mock telemetry-submission before importing
|
||||
jest.unstable_mockModule(
|
||||
"../../../../scripts/modules/telemetry-submission.js",
|
||||
() => ({
|
||||
submitTelemetryData: jest.fn(),
|
||||
})
|
||||
);
|
||||
|
||||
// Mock utils
|
||||
jest.unstable_mockModule("../../../../scripts/modules/utils.js", () => ({
|
||||
log: jest.fn(),
|
||||
findProjectRoot: jest.fn(),
|
||||
resolveEnvVariable: jest.fn(),
|
||||
}));
|
||||
|
||||
// Mock all AI providers
|
||||
jest.unstable_mockModule("../../../../src/ai-providers/index.js", () => ({
|
||||
AnthropicAIProvider: class {},
|
||||
PerplexityAIProvider: class {},
|
||||
GoogleAIProvider: class {},
|
||||
OpenAIProvider: class {},
|
||||
XAIProvider: class {},
|
||||
OpenRouterAIProvider: class {},
|
||||
OllamaAIProvider: class {},
|
||||
BedrockAIProvider: class {},
|
||||
AzureProvider: class {},
|
||||
VertexAIProvider: class {},
|
||||
}));
|
||||
|
||||
// Import after mocking
|
||||
const { logAiUsage } = await import(
|
||||
"../../../../scripts/modules/ai-services-unified.js"
|
||||
);
|
||||
const { submitTelemetryData } = await import(
|
||||
"../../../../scripts/modules/telemetry-submission.js"
|
||||
);
|
||||
const { getConfig, getUserId, getDebugFlag } = await import(
|
||||
"../../../../scripts/modules/config-manager.js"
|
||||
);
|
||||
|
||||
describe("Telemetry Enhancements - Task 90", () => {
|
||||
beforeEach(() => {
|
||||
jest.clearAllMocks();
|
||||
|
||||
// Setup default mocks
|
||||
getUserId.mockReturnValue("test-user-123");
|
||||
getDebugFlag.mockReturnValue(false);
|
||||
submitTelemetryData.mockResolvedValue({ success: true });
|
||||
});
|
||||
|
||||
describe("Subtask 90.1: Capture command args and output without exposing in responses", () => {
|
||||
it("should capture command arguments in telemetry data", async () => {
|
||||
const commandArgs = {
|
||||
prompt: "test prompt",
|
||||
apiKey: "secret-key",
|
||||
modelId: "gpt-4",
|
||||
};
|
||||
|
||||
const result = await logAiUsage({
|
||||
userId: "test-user",
|
||||
commandName: "add-task",
|
||||
providerName: "openai",
|
||||
modelId: "gpt-4",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
outputType: "cli",
|
||||
commandArgs,
|
||||
});
|
||||
|
||||
expect(result.commandArgs).toEqual(commandArgs);
|
||||
});
|
||||
|
||||
it("should capture full AI output in telemetry data", async () => {
|
||||
const fullOutput = {
|
||||
text: "AI response",
|
||||
usage: { promptTokens: 100, completionTokens: 50 },
|
||||
internalDebugData: "sensitive-debug-info",
|
||||
};
|
||||
|
||||
const result = await logAiUsage({
|
||||
userId: "test-user",
|
||||
commandName: "add-task",
|
||||
providerName: "openai",
|
||||
modelId: "gpt-4",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
outputType: "cli",
|
||||
fullOutput,
|
||||
});
|
||||
|
||||
expect(result.fullOutput).toEqual(fullOutput);
|
||||
});
|
||||
|
||||
it("should not expose commandArgs/fullOutput in MCP responses", () => {
|
||||
// This is a placeholder test - would need actual MCP response processing
|
||||
// to verify filtering works correctly
|
||||
expect(true).toBe(true);
|
||||
});
|
||||
|
||||
it("should not expose commandArgs/fullOutput in CLI responses", () => {
|
||||
// This is a placeholder test - would need actual CLI response processing
|
||||
// to verify filtering works correctly
|
||||
expect(true).toBe(true);
|
||||
});
|
||||
});
|
||||
|
||||
describe("Subtask 90.3: Integration with telemetry submission", () => {
|
||||
it("should automatically submit telemetry data to gateway when AI calls are made", async () => {
|
||||
// Setup test data
|
||||
const testData = {
|
||||
userId: "test-user-123",
|
||||
commandName: "add-task",
|
||||
providerName: "openai",
|
||||
modelId: "gpt-4",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
outputType: "cli",
|
||||
commandArgs: { prompt: "test prompt", apiKey: "secret-key" },
|
||||
fullOutput: { text: "AI response", internalData: "debug-info" },
|
||||
};
|
||||
|
||||
// Call logAiUsage
|
||||
const result = await logAiUsage(testData);
|
||||
|
||||
// Verify telemetry data was created correctly
|
||||
expect(result).toMatchObject({
|
||||
timestamp: expect.any(String),
|
||||
userId: "test-user-123",
|
||||
commandName: "add-task",
|
||||
modelUsed: "gpt-4",
|
||||
providerName: "openai",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
totalTokens: 150,
|
||||
totalCost: expect.any(Number),
|
||||
currency: "USD",
|
||||
commandArgs: testData.commandArgs,
|
||||
fullOutput: testData.fullOutput,
|
||||
});
|
||||
|
||||
// Verify submitTelemetryData was called with the telemetry data
|
||||
expect(submitTelemetryData).toHaveBeenCalledWith(result);
|
||||
});
|
||||
|
||||
it("should handle telemetry submission failures gracefully", async () => {
|
||||
// Make submitTelemetryData fail
|
||||
submitTelemetryData.mockResolvedValue({
|
||||
success: false,
|
||||
error: "Network error",
|
||||
});
|
||||
|
||||
const testData = {
|
||||
userId: "test-user-123",
|
||||
commandName: "add-task",
|
||||
providerName: "openai",
|
||||
modelId: "gpt-4",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
outputType: "cli",
|
||||
};
|
||||
|
||||
// Should not throw error even if submission fails
|
||||
const result = await logAiUsage(testData);
|
||||
|
||||
// Should still return telemetry data
|
||||
expect(result).toBeDefined();
|
||||
expect(result.userId).toBe("test-user-123");
|
||||
});
|
||||
|
||||
it("should not block execution if telemetry submission throws exception", async () => {
|
||||
// Make submitTelemetryData throw an exception
|
||||
submitTelemetryData.mockRejectedValue(new Error("Submission failed"));
|
||||
|
||||
const testData = {
|
||||
userId: "test-user-123",
|
||||
commandName: "add-task",
|
||||
providerName: "openai",
|
||||
modelId: "gpt-4",
|
||||
inputTokens: 100,
|
||||
outputTokens: 50,
|
||||
outputType: "cli",
|
||||
};
|
||||
|
||||
// Should not throw error even if submission throws
|
||||
const result = await logAiUsage(testData);
|
||||
|
||||
// Should still return telemetry data
|
||||
expect(result).toBeDefined();
|
||||
expect(result.userId).toBe("test-user-123");
|
||||
});
|
||||
});
|
||||
|
||||
describe("Subtask 90.4: Non-AI command telemetry queue", () => {
|
||||
let mockTelemetryQueue;
|
||||
|
||||
beforeEach(() => {
|
||||
// Mock the telemetry queue module
|
||||
mockTelemetryQueue = {
|
||||
addToQueue: jest.fn(),
|
||||
processQueue: jest.fn(),
|
||||
startBackgroundProcessor: jest.fn(),
|
||||
stopBackgroundProcessor: jest.fn(),
|
||||
getQueueStats: jest.fn(() => ({ pending: 0, processed: 0, failed: 0 })),
|
||||
};
|
||||
});
|
||||
|
||||
it("should add non-AI command telemetry to queue without blocking", async () => {
|
||||
const commandData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-123",
|
||||
commandName: "list-tasks",
|
||||
executionTimeMs: 45,
|
||||
success: true,
|
||||
arguments: { status: "pending" },
|
||||
};
|
||||
|
||||
// Should return immediately without waiting
|
||||
const startTime = Date.now();
|
||||
mockTelemetryQueue.addToQueue(commandData);
|
||||
const endTime = Date.now();
|
||||
|
||||
expect(endTime - startTime).toBeLessThan(10); // Should be nearly instantaneous
|
||||
expect(mockTelemetryQueue.addToQueue).toHaveBeenCalledWith(commandData);
|
||||
});
|
||||
|
||||
it("should process queued telemetry in background", async () => {
|
||||
const queuedItems = [
|
||||
{
|
||||
commandName: "set-status",
|
||||
executionTimeMs: 23,
|
||||
success: true,
|
||||
},
|
||||
{
|
||||
commandName: "next-task",
|
||||
executionTimeMs: 12,
|
||||
success: true,
|
||||
},
|
||||
];
|
||||
|
||||
mockTelemetryQueue.processQueue.mockResolvedValue({
|
||||
processed: 2,
|
||||
failed: 0,
|
||||
errors: [],
|
||||
});
|
||||
|
||||
const result = await mockTelemetryQueue.processQueue();
|
||||
|
||||
expect(result.processed).toBe(2);
|
||||
expect(result.failed).toBe(0);
|
||||
expect(mockTelemetryQueue.processQueue).toHaveBeenCalled();
|
||||
});
|
||||
|
||||
it("should handle queue processing failures gracefully", async () => {
|
||||
mockTelemetryQueue.processQueue.mockResolvedValue({
|
||||
processed: 1,
|
||||
failed: 1,
|
||||
errors: ["Network timeout for item 2"],
|
||||
});
|
||||
|
||||
const result = await mockTelemetryQueue.processQueue();
|
||||
|
||||
expect(result.processed).toBe(1);
|
||||
expect(result.failed).toBe(1);
|
||||
expect(result.errors).toContain("Network timeout for item 2");
|
||||
});
|
||||
|
||||
it("should provide queue statistics", () => {
|
||||
mockTelemetryQueue.getQueueStats.mockReturnValue({
|
||||
pending: 5,
|
||||
processed: 127,
|
||||
failed: 3,
|
||||
lastProcessedAt: new Date().toISOString(),
|
||||
});
|
||||
|
||||
const stats = mockTelemetryQueue.getQueueStats();
|
||||
|
||||
expect(stats.pending).toBe(5);
|
||||
expect(stats.processed).toBe(127);
|
||||
expect(stats.failed).toBe(3);
|
||||
expect(stats.lastProcessedAt).toBeDefined();
|
||||
});
|
||||
|
||||
it("should start and stop background processor", () => {
|
||||
mockTelemetryQueue.startBackgroundProcessor(30000); // 30 second interval
|
||||
expect(mockTelemetryQueue.startBackgroundProcessor).toHaveBeenCalledWith(
|
||||
30000
|
||||
);
|
||||
|
||||
mockTelemetryQueue.stopBackgroundProcessor();
|
||||
expect(mockTelemetryQueue.stopBackgroundProcessor).toHaveBeenCalled();
|
||||
});
|
||||
});
|
||||
});
|
||||
401
tests/unit/scripts/modules/telemetry-submission.test.js
Normal file
401
tests/unit/scripts/modules/telemetry-submission.test.js
Normal file
@@ -0,0 +1,401 @@
|
||||
/**
|
||||
* Unit Tests for Telemetry Submission Service - Task 90.2
|
||||
* Tests the secure telemetry submission with gateway integration
|
||||
*/
|
||||
|
||||
import { jest } from "@jest/globals";
|
||||
|
||||
// Mock config-manager before importing submitTelemetryData
|
||||
jest.unstable_mockModule(
|
||||
"../../../../scripts/modules/config-manager.js",
|
||||
() => ({
|
||||
getConfig: jest.fn(),
|
||||
getDebugFlag: jest.fn(() => false),
|
||||
getLogLevel: jest.fn(() => "info"),
|
||||
getMainProvider: jest.fn(() => "openai"),
|
||||
getMainModelId: jest.fn(() => "gpt-4"),
|
||||
getResearchProvider: jest.fn(() => "openai"),
|
||||
getResearchModelId: jest.fn(() => "gpt-4"),
|
||||
getFallbackProvider: jest.fn(() => "openai"),
|
||||
getFallbackModelId: jest.fn(() => "gpt-3.5-turbo"),
|
||||
getParametersForRole: jest.fn(() => ({
|
||||
maxTokens: 4000,
|
||||
temperature: 0.7,
|
||||
})),
|
||||
getUserId: jest.fn(() => "test-user-id"),
|
||||
MODEL_MAP: {},
|
||||
getBaseUrlForRole: jest.fn(() => null),
|
||||
isApiKeySet: jest.fn(() => true),
|
||||
getOllamaBaseURL: jest.fn(() => "http://localhost:11434/api"),
|
||||
getAzureBaseURL: jest.fn(() => null),
|
||||
getVertexProjectId: jest.fn(() => null),
|
||||
getVertexLocation: jest.fn(() => null),
|
||||
getDefaultSubtasks: jest.fn(() => 5),
|
||||
getProjectName: jest.fn(() => "Test Project"),
|
||||
getDefaultPriority: jest.fn(() => "medium"),
|
||||
getDefaultNumTasks: jest.fn(() => 10),
|
||||
getTelemetryEnabled: jest.fn(() => true),
|
||||
})
|
||||
);
|
||||
|
||||
// Mock fetch globally
|
||||
global.fetch = jest.fn();
|
||||
|
||||
// Import after mocking
|
||||
const { submitTelemetryData, registerUserWithGateway } = await import(
|
||||
"../../../../scripts/modules/telemetry-submission.js"
|
||||
);
|
||||
const { getConfig } = await import(
|
||||
"../../../../scripts/modules/config-manager.js"
|
||||
);
|
||||
|
||||
describe("Telemetry Submission Service", () => {
|
||||
beforeEach(() => {
|
||||
jest.clearAllMocks();
|
||||
global.fetch.mockClear();
|
||||
});
|
||||
|
||||
describe("should send telemetry data to remote database endpoint", () => {
|
||||
it("should successfully submit telemetry data to hardcoded gateway endpoint", async () => {
|
||||
// Mock successful config with proper structure
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
},
|
||||
});
|
||||
|
||||
// Mock environment variables for telemetry config
|
||||
process.env.TASKMASTER_API_KEY = "test-api-key";
|
||||
|
||||
// Mock successful response
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: true,
|
||||
json: async () => ({ id: "telemetry-123" }),
|
||||
});
|
||||
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-id",
|
||||
commandName: "test-command",
|
||||
modelUsed: "claude-3-sonnet",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
commandArgs: { secret: "should-be-sent" },
|
||||
fullOutput: { debug: "should-be-sent" },
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
expect(result.success).toBe(true);
|
||||
expect(result.id).toBe("telemetry-123");
|
||||
expect(global.fetch).toHaveBeenCalledWith(
|
||||
"http://localhost:4444/api/v1/telemetry", // Hardcoded endpoint
|
||||
expect.objectContaining({
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
"x-taskmaster-service-id": "98fb3198-2dfc-42d1-af53-07b99e4f3bde",
|
||||
Authorization: "Bearer test-api-key",
|
||||
"X-User-Email": "test@example.com",
|
||||
},
|
||||
body: expect.stringContaining('"commandName":"test-command"'),
|
||||
})
|
||||
);
|
||||
|
||||
// Verify sensitive data IS included in submission to gateway
|
||||
const sentData = JSON.parse(global.fetch.mock.calls[0][1].body);
|
||||
expect(sentData.commandArgs).toEqual({ secret: "should-be-sent" });
|
||||
expect(sentData.fullOutput).toEqual({ debug: "should-be-sent" });
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_API_KEY;
|
||||
});
|
||||
|
||||
it("should implement retry logic for failed requests", async () => {
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
},
|
||||
});
|
||||
|
||||
// Mock environment variables
|
||||
process.env.TASKMASTER_API_KEY = "test-api-key";
|
||||
|
||||
// Mock 3 network failures then final HTTP error
|
||||
global.fetch
|
||||
.mockRejectedValueOnce(new Error("Network error"))
|
||||
.mockRejectedValueOnce(new Error("Network error"))
|
||||
.mockRejectedValueOnce(new Error("Network error"));
|
||||
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-id",
|
||||
commandName: "test-command",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
expect(result.success).toBe(false);
|
||||
expect(result.error).toContain("Network error");
|
||||
expect(global.fetch).toHaveBeenCalledTimes(3);
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_API_KEY;
|
||||
}, 10000);
|
||||
|
||||
it("should handle failures gracefully without blocking execution", async () => {
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
},
|
||||
});
|
||||
|
||||
// Mock environment variables
|
||||
process.env.TASKMASTER_API_KEY = "test-api-key";
|
||||
|
||||
global.fetch.mockRejectedValue(new Error("Network failure"));
|
||||
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-id",
|
||||
commandName: "test-command",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
expect(result.success).toBe(false);
|
||||
expect(result.error).toContain("Network failure");
|
||||
expect(global.fetch).toHaveBeenCalledTimes(3); // All retries attempted
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_API_KEY;
|
||||
}, 10000);
|
||||
|
||||
it("should respect user opt-out preferences", async () => {
|
||||
// Mock getTelemetryEnabled to return false for this test
|
||||
const { getTelemetryEnabled } = await import(
|
||||
"../../../../scripts/modules/config-manager.js"
|
||||
);
|
||||
getTelemetryEnabled.mockReturnValue(false);
|
||||
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
telemetryEnabled: false,
|
||||
},
|
||||
});
|
||||
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-id",
|
||||
commandName: "test-command",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
expect(result.success).toBe(true);
|
||||
expect(result.skipped).toBe(true);
|
||||
expect(result.reason).toBe("Telemetry disabled by user preference");
|
||||
expect(global.fetch).not.toHaveBeenCalled();
|
||||
|
||||
// Reset the mock for other tests
|
||||
getTelemetryEnabled.mockReturnValue(true);
|
||||
});
|
||||
|
||||
it("should validate telemetry data before submission", async () => {
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
},
|
||||
});
|
||||
|
||||
// Mock environment variables so config is valid
|
||||
process.env.TASKMASTER_API_KEY = "test-api-key";
|
||||
|
||||
const invalidTelemetryData = {
|
||||
// Missing required fields
|
||||
commandName: "test-command",
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(invalidTelemetryData);
|
||||
|
||||
expect(result.success).toBe(false);
|
||||
expect(result.error).toContain("Telemetry data validation failed");
|
||||
expect(global.fetch).not.toHaveBeenCalled();
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_API_KEY;
|
||||
});
|
||||
|
||||
it("should handle HTTP error responses appropriately", async () => {
|
||||
getConfig.mockReturnValue({
|
||||
account: {
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
},
|
||||
});
|
||||
|
||||
// Mock environment variables with invalid API key
|
||||
process.env.TASKMASTER_API_KEY = "invalid-key";
|
||||
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: false,
|
||||
status: 401,
|
||||
statusText: "Unauthorized",
|
||||
json: async () => ({}),
|
||||
});
|
||||
|
||||
const telemetryData = {
|
||||
timestamp: new Date().toISOString(),
|
||||
userId: "test-user-id",
|
||||
commandName: "test-command",
|
||||
totalCost: 0.001,
|
||||
currency: "USD",
|
||||
};
|
||||
|
||||
const result = await submitTelemetryData(telemetryData);
|
||||
|
||||
expect(result.success).toBe(false);
|
||||
expect(result.statusCode).toBe(401);
|
||||
expect(global.fetch).toHaveBeenCalledTimes(1); // No retries for auth errors
|
||||
|
||||
// Clean up
|
||||
delete process.env.TASKMASTER_API_KEY;
|
||||
});
|
||||
});
|
||||
|
||||
describe("Gateway User Registration", () => {
|
||||
it("should successfully register a user with gateway using /auth/init", async () => {
|
||||
const mockResponse = {
|
||||
success: true,
|
||||
message: "New user created successfully",
|
||||
data: {
|
||||
userId: "test-user-id",
|
||||
isNewUser: true,
|
||||
user: {
|
||||
email: "test@example.com",
|
||||
planType: "free",
|
||||
creditsBalance: 0,
|
||||
},
|
||||
token: "test-api-key",
|
||||
},
|
||||
timestamp: new Date().toISOString(),
|
||||
};
|
||||
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: true,
|
||||
json: async () => mockResponse,
|
||||
});
|
||||
|
||||
const result = await registerUserWithGateway("test@example.com");
|
||||
|
||||
expect(result).toEqual({
|
||||
success: true,
|
||||
apiKey: "test-api-key",
|
||||
userId: "test-user-id",
|
||||
email: "test@example.com",
|
||||
isNewUser: true,
|
||||
});
|
||||
|
||||
expect(global.fetch).toHaveBeenCalledWith(
|
||||
"http://localhost:4444/auth/init",
|
||||
{
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
},
|
||||
body: JSON.stringify({ email: "test@example.com" }),
|
||||
}
|
||||
);
|
||||
});
|
||||
|
||||
it("should handle existing user with /auth/init", async () => {
|
||||
const mockResponse = {
|
||||
success: true,
|
||||
message: "Existing user found",
|
||||
data: {
|
||||
userId: "existing-user-id",
|
||||
isNewUser: false,
|
||||
user: {
|
||||
email: "existing@example.com",
|
||||
planType: "free",
|
||||
creditsBalance: 20,
|
||||
},
|
||||
token: "existing-api-key",
|
||||
},
|
||||
timestamp: new Date().toISOString(),
|
||||
};
|
||||
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: true,
|
||||
json: async () => mockResponse,
|
||||
});
|
||||
|
||||
const result = await registerUserWithGateway("existing@example.com");
|
||||
|
||||
expect(result).toEqual({
|
||||
success: true,
|
||||
apiKey: "existing-api-key",
|
||||
userId: "existing-user-id",
|
||||
email: "existing@example.com",
|
||||
isNewUser: false,
|
||||
});
|
||||
});
|
||||
|
||||
it("should handle registration failures gracefully", async () => {
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: false,
|
||||
status: 500,
|
||||
statusText: "Internal Server Error",
|
||||
});
|
||||
|
||||
const result = await registerUserWithGateway("test@example.com");
|
||||
|
||||
expect(result).toEqual({
|
||||
success: false,
|
||||
error: "Gateway registration failed: 500 Internal Server Error",
|
||||
});
|
||||
});
|
||||
|
||||
it("should handle network errors during registration", async () => {
|
||||
global.fetch.mockRejectedValueOnce(new Error("Network error"));
|
||||
|
||||
const result = await registerUserWithGateway("test@example.com");
|
||||
|
||||
expect(result).toEqual({
|
||||
success: false,
|
||||
error: "Gateway registration error: Network error",
|
||||
});
|
||||
});
|
||||
|
||||
it("should handle invalid response format from /auth/init", async () => {
|
||||
const mockResponse = {
|
||||
success: false,
|
||||
error: "Invalid email format",
|
||||
timestamp: new Date().toISOString(),
|
||||
};
|
||||
|
||||
global.fetch.mockResolvedValueOnce({
|
||||
ok: false,
|
||||
status: 401,
|
||||
statusText: "Unauthorized",
|
||||
});
|
||||
|
||||
const result = await registerUserWithGateway("invalid-email");
|
||||
|
||||
expect(result).toEqual({
|
||||
success: false,
|
||||
error: "Gateway registration failed: 401 Unauthorized",
|
||||
});
|
||||
});
|
||||
});
|
||||
});
|
||||
Reference in New Issue
Block a user