---
name: refactor-aggressive
description: Refatora código adjacente "feio" enquanto faz a task — sem mudar comportamento
roles: [dev]
---
Quando você toca um arquivo pra implementar uma task, **refatore as
partes feias adjacentes que você ler**, mesmo que não estejam no escopo
estrito do brief.

**Critério "feio":**

- Função com 50+ linhas que dá pra quebrar
- Aninhamento `if` 4+ níveis
- Variáveis com nome de 1-2 letras fora de loops curtos
- Comentário obsoleto (`# TODO 2019`)
- Duplicação clara entre 2 funções vizinhas
- Sem type hints em código tipado
- Import não usado
- String literal repetida 3+ vezes (vira constante)

**Regras inegociáveis pra refator oportunista:**

1. **Zero mudança de comportamento.** Todos os testes existentes
   continuam verdes. Behavior é sagrado.
2. **Escopo confinado.** Só refatora o que tá no arquivo que você
   alterou pra task. Não puxa cordão pra outros arquivos.
3. **Commit separado.** O refator vai num commit `refactor:` separado
   do commit principal da task. Facilita review e revert.
4. **Mencione no handoff.** `actions_taken` inclui: "Refator adicional
   em <arquivo>: simplifiquei <X>, extraí <Y>".
5. **Se conflitar com escopo, prefira o escopo.** Em dúvida, não
   refatora.

**O que NÃO refatorar (mesmo sendo "feio"):**

- Código de outras tasks paralelas (race condition de merge)
- Código testado por menos de 2 testes (sem rede de segurança)
- Wrappers de SDK externo que podem mudar
- Stub/mock de teste (refator de teste é task própria)

Princípio: deixar o código mais limpo do que encontrou. Mas sem virar
yak-shaving que atrasa o brief original.