BackToCimaCoppi 测试执行路由
本 skill 只回答：冻结用例如何被准备、执行、路由和收口。不要在本层改用例口径；不要写项目凭据或平台专属细节。
0. 同一 goal 内的两种模式
| 模式 | 发生时点 | 可以做 | 禁止做 |
|---|---|---|---|
bootstrap M0 启动检查 |
goal 首个里程碑 | 实现/修复测试资产、runner、夹具、数据/环境适配与证据工具；每个命中面运行一个最小健康探针 | 改冻结用例语义、扩大用户授权、给逐 AC 提前签发 Ready |
verification 正式验证 |
goal 各施工切片内及候选交付前 | 跑冻结矩阵、封存 raw、派生证据状态；发现基础设施缺陷可就地修复并按影响面重跑 | 手填 VERIFIED、削弱断言、把产品现状反写测试 |
两种模式执行前都必须满足：
- 已读取冻结用例规格。
- 已确认
execution_ref或预定锚点。 - 已生成执行面矩阵：单元、接口、DB 预置、DB 终态、Web/admin UI、小程序 UI、视觉、手工；本任务命中面各一行，N/A 有可核理由。
- 已识别项目执行 skill；如果项目没有执行 skill，先报告缺口。
涉及真实动作时必须有上游用户授权锚点，逐项锁定目标环境、精确动作、目标对象、费用上限（含重试储备）与副作用范围。没有独立 readiness 门票；bootstrap 的失败先在 goal 内自愈。只有 goal-charter §4 白名单（真值矛盾 / 死亡线 / 未预授权动作，细则以彼处为真值）或计划内真实人工里程碑才交给用户；安全路径穷尽或达到限轮只交付 EXECUTION_BLOCKED，不前拉上游。
禁止行为：
- 边执行边修改断言。
- 用“环境不方便”跳过自动化。
- 把手工验证计作自动化覆盖。
- 把 AI 可控浏览器/开发者工具、DOM/data 断言、截图或 VLM 判读降级成手工。
- 失败后只写“测试失败”，不分类。
- 状态账本自证、派生聚合物冒充 raw、从账本反向改 raw、事后补绑候选版本或环境。
1. 执行流程
1.1 bootstrap M0 启动检查
- 读取冻结用例、执行面矩阵、上游授权与项目执行 skill；逐面加载对应参考。
- 先查项目正式测试基座、稳定 runner/夹具/环境适配与其登记索引，逐项记录
稳定路径 / 来源 commit / 当前分支是否可达 / 兼容性探针；可复用且可达的资产先复用，禁止无声重造。资产只存在于兄弟分支时标记PROPAGATION_REQUIRED，不得假称已经继承，也不得擅自合并分支。 - 每个命中面填写：环境身份/保真度、凭据位置、数据建立/清理/恢复、部署通路、预算、最小健康探针与人工边界；N/A 面填写证据化理由。
- 实现或修复
execution_ref、测试资产、runner、夹具、环境适配与证据工具；错误命令、路径和依赖属于本模式自愈项。 - 每个命中面只运行一个能区分“执行基础设施坏了”与“可以开始工作”的健康探针。报告状态仅为
HEALTHY / REPAIRED / BLOCKED_AUTH / MANUAL_BOUNDARY，不得逐 AC 预演或签发 Ready。 - 输出
_shared/T{n}-goal启动检查.md。这份报告是 goal 的首个运行记录，不是章程准入证明，也不冻结测试资产版本；资产继承清单是复用事实，不是新准入闸。
1.2 verification 正式验证
- 复验冻结用例、M0 启动检查、当前测试资产和候选 commit/tree。
- 按矩阵路由执行测试。发现测试资产/runner/夹具/环境适配/证据工具缺陷时，在同一 goal 内修复；登记影响面，重跑受影响测试和证据。
- 编号覆盖核对：冻结
assertion_index的每个AC-x都在测试资产里有字面落点；项目检查器必须通过。 - 每次运行按 §3.5 单向封存证据，再派生
VERIFIED / BLOCKED / MISSING / WAIVED。 - 运行项目执行证据检查器；失败按 §4 分类并路由，产出执行报告。
2. 路由表
| 用例类型 | 路由 |
|---|---|
| 单元测试 | 项目执行 skill 的 unit 参考 |
| 接口测试 | 项目执行 skill 的 api 参考 |
| DB 预置/校验 | 项目执行 skill 的 db 参考 |
| Web UI 自动化 | 项目执行 skill 的 web-ui 参考 |
| 小程序 UI 自动化 | 项目执行 skill 的 mp-ui 参考 |
| 视觉/VLM 验收 | 项目执行 skill 的 visual 参考 |
| 交付/发布验证 | 项目执行 skill 的 release/evidence 参考 |
| 手工验证 | 项目执行 skill 的 evidence 参考；只生成 runbook 与回传要求 |
项目执行 skill 的名称、参考文件布局与命令细节由项目级补丁声明（见 templates/项目级补丁模板/）。项目一旦提供了自己的测试执行 skill，该项目的全部执行请求统一路由到它，本 skill 不再猜测命令。
3. 执行顺序
默认顺序：
- 静态/单元测试：快速暴露局部缺陷。
- 数据前置：准备幂等测试数据。
- 接口测试：验证契约与业务写链路。
- DB 校验：验证终态、不变量、幂等。
- Web/小程序 UI 自动化：验证用户路径。
- 视觉验收：判读布局、图表、canvas 合成图等视觉结果。
- 交付收口：汇总证据和阻断项。
可以调整顺序，但必须说明原因。例如 UI 用例依赖接口造数完成，接口测试必须先跑。
3.1 可复用执行资产的晋升与交接
goal 中新增或修复的执行资产在候选交接前必须分三类：
| 分类 | 典型内容 | 终态 |
|---|---|---|
| 任务临时 | raw、截图、会话状态、一次性恢复文件、内容寻址证据包 | 留在任务证据或本地运行根；不得冒充下次可复用基座 |
| 领域/场景复用 | 正式测试脚本、fixture、领域 harness、稳定 execution_ref |
晋升到项目正式测试目录并提交；登记入口、适用范围、环境前提与验证命令 |
| 项目通用 | 公共 runner、环境适配器、证据/清理工具 | 晋升到项目公共稳定路径并提交；登记已验证消费者与兼容边界 |
飞行日志或候选交接必须有“执行资产交接”段，逐项记录：稳定路径、资产分类、引入/修复 commit、验证命令与结果、环境/凭据前提、已知消费者、当前分支可达性、兄弟分支传播状态。没有复用价值时明确写“本轮无可晋升资产”。可复用资产不得只留在任务 _shared、本地运行根或未提交工作树；跨分支传播尚未完成可以显式留为 PROPAGATION_REQUIRED，但后续任务在 commit 可达前不得宣称继承成功。
这是一项候选交接义务，不是恢复独立执行准备：M0 不因登记不完整停机，当前 goal 仍在授权内自愈；候选终审只核对“本轮实际产生的复用价值是否已晋升并如实说明传播状态”。
3.5 单向证据协议
证据顺序固定：raw 运行先发生 → 采集时不可变信封 → AC 映射 → 状态账本。
新候选沿用 schema_version=2，但必须声明 evidence_semantics_version: assertion-native-v1。缺该标记的旧包只能显式以 legacy 只读模式审计，不能签发新的 CANDIDATE_READY。
信封与 raw 必须位于同一内容寻址包，并至少封存：候选 commit/tree、环境身份与保真度、run ID、framework_test_id、原生报告路径与 SHA-256、原生结果定位、assertion ID、proof_part_id、观测面、observed、expected/判定器、采集时间。自动化 raw 必须来自框架原生报告或真实扫描器输出；wrapper 只允许规范化和装配，禁止生成断言事实。手工/物理边界必须指向采集时产生的原始键、截图或外部响应，不得用事后聚合哈希代替。任何状态都只能从该包重算；禁止逆向改 raw、派生聚合物冒充 raw、事后补绑候选或环境。
多个 AC 可共享同一个真实测试，但每个 AC 必须满足 L7 的全部证明部件。去除 AC/测试标识、路径、时间戳和哈希后仍相同的观测内容，只有存在 L7 等价组时才能复用；换 assertion ID、test ID 或 observation key 不能把通用观测变成独立证明。套件退出码、文件存在、日志/聚合哈希、源码位置均属代理观测，不能单独签发 VERIFIED。
消费者完整性：每个已执行测试/套件必须被至少一个 AC 消费，或显式声明 supporting_only_reason；任何失败、错误、跳过、已绑定但未执行的测试都阻断候选，辅助套件失败也不例外。多部件 AC 缺任一部件即为 MISSING。
候选交付前必须生成观测分布报告：代理观测、标准化重复簇、等价组、孤儿套件、未消费失败/跳过、未执行绑定、多部件缺口均列数量和明细，任一非法项非零不得报 CANDIDATE_READY。MISSING 证明缺什么，BLOCKED 证明物理边界，二者不要求伪造运行成功证据，也绝不计入覆盖。
4. 失败分类
失败必须分类：
| 分类 | 含义 | 处置 |
|---|---|---|
PRODUCT_BUG |
产品实现与冻结用例或上游真值不符 | 路由 goal 修产品代码，重跑相关测试 |
HARNESS_BUG |
测试资产、runner、夹具或证据工具错误，但用例口径正确；历史 TEST_BUG 等价映射到本类 |
goal 内修复，按影响面重跑；不得让小错使全部上游失效 |
SPEC_STALE |
冻结用例或上游正式真值的语义确有缺陷 | 默认热修：附修改方案经业务决策负责人按项目治理批准后直接修订用例/正式层，按语义影响面作废并重跑下游，回同一 goal 续跑；热修不可靠且获相应批准才回退用例设计或设计+规格冻结子任务 |
ENV |
服务、网络、依赖或测试数据环境问题 | goal 内修环境或重建数据后重跑；缺外部授权另分 AUTHORITY_REQUIRED |
FLAKE |
时序或异步导致间歇失败 | 修等待/隔离；连续 flake 不得当通过 |
MANUAL_REQUIRED |
AI 无法操作真实设备/原生对象/原生授权等物理边界 | 输出物理边界证明、runbook、客观回传要求与写明责任角色的人工里程碑 |
AUTHORITY_REQUIRED |
所需真实动作未获授权或凭据位置未知 | 停在对应环境所有者/发布授权人补权或告知受控位置；不得猜测或偷偷降级为模拟 |
5. 报告格式
bootstrap 启动检查至少包含：
## 授权与身份
- 上游授权锚点：
- 目标环境 / 动作 / 对象 / 费用上限 / 副作用范围：
## 执行面启动检查
| 测试面 | 命中/N/A | N/A理由 | 环境身份 | 最小健康探针 | 结果 | 修复 | 清理/恢复 | 人工边界 |
> 禁止在此报告列逐 AC Ready 状态；完整 AC 证明只由正式验证的 raw 单向证据链产生。
verification 报告至少包含：
## 执行矩阵
| case_id | 测试面 | execution_ref | 执行状态 | 保真度(真连/模拟/手工) | raw信封/AC映射 |
## 编号覆盖
- 检查器命令与结果 / 人工对账表：
- 有编号无落点的 AC 清单（应为空）：
## 语义证据分布
- evidence_semantics_version：
- 代理观测 / 标准化重复簇 / 未声明等价复用：
- 孤儿套件 / 未消费失败与跳过 / 未执行绑定：
- 多部件缺口：
## 数据策略
- 前置方式：
- 清理方式：
- DB 校验：
## 失败分类
| case_id | 分类 | 证据 | 下一步 |
## 交付判断
- 可交付 / 不可交付：
- 真连绿 / 模拟绿分计（模拟绿逐条列真实链路收口去向）：
- 阻断项：
- 手工例外：
6. 与其他 skill 的边界
- 规范矩阵不足：回到
test-standards。 - 用例质量不足：回到
test-case-design。 - 项目命令和工具细节：进入项目执行 skill。
- 测试暴露产品缺陷：进入项目排障/RCA skill 或主线程修复流程。
- 测试基础设施缺陷：留在同一 goal，修复并按影响面重跑。