wreck-it：在用户之前搞垮你的应用是做什么的？

下文中的 WRECK 指代 npx @miyanishar/wreck-it。CLI 负责确定性工作（设置、端点发现、扫描、模糊测试、页面速度、负载测试、问题追踪、评分、报告、测试）。你通过 Playwright MCP 驱动浏览器，扮演用户角色，判断什么是 Bug 并将其追溯到代码。

仅出报告。运行期间不要修复 Bug，除非用户在看到报告后要求修复。

规则（始终遵守）

仅限本地。 CLI 拒绝非本地目标。只有当用户声明他们拥有某个远程目标时，才传递 --i-own-this。
仅使用假数据。 使用测试账号、假名称，绝不使用真实的个人或支付数据。将你创建的内容命名为 wreck-it …，并记录日志：WRECK run created "<what>" --by <persona>（报告中会列出以便清理）。
写入前先询问。 预检的 safety.ask 列出了以下问题：托管（通常是生产）数据库、真实的 Stripe 密钥、没有可阅读收件箱的电子邮件、付费的 AI/SMS 调用。在一条消息中全部问完，并在正常用户阶段之前，将每个“是”的记录保存在 .wreck-it/config.json（allowRemoteDb、testEmail、allowSideEffects）中。如果数据库是生产数据库，主动停止，以便用户将应用指向开发环境。
金钱与消息。 仅使用 Stripe 测试密钥（卡号 4242 4242 4242 4242）进行支付；如果是真实密钥，则在支付步骤停止。除非用户允许，每个流程中触发 AI/SMS/电子邮件操作最多 2-3 次。fuzz 和 load 会跳过这些端点。
电子邮件。 使用 WRECK email new 生成的地址注册，绝不使用 example.com。对于本地收件箱，你自己读取链接（WRECK email read --to <address>）；否则向用户询问链接，或将检查标记为“已跳过：无可读收件箱”。
保持共享登录状态活跃。 切勿注销、删除或更改其他阶段使用的账号密码：在 Supabase 和许多应用中，注销会结束该用户的每一个会话。测试注销和删除功能应放在最后，并使用一次性账号。

聚焦运行（单个功能）

当用户指定单个功能或流程（“测试结账流程”/“/wreck focus signup”）时，仅在几分钟内测试该功能：

执行 WRECK run init --focus "<feature>"、WRECK discover、WRECK setup --dry-run 和 WRECK preflight --wait 5，处理方式同阶段 1。仅当该功能需要登录时才登录（阶段 2）。仅当该功能会写入数据时才询问 safety.ask 问题。
确定范围。 根据 discovery.json 和代码，列出该功能的页面和 API 路由（例如 /cart、/checkout、/api/cart、/api/orders）。用一句话告知用户范围。
测试它（跳过不适用的角色和阶段，将其标记为 skipped）：
- 先以普通用户身份操作该功能，然后以手机上的匆忙新手身份操作（双击、错误格式、中途返回）。检查探索技能中适用的检查清单（总计、持久化、删除、错误消息）。
- WRECK sweep --record --only <pages…> 和 WRECK fuzz --record --only <api routes…>。
- 混沌技能的恶意输入、双击、导航和网络故障，仅针对该功能的表单。
- 如果该功能有自己的页面，执行 WRECK perf --record <pages…>。
复现并追溯每个问题（阶段 9），然后执行 WRECK report && WRECK gen-tests。报告标记为聚焦运行：说“功能评分”，而不是“就绪度”。

管道

用 WRECK run stage <stage> running|done|skipped|failed 标记各个阶段。过程中保存问题。

1. 设置与预检

WRECK run init               # --fresh 丢弃上一次运行的问题
WRECK discover
WRECK setup --dry-run        # 已安装什么，缺少什么
WRECK preflight --wait 5

如果 setup --dry-run 列出了需要安装的内容，显示给用户并询问一次；用户同意后执行 WRECK setup。如果它添加了 MCP 服务器，浏览器工具仅在用户重启代理后才会出现：告知用户这一点，同时提供仅 CLI 运行的方式。
浏览器工具提示“浏览器 … 未安装”：执行 WRECK setup --skip playwright-mcp devtools-mcp，然后重试。
预检退出码 4（应用无法访问）：主动在后台启动 devScript，然后执行 WRECK preflight --wait 60。退出码 3（目标拒绝连接）：停止并解释。
没有 .wreck-it/config.json：创建 {"baseUrl": "http://localhost:3000"}（使用真实端口）。
仅 CLI 运行（无浏览器工具）：sweep --record、fuzz --record、perf --record、阶段 7 和报告；将 personas、normal、explore、chaos 标记为 skipped 并说明原因。决不假装你点击了整个应用。

2. 登录

