jcchikikomori/skills-md

Regras de Git

• Nunca execute git commit ou `git push — pois os commits serão assinados por GPG.
• Seu trabalho é preparar e estagiar mudanças apenas (git add). O usuário fará commit e push manualmente em seu próprio terminal onde GPG + TTY funcionam.
• git stash, git diff, git status, git log, git add e comandos git somente leitura são todos permitidos.
• Para reverter/desfazer, use git blame para identificar mudanças e reduzir erros.
• Busque o repositório atual primeiro antes de fazer qualquer alteração. Se houver uma alteração em andamento vinda do upstream, pergunte se é necessário um merge/rebase.

Merge / Rebase na Branch de Destino

Execute estas etapas em ordem antes de integrar mudanças do upstream:

1. Buscar upstream

   git fetch origin
   

2. Verificar divergência — commits no destino que ainda não estão na branch atual

   git log HEAD..origin/<destino> --oneline
   

3. Verificar sobreposição de arquivos

   git diff --name-only HEAD...origin/<destino>
   

4. Executar verificação de impacto em especificações/testes (veja abaixo) — faça isso ANTES de merge ou rebase.

5. Avaliar risco de conflito — se a divergência ou sobreposição de arquivos for significativa, pergunte ao usuário se deve fazer merge ou rebase.

6. Apenas estagiar — o usuário faz commit e push manualmente (restrição GPG).

Verificação de Impacto em Especificações e Testes

Antes de qualquer merge ou rebase, verifique mudanças no upstream em especificações/testes que se sobrepõem ao trabalho da branch atual:

git diff HEAD...origin/<destino> -- \
  '*_spec.rb' '*.spec.*' '*.test.*' \
  'spec/' 'test/' '__tests__/' 'tests/'

Se arquivos de especificação/teste mudaram no upstream:

• Exiba o diff — mostre quais arquivos de teste mudaram e o que mudou.
• Sinalize sobreposição de domínio — identifique se os testes alterados cobrem as mesmas funcionalidades ou arquivos que a branch atual modifica.
• Pergunte antes de prosseguir — se a implementação da branch atual pode ser testada por especificações desatualizadas ou recém-alteradas, pergunte ao usuário se deve atualizar a branch primeiro ou prosseguir.

Justificativa: mesclar mudanças de teste do upstream em uma branch com nova implementação cria falsos negativos no CI — os testes passam porque testam comportamento antigo. Detectar desvio de especificação antes do merge evita falhas confusas downstream.

Resolução de Conflitos

• Se houver conflitos de merge, avalie o problema e pergunte ao usuário se devemos resolvê-lo ou não.
• Resolva cada conflito por arquivo. não resolva tudo de uma vez.

Tags

• Siga os prefixos de versão existentes (se disponíveis).
• Siga o formato de versionamento do SemVer (ex.: v1.0.0-beta).

Padrões de Pull Request

• Tamanho do PR ≤ 200 linhas (a menos que não seja possível simplificação razoável).
• Escopo limitado: Apenas mudanças para o ticket/story (sem refatoração não relacionada).
• Descrição curta ou pontos resumindo as mudanças.