mcp-probe-kit 3.1.0 → 3.3.0

package/build/tools/fix_bug.js

@@ -10,167 +10,167 @@ import { parseArgs, getString } from "../utils/parseArgs.js";
 import { okStructured } from "../lib/response.js";
 import { renderGuidanceHeader } from "../lib/guidance.js";
 import { handleToolError } from "../utils/error-handler.js";
-const PROMPT_TEMPLATE = `# TBP 8 步 Bug 真因分析与修复指南
-
-## 🐛 Bug 信息
-
-**错误信息**:
-\`\`\`
-{error_message}
-\`\`\`
-
-{stack_trace_section}
-
-{reproduce_section}
-
-{behavior_section}
-
-{code_context_section}
-
----
-
-## TBP-1 现象
-
-先把用户可见的问题定义准确，避免“坏了/卡了/有问题”这类泛化描述。
-
-要求：
-1. 用 1-2 句定义现象
-2. 明确是“慢”“停滞”“失败”“回归”还是“未生效”
-3. 如果提供了期望/实际行为，必须纳入现象定义
-
-## TBP-2 时间线
-
-基于现有信息复盘事件顺序，至少回答：
-1. 什么时候开始
-2. 中间发生了什么
-3. 最后停在什么状态
-
-优先记录：
-- 用户输入 / 复现步骤
-- first progress / first error
-- tool call / stack / stop / timeout
-- 关键文件或模块
-
-## TBP-3 不是这个
-
-列出当前应优先排除的错误方向，并说明需要什么证据排除。
-
-常见排除项：
-- 不是单纯网络慢
-- 不是前端展示截断
-- 不是消息没转发
-- 不是纯粹的超时表象
-- 不是用户输入丢失
-
-## TBP-4 共同模式
-
-对比成功/失败样本，找出从哪一步开始分叉。
-
-重点检查：
-- 传输层
-- 会话状态机
-- 完成态判定
-- 工具执行
-- 文件写入
-- 重试策略
-
-## TBP-5 边界
-
-明确指出问题失控落在哪一层：
-- 上游模型 / SDK
-- 网关状态机
-- session 复用
-- tool 执行层
-- 文件系统
-- 环境配置
-- UI 展示层
-
-## TBP-6 真因
-
-真因必须写成因果句：
-\`A + B 在条件 D 下导致了 C\`
-
-不允许只写：
-- 超时了
-- SDK 有 bug
-- 返回慢
-
-## TBP-7 证据链
-
-说明：
-1. 哪些证据支持真因
-2. 哪些现象若出现会推翻它，但现场没有出现
-3. 为什么其他解释更弱
-
-## TBP-8 修复
-
-只有在证据链闭合后，才开始设计修复。
-
-每个修复方案都要说明：
-- 改哪一层
-- 为什么这是修真因，不是补症状
-- 风险是什么
-- 怎么验证
-
----
-
-## 📤 输出格式要求
-
-请严格按以下 JSON 格式输出修复指南：
-
-\`\`\`json
-{
-  "bug_summary": "Bug 简述（一句话）",
-  "analysis_mode": "tbp8",
-  "analysis": {
-    "error_type": "错误类型",
-    "direct_cause": "直接原因",
-    "root_cause": "根本原因",
-    "affected_scope": "影响范围"
-  },
-  "tbp": {
-    "phenomenon": "TBP-1 现象",
-    "timeline": [],
-    "ruled_out": [],
-    "common_pattern": "TBP-4 共同模式",
-    "boundary": "TBP-5 边界",
-    "root_cause_statement": "A + B 在条件 D 下导致 C",
-    "evidence": [],
-    "repair": []
-  },
-  "location": {
-    "file": "问题文件路径",
-    "line": 42,
-    "function": "问题函数名",
-    "code_snippet": "问题代码片段"
-  },
-  "fix_plan": {
-    "chosen_solution": "选择的修复方案",
-    "reason": "选择理由",
-    "steps": [
-      { "step": 1, "action": "修复步骤", "file": "文件", "change": "变更内容" }
-    ],
-    "code_before": "修改前代码",
-    "code_after": "修改后代码"
-  },
-  "verification": {
-    "test_cases": ["测试用例1", "测试用例2"],
-    "manual_checks": ["手动验证项1", "手动验证项2"]
-  }
-}
-\`\`\`
-
-## ⚠️ 护栏
-
-- 不要一看到新现象就补一个新分支，先判断是不是同一类根因在换表现
-- 不要把“超时”直接当真因，要先分清是没进展、慢进展，还是结果已出现但判定过严
-- 不要只看单一样本就下结论，有对比样本时必须做对比
-- 如果证据不足，要明确说明还缺什么证据
-
----
-
-*指南版本: 2.0.0*
-*工具: MCP Probe Kit - fix_bug*
+const PROMPT_TEMPLATE = `# TBP 8 步 Bug 真因分析与修复指南
+
+## 🐛 Bug 信息
+
+**错误信息**:
+\`\`\`
+{error_message}
+\`\`\`
+
+{stack_trace_section}
+
+{reproduce_section}
+
+{behavior_section}
+
+{code_context_section}
+
+---
+
+## TBP-1 现象
+
+先把用户可见的问题定义准确，避免“坏了/卡了/有问题”这类泛化描述。
+
+要求：
+1. 用 1-2 句定义现象
+2. 明确是“慢”“停滞”“失败”“回归”还是“未生效”
+3. 如果提供了期望/实际行为，必须纳入现象定义
+
+## TBP-2 时间线
+
+基于现有信息复盘事件顺序，至少回答：
+1. 什么时候开始
+2. 中间发生了什么
+3. 最后停在什么状态
+
+优先记录：
+- 用户输入 / 复现步骤
+- first progress / first error
+- tool call / stack / stop / timeout
+- 关键文件或模块
+
+## TBP-3 不是这个
+
+列出当前应优先排除的错误方向，并说明需要什么证据排除。
+
+常见排除项：
+- 不是单纯网络慢
+- 不是前端展示截断
+- 不是消息没转发
+- 不是纯粹的超时表象
+- 不是用户输入丢失
+
+## TBP-4 共同模式
+
+对比成功/失败样本，找出从哪一步开始分叉。
+
+重点检查：
+- 传输层
+- 会话状态机
+- 完成态判定
+- 工具执行
+- 文件写入
+- 重试策略
+
+## TBP-5 边界
+
+明确指出问题失控落在哪一层：
+- 上游模型 / SDK
+- 网关状态机
+- session 复用
+- tool 执行层
+- 文件系统
+- 环境配置
+- UI 展示层
+
+## TBP-6 真因
+
+真因必须写成因果句：
+\`A + B 在条件 D 下导致了 C\`
+
+不允许只写：
+- 超时了
+- SDK 有 bug
+- 返回慢
+
+## TBP-7 证据链
+
+说明：
+1. 哪些证据支持真因
+2. 哪些现象若出现会推翻它，但现场没有出现
+3. 为什么其他解释更弱
+
+## TBP-8 修复
+
+只有在证据链闭合后，才开始设计修复。
+
+每个修复方案都要说明：
+- 改哪一层
+- 为什么这是修真因，不是补症状
+- 风险是什么
+- 怎么验证
+
+---
+
+## 📤 输出格式要求
+
+请严格按以下 JSON 格式输出修复指南：
+
+\`\`\`json
+{
+  "bug_summary": "Bug 简述（一句话）",
+  "analysis_mode": "tbp8",
+  "analysis": {
+    "error_type": "错误类型",
+    "direct_cause": "直接原因",
+    "root_cause": "根本原因",
+    "affected_scope": "影响范围"
+  },
+  "tbp": {
+    "phenomenon": "TBP-1 现象",
+    "timeline": [],
+    "ruled_out": [],
+    "common_pattern": "TBP-4 共同模式",
+    "boundary": "TBP-5 边界",
+    "root_cause_statement": "A + B 在条件 D 下导致 C",
+    "evidence": [],
+    "repair": []
+  },
+  "location": {
+    "file": "问题文件路径",
+    "line": 42,
+    "function": "问题函数名",
+    "code_snippet": "问题代码片段"
+  },
+  "fix_plan": {
+    "chosen_solution": "选择的修复方案",
+    "reason": "选择理由",
+    "steps": [
+      { "step": 1, "action": "修复步骤", "file": "文件", "change": "变更内容" }
+    ],
+    "code_before": "修改前代码",
+    "code_after": "修改后代码"
+  },
+  "verification": {
+    "test_cases": ["测试用例1", "测试用例2"],
+    "manual_checks": ["手动验证项1", "手动验证项2"]
+  }
+}
+\`\`\`
+
+## ⚠️ 护栏
+
+- 不要一看到新现象就补一个新分支，先判断是不是同一类根因在换表现
+- 不要把“超时”直接当真因，要先分清是没进展、慢进展，还是结果已出现但判定过严
+- 不要只看单一样本就下结论，有对比样本时必须做对比
+- 如果证据不足，要明确说明还缺什么证据
+
+---
+
+*指南版本: 2.0.0*
+*工具: MCP Probe Kit - fix_bug*
 `;
 function inferBugType(text) {
     if (/timeout|latency|slow|卡|慢|超时/i.test(text))

package/build/tools/gencommit.js

@@ -50,66 +50,66 @@ function buildTextGuide(changes) {
             ],
         outputs: ["一份规范说明文档，供 AI 直接据此写出最终 commit message"],
     });
