@cloudbase/cli 2.10.0-beta.0 → 2.10.1-alpha.0

package/specs/tcb-pull-cnb-support/requirements.md

@@ -1,56 +0,0 @@
-# 需求文档
-
-## 介绍
-
-为 `tcb pull` 命令增加 cnb.cool 仓库的支持，使开发者能够直接从 cnb.cool 平台拉取项目模板。
-
-## 需求
-
-### 需求 1 - 支持 cnb.cool URL 解析
-
-**用户故事：** 作为开发者，我希望能够通过 `tcb pull https://cnb.cool/username/repo` 直接拉取 cnb.cool 上的项目模板。
-
-#### 验收标准
-
-1. When 用户输入 `tcb pull https://cnb.cool/username/repo`，the tcb pull 命令 shall 识别出这是一个 cnb.cool URL 并进行相应处理。
-2. When 用户输入 `tcb pull https://cnb.cool/username/repo/tree/branch/path`，the tcb pull 命令 shall 支持拉取 cnb.cool 仓库的指定分支和子目录。
-3. When 用户输入无效的 cnb.cool URL，the tcb pull 命令 shall 显示清晰的错误提示信息。
-
-### 需求 2 - cnb.cool 仓库拉取功能
-
-**用户故事：** 作为开发者，我希望 `tcb pull` 命令能够成功拉取 cnb.cool 上的项目模板到本地。
-
-#### 验收标准
-
-1. When 用户执行 `tcb pull https://cnb.cool/username/repo`，the 系统 shall 成功下载并解压 cnb.cool 上的仓库内容。
-2. When 用户指定输出目录时，the 系统 shall 将模板内容保存到指定的目录中。
-3. When 拉取过程中发生错误，the 系统 shall 显示详细的错误信息并提供可能的解决方案。
-
-### 需求 3 - 命令帮助更新
-
-**用户故事：** 作为开发者，我希望在 `tcb pull` 命令的帮助信息中看到 cnb.cool 的使用说明。
-
-#### 验收标准
-
-1. When 用户执行 `tcb pull --help`，the 帮助信息 shall 包含 cnb.cool 的支持说明和示例。
-2. When 用户执行 `tcb pull list`，the 模板列表 shall 包含 cnb.cool 的支持格式说明。
-
-## 示例
-
-```bash
-# 拉取 cnb.cool 上的项目
-tcb pull https://cnb.cool/tencent/cloud/cloudbase/CloudBase-AI-ToolKit
-
-# 拉取指定分支和子目录
-tcb pull https://cnb.cool/shuishenhuole/learning/tree/main/examples
-
-# 指定输出目录
-tcb pull https://cnb.cool/username/repo --output ./my-project
-```
-
-
-
-
-
-
-

package/specs/tcb-pull-cnb-support/tasks.md

