页面自动测试任务卡

每条要长期保留的浏览器测试，在 .ai/web-e2e/<flow-id>.md 保留一张任务卡。任务卡记录业务决策，不记录 CSS 选择器和具体 Playwright 写法。

谁负责什么

AI 从代码和页面查明：

• 路由、菜单、页面字段和按钮；
• 现有 API、状态值、数据依赖和已有测试；
• 项目的包管理器、Playwright 配置和报告命令。

页面负责人决定：

• 最值得保护的业务结果；
• 哪些专用数据和账号可以使用；
• 什么精确结果算通过；
• 是否允许写入、API 辅助和清理。

模板

---
id: <稳定的小写连字符编号>
name: <业务人能看懂的流程名>
risk: read-only | writes-test-data
---

## 1. 业务目标

<只写这条流程要防止什么用户可见问题>

## 2. 入口与权限

- 环境：<local | test | preview>
- 页面/菜单：<路由和菜单名>
- 角色：<专用测试账号所需角色>
- 允许域名：<明确域名列表>

## 3. 前置数据

- <可稳定定位的专用样本、状态和唯一标识>
- 缺失时：BLOCKED，不用 mock 伪造通过。

## 4. 用户主路径

1. <用户操作>
2. <用户操作>
3. <用户操作>

## 5. 通过标准

- <可观察、可判定的状态、数量或数据变化>
- <不使用“正常”“无异常”等含糊描述>

## 6. 写入与清理

- 允许写入：<是 | 否>
- 允许 API 辅助：<前置 | 触发 | 清理 | 都不允许>
- 测试数据前缀：<专用前缀>
- 精确清理方式：<页面操作或现有 API>

## 7. 限制与证据

- 已知限制：<验证码、调度等待、第三方页面等>
- 失败证据：HTML 报告 + 截图 + trace；需要时加录像。

完整性检查

满足以下条件后才生成用例：

• 只有一个明确的业务主目标；
• 前置数据可以稳定找到，或已授权创建；
• 每个通过标准都能从页面、真实 API 或允许的数据查询观察；
• 写操作的授权、前缀和清理边界明确；
• 登录和验证码的人工接管方式明确。