| name | 507-test |
| description | 测试任务：测试本身是主要任务时，用现有框架补行为测试、运行测试、修正过时测试或缩小失败范围；真实生产 bug 转根因修复。Use when user says test, testing, 写测试, 加测试, 补测试, 跑测试, 运行测试, 测试挂了, 测试失败, 修失败测试, 缩小失败范围, coverage. |
测试与失败定位（test）
专门处理测试资产和失败诊断。它观察公开行为、缩小失败范围并补足关键覆盖，不承担真实生产 bug 的实现修复。
原则
- 测试公共接口和调用者关心的行为，不锁定私有方法、内部字段或调用次数。
- 沿用项目已有测试框架、命令、命名和目录，不为单个任务引入新测试栈。
- mock（模拟）只放第三方服务、数据库、时间、随机数、文件系统等系统边界，不 mock 自己的内部协作者。
- 断言具体输出、状态、错误或副作用，不只断言“没有报错”。
- 失败先分类，不直接改断言把红灯变绿。
- 如果测试必须穿透大量内部结构或伪造巨大对象，先怀疑模块形状和公开接口。
工作流程
1. 明确任务
判断是新增测试、运行测试、修失败测试、缩小失败范围，还是覆盖关键边界。确认预期行为、公开入口、已有命令和项目测试约定。
2. 读取证据和惯例
修失败测试时先读完整输出，定位首个真实失败。再读相邻测试、fixture（测试样本）、项目说明和局部规范，理解当前测试接缝。
3. 选择最高公开接缝
优先使用公开 API（接口）、CLI（命令行）、页面或其他真实入口。内部重命名、拆函数或替换实现不应让行为测试失效。
4. 编写最小有效测试
- 测试名描述行为场景；
- 优先主路径、重要边界和关键错误路径；
- 不追求无价值的全组合覆盖；
- partial（局部对象）或故意错类型只允许用于测试构造，不进入生产代码。
5. 递进运行
依次从单个用例、单个文件/包、相关集合扩大到项目要求的完整测试或构建检查。记录命令、结果和首个失败证据。
失败分类与路由
- 生产行为不符合既定规格：保留测试作为反馈环，转
507-fix；
- 规格已改变：先确认新规格，再更新测试和相关说明；
- 测试过时：只调整测试，使其回到公开行为和当前约定；
- fixture、编译、依赖或环境故障：修测试环境，不伪装成产品行为；
- 用户明确要求 test-first（测试先行）或 TDD（测试驱动开发）：转
507-tdd。
交付
报告新增/修改的测试、覆盖行为、运行命令与结果、失败分类、路由和未覆盖边界。测试稳定后可用 507-review 独立审查；用户明确要求提交时再用 507-commit。
完成与接力
- 完成信号：目标行为已有稳定测试或失败已完成可信分类，相关测试层级和构建检查结果已报告。
- 产物：测试资产、运行证据、失败分类与未覆盖边界。
- 候选出口：生产行为错误进入
507-fix；规格变化进入 507-grill / 507-prd；明确 test-first 请求进入 507-tdd；测试工作完成后进入 507-review，用户明确要求提交时再进入 507-commit。
- 回退条件：环境或 fixture 故障先修反馈环，不通过改断言掩盖真实失败。
