Parte 4 Construcción de la Estación Estación Donde el SDD Ayudó y Donde No

En las partes anteriores describimos el enfoque de Spec Driven Development SDD el proyecto Station Station y el flujo de trabajo con agent os. Aquí cuento la experiencia real de desarrollo con sus éxitos y sus fricciones. Veremos donde la estructura realmente ayudó y donde la solución requirió investigación manual y depuración tradicional. Si piensas usar SDD en tu próximo proyecto este artículo te ayudará a poner expectativas realistas.

Reto 1 Bypass de autenticación con Cloudflare

Contexto El proyecto depende de acceder a datos de transacciones Myki sin autenticación no hay datos y no hay proyecto. El bloqueo principal fue la protección Cloudflare Turnstile que detecta navegadores automatizados.

Qué sucedió El intento inicial con Playwright en modo headless fue bloqueado por un overlay de verificacion que impedía interactuar con el formulario. El objetivo en la especificación era sencillo extraer el token Bearer de la respuesta de autenticación para llamadas API pero la spec no capturó la complejidad de la deteccion de bots.

Cómo ayudó SDD La especificación dio criterios de éxito claros extraer el token Bearer y una descomposición de tareas que permitía localizar donde fallaba el proceso lanzar el navegador navegar hasta login rellenar credenciales enviar formulario extraer tokens. Registrar cada intento fallido dentro de la especificación impidió repetir enfoques inútiles días después.

Qué no pudo resolver SDD no resolvió el problema técnico profundo Cloudflare detectaba headless y a veces incluso el modo visible parecía automatizado. Probé cambios en user agent cabeceras plugins de stealth y al final la solución requirió entender fingerprinting de navegadores.

Solución final Tras investigar lo que funcionó fue usar un perfil de navegador persistente con metadatos mínimos cookies preferencias historial vacíos y lanzar Playwright con launch persistent context usando ese directorio de perfil El contexto con perfil hace que Playwright parezca un Chrome real y evita la detección constante.

Lección SDD te da el objetivo y el camino para llegar pero no sustituye investigación ni experiencia técnica. La especificación no te da hacks contra Cloudflare. Lo valioso fue que cuando encontré la solución quedó documentada y reutilizable para futuras características.

Reto 2 Bug en múltiples capas manualAttendanceDates

Contexto Esta mejora apareció después de que el sistema ya funcionara para detectar asistencia via PTV. Necesitaba un campo manualAttendanceDates para añadir días en oficina que no generan transacción Myki.

Qué sucedió La característica se implementó y desplegó pero las fechas manuales no se mostraban correctamente. No era un bug único sino varios problemas distribuidos entre backend workflow y frontend.

Cómo ayudó SDD La spec ofrecía un mapa claro del flujo de datos y una lista de tareas para comprobar parsing de configuración backend generación de JSON y renderizado en el UI. Con esa guía pude ir capa por capa y aislar donde faltaba la fusión de fechas manuales con las detectadas.

Qué no pudo resolver Encontrar los puntos exactos donde tocar el código requirió revisar manualmente el backend las acciones en GitHub y el frontend. La IA pudo aplicar correcciones una vez que le di la ubicación correcta pero identificar esas ubicaciones y entender las suposiciones cruzadas fue trabajo humano.

Lección SDD facilita la depuración sistemática pero no reemplaza la necesidad de entender integraciones entre componentes. Añadir un campo de configuración en sistemas multi capa suele implicar cambios en varias piezas y eso hay que descubrirlo inspeccionando el código y trazando el contrato de datos.

Reto 3 Manejo de zonas horarias

Contexto El calendario mostraba días desplazados un dia respecto a los valores en attendance.json La especificación decía mostrar exactamente las fechas del JSON.

Cómo ayudó SDD El criterio claro hizo evidente que el resultado era incorrecto y la descomposición de tareas permitió centrar la búsqueda en el parsing de fechas y no en el renderizado.

Qué no pudo resolver La spec no especificó la zona horaria y ahí estuvo la trampa JavaScript toISOString convierte a UTC y para fechas cercanas a medianoche el día puede cambiar. La solución fue formatear en la zona local por ejemplo usando toLocaleDateString con formato ISO local.

Lección Las especificaciones deben explícitamente exponer suposiciones no obvias como manejo de zonas horarias. Muchas veces no sabes qué precisar hasta que un bug te lo revela.

Reto 4 Integración con librería de terceros

Contexto Integré la librería date holidays para detectar festivos de Victoria y mostrarlos en rojo en el calendario.

Qué sucedió La librería devolvía fechas como string con hora YYYY-MM-DD HH MM SS en lugar de objetos Date. La spec indicaba la librería y el comportamiento esperado pero no detallaba el formato de salida.

