---
name: development-validation
description: 通用开发生命周期的「验证与测试」阶段 owner；当实现或产物需要证明行为、合同和运行链路时使用，负责按 L0-L4 选择最小充分证据，不负责可维护性 Review 或发布决策。
---

# Development Validation

## 目标

用充分证据覆盖风险，避免重复验证。

## AI 验收（mode=acceptance）

实现稳定后按原始需求及已确认变更逐项核对“用户结果 → 产物/真实入口 → 当前证据”，标记 passed/failed/unverified，同步已有验收账本及 stable IDs。沿约定角色、触发到最终结果验证，区分真实运行与演练；复用有效证据，测试数量或局部记录不能证明完整覆盖。

跨架构交付按合同的双向对账，从可执行产物和环境复核旧→新变化及目标→新缺口；条件能力须实际进入相应分支。缺入口或只验证常规分支不能 `passed`。验证者可以仍是实现者，但证据必须来自产物与运行结果，不能由设计说明和验收表互相背书。

性能或成本为 Required 项时，按冻结的任务、负载、环境和口径测量用户可感知延迟及实际资源用量，并核对计费依据；同条件比较报告样本量、分位数或区间、冷/热与条件分支、固定/边际成本。估算与线上实测分开，说明外部模型、网络和缓存等变量。不能用启动时间代替端到端等待、一次最佳值代替尾延迟，或空闲单用户成本代替约定使用量。未达门槛或关键分支无证据则保持 `failed`/`not-run` 并返工，不以功能测试通过宣布交付。

有原型/附件等输入基准时，从日志或任务已有输入定位适用版本，按约定用途直接对比实现：功能形态、用户链路、交互/状态及要求保持的外观。设计自身的测试不能替代来源核对；只作参考的维度不强加一致性。记录对应证据与差异；原件不可访问或未核对则相关项不能 passed，不以截图相似证明功能一致。

缺实现/证据返回对应阶段继续循环；标准漏项返回设计，不按已实现部分缩减需求。仅缺授权/外部依赖时完成可做准备并报告阻塞。阶段验收须用户明确约定。

必需项全部有效通过才输出 acceptance-ready，附范围、证据与主观确认项；总流程结合 Review 进入 Delivery。Delivery只消费结论和交接，不重做需求验收；不宣称用户验收通过。

## 风险分级

### L0：文档与元信息

- 普通文档只做链接、格式、结构或 diff 检查。流程/授权等规则语义变更按实际影响验证路由、反例与合同，不因 Markdown 归为低风险；纯规则不运行产品 build/tsc/冒烟。

### L1：局部低风险

- TypeScript/TSX 触达时运行最窄可覆盖改动的 tsc。
- 源码触达时运行一次 targeted ESLint；不先跑会被无关债务阻塞的全 package lint。
- 纯视觉修改证明目标页面能加载、目标样式已生效；审美偏好交给用户确认。未改变交互或数据语义时，不增加全链路冒烟或多张截图。

### L2：局部行为与 bugfix

- 选择一份最贴近风险的定向测试。
- 从真实用户路径、最近链路冒烟、assembled boundary test 中选择优先级最高且成本合理的一条功能证据；定向测试已组装真实边界并证明同一合同可兼任，不机械追加第二份。
- Task Understanding 选择 `reproduce` 时，保留修前失败证据，并用同一入口和观察指标证明修后通过；昂贵端到端复现可以降到命中同一违约点的边界回放或定向失败测试。
- Task Understanding 选择 `skip-reproduction` 时，核对其直接根因证据和预先声明的替代验证；只有替代证据能确定证明原合同恢复时才可通过，并披露没有修前失败基线。
- 验证中发现根因、失败边界或判定条件仍不确定时，原跳过决定失效，返回 Task Understanding 补复现，不在 Validation 内猜测成功。

### L3：跨边界与高影响

- 纯规则用治理检查与场景审查；以下运行链路要求不适用。源码/类型/运行链路须 tsc、targeted lint 与定向测试。
- 增加 assembled boundary test 或真实链路冒烟；两者都跑时分别证明不同风险。公开闭集 variant 同时读取[合同变体传播验证](references/public-contract-variant-validation.md)。
- 第三方框架/Factor/协议须用真实标准接口和上游执行形态命中触达合同；兼容接口、mock 或相邻能力不能替代，偏离另测。
- 只有影响面确实扩大时才增加 package/full regression。
- HTTP/API/transport 变更应在组装后的真实边界断言精确 contract，不只检查状态码或方法被调用。

### L4：发布与不可逆变更

按目标项目的发布、迁移和恢复合同验证真实目标环境、产物身份、回退入口及已授权范围；项目没有可靠执行入口时不能宣称发布验证通过。

## 条件验证

- 触达控件视觉状态、共享反馈或主题颜色时，选择真实渲染证据；L1/L2 的低成本证据原则不能将视觉正确性降为类名或事件断言。项目有交互质量合同时按其补充判定。

- 分页/懒加载、虚拟列表瞬态、IME/选区、结构化输入、附件消费闭环或外部主题复刻：读取[复杂 UI 验证](references/ui-validation.md)。普通 CSS 和审美修改不读取。
- 用户已在真实实例复现，或任务触达启动、重复状态转换、持久化恢复和运行实例时，使用目标项目的当前源码与隔离运行入口验证；不能用全局旧版本或相邻实例证明本次改动。
- 项目有扩展构建、桌面打包、模型对话或发布渠道的专项验证合同，且本次确实触达时，读取对应项目方法。

仅读当前风险所需参考。

## 执行节奏

- 调查和实现阶段只跑能指导下一步的最快定向检查；实现稳定后统一执行一次收尾验证。
- 相关实现未变化时，不重复运行已经通过的同一验证。
- 自主验收按预定标准完成可控验证，不因用户离线升级全套端到端；浏览器仅证明低成本证据无法覆盖的风险。环境缺口披露，不能冒充通过或阻断其余可做工作。
- 目标能力的实现或装配链路继续变化后，旧证据立即失效。
- 按上述风险分级和项目 `AGENTS.md` 执行适用的类型与静态检查，不以测试替代类型检查。
- 项目治理检查只在对应文件、owner、目录或规则发生变化时运行，不机械执行无关全量检查。
- 长日志只保留结论、失败切片和 artifact 路径。

本地验证产生非交付生成物时，收尾前使用既有 clean/check 入口恢复或确认干净；只有发布、打包或用户明确要求刷新产物时才保留。

## 输出

报告风险、证据层级、结果、未验证链路和主观确认项；tsc/lint、mock 和回放不能冒充真实功能验证。用户验收交接归 Delivery。

本阶段不做 findings-first 可维护性审查，不运行 maintainability guard，也不决定改动是否可以发布；失败时返回证据和正确返工目标。