Skip to content

feat: update task remote#1345

Merged
Crunchyman-ralph merged 7 commits intonextfrom
ralph/feat/update.task.remote.quick
Oct 25, 2025
Merged

feat: update task remote#1345
Crunchyman-ralph merged 7 commits intonextfrom
ralph/feat/update.task.remote.quick

Conversation

@Crunchyman-ralph
Copy link
Collaborator

@Crunchyman-ralph Crunchyman-ralph commented Oct 24, 2025

What type of PR is this?

  • 🐛 Bug fix
  • ✨ Feature
  • 🔌 Integration
  • 📝 Docs
  • 🧹 Refactor
  • Other:

Description

Related Issues

How to Test This

# Example commands or steps

Expected result:

Contributor Checklist

  • Created changeset: npm run changeset
  • Tests pass: npm test
  • Format check passes: npm run format-check (or npm run format to fix)
  • Addressed CodeRabbit comments (if any)
  • Linked related issues (if any)
  • Manually tested the changes

Changelog Entry


For Maintainers

  • PR title follows conventional commits
  • Target branch correct
  • Labels added
  • Milestone assigned (if applicable)

Summary by CodeRabbit

  • New Features

    • AI-powered task updates via natural-language prompts — remote-first delegation with local fallback.
    • CLI/tools accept flexible task IDs (numeric, alphanumeric, label-number, subtask forms).
    • Temporary bridge and lightweight API client enable remote AI updates during migration.
    • Task update API now supports prompt-based update modes (append/update/rewrite).
  • Chores

    • Modernized Node.js fs imports and aligned tests.
    • JSON output mode omits verbose task details for concise exports.

@changeset-bot
Copy link

changeset-bot bot commented Oct 24, 2025

⚠️ No Changeset found

Latest commit: 5841685

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 24, 2025

Walkthrough

Adds 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

Cohort / File(s) Summary
Bridge package (new)
packages/tm-bridge/README.md, packages/tm-bridge/package.json, packages/tm-bridge/src/index.ts, packages/tm-bridge/src/update-bridge.ts, packages/tm-bridge/tsconfig.json
New temporary bridge exposing tryUpdateViaRemote and types; delegates updates to tm-core when storage is API, provides CLI UI/telemetry, and falls back to local file updates.
Storage API + client
packages/tm-core/src/modules/storage/utils/api-client.ts, packages/tm-core/src/modules/storage/adapters/api-storage.ts
Added ApiClient utility and ApiStorage support for updateTaskWithPrompt (PATCH /ai/api/v1/tasks/{taskId}/prompt), response validation, logging, and TaskMasterError wrapping.
File storage (explicit unsupported)
packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts, packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
Added updateTaskWithPrompt that throws unsupported error; adjusted fs imports and constant references in file operations.
Storage interface
packages/tm-core/src/common/interfaces/storage.interface.ts
Added updateTaskWithPrompt(...) to IStorage and abstract BaseStorage.
Task service & domain
packages/tm-core/src/modules/tasks/services/task-service.ts, packages/tm-core/src/modules/tasks/tasks-domain.ts
Added updateTask and updateTaskWithPrompt on TaskService and delegating methods on TasksDomain; includes tag resolution, id normalization, and TaskMasterError wrapping.
CLI & MCP direct functions
mcp-server/src/core/direct-functions/update-task-by-id.js, mcp-server/src/core/direct-functions/update-subtask-by-id.js, scripts/modules/commands.js, scripts/modules/task-manager/update-task-by-id.js, scripts/modules/task-manager/update-subtask-by-id.js
Relaxed ID validation to accept numeric and label-number formats; integrated tryUpdateViaRemote remote-update attempt with early-return on success and fallback to legacy local update logic; minor logging/comment updates.
List tasks command & tests
scripts/modules/task-manager/list-tasks.js, tests/unit/scripts/modules/task-manager/list-tasks.test.js
listTasks made async, integrated tm-core listing with legacy fallback, strips details in JSON output; tests updated to mock @tm/core and use async assertions.
FS import consolidation
packages/tm-core/src/modules/config/services/config-loader.service.ts, packages/tm-core/src/modules/config/services/config-persistence.service.ts, packages/tm-core/src/modules/config/services/runtime-state-manager.service.ts, packages/tm-core/src/modules/reports/managers/complexity-report-manager.ts, packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts, packages/tm-core/src/modules/workflow/managers/workflow-state-manager.ts, packages/tm-core/src/modules/storage/adapters/file-storage/file-operations.ts
Replaced various import { promises as fs } from 'node:fs' with import fs from 'node:fs/promises' (and adjusted a few constants/usages).
Tests & test data typing
packages/tm-core/src/modules/config/services/config-persistence.service.spec.ts, packages/tm-core/src/modules/config/services/config-loader.service.spec.ts, packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
Switched fs imports in tests, added PartialConfiguration typing for mocks, expanded mock config shape, and renamed activeTagcurrentTag in runtime-state tests.
Auth visibility
packages/tm-core/src/modules/auth/managers/auth-manager.ts
Changed supabaseClient visibility from private to public.
TS config / paths
tsconfig.json
Added path mappings for @tm/bridge to enable imports of the new package.
Direct-function tweaks
mcp-server/src/core/direct-functions/update-subtask-by-id.js
Simplified internal note to reference bridge script and precomputed parentId usage in returned object.

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
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~75 minutes

