OpenClaw Parallels Smoke

OpenClaw Parallels Smoke 是做什么的？

使用此技能进行 Parallels 客户机工作流和烟雾测试解读。请勿在常规仓库工作中加载。

全局规则

• Parallels 默认是发布后置信度覆盖，不是有界 beta 发布阶段的先决条件。请针对一个确切的已发布包版本运行，并记录授权该包的 Validation SHA + Tooling SHA 运行元组。Validation SHA 映射到其 Code SHA 或 Release SHA；它不是第三个发布标识。
• 发布后 Parallels 通道失败不会追溯取消发布 beta。将其归类为产品、工具链/来源、基础设施/凭证或包装器故障。只有确认的产品缺陷才进入下一个 beta。
• 为每个独立的客户机家族使用一个协调器和一个通道。诊断并重试一个失败的家族一次，然后重新评估；不要自动重启整个矩阵。
• 在任何配置之前，先清点现有 VM 和快照。如果预配置的原始快照与请求的基线匹配，则切换到它并复用其用户、工具和基本设置。不要为新 VM，重新安装 macOS 或为“全新”运行重建客户机基线。
• “全新”意味着恢复最近的现有原始快照，而不是创建另一个快照。除非用户明确要求或没有合适的基线，否则不要创建临时快照；恢复原始快照并在临时运行后保持客户机停止。
• 在恢复快照之前检查其状态。原始 poweron 快照可能包含预配置的已登录会话；正常切换到它，以便 Parallels 恢复该会话。不要在测试入口点传递 --skip-resume，除非运行故意需要丢弃已保存的会话并从登录窗口启动。--skip-resume 对于必须让恢复的源客户机保持停止的最终清理是可以接受的。
• 烟雾运行中的网关验证应使用 openclaw gateway status --deep --require-rpc，除非正在检查的稳定版本尚不支持它。
• 稳定版 2026.3.12 升级前诊断可能需要简单的 gateway status --deep 回退。
• 将该稳定版预升级通道上的 precheck=latest-ref-fail 视为基线，而不是自动回归。
• 传递 --json 以获得机器可读的摘要。
• 每阶段日志默认位于 .artifacts/parallels/openclaw-parallels-* 下。当运行需要另一个工件卷时，使用 OPENCLAW_PARALLELS_ARTIFACT_ROOT 覆盖。
• 不要在同一个全新工作空间或会话中并行运行本地和网关代理轮次。
• 为每个顶级 Parallels 通道硬性设置主机 timeout --foreground（如果可用则为 gtimeout --foreground），以便停滞的安装、快照切换或 prlctl exec 传输不会消耗剩余的测试窗口。默认值：
  • macOS：75m
  • Linux：75m
  • Windows：90m
  • 聚合 npm-update 包装器：150m 如果某个通道达到上限，则在那里停止，检查最新的 /tmp/openclaw-parallels-* 运行目录和阶段日志，然后修复或重新运行受影响的最小通道。不要继续等待已达到上限的通道。
• 实际的 OpenClaw npm 安装/更新阶段比整个通道上限更严格的信号：安装阶段通常应在 7 分钟内完成，更新阶段通常应在 5 分钟内显示有意义的进展。如果名为 install-main、install-latest、install-baseline 或 install-baseline-package 的阶段超过 420 秒，或名为 update-dev / 同一客户机的 openclaw update 阶段超过 300 秒且没有新标记，则从该阶段日志和客户机进程状态开始诊断。当前的 Windows 更新阶段仍可在大约 10-15 分钟后通过，因为 doctor --fix 可能安装捆绑的插件运行时依赖项；保持脚本硬上限接近 20 分钟，除非日志真正停滞。
• 对于完整的 OS 矩阵，在主机容量允许时，优先并行运行独立的客户机家族通道：
  • timeout --foreground 75m pnpm test:parallels:macos -- --json
  • timeout --foreground 90m pnpm test:parallels:windows -- --json
  • timeout --foreground 75m pnpm test:parallels:linux -- --json 将每个通道保留在自己的 Shell/会话中，并跟踪每个通道的运行目录。在启动矩阵之前，运行任何必需的主机构建/包门控直至完成。当需要当前主版本的 tgz 打包时，smoke 脚本通过 pnpm build、清单/暂存和 npm pack 持有共享包锁；如果该锁丢失或损坏，则序列化矩阵而不是接受并发 dist 变异。
