El Bug Que Estaba Escondido en la Capa de la API

La vista de la mesa cargó. El canvas se renderizó. La mesa existía en la base de datos.

Pero cuando el front-end le pidió al servidor el estado actual de la mesa — los asientos, los stacks, quién está sentado dónde — el servidor devolvió un 404. Nada. Sin asientos, sin datos del juego, nada con lo que el renderer pudiera trabajar.

El canvas estaba en blanco porque no tenía nada que dibujar.

Aquí está la explicación técnica, lo más corta posible: el API gateway frente al table engine quita un prefijo de cada URL antes de reenviar la request. /api/v1/tables/... llega al table engine como /tables/.... Las rutas del table engine, tal como las escribió la sesión de build, fueron registradas esperando el prefijo completo — entonces el servidor estaba escuchando en /api/v1/tables/... pero recibiendo /tables/.... Cada request fallaba.

No es un error de lógica. No es un algoritmo roto. Una tabla de routing con las direcciones equivocadas. El tipo de cosa que solo emerge cuando pruebas el stack completo junto.

Cuánto Tiempo Tomó Encontrarlo?

Inicio hasta arreglo: menos de una hora.

Eso es rápido. Aquí está lo que lo hizo rápido: la metodología de debugging.

Trabajar con un agente AI en esto no significa preguntar "¿qué está mal?" y esperar una respuesta. Significa darle al agente el contexto correcto simultáneamente — la configuración del proxy que maneja el prefijo, los archivos de registro de rutas en el table engine, los logs de requests mostrando 404 — y pedirle que trace la discrepancia.

Cuando esas piezas son visibles juntas, el agente puede hacer pattern-matching a través de una superficie que le tomaría a un ingeniero humano veinte minutos solo navegar. El agente encontró el mismatch entre la regla de rewrite del proxy y el registro de ruta en el table engine en cerca de tres minutos.

El Bug Detrás del Bug

Encontrar el bug de routing expuso el siguiente.

El endpoint ahora respondía. Pero los datos que devolvía estaban en el formato equivocado.

El table engine habla un idioma internamente: números de asiento, códigos de estado como occupied, conteos de fichas en bruto como enteros simples. El renderer del front-end habla otro: índices de asiento, strings de moneda formateados como $235.50, nombres de campos específicos que espera por contrato desde una definición de tipo contra la cual fue escrito.

Nadie escribió una capa de traducción. La sesión de build escribió el endpoint y devolvió el formato interno. El renderer recibió datos que no reconocía y silenciosamente produjo nada.

Esta es la clase de bug que es notoriamente difícil de escribir un test para en avance. Tienes que tener ambos sistemas corriendo, conectados, e intentando hablar entre sí para verlo. Ningún unit test cubre el gap entre dos sistemas cuando ninguno tiene un bug por sí mismo.

Lo Que Esto Significa para la Metodología de Build

La fase de testing no significa que la metodología falló. Significa que la metodología nos llevó al testing.

Cada plataforma de software tiene una capa de integración donde las piezas tienen que encontrarse en el mundo real. El desarrollo spec-driven te lleva a esa capa más rápido. No la salta.

El próximo post en esta serie cubre lo que pasó cuando aplicamos las correcciones — y el browser mostró el mismo resultado roto de todas formas.

Para la metodología de ingeniería detrás de cómo construimos — el spec, las sesiones, lo que hace el agente durante una sesión y lo que hace el arquitecto — el write-up completo está en The Salty Korean.

Stay salty.