regression-testing

# 回归测试（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 三层全部来自落盘产物，不依赖会话记忆： 1. **代码级锚点**：用例附录「代码证据清单（TC ↔ 文件:行）」，由 Schema 的 `code_refs` 结构化 2. **功能层**：需求模型 + Schema 的 `module` / `risk_ref` 3. **per-run 增量**：改动文件映射附录（针对本次 diff 生成） > 没有这个数据结构，影响面分析就只是"让模型读一遍 diff 猜"。**启动前三档资产盘点**（决定走哪条路，防止零资产硬编清单）： > - **全套齐**（markmap + Schema 追溯映射都在）：走工作流完整分析链 > - **只有 markmap 无 Schema**：先由 `test-case-writing` 对存量 markmap 抽取补建（不需要人工重写），再进工作流 > - **零用例资产**：不凭 diff 编造清单——向用户给降级选项：P0 冒烟建议（逐条标「无追溯依据，覆盖不保真」），或先由 `test-case-writing` 补建最小用例集再回来跑本流程 > > **知识库输入（另查，不改变上述分流）**：项目存在 `.qa/` 知识库时，启动先读其 `INDEX.md`——`flaky-tests.md` 的 active 条目直接作为「历史噪声 vs 真实回归」判定与回归分级的输入（写入与治理由 `qa-memory` 承担）。 ## When to Use - 代码变更（feature/Bug 修复/重构）合入后，需要选择回归范围 - Bug 修复后需要确定"修复验证 + 关联回归"的用例集 - 需要一份逐条给依据、可裁剪的分级回归清单 ## When NOT to Use - 用例文件的增量修改本身（标记/新增/废弃用例）→ `test-case-writing` 增量更新流程 - 长期回归策略（锚点用例、回归节奏）→ `test-strategy` 的 regression_plan - 单条失败的分辨与定性 → 执行类 skill 单条流程（`automated-e2e-testing` 工作流二 / `api-testing` §4）；一轮失败 ≥3 条先走 `../core/triage.md` 分流；Bug 经用户定性裁决后才进 `bug-analysis`（其输入必须是已确认 Bug） - 端到端流水线 → `qa` 编排 ## 分析链 ```text Changed Files（git dif...