Areas to focus review on:

  • packages/tm-bridge/src/update-bridge.ts — tm-core creation/preflight, delegation/fallback semantics, UI/indicator lifecycle.
  • scripts/modules/task-manager/update-task-by-id.js and update-subtask-by-id.js — ID normalization, remote vs local branching, early-return semantics.
  • packages/tm-core/src/modules/storage/adapters/api-storage.ts and packages/tm-core/src/modules/storage/utils/api-client.ts — auth/session expectations, request/error mapping, and TaskMasterError metadata.
  • scripts/modules/task-manager/list-tasks.js and tests — tm-core integration, fallback correctness, and JSON output modifications.
  • packages/tm-core/src/common/interfaces/storage.interface.ts and FileStorage — ensure added method signatures align and unsupported-file-storage behavior is clear.

Possibly related PRs

Suggested reviewers

  • eyaltoledano

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Title Check ❓ Inconclusive The PR title "feat: update task remote" is related to the changeset, as the changes do introduce remote task update capabilities through a new bridge package, API storage implementation, and integration with the task update workflow. However, the term "remote" is somewhat vague and could benefit from greater specificity. Without additional context, a developer scanning the git history may not immediately understand what concrete capability is being added—whether it refers to delegating updates to a remote API, supporting cloud-based task storage, or something else. The title captures a real aspect of the change but lacks clarity about what "remote" specifically means in this implementation. Consider revising the title to be more explicit about the feature being added, such as "feat: support AI-powered task updates with remote API delegation" or "feat: add prompt-based task updates via API storage." This would make the purpose and scope of the change clearer to reviewers and future maintainers scanning the commit history.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch ralph/feat/update.task.remote.quick

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 uses currentTag as the field name. This test will fail when setCurrentTag is called since the saved JSON will contain currentTag, not activeTag.

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 storage

Move 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 storage

Add 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 update
tests/unit/scripts/modules/task-manager/list-tasks.test.js (2)

80-141: Deduplicate fixtures to keep tests consistent

Prefer 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 brittleness

Avoid 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 set

Use 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 logger

Use 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 formatting

addComplexityToTask 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

📥 Commits

Reviewing files that changed from the base of the PR and between 03b7ef9 and 7d64fac.