@@ -1,101 +0,0 @@
-# 实施计划
-
-## 已完成任务
-
-- [x] 1. 更新 GitUrlInfo 接口以支持 cnb 平台
-  - 在 `GitUrlInfo` 接口中添加 `'cnb'` 平台类型
-  - 确保类型定义的完整性
-
-- [x] 2. 实现 cnb.cool URL 识别逻辑
-  - 修改 `isGitUrl()` 方法识别 cnb.cool URLs
-  - 添加对 `cnb.cool` 域名的支持
-
-- [x] 3. 实现 cnb.cool URL 解析逻辑
-  - 修改 `parseGitUrl()` 方法解析 cnb.cool URLs
-  - 支持基础 URL 和带分支/子目录的 URL
-  - 处理 SSH URL 中的 cnb.cool 支持
-
-- [x] 4. 实现 cnb.cool Git URL 构建
-  - 修改 `buildGitUrl()` 方法支持 cnb 平台
-  - 构建标准的 Git URL 格式
-
-- [x] 5. 更新命令帮助信息
-  - 更新 `tcb pull` 命令的帮助描述
-  - 添加 cnb.cool 的使用示例
-  - 更新 `tcb pull list` 的输出信息
-
-- [x] 6. 编写单元测试
-  - 创建 `template-manager-cnb.test.ts` 测试文件
-  - 覆盖 URL 解析、验证和构建的测试用例
-  - 确保测试覆盖率达到要求
-
-- [x] 7. 验证功能完整性
-  - 运行测试验证功能正确性
-  - 检查代码编译无错误
-  - 验证帮助信息显示正确
-
-## 验收标准
-
-### 功能验收标准
-1. **URL 解析功能**
-   - [x] 能够正确解析 `https://cnb.cool/user/repo` 格式
-   - [x] 能够正确解析 `https://cnb.cool/user/repo/tree/branch/path` 格式
-   - [x] 能够正确处理 HTTP 和 HTTPS 协议
-
-2. **Git 仓库支持**
-   - [x] 能够构建正确的 cnb.cool Git URL
-   - [x] 能够复用现有的 Git 下载逻辑
-   - [x] 支持分支和子目录拉取
-
-3. **用户界面**
-   - [x] 命令帮助信息包含 cnb.cool 支持说明
-   - [x] `tcb pull list` 显示 cnb.cool 支持格式
-   - [x] 提供清晰的使用示例
-
-4. **测试覆盖**
-   - [x] URL 解析测试通过
-   - [x] URL 验证测试通过
-   - [x] Git URL 构建测试通过
-   - [x] 集成测试通过
-
-### 性能验收标准
-- [x] 代码编译无错误
-- [x] 测试执行时间在合理范围内
-- [x] 不影响现有功能的性能
-
-### 兼容性验收标准
-- [x] 不破坏现有的 GitHub/Gitee 支持
-- [x] 保持向后兼容性
-- [x] API 接口保持不变
-
-## 技术债务和风险
-
-### 已识别的技术债务
-1. **测试覆盖率**：当前测试主要集中在 URL 解析，缺少实际 Git 克隆的集成测试
-2. **错误处理**：cnb.cool 特有的错误场景可能需要更细致的处理
-
-### 风险评估
-1. **低风险**：URL 解析逻辑相对简单，测试覆盖充分
-2. **中风险**：实际 cnb.cool 仓库的网络访问可能有未知问题
-3. **低风险**：复用现有 Git 逻辑，减少了新代码的复杂性
-
-## 后续优化建议
-
-1. **集成测试增强**
-   - 添加实际 cnb.cool 仓库的拉取测试
-   - 模拟网络错误场景的测试
-
-2. **用户体验优化**
-   - 添加 cnb.cool 特有的错误提示
-   - 支持更多的 URL 格式变体
-
-3. **监控和运维**
-   - 添加 cnb.cool 拉取的性能监控
-   - 记录错误日志用于问题排查
-
-
-
-
-
-
-

package/specs/tcb-pull-mcp-integration/design.md

