Teste de Pré-Lançamento de Plugins OpenClaw

O que Teste de Pré-Lançamento de Plugins OpenClaw faz?

Use este skill quando o usuário solicitar confiança na liberação de plugins, varreduras de ciclo de vida de plugins, prova de artefatos de pacote ou "o que mais devemos testar antes do lançamento?". Ele complementa openclaw-testing; use também esse skill ao escolher o runner mais barato e seguro ou ao depurar uma pista com falha.

Objetivo

Provar o sistema de plugins como uma superfície de produto, não apenas como testes de código-fonte:

• ciclo de vida de plugins agrupados: instalar, inspecionar, ativar, desativar, desinstalar
• comportamento do artefato de pacote a partir de um HOME limpo
• validação e idempotência de doctor/fix/config
• descoberta de configuração e ida e volta de configuração
• visibilidade de status/log e diagnósticos
• inicialização/bootstrap do gateway com snapshots de metadados de plugins
• compatibilidade pública do SDK para plugins externos reais
• sondagens de provedor/canal ativas (live-ish) somente quando credenciais seguras existirem

Primeiras Verificações

A partir da raiz do repositório OpenClaw:

pnpm docs:list
git status --short --branch
readlink node_modules
pnpm changed:lanes --json

Em worktrees do Codex sob .codex/worktrees, node_modules deve ser um link simbólico para o checkout principal do OpenClaw. Não execute pnpm install lá. Para prova ampla ou com muitos pacotes, use Blacksmith Testbox ou GitHub Actions.

Escolha do Runner

Prefira esta ordem:

1. GitHub Package Acceptance para prova de produto com pacote instalável.
2. ci-build-artifacts-testbox.yml Testbox quando pistas Docker/de pacotes precisarem de dist, dist-runtime e caches de pacote semeados.
3. ci-check-testbox.yml Testbox para verificações de código-fonte, Vitest direcionado, verificações de limite de pacote ou pistas Docker focadas.
4. Comandos locais direcionados apenas para pequenas sondagens de formato/estático/unidade.

Evite execuções longas de Docker de pacote a partir de uma worktree esparsa desatualizada. Se a sincronização do Testbox relatar centenas de arquivos alterados ou começar a excluir entradas de pacote, pare e prepare uma nova box a partir do main atual, ou mude para Package Acceptance.

Linha de Base Existente

Execute ou verifique estes antes de inventar nova cobertura:

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
pnpm test:docker:bundled-channel-deps:fast

Para prova completa de instalação/desinstalação agrupada, fragmente a varredura do pacote:

OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall

Escopo atual esperado do pacote: 116 plugins agrupados públicos nos fragmentos 0-7. Plugins QA privados são apenas modo código-fonte, a menos que um pacote os inclua explicitamente.

Matriz de Confiança

Use esta matriz para aprovação de pré-lançamento. Registre pass/fail, URL do run/ID do Testbox, SHA/versão do pacote e motivo de live-ish ignorada.

Superfície	Prova	Runner preferido
Artefato de pacote	Package Acceptance suite_profile=package ou pistas personalizadas	GitHub Actions
Ciclo de vida agrupado	8 fragmentos test:docker:bundled-plugin-install-uninstall	Testbox ou Docker de release
Plugins externos	test:docker:plugins e plugins-offline	Testbox/package acceptance
Atualização no-op	test:docker:plugin-update	Testbox/package acceptance
Dependências de runtime de canal	test:docker:bundled-channel-deps:fast mais canais-chave	Testbox/package acceptance
Doctor/fix	configurações ruins semeadas + doctor --fix --non-interactive	novo harness Docker/Testbox
Ida e volta de configuração	config set/get, inspecionar, doctor, recarregar, hash diff	novo harness Docker/Testbox
Bootstrap do gateway	HOME limpo, grupos de plugins ativados/desativados, JSON de status	novo harness Docker/Testbox
Compatibilidade SDK	plugins externos de diretório, tgz e file: usando subcaminhos do SDK	test:docker:plugins mais nova fumaça
Live-ish	sondagens de provedor/canal editadas apenas para env presente	pistas live do Testbox

Plano de Aceitação de Pacote

Use isto ao validar uma branch de release, beta ou pacote candidato:

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branch-or-sha> \
  -f suite_profile=custom \
  -f docker_lanes='plugins-offline plugin-update bundled-channel-deps-compat doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
  -f telegram_mode=mock-openai

