Gerenciador de Lançamentos do OpenClaw

O que Gerenciador de Lançamentos do OpenClaw faz?

Use para uma operação de lançamento, não para desenvolvimento comum ou mutação consultiva. Leia docs/reference/RELEASING.md para a política atual. Carregue $release-private quando disponível antes de resolver localizadores de credenciais privadas ou topologia de host; operações de credenciais usam $one-password.

Escolha a função

• Proprietário de lançamento (padrão): "Gerenciar este lançamento" é responsável por um lançamento desde a preparação até a verificação, retrospectiva e encerramento. Comece com o ciclo de vida do proprietário, mesmo para um prompt curto.
• Gerente de lançamento / orquestrador: coordena vários proprietários de lançamento, redige seus briefings de kickoff ou handoff e roteia oportunidades de hotfix. Comece com modo gerente. Esta função não se torna um segundo escritor do branch de lançamento ou estado de publicação de um proprietário.

A skill é responsável pelo processo geral; o prompt inicial carrega a intenção, autoridade e estado específicos do lançamento, não um runbook copiado. Um handoff retoma essa intenção com evidências atuais, em vez de iniciar outro lançamento.

Escolha a operação

Leia apenas as referências necessárias para a fase selecionada:

• Preparação ou publicação regular beta/estável: lançamento regular, que roteia a preparação e a prova específica da fase. Se a solicitação não especificar estável/completo, o padrão é beta; a autorização beta não autoriza a promoção para estável posteriormente.
• Descoberta e portabilidade de backport: inventário de candidatos e briefing do trabalhador. Para extended-stable, leia também preparação de backport; alterações de SDK/config precisam de um aviso visível de risco de manutenção e decisão do mantenedor.
• Publicação de Gateway extended-stable .33+: publicação extended-stable. Use o editor compartilhado com entradas extended-stable; seu GitHub Release não-Latest carrega evidências sem publicação nativa de aplicativo ou ClawHub.
• Seleção de validação ou prova falhada: validação e confiança, com $release-openclaw-ci para execução de fluxo de trabalho e manifestos imutáveis.
• Publicação interrompida ou promoção de registro: recuperação de publicação.
• Ativos nativos: publicação de plataforma, com $release-openclaw-mac para operações macOS.
• Sincronização pós-publicação estável e handoff de implantação SHA exata: encerramento principal.
• Retrospectiva de lançamento e ledger de issues compartilhado (cada trilha e qualquer snapshot de handoff): retrospectiva.
• Notas de lançamento: $openclaw-changelog-update, incluindo sua rota separada de mirror de docs pós-lançamento aprovada. A geração inicial de lançamento mantém seu formato existente; a publicação de docs não é executada automaticamente durante o lançamento. Anúncios solicitados: $release-openclaw-announcement para Discord, $release-tweets para X. Anúncios nunca bloqueiam a publicação e exigem autorização explícita de postagem.
• Verificação de artefato publicado: $verify-release. Operações GHSA: $openclaw-ghsa-maintainer apenas com autorização explícita de fluxo de trabalho de segurança.

Gerenciamento de ledger de hotfix

Prefira o ledger de hotfix compartilhado para descoberta de backport, seleção e resultados, incluindo lançamentos de propriedade da Tideclaw. Reutilize candidatos, adicione descobertas de lançamentos main/irmãos e atualize as avaliações de cada lançamento. Se o acesso não estiver disponível, mantenha evidências locais e sincronize mais tarde. Esta é uma contabilidade recomendada, não outro gate de lançamento.

Limites compartilhados de lançamento

O FRV deve concluir como sucesso sob a política de ferramentas de lançamento verificado e fixada em P política de ferramentas de lançamento verificada. Apenas falhas exatas de provedor ativo ou folhas do Telegram podem ser dispensadas, sem pular testes ou alterar C/Q. Todas as outras faixas obrigatórias devem ser bem-sucedidas: Windows e macOS Node e outros trabalhos normais de CI, smoke de instalação, faixas sobreviventes, update-first-hop-compat*, qualificação pack/npm, integridade de pacote, e verificações de Gateway Linux/Windows/macOS, incluindo verificações de instalação/atualização do Windows empacotado em Verificações de Lançamento. Uma execução cancelada ainda bloqueia. Preserve primeiras falhas e classifique cada uma como abaixo antes da recuperação. A publicação estável requer evidência estável/completa, soak e desempenho bloqueante. A evidência de perfil beta não pode autorizar a publicação estável. Nenhum desses gates rigorosos, soak ou desempenho pode ser dispensado. Todas as nove combinações de instalação/atualização do Gateway em Linux, Windows e macOS são necessárias para a qualificação de todos os grupos. Preserve identidade, proveniência, evidências completas e aprovações de publicação existentes.