• 不要同时针对同一客户机家族运行多个烟雾通道。Tahoe 通道共享主机 HTTP 端口，如果两个作业同时接触同一 VM，Windows/Linux 通道可能在快照恢复/启动状态上冲突。
• 不要将聚合的 pnpm test:parallels:npm-update 包装器与单独的 macOS/Windows/Linux 烟雾通道并行运行；它会接触相同的客户机家族和快照。
• 在任何不相关的主机命令可能重建、清理或重新暂存 dist（pnpm build、pnpm ui:build、pnpm release:check、pnpm test:install:smoke、npm pack/install smoke 或运行包/构建准备的 Docker 通道）时，不要启动 Parallels 通道。先运行不相关的构建/包门控，让它们完成，然后启动 VM 矩阵。并发的 dist 变异可能使主机 npm pack 因缺少文件而失败，并浪费整个 VM 周期。
• 在运行或优化矩阵时，记录每个通道的 wall‑clock 时长以及来自 /tmp/openclaw-parallels-* 日志的最慢阶段。在更改烟雾顺序、超时或辅助行为之前使用该计时。
• 如果主机构建更改了跟踪的生成文件，例如 src/canvas-host/a2ui/.bundle.hash，则在花费 VM 时间之前停止。单独提交生成的工件或修复生成器漂移，然后重新运行受影响的的最小通道。
• 如果在活跃的多代理工作下 main 正在移动，则对于长时间的 Parallels 套件，优先选择固定到一个提交的分离工作树。烟雾脚本现在验证打包的 tgz 提交，而不是实时的 git rev-parse HEAD，但固定的工作树仍可避免重跑期间嘈杂的重新构建/版本漂移。
• 对于 openclaw update --channel dev 通道，请记住客户机会克隆 GitHub 的 main，而不是您的本地工作树。如果本地修复存在但重跑仍然在克隆的开发检出中失败，则不要将其视为修复的反证，直到分支已被推送。
• 对于 prlctl exec，先传递 VM 名称，然后是 --current-user（prlctl exec "$VM" --current-user ...），而不是相反。
• 如果工作流从仓库检出而不是站点安装程序/npm 版本安装 OpenClaw，则最后安装一个真实的客户机 CLI shim 并在全新的客户机 Shell 中验证它。仓库内的 pnpm openclaw ... 对于交接对等性来说是不够的。
• 在 macOS 客户机上，优先选择用户全局安装以及 PATH 可见的稳定 shim：
  • 使用 NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g . 安装
  • 确保 ~/.local/bin/openclaw 存在或 ~/.npm-global/bin 在 PATH 上
  • 从全新的客户机 Shell 使用 which openclaw 和 openclaw --version 验证

npm install then update（先安装再更新）

• 首选入口点：pnpm test:parallels:npm-update
• 对于仅限 macOS 的已发布版本更新检查，请使用：
  • timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<旧版本> --update-target <目标版本或标签> --json 这保持了同一客户机 openclaw update --tag ... 的覆盖范围，并使用了共享的 macOS 当前用户/sudo 回退，而无需启动 Windows/Linux 通道。
• 必需的覆盖范围：每个版本/更新回归运行必须包括两个通道：
  • 新快照 -> 安装请求的包/基线 -> smoke
  • 同一客户机基线 -> 运行客户机已安装的 openclaw update ... 命令 -> 再次 smoke
• 更新通道必须演练 OpenClaw 的内部更新程序。不要将直接的 npm install -g <tgz-or-spec> 或工具端包交换算作更新流覆盖；那些只是安装烟雾测试。
• 对于已发布的目标，先安装旧基线包（例如 [email protected]），然后使用预期的通道/标签（例如 openclaw update --channel beta --yes --json）运行已安装的客户机 CLI，并在命令之后验证 openclaw --version、openclaw update status --json、网关 RPC 和一个代理轮次。
• 对于未发布的目标，在主机上打包候选版本，通过工具 HTTP 服务器提供 .tgz，并将客户机更新程序指向该提供的包。首选 openclaw update --tag http://<主机 IP>:<端口>/openclaw-<版本>.tgz --yes --json；当通道持久性也很重要时，传递 --channel <stable|beta> 并在客户机更新环境中将 OPENCLAW_UPDATE_PACKAGE_SPEC 设置为同一个提供的 URL。被测试的命令仍必须是 openclaw update，而不是直接 npm。
• 对于未发布的本地修复验证，请记住旧的基线更新程序代码仍控制着第一跳。仅存在于新更新程序代码中的修复无法更改已运行的旧进程；提供的候选版本必须保持与基线主机兼容的包/插件元数据，或者基线本身必须包含更新程序修复。
• 对于 beta/稳定版验证，在运行之前立即解析标签（npm view openclaw@beta version dist.tarball 或 npm view openclaw@latest ...）。当长 VM 矩阵已在运行时，标签可能会移动；在预期的预发布版本通过早期的注册表 404/标签延迟检查出现后，重新启动矩阵。
• 使用配置的秘密工作流仅注入 OpenAI/Anthropic 通道所需的提供程序密钥。不要打印秘密或环境转储；通过客户机执行环境传递提供程序密钥。
• 同一客户机更新验证应在代理轮次之前将默认模型显式设置为 openai/gpt-5.4，并使用全新的显式 --session-id，以便旧会话模型状态不会泄漏到检查中。
• 聚合的 npm-update 包装器必须在全新和更新通道之前使用与 parallels-linux-smoke.sh 相同的 Ubuntu 回退策略解析 Linux VM。当确切的默认 VM 缺失时，将主版本 >= 24 的任何 Ubuntu 客户机视为可接受，首选具有最新原始电源关闭快照的最新版本 Ubuntu 客户机。在 Peter 当前的主机上，使用 Ubuntu 26.04。
• 在 macOS 同一客户机更新检查中，在 npm 升级后、gateway status / agent 之前重新启动网关；否则 launchd 可能会报告已加载的服务，而旧进程已退出且新进程尚未准备好 RPC。
• npm-update 聚合的 macOS 更新部分将客户机更新脚本写为 root，然后以桌面用户身份运行。如果 prlctl exec "$MACOS_VM" --current-user ... 无法认证，则通过普通 root prlctl exec 加上 sudo -u <桌面用户> /usr/bin/env HOME=/Users/<桌面用户> USER=<桌面用户> LOGNAME=<桌面用户> PATH=/opt/homebrew/bin:/opt/homebrew/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin ... 重试。这是 Parallels 传输回退；仍应在更新后验证 openclaw --version、网关 RPC 和一个代理轮次。
• 在 Windows 同一客户机更新检查中，在 npm 升级后、gateway status / agent 之前重新启动网关；否则就地全局 npm 更新可能会使正在运行的服务中存在陈旧的散列 dist/* 模块导入。
• 在这些 Windows 同一客户机更新检查中，不要将一个非零的 openclaw gateway restart 视为绝对失败。当前的登录项重启可能在后台服务再次可观之前报告失败；随后进行更长的 RPC 就绪等待，并且仅当就绪状态仍未返回时，才使用 gateway start 作为恢复步骤。
• 在该 Windows 重启之后，不要信任在固定睡眠之后的一次 gateway status --deep --require-rpc 调用。重试 RPC 就绪探测大约 30 秒并记录每次尝试；当前客户机可以在新的 RPC 端点仍在启动时将端口 18789 保持绑定。
• 对于 Windows 同一客户机更新检查，优先使用完成文件/日志耗尽 PowerShell 运行程序模式，而不是长时间存在的 prlctl exec ... powershell -EncodedCommand ... 传输。客户机可能成功完成，而外部的 prlctl exec 仍然挂起。
• Windows 同一客户机更新辅助程序应在长时间步骤（如 tgz 下载和 npm install -g）之前将阶段标记写入其日志，以便外部进度监视器在健康但静默的安装期间不会停留在 waiting for first log line 上。
• Linux 同一客户机更新验证还应导出 HOME=/root，通过 prlctl exec ... /usr/bin/env 传递 OPENAI_API_KEY，并使用 openclaw agent --local；全新的 Linux 基线不依赖持久化的网关凭据。
• npm-update 包装器现在从嵌套日志文件打印每个通道的进度。如果某个通道看起来仍然停滞，请先检查 runDir 中的嵌套日志（macos-fresh.log、windows-fresh.log、linux-fresh.log、macos-update.log、windows-update.log、linux-update.log），而不是假设外部包装器挂起。
• 每次运行都会写入 summary.json 和 summary.md；首先阅读 markdown 以进行快速人工分类，然后阅读 JSON/计时以进行自动化。
• 对于标签发布后的完整 beta 验证，首选一个命令：
  • timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json 这会将 beta3 解析为最新的 *-beta.3 版本，运行最新->该版本的同一客户机更新覆盖，然后在相同选定的 OS 矩阵上对该确切的已发布目标运行全新安装烟雾测试。使用 --platform macos|windows|linux 缩小重跑范围。
• 对于带有代理轮次的 beta 4 npm 验证，已知良好的形状是：
  • gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai/gpt-5.4 --json 在验证特定预发布版本号时，优先使用显式的 beta4 别名而不是 openclaw@beta；npm 标签可能会移动。
• 如果包装器使某个通道失败，请阅读…

[因翻译而截断]