verificar-lançamento

Verificar Lançamento

Use esta skill quando for perguntado se um lançamento do OpenClaw está totalmente publicado, promovido, testado por fumaça ou verificado ao vivo. Esta é uma skill de verificação, não de publicação; use $release-openclaw-maintainer antes de alterar o estado do lançamento.

Regras

• Resolva sufixos curtos como .27 para a versão CalVer concreta a partir da data/contexto atual e informe a versão resolvida.
• Resolva a trilha primeiro. Ambas as trilhas usam o ledger compartilhado de evidências de Release do GitHub. A trilha regular beta/stable também usa o gráfico da plataforma; a trilha extended-stable usa seu branch canônico, seletor npm e superfícies do Gateway. Não exija artefatos nativos ou do ClawHub de uma trilha na outra.
• Verifique o estado ativo. Não confie no estado do checkout local, notas de lançamento ou memória antiga como verdade atual.
• Se o checkout estiver sujo ou divergente, use-o apenas para scripts/referência. Para metadados de versão, busque da release/tag do GitHub ou descompacte o tarball da tag em /tmp.
• Nunca imprima segredos.
• Mantenha a saída final concisa: sim/não, marcadores de evidência, ressalvas, limpeza.

Verificações regulares beta/stable

Use estas verificações apenas para a trilha de lançamento orquestrada regular.

1. Release do GitHub:
   • gh release view v<VERSÃO> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • Confirme que lançamentos stable não são rascunho ou pré-lançamento.
   • Confirme que o corpo da release tem links de evidência do npm, CI, npm de plugins, ClawHub, mac/appcast quando esperado.
   • Confirme que os ativos esperados para lançamentos stable no Mac foram enviados: zip, dmg, dSYM, evidência de dependências, manifesto de validação completa imutável, evidência pós-publicação e manifesto de encerramento stable-main.
   • Baixe cada ativo de evidência imutável e seu companheiro .sha256, então verifique a soma de verificação antes de confiar no registro da release.
2. npm raiz:
   • npm view openclaw@<VERSÃO> version dist-tags.latest dist.tarball dist.integrity time.<VERSÃO> --json
   • latest deve ser igual a <VERSÃO> para stable.
   • Registre tarball, integridade, hora de publicação.
   • Confirme que a evidência pós-publicação da release registra npmRegistrySignaturesVerified: true e npmProvenanceAttestationMatched: true.
3. Conjunto de publicação de plugins:
   • Obtenha os metadados exatos da tag do GitHub, não do checkout local quando sujo: baixe https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSÃO> em /tmp/openclaw-v<VERSÃO>-src.
   • Derive o conjunto completo esperado de pacotes npm e ClawHub para a trilha de lançamento com os planejadores/coletor canônicos de publicação a partir do SHA da ferramenta registrado na release, usando os metadados exatos do pacote da tag. Não conte flags de publicação brutas: openclaw.build.bundledDist === true adia explicitamente a publicação externa mesmo quando as flags de publicação estão definidas. Registre nomes de pacotes adiados e motivos separadamente.
   • Reconcilie identidades, versões e contagens esperadas de pacotes entre a publicação original, versões previamente publicadas e execuções de recuperação selecionadas usando planos de publicação imutáveis, leitura de registro e jobs do workflow. Um subconjunto de recuperação selecionado não deve reduzir o conjunto completo esperado do lançamento: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
   • Para cada plugin npm esperado, verifique a versão planejada e o seletor npm a partir do plano de publicação imutável. Uma beta regular publica em beta; não exija que ela mova latest. Verifique quaisquer tags de espelho planejadas separadamente.
4. ClawHub:
   • Verifique a conclusão do workflow de Release do Plugin ClawHub e a contagem de jobs de publicação.
   • Use o próprio OpenClaw para prova de registro ao vivo: openclaw plugins search <plugin-conhecido> --json.
   • Instale um plugin oficial na versão de release exata solicitada a partir do ClawHub em um HOME isolado: openclaw plugins install clawhub:@openclaw/matrix@<VERSÃO>. Prefira matrix a menos que esse plugin não esteja no conjunto esperado. As versões do ClawHub pertencem à especificação; --pin é suportado apenas para instalações npm.
