claude-task-master 核心库 tm-core 全解析包结构、工程化工具链与模块化演进路线【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master导读tm-core包名tm/core是 claude-task-master 项目中承担任务管理与编排能力的核心 TypeScript 库CLI、MCP 服务、编辑器扩展等上层应用都围绕它构建。本文以 packages/tm-core/CHANGELOG.md 为主体骨架结合当前仓库中 src 的真实实现系统讲解 tm-core 的目录结构、构建与测试基础设施、统一门面 API、错误处理体系、路径与 Provider 常量以及从「占位结构」到「完整实现」的发布演进路线帮助你快速理解并上手这套核心库。一、tm-core 在 claude-task-master 中的定位从 packages/tm-core/package.json 可以看到该包被描述为 Core library for Task Master - TypeScript task management system。在 monorepo 中它位于packages/tm-core与tm-bridge、tm-profiles、claude-code-plugin、ai-sdk-provider-grok-cli等包平级是整个任务管理系统的地基任务实体的建模、工作流编排、AI Provider 抽象、存储层适配、Git 集成、认证与会话管理都被收敛到这个包中。需要特别说明的是当前仓库中 tm-core 的实际实现已经远超 CHANGELOG 所描述的「占位实现」状态——src/modules下已经沉淀了 15 个功能模块的实体代码与配套测试本文后续章节将逐一对应展开。二、包结构与模块化架构CHANGELOG 的 Package Structure 一节规划了src/types/、src/providers/、src/storage/、src/parser/、src/utils/、src/errors/、tests/七个占位目录。从当前仓库的实际目录树看这一骨架已经演化成了更精细的分层结构核心是src/common跨模块公共件与src/modules业务领域模块的两级划分src/common/所有模块共享的公共设施constants/路径常量paths.ts与 Provider 校验常量providers.tserrors/统一错误类TaskMasterError与错误码表task-master-error.tsinterfaces/IConfiguration、存储层接口等抽象契约logger/可插拔的日志工厂支持 MCP 日志回调mappers/任务实体映射器TaskMapperschemas/基于 Zod 的校验 Schema如 task-idtypes/数据库类型、仓库类型、legacy 兼容类型utils/Git 工具、ID 生成器、路径规范化、项目根目录查找src/modules/15 个领域模块每个模块遵循 domain services managers/adapters 的内部结构ai/AI Provider 接口与基础实现auth/认证领域OAuth 服务、会话管理、Supabase 会话存储、命令守卫briefs/任务简报领域commands/、dependencies/命令与依赖关系config/配置领域ConfigManager、加载/合并/持久化服务、环境变量 Providerexecution/执行器Claude 执行器、执行器工厂git/Git 领域适配器、分支名生成、提交信息生成、范围检测、模板引擎integration/集成领域Supabase 客户端、导出服务、任务展开服务loop/循环执行领域默认/去重/熵/代码检查/测试覆盖等预设prompts/提示词服务与触发条件评估reports/复杂度报告管理storage/存储层文件存储适配器、API 存储、存储工厂、活动日志tasks/任务领域实体、仓库、解析器、校验、服务、Supabase 仓库ui/、workflow/UI 与工作流编排状态管理、TDD 阶段、测试结果校验src/testing/面向集成测试的 fixturescreateTask、createTasksFile、TaskScenarios等src/index.tsbarrel 导出统一暴露createTmCore与全部公开类型这种分层与 CHANGELOG 规划的模块化思路一脉相承但落地为更符合领域驱动风格的目录约定每个领域模块自带测试文件如auth-manager.spec.ts、config-manager.spec.ts、workflow-orchestrator.spec.ts测试与源码同目录共存便于快速定位。三、开发基础设施构建、测试与代码质量CHANGELOG 的 Development Infrastructure 一节列出的工具链在当前仓库中均有对应落点其中一部分发生了实际演进值得对照阅读3.1 TypeScript 严格模式packages/tm-core/tsconfig.json 完全贯彻了 CHANGELOG 记录的 TypeScript support with strict modetarget: ES2022、module: NodeNext、moduleResolution: NodeNext源码采用显式.js后缀导入如./modules/tasks/tasks-domain.js符合 NodeNext ESM 规范strict: true并显式开启noImplicitAny、strictNullChecks、strictFunctionTypes、strictBindCallApply、noImplicitThis、alwaysStrict等全部严格检查项额外开启noUnusedLocals、noUnusedParameters、noImplicitReturns、noFallthroughCasesInSwitch从编译期拦截未使用变量与缺失返回路径declaration、declarationMap、sourceMap全开产物输出到./dist。3.2 双格式构建的演进CHANGELOG 记录的是 Dual ESM/CJS build system with tsup。从当前仓库看package.json 采用了type: module的 ESM 优先策略exports字段将.、./testing、./auth、./storage、./config、./providers、./services、./errors、./logger、./types、./interfaces、./utils等子路径全部直接指向./src/...的 TS 源码main: ./dist/index.js与types: ./src/index.ts并存说明当前阶段更强调「源码即入口」的开发体验仓库根目录同时存在 tsdown.config.ts可推断最终发布形态仍会收敛到统一构建产物。读者在接入时应以exports字段为权威依据按子路径做按需导入。3.3 测试框架从 Jest 到 VitestCHANGELOG 明确记录 Jest testing framework with TypeScript support但当前仓库的实际脚本与配置已迁移到 Vitestpackage.json中的test系列脚本全部为vitest run/vitest run --coverage并配套 packages/tm-core/vitest.config.ts。该配置在根配置基础上做了三件事测试范围同时纳入tests/**与src/**下的*.test.ts/*.spec.ts实现「源码旁测试」覆盖率门槛将 branches / functions / lines / statements 四个维度的阈值统一提到80%显著高于默认要求体现核心库的质量底线路径别名配置→src以及/types、/providers、/storage、/parser、/utils、/errors等子路径别名与 CHANGELOG 规划的子目录一一对应。仓库中已沉淀大量测试证据src内散布着 30 个.spec.ts/.test.ts如 presets.spec.ts、config-manager.spec.tstests/integration下另有 12 个集成测试文件与 tests/setup.ts 全局初始化。3.4 代码质量与依赖选型CHANGELOG 记录的 ESLint and Prettier 在仓库中同样演化为 Biomepackage.json的lint/format脚本均为biome check/biome format根目录 biome.json 统一管理。运行npm run typechecktsc --noEmit即可在不产出文件的前提下完成全量类型校验。运行时依赖的选型也体现了库的定位见 package.jsonzod^4任务 ID、配置等结构的运行时校验src/common/schemas/与src/modules/tasks/validation/均基于 Zodsupabase/supabase-js云端存储与认证后端的客户端fs-extra、proper-lockfile、steno文件系统操作的健壮性原子写入、跨进程文件锁simple-gitGit 领域操作的底层封装date-fns日期格式化。四、统一门面TmCore 与 createTmCoreCHANGELOG 虽未展开描述 API 形态但这是当前仓库最重要的实现事实。入口文件 src/index.ts 的注释明确写道createTmCore是使用 tm-core 的唯一方式门面类 src/tm-core.ts 通过私有构造函数 静态工厂方法TmCore.create()保证实例永远处于已初始化状态。4.1 初始化选项import { createTmCore } from tm/core; const tmcore await createTmCore({ projectPath: process.cwd(), // 必需项目根目录绝对路径 configuration: { /* 可选配置覆盖 */ }, loggerConfig: { // 可选日志配置MCP 集成/调试 level: LogLevel.INFO, mcpMode: true, logCallback: log // MCP 日志函数 } });构造函数会对projectPath做两次校验缺失则抛MISSING_CONFIGURATION非绝对路径则抛INVALID_INPUT随后path.resolve归一化。初始化顺序initialize()方法是理解依赖关系的钥匙先创建 Logger保证后续任何日志可用ConfigManager.create(projectPath)加载配置若传入configuration覆盖项则立即updateConfig依次实例化 7 个领域门面AuthDomain→TasksDomain依赖 config 与 auth→WorkflowDomain→GitDomain→ConfigDomain→IntegrationDomain→LoopDomainawait this._tasks.initialize()完成任务的异步初始化关键跨域装配workflow.setTasksDomain(this._tasks)——工作流推进任务状态时需要回调任务域通过close()释放资源文件锁、存储句柄测试场景务必调用。4.2 领域门面一览TmCore以只读 getter 暴露全部领域能力即 CHANGELOG 中src/index.ts示例所展示的调用形态await tmcore.auth.authenticateWithOAuth(); // 认证 const tasks await tmcore.tasks.list(); // 任务列表 await tmcore.workflow.start({ taskId: 1 }); // 启动工作流 await tmcore.git.commit(feat: add feature); // Git 提交 const modelConfig tmcore.config.getModelConfig(); // 读取模型配置 await tmcore.integration.exportTasks({ ... }); // 导出任务 await tmcore.loop.run({ ... }); // 循环执行同时src/index.ts通过 Advanced API 区块向 CLI/Extension/MCP 暴露了底层类AuthManager、WorkflowOrchestrator、PreflightChecker、TaskLoaderService、ExportService、PromptService等以及任务过滤工具集filterReadyTasks、filterBlockingTasks、buildBlocksMap、ACTIONABLE_STATUSES说明 tm-core 在设计上同时服务「高层调用」与「深度集成」两类消费者。五、公共基础设施错误、路径与 Provider 常量5.1 统一错误体系CHANGELOG 规划的 Custom error classes 在 src/common/errors/task-master-error.ts 中实现为TaskMasterError它继承了原生Error并增强四类能力错误码表ERROR_CODES按域组织涵盖文件系统FILE_NOT_FOUND等、解析PARSE_ERROR、JSON_PARSE_ERROR、YAML_PARSE_ERROR、校验VALIDATION_ERROR等、网络与认证API_ERROR、AUTHENTICATION_ERROR等、任务TASK_NOT_FOUND、TASK_DEPENDENCY_ERROR、TASK_STATUS_ERROR、存储、配置、Provider 及通用错误INTERNAL_ERROR、INVALID_INPUT、NOT_IMPLEMENTED上下文ErrorContext可携带details、operation、resource、operationStack、userMessage、errorId、metadata错误链cause参数支持嵌套wrap()/withContext()可派生新错误hasCode()沿 cause 链回溯判断错误码安全与序列化getSanitizedDetails()会过滤包含password/token/key/secret/auth/credential等敏感键的 detailstoJSON()输出结构化日志。5.2 路径常量与项目边界探测src/common/constants/paths.ts 集中定义了.taskmaster目录体系config.json、state.json、tasks/tasks.json、docs/prd.txt、reports/task-complexity-report.json、templates/example_prd.txt同时保留 legacy 路径tasks/tasks.json、scripts/prd.txt、.taskmasterconfig以兼容旧项目。更关键的是三组「项目标记」TASKMASTER_PROJECT_MARKERS唯一定位 Task Master 项目的标记.taskmaster目录、config、tasks 文件、legacy configPROJECT_BOUNDARY_MARKERS向上遍历的边界——遇到.git、package.json、Cargo.toml、pyproject.toml、turbo.json等 100 种 VCS/平台/语言标记即停止向上查找避免误入 home 目录找到无关的.taskmasterOTHER_PROJECT_MARKERS非 TM 专属但常见的任务文件。这套机制配合src/common/utils/project-root-finder.ts含.test.ts与.spec.ts双份测试与path-normalizer.ts共同支撑「在任意子目录启动 CLI/MCP 时定位项目根」的能力。5.3 Provider 常量src/common/constants/providers.ts 区分了两类 AI ProviderVALIDATED_PROVIDERSanthropic、openai、google、zai、perplexity、xai、groq、mistral、azure、openrouter、bedrock、ollama需要对照supported-models.json校验与CUSTOM_PROVIDERSazure、vertex、bedrock、openrouter、ollama、lmstudio、openai-compatible、claude-code、mcp、gemini-cli、grok-cli、codex-cli。这与项目根目录 scripts/modules/supported-models.json 的模型清单相互印证是src/modules/ai/与src/modules/config/校验模型配置的常量基础。六、版本演进与发布规划从 0.26.1 到 1.0.0CHANGELOG 的主体脉络是一条清晰的「脚手架 → 完整实现」演进线这也是本文最值得对照仓库现状的部分6.1 Unreleased初始包结构与基础设施已完成该节记录了已落地的全部内容前三章的源码证据可以逐一对应初始包结构、TypeScript 严格模式、双格式构建、测试框架、代码质量工具、模块化架构与 barrel 导出、模块占位实现、文档与 README。唯一与当前仓库有出入的是工具链选型——Jest 已迁移为 Vitest、ESLint/Prettier 已迁移为 Biome建议读者以 package.json 的实际脚本为准。6.2 1.0.0 规划Tasks 116–125CHANGELOG 将完整实现拆解为 10 个任务对照当前仓库可以评估每个任务的完成度任务规划内容当前仓库实现证据Task 116 类型系统任务/项目/配置类型、Zod 校验common/types、common/schemas、modules/tasks/validationTask 117 AI Provider基接口、多厂商接入、工厂注册modules/ai/providers/base-provider.ts与 interfacesTask 118 存储层文件系统/内存适配器、工厂modules/storage/adapters/file-storage/、storage-factory.tsTask 119 任务解析PRD/Markdown/JSON 解析modules/tasks/parser/Task 120 工具函数ID 生成、日期、校验、FScommon/utils/、utils/time.utils.tsTask 121 错误处理任务/存储/Provider/校验错误common/errors/task-master-error.tsTask 122 配置系统Schema、默认配置、环境变量modules/config/loader/merger/persistence/env providerTask 123 测试设施单测、集成测试、Mock30 源码旁测试、tests/integration、src/testingfixturesTask 124 文档API 文档、示例、迁移指南README.md、本文所依据的 CHANGELOGTask 125 打包发布最终验证、发布、CI/CDexports子路径、dist产物规划从源码结构看Tasks 116–123 的主体已经实现结合 CHANGELOG Development Status 一节的符号约定✅ 完成、 进行中Task 124 文档与 Task 125 发布收尾仍是后续重点。6.3 关于文档顶部的null占位CHANGELOG 开头存在 11 个连续的## null空标题属于脚手架阶段的占位残留不影响上述内容的准确性——它们是尚未生成的版本节点实际有意义的内容从## 0.26.1开始。读者判断发布历史时应以真实版本号为准。七、如何查看与验证本文所有结论均可直接在仓库中复现验证# 1. 查看包定义、脚本与依赖 cat packages/tm-core/package.json # 2. 查看严格 TypeScript 配置 cat packages/tm-core/tsconfig.json # 3. 查看测试配置80% 覆盖率门槛、路径别名 cat packages/tm-core/vitest.config.ts # 4. 全量类型检查无产物输出 npm run typecheck --workspacepackages/tm-core # 5. 运行单元测试与覆盖率 npm run test:coverage --workspacepackages/tm-core # 6. 阅读统一门面与 barrel 导出 # packages/tm-core/src/tm-core.ts # packages/tm-core/src/index.ts阅读路线建议先读 src/index.ts 了解对外 API 全貌再读 src/tm-core.ts 理解领域装配顺序随后按需深入src/modules/domain/的具体服务与测试。若需为 tm-core 编写集成测试可直接复用 src/testing 提供的createTask、createTasksFile、TaskScenarios等 fixtures。结语tm-core的 CHANGELOG 虽以脚手架视角记录了包的诞生但当前仓库的实现已经将其推进为 claude-task-master 真正的核心引擎严格的 TypeScript 类型约束、80% 覆盖率门槛的 Vitest 测试体系、以TmCore门面为中心的七领域架构、统一的错误码与项目探测机制共同构成了上层 CLI/MCP/扩展可依赖的稳定地基。理解这份 CHANGELOG 与源码的对应关系也就掌握了整个任务管理系统的心脏结构。【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/12 2:49:45 · 阅读 1.2k claude-task-master 核心库 tm-core 全解析：包结构、工程化工具链与模块化演进路线
claude-task-master 核心库 tm-core 全解析包结构、工程化工具链与模块化演进路线【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master导读tm-core包名tm/core是 claude-task-master 项目中承担任务管理与编排能力的核心 TypeScript 库CLI、MCP 服务、编辑器扩展等上层应用都围绕它构建。本文以 packages/tm-core/CHANGELOG.md 为主体骨架结合当前仓库中 src 的真实实现系统讲解 tm-core 的目录结构、构建与测试基础设施、统一门面 API、错误处理体系、路径与 Provider 常量以及从「占位结构」到「完整实现」的发布演进路线帮助你快速理解并上手这套核心库。一、tm-core 在 claude-task-master 中的定位从 packages/tm-core/package.json 可以看到该包被描述为 Core library for Task Master - TypeScript task management system。在 monorepo 中它位于packages/tm-core与tm-bridge、tm-profiles、claude-code-plugin、ai-sdk-provider-grok-cli等包平级是整个任务管理系统的地基任务实体的建模、工作流编排、AI Provider 抽象、存储层适配、Git 集成、认证与会话管理都被收敛到这个包中。需要特别说明的是当前仓库中 tm-core 的实际实现已经远超 CHANGELOG 所描述的「占位实现」状态——src/modules下已经沉淀了 15 个功能模块的实体代码与配套测试本文后续章节将逐一对应展开。二、包结构与模块化架构CHANGELOG 的 Package Structure 一节规划了src/types/、src/providers/、src/storage/、src/parser/、src/utils/、src/errors/、tests/七个占位目录。从当前仓库的实际目录树看这一骨架已经演化成了更精细的分层结构核心是src/common跨模块公共件与src/modules业务领域模块的两级划分src/common/所有模块共享的公共设施constants/路径常量paths.ts与 Provider 校验常量providers.tserrors/统一错误类TaskMasterError与错误码表task-master-error.tsinterfaces/IConfiguration、存储层接口等抽象契约logger/可插拔的日志工厂支持 MCP 日志回调mappers/任务实体映射器TaskMapperschemas/基于 Zod 的校验 Schema如 task-idtypes/数据库类型、仓库类型、legacy 兼容类型utils/Git 工具、ID 生成器、路径规范化、项目根目录查找src/modules/15 个领域模块每个模块遵循 domain services managers/adapters 的内部结构ai/AI Provider 接口与基础实现auth/认证领域OAuth 服务、会话管理、Supabase 会话存储、命令守卫briefs/任务简报领域commands/、dependencies/命令与依赖关系config/配置领域ConfigManager、加载/合并/持久化服务、环境变量 Providerexecution/执行器Claude 执行器、执行器工厂git/Git 领域适配器、分支名生成、提交信息生成、范围检测、模板引擎integration/集成领域Supabase 客户端、导出服务、任务展开服务loop/循环执行领域默认/去重/熵/代码检查/测试覆盖等预设prompts/提示词服务与触发条件评估reports/复杂度报告管理storage/存储层文件存储适配器、API 存储、存储工厂、活动日志tasks/任务领域实体、仓库、解析器、校验、服务、Supabase 仓库ui/、workflow/UI 与工作流编排状态管理、TDD 阶段、测试结果校验src/testing/面向集成测试的 fixturescreateTask、createTasksFile、TaskScenarios等src/index.tsbarrel 导出统一暴露createTmCore与全部公开类型这种分层与 CHANGELOG 规划的模块化思路一脉相承但落地为更符合领域驱动风格的目录约定每个领域模块自带测试文件如auth-manager.spec.ts、config-manager.spec.ts、workflow-orchestrator.spec.ts测试与源码同目录共存便于快速定位。三、开发基础设施构建、测试与代码质量CHANGELOG 的 Development Infrastructure 一节列出的工具链在当前仓库中均有对应落点其中一部分发生了实际演进值得对照阅读3.1 TypeScript 严格模式packages/tm-core/tsconfig.json 完全贯彻了 CHANGELOG 记录的 TypeScript support with strict modetarget: ES2022、module: NodeNext、moduleResolution: NodeNext源码采用显式.js后缀导入如./modules/tasks/tasks-domain.js符合 NodeNext ESM 规范strict: true并显式开启noImplicitAny、strictNullChecks、strictFunctionTypes、strictBindCallApply、noImplicitThis、alwaysStrict等全部严格检查项额外开启noUnusedLocals、noUnusedParameters、noImplicitReturns、noFallthroughCasesInSwitch从编译期拦截未使用变量与缺失返回路径declaration、declarationMap、sourceMap全开产物输出到./dist。3.2 双格式构建的演进CHANGELOG 记录的是 Dual ESM/CJS build system with tsup。从当前仓库看package.json 采用了type: module的 ESM 优先策略exports字段将.、./testing、./auth、./storage、./config、./providers、./services、./errors、./logger、./types、./interfaces、./utils等子路径全部直接指向./src/...的 TS 源码main: ./dist/index.js与types: ./src/index.ts并存说明当前阶段更强调「源码即入口」的开发体验仓库根目录同时存在 tsdown.config.ts可推断最终发布形态仍会收敛到统一构建产物。读者在接入时应以exports字段为权威依据按子路径做按需导入。3.3 测试框架从 Jest 到 VitestCHANGELOG 明确记录 Jest testing framework with TypeScript support但当前仓库的实际脚本与配置已迁移到 Vitestpackage.json中的test系列脚本全部为vitest run/vitest run --coverage并配套 packages/tm-core/vitest.config.ts。该配置在根配置基础上做了三件事测试范围同时纳入tests/**与src/**下的*.test.ts/*.spec.ts实现「源码旁测试」覆盖率门槛将 branches / functions / lines / statements 四个维度的阈值统一提到80%显著高于默认要求体现核心库的质量底线路径别名配置→src以及/types、/providers、/storage、/parser、/utils、/errors等子路径别名与 CHANGELOG 规划的子目录一一对应。仓库中已沉淀大量测试证据src内散布着 30 个.spec.ts/.test.ts如 presets.spec.ts、config-manager.spec.tstests/integration下另有 12 个集成测试文件与 tests/setup.ts 全局初始化。3.4 代码质量与依赖选型CHANGELOG 记录的 ESLint and Prettier 在仓库中同样演化为 Biomepackage.json的lint/format脚本均为biome check/biome format根目录 biome.json 统一管理。运行npm run typechecktsc --noEmit即可在不产出文件的前提下完成全量类型校验。运行时依赖的选型也体现了库的定位见 package.jsonzod^4任务 ID、配置等结构的运行时校验src/common/schemas/与src/modules/tasks/validation/均基于 Zodsupabase/supabase-js云端存储与认证后端的客户端fs-extra、proper-lockfile、steno文件系统操作的健壮性原子写入、跨进程文件锁simple-gitGit 领域操作的底层封装date-fns日期格式化。四、统一门面TmCore 与 createTmCoreCHANGELOG 虽未展开描述 API 形态但这是当前仓库最重要的实现事实。入口文件 src/index.ts 的注释明确写道createTmCore是使用 tm-core 的唯一方式门面类 src/tm-core.ts 通过私有构造函数 静态工厂方法TmCore.create()保证实例永远处于已初始化状态。4.1 初始化选项import { createTmCore } from tm/core; const tmcore await createTmCore({ projectPath: process.cwd(), // 必需项目根目录绝对路径 configuration: { /* 可选配置覆盖 */ }, loggerConfig: { // 可选日志配置MCP 集成/调试 level: LogLevel.INFO, mcpMode: true, logCallback: log // MCP 日志函数 } });构造函数会对projectPath做两次校验缺失则抛MISSING_CONFIGURATION非绝对路径则抛INVALID_INPUT随后path.resolve归一化。初始化顺序initialize()方法是理解依赖关系的钥匙先创建 Logger保证后续任何日志可用ConfigManager.create(projectPath)加载配置若传入configuration覆盖项则立即updateConfig依次实例化 7 个领域门面AuthDomain→TasksDomain依赖 config 与 auth→WorkflowDomain→GitDomain→ConfigDomain→IntegrationDomain→LoopDomainawait this._tasks.initialize()完成任务的异步初始化关键跨域装配workflow.setTasksDomain(this._tasks)——工作流推进任务状态时需要回调任务域通过close()释放资源文件锁、存储句柄测试场景务必调用。4.2 领域门面一览TmCore以只读 getter 暴露全部领域能力即 CHANGELOG 中src/index.ts示例所展示的调用形态await tmcore.auth.authenticateWithOAuth(); // 认证 const tasks await tmcore.tasks.list(); // 任务列表 await tmcore.workflow.start({ taskId: 1 }); // 启动工作流 await tmcore.git.commit(feat: add feature); // Git 提交 const modelConfig tmcore.config.getModelConfig(); // 读取模型配置 await tmcore.integration.exportTasks({ ... }); // 导出任务 await tmcore.loop.run({ ... }); // 循环执行同时src/index.ts通过 Advanced API 区块向 CLI/Extension/MCP 暴露了底层类AuthManager、WorkflowOrchestrator、PreflightChecker、TaskLoaderService、ExportService、PromptService等以及任务过滤工具集filterReadyTasks、filterBlockingTasks、buildBlocksMap、ACTIONABLE_STATUSES说明 tm-core 在设计上同时服务「高层调用」与「深度集成」两类消费者。五、公共基础设施错误、路径与 Provider 常量5.1 统一错误体系CHANGELOG 规划的 Custom error classes 在 src/common/errors/task-master-error.ts 中实现为TaskMasterError它继承了原生Error并增强四类能力错误码表ERROR_CODES按域组织涵盖文件系统FILE_NOT_FOUND等、解析PARSE_ERROR、JSON_PARSE_ERROR、YAML_PARSE_ERROR、校验VALIDATION_ERROR等、网络与认证API_ERROR、AUTHENTICATION_ERROR等、任务TASK_NOT_FOUND、TASK_DEPENDENCY_ERROR、TASK_STATUS_ERROR、存储、配置、Provider 及通用错误INTERNAL_ERROR、INVALID_INPUT、NOT_IMPLEMENTED上下文ErrorContext可携带details、operation、resource、operationStack、userMessage、errorId、metadata错误链cause参数支持嵌套wrap()/withContext()可派生新错误hasCode()沿 cause 链回溯判断错误码安全与序列化getSanitizedDetails()会过滤包含password/token/key/secret/auth/credential等敏感键的 detailstoJSON()输出结构化日志。5.2 路径常量与项目边界探测src/common/constants/paths.ts 集中定义了.taskmaster目录体系config.json、state.json、tasks/tasks.json、docs/prd.txt、reports/task-complexity-report.json、templates/example_prd.txt同时保留 legacy 路径tasks/tasks.json、scripts/prd.txt、.taskmasterconfig以兼容旧项目。更关键的是三组「项目标记」TASKMASTER_PROJECT_MARKERS唯一定位 Task Master 项目的标记.taskmaster目录、config、tasks 文件、legacy configPROJECT_BOUNDARY_MARKERS向上遍历的边界——遇到.git、package.json、Cargo.toml、pyproject.toml、turbo.json等 100 种 VCS/平台/语言标记即停止向上查找避免误入 home 目录找到无关的.taskmasterOTHER_PROJECT_MARKERS非 TM 专属但常见的任务文件。这套机制配合src/common/utils/project-root-finder.ts含.test.ts与.spec.ts双份测试与path-normalizer.ts共同支撑「在任意子目录启动 CLI/MCP 时定位项目根」的能力。5.3 Provider 常量src/common/constants/providers.ts 区分了两类 AI ProviderVALIDATED_PROVIDERSanthropic、openai、google、zai、perplexity、xai、groq、mistral、azure、openrouter、bedrock、ollama需要对照supported-models.json校验与CUSTOM_PROVIDERSazure、vertex、bedrock、openrouter、ollama、lmstudio、openai-compatible、claude-code、mcp、gemini-cli、grok-cli、codex-cli。这与项目根目录 scripts/modules/supported-models.json 的模型清单相互印证是src/modules/ai/与src/modules/config/校验模型配置的常量基础。六、版本演进与发布规划从 0.26.1 到 1.0.0CHANGELOG 的主体脉络是一条清晰的「脚手架 → 完整实现」演进线这也是本文最值得对照仓库现状的部分6.1 Unreleased初始包结构与基础设施已完成该节记录了已落地的全部内容前三章的源码证据可以逐一对应初始包结构、TypeScript 严格模式、双格式构建、测试框架、代码质量工具、模块化架构与 barrel 导出、模块占位实现、文档与 README。唯一与当前仓库有出入的是工具链选型——Jest 已迁移为 Vitest、ESLint/Prettier 已迁移为 Biome建议读者以 package.json 的实际脚本为准。6.2 1.0.0 规划Tasks 116–125CHANGELOG 将完整实现拆解为 10 个任务对照当前仓库可以评估每个任务的完成度任务规划内容当前仓库实现证据Task 116 类型系统任务/项目/配置类型、Zod 校验common/types、common/schemas、modules/tasks/validationTask 117 AI Provider基接口、多厂商接入、工厂注册modules/ai/providers/base-provider.ts与 interfacesTask 118 存储层文件系统/内存适配器、工厂modules/storage/adapters/file-storage/、storage-factory.tsTask 119 任务解析PRD/Markdown/JSON 解析modules/tasks/parser/Task 120 工具函数ID 生成、日期、校验、FScommon/utils/、utils/time.utils.tsTask 121 错误处理任务/存储/Provider/校验错误common/errors/task-master-error.tsTask 122 配置系统Schema、默认配置、环境变量modules/config/loader/merger/persistence/env providerTask 123 测试设施单测、集成测试、Mock30 源码旁测试、tests/integration、src/testingfixturesTask 124 文档API 文档、示例、迁移指南README.md、本文所依据的 CHANGELOGTask 125 打包发布最终验证、发布、CI/CDexports子路径、dist产物规划从源码结构看Tasks 116–123 的主体已经实现结合 CHANGELOG Development Status 一节的符号约定✅ 完成、 进行中Task 124 文档与 Task 125 发布收尾仍是后续重点。6.3 关于文档顶部的null占位CHANGELOG 开头存在 11 个连续的## null空标题属于脚手架阶段的占位残留不影响上述内容的准确性——它们是尚未生成的版本节点实际有意义的内容从## 0.26.1开始。读者判断发布历史时应以真实版本号为准。七、如何查看与验证本文所有结论均可直接在仓库中复现验证# 1. 查看包定义、脚本与依赖 cat packages/tm-core/package.json # 2. 查看严格 TypeScript 配置 cat packages/tm-core/tsconfig.json # 3. 查看测试配置80% 覆盖率门槛、路径别名 cat packages/tm-core/vitest.config.ts # 4. 全量类型检查无产物输出 npm run typecheck --workspacepackages/tm-core # 5. 运行单元测试与覆盖率 npm run test:coverage --workspacepackages/tm-core # 6. 阅读统一门面与 barrel 导出 # packages/tm-core/src/tm-core.ts # packages/tm-core/src/index.ts阅读路线建议先读 src/index.ts 了解对外 API 全貌再读 src/tm-core.ts 理解领域装配顺序随后按需深入src/modules/domain/的具体服务与测试。若需为 tm-core 编写集成测试可直接复用 src/testing 提供的createTask、createTasksFile、TaskScenarios等 fixtures。结语tm-core的 CHANGELOG 虽以脚手架视角记录了包的诞生但当前仓库的实现已经将其推进为 claude-task-master 真正的核心引擎严格的 TypeScript 类型约束、80% 覆盖率门槛的 Vitest 测试体系、以TmCore门面为中心的七领域架构、统一的错误码与项目探测机制共同构成了上层 CLI/MCP/扩展可依赖的稳定地基。理解这份 CHANGELOG 与源码的对应关系也就掌握了整个任务管理系统的心脏结构。【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考