disciplined-validation

用途

disciplined-validation 是 disciplined development（纪律化开发）流程的第 5 阶段，定位为“验证”。其目标是证明系统满足 Phase 1 研究文档中的原始需求，通过系统测试与结构化用户验收测试（UAT）完成端到端验证，并获得干系人的正式签核，作为进入生产部署前的关口。

前置条件

执行本阶段需要：

• Phase 4（disciplined-verification）验证已通过；
• Phase 1 的研究文档（disciplined-research）；
• Phase 2 的设计文档（disciplined-design）；
• 所有验证阶段缺陷已解决。

核心原则

• Build the Right Thing：验证系统满足原始需求；
• End-to-End Proof：完整的用户工作流按预期工作；
• Stakeholder Sign-off：业务负责人正式批准上线；
• Defects Loop Back：失败项回退到研究或设计阶段；
• Leverage Specialists：使用专家技能执行聚焦的验证任务。

两部分流程

Part A：系统测试

1. 阅读研究文档中的约束与非功能性需求（NFR）；
2. 从用户工作流构建端到端测试场景；
3. 使用 rust-performance 验证性能 NFR（对照研究目标运行基准，记录构建配置 release-lto，比较延迟、吞吐、内存与预算，证据为 Criterion 报告、hyperfine 结果）；
4. 使用 security-audit 验证安全 NFR（对暴露端点做 OWASP 检查、认证流程渗透测试、输入校验审计，证据为审计报告与工具输出）；
5. 若涉及 UI 变更，使用 visual-testing（定义视觉面、建立基线、运行视觉回归测试，证据为截图差异与基线更新）；
6. 验证可访问性要求（WCAG 2.1 AA，axe、pa11y；键盘导航；屏幕阅读器测试；证据为可访问性审计报告）；
7. 在类生产环境中执行端到端系统测试；
8. 用 NFR 证据更新 requirements-traceability 矩阵；
9. 若发现缺陷，分类为设计缺陷或实现问题，回退到 Phase 2（设计）或 Phase 4（验证），修复后重新进入验证。

Part B：验收测试（UAT）

1. 使用 acceptance-testing 构建 UAT 计划（从研究需求推导验收标准、编写场景（Gherkin 或清单）、定义测试数据与环境、创建签核清单）；
2. 执行验收场景（遵循 acceptance-testing 方法论，记录证据如截图、日志、录屏，失败用缺陷报告模板记录）；
3. 使用 AskUserQuestionTool 进行结构化干系人访谈（问题验证、成功标准核验、风险评估、签核条件）；
4. 用验收证据更新 requirements-traceability（将每条需求链接到验收场景、附上证据工件、标记验证状态）；
5. 若需求未满足，若需求本身有误回退 Phase 1，若方案不匹配回退 Phase 2；
6. 按 acceptance-testing 清单收集干系人签核；
7. 运行 quality-gate 产出最终 go/no-go 报告（汇总所有专家技能输出、生成 Quality Gate Report、记录后续事项或条件）；
8. 产出包含全部证据的最终验证报告。

缺陷回退协议

发现缺陷时进行分类与路由：

• 需求错误 → Phase 1（研究）；
• 需求变更 → Phase 1（研究）；
• 设计不匹配 → Phase 2（设计）；
• NFR 未达成 → Phase 2（设计）；
• 集成测试通过但 e2e 失败（验证缺口）→ Phase 4（验证）。 随后在缺陷登记册中完整留痕，等待左侧阶段修复，再从系统测试层面重新进入验证，重跑受影响的端到端场景，必要时重新验证 NFR。

专家技能编排

本技能通过编排以下专家技能完成验证：

• acceptance-testing：从需求构建 UAT 场景，输出 UAT 计划 + 场景 + 签核；
• visual-testing：若 UI 变更在范围内，输出视觉回归计划 + 基线；
• requirements-traceability：将需求追溯到验收证据，输出带证据的更新矩阵；
• security-audit：系统级安全验证，输出安全发现 + 补救；
• rust-performance：验证 NFR 性能目标，输出基准结果对照目标；
• quality-gate：最终 go/no-go 决策，输出 Quality Gate Report。

系统测试类别

• 端到端场景：将研究中的用户工作流映射为测试场景（例如用户注册、数据导出），含步骤、预期结果与研究引用；
• 非功能性需求：验证研究文档中的 NFR，覆盖性能（延迟 p95、吞吐、内存峰值，可用 k6、heaptrack）、安全（OWASP，sqlmap、ZAP、手工）、可访问性（WCAG 2.1 AA，axe、NVDA、手工）、负载测试（正常/峰值/压力负载与错误率）。

验收访谈框架

使用 AskUserQuestionTool 进行结构化访谈，涵盖：

• 问题验证（是否解决了原始问题、是否有未解决部分、问题是否变化）；
• 成功标准（是否达成、生产环境如何衡量、哪些指标意味着失败）；
• 完整性（是否有遗漏需求、隐式需求、最担心的边界情况）；
• 风险评估（上线风险、阻止上线的因素、回滚计划、合规或监管关注）；
• 签核（是否批准上线、附带条件、还有谁需签核、是否偏好分阶段发布）。

验证报告模板

产出 Validation Report，包含：状态（Validated / Conditional / Failed）、日期、干系人、研究/设计/验证报告链接、执行摘要、专家技能结果（性能、安全、视觉回归、验收测试、需求追溯、质量门）、系统测试结果（端到端场景、NFR 对照表与详情）、验收结果、需求追溯表、验收访谈摘要、未决关注点、缺陷登记册、签核表、门禁清单与附录（访谈记录、测试证据、合规工件）。

门禁标准

进入生产部署前需满足：

• 专家技能要求：rust-performance 基准全部通过研究中的 NFR 目标；security-audit 无严重/高危发现（或已修复并复审）；visual-testing 无意外视觉回归（若 UI 在范围内）；acceptance-testing 所有 UAT 场景执行且通过；requirements-traceability 矩阵完整、无阻塞缺口；quality-gate 最终报告为 Pass 或 Pass with Follow-ups。
• 核心验证要求：所有用户工作流端到端测试；NFR 已验证；所有需求追溯到验收证据；干系人结构化访谈完成；所有严重/高危缺陷经回退修复；收到所有必要干系人正式签核；部署条件记录且可达成；具备生产就绪条件。

约束

• 不得跳过系统测试，所有 NFR 必须验证；
• 使用 AskUserQuestionTool 框架进行结构化访谈；
• 每条验收标准链接到 Phase 1；
• 缺陷通过左侧阶段正确回退；
• 无文档化批准不得部署。

成功指标

• 研究中的所有需求均有验收证据；
• 所有 NFR 达到研究目标；
• 干系人正式批准上线；
• 无未关闭的严重/高危缺陷；
• 部署条件记录且可达成；
• 从需求到验收的完整审计轨迹。

部署就绪

Phase 5 批准后，功能即具备生产部署条件，具有完整 V 模型追溯、正式干系人签核、经正确阶段解决的全部缺陷、已验证的 NFR 以及记录的部署条件。

限制

关于该技能的收费方式、价格、支持的平台范围等具体信息，暂未提供。