@@ -1,153 +0,0 @@
-# 技术方案设计
-
-## 架构概述
-
-本方案通过在 `TemplateManager` 中集成 MCP 配置修改功能，使 `tcb pull` 命令在下载模板后能够自动修改 MCP 配置文件，将 npx 命令替换为 `cloudbase-mcp` 命令，从而与 `tcb ai` 命令保持一致的行为。
-
-## 技术栈
-
-- Node.js CLI 工具
-- `fs-extra`: 文件系统操作
-- `simple-git`: Git 操作
-- 现有的 MCP 配置修改逻辑
-
-## 技术选型
-
-### 1. 代码复用策略
-- 将 `tcb ai` 命令中的 MCP 配置修改逻辑提取到独立的工具类中
-- 在 `TemplateManager` 中调用这些工具类
-- 避免代码重复，保持逻辑一致性
-
-### 2. 集成点设计
-- 在 `TemplateManager.pullTemplate` 方法的最后阶段添加 MCP 配置修改
-- 在 `copyFromTempToTarget` 方法完成后执行 MCP 配置修改
-- 确保不影响现有的模板下载流程
-
-### 3. 错误处理策略
-- MCP 配置修改失败不应影响模板下载的成功完成
-- 提供详细的日志记录，便于问题排查
-- 支持用户选择跳过 MCP 配置修改
-
-## 核心组件设计
-
-### 1. MCPConfigModifier 工具类
-```typescript
-export class MCPConfigModifier {
-    // 修改指定目录下的所有 MCP 配置文件
-    async modifyMCPConfigs(extractDir: string, log: Logger): Promise<void>
-    
-    // 修改单个 JSON 配置文件
-    private async modifyMCPJsonFile(filePath: string, log: Logger): Promise<void>
-    
-    // 修改单个 TOML 配置文件
-    private async modifyMCPTomlFile(filePath: string, log: Logger): Promise<void>
-}
-```
-
-### 2. TemplateManager 增强
-```typescript
-export class TemplateManager {
-    private mcpConfigModifier: MCPConfigModifier
-    
-    constructor() {
-        this.mcpConfigModifier = new MCPConfigModifier()
-    }
-    
-    // 在模板复制完成后调用 MCP 配置修改
-    private async copyFromTempToTarget(tempDir: string, targetPath: string, force: boolean, log: Logger): Promise<void> {
-        // ... 现有的复制逻辑 ...
-        
-        // 新增：修改 MCP 配置文件
-        try {
-            await this.mcpConfigModifier.modifyMCPConfigs(targetPath, log)
-        } catch (error) {
-            log.warn(`⚠️ MCP 配置修改失败: ${error.message}`)
-        }
-    }
-}
-```
-
-## 数据流设计
-
-```mermaid
-graph TD
-    A[tcb pull 命令] --> B[TemplateManager.pullTemplate]
-    B --> C[下载模板到临时目录]
-    C --> D[复制到目标目录]
-    D --> E[MCPConfigModifier.modifyMCPConfigs]
-    E --> F[遍历 IDE 配置文件]
-    F --> G{文件类型判断}
-    G -->|JSON| H[modifyMCPJsonFile]
-    G -->|TOML| I[modifyMCPTomlFile]
-    H --> J[替换 npx 命令]
-    I --> J
-    J --> K[保存修改后的配置]
-    K --> L[完成]
-```
-
-## 配置文件映射
-
-复用 `tcb ai` 命令中已定义的 IDE 配置文件映射：
-
-```typescript
-const IDE_FILE_MAPPINGS: Record<string, IdeFileDescriptor[]> = {
-    cursor: [
-        { path: '.cursor/rules/cloudbase-rules.mdc' },
-        { path: '.cursor/mcp.json', isMcpConfig: true }
-    ],
-    'claude-code': [
-        { path: 'CLAUDE.md' }, 
-        { path: '.mcp.json', isMcpConfig: true }
-    ],
-    // ... 其他 IDE 配置
-}
-```
-
-## 测试策略
-
-### 1. 单元测试
-- 测试 `MCPConfigModifier` 类的各个方法
-- 测试不同格式配置文件的修改逻辑
-- 测试错误处理机制
-
-### 2. 集成测试
-- 测试 `tcb pull` 命令的完整流程
-- 测试内置模板和 Git 仓库的 MCP 配置修改
-- 测试与现有功能的兼容性
-
-### 3. 端到端测试
-- 测试完整的模板下载和配置修改流程
-- 测试不同 IDE 配置文件的生成和修改
-- 测试错误场景的处理
-
-## 安全性考虑
-
-- 确保 MCP 配置修改不影响模板下载的安全性
-- 验证修改后的配置文件格式正确性
-- 防止路径遍历攻击
-
-## 性能考虑
-
-- MCP 配置修改在模板复制完成后异步执行
-- 避免重复读取和解析配置文件
-- 优化文件遍历和修改逻辑
-
-## 实施计划
-
-```mermaid
-graph TD
-    A[提取 MCP 配置修改逻辑] --> B[创建 MCPConfigModifier 类]
-    B --> C[修改 TemplateManager 集成]
-    C --> D[测试验证]
-    D --> E[文档更新]
-```
-
-
-
-
-
-
-
-
-
-

