pr-simplify

Simplifique a alteração

Uma passagem de edição feita pelo autor da alteração: execute-a no seu próprio branch antes de abrir o PR e novamente antes de enviar grandes reparos. Ela precede a revisão e nunca a substitui. Herda o escopo da tarefa e a autoridade de reparo; uma solicitação apenas de revisão recebe descobertas, não edições. O fluxo de trabalho do mantenedor escolhido é o responsável pela publicação, revisão e merge.

O diff é uma proposta. Testes aprovados mostram que funciona, não que sua arquitetura ou cada teste adicionado seja necessário.

Regras: as seções "Prioridades de design", "Um proprietário, corte completo", "Proteções de runtime e código" e "Produto e validação" do AGENTS.md raiz, além do AGENTS.md mais próximo com escopo definido. As etapas 2 e 3 aplicam todas as regras a cada arquivo alterado.

1. Re-derivar a menor correção completa

Leia o resultado do usuário e o escopo mais recente, o diff completo em relação à base de merge alvo e as provas retidas. Reutilize o contexto da sessão já coletado. Então pergunte:

Partindo da base, qual é a menor correção completa usando os proprietários já presentes? Eu ainda introduziria essa arquitetura?

Inspecione primeiro os maiores módulos adicionados, estados, adaptadores e infraestrutura de teste. Leia seus chamadores diretos e histórico relevante: comportamento aparentemente redundante pode proteger uma configuração já enviada ou uma regressão anterior. O escopo é o sistema alterado e os caminhos que ele substitui.

Rastreie cada pedaço alterado até o resultado declarado. Um pedaço que atende a outro objetivo sai desta alteração: remova-o ou mova-o para seu próprio PR.

Conte o número de linhas alteradas não mecânicas. Acima de cerca de 800, ou cerca de 500 para lógica complexa, nomeie o menor estágio coerente que pode ser implantado primeiro e corte a alteração para esse estágio.

Concluído quando você puder declarar o defeito, o invariante necessário e a menor correção completa em uma frase cada, e cada pedaço restante servir a essa correção.

2. Remover arquitetura desnecessária

Aplique cada simplificação suportada no diff:

• Um único proprietário de decisão. Mova a política repetida do lado do chamador para a operação que possui a decisão. Migre os chamadores afetados e remova as implementações antigas, exportações e branches de reparo. Diferentes transportes podem compartilhar uma decisão mantendo seus próprios contratos de entrega.
• Estado existente primeiro. Desafie novos esquemas, gerentes, caches e representações combinadas. Reutilize um proprietário existente quando seu tempo de vida, autoridade, atomicidade e limpeza forem adequados. Remova uma migração proposta apenas quando for genuinamente desnecessária; mantenha a migração que mantém a configuração e o estado existentes funcionando após a atualização. Novo estado pertence a um campo que o significa.
• Remova o caminho redundante. Elimine renderizadores paralelos, parsers duplicados, operações de ciclo de vida falsas usadas apenas para obter um resultado, estado derivado que chamadores já podem obter e wrappers que apenas encaminham ou renomeiam. Prefira uma representação mais simples em vez de modos de fallback ao redor da antiga.
• Polimento por último. Em cada pedaço alterado, mantenha apenas o que um mantenedor do arquivo circundante escreveria:
  • comentários que explicam propriedade, ciclo de vida, ordenação ou restrições;
  • verificações e blocos try/catch que correspondem ao módulo circundante e protegem estados reais;
  • tipos reais em vez de casts de lavagem (as any, as unknown as T, widen-then-assert);
  • variáveis e auxiliares que adicionam significado de domínio, removem duplicação ou simplificam o fluxo de controle;
  • shims, aliases, retentativas e fallbacks apoiados por um contrato nomeado enviado e plano de remoção;
  • nomenclatura, fluxo de controle, importações e formatação que correspondem ao arquivo circundante.

Preserve a correção solicitada e o comportamento suportado, não o design acidental da proposta. Mantenha diferenças reais de domínio e compatibilidade pública justificada. Quando o histórico (git log -p -S <símbolo>) deixar o propósito de um caminho pouco claro, mantenha-o e relate-o. Relate novas decisões de produto, contratos que quebram, limpeza não relacionada e substituição destrutiva de branches como descobertas para o proprietário.

3. Manter testes para falhas

Para cada grupo de teste adicionado ou alterado e seus auxiliares de configuração, nomeie a falha observável distinta que ele captura.

Mantenha regressões para o defeito real e limites distintos: ordenação, cancelamento, autoridade obsoleta, reinicialização, rejeição, erros reais e diferenças de consumidores afetados. Mantenha guardas de contrato estáticos que protegem independentemente um limite real. Remova casos duplicados do mesmo caminho, ecos de mock, asserções de cópia de campo ou redação incidentais, asserções em valores definidos estaticamente, testes que apenas provam que a lógica removida sumiu, testes de implementações obsoletas e infraestrutura ou hooks de produção apenas para teste. Consolide casos úteis em uma suíte de proprietário existente.

Remover testes nunca enfraquece as asserções, a cobertura de limites reais ou as linhas de base que permanecem.

Concluído quando cada grupo de teste restante tem uma falha nomeada.

4. Provar a alteração menor e entregá-la

Agrupe as edições, então reexecute a reprodução e as verificações focadas para os contratos alterados e consumidores afetados. Reutilize provas cujas entradas não foram alteradas. Uma reinicialização, upgrade ou alegação de transporte preservados precisam de prova aplicável. O fluxo de trabalho existente seleciona verificações mais amplas.

Concluído quando o diff completo é inspecionado, cada regra tem um veredito para cada arquivo alterado, simplificações suportadas são aplicadas, caminhos substituídos são inacessíveis e o comportamento afetado ainda tem prova. Nenhuma alteração é um resultado válido quando a forma existente é justificada. Mire em código líquido negativo, não em uma cota de exclusão.

Relate no corpo do PR ou na evidência de tarefa existente: a responsabilidade ou maquinário que desapareceu, o comportamento ainda protegido e os deltas de produção/teste em relação à base de merge. Rotule uma redução em relação a uma revisão anterior separadamente do delta de toda a alteração. Nomeie qualquer crescimento necessário restante ou decisão não resolvida.

Em seguida, abra ou atualize o PR. Após reparos posteriores, simplifique apenas as novas alterações e os proprietários que elas tocam antes de enviá-los.