Google、GitHub、SSO、托管登录、魔法链接、2FA（discovery.json 中 auth.sso 已设置，或没有密码字段）：告知用户“浏览器窗口将打开。以你的测试用户身份登录；登录后窗口会自动关闭。”执行 WRECK login（最多等待 10 分钟；使用较长的超时时间）。其输出应显示 check: valid。对于需要双用户检查的情况，使用 WRECK login --label second；对于全新账号检查，使用 --label fresh，或将其标记为跳过。
邮箱和密码： 注册测试账号（或使用用户的账号），并将 "accounts": [{"label": "main", "email": "…", "password": "…"}] 添加到配置中。
此后：sweep、fuzz 和 perf 会自动登录。在浏览器中，在访问登录后的页面之前，调用 browser_set_storage_state，参数为 {"filename": ".wreck-it/auth/<label>.json"}。记录为登录状态下的问题会获得 "auth": "<label>"，其步骤从登录后开始。
如果预检或 WRECK login --check 返回 expired，要求用户再次执行 login。

3. 用户角色

使用 wreck-personas 技能。

4-5. 普通用户，然后是用户角色

使用 wreck-explore 技能。在安装了插件的 Claude Code 中，最多可并行运行 3 个角色作为 wreck-persona 子代理，每个角色使用一个浏览器（wreck-browser-1..3）；在此期间不要自己使用浏览器，等待所有子代理完成后再进入阶段 6。其他代理：一个角色接一个角色地运行。

6. 混沌测试

使用 wreck-chaos 技能（扫描、API 模糊测试、恶意输入、双击、导航、网络故障、会话篡改、键盘操作）。

7. 页面速度与负载

使用 wreck-load 技能。

8. 安全测试

不在 v1 中：WRECK run stage security skipped。

9. 复现，然后追溯

WRECK finding list：在全新环境中重新运行每个状态为 ? 的问题，如果问题再次出现，则设置 reproduced: true（未复现的问题不计分）。然后对每个已复现但没有 source 的问题使用 wreck-trace 技能。

10. 报告

在生成报告之前，检查每个复现的浏览器问题的截图是否显示了实际的失败情况。也要复查来自 CLI 扫描的问题；遵循 references/recording-findings.md 中的截图指南。验证保存的图片文件是否存在，并解决任何缺少截图的警告。仅限 API 或负载的问题可以使用请求/指标证据代替；当截图不适用或无法捕获时，请说明情况。

在最后一次问题更新后生成报告和测试。如果此后你更改了某个问题，在展示结果前重新生成两者。阅读 references/regression-tests.md：检查保留的 spec 警告，并将那些测试与更新后的问题协调一致；重新生成时会故意保留代理的编辑和 fixture。对有 Bug 的应用运行支持的 spec，并检查失败是否达到了预期的断言。在报告中披露跳过的、设置失败的、超时的或未经验证的测试；如果存在修正后的副本，也对其执行相同的 spec。

WRECK report && WRECK gen-tests && WRECK run stage report done

探索过程中（阶段 4-6）

严格按照 references/recording-findings.md 记录 Bug：WRECK finding add、结构化步骤、角色/目标标记、描述正确行为的断言，然后在全新环境中重放并设置 reproduced: true。
每次导航后，通过 browser_evaluate 运行异常脚本（WRECK oddity-script，仅一次），并检查 browser_console_messages 和 browser_network_requests（4xx/5xx）。同时留意脚本无法判断的问题：布局损坏、无引导的空状态、无尽转圈、死按钮、不一致的日期或价格。将真实问题记录为 oddity。
记录覆盖率：WRECK run visit <route> --persona <name>。

最终消息

简短消息：评分和等级、“首先修复这个”的问题及其 file:line、按严重程度分类的数量、未完成的阶段、路径 .wreck-it/report.html、.wreck-it/report.md、tests/wreck-it/ 以及 npx playwright test tests/wreck-it。主动修复最高优先级的几个问题；等待用户同意。

在展示 Bug 时，将相关截图附在问题 ID 和解释旁边。使用聊天的图片附件支持或包含实际保存文件路径的 Markdown 图片；仅报告路径不能展示证据。在聊天中展示最高优先级的几个问题及其截图，将完整集合保留在报告中。如果图片不可用或不适用，说明原因，并改为提供请求、追溯或指标的链接。将存储的 shots/... 路径解析为相对于 .wreck-it/ 的路径。

对于你在聊天中包含的每个浏览器问题，使用以下格式（将示例替换为实际问题和已验证的绝对图片路径）：

**WR-007 — 购物车小计忽略数量**（`lib/cart.ts:19`）
三件 $79.99 的商品总价应为 $239.97；但页面显示为 $79.99。
![WR-007：数量 3 但小计错误](/absolute/project/.wreck-it/shots/WR-007-cart.png)

在发送之前，打开你计划展示的每张图片，描述它实际显示的状态和数值。验证你展示的每个浏览器问题都附有图片附件或图片嵌入。列出图片文件名或声明截图已保存不视为附件。通过展示更少的问题及其证据来保持回复简洁，并提供完整报告的链接；将剩余的浏览器问题保留在报告中，而不是在聊天中添加无插图的列表。

wreck-it：在用户之前搞垮你的应用