Jeandoom bug-killer — Bug 全链路分析编排器（薄）
链路总调度：入口模式判断 → 本地项目 bug 走 bug-killer-native（直接分析输出）；否则建 bug 目录 → 按序调度 4 analyzer → 失败时暂停问用户 → 汇总分析报告。用户显式触发"修复" → 追加调度 code-manager + code-dever → 修复报告。
Claude vs 脚本分工
| 角色 | 职责 |
|---|---|
| Claude | 建 bug 目录 → 按序调度 4 analyzer（用 Skill 工具） → 检查物料完成 → 失败时 AskUserQuestion → 汇总分析报告 → 用户触发"修复"时调度 code-manager + code-dever |
| 无 Python 脚本 | 编排是 Claude 调度强项 |
| 无 context-manager | 状态机彻底删除，每个 skill 自管物料 |
编排流程
用户: "bug-killer 查 TB xxx" / "查这个 bug" / "排查 xxx"
│
⓪ 模式判断（见下节）：
本地项目 bug → 调度 bug-killer-native（直接分析输出，零物料）→ 结束
否则 → 继续 ①
│
① 解析输入 + 生成 bug_id
│
② 建目录骨架 bugs/bug-{yyyyMMdd}-{slug}/{clue,logs,code,root-cause,reports}/
│
③ 按序调度（每步用 Skill 工具，检查产物文件存在再进下一步）：
1. maycur-ai-bug-clue-analyzer → clue/clue.md
2. maycur-ai-log-analyzer → logs/{sls-logs.json, langfuse-trace.json}
3. maycur-ai-code-analyzer → code/code-analysis.md
4. maycur-ai-root-cause-analyzer → root-cause/root-cause.md
│
④ 任一步失败 → 暂停 + AskUserQuestion（重试/跳过/中止）
│
⑤ 全部完成 → 汇总 reports/01-问题分析报告.md
│
─── 分析阶段结束，等待用户决策 ───
│
⑥ 用户显式触发"修复"→ 调度修复链路：
1. maycur-ai-code-manager 阶段 ①②（opser 确认 + bugfix 分支）
2. maycur-ai-code-dever（Edit + 02-修复报告）
3. maycur-ai-code-manager 阶段 ③④⑤（commit + push + MR，全部确认）
│
⑦ MR url 回写 reports/02-修复报告.md
修复阶段默认不执行——分析报告交付后等用户显式说"修复"/"fix"/"改代码"才进。
模式判断（⓪）
判断"用户要分析和解决的是当前目录所在项目的 bug"：
| 条件 | 判定 |
|---|---|
| 用户明说"本地 / 当前项目 / 这个项目" + cwd 是 git 仓库 | native |
| 报错堆栈 / 模块名 / 接口路径与 cwd 项目匹配（包名、服务名、git remote 对应） | native |
| bug 属于其他服务 / 平台（TB 单、跨服务 traceId、cwd 项目无关） | 物料管线 |
拿不准 → AskUserQuestion 二选一（本地项目分析 / 全链路物料分析）。
bug_id 命名 + 目录骨架
bugs/bug-{yyyyMMdd}-{slug}/
├── clue/ ← bug-clue-analyzer 产出
├── logs/ ← log-analyzer 产出
├── code/ ← code-analyzer 产出
├── root-cause/ ← root-cause-analyzer 产出
├── reports/ ← bug-killer 汇总产出
└── repos/ ← code-analyzer 拉代码时建（按需）
bug_id slug 来源：TB 标题前几个字 / 用户描述关键词
示例：bug-20260723-login-npe
物料交接（无状态机）
不维护 context.json。每个 skill 读上游物料 / 写自己物料（去中心化）。bug-killer 只用"物料文件存在"判断完成（不解析内容）：
| 阶段 | 完成判断 |
|---|---|
| bug-clue 完成 | clue/clue.md 存在 |
| log-analyzer 完成 | logs/sls-logs.json + logs/langfuse-trace.json 存在 |
| code-analyzer 完成 | code/code-analysis.md 存在 |
| root-cause-analyzer 完成 | root-cause/root-cause.md 存在 |
| code-manager 准备完成 | repos/{project}/ 存在 + 当前分支 bugfix-* |
| code-dever 完成 | reports/02-修复报告.md 存在 |
| code-manager commit 完成 | reports/02-修复报告.md 含 MR url |
错误处理：暂停不崩溃
任一 skill 失败 → 暂停 + AskUserQuestion 提供选项：
| 选项 | 行为 |
|---|---|
| 重试当前 skill | 重新调度当前 skill |
| 跳过 | 标注缺失物料，下游 skill 用独立模式补齐（用户手动输入） |
| 中止 | 停止整条链路，保留已生成物料 |
跳过时下游 skill 在独立模式下运行，仍可产出（但可能证据不足）。
修复阶段特殊处理：code-manager 的 commit/push/MR/merge 任一步用户拒绝 → 暂停（不静默跳过）。详见 code-manager SKILL.md 用户确认清单。
最终汇总报告 reports/01-问题分析报告.md
# Bug 分析报告：bug-{id}
## 线索信息
- **bug_id**: bug-20260723-login-npe
- **来源**: TB / 对话 / 用户描述
- **创建时间**: 2026-07-23T10:00:00
- **现象**: 用户登录报错 NullPointerException
- **entCode**: EC001
- **单据号**: BX20260723001
- **环境**: prod
- **异常关键字**: NullPointerException, Cannot invoke method
- **traceId**: abc123def456abcd
- **时间窗**: 2026-07-21T10:00:00 ~ 2026-07-23T10:00:00
## 摘要
（从 root-cause.md 的"结论摘要"引用：根因 + 置信度 + 影响范围）
## 时间线
- bug-clue: ✅ 完成（→ clue/clue.md）
- log-analyzer: ✅ 完成（→ logs/*.json，N 条日志，M 个 traceId）
- code-analyzer: ✅ 完成（→ code/code-analysis.md，K 个定位点）
- root-cause-analyzer: ✅ 完成（→ root-cause.md，置信度：高）
## 详细结论
### 根因链
（引用 root-cause.md 的根因链）
### 证据矩阵
（引用 root-cause.md 的证据矩阵）
### 解决方案
（引用 root-cause.md 的分级解决方案）
## 原始物料
- [clue/clue.md](../clue/clue.md)
- [logs/langfuse-trace.json](../logs/langfuse-trace.json)
- [logs/sls-logs.json](../logs/sls-logs.json)
- [code/code-analysis.md](../code/code-analysis.md)
- [root-cause/root-cause.md](../root-cause/root-cause.md)
字段说明：
- 线索信息（开头）：bug 现场基本信息，读者快速确认"这是不是我要找的 bug"
- 摘要：从 root-cause.md 引用结论，不重新推理
- 时间线：4 个 analyzer 的完成状态 + 物料链接
- 详细结论：引用 root-cause.md（不复制全文，用引用块）
- 原始物料：相对路径链接（可追溯）
用户触点（AskUserQuestion 时机）
| 阶段 | 触点 |
|---|---|
| bug-clue 独立模式 | 收集现象描述 / TB ID |
| log-analyzer | SLS project/logstore 选择（基于环境） |
| code-analyzer | 项目名/环境（若 clue 没给全） |
| 任一 analyzer 失败 | 重试/跳过/中止决策 |
| 分析完成 | 询问是否进入修复阶段（默认不进，等用户显式触发） |
| code-manager 阶段 ② | bugfix 分支名确认 |
| code-dever | 方案选择 + 每个 Edit 确认（详见 code-dever SKILL.md） |
| code-manager 阶段 ③④⑤⑥ | commit/push/MR/merge 全部确认 |
| 任一修复 skill 失败 | 重试/跳过/中止决策 |
bug-killer 编排器不替 skill 做决策——只在 skill 需要用户输入时透传 AskUserQuestion。
边界
- 不做业务分析（4 analyzer 职责）
- 不做代码 Edit（code-dever 职责）
- 不做 git 操作（code-manager 职责）
- 不维护状态机（去中心化）
- 不自动进入修复阶段（用户显式触发）
- 不替 skill 做决策（只透传 AskUserQuestion）
- 不写 Python 脚本（纯 Claude 编排）
依赖
分析阶段（P0）：
- bug-killer-native：模式 ⓪（本地项目 bug，直接分析输出，零物料）
- maycur-ai-bug-clue-analyzer：阶段 1（信息收集 + 线索提取）
- maycur-ai-log-analyzer：阶段 2（日志/trace 查询）
- maycur-ai-code-analyzer：阶段 3（代码定位 + 数据流）
- maycur-ai-root-cause-analyzer：阶段 4（综合根因 + 方案）
修复阶段（P1，用户显式触发）：
- maycur-ai-code-manager：git 流程（opser + 切 bugfix + commit/push/MR）
- maycur-ai-code-dever：半自动 Edit（基于 root-cause.md 方案）