优先采用用户明确的提交区间、分支、工作区或功能目标。已有会话足以确定范围时直接使用；否则查覆盖匹配的已验证基线，仍无法确定才询问，不自行扩大为全量。
- P0 冒烟：页面、必要导航和基本主流程可用，是环境与入口检查。
- 变更验收：从本次需求和实际差异提取场景，验证改变的结果、相关失败/取消路径与旧行为兼容。用户要求“验证本次改动”时不能只以 P0 完成。
将必要场景赋予模块内稳定标识（如 save-reopen），注明预期、所需数据和证据。依赖数据或权限暂不可用的场景保留为未覆盖；深度、排除项和原因写入 run，不靠通过数量掩盖缺项。
按本次业务后果逐项判断以下六维是否适用，写入 run：适用项关联场景 ID，不适用项说明原因。一个场景可以覆盖多维，不要求每次新增六个用例；缺数据、缺权限或工具受阻属于适用但未覆盖，不能记为不适用。
| 维度 | 判断要点 |
|---|---|
| 正常 | 目标操作完成后应得到什么结果 |
| 失败 | 无效输入或依赖失败时，何时拦截、哪些动作或写入不得发生 |
| 取消 | 存在取消/返回/关闭路径时，是否遗留写入或未提交状态 |
| 排除对象 | 哪些对象、状态或条件不应受本次变更影响 |
| 向后兼容 | 既有数据、配置、调用方式和旧流程是否需要保持可用 |
| 数据正确性 | 值、数量、结构、参数绑定或持久化结果应如何独立核对 |
预期来自用户要求、适用契约或独立样例，并注明来源；当前实现输出和历史“通过”不能反推预期。业务预期确有缺口时先澄清该缺口，其他已有依据的场景继续执行。
每个相关仓库分别执行适用的 Git 查询，按最终态聚合影响面：
git rev-parse --show-toplevel
git rev-parse HEAD
git status --short
git diff --name-only <base>..<target>前后端分仓时分别记录仓库路径、base 和 target 完整 hash；一个仓库的 HEAD 不代表整套系统版本。用户要求分提交验证时再检查中间版本。
提交范围与实际运行的工作区分开记录：即使任务只指定提交，也要检查相关已暂存、未暂存和未跟踪文件。服务若运行了相关 dirty 内容，结果属于该工作区组合，不能直接证明 target 提交；保留相关差异摘要/证据位置，或在已授权的隔离版本中验证。无关 dirty 不必纳入功能范围，但说明判断依据，不清理用户改动。
tested-commits.md 每条基线至少记录：
- 日期/run: <日期> / <runs 中的记录链接>
- 版本: <仓库名: 完整 hash>；<另一仓库名: 完整 hash>
- 工作区: <相关 dirty 无/差异证据；是否确实运行这些版本>
- scope: <模块、改动范围及明确排除项>
- depth: <P0 冒烟 / 变更验收>
- coverage: <已通过的场景标识及证据链接>
- 未覆盖: <无或具体列表>先比对本次所需 scope、depth、场景、数据前提和版本组合，再决定复用。旧记录只有 hash 时不能推定完整覆盖；P0 基线、局部通过或受相关 dirty 影响的结果不能作为整批验收的增量起点。即使 base..HEAD 为空，尚未覆盖或前提变化的必要场景仍要验证。更新规则见 execute.md。
先读取 modules/ 中触发范围以建立索引，仅展开命中模块的完整内容。一个文件影响多个模块时保留全部相关场景，并沿实际调用链补充影响面。
命中模块列有前置或公共场景引用时，按文件链接与场景 ID 读取本次实际需要的部分，核对使用条件、参数差异及所需状态。前置状态已满足时可复用，不重复执行登录等操作；读取引用不等于执行授权，也不扩大本次验收范围。引用缺失或失效时先核对相关入口及证据，不改为遍历全部历史 run。
| 分类 | 处理 |
|---|---|
| 命中模块 | 核对历史步骤仍适用，再安排 P0 与本次验收场景 |
| 模块知识缺失 | 从服务/API、前端 API 包装、组件和路由/菜单追踪页面入口；找到后现场探索并补模块知识 |
| 已确认没有页面入口 | 选择适用的定向测试、API/事件调用或其他受控验证；构建、启动和日志只能证明对应层面 |
| 文档或无运行影响的改动 | 做内容/引用检查，说明无需页面测试的依据 |
| 仍无法映射或验证受阻 | 列出文件、已查调用链、原因和未覆盖场景，不能直接认定“后端改动无需页面验证” |
完整分类写入 run；接口验证、降级验证与页面验证分别报告，任何影响范围都不静默丢弃。