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。
三、适用与不适用 适用：Bug 已定性确认，需要定位根因（读到 文件:行 的分叉点）；需要评估影响面（同根因其他路径 / 脏数据 / 受影响用户）；修复后需要回归用例建议（修复验证 + 关联回归）。 不适用：还没定性（「这是 Bug 还是特性？」）→ 先经用户裁决（Bug 定性检查点，见 qa）；证据收集阶段 → automated-e2e-testing 工作流二 / api-testing；代码审查发现的疑似缺陷（未复现、未定性）→ test-case-writing 的 Cx 缺陷记录；需要回归清单（哪些用例要跑）→ regression-testing；端到端流水线 → qa 编排（本 skill 是其阶段 6）。
四、Bug 条目结构 条目字段与填写模板以 ../core/report-template.md §3 为唯一来源（此时加载），本 skill 只补充填写语义：填写范围为根因分析 / 影响范围 / Severity 依据 / 修复建议 / 回归建议五个扩展字段；报告 §3 中除「复验轮次」外的 8 个基础字段（严重程度 / 状态 / 发现方式 / 复现步骤 / 预期行为 / 实际行为 / 证据 / 环境）由发现方已填，不重写。根因分析必须标注 status：Inference（读代码推断，未运行验证）或 Verified（已通过复现/最小实验验证，E3），不伪装推断为事实；影响范围 / Severity 依据逐条给来源；证据链标注 evidence 等级（E0–E4 + 文件:行）。
五、工作流
- 复现（先拿到稳定证据）：按 Bug 报告步骤复现；复现不了不硬分析，区分「环境差异 / 数据依赖 / 概率性」，向用户要环境与数据线索；复现过程采集请求/响应原文、日志、截图（E3 运行证据）。概率性 Bug 战术：① 基线量化——先跑足样本量建复现频率基线（N≥10 次记录触发次数），修复后同条件复验对比；② 定向提频三类——并发类加大并发度 / 缩短操作间隔复跑，时间类取时区 / 跨日 / 跨秒边界时刻集中触发，环境类换设备 / 数据 / 网络条件对比隔离触发因素。
- 读代码定位根因：从现象入口（页面/接口）向下追入口 → 调用链 → 数据读写，定位到具体行为与预期的分叉点（文件:行）；检查常见根因类别：边界未防护 / null 未兜底 / 状态竞态 / 事务不完整 / 缓存不一致 / 权限漏判 / 并发覆盖 / 配置漂移；根因结论标注 status。
- 影响分析（五面）：功能面（同一根因波及哪些入口/路径，grep 相同模式的其他调用点）；数据面（是否已产生脏数据、影响存量数据范围）；用户面（受影响角色与操作路径）；安全面（是否构成可被利用的窗口——越权可达 / 敏感数据暴露 / 注入面，命中即 Severity 上浮一级，S2→S1、S1→S0，S0 封顶；已构成实际安全后果的直接 S0，不适用上浮口径）；修复波及面（预期修复方式会改动哪些代码 / 配置 / 数据，是回归建议的直接输入）。
- 定级与修复建议：Severity 按后果分级（S 系与用例优先级 P 系分离）——数据丢失/资损/已构成实际安全后果 → S0；核心功能主路径不可用 → S0，核心功能旁路不可用 → S1；部分降级 → S1；体验问题 → S2。仅构成潜在可利用窗口的安全问题不上浮到 S0，按安全面上浮一级。修复建议给方向，不越界替开发写补丁。
- 回归建议（衔接 regression-testing）：修复验证用例（直接复现该 Bug 的用例，没有则建议新增并给 TC 编号建议，按 ../core/case-format.md 格式与 ../core/executability.md 可执行性标准描述）；关联回归（同根因模式的其他路径 + 该功能的锚点用例）；双向互链（本条目编号写进对应回归清单的「关联 Bug」行、清单中修复验证用例的 TC 编号回填本条目「回归建议」）；回归范围选择移交 regression-testing。
- 落盘：单阶段独立使用时，Bug 条目追加进测试报告对应条目；无报告时可新建报告文件（按 ../core/report-template.md）。作为流水线 Bug 分析阶段运行时，不新建、不改写最终测试报告——条目统一写 {项目}/Bug条目_{日期}.md 中转文件，由编排收尾阶段拼装。沉淀判定（收尾必做）：本次根因+修法若过 qa-memory 的写入判据，按其流程沉淀为项目 .qa/ 知识库的 defect 条目（evidence 指向本 Bug 条目）。
六、常见错误 未复现就开始分析（根因建立在想象上，应先复现拿 E3 证据）；根因推测定性为事实（应标注 Inference/Verified）；现象当根因（应追到行为与预期分叉的 文件:行）；影响范围只看单点（应 grep 相同模式，做五面分析）；越界写补丁代码（应给修复方向与验证建议）；把回归范围选择也做了（本 skill 出回归建议，范围选择移交）；疑似缺陷（未定性）直接进本流程（输入必须是已确认 Bug，未定性先走裁决）。