Comece pelos erros caros
Um linter consegue revisar milhares de frases em segundos, então é tentador codificar toda preferência editorial. Evite isso. Comece por nomes de produto incorretos, terminologia inconsistente, linguagem de risco, warnings ambíguos e erros repetitivos de formatação.
Se a primeira execução gerar centenas de avisos de baixo valor, a equipe aprenderá a ignorar a ferramenta.
Trate regras como código
Guarde configuração e vocabulários do Vale no repositório, faça review das mudanças e use nomes que expressem intenção. ApprovedProductNames é mais fácil de discutir que RegexRule17.
Mantenha pequenos fixtures com exemplos que devem passar e falhar.
Separe erros de recomendações
Bloqueie o build apenas por problemas que a equipe concordou que devem ser corrigidos. Use warnings onde é necessário julgamento editorial. Assim o CI permanece previsível.
Cuide do vocabulário
Terminologia costuma dar retorno rápido. Centralize nomes aprovados, capitalização e substituições. Adicione exceções explícitas em vez de desativar regras úteis globalmente.
Falsos positivos também são sinais: às vezes a regra está errada; às vezes o modelo de conteúdo dificulta consistência.
Edição humana continua humana
Vale não decide se uma explicação responde à pergunta certa ou se um exemplo ensina o modelo correto. Automatize defeitos repetíveis e reserve atenção humana para estrutura, evidência e clareza.
Um bom quality gate quase é entediante: encontra sempre os mesmos problemas importantes e raramente surpreende o autor.
Exemplo aplicado
Trate “Use Vale como quality gate, não como polícia de pontuação” como uma avaliação pequena, não como comparação de listas de recursos. Escolha três amostras reais: uma página simples, uma com código ou dados estruturados e outra com navegação, reutilização ou localização. Teste todas com a ferramenta ou método e anote o que ficou mais fácil e qual novo custo de manutenção apareceu.
Avalie o trabalho repetido da equipe:
- se a fonte é compreensível para o autor;
- se o revisor enxerga um diff significativo;
- se o build aponta um problema que pode ser corrigido;
- se o conteúdo pode ser movido, localizado e reutilizado sem limpeza manual.
Uma boa ferramenta reduz incerteza em autoria, revisão e publicação. Se a complexidade apenas migra para configuração frágil, plugins ou memória de uma pessoa, esse custo também faz parte da decisão.
Checklist editorial rápido
- Comece pelos erros caros. Um linter consegue revisar milhares de frases em segundos, então é tentador codificar toda preferência editorial.
- Trate regras como código. Guarde configuração e vocabulários do Vale no repositório, faça review das mudanças e use nomes que expressem intenção.
- Separe erros de recomendações. Bloqueie o build apenas por problemas que a equipe concordou que devem ser corrigidos.
- Cuide do vocabulário. Terminologia costuma dar retorno rápido.
