Refatoração nativa do repositório

Quando usar

• Use quando o usuário pedir para revisar um diff, branch ou PR quanto à correção, quebra de contrato ou risco operacional.
• Use quando o usuário autorizar limpeza limitada antes de abrir um PR ou pedir para consolidar políticas duplicadas com propriedade compartilhada.
• Use para reabilitação de repositório apenas quando o usuário solicitar explicitamente trabalho em vários domínios.
• Estabeleça autoridade de revisão apenas, edição ou combinada antes de escolher o modo de operação.

Produza a menor mudança coerente que pertença naturalmente ao repositório de destino.

Priorize na ordem:

1. Correção e segurança: prevenir regressões, evitar novas vulnerabilidades de segurança, lidar com condições de contorno.
2. Integridade semântica: preservar invariantes existentes, transições de estado, validação e limites de erro.
3. Contratos permanecem como declarados: a regra vive em references/shared-contracts.md §1. Preserve o contrato de destino autorizado; caso contrário, mantenha tipos declarados exatos. Auxiliares internos são aceitáveis quando os contratos expostos permanecem exatos.
4. Conformidade do repositório: corresponder à nomenclatura circundante, convenções de domínio e precedentes arquitetônicos.
5. Economia e simplicidade: intervenção mínima. Exclua peso morto, evite abstrações prematuras.

Esta é uma habilidade de auditoria pós-implementação e limpeza pequena. Não é permissão para redesenhar o repositório. Estabeleça uma consequência concreta, como comportamento inconsistente, política duplicada que deve mudar junta, propriedade pouco clara, custo de recurso evitável ou um obstáculo de manutenção demonstrado. Deixe o código saudável inalterado quando o benefício for especulativo.

Intervenção mínima e portão de evidências

• Intervenção baseada em evidências: refatore apenas com evidências concretas de divergência, defeito ou risco operacional. Se o código greenfield ou um diff aditivo já for mínimo, idiomático e estiver passando, deixe-o. Um padrão que você reconhece é um achado candidato, não um motivo para mudar nada.
• DRY semântico (consolidação custo-benefício): mescle lógica duplicada apenas quando as cópias compartilharem um proprietário, um invariante e um motivo para mudar, e apenas se a mesclagem economizar mais do que custar. Deixe verificações de aparência semelhante em domínios separados em paz e mantenha pequenas duplicações locais quando a mesclagem obscureceria a propriedade.
• Proteção de limite de contrato: preserve interfaces públicas, nomes de parâmetros e tipos de retorno, exceto onde a tarefa autoriza claramente a mudança. Durante a limpeza, mantenha o contrato de destino autorizado; não reverta para o antigo.

Modos de operação

• Autoridade de Revisão vs. Refatoração: primeiro estabeleça o resultado: achados, edições ou ambos. Apenas revisão significa inspeção e verificação, sem edições de código. Limpeza autorizada permite correções limitadas; não peça aprovação novamente para escolhas rotineiras.
• Limpeza de conjunto de alterações: para uma árvore de trabalho, branch, intervalo de commits, recurso ou ponto de verificação limitado. Trabalhe primeiro com o diff; leia o código circundante apenas para entender a propriedade, os contratos e o precedente.
• Reabilitação de repositório: apenas quando explicitamente solicitado em vários domínios. Leia reabilitação de repositório, crie um perfil curto e trabalhe em lotes que você possa verificar independentemente.

Hierarquia de evidências

Use a hierarquia de evidências para guiar a investigação, não para resolver contradições materiais automaticamente. Reconcilie requisitos conflitantes, documentação, chamadores e testes antes de alterar o contrato afetado. Quando os padrões do repositório entram em conflito, resolva na ordem:

1. Requisitos do usuário e escopo explicitamente autorizado.
2. Arquitetura documentada e diretrizes do repositório.
3. Contratos públicos observáveis e esquemas persistidos.
4. Código irmão saudável dentro do mesmo domínio e limite de tempo de execução.
5. Testes, esquemas, chamadores e dependências relevantes.
6. Convenções locais dominantes.
7. Idiomas de linguagem e tempo de execução.
8. Padrões conservadores e idiomáticos.

Nunca trate uma solução temporária, um irmão com defeito ou um padrão acidental como precedente.

Fluxo de trabalho

1. Estabelecer escopo e linha de base

Antes de mutar o código, identifique:

• Base de comparação e estado da árvore de trabalho.
• Arquivos no escopo vs. modificações do usuário intocadas.
• Comandos de verificação existentes e seu status atual de aprovação/reprovação.

Diferencie falhas pré-existentes de regressões introduzidas por esta passagem. Nunca afirme que uma verificação foi executada quando não foi.

2. Estabelecer intenção, propriedade e preservação

A refatoração preserva o comportamento por padrão. Proteja:

…