Acceptance Design

用于设计验收标准和验收记录。

When to Use

• 需要编写验收条件和验证命令
• 需要建立任务到验收报告的追踪
• 需要补测试用例和已知缺口
• Prompt 完成后，需要设计如何验收输出

Input

Output Schema

Minimum Viable Output

• acceptance/README.md 含每个 MVP Task 至少 1 个验收条目（≥3 条）
• 每个验收含：验收条件 + 通过/失败标准
• 含 acceptance-plan.md 矩阵（任务→验收映射）

Complete Output

• acceptance/README.md：完整索引，含所有验收状态
• 每个 A-NNN.md：含验证命令、手工检查点、已知缺口
• acceptance-plan.md：完整验收矩阵（任务ID×Prompt×验收×报告）
• 含 reports/acceptance/ 下的执行报告模板

Dependencies

Procedure

1. 先确认目标项目根目录，并只在该项目目录下写验收与报告
2. 验收条件必须量化
3. 每个任务至少对应一个验收文件
4. 报告中记录实际命令、输出、预期和结果

量化验收标准示例

✅ 量化（通过）

- API 响应时间 ≤200ms（P99）
- 用户操作完成率 ≥90%
- 登录失败率 <1%
- 每次搜索返回结果 ≤3s

❌ 不可量化（不通过）

- "系统应该快速响应" → 应改为具体 ms 数
- "用户体验应该流畅" → 应改为操作完成率或响应时间
- "错误率应该在可接受范围内" → 应改为具体百分比

acceptance/A-NNN.md 模板

# 验收: <任务ID> — <任务名称>

## 验收条件

| # | 条件 | 通过标准 | 验证方式 |
|---|------|---------|---------|
| 1 | ... | ... | 命令/手工检查 |
| 2 | ... | ... | 命令/手工检查 |

## 验证命令

```bash
<具体命令>

通过标准: <输出应包含的内容或数值>

手工检查点

• ...
• ...

已知缺口

• ...

执行记录

### reports/acceptance/R-NNN.json 模板

```json
{
  "id": "A-001",
  "task_id": "T1",
  "task_name": "<任务名称>",
  "executed_at": "YYYY-MM-DDTHH:mm:ss",
  "executor": "<执行人>",
  "result": "PASS | FAIL | PARTIAL",
  "checks": [
    {
      "id": 1,
      "condition": "<验收条件描述>",
      "criterion": "<通过标准>",
      "verification_method": "命令 | 手工检查",
      "actual_result": "<实际结果>",
      "passed": true
    }
  ],
  "command_output": "<如有命令，输出摘要>",
  "known_gaps": ["<缺口描述，如有>"],
  "notes": "<备注>"
}

Enriched Behavior

• 不只列检查项，要形成"可执行、可重复、可回溯"的验收闭环
• 可以同时覆盖功能、结构、回写一致性、已知缺口和失败重试策略
• 当命令还无法完全自动化时，可以先给手工检查步骤和通过标准，不要放弃落文档
• 输出应直接服务于开发自检和人工复核

Target Pages

• <项目根目录>/acceptance/README.md（主）
• <项目根目录>/acceptance/（验收文件目录）
• <项目根目录>/wiki/06-quality/acceptance-plan.md（主）
• <项目根目录>/wiki/06-quality/test-cases.md（辅）
• <项目根目录>/reports/acceptance/（报告目录）

页面归属说明

Changelog