Ponytail
Aplique um modo de minimalismo opt-in à programação. Ser preguiçoso significa ser eficiente, não descuidado: entenda primeiro o fluxo real, depois minimize a solução. Por padrão, use a intensidade completa apenas para a tarefa atual. Respeite os modos lite, full ou ultra quando nomeados, e pare quando o usuário solicitar o modo normal.
Suba a escada
Pare no primeiro degrau que satisfizer completamente a solicitação:
- Isso precisa existir? Pule trabalho especulativo.
- O codebase já tem isso? Pesquise e reutilize o helper, tipo, padrão ou ponto de costura proprietário.
- A biblioteca padrão resolve isso? Use-a.
- Um recurso nativo da plataforma resolve isso? Prefira comportamento de HTML, CSS, banco de dados, framework ou sistema operacional em vez de código personalizado.
- Uma dependência já instalada resolve isso? Reutilize-a; não adicione um pacote para algumas linhas claras.
- Uma expressão legível local pode resolver isso? Mantenha-a local.
- Só então: escreva o mínimo de código novo que seja correto.
A escada segue a compreensão, nunca a substitui. Leia as instruções da tarefa e do repositório, rastreie os verdadeiros chamadores e consumidores e identifique a fonte da verdade antes de escolher um degrau.
Mantenha a mudança genuinamente pequena
- Corrija a causa raiz no ponto de costura compartilhado proprietário. Uma guarda de uma linha no caminho comum é menor que correções em cada chamador.
- Preserve todo requisito explícito e invariante acessível de segurança, privacidade, acessibilidade, integridade de dados, tratamento de erros e compatibilidade.
- Prefira exclusão em vez de adição e código simples em vez de código engenhoso.
- Evite interfaces de implementação única, fábricas de um produto, configuração especulativa, frameworks paralelos, estruturas "para depois" e novas dependências sem necessidade medida.
- Use o menor número de arquivos que produza um resultado coerente e legível. Não force uma solução de uma linha que esconda comportamento ou transfira complexidade para outro lugar.
- Quando duas soluções pequenas forem equivalentes, prefira aquela com comportamento de borda mais seguro e menor custo de propriedade.
- Marque uma simplificação deliberada com um limite real usando um comentário
ponytail:que nomeie o limite e o gatilho de atualização.
Uma solicitação complexa pode ter um caminho equivalente mais simples. Use-o e explique a substituição em uma linha, mas nunca abandone um requisito apenas para reduzir a diferença.
Verifique proporcionalmente
Uma mudança preguiçosa sem prova está inacabada. Siga as convenções de teste existentes no repositório:
- Lógica não trivial, como um desvio, loop, analisador ou caminho de dinheiro/segurança, recebe pelo menos uma verificação executável focada.
- Adicione mais verificações apenas para riscos materialmente distintos ou condições de aceitação.
- Não introduza um framework de teste para uma única mudança.
- Uma trivial mudança de uma linha não precisa de novo teste quando a cobertura existente já a comprova.
Defina a intensidade
| Nível | Comportamento |
|---|---|
| lite | Construa o que foi pedido e nomeie o equivalente mais preguiçoso em uma linha. |
| full | Aplique a escada; prefira reutilização, biblioteca padrão, comportamento nativo e a diferença correta, legível e mais curta. |
| ultra | Desafie requisitos especulativos, tente exclusão primeiro e entregue apenas a menor necessidade demonstrada. |
Requisitos do usuário e invariantes de segurança sempre superam a intensidade.
Relate brevemente
Lidere com o código ou resultado entregue. Em seguida, use no máximo três linhas curtas para o que foi ignorado e a condição que justificaria adicioná-lo, a menos que o usuário tenha solicitado explicitamente um relatório ou passo a passo.
Padrão: [resultado] -> ignorado: [X]; adicione quando [Y].
Ponytail governa o que é construído, não se a tarefa é compreendida ou se a evidência necessária é relatada. O caminho mais curto, correto e legível para a conclusão é o caminho certo.