Cómo ayudó SDD Tener documentado que debíamos usar esa librería evitó decisiones posteriores y permitió crear tests para la integración.

Qué no pudo resolver La sorpresa en tiempo de ejecución requirió inspeccionar la salida real de la librería y convertir manualmente la cadena a un objeto Date usando substring y constructor Date con año mes dia para preservar la zona local.

Lección No des por sentado que una dependencia devuelva exactamente lo que esperas. Ejecuta y comprueba el output y registra quirks en la spec para que futuros desarrolladores no tropiecen con lo mismo.

Reto 5 Preferencias de usuario vs suposiciones de desarrollador

Contexto Por defecto react calendar pintaba fines de semana en rojo y pensé en eliminar esa estilización para evitar confusión con días de asistencia.

Qué pasó Antes de cambiar pregunté al usuario que era en este caso yo con rol de usuario y la respuesta fue que prefería mantener fines de semana y festivos en rojo. Casi elimino una funcionalidad valiosa por actuar como desarrollador en lugar de usuario.

Cómo ayudó SDD El flujo de trabajo con puntos de revisión me obligó a validar cambios importantes con el usuario antes de implementarlos y documentar la decisión en la spec.

Qué no pudo resolver SDD no sustituye preguntar al usuario. Crea el punto donde preguntar pero no realiza la comunicación por ti.

Lección Estructura no es lo mismo que juicio humano. Aprovecha las revisiones para alinear decisiones con valor real.

Dónde SDD aportó más valor

1 Criterios de éxito claros Cada bug fue evidente gracias a la definición de éxito en la spec eso acelera identificar desviaciones. 2 Depuración sistemática La descomposición por tareas ofrece un mapa de donde probar configuraciones backend JSON UI. 3 Documentación de decisiones Volver al proyecto una semana despues fue mucho más rápido porque las razones y supuestos estaban escritos. 4 Puntos de revisión Forzaron pausas para feedback y evitaron cambios impulsivos.

Límites de SDD

1 Integración multi capa Requiere comprensión holística humana para conectar contratos de datos entre componentes. 2 Suposiciones ocultas Cosas que parecen obvias como zona horaria deben ser explicitadas. 3 Comportamiento de librerías externas Solo descubres quirks ejecutando y depurando. 4 Preferencias de usuario Estructura facilita preguntar pero no reemplaza la comunicación con usuarios.

Retorno honesto de la inversión SDD

Tiempo en especificaciones aproximadamente 4 5 horas implementación 2 dias depuración 4 6 horas total alrededor de 3 dias para entregar 8 funcionalidades completamente desplegadas. Ahorros concretos depurar fue más rápido gracias al enfoque sistemático la documentación evitó re aprender el proyecto y el checklist de tareas redujo la probabilidad de dejar funcionalidades a medias. Costes inversión de tiempo inicial en escribir specs y curva de aprendizaje del flujo con agent os.

Resumen

Spec Driven Development no es magia pero proporciona estructura documentación y puntos de control que transforman como se afrontan problemas complejos. Los retos reales como fingerprinting de navegadores bugs distribuidos zonas horarias y comportamientos inesperados de dependencias hubieran aparecido con o sin SDD. La diferencia es que con SDD el proceso fue más sostenible reproducible y recuperable.

Sobre Q2BSTUDIO

En Q2BSTUDIO somos una empresa de desarrollo de software dedicada a crear aplicaciones a medida y software a medida para clientes con necesidades reales. Somos especialistas en inteligencia artificial IA para empresas agentes IA implementación de servicios cloud aws y azure ciberseguridad y pentesting así como servicios de inteligencia de negocio y power bi. Si buscas una solución a medida para tu producto podemos ayudarte desde el diseño hasta la puesta en producción y el soporte continuo.

Conecta con nuestras áreas principales si necesitas desarrollar una aplicación personalizada visita desarrollo de aplicaciones y software multiplataforma y si tu foco es aprovechar inteligencia artificial en tu empresa consulta nuestra oferta de inteligencia artificial y soluciones IA para empresas. Además ofrecemos servicios de ciberseguridad pentesting y consultoría cloud para asegurar y optimizar tus sistemas.

Qué sigue

En la parte 5 cerraremos con un marco de decisión para saber cuándo usar SDD y cuándo optar por un enfoque más ligero y además explicaremos cómo empezar a trabajar con Station Station y agent os. Si quieres que auditemos tu flujo de desarrollo o te guiemos en la adopción de SDD en tu empresa contacta con el equipo de Q2BSTUDIO.