Tres formas en que "la spec decía X" estaba mal
Mantengo un issue tipo spike para atrapar pequeñas señales de descomposición antes de que se acumulen: symlinks muertos, documentación desactualizada, un campo faltante en package.json. Esta semana finalmente vacié el backlog que se le había acumulado. Tres de los siete elementos resultaron ser el mismo tipo de error: algo escrito (un destino de symlink, una solución en curso, un token de CSS) dejó de coincidir con la realidad, y nadie lo notó hasta que fui a revisar.
El symlink que no apuntaba a nada. Tres archivos bajo .cursor/rules/ eran symlinks versionados hacia ~/Projects/cursor-rules/. Ese directorio no existe. No es que se haya “movido”, ~/Projects/ mismo no está ahí. Lo que sea que haya sincronizado esas reglas alguna vez fue una acción puntual, nunca un mecanismo real, y desde entonces los symlinks solo siguieron apuntando a la nada. Eliminarlos no fue una decisión difícil una vez que revisé, no había nada que restaurar.
La solución de auditoría que ya estaba en curso. El spike marcó 9 vulnerabilidades en el toolchain de build para npm audit fix. Antes de correrlo, revisé los PRs abiertos, tres ramas de Dependabot ya cubrían las mismas dependencias, en cola detrás de un issue anterior de CI gate. Correr audit fix a mano habría significado pelear contra mi propia automatización sin ninguna razón. A veces la solución es “confirmar que ya está programado” en vez de “hacerlo”.
La clase CSS que nunca existió. La documentación de mi propio proyecto describía un archivo global.css y un componente llamado MainContent. Ninguno de los dos existe en el código actual, la composición de la página es Hero más tres componentes de sección más un widget, no hay nada llamado MainContent en ninguna parte. La documentación había quedado desfasada de una versión mucho más antigua del sitio y nadie la había comparado con la realidad desde entonces. Reescribirla significó leer el árbol real de componentes en vez de confiar en lo que ya estaba escrito sobre él.
Ninguno de estos necesitó ingenio. Cada uno necesitó el mismo movimiento: no confiar en la descripción escrita, verificar aquello que describe. Un destino de symlink muerto, un rastreador de issues y un árbol de componentes, tres fuentes de verdad distintas, la misma lección cada vez.
Una pequeña solución adicional en el mismo lote merece una mención de una línea: una insignia de estado estaba en 9.6px, por debajo del tamaño que la mayoría de las guías de accesibilidad trata como piso para texto asociado al cuerpo, se subió a 12px. Y un botón de “iniciar juego” que se removía del DOM al hacer clic dejaba caer el foco de teclado en <body>, se lo movió al iframe que reemplaza al botón en su lugar. Ninguno de los dos es emocionante, pero ambos son del tipo de cosa que es invisible a menos que se esté usando un teclado o un lector de pantalla, que es exactamente por qué no los atrapan los checks de build o de tipos.
Lecturas relacionadas
El bug detrás del bug
Un widget de GitHub roto, rastreado hasta una demo del proyecto original en pausa, y, encontrado en el camino, una CSP fijada por hash invalidada en silencio por un arreglo de accesibilidad de una sola línea.
Los pills de filtro existían, solo que no donde alguien pudiera encontrarlos
Vistas filtradas por proyecto con una linda barra de navegación de pills, accesibles solo desde las tarjetas de la portada. El índice principal /blog, donde realmente aterriza todo el mundo, no tenía ninguna forma de entrar.
El CTA que apuntaba al dev log equivocado
El único llamado a la acción de la página de Deep Cut Atlas enlazaba al blog completo sin filtrar, un enlace que funcionaba, devolvía 200, y en silencio mandó a todos al lugar equivocado durante semanas.