---
trigger: always_on
---

# Testing Governance

## Core Model

Harness 的测试不是“写完代码再补几个脚本”，而是 5 层连续验证：

1. **自然语言测试用例**：先把需求转成 Requirement ID、Oracle、测试数据、证据路径和 TDD 候选
2. **TDD RED / GREEN / REFACTOR**：对适合 TDD 的行为先失败、再通过、再守护重构
3. **开发验证**：编码过程中的 affected tests、单元、组件、契约、lint、typecheck
4. **验收验证**：代码写完后从用户故事或业务闭环视角重新跑 fresh evidence
5. **回归 / release 验证**：跨故事主流程、P0/P1 回归、契约、E2E、视觉或等价系统级验证

## Required Rules

- 不允许等代码完成后才第一次定义测试范围。
- `feature_impl` / `release` 进入实现前，必须先有 `docs/testing/test-plan-template.md` 或等价 `test_plan_summary`。
- `feature_impl` 进入实现前，必须有 `docs/testing/NATURAL_LANGUAGE_TEST_CASES.md`、追溯矩阵、测试数据和验证矩阵支撑。
- `feature_impl` 默认要求 TDD：先写 RED，再写最小实现，再跑 GREEN，再跑 REFACTOR guard。
- `development_validation` 只能证明开发过程反馈，不能替代最终 `acceptance_validation`。
- 最终完成声明必须基于 fresh evidence，不能复用旧日志或编码中途的小测试。
- 高风险用户可见任务如果缺少 `docs/testing/e2e-plan.md` 或等价计划，不得直接进入实现。

## Acceptance Mapping

- 每条 acceptance 都必须能映射到至少一个验证动作或证据路径。
- 每个高风险任务都必须覆盖 positive / negative / boundary / regression / permission / security case。
- 如果实现完成后无法回答“哪条 acceptance 被哪条验证覆盖”，任务不得通过 Stage 2。
- 非 TDD 自然语言用例不得停留在设计文档中；必须进入 `story_full_chain`、`acceptance_validation`、`verify-matrix` 或回归计划。

## Fake-Test Guard

以下情况默认视为假测试或弱验证，Stage 2 应直接拦截：

- 只断言 `200`、`truthy`、元素存在或 snapshot，没有业务语义断言
- 只测 happy path，没有异常、权限、边界或副作用/无副作用验证
- mock 掉被测 service、权限判断、状态机或核心写路径
- 只跑局部 smoke、affected tests、静态检查或 `git diff --check` 就声称任务完成
- 开发验证日志被拿来冒充最终验收验证

## Risk-Based Expectations

- `routine`：至少给出改动说明、最小验证和影响文件
- `standard`：必须有输入契约检查、测试计划和 acceptance 映射
- `deep`：必须有影响面分析、回归范围和剩余风险说明
- `critical`：必须额外验证安全、权限、数据一致性、回滚或人工审批要求

## Failure Triage

测试失败时先分类，再决定修复：

- `TEST_CODE_ISSUE`
- `PRODUCT_BUG`
- `REQUIREMENT_CHANGE`
- `ENV_OR_DATA_ISSUE`
- `FLAKY`

不要直接弱化断言、跳过测试或把产品缺陷改写成“测试通过”。

## Agent Support

- `test-planner`：补测试矩阵、受影响测试、证据路径和是否需要 E2E
- `failure-triage`：失败归因和 owner 路由
- `tdd-guide` / `tdd`：测试先行和 RED/GREEN/REFACTOR 约束
- `e2e-runner`：关键用户流和浏览器验证
