bug-analysis

# Bug 分析（bug-analysis） 对**已确认**的 Bug 做根因定位、影响分析、回归建议。 - **输入**：Bug 报告（现象 + 复现步骤 + 证据）、代码仓库、（可选）需求模型 / 测试用例；批量执行场景下 A 类条目可来自失败分流表（`../core/triage.md` 产出，条目附带的 G/S 信号摘要与 evidence 字段即复现起点） - **输出（落盘）**：Bug 条目（结构见下），**追加进测试报告**（`../core/report-template.md` §3 的根因分析 / 影响范围 / Severity 依据 / 修复建议 / 回归建议五个扩展字段即本 skill 的填写范围） - **边界**：输入是**已确认**的 Bug（用户或执行结果已定性"这是缺陷"）；审查发现的**疑似**缺陷（待验证）归 `test-case-writing` 的 Cx 记录；回归**范围选择**归 `regression-testing` ## When to Use - Bug 已经定性确认，需要定位根因（读到 `文件:行` 的分叉点） - 需要评估 Bug 的影响面（同根因其他路径 / 脏数据 / 受影响用户） - 修复后需要回归用例建议（修复验证 + 关联回归） ## When NOT to Use - 还没定性（"这是 Bug 还是特性？"）→ 先经用户裁决（Bug 定性检查点，见 `qa`）；证据收集阶段 → `automated-e2e-testing` 工作流二 / `api-testing` - 代码审查发现的疑似缺陷（未复现、未定性）→ `test-case-writing` 的 Cx 缺陷记录（待实测确认） - 需要回归清单（哪些用例要跑）→ `regression-testing`（本 skill 产出回归用例**建议**） - 端到端流水线 → `qa` 编排（本 skill 是其阶段 6） ## Bug 条目结构（追加进测试报告） 条目字段与填写模板**以 `../core/report-template.md` §3 为唯一来源**（此时加载），本 skill 只补充填写语义： - **本 skill 的填写范围**：根因分析 / 影响范围 / Severity 依据 / 修复建议 / 回归建议五个扩展字段（报告 §3 中除「复验轮次」外的 8 个基础字段——严重程度 / 状态（初始"新建"，后续随回归结果更新，见 `../core/report-template.md` 使用约定 6） / 发现方式 / 复现步骤 / 预期行为 / 实际行为 / 证据 / 环境——由发现方已填，不重写） - **根因分析**必须标注 status：**Inference**（读代码推断，未运行验证）或 **Verified**（已通过复现/最小实验验证，E3）——不伪装推断为事实（状态语义见 `../core/evidence.md` 第 3 节） - **影响范围 / Severity 依据**逐条给来源；证据链标注 evidence 等级（E0–E4 + `文件:行`） ## 工作流 ### 1. 复现（先拿到稳定证据） - 按 Bug 报告步骤复现；复现不了 → 不硬分析，区分"环境差异 / 数据依赖 / 概率性"，向用户要环境与数据线索 - 复现过程采集证据：请求/响应原文、日志、截图（E3 运行证据） - **概率性 Bug 战术**：低频复现不硬等——① **基线量化...