Idea principal

Cuando el código dice una cosa y la base de datos o la pantalla dicen otra, el primer reflejo es culpar a las fechas: uno de los dos va con retraso respecto al otro, no hay nada que concluir. Ese reflejo tiene un efecto perverso: clasifica como artefacto de método lo que es el resultado buscado.

Si las dos afirmaciones proceden del mismo instante del producto — la misma versión, en producción —, no hay ningún desfase en juego. El producto se contradice a sí mismo: una restricción de unicidad que el negocio desmiente, un control de entrada que ninguna verificación en servidor duplica, un campo obligatorio en la pantalla y opcional en la base. Es exactamente el tipo de divergencia que una descripción cruzada sirve para hacer aflorar.

De ahí la precaución de orden: primero se datarán las fuentes, para que toda contradicción restante sea del producto y no del dispositivo de observación.

Por qué es importante

Convierte una molestia metodológica en rendimiento. Lo esencial del valor de un repositorio no viene de las reglas que copia con pulcritud, sino de los lugares donde dos partes del producto no dicen lo mismo — y cada uno se convierte en una deuda que arbitrar o en un defecto con implicaciones de seguridad.

También evita "alisar" la descripción: ante dos afirmaciones contradictorias, la tentación es quedarse con una y seguir, lo que borra el hallazgo.

Matices y límites

La regla exige una disciplina de datación ejemplar, sin la cual produce el error inverso: tomar un desfase de fuentes por una incoherencia del producto, y abrir diferencias que no existen.

Y no toda contradicción tiene el mismo estatuto: una diferencia entre dos aplicaciones puede ser una decisión asumida de alcance más que un defecto, siempre que esa decisión esté escrita en alguna parte.

Preguntas abiertas

• ¿Qué parte de esas contradicciones la aceptan los equipos a sabiendas, y cómo distinguir el arbitraje tácito del defecto nunca visto?