📒 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 through generateTextService or generateObjectService.
Do not import or call anything from the old ai-services.js, ai-client-factory.js, or ai-client-utils.js files.
Do not fetch AI-specific parameters (model ID, max tokens, temp) using config-manager.js getters for the AI call. Pass the role instead.
Do not implement fallback or retry logic outside ai-services-unified.js.
Do not handle API key resolution outside the service layer (it uses utils.js internally).
Determine the appropriate role (main, research, fallback) in your core logic and pass it to the service.
Pass the session object (received in the context parameter, especially from direct function wrappers) to the service call when in MCP context.
Use generateTextService and implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, as generateObjectService has shown unreliability with some providers/schemas.
Be aware of potential reliability issues with generateObjectService across different providers and complex schemas. Prefer generateTextService + 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/modules or MCP tool/direct function definitions change.

Files:

  • scripts/modules/commands.js
  • scripts/modules/task-manager/update-task-by-id.js
  • scripts/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.js
  • mcp-server/src/core/direct-functions/update-task-by-id.js
  • tests/unit/scripts/modules/task-manager/list-tasks.test.js
  • mcp-server/src/core/direct-functions/update-subtask-by-id.js
  • scripts/modules/task-manager/update-task-by-id.js
  • scripts/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.js
  • mcp-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.js
  • mcp-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 an outputFormat parameter or by wrapping the call with silent mode.

Files:

  • mcp-server/src/core/direct-functions/update-task-by-id.js
  • mcp-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 prevent mcpLog[level] is not a function errors; do not pass the FastMCP log object directly as mcpLog to core functions.
Ensure silent mode is disabled in a finally block to prevent it from staying enabled.

Files:

  • mcp-server/src/core/direct-functions/update-task-by-id.js
  • mcp-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.ts
  • packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
  • tests/unit/scripts/modules/task-manager/list-tasks.test.js
  • 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-loader.service.spec.ts
  • packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
  • tests/unit/scripts/modules/task-manager/list-tasks.test.js
  • 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-loader.service.spec.ts
  • packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
  • 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-loader.service.spec.ts
  • packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
  • 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-loader.service.spec.ts
  • packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts
  • packages/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 through generateTextService or generateObjectService.