package/specs/tcb-pull-mcp-integration/implementation-summary.md

@@ -1,127 +0,0 @@
-# 实现总结
-
-## 已完成功能
-
-### 1. MCP 配置修改器 ✅
-
-- **功能**: 创建了独立的 `MCPConfigModifier` 工具类
-- **位置**: `src/utils/mcp-config-modifier.ts`
-- **能力**: 
-  - 自动检测并修改所有 IDE 的 MCP 配置文件
-  - 支持 JSON 和 TOML 两种格式
-  - 将 `npx npm-global-exec@latest @cloudbase/cloudbase-mcp@latest` 替换为 `cloudbase-mcp`
-  - 递归处理嵌套配置
-  - 完整的错误处理和日志记录
-
-### 2. TemplateManager 集成 ✅
-
-- **功能**: 在 `TemplateManager` 中集成了 MCP 配置修改功能
-- **位置**: `src/utils/template-manager.ts`
-- **集成点**: 在 `copyFromTempToTarget` 方法完成后自动调用
-- **特性**: 
-  - 不影响现有的模板下载流程
-  - 错误处理确保 MCP 配置修改失败不影响模板下载
-  - 支持所有内置模板和 Git 仓库下载
-
-### 3. 测试覆盖 ✅
-
-- **单元测试**: `test/utils/mcp-config-modifier.test.ts`
-  - 测试 JSON 配置文件修改
-  - 测试 TOML 配置文件修改
-  - 测试嵌套配置处理
-  - 测试错误处理机制
-  - 测试边界情况
-
-- **集成测试**: `test/utils/template-manager-mcp.test.ts`
-  - 测试模板复制后的 MCP 配置修改
-  - 测试不同文件格式的处理
-  - 测试与现有功能的兼容性
-  - 测试错误场景的处理
-
-### 4. 支持的 IDE 配置 ✅
-
-- **Cursor**: `.cursor/mcp.json`
-- **VSCode**: `.vscode/mcp.json`
-- **Claude Code**: `.mcp.json`
-- **OpenAI Codex**: `.codex/config.toml`
-- **OpenCode**: `.opencode.json`
-- **CodeBuddy**: `.rules/cloudbase-rules.md`
-- **Qwen Code**: `.qwen/settings.json`
-- **百度 Comate**: `.comate/mcp.json`
-- **RooCode**: `.roo/mcp.json`
-- **Aider**: `mcp.json`
-- 以及其他主流 AI 编辑器
-
-## 技术实现
-
-### 1. 代码复用策略
-
-- 从 `tcb ai` 命令中提取了 MCP 配置修改逻辑
-- 创建了独立的工具类，避免代码重复
-- 保持了与原始实现完全一致的逻辑
-
-### 2. 集成设计
-
-- 在 `TemplateManager` 的合适时机调用 MCP 配置修改
-- 使用依赖注入模式，便于测试和维护
-- 错误处理确保核心功能不受影响
-
-### 3. 配置修改逻辑
-
-- **JSON 文件**: 要求同时包含 `npm-global-exec@latest` 和 `@cloudbase/cloudbase-mcp@latest`
-- **TOML 文件**: 只要求包含 `@cloudbase/cloudbase-mcp@latest`
-- 自动添加 `INTEGRATION_IDE: "CloudBaseCLI"` 环境变量
-
-## 使用效果
-
-### 1. 用户体验提升
-
-- 用户使用 `tcb pull` 下载模板后，MCP 配置自动优化
-- 无需手动安装额外的 MCP 包
-- 配置成功率显著提高
-
-### 2. 功能一致性
-
-- `tcb pull` 和 `tcb ai` 命令在 MCP 配置修改方面完全一致
-- 用户无需学习不同的配置方式
-- 维护成本降低
-
-### 3. 向后兼容性
-
-- 现有功能完全不受影响
-- 新增功能为可选，不会破坏现有流程
-- 错误处理确保稳定性
-
-## 测试验证
-
-### 1. 自动化测试
-
-- 所有测试用例通过 ✅
-- 覆盖了主要功能点和边界情况
-- 测试覆盖率良好
-
-### 2. 手动验证
-
-- 创建了测试配置文件进行功能验证
-- JSON 和 TOML 格式修改都正常工作
-- 嵌套配置处理正确
-
-## 总结
-
-成功实现了在 `tcb pull` 命令中集成 MCP 配置修改功能，使该命令与 `tcb ai` 命令保持一致的行为。主要成果包括：
-
-1. **功能完整性**: 支持所有主流 IDE 的 MCP 配置文件
-2. **技术质量**: 代码结构清晰，测试覆盖完整
-3. **用户体验**: 自动化配置修改，提高成功率
-4. **维护性**: 代码复用，逻辑一致，易于维护
-
-该功能现在已经可以投入使用，用户在使用 `tcb pull` 命令下载模板时将自动获得优化后的 MCP 配置。
-
-
-
-
-
-
-
-
-

