Acceptance Criteria

Triggers

• product-agent 启动 / /prd 命令
• test-agent 启动 / /test 命令

Core Principles

1. 每个用户故事至少 1 条 happy-path + 1 条 edge-case
2. 可自动化测试 是硬约束——如果测试工程师无法在不问产品的情况下把它变成代码，它就不合格
3. Non-Goals 和验收标准等重要——明确边界防止实现漂移

Format

Given <前置状态 / 上下文>
When  <用户动作 或 系统事件>
Then  <可观测结果，含可量化断言>

示例（登录场景）

# Happy-path
Given 用户已注册（email: alice@example.com，password: 已设置）
When  用户提交正确的 email + password
Then  HTTP 200，body.token 存在（JWT 格式），有效期 1 小时

# Edge-case：密码错误
Given 用户已注册
When  用户提交正确 email + 错误 password，连续 5 次
Then  第 5 次返回 HTTP 429，body.error.code = "too_many_attempts"，锁定 15 分钟

# Edge-case：账号不存在
Given 系统中无此 email 的用户
When  用户提交该 email
Then  HTTP 404，body.error.code = "user_not_found"

Do

• 使用可观测的结果（HTTP 状态码 + 响应字段断言、页面上出现的精确文本）
• 数值要具体（响应时间 < 500ms，而不是"响应快"）
• 错误路径要给出确切错误码或错误文案（而不是"报错"）
• 边界值全覆盖：0 / 1 / 最大值 / 负数 / 空字符串 / null / 超长输入

Don't

• 写"系统应该正确处理 X"（"正确"无客观判定）
• 写"用户体验要好"（不可测）
• 写"根据需要返回相关数据"（糊弄词，定义不清）
• 写"性能要足够快"（没有数值的性能要求无效）

可测试性判定表

Self-Test（交给 test-agent 前自问）

• 我能只看这条验收标准写出 test 代码吗？
• "通过 / 不通过" 的判定是客观的吗？
• 边界值（0 / 1 / 最大值 / 负数 / 空 / null）都覆盖了吗？
• 每个用户故事至少有 1 条 happy-path + 1 条 edge-case 吗？
• 非目标（Non-Goals）≥ 3 条吗？

Templates & References

• templates/prd.template.md（内含验收标准填写示例）
• skills/api-contract-first/SKILL.md（错误码与验收标准对应关系）