Vibe CI Supply Chain: pinagem verificável sem reescrever histórico

ANÁLISE EDITORIAL

Um pipeline pode estar verde e ainda depender de uma tag móvel, de uma Action trocada depois da revisão ou de um binário baixado sem conferir o hash. A Vibe CI Supply Chain transforma essas preocupações em regras operacionais para o agente que trabalha no repositório do Mistral Vibe. Ela orienta como lidar com Git, GitHub Actions, imagens de container, hooks do pre-commit, dependências do sistema de build e downloads externos. O valor está na disciplina verificável, não ém prometer que uma cadeia de software ficou invulnerável.

O que esta Skill faz

A Skill registra um conjunto curto de decisões que precisam sobreviver a uma conversa com o agente. Para Git, ela proíbe reescrever commits já enviados e diferencia duas reconciliações que muita equipe mistura: rebase da branch atual sobre o próprio upstream quando um push é rejeitado, e merge da branch base na branch de trabalho depois que o pull request já existe. Para CI, exige que cada referência uses: aponte para o SHA completo de um commit e mantenha um comentário humano com a versão correspondente.

Na cadeia de suprimentos, o documento pede identificadores imutáveis para imagens de container, hooks, dependências que executam durante o build e binários externos. Também protege um detalhe interno do Vibe: o orçamento de módulos importados durante a inicialização. Se esse orçamento estourar, a orientação é investigar a regressão, não aumentar o limite para fazer o teste passar.

Para quem serve

Ela serve primeiro a mantenedores e contribuidores do Mistral Vibe que alteram workflows, dependências, scripts de empacotamento, imagens, hooks ou a estrutura de imports do projeto. Também é uma referência concreta para revisores que querem ensinar um agente a respeitar políticas de histórico e pinagem sem repetir instruções em cada prompt.

Fora desse contexto, use o texto como estudo, não como política pronta. Um projeto pode adotar merge em vez de rebase, não usar uv, permitir tags mantidas por uma organização confiável ou controlar imagens por outra ferramenta. A Skill não descobre a política de um repositório e não substitui o arquivo de contribuição, a proteção de branch, o lockfile ou a revisão de segurança.

Origem e curadoria

A origem auditada é a pasta .agents/skills/vibe-ci-supply-chain. A curadoria fixou o commit b166c3a39eaac6ece96ca31840a3278c636616b5, que coincide com a release v2.25.3 publicada em 11/09/2026. O LICENSE declara Apache-2.0.

O arquivo foi lido integralmente. A pasta individual tem somente um SKILL.md, sem scripts, referências adicionais, templates ou ativos ocultos. GitLab e Hugging Face foram pesquisados para localizar uma origem canônica alternativa. O Hugging Face oficial da Mistral menciona o Vibe e aponta para o mesmo repositório GitHub; nenhuma cópia oficial concorrente da Skill foi encontrada.

Compatibilidade e pré-requisitos

O contexto funcional é o próprio Mistral Vibe, que na revisão fixada declara Python 3.12 ou posterior. O README informa que o programa funciona no Windows, mas o alvo oficialmente suportado continua sendo o ambiente Unix. Em Windows nativo, o Vibe prefere Git Bash quando disponível e usa PowerShell como alternativa para as ferramentas gerenciadas. Isso importa porque a Skill mostra comandos e caminhos concebidos para a árvore do projeto.

Para seguir todas as regras, você precisa de Git, acesso autorizado ao repositório, uv, e das ferramentas chamadas pela mudança, como GitHub CLI, pre-commit ou um cliente de registry. Uma conta Mistral e chave de API são requisitos do Vibe, não do ZIP documental. Nunca coloque a chave no prompt, no repositório, no workflow ou no pacote da Skill.

Instalação com revisão

O README oficial fixado documenta a instalação do Vibe com uv tool install mistral-vibe e também com pip. Para instalar uma Skill local no Vibe, o mesmo README descreve pastas com SKILL.md em escopos de usuário ou projeto. Como esta Skill pertence ao próprio repositório, o caminho mais fiel é usar o checkout oficial fixado e revisar a pasta antes de habilitá-la.

uv tool install mistral-vibe
git clone https://github.com/mistralai/mistral-vibe.git
cd mistral-vibe
git checkout b166c3a39eaac6ece96ca31840a3278c636616b5

Esses comandos consultam a rede, gravam arquivos e podem instalar executáveis e dependências. Execute primeiro em ambiente de teste. O download do Bastidores contém apenas os textos permitidos e não é instalador do Vibe. A página do repositório e o ZIP local são botões separados justamente porque resolvem necessidades diferentes.

Configure o escopo antes do primeiro pedido

Informe ao agente qual branch está em trabalho, qual é o upstream, qual branch serve de base para o pull request e se existe política da organização que prevalece sobre a Skill. Delimite também os arquivos autorizados: por exemplo, somente .github/workflows, .pre-commit-config.yaml e pyproject.toml. Sem isso, uma revisão de pinagem pode se transformar em uma reforma ampla do repositório.