5. Workflows de release:
   • Verifique as conclusões e links de evidência nas notas de release: Validação Completa da Release, Verificações de Release do OpenClaw, Release NPM do OpenClaw, Release NPM de Plugin, Release ClawHub de Plugin, pré-verificação/validação/publicação do Mac quando ativos stable do Mac são esperados.
   • Para stable, verifique se OpenClaw Stable Main Closeout foi bem-sucedido e seu manifesto registra a tag de release correspondente, exercício de reversão atual, soak stable e evidências de desempenho bloqueantes.
   • Resuma apenas jobs bem-sucedidos/falhos relevantes; ignore lanes opcionais rotineiramente ignoradas, a menos que o corpo da release as tenha prometido.

Verificações extended-stable

Extended-stable tem uma Release do GitHub com evidência de release compartilhada, mas sem artefatos nativos ou do ClawHub. Verifique-a juntamente com a tag ativa, workflow, registro, proveniência e estado da imagem.

1. Identidade: exija a v<VERSÃO> final no patch 33+, sem sufixo, contida em extended-stable/YYYY.M.33. Apenas um candidato ativo deve ser igual à ponta. A raiz e cada plugin oficial publicável devem declarar <VERSÃO>. Exija a tag Git e uma Release do GitHub pública e não pré-lançamento cujo título e corpo canônico correspondam à tag. Exija isLatest=false, a evidência de dependências, o manifesto imutável de Validação Completa da Release, evidência pós-publicação e suas somas de verificação. Exija nenhum ativo nativo ou do ClawHub.
2. Cadeia de workflow: encontre a execução pai de release bem-sucedida, mais seus filhos de pré-verificação, validação completa, npm de plugin e publicação do núcleo. Exija um pai protegido release-publish/* e um produtor de validação canônico release-ci/* com proveniência verificada de SHA do workflow. A validação deve usar rerun_group=all, release_profile=stable, soak/desempenho bloqueantes e a tentativa salva. A publicação do núcleo deve referenciar todos os três IDs de execução e vincular seu manifesto, ref do workflow e digest do tarball ao SHA da release.
3. Registro: exija que os seletores exato e extended-stable retornem <VERSÃO> para a raiz, cada entrada corePackageTarballs da pré-verificação e cada plugin oficial publishToNpm === true derivado da tag. Compare o plano de plugin, jobs e leitura completa; nunca infira inventário a partir de diffs.
4. Proveniência: a partir da ferramenta atual confiável, execute node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSÃO>. Exija assinaturas, proveniência de branch canônico e vinculação do digest de publicação/pré-verificação ao SHA da release. Preserve a saída e URLs do workflow.
5. Docker: verifique as imagens exatas default, slim, browser e architecture e suas atestações em ambos os registros. Apenas os três aliases extended-stable* podem resolver para esses digests. Exija a execução pai OpenClaw Release Publish bem-sucedida e sua verificação Docker concluída. A rota normal finaliza depois; um caminho rápido explicitamente solicitado pode ativar o GitHub primeiro. Repare aliases através de Docker Channel Promotion do main atual para a tag exata, sem reconstruir.
6. Recuperação: nunca republique. Use promote_extended_stable no workflow de dist-tag openclaw/releases para o seletor raiz (um patch final 33+ sem sufixo) e ferramentas aprovadas de credenciais isoladas para outros, então repita a leitura completa. Não exija ClawHub, aplicativos nativos/mobile, site, dist-tags privadas ou latest regular. Exija evidência de release compartilhada, mas não exija ativos nativos ou do ClawHub regulares.

Fumaça de pacote publicado

Após as verificações de publicação específicas da trilha passarem, use uma instalação/cache descartável com estado isolado do OpenClaw:

• npm exec --yes --package openclaw@<VERSÃO> -- openclaw --version.
• Execute pelo menos um comando inofensivo que toque na superfície CLI publicada, por exemplo plugins --help ou gateway --help.

Não inicie um Gateway local extra nem execute uma interação de modelo ao vivo ad hoc como verificação preliminar de release. Use os workflows canônicos de validação de release e evidências de publicação acima; isso não remove nenhuma de suas lanes obrigatórias. Execute verificações manuais ao vivo adicionais apenas quando explicitamente solicitado.

Ressalvas a Relatar

• Ressalva de dist-tag: stable latest é a verdade da release; se beta opcional ainda apontar para uma versão beta, relate como ressalva, não como bloqueador de release stable, a menos que o usuário tenha pedido para verificar a promoção beta.
• Ressalva de trilha: nomeie a trilha e as superfícies intencionalmente ausentes. Não considere artefatos ausentes de release regular como uma falha de extended-stable.
• Ressalva de checkout divergente: informe quando o SHA da fonte local difere da tag de release ou origin e quais fontes ativas foram usadas em vez disso.