Compare commits
33 Commits
add-comple
...
fix/ollama
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
db6fdebdcd | ||
|
|
60b8e97a1c | ||
|
|
3a6d6dd671 | ||
|
|
f4a83ec047 | ||
|
|
0699f64299 | ||
|
|
60b8f5faa3 | ||
|
|
cd6e42249e | ||
|
|
fcd80623b6 | ||
|
|
026815353f | ||
|
|
8a3b611fc2 | ||
|
|
6ba42b53dc | ||
|
|
3e304232ab | ||
|
|
70fa5b0031 | ||
|
|
314c0de8c4 | ||
|
|
58b417a8ce | ||
|
|
bc19bc7927 | ||
|
|
da636f6681 | ||
|
|
ca5ec03cd8 | ||
|
|
79a41543d5 | ||
|
|
9f4bac8d6a | ||
|
|
e53d5e1577 | ||
|
|
59230c4d91 | ||
|
|
04b6a3cb21 | ||
|
|
37178ff1b9 | ||
|
|
bbc8b9cc1f | ||
|
|
c955431753 | ||
|
|
21c3cb8cda | ||
|
|
ab84afd036 | ||
|
|
f89d2aacc0 | ||
|
|
0288311965 | ||
|
|
8ae772086d | ||
|
|
2b3ae8bf89 | ||
|
|
245c3cb398 |
11
.changeset/free-bikes-smile.md
Normal file
11
.changeset/free-bikes-smile.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
'task-master-ai': minor
|
||||
---
|
||||
|
||||
Add Ollama as a supported AI provider.
|
||||
|
||||
- You can now add it by running `task-master models --setup` and selecting it.
|
||||
- Ollama is a local model provider, so no API key is required.
|
||||
- Ollama models are available at `http://localhost:11434/api` by default.
|
||||
- You can change the default URL by setting the `OLLAMA_BASE_URL` environment variable or by adding a `baseUrl` property to the `ollama` model role in `.taskmasterconfig`.
|
||||
- If you want to use a custom API key, you can set it in the `OLLAMA_API_KEY` environment variable.
|
||||
5
.changeset/nice-lies-cover.md
Normal file
5
.changeset/nice-lies-cover.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'task-master-ai': patch
|
||||
---
|
||||
|
||||
Adds costs information to AI commands using input/output tokens and model costs.
|
||||
@@ -2,11 +2,25 @@
|
||||
"mode": "exit",
|
||||
"tag": "rc",
|
||||
"initialVersions": {
|
||||
"task-master-ai": "0.13.2"
|
||||
"task-master-ai": "0.14.0-rc.0"
|
||||
},
|
||||
"changesets": [
|
||||
"beige-doodles-type",
|
||||
"floppy-plants-marry",
|
||||
"forty-plums-stay",
|
||||
"free-bikes-smile",
|
||||
"many-wasps-sell",
|
||||
"nice-lies-cover",
|
||||
"red-oranges-attend",
|
||||
"red-suns-wash"
|
||||
"red-suns-wash",
|
||||
"sharp-dingos-melt",
|
||||
"six-cloths-happen",
|
||||
"slow-singers-swim",
|
||||
"small-toys-fly",
|
||||
"social-masks-fold",
|
||||
"soft-zoos-flow",
|
||||
"ten-ways-mate",
|
||||
"tricky-wombats-spend",
|
||||
"wide-eyes-relax"
|
||||
]
|
||||
}
|
||||
|
||||
7
.changeset/small-toys-fly.md
Normal file
7
.changeset/small-toys-fly.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
'task-master-ai': patch
|
||||
---
|
||||
|
||||
Small fixes
|
||||
- `next` command no longer incorrectly suggests that subtasks be broken down into subtasks in the CLI
|
||||
- fixes the `append` flag so it properly works in the CLI
|
||||
5
.changeset/social-masks-fold.md
Normal file
5
.changeset/social-masks-fold.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
'task-master-ai': minor
|
||||
---
|
||||
|
||||
Display task complexity scores in task lists, next task, and task details views.
|
||||
@@ -25,6 +25,7 @@ This document outlines the architecture and usage patterns for interacting with
|
||||
* Implements **retry logic** for specific API errors (`_attemptProviderCallWithRetries`).
|
||||
* Resolves API keys automatically via `_resolveApiKey` (using `resolveEnvVariable`).
|
||||
* Maps requests to the correct provider implementation (in `src/ai-providers/`) via `PROVIDER_FUNCTIONS`.
|
||||
* Returns a structured object containing the primary AI result (`mainResult`) and telemetry data (`telemetryData`). See [`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc) for details on how this telemetry data is propagated and handled.
|
||||
|
||||
* **Provider Implementations (`src/ai-providers/*.js`):**
|
||||
* Contain provider-specific wrappers around Vercel AI SDK functions (`generateText`, `generateObject`).
|
||||
|
||||
@@ -42,6 +42,7 @@ alwaysApply: false
|
||||
- Resolves API keys (from `.env` or `session.env`).
|
||||
- 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**
|
||||
- **Purpose**: Provider-specific wrappers for Vercel AI SDK functions.
|
||||
|
||||
@@ -3,7 +3,6 @@ description: Glossary of other Cursor rules
|
||||
globs: **/*
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Glossary of Task Master Cursor Rules
|
||||
|
||||
This file provides a quick reference to the purpose of each rule file located in the `.cursor/rules` directory.
|
||||
@@ -23,4 +22,5 @@ This file provides a quick reference to the purpose of each rule file located in
|
||||
- **[`tests.mdc`](mdc:.cursor/rules/tests.mdc)**: Guidelines for implementing and maintaining tests for Task Master CLI.
|
||||
- **[`ui.mdc`](mdc:.cursor/rules/ui.mdc)**: Guidelines for implementing and maintaining user interface components.
|
||||
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions.
|
||||
- **[`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc)**: Guidelines for integrating AI usage telemetry across Task Master.
|
||||
|
||||
|
||||
@@ -522,3 +522,8 @@ Follow these steps to add MCP support for an existing Task Master command (see [
|
||||
// Add more functions as implemented
|
||||
};
|
||||
```
|
||||
|
||||
## Telemetry Integration
|
||||
|
||||
- Direct functions calling core logic that involves AI should receive and pass through `telemetryData` within their successful `data` payload. See [`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc) for the standard pattern.
|
||||
- MCP tools use `handleApiResult`, which ensures the `data` object (potentially including `telemetryData`) from the direct function is correctly included in the final response.
|
||||
|
||||
@@ -3,7 +3,6 @@ description: Guidelines for integrating new features into the Task Master CLI
|
||||
globs: scripts/modules/*.js
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Task Master Feature Integration Guidelines
|
||||
|
||||
## Feature Placement Decision Process
|
||||
@@ -196,6 +195,8 @@ The standard pattern for adding a feature follows this workflow:
|
||||
- ✅ **DO**: If an MCP tool fails with vague errors (e.g., JSON parsing issues like `Unexpected token ... is not valid JSON`), **try running the equivalent CLI command directly in the terminal** (e.g., `task-master expand --all`). CLI output often provides much more specific error messages (like missing function definitions or stack traces from the core logic) that pinpoint the root cause.
|
||||
- ❌ **DON'T**: Rely solely on MCP logs if the error is unclear; use the CLI as a complementary debugging tool for core logic issues.
|
||||
|
||||
- **Telemetry Integration**: Ensure AI calls correctly handle and propagate `telemetryData` as described in [`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc).
|
||||
|
||||
```javascript
|
||||
// 1. CORE LOGIC: Add function to appropriate module (example in task-manager.js)
|
||||
/**
|
||||
|
||||
228
.cursor/rules/telemetry.mdc
Normal file
228
.cursor/rules/telemetry.mdc
Normal file
@@ -0,0 +1,228 @@
|
||||
---
|
||||
description: Guidelines for integrating AI usage telemetry across Task Master.
|
||||
globs: scripts/modules/**/*.js,mcp-server/src/**/*.js
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# AI Usage Telemetry Integration
|
||||
|
||||
This document outlines the standard pattern for capturing, propagating, and handling AI usage telemetry data (cost, tokens, model, etc.) across the Task Master stack. This ensures consistent telemetry for both CLI and MCP interactions.
|
||||
|
||||
## Overview
|
||||
|
||||
Telemetry data is generated within the unified AI service layer ([`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js)) and then passed upwards through the calling functions.
|
||||
|
||||
- **Data Source**: [`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js) (specifically its `generateTextService`, `generateObjectService`, etc.) returns an object like `{ mainResult: AI_CALL_OUTPUT, telemetryData: TELEMETRY_OBJECT }`.
|
||||
- **`telemetryData` Object Structure**:
|
||||
```json
|
||||
{
|
||||
"timestamp": "ISO_STRING_DATE",
|
||||
"userId": "USER_ID_FROM_CONFIG",
|
||||
"commandName": "invoking_command_or_tool_name",
|
||||
"modelUsed": "ai_model_id",
|
||||
"providerName": "ai_provider_name",
|
||||
"inputTokens": NUMBER,
|
||||
"outputTokens": NUMBER,
|
||||
"totalTokens": NUMBER,
|
||||
"totalCost": NUMBER, // e.g., 0.012414
|
||||
"currency": "USD" // e.g., "USD"
|
||||
}
|
||||
```
|
||||
|
||||
## Integration Pattern by Layer
|
||||
|
||||
The key principle is that each layer receives telemetry data from the layer below it (if applicable) and passes it to the layer above it, or handles it for display in the case of the CLI.
|
||||
|
||||
### 1. Core Logic Functions (e.g., in `scripts/modules/task-manager/`)
|
||||
|
||||
Functions in this layer that invoke AI services are responsible for handling the `telemetryData` they receive from [`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js).
|
||||
|
||||
- **Actions**:
|
||||
1. Call the appropriate AI service function (e.g., `generateObjectService`).
|
||||
- Pass `commandName` (e.g., `add-task`, `expand-task`) and `outputType` (e.g., `cli` or `mcp`) in the `params` object to the AI service. The `outputType` can be derived from context (e.g., presence of `mcpLog`).
|
||||
2. The AI service returns an object, e.g., `aiServiceResponse = { mainResult: {/*AI output*/}, telemetryData: {/*telemetry data*/} }`.
|
||||
3. Extract `aiServiceResponse.mainResult` for the core processing.
|
||||
4. **Must return an object that includes `aiServiceResponse.telemetryData`**.
|
||||
Example: `return { operationSpecificData: /*...*/, telemetryData: aiServiceResponse.telemetryData };`
|
||||
|
||||
- **CLI Output Handling (If Applicable)**:
|
||||
- If the core function also handles CLI output (e.g., it has an `outputFormat` parameter that can be `'text'` or `'cli'`):
|
||||
1. Check if `outputFormat === 'text'` (or `'cli'`).
|
||||
2. If so, and if `aiServiceResponse.telemetryData` is available, call `displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli')` from [`scripts/modules/ui.js`](mdc:scripts/modules/ui.js).
|
||||
- This ensures telemetry is displayed directly to CLI users after the main command output.
|
||||
|
||||
- **Example Snippet (Core Logic in `scripts/modules/task-manager/someAiAction.js`)**:
|
||||
```javascript
|
||||
import { generateObjectService } from '../ai-services-unified.js';
|
||||
import { displayAiUsageSummary } from '../ui.js';
|
||||
|
||||
async function performAiRelatedAction(params, context, outputFormat = 'text') {
|
||||
const { commandNameFromContext, /* other context vars */ } = context;
|
||||
let aiServiceResponse = null;
|
||||
|
||||
try {
|
||||
aiServiceResponse = await generateObjectService({
|
||||
// ... other parameters for AI service ...
|
||||
commandName: commandNameFromContext || 'default-action-name',
|
||||
outputType: context.mcpLog ? 'mcp' : 'cli' // Derive outputType
|
||||
});
|
||||
|
||||
const usefulAiOutput = aiServiceResponse.mainResult.object;
|
||||
// ... do work with usefulAiOutput ...
|
||||
|
||||
if (outputFormat === 'text' && aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
|
||||
return {
|
||||
actionData: /* results of processing */,
|
||||
telemetryData: aiServiceResponse.telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
// ... handle error ...
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Direct Function Wrappers (in `mcp-server/src/core/direct-functions/`)
|
||||
|
||||
These functions adapt core logic for the MCP server, ensuring structured responses.
|
||||
|
||||
- **Actions**:
|
||||
1. Call the corresponding core logic function.
|
||||
- Pass necessary context (e.g., `session`, `mcpLog`, `projectRoot`).
|
||||
- Provide the `commandName` (typically derived from the MCP tool name) and `outputType: 'mcp'` in the context object passed to the core function.
|
||||
- If the core function supports an `outputFormat` parameter, pass `'json'` to suppress CLI-specific UI.
|
||||
2. The core logic function returns an object (e.g., `coreResult = { actionData: ..., telemetryData: ... }`).
|
||||
3. Include `coreResult.telemetryData` as a field within the `data` object of the successful response returned by the direct function.
|
||||
|
||||
- **Example Snippet (Direct Function `someAiActionDirect.js`)**:
|
||||
```javascript
|
||||
import { performAiRelatedAction } from '../../../../scripts/modules/task-manager/someAiAction.js'; // Core function
|
||||
import { createLogWrapper } from '../../tools/utils.js'; // MCP Log wrapper
|
||||
|
||||
export async function someAiActionDirect(args, log, context = {}) {
|
||||
const { session } = context;
|
||||
// ... prepare arguments for core function from args, including args.projectRoot ...
|
||||
|
||||
try {
|
||||
const coreResult = await performAiRelatedAction(
|
||||
{ /* parameters for core function */ },
|
||||
{ // Context for core function
|
||||
session,
|
||||
mcpLog: createLogWrapper(log),
|
||||
projectRoot: args.projectRoot,
|
||||
commandNameFromContext: 'mcp_tool_some_ai_action', // Example command name
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json' // Request 'json' output format from core function
|
||||
);
|
||||
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
operationSpecificData: coreResult.actionData,
|
||||
telemetryData: coreResult.telemetryData // Pass telemetry through
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
// ... error handling, return { success: false, error: ... } ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. MCP Tools (in `mcp-server/src/tools/`)
|
||||
|
||||
These are the exposed endpoints for MCP clients.
|
||||
|
||||
- **Actions**:
|
||||
1. Call the corresponding direct function wrapper.
|
||||
2. The direct function returns an object structured like `{ success: true, data: { operationSpecificData: ..., telemetryData: ... } }` (or an error object).
|
||||
3. Pass this entire result object to `handleApiResult(result, log)` from [`mcp-server/src/tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
|
||||
4. `handleApiResult` ensures that the `data` field from the direct function's response (which correctly includes `telemetryData`) is part of the final MCP response.
|
||||
|
||||
- **Example Snippet (MCP Tool `some_ai_action.js`)**:
|
||||
```javascript
|
||||
import { someAiActionDirect } from '../core/task-master-core.js';
|
||||
import { handleApiResult, withNormalizedProjectRoot } from './utils.js';
|
||||
// ... zod for parameters ...
|
||||
|
||||
export function registerSomeAiActionTool(server) {
|
||||
server.addTool({
|
||||
name: "some_ai_action",
|
||||
// ... description, parameters ...
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
try {
|
||||
const resultFromDirectFunction = await someAiActionDirect(
|
||||
{ /* args including projectRoot */ },
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
return handleApiResult(resultFromDirectFunction, log); // This passes the nested telemetryData through
|
||||
} catch (error) {
|
||||
// ... error handling ...
|
||||
}
|
||||
})
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### 4. CLI Commands (`scripts/modules/commands.js`)
|
||||
|
||||
These define the command-line interface.
|
||||
|
||||
- **Actions**:
|
||||
1. Call the appropriate core logic function.
|
||||
2. Pass `outputFormat: 'text'` (or ensure the core function defaults to text-based output for CLI).
|
||||
3. The core logic function (as per Section 1) is responsible for calling `displayAiUsageSummary` if telemetry data is available and it's in CLI mode.
|
||||
4. The command action itself **should not** call `displayAiUsageSummary` if the core logic function already handles this. This avoids duplicate display.
|
||||
|
||||
- **Example Snippet (CLI Command in `commands.js`)**:
|
||||
```javascript
|
||||
// In scripts/modules/commands.js
|
||||
import { performAiRelatedAction } from './task-manager/someAiAction.js'; // Core function
|
||||
|
||||
programInstance
|
||||
.command('some-cli-ai-action')
|
||||
// ... .option() ...
|
||||
.action(async (options) => {
|
||||
try {
|
||||
const projectRoot = findProjectRoot() || '.'; // Example root finding
|
||||
// ... prepare parameters for core function from command options ...
|
||||
await performAiRelatedAction(
|
||||
{ /* parameters for core function */ },
|
||||
{ // Context for core function
|
||||
projectRoot,
|
||||
commandNameFromContext: 'some-cli-ai-action',
|
||||
outputType: 'cli'
|
||||
},
|
||||
'text' // Explicitly request text output format for CLI
|
||||
);
|
||||
// Core function handles displayAiUsageSummary internally for 'text' outputFormat
|
||||
} catch (error) {
|
||||
// ... error handling ...
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## Summary Flow
|
||||
|
||||
The telemetry data flows as follows:
|
||||
|
||||
1. **[`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js)**: Generates `telemetryData` and returns `{ mainResult, telemetryData }`.
|
||||
2. **Core Logic Function**:
|
||||
* Receives `{ mainResult, telemetryData }`.
|
||||
* Uses `mainResult`.
|
||||
* If CLI (`outputFormat: 'text'`), calls `displayAiUsageSummary(telemetryData)`.
|
||||
* Returns `{ operationSpecificData, telemetryData }`.
|
||||
3. **Direct Function Wrapper**:
|
||||
* Receives `{ operationSpecificData, telemetryData }` from core logic.
|
||||
* Returns `{ success: true, data: { operationSpecificData, telemetryData } }`.
|
||||
4. **MCP Tool**:
|
||||
* Receives direct function response.
|
||||
* `handleApiResult` ensures the final MCP response to the client is `{ success: true, data: { operationSpecificData, telemetryData } }`.
|
||||
5. **CLI Command**:
|
||||
* Calls core logic with `outputFormat: 'text'`. Display is handled by core logic.
|
||||
|
||||
This pattern ensures telemetry is captured and appropriately handled/exposed across all interaction modes.
|
||||
@@ -1,31 +1,32 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 100000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 120000,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Taskmaster",
|
||||
"ollamaBaseUrl": "http://localhost:11434/api",
|
||||
"azureOpenaiBaseUrl": "https://your-endpoint.openai.azure.com/"
|
||||
}
|
||||
}
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 100000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-3-7-sonnet-20250219",
|
||||
"maxTokens": 8192,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"debug": false,
|
||||
"defaultSubtasks": 5,
|
||||
"defaultPriority": "medium",
|
||||
"projectName": "Taskmaster",
|
||||
"ollamaBaseUrl": "http://localhost:11434/api",
|
||||
"userId": "1234567890",
|
||||
"azureOpenaiBaseUrl": "https://your-endpoint.openai.azure.com/"
|
||||
}
|
||||
}
|
||||
|
||||
60
CHANGELOG.md
60
CHANGELOG.md
@@ -1,5 +1,65 @@
|
||||
# task-master-ai
|
||||
|
||||
## 0.14.0-rc.1
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#536](https://github.com/eyaltoledano/claude-task-master/pull/536) [`f4a83ec`](https://github.com/eyaltoledano/claude-task-master/commit/f4a83ec047b057196833e3a9b861d4bceaec805d) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Add Ollama as a supported AI provider.
|
||||
|
||||
- You can now add it by running `task-master models --setup` and selecting it.
|
||||
- Ollama is a local model provider, so no API key is required.
|
||||
- Ollama models are available at `http://localhost:11434/api` by default.
|
||||
- You can change the default URL by setting the `OLLAMA_BASE_URL` environment variable or by adding a `baseUrl` property to the `ollama` model role in `.taskmasterconfig`.
|
||||
- If you want to use a custom API key, you can set it in the `OLLAMA_API_KEY` environment variable.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#442](https://github.com/eyaltoledano/claude-task-master/pull/442) [`2b3ae8b`](https://github.com/eyaltoledano/claude-task-master/commit/2b3ae8bf89dc471c4ce92f3a12ded57f61faa449) Thanks [@eyaltoledano](https://github.com/eyaltoledano)! - Adds costs information to AI commands using input/output tokens and model costs.
|
||||
|
||||
- [#442](https://github.com/eyaltoledano/claude-task-master/pull/442) [`0288311`](https://github.com/eyaltoledano/claude-task-master/commit/0288311965ae2a343ebee4a0c710dde94d2ae7e7) Thanks [@eyaltoledano](https://github.com/eyaltoledano)! - Small fixes - `next` command no longer incorrectly suggests that subtasks be broken down into subtasks in the CLI - fixes the `append` flag so it properly works in the CLI
|
||||
|
||||
## 0.14.0-rc.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#521](https://github.com/eyaltoledano/claude-task-master/pull/521) [`ed17cb0`](https://github.com/eyaltoledano/claude-task-master/commit/ed17cb0e0a04dedde6c616f68f24f3660f68dd04) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - .taskmasterconfig now supports a baseUrl field per model role (main, research, fallback), allowing endpoint overrides for any provider.
|
||||
|
||||
- [#528](https://github.com/eyaltoledano/claude-task-master/pull/528) [`58b417a`](https://github.com/eyaltoledano/claude-task-master/commit/58b417a8ce697e655f749ca4d759b1c20014c523) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Display task complexity scores in task lists, next task, and task details views.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#478](https://github.com/eyaltoledano/claude-task-master/pull/478) [`4117f71`](https://github.com/eyaltoledano/claude-task-master/commit/4117f71c18ee4d321a9c91308d00d5d69bfac61e) Thanks [@joedanz](https://github.com/joedanz)! - Fix CLI --force flag for parse-prd command
|
||||
|
||||
Previously, the --force flag was not respected when running `parse-prd`, causing the command to prompt for confirmation or fail even when --force was provided. This patch ensures that the flag is correctly passed and handled, allowing users to overwrite existing tasks.json files as intended.
|
||||
|
||||
- Fixes #477
|
||||
|
||||
- [#511](https://github.com/eyaltoledano/claude-task-master/pull/511) [`17294ff`](https://github.com/eyaltoledano/claude-task-master/commit/17294ff25918d64278674e558698a1a9ad785098) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Task Master no longer tells you to update when you're already up to date
|
||||
|
||||
- [#523](https://github.com/eyaltoledano/claude-task-master/pull/523) [`da317f2`](https://github.com/eyaltoledano/claude-task-master/commit/da317f2607ca34db1be78c19954996f634c40923) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Fix the error handling of task status settings
|
||||
|
||||
- [#527](https://github.com/eyaltoledano/claude-task-master/pull/527) [`a8dabf4`](https://github.com/eyaltoledano/claude-task-master/commit/a8dabf44856713f488960224ee838761716bba26) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Remove caching layer from MCP direct functions for task listing, next task, and complexity report
|
||||
|
||||
- Fixes issues users where having where they were getting stale data
|
||||
|
||||
- [#417](https://github.com/eyaltoledano/claude-task-master/pull/417) [`a1f8d52`](https://github.com/eyaltoledano/claude-task-master/commit/a1f8d52474fdbdf48e17a63e3f567a6d63010d9f) Thanks [@ksylvan](https://github.com/ksylvan)! - Fix for issue #409 LOG_LEVEL Pydantic validation error
|
||||
|
||||
- [#501](https://github.com/eyaltoledano/claude-task-master/pull/501) [`0a61184`](https://github.com/eyaltoledano/claude-task-master/commit/0a611843b56a856ef0a479dc34078326e05ac3a8) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Fix initial .env.example to work out of the box
|
||||
|
||||
- Closes #419
|
||||
|
||||
- [#435](https://github.com/eyaltoledano/claude-task-master/pull/435) [`a96215a`](https://github.com/eyaltoledano/claude-task-master/commit/a96215a359b25061fd3b3f3c7b10e8ac0390c062) Thanks [@lebsral](https://github.com/lebsral)! - Fix default fallback model and maxTokens in Taskmaster initialization
|
||||
|
||||
- [#517](https://github.com/eyaltoledano/claude-task-master/pull/517) [`e96734a`](https://github.com/eyaltoledano/claude-task-master/commit/e96734a6cc6fec7731de72eb46b182a6e3743d02) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Fix bug when updating tasks on the MCP server (#412)
|
||||
|
||||
- [#496](https://github.com/eyaltoledano/claude-task-master/pull/496) [`efce374`](https://github.com/eyaltoledano/claude-task-master/commit/efce37469bc58eceef46763ba32df1ed45242211) Thanks [@joedanz](https://github.com/joedanz)! - Fix duplicate output on CLI help screen
|
||||
|
||||
- Prevent the Task Master CLI from printing the help screen more than once when using `-h` or `--help`.
|
||||
- Removed redundant manual event handlers and guards for help output; now only the Commander `.helpInformation` override is used for custom help.
|
||||
- Simplified logic so that help is only shown once for both "no arguments" and help flag flows.
|
||||
- Ensures a clean, branded help experience with no repeated content.
|
||||
- Fixes #339
|
||||
|
||||
## 0.13.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
17
README.md
17
README.md
@@ -11,8 +11,20 @@ A task management system for AI-driven development with Claude, designed to work
|
||||
|
||||
## Requirements
|
||||
|
||||
Taskmaster utilizes AI across several commands, and those require a separate API key. You can use a variety of models from different AI providers provided you add your API keys. For example, if you want to use Claude 3.7, you'll need an Anthropic API key.
|
||||
|
||||
You can define 3 types of models to be used: the main model, the research model, and the fallback model (in case either the main or research fail). Whatever model you use, its provider API key must be present in either mcp.json or .env.
|
||||
|
||||
At least one (1) of the following is required:
|
||||
|
||||
- Anthropic API key (Claude API)
|
||||
- OpenAI SDK (for Perplexity API integration, optional)
|
||||
- OpenAI API key
|
||||
- Google Gemini API key
|
||||
- Perplexity API key (for research model)
|
||||
- xAI API Key (for research or main model)
|
||||
- OpenRouter API Key (for research or main model)
|
||||
|
||||
Using the research model is optional but highly recommended. You will need at least ONE API key. Adding all API keys enables you to seamlessly switch between model providers at will.
|
||||
|
||||
## Quick Start
|
||||
|
||||
@@ -36,7 +48,8 @@ MCP (Model Control Protocol) provides the easiest way to get started with Task M
|
||||
"MISTRAL_API_KEY": "YOUR_MISTRAL_KEY_HERE",
|
||||
"OPENROUTER_API_KEY": "YOUR_OPENROUTER_KEY_HERE",
|
||||
"XAI_API_KEY": "YOUR_XAI_KEY_HERE",
|
||||
"AZURE_OPENAI_API_KEY": "YOUR_AZURE_KEY_HERE"
|
||||
"AZURE_OPENAI_API_KEY": "YOUR_AZURE_KEY_HERE",
|
||||
"OLLAMA_API_KEY": "YOUR_OLLAMA_API_KEY_HERE"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -5,4 +5,5 @@ OPENAI_API_KEY="your_openai_api_key_here" # Optional, for OpenAI/Ope
|
||||
GOOGLE_API_KEY="your_google_api_key_here" # Optional, for Google Gemini models.
|
||||
MISTRAL_API_KEY="your_mistral_key_here" # Optional, for Mistral AI models.
|
||||
XAI_API_KEY="YOUR_XAI_KEY_HERE" # Optional, for xAI AI models.
|
||||
AZURE_OPENAI_API_KEY="your_azure_key_here" # Optional, for Azure OpenAI models (requires endpoint in .taskmasterconfig).
|
||||
AZURE_OPENAI_API_KEY="your_azure_key_here" # Optional, for Azure OpenAI models (requires endpoint in .taskmasterconfig).
|
||||
OLLAMA_API_KEY="your_ollama_api_key_here" # Optional: For remote Ollama servers that require authentication.
|
||||
@@ -39,7 +39,7 @@
|
||||
{
|
||||
"slug": "debug",
|
||||
"name": "Debug",
|
||||
"roleDefinition": "You are Roo, an expert software debugger specializing in systematic problem diagnosis and resolution. When activated by another mdode, your task is to meticulously analyze the provided debugging request (potentially referencing Taskmaster tasks, logs, or metrics), use diagnostic tools as instructed to investigate the issue, identify the root cause, and report your findings and recommended next steps back via `attempt_completion`. You focus solely on diagnostics within the scope defined by the delegated task.",
|
||||
"roleDefinition": "You are Roo, an expert software debugger specializing in systematic problem diagnosis and resolution. When activated by another mode, your task is to meticulously analyze the provided debugging request (potentially referencing Taskmaster tasks, logs, or metrics), use diagnostic tools as instructed to investigate the issue, identify the root cause, and report your findings and recommended next steps back via `attempt_completion`. You focus solely on diagnostics within the scope defined by the delegated task.",
|
||||
"customInstructions": "Reflect on 5-7 different possible sources of the problem, distill those down to 1-2 most likely sources, and then add logs to validate your assumptions. Explicitly ask the user to confirm the diagnosis before fixing the problem.",
|
||||
"groups": [
|
||||
"read",
|
||||
|
||||
368
context/chats/max-min-tokens.txt.md
Normal file
368
context/chats/max-min-tokens.txt.md
Normal file
@@ -0,0 +1,368 @@
|
||||
We want to refine how Task Master handles AI model token limits to be more precise, by:
|
||||
|
||||
1. Distinguishing between `maxInputTokens` and `maxOutputTokens` in the configuration.
|
||||
2. Dynamically adjusting the `maxOutputTokens` for an API call based on the actual prompt length to stay within the model's total context window (or respecting separate input/output limits if the API and model support that).
|
||||
3. Ensuring that `ai-services-unified.js` uses these more granular limits.
|
||||
|
||||
This is a good improvement for both cost control and preventing errors.
|
||||
|
||||
Here's a plan:
|
||||
|
||||
**Phase 1: Configuration and Core Logic Updates**
|
||||
|
||||
1. **Update `.taskmasterconfig` Structure:**
|
||||
- I'll modify the `models` section in your `.taskmasterconfig`. For each role (`main`, `research`, `fallback`), `maxTokens` will be replaced with `maxInputTokens` and `maxOutputTokens`.
|
||||
- We'll need to decide on reasonable default values for these new fields. We can look at the current `maxTokens` and the model's known limits to make an initial guess.
|
||||
2. **Update `MODEL_MAP` in `ai-services-unified.js`:**
|
||||
- This array already stores cost data. We need to ensure it also stores the _absolute_ maximum input and output tokens for each model listed (e.g., `model_max_input_tokens`, `model_max_output_tokens`). If these fields are not present, they will need to be added. The values in `.taskmasterconfig` will then represent user-defined operational limits, which should ideally be validated against these absolute maximums.
|
||||
3. **Update `config-manager.js`:**
|
||||
- Getter functions like `getParametersForRole` will be updated to fetch `maxInputTokens` and `maxOutputTokens` instead of the singular `maxTokens`.
|
||||
- New getters might be needed if we want to access the model's absolute limits directly from `MODEL_MAP` via `config-manager.js`.
|
||||
4. **Update `ai-services-unified.js` (`_unifiedServiceRunner`):**
|
||||
- **Token Counting:** This is a crucial step. Before an API call, we need to estimate the token count of the combined `systemPrompt` and `userPrompt`.
|
||||
- The Vercel AI SDK or the individual provider SDKs might offer utilities for this. For example, some SDKs expose a `tokenizer` or a way to count tokens for a given string.
|
||||
- If a direct utility isn't available through the Vercel SDK for the specific provider, we might need to use a library like `tiktoken` for OpenAI/Anthropic models or investigate provider-specific tokenization. This could be complex as tokenization varies between models.
|
||||
- For now, let's assume we can get a reasonable estimate.
|
||||
- **Dynamic Output Token Calculation & Validation:**
|
||||
- Retrieve `configured_max_input_tokens` and `configured_max_output_tokens` from `config-manager.js` for the current role.
|
||||
- Retrieve `model_absolute_max_input_tokens` and `model_absolute_max_output_tokens` from `MODEL_MAP`.
|
||||
- Let `prompt_tokens = countTokens(systemPrompt + userPrompt)`.
|
||||
- **Input Validation:** If `prompt_tokens > configured_max_input_tokens` OR `prompt_tokens > model_absolute_max_input_tokens`, throw an error. (We might also consider auto-truncation strategies in the future, but an error is safer to start).
|
||||
- **Output Calculation:** The `max_tokens` parameter sent to the API (which typically refers to the _max number of tokens to generate_) should be `configured_max_output_tokens`. We also need to ensure this doesn't violate the model's absolute output limit.
|
||||
- Some models have a _total_ context window (input + output). If this is the case for a model, the `max_tokens` parameter for the API call might need to be `min(configured_max_output_tokens, model_absolute_total_tokens - prompt_tokens)`. However, many modern APIs handle separate input and output limits, simplifying this. We'll aim to pass `configured_max_output_tokens` as the API's `max_tokens` parameter, assuming the input validation has passed.
|
||||
- **API Call Parameter:** Update the `callParams` to use the correctly determined `max_tokens` for generation (which will be our `configured_max_output_tokens`).
|
||||
|
||||
**Phase 2: Error Handling and Refinements**
|
||||
|
||||
1. **Enhanced Error Handling:** Provide clear error messages if prompt tokens exceed input limits, or if API calls fail due to token issues despite our calculations.
|
||||
2. **Validation:** Add validation (perhaps in `config-manager.js` or when `task-master models --setup` is run) to ensure `configured_max_input_tokens` and `configured_max_output_tokens` in `.taskmasterconfig` do not exceed the `model_absolute_max_input_tokens` and `model_absolute_max_output_tokens` from `MODEL_MAP`.
|
||||
|
||||
Let's start by inspecting `scripts/modules/config-manager.js` to see how parameters and `MODEL_MAP` are currently handled. This will inform the changes needed for `.taskmasterconfig` and `ai-services-unified.js`.
|
||||
|
||||
I will now read `scripts/modules/config-manager.js`.
|
||||
|
||||
Okay, I've reviewed `scripts/modules/config-manager.js`. Here's what I've gathered and how it impacts the plan:
|
||||
|
||||
- **`MODEL_MAP` Source:** `MODEL_MAP` is loaded from `supported-models.json`. This is excellent, as it means we can update the model capabilities (including new token limits) in a structured JSON file.
|
||||
- **Configuration Loading:** `_loadAndValidateConfig` handles loading `.taskmasterconfig` and merging it with `DEFAULTS`.
|
||||
- **Getters:** There are specific getters for `maxTokens` for each role (e.g., `getMainMaxTokens`). We will need to update these.
|
||||
- **`getParametersForRole`:** This function already exists and is a good candidate for returning the new `maxInputTokens` and `maxOutputTokens`.
|
||||
|
||||
Here's the refined plan:
|
||||
|
||||
**Phase 1: Configuration and Data Structures**
|
||||
|
||||
1. **Update `supported-models.json`:**
|
||||
|
||||
- For each model entry in `supported-models.json`, we need to add `maxInputTokens` and `maxOutputTokens` fields. These should reflect the _absolute maximums_ for that specific model.
|
||||
- Example entry change:
|
||||
|
||||
```json
|
||||
// Before
|
||||
{
|
||||
"id": "claude-3-7-sonnet-20250219",
|
||||
"name": "Claude 3.7 Sonnet (Preview)",
|
||||
"context_window": 200000, // This might be total context
|
||||
"cost_per_1m_tokens": { "input": 3, "output": 15, "currency": "USD" }
|
||||
}
|
||||
|
||||
// After (assuming 200k is total, and we make a reasonable split or find official numbers)
|
||||
{
|
||||
"id": "claude-3-7-sonnet-20250219",
|
||||
"name": "Claude 3.7 Sonnet (Preview)",
|
||||
"maxInputTokens": 190000, // Example
|
||||
"maxOutputTokens": 8192, // Example, often smaller for generation
|
||||
"cost_per_1m_tokens": { "input": 3, "output": 15, "currency": "USD" }
|
||||
}
|
||||
```
|
||||
|
||||
- I will need to find the official input/output token limits for the models currently in your `MODEL_MAP`. If you have this information handy, it would speed things up. Otherwise, I can make educated guesses or search for them.
|
||||
|
||||
2. **Update `.taskmasterconfig` (Defaults and User File):**
|
||||
- In `scripts/modules/config-manager.js`, modify the `DEFAULTS` object. For each role (`main`, `research`, `fallback`), replace `maxTokens` with:
|
||||
- `maxInputTokens`: A sensible default (e.g., a large portion of the model's capability, but user-configurable).
|
||||
- `maxOutputTokens`: A sensible default for generation (e.g., 4096 or 8192).
|
||||
- You will then need to manually update your existing `.taskmasterconfig` file to reflect this new structure. I can provide the snippet for you to paste.
|
||||
3. **Update `config-manager.js`:**
|
||||
- Modify `getParametersForRole(role, explicitRoot = null)`:
|
||||
- It currently fetches `maxTokens` and `temperature`.
|
||||
- Update it to fetch `maxInputTokens`, `maxOutputTokens`, and `temperature` from the loaded config for the given role.
|
||||
- Remove the role-specific `getMaxTokens` functions (e.g., `getMainMaxTokens`, `getResearchMaxTokens`, `getFallbackMaxTokens`). The `getParametersForRole` will be the central way to get these.
|
||||
- (Optional, for later validation) Consider adding a new function `getModelCapabilities(providerName, modelId)` that reads from `MODEL_MAP` to return the absolute `maxInputTokens` and `maxOutputTokens` for a given model. This would be useful for validating the user's settings in `.taskmasterconfig`.
|
||||
|
||||
**Phase 2: Core Logic in `ai-services-unified.js`**
|
||||
|
||||
1. **Token Counting (`_unifiedServiceRunner`):**
|
||||
|
||||
- This is the most complex part. We need a reliable way to count tokens for the prompts.
|
||||
- **Strategy 1 (Ideal):** Leverage Vercel AI SDK. The SDK might provide a way to get a tokenizer for the active model or a utility function. We'll need to investigate its capabilities.
|
||||
- **Strategy 2 (Fallback):** Use a library like `tiktoken` for models compatible with OpenAI's tokenization (many are, including some Anthropic models). For other models, we might need provider-specific tokenizers or make estimations (less ideal).
|
||||
- **Initial Approach:** Let's try to find a Vercel AI SDK utility first. If not, we'll start with `tiktoken` as a common case and acknowledge that other models might need specific handling later.
|
||||
- The function `_unifiedServiceRunner` will call this token counting utility:
|
||||
|
||||
```javascript
|
||||
// Placeholder for token counting
|
||||
function countTokens(text, modelId /* or providerName */) {
|
||||
// ... implementation using SDK or library ...
|
||||
// This is a simplification; actual tokenization is model-specific.
|
||||
// For now, a rough estimate might be (text.length / 4) as a placeholder
|
||||
// if a proper tokenizer isn't immediately available.
|
||||
if (!text) return 0;
|
||||
return Math.ceil(text.length / 3.5); // Very rough general estimate
|
||||
}
|
||||
|
||||
const promptTokens = countTokens(systemPrompt) + countTokens(prompt);
|
||||
```
|
||||
|
||||
2. **Dynamic Output Token Calculation & Validation (`_unifiedServiceRunner`):**
|
||||
|
||||
- Fetch parameters using the updated `getParametersForRole` from `config-manager.js`:
|
||||
```javascript
|
||||
const roleParams = getParametersForRole(
|
||||
currentRole,
|
||||
effectiveProjectRoot
|
||||
);
|
||||
// roleParams will now contain { maxInputTokens, maxOutputTokens, temperature }
|
||||
```
|
||||
- Fetch model's absolute limits from `MODEL_MAP` (we'll need a helper in `config-manager.js` or do it directly in `ai-services-unified.js` for now):
|
||||
```javascript
|
||||
// Simplified; ideally use a robust getter from config-manager
|
||||
const modelInfo = MODEL_MAP[providerName?.toLowerCase()]?.find(
|
||||
(m) => m.id === modelId
|
||||
);
|
||||
const modelAbsoluteMaxInput = modelInfo?.maxInputTokens || Infinity;
|
||||
const modelAbsoluteMaxOutput =
|
||||
modelInfo?.maxOutputTokens || roleParams.maxOutputTokens; // Fallback to configured if not in map
|
||||
```
|
||||
- **Input Validation:**
|
||||
```javascript
|
||||
if (promptTokens > roleParams.maxInputTokens) {
|
||||
throw new Error(
|
||||
`Prompt (${promptTokens} tokens) exceeds configured max input tokens (${roleParams.maxInputTokens}) for role '${currentRole}'.`
|
||||
);
|
||||
}
|
||||
if (promptTokens > modelAbsoluteMaxInput) {
|
||||
throw new Error(
|
||||
`Prompt (${promptTokens} tokens) exceeds model's absolute max input tokens (${modelAbsoluteMaxInput}) for ${modelId}.`
|
||||
);
|
||||
}
|
||||
```
|
||||
- **API Call Parameter (`max_tokens` for generation):**
|
||||
The `max_tokens` parameter passed to the provider's API call should be `roleParams.maxOutputTokens`. We must also ensure this doesn't exceed the model's absolute output capability.
|
||||
|
||||
```javascript
|
||||
const apiMaxOutputTokens = Math.min(
|
||||
roleParams.maxOutputTokens,
|
||||
modelAbsoluteMaxOutput
|
||||
);
|
||||
|
||||
const callParams = {
|
||||
apiKey,
|
||||
modelId,
|
||||
// Use apiMaxOutputTokens for the actual API call
|
||||
maxTokens: apiMaxOutputTokens, // This usually means max tokens to GENERATE
|
||||
temperature: roleParams.temperature,
|
||||
messages,
|
||||
baseUrl,
|
||||
...(serviceType === 'generateObject' && { schema, objectName }),
|
||||
...restApiParams
|
||||
};
|
||||
```
|
||||
|
||||
3. **Update `logAiUsage`:**
|
||||
- The cost calculation in `logAiUsage` seems correct as it already uses `inputCost` and `outputCost` per 1M tokens. This part should remain compatible.
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
1. **Modify `supported-models.json`:** I need the content of this file to propose the new `maxInputTokens` and `maxOutputTokens` fields. Please provide it.
|
||||
2. **Decide on Tokenizer Strategy:** What are your thoughts on the token counting? Are you aware of any utilities within Vercel AI SDK for this, or should we plan to integrate `tiktoken` initially?
|
||||
|
||||
Once I have the content of `supported-models.json`, I can draft the changes for it and then proceed to `config-manager.js` and `.taskmasterconfig`.
|
||||
|
||||
```json
|
||||
// Before
|
||||
{
|
||||
"id": "claude-3-7-sonnet-20250219",
|
||||
"name": "Claude 3.7 Sonnet (Preview)",
|
||||
"context_window": 200000, // This might be total context
|
||||
"cost_per_1m_tokens": { "input": 3, "output": 15, "currency": "USD" }
|
||||
}
|
||||
|
||||
// After (assuming 200k is total, and we make a reasonable split or find official numbers)
|
||||
{
|
||||
"id": "claude-3-7-sonnet-20250219",
|
||||
"name": "Claude 3.7 Sonnet (Preview)",
|
||||
"maxInputTokens": 190000, // Example
|
||||
"maxOutputTokens": 8192, // Example, often smaller for generation
|
||||
"cost_per_1m_tokens": { "input": 3, "output": 15, "currency": "USD" }
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Placeholder for token counting
|
||||
function countTokens(text, modelId /* or providerName */) {
|
||||
// ... implementation using SDK or library ...
|
||||
// This is a simplification; actual tokenization is model-specific.
|
||||
// For now, a rough estimate might be (text.length / 4) as a placeholder
|
||||
// if a proper tokenizer isn't immediately available.
|
||||
if (!text) return 0;
|
||||
return Math.ceil(text.length / 3.5); // Very rough general estimate
|
||||
}
|
||||
|
||||
const promptTokens = countTokens(systemPrompt) + countTokens(prompt);
|
||||
```
|
||||
|
||||
```javascript
|
||||
const roleParams = getParametersForRole(currentRole, effectiveProjectRoot);
|
||||
// roleParams will now contain { maxInputTokens, maxOutputTokens, temperature }
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Simplified; ideally use a robust getter from config-manager
|
||||
const modelInfo = MODEL_MAP[providerName?.toLowerCase()]?.find(
|
||||
(m) => m.id === modelId
|
||||
);
|
||||
const modelAbsoluteMaxInput = modelInfo?.maxInputTokens || Infinity;
|
||||
const modelAbsoluteMaxOutput =
|
||||
modelInfo?.maxOutputTokens || roleParams.maxOutputTokens; // Fallback to configured if not in map
|
||||
```
|
||||
|
||||
```javascript
|
||||
if (promptTokens > roleParams.maxInputTokens) {
|
||||
throw new Error(
|
||||
`Prompt (${promptTokens} tokens) exceeds configured max input tokens (${roleParams.maxInputTokens}) for role '${currentRole}'.`
|
||||
);
|
||||
}
|
||||
if (promptTokens > modelAbsoluteMaxInput) {
|
||||
throw new Error(
|
||||
`Prompt (${promptTokens} tokens) exceeds model's absolute max input tokens (${modelAbsoluteMaxInput}) for ${modelId}.`
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
const apiMaxOutputTokens = Math.min(
|
||||
roleParams.maxOutputTokens,
|
||||
modelAbsoluteMaxOutput
|
||||
);
|
||||
|
||||
const callParams = {
|
||||
apiKey,
|
||||
modelId,
|
||||
// Use apiMaxOutputTokens for the actual API call
|
||||
maxTokens: apiMaxOutputTokens, // This usually means max tokens to GENERATE
|
||||
temperature: roleParams.temperature,
|
||||
messages,
|
||||
baseUrl,
|
||||
...(serviceType === 'generateObject' && { schema, objectName }),
|
||||
...restApiParams
|
||||
};
|
||||
```
|
||||
|
||||
Okay, I have the contents of `supported-models.json`.
|
||||
|
||||
It seems many models have a `max_tokens` field, which I assume is the _total context window_. Some don't have it, and for others (like OpenAI `gpt-4o`), the listed `max_tokens` (16384) is known to be its _output_ token limit when using the Chat Completions API, while the context window is much larger (128k). This highlights the complexity: `max_tokens` in `supported-models.json` is used inconsistently.
|
||||
|
||||
**Revised Plan for `supported-models.json` and Token Definitions:**
|
||||
|
||||
To bring clarity, we'll introduce two new fields and ensure their meaning is consistent:
|
||||
|
||||
- `contextWindowTokens`: The total number of tokens the model can process (input + output). This would replace the current ambiguous `max_tokens`.
|
||||
- `maxOutputTokens`: The maximum number of tokens the model can _generate_ in a single response. This is often smaller than the total context window, especially for larger models.
|
||||
|
||||
If a model _only_ specifies a total context window, we'll have to make a reasonable assumption for `maxOutputTokens` (e.g., 4096 or 8192, or a fraction of the total context window). If it only specifies an output token limit (like some OpenAI models in certain API modes), we'll need to find its total context window.
|
||||
|
||||
**Updated `supported-models.json` Structure (Example):**
|
||||
|
||||
```json
|
||||
// For a model like Anthropic Claude 3.7 Sonnet (Preview)
|
||||
{
|
||||
"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, // From Anthropic's documentation
|
||||
"maxOutputTokens": 8192 // Anthropic default, user can override in .taskmasterconfig
|
||||
}
|
||||
|
||||
// For a model like OpenAI GPT-4o
|
||||
{
|
||||
"id": "gpt-4o",
|
||||
"swe_score": 0.332,
|
||||
"cost_per_1m_tokens": { "input": 2.5, "output": 10.0 },
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"contextWindowTokens": 128000, // Official context window
|
||||
"maxOutputTokens": 16384 // Max output for chat completions is 16k for gpt-4o (used to be 4k/8k for older gpt-4)
|
||||
// but the model card mentions 128k total. The API call parameter for `max_tokens` sets this output cap.
|
||||
}
|
||||
```
|
||||
|
||||
I will proceed to generate the updated `supported-models.json` content. This will be a significant change. I will make my best effort to find the correct `contextWindowTokens` and `maxOutputTokens` for each model. If official numbers are ambiguous or not readily available, I'll use sensible defaults and add a comment.
|
||||
|
||||
**Regarding Tokenizer Strategy:**
|
||||
|
||||
- **Vercel AI SDK:** The `ai` package (Vercel AI SDK) itself is a lightweight wrapper. Tokenization is usually handled by the underlying provider-specific SDKs (e.g., `@anthropic-ai/sdk`, `openai`). The Vercel SDK doesn't provide a universal tokenizer.
|
||||
- **Provider SDKs:**
|
||||
- `@anthropic-ai/sdk`: Does not expose a public tokenizer directly. Anthropic recommends counting based on their guidelines (roughly 3.5 chars/token for English).
|
||||
- `openai` (for Node.js): The `gpt-3-encoder` or `tiktoken` libraries are commonly used. `tiktoken` is more current.
|
||||
- **`tiktoken`:** This is a good general-purpose library for OpenAI models and those that use compatible tokenization (many models fine-tuned from Llama, etc., might be close). It supports various encodings.
|
||||
- **Recommendation:**
|
||||
1. Start by integrating `tiktoken`. We can select the encoding based on the provider or even specific model if needed (e.g., `cl100k_base` for gpt-4, gpt-3.5-turbo, DALL-E models).
|
||||
2. For providers where `tiktoken` is not accurate (e.g., Google's Gemini, Perplexity if they have proprietary tokenizers), we might have to rely on character-based estimations (e.g., `length / N`) as a rougher guide or investigate if their specific SDKs offer token counting.
|
||||
3. The Vercel AI SDK's `experimental_streamObject` and other functions _might_ internally handle some aspects of token counting for request preparation, but we need explicit counting for our logic _before_ the call.
|
||||
|
||||
For now, let's assume we'll add a `countTokens` utility that uses `tiktoken` for OpenAI and Anthropic (as Anthropic's guidance is character-based but `cl100k_base` is often a decent proxy for their tokenization for rough estimates, though not perfect), and a character-based fallback for others.
|
||||
|
||||
I will now generate the proposed changes for `scripts/modules/supported-models.json`. This will be a large diff.
|
||||
|
||||
After this, we'll move to:
|
||||
|
||||
1. Updating `.taskmasterconfig` defaults in `config-manager.js` and providing you the snippet for your user file.
|
||||
2. Updating `config-manager.js` getters.
|
||||
3. Implementing the logic in `ai-services-unified.js`.
|
||||
|
||||
```json
|
||||
// For a model like Anthropic Claude 3.7 Sonnet (Preview)
|
||||
{
|
||||
"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, // From Anthropic's documentation
|
||||
"maxOutputTokens": 8192 // Anthropic default, user can override in .taskmasterconfig
|
||||
}
|
||||
|
||||
// For a model like OpenAI GPT-4o
|
||||
{
|
||||
"id": "gpt-4o",
|
||||
"swe_score": 0.332,
|
||||
"cost_per_1m_tokens": { "input": 2.5, "output": 10.0 },
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"contextWindowTokens": 128000, // Official context window
|
||||
"maxOutputTokens": 16384 // Max output for chat completions is 16k for gpt-4o (used to be 4k/8k for older gpt-4)
|
||||
// but the model card mentions 128k total. The API call parameter for `max_tokens` sets this output cap.
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
// For a model like Anthropic Claude 3.7 Sonnet (Preview)
|
||||
{
|
||||
"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, // From Anthropic's documentation
|
||||
"maxOutputTokens": 8192 // Anthropic default, user can override in .taskmasterconfig
|
||||
}
|
||||
|
||||
// For a model like OpenAI GPT-4o
|
||||
{
|
||||
"id": "gpt-4o",
|
||||
"swe_score": 0.332,
|
||||
"cost_per_1m_tokens": { "input": 2.5, "output": 10.0 },
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"contextWindowTokens": 128000, // Official context window
|
||||
"maxOutputTokens": 16384 // Max output for chat completions is 16k for gpt-4o (used to be 4k/8k for older gpt-4)
|
||||
// but the model card mentions 128k total. The API call parameter for `max_tokens` sets this output cap.
|
||||
}
|
||||
```
|
||||
@@ -94,6 +94,7 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
|
||||
let manualTaskData = null;
|
||||
let newTaskId;
|
||||
let telemetryData;
|
||||
|
||||
if (isManualCreation) {
|
||||
// Create manual task data object
|
||||
@@ -109,7 +110,7 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
);
|
||||
|
||||
// Call the addTask function with manual task data
|
||||
newTaskId = await addTask(
|
||||
const result = await addTask(
|
||||
tasksPath,
|
||||
null, // prompt is null for manual creation
|
||||
taskDependencies,
|
||||
@@ -117,13 +118,17 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
{
|
||||
session,
|
||||
mcpLog,
|
||||
projectRoot
|
||||
projectRoot,
|
||||
commandName: 'add-task',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json', // outputFormat
|
||||
manualTaskData, // Pass the manual task data
|
||||
false, // research flag is false for manual creation
|
||||
projectRoot // Pass projectRoot
|
||||
);
|
||||
newTaskId = result.newTaskId;
|
||||
telemetryData = result.telemetryData;
|
||||
} else {
|
||||
// AI-driven task creation
|
||||
log.info(
|
||||
@@ -131,7 +136,7 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
);
|
||||
|
||||
// Call the addTask function, passing the research flag
|
||||
newTaskId = await addTask(
|
||||
const result = await addTask(
|
||||
tasksPath,
|
||||
prompt, // Use the prompt for AI creation
|
||||
taskDependencies,
|
||||
@@ -139,12 +144,16 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
{
|
||||
session,
|
||||
mcpLog,
|
||||
projectRoot
|
||||
projectRoot,
|
||||
commandName: 'add-task',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json', // outputFormat
|
||||
null, // manualTaskData is null for AI creation
|
||||
research // Pass the research flag
|
||||
);
|
||||
newTaskId = result.newTaskId;
|
||||
telemetryData = result.telemetryData;
|
||||
}
|
||||
|
||||
// Restore normal logging
|
||||
@@ -154,7 +163,8 @@ export async function addTaskDirect(args, log, context = {}) {
|
||||
success: true,
|
||||
data: {
|
||||
taskId: newTaskId,
|
||||
message: `Successfully added new task #${newTaskId}`
|
||||
message: `Successfully added new task #${newTaskId}`,
|
||||
telemetryData: telemetryData
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
|
||||
@@ -79,17 +79,19 @@ export async function analyzeTaskComplexityDirect(args, log, context = {}) {
|
||||
}
|
||||
|
||||
let report;
|
||||
let coreResult;
|
||||
|
||||
try {
|
||||
// --- Call Core Function (Pass context separately) ---
|
||||
// Pass coreOptions as the first argument
|
||||
// Pass context object { session, mcpLog } as the second argument
|
||||
report = await analyzeTaskComplexity(
|
||||
coreOptions, // Pass options object
|
||||
{ session, mcpLog: logWrapper } // Pass context object
|
||||
// Removed the explicit 'json' format argument, assuming context handling is sufficient
|
||||
// If issues persist, we might need to add an explicit format param to analyzeTaskComplexity
|
||||
);
|
||||
coreResult = await analyzeTaskComplexity(coreOptions, {
|
||||
session,
|
||||
mcpLog: logWrapper,
|
||||
commandName: 'analyze-complexity',
|
||||
outputType: 'mcp'
|
||||
});
|
||||
report = coreResult.report;
|
||||
} catch (error) {
|
||||
log.error(
|
||||
`Error in analyzeTaskComplexity core function: ${error.message}`
|
||||
@@ -125,8 +127,11 @@ export async function analyzeTaskComplexityDirect(args, log, context = {}) {
|
||||
};
|
||||
}
|
||||
|
||||
// Added a check to ensure report is defined before accessing its properties
|
||||
if (!report || typeof report !== 'object') {
|
||||
if (
|
||||
!coreResult ||
|
||||
!coreResult.report ||
|
||||
typeof coreResult.report !== 'object'
|
||||
) {
|
||||
log.error(
|
||||
'Core analysis function returned an invalid or undefined response.'
|
||||
);
|
||||
@@ -141,8 +146,8 @@ export async function analyzeTaskComplexityDirect(args, log, context = {}) {
|
||||
|
||||
try {
|
||||
// Ensure complexityAnalysis exists and is an array
|
||||
const analysisArray = Array.isArray(report.complexityAnalysis)
|
||||
? report.complexityAnalysis
|
||||
const analysisArray = Array.isArray(coreResult.report.complexityAnalysis)
|
||||
? coreResult.report.complexityAnalysis
|
||||
: [];
|
||||
|
||||
// Count tasks by complexity (remains the same)
|
||||
@@ -159,15 +164,16 @@ export async function analyzeTaskComplexityDirect(args, log, context = {}) {
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
message: `Task complexity analysis complete. Report saved to ${outputPath}`, // Use outputPath from args
|
||||
reportPath: outputPath, // Use outputPath from args
|
||||
message: `Task complexity analysis complete. Report saved to ${outputPath}`,
|
||||
reportPath: outputPath,
|
||||
reportSummary: {
|
||||
taskCount: analysisArray.length,
|
||||
highComplexityTasks,
|
||||
mediumComplexityTasks,
|
||||
lowComplexityTasks
|
||||
},
|
||||
fullReport: report // Now includes the full report
|
||||
fullReport: coreResult.report,
|
||||
telemetryData: coreResult.telemetryData
|
||||
}
|
||||
};
|
||||
} catch (parseError) {
|
||||
|
||||
@@ -63,12 +63,18 @@ export async function expandAllTasksDirect(args, log, context = {}) {
|
||||
{ session, mcpLog, projectRoot }
|
||||
);
|
||||
|
||||
// Core function now returns a summary object
|
||||
// Core function now returns a summary object including the *aggregated* telemetryData
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
message: `Expand all operation completed. Expanded: ${result.expandedCount}, Failed: ${result.failedCount}, Skipped: ${result.skippedCount}`,
|
||||
details: result // Include the full result details
|
||||
details: {
|
||||
expandedCount: result.expandedCount,
|
||||
failedCount: result.failedCount,
|
||||
skippedCount: result.skippedCount,
|
||||
tasksToExpand: result.tasksToExpand
|
||||
},
|
||||
telemetryData: result.telemetryData // Pass the aggregated object
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
|
||||
@@ -193,13 +193,19 @@ export async function expandTaskDirect(args, log, context = {}) {
|
||||
if (!wasSilent) enableSilentMode();
|
||||
|
||||
// Call the core expandTask function with the wrapped logger and projectRoot
|
||||
const updatedTaskResult = await expandTask(
|
||||
const coreResult = await expandTask(
|
||||
tasksPath,
|
||||
taskId,
|
||||
numSubtasks,
|
||||
useResearch,
|
||||
additionalContext,
|
||||
{ mcpLog, session, projectRoot },
|
||||
{
|
||||
mcpLog,
|
||||
session,
|
||||
projectRoot,
|
||||
commandName: 'expand-task',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
forceFlag
|
||||
);
|
||||
|
||||
@@ -215,16 +221,17 @@ export async function expandTaskDirect(args, log, context = {}) {
|
||||
? updatedTask.subtasks.length - subtasksCountBefore
|
||||
: 0;
|
||||
|
||||
// Return the result
|
||||
// Return the result, including telemetryData
|
||||
log.info(
|
||||
`Successfully expanded task ${taskId} with ${subtasksAdded} new subtasks`
|
||||
);
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
task: updatedTask,
|
||||
task: coreResult.task,
|
||||
subtasksAdded,
|
||||
hasExistingSubtasks
|
||||
hasExistingSubtasks,
|
||||
telemetryData: coreResult.telemetryData
|
||||
},
|
||||
fromCache: false
|
||||
};
|
||||
|
||||
@@ -18,7 +18,7 @@ import {
|
||||
*/
|
||||
export async function listTasksDirect(args, log) {
|
||||
// Destructure the explicit tasksJsonPath from args
|
||||
const { tasksJsonPath, status, withSubtasks } = args;
|
||||
const { tasksJsonPath, reportPath, status, withSubtasks } = args;
|
||||
|
||||
if (!tasksJsonPath) {
|
||||
log.error('listTasksDirect called without tasksJsonPath');
|
||||
@@ -49,6 +49,7 @@ export async function listTasksDirect(args, log) {
|
||||
const resultData = listTasks(
|
||||
tasksJsonPath,
|
||||
statusFilter,
|
||||
reportPath,
|
||||
withSubtasksFilter,
|
||||
'json'
|
||||
);
|
||||
@@ -63,6 +64,7 @@ export async function listTasksDirect(args, log) {
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
log.info(
|
||||
`Core listTasks function retrieved ${resultData.tasks.length} tasks`
|
||||
);
|
||||
|
||||
@@ -4,7 +4,10 @@
|
||||
*/
|
||||
|
||||
import { findNextTask } from '../../../../scripts/modules/task-manager.js';
|
||||
import { readJSON } from '../../../../scripts/modules/utils.js';
|
||||
import {
|
||||
readJSON,
|
||||
readComplexityReport
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import {
|
||||
enableSilentMode,
|
||||
disableSilentMode
|
||||
@@ -20,7 +23,7 @@ import {
|
||||
*/
|
||||
export async function nextTaskDirect(args, log) {
|
||||
// Destructure expected args
|
||||
const { tasksJsonPath } = args;
|
||||
const { tasksJsonPath, reportPath } = args;
|
||||
|
||||
if (!tasksJsonPath) {
|
||||
log.error('nextTaskDirect called without tasksJsonPath');
|
||||
@@ -55,8 +58,11 @@ export async function nextTaskDirect(args, log) {
|
||||
};
|
||||
}
|
||||
|
||||
// Read the complexity report
|
||||
const complexityReport = readComplexityReport(reportPath);
|
||||
|
||||
// Find the next task
|
||||
const nextTask = findNextTask(data.tasks);
|
||||
const nextTask = findNextTask(data.tasks, complexityReport);
|
||||
|
||||
if (!nextTask) {
|
||||
log.info(
|
||||
|
||||
@@ -105,11 +105,9 @@ export async function parsePRDDirect(args, log, context = {}) {
|
||||
}
|
||||
}
|
||||
|
||||
const useForce = force === true;
|
||||
const useAppend = append === true;
|
||||
if (useAppend) {
|
||||
if (append) {
|
||||
logWrapper.info('Append mode enabled.');
|
||||
if (useForce) {
|
||||
if (force) {
|
||||
logWrapper.warn(
|
||||
'Both --force and --append flags were provided. --force takes precedence; append mode will be ignored.'
|
||||
);
|
||||
@@ -117,7 +115,7 @@ export async function parsePRDDirect(args, log, context = {}) {
|
||||
}
|
||||
|
||||
logWrapper.info(
|
||||
`Parsing PRD via direct function. Input: ${inputPath}, Output: ${outputPath}, NumTasks: ${numTasks}, Force: ${useForce}, Append: ${useAppend}, ProjectRoot: ${projectRoot}`
|
||||
`Parsing PRD via direct function. Input: ${inputPath}, Output: ${outputPath}, NumTasks: ${numTasks}, Force: ${force}, Append: ${append}, ProjectRoot: ${projectRoot}`
|
||||
);
|
||||
|
||||
const wasSilent = isSilentMode();
|
||||
@@ -131,21 +129,28 @@ export async function parsePRDDirect(args, log, context = {}) {
|
||||
inputPath,
|
||||
outputPath,
|
||||
numTasks,
|
||||
{ session, mcpLog: logWrapper, projectRoot, useForce, useAppend },
|
||||
{
|
||||
session,
|
||||
mcpLog: logWrapper,
|
||||
projectRoot,
|
||||
force,
|
||||
append,
|
||||
commandName: 'parse-prd',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json'
|
||||
);
|
||||
|
||||
// parsePRD returns { success: true, tasks: processedTasks } on success
|
||||
if (result && result.success && Array.isArray(result.tasks)) {
|
||||
logWrapper.success(
|
||||
`Successfully parsed PRD. Generated ${result.tasks.length} tasks.`
|
||||
);
|
||||
// Adjust check for the new return structure
|
||||
if (result && result.success) {
|
||||
const successMsg = `Successfully parsed PRD and generated tasks in ${result.tasksPath}`;
|
||||
logWrapper.success(successMsg);
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
message: `Successfully parsed PRD and generated ${result.tasks.length} tasks.`,
|
||||
outputPath: outputPath,
|
||||
taskCount: result.tasks.length
|
||||
message: successMsg,
|
||||
outputPath: result.tasksPath,
|
||||
telemetryData: result.telemetryData
|
||||
}
|
||||
};
|
||||
} else {
|
||||
|
||||
@@ -3,7 +3,11 @@
|
||||
* Direct function implementation for showing task details
|
||||
*/
|
||||
|
||||
import { findTaskById, readJSON } from '../../../../scripts/modules/utils.js';
|
||||
import {
|
||||
findTaskById,
|
||||
readComplexityReport,
|
||||
readJSON
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import { findTasksJsonPath } from '../utils/path-utils.js';
|
||||
|
||||
/**
|
||||
@@ -12,6 +16,7 @@ import { findTasksJsonPath } from '../utils/path-utils.js';
|
||||
* @param {Object} args - Command arguments.
|
||||
* @param {string} args.id - Task ID to show.
|
||||
* @param {string} [args.file] - Optional path to the tasks file (passed to findTasksJsonPath).
|
||||
* @param {string} args.reportPath - Explicit path to the complexity report file.
|
||||
* @param {string} [args.status] - Optional status to filter subtasks by.
|
||||
* @param {string} args.projectRoot - Absolute path to the project root directory (already normalized by tool).
|
||||
* @param {Object} log - Logger object.
|
||||
@@ -22,7 +27,7 @@ export async function showTaskDirect(args, log) {
|
||||
// Destructure session from context if needed later, otherwise ignore
|
||||
// const { session } = context;
|
||||
// Destructure projectRoot and other args. projectRoot is assumed normalized.
|
||||
const { id, file, status, projectRoot } = args;
|
||||
const { id, file, reportPath, status, projectRoot } = args;
|
||||
|
||||
log.info(
|
||||
`Showing task direct function. ID: ${id}, File: ${file}, Status Filter: ${status}, ProjectRoot: ${projectRoot}`
|
||||
@@ -59,9 +64,12 @@ export async function showTaskDirect(args, log) {
|
||||
};
|
||||
}
|
||||
|
||||
const complexityReport = readComplexityReport(reportPath);
|
||||
|
||||
const { task, originalSubtaskCount } = findTaskById(
|
||||
tasksData.tasks,
|
||||
id,
|
||||
complexityReport,
|
||||
status
|
||||
);
|
||||
|
||||
|
||||
@@ -108,18 +108,24 @@ export async function updateSubtaskByIdDirect(args, log, context = {}) {
|
||||
|
||||
try {
|
||||
// Execute core updateSubtaskById function
|
||||
const updatedSubtask = await updateSubtaskById(
|
||||
const coreResult = await updateSubtaskById(
|
||||
tasksPath,
|
||||
subtaskIdStr,
|
||||
prompt,
|
||||
useResearch,
|
||||
{ mcpLog: logWrapper, session, projectRoot },
|
||||
{
|
||||
mcpLog: logWrapper,
|
||||
session,
|
||||
projectRoot,
|
||||
commandName: 'update-subtask',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json'
|
||||
);
|
||||
|
||||
if (updatedSubtask === null) {
|
||||
if (!coreResult || coreResult.updatedSubtask === null) {
|
||||
const message = `Subtask ${id} or its parent task not found.`;
|
||||
logWrapper.error(message); // Log as error since it couldn't be found
|
||||
logWrapper.error(message);
|
||||
return {
|
||||
success: false,
|
||||
error: { code: 'SUBTASK_NOT_FOUND', message: message },
|
||||
@@ -136,9 +142,10 @@ export async function updateSubtaskByIdDirect(args, log, context = {}) {
|
||||
message: `Successfully updated subtask with ID ${subtaskIdStr}`,
|
||||
subtaskId: subtaskIdStr,
|
||||
parentId: subtaskIdStr.split('.')[0],
|
||||
subtask: updatedSubtask,
|
||||
subtask: coreResult.updatedSubtask,
|
||||
tasksPath,
|
||||
useResearch
|
||||
useResearch,
|
||||
telemetryData: coreResult.telemetryData
|
||||
},
|
||||
fromCache: false
|
||||
};
|
||||
|
||||
@@ -110,7 +110,7 @@ export async function updateTaskByIdDirect(args, log, context = {}) {
|
||||
|
||||
try {
|
||||
// Execute core updateTaskById function with proper parameters
|
||||
const updatedTask = await updateTaskById(
|
||||
const coreResult = await updateTaskById(
|
||||
tasksPath,
|
||||
taskId,
|
||||
prompt,
|
||||
@@ -118,19 +118,26 @@ export async function updateTaskByIdDirect(args, log, context = {}) {
|
||||
{
|
||||
mcpLog: logWrapper,
|
||||
session,
|
||||
projectRoot
|
||||
projectRoot,
|
||||
commandName: 'update-task',
|
||||
outputType: 'mcp'
|
||||
},
|
||||
'json'
|
||||
);
|
||||
|
||||
// Check if the core function indicated the task wasn't updated (e.g., status was 'done')
|
||||
if (updatedTask === null) {
|
||||
// Check if the core function returned null or an object without success
|
||||
if (!coreResult || coreResult.updatedTask === null) {
|
||||
// Core function logs the reason, just return success with info
|
||||
const message = `Task ${taskId} was not updated (likely already completed).`;
|
||||
logWrapper.info(message);
|
||||
return {
|
||||
success: true,
|
||||
data: { message: message, taskId: taskId, updated: false },
|
||||
data: {
|
||||
message: message,
|
||||
taskId: taskId,
|
||||
updated: false,
|
||||
telemetryData: coreResult?.telemetryData
|
||||
},
|
||||
fromCache: false
|
||||
};
|
||||
}
|
||||
@@ -146,7 +153,8 @@ export async function updateTaskByIdDirect(args, log, context = {}) {
|
||||
tasksPath: tasksPath,
|
||||
useResearch: useResearch,
|
||||
updated: true,
|
||||
updatedTask: updatedTask
|
||||
updatedTask: coreResult.updatedTask,
|
||||
telemetryData: coreResult.telemetryData
|
||||
},
|
||||
fromCache: false
|
||||
};
|
||||
|
||||
@@ -85,7 +85,6 @@ export async function updateTasksDirect(args, log, context = {}) {
|
||||
'json'
|
||||
);
|
||||
|
||||
// updateTasks returns { success: true, updatedTasks: [...] } on success
|
||||
if (result && result.success && Array.isArray(result.updatedTasks)) {
|
||||
logWrapper.success(
|
||||
`Successfully updated ${result.updatedTasks.length} tasks.`
|
||||
@@ -95,7 +94,8 @@ export async function updateTasksDirect(args, log, context = {}) {
|
||||
data: {
|
||||
message: `Successfully updated ${result.updatedTasks.length} tasks.`,
|
||||
tasksFile,
|
||||
updatedCount: result.updatedTasks.length
|
||||
updatedCount: result.updatedTasks.length,
|
||||
telemetryData: result.telemetryData
|
||||
}
|
||||
};
|
||||
} else {
|
||||
|
||||
@@ -339,6 +339,49 @@ export function findPRDDocumentPath(projectRoot, explicitPath, log) {
|
||||
return null;
|
||||
}
|
||||
|
||||
export function findComplexityReportPath(projectRoot, explicitPath, log) {
|
||||
// If explicit path is provided, check if it exists
|
||||
if (explicitPath) {
|
||||
const fullPath = path.isAbsolute(explicitPath)
|
||||
? explicitPath
|
||||
: path.resolve(projectRoot, explicitPath);
|
||||
|
||||
if (fs.existsSync(fullPath)) {
|
||||
log.info(`Using provided PRD document path: ${fullPath}`);
|
||||
return fullPath;
|
||||
} else {
|
||||
log.warn(
|
||||
`Provided PRD document path not found: ${fullPath}, will search for alternatives`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
// Common locations and file patterns for PRD documents
|
||||
const commonLocations = [
|
||||
'', // Project root
|
||||
'scripts/'
|
||||
];
|
||||
|
||||
const commonFileNames = [
|
||||
'complexity-report.json',
|
||||
'task-complexity-report.json'
|
||||
];
|
||||
|
||||
// Check all possible combinations
|
||||
for (const location of commonLocations) {
|
||||
for (const fileName of commonFileNames) {
|
||||
const potentialPath = path.join(projectRoot, location, fileName);
|
||||
if (fs.existsSync(potentialPath)) {
|
||||
log.info(`Found PRD document at: ${potentialPath}`);
|
||||
return potentialPath;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
log.warn(`No PRD document found in common locations within ${projectRoot}`);
|
||||
return null;
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves the tasks output directory path
|
||||
* @param {string} projectRoot - The project root directory
|
||||
|
||||
@@ -10,7 +10,10 @@ import {
|
||||
withNormalizedProjectRoot
|
||||
} from './utils.js';
|
||||
import { showTaskDirect } from '../core/task-master-core.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import {
|
||||
findTasksJsonPath,
|
||||
findComplexityReportPath
|
||||
} from '../core/utils/path-utils.js';
|
||||
|
||||
/**
|
||||
* Custom processor function that removes allTasks from the response
|
||||
@@ -50,6 +53,12 @@ export function registerShowTaskTool(server) {
|
||||
.string()
|
||||
.optional()
|
||||
.describe('Path to the tasks file relative to project root'),
|
||||
complexityReport: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
'Path to the complexity report file (relative to project root or absolute)'
|
||||
),
|
||||
projectRoot: z
|
||||
.string()
|
||||
.optional()
|
||||
@@ -81,9 +90,22 @@ export function registerShowTaskTool(server) {
|
||||
}
|
||||
|
||||
// Call the direct function, passing the normalized projectRoot
|
||||
// Resolve the path to complexity report
|
||||
let complexityReportPath;
|
||||
try {
|
||||
complexityReportPath = findComplexityReportPath(
|
||||
projectRoot,
|
||||
args.complexityReport,
|
||||
log
|
||||
);
|
||||
} catch (error) {
|
||||
log.error(`Error finding complexity report: ${error.message}`);
|
||||
}
|
||||
const result = await showTaskDirect(
|
||||
{
|
||||
tasksJsonPath: tasksJsonPath,
|
||||
reportPath: complexityReportPath,
|
||||
// Pass other relevant args
|
||||
id: id,
|
||||
status: status,
|
||||
projectRoot: projectRoot
|
||||
|
||||
@@ -10,7 +10,10 @@ import {
|
||||
withNormalizedProjectRoot
|
||||
} from './utils.js';
|
||||
import { listTasksDirect } from '../core/task-master-core.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import {
|
||||
findTasksJsonPath,
|
||||
findComplexityReportPath
|
||||
} from '../core/utils/path-utils.js';
|
||||
|
||||
/**
|
||||
* Register the getTasks tool with the MCP server
|
||||
@@ -38,6 +41,12 @@ export function registerListTasksTool(server) {
|
||||
.describe(
|
||||
'Path to the tasks file (relative to project root or absolute)'
|
||||
),
|
||||
complexityReport: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
'Path to the complexity report file (relative to project root or absolute)'
|
||||
),
|
||||
projectRoot: z
|
||||
.string()
|
||||
.describe('The directory of the project. Must be an absolute path.')
|
||||
@@ -60,11 +69,23 @@ export function registerListTasksTool(server) {
|
||||
);
|
||||
}
|
||||
|
||||
// Resolve the path to complexity report
|
||||
let complexityReportPath;
|
||||
try {
|
||||
complexityReportPath = findComplexityReportPath(
|
||||
args.projectRoot,
|
||||
args.complexityReport,
|
||||
log
|
||||
);
|
||||
} catch (error) {
|
||||
log.error(`Error finding complexity report: ${error.message}`);
|
||||
}
|
||||
const result = await listTasksDirect(
|
||||
{
|
||||
tasksJsonPath: tasksJsonPath,
|
||||
status: args.status,
|
||||
withSubtasks: args.withSubtasks
|
||||
withSubtasks: args.withSubtasks,
|
||||
reportPath: complexityReportPath
|
||||
},
|
||||
log
|
||||
);
|
||||
|
||||
@@ -10,7 +10,10 @@ import {
|
||||
withNormalizedProjectRoot
|
||||
} from './utils.js';
|
||||
import { nextTaskDirect } from '../core/task-master-core.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import {
|
||||
findTasksJsonPath,
|
||||
findComplexityReportPath
|
||||
} from '../core/utils/path-utils.js';
|
||||
|
||||
/**
|
||||
* Register the next-task tool with the MCP server
|
||||
@@ -23,6 +26,12 @@ export function registerNextTaskTool(server) {
|
||||
'Find the next task to work on based on dependencies and status',
|
||||
parameters: z.object({
|
||||
file: z.string().optional().describe('Absolute path to the tasks file'),
|
||||
complexityReport: z
|
||||
.string()
|
||||
.optional()
|
||||
.describe(
|
||||
'Path to the complexity report file (relative to project root or absolute)'
|
||||
),
|
||||
projectRoot: z
|
||||
.string()
|
||||
.describe('The directory of the project. Must be an absolute path.')
|
||||
@@ -45,9 +54,21 @@ export function registerNextTaskTool(server) {
|
||||
);
|
||||
}
|
||||
|
||||
// Resolve the path to complexity report
|
||||
let complexityReportPath;
|
||||
try {
|
||||
complexityReportPath = findComplexityReportPath(
|
||||
args.projectRoot,
|
||||
args.complexityReport,
|
||||
log
|
||||
);
|
||||
} catch (error) {
|
||||
log.error(`Error finding complexity report: ${error.message}`);
|
||||
}
|
||||
const result = await nextTaskDirect(
|
||||
{
|
||||
tasksJsonPath: tasksJsonPath
|
||||
tasksJsonPath: tasksJsonPath,
|
||||
reportPath: complexityReportPath
|
||||
},
|
||||
log
|
||||
);
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "task-master-ai",
|
||||
"version": "0.13.2",
|
||||
"version": "0.14.0-rc.1",
|
||||
"description": "A task management system for ambitious AI-driven development that doesn't overwhelm and confuse Cursor.",
|
||||
"main": "index.js",
|
||||
"type": "module",
|
||||
@@ -49,6 +49,9 @@
|
||||
"@anthropic-ai/sdk": "^0.39.0",
|
||||
"@openrouter/ai-sdk-provider": "^0.4.5",
|
||||
"ai": "^4.3.10",
|
||||
"boxen": "^8.0.1",
|
||||
"chalk": "^5.4.1",
|
||||
"cli-table3": "^0.6.5",
|
||||
"commander": "^11.1.0",
|
||||
"cors": "^2.8.5",
|
||||
"dotenv": "^16.3.1",
|
||||
@@ -65,9 +68,6 @@
|
||||
"openai": "^4.89.0",
|
||||
"ora": "^8.2.0",
|
||||
"uuid": "^11.1.0",
|
||||
"boxen": "^8.0.1",
|
||||
"chalk": "^5.4.1",
|
||||
"cli-table3": "^0.6.5",
|
||||
"zod": "^3.23.8"
|
||||
},
|
||||
"engines": {
|
||||
|
||||
@@ -15,9 +15,12 @@ import {
|
||||
getFallbackProvider,
|
||||
getFallbackModelId,
|
||||
getParametersForRole,
|
||||
getUserId,
|
||||
MODEL_MAP,
|
||||
getDebugFlag,
|
||||
getBaseUrlForRole
|
||||
} from './config-manager.js';
|
||||
import { log, resolveEnvVariable, findProjectRoot } from './utils.js';
|
||||
import { log, resolveEnvVariable, isSilentMode } from './utils.js';
|
||||
|
||||
import * as anthropic from '../../src/ai-providers/anthropic.js';
|
||||
import * as perplexity from '../../src/ai-providers/perplexity.js';
|
||||
@@ -25,8 +28,39 @@ import * as google from '../../src/ai-providers/google.js';
|
||||
import * as openai from '../../src/ai-providers/openai.js';
|
||||
import * as xai from '../../src/ai-providers/xai.js';
|
||||
import * as openrouter from '../../src/ai-providers/openrouter.js';
|
||||
import * as ollama from '../../src/ai-providers/ollama.js';
|
||||
// TODO: Import other provider modules when implemented (ollama, etc.)
|
||||
|
||||
// Helper function to get cost for a specific model
|
||||
function _getCostForModel(providerName, modelId) {
|
||||
if (!MODEL_MAP || !MODEL_MAP[providerName]) {
|
||||
log(
|
||||
'warn',
|
||||
`Provider "${providerName}" not found in MODEL_MAP. Cannot determine cost for model ${modelId}.`
|
||||
);
|
||||
return { inputCost: 0, outputCost: 0, currency: 'USD' }; // Default to zero cost
|
||||
}
|
||||
|
||||
const modelData = MODEL_MAP[providerName].find((m) => m.id === modelId);
|
||||
|
||||
if (!modelData || !modelData.cost_per_1m_tokens) {
|
||||
log(
|
||||
'debug',
|
||||
`Cost data not found for model "${modelId}" under provider "${providerName}". Assuming zero cost.`
|
||||
);
|
||||
return { inputCost: 0, outputCost: 0, currency: 'USD' }; // Default to zero cost
|
||||
}
|
||||
|
||||
// Ensure currency is part of the returned object, defaulting if not present
|
||||
const currency = modelData.cost_per_1m_tokens.currency || 'USD';
|
||||
|
||||
return {
|
||||
inputCost: modelData.cost_per_1m_tokens.input || 0,
|
||||
outputCost: modelData.cost_per_1m_tokens.output || 0,
|
||||
currency: currency
|
||||
};
|
||||
}
|
||||
|
||||
// --- Provider Function Map ---
|
||||
// Maps provider names (lowercase) to their respective service functions
|
||||
const PROVIDER_FUNCTIONS = {
|
||||
@@ -63,6 +97,11 @@ const PROVIDER_FUNCTIONS = {
|
||||
generateText: openrouter.generateOpenRouterText,
|
||||
streamText: openrouter.streamOpenRouterText,
|
||||
generateObject: openrouter.generateOpenRouterObject
|
||||
},
|
||||
ollama: {
|
||||
generateText: ollama.generateOllamaText,
|
||||
streamText: ollama.streamOllamaText,
|
||||
generateObject: ollama.generateOllamaObject
|
||||
}
|
||||
// TODO: Add entries for ollama, etc. when implemented
|
||||
};
|
||||
@@ -150,14 +189,10 @@ function _resolveApiKey(providerName, session, projectRoot = null) {
|
||||
mistral: 'MISTRAL_API_KEY',
|
||||
azure: 'AZURE_OPENAI_API_KEY',
|
||||
openrouter: 'OPENROUTER_API_KEY',
|
||||
xai: 'XAI_API_KEY'
|
||||
xai: 'XAI_API_KEY',
|
||||
ollama: 'OLLAMA_API_KEY'
|
||||
};
|
||||
|
||||
// Double check this -- I have had to use an api key for ollama in the past
|
||||
// if (providerName === 'ollama') {
|
||||
// return null; // Ollama typically doesn't require an API key for basic setup
|
||||
// }
|
||||
|
||||
const envVarName = keyMap[providerName];
|
||||
if (!envVarName) {
|
||||
throw new Error(
|
||||
@@ -166,6 +201,13 @@ function _resolveApiKey(providerName, session, projectRoot = null) {
|
||||
}
|
||||
|
||||
const apiKey = resolveEnvVariable(envVarName, session, projectRoot);
|
||||
|
||||
// Special handling for Ollama - API key is optional
|
||||
if (providerName === 'ollama') {
|
||||
return apiKey || null;
|
||||
}
|
||||
|
||||
// For all other providers, API key is required
|
||||
if (!apiKey) {
|
||||
throw new Error(
|
||||
`Required API key ${envVarName} for provider '${providerName}' is not set in environment, session, or .env file.`
|
||||
@@ -197,18 +239,22 @@ async function _attemptProviderCallWithRetries(
|
||||
|
||||
while (retries <= MAX_RETRIES) {
|
||||
try {
|
||||
log(
|
||||
'info',
|
||||
`Attempt ${retries + 1}/${MAX_RETRIES + 1} calling ${fnName} (Provider: ${providerName}, Model: ${modelId}, Role: ${attemptRole})`
|
||||
);
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
'info',
|
||||
`Attempt ${retries + 1}/${MAX_RETRIES + 1} calling ${fnName} (Provider: ${providerName}, Model: ${modelId}, Role: ${attemptRole})`
|
||||
);
|
||||
}
|
||||
|
||||
// Call the specific provider function directly
|
||||
const result = await providerApiFn(callParams);
|
||||
|
||||
log(
|
||||
'info',
|
||||
`${fnName} succeeded for role ${attemptRole} (Provider: ${providerName}) on attempt ${retries + 1}`
|
||||
);
|
||||
if (getDebugFlag()) {
|
||||
log(
|
||||
'info',
|
||||
`${fnName} succeeded for role ${attemptRole} (Provider: ${providerName}) on attempt ${retries + 1}`
|
||||
);
|
||||
}
|
||||
return result;
|
||||
} catch (error) {
|
||||
log(
|
||||
@@ -221,13 +267,13 @@ async function _attemptProviderCallWithRetries(
|
||||
const delay = INITIAL_RETRY_DELAY_MS * Math.pow(2, retries - 1);
|
||||
log(
|
||||
'info',
|
||||
`Retryable error detected. Retrying in ${delay / 1000}s...`
|
||||
`Something went wrong on the provider side. Retrying in ${delay / 1000}s...`
|
||||
);
|
||||
await new Promise((resolve) => setTimeout(resolve, delay));
|
||||
} else {
|
||||
log(
|
||||
'error',
|
||||
`Non-retryable error or max retries reached for role ${attemptRole} (${fnName} / ${providerName}).`
|
||||
`Something went wrong on the provider side. Max retries reached for role ${attemptRole} (${fnName} / ${providerName}).`
|
||||
);
|
||||
throw error;
|
||||
}
|
||||
@@ -243,7 +289,15 @@ async function _attemptProviderCallWithRetries(
|
||||
* Base logic for unified service functions.
|
||||
* @param {string} serviceType - Type of service ('generateText', 'streamText', 'generateObject').
|
||||
* @param {object} params - Original parameters passed to the service function.
|
||||
* @param {string} params.role - The initial client role.
|
||||
* @param {object} [params.session=null] - Optional MCP session object.
|
||||
* @param {string} [params.projectRoot] - Optional project root path.
|
||||
* @param {string} params.commandName - Name of the command invoking the service.
|
||||
* @param {string} params.outputType - 'cli' or 'mcp'.
|
||||
* @param {string} [params.systemPrompt] - Optional system prompt.
|
||||
* @param {string} [params.prompt] - The prompt for the AI.
|
||||
* @param {string} [params.schema] - The Zod schema for the expected object.
|
||||
* @param {string} [params.objectName] - Name for object/tool.
|
||||
* @returns {Promise<any>} Result from the underlying provider call.
|
||||
*/
|
||||
async function _unifiedServiceRunner(serviceType, params) {
|
||||
@@ -255,15 +309,25 @@ async function _unifiedServiceRunner(serviceType, params) {
|
||||
prompt,
|
||||
schema,
|
||||
objectName,
|
||||
commandName,
|
||||
outputType,
|
||||
...restApiParams
|
||||
} = params;
|
||||
log('info', `${serviceType}Service called`, {
|
||||
role: initialRole,
|
||||
projectRoot
|
||||
});
|
||||
if (getDebugFlag()) {
|
||||
log('info', `${serviceType}Service called`, {
|
||||
role: initialRole,
|
||||
commandName,
|
||||
outputType,
|
||||
projectRoot
|
||||
});
|
||||
}
|
||||
|
||||
// Determine the effective project root (passed in or detected)
|
||||
const effectiveProjectRoot = projectRoot || findProjectRoot();
|
||||
// Determine the effective project root (passed in or detected if needed by config getters)
|
||||
const { findProjectRoot: detectProjectRoot } = await import('./utils.js'); // Dynamically import if needed
|
||||
const effectiveProjectRoot = projectRoot || detectProjectRoot();
|
||||
|
||||
// Get userId from config - ensure effectiveProjectRoot is passed
|
||||
const userId = getUserId(effectiveProjectRoot);
|
||||
|
||||
let sequence;
|
||||
if (initialRole === 'main') {
|
||||
@@ -291,7 +355,9 @@ async function _unifiedServiceRunner(serviceType, params) {
|
||||
roleParams,
|
||||
providerFnSet,
|
||||
providerApiFn,
|
||||
baseUrl;
|
||||
baseUrl,
|
||||
providerResponse,
|
||||
telemetryData = null;
|
||||
|
||||
try {
|
||||
log('info', `New AI service call with role: ${currentRole}`);
|
||||
@@ -415,7 +481,7 @@ async function _unifiedServiceRunner(serviceType, params) {
|
||||
};
|
||||
|
||||
// 6. Attempt the call with retries
|
||||
const result = await _attemptProviderCallWithRetries(
|
||||
providerResponse = await _attemptProviderCallWithRetries(
|
||||
providerApiFn,
|
||||
callParams,
|
||||
providerName,
|
||||
@@ -423,9 +489,53 @@ async function _unifiedServiceRunner(serviceType, params) {
|
||||
currentRole
|
||||
);
|
||||
|
||||
log('info', `${serviceType}Service succeeded using role: ${currentRole}`);
|
||||
// --- Log Telemetry & Capture Data ---
|
||||
// Use providerResponse which contains the usage data directly for text/object
|
||||
if (userId && providerResponse && providerResponse.usage) {
|
||||
try {
|
||||
telemetryData = await logAiUsage({
|
||||
userId,
|
||||
commandName,
|
||||
providerName,
|
||||
modelId,
|
||||
inputTokens: providerResponse.usage.inputTokens,
|
||||
outputTokens: providerResponse.usage.outputTokens,
|
||||
outputType
|
||||
});
|
||||
} catch (telemetryError) {
|
||||
// logAiUsage already logs its own errors and returns null on failure
|
||||
// No need to log again here, telemetryData will remain null
|
||||
}
|
||||
} else if (userId && providerResponse && !providerResponse.usage) {
|
||||
log(
|
||||
'warn',
|
||||
`Cannot log telemetry for ${commandName} (${providerName}/${modelId}): AI result missing 'usage' data. (May be expected for streams)`
|
||||
);
|
||||
}
|
||||
// --- End Log Telemetry ---
|
||||
|
||||
return result;
|
||||
// --- Extract the correct main result based on serviceType ---
|
||||
let finalMainResult;
|
||||
if (serviceType === 'generateText') {
|
||||
finalMainResult = providerResponse.text;
|
||||
} else if (serviceType === 'generateObject') {
|
||||
finalMainResult = providerResponse.object;
|
||||
} else if (serviceType === 'streamText') {
|
||||
finalMainResult = providerResponse; // Return the whole stream object
|
||||
} else {
|
||||
log(
|
||||
'error',
|
||||
`Unknown serviceType in _unifiedServiceRunner: ${serviceType}`
|
||||
);
|
||||
finalMainResult = providerResponse; // Default to returning the whole object as fallback
|
||||
}
|
||||
// --- End Main Result Extraction ---
|
||||
|
||||
// Return a composite object including the extracted main result and telemetry data
|
||||
return {
|
||||
mainResult: finalMainResult,
|
||||
telemetryData: telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
const cleanMessage = _extractErrorMessage(error);
|
||||
log(
|
||||
@@ -470,11 +580,16 @@ async function _unifiedServiceRunner(serviceType, params) {
|
||||
* @param {string} [params.projectRoot=null] - Optional project root path for .env fallback.
|
||||
* @param {string} params.prompt - The prompt for the AI.
|
||||
* @param {string} [params.systemPrompt] - Optional system prompt.
|
||||
* // Other specific generateText params can be included here.
|
||||
* @returns {Promise<string>} The generated text content.
|
||||
* @param {string} params.commandName - Name of the command invoking the service.
|
||||
* @param {string} [params.outputType='cli'] - 'cli' or 'mcp'.
|
||||
* @returns {Promise<object>} Result object containing generated text and usage data.
|
||||
*/
|
||||
async function generateTextService(params) {
|
||||
return _unifiedServiceRunner('generateText', params);
|
||||
// Ensure default outputType if not provided
|
||||
const defaults = { outputType: 'cli' };
|
||||
const combinedParams = { ...defaults, ...params };
|
||||
// TODO: Validate commandName exists?
|
||||
return _unifiedServiceRunner('generateText', combinedParams);
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -487,11 +602,18 @@ async function generateTextService(params) {
|
||||
* @param {string} [params.projectRoot=null] - Optional project root path for .env fallback.
|
||||
* @param {string} params.prompt - The prompt for the AI.
|
||||
* @param {string} [params.systemPrompt] - Optional system prompt.
|
||||
* // Other specific streamText params can be included here.
|
||||
* @returns {Promise<ReadableStream<string>>} A readable stream of text deltas.
|
||||
* @param {string} params.commandName - Name of the command invoking the service.
|
||||
* @param {string} [params.outputType='cli'] - 'cli' or 'mcp'.
|
||||
* @returns {Promise<object>} Result object containing the stream and usage data.
|
||||
*/
|
||||
async function streamTextService(params) {
|
||||
return _unifiedServiceRunner('streamText', params);
|
||||
const defaults = { outputType: 'cli' };
|
||||
const combinedParams = { ...defaults, ...params };
|
||||
// TODO: Validate commandName exists?
|
||||
// NOTE: Telemetry for streaming might be tricky as usage data often comes at the end.
|
||||
// The current implementation logs *after* the stream is returned.
|
||||
// We might need to adjust how usage is captured/logged for streams.
|
||||
return _unifiedServiceRunner('streamText', combinedParams);
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -507,15 +629,89 @@ async function streamTextService(params) {
|
||||
* @param {string} [params.systemPrompt] - Optional system prompt.
|
||||
* @param {string} [params.objectName='generated_object'] - Name for object/tool.
|
||||
* @param {number} [params.maxRetries=3] - Max retries for object generation.
|
||||
* @returns {Promise<object>} The generated object matching the schema.
|
||||
* @param {string} params.commandName - Name of the command invoking the service.
|
||||
* @param {string} [params.outputType='cli'] - 'cli' or 'mcp'.
|
||||
* @returns {Promise<object>} Result object containing the generated object and usage data.
|
||||
*/
|
||||
async function generateObjectService(params) {
|
||||
const defaults = {
|
||||
objectName: 'generated_object',
|
||||
maxRetries: 3
|
||||
maxRetries: 3,
|
||||
outputType: 'cli'
|
||||
};
|
||||
const combinedParams = { ...defaults, ...params };
|
||||
// TODO: Validate commandName exists?
|
||||
return _unifiedServiceRunner('generateObject', combinedParams);
|
||||
}
|
||||
|
||||
export { generateTextService, streamTextService, generateObjectService };
|
||||
// --- Telemetry Function ---
|
||||
/**
|
||||
* Logs AI usage telemetry data.
|
||||
* For now, it just logs to the console. Sending will be implemented later.
|
||||
* @param {object} params - Telemetry parameters.
|
||||
* @param {string} params.userId - Unique user identifier.
|
||||
* @param {string} params.commandName - The command that triggered the AI call.
|
||||
* @param {string} params.providerName - The AI provider used (e.g., 'openai').
|
||||
* @param {string} params.modelId - The specific AI model ID used.
|
||||
* @param {number} params.inputTokens - Number of input tokens.
|
||||
* @param {number} params.outputTokens - Number of output tokens.
|
||||
*/
|
||||
async function logAiUsage({
|
||||
userId,
|
||||
commandName,
|
||||
providerName,
|
||||
modelId,
|
||||
inputTokens,
|
||||
outputTokens,
|
||||
outputType
|
||||
}) {
|
||||
try {
|
||||
const isMCP = outputType === 'mcp';
|
||||
const timestamp = new Date().toISOString();
|
||||
const totalTokens = (inputTokens || 0) + (outputTokens || 0);
|
||||
|
||||
// Destructure currency along with costs
|
||||
const { inputCost, outputCost, currency } = _getCostForModel(
|
||||
providerName,
|
||||
modelId
|
||||
);
|
||||
|
||||
const totalCost =
|
||||
((inputTokens || 0) / 1_000_000) * inputCost +
|
||||
((outputTokens || 0) / 1_000_000) * outputCost;
|
||||
|
||||
const telemetryData = {
|
||||
timestamp,
|
||||
userId,
|
||||
commandName,
|
||||
modelUsed: modelId, // Consistent field name from requirements
|
||||
providerName, // Keep provider name for context
|
||||
inputTokens: inputTokens || 0,
|
||||
outputTokens: outputTokens || 0,
|
||||
totalTokens,
|
||||
totalCost: parseFloat(totalCost.toFixed(6)),
|
||||
currency // Add currency to the telemetry data
|
||||
};
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log('info', 'AI Usage Telemetry:', telemetryData);
|
||||
}
|
||||
|
||||
// TODO (Subtask 77.2): Send telemetryData securely to the external endpoint.
|
||||
|
||||
return telemetryData;
|
||||
} catch (error) {
|
||||
log('error', `Failed to log AI usage telemetry: ${error.message}`, {
|
||||
error
|
||||
});
|
||||
// Don't re-throw; telemetry failure shouldn't block core functionality.
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
export {
|
||||
generateTextService,
|
||||
streamTextService,
|
||||
generateObjectService,
|
||||
logAiUsage
|
||||
};
|
||||
|
||||
@@ -62,7 +62,8 @@ import {
|
||||
stopLoadingIndicator,
|
||||
displayModelConfiguration,
|
||||
displayAvailableModels,
|
||||
displayApiKeyStatus
|
||||
displayApiKeyStatus,
|
||||
displayAiUsageSummary
|
||||
} from './ui.js';
|
||||
|
||||
import { initializeProject } from '../init.js';
|
||||
@@ -515,7 +516,7 @@ function registerCommands(programInstance) {
|
||||
const force = options.force || false;
|
||||
const append = options.append || false;
|
||||
let useForce = force;
|
||||
let useAppend = false;
|
||||
let useAppend = append;
|
||||
|
||||
// Helper function to check if tasks.json exists and confirm overwrite
|
||||
async function confirmOverwriteIfNeeded() {
|
||||
@@ -543,10 +544,10 @@ function registerCommands(programInstance) {
|
||||
if (!(await confirmOverwriteIfNeeded())) return;
|
||||
|
||||
console.log(chalk.blue(`Generating ${numTasks} tasks...`));
|
||||
spinner = ora('Parsing PRD and generating tasks...').start();
|
||||
spinner = ora('Parsing PRD and generating tasks...\n').start();
|
||||
await parsePRD(defaultPrdPath, outputPath, numTasks, {
|
||||
useAppend,
|
||||
useForce
|
||||
append: useAppend, // Changed key from useAppend to append
|
||||
force: useForce // Changed key from useForce to force
|
||||
});
|
||||
spinner.succeed('Tasks generated successfully!');
|
||||
return;
|
||||
@@ -605,10 +606,10 @@ function registerCommands(programInstance) {
|
||||
console.log(chalk.blue('Appending to existing tasks...'));
|
||||
}
|
||||
|
||||
spinner = ora('Parsing PRD and generating tasks...').start();
|
||||
spinner = ora('Parsing PRD and generating tasks...\n').start();
|
||||
await parsePRD(inputFile, outputPath, numTasks, {
|
||||
append: useAppend,
|
||||
useForce
|
||||
useAppend: useAppend,
|
||||
useForce: useForce
|
||||
});
|
||||
spinner.succeed('Tasks generated successfully!');
|
||||
} catch (error) {
|
||||
@@ -1072,10 +1073,16 @@ function registerCommands(programInstance) {
|
||||
.command('list')
|
||||
.description('List all tasks')
|
||||
.option('-f, --file <file>', 'Path to the tasks file', 'tasks/tasks.json')
|
||||
.option(
|
||||
'-r, --report <report>',
|
||||
'Path to the complexity report file',
|
||||
'scripts/task-complexity-report.json'
|
||||
)
|
||||
.option('-s, --status <status>', 'Filter by status')
|
||||
.option('--with-subtasks', 'Show subtasks for each task')
|
||||
.action(async (options) => {
|
||||
const tasksPath = options.file;
|
||||
const reportPath = options.report;
|
||||
const statusFilter = options.status;
|
||||
const withSubtasks = options.withSubtasks || false;
|
||||
|
||||
@@ -1087,7 +1094,7 @@ function registerCommands(programInstance) {
|
||||
console.log(chalk.blue('Including subtasks in listing'));
|
||||
}
|
||||
|
||||
await listTasks(tasksPath, statusFilter, withSubtasks);
|
||||
await listTasks(tasksPath, statusFilter, reportPath, withSubtasks);
|
||||
});
|
||||
|
||||
// expand command
|
||||
@@ -1137,12 +1144,6 @@ function registerCommands(programInstance) {
|
||||
{} // Pass empty context for CLI calls
|
||||
// outputFormat defaults to 'text' in expandAllTasks for CLI
|
||||
);
|
||||
// Optional: Display summary from result
|
||||
console.log(chalk.green(`Expansion Summary:`));
|
||||
console.log(chalk.green(` - Attempted: ${result.tasksToExpand}`));
|
||||
console.log(chalk.green(` - Expanded: ${result.expandedCount}`));
|
||||
console.log(chalk.yellow(` - Skipped: ${result.skippedCount}`));
|
||||
console.log(chalk.red(` - Failed: ${result.failedCount}`));
|
||||
} catch (error) {
|
||||
console.error(
|
||||
chalk.red(`Error expanding all tasks: ${error.message}`)
|
||||
@@ -1272,7 +1273,7 @@ function registerCommands(programInstance) {
|
||||
// add-task command
|
||||
programInstance
|
||||
.command('add-task')
|
||||
.description('Add a new task using AI or manual input')
|
||||
.description('Add a new task using AI, optionally providing manual details')
|
||||
.option('-f, --file <file>', 'Path to the tasks file', 'tasks/tasks.json')
|
||||
.option(
|
||||
'-p, --prompt <prompt>',
|
||||
@@ -1313,74 +1314,70 @@ function registerCommands(programInstance) {
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const tasksPath =
|
||||
options.file ||
|
||||
path.join(findProjectRoot() || '.', 'tasks', 'tasks.json') || // Ensure tasksPath is also relative to a found root or current dir
|
||||
'tasks/tasks.json';
|
||||
|
||||
// Correctly determine projectRoot
|
||||
const projectRoot = findProjectRoot();
|
||||
|
||||
let manualTaskData = null;
|
||||
if (isManualCreation) {
|
||||
manualTaskData = {
|
||||
title: options.title,
|
||||
description: options.description,
|
||||
details: options.details || '',
|
||||
testStrategy: options.testStrategy || ''
|
||||
};
|
||||
// Restore specific logging for manual creation
|
||||
console.log(
|
||||
chalk.blue(`Creating task manually with title: "${options.title}"`)
|
||||
);
|
||||
} else {
|
||||
// Restore specific logging for AI creation
|
||||
console.log(
|
||||
chalk.blue(`Creating task with AI using prompt: "${options.prompt}"`)
|
||||
);
|
||||
}
|
||||
|
||||
// Log dependencies and priority if provided (restored)
|
||||
const dependenciesArray = options.dependencies
|
||||
? options.dependencies.split(',').map((id) => id.trim())
|
||||
: [];
|
||||
if (dependenciesArray.length > 0) {
|
||||
console.log(
|
||||
chalk.blue(`Dependencies: [${dependenciesArray.join(', ')}]`)
|
||||
);
|
||||
}
|
||||
if (options.priority) {
|
||||
console.log(chalk.blue(`Priority: ${options.priority}`));
|
||||
}
|
||||
|
||||
const context = {
|
||||
projectRoot,
|
||||
commandName: 'add-task',
|
||||
outputType: 'cli'
|
||||
};
|
||||
|
||||
try {
|
||||
// Prepare dependencies if provided
|
||||
let dependencies = [];
|
||||
if (options.dependencies) {
|
||||
dependencies = options.dependencies
|
||||
.split(',')
|
||||
.map((id) => parseInt(id.trim(), 10));
|
||||
}
|
||||
|
||||
// Create manual task data if title and description are provided
|
||||
let manualTaskData = null;
|
||||
if (isManualCreation) {
|
||||
manualTaskData = {
|
||||
title: options.title,
|
||||
description: options.description,
|
||||
details: options.details || '',
|
||||
testStrategy: options.testStrategy || ''
|
||||
};
|
||||
|
||||
console.log(
|
||||
chalk.blue(`Creating task manually with title: "${options.title}"`)
|
||||
);
|
||||
if (dependencies.length > 0) {
|
||||
console.log(
|
||||
chalk.blue(`Dependencies: [${dependencies.join(', ')}]`)
|
||||
);
|
||||
}
|
||||
if (options.priority) {
|
||||
console.log(chalk.blue(`Priority: ${options.priority}`));
|
||||
}
|
||||
} else {
|
||||
console.log(
|
||||
chalk.blue(
|
||||
`Creating task with AI using prompt: "${options.prompt}"`
|
||||
)
|
||||
);
|
||||
if (dependencies.length > 0) {
|
||||
console.log(
|
||||
chalk.blue(`Dependencies: [${dependencies.join(', ')}]`)
|
||||
);
|
||||
}
|
||||
if (options.priority) {
|
||||
console.log(chalk.blue(`Priority: ${options.priority}`));
|
||||
}
|
||||
}
|
||||
|
||||
// Pass mcpLog and session for MCP mode
|
||||
const newTaskId = await addTask(
|
||||
options.file,
|
||||
options.prompt, // Pass prompt (will be null/undefined if not provided)
|
||||
dependencies,
|
||||
const { newTaskId, telemetryData } = await addTask(
|
||||
tasksPath,
|
||||
options.prompt,
|
||||
dependenciesArray,
|
||||
options.priority,
|
||||
{
|
||||
// For CLI, session context isn't directly available like MCP
|
||||
// We don't need to pass session here for CLI API key resolution
|
||||
// as dotenv loads .env, and utils.resolveEnvVariable checks process.env
|
||||
},
|
||||
'text', // outputFormat
|
||||
manualTaskData, // Pass the potentially created manualTaskData object
|
||||
options.research || false // Pass the research flag value
|
||||
context,
|
||||
'text',
|
||||
manualTaskData,
|
||||
options.research
|
||||
);
|
||||
|
||||
console.log(chalk.green(`✓ Added new task #${newTaskId}`));
|
||||
console.log(chalk.gray('Next: Complete this task or add more tasks'));
|
||||
// addTask handles detailed CLI success logging AND telemetry display when outputFormat is 'text'
|
||||
// No need to call displayAiUsageSummary here anymore.
|
||||
} catch (error) {
|
||||
console.error(chalk.red(`Error adding task: ${error.message}`));
|
||||
if (error.stack && getDebugFlag()) {
|
||||
console.error(error.stack);
|
||||
if (error.details) {
|
||||
console.error(chalk.red(error.details));
|
||||
}
|
||||
process.exit(1);
|
||||
}
|
||||
@@ -1393,9 +1390,15 @@ function registerCommands(programInstance) {
|
||||
`Show the next task to work on based on dependencies and status${chalk.reset('')}`
|
||||
)
|
||||
.option('-f, --file <file>', 'Path to the tasks file', 'tasks/tasks.json')
|
||||
.option(
|
||||
'-r, --report <report>',
|
||||
'Path to the complexity report file',
|
||||
'scripts/task-complexity-report.json'
|
||||
)
|
||||
.action(async (options) => {
|
||||
const tasksPath = options.file;
|
||||
await displayNextTask(tasksPath);
|
||||
const reportPath = options.report;
|
||||
await displayNextTask(tasksPath, reportPath);
|
||||
});
|
||||
|
||||
// show command
|
||||
@@ -1408,6 +1411,11 @@ function registerCommands(programInstance) {
|
||||
.option('-i, --id <id>', 'Task ID to show')
|
||||
.option('-s, --status <status>', 'Filter subtasks by status') // ADDED status option
|
||||
.option('-f, --file <file>', 'Path to the tasks file', 'tasks/tasks.json')
|
||||
.option(
|
||||
'-r, --report <report>',
|
||||
'Path to the complexity report file',
|
||||
'scripts/task-complexity-report.json'
|
||||
)
|
||||
.action(async (taskId, options) => {
|
||||
const idArg = taskId || options.id;
|
||||
const statusFilter = options.status; // ADDED: Capture status filter
|
||||
@@ -1418,8 +1426,9 @@ function registerCommands(programInstance) {
|
||||
}
|
||||
|
||||
const tasksPath = options.file;
|
||||
const reportPath = options.report;
|
||||
// PASS statusFilter to the display function
|
||||
await displayTaskById(tasksPath, idArg, statusFilter);
|
||||
await displayTaskById(tasksPath, idArg, reportPath, statusFilter);
|
||||
});
|
||||
|
||||
// add-dependency command
|
||||
@@ -2075,7 +2084,7 @@ function registerCommands(programInstance) {
|
||||
);
|
||||
|
||||
// Exit with error if any removals failed
|
||||
if (successfulRemovals.length === 0) {
|
||||
if (result.removedTasks.length === 0) {
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -669,6 +669,34 @@ function isConfigFilePresent(explicitRoot = null) {
|
||||
return fs.existsSync(configPath);
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets the user ID from the configuration.
|
||||
* @param {string|null} explicitRoot - Optional explicit path to the project root.
|
||||
* @returns {string|null} The user ID or null if not found.
|
||||
*/
|
||||
function getUserId(explicitRoot = null) {
|
||||
const config = getConfig(explicitRoot);
|
||||
if (!config.global) {
|
||||
config.global = {}; // Ensure global object exists
|
||||
}
|
||||
if (!config.global.userId) {
|
||||
config.global.userId = '1234567890';
|
||||
// Attempt to write the updated config.
|
||||
// It's important that writeConfig correctly resolves the path
|
||||
// using explicitRoot, similar to how getConfig does.
|
||||
const success = writeConfig(config, explicitRoot);
|
||||
if (!success) {
|
||||
// Log an error or handle the failure to write,
|
||||
// though for now, we'll proceed with the in-memory default.
|
||||
log(
|
||||
'warning',
|
||||
'Failed to write updated configuration with new userId. Please let the developers know.'
|
||||
);
|
||||
}
|
||||
}
|
||||
return config.global.userId;
|
||||
}
|
||||
|
||||
/**
|
||||
* Gets a list of all provider names defined in the MODEL_MAP.
|
||||
* @returns {string[]} An array of provider names.
|
||||
@@ -688,8 +716,8 @@ export {
|
||||
// Core config access
|
||||
getConfig,
|
||||
writeConfig,
|
||||
ConfigurationError, // Export custom error type
|
||||
isConfigFilePresent, // Add the new function export
|
||||
ConfigurationError,
|
||||
isConfigFilePresent,
|
||||
|
||||
// Validation
|
||||
validateProvider,
|
||||
@@ -722,7 +750,7 @@ export {
|
||||
getProjectName,
|
||||
getOllamaBaseUrl,
|
||||
getParametersForRole,
|
||||
|
||||
getUserId,
|
||||
// API Key Checkers (still relevant)
|
||||
isApiKeySet,
|
||||
getMcpApiKeyStatus,
|
||||
|
||||
@@ -99,34 +99,39 @@
|
||||
],
|
||||
"google": [
|
||||
{
|
||||
"id": "gemini-2.5-pro-exp-03-25",
|
||||
"id": "gemini-2.5-pro-preview-05-06",
|
||||
"swe_score": 0.638,
|
||||
"cost_per_1m_tokens": null,
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"max_tokens": 1048000
|
||||
},
|
||||
{
|
||||
"id": "gemini-2.5-pro-preview-03-25",
|
||||
"swe_score": 0.638,
|
||||
"cost_per_1m_tokens": null,
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"max_tokens": 1048000
|
||||
},
|
||||
{
|
||||
"id": "gemini-2.5-flash-preview-04-17",
|
||||
"swe_score": 0,
|
||||
"cost_per_1m_tokens": null,
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"max_tokens": 1048000
|
||||
},
|
||||
{
|
||||
"id": "gemini-2.0-flash",
|
||||
"swe_score": 0.754,
|
||||
"cost_per_1m_tokens": { "input": 0.15, "output": 0.6 },
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"max_tokens": 1048000
|
||||
},
|
||||
{
|
||||
"id": "gemini-2.0-flash-thinking-experimental",
|
||||
"swe_score": 0.754,
|
||||
"cost_per_1m_tokens": { "input": 0.15, "output": 0.6 },
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
},
|
||||
{
|
||||
"id": "gemini-2.0-pro",
|
||||
"id": "gemini-2.0-flash-lite",
|
||||
"swe_score": 0,
|
||||
"cost_per_1m_tokens": null,
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
"allowed_roles": ["main", "fallback"],
|
||||
"max_tokens": 1048000
|
||||
}
|
||||
],
|
||||
"perplexity": [
|
||||
|
||||
@@ -23,7 +23,7 @@ import updateSubtaskById from './task-manager/update-subtask-by-id.js';
|
||||
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 { readComplexityReport } from './utils.js';
|
||||
// Export task manager functions
|
||||
export {
|
||||
parsePRD,
|
||||
@@ -45,5 +45,6 @@ export {
|
||||
removeTask,
|
||||
findTaskById,
|
||||
taskExists,
|
||||
isTaskDependentOn
|
||||
isTaskDependentOn,
|
||||
readComplexityReport
|
||||
};
|
||||
|
||||
@@ -8,7 +8,8 @@ import {
|
||||
displayBanner,
|
||||
getStatusWithColor,
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
import { readJSON, writeJSON, log as consoleLog, truncate } from '../utils.js';
|
||||
import { generateObjectService } from '../ai-services-unified.js';
|
||||
@@ -44,7 +45,9 @@ const AiTaskDataSchema = z.object({
|
||||
* @param {boolean} useResearch - Whether to use the research model (passed to unified service)
|
||||
* @param {Object} context - Context object containing session and potentially projectRoot
|
||||
* @param {string} [context.projectRoot] - Project root path (for MCP/env fallback)
|
||||
* @returns {number} The new task ID
|
||||
* @param {string} [context.commandName] - The name of the command being executed (for telemetry)
|
||||
* @param {string} [context.outputType] - The output type ('cli' or 'mcp', for telemetry)
|
||||
* @returns {Promise<object>} An object containing newTaskId and telemetryData
|
||||
*/
|
||||
async function addTask(
|
||||
tasksPath,
|
||||
@@ -56,7 +59,7 @@ async function addTask(
|
||||
manualTaskData = null,
|
||||
useResearch = false
|
||||
) {
|
||||
const { session, mcpLog, projectRoot } = context;
|
||||
const { session, mcpLog, projectRoot, commandName, outputType } = context;
|
||||
const isMCP = !!mcpLog;
|
||||
|
||||
// Create a consistent logFn object regardless of context
|
||||
@@ -78,6 +81,7 @@ async function addTask(
|
||||
);
|
||||
|
||||
let loadingIndicator = null;
|
||||
let aiServiceResponse = null; // To store the full response from AI service
|
||||
|
||||
// Create custom reporter that checks for MCP log
|
||||
const report = (message, level = 'info') => {
|
||||
@@ -89,20 +93,6 @@ async function addTask(
|
||||
};
|
||||
|
||||
try {
|
||||
// Only display banner and UI elements for text output (CLI)
|
||||
if (outputFormat === 'text') {
|
||||
displayBanner();
|
||||
|
||||
console.log(
|
||||
boxen(chalk.white.bold(`Creating New Task`), {
|
||||
padding: 1,
|
||||
borderColor: 'blue',
|
||||
borderStyle: 'round',
|
||||
margin: { top: 1, bottom: 1 }
|
||||
})
|
||||
);
|
||||
}
|
||||
|
||||
// Read the existing tasks
|
||||
const data = readJSON(tasksPath);
|
||||
if (!data || !data.tasks) {
|
||||
@@ -169,7 +159,7 @@ async function addTask(
|
||||
} else {
|
||||
report('DEBUG: Taking AI task generation path.', 'debug');
|
||||
// --- Refactored AI Interaction ---
|
||||
report('Generating task data with AI...', 'info');
|
||||
report(`Generating task data with AI with prompt:\n${prompt}`, 'info');
|
||||
|
||||
// Create context string for task creation prompt
|
||||
let contextTasks = '';
|
||||
@@ -229,29 +219,51 @@ async function addTask(
|
||||
// Start the loading indicator - only for text mode
|
||||
if (outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
`Generating new task with ${useResearch ? 'Research' : 'Main'} AI...`
|
||||
`Generating new task with ${useResearch ? 'Research' : 'Main'} AI...\n`
|
||||
);
|
||||
}
|
||||
|
||||
try {
|
||||
// Determine the service role based on the useResearch flag
|
||||
const serviceRole = useResearch ? 'research' : 'main';
|
||||
|
||||
report('DEBUG: Calling generateObjectService...', 'debug');
|
||||
// Call the unified AI service
|
||||
const aiGeneratedTaskData = await generateObjectService({
|
||||
role: serviceRole, // <-- Use the determined role
|
||||
session: session, // Pass session for API key resolution
|
||||
projectRoot: projectRoot, // <<< Pass projectRoot here
|
||||
schema: AiTaskDataSchema, // Pass the Zod schema
|
||||
objectName: 'newTaskData', // Name for the object
|
||||
|
||||
aiServiceResponse = await generateObjectService({
|
||||
// Capture the full response
|
||||
role: serviceRole,
|
||||
session: session,
|
||||
projectRoot: projectRoot,
|
||||
schema: AiTaskDataSchema,
|
||||
objectName: 'newTaskData',
|
||||
systemPrompt: systemPrompt,
|
||||
prompt: userPrompt
|
||||
prompt: userPrompt,
|
||||
commandName: commandName || 'add-task', // Use passed commandName or default
|
||||
outputType: outputType || (isMCP ? 'mcp' : 'cli') // Use passed outputType or derive
|
||||
});
|
||||
report('DEBUG: generateObjectService returned successfully.', 'debug');
|
||||
|
||||
if (!aiServiceResponse || !aiServiceResponse.mainResult) {
|
||||
throw new Error(
|
||||
'AI service did not return the expected object structure.'
|
||||
);
|
||||
}
|
||||
|
||||
// Prefer mainResult if it looks like a valid task object, otherwise try mainResult.object
|
||||
if (
|
||||
aiServiceResponse.mainResult.title &&
|
||||
aiServiceResponse.mainResult.description
|
||||
) {
|
||||
taskData = aiServiceResponse.mainResult;
|
||||
} else if (
|
||||
aiServiceResponse.mainResult.object &&
|
||||
aiServiceResponse.mainResult.object.title &&
|
||||
aiServiceResponse.mainResult.object.description
|
||||
) {
|
||||
taskData = aiServiceResponse.mainResult.object;
|
||||
} else {
|
||||
throw new Error('AI service did not return a valid task object.');
|
||||
}
|
||||
|
||||
report('Successfully generated task data from AI.', 'success');
|
||||
taskData = aiGeneratedTaskData; // Assign the validated object
|
||||
} catch (error) {
|
||||
report(
|
||||
`DEBUG: generateObjectService caught error: ${error.message}`,
|
||||
@@ -362,11 +374,25 @@ async function addTask(
|
||||
{ padding: 1, borderColor: 'green', borderStyle: 'round' }
|
||||
)
|
||||
);
|
||||
|
||||
// Display AI Usage Summary if telemetryData is available
|
||||
if (
|
||||
aiServiceResponse &&
|
||||
aiServiceResponse.telemetryData &&
|
||||
(outputType === 'cli' || outputType === 'text')
|
||||
) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
}
|
||||
|
||||
// Return the new task ID
|
||||
report(`DEBUG: Returning new task ID: ${newTaskId}`, 'debug');
|
||||
return newTaskId;
|
||||
report(
|
||||
`DEBUG: Returning new task ID: ${newTaskId} and telemetry.`,
|
||||
'debug'
|
||||
);
|
||||
return {
|
||||
newTaskId: newTaskId,
|
||||
telemetryData: aiServiceResponse ? aiServiceResponse.telemetryData : null
|
||||
};
|
||||
} catch (error) {
|
||||
// Stop any loading indicator on error
|
||||
if (loadingIndicator) {
|
||||
|
||||
@@ -4,7 +4,11 @@ import readline from 'readline';
|
||||
|
||||
import { log, readJSON, writeJSON, isSilentMode } from '../utils.js';
|
||||
|
||||
import { startLoadingIndicator, stopLoadingIndicator } from '../ui.js';
|
||||
import {
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
|
||||
@@ -196,35 +200,32 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
}
|
||||
|
||||
const prompt = generateInternalComplexityAnalysisPrompt(tasksData);
|
||||
// System prompt remains simple for text generation
|
||||
const systemPrompt =
|
||||
'You are an expert software architect and project manager analyzing task complexity. Respond only with the requested valid JSON array.';
|
||||
|
||||
let loadingIndicator = null;
|
||||
if (outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator('Calling AI service...');
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
`${useResearch ? 'Researching' : 'Analyzing'} the complexity of your tasks with AI...\n`
|
||||
);
|
||||
}
|
||||
|
||||
let fullResponse = ''; // To store the raw text response
|
||||
let aiServiceResponse = null;
|
||||
let complexityAnalysis = null;
|
||||
|
||||
try {
|
||||
const role = useResearch ? 'research' : 'main';
|
||||
reportLog(`Using AI service with role: ${role}`, 'info');
|
||||
|
||||
fullResponse = await generateTextService({
|
||||
aiServiceResponse = await generateTextService({
|
||||
prompt,
|
||||
systemPrompt,
|
||||
role,
|
||||
session,
|
||||
projectRoot
|
||||
projectRoot,
|
||||
commandName: 'analyze-complexity',
|
||||
outputType: mcpLog ? 'mcp' : 'cli'
|
||||
});
|
||||
|
||||
reportLog(
|
||||
'Successfully received text response via AI service',
|
||||
'success'
|
||||
);
|
||||
|
||||
// --- Stop Loading Indicator (Unchanged) ---
|
||||
if (loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
loadingIndicator = null;
|
||||
@@ -236,26 +237,18 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
chalk.green('AI service call complete. Parsing response...')
|
||||
);
|
||||
}
|
||||
// --- End Stop Loading Indicator ---
|
||||
|
||||
// --- Re-introduce Manual JSON Parsing & Cleanup ---
|
||||
reportLog(`Parsing complexity analysis from text response...`, 'info');
|
||||
let complexityAnalysis;
|
||||
try {
|
||||
let cleanedResponse = fullResponse;
|
||||
// Basic trim first
|
||||
let cleanedResponse = aiServiceResponse.mainResult;
|
||||
cleanedResponse = cleanedResponse.trim();
|
||||
|
||||
// Remove potential markdown code block fences
|
||||
const codeBlockMatch = cleanedResponse.match(
|
||||
/```(?:json)?\s*([\s\S]*?)\s*```/
|
||||
);
|
||||
if (codeBlockMatch) {
|
||||
cleanedResponse = codeBlockMatch[1].trim(); // Trim content inside block
|
||||
reportLog('Extracted JSON from code block', 'info');
|
||||
cleanedResponse = codeBlockMatch[1].trim();
|
||||
} else {
|
||||
// If no code block, ensure it starts with '[' and ends with ']'
|
||||
// This is less robust but a common fallback
|
||||
const firstBracket = cleanedResponse.indexOf('[');
|
||||
const lastBracket = cleanedResponse.lastIndexOf(']');
|
||||
if (firstBracket !== -1 && lastBracket > firstBracket) {
|
||||
@@ -263,13 +256,11 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
firstBracket,
|
||||
lastBracket + 1
|
||||
);
|
||||
reportLog('Extracted content between first [ and last ]', 'info');
|
||||
} else {
|
||||
reportLog(
|
||||
'Warning: Response does not appear to be a JSON array.',
|
||||
'warn'
|
||||
);
|
||||
// Keep going, maybe JSON.parse can handle it or will fail informatively
|
||||
}
|
||||
}
|
||||
|
||||
@@ -283,48 +274,23 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
);
|
||||
}
|
||||
|
||||
try {
|
||||
complexityAnalysis = JSON.parse(cleanedResponse);
|
||||
} catch (jsonError) {
|
||||
reportLog(
|
||||
'Initial JSON parsing failed. Raw response might be malformed.',
|
||||
'error'
|
||||
);
|
||||
reportLog(`Original JSON Error: ${jsonError.message}`, 'error');
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log(chalk.red('--- Start Raw Malformed Response ---'));
|
||||
console.log(chalk.gray(fullResponse));
|
||||
console.log(chalk.red('--- End Raw Malformed Response ---'));
|
||||
}
|
||||
// Re-throw the specific JSON parsing error
|
||||
throw new Error(
|
||||
`Failed to parse JSON response: ${jsonError.message}`
|
||||
);
|
||||
}
|
||||
|
||||
// Ensure it's an array after parsing
|
||||
if (!Array.isArray(complexityAnalysis)) {
|
||||
throw new Error('Parsed response is not a valid JSON array.');
|
||||
}
|
||||
} catch (error) {
|
||||
// Catch errors specifically from the parsing/cleanup block
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator); // Ensure indicator stops
|
||||
complexityAnalysis = JSON.parse(cleanedResponse);
|
||||
} catch (parseError) {
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
reportLog(
|
||||
`Error parsing complexity analysis JSON: ${error.message}`,
|
||||
`Error parsing complexity analysis JSON: ${parseError.message}`,
|
||||
'error'
|
||||
);
|
||||
if (outputFormat === 'text') {
|
||||
console.error(
|
||||
chalk.red(
|
||||
`Error parsing complexity analysis JSON: ${error.message}`
|
||||
`Error parsing complexity analysis JSON: ${parseError.message}`
|
||||
)
|
||||
);
|
||||
}
|
||||
throw error; // Re-throw parsing error
|
||||
throw parseError;
|
||||
}
|
||||
// --- End Manual JSON Parsing & Cleanup ---
|
||||
|
||||
// --- Post-processing (Missing Task Check) - (Unchanged) ---
|
||||
const taskIds = tasksData.tasks.map((t) => t.id);
|
||||
const analysisTaskIds = complexityAnalysis.map((a) => a.taskId);
|
||||
const missingTaskIds = taskIds.filter(
|
||||
@@ -359,10 +325,8 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
}
|
||||
}
|
||||
}
|
||||
// --- End Post-processing ---
|
||||
|
||||
// --- Report Creation & Writing (Unchanged) ---
|
||||
const finalReport = {
|
||||
const report = {
|
||||
meta: {
|
||||
generatedAt: new Date().toISOString(),
|
||||
tasksAnalyzed: tasksData.tasks.length,
|
||||
@@ -373,15 +337,13 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
complexityAnalysis: complexityAnalysis
|
||||
};
|
||||
reportLog(`Writing complexity report to ${outputPath}...`, 'info');
|
||||
writeJSON(outputPath, finalReport);
|
||||
writeJSON(outputPath, report);
|
||||
|
||||
reportLog(
|
||||
`Task complexity analysis complete. Report written to ${outputPath}`,
|
||||
'success'
|
||||
);
|
||||
// --- End Report Creation & Writing ---
|
||||
|
||||
// --- Display CLI Summary (Unchanged) ---
|
||||
if (outputFormat === 'text') {
|
||||
console.log(
|
||||
chalk.green(
|
||||
@@ -435,23 +397,28 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
if (getDebugFlag(session)) {
|
||||
console.debug(
|
||||
chalk.gray(
|
||||
`Final analysis object: ${JSON.stringify(finalReport, null, 2)}`
|
||||
`Final analysis object: ${JSON.stringify(report, null, 2)}`
|
||||
)
|
||||
);
|
||||
}
|
||||
}
|
||||
// --- End Display CLI Summary ---
|
||||
|
||||
return finalReport;
|
||||
} catch (error) {
|
||||
// Catches errors from generateTextService call
|
||||
if (aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
}
|
||||
|
||||
return {
|
||||
report: report,
|
||||
telemetryData: aiServiceResponse?.telemetryData
|
||||
};
|
||||
} catch (aiError) {
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
reportLog(`Error during AI service call: ${error.message}`, 'error');
|
||||
reportLog(`Error during AI service call: ${aiError.message}`, 'error');
|
||||
if (outputFormat === 'text') {
|
||||
console.error(
|
||||
chalk.red(`Error during AI service call: ${error.message}`)
|
||||
chalk.red(`Error during AI service call: ${aiError.message}`)
|
||||
);
|
||||
if (error.message.includes('API key')) {
|
||||
if (aiError.message.includes('API key')) {
|
||||
console.log(
|
||||
chalk.yellow(
|
||||
'\nPlease ensure your API keys are correctly configured in .env or ~/.taskmaster/.env'
|
||||
@@ -462,10 +429,9 @@ async function analyzeTaskComplexity(options, context = {}) {
|
||||
);
|
||||
}
|
||||
}
|
||||
throw error; // Re-throw AI service error
|
||||
throw aiError;
|
||||
}
|
||||
} catch (error) {
|
||||
// Catches general errors (file read, etc.)
|
||||
reportLog(`Error analyzing task complexity: ${error.message}`, 'error');
|
||||
if (outputFormat === 'text') {
|
||||
console.error(
|
||||
|
||||
@@ -1,7 +1,14 @@
|
||||
import { log, readJSON, isSilentMode } from '../utils.js';
|
||||
import { startLoadingIndicator, stopLoadingIndicator } from '../ui.js';
|
||||
import {
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
import expandTask from './expand-task.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
import { aggregateTelemetry } from '../utils.js';
|
||||
import chalk from 'chalk';
|
||||
import boxen from 'boxen';
|
||||
|
||||
/**
|
||||
* Expand all eligible pending or in-progress tasks using the expandTask function.
|
||||
@@ -14,7 +21,7 @@ import { getDebugFlag } from '../config-manager.js';
|
||||
* @param {Object} [context.session] - Session object from MCP.
|
||||
* @param {Object} [context.mcpLog] - MCP logger object.
|
||||
* @param {string} [outputFormat='text'] - Output format ('text' or 'json'). MCP calls should use 'json'.
|
||||
* @returns {Promise<{success: boolean, expandedCount: number, failedCount: number, skippedCount: number, tasksToExpand: number, message?: string}>} - Result summary.
|
||||
* @returns {Promise<{success: boolean, expandedCount: number, failedCount: number, skippedCount: number, tasksToExpand: number, telemetryData: Array<Object>}>} - Result summary.
|
||||
*/
|
||||
async function expandAllTasks(
|
||||
tasksPath,
|
||||
@@ -51,8 +58,8 @@ async function expandAllTasks(
|
||||
let loadingIndicator = null;
|
||||
let expandedCount = 0;
|
||||
let failedCount = 0;
|
||||
// No skipped count needed now as the filter handles it upfront
|
||||
let tasksToExpandCount = 0; // Renamed for clarity
|
||||
let tasksToExpandCount = 0;
|
||||
const allTelemetryData = []; // Still collect individual data first
|
||||
|
||||
if (!isMCPCall && outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
@@ -90,6 +97,7 @@ async function expandAllTasks(
|
||||
failedCount: 0,
|
||||
skippedCount: 0,
|
||||
tasksToExpand: 0,
|
||||
telemetryData: allTelemetryData,
|
||||
message: 'No tasks eligible for expansion.'
|
||||
};
|
||||
// --- End Fix ---
|
||||
@@ -97,19 +105,6 @@ async function expandAllTasks(
|
||||
|
||||
// Iterate over the already filtered tasks
|
||||
for (const task of tasksToExpand) {
|
||||
// --- Remove Redundant Check ---
|
||||
// The check below is no longer needed as the initial filter handles it
|
||||
/*
|
||||
if (task.subtasks && task.subtasks.length > 0 && !force) {
|
||||
logger.info(
|
||||
`Skipping task ${task.id}: Already has subtasks. Use --force to overwrite.`
|
||||
);
|
||||
skippedCount++;
|
||||
continue;
|
||||
}
|
||||
*/
|
||||
// --- End Removed Redundant Check ---
|
||||
|
||||
// Start indicator for individual task expansion in CLI mode
|
||||
let taskIndicator = null;
|
||||
if (!isMCPCall && outputFormat === 'text') {
|
||||
@@ -117,17 +112,23 @@ async function expandAllTasks(
|
||||
}
|
||||
|
||||
try {
|
||||
// Call the refactored expandTask function
|
||||
await expandTask(
|
||||
// Call the refactored expandTask function AND capture result
|
||||
const result = await expandTask(
|
||||
tasksPath,
|
||||
task.id,
|
||||
numSubtasks, // Pass numSubtasks, expandTask handles defaults/complexity
|
||||
numSubtasks,
|
||||
useResearch,
|
||||
additionalContext,
|
||||
context, // Pass the whole context object { session, mcpLog }
|
||||
force // Pass the force flag down
|
||||
force
|
||||
);
|
||||
expandedCount++;
|
||||
|
||||
// Collect individual telemetry data
|
||||
if (result && result.telemetryData) {
|
||||
allTelemetryData.push(result.telemetryData);
|
||||
}
|
||||
|
||||
if (taskIndicator) {
|
||||
stopLoadingIndicator(taskIndicator, `Task ${task.id} expanded.`);
|
||||
}
|
||||
@@ -146,18 +147,48 @@ async function expandAllTasks(
|
||||
}
|
||||
}
|
||||
|
||||
// Log final summary (removed skipped count from message)
|
||||
// --- AGGREGATION AND DISPLAY ---
|
||||
logger.info(
|
||||
`Expansion complete: ${expandedCount} expanded, ${failedCount} failed.`
|
||||
);
|
||||
|
||||
// Return summary (skippedCount is now 0) - Add success: true here as well for consistency
|
||||
// Aggregate the collected telemetry data
|
||||
const aggregatedTelemetryData = aggregateTelemetry(
|
||||
allTelemetryData,
|
||||
'expand-all-tasks'
|
||||
);
|
||||
|
||||
if (outputFormat === 'text') {
|
||||
const summaryContent =
|
||||
`${chalk.white.bold('Expansion Summary:')}\n\n` +
|
||||
`${chalk.cyan('-')} Attempted: ${chalk.bold(tasksToExpandCount)}\n` +
|
||||
`${chalk.green('-')} Expanded: ${chalk.bold(expandedCount)}\n` +
|
||||
// Skipped count is always 0 now due to pre-filtering
|
||||
`${chalk.gray('-')} Skipped: ${chalk.bold(0)}\n` +
|
||||
`${chalk.red('-')} Failed: ${chalk.bold(failedCount)}`;
|
||||
|
||||
console.log(
|
||||
boxen(summaryContent, {
|
||||
padding: 1,
|
||||
margin: { top: 1 },
|
||||
borderColor: failedCount > 0 ? 'red' : 'green', // Red if failures, green otherwise
|
||||
borderStyle: 'round'
|
||||
})
|
||||
);
|
||||
}
|
||||
|
||||
if (outputFormat === 'text' && aggregatedTelemetryData) {
|
||||
displayAiUsageSummary(aggregatedTelemetryData, 'cli');
|
||||
}
|
||||
|
||||
// Return summary including the AGGREGATED telemetry data
|
||||
return {
|
||||
success: true, // Indicate overall success
|
||||
success: true,
|
||||
expandedCount,
|
||||
failedCount,
|
||||
skippedCount: 0,
|
||||
tasksToExpand: tasksToExpandCount
|
||||
tasksToExpand: tasksToExpandCount,
|
||||
telemetryData: aggregatedTelemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
if (loadingIndicator)
|
||||
|
||||
@@ -4,7 +4,11 @@ import { z } from 'zod';
|
||||
|
||||
import { log, readJSON, writeJSON, isSilentMode } from '../utils.js';
|
||||
|
||||
import { startLoadingIndicator, stopLoadingIndicator } from '../ui.js';
|
||||
import {
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
|
||||
@@ -142,7 +146,7 @@ function generateResearchUserPrompt(
|
||||
"id": <number>, // Sequential ID starting from ${nextSubtaskId}
|
||||
"title": "<string>",
|
||||
"description": "<string>",
|
||||
"dependencies": [<number>], // e.g., [${nextSubtaskId + 1}]
|
||||
"dependencies": [<number>], // e.g., [${nextSubtaskId + 1}]. If no dependencies, use an empty array [].
|
||||
"details": "<string>",
|
||||
"testStrategy": "<string>" // Optional
|
||||
},
|
||||
@@ -162,6 +166,8 @@ ${contextPrompt}
|
||||
CRITICAL: Respond ONLY with a valid JSON object containing a single key "subtasks". The value must be an array of the generated subtasks, strictly matching this structure:
|
||||
${schemaDescription}
|
||||
|
||||
Important: For the 'dependencies' field, if a subtask has no dependencies, you MUST use an empty array, for example: "dependencies": []. Do not use null or omit the field.
|
||||
|
||||
Do not include ANY explanatory text, markdown, or code block markers. Just the JSON object.`;
|
||||
}
|
||||
|
||||
@@ -182,77 +188,153 @@ function parseSubtasksFromText(
|
||||
parentTaskId,
|
||||
logger
|
||||
) {
|
||||
logger.info('Attempting to parse subtasks object from text response...');
|
||||
if (!text || text.trim() === '') {
|
||||
throw new Error('AI response text is empty.');
|
||||
if (typeof text !== 'string') {
|
||||
logger.error(
|
||||
`AI response text is not a string. Received type: ${typeof text}, Value: ${text}`
|
||||
);
|
||||
throw new Error('AI response text is not a string.');
|
||||
}
|
||||
|
||||
let cleanedResponse = text.trim();
|
||||
const originalResponseForDebug = cleanedResponse;
|
||||
if (!text || text.trim() === '') {
|
||||
throw new Error('AI response text is empty after trimming.');
|
||||
}
|
||||
|
||||
// 1. Extract from Markdown code block first
|
||||
const codeBlockMatch = cleanedResponse.match(
|
||||
/```(?:json)?\s*([\s\S]*?)\s*```/
|
||||
const originalTrimmedResponse = text.trim(); // Store the original trimmed response
|
||||
let jsonToParse = originalTrimmedResponse; // Initialize jsonToParse with it
|
||||
|
||||
logger.debug(
|
||||
`Original AI Response for parsing (full length: ${jsonToParse.length}): ${jsonToParse.substring(0, 1000)}...`
|
||||
);
|
||||
if (codeBlockMatch) {
|
||||
cleanedResponse = codeBlockMatch[1].trim();
|
||||
logger.info('Extracted JSON content from Markdown code block.');
|
||||
} else {
|
||||
// 2. If no code block, find first '{' and last '}' for the object
|
||||
const firstBrace = cleanedResponse.indexOf('{');
|
||||
const lastBrace = cleanedResponse.lastIndexOf('}');
|
||||
if (firstBrace !== -1 && lastBrace > firstBrace) {
|
||||
cleanedResponse = cleanedResponse.substring(firstBrace, lastBrace + 1);
|
||||
logger.info('Extracted content between first { and last }.');
|
||||
|
||||
// --- Pre-emptive cleanup for known AI JSON issues ---
|
||||
// Fix for "dependencies": , or "dependencies":,
|
||||
if (jsonToParse.includes('"dependencies":')) {
|
||||
const malformedPattern = /"dependencies":\s*,/g;
|
||||
if (malformedPattern.test(jsonToParse)) {
|
||||
logger.warn('Attempting to fix malformed "dependencies": , issue.');
|
||||
jsonToParse = jsonToParse.replace(
|
||||
malformedPattern,
|
||||
'"dependencies": [],'
|
||||
);
|
||||
logger.debug(
|
||||
`JSON after fixing "dependencies": ${jsonToParse.substring(0, 500)}...`
|
||||
);
|
||||
}
|
||||
}
|
||||
// --- End pre-emptive cleanup ---
|
||||
|
||||
let parsedObject;
|
||||
let primaryParseAttemptFailed = false;
|
||||
|
||||
// --- Attempt 1: Simple Parse (with optional Markdown cleanup) ---
|
||||
logger.debug('Attempting simple parse...');
|
||||
try {
|
||||
// Check for markdown code block
|
||||
const codeBlockMatch = jsonToParse.match(/```(?:json)?\s*([\s\S]*?)\s*```/);
|
||||
let contentToParseDirectly = jsonToParse;
|
||||
if (codeBlockMatch && codeBlockMatch[1]) {
|
||||
contentToParseDirectly = codeBlockMatch[1].trim();
|
||||
logger.debug('Simple parse: Extracted content from markdown code block.');
|
||||
} else {
|
||||
logger.debug(
|
||||
'Simple parse: No markdown code block found, using trimmed original.'
|
||||
);
|
||||
}
|
||||
|
||||
parsedObject = JSON.parse(contentToParseDirectly);
|
||||
logger.debug('Simple parse successful!');
|
||||
|
||||
// Quick check if it looks like our target object
|
||||
if (
|
||||
!parsedObject ||
|
||||
typeof parsedObject !== 'object' ||
|
||||
!Array.isArray(parsedObject.subtasks)
|
||||
) {
|
||||
logger.warn(
|
||||
'Response does not appear to contain a JSON object structure. Parsing raw response.'
|
||||
'Simple parse succeeded, but result is not the expected {"subtasks": []} structure. Will proceed to advanced extraction.'
|
||||
);
|
||||
primaryParseAttemptFailed = true;
|
||||
parsedObject = null; // Reset parsedObject so we enter the advanced logic
|
||||
}
|
||||
// If it IS the correct structure, we'll skip advanced extraction.
|
||||
} catch (e) {
|
||||
logger.warn(
|
||||
`Simple parse failed: ${e.message}. Proceeding to advanced extraction logic.`
|
||||
);
|
||||
primaryParseAttemptFailed = true;
|
||||
// jsonToParse is already originalTrimmedResponse if simple parse failed before modifying it for markdown
|
||||
}
|
||||
|
||||
// --- Attempt 2: Advanced Extraction (if simple parse failed or produced wrong structure) ---
|
||||
if (primaryParseAttemptFailed || !parsedObject) {
|
||||
// Ensure we try advanced if simple parse gave wrong structure
|
||||
logger.debug('Attempting advanced extraction logic...');
|
||||
// Reset jsonToParse to the original full trimmed response for advanced logic
|
||||
jsonToParse = originalTrimmedResponse;
|
||||
|
||||
// (Insert the more complex extraction logic here - the one we worked on with:
|
||||
// - targetPattern = '{"subtasks":';
|
||||
// - careful brace counting for that targetPattern
|
||||
// - fallbacks to last '{' and '}' if targetPattern logic fails)
|
||||
// This was the logic from my previous message. Let's assume it's here.
|
||||
// This block should ultimately set `jsonToParse` to the best candidate string.
|
||||
|
||||
// Example snippet of that advanced logic's start:
|
||||
const targetPattern = '{"subtasks":';
|
||||
const patternStartIndex = jsonToParse.indexOf(targetPattern);
|
||||
|
||||
if (patternStartIndex !== -1) {
|
||||
let openBraces = 0;
|
||||
let firstBraceFound = false;
|
||||
let extractedJsonBlock = '';
|
||||
// ... (loop for brace counting as before) ...
|
||||
// ... (if successful, jsonToParse = extractedJsonBlock) ...
|
||||
// ... (if that fails, fallbacks as before) ...
|
||||
} else {
|
||||
// ... (fallback to last '{' and '}' if targetPattern not found) ...
|
||||
}
|
||||
// End of advanced logic excerpt
|
||||
|
||||
logger.debug(
|
||||
`Advanced extraction: JSON string that will be parsed: ${jsonToParse.substring(0, 500)}...`
|
||||
);
|
||||
try {
|
||||
parsedObject = JSON.parse(jsonToParse);
|
||||
logger.debug('Advanced extraction parse successful!');
|
||||
} catch (parseError) {
|
||||
logger.error(
|
||||
`Advanced extraction: Failed to parse JSON object: ${parseError.message}`
|
||||
);
|
||||
logger.error(
|
||||
`Advanced extraction: Problematic JSON string for parse (first 500 chars): ${jsonToParse.substring(0, 500)}`
|
||||
);
|
||||
throw new Error( // Re-throw a more specific error if advanced also fails
|
||||
`Failed to parse JSON response object after both simple and advanced attempts: ${parseError.message}`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
// 3. Attempt to parse the object
|
||||
let parsedObject;
|
||||
try {
|
||||
parsedObject = JSON.parse(cleanedResponse);
|
||||
} catch (parseError) {
|
||||
logger.error(`Failed to parse JSON object: ${parseError.message}`);
|
||||
logger.error(
|
||||
`Problematic JSON string (first 500 chars): ${cleanedResponse.substring(0, 500)}`
|
||||
);
|
||||
logger.error(
|
||||
`Original Raw Response (first 500 chars): ${originalResponseForDebug.substring(0, 500)}`
|
||||
);
|
||||
throw new Error(
|
||||
`Failed to parse JSON response object: ${parseError.message}`
|
||||
);
|
||||
}
|
||||
|
||||
// 4. Validate the object structure and extract the subtasks array
|
||||
// --- Validation (applies to successfully parsedObject from either attempt) ---
|
||||
if (
|
||||
!parsedObject ||
|
||||
typeof parsedObject !== 'object' ||
|
||||
!Array.isArray(parsedObject.subtasks)
|
||||
) {
|
||||
logger.error(
|
||||
`Parsed content is not an object or missing 'subtasks' array. Content: ${JSON.stringify(parsedObject).substring(0, 200)}`
|
||||
`Final parsed content is not an object or missing 'subtasks' array. Content: ${JSON.stringify(parsedObject).substring(0, 200)}`
|
||||
);
|
||||
throw new Error(
|
||||
'Parsed AI response is not a valid object containing a "subtasks" array.'
|
||||
'Parsed AI response is not a valid object containing a "subtasks" array after all attempts.'
|
||||
);
|
||||
}
|
||||
const parsedSubtasks = parsedObject.subtasks; // Extract the array
|
||||
const parsedSubtasks = parsedObject.subtasks;
|
||||
|
||||
logger.info(
|
||||
`Successfully parsed ${parsedSubtasks.length} potential subtasks from the object.`
|
||||
);
|
||||
if (expectedCount && parsedSubtasks.length !== expectedCount) {
|
||||
logger.warn(
|
||||
`Expected ${expectedCount} subtasks, but parsed ${parsedSubtasks.length}.`
|
||||
);
|
||||
}
|
||||
|
||||
// 5. Validate and Normalize each subtask using Zod schema
|
||||
let currentId = startId;
|
||||
const validatedSubtasks = [];
|
||||
const validationErrors = [];
|
||||
@@ -260,22 +342,21 @@ function parseSubtasksFromText(
|
||||
for (const rawSubtask of parsedSubtasks) {
|
||||
const correctedSubtask = {
|
||||
...rawSubtask,
|
||||
id: currentId, // Enforce sequential ID
|
||||
id: currentId,
|
||||
dependencies: Array.isArray(rawSubtask.dependencies)
|
||||
? rawSubtask.dependencies
|
||||
.map((dep) => (typeof dep === 'string' ? parseInt(dep, 10) : dep))
|
||||
.filter(
|
||||
(depId) => !isNaN(depId) && depId >= startId && depId < currentId
|
||||
) // Ensure deps are numbers, valid range
|
||||
)
|
||||
: [],
|
||||
status: 'pending' // Enforce pending status
|
||||
// parentTaskId can be added if needed: parentTaskId: parentTaskId
|
||||
status: 'pending'
|
||||
};
|
||||
|
||||
const result = subtaskSchema.safeParse(correctedSubtask);
|
||||
|
||||
if (result.success) {
|
||||
validatedSubtasks.push(result.data); // Add the validated data
|
||||
validatedSubtasks.push(result.data);
|
||||
} else {
|
||||
logger.warn(
|
||||
`Subtask validation failed for raw data: ${JSON.stringify(rawSubtask).substring(0, 100)}...`
|
||||
@@ -285,18 +366,14 @@ function parseSubtasksFromText(
|
||||
logger.warn(errorMessage);
|
||||
validationErrors.push(`Subtask ${currentId}: ${errorMessage}`);
|
||||
});
|
||||
// Optionally, decide whether to include partially valid tasks or skip them
|
||||
// For now, we'll skip invalid ones
|
||||
}
|
||||
currentId++; // Increment ID for the next *potential* subtask
|
||||
currentId++;
|
||||
}
|
||||
|
||||
if (validationErrors.length > 0) {
|
||||
logger.error(
|
||||
`Found ${validationErrors.length} validation errors in the generated subtasks.`
|
||||
);
|
||||
// Optionally throw an error here if strict validation is required
|
||||
// throw new Error(`Subtask validation failed:\n${validationErrors.join('\n')}`);
|
||||
logger.warn('Proceeding with only the successfully validated subtasks.');
|
||||
}
|
||||
|
||||
@@ -305,8 +382,6 @@ function parseSubtasksFromText(
|
||||
'AI response contained potential subtasks, but none passed validation.'
|
||||
);
|
||||
}
|
||||
|
||||
// Ensure we don't return more than expected, preferring validated ones
|
||||
return validatedSubtasks.slice(0, expectedCount || validatedSubtasks.length);
|
||||
}
|
||||
|
||||
@@ -336,9 +411,13 @@ async function expandTask(
|
||||
context = {},
|
||||
force = false
|
||||
) {
|
||||
const { session, mcpLog } = context;
|
||||
const { session, mcpLog, projectRoot: contextProjectRoot } = context;
|
||||
const outputFormat = mcpLog ? 'json' : 'text';
|
||||
|
||||
// Determine projectRoot: Use from context if available, otherwise derive from tasksPath
|
||||
const projectRoot =
|
||||
contextProjectRoot || path.dirname(path.dirname(tasksPath));
|
||||
|
||||
// Use mcpLog if available, otherwise use the default console log wrapper
|
||||
const logger = mcpLog || {
|
||||
info: (msg) => !isSilentMode() && log('info', msg),
|
||||
@@ -363,7 +442,9 @@ async function expandTask(
|
||||
);
|
||||
if (taskIndex === -1) throw new Error(`Task ${taskId} not found`);
|
||||
const task = data.tasks[taskIndex];
|
||||
logger.info(`Expanding task ${taskId}: ${task.title}`);
|
||||
logger.info(
|
||||
`Expanding task ${taskId}: ${task.title}${useResearch ? ' with research' : ''}`
|
||||
);
|
||||
// --- End Task Loading/Filtering ---
|
||||
|
||||
// --- Handle Force Flag: Clear existing subtasks if force=true ---
|
||||
@@ -381,7 +462,6 @@ async function expandTask(
|
||||
let complexityReasoningContext = '';
|
||||
let systemPrompt; // Declare systemPrompt here
|
||||
|
||||
const projectRoot = path.dirname(path.dirname(tasksPath));
|
||||
const complexityReportPath = path.join(
|
||||
projectRoot,
|
||||
'scripts/task-complexity-report.json'
|
||||
@@ -488,28 +568,27 @@ async function expandTask(
|
||||
let loadingIndicator = null;
|
||||
if (outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
`Generating ${finalSubtaskCount} subtasks...`
|
||||
`Generating ${finalSubtaskCount} subtasks...\n`
|
||||
);
|
||||
}
|
||||
|
||||
let responseText = '';
|
||||
let aiServiceResponse = null;
|
||||
|
||||
try {
|
||||
const role = useResearch ? 'research' : 'main';
|
||||
logger.info(`Using AI service with role: ${role}`);
|
||||
|
||||
// Call generateTextService with the determined prompts
|
||||
responseText = await generateTextService({
|
||||
// Call generateTextService with the determined prompts and telemetry params
|
||||
aiServiceResponse = await generateTextService({
|
||||
prompt: promptContent,
|
||||
systemPrompt: systemPrompt, // Use the determined system prompt
|
||||
systemPrompt: systemPrompt,
|
||||
role,
|
||||
session,
|
||||
projectRoot
|
||||
projectRoot,
|
||||
commandName: 'expand-task',
|
||||
outputType: outputFormat
|
||||
});
|
||||
logger.info(
|
||||
'Successfully received text response from AI service',
|
||||
'success'
|
||||
);
|
||||
responseText = aiServiceResponse.mainResult;
|
||||
|
||||
// Parse Subtasks
|
||||
generatedSubtasks = parseSubtasksFromText(
|
||||
@@ -550,14 +629,23 @@ async function expandTask(
|
||||
// --- End Change: Append instead of replace ---
|
||||
|
||||
data.tasks[taskIndex] = task; // Assign the modified task back
|
||||
logger.info(`Writing updated tasks to ${tasksPath}`);
|
||||
writeJSON(tasksPath, data);
|
||||
logger.info(`Generating individual task files...`);
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
logger.info(`Task files generated.`);
|
||||
// --- End Task Update & File Writing ---
|
||||
|
||||
return task; // Return the updated task object
|
||||
// Display AI Usage Summary for CLI
|
||||
if (
|
||||
outputFormat === 'text' &&
|
||||
aiServiceResponse &&
|
||||
aiServiceResponse.telemetryData
|
||||
) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
|
||||
// Return the updated task object AND telemetry data
|
||||
return {
|
||||
task,
|
||||
telemetryData: aiServiceResponse?.telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
// Catches errors from file reading, parsing, AI call etc.
|
||||
logger.error(`Error expanding task ${taskId}: ${error.message}`, 'error');
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
import { log } from '../utils.js';
|
||||
import { addComplexityToTask } from '../utils.js';
|
||||
|
||||
/**
|
||||
* Return the next work item:
|
||||
* • Prefer an eligible SUBTASK that belongs to any parent task
|
||||
@@ -15,9 +18,10 @@
|
||||
* ─ parentId → number (present only when it's a subtask)
|
||||
*
|
||||
* @param {Object[]} tasks – full array of top-level tasks, each may contain .subtasks[]
|
||||
* @param {Object} [complexityReport=null] - Optional complexity report object
|
||||
* @returns {Object|null} – next work item or null if nothing is eligible
|
||||
*/
|
||||
function findNextTask(tasks) {
|
||||
function findNextTask(tasks, complexityReport = null) {
|
||||
// ---------- helpers ----------------------------------------------------
|
||||
const priorityValues = { high: 3, medium: 2, low: 1 };
|
||||
|
||||
@@ -91,7 +95,14 @@ function findNextTask(tasks) {
|
||||
if (aPar !== bPar) return aPar - bPar;
|
||||
return aSub - bSub;
|
||||
});
|
||||
return candidateSubtasks[0];
|
||||
const nextTask = candidateSubtasks[0];
|
||||
|
||||
// Add complexity to the task before returning
|
||||
if (nextTask && complexityReport) {
|
||||
addComplexityToTask(nextTask, complexityReport);
|
||||
}
|
||||
|
||||
return nextTask;
|
||||
}
|
||||
|
||||
// ---------- 2) fall back to top-level tasks (original logic) ------------
|
||||
@@ -116,6 +127,11 @@ function findNextTask(tasks) {
|
||||
return a.id - b.id;
|
||||
})[0];
|
||||
|
||||
// Add complexity to the task before returning
|
||||
if (nextTask && complexityReport) {
|
||||
addComplexityToTask(nextTask, complexityReport);
|
||||
}
|
||||
|
||||
return nextTask;
|
||||
}
|
||||
|
||||
|
||||
@@ -19,8 +19,6 @@ function generateTaskFiles(tasksPath, outputDir, options = {}) {
|
||||
// Determine if we're in MCP mode by checking for mcpLog
|
||||
const isMcpMode = !!options?.mcpLog;
|
||||
|
||||
log('info', `Preparing to regenerate task files in ${tasksPath}`);
|
||||
|
||||
const data = readJSON(tasksPath);
|
||||
if (!data || !data.tasks) {
|
||||
throw new Error(`No valid tasks found in ${tasksPath}`);
|
||||
@@ -31,7 +29,7 @@ function generateTaskFiles(tasksPath, outputDir, options = {}) {
|
||||
fs.mkdirSync(outputDir, { recursive: true });
|
||||
}
|
||||
|
||||
log('info', `Found ${data.tasks.length} tasks to regenerate`);
|
||||
log('info', `Preparing to regenerate ${data.tasks.length} task files`);
|
||||
|
||||
// Validate and fix dependencies before generating files
|
||||
log('info', `Validating and fixing dependencies`);
|
||||
|
||||
@@ -2,13 +2,20 @@ import chalk from 'chalk';
|
||||
import boxen from 'boxen';
|
||||
import Table from 'cli-table3';
|
||||
|
||||
import { log, readJSON, truncate } from '../utils.js';
|
||||
import {
|
||||
log,
|
||||
readJSON,
|
||||
truncate,
|
||||
readComplexityReport,
|
||||
addComplexityToTask
|
||||
} from '../utils.js';
|
||||
import findNextTask from './find-next-task.js';
|
||||
|
||||
import {
|
||||
displayBanner,
|
||||
getStatusWithColor,
|
||||
formatDependenciesWithStatus,
|
||||
getComplexityWithColor,
|
||||
createProgressBar
|
||||
} from '../ui.js';
|
||||
|
||||
@@ -16,6 +23,7 @@ import {
|
||||
* List all tasks
|
||||
* @param {string} tasksPath - Path to the tasks.json file
|
||||
* @param {string} statusFilter - Filter by status
|
||||
* @param {string} reportPath - Path to the complexity report
|
||||
* @param {boolean} withSubtasks - Whether to show subtasks
|
||||
* @param {string} outputFormat - Output format (text or json)
|
||||
* @returns {Object} - Task list result for json format
|
||||
@@ -23,6 +31,7 @@ import {
|
||||
function listTasks(
|
||||
tasksPath,
|
||||
statusFilter,
|
||||
reportPath = null,
|
||||
withSubtasks = false,
|
||||
outputFormat = 'text'
|
||||
) {
|
||||
@@ -37,6 +46,13 @@ function listTasks(
|
||||
throw new Error(`No valid tasks found in ${tasksPath}`);
|
||||
}
|
||||
|
||||
// Add complexity scores to tasks if report exists
|
||||
const complexityReport = readComplexityReport(reportPath);
|
||||
// Apply complexity scores to tasks
|
||||
if (complexityReport && complexityReport.complexityAnalysis) {
|
||||
data.tasks.forEach((task) => addComplexityToTask(task, complexityReport));
|
||||
}
|
||||
|
||||
// Filter tasks by status if specified
|
||||
const filteredTasks =
|
||||
statusFilter && statusFilter.toLowerCase() !== 'all' // <-- Added check for 'all'
|
||||
@@ -257,8 +273,8 @@ function listTasks(
|
||||
);
|
||||
const avgDependenciesPerTask = totalDependencies / data.tasks.length;
|
||||
|
||||
// Find next task to work on
|
||||
const nextItem = findNextTask(data.tasks);
|
||||
// Find next task to work on, passing the complexity report
|
||||
const nextItem = findNextTask(data.tasks, complexityReport);
|
||||
|
||||
// Get terminal width - more reliable method
|
||||
let terminalWidth;
|
||||
@@ -301,8 +317,11 @@ function listTasks(
|
||||
`${chalk.blue('•')} ${chalk.white('Avg dependencies per task:')} ${avgDependenciesPerTask.toFixed(1)}\n\n` +
|
||||
chalk.cyan.bold('Next Task to Work On:') +
|
||||
'\n' +
|
||||
`ID: ${chalk.cyan(nextItem ? nextItem.id : 'N/A')} - ${nextItem ? chalk.white.bold(truncate(nextItem.title, 40)) : chalk.yellow('No task available')}\n` +
|
||||
`Priority: ${nextItem ? chalk.white(nextItem.priority || 'medium') : ''} Dependencies: ${nextItem ? formatDependenciesWithStatus(nextItem.dependencies, data.tasks, true) : ''}`;
|
||||
`ID: ${chalk.cyan(nextItem ? nextItem.id : 'N/A')} - ${nextItem ? chalk.white.bold(truncate(nextItem.title, 40)) : chalk.yellow('No task available')}
|
||||
` +
|
||||
`Priority: ${nextItem ? chalk.white(nextItem.priority || 'medium') : ''} Dependencies: ${nextItem ? formatDependenciesWithStatus(nextItem.dependencies, data.tasks, true, complexityReport) : ''}
|
||||
` +
|
||||
`Complexity: ${nextItem && nextItem.complexityScore ? getComplexityWithColor(nextItem.complexityScore) : chalk.gray('N/A')}`;
|
||||
|
||||
// Calculate width for side-by-side display
|
||||
// Box borders, padding take approximately 4 chars on each side
|
||||
@@ -412,9 +431,16 @@ function listTasks(
|
||||
// Make dependencies column smaller as requested (-20%)
|
||||
const depsWidthPct = 20;
|
||||
|
||||
const complexityWidthPct = 10;
|
||||
|
||||
// Calculate title/description width as remaining space (+20% from dependencies reduction)
|
||||
const titleWidthPct =
|
||||
100 - idWidthPct - statusWidthPct - priorityWidthPct - depsWidthPct;
|
||||
100 -
|
||||
idWidthPct -
|
||||
statusWidthPct -
|
||||
priorityWidthPct -
|
||||
depsWidthPct -
|
||||
complexityWidthPct;
|
||||
|
||||
// Allow 10 characters for borders and padding
|
||||
const availableWidth = terminalWidth - 10;
|
||||
@@ -424,6 +450,9 @@ function listTasks(
|
||||
const statusWidth = Math.floor(availableWidth * (statusWidthPct / 100));
|
||||
const priorityWidth = Math.floor(availableWidth * (priorityWidthPct / 100));
|
||||
const depsWidth = Math.floor(availableWidth * (depsWidthPct / 100));
|
||||
const complexityWidth = Math.floor(
|
||||
availableWidth * (complexityWidthPct / 100)
|
||||
);
|
||||
const titleWidth = Math.floor(availableWidth * (titleWidthPct / 100));
|
||||
|
||||
// Create a table with correct borders and spacing
|
||||
@@ -433,9 +462,17 @@ function listTasks(
|
||||
chalk.cyan.bold('Title'),
|
||||
chalk.cyan.bold('Status'),
|
||||
chalk.cyan.bold('Priority'),
|
||||
chalk.cyan.bold('Dependencies')
|
||||
chalk.cyan.bold('Dependencies'),
|
||||
chalk.cyan.bold('Complexity')
|
||||
],
|
||||
colWidths: [
|
||||
idWidth,
|
||||
titleWidth,
|
||||
statusWidth,
|
||||
priorityWidth,
|
||||
depsWidth,
|
||||
complexityWidth // Added complexity column width
|
||||
],
|
||||
colWidths: [idWidth, titleWidth, statusWidth, priorityWidth, depsWidth],
|
||||
style: {
|
||||
head: [], // No special styling for header
|
||||
border: [], // No special styling for border
|
||||
@@ -454,7 +491,8 @@ function listTasks(
|
||||
depText = formatDependenciesWithStatus(
|
||||
task.dependencies,
|
||||
data.tasks,
|
||||
true
|
||||
true,
|
||||
complexityReport
|
||||
);
|
||||
} else {
|
||||
depText = chalk.gray('None');
|
||||
@@ -480,7 +518,10 @@ function listTasks(
|
||||
truncate(cleanTitle, titleWidth - 3),
|
||||
status,
|
||||
priorityColor(truncate(task.priority || 'medium', priorityWidth - 2)),
|
||||
depText // No truncation for dependencies
|
||||
depText,
|
||||
task.complexityScore
|
||||
? getComplexityWithColor(task.complexityScore)
|
||||
: chalk.gray('N/A')
|
||||
]);
|
||||
|
||||
// Add subtasks if requested
|
||||
@@ -516,6 +557,8 @@ function listTasks(
|
||||
// Default to regular task dependency
|
||||
const depTask = data.tasks.find((t) => t.id === depId);
|
||||
if (depTask) {
|
||||
// Add complexity to depTask before checking status
|
||||
addComplexityToTask(depTask, complexityReport);
|
||||
const isDone =
|
||||
depTask.status === 'done' || depTask.status === 'completed';
|
||||
const isInProgress = depTask.status === 'in-progress';
|
||||
@@ -541,7 +584,10 @@ function listTasks(
|
||||
chalk.dim(`└─ ${truncate(subtask.title, titleWidth - 5)}`),
|
||||
getStatusWithColor(subtask.status, true),
|
||||
chalk.dim('-'),
|
||||
subtaskDepText // No truncation for dependencies
|
||||
subtaskDepText,
|
||||
subtask.complexityScore
|
||||
? chalk.gray(`${subtask.complexityScore}`)
|
||||
: chalk.gray('N/A')
|
||||
]);
|
||||
});
|
||||
}
|
||||
@@ -597,6 +643,8 @@ function listTasks(
|
||||
subtasksSection = `\n\n${chalk.white.bold('Subtasks:')}\n`;
|
||||
subtasksSection += parentTaskForSubtasks.subtasks
|
||||
.map((subtask) => {
|
||||
// Add complexity to subtask before display
|
||||
addComplexityToTask(subtask, complexityReport);
|
||||
// Using a more simplified format for subtask status display
|
||||
const status = subtask.status || 'pending';
|
||||
const statusColors = {
|
||||
@@ -625,8 +673,8 @@ function listTasks(
|
||||
'\n\n' +
|
||||
// Use nextItem.priority, nextItem.status, nextItem.dependencies
|
||||
`${chalk.white('Priority:')} ${priorityColors[nextItem.priority || 'medium'](nextItem.priority || 'medium')} ${chalk.white('Status:')} ${getStatusWithColor(nextItem.status, true)}\n` +
|
||||
`${chalk.white('Dependencies:')} ${nextItem.dependencies && nextItem.dependencies.length > 0 ? formatDependenciesWithStatus(nextItem.dependencies, data.tasks, true) : chalk.gray('None')}\n\n` +
|
||||
// Use nextItem.description (Note: findNextTask doesn't return description, need to fetch original task/subtask for this)
|
||||
`${chalk.white('Dependencies:')} ${nextItem.dependencies && nextItem.dependencies.length > 0 ? formatDependenciesWithStatus(nextItem.dependencies, data.tasks, true, complexityReport) : chalk.gray('None')}\n\n` +
|
||||
// Use nextTask.description (Note: findNextTask doesn't return description, need to fetch original task/subtask for this)
|
||||
// *** Fetching original item for description and details ***
|
||||
`${chalk.white('Description:')} ${getWorkItemDescription(nextItem, data.tasks)}` +
|
||||
subtasksSection + // <-- Subtasks are handled above now
|
||||
|
||||
@@ -17,6 +17,7 @@ import {
|
||||
import { generateObjectService } from '../ai-services-unified.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
import generateTaskFiles from './generate-task-files.js';
|
||||
import { displayAiUsageSummary } from '../ui.js';
|
||||
|
||||
// Define the Zod schema for a SINGLE task object
|
||||
const prdSingleTaskSchema = z.object({
|
||||
@@ -47,8 +48,8 @@ const prdResponseSchema = z.object({
|
||||
* @param {string} tasksPath - Path to the tasks.json file
|
||||
* @param {number} numTasks - Number of tasks to generate
|
||||
* @param {Object} options - Additional options
|
||||
* @param {boolean} [options.useForce=false] - Whether to overwrite existing tasks.json.
|
||||
* @param {boolean} [options.useAppend=false] - Append to existing tasks file.
|
||||
* @param {boolean} [options.force=false] - Whether to overwrite existing tasks.json.
|
||||
* @param {boolean} [options.append=false] - Append to existing tasks file.
|
||||
* @param {Object} [options.reportProgress] - Function to report progress (optional, likely unused).
|
||||
* @param {Object} [options.mcpLog] - MCP logger object (optional).
|
||||
* @param {Object} [options.session] - Session object from MCP server (optional).
|
||||
@@ -61,8 +62,8 @@ async function parsePRD(prdPath, tasksPath, numTasks, options = {}) {
|
||||
mcpLog,
|
||||
session,
|
||||
projectRoot,
|
||||
useForce = false,
|
||||
useAppend = false
|
||||
force = false,
|
||||
append = false
|
||||
} = options;
|
||||
const isMCP = !!mcpLog;
|
||||
const outputFormat = isMCP ? 'json' : 'text';
|
||||
@@ -89,17 +90,16 @@ async function parsePRD(prdPath, tasksPath, numTasks, options = {}) {
|
||||
}
|
||||
};
|
||||
|
||||
report(
|
||||
`Parsing PRD file: ${prdPath}, Force: ${useForce}, Append: ${useAppend}`
|
||||
);
|
||||
report(`Parsing PRD file: ${prdPath}, Force: ${force}, Append: ${append}`);
|
||||
|
||||
let existingTasks = [];
|
||||
let nextId = 1;
|
||||
let aiServiceResponse = null;
|
||||
|
||||
try {
|
||||
// Handle file existence and overwrite/append logic
|
||||
if (fs.existsSync(tasksPath)) {
|
||||
if (useAppend) {
|
||||
if (append) {
|
||||
report(
|
||||
`Append mode enabled. Reading existing tasks from ${tasksPath}`,
|
||||
'info'
|
||||
@@ -121,7 +121,7 @@ async function parsePRD(prdPath, tasksPath, numTasks, options = {}) {
|
||||
);
|
||||
existingTasks = []; // Reset if read fails
|
||||
}
|
||||
} else if (!useForce) {
|
||||
} else if (!force) {
|
||||
// Not appending and not forcing overwrite
|
||||
const overwriteError = new Error(
|
||||
`Output file ${tasksPath} already exists. Use --force to overwrite or --append.`
|
||||
@@ -206,8 +206,8 @@ Guidelines:
|
||||
// Call the unified AI service
|
||||
report('Calling AI service to generate tasks from PRD...', 'info');
|
||||
|
||||
// Call generateObjectService with the CORRECT schema
|
||||
const generatedData = await generateObjectService({
|
||||
// Call generateObjectService with the CORRECT schema and additional telemetry params
|
||||
aiServiceResponse = await generateObjectService({
|
||||
role: 'main',
|
||||
session: session,
|
||||
projectRoot: projectRoot,
|
||||
@@ -215,7 +215,8 @@ Guidelines:
|
||||
objectName: 'tasks_data',
|
||||
systemPrompt: systemPrompt,
|
||||
prompt: userPrompt,
|
||||
reportProgress
|
||||
commandName: 'parse-prd',
|
||||
outputType: isMCP ? 'mcp' : 'cli'
|
||||
});
|
||||
|
||||
// Create the directory if it doesn't exist
|
||||
@@ -223,12 +224,32 @@ Guidelines:
|
||||
if (!fs.existsSync(tasksDir)) {
|
||||
fs.mkdirSync(tasksDir, { recursive: true });
|
||||
}
|
||||
logFn.success('Successfully parsed PRD via AI service.'); // Assumes generateObjectService validated
|
||||
logFn.success('Successfully parsed PRD via AI service.\n');
|
||||
|
||||
// Validate and Process Tasks
|
||||
// const generatedData = aiServiceResponse?.mainResult?.object;
|
||||
|
||||
// Robustly get the actual AI-generated object
|
||||
let generatedData = null;
|
||||
if (aiServiceResponse?.mainResult) {
|
||||
if (
|
||||
typeof aiServiceResponse.mainResult === 'object' &&
|
||||
aiServiceResponse.mainResult !== null &&
|
||||
'tasks' in aiServiceResponse.mainResult
|
||||
) {
|
||||
// If mainResult itself is the object with a 'tasks' property
|
||||
generatedData = aiServiceResponse.mainResult;
|
||||
} else if (
|
||||
typeof aiServiceResponse.mainResult.object === 'object' &&
|
||||
aiServiceResponse.mainResult.object !== null &&
|
||||
'tasks' in aiServiceResponse.mainResult.object
|
||||
) {
|
||||
// If mainResult.object is the object with a 'tasks' property
|
||||
generatedData = aiServiceResponse.mainResult.object;
|
||||
}
|
||||
}
|
||||
|
||||
if (!generatedData || !Array.isArray(generatedData.tasks)) {
|
||||
// This error *shouldn't* happen if generateObjectService enforced prdResponseSchema
|
||||
// But keep it as a safeguard
|
||||
logFn.error(
|
||||
`Internal Error: generateObjectService returned unexpected data structure: ${JSON.stringify(generatedData)}`
|
||||
);
|
||||
@@ -265,36 +286,27 @@ Guidelines:
|
||||
);
|
||||
});
|
||||
|
||||
const allTasks = useAppend
|
||||
const finalTasks = append
|
||||
? [...existingTasks, ...processedNewTasks]
|
||||
: processedNewTasks;
|
||||
const outputData = { tasks: finalTasks };
|
||||
|
||||
const finalTaskData = { tasks: allTasks }; // Use the combined list
|
||||
|
||||
// Write the tasks to the file
|
||||
writeJSON(tasksPath, finalTaskData);
|
||||
// Write the final tasks to the file
|
||||
writeJSON(tasksPath, outputData);
|
||||
report(
|
||||
`Successfully wrote ${allTasks.length} total tasks to ${tasksPath} (${processedNewTasks.length} new).`,
|
||||
`Successfully ${append ? 'appended' : 'generated'} ${processedNewTasks.length} tasks in ${tasksPath}`,
|
||||
'success'
|
||||
);
|
||||
report(`Tasks saved to: ${tasksPath}`, 'info');
|
||||
|
||||
// Generate individual task files
|
||||
if (reportProgress && mcpLog) {
|
||||
// Enable silent mode when being called from MCP server
|
||||
enableSilentMode();
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
disableSilentMode();
|
||||
} else {
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
}
|
||||
// Generate markdown task files after writing tasks.json
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath), { mcpLog });
|
||||
|
||||
// Only show success boxes for text output (CLI)
|
||||
// Handle CLI output (e.g., success message)
|
||||
if (outputFormat === 'text') {
|
||||
console.log(
|
||||
boxen(
|
||||
chalk.green(
|
||||
`Successfully generated ${processedNewTasks.length} new tasks. Total tasks in ${tasksPath}: ${allTasks.length}`
|
||||
`Successfully generated ${processedNewTasks.length} new tasks. Total tasks in ${tasksPath}: ${finalTasks.length}`
|
||||
),
|
||||
{ padding: 1, borderColor: 'green', borderStyle: 'round' }
|
||||
)
|
||||
@@ -314,9 +326,18 @@ Guidelines:
|
||||
}
|
||||
)
|
||||
);
|
||||
|
||||
if (aiServiceResponse && aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
}
|
||||
|
||||
return { success: true, tasks: processedNewTasks };
|
||||
// Return telemetry data
|
||||
return {
|
||||
success: true,
|
||||
tasksPath,
|
||||
telemetryData: aiServiceResponse?.telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
report(`Error parsing PRD: ${error.message}`, 'error');
|
||||
|
||||
|
||||
@@ -3,12 +3,12 @@ import path from 'path';
|
||||
import chalk from 'chalk';
|
||||
import boxen from 'boxen';
|
||||
import Table from 'cli-table3';
|
||||
import { z } from 'zod';
|
||||
|
||||
import {
|
||||
getStatusWithColor,
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
import {
|
||||
log as consoleLog,
|
||||
@@ -17,10 +17,7 @@ import {
|
||||
truncate,
|
||||
isSilentMode
|
||||
} from '../utils.js';
|
||||
import {
|
||||
generateObjectService,
|
||||
generateTextService
|
||||
} from '../ai-services-unified.js';
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
import generateTaskFiles from './generate-task-files.js';
|
||||
|
||||
@@ -64,7 +61,6 @@ async function updateSubtaskById(
|
||||
try {
|
||||
report('info', `Updating subtask ${subtaskId} with prompt: "${prompt}"`);
|
||||
|
||||
// Validate subtask ID format
|
||||
if (
|
||||
!subtaskId ||
|
||||
typeof subtaskId !== 'string' ||
|
||||
@@ -75,19 +71,16 @@ async function updateSubtaskById(
|
||||
);
|
||||
}
|
||||
|
||||
// Validate prompt
|
||||
if (!prompt || typeof prompt !== 'string' || prompt.trim() === '') {
|
||||
throw new Error(
|
||||
'Prompt cannot be empty. Please provide context for the subtask update.'
|
||||
);
|
||||
}
|
||||
|
||||
// Validate tasks file exists
|
||||
if (!fs.existsSync(tasksPath)) {
|
||||
throw new Error(`Tasks file not found at path: ${tasksPath}`);
|
||||
}
|
||||
|
||||
// Read the tasks file
|
||||
const data = readJSON(tasksPath);
|
||||
if (!data || !data.tasks) {
|
||||
throw new Error(
|
||||
@@ -95,7 +88,6 @@ async function updateSubtaskById(
|
||||
);
|
||||
}
|
||||
|
||||
// Parse parent and subtask IDs
|
||||
const [parentIdStr, subtaskIdStr] = subtaskId.split('.');
|
||||
const parentId = parseInt(parentIdStr, 10);
|
||||
const subtaskIdNum = parseInt(subtaskIdStr, 10);
|
||||
@@ -111,7 +103,6 @@ async function updateSubtaskById(
|
||||
);
|
||||
}
|
||||
|
||||
// Find the parent task
|
||||
const parentTask = data.tasks.find((task) => task.id === parentId);
|
||||
if (!parentTask) {
|
||||
throw new Error(
|
||||
@@ -119,7 +110,6 @@ async function updateSubtaskById(
|
||||
);
|
||||
}
|
||||
|
||||
// Find the subtask
|
||||
if (!parentTask.subtasks || !Array.isArray(parentTask.subtasks)) {
|
||||
throw new Error(`Parent task ${parentId} has no subtasks.`);
|
||||
}
|
||||
@@ -135,20 +125,7 @@ async function updateSubtaskById(
|
||||
|
||||
const subtask = parentTask.subtasks[subtaskIndex];
|
||||
|
||||
const subtaskSchema = z.object({
|
||||
id: z.number().int().positive(),
|
||||
title: z.string(),
|
||||
description: z.string().optional(),
|
||||
status: z.string(),
|
||||
dependencies: z.array(z.union([z.string(), z.number()])).optional(),
|
||||
priority: z.string().optional(),
|
||||
details: z.string().optional(),
|
||||
testStrategy: z.string().optional()
|
||||
});
|
||||
|
||||
// Only show UI elements for text output (CLI)
|
||||
if (outputFormat === 'text') {
|
||||
// Show the subtask that will be updated
|
||||
const table = new Table({
|
||||
head: [
|
||||
chalk.cyan.bold('ID'),
|
||||
@@ -157,13 +134,11 @@ async function updateSubtaskById(
|
||||
],
|
||||
colWidths: [10, 55, 10]
|
||||
});
|
||||
|
||||
table.push([
|
||||
subtaskId,
|
||||
truncate(subtask.title, 52),
|
||||
getStatusWithColor(subtask.status)
|
||||
]);
|
||||
|
||||
console.log(
|
||||
boxen(chalk.white.bold(`Updating Subtask #${subtaskId}`), {
|
||||
padding: 1,
|
||||
@@ -172,10 +147,7 @@ async function updateSubtaskById(
|
||||
margin: { top: 1, bottom: 0 }
|
||||
})
|
||||
);
|
||||
|
||||
console.log(table.toString());
|
||||
|
||||
// Start the loading indicator - only for text output
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
useResearch
|
||||
? 'Updating subtask with research...'
|
||||
@@ -183,15 +155,15 @@ async function updateSubtaskById(
|
||||
);
|
||||
}
|
||||
|
||||
let parsedAIResponse;
|
||||
let generatedContentString = '';
|
||||
let newlyAddedSnippet = '';
|
||||
let aiServiceResponse = null;
|
||||
|
||||
try {
|
||||
// --- GET PARENT & SIBLING CONTEXT ---
|
||||
const parentContext = {
|
||||
id: parentTask.id,
|
||||
title: parentTask.title
|
||||
// Avoid sending full parent description/details unless necessary
|
||||
};
|
||||
|
||||
const prevSubtask =
|
||||
subtaskIndex > 0
|
||||
? {
|
||||
@@ -200,7 +172,6 @@ async function updateSubtaskById(
|
||||
status: parentTask.subtasks[subtaskIndex - 1].status
|
||||
}
|
||||
: null;
|
||||
|
||||
const nextSubtask =
|
||||
subtaskIndex < parentTask.subtasks.length - 1
|
||||
? {
|
||||
@@ -214,154 +185,123 @@ async function updateSubtaskById(
|
||||
Parent Task: ${JSON.stringify(parentContext)}
|
||||
${prevSubtask ? `Previous Subtask: ${JSON.stringify(prevSubtask)}` : ''}
|
||||
${nextSubtask ? `Next Subtask: ${JSON.stringify(nextSubtask)}` : ''}
|
||||
Current Subtask Details (for context only):\n${subtask.details || '(No existing details)'}
|
||||
`;
|
||||
|
||||
const systemPrompt = `You are an AI assistant updating a parent task's subtask. This subtask will be part of a larger parent task and will be used to direct AI agents to complete the subtask. Your goal is to GENERATE new, relevant information based on the user's request (which may be high-level, mid-level or low-level) and APPEND it to the existing subtask 'details' field, wrapped in specific XML-like tags with an ISO 8601 timestamp. Intelligently determine the level of detail to include based on the user's request. Some requests are meant simply to update the subtask with some mid-implementation details, while others are meant to update the subtask with a detailed plan or strategy.
|
||||
const systemPrompt = `You are an AI assistant helping to update a subtask. You will be provided with the subtask's existing details, context about its parent and sibling tasks, and a user request string.
|
||||
|
||||
Context Provided:
|
||||
- The current subtask object.
|
||||
- Basic info about the parent task (ID, title).
|
||||
- Basic info about the immediately preceding subtask (ID, title, status), if it exists.
|
||||
- Basic info about the immediately succeeding subtask (ID, title, status), if it exists.
|
||||
- A user request string.
|
||||
Your Goal: Based *only* on the user's request and all the provided context (including existing details if relevant to the request), GENERATE the new text content that should be added to the subtask's details.
|
||||
Focus *only* on generating the substance of the update.
|
||||
|
||||
Guidelines:
|
||||
1. Analyze the user request considering the provided subtask details AND the context of the parent and sibling tasks.
|
||||
2. GENERATE new, relevant text content that should be added to the 'details' field. Focus *only* on the substance of the update based on the user request and context. Do NOT add timestamps or any special formatting yourself. Avoid over-engineering the details, provide .
|
||||
3. Update the 'details' field in the subtask object with the GENERATED text content. It's okay if this overwrites previous details in the object you return, as the calling code will handle the final appending.
|
||||
4. Return the *entire* updated subtask object (with your generated content in the 'details' field) as a valid JSON object conforming to the provided schema. Do NOT return explanations or markdown formatting.`;
|
||||
Output Requirements:
|
||||
1. Return *only* the newly generated text content as a plain string. Do NOT return a JSON object or any other structured data.
|
||||
2. Your string response should NOT include any of the subtask's original details, unless the user's request explicitly asks to rephrase, summarize, or directly modify existing text.
|
||||
3. Do NOT include any timestamps, XML-like tags, markdown, or any other special formatting in your string response.
|
||||
4. Ensure the generated text is concise yet complete for the update based on the user request. Avoid conversational fillers or explanations about what you are doing (e.g., do not start with "Okay, here's the update...").`;
|
||||
|
||||
const subtaskDataString = JSON.stringify(subtask, null, 2);
|
||||
// Updated user prompt including context
|
||||
const userPrompt = `Task Context:\n${contextString}\nCurrent Subtask:\n${subtaskDataString}\n\nUser Request: "${prompt}"\n\nPlease GENERATE new, relevant text content for the 'details' field based on the user request and the provided context. Return the entire updated subtask object as a valid JSON object matching the schema, with the newly generated text placed in the 'details' field.`;
|
||||
// --- END UPDATED PROMPTS ---
|
||||
// Pass the existing subtask.details in the user prompt for the AI's context.
|
||||
const userPrompt = `Task Context:\n${contextString}\n\nUser Request: "${prompt}"\n\nBased on the User Request and all the Task Context (including current subtask details provided above), what is the new information or text that should be appended to this subtask's details? Return ONLY this new text as a plain string.`;
|
||||
|
||||
// Call Unified AI Service using generateObjectService
|
||||
const role = useResearch ? 'research' : 'main';
|
||||
report('info', `Using AI object service with role: ${role}`);
|
||||
report('info', `Using AI text service with role: ${role}`);
|
||||
|
||||
parsedAIResponse = await generateObjectService({
|
||||
aiServiceResponse = await generateTextService({
|
||||
prompt: userPrompt,
|
||||
systemPrompt: systemPrompt,
|
||||
schema: subtaskSchema,
|
||||
objectName: 'updatedSubtask',
|
||||
role,
|
||||
session,
|
||||
projectRoot,
|
||||
maxRetries: 2
|
||||
maxRetries: 2,
|
||||
commandName: 'update-subtask',
|
||||
outputType: isMCP ? 'mcp' : 'cli'
|
||||
});
|
||||
report(
|
||||
'success',
|
||||
'Successfully received object response from AI service'
|
||||
);
|
||||
|
||||
if (
|
||||
aiServiceResponse &&
|
||||
aiServiceResponse.mainResult &&
|
||||
typeof aiServiceResponse.mainResult === 'string'
|
||||
) {
|
||||
generatedContentString = aiServiceResponse.mainResult;
|
||||
} else {
|
||||
generatedContentString = '';
|
||||
report(
|
||||
'warn',
|
||||
'AI service response did not contain expected text string.'
|
||||
);
|
||||
}
|
||||
|
||||
if (outputFormat === 'text' && loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
loadingIndicator = null;
|
||||
}
|
||||
|
||||
if (!parsedAIResponse || typeof parsedAIResponse !== 'object') {
|
||||
throw new Error('AI did not return a valid object.');
|
||||
}
|
||||
|
||||
report(
|
||||
'success',
|
||||
`Successfully generated object using AI role: ${role}.`
|
||||
);
|
||||
} catch (aiError) {
|
||||
report('error', `AI service call failed: ${aiError.message}`);
|
||||
if (outputFormat === 'text' && loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator); // Ensure stop on error
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
loadingIndicator = null;
|
||||
}
|
||||
throw aiError;
|
||||
}
|
||||
|
||||
// --- TIMESTAMP & FORMATTING LOGIC (Handled Locally) ---
|
||||
// Extract only the generated content from the AI's response details field.
|
||||
const generatedContent = parsedAIResponse.details || ''; // Default to empty string
|
||||
if (generatedContentString && generatedContentString.trim()) {
|
||||
// Check if the string is not empty
|
||||
const timestamp = new Date().toISOString();
|
||||
const formattedBlock = `<info added on ${timestamp}>\n${generatedContentString.trim()}\n</info added on ${timestamp}>`;
|
||||
newlyAddedSnippet = formattedBlock; // <--- ADD THIS LINE: Store for display
|
||||
|
||||
if (generatedContent.trim()) {
|
||||
// Generate timestamp locally
|
||||
const timestamp = new Date().toISOString(); // <<< Local Timestamp
|
||||
|
||||
// Format the content with XML-like tags and timestamp LOCALLY
|
||||
const formattedBlock = `<info added on ${timestamp}>\n${generatedContent.trim()}\n</info added on ${timestamp}>`; // <<< Local Formatting
|
||||
|
||||
// Append the formatted block to the *original* subtask details
|
||||
subtask.details =
|
||||
(subtask.details ? subtask.details + '\n' : '') + formattedBlock; // <<< Local Appending
|
||||
report(
|
||||
'info',
|
||||
'Appended timestamped, formatted block with AI-generated content to subtask.details.'
|
||||
);
|
||||
(subtask.details ? subtask.details + '\n' : '') + formattedBlock;
|
||||
} else {
|
||||
report(
|
||||
'warn',
|
||||
'AI response object did not contain generated content in the "details" field. Original details remain unchanged.'
|
||||
'AI response was empty or whitespace after trimming. Original details remain unchanged.'
|
||||
);
|
||||
newlyAddedSnippet = 'No new details were added by the AI.';
|
||||
}
|
||||
// --- END TIMESTAMP & FORMATTING LOGIC ---
|
||||
|
||||
// Get a reference to the subtask *after* its details have been updated
|
||||
const updatedSubtask = parentTask.subtasks[subtaskIndex]; // subtask === updatedSubtask now
|
||||
const updatedSubtask = parentTask.subtasks[subtaskIndex];
|
||||
|
||||
report('info', 'Updated subtask details locally after AI generation.');
|
||||
// --- END UPDATE SUBTASK ---
|
||||
|
||||
// Only show debug info for text output (CLI)
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log(
|
||||
'>>> DEBUG: Subtask details AFTER AI update:',
|
||||
updatedSubtask.details // Use updatedSubtask
|
||||
updatedSubtask.details
|
||||
);
|
||||
}
|
||||
|
||||
// Description update logic (keeping as is for now)
|
||||
if (updatedSubtask.description) {
|
||||
// Use updatedSubtask
|
||||
if (prompt.length < 100) {
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log(
|
||||
'>>> DEBUG: Subtask description BEFORE append:',
|
||||
updatedSubtask.description // Use updatedSubtask
|
||||
updatedSubtask.description
|
||||
);
|
||||
}
|
||||
updatedSubtask.description += ` [Updated: ${new Date().toLocaleDateString()}]`; // Use updatedSubtask
|
||||
updatedSubtask.description += ` [Updated: ${new Date().toLocaleDateString()}]`;
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log(
|
||||
'>>> DEBUG: Subtask description AFTER append:',
|
||||
updatedSubtask.description // Use updatedSubtask
|
||||
updatedSubtask.description
|
||||
);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Only show debug info for text output (CLI)
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log('>>> DEBUG: About to call writeJSON with updated data...');
|
||||
}
|
||||
|
||||
// Write the updated tasks to the file (parentTask already contains the updated subtask)
|
||||
writeJSON(tasksPath, data);
|
||||
|
||||
// Only show debug info for text output (CLI)
|
||||
if (outputFormat === 'text' && getDebugFlag(session)) {
|
||||
console.log('>>> DEBUG: writeJSON call completed.');
|
||||
}
|
||||
|
||||
report('success', `Successfully updated subtask ${subtaskId}`);
|
||||
|
||||
// Generate individual task files
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
|
||||
// Stop indicator before final console output - only for text output (CLI)
|
||||
if (outputFormat === 'text') {
|
||||
if (loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
loadingIndicator = null;
|
||||
}
|
||||
|
||||
console.log(
|
||||
boxen(
|
||||
chalk.green(`Successfully updated subtask #${subtaskId}`) +
|
||||
@@ -370,31 +310,30 @@ Guidelines:
|
||||
' ' +
|
||||
updatedSubtask.title +
|
||||
'\n\n' +
|
||||
// Update the display to show the new details field
|
||||
chalk.white.bold('Updated Details:') +
|
||||
chalk.white.bold('Newly Added Snippet:') +
|
||||
'\n' +
|
||||
chalk.white(truncate(updatedSubtask.details || '', 500, true)), // Use updatedSubtask
|
||||
chalk.white(newlyAddedSnippet),
|
||||
{ padding: 1, borderColor: 'green', borderStyle: 'round' }
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
return updatedSubtask; // Return the modified subtask object
|
||||
if (outputFormat === 'text' && aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
|
||||
return {
|
||||
updatedSubtask: updatedSubtask,
|
||||
telemetryData: aiServiceResponse.telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
// Outer catch block handles final errors after loop/attempts
|
||||
// Stop indicator on error - only for text output (CLI)
|
||||
if (outputFormat === 'text' && loadingIndicator) {
|
||||
stopLoadingIndicator(loadingIndicator);
|
||||
loadingIndicator = null;
|
||||
}
|
||||
|
||||
report('error', `Error updating subtask: ${error.message}`);
|
||||
|
||||
// Only show error UI for text output (CLI)
|
||||
if (outputFormat === 'text') {
|
||||
console.error(chalk.red(`Error: ${error.message}`));
|
||||
|
||||
// Provide helpful error messages based on error type
|
||||
if (error.message?.includes('ANTHROPIC_API_KEY')) {
|
||||
console.log(
|
||||
chalk.yellow('\nTo fix this issue, set your Anthropic API key:')
|
||||
@@ -409,7 +348,6 @@ Guidelines:
|
||||
' 2. Or run without the research flag: task-master update-subtask --id=<id> --prompt="..."'
|
||||
);
|
||||
} else if (error.message?.includes('overloaded')) {
|
||||
// Catch final overload error
|
||||
console.log(
|
||||
chalk.yellow(
|
||||
'\nAI model overloaded, and fallback failed or was unavailable:'
|
||||
@@ -417,7 +355,6 @@ Guidelines:
|
||||
);
|
||||
console.log(' 1. Try again in a few minutes.');
|
||||
console.log(' 2. Ensure PERPLEXITY_API_KEY is set for fallback.');
|
||||
console.log(' 3. Consider breaking your prompt into smaller updates.');
|
||||
} else if (error.message?.includes('not found')) {
|
||||
console.log(chalk.yellow('\nTo fix this issue:'));
|
||||
console.log(
|
||||
@@ -426,22 +363,22 @@ Guidelines:
|
||||
console.log(
|
||||
' 2. Use a valid subtask ID with the --id parameter in format "parentId.subtaskId"'
|
||||
);
|
||||
} else if (error.message?.includes('empty stream response')) {
|
||||
} else if (
|
||||
error.message?.includes('empty stream response') ||
|
||||
error.message?.includes('AI did not return a valid text string')
|
||||
) {
|
||||
console.log(
|
||||
chalk.yellow(
|
||||
'\nThe AI model returned an empty response. This might be due to the prompt or API issues. Try rephrasing or trying again later.'
|
||||
'\nThe AI model returned an empty or invalid response. This might be due to the prompt or API issues. Try rephrasing or trying again later.'
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
if (getDebugFlag(session)) {
|
||||
// Use getter
|
||||
console.error(error);
|
||||
}
|
||||
} else {
|
||||
throw error; // Re-throw for JSON output
|
||||
throw error;
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -16,7 +16,8 @@ import {
|
||||
import {
|
||||
getStatusWithColor,
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
@@ -94,10 +95,6 @@ function parseUpdatedTaskFromText(text, expectedTaskId, logFn, isMCP) {
|
||||
// It worked! Use this as the primary cleaned response.
|
||||
cleanedResponse = potentialJsonFromBraces;
|
||||
parseMethodUsed = 'braces';
|
||||
report(
|
||||
'info',
|
||||
'Successfully parsed JSON content extracted between first { and last }.'
|
||||
);
|
||||
} catch (e) {
|
||||
report(
|
||||
'info',
|
||||
@@ -376,29 +373,125 @@ The changes described in the prompt should be thoughtfully applied to make the t
|
||||
const userPrompt = `Here is the task to update:\n${taskDataString}\n\nPlease update this task based on the following new context:\n${prompt}\n\nIMPORTANT: In the task JSON above, any subtasks with "status": "done" or "status": "completed" should be preserved exactly as is. Build your changes around these completed items.\n\nReturn only the updated task as a valid JSON object.`;
|
||||
// --- End Build Prompts ---
|
||||
|
||||
let updatedTask;
|
||||
let loadingIndicator = null;
|
||||
if (outputFormat === 'text') {
|
||||
let aiServiceResponse = null;
|
||||
|
||||
if (!isMCP && outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator(
|
||||
useResearch ? 'Updating task with research...\n' : 'Updating task...\n'
|
||||
);
|
||||
}
|
||||
|
||||
let responseText = '';
|
||||
try {
|
||||
// --- Call Unified AI Service (generateTextService) ---
|
||||
const role = useResearch ? 'research' : 'main';
|
||||
report('info', `Using AI service with role: ${role}`);
|
||||
|
||||
responseText = await generateTextService({
|
||||
prompt: userPrompt,
|
||||
const serviceRole = useResearch ? 'research' : 'main';
|
||||
aiServiceResponse = await generateTextService({
|
||||
role: serviceRole,
|
||||
session: session,
|
||||
projectRoot: projectRoot,
|
||||
systemPrompt: systemPrompt,
|
||||
role,
|
||||
session,
|
||||
projectRoot
|
||||
prompt: userPrompt,
|
||||
commandName: 'update-task',
|
||||
outputType: isMCP ? 'mcp' : 'cli'
|
||||
});
|
||||
report('success', 'Successfully received text response from AI service');
|
||||
// --- End AI Service Call ---
|
||||
|
||||
if (loadingIndicator)
|
||||
stopLoadingIndicator(loadingIndicator, 'AI update complete.');
|
||||
|
||||
// Use mainResult (text) for parsing
|
||||
const updatedTask = parseUpdatedTaskFromText(
|
||||
aiServiceResponse.mainResult,
|
||||
taskId,
|
||||
logFn,
|
||||
isMCP
|
||||
);
|
||||
|
||||
// --- Task Validation/Correction (Keep existing logic) ---
|
||||
if (!updatedTask || typeof updatedTask !== 'object')
|
||||
throw new Error('Received invalid task object from AI.');
|
||||
if (!updatedTask.title || !updatedTask.description)
|
||||
throw new Error('Updated task missing required fields.');
|
||||
// Preserve ID if AI changed it
|
||||
if (updatedTask.id !== taskId) {
|
||||
report('warn', `AI changed task ID. Restoring original ID ${taskId}.`);
|
||||
updatedTask.id = taskId;
|
||||
}
|
||||
// Preserve status if AI changed it
|
||||
if (
|
||||
updatedTask.status !== taskToUpdate.status &&
|
||||
!prompt.toLowerCase().includes('status')
|
||||
) {
|
||||
report(
|
||||
'warn',
|
||||
`AI changed task status. Restoring original status '${taskToUpdate.status}'.`
|
||||
);
|
||||
updatedTask.status = taskToUpdate.status;
|
||||
}
|
||||
// Preserve completed subtasks (Keep existing logic)
|
||||
if (taskToUpdate.subtasks?.length > 0) {
|
||||
if (!updatedTask.subtasks) {
|
||||
report(
|
||||
'warn',
|
||||
'Subtasks removed by AI. Restoring original subtasks.'
|
||||
);
|
||||
updatedTask.subtasks = taskToUpdate.subtasks;
|
||||
} else {
|
||||
const completedOriginal = taskToUpdate.subtasks.filter(
|
||||
(st) => st.status === 'done' || st.status === 'completed'
|
||||
);
|
||||
completedOriginal.forEach((compSub) => {
|
||||
const updatedSub = updatedTask.subtasks.find(
|
||||
(st) => st.id === compSub.id
|
||||
);
|
||||
if (
|
||||
!updatedSub ||
|
||||
JSON.stringify(updatedSub) !== JSON.stringify(compSub)
|
||||
) {
|
||||
report(
|
||||
'warn',
|
||||
`Completed subtask ${compSub.id} was modified or removed. Restoring.`
|
||||
);
|
||||
// Remove potentially modified version
|
||||
updatedTask.subtasks = updatedTask.subtasks.filter(
|
||||
(st) => st.id !== compSub.id
|
||||
);
|
||||
// Add back original
|
||||
updatedTask.subtasks.push(compSub);
|
||||
}
|
||||
});
|
||||
// Deduplicate just in case
|
||||
const subtaskIds = new Set();
|
||||
updatedTask.subtasks = updatedTask.subtasks.filter((st) => {
|
||||
if (!subtaskIds.has(st.id)) {
|
||||
subtaskIds.add(st.id);
|
||||
return true;
|
||||
}
|
||||
report('warn', `Duplicate subtask ID ${st.id} removed.`);
|
||||
return false;
|
||||
});
|
||||
}
|
||||
}
|
||||
// --- End Task Validation/Correction ---
|
||||
|
||||
// --- Update Task Data (Keep existing) ---
|
||||
data.tasks[taskIndex] = updatedTask;
|
||||
// --- End Update Task Data ---
|
||||
|
||||
// --- Write File and Generate (Unchanged) ---
|
||||
writeJSON(tasksPath, data);
|
||||
report('success', `Successfully updated task ${taskId}`);
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
// --- End Write File ---
|
||||
|
||||
// --- Display CLI Telemetry ---
|
||||
if (outputFormat === 'text' && aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli'); // <<< ADD display
|
||||
}
|
||||
|
||||
// --- Return Success with Telemetry ---
|
||||
return {
|
||||
updatedTask: updatedTask, // Return the updated task object
|
||||
telemetryData: aiServiceResponse.telemetryData // <<< ADD telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
// Catch errors from generateTextService
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
@@ -407,114 +500,7 @@ The changes described in the prompt should be thoughtfully applied to make the t
|
||||
report('error', 'Please ensure API keys are configured correctly.');
|
||||
}
|
||||
throw error; // Re-throw error
|
||||
} finally {
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
}
|
||||
|
||||
// --- Parse and Validate Response ---
|
||||
try {
|
||||
// Pass logFn and isMCP flag to the parser
|
||||
updatedTask = parseUpdatedTaskFromText(
|
||||
responseText,
|
||||
taskId,
|
||||
logFn,
|
||||
isMCP
|
||||
);
|
||||
} catch (parseError) {
|
||||
report(
|
||||
'error',
|
||||
`Failed to parse updated task from AI response: ${parseError.message}`
|
||||
);
|
||||
if (getDebugFlag(session)) {
|
||||
report('error', `Raw AI Response:\n${responseText}`);
|
||||
}
|
||||
throw new Error(
|
||||
`Failed to parse valid updated task from AI response: ${parseError.message}`
|
||||
);
|
||||
}
|
||||
// --- End Parse/Validate ---
|
||||
|
||||
// --- Task Validation/Correction (Keep existing logic) ---
|
||||
if (!updatedTask || typeof updatedTask !== 'object')
|
||||
throw new Error('Received invalid task object from AI.');
|
||||
if (!updatedTask.title || !updatedTask.description)
|
||||
throw new Error('Updated task missing required fields.');
|
||||
// Preserve ID if AI changed it
|
||||
if (updatedTask.id !== taskId) {
|
||||
report('warn', `AI changed task ID. Restoring original ID ${taskId}.`);
|
||||
updatedTask.id = taskId;
|
||||
}
|
||||
// Preserve status if AI changed it
|
||||
if (
|
||||
updatedTask.status !== taskToUpdate.status &&
|
||||
!prompt.toLowerCase().includes('status')
|
||||
) {
|
||||
report(
|
||||
'warn',
|
||||
`AI changed task status. Restoring original status '${taskToUpdate.status}'.`
|
||||
);
|
||||
updatedTask.status = taskToUpdate.status;
|
||||
}
|
||||
// Preserve completed subtasks (Keep existing logic)
|
||||
if (taskToUpdate.subtasks?.length > 0) {
|
||||
if (!updatedTask.subtasks) {
|
||||
report('warn', 'Subtasks removed by AI. Restoring original subtasks.');
|
||||
updatedTask.subtasks = taskToUpdate.subtasks;
|
||||
} else {
|
||||
const completedOriginal = taskToUpdate.subtasks.filter(
|
||||
(st) => st.status === 'done' || st.status === 'completed'
|
||||
);
|
||||
completedOriginal.forEach((compSub) => {
|
||||
const updatedSub = updatedTask.subtasks.find(
|
||||
(st) => st.id === compSub.id
|
||||
);
|
||||
if (
|
||||
!updatedSub ||
|
||||
JSON.stringify(updatedSub) !== JSON.stringify(compSub)
|
||||
) {
|
||||
report(
|
||||
'warn',
|
||||
`Completed subtask ${compSub.id} was modified or removed. Restoring.`
|
||||
);
|
||||
// Remove potentially modified version
|
||||
updatedTask.subtasks = updatedTask.subtasks.filter(
|
||||
(st) => st.id !== compSub.id
|
||||
);
|
||||
// Add back original
|
||||
updatedTask.subtasks.push(compSub);
|
||||
}
|
||||
});
|
||||
// Deduplicate just in case
|
||||
const subtaskIds = new Set();
|
||||
updatedTask.subtasks = updatedTask.subtasks.filter((st) => {
|
||||
if (!subtaskIds.has(st.id)) {
|
||||
subtaskIds.add(st.id);
|
||||
return true;
|
||||
}
|
||||
report('warn', `Duplicate subtask ID ${st.id} removed.`);
|
||||
return false;
|
||||
});
|
||||
}
|
||||
}
|
||||
// --- End Task Validation/Correction ---
|
||||
|
||||
// --- Update Task Data (Keep existing) ---
|
||||
data.tasks[taskIndex] = updatedTask;
|
||||
// --- End Update Task Data ---
|
||||
|
||||
// --- Write File and Generate (Keep existing) ---
|
||||
writeJSON(tasksPath, data);
|
||||
report('success', `Successfully updated task ${taskId}`);
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
// --- End Write File ---
|
||||
|
||||
// --- Final CLI Output (Keep existing) ---
|
||||
if (outputFormat === 'text') {
|
||||
/* ... success boxen ... */
|
||||
}
|
||||
// --- End Final CLI Output ---
|
||||
|
||||
return updatedTask; // Return the updated task
|
||||
} catch (error) {
|
||||
// General error catch
|
||||
// --- General Error Handling (Keep existing) ---
|
||||
|
||||
@@ -15,7 +15,8 @@ import {
|
||||
import {
|
||||
getStatusWithColor,
|
||||
startLoadingIndicator,
|
||||
stopLoadingIndicator
|
||||
stopLoadingIndicator,
|
||||
displayAiUsageSummary
|
||||
} from '../ui.js';
|
||||
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
@@ -93,10 +94,6 @@ function parseUpdatedTasksFromText(text, expectedCount, logFn, isMCP) {
|
||||
// It worked! Use this as the primary cleaned response.
|
||||
cleanedResponse = potentialJsonFromArray;
|
||||
parseMethodUsed = 'brackets';
|
||||
report(
|
||||
'info',
|
||||
'Successfully parsed JSON content extracted between first [ and last ].'
|
||||
);
|
||||
} catch (e) {
|
||||
report(
|
||||
'info',
|
||||
@@ -350,31 +347,100 @@ The changes described in the prompt should be applied to ALL tasks in the list.`
|
||||
const userPrompt = `Here are the tasks to update:\n${taskDataString}\n\nPlease update these tasks based on the following new context:\n${prompt}\n\nIMPORTANT: In the tasks JSON above, any subtasks with "status": "done" or "status": "completed" should be preserved exactly as is. Build your changes around these completed items.\n\nReturn only the updated tasks as a valid JSON array.`;
|
||||
// --- End Build Prompts ---
|
||||
|
||||
// --- AI Call ---
|
||||
let loadingIndicator = null;
|
||||
if (outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator('Updating tasks...\n');
|
||||
let aiServiceResponse = null;
|
||||
|
||||
if (!isMCP && outputFormat === 'text') {
|
||||
loadingIndicator = startLoadingIndicator('Updating tasks with AI...\n');
|
||||
}
|
||||
|
||||
let responseText = '';
|
||||
let updatedTasks;
|
||||
|
||||
try {
|
||||
// --- Call Unified AI Service ---
|
||||
const role = useResearch ? 'research' : 'main';
|
||||
if (isMCP) logFn.info(`Using AI service with role: ${role}`);
|
||||
else logFn('info', `Using AI service with role: ${role}`);
|
||||
// Determine role based on research flag
|
||||
const serviceRole = useResearch ? 'research' : 'main';
|
||||
|
||||
responseText = await generateTextService({
|
||||
prompt: userPrompt,
|
||||
// Call the unified AI service
|
||||
aiServiceResponse = await generateTextService({
|
||||
role: serviceRole,
|
||||
session: session,
|
||||
projectRoot: projectRoot,
|
||||
systemPrompt: systemPrompt,
|
||||
role,
|
||||
session,
|
||||
projectRoot
|
||||
prompt: userPrompt,
|
||||
commandName: 'update-tasks',
|
||||
outputType: isMCP ? 'mcp' : 'cli'
|
||||
});
|
||||
if (isMCP) logFn.info('Successfully received text response');
|
||||
|
||||
if (loadingIndicator)
|
||||
stopLoadingIndicator(loadingIndicator, 'AI update complete.');
|
||||
|
||||
// Use the mainResult (text) for parsing
|
||||
const parsedUpdatedTasks = parseUpdatedTasksFromText(
|
||||
aiServiceResponse.mainResult,
|
||||
tasksToUpdate.length,
|
||||
logFn,
|
||||
isMCP
|
||||
);
|
||||
|
||||
// --- Update Tasks Data (Unchanged) ---
|
||||
if (!Array.isArray(parsedUpdatedTasks)) {
|
||||
// Should be caught by parser, but extra check
|
||||
throw new Error(
|
||||
'Parsed AI response for updated tasks was not an array.'
|
||||
);
|
||||
}
|
||||
if (isMCP)
|
||||
logFn.info(
|
||||
`Received ${parsedUpdatedTasks.length} updated tasks from AI.`
|
||||
);
|
||||
else
|
||||
logFn('success', 'Successfully received text response via AI service');
|
||||
// --- End AI Service Call ---
|
||||
logFn(
|
||||
'info',
|
||||
`Received ${parsedUpdatedTasks.length} updated tasks from AI.`
|
||||
);
|
||||
// Create a map for efficient lookup
|
||||
const updatedTasksMap = new Map(
|
||||
parsedUpdatedTasks.map((task) => [task.id, task])
|
||||
);
|
||||
|
||||
let actualUpdateCount = 0;
|
||||
data.tasks.forEach((task, index) => {
|
||||
if (updatedTasksMap.has(task.id)) {
|
||||
// Only update if the task was part of the set sent to AI
|
||||
data.tasks[index] = updatedTasksMap.get(task.id);
|
||||
actualUpdateCount++;
|
||||
}
|
||||
});
|
||||
if (isMCP)
|
||||
logFn.info(
|
||||
`Applied updates to ${actualUpdateCount} tasks in the dataset.`
|
||||
);
|
||||
else
|
||||
logFn(
|
||||
'info',
|
||||
`Applied updates to ${actualUpdateCount} tasks in the dataset.`
|
||||
);
|
||||
|
||||
writeJSON(tasksPath, data);
|
||||
if (isMCP)
|
||||
logFn.info(
|
||||
`Successfully updated ${actualUpdateCount} tasks in ${tasksPath}`
|
||||
);
|
||||
else
|
||||
logFn(
|
||||
'success',
|
||||
`Successfully updated ${actualUpdateCount} tasks in ${tasksPath}`
|
||||
);
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
|
||||
if (outputFormat === 'text' && aiServiceResponse.telemetryData) {
|
||||
displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli');
|
||||
}
|
||||
|
||||
return {
|
||||
success: true,
|
||||
updatedTasks: parsedUpdatedTasks,
|
||||
telemetryData: aiServiceResponse.telemetryData
|
||||
};
|
||||
} catch (error) {
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
if (isMCP) logFn.error(`Error during AI service call: ${error.message}`);
|
||||
@@ -390,98 +456,10 @@ The changes described in the prompt should be applied to ALL tasks in the list.`
|
||||
'Please ensure API keys are configured correctly in .env or mcp.json.'
|
||||
);
|
||||
}
|
||||
throw error; // Re-throw error
|
||||
throw error;
|
||||
} finally {
|
||||
if (loadingIndicator) stopLoadingIndicator(loadingIndicator);
|
||||
}
|
||||
|
||||
// --- Parse and Validate Response ---
|
||||
try {
|
||||
updatedTasks = parseUpdatedTasksFromText(
|
||||
responseText,
|
||||
tasksToUpdate.length,
|
||||
logFn,
|
||||
isMCP
|
||||
);
|
||||
} catch (parseError) {
|
||||
if (isMCP)
|
||||
logFn.error(
|
||||
`Failed to parse updated tasks from AI response: ${parseError.message}`
|
||||
);
|
||||
else
|
||||
logFn(
|
||||
'error',
|
||||
`Failed to parse updated tasks from AI response: ${parseError.message}`
|
||||
);
|
||||
if (getDebugFlag(session)) {
|
||||
if (isMCP) logFn.error(`Raw AI Response:\n${responseText}`);
|
||||
else logFn('error', `Raw AI Response:\n${responseText}`);
|
||||
}
|
||||
throw new Error(
|
||||
`Failed to parse valid updated tasks from AI response: ${parseError.message}`
|
||||
);
|
||||
}
|
||||
// --- End Parse/Validate ---
|
||||
|
||||
// --- Update Tasks Data (Unchanged) ---
|
||||
if (!Array.isArray(updatedTasks)) {
|
||||
// Should be caught by parser, but extra check
|
||||
throw new Error('Parsed AI response for updated tasks was not an array.');
|
||||
}
|
||||
if (isMCP)
|
||||
logFn.info(`Received ${updatedTasks.length} updated tasks from AI.`);
|
||||
else
|
||||
logFn('info', `Received ${updatedTasks.length} updated tasks from AI.`);
|
||||
// Create a map for efficient lookup
|
||||
const updatedTasksMap = new Map(
|
||||
updatedTasks.map((task) => [task.id, task])
|
||||
);
|
||||
|
||||
// Iterate through the original data and update based on the map
|
||||
let actualUpdateCount = 0;
|
||||
data.tasks.forEach((task, index) => {
|
||||
if (updatedTasksMap.has(task.id)) {
|
||||
// Only update if the task was part of the set sent to AI
|
||||
data.tasks[index] = updatedTasksMap.get(task.id);
|
||||
actualUpdateCount++;
|
||||
}
|
||||
});
|
||||
if (isMCP)
|
||||
logFn.info(
|
||||
`Applied updates to ${actualUpdateCount} tasks in the dataset.`
|
||||
);
|
||||
else
|
||||
logFn(
|
||||
'info',
|
||||
`Applied updates to ${actualUpdateCount} tasks in the dataset.`
|
||||
);
|
||||
// --- End Update Tasks Data ---
|
||||
|
||||
// --- Write File and Generate (Unchanged) ---
|
||||
writeJSON(tasksPath, data);
|
||||
if (isMCP)
|
||||
logFn.info(
|
||||
`Successfully updated ${actualUpdateCount} tasks in ${tasksPath}`
|
||||
);
|
||||
else
|
||||
logFn(
|
||||
'success',
|
||||
`Successfully updated ${actualUpdateCount} tasks in ${tasksPath}`
|
||||
);
|
||||
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
|
||||
// --- End Write File ---
|
||||
|
||||
// --- Final CLI Output (Unchanged) ---
|
||||
if (outputFormat === 'text') {
|
||||
console.log(
|
||||
boxen(chalk.green(`Successfully updated ${actualUpdateCount} tasks`), {
|
||||
padding: 1,
|
||||
borderColor: 'green',
|
||||
borderStyle: 'round'
|
||||
})
|
||||
);
|
||||
}
|
||||
// --- End Final CLI Output ---
|
||||
} catch (error) {
|
||||
// --- General Error Handling (Unchanged) ---
|
||||
if (isMCP) logFn.error(`Error updating tasks: ${error.message}`);
|
||||
|
||||
@@ -17,7 +17,11 @@ import {
|
||||
isSilentMode
|
||||
} from './utils.js';
|
||||
import fs from 'fs';
|
||||
import { findNextTask, analyzeTaskComplexity } from './task-manager.js';
|
||||
import {
|
||||
findNextTask,
|
||||
analyzeTaskComplexity,
|
||||
readComplexityReport
|
||||
} from './task-manager.js';
|
||||
import { getProjectName, getDefaultSubtasks } from './config-manager.js';
|
||||
import { TASK_STATUS_OPTIONS } from '../../src/constants/task-status.js';
|
||||
import { getTaskMasterVersion } from '../../src/utils/getVersion.js';
|
||||
@@ -264,12 +268,14 @@ function getStatusWithColor(status, forTable = false) {
|
||||
* @param {Array} dependencies - Array of dependency IDs
|
||||
* @param {Array} allTasks - Array of all tasks
|
||||
* @param {boolean} forConsole - Whether the output is for console display
|
||||
* @param {Object|null} complexityReport - Optional pre-loaded complexity report
|
||||
* @returns {string} Formatted dependencies string
|
||||
*/
|
||||
function formatDependenciesWithStatus(
|
||||
dependencies,
|
||||
allTasks,
|
||||
forConsole = false
|
||||
forConsole = false,
|
||||
complexityReport = null // Add complexityReport parameter
|
||||
) {
|
||||
if (
|
||||
!dependencies ||
|
||||
@@ -333,7 +339,11 @@ function formatDependenciesWithStatus(
|
||||
typeof depId === 'string' ? parseInt(depId, 10) : depId;
|
||||
|
||||
// Look up the task using the numeric ID
|
||||
const depTaskResult = findTaskById(allTasks, numericDepId);
|
||||
const depTaskResult = findTaskById(
|
||||
allTasks,
|
||||
numericDepId,
|
||||
complexityReport
|
||||
);
|
||||
const depTask = depTaskResult.task; // Access the task object from the result
|
||||
|
||||
if (!depTask) {
|
||||
@@ -752,7 +762,7 @@ function truncateString(str, maxLength) {
|
||||
* Display the next task to work on
|
||||
* @param {string} tasksPath - Path to the tasks.json file
|
||||
*/
|
||||
async function displayNextTask(tasksPath) {
|
||||
async function displayNextTask(tasksPath, complexityReportPath = null) {
|
||||
displayBanner();
|
||||
|
||||
// Read the tasks file
|
||||
@@ -762,8 +772,11 @@ async function displayNextTask(tasksPath) {
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Read complexity report once
|
||||
const complexityReport = readComplexityReport(complexityReportPath);
|
||||
|
||||
// Find the next task
|
||||
const nextTask = findNextTask(data.tasks);
|
||||
const nextTask = findNextTask(data.tasks, complexityReport);
|
||||
|
||||
if (!nextTask) {
|
||||
console.log(
|
||||
@@ -824,7 +837,18 @@ async function displayNextTask(tasksPath) {
|
||||
],
|
||||
[
|
||||
chalk.cyan.bold('Dependencies:'),
|
||||
formatDependenciesWithStatus(nextTask.dependencies, data.tasks, true)
|
||||
formatDependenciesWithStatus(
|
||||
nextTask.dependencies,
|
||||
data.tasks,
|
||||
true,
|
||||
complexityReport
|
||||
)
|
||||
],
|
||||
[
|
||||
chalk.cyan.bold('Complexity:'),
|
||||
nextTask.complexityScore
|
||||
? getComplexityWithColor(nextTask.complexityScore)
|
||||
: chalk.gray('N/A')
|
||||
],
|
||||
[chalk.cyan.bold('Description:'), nextTask.description]
|
||||
);
|
||||
@@ -846,8 +870,11 @@ async function displayNextTask(tasksPath) {
|
||||
);
|
||||
}
|
||||
|
||||
// Show subtasks if they exist
|
||||
if (nextTask.subtasks && nextTask.subtasks.length > 0) {
|
||||
// Determine if the nextTask is a subtask
|
||||
const isSubtask = !!nextTask.parentId;
|
||||
|
||||
// Show subtasks if they exist (only for parent tasks)
|
||||
if (!isSubtask && nextTask.subtasks && nextTask.subtasks.length > 0) {
|
||||
console.log(
|
||||
boxen(chalk.white.bold('Subtasks'), {
|
||||
padding: { top: 0, bottom: 0, left: 1, right: 1 },
|
||||
@@ -947,8 +974,10 @@ async function displayNextTask(tasksPath) {
|
||||
});
|
||||
|
||||
console.log(subtaskTable.toString());
|
||||
} else {
|
||||
// Suggest expanding if no subtasks
|
||||
}
|
||||
|
||||
// Suggest expanding if no subtasks (only for parent tasks without subtasks)
|
||||
if (!isSubtask && (!nextTask.subtasks || nextTask.subtasks.length === 0)) {
|
||||
console.log(
|
||||
boxen(
|
||||
chalk.yellow('No subtasks found. Consider breaking down this task:') +
|
||||
@@ -967,22 +996,30 @@ async function displayNextTask(tasksPath) {
|
||||
}
|
||||
|
||||
// Show action suggestions
|
||||
let suggestedActionsContent = chalk.white.bold('Suggested Actions:') + '\n';
|
||||
if (isSubtask) {
|
||||
// Suggested actions for a subtask
|
||||
suggestedActionsContent +=
|
||||
`${chalk.cyan('1.')} Mark as in-progress: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=in-progress`)}\n` +
|
||||
`${chalk.cyan('2.')} Mark as done when completed: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=done`)}\n` +
|
||||
`${chalk.cyan('3.')} View parent task: ${chalk.yellow(`task-master show --id=${nextTask.parentId}`)}`;
|
||||
} else {
|
||||
// Suggested actions for a parent task
|
||||
suggestedActionsContent +=
|
||||
`${chalk.cyan('1.')} Mark as in-progress: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=in-progress`)}\n` +
|
||||
`${chalk.cyan('2.')} Mark as done when completed: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=done`)}\n` +
|
||||
(nextTask.subtasks && nextTask.subtasks.length > 0
|
||||
? `${chalk.cyan('3.')} Update subtask status: ${chalk.yellow(`task-master set-status --id=${nextTask.id}.1 --status=done`)}` // Example: first subtask
|
||||
: `${chalk.cyan('3.')} Break down into subtasks: ${chalk.yellow(`task-master expand --id=${nextTask.id}`)}`);
|
||||
}
|
||||
|
||||
console.log(
|
||||
boxen(
|
||||
chalk.white.bold('Suggested Actions:') +
|
||||
'\n' +
|
||||
`${chalk.cyan('1.')} Mark as in-progress: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=in-progress`)}\n` +
|
||||
`${chalk.cyan('2.')} Mark as done when completed: ${chalk.yellow(`task-master set-status --id=${nextTask.id} --status=done`)}\n` +
|
||||
(nextTask.subtasks && nextTask.subtasks.length > 0
|
||||
? `${chalk.cyan('3.')} Update subtask status: ${chalk.yellow(`task-master set-status --id=${nextTask.id}.1 --status=done`)}`
|
||||
: `${chalk.cyan('3.')} Break down into subtasks: ${chalk.yellow(`task-master expand --id=${nextTask.id}`)}`),
|
||||
{
|
||||
padding: { top: 0, bottom: 0, left: 1, right: 1 },
|
||||
borderColor: 'green',
|
||||
borderStyle: 'round',
|
||||
margin: { top: 1 }
|
||||
}
|
||||
)
|
||||
boxen(suggestedActionsContent, {
|
||||
padding: { top: 0, bottom: 0, left: 1, right: 1 },
|
||||
borderColor: 'green',
|
||||
borderStyle: 'round',
|
||||
margin: { top: 1 }
|
||||
})
|
||||
);
|
||||
}
|
||||
|
||||
@@ -992,7 +1029,12 @@ async function displayNextTask(tasksPath) {
|
||||
* @param {string|number} taskId - The ID of the task to display
|
||||
* @param {string} [statusFilter] - Optional status to filter subtasks by
|
||||
*/
|
||||
async function displayTaskById(tasksPath, taskId, statusFilter = null) {
|
||||
async function displayTaskById(
|
||||
tasksPath,
|
||||
taskId,
|
||||
complexityReportPath = null,
|
||||
statusFilter = null
|
||||
) {
|
||||
displayBanner();
|
||||
|
||||
// Read the tasks file
|
||||
@@ -1002,11 +1044,15 @@ async function displayTaskById(tasksPath, taskId, statusFilter = null) {
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Read complexity report once
|
||||
const complexityReport = readComplexityReport(complexityReportPath);
|
||||
|
||||
// Find the task by ID, applying the status filter if provided
|
||||
// Returns { task, originalSubtaskCount, originalSubtasks }
|
||||
const { task, originalSubtaskCount, originalSubtasks } = findTaskById(
|
||||
data.tasks,
|
||||
taskId,
|
||||
complexityReport,
|
||||
statusFilter
|
||||
);
|
||||
|
||||
@@ -1061,6 +1107,12 @@ async function displayTaskById(tasksPath, taskId, statusFilter = null) {
|
||||
chalk.cyan.bold('Status:'),
|
||||
getStatusWithColor(task.status || 'pending', true)
|
||||
],
|
||||
[
|
||||
chalk.cyan.bold('Complexity:'),
|
||||
task.complexityScore
|
||||
? getComplexityWithColor(task.complexityScore)
|
||||
: chalk.gray('N/A')
|
||||
],
|
||||
[
|
||||
chalk.cyan.bold('Description:'),
|
||||
task.description || 'No description provided.'
|
||||
@@ -1139,7 +1191,18 @@ async function displayTaskById(tasksPath, taskId, statusFilter = null) {
|
||||
[chalk.cyan.bold('Priority:'), priorityColor(task.priority || 'medium')],
|
||||
[
|
||||
chalk.cyan.bold('Dependencies:'),
|
||||
formatDependenciesWithStatus(task.dependencies, data.tasks, true)
|
||||
formatDependenciesWithStatus(
|
||||
task.dependencies,
|
||||
data.tasks,
|
||||
true,
|
||||
complexityReport
|
||||
)
|
||||
],
|
||||
[
|
||||
chalk.cyan.bold('Complexity:'),
|
||||
task.complexityScore
|
||||
? getComplexityWithColor(task.complexityScore)
|
||||
: chalk.gray('N/A')
|
||||
],
|
||||
[chalk.cyan.bold('Description:'), task.description]
|
||||
);
|
||||
@@ -1955,6 +2018,51 @@ function displayAvailableModels(availableModels) {
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Displays AI usage telemetry summary in the CLI.
|
||||
* @param {object} telemetryData - The telemetry data object.
|
||||
* @param {string} outputType - 'cli' or 'mcp' (though typically only called for 'cli').
|
||||
*/
|
||||
function displayAiUsageSummary(telemetryData, outputType = 'cli') {
|
||||
if (
|
||||
(outputType !== 'cli' && outputType !== 'text') ||
|
||||
!telemetryData ||
|
||||
isSilentMode()
|
||||
) {
|
||||
return; // Only display for CLI and if data exists and not in silent mode
|
||||
}
|
||||
|
||||
const {
|
||||
modelUsed,
|
||||
providerName,
|
||||
inputTokens,
|
||||
outputTokens,
|
||||
totalTokens,
|
||||
totalCost,
|
||||
commandName
|
||||
} = telemetryData;
|
||||
|
||||
let summary = chalk.bold.blue('AI Usage Summary:') + '\n';
|
||||
summary += chalk.gray(` Command: ${commandName}\n`);
|
||||
summary += chalk.gray(` Provider: ${providerName}\n`);
|
||||
summary += chalk.gray(` Model: ${modelUsed}\n`);
|
||||
summary += chalk.gray(
|
||||
` Tokens: ${totalTokens} (Input: ${inputTokens}, Output: ${outputTokens})\n`
|
||||
);
|
||||
summary += chalk.gray(` Est. Cost: $${totalCost.toFixed(6)}`);
|
||||
|
||||
console.log(
|
||||
boxen(summary, {
|
||||
padding: 1,
|
||||
margin: { top: 1 },
|
||||
borderColor: 'blue',
|
||||
borderStyle: 'round',
|
||||
title: '💡 Telemetry',
|
||||
titleAlignment: 'center'
|
||||
})
|
||||
);
|
||||
}
|
||||
|
||||
// Export UI functions
|
||||
export {
|
||||
displayBanner,
|
||||
@@ -1972,5 +2080,6 @@ export {
|
||||
confirmTaskOverwrite,
|
||||
displayApiKeyStatus,
|
||||
displayModelConfiguration,
|
||||
displayAvailableModels
|
||||
displayAvailableModels,
|
||||
displayAiUsageSummary
|
||||
};
|
||||
|
||||
@@ -275,6 +275,22 @@ function findTaskInComplexityReport(report, taskId) {
|
||||
return report.complexityAnalysis.find((task) => task.taskId === taskId);
|
||||
}
|
||||
|
||||
function addComplexityToTask(task, complexityReport) {
|
||||
let taskId;
|
||||
if (task.isSubtask) {
|
||||
taskId = task.parentTask.id;
|
||||
} else if (task.parentId) {
|
||||
taskId = task.parentId;
|
||||
} else {
|
||||
taskId = task.id;
|
||||
}
|
||||
|
||||
const taskAnalysis = findTaskInComplexityReport(complexityReport, taskId);
|
||||
if (taskAnalysis) {
|
||||
task.complexityScore = taskAnalysis.complexityScore;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Checks if a task exists in the tasks array
|
||||
* @param {Array} tasks - The tasks array
|
||||
@@ -325,10 +341,17 @@ function formatTaskId(id) {
|
||||
* Finds a task by ID in the tasks array. Optionally filters subtasks by status.
|
||||
* @param {Array} tasks - The tasks array
|
||||
* @param {string|number} taskId - The task ID to find
|
||||
* @param {Object|null} complexityReport - Optional pre-loaded complexity report
|
||||
* @returns {Object|null} The task object or null if not found
|
||||
* @param {string} [statusFilter] - Optional status to filter subtasks by
|
||||
* @returns {{task: Object|null, originalSubtaskCount: number|null}} The task object (potentially with filtered subtasks) and the original subtask count if filtered, or nulls if not found.
|
||||
*/
|
||||
function findTaskById(tasks, taskId, statusFilter = null) {
|
||||
function findTaskById(
|
||||
tasks,
|
||||
taskId,
|
||||
complexityReport = null,
|
||||
statusFilter = null
|
||||
) {
|
||||
if (!taskId || !tasks || !Array.isArray(tasks)) {
|
||||
return { task: null, originalSubtaskCount: null };
|
||||
}
|
||||
@@ -356,10 +379,17 @@ function findTaskById(tasks, taskId, statusFilter = null) {
|
||||
subtask.isSubtask = true;
|
||||
}
|
||||
|
||||
// Return the found subtask (or null) and null for originalSubtaskCount
|
||||
// If we found a task, check for complexity data
|
||||
if (subtask && complexityReport) {
|
||||
addComplexityToTask(subtask, complexityReport);
|
||||
}
|
||||
|
||||
return { task: subtask || null, originalSubtaskCount: null };
|
||||
}
|
||||
|
||||
let taskResult = null;
|
||||
let originalSubtaskCount = null;
|
||||
|
||||
// Find the main task
|
||||
const id = parseInt(taskId, 10);
|
||||
const task = tasks.find((t) => t.id === id) || null;
|
||||
@@ -369,6 +399,8 @@ function findTaskById(tasks, taskId, statusFilter = null) {
|
||||
return { task: null, originalSubtaskCount: null };
|
||||
}
|
||||
|
||||
taskResult = task;
|
||||
|
||||
// If task found and statusFilter provided, filter its subtasks
|
||||
if (statusFilter && task.subtasks && Array.isArray(task.subtasks)) {
|
||||
const originalSubtaskCount = task.subtasks.length;
|
||||
@@ -379,12 +411,18 @@ function findTaskById(tasks, taskId, statusFilter = null) {
|
||||
subtask.status &&
|
||||
subtask.status.toLowerCase() === statusFilter.toLowerCase()
|
||||
);
|
||||
// Return the filtered task and the original count
|
||||
return { task: filteredTask, originalSubtaskCount: originalSubtaskCount };
|
||||
|
||||
taskResult = filteredTask;
|
||||
originalSubtaskCount = originalSubtaskCount;
|
||||
}
|
||||
|
||||
// Return original task and null count if no filter or no subtasks
|
||||
return { task: task, originalSubtaskCount: null };
|
||||
// If task found and complexityReport provided, add complexity data
|
||||
if (taskResult && complexityReport) {
|
||||
addComplexityToTask(taskResult, complexityReport);
|
||||
}
|
||||
|
||||
// Return the found task and original subtask count
|
||||
return { task: taskResult, originalSubtaskCount };
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -508,6 +546,61 @@ function detectCamelCaseFlags(args) {
|
||||
return camelCaseFlags;
|
||||
}
|
||||
|
||||
/**
|
||||
* Aggregates an array of telemetry objects into a single summary object.
|
||||
* @param {Array<Object>} telemetryArray - Array of telemetryData objects.
|
||||
* @param {string} overallCommandName - The name for the aggregated command.
|
||||
* @returns {Object|null} Aggregated telemetry object or null if input is empty.
|
||||
*/
|
||||
function aggregateTelemetry(telemetryArray, overallCommandName) {
|
||||
if (!telemetryArray || telemetryArray.length === 0) {
|
||||
return null;
|
||||
}
|
||||
|
||||
const aggregated = {
|
||||
timestamp: new Date().toISOString(), // Use current time for aggregation time
|
||||
userId: telemetryArray[0].userId, // Assume userId is consistent
|
||||
commandName: overallCommandName,
|
||||
modelUsed: 'Multiple', // Default if models vary
|
||||
providerName: 'Multiple', // Default if providers vary
|
||||
inputTokens: 0,
|
||||
outputTokens: 0,
|
||||
totalTokens: 0,
|
||||
totalCost: 0,
|
||||
currency: telemetryArray[0].currency || 'USD' // Assume consistent currency or default
|
||||
};
|
||||
|
||||
const uniqueModels = new Set();
|
||||
const uniqueProviders = new Set();
|
||||
const uniqueCurrencies = new Set();
|
||||
|
||||
telemetryArray.forEach((item) => {
|
||||
aggregated.inputTokens += item.inputTokens || 0;
|
||||
aggregated.outputTokens += item.outputTokens || 0;
|
||||
aggregated.totalCost += item.totalCost || 0;
|
||||
uniqueModels.add(item.modelUsed);
|
||||
uniqueProviders.add(item.providerName);
|
||||
uniqueCurrencies.add(item.currency || 'USD');
|
||||
});
|
||||
|
||||
aggregated.totalTokens = aggregated.inputTokens + aggregated.outputTokens;
|
||||
aggregated.totalCost = parseFloat(aggregated.totalCost.toFixed(6)); // Fix precision
|
||||
|
||||
if (uniqueModels.size === 1) {
|
||||
aggregated.modelUsed = [...uniqueModels][0];
|
||||
}
|
||||
if (uniqueProviders.size === 1) {
|
||||
aggregated.providerName = [...uniqueProviders][0];
|
||||
}
|
||||
if (uniqueCurrencies.size > 1) {
|
||||
aggregated.currency = 'Multiple'; // Mark if currencies actually differ
|
||||
} else if (uniqueCurrencies.size === 1) {
|
||||
aggregated.currency = [...uniqueCurrencies][0];
|
||||
}
|
||||
|
||||
return aggregated;
|
||||
}
|
||||
|
||||
// Export all utility functions and configuration
|
||||
export {
|
||||
LOG_LEVELS,
|
||||
@@ -524,10 +617,12 @@ export {
|
||||
findCycles,
|
||||
toKebabCase,
|
||||
detectCamelCaseFlags,
|
||||
enableSilentMode,
|
||||
disableSilentMode,
|
||||
isSilentMode,
|
||||
resolveEnvVariable,
|
||||
enableSilentMode,
|
||||
getTaskManager,
|
||||
findProjectRoot
|
||||
isSilentMode,
|
||||
addComplexityToTask,
|
||||
resolveEnvVariable,
|
||||
findProjectRoot,
|
||||
aggregateTelemetry
|
||||
};
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"meta": {
|
||||
"generatedAt": "2025-05-03T04:45:36.864Z",
|
||||
"tasksAnalyzed": 36,
|
||||
"generatedAt": "2025-05-17T22:29:22.179Z",
|
||||
"tasksAnalyzed": 40,
|
||||
"thresholdScore": 5,
|
||||
"projectName": "Taskmaster",
|
||||
"usedResearch": false
|
||||
@@ -10,290 +10,322 @@
|
||||
{
|
||||
"taskId": 24,
|
||||
"taskTitle": "Implement AI-Powered Test Generation Command",
|
||||
"complexityScore": 8,
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement AI-Powered Test Generation Command' task by detailing the specific steps required for AI prompt engineering, including data extraction, prompt formatting, and error handling.",
|
||||
"reasoning": "Requires AI integration, complex logic, and thorough testing. Prompt engineering and API interaction add significant complexity."
|
||||
"expansionPrompt": "Break down the implementation of the AI-powered test generation command into detailed subtasks covering: command structure setup, AI prompt engineering, test file generation logic, integration with Claude API, and comprehensive error handling.",
|
||||
"reasoning": "This task involves complex integration with an AI service (Claude), requires sophisticated prompt engineering, and needs to generate structured code files. The existing 3 subtasks are a good start but could be expanded to include more detailed steps for AI integration, error handling, and test file formatting."
|
||||
},
|
||||
{
|
||||
"taskId": 26,
|
||||
"taskTitle": "Implement Context Foundation for AI Operations",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Implement Context Foundation for AI Operations' task by detailing the specific steps for integrating file reading, cursor rules, and basic context extraction into the Claude API prompts.",
|
||||
"reasoning": "Involves modifying multiple commands and integrating different context sources. Error handling and backwards compatibility are crucial."
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "The current 4 subtasks for implementing the context foundation appear comprehensive. Consider if any additional subtasks are needed for testing, documentation, or integration with existing systems.",
|
||||
"reasoning": "This task involves creating a foundation for context integration with several well-defined components. The existing 4 subtasks cover the main implementation areas (context-file flag, cursor rules integration, context extraction utility, and command handler updates). The complexity is moderate as it requires careful integration with existing systems but has clear requirements."
|
||||
},
|
||||
{
|
||||
"taskId": 27,
|
||||
"taskTitle": "Implement Context Enhancements for AI Operations",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Implement Context Enhancements for AI Operations' task by detailing the specific steps for code context extraction, task history integration, and PRD context integration, including parsing, summarization, and formatting.",
|
||||
"reasoning": "Builds upon the previous task with more sophisticated context extraction and integration. Requires intelligent parsing and summarization."
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "The current 4 subtasks for implementing context enhancements appear well-structured. Consider if any additional subtasks are needed for testing, documentation, or performance optimization.",
|
||||
"reasoning": "This task builds upon the foundation from Task #26 and adds more sophisticated context handling features. The 4 existing subtasks cover the main implementation areas (code context extraction, task history context, PRD context integration, and context formatting). The complexity is higher than the foundation task due to the need for intelligent context selection and optimization."
|
||||
},
|
||||
{
|
||||
"taskId": 28,
|
||||
"taskTitle": "Implement Advanced ContextManager System",
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Implement Advanced ContextManager System' task by detailing the specific steps for creating the ContextManager class, implementing the optimization pipeline, and adding command interface enhancements, including caching and performance monitoring.",
|
||||
"reasoning": "A comprehensive system requiring careful design, optimization, and testing. Involves complex algorithms and performance considerations."
|
||||
},
|
||||
{
|
||||
"taskId": 32,
|
||||
"taskTitle": "Implement \"learn\" Command for Automatic Cursor Rule Generation",
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 10,
|
||||
"expansionPrompt": "Expand the 'Implement \"learn\" Command for Automatic Cursor Rule Generation' task by detailing the specific steps for Cursor data analysis, rule management, and AI integration, including error handling and performance optimization.",
|
||||
"reasoning": "Requires deep integration with Cursor's data, complex pattern analysis, and AI interaction. Significant error handling and performance optimization are needed."
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the advanced ContextManager system appear comprehensive. Consider if any additional subtasks are needed for testing, documentation, or backward compatibility with previous context implementations.",
|
||||
"reasoning": "This task represents the most complex phase of the context implementation, requiring a sophisticated class design, optimization algorithms, and integration with multiple systems. The 5 existing subtasks cover the core implementation areas, but the complexity is high due to the need for intelligent context prioritization, token management, and performance monitoring."
|
||||
},
|
||||
{
|
||||
"taskId": 40,
|
||||
"taskTitle": "Implement 'plan' Command for Task Implementation Planning",
|
||||
"complexityScore": 6,
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Implement 'plan' Command for Task Implementation Planning' task by detailing the steps for retrieving task content, generating implementation plans with AI, and formatting the plan within XML tags.",
|
||||
"reasoning": "Involves AI integration and requires careful formatting and error handling. Switching between Claude and Perplexity adds complexity."
|
||||
"expansionPrompt": "The current 4 subtasks for implementing the 'plan' command appear well-structured. Consider if any additional subtasks are needed for testing, documentation, or integration with existing task management workflows.",
|
||||
"reasoning": "This task involves creating a new command that leverages AI to generate implementation plans. The existing 4 subtasks cover the main implementation areas (retrieving task content, generating plans with AI, formatting in XML, and error handling). The complexity is moderate as it builds on existing patterns for task updates but requires careful AI integration."
|
||||
},
|
||||
{
|
||||
"taskId": 41,
|
||||
"taskTitle": "Implement Visual Task Dependency Graph in Terminal",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 8,
|
||||
"expansionPrompt": "Expand the 'Implement Visual Task Dependency Graph in Terminal' task by detailing the steps for designing the graph rendering system, implementing layout algorithms, and handling circular dependencies and filtering options.",
|
||||
"reasoning": "Requires complex graph algorithms and terminal rendering. Accessibility and performance are important considerations."
|
||||
"recommendedSubtasks": 10,
|
||||
"expansionPrompt": "The current 10 subtasks for implementing the visual task dependency graph appear comprehensive. Consider if any additional subtasks are needed for performance optimization with large graphs or additional visualization options.",
|
||||
"reasoning": "This task involves creating a sophisticated visualization system for terminal display, which is inherently complex due to layout algorithms, ASCII/Unicode rendering, and handling complex dependency relationships. The 10 existing subtasks cover all major aspects of implementation, from CLI interface to accessibility features."
|
||||
},
|
||||
{
|
||||
"taskId": 42,
|
||||
"taskTitle": "Implement MCP-to-MCP Communication Protocol",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Implement MCP-to-MCP Communication Protocol' task by detailing the steps for defining the protocol, implementing the adapter pattern, and building the client module, including error handling and security considerations.",
|
||||
"reasoning": "Requires designing a new protocol and implementing communication with external systems. Security and error handling are critical."
|
||||
},
|
||||
{
|
||||
"taskId": 43,
|
||||
"taskTitle": "Add Research Flag to Add-Task Command",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 3,
|
||||
"expansionPrompt": "Expand the 'Add Research Flag to Add-Task Command' task by detailing the steps for updating the command parser, generating research subtasks, and linking them to the parent task.",
|
||||
"reasoning": "Relatively straightforward, but requires careful handling of subtask generation and linking."
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 8,
|
||||
"expansionPrompt": "The current 8 subtasks for implementing the MCP-to-MCP communication protocol appear well-structured. Consider if any additional subtasks are needed for security hardening, performance optimization, or comprehensive documentation.",
|
||||
"reasoning": "This task involves designing and implementing a complex communication protocol between different MCP tools and servers. It requires sophisticated adapter patterns, client-server architecture, and handling of multiple operational modes. The complexity is very high due to the need for standardization, security, and backward compatibility."
|
||||
},
|
||||
{
|
||||
"taskId": 44,
|
||||
"taskTitle": "Implement Task Automation with Webhooks and Event Triggers",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Implement Task Automation with Webhooks and Event Triggers' task by detailing the steps for implementing the webhook registration system, event system, and trigger definition interface, including security and error handling.",
|
||||
"reasoning": "Requires designing a robust event system and integrating with external services. Security and error handling are critical."
|
||||
"expansionPrompt": "The current 7 subtasks for implementing task automation with webhooks appear comprehensive. Consider if any additional subtasks are needed for security testing, rate limiting implementation, or webhook monitoring tools.",
|
||||
"reasoning": "This task involves creating a sophisticated event system with webhooks for integration with external services. The complexity is high due to the need for secure authentication, reliable delivery mechanisms, and handling of various webhook formats and protocols. The existing subtasks cover the main implementation areas but security and monitoring could be emphasized more."
|
||||
},
|
||||
{
|
||||
"taskId": 45,
|
||||
"taskTitle": "Implement GitHub Issue Import Feature",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement GitHub Issue Import Feature' task by detailing the steps for parsing the URL, fetching issue details from the GitHub API, and generating a well-formatted task.",
|
||||
"reasoning": "Requires interacting with the GitHub API and handling various error conditions. Authentication adds complexity."
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the GitHub issue import feature appear well-structured. Consider if any additional subtasks are needed for handling GitHub API rate limiting, caching, or supporting additional issue metadata.",
|
||||
"reasoning": "This task involves integrating with the GitHub API to import issues as tasks. The complexity is moderate as it requires API authentication, data mapping, and error handling. The existing 5 subtasks cover the main implementation areas from design to end-to-end implementation."
|
||||
},
|
||||
{
|
||||
"taskId": 46,
|
||||
"taskTitle": "Implement ICE Analysis Command for Task Prioritization",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement ICE Analysis Command for Task Prioritization' task by detailing the steps for calculating ICE scores, generating the report file, and implementing the CLI rendering.",
|
||||
"reasoning": "Requires AI integration for scoring and careful formatting of the report. Integration with existing complexity reports adds complexity."
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the ICE analysis command appear comprehensive. Consider if any additional subtasks are needed for visualization of ICE scores or integration with other prioritization methods.",
|
||||
"reasoning": "This task involves creating an AI-powered analysis system for task prioritization using the ICE methodology. The complexity is high due to the need for sophisticated scoring algorithms, AI integration, and report generation. The existing subtasks cover the main implementation areas from algorithm design to integration with existing systems."
|
||||
},
|
||||
{
|
||||
"taskId": 47,
|
||||
"taskTitle": "Enhance Task Suggestion Actions Card Workflow",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Enhance Task Suggestion Actions Card Workflow' task by detailing the steps for implementing the task expansion, context addition, and task management phases, including UI/UX considerations.",
|
||||
"reasoning": "Requires significant UI/UX work and careful state management. Integration with existing functionality is crucial."
|
||||
"expansionPrompt": "The current 6 subtasks for enhancing the task suggestion actions card workflow appear well-structured. Consider if any additional subtasks are needed for user testing, accessibility improvements, or performance optimization.",
|
||||
"reasoning": "This task involves redesigning the UI workflow for task expansion and management. The complexity is moderate as it requires careful UX design and state management but builds on existing components. The 6 existing subtasks cover the main implementation areas from design to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 48,
|
||||
"taskTitle": "Refactor Prompts into Centralized Structure",
|
||||
"complexityScore": 5,
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 3,
|
||||
"expansionPrompt": "Expand the 'Refactor Prompts into Centralized Structure' task by detailing the steps for creating the 'prompts' directory, extracting prompts into individual files, and updating functions to import them.",
|
||||
"reasoning": "Primarily a refactoring task, but requires careful attention to detail to avoid breaking existing functionality."
|
||||
"expansionPrompt": "The current 3 subtasks for refactoring prompts into a centralized structure appear appropriate. Consider if any additional subtasks are needed for prompt versioning, documentation, or testing.",
|
||||
"reasoning": "This task involves a straightforward refactoring to improve code organization. The complexity is relatively low as it primarily involves moving code rather than creating new functionality. The 3 existing subtasks cover the main implementation areas from directory structure to integration."
|
||||
},
|
||||
{
|
||||
"taskId": 49,
|
||||
"taskTitle": "Implement Code Quality Analysis Command",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Implement Code Quality Analysis Command' task by detailing the steps for pattern recognition, best practice verification, and improvement recommendations, including AI integration and task creation.",
|
||||
"reasoning": "Requires complex code analysis and AI integration. Generating actionable recommendations adds complexity."
|
||||
"expansionPrompt": "The current 6 subtasks for implementing the code quality analysis command appear comprehensive. Consider if any additional subtasks are needed for performance optimization with large codebases or integration with existing code quality tools.",
|
||||
"reasoning": "This task involves creating a sophisticated code analysis system with pattern recognition, best practice verification, and AI-powered recommendations. The complexity is high due to the need for code parsing, complex analysis algorithms, and integration with AI services. The existing subtasks cover the main implementation areas from algorithm design to user interface."
|
||||
},
|
||||
{
|
||||
"taskId": 50,
|
||||
"taskTitle": "Implement Test Coverage Tracking System by Task",
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Implement Test Coverage Tracking System by Task' task by detailing the steps for creating the tests.json file structure, developing the coverage report parser, and implementing the CLI commands and AI-powered test generation system.",
|
||||
"reasoning": "A comprehensive system requiring deep integration with testing tools and AI. Maintaining bidirectional relationships adds complexity."
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the test coverage tracking system appear well-structured. Consider if any additional subtasks are needed for integration with CI/CD systems, performance optimization, or visualization tools.",
|
||||
"reasoning": "This task involves creating a complex system that maps test coverage to specific tasks and subtasks. The complexity is very high due to the need for sophisticated data structures, integration with coverage tools, and AI-powered test generation. The existing subtasks are comprehensive and cover the main implementation areas from data structure design to AI integration."
|
||||
},
|
||||
{
|
||||
"taskId": 51,
|
||||
"taskTitle": "Implement Perplexity Research Command",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement Perplexity Research Command' task by detailing the steps for creating the Perplexity API client, implementing task context extraction, and building the CLI interface.",
|
||||
"reasoning": "Requires API integration and careful formatting of the research results. Caching adds complexity."
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the Perplexity research command appear comprehensive. Consider if any additional subtasks are needed for caching optimization, result formatting, or integration with other research tools.",
|
||||
"reasoning": "This task involves creating a new command that integrates with the Perplexity AI API for research. The complexity is moderate as it requires API integration, context extraction, and result formatting. The 5 existing subtasks cover the main implementation areas from API client to caching system."
|
||||
},
|
||||
{
|
||||
"taskId": 52,
|
||||
"taskTitle": "Implement Task Suggestion Command for CLI",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement Task Suggestion Command for CLI' task by detailing the steps for collecting existing task data, generating task suggestions with AI, and implementing the interactive CLI interface.",
|
||||
"reasoning": "Requires AI integration and careful design of the interactive interface. Handling various flag combinations adds complexity."
|
||||
"expansionPrompt": "The current 5 subtasks for implementing the task suggestion command appear well-structured. Consider if any additional subtasks are needed for suggestion quality evaluation, user feedback collection, or integration with existing task workflows.",
|
||||
"reasoning": "This task involves creating a new CLI command that generates contextually relevant task suggestions using AI. The complexity is moderate as it requires AI integration, context collection, and interactive CLI interfaces. The existing subtasks cover the main implementation areas from data collection to user interface."
|
||||
},
|
||||
{
|
||||
"taskId": 53,
|
||||
"taskTitle": "Implement Subtask Suggestion Feature for Parent Tasks",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Implement Subtask Suggestion Feature for Parent Tasks' task by detailing the steps for validating parent tasks, gathering context, generating subtask suggestions with AI, and implementing the interactive CLI interface.",
|
||||
"reasoning": "Requires AI integration and careful design of the interactive interface. Linking subtasks to parent tasks adds complexity."
|
||||
"expansionPrompt": "The current 6 subtasks for implementing the subtask suggestion feature appear comprehensive. Consider if any additional subtasks are needed for suggestion quality metrics, user feedback collection, or performance optimization.",
|
||||
"reasoning": "This task involves creating a feature that suggests contextually relevant subtasks for parent tasks. The complexity is moderate as it builds on existing task management systems but requires sophisticated AI integration and context analysis. The 6 existing subtasks cover the main implementation areas from validation to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 55,
|
||||
"taskTitle": "Implement Positional Arguments Support for CLI Commands",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement Positional Arguments Support for CLI Commands' task by detailing the steps for updating the argument parsing logic, defining the positional argument order, and handling edge cases.",
|
||||
"reasoning": "Requires careful modification of the command parsing logic and ensuring backward compatibility. Handling edge cases adds complexity."
|
||||
"expansionPrompt": "The current 5 subtasks for implementing positional arguments support appear well-structured. Consider if any additional subtasks are needed for backward compatibility testing, documentation updates, or user experience improvements.",
|
||||
"reasoning": "This task involves modifying the command parsing logic to support positional arguments alongside the existing flag-based syntax. The complexity is moderate as it requires careful handling of different argument styles and edge cases. The 5 existing subtasks cover the main implementation areas from analysis to documentation."
|
||||
},
|
||||
{
|
||||
"taskId": 57,
|
||||
"taskTitle": "Enhance Task-Master CLI User Experience and Interface",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Enhance Task-Master CLI User Experience and Interface' task by detailing the steps for log management, visual enhancements, interactive elements, and output formatting.",
|
||||
"reasoning": "Requires significant UI/UX work and careful consideration of different terminal environments. Reducing verbose logging adds complexity."
|
||||
"expansionPrompt": "The current 6 subtasks for enhancing the CLI user experience appear comprehensive. Consider if any additional subtasks are needed for accessibility testing, internationalization, or performance optimization.",
|
||||
"reasoning": "This task involves a significant overhaul of the CLI interface to improve user experience. The complexity is high due to the breadth of changes (logging, visual elements, interactive components, etc.) and the need for consistent design across all commands. The 6 existing subtasks cover the main implementation areas from log management to help systems."
|
||||
},
|
||||
{
|
||||
"taskId": 60,
|
||||
"taskTitle": "Implement Mentor System with Round-Table Discussion Feature",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Implement Mentor System with Round-Table Discussion Feature' task by detailing the steps for mentor management, round-table discussion implementation, and integration with the task system, including LLM integration.",
|
||||
"reasoning": "Requires complex AI simulation and careful formatting of the discussion output. Integrating with the task system adds complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 61,
|
||||
"taskTitle": "Implement Flexible AI Model Management",
|
||||
"complexityScore": 9,
|
||||
"recommendedSubtasks": 8,
|
||||
"expansionPrompt": "Expand the 'Implement Flexible AI Model Management' task by detailing the steps for creating the configuration management module, implementing the CLI command parser, and integrating the Vercel AI SDK.",
|
||||
"reasoning": "Requires deep integration with multiple AI models and careful management of API keys and configuration options. Vercel AI SDK integration adds complexity."
|
||||
"expansionPrompt": "The current 7 subtasks for implementing the mentor system appear well-structured. Consider if any additional subtasks are needed for mentor personality consistency, discussion quality evaluation, or performance optimization with multiple mentors.",
|
||||
"reasoning": "This task involves creating a sophisticated mentor simulation system with round-table discussions. The complexity is high due to the need for personality simulation, complex LLM integration, and structured discussion management. The 7 existing subtasks cover the main implementation areas from architecture to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 62,
|
||||
"taskTitle": "Add --simple Flag to Update Commands for Direct Text Input",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Add --simple Flag to Update Commands for Direct Text Input' task by detailing the steps for updating the command parsers, implementing the conditional logic, and formatting the user input with a timestamp.",
|
||||
"reasoning": "Relatively straightforward, but requires careful attention to formatting and ensuring consistency with AI-processed updates."
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 8,
|
||||
"expansionPrompt": "The current 8 subtasks for implementing the --simple flag appear comprehensive. Consider if any additional subtasks are needed for user experience testing or documentation updates.",
|
||||
"reasoning": "This task involves adding a simple flag option to bypass AI processing for updates. The complexity is relatively low as it primarily involves modifying existing command handlers and adding a flag. The 8 existing subtasks are very detailed and cover all aspects of implementation from command parsing to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 63,
|
||||
"taskTitle": "Add pnpm Support for the Taskmaster Package",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Add pnpm Support for the Taskmaster Package' task by detailing the steps for updating the documentation, ensuring package scripts compatibility, and testing the installation and operation with pnpm.",
|
||||
"reasoning": "Requires careful attention to detail to ensure compatibility with pnpm's execution model. Testing and documentation are crucial."
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 8,
|
||||
"expansionPrompt": "The current 8 subtasks for adding pnpm support appear comprehensive. Consider if any additional subtasks are needed for CI/CD integration, performance comparison, or documentation updates.",
|
||||
"reasoning": "This task involves ensuring the package works correctly with pnpm as an alternative package manager. The complexity is moderate as it requires careful testing of installation processes and scripts across different environments. The 8 existing subtasks cover all major aspects from documentation to binary verification."
|
||||
},
|
||||
{
|
||||
"taskId": 64,
|
||||
"taskTitle": "Add Yarn Support for Taskmaster Installation",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Add Yarn Support for Taskmaster Installation' task by detailing the steps for updating package.json, adding Yarn-specific configuration files, and testing the installation and operation with Yarn.",
|
||||
"reasoning": "Requires careful attention to detail to ensure compatibility with Yarn's execution model. Testing and documentation are crucial."
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 9,
|
||||
"expansionPrompt": "The current 9 subtasks for adding Yarn support appear comprehensive. Consider if any additional subtasks are needed for performance testing, CI/CD integration, or compatibility with different Yarn versions.",
|
||||
"reasoning": "This task involves ensuring the package works correctly with Yarn as an alternative package manager. The complexity is moderate as it requires careful testing of installation processes and scripts across different environments. The 9 existing subtasks are very detailed and cover all aspects from configuration to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 65,
|
||||
"taskTitle": "Add Bun Support for Taskmaster Installation",
|
||||
"complexityScore": 7,
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Add Bun Support for Taskmaster Installation' task by detailing the steps for updating the installation scripts, testing the installation and operation with Bun, and updating the documentation.",
|
||||
"reasoning": "Requires careful attention to detail to ensure compatibility with Bun's execution model. Testing and documentation are crucial."
|
||||
},
|
||||
{
|
||||
"taskId": 66,
|
||||
"taskTitle": "Support Status Filtering in Show Command for Subtasks",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Support Status Filtering in Show Command for Subtasks' task by detailing the steps for updating the command parser, modifying the show command handler, and updating the help documentation.",
|
||||
"reasoning": "Relatively straightforward, but requires careful handling of status validation and filtering."
|
||||
"expansionPrompt": "The current 6 subtasks for adding Bun support appear well-structured. Consider if any additional subtasks are needed for handling Bun-specific issues, performance testing, or documentation updates.",
|
||||
"reasoning": "This task involves adding support for the newer Bun package manager. The complexity is slightly higher than the other package manager tasks due to Bun's differences from Node.js and potential compatibility issues. The 6 existing subtasks cover the main implementation areas from research to documentation."
|
||||
},
|
||||
{
|
||||
"taskId": 67,
|
||||
"taskTitle": "Add CLI JSON output and Cursor keybindings integration",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Add CLI JSON output and Cursor keybindings integration' task by detailing the steps for implementing the JSON output logic, creating the install-keybindings command structure, and handling keybinding file manipulation.",
|
||||
"reasoning": "Requires careful formatting of the JSON output and handling of file system operations. OS detection adds complexity."
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "The current 5 subtasks for implementing JSON output and Cursor keybindings appear well-structured. Consider if any additional subtasks are needed for testing across different operating systems, documentation updates, or user experience improvements.",
|
||||
"reasoning": "This task involves two distinct features: adding JSON output to CLI commands and creating a keybindings installation command. The complexity is moderate as it requires careful handling of different output formats and OS-specific file paths. The 5 existing subtasks cover the main implementation areas for both features."
|
||||
},
|
||||
{
|
||||
"taskId": 68,
|
||||
"taskTitle": "Ability to create tasks without parsing PRD",
|
||||
"complexityScore": 3,
|
||||
"recommendedSubtasks": 2,
|
||||
"expansionPrompt": "Expand the 'Ability to create tasks without parsing PRD' task by detailing the steps for creating tasks without a PRD.",
|
||||
"reasoning": "Simple task to allow task creation without a PRD."
|
||||
"expansionPrompt": "The current 2 subtasks for implementing task creation without PRD appear appropriate. Consider if any additional subtasks are needed for validation, error handling, or integration with existing task management workflows.",
|
||||
"reasoning": "This task involves a relatively simple modification to allow task creation without requiring a PRD document. The complexity is low as it primarily involves creating a form interface and saving functionality. The 2 existing subtasks cover the main implementation areas of UI design and data saving."
|
||||
},
|
||||
{
|
||||
"taskId": 69,
|
||||
"taskTitle": "Enhance Analyze Complexity for Specific Task IDs",
|
||||
"complexityScore": 6,
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Enhance Analyze Complexity for Specific Task IDs' task by detailing the steps for modifying the core logic, updating the CLI, and updating the MCP tool.",
|
||||
"reasoning": "Requires modifying existing functionality and ensuring compatibility with both CLI and MCP."
|
||||
"expansionPrompt": "The current 4 subtasks for enhancing the analyze-complexity feature appear well-structured. Consider if any additional subtasks are needed for performance optimization with large task sets or visualization improvements.",
|
||||
"reasoning": "This task involves modifying the existing analyze-complexity feature to support analyzing specific task IDs and updating reports. The complexity is moderate as it requires careful handling of report merging and filtering logic. The 4 existing subtasks cover the main implementation areas from core logic to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 70,
|
||||
"taskTitle": "Implement 'diagram' command for Mermaid diagram generation",
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Implement 'diagram' command for Mermaid diagram generation' task by detailing the steps for creating the command, generating the Mermaid diagram, and handling different output options.",
|
||||
"reasoning": "Requires generating Mermaid diagrams and handling different output options."
|
||||
"expansionPrompt": "The current 4 subtasks for implementing the 'diagram' command appear well-structured. Consider if any additional subtasks are needed for handling large dependency graphs, additional output formats, or integration with existing visualization tools.",
|
||||
"reasoning": "This task involves creating a new command that generates Mermaid diagrams to visualize task dependencies. The complexity is moderate as it requires parsing task relationships, generating proper Mermaid syntax, and handling various output options. The 4 existing subtasks cover the main implementation areas from interface design to documentation."
|
||||
},
|
||||
{
|
||||
"taskId": 72,
|
||||
"taskTitle": "Implement PDF Generation for Project Progress and Dependency Overview",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "Expand the 'Implement PDF Generation for Project Progress and Dependency Overview' task by detailing the steps for summarizing project progress, visualizing the dependency chain, and generating the PDF document.",
|
||||
"reasoning": "Requires integrating with the diagram command and using a PDF generation library. Handling large dependency chains adds complexity."
|
||||
},
|
||||
{
|
||||
"taskId": 73,
|
||||
"taskTitle": "Implement Custom Model ID Support for Ollama/OpenRouter",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "Expand the 'Implement Custom Model ID Support for Ollama/OpenRouter' task by detailing the steps for modifying the CLI, implementing the interactive setup, and handling validation and warnings.",
|
||||
"reasoning": "Requires integrating with external APIs and handling different model types. Validation and warnings are crucial."
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "The current 6 subtasks for implementing PDF generation appear comprehensive. Consider if any additional subtasks are needed for handling large projects, additional visualization options, or integration with existing reporting tools.",
|
||||
"reasoning": "This task involves creating a feature to generate PDF reports of project progress and dependency visualization. The complexity is high due to the need for PDF generation, data collection, and visualization integration. The 6 existing subtasks cover the main implementation areas from library selection to export options."
|
||||
},
|
||||
{
|
||||
"taskId": 75,
|
||||
"taskTitle": "Integrate Google Search Grounding for Research Role",
|
||||
"complexityScore": 6,
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 4,
|
||||
"expansionPrompt": "Expand the 'Integrate Google Search Grounding for Research Role' task by detailing the steps for modifying the AI service layer, implementing the conditional logic, and updating the supported models.",
|
||||
"reasoning": "Requires conditional logic and integration with the Google Search Grounding API."
|
||||
"expansionPrompt": "The current 4 subtasks for integrating Google Search Grounding appear well-structured. Consider if any additional subtasks are needed for testing with different query types, error handling, or performance optimization.",
|
||||
"reasoning": "This task involves updating the AI service layer to enable Google Search Grounding for research roles. The complexity is moderate as it requires careful integration with the existing AI service architecture and conditional logic. The 4 existing subtasks cover the main implementation areas from service layer modification to testing."
|
||||
},
|
||||
{
|
||||
"taskId": 76,
|
||||
"taskTitle": "Develop E2E Test Framework for Taskmaster MCP Server (FastMCP over stdio)",
|
||||
"complexityScore": 9,
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 7,
|
||||
"expansionPrompt": "Expand the 'Develop E2E Test Framework for Taskmaster MCP Server (FastMCP over stdio)' task by detailing the steps for launching the FastMCP server, implementing the message protocol handler, and developing the request/response correlation mechanism.",
|
||||
"reasoning": "Requires complex system integration and robust error handling. Designing a comprehensive test framework adds complexity."
|
||||
"expansionPrompt": "The current 7 subtasks for developing the E2E test framework appear comprehensive. Consider if any additional subtasks are needed for test result reporting, CI/CD integration, or performance benchmarking.",
|
||||
"reasoning": "This task involves creating a sophisticated end-to-end testing framework for the MCP server. The complexity is high due to the need for subprocess management, protocol handling, and robust test case definition. The 7 existing subtasks cover the main implementation areas from architecture to documentation."
|
||||
},
|
||||
{
|
||||
"taskId": 77,
|
||||
"taskTitle": "Implement AI Usage Telemetry for Taskmaster (with external analytics endpoint)",
|
||||
"complexityScore": 7,
|
||||
"recommendedSubtasks": 18,
|
||||
"expansionPrompt": "The current 18 subtasks for implementing AI usage telemetry appear very comprehensive. Consider if any additional subtasks are needed for security hardening, privacy compliance, or user feedback collection.",
|
||||
"reasoning": "This task involves creating a telemetry system to track AI usage metrics. The complexity is high due to the need for secure data transmission, comprehensive data collection, and integration across multiple commands. The 18 existing subtasks are extremely detailed and cover all aspects of implementation from core utility to provider-specific updates."
|
||||
},
|
||||
{
|
||||
"taskId": 80,
|
||||
"taskTitle": "Implement Unique User ID Generation and Storage During Installation",
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 5,
|
||||
"expansionPrompt": "The current 5 subtasks for implementing unique user ID generation appear well-structured. Consider if any additional subtasks are needed for privacy compliance, security auditing, or integration with the telemetry system.",
|
||||
"reasoning": "This task involves generating and storing a unique user identifier during installation. The complexity is relatively low as it primarily involves UUID generation and configuration file management. The 5 existing subtasks cover the main implementation areas from script structure to documentation."
|
||||
},
|
||||
{
|
||||
"taskId": 81,
|
||||
"taskTitle": "Task #81: Implement Comprehensive Local Telemetry System with Future Server Integration Capability",
|
||||
"complexityScore": 8,
|
||||
"recommendedSubtasks": 6,
|
||||
"expansionPrompt": "The current 6 subtasks for implementing the comprehensive local telemetry system appear well-structured. Consider if any additional subtasks are needed for data migration, storage optimization, or visualization tools.",
|
||||
"reasoning": "This task involves expanding the telemetry system to capture additional metrics and implement local storage with future server integration capability. The complexity is high due to the breadth of data collection, storage requirements, and privacy considerations. The 6 existing subtasks cover the main implementation areas from data collection to user-facing benefits."
|
||||
},
|
||||
{
|
||||
"taskId": 82,
|
||||
"taskTitle": "Update supported-models.json with token limit fields",
|
||||
"complexityScore": 3,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears straightforward enough to be implemented without further subtasks. Focus on researching accurate token limit values for each model and ensuring backward compatibility.",
|
||||
"reasoning": "This task involves a simple update to the supported-models.json file to include new token limit fields. The complexity is low as it primarily involves research and data entry. No subtasks are necessary as the task is well-defined and focused."
|
||||
},
|
||||
{
|
||||
"taskId": 83,
|
||||
"taskTitle": "Update config-manager.js defaults and getters",
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears straightforward enough to be implemented without further subtasks. Focus on updating the DEFAULTS object and related getter functions while maintaining backward compatibility.",
|
||||
"reasoning": "This task involves updating the config-manager.js module to replace maxTokens with more specific token limit fields. The complexity is relatively low as it primarily involves modifying existing code rather than creating new functionality. No subtasks are necessary as the task is well-defined and focused."
|
||||
},
|
||||
{
|
||||
"taskId": 84,
|
||||
"taskTitle": "Implement token counting utility",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears well-defined enough to be implemented without further subtasks. Focus on implementing accurate token counting for different models and proper fallback mechanisms.",
|
||||
"reasoning": "This task involves creating a utility function to count tokens for different AI models. The complexity is moderate as it requires integration with the tiktoken library and handling different tokenization schemes. No subtasks are necessary as the task is well-defined and focused."
|
||||
},
|
||||
{
|
||||
"taskId": 85,
|
||||
"taskTitle": "Update ai-services-unified.js for dynamic token limits",
|
||||
"complexityScore": 6,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears well-defined enough to be implemented without further subtasks. Focus on implementing dynamic token limit adjustment based on input length and model capabilities.",
|
||||
"reasoning": "This task involves modifying the AI service runner to use the new token counting utility and dynamically adjust output token limits. The complexity is moderate to high as it requires careful integration with existing code and handling various edge cases. No subtasks are necessary as the task is well-defined and focused."
|
||||
},
|
||||
{
|
||||
"taskId": 86,
|
||||
"taskTitle": "Update .taskmasterconfig schema and user guide",
|
||||
"complexityScore": 4,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears straightforward enough to be implemented without further subtasks. Focus on creating clear migration guidance and updating documentation.",
|
||||
"reasoning": "This task involves creating a migration guide for users to update their configuration files and documenting the new token limit options. The complexity is relatively low as it primarily involves documentation and schema validation. No subtasks are necessary as the task is well-defined and focused."
|
||||
},
|
||||
{
|
||||
"taskId": 87,
|
||||
"taskTitle": "Implement validation and error handling",
|
||||
"complexityScore": 5,
|
||||
"recommendedSubtasks": 1,
|
||||
"expansionPrompt": "This task appears well-defined enough to be implemented without further subtasks. Focus on comprehensive validation and helpful error messages throughout the system.",
|
||||
"reasoning": "This task involves adding validation and error handling for token limits throughout the system. The complexity is moderate as it requires careful integration with multiple components and creating helpful error messages. No subtasks are necessary as the task is well-defined and focused."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -50,7 +50,7 @@ function getClient(apiKey, baseUrl) {
|
||||
* @param {number} [params.maxTokens] - Maximum tokens for the response.
|
||||
* @param {number} [params.temperature] - Temperature for generation.
|
||||
* @param {string} [params.baseUrl] - The base URL for the Anthropic API.
|
||||
* @returns {Promise<string>} The generated text content.
|
||||
* @returns {Promise<object>} The generated text content and usage.
|
||||
* @throws {Error} If the API call fails.
|
||||
*/
|
||||
export async function generateAnthropicText({
|
||||
@@ -76,7 +76,14 @@ export async function generateAnthropicText({
|
||||
'debug',
|
||||
`Anthropic generateText result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.text;
|
||||
// Return both text and usage
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log('error', `Anthropic generateText failed: ${error.message}`);
|
||||
// Consider more specific error handling or re-throwing a standardized error
|
||||
@@ -156,7 +163,7 @@ export async function streamAnthropicText({
|
||||
* @param {number} [params.temperature] - Temperature for generation.
|
||||
* @param {number} [params.maxRetries] - Max retries for validation/generation.
|
||||
* @param {string} [params.baseUrl] - The base URL for the Anthropic API.
|
||||
* @returns {Promise<object>} The generated object matching the schema.
|
||||
* @returns {Promise<object>} The generated object matching the schema and usage.
|
||||
* @throws {Error} If generation or validation fails.
|
||||
*/
|
||||
export async function generateAnthropicObject({
|
||||
@@ -197,7 +204,14 @@ export async function generateAnthropicObject({
|
||||
'debug',
|
||||
`Anthropic generateObject result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.object;
|
||||
// Return both object and usage
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
|
||||
@@ -9,7 +9,7 @@ import { generateText, streamText, generateObject } from 'ai'; // Import from ma
|
||||
import { log } from '../../scripts/modules/utils.js'; // Import logging utility
|
||||
|
||||
// Consider making model configurable via config-manager.js later
|
||||
const DEFAULT_MODEL = 'gemini-2.0-pro'; // Or a suitable default
|
||||
const DEFAULT_MODEL = 'gemini-2.5-pro-exp-03-25'; // Or a suitable default
|
||||
const DEFAULT_TEMPERATURE = 0.2; // Or a suitable default
|
||||
|
||||
function getClient(apiKey, baseUrl) {
|
||||
@@ -56,7 +56,17 @@ async function generateGoogleText({
|
||||
temperature,
|
||||
maxOutputTokens: maxTokens
|
||||
});
|
||||
return result.text;
|
||||
|
||||
// Assuming result structure provides text directly or within a property
|
||||
// return result.text; // Adjust based on actual SDK response
|
||||
// Return both text and usage
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
@@ -142,14 +152,23 @@ async function generateGoogleObject({
|
||||
try {
|
||||
const googleProvider = getClient(apiKey, baseUrl);
|
||||
const model = googleProvider(modelId);
|
||||
const { object } = await generateObject({
|
||||
const result = await generateObject({
|
||||
model,
|
||||
schema,
|
||||
messages,
|
||||
temperature,
|
||||
maxOutputTokens: maxTokens
|
||||
});
|
||||
return object;
|
||||
|
||||
// return object; // Return the parsed object
|
||||
// Return both object and usage
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
|
||||
163
src/ai-providers/ollama.js
Normal file
163
src/ai-providers/ollama.js
Normal file
@@ -0,0 +1,163 @@
|
||||
/**
|
||||
* ollama.js
|
||||
* AI provider implementation for Ollama models using the ollama-ai-provider package.
|
||||
*/
|
||||
|
||||
import { createOllama } from 'ollama-ai-provider';
|
||||
import { log } from '../../scripts/modules/utils.js'; // Import logging utility
|
||||
import { generateObject, generateText, streamText } from 'ai';
|
||||
|
||||
// Consider making model configurable via config-manager.js later
|
||||
const DEFAULT_MODEL = 'llama3'; // Or a suitable default for Ollama
|
||||
const DEFAULT_TEMPERATURE = 0.2;
|
||||
|
||||
function getClient(baseUrl) {
|
||||
// baseUrl is optional, defaults to http://localhost:11434
|
||||
return createOllama({
|
||||
baseUrl: baseUrl || undefined
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates text using an Ollama model.
|
||||
*
|
||||
* @param {object} params - Parameters for the generation.
|
||||
* @param {string} params.modelId - Specific model ID to use (overrides default).
|
||||
* @param {number} params.temperature - Generation temperature.
|
||||
* @param {Array<object>} params.messages - The conversation history (system/user prompts).
|
||||
* @param {number} [params.maxTokens] - Optional max tokens.
|
||||
* @param {string} [params.baseUrl] - Optional Ollama base URL.
|
||||
* @returns {Promise<string>} The generated text content.
|
||||
* @throws {Error} If API call fails.
|
||||
*/
|
||||
async function generateOllamaText({
|
||||
modelId = DEFAULT_MODEL,
|
||||
messages,
|
||||
maxTokens,
|
||||
temperature = DEFAULT_TEMPERATURE,
|
||||
baseUrl
|
||||
}) {
|
||||
log('info', `Generating text with Ollama model: ${modelId}`);
|
||||
|
||||
try {
|
||||
const client = getClient(baseUrl);
|
||||
const result = await generateText({
|
||||
model: client(modelId),
|
||||
messages,
|
||||
maxTokens,
|
||||
temperature
|
||||
});
|
||||
log('debug', `Ollama generated text: ${result.text}`);
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`Error generating text with Ollama (${modelId}): ${error.message}`
|
||||
);
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Streams text using an Ollama model.
|
||||
*
|
||||
* @param {object} params - Parameters for the streaming.
|
||||
* @param {string} params.modelId - Specific model ID to use (overrides default).
|
||||
* @param {number} params.temperature - Generation temperature.
|
||||
* @param {Array<object>} params.messages - The conversation history.
|
||||
* @param {number} [params.maxTokens] - Optional max tokens.
|
||||
* @param {string} [params.baseUrl] - Optional Ollama base URL.
|
||||
* @returns {Promise<ReadableStream>} A readable stream of text deltas.
|
||||
* @throws {Error} If API call fails.
|
||||
*/
|
||||
async function streamOllamaText({
|
||||
modelId = DEFAULT_MODEL,
|
||||
temperature = DEFAULT_TEMPERATURE,
|
||||
messages,
|
||||
maxTokens,
|
||||
baseUrl
|
||||
}) {
|
||||
log('info', `Streaming text with Ollama model: ${modelId}`);
|
||||
|
||||
try {
|
||||
const ollama = getClient(baseUrl);
|
||||
const stream = await streamText({
|
||||
model: modelId,
|
||||
messages,
|
||||
temperature,
|
||||
maxTokens
|
||||
});
|
||||
return stream;
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`Error streaming text with Ollama (${modelId}): ${error.message}`
|
||||
);
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Generates a structured object using an Ollama model using the Vercel AI SDK's generateObject.
|
||||
*
|
||||
* @param {object} params - Parameters for the object generation.
|
||||
* @param {string} params.modelId - Specific model ID to use (overrides default).
|
||||
* @param {number} params.temperature - Generation temperature.
|
||||
* @param {Array<object>} params.messages - The conversation history.
|
||||
* @param {import('zod').ZodSchema} params.schema - Zod schema for the expected object.
|
||||
* @param {string} params.objectName - Name for the object generation context.
|
||||
* @param {number} [params.maxTokens] - Optional max tokens.
|
||||
* @param {number} [params.maxRetries] - Max retries for validation/generation.
|
||||
* @param {string} [params.baseUrl] - Optional Ollama base URL.
|
||||
* @returns {Promise<object>} The generated object matching the schema.
|
||||
* @throws {Error} If generation or validation fails.
|
||||
*/
|
||||
async function generateOllamaObject({
|
||||
modelId = DEFAULT_MODEL,
|
||||
temperature = DEFAULT_TEMPERATURE,
|
||||
messages,
|
||||
schema,
|
||||
objectName = 'generated_object',
|
||||
maxTokens,
|
||||
maxRetries = 3,
|
||||
baseUrl
|
||||
}) {
|
||||
log('info', `Generating object with Ollama model: ${modelId}`);
|
||||
try {
|
||||
const ollama = getClient(baseUrl);
|
||||
const result = await generateObject({
|
||||
model: ollama(modelId),
|
||||
mode: 'tool',
|
||||
schema: schema,
|
||||
messages: messages,
|
||||
tool: {
|
||||
name: objectName,
|
||||
description: `Generate a ${objectName} based on the prompt.`
|
||||
},
|
||||
maxOutputTokens: maxTokens,
|
||||
temperature: temperature,
|
||||
maxRetries: maxRetries
|
||||
});
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`Ollama generateObject ('${objectName}') failed: ${error.message}`
|
||||
);
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
|
||||
export { generateOllamaText, streamOllamaText, generateOllamaObject };
|
||||
@@ -1,5 +1,5 @@
|
||||
import { createOpenAI } from '@ai-sdk/openai'; // Using openai provider from Vercel AI SDK
|
||||
import { generateObject } from 'ai'; // Import necessary functions from 'ai'
|
||||
import { generateObject, generateText } from 'ai'; // Import necessary functions from 'ai'
|
||||
import { log } from '../../scripts/modules/utils.js';
|
||||
|
||||
function getClient(apiKey, baseUrl) {
|
||||
@@ -16,7 +16,7 @@ function getClient(apiKey, baseUrl) {
|
||||
* Generates text using OpenAI models via Vercel AI SDK.
|
||||
*
|
||||
* @param {object} params - Parameters including apiKey, modelId, messages, maxTokens, temperature, baseUrl.
|
||||
* @returns {Promise<string>} The generated text content.
|
||||
* @returns {Promise<object>} The generated text content and usage.
|
||||
* @throws {Error} If API call fails.
|
||||
*/
|
||||
export async function generateOpenAIText(params) {
|
||||
@@ -36,15 +36,14 @@ export async function generateOpenAIText(params) {
|
||||
const openaiClient = getClient(apiKey, baseUrl);
|
||||
|
||||
try {
|
||||
const result = await openaiClient.chat(messages, {
|
||||
model: modelId,
|
||||
max_tokens: maxTokens,
|
||||
const result = await generateText({
|
||||
model: openaiClient(modelId),
|
||||
messages,
|
||||
maxTokens,
|
||||
temperature
|
||||
});
|
||||
|
||||
const textContent = result?.choices?.[0]?.message?.content?.trim();
|
||||
|
||||
if (!textContent) {
|
||||
if (!result || !result.text) {
|
||||
log(
|
||||
'warn',
|
||||
'OpenAI generateText response did not contain expected content.',
|
||||
@@ -56,7 +55,13 @@ export async function generateOpenAIText(params) {
|
||||
'debug',
|
||||
`OpenAI generateText completed successfully for model: ${modelId}`
|
||||
);
|
||||
return textContent;
|
||||
return {
|
||||
text: result.text.trim(),
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
@@ -122,7 +127,7 @@ export async function streamOpenAIText(params) {
|
||||
* Generates structured objects using OpenAI models via Vercel AI SDK.
|
||||
*
|
||||
* @param {object} params - Parameters including apiKey, modelId, messages, schema, objectName, maxTokens, temperature, baseUrl.
|
||||
* @returns {Promise<object>} The generated object matching the schema.
|
||||
* @returns {Promise<object>} The generated object matching the schema and usage.
|
||||
* @throws {Error} If API call fails or object generation fails.
|
||||
*/
|
||||
export async function generateOpenAIObject(params) {
|
||||
@@ -166,7 +171,21 @@ export async function generateOpenAIObject(params) {
|
||||
'debug',
|
||||
`OpenAI generateObject completed successfully for model: ${modelId}`
|
||||
);
|
||||
return result.object;
|
||||
if (!result || typeof result.object === 'undefined') {
|
||||
log(
|
||||
'warn',
|
||||
'OpenAI generateObject response did not contain expected object.',
|
||||
{ result }
|
||||
);
|
||||
throw new Error('Failed to extract object from OpenAI response.');
|
||||
}
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
|
||||
@@ -41,20 +41,53 @@ async function generateOpenRouterText({
|
||||
const openrouter = getClient(apiKey, baseUrl);
|
||||
const model = openrouter.chat(modelId); // Assuming chat model
|
||||
|
||||
const { text } = await generateText({
|
||||
// Capture the full result from generateText
|
||||
const result = await generateText({
|
||||
model,
|
||||
messages,
|
||||
maxTokens,
|
||||
temperature,
|
||||
...rest // Pass any additional parameters
|
||||
});
|
||||
return text;
|
||||
|
||||
// Check if text and usage are present
|
||||
if (!result || typeof result.text !== 'string') {
|
||||
log(
|
||||
'warn',
|
||||
`OpenRouter generateText for model ${modelId} did not return expected text.`,
|
||||
{ result }
|
||||
);
|
||||
throw new Error('Failed to extract text from OpenRouter response.');
|
||||
}
|
||||
if (!result.usage) {
|
||||
log(
|
||||
'warn',
|
||||
`OpenRouter generateText for model ${modelId} did not return usage data.`,
|
||||
{ result }
|
||||
);
|
||||
// Decide if this is critical. For now, let it pass but telemetry will be incomplete.
|
||||
}
|
||||
|
||||
log('debug', `OpenRouter generateText completed for model ${modelId}`);
|
||||
// Return text and usage
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`OpenRouter generateText failed for model ${modelId}: ${error.message}`
|
||||
);
|
||||
// Re-throw the error for the unified layer to handle retries/fallbacks
|
||||
let detailedMessage = `OpenRouter generateText failed for model ${modelId}: ${error.message}`;
|
||||
if (error.cause) {
|
||||
detailedMessage += `\n\nCause:\n\n ${typeof error.cause === 'string' ? error.cause : JSON.stringify(error.cause)}`;
|
||||
}
|
||||
// Vercel AI SDK sometimes wraps the actual API error response in error.data
|
||||
if (error.data) {
|
||||
detailedMessage += `\n\nData:\n\n ${JSON.stringify(error.data)}`;
|
||||
}
|
||||
// Log the original error object for full context if needed for deeper debugging
|
||||
log('error', detailedMessage, { originalErrorObject: error });
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
@@ -100,10 +133,14 @@ async function streamOpenRouterText({
|
||||
});
|
||||
return stream;
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`OpenRouter streamText failed for model ${modelId}: ${error.message}`
|
||||
);
|
||||
let detailedMessage = `OpenRouter streamText failed for model ${modelId}: ${error.message}`;
|
||||
if (error.cause) {
|
||||
detailedMessage += `\n\nCause:\n\n ${typeof error.cause === 'string' ? error.cause : JSON.stringify(error.cause)}`;
|
||||
}
|
||||
if (error.data) {
|
||||
detailedMessage += `\n\nData:\n\n ${JSON.stringify(error.data)}`;
|
||||
}
|
||||
log('error', detailedMessage, { originalErrorObject: error });
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
@@ -146,12 +183,12 @@ async function generateOpenRouterObject({
|
||||
const openrouter = getClient(apiKey, baseUrl);
|
||||
const model = openrouter.chat(modelId);
|
||||
|
||||
const { object } = await generateObject({
|
||||
// Capture the full result from generateObject
|
||||
const result = await generateObject({
|
||||
model,
|
||||
schema,
|
||||
mode: 'tool', // Standard mode for most object generation
|
||||
mode: 'tool',
|
||||
tool: {
|
||||
// Define the tool based on the schema
|
||||
name: objectName,
|
||||
description: `Generate an object conforming to the ${objectName} schema.`,
|
||||
parameters: schema
|
||||
@@ -159,15 +196,45 @@ async function generateOpenRouterObject({
|
||||
messages,
|
||||
maxTokens,
|
||||
temperature,
|
||||
maxRetries, // Pass maxRetries if supported by generateObject
|
||||
maxRetries,
|
||||
...rest
|
||||
});
|
||||
return object;
|
||||
|
||||
// Check if object and usage are present
|
||||
if (!result || typeof result.object === 'undefined') {
|
||||
log(
|
||||
'warn',
|
||||
`OpenRouter generateObject for model ${modelId} did not return expected object.`,
|
||||
{ result }
|
||||
);
|
||||
throw new Error('Failed to extract object from OpenRouter response.');
|
||||
}
|
||||
if (!result.usage) {
|
||||
log(
|
||||
'warn',
|
||||
`OpenRouter generateObject for model ${modelId} did not return usage data.`,
|
||||
{ result }
|
||||
);
|
||||
}
|
||||
|
||||
log('debug', `OpenRouter generateObject completed for model ${modelId}`);
|
||||
// Return object and usage
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
`OpenRouter generateObject failed for model ${modelId}: ${error.message}`
|
||||
);
|
||||
let detailedMessage = `OpenRouter generateObject failed for model ${modelId}: ${error.message}`;
|
||||
if (error.cause) {
|
||||
detailedMessage += `\n\nCause:\n\n ${typeof error.cause === 'string' ? error.cause : JSON.stringify(error.cause)}`;
|
||||
}
|
||||
if (error.data) {
|
||||
detailedMessage += `\n\nData:\n\n ${JSON.stringify(error.data)}`;
|
||||
}
|
||||
log('error', detailedMessage, { originalErrorObject: error });
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -56,7 +56,14 @@ export async function generatePerplexityText({
|
||||
'debug',
|
||||
`Perplexity generateText result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.text;
|
||||
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log('error', `Perplexity generateText failed: ${error.message}`);
|
||||
throw error;
|
||||
@@ -153,7 +160,13 @@ export async function generatePerplexityObject({
|
||||
'debug',
|
||||
`Perplexity generateObject result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.object;
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
|
||||
@@ -31,7 +31,7 @@ function getClient(apiKey, baseUrl) {
|
||||
* @param {number} [params.maxTokens] - Maximum tokens for the response.
|
||||
* @param {number} [params.temperature] - Temperature for generation.
|
||||
* @param {string} [params.baseUrl] - The base URL for the xAI API.
|
||||
* @returns {Promise<string>} The generated text content.
|
||||
* @returns {Promise<object>} The generated text content and usage.
|
||||
* @throws {Error} If the API call fails.
|
||||
*/
|
||||
export async function generateXaiText({
|
||||
@@ -55,7 +55,14 @@ export async function generateXaiText({
|
||||
'debug',
|
||||
`xAI generateText result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.text;
|
||||
// Return text and usage
|
||||
return {
|
||||
text: result.text,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log('error', `xAI generateText failed: ${error.message}`);
|
||||
throw error;
|
||||
@@ -114,7 +121,7 @@ export async function streamXaiText({
|
||||
* @param {number} [params.temperature] - Temperature for generation.
|
||||
* @param {number} [params.maxRetries] - Max retries for validation/generation.
|
||||
* @param {string} [params.baseUrl] - The base URL for the xAI API.
|
||||
* @returns {Promise<object>} The generated object matching the schema.
|
||||
* @returns {Promise<object>} The generated object matching the schema and its usage.
|
||||
* @throws {Error} If generation or validation fails.
|
||||
*/
|
||||
export async function generateXaiObject({
|
||||
@@ -142,7 +149,8 @@ export async function generateXaiObject({
|
||||
messages: messages,
|
||||
tool: {
|
||||
name: objectName,
|
||||
description: `Generate a ${objectName} based on the prompt.`
|
||||
description: `Generate a ${objectName} based on the prompt.`,
|
||||
parameters: schema
|
||||
},
|
||||
maxTokens: maxTokens,
|
||||
temperature: temperature,
|
||||
@@ -152,7 +160,14 @@ export async function generateXaiObject({
|
||||
'debug',
|
||||
`xAI generateObject result received. Tokens: ${result.usage.completionTokens}/${result.usage.promptTokens}`
|
||||
);
|
||||
return result.object;
|
||||
// Return object and usage
|
||||
return {
|
||||
object: result.object,
|
||||
usage: {
|
||||
inputTokens: result.usage.promptTokens,
|
||||
outputTokens: result.usage.completionTokens
|
||||
}
|
||||
};
|
||||
} catch (error) {
|
||||
log(
|
||||
'error',
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Task ID: 32
|
||||
# Title: Implement "learn" Command for Automatic Cursor Rule Generation
|
||||
# Status: pending
|
||||
# Status: deferred
|
||||
# Dependencies: None
|
||||
# Priority: high
|
||||
# Description: Create a new "learn" command that analyzes Cursor's chat history and code changes to automatically generate or update rule files in the .cursor/rules directory, following the cursor_rules.mdc template format. This command will help Cursor autonomously improve its ability to follow development standards by learning from successful implementations.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Task ID: 43
|
||||
# Title: Add Research Flag to Add-Task Command
|
||||
# Status: pending
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Implement a '--research' flag for the add-task command that enables users to automatically generate research-related subtasks when creating a new task.
|
||||
|
||||
@@ -48,3 +48,47 @@ Testing should verify both the functionality and security of the webhook system:
|
||||
5. Manual verification:
|
||||
- Set up integrations with common services (GitHub, Slack, etc.) to verify real-world functionality
|
||||
- Verify that the CLI interface for managing webhooks works as expected
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design webhook registration API endpoints [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create API endpoints for registering, updating, and deleting webhook subscriptions
|
||||
### Details:
|
||||
Implement RESTful API endpoints that allow clients to register webhook URLs, specify event types they want to subscribe to, and manage their subscriptions. Include validation for URL format, required parameters, and authentication requirements.
|
||||
|
||||
## 2. Implement webhook authentication and security measures [pending]
|
||||
### Dependencies: 44.1
|
||||
### Description: Develop security mechanisms for webhook verification and payload signing
|
||||
### Details:
|
||||
Implement signature verification using HMAC, rate limiting to prevent abuse, IP whitelisting options, and webhook secret management. Create a secure token system for webhook verification and implement TLS for all webhook communications.
|
||||
|
||||
## 3. Create event trigger definition interface [pending]
|
||||
### Dependencies: None
|
||||
### Description: Design and implement the interface for defining event triggers and conditions
|
||||
### Details:
|
||||
Develop a user interface or API that allows defining what events should trigger webhooks. Include support for conditional triggers based on event properties, filtering options, and the ability to specify payload formats.
|
||||
|
||||
## 4. Build event processing and queuing system [pending]
|
||||
### Dependencies: 44.1, 44.3
|
||||
### Description: Implement a robust system for processing and queuing events before webhook delivery
|
||||
### Details:
|
||||
Create an event queue using a message broker (like RabbitMQ or Kafka) to handle high volumes of events. Implement event deduplication, prioritization, and persistence to ensure reliable delivery even during system failures.
|
||||
|
||||
## 5. Develop webhook delivery and retry mechanism [pending]
|
||||
### Dependencies: 44.2, 44.4
|
||||
### Description: Create a reliable system for webhook delivery with retry logic and failure handling
|
||||
### Details:
|
||||
Implement exponential backoff retry logic, configurable retry attempts, and dead letter queues for failed deliveries. Add monitoring for webhook delivery success rates and performance metrics. Include timeout handling for unresponsive webhook endpoints.
|
||||
|
||||
## 6. Implement comprehensive error handling and logging [pending]
|
||||
### Dependencies: 44.5
|
||||
### Description: Create robust error handling, logging, and monitoring for the webhook system
|
||||
### Details:
|
||||
Develop detailed error logging for webhook failures, including response codes, error messages, and timing information. Implement alerting for critical failures and create a dashboard for monitoring system health. Add debugging tools for webhook delivery issues.
|
||||
|
||||
## 7. Create webhook testing and simulation tools [pending]
|
||||
### Dependencies: 44.3, 44.5, 44.6
|
||||
### Description: Develop tools for testing webhook integrations and simulating event triggers
|
||||
### Details:
|
||||
Build a webhook testing console that allows manual triggering of events, viewing delivery history, and replaying failed webhooks. Create a webhook simulator for developers to test their endpoint implementations without generating real system events.
|
||||
|
||||
|
||||
@@ -53,3 +53,35 @@ Testing should cover the following scenarios:
|
||||
- Test the interaction with other flags and commands
|
||||
|
||||
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.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design GitHub API integration architecture [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a technical design document outlining the architecture for GitHub API integration, including authentication flow, rate limiting considerations, and error handling strategies.
|
||||
### Details:
|
||||
Document should include: API endpoints to be used, authentication method (OAuth vs Personal Access Token), data flow diagrams, and security considerations. Research GitHub API rate limits and implement appropriate throttling mechanisms.
|
||||
|
||||
## 2. Implement GitHub URL parsing and validation [pending]
|
||||
### Dependencies: 45.1
|
||||
### Description: Create a module to parse and validate GitHub issue URLs, extracting repository owner, repository name, and issue number.
|
||||
### Details:
|
||||
Handle various GitHub URL formats (e.g., github.com/owner/repo/issues/123, github.com/owner/repo/pull/123). Implement validation to ensure the URL points to a valid issue or pull request. Return structured data with owner, repo, and issue number for valid URLs.
|
||||
|
||||
## 3. Develop GitHub API client for issue fetching [pending]
|
||||
### Dependencies: 45.1, 45.2
|
||||
### Description: Create a service to authenticate with GitHub and fetch issue details using the GitHub REST API.
|
||||
### Details:
|
||||
Implement authentication using GitHub Personal Access Tokens or OAuth. Handle API responses, including error cases (rate limiting, authentication failures, not found). Extract relevant issue data: title, description, labels, assignees, and comments.
|
||||
|
||||
## 4. Create task formatter for GitHub issues [pending]
|
||||
### Dependencies: 45.3
|
||||
### Description: Develop a formatter to convert GitHub issue data into the application's task format.
|
||||
### Details:
|
||||
Map GitHub issue fields to task fields (title, description, etc.). Convert GitHub markdown to the application's supported format. Handle special GitHub features like issue references and user mentions. Generate appropriate tags based on GitHub labels.
|
||||
|
||||
## 5. Implement end-to-end import flow with UI [pending]
|
||||
### Dependencies: 45.4
|
||||
### Description: Create the user interface and workflow for importing GitHub issues, including progress indicators and error handling.
|
||||
### 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.
|
||||
|
||||
|
||||
@@ -53,3 +53,35 @@ The command should follow the same design patterns as `analyze-complexity` for c
|
||||
- The ranking should prioritize high-impact, high-confidence, easy-to-implement tasks
|
||||
- Performance should be acceptable even with a large number of tasks
|
||||
- The command should handle edge cases gracefully (empty projects, missing data)
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design ICE scoring algorithm [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create the algorithm for calculating Impact, Confidence, and Ease scores for tasks
|
||||
### Details:
|
||||
Define the mathematical formula for ICE scoring (Impact × Confidence × Ease). Determine the scale for each component (e.g., 1-10). Create rules for how AI will evaluate each component based on task attributes like complexity, dependencies, and descriptions. Document the scoring methodology for future reference.
|
||||
|
||||
## 2. Implement AI integration for ICE scoring [pending]
|
||||
### Dependencies: 46.1
|
||||
### Description: Develop the AI component that will analyze tasks and generate ICE scores
|
||||
### Details:
|
||||
Create prompts for the AI to evaluate Impact, Confidence, and Ease. Implement error handling for AI responses. Add caching to prevent redundant AI calls. Ensure the AI provides justification for each score component. Test with various task types to ensure consistent scoring.
|
||||
|
||||
## 3. Create report file generator [pending]
|
||||
### Dependencies: 46.2
|
||||
### Description: Build functionality to generate a structured report file with ICE analysis results
|
||||
### Details:
|
||||
Design the report file format (JSON, CSV, or Markdown). Implement sorting of tasks by ICE score. Include task details, individual I/C/E scores, and final ICE score in the report. Add timestamp and project metadata. Create a function to save the report to the specified location.
|
||||
|
||||
## 4. Implement CLI rendering for ICE analysis [pending]
|
||||
### Dependencies: 46.3
|
||||
### Description: Develop the command-line interface for displaying ICE analysis results
|
||||
### Details:
|
||||
Design a tabular format for displaying ICE scores in the terminal. Use color coding to highlight high/medium/low priority tasks. Implement filtering options (by score range, task type, etc.). Add sorting capabilities. Create a summary view that shows top N tasks by ICE score.
|
||||
|
||||
## 5. Integrate with existing complexity reports [pending]
|
||||
### Dependencies: 46.3, 46.4
|
||||
### Description: Connect the ICE analysis functionality with the existing complexity reporting system
|
||||
### Details:
|
||||
Modify the existing complexity report to include ICE scores. Ensure consistent formatting between complexity and ICE reports. Add cross-referencing between reports. Update the command-line help documentation. Test the integrated system with various project sizes and configurations.
|
||||
|
||||
|
||||
@@ -64,3 +64,41 @@ Testing should verify the complete workflow functions correctly:
|
||||
5. Regression Testing:
|
||||
- Verify that existing functionality continues to work
|
||||
- Ensure compatibility with keyboard shortcuts and accessibility features
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design Task Expansion UI Components [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create UI components for the expanded task suggestion actions card that allow for task breakdown and additional context input.
|
||||
### Details:
|
||||
Design mockups for expanded card view, including subtask creation interface, context input fields, and task management controls. Ensure the design is consistent with existing UI patterns and responsive across different screen sizes. Include animations for card expansion/collapse.
|
||||
|
||||
## 2. Implement State Management for Task Expansion [pending]
|
||||
### Dependencies: 47.1
|
||||
### Description: Develop the state management logic to handle expanded task states, subtask creation, and context additions.
|
||||
### Details:
|
||||
Create state handlers for expanded/collapsed states, subtask array management, and context data. Implement proper validation for user inputs and error handling. Ensure state persistence across user sessions and synchronization with backend services.
|
||||
|
||||
## 3. Build Context Addition Functionality [pending]
|
||||
### Dependencies: 47.2
|
||||
### Description: Create the functionality that allows users to add additional context to tasks and subtasks.
|
||||
### Details:
|
||||
Implement context input fields with support for rich text, attachments, links, and references to other tasks. Add auto-save functionality for context changes and version history if applicable. Include context suggestion features based on task content.
|
||||
|
||||
## 4. Develop Task Management Controls [pending]
|
||||
### Dependencies: 47.2
|
||||
### Description: Implement controls for managing tasks within the expanded card view, including prioritization, scheduling, and assignment.
|
||||
### Details:
|
||||
Create UI controls for task prioritization (drag-and-drop ranking), deadline setting with calendar integration, assignee selection with user search, and status updates. Implement notification triggers for task changes and deadline reminders.
|
||||
|
||||
## 5. Integrate with Existing Task Systems [pending]
|
||||
### Dependencies: 47.3, 47.4
|
||||
### Description: Ensure the enhanced actions card workflow integrates seamlessly with existing task management functionality.
|
||||
### Details:
|
||||
Connect the new UI components to existing backend APIs. Update data models if necessary to support new features. Ensure compatibility with existing task filters, search, and reporting features. Implement data migration plan for existing tasks if needed.
|
||||
|
||||
## 6. Test and Optimize User Experience [pending]
|
||||
### Dependencies: 47.5
|
||||
### Description: Conduct thorough testing of the enhanced workflow and optimize based on user feedback and performance metrics.
|
||||
### Details:
|
||||
Perform usability testing with representative users. Collect metrics on task completion time, error rates, and user satisfaction. Optimize performance for large task lists and complex subtask hierarchies. Implement A/B testing for alternative UI approaches if needed.
|
||||
|
||||
|
||||
@@ -42,3 +42,23 @@ Testing should verify that the refactoring maintains identical functionality whi
|
||||
4. Documentation:
|
||||
- Verify documentation is updated to reflect the new prompt organization
|
||||
- Confirm the index.js export pattern works as expected for importing prompts
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create prompts directory structure [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a centralized 'prompts' directory with appropriate subdirectories for different prompt categories
|
||||
### Details:
|
||||
Create a 'prompts' directory at the project root. Within this directory, create subdirectories based on functional categories (e.g., 'core', 'agents', 'utils'). Add an index.js file in each subdirectory to facilitate imports. Create a root index.js file that re-exports all prompts for easy access.
|
||||
|
||||
## 2. Extract prompts into individual files [pending]
|
||||
### Dependencies: 48.1
|
||||
### Description: Identify all hardcoded prompts in the codebase and extract them into individual files in the prompts directory
|
||||
### Details:
|
||||
Search through the codebase for all hardcoded prompt strings. For each prompt, create a new file in the appropriate subdirectory with a descriptive name (e.g., 'taskBreakdownPrompt.js'). Format each file to export the prompt string as a constant. Add JSDoc comments to document the purpose and expected usage of each prompt.
|
||||
|
||||
## 3. Update functions to import prompts [pending]
|
||||
### Dependencies: 48.1, 48.2
|
||||
### Description: Modify all functions that use hardcoded prompts to import them from the centralized structure
|
||||
### Details:
|
||||
For each function that previously used a hardcoded prompt, add an import statement to pull in the prompt from the centralized structure. Test each function after modification to ensure it still works correctly. Update any tests that might be affected by the refactoring. Create a pull request with the changes and document the new prompt structure in the project documentation.
|
||||
|
||||
|
||||
@@ -64,3 +64,41 @@ Testing should verify all aspects of the code analysis command:
|
||||
- Generated recommendations are specific and actionable
|
||||
- Created tasks follow the project's task format standards
|
||||
- Analysis results are consistent across multiple runs on the same codebase
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design pattern recognition algorithm [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create an algorithm to identify common code patterns and anti-patterns in the codebase
|
||||
### Details:
|
||||
Develop a system that can scan code files and identify common design patterns (Factory, Singleton, etc.) and anti-patterns (God objects, excessive coupling, etc.). Include detection for language-specific patterns and create a classification system for identified patterns.
|
||||
|
||||
## 2. Implement best practice verification [pending]
|
||||
### Dependencies: 49.1
|
||||
### Description: Build verification checks against established coding standards and best practices
|
||||
### Details:
|
||||
Create a framework to compare code against established best practices for the specific language/framework. Include checks for naming conventions, function length, complexity metrics, comment coverage, and other industry-standard quality indicators.
|
||||
|
||||
## 3. Develop AI integration for code analysis [pending]
|
||||
### Dependencies: 49.1, 49.2
|
||||
### Description: Integrate AI capabilities to enhance code analysis and provide intelligent recommendations
|
||||
### Details:
|
||||
Connect to AI services (like OpenAI) to analyze code beyond rule-based checks. Configure the AI to understand context, project-specific patterns, and provide nuanced analysis that rule-based systems might miss.
|
||||
|
||||
## 4. Create recommendation generation system [pending]
|
||||
### Dependencies: 49.2, 49.3
|
||||
### Description: Build a system to generate actionable improvement recommendations based on analysis results
|
||||
### Details:
|
||||
Develop algorithms to transform analysis results into specific, actionable recommendations. Include priority levels, effort estimates, and potential impact assessments for each recommendation.
|
||||
|
||||
## 5. Implement task creation functionality [pending]
|
||||
### Dependencies: 49.4
|
||||
### Description: Add capability to automatically create tasks from code quality recommendations
|
||||
### Details:
|
||||
Build functionality to convert recommendations into tasks in the project management system. Include appropriate metadata, assignee suggestions based on code ownership, and integration with existing workflow systems.
|
||||
|
||||
## 6. Create comprehensive reporting interface [pending]
|
||||
### Dependencies: 49.4, 49.5
|
||||
### Description: Develop a user interface to display analysis results and recommendations
|
||||
### Details:
|
||||
Build a dashboard showing code quality metrics, identified patterns, recommendations, and created tasks. Include filtering options, trend analysis over time, and the ability to drill down into specific issues with code snippets and explanations.
|
||||
|
||||
|
||||
@@ -49,3 +49,35 @@ Testing should verify both the functionality and user experience of the suggest-
|
||||
- Test with extremely large numbers of existing tasks
|
||||
|
||||
Manually verify the command produces contextually appropriate suggestions that align with the project's current state and needs.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design data collection mechanism for existing tasks [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a module to collect and format existing task data from the system for AI processing
|
||||
### Details:
|
||||
Implement a function that retrieves all existing tasks from storage, formats them appropriately for AI context, and handles edge cases like empty task lists or corrupted data. Include metadata like task status, dependencies, and creation dates to provide rich context for suggestions.
|
||||
|
||||
## 2. Implement AI integration for task suggestions [pending]
|
||||
### Dependencies: 52.1
|
||||
### Description: Develop the core functionality to generate task suggestions using AI based on existing tasks
|
||||
### Details:
|
||||
Create an AI prompt template that effectively communicates the existing task context and request for suggestions. Implement error handling for API failures, rate limiting, and malformed responses. Include parameters for controlling suggestion quantity and specificity.
|
||||
|
||||
## 3. Build interactive CLI interface for suggestions [pending]
|
||||
### Dependencies: 52.2
|
||||
### Description: Create the command-line interface for requesting and displaying task suggestions
|
||||
### Details:
|
||||
Design a user-friendly CLI command structure with appropriate flags for customization. Implement progress indicators during AI processing and format the output of suggestions in a clear, readable format. Include help text and examples in the command documentation.
|
||||
|
||||
## 4. Implement suggestion selection and task creation [pending]
|
||||
### Dependencies: 52.3
|
||||
### Description: Allow users to interactively select suggestions to convert into actual tasks
|
||||
### Details:
|
||||
Create an interactive selection interface where users can review suggestions, select which ones to create as tasks, and optionally modify them before creation. Implement batch creation capabilities and validation to ensure new tasks meet system requirements.
|
||||
|
||||
## 5. Add configuration options and flag handling [pending]
|
||||
### Dependencies: 52.3, 52.4
|
||||
### Description: Implement various configuration options and command flags for customizing suggestion behavior
|
||||
### Details:
|
||||
Create a comprehensive set of command flags for controlling suggestion quantity, specificity, format, and other parameters. Implement persistent configuration options that users can set as defaults. Document all available options and provide examples of common usage patterns.
|
||||
|
||||
|
||||
@@ -48,3 +48,35 @@ Testing should verify both the new positional argument functionality and continu
|
||||
- Verify examples in documentation show both styles where appropriate
|
||||
|
||||
All tests should pass with 100% of commands supporting both argument styles without any regression in existing functionality.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Analyze current CLI argument parsing structure [pending]
|
||||
### Dependencies: None
|
||||
### Description: Review the existing CLI argument parsing code to understand how arguments are currently processed and identify integration points for positional arguments.
|
||||
### Details:
|
||||
Document the current argument parsing flow, identify key classes and methods responsible for argument handling, and determine how named arguments are currently processed. Create a technical design document outlining the current architecture and proposed changes.
|
||||
|
||||
## 2. Design positional argument specification format [pending]
|
||||
### Dependencies: 55.1
|
||||
### Description: Create a specification for how positional arguments will be defined in command definitions, including their order, required/optional status, and type validation.
|
||||
### Details:
|
||||
Define a clear syntax for specifying positional arguments in command definitions. Consider how to handle mixed positional and named arguments, default values, and type constraints. Document the specification with examples for different command types.
|
||||
|
||||
## 3. Implement core positional argument parsing logic [pending]
|
||||
### Dependencies: 55.1, 55.2
|
||||
### Description: Modify the argument parser to recognize and process positional arguments according to the specification, while maintaining compatibility with existing named arguments.
|
||||
### Details:
|
||||
Update the parser to identify arguments without flags as positional, map them to the correct parameter based on order, and apply appropriate validation. Ensure the implementation handles missing required positional arguments and provides helpful error messages.
|
||||
|
||||
## 4. Handle edge cases and error conditions [pending]
|
||||
### Dependencies: 55.3
|
||||
### Description: Implement robust handling for edge cases such as too many/few arguments, type mismatches, and ambiguous situations between positional and named arguments.
|
||||
### Details:
|
||||
Create comprehensive error handling for scenarios like: providing both positional and named version of the same argument, incorrect argument types, missing required positional arguments, and excess positional arguments. Ensure error messages are clear and actionable for users.
|
||||
|
||||
## 5. Update documentation and create usage examples [pending]
|
||||
### Dependencies: 55.2, 55.3, 55.4
|
||||
### Description: Update CLI documentation to explain positional argument support and provide clear examples showing how to use positional arguments with different commands.
|
||||
### Details:
|
||||
Revise user documentation to include positional argument syntax, update command reference with positional argument information, and create example command snippets showing both positional and named argument usage. Include a migration guide for users transitioning from named-only to positional arguments.
|
||||
|
||||
|
||||
@@ -65,3 +65,41 @@ Acceptance Criteria:
|
||||
- Help text is comprehensive and includes examples
|
||||
- Interface is visually consistent across all commands
|
||||
- Tool remains fully functional in non-interactive environments
|
||||
|
||||
# Subtasks:
|
||||
## 1. Implement Configurable Log Levels [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a logging system with different verbosity levels that users can configure
|
||||
### Details:
|
||||
Design and implement a logging system with at least 4 levels (ERROR, WARNING, INFO, DEBUG). Add command-line options to set the verbosity level. Ensure logs are color-coded by severity and can be redirected to files. Include timestamp formatting options.
|
||||
|
||||
## 2. Design Terminal Color Scheme and Visual Elements [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a consistent and accessible color scheme for the CLI interface
|
||||
### Details:
|
||||
Define a color palette that works across different terminal environments. Implement color-coding for different task states, priorities, and command categories. Add support for terminals without color capabilities. Design visual separators, headers, and footers for different output sections.
|
||||
|
||||
## 3. Implement Progress Indicators and Loading Animations [pending]
|
||||
### Dependencies: 57.2
|
||||
### Description: Add visual feedback for long-running operations
|
||||
### Details:
|
||||
Create spinner animations for operations that take time to complete. Implement progress bars for operations with known completion percentages. Ensure animations degrade gracefully in terminals with limited capabilities. Add estimated time remaining calculations where possible.
|
||||
|
||||
## 4. Develop Interactive Selection Menus [pending]
|
||||
### Dependencies: 57.2
|
||||
### Description: Create interactive menus for task selection and configuration
|
||||
### Details:
|
||||
Implement arrow-key navigation for selecting tasks from a list. Add checkbox and radio button interfaces for multi-select and single-select options. Include search/filter functionality for large task lists. Ensure keyboard shortcuts are consistent and documented.
|
||||
|
||||
## 5. Design Tabular and Structured Output Formats [pending]
|
||||
### Dependencies: 57.2
|
||||
### Description: Improve the formatting of task lists and detailed information
|
||||
### Details:
|
||||
Create table layouts with proper column alignment for task lists. Implement tree views for displaying task hierarchies and dependencies. Add support for different output formats (plain text, JSON, CSV). Ensure outputs are properly paginated for large datasets.
|
||||
|
||||
## 6. Create Help System and Interactive Documentation [pending]
|
||||
### Dependencies: 57.2, 57.4, 57.5
|
||||
### Description: Develop an in-CLI help system with examples and contextual assistance
|
||||
### Details:
|
||||
Implement a comprehensive help command with examples for each feature. Add contextual help that suggests relevant commands based on user actions. Create interactive tutorials for new users. Include command auto-completion suggestions and syntax highlighting for command examples.
|
||||
|
||||
|
||||
@@ -71,3 +71,47 @@ Ensure all commands have proper help text and error handling for cases like no m
|
||||
- Verify the personality simulation is consistent and believable
|
||||
- Test the round-table output file readability and usefulness
|
||||
- Verify that using round-table output to update tasks produces meaningful improvements
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design Mentor System Architecture [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a comprehensive architecture for the mentor system, defining data models, relationships, and interaction patterns.
|
||||
### Details:
|
||||
Define mentor profiles structure, expertise categorization, availability tracking, and relationship to user accounts. Design the database schema for storing mentor information and interactions. Create flowcharts for mentor-mentee matching algorithms and interaction workflows.
|
||||
|
||||
## 2. Implement Mentor Profile Management [pending]
|
||||
### Dependencies: 60.1
|
||||
### Description: Develop the functionality for creating, editing, and managing mentor profiles in the system.
|
||||
### Details:
|
||||
Build UI components for mentor profile creation and editing. Implement backend APIs for profile CRUD operations. Create expertise tagging system and availability calendar. Add profile verification and approval workflows for quality control.
|
||||
|
||||
## 3. Develop Round-Table Discussion Framework [pending]
|
||||
### Dependencies: 60.1
|
||||
### Description: Create the core framework for hosting and managing round-table discussions between mentors and users.
|
||||
### Details:
|
||||
Design the discussion room data model and state management. Implement discussion scheduling and participant management. Create discussion topic and agenda setting functionality. Develop discussion moderation tools and rules enforcement mechanisms.
|
||||
|
||||
## 4. Implement LLM Integration for AI Mentors [pending]
|
||||
### Dependencies: 60.3
|
||||
### Description: Integrate LLM capabilities to simulate AI mentors that can participate in round-table discussions.
|
||||
### Details:
|
||||
Select appropriate LLM models for mentor simulation. Develop prompt engineering templates for different mentor personas and expertise areas. Implement context management to maintain conversation coherence. Create fallback mechanisms for handling edge cases in discussions.
|
||||
|
||||
## 5. Build Discussion Output Formatter [pending]
|
||||
### Dependencies: 60.3, 60.4
|
||||
### Description: Create a system to format and present round-table discussion outputs in a structured, readable format.
|
||||
### Details:
|
||||
Design templates for discussion summaries and transcripts. Implement real-time formatting of ongoing discussions. Create exportable formats for discussion outcomes (PDF, markdown, etc.). Develop highlighting and annotation features for key insights.
|
||||
|
||||
## 6. Integrate Mentor System with Task Management [pending]
|
||||
### Dependencies: 60.2, 60.3
|
||||
### Description: Connect the mentor system with the existing task management functionality to enable task-specific mentoring.
|
||||
### Details:
|
||||
Create APIs to link tasks with relevant mentors based on expertise. Implement functionality to initiate discussions around specific tasks. Develop mechanisms for mentors to provide feedback and guidance on tasks. Build notification system for task-related mentor interactions.
|
||||
|
||||
## 7. Test and Optimize Round-Table Discussions [pending]
|
||||
### Dependencies: 60.4, 60.5, 60.6
|
||||
### Description: Conduct comprehensive testing of the round-table discussion feature and optimize for performance and user experience.
|
||||
### Details:
|
||||
Perform load testing with multiple concurrent discussions. Test AI mentor responses for quality and relevance. Optimize LLM usage for cost efficiency. Conduct user testing sessions and gather feedback. Implement performance monitoring and analytics for ongoing optimization.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Task ID: 61
|
||||
# Title: Implement Flexible AI Model Management
|
||||
# Status: in-progress
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Priority: high
|
||||
# Description: Currently, Task Master only supports Claude for main operations and Perplexity for research. Users are limited in flexibility when managing AI models. Adding comprehensive support for multiple popular AI models (OpenAI, Ollama, Gemini, OpenRouter, Grok) and providing intuitive CLI commands for model management will significantly enhance usability, transparency, and adaptability to user preferences and project-specific needs. This task will now leverage Vercel's AI SDK to streamline integration and management of these models.
|
||||
@@ -486,7 +486,7 @@ The existing `ai-services.js` should be refactored to:
|
||||
7. Add verbose output option for debugging
|
||||
8. Testing approach: Create integration tests that verify model setting functionality with various inputs
|
||||
|
||||
## 8. Update Main Task Processing Logic [deferred]
|
||||
## 8. Update Main Task Processing Logic [done]
|
||||
### Dependencies: 61.4, 61.5, 61.18
|
||||
### Description: Refactor the main task processing logic to use the new AI services module and support dynamic model selection.
|
||||
### Details:
|
||||
@@ -554,7 +554,7 @@ When updating the main task processing logic, implement the following changes to
|
||||
```
|
||||
</info added on 2025-04-20T03:55:56.310Z>
|
||||
|
||||
## 9. Update Research Processing Logic [deferred]
|
||||
## 9. Update Research Processing Logic [done]
|
||||
### Dependencies: 61.4, 61.5, 61.8, 61.18
|
||||
### Description: Refactor the research processing logic to use the new AI services module and support dynamic model selection for research operations.
|
||||
### Details:
|
||||
@@ -747,7 +747,7 @@ const result = await generateObjectService({
|
||||
5. Ensure any default values previously hardcoded are now retrieved from the configuration system.
|
||||
</info added on 2025-04-20T03:55:01.707Z>
|
||||
|
||||
## 12. Refactor Basic Subtask Generation to use generateObjectService [cancelled]
|
||||
## 12. Refactor Basic Subtask Generation to use generateObjectService [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Update the `generateSubtasks` function in `ai-services.js` to use the new `generateObjectService` from `ai-services-unified.js` with a Zod schema for the subtask array.
|
||||
### Details:
|
||||
@@ -798,7 +798,7 @@ The refactoring should leverage the new configuration system:
|
||||
```
|
||||
</info added on 2025-04-20T03:54:45.542Z>
|
||||
|
||||
## 13. Refactor Research Subtask Generation to use generateObjectService [cancelled]
|
||||
## 13. Refactor Research Subtask Generation to use generateObjectService [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Update the `generateSubtasksWithPerplexity` function in `ai-services.js` to first perform research (potentially keeping the Perplexity call separate or adapting it) and then use `generateObjectService` from `ai-services-unified.js` with research results included in the prompt.
|
||||
### Details:
|
||||
@@ -828,7 +828,7 @@ const { verbose } = getLoggingConfig();
|
||||
5. Ensure the transition to generateObjectService maintains all existing functionality while leveraging the new configuration system
|
||||
</info added on 2025-04-20T03:54:26.882Z>
|
||||
|
||||
## 14. Refactor Research Task Description Generation to use generateObjectService [cancelled]
|
||||
## 14. Refactor Research Task Description Generation to use generateObjectService [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Update the `generateTaskDescriptionWithPerplexity` function in `ai-services.js` to first perform research and then use `generateObjectService` from `ai-services-unified.js` to generate the structured task description.
|
||||
### Details:
|
||||
@@ -869,7 +869,7 @@ return generateObjectService({
|
||||
5. Remove any hardcoded configuration values, ensuring all settings are retrieved from the centralized configuration system.
|
||||
</info added on 2025-04-20T03:54:04.420Z>
|
||||
|
||||
## 15. Refactor Complexity Analysis AI Call to use generateObjectService [cancelled]
|
||||
## 15. Refactor Complexity Analysis AI Call to use generateObjectService [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Update the logic that calls the AI after using `generateComplexityAnalysisPrompt` in `ai-services.js` to use the new `generateObjectService` from `ai-services-unified.js` with a Zod schema for the complexity report.
|
||||
### Details:
|
||||
@@ -916,7 +916,7 @@ The complexity analysis AI call should be updated to align with the new configur
|
||||
```
|
||||
</info added on 2025-04-20T03:53:46.120Z>
|
||||
|
||||
## 16. Refactor Task Addition AI Call to use generateObjectService [cancelled]
|
||||
## 16. Refactor Task Addition AI Call to use generateObjectService [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Update the logic that calls the AI after using `_buildAddTaskPrompt` in `ai-services.js` to use the new `generateObjectService` from `ai-services-unified.js` with a Zod schema for the single task object.
|
||||
### Details:
|
||||
@@ -961,7 +961,7 @@ To implement this refactoring, you'll need to:
|
||||
4. Update any error handling to match the new service's error patterns.
|
||||
</info added on 2025-04-20T03:53:27.455Z>
|
||||
|
||||
## 17. Refactor General Chat/Update AI Calls [deferred]
|
||||
## 17. Refactor General Chat/Update AI Calls [done]
|
||||
### Dependencies: 61.23
|
||||
### Description: Refactor functions like `sendChatWithContext` (and potentially related task update functions in `task-manager.js` if they make direct AI calls) to use `streamTextService` or `generateTextService` from `ai-services-unified.js`.
|
||||
### Details:
|
||||
@@ -1008,7 +1008,7 @@ When refactoring `sendChatWithContext` and related functions, ensure they align
|
||||
5. Ensure any default behaviors respect configuration defaults rather than hardcoded values.
|
||||
</info added on 2025-04-20T03:53:03.709Z>
|
||||
|
||||
## 18. Refactor Callers of AI Parsing Utilities [deferred]
|
||||
## 18. Refactor Callers of AI Parsing Utilities [done]
|
||||
### Dependencies: None
|
||||
### Description: Update the code that calls `parseSubtasksFromText`, `parseTaskJsonResponse`, and `parseTasksFromCompletion` to instead directly handle the structured JSON output provided by `generateObjectService` (as the refactored AI calls will now use it).
|
||||
### Details:
|
||||
@@ -1761,19 +1761,19 @@ export async function generateGoogleObject({
|
||||
```
|
||||
</info added on 2025-04-27T00:00:46.675Z>
|
||||
|
||||
## 25. Implement `ollama.js` Provider Module [pending]
|
||||
## 25. Implement `ollama.js` Provider Module [done]
|
||||
### Dependencies: None
|
||||
### Description: Create and implement the `ollama.js` module within `src/ai-providers/`. This module should contain functions to interact with local Ollama models using the **`ollama-ai-provider` library**, adhering to the standardized input/output format defined for `ai-services-unified.js`. Note the specific library used.
|
||||
### Details:
|
||||
|
||||
|
||||
## 26. Implement `mistral.js` Provider Module using Vercel AI SDK [pending]
|
||||
## 26. Implement `mistral.js` Provider Module using Vercel AI SDK [done]
|
||||
### Dependencies: None
|
||||
### Description: Create and implement the `mistral.js` module within `src/ai-providers/`. This module should contain functions to interact with Mistral AI models using the **Vercel AI SDK (`@ai-sdk/mistral`)**, adhering to the standardized input/output format defined for `ai-services-unified.js`.
|
||||
### Details:
|
||||
|
||||
|
||||
## 27. Implement `azure.js` Provider Module using Vercel AI SDK [pending]
|
||||
## 27. Implement `azure.js` Provider Module using Vercel AI SDK [done]
|
||||
### Dependencies: None
|
||||
### Description: Create and implement the `azure.js` module within `src/ai-providers/`. This module should contain functions to interact with Azure OpenAI models using the **Vercel AI SDK (`@ai-sdk/azure`)**, adhering to the standardized input/output format defined for `ai-services-unified.js`.
|
||||
### Details:
|
||||
@@ -2649,13 +2649,13 @@ Here are more detailed steps for removing unnecessary console logs:
|
||||
10. After committing changes, monitor the application in staging environment to ensure no critical information is lost.
|
||||
</info added on 2025-05-02T20:47:56.080Z>
|
||||
|
||||
## 44. Add setters for temperature, max tokens on per role basis. [pending]
|
||||
## 44. Add setters for temperature, max tokens on per role basis. [done]
|
||||
### Dependencies: None
|
||||
### Description: NOT per model/provider basis though we could probably just define those in the .taskmasterconfig file but then they would be hard-coded. if we let users define them on a per role basis, they will define incorrect values. maybe a good middle ground is to do both - we enforce maximum using known max tokens for input and output at the .taskmasterconfig level but then we also give setters to adjust temp/input tokens/output tokens for each of the 3 roles.
|
||||
### Details:
|
||||
|
||||
|
||||
## 45. Add support for Bedrock provider with ai sdk and unified service [pending]
|
||||
## 45. Add support for Bedrock provider with ai sdk and unified service [done]
|
||||
### Dependencies: None
|
||||
### Description:
|
||||
### Details:
|
||||
|
||||
@@ -9,3 +9,41 @@ Update the Taskmaster installation scripts and documentation to support Bun as a
|
||||
|
||||
# Test Strategy:
|
||||
1. Install Taskmaster using Bun on macOS, Linux, and Windows (including WSL and PowerShell), following the updated documentation. 2. Run the full installation and initialization process, verifying that the directory structure, templates, and MCP config are set up identically to npm, pnpm, and Yarn. 3. Execute all CLI commands (including 'init') and confirm functional parity. 4. If a website or account setup is required, test these flows for consistency; if not, confirm and document this. 5. Check for Bun-specific issues (e.g., install hangs) and verify that troubleshooting steps are effective. 6. Ensure the documentation is clear, accurate, and up to date for all supported platforms.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Research Bun compatibility requirements [pending]
|
||||
### Dependencies: None
|
||||
### Description: Investigate Bun's JavaScript runtime environment and identify key differences from Node.js that may affect Taskmaster's installation and operation.
|
||||
### Details:
|
||||
Research Bun's package management, module resolution, and API compatibility with Node.js. Document any potential issues or limitations that might affect Taskmaster. Identify required changes to make Taskmaster compatible with Bun's execution model.
|
||||
|
||||
## 2. Update installation scripts for Bun compatibility [pending]
|
||||
### Dependencies: 65.1
|
||||
### Description: Modify the existing installation scripts to detect and support Bun as a runtime environment.
|
||||
### Details:
|
||||
Add Bun detection logic to installation scripts. Update package management commands to use Bun equivalents where needed. Ensure all dependencies are compatible with Bun. Modify any Node.js-specific code to work with Bun's runtime.
|
||||
|
||||
## 3. Create Bun-specific installation path [pending]
|
||||
### Dependencies: 65.2
|
||||
### Description: Implement a dedicated installation flow for Bun users that optimizes for Bun's capabilities.
|
||||
### Details:
|
||||
Create a Bun-specific installation script that leverages Bun's performance advantages. Update any environment detection logic to properly identify Bun environments. Ensure proper path resolution and environment variable handling for Bun.
|
||||
|
||||
## 4. Test Taskmaster installation with Bun [pending]
|
||||
### Dependencies: 65.3
|
||||
### Description: Perform comprehensive testing of the installation process using Bun across different operating systems.
|
||||
### Details:
|
||||
Test installation on Windows, macOS, and Linux using Bun. Verify that all Taskmaster features work correctly when installed via Bun. Document any issues encountered and implement fixes as needed.
|
||||
|
||||
## 5. Test Taskmaster operation with Bun [pending]
|
||||
### Dependencies: 65.4
|
||||
### Description: Ensure all Taskmaster functionality works correctly when running under Bun.
|
||||
### Details:
|
||||
Test all Taskmaster commands and features when running with Bun. Compare performance metrics between Node.js and Bun. Identify and fix any runtime issues specific to Bun. Ensure all plugins and extensions are compatible.
|
||||
|
||||
## 6. Update documentation for Bun support [pending]
|
||||
### Dependencies: 65.4, 65.5
|
||||
### Description: Update all relevant documentation to include information about installing and running Taskmaster with Bun.
|
||||
### Details:
|
||||
Add Bun installation instructions to README and documentation. Document any Bun-specific considerations or limitations. Update troubleshooting guides to include Bun-specific issues. Create examples showing Bun usage with Taskmaster.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Task ID: 66
|
||||
# Title: Support Status Filtering in Show Command for Subtasks
|
||||
# Status: pending
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Enhance the 'show' command to accept a status parameter that filters subtasks by their current status, allowing users to view only subtasks matching a specific status.
|
||||
|
||||
@@ -9,3 +9,17 @@
|
||||
|
||||
# Test Strategy:
|
||||
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design task creation form without PRD [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a user interface form that allows users to manually input task details without requiring a PRD document
|
||||
### Details:
|
||||
Design a form with fields for task title, description, priority, assignee, due date, and other relevant task attributes. Include validation to ensure required fields are completed. The form should be intuitive and provide clear guidance on how to create a task manually.
|
||||
|
||||
## 2. Implement task saving functionality [pending]
|
||||
### Dependencies: 68.1
|
||||
### Description: Develop the backend functionality to save manually created tasks to the database
|
||||
### Details:
|
||||
Create API endpoints to handle task creation requests from the frontend. Implement data validation, error handling, and confirmation messages. Ensure the saved tasks appear in the task list view and can be edited or deleted like PRD-parsed tasks.
|
||||
|
||||
|
||||
@@ -57,3 +57,29 @@ Implementation Plan:
|
||||
* Call `analyze_project_complexity` tool without `ids`. Verify full analysis and merging.
|
||||
3. Verify report `meta` section is updated correctly on each run.
|
||||
|
||||
|
||||
# Subtasks:
|
||||
## 1. Modify core complexity analysis logic [pending]
|
||||
### Dependencies: None
|
||||
### Description: Update the core complexity analysis function to accept specific task IDs as input parameters
|
||||
### Details:
|
||||
Refactor the existing complexity analysis module to allow filtering by task IDs. This involves modifying the data processing pipeline to filter tasks before analysis, ensuring the complexity metrics are calculated only for the specified tasks while maintaining context awareness.
|
||||
|
||||
## 2. Update CLI interface for task-specific complexity analysis [pending]
|
||||
### Dependencies: 69.1
|
||||
### Description: Extend the CLI to accept task IDs as parameters for the complexity analysis command
|
||||
### Details:
|
||||
Add a new flag or parameter to the CLI that allows users to specify task IDs for targeted complexity analysis. Update the command parser, help documentation, and ensure proper validation of the provided task IDs.
|
||||
|
||||
## 3. Integrate task-specific analysis with MCP tool [pending]
|
||||
### Dependencies: 69.1
|
||||
### Description: Update the MCP tool interface to support analyzing complexity for specific tasks
|
||||
### Details:
|
||||
Modify the MCP tool's API endpoints and UI components to allow users to select specific tasks for complexity analysis. Ensure the UI provides clear feedback about which tasks are being analyzed and update the visualization components to properly display partial analysis results.
|
||||
|
||||
## 4. Create comprehensive tests for task-specific complexity analysis [pending]
|
||||
### Dependencies: 69.1, 69.2, 69.3
|
||||
### Description: Develop test cases to verify the correct functioning of task-specific complexity analysis
|
||||
### Details:
|
||||
Create unit and integration tests that verify the task-specific complexity analysis works correctly across both CLI and MCP interfaces. Include tests for edge cases such as invalid task IDs, tasks with dependencies outside the selected set, and performance tests for large task sets.
|
||||
|
||||
|
||||
@@ -9,3 +9,29 @@ The task involves implementing a new command that accepts an optional '--id' par
|
||||
|
||||
# Test Strategy:
|
||||
Verify the command functionality by testing with both specific task IDs and general invocation: 1) Run the command with a valid '--id' and ensure the resulting diagram accurately depicts the specified task's dependencies with correct color codings for statuses. 2) Execute the command without '--id' to ensure a complete workflow diagram is generated for all tasks. 3) Check that arrows correctly represent dependency relationships. 4) Validate the Markdown (.md) file export option by confirming the file format and content after saving. 5) Test error responses for non-existent task IDs and malformed inputs.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design the 'diagram' command interface [pending]
|
||||
### Dependencies: None
|
||||
### Description: Define the command structure, arguments, and options for the Mermaid diagram generation feature
|
||||
### Details:
|
||||
Create a command specification that includes: input parameters for diagram source (file, stdin, or string), output options (file, stdout, clipboard), format options (SVG, PNG, PDF), styling parameters, and help documentation. Consider compatibility with existing command patterns in the application.
|
||||
|
||||
## 2. Implement Mermaid diagram generation core functionality [pending]
|
||||
### Dependencies: 70.1
|
||||
### Description: Create the core logic to parse Mermaid syntax and generate diagram output
|
||||
### Details:
|
||||
Integrate with the Mermaid library to parse diagram syntax. Implement error handling for invalid syntax. Create the rendering pipeline to generate the diagram in memory before output. Support all standard Mermaid diagram types (flowchart, sequence, class, etc.). Include proper logging for the generation process.
|
||||
|
||||
## 3. Develop output handling mechanisms [pending]
|
||||
### Dependencies: 70.2
|
||||
### Description: Implement different output options for the generated diagrams
|
||||
### Details:
|
||||
Create handlers for different output formats (SVG, PNG, PDF). Implement file output with appropriate naming conventions and directory handling. Add clipboard support for direct pasting. Implement stdout output for piping to other commands. Include progress indicators for longer rendering operations.
|
||||
|
||||
## 4. Create documentation and examples [pending]
|
||||
### Dependencies: 70.3
|
||||
### Description: Provide comprehensive documentation and examples for the 'diagram' command
|
||||
### Details:
|
||||
Write detailed command documentation with all options explained. Create example diagrams covering different diagram types. Include troubleshooting section for common errors. Add documentation on extending the command with custom themes or templates. Create integration examples showing how to use the command in workflows with other tools.
|
||||
|
||||
|
||||
@@ -9,3 +9,41 @@ This task involves creating a new CLI command named 'progress-pdf' within the ex
|
||||
|
||||
# Test Strategy:
|
||||
Verify the completion of this task through a multi-step testing approach: 1) Unit Tests: Create tests for the PDF generation logic to ensure data (task statuses and dependencies) is correctly fetched and formatted. Mock the PDF library to test edge cases like empty task lists or broken dependency links. 2) Integration Tests: Run the 'progress-pdf' command via CLI to confirm it generates a PDF file without errors under normal conditions, with filtered task IDs, and with various status filters. Validate that the output file exists in the specified directory and can be opened. 3) Content Validation: Manually or via automated script, check the generated PDF content to ensure it accurately reflects the current project state (compare task counts and statuses against a known project state) and includes dependency diagrams as images. 4) Error Handling Tests: Simulate failures in diagram generation or PDF creation (e.g., invalid output path, library errors) and verify that appropriate error messages are logged and the command exits gracefully. 5) Accessibility Checks: Use a PDF accessibility tool or manual inspection to confirm that text is selectable and images have alt text. Run these tests across different project sizes (small with few tasks, large with complex dependencies) to ensure scalability. Document test results and include a sample PDF output in the project repository for reference.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Research and select PDF generation library [pending]
|
||||
### Dependencies: None
|
||||
### Description: Evaluate available PDF generation libraries for Node.js that can handle diagrams and formatted text
|
||||
### Details:
|
||||
Compare libraries like PDFKit, jsPDF, and Puppeteer based on features, performance, and ease of integration. Consider compatibility with diagram visualization tools. Document findings and make a recommendation with justification.
|
||||
|
||||
## 2. Design PDF template and layout [pending]
|
||||
### Dependencies: 72.1
|
||||
### Description: Create a template design for the project progress PDF including sections for summary, metrics, and dependency visualization
|
||||
### Details:
|
||||
Design should include header/footer, progress summary section, key metrics visualization, dependency diagram placement, and styling guidelines. Create a mockup of the final PDF output for approval.
|
||||
|
||||
## 3. Implement project progress data collection module [pending]
|
||||
### Dependencies: 72.1
|
||||
### Description: Develop functionality to gather and process project data for the PDF report
|
||||
### Details:
|
||||
Create functions to extract task completion percentages, milestone status, timeline adherence, and other relevant metrics from the project database. Include data transformation logic to prepare for PDF rendering.
|
||||
|
||||
## 4. Integrate with dependency visualization system [pending]
|
||||
### Dependencies: 72.1, 72.3
|
||||
### Description: Connect to the existing diagram command to generate visual representation of task dependencies
|
||||
### Details:
|
||||
Implement adapter for the diagram command output to be compatible with the PDF generation library. Handle different scales of dependency chains and ensure proper rendering of complex relationships.
|
||||
|
||||
## 5. Build PDF generation core functionality [pending]
|
||||
### Dependencies: 72.2, 72.3, 72.4
|
||||
### Description: Develop the main module that combines data and visualizations into a formatted PDF document
|
||||
### Details:
|
||||
Implement the core PDF generation logic using the selected library. Include functions for adding text sections, embedding visualizations, formatting tables, and applying the template design. Add pagination and document metadata.
|
||||
|
||||
## 6. Create export options and command interface [pending]
|
||||
### Dependencies: 72.5
|
||||
### Description: Implement user-facing commands and options for generating and saving PDF reports
|
||||
### Details:
|
||||
Develop CLI commands for PDF generation with parameters for customization (time period, detail level, etc.). Include options for automatic saving to specified locations, email distribution, and integration with existing project workflows.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Task ID: 73
|
||||
# Title: Implement Custom Model ID Support for Ollama/OpenRouter
|
||||
# Status: in-progress
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Allow users to specify custom model IDs for Ollama and OpenRouter providers via CLI flag and interactive setup, with appropriate validation and warnings.
|
||||
|
||||
@@ -9,3 +9,29 @@
|
||||
|
||||
# Test Strategy:
|
||||
1. Configure a Google model (e.g., gemini-1.5-flash-latest) as the 'research' model in `.taskmasterconfig`.\n2. Run a command with the `--research` flag (e.g., `task-master add-task --prompt='Latest news on AI SDK 4.2' --research`).\n3. Verify logs show 'Enabling Google Search Grounding'.\n4. Check if the task output incorporates recent information.\n5. Configure the same Google model as the 'main' model.\n6. Run a command *without* the `--research` flag.\n7. Verify logs *do not* show grounding being enabled.\n8. Add unit tests to `ai-services-unified.test.js` to verify the conditional logic for adding `providerOptions`. Ensure mocks correctly simulate different roles and providers.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Modify AI service layer to support Google Search Grounding [pending]
|
||||
### Dependencies: None
|
||||
### Description: Update the AI service layer to include the capability to integrate with Google Search Grounding API for research-related queries.
|
||||
### Details:
|
||||
Extend the existing AI service layer by adding new methods and interfaces to handle Google Search Grounding API calls. This includes creating authentication mechanisms, request formatters, and response parsers specific to the Google Search API. Ensure proper error handling and retry logic for API failures.
|
||||
|
||||
## 2. Implement conditional logic for research role detection [pending]
|
||||
### Dependencies: 75.1
|
||||
### Description: Create logic to detect when a conversation is in 'research mode' and should trigger the Google Search Grounding functionality.
|
||||
### Details:
|
||||
Develop heuristics or machine learning-based detection to identify when a user's query requires research capabilities. Implement a decision tree that determines when to activate Google Search Grounding based on conversation context, explicit user requests for research, or specific keywords. Include configuration options to adjust sensitivity of the detection mechanism.
|
||||
|
||||
## 3. Update supported models configuration [pending]
|
||||
### Dependencies: 75.1
|
||||
### Description: Modify the model configuration to specify which AI models can utilize the Google Search Grounding capability.
|
||||
### Details:
|
||||
Update the model configuration files to include flags for Google Search Grounding compatibility. Create a registry of supported models with their specific parameters for optimal integration with the search API. Implement version checking to ensure compatibility between model versions and the Google Search Grounding API version.
|
||||
|
||||
## 4. Create end-to-end testing suite for research functionality [pending]
|
||||
### Dependencies: 75.1, 75.2, 75.3
|
||||
### Description: Develop comprehensive tests to verify the correct operation of the Google Search Grounding integration in research contexts.
|
||||
### Details:
|
||||
Build automated test cases that cover various research scenarios, including edge cases. Create mock responses for the Google Search API to enable testing without actual API calls. Implement integration tests that verify the entire flow from user query to research-enhanced response. Include performance benchmarks to ensure the integration doesn't significantly impact response times.
|
||||
|
||||
|
||||
@@ -57,3 +57,47 @@ Implement detailed logging with different verbosity levels:
|
||||
- DEBUG: Raw request/response data
|
||||
|
||||
Run the test suite in a clean environment and confirm all expected assertions and logs are produced. Validate that new test cases can be added with minimal effort and that the framework integrates with CI pipelines. Create a CI configuration that runs tests on each commit.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Design E2E Test Framework Architecture [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a high-level design document for the E2E test framework that outlines components, interactions, and test flow
|
||||
### Details:
|
||||
Define the overall architecture of the test framework, including test runner, FastMCP server launcher, message protocol handler, and assertion components. Document how these components will interact and the data flow between them. Include error handling strategies and logging requirements.
|
||||
|
||||
## 2. Implement FastMCP Server Launcher [pending]
|
||||
### Dependencies: 76.1
|
||||
### Description: Create a component that can programmatically launch and manage the FastMCP server process over stdio
|
||||
### Details:
|
||||
Develop a module that can spawn the FastMCP server as a child process, establish stdio communication channels, handle process lifecycle events, and implement proper cleanup procedures. Include error handling for process failures and timeout mechanisms.
|
||||
|
||||
## 3. Develop Message Protocol Handler [pending]
|
||||
### Dependencies: 76.1
|
||||
### Description: Implement a handler that can serialize/deserialize messages according to the FastMCP protocol specification
|
||||
### Details:
|
||||
Create a protocol handler that formats outgoing messages and parses incoming messages according to the FastMCP protocol. Implement validation for message format compliance and error handling for malformed messages. Support all required message types defined in the protocol.
|
||||
|
||||
## 4. Create Request/Response Correlation Mechanism [pending]
|
||||
### Dependencies: 76.3
|
||||
### Description: Implement a system to track and correlate requests with their corresponding responses
|
||||
### Details:
|
||||
Develop a correlation mechanism using unique identifiers to match requests with their responses. Implement timeout handling for unresponded requests and proper error propagation. Design the API to support both synchronous and asynchronous request patterns.
|
||||
|
||||
## 5. Build Test Assertion Framework [pending]
|
||||
### Dependencies: 76.3, 76.4
|
||||
### Description: Create a set of assertion utilities specific to FastMCP server testing
|
||||
### Details:
|
||||
Develop assertion utilities that can validate server responses against expected values, verify timing constraints, and check for proper error handling. Include support for complex response validation patterns and detailed failure reporting.
|
||||
|
||||
## 6. Implement Test Cases [pending]
|
||||
### Dependencies: 76.2, 76.4, 76.5
|
||||
### Description: Develop a comprehensive set of test cases covering all FastMCP server functionality
|
||||
### Details:
|
||||
Create test cases for basic server operations, error conditions, edge cases, and performance scenarios. Organize tests into logical groups and ensure proper isolation between test cases. Include documentation for each test explaining its purpose and expected outcomes.
|
||||
|
||||
## 7. Create CI Integration and Documentation [pending]
|
||||
### Dependencies: 76.6
|
||||
### Description: Set up continuous integration for the test framework and create comprehensive documentation
|
||||
### Details:
|
||||
Configure the test framework to run in CI environments, generate reports, and fail builds appropriately. Create documentation covering framework architecture, usage instructions, test case development guidelines, and troubleshooting procedures. Include examples of extending the framework for new test scenarios.
|
||||
|
||||
|
||||
594
tasks/task_077.txt
Normal file
594
tasks/task_077.txt
Normal file
@@ -0,0 +1,594 @@
|
||||
# Task ID: 77
|
||||
# Title: Implement AI Usage Telemetry for Taskmaster (with external analytics endpoint)
|
||||
# Status: in-progress
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Capture detailed AI usage data (tokens, costs, models, commands) within Taskmaster and send this telemetry to an external, closed-source analytics backend for usage analysis, profitability measurement, and pricing optimization.
|
||||
# Details:
|
||||
* Add a telemetry utility (`logAiUsage`) within `ai-services.js` to track AI usage.
|
||||
* Collected telemetry data fields must include:
|
||||
* `timestamp`: Current date/time in ISO 8601.
|
||||
* `userId`: Unique user identifier generated at setup (stored in `.taskmasterconfig`).
|
||||
* `commandName`: Taskmaster command invoked (`expand`, `parse-prd`, `research`, etc.).
|
||||
* `modelUsed`: Name/ID of the AI model invoked.
|
||||
* `inputTokens`: Count of input tokens used.
|
||||
* `outputTokens`: Count of output tokens generated.
|
||||
* `totalTokens`: Sum of input and output tokens.
|
||||
* `totalCost`: Monetary cost calculated using pricing from `supported_models.json`.
|
||||
* Send telemetry payload securely via HTTPS POST request from user's Taskmaster installation directly to the closed-source analytics API (Express/Supabase backend).
|
||||
* Introduce a privacy notice and explicit user consent prompt upon initial installation/setup to enable telemetry.
|
||||
* Provide a graceful fallback if telemetry request fails (e.g., no internet connectivity).
|
||||
* Optionally display a usage summary directly in Taskmaster CLI output for user transparency.
|
||||
|
||||
# Test Strategy:
|
||||
|
||||
|
||||
# Subtasks:
|
||||
## 1. Implement telemetry utility and data collection [done]
|
||||
### Dependencies: None
|
||||
### Description: Create the logAiUsage utility in ai-services.js that captures all required telemetry data fields
|
||||
### Details:
|
||||
Develop the logAiUsage function that collects timestamp, userId, commandName, modelUsed, inputTokens, outputTokens, totalTokens, and totalCost. Implement token counting logic and cost calculation using pricing from supported_models.json. Ensure proper error handling and data validation.
|
||||
<info added on 2025-05-05T21:08:51.413Z>
|
||||
Develop the logAiUsage function that collects timestamp, userId, commandName, modelUsed, inputTokens, outputTokens, totalTokens, and totalCost. Implement token counting logic and cost calculation using pricing from supported_models.json. Ensure proper error handling and data validation.
|
||||
|
||||
Implementation Plan:
|
||||
1. Define `logAiUsage` function in `ai-services-unified.js` that accepts parameters: userId, commandName, providerName, modelId, inputTokens, and outputTokens.
|
||||
|
||||
2. Implement data collection and calculation logic:
|
||||
- Generate timestamp using `new Date().toISOString()`
|
||||
- Calculate totalTokens by adding inputTokens and outputTokens
|
||||
- Create a helper function `_getCostForModel(providerName, modelId)` that:
|
||||
- Loads pricing data from supported-models.json
|
||||
- Finds the appropriate provider/model entry
|
||||
- Returns inputCost and outputCost rates or defaults if not found
|
||||
- Calculate totalCost using the formula: ((inputTokens/1,000,000) * inputCost) + ((outputTokens/1,000,000) * outputCost)
|
||||
- Assemble complete telemetryData object with all required fields
|
||||
|
||||
3. Add initial logging functionality:
|
||||
- Use existing log utility to record telemetry data at 'info' level
|
||||
- Implement proper error handling with try/catch blocks
|
||||
|
||||
4. Integrate with `_unifiedServiceRunner`:
|
||||
- Modify to accept commandName and userId parameters
|
||||
- After successful API calls, extract usage data from results
|
||||
- Call logAiUsage with the appropriate parameters
|
||||
|
||||
5. Update provider functions in src/ai-providers/*.js:
|
||||
- Ensure all provider functions return both the primary result and usage statistics
|
||||
- Standardize the return format to include a usage object with inputTokens and outputTokens
|
||||
</info added on 2025-05-05T21:08:51.413Z>
|
||||
<info added on 2025-05-07T17:28:57.361Z>
|
||||
To implement the AI usage telemetry effectively, we need to update each command across our different stacks. Let's create a structured approach for this implementation:
|
||||
|
||||
Command Integration Plan:
|
||||
1. Core Function Commands:
|
||||
- Identify all AI-utilizing commands in the core function library
|
||||
- For each command, modify to pass commandName and userId to _unifiedServiceRunner
|
||||
- Update return handling to process and forward usage statistics
|
||||
|
||||
2. Direct Function Commands:
|
||||
- Map all direct function commands that leverage AI capabilities
|
||||
- Implement telemetry collection at the appropriate execution points
|
||||
- Ensure consistent error handling and telemetry reporting
|
||||
|
||||
3. MCP Tool Stack Commands:
|
||||
- Inventory all MCP commands with AI dependencies
|
||||
- Standardize the telemetry collection approach across the tool stack
|
||||
- Add telemetry hooks that maintain backward compatibility
|
||||
|
||||
For each command category, we'll need to:
|
||||
- Document current implementation details
|
||||
- Define specific code changes required
|
||||
- Create tests to verify telemetry is being properly collected
|
||||
- Establish validation procedures to ensure data accuracy
|
||||
</info added on 2025-05-07T17:28:57.361Z>
|
||||
|
||||
## 2. Implement secure telemetry transmission [deferred]
|
||||
### Dependencies: 77.1
|
||||
### Description: Create a secure mechanism to transmit telemetry data to the external analytics endpoint
|
||||
### Details:
|
||||
Implement HTTPS POST request functionality to securely send the telemetry payload to the closed-source analytics API. Include proper encryption in transit using TLS. Implement retry logic and graceful fallback mechanisms for handling transmission failures due to connectivity issues.
|
||||
<info added on 2025-05-14T17:52:40.647Z>
|
||||
To securely send structured JSON telemetry payloads from a Node.js CLI tool to an external analytics backend, follow these steps:
|
||||
|
||||
1. Use the Axios library for HTTPS POST requests. Install it with: npm install axios.
|
||||
2. Store sensitive configuration such as the analytics endpoint URL and any secret keys in environment variables (e.g., process.env.ANALYTICS_URL, process.env.ANALYTICS_KEY). Use dotenv or a similar library to load these securely.
|
||||
3. Construct the telemetry payload as a JSON object with the required fields: userId, commandName, modelUsed, inputTokens, outputTokens, totalTokens, totalCost, and timestamp (ISO 8601).
|
||||
4. Implement robust retry logic using the axios-retry package (npm install axios-retry). Configure exponential backoff with a recommended maximum of 3 retries and a base delay (e.g., 500ms).
|
||||
5. Ensure all requests use HTTPS to guarantee TLS encryption in transit. Axios automatically uses HTTPS when the endpoint URL starts with https://.
|
||||
6. Handle errors gracefully: catch all transmission errors, log them for diagnostics, and ensure failures do not interrupt or degrade the CLI user experience. Optionally, queue failed payloads for later retry if persistent connectivity issues occur.
|
||||
7. Example code snippet:
|
||||
|
||||
require('dotenv').config();
|
||||
const axios = require('axios');
|
||||
const axiosRetry = require('axios-retry');
|
||||
|
||||
axiosRetry(axios, {
|
||||
retries: 3,
|
||||
retryDelay: axiosRetry.exponentialDelay,
|
||||
retryCondition: (error) => axiosRetry.isNetworkOrIdempotentRequestError(error),
|
||||
});
|
||||
|
||||
async function sendTelemetry(payload) {
|
||||
try {
|
||||
await axios.post(process.env.ANALYTICS_URL, payload, {
|
||||
headers: {
|
||||
'Content-Type': 'application/json',
|
||||
'Authorization': `Bearer ${process.env.ANALYTICS_KEY}`,
|
||||
},
|
||||
timeout: 5000,
|
||||
});
|
||||
} catch (error) {
|
||||
// Log error, do not throw to avoid impacting CLI UX
|
||||
console.error('Telemetry transmission failed:', error.message);
|
||||
// Optionally, queue payload for later retry
|
||||
}
|
||||
}
|
||||
|
||||
const telemetryPayload = {
|
||||
userId: 'user-123',
|
||||
commandName: 'expand',
|
||||
modelUsed: 'gpt-4',
|
||||
inputTokens: 100,
|
||||
outputTokens: 200,
|
||||
totalTokens: 300,
|
||||
totalCost: 0.0123,
|
||||
timestamp: new Date().toISOString(),
|
||||
};
|
||||
|
||||
sendTelemetry(telemetryPayload);
|
||||
|
||||
8. Best practices:
|
||||
- Never hardcode secrets or endpoint URLs in source code.
|
||||
- Use environment variables and restrict access permissions.
|
||||
- Validate all payload fields before transmission.
|
||||
- Ensure the CLI continues to function even if telemetry transmission fails.
|
||||
|
||||
References: [1][2][3][5]
|
||||
</info added on 2025-05-14T17:52:40.647Z>
|
||||
<info added on 2025-05-14T17:57:18.218Z>
|
||||
User ID Retrieval and Generation:
|
||||
|
||||
The telemetry system must securely retrieve the user ID from the .taskmasterconfig globals, where it should have been generated during the initialization phase. Implementation should:
|
||||
|
||||
1. Check for an existing user ID in the .taskmasterconfig file before sending any telemetry data.
|
||||
2. If no user ID exists (for users who run AI commands without prior initialization or during upgrades), automatically generate a new UUID v4 and persist it to the .taskmasterconfig file.
|
||||
3. Implement a getOrCreateUserId() function that:
|
||||
- Reads from the global configuration file
|
||||
- Returns the existing ID if present
|
||||
- Generates a cryptographically secure UUID v4 if not present
|
||||
- Saves the newly generated ID to the configuration file
|
||||
- Handles file access errors gracefully
|
||||
|
||||
4. Example implementation:
|
||||
```javascript
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
const { v4: uuidv4 } = require('uuid');
|
||||
|
||||
function getOrCreateUserId() {
|
||||
const configPath = path.join(os.homedir(), '.taskmasterconfig');
|
||||
|
||||
try {
|
||||
// Try to read existing config
|
||||
const config = JSON.parse(fs.readFileSync(configPath, 'utf8'));
|
||||
|
||||
if (config.userId) {
|
||||
return config.userId;
|
||||
}
|
||||
|
||||
// No user ID found, generate and save
|
||||
config.userId = uuidv4();
|
||||
fs.writeFileSync(configPath, JSON.stringify(config, null, 2));
|
||||
return config.userId;
|
||||
} catch (error) {
|
||||
// Handle case where config doesn't exist or is invalid
|
||||
const userId = uuidv4();
|
||||
const newConfig = { userId };
|
||||
|
||||
try {
|
||||
fs.writeFileSync(configPath, JSON.stringify(newConfig, null, 2));
|
||||
} catch (writeError) {
|
||||
console.error('Failed to save user ID to config:', writeError.message);
|
||||
}
|
||||
|
||||
return userId;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
5. Ensure this function is called before constructing any telemetry payload to guarantee a consistent user ID across all telemetry events.
|
||||
</info added on 2025-05-14T17:57:18.218Z>
|
||||
<info added on 2025-05-15T18:45:32.123Z>
|
||||
**Invocation Point for Sending Telemetry:**
|
||||
* The primary invocation for sending the telemetry payload should occur in `scripts/modules/ai-services-unified.js`.
|
||||
* This should happen *after* the `telemetryData` object is fully constructed and *after* user consent (from subtask 77.3) has been confirmed.
|
||||
|
||||
**Dedicated Module for Transmission Logic:**
|
||||
* The actual HTTPS POST request mechanism, including TLS encryption, retry logic, and graceful fallbacks, should be implemented in a new, separate module (e.g., `scripts/modules/telemetry-sender.js` or `scripts/utils/telemetry-client.js`).
|
||||
* This module will be imported and utilized by `scripts/modules/ai-services-unified.js`.
|
||||
|
||||
**Key Considerations:**
|
||||
* Robust error handling must be in place for the telemetry transmission process; failures should be logged locally and must not disrupt core application functionality.
|
||||
* The entire telemetry sending process is contingent upon explicit user consent as outlined in subtask 77.3.
|
||||
|
||||
**Implementation Plan:**
|
||||
1. Create a new module `scripts/utils/telemetry-client.js` with the following functions:
|
||||
- `sendTelemetryData(telemetryPayload)`: Main function that handles the HTTPS POST request
|
||||
- `isUserConsentGiven()`: Helper function to check if user has consented to telemetry
|
||||
- `logTelemetryError(error)`: Helper function for consistent error logging
|
||||
|
||||
2. In `ai-services-unified.js`, after constructing the telemetryData object:
|
||||
```javascript
|
||||
const telemetryClient = require('../utils/telemetry-client');
|
||||
|
||||
// After telemetryData is constructed
|
||||
if (telemetryClient.isUserConsentGiven()) {
|
||||
// Non-blocking telemetry submission
|
||||
telemetryClient.sendTelemetryData(telemetryData)
|
||||
.catch(error => telemetryClient.logTelemetryError(error));
|
||||
}
|
||||
```
|
||||
|
||||
3. Ensure the telemetry-client module implements:
|
||||
- Axios with retry logic for robust HTTP requests
|
||||
- Proper TLS encryption via HTTPS
|
||||
- Comprehensive error handling
|
||||
- Configuration loading from environment variables
|
||||
- Validation of payload data before transmission
|
||||
</info added on 2025-05-15T18:45:32.123Z>
|
||||
|
||||
## 3. Develop user consent and privacy notice system [deferred]
|
||||
### Dependencies: None
|
||||
### Description: Create a privacy notice and explicit consent mechanism during Taskmaster setup
|
||||
### Details:
|
||||
Design and implement a clear privacy notice explaining what data is collected and how it's used. Create a user consent prompt during initial installation/setup that requires explicit opt-in. Store the consent status in the .taskmasterconfig file and respect this setting throughout the application.
|
||||
|
||||
## 4. Integrate telemetry into Taskmaster commands [done]
|
||||
### Dependencies: 77.1, 77.3
|
||||
### Description: Integrate the telemetry utility across all relevant Taskmaster commands
|
||||
### Details:
|
||||
Modify each Taskmaster command (expand, parse-prd, research, etc.) to call the logAiUsage utility after AI interactions. Ensure telemetry is only sent if user has provided consent. Implement the integration in a way that doesn't impact command performance or user experience.
|
||||
<info added on 2025-05-06T17:57:13.980Z>
|
||||
Modify each Taskmaster command (expand, parse-prd, research, etc.) to call the logAiUsage utility after AI interactions. Ensure telemetry is only sent if user has provided consent. Implement the integration in a way that doesn't impact command performance or user experience.
|
||||
|
||||
Successfully integrated telemetry calls into `addTask` (core) and `addTaskDirect` (MCP) functions by passing `commandName` and `outputType` parameters to the telemetry system. The `ai-services-unified.js` module now logs basic telemetry data, including calculated cost information, whenever the `add-task` command or tool is invoked. This integration respects user consent settings and maintains performance standards.
|
||||
</info added on 2025-05-06T17:57:13.980Z>
|
||||
|
||||
## 5. Implement usage summary display [done]
|
||||
### Dependencies: 77.1, 77.4
|
||||
### Description: Create an optional feature to display AI usage summary in the CLI output
|
||||
### Details:
|
||||
Develop functionality to display a concise summary of AI usage (tokens used, estimated cost) directly in the CLI output after command execution. Make this feature configurable through Taskmaster settings. Ensure the display is formatted clearly and doesn't clutter the main command output.
|
||||
|
||||
## 6. Telemetry Integration for parse-prd [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the parse-prd functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/parse-prd.js`):**
|
||||
* Modify AI service call to include `commandName: \'parse-prd\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }`.
|
||||
* Return object including `telemetryData`.
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/parse-prd.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/parse-prd.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
|
||||
## 7. Telemetry Integration for expand-task [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the expand-task functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/expand-task.js`):**
|
||||
* Modify AI service call to include `commandName: \'expand-task\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }`.
|
||||
* Return object including `telemetryData`.
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/expand-task.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/expand-task.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
|
||||
## 8. Telemetry Integration for expand-all-tasks [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the expand-all-tasks functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/expand-all-tasks.js`):**
|
||||
* Modify AI service call (likely within a loop or called by a helper) to include `commandName: \'expand-all-tasks\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }`.
|
||||
* Aggregate or handle `telemetryData` appropriately if multiple AI calls are made.
|
||||
* Return object including aggregated/relevant `telemetryData`.
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/expand-all-tasks.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/expand-all.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
|
||||
## 9. Telemetry Integration for update-tasks [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the update-tasks (bulk update) functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/update-tasks.js`):**
|
||||
* Modify AI service call (likely within a loop) to include `commandName: \'update-tasks\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }` for each AI call.
|
||||
* Aggregate or handle `telemetryData` appropriately for multiple calls.
|
||||
* Return object including aggregated/relevant `telemetryData`.
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/update-tasks.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/update.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
|
||||
## 10. Telemetry Integration for update-task-by-id [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the update-task-by-id functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/update-task-by-id.js`):**
|
||||
* Modify AI service call to include `commandName: \'update-task\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }`.
|
||||
* Return object including `telemetryData`.
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/update-task-by-id.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/update-task.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
|
||||
## 11. Telemetry Integration for update-subtask-by-id [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the update-subtask-by-id functionality.
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/update-subtask-by-id.js`):**
|
||||
* Verify if this function *actually* calls an AI service. If it only appends text, telemetry integration might not apply directly here, but ensure its callers handle telemetry if they use AI.
|
||||
* *If it calls AI:* Modify AI service call to include `commandName: \'update-subtask\'` and `outputType`.
|
||||
* *If it calls AI:* Receive `{ mainResult, telemetryData }`.
|
||||
* *If it calls AI:* Return object including `telemetryData`.
|
||||
* *If it calls AI:* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/update-subtask-by-id.js`):**
|
||||
* *If core calls AI:* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* *If core calls AI:* Pass `outputFormat: \'json\'` if applicable.
|
||||
* *If core calls AI:* Receive `{ ..., telemetryData }` from core.
|
||||
* *If core calls AI:* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/update-subtask.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through (if present).
|
||||
|
||||
|
||||
## 12. Telemetry Integration for analyze-task-complexity [done]
|
||||
### Dependencies: None
|
||||
### Description: Integrate AI usage telemetry capture and propagation for the analyze-task-complexity functionality. [Updated: 5/9/2025]
|
||||
### Details:
|
||||
\
|
||||
Apply telemetry pattern from telemetry.mdc:
|
||||
|
||||
1. **Core (`scripts/modules/task-manager/analyze-task-complexity.js`):**
|
||||
* Modify AI service call to include `commandName: \'analyze-complexity\'` and `outputType`.
|
||||
* Receive `{ mainResult, telemetryData }`.
|
||||
* Return object including `telemetryData` (perhaps alongside the complexity report data).
|
||||
* Handle CLI display via `displayAiUsageSummary` if applicable.
|
||||
|
||||
2. **Direct (`mcp-server/src/core/direct-functions/analyze-task-complexity.js`):**
|
||||
* Pass `commandName`, `outputType: \'mcp\'` to core.
|
||||
* Pass `outputFormat: \'json\'` if applicable.
|
||||
* Receive `{ ..., telemetryData }` from core.
|
||||
* Return `{ success: true, data: { ..., telemetryData } }`.
|
||||
|
||||
3. **Tool (`mcp-server/src/tools/analyze.js`):**
|
||||
* Verify `handleApiResult` correctly passes `data.telemetryData` through.
|
||||
|
||||
<info added on 2025-05-09T04:02:44.847Z>
|
||||
## Implementation Details for Telemetry Integration
|
||||
|
||||
### Best Practices for Implementation
|
||||
|
||||
1. **Use Structured Telemetry Objects:**
|
||||
- Create a standardized `TelemetryEvent` object with fields:
|
||||
```javascript
|
||||
{
|
||||
commandName: string, // e.g., 'analyze-complexity'
|
||||
timestamp: ISO8601 string,
|
||||
duration: number, // in milliseconds
|
||||
inputTokens: number,
|
||||
outputTokens: number,
|
||||
model: string, // e.g., 'gpt-4'
|
||||
success: boolean,
|
||||
errorType?: string, // if applicable
|
||||
metadata: object // command-specific context
|
||||
}
|
||||
```
|
||||
|
||||
2. **Asynchronous Telemetry Processing:**
|
||||
- Use non-blocking telemetry submission to avoid impacting performance
|
||||
- Implement queue-based processing for reliability during network issues
|
||||
|
||||
3. **Error Handling:**
|
||||
- Implement robust try/catch blocks around telemetry operations
|
||||
- Ensure telemetry failures don't affect core functionality
|
||||
- Log telemetry failures locally for debugging
|
||||
|
||||
4. **Privacy Considerations:**
|
||||
- Never include PII or sensitive data in telemetry
|
||||
- Implement data minimization principles
|
||||
- Add sanitization functions for metadata fields
|
||||
|
||||
5. **Testing Strategy:**
|
||||
- Create mock telemetry endpoints for testing
|
||||
- Add unit tests verifying correct telemetry data structure
|
||||
- Implement integration tests for end-to-end telemetry flow
|
||||
|
||||
### Code Implementation Examples
|
||||
|
||||
```javascript
|
||||
// Example telemetry submission function
|
||||
async function submitTelemetry(telemetryData, endpoint) {
|
||||
try {
|
||||
// Non-blocking submission
|
||||
fetch(endpoint, {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify(telemetryData)
|
||||
}).catch(err => console.error('Telemetry submission failed:', err));
|
||||
} catch (error) {
|
||||
// Log locally but don't disrupt main flow
|
||||
console.error('Telemetry error:', error);
|
||||
}
|
||||
}
|
||||
|
||||
// Example integration in AI service call
|
||||
async function callAiService(params) {
|
||||
const startTime = Date.now();
|
||||
try {
|
||||
const result = await aiService.call({
|
||||
...params,
|
||||
commandName: 'analyze-complexity',
|
||||
outputType: 'mcp'
|
||||
});
|
||||
|
||||
// Construct telemetry object
|
||||
const telemetryData = {
|
||||
commandName: 'analyze-complexity',
|
||||
timestamp: new Date().toISOString(),
|
||||
duration: Date.now() - startTime,
|
||||
inputTokens: result.usage?.prompt_tokens || 0,
|
||||
outputTokens: result.usage?.completion_tokens || 0,
|
||||
model: result.model || 'unknown',
|
||||
success: true,
|
||||
metadata: {
|
||||
taskId: params.taskId,
|
||||
// Add other relevant non-sensitive metadata
|
||||
}
|
||||
};
|
||||
|
||||
return { mainResult: result.data, telemetryData };
|
||||
} catch (error) {
|
||||
// Error telemetry
|
||||
const telemetryData = {
|
||||
commandName: 'analyze-complexity',
|
||||
timestamp: new Date().toISOString(),
|
||||
duration: Date.now() - startTime,
|
||||
success: false,
|
||||
errorType: error.name,
|
||||
metadata: {
|
||||
taskId: params.taskId,
|
||||
errorMessage: sanitizeErrorMessage(error.message)
|
||||
}
|
||||
};
|
||||
|
||||
// Re-throw the original error after capturing telemetry
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
```
|
||||
</info added on 2025-05-09T04:02:44.847Z>
|
||||
|
||||
## 13. Update google.js for Telemetry Compatibility [done]
|
||||
### Dependencies: None
|
||||
### Description: Modify src/ai-providers/google.js functions to return usage data.
|
||||
### Details:
|
||||
Update the provider functions in `src/ai-providers/google.js` to ensure they return telemetry-compatible results:\n\n1. **`generateGoogleText`**: Return `{ text: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts from the Vercel AI SDK result.\n2. **`generateGoogleObject`**: Return `{ object: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts.\n3. **`streamGoogleText`**: Return the *full stream result object* returned by the Vercel AI SDK's `streamText`, not just the `textStream` property. The full object contains usage information.\n\nReference `anthropic.js` for the pattern.
|
||||
|
||||
## 14. Update openai.js for Telemetry Compatibility [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify src/ai-providers/openai.js functions to return usage data.
|
||||
### Details:
|
||||
Update the provider functions in `src/ai-providers/openai.js` to ensure they return telemetry-compatible results:\n\n1. **`generateOpenAIText`**: Return `{ text: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts from the Vercel AI SDK result.\n2. **`generateOpenAIObject`**: Return `{ object: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts.\n3. **`streamOpenAIText`**: Return the *full stream result object* returned by the Vercel AI SDK's `streamText`, not just the `textStream` property. The full object contains usage information.\n\nReference `anthropic.js` for the pattern.
|
||||
|
||||
## 15. Update openrouter.js for Telemetry Compatibility [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify src/ai-providers/openrouter.js functions to return usage data.
|
||||
### Details:
|
||||
Update the provider functions in `src/ai-providers/openrouter.js` to ensure they return telemetry-compatible results:\n\n1. **`generateOpenRouterText`**: Return `{ text: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts from the Vercel AI SDK result.\n2. **`generateOpenRouterObject`**: Return `{ object: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts.\n3. **`streamOpenRouterText`**: Return the *full stream result object* returned by the Vercel AI SDK's `streamText`, not just the `textStream` property. The full object contains usage information.\n\nReference `anthropic.js` for the pattern.
|
||||
|
||||
## 16. Update perplexity.js for Telemetry Compatibility [done]
|
||||
### Dependencies: None
|
||||
### Description: Modify src/ai-providers/perplexity.js functions to return usage data.
|
||||
### Details:
|
||||
Update the provider functions in `src/ai-providers/perplexity.js` to ensure they return telemetry-compatible results:\n\n1. **`generatePerplexityText`**: Return `{ text: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts from the Vercel AI SDK result.\n2. **`generatePerplexityObject`**: Return `{ object: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts.\n3. **`streamPerplexityText`**: Return the *full stream result object* returned by the Vercel AI SDK's `streamText`, not just the `textStream` property. The full object contains usage information.\n\nReference `anthropic.js` for the pattern.
|
||||
|
||||
## 17. Update xai.js for Telemetry Compatibility [pending]
|
||||
### Dependencies: None
|
||||
### Description: Modify src/ai-providers/xai.js functions to return usage data.
|
||||
### Details:
|
||||
Update the provider functions in `src/ai-providers/xai.js` to ensure they return telemetry-compatible results:\n\n1. **`generateXaiText`**: Return `{ text: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts from the Vercel AI SDK result.\n2. **`generateXaiObject`**: Return `{ object: ..., usage: { inputTokens: ..., outputTokens: ... } }`. Extract token counts.\n3. **`streamXaiText`**: Return the *full stream result object* returned by the Vercel AI SDK's `streamText`, not just the `textStream` property. The full object contains usage information.\n\nReference `anthropic.js` for the pattern.
|
||||
|
||||
## 18. Create dedicated telemetry transmission module [pending]
|
||||
### Dependencies: 77.1, 77.3
|
||||
### Description: Implement a separate module for handling telemetry transmission logic
|
||||
### Details:
|
||||
Create a new module (e.g., `scripts/utils/telemetry-client.js`) that encapsulates all telemetry transmission functionality:
|
||||
|
||||
1. Implement core functions:
|
||||
- `sendTelemetryData(telemetryPayload)`: Main function to handle HTTPS POST requests
|
||||
- `isUserConsentGiven()`: Helper to check if user has consented to telemetry
|
||||
- `logTelemetryError(error)`: Helper for consistent error logging
|
||||
|
||||
2. Use Axios with retry logic:
|
||||
- Configure with exponential backoff (max 3 retries, 500ms base delay)
|
||||
- Implement proper TLS encryption via HTTPS
|
||||
- Set appropriate timeouts (5000ms recommended)
|
||||
|
||||
3. Implement robust error handling:
|
||||
- Catch all transmission errors
|
||||
- Log failures locally without disrupting application flow
|
||||
- Ensure failures are transparent to users
|
||||
|
||||
4. Configure securely:
|
||||
- Load endpoint URL and authentication from environment variables
|
||||
- Never hardcode secrets in source code
|
||||
- Validate payload data before transmission
|
||||
|
||||
5. Integration with ai-services-unified.js:
|
||||
- Import the telemetry-client module
|
||||
- Call after telemetryData object is constructed
|
||||
- Only send if user consent is confirmed
|
||||
- Use non-blocking approach to avoid performance impact
|
||||
|
||||
92
tasks/task_080.txt
Normal file
92
tasks/task_080.txt
Normal file
@@ -0,0 +1,92 @@
|
||||
# Task ID: 80
|
||||
# Title: Implement Unique User ID Generation and Storage During Installation
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Generate a unique user identifier during npm installation and store it in the .taskmasterconfig globals to enable anonymous usage tracking and telemetry without requiring user registration.
|
||||
# Details:
|
||||
This task involves implementing a mechanism to generate and store a unique user identifier during the npm installation process of Taskmaster. The implementation should:
|
||||
|
||||
1. Create a post-install script that runs automatically after npm install completes
|
||||
2. Generate a cryptographically secure random UUID v4 as the unique user identifier
|
||||
3. Check if a user ID already exists in the .taskmasterconfig file before generating a new one
|
||||
4. Add the generated user ID to the globals section of the .taskmasterconfig file
|
||||
5. Ensure the user ID persists across updates but is regenerated on fresh installations
|
||||
6. Handle edge cases such as failed installations, manual deletions of the config file, or permission issues
|
||||
7. Add appropriate logging to notify users that an anonymous ID is being generated (with clear privacy messaging)
|
||||
8. Document the purpose of this ID in the codebase and user documentation
|
||||
9. Ensure the ID generation is compatible with all supported operating systems
|
||||
10. Make the ID accessible to the telemetry system implemented in Task #77
|
||||
|
||||
The implementation should respect user privacy by:
|
||||
- Not collecting any personally identifiable information
|
||||
- Making it clear in documentation how users can opt out of telemetry
|
||||
- Ensuring the ID cannot be traced back to specific users or installations
|
||||
|
||||
This user ID will serve as the foundation for anonymous usage tracking, helping to understand how Taskmaster is used without compromising user privacy. Note that while we're implementing the ID generation now, the actual server-side collection is not yet available, so this data will initially only be stored locally.
|
||||
|
||||
# Test Strategy:
|
||||
Testing for this feature should include:
|
||||
|
||||
1. **Unit Tests**:
|
||||
- Verify the UUID generation produces valid UUIDs
|
||||
- Test the config file reading and writing functionality
|
||||
- Ensure proper error handling for file system operations
|
||||
- Verify the ID remains consistent across multiple reads
|
||||
|
||||
2. **Integration Tests**:
|
||||
- Run a complete npm installation in a clean environment and verify a new ID is generated
|
||||
- Simulate an update installation and verify the existing ID is preserved
|
||||
- Test the interaction between the ID generation and the telemetry system
|
||||
- Verify the ID is correctly stored in the expected location in .taskmasterconfig
|
||||
|
||||
3. **Manual Testing**:
|
||||
- Perform fresh installations on different operating systems (Windows, macOS, Linux)
|
||||
- Verify the installation process completes without errors
|
||||
- Check that the .taskmasterconfig file contains the generated ID
|
||||
- Test scenarios where the config file is manually deleted or corrupted
|
||||
|
||||
4. **Edge Case Testing**:
|
||||
- Test behavior when the installation is run without sufficient permissions
|
||||
- Verify handling of network disconnections during installation
|
||||
- Test with various npm versions to ensure compatibility
|
||||
- Verify behavior when .taskmasterconfig already exists but doesn't contain a user ID section
|
||||
|
||||
5. **Validation**:
|
||||
- Create a simple script to extract and analyze generated IDs to ensure uniqueness
|
||||
- Verify the ID format meets UUID v4 specifications
|
||||
- Confirm the ID is accessible to the telemetry system from Task #77
|
||||
|
||||
The test plan should include documentation of all test cases, expected results, and actual outcomes. A successful implementation will generate unique IDs for each installation while maintaining that ID across updates.
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create post-install script structure [pending]
|
||||
### Dependencies: None
|
||||
### Description: Set up the post-install script that will run automatically after npm installation to handle user ID generation.
|
||||
### Details:
|
||||
Create a new file called 'postinstall.js' in the project root. Configure package.json to run this script after installation by adding it to the 'scripts' section with the key 'postinstall'. The script should import necessary dependencies (fs, path, crypto) and set up the basic structure to access and modify the .taskmasterconfig file. Include proper error handling and logging to capture any issues during execution.
|
||||
|
||||
## 2. Implement UUID generation functionality [pending]
|
||||
### Dependencies: 80.1
|
||||
### Description: Create a function to generate cryptographically secure UUIDs v4 for unique user identification.
|
||||
### Details:
|
||||
Implement a function called 'generateUniqueUserId()' that uses the crypto module to create a UUID v4. The function should follow RFC 4122 for UUID generation to ensure uniqueness and security. Include validation to verify the generated ID matches the expected UUID v4 format. Document the function with JSDoc comments explaining its purpose for anonymous telemetry.
|
||||
|
||||
## 3. Develop config file handling logic [pending]
|
||||
### Dependencies: 80.1
|
||||
### Description: Create functions to read, parse, modify, and write to the .taskmasterconfig file for storing the user ID.
|
||||
### Details:
|
||||
Implement functions to: 1) Check if .taskmasterconfig exists and create it if not, 2) Read and parse the existing config file, 3) Check if a user ID already exists in the globals section, 4) Add or update the user ID in the globals section, and 5) Write the updated config back to disk. Handle edge cases like malformed config files, permission issues, and concurrent access. Use atomic write operations to prevent config corruption.
|
||||
|
||||
## 4. Integrate user ID generation with config storage [pending]
|
||||
### Dependencies: 80.2, 80.3
|
||||
### Description: Connect the UUID generation with the config file handling to create and store user IDs during installation.
|
||||
### Details:
|
||||
Combine the UUID generation and config handling functions to: 1) Check if a user ID already exists in config, 2) Generate a new ID only if needed, 3) Store the ID in the config file, and 4) Handle installation scenarios (fresh install vs. update). Add appropriate logging to inform users about the anonymous ID generation with privacy-focused messaging. Ensure the process is idempotent so running it multiple times won't create multiple IDs.
|
||||
|
||||
## 5. Add documentation and telemetry system access [pending]
|
||||
### Dependencies: 80.4
|
||||
### Description: Document the user ID system and create an API for the telemetry system to access the user ID.
|
||||
### Details:
|
||||
Create comprehensive documentation explaining: 1) The purpose of the anonymous ID, 2) How user privacy is protected, 3) How to opt out of telemetry, and 4) Technical details of the implementation. Implement a simple API function 'getUserId()' that reads the ID from config for use by the telemetry system. Update the README and user documentation to include information about anonymous usage tracking. Ensure cross-platform compatibility by testing on all supported operating systems. Make it clear in the documentation that while we're collecting this ID, the server-side collection is not yet implemented, so data remains local for now.
|
||||
|
||||
144
tasks/task_081.txt
Normal file
144
tasks/task_081.txt
Normal file
@@ -0,0 +1,144 @@
|
||||
# Task ID: 81
|
||||
# Title: Task #81: Implement Comprehensive Local Telemetry System with Future Server Integration Capability
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Expand the existing telemetry system to capture additional metrics about feature usage, performance, and user behavior patterns, implementing local storage and aggregation of telemetry data with the capability for future server integration.
|
||||
# Details:
|
||||
This task builds upon the existing telemetry infrastructure (Tasks #77 and #80) to provide more comprehensive insights into how users interact with the application, while storing data locally until a server endpoint becomes available.
|
||||
|
||||
Key implementation details:
|
||||
1. Identify and implement additional telemetry data points:
|
||||
- Command execution frequency and timing metrics
|
||||
- Feature usage patterns (which commands/features are most/least used)
|
||||
- Performance metrics (execution time, memory usage, etc.)
|
||||
- Error rates and types
|
||||
- Session duration and activity patterns
|
||||
- System environment information (OS, Node version, etc.)
|
||||
|
||||
2. Implement a local telemetry storage system:
|
||||
- Create a robust local storage mechanism to hold telemetry data indefinitely
|
||||
- Implement data aggregation to combine similar events and reduce storage size
|
||||
- Add data retention policies to prevent excessive local storage usage
|
||||
- Implement configurable storage limits and cleanup procedures
|
||||
- Design the storage format to be compatible with future server transmission
|
||||
|
||||
3. Add privacy-preserving mechanisms:
|
||||
- Ensure all personally identifiable information is properly anonymized
|
||||
- Implement data minimization principles (only collect what's necessary)
|
||||
- Add user-configurable telemetry levels (basic, enhanced, full)
|
||||
- Provide clear documentation on what data is collected and how it's used
|
||||
|
||||
4. Design for future server integration:
|
||||
- Create a pluggable transmission architecture that can be connected to a server later
|
||||
- Define API contracts and data formats for future server endpoints
|
||||
- Add configuration options for server URLs and authentication that will be used later
|
||||
- Implement feature flags to easily enable server transmission when available
|
||||
|
||||
5. Add telemetry debugging capabilities:
|
||||
- Create a developer mode to view telemetry data being collected
|
||||
- Implement logging of telemetry events (when in debug mode)
|
||||
- Add commands to export telemetry data for manual analysis
|
||||
- Create visualization tools for local telemetry data
|
||||
|
||||
6. Focus on user-facing benefits:
|
||||
- Implement personal usage dashboards showing the user's own patterns
|
||||
- Add productivity insights based on collected telemetry
|
||||
- Create features that allow users to optimize their workflow based on their usage data
|
||||
- Ensure all telemetry collection provides immediate value to the user
|
||||
|
||||
# Test Strategy:
|
||||
The testing strategy for the expanded telemetry system should be comprehensive and cover all aspects of the implementation:
|
||||
|
||||
1. Unit Tests:
|
||||
- Test each telemetry collection function in isolation
|
||||
- Verify proper anonymization of sensitive data
|
||||
- Test aggregation logic with various input scenarios
|
||||
- Validate local storage mechanisms with different data volumes
|
||||
- Test data retention and cleanup policies
|
||||
|
||||
2. Integration Tests:
|
||||
- Verify telemetry data is properly stored locally
|
||||
- Test the complete flow from data collection to local storage
|
||||
- Validate that the storage format is suitable for future server transmission
|
||||
- Test different application states (startup, shutdown, crash recovery)
|
||||
- Verify proper handling of storage failures
|
||||
|
||||
3. End-to-End Tests:
|
||||
- Create automated E2E tests that perform various user actions and verify telemetry is captured
|
||||
- Test with simulated long-term usage to verify storage efficiency
|
||||
- Verify that aggregated data accurately represents the performed actions
|
||||
|
||||
4. Performance Tests:
|
||||
- Measure the performance impact of the expanded telemetry system
|
||||
- Test with large volumes of telemetry data to ensure efficient handling
|
||||
- Verify memory usage remains within acceptable limits
|
||||
- Test CPU utilization during telemetry collection and storage operations
|
||||
|
||||
5. Manual Testing:
|
||||
- Verify telemetry debug mode correctly displays collected data
|
||||
- Test different telemetry level configurations
|
||||
- Manually verify the accuracy of collected metrics
|
||||
- Test the export functionality and analyze the exported data
|
||||
- Validate that user-facing insights and dashboards provide accurate and useful information
|
||||
|
||||
6. Privacy Compliance Testing:
|
||||
- Verify no PII is stored without proper anonymization
|
||||
- Test opt-out functionality works correctly
|
||||
- Ensure telemetry levels properly restrict data collection as configured
|
||||
|
||||
7. Regression Testing:
|
||||
- Verify existing functionality continues to work with the expanded telemetry
|
||||
- Ensure the system is designed to be compatible with future server integration
|
||||
|
||||
8. User Experience Testing:
|
||||
- Test the usability of personal dashboards and insights features
|
||||
- Gather feedback on the usefulness of telemetry-based recommendations
|
||||
- Verify users can easily understand their own usage patterns
|
||||
|
||||
# Subtasks:
|
||||
## 1. Implement Additional Telemetry Data Collection Points [pending]
|
||||
### Dependencies: None
|
||||
### Description: Extend the telemetry system to capture new metrics including command execution frequency, feature usage patterns, performance metrics, error rates, session data, and system environment information. [Updated: 5/8/2025] [Updated: 5/8/2025] [Updated: 5/8/2025]
|
||||
### Details:
|
||||
Create new telemetry event types and collection points throughout the codebase. Implement hooks in the command execution pipeline to track timing and frequency. Add performance monitoring for key operations using high-resolution timers. Capture system environment data at startup. Implement error tracking that records error types and frequencies. Add session tracking with start/end events and periodic heartbeats.
|
||||
<info added on 2025-05-08T22:57:23.259Z>
|
||||
This is a test note added via the MCP tool. The telemetry collection system should be thoroughly tested before implementation.
|
||||
</info added on 2025-05-08T22:57:23.259Z>
|
||||
<info added on 2025-05-08T22:59:29.818Z>
|
||||
For future server integration, Prometheus time-series database with its companion storage solutions (like Cortex or Thanos) would be an excellent choice for handling our telemetry data. The local telemetry collection system should be designed with compatible data structures and metrics formatting that will allow seamless export to Prometheus once server-side infrastructure is in place. This approach would provide powerful querying capabilities, visualization options through Grafana, and scalable long-term storage. Consider implementing the OpenMetrics format locally to ensure compatibility with the Prometheus ecosystem.
|
||||
</info added on 2025-05-08T22:59:29.818Z>
|
||||
<info added on 2025-05-08T23:02:59.692Z>
|
||||
Prometheus would be an excellent choice for server-side telemetry storage and analysis. When designing the local telemetry collection system, we should structure our metrics and events to be compatible with Prometheus' data model (time series with key-value pairs). This would allow for straightforward export to Prometheus once server infrastructure is established. For long-term storage, companion solutions like Cortex or Thanos could extend Prometheus' capabilities, enabling historical analysis and scalable retention. Additionally, adopting the OpenMetrics format locally would ensure seamless integration with the broader Prometheus ecosystem, including visualization through Grafana dashboards.
|
||||
</info added on 2025-05-08T23:02:59.692Z>
|
||||
|
||||
## 2. Build Robust Local Telemetry Storage System [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a persistent local storage mechanism to hold telemetry data indefinitely with aggregation capabilities to combine similar events and reduce storage requirements.
|
||||
### Details:
|
||||
Implement a persistent local store using SQLite or similar lightweight database. Create data schemas for different telemetry types. Develop aggregation functions that can combine similar events (e.g., multiple instances of the same command) into summary statistics. Implement data retention policies to prevent excessive storage usage. Add serialization/deserialization for telemetry objects. Design the storage format to be compatible with future server transmission needs.
|
||||
|
||||
## 3. Design Server Transmission Architecture for Future Implementation [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create a pluggable architecture for future server transmission capabilities while maintaining local-only functionality for now.
|
||||
### Details:
|
||||
Design a modular transmission system with clear interfaces that can be implemented later when a server becomes available. Define data formats and API contracts for future server endpoints. Add configuration options for server URLs and authentication that will be used in the future. Implement feature flags to easily enable server transmission when available. Create a transmission queue design that can be activated later. Document the architecture for future implementation.
|
||||
|
||||
## 4. Implement Privacy Controls and User Configuration [pending]
|
||||
### Dependencies: None
|
||||
### Description: Add privacy-preserving mechanisms including data anonymization, minimization principles, and user-configurable telemetry levels.
|
||||
### Details:
|
||||
Create a telemetry sanitization layer that removes or hashes PII before storage. Implement three telemetry levels (basic, enhanced, full) with clear documentation of what each includes. Add user settings UI for controlling telemetry levels. Create a first-run experience that explains telemetry and requests user consent. Implement runtime filtering of telemetry events based on user settings.
|
||||
|
||||
## 5. Add Telemetry Debugging and Local Analysis Tools [pending]
|
||||
### Dependencies: None
|
||||
### Description: Create developer tools for debugging telemetry including a developer mode to view collected data, logging capabilities, and local data analysis features.
|
||||
### Details:
|
||||
Implement a developer console command to toggle telemetry debug mode. Create a UI panel that displays collected telemetry data when in debug mode. Add detailed logging of telemetry events to the application log when debugging is enabled. Create commands to export telemetry data in various formats (JSON, CSV) for manual analysis. Implement basic visualization tools for local telemetry data to help users understand their own usage patterns.
|
||||
|
||||
## 6. Develop User-Facing Telemetry Benefits [pending]
|
||||
### Dependencies: 81.1, 81.2
|
||||
### Description: Create features that provide immediate value to users based on their telemetry data, focusing on personal insights and workflow optimization.
|
||||
### Details:
|
||||
Implement a personal usage dashboard that visualizes the user's command usage patterns, feature adoption, and productivity trends. Create a 'productivity insights' feature that offers personalized recommendations based on usage patterns. Add workflow optimization suggestions that help users discover more efficient ways to use the application. Develop weekly/monthly usage reports that users can view to track their own progress. Ensure all telemetry collection has a direct benefit to the user in the absence of server-side analysis.
|
||||
|
||||
34
tasks/task_082.txt
Normal file
34
tasks/task_082.txt
Normal file
@@ -0,0 +1,34 @@
|
||||
# Task ID: 82
|
||||
# Title: Update supported-models.json with token limit fields
|
||||
# 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.
|
||||
# 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
|
||||
}
|
||||
```
|
||||
|
||||
# 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
|
||||
95
tasks/task_083.txt
Normal file
95
tasks/task_083.txt
Normal file
@@ -0,0 +1,95 @@
|
||||
# Task ID: 83
|
||||
# Title: Update config-manager.js defaults and getters
|
||||
# Status: pending
|
||||
# Dependencies: 82
|
||||
# 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.
|
||||
# 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
|
||||
};
|
||||
```
|
||||
|
||||
# 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)
|
||||
|
||||
# Subtasks:
|
||||
## 1. Update config-manager.js with specific token limit fields [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.
|
||||
### 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
|
||||
|
||||
93
tasks/task_084.txt
Normal file
93
tasks/task_084.txt
Normal file
@@ -0,0 +1,93 @@
|
||||
# Task ID: 84
|
||||
# Title: Implement token counting utility
|
||||
# Status: pending
|
||||
# Dependencies: 82
|
||||
# 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.
|
||||
# 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);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
# 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
|
||||
104
tasks/task_085.txt
Normal file
104
tasks/task_085.txt
Normal file
@@ -0,0 +1,104 @@
|
||||
# Task ID: 85
|
||||
# Title: Update ai-services-unified.js for dynamic token limits
|
||||
# Status: pending
|
||||
# Dependencies: 83, 84
|
||||
# Priority: medium
|
||||
# Description: Modify the _unifiedServiceRunner function in ai-services-unified.js to use the new token counting utility and dynamically adjust output token limits based on input length.
|
||||
# Details:
|
||||
1. Import the token counter in `ai-services-unified.js`:
|
||||
```javascript
|
||||
const { countTokens } = require('./token-counter');
|
||||
const { getParametersForRole, getModelCapabilities } = require('./config-manager');
|
||||
```
|
||||
|
||||
2. Update the `_unifiedServiceRunner` function to implement dynamic token limit adjustment:
|
||||
```javascript
|
||||
async function _unifiedServiceRunner({
|
||||
serviceType,
|
||||
provider,
|
||||
modelId,
|
||||
systemPrompt,
|
||||
prompt,
|
||||
temperature,
|
||||
currentRole,
|
||||
effectiveProjectRoot,
|
||||
// ... other parameters
|
||||
}) {
|
||||
// Get role parameters with new token limits
|
||||
const roleParams = getParametersForRole(currentRole, effectiveProjectRoot);
|
||||
|
||||
// Get model capabilities
|
||||
const modelCapabilities = getModelCapabilities(provider, modelId);
|
||||
|
||||
// Count tokens in the prompts
|
||||
const systemPromptTokens = countTokens(systemPrompt, provider, modelId);
|
||||
const userPromptTokens = countTokens(prompt, provider, modelId);
|
||||
const totalPromptTokens = systemPromptTokens + userPromptTokens;
|
||||
|
||||
// Validate against input token limits
|
||||
if (totalPromptTokens > roleParams.maxInputTokens) {
|
||||
throw new Error(
|
||||
`Prompt (${totalPromptTokens} tokens) exceeds configured max input tokens (${roleParams.maxInputTokens}) for role '${currentRole}'.`
|
||||
);
|
||||
}
|
||||
|
||||
// Validate against model's absolute context window
|
||||
if (modelCapabilities.contextWindowTokens && totalPromptTokens > modelCapabilities.contextWindowTokens) {
|
||||
throw new Error(
|
||||
`Prompt (${totalPromptTokens} tokens) exceeds model's context window (${modelCapabilities.contextWindowTokens}) for ${modelId}.`
|
||||
);
|
||||
}
|
||||
|
||||
// Calculate available output tokens
|
||||
// If model has a combined context window, we need to subtract input tokens
|
||||
let availableOutputTokens = roleParams.maxOutputTokens;
|
||||
|
||||
// If model has a context window constraint, ensure we don't exceed it
|
||||
if (modelCapabilities.contextWindowTokens) {
|
||||
const remainingContextTokens = modelCapabilities.contextWindowTokens - totalPromptTokens;
|
||||
availableOutputTokens = Math.min(availableOutputTokens, remainingContextTokens);
|
||||
}
|
||||
|
||||
// Also respect the model's absolute max output limit
|
||||
if (modelCapabilities.maxOutputTokens) {
|
||||
availableOutputTokens = Math.min(availableOutputTokens, modelCapabilities.maxOutputTokens);
|
||||
}
|
||||
|
||||
// Prepare API call parameters
|
||||
const callParams = {
|
||||
apiKey,
|
||||
modelId,
|
||||
maxTokens: availableOutputTokens, // Use dynamically calculated output limit
|
||||
temperature: roleParams.temperature,
|
||||
messages,
|
||||
baseUrl,
|
||||
...(serviceType === 'generateObject' && { schema, objectName }),
|
||||
...restApiParams
|
||||
};
|
||||
|
||||
// Log token usage information
|
||||
console.debug(`Token usage: ${totalPromptTokens} input tokens, ${availableOutputTokens} max output tokens`);
|
||||
|
||||
// Rest of the function remains the same...
|
||||
}
|
||||
```
|
||||
|
||||
3. Update the error handling to provide clear messages about token limits:
|
||||
```javascript
|
||||
try {
|
||||
// Existing code...
|
||||
} catch (error) {
|
||||
if (error.message.includes('tokens')) {
|
||||
// Token-related errors should be clearly identified
|
||||
console.error(`Token limit error: ${error.message}`);
|
||||
}
|
||||
throw error;
|
||||
}
|
||||
```
|
||||
|
||||
# Test Strategy:
|
||||
1. Test with prompts of various lengths to verify dynamic adjustment
|
||||
2. Test with different models to ensure model-specific limits are respected
|
||||
3. Verify error messages are clear when limits are exceeded
|
||||
4. Test edge cases: very short prompts, prompts near the limit
|
||||
5. Integration test with actual API calls to verify the calculated limits work in practice
|
||||
107
tasks/task_086.txt
Normal file
107
tasks/task_086.txt
Normal file
@@ -0,0 +1,107 @@
|
||||
# Task ID: 86
|
||||
# Title: Update .taskmasterconfig schema and user guide
|
||||
# Status: pending
|
||||
# Dependencies: 83
|
||||
# Priority: medium
|
||||
# Description: Create a migration guide for users to update their .taskmasterconfig files and document the new token limit configuration options.
|
||||
# Details:
|
||||
1. Create a migration script or guide for users to update their existing `.taskmasterconfig` files:
|
||||
|
||||
```javascript
|
||||
// Example migration snippet for .taskmasterconfig
|
||||
{
|
||||
"main": {
|
||||
// Before:
|
||||
// "maxTokens": 16000,
|
||||
|
||||
// After:
|
||||
"maxInputTokens": 16000,
|
||||
"maxOutputTokens": 4000,
|
||||
"temperature": 0.7
|
||||
},
|
||||
"research": {
|
||||
"maxInputTokens": 16000,
|
||||
"maxOutputTokens": 4000,
|
||||
"temperature": 0.7
|
||||
},
|
||||
"fallback": {
|
||||
"maxInputTokens": 8000,
|
||||
"maxOutputTokens": 2000,
|
||||
"temperature": 0.7
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. Update the user documentation to explain the new token limit fields:
|
||||
|
||||
```markdown
|
||||
# Token Limit Configuration
|
||||
|
||||
Task Master now provides more granular control over token limits with separate settings for input and output tokens:
|
||||
|
||||
- `maxInputTokens`: Maximum number of tokens allowed in the input prompt (system prompt + user prompt)
|
||||
- `maxOutputTokens`: Maximum number of tokens the model should generate in its response
|
||||
|
||||
## Benefits
|
||||
|
||||
- More precise control over token usage
|
||||
- Better cost management
|
||||
- Reduced likelihood of hitting model context limits
|
||||
- Dynamic adjustment to maximize output space based on input length
|
||||
|
||||
## Migration from Previous Versions
|
||||
|
||||
If you're upgrading from a previous version, you'll need to update your `.taskmasterconfig` file:
|
||||
|
||||
1. Replace the single `maxTokens` field with separate `maxInputTokens` and `maxOutputTokens` fields
|
||||
2. Recommended starting values:
|
||||
- Set `maxInputTokens` to your previous `maxTokens` value
|
||||
- Set `maxOutputTokens` to approximately 1/4 of your model's context window
|
||||
|
||||
## Example Configuration
|
||||
|
||||
```json
|
||||
{
|
||||
"main": {
|
||||
"maxInputTokens": 16000,
|
||||
"maxOutputTokens": 4000,
|
||||
"temperature": 0.7
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
3. Update the schema validation in `config-manager.js` to validate the new fields:
|
||||
|
||||
```javascript
|
||||
function _validateConfig(config) {
|
||||
// ... existing validation
|
||||
|
||||
// Validate token limits for each role
|
||||
['main', 'research', 'fallback'].forEach(role => {
|
||||
if (config[role]) {
|
||||
// Check if old maxTokens is present and warn about migration
|
||||
if (config[role].maxTokens !== undefined) {
|
||||
console.warn(`Warning: 'maxTokens' in ${role} role is deprecated. Please use 'maxInputTokens' and 'maxOutputTokens' instead.`);
|
||||
}
|
||||
|
||||
// Validate new token limit fields
|
||||
if (config[role].maxInputTokens !== undefined && (!Number.isInteger(config[role].maxInputTokens) || config[role].maxInputTokens <= 0)) {
|
||||
throw new Error(`Invalid maxInputTokens for ${role} role: must be a positive integer`);
|
||||
}
|
||||
|
||||
if (config[role].maxOutputTokens !== undefined && (!Number.isInteger(config[role].maxOutputTokens) || config[role].maxOutputTokens <= 0)) {
|
||||
throw new Error(`Invalid maxOutputTokens for ${role} role: must be a positive integer`);
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
return config;
|
||||
}
|
||||
```
|
||||
|
||||
# Test Strategy:
|
||||
1. Verify documentation is clear and provides migration steps
|
||||
2. Test the validation logic with various config formats
|
||||
3. Test backward compatibility with old config format
|
||||
4. Ensure error messages are helpful when validation fails
|
||||
119
tasks/task_087.txt
Normal file
119
tasks/task_087.txt
Normal file
@@ -0,0 +1,119 @@
|
||||
# Task ID: 87
|
||||
# Title: Implement validation and error handling
|
||||
# Status: pending
|
||||
# Dependencies: 85
|
||||
# Priority: low
|
||||
# Description: Add comprehensive validation and error handling for token limits throughout the system, including helpful error messages and graceful fallbacks.
|
||||
# Details:
|
||||
1. Add validation when loading models in `config-manager.js`:
|
||||
```javascript
|
||||
function _validateModelMap(modelMap) {
|
||||
// Validate each provider's models
|
||||
Object.entries(modelMap).forEach(([provider, models]) => {
|
||||
models.forEach(model => {
|
||||
// Check for required token limit fields
|
||||
if (!model.contextWindowTokens) {
|
||||
console.warn(`Warning: Model ${model.id} from ${provider} is missing contextWindowTokens field`);
|
||||
}
|
||||
if (!model.maxOutputTokens) {
|
||||
console.warn(`Warning: Model ${model.id} from ${provider} is missing maxOutputTokens field`);
|
||||
}
|
||||
});
|
||||
});
|
||||
return modelMap;
|
||||
}
|
||||
```
|
||||
|
||||
2. Add validation when setting up a model in the CLI:
|
||||
```javascript
|
||||
function validateModelConfig(modelConfig, modelCapabilities) {
|
||||
const issues = [];
|
||||
|
||||
// Check if input tokens exceed model's context window
|
||||
if (modelConfig.maxInputTokens > modelCapabilities.contextWindowTokens) {
|
||||
issues.push(`maxInputTokens (${modelConfig.maxInputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
|
||||
}
|
||||
|
||||
// Check if output tokens exceed model's maximum
|
||||
if (modelConfig.maxOutputTokens > modelCapabilities.maxOutputTokens) {
|
||||
issues.push(`maxOutputTokens (${modelConfig.maxOutputTokens}) exceeds model's maximum output tokens (${modelCapabilities.maxOutputTokens})`);
|
||||
}
|
||||
|
||||
// Check if combined tokens exceed context window
|
||||
if (modelConfig.maxInputTokens + modelConfig.maxOutputTokens > modelCapabilities.contextWindowTokens) {
|
||||
issues.push(`Combined maxInputTokens and maxOutputTokens (${modelConfig.maxInputTokens + modelConfig.maxOutputTokens}) exceeds model's context window (${modelCapabilities.contextWindowTokens})`);
|
||||
}
|
||||
|
||||
return issues;
|
||||
}
|
||||
```
|
||||
|
||||
3. Add graceful fallbacks in `ai-services-unified.js`:
|
||||
```javascript
|
||||
// Fallback for missing token limits
|
||||
if (!roleParams.maxInputTokens) {
|
||||
console.warn(`Warning: maxInputTokens not specified for role '${currentRole}'. Using default value.`);
|
||||
roleParams.maxInputTokens = 8000; // Reasonable default
|
||||
}
|
||||
|
||||
if (!roleParams.maxOutputTokens) {
|
||||
console.warn(`Warning: maxOutputTokens not specified for role '${currentRole}'. Using default value.`);
|
||||
roleParams.maxOutputTokens = 2000; // Reasonable default
|
||||
}
|
||||
|
||||
// Fallback for missing model capabilities
|
||||
if (!modelCapabilities.contextWindowTokens) {
|
||||
console.warn(`Warning: contextWindowTokens not specified for model ${modelId}. Using conservative estimate.`);
|
||||
modelCapabilities.contextWindowTokens = roleParams.maxInputTokens + roleParams.maxOutputTokens;
|
||||
}
|
||||
|
||||
if (!modelCapabilities.maxOutputTokens) {
|
||||
console.warn(`Warning: maxOutputTokens not specified for model ${modelId}. Using role configuration.`);
|
||||
modelCapabilities.maxOutputTokens = roleParams.maxOutputTokens;
|
||||
}
|
||||
```
|
||||
|
||||
4. Add detailed logging for token usage:
|
||||
```javascript
|
||||
function logTokenUsage(provider, modelId, inputTokens, outputTokens, role) {
|
||||
const inputCost = calculateTokenCost(provider, modelId, 'input', inputTokens);
|
||||
const outputCost = calculateTokenCost(provider, modelId, 'output', outputTokens);
|
||||
|
||||
console.info(`Token usage for ${role} role with ${provider}/${modelId}:`);
|
||||
console.info(`- Input: ${inputTokens.toLocaleString()} tokens ($${inputCost.toFixed(6)})`);
|
||||
console.info(`- Output: ${outputTokens.toLocaleString()} tokens ($${outputCost.toFixed(6)})`);
|
||||
console.info(`- Total cost: $${(inputCost + outputCost).toFixed(6)}`);
|
||||
console.info(`- Available output tokens: ${availableOutputTokens.toLocaleString()}`);
|
||||
}
|
||||
```
|
||||
|
||||
5. Add a helper function to suggest configuration improvements:
|
||||
```javascript
|
||||
function suggestTokenConfigImprovements(roleParams, modelCapabilities, promptTokens) {
|
||||
const suggestions = [];
|
||||
|
||||
// If prompt is using less than 50% of allowed input
|
||||
if (promptTokens < roleParams.maxInputTokens * 0.5) {
|
||||
suggestions.push(`Consider reducing maxInputTokens from ${roleParams.maxInputTokens} to save on potential costs`);
|
||||
}
|
||||
|
||||
// If output tokens are very limited due to large input
|
||||
const availableOutput = Math.min(
|
||||
roleParams.maxOutputTokens,
|
||||
modelCapabilities.contextWindowTokens - promptTokens
|
||||
);
|
||||
|
||||
if (availableOutput < roleParams.maxOutputTokens * 0.5) {
|
||||
suggestions.push(`Available output tokens (${availableOutput}) are significantly less than configured maxOutputTokens (${roleParams.maxOutputTokens}) due to large input`);
|
||||
}
|
||||
|
||||
return suggestions;
|
||||
}
|
||||
```
|
||||
|
||||
# Test Strategy:
|
||||
1. Test validation functions with valid and invalid configurations
|
||||
2. Verify fallback behavior works correctly when configuration is missing
|
||||
3. Test error messages are clear and actionable
|
||||
4. Test logging functions provide useful information
|
||||
5. Verify suggestion logic provides helpful recommendations
|
||||
1392
tasks/tasks.json
1392
tasks/tasks.json
File diff suppressed because one or more lines are too long
@@ -5,6 +5,42 @@
|
||||
# It requires curl and jq to be installed.
|
||||
# It expects the project root path to be passed as the second argument.
|
||||
|
||||
# --- New Function: extract_and_sum_cost ---
|
||||
# Takes a string containing command output.
|
||||
# Extracts costs (lines with "Est. Cost: $X.YYYYYY" or similar from telemetry output)
|
||||
# from the output, sums them, and adds them to the GLOBAL total_e2e_cost variable.
|
||||
extract_and_sum_cost() {
|
||||
local command_output="$1"
|
||||
# Ensure total_e2e_cost is treated as a number, default to 0.0 if not set or invalid
|
||||
if ! [[ "$total_e2e_cost" =~ ^[0-9]+(\.[0-9]+)?$ ]]; then
|
||||
total_e2e_cost="0.0"
|
||||
fi
|
||||
|
||||
local extracted_cost_sum="0.0"
|
||||
|
||||
# Grep for lines containing "Est. Cost: $", then extract the numeric value.
|
||||
# Example line: │ Est. Cost: $0.093549 │
|
||||
# Accumulate all costs found in the command_output
|
||||
while IFS= read -r line; do
|
||||
# Extract the numeric part after 'Est. Cost: $' and before any trailing spaces/chars
|
||||
cost_value=$(echo "$line" | grep -o -E 'Est\. Cost: \$([0-9]+\.[0-9]+)' | sed -E 's/Est\. Cost: \$//g')
|
||||
if [[ -n "$cost_value" && "$cost_value" =~ ^[0-9]+\.[0-9]+$ ]]; then
|
||||
# echo "[DEBUG] Found cost value: $cost_value in line: '$line'" # For debugging
|
||||
extracted_cost_sum=$(echo "$extracted_cost_sum + $cost_value" | bc)
|
||||
# else # For debugging
|
||||
# echo "[DEBUG] No valid cost value found or extracted in line: '$line' (extracted: '$cost_value')" # For debugging
|
||||
fi
|
||||
done < <(echo "$command_output" | grep -E 'Est\. Cost: \$')
|
||||
|
||||
# echo "[DEBUG] Extracted sum from this command output: $extracted_cost_sum" # For debugging
|
||||
if (( $(echo "$extracted_cost_sum > 0" | bc -l) )); then
|
||||
total_e2e_cost=$(echo "$total_e2e_cost + $extracted_cost_sum" | bc)
|
||||
# echo "[DEBUG] Updated global total_e2e_cost: $total_e2e_cost" # For debugging
|
||||
fi
|
||||
# No echo here, the function modifies a global variable.
|
||||
}
|
||||
export -f extract_and_sum_cost # Export for use in other scripts if sourced
|
||||
|
||||
analyze_log_with_llm() {
|
||||
local log_file="$1"
|
||||
local project_root="$2" # Expect project root as the second argument
|
||||
@@ -15,17 +51,17 @@ analyze_log_with_llm() {
|
||||
fi
|
||||
|
||||
local env_file="${project_root}/.env" # Path to .env in project root
|
||||
local supported_models_file="${project_root}/scripts/modules/supported-models.json"
|
||||
|
||||
local provider_summary_log="provider_add_task_summary.log" # File summarizing provider test outcomes
|
||||
local api_key=""
|
||||
# !!! IMPORTANT: Replace with your actual Claude API endpoint if different !!!
|
||||
local api_endpoint="https://api.anthropic.com/v1/messages"
|
||||
# !!! IMPORTANT: Ensure this matches the variable name in your .env file !!!
|
||||
local api_key_name="ANTHROPIC_API_KEY"
|
||||
local llm_analysis_model_id="claude-3-7-sonnet-20250219" # Model used for this analysis
|
||||
local llm_analysis_provider="anthropic"
|
||||
|
||||
echo "" # Add a newline before analysis starts
|
||||
|
||||
# Check for jq and curl
|
||||
if ! command -v jq &> /dev/null; then
|
||||
echo "[HELPER_ERROR] LLM Analysis requires 'jq'. Skipping analysis." >&2
|
||||
return 1
|
||||
@@ -34,34 +70,31 @@ analyze_log_with_llm() {
|
||||
echo "[HELPER_ERROR] LLM Analysis requires 'curl'. Skipping analysis." >&2
|
||||
return 1
|
||||
fi
|
||||
if ! command -v bc &> /dev/null; then
|
||||
echo "[HELPER_ERROR] LLM Analysis requires 'bc' for cost calculation. Skipping analysis." >&2
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Check for API Key in the PROJECT ROOT's .env file
|
||||
if [ -f "$env_file" ]; then
|
||||
# Original assignment - Reading from project root .env
|
||||
api_key=$(grep "^${api_key_name}=" "$env_file" | sed -e "s/^${api_key_name}=//" -e 's/^[[:space:]"]*//' -e 's/[[:space:]"]*$//')
|
||||
fi
|
||||
|
||||
if [ -z "$api_key" ]; then
|
||||
echo "[HELPER_ERROR] ${api_key_name} not found or empty in project root .env file ($env_file). Skipping LLM analysis." >&2 # Updated error message
|
||||
echo "[HELPER_ERROR] ${api_key_name} not found or empty in project root .env file ($env_file). Skipping LLM analysis." >&2
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Log file path is passed as argument, need to ensure it exists relative to where the script *calling* this function is, OR use absolute path.
|
||||
# Assuming absolute path or path relative to the initial PWD for simplicity here.
|
||||
# The calling script passes the correct path relative to the original PWD.
|
||||
if [ ! -f "$log_file" ]; then
|
||||
echo "[HELPER_ERROR] Log file not found: $log_file (PWD: $(pwd)). Check path passed to function. Skipping LLM analysis." >&2 # Updated error
|
||||
echo "[HELPER_ERROR] Log file not found: $log_file (PWD: $(pwd)). Check path passed to function. Skipping LLM analysis." >&2
|
||||
return 1
|
||||
fi
|
||||
|
||||
local log_content
|
||||
# Read entire file, handle potential errors
|
||||
log_content=$(cat "$log_file") || {
|
||||
echo "[HELPER_ERROR] Failed to read log file: $log_file. Skipping LLM analysis." >&2
|
||||
return 1
|
||||
}
|
||||
|
||||
# Prepare the prompt using a quoted heredoc for literal interpretation
|
||||
read -r -d '' prompt_template <<'EOF'
|
||||
Analyze the following E2E test log for the task-master tool. The log contains output from various 'task-master' commands executed sequentially.
|
||||
|
||||
@@ -99,41 +132,34 @@ Here is the main log content:
|
||||
|
||||
%s
|
||||
EOF
|
||||
# Note: The final %s is a placeholder for printf later
|
||||
|
||||
local full_prompt
|
||||
# Use printf to substitute the log content into the %s placeholder
|
||||
if ! printf -v full_prompt "$prompt_template" "$log_content"; then
|
||||
echo "[HELPER_ERROR] Failed to format prompt using printf." >&2
|
||||
# It's unlikely printf itself fails, but good practice
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Construct the JSON payload for Claude Messages API
|
||||
local payload
|
||||
payload=$(jq -n --arg prompt "$full_prompt" '{
|
||||
"model": "claude-3-haiku-20240307", # Using Haiku for faster/cheaper testing
|
||||
"max_tokens": 3072, # Increased slightly
|
||||
"model": "'"$llm_analysis_model_id"'",
|
||||
"max_tokens": 3072,
|
||||
"messages": [
|
||||
{"role": "user", "content": $prompt}
|
||||
]
|
||||
# "temperature": 0.0 # Optional: Lower temperature for more deterministic JSON output
|
||||
}') || {
|
||||
echo "[HELPER_ERROR] Failed to create JSON payload using jq." >&2
|
||||
return 1
|
||||
}
|
||||
|
||||
local response_raw response_http_code response_body
|
||||
# Capture body and HTTP status code separately
|
||||
response_raw=$(curl -s -w "\nHTTP_STATUS_CODE:%{http_code}" -X POST "$api_endpoint" \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "x-api-key: $api_key" \
|
||||
-H "anthropic-version: 2023-06-01" \
|
||||
--data "$payload")
|
||||
|
||||
# Extract status code and body
|
||||
response_http_code=$(echo "$response_raw" | grep '^HTTP_STATUS_CODE:' | sed 's/HTTP_STATUS_CODE://')
|
||||
response_body=$(echo "$response_raw" | sed '$d') # Remove last line (status code)
|
||||
response_body=$(echo "$response_raw" | sed '$d')
|
||||
|
||||
if [ "$response_http_code" != "200" ]; then
|
||||
echo "[HELPER_ERROR] LLM API call failed with HTTP status $response_http_code." >&2
|
||||
@@ -146,17 +172,41 @@ EOF
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Pipe the raw response body directly to the Node.js parser script
|
||||
# Calculate cost of this LLM analysis call
|
||||
local input_tokens output_tokens input_cost_per_1m output_cost_per_1m calculated_llm_cost
|
||||
input_tokens=$(echo "$response_body" | jq -r '.usage.input_tokens // 0')
|
||||
output_tokens=$(echo "$response_body" | jq -r '.usage.output_tokens // 0')
|
||||
|
||||
if [ -f "$supported_models_file" ]; then
|
||||
model_cost_info=$(jq -r --arg provider "$llm_analysis_provider" --arg model_id "$llm_analysis_model_id" '
|
||||
.[$provider][] | select(.id == $model_id) | .cost_per_1m_tokens
|
||||
' "$supported_models_file")
|
||||
|
||||
if [[ -n "$model_cost_info" && "$model_cost_info" != "null" ]]; then
|
||||
input_cost_per_1m=$(echo "$model_cost_info" | jq -r '.input // 0')
|
||||
output_cost_per_1m=$(echo "$model_cost_info" | jq -r '.output // 0')
|
||||
|
||||
calculated_llm_cost=$(echo "($input_tokens / 1000000 * $input_cost_per_1m) + ($output_tokens / 1000000 * $output_cost_per_1m)" | bc -l)
|
||||
# Format to 6 decimal places
|
||||
formatted_llm_cost=$(printf "%.6f" "$calculated_llm_cost")
|
||||
echo "LLM Analysis AI Cost: $formatted_llm_cost USD" # This line will be parsed by run_e2e.sh
|
||||
else
|
||||
echo "[HELPER_WARNING] Cost data for model $llm_analysis_model_id not found in $supported_models_file. LLM analysis cost not calculated."
|
||||
fi
|
||||
else
|
||||
echo "[HELPER_WARNING] $supported_models_file not found. LLM analysis cost not calculated."
|
||||
fi
|
||||
# --- End cost calculation for this call ---
|
||||
|
||||
if echo "$response_body" | node "${project_root}/tests/e2e/parse_llm_output.cjs" "$log_file"; then
|
||||
echo "[HELPER_SUCCESS] LLM analysis parsed and printed successfully by Node.js script."
|
||||
return 0 # Success
|
||||
return 0
|
||||
else
|
||||
local node_exit_code=$?
|
||||
echo "[HELPER_ERROR] Node.js parsing script failed with exit code ${node_exit_code}."
|
||||
echo "[HELPER_ERROR] Raw API response body (first 500 chars): $(echo "$response_body" | head -c 500)"
|
||||
return 1 # Failure
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
# Export the function so it might be available to subshells if sourced
|
||||
export -f analyze_log_with_llm
|
||||
@@ -60,9 +60,52 @@ MAIN_ENV_FILE="$TASKMASTER_SOURCE_DIR/.env"
|
||||
# ---
|
||||
|
||||
# <<< Source the helper script >>>
|
||||
# shellcheck source=tests/e2e/e2e_helpers.sh
|
||||
source "$TASKMASTER_SOURCE_DIR/tests/e2e/e2e_helpers.sh"
|
||||
|
||||
# ==========================================
|
||||
# >>> Global Helper Functions Defined in run_e2e.sh <<<
|
||||
# --- Helper Functions (Define globally before export) ---
|
||||
_format_duration() {
|
||||
local total_seconds=$1
|
||||
local minutes=$((total_seconds / 60))
|
||||
local seconds=$((total_seconds % 60))
|
||||
printf "%dm%02ds" "$minutes" "$seconds"
|
||||
}
|
||||
|
||||
# Note: This relies on 'overall_start_time' being set globally before the function is called
|
||||
_get_elapsed_time_for_log() {
|
||||
local current_time
|
||||
current_time=$(date +%s)
|
||||
# Use overall_start_time here, as start_time_for_helpers might not be relevant globally
|
||||
local elapsed_seconds
|
||||
elapsed_seconds=$((current_time - overall_start_time))
|
||||
_format_duration "$elapsed_seconds"
|
||||
}
|
||||
|
||||
log_info() {
|
||||
echo "[INFO] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
}
|
||||
|
||||
log_success() {
|
||||
echo "[SUCCESS] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
}
|
||||
|
||||
log_error() {
|
||||
echo "[ERROR] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1" >&2
|
||||
}
|
||||
|
||||
log_step() {
|
||||
test_step_count=$((test_step_count + 1))
|
||||
echo ""
|
||||
echo "============================================="
|
||||
echo " STEP ${test_step_count}: [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
echo "============================================="
|
||||
}
|
||||
# ==========================================
|
||||
|
||||
# <<< Export helper functions for subshells >>>
|
||||
export -f log_info log_success log_error log_step _format_duration _get_elapsed_time_for_log
|
||||
export -f log_info log_success log_error log_step _format_duration _get_elapsed_time_for_log extract_and_sum_cost
|
||||
|
||||
# --- Argument Parsing for Analysis-Only Mode ---
|
||||
# This remains the same, as it exits early if matched
|
||||
@@ -138,6 +181,7 @@ fi
|
||||
# Note: These are mainly for step numbering within the log now, not for final summary
|
||||
test_step_count=0
|
||||
start_time_for_helpers=0 # Separate start time for helper functions inside the pipe
|
||||
total_e2e_cost="0.0" # Initialize total E2E cost
|
||||
# ---
|
||||
|
||||
# --- Log File Setup ---
|
||||
@@ -220,12 +264,16 @@ log_step() {
|
||||
fi
|
||||
|
||||
# --- Dependency Checks ---
|
||||
log_step "Checking for dependencies (jq)"
|
||||
log_step "Checking for dependencies (jq, bc)"
|
||||
if ! command -v jq &> /dev/null; then
|
||||
log_error "Dependency 'jq' is not installed or not found in PATH. Please install jq (e.g., 'brew install jq' or 'sudo apt-get install jq')."
|
||||
exit 1
|
||||
fi
|
||||
log_success "Dependency 'jq' found."
|
||||
if ! command -v bc &> /dev/null; then
|
||||
log_error "Dependency 'bc' not installed (for cost calculation). Please install bc (e.g., 'brew install bc' or 'sudo apt-get install bc')."
|
||||
exit 1
|
||||
fi
|
||||
log_success "Dependencies 'jq' and 'bc' found."
|
||||
|
||||
# --- Test Setup (Output to tee) ---
|
||||
log_step "Setting up test environment"
|
||||
@@ -292,30 +340,43 @@ log_step() {
|
||||
log_success "Project initialized."
|
||||
|
||||
log_step "Parsing PRD"
|
||||
task-master parse-prd ./prd.txt --force
|
||||
if [ ! -s "tasks/tasks.json" ]; then
|
||||
log_error "Parsing PRD failed: tasks/tasks.json not found or is empty."
|
||||
cmd_output_prd=$(task-master parse-prd ./prd.txt --force 2>&1)
|
||||
exit_status_prd=$?
|
||||
echo "$cmd_output_prd"
|
||||
extract_and_sum_cost "$cmd_output_prd"
|
||||
if [ $exit_status_prd -ne 0 ] || [ ! -s "tasks/tasks.json" ]; then
|
||||
log_error "Parsing PRD failed: tasks/tasks.json not found or is empty. Exit status: $exit_status_prd"
|
||||
exit 1
|
||||
else
|
||||
log_success "PRD parsed successfully."
|
||||
fi
|
||||
log_success "PRD parsed successfully."
|
||||
|
||||
log_step "Expanding Task 1 (to ensure subtask 1.1 exists)"
|
||||
# Add --research flag if needed and API keys support it
|
||||
task-master analyze-complexity --research --output complexity_results.json
|
||||
if [ ! -f "complexity_results.json" ]; then
|
||||
log_error "Complexity analysis failed: complexity_results.json not found."
|
||||
cmd_output_analyze=$(task-master analyze-complexity --research --output complexity_results.json 2>&1)
|
||||
exit_status_analyze=$?
|
||||
echo "$cmd_output_analyze"
|
||||
extract_and_sum_cost "$cmd_output_analyze"
|
||||
if [ $exit_status_analyze -ne 0 ] || [ ! -f "complexity_results.json" ]; then
|
||||
log_error "Complexity analysis failed: complexity_results.json not found. Exit status: $exit_status_analyze"
|
||||
exit 1
|
||||
else
|
||||
log_success "Complexity analysis saved to complexity_results.json"
|
||||
fi
|
||||
log_success "Complexity analysis saved to complexity_results.json"
|
||||
|
||||
log_step "Generating complexity report"
|
||||
task-master complexity-report --file complexity_results.json > complexity_report_formatted.log
|
||||
log_success "Formatted complexity report saved to complexity_report_formatted.log"
|
||||
|
||||
log_step "Expanding Task 1 (assuming it exists)"
|
||||
# Add --research flag if needed and API keys support it
|
||||
task-master expand --id=1 # Add --research?
|
||||
log_success "Attempted to expand Task 1."
|
||||
cmd_output_expand1=$(task-master expand --id=1 2>&1)
|
||||
exit_status_expand1=$?
|
||||
echo "$cmd_output_expand1"
|
||||
extract_and_sum_cost "$cmd_output_expand1"
|
||||
if [ $exit_status_expand1 -ne 0 ]; then
|
||||
log_error "Expanding Task 1 failed. Exit status: $exit_status_expand1"
|
||||
else
|
||||
log_success "Attempted to expand Task 1."
|
||||
fi
|
||||
|
||||
log_step "Setting status for Subtask 1.1 (assuming it exists)"
|
||||
task-master set-status --id=1.1 --status=done
|
||||
@@ -359,10 +420,11 @@ log_step() {
|
||||
|
||||
if [ -x "$verification_script_path" ]; then
|
||||
log_info "--- Executing Fallback Verification Script: $verification_script_path ---"
|
||||
# Execute the script directly, allowing output to flow to tee
|
||||
# Pass the current directory (the test run dir) as the argument
|
||||
"$verification_script_path" "$(pwd)"
|
||||
verification_exit_code=$? # Capture exit code immediately
|
||||
verification_output=$("$verification_script_path" "$(pwd)" 2>&1)
|
||||
verification_exit_code=$?
|
||||
echo "$verification_output"
|
||||
extract_and_sum_cost "$verification_output"
|
||||
|
||||
log_info "--- Finished Fallback Verification Script Execution (Exit Code: $verification_exit_code) ---"
|
||||
|
||||
# Log success/failure based on captured exit code
|
||||
@@ -370,13 +432,9 @@ log_step() {
|
||||
log_success "Fallback verification script reported success."
|
||||
else
|
||||
log_error "Fallback verification script reported FAILURE (Exit Code: $verification_exit_code)."
|
||||
# Decide whether to exit the main script or just log the error
|
||||
# exit 1 # Uncomment to make verification failure fatal
|
||||
fi
|
||||
else
|
||||
log_error "Fallback verification script not found or not executable at $verification_script_path. Skipping verification."
|
||||
# Decide whether to exit or continue
|
||||
# exit 1
|
||||
fi
|
||||
else
|
||||
log_info "Skipping Fallback Verification test as requested by flag."
|
||||
@@ -393,7 +451,7 @@ log_step() {
|
||||
declare -a models=(
|
||||
"claude-3-7-sonnet-20250219"
|
||||
"gpt-4o"
|
||||
"gemini-2.5-pro-exp-03-25"
|
||||
"gemini-2.5-pro-preview-05-06"
|
||||
"sonar-pro" # Note: This is research-only, add-task might fail if not using research model
|
||||
"grok-3"
|
||||
"anthropic/claude-3.7-sonnet" # OpenRouter uses Claude 3.7
|
||||
@@ -435,9 +493,9 @@ log_step() {
|
||||
|
||||
# 3. Check for success and extract task ID
|
||||
new_task_id=""
|
||||
if [ $add_task_exit_code -eq 0 ] && echo "$add_task_cmd_output" | grep -q "✓ Added new task #"; then
|
||||
# Attempt to extract the ID (adjust grep/sed/awk as needed based on actual output format)
|
||||
new_task_id=$(echo "$add_task_cmd_output" | grep "✓ Added new task #" | sed 's/.*✓ Added new task #\([0-9.]\+\).*/\1/')
|
||||
extract_and_sum_cost "$add_task_cmd_output"
|
||||
if [ $add_task_exit_code -eq 0 ] && (echo "$add_task_cmd_output" | grep -q "✓ Added new task #" || echo "$add_task_cmd_output" | grep -q "✅ New task created successfully:" || echo "$add_task_cmd_output" | grep -q "Task [0-9]\+ Created Successfully"); then
|
||||
new_task_id=$(echo "$add_task_cmd_output" | grep -o -E "(Task |#)[0-9.]+" | grep -o -E "[0-9.]+" | head -n 1)
|
||||
if [ -n "$new_task_id" ]; then
|
||||
log_success "Add-task succeeded for $provider. New task ID: $new_task_id"
|
||||
echo "Provider $provider add-task SUCCESS (ID: $new_task_id)" >> provider_add_task_summary.log
|
||||
@@ -522,8 +580,6 @@ log_step() {
|
||||
log_success "Validation correctly identified non-existent dependency 999."
|
||||
else
|
||||
log_error "Validation DID NOT report non-existent dependency 999 as expected. Check validate_deps_non_existent.log"
|
||||
# Consider exiting here if this check fails, as it indicates a validation logic problem
|
||||
# exit 1
|
||||
fi
|
||||
|
||||
log_step "Fixing dependencies (should remove 1 -> 999)"
|
||||
@@ -534,7 +590,6 @@ log_step() {
|
||||
task-master validate-dependencies > validate_deps_after_fix_non_existent.log 2>&1 || true # Allow potential failure
|
||||
if grep -q "Non-existent dependency ID: 999" validate_deps_after_fix_non_existent.log; then
|
||||
log_error "Validation STILL reports non-existent dependency 999 after fix. Check logs."
|
||||
# exit 1
|
||||
else
|
||||
log_success "Validation shows non-existent dependency 999 was removed."
|
||||
fi
|
||||
@@ -553,7 +608,6 @@ log_step() {
|
||||
log_success "Validation correctly identified circular dependency between 4 and 5."
|
||||
else
|
||||
log_error "Validation DID NOT report circular dependency 4<->5 as expected. Check validate_deps_circular.log"
|
||||
# exit 1
|
||||
fi
|
||||
|
||||
log_step "Fixing dependencies (should remove one side of 4 <-> 5)"
|
||||
@@ -564,7 +618,6 @@ log_step() {
|
||||
task-master validate-dependencies > validate_deps_after_fix_circular.log 2>&1 || true # Allow potential failure
|
||||
if grep -q -E "Circular dependency detected involving task IDs: (4, 5|5, 4)" validate_deps_after_fix_circular.log; then
|
||||
log_error "Validation STILL reports circular dependency 4<->5 after fix. Check logs."
|
||||
# exit 1
|
||||
else
|
||||
log_success "Validation shows circular dependency 4<->5 was resolved."
|
||||
fi
|
||||
@@ -582,25 +635,60 @@ log_step() {
|
||||
log_success "Added Task $manual_task_id manually."
|
||||
|
||||
log_step "Adding Task $ai_task_id (AI)"
|
||||
task-master add-task --prompt="Implement basic UI styling using CSS variables for colors and spacing" --priority=medium --dependencies=1 # Depends on frontend setup
|
||||
log_success "Added Task $ai_task_id via AI prompt."
|
||||
cmd_output_add_ai=$(task-master add-task --prompt="Implement basic UI styling using CSS variables for colors and spacing" --priority=medium --dependencies=1 2>&1)
|
||||
exit_status_add_ai=$?
|
||||
echo "$cmd_output_add_ai"
|
||||
extract_and_sum_cost "$cmd_output_add_ai"
|
||||
if [ $exit_status_add_ai -ne 0 ]; then
|
||||
log_error "Adding AI Task $ai_task_id failed. Exit status: $exit_status_add_ai"
|
||||
else
|
||||
log_success "Added Task $ai_task_id via AI prompt."
|
||||
fi
|
||||
|
||||
|
||||
log_step "Updating Task 3 (update-task AI)"
|
||||
task-master update-task --id=3 --prompt="Update backend server setup: Ensure CORS is configured to allow requests from the frontend origin."
|
||||
log_success "Attempted update for Task 3."
|
||||
cmd_output_update_task3=$(task-master update-task --id=3 --prompt="Update backend server setup: Ensure CORS is configured to allow requests from the frontend origin." 2>&1)
|
||||
exit_status_update_task3=$?
|
||||
echo "$cmd_output_update_task3"
|
||||
extract_and_sum_cost "$cmd_output_update_task3"
|
||||
if [ $exit_status_update_task3 -ne 0 ]; then
|
||||
log_error "Updating Task 3 failed. Exit status: $exit_status_update_task3"
|
||||
else
|
||||
log_success "Attempted update for Task 3."
|
||||
fi
|
||||
|
||||
log_step "Updating Tasks from Task 5 (update AI)"
|
||||
task-master update --from=5 --prompt="Refactor the backend storage module to use a simple JSON file (storage.json) instead of an in-memory object for persistence. Update relevant tasks."
|
||||
log_success "Attempted update from Task 5 onwards."
|
||||
cmd_output_update_from5=$(task-master update --from=5 --prompt="Refactor the backend storage module to use a simple JSON file (storage.json) instead of an in-memory object for persistence. Update relevant tasks." 2>&1)
|
||||
exit_status_update_from5=$?
|
||||
echo "$cmd_output_update_from5"
|
||||
extract_and_sum_cost "$cmd_output_update_from5"
|
||||
if [ $exit_status_update_from5 -ne 0 ]; then
|
||||
log_error "Updating from Task 5 failed. Exit status: $exit_status_update_from5"
|
||||
else
|
||||
log_success "Attempted update from Task 5 onwards."
|
||||
fi
|
||||
|
||||
log_step "Expanding Task 8 (AI)"
|
||||
task-master expand --id=8 # Expand task 8: Frontend logic
|
||||
log_success "Attempted to expand Task 8."
|
||||
cmd_output_expand8=$(task-master expand --id=8 2>&1)
|
||||
exit_status_expand8=$?
|
||||
echo "$cmd_output_expand8"
|
||||
extract_and_sum_cost "$cmd_output_expand8"
|
||||
if [ $exit_status_expand8 -ne 0 ]; then
|
||||
log_error "Expanding Task 8 failed. Exit status: $exit_status_expand8"
|
||||
else
|
||||
log_success "Attempted to expand Task 8."
|
||||
fi
|
||||
|
||||
log_step "Updating Subtask 8.1 (update-subtask AI)"
|
||||
task-master update-subtask --id=8.1 --prompt="Implementation note: Remember to handle potential API errors and display a user-friendly message."
|
||||
log_success "Attempted update for Subtask 8.1."
|
||||
cmd_output_update_subtask81=$(task-master update-subtask --id=8.1 --prompt="Implementation note: Remember to handle potential API errors and display a user-friendly message." 2>&1)
|
||||
exit_status_update_subtask81=$?
|
||||
echo "$cmd_output_update_subtask81"
|
||||
extract_and_sum_cost "$cmd_output_update_subtask81"
|
||||
if [ $exit_status_update_subtask81 -ne 0 ]; then
|
||||
log_error "Updating Subtask 8.1 failed. Exit status: $exit_status_update_subtask81"
|
||||
else
|
||||
log_success "Attempted update for Subtask 8.1."
|
||||
fi
|
||||
|
||||
# Add a couple more subtasks for multi-remove test
|
||||
log_step 'Adding subtasks to Task 2 (for multi-remove test)'
|
||||
@@ -693,9 +781,16 @@ log_step() {
|
||||
|
||||
# === AI Commands (Re-test some after changes) ===
|
||||
log_step "Analyzing complexity (AI with Research - Final Check)"
|
||||
task-master analyze-complexity --research --output complexity_results_final.json
|
||||
if [ ! -f "complexity_results_final.json" ]; then log_error "Final Complexity analysis failed."; exit 1; fi
|
||||
log_success "Final Complexity analysis saved."
|
||||
cmd_output_analyze_final=$(task-master analyze-complexity --research --output complexity_results_final.json 2>&1)
|
||||
exit_status_analyze_final=$?
|
||||
echo "$cmd_output_analyze_final"
|
||||
extract_and_sum_cost "$cmd_output_analyze_final"
|
||||
if [ $exit_status_analyze_final -ne 0 ] || [ ! -f "complexity_results_final.json" ]; then
|
||||
log_error "Final Complexity analysis failed. Exit status: $exit_status_analyze_final. File found: $(test -f complexity_results_final.json && echo true || echo false)"
|
||||
exit 1 # Critical for subsequent report step
|
||||
else
|
||||
log_success "Final Complexity analysis command executed and file created."
|
||||
fi
|
||||
|
||||
log_step "Generating complexity report (Non-AI - Final Check)"
|
||||
task-master complexity-report --file complexity_results_final.json > complexity_report_formatted_final.log
|
||||
@@ -775,4 +870,8 @@ else
|
||||
echo "[ERROR] [$formatted_duration_for_error] $(date +"%Y-%m-%d %H:%M:%S") Test run directory $TEST_RUN_DIR not found. Cannot perform LLM analysis." >&2
|
||||
fi
|
||||
|
||||
# Final cost formatting
|
||||
formatted_total_e2e_cost=$(printf "%.6f" "$total_e2e_cost")
|
||||
echo "Total E2E AI Cost: $formatted_total_e2e_cost USD"
|
||||
|
||||
exit $EXIT_CODE
|
||||
@@ -18,6 +18,25 @@ set -o pipefail
|
||||
|
||||
# --- Embedded Helper Functions ---
|
||||
# Copied from e2e_helpers.sh to make this script standalone
|
||||
# OR source it if preferred and path is reliable
|
||||
|
||||
# <<< Determine SCRIPT_DIR and PROJECT_ROOT_DIR early >>>
|
||||
SCRIPT_DIR_FV="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
|
||||
PROJECT_ROOT_DIR_FV="$( cd "$SCRIPT_DIR_FV/../.." &> /dev/null && pwd )" # Assumes script is in tests/e2e/
|
||||
|
||||
# --- Try to Source e2e_helpers.sh ---
|
||||
E2E_HELPERS_PATH_FV="${PROJECT_ROOT_DIR_FV}/tests/e2e/e2e_helpers.sh"
|
||||
if [ -f "$E2E_HELPERS_PATH_FV" ]; then
|
||||
# shellcheck source=tests/e2e/e2e_helpers.sh
|
||||
source "$E2E_HELPERS_PATH_FV"
|
||||
echo "[INFO FV] Sourced e2e_helpers.sh successfully."
|
||||
else
|
||||
echo "[ERROR FV] e2e_helpers.sh not found at $E2E_HELPERS_PATH_FV. Cost extraction will fail."
|
||||
# Define a placeholder if not found, so the script doesn't break immediately,
|
||||
# but cost extraction will effectively be a no-op.
|
||||
extract_and_sum_cost() { echo "$2"; } # Returns current total, effectively adding 0
|
||||
fi
|
||||
|
||||
|
||||
_format_duration() {
|
||||
local total_seconds=$1
|
||||
@@ -27,127 +46,112 @@ _format_duration() {
|
||||
}
|
||||
|
||||
_get_elapsed_time_for_log() {
|
||||
# Needs overall_start_time defined in the main script body
|
||||
local current_time=$(date +%s)
|
||||
local elapsed_seconds=$((current_time - overall_start_time))
|
||||
local current_time
|
||||
current_time=$(date +%s)
|
||||
local elapsed_seconds
|
||||
elapsed_seconds=$((current_time - overall_start_time)) # Needs overall_start_time
|
||||
_format_duration "$elapsed_seconds"
|
||||
}
|
||||
|
||||
log_info() {
|
||||
echo "[INFO] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
echo "[INFO FV] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
}
|
||||
|
||||
log_success() {
|
||||
echo "[SUCCESS] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
echo "[SUCCESS FV] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
}
|
||||
|
||||
log_error() {
|
||||
echo "[ERROR] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1" >&2
|
||||
echo "[ERROR FV] [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1" >&2
|
||||
}
|
||||
|
||||
log_step() {
|
||||
# Needs test_step_count defined and incremented in the main script body
|
||||
test_step_count=$((test_step_count + 1))
|
||||
test_step_count=$((test_step_count + 1)) # Needs test_step_count
|
||||
echo ""
|
||||
echo "============================================="
|
||||
echo " STEP ${test_step_count}: [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
echo " FV STEP ${test_step_count}: [$(_get_elapsed_time_for_log)] $(date +"%Y-%m-%d %H:%M:%S") $1"
|
||||
echo "============================================="
|
||||
}
|
||||
|
||||
# --- Signal Handling ---
|
||||
# Global variable to hold child PID
|
||||
child_pid=0
|
||||
# Use a persistent log file name
|
||||
PROGRESS_LOG_FILE="fallback_verification_progress.log"
|
||||
PROGRESS_LOG_FILE="fallback_verification_progress.log" # Stays in run dir
|
||||
|
||||
cleanup() {
|
||||
echo "" # Newline after ^C
|
||||
echo ""
|
||||
log_error "Interrupt received. Cleaning up any running child process..."
|
||||
if [ "$child_pid" -ne 0 ]; then
|
||||
log_info "Killing child process (PID: $child_pid) and its group..."
|
||||
kill -TERM -- "-$child_pid" 2>/dev/null || kill -KILL -- "-$child_pid" 2>/dev/null
|
||||
child_pid=0
|
||||
fi
|
||||
# DO NOT delete the progress log file on interrupt
|
||||
log_info "Progress saved in: $PROGRESS_LOG_FILE"
|
||||
exit 130 # Exit with code indicating interrupt
|
||||
# Print current total cost on interrupt
|
||||
if [[ -n "${total_fallback_cost+x}" && "$total_fallback_cost" != "0.0" ]]; then # Check if var is set and not initial
|
||||
log_info "Current Total Fallback AI Cost at interruption: $total_fallback_cost USD"
|
||||
fi
|
||||
exit 130
|
||||
}
|
||||
|
||||
# Trap SIGINT (Ctrl+C) and SIGTERM
|
||||
trap cleanup INT TERM
|
||||
|
||||
# --- Configuration ---
|
||||
# Determine the project root relative to this script's location
|
||||
# Use a robust method to find the script's own directory
|
||||
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
|
||||
# Assumes this script is in tests/e2e/
|
||||
PROJECT_ROOT_DIR="$( cd "$SCRIPT_DIR/../.." &> /dev/null && pwd )"
|
||||
SUPPORTED_MODELS_FILE="$PROJECT_ROOT_DIR/scripts/modules/supported-models.json"
|
||||
BASE_RUNS_DIR="$PROJECT_ROOT_DIR/tests/e2e/_runs"
|
||||
# SCRIPT_DIR and PROJECT_ROOT_DIR already defined above
|
||||
SUPPORTED_MODELS_FILE="$PROJECT_ROOT_DIR_FV/scripts/modules/supported-models.json"
|
||||
BASE_RUNS_DIR="$PROJECT_ROOT_DIR_FV/tests/e2e/_runs"
|
||||
|
||||
# --- Determine Target Run Directory ---
|
||||
TARGET_RUN_DIR=""
|
||||
if [ "$#" -ge 1 ] && [ -n "$1" ]; then
|
||||
# Use provided argument if it exists
|
||||
TARGET_RUN_DIR="$1"
|
||||
# Make path absolute if it's relative
|
||||
if [[ "$TARGET_RUN_DIR" != /* ]]; then
|
||||
TARGET_RUN_DIR="$(pwd)/$TARGET_RUN_DIR"
|
||||
fi
|
||||
echo "[INFO] Using provided target run directory: $TARGET_RUN_DIR"
|
||||
echo "[INFO FV] Using provided target run directory: $TARGET_RUN_DIR"
|
||||
else
|
||||
# Find the latest run directory
|
||||
echo "[INFO] No run directory provided, finding latest in $BASE_RUNS_DIR..."
|
||||
echo "[INFO FV] No run directory provided, finding latest in $BASE_RUNS_DIR..."
|
||||
TARGET_RUN_DIR=$(ls -td "$BASE_RUNS_DIR"/run_* 2>/dev/null | head -n 1)
|
||||
if [ -z "$TARGET_RUN_DIR" ]; then
|
||||
echo "[ERROR] No run directories found matching 'run_*' in $BASE_RUNS_DIR. Cannot proceed." >&2
|
||||
echo "[ERROR FV] No run directories found matching 'run_*' in $BASE_RUNS_DIR. Cannot proceed." >&2
|
||||
exit 1
|
||||
fi
|
||||
echo "[INFO] Found latest run directory: $TARGET_RUN_DIR"
|
||||
echo "[INFO FV] Found latest run directory: $TARGET_RUN_DIR"
|
||||
fi
|
||||
|
||||
# Validate the target directory
|
||||
if [ ! -d "$TARGET_RUN_DIR" ]; then
|
||||
echo "[ERROR] Target run directory not found or is not a directory: $TARGET_RUN_DIR" >&2
|
||||
echo "[ERROR FV] Target run directory not found or is not a directory: $TARGET_RUN_DIR" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# --- Change to Target Directory ---
|
||||
echo "[INFO] Changing working directory to: $TARGET_RUN_DIR"
|
||||
echo "[INFO FV] Changing working directory to: $TARGET_RUN_DIR"
|
||||
if ! cd "$TARGET_RUN_DIR"; then
|
||||
echo "[ERROR] Failed to cd into target directory: $TARGET_RUN_DIR" >&2
|
||||
echo "[ERROR FV] Failed to cd into target directory: $TARGET_RUN_DIR" >&2
|
||||
exit 1
|
||||
fi
|
||||
echo "[INFO] Now operating inside: $(pwd)"
|
||||
echo "[INFO FV] Now operating inside: $(pwd)"
|
||||
|
||||
overall_start_time=$(date +%s) # Initialize for logging helpers
|
||||
test_step_count=0 # Initialize for logging helpers
|
||||
total_fallback_cost="0.0" # Initialize total cost for this script
|
||||
|
||||
# --- Now we are inside the target run directory ---
|
||||
overall_start_time=$(date +%s)
|
||||
test_step_count=0
|
||||
log_info "Starting fallback verification script execution in $(pwd)"
|
||||
log_info "Progress will be logged to: $(pwd)/$PROGRESS_LOG_FILE"
|
||||
|
||||
# --- Dependency Checks ---
|
||||
log_step "Checking for dependencies (jq) in verification script"
|
||||
if ! command -v jq &> /dev/null; then
|
||||
log_error "Dependency 'jq' is not installed or not found in PATH."
|
||||
exit 1
|
||||
fi
|
||||
log_success "Dependency 'jq' found."
|
||||
log_step "Checking for dependencies (jq, bc) in verification script"
|
||||
if ! command -v jq &> /dev/null; then log_error "Dependency 'jq' not installed."; exit 1; fi
|
||||
if ! command -v bc &> /dev/null; then log_error "Dependency 'bc' not installed (for cost calculation)."; exit 1; fi
|
||||
log_success "Dependencies 'jq' and 'bc' found."
|
||||
|
||||
|
||||
# --- Verification Logic ---
|
||||
log_step "Starting/Resuming Fallback Model (generateObjectService) Verification"
|
||||
# Ensure progress log exists, create if not
|
||||
touch "$PROGRESS_LOG_FILE"
|
||||
|
||||
# Ensure the supported models file exists (using absolute path)
|
||||
if [ ! -f "$SUPPORTED_MODELS_FILE" ]; then
|
||||
log_error "supported-models.json not found at absolute path: $SUPPORTED_MODELS_FILE."
|
||||
log_error "supported-models.json not found at: $SUPPORTED_MODELS_FILE."
|
||||
exit 1
|
||||
fi
|
||||
log_info "Using supported models file: $SUPPORTED_MODELS_FILE"
|
||||
|
||||
# Ensure subtask 1.1 exists (basic check, main script should guarantee)
|
||||
# Check for tasks.json in the current directory (which is now the run dir)
|
||||
if [ ! -f "tasks/tasks.json" ]; then
|
||||
log_error "tasks/tasks.json not found in current directory ($(pwd)). Was this run directory properly initialized?"
|
||||
exit 1
|
||||
@@ -158,78 +162,90 @@ if ! jq -e '.tasks[] | select(.id == 1) | .subtasks[] | select(.id == 1)' tasks/
|
||||
fi
|
||||
log_info "Subtask 1.1 found in $(pwd)/tasks/tasks.json, proceeding with verification."
|
||||
|
||||
# Read providers and models using jq
|
||||
jq -c 'to_entries[] | .key as $provider | .value[] | select(.allowed_roles[]? == "fallback") | {provider: $provider, id: .id}' "$SUPPORTED_MODELS_FILE" | while IFS= read -r model_info; do
|
||||
provider=$(echo "$model_info" | jq -r '.provider')
|
||||
model_id=$(echo "$model_info" | jq -r '.id')
|
||||
flag="" # Default flag
|
||||
flag=""
|
||||
|
||||
# Check if already tested
|
||||
# Use grep -Fq for fixed string and quiet mode
|
||||
if grep -Fq "${provider},${model_id}," "$PROGRESS_LOG_FILE"; then
|
||||
log_info "--- Skipping: $provider / $model_id (already tested, result in $PROGRESS_LOG_FILE) ---"
|
||||
# Still need to sum up its cost if it was successful before
|
||||
previous_test_output=$(grep -F "${provider},${model_id}," "$PROGRESS_LOG_FILE" | head -n 1)
|
||||
# Assuming the output file for successful test exists and contains cost
|
||||
prev_output_file="update_subtask_raw_output_${provider}_${model_id//\//_}.log"
|
||||
if [[ "$previous_test_output" == *",SUCCESS"* && -f "$prev_output_file" ]]; then
|
||||
# shellcheck disable=SC2154 # overall_start_time is set
|
||||
log_info "Summing cost from previous successful test of $provider / $model_id from $prev_output_file"
|
||||
# shellcheck disable=SC2154 # total_fallback_cost is set
|
||||
total_fallback_cost=$(extract_and_sum_cost "$(cat "$prev_output_file")" "$total_fallback_cost")
|
||||
log_info "Cumulative fallback AI cost after previous $provider / $model_id: $total_fallback_cost USD"
|
||||
fi
|
||||
continue
|
||||
fi
|
||||
|
||||
log_info "--- Verifying: $provider / $model_id ---"
|
||||
|
||||
# Determine provider flag
|
||||
if [ "$provider" == "openrouter" ]; then
|
||||
flag="--openrouter"
|
||||
elif [ "$provider" == "ollama" ]; then
|
||||
flag="--ollama"
|
||||
fi
|
||||
if [ "$provider" == "openrouter" ]; then flag="--openrouter"; fi
|
||||
if [ "$provider" == "ollama" ]; then flag="--ollama"; fi
|
||||
|
||||
# 1. Set the main model
|
||||
if ! command -v task-master &> /dev/null; then
|
||||
log_error "task-master command not found."
|
||||
echo "[INSTRUCTION] Please run 'npm link task-master-ai' in the project root first."
|
||||
echo "[INSTRUCTION FV] Please run 'npm link task-master-ai' in the project root first."
|
||||
exit 1
|
||||
fi
|
||||
log_info "Setting main model to $model_id ${flag:+using flag $flag}..."
|
||||
set_model_cmd="task-master models --set-main \"$model_id\" $flag"
|
||||
model_set_status="SUCCESS"
|
||||
if ! eval $set_model_cmd > /dev/null 2>&1; then
|
||||
if ! eval "$set_model_cmd" > /dev/null 2>&1; then
|
||||
log_error "Failed to set main model for $provider / $model_id. Skipping test."
|
||||
echo "$provider,$model_id,SET_MODEL_FAILED" >> "$PROGRESS_LOG_FILE"
|
||||
continue # Skip the actual test if setting fails
|
||||
continue
|
||||
fi
|
||||
log_info "Set main model ok."
|
||||
|
||||
# 2. Run update-subtask
|
||||
log_info "Running update-subtask --id=1.1 --prompt='Test generateObjectService' (timeout 120s)"
|
||||
update_subtask_output_file="update_subtask_raw_output_${provider}_${model_id//\//_}.log"
|
||||
|
||||
timeout 120s task-master update-subtask --id=1.1 --prompt="Simple test prompt to verify generateObjectService call." > "$update_subtask_output_file" 2>&1 &
|
||||
|
||||
# Capture output to a variable AND a file
|
||||
update_subtask_command_output=""
|
||||
timeout 120s task-master update-subtask --id=1.1 --prompt="Simple test prompt to verify generateObjectService call." 2>&1 | tee "$update_subtask_output_file" &
|
||||
# Store the command output in a variable simultaneously
|
||||
# update_subtask_command_output=$(timeout 120s task-master update-subtask --id=1.1 --prompt="Simple test prompt to verify generateObjectService call." 2>&1)
|
||||
# The above direct capture won't work well with tee and backgrounding. Instead, read the file after command completion.
|
||||
child_pid=$!
|
||||
wait "$child_pid"
|
||||
update_subtask_exit_code=$?
|
||||
child_pid=0
|
||||
|
||||
# 3. Check result and log persistently
|
||||
# Read output from file for cost extraction
|
||||
if [ -f "$update_subtask_output_file" ]; then
|
||||
update_subtask_command_output=$(cat "$update_subtask_output_file")
|
||||
else
|
||||
update_subtask_command_output="" # Ensure it's defined
|
||||
fi
|
||||
|
||||
result_status=""
|
||||
if [ $update_subtask_exit_code -eq 0 ] && grep -q "Successfully updated subtask #1.1" "$update_subtask_output_file"; then
|
||||
if [ $update_subtask_exit_code -eq 0 ] && echo "$update_subtask_command_output" | grep -q "Successfully updated subtask #1.1"; then
|
||||
log_success "update-subtask succeeded for $provider / $model_id (Verified Output)."
|
||||
result_status="SUCCESS"
|
||||
# Extract and sum cost if successful
|
||||
# shellcheck disable=SC2154 # total_fallback_cost is set
|
||||
total_fallback_cost=$(extract_and_sum_cost "$update_subtask_command_output" "$total_fallback_cost")
|
||||
log_info "Cumulative fallback AI cost after $provider / $model_id: $total_fallback_cost USD"
|
||||
elif [ $update_subtask_exit_code -eq 124 ]; then
|
||||
log_error "update-subtask TIMED OUT for $provider / $model_id. Check $update_subtask_output_file."
|
||||
result_status="FAILED_TIMEOUT"
|
||||
elif [ $update_subtask_exit_code -eq 130 ] || [ $update_subtask_exit_code -eq 143 ]; then
|
||||
log_error "update-subtask INTERRUPTED for $provider / $model_id."
|
||||
result_status="INTERRUPTED" # Record interruption
|
||||
# Don't exit the loop, allow script to finish or be interrupted again
|
||||
result_status="INTERRUPTED"
|
||||
else
|
||||
log_error "update-subtask FAILED for $provider / $model_id (Exit Code: $update_subtask_exit_code). Check $update_subtask_output_file."
|
||||
result_status="FAILED"
|
||||
fi
|
||||
|
||||
# Append result to the persistent log file
|
||||
echo "$provider,$model_id,$result_status" >> "$PROGRESS_LOG_FILE"
|
||||
|
||||
done # End of fallback verification loop
|
||||
done
|
||||
|
||||
# --- Generate Final Verification Report to STDOUT ---
|
||||
# Report reads from the persistent PROGRESS_LOG_FILE
|
||||
echo ""
|
||||
echo "--- Fallback Model Verification Report (via $0) ---"
|
||||
echo "Executed inside run directory: $(pwd)"
|
||||
@@ -254,17 +270,13 @@ echo ""
|
||||
echo "Models INTERRUPTED during test (Inconclusive - Rerun):"
|
||||
awk -F',' '$3 == "INTERRUPTED" { print "- " $1 " / " $2 }' "$PROGRESS_LOG_FILE" | sort
|
||||
echo ""
|
||||
# Print the total cost for this script's operations
|
||||
formatted_total_fallback_cost=$(printf "%.6f" "$total_fallback_cost")
|
||||
echo "Total Fallback AI Cost (this script run): $formatted_total_fallback_cost USD" # This line will be parsed
|
||||
echo "-------------------------------------------------------"
|
||||
echo ""
|
||||
|
||||
# Don't clean up the progress log
|
||||
# if [ -f "$PROGRESS_LOG_FILE" ]; then
|
||||
# rm "$PROGRESS_LOG_FILE"
|
||||
# fi
|
||||
|
||||
log_info "Finished Fallback Model (generateObjectService) Verification Script"
|
||||
|
||||
# Remove trap before exiting normally
|
||||
trap - INT TERM
|
||||
|
||||
exit 0 # Exit successfully after printing the report
|
||||
exit 0
|
||||
|
||||
@@ -3,9 +3,8 @@
|
||||
*/
|
||||
|
||||
import { jest } from '@jest/globals';
|
||||
import path from 'path';
|
||||
import path, { dirname } from 'path';
|
||||
import { fileURLToPath } from 'url';
|
||||
import { dirname } from 'path';
|
||||
|
||||
// Get the current module's directory
|
||||
const __filename = fileURLToPath(import.meta.url);
|
||||
@@ -27,6 +26,7 @@ const mockReadJSON = jest.fn();
|
||||
const mockWriteJSON = jest.fn();
|
||||
const mockEnableSilentMode = jest.fn();
|
||||
const mockDisableSilentMode = jest.fn();
|
||||
const mockReadComplexityReport = jest.fn().mockReturnValue(null);
|
||||
|
||||
const mockGetAnthropicClient = jest.fn().mockReturnValue({});
|
||||
const mockGetConfiguredAnthropicClient = jest.fn().mockReturnValue({});
|
||||
@@ -130,6 +130,7 @@ jest.mock('../../../scripts/modules/utils.js', () => ({
|
||||
writeJSON: mockWriteJSON,
|
||||
enableSilentMode: mockEnableSilentMode,
|
||||
disableSilentMode: mockDisableSilentMode,
|
||||
readComplexityReport: mockReadComplexityReport,
|
||||
CONFIG: {
|
||||
model: 'claude-3-7-sonnet-20250219',
|
||||
maxTokens: 64000,
|
||||
@@ -160,15 +161,6 @@ jest.mock('../../../scripts/modules/task-manager.js', () => ({
|
||||
}));
|
||||
|
||||
// Import dependencies after mocks are set up
|
||||
import fs from 'fs';
|
||||
import {
|
||||
readJSON,
|
||||
writeJSON,
|
||||
enableSilentMode,
|
||||
disableSilentMode
|
||||
} from '../../../scripts/modules/utils.js';
|
||||
import { expandTask } from '../../../scripts/modules/task-manager.js';
|
||||
import { findTasksJsonPath } from '../../../mcp-server/src/core/utils/path-utils.js';
|
||||
import { sampleTasks } from '../../fixtures/sample-tasks.js';
|
||||
|
||||
// Mock logger
|
||||
@@ -220,6 +212,37 @@ describe('MCP Server Direct Functions', () => {
|
||||
});
|
||||
|
||||
describe('listTasksDirect', () => {
|
||||
// Sample complexity report for testing
|
||||
const mockComplexityReport = {
|
||||
meta: {
|
||||
generatedAt: '2025-03-24T20:01:35.986Z',
|
||||
tasksAnalyzed: 3,
|
||||
thresholdScore: 5,
|
||||
projectName: 'Test Project',
|
||||
usedResearch: false
|
||||
},
|
||||
complexityAnalysis: [
|
||||
{
|
||||
taskId: 1,
|
||||
taskTitle: 'Initialize Project',
|
||||
complexityScore: 3,
|
||||
recommendedSubtasks: 2
|
||||
},
|
||||
{
|
||||
taskId: 2,
|
||||
taskTitle: 'Create Core Functionality',
|
||||
complexityScore: 8,
|
||||
recommendedSubtasks: 5
|
||||
},
|
||||
{
|
||||
taskId: 3,
|
||||
taskTitle: 'Implement UI Components',
|
||||
complexityScore: 6,
|
||||
recommendedSubtasks: 4
|
||||
}
|
||||
]
|
||||
};
|
||||
|
||||
// Test wrapper function that doesn't rely on the actual implementation
|
||||
async function testListTasks(args, mockLogger) {
|
||||
// File not found case
|
||||
@@ -235,21 +258,35 @@ describe('MCP Server Direct Functions', () => {
|
||||
};
|
||||
}
|
||||
|
||||
// Check for complexity report
|
||||
const complexityReport = mockReadComplexityReport();
|
||||
let tasksData = [...sampleTasks.tasks];
|
||||
|
||||
// Add complexity scores if report exists
|
||||
if (complexityReport && complexityReport.complexityAnalysis) {
|
||||
tasksData = tasksData.map((task) => {
|
||||
const analysis = complexityReport.complexityAnalysis.find(
|
||||
(a) => a.taskId === task.id
|
||||
);
|
||||
if (analysis) {
|
||||
return { ...task, complexityScore: analysis.complexityScore };
|
||||
}
|
||||
return task;
|
||||
});
|
||||
}
|
||||
|
||||
// Success case
|
||||
if (!args.status && !args.withSubtasks) {
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
tasks: sampleTasks.tasks,
|
||||
tasks: tasksData,
|
||||
stats: {
|
||||
total: sampleTasks.tasks.length,
|
||||
completed: sampleTasks.tasks.filter((t) => t.status === 'done')
|
||||
total: tasksData.length,
|
||||
completed: tasksData.filter((t) => t.status === 'done').length,
|
||||
inProgress: tasksData.filter((t) => t.status === 'in-progress')
|
||||
.length,
|
||||
inProgress: sampleTasks.tasks.filter(
|
||||
(t) => t.status === 'in-progress'
|
||||
).length,
|
||||
pending: sampleTasks.tasks.filter((t) => t.status === 'pending')
|
||||
.length
|
||||
pending: tasksData.filter((t) => t.status === 'pending').length
|
||||
}
|
||||
},
|
||||
fromCache: false
|
||||
@@ -258,16 +295,14 @@ describe('MCP Server Direct Functions', () => {
|
||||
|
||||
// Status filter case
|
||||
if (args.status) {
|
||||
const filteredTasks = sampleTasks.tasks.filter(
|
||||
(t) => t.status === args.status
|
||||
);
|
||||
const filteredTasks = tasksData.filter((t) => t.status === args.status);
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
tasks: filteredTasks,
|
||||
filter: args.status,
|
||||
stats: {
|
||||
total: sampleTasks.tasks.length,
|
||||
total: tasksData.length,
|
||||
filtered: filteredTasks.length
|
||||
}
|
||||
},
|
||||
@@ -280,10 +315,10 @@ describe('MCP Server Direct Functions', () => {
|
||||
return {
|
||||
success: true,
|
||||
data: {
|
||||
tasks: sampleTasks.tasks,
|
||||
tasks: tasksData,
|
||||
includeSubtasks: true,
|
||||
stats: {
|
||||
total: sampleTasks.tasks.length
|
||||
total: tasksData.length
|
||||
}
|
||||
},
|
||||
fromCache: false
|
||||
@@ -370,6 +405,29 @@ describe('MCP Server Direct Functions', () => {
|
||||
expect(result.error.code).toBe('FILE_NOT_FOUND_ERROR');
|
||||
expect(mockLogger.error).toHaveBeenCalled();
|
||||
});
|
||||
|
||||
test('should include complexity scores when complexity report exists', async () => {
|
||||
// Arrange
|
||||
mockReadComplexityReport.mockReturnValueOnce(mockComplexityReport);
|
||||
const args = {
|
||||
projectRoot: testProjectRoot,
|
||||
file: testTasksPath,
|
||||
withSubtasks: true
|
||||
};
|
||||
|
||||
// Act
|
||||
const result = await testListTasks(args, mockLogger);
|
||||
// Assert
|
||||
expect(result.success).toBe(true);
|
||||
|
||||
// Check that tasks have complexity scores from the report
|
||||
mockComplexityReport.complexityAnalysis.forEach((analysis) => {
|
||||
const task = result.data.tasks.find((t) => t.id === analysis.taskId);
|
||||
if (task) {
|
||||
expect(task.complexityScore).toBe(analysis.complexityScore);
|
||||
}
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
describe('expandTaskDirect', () => {
|
||||
|
||||
@@ -8,6 +8,30 @@ const mockGetResearchModelId = jest.fn();
|
||||
const mockGetFallbackProvider = jest.fn();
|
||||
const mockGetFallbackModelId = jest.fn();
|
||||
const mockGetParametersForRole = jest.fn();
|
||||
const mockGetUserId = jest.fn();
|
||||
const mockGetDebugFlag = jest.fn();
|
||||
|
||||
// --- Mock MODEL_MAP Data ---
|
||||
// Provide a simplified structure sufficient for cost calculation tests
|
||||
const mockModelMap = {
|
||||
anthropic: [
|
||||
{
|
||||
id: 'test-main-model',
|
||||
cost_per_1m_tokens: { input: 3, output: 15, currency: 'USD' }
|
||||
},
|
||||
{
|
||||
id: 'test-fallback-model',
|
||||
cost_per_1m_tokens: { input: 3, output: 15, currency: 'USD' }
|
||||
}
|
||||
],
|
||||
perplexity: [
|
||||
{
|
||||
id: 'test-research-model',
|
||||
cost_per_1m_tokens: { input: 1, output: 1, currency: 'USD' }
|
||||
}
|
||||
]
|
||||
// Add other providers/models if needed for specific tests
|
||||
};
|
||||
const mockGetBaseUrlForRole = jest.fn();
|
||||
|
||||
jest.unstable_mockModule('../../scripts/modules/config-manager.js', () => ({
|
||||
@@ -18,6 +42,9 @@ jest.unstable_mockModule('../../scripts/modules/config-manager.js', () => ({
|
||||
getFallbackProvider: mockGetFallbackProvider,
|
||||
getFallbackModelId: mockGetFallbackModelId,
|
||||
getParametersForRole: mockGetParametersForRole,
|
||||
getUserId: mockGetUserId,
|
||||
getDebugFlag: mockGetDebugFlag,
|
||||
MODEL_MAP: mockModelMap,
|
||||
getBaseUrlForRole: mockGetBaseUrlForRole
|
||||
}));
|
||||
|
||||
@@ -46,10 +73,15 @@ jest.unstable_mockModule('../../src/ai-providers/perplexity.js', () => ({
|
||||
const mockLog = jest.fn();
|
||||
const mockResolveEnvVariable = jest.fn();
|
||||
const mockFindProjectRoot = jest.fn();
|
||||
const mockIsSilentMode = jest.fn();
|
||||
const mockLogAiUsage = jest.fn();
|
||||
|
||||
jest.unstable_mockModule('../../scripts/modules/utils.js', () => ({
|
||||
log: mockLog,
|
||||
resolveEnvVariable: mockResolveEnvVariable,
|
||||
findProjectRoot: mockFindProjectRoot
|
||||
findProjectRoot: mockFindProjectRoot,
|
||||
isSilentMode: mockIsSilentMode,
|
||||
logAiUsage: mockLogAiUsage
|
||||
}));
|
||||
|
||||
// Import the module to test (AFTER mocks)
|
||||
@@ -85,11 +117,16 @@ describe('Unified AI Services', () => {
|
||||
|
||||
// Set a default behavior for the new mock
|
||||
mockFindProjectRoot.mockReturnValue(fakeProjectRoot);
|
||||
mockGetDebugFlag.mockReturnValue(false);
|
||||
mockGetUserId.mockReturnValue('test-user-id'); // Add default mock for getUserId
|
||||
});
|
||||
|
||||
describe('generateTextService', () => {
|
||||
test('should use main provider/model and succeed', async () => {
|
||||
mockGenerateAnthropicText.mockResolvedValue('Main provider response');
|
||||
mockGenerateAnthropicText.mockResolvedValue({
|
||||
text: 'Main provider response',
|
||||
usage: { inputTokens: 10, outputTokens: 20, totalTokens: 30 }
|
||||
});
|
||||
|
||||
const params = {
|
||||
role: 'main',
|
||||
@@ -99,7 +136,8 @@ describe('Unified AI Services', () => {
|
||||
};
|
||||
const result = await generateTextService(params);
|
||||
|
||||
expect(result).toBe('Main provider response');
|
||||
expect(result.mainResult).toBe('Main provider response');
|
||||
expect(result).toHaveProperty('telemetryData');
|
||||
expect(mockGetMainProvider).toHaveBeenCalledWith(fakeProjectRoot);
|
||||
expect(mockGetMainModelId).toHaveBeenCalledWith(fakeProjectRoot);
|
||||
expect(mockGetParametersForRole).toHaveBeenCalledWith(
|
||||
@@ -129,7 +167,10 @@ describe('Unified AI Services', () => {
|
||||
const mainError = new Error('Main provider failed');
|
||||
mockGenerateAnthropicText
|
||||
.mockRejectedValueOnce(mainError)
|
||||
.mockResolvedValueOnce('Fallback provider response');
|
||||
.mockResolvedValueOnce({
|
||||
text: 'Fallback provider response',
|
||||
usage: { inputTokens: 15, outputTokens: 25, totalTokens: 40 }
|
||||
});
|
||||
|
||||
const explicitRoot = '/explicit/test/root';
|
||||
const params = {
|
||||
@@ -139,7 +180,8 @@ describe('Unified AI Services', () => {
|
||||
};
|
||||
const result = await generateTextService(params);
|
||||
|
||||
expect(result).toBe('Fallback provider response');
|
||||
expect(result.mainResult).toBe('Fallback provider response');
|
||||
expect(result).toHaveProperty('telemetryData');
|
||||
expect(mockGetMainProvider).toHaveBeenCalledWith(explicitRoot);
|
||||
expect(mockGetFallbackProvider).toHaveBeenCalledWith(explicitRoot);
|
||||
expect(mockGetParametersForRole).toHaveBeenCalledWith(
|
||||
@@ -175,14 +217,16 @@ describe('Unified AI Services', () => {
|
||||
mockGenerateAnthropicText
|
||||
.mockRejectedValueOnce(mainError)
|
||||
.mockRejectedValueOnce(fallbackError);
|
||||
mockGeneratePerplexityText.mockResolvedValue(
|
||||
'Research provider response'
|
||||
);
|
||||
mockGeneratePerplexityText.mockResolvedValue({
|
||||
text: 'Research provider response',
|
||||
usage: { inputTokens: 20, outputTokens: 30, totalTokens: 50 }
|
||||
});
|
||||
|
||||
const params = { role: 'main', prompt: 'Research fallback test' };
|
||||
const result = await generateTextService(params);
|
||||
|
||||
expect(result).toBe('Research provider response');
|
||||
expect(result.mainResult).toBe('Research provider response');
|
||||
expect(result).toHaveProperty('telemetryData');
|
||||
expect(mockGetMainProvider).toHaveBeenCalledWith(fakeProjectRoot);
|
||||
expect(mockGetFallbackProvider).toHaveBeenCalledWith(fakeProjectRoot);
|
||||
expect(mockGetResearchProvider).toHaveBeenCalledWith(fakeProjectRoot);
|
||||
@@ -249,22 +293,32 @@ describe('Unified AI Services', () => {
|
||||
const retryableError = new Error('Rate limit');
|
||||
mockGenerateAnthropicText
|
||||
.mockRejectedValueOnce(retryableError) // Fails once
|
||||
.mockResolvedValue('Success after retry'); // Succeeds on retry
|
||||
.mockResolvedValueOnce({
|
||||
// Succeeds on retry
|
||||
text: 'Success after retry',
|
||||
usage: { inputTokens: 5, outputTokens: 10, totalTokens: 15 }
|
||||
});
|
||||
|
||||
const params = { role: 'main', prompt: 'Retry success test' };
|
||||
const result = await generateTextService(params);
|
||||
|
||||
expect(result).toBe('Success after retry');
|
||||
expect(result.mainResult).toBe('Success after retry');
|
||||
expect(result).toHaveProperty('telemetryData');
|
||||
expect(mockGenerateAnthropicText).toHaveBeenCalledTimes(2); // Initial + 1 retry
|
||||
expect(mockLog).toHaveBeenCalledWith(
|
||||
'info',
|
||||
expect.stringContaining('Retryable error detected. Retrying')
|
||||
expect.stringContaining(
|
||||
'Something went wrong on the provider side. Retrying'
|
||||
)
|
||||
);
|
||||
});
|
||||
|
||||
test('should use default project root or handle null if findProjectRoot returns null', async () => {
|
||||
mockFindProjectRoot.mockReturnValue(null); // Simulate not finding root
|
||||
mockGenerateAnthropicText.mockResolvedValue('Response with no root');
|
||||
mockGenerateAnthropicText.mockResolvedValue({
|
||||
text: 'Response with no root',
|
||||
usage: { inputTokens: 1, outputTokens: 1, totalTokens: 2 }
|
||||
});
|
||||
|
||||
const params = { role: 'main', prompt: 'No root test' }; // No explicit root passed
|
||||
await generateTextService(params);
|
||||
|
||||
@@ -2,8 +2,9 @@
|
||||
* Task finder tests
|
||||
*/
|
||||
|
||||
// Import after mocks are set up - No mocks needed for readComplexityReport anymore
|
||||
import { findTaskById } from '../../scripts/modules/utils.js';
|
||||
import { sampleTasks, emptySampleTasks } from '../fixtures/sample-tasks.js';
|
||||
import { emptySampleTasks, sampleTasks } from '../fixtures/sample-tasks.js';
|
||||
|
||||
describe('Task Finder', () => {
|
||||
describe('findTaskById function', () => {
|
||||
@@ -55,5 +56,62 @@ describe('Task Finder', () => {
|
||||
expect(result.task).toBeNull();
|
||||
expect(result.originalSubtaskCount).toBeNull();
|
||||
});
|
||||
test('should work correctly when no complexity report is provided', () => {
|
||||
// Pass null as the complexity report
|
||||
const result = findTaskById(sampleTasks.tasks, 2, null);
|
||||
|
||||
expect(result.task).toBeDefined();
|
||||
expect(result.task.id).toBe(2);
|
||||
expect(result.task.complexityScore).toBeUndefined();
|
||||
});
|
||||
test('should work correctly when task has no complexity data in the provided report', () => {
|
||||
// Define a complexity report that doesn't include task 2
|
||||
const complexityReport = {
|
||||
complexityAnalysis: [{ taskId: 999, complexityScore: 5 }]
|
||||
};
|
||||
|
||||
const result = findTaskById(sampleTasks.tasks, 2, complexityReport);
|
||||
|
||||
expect(result.task).toBeDefined();
|
||||
expect(result.task.id).toBe(2);
|
||||
expect(result.task.complexityScore).toBeUndefined();
|
||||
});
|
||||
|
||||
test('should include complexity score when report is provided', () => {
|
||||
// Define the complexity report for this test
|
||||
const complexityReport = {
|
||||
meta: {
|
||||
generatedAt: '2023-01-01T00:00:00.000Z',
|
||||
tasksAnalyzed: 3,
|
||||
thresholdScore: 5
|
||||
},
|
||||
complexityAnalysis: [
|
||||
{
|
||||
taskId: 1,
|
||||
taskTitle: 'Initialize Project',
|
||||
complexityScore: 3,
|
||||
recommendedSubtasks: 2
|
||||
},
|
||||
{
|
||||
taskId: 2,
|
||||
taskTitle: 'Create Core Functionality',
|
||||
complexityScore: 8,
|
||||
recommendedSubtasks: 5
|
||||
},
|
||||
{
|
||||
taskId: 3,
|
||||
taskTitle: 'Implement UI Components',
|
||||
complexityScore: 6,
|
||||
recommendedSubtasks: 4
|
||||
}
|
||||
]
|
||||
};
|
||||
|
||||
const result = findTaskById(sampleTasks.tasks, 2, complexityReport);
|
||||
|
||||
expect(result.task).toBeDefined();
|
||||
expect(result.task.id).toBe(2);
|
||||
expect(result.task.complexityScore).toBe(8);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
Reference in New Issue
Block a user