Comece em modo somente leitura e peça uma tabela com referência atual, origem, identificador imutável proposto, método de verificação e risco da troca. Nenhum commit, rebase, merge, push, download ou alteração de workflow deve ocorrer antes de uma segunda autorização. Uma regra de segurança não amplia por si só o escopo de escrita do agente.

Primeiro uso seguro

Um primeiro pedido prático é: “Revise somente os workflows autorizados. Liste referências mutáveis, dependências de build sem versão exata e downloads sem checksum. não altere arquivos, não baixe binários e não éxecute Git. Para cada achado, mostre arquivo, linha, evidência e forma de confirmar a correção”. Esse formato permite testar se o agente entendeu as restrições sem entregar controle do histórico.

Depois da triagem, escolha um achado pequeno. Para uma Action marcada com versão, o agente deve resolver o tag para o commit real, confirmar que o objeto final é do tipo commit e registrar o SHA completo com o comentário da versão. A documentação do GitHub sobre uso de Actions recomenda SHA completo para referências de terceiros e explica o custo: atualizações deixam de chegar automaticamente.

Git sem reescrever histórico

A Skill veta git commit --amend, git push --force e git push --force-with-lease. O princípio é simples: uma correção vira um novo commit e o envio usa git push comum. Quando o upstream da própria branch avançou, a orientação e fazer rebase da branch local sobre esse upstream. Quando a branch base avançou depois que o pull request foi aberto, a orientação muda para merge da base na branch atual.

Essa diferença preserva o histórico que outros revisores já viram no pull request. Ainda assim, rebase e merge podem gerar conflitos e modificar muitos arquivos. Antes de executar, compare com a política do repositório, confira git status, proteja trabalho não commitado e mantenha um caminho de retorno. A referência oficial do rebase e a referência oficial do merge detalham os efeitos que a Skill resume.

Actions fixadas no commit real

Em GitHub Actions, uma tag como v4 é legível, mas pode mudar de destino. A Skill exige o SHA completo do commit e um comentário como # v4.2.2. também alerta para tags anotadas: o objeto apontado pelo tag pode ser outro objeto tag, não o commit executado. Por isso a verificação deve “descascar” a referência e confirmar o tipo com git cat-file -t.

O GitHub oferece uma política que pode exigir Actions fixadas em SHA completo. Mesmo com a política, o revisor precisa conferir se o SHA veio do repositório oficial da Action, se a versão comentada corresponde ao commit e se as permissões do workflow continuam mínimas. Pinagem reduz variação, mas também fixa vulnerabilidades antigas até que alguém atualize o identificador.

Containers, hooks e dependências de build

Para containers, a Skill troca tags por referências @sha256:. A documentação do Docker confirma que o digest identifica uma versão exata da imagem. O cuidado adicional aparece em imagens multiplataforma: o digest do índice e os digests de cada plataforma não são intercambiáveis. O agente deve registrar qual manifesto foi resolvido, para qual registry e arquitetura.

Em .pre-commit-config.yaml, o documento pede SHA completo e comentário de versão para cada rev:. O comando pre-commit autoupdate --freeze, documentado pelo projeto pre-commit, ajuda a converter tags em hashes. No pyproject.toml, dependências de [build-system] recebem versões exatas porque executam durante a construção e podem escapar da proteção esperada do lockfile principal.

Downloads externos com checksum

O padrão rejeita encadear um download não verificado diretamente em tar, shell ou instalador. Primeiro o arquivo vai para um temporário, depois o SHA-256 é comparado com um valor conhecido para aquela versão e arquitetura, e somente então ocorre a extração. Se não éxistir hash cadastrado para a combinação solicitada, o processo deve falhar de forma explícita.

Esse mecanismo não prova que o fornecedor original era confiável, mas detecta alteração em relação ao artefato previamente aprovado. O hash precisa vir de uma fonte independente ou de um processo de release controlado, não do mesmo canal possivelmente comprometido. mudanças de versão devem atualizar URL, checksum, comentário humano e teste de instalação como uma única revisão.

Orçamento de imports do Vibe

A parte mais específica da Skill monitora o custo de inicialização de import vibe e da interface textual. O repositório guarda um script de medição e um arquivo com orçamentos. Se uma mudança no caminho de importacao ultrapassa o limite, a orientação e procurar import tardio, dependência desnecessaria ou carregamento que pode ser adiado.

Aumentar o orçamento apenas para silenciar o teste esconde uma regressão. A Skill admite ampliar o limite quando o custo é deliberado e justificado no pull request, usando o valor observado com margem aproximada de 10%. Isso é uma convenção interna, não um benchmark universal. Em outro projeto, caminhos, ferramenta de medição e margem precisam ser definidos pela equipe.

Resultado esperado