package/specs/tcb-pull-mcp-integration/requirements.md

@@ -1,68 +0,0 @@
-# 需求文档
-
-## 介绍
-
-当前 `tcb ai` 命令在下载模板时会自动修改 MCP 配置文件，将 `npx npm-global-exec@latest @cloudbase/cloudbase-mcp@latest` 命令替换为 `cloudbase-mcp`，但 `tcb pull` 命令没有实现这个功能。这导致用户使用 `tcb pull` 下载的模板中的 MCP 配置仍然使用 npx 命令，需要额外安装依赖，降低了配置成功率。
-
-## 需求
-
-### 需求 1 - tcb pull 命令集成 MCP 配置修改
-
-**用户故事：** 作为开发者，我希望使用 `tcb pull` 命令下载模板后，系统能够自动修改 MCP 配置文件，将 npx 命令替换为 CLI 提供的全局命令，避免额外的依赖安装。
-
-#### 验收标准
-
-1. When 使用 `tcb pull` 命令下载模板完成后，the 系统 shall 自动检测并修改所有 MCP 配置文件
-2. When 发现 `.cursor/mcp.json` 等配置文件时，the 系统 shall 将 `npx npm-global-exec@latest @cloudbase/cloudbase-mcp@latest` 替换为 `cloudbase-mcp`
-3. When 修改完成后，the 系统 shall 验证配置文件的正确性
-4. When 用户使用 `tcb pull` 下载的模板时，the MCP 功能 shall 无需额外安装即可正常工作
-
-### 需求 2 - 保持与 tcb ai 命令的一致性
-
-**用户故事：** 作为开发者，我希望 `tcb pull` 和 `tcb ai` 命令在模板下载和 MCP 配置修改方面保持一致的行为，避免混淆。
-
-#### 验收标准
-
-1. When 使用 `tcb pull` 下载模板时，the MCP 配置修改逻辑 shall 与 `tcb ai` 命令完全一致
-2. When 支持相同的 IDE 配置文件格式时，the 系统 shall 使用相同的修改规则
-3. When 处理 JSON 和 TOML 格式时，the 系统 shall 使用相同的转换逻辑
-4. When 出现错误时，the 系统 shall 提供相同的错误处理和日志记录
-
-### 需求 3 - 支持所有内置模板和 Git 仓库
-
-**用户故事：** 作为开发者，我希望无论从内置模板还是 Git 仓库下载内容，`tcb pull` 命令都能正确处理 MCP 配置。
-
-#### 验收标准
-
-1. When 下载内置模板（miniprogram、react、vue、uniapp、rules）时，the 系统 shall 自动修改 MCP 配置
-2. When 从 Git 仓库下载模板时，the 系统 shall 自动修改 MCP 配置
-3. When 从 Git 子目录下载内容时，the 系统 shall 自动修改 MCP 配置
-4. When 支持多种 IDE 配置时，the 系统 shall 处理所有相关的配置文件
-
-### 需求 4 - 向后兼容性
-
-**用户故事：** 作为开发者，我希望新功能不会影响现有的 `tcb pull` 命令功能，保持向后兼容。
-
-#### 验收标准
-
-1. When 现有 `tcb pull` 命令功能使用时，the 系统 shall 保持原有行为不变
-2. When 新增 MCP 配置修改功能时，the 系统 shall 不影响模板下载的核心流程
-3. When 出现 MCP 配置修改失败时，the 系统 shall 不影响模板下载的成功完成
-4. When 用户可以选择跳过 MCP 配置修改时，the 系统 shall 提供相应的选项
-
-## 技术约束
-
-- 必须复用 `tcb ai` 命令中已有的 MCP 配置修改逻辑
-- 必须支持 JSON 和 TOML 两种配置文件格式
-- 必须支持所有已定义的 IDE 配置文件映射
-- 必须保持与现有代码架构的一致性
-
-
-
-
-
-
-
-
-
-

