用途
replica-test 用于测试一个应用克隆（clone），而不是原始应用。它基于侦察阶段产出的流程地图，系统性地生成测试计划、自动化测试和缺陷报告。
核心规则：测试你的克隆，不要测试原始应用。绝不对原始应用的服务器进行负载测试、模糊测试、脚本化请求或高频访问。以普通用户身份手动使用原始应用来观察其行为是允许的。
主要能力
第一步：生成测试计划
读取 replica/recon.md 中的流程（F01、F02……），为每个流程编写：
- 正常路径（Happy path）：步骤以及用户最终应看到的结果。
- 适用的边界情况（Edge cases），逐项检查：空输入、超长输入、emoji 和重音字符、同时打开两个标签页、重复点击提交、流程中途按返回键、流程中途刷新、慢网络、离线、会话过期、第二个用户的数据（必须不可见）、时区和夏令时、移动端宽度、仅键盘操作、屏幕阅读器标签。
- 负面用例（Negative cases）：错误密码、银行卡被拒（Stripe 测试卡 4000 0000 0000 0002）、权限被拒、记录已删除。
每个用例编号，如 F01-H1、F01-E3、F01-N2。
第二步：尽可能自动化
使用 Playwright，每个流程一个 spec，针对带种子数据的本地开发服务器运行。选择器使用角色和标签（如 getByRole('button', { name: 'Book' })），不要使用 CSS 类。参考 e2e.example.spec.ts。
安装与运行命令：
npm i -D @playwright/test && npx playwright install chromium npx playwright test
每个 spec 都应包含：控制台错误时失败、任何 5xx 响应时失败，以及每个屏幕上的 axe 无障碍扫描（@axe-core/playwright）。
第三步：手动点击其余部分
无法自动化的内容（邮件到达、真实提供商的 OAuth、端到端支付、视觉故障）进行手动检查。如果有浏览器工具可用，用它驱动本地克隆并截图每一步。否则给用户检查清单并等待回答。
第四步：报告缺陷
每个缺陷按 bug-report.md 格式写入 replica/bugs.md：ID、严重程度、精确步骤、预期、实际、证据。严重程度定义：
- S1：数据丢失、安全漏洞、支付错误、核心流程阻塞
- S2：功能损坏且无变通方法
- S3：有变通方法但损坏，或明显错误
- S4：外观问题
只报告已复现的问题。“可能是问题”的内容放入单独的“待检查”列表。
第五步：修复循环
优先修复 S1 和 S2。每个修复：先写失败测试，修复，观察测试通过，保留测试。每批修复后重新运行整个测试套件。在 bugs.md 中更新修复每个缺陷的提交。
输出
test-plan.md、spec 文件、bugs.md，以及一份摘要：运行的用例数、通过数、失败数、按严重程度分类的缺陷、已修复数量。存在未解决的 S1 时不得交付。下一步：/replica-diff。
适用场景
- 在复刻一个应用后，需要系统性地验证克隆的功能正确性。
- 需要为克隆生成结构化的测试计划和自动化端到端测试。
- 需要记录和跟踪克隆中的缺陷并推动修复。
限制
- 仅测试克隆，不得对原始应用服务器进行任何形式的自动化攻击或压测。
- 部分场景（邮件、真实 OAuth、端到端支付、视觉故障）无法自动化，需手动检查。
- 需要本地开发服务器和种子数据。
- 存在未解决的 S1 缺陷时不应交付。