用途
disciplined-verification 是规范化开发（disciplined development）流程的第 4 阶段，角色定位是"验证专家"。其目标是通过系统化的单元测试和集成测试，验证实现（Phase 3 产出）是否与设计（Phase 2 产出）和规格（Phase 2.5 产出）一致，并保持完整的可追溯性。
该技能的核心原则包括：
- 追溯至设计：每个测试都映射到一个设计元素或规格发现。
- 正确地构建：验证实现符合规格。
- 缺陷回退：失败会返回左侧的原始阶段处理。
- 不 mock 内部代码：只 mock 外部依赖。
- 借助专业子技能：使用专职技能完成聚焦的验证任务。
前置条件
Phase 4 需要：
- 来自 Phase 3（disciplined-implementation）的可运行代码
- 来自 Phase 2（disciplined-design）的实现计划
- 来自 Phase 2.5（disciplined-specification）的规格发现（如适用）
- 所有实现测试通过
主要能力与专业子技能编排
该技能通过编排以下专业子技能来完成验证：
| 子技能 | 使用时机 | 产出 |
|---|---|---|
| ubs-scanner | 始终最先执行——自动化缺陷检测 | 缺陷发现 + 修复建议 |
| requirements-traceability | 构建 REQ→设计→代码→测试矩阵 | 追溯矩阵 + 缺口 |
| code-review | 验证代码质量与模式 | 评审发现 + 清单 |
| security-audit | 若涉及认证、加密、不可信输入 | 安全发现 |
| rust-performance | 若涉及热点路径、算法 | 基准测试结果 |
| testing | 编写并执行单元/集成测试 | 测试覆盖率报告 |
调用顺序约定：
- 首先（始终）：运行
ubs-scanner做自动化缺陷检测，捕获空指针、安全问题、异步错误；对严重发现阻塞，记录高优先级发现。 - Part A（单元测试）期间：使用
requirements-traceability构建初始矩阵；使用testing技能模式实现测试；使用code-review做代码质量验证。 - Part B（集成测试）期间：如集成触及安全边界则使用
security-audit；如集成有性能预算则使用rust-performance；更新requirements-traceability矩阵并附上证据。
使用方式（两部分流程）
Part A：单元测试
- 阅读实现计划（Phase 2）和规格发现（Phase 2.5）。
- 使用
requirements-traceability技能构建追溯矩阵：从 Phase 1 研究中提取需求，映射 需求→设计→代码→测试，在编写测试前识别缺口。 - 使用
testing技能模式编写单元测试：Arrange-Act-Assert 结构，针对边界情况使用基于属性的测试，覆盖 Phase 2.5 的所有规格发现。 - 执行单元测试并跟踪覆盖率：
cargo test --all-features cargo llvm-cov --html # or tarpaulin - 使用
code-review技能运行代码质量检查：验证 Agent PR Checklist 条目，执行cargo fmt --check && cargo clippy。 - 如果发现缺陷：分类为实现缺陷还是设计缺口；回退到 Phase 3（实现）或 Phase 2.5（规格）修复；修复后重新进入验证。
Part B：集成测试
- 阅读设计文档，了解模块边界和数据流。
- 从架构中识别集成点。
- 如跨越安全边界，使用
security-audit技能：检查认证流程、验证输入校验、审计 unsafe 代码。 - 如存在性能预算，使用
rust-performance技能：运行基准测试（Criterion），与基线对比，记录所用构建配置。 - 构建并执行集成测试：测试模块边界，验证数据流符合设计。
- 用证据更新
requirements-traceability矩阵：将测试关联到需求，附上基准测试结果，引用安全审计发现。 - 如发现缺陷：分类为集成缺陷还是架构问题；回退到 Phase 2（设计）或 Phase 3（实现）修复；修复后重新进入验证。
- 使用 AskUserQuestionTool 就验证关注点访谈用户。
- 门禁：验证前需人工审批。
缺陷回退协议
发现缺陷时，分类并路由回其来源阶段：
- 代码缺陷 → 回退到 Phase 3（实现）
- 缺失边界情况 → 回退到 Phase 2.5（规格）
- 设计缺口 → 回退到 Phase 2.5（规格）
- 架构问题 → 回退到 Phase 2（设计）
记录到缺陷登记表（ID、描述、来源阶段、严重度、指派、状态）。等待修复在左侧阶段完成，然后从发现缺陷的那个测试处恢复验证，而非从头重启，并重新运行相关测试确认修复。
缺陷分类指南：
| 症状 | 来源 | 回退到 |
|---|---|---|
| 测试失败、代码错误 | 实现缺陷 | Phase 3 |
| 测试失败、边界情况未处理 | 规格缺口 | Phase 2.5 |
| 模块无法集成 | 设计缺陷 | Phase 2 |
| API 契约不匹配 | 架构问题 | Phase 2 |
| 缺少函数 | 设计遗漏 | Phase 2 |
| 性能问题 | 非功能性需求未明确 | Phase 2 或 2.5 |
追溯矩阵与报告模板
该技能提供单元测试追溯矩阵、集成测试追溯矩阵（含模块边界、集成测试、数据流验证）以及验证报告模板。验证报告包含：摘要指标表（单元测试覆盖率目标 80%、集成点、边界情况、未关闭缺陷）、各专业子技能结果、单元测试结果（按模块的覆盖率）、集成测试结果、缺陷登记表、验证访谈记录、门禁清单与审批表。
验证访谈问题（使用 AskUserQuestionTool）
覆盖率问题：
- "是否有你认为关键、必须 100% 覆盖的函数或路径？"
- "是否有来自生产事故的已知边界情况需要我们显式测试？"
集成问题：
- "是否有我们集成、且存在已知怪癖的外部系统或 API？"
- "模块之间你最担心哪些失败模式？"
风险问题：
- "什么情况会导致你阻塞验证？什么是绝对不可接受的？"
- "是否有前几个阶段遗留、现在需要处理的缺陷？"
门禁标准
进入 Phase 5（验证）之前必须满足：
- UBS 扫描完成且 0 个严重发现（ubs-scanner）
- 所有公共函数都有单元测试
- 覆盖 Phase 2.5 规格的边界情况
- 关键路径覆盖率 > 80%
- 所有模块边界都已测试
- 数据流已对照设计图验证
- 所有严重和高严重度缺陷已解决
- 中/低严重度缺陷已解决或经批准明确延期
- 追溯矩阵完整
- 已获得人工审批
约束
- 不可跳过：需要完整的单元和集成测试。
- 全部追溯：每个测试都必须映射到设计元素。
- 分类缺陷：不要只修复——要追溯到来源阶段。
- 正确回退：缺陷经过左侧阶段处理，而非就地修补。
- 记录缺口：缺失的覆盖必须明确标注并获得批准。
成功指标
- 所有设计元素都有对应测试
- 所有规格发现（边界情况）都被覆盖
- 没有未测试的公共 API
- 所有模块边界已验证
- 数据流符合设计
- 缺陷经过正确阶段追溯并解决
- 有把握地进入验证阶段
后续步骤
Phase 4 审批通过后：使用 disciplined-validation 技能进入验证（Phase 5）；系统测试将对照架构和非功能性需求进行验证；验收测试将对照原始需求进行验证。