Mantenedor de Repositório

Visão Geral

Auditar a saúde do repositório, aplicar correções autorizadas de forma restrita e finalizar através do fluxo de trabalho protegido do próprio repositório.

Quando Usar

Use quando o usuário pedir para manter, limpar, auditar, fortalecer ou preparar um repositório para lançamento. Use uma habilidade mais específica de segurança, banco de dados, implantação ou lançamento quando essa for a tarefa dominante.

Portão de Política do Repositório

Antes da mutação:

1. Ler os arquivos raiz e aninhados AGENTS.md, orientação para contribuidores, documentação do mantenedor e instruções de lançamento.
2. Inspecionar o branch atual, a árvore de trabalho, os arquivos preparados, os remotos, o branch padrão e a proteção de branch efetiva.
3. Descobrir comandos nativos do repositório para validação, sincronização, merge e lançamento.
4. Preservar trabalho do usuário não relacionado e saídas geradas que não estão no escopo.

Se o repositório nomear uma habilidade de mantenedor obrigatória ou um comando protegido, delegue a ele em vez de inventar um branch, merge, sincronização ou caminho de lançamento paralelo. Em agentic-awesome-skills, use antigravity-maintainer-batch-release e npm run merge:batch; main é apenas para pull-request.

As verificações protegidas de rotina para agentic-awesome-skills são pr-policy, pr-evidence, source-validation e artifact-preview. A pré-visualização do AAS Core suportada usa testes unitários direcionados mais um caminho de fumaça Linux/Node LTS empacotado e revisão do Workbench. Não ressuscite a linha de base certificada-v1 aposentada, benchmark, tuning-gold, transaction-fault, race ou a matriz de sistema operacional/runtime congelada como portões de merge de rotina.

Uso

1. Estabelecer a linha de base

git status --short --branch
git diff --stat
git diff --cached --stat
git remote -v
git log -5 --oneline

Registrar as versões de runtime e os comandos de teste exigidos pelo repositório. Use um clone temporário limpo ou árvore de trabalho quando as alterações existentes do usuário não puderem ser isoladas com segurança.

2. Auditar lanes independentes

Executar verificações independentes somente leitura em paralelo, quando possível.

Artefatos e higiene do Git

• caches não rastreados, saída de compilação, arquivos do editor e sobras de teste;
• arquivos grandes ou binários rastreados, segredos acidentais, desvio de modo executável e lacunas em arquivos ignorados;
• branches obsoletos, HEAD destacado, alterações preparadas existentes, submódulos e links simbólicos;
• arquivos gerados cuja propriedade pertence ao CI ou a um fluxo de trabalho de sincronização canônica.

Não exclua ou reescreva o histórico durante a auditoria.

Dependências e empacotamento

• acordo de lockfile e manifesto;
• dependências desatualizadas, vulneráveis, duplicadas, não utilizadas ou de fim de vida;
• importações de runtime incorretamente colocadas em dependências de desenvolvimento;
• comportamento de clean-install, conteúdo do pacote e ponto de entrada executável.

Trate a saída da ferramenta de auditoria como evidência para verificar, não como permissão automática para atualizar ou remover pacotes.

Saúde do CI e de lançamento

• execuções de fluxo de trabalho falhando, canceladas, puladas ou obsoletas;
• matrizes de runtime obsoletas, redundantes ou injustificadamente amplas e ações não fixadas ou obsoletas;
• verificações obrigatórias, proteção de branch, permissões de lançamento e limites de segredo;
• incompatibilidade entre comandos de lançamento documentados e implementados.

Documentação e metadados do repositório

• README, changelog, versão, exemplos, links, badges, créditos e metadados de suporte;
• instruções de contribuição e modelos de PR versus política de CI atual;
• desvio na documentação gerada de catálogo, site ou API.

Sinais de qualidade de código

• código morto, marcadores de implementação obsoletos, logs de depuração, código comentado e testes ausentes;
• padrões inseguros, erros suprimidos, exposição de credenciais e caminhos específicos do ambiente.

Apenas para projetos FAF, inspecione também os contratos declarados .faf, .faf-dna, sync, score e MCP com os comandos FAF instalados do projeto.

3. Produzir um conjunto de decisões priorizado

Para cada relatório de descoberta:

• evidência e caminhos afetados;
• gravidade e impacto no usuário;
• se é seguro corrigir agora, precisa de aprovação ou pertence a outro fluxo de trabalho;
• validação exata que prova a correção.

Deduplique sintomas com a mesma causa raiz. Não misture modernização opcional com bloqueadores de lançamento.

4. Aplicar correções autorizadas

Faça o menor conjunto de alterações coerente. Mantenha a propriedade de arquivos de origem e gerados separada, atualize testes com alterações de comportamento e reexecute a verificação falha direcionada após cada grupo de correções.

Nunca exclua dados, reescreva o histórico, rotacione credenciais, altere a proteção de branch ou atualize versões com quebras sem autorização explícita.

5. Validar e publicar com segurança

…