verify-manual

Manual Verification Handbook Generator

Generate a step-by-step verification handbook for the just-completed code implementation, stored in the docs/verify/ directory.

Trigger Scenarios

The user actively says "help me verify", "verification handbook", "verify", "do a manual test"
/to-prd or /to-issues Automatically triggered after code completion

Prerequisite Information Collection

Before generating the handbook, first confirm the following information (if it is already in the context, just use it; do not ask again):

Issue/PRD number — the basis for the verification handbook's filename
What was changed — read the most recent git diff or conversation context, and summarize the scope of changes
Application type — Web frontend / API backend / CLI tool / full stack (determines the verification method)

If the issue number cannot be determined, use verify-YYYY-MM-DD.md instead.

Generation Process

Step 1: Analyze the changes

Run the following command to understand what was changed:

git diff --stat HEAD~1
git diff HEAD~1 -- '*.py' '*.ts' '*.tsx' '*.js' '*.jsx'

Combine with the conversation context, and summarize:

Which functionality was added
Which existing behavior was modified
Related areas that may be affected

Step 2: Generate the verification handbook

Based on the analysis results, generate a verification handbook with the following structure:

# 验证手册 · Issue #NNNN — [简短标题]

> **生成时间**: YYYY-MM-DD HH:MM
> **变更范围**: [一句话概括改了什么]
> **应用类型**: [Web 前端 / API 后端 / CLI / 全栈]

---

## 🔴 冒烟测试（5 分钟）

> 先确保最基础的东西能跑起来。任何一步失败就停止，不需要继续。

### 1.1 服务启动

- **步骤**: [启动命令，如 `cd backend && uvicorn main:app --reload`]
- **预期**: 服务启动无报错，监听在预期端口
- **截图**: 终端输出截图
- [ ] 通过
- [ ] 失败 — 实际结果: _______________

### 1.2 基础连通性

- **步骤**: [如 `curl http://localhost:8000/health` 或打开浏览器访问首页]
- **预期**: 返回 200 或页面正常渲染
- **截图**: 浏览器/终端截图
- [ ] 通过
- [ ] 失败 — 实际结果: _______________

---

## 🟡 功能点验证（核心）

> 逐个验证本次变更的核心功能点。每个功能点独立测试。

### 2.1 — [功能点名称]

**前置条件**: [如"已登录"、"数据库有测试数据"等，没有就写"无"]

- **步骤**:
  1. [具体操作 1，如"打开 /rules 页面"]
  2. [具体操作 2，如"点击「新建规则」按钮"]
  3. [具体操作 3，如"填写名称字段为 test-rule"]
- **预期**: [期望看到的结果，如"规则创建成功，出现在列表中"]
- **截图**: [在哪里截图]
- [ ] 通过
- [ ] 失败 — 实际结果: _______________

### 2.2 — [功能点名称]

[同上结构...]

---

## 🟢 端到端场景（完整流程）

> 走一个完整的用户流程，验证各功能点协同工作。

### 3.1 — [场景名称，如"完整的规则创建→查看→编辑→删除流程"]

**前置条件**: [需要的初始状态]

- **步骤**:
  1. [步骤 1]
  2. [步骤 2]
  3. [步骤 3]
- **预期**: [整个流程顺畅完成，无报错]
- **截图**: [关键节点截图]
- [ ] 通过
- [ ] 失败 — 实际结果: _______________

---

## 📋 验证总结

| 层级 | 通过 | 失败 | 跳过 |
|------|------|------|------|
| 冒烟测试 | 0 | 0 | 0 |
| 功能点 | 0 | 0 | 0 |
| 端到端 | 0 | 0 | 0 |

**结论**: [ ] 全部通过，可以合并 / [ ] 有问题，需要修复

**遗留问题**:
-

Step 3: Write to file

Write the generated handbook to docs/verify/issue-NNNN.md(or docs/verify/YYYY-MM-DD.md）。

If the docs/verify/ directory does not exist, create it first:

mkdir -p docs/verify

Step 4: Output summary

Output in the conversation:

✅ 验证手册已生成：docs/verify/issue-NNNN.md

📋 验证清单概览：
- 🔴 冒烟测试：X 步（先跑这个，5 分钟）
- 🟡 功能点：X 个（逐个验证）
- 🟢 端到端：X 个场景（完整流程）

💡 建议：先跑冒烟测试，通过后逐个验证功能点。
   发现问题直接在手册里打 ❌ 并记录实际结果。

Verification Method Reference

Depending on the application type, verification steps are written differently:

Web frontend

Steps are mainly "open/click/fill in/submit"
Expectations are mainly page state/navigation/Toast notifications
Screenshot guidance is specific to the page area

API backend

Steps are mainly curl commands or Postman requests
Expectations are mainly HTTP status code + response body structure
Screenshot guidance is to the terminal/Postman response

Full stack

Combine frontend operations + backend verification
Check both UI feedback and data persistence

Notes

Steps must bespecific enough to follow blindly, and vague descriptions like "test the functionality" must not be written
Expected results must bedeterminable, and "should be normal" must not be written; instead write "returns 200, body contains {"id": N}"
Smoke test steps should be kept within 3 steps, ensuring it can be completed in 5 minutes
Each functionality verification point should be kept within 5 steps
If the change is very small (for example, only one field validation was changed), the end-to-end scenario can be omitted