regression-testing
Installation
SKILL.md
回归测试（regression-testing）
代码变更 → 自动判断应该回归哪些测试。
- 输入：Code Diff（
git diff <base>...<head>）、Bug 修复说明、需求变更说明、已有用例（markmap +测试用例.schema.yaml）、（可选）需求模型 - 输出（落盘）：
{项目}/回归清单_{日期}.md——必须回归（P0）/ 建议回归（P1）/ 可选回归（P2）三级，逐条给依据。档名沿用 P 系记号，但归档规则是影响直接程度，与用例自身优先级是两套口径：直连改动 → 必须回归，同模块间接受影响 → 建议回归；一条 [P2] 用例因 code_refs 直连改动同样进「必须回归」档（流水线分层消费按本档位执行，见../core/pipeline-integration.md） - 前置依赖：持久的"用例 ↔ 代码 ↔ 功能"追溯映射，v0 三层全部来自落盘产物，不依赖会话记忆：
- 代码级锚点：用例附录「代码证据清单（TC ↔ 文件:行）」，由 Schema 的
code_refs结构化 - 功能层：需求模型 + Schema 的
module/risk_ref - per-run 增量：改动文件映射附录（针对本次 diff 生成）
- 代码级锚点：用例附录「代码证据清单（TC ↔ 文件:行）」，由 Schema 的
没有这个数据结构，影响面分析就只是"让模型读一遍 diff 猜"。启动前三档资产盘点（决定走哪条路，防止零资产硬编清单）：
- 全套齐（markmap + Schema 追溯映射都在）：走工作流完整分析链
- 只有 markmap 无 Schema：先由
test-case-writing对存量 markmap 抽取补建（不需要人工重写），再进工作流- 零用例资产：不凭 diff 编造清单——向用户给降级选项：P0 冒烟建议（逐条标「无追溯依据，覆盖不保真」），或先由
test-case-writing补建最小用例集再回来跑本流程知识库输入（另查，不改变上述分流）：项目存在
.qa/知识库时，启动先读其INDEX.md——flaky-tests.md的 active 条目直接作为「历史噪声 vs 真实回归」判定与回归分级的输入（写入与治理由qa-memory承担）。