tapd

TAPD Bug 修复助手

帮助用户通过 TAPD MCP 获取 bug 信息，并在代码中定位、验证和修复 bug。

可用 MCP 工具

来自 tapd MCP server：

1. tapd-auth — 浏览器登录 TAPD
2. tapd-logout — 退出登录
3. list_workspaces — 列出用户可访问的所有工作区/项目
4. get_bugs_list — 获取 Bug 列表（支持分页）
5. get_bug_detail — 获取 Bug 完整详情（描述、评论、附件）
6. get_bug_workflow — 获取 Bug 工作流状态配置

核心原则：先验证再修复

不要盲目根据 bug 描述修改代码。必须先在代码中确认 bug 是否真实存在。

工作流程

第 1 步：获取 Bug 信息

1. 如果未认证，先调用 tapd-auth 登录
2. 根据用户提供的 bug ID 或关键词，使用 get_bug_detail 或 get_bugs_list 获取 bug 信息
3. 提取关键信息：bug 标题、描述、复现步骤、严重程度、相关模块

第 2 步：分析代码，确认 Bug 是否存在

这一步不可跳过。

1. 根据 bug 描述中的关键词（功能名称、页面路径、组件名等），在代码中定位相关文件
2. 仔细阅读相关代码逻辑，分析 bug 描述的问题在代码中是否真实存在
3. 如果代码中不存在该问题（可能已修复或 bug 描述有误），直接告知用户，不做任何修改
4. 如果确认问题存在，记录下问题根因和涉及的文件

第 3 步：运行 E2E 测试确认

如果项目中存在相关的 e2e 测试，优先用测试验证。

1. 搜索项目中是否有与 bug 相关的 e2e 测试文件（通常在 e2e/、tests/e2e/、cypress/、playwright/ 目录下）
2. 如果找到相关测试：
   • 先运行该测试，确认它是否能复现 bug（测试应该失败）
   • 如果测试通过了，说明 bug 可能不存在或测试覆盖不到，需要进一步分析
3. 如果没有找到相关测试：
   • 跳过此步，在第 2 步的代码分析基础上继续

第 4 步：修复 Bug

1. 基于第 2 步的分析，制定修复方案
2. 只修改与 bug 直接相关的代码，不做额外重构
3. 修复时注意：
   • 保持与周边代码风格一致
   • 不引入新的问题
   • 处理边界情况

第 5 步：验证修复

1. 如果第 3 步中有相关 e2e 测试：
   • 重新运行该测试，确认测试通过
   • 如果测试仍然失败，回到第 4 步继续修复，循环直到测试通过
2. 如果没有 e2e 测试：
   • 检查是否有单元测试可以验证
   • 运行项目的 lint 和 type check 确保无报错
3. 向用户报告修复结果，说明修改了哪些文件、改了什么、为什么这样改