Ideia principal

Quando o código diz uma coisa e o banco de dados ou a tela diz outra, o primeiro reflexo é culpar as datas: um dos dois está atrasado em relação ao outro, não há nada a concluir. Esse reflexo tem um efeito perverso — ele classifica como artefato de método aquilo que é justamente o resultado procurado.

Se as duas afirmações vêm do mesmo instante do produto — a mesma versão, em produção —, nenhuma defasagem está em causa. O produto se contradiz a si mesmo: uma restrição de unicidade que o negócio desmente, uma validação de formulário que nenhuma verificação no servidor duplica, um campo obrigatório na tela e opcional no banco. É exatamente o tipo de divergência que uma descrição cruzada serve para trazer à tona.

Daí a precaução de ordem: vamos datar as fontes primeiro, para que toda contradição restante seja do produto e não do dispositivo de observação.

Por que isso importa

Isso transforma um incômodo metodológico em rendimento. O grosso do valor de um repositório de referência não vem das regras que ele copia direitinho, mas dos pontos em que duas partes do produto não dizem a mesma coisa — cada um virando uma dívida a arbitrar ou um defeito com implicação de segurança.

Isso também evita "alisar" a descrição: diante de duas afirmações contraditórias, a tentação é reter uma e seguir em frente, o que apaga o achado.

Nuances e limites

A regra exige uma disciplina de datação exemplar; sem isso, ela produz o erro inverso: tomar uma defasagem de fontes por uma incoerência do produto, e abrir divergências que não existem.

E nem toda contradição tem o mesmo estatuto: uma diferença entre dois aplicativos pode ser uma escolha assumida de escopo em vez de um defeito, desde que essa escolha esteja escrita em algum lugar.

Questões em aberto

• Que parcela dessas contradições é aceita conscientemente pelas equipes, e como distinguir a arbitragem tácita do defeito nunca visto?