HyperExecute 操作员

要解决什么问题

在 LambdaTest HyperExecute 上跑自动化测试时，真正容易踩坑的往往不是「会不会写测试」，而是 hyperexecute.yaml 与本地/CI 环境是否一致、官方 CLI 能否通过 --validate，以及云作业失败后日志与工件散落在哪。凭据硬编码、作业密钥进仓库、未验证就直接 --run，都会把问题放大到云端才暴露。

技能如何工作

本技能把 HyperExecute CLI 当作 analyze、验证、执行、日志与工件的权威来源，按固定流程推进：

1. 定位 CLI；缺失时先询问再下载（非自治会话不得擅自装）。
2. CLI 可用则运行 hyperexecute analyze，否则退回本地检查。
3. 结合 analyze 输出、项目测试命令与 reference/ 模板编写或修复 hyperexecute.yaml。
4. 运行 node scripts/doctor.js --config hyperexecute.yaml 与 node scripts/validate-config.js hyperexecute.yaml。
5. 用官方命令 ./hyperexecute --user "$LT_USERNAME" --key "$LT_ACCESS_KEY" --config hyperexecute.yaml --validate 做最终校验。
6. 实际云作业前必须确认（除非用户已选自治 HyperExecute 会话）。
7. 失败时按 reference/troubleshooting.md 下载日志/工件/报告。

辅助脚本包括 build-command.js（打印安全的验证/运行/下载命令）、summarize-artifacts.js（汇总下载物）。参考资料覆盖 CLI 标志、YAML 模式、框架配方、CI/CD 与安全规则。

适用边界与注意点

• 优先 模板驱动 YAML，而非泛化生成器；测试命令与路径因项目而异。
• 使用 LT_USERNAME / LT_ACCESS_KEY 环境变量或 CI 密钥；额外范围密钥用 --job-secret-file，且应被 .gitignore / .hyperexecuteignore 排除。
• 自治模式下：先验证再运行，检查输出，必要时拉取工件；仅在配置或环境可修复时重试，避免盲目重复提交云作业。