Cada teste falhado recebe uma decisão explícita do líder, bloqueador real de lançamento ou flake, registrada no handoff com sua evidência: o mesmo SHA passando em outro lugar ou em uma nova execução, sem relação com o delta do lançamento, uma assinatura de runner ou infra, um histórico do mesmo caso falhando, ou um bug de produto pré-existente que não é uma regressão (por exemplo, o bug "Atribuir a…" de 2026.9.6). Um bloqueador real é uma regressão em bytes ou comportamento enviados, ou um defeito de atualização/instalação/ publicação; corrija-o no branch de lançamento. Reexecute um flake no mesmo SHA de Lançamento com no máximo duas novas execuções registradas por padrão e registre um issue ou PR de correção em paralelo no main com a evidência. Nunca recorte para um flake. Uma dispensa deliberada de ferramenta de código requer validação FRV sob o novo P fixado, não uma substituição do editor. Um flake não dispensado que permanece vermelho bloqueia a publicação. Falhas apenas no main e falhas de infraestrutura (indisponibilidades de runner, trabalhos fantasmas do GitHub, offload de runner hospedado) contam como flakes para o lançamento.

Advertências de dependência nunca atrasam um lançamento. Uma advertência recém-publicada nunca é motivo para recortar, alterar ferramentas ou reexecutar a validação. Registre-a na evidência e handoff do lançamento e, em seguida, registre ou enfileire o bump de dependência no main como um acompanhamento normal após a publicação. Apenas uma descoberta de malware conhecido interrompe a publicação. As evidências de dependência do lançamento e a CI despachada pelo lançamento impõem isso.

A saúde da CI do main nunca bloqueia um lançamento. A validação e a publicação são executadas a partir do branch de lançamento mais ferramentas fixadas, portanto, um main vermelho não é motivo para esperar, recortar ou pausar. Quando o lançamento precisa de uma correção de ferramentas de lançamento no main (os SHAs das ferramentas devem ser commits main confiáveis), falhas do main que a correção não causa não devem impedir esse pouso: prove em um checkout limpo do main que a falha já existe lá, registre-a no corpo do PR e mescle. Durante um lançamento ativo, uma mesclagem administrativa é permitida para um PR de ferramentas de lançamento exatamente nessa situação. O main vermelho ainda é corrigido, em paralelo por uma faixa separada, nunca no caminho crítico do lançamento.

Siga o loop de tempo de parede do FRV: inicie a validação remota prontamente, repare falhas conforme os diagnósticos são drenados e minimize o tempo de inatividade entre os ciclos. Inclua cada correção conhecida não-flake que afete a próxima execução em vez de carregar conscientemente falhas adiante; sobreponha verificações locais úteis com validação remota. Isso orienta o agendamento, não novos gates.

Os objetivos operacionais são aproximadamente 20 minutos para selar a validação e a publicação dentro de uma hora, não garantias medidas. Filhos apenas de origem começam ao lado dos produtores de artefatos; consumidores candidatos começam assim que o candidato estiver pronto. Filhos verdes selados de forma independente podem ser reutilizados para o mesmo alvo exato e entradas, mesmo quando seu pai falhou, foi cancelado ou permanece ativo; verifique sua identidade de qualificação admitida original (ou SHA de fluxo de trabalho principal confiável histórico) e a tentativa atual. O manifesto selado fornece o resumo de evidências do SDK e as decisões de publicação do npm; ele nunca reconhece alterações na API do SDK, portanto, forneça plugin_sdk_api_acknowledgement sempre que o relatório do SDK contiver alterações. O editor aceita apenas FRV bem-sucedido e não pode conceder uma dispensa. Entradas explícitas do editor selecionam o escopo da publicação; o auxiliar candidato ainda valida seu reconhecimento explícito do SDK quando necessário.

Use os padrões de autoridade do ciclo de vida do proprietário para solicitações de gerenciamento de lançamento: beta inclui publicação validada, a menos que retida; estável e extended-stable exigem aprovação de publicação. Uma solicitação explícita apenas de preparação nunca autoriza a publicação. Uma instrução explícita para publicar ou concluir um lançamento nomeado acarreta sua publicação e verificação validadas; não pergunte novamente a menos que a identidade, canal, escopo ou risco material mudem. Resolva e registre a versão antes de alterá-la; versões não especificadas seguem a regra de aprovação do ciclo de vida. Autoridade de envio para código comum não é autoridade de lançamento.