Use source=npm -f package_spec=openclaw@beta para prova de beta publicado. Mantenha workflow_ref como o código de harness atual confiável, a menos que o processo de release diga o contrário.

Plano de Novo Harness Testbox

Se for necessária mais certeza, adicione ou execute uma pista Docker plugin-lifecycle-matrix que use um tarball de pacote e listas de plugins fragmentadas. Por plugin:

1. Comece com um HOME limpo.
2. Capture plugins list --json.
3. plugins install <id>.
4. plugins inspect <id> --json.
5. plugins disable <id>, então afirme visibilidade desativada.
6. plugins enable <id>, exceto plugins que exigem configuração sem ela.
7. plugins registry --refresh.
8. doctor --non-interactive.
9. plugins uninstall <id> --force.
10. Afirme que nenhuma entrada de configuração, resíduo de allow/deny, registro de instalação, diretório gerenciado ou caminho de carga dist/extensions/... agrupado permanece.
11. Afirme que os diagnósticos não contêm level: "error" e a saída oculta valores com aparência de segredo.

Mantenha memory-lancedb especial: ele requer configuração. Primeiro, afirme que a instalação não o ativa sem configuração incorporada, depois execute um segundo caso configurado.

Matriz Doctor/Fix

Semeie estados ruins e exija que doctor --fix --non-interactive os repare, depois execute doctor novamente e exija idempotência:

• plugins.allow desatualizado
• plugins.entries desatualizado
• configuração de canal desatualizada para plugin de canal ausente
• plugins.entries.<id>.config inválido
• caminho agrupado no pacote em plugins.load.paths
• plugins.installs legado
• configuração de canal/plugin desativado que não deve preparar dependências de runtime
• árvore de pacote global de propriedade do root que deve permanecer inalterada

Matriz de Bootstrap do Gateway

Inicie o OpenClaw empacotado no Docker com estado limpo:

• plugins de provedor ativados, sem credenciais: pronto com avisos, sem crash
• plugins de canal configurados como desativados: sem dependências de runtime preparadas
• plugins de ativação na inicialização ativados: pronto e refletido no status
• configuração de plugin único inválida: plugin ruim ignorado/quarentenado, outros permanecem

Afirme:

• gateway atinge o estado pronto
• openclaw status --json inclui diagnósticos de plugins
• openclaw plugins inspect --all --json é analisável
• árvore de pacote não é mutada
• logs não contêm tokens brutos

Representantes de Ida e Volta de Configuração

Use famílias de plugins representativas em vez de todos os plugins para ida e volta profunda de configuração:

• provedores: openai, anthropic, mistral, openrouter
• canais: telegram, discord, slack, whatsapp
• memória: memory-lancedb
• recurso/runtime: browser, acpx, tokenjuice

Para cada representante:

1. Escreva a configuração via CLI quando possível.
2. Leia-a de volta através de config get ou JSON.
3. Execute plugins inspect.
4. Execute doctor --non-interactive.
5. Acione o recarregamento de configuração do gateway, se aplicável.
6. Compare o hash de configuração antes/depois de comandos no-op.

Fumaça de SDK Externo

Em uma pista Docker de pacote, crie plugins externos minúsculos e instale-os a partir de:

• diretório local
• .tgz
• especificação npm file:

Cubra formas CJS e ESM, além de pelo menos um plugin importando subcaminhos focados de openclaw/plugin-sdk/*. Afirme que plugins inspect vê sua ferramenta, método de gateway, comando CLI ou serviço.

Regras de Sondagem Live-ish

Antes de trabalho live-ish, obtenha env permitido no Testbox e gere uma matriz de disponibilidade editada: presente/ausente apenas, nunca valores.

Execute apenas sondagens para credenciais que existem. Prefira sondagens de auth/catálogo/status em vez de enviar mensagens visíveis ao usuário. Se uma sonda puder contatar um usuário externo, canal ou espaço de trabalho, pare e pergunte ao usuário.

Relatório

Relate neste formato:

package/ref:
tbx ids / run urls:
matrix:
  bundled lifecycle:
  package acceptance:
  doctor/fix:
  gateway bootstrap:
  config round-trip:
  sdk external:
  live-ish:
failures:
skips:
next highest-value gap:

Diga claramente quando uma falha é dano de sincronização/ambiente do Testbox em vez de comportamento do produto, e prove isso com uma reexecução limpa ou comparação com o main atual.