release-openclaw-ci

CI de Lançamento do OpenClaw

Use esta skill com $release-openclaw-maintainer e $openclaw-testing quando um candidato a lançamento precisar de validação completa, prova de instalação/atualização, verificações de provedores ativos ou recuperação de CI.

Salvaguardas

• Sem incremento de versão, tag, publicação npm, lançamento no GitHub ou promoção de lançamento sem aprovação explícita do operador.
• Após compactação, retomada ou novo direcionamento, reescreva o objetivo efetivo e a fase atual a partir da instrução explícita mais recente do operador. Não mescle escopo antigo de volta ao lançamento ativo.
• Mantenha o escopo do lançamento assim que uma branch de lançamento ou SHA de Código existir. Valide e entregue exatamente esse lançamento; não transforme main em movimento em uma segunda fila de trabalho.
• Registre C (candidato), Q (qualificação de teste), P (admissão/agregação/verificador/publicador), grupo de reexecução, perfil, soak efetivo e referências de contexto/transporte. A qualificação de teste de novo candidato padrão é Q=C, incluindo o fluxo de trabalho completo, fluxo de trabalho reutilizável, ação local, script, planejador, contrato e fechamento de cobertura. SHA de Código e SHA de Lançamento permanecem papéis de ciclo de vida, não identidades extras de fluxo de trabalho.
• O auxiliar de candidato aceita uma tag de lançamento ausente ou uma tag leve ou anotada existente que resolva para o SHA candidato exato. Uma tag conflitante ou falha na consulta remota interrompe a validação; nunca mova uma tag para recuperar.
• Congele C/Q e selecione independentemente P confiável em main ou em uma tag de publicação protegida. C/Q não precisa ser ancestral de P. Contratos de candidato ausentes exigem um backport deliberado; nunca substitua silenciosamente por ferramentas mais novas de main.
• Aplique uma barreira de incêndio de lançamento após o SHA de Código ser congelado. Admita apenas defeitos de produto confirmados, bytes de pacote incorretos ou não verificáveis, defeitos de segurança ou falhas que tornem a publicação impossível. Enfileire outras descobertas para confiança pós-publicação ou para o próximo beta. Advertências de dependência nunca são admissões de barreira de incêndio: registre-as como evidência de lançamento e enfileire o incremento em main após a publicação; apenas malware conhecido interrompe a publicação.
• Filhos de CI congelados usam o planejador de shards Node de Q e custos medidos, enquanto descobrem e executam testes a partir do checkout do candidato. Planos de lançamento completo hospedados dividem linhas medidas acima de 12 minutos; preserve cobertura de arquivo, limites de worker e gerações de tempo completas. Um proprietário indivisível acima do orçamento deve ser dividido em vez de aumentar o orçamento de lançamento. Após o filho ser concluído, o encerramento executa scripts/ci-shard-timings-refresh.mts para essa execução exata e commita os custos gerados; não edite medições manualmente.
• Testes candidatos executam seu próprio fechamento Q congelado; P admitido possui a decisão agregada de FRV e a política de waiver verificada. Verificações apenas em main e cenários de main futuro não são requisitos implícitos de lançamento. Corrigir um harness de qualificação congelado significa um novo C/Q, com novas evidências vinculadas. Um reparo apenas de P (admissão/agregação/verificador/publicador) pode manter C/Q e suas evidências originais.
• Tags leves protegidas release-publish/<12sha>-<provenance-run> identificam P, não Q. O sufixo registra a proveniência da criação da tag, não o pai atual. Auxiliares de publicação mantêm seu argumento --workflow-sha <P>; o argumento --workflow-sha do auxiliar FRV em vez disso seleciona Q e deve ser igual a C na rota candidata.
• Toque em main apenas para uma alteração solicitada pelo operador ou o menor bloqueador crítico pertencente à main que impede este lançamento e não pode ser tratado a partir da branch de lançamento. A saúde do CI de main nunca bloqueia um lançamento. Se um pouso de ferramentas de lançamento for bloqueado por falhas de main que não causou, prove em um checkout limpo de 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 esse caso exato. Uma faixa separada corrige main vermelha em paralelo, fora do caminho crítico do lançamento.
• Aterre correções apenas de ferramentas em main com o rótulo release-fast-lane adicionado antes do push (consulte Faixa rápida de ferramentas de lançamento): openclaw/ci-gate então executa lint, tipos, guardas, dependências, docs e as linhas Node alteradas apenas. Aterre através do fluxo de trabalho nativo de mantenedor. Esse fluxo de trabalho possui requisitos de revisão e pouso, incluindo a política de aviso ClawSweeper; o rótulo muda apenas a seleção de CI.
• OPENCLAW_RELEASE_RUNNER_GROUP opcionalmente roteia pais e workers de validação e o pai do Release Publish mais seus filhos de publicação para capacidade reservada com rótulos inalterados; jobs de publicação e aprovação credenciados permanecem em rótulos padrão hospedados pelo GitHub. Configure runners elegíveis e acesso ao repositório primeiro; não definido preserva o roteamento comum. Workers compartilhados herdam o grupo do chamador; CI de PR/main e trabalho agendado não relacionado permanece fora dele.
• Verifique o pai noturno para o SHA de Código antes de despachar uma nova validação de main; ele sela recibos por filho que despachos de destino exato adotam quando as entradas correspondem. O noturno executa esta rota auxiliar explícita de main confiável (--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main), portanto seu pai é executado em uma branch release-ci/<sha12>-<id>, não em main.
• FRV deve concluir com sucesso sob a política de waiver verificada de P fixado; todas as outras faixas necessárias devem passar. Consulte Requisitos de publicação. Tags estáveis exigem evidência estável/completa, soak e desempenho bloqueador. Evidência de perfil beta não pode qualificar estável. Soak e desempenho não podem ser dispensados. A qualificação de todos os grupos requer todas as nove combinações de instalação/atualização do Gateway Linux/Windows/macOS. Preserve primeiras falhas, identidade e evidência completa.
• A publicação nativa em macOS, Windows, Linux e Android é independente da finalização npm/ClawHub, GitHub e encerramento de main. Cada plataforma mantém seus próprios requisitos de assinatura, qualificação, artefato e atualizador; relate plataformas pendentes com precisão e repare falhas apenas nativas em paralelo.
• Não defina segredos do GitHub a partir de candidatos não validados do 1Password. Se um candidato retornar 401/403, deixe o segredo existente intacto e relate o provedor ausente exato.
• Use $one-password para leituras/gravações de segredos: uma sessão persistente do tmux, itens direcionados apenas, sem saída de segredos.
• Observe uma execução pai com pnpm frv watch --run <pai> (consulte Observar). Evite loops amplos de gh run view; a cota REST é fácil de queimar.
• Busque logs apenas para jobs com falha ou atualmente bloqueando. Se a cota estiver baixa, pare de consultar e aguarde a reinicialização.
• Trate flutuações de provedores ativos separadamente de falhas de código: prove validade da chave, status HTTP do provedor, evidência de nova tentativa e faixa exata com falha antes de editar código.
• Ao diagnosticar uma falha de provedor ativo, uma resposta de lista de modelos prova autenticação, não direito de faturamento ou inferência. Confirme a credencial com uma sonda de conclusão real antes de tratá-la como válida. Corrija a credencial primeiro; não adicione um caminho de autenticação alternativo meramente para contornar uma credencial de lançamento com falha.
• A Validação Completa de Lançamento separa o despacho de filho exato, a Decisão de Lançamento e a Drenagem de Diagnóstico. Com fail_fast=false, ela faz zero chamadas de cancelamento de filho; a Drenagem de Diagnóstico segue cada filho selecionado até o terminal, a menos que o próprio coletor seja cancelado ou perca o acesso à API do GitHub. Com fail_fast=true, a Decisão de Lançamento pode cancelar apenas o filho exato ainda ativo que possui uma falha bloqueadora.
• A continuação do mesmo pai requer que a raiz original tenha sido despachada com fail_fast=false. O controlador verifica essa entrada exata registrada antes de qualquer mutação de reexecução.
• Um pai que produziu seus próprios artefatos candidatos selados não pode ser continuado: as reexecuções do GitHub tornam esses artefatos de tentativa anterior indisponíveis. Mantenha os SHAs de candidato e qualificação congelados, substitua esse pai e inicie uma nova Validação Completa de Lançamento de todos os grupos.
• Após o despacho, um artefato de plano de execução imutável registra a tentativa original do pai, tuplas e títulos exatos dos filhos, cobertura selecionada, portões e identidade de reutilização. Os mesmos bytes são salvos sob uma chave de cache de ID de execução exata. Decisão, Drenagem, escrita de manifesto, validação de evidência e verificação final consomem o artefato para sua tentativa atual. Uma nova tentativa do coletor restaura o plano em cache, valida-o, reenvia seu artefato e adota os mesmos filhos; estado de plano ausente é uma falha de orquestração, não permissão para reconstruir o plano ou redespachar.
• Evidência reutilizada não é confiável apenas porque a selagem do plano a encontrou. A Decisão de Lançamento repete o SHA de destino selado, SHA de evidência, política, caminhos alterados, execução selecionada, execução raiz, manifesto de origem, identidade de ferramenta confiável e verificações de filho exato antes de retornar passed.
• Retentativas de pai selecionam os artefatos mais novos de Decisão e Drenagem independentemente; ambos devem vincular o mesmo plano imutável mesmo quando suas tentativas de origem diferem.
• Retentativas de filho fazem parte do mesmo plano imutável apenas quando o ID de execução do filho, caminho do fluxo de trabalho, ref, SHA Q, título de despacho, evento, alvo, candidato e entradas de validação permanecem exatos. Tentativas de filho mais novas substituem jobs correspondentes; jobs ausentes de uma tentativa mais nova são transportados. Uma identidade de job duplicada, tentativa ausente, tentativa regredida ou tupla alterada falha fechada. frv status e continue permitem até 60 segundos de reconciliação somente leitura quando o GitHub retorna temporariamente jobs duplicados na tentativa de retentativa mais nova. A tupla de execução e a tentativa permanecem fixadas; duplicatas persistentes e conflitos de tentativa mais antiga permanecem erros.
• Use pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verify para recuperação ciente de tentativas. O controlador não tem estado: o plano de execução imutável, tentativas exatas de execução do GitHub, Drenagem de Diagnóstico e manifesto final são as únicas autoridades. Ele nunca escreve uma tag, pacote, entrada de registro, candidato a lançamento ou publicação.
• A prova de controlador pós-mesclagem deve usar o SHA aterrado revisado em main protegido através do FRV Proof Broker e FRV Proof Fixture não relacionados a lançamento. Despache o broker com o número do pull request mesclado e o commit aterrado exato. O broker deve exigir que o commit de mesclagem desse pull request corresponda ao commit aterrado, provar que o commit aterrado é idêntico ou ancestral do seu SHA de fluxo de trabalho confiável e repetir as verificações de autoridade, mesclagem e ancestralidade imediatamente antes de reexecutar a fixture. Exija que a execução exata da fixture de no-op fixo progrida de sua falha intencional da tentativa um para uma aprovação da tentativa dois. O broker deve emitir seu recibo sem criar um candidato a lançamento, artefato de lançamento, publicação, ref de repositório, pai substituto ou outra mutação de fluxo de trabalho. Esta é a prova de reexecução de job direcionado hospedada no GitHub; testes focados do controlador possuem elegibilidade de plano imutável, preservação de tentativa verde, coleta do mesmo pai e invocação do verificador estrito. Nunca use uma execução real de Validação Completa de Lançamento para esta prova. Consulte Validação Completa de Lançamento.
• Use um operador de lançamento, um frv watch e no máximo um investigador para a superfície de falha atual. Não construa árvores de plano de auditoria-revisão em torno de uma única transição de fluxo de trabalho.
• Para lançamentos beta/estáveis regulares, o SHA de Código pode já conter notas finais e servir como SHA de Lançamento. Um pai completo fresco bem-sucedido pode qualificar ambos os papéis e seus bytes de publicação exatos. Se as notas mudarem depois, um SHA de Lançamento posterior pode reutilizar evidência de produto apenas quando seu delta completo do SHA de Código alterar o CHANGELOG/YYYY.M.PATCH.md selecionado e opcionalmente CHANGELOG.md e CHANGELOG/records/YYYY.M.PATCH.md, sem outros caminhos, renomeações ou exclusões; seus bytes alterados ainda precisam de qualificação.
• Estável estendido valida uma ponta de branch exata; ele não reutiliza o modelo de evidência SHA de Código/SHA de Lançamento regular.
• Em uma árvore de trabalho esparsa ou sincronização de fonte Testbox, primeiro confirme package.json, pnpm-lock.yaml e cada caminho de fonte que a verificação selecionada lê. Se algum estiver ausente, esse checkout não pode validar uma dependência de lançamento ou faixa Docker: pare e use o portão alterado remoto do repositório ou uma árvore de trabalho de tarefa completa. Quando as entradas estão presentes e uma correção de lançamento altera package.json ou pnpm-lock.yaml, reconstrua apenas a caixa descartável de propriedade da tarefa com CI=true pnpm install --frozen-lockfile, em seguida, execute uma sonda require.resolve() explícita antes de Docker ou testes focados. A flag CI permite que o pnpm recrie um diretório de módulos pré-aquecido sem confirmação interativa. Não enfraqueça o lockfile ou rotule falhas de checkout esparso como falhas de produto/Docker.
• Se o candidato for rebasado ou seu SHA base mudar após o pré-aquecimento, pare a caixa de propriedade da tarefa e pré-aqueça uma nova antes de testar. A sincronização de fonte Testbox é relativa à árvore de fonte pré-aquecida; continuar pode misturar um arquivo base antigo com um diff candidato novo e produzir falsas falhas de lockfile ou Docker.
• Testboxes reutilizadas são verificadas em relação à sua fonte gravada após sua primeira execução bem-sucedida. Edições apenas de fonte podem reutilizar a locação; deriva de base, dependência, wrapper ou fluxo de trabalho Testbox requer uma nova locação. Não defina OPENCLAW_TESTBOX_ALLOW_STALE=1 para evidência de lançamento.
• Para um candidato a lançamento commitado com o wrapper ciente de cápsula suportado, execute node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <comando> a partir do checkout desse candidato ao usar Testbox. A cápsula preserva a fonte do candidato e dependências congeladas enquanto main fornece limites de admissão atuais. Se o candidato não tiver esse contrato de wrapper, use a rota de validação de lançamento de destino exato abaixo com SHAs separados de Validação e Ferramentas. Não despache refs de fluxo de trabalho Testbox de candidato.