Uma boa execução produz um inventário dos pontos mutáveis, a evidência de cada resolução, as alterações propostas e os comandos de validação. Para Actions, registre repositório, tag humana, SHA completo e tipo do objeto. Para containers, registre registry, tag de origem, digest e plataforma. Para binários, inclua versão, arquitetura, URL, SHA-256 esperado e comportamento quando o hash não éxiste.

Se a tarefa autorizou edição, o resultado também deve mostrar o diff, os testes executados e o que permaneceu não verificável. não aceite como conclusão “pipeline seguro”. Prefira fatos estreitos, como “todas as referências uses: destes três workflows apontam para SHAs completos conferidos na data da revisão”.

Permissões e riscos

A Skill pode levar o agente a consultar GitHub, registries e páginas de release; alterar YAML, TOML e hooks; executar uv run; criar commits; fazer rebase, merge e push; ou baixar binários para verificar hashes. Cada uma dessas ações tem efeito diferente. Rede, escrita local, execução e mudança remota devem ser autorizadas separadamente.

Workflows costumam acessar GITHUB_TOKEN, segredos de deploy e ambientes protegidos. Nunca imprima valores em logs nem copie segredos para o prompt. Um SHA fixo pode apontar para código malicioso, e um checksum correto pode autenticar um artefato malicioso aprovado por engano. Revisão de origem, menor privilégio e atualização regular continuam obrigatórias.

Erros comuns e como corrigir

• Usar o hash do objeto tag: resolva a referência até o commit e confirme o tipo antes de atualizar o workflow.
• Fixar somente a tag da imagem: registre o digest do manifesto correto e a plataforma que será executada.
• Copiar checksum do mesmo download: busque o valor em canal confiável e versionado ou gere-o no processo de release aprovado.
• Aumentar o orçamento de imports automaticamente: investigue a regressão e justifique qualquer nova margem no pull request.
• Executar Git fora de uv run no Vibe: a Skill usa o ambiente do projeto para que os hooks encontrem dependências como o pyright.
• Aplicar a política a outro repositório: compare primeiro com CONTRIBUTING, proteções de branch e ferramentas locais.

Quando não usar

Não use esta Skill para auditar todo o software de terceiros, gerar SBOM, assinar artefatos, verificar proveniência SLSA, analisar vulnerabilidades de imagens ou responder a um incidente. Ela também não substitui Dependabot, Renovate, políticas de admissão, verificação de assinatura nem um fluxo de release reproduzível.

Se a necessidade for revisar manifests Flux sem tocar o cluster, a GitOps Repo Audit resolve outro problema. Se o repositório não é o Mistral Vibe, extraia os princípios aplicáveis e escreva uma política própria, em vez de instalar regras com caminhos e decisões internas que podem conflitar com sua equipe.

Versão, licença e pacote auditado

A pasta individual não declara uma versão separada. Esta curadoria usa a release v2.25.3 e o commit b166c3a39eaac6ece96ca31840a3278c636616b5, sob licença Apache-2.0, com 4.937 estrelas verificadas em 11/09/2026. O pacote local tem 7.181 bytes e somente três arquivos textuais: SKILL.md, LICENSE e ORIGEM.md.

Não há executáveis, Python, uv, Git, GitHub CLI, pre-commit, imagens, dependências, workflows, hooks, configurações, credenciais, logs ou dados. SHA-256 do ZIP: 467cc7625c689af652a4c5b7664788d0cd91ec0b65ce779302dd8600c05b6491.

O que a revisão editorial confirmou

O texto oficial separa histórico Git publicado de sincronização local, exige commit real para Actions, usa digest para containers, congela hooks e dependências executadas no build e verifica binários antes de extrair. também foi confirmado que a pasta individual não carrega código adicional e que a licença raiz permite redistribuir os três textos selecionados.

A revisão encontrou o limite central: a Skill codifica decisões do Mistral Vibe, inclusive comandos por uv run, caminhos de medição e uma estrategia particular de merge e rebase. Ela é valiosa porque e específica. Apresenta-la como regra universal seria retirar justamente o contexto que a torna verificável.

Checklist antes de executar

• Fixe o repositório, o commit, a branch atual, o upstream e a branch base.
• Confirme os arquivos autorizados e comece com inventário somente leitura.
• Valide tags anotadas até o commit real e registre a versão humana ao lado do SHA.
• Resolva digests por registry e plataforma; não trate uma tag como imutável.
• Obtenha checksums por processo independente e falhe quando o hash estiver ausente.
• Revise diff e testes antes de commit, merge, rebase ou push.
• Nunca exponha tokens, chaves, segredos de workflow ou conteúdo privado nos resultados.

Fontes oficiais consultadas

• Mistral Vibe, repositório oficial, requisitos, instalação e funcionamento.
• SKILL.md no commit auditado.
• Release v2.25.3.
• GitHub Docs, proteção contra ameacas em Actions.
• GitHub Docs, referências por SHA completo.
• Docker Docs, pull por digest.
• pre-commit, autoupdate e freeze.
• uv, instalação e execução de ferramentas.