Do not import or call anything from the old ai-services.js, ai-client-factory.js, or ai-client-utils.js files.
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) using config-manager.js getters for the AI call. Pass the role instead.
Do not implement fallback or retry logic outside ai-services-unified.js.
Do not handle API key resolution outside the service layer (it uses utils.js internally).
Determine the appropriate role (main, research, fallback) in your core logic and pass it to the service.
Pass the session object (received in the context parameter, especially from direct function wrappers) to the service call when in MCP context.
Use generateTextService and implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, as generateObjectService has shown unreliability with some providers/schemas.
Be aware of potential reliability issues with generateObjectService across different providers and complex schemas. Prefer generateTextService + 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/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.js
  • scripts/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 in scripts/modules/task-manager/*; instead, pass the role to the unified AI service.

Files:

  • scripts/modules/task-manager/update-task-by-id.js
  • scripts/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.ts
  • packages/tm-core/src/modules/tasks/tasks-domain.ts
  • mcp-server/src/core/direct-functions/update-task-by-id.js
  • mcp-server/src/core/direct-functions/update-subtask-by-id.js
  • 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/commands.js
  • tests/unit/scripts/modules/task-manager/list-tasks.test.js
  • 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 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.js
  • 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:

  • 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.js
  • 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 : 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.ts
  • tests/unit/scripts/modules/task-manager/list-tasks.test.js
  • packages/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.ts
  • 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 : 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.js
  • 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 : 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.js
  • scripts/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.js
  • 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 : 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' to import 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/promises as 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/promises for 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 activeTag to currentTag throughout the service API and state structure.


161-270: LGTM! Test updates align with API rename.

The remaining test updates correctly use getCurrentTag and setCurrentTag methods and verify currentTag in 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 updateWithPrompt to 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/promises for 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 call getSession(). The change from private to public is 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 createTmCore function is an async static factory method that creates an instance and awaits instance.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 time tmCore.tasks.getStorageType() is called, the storage layer is already initialized. Additionally, the getStorageType() 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 solid

Good 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 it

See interface/BaseStorage mismatch; fix in BaseStorage (separate comment).


524-613: No duplication found—review comment is incorrect

Verification shows only one updateTaskWithPrompt method 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 dismissed

The 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 fallback

Initialization + fallback to readJSON is well‑structured; good resilience without breaking existing flows.


241-260: JSON: details stripping looks correct

Filtering first, then omitting details (including subtask details) yields a lean JSON payload. Matches tests.

- add bridge package to bridge tm core and legacy scripts
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

createLogWrapper typically exposes standard levels (info/warn/error/debug). Use logWrapper.info to avoid runtime errors.

-      logWrapper.success(successMessage);
+      logWrapper.info(successMessage);

73-88: Normalize numeric IDs to strings.

When id is 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

📥 Commits

Reviewing files that changed from the base of the PR and between 7d64fac and 1ff8e39.

⛔ Files ignored due to path filters (1)
  • package-lock.json is 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 through generateTextService or generateObjectService.
Do not import or call anything from the old ai-services.js, ai-client-factory.js, or ai-client-utils.js files.
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) using config-manager.js getters for the AI call. Pass the role instead.
Do not implement fallback or retry logic outside ai-services-unified.js.
Do not handle API key resolution outside the service layer (it uses utils.js internally).
Determine the appropriate role (main, research, fallback) in your core logic and pass it to the service.
Pass the session object (received in the context parameter, especially from direct function wrappers) to the service call when in MCP context.
Use generateTextService and implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, as generateObjectService has shown unreliability with some providers/schemas.
Be aware of potential reliability issues with generateObjectService across different providers and complex schemas. Prefer generateTextService + 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.js
  • 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/modules or MCP tool/direct function definitions change.

Files:

  • scripts/modules/task-manager/update-subtask-by-id.js
  • 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-subtask-by-id.js
  • 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 in scripts/modules/task-manager/*; instead, pass the role to the unified AI service.

Files:

  • scripts/modules/task-manager/update-subtask-by-id.js
  • 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-subtask-by-id.js
  • scripts/modules/task-manager/update-task-by-id.js
  • mcp-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 an outputFormat parameter 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 prevent mcpLog[level] is not a function errors; do not pass the FastMCP log object directly as mcpLog to core functions.
Ensure silent mode is disabled in a finally block 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.js
  • scripts/modules/task-manager/update-task-by-id.js
  • packages/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.js
  • 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-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.json
  • tsconfig.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.json
  • tsconfig.json
  • packages/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/bridge follows 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 to updateTaskWithPrompt() 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 updateTask and updateTaskWithPrompt methods 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 updateTaskWithPrompt method 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 getApiClient helper 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 tryUpdateViaRemote from @tm/bridge properly 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 ApiClient class 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

@Crunchyman-ralph Crunchyman-ralph changed the title chore: fix CI feat: update task remote Oct 25, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 !== taskId can be true for 1 !== '1', leading to writing a string ID back to file. Compare to numericTaskId and 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 generateObjectService due 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 passing role: '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

📥 Commits

Reviewing files that changed from the base of the PR and between 1ff8e39 and 08c7da5.

📒 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 through generateTextService or generateObjectService.
Do not import or call anything from the old ai-services.js, ai-client-factory.js, or ai-client-utils.js files.
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) using config-manager.js getters for the AI call. Pass the role instead.
Do not implement fallback or retry logic outside ai-services-unified.js.
Do not handle API key resolution outside the service layer (it uses utils.js internally).
Determine the appropriate role (main, research, fallback) in your core logic and pass it to the service.
Pass the session object (received in the context parameter, especially from direct function wrappers) to the service call when in MCP context.
Use generateTextService and implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, as generateObjectService has shown unreliability with some providers/schemas.
Be aware of potential reliability issues with generateObjectService across different providers and complex schemas. Prefer generateTextService + 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/modules or 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 in scripts/modules/task-manager/*; instead, pass the role to 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 updateTaskWithPrompt method. This improves API clarity for consumers.


78-94: Well-designed API addition!

The new updateTaskWithPrompt method provides a clear interface for AI-powered task updates. The documentation is comprehensive, and the signature properly includes both useResearch and mode options with clear descriptions of their usage contexts.


251-257: Past review issue resolved: signatures now match!

The abstract method declaration in BaseStorage now matches the IStorage interface exactly, including the mode option that was previously flagged in the past review. Both declarations properly include options?: { 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 own package.json with ESM type, main, and exports fields. npm workspaces will automatically symlink it to node_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.

@Crunchyman-ralph Crunchyman-ralph force-pushed the ralph/feat/update.task.remote.quick branch from 08c7da5 to 2aa289c Compare October 25, 2025 14:49
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 on projectRoot, rather than requiring tasksJsonPath to 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 projectRoot is a required parameter in UpdateBridgeParams (line 14), the fallback to process.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

📥 Commits

Reviewing files that changed from the base of the PR and between 08c7da5 and 2aa289c.

📒 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 an outputFormat parameter 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 prevent mcpLog[level] is not a function errors; do not pass the FastMCP log object directly as mcpLog to core functions.
Ensure silent mode is disabled in a finally block 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.info properly 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 (or TM_BASE_DOMAIN) is documented in setup/configuration guides.

@Crunchyman-ralph Crunchyman-ralph force-pushed the ralph/feat/update.task.remote.quick branch from 2aa289c to 5841685 Compare October 25, 2025 15:05
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 the updatedTask field.

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 tag parameter 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

📥 Commits

Reviewing files that changed from the base of the PR and between 2aa289c and 5841685.

📒 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 through generateTextService or generateObjectService.
Do not import or call anything from the old ai-services.js, ai-client-factory.js, or ai-client-utils.js files.
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) using config-manager.js getters for the AI call. Pass the role instead.
Do not implement fallback or retry logic outside ai-services-unified.js.
Do not handle API key resolution outside the service layer (it uses utils.js internally).
Determine the appropriate role (main, research, fallback) in your core logic and pass it to the service.
Pass the session object (received in the context parameter, especially from direct function wrappers) to the service call when in MCP context.
Use generateTextService and implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, as generateObjectService has shown unreliability with some providers/schemas.
Be aware of potential reliability issues with generateObjectService across different providers and complex schemas. Prefer generateTextService + 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/modules or 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 in scripts/modules/task-manager/*; instead, pass the role to 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
  • mcp-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 an outputFormat parameter 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 prevent mcpLog[level] is not a function errors; do not pass the FastMCP log object directly as mcpLog to core functions.
Ensure silent mode is disabled in a finally block 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.js
  • packages/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.js
  • mcp-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_ERROR for 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.success to logWrapper.info correctly 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 findTasksJsonPath to findTasksPath is intentional and valid. The script output confirms that:

  • findTasksPath is the canonical function exported at line 214 in path-utils.js
  • findTasksJsonPath exists as a backward-compatible alias (line 255)
  • findTasksPath is used consistently across all direct functions with correct parameters

Using the primary function name findTasksPath directly is cleaner than using the alias. The implementation aligns with the updated path resolution strategy.

Comment on lines +81 to +92
// 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 }
};
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ 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.

@Crunchyman-ralph Crunchyman-ralph merged commit 486ed40 into next Oct 25, 2025
8 checks passed
github-actions bot added a commit that referenced this pull request Oct 25, 2025
  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>
@coderabbitai coderabbitai bot mentioned this pull request Nov 7, 2025
16 tasks
sfc-gh-dflippo pushed a commit to sfc-gh-dflippo/task-master-ai that referenced this pull request Dec 4, 2025
@coderabbitai coderabbitai bot mentioned this pull request Jan 11, 2026
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant