OpenClaw 预发布插件测试
当用户询问插件发布信心、插件生命周期扫描、包制品插件验证，或“发布前还应测试什么？”时，使用本技能。它是对 openclaw-testing 的补充；在选用最便宜的安全运行器或调试失败的通道时，也应同时使用那个技能。
目标
将插件系统作为产品表面进行验证，而不仅仅是源码测试：
- 捆绑插件生命周期：安装、检查、启用、禁用、卸载
- 包制品在全新
HOME下的行为 - doctor/fix/config 验证及其幂等性
- 配置发现与配置往返
- 状态/日志可见性与诊断
- 网关启动/引导及插件元数据快照
- 针对真实外部插件的公共 SDK 兼容性
- 仅在存在安全凭据时才进行实时提供商/通道探测
首要检查
在 OpenClaw 仓库根目录下执行：
pnpm docs:list
git status --short --branch
pnpm changed:lanes --json
参考 openclaw-testing 以了解依赖归属以及本地或远程验证方式的选择。
运行器选择
优先顺序如下：
- GitHub 包验收：用于可安装包的产品验证。
- 当前专属 Linux 工作节点：用于受信任的源码/包/Docker 验证，前提是它拥有所需的依赖和功能。
ci-build-artifacts-testbox.ymlTestbox：当 Docker/包通道需要预先填充的dist、dist-runtime和包缓存时使用。ci-check-testbox.ymlTestbox：用于源码检查、目标化 Vitest、包边界检查或聚焦的 Docker 通道。- 仅限工作站的定向命令：用于小型格式化/静态/单元探测。
避免从过时的稀疏工作树运行长时间的包 Docker 运行。如果 Testbox 同步报告数百个更改的文件或开始删除包输入，请停止并从当前 main 预热一个新的盒子，或切换到包验收。
现有基准
在发明新的覆盖率之前，先运行或验证以下内容：
OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update
对于完整的捆绑安装/卸载验证，对打包的扫描进行分片：
OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall
此示例将所选包的插件清单划分为分片 0-7。私有 QA 插件仅以源码模式存在，除非包明确包含它们。
置信度矩阵
使用此矩阵进行预发布签核。记录通过/失败、运行 URL/Testbox ID、包 SHA/版本以及跳过实时探测的原因。
| 表面 | 证明 | 首选运行器 |
|---|---|---|
| 包制品 | 包验收 suite_profile=package 或自定义通道 | GitHub Actions |
| 捆绑生命周期 | 分片 test:docker:bundled-plugin-install-uninstall | Testbox 或发布版 Docker |
| 外部插件 | test:docker:plugins 和 plugins-offline | Testbox/包验收 |
| 更新无操作 | test:docker:plugin-update | Testbox/包验收 |
| 诊断/修复 | 预设错误配置 + doctor --fix --non-interactive | 新的 Docker/Testbox 工具 |
| 配置往返 | config set/get, inspect, doctor, reload, diff hash | 新的 Docker/Testbox 工具 |
| 网关引导 | 全新 HOME，插件组启用/禁用，状态 JSON | 新的 Docker/Testbox 工具 |
| SDK 兼容性 | 使用 SDK 子路径的目录、tgz 和 file: 外部插件 | test:docker:plugins 加新的冒烟测试 |
| 实时探测 | 仅针对存在的环境进行脱敏的提供商/通道探测 | Testbox 实时通道 |
包验收计划
完整的发布验证负责最终的候选资格认证，使用 Q=C 和确切的发布 tarball。使用独立的包验收进行诊断或发布后置信度验证，但不能替代候选资格认证：
gh workflow run package-acceptance.yml \
--repo openclaw/openclaw \
--ref main \
-f workflow_ref=main \
-f source=ref \
-f package_ref=<分支或sha> \
-f suite_profile=custom \
-f docker_lanes='plugins-offline plugin-update doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
-f telegram_mode=mock-openai
对于已发布的 beta 通道验证，使用 source=npm -f package_spec=openclaw@beta。这些独立的诊断/置信度运行可以使用受信任的当前工具代码；候选资格认证必须保留冻结候选者的工具。
对于扩展稳定版共享发布，需要从候选者拥有的 release-ci/* 工具在 Q=C 时完成完整的确切目标完整发布验证，并配备受信任的 P 准入和发布工具。直接的规范分支或 main 生产者不满足受保护发布者的要求。包验收是一个发布后选择器冒烟测试：
gh workflow run package-acceptance.yml \
--repo openclaw/openclaw \
--ref main \
-f workflow_ref=main \
-f source=npm \
-f package_spec=openclaw@extended-stable \
-f suite_profile=package \
-f telegram_mode=mock-openai
记录解析的版本。仍然验证标签的 all-publishable 清单中的每个包和选择器；一次冒烟测试不能代替注册表回读。
插件 npm 制品资格认证
对于发布候选者，完整的发布验证负责插件 npm 制品的资格认证。在调度时提供其发布选择；所有组父级以仅制品模式调用 plugin-npm-release.yml，针对确切的 Release SHA，要求成功的 tarball 回读，并将不可变的聚合描述符记录在 publicationArtifacts.pluginNpm 中。发布准备和发布必须使用该确切描述符，而不是重新打包插件。
仅当需要针对常规发布候选者之外的聚焦诊断或选定插件修复时，才使用独立的受信任工作流预检：
release_sha="$(git rev-parse origin/release/2026.7.1)"
gh workflow run plugin-npm-release.yml \
--repo openclaw/openclaw \
--ref main \
-f preflight_only=true \
-f publish_scope=selected \
-f plugins=@openclaw/meta-provider \
-f ref="${release_sha}" \
-f npm_dist_tag=default
不要传递 release_publish_run_id。要求工作流成功完成 verify_plugin_npm_preflight。记录运行 URL、工作流 SHA 和源码 SHA。工作流首先创建暂存/回读制品 plugin-npm-package-source-<source-sha>-<extension-id>，其中包含 npm-pack.json、preflight-manifest.json 和 tarball。然后上传最终消费者制品 plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt>，其中包含 tarball 和 plugin-publication-manifest.json。
分别记录最终制品名称和摘要。清单使用 openclaw.plugin-publication-artifact/v1 并记录目标 SHA、包清单哈希、发布路由和策略，以及 tarball 哈希和清单。此独立验证仅用于验证；它不授权或暂存发布，也不能替代完整发布验证的清单绑定描述符。制品清单（而非解压的源码树）是安全和包内容边界：仅源码的夹具无关紧要。包拥有的测试和夹具路径如果不在运行时和技能资产之外，则无法通过资格认证；交付的运行时仍会进行安全扫描。捆绑的 node_modules 保留依赖证据而非插件源码策略。独立的 trusted_publisher_preflight=true OIDC 检查需要一个受保护的 release-publish/<tooling-sha12>-<epoch> 调度标签，并在 npm-publish 中运行。真实发布还需要该工具标签；直接的人为调度在发布前会等待其 npm-release 批准任务。
对于已发布的版本，要求 npm 的 dist.integrity 和 dist.shasum 与验证过的 tarball 匹配。仅将缺失或可证明较旧的 dist-tag 视为可修复；较新或不可比较的选择器是阻塞项。
新的 Testbox 工具计划
如果需要更多确定性，添加或运行一个 plugin-lifecycle-matrix Docker 通道，该通道使用一个包 tarball 和分片的插件列表。每个插件：
- 从全新的
HOME开始。 - 捕获
plugins list --json。 plugins install <id>。plugins inspect <id> --json。plugins disable <id>，然后断言禁用后的可见性。plugins enable <id>，但需要配置的插件在没有配置时除外。plugins registry --refresh。doctor --non-interactive。plugins uninstall <id> --force。- 断言插件的
plugins.entries值恰好是{ enabled: false }，而其允许/拒绝条目、安装记录、托管目录和捆绑运行时加载路径都已消失。对于历史目标，使用现有工具的源码限定卸载期望。 - 断言诊断输出中没有
level: "error"，并且输出会脱敏看起来像密钥的值。
memory-lancedb 特殊处理：它需要配置。首先断言安装不会在没有嵌入配置的情况下启用它，然后运行第二个配置后的用例。
诊断/修复矩阵
预先设置错误状态，并要求 doctor --fix --non-interactive 修复它们，然后再次运行 doctor 并要求幂等性：
- 过时的
plugins.allow - 过时的
plugins.entries - 针对缺失通道插件的过时通道配置
- 无效的
plugins.entries.<id>.config - 打包的捆绑路径在
plugins.load.paths中 - 遗留的
plugins.installs - 禁用的通道/插件配置，不得暂存运行时依赖
- 根拥有的全局包树，必须保持不变
网关引导矩阵
在 Docker 中以全新状态启动打包的 OpenClaw：
- 提供商插件已启用，无凭据：就绪但带有警告，不崩溃
- 通道插件配置为禁用：不暂存运行时依赖
- 启动激活的插件已启用：就绪并在状态中反映
- 无效的单个插件配置：有问题的插件被跳过/隔离，其他插件正常
断言：
- 网关达到就绪状态
openclaw status --json包含插件诊断信息openclaw plugins inspect --all --json可解析- 包树未被修改
- 日志中不包含原始令牌
配置往返代表
使用代表性插件家族而非每个插件进行深入配置往返：
- 提供商：
openai、anthropic、mistral、openrouter - 通道：
telegram、discord、slack、whatsapp - 记忆：
memory-lancedb - 特性/运行时：
browser、acpx、tokenjuice
对于每个代表：
- 尽可能通过 CLI 写入配置。
- 通过
config get或 JSON 回读配置。 - 运行
plugins inspect。 - 运行
doctor --non-interactive。 - 如果适用，触发网关配置重载。
- 比较无操作命令前后的配置哈希。
外部 SDK 冒烟测试
在包 Docker 通道中，创建小型外部插件并从以下来源安装它们：
- 本地目录
.tgzfile:npm 说明符
覆盖 CJS 和 ESM 形态，以及至少一个导入聚焦的 openclaw/plugin-sdk/* 子路径的插件。断言 plugins inspect 能看到其工具、网关方法、CLI 命令或服务。
实时探测规则
在进行实时工作之前，在 Testbox 中获取允许的环境变量并生成脱敏的可用性矩阵：仅显示存在/缺失，绝不显示值。
仅对存在的凭据运行探测。优先进行认证/目录/状态探测，而不是发送用户可见消息。如果探测可能接触外部用户、通道或工作区，请停止并询问用户。
报告
按以下格式报告：
包/引用:
tbx ID / 运行 URL:
矩阵:
捆绑生命周期:
包验收:
诊断/修复:
网关引导:
配置往返:
SDK 外部:
实时探测:
失败:
跳过:
下一个最高价值缺口:
当失败是 Testbox 同步/环境损坏而非产品行为时，要明确说明，并通过干净的重新运行或当前 main 对比来证明这一点。