Fundamentos: cómo leer el registro de verificación de una compilación

Hace tres semanas construí un widget de reservas para una amiga que dirige un estudio de yoga — un chat, un plan que aprobé rápido porque estaba ocupada con otra cosa, una ejecución, y luego una tarjeta de versión con una marca verde que miré por encima y sobre la que seguí adelante. El martes me escribió preguntando si podía apuntar el sitio de un segundo estudio a la misma compilación. Antes de decir que sí, volví a mirar qué había significado realmente "verificado" tres semanas antes, y fue entonces cuando leí uno de estos registros por primera vez en lugar de simplemente confiar en la marca de verificación.

Vive justo en la tarjeta de versión, junto a la vista previa y las acciones de código — el mismo lugar al que irías para volver a desplegar o revertir. Lo primero que noté: está limitado a esa única versión, no a toda la conversación. Había iterado sobre esta compilación cinco veces persiguiendo un selector de fechas roto, y medio esperaba que el registro me contara la historia de todo el ir y venir. No lo hace. El registro de la versión 4 solo describe la versión 4. No tiene memoria de que la versión 2 se publicó con un formulario de inicio de sesión que fallaba silenciosamente, y no me dirá si la versión 5 corrigió discretamente algo que la versión 3 rompió. Cada registro es una instantánea, no un diff ni un registro de cambios — si quiero el historial de lo que cambió de versión en versión, esa es una vista completamente distinta. Esta solo responde "¿está bien esta?".

Al desplazarme hacia abajo, el registro se divide en seis filas:

Las seis estaban en verde, y mi primer instinto fue el mismo instinto equivocado que supongo tiene la mayoría de la gente: seguridad pasó, así que es segura; accesibilidad pasó, así que es accesible. Ninguna de esas dos lecturas sobrevive al contacto con lo que realmente hacen las comprobaciones. La aprobación de seguridad significa que lo superficial — una concatenación de cadenas en una consulta, una clave de API expuesta en el paquete del cliente, un eval sobre algo escrito por un usuario — no apareció. No es un día con un pentester. El estudio de mi amiga no cobra pagos a través de este widget, solo nombres y horarios, así que el nivel era suficiente para ella. Si hubiera sido un flujo de pago, habría querido más que un nivel mínimo.

Accesibilidad fue la fila que realmente me hizo detenerme a buscar algo, porque "aprobación de axe" suena exhaustivo y no lo es. Axe — el motor automatizado que corre por debajo — detecta de forma fiable entre un tercio y la mitad de los criterios de éxito de WCAG: texto alternativo faltante, malas relaciones de contraste, campos de formulario sin etiquetar, mal uso evidente de ARIA. No puede decirte si el desplegable del selector de fecha personalizado que había pedido es utilizable con un lector de pantalla, si al navegar con tabulador por el flujo de reserva de varios pasos el foco cae en un lugar sensato, o si el estado "confirmado" frente a "pendiente" que había coloreado en verde y amarillo es un problema para alguien con daltonismo rojo-verde. Eso requiere que una persona recorra la compilación con las herramientas que realmente usan los usuarios con discapacidad, desactivadas para la prueba. Axe es una señal real, no es nada — es la capa de corrector ortográfico de la accesibilidad, no el editor.

Conformidad fue la fila que casi me salté, porque suena burocrática — "contiene lo que prometía el plan" — hasta que recordé que el plan que había aprobado lo escribí distraída, y sinceramente no podía recordar si había pedido confirmaciones por correo electrónico o solo por SMS. Esta es la capa que compara la compilación con el plan, no con mi intención real, y pasó, lo que me indicó que la compilación coincidía con lo que había aceptado, no necesariamente con lo que había querido decir. He oído hablar de compilaciones que eran funcionalmente sólidas y seguras y aun así fallaron en esta capa porque una función se eliminó silenciosamente por presión de tiempo. Es la capa que mantiene a una compilación fiel a la conversación que la produjo, incluso cuando la conversación en sí fue algo descuidada.

Debajo de las seis filas había una lista más larga, dividida en dos categorías, y ahí es donde pasé más tiempo. Los elementos de corrección obligatoria no son cosas que actualmente estén mal en la compilación — son comprobantes. Una línea decía que la capa de revisión había señalado un caso en el que una cadena de fecha se interpolaba directamente en una consulta, y ya se había corregido antes de que esta versión se marcara como completa. No estaba mirando una herida abierta; estaba mirando una cicatriz. Esa distinción importa, porque si lees una entrada de corrección obligatoria como una advertencia en vivo, vas a perder tiempo preocupándote por algo que ya está resuelto.

La lista de avisos era más larga, y en su mayoría eran cosas que yo misma habría dicho si estuviera revisando el código de un colega sin querer bloquear la fusión: "considera extraer el bloque repetido de renderizado de horarios en un componente compartido", "este endpoint no tiene limitación de tasa, lo cual está bien para una herramienta interna de reservas, pero conviene reconsiderarlo si se vuelve pública". Nada en esa lista era un defecto. Eran decisiones que un verificador tomó teniendo solo el plan y el código para guiarse, y para el planificador interno de un estudio de yoga, cada una de esas decisiones cayó del lado razonable. Si el estudio de mi amiga hubiera sido una franquicia con el widget incrustado en cincuenta páginas de ubicaciones, habría querido rebatir lo de la limitación de tasa — la clasificación depende de un contexto que el verificador solo puede suponer, y cuando una suposición te parece incorrecta, lo correcto es decirlo en el chat, no asumir que la etiqueta es definitiva.

Lo que me llamó la atención, al ver una lista de avisos de tamaño considerable junto a una columna de correcciones obligatorias vacía, es que casi leí la longitud de esa lista como una mala señal. No lo es. Una compilación sin ninguna nota de aviso obtuvo una aprobación estrecha o tuvo suerte; una compilación con un montón de elementos de "considera" y nada pendiente en correcciones obligatorias es una que realmente ha sido examinada con cuidado. La columna de avisos es lo que se supone que debe quedar una vez que se han eliminado los problemas reales.

Lo otro que me obligué a hacer, dado que este registro tenía tres semanas de antigüedad, fue comprobar qué capas realmente se ejecutaron antes de confiar en los veredictos. Las seis estaban presentes aquí, pero desde entonces he visto una compilación donde la accesibilidad simplemente estaba ausente de la lista en lugar de marcada como aprobada o fallida — eso no es lo mismo que ser omitida por no ser importante, es una señal de que la comprobación no se ejecutó para ese tipo de sitio o esa configuración de indicadores en particular, y leer la ausencia como una aprobación silenciosa es exactamente el error que este formato invita si estás leyendo por encima.

Nada de esto me dijo si el flujo de reservas del estudio de yoga realmente convierte, si la gente lo abandona en el paso de elegir horario, o si la idea misma de un widget personalizado en lugar de simplemente enlazar a Calendly era la decisión correcta desde el principio. La verificación demuestra que una compilación funciona según lo prometido, no que la promesa fuera la correcta — son preguntas separadas, y he visto compilaciones pasar limpias por todas las capas y aun así fracasar con usuarios reales porque "funciona correctamente" y "resuelve el problema correcto" no se superponen tanto como uno quisiera. La mitad de esto que realmente responde a la segunda pregunta es el bucle de medición, y ambas cosas están pensadas para leerse juntas. Un registro de verificación impecable en una función que nadie reserva sigue siendo una función que nadie reserva.