A aprovação explícita de um operador para fazer o que for necessário para preparar um lançamento nomeado é autoridade permanente para as decisões e reparos de preparação necessários. Carregue-a até correções de candidatos e ferramentas, design de atualização/migração, alinhamentos de teste ou inventário de segurança revisados, prova isolada, commits, pushes e recuperação de validação. Registre a decisão, sua evidência e o contrato de suporte selecionado; não pergunte novamente apenas porque uma classe de trabalho já aprovada atinge uma etapa de implementação ou verificação. Continue o trabalho independente enquanto resolve um bloqueador. Esta autoridade não permite ocultar defeitos, reduzir um gate para fabricar sucesso, alterações destrutivas no estado do operador, trabalho não relacionado ou publicação. Uma solicitação apenas de preparação ainda requer uma instrução de publicação separada antes de liberar artefatos ou uma versão de ponte.

Mantenha um registro de estado compacto usando o template de handoff: meta efetiva, versão/tag/branch, SHAs de corte/Código/Lançamento, identidades C/Q/P, execução principal ativa e tentativa, artefatos filhos bem-sucedidos, alterações aprovadas, fase e próxima ação. O direcionamento mais recente do operador substitui o escopo substituído. As evidências concluídas permanecem completas até que uma alteração nomeada as invalide.

Para lançamentos regulares, prepare notas completas antes de congelar o SHA de Código quando possível. Se essas notas forem finais, SHA de Código e SHA de Lançamento são o mesmo commit: uma qualificação completa nova e bem-sucedida pode fornecer ambas as funções e seus bytes de publicação exatos. Não crie outro commit ou execute apenas para separar os rótulos. Se as notas mudarem após a qualificação, um descendente cujo delta completo inclui CHANGELOG/<version>.md (versão beta exata ou base estável) e apenas essa entrada, seu registro correspondente e índice raiz pode usar split-changelog-release-v1 para reutilizar a prova do produto enquanto qualifica novos bytes de publicação. Qualquer outro delta de origem, renomeação ou exclusão retorna ao loop do SHA de Código. Histórico recibos apenas de raiz retêm changelog-only-release-v1. Nova qualificação de teste congela Q=C: o fechamento do fluxo de trabalho de teste do candidato pertence ao candidato. Mantenha P independente e confiável (admissão, decisão agregada, verificador e editor) separado. Um reparo de harness Q requer um novo C/Q e evidência recém-ligada; reparos apenas de P ou infraestrutura podem preservar o candidato. Contratos de qualificação ausentes precisam de um backport deliberado, nunca de fallback para main futuro.

Assim que um candidato é cortado, sua base é a decisão do operador. Nunca recorte (re-baseie o candidato em main mais recente) a menos que Peter peça explicitamente por isso naquele lançamento. Sem perguntar, cherry-pick commits já mesclados do main no branch de lançamento apenas para corrigir um bloqueador de lançamento confirmado: uma faixa obrigatória falhando deterministicamente no candidato congelado, ou um defeito de atualização/instalação/ bytes de publicação. Nomeie cada cherry-pick no registro de handoff. Não permitido: backports oportunistas, reversões de recursos ou uma nova base obtida para "pegar" uma correção que cherry-pick limpa o suficiente com uma pequena resolução de conflito. Adições explícitas aprovadas pelo operador seguem o procedimento de admissão do proprietário: registre o escopo alterado e requalifique o novo candidato, nunca reutilize silenciosamente prova invalidada. A notificação de oportunidade de um gerente não é essa aprovação.

Melhorias no processo de lançamento feitas durante um lançamento são aplicadas em ambos os branches. As alterações de fluxo de trabalho, script de lançamento, teste de lançamento, RELEASING.md e skill de lançamento mesclam no main primeiro e, em seguida, são cherry-pick (-x) para release/YYYY.M.PATCH para o próximo candidato ou patch. Um reparo de qualificação necessário para este lançamento deve ser aplicado antes de congelar um novo C/Q; nunca troque silenciosamente o harness por um candidato já qualificado. Onde a infraestrutura de CI apenas do main está faltando no branch, mantenha a forma de expressão do branch e porte apenas a lógica. O código do produto no branch de lançamento permanece apenas bloqueador de acordo com a regra acima.

Resolva cada PR de reparo aberto para o lançamento antes do relatório final. O PR de retrospectiva descrito abaixo é o entregável de encerramento aberto necessário, não um reparo não resolvido. Liste cada PR criado durante o lançamento (gh pr list --author @me --state open mais qualquer PR vinculado a th...