El chequeo de frescura que saltaba cada vez que alguien hacía lo correcto

Un registro interno de citas del código tenía nueve filas apuntando a la misma línea: la que declara qué capas existen. Añadir una capa es lo correcto y, byte a byte, también es un cambio en esa línea. Resultado: cada alta legítima ponía nueve filas en rojo a la vez, y el registro se pasaba la vida marcando obsolescencia por el mejor de los motivos.

La reparación que rompe la herramienta

La salida obvia es volver a fijar la huella: bytes nuevos, hash nuevo, filas en verde. Hacerlo una vez ya le enseña a la herramienta a borrar sus propios hallazgos. "Obsoleto" pasa a significar "obsoleto desde la última vez que alguien volvió a fijar el pin", que es una propiedad de tus costumbres, no del código. Una obsolescencia real, esa en la que la cita ya no coincide con lo que hay, queda blanqueada en verde por el mismo comando que arregla la falsa, y la salida no distingue una de otra. Hay un brazo de test cuyo único trabajo es afirmar que esto no puede pasar, repin_never_repairs_a_stale_pin, y merece la pena tenerlo porque la tentación llega disfrazada de orden.

Qué protege de verdad la fila

Con el repin descartado, la pregunta útil dejó de ser cómo mantener fresca la huella y pasó a ser para qué sirve. Ninguna de las nueve filas afirma nada sobre el valor de la lista: nombran los binarios de chequeo por capa y necesitan que la declaración exista y se encuentre. Que hoy diga cinco capas o quince les da igual, y de eso ya se encargan otros tres parsers que rechazan entradas mal formadas o desconocidas. La huella protegía una propiedad de la que la fila no depende y duplicaba una comprobación que ya hacen otros tres dispositivos.

De ahí salió un segundo tipo de anclaje, que apunta a una clave en lugar de a bytes: path/to/file@key:layers. Sus veredictos son tres. Fresca cuando la clave aparece exactamente una vez; obsoleta cuando falta, y entonces la fila entra en la lista de huérfanas para que no se pierda en silencio; ambigua cuando aparece más de una vez. Esa tercera importa más de lo que parece: dos declaraciones de la misma clave no son "encontrada" ni "ausente", y meterlas en cualquiera de los dos sacos es como una herramienta empieza a responder preguntas que no puede responder. El anclaje por clave tampoco tiene estado de movimiento, así que no hay nada posicional que se desplace y el repin no tiene nada que reescribir aunque se lo pidan. El bug que preocupaba no queda protegido: simplemente no existe.

Diez filas se movieron al anclaje por clave. Las demás conservaron la huella de bytes, porque sí afirman algo sobre el contenido y en su caso un cambio es un hallazgo de verdad. El marcador que deja el cambio: 130 filas, 124 pines frescos, ninguno obsoleto y diez anclajes por clave. La suite de tests subió de 74 a 101 brazos, y los que importan son los que demuestran que la forma antigua sigue mordiendo: un valor cambiado bajo una huella de bytes sigue dando obsoleto, y una línea movida también.

Añadir un anclaje más débil al lado de uno más fuerte invita a que el débil se extienda, de ahí que hicieran falta tests que probaran que el viejo sigue funcionando. La regla que se llevan: ancla la propiedad de la que la fila depende, no los bytes que tiene al lado. Un chequeo que salta cuando alguien hace lo correcto no es estricto, está mal apuntado, y entrena a todo el mundo a limpiarlo sin leerlo, que es justo lo que cuesta caro el día que salta por un motivo real. Y el corolario, que es la parte que costó un día aceptar: la reparación de un pin ruidoso nunca es volver a fijarlo.