Lançamentos desktop do BaoCut
Este é o aplicativo Electron v3 (com.baocut.app). A skill antiga baocut-app é uma
referência, não o fluxo executável deste checkout. Mantenha esta skill de desenvolvedor
fora da pasta skills/ do craft do App; não invoque lançamentos legacy GPUI/npm/Homebrew.
Selecione o fluxo de trabalho
| Intenção do usuário | Leia e siga |
|---|---|
| Solicitação de lançamento/publicação comum; nenhum método especificado | Lançamento via tag — padrão. Envie a tag da fonte congelada; publique macOS arm64 verificado primeiro, depois anexe Windows CPU/CUDA/Vulkan à mesma Release. |
| Pacote/candidato local explícito, lançamento tradicional ou manual, recuperação/continuação de plataforma única | Lançamento tradicional. Respeite as plataformas solicitadas e o escopo local/público. |
| Apenas identidade de assinatura, backups portáteis ou credenciais GitHub | Assinatura/backups. Não crie tag nem publique. |
Carregue apenas a referência necessária para a intenção selecionada. Não pergunte ao usuário para escolher entre os dois métodos de lançamento quando ele não tiver especificado um: use lançamento via tag. Não recorra silenciosamente ao empacotamento tradicional após uma falha no Actions. Uma instrução específica de plataforma ou local substitui o escopo padrão de todas as plataformas; siga o método e os limites explícitos do usuário.
Restrições compartilhadas de lançamento
- Inspecione o status do git antes de editar; preserve trabalho não relacionado ou concorrente. Commite alterações de origem de propriedade da tarefa antes de congelar um lançamento. Siga as regras de confirmação do repositório, push autorizado da tarefa atual e limpeza da árvore de trabalho; não reutilize autorização de push de outra tarefa nem solicite novamente quando já concedida aqui.
apps/desktop/package.jsonpossui a versão do App. Sincronize a versão raiz e o lockfile por meio do npm; não incremente versões do Cargo ou do protocolo para um lançamento do App.- Consulte lançamentos/feeds reais antes de escolher uma build. As builds aumentam estritamente; tags/arquivos já publicados são imutáveis.
- Mantenha a tag e todos os artefatos de plataforma vinculados a um único SHA de origem completo. Nunca envie binários de fonte suja, materiais de assinatura privados ou submissões de notário intermediárias.
- Publique a Release macOS, o changelog reconciliado e os links de download verificados assim que o candidato macOS for aprovado; as builds Windows/CUDA não bloqueiam esta etapa. A conclusão de plataforma posterior atualiza os ativos, notas e feeds dessa Release, nunca a tag Git ou seu SHA de origem. Relate plataformas pendentes separadamente; avance Latest na etapa de conclusão abaixo.
- Para cada nova versão/build publicada, siga notas de versão: faça o inventário do intervalo completo de commits/PRs, resuma intervalos grandes em lotes, reconcilie a cobertura e publique o changelog consolidado. Um candidato local mantém as mesmas notas localmente; a continuação de plataforma reutiliza o intervalo da versão existente.
- Após cada lançamento público ou continuação de plataforma, verifique os links de download
usando links de download. Os READMEs e o baocut.com
apontam para
baocut.com/download/<id>, que segue o GitHub Releases por conta própria. Não edite os READMEs nem reimplante o site para um lançamento; verifique se o baocut.com serve a nova build. - Relate verificações e pulos reais. Um push de tag ou verificação de credencial por si só não é um lançamento concluído; a publicação requer jobs bem-sucedidos, leitura pública, feeds, notas de versão verificadas e uma verificação de download do baocut.com aprovada.
Lançamento público completo
Depois que todas as plataformas selecionadas tiverem sido publicadas, os ativos públicos e feeds tiverem passado na leitura, e as notas de versão consolidadas estiverem verificadas, marque a versão desktop estável mais recente como Latest na aba Releases do GitHub:
gh release edit "$release_tag" --repo "$release_repo" --latest
gh api "repos/$release_repo/releases/latest" --jq '.tag_name'
Use o repositório e a tag verificados para esta tarefa; a leitura deve corresponder a essa tag. Os publicadores de plataforma preservam o Latest anterior enquanto validação e uploads estão em andamento, portanto, esta etapa final é necessária mesmo quando o Actions é bem-sucedido. Candidatos locais, drafts e pré-lançamentos não avançam o Latest. Ao continuar um lançamento mais antigo, mantenha uma versão desktop publicada mais nova/build como Latest. Inclua a tag Latest verificada no relatório de conclusão.
O guia desktop é responsável pela mecânica de empacotamento; referências específicas de modo explicam quando carregá-lo. Solicitações apenas para alterar a configuração de lançamento não devem criar uma tag de lançamento nem publicar.