test

test - 验证阶段

不变量

• 根据任务文档中的验收标准进行验证。
• 使用项目中现有的最佳验证路径。
• 核心工作流不得要求使用某一种特定的浏览器自动化工具。
• 始终在 docs/testing/ 下编写一份最终报告。
• 测试通过且用户批准后，将 TASKS.md 更新为 Approved，并重新读取任务跟踪表，确认任务行已移动。任务跟踪表过时会阻塞下游工作和无头会话。

运行时适配器可以将此阶段呈现为斜杠命令、菜单操作或自然语言技能调用。可移植的阶段名称为 test。

工作流

1. 阅读 AGENTS.md。
2. 确认任务 ID，并阅读 docs/task/{ID}-{task-name}.md。
3. 确认任务已达到质量门槛。
4. 根据 Acceptance Criteria 和 Verification Approach 制定验证计划。
5. 优先使用项目现有命令和兼容 CI 的检查。
6. 运行安全的验证命令。
7. 仅在任务需要时使用浏览器自动化或手动检查。
8. 如果项目中存在 docs/templates/test-report.md，则以此为模板编写 docs/testing/{ID}-{task-name}.md；否则，使用与此文件放在一起的 templates/test-report.md。
9. 仅在测试通过且用户批准后，才将任务移至 Approved；如果需要修复，则将其留在 Testing。
10. 如果已移动任务，重新读取 TASKS.md，确认该任务行位于 Approved 中且不在 Testing 中。如果任务行不在预期的分区中，则说明移动操作遗漏了——交接前立即完成编辑。

验证优先级

先使用范围最小且可靠的检查：

1. 纯逻辑的单元测试。
2. API、数据库、服务或跨模块行为的集成测试。
3. 面向用户工作流的浏览器或端到端检查。
4. 项目质量要求所涵盖的静态检查，例如类型检查、lint 或构建。
5. 仅在无法自动化或自动化成本不划算时进行手动检查。

如果不存在可行的验证路径，则编写一份 BLOCKED 报告，说明缺少什么。

证据规则

• **运行每项标准对应的检查，并与任务文档中的 Baseline 对比。**记录两个值。只有在检查已运行且结果符合预期时，该项标准才算通过。
• 评估验证方法。仅断言源文本、文件结构或模拟对象调用次数的检查，只能证明代码具备某种形式，不能证明其行为正确。将此类结果标记为弱证据；如果可以检查行为或输出，则应运行相应检查。
• 必须进行无回归检查，不可省略：重新运行任务中说明不得改变的行为检查。
• **绝不能仅凭推理判定为 PASS。**如果无法运行某项检查，则将结果标记为 SKIPPED 或 BLOCKED，并说明原因。

线上验证

测试通过可以说明代码正确，但不能说明改动已经上线。如果改动需经由分别部署的组件发布（服务、函数、工作进程、迁移）：

• 验证运行系统中的输出（改动应产生的行、消息或记录），而不是验证是否在线（状态码、“作业成功”或已部署的版本号）。
• 任何需要先部署或由负责人采取操作的检查，都应标记为 Deferred，并注明确切步骤，不得标记为 PASS。

报告规则

• 仅在 docs/testing/ 下编写最终报告。
• 不要在仓库根目录散放临时报告。
• 按实际运行的内容准确记录命令。
• 记录跳过的检查及原因。
• 提供足够的证据，以便实现阶段无需查阅会话历史即可修复失败。

交接

PASS：

Verification passed for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Next stage after user approval: document {ID}

FAIL 或 BLOCKED：

Verification failed or blocked for task {ID}
Report: docs/testing/{ID}-{task-name}.md
Return to implementation with the report context.