用途
e2e-run 用于运行当前项目中已经存在的 e2e 资产，并把执行证据、问题分类和下一步建议沉淀为稳定产物。该技能不是用来生成新用例；如果仓库里没有 e2e 脚本或规格，应明确建议使用 /e2e-find。该技能仅面向用户显式触发，不用于其他技能链式调用。
主要能力
- 先发现已有 e2e 资产，再决定执行路径，不盲跑命令。
- 优先复用项目原生测试框架；只有在缺少脚本时才走规格驱动验证。
- 每次执行都保存一份可追溯快照，包含人类可读报告和机器可读摘要。
- 问题分析必须可操作，区分环境、数据、脚本失败、规格漂移与未知问题。
使用方式
工作流程如下：
- 收集项目上下文：优先读取根目录和子包中的 package.json、pnpm-workspace.yaml、turbo.json、nx.json、playwright.config.、cypress.config.、Makefile、docker-compose*.yml、README*、docs/。用户传入的 $ARGUMENTS 视为范围提示，例如路由或页面 /login、功能 checkout、用例路径或目录 tests/e2e/auth。
- 发现 e2e 资产：按 references/discovery-and-routing.md 分类为 script（可直接运行的 Playwright/Cypress/项目原生 e2e 脚本）或 spec（Markdown 规格，通常来自 specs/e2e/、docs/e2e/、tests/e2e/specs/）。记录发现的 runner、脚本命令、测试目录和规格文件，默认运行范围是 smoke、critical、main-path 还是用户显式指定范围，以及被排除的候选资产和原因。若既无 script 也无 spec，立即停止并建议用户先使用 /e2e-find。
- 推断如何运行服务：根据 references/discovery-and-routing.md 推断被测服务的启动命令与入口地址，优先选择最接近项目推荐开发方式的命令、能支撑当前范围验证的目标应用、启动成本最低且最容易获得稳定证据的命令。不要无说明地同时盲跑多个候选命令。若推断出的正确启动或执行命令超出当前 allowlist，可返回 needs-input。
- 选择执行模式：若发现可执行脚本，以 script 模式为主；若没有脚本但存在 Markdown 规格，进入 spec 模式；若两类都存在，可用规格辅助限定范围、命名产物和补充问题分析，但不要让规格覆盖脚本真实结果。若用户未指定范围，默认只跑 smoke、critical、main-path 小集合；若项目内没有这些标记，则选择主链路最清晰的一组案例。无法安全收敛时，停止并说明原因。
- 执行并收集证据：
- Script 模式：启动服务，记录本次启动进程的 PID 或等价标识，只允许清理由本次运行启动的进程；运行项目原生 e2e 命令或最小必要的 runner 命令；将标准输出、错误输出和关键失败片段写入快照目录；尽可能保留 runner 自带的报告、trace、截图、视频或 junit/xml 文件。
- Spec 模式：启动服务，记录本次启动进程的 PID 或等价标识，只允许清理由本次运行启动的进程；读取目标规格中的主流程、前置条件、终态断言与代码锚点；优先使用 agent-browser 执行真实交互验证；若不可用或不稳定，则降级到带重试的 HTTP 可达性检查、入口 HTML、关键 URL 跳转、关键 API 返回等最小证据；不要把规格伪装成已自动化脚本，无法可靠验证的步骤标记为 blocked。
- 保存输出：严格遵循 references/output-policy.md，为本次运行选择一个稳定的项目内结果目录，为单次执行创建独立快照目录，至少写入 report.md、summary.json、service.log、runner.log；若有截图、trace、视频或 HAR，统一放到 evidence/；在收尾阶段停止本次技能启动的服务进程，如果服务不是本次启动，只记录现状，不主动终止。report.md 和 summary.json 的字段必须分别遵循 references/report-template.md 和 references/summary-template.md。
- 分析问题：对每个失败、阻塞或可疑结果做归因，分类仅限 environment、data/auth、test failure、spec drift、unknown。分析中必须包含触发该问题的用例或规格、证据来源、为什么归到该类别、最小下一步建议。
- 向用户汇报结果：至少说明本次采用了 script 还是 spec 模式、选择了哪个启动命令和入口地址、执行了哪些用例或规格、通过/失败/阻塞各有多少、结果目录和关键证据文件位置；如果无用例，说明为什么建议转到 /e2e-find。
适用场景
- 用户要求运行 e2e 测试、执行 Playwright/Cypress 用例、针对运行中的服务验证已有 e2e 规格。
- 示例一：用户说“运行这个项目的登录 e2e，并把失败原因记下来”，应先找 Playwright 配置、测试目录和登录相关标签或文件，判断服务启动命令和登录入口，跑最小必要的登录用例，把结果保存为一次快照并输出失败归因。
- 示例二：用户说“根据现有 e2e 规格验证 checkout 主流程，并保存结果”，应找到 checkout 规格文件，启动目标服务，优先用 agent-browser 验证主流程，否则退化到 HTTP 和入口证据，把结果标记为 spec 模式并说明哪些步骤仍需真实自动化脚本。
- 示例三：用户说“帮我跑一下这个项目的 e2e”，若发现仓库里既无 e2e 脚本也无 e2e 规格，应明确给出已检查的目录和配置，建议用户改用 /e2e-find 先生成或补齐用例。
限制与约束
- 不要先跑服务再猜用例。
- 不要默认跑全量 e2e，除非用户明确要求。
- 不要覆盖上一次结果；每次执行必须保留独立快照。
- 不要把日志直接堆进最终回复；把日志写入文件，在回复中给出结论和路径。
- 不要把规格驱动验证描述成“测试已全部自动化通过”。
- 不要省略失败证据和下一步建议。
- 无法判断启动命令时，列出已检查的文件、候选命令和缺失信息，不要盲跑多个服务。
- 需要账号、验证码或外部依赖时，允许继续收集最小证据，但将受影响用例标记为 blocked 或 needs-input，并在报告中说明缺口。
- runner 自带报告目录不稳定时，优先保留原始 runner 产物路径，同时在本次快照目录内建立索引或拷贝必要证据，不要强行改写项目现有配置。
- 服务可能遗留后台进程时，仅允许终止本次技能显式启动并记录了 PID 的进程；若端口已被已有服务占用，只记录并复用或返回 needs-input，不要杀掉未知来源的进程。
附加资源
- 发现规则与双路径路由见 references/discovery-and-routing.md
- 结果目录与落盘策略见 references/output-policy.md
- Markdown 报告结构见 references/report-template.md
- JSON 摘要结构见 references/summary-template.md
- evals/evals.json 提供触发与行为样例
- agents/openai.yaml 提供该技能的 UI 元数据