Ninguno de Esos Cambios Funcionó Después de Recargar la Página

Las rutas estaban arregladas. El endpoint de estado fue reescrito. El formato de datos fue corregido. Cada cambio confirmado en el repositorio, visible en el archivo, exactamente como se pretendía.

Recargué el navegador. Nada cambió.

La misma tabla rota. El mismo lienzo en blanco.

Lo Que Realmente Estaba Pasando

La plataforma se ejecuta localmente en Docker — un conjunto de contenedores, cada uno corriendo un servicio, conectados a través de una configuración compartida. La aplicación web del front-end está montada por volumen: los archivos fuente en disco se mapean directamente al contenedor. Vite, la herramienta de build, observa los cambios de archivos y recarga el navegador automáticamente.

Excepto que no estaba observando.

En Windows con Docker corriendo sobre WSL2 — la capa de compatibilidad Linux que Windows usa para contenedores — las notificaciones de eventos del sistema de archivos en las que Vite confía para detectar cambios no se propagan correctamente a través de la frontera de virtualización. El sistema de notificaciones de Linux reporta el cambio. Windows no lo reenvía. Vite nunca ve la actualización del archivo. El navegador sigue sirviendo el código que estaba allí antes.

La solución fue una línea en la configuración de Vite: usePolling: true. En lugar de esperar ser notificado de cambios, Vite los revisa cada 300 milisegundos. Es ligeramente menos eficiente. Funciona.

El motor de mesas — el servicio backend que gestiona el estado real del juego — tenía su propia versión del mismo problema. Los servicios backend en este stack no corren con modo watch. Los cambios de código requieren reiniciar el contenedor manualmente. Comportamiento estándar para un servicio de grado producción. Solo hay que saber reiniciarlo.

La Otra Cosa Que Estaba Mal

Una vez resueltos los problemas del entorno, surgió un tercer bug: la ruta de mesa tenía un auth guard que siempre enviaba al navegador a la página de login.

No porque el usuario no estuviera autenticado. Lo estaba. El guard estaba revisando un valor de contexto de TanStack Router que nunca fue poblado — el router se configuró sin un context provider, por lo que context.auth siempre era undefined. El guard leía "no autenticado", redirigía a login. Login veía una sesión autenticada, redirigía de vuelta al lobby. El navegador entraba en bucle.

Una línea cambiada. El guard fue actualizado para leer directamente desde el authentication store, el mismo patrón que usa cada otra ruta en la aplicación. Resuelto.

Lo Que Esto Requiere de la Persona Frente al Teclado

Las correcciones eran correctas. El sistema no las estaba recogiendo. Esa observación — que código correcto y código corriendo son dos cosas diferentes — requirió conocer el entorno de desarrollo lo suficientemente bien para hacer la pregunta correcta.

El agente puede escribir la corrección. Puede rastrear el bug una vez que lo describes. No puede notar que el navegador está sirviendo una versión cacheada del código de antes del cambio de configuración. Esa observación es humana.

Conocer el sistema lo suficientemente bien para diagnosticar por qué una corrección correcta no está surtiendo efecto — esa es la parte que no se automatiza.

Después de la configuración de polling, después de los reinicios de contenedor, después de la corrección del auth guard: la mesa cargó. Los asientos aparecieron. El diálogo de buy-in se renderizó. Las cards del lobby tenían la altura correcta. Todo funcionó.

El próximo post cubre cómo se vio el integration testing una vez que tuvimos un sistema funcionando contra el cual probar — y por qué esa fase se ve igual sin importar si AI o humanos escribieron el código.

Para la perspectiva del founder sobre navegar este tipo de proceso de debugging — lo que el rol del human-in-the-loop realmente demanda cuando AI escribió la mayor parte del codebase — está en The Salty Korean.

Stay salty.