feat: add update-task to new structure#1335
Conversation
|
WalkthroughMajor reorganization of the tm-core package structure, relocating code from flat to modular Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant TmCore
participant ConfigDomain
participant TasksDomain
participant AuthDomain
participant WorkflowDomain
participant GitDomain
Client->>TmCore: createTmCore(options)
activate TmCore
TmCore->>TmCore: create(options)
TmCore->>TmCore: new TmCore(options)
TmCore->>TmCore: initialize()
TmCore->>ConfigDomain: new ConfigDomain(configManager)
TmCore->>TasksDomain: new TasksDomain(configManager)
TmCore->>AuthDomain: new AuthDomain()
TmCore->>WorkflowDomain: new WorkflowDomain(configManager)
TmCore->>GitDomain: new GitDomain(projectPath)
Note over TmCore: Initialize async domains
TmCore->>TasksDomain: initialize()
activate TasksDomain
TasksDomain-->>TmCore: ready
deactivate TasksDomain
TmCore-->>Client: TmCore instance
deactivate TmCore
Client->>TmCore: tasks.list()
TmCore->>TasksDomain: list(options)
TasksDomain-->>Client: TaskListResult
Client->>TmCore: auth.getCredentials()
TmCore->>AuthDomain: getCredentials()
AuthDomain-->>Client: AuthCredentials
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Reasoning: This is a substantial structural reorganization affecting dozens of files across the codebase. While most changes follow consistent patterns (import path refactoring, module relocation), the scope is significant: new facade/domain classes with multiple delegating methods, comprehensive public API surface reorganization, and widespread import path updates. The systematic nature of changes (homogeneous refactoring patterns repeated across modules) mitigates some complexity, but reviewers must verify correct path resolution across all relocated modules, ensure facade delegation patterns are correctly implemented, and validate that the new unified entry point (TmCore) properly initializes and wires all domain components. Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/tm-core/src/modules/auth/services/credential-store.test.ts (1)
24-26: Fix the mock import path to match the actual import.The mock uses
'../logger/index.js'but the actual code incredential-store.ts(line 9) imports from'../../../common/logger/index.js'. This path mismatch will cause the mock to fail.Apply this diff to fix the mock path:
-vi.mock('../logger/index.js', () => ({ +vi.mock('../../../common/logger/index.js', () => ({ getLogger: () => mockLogger }));packages/tm-core/src/modules/config/managers/config-manager.spec.ts (1)
16-20: Critical: Mock paths don't match import paths.The mock paths use
'./services/...'but the actual imports (lines 9-13) use'../services/...'. This mismatch means the mocks won't intercept the real module imports, causing the tests to fail or test actual implementations instead of mocks.Apply this diff to fix the mock paths:
// Mock all services -vi.mock('./services/config-loader.service.js'); -vi.mock('./services/config-merger.service.js'); -vi.mock('./services/runtime-state-manager.service.js'); -vi.mock('./services/config-persistence.service.js'); -vi.mock('./services/environment-config-provider.service.js'); +vi.mock('../services/config-loader.service.js'); +vi.mock('../services/config-merger.service.js'); +vi.mock('../services/runtime-state-manager.service.js'); +vi.mock('../services/config-persistence.service.js'); +vi.mock('../services/environment-config-provider.service.js');
🧹 Nitpick comments (6)
packages/tm-core/src/modules/dependencies/index.ts (1)
1-8: Placeholder structure is appropriate for the modular refactoring.This placeholder correctly scaffolds the dependencies domain module as part of the broader tm-core reorganization. The JSDoc and TODO provide clear context for future migration work.
Minor suggestions for better visibility and completeness:
- Consider adding an explicit placeholder export (e.g.,
export const dependenciesDomain = {}) to ensure the module is importable without errors during the transition phase, even if consumers receive an empty object temporarily.- If other domain modules (auth, workflow, etc.) follow a similar pattern, ensure consistency in placeholder structure and export shape across all domain modules.
packages/tm-core/src/modules/commands/index.ts (1)
1-8: Clarify intent: is this placeholder ready for merge?This file contains only JSDoc and a TODO with no actual implementation or working exports. While the file signals the architectural intent for future commands migration, it doesn't provide value until the migration work is completed.
Consider deferring this file until:
- The migration from
scripts/modules/commands.jsis ready to implement, or- At least a stub
command-handleror working re-export is in place to unblock dependent codeIf the broader modular restructuring requires this placeholder as a scaffold for parallel work, clarify this intent in a comment or document so reviewers understand why WIP scaffolding is being merged.
packages/tm-core/src/modules/tasks/repositories/supabase/dependency-fetcher.ts (1)
2-3: <!-- [scratchpad_update]
[task review_file_1/1 verification_2/3][observations - web search results]
- Deep relative imports like
../../../../are widely recognized as anti-pattern in TypeScript- Multiple sources recommend path aliases (tsconfig.json) or baseUrl to reduce deeply nested imports
- Sources from 2020-2025 consistently advocate against deep relative paths in large codebases
- The pattern
../../../../requires tracking directory depth and is error-prone[analysis of web search]
- Current import pattern uses deep relative path (
../../../../common/types/...)- This is explicitly discouraged in modern TypeScript best practices
- The project may benefit from path aliases instead of deep relative imports
- However, the import path IS correct and the types DO exist at those locations
- The refactoring itself is not incorrect, just potentially suboptimal
[decision]
- Verification shows import path changes are valid and types exist
- All Database type imports are consistent with this new pattern
- However, should flag that deeply nested relative imports are not ideal practice
- Still need to verify: DependencyWithDisplayId imports
[scratchpad_end] -->Now let me verify the second import (DependencyWithDisplayId) to ensure complete coverage:<!-- [scratchpad_update]
[task review_file_1/1 verification_3/3 complete][observations - final]
Script output confirmed:
- Type files exist at new paths: database.types.ts and repository-types.ts ✓
- Database import is consistent and correct across files ✓
- DependencyWithDisplayId type comes from ../../../../common/types/repository-types.js ✓
- No old import patterns found
Web search on monorepo patterns shows:
- Deep relative imports are discouraged as anti-pattern
- Path aliases (tsconfig.json) are recommended best practice
- The codebase may be using monorepo structure (modules directory structure suggests this)
- However, relative imports ARE a valid, albeit less optimal, pattern
[analysis - final]
- ✓ Import paths are CORRECT and types exist at target locations
- ✓ Migration appears complete in this file
- ✓ All imports follow consistent pattern with correct relative paths
- ⚠ Using deep relative imports (../../../../) is not ideal from maintainability perspective
- ✓ No functional issues or breaking changes
[decision]
- Verification shows no critical issues
- Import changes are valid but could be improved with path aliases
- Should resolve the review comment with constructive note about import pattern optimization
- Upgrade to optional refactoring suggestion about considering path aliases for future
[scratchpad_end] -->Import paths correctly refactored to centralized location; consider path aliases for improved maintainability.
The import paths have been successfully migrated to
../../../../common/types/, and both target type files (database.types.tsandrepository-types.ts) exist at their new locations. The refactoring is complete and syntactically correct.However, the use of deep relative import paths (four levels of
../) adds cognitive overhead when reading and maintaining the code. While relative imports can become unwieldy as your codebase grows and files get nested very deep, consider consolidating import paths through TypeScript path aliases intsconfig.jsonas a future improvement for better maintainability.update-task-migration-plan.md (2)
255-255: Add language identifier to fenced code block.The fenced code block on line 255 is missing a language identifier, which affects syntax highlighting and markdown rendering.
Apply this change:
-``` +```text packages/tm-core/ src/
887-887: Add language identifier to fenced code block.The fenced code block on line 887 (class diagram) is missing a language identifier.
Apply this change:
-``` +```text ┌─────────────────────────┐ │ UpdateTaskService │ ◄─── Main Orchestratorpackages/tm-core/src/tm-core.ts (1)
72-90: Pattern enforces async initialization but has type-safety trade-offs.The private constructor initializes readonly domain properties to
null! as any, which bypasses TypeScript's null-safety untilinitialize()is called. While the static factory pattern ensures proper initialization in normal usage, this creates potential runtime issues if:
- Internal code accidentally calls the constructor directly
initialize()throws before setting all propertiesConsider these alternatives to strengthen type safety:
Option 1: Use assertion methods
get tasks(): TasksDomain { + if (!this._tasks) throw new Error('TmCore not initialized'); + return this._tasks; }Option 2: Use optional chaining with runtime checks
-public readonly tasks: TasksDomain; +private _tasks?: TasksDomain; +get tasks(): TasksDomain { + if (!this._tasks) throw new TaskMasterError('TmCore not initialized', ERROR_CODES.INTERNAL_ERROR); + return this._tasks; +}The current pattern works but relies on discipline to always use
TmCore.create().
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (68)
package.json(2 hunks)packages/tm-core/src/common/interfaces/index.ts(1 hunks)packages/tm-core/src/executors/index.ts(0 hunks)packages/tm-core/src/index.ts(1 hunks)packages/tm-core/src/modules/ai/index.ts(1 hunks)packages/tm-core/src/modules/ai/providers/base-provider.ts(2 hunks)packages/tm-core/src/modules/auth/auth-domain.ts(1 hunks)packages/tm-core/src/modules/auth/index.ts(1 hunks)packages/tm-core/src/modules/auth/managers/auth-manager.spec.ts(1 hunks)packages/tm-core/src/modules/auth/managers/auth-manager.ts(1 hunks)packages/tm-core/src/modules/auth/services/credential-store.test.ts(1 hunks)packages/tm-core/src/modules/auth/services/credential-store.ts(1 hunks)packages/tm-core/src/modules/auth/services/oauth-service.ts(1 hunks)packages/tm-core/src/modules/auth/services/organization.service.ts(1 hunks)packages/tm-core/src/modules/auth/services/supabase-session-storage.ts(1 hunks)packages/tm-core/src/modules/commands/index.ts(1 hunks)packages/tm-core/src/modules/config/config-domain.ts(1 hunks)packages/tm-core/src/modules/config/index.ts(2 hunks)packages/tm-core/src/modules/config/managers/config-manager.spec.ts(1 hunks)packages/tm-core/src/modules/config/managers/config-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-merger.service.ts(1 hunks)packages/tm-core/src/modules/config/services/config-persistence.service.ts(1 hunks)packages/tm-core/src/modules/config/services/environment-config-provider.service.ts(1 hunks)packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts(1 hunks)packages/tm-core/src/modules/config/services/runtime-state-manager.service.ts(1 hunks)packages/tm-core/src/modules/dependencies/index.ts(1 hunks)packages/tm-core/src/modules/execution/executors/base-executor.ts(1 hunks)packages/tm-core/src/modules/execution/executors/claude-executor.ts(1 hunks)packages/tm-core/src/modules/execution/executors/executor-factory.ts(1 hunks)packages/tm-core/src/modules/execution/index.ts(1 hunks)packages/tm-core/src/modules/execution/services/executor-service.ts(1 hunks)packages/tm-core/src/modules/execution/types.ts(1 hunks)packages/tm-core/src/modules/git/git-domain.ts(1 hunks)packages/tm-core/src/modules/git/index.ts(1 hunks)packages/tm-core/src/modules/git/services/branch-name-generator.spec.ts(1 hunks)packages/tm-core/src/modules/integration/clients/supabase-client.ts(1 hunks)packages/tm-core/src/modules/integration/services/export.service.ts(1 hunks)packages/tm-core/src/modules/reports/index.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(1 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts(1 hunks)packages/tm-core/src/modules/storage/adapters/file-storage/format-handler.ts(1 hunks)packages/tm-core/src/modules/storage/index.ts(2 hunks)packages/tm-core/src/modules/storage/services/storage-factory.ts(1 hunks)packages/tm-core/src/modules/tasks/entities/task.entity.ts(1 hunks)packages/tm-core/src/modules/tasks/parser/index.ts(1 hunks)packages/tm-core/src/modules/tasks/repositories/supabase/dependency-fetcher.ts(1 hunks)packages/tm-core/src/modules/tasks/repositories/supabase/supabase-task-repository.ts(1 hunks)packages/tm-core/src/modules/tasks/repositories/task-repository.interface.ts(1 hunks)packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-execution-service.ts(1 hunks)packages/tm-core/src/modules/tasks/services/task-loader.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/ui/index.ts(1 hunks)packages/tm-core/src/modules/workflow/managers/workflow-state-manager.spec.ts(1 hunks)packages/tm-core/src/modules/workflow/managers/workflow-state-manager.ts(1 hunks)packages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.ts(1 hunks)packages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.ts(2 hunks)packages/tm-core/src/modules/workflow/services/workflow-activity-logger.ts(1 hunks)packages/tm-core/src/modules/workflow/services/workflow.service.ts(1 hunks)packages/tm-core/src/modules/workflow/workflow-domain.ts(1 hunks)packages/tm-core/src/services/index.ts(0 hunks)packages/tm-core/src/task-master-core.ts(2 hunks)packages/tm-core/src/tm-core.ts(1 hunks)update-task-migration-plan.md(1 hunks)
💤 Files with no reviewable changes (2)
- packages/tm-core/src/executors/index.ts
- packages/tm-core/src/services/index.ts
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{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/workflow/managers/workflow-state-manager.spec.tspackages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.tspackages/tm-core/src/modules/config/managers/config-manager.spec.tspackages/tm-core/src/modules/auth/managers/auth-manager.spec.tspackages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/git/services/branch-name-generator.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/auth/services/credential-store.test.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/workflow/managers/workflow-state-manager.spec.tspackages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.tspackages/tm-core/src/modules/config/managers/config-manager.spec.tspackages/tm-core/src/modules/auth/managers/auth-manager.spec.tspackages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/git/services/branch-name-generator.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/auth/services/credential-store.test.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/workflow/managers/workflow-state-manager.spec.tspackages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.tspackages/tm-core/src/modules/config/managers/config-manager.spec.tspackages/tm-core/src/modules/auth/managers/auth-manager.spec.tspackages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/git/services/branch-name-generator.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/auth/services/credential-store.test.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/workflow/managers/workflow-state-manager.spec.tspackages/tm-core/src/modules/config/managers/config-manager.spec.tspackages/tm-core/src/modules/auth/managers/auth-manager.spec.tspackages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/git/services/branch-name-generator.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.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/workflow/managers/workflow-state-manager.spec.tspackages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.tspackages/tm-core/src/modules/config/managers/config-manager.spec.tspackages/tm-core/src/modules/auth/managers/auth-manager.spec.tspackages/tm-core/src/modules/config/services/config-loader.service.spec.tspackages/tm-core/src/modules/git/services/branch-name-generator.spec.tspackages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.tspackages/tm-core/src/modules/auth/services/credential-store.test.ts
**/*.test.ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
**/*.test.ts: Use established mocking patterns for dependencies such as bcrypt and Prisma in test files
Test all code paths, including edge cases and error scenarios, in test files
Use descriptive names for test functions, such as should_return_error_for_invalid_input
Files:
packages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.tspackages/tm-core/src/modules/auth/services/credential-store.test.ts
package.json
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Add and update test scripts in package.json to include test, test:watch, test:coverage, test:unit, test:integration, test:e2e, and test:ci
Files:
package.json
**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
Reference documentation at https://docs.task-master.dev rather than local file paths in content
Files:
update-task-migration-plan.md
🧠 Learnings (28)
📓 Common learnings
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.
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.
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Provider modules must import the provider's create<ProviderName> function from ai-sdk/<provider-name>, and import generateText, streamText, generateObject from the core ai package, as well as the log utility from ../../scripts/modules/utils.js.
Applied to files:
packages/tm-core/src/modules/ai/index.tspackages/tm-core/src/common/interfaces/index.tspackages/tm-core/src/modules/ai/providers/base-provider.ts
📚 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-core/src/modules/ai/index.tspackages/tm-core/src/modules/tasks/services/task-execution-service.tspackages/tm-core/src/modules/execution/types.tspackages/tm-core/src/task-master-core.tspackages/tm-core/src/tm-core.tspackage.jsonpackages/tm-core/src/modules/execution/executors/claude-executor.tspackages/tm-core/src/index.tspackages/tm-core/src/common/interfaces/index.ts
📚 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 src/ai-providers/*.js : Provider-specific wrappers for Vercel AI SDK functions must be implemented in src/ai-providers/*.js, each file corresponding to a provider.
Applied to files:
packages/tm-core/src/modules/ai/index.tspackages/tm-core/src/modules/ai/providers/base-provider.ts
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Provider modules must export three functions: generate<ProviderName>Text, stream<ProviderName>Text, and generate<ProviderName>Object.
Applied to files:
packages/tm-core/src/modules/ai/index.ts
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Create a new provider module file in src/ai-providers/ named <provider-name>.js when adding a new AI provider.
Applied to files:
packages/tm-core/src/modules/ai/index.tspackages/tm-core/src/modules/ai/providers/base-provider.ts
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to tests/unit/ai-providers/*.test.js : Create unit tests for the new provider in tests/unit/ai-providers/<provider-name>.test.js, mocking ai-sdk/<provider-name> and core ai module functions, and testing all exported functions for correct behavior and error handling.
Applied to files:
packages/tm-core/src/modules/ai/index.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/ai-services.js : Features that use AI models belong in 'scripts/modules/ai-services.js'.
Applied to files:
packages/tm-core/src/modules/ai/index.ts
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to scripts/modules/ai-services-unified.js : Integrate the new provider module with scripts/modules/ai-services-unified.js by importing it and adding an entry to the PROVIDER_FUNCTIONS map.
Applied to files:
packages/tm-core/src/modules/ai/index.ts
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Implement generate<ProviderName>Text, stream<ProviderName>Text, and generate<ProviderName>Object functions in provider modules with basic validation and try/catch error handling.
Applied to files:
packages/tm-core/src/modules/ai/index.ts
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/commands.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
packages/tm-core/src/modules/ai/index.ts
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
packages/tm-core/src/modules/tasks/services/task-execution-service.tspackages/tm-core/src/modules/tasks/services/task-service.tspackages/tm-core/src/task-master-core.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/dependency-manager.js : Features that handle task relationships belong in 'scripts/modules/dependency-manager.js'.
Applied to files:
packages/tm-core/src/modules/dependencies/index.ts
📚 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 graph traversal algorithms (DFS) to detect cycles
Applied to files:
packages/tm-core/src/modules/dependencies/index.ts
📚 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 : Detect circular dependencies, validate dependency references, and support cross-tag dependency checking (future enhancement) in dependency analysis utilities.
Applied to files:
packages/tm-core/src/modules/dependencies/index.ts
📚 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 : Handle both direct and indirect self-dependencies
Applied to files:
packages/tm-core/src/modules/dependencies/index.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 : Check for existing dependencies to prevent duplicates
Applied to files:
packages/tm-core/src/modules/dependencies/index.ts
📚 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:
packages/tm-core/src/modules/auth/managers/auth-manager.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
📚 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-core/src/modules/execution/types.tspackages/tm-core/src/task-master-core.tspackage.jsonpackages/tm-core/src/modules/execution/executors/claude-executor.ts
📚 Learning: 2025-10-15T14:43:40.410Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1314
File: packages/tm-core/src/auth/credential-store.ts:92-94
Timestamp: 2025-10-15T14:43:40.410Z
Learning: In the claude-task-master codebase, `getCredentials()` in `credential-store.ts` defaults to `allowExpired: true` to enable Supabase refresh flows. The Supabase client automatically handles token refresh when credentials are expired but have a valid refresh token. The `SupabaseSessionStorage` updates the credentials after Supabase performs the refresh. This is an intentional design pattern where the credential store is passive storage and Supabase manages the active token lifecycle.
Applied to files:
packages/tm-core/src/modules/auth/services/supabase-session-storage.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/commands.js : All new user-facing commands should be added to 'scripts/modules/commands.js'.
Applied to files:
packages/tm-core/src/modules/commands/index.ts
📚 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 : Export the registerCommands function and keep the CLI setup code clean and maintainable.
Applied to files:
packages/tm-core/src/modules/commands/index.ts
📚 Learning: 2025-09-26T19:03:33.225Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: package.json:130-132
Timestamp: 2025-09-26T19:03:33.225Z
Learning: In the eyaltoledano/claude-task-master repository, packages are bundled using tsdown during the build process, which means dependencies imported by the source code (including tm internal packages like tm/ai-sdk-provider-grok-cli) are included in the final bundle and don't need to be available as separate runtime dependencies, so they should remain as devDependencies rather than being moved to dependencies.
Applied to files:
package.json
📚 Learning: 2025-10-08T19:57:00.982Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1282
File: packages/tm-core/src/utils/index.ts:16-34
Timestamp: 2025-10-08T19:57:00.982Z
Learning: For the tm-core package in the eyaltoledano/claude-task-master repository, the team prefers a minimal, need-based export strategy in index files rather than exposing all internal utilities. Exports should only be added when functions are actually consumed by other packages in the monorepo.
Applied to files:
packages/tm-core/src/index.ts
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Describes the high-level architecture of the Task Master CLI application, including the new tagged task lists system (architecture.mdc).
Applied to files:
update-task-migration-plan.md
📚 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:
update-task-migration-plan.md
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not implement fallback or retry logic outside `ai-services-unified.js`.
Applied to files:
packages/tm-core/src/modules/ai/providers/base-provider.ts
🧬 Code graph analysis (5)
packages/tm-core/src/modules/workflow/workflow-domain.ts (1)
packages/tm-core/src/modules/workflow/services/workflow.service.ts (1)
WorkflowService(77-494)
packages/tm-core/src/modules/tasks/tasks-domain.ts (4)
packages/tm-core/src/modules/tasks/services/task-service.ts (1)
TaskService(51-565)packages/tm-core/src/modules/tasks/services/task-execution-service.ts (1)
TaskExecutionService(42-308)packages/tm-core/src/modules/tasks/services/task-loader.service.ts (2)
TaskLoaderService(59-401)TaskValidationResult(27-40)packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts (1)
PreflightChecker(61-395)
packages/tm-core/src/tm-core.ts (5)
packages/tm-core/src/modules/tasks/tasks-domain.ts (1)
TasksDomain(32-184)packages/tm-core/src/modules/auth/auth-domain.ts (1)
AuthDomain(17-127)packages/tm-core/src/modules/workflow/workflow-domain.ts (1)
WorkflowDomain(18-98)packages/tm-core/src/modules/git/git-domain.ts (1)
GitDomain(14-238)packages/tm-core/src/modules/config/config-domain.ts (1)
ConfigDomain(12-113)
packages/tm-core/src/modules/config/config-domain.ts (1)
packages/tm-core/src/common/interfaces/configuration.interface.ts (1)
RuntimeStorageConfig(104-119)
packages/tm-core/src/modules/git/git-domain.ts (1)
packages/tm-core/src/modules/git/services/commit-message-generator.ts (1)
CommitMessageGenerator(53-205)
🪛 LanguageTool
update-task-migration-plan.md
[grammar] ~1111-~1111: Use a hyphen to join words.
Context: ...er, FuzzyTaskSearch` - Port context gathering logic from both old files 2. ...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.18.1)
update-task-migration-plan.md
255-255: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
887-887: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (66)
packages/tm-core/src/modules/ui/index.ts (1)
1-8: Placeholder structure is appropriate for ongoing modularization.The file serves as a reasonable placeholder during the module restructuring. The JSDoc is clear, and the TODO accurately marks this as future work to migrate from
scripts/modules/ui.js.Please verify that this module file integrates properly into the parent module structure (e.g., re-exported from
packages/tm-core/src/modules/index.tsor the TmCore facade as appropriate). This ensures module resolution remains unbroken during the refactor.packages/tm-core/src/modules/tasks/parser/index.ts (2)
6-6: Verify the import extension is appropriate for TypeScript source files.The import uses a
.jsextension when importing from TypeScript source files. Per the repository's pattern (internal packages export TypeScript source files, not compiled JavaScript), please verify that this extension is intentional and compatible with your build tooling.If this file should reference the TypeScript source directly (as per the learnings about internal package exports), consider whether the import should reference the
.tssource or omit the extension entirely:-import type { PlaceholderTask } from '../../../common/types/index.js'; +import type { PlaceholderTask } from '../../../common/types/index.ts';or
-import type { PlaceholderTask } from '../../../common/types/index.js'; +import type { PlaceholderTask } from '../../../common/types';Based on learnings, the repository's tsconfig path mappings resolve to TypeScript source files directly during build time with tsdown bundling.
14-39: LGTM — placeholder implementation is appropriate.The TaskParser interface and PlaceholderParser class are well-structured. The
@deprecatedmarker appropriately signals the temporary nature, and commented-out parser implementations suggest a clear path forward for future work. The simple line-based parsing logic is adequate for a placeholder.packages/tm-core/src/modules/storage/adapters/file-storage/format-handler.ts (1)
5-5: LGTM! Import path correctly updated for module reorganization.The import path correctly reflects the new centralized types location. The path resolves to
packages/tm-core/src/common/types/index.js, and bothTaskandTaskMetadatatypes are used consistently throughout the file.packages/tm-core/src/modules/tasks/entities/task.entity.ts (1)
5-11: Import paths resolve correctly; no issues identified.Verification confirms all symbols (ERROR_CODES, TaskMasterError, Task, Subtask, TaskPriority, TaskStatus) are properly exported from their source files:
packages/tm-core/src/common/errors/task-master-error.tsexports ERROR_CODES and TaskMasterErrorpackages/tm-core/src/common/types/index.tsexports the four type importsThe centralized refactoring is sound.
packages/tm-core/src/modules/tasks/repositories/task-repository.interface.ts (1)
1-2: Import path updates verified and correct.All imports resolve to valid exports:
TaskandTaskTagare properly exported frompackages/tm-core/src/common/types/index.tsLoadTasksOptionsis properly exported frompackages/tm-core/src/common/interfaces/storage.interface.tsThe relative path depth and
.jsextensions are appropriate for the file structure and ES module configuration.packages/tm-core/src/modules/tasks/repositories/supabase/supabase-task-repository.ts (1)
2-5: All imports verified and correctly target centralized module locations.The refactor is sound:
Taskproperly exported frompackages/tm-core/src/common/types/index.tsDatabaseandJsonproperly exported frompackages/tm-core/src/common/types/database.types.tsTaskMapperproperly exported frompackages/tm-core/src/common/mappers/TaskMapper.tsAuthManagercorrectly imported from sibling auth module- No lingering old imports remain in the file
- Relative path depth correctly accounts for file location in
repositories/supabase/subdirectorypackages/tm-core/src/modules/auth/services/organization.service.ts (1)
7-9: LGTM! Import paths updated to centralized common modules.The import path refactoring correctly references the new centralized module structure without altering runtime behavior.
packages/tm-core/src/modules/tasks/services/preflight-checker.service.ts (1)
9-14: LGTM! Import paths correctly updated.The logger and git-utils imports now reference the centralized common module paths, consistent with the broader refactoring effort.
packages/tm-core/src/modules/integration/services/export.service.ts (1)
6-11: LGTM! Module imports updated correctly.The import statements properly reference the reorganized module structure for types, managers, errors, and storage adapters.
packages/tm-core/src/modules/auth/services/credential-store.ts (1)
7-9: LGTM! Import paths align with new module structure.The imports correctly reference the reorganized auth module types, config, and centralized logger.
package.json (2)
12-16: LGTM! Workspaces reformatted for readability.The multi-line formatting improves readability without changing functionality.
146-146: LGTM! Type definitions added correctly.Adding
@types/fs-extrato devDependencies is appropriate sincefs-extrais used in dependencies. This aligns with the repository's pattern where types are in devDependencies because packages are bundled with tsdown at build time.Based on learnings.
packages/tm-core/src/modules/auth/services/credential-store.test.ts (1)
6-8: LGTM! Test imports updated correctly.The import paths for CredentialStore and types properly reflect the new module structure.
packages/tm-core/src/modules/tasks/services/task-loader.service.ts (1)
6-9: LGTM! Import paths correctly updated.The imports for types, ConfigManager, and logger properly reference the new centralized module structure.
packages/tm-core/src/modules/workflow/services/workflow-activity-logger.ts (1)
8-11: LGTM! Import paths align with new module structure.The imports correctly reference the reorganized workflow orchestrator, types, storage adapters, and centralized logger.
packages/tm-core/src/task-master-core.ts (1)
5-60: LGTM! Import path refactoring aligns with modular structure.The import path updates systematically migrate from a flat structure to the new modular
./modules/*layout. The changes:
- Preserve all public API types and their names
- Follow a consistent pattern across all imports and re-exports
- Align with the broader PR objective of reorganizing tm-core into domain-based modules
No breaking changes detected.
packages/tm-core/src/modules/auth/services/supabase-session-storage.ts (1)
10-12: LGTM! Import paths updated for auth module reorganization.Import paths correctly updated to reflect the new auth module structure with nested services and centralized types. No behavioral changes.
packages/tm-core/src/modules/tasks/services/task-execution-service.ts (1)
6-6: LGTM! Task type import centralized to common module.The Task type import is correctly updated to reference the centralized common/types location, consistent with the broader refactor to consolidate shared types.
packages/tm-core/src/modules/git/services/branch-name-generator.spec.ts (1)
5-5: LGTM! Test import updated for module relocation.Import path correctly updated to reflect the branch-name-generator module's relocation to the services subdirectory. Test structure and logic remain unchanged.
packages/tm-core/src/modules/auth/managers/auth-manager.spec.ts (1)
76-76: LGTM! Test import updated for auth module reorganization.Import path correctly updated to reflect AuthManager's relocation to the nested managers directory. Mocks are properly set up before the SUT import, following established testing patterns.
packages/tm-core/src/modules/config/services/runtime-state-manager.service.ts (1)
11-13: LGTM! Imports centralized to common modules.Import paths correctly updated to reference centralized common modules for errors, configuration, and logging. No behavioral changes detected.
packages/tm-core/src/modules/workflow/managers/workflow-state-manager.ts (1)
12-13: LGTM! Import paths updated for workflow module reorganization.Import paths correctly updated to reflect the workflow module's new structure and centralized logger location. No behavioral changes.
packages/tm-core/src/modules/integration/clients/supabase-client.ts (1)
11-14: LGTM! Import paths updated for module reorganization.The import paths have been correctly updated to reflect the new modular structure, with auth-related imports from
../../auth/and shared utilities from../../../common/.packages/tm-core/src/modules/config/services/config-loader.service.ts (1)
8-9: LGTM! Import paths correctly updated.Configuration interfaces and error classes have been appropriately relocated to the centralized common modules.
Also applies to: 13-13
packages/tm-core/src/modules/config/services/config-merger.service.ts (1)
6-6: LGTM! Import path correctly updated.packages/tm-core/src/modules/config/services/environment-config-provider.service.ts (1)
6-7: LGTM! Import paths correctly updated.packages/tm-core/src/modules/auth/services/oauth-service.ts (1)
15-19: LGTM! Import paths updated for modular structure.The import paths correctly reflect the new module organization, with auth-specific imports from relative module paths and shared utilities from centralized common modules.
packages/tm-core/src/modules/execution/executors/claude-executor.ts (1)
6-6: LGTM! Import paths correctly updated.Also applies to: 11-11
packages/tm-core/src/modules/execution/executors/executor-factory.ts (1)
5-5: LGTM! Import paths correctly updated.Also applies to: 7-7
packages/tm-core/src/modules/tasks/services/task-service.ts (1)
11-16: LGTM! Import paths correctly updated.The import paths appropriately reference centralized common modules and cross-module dependencies.
packages/tm-core/src/modules/execution/executors/base-executor.ts (1)
5-7: LGTM! Import paths updated to centralized common modules.The import paths have been correctly updated to reference the new centralized common module structure, maintaining proper relative paths and ESM
.jsextensions.packages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.test.ts (1)
2-8: LGTM! Test imports updated to match new module structure.The test imports have been correctly updated to reference the relocated WorkflowOrchestrator and types from their new module paths.
packages/tm-core/src/modules/workflow/managers/workflow-state-manager.spec.ts (1)
6-6: LGTM! Import path correctly updated.The WorkflowStateManager import has been properly updated to reference the new managers subdirectory location.
packages/tm-core/src/modules/execution/types.ts (1)
5-5: LGTM! Task type import centralized.The Task type import has been correctly updated to reference the centralized common types module, aligning with the broader refactoring effort.
packages/tm-core/src/modules/config/services/config-loader.service.spec.ts (1)
8-8: LGTM! Configuration constant import centralized.The DEFAULT_CONFIG_VALUES import has been correctly updated to the centralized common interfaces path.
packages/tm-core/src/modules/storage/adapters/file-storage/file-storage.ts (1)
5-15: LGTM! Storage imports updated to centralized modules.All imports have been correctly updated to reference the new centralized common module structure and relocated report managers. The relative paths are appropriate given the file's depth in the directory tree.
packages/tm-core/src/modules/config/services/config-persistence.service.ts (1)
8-13: LGTM! Configuration service imports centralized.All imports (PartialConfiguration, error handling, and logging) have been correctly updated to reference the centralized common modules.
packages/tm-core/src/modules/config/services/runtime-state-manager.service.spec.ts (1)
8-8: LGTM! Configuration constant import centralized.The DEFAULT_CONFIG_VALUES import has been correctly updated to match the new centralized common interfaces path.
packages/tm-core/src/modules/reports/managers/complexity-report-manager.ts (1)
12-13: LGTM! Import paths updated for module reorganization.The import paths have been correctly updated to reflect the new centralized module structure, moving types to the parent module level and logger to the common utilities path.
packages/tm-core/src/modules/ai/index.ts (1)
6-6: LGTM! AI module export consolidated.The export has been updated to point to the new providers module structure, centralizing the AI provider surface area.
packages/tm-core/src/modules/storage/services/storage-factory.ts (1)
5-16: LGTM! Storage imports reorganized to centralized structure.All import paths have been correctly updated to reflect the new modular architecture, with interfaces centralized under
common/interfaces/, adapters at the module level, and cross-module dependencies properly resolved.packages/tm-core/src/modules/config/index.ts (2)
7-7: LGTM! ConfigManager export updated for nested structure.The ConfigManager export path has been correctly updated to reflect its new location in the
managers/subdirectory.
41-44: LGTM! Configuration interfaces centralized.The configuration interface imports have been correctly updated to use the centralized common interfaces path, maintaining consistency with the broader module reorganization.
packages/tm-core/src/modules/execution/services/executor-service.ts (1)
5-13: LGTM! Execution service imports reorganized.All import paths have been correctly updated to reflect the new modular structure, with common types and utilities centralized and module-specific types properly resolved at the module level.
packages/tm-core/src/modules/workflow/orchestrators/workflow-orchestrator.ts (2)
12-12: LGTM! Workflow types import updated.The workflow type imports have been correctly updated to reference the module-level types file, reflecting the reorganization of the workflow module structure.
567-567: LGTM! WorkflowError type path updated.The inline type import for
WorkflowErrorhas been correctly updated to match the new module-level types location.packages/tm-core/src/common/interfaces/index.ts (1)
11-12: LGTM! AI Provider interfaces relocated to AI module.The AI Provider interface exports have been correctly updated to reference their new location within the AI module structure, maintaining interface encapsulation while preserving the public export surface.
packages/tm-core/src/modules/reports/index.ts (1)
5-5: LGTM! ComplexityReportManager export updated for nested structure.The export path has been correctly updated to reflect the manager's new location in the
managers/subdirectory, consistent with the broader module reorganization pattern.packages/tm-core/src/modules/config/managers/config-manager.ts (1)
9-21: LGTM!The import path updates correctly align with the new module structure, moving to centralized common interfaces and nested service directories. No logic changes detected.
packages/tm-core/src/modules/auth/managers/auth-manager.ts (1)
5-22: LGTM!Import paths correctly updated to reflect the new module structure, with proper relative paths to nested managers, services, integration clients, and common modules. No functional changes detected.
packages/tm-core/src/modules/workflow/services/workflow.service.ts (1)
6-17: LGTM!Import paths correctly updated to reflect the reorganized module structure with nested orchestrators, managers, services, and types directories. No functional changes detected.
packages/tm-core/src/modules/storage/adapters/api-storage.ts (1)
6-23: LGTM!Import paths correctly updated to reference centralized common interfaces, types, and errors, along with properly nested repository and manager modules. No functional changes detected.
packages/tm-core/src/modules/git/index.ts (1)
7-13: LGTM!Export paths correctly updated to reflect the new nested adapters/ and services/ directory structure while maintaining the same public API surface.
packages/tm-core/src/modules/auth/index.ts (1)
5-13: LGTM!Export paths correctly updated to reflect the new nested managers/ and services/ directory structure while maintaining the same public API surface and exported symbol names.
packages/tm-core/src/modules/execution/index.ts (1)
1-12: LGTM!This new index file properly establishes a centralized public API entry point for the execution module, aligning with the broader modular reorganization pattern across the codebase.
packages/tm-core/src/modules/workflow/workflow-domain.ts (1)
1-98: LGTM! Clean domain facade implementation.The WorkflowDomain follows a consistent delegation pattern and provides a well-structured public API for TDD workflow operations. The constructor properly extracts the project root from ConfigManager, and all methods delegate cleanly to the underlying WorkflowService.
packages/tm-core/src/modules/storage/index.ts (1)
7-24: LGTM! Export path updates align with module reorganization.The updated import paths correctly reflect the new modular structure, moving adapters to
./adapters/*, services to./services/*, and common interfaces to../../common/interfaces/*. This is consistent with the broader PR reorganization.packages/tm-core/src/modules/ai/providers/base-provider.ts (2)
9-14: LGTM! Import path updates align with centralized common structure.The updated paths correctly move TaskMasterError to the common errors location and AI provider interfaces to the module-relative interfaces path.
431-441: LGTM! Return type import paths updated consistently.The abstract method signatures correctly use the new relative interface path for ProviderInfo, AIModel[], and ProviderUsageStats return types.
packages/tm-core/src/modules/config/config-domain.ts (1)
1-113: LGTM! Clean and consistent configuration domain facade.The ConfigDomain provides a well-organized public API for configuration management, properly delegating all operations to the underlying ConfigManager. The method organization by functional areas (Configuration Access, Runtime State, Configuration Updates, Utilities) enhances readability.
packages/tm-core/src/modules/auth/auth-domain.ts (1)
1-127: LGTM! Well-structured auth domain facade.The AuthDomain provides a clean public API for authentication and authorization operations. The use of singleton AuthManager (via
getInstance()) is appropriate for auth state management, distinguishing it appropriately from other domain facades that accept ConfigManager.packages/tm-core/src/modules/git/git-domain.ts (1)
1-238: LGTM! Comprehensive git domain facade.The GitDomain provides an extensive, well-organized public API for Git operations. The functional grouping (Repository Validation, Working Tree Status, Branch Operations, Commit Operations, Remote Operations, Commit Message Generation) makes the large API surface easy to navigate. The delegation pattern is consistent with other domain facades.
packages/tm-core/src/modules/tasks/tasks-domain.ts (1)
1-184: LGTM! Well-coordinated tasks domain facade.The TasksDomain effectively coordinates four underlying services (TaskService, TaskExecutionService, TaskLoaderService, PreflightChecker) and provides a comprehensive public API. The initialization pattern correctly calls only
taskService.initialize(), as the other services either use lazy initialization (TaskLoaderService) or don't require setup (TaskExecutionService, PreflightChecker).packages/tm-core/src/index.ts (2)
1-28: Excellent documentation and API design.The example clearly demonstrates the new unified access pattern through the TmCore facade. The "ONLY way" directive appropriately signals that this is the intended entry point for all consumers.
44-102: Code structure is correct; all type exports verified.All module files exist and export the required types as specified in index.ts:
- Tasks domain: 3 service files, all types present ✓
- Auth domain: types.ts exports AuthCredentials, OAuthFlowOptions, UserContext ✓
- Workflow domain: workflow.service.ts exports StartWorkflowOptions, WorkflowStatus, NextAction; types.ts exports WorkflowPhase, TDDPhase, WorkflowContext, WorkflowState, TestResult ✓
- Git, Integration, Reports domains: all files and exports verified ✓
The selective type export strategy is sound and aligns with the facade pattern.
| /** | ||
| * @fileoverview Main entry point for the tm-core package | ||
| * This file exports all public APIs from the core Task Master library | ||
| * @fileoverview Main entry point for @tm/core | ||
| * Provides unified access to all Task Master functionality through TmCore | ||
| */ | ||
|
|
||
| // Export main facade | ||
| export { | ||
| TaskMasterCore, | ||
| createTaskMasterCore, | ||
| type TaskMasterCoreOptions, | ||
| type ListTasksResult, | ||
| type StartTaskOptions, | ||
| type StartTaskResult, | ||
| type ConflictCheckResult, | ||
| type ExportTasksOptions, | ||
| type ExportResult | ||
| } from './task-master-core.js'; | ||
|
|
||
| // Re-export types | ||
| export type * from './types/index.js'; | ||
|
|
||
| // Re-export interfaces (types only to avoid conflicts) | ||
| export type * from './interfaces/index.js'; | ||
|
|
||
| // Re-export constants | ||
| export * from './constants/index.js'; | ||
|
|
||
| // Re-export providers | ||
| export * from './providers/index.js'; | ||
|
|
||
| // Re-export storage (selectively to avoid conflicts) | ||
| export { | ||
| FileStorage, | ||
| ApiStorage, | ||
| StorageFactory, | ||
| type ApiStorageConfig | ||
| } from './storage/index.js'; | ||
| export { PlaceholderStorage, type StorageAdapter } from './storage/index.js'; | ||
|
|
||
| // Re-export parser | ||
| export * from './parser/index.js'; | ||
|
|
||
| // Re-export utilities | ||
| export * from './utils/index.js'; | ||
|
|
||
| // Re-export errors | ||
| export * from './errors/index.js'; | ||
|
|
||
| // Re-export entities | ||
| export { TaskEntity } from './entities/task.entity.js'; | ||
|
|
||
| // Re-export authentication | ||
| export { | ||
| AuthManager, | ||
| AuthenticationError, | ||
| type AuthCredentials, | ||
| type OAuthFlowOptions, | ||
| type AuthConfig | ||
| } from './auth/index.js'; | ||
|
|
||
| // Re-export logger | ||
| export { getLogger, createLogger, setGlobalLogger } from './logger/index.js'; | ||
|
|
||
| // Re-export executors | ||
| export * from './executors/index.js'; | ||
|
|
||
| // Re-export reports | ||
| export { | ||
| ComplexityReportManager, | ||
| type ComplexityReport, | ||
| type ComplexityReportMetadata, | ||
| type ComplexityAnalysis, | ||
| type TaskComplexityData | ||
| } from './reports/index.js'; | ||
|
|
||
| // Re-export services | ||
| export { | ||
| PreflightChecker, | ||
| TaskLoaderService, | ||
| type CheckResult, | ||
| type PreflightResult, | ||
| type TaskValidationResult, | ||
| type ValidationErrorType, | ||
| type DependencyIssue | ||
| } from './services/index.js'; | ||
|
|
||
| // Re-export Git adapter | ||
| export { GitAdapter } from './git/git-adapter.js'; | ||
| export { | ||
| CommitMessageGenerator, | ||
| type CommitMessageOptions | ||
| } from './git/commit-message-generator.js'; | ||
|
|
||
| // Re-export workflow orchestrator, state manager, activity logger, and types | ||
| export { WorkflowOrchestrator } from './workflow/workflow-orchestrator.js'; | ||
| export { WorkflowStateManager } from './workflow/workflow-state-manager.js'; | ||
| export { WorkflowActivityLogger } from './workflow/workflow-activity-logger.js'; | ||
| // ========== Primary API ========== | ||
|
|
||
| /** | ||
| * Create a new TmCore instance - The ONLY way to use tm-core | ||
| * | ||
| * @example | ||
| * ```typescript | ||
| * import { createTmCore } from '@tm/core'; | ||
| * | ||
| * const tmcore = await createTmCore({ | ||
| * projectPath: process.cwd() | ||
| * }); | ||
| * | ||
| * // Access domains | ||
| * await tmcore.auth.login({ ... }); | ||
| * const tasks = await tmcore.tasks.list(); | ||
| * await tmcore.workflow.start({ taskId: '1' }); | ||
| * await tmcore.git.commit('feat: add feature'); | ||
| * const config = tmcore.config.get('models.main'); | ||
| * ``` | ||
| */ | ||
| export { createTmCore, type TmCoreOptions } from './tm-core.js'; | ||
| export type { TmCore } from './tm-core.js'; | ||
|
|
||
| // ========== Type Exports ========== | ||
|
|
||
| // Common types that consumers need | ||
| export type * from './common/types/index.js'; | ||
|
|
||
| // Common interfaces | ||
| export type * from './common/interfaces/index.js'; | ||
|
|
||
| // Constants | ||
| export * from './common/constants/index.js'; | ||
|
|
||
| // Errors | ||
| export * from './common/errors/index.js'; | ||
|
|
||
| // ========== Domain-Specific Type Exports ========== | ||
|
|
||
| // Task types | ||
| export type { | ||
| TaskListResult, | ||
| GetTaskListOptions | ||
| } from './modules/tasks/services/task-service.js'; | ||
|
|
||
| export type { | ||
| StartTaskOptions, | ||
| StartTaskResult, | ||
| ConflictCheckResult | ||
| } from './modules/tasks/services/task-execution-service.js'; | ||
|
|
||
| export type { | ||
| PreflightResult, | ||
| CheckResult | ||
| } from './modules/tasks/services/preflight-checker.service.js'; | ||
|
|
||
| // Auth types | ||
| export type { | ||
| AuthCredentials, | ||
| OAuthFlowOptions, | ||
| UserContext | ||
| } from './modules/auth/types.js'; | ||
|
|
||
| // Workflow types | ||
| export type { | ||
| StartWorkflowOptions, | ||
| WorkflowStatus, | ||
| NextAction | ||
| } from './modules/workflow/services/workflow.service.js'; | ||
|
|
||
| export type { | ||
| WorkflowPhase, | ||
| TDDPhase, | ||
| WorkflowContext, | ||
| WorkflowState, | ||
| WorkflowEvent, | ||
| WorkflowEventData, | ||
| WorkflowEventListener, | ||
| SubtaskInfo, | ||
| TestResult, | ||
| WorkflowError | ||
| } from './workflow/types.js'; | ||
|
|
||
| // Re-export workflow service | ||
| export { WorkflowService } from './services/workflow.service.js'; | ||
| TestResult | ||
| } from './modules/workflow/types.js'; | ||
|
|
||
| // Git types | ||
| export type { | ||
| StartWorkflowOptions, | ||
| WorkflowStatus, | ||
| NextAction | ||
| } from './services/workflow.service.js'; | ||
| CommitMessageOptions | ||
| } from './modules/git/services/commit-message-generator.js'; | ||
|
|
||
| // Integration types | ||
| export type { | ||
| ExportTasksOptions, | ||
| ExportResult | ||
| } from './modules/integration/services/export.service.js'; | ||
|
|
||
| // Reports types | ||
| export type { | ||
| ComplexityReport, | ||
| ComplexityReportMetadata, | ||
| ComplexityAnalysis, | ||
| TaskComplexityData | ||
| } from './modules/reports/types.js'; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify migration from old API to new TmCore facade.
This is a major breaking change that removes the entire previous public API (TaskMasterCore, createTaskMasterCore, etc.) in favor of the new unified TmCore facade. Ensure all consumers in the monorepo have been updated to use the new API pattern.
🏁 Script executed:
#!/bin/bash
# Search for any lingering references to old API
echo "=== Searching for old API usage ==="
# Search for old imports/usages (excluding this file and git history)
echo "--- Checking for TaskMasterCore references ---"
rg -n "TaskMasterCore" --type ts --type tsx -g '!packages/tm-core/src/index.ts' -g '!*.md' -g '!CHANGELOG*' | head -20
echo -e "\n--- Checking for createTaskMasterCore references ---"
rg -n "createTaskMasterCore" --type ts --type tsx -g '!packages/tm-core/src/index.ts' -g '!*.md' -g '!CHANGELOG*' | head -20
echo -e "\n--- Checking for imports from @tm/core ---"
echo "Should see new pattern: import { createTmCore } from '@tm/core'"
rg -n "from ['\"]@tm/core['\"]" --type ts --type tsx -C 1 | head -30Length of output: 328
---
🏁 Script executed:
```shell
#!/bin/bash
# Search for any lingering references to old API - corrected version
echo "=== Searching for old API usage ==="
# Search for old imports/usages (excluding this file and git history)
echo "--- Checking for TaskMasterCore references ---"
rg -n "TaskMasterCore" --type ts -g '!packages/tm-core/src/index.ts' -g '!*.md' -g '!CHANGELOG*' 2>/dev/null || echo "No matches found"
echo -e "\n--- Checking for createTaskMasterCore references ---"
rg -n "createTaskMasterCore" --type ts -g '!packages/tm-core/src/index.ts' -g '!*.md' -g '!CHANGELOG*' 2>/dev/null || echo "No matches found"
echo -e "\n--- Checking for imports from @tm/core ---"
echo "Should see new pattern: import { createTmCore } from '@tm/core'"
rg -n "from ['\"]@tm/core['\"]" --type ts -C 1 2>/dev/null || echo "No matches found"
echo -e "\n--- Checking broader codebase for any @tm/ imports ---"
rg -n "from ['\"]@tm/" --type ts -C 1 2>/dev/null | head -40
Length of output: 23358
Migration to new TmCore API is incomplete—old API still exists and is actively used throughout the codebase.
The old TaskMasterCore class and createTaskMasterCore factory function still exist at packages/tm-core/src/task-master-core.ts and have NOT been removed. All consumers remain on the old API:
- apps/cli: 7+ commands (
start.command.ts,list.command.ts,show.command.ts,next.command.ts,autopilot.command.ts,export.command.ts,set-status.command.ts) - apps/extension:
terminal-manager.ts - apps/mcp:
tools/autopilot/start.tool.ts - packages/tm-core/tests:
tests/integration/list-tasks.test.ts
While index.ts exports the new createTmCore and TmCore APIs, the old exports from task-master-core.ts are still being imported everywhere. Either:
- Implement
createTmCoreas a wrapper/alias for the old API (for backwards compatibility), or - Remove the old API and update all consumers to the new pattern
| // ========== Type Exports ========== | ||
|
|
||
| // Common types that consumers need | ||
| export type * from './common/types/index.js'; | ||
|
|
||
| // Common interfaces | ||
| export type * from './common/interfaces/index.js'; | ||
|
|
||
| // Constants | ||
| export * from './common/constants/index.js'; | ||
|
|
||
| // Errors | ||
| export * from './common/errors/index.js'; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the new common module structure exists.
The export pattern is correct (type-only for types/interfaces, runtime for constants/errors), but we should verify that all referenced common modules exist and export the expected symbols.
🏁 Script executed:
#!/bin/bash
# Verify common module files exist and check their exports
echo "=== Checking common module files ==="
for module in types interfaces constants errors; do
file="packages/tm-core/src/common/${module}/index.ts"
if [ -f "$file" ]; then
echo "✓ $file exists"
echo " Exports:"
rg -n "^export" "$file" | head -10
else
echo "✗ $file NOT FOUND"
fi
echo ""
doneLength of output: 1774
Fix export pattern at line 36 to include runtime exports.
The common module structure is correctly set up, but there's an issue with how interfaces are re-exported. The file packages/tm-core/src/common/interfaces/index.ts does both export type * and export *, but line 36 in the main index uses export type * which filters out runtime exports. This should be changed to export * to preserve runtime values from storage, ai-provider, and configuration interfaces.
Correct line 36:
export * from './common/interfaces/index.js';
🤖 Prompt for AI Agents
In packages/tm-core/src/index.ts around lines 30 to 42, the interfaces re-export
uses a type-only export on line 36 which strips runtime exports; change that
export from a type-only export to a regular export so runtime values in
./common/interfaces/index.js are re-exported (i.e., replace the `export type *`
form with a plain `export *` for the interfaces index).
| } from './types.js'; | ||
| import { BaseExecutor } from './base-executor.js'; | ||
| } from '../types.js'; | ||
| import { BaseExecutor } from '../executors/base-executor.js'; |
There was a problem hiding this comment.
Fix the import path to use same-directory reference.
The import path ../executors/base-executor.js resolves to the same directory as the current file. Since both claude-executor.ts and base-executor.ts are in packages/tm-core/src/modules/execution/executors/, this should use a same-directory import.
Apply this diff:
-import { BaseExecutor } from '../executors/base-executor.js';
+import { BaseExecutor } from './base-executor.js';📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { BaseExecutor } from '../executors/base-executor.js'; | |
| import { BaseExecutor } from './base-executor.js'; |
🤖 Prompt for AI Agents
In packages/tm-core/src/modules/execution/executors/claude-executor.ts around
line 12, the import uses a parent-directory path to a module in the same
directory; replace the import path to reference the same directory (e.g. change
../executors/base-executor.js to ./base-executor.js) so the module resolves
correctly.
| import { ClaudeExecutor } from './claude-executor.js'; | ||
| import { getLogger } from '../logger/index.js'; | ||
| import type { ITaskExecutor, ExecutorOptions, ExecutorType } from '../types.js'; | ||
| import { ClaudeExecutor } from '../executors/claude-executor.js'; |
There was a problem hiding this comment.
Fix the import path to use same-directory reference.
The import path ../executors/claude-executor.js resolves to the same directory as the current file. Since both executor-factory.ts and claude-executor.ts are in packages/tm-core/src/modules/execution/executors/, this should use a same-directory import.
Apply this diff:
-import { ClaudeExecutor } from '../executors/claude-executor.js';
+import { ClaudeExecutor } from './claude-executor.js';📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { ClaudeExecutor } from '../executors/claude-executor.js'; | |
| import { ClaudeExecutor } from './claude-executor.js'; |
🤖 Prompt for AI Agents
In packages/tm-core/src/modules/execution/executors/executor-factory.ts around
line 6, the import uses a parent-directory path to reference claude-executor.js
though both files are in the same directory; change the import to a
same-directory reference (./claude-executor.js) so the module resolves correctly
and stays consistent with local-file imports.
| import { ERROR_CODES, TaskMasterError } from '../errors/task-master-error.js'; | ||
| import { getLogger } from '../logger/factory.js'; | ||
| import { ERROR_CODES, TaskMasterError } from '../../../common/errors/task-master-error.js'; | ||
| import { getLogger } from '../../../common/logger/factory.js'; |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the logger import path for consistency.
This file imports getLogger from ../../../common/logger/factory.js, while other files in this PR import from ../../../common/logger/index.js. Please verify whether this difference is intentional or if it should be index.js for consistency.
🏁 Script executed:
#!/bin/bash
# Check which logger files exist and their exports
echo "=== Checking logger module structure ==="
fd -t f "factory.js|index.js" packages/tm-core/src/common/logger/
echo -e "\n=== Checking getLogger exports in logger/index.js ==="
if [ -f packages/tm-core/src/common/logger/index.js ]; then
rg -A2 "export.*getLogger" packages/tm-core/src/common/logger/index.js
fi
echo -e "\n=== Checking getLogger in logger/factory.js ==="
if [ -f packages/tm-core/src/common/logger/factory.js ]; then
rg -A2 "export.*getLogger" packages/tm-core/src/common/logger/factory.js
fi
echo -e "\n=== Checking other files' logger imports ==="
rg -n "from.*common/logger/(index|factory)\.js" packages/tm-core/src/modules/ | head -20Length of output: 2721
</shell_scripts_instructions>
🏁 Script executed:
#!/bin/bash
# More comprehensive search for logger module
echo "=== Looking for all logger-related files ==="
fd -t f "logger" packages/tm-core/src/common/ 2>/dev/null || echo "Not in src/common"
echo -e "\n=== Checking packages/tm-core/src/index.ts for logger exports ==="
if [ -f packages/tm-core/src/index.ts ]; then
cat packages/tm-core/src/index.ts
fi
echo -e "\n=== Looking for logger directory ==="
find packages/tm-core/src -type d -name "*logger*" 2>/dev/null
echo -e "\n=== Checking package.json exports for tm-core ==="
if [ -f packages/tm-core/package.json ]; then
jq '.exports' packages/tm-core/package.json 2>/dev/null || echo "No exports field"
fi
echo -e "\n=== Checking if logger files might be named differently ==="
find packages/tm-core/src/common -type f 2>/dev/null | head -20Length of output: 4045
</shell_scripts_instructions>
🏁 Script executed:
#!/bin/bash
# Check actual logger file contents
echo "=== Checking src/common/logger/index.ts ==="
cat packages/tm-core/src/common/logger/index.ts 2>/dev/null || echo "File not found"
echo -e "\n=== Checking src/common/logger/factory.ts ==="
cat packages/tm-core/src/common/logger/factory.ts 2>/dev/null || echo "File not found"
echo -e "\n=== Checking if src/logger/index.ts exists (per package.json) ==="
if [ -f packages/tm-core/src/logger/index.ts ]; then
cat packages/tm-core/src/logger/index.ts
else
echo "File not found"
# Check what's in src/logger/ if it exists
ls -la packages/tm-core/src/logger/ 2>/dev/null || echo "Directory doesn't exist"
fiLength of output: 1615
Update logger import path to index.ts for consistency with rest of codebase.
The file imports getLogger from factory.ts directly, while all other modules in the codebase import from index.ts. Since index.ts already re-exports from factory.ts, standardizing on the public module interface would improve consistency. Update the import in task-service.ts (and the two other task module files: preflight-checker.service.ts and task-loader.service.ts) to use index.ts.
🤖 Prompt for AI Agents
In packages/tm-core/src/modules/tasks/services/task-service.ts around line 17
the import pulls getLogger directly from factory.js; update it to import from
the module index (../../../common/logger/index.js or ../../../common/logger) to
match the project's public interface; likewise update the imports in the two
other task module files (preflight-checker.service.ts and
task-loader.service.ts) to import getLogger from the logger index export so all
three files use the same public path.
| private async initialize(): Promise<void> { | ||
| try { | ||
| // Create config manager | ||
| (this as any)._configManager = await ConfigManager.create(this._projectPath); | ||
|
|
||
| // Apply configuration overrides if provided | ||
| if (this._options.configuration) { | ||
| await this._configManager.updateConfig(this._options.configuration); | ||
| } | ||
|
|
||
| // Initialize domain facades | ||
| (this as any).tasks = new TasksDomain(this._configManager); | ||
| (this as any).auth = new AuthDomain(); | ||
| (this as any).workflow = new WorkflowDomain(this._configManager); | ||
| (this as any).git = new GitDomain(this._projectPath); | ||
| (this as any).config = new ConfigDomain(this._configManager); | ||
|
|
||
| // Initialize domains that need async setup | ||
| await this.tasks.initialize(); | ||
| } catch (error) { | ||
| throw new TaskMasterError( | ||
| 'Failed to initialize TmCore', | ||
| ERROR_CODES.INTERNAL_ERROR, | ||
| { operation: 'initialize' }, | ||
| error as Error | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify error handling in initialize() covers all failure modes.
The initialize() method wraps errors in TaskMasterError, but ensure that partial initialization failures leave the instance in a safe state (e.g., if tasks.initialize() fails after domain facades are created).
Run the following script to check if there are any direct constructor calls or tests that bypass the factory:
🏁 Script executed:
#!/bin/bash
# Check for direct TmCore constructor calls (should only be within the class)
rg -n "new TmCore\(" --type ts -A 2 -B 2
# Check test files for proper usage
rg -n "TmCore\.create|createTmCore" --type ts -g "**/test/**" -g "**/*.spec.ts" -g "**/*.test.ts"Length of output: 333
I need to verify a few more things about the error handling and state safety concern raised in the review comment.
</script>🏁 Script executed:
#!/bin/bash
# Search for test files in the repository
fd -e spec.ts -e test.ts -e spec.js -e test.js | head -20
# Check if domain classes have cleanup/rollback methods
rg -n "cleanup|rollback|reset|teardown" --type ts -A 2 -B 2
# Inspect the domain constructors and ConfigManager to understand potential side effects
rg -n "class (TasksDomain|AuthDomain|WorkflowDomain|GitDomain|ConfigDomain|ConfigManager)" --type ts -A 5Length of output: 34482
I need to examine the TasksDomain.initialize() method and the close() method to understand partial initialization handling.
🏁 Script executed:
#!/bin/bash
# Find and examine TasksDomain.initialize() implementation
rg -n "initialize\(\)" packages/tm-core/src/modules/tasks/tasks-domain.ts -A 15
# Examine the close() method in tm-core to verify cleanup strategy
rg -n "async close\(\)" packages/tm-core/src/tm-core.ts -A 20
# Check if domain constructors have any side effects (file I/O, network calls, etc.)
rg -n "constructor\(" packages/tm-core/src/modules/tasks/tasks-domain.ts -A 10
rg -n "constructor\(" packages/tm-core/src/modules/auth/auth-domain.ts -A 5
rg -n "constructor\(" packages/tm-core/src/modules/workflow/workflow-domain.ts -A 5Length of output: 1206
🏁 Script executed:
#!/bin/bash
# Get the complete close() method from tm-core.ts
cat packages/tm-core/src/tm-core.ts | sed -n '/^\s*async close\(\)/,/^\s*}/p' | head -30
# Also check if there's error handling or rollback in initialize
cat packages/tm-core/src/tm-core.ts | sed -n '96,123p'
# Check TaskService.initialize to understand what could fail
rg -n "class TaskService" packages/tm-core/src/modules/tasks/services -A 30 | head -50Length of output: 3639
🏁 Script executed:
#!/bin/bash
# Get full close() method with proper line extraction
rg -n "async close\(\)" packages/tm-core/src/tm-core.ts -A 30
# Also check what happens in the factory create() method after initialize() fails
ast-grep --pattern $'static async create($_, $_): Promise<TmCore> {
$$$
}'Length of output: 0
🏁 Script executed:
#!/bin/bash
# List all methods in tm-core.ts
rg -n "^\s*(private |public |protected |async )*\w+\(" packages/tm-core/src/tm-core.ts | head -20
# Show entire content of tm-core.ts to understand structure
wc -l packages/tm-core/src/tm-core.ts
# Check exports and inheritance
head -50 packages/tm-core/src/tm-core.ts
# Check if there are any cleanup/close methods
rg -n "close|cleanup|destroy" packages/tm-core/src/tm-core.ts -B 2 -A 5Length of output: 1833
Partial initialization can leave TmCore instance in unsafe state after failure—add rollback or guard mechanism.
The review comment correctly identifies a critical issue. If await this.tasks.initialize() fails at line 113:
- All domain facades are already created and assigned to the instance (lines 108-112)
- The error is wrapped and re-thrown, but the instance is left partially initialized with no cleanup
- Since
TmCorehas noclose()or cleanup method, resources cannot be properly released or the instance reset - Callers have no way to recover safely
Recommended fixes:
- Add a
close()method to TmCore to safely release domain resources - Wrap domain creation in a try-catch that cleans up on failure, or defer domain assignment until after
tasks.initialize()succeeds - Add an
initializedflag and guard against using the instance if initialization failed
🤖 Prompt for AI Agents
In packages/tm-core/src/tm-core.ts around lines 96 to 123, initialization
assigns domain facades before async setup of tasks, so if await
this.tasks.initialize() fails the instance is left partially initialized; to
fix, either defer assigning domain properties to the instance until after
tasks.initialize() completes successfully or wrap the creation/assignment in a
try block that on any failure calls a new close() method to teardown any
already-created domains and unset properties, and add an initialized boolean
flag that is set only after successful completion and checked by public methods
to guard usage when initialization failed.
Crunchyman-ralph
changed the title
Crunchyman-ralph
force-pushed
the
ralph/feat/update.task.remote
branch
from
541a288 to
03b7ef9
Compare
1 participant
…in.0.30.0# What type of PR is this?
Description
Related Issues
How to Test This
# Example commands or stepsExpected result:
Contributor Checklist
npm run changesetnpm testnpm run format-check(ornpm run formatto fix)Changelog Entry
For Maintainers
Summary by CodeRabbit
New Features
TmCorefacade providing simplified access to task, auth, workflow, git, and config functionality viacreateTmCore()factory.TasksDomain,AuthDomain,WorkflowDomain,GitDomain,ConfigDomain) exposing core operations through organized, user-facing interfaces.Breaking Changes
TaskMasterCorein favor of newTmCoreapproach.Refactor
modules/structure containing services, adapters, and managers.Chores
@types/fs-extradependency.