Conversation
|
WalkthroughAdds a temporary bridge to delegate AI-driven task updates to API-backed storage (with file fallback), introduces updateTaskWithPrompt across storage and service layers, relaxes CLI ID validation, consolidates fs promises imports, exposes AuthManager.supabaseClient, and updates scripts/tests to integrate tm-core and the bridge. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as CLI / MCP script
participant Bridge as @tm/bridge.tryUpdateViaRemote
participant TMCore as tm-core
participant Storage as Storage Adapter
participant API as Backend API
CLI->>Bridge: tryUpdateViaRemote({taskId, prompt, projectRoot, ...})
Bridge->>TMCore: createTmCore(projectRoot)
TMCore-->>Bridge: tmCore (storageType)
alt storageType == "api"
Bridge->>TMCore: tmCore.tasks.updateWithPrompt(taskId, prompt, mode)
TMCore->>Storage: storage.updateTaskWithPrompt(...)
Storage->>API: PATCH /ai/api/v1/tasks/{taskId}/prompt
API-->>Storage: UpdateTaskWithPromptResponse
Storage-->>TMCore: success
TMCore-->>Bridge: resolved
Bridge-->>CLI: RemoteUpdateResult { success: true, ... }
else
Bridge-->>CLI: null (fallback)
CLI->>Storage: perform local file-based update
Storage-->>CLI: updated task (local)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Areas to focus review on:
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts (1)
117-136: Fix inconsistent field name in assertion.Line 127 checks for
"activeTag":"test-tag"in the JSON output, but the service now usescurrentTagas the field name. This test will fail whensetCurrentTagis called since the saved JSON will containcurrentTag, notactiveTag.Apply this diff to fix the assertion:
// Verify writeFile was called with correct data expect(fs.writeFile).toHaveBeenCalledWith( '/test/project/.taskmaster/state.json', - expect.stringContaining('"activeTag":"test-tag"'), + expect.stringContaining('"currentTag":"test-tag"'), 'utf-8' );packages/tm-core/src/modules/config/services/config-loader.service.spec.ts (1)
6-15: Fix mock target: mock 'node:fs/promises', not 'node:fs'.You now import from node:fs/promises but still mock node:fs. As a result, vi.mocked(fs.readFile/access) aren’t mocked and tests will fail. Mock fs/promises directly.
Apply this diff:
-vi.mock('node:fs', () => ({ - promises: { - readFile: vi.fn(), - access: vi.fn() - } -})); +vi.mock('node:fs/promises', () => ({ + default: { + readFile: vi.fn(), + access: vi.fn() + } +}));packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts (1)
10-20: Fix mock target to 'node:fs/promises'.Tests import fs from node:fs/promises; current mock hits node:fs, leaving fs.* unmocked.
Apply this diff:
-vi.mock('node:fs', () => ({ - promises: { - readFile: vi.fn(), - writeFile: vi.fn(), - mkdir: vi.fn(), - unlink: vi.fn(), - access: vi.fn(), - readdir: vi.fn(), - rename: vi.fn() - } -})); +vi.mock('node:fs/promises', () => ({ + default: { + readFile: vi.fn(), + writeFile: vi.fn(), + mkdir: vi.fn(), + unlink: vi.fn(), + access: vi.fn(), + readdir: vi.fn(), + rename: vi.fn() + } +}));mcp-server/src/core/direct-functions/update-task-by-id.js (2)
60-68: Don’t require tasksJsonPath for API storage; resolve path only for file storageMove this validation after detecting storageType and resolve with findTasksJsonPath(projectRoot) for file storage. This prevents false failures in API mode. As per coding guidelines.
- // Check if tasksJsonPath was provided - if (!tasksJsonPath) { - const errorMessage = 'tasksJsonPath is required but was not provided.'; - logWrapper.error(errorMessage); - return { - success: false, - error: { code: 'MISSING_ARGUMENT', message: errorMessage } - }; - }Apply tasksPath derivation in the file-storage branch (see next diff). Based on learnings.
6-11: Import findTasksJsonPath and use it when in file storageAdd helper import now so you can resolve the path on demand. As per coding guidelines.
import { enableSilentMode, disableSilentMode, - isSilentMode + isSilentMode, + findTasksJsonPath } from '../../../../scripts/modules/utils.js';
🧹 Nitpick comments (10)
quick_fix_update_task.md (1)
1-90: Promote this “Quick Fix Plan” to an ADR/issue with acceptance criteria.Add owner, date, success criteria, rollback, and links to docs.task-master.dev. This improves traceability and avoids drift.
packages/tm-core/src/modules/tasks/tasks-domain.ts (1)
114-145: Doc/type mismatch for updateWithPrompt options.JSDoc documents options.useResearch, but the type omits it. Include it (pass-through to service) or remove from docs.
Apply this diff:
- options?: { mode?: 'append' | 'update' | 'rewrite' } + options?: { mode?: 'append' | 'update' | 'rewrite'; useResearch?: boolean }packages/tm-core/src/modules/tasks/services/task-service.ts (2)
508-555: Optionally guard with initialize() to avoid “Storage not initialized”.If callers forget to init the domain, this throws. Safe to auto-init when needed.
Apply this diff:
async updateTask( @@ - // Ensure we have storage - if (!this.storage) { + // Ensure we have storage + if (!this.storage) { throw new TaskMasterError( 'Storage not initialized', ERROR_CODES.STORAGE_ERROR ); } + if (!this.initialized) { + await this.initialize(); + }
566-616: Keep type in sync with storage: allow useResearch in options.Aligns with IStorage.updateTaskWithPrompt options and upstream docs.
Apply this diff:
- options?: { mode?: 'append' | 'update' | 'rewrite' } + options?: { mode?: 'append' | 'update' | 'rewrite'; useResearch?: boolean }Also consider the same initialize() guard as above for consistency.
scripts/modules/task-manager/update-task-by-id.js (1)
41-52: Update JSDoc: taskId type is no longer numeric-only.The function accepts string IDs (e.g., HAM-123). Adjust the JSDoc to prevent confusion.
- * @param {number} taskId - ID of the task to update + * @param {string|number} taskId - ID of the task to updatetests/unit/scripts/modules/task-manager/list-tasks.test.js (2)
80-141: Deduplicate fixtures to keep tests consistentPrefer importing shared fixtures (tests/fixtures/) or the existing setup.js sampleTasks instead of redefining here to avoid drift. Based on learnings.
339-348: Loosen error message assertion to reduce brittlenessAvoid asserting the exact message; keep code + any string.
- ).rejects.toEqual( - expect.objectContaining({ - code: 'TASK_LIST_ERROR', - message: 'File not found' - }) - ); + ).rejects.toMatchObject({ + code: 'TASK_LIST_ERROR', + message: expect.any(String) + });As per coding guidelines.
mcp-server/src/core/direct-functions/update-task-by-id.js (1)
50-53: Align error codes to standardized setUse INPUT_VALIDATION_ERROR, FILE_NOT_FOUND_ERROR, CORE_FUNCTION_ERROR, UNEXPECTED_ERROR for consistency across direct functions. Current codes (TMCORE_INIT_ERROR, MISSING_ARGUMENT, etc.) diverge. As per coding guidelines.
Also applies to: 65-67, 76-78, 86-88, 103-105, 221-223, 236-238
packages/tm-core/src/modules/storage/adapters/api-storage.ts (1)
591-599: Replace console.log with package loggerUse your standard logger (getLogger) rather than console in core libraries. Keeps output controllable and testable.
scripts/modules/task-manager/list-tasks.js (1)
615-656: Avoid mutating dependency tasks while formattingaddComplexityToTask on depTask mutates the shared task list during table rendering. Consider computing display-only values without side effects.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
mcp-server/src/core/direct-functions/update-subtask-by-id.js(3 hunks)mcp-server/src/core/direct-functions/update-task-by-id.js(4 hunks)packages/tm-core/src/common/interfaces/storage.interface.ts(3 hunks)packages/tm-core/src/modules/auth/managers/auth-manager.ts(1 hunks)packages/tm-core/src/modules/config/services/config-loader.service.spec.ts(1 hunks)packages/tm-core/src/modules/config/services/config-loader.service.ts(1 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts(2 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.ts(1 hunks)packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts(12 hunks)packages/tm-core/src/modules/config/services/runtime-state-manager.service.ts(1 hunks)packages/tm-core/src/modules/reports/managers/complexity-report-manager.ts(1 hunks)packages/tm-core/src/modules/storage/adapters/api-storage.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts(1 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts(1 hunks)packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-service.ts(1 hunks)packages/tm-core/src/modules/tasks/tasks-domain.ts(1 hunks)packages/tm-core/src/modules/workflow/managers/workflow-state-manager.ts(1 hunks)quick_fix_update_task.md(1 hunks)scripts/modules/commands.js(2 hunks)scripts/modules/task-manager/list-tasks.js(3 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)tests/unit/scripts/modules/task-manager/list-tasks.test.js(27 hunks)
🧰 Additional context used
📓 Path-based instructions (23)
**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
Reference documentation at https://docs.task-master.dev rather than local file paths in content
Files:
quick_fix_update_task.md
scripts/modules/commands.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/commands.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.
scripts/modules/commands.js: All new user-facing commands should be added to 'scripts/modules/commands.js'.
Use consistent patterns for option naming and help text in CLI commands.
Follow the Commander.js model for subcommand structure in CLI commands.
When using callbacks (like in Commander.js commands), define them separately to allow testing the callback logic independently.
Add help text to the command definition and update 'dev_workflow.mdc' with command reference when adding a new feature.
Follow the established pattern in 'commands.js' for CLI command implementation, using Commander.js for argument parsing, including comprehensive help text and examples, and supporting tagged task context awareness.
Provide clear error messages for common failu...
Files:
scripts/modules/commands.js
scripts/modules/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module in scripts/modules/ should be focused on a single responsibility, following the modular architecture (e.g., commands.js for CLI command handling, task-manager.js for task data and core logic, dependency-manager.js for dependency management, ui.js for CLI output formatting, ai-services-unified.js for AI service integration, config-manager.js for configuration management, utils.js for utility functions).
scripts/modules/*.js: Export all core functions, helper functions, and utility methods needed by your new function or command from their respective modules. Explicitly review the module's export block to ensure every required dependency is included.
Pass all required parameters to functions you call within your implementation and verify that direct function parameters match their core function counterparts.
Use consistent file naming conventions: 'task_${id.toString().padStart(3, '0')}.txt', use path.join for composing file paths, and use appropriate file extensions (.txt for tasks, .json for data).
Use structured error objects with code and message properties, include clear error messages, and handle both function-specific and file system errors.
Import all silent mode utilities together from 'scripts/modules/utils.js' and always use isSilentMode() to check global silent mode status. Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output.
Core functions should check outputFormat === 'text' before displaying UI elements and use internal logging that respects silent mode.
Design functions to accept dependencies as parameters (dependency injection) and avoid hard-coded dependencies that are difficult to mock.
Keep pure logic separate from I/O operations or UI rendering to allow testing the logic without mocking complex dependencies.
When implementing core logic for new features, do so in 'scripts/modules/' before CLI or MCP interfaces, and d...
Files:
scripts/modules/commands.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/commands.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
scripts/modules/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/*: Every command that reads or writes tasks.json must be tag-aware
All command files must import getCurrentTag from utils.js
Every CLI command that operates on tasks must include the --tag CLI option
All commands must resolve the tag using the pattern: options.tag || getCurrentTag(projectRoot) || 'master'
All commands must find projectRoot with error handling before proceeding
All commands must pass { projectRoot, tag } as context to core functions
MCP direct functions must accept and use a context object containing projectRoot and tag, and pass them to core functions
Do not hard-code tag resolution (e.g., const tag = options.tag || 'master';); always use getCurrentTag
Do not omit the --tag CLI option in commands that operate on tasks
Do not omit the context parameter when calling core functions from commands
Do not call readJSON or writeJSON without passing projectRoot and tag
Files:
scripts/modules/commands.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/commands.jsmcp-server/src/core/direct-functions/update-task-by-id.jstests/unit/scripts/modules/task-manager/list-tasks.test.jsmcp-server/src/core/direct-functions/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
mcp-server/src/core/direct-functions/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
mcp-server/src/core/direct-functions/*.js: Direct function files in mcp-server/src/core/direct-functions/.js must implement silent mode using enableSilentMode and disableSilentMode from scripts/modules/utils.js, and always restore silent mode state using a try/finally block.
Direct function parameters in mcp-server/src/core/direct-functions/.js must match the corresponding core function signatures; do not add extra parameters not present in the core function.
Always use the isSilentMode() function to check silent mode state in mcp-server/src/core/direct-functions/*.js; do not access global variables like silentMode directly.
mcp-server/src/core/direct-functions/*.js: Check that all helper functions your direct function needs are properly exported from their source modules and import these dependencies explicitly at the top of your file in direct functions.
Verify the signature of core functions you're calling in direct functions and ensure all required parameters are provided, passing explicit values for required parameters rather than relying on defaults.
Use path.join() instead of string concatenation for file paths, and follow established file naming conventions (e.g., 'task_001.txt') in direct functions.
Wrap core function calls and AI calls in try/catch blocks in direct functions, log errors with appropriate severity and context, and return standardized error objects with code and message.
When calling a core function from a direct function, pass the log object provided by FastMCP wrapped in the standard logWrapper object as the mcpLog property in the options argument.
Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output that isn't reliably controlled by passing { mcpLog } or an outputFormat parameter.
Do not wrap calls to the unified AI service (generateTextService, generateObjectService) in silent mode; their logging is handled internal...
Files:
mcp-server/src/core/direct-functions/update-task-by-id.jsmcp-server/src/core/direct-functions/update-subtask-by-id.js
mcp-server/src/{tools,core/direct-functions}/*.js
📄 CodeRabbit inference engine (.cursor/rules/mcp.mdc)
mcp-server/src/{tools,core/direct-functions}/*.js: Use kebab-case for all file names in mcp-server/src/tools/ and mcp-server/src/core/direct-functions/.
Use helpers from mcp-server/src/tools/utils.js, mcp-server/src/core/utils/path-utils.js, and mcp-server/src/core/utils/ai-client-utils.js for centralized utilities.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.jsmcp-server/src/core/direct-functions/update-subtask-by-id.js
mcp-server/src/core/direct-functions/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
mcp-server/src/core/direct-functions/**/*.js: Direct function wrappers in mcp-server/src/core/direct-functions/ must call the corresponding core logic function, passing commandName and outputType: 'mcp' in the context, and outputFormat: 'json' if supported.
Direct function wrappers in mcp-server/src/core/direct-functions/ must include coreResult.telemetryData as a field within the data object of the successful response.In direct functions (
mcp-server/src/core/direct-functions/*) that call core functions (scripts/modules/*), ensure console output from the core function is suppressed to avoid breaking MCP JSON responses, preferably by passing anoutputFormatparameter or by wrapping the call with silent mode.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.jsmcp-server/src/core/direct-functions/update-subtask-by-id.js
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}: Use the logger wrapper pattern when passing loggers to preventmcpLog[level] is not a functionerrors; do not pass the FastMCPlogobject directly asmcpLogto core functions.
Ensure silent mode is disabled in afinallyblock to prevent it from staying enabled.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.jsmcp-server/src/core/direct-functions/update-subtask-by-id.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tstests/unit/scripts/modules/task-manager/list-tasks.test.jspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tstests/unit/scripts/modules/task-manager/list-tasks.test.jspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
**/?(*.)+(spec|test).ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
In JavaScript/TypeScript projects using Jest, test files should match *.test.ts and *.spec.ts patterns
Files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
{packages/*/src/**/*.spec.ts,apps/*/src/**/*.spec.ts}
📄 CodeRabbit inference engine (CLAUDE.md)
Place package and app unit test files alongside source as *.spec.ts under src (packages//src//.spec.ts or apps//src//.spec.ts)
Files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
{packages/*/src/**/*.@(spec|test).ts,apps/*/src/**/*.@(spec|test).ts,packages/*/tests/**/*.@(spec|test).ts,apps/*/tests/**/*.@(spec|test).ts,tests/unit/packages/*/**/*.@(spec|test).ts}
📄 CodeRabbit inference engine (CLAUDE.md)
{packages/*/src/**/*.@(spec|test).ts,apps/*/src/**/*.@(spec|test).ts,packages/*/tests/**/*.@(spec|test).ts,apps/*/tests/**/*.@(spec|test).ts,tests/unit/packages/*/**/*.@(spec|test).ts}: Do not use async/await in test functions unless the test is explicitly exercising asynchronous behavior
Use synchronous top-level imports in tests; avoid dynamic await import()
Keep test bodies synchronous whenever possible
Files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
🧠 Learnings (35)
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
packages/tm-core/src/modules/tasks/services/task-service.tspackages/tm-core/src/modules/tasks/tasks-domain.tsmcp-server/src/core/direct-functions/update-task-by-id.jsmcp-server/src/core/direct-functions/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
scripts/modules/commands.jstests/unit/scripts/modules/task-manager/list-tasks.test.jsscripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Use tagged task system aware functions for task finding and manipulation, handle both task and subtask operations, and validate task IDs before operations.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Allow numeric subtask IDs to reference other subtasks within the same parent
Applied to files:
scripts/modules/commands.jsmcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Use numeric IDs for direct task references
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Subtasks must use consistent properties, maintain simple numeric IDs unique within the parent task, and must not duplicate parent task properties.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Use string IDs with dot notation (e.g., "1.2") for subtask references
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/task-manager.js : Features that create, read, update, or delete tasks belong in 'scripts/modules/task-manager.js'.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.jsscripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Create utilities for consistent task ID handling and support different ID formats (numeric, string, dot notation); do not duplicate formatting logic across modules.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-10-20T16:44:58.162Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-10-20T16:44:58.162Z
Learning: Applies to {packages/*/src/**/*.@(spec|test).ts,apps/*/src/**/*.@(spec|test).ts,packages/*/tests/**/*.@(spec|test).ts,apps/*/tests/**/*.@(spec|test).ts,tests/unit/packages/*/**/*.@(spec|test).ts} : Use synchronous top-level imports in tests; avoid dynamic await import()
Applied to files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.ts
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Applied to files:
packages/tm-core/src/modules/config/services/config-loader.service.spec.tstests/unit/scripts/modules/task-manager/list-tasks.test.jspackages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Test core logic independently with both data formats, mock file system operations, test tag resolution behavior, and verify migration compatibility in unit tests.
Applied to files:
packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tstests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Verify modifications on the in-memory task objects passed to writeJSON.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Applies to scripts/modules/task-manager/*.js : Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.jsscripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Allow filtering tasks by status within the current tag context, handle subtask display in lists, and use consistent table formats.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.jsscripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Test CLI and MCP interfaces with real task data, verify end-to-end workflows across tag contexts, and test error scenarios and recovery in integration tests.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Module dependencies should be mocked before importing the test module, following Jest's hoisting behavior.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Mock readJSON and writeJSON to avoid real file system interactions in tests.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.js
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to tasks.json : Use the `tasks.json` file (generated by Taskmaster) to store the project's task list, including tags and task structures.
Applied to files:
tests/unit/scripts/modules/task-manager/list-tasks.test.jsscripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI, create them in the current tag context (defaulting to 'master'), provide clear prompts to guide AI task generation, and validate/clean up AI-generated tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/task-manager/**/*.js : Do not call AI-specific getters (like `getMainModelId`, `getMainMaxTokens`) from core logic functions in `scripts/modules/task-manager/*`; instead, pass the `role` to the unified AI service.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : For AI-powered commands that benefit from project context, use the ContextGatherer utility for multi-source context extraction, support task IDs, file paths, custom context, and project tree, implement fuzzy search for automatic task discovery, and display detailed token breakdown for transparency.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Implement silent migration from legacy to tagged format in the readJSON() function, detect legacy format, convert automatically, and preserve all existing task data during migration.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Tasks must be organized into separate contexts (tags) within tasks.json, using the tagged format: {"master": {"tasks": [...]}, "feature-branch": {"tasks": [...]}}. Legacy format {"tasks": [...]} must be silently migrated to the tagged format on first use.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:13:30.188Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-07-18T17:13:30.188Z
Learning: Applies to scripts/modules/task-manager/* : All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Tasks must be accessed and updated through the tag resolution layer using getTasksForTag(data, tagName) and setTasksForTag(data, tagName, tasks); direct manipulation of the tagged structure in core functions is not allowed.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use tag resolution functions to maintain backward compatibility, returning legacy format to core functions and not exposing the tagged structure to existing core logic.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Core functions must receive the legacy format for 100% backward compatibility, using tag resolution functions to abstract the tagged structure.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T05:38:17.352Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#943
File: scripts/modules/task-manager/move-task.js:24-24
Timestamp: 2025-07-18T05:38:17.352Z
Learning: In the Claude Task Master system, core task-manager functions are designed with fallback mechanisms for missing projectRoot parameters using the pattern `const projectRoot = providedProjectRoot || findProjectRoot();`. The readJSON and writeJSON functions have default parameters (projectRoot = null, tag = null) and handle missing parameters gracefully. Adding strict validation to these core functions would break the established flexible architecture pattern.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Use tag resolution functions for all task data access, provide backward compatibility with legacy format, and default to 'master' tag when no tag is specified.
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:13:30.188Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-07-18T17:13:30.188Z
Learning: Applies to scripts/modules/* : Every command that reads or writes tasks.json must be tag-aware
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:13:30.188Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-07-18T17:13:30.188Z
Learning: Applies to scripts/modules/task-manager/* : All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
Applied to files:
scripts/modules/task-manager/list-tasks.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Applied to files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
🧬 Code graph analysis (8)
packages/tm-core/src/modules/tasks/services/task-service.ts (2)
mcp-server/src/core/direct-functions/update-task-by-id.js (1)
taskId(92-92)scripts/modules/dependency-manager.js (1)
taskIdStr(383-383)
scripts/modules/commands.js (7)
scripts/modules/task-manager/set-task-status.js (1)
taskId(105-105)mcp-server/src/core/direct-functions/add-dependency.js (1)
taskId(67-68)mcp-server/src/core/direct-functions/expand-task.js (1)
taskId(78-78)mcp-server/src/core/direct-functions/set-task-status.js (1)
taskId(69-69)mcp-server/src/core/direct-functions/remove-dependency.js (1)
taskId(65-66)tests/unit/scripts/modules/task-manager/update-single-task-status.test.js (1)
taskId(103-103)scripts/modules/task-manager/update-single-task-status.js (1)
taskId(92-92)
mcp-server/src/core/direct-functions/update-task-by-id.js (3)
mcp-server/src/core/direct-functions/update-subtask-by-id.js (11)
tmCore(37-37)logWrapper(34-34)errorMessage(60-60)errorMessage(70-71)errorMessage(80-81)errorMessage(92-92)errorMessage(102-102)storageType(125-125)tasksPath(111-111)useResearch(112-112)coreResult(161-175)scripts/modules/task-manager/update-task-by-id.js (3)
tmCore(113-115)projectRoot(90-90)storageType(118-118)scripts/modules/task-manager/list-tasks.js (1)
tmCore(48-50)
packages/tm-core/src/modules/storage/adapters/api-storage.ts (1)
packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
AuthManager(26-286)
tests/unit/scripts/modules/task-manager/list-tasks.test.js (2)
tests/unit/scripts/modules/task-manager/setup.js (2)
sampleTasks(7-59)sampleTasks(7-59)scripts/modules/task-manager/list-tasks.js (1)
result(53-53)
mcp-server/src/core/direct-functions/update-subtask-by-id.js (2)
mcp-server/src/core/direct-functions/update-task-by-id.js (6)
tmCore(39-39)logWrapper(36-36)storageType(125-125)coreResult(155-170)tasksPath(109-109)useResearch(112-112)scripts/modules/task-manager/update-task-by-id.js (3)
tmCore(113-115)projectRoot(90-90)storageType(118-118)
scripts/modules/task-manager/update-task-by-id.js (5)
mcp-server/src/core/direct-functions/update-task-by-id.js (4)
taskId(92-92)tasksPath(109-109)tmCore(39-39)storageType(125-125)mcp-server/src/core/direct-functions/add-dependency.js (2)
taskId(67-68)tasksPath(64-64)src/utils/path-utils.js (7)
projectRoot(137-137)projectRoot(226-226)projectRoot(298-298)projectRoot(369-369)projectRoot(415-415)findProjectRoot(55-115)tag(398-398)scripts/modules/task-manager/update-tasks.js (2)
projectRoot(70-70)data(76-76)scripts/modules/task-manager/list-tasks.js (2)
tmCore(48-50)task(844-844)
scripts/modules/task-manager/list-tasks.js (3)
tests/unit/scripts/modules/task-manager/list-tasks.test.js (1)
listTasks(76-78)scripts/modules/task-manager/update-task-by-id.js (2)
tmCore(113-115)projectRoot(90-90)scripts/modules/ai-services-unified.js (1)
tasksPath(193-198)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (21)
packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts (1)
6-6: LGTM! Import modernization follows Node.js best practices.The update from
'fs'to'node:fs'is a recommended modernization that makes it explicit this is a Node.js built-in module and prevents potential naming conflicts.packages/tm-core/src/modules/workflow/managers/workflow-state-manager.ts (1)
9-9: LGTM! Modern filesystem import pattern.The switch from
import { promises as fs } from 'node:fs'toimport fs from 'node:fs/promises'is the recommended modern approach for accessing filesystem promises in Node.js. This change maintains backward compatibility while following current best practices.packages/tm-core/src/modules/config/services/runtime-state-manager.service.ts (1)
6-6: LGTM! Modern filesystem import pattern.Consistent with the broader repository refactor to use
node:fs/promisesas the standard import path for filesystem promises.packages/tm-core/src/modules/reports/managers/complexity-report-manager.ts (1)
6-6: LGTM! Modern filesystem import pattern.Aligns with the repository-wide standardization on
node:fs/promisesfor filesystem operations.packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts (3)
6-6: LGTM! Modern filesystem import pattern.Consistent with the repository-wide standardization on
node:fs/promises.
38-108: LGTM! Test updates align with API rename.The test updates correctly reflect the migration from
activeTagtocurrentTagthroughout the service API and state structure.
161-270: LGTM! Test updates align with API rename.The remaining test updates correctly use
getCurrentTagandsetCurrentTagmethods and verifycurrentTagin state assertions.mcp-server/src/core/direct-functions/update-subtask-by-id.js (3)
36-51: LGTM! Proper TM Core initialization with error handling.The initialization includes appropriate error handling and logging, returning a standardized error object on failure. This follows the pattern established in update-task-by-id.js.
124-154: LGTM! API storage path correctly delegates to backend.The API storage branch properly uses
updateWithPromptto send the update request to the backend. The success message correctly indicates that the prompt was sent, and the returned data structure is appropriate.
53-250: LGTM! Consistent error handling and silent mode management.The overall structure follows established patterns with proper:
- Input validation with specific error codes
- Silent mode handling in try/finally blocks
- Error wrapping with appropriate codes
- Logging at key decision points
packages/tm-core/src/modules/config/services/config-loader.service.ts (1)
6-6: LGTM! Modern filesystem import pattern.Consistent with the repository-wide refactor to standardize on
node:fs/promises.packages/tm-core/src/modules/config/services/config-persistence.service.ts (1)
6-6: LGTM! Modern filesystem import pattern.Final file completing the repository-wide standardization on
node:fs/promisesfor filesystem operations.packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
31-31: Change is justified—external code depends on supabaseClient.External access found in
packages/tm-core/src/modules/storage/adapters/api-storage.ts(line 549), where the storage adapter retrieves the Supabase client to callgetSession(). The change fromprivatetopublicis necessary to support this dependency and does not create unnecessary encapsulation violations.scripts/modules/commands.js (1)
1083-1107: LGTM: broader ID validation for update-task.Accepting label-number IDs (e.g., ham-123) aligns with API-backed storage. No further concerns.
Please ensure command help/examples mention non-numeric IDs where relevant.
scripts/modules/task-manager/update-task-by-id.js (1)
111-121: Review comment is based on an incorrect assumption about TM Core initialization.The
createTmCorefunction is an async static factory method that creates an instance and awaitsinstance.initialize()before returning it. This factory pattern guarantees that all initialization, including storage setup, is complete before the instance is returned to the caller.In the code shown,
await createTmCore({...})properly waits for the factory method to complete, ensuring that by the timetmCore.tasks.getStorageType()is called, the storage layer is already initialized. Additionally, thegetStorageType()implementation simply returns a literal string ('file' or 'api') and does not check initialization state.No defensive initialization check is needed—the code is already correct.
Likely an incorrect or invalid review comment.
tests/unit/scripts/modules/task-manager/list-tasks.test.js (1)
50-58: Tm‑core mocking approach is solidGood use of jest.unstable_mockModule to control tm-core and keep tests hermetic.
packages/tm-core/src/modules/storage/adapters/api-storage.ts (3)
528-529: Type surface: options.mode is accepted here but abstract BaseStorage omits itSee interface/BaseStorage mismatch; fix in BaseStorage (separate comment).
524-613: No duplication found—review comment is incorrectVerification shows only one
updateTaskWithPromptmethod definition at line 524. The other references (lines 535, 557, 604) are string literals used in logging and error handling, not duplicate method definitions.Likely an incorrect or invalid review comment.
567-575: The review comment is incorrect and can be dismissedThe current setup is correct for Node.js. @types/node v22 includes global fetch type definitions through its bundled undici-types dependency, which is already in devDependencies. The code will compile and run without issues. Adding DOM lib or importing a fetch polyfill would be unnecessary.
Likely an incorrect or invalid review comment.
scripts/modules/task-manager/list-tasks.js (2)
45-68: Tm‑core bridge with clean legacy fallbackInitialization + fallback to readJSON is well‑structured; good resilience without breaking existing flows.
241-260: JSON: details stripping looks correctFiltering first, then omitting details (including subtask details) yields a lean JSON payload. Matches tests.
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
Outdated
Show resolved
Hide resolved
packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
Show resolved
Hide resolved
packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts
Show resolved
Hide resolved
- add bridge package to bridge tm core and legacy scripts
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
mcp-server/src/core/direct-functions/update-task-by-id.js (2)
140-141: Avoid nonstandard logger level "success".
createLogWrappertypically exposes standard levels (info/warn/error/debug). UselogWrapper.infoto avoid runtime errors.- logWrapper.success(successMessage); + logWrapper.info(successMessage);
73-88: Normalize numeric IDs to strings.When
idis a number, it should be converted to a string for consistency with downstream APIs.} else if (typeof id === 'number') { // Convert number to string for consistency - taskId = id; + taskId = String(id);scripts/modules/task-manager/update-task-by-id.js (1)
107-129: Reorder checks to support API storage without local files.The file existence check (line 107) runs before the bridge attempt (lines 111-129). For API storage scenarios where no local tasks.json exists, this will fail early and never reach the bridge path.
Move the bridge check before the file existence check:
- if (!fs.existsSync(tasksPath)) - throw new Error(`Tasks file not found: ${tasksPath}`); - // --- End Input Validations --- - - // --- BRIDGE: Try remote update first (API storage) --- + // --- BRIDGE: Try remote update first (API storage) --- const remoteResult = await tryUpdateViaRemote({ taskId, prompt, projectRoot, tag, appendMode, useResearch, isMCP, outputFormat, report }); // If remote handled it, return the result if (remoteResult) { return remoteResult; } // Otherwise fall through to file-based logic below // --- End BRIDGE --- + + // For file storage, ensure the tasks file exists + if (!fs.existsSync(tasksPath)) + throw new Error(`Tasks file not found: ${tasksPath}`); + // --- End Input Validations ---
🧹 Nitpick comments (4)
packages/tm-bridge/tsconfig.json (1)
1-36: Consider inheriting root tsconfig for consistency.Add "extends": "../../tsconfig.json" so this package inherits shared compiler settings and internal path mappings, reducing divergence. Based on learnings.
packages/tm-bridge/src/update-bridge.ts (2)
100-113: Avoid logging raw prompt by default.Prompts may contain sensitive data. Gate the preview behind a debug flag and shorten it.
- chalk.white( - `Prompt: ${prompt.substring(0, 100)}${prompt.length > 100 ? '...' : ''}` - ), + (() => { + const show = process.env.TM_DEBUG === '1'; + const preview = `${prompt.substring(0, 60)}${prompt.length > 60 ? '...' : ''}`; + return chalk.white(`Prompt: ${show ? preview : '[hidden]'}`); + })(),
8-27: Unused param in UpdateBridgeParams.useResearch is accepted but never used. Remove it or plumb it through if the remote path needs it.
packages/tm-bridge/README.md (1)
24-32: Optional: Add language identifier to code fence.The static analysis tool suggests adding a language identifier to the fenced code block for better rendering.
-``` +```text Current: CLI → legacy scripts → @tm/bridge → @tm/core MCP → direct functions → legacy scripts → @tm/bridge → @tm/core
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (13)
mcp-server/src/core/direct-functions/update-subtask-by-id.js(2 hunks)mcp-server/src/core/direct-functions/update-task-by-id.js(2 hunks)packages/tm-bridge/README.md(1 hunks)packages/tm-bridge/package.json(1 hunks)packages/tm-bridge/src/index.ts(1 hunks)packages/tm-bridge/src/update-bridge.ts(1 hunks)packages/tm-bridge/tsconfig.json(1 hunks)packages/tm-core/src/modules/storage/adapters/api-storage.ts(5 hunks)packages/tm-core/src/modules/storage/utils/api-client.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-service.ts(1 hunks)scripts/modules/task-manager/update-subtask-by-id.js(2 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)tsconfig.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- mcp-server/src/core/direct-functions/update-subtask-by-id.js
🧰 Additional context used
📓 Path-based instructions (10)
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.jsmcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/core/direct-functions/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
mcp-server/src/core/direct-functions/*.js: Direct function files in mcp-server/src/core/direct-functions/.js must implement silent mode using enableSilentMode and disableSilentMode from scripts/modules/utils.js, and always restore silent mode state using a try/finally block.
Direct function parameters in mcp-server/src/core/direct-functions/.js must match the corresponding core function signatures; do not add extra parameters not present in the core function.
Always use the isSilentMode() function to check silent mode state in mcp-server/src/core/direct-functions/*.js; do not access global variables like silentMode directly.
mcp-server/src/core/direct-functions/*.js: Check that all helper functions your direct function needs are properly exported from their source modules and import these dependencies explicitly at the top of your file in direct functions.
Verify the signature of core functions you're calling in direct functions and ensure all required parameters are provided, passing explicit values for required parameters rather than relying on defaults.
Use path.join() instead of string concatenation for file paths, and follow established file naming conventions (e.g., 'task_001.txt') in direct functions.
Wrap core function calls and AI calls in try/catch blocks in direct functions, log errors with appropriate severity and context, and return standardized error objects with code and message.
When calling a core function from a direct function, pass the log object provided by FastMCP wrapped in the standard logWrapper object as the mcpLog property in the options argument.
Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output that isn't reliably controlled by passing { mcpLog } or an outputFormat parameter.
Do not wrap calls to the unified AI service (generateTextService, generateObjectService) in silent mode; their logging is handled internal...
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/{tools,core/direct-functions}/*.js
📄 CodeRabbit inference engine (.cursor/rules/mcp.mdc)
mcp-server/src/{tools,core/direct-functions}/*.js: Use kebab-case for all file names in mcp-server/src/tools/ and mcp-server/src/core/direct-functions/.
Use helpers from mcp-server/src/tools/utils.js, mcp-server/src/core/utils/path-utils.js, and mcp-server/src/core/utils/ai-client-utils.js for centralized utilities.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/core/direct-functions/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
mcp-server/src/core/direct-functions/**/*.js: Direct function wrappers in mcp-server/src/core/direct-functions/ must call the corresponding core logic function, passing commandName and outputType: 'mcp' in the context, and outputFormat: 'json' if supported.
Direct function wrappers in mcp-server/src/core/direct-functions/ must include coreResult.telemetryData as a field within the data object of the successful response.In direct functions (
mcp-server/src/core/direct-functions/*) that call core functions (scripts/modules/*), ensure console output from the core function is suppressed to avoid breaking MCP JSON responses, preferably by passing anoutputFormatparameter or by wrapping the call with silent mode.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}: Use the logger wrapper pattern when passing loggers to preventmcpLog[level] is not a functionerrors; do not pass the FastMCPlogobject directly asmcpLogto core functions.
Ensure silent mode is disabled in afinallyblock to prevent it from staying enabled.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
Reference documentation at https://docs.task-master.dev rather than local file paths in content
Files:
packages/tm-bridge/README.md
🧠 Learnings (13)
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.jspackages/tm-core/src/modules/tasks/services/task-service.ts
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI, create them in the current tag context (defaulting to 'master'), provide clear prompts to guide AI task generation, and validate/clean up AI-generated tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-09-26T19:05:47.555Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Applied to files:
packages/tm-bridge/package.jsontsconfig.json
📚 Learning: 2025-09-26T19:10:32.906Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: tsconfig.json:22-28
Timestamp: 2025-09-26T19:10:32.906Z
Learning: In the eyaltoledano/claude-task-master repository, all internal tm/ package path mappings in tsconfig.json consistently point to TypeScript source files (e.g., "./packages/*/src/index.ts") rather than built JavaScript. This is intentional architecture because tsdown bundles internal packages directly from source during build time, eliminating the need for separate compilation of internal packages.
Applied to files:
packages/tm-bridge/package.jsontsconfig.jsonpackages/tm-bridge/tsconfig.json
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Allow numeric subtask IDs to reference other subtasks within the same parent
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:40.548Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:40.548Z
Learning: Applies to scripts/modules/dependency-manager.js : Use numeric IDs for direct task references
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Use tagged task system aware functions for task finding and manipulation, handle both task and subtask operations, and validate task IDs before operations.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Create utilities for consistent task ID handling and support different ID formats (numeric, string, dot notation); do not duplicate formatting logic across modules.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to {scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js} : Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors; do not pass the FastMCP `log` object directly as `mcpLog` to core functions.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:11:36.732Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-07-18T17:11:36.732Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : Use log.info() for progress indication within direct functions instead of reportProgress.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to mcp-server/src/core/utils/path-utils.js : Call `findTasksJsonPath(args, log)` from within direct function wrappers in `mcp-server/src/core/direct-functions/` to get the absolute path to the relevant `tasks.json`.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
🧬 Code graph analysis (6)
packages/tm-bridge/src/update-bridge.ts (5)
mcp-server/src/core/direct-functions/update-subtask-by-id.js (1)
args(31-31)mcp-server/src/core/direct-functions/update-task-by-id.js (1)
args(32-33)scripts/modules/task-manager/list-tasks.js (1)
tmCore(48-50)scripts/modules/task-manager/update-subtask-by-id.js (4)
projectRoot(91-91)report(57-64)isMCP(54-54)loadingIndicator(66-66)scripts/modules/task-manager/update-task-by-id.js (4)
projectRoot(90-90)report(68-75)isMCP(65-65)loadingIndicator(322-322)
scripts/modules/task-manager/update-subtask-by-id.js (2)
scripts/modules/task-manager/update-task-by-id.js (1)
remoteResult(112-122)packages/tm-bridge/src/update-bridge.ts (1)
tryUpdateViaRemote(51-182)
scripts/modules/task-manager/update-task-by-id.js (5)
scripts/modules/dependency-manager.js (3)
taskId(985-987)task(391-391)task(988-988)mcp-server/src/core/direct-functions/add-dependency.js (1)
taskId(67-68)scripts/modules/task-manager/update-subtask-by-id.js (2)
projectRoot(91-91)remoteResult(99-109)src/utils/path-utils.js (7)
projectRoot(137-137)projectRoot(226-226)projectRoot(298-298)projectRoot(369-369)projectRoot(415-415)findProjectRoot(55-115)tag(398-398)packages/tm-bridge/src/update-bridge.ts (1)
tryUpdateViaRemote(51-182)
mcp-server/src/core/direct-functions/update-task-by-id.js (5)
scripts/modules/dependency-manager.js (1)
taskId(985-987)mcp-server/src/core/direct-functions/add-dependency.js (1)
taskId(67-68)mcp-server/src/core/direct-functions/remove-dependency.js (1)
taskId(65-66)mcp-server/src/core/direct-functions/set-task-status.js (4)
taskId(69-69)errorMessage(36-36)errorMessage(46-47)errorMessage(56-57)mcp-server/src/core/direct-functions/update-subtask-by-id.js (6)
errorMessage(42-42)errorMessage(52-53)errorMessage(62-63)errorMessage(74-74)errorMessage(84-84)logWrapper(33-33)
packages/tm-core/src/modules/tasks/services/task-service.ts (1)
scripts/modules/dependency-manager.js (1)
taskIdStr(383-383)
packages/tm-core/src/modules/storage/adapters/api-storage.ts (2)
packages/tm-core/src/modules/storage/utils/api-client.ts (1)
ApiClient(24-146)packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
AuthManager(26-286)
🪛 markdownlint-cli2 (0.18.1)
packages/tm-bridge/README.md
24-24: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (11)
tsconfig.json (1)
30-33: Path aliases for @tm/bridge are correctly configured.The verification confirms
@tm/bridgefollows the established monorepo pattern consistently used for all internal packages, mapping to TypeScript sources as intended for tsdown's source-level bundling.packages/tm-bridge/src/update-bridge.ts (1)
135-140: ****The review comment is incorrect. The codebase exposes
updateWithPrompt()as a public method in the tasks-domain module, which is the correct API being called. Internally, this method delegates toupdateTaskWithPrompt()on the storage service, so the code at line 137 in update-bridge.ts is correct as written and will not throw at runtime.Likely an incorrect or invalid review comment.
packages/tm-bridge/package.json (1)
4-16: The current exports configuration is correct for this internal package architecture.The review comment's concern about "runtime TS import crashes" is invalid. The scripts/ entries are bundled by tsdown with
noExternal: [/^@tm\//], which means @tm/bridge is bundled into the output. The scripts don't run at runtime directly—they're processed during build and output as JavaScript to dist/. The current pattern of pointing exports to TypeScript source aligns with how internal packages are consumed during build-time bundling with tsdown.No changes needed. The diff suggested in the review comment is unnecessary and contradicts the established pattern for internal packages in this monorepo.
Likely an incorrect or invalid review comment.
packages/tm-bridge/README.md (1)
1-53: LGTM - Clear documentation of temporary bridge package.The README effectively documents the bridge package's purpose, deletion criteria, migration path, and usage. The warnings about its temporary nature are prominent and clear.
packages/tm-bridge/src/index.ts (1)
1-16: LGTM - Clean public API surface.The index file properly re-exports the bridge API with clear documentation about the package's temporary nature.
packages/tm-core/src/modules/tasks/services/task-service.ts (1)
508-615: LGTM - Well-structured task update methods.The new
updateTaskandupdateTaskWithPromptmethods follow consistent patterns:
- Validate storage initialization
- Normalize taskId to string
- Resolve active tag
- Preserve user-facing errors (NO_BRIEF_SELECTED)
- Wrap internal errors with detailed context
The separation between direct updates and AI-powered updates is clear and appropriate.
packages/tm-core/src/modules/storage/adapters/api-storage.ts (2)
522-590: LGTM - Clean API-backed update with prompt support.The
updateTaskWithPromptmethod properly:
- Validates initialization
- Determines mode with sensible default ('append')
- Delegates to ApiClient for auth/error handling
- Validates API response
- Wraps errors appropriately with context
The implementation leverages the new ApiClient utility effectively, centralizing auth and error handling.
887-914: LGTM - API client factory with proper context.The
getApiClienthelper properly:
- Lazily creates the client
- Validates environment configuration
- Ensures brief selection via context
- Passes auth manager and account ID
scripts/modules/task-manager/update-task-by-id.js (2)
80-94: LGTM - Relaxed ID validation supports multiple formats.The updated validation properly accepts numeric, alphanumeric, and subtask IDs while ensuring non-empty values. Early project root determination is appropriate for API key checks and bridge usage.
37-37: LGTM - Bridge integration imported correctly.The import of
tryUpdateViaRemotefrom@tm/bridgeproperly integrates the temporary bridge layer for API storage delegation.packages/tm-core/src/modules/storage/utils/api-client.ts (1)
1-146: LGTM - Well-designed API client utility.The
ApiClientclass provides clean centralization of:
- Authentication via session tokens
- Request construction with proper headers
- Error handling with TaskMasterError wrapping
- Type-safe generic methods
- Graceful fallback for non-JSON error responses
The implementation follows good practices:
- Re-throws existing TaskMasterError instances without double-wrapping
- Provides convenient verb methods (get/post/patch/put/delete)
- Includes detailed context in error objects
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/modules/task-manager/update-task-by-id.js (1)
438-441: Fix ID-restore type drift; compare using normalized numeric ID and restore as number.
updatedTask.id !== taskIdcan be true for1 !== '1', leading to writing a string ID back to file. Compare tonumericTaskIdand set a number.- if (updatedTask.id !== taskId) { - report('warn', `AI changed task ID. Restoring original ID ${taskId}.`); - updatedTask.id = taskId; - } + if (String(updatedTask.id) !== String(numericTaskId)) { + report('warn', `AI changed task ID. Restoring original ID ${numericTaskId}.`); + updatedTask.id = numericTaskId; + }
♻️ Duplicate comments (1)
scripts/modules/task-manager/update-task-by-id.js (1)
41-53: JSDoc type for taskId should allow string or number; update return shape doc.You accept non-numeric and display IDs; reflect this in docs and describe the returned object shape.
- * @param {number} taskId - ID of the task to update + * @param {string|number} taskId - ID of the task to update (numeric for file storage; display/compound IDs allowed for remote/API) @@ - * @returns {Promise<Object|null>} - The updated task or null if update failed. + * @returns {Promise<{updatedTask?: Object|null, telemetryData?: any, tagInfo?: any, remote?: Object}|null>} + * Returns normalized object for both remote and local paths; `updatedTask` is null when handled remotely.
🧹 Nitpick comments (3)
scripts/modules/task-manager/update-task-by-id.js (3)
347-359: Prefer generateTextService + manual JSON parsing (+ Zod) for reliability.Guidelines recommend text generation + robust manual parsing over
generateObjectServicedue to provider variability. Switch the full-update path accordingly.- } else { - // Full update mode uses generateObjectService for structured output - aiServiceResponse = await generateObjectService({ - role: serviceRole, - session: session, - projectRoot: projectRoot, - systemPrompt: systemPrompt, - prompt: userPrompt, - schema: COMMAND_SCHEMAS['update-task-by-id'], - objectName: 'task', - commandName: 'update-task', - outputType: isMCP ? 'mcp' : 'cli' - }); - } + } else { + // Full update: use text generation and parse JSON manually + aiServiceResponse = await generateTextService({ + role: serviceRole, + session, + projectRoot, + systemPrompt, + prompt: userPrompt, + commandName: 'update-task', + outputType: isMCP ? 'mcp' : 'cli' + }); + } @@ - // Full update mode: Use structured data directly - const updatedTask = aiServiceResponse.mainResult.task; + // Full update mode: parse structured data from text + let parsed; + try { + parsed = JSON.parse(aiServiceResponse.mainResult); + } catch (e) { + throw new Error('AI did not return valid JSON for update-task.'); + } + // If a Zod schema is available, validate + if (COMMAND_SCHEMAS?.['update-task-by-id']?.parse) { + parsed = COMMAND_SCHEMAS['update-task-by-id'].parse(parsed); + } + const updatedTask = parsed.task;As per coding guidelines.
Also applies to: 430-431
95-105: Avoid API-key gating in core logic; let the unified service handle capability fallback.Choosing role is fine, but checking
isApiKeySet('perplexity')in core logic couples this module to provider specifics. Consider always passingrole: 'research'when requested and let the service layer resolve fallback and messaging.- if (useResearch && !isApiKeySet('perplexity', session)) { - report( - 'warn', - 'Perplexity research requested but API key not set. Falling back.' - ); - if (outputFormat === 'text') - console.log( - chalk.yellow('Perplexity AI not available. Falling back to main AI.') - ); - useResearch = false; - } + // Defer provider/key resolution to the service layer + // If research is unavailable, the service will fallback and return telemetry we can display.As per coding guidelines.
369-385: Safer append markup to reduce downstream parsing risk.Custom tags like
<info added on ...>may break markdown renderers or naive HTML sanitizers. Consider a plain Markdown block with timestamped header.- const formattedBlock = `<info added on ${timestamp}>\n${generatedContentString.trim()}\n</info added on ${timestamp}>`; + const formattedBlock = `### Update (${timestamp})\n\n${generatedContentString.trim()}\n`;
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
mcp-server/src/core/direct-functions/update-task-by-id.js(3 hunks)packages/tm-core/src/common/interfaces/storage.interface.ts(3 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts(1 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- mcp-server/src/core/direct-functions/update-task-by-id.js
- packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts
- packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
- packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
🧰 Additional context used
📓 Path-based instructions (5)
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/update-task-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/task-manager/update-task-by-id.js
🧠 Learnings (4)
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI, create them in the current tag context (defaulting to 'master'), provide clear prompts to guide AI task generation, and validate/clean up AI-generated tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
🧬 Code graph analysis (1)
scripts/modules/task-manager/update-task-by-id.js (4)
mcp-server/src/core/direct-functions/add-dependency.js (1)
taskId(67-68)scripts/modules/task-manager/update-subtask-by-id.js (2)
projectRoot(91-91)remoteResult(99-109)src/utils/path-utils.js (7)
projectRoot(137-137)projectRoot(226-226)projectRoot(298-298)projectRoot(369-369)projectRoot(415-415)findProjectRoot(55-115)tag(398-398)packages/tm-bridge/src/update-bridge.ts (1)
tryUpdateViaRemote(51-182)
🔇 Additional comments (5)
packages/tm-core/src/common/interfaces/storage.interface.ts (3)
66-66: Good clarification!The addition of "(direct structural update)" helps distinguish this method from the new AI-powered
updateTaskWithPromptmethod. This improves API clarity for consumers.
78-94: Well-designed API addition!The new
updateTaskWithPromptmethod provides a clear interface for AI-powered task updates. The documentation is comprehensive, and the signature properly includes bothuseResearchandmodeoptions with clear descriptions of their usage contexts.
251-257: Past review issue resolved: signatures now match!The abstract method declaration in
BaseStoragenow matches theIStorageinterface exactly, including themodeoption that was previously flagged in the past review. Both declarations properly includeoptions?: { useResearch?: boolean; mode?: 'append' | 'update' | 'rewrite' }, ensuring TypeScript signature alignment.scripts/modules/task-manager/update-task-by-id.js (2)
37-37: @tm/bridge is properly declared and configured—no action needed.@tm/bridge is correctly set up as a workspace package in the root
package.json(workspaces includes"packages/*") and is properly configured in its ownpackage.jsonwith ESM type, main, and exports fields. npm workspaces will automatically symlink it tonode_modules/@tm/bridge, and Node.js ESM resolution will find it at runtime without errors.Likely an incorrect or invalid review comment.
354-355: The schema key is verified to exist; review comment concern is inaccurate.The schema key 'update-task-by-id' exists in COMMAND_SCHEMAS and is properly imported. However, the stated concern about "providers that do not supply it" is misleading—providers don't supply schemas; these are codebase-level configurations. Reviewing the codebase pattern, no other task-manager files (add-task.js, update-tasks.js, expand-task.js, analyze-task-complexity.js) guard against missing schema keys when calling generateObjectService. Adding a guard clause here would be inconsistent with the established pattern throughout the codebase.
The actual risk (typos in key names) is a code review concern, not a runtime provider issue. The current implementation matches the codebase standard.
08c7da5 to
2aa289c
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
mcp-server/src/core/direct-functions/update-task-by-id.js (1)
155-163: Use standard error codes per guidelines.The error codes should match the standardized set defined in the coding guidelines.
Based on learnings.
Apply this diff:
} catch (error) { logWrapper.error(`Error updating task by ID: ${error.message}`); return { success: false, error: { - code: 'UPDATE_TASK_CORE_ERROR', + code: 'CORE_FUNCTION_ERROR', message: error.message || 'Unknown error updating task' } }; } finally {} catch (error) { logWrapper.error(`Setup error in updateTaskByIdDirect: ${error.message}`); if (isSilentMode()) disableSilentMode(); return { success: false, error: { - code: 'DIRECT_FUNCTION_SETUP_ERROR', + code: 'UNEXPECTED_ERROR', message: error.message || 'Unknown setup error' } }; }Also applies to: 169-179
🧹 Nitpick comments (2)
mcp-server/src/core/direct-functions/update-task-by-id.js (1)
42-50: Consider using findTasksJsonPath per guidelines.The coding guidelines specify that direct functions should derive the tasks.json path using
findTasksJsonPath(args, log)based onprojectRoot, rather than requiringtasksJsonPathto be provided. While the current validation works, aligning with the guideline would ensure consistency across direct functions.As per coding guidelines.
Also applies to: 90-91
packages/tm-bridge/src/update-bridge.ts (1)
67-67: Remove redundant fallback to process.cwd().Since
projectRootis a required parameter in UpdateBridgeParams (line 14), the fallback toprocess.cwd()is unnecessary.- tmCore = await createTmCore({ - projectPath: projectRoot || process.cwd() - }); + tmCore = await createTmCore({ + projectPath: projectRoot + });
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
mcp-server/src/core/direct-functions/update-task-by-id.js(5 hunks)packages/tm-bridge/README.md(1 hunks)packages/tm-bridge/src/update-bridge.ts(1 hunks)packages/tm-bridge/tsconfig.json(1 hunks)packages/tm-core/src/common/interfaces/storage.interface.ts(3 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/api-storage.ts(5 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-service.ts(1 hunks)packages/tm-core/src/modules/tasks/tasks-domain.ts(1 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/tm-bridge/README.md
🚧 Files skipped from review as they are similar to previous changes (6)
- scripts/modules/task-manager/update-task-by-id.js
- packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
- packages/tm-core/src/modules/tasks/tasks-domain.ts
- packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
- packages/tm-bridge/tsconfig.json
- packages/tm-core/src/modules/tasks/services/task-service.ts
🧰 Additional context used
📓 Path-based instructions (5)
mcp-server/src/core/direct-functions/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
mcp-server/src/core/direct-functions/*.js: Direct function files in mcp-server/src/core/direct-functions/.js must implement silent mode using enableSilentMode and disableSilentMode from scripts/modules/utils.js, and always restore silent mode state using a try/finally block.
Direct function parameters in mcp-server/src/core/direct-functions/.js must match the corresponding core function signatures; do not add extra parameters not present in the core function.
Always use the isSilentMode() function to check silent mode state in mcp-server/src/core/direct-functions/*.js; do not access global variables like silentMode directly.
mcp-server/src/core/direct-functions/*.js: Check that all helper functions your direct function needs are properly exported from their source modules and import these dependencies explicitly at the top of your file in direct functions.
Verify the signature of core functions you're calling in direct functions and ensure all required parameters are provided, passing explicit values for required parameters rather than relying on defaults.
Use path.join() instead of string concatenation for file paths, and follow established file naming conventions (e.g., 'task_001.txt') in direct functions.
Wrap core function calls and AI calls in try/catch blocks in direct functions, log errors with appropriate severity and context, and return standardized error objects with code and message.
When calling a core function from a direct function, pass the log object provided by FastMCP wrapped in the standard logWrapper object as the mcpLog property in the options argument.
Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output that isn't reliably controlled by passing { mcpLog } or an outputFormat parameter.
Do not wrap calls to the unified AI service (generateTextService, generateObjectService) in silent mode; their logging is handled internal...
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/{tools,core/direct-functions}/*.js
📄 CodeRabbit inference engine (.cursor/rules/mcp.mdc)
mcp-server/src/{tools,core/direct-functions}/*.js: Use kebab-case for all file names in mcp-server/src/tools/ and mcp-server/src/core/direct-functions/.
Use helpers from mcp-server/src/tools/utils.js, mcp-server/src/core/utils/path-utils.js, and mcp-server/src/core/utils/ai-client-utils.js for centralized utilities.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/core/direct-functions/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
mcp-server/src/core/direct-functions/**/*.js: Direct function wrappers in mcp-server/src/core/direct-functions/ must call the corresponding core logic function, passing commandName and outputType: 'mcp' in the context, and outputFormat: 'json' if supported.
Direct function wrappers in mcp-server/src/core/direct-functions/ must include coreResult.telemetryData as a field within the data object of the successful response.In direct functions (
mcp-server/src/core/direct-functions/*) that call core functions (scripts/modules/*), ensure console output from the core function is suppressed to avoid breaking MCP JSON responses, preferably by passing anoutputFormatparameter or by wrapping the call with silent mode.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}: Use the logger wrapper pattern when passing loggers to preventmcpLog[level] is not a functionerrors; do not pass the FastMCPlogobject directly asmcpLogto core functions.
Ensure silent mode is disabled in afinallyblock to prevent it from staying enabled.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
🧠 Learnings (5)
📚 Learning: 2025-07-18T17:11:36.732Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-07-18T17:11:36.732Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : Use consistent error codes across direct function wrappers: INPUT_VALIDATION_ERROR, FILE_NOT_FOUND_ERROR, CORE_FUNCTION_ERROR, UNEXPECTED_ERROR.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Use numeric IDs for direct task references
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to {scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js} : Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors; do not pass the FastMCP `log` object directly as `mcpLog` to core functions.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:11:36.732Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-07-18T17:11:36.732Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : Use log.info() for progress indication within direct functions instead of reportProgress.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to mcp-server/src/core/utils/path-utils.js : Call `findTasksJsonPath(args, log)` from within direct function wrappers in `mcp-server/src/core/direct-functions/` to get the absolute path to the relevant `tasks.json`.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
🧬 Code graph analysis (3)
mcp-server/src/core/direct-functions/update-task-by-id.js (5)
mcp-server/src/core/direct-functions/update-subtask-by-id.js (7)
errorMessage(42-42)errorMessage(52-53)errorMessage(62-63)errorMessage(74-74)errorMessage(84-84)logWrapper(33-33)successMessage(133-133)mcp-server/src/core/direct-functions/set-task-status.js (4)
errorMessage(36-36)errorMessage(46-47)errorMessage(56-57)taskId(69-69)scripts/modules/utils.js (3)
taskId(900-900)id(940-940)id(1019-1019)mcp-server/src/core/direct-functions/add-dependency.js (1)
taskId(67-68)mcp-server/src/core/direct-functions/remove-dependency.js (1)
taskId(65-66)
packages/tm-bridge/src/update-bridge.ts (4)
mcp-server/src/core/direct-functions/update-task-by-id.js (6)
args(32-33)errorMessage(44-44)errorMessage(54-55)errorMessage(64-65)errorMessage(82-82)taskId(74-74)mcp-server/src/core/direct-functions/update-subtask-by-id.js (6)
args(31-31)errorMessage(42-42)errorMessage(52-53)errorMessage(62-63)errorMessage(74-74)errorMessage(84-84)scripts/modules/task-manager/update-task-by-id.js (4)
projectRoot(89-89)report(67-74)isMCP(64-64)loadingIndicator(322-322)scripts/modules/task-manager/update-subtask-by-id.js (4)
projectRoot(91-91)report(57-64)isMCP(54-54)loadingIndicator(66-66)
packages/tm-core/src/modules/storage/adapters/api-storage.ts (2)
packages/tm-core/src/modules/storage/utils/api-client.ts (1)
ApiClient(24-146)packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
AuthManager(26-286)
🔇 Additional comments (5)
mcp-server/src/core/direct-functions/update-task-by-id.js (2)
73-88: ID normalization correctly addresses past feedback.The numeric-to-string conversion at line 80 properly addresses the previous review comment. The flexible ID validation (supporting numeric, alphanumeric, and subtask formats) is appropriate for a generic update function, with format validation delegated to the core function.
140-141: Logging correctly uses standard level.The change to
logWrapper.infoproperly addresses the previous feedback about avoiding non-standard logger levels.packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts (1)
375-389: LGTM! Clear error guidance for unsupported feature.The method correctly implements the IStorage contract by throwing a descriptive error that guides users to handle AI processing client-side before calling updateTask(). Parameter naming with underscore prefixes appropriately signals unused parameters.
packages/tm-core/src/common/interfaces/storage.interface.ts (1)
78-93: LGTM! Interface and abstract signatures are now aligned.The updateTaskWithPrompt method signatures match correctly between IStorage and BaseStorage, including all parameter types and the mode option. Documentation clearly distinguishes this AI-powered method from the direct updateTask method.
Also applies to: 251-256
packages/tm-core/src/modules/storage/adapters/api-storage.ts (1)
889-916: API client initialization is clean; ensure environment variable is documented.The getApiClient method correctly initializes the ApiClient on-demand with proper auth context. Ensure that
TM_PUBLIC_BASE_DOMAIN(orTM_BASE_DOMAIN) is documented in setup/configuration guides.
2aa289c to
5841685
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
scripts/modules/task-manager/update-task-by-id.js (1)
106-124: Normalize remote result to match local return shape.The remote pathway returns
{ success, taskId, message, telemetryData, tagInfo }while the local file-based path (lines 427-431, 551-555) returns{ updatedTask, telemetryData, tagInfo }. This signature mismatch can break downstream callers expecting theupdatedTaskfield.Normalize the return at line 121:
- if (remoteResult) { - return remoteResult; - } + if (remoteResult) { + // Normalize to local-return shape to keep callers stable + return { + updatedTask: null, // Remote doesn't return full task object + telemetryData: remoteResult.telemetryData ?? null, + tagInfo: remoteResult.tagInfo ?? null, + message: remoteResult.message, + success: remoteResult.success, + taskId: remoteResult.taskId + }; + }This ensures consistent return shapes across both code paths.
packages/tm-core/src/modules/storage/adapters/api-storage.ts (1)
524-592: Include tag parameter in API request.The
tagparameter is accepted throughout the call chain but never sent to the API endpoint. At line 544, the request body only includes{ prompt, mode }.Include tag when provided:
const result = await apiClient.patch<UpdateTaskWithPromptResponse>( `/ai/api/v1/tasks/${taskId}/prompt`, - { prompt, mode } + { prompt, mode, ...(tag ? { tag } : {}) } );This ensures the backend receives the tag context if specified by the caller.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
mcp-server/src/core/direct-functions/update-task-by-id.js(5 hunks)packages/tm-bridge/README.md(1 hunks)packages/tm-bridge/src/update-bridge.ts(1 hunks)packages/tm-bridge/tsconfig.json(1 hunks)packages/tm-core/src/common/interfaces/storage.interface.ts(3 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/api-storage.ts(5 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts(2 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-service.ts(1 hunks)packages/tm-core/src/modules/tasks/tasks-domain.ts(1 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/tm-bridge/README.md
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
- packages/tm-bridge/src/update-bridge.ts
- packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts
- packages/tm-core/src/modules/tasks/tasks-domain.ts
🧰 Additional context used
📓 Path-based instructions (14)
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/update-task-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/task-manager/update-task-by-id.jsmcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/core/direct-functions/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
mcp-server/src/core/direct-functions/*.js: Direct function files in mcp-server/src/core/direct-functions/.js must implement silent mode using enableSilentMode and disableSilentMode from scripts/modules/utils.js, and always restore silent mode state using a try/finally block.
Direct function parameters in mcp-server/src/core/direct-functions/.js must match the corresponding core function signatures; do not add extra parameters not present in the core function.
Always use the isSilentMode() function to check silent mode state in mcp-server/src/core/direct-functions/*.js; do not access global variables like silentMode directly.
mcp-server/src/core/direct-functions/*.js: Check that all helper functions your direct function needs are properly exported from their source modules and import these dependencies explicitly at the top of your file in direct functions.
Verify the signature of core functions you're calling in direct functions and ensure all required parameters are provided, passing explicit values for required parameters rather than relying on defaults.
Use path.join() instead of string concatenation for file paths, and follow established file naming conventions (e.g., 'task_001.txt') in direct functions.
Wrap core function calls and AI calls in try/catch blocks in direct functions, log errors with appropriate severity and context, and return standardized error objects with code and message.
When calling a core function from a direct function, pass the log object provided by FastMCP wrapped in the standard logWrapper object as the mcpLog property in the options argument.
Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output that isn't reliably controlled by passing { mcpLog } or an outputFormat parameter.
Do not wrap calls to the unified AI service (generateTextService, generateObjectService) in silent mode; their logging is handled internal...
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/{tools,core/direct-functions}/*.js
📄 CodeRabbit inference engine (.cursor/rules/mcp.mdc)
mcp-server/src/{tools,core/direct-functions}/*.js: Use kebab-case for all file names in mcp-server/src/tools/ and mcp-server/src/core/direct-functions/.
Use helpers from mcp-server/src/tools/utils.js, mcp-server/src/core/utils/path-utils.js, and mcp-server/src/core/utils/ai-client-utils.js for centralized utilities.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
mcp-server/src/core/direct-functions/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
mcp-server/src/core/direct-functions/**/*.js: Direct function wrappers in mcp-server/src/core/direct-functions/ must call the corresponding core logic function, passing commandName and outputType: 'mcp' in the context, and outputFormat: 'json' if supported.
Direct function wrappers in mcp-server/src/core/direct-functions/ must include coreResult.telemetryData as a field within the data object of the successful response.In direct functions (
mcp-server/src/core/direct-functions/*) that call core functions (scripts/modules/*), ensure console output from the core function is suppressed to avoid breaking MCP JSON responses, preferably by passing anoutputFormatparameter or by wrapping the call with silent mode.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
{scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js}: Use the logger wrapper pattern when passing loggers to preventmcpLog[level] is not a functionerrors; do not pass the FastMCPlogobject directly asmcpLogto core functions.
Ensure silent mode is disabled in afinallyblock to prevent it from staying enabled.
Files:
mcp-server/src/core/direct-functions/update-task-by-id.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
**/?(*.)+(spec|test).ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
In JavaScript/TypeScript projects using Jest, test files should match *.test.ts and *.spec.ts patterns
Files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
{packages/*/src/**/*.spec.ts,apps/*/src/**/*.spec.ts}
📄 CodeRabbit inference engine (CLAUDE.md)
Place package and app unit test files alongside source as *.spec.ts under src (packages//src//.spec.ts or apps//src//.spec.ts)
Files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
{packages/*/src/**/*.@(spec|test).ts,apps/*/src/**/*.@(spec|test).ts,packages/*/tests/**/*.@(spec|test).ts,apps/*/tests/**/*.@(spec|test).ts,tests/unit/packages/*/**/*.@(spec|test).ts}
📄 CodeRabbit inference engine (CLAUDE.md)
{packages/*/src/**/*.@(spec|test).ts,apps/*/src/**/*.@(spec|test).ts,packages/*/tests/**/*.@(spec|test).ts,apps/*/tests/**/*.@(spec|test).ts,tests/unit/packages/*/**/*.@(spec|test).ts}: Do not use async/await in test functions unless the test is explicitly exercising asynchronous behavior
Use synchronous top-level imports in tests; avoid dynamic await import()
Keep test bodies synchronous whenever possible
Files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
🧠 Learnings (14)
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.jspackages/tm-core/src/modules/tasks/services/task-service.ts
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Allow numeric subtask IDs to reference other subtasks within the same parent
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:45.690Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:45.690Z
Learning: Applies to scripts/modules/dependency-manager.js : Use numeric IDs for direct task references
Applied to files:
scripts/modules/task-manager/update-task-by-id.jsmcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Subtasks must use consistent properties, maintain simple numeric IDs unique within the parent task, and must not duplicate parent task properties.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:11:36.732Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-07-18T17:11:36.732Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : The *Direct function is responsible for finding the exact tasks.json path using findTasksJsonPath, relying on the projectRoot passed in args.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to {scripts/modules/utils.js,mcp-server/src/core/direct-functions/**/*.js} : Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors; do not pass the FastMCP `log` object directly as `mcpLog` to core functions.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to mcp-server/src/core/utils/path-utils.js : Call `findTasksJsonPath(args, log)` from within direct function wrappers in `mcp-server/src/core/direct-functions/` to get the absolute path to the relevant `tasks.json`.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/task-manager.js : Features that create, read, update, or delete tasks belong in 'scripts/modules/task-manager.js'.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Use tagged task system aware functions for task finding and manipulation, handle both task and subtask operations, and validate task IDs before operations.
Applied to files:
mcp-server/src/core/direct-functions/update-task-by-id.js
📚 Learning: 2025-09-26T19:10:32.906Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: tsconfig.json:22-28
Timestamp: 2025-09-26T19:10:32.906Z
Learning: In the eyaltoledano/claude-task-master repository, all internal tm/ package path mappings in tsconfig.json consistently point to TypeScript source files (e.g., "./packages/*/src/index.ts") rather than built JavaScript. This is intentional architecture because tsdown bundles internal packages directly from source during build time, eliminating the need for separate compilation of internal packages.
Applied to files:
packages/tm-bridge/tsconfig.json
📚 Learning: 2025-09-26T19:05:47.555Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Applied to files:
packages/tm-bridge/tsconfig.json
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Do not import real AI service clients in tests; create fully mocked versions that return predictable responses.
Applied to files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Applied to files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Applied to files:
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts
🧬 Code graph analysis (4)
scripts/modules/task-manager/update-task-by-id.js (3)
scripts/modules/task-manager/update-subtask-by-id.js (2)
projectRoot(91-91)remoteResult(99-109)src/utils/path-utils.js (3)
projectRoot(137-137)findProjectRoot(55-115)tag(398-398)packages/tm-bridge/src/update-bridge.ts (1)
tryUpdateViaRemote(49-183)
mcp-server/src/core/direct-functions/update-task-by-id.js (2)
mcp-server/src/core/utils/path-utils.js (1)
findTasksPath(214-216)src/utils/path-utils.js (1)
findTasksPath(124-189)
packages/tm-core/src/modules/storage/adapters/api-storage.ts (2)
packages/tm-core/src/modules/storage/utils/api-client.ts (1)
ApiClient(24-146)packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
AuthManager(26-286)
packages/tm-core/src/modules/tasks/services/task-service.ts (2)
mcp-server/src/core/direct-functions/update-task-by-id.js (1)
taskId(65-65)scripts/modules/dependency-manager.js (1)
taskIdStr(383-383)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (17)
packages/tm-bridge/tsconfig.json (1)
1-37: Configuration looks solid for the new @tm/bridge package.The tsconfig is well-structured with appropriate ES2022 target, NodeNext module resolution, and comprehensive strict mode settings. The include/exclude patterns and output configuration align with the repository's conventions for TypeScript packages that are bundled by tsdown at build time.
Minor note: Lines 14–24 explicitly re-declare strict-mode options that are already included by the "strict" flag on line 13. While this adds documentation clarity, it's technically redundant. This is fine to keep as-is if the team prefers explicit option declaration for visibility; otherwise, removing them is acceptable.
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts (2)
6-8: LGTM! Import changes align with project conventions.The consolidation to a default fs import and the type-only import for PartialConfiguration correctly prevent runtime resolution issues in vitest.
36-46: LGTM! Mock data properly reflects expanded configuration.The expanded storage properties align with the enhanced configuration interface and provide better test coverage.
packages/tm-core/src/common/interfaces/storage.interface.ts (2)
78-94: LGTM! Interface and abstract signatures properly aligned.The updateTaskWithPrompt method signatures in both IStorage and BaseStorage now match correctly, with all options (useResearch and mode) included in both declarations.
251-256: LGTM! Abstract declaration matches interface.The BaseStorage abstract method signature correctly mirrors the IStorage interface declaration.
scripts/modules/task-manager/update-task-by-id.js (2)
79-93: LGTM! Input validation and project root determination strengthened.The early validation of taskId and explicit projectRoot determination improve robustness and provide clearer error messages.
135-146: LGTM! Strict numeric ID validation for file storage.The validation correctly enforces that file storage requires strictly numeric IDs and provides helpful error messages guiding users to appropriate alternatives for other ID formats.
packages/tm-core/src/modules/tasks/services/task-service.ts (2)
508-560: LGTM! Well-structured direct task update method.The method follows service-layer best practices:
- Validates storage initialization
- Resolves active tag appropriately
- Normalizes taskId to string
- Preserves user-facing errors (NO_BRIEF_SELECTED) without wrapping
- Wraps other errors with detailed context
562-625: LGTM! AI-powered update method properly structured.The implementation correctly:
- Validates storage and initializes if needed
- Resolves tag from provided or active context
- Delegates to storage layer with all options
- Handles errors appropriately (preserves TaskMasterError, wraps others with context)
packages/tm-core/src/modules/storage/adapters/api-storage.ts (3)
52-66: LGTM! Response interface properly typed.The UpdateTaskWithPromptResponse interface correctly models the expected API response structure.
79-80: LGTM! Private fields appropriately declared.The apiClient and logger fields are correctly scoped as private for internal use.
889-916: LGTM! API client initialization properly centralized.The getApiClient helper correctly:
- Lazily initializes the client
- Validates environment configuration
- Ensures brief context is selected
- Passes required auth and account context
mcp-server/src/core/direct-functions/update-task-by-id.js (5)
50-50: LGTM! Error codes properly standardized.The error codes have been correctly unified to
INPUT_VALIDATION_ERRORfor all input validation failures, which aligns with the coding guidelines for consistent error handling across direct function wrappers.As per coding guidelines.
Also applies to: 60-60, 77-77, 90-90
64-79: LGTM! ID parsing logic is robust.The ID validation correctly handles strings (including numeric, alphanumeric, and subtask IDs), converts numbers to strings for consistency, and properly rejects invalid types with appropriate error messages. This addresses the previous review feedback about normalizing numeric IDs.
101-104: LGTM! Silent mode handling is correct.The silent mode implementation properly uses
isSilentMode()to check state, enables silent mode when needed, and reliably restores the previous state using try/finally blocks, following the coding guidelines exactly.As per coding guidelines.
Also applies to: 165-168, 172-172
142-142: LGTM! Logger level corrected.The change from
logWrapper.successtologWrapper.infocorrectly addresses the previous review feedback about using standard logger levels, preventing potential runtime errors.
13-13: No issues found—the import change is correct.The function name change from
findTasksJsonPathtofindTasksPathis intentional and valid. The script output confirms that:
findTasksPathis the canonical function exported at line 214 in path-utils.jsfindTasksJsonPathexists as a backward-compatible alias (line 255)findTasksPathis used consistently across all direct functions with correct parametersUsing the primary function name
findTasksPathdirectly is cleaner than using the alias. The implementation aligns with the updated path resolution strategy.
| // Resolve tasks.json path - use provided or find it | ||
| const tasksPath = | ||
| tasksJsonPath || | ||
| findTasksPath({ projectRoot, file: args.file }, logWrapper); | ||
| if (!tasksPath) { | ||
| const errorMessage = 'tasks.json path could not be resolved.'; | ||
| logWrapper.error(errorMessage); | ||
| return { | ||
| success: false, | ||
| error: { code: 'INPUT_VALIDATION_ERROR', message: errorMessage } | ||
| }; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
Verify args.file is a valid parameter.
The path resolution logic is correct, but line 84 references args.file, which is not declared in the function signature (line 33) or mentioned in the JSDoc (lines 15-29). Confirm whether file is a valid optional argument that should be added to the destructuring and documentation, or if it should be removed from the findTasksPath call.
🏁 Script executed:
#!/bin/bash
# Check if 'file' parameter is used elsewhere in direct functions and in the path-utils implementation
echo "=== Checking if 'file' is used in other direct functions ==="
rg -n -C3 "args\.file|file:" mcp-server/src/core/direct-functions/
echo -e "\n=== Checking findTasksPath implementation for 'file' parameter usage ==="
ast-grep --pattern $'function findTasksPath($$$) {
$$$
}'Length of output: 11752
Add args.file to JSDoc and function parameters.
The code correctly passes args.file to findTasksPath, matching the pattern used in show-task.js. However, args.file is not documented in the JSDoc or destructured in the function signature. Add the parameter to line 15-29 JSDoc with the description: * @param {string} [args.file] - Optional path to the tasks file (passed to findTasksPath). and include file in the destructured parameters at line 33.
🤖 Prompt for AI Agents
In mcp-server/src/core/direct-functions/update-task-by-id.js around lines 15–33
and 81–92, add missing documentation and parameter for args.file: update the
JSDoc block (lines ~15–29) to include the new tag "* @param {string} [args.file]
- Optional path to the tasks file (passed to findTasksPath)." and then include
file in the function's destructured parameters at line ~33 (e.g., add file to
the existing args destructuring) so that args.file is documented and available
when calling findTasksPath.
This PR was automatically generated to update documentation based on recent changes. Original commit: feat: update task remote (#1345)\n\n\n Co-authored-by: Claude <claude-assistant@anthropic.com>
What type of PR is this?
Description
Related Issues
How to Test This
# Example commands or stepsExpected result:
Contributor Checklist
npm run changesetnpm testnpm run format-check(ornpm run formatto fix)Changelog Entry
For Maintainers
Summary by CodeRabbit
New Features
Chores