-    return `${header}请按以下规则生成 Git commit message：
-
-**定位**
-- 本工具返回的是说明文档，不是最终 commit message
-- AI 必须根据本说明和变更内容，直接写出最终提交消息
-- 不要重复调用 gencommit
-- 不要说“工具返回为空”
-- 不要忽略本工具约定后自行发挥
-
-**强约束**
-- type 和 emoji 必须使用下方固定映射，不允许自创、不允许替换
-- 如果语义接近多个 type，选择最贴近本次主要变更的一种，不输出多个候选
-- 最终必须只输出一条 commit message 本体
-- 除非用户明确要求，否则不要附加解释、分析过程、前缀说明、代码块外文本
-- 如果缺少足够变更信息，先索取变更信息；不要猜测最终 commit message
-
-**第一步：获取变更信息**
-${changes ? `已提供变更内容：\n${changes}` : `
-1. 执行 \`git status\` 查看修改文件
-2. 执行 \`git diff\` 查看具体变更
-3. 如有暂存文件，执行 \`git diff --staged\`
-`}
-
-**第二步：分析变更**
-- 识别变更类型（新功能、修复、重构等）
-- 选择对应 emoji
-- 提炼一句中文 subject
-- 如有必要，在 body 中说明影响模块、关键改动和原因
-
-**第三步：输出最终 commit message**
-- 直接输出最终结果
-- 不要附加“根据 gencommit 规则生成如下”这类解释
-- 不要输出多条候选，默认只给一条最合适的
-- 不要自创新的 type 或 emoji
-- 不要把示例原样复用到当前提交
-
-**格式**
-\`\`\`
-<type>: <emoji> <subject>
-
-<body>
-
-<footer>
-\`\`\`
-
-**允许的 type**
-${ALLOWED_TYPES.map((item) => `- ${item.type} ${item.emoji}: ${item.when}`).join("\n")}
-
-**硬性规则**
-1. type 后面加冒号和空格，再接 emoji
-2. subject 使用中文，简洁明确，尽量不超过 50 字
-3. body 可选，但有必要时应说明影响范围和关键改动
-4. footer 可选，用于 issue / BREAKING CHANGE
-5. 最终只输出 commit message 本体
-6. 不允许使用固定映射之外的 type / emoji
-7. \`fixed\` 与 \`fix\` 都可用，但语义都表示“修复”；若无兼容性要求，优先用 \`fixed\`
-8. 若本次提交以文档、样式、测试、依赖调整为主，不要误用 \`feat\` 或 \`fixed\`
-
-**参考示例**
-${EXAMPLES.map((item) => `\`\`\`gitcommit\n${item.fullMessage}\n\`\`\``).join("\n\n")}
+    return `${header}请按以下规则生成 Git commit message：
+
+**定位**
+- 本工具返回的是说明文档，不是最终 commit message
+- AI 必须根据本说明和变更内容，直接写出最终提交消息
+- 不要重复调用 gencommit
+- 不要说“工具返回为空”
+- 不要忽略本工具约定后自行发挥
+
+**强约束**
+- type 和 emoji 必须使用下方固定映射，不允许自创、不允许替换
+- 如果语义接近多个 type，选择最贴近本次主要变更的一种，不输出多个候选
+- 最终必须只输出一条 commit message 本体
+- 除非用户明确要求，否则不要附加解释、分析过程、前缀说明、代码块外文本
+- 如果缺少足够变更信息，先索取变更信息；不要猜测最终 commit message
+
+**第一步：获取变更信息**
+${changes ? `已提供变更内容：\n${changes}` : `
+1. 执行 \`git status\` 查看修改文件
+2. 执行 \`git diff\` 查看具体变更
+3. 如有暂存文件，执行 \`git diff --staged\`
+`}
+
+**第二步：分析变更**
+- 识别变更类型（新功能、修复、重构等）
+- 选择对应 emoji
+- 提炼一句中文 subject
+- 如有必要，在 body 中说明影响模块、关键改动和原因
+
+**第三步：输出最终 commit message**
+- 直接输出最终结果
+- 不要附加“根据 gencommit 规则生成如下”这类解释
+- 不要输出多条候选，默认只给一条最合适的
+- 不要自创新的 type 或 emoji
+- 不要把示例原样复用到当前提交
+
+**格式**
+\`\`\`
+<type>: <emoji> <subject>
+
+<body>
+
+<footer>
+\`\`\`
+
+**允许的 type**
+${ALLOWED_TYPES.map((item) => `- ${item.type} ${item.emoji}: ${item.when}`).join("\n")}
+
+**硬性规则**
+1. type 后面加冒号和空格，再接 emoji
+2. subject 使用中文，简洁明确，尽量不超过 50 字
+3. body 可选，但有必要时应说明影响范围和关键改动
+4. footer 可选，用于 issue / BREAKING CHANGE
+5. 最终只输出 commit message 本体
+6. 不允许使用固定映射之外的 type / emoji
+7. \`fixed\` 与 \`fix\` 都可用，但语义都表示“修复”；若无兼容性要求，优先用 \`fixed\`
+8. 若本次提交以文档、样式、测试、依赖调整为主，不要误用 \`feat\` 或 \`fixed\`
+
+**参考示例**
+${EXAMPLES.map((item) => `\`\`\`gitcommit\n${item.fullMessage}\n\`\`\``).join("\n\n")}
 `;
 }
 export async function gencommit(args) {

package/build/tools/index.d.ts

@@ -6,6 +6,7 @@ export { gentest } from "./gentest.js";
 export { refactor } from "./refactor.js";
 export { initProjectContext } from "./init_project_context.js";
 export { addFeature } from "./add_feature.js";
+export { checkSpec } from "./check_spec.js";
 export { fixBug } from "./fix_bug.js";
 export { estimate } from "./estimate.js";
 export { startFeature } from "./start_feature.js";

package/build/tools/index.js

@@ -6,6 +6,7 @@ export { gentest } from "./gentest.js";
 export { refactor } from "./refactor.js";
 export { initProjectContext } from "./init_project_context.js";
 export { addFeature } from "./add_feature.js";
+export { checkSpec } from "./check_spec.js";
 export { fixBug } from "./fix_bug.js";
 export { estimate } from "./estimate.js";
 // 智能编排工具