package/specs/tcb-pull-mcp-integration/tasks.md

@@ -1,125 +0,0 @@
-# 实施计划
-
-## 阶段一：代码重构和提取
-
-- [x] 1. 提取 MCP 配置修改逻辑
-  - 从 `src/utils/ai/router.ts` 中提取 `modifyMCPConfigs` 相关方法
-  - 创建独立的 `MCPConfigModifier` 工具类
-  - 提取 IDE 配置文件映射常量
-  - 提取配置文件格式推断逻辑
-  - _需求: 需求 1, 需求 2
-
-- [x] 2. 创建 MCPConfigModifier 类
-  - 实现 `modifyMCPConfigs` 主方法
-  - 实现 `modifyMCPJsonFile` 方法
-  - 实现 `modifyMCPTomlFile` 方法
-  - 实现 `objectToToml` 辅助方法
-  - 添加完整的错误处理和日志记录
-  - _需求: 需求 1, 需求 2
-
-- [x] 3. 提取共享常量和类型
-  - 将 `IDE_FILE_MAPPINGS` 常量移动到共享位置
-  - 将 `IdeFileDescriptor` 接口移动到共享位置
-  - 将 `inferConfigFormat` 函数移动到共享位置
-  - 确保类型定义的一致性
-  - _需求: 需求 2
-
-## 阶段二：TemplateManager 集成
-
-- [x] 4. 修改 TemplateManager 类
-  - 在 `TemplateManager` 构造函数中初始化 `MCPConfigModifier`
-  - 在 `copyFromTempToTarget` 方法完成后调用 MCP 配置修改
-  - 添加错误处理，确保 MCP 配置修改失败不影响模板下载
-  - 添加相应的日志记录
-  - _需求: 需求 1, 需求 4
-
-- [x] 5. 集成点优化
-  - 确保 MCP 配置修改在正确的时机执行
-  - 优化执行顺序，避免重复文件操作
-  - 添加性能监控和日志记录
-  - 支持可选的 MCP 配置修改跳过
-  - _需求: 需求 1, 需求 4
-
-## 阶段三：测试和验证
-
-- [x] 6. 单元测试编写
-  - 为 `MCPConfigModifier` 类编写单元测试
-  - 测试 JSON 配置文件修改逻辑
-  - 测试 TOML 配置文件修改逻辑
-  - 测试错误处理机制
-  - 测试边界情况
-  - _需求: 需求 1, 需求 2
-
-- [x] 7. 集成测试编写
-  - 测试 `tcb pull` 命令的完整流程
-  - 测试内置模板的 MCP 配置修改
-  - 测试 Git 仓库的 MCP 配置修改
-  - 测试 Git 子目录的 MCP 配置修改
-  - 测试与现有功能的兼容性
-  - _需求: 需求 1, 需求 3
-
-- [x] 8. 端到端测试
-  - 测试完整的模板下载和配置修改流程
-  - 测试不同 IDE 配置文件的生成和修改
-  - 测试错误场景的处理和恢复
-  - 测试性能影响和资源使用
-  - _需求: 需求 1, 需求 2, 需求 3
-
-## 阶段四：文档和优化
-
-- [ ] 9. 文档更新
-  - 更新 `docs/template-pull.md` 文档
-  - 添加 MCP 配置修改功能的说明
-  - 更新命令使用示例
-  - 添加故障排除指南
-  - _需求: 需求 1, 需求 2
-
-- [ ] 10. 代码优化
-  - 优化文件遍历和修改逻辑
-  - 减少重复的文件系统操作
-  - 优化内存使用和性能
-  - 添加配置选项和开关
-  - _需求: 需求 4
-
-## 阶段五：发布和部署
-
-- [ ] 11. 代码审查
-  - 确保代码质量和一致性
-  - 验证与现有架构的兼容性
-  - 检查安全性和性能影响
-  - 确保测试覆盖率
-  - _需求: 所有需求
-
-- [ ] 12. 发布准备
-  - 更新版本号和变更日志
-  - 准备发布说明
-  - 验证所有功能正常工作
-  - 准备回滚计划
-  - _需求: 所有需求
-
-## 验收标准检查
-
-### 需求 1 - tcb pull 命令集成 MCP 配置修改
-- [x] When 使用 `tcb pull` 命令下载模板完成后，the 系统 shall 自动检测并修改所有 MCP 配置文件
-- [x] When 发现 `.cursor/mcp.json` 等配置文件时，the 系统 shall 将 `npx npm-global-exec@latest @cloudbase/cloudbase-mcp@latest` 替换为 `cloudbase-mcp`
-- [x] When 修改完成后，the 系统 shall 验证配置文件的正确性
-- [x] When 用户使用 `tcb pull` 下载的模板时，the MCP 功能 shall 无需额外安装即可正常工作
-
-### 需求 2 - 保持与 tcb ai 命令的一致性
-- [x] When 使用 `tcb pull` 下载模板时，the MCP 配置修改逻辑 shall 与 `tcb ai` 命令完全一致
-- [x] When 支持相同的 IDE 配置文件格式时，the 系统 shall 使用相同的修改规则
-- [x] When 处理 JSON 和 TOML 格式时，the 系统 shall 使用相同的转换逻辑
-- [x] When 出现错误时，the 系统 shall 提供相同的错误处理和日志记录
-
-### 需求 3 - 支持所有内置模板和 Git 仓库
-- [x] When 下载内置模板（miniprogram、react、vue、uniapp、rules）时，the 系统 shall 自动修改 MCP 配置
-- [x] When 从 Git 仓库下载模板时，the 系统 shall 自动修改 MCP 配置
-- [x] When 从 Git 子目录下载内容时，the 系统 shall 自动修改 MCP 配置
-- [x] When 支持多种 IDE 配置时，the 系统 shall 处理所有相关的配置文件
-
-### 需求 4 - 向后兼容性
-- [x] When 现有 `tcb pull` 命令功能使用时，the 系统 shall 保持原有行为不变
-- [x] When 新增 MCP 配置修改功能时，the 系统 shall 不影响模板下载的核心流程
-- [x] When 出现 MCP 配置修改失败时，the 系统 shall 不影响模板下载的成功完成
-- [x] When 用户可以选择跳过 MCP 配置修改时，the 系统 